Skip to Content

It’s always wonderful time when your product is so good and the board team decide to sell it into many other countries. But normally after the celebration party you need to face the new challenge: globalization.

When talking about software globalization, someone thinks of text translation, someone thinks of suffering code adjustment. No doubt that some globalization topics can drive people crazy (for example RTL and LTR UI layout when taking Arabic into consideration). But there are some quite simple things, which could efficiently help you to avoid globalization issues in the future.

Be Generous! Give It Enough Space!

When designing your UI layout, please always consider globalization. Your UI looks perfect in English does not means it will be the same in other languages. Sometimes it will be even unusable. For example, the following add button looks good in English, but after the text “Add” is translated into German, it will be unreadable. Sometimes it’s really painful to adjust the UI layout when English users have alrealy get used to it. So always remeber to give a wider space for text. This can help you to get rid of many translation issues in the future.

But how wide? Luckily we have a tool called text space calculator. It can recommand you a length, which fit more than 90% cases. After you read the document you will see the algorithmus behind it is super easy, but it really helps. And BTW we also have a Bridge version. Searching “UI text space calculator” in Bridge and give it a try!

Another useful tool is Pseudo, which is based on text space calculator. With it you could easily find which texts have potential issues. It could also help you to find out hardcoded texts and concatenated texts.

Concatenated Text is a Beast!

We always rely on text concatenation to dynamically build a text at runtime. But be careful of the danger behind it. Everything will only work smoothly until you start considering globalization.

Maybe…you have hardcoded the punctuation?

One day, your PO told you: “Let’s show users all the active products!” Then maybe your implementation will looks like following:

// The string starts with the i18n text "Active Products:"
var activeProductsString = this.getResourceBundle().getText('i18nActiveProducts');
activeProducts.forEach(product => activeProductsString += '"' + product + '" ');
return activeProductsString;

Looks good, right? Your text is pure i18n and there shouldn’t be any problem! But actually you missed the quotation marks. Quotation marks looks different in different languages. And it’s same for many other punctuations. I won’t say it’s a fatal problem, but it truely influence the globalization.

"Product"     // English quotaion marks
“产品”        // Chinese quotaion marks
„Produkt“     // German quotaion marks

What? First name is not always at the first place?

If you have some knowledge of Chinese or Japanese, you will know the answer is no. Check following example and you will know hardcoding the order is also very dangerous. Besides name another example is the date. Writing something like {day} + ‘/’ + {month} + ‘/’ + {year} is not a good idea.

Be careful of the function “toLowerCase()”!

When you are building an English string by adding some nouns into it, converting the nouns to lower case might be a good choice. But is that the same case for other languages? No. For example, in Chinese the charactors do not have lower or upper cases. And in German all the nouns are started with upper cases.

// The string starts with i18n text "I have many fruits: "
var fruitsString = this.getResourceBundle('i18nFruitsString');
fruits.forEach(fruit => fruitsString += fruit.toLowerCase() + ', ');

// English result: "I have many fruits: apple, orange, banana", looks good!
// German result: "Ich habe viele Obste: apfel, orange, banane", WRONG!!! should be "Apfel, Orange, Banane"

Not all the languages have such simple grammar as English

Let’s assume you are building a shopping cart application. And you want to tell the user if the product with selected properties is available. So you adopt concatenated text. And you put such a text in your i18n file:

#XMSG: Product with selected property is not available. {0}: property, {1}: product.
i18nProductNotAvailable = Sorry, the {0} {1} is not available.

You did a test in English and got the wanted message: “Sorry, the blue pen is not available”. Looks nice but finally you will know this approach cannot work in German at all. Check the wiki here and you will know the reason. If you find the wiki too long, maybe following example could help you to get a bit idea.

Do not Restrict User’s Input

When your application is only facing the English users, you could simply restrict user’s input data. For example, for the field “First Name” we only accept English letters and a few punctuations. But you should get rid of it when you want globalization.

Searching and Sorting is Not That Easy

Searching and sorting are very commonly used data processes. And normally they are taken into consideration when designing architecture of the backend service. So if you have realized the potential globalization issues in the designing process, maybe you’ll recieve less tickets about globalization.

Searching

For the searching function, normally will use the “is” or “contains” strategy. But both need to be adjusted when coming to another language. For example, in German the letter “ö” could also be expressed as “oe”. So if the user is searching for “Koepper”, both “Koepper” and “Köpper” should be in the results list. Luckily this feature is already enabled for some databases, you just need to remember to do the configuation.

Sorting

“Apple” should be always before “Banana” because “A” is before “B”. But what should be the correct order between “苹果” and “香蕉”? For a non-Chinese user this is a hard question. Normally a database could sort in different languages, but when you are designing your service please remember this part.

Good Comments are the Soul of I18n Files

Using comments is a good coding habit, especially in i18n files. Please remember that when a translator is translating your text, his only knowledge about this field is from your comment. For example the word “Order” could have different meanings:

  1. a sales order
  2. sequence
  3. command

And in other languages they might be translated into totally different words. How should a tranlator make his dicission without a comment? So start writing good comments in your i18n files from today, and you will get less troubles in the future. Following is the recommanded way to write comments in the product standard Globalization.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Rick Verbeek

    Great post! A lot of localization and globalization issues can be prevented using the right guidelines for internationalization. This saves a lot of time and money as well which would normally be spent on fixing these issues.

    Working for one of SAPs dedicated language service providers, I especially see the added value of using Pseudo (2Q) to identify which software texts have been externalized. For example: using 2Q and working together with product QEs at SAP has helped us bring the amount of language related errors in the Dutch version of SAP Leonardo IoT Bridge down to zero.

    Rick Verbeek / GlobalizeMe

    (0) 

Leave a Reply