DEV Community

Eric Ahnell
Eric Ahnell

Posted on

DEV Questions 4: L10N and I18N gotchas

Post 4 in an ongoing series...

Localization (L10N for short) and Internationalization (I18N) are tricky to get right. Most developers who have done this know about text encoding, length differences affecting layout, and externalizing text. However, this is not enough... as with these three approaches alone, some languages cannot be supported properly.

One common source of trouble is "dynamic" text - such as the English string "You have 2 items in your shopping cart". Clearly the 2 will need to be modified at runtime. However, not all languages use the singular or plural, that's it model English does. The most complex model I am aware of uses FIVE forms: None, one, few, some, and many are all treated differently. (Note that English does not distinguish between none, few, some, or many, treating them all as "plural".) This implies that "items" in the string above must be parameterized as well, and mapped to the language's plural rules - which, thankfully, Unicode has defined for us.

Another thing that can lead to problems is differing word order between languages. For strings without any variables, this is easy enough to handle, but in the "dynamic" case mentioned above, the locations of the placeholders will have to be moved for the languages requiring it.

Finally, there's the thorny subject of idioms... these almost never translate well into other languages. There are several ways to handle this: Remove all idioms from the "fallback/base" text before translating, or separate the "default" text from the "fallback/base" text that gets translated, taking idioms out of the second but leaving them in the first. Which approach to use depends on how important the idioms are for context in the original language, which will of course vary by use case.

One more thing... in the event your code displays anything that varies by locale, such as dates, times, and currencies, those too must be adjusted to suit local expectations. It is FAR too easy to overlook these concerns, create low-effort translations, and have your application fare poorly outside its original market, due to lack of understanding. Don't be tempted!

Now for you: What has made translation easy / hard for you and your code?

Top comments (0)