i18n – Internationalisation: users are not just locals from your locale

So you’ve finally decided to launch outside of your own country (or locale) and presumably outside of your comfort zone. Unless your domain is very specific to your locale this should have been on the radar from day one. But let’s face it who wants to think about launching elsewhere when you’re deep down in the guts of what makes your application great! That’s why you put it off until absolutely necessary. Truthfully, that’s probably a good decision. No use in wasting time on something that may never be an issue. But once you’ve got “market penetration”, you will have users asking for these changes.

Internationalisation is not only important for different languages, but also different dialects. For example the en-GB (British English) locale would use “colour” and “neighbour” whereas the en-US (US English) locale would use “color” and “neighbor”. There are also differences like currency symbols: the British Pound £ (en-GB) or US Dollar $ (en-US). Number formatting can be different. Some countries use the comma to separate the thousands place and period to separate decimals while others use the opposite. Some languages read right to left like Arabic or Hebrew. This can be especially difficult to support because it usually means differences in the webpage CSS. Date and time formatting can be a pain in the derriere if the UI does not prominently display what format it is expecting. Using a New Zealand website? Then of course you have a day, month, and year order. In the US it would be month, day, and year…this can make for some inconvenient scheduling issues. Hopefully your dates are stored in UTC!

Displaying addresses and phone numbers have differences as well, but they normally only make for a minor annoyance to the user if they are displayed incorrectly for their locale. Make sure your validation isn’t too strict though! Ever try entering a non-US phone number into a US website? “You have entered an invalid phone number. Please try again”. UGH!

Units of measure may use the Imperial system if you are in the US or Metric if you are, well, pretty much anywhere else in the world. Ask anyone from NASA who was on the Mars Climate Orbiter project how important these differences can be. Translation isn’t just for languages my friends.

Wondering what your locale would be? Here are some examples of the most popular locales:

Language family Language tag Language variant
Bangla bn-BD Bangla (Bangladesh)
bn-IN Bangla (India)
Chinese zh-CN Mainland China, simplified characters
zh-TW Taiwan, traditional characters
zh-HK Hong Kong, traditional characters
Dutch nl-BE Belgian Dutch
nl-NL Standard Dutch (as spoken in The Netherlands)
English en-NZ New Zealand English
en-GB British English
en-US American English
en-CA Canadian English
en-IN Indian English
en-AU Australian English
French fr-BE Belgian French
fr-CH “Swiss” French
fr-FR Standard French (especially in France)
fr-CA Canadian French
German de-AT Austrian German
de-DE Standard German (as spoken in Germany)
de-CH “Swiss” German
Italian it-CH “Swiss” Italian
it-IT Standard Italian (as spoken in Italy)
Portuguese pt-PT European Portuguese (as written and spoken in Portugal)
pt-BR Brazilian Portuguese
Spanish es-ES Castilian Spanish (as spoken in Central-Northern Spain)
es-MX Mexican Spanish
es-AR Argentine Spanish
es-CO Colombian Spanish
es-CL Chilean Spanish
Tamil ta-IN Indian Tamil
ta-LK Sri Lankan Tamil

Other side-effects like time zones can be pulled in as well. Being in New Zealand we get the brunt of time zone issues because most of the modern world is well outside of our normal operating hours.

All of this can be important if you want your users to feel comfortable using your product/website. Having the ability to use an English version of a Costa Rican banking website when paying taxes or paying the electric bill can remove a lot of anxiety and extend one’s use of said website. Or, try changing the radio clock on a Japanese used car import, I dare you.

For the pedants out there, I made references to aspects of globalisation, internationalisation (i18n), localisation (L10n), and translation. All of which can be used interchangeably when speaking of such things in general, but please note they are not exact synonyms of each other.

Globalisation is the umbrella term for making a product/website locale-friendly and includes internationalisation, localisation, and translation within it. Internationalisation involves planning and preparing your product/website by removing all locale-specific hard-coded (meaning static or non-dynamic) references and content. Localisation is the process of adapting a product/website to a specific locale or set of locales by providing a configuration to support that locale. Translation is fairly obvious – translating the content to different languages or systems. Translation is part of the localisation configuration and usually does not include locale-specific differences like varying spellings of words, grammar, or currency matching.

Globalisation is an ongoing process, not a one time change. Make sure you keep tabs on changes to the locales you support. I can’t imagine the headache caused by the state of Arizona in the US when they decided to no longer observe daylight saving time. I would guess many software firms had a hay day for that fiasco like they did when the whole Y2K thing happened, albeit on a much smaller scale.

And now for a real-world example! Within one of our applications, we needed to start supporting Australia, instead of just New Zealand. So, one of the places that needed localisation was in the terms page, aka “Ts and Cs”. We needed to have different text for each country. Since this application uses Ember.js for the front end I added the ember-i18n npm package to the project:

Then I added a couple of locales with that nice generator the package provides.

Those commands generate two files each: app/locales/en-nz/config.js and app/locales/en-nz/translations.js where “en-nz” is whatever locale you give as the last parameter to the command.

Nothing in the config.js file needed to be changed, but in the translations.js file I added a few lines:

And for the Australia version app/locales/en-au/translations.js:

And here is an example of using one of those translations in the template terms.hbs:

So now, when an Australian user views the terms page, that user will see this HTML:

And the New Zealand users will see this HTML:

You can tell I didn’t use localisation to do any actual translation, but it was necessary for the two locales to have different text displayed. I also use this localisation for determining whether to use the New Zealand Business Number API as a lookup (or not for AU) when adding companies to the application.  That is not the extent of internationalisation use by the application, just a couple of good examples.

I am looking forward to more internationalisation work as we begin to delve into the differences between New Zealand and Australia when it comes to the needs of our application users.