Typical localization of bugs

Question

We are now adding support for German, Spanish, French, Italian to our application. We've translated all strings and added a big margin for them in the UI. Now I am wondering what kind of bugs to expect besides the obvious translation, text and clipping bugs.

From what I've read, sorting strings, displaying dates, floating number formats all depend on the locale. I assume there are other things as well.

Which bugs should I expect and test for?

Answer 1

Some of the things I've run into:

• Currency formats are locale dependent.
• You can also have issues with different locale-based keyboards. I've seen issues where a problem only occurs when the language and the keyboard are configured for a specific locale (this was Turkish language and Turkish keyboard).
• For German, you'll want to watch your line breaks - German tends to concatenate words so you get very long words that can completely mangle the overall layout.
• If your application uses a database, you want to make sure the database collation doesn't do anything horrible to the non-ASCII characters the language uses.
• You also need to make sure that you specify the Unicode format you're working with if there are any exports/imports involved.
• This isn't as likely with French, German, Spanish, or Italian, but check that there's nowhere in the application that renders the strings as images (I ran into this with Japanese). Image renders for ASCII characters are generally smaller than those outside the ASCII character set, which can cause unusual errors.

Answer 2

We got burned by a limited input field for income. Because I live in germany, values up to 100000 € where perfectly ok for our testers. But the website got translated for countries like russia, where 100000 rubel is not really much....

Answer 3

You can save yourself a lot of time by knowing more about your application.

First, many of the issues dealing with currency formats, number formats, measurement system, long and short date formats, long and short time formats, calendar, first day of week, and also sort order are handled by the operating system if the developer is utilizing the OS APIs (which is likely) instead of writing functions to handle this functionality. If this is the case, then you can reduce (not eliminate) test coverage. (BTW...we refer to this type of functionality as globalization testing at MS.) The same is true for data handling assuming the app is written to support Unicode and your devs haven't been living in a cave for the past 20 years or for some bizarre reason thunk to the ancient ANSI character code page model. :-)

As for localization testing specifically (modifying a program for a specific international market) so issues to look for include

1. string expansion - esp in German. Typically allow for @35% more chars
2. Hard coded strings in the code (that are not translated)
3. Concatenated strings in the code (that cause the ordering of translated string not to make sense)
4. Key mnemonics mapped to native characters on the keyboard that don't work (both accelerator keys and shortcut keys)
5. UI layout (often changes due to resizing of labels for text.
6. some apps might need specific drivers or libs for your target market (locale)
7. If you have help files, don't forget to look at that
8. If you have web links make sure they also point to the appropriate location (esp. if those pages are localized)
9. Of course there could be issues with the "quality" of the translation. If this is a concern I would recommend partnering with native speakers in-country to look at the translation much the way an editor would review a book or article. Problems with translation sometimes occur because the translator doesn't understand the context in which a string is used. Providing bitmaps of various windows/dialogs can help translators understand the context of the strings.

Answer 4

Typical bugs which described in many qa forums are:

• text expansion, resulting in truncated strings
• GUI alterations, resulting in overlaps of GUI elements and controls or their misalignment
• automatic hotkeys assignment, resulting in duplicated hotkey
• hard-coded strings, resulting in untranslated strings
• unsupported code pages, resulting in garbage
• missing or extra controls, resulting in missing or broken functionality

I suggest you to read this article, well explained: http://www.moravia.com/files/download/Best_Practices_in_Localization_Testing.pdf

Answer 5

This may be something you consider "obvious", but given that it's the single most common translation problem we have, I think it's important to mention. It's less a bug, and more something that gets completely overlooked: Words often aren't used in the same order as the base language.

For example: Say you want to translate Welcome, [name]. The naive approach is to simply translate "Welcome," and slap them together in the code, trans("Welcome,") + username - this is not correct, since some languages won't use that pattern.

It should instead be something like this, to borrow Python syntax:

trans("Welcome, %(name)s") % {'name': username}

This requires the translators to understand that %(name)s is a placeholder and must be kept. But it allows them to be a whole lot more flexible in the languages that use a different syntax. For example, the above translation in Japanese would be (according to Google Translate):

ようこそ、%(name)sに

Surprise! There's an extra character at the end that European languages don't use, that couldn't have been added using the naive code.

I don't know if the European languages listed in the question have similar issues (although in a more complex example, I could see the Latin-based languages being different than the Germanic ones), so this might not directly apply to the OP - but should still be helpful to others.

Answer 6

Currency formats: Make sure that the currency format actually matches the currency that you are talking about! If I tell you that I had a $500 hotel bill in New York, and you translate that into German, changing the $500 bill to €500 would be a very bad idea. Translating to 500 Yen might be harmless because the Japanese readers will know that the number cannot be right.

Make sure that things don't get translated that shouldn't be translated. Strings that actually are part of the code. If you translate your database keys, you are going to be in trouble.

Context dependent translation: A key on a keyboard is different from a key used to unlock a door or a music key like C-flat. If you translate the word "key" once your users might be either very confused or have a good laugh at your expense.

Plurals are fun. In English: 0 items, 1 item, 2 items and so on. Rules are different in different languages. Best avoid this :-)

Answer 7

These days I fix localization bugs every day for an Android app.

The most common error I encounter is corrupted keywords/variables.
Examples:

• <![CDATA[ becomes <![CDATA [
• %2$d%%\n becomes %2$d％%\n

This is made worse by pre-translation software, which uses Google Translate or equivalent to provide a first shot for the translator to improve. Such software corrupts variables very often.

Note: variables are needed to translate things like "You have 3 talismans": (English) You have %NUMBER %OBJECT (Japanese) 君は%OBJECTを%NUMBER個持ってる ... and that's even more complicated when considering how plurals and grammar differ in each language. That's why variables are needed.

The problem could be fixed by improving the translation platform, or by training the translators, both of which is not easy as we are an Open Source project using a third-party crowdsourced translation platform.

Answer 8

To avoid a lot of problems, ensure the entire application tier from the web layer to the database uses the UTF-8 character set exclusively.

On a related note, ensure Server times and all references thereof (storage, etc) are done using GMT (UTC+0). Otherwise overlaps in daylight savings times, localized references etc will likely corrupt time-stamps, logic, etc. Only at the client side can date/time then be converted to the local time-zone/locale.

Check for input/output consistency (is what the user entered, in any language, actually displayed).

Make sure the translations are done by locals. The Chevrolet Nova (which in English means "exploding star") in Spanish means "No Go" (true story of a marketing disaster).

Check search-engine results. Stemming especially is always language-specific and can result in very strange results when English is assumed.