英语论文网

key document set in 12 languages on time. They did, however,
allow for a decentralized organization of the production
chain, and at least all actors involved were working in the
same PC environment.
The real jolt for localization came from the profusion of
small companies developing and marketing clever utilities and
tool sets that finally evolved into memory tools and CAT
THIS ARTICLE WAS FIRST PUBLISHED IN MULTILINGUAL COMPUTING & TECHNOLOGY #55 VOLUME 14 ISSUE 3 APRIL/MAY 2003 81
THE USE OF XML
IN LOCALIZATION
Hans-Günther Höser
program suites. In the resulting boom, most of the big localization
players still on the market took off. But the enormous success
of PC editors which produced content exclusively in proprietary
formats, among other causes, forced us to abandon
hope in getting machine translation off the ground one day.
WordPerfect, WinWord and FrameMaker quickly became the
most popular editing tools, and we were still struggling with
incompatible RTF versions when a new storm appeared on the
horizon. The Internet had brought HTML to the forefront.
Until Office 97, you needed third-party converters and a lot
of tweaking to get your content displayed on the Web.
However, after the thriving success of comet companies that
cashed in on HTML converters, big players such as Adobe,
Corel and Microsoft soon adapted to demand by providing
built-in conversion facilities for their editors. These converters
produced — and still produce — a proprietary form of
markup language. The reason seems obvious: besides displaying
content in a browser, “proprietary” HTML has other
important objectives. Ideally, it should render the initial application’s
WYSIWYG quality without too much loss, should be
backward convertible and should be portable to most of the
other applications in the program suite. Some cynics, however,
venture another reason: to make sure that the HTML and,
more recently, XML files produced by these program suites
will not work properly in their competitors’ environments.
Converting between competing editors, between different
applications within the same suite or even between different
versions of the same application has always meant a lot of
reformatting, especially if you want the same look and feel for
printed documentation, WinHelp and the Web. More than just
a technical challenge, this also represents a commercial issue:
why would anyone want to wait and pay a lot of money to get
the PDF, HLP and HTML versions of localized text when only a
few words change between the different output formats?
Localization tools restrict their users to a limited number
of file formats, often don’t even support all the features
inherent in these formats and store proprietary formatting
information in the memory. This is the main reason why
leveraging from Microsoft RTF (for example, WinHelp) memory
is disappointing when translating standard HTML files or
the other way around.
HTML went on to pave the way for XML. To understand the
growing importance of markup languages, it is worth considering
the contrary effect the Internet produced on localization.
On the one hand, since everyone quickly acknowledged
that English is not yet the world language shared by all educated
people connecting to the Web, the Internet brought with it
a growing need for localization. O