Traditionally, software product teams would first design the product with only one language, and start thinking about adding more translation keys only after development. This often sounds like common sense considering that software release deadlines are usually quite tight.
However, incorporating the localization process early in the design stage can help avoid costly rework down the line, ensuring that translations don’t impact your design negatively and keeping the overall process streamlined.
Smart and experienced teams design and develop a new product or application with internationalization in mind, even if localization is not planned for the foreseeable future, as it will save a lot of pain when the localization work finally begins.
Developer creates the translation keys and commits the code to the repository.
The source is supplied to PMs (Product Managers) / Localization Managers.
Managers pre-translate using existing resources, define the scope, and assign tasks.
Translators translate new/modified strings.
Reviewers / QA team revise the strings, proofread, and run QA checks to ensure quality.
The translated content is pulled to the repository by the developers.
However, even though this workflow enables you to automate many parts of your localization process (with the right localization software), this still doesn't fully save you from issues and delays down the road if the actual translations are planned to be added only after development.
Inevitable issues in the best practice l10n workflow
Translations impact your design
Different languages require different amounts of space in design. For example, translating from the English language into German can result in a 20-35% text expansion. Translating from English to Swedish can result in a 20-35% text contraction.
slack.com vs slack.com/intl/de-de/
Plus, if you want to include Korean, Japanese, Chinese, and other non-latin script languages, this can also result in vertical text expansion.
Furthermore, it’s important to remember that some languages (such as Hebrew and Arabic) are written from right to left. As you can imagine, this can, and most likely will, distort or break your design and lead to bugs.
Even more so, localization is not just about translating words, your design might not be suitable for other markets for cultural reasons, which can lead to low adoption.
Translators still won't have enough context
Your translators likely won't be going through your UI and trying to figure out where each content key is supposed to be placed, what its function is, and how it will look after translation. This becomes even more cumbersome if translators are not provided with any contextual information in relation to the translation and its intended purpose (like screenshots).
If this is not kept in mind, it will lead to translation and localization errors and a confusing experience for your multilingual customers.
Maintaining changes in development is always more difficult, slower, and expensive
The first two issues above are common localization challenges, and will always be present when designing and developing multilingual software products. However, if you work with translations only after development, you'll encounter two big challenges that could have been avoided or significantly reduced:
Whatever changes or fixes are needed, they will have to go through your engineering team who will either fix bugs or break new texts into keys, and sync with existing keys.
Your bugs and translation errors will be seen by real users.
This adds up and localization becomes unnecessarily expensive and time-consuming. In turn, this also slows down your releases to all markets resulting in lost opportunities (revenue from all your markets), as your team will be busy fixing existing errors and spending more time on LQA (Language quality assurance).
We calculated the associated costs of l10n (localization) bug fixes and the numbers aren’t pretty at all. For the average mobile app, in terms of complexity, the total costs of fixing those bugs can reach $52,800 / year.
The biggest challenges with translating content after development are the later releases of our projects, or releases with less languages (due to tighter deadlines). Maintaining changes in development and keeping current keys in sync is also more difficult after development.
Designers create their prototypes and mockups in Figma, populate them with different languages, and are able to check how the design will look with different translations early in the process. That means your designer can now see if the design has to be altered to suit different locales before a single line of code is written.
On top of that, translators will have already been provided with screenshots of the planned locations for the text to provide context, simultaneously improving the precision of the translation as well as increasing the speed at which they can work.
This improved localization workflow allows your team to:
Catch design breaks at an early stage of your product development process.
Get product feedback early in your development process, both from linguists and/or user tests in multiple languages.
Lower the risk of localization errors in your product.
Lower the risk of a bad product/market fit.
Eliminate the seemingly endless back and forth between designers, developers, managers, and translators.
Ultimately shorten your time to market while ensuring higher quality translations.
The Lokalise plugin for Figma has decreased time to market for our projects significantly. Before, we used to translate content after development - but now we can translate it while it is being designed, thus we can release it sooner.Črt Mrzlikar, Project Manager, CNJ
Črt Mrzlikar, Project Manager, CNJ
How the Figma plugin works
The Lokalise Figma plugin is available from the Pro plan and above. The key mechanics of the integration are as follows:
1. Push texts from Figma to Lokalise (with screenshots attached).
2. Translators create translations in Lokalise.
3. The designer can “pull” translations from Lokalise back to Figma.
4. The designer can switch between languages in Figma to view how the different language texts appear in the designs.
With over 50,000 paying users, Figma has become a staple tool of the product design world. This has been a highly requested integration as many of our users have written to tell us how much it would improve their workflows.
Alex is Product lead at Lokalise, a tech enthusiast, and co-founder of an amateur football league. He has helped many customers to make improvements to their localization workflows and has become Lokalise’s product guru. In his free time, he enjoys travelling, playing football, and basketball.
Alex is Product lead at Lokalise, a tech enthusiast, and co-founder of an amateur football league. He has helped many customers to make improvements to their localization workflows and has become Lokalise’s product guru. In his free time, he enjoys travelling, playing football, and basketball.
Design-stage localization: 3 reasons why it's the solution for fast-growing, agile companies (Part 1)
Design-stage localization is a powerful way to continuously release fully localized products like mobile apps, web apps, and games. It allows for the creation of designs suitable for multiple languages and bridges the gap between the designers, developers, and translators working on localization. But talk to fast-growing companies that are agile and rely on continuous development to some degree; you’ll quickly realize that most haven’t maintained processes
Design-stage localization: the top challenges for localization teams (Part 2)
In Part 1, we covered why design-stage localization is a game-changing solution for agile, multilingual product development. If you read it, you’ve likely thought about what it would take to create a unified localization workflow based around Lokalise, your design tool, and localization team. You might be asking “should I use mac
Translation Management System: Everything you need to know
When you’re expanding into new markets, your content needs to speak multiple languages. But managing translations manually can quickly turn into a logistical nightmare. This is where a Translation Management System (TMS) comes in. In this comprehensive guide, you’ll learn everything you need to know about translation management systems, starting with understanding what is tr
