Poor Context
Imagine a situation: you go to a neighboring country where the language is very similar to yours. You understand a lot of what the people are saying by using context clues to get the meaning. For example, you hear someone saying a phrase where you understand some words and place them into the conversation’s context.
That’s kind of how translators work to localize software and website copy. They receive texts in spreadsheets containing software strings and need to decipher the meaning of specific parts without having a clear context. To do so, they need to overcome these localization issues,
- Finding and separating strings with dialogues etc.
- Understanding the context of conversations and connection between content parts
- Providing a clear order to text strings.
Here’s a simple example of a game localization spreadsheet to give you an idea.
|
STRING ID
|
SOURCE TEXT
|
|
goal_12_start
|
Have a quick meal.
|
|
goal_12_ongoing
|
Turn on the stove
|
|
goal_12_done
|
Ken is now ready for school now.
|
Have you been able to get the meaning from the context? Now, imagine there’re thousands of these with much longer sentences.
Hard-Coding Locale-Based Keyboards
Website and software localization isn’t limited to the translation of the copy. Currencies, dates, times, measurement systems - localization experts should consider these to ensure that the final version makes sense to the target user.
Hard-coding them is the worst thing that can be done here. If hard-coded, the final text version would be just weird to readers.
A better idea is to use localizable strings and leave localization experts to do their job. For example, go for a standard ISO format to store these keywords and make a Python library for conversion.
- from trados.dates import format_currency
- from trados.numbers import format_datetime
- print(format_datetime(locale='ja_JP'))
- 2020年11月17日 (水) 11:48:08
- print(format_currency(12.80, 'EUR', locale='fr_FR'))
- # 12,80 €
- print(format_currency(12.80, 'USD', locale='en_US'))
- # US$12.80
Not Using Bug Management Systems
A check for bugs in software or website copy localization can reveal many bugs,
- Missing translation
- Overlocalization (localization of elements that should be left in the original form)
- Inconsistent terminology
- Missing text
- UI issues (see example below).
A common website UI issue is not enough room for copy.
To find and resolve these issues, localization experts employ either a bug tracking system or translation management system (TMS).
Undertranslation
Undertranslation means that a lack of a complete translation of the user-visible language as well as the adaptation of items like hotkeys. For example, an app might have a localized interface but the Help files remain in the original language.
Recently, we’ve seen a tendency to provide localization where a professional uses a series of electronic tools like translation memories and software powered by machine translation technology. This approach, although effective for quick translation, is not suitable for localization.
Broken Character Encoding
Localization testing tools typically find this issue during internationalization readiness check.
Broken character encoding happens when a software or a website doesn’t recognize language characters. A good example here would be a software which, if changed to a Vietnamese locale, displays squares and other characters instead of letters.
That’s why having a clear plan to translate the texts into other languages from the onset is one of the software localization best practices.
Data and Time Formatting
A small issue that causes a lot of problems for users. If the software product or a website doesn’t support local characters of date and time - it won’t be user-friendly, to say the least.
For example,
- A UK-based user might be confused that an app’s settings have Monday as the start of the week
- Displaying dates in the European format - dd-mm-yyyy - would be confusing for U.S.-based users who prefer the mm-dd-yyyy format.
Take a look at
DateTime class in C# to know how to represent different formats and avoid many localization issues.
Font Affairs
Incorrect font size and type is an issue that hurts the user experience. Often found during a layout check in different platforms and browsers, it means that the software doesn’t support fonts.
If a special character, say one from an Arabic or a Cyrillic-based alphabet, is not available in software’s fonts, it won’t be displayed correctly on the screen. As a result, some troubles with navigating and using the product might occur.
To prevent this issue, add special characters to the fonts before starting localization. One can make a list of the fonts to ensure that all fonts are there. Moreover, keep in mind that the translated copy is almost always at 25 percent larger than the original, so don’t pick fonts that are either too small or too large.
Save Yourself a Lot of Trouble
If you know and work on these localization issues beforehand, you’ll avoid a lot of trouble like reworking the whole thing to support other languages. That’s why following software localization best practices is a must to create the best possible user experience for people from all over the world.
Hopefully, this information will help your localization process to be more organized and effective in finding and preventing mistakes.
Mahesh ChandPosted Apr 10, 2020, 8:39 AM
Thank you, Mark for sharing your wisdom. Welcome to C# Corner community.