What Is Internationalization (i18n) and What Is i18n Testing?
Are you ready to take your software global? Internationalization and localization can be stumbling blocks for development teams given all their demands. But with good continuous systems and practices, the challenges can be met without a drag on new feature development.
Internationalization, also known as i18n, enables support for delivering a user experience in multiple languages, regional preferences, and cultural contexts. It involves capabilities like separating locale and language-dependent elements from the core code or content so that the code can support the requirements of a broader, global audience.
Since creating unique software versions for individual markets is impractical and cost-prohibitive, developers rely on internationalization to make supporting multiple languages and locales with a single code base easier. Developing software with internationalization in mind makes it much more cost-effective to support multiple languages, saves time during the development process, and makes it easier to add support for additional regions later.
Internationalization can be time-consuming and challenging particularly for a legacy code base—from trying to find specific places with broken code to understanding how to adapt the code. It is easy to miss aspects and locale behaviors. However, internationalization is necessary to adapt software, and if managed early and continuously in the development process, it can be done efficiently and proactively. Read on to learn more about internationalization.
In this article, we'll talk about:
Key Definitions
Before we take a deep dive into internationalization testing, we’ll define three key terms in the process of developing software for other languages and cultures, and then we’ll explain how they’re different but work together.
Globalization is the process of designing and developing a software product that functions in multiple countries and languages. It’s sometimes referred to as g11n, as 11 letters are between the “g” and the “n”:
g11n (g + lobalizatio + n)
Example: Amazon—you can buy products in multiple languages worldwide.
Internationalization is the process of making code world-ready to be localized to a specific region and language. It’s sometimes referred to as i18n, as 18 letters are between the “I” and the “n”:
i18n (i+ nternationalizatio + n)
Example: Ensuring the code behind all the form fields needed to purchase a product from Amazon (e.g., phone numbers, currency, address block, etc.) are adapted for other languages and cultures.
Localization is the process of adapting the application content to meet the language, culture, and other requirements of a specific target market. It’s sometimes referred to as l10n, as ten letters are between the “I” and the “n”:
l10n (L + ocalizatio + n)
Example: Properly translating and localizing content (e.g., product descriptions, video captions, reviews, etc.) into Amazon’s product pages and purchasing process.
Internationalizing software leads to a higher-quality product that should provide a seamless user experience. In addition, identifying issues early on in the software development process will save time, money, and resources in the long-run and make adding more languages easier.
Key Points
Software localization is dependent on internationalization.
Bad Internationalization = Bad Localization = Increased Cost and Time
Internationalization Issues: The Basics
Internationalization (i18n) is the process of preparing software to support local languages and cultural settings for other markets. An internationalized product supports the requirements of local markets worldwide, functioning more appropriately based on local norms, and better meeting in-country user expectations. i18n is product development-focused—not to be confused with localization, which involves translating and adapting content to cultures.
In this section, we’ll discuss issues that developers may encounter when preparing software for internationalization.
| Issue | Explanation |
| Locale—not just language | Language is dependent on locale. Even English has variations dependent on locale: British English, Australian English, Canadian English, etc. Some of the differences that will affect i18n include units of measurement (metric system) and currency. Developers need to create logic for locale negotiations and build missing frameworks for loading local resources and requirements. |
| Embedded strings | Translators can’t access embedded strings; they need to be moved to resource files so translators can access them. |
| Concatenations | The word order is different for different languages. In English, words are in S-V-O order, like this: In Japanese, the words are in S-O-V order, like this: You have to refactor software code where concatenations are used or else the phrase or sentence will be incorrect. |
| Formatting—numbers, names, addresses, dates, time of day, currencies, and much more | Many types of data must adapt to locale-specific coding requirements. For example, a date in German goes by day/month/year and uses periods instead of slashes. English: 6/28/23 German: 28.6.23 Currencies also vary. For example, Canadian French puts the dollar sign at the end of the amount and uses a comma instead of a period. Here’s an example: Canadian English: $123.45 Canadian French: 123,45$ |
| Character encoding support | Software should standardize on the Unicode standard to be able to support other languages. |
| Fonts | Some fonts will not produce clear readable characters, or good word spacing, in particular languages, i.e., Chinese ideographs. Hard-coded font choices in particular are limiting and should not be used. Some languages, like Arabic and Hebrew, are bi-directional languages. In bi-directional languages, the content is read from right to left, with proper English terms or numbers reading left to right. |
Internationalization Issues: A Deep Dive
Now that we’ve covered the basics, let’s dive into i18n. We’ll take a look at the four main components:
- Pseudo-Localization
- Static Analysis
- Localization File Issues
- In-Country Localization Review
Pseudo-Localization is one of the approaches to i18n testing.
What Is Pseudo-Localization?
Pseudo-Localization is the process of simulating languages in resource files without actually adding the whole
translation. The goal is to identify and address any potential issues related to languages early on in the software
development cycle. Issues may include things like:
- Truncated strings
- Embedded strings
- Text expansion
- Character encoding
- Text concatenation
- Other UI issues
Since pseudo-localization replaces text with test characters to find internationalization issues, developers can make
adjustments before the actual translation process begins, making the process go more smoothly, saving time, and
eliminating coding rework.
How Pseudo-Localization Works
Run the pseudo-localization version, using the Esperanto locale in locale settings. Have pseudo-localization always
update with each build.
Examples
We helped one of our clients with pseudo-localization, and here’s an example of some of the results. This is a
screenshot of text with the browser locale set to Esperanto.
You can see that the text “Connect Generations” comprises “padded” characters. These padded characters represent
characters from other languages.
This table shows additional pseudo-localization results that aren’t quite as obvious: four failed strings and one that
passed.
Benefits of Pseudo-Localization
Some of the benefits of pseudo-localization are that developers:
- Can see embedded strings and concatenations.
- May be able to see and recognize some formatting issues.
- Can see text expansion for languages that require more UI space (e.g., German).
Challenges of Pseudo-Localization
Although pseudo-localization is an effective way to catch errors early on, it has challenges:
- Although developers can see an error, the error doesn’t connect to that part of the code.
- Pseudo-localization won’t catch all i18n issues.
Localyzer: Our Solution for Pseudo-Localization
One feature of our Localyzer software is it automatically and continuously retrieves strings from your software
repositories and tests them for pseudo-localization rules. Whenever someone adds a string to a resource file, Localyzer
will automatically recognize that string and perform pseudo-localization. An email alert sends the result, and the
dashboard confirms the pseudolocalization update. The developer then runs the application using the Esperanto locale and
can see the UI with text expansion and character set support verified. Here’s a snapshot of the Localyzer dashboard.
Learn more about Localyzer.
Static analysis is another approach to i18n testing.
What Is Static Analysis?
Static analysis is a software development practice that examines code at the source level during ongoing development without running the software like during testing. The static analysis process can be integrated into the software development process and used to identify issues that can be difficult to discover during testing and to measure coding quality. It looks at things like code structure, syntax, security vulnerabilities, performance bottlenecks, and compliance violations.
Static analysis can be used to detect and highlight internationalization issues in the source code. For example, it can find code sections that impede or complicate localization and adaptation of the software for other languages, such as:
- Hard-coded strings
- String concatenation
- Formatting and localization-sensitive methods, such as, numerical, time, and date formats
- Character encoding and Unicode handling
- Locale-limiting static files and programming patterns
How Static Analysis Works
You can run static analysis tools to scan the source code for specific things in the
code by setting up rules in the tools.
Benefits of Static Analysis
Some of the benefits of static analysis are that you can:
- Find i18n issues that using pseudo localization alone won’t cover.
- Find i18n issues as the developer is writing code.
- Get precise details quickly on where an issue is and help on how to fix it.
- See it in the developers working environment (IDE), their commits (like saving), and pull request reports (submitting to the team).
- Run it automatically, so a developer doesn’t have to remember.
- Avoid the costly cycle of gathering screenshots of errors, logging bugs, assigning, fixing, and verifying.
- Have the developers focus on developing, not including bugs that may not be in their assigned code.
- Analyze broader repositories for applications.
- Follow a repeatable and scalable process for the entire company.
Challenges of Static Analysis
Static analysis can be fine-tuned and adjusted for sensitivity to avoid too many false positive results. It’s crucial to establish a feedback loop to continuously refine the findings as the developer encounters issues.
Globalyzer: Our Solution for Static Analysis
Our Globalyzer solution lets developers see i18n issues in the development environment as they write code. It displays exactly where the bugs are in the developer IDEs, so developers can quickly fix the issues before the strings even go to localization. Developers can track their progress through Globalyzer’s dashboard. Globalyzer also can display detected issues in commit and pull request reports. Here’s an example of an embedded string issue.
Learn more about Globalyzer on our product page.
Some internationalization bugs are in a gray area that could be called localization. These have to do with resource files that are sent for translation. Examples include:
- Duplicate string IDs
- A missing formatting element, such as a curly bracket
- A translated string parameter
How Checking Localization Files Works
In a typical manual localization process, developers extract the software strings from the source code or resource files, package them up, send them to translation, integrate them back into the code after translation, and then test them. This type of process requires a lot of manual, detailed work, which is prone to error and delays.Localyzer Solution
Localyzer is a tool that connects and manages localization from software repositories automatically. Localyzer retrieves software strings for translation and passes them back from translation.
One of the key features of Localyzer is that it doesn’t just automatically accept the files from translation—it makes sure that the files are error-free, so you won’t experience issues further down the process.
Localyzer performs a 45-point file verification covering all kinds of issues including:
- Duplicate string IDs
- Missing curly bracket(s)
- Improper file formats (can be transformed)
- Incorrect use of ICU
- Date formatting
- File too big
- Character encoding
- No key
- No text
- Argument mismatch
You can view and track the issues from Localyzer’s dashboard:
As we talked about earlier, Localyzer also automatically creates a pseudo-localized version of the application with every update. This lets the developer and testers see their work in multiple languages. Again, visual feedback is extremely useful, and using machines means no delay due to human translation.
Another feature of Localyzer is that it can connect to your translation repository, whether that’s a translation management system, custom translation engine, machine translation, a localization company’s portal, or others. After translation, the in-country reviewers can review the content via the translation repository using LocalyzerQA. This saves time and effort by eliminating manual processes of managing and synchronizing files that can introduce errors.
Learn more about Localyzer on our product page.
What Is an In-Country Localization Review?
An in-country review is a QA step to validate the translation. In-country reviewers (ICRs) from within the target market review the application. ICRs are usually employees or distributors of your products who speak the target language, reside within the target country, and understand your business needs and goals.How an In-Country Review Works
The review process is typically done manually by taking screenshots, sending them to the ICRs for review, ICRs marking up changes and sending them back, capturing changes in a bug system, and developers making changes. A localization engineering resource is usually assigned to update the localization files with the changes. However, finding the words in the software is not always obvious. Overall, this manual process is time-consuming, involves many steps and multiple resources, and is error-prone.Examples
Here’s an example of what an ICR might see—the translations are in context.
To make changes, the ICR uses the LocalyzerQA window to edit and proof the strings.
Localization Reviews Using LocalyzerQA
LocalyzerQA lets the reviewer examine the translations in the context of the application and make suggestions. Once the changes are approved, LocalyzerQA automatically updates the localization files. In addition, the edits are made automatically to a translation management system for storage in a translation memory for use on the next project. This process creates a fast and efficient localization testing and QA correction loop.Learn more about LocalyzerQA on our product page.
FIGMA and i18n and l10n During Design
The trend in software development is to design UI within prototyping tools, such as FIGMA. The designers create the UI layout and developers then develop the code using the FIGMA output as a template. Even though FIGMA does not actually create any new code used in an application, there is an opportunity to design i18n and localization considerations into that effort.
Pseudolocalization (made possible via Localyer) can be used so that the designer can immediately see the impacts of string expansion for additional languages, without needing to understand other target languages. Machine translations can be immediately implemented to see translated interfaces, and some teams will even go to human translations immediately from FIGMA so those translations are used during the actual code development. For Localyzer’s FIGMA capabilities, see: https://wiki.lingoport.com/Figma_API_Project.
Conclusion
Internationalization is more than preparing software for language translation—it’s a process for designing to support the unique formatting needs, numbers, currencies, dates, and local languages in a way that feels like it was coded for each locale. It’s also the framework for offering users the best possible experience regardless of where they live.
Supporting i18n makes the localization process easier and more efficient, saving time and reducing costs. Adding new features is a smoother process too, since internationalization is already in place and part of your developer team’s best practices.
Coding with internationalization in mind also prepares companies that aren’t ready to expand into new markets today to make that move more easily when the time comes. Including internationalization support in your code—whether it’s a new project or an update in anticipation of moving into different markets—is good business. Your investment will pay off by streamlining localization and reducing related bugs, creating a more efficient update process, and opening the doors for faster expansion into new markets.
For more than 20 years, we’ve been helping companies with software internationalization. Let us help you and your team prepare for a continuous globalization process using our technology and expert resources.
The Platform
The Lingoport product suite
Kill the chaos typically found in global software development. Eliminate manual spreadsheets, rework and globalization backlogs without proxies or libraries.
Globalyzer, Localyzer and Localyzer QA work together to support i18n, l10n and QA. See your timely globalization data centralized on the Lingoport Suite Dashboard.
Frequently Asked Questions (FAQs)
Internationalization is the process of preparing software for different languages, regions, and cultural conventions. The goal is to make the software look like it was created specifically for a market.
Developing software with i18n in mind lets you streamline the localization process for new markets. It provides a foundation for future scalability and simplifies the process of adding support for additional languages.
Internationalize software during the development phase. If you wait until after development, you’ll likely have to make coding changes, which may delay the product release.
Best practices for internationalization include four components: pseudo-localization, static analysis, reviewing localization files, and reviewing text by an expert.
Pseudo-localization simulates the translation process by replacing text with test characters to identify potential language issues early in the development cycle.
Our technologies include:
- Globalyzer – Find and fix i18n bugs early.
- Localyzer – Find errors in localization files.
- Localyzer QA – Review translations in context.
Glossary
Globalization – Making products available in other languages.
Internationalization – Ensuring that software is adapted to a global market.
Localization – Translating and adapting content from one language to another to include linguistic and cultural appropriateness.
