Advice on ASP.NET Multi-Lingual Strategy

Question

Hi brothers and sisters,

I am wondering if anyone would share their experience on what they think as the best strategy to enable dynamic multi-lingual system using .NET

I have a customer who wishes to have an semi-MRP system that stores all Product's Materials and specs. These information will later be used for other modules such as Invoices, Purchasing, Marketing (extracting the information for printing purposes) and many more.

The thing is, he wants everything to be stored multiple languages. He is also unable to fixed the number of languages. Hence, the number of languages will grow throughout time.

So I guess what I am asking is, what is the best strategy to setup a dynamic language enabled website that encompasses the field names (eg, name) and also it's data (eg, Lasker).

Many thanks in advance, Lasker

Answer 1

There are several options available.

---

First, to the labels and elements of UI.

Here are generally two options possible, you either use resources (*.resx) or roll out your own multilingual support on the database level. They both have their advantages and disadvantages.

Resoures:

[+] Easy solution, everything is ready for immediate use. You define a textual resource in a family of files named like Orders.en.resx, Orders.fr.resx etc. In code you reference these strings as Resources.Orders.Title. So it is a simple solution for static elements of UI.

[+] Resource files are basically simple XML documents that can quickly be read and parsed, so not much overhead or performance loss.

[-] If you need to change something, you will have to recompile the project. That consequently means you will need the development environment (VS) installed for anyone who may consider updating texts. Then, you will also need to deploy the recompiled version again. The same applied for introduction of new languages into the system.

[-] Will not work for non-technical stuff, since participation of specialists required.

Custom database-driven multilingual solution:

[-] Will require some effort and time to design and implement

[-] Every single UI text will be pulled from the database, which means performance drop and extra load on the database

[+] Will allow dynamic on-the-fly change of texts and deletion/addition of new languages. No recompilation or deployment will be required.

[+] Now a huge plus. Since no technical skills are required to work on texts, you can outsource this work to any location. You may implement a web interface and change tracking system for professional translation service shops to correct your texts and perform translations to any language you need quickly after new texts are discovered.

---

Now to the dynamic texts (actual content).

Here you can either split each text to be stored as an extra record per language in some table or to merge all translations into a single entity.

Multiple records:

Imagine following database model:

[Language]
-----------------
ID    Description

[Translation]
------------------
ID    FallbackText

[TranslationText]
--------------------------------
ID    TRID    LanguageID    Text

[Order]
------------------------------------------------
ID    TitleTRID    DescriptionTRID    RemarkTRID

Everywhere in the database where you need to store a multilingual text, you will instead reference some TranslationID. Then dependent on the active language, you system will look for an appropriate translation or, if not found, return a default text (usually set by developers).

Single entity:

You keep all translations for a given text in one string by using some means of distinguishing particular translations. XML naturally works here.

<translation>
  <en>Order</en>
  <de>Bestellung</de>
  <fr>Commande</fr>
</translation>

Here you database model will be simpler but you will need to parse every single text to extract the needed version.

---

These are the widely used strategies. Which one will work best for you will depend on your needs and your expected usage scenarios.

Hope that helps. :)

Answer 2

hi

we've had the same conundrum and New in Town has basically given the options.

why we went with the resx option, mainly is because in most cases, especially websites, all that needs to change is the static content, i.e. labels, UI elements. if you're working with VS, once you create a page, there is an option to create the resx files for you. This is found in the Generate Local Resource in the Tools options. This will pick up all elements that HAVE ids (this is important), and generate the first resx file for you. creating copies of that for different languages is pretty simple after that.

changing the language is as simple as changing your web.config. example

<globalization enableClientBasedCulture="true" culture="ar-EG" uiCulture="ar-EG"/>

hope that helps