Tag: Localisation

Talking about intercultural communication in class this week, we delved into several topics, including localisation and writing with an international audience in mind.

According to Bert Esselink (2003), localisation “revolves around combining language and technology to produce a product that can cross cultural and language barriers”. Though at first localisation applied mostly to software applications, today global web communication means that a great number of technical authors write for localisation. Localisation best practices are a broad topic, but this post focusses on some practical strings authoring advice from a translator’s point of view.

Internationalisation

The #1 best practice in localisation is to internationalise your product. This means you should ensure that your product and your content will enable localisation for your present and future markets. “Future” is key because all languages do not have the same requirements, and you should strive to “future-proof” your code and content from the start.

Internationalisation has technical and linguistic aspects. Technical aspects include ensuring your platform and code will support the specificities of each locale, including different character sets and orientations. Three pieces of advice here:

• Prefer Unicode to maximise compatibility.
• Do not hardcode text in graphics. Otherwise, you will need to extract the text for translation, and create new localised graphics. Different characters and right-to-left orientation will add extra work.
• In doubt, check with a localisation specialist before authoring.

You can find more technical advice online, for example on web pages by Microsoft, Google Developers, Mozilla, and Oracle. As you can see on these pages, technical best practices are not enough to get your strings ready for localisation.

Authoring strings for localisation

As a translator, technical issues tend to be solved when I receive the strings, but linguistic issues may remain. Why should you care? After all, it is up to the translator to solve these issues. Yes, but:

• The translator most likely translates the strings out of context in a computer-assisted translation (CAT) tool. He/she only sees the translatable text and the description keys/strings. More on that shortly.
• If the translator misinterprets a string and introduces errors in the translation memory (TM), these errors will persist until a) you do the in-context review (best-case scenario) or b) a diligent user (the world?) gives you feedback.
• If a translator sends you questions for each unclear strings, this translates into extra work and time lost for both of you – maybe extra cost as well.

Below I provide a few pieces of strings authoring advice based on the biggest pain points I have experienced as a translator.

#1 Rule: String descriptions are the best

Unfortunately, translators often localise user interfaces without any visual support. They may have access to the live website/app, but the international version may not be available yet. A demo version of the software may not be in the cards. Translators may have access to screenshots, but these do not display the whole content. There is a simple solution that is beneficial to all the users of the strings files – descriptions. In most strings files, you can insert a description key to clarify the translatable content that follows (button, menu item, alert, etc). This is very useful especially for very short strings. Consider these examples:

• “Bookmark” and “Contact”: Buttons? Menu items?
• “Empty”: Button? Message alerting you to an empty folder?
• “Login”: Form field? Button? Yes, it should be “Login” (form field) and “Log in” (button). Without context, spelling mistakes can create confusion.

You can also insert a description string to clarify some items: what do the placeholders replace? If there are numerical variables, what is their numerical range? Etc. A description string is very helpful in case of length limits (see below). If you struggled to stay within a limit, the translators are likely to struggle as well. In case of a very short string, explain what the button, message or menu item does. It will help to find a shorter alternative.

Keep it short, but do not sacrifice clarity

Clarity is essential in technical communication, but even more so in web/software localisation because length constraints are frequent. Many languages need more space than English to express the same idea. For example, even if instructed to “keep it short”, languages like Latin languages, German, etc., can be up to 30-35% longer than English. Make every word count. This is especially true for menu items, app strings, and Google Ads. If there are absolute length limits:

• Do not reach the limit in English. Plan for the 30-35% expansion rate. Of course, that may not be possible if the limit is 6 characters.
• Avoid abbreviating. Abbreviating may not solve length issues in some languages. If available, choose an alternative that does not require abbreviating. If not available, provide a description string.
• State the limits clearly as a number of characters. CAT tools can highlight strings that are over these limits.

Because of length limits, you may resort to complex noun clauses. Please don’t. If you can. What is a complex noun clause? In a complex noun clause, several words form a complex term without any clear functional link between each word. Typically, one word is the subject and the other words modify this subject. Consider these two examples from the Oracle Guidelines:

• “Empty File” – Is the file empty? Is it a button to empty the file?
• “Quantity Changes Impact Rate Master”. Do changes in quantity impact the rate master? Does the quantity change the impact rate master?

As the source of most translators’ questions, complex noun clauses are the best argument in favour of description strings. If you cannot avoid such clauses, clarify them.

List the strings in a logical, not alphabetical, order

Here is why you should avoid ordering strings by alphabetical order, and prefer a logical order by webpage, menu, section, type of string, etc.:

• A logical order makes it easier to refer to a specific string in case of questions or updates.
• Picture this: there are two “Empty” strings in the strings file. One is a button in Menu X, and the other is a message in Menu Y. You want to edit the message to clarify it, but both strings follow each other in alphabetical order and there is no clear description key. How long will it take you to identify the right string? And the translator?
• Concatenated strings are unlikely to be displayed together in alphabetical order. Eg.: you split a sentence into String #1 and String #2. If you order the strings logically, String #2 will be directly after String #1, providing the translators with the right context. Alphabetical order makes this unlikely. Have dozens of concatenated strings and this becomes a puzzle.

On the topic of concatenated strings…

Avoid concatenating, and be careful with placeholders

When concatenating strings, you assume that grammar and syntax rules are the same in all languages. Mozilla provides a good example of concatenation issues and recommends using placeholders instead. This is invaluable advice, but it is not always enough because abusing placeholders and variables also causes grammatical issues. Consider this real-life example:

“Delivery is scheduled {0} {1} {2} from {3} at {4}”

There were no explanation regarding what {0}, {1} {2}, {3} and {4} meant. The author could not say for sure what each stood for. Searching the other strings, we solved the puzzle:

• {0} stands for “every”
• {1} is a numerical variable ≥ 1
• {2} stands for “day(s)”, “week(s)” or “month(s)”
• {3} is the start date
• {4} is the delivery location

This works (somehow) in English, but it does not work in French, with or without concatenation. “Day” and “month” are masculine while “week” is feminine, and “every” has to agree in gender. Also, the numerical variable is not needed when it equals 1. For {3}, the proposition is “à partir de lundi 11 février”, but it is “à partir du 11 février”. Here is the French translation with text instead:

Every 1 day(s): “La livraison est programmée tous/toutes les 1 jour(s) à partir de {Date} à l’adresse {Address}”

To be grammatically correct, it should read:

“La livraison est programmée tous les jours à partir de {Date} à l’adresse {Address}”

To reduce the number of alternative strings, we end up with awkward English and localised strings. At least two variants of “{0} {1} {2}” are necessary in French, one for masculine and one for feminine (we could live with the unaesthetic “(s)”). Languages like Russian require even more variants because there are three possible declinations for “day(s)”, three more for “week(s)”, and another three for “month(s)”, depending on the preceding number.

Do not overdo it with placeholders. Limit the number of placeholders that contain variables. If you cannot, define with target linguists the number of variant strings you need to provide for localisation.

Conclusion

String authoring should abide by technical communication guidelines regarding clarity and cultural sensitivity. More than other content types, strings must be concise, but never at the expense of clarity. Though it may seem like a burden at first, providing descriptions and inserting variant strings to account for different writing rules will make strings management easier for you and your localisation teams.

References

Esselink, B. (2003) “The evolution of localisation”, Multilingual Computing and Technology, available: http://www.intercultural.urv.cat/media/upload/domain_317/arxius/Technology/Esselink_Evolution.pdf
[last access 10 February 2019].

Globalization Documentation (n.d.) Microsoft, available: https://docs.microsoft.com/en-us/globalization/
[last access 10 February 2019].

Internationalization (i18n) open source libraries and APIs (n.d.) Google Developers, available: https://developers.google.com/international/
[last access 10 February 2019].

Localization content best practices (n.d.) MDN Web docs, available: https://developer.mozilla.org/en-US/docs/Mozilla/Localization/Localization_content_best_practices#Avoid_concatenations_use_placeholders_instead
[last access 10 February 2019].

Understanding Translation Issues (n.d.) Oracle, available: https://docs.oracle.com/cd/E17984_01/doc.898/e14698/translation_issues.htm
[last access 10 February 2019].