Best Practices for writing software to be consumed internationally (i18n)

Question

I am looking for opinions from experts that have written software consumed internationally. I would like to understand the best practices people have employeed at each logic

Answer 1

You could write a book about this subject.

At all layers, don't make assumptions about:

• text width
• text directionality
• tokenization of natural language
• currency (format, decimal precision, taxation, etc.)
• grammar and spelling
• alphabets
• number systems and formatting
• sort order
• dates, times, time zones and calendars
• social conventions or cultural references (icons, flags, etc.)
• searching
• capitalization
• addresses
• proper names (firstname/lastname etc.)
• telephone numbers
• legal/regulatory requirements
• usage of social security numbers or other local conventions

I'm sure I'm only scratching the surface.

Answer 2

Make sure that there is plenty of spare room in UI controls. Text has a tendency to become a lot longer when translated from English to something like French or German.

Although it is focused somewhat on the Windows side of i18n things, pay attention to Michael Kaplan's blog. He is very well versed in this field, and has posted many blogs posts containing general stuff that's useful.

Answer 3

Data

• When you go to UTF-8, be prepared for characters to take up to 3 bytes each (in the case of Chinese), which means that VARCHAR(20) now needs to be a VARCHAR(60).
• Unless you really have a good reason to do it, for the love of god, don't store your UI translations in the DB.

Business

• Spend a lot of time on requirements. As a starting point, take a screenshot of every single screen in your app, put it in a document, and start drawing boxes around things that need i18n support. Then map each of those boxes to an area of code that needs to change.

UI

Don’t

string foo = "Page " + currentPage + " of " + totalPages;

Do

string foo = string.Format("Page {0} of {1}", currentPage, totalPages);

Why? Word Order Matters.

<value>Page {0} of {1}</value>
 <value>{1}ページ中の第{0}ページ</value>

Nothing is sacred in the UI Even something as fundamental as showing green for positive numbers and red for negative numbers is fair game.

Answer 4

For localisation, do not hardcode UI strings. Use something like gettext.

Answer 5

If you're using .Net, The Resource files (.resx) system is very flexible.

Look up usages of ResourceManager.GetString("string name", CultureInfo).

We use this system to flip between English, German, French, Spanish, Russian and Arabic quite successfully.

Also when considering usage in foreign locales, spend some time looking at Input as well as output; the Turkish problem is a good example of how different inputs can cause problems.

Answer 6

Unicode (or wchar, or whatever its equivalent in <language of choice> is) everywhere. Don't store labels in the database. Be prepared to allow text and controls to go "the wrong way", i.e. right-to-left.