You’re releasing software in multiple languages for 6 markets. You get back your localized files and get ready for release. But now, at this late stage, you’ve discovered issues. Some of your interface is still in English. Perhaps dates are still showing up in a US-centric format? Perhaps the translations aren’t displaying properly because there isn’t enough space in the UI? Or, you’ve got square boxes and garbage characters that should be displaying in Japanese.
While you could find many of these issues during software development using Globalyzer (when it’s easy, fast and cheap to fix), it is still wise to have a global testing plan that includes pseudo-localization. You can test for localization support, and as a result, not have surprises after translation.
What is Pseudo-Localization?
Pseudo-localization is a technique that helps software development teams detect potential issues around user facing strings early on. Pseudo-localization transforms resource files written by developers and shows the transformed strings when a specific locale, the pseudo-locale, is passed to the application.
String Externalization
When developers write code for a global market, the strings need to be moved from the code into resource files. This process is called string externalization. If the strings are not externalized, they cannot be translated and a user looking at the application will always see the strings in the same way, with the locale set to German, French, or Japanese. Strings which are not externalized are called hard-coded strings.
For example, in some code using .ejs, if the string Family Tree is hard coded, setting the locale to French will still have “Family Tree” showing in the UI:
<span class=“visible-phone”>Family Tree</span>
If instead the string is externalized, it can be translated and setting the locale to French will show another string:
The .ejs file snippet:
<span class=“visible-phone”><%- i18n(‘FamilyTree’) %></span>
The corresponding .json resource file snippet in English:
“FamilyTree“: “Family Tree”,
The corresponding .json resource file snippet in French:
“FamilyTree“: “Arbre Familial”,
The UI set to French:
Pseudo-Localization
When strings have been externalized into a resource file, they can be transformed for testing purposes independently of translation and that transformation can be shown in the UI using a pseudo-locale.
French is a typical ‘real’ locale: French users will most likely want to see the application in their language. The same is true for most regions, like Japanese, Chinese, Spanish, etc.
A pseudo-locale is a locale that is not a going to have many, if any, users. A typical pseudo-locale is Esperanto. Very few if any users will want to see an application in Esperanto so it makes it a good candidate for a pseudo-locale.
Using the previous ‘Family Tree’ example, here is a possible corresponding snippet in Esperanto:
FamilyTree“: “[Ƒåɱîļý Ţŕéé—- П國カ내]”,
When viewing the application in Esperanto, the banner will now look like:
Why Pseudo-Localize?
The benefits of pseudo-localization are many, including:
- If the strings are displayed in pseudo-localized form, they have been externalized and can be translated.
- If the strings do not have any mojibake (corrupt characters), the user interface displays Unicode characters correctly.
- If QA can see the start and end character (here “[“ and “]”), the layout takes care of strings which will be longer when translated, say, in German.
- Pseudo-localization may also help identify concatenation issues, for instance when in what should be the same resource, the end and start characters appear multiple times.
When to Pseudo-Localize?
Pseudo-localization should be part of localization (L10n) automation. For instance, Lingoport Resource Manager, or LRM, automatically pseudo-localizes all resource files as they are modified or based on a frequency, such as twice a day.
This means that ‘someone’ does not have to think about it, ‘someone’ who may have other things to do such as coding an application.
Both Lingoport’s Globalyzer and Resource Manager support pseudo-localization. The former, helping developers unit test their work, the latter, on a continuous basis so that QA can always use pseudo-localization in their test criteria. It should be noted that pseudo-localization is a testing procedure, while using Globalyzer, particularly when it’s implemented within an IDE, helps avoid internationalization (i18n) issues as software is developed (and when it’s most efficient to fix). This includes i18n bugs beyond string-related issues. Even so, we always recommend implementing pseudo-localization as part of your software development practice.
Mind the Gap
Any hitch in the process, like a missing curly bracket or a duplicate string ID, is often found later in QA or when something breaks. That means a developer has to go back and find where that issue occurs, causing additional lost progress.
Our special guest on the webinar will be Darin Goble, Director, Client Solutions at Welocalize. With 20 years of experience in the localization industry, Darin has worked in production, engineering, solutions and management roles in four different services organizations and held technical and finance roles at Hewlett Packard. He has also served on the Project Management Institute’s board of directors for the Portland Oregon Chapter.