How to Localize Software: 10 Dos and Don’ts for a Watertight Software Localization Process

ShareShare on Facebook6Share on LinkedIn191Tweet about this on TwitterShare on Google+2

Localization and translation are often considered one and the same, rather than complementary. But, while there’s some overlap between the two, the software localization process is much more complex. Adapting a product or content to a specific locale or market involves tweaking graphics, layouts, formatting, and everything between—not to mention satisfying other markets’ legal requirements, data compliance, device preferences, and technology trends.

With all the nuanced cultural considerations to think about, it’s easy to overlook elements that seem trivial, but play a crucial role in delivering a flawless product to the widest possible audience. So, where to begin? The following are key software localization best practices and pitfalls to be mindful of.

Do approach localization as a strategy.

First things first, it’s important to be clear about how software localization will support your holistic goals. Avoid localization failure by taking extra care in your requirements analysis and design phases, and ensure that all stakeholders are in agreement on target markets, languages, and issues unique to each.

Approach the software localization process as a strategy, not a task, for worldwide success. If you make global-readiness your goal, you’ll never have to re-engineer to take advantage of a market opportunity.

Don’t forget to design with localization in mind.

A localization-friendly design is one that helps to cut schedule delays and cost overruns. It features source code and structure that helps to prevent:

  • Replication of source bugs in target files
  • Avoidable translation errors
  • Common software localization errors, including functional, display, abbreviation, and over- and under-localization.

Tip: Use templates to ensure consistent brand presence. Need to ensure your design is localization-ready? Test, test again, and test some more. Pseudo-localization (a form of QA testing) is a useful process that helps to reduce risk by revealing potential translation problems, such as user interface (UI) layout issues caused by special characters or string length.

Do build a library of internationalized objects.

Remember: internationalization enables localization. Building a library of internationalized objects will spare you from rework as you resolve how to localize software into multiple languages. These include:

  • User interface design elements
  • Sort and search functionality
  • Multi-byte character support (for Asian languages)
  • Bi-directional or right-to-left support (Arabic & Hebrew languages)
  • Address, number, date, and currency formats.

Don’t make source text too long.

All languages have different sentence structures, different rules for pluralization, and use different amounts of words to express an idea. Minimize translation problems with clear and concise source content, which contains:

  • Brief sentences
  • Standard English word order, whenever possible
  • No phrases with many consecutive nouns (noun strings)
  • No synonyms; use one term to identify a single concept
  • No acronyms; they will need extra translation and lose any secondary meanings.

Tip: As well as avoiding synonyms, don’t “verb” your nouns. In other words, don’t reuse the same text in different context. Many words in the English language could be either a noun or a verb: for example, file, share, and design. Decide on a single use for text and use it consistently.

Do plan for text expansion.

The English language is estimated to consist of over 1,000,000 words, while most other languages have fewer than 500,000. So, when translated into other languages, English content strings are likely to expand or contract. For example, the English “Have a nice day!” is translated into German as “Ich wünsche Ihnen einen schönen Tag!”: a 125% length increase. Translating English to Asian languages has the opposite effect.

At the least, plan for 30-35% expansion—and consider white space use. Again, focus on keeping the source text short, and other software localization best practices related to formatting and word choice.

Don’t misuse icons.

Of course, software localization best practices aren’t only concerned with textual communication. Visuals, too, hold different connotations for different cultures. Icons—without text—are beneficial because they require less translation and can reduce cost. But remember that not all symbols are universal or neutral.

For example, a U.S.-style mailbox doesn’t translate to many other cultures. Do your research and avoid images of hands or feet, animals, and other symbols which can have unexpected or unwelcome meanings.

Do use UTF-8 encoding.

Most modern technologies default to UTF-8, the most popular format for Unicode. UTF-8 is described by Dr. Ken Lunde, a renowned information processing specialist, as “the world’s first intelligent character encoding.” Unicode is supported by all major hardware and software companies and is required by standards such as XML, Java, and Javascript. Using UTF-8 ensures easy and correct translation into all languages, especially Asian CJKV (Chinese, Japanese, Korean, and Vietnamese) languages.

Don’t hardcode text or punctuation.

Hardcoded text—or text embedded in source code—must be extracted for translation when you’re ready to localize. Your language service provider (LSP) can run a parser to identify translatable text, but you’re better off minimizing it at the design level. Instead, use separate resource files—for titles, product names, and error messages, for example—and resource commenting to eliminate translation errors.

Tip: It may be tempting to concatenate separate strings using placeholders, with hardcoded word or phrase order, to reduce the size of a string. But this often results in mistranslation and incorrectly localized strings, as word order and grammar rules vary from language to language. To solve this problem, simply avoid it at all costs.

Do consult with a localization expert.

Besides localization checklists provided for Android, iOS, and Windows development, your LSP can provide you with insights and optimized processes that will save you time, money, and rework. Consider specific questions for your provider before kickoff of your software localization process to ensure a successful working relationship.

Tip: Remember to provide your LSP with Do-Not-Translate (DNT) lists to prevent over- or under-localization. Both can impact code functionality if an incorrectly translated string has a critical function within the program.

Don’t just meet expectations—exceed them.

In the end, every little detail deserves careful attention. From the simplest mobile app to complex multi-user systems, localization is the key to driving software sales and acceptance.

Benchmark your efforts using the 80-20 rule of “glocalization,” or appealing to 80-20 ratio of global and local customer behaviors. By truly understanding local markets and incorporating cultural sensitivities into design and development, you won’t just meet users’ expectations; you’ll transform their experience. With software development that is global-ready by design, there’s no reason not to start unlocking global market opportunities.

To learn about how to localize software in more detail, get our free ebook The Developer’s Dozen: 12 Best Practices for Software Localization.

ShareShare on Facebook6Share on LinkedIn191Tweet about this on TwitterShare on Google+2