Hello, this is Sahil Khokhar, a Software Engineer with the Web team at Mercari JP.
I would like to take this opportunity to continue my efforts towards helping everyone understand Web Accessibility and its relevance with regards to Internationalization and Localization, which play an essential role in Globalization of the Product Application.
After explaining The Importance of Web Accessibility in my previous blog, today I would like to divert the attention of readers towards the meaning and differences between Internationalization and Localization and their contribution in Globalization of the Product.
Internationalization, Localization, and Globalization all sound similar, and that is why they may seem like interchangeable concepts to many people. Hopefully, by the end of this blog, you will be able to spot the subtleties that distinguish these "going global" terminologies.
What is Internationalization?
Internationalization, often abbreviated as i18n (because of the number of letters, 18, between “i” and “n”), according to W3C is the process of
[making] your content, application, specification, and so on, in a way that ensures it will work well for, or can be easily adapted for, users from any culture, region, or language.
In simple words, it is a strategy of architecting the product or the service to be as language and culture-neutral as possible so that it can be easily consumed by users with different backgrounds and nationalities.
i18n of the product or service is often carried out during the initial design and development phase by designers and developers. It is what operates at a more technical and foundational level of the product.
In the case of software products and electronics, i18n involves a number of different challenges:
- Backend: The application’s backend must address the concerns of i18n for the data returned.
- Frontend: The application’s frontend must showcase good practices to accommodate and incorporate translated static as well as dynamic content.
- Design: The application’s design should be flexible enough to adapt to the changes brought to the interface due to the translated content.
- Data encoding: Even though the ASCII character encoding suffices for texts in most Western European languages, languages using non-Latin alphabets, like Chinese, Russian, Korean, and Hindi require larger character encodings such as Unicode.
- Hardware support: It is essential for Software developers and designers to consider that some hardware devices might not be available in all the countries.
The most loved Swedish furniture brand IKEA is an excellent example of i18n as it intelligently internationalizes the assembly instructions for its furniture by making use of just illustrations and diagrams, without using any text that would require translation. Some of its products with instructions that require translation are written by keeping in mind the goal of being as culturally-neutral as possible.
Let’s take an example where our goal is to internationalize the home screen of a marketplace application, and we are required to display personalized item recommendations on the home screen. This is where we are required to set up i18n for displaying a heading (title) on the home screen.
Keeping this situation in mind, let us assume that our application is planned to be launched in both, Japanese and English. Rather than hard coding the heading in each of the languages, we prepare our codebase to receive the right set of configuration based on the target language. To achieve this step, the usage of key placeholders is required that — when localized — automatically retrieve each target language without needing any fundamental engineering changes.
Let’s say the heading key is ‘title’. The Japanese value of ‘title’ would be “おすすめの商品”, and the English version would be “Recommended items”.
So, writing the code for the home screen would look like this,
What is Localization?
Localization, often abbreviated as l10n (because of the number of letters, 10, between “l” and “n”), according to wikipedia is the process of
adapting your internationalized software and the experience to meet the language, cultural, and other requirements of a specific target market, otherwise known as a locale, by adding resources and translating content.
In simpler words, l10n uses the infrastructure and flexibility provided by i18n to adapt the content and experience for a given locale (or specific market).
l10n is typically conducted by language specialists or translators on the user-facing components of the software or application and usually happens after the process of i18n has been concluded.
Localization is not just limited to translating text languages as it also refers to localizing naming conventions, date and time differences, accounting standards, currency, culturally appropriate symbols (pictograms), hand gestures, images, legal requirements (such as relatively recently implemented GDPR for the use of European Union citizens’ personal data), and other locale-specific components.
Pseudo-localization is another helpful step for localization as it relates localization to internationalization. It is the process that “tests” the space that various languages are bound to take up in your finished design, and allows you to understand the contraction, expansion, or the vertical space required — without having to conduct a translation.
Did you know that Japanese to English translation can expand the text by up-to 55%? Figma and Sketch are some of the interface design tools that can help you during the design process by keeping i18n in mind.
Internationalization vs Localization
i18n is the process that usually occurs before l10n during the development cycle of the software or product. i18n operates on a technical level underneath the umbrella of l10n efforts. While software localization involves attuning your formatting to a more global and diverse experience (such as dates, times, numeric values, design, and cultural cues), it is software i18n that prepares your codebase to accept these variations between the different languages.
Although l10n is the process that usually follows i18n, but — beyond adapting your software to a specific market — the localization process is also adept to highlighting any words, phrases, or user interface (UI) elements that haven’t correctly been internationalized or adapted to the cultural requirements of the target market.
To understand this further, let’s take a look at some good examples of this.
Let’s say that after concluding the process of internationalization for your product application, you are now conducting localization for the Arabic language. Arabic is a right-to-left (RTL) language which not only requires translated content but also needs an altogether different interface design. Therefore, while localizing your product for Arabic, you discover your internationalization or user interface design team made an error. After scrutiny, you find that the team failed in implementing the correct code that allows for both LTR and RTL designs (also known as Bidirectionality). Hence, before beginning with the localization for the product application, it is necessary to internationalize your codebase and build the technical foundations necessary to adapt to any kind of localized content.
To give you a good reference, let’s go back to our favorite swedish furniture brand IKEA and see how their internationalized website accommodates both LTR (English) and RTL (Arabic) designs.
LTR Interface Design
RTL Interface Design
More details on Bidirectionality by Material Design.
When creating the film ‘Inside Out’, Pixar modified its animation to accommodate multiple versions of a scene where a character points to and reads a sign. In the Arabic version of the film, the character motions from right to left, rather than the left-to-right direction the animation takes in the English version of the film.
Side by side: Depending on the country in which you live, you may see different green vegetables used in Pixar’s “Inside Out”
Siri, Apple’s virtual assistant is another excellent example of a service that has been successfully localized. When users ask Siri for the weather report or directions to a specific address, Siri can provide the answer in Celsius (°C) or Fahrenheit (°F), or Kilometers (km) or Miles (mi) respectively, depending on the user’s location or language/region preference settings.
These examples exhibit how internationalization and localization are both important when preparing your product for the global markets. Because of this, until you perform the localization process a couple of times by keeping in mind all factors necessary for adapting your product to the target market, you shouldn’t consider it as fully internationalized.
Contribution of Internationalization and Localization towards Globalization
As it’s quite evident from above that the strongest similarity between internationalization and localization is their shared goal: Globalization.
Globalization, often abbreviated as g11n (because of the number of letters, 11, between “g” and “n”), is when an organization develops international influence and starts operating on an international scale, by bringing its software or application product to the rest of the world.
Going global for any business requires a lot of preparation, and that is why Internationalization and Localization can be a good start to get the fundamentals right for Globalization of your product application. Some of the best examples for you to form a better understanding of Globalization are:
- Online Marketplaces like eBay and Amazon, which operate in over 200 countries bring out a customized experience for local markets and businesses.
- Netflix, a leading online streaming platform which currently operates in over 190 countries, modifies the content that it offers with subtitles and programming in local languages.
- McDonald’s, the American Fast Food giant that operates in over 100 countries provides customized menus and offerings for its customers.
The Blurring lines between Internationalization and Accessibility
The recent studies related to Internationalization and Localization have started to include accessibility amongst the key aspects that need to be taken into consideration when adapting a product application to another language and culture (localization).
Now that we have formed an understanding of the basics of Accessibility and Internationalization, the complexity lies in their intersection. If you have a product application with a general user interface, modified and fine-tuned, to satisfy the needs of just one geographic market, then there are three other user groups that you are omitting.
As per the above image, by reaching either of ‘A’ or ‘I’ quadrants, your product would be open to a new and diverse kind of user-base. However, what it requires is a combination of internationalization and accessibility standards across the product application that helps you reach the ‘I&A’ quadrant and ensure that it in-fact is truly open and accessible for everyone.
The definition of one of the four Accessibility principles, Robust(ness), according to WCAG 2.0,
Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
Within the ‘I&A’ quadrant, this definition of “robust support” starts changing and expanding. Graceful degradation of the User Interface in the case of low-speed cellular data connections, device, and operating system’s (OS) age and how your product application behavior changes according to that are some of the factors that add on and start to become more relevant. To simplify, a highly robust iPhone application would be considered useless if the majority user-base of the target market uses an Android device.
So, what do we need to do? A mature organization that has a vision of ‘going global’ would make ideation, design, development, and testing process improvements for incorporating the standards necessary to reach the ‘I&A’ quadrant. What we need to do is to stop imagining our target user-base as a monolith and start indulging and understanding more about the cultural and experience diversification that they possess. As this article nicely states,
An elderly user in Japan will have totally different needs than a blind user in Spain.
Is investing your time and resources in all this worth it?
For sure! An increase in the diverse user base engagement will prove the effort worthwhile. Not only will it open up new horizons for your business, but will also lead to your user-base expansion without having to re-engineer your product from the ground up.
Some of the most popularly known frontend libraries used for internationalization are react-i18next and react-intl. In my next blog, I would be explaining how we can incorporate i18n in your frontend application.