Question

I’m planning on developing software for the international market.

What architecture decisions should I consider other than just converting the text from one language to other?

Answer 1

There are a huge number of issues, depending on how far you are interested in going.

1. Numbers – both in thousands and decimal separators. In fact, not all locales use a separator every three digits. And the rules for writing out numbers as text, say for writing checks, vary considerably.
2. Currency and Measurements – not all currency has two digits of decimals. The sign can be leading or trailing. The indicator for negatives can be a sign, parentheses, or leading or trailing text (like “dr” and “cr” are sometimes used in US English). Similar issues for measurements (English vs. Metric vs. local).
3. Language script – it’s not always left-to-right, top-to-bottom. Unicode is a must. Also, text layout changes by language. The same text can be shorter or much longer when translated, which means forms must be flexible.
4. Literal strings vs. Translatable strings – some text is literal and won’t be translated; it’s helpful if you design for that up front and make sure translatable strings are handled consistently (via resources or whatever is available). You’ll also want to template strings like “abc {1} xyz” or “abc %1 xyz” for insertion text instead of doing “abc” + n + “xyz”, since the place that the inserted text goes will vary by sentence structure.
5. Date and time – Not every country uses the same calendar; some have different year counting systems. For some fun, dig through the java.util.Calendar or System.Globalization.Calendar classes sometime.
6. Icons and Colors – What looks like a grippy hand in one culture may be an offensive gesture in another. And colors have different meanings as well.

Internationalization (I18N) can be a big deal, but it’s not overwhelming. Pick your scope, and then dive in. Once you get the first couple of locales done, it gets easier. 🙂

Hope this helps.