In which layer shall i18n/multi-lingual be handled?

Question

Hi,

The project that we worked on consists of 3 tiers: the presentation tier, the business logic tier and data tier, I will call them here the front, mid and back.

The front is written in PHP and it communicates with the mid via web service (XML-RPC, SOAP, etc.). Users can also write their own clients to talk to the mid. The nid is developed in Java, it performs business logic and provides data to the front, it may also throws exception to the front.

The question I am having is, if I want to have multi-lingual support in future, where shall I develop i18n? It makes sense to be at the front because of all the texts that it has, what about exception and other messages coming from the mid?

If a user develops their own client and the mid has multi-lingual support, the messages coming from it (like exception as said above) can therefore be in their selected language. That's the advantage I'm seeing. I just don't like the idea of having two layers with i18n code and having to handle i18n when I am handling an exception.

Answer 1

Hi,

I would ask you a question: The i18n data would be handled in the back layer (data tier)? If you say yes then you got it, but if you say no then I would put it in the mid layer (busieness tier) because medium and larger projects use to interact with I18N (exceptions, currencies, message formats, time zones, charsets, etc...)

I would put it in the front layer (presentation tier) for smaller projects.

Regards.

Answer 2

If you want to be completely internationalized, exceptions and other messages from the middle-tier should not include text. You should specify a code that the client must look up in a table to understand.

Answer 3

It depends a lot on your application.

If you think UI localization, the presentations is definitely affected.

I would say that the middle tier should not generate any messages. Exceptions are intended for developers, not for users. So in the presentation capture the exception, and present it to the user in a localized way saying something like "Fatal error 12313 occurred, please send this report to ..." (maybe even nicer, you don't show the exception text at all, offer a "Send a crash report" button, with a "Show report" button for the user to see that you are not sending any private data).

But if you thing about stuff beyond UI, then the others might also be affected. The business logic might be affected (for instance the way the tax systems work are different from country to country). And that is independent of the UI (Canada or Australia have another tax system than US, even if the UI is still English). So you might want to design this layer very modular.

The content of the database might also be affected. Imagine you have products that are not available (or are banned) in certain countries. So you might need extra fields (or tables) to carry that info.

So in the end the answer is "you have to think about i18n at every level!" and ask yourself "what if"