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 effort to improve user experience and establish a reputation, and localization is necessary. 😎
"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 half of the journey to successfully expand 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 and outdated texts change or are deleted, so being in control of everything without a localization suite such as Localazy is even harder.
We 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, dramatically lowering the costs of translations. 😁
Images add clarity to your product and make it more visually captivating. What’s even more helpful are images with text. However, images containing text can 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 uses different notions that cause huge misconceptions. 😓
Let’s say that you’re localizing a food-related app. A British person would ‘have a biscuit’ 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 or tennis shoes 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. 👨💻
./locales/en_CA/LC_MESSAGES/messages.po
messageid "login_message"
messagestr "How ya doin’?!"
./locales/en_AU/LC_MESSAGES/messages.po
messageid "login_message"
messagestr "How are you going?!"❌ 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.
A solid style guide and a glossary are essential for a basic understanding of the project and its different terms, but sometimes they might not be enough. Enrich your localization notes with comments and alternate phrases, and give as much context as possible for the text and the formats.
✍️ Learn: How to prepare a style guide for localizing your project
Context is the key to producing localized content that hits the right spot. 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.
📖 Read the 12 reasons why Localazy is better than spreadsheets for localization projects
If you don’t provide translators with guiding comments, the 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 challenging 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. 💰
Suppose the localizable content is stored in multiple variables across the codebase. In that case, 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 the form of a key to identify them. Remember to choose 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, but always search for the most advantageous option suitable for your project.
❌ 5. Ignoring different translation lengths 🔗
When thinking of translation and localization, don’t center interface formats around English. Not every language has the same flexibility and succinctness. Compared to languages like Finnish or German, English might be quite compact at times, which signifies a noticeable difference in text density and length.
Imagine what a mess it would 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 wise 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. A responsive 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 save files using their encoding system by default. 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. Since the encoding differs, a website with an English-based server receiving traffic to its Chinese content could corrupt the characters.
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 text directionality 🔗
Besides encoding and string lengths, we shouldn’t forget about text directionality. Languages such as Hebrew, Arabic, and Urdu are written in the right-to-left format, and some of them are bidirectional, which requires implementing BiDi support to display them correctly.
Having a detailed list of languages in mind before designing your software or application will help you estimate the nature of its interface. If the list includes languages written in multiple directions, discuss this with your developer to make sure the user experience is equal for every language.
✅ 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 towards quality multilingual content. 😉
At Localazy, we offer a variety of tools and integrations that allow content adaptation into multiple languages. Thanks to the easy-to-use interface, you can translate your app, software, or website with minimal mistakes into 80+ languages. Register today and try it for free.
