What is i18n? Internationalization, commonly abbreviated as i18n, is a foundational step in creating software applications that resonate globally. It involves designing your software to easily adapt to different languages, regions, and cultures.
i18n is a numeronym (i+ nternationalizatio + n) used for the word internationalization. Numeronyms are also used to define other aspects of the process of going global, such as l10n (localization), globalization (g11n), translation (t10n).
What Is i18n?
Exploring the Meaning of i18n
Internationalization, prepares your software for worldwide use. This process separates locale and language details from the main code, enabling support for various languages and cultural norms efficiently and cost-effectively.
Challenges with Implementing i18n
Integrating i18n, especially into existing systems not initially designed for global use, is challenging. It involves reviewing the code to identify and modify parts that assume a single language or locale, ensuring the software can adapt globally. Key challenges include ensuring all locale-specific functionalities are considered to avoid a compromised user experience across different regions. Yet, these hurdles can be navigated through early and ongoing i18n efforts, utilizing the right tools and adhering to industry best practices.
The Importance of i18n Support
For successful internationalization, extensive i18n support is crucial. This includes tools that streamline the i18n process, detailed guides, and forums for developer collaboration. Effective i18n support allows teams to address specific international challenges, such as handling locale-specific data and managing text expansion. Strong i18n support not only overcomes internationalization obstacles but is essential for leveraging your software’s global potential.
What is the difference between localization (L10n) and internationalization (i18n)?
I18n is the foundation on which effective software localization (L10n) is built.
Think of it as the behind-the-scenes work on your product, setting the stage for l10n, which is where we translate and tweak content to fit right in with local cultures. To put the difference in simple words – i18n adapts the code, l10n adapts the experience.
Imagine an online store needs to ensure that the code behind all form fields necessary for purchasing a product (e.g., phone numbers, currency, address blocks, etc.) is adapted for different languages and cultures. This is internationalization.
Now, let’s assume that the same store needs to ensure the proper translation and adaptation of product description pages (including design), video captions, reviews, etc. This is localization.
To learn more about the difference between i18n, L10n, and g11n check this article.
What are the common internationalization (i18n) challenges?
Internationalizing software involves several technical and cultural considerations. From managing embedded strings to addressing region-specific formatting, the challenges are varied. Let’s explore some of these:
Locale—not just language
Language varies by locale. For example, English differs across regions: British English, Australian English, Canadian English, etc. Differences that affect i18n include units of measurement (e.g., the metric system) and currency. Developers need to create logic for locale negotiations and develop frameworks for loading local resources and requirements.
Embedded strings
Translators cannot access embedded strings directly in the source code; these need to be moved to resource files or databases to be accessible. This represents a significant challenge for developers and localization managers. Without tools that automatically extract embedded strings into translation management systems, manual extraction becomes a developer’s nightmare.
When a string is embedded in source code, translators can’t access it and there will be no mechanism to substitute translated strings.
“If you don’t or if you partially extract strings from software code and miss some, you end up with an application that has English in the middle of the rest of the translated text. This is not the fault of the translator, as they couldn’t translate it because they never received this paragraph. Therefore, something as simple as not extracting a string can cause big issues. If you don’t hold back the release and fix these issues, your product risks being rejected in the target market.”
Milen Epik, Webinar “A Crash Course in Internationalization Bugs”
Concatenations
Word order varies across languages (S -> Subject, V -> Verb, O -> Object), requiring changes in code where concatenations are used to ensure phrases or sentences are correct. For example, in English, the order is S-V-O (“System A sends data”), whereas in Japanese, it is S-O-V (“System A data sends”).
Region-Specific Formatting
Region-specific formatting presents a significant challenge in making software universally accessible and user-friendly. Every country has its unique way of displaying dates, times, numbers, currencies, and contact information. Not taking into account these regional preferences can confuse users, diminish their experience, and potentially discourage them from using the software.
Here are some examples of how region-specific formatting varies:
Date and Time: In the United States, the date format commonly used is Month/Day/Year (e.g., 03/14/2024), whereas in much of Europe and other parts of the world, the format is Day/Month/Year (e.g., 14/03/2024). Additionally, 24-hour time notation is standard in some countries, while others use 12-hour notation with AM/PM
Currency: Not only do different countries use different currencies, but the format of currency symbols and their placement (even for regions) relative to the number also varies. For instance, Canadian English uses “$123.45, while Canadian French uses “123,45 $”.
Numbers: Issues with numbers can include decimal and thousand separators, digit grouping, percentage symbols, currency symbols, and more. For example, thousand separators vary from country to country: the US uses commas (1,000), Germany uses periods (1.000), France uses spaces (1 000).
Text expansion
Text expansion can make menus and buttons unreadable and potentially render the UI unusable in certain languages. For example, French and Spanish increase length by 15-30%, while German and Dutch are notorious for expanding text by up to 35%. Although script languages may result in shorter translation strings, the characters are often taller, requiring more vertical spacing.
These are just the most typical i18n issues encountered during implementation. Addressing these can be a substantial, resource-intensive task, possibly requiring the hiring of i18n experts to ensure smooth progress and adherence to deadlines.
What are the best practices for i18n?
As discussed in the previous chapter, there are many i18n issues that can lead to bugs in the code. However, with proper planning and i18n support, these challenges can be successfully overcome. The key steps to ensuring your software is truly ready for a global audience include using i18n tools and adhering to best i18n practices.
Embedded strings
Localizing text strings that are left embedded in the software code is essentially impossible. However, by externalizing the strings into resource files, the localization (l10n)/translation problem is easily solved.
Example: Here are two simple text strings
String titleLabel =”Order history”; String nbItemLabel =”Number of items”;
Generate a Key/Value pair in a resource file and refer to that key in the code to retrieve the value. The value is the string itself. You can retrieve the string from a locale-dependent resource file.
The key/value pair in the resource file looks like this:
order.history.title=Order history item.number.label=Number of items
Concatenated strings
Concatenation of the string fragments or string variables produces grammatically incorrect translations, often with unclear or nonsensical meanings.
To avoid the dangers of concatenating strings, where possible, use full sentences and discuss the base text with your l10n team before it is signed off. If you must insert variables, use a notation such as curly brackets {} marking the insertion point instead of concatenation.
Here is an example, you need a string code for an application message confirming a project is ready.
English:
LOCALYZER_READY_PROJECT_NAME= Your Localyzer Project ${LzProjectName} is ready
Turkish:
LOCALYZER_READY_PROJECT_NAME=${LzProjectName} adlı Localyzer projeniz hazırdır
The variable ${LzProjectName} gets replaced with the appropriate value during runtime.
Text expansion
Provide expansion guidelines to your UI designer to keep in mind when designing screens. UI designs can be tested with pseudo-localization or machine translation to view the expansion and adjust early on.
If your designers use Figma, they can conduct expansion testing during the design stage instead of waiting for the development phase. To achieve this, you will need to use solutions similar to Localyzer, which has a connector to Figma and can take the design for translation using either your translation provider, machine translation, or AI (such as ChatGPT).
What are the examples of internationalization (i18n)?
Airbnb
Airbnb stands out in internationalization by paying attention to details. Their platform adapts to local preferences, not just in language but in elements like currency display. They position the currency symbol according to regional habits: before the amount for Australia and after for Norway. This approach helps Airbnb provide a smooth, localized experience for global users.
Workday
Key to Workday’s i18n success started with a focus on education, engagement and implementation of specific i18n tools.
By integrating developer-friendly i18n tools, like Globalyzer, Workday bridges the gap between coding and localization. The tools helped to streamline the internationalization process, making it a seamless aspect of product development. This approach not only identified and resolved potential i18n issues early but also aligned product offerings with the diverse needs of global markets.
Furthermore, they established comprehensive internationalization resources and training for all new hires, particularly engineers, ensuring a standardized approach to product localization across the board.
Workday’s story is an example of a well-implemented i18n strategy, highlighting the critical role of tools, training, and team engagement in achieving global success.
What are the benefits of implementing internationalization (i18n)?
Cost saving: By integrating i18n from the start of development, you minimize the costs associated with later bug fixes (which also makes developers happier—nobody likes bugs!)
Shorter time to market – Implementing i18n leads to smoother localization with fewer bugs, better collaboration between developers and localization teams, and swift adaptation of content. This accelerates the localization workflow and reduces time to market.
Resource Efficiency: A proactive approach is better than a reactive one. Addressing potential localization needs early in the development process helps avoid the resource-intensive task of having developers fix issues later on.
Global Users Experience: i18n ensures elements such as user interfaces, date/time formats, currency, and measurements are tailored to local norms, providing a seamless user experience. Localization issues can make the product challenging to use and potentially damage your brand’s reputation.
Easily scalable product– I18n ensures your software is built with scalability in mind. This approach allows for the effortless addition of new languages or adaptation to new cultural norms. So, when you are ready to enter new markets, you’ll find that much of the groundwork has already been completed.
Conclusion
Internationalization, or i18n, is more than just a step in software development; it’s a comprehensive approach to making your software universally accessible. By focusing on i18n support and embracing i18n best practices, developers can create products that resonate on a global scale, ensuring a seamless user experience regardless of language or location.
At Lingoport, we provide a number of i18n services and products tailored to meet your internationalization needs whether you are just starting your i18n journey, want to improve the processes and fix the i18n bug debt or expanding to the new markets. Discover how Lingoport’s i18n solutions can elevate your software’s global potential.
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.
When should we internationalize our software?
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.
What are some best practices for internationalizing (i18n) testing?
Best practices for internationalization include four components: pseudo-localization, static analysis, reviewing localization files, and reviewing text by an expert.
What is pseudo-localization?
Pseudo-localization simulates the translation process by replacing text with test characters to identify potential language issues early in the development cycle.
What tools and technologies help with internationalization (i18n)?
Kate is a seasoned B2B content marketing manager with a five-year journey in the localization industry. She is passionate about crafting various types of content to educate people about internationalization (i18n), localization, and the latest technological advances, including Large Language Models (LLMs).
Talk to Our Experts
Get you tailored consultation on i18n & L10n products and services.
