Re: PHP+gettext

[Christian Rose <menthos menthos com>]

Shawn T Amundson wrote:
> > > gettext is a solution based on the necessity of combining short strings
> > > with code.  Even maintaining it in C really sucks; it just happens to be
> > > the best you can do in that situation.
> >
> > I obviously disagree.
> > Please tell me what sucks. The only problem I know is the context
> > problem, but that is only a problem with very, very short messages.
> 
> Ok, I'll agree it doesn't suck when working with C since there is no
> better way to do it.  What I meant was it's a lot of work and effort,
> even in C.

And that is *very* well worth it. From a developer's view gettext may
seem overly complex and overkill ("why not just store the strings in a
hash"?) but that's because it's actually a translation system worth its
name. Believe me, any system that doesn't use message catalogs but
places strings to translate in the code directly in a data structure is
no translation system. It's just plain broken from a translation
maintainership viewpoint.

If you tell me a (free!) replecement for gettext that also handles
message merging, fuzzy matching (similar message matching), string
extraction and the like, and has half the tools that gettext has, then
we can talk, IMHO. There's no point in maintaining a translation without
those features. Thay are necessary.


You could even start by explaining how translations would work in your
proposed solution - I found nothing about that at the fabric site.


> > > Doing it for entire pages of text and/or html is not even realistically
> > > maintainable.
> >
> > How come? If you mark an entire page in a single _() chunk, obviously it
> > will be a pain to translate and maintain. Not so if you for example use
> > a different _() for every paragraph. And if you write your pages
> > properly you wont use pragraphs with 15-20 lines or more anyway.
> 
> Fixing typos or changing wording in english then messes up everyone
> else, and since that's a common thing for a website of any size, the
> problem is substantial.  It simply isn't realistic.

Of course it is. You're just speculating, right?

First, most of the pages on www.gnome.org (gnotices and bugzilla aside)
are very static. Joakim Ziegler mentions that the pages are currently
very outdated all the time.

Second, I update Swedish GNOME software translations daily. Many of the
big cvs modules are between 500 and 2000 messages and some notoriously
active ones (like Galeon, Evolution, gtk+ and Ximian Setup Tools as
examples) often have several commits a day with new messages or changed
messages (completely new strings, slightly changed strings, fixed typos,
fixed wordings etc.) Even if the pace is fast, I manage to update those
translations to 100% several times a week, and sometimes also daily.

Don't tell me gnomeweb would be any harder than that. In fact, given
that most of the pages at www.gnome.org are very static by their nature
and thus maybe doesn't change every day, I even think it will be even
simpler to maintain it translationwise than some of the Gnome software.


> > There's no need to reinvent the wheel.
> 
> What can I say, except that I think your wheel has a flat tire. ;-)

No. I'm proposing a fully working wheel. You haven't yet proposed
anything. From the looks of it, it sure looks like what you are
proposing is a sleigh -- even though there is no snow, and never will
be.


> Seriously though, it seems you suggest extending gettext beyond it's
> rational uses.

No -- this is the use gettext was designed for. There's no difference
between a frequently updated, 2000 messages application like Evolution,
and a big web application translation-wise. Neither should it be.


Christian