Subject: Re: non-Unix gettext (was Re: how should we localize locale names?)
From: Joaquin Cuenca Abela (cuenca@celium.net)
Date: Tue Mar 13 2001 - 12:16:05 CST
On 12 Mar 2001 14:09:33 -0800, Paul Rohr wrote:
> 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.
ok, I didn't understand your statement. Are you speaking about the
tools that gettext give to merge old translations with new ones, etc.?
If you're speaking of these tools, can you point me to the xp tools that
abiword provides to our translators?
> >> 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.
Yes, I'm saying that.
> Are you saying that you've written native GUI apps on those platforms
to use
> those files? If so, where are the patches? ;-)
?
I said:
> >I've translated po files in windows, solaris and linux. The platform
> >used never was a problem.
when I spoke about GUI apps? ;-)
So, no, I'm not saying that.
> <bait>
> Maybe I'm really as obtuse about this as people keep implying, and it
really
I don't consider you obtuse (by no means), and I didn't insulted you in
my previous email.
> *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.
you asked about gettext advantages, and about experience of gettext's
users in non-unix land, and I wrote with what I think are the advantages
of gettext over our i18n system and with my experiences as user of
gettext in windows. If you consider that the fact that I don't have a
patch to convert from our i18n system to gettext don't give me right to
speak up, I will not continue the thread.
My email was just my honest feelings based in my experiences.
> The only place I've *ever* seen gettext used was on either Unix, or a
very
> Unix-y port. Why is that?
maybe because gettext roots comes from unix?
> >> 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.
I can point you to me as example. Our i18n mechanism is getting better
and better, but it still has (IMHO) some glitches (specially merging new
messages with old translations).
I can point you to windows translators that are experiencing the same
problem. For instance, Saint-Denis just said a few hours ago:
<quote>
The fr-FR.strings format is inappropriate. I tried to modify it by hand
but there is also a lot of line moving needed... I feel like it is quite
error prone.
Could somebody revert this file to it's previous cvs version. I will
then modify it to make it operationnal. It looks to me there is less
work to be done that way.
</quote>
You really can not know how hard is to merge in your translation new
messages until you try it. Sometimes it works well, sometimes there are
problems. I've done it with our i18n mechanism and with gettext, and I
found the gettext way far easier (but, yes, I'm a linux user, I know)
> >> 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.
I don't know when I lost all these points, but, yes, I openly agree that
gettext tools do inherently favor unix translators (it's just that I
don't think that they harm windows translators... I've been there, too,
and it doesn't harmed me).
> 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.
well, right now windows translators should manage the same merge pain
than the unix translators[1]. Saint-Denis is a windows translator (at
least I think so), and he seems to experience these problems.
> >> 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
not so many hackers in the world?
somebody might do it, but I don't think that somebody will do it (but,
of course, I may be wrong).
> 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
I didn't said that it was a native app (I even said that "it has some
glitches"). I said that gettext worked without a glitch.
Do you have used gimp for windows with a foreign langage?
Do you experiences some glitches (related to the i18n mechanism!) ?
I used it with a foreign langage. I just installed it, and it showed in
french... I don't even know how to change the langage! (exactly as the
others windows apps that I have).
> Is that the only use of non-Unix gettext that you know of?
It's the only one that I've personally tested, why?
[1]: Actually, I don't think that our current i18n system hurds our
users (at least, I will not think it until somebody changes my last
patch about the TODO icons & labels), and I don't think that it hurds
our translators, because thanks to Kenneth the translators can use .po
files to translate the messages, so I think that current problems with
our i18n system are:
* it hurds our translators in the translation of menubar & toolbar.
* it makes harder to i18n a dialog.
* it can not work (at least I don't see how to do it) with tools like
libglade.
current advantages over gettext are:
* you can do cool things like change the layout of the menu items
* it works the same way for all the platforms/don't impose dependencies
in another lib (potentially not present in non-unix systems).
At least these are my personal feelings.
Cheers,
-- Joaquín Cuenca Abela cuenca@celium.net
This archive was generated by hypermail 2b25 : Tue Mar 13 2001 - 12:17:10 CST