What is design-stage localization?
Design-stage localization (DSL) is a way to arrange your workflow so that your localization process and design stage of product development occur in parallel.
It is similar to continuous localization, but there is one crucial difference. Traditional continuous localization starts the translation process after the design stage is complete, while DSL begins at the design stage.
Why design-stage localization?
Because of significant efficiency improvements. Especially for agile teams or companies that rely on Continuous Integration and Continuous Deployment (CI/CD). Let’s see why.
Linguists and designers can see localized prototypes directly on the designs and give real-time feedback. They don’t need to wait for the product to be developed for them to check the output.
On top of that, feedback from translators and designers is made actionable spontaneously with little wait time, and updates are handled quickly.
Reduced time to market
As we’ve already discussed, DSL allows localization to be carried out in parallel with the design and development stages of product/software development. It complements the nature of agile software development, which means localization becomes part of product development and not an afterthought.
Developers and other stakeholders do not necessarily need to wait for translators for them to launch, as opposed to the traditional localization workflows that you can see in the image below.
Prevent L10N issues earlier
Design-stage localization allows UI engineers or developers to optimize and account for UI layout issues caused by text expansion and contraction before the development.
Traditionally, these issues would’ve been identified and fixed post-release, which slows down your time-to-market, ultimately costing you money.
Design-stage localization allows designers, developers, marketing teams, linguists, and other involved parties to seamlessly communicate and collaborate without dealing with pesky emails. And it all happens within the design stage, and even better, within the design tool itself! All of this is done before the product is even built!
By providing visual context, translators can produce quality translations, which will impact the overall user experience. Developers can work efficiently without a hassle by using screenshots to identify where key names are placed.
Now that we have seen why we could consider implementing DSL into our workflow, let’s see how it works.
Design localization workflow
This type of workflow is flexible and can be tailored to your technology stack and existing workflows.
- Designers start working on the product’s UI in the source language and assign each string with a relevant key name. Once finalized and approved, the keys and strings are pushed to a translation management system (TMS) or a platform for translators to start the localization process before the product goes into development.
- Linguists translate, proofread, sign off, and publish the localized strings. Designers pull the strings within the design tool, review the localized prototypes, and optimize them further.
- Developers get the translation keys from screenshots generated from the design tool sent by the designers, and develop the product with reference to the localized prototypes. The product is then tested by the QA team and finally released to multiple markets.
As mentioned above, this workflow can be adjusted.
- Designers could start designing and testing their UIs with machine translations, set character limits, and send out the keys with screenshots to the linguists and developers.
- Developers and linguists could start simultaneously. The developers could use key names in the designs instead of the actual language values. Once ready, the developers could pull the strings, test, and prepare for release.
Integrating this kind of workflow requires certain tools to really provide value in product development. These tools include:
- Translation tools—A translation management system with an API.
- Design tools—A Figma, Sketch, or Adobe XD plugin that can connect to your TMS.
Design-stage localization demo
Now let’s see design-stage localization in action by doing a simple demo. You can access the user interface designs from our Figma page.
The designs were created by modifying “Mental Health / Mindfulness Mobile App (Neubrutalism) UI” © Bilal Limi (Licensed under CC BY 4.0)
To successfully perform this demo, you’ll need these tools:
- A Locize account (we’ll use it as our TMS platform).
After copying the designs from our page, navigate to the Resources tab highlighted in blue and search for the Trans Localize plugin. After that, click Run.
Finally, our plugin will be displayed in your Figma project.
The functionalities of this plugin are straightforward:
- Pull—To pull translatable strings to the Locize.
- Push—To push translatable strings to the Locize.
- Display Keys—To display translation keys on UI designs.
As mentioned above, we will use Locize as our TMS, so let’s set it up.
Create an account and create a new project named l10n-app.
The plugin requires some information before pushing or pulling translation strings. All that can be obtained under the project settings found at the top-right corner.
Finally, you can obtain the required information at the bottom part of the page, namely, project ID, API key, and namespace.
Displaying translation keys
Navigate back to Figma, open our plugin, and click on the display keys to view the translation keys directly on the UI.
Despite its apparent simplicity, it’s a powerful feature. It helps engineers or developers know where each translation key needs to be placed. They don’t need to waste time thinking and generating keys, thus improving their efficiency. The screenshot below exemplifies its usefulness.
Pushing translation strings
To push strings to the Locize TMS, fill in the information required and select the version you want. It will appear automatically after filling in the project ID.
Next, click the Save button. And you can now click on push to push the strings to the Locize platform.
You should push the strings from your source/reference language. In our case, it’s English (en-US).
You should be able to see the number of words and keys just under the namespace.
Before we can translate strings, we need to choose the target language. Click the button indicated on the screenshot and add a new language. In our case, we choose Spanish (es).
Next, switch to the target language by clicking the EN-US dropdown button and selecting es. Finally, go to the namespaces, click the button on the screenshot, and start translating.
Translate all your strings and click the Save button at the top-right corner. After you have completed your translations, you’ll need to publish them.
Navigate to your dashboard, click on Show me the publish/CDN details, and click on the indicated button. Finally, your strings will be published!
Pulling translation strings
In Figma, run our plugin, input the required information, select the target language, click on pull strings, and watch the magic happen! The UI strings will now be in the target language and you can start pointing out design issues related to the target language.
From the image above, you can clearly spot text expansion. If the app was localized into Spanish after the first release, or just after development without coding the UI to accommodate text expansion, it would’ve broken the layout, costing you time and money.
This plugin is used for demonstrational purposes only, and has limited features; however, it will be supported with new features in the future.