Going global is a monumental leap for any company. It signifies a transition from the initial challenges of establishing your business to proving that your concept can thrive on a global scale. Beyond attracting incidental web traffic and piquing the interest of new regions, expanding globally often involves establishing partnerships, opening offices, and working with agents. For software companies, this journey also necessitates internationalizing and localizing software to stay competitive and meet diverse market demands.

Understanding Internationalization, Localization, and Globalization

To embark on this journey, it’s crucial to grasp the core concepts that underpin internationalization, localization, and globalization. These terms are often abbreviated for convenience:

• Internationalization (i18n): Internationalization, often abbreviated as i18n (i – then 18 letters – n), is the process of making a single code base locale-independent so that the application can be easily localized to other locales with no source code changes. In essence, it’s about preparing your software to adapt seamlessly to different regions.

• Localization (L10n): Localization, often abbreviated as L10n (L– then 10 letters– n), is the translation and application of locale-specific terms and style so that a product is locale-specific – that is, it looks and reads like a product native to the market in which it is being sold. L10n takes the internationalized software and tailors it for specific locales, making it resonate with users in different regions.

• Globalization (g11n): Globalization, sometimes abbreviated as g11n (g– then 11 letters– n), includes both internationalization and localization together and often refers to the entire process of supporting other locales. It encompasses the holistic approach of making your software globally accessible.

The Role of Locales

A crucial aspect of these processes is understanding locales in computing. A locale is a set of parameters that defines the user’s language, region, and any special variant preferences that the user wants to see in their user interface. Usually, a locale identifier consists of at least a language identifier and a region identifier.

Consider this: In both the US and the UK, the typical language is English. However, other parameters such as date format, temperature units, and even some spelling conventions differ.

Internationalization (i18n) Testing: Laying the Foundation

Internationalization begins with the careful preparation of your software to adapt seamlessly to various locales. This foundational step involves making your software culturally and technically neutral. It’s where the journey towards a global audience truly begins.

Localization (L10n) Testing: Tailoring for Diverse Audiences

Localization (L10n) takes the internationalized software and tailors it for specific locales. This includes adapting content, formats, and user interfaces to resonate with users in different regions. Each localization effort opens doors to new markets and expands your global reach.

Why Wasn’t It Internationalized in the First Place?

In a perfect world, all products would be created with i18n as a fundamental requirement from the start. But often, with new product development, teams are just trying to make a product work and see if there’s a response. The initial focus is on relevance and acceptance of the application. Follow-on efforts are feature-focused. I18n isn’t really like a feature, as its requirements underpin an entire application.

As mentioned above, going back and internationalizing code requires a business case. It takes time and will distract the development team from new features. Sometimes, when you rewrite products, it’s an excellent opportunity to invest effort in internationalization. In many cases, outsourcing i18n can be beneficial, as it brings in expertise, allowing your team to focus on other areas while still learning from experts to ensure future internationalization in development. Expert help enables you to implement i18n faster with greater quality and less project risk.

Although people often think i18n is just about string externalization and the resulting localization, there is much more involved. There are locale frameworks that will govern locale behaviour, methods/functions/classes that may need to be changed, static files to alter, and even hard-coded patterns (e.g., a hard-coded font) that may need fixing. Issues like date/time, address, phone number, and numerical and measurement formats will have to adapt to local preferences. You’ll need character support, sorting changes, and more. String externalization is like the visible part of an iceberg. You see it, but there’s much more below the surface.

Consumer-Facing Software

It’s easy to see how consumer-facing software has a higher requirement for i18n and L10n if it’s to gain broad acceptance, even in markets where English is more common.

However, some argue that English is commonly used and understood in many places. Remember, if you travel to major cities in Europe, you’ll find that you can get along with English pretty well. But in terms of product preferences, people typically prefer engaging in their own languages. As you get out of major cities, you’ll find less English proficiency. Even with English (which English?), you still have formatting issues, as mentioned, like decimal and comma placement in numbers.

Technical Software

The notion of “English everywhere” holds particular weight in the realm of technical software. It’s true to an extent, especially if your user base consists mainly of technical professionals, such as system administrators. In such cases, English may suffice for a broader global reach. However, it’s essential to recognize that this approach falls flat when you venture into the Asia Pacific region, encompassing countries like Japan, Korea, and China.

Unpacking the Phases of Internationalization

Internationalization (i18n) is a multifaceted process, and the approach you take depends on your specific business case and target markets. Ideally, being globally ready for all locales is the ultimate goal.

The Significance of Unicode

One critical aspect of internationalization is Unicode support. If your software primarily targets Western European languages like French, Italian, German, Spanish, and Portuguese, you might not immediately require Unicode support. However, here’s where a strategic choice comes into play.

In the realm of internationalization testing (i18n testing), it’s advisable to embrace Unicode as early as possible. While implementing Unicode can add approximately 25% more work to your i18n implementation (with exceptions), it’s a valuable investment. Most modern databases and programming languages offer Unicode support, but you typically need to enable it. By addressing Unicode as part of your initial i18n efforts, you save yourself from the need to restart the process later.

Tailoring to Specific Markets and Complex Scripts

It’s important to note that Unicode support becomes a prerequisite when your expansion plans involve markets and languages with complex scripts. These scripts include Japanese, Simplified and Traditional Chinese, Korean, Vietnamese, Hebrew, Arabic, and Cyrillic-based languages (e.g., Russian).

Real-World Scenarios

To highlight the importance of Unicode support, consider a real-world scenario. Imagine your company has secured a significant deal, and you must deliver your product in Brazilian Portuguese within just three months. In such cases, having Unicode support already integrated into your software becomes a game-changer, enabling a swift and efficient localization process.

In conclusion, internationalization testing (i18n testing) for technical software involves a nuanced understanding of your target markets, the need for Unicode support, and the flexibility to adapt to complex scripts when expanding into specific regions. By addressing these considerations strategically, you ensure that your technical software can effectively navigate the complexity of global markets.

I18n Phase 1: Data

The first internationalization priority should be the ability to input, process, and transform customer data. In my opinion, this should be a benchmark requirement for any software that could have global customers or enterprise customers, whether or not localization is considered to be in the future. Note that the U/I is not changing in this phase. There is no U/I localization yet.

Even if you are actively selling only in your home country, it’s likely that you will run into customers in other countries or your customers will have customers in other countries. At least let people enter data in multiple languages and formats. Store it, transform it, and retrieve it without corrupting it.

Minimally, accents and diacritics shouldn’t cause character corruption (those square boxes and odd shapes you’ve probably seen). Better yet, add Unicode support in the database and source code.  Character corruption shouldn’t be caused by issues in the various components of your product source code.

Character corruption example:

Better if data could be stored and managed in variable formats for information such as date/time, numerical units, addresses, phone numbers, and currencies.

Automation is the best approach to achieving this in a seamless, efficient, and scalable manner. To that end, Lingoport’s Globalyzer can be used to scan your source code and database scripts to find these issues and guide developers to fix them. Our services team can perform refactoring work, as well.

I18n Phase 1.5: Locale Frameworks

You’ll need a locale framework for each programming language within your source code.

This paves the way for string externalization and presentation, which will be needed for localization. Presentation of formats for date/time, numerical units, addresses, phone numbers, collation, currencies, and more are also controlled by locale frameworks.

Lingoport’s services teams can help you make the right choices and even implement them for you.

I18n Phase 2: Language and Localization

String externalization is often what most people think of as the critical i18n and L10n steps. User-facing words or strings are removed from being embedded in the source code and replaced with a function call, typically to a resource file where the strings will now reside. This way, if the user selects a locale preference (remember those locale frameworks), French in France, for example, the code will retrieve the French strings in the resource file for presentation.

String externalization can be tedious and time-consuming. The issue is that lots of things may look like strings at the source code level that aren’t actually user-facing strings. Examples are named variables, debug statements, and internal queries. Lingoport’s Globalyzer has default and extendable capabilities to aid these distinctions. Globalyzer Workbench enables an i18n engineer to assemble strings, walk through them, and then externalize them in bulk.

You’ll also want to test your work. Lingoport’s Resource Manager will automatically generate a pseudo-locale that will help your team functionally test how the software will behave in another language without the testers needing to understand that target language. Pad characters are added around the original English strings with expansion automatically set based on typical U/I requirements in the target languages. Alternatively, the expansion can be configured manually. This way, testers can immediately see any missing strings or U/I elements that won’t properly expand for longer words and changes in fonts in other languages (i.e., German, Chinese).

A pseudo-localized page for a family tree application:

I18n Phase 2.5: Workflow

With some software, workflow, and processes are different depending on market requirements. This takes market research and coordination with in-country representation. For instance, tax management or medical administrative software is likely to have different requirements and steps in most markets.

I18n Phase 3: Bidi Support

If your product is being sold in places using bi-directional languages such as Hebrew or Arabic, you’ll need to enable and test your pages to support U/I mirroring and the bi-directional nature of the text that goes right to left but with left-to-right elements within. Unicode support is a prerequisite.

Ongoing i18n and L10n

Now that you’ve internationalized and localized your software, your work isn’t over. Your teams will be steadily releasing new features and functionality. I18n surprises can arise down the line that cost time and iterations to fix. It’s not hard for a developer to make a mistake. Just as your teams may continuously measure for coding quality issues and security, i18n quality now becomes another metric.

Localization for every sprint, branch, and repository makes for tedious, error-prone work that slows agile progress. That process can be automated, taking your developers out of the resource file update nanny business.

Lingoport Suite’s Globalyzer continuously supports i18n from the developer IDE to source repositories. Lingoport’s Resource Manager automates resource file updates from source to translation and back again, with quality checks in each direction. QA is supported as well.

Lingoport Dashboard lets teams see and manage i18n & L10n status and process, supporting i18n issue drill-downs to associated source code, issue assignment, and completion. You can itemize and examine issues with localization resource files in a similar manner.

We’ve seen teams go from 5-week localization update cycles to under 3 days over hundreds of repositories. Our services teams have internationalized many well-known applications, ranging from small to millions of lines of code. You might be surprised to witness the efficiency gains achievable in the development process.

We hope that you find this primer useful as you look to address the i18n and L10n of your own software products. If you have any questions, do not hesitate to reach out, and a Lingoport team member will be happy to talk through the issues with you.

Frequently Asked Questions 

What is internationalization testing?

Internationalization testing, often abbreviated as i18n testing, is a crucial phase in software development that focuses on preparing a product or application to adapt seamlessly to various locales and languages. It ensures that the software is designed and developed in a way that makes it easy to localize for different regions without modifying the source code. The goal of internationalization testing is to identify and address potential issues related to cultural, linguistic, and technical aspects to create a globally adaptable software foundation.

What is the meaning of i18n?

The abbreviation “i18n” refers to “internationalization.” The “i” represents the first letter of the word, followed by 18 characters (representing the letters between the “i” and the “n”), and ending with the “n.” This abbreviation is used for convenience in discussions and written materials to refer to the broader concept of internationalization, especially in the context of software development.

What is the difference between internationalization and localization testing?

Internationalization (i18n) testing and localization (L10n) testing are two distinct phases in the software development process.

• Internationalization Testing (i18n Testing): This phase ensures that the software’s core architecture and design are adaptable to various locales without requiring source code changes. It focuses on making the software culturally and ethnically neutral.
• Localization Testing (L10n Testing): Localization testing, on the other hand, involves the adaptation of the internationalized software for specific target locales. It involves translating content, adjusting formats, and ensuring that the software presents and functions as if it were originally designed for the local market.

In summary, internationalization testing prepares the software for localization, while localization testing tailors it for specific regions.

What is an example of internationalization and localization?

An example of internationalization is designing a software application to support multiple languages and regions from the start. This includes using Unicode character encoding to handle diverse character sets and ensuring that date and time formats are adaptable.

An example of localization is taking an internationally designed application and customizing it for a specific locale. For instance, when localizing an e-commerce platform originally designed in English for the Japanese market, the process includes translating the user interface, converting currency and measurement units, and incorporating local payment methods.

What are the types of internationalization testing?

Internationalization testing encompasses various testing types to ensure that software is adaptable to different locales. Some key types of internationalization testing include:

• Character Encoding Testing: Verifies the proper display and handling of characters from different languages, scripts, and character sets.
• Date and Time Format Testing: Ensures that date and time formats are culturally appropriate and adhere to regional conventions.
• Currency and Number Format Testing: Validates the correct display and formatting of currency and numerical values according to local conventions.
• Locale-Specific Functionality Testing: Checks that locale-specific functionality, such as address formats and phone number validation, works as expected.
• User Interface (UI) Testing: Focuses on the visual aspects of the UI, including text alignment, layout, and the overall appearance in different languages.
• Content Translation Testing: Ensures the accuracy and context-appropriateness of translated content.
• Compatibility Testing: Verifies that the software operates smoothly on various operating systems, browsers, and devices used in different regions.

These types of testing collectively ensure that a software product is well-prepared for international markets, minimizing localization challenges and maximizing global reach.

Other resources:

• 10X Globalization Webinar with FamilySearch’s Rob Thomas
• CA AgileCentral/Rally Software Webinar
• Fearlessly Leading Globalization Webinar with NetApp’s Anna Schlegel