After succeeding in your local market,
many will look at entering international markets, where localization of
your software graphical user interface (GUI) may become a necessity.
Often, a product localization group or a technical translation services
group is tasked at this point with converting the application into other
languages, including its GUI.
All applications containing a 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
|
Figure 1
English original dialog
|
Strings expand in size with
translation. The percentage of expansion varies according to the
source language, target language, and size of the source string.
Pseudo-translation allows you to
expand the size of the string by any percentage you think your GUI
can absorb.
In the example below, text is
pseudo-translated into French and expanded by 15%. The source dialog
box is shown in its initial form in Figure 1.
|
|
Figure 2 Dialog
box after pseudo-translation in French and insertion of a pre- and
post-text character (_) |
In Figure 2 you can see how the
pseudo-translation technique permits correct resizing due to the
fixed pre- and post-delimiters (_) that are added to help identify
the beginning and end of each string. The characters added to each
string expand its size by 15% causing many to be truncated.
|
|
Figure 3 Pseudo-translated dialog
after resizing
|
Figure 3 shows pseudo-translated
dialog after resizing. Note the correct sizing to see the pre- and
post-text character (_) at the beginning and end of each string. If
any strings are hard-coded, they will appear in the dialog box
intact.
When character-encoding, hard-coded
text, and resizing are corrected in the source files up-front,
localizing them into other languages will become much easier,
faster, and more efficient.
|
The benefits of pseudo-translation help you avoid the problems that can increase
your localization costs and delay your release:
-
No significant last-minute rework to
source code to remove encoding problems will be needed.
-
Hard-coded strings will no longer
need to be localized at the last minute, requiring updates to your
resource files in all target languages.
-
Minimum resizing will be needed for
each of the target languages.
-
QA time is minimized.
-
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.
If they are too busy, which is the main
reason we hear why it is almost never done,
contact
us! The savings are well worth the effort.
You may add a link on your
corporate Web site to any of our articles
