How do you implement a multiculture web application

Question

Hi,

I believe several of us have already worked on a project where not only the UI, but also data has to be supported in different languages. Such as - being able to provide and store a translation for what I'm writing here, for instance.

What's more, I also believe several of us have some time-triggered events (such as when expiring membership access) where user location should be taken into account to calculate, like, midnight according to the right time-zone.

Finally there's also the need to support Right to Left user interfaces accoring to certain languages and the use of diferent encodings when reading submitted data files (parsing text and excel data, for instance)

Currently I'm storing all my translations for all my entities on a single table (not so pratical as it is very hard to find yourself when doing sql queries to look into a problem), setting UI translations mainly on satellite assemblies and not supporting neither time zones nor right to left design.

What are your experiences when dealing with these challenges?

[Edit]

I assume most people think that this level of multiculture requirement is just like building a huge project. As a matter of fact if you tihnk about an online survey where:

1. Answers will collected only until midnight
2. Questionnaire definition and part of the answers come from a text file (in any language) as well as translations
3. Questions and response options must be displayed in several languages, according to who is accessing it
4. Reports also have to be shown and generated in several different languages

As one can see, we do not have to go too far in an application to have this kind of requirements.

[Edit2]

Just found out my question is a duplicate

i18n in your projects

The first answer (when ordering by vote) is so compreheensive I have to get at least a part of it implemented someday.

Answer 1

Go slow.

Think everything through, then really think about what you're doing again. Bear in mind that the more you add (like Right to Left) the longer your QA cycle will be.

Answer 2

The primary piece to your puzzle will be extensive use of interfaces on the code side, and either one data source that gets passed through a translator to whichever languages need to be supported, or separate data sources for each language.

The time issues can be handled by the interfaces, because presumably you will want things to function in the same fashion, but differ in the implementation details. To a large extent, a similar thought process can be applied to the creation of the interface when adjusting it to support differing languages. When you get down to it, skinning is exactly this, where the content being skinned is the interface, and the look/feel is the implementation.

Answer 3

Do what your users need. For instance, most programmer understand English, there is no sense to translate posts on this site. If many of your users need a translation, add a new table column with the language id, and another column to link a translated row to its original. If your target auditory contains the users from the Middle East, implement Right to Left. If time precision is critical up to an hour, add a time zone column to the user table, and so on.

Answer 4

If you're on *NIX, use gettext. Most languages I've used have some level of support; PHP's is pretty good, for instance.

Answer 5

Be very very cautious. From what you say about the i18n features you're trying to implement, I wonder if you're over-reaching.

Notice that the big boy (e.g. eBay, amazon.com, yahoo, bbc) web applications actually deliver separate apps in each language they want to support. Each of these web applications do consume a common core set of services. Don't be surprised if the business needs of two different countries that even speak the same language (e.g. UK & US) are different enough that you do need a separate app for each.

On the other hand, you might need to become like the next amazon.com. It's difficult to deliver a successful web application in one language, much less many. You should not be afraid to favor one user population (say, your Asian-language speakers) over others if this makes sense for your web app's business needs.

Answer 6

I'll describe what has been done in my project (it wasn't my original architecture but I liked it anyways)

Providing Translation Support

Text which needs to be translated have been divided into three different categories:

1. Error text: Like errors which happen deep in the application business layer
2. UI Text: Text which is shown in the User interface (labels, buttons, grid titles, menus)
3. User-defined Text: text which needs to be translatable according to the final user's preferences (that is - the user creates a question in a survey and he can also create a translated version of that survey)

For each different cathegory the schema used to provide translation service is different - so that we have:

1. Error Text: A library with static functions which access resource files
2. UI Text: A "Helper" class which, linked to the view engine, provides translations from remote assemblies
3. User-defined Text: A table in the database which provides translations (according to typeID of the translated entity and object id) and is linked to the entity via a 1 x N relationship

I haven't, however, attacked the other obvious problems such as dealing with time zones, different layouts and picture translation (if this is really necessary). Does anyone have tackled this problem in a different way?

Has anyone ever tackled the other i18n problems?