Localization for writers and designers

The craft of localizing and translating software is a complex orchestration of people, processes and technologies. Anyone designing and building products for multiple languages should have a good appreciation and understanding of how localization works.

For many writers and designers, localization and translation is shrouded in mystery. Localization teams are often separated from design teams which limits collaboration. Unlike design, localization is generally treated as a cost center which means it’s primarily driven by optimization concerns for a certain output (words translated) per resource (time and money).

After having spoken to many writers, translators and engineers, we wanted to share our learnings how translation usually works at companies, some common challenges and best practices. This is a complex topic with many layers, so please treat this as a starting point for those new to the topic and we hope it helps to start a conversation within your organizations. It's also worth highlighting that this article is mostly focused on translation which is just one aspect of localization.

Translation workflow

The starting point for any translation flow is usually the creation of new content. This could be an update to an existing feature or a completely new feature. The new design is handed over to the engineering team which starts building the UI and creates the new strings in code. The basic steps of translation management look like this:

Basic translation flow

This seems simple enough on the surface, but there are many challenges that arise in day-to-day operations of a translation workflow. Here are a few common problems:

Problem #1: Deciding when to translate

Once the new strings are in code, translators could start translating. However, often those strings aren’t final. The designs are still being tweaked or - worst case - lorem ipsum is used in code as a placeholder. Translating draft strings is costly and leads to a lot of frustration for everyone involved.

Best practice: Create an approval flow that clearly marks strings as final for translation.

Problem #2: Managing translators across many languages

This is a really complex problem and its complexity increases with each language that is added to a product. Computer translations are imperfect and humans are an important part of any translation flow. Most of the time translators are contractors hired by a translation agency. So your localization team has to manage an agency and the agency normally has their own project managers supervising their translators.

Best practice: Have experienced professionals who manage your translation process and who find great translators or agencies.

Problem #3: Ignoring the length and sentence structure of other languages

Your localization experience is incomplete if you haven’t seen German blow up your UI. Plan for  additional space to accommodate “longer” languages (a good rule of thumb is 30% extra space from English to other languages). But it’s not just as simple as that. Other languages also have different sentence structures which means you might have to move dynamic variables around or even restructure your content.

Best practice: Writers and designers should have a good appreciation for translation concerns. Spend time with your localization teams early in the process so they can highlight areas of concern in your designs and propose solutions.

Problem #4: Finding the right technologies

There is a huge range of translation management systems (TMS) out there that are used to manage translation processes. TMSs are the connector between your localization team and your translators. Translators are assigned to certain strings for a given language, translation progress is tracked and quality is managed. The final translation is then fed back into a database for the engineering team to pull into the product. Larger companies might build custom solutions to host language string files, others use their version control system (eg GitHub) or a TMS/CMS for string hosting.

Best practice: Do an extensive vendor evaluation process to find the right TMS for your needs. Having experienced engineering and localization teams are hugely valuable in finding the right setup.

Problem #5: Context is missing for translators

Since most translators are far removed from the designers who write the primary language copy, they lack context of what they are translating. Not seeing the strings in the context of the designs can lead to bad outcomes. Additionally, there might be local constraints (eg legal and regulatory) that require specific treatment in the native language that do not apply in other languages. Passing on notes and the visual context of copy is often difficult since everything goes through engineering first (where the context is often stripped away since everything is stored in simple key-value pairs in the string files).

Best practice: Some teams use commenting that is added to code files to add written context. Some TMSs allow for manual upload of screenshots which is helpful but tedious. Overall, this is a problem that many teams still struggle with and better tools can help solve. We at Strings have some new features in the works that will address this gap.

Overall, localization and translation is a fascinating and complex topic that will continue to grow in importance as software is distributed globally faster. Design, product and engineering teams should have a good understanding of how localization works and should avoid throwing it over the wall assuming the localization team takes care of it.

We are very interested in this topic as we think there is a lot to improve in the workflow between content design, engineering and localization. If you’re interested in chatting to us about your ideas and thoughts on this topic, please reach out any time (email: contact at strings.design).

Try Strings

Strings is a writer-friendly tool for editing an app’s string files.

Start for free