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.


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:



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!


6 Responses to “Internationalization in applications – Call for discussion”

  1. I think you’ve got your requirements overgeneralized and as such mixed up. Mixing business contexts (corporate and residential customers) with cultural is actually mixing cross-cutting concerns.

    Besides, you missed many more features required for real internationalization, like formatting numbers and dates, handling text direction, different measurement systems (imperial vs. metric), etc.

  2. Hi Bruce, and thanks for the comment.

    I agree that there are quite a number of features when it comes to formatting (currency etc) that’s not covered there, and I’ll update the post to cover those topics later on.

    How would you implement support for the contexts as described? Please bear in mind that it’s not necessarily corporate vs residential, and perhaps that was a poor example chosen by me. User vs admin is perhaps better. The two different contexts will share 90%+ of the translated texts, hence splitting them is not a good approach in my opinion.

  3. admin :
    How would you implement support for the contexts as described? Please bear in mind that it’s not necessarily corporate vs residential, and perhaps that was a poor example chosen by me. User vs admin is perhaps better. The two different contexts will share 90%+ of the translated texts, hence splitting them is not a good approach in my opinion.

    I don’t know the specifics of your application, but usually different levels of users are presented with different interfaces, like admin control panel vs user interface. This is definitely true for the application I’m currently working on, but I understand that it may not be the case for your product. We have separate admin and user interface, but both use the same translation mechanism in view scripts, like this:


    Since translations are stored independently of view scripts, we can reuse translations in different view scripts without problems. The only thing to note is that translations should be logically complete chunks of text, therefore some templating support (even if it’s the most basic one, such as offered by MessageFormater class from pecl/intl extension) should be provided.

    If application required single interface for different levels of users I would go for using several view scripts and choose appropriate view in controller based on user level.

  4. Well i have to agree with Bruce. Adding so much logic into translation service might become very hard to manage.

    How would you use the service classes (or whatever would it be)? Passing context and tag? then context would be growing and growing and translation service with it.

    I would employ simpler solution, keep the decision of which text to show in business logic as it is closes to the source of what should be shown (at least more or less what you want to show) and then in translation service just find the correct string for it depending on locale. All you pass is locale (lets say language and country). Or you can even keep it in the service static variable and set it during bootstrap or something.

    View would just show the populated string.


  5. You should take a look at r3 project:

    It has support for the generic “contexts” you talk about, but they are called “intls” there, although they should really be called “variations”.

  6. You should see the I18N and L18N chapters at Symfony-project documentation. They will be very helpful.

Leave a Reply



You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">