non-Unix gettext (was Re: how should we localize locale names?)


Subject: non-Unix gettext (was Re: how should we localize locale names?)
From: Paul Rohr (paul@abisource.com)
Date: Mon Mar 12 2001 - 16:09:33 CST


At 02:29 PM 3/10/01 +0100, Joaquín Cuenca Abela wrote:
>Paul Rohr wrote:
>> 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)

Yes. With the exception of CRLF issues, the files aren't platform-specific.
The relevant question is how platform-specific the *tools* are. Remember
that cygwin != windows.

>> 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.

Are you saying that you've edited a PO file on all those platforms (and not
gotten bit by CRLF issues)? That I'll believe.

Are you saying that you've written native GUI apps on those platforms to use
those files? If so, where are the patches? ;-)

<bait>
Maybe I'm really as obtuse about this as people keep implying, and it really
*is* that easy to use gettext in native Windows or Mac apps. If so, I guess
I keep expecting some gettext advocate to demonstrate how easy this is by
producing a *native* solution that Just Works. That would certainly shut me
up.

The only place I've *ever* seen gettext used was on either Unix, or a very
Unix-y port. Why is that?
</bait>

>> 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.

Show me happy apps and happy translators. I keep seeing people doing
everything *but* what you suggest.

>> 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/abiword-dev@abisource.com/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

Thanks for the pointer. Next time I'm online, I'll reread it. In the mean
time, you'd gain a lot more points with me if you'd acknowledge that gettext
tools *do* inherently favor translators on your platform of choice.

To convince folks on other platforms, you need to either do the work, or
come up with reasons why it'd be better for *them*, too, and not just for
you.

>> 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?

Why not? People develop tools when and if it's worth their while. People
have done so for Mozilla, and they could conceivably do so for AbiWord.
(I'm not saying they should, I'm just saying they might.) Adding another
syntax isn't rocket science.

If Owen can do the relevant parsing in what, a 100 lines of perl, how hard
would it really be for a Unix developer to hook the relevant code into
KBabel? It's not like they'd need access to a Mac or Windows development
environment, which seems to be the current hurdle to making gettext Just
Work in AbiWord.

In the mean time, everyone will continue editing text files by hand.

>> 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.

I have a copy of the Win32 version of the gimp, too. It's a truly
impressive hack, but it's by no means a native app. The thought of trying
to dig through all those sources to extract the relevant bits of code is not
particularly appealing.

Is that the only use of non-Unix gettext that you know of?

Paul,
trying not to troll



This archive was generated by hypermail 2b25 : Mon Mar 12 2001 - 17:06:31 CST