After succeeding in your local market, many will look at entering international markets, where localization of your software GUI may become a necessity. Often, a localization group is tasked at this point with converting the application into other languages, including its GUI.

All applications containing a graphical user interface (GUI) rely on text and graphics to enhance the interface with the user. This often takes the form of icons, menus, dialog boxes, tool tips, and messages.

Traditionally, the process that is followed begins with translating the GUI text. Then, the geometrical X and Y coordinates of text in the dialog boxes are changed to accommodate the typically larger text strings resulting from the translation.

After the translation and resizing are completed, the application is compiled. Quality assurance (QA) is then performed to ensure the accuracy of the translation and location of strings, as well as the absence of truncated strings, corrupt characters, or hard-coded text.

When all the problems are reported, localizers or developers must essentially repeat the initial steps:

When n languages are involved, the above process will take place 2n times, twice for each language. The same problems are often reported by different language teams, and then verified by those same teams.

Pseudo-translation can be used to resolve many localization problems before any translation takes place, eliminating the majority of the problems that are redundantly reported by the localization QA teams. Here is how:

1. Detecting encoding problems

By placing or replacing target characters in all GUI strings, you can detect character-encoding issues in the source files.

Here's an example of two strings from a C resource file, with their respective pseudo-translations in Japanese. In the following examples, Japanese characters replace the vowels in all English words. Each string is augmented by predefined pre- (日本) and post- (本日) text.

This technique enables any of your developers to test the product, since the GUI, with some familiarity to it, is still legible:
IDS_TITLE_OPEN_SKIN "Select Device"
IDS_TITLE_OPEN_SKIN "日本Sイlイct Dイvウcイ本日"

IDS_MY_OPEN "&Open"
IDS_MY_OPEN "日本&Opイn本日"

If your text is not properly encoded, you will see junk characters instead of Japanese characters. The result will display as one of the following:
IDS_TITLE_OPEN_SKIN "Select Device"
becomes    IDS_TITLE_OPEN_SKIN "??S?l?ct D?v?c???"
or             IDS_TITLE_OPEN_SKIN "□□S□l□ct D□v□c□□□"
or             IDS_TITLE_OPEN_SKIN "ÆüËÜS¥¤l¥¤ct D¥¤v¥¦c¥¤ËÜÆü"

After compilation, testers can easily detect corrupt characters and fix any encoding issues in the application. This process eliminates redundancy caused by errors in encoding.

2. Detecting hard-coded strings

Another benefit to pseudo-translation is the ability to detect hard-coded strings in the GUI before the localization starts.

Consider the above example after the pseudo-translated GUI files are compiled. Instead of Japanese characters in the strings, you will see intact English strings in the GUI.

IDS_TITLE_OPEN_SKIN "Select Device"
IDS_TITLE_OPEN_SKIN "日本Sイlイct Dイvウcイ本日"

IDS_MY_OPEN "&Open"
IDS_MY_OPEN "&Open"

Strings that remain fully in English (such as “&Open”) indicate that they are still embedded in the code and need to be externalized into the resource files.

Externalizing all the strings to translate before translation starts minimizes rework, translators minimum fees, and the need to re-translate files after missing strings are added to them.

3. Allowing for string expansion to expand dialog boxes

1. No significant last-minute rework to source code to remove encoding problems will be needed.

2. Hard-coded strings will no longer need to be localized at the last minute, requiring updates to your resource files in all target languages.

3. Minimum resizing will be needed for each of the target languages.

4. QA time is minimized.

5. Overlap work among the different language QA teams is eliminated.

Perhaps the best part about pseudo-translation is that it does not require any language skills. Your developers or SQA staff, with the help of scripts or inexpensive off-the-shelf software, can perform the task – but only if you schedule and plan for it.