It’s easy to look for shortcuts to save time and money when internationalizing software. Unfortunately, those shortcuts can lead to delays and unplanned expenses when software doesn’t work as expected, or in some cases, isn’t usable.
Assuming everyone understands English, internationalizing later when it’s time to expand into new markets, and skipping testing software in multiple languages are common pitfalls when justifying shortcuts. The savings they seem to offer are illusions because the cost to address them can be hundreds of times higher than finding and fixing them before shipping. Instead of looking for shortcuts, companies should use automation to streamline the software internationalization process.
Internationalization, or i18n, makes software capable of being localized so it appears as a native language app for users based on their locale. Even if a company isn’t doing business in multiple languages today, expanding into new regions later will require multilingual support. Planning for that now — and knowing how to recognize potentially expensive shortcuts — puts businesses in a stronger position to successfully compete when they make the move into new markets.
English Isn’t the Only Language
English may be seen as a “universal language,” but that doesn’t mean it’s the only language your software should support. In fact, limiting software to just English also means deciding which locale to support because English isn’t exactly the same everywhere. Spellings, word meanings, and number formatting, for example, aren’t consistent everywhere English is spoken.
While it may be common, English isn’t the native language for most of the world. Offering users software interfaces that support their native language and locale make for an overall better experience, create a first-class experience, and builds loyalty by making customers feel like they’re important enough to warrant a product developed for them.
Software that supports formatting for the user’s locale helps reduce the likelihood they’ll misunderstand word meanings and numbers. How commas and decimal points are used in numbers varies around the world, currencies vary by country, and measurement standards aren’t universal. Expecting users to understand number formats they aren’t familiar with, and to convert money and measurements themselves, leads to confusion, frustration, and possibly customers who leave to find an easier solution from other companies.
Don’t Skip Unicode Support
Unicode is a standard font format that can contain characters for a wide range of languages. Supporting Unicode in an application’s code is a key part of internationalization and localization (or l10n) because it’s a necessary element in translating text into different languages. Without Unicode, developers would be faced with a figurative brick wall preventing them from including i18n support in their code.
Lingoport CEO Adam Asnes says incorporating Unicode early in the development process is a good idea. “I like to recommend that people take on Unicode as early as possible. Most every modern database and programming language offers Unicode support,” he said.
Waiting until it’s time to expand into new countries before adding Unicode support costs significantly more than building it in during initial development. The time the dev team spends reworking code for Unicode takes away from new features they could be working on, and increases the risk of introducing new bugs that have to be tracked down and fixed.
Supporting double-byte Unicode is important, too, for software that’s being localized in languages with complex scripts such as Arabic, simplified and traditional Chinese, Hebrew, Japanese, and Cyrillic languages like Russian.
Arabic and Hebrew are Bi-directional Languages
Arabic and Hebrew are read primarily from right to left, which requires bi-directional language support when localizing. Interface elements such as menus can still progress from left to right, but the language content they show must display from right to left. Supporting the correct reading direction without breaking any interface elements is important for ensuring software is readable in these languages.
Internationalize Everywhere
Localizing only some parts of a project — like user-facing elements, but skipping administrative interfaces — leaves software feeling incomplete and looks unfinished and unprofessional. Customers responsible for using the non-localized elements may not understand the language well enough to effectively navigate the interface, or understand prompts and other dialogs.
Test in Every Language Your Software Supports
Testing internationalized software in only one language won’t reveal problems that appear for users in other locales. If software that supports i18n has been localized for English, German, and Japanese, for example, it needs to be tested in all three languages. Testing software or updates only in English doesn’t reveal problems that show up in other languages.
Lingoport’s Localyzer can provide pseudo-localization so that developers and QA personnel who likely don’t speak all target languages, can still test for basic U/I functionality. Pseudo-localization creates a locale that uses the English or source language and pads and expands strings/messages so that team members can see if a string is being cut off, or not externalized. It’s not a complete i18n check method, but it is effective and useful.
Tools like Globalyzer can help by identifying i18n bugs before localization starts. Localyzer QA helps streamline l10n testing by showing text in the actual user interface so reviewers can quickly tag language changes and submit them for approval. Without testing, there isn’t any way to know if software is coded correctly.
Internationalization is an Ongoing Process
Internationalization isn’t a code assignment that’s added during a development sprint. It’s an integral part of the development process that starts during the pre-release coding phase and continues through new feature updates and bug patches. All code changes need to be made with internationalization in mind. Instead of thinking of i18n as a software feature, look at it as part of the application’s foundation.
Globalyzer makes that process much easier by automatically monitoring code for i18n-related problems. It works as part of the developer’s IDE so they can see issues without having to sift through hundreds or thousands of lines of code. Globalyzer acts like an assistant scanning for potential problems so the dev team can focus on coding.
Design with Empathy
Imagine, as a native English speaker, encountering a menu, dialog, or other interface element in German. If the lack of localization would be a problem for you, then it’s a good bet that failing to include i18n support throughout the product will be a problem for users, too. Thinking about user’s needs and potential pain points during development makes it easier to spot places where internationalization and localization aren’t adequately supported.
Resources to Learn More
Phasing Software i18n and L10n: What’s Right for Your Company?
While looking for shortcuts to internationalization may be tempting, that can lead to skipping important steps in the process, and cause unnecessary delays when dev teams have to add support later or fix bugs that were missed before shipping. Preparing software for internationalization as early as possible in the development process is the real shortcut to successful i18n support.
