The complete guide to design-stage localization
Get the ebookTraditionally, 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.
Once a company decides to add more languages, the traditional best practice localization workflow looks like this:
- 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.
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.
Črt Mrzlikar, Project Manager, CNJ
The complete guide to design-stage localization
Get the ebookStart translating in the design stage
With Lokalise, you can now add designers (and copywriters) into the mix early on. The Lokalise integration for Figma makes it possible to start translating in the design stage.
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.
For a step-by-step tutorial, take a look at the documentation along with the video included in it.
Highly requested and finally delivered
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.
If you’re interested in giving the Lokalise Figma plugin a try, check it out in the Figma plugin community and sign up for a 14-day free trial. You’ll get access to all of our features (including Figma plugin), no credit card required. But if you’re not keen on Figma we also have a Adobe XD plugin, check out our guide on multilingual UX & UI design best practices in Adobe XD.
