What to remember about when adding other languages to your website

So you want to go international with your website, huh? In this post I'll try to summarize all the possible changes that you will have to go through. The complexity of this upgrade will obviously depend on the current design, framework you use etc. The sooner you start thinking about it the better, as this will save you some mundune work in future.

Unfortunetally translating your website is not always as easy as creating an alternative language file. I've learned that recently while translating my Polish project www.DziennikLotow.pl into an English version www.MySkyMap.com.

The checklist below may help you to remember about some important tasks that need to be completed as part of translation process:

Domain name

Before you introduce a new language you have to think if you need a new domain as well. You will probably get away with a single domain in case it's one of the common, worldwide recognized domains, like .com, .net etc. In that case you still need to define your strategy for serving translated content for users accessing your website for the first time. There are several options here:

• Default language
  Until visitors chooses to change their language you serve the content using a default one e.g. English
• Browser settings
  You can check the default browser language set by the user and serve translated content basing on that (if available)
• Language specific url
  When advertising your website you can use links that have the language defined as part of the url e.g. http://www.yourdomain.com/en/ or using subdomains e.g. http://www.en.yourdomain.com

Once the user selects the language manually or logs in you have more options e.g. storing preferred language in user session, passing additional url params etc.

In the situation when you have a country specific domain (like .pl) and you would like to expand, it is probaly better to register a domain with a common ending (like .com) for the new language version. You can then determine the language to use depending on the domain name. The small disadvantage of this approach is that it may not be possible to change website language without loosing session data, unless you have some CDSSO (Cross-Domain Single Sign On) implemented.

Alternativelly after registering a global domain you can abandon the local one (or make it redirect to global) and then use mechanisms described above.

Static texts

Translating the text content is usually the first part that you think about when starting to add support for a new language. This covers not only text blocks, but also things like navigation menus, alerts, image alternative texts, page meta information (keywords, desc, etc) and many more. Everything that is a part of a HTML response and is language-specific should get transleted.

Most of the modern web applications frameworks support creating different language versions out-of-the-box (OOTB). However, it is developer`s responsibility to make use of the internationalization (I18N) functionality offered by the engine they use. This has to be thought about from the very begining, so you don't end up with string that need to be translted hard-coded in your application.

The most common way of achieving I18N is to create separate files for each language, that contain all possible static text content that can be displayed by your website. Each file usually contains text messages that can be identified by a uniqe key. For example, this is how simple language files for English & Polish languages could look like:

ThankYou = Thank you
Goodbye = Goodbye
Please = Please

ThankYou = Dziękuję
Goodbye = Do widzenia
Please = Proszę

Note that the same keys are used to identify the messeges in both files.

As a popular alternative you could store all messages that require translation in a databse. See my other post on that. I believe this appraoch is more complex than language files, and therefore I only use if it's really required.

Warning: Javascript - if you reference any static javascript files that include some messages that need to be translated you will have troubles using default I18N mechanism in most of the frameworks. One possible solution is to serve those files dynamically and injecting the translted messages before returning the server response with javascript content. You will find more alternatives on the Web.

Graphics

In general, it is not a good practice to present any text content using graphics. It is because graphics take more time to load than a regular text and require additional HTTP requests (they can be cached but still). Good graphic designers remember about that when creating their desings. However, it still may happen that graphics on your website present some text e.g. logo, fancy menu etc.

If your website contains any graphics presenting language specific texts you will need to create alternative versions for each language. You will also need to create mechanism for displaying them depending on the current language. That part can be easily achieved with the language files used for static text content.

Data formats

When creating a localized version of a website content you should also care about data formats used in the country you are preparing content for. Common elements that can be presented using different formats depending on the country are numbers, date & time, money amounts etc.

Updates

Nowadays most of the popular websites share some updates with their users on a regular basis. Most of them has its "News" or "Blog" sections, so does probably yours. When you add a new language support to your website, it is important to choose your strategy. Basically you have 2 main options:

• Default language only
  If you assume that a vast majority of your users either uses the default language or at least understands it you can write all the updates in it e.g. in English
• Language specific updates
  If you can afford the time required to translate all your updates it will be always appriciated by your users if you create different language versions for each update. However, don't use automatic translation because this may have exact opposite result. Again, most of the frameworks used for posting content (e.g. Wordpress) support serving multiple language versions.

Changing language

When adding support for multiple languages you will obviously need a widget for changing the language. There are plenty of types (with flags, with language names etc). The widget is usually placed in the top right corner of your page. Altghough some types looks 'cooler' you have to rememebr about accesibility. In most cases simple solutions are the best ones.

Remember that except the UI part the widget will need to work with your language selection mechanism on the server side.

Other stuff...

The aspects of i18n described above are the most basic ones and apply in most cases. Except those, there are also challenges more specific to you website. In my case these were:

• Rewriting Urls
  Since I have a different domain for a new langauge I needed to add url rewriting rules to .htaccess file, so the website works ok for the new domain.
• Emails
  I had to translate existing email templates.
• Facebook Connect
  When configuring Facebook connect you provide app Id. That app is specific to a single domain, so I neede to create a separat facebook app for my new domain.
• Facebook Fanpage
  The same situation as described in "Updates" section i.e. do you want to have 2 separate fan pages and create a single one with content in the default language?
• Analytics
  I've setup a new google analytics site to separate stats coming from different domains.

As you can see the process of adding support for a new language may require much mroe work than it seems at the begining. I admit that I still have somethings to do, as I implemented only the most important changes.