If the answer is: “everyone knows English”, you might be leaving a lot of money on the table. Competing in a global market requires maximum efforts on improving user experience to establish a reputation and localization is a must. 😎
"More than 75% of the global population doesn't speak any English at all!" 📚 Mythbusters: Our users speak English, so we don’t have to localize
Opting for software localization is only halfway to successfully expanding your market reach because localization itself is challenging. It's usually a tedious process to get everything localized correctly. And it never ends - as the project evolves, new texts appear, outdated texts change or are deleted so being in control of everything without a localization suite such as Localazy is even harder.
That's why have prepared a list of seven software localization mistakes that you can avoid before diving into the world of localization, translation, and continuous improvements with Localazy.
❌ 1. Not Separating Text from Images
Not unnecessarily, they say that one picture is worth a thousand words. If we were to take this literally, images could save thousands of words, lowering the costs of translations dramatically. 😁
Images add clarity to your product and make it visually more captivating. What’s even more helpful are images with text. Even though it happens that images containing text could pose difficulties for translators and they could ask for extra budget and time.
Hence, what advice is applicable in these cases? Text extraction. Extracting text from an image assists in creating a localized version of your software that’s easier to manage and work with. Detach the text and present it as a separate component. Also, pay attention to the compatibility of the text with the accompanying image across languages. 🕵️♂️
Learn how the Figma Localization Plugin by Localazy can help you translate texts in your images and even whole designs correctly and seamlessly.
❌ 2. Not Specifying the Exact Locale
Localization is all about adapting your message to the native culture of users. Knowing what language they speak is simply not enough. Even though the same language is spoken in multiple countries, each of them uses different notions that cause huge misconceptions. 😓
Let’s say that you’re localizing a food-related app. A British person would ‘have a cookie’ while an American would ‘eat a cookie.’ 🍪
Small cultural nuances weaken or strengthen a statement. Another example would be athletic shoes. In Canada, you can refer to them as runners, while in the United States you’ll have to say running shoes, tennis shoes, or cross-trainers to be understood. 👟
Being precise pays. Considering it from a marketing point of view, a negatively ambiguous term could cause sales or app downloads to decline. Instead, use a full locale property to serve each dialect. Locales contain the country code along with the language name.
For instance, English in 🎡 Great Britain, 🦘 Australia, 🍁 Canada, and the 🗽 United States would be written respectively: en-GB, en-AU, en-CA, and en-US. Offering such options helps you customize features of your app or software such as data formats, spelling, and nuanced phrases among demographics where the same language is spoken. 👨💻
❌ 3. Not Clarifying the Context
When translating and localizing, context is everything. It’s what separates human translation from machine translation. Keep this in mind while providing translators with your content. Strings used in specific contexts will get translators confused unless you provide 💬 comments, 🖼️ screenshots, and other 📖 artifacts (style guide, glossary, documentation, etc.) that will help them navigate through the various strings.
Style guide and Glossary are essential for providing a basic understanding of the project and different terms, but sometimes might not be enough. Enrich your localization notes with comments and alternate phrases, and give as much context as possible for text and the formats besides which it’s used.
Learn How to prepare a style guide for localization of your project
Even when using old-school tools such as spreadsheets 🤭 to manage to work on content with translators, adding a column for context notes helps. If space allows, include screenshots as well. Context is the key to producing localized content that hits the point.
Read the 12 Reasons Why Localazy is Better Than Spreadsheets for Localization Projects
If you don’t provide translators with guiding comments, chances are that you’ll get a translation to be frowned upon. If you’re translating an Android app, for example, being able to leave comments in the process avoids misunderstandings.
❌ 4. Not Separating Text from Code
Translation requires focus and clarity. If the translator has to struggle to find the content that needs translation because it’s stuffed somewhere within the source code, it will be difficult to maintain the quality and get results in a timely manner.
Considering the extended amount of hours needed to finish a task, the translator might lose efficiency while increasing the project costs. 💰
If the localizable content is stored in multiple variables across the codebase, it presents challenges to version control, and you might miss some texts entirely while preparing the content for translation. Instead, take time to extract this text into dedicated files. These resource files should maintain all of the app or software’s content. Examples include error messages, titles, or product/packages names.
Paste these translatable strings into resource files by assigning each a specific name, in form of a key to identify them. Remember to put unique IDs that are descriptive, and show the use of text (title, paragraph, button label, etc.). ☑️
Resource files can be created in different formats depending on the framework or programming language used. JSON, YAML, PO, and XLIFF/XML are some of the most used ones at the moment but always search for the most advantageous option that is suitable for your project.
❌ 5. Forgetting different translations lengths
When thinking of translation and localization, don’t center interface formats around English. Not every language comes with the same flexibility and succinctness as English. Compared to languages like Finnish or German, it might be quite compact at times, which signifies a noticeable difference in text density and length.
Imagine what a mess would it be if texts began overlapping and stretching outside of the interface causing extra work for the developer and requiring complex and expensive solutions? Therefore, it’s smart to consider this before sending your content for translation.
To avoid these awkward interface mistakes, leave room for buttons, banners, and menu options to shrink and grow. An adjustable interface accommodates text of various lengths with ease. Layout managers function well for adjusting the interface elements accordingly by relying on the features of each locale and the pixel positioning of widgets at runtime. While most of the work will be through files, it’s advisable to save the dimensions of labels on resource files.
❌ 6. Not supporting Unicode
Programming languages use their encoding system by default to save files. If your translation strings are handled by a data type that does not work well with Unicode, but you save a file with a different encoding, the localized content might come out distorted.
Chinese and English for example use two dissimilar character encoding standards for encoding content. For a website with an English-based server, receiving traffic to its Chinese content could result in the corruption of the characters since encoding differs.
Standardizing encoding all across your platforms saves unnecessary headaches. This is why most developers suggest implementing UTF-8 on servers and browsers, including several layers, such as HTML, database, HTTP server, and the software or application. Only Asian Languages require UTF-16 encoding.
❌ 7. Not considering vertical and RTL languages
Besides encoding and string lengths, we shouldn’t forget the text directions. Languages such as Hebrew, Arabic, Urdu are written in the right-to-left format while others such as Chinese, Vietnamese, or Korean are written vertically.
Having a detailed list of languages in mind before designing your software or application will help you estimate the nature of its interface. If this list includes languages that are written in more than one direction discuss it with your developer. 🤔
Different directions require different string placements. Vertical writing organizes strings one under the other rather than being rotated by 90 degrees. For solving this issue, create multiple stylesheets based on letters' directions which can be triggered by a direction string on the file.
✅ Conclusion
Localizing a product or service requires a lot of effort, the right professionals, and most importantly, the proper translation management software to make localization easier. Avoiding common mistakes is the first step toward quality multilingual content. 😉
At Localazy, we offer a diverse number of tools and integrations which make possible the adaptation of content into multiple languages. Thanks to the easy-to-use interface you can translate your app, software, or website with minimal mistakes into 80+ languages. Sign up today!
📚 Further Reading
This is a companion discussion topic for the original entry at https://localazy.com/blog/stop-making-7-software-localization-mistakes