So, you have built this great software and it’s becoming successful in the US market. User adoption picked up, clients are gradually flowing in, and you’ve come up with a plan to expand to international markets. Yes, it’s the right move to go global! You’re thinking “all I need is to translate my software into a bunch of languages, and I’m going to be successful internationally”. What is more, there are numerous agencies offering to translate your product fast and at a low price. Unfortunately, two months later and with $30k less in your budget, you’re looking at an ugly, malformed UI of your product in German/Japanese/Spanish (you name it), spotted with untranslated text strings, and your bi-lingual colleagues tell you most of the translations are ridiculously wrong. You can’t go global with this thing…
So what went wrong?
Going global the naive way
Yes, everything went wrong. Literally everything.
Going global can be very expensive if you take shortcuts. It will cost you wasted time, money, and resources. Plus frustration of your teams, not to mention prospective clients, if you’ve already signed them up for international release “coming soon”. But if done right from the beginning, internationalizing your software is really a one-off effort. Yes, it does span most of your teams (Engineering, Product, Operations, Marketing), but once you’re done, you’re done – Localization can be built into continuous deployment just like many other engineering processes – e.g. testing, bug fixing, code review, etc.. And yes, successful globalization effort does not have to involve slower release cycles, costly bug fixing or high price tags for translation. If planned well, with proper guidance for all your teams, with automated solutions, careful choice of translation model, and robust set-up of Quality Assurance, the entire go-global effort can be yet another large “feature” you’re about to ship with the next release.
So what’s the secret sauce?
First, get used to the idea the go-global process is not a translation task. The actual translation constitutes 10% of what needs to be done, and it’s relatively simple if you select the right translation agency, train translators on your product, and give them guidance on desired terminology and style for each market. A smart PM can prep this easily.
The bulk of the go-global effort is to internationalize codebase of your software, i.e. make it ready for translation. Or, in engineer’s terms, extract text strings from code, use Unicode i18n libraries to handle culturally-sensitive data like date format, alphabetical sorting, pluralized nouns, etc. and build basic localization architecture for your product. For example, your databases, APIs, or core features likely require some adjustments to handle multilingual content. Here is an example of poor international user experience if you don’t do it:
Example of poorly localized UI without proper internationalization work.
Another important part of going global is training your people. And I don’t mean that one person you’ve selected to be your Localization Project Manager, but rather the entire engineering team, all Product Managers, all Designers, and even your Customer Success teams, if they’re supposed to handle international clients. Your engineers need to be on the same page, what is required when creating a translatable text string, how to use i18n libraries, or how to pass language parameters when making calls between APIs. Your PMs may need a workshop to be more aware of internationally-sensitive aspects of software development, like for example the use of colors, symbols, acronyms, references to national holidays, use of humor, jargon, or simply different behavior patterns in users across global markets. Similarly, your Designers must become more sensitive to what happens with the UI when you send it for translation. On average, translations are going to be 30-50% longer than the English UI text, but some very short UI strings may need up to 200% more UI space to fit after translation! Asian languages pose their challenges, too, with legibility of fonts or character truncation.
Most of such pitfalls can be easily avoided well before a final QA check, if your teams have had the right training and access to handy i18n (internationalization) guides.
Last but not least, you want to bake Localization into your standard development cycle, so it becomes yet another process running smoothly in the background rather than a blocker for your engineering teams. A well-designed Continuous Localization process does not slow you down and requires zero manual effort from your engineers! As new features are being coded, translation happens “automatically” (well, at least for the engineers). As soon as new text strings are detected in repository, they are sent to your trusted translators, and return translated typically within 24hrs, ready for your engineers to build a release candidate. Such set-up reduces operational costs of going global and allows for super fast expansion into new languages.
Usually dreaded by engineers, software localization can be a very rewarding project for all your teams. It just takes a bit more understanding of what’s involved in the effort and how to do it right. Think of it as the next big product feature touching all corners of your software. If done right, you tap into new markets and jump ahead of your (English-only) competitors.