Where to place language translations in an multitiered architecture

Question

I build an app with following layers:

• WEB presentation layer
• Business Logic Layer - BLL - called from WEB UI through HTTP web services
• WindowsService - Runtime - called from BLL through net.pipe

BLL can also be called from 3rd party for integration into other customer's systems.

Let's say that there is an validation error that happens in the Runtime or even BLL. Where would be better to put translations:

1. in the exception message - means that we must send UICulture from WEB layer to lower layers
2. BLL and Runtime are returning error codes or custom Exception derived types and translation is performed in WEB UI layer
3. some other method

What is the best practice for supporting multiple languages in SOA architectures ?

EDIT: I should probably use the term tiers instead of layers.

• WEB UI tier is implemented in ASP.NET web forms and will be deployed on server A under IIS.
• BLL and Runtime will be deployed on server B but are separated by process boundaries (BLL runs under ASP.NET worker process because of WCF services and Runtime runs as separated windows service process).

Answer 1

I'm not quite sure what is your definition of the WEB UI. If you use the MVC pattern, the Controller would be place to take care of showing the right language version in the UI, while the text itself would be in the View layer. What I didn't understand is what plays the role of the controller in your architecture. Does BLL mean only including processing logic and no communication between UI and Services? If so, then probably the Web UI layer would contain the localization logic.

I would also say that it depends a lot on the technology you use in the project. ASP.NET for example has a built-in localization model that you can use. I'm not saying it should serve as an example, even on the contrary - ASP.NET breaks separation of concerns. But I think this is an issue, which would have very different solutions in different custom architecture models, as in your case.

Answer 2

My advice for your issues is general because I do not know the specifics of the .NET platform you are working with.

From your question, I see two distinct problems.

1. You web presentation layer will be language-dependent. It will require custom CSS, fonts, spacing and even custom content. Do not fool yourself that this will not be needed. This is one of the biggest mistakes people make initially when internationalizing web applications. You will need another style for the language. So, if you are using a template approach you can put most of your language content right in the language-dependent template.

2. From the description of your problem, it sounds like you will also need to handle localized error messages. There is two approaches two this: you can have a language file where you localize when the error is thrown using a resource file solution. Another approach is to have your error messages use a common identifier and parameters and have another layer catch the message and localize it. I myself prefer the former solution since it is simpler.

Also remember that if you are writing your error messages to a log file, that the error messages are in a language that the developers can read. Likewise for errors displayed to users in the GUI, you will want some way for the users to identify the errors to the developers who do not speak the user's language. This could be done by using numbers - I prefer using short keys like DATABASE_ERROR_BAD_QUERY.

Answer 3

The translation should be handled by the presentation layer as it relates to the view. The more context that can be added to the message the better and the business logic might not be aware of the context nor should it be.

An approach that I've used is as follows:

• Business logic throws unique, defined error codes which can be used as keys into a resource bundle to get a translated message.

• Presentation layer maintains a text package containing all the error code translations separate from the general presentation layer code.

• The presentation layer depends on
  both the business logic and the text package.

• 3rd party clients of the business logic, like a web service, can choose to include the text package as a dependency if they want the standard error code translations. Otherwise they can handle the error codes thrown by the business logic on their own.

Answer 4

Based on how your application is structured, you may need internationalization in two locations:

1) Software itself. Menus, Dialogs, Messages, Labels, Reports, etc.

2) Content. Your application when running in more than one language will likely need to handle content in more than one language.

I have had good luck in seperating the management tools and the publishing logic in different layers (so far).

First, consider placing the language translation management and generation logic (resource bundles, etc) in the Business Logic. So, for all your translations, you want a way to quickly sync all data entries as they get added to the system in all languages from a master language (english), and then populate and manage those. So, if you're using resource bundles for example, generate the rb files from a database for all the languages.

Second, publish the language translations logic at the presentation tier. It has more to do with presentation and formatting. You inevitably will run into issues with localization for dates, times, currencies, etc that you can handle pretty well here. You may or may not build your own library to publish these things as the confines, or flexibility of your programming language may or may not allow.

If you can give more details I'm sure there are other insights available from everyone here.

Good Luck!