About the author: Jost Zetzsche is an ATA-certified English-to-German translator and a localization and translation consultant. He co-founded International Writers' Group on the Oregon coast and sends out a free, biweekly technical newsletter for translators (see www.internationalwriters.com/toolkit).
Depends on who's asking, I guess. Does the average translator who every
once in awhile translates software need a software localization tool?
Not necessarily. Does the translation agency that offers "localization
services" need one? Well, they should at least be aware of the tools
out there and be ready to make the investment when the time comes. Does
the end client who translates his software product into one or several
languages need it? In my opinion, either he or his language provider
absolutely does!
All this information doesn't help much if you don't know what software
localization tools actually do. So, here goes:
Ten or fifteen years ago (and in many cases even today), software was
translated by
finding out which files contained translatables (in the case of
most Win32 applications, the translatable strings were typically
located in binary EXE or DLL files, i.e., files that cannot be opened
with a text editor),
breaking (=decompiling) these files apart with a development tool
into numerous individual "flat" files (such as text-based RC files),
translating the RC files in a text editor or in a translation
memory tool,
combining (=compiling) these files back into the original EXE or
DLL files,
testing these files extensively for cut-off text due to text
expansion or any other errors that may have been introduced, and
starting the process from scratch if any change in text occurred
during the development cycle or any other editing had to be done.
Sound complicated and convoluted? Well, it was (and is).
Some of the more sophisticated companies such as Microsoft and Corel
started to look for other solutions. They developed internal tools that
performed the following functions:
— allowed developers to test the software before translation to
determine whether a translation could indeed be performed into more
complex languages such as Arabic/Hebrew or Chinese/Japanese/Korean
— allowed translators to directly go into the binary software files to
translate those and build a glossary during the translation that
functioned as a translation memory
— allowed translators to see everything in a WYSIWYG ("what you see is
what you get") format and resize text fields that needed to accommodate
text expansion or contraction
— allowed the automatic testing for various errors
— eliminated the need for the various compilation procedures and at
the same time streamlined updates to the software (like for a new
release or bug fix), because the old glossaries could be applied and
only new text needed to be translated
This, in a nutshell, is what software localization tools still do
today, although they have included other development formats, most
recently the new Microsoft development standard .NET or XLIFF (the
translation exchange format that was discussed in the last newsletter).
While Microsoft decided to keep its tool, LocStudio, internal, Corel
decided to market its tool, Catalyst, to the rest of the translation
and software development community. Catalyst, today owned by Alchemy
Software (see www.alchemysoftware.ie), is the market leader in a field
with numerous other players, many of which have remarkably similar
feature sets. (More than in any other field I know of, there is a
plethora of blame that unofficially goes around between the different
vendors about copying features, etc.)
Here is a list of the involved players:
— Catalyst: Supports Win32, .NET, Java, XML, XLIFF, and numerous
database types and offers an interface to Trados applications.
— Passolo (see www.passolo.com): The second-largest player in the
market and the most formidable contender to Catalyst. Originally
developed for medical applications, Passolo today supports Win32,
Delphi, Java, XML, XLIFF, and offers an interface to Trados and Transit
memories and terminology databases. It also supports .NET, possibly in
a more sophisticated manner than its competitors.
— RC-WinTrans (www.schaudin.com): Originally a tool specialized in the
translation of RC files (thus the name — it boggles my mind that they
haven't changed it). Today supports Win32, .NET, Java Properties.
— Multilizer (see www.multilizer.com): Finnish tool that originally
was designed for Delphi. Today it also supports Win32, .NET, Java, XML,
and database contents.
— SDL Insight (see www.sdl.com/products/sdlinsight.htm): Product in
the SDL tools suite that plugs in to all the other SDL tools, including
SDLX. Supports Win32 and .NET.
All of the tools come in several editions that have radically different
price tags, and many of the above-listed abilities are sold as separate
plug-ins. Typically there is a translator edition that excludes some of
the more development-oriented functionality, and a developer or
localizer edition that contains all the functionality. Catalyst also
comes in an edition that allows the developer to create files that can
be worked on in a freely downloadable edition for the translator (the
Lite or QuickShip version).
To come back to our original question, when these tools were first
released, software developers across the board became nervous. They
were afraid that a new development-oriented tool would likely cause
problems — as most of us know, developers feel quite protective of
their "baby," the software. At this point, however, it's clear that
these fears are completely unwarranted. Unless software is completely
unique and customized in its make-up, it's not only safe to use a
software localization tool, it's silly not to — and a great waste of
money, time, and energy to boot.
Home
