Paul Rohr wrote:
>
> 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.
Paul, I suppose that you're aware, but the po files are just text (there
are not platform-specific)
> 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.
I've translated po files in windows, solaris and linux. The platform
used never was a problem.
> PO files are only "standard" on desktops which happen to not run Windows or
> Mac.
A good start :)
In addition, even if it's not the standard in windows, apps that use
gettext in windows work without a glitch, and I'm sure that windows
translators will be so confortable with a po file as with our string's
file.
> 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?
http://www.mail-archive.com/[email protected]/msg06799.html
In short, you have tools to merge old po translations with the current
one, and it's easier to use by the programmers
> 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.
Paul, do you really think that somebody will adapt something like kbabel
to the *ABIWORD* string's file?
> As annoying as our current platform-agnostic mechanism is, it hasn't stopped
> us from getting 25 translations already. That ain't shabby.
Nobody is saying that it doesn't (mostly) works. I think that Dom is
only saying that there are better ways
> By contrast, having en-US equivalents always show up as a fallback might
> tend to disguise the problem on a casual glance.
Sorry to be a bit arish, Paul, but the TODO icon is *WRONG*. The TODO
icon is way too much intrusive.
> 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.
It works great. A few months ago I installed the windows version of
gimp at work... it has some glitches (specially due to gtk in windows).
But the translation worked without a glitch. I just installed it, and
it showed in french.
Cheers,
--
Joaquín Cuenca Abela
[EMAIL PROTECTED]
