The web is a global communication medium, and yet very few startups (and surprisingly few established companies), have a strategy for going global. Until just a few years ago, going global was something only the world’s largest and richest companies could afford to do. It meant opening overseas offices, developing new sales and distribution channels, all things beyond the reach of any startup. Today, users from any corner of the world can find you and your service, and if they like it, recommend it to friends. This article describes a short list of simple and inexpensive things you can do in the early days to prepare your company and products for global use.
This article explains some of the things to do before you even consider launching your product in other languages. Most companies only begin looking for translation services after a requirement has been forced upon them, which usually leads to bad outcomes. There are a few simple things you can do early on in your company’s development to position yourself so that when you need to go multilingual, you can easily make the transition.
#1 : Use Localization Tools Early On
Localization tools streamline the process of making an application or web service multilingual (e.g. translating menus, prompts, error messages, etc). Even if you don’t plan to launch your application in other languages, you should build it from the first version as if you do. Localization tools can help you in other ways, for example, by enabling designers and product managers to manage your applications messages without touching source code.
You’ll need two different tools to do this. One is a localization module for your preferred programming environment (gettext is a popular open source localization tool that’s available for most programming languages). This module takes care of merging texts into your application from separately maintained prompt catalogs (you’re not hard coding application prompts in source code, are you?). The second tool you’ll need is a localization management tool. Transifex, which we’ve reviewed here, is an especially interesting tool for software developers. It’s sort of like Github for localization, and makes the process of curating your project’s messages and other assets easy.
#2 : Localize Your App In British English
Before attempting to translate your application to a different language, a good place to start is by localizing it from American to British English (we’re assuming your starting off in American English as a tech startup). In the process of doing this, you’ll walk through all of the steps required to successfully localize your application into other languages, but without the risk of publishing a poorly translated version of your service. This is also smart business. The English speaking world is huge, and many English speakers find British English more agreeable.
In the course of doing this, you’ll walk yourself through the key steps in localizing an app or service:
- Create and maintain centrally managed prompt files in a localization management tool like Transifex.
- Create “mirror” prompt files in the target language (British English)
- Have junior translators “translate” the American English prompts into British form
- Have trusted reviewers review and post-edit the British “translations” prior to acceptance
- Update your application to correctly display dates, times, units of measure, currencies, etc (this is referred to as internationalization, most app development frameworks have built-in tools for managing common internationalization and formatting tasks).
- Figure out your CMS’s language support features (and bugs), creating paths or subdomains for translated versions (e.g. yoursite.co.uk, en-gb.yoursite.com).
This may seem a bit silly, but its a low-risk way to bootstrap your organization’s localization capability. Since British and American English differ only in style, and are easily readable to any English speaker, the risk of a comically bad translation slipping through is basically nil. The main point of the exercise is to learn and rehearse the translation and localization process before jumping into more difficult projects (i.e. launching in a language few of your people speak).
#3 : Recruit Bilingual Employees and Customers
Outsourcing translation to third parties is risky, because translation agencies rarely understand your product as well as you and your users do. A better approach is to build your own translation capability, especially for the most visible parts of your application, yet few companies do this. This is as simple as making language skills part of your recruitment process, and inviting users to join your future translation community. If you anticipate that Latin America will be an interesting market for you, make an effort to recruit Spanish and Portuguese speakers early on. As a small startup, you probably won’t find enough people to do all of your translation for you, and will need the help of outside vendors, but what you want to do is to find a few really skilled people who can review the work of others, rank outsourced vendors, and so on. These people will form the core of your future localization and project management teams.
Next Steps
The next step, of course, will be to translate and launch your product in other languages, but the point of this article is “walk before you run”. Most companies only think about translation and localization after a requirement has been forced upon them. By then, one or two years of bad habits are already baked into their source code, and they’re forced to find help in a hurry. This usually leads to a bad outcome.
To recap the main points of this explainer:
- When coding your application, assume it will be maintained in many languages. Use gettext, or the preferred localization module for your programming language, even if you’re only managing prompts in one language.
- Manage your prompts, error message and other assets separately from application source code, and use a localization management tool to manage these resources. Transifex is an inexpensive hosted solution that’s worth a look.
- Before attempting to localize your product in a foreign language, do a dry run by localizing it in a different regional form of your primary language.
- Start recruiting bilingual staff, users and peers from day one. Keep an inventory of language skills in your network.
If you follow these three steps early on, you’ll set yourself up so that when you see a surge in demand from a new region, you have the technical systems, people and processes in place to respond to this efficiently and quickly. Most companies I talk to think about translation and localization as an after thought, and only deal with it when demand dictates they do something about it, which usually leads to bad outcomes. The important point is that you can set up systems and processes at very little cost early on so that when you need to take the next step, your systems and your team are already prepared to go global.
Pingback: Tutorial : Prioritizing Which Languages To Support | Translation Reports