For the last couple of years, the majority of sites we have built have been marketing to a global audience, which means we have taken on the challenges of displaying the site in an appropriate language (‘internationalisation’ or ‘i18n’) and often modifying the content for various countries and regions (‘localisation’ or ‘L10n’).One of the biggest challenges though is to get all parties involved in a project to appreciate the difference between ‘language’ and ‘locale’, and things can often become quite complex very quickly. For instance, whilst it might be a reasonable to assume that a visitor viewing the site in Japanese might be in Japan, and that conversely visitors in Japan are likely to be viewing a site in Japanese, it’s not safe to make the assumption that visitors viewing a site in French are all in France – they might equally be in Switzerland or Canada for instance which both have significant French speaking populations – and it follows that if you want to deliver specific content to Canadian visitors then knowing their language is not very helpful as it could be either French or English, or a multitude of others.Of course that’s simplifying many of the issues – we also have to consider regional dialects and other variations – a significant one being the difference between ‘British’ English and ‘American’ English – not only the different spelling of ‘colour’ / ‘color’ (or ‘localisation’ / ‘localization’) but also different date formats (9/11/01 in the UK is 9th November not September 11th), and different preferences for units of measurement (metres / feet, kg. / lb. etc.) for example. Whilst it is relatively straightforward to apply translations of a site into different languages, right from the initial planning of a multilingual or globalised website decisions have to be made about how the site behaviour and content will be required to vary for visitors with various combinations of locale and language – this can then be built into the application logic and content plan.

• Make sure everyone involved in the project understands the difference between language and locale
• Plan how language and locale differences will affect things from the start – factor this into visual designs, technical architecture and the content plan
• Decide how you’re going to deliver the right language / locale to the user – and allow the user to influence which variant he / she gets
• Get the site built and tested in English (or your default language of choice) first before going out for translation – any changes to the base content will have much larger implications afterwards.
• Be methodical in your documentation and processing of translations, use the right tools and good version control and file naming conventions
• Use a rigorous and comprehensive testing regime, and ensure any changes to the site’s core content is reflected in the translations.