views:

355

answers:

2

We are going to develop an ASP.NET website in 30 language. What is the best solution for developing that site? which architecture to be used?

+4  A: 

I suggest storing UI properties in resource files (.resx) and have the CurrentUICulture to the specific language for each request:

<globalization culture="auto" uiCulture="auto" />

If your Web site is mostly content-oriented rather than a business oriented application that differs heavily based on the language, you might want to consider building separate set of pages for each language and redirect the user based on a cookie or profile property or Request.UserLanguages. It's not possible to give a general prescription for globalization problem. The best architecture differs significantly based on the nature of each individual project.

Mehrdad Afshari
Web site is content oriented
Ahmed
What is the best architecture for developing this?
Ahmed
If the content and page orientation differs significantly for each individual language (and there's no one to one relation between each UI element), I think your best bet is to have a set of `aspx` pages for each language and just share the business logic using a class library.
Mehrdad Afshari
+1  A: 

NLS is a recurring requirement, and often when the question about NLS functionality is asked, the people asking are not aware of the complexity. NLS typically split into (at least) 2 areas:

  • NLS in the UI

  • NLS in the data

In your case, a content-based website, you may even split the second point into - data generated by the website provider and - user generated data.

For UI NLS you can use the .resx mechanism as mentioned by Mehrdad, but you should be aware that every work on localization always requires to edit the source code (i.e. the resx files).

When I had to develop a multi-languge web app, I therefore chose to handle the NLS requirement in my code, and created a couple of NLS-specific tables that mirrored the UI (btw this was the motivation to write graspx: extract all visible texts from aspx source, such as Label.Text etc). There is a separate application to upload the UI definition, and let translators do their work. The main application has an import functionality for the translated texts.

The data model looks like this: Page - PageItems - PageItemTexts (with reference to a Language), so it's quite simple.

The same model can be applied to the content: instead of Page and PageItems, you simply have ContentItems, which hold a PK and a identifier only, and a table holding the text of the ContentItems associated with a language.

Additionally, you may define some sort of language fallback chain, so that a text which is not yet translated is displayed in the original language, or some other (closely related) language.

The displayed language can be selected by the language provided by the browser (HTTP_ACCEPT_LANGUAGE), but should be allowed to be overwritten by the user (e.g. via a combobox). The selected language should be stored in a session variable, in a cookie, or in the database (for registered users).

devio