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:
ember install ember-i18nThen I added a couple of locales with that nice generator the package provides.
ember generate locale en-nzember generate locale en-auThose 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:
export default {
'terms.disclaimer': '',
'terms.jurisdiction': 'These Terms of Use are a legal agreement. They are governed by the laws of New Zealand, and You submit to the exclusive jurisdiction of the New Zealand courts for any matter or dispute arising in relation to these Terms.'
}And for the Australia version app/locales/en-au/translations.js:
export default {
'terms.disclaimer': 'Please note that these terms and conditions are from New Zealand and are being reviewed for use in Australia.',
'terms.jurisdiction': 'These Terms of Use are a legal agreement.'
}And here is an example of using one of those translations in the template terms.hbs:
<div class="legal">
<h1>Terms of Use</h1>
<p>{{t 'terms.disclaimer'}}</p>
...So now, when an Australian user views the terms page, that user will see this HTML:
<div class="legal">
<h1>Terms of Use</h1>
<p>Please note that these terms and conditions are from New Zealand
and are being reviewed for use in Australia.
...And the New Zealand users will see this HTML:
<div class="legal">
<h1>Terms of Use</h1>
<p></p>
...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.
