The translators I've worked with use robots like these to do much of the
out sounding like they were done on BabelFish. I've found that technical
religious to some people what the programs say. Something in one language
may translated totally obnoxious in another. I think the only best way to
enlist their help. Giovanni has helped me a few times with Italian ... he
the biggest and best localization shops have localization ENGINEERS that
use the tools you talk about, but the actual translations come from
Nope. Engineers don't care about these tools, really.
As a localization engineer you import/export the original files
in/from these tools, but the tools are used by translators to do
the real translation work.
What I'm talking about are CAT (Computer Added Translation) tools,
with translation memory, glossaries, fuzzy matches, etc.
Take a look at stuff like Alchemy Catalyst, or Trados.
I'm convinced that some of the translators do their work
with pen and paper at the kitchen table, with nary a PC in sight.
I am also convinced that some of the programmers do their work
with pen and paper at the kitchen table :-)
The localization engineers then manually create the .rc files from these
handwritings, or at best, copy and paste strings saved in .doc or .pdf
files from the translators. That is why localization engineers are very
sensitive and don't want to be called "translators". The reason is that
translators are not engineers, and vice-versa.
No, really, I don't know what is your experience, but a localization
company, no matter how small or big, will have to use the the type of
tools that I mention, if they are to survive.
If someone does such job with copy/paste, I would not call him an
Yes, you might have to do something like that once in a blue moon.
But that happens because some "smart programmer" invented a
"smart format" for localization (that standard tools can't handle
And even then, you probably put together a Perl script.
Even if they were, the tools you discuss don't give instant preview of
dialogs, etc. for skinned windows that are not standard dialogs or
The only way you know if a string fits is to see it running in the actual
skinned window. Neither do the tools show you whether a string that has
formatting placeholders, e.g.
Will the string for the product called %s fit here?
where %s is substituted at runtime
Translators don't care at all about strings fitting in dialogs,
or the exact look and feel.
That is the job of the localization engineer.
Translators don't resize dialogs, don't check for double hot-keys, etc.
All they need is context. See the string in the English dialog is almost
What they care about is productivity. And that is achieved with
reusability (translation memory, fuzzy matches, integrated glossaries,
AFAIK, these tools only work a fraction of the time, for the dumbest and
ugliest of UI designs that don't attempt to alter window styles and
based on program state.
Again, that is not their role. These are translation tools, not design
That simply is not going to work keeping up with
WPF, Silverlight, and other RIA.
All of them are formats designed by programmers who don't care/know
anything about localization/internationalization.
Each time someone comes with a new format, the whole localization world
struggles to handle the new crap.
Let's remember: localization is not only about strings!
Everything can change: colors, fonts, font sizes, images, alignment, etc.
So rather than waste time with these
"tools" that fall short of real life situations, why not just make sure
try it in real life?
I have explained: translators don't care about how stuff works in real
Same as good writers don't care about fancy DTP.
That is the job of someone else.
The system I designed was for Logitech, which supports many languages
Adobe and is mass deployed.
You don't know if is was a pain or not to use.
Or what are the quality tradeofs.
I guess the company that released the "all your bases are belong to us"
was also quite happy with he localization process :-)
Mihai Nita [Microsoft MVP, Visual C++]
Replace _year_ with _ to get the real email