Question

What are the steps to develop a multilingual web application?

Should i store the languages texts and resources in database or should i use property files or resource files?

I understand that I need to use CurrentCulture with C# alone with CultureFormat etc.

I wanted to know you opinions on steps to build a multilingual web application.

Doesn’t have to be language specific. I’m just looking for steps to build this.

Answer 1

The specific mechanisms are different depending on the platform you are developing on.

As a cursory set of work items:

1. Separation of code from content. Generally, resources are compiled into assemblies with the help of resource files (in dot net) or stored in property files (in java, though there are other options), or some other location, and referred to by ID. If you want localization costs to be reasonable, you need to avoid changes to the IDs between releases, as most localization tools will treat new IDs as new content.
2. Identification of areas in the application which make assumptions about the locale of the user, especially date/time, currency, number formatting or input.
3. Create some mechanism for locale-specific CSS content; not all fonts work for all languages, and not all font-sizes are sane for all languages. Don’t paint yourself into a corner of forcing Thai text to be displayed in 8 pt. Also, text directionality is going to be right-to-left for at least two languages.
4. Design your page content to reflow or resize reasonably when more or less content than you expect is present. Many languages expand 50-80% from English for short strings, and 30-40% for longer pieces of content (that’s a rough rule of thumb, not a law).
5. Identify cultural presumptions made by your UI designers, and try to make them more neutral, or, if you’ve got money and sanity to burn, localizable. Mailboxes don’t look the same everywhere, hand gestures aren’t universal, and something that’s cute or clever or relies on a visual pun won’t necessarily travel well.
6. Choose appropriate encodings for your supported languages. It’s now reasonable to use UTF-8 for all content that’s sent to web browsers, regardless of language.
7. Choose appropriate collation for your databases, or enable alternate collations, if you are dealing with content in multiple languages in your databases. Case-insensitivity works differently in many languages than it does in English, and accent insensitivity is acceptable in some languages and generally inappropriate in others.
8. Don’t assume words are delimited by spaces or that sentences are delimited by punctuation, if you’re trying to support search.

Avoid:

1. Storing localized content in databases, unless there’s a really, really, good reason. And then, think again. If you have content that is somewhat dynamic and representatives of each region need to customize it, it may be reasonable to store certain categories of content with an associated locale ID.
2. Trying to be clever with string concatenation. Also, try not to assume rules about pluralization or counting work the same for every culture. Make sure, at least, that the order of strings (and controls) can be specified with format strings that are typical your platform, or well documented in your localization kit if you elect to roll your own for some reason.
3. Presuming that it’s ok for code bugs to be fixed by localizers. That’s generally not reasonable, at least if you want to deliver your product within a reasonable time at a reasonable cost; it’s sometimes not even possible.