When you publish a web application, it’s instantly available to a global user base (unless, of course, you bar certain regions from accessing it). This means that if you want your application to be functional everywhere, you need to ensure that it’s properly internationalized, and then localized for specific target regions.
By definition, internationalization is the technical process of preparing an application for use in a range of locales without the need for subsequent engineering changes. Localization is adapting an application for a specific locale by adding locale-specific components and translating the text. The two terms are often abbreviated to i18n (internationalization) and L10n (localization). Here is an overview of some of the issues to bear in mind when internationalizing a web application.
Why internationalize?
One of the main reasons for making sure you internationalize your web application is to protect your intellectual property. If you don't internationalize your web app and it then goes on to become a roaring success, the chances are someone else well 'internationalize' it for you by creating a clone.
Famous examples of this are the many Facebook clones that sprang up before localized versions of the site were officially released. Two of the biggest are Russia's Vkontakte and China's Renren. If your application is properly internationalized, it is more likely that a localized version will be adopted in new territories, rather than developers in that territory deciding to build a clone. Once you have internationalized your application, you can do the localization work yourself, or, as often happens with open-source projects, draw on the expertise of the user community to do it for you.
The basics of internationalization
There are specific engineering processes that are required for internationalizing an application, most of which are unique to the development platform you are using. However, there are many universal first principles in internationalization, some of which we will examine here.
You should clearly establish your ‘base language’ as early into the project as possible. This is particularly important if you have a multilingual development team. The base language will probably be the default when translations are missing and it is what the translators will be working from, so it’s important to get it right.
Make sure that you use clear language, avoiding abbreviations, slang and jargon. All of your messages, ‘readme’ files, UI elements etc. should be written using plain and concise language. This will not only increase the usability of your application, but will be a big help when the app is localized. You can maintain good quality writing by creating a ‘style guide’, which lays down the rules and conventions for all written parts of the app. If your base language is English, decide whether you will be using US or UK spelling.
Remember that when text is translated it will usually take up a different amount of space. For example, a paragraph in English will usually require more space when it is translated into German. This means that you should allow enough space for translated text when you are designing text areas, form input boxes, menu items, buttons, and the like. Where possible, avoid static sizing and if there are areas that require strings of a fixed size, include a comment for translators so they know the maximum length for their translated text.
Adapting for cultural and practical differences
Internationalization is not just about language differences. There are other cultural and practical differences that will affect the way users interact with your app. For example, registration forms need to be flexible enough to allow for the subtle regional differences in street addresses, zip codes and phone numbers. Date formats, currencies and weights and measures all vary, even between regions that speak the same language. Wherever possible, use system settings and functions to handle these types of regional data – if your form is set to only recognise phone numbers as being of a certain number of digits, for example, then your form will be inaccessible to large parts of the world.
In these instances, it’s useful to have an outline of each of the markets you intend the app for, to ensure that you have either an option available to address each different format for personal details/currency/etc., and also to address cultural differences, such as in aesthetics and business process logic.
Using hard-coded images, icons and colours without proper consideration can cause problems for internationalization. Text in images is a big no-no because new versions of the images will have to be created each time the app is localized. Ensure that any icons you use are completely unambiguous and have a universal meaning. For example, using a ‘thumbs-up’ icon to mean ‘OK’ may be fine for most Western countries, but in some parts of the world a ‘thumbs-up’ gesture is incredibly offensive. In the same way, don’t take colours for granted. If you are using colour to convey meaning, check that it will be understood all over the world. Red can symbolize war, but it can also mean love and passion, while green may be either a holy colour, or signify the environment.
Lastly, avoid concatenating strings because this can make translation very difficult or even impossible. A better approach would be to use named variables which can be easily moved around and substituted. When sorting data, remember that not all alphabets begin with ‘A’ and end with ‘Z’. In fact, some languages don’t even use the concept of an alphabet – it’s better to try to have the database perform sorting for you, whenever possible.
Conclusion
As you can see, internationalizing a software application is not a quick and simple process – it involves re-assessing every aspect of the application to make sure that it is not regionally or culturally specific, and that it is suitably flexible to be accessible by pretty much anyone in the world. Once you have your software app internationalized, the next step towards achieving full global functionality is to have it localized for each individual target market. For instance, in the US version, to have the address format set for the US, with the US states in the State drop-down menu, while the UK version would have the relevant counties, districts and cities in the drop down, amongst other region-specific touches. The topic of localization, though, is one for another article.
About the author
Christian Arno is the founder and Managing Director of global translation company Lingo24. Launched in 2001, Lingo24 now has over 130 employees spanning four continents and clients in over sixty countries.
Contact Lingo24 with a translation or localized marketing request mentioning Developer Fusion before 30 February 2011 and receive a 10% discount on your first order.
Comments