A showcase specimen

With Office 2007, Microsoft made an important decision; whether it was in response to the call of times or to get ahead of potential lawsuits is not our concern in this post. But the change Office 2007 brought along was significant, and Microsoft scored a point in our book by having switched to an open format and making the specifications public.

In spite of the fundamental flaws of Office products yet to be addressed even today, structural localization of complex Excel, PowerPoint, and even Word documents has benefited from the change. Turning these documents inside out has become just a bit short of a walk in the park, enabling targeted and automated xml-level modifications. Usually such profound adaptation is not necessary, as the focus is on the content, but in certain scenarios it is essential. We have been localizing Microsoft-certified examinations up to 23 languages since 2010, a task which is an exact fit for this approach.

Let’s assume that all UI elements, style sets, special features and hidden content are to be adapted to the target locale. All translatable content cannot be processed with common CAT tools, and some of the features need recreation of files from scratch to conform to the target locale fully. Moreover, manually redesigning hundreds of files would not only be extremely time-consuming, it could also bring about the unintentional introduction of errors, omissions and inconsistencies with the document specification, design and purpose. Finally, E-Learning content also necessitates that the target audience’s mindset, customs, and learning habits be reflected in the localized variants.

Disentanglement

This showcase challenge presents two dilemmas: what project management paths to implement, and how can localization be realized technically.

From the management perspective, we have to face two opposing deliberations. On the one hand, native input is required in all phases of the project to identify localizable elements and propose appropriate action. On the other hand, only controlled and focused project management can prevent potential mistakes spiralling downstream, and along these lines only certain phases should be outsourced. One of the solutions to cut this Gordian knot is to set up pause points to ensure the convergence of all input coming from native sources.

• Phase 1: Identification of common localizable, non-translatable elements, formatting properties and potential differences (Centralized)
• Phase 2: Understanding how the document will be used during the course of the examination (Centralized)
• Phase 3: Identification and evaluation of localizable elements and assessing content regarding educational conventions and performance (In-country, native)
• Phase 4: Setting large scale formatting which affects the entire document (Centralized)
• Phase 5: Creation of a project-specific localization guide and automatic QA profiles for engineers and translators drawing from the results of previous phases, including terminology, UI reference, document conformity (Centralized)
• Phase 6: Translation of body text and other elements separately (In-country, native)
• Phase 7: Setting small scale formatting and final format localization (Centralized)
• Phase 8: Performing QA/proofreading and consistency/conformity/congruency checks (In-country, native)

A prerequisite for this project control methodology is that content and elements can be identified, processed and adapted without all-around human involvement, presuming that keeping turnaround time and human resource investment at an acceptable level is a factor. In the current case, if it hadn’t been for the possibility to disembowel the files, we would have been left with less favourable options.

With this intimidating notion, let’s leave this post lopsided, and get to the bottom of how Microsoft localization can be achieved on the xml-level next week.