Car Configurator Multilingual Architecture

This article has been updated and moved to a new location.

Overall Architecture

Figure 1 below shows the schematic architecture of the Car Configurator. There are also some screenshots available here.

Figure 1: Schematic View of the Car Configurator Architecture

This architecture has been developed as a function of the specific characteristics of the car configuration process:

• Marketing Purpose:
  The application serves to attract clients and thus has to provide a high quality user interface. Application failures or linguistic mistakes are not tolerable.
• Maintenance Emphasis:
  Car product configuration information is changing frequently, so that comfortable maintenance procedures became a hard requirement for the project. We decided to implement an Excel configuration interface for this phase of the project. Later project phases will feature an integrated product definition environment.
• Language and Country Specific Configuration:
  The product configuration is dependent both on language and country. For instance, the Swiss product configuration is available in the three languages of Switzerland (German, French and Italian), while the German language is used in the German, Austrian and Swiss country configurations.
• Price and Currencies:
  Euro, Swiss Franc, German Mark and Spanish Peseta are supported as currencies, including a complex configuration to provide rounded numbers for all major product options.
• Language and Country Specific Graphics:
  Graphical GUI elements can depend on language (text GIFs) or country (product appearance).
• Localization and Configuration Fallback Handling:
  The combination of language, country and product specific GIFs results in a combinatory explosion of the number of graphical elements. As a consequence, a fallback system handles missing GIFs for specific combinations and returns more generic images instead. Using this technique we were able to reduce the number of GIFs by a factor of 10 to about 1000. Fallback events are reported to the Workflow System for manual inspection.
  

Architecture Details

Figure 2 below shows a simplified class diagram for the Car Configurator that shows the various subsystems from Figure 1.

Figure 2: Schematic Car Configurator Class Diagram

Please note the Localization Subsystem on the right hand side. Its access class "Loc" defines a single static method

• Loc.getText(String key, String family, Locale locale)

that returns a language and country specific representation for any localizable item. It uses the Java default ResourceBundle structure as storage for the localization items. These ResourceBundles are filled with information coming from several RBLoader classes, which coincide with the ObjectFactories. This is a convenient solution because the ObjectFactory classes already have access to the underlying data sources.

Please contact me if you have doubts or questions. I am also available as a freelance consultant.