Whenever someone in the localization industry tells me about a project that experienced a lot of technical problems, my first question is usually, “well, what happened when you performed a pseudo-localization test?”
Far too frequently, that question is met with awkward silence, followed by attempts to rationalize why pseudo-localization failed to be completed at the start of the project. Those rationalizations rarely seem sufficient, especially when a project spins out of control to the point that someone loses a client or someone loses a job.
Unfortunately, many localization managers are localizing without performing pseudo-localization, the most basic of tests to be sure that a product is properly internationalized. Most people in the localization industry know that internationalization is important. A decade ago, the Localization Industry Standards Association (LISA) used to say that proper internationalization reduces total localization time and costs by about half. One way to look at it is that it might cost $1,000 and 20 hours to make a fix and internationalize the original source, or it might cost $20,000 and 400 hours to make the same correction in the target version of 20 different language versions, plus $20,000 and 400 hours more for each update rolled out in the same 20 languages.
Pseudo-localization — also called pseudo-translation, test translation, round-trip translation and dummy translation — simulates translation by automatically replacing text with test characters while preserving non-translatable code and simulating text expansion or contraction. In addition to testing internationalization, this also helps to prevent at least 90% of technical problems that can go wrong in a project.
Here are six reasons why you should not skip pseudo-localization testing at the start of your next project.
1. Preemptively identify internationalization issues
No one can fix problems they don’t know they have. Without pseudo-translation, most internationalization issues are not identified until the project is running up against the delivery deadline, putting timelines and budgets at risk. By inspecting a pseudo-localization early in the project, the following localizability issues can be identified before they affect costs and scheduling:
Over-externalization. Automatic replacement of translatable text identifies if code is improperly included with translatable text.
Improper display of character sets. Test characters show if target languages will not display properly in the final product.
Text not included for translation. Once everything is replaced with test characters, any untranslated source text stands out quite obviously.
Text embedded in images. Any text hardcoded in images will also stand apart easily from the test characters.
Unhandled text expansion and contraction. Prefix and suffix markers {like brackets} that surround each string of text will be hidden if content boxes or menus do not allow for text expansion with existing sizing or dynamic resizing.
Concatenation. Excessive use of concatenation and variables are revealed in the simulated text by clusters of variables and prefix/suffix markers.
Sometimes these tests can also help spot issues where regional settings are not properly internationalized, but that usually requires more manual inspection.
2. Be visually convincing
The visual nature of pseudo-localization makes issues much more obvious and solutions much clearer.
“I have spent the last two years trying to convince this department to better internationalize, seeing hardly any improvement,” said one localization manager at a large ecommerce company. “Now that I’ve showed them the results of the pseudo-localization, they finally get it! After only two hours, they’re making plans to implement the needed fixes.”
After pseudo-translating, there is the chance that the application will not even compile. That indicates that code has been translated and you must fix issues with over-externalization and then repeat the test.
If the application compiles successfully, you might spot issues as in Figure 2.
This pseudo-localization identifies multiple internationalization problems.
The text “Sign In” is left in English and indicates problems with text that is either embedded in an image or simply not included in resource files for translation.
The test characters in the search box appear as squares – sometimes called tofu boxes – and indicate a need to fix character display issues.
Sloppy wrapping in the orange search button and missing brackets on the end of two truncated strings indicate that the application does not allow for text expansion.
When all these issues are resolved, the pseudo-translation test should be repeated until it comes out clean, as in Figure 3 with all issues resolved.
3. Do it once and you’ll never go back
When a company that has previously experienced many technical problems in localization projects is exposed to pseudo-translation, they will never want to go back to the old way of doing things.
“Why didn’t our old vendor ever do this pseudo-localization for our website?” asked one localization manager after seeing the benefits of the process.
“This other vendor has been trying to win our business,” related another localization manager. “So, I asked them about their pseudo-translation process. But they couldn’t even answer the question. Why would I even consider them? That seems too risky.”
4. Cover your backside
When internationalization problems affect timelines and budgets, developers and others naturally tend to shift blame to the localization team or vendor. But localization teams can guard against such unnecessary faultfinding by performing pseudo-localization tests and warning about relevant risks before a project starts.
Sometimes requestors will not fully understand the need for these tests, refusing to allow it in the timeline or refusing to allocate resources to compile the pseudo-translated website or application. Does this pushback immunize the localization team from blame if something goes wrong that could have otherwise been prevented with pseudo-localization? No, not unless the localization team has adequately warned the requestor of the relevant risks.
A decade ago, a project manager under my supervision received such pushback from a large social networking company. Regrettably, this manager rolled over too easily and did not complete every step needed for pseudo-localization testing. The project quickly became an expensive and time-consuming disaster. Were my project manager and I immune from blame? No, not at all.
“You guys are the experts!” exclaimed the exasperated director of engineering whose team refused the test. “We need you to warn us of these risks and escalate things to shake us up if needed.”
From that point forward, my project managers required senior approval before skipping pseudo-localization testing on a project. That meant the senior contact of any client who refused such standard testing was required to sign and accept a lengthy list of increased risks that resulted from such a refusal. Nine times out of ten, the client would then decide they did not want to assume such risks and would reconsider. Those remaining times that a client assumed such risks with their signature, my project managers and I were shielded from undeserved accusations. Sometimes the client would beat the odds and nothing would go wrong, but, when a project became problematic due to internationalization issues, we maintained a good relationship with the client who now felt more trusting.
5. Test more than just internationalization
Pseudo-localization tests more than just internationalization, it’s a dry run that tests your organization’s entire localization process. The round-trip nature of the test ensures that integrations and the entire workflow are working as desired. Any slowdowns in what should be a quick test will identify the need to automate manual steps, thus also aiding agile localization.
Former Elanex CEO and artificial intelligence entrepreneur Jonathan Kirk used to joke, “it is called a ‘dummy test’ because you’re a dummy if you don’t do it,” and I can’t argue with that. That dummy text in the simulation even helps to test for manual formatting like excessive manual line breaks and indenting with the space bar in nontechnical translation projects of Microsoft Word documents.
6. Find pseudo-localization features everywhere
In the early 2000s, virtual localization tools like Passolo were some of the only tools to include built-in pseudo-localization capabilities. Over the last decade, pseudo-translation features have become nearly ubiquitous in translation technology. This common feature is found in recent versions of SDL Trados Studio, WorldServer and many other competing systems. Lingoport’s Globalyzer contains much more robust features to spot internationalization bugs. But a tool doesn’t need to include much to be useful. I recommend the following three features at a minimum:
1 Automatic insertion of test characters — to easily check character set support, over-externalization of code, embedding of text in images and extraction of text from resource files.
2 Insertion of prefix and suffix characters — to quickly identify expansion issues or excessive concatenation.
3 Simulation of expansion and contraction — to check proper handling of text when the translation expands or contracts by an expected percentage.
With such features now commonplace, most localizers can pseudo-translate using the same tools in which real translation takes place. Localizers no longer need to resort to separate pseudo-localization software that fails to use the same filters or machine translations that fail to insert prefix and suffix markers.
Pseudo-localization testing will not prevent every problem. For example, additional effort is required to simulate mirroring and prevent issues when localizing for right-to-left locales. But simulation of translation is the smart choice for those who want to overcome the technical challenges that may arise in a localization project.
