At no time is freedom of speech more precious than when a man hits his thumb with a hammer.

~Marshall Lumsden

This is an experiment in designing an internationalization feature which I’ve been thinking about for a while. The idea is for people to come up with designs and implementations for the described requirements, and get a healthy discussion going on how to get a feature like this implemented in the best way. I’ve came up with some features and requirements which should make the design somewhat interesting.

Wanna play? If so, continue reading.

Now, let’s consider a website, which is to be deployed for several markets (in several countries), and serve both residential and corporate customers.

Requirements

A “tag” is an identifier for any given text that may be translated. The “tag” can be the text itself in the source language, or an identifier such as LABEL_CLICK_HERE, all depending on the implementation.

A tag’s content can be translated to any given language

This is the most basic feature, and does not need any explanation.

Any given market should be able to use the application in any given language

Customers in the French market should be able to view the application in German and so on. Does not sound tricky, but see next point.

A tag’s content *may* have different meaning in different markets

For example, in the US a zipCode validation error will differ from the zipCode validation error used in Spain, but surname validation errors will be the same. This also goes for descriptive texts for features and services which might differ. However, for 90%+ of the translated texts, the English translation in Spain would be the same as the english translation in the US.

A tag’s content *may* differ based on the context of the user

Imagine the front-page when a used is logged in. A text is presented here with information about available features, instructions on how to use them etc. Now, some of these features are not available for residential customers, while some are exclusive to residential customers. The usage/instructions of the features may be different for corporate customers. In addition, both residential and corporate customers have roles in the application (admin users and regular users), and the content may differ based on the role. Most of the tags will just have one content, but some may have several. The available contexts could be visualized as a tree structure, with ‘ALL’ at the top, which forks out to corporate and residential, which in turn forks out to admin / user:

Contexts

Contexts

When retrieving content for a tag the system should first look for the user’s context, for example “Residential Admin”, and if no content is present it shall select the parent etc.

Any changes to a tags’s content should be kept in a history log

Every time a tag’s content is changed, the old version should be kept for historical purposes. A nice bonus would be to be able to change a tag’s content ahead of time , that is, setting an effective date.

These are the basic requirements I’ve made up for this experiment. Now, I’d like to hear how you tackle internationalization in your application, and how you would design a implementation which would sastisfy the requriements described here. I’m working on my own implementation for this which I’d like to share after I’ve seen what other people come up with. If you have suggestions for more requirements which would make this even more interesting, please send a comment!

[tags]PHP,Internationalization[/tags]