In Berlin in the spring of 2011, my colleague Wolfram and I were working as CTO and VP of engineering, respectively, at a newly formed startup. We were finishing the first lines of code for an apartment-booking site prototype. Our investor urged that our prototype be available in 24 languages from the get-go. His request threw us into a process—localization—that we had no clue how to navigate.
At the time, our newly formed team was just coming together. We were ambitious but naïve. We didn’t know how to build and ship a minimum viable product to two dozen markets at the same time. The experience was thrilling but we were also curious whether we could sustain the pressure of a big project with a large investment. But working on a quickly growing and highly international product triggered our interest in localization and eventually led us to build our own localization platform, PhraseApp.
Don’t do what we did
As we began to translate the booking platform, we worked with translation pros and amateurs, our country managers, and other bilingual and multilingual individuals. (Now, we often encounter this type of setting in startups, where teams utilize immediately available resources to their fullest potential.) At the time, we kicked off internationalizing our application by extracting copy into locale files, copying the copy into spreadsheets, emailing them to our translators, and then … waiting. And waiting some more. As the first translations came back (sent as individual spreadsheets), we compiled all translations back into individual locale files for each language.
The resulting translations were far from great. It wasn’t because our translators weren’t skilled or trying hard enough: They had no context on the bits of text they were translating. They also had no idea how the text would appear in the final product, where it was used, or how it connected to our software’s user interface. Because spreadsheets were all we sent them, they weren’t set up for success.
We considered what could yield better results. Could we give our translators direct access to our product so that they could edit copy within the application? We could, so we did: building a prototype that allowed in-context editing. At the core, we wanted localization to happen as close to our product development process as possible. We also wanted to integrate translator workflows into our software release process rather than integrating our product into any localization provider tooling.
Since that Berlin spring almost a decade ago, we’ve learned from thousands of companies and thousands of software localization processes to build our localization platform SaaS. Here’s what we’ve learned so far.
Determine if your localization process works
What we experienced in Berlin is common to software companies starting localization. Sooner or later the work becomes so complicated—due to the number of stakeholders, remoteness of team members, time constraints, and so on—that the initial process in place no longer works. Typical indicators of a broken localization process are a high percentage of translation loops, long wait times before a finished feature can be released across markets, and translation quality issues that can be felt by your users.
Understand your translators
Although there are magnificent examples of specialist translation providers for software creators, for most translation companies (also called language service providers) software localization is only a minor part of their business. Their main focus is on content-heavy documents and larger texts.
Working with software creators means having to deal with tiny increments of text, as well as quality and speed requirements that lead to increased switching costs between projects and customers.
Product teams and developers owe translators input on the context of the copy they’re translating. Only when our intentions and requirements are clear can we expect good translation results. This includes providing information on tone and style, as well as— possibly—a glossary of brand terminology, screenshots, and access to your product.
Better briefings decrease turnaround time and rework in translation processes. An ideal setting includes linguistic supervision within your company or even product team, though this may be less feasible when your team is small. An alternative can be a specialized localization provider with experience in software product localization who can cater to your delivery requirements.
Make localization a core part of the development process
Kicking off content creation and localization early in the process enables you to keep your copy in sync with feature progress and allows for earlier incremental releases. Many of our customers’ teams use the same project management tools and ticketing systems for feature development and localization alike, such as Kanban boards or added development stages for finalizing localization.
Treat localization as a priority in your product development process. Besides the textual translation, it may impact your feature and communication design. Plan with its impact in mind.
Save strings but protect the source
In the beginning, make sure that you extract all hard-coded strings from your source code into your framework’s language file. Start with your templates—this also includes error messages and maybe even used values for different attributes within your business logic. For search engine optimization, localized routing is also a viable concern. While there are open-source tools to extract strings for the most popular templating languages and platforms, you should think about a system to make your language files accessible for translation. Giving your translators direct access to your source code is not a good idea. (What can go wrong, will go wrong.)
Keep sentences simple
Recently a customer asked me for advice on which localization library or format they should use and how they could utilize ICU MessageFormat best. My advice was and is: Keep it simple. Utilizing message formats to their max can lead to having business logic inside your translator copy. It turns your strings into tiny templates that potentially mix business logic and view concerns, which can be awkward for your translators as they need to learn how to handle it. Reducing the amount of pluralization and syntax within your strings makes your life easier. Modern localization management systems generally allow you to share language data across multiple platforms, e.g., serving the same content for iOS and Android.
Keep paragraphs together and aim to not split sentences apart. This automatically offers translators a little more context. Keep in mind that sentence density and length vary greatly between languages. While English sentences tend to be concise, in German an author expressing the same content may extend a sentence using subclauses and provide ever more words to describe the same circumstances in a more elaborate manner.
Prepare for time, currency, and length differences
Besides the mere translation of text, localization often requires that your application handle different time zones and currency formats. This is a design concern that needs to be recognized early on. Consider everything from the choice of character encoding in your database to the modeling of monetary values inside your business logic. Luckily, most software frameworks come with helpful libraries for this purpose.
Last but not least, your design needs to anticipate different content lengths for different languages’ specific typefaces. Google’s excellent Android localization guide advises using a flexible layout allowing for different text and character lengths. We usually suggest leaving 20 percent in stretch room for texts. Pseudolocalization, randomly generated text that uses a language’s script and typical word length distribution, like Lorem Ipsum, is a good mechanism for providing your designers with an idea of how a specific language’s script will look within a given layout. They can adapt to this without the need for the finalized translated content.
Use machine translation where appropriate
Although it’s more fluent and readable than it’s ever been, most machine translation still lacks contextual precision, domain specificities, and the brand voice of a well-instructed human translator.
Utilize machine translation where it’s most strong: to increase language exposure and accessibility, such as for large bodies of content, real-time use cases, prototyping, and user-generated content. Most professional product teams, however, do better when they rely on specialized human translators. They can quickly pick up on contextual requirements and brand voice. A well-managed team can return localizations without long delays.
Localization is hard but not np hard
Due to the availability of global platforms such as the App Store and Google Play, localization has become a viable option for software developers even in the early stages of their product development. Modern web frameworks and their built-in support for internationalization have contributed to the accessibility of localization as well.
However, brilliant localization has to comprise more than just content that’s contextually and technically correct. It’s about understanding your product’s markets across the globe and the cultural differences within your audience. It never stops. Every new language and local market you approach adds new facets to your product design requirements.