December 14, 2020 By Olena Polissky Comments are Off

Best Practices for Successful UI Localization

UI localization is one of the fastest ways to achieve sales goals for software companies tapping into new global markets and aiming to grow internationally.

In 2020, the research firm App Annie reported that emerging markets such as Brazil, India, and Indonesia drove year-over-year app downloads growth. During the COVID pandemic, the use of mobile apps has increased further—not just for games and entertainment but for banking, food delivery, and even fitness.

And mobile apps are not the only source of growth. Companies such as Copperleaf Technologies, an Art One’s client that specializes in decision analytics software, have significantly increased revenue after localizing their software for new markets.

However, there are important considerations for launching the software in a foreign market, and localizing the user interface (UI) of an application presents a different set of challenges from document translation. When developing an application, designers and programmers should think about how the UI will need to adapt for the translated text. Once they hand the product off to the professional translation company that will oversee the UI localization, they will need to ensure that translators have the tools they need to do their job correctly.

This article is the first in a series aimed at designers and developers that will share best practices in UI localization. We will start out by talking about a set of principles that apply regardless of your source or target language. Future articles will address topics specific to different language groups.

Note: The examples in this article center on UI localization workflows for software originating in English. However, many of the same concepts apply when localizing from another language into English.

While Developing Software

Allow Space For Word Growth

Each language needs a certain number of words or characters to express an idea. The number needed changes from one language to the next. When an idea requires more words or characters in the target text, we call this “expansion” or “word growth.” When fewer words or characters are needed, that’s “contraction”.

When you translate from English into Spanish, for example, the target language will need at least 10% more space than the source. The same is true of other Romance languages such as Italian, French, and Portuguese. Other languages at the higher end of the scale include German, Finnish, and Hungarian.

You may sometimes have expansion issues while translating into character-based languages during Japanese or Chinese software localization. This is especially true when writing loanwords using Japanese katakana. But depending on the context, you may find yourself with the opposite issue. An idea that takes 30 characters to express in English only needs two or three two-byte characters in Chinese.

Let us take a look at how the 14-byte English phrase “Privacy Policy” expands or contracts:

Many UIs have not been designed with localization in mind. In other words, they only permit enough space for the text in the original language. This can cause a longer phrase in the target language to overlap with other text, disappear, or be unreadable.

Likewise, contraction may also create layout issues, even if only due to an excess of white space.

Prepare For UI Localization in Right-to-Left Languages

Several languages read from right to left, among them Hebrew, Arabic, and Farsi. In these cases, text must be aligned from right to left. The same applies to the entire interface. It needs to mirror the left-to-right layout, or it will not reflect the way users of those languages interact with software.

Quality assurance is a vital part of UI localization into any language. However, it is even more essential when localizing into right-to-left languages. An experienced user of that language needs to thoroughly test the localized software. The goal is to ensure that the user experience mimics that of the original language.

Don’t Repurpose the Same String For Different Contexts

When writing code, it is best not to repurpose the same string in multiple parts of the UI. Many languages have homographs, i.e., words spelled the same way but have different meanings. Often, they are different parts of speech altogether.

English is famously rich in homographs. For example, wave, which can be a verb in “wave your hand” or a noun, as in “there’s a wave coming in”. However, it is hardly unique. For example, the Spanish word sobre can mean either “on top/above” or “an envelope,” depending on the context.

Software company Mozilla explains this concept to its developers with the word bookmark:

“Take Bookmark: it can be both a noun and a verb in English. A developer could be tempted to reuse the same string “Bookmark” in the button to add a bookmark, and in the header for the next dialog. This will not work in some languages.”

In Portuguese, a bookmark is a marcador. But if you are clicking on a button to add a page to your bookmarks, you would expect it to say Adicionar aos marcadores [“Add to favorites”].

Create strings that allow for the flexibility to use correct grammar

Many common shortcuts save time when developing the source-language version of a software program. These same shortcuts then cause hiccups when it is time for localization.

Concatenating strings is one of the most problematic shortcuts. To allow for accuracy and good grammar during localization, a variable or placeholder needs to occur within a full string. If a series of shorter strings are concatenated, it becomes difficult for translators to use correct word order and grammar.

Some examples:

Possessives. Mary logs into her bank account. When writing the code, a developer concatenated the placeholder for her name with ‘s account to produce “Mary’s account” in English. In many other languages, however, the possessive marker comes before the name. This leaves the linguist unable to correctly represent the possessive in the target language.
Gender and number of adjectives, prepositions, etc. Many languages use a different form of an adjective or preposition based on the number and gender of the people (or things) it describes. For example, if ordering a product online, the line items might include “Estimated delivery fees” and “Estimated total.” In French, the word total is masculine and singular, while the word frais de livraison [“delivery fees”] is plural, which affects the prepositions that precede each word in a phrase. If a developer tries to concatenate “Estimated” with a variable to save strings, then the French text loses the ability to adapt the preposition for the specific noun.
Affixes. Some languages do not use separate words to convey certain ideas. Agglutinative languages such as Turkish or Korean append a suffix or a prefix to an existing root word to add layers of meaning. If linguists are forced to follow an existing sentence structure or word order, they may not be able to use the correct word form for their language.

By ensuring that strings consist of full sentences or even paragraphs, many of these grammatical issues can be avoided. With longer strings, the linguist can change the order of words or clauses within the target text.

Use the right encoding to ensure characters display correctly

When reviewing a localized UI, you may come across a series of characters such as

These incorrectly encoded characters arise when an encoding system is not specified. The software falls back on a standard format such as ASCII. Characters without a correct match in that system will display incorrectly. For all elements of your UI to display correctly, it is necessary to specify the correct encoding format (most sites use UTF-8).

During a Localization Project

Define a Precise Target Locale

Localization software may require a code that identifies the target language and the target market. For example, a Spanish-language website intended for users in Spain uses code es_ES. Its counterpart aimed at users in Mexico uses es_MX. Both start with Spanish (es), but the country code is different.

Language variants each have their own vocabulary and grammar. Portuguese is an excellent example. Brazilian users have adopted many loanwords from African and Indigenous languages. Grammar has also diverged over the years, especially regarding pronouns.

Different regions may not use the same measurement systems or date/time formats. We see this in English – Canadians and Australians use kilometers when mentioning distances. Their American and British counterparts still refer to miles.

We’ve written about regional variations in English, French, Spanish, Portuguese, and Chinese. These articles will help explain why choosing the right locale is so important for these target languages.

English Dialects & Regional Variations

French Dialects & Regional Variations

Spanish Dialects & Regional Variations

Portuguese Dialects & Regional Variations

Chinese Dialects & Regional Variations

Include a Pseudo-Translation Step

One way to detect potential UI localization issues at the start of a project is to incorporate pseudo-translation (also known as pseudo-localization) into the process.

Pseudo-translation identifies the translatable elements in the code, then provides a “translation” of strings which increases the length of words by adding vowels, inserts accented characters, and more.

For example, a pseudo-translation of the string Click here to select multiple tasks might read as follows: “Çℓïçƙ λèřè ƭô ƨèℓèçƭ ₥úℓƭïƥℓè ƭáƨƙƨ. ℓôřè₥ ïƥƨú.”

As shown in the example above, this effectively mimics a translated text, demonstrating potential layout and encoding issues. Additionally, a full pseudo-translation of the UI may also highlight strings that might have remained untranslated, i.e., sometimes, the strings required for translation are being called from multiple files, and some need to be manually added. If this is the case, pseudo-translation can highlight where the developer has missed a file.

Provide Context For Each String

Any translator will tell you that context is the key to ensuring that they use the right words. The effort required to provide translators with context during a UI localization project will pay dividends in terms of quality. The adequate context will save time in the quality assurance phase when fewer errors are reported, and it will help avoid user reports of translation issues once the product is on the market.

This is particularly true for strings that consist of a single word to be used in a concatenation. For example, an English-to-Spanish translator facing the standalone word type will have to make an educated guess. The word might refer to a category [“categoría” or “tipo”] or it could be a command [“escribe”]. If the translator can see the context in which the word appears, it is much easier for them to select the accurate translation.

The more context you can provide translators, the more accurate each element of the translated UI will be. There are several tools available in the market today which can incorporate translation into the software development process. However, each tool is designed for a specific development platform. We can work with you to identify your specific requirements and choose the tool to incorporate into your agile development environment.

Ensure That Your UI And Your Documentation Are Consistent

Ideally, your technical documentation will be localized following the same guidelines and terminology as your UI. Using the same glossary and translation memory for both will ensure consistency between the two. If you use different terminology, you may risk causing further frustration for users that are already struggling.

For example, if your English-language UI uses the word ‘Send’ on a button, so should your documentation. If a user gets told to click ‘Submit’ instead of ‘Send’, they may be confused about the action that they need to take.

This also ensures that users can find the help they need. They will search your documentation portal using the names of the menus, actions, and buttons within the UI. Using different terms in documentation and software may mean that their search comes up empty.

Plan For Thorough QA Testing

Successful UI localization depends on a thorough in-language QA process. Each target language should undergo QA using the same use cases as the source. If possible, a user of the target language should perform the final QA. They will ensure that no code was modified during the translation process. They will also confirm that the localized application works the same way the original does.

If you have already designed your application with UI localization in mind, then you are ready to start the localization process.

At Art One Translations, we have localized many applications. Our team is familiar with all the technical challenges that may arise during UI localization. Whether you have a simple widget for a website, a mobile game, or complex enterprise-level software, we are here to ensure that your UI localization is seamless. Your end-users will rave about the results.

Comments are closed.