Re: Unicode setting question
"Mihai N." <firstname.lastname@example.org> wrote in message
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.
I had not thought the translators used the tools with translation memory,
etc. If that is the case, I don't know why all the translations were
delivered to us via .pdf/.doc files. In another large company (not
Logitech) that uses an outsourcing service, in fact the translations were
delivered in a variety of free-text .pdf, .doc, or even .xls files, and even
formatted differently from one another. There certainly did not seem to be
one standard tool used for all the languages. So I am at a loss to explain
this. It's happened several times. At no time did the translations come
across as you describe.
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,
As I understand, the localization engineer gets a new build from development
and runs the resources into a tool with translation memory to get a list of
new/updated strings that need to be translated. It then exports these
strings into some plain text file. I presume the file is then translated on
the kitchen table in some country you or I will never visit, and gets sent
back, whereby the translation tool sucks it back it and integrates it into
the .rc file.
The the localization engineer build it to product a new resource .dll and
then runs the product with this .dll and checks for things like cut-off
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
No matter, whoever does things like check for cut-off strings (either the
localization engineer or translator) needs to run the actual product to see
And it is beyond the localization engineers that I have worked with to know
how to run a complex build to product the resource dll. It is not beyond
them to be able to drag and drop an xml file to the correct folder. In
fact, we saved 1 day per resource-cycle by switching from resource dll to
XML by removing the build requirement, since development did not have to
produce the resource dll for the localization engineer.
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.
And that's why such a "simulation tool" that does not show the actual screen
the user would see does not work even for Windows apps today (e.g. for
skinned apps or dynamic content), let alone for more rich apps tomorrow.
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.
Then the xml file scheme I designed was for the "someone else". The
industry as you describe is really broken. Someone is responsible that a
string is too long and is cut off, yet does not have the authority or
knowledge to do anything about it? Why not give that authority and
responsibility to the person actually translating the string so a shorter
translation can be substituted on the spot and the cut off text never
happen? That's what it's all about.
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 :-)
I'm sorry but that system was introduced in 2003 with Logitech SetPoint
which ships with each mouse/keyboard and not only is continuing today but
has spread to other divisions.
What is this "all your bases belong to us"? Logitech is not known to be