How do we make Office? Ensuring the UI looks great in all languages

Greetings Earthlings!

It’s me “-----“, continuing my mission to bring you up to galaxial speed on the wizbang concepts of Office. Let’s blast off…

Today I’d like to give you a glimpse of how we test Office 2010 so that it looks great in so many languages. So get those neurons in place!

As technology brings people closer, it is highly desired to architect software people can use it in their own language. Consider an Office application like Word. In order for Word to be used across the world, it should be designed to handle different languages. Some languages are written in a Right-To-Left (RTL) direction, like Arabic and Hebrew, while others are written from Left-to-Right (LTR) like French and Thai. In order to handle such cases, User Interface (UI) should be designed and verified to ensure that it can grow and shrink and follow various language characteristics without causing troubles once translated in another language (localized). For example, text in some languages can be longer than the corresponding text in the original language. This would cause the text to be cut off if there is insufficient space for displaying.

Pseudo-localization: What is it?

Office applications ship globally with UI appearing in many languages. This would suggest that testers test each localized application for all languages. First, translators will translate each word into the corresponding language, and then testers will verify the applications’ behaviors. If testers discover functionality defects, translations might need to be changed after the fixes. This turns out to be a time and resource expensive process, and if adopted, Office would take many years to ship in multiple languages.

Here comes Pseudo-localization to the rescue. Pseudo-localization is a process that reveals potential difficulties with localization early enough in the development cycle. It does so by replacing localizable text (particularly in a UI) with text that imitates the most problematic characteristics of text from a wide variety of languages. The resulting text is in fact a translation of the English text into a “pseudo” language that is readable by someone who can read English. It also differs in length and is usually much longer compared to the original text (generally English). This helps ensure cases where the translated text is longer than English text are verified. Sometimes, pseudo-localized text is decorated with brackets or other delimiters to identify cases where the target text could be truncated.

Here is an example of pseudo-localized resources using the artificial language described above. Suppose that we have an English resource string as follows:

Use Pseudo-localized Build

With simple accented non-English character replacement as the pseudo language, the pseudo-localized string would become:

Use Pšeûdõ-locâližëd Büïld

Adding a start delimiter as “[:“, and end delimiter as “]”, it becomes:

[:Use Pšeûdõ-locâližëd Büïld]

If we increase the length of the string by appending some characters, such as “??????šÂ´ß??”, it finally becomes:

[:Use Pšeûdõ-locâližëd Büïld??????šÂ´ß??]

Suppose that we have the above string in this example in a pseudo-localized application and now we use this for testing. If the string remains as original English text, we find an un-localized bug possibly due to hard-coding of the string. If the start and/or end delimiters are missing, we find a string truncation bug (i.e., the UI elements are not stretched enough to hold the string). If any of the characters are not displayed well, we find a string rendering bug related to code page handling (e.g., font linking issues). You can see that many potential issues can be found even with the simple pseudo language of the example. In some cases we also find functionality issues due to the presence of certain characters in strings and where they are used.

The following is an example of the look and feel of the Word Options dialog in its pseudo-localized form:

In short, pseudo-localization is a cheap and automated way to create a rapid prototype of a localized build – the pseudo-localized build. Using the generated pseudo-localized build will enable testing for defects that would prevent effective localization of the software application for the global market.

Ok – that’s pretty much it!  Great Galaxies – that’s worthy of a meteor shower! 

Happy [:Reâdiñg???? ???? Ii????'.]!

Martian

As stars shine, so must I give special thanks to Yixiang Huang and Zeeshan Furqan for their invaluable contribution to this article. I would also like to give a galactic thanks to Murtuza Shakir, Reda Elkhadiri, J. Barrera, Ryan Hamshire and Tom Lavoy for their assistance. These Earthlings (i.e. contributors) are Software Development Engineers in Test or Program Managers at Microsoft with the Office Global Experience Platform team, in Redmond, Washington, USA. Their team work behind the scenes and specifically focuses on ensuring that Office applications are ‘galaxy-ready’!

The example companies, organizations, products, domain names, email addresses, logos, people and events depicted herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, or event is intended or should be inferred.