What is Pseudo-Localization?

What is Pseudo-Localization?

Pseudo-localization is an effective way to test the localization-readiness of an application. By pseudo-localizing the resource files, an application can be tested for internationalization without waiting for localization.

Creating pseudo-localized resource files help test for:

  1. embedded strings,
  2. text that was externalized but should not be,
  3. text expansion issues,
  4. character-encoding problems,
  5. text concatenation issues, and
  6. UI boundary issues can be identified.

Pseudo-localization is covered by many terms: pseudo-translation, test translation, round-trip test translation, translation simulation, or dummy translation. It basically means simulating translation by automatically replacing text with test characters while preserving non-translatable code and simulating expansion or contraction.

Check out the video (or read through the transcription) below to discover how pseudo-localization can help prevent costly L10n issues and improve the speed and quality of localization.


What is Pseudo-Localization? | Video Transcription

Hi, this is Adam Asnes from Lingoport with just a brief technical talk on pseudo-localization. This is a concept that can really help you if you want to enable your QA department to not treat localization as an afterthought, but instead continuously test during the sprint for the localizability of your UI.

Although pseudo-localization is certainly not full coverage, and I don’t recommend it as the only way to approach internationalization, it is a really straightforward, effective way to catch errors at least reasonably early in the development cycle. Globalyzer will find issues as developers are actually coding and show you exactly where those issues are. But pseudo-localization, if that’s all you got, is certainly better than nothing. It is supported by default by our products so that they’re automatic every time somebody updates a file. You don’t even have to think about it. It just happens.

But let me give you the principle here, and then you can decide. First of all, this is an actual screenshot from one of our customers. What you’re seeing is the locale on the browser changed to Esperanto. So for this site, they consistently inject these pseudo-localizations so that their QA department can make sure that languages will be supported without having to wait for the localization to happen.

Image V.0


So anybody who is testing their application in U.S. English should be able to read that this says, “Connect Generations.” If they look at the screen and it just says, “Connect Generations” without these pad characters on it, they know they have a problem (See image V.0). In fact, it tells them that they have an embedded string. That string is embedded in the source code, and it’s unavailable to the translators.

Take the open paren and this closed paren for example(see image V.1). If there’s two of them, they know they have a concatenation. That is the string is being built. The problem with strings being built, is that they may not be localizable for the target languages because of several factors including the word order being wrong, plurals being handled differently or incorrectly, adjectives in a different place, etc.

Image V.1

If, say, this came out all as like a bunch of square boxes, then we’d know that they had an encoding or a font issue. And so on down the line. If, for instance, there’s no square bracket at the end, we know that the interface is cutting off that expansion. Then finally, we can see here if it shows up like this (see image V.1), it’s a pass. We see the beginning and the end.

Now with these characters, you’ll notice we’ve added diacritics by default, and we have expanded the string open and close characters and some Unicode characters. This is what helps us to see right away, will the string expand to fit, say, German or another language that typically takes up a little bit more space? Will the fonts support, Chinese or Japanese? So we make this a continuous process. We can do it in Globalyzer, but it happens automatically in our Lingoport Resource Manager. You can see that if you go to lingoport.com/products. You’ll see the whole scope.

With Resource Manager, nobody has to think about this. The minute somebody adds a string to any resource file in the repo, it’s automatically going to get recognized, and the pseudo-localization is created so testers can be continuously testing. Now you can also test for things like date format. You’ll need to build those test cases, and it’s a little more complicated, but it’s all available to you.

The reason why, again, I say this is not the be all-end all, is that it still puts you pretty far away from the coding experience, in terms of finding internationalization. But like any coding quality, you need to test, and this is one of the many ways that you can test. If you’re using Lingoport Resource Manager, you can actually click on a string and track back to exactly where that string is within your code base so there’s no time spent looking for that string by the developers.

Need support with your i18n project? Contact Us.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *