Continued from front
page:
To put it all into context, here are some statistics:
- Last year more than 24 million words were localized on the
content Web sites that we manage, including Product Catalog, Solutions, Direct Access,
TechNet, and even
Backstage.
- More than 400,000 words were processed just for Backstage,
which is translated into 24 languages.
- In addition, nearly 1.3 million words were translated for
e-mail newsletters such as Exploring Windows, Office News Service,
the MSDN Flash, and the TechNet Flash.
- Another 700,000 words were localized for more static projects
(aka "one-time" localization jobs). For example, strings for Web
services such as Search
and Profile
Center.
In the localization world, it is common to
have English come first, and then all other languages localized
based on the English model - a tedious way to translate. As we
reported two years ago (see "Taking A
Global View: Localizing for the Web"). It was once common for
our localization process to start only after design of the Web site
for the U.S. market had been completed and shipped. Not only did
this ensure large delays between U.S. and international releases,
but it also required resources for re-engineering the templates and
editing the content to remove any U.S.-specific content. Now sites
are designed to be global from the start. Even double-byte
languages, such as Chinese and Korean, and bi-directional languages,
such as Hebrew, are accommodated as easily as English.
Philosophy
With challenges like these, we need a
consistent philosophy to survive - better yet, thrive - in the
ever-changing world of localization, something we have been
perfecting in the last eighteen months. Simultaneous shipping of
content to 47 subsidiary sites (Microsoft's presence in countries
other than the U.S.) and the implementation of database-backend Web
tools have made localization more efficient; within this model we
are able to provide the subsidiaries with instant access to the
latest technologies and a content workflow that is much more
streamlined.
Our philosophy of localization has not changed.
First of all, process is the key to localization success and to a
smooth and efficient workflow. Second, we never forget our
customers, both internal and external, the subsidiaries and the end
users. Third, we work closely with the product planning, program
management, development and test teams to make sure that they
understand the requirements of worldwide programs and how to design
projects with a global perspective. Our team knows and cares about
the needs of the international Subsidiaries.
For example,
when designing the registration system for microsoft.com, the
Localization Program Manager worked closely with the program
management and development teams to ensure that address forms on the
site were regionalized, international requirements were included in
the privacy statement, and that the architecture of the system
allowed for different character sets and country-specific
customizations. Planning and cross-team cooperation of this nature
occurs before localization begins.
And last but not least,
we get and keep great localization vendors who localize Web content
and applications both quickly and carefully. They are critical to
our success.
Process
We have implemented the best
tools to create great process. In May of 1999 we launched version 1
of our Product Catalog publishing tool which includes a worldwide
localization workflow, and we were pleased with the results. The
Unicode support in Microsoft SQL Server has taken the place of more
antiquated approaches to localization (see Figure 1).
 Figure 1. Unicode strings for different
languages displayed from a SQL Server database. (Click to
enlarge)
On top of the database, we constructed a
workflow facility that enables subsidiaries and vendors to input and
localize content applicable to their markets, complete with a
queuing schedule. The process also lets them know when they are next
in the queue to input content to publish. We were very excited about
this new tool because we no longer had to deal with a manual
workflow.
However, there was one key challenge despite the
excellent progress we had made. We discovered that it was not good
for everyone. Some of our vendors found it difficult to log on to
our intranet and - because of slow overseas connections - very
expensive. We decided that we needed to change the process in order
to accommodate our customers, both to keep them happy and the cost
low. So we are creating a method for them to download the files and
work on them offline.
Tools
Out of all this effort
and learning, of course we are getting smarter about what it takes
to build and implement truly worldwide tools. The next version of
our worldwide localization workflow tools will have a crystal clear
UI within which our subsidiaries worldwide will be able to continue
to choose what they want localized and input their own unique
content.
For example, we will extend the Product Catalog
publishing tool model to other sets of content, offering our
subsidiaries a list of content and they select what they want to
have translated. They also have the ability to add their own local
market content, and then everything that needs to be translated goes
to the outsource Localization Vendors located in-market. Our goal is
to encapsulate everything into an XML file and put it into a
standalone third-party localization tool. (For more information on
the evolution of our catalog tool, see "Building
a Better Product Catalog: Putting SQL Server 7.0 and XML to Work in
a Three-Tier Solution".)
We are now moving toward using
a localization tool with a "translation memory" engine that keeps a
record of all content that has been previously translated. This
enables us to accurately determine how much content is truly new and
how much can be recycled from previous projects whenever we start a
new round of localization. We estimate that we can reduce the volume
of localization work by up to 25 percent in this manner. For
example, a string such as "The following is a list of frequently
asked questions" can be put into memory and reused thousands of
times. It makes no sense to reword it or translate it again. In
addition, translators can use the tool to quickly check how a
specific word or phrase has been translated in other contexts, which
is crucial to ensure consistency across the many properties on which
we work.
In fact, we currently have a pilot program for the
Search Web Service, one of our smaller projects. In this program,
the strings are exported as XML, dropped into the localization tool,
translated, and then returned. We want to see how the platform for
XML needs to be tweaked so the localization tool can pick it up
without any problems. Once this localization-friendly XML format is
perfected, we can use it for other projects including our worldwide
localization workflow tools.
Relationships
Everyone on the Microsoft Web
localization team works to support the subsidiaries and what they
need from the site. We serve as a channel between the subsidiaries
and the corporate team in Redmond and work with them on projects
such as our worldwide registration system, application string
localization, requirements for new global releases, and other
globalization and localization priorities. Our relationship with the
subsidiaries is a two-way street: We respect their local market and
industry knowledge and try to learn as much as we can from them.
This, in turn, adds to our success.
For example, in May and
June, our localization team hosted Platform Summits in Asia and
Europe with our subsidiaries. We shared plans, brainstormed on new
ideas, and cultivated our "virtual team" approach for two days,
resulting in a better partnership to the shared challenges of
localization and globalization.
The other part of our job is
our relationship with the localization vendors. These outside
companies operate from their own offices, most typically "in
country" to the Microsoft subsidiary. They not only provide the
translation work but also offer a local market expertise taking the
work beyond only translation. Our main connection with the vendors
is a project manager (PM). For example, the project manager at the
Spain vendor, a native speaker, works in Madrid and employs local
translators in Spain. This project manager and his team are able to
provide us with crucial insight and culturally specific conventions
in language and style to make the site truly Spanish for the local
Spain market. Because much of our job is a thorough evaluation of
the quality of the translations they do mapped to the overall goals
of the project and needs of the local market, our relationship with
the PM is crucial.
Before we hire the vendors, they must
take a standardized test so we can ascertain their level of
expertise. Typically our project size is smaller and we have a
faster turnaround time required, consequently we need a vendor who
works quickly and who can speak to the local customer. This is vital
for localizing content.
It is critical to maintain long-term
partnerships with vendors. One reason is that the learning curve can
be steep, so it is often in our best interest to keep these
relationship vital. If the subsidiary is happy with the localization
vendor, we want to continue to do more projects together, resulting
in higher quality content.
We also serve as an intermediary
between the subsidiaries and vendors. If a subsidiary sees the
quality of a vendor’s translation as sub-standard, we establish
communications with the vendor to determine: Is it the quality of
the content, or the code, or could it be something else that is
affecting the translation? Sometimes it could be something
relatively simple such as unclear project instructions. We work with
both the subsidiary and the vendor to develop and maintain this
relationship. Maintaining high quality for each project is our job.
The Microsoft Web localization team ensures that worldwide
features are built into all Web applications. With the innovation
and utilization of Unicode, SQL Server, and XML, all languages
become equal and we can work with English, or German, or Chinese, or
Hebrew, or Japanese. For us, English truly is just another language.
|
 |
|
|
Microsoft's Localization Workflow for the Web
Here is a
typical workflow for our localization
process:
|
| 1. |
The Localization
Program Manager (LPM) works with the development team to
ensure that globalization and localization are "baked
in" to the project specifications from the beginning and
not as an afterthought. Development codes strings and/or
content so that it's easy to extract into a localization
tool. The corporate team peruses the file, makes
necessary changes, and then hands this off to the
Localization Program Manager.
|
| 2. |
The LPM
"pre-localizes" the file by performing quality assurance
on the strings, ensuring that everything is included and
clearly outlined for the localization vendors, and then
sends the final file - edited, frozen and ready for
localization - to the vendors with instructions and a
deadline. The LPM works closely with the vendors to
answer any questions about the project and/or files,
such as what a particular string means, what the right
context is, the right screenshots of pages, and so on.
The LPM also makes certain that the vendors finish the
project on time.
|
| 3. |
The vendors send
back the localized versions of the content to the LPM
who does quality assurance, on the now 29 files (instead
of just the one English file!).
|
| 4. |
The LPM sends
these 29 files to each subsidiary for review, along with
similarly "pre-localized" English versions customized
for the non-US English sites. The subsidiaries examine
many things including functionality, linguistic
cohesion, and images, as well as local-market
suitability. The LPM makes sure that the subsidiaries
are happy with the vendor’s work and will collaborate
with the vendor to make any requested changes based on
subsidiary feedback.
|
| 5. |
The subsidiaries
may also provide the localization team feedback and, if
necessary, open "bugs" in a centralized bug database.
The LPM works with the development and test teams to
ensure that all bugs are
resolved.
| |
| |
TechNet
