|
Here are a few more of your questions that I chose not to send to the
tool vendors when I ruined their Christmas break with some of your other pesky
questions. (-;
One person asked whether TEnT (translation environment tool) vendors should
look more seriously into adding features of localization tools, such as Catalyst
and Passolo (or any of the smaller competitors). The questioner alluded to the problems that
are often caused by localization projects being pushed through
"normal" TEnTs "causing a host of problems and necessitating a
lot of downstream cleanup."
First of all I agree. There can be a lot of post-processing with
software files that have been translated as if they were "normal"
documentation files. That should not be too surprising since this is a) the
very reason for localization tools in the first place and b) why localization
tool vendors would tell you that they don't view their tools as translation
tools (though they all share this feature) but as development tools.
Secondly, there are some TEnTs that have some localization features (Transit, Trados TagEditor, and Across
allow you to translate .exe or .dll files, memoQ
has a component to translate and localize .resx files, and the latest couple of
versions of SDL Trados come with a
pared-down version of Passolo).
But, thirdly, this really is not the answer to the question. It's fine
to be able to translate some of these individual formats with a TEnT, but if
you are providing localization services in a professional manner you don't want
to limit yourself to just a couple of formats here and there. You'll need to be
able to work on a much wider range of file and software development formats -- and
you'll need a tool whose vendor is able to truly devote resources to the
different formats and be able to respond to new developments. This is something
that I believe TEnT vendors can't provide because there won't be any return on
investment: the group of users interested in these formats and localization
features is too small to warrant large investments (put differently: who is
going to flip the bill for that kind of investment?). Plus, the market of
localization tools is crowded as it is. There are the two big ones (Catalyst and Passolo) along with a host of other smaller players (RC-WinTrans, Multilizer, Language Studio,
Lingobit Localizer, Sisulizer, and Visual Localize to name a few). The only way that I could see a
feasible extension into localization territory for a TEnT vendor would be
through partnerships -- sort of along the lines of what SDL did (maybe without
the outright takeover component.)
And here is one more thing (and I know that I am entering touchy
territory). Localization has changed. One of the main emphases has been on developing
tools that would get into formats that "normal" tools just could not
get into (things like .exe, .dll. or .ocx files) and then perform translation
and all other localization-related tasks (resizing, testing, etc.). This
stumbling block is on the verge of going away. While there are still some
legacy applications that use these formats, most new applications are written
in development languages that place their translatables in XML formats, which almost
any tool can get into. While there are still tasks that are specific to localization
tools and typically not performed by TEnTs, it's a different emphasis. One of
the greatest challenges that I see with web applications and content management
systems is the presentation of context for the translator, and this is an area
of needed improvement for both localization and translation environment tools.
Here was another question: Is there any prospect of having the output
of one TEnT be acceptable (interchangeable) to the format of some other tool?
One could write a lot about this (ask all the saintly folks who work on
the development of standards for instance!), but if I wanted to answer this in a
single word, the answer would be: XLIFF. (I know, this is actually not a word
but an acronym!)
At the risk of repeating myself, I think XLIFF is the most promising and
complete of all exchange formats in our industry. Unlike TBX for termbases and
TMX for translation memories, it is geared toward the exchange of translation
data itself, but it can and will also be used for the exchange of translation
memory data.
This XML-based format was originally created for localization-related
formats (mostly resource files and XML-based files), but now it can be used for
virtually any source format. In fact, tools like Heartsome, Swordfish, and Trados Studio use it as their internal format for all translation
tasks. Beyond the actual translation data itself, XLIFF files also contain information
about the translation data (such as status of the translation) and can contain
all the data needed to recreate the original file. At this point there are
still some hiccups in the exchangeability between tools -- mostly due to
different versions of XLIFF that the different tool vendors use -- but at some
point in the near future, it truly won't matter what tool you use if it supports
XLIFF.
(Note that this will work only with
desktop-based projects. For server-based projects, exchangeability will be much
harder to achieve.) | 
