top of page

How the product team can impact the quality of localization

Updated: Jan 31

Greetings! My name is Yaroslava Kachan, and I am a technical writer at MacPaw on the Setapp product. Setapp is a service that gives users access to 240+ apps (CleanMyMac, Bartender, CleanShot X, Craft, TypingMind, and many others) with a single subscription. We localized Setapp in 7 languages and ordered translations from freelancers. Last year, we also added the Ukrainian localization and made it on our own. This helped to look at the localization process from a new point of view:


  • First, we saw our communication with translators through their eyes and, let's say, could feel their pains.

  • And secondly, we realized what and where we could improve processes on our side to get a better translation. 


Unfortunately, it is difficult to predict where something can go wrong. Suppose you draw an analogy with driving a car. In that case, no matter how well you learn the traffic rules, you will still have to get into dangerous situations and hit the brakes hard several times before becoming an experienced driver and seeing the danger from afar. Therefore, I want to give ready-made recommendations in this article and demonstrate where such "dangerous" situations arise.


I will share real cases from our team's life and our conclusions. I hope this article will protect you from our mistakes, and your products will always have a top level of localization.


Disclaimer:

I excluded some prerequisites and circumstances to keep the text manageable. The situations were more complex and complicated than this article may seem.


Situation No. 1. Adding new functionality

The team added two new buttons to the interface:


  • Get Web App (11 characters)

  • Get iOS App (11 characters)


It was necessary to localize them. For the translator, it was a task with an asterisk because the words Get and App in other languages are quite long for buttons. In particular, in Ukrainian:

  • Установити вебпрограму (23)

  • Установити iOS-програму (23)


Translated buttons would flood the interface.


Preliminary decision

To simplify the task for translators, the team proposed new names that did not contain the word App :

  • Get for Web (11)

  • Get for iOS (11)


But, when we got rid of the word App, the button names in Ukrainian were still too long:

  • Установити на веб (17)

  • Установити на iOS (17)


This option did not fit our design, and we had to look for a solution in another dimension.


Final decision

We decided not to change the buttons' names but to inform the translators of the maximum number of characters. After all, localization is a way to an optimal solution considering all limitations and wishes. The Ukrainian localization took on the following form:

 

Recommendation

Indicate for translators the limit on the copy's length, where relevant

If you know that a specific button/label/header cannot contain more than N characters, please mention it.

❌ Button.

✅ Button. Max length: 9 chars.

 

"Shortening" the English text for the sake of translations is ineffective. Well, with a probability of 50%, it will help, but with a chance of 50%, it will not help.


Situation No. 2. Applying changes to the existing functionality

Our product has various thematic blocks that simplify navigation:


At some point, we decided to try to place the blocks more compactly:


Preliminary decision

English localization Recommended for you (19) did not fit into the new design, so the copy was shortened to Recommended and sent for re-translation.

It was an English-centric view: "If the problems are solved in English, they are automatically solved for other languages as well." The English-centric view creates the false impression that other copies behave the same way as English copies. However, Recently updated in Ukrainian  Нещодавні оновлення (19). 19 characters was too much for the new design. But this copy was not sent for re-translation because everything was OK with the English one.


Final decision

All block names were sent for re-translation, not only those that got changes in English.


 

Recommendation

Avoid the English-centric view of the texts

In case of design or UX changes, assess whether they could theoretically affect copies in other languages. If so, send the copies for re-translation and indicate their new use conditions.

 

Remember, other localizations "live their own lives" :)


Situation No. 3. Cloning of existing functionality

We had the "Invite friends" button on the top of the Setapp desktop for a while. Later, we decided to duplicate it in the profile menu:

Because the translations for this copy have already been done, the team decided not to send the copy for re-translation.


Preliminary decision

The team copied translations from an already existing button. The team capitalized the words in all languages as they must be in English. 



As you can see, in some translations, this capitalization was inappropriate. Not all languages have a tradition of capitalizing words in menus. Each language has its own spelling rules, which may differ from the Apple Style Guide. And what was correct in English created inconsistency in other locales.


Final decision

The team aligned the capitalization with the spelling rules of each language.

 

Recommendation

Do not make changes to the localization without the consent of the translator


Even if the solution seems obvious to you, it is best to consult with a translator to ensure it has to be this way.

 

In addition to spelling, punctuation is another challenge with pitfalls in every language. Therefore, approve even the most superficial changes with translators who know perfectly all the peculiarities and contexts of their language.


Situation N. Anywhere, anytime


But if someone asked me for universal advice, I'd say:


 

Recommendation

Add screenshots

This is a treasure for the translator.

 

Going back to the driving analogy, screenshots are the navigator. You can explain the route with words: "Go straight, see a roundabout, take the second exit, turn left in 10 kilometers...". Or you can give the driver a navigator, which will solve 99% of his questions about the route. A screenshot is a guide to what you need to localize, how, and why. Even if it seems to the team that everything here is simple and obvious, it may not be so.


Imagine that in a copy with dozens of other copies, you send for translation the names of categories — Optimize, Work, Create, Develop.


With no screenshot, it's unclear that all these copies belong to something common. So, the words can be translated as:

  • different parts of speech («Робота», «Створити»)

  • not aligned in the mode of verbs («Оптимізуйте», «Створити»)

  • the difference between the words is almost erased («Зробити», «Створити», «Розробити»)


This example is artificially dramatized since we did give a screenshot:). But hopefully, it conveys why a screenshot makes a translator's life so much easier and enhances the localization quality.

If your language, you will still be able to catch all the flaws later and fix them, then in the Chinese one - probably never. A product can look, let's say, weird for years, and the team won't even know about it. Therefore, taking care of all "dangerous situations" in advance is better.

34 views0 comments

Recent Posts

See All
bottom of page