If you’re launching a product for many different markets, there will be a step in the development process where you will need to transform your product from supporting just one language to supporting many languages.
Translating the textual data in your product is an essential part of adapting it to the global market. Product teams dream of making the localization process as efficient as possible, but all too often this process becomes hard and tedious. In this article, we’ll focus on the solution that makes this process much more comfortable: pseudo-localization. But before we dive into details about pseudo-localization, it’s vital to understand the concepts of localization and internationalization.
Grow your business with the Shopify Partner Program
Whether you offer web design and development services or want to build apps for the Shopify App Store, the Shopify Partner Program will set you up for success. Join for free and access revenue share opportunities, developer preview environments, and educational resources.Sign up
Internationalization vs. localization
While the terms “internationalization” and “localization” aren’t new, many product teams still don't understand their meaning, or use them interchangeably. While both terms are closely related, they are not the same thing. Let’s start with the first term.
Internationalization is the process of making a product easier to localize for all languages. Internationalization usually involves steps like tweaking a product’s UI so it will be ready to support multiple languages.
Localization, on the other hand, is the process of adapting a product to a specific country or region. Localization is about adjusting your product so that it will meet the requirements of each region you design for. This adaptation happens by translating text and adding locale-specific components.
Internationalization and localization are connected, and one typically follows the other.
The traditional process of localization and its problems
Traditionally, product development and product localization are independent processes. Usually, localization starts when development is finished. The product is created in one language (such as English) and then textual content is extracted into external resources. The localization team takes these resources and translates them into different target languages (e.g. Hindi, Japanese, German, French, etc.).
This approach has a major built-in flaw—many product bugs may be found during the process of localization, not during development. And, as we all know, the later a defect is found in the software development life cycle, the more expensive it becomes to fix it.
Below are a few common problems that product teams face during localization.
1. Some strings can be hard-coded in source code
Every localizable string should be editable without touching a line of code. This is the number one rule for localization. Unfortunately, many product teams break this rule and add some strings in source code. As a result, it becomes impossible to extract such sentences, and they won’t appear in resources sent to the localization group for translation. This often leads to a bad user experience (UX) when untranslated strings make their way into a final release.
"Every localizable string should be editable without touching a line of code."
2. The translated text can be longer than the text in the source language
User interfaces (UI) are typically designed according to the needs of one core language (e.g. English), and all content containers are measured based on the core language string lengths. However, when translating into other languages, the translated text could end up longer than the core language.
For instance, when we translate text from English to German, the German version of the text can be up to 30 percent longer than the text in English. As a result, translated text might not fit within the UI constraints, and the users end up seeing broken UI elements, such as text that goes out of bounds or font glyphs that are cut off vertically because they are larger than in the core language.
3. Bugs can multiply
When you need to translate a product into a few different languages, the traditional procedure for localization often leads to multiplication of localization bugs in bug tracking systems. Imagine a situation when you need to support 10 different languages, and you find the same issue in every single one of them. As a result, you have 10 new bugs. This leads to the multiplication of required resources to fix the issues.
You might also like: How to Build Multilingual Shopify Apps.
What is pseudo-localization?
Pseudo-localization is designed to catch the problems mentioned above. Pseudo-localization (or pseudolocalization, or pseudo-translation) is the process of verifying that your product is ready for localization. Pseudo-localization helps you see how a product’s UI will look after translation, without actually creating a real translation. Instead of translating the text of the product into a different language, the textual elements of a product are replaced with an altered version of the original language.
For example, with pseudo-localization, the phrase “Account Settings” becomes [!!! Àççôûñţ Šéţţîñĝš !!!]. This translation remains readable to English speaking team members, and allows them to see translation-related issues.
Pseudo-localization and the development cycle
The great thing about pseudo-localization is that it fits well in the development cycle. It allows engineering teams to continuously test their UI for localizability during their development sprints, because pseudo-localization becomes the default development language for the team. When developers or QAs run their debug builds, they see pseudo-localized content. This helps product teams treat localization as a priority rather than an afterthought, and gives them the opportunity to fix issues during the design phase, before translation even starts.
"Pseudo-localization allows engineering teams to continuously test their UI for localizability during their development sprints, because pseudo-localization becomes the default development language for the team."
Simulate translation-induced expansion
As mentioned above, some languages are known to be longer than others, while others are shorter. For example, French texts are on average 20 percent longer than English ones, while Japanese texts are 30 to 60 percent shorter. For example, think of the button label “New.” In English, it’s three characters, but in French, it’s eight characters: “Nouveau.” The French label is almost three times longer than the English.
The tool you use for pseudo-localization should allow for extending the length of the messages. In most cases, it’s enough to have a 30 percent extension (this number covers several popular languages such as German). As a result, the product team will leave enough room for longer translations.
Quick tip: Pay additional attention to menus and buttons, because labels in those controls typically go out of containers.
You might also like: How to Build a Shopify App: The Complete Guide.
There are many tools available on the market that help you introduce pseudo-localization in your development process. Alchemy Catalyst, Globalyst, and SDL Passolo offer not only a pseudo-localization capability, but also allow automating the testing process itself.
In an attempt to ease the process of pseudo-localization, Shopify has created its own small pseudo-localization tool that gives you the ability to preview your product with pseudo-translations. This tool can help you with:
- Identifying untranslated strings
- Expanding words by doubling all vowels to mimic languages with longer words
- Using English lookalike UTF8 characters for readability
Access Shopify’s pseudo-localization tool now.
The importance of advocating for pseudo-localization
Finding a proper tool for pseudo-localization is just half of the battle. The real work starts when you make attempts to introduce this solution to the engineering team. Developers and QAs should understand the value of pseudo-localization, or they won’t be motivated to use it in their development process.
This is why it’s vital to invest your time and energy in advocating and educating product teams to change the way they work fundamentally. A proven way to demonstrate the impact of embracing pseudo-localization is to track the number of bugs found during localization, and show how pseudo-localization helps to reduce this number. Seeing the real numbers will help the engineering team believe in this solution.
With the world becoming more global every day, putting localization at the top of your priorities will help you build products that work on an international scale.
What are your thoughts on pseudo-localization? Share in the comments below.