Re: Unicode setting question
"Mihai N." <nmihai_year_2000@yahoo.com> wrote in message
news:Xns9AAF80DFD11BEMihaiN@207.46.248.16...
It allows localizers to edit standard XML files and see the results
immediately in the application without waiting for the resources to be
built
with proprietary resource compiler tools and a complex build system.
They don't care about that.
People don't understand how localization work, beyond the small shop
where a student comes and does some translation (that's not localization).
There are now dedicated localization tools, that can handle all standard
formats (including .rc). They give you instant preview of the English
and translated dialogs and menus. They can do a lot of stuff.
You come with a proprietary format, you break all that.
Why would I want to install a crappy alpha version of your software
on my machine, and search for the right string or dialog in an
application with 200 dialogs, when I can have it in my localization
tool, at the tip of my finger?
Imagine this: let's replace the .rc format with some XML that you
edit by hand, is loaded at runtime, and you can see in the
running application your what you did.
Would you like that? No, because you have a resource editor!
With wysiwyg capabilities. And you don't have to search for the dialog,
you are there.
Localization is a serious business. Having someone to translate in
Notepad is like contracting a student to to program C++ in Notepad.
Translators are professionals, just speaking a language is not enough.
So no, it's a bad idea, pushed by people who don't understand how things
work in the localization *industry*
Mihai, you are certainly the best localization engineer I personally know by
far, but all the other shops I've experienced do not do it this way. Even
the biggest and best localization shops have localization ENGINEERS that may
use the tools you talk about, but the actual translations come from
who-knows-where. 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. 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.
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 windows.
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
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 content
based on program state. That simply is not going to work keeping up with
WPF, Silverlight, and other RIA. So rather than waste time with these
"tools" that fall short of real life situations, why not just make sure and
try it in real life?
The system I designed was for Logitech, which supports many languages like
Adobe and is mass deployed.
-- David