Localization in Figma in one click: Joom’s sharing its know-how

Anna Nodzhák, Design Director at Joom, tells how to work with translations, stop going mad with manual text transfers, and automate artboard localization in Figma if you have a multilingual application.

At the launch, a product has often a number of urgent needs that have to be addressed. It is not always possible to do everything at the highest level at once until you get more available resources. So we’ve been outsourcing the content creation for the App Store and Google Play for a long time. It worked, and even worked well, but we wanted to improve it. Recently, we’ve finally decided to create the content in-house.

What does the process of preparing covers for stores include? Let’s skip the part about analyzing trends and competitors, processing data, etc. Here we’ll talk about adapting covers for two platforms in three dimensions in 17 languages. That’s 102 screens in total. Ready, steady, go!

Part I. Technical aspects, or how to avoid the copy-paste approach

The app page in the store is on the very top of the marketing funnel so the communication process should be flawless. That’s at this point when you either get a new customer or lose her. Therefore, simple translations made in a hurry with Google Translate are not enough. It is crucial to have texts that are not only impeccable, but also vivid and adapted to local particularities. At Joom, these are country managers who are responsible for the quality of translation. In short, they manage our customer support and content projects in different languages.

When we received the translations for the first time, we naively thought that we could just copy and paste everything manually into artboards. However, it turned out that this process takes about an hour just for one language (double check included). To get all the translations for an artboard, you need to go through two boring, painstaking and extremely exhausting days. And that’s just to obtain one version. But wait, you’ll certainly have edits as well. Besides, a series of experiments should be carried out. Such labor is more suitable for a robot rather than a living person. Obviously, we were looking for another solution and needed some magic…

Writing a plugin for Figma

Figma allows you to manipulate document content through a system of plugins that can be written in TypeScript. My colleague Iskander Sitdikov agreed to help with plugin development. It seemed at the time that all we needed was to load the dictionary, find all the texts, and replace them with the corresponding translations.

First, we immediately noticed that some parts of our texts, such as numbers, percentages, prices, names (Google Play, Joom, Joompay), did not need to be translated, and decided to support custom exclusions. We made the first version of the plugin and were delighted with the speed of the artboard transformation.

Well, we were rather happy until…

…we noticed that even if the artboards were translated, it didn’t work the way we expected. We had quite a lot of text with hybrid formatting, and it all went wrong.

Preserving the formatting

In cases when several styles were applied in one paragraph, as, for example, in the comment to the post (see below), instead of the Medium Primary 100 heading and the Regular Primary 60 link we got the entire Medium Primary 100 block. It’s really time-consuming and risky to re-mark it manually every time after replacing the text, especially if you don’t speak the language.

But it looked like we could quite easily do it automatically, if we translated the marked parts of the texts. We promptly sent additional texts for translation and started developing the second version of the plugin.

The new version cleverly split the texts into parts and carefully put translations into them preserving the correct formatting. At that stage we found some small defects in the formatting: sometimes a piece of text with an extra space at the end was highlighted, which is why the translation was simply not available for it.

Adding a currency converter

Then we noticed that we still had prices in rubles. The existing currency conversion plugin did not work exactly as we wanted. It was important to preserve the same formatting of currencies as in our app, including designation, position, and separators. To address the issue, we also implemented a customizable currency converter.

Everything seemed to work properly. We were happy again. And then it was the turn of the Arabic and Hebrew.

Translating into RTL languages

Trust us, a whole novel could be devoted to this part, and not just a paragraph. Figma does not support RTL languages ​​- those that are written and read from right to left. What a pain!

We did find a couple of plugins for interactive input of Arabic text, that didn’t work, and one plugin for batch RTL re-formatting, that didn’t work either.

Pasting and formatting these translations manually was even more dangerous than <insert your horrifying comparison>. Better <insert your most reckless act>.

Having digged through the existing plugins and spent a lot of nerves and efforts, we nevertheless added to our plugin the ability to translate into RTL languages with the correct text orientation, word wrapping, and even with fully preserved formatting.

It was quite challenging to debug the display of the Arabic text, having only Google Translate at hand and without any notion of the language. Unfortunately, even after all this witchcraft with texts, we couldn’t fully automate them as we did with other languages, since the interfaces themselves, the order and direction of the elements still had to be turned over manually. But soon after releasing the plugin we fixed this as well. Here is how the final flow looks like.

Previously, we would spend about an hour transferring texts to artboards for five screens in one language. Translating texts in 17 languages would have taken more than two days of monotonous work. Now with the help of the plugin, translation is done in one click.

But I’m getting ahead of myself. Up to this point, the story was only about the difficulties concerning one aspect: artboards — plugin — Figma. Yet, there is another big part of work that took the most time and effort, so let’s talk about it.

Part II. Human aspects: we are still not robots and want to make as few mistakes as possible.

The plugin is not a human, it does not make mistakes and does not forgive. It will help if some translation is missing, if there is an extra space, if there is a missing space, and so on. But people make mistakes, alas.

Correcting mistakes in translations (in advance)

As it was mentioned above, the plugin can detect many errors. Yet, it is better to avoid mistakes at the stage of preparing translations. This will help you to save a lot of time. Otherwise, once you discover some mistakes you’ll have to submit the texts for additional translation, then wait till you can return back to the task.

Creating a general context

The context is very important: although the mock-ups have phrases highlighted in white and red, we all perfectly understand that this is one text. We sent these phrases to the translators in the form of a table, which also contained blocks of texts highlighted in color, so they could match phrases visually. However, it turned out that in the table these phrases were not perceived as related to each other. Translations failed.

We had to make the markup more explicit and to explain again to the translators that these pieces of text are part of the whole. One more round of translations and we fixed this problem.

Making final edits

All translations are done. Fonts on the covers are adjusted accordingly (did you know that a title in three lines in English easily turns into six in Italian?). Everything is ready, even Arabic and Hebrew versions! We upload all covers grouped by locale, platform, size, and experiment. And if we were not so exhausted, this would definitely be the time for tears of joy. We happily resolve the task.

Then, for the first time, country managers see texts in covers and… suggest edits. All edits come in the form of a document, so we need to transfer them to the table. There are no screen numbers in the table. Therefore, to correlate edits with artboards, we have to check the text and look for it in the table. Edits are sent by everyone in their own way. One translator precises which text to replace with which, the other shares the correct version only. One does not duplicate the same texts in different versions, the other enumerates screen by screen… Done! Can we now happily close the task?

Well, not yet, as far as our country managers decide to make the translations more native and suggest more revisions. Even though there were only a few minor edits on each screen, we had to rewrite almost all the texts in all locales, re-check all the screens, and re-upload everything again. We have learned from our mistakes and could probably help somebody else to avoid these mistakes thanks to our recommendations.

• First of all, prepare the main version of the artboards (the one that you will duplicate in different languages) and final texts for translation.
• Along with the texts, be sure to show the translators the mock-ups of the main version so that they understand the context of the task correctly.
• If you need to break down phrases into blocks, make an explicit markup, and also explain the meaning of this markup and additionally draw the attention of the translators to this.
• And most importantly, explain the importance of the fact that the finished translations are sent only once with no revisions possible after that. It is just too expensive.

Any links to the plugin?

If you also work with many languages, try out the plugin: Static Localizer.

If you are interested in how we developed the plugin, check the source code on GitHub. And feel free to share your most mundane design tasks in the comments!