February 22, 2021 By Olena Polissky Comments are Off

HOW TO AVOID COSTLY MISTAKES WITH UI LOCALIZATION INTO ROMANCE LANGUAGES

Following our first article on general issues with UI localization, we have chosen to begin this series with UI localization into Romance languages, largely because this language family—which includes Spanish, French, Portuguese, and Italian—encompasses nearly a billion native speakers.

Speakers of Romance Languages in the World

Software Localization to Spanish

Spanish is the most widely spoken of the four languages, with over 480 million native speakers in Europe and Latin America. As such, localization to Spanish is a common choice for companies launching a software localization initiative.

Software Localization to Portuguese

The second most widely spoken language is Portuguese. It has over 270 million native speakers. The majority of Portuguese speakers reside in Brazil, with significant populations in Portugal as well as in several African nations. Because of the differences between the language used in Portugal and in Brazil, Portuguese software localization often takes a two-pronged approach.

Software Localization to French

French comes in third, with over 77 million native speakers, who live in France, Canada, and throughout Africa. Since the French spoken in Europe differs significantly from Quebecois French, French software localization follows a two-pronged strategy similar to Portuguese. The robust market for apps and software in France means that many companies opt for localization to the French early in their expansion process.

Software Localization to Italian

Italian is the least widely spoken of the four, with 63 million native speakers. However, many companies prioritize Italian software localization over other, more widely spoken languages such as Portuguese. It is considered one of the “Big Four” languages in software localization, along with French, Spanish, and German (together, they are referred to as FIGS).

Each of these languages originates from Vulgar Latin, and so they share many common characteristics in terms of grammar and vocabulary. For this reason, we will approach them as a group when discussing the challenges involved in the software localization process from English into any of the Romance languages.

Expansion and Contraction

One of the major challenges that developers face during UI localization into Romance languages is expansion, also referred to as word growth. Expansion is a localization industry term that means that a word or phrase that conveys the same meaning in two languages is longer in the target language.

As an example, we will look at a phrase often used by Microsoft in their multilingual support documentation:

As you can see, each of the translations is significantly longer than the English. While the Spanish phrase in the table above is particularly long, in general, experienced localization professionals estimate 30%-word growth when translating from English to any of these languages.

If the user interface can only display as many characters as appear in the English text, then the translated text may appear cut off or be completely unreadable. In the example above, if only 15 characters’ worth of space were allotted, the text would read Opciones de ini after localization to Spanish. For a Spanish-language reader, the meaning might be entirely lost.

Ideally, expansion should be addressed before the process of UI localization into Romance languages even begins.

Developers who know their product is going to undergo localization to French, for example, can design with expansion in mind, allowing more characters to display than appear in the English source. They should also steer clear of using fixed widths or heights for elements, so that text has room to grow—or wrap to a second line—as needed.

The Role of Grammar in UI Localization into Romance Languages

The main goal of the localization process is to have a user interface that reads naturally to an end-user. And for an end-user to feel like the UI reads smoothly, it is vital to use correct grammar in the target language.

There are a number of aspects of Romance language grammar that come into play during software localization. We are going to introduce each one and provide examples of how they might appear during UI localization into Romance languages.

Gender agreement in Romance languages

Unlike English, all four Romance languages use grammatical gender.

This means that each noun has a gender. Depending on a noun’s gender, the article changes—and often, so do the endings of adjectives.

How does that work in an actual string? Here is an example that might come up when working on the Spanish localization of error messages.

In English, we say “the printer is not connected.” If we start talking about the keyboard instead, no other element of the sentence changes; we just say, “the keyboard is not connected.”

In Spanish, however, the words for “printer” (la impresora) and “keyboard” (el teclado) have different genders.

In other words, if the original English-language string is written using a variable to indicate the object’s name (“The [object] is not connected”), then the translator does not have the flexibility to make sure the grammar is correct.

To make the strings translation process simpler during localization to Spanish, it would be best to have a separate string in the code for each individual error message:

The printer is not connected.
The keyboard is not connected.

It is also important not to over-generalize and try to use a shortcut by assuming that the only thing that changes is the last letter of an adjective. For example, in French, adjectives ending in -x in the masculine form (such as vieux, which means “old”) end with an -e in their feminine form (vieille).

Possessive pronouns in Romance languages

Possessive pronouns are another example of grammatical gender that can affect UI translation.

These pronouns (“his/her”, for example) do reflect gender in English, but it is the gender of the person being referred to. If a woman owns a house, we refer to it as “her house”; if a man owns it, we say “his house”.

In French, for example, the possessive pronoun reflects the gender of the noun being discussed, not the gender of the person being referred to.

C’est sa maison (That’s her house) uses ‘sa’ because ‘la maison’ (house) is feminine.

C’est son garage (That’s her garage) uses ‘son’ because ‘le garage’ (garage) is masculine.

The same possessive pronouns would be used in localization to French whether we are discussing what belongs to Marie, a woman, or Jean-Luc, a man. Because possessive pronouns reflect the noun they modify, it is important to keep the two elements within one string during localization to French and not to use a variable in place of the noun.

Much of what applies to grammatical gender during the UI translation process also applies to number.

This means that there are four different ways to write the word “small” during localization to Portuguese, for example.

Because of the implications of gender and number, it is worth noting that the words “it” and “they” can present problems for translators during Portuguese software localization (as well as in the other three languages mentioned above) if not enough context is available.

“I” and “the” are gender-neutral in English, but there is no gender-neutral equivalent in any of these four languages. If a translator takes a guess during localization to Portuguese and gets it wrong, the resulting construction will stand out to a Portuguese reader.

The solution is to provide translators with as much context as possible during the UI localization process and to realize that in some situations, a string may need to include multiple full sentences.

It might seem logical to separate “The program finished installing. You can now click to access it” into two strings. However, by keeping them as a single string during localization to Portuguese, you allow the translator to render a grammatically correct translation.

Beware of the ‘s possessive in code

Ask anyone who has led a project involving UI localization into Romance languages from English, and they likely have wrestled with this particular dilemma.

To indicate possession, English uses an apostrophe followed by the letter “s”: “The white one is John’s house”.

Romance languages typically use the equivalent of the word “of” to indicate possession. So, for localization to Italian, “John’s house” becomes la casa di John. (Literally, “the house of John”.)

English-monolingual developers do not always realize that other languages have a different way of expressing possession. This can lead to strings that cause problems during software localization into Romance languages.

To avoid issues during UI translation, the best practice is to ensure that any string including an apostrophe -s possessive is left as a full sentence. This will maximize the translator’s ability to reorder the elements of the sentence correctly in the target language.

As always, the best way to successfully localize any user interface is by taking into consideration the characteristics of the target language before writing both the code and the elements of the UI. This ensures meaning will be preserved while allowing for the stylish, accurate translation of strings.

If the issues we described resonate with your experience, we hope that with our tips you will be better prepared for software localization into Romance languages in the future.