Software Localization Do’s and Don’ts
|
Font size:
We live in the digital era. With AI, web, mobile apps, and DApps becoming almost indispensable to our daily life, software localization has grown in importance for ensuring a unique user experience across regions and cultures.
Tech bigwigs like Airbnb, Uber, Google, and Apple know it first-hand. Wherever users are in the world, they can access their favourite services in their language and enjoy a meaningful experience and user journey matching their cultural expectations and habits. That’s where software localization comes in. But what is it, really? How do you do it right?
Software localization is a minute process requiring a fail-safe plan covering all the aspects of localization- from strategy to deployment and implementation. In this article, we break down the do’s and don’ts of software localization that every developer should know.
Do create a software localization strategy
Localization should be approached as a strategy, not a one-time task. Before thinking about UI design or app content localization, you should first lay down the goals that your software localization is supposed to cover – what you aim to achieve by adapting your software to another locale.
A successful software localization strategy should include:
● Creating a style guide
● Building a library of global-ready objects, such as date and number formats, addresses, and currency formats, multi-byte character support (especially for Asian languages), right-to-left alignment (for Arabic and Hebrew), search experience, user interface, RTL vs LTR languages
● Providing enough space for text expansion
● Using Unicode UTF-8 to accommodate special characters and language scripts effortlessly
● Translating & localizing your software content
● Revising, testing and fixing any translation or design issues (This is the QA phase!)
● Releasing your localized software product
To avoid costly localization blunders, exercise extra care and diligence in the quality assurance phase to ensure that all your project elements are in accord with your target market(s), languages, and aspects unique to each locale. Additionally, working with local engineers, marketers, and linguists will spare you the headache of re-engineering any of your elements (or even the whole project) to expand into a new market.
Don’t take UI design lightly
UI design is central to software localization. Taking a holistic approach to localized design will help you avoid delays and budget overruns.
A localization-ready design is one that prevents the replication of source file bugs in the target language. Including the source code and structure into your localized UI is the best practice. Also, using design templates and testing allows you to eliminate any localization errors, be they graphics mislocalizations or functionality, display or abbreviation errors.
Pseudo-localization is always a good way to QA your UI designs to see how your software will look after localization. A core part of the QA/revision process, pseudo-localization helps you identify and eliminate localization bugs.
For example, if you support 20 languages, chances are you will find at least one bug in each language. Consequently, you will have 20 new bugs in your target files. Pseudo-localization makes bug fixing easy. But how does it do that?
Simple. Instead of translating/localizing software content into the target language, it replaces the source-language text with an altered version. For example, “Account Settings” will become [!!! Àççôûñţ Šéţţîñĝš !!!] with pseudo-localization.
The beauty of pseudo-localization is that it fits effortlessly into the software development cycle, enabling engineering teams to test their localized UI as they go along. As this topic is vast and deserves special attention, we will cover it in more detail in a future article. So keep an eye on us, and let’s get on with our software localization do’s and don’ts.
Do create translation-friendly content
Creating translation-friendly content for your web or mobile apps is crucial if you want your localization to be successful. Avoiding jargon-free and colloquial language as much as possible will make translators’ work considerably easier and guarantee your project’s success.
But software is all tech, and tech is full of jargon. That’s where transcreation comes in. Specific terms are either adapted in the target language or borrowed (calque or loan translation) from English. This phenomenon explains the penetration into Polish and widespread usage of terms such as:
styl internetowy – Internet style
internetowa odmiana polszczyzny – Internet variety of Polish language
polszczyzna internetowa – Internet Polish
ęzyk polski używany w Internecie- Polish language used on the Internet
język internetowy- Internet language
język Internetu – language of the Internet, and
E-język – e-language
internetowa odmiana polszczyzny – Internet variety of Polish language
polszczyzna internetowa – Internet Polish
ęzyk polski używany w Internecie- Polish language used on the Internet
język internetowy- Internet language
język Internetu – language of the Internet, and
E-język – e-language
Do consider loan translations when localizing software-related content. It will help you minimise translation and localization problems.
Of course, each language works differently. Other languages may be less permissive or prone to lexical calques, such as the above (which should be included in your software localization style guide).
Ideally, your source text should be concise yet expressive. Remember, different languages have different grammar structures, use different pluralisation rules, number formats, etc.
Use standard language word order, and avoid humour, colloquialisms, and passive voice (ideally). Also, excessive use of synonymy may lead to confusion and mistranslation, which is why it’s best avoided.
Use of relative pronouns such as “that” and “which” is encouraged as it helps clarify the context. Lastly, use one-word substitutes for any phrases and phrasal verbs. Remember, not all languages are as creative as English in terms of phraseology. In other words, keep short, sweet and to the point.
Do allow space for text expansion
When localizing your software app, be language-conscious! Nothing makes a UI less attractive than misalignment or some random copy running over graphics or outside the text box.
To avoid this, allow enough space for text expansion. If your software’s language is English and you want to localize it to Spanish, French, Italian, and German, as shown above, you must be more generous when allocating copy space.
According to a language study counting the words in digitised books conducted by Harvard University and Google in 2010, English is estimated to have 1,022,000 words, a number expected to grow by 1,000 year-over-year.
Comparatively, other languages have less than 500,000 words. Therefore, strings may expand or contract when translating content from English to other languages, depending on how many words you need to use in the target language to express the same idea.
The English phrase, “Have a nice day!” translates to “Ich wunsche Ihnen einen schonen Tag!” in German, with an increase in text length of roughly 125%. In comparison, translating text to Asian languages results in a decrease in text length. This is why it’s best to allow for 30-35% text expansion when localizing software to other languages. Don’t forget the white space!
Don’t assume all icons are created equal
Software localization takes into consideration all elements of design and content. Speaking of design, icons are an important part of it. They guide users through. That’s why we love them because they make our experience seamless. But don’t assume they are universal or neutral.
For example, a US-style email symbol does not translate to other cultures. Do your research and best avoid symbols of hands, animals, and feet; they can have negative connotations.
Ideally, add a section with preferred icons and symbols to your software localization style guide (one of the first items on our to-do list).
Do use Unicode
Unicode character encoding can make your engineers’ and designers’ lives easier. Typically, all tech solutions today come with UTF-8 Unicode.
UTF-8 facilitates smooth and accurate translation into all languages, irrespective of script or use of special characters. That’s what made Dr Ken Lunde, a well-known information processing expert, qualify UTF-8 Unicode as “the world’s first intelligent character encoding.”
As a standard, Unicode is supported by XML, Java and Javascript. It proves utterly beneficial when localizing to Asian CJKV languages (i.e., Chinese, Japanese, Korean, Vietnamese).
Don’t hardcode text strings
Never hardcode text or punctuation, and never embed text in your source code. This will double the work of your engineers, who will have to extract it from the code and manually input each string into the translation system.
You can avoid this hassle by using individual files for every item, such as titles, product name(s), error messages, update notifications, etc.
Tempting as it may seem to use placeholders by including a hardcoded word or phrase as in the example below, it is a risky undertaking that often results in mistranslations and incorrectly localized strings due to the numerous differences between languages – grammar rules, sentence structure, punctuation rules, etc. So, just don’t do it!
Do talk to a software localization expert
You may know your product better than anyone. (After all, you created it, so how could you not?!) But do you also have the know-how to localize it to 10-20 languages or more?
An expert localization agency like Pangea Global can help you lift your software localization project off the ground. With over 600 translation professionals and IT industry insiders well-accustomed to the habits and cultural norms of the regions they translate and localize for, we are your partner in need if you’re looking to expand your market share. Contact us today to launch your products as early as tomorrow.
