At 04:20 PM 3/8/01 -0500, Dom Lachowicz wrote:
>Since our .strings files are non-standard (as well as our using
>the .H files for other strings/resources), our translators can't use their
>favorite translation tools like KBabel or whatever the Gnome equivalent is.
Whoa. Let's unpack that sentence a bit.
1. Please decouple the .h issues from the .strings issues. Moving strings
out of .h files is worthwhile, regardless of the mechanism we use. (For
more on the remaining .h issues, see below.)
2. If anyone knows of an efficient XP "standard" for globalizing strings,
by all means speak up. To my knowledge, most XP products still use parallel
platform-specific resources and tools for packaging and maintaining their
translations.
The fact that we ship the **exact same unmodified** translations on all our
platforms is unprecedented, AFAIK. I neither know nor care what platform
translator #42 works on because it doesn't matter. They're cleanly encoded
in XML, so you can do whatever you want with them. I suppose I could claim
that this makes *us* the standard, but that'd be silly, so I won't.
PO files are only "standard" on desktops which happen to not run Windows or
Mac. I haven't assessed that technology to decide whether I think it
*should* become such a standard. I'm just claiming that it ain't no such
animal until you or someone else stops lobbying and does the work to make it
one.
3. Are tools the real issue here? I wasn't aware of KBabel per se, but I
can see how that could be a real issue for translators who:
- run Linux,
- translate lots of other packages, and
- are familiar with .po files and tools.
That doesn't help all of our translators, but for those who do, it'd be
nice. Is this tools issue really the main thing driving the gettext
advocates, or is there some argument about the technical merits of that
particular technology that I haven't heard?
Honestly, those tools aren't rocket science, and once we've done the work to
get *all* our strings out into a single file, people could easily adapt any
well-designed tool to read and write this format as well.
As annoying as our current platform-agnostic mechanism is, it hasn't stopped
us from getting 25 translations already. That ain't shabby.
>>I'll assert that the biggest problem with the existing mechanism isn't the
>>strings, it's the menus and toolbars. If anyone would like to figure out
>>how to get *those* loaded from an external file, wouldn't we all be a lot
>>better off?
>
>I couldn't agree more, at least with regard to the toolbars. There is no
>real reason that I can think of that the menus need to be how they currently
>are. A string is a string. Period. And the only reason that the toolbars
>need to be handled a little differently is because of the XPM icons that
>have to be internationalized.
Note that one other reason for all those .h files is to allow certain menu
or toolbar items to be rebound or eliminated entirely if they're not
appropriate for that locale. (Jeff had some cases in mind, but I don't
recall offhand what they were.)
Would everyone be comfortable if we removed the ability for localizations to
change the menu and/or toolbar layouts? If that flexibility isn't needed
for any of our locales, then Jeff wasted an awful lot of time implementing
it.
>Now I'd like to suggest a RFP maybe - no more TODO icons/strings in menus
>and toolbars for non-translated strings. We should display the English
>equivalent without fail if no localized version exists.
I'd be interested in more opinions on this. The idea of TODOs is that
they're an eyesore, which theoretically motivates folks to figure out how to
fix them. There's something blatantly wrong, and this shines a harsh
spotlight on it.
By contrast, having en-US equivalents always show up as a fallback might
tend to disguise the problem on a casual glance.
>>Even if we do the work to switch to gettext on all platforms (or some other
>>mechanism), wouldn't we still have the menu and toolbar problem?
>
>Probably not with a little creativity and a bit of deviousness...
Fine. As always, I'd love to see how this is going to work on non-Unix
platforms. Until I do, the debate is unlikely to gain much traction with
me.
Paul
