By Adolfo Gómez-Urda
What is it?
Pseudo-localization is the process by which the video game source text (we’ll assume it’s English in this article) is translated into other languages using fake (or pseudo-) translations.
This process should be fully functional at least a couple months before Localization QA (LQA) starts, but ideally, the English text should be pseudo-localized as soon as the first English strings are entered into the string files or string database, even if the localization process has not started at all. A pseudo-localized build contains pseudo-translations in the localized builds where, by default, there would be empty strings, string IDs, or English text for those English strings that have not been translated yet.
It is important to turn off this feature a few days before the game is shipped, to avoid released versions with pseudo-translations in them.
How Does it Work?
When a translation is empty and the English text is not empty, instead of integrating an empty translation into the localized versions of the game, this feature would export a pseudo-translation, which would be formed by a prefix of special characters (30%-50% of the source text) specific to the exported language followed by the source text. For example, if the source text reads "PRESS START" (11 characters), 3 or 4 (30%) Spanish-specific characters (taken from a list of all possible Spanish characters) would be added to the beginning of the source text to form a pseudo-translated string: "áéíóPRESS START".
The shorter the English text is, the more it will expand when localized. You should therefore consider using smart pseudo-localization:
English Text Length
Length of the Added Prefix
50% of the source text
40% of the source text
More than 20 characters
30% of the source text
French Pseudo-localization on Mad Max that allows us to see upper case font glyph issues
(character “É” being represented as an “é”) and a hardcoded string (“NAVIGATE”)
For dev teams working on string database solutions (as opposed to manually editing txt string files), it is important that the pseudo-localization takes place outside of the string database. That is, the strings should be pseudo-translated while they are being exported from the string database, but the database itself should not be polluted with pseudo-translations.
What Characters Should I Use?
The following lists contain all the characters you will need for each of the most common languages:
- French: àâæéèêëîïôœùûüçÀÂÆÉÈÊËÎÏÔŒÙÛÜÇ
- German: ÄÖÜẞäöüß‚„
- Italian: àéèìòùÀÉÈÌÒÙªº
- Spanish: áéíóúüñÁÉÍÓÚÜÑ¿¡ªº
- Portuguese: àáâãçéêíóôõúüÀÁÂÃÇÉÊÍÓÔÕÚÜ
- Polish: ąćęłńóśżźĄĆĘŁŃÓŚŻŹ‚„
- Czech: áčďéěíňóřšťúůýžÁČĎÉĚÍŇÓŘŠŤÚŮÝŽ‚„
- Russian: абвгдеёжзийклмнопрстуфхцчшщъыьэюяАБВГДЕЁЖЗИЙКЛМНОПРСТУФХЦЧШЩЪЫЬЭЮЯ№
- Dutch: àáèéêëïóöÀÁÈÉÊËÏÓÖ
- Danish: åæøÅÆØ
- Norwegian: åæøÅÆØ
- Finish: åäöšžÅÄÖŠŽ
- Swedish: åäöÅÄÖ
This feature should be used for 3 main reasons:
- To flag the text boxes that will need to be expanded to accommodate the longer translations. Since the generated pseudo-translations take into account the average text expansion when localizing into other languages, if a pseudo-translation is cutoff, some of the real translations will most likely be cutoff as well.
- To test the fonts to ensure they support all the necessary special characters for each language and that the glyphs for such special characters don't have any design issues. Since the prefix is formed by language-specific special characters, you will quickly see if some characters are not supported for a specific language.
- To flag hardcoded strings or non-localized art; if a string is not pseudo-translated or translated and it only appears in English in the game, it's either hardcoded or an image. A hardcoded string may require work from several people in the development team, so you really should get these flagged as early as possible.
As soon as the pseudo-localization feature is functional, you can perform an internationalization pass to flag as many of the issues above as possible before LQA starts. Flagging these early is important, since fixing them will require dev team’s resources (programmers, UI designers), which are much more scarce later down the line in the development cycle when LQA starts. Noticing and flagging these issues early before the start of LQA will also make the QA much more efficient.