Keith Watanabe * NET 2.0

After talking to my coworker the other day, I realized that the majority of the websites springing from the US (or any place for that matter) with an intention to go international (in which most seemingly have that purpose) don't really understand what localization implies.  It seems that most web architecture consider localization a simple matter of translation.  This is not entirely the meaning behind localization.

One big issue would be dealing with time.  For instance, one of the in house applications use Australian time.  So reports come out questionably for people outside of Australia.

After consideration, I've come up with a few ideas in terms of architecture for localizing an application.

• The database backend must be setup so that date/time stamps are all handled as long integers set with GMT.  Display would then use the browser's settings to convert the times into something more readable for the local viewer.
• Database tables need to consider localized mappings for any lookup data.  Lookup data means things like drop downs or even product information.  You can have a default table having default language information, but additional tables would exist to extend each column that requires some form of display.  Once an application determines what language is required for display, the correct table information would be pulled out.
• Controller logic must be completely dumbed down.  There should be absolutely zero business decisions in the controllers.  All processing logic should go into a business layer that provide web services or stateless method calls, which involve either data processing or some other system interaction (e.g. file I/O, mail, etc.)
• Non-enforced templates/views.  What this means is that the local developers/office have more control over the display and flow of an application.  This avoids the one-size-fits-all problem that many web companies who go international suffer.

The biggest differentiation I've started to see in the way international applications should be developed is that the view portions must be heavily customizable.  Right now, most web applications simply use templates with some message packaging method that allows people to easily (or so they think) translate each line of text.

However, I think this notion is terribly inefficient and only gives rise to problems, especially when sites are designed with set sizes.  For instance, English texts tend to be longer than Japanese, so if a site is designed with absolute positions, etc. the layouts will get destroyed.  Another major issue is workflow.  It has been said that in Japan, for example, people like having all information aggregated into one place.  However, I've seen applications that splits up data inefficiently, so people here suffer from dealing with poor workflows.  Providing pure data interfaces and processing logic would empower local developers to customize the interface, not just the translation aspects.