Re: Handling Translations

[Christian Rose <menthos menthos com>]

michaeld senet com au wrote:
> > > It seems to me that both these methods are somewhat complex, and, more
> > > importantly, slow.
> > Do you have any data on that? I doubt the gettext solution introduces
> > any user-noticable difference in speed. If in doubt, test it, compare
> > it, produce some data on performerance, and then we can have a
> > discussion. Speculating isn't helping.
> 
> Ok, agreed.  But if speed is an issue we can always use FOO (where FOO is
> possibly gettext) to localise statically. ie create localised pages using
> gettext and just serve them up.  Speed issue gone.

Yes, creating static pages from po files is one possible solution. As
long as what the translators get to translate is po files, everything
else is just implementation detail.


> Make a change in the root
> document and use 'make' to redo the translation (and may include contacting
> translators directly, or marking the page as needing effort from a translator).

Marking the changed pages is not needed, marking changes (fuzzys) is
automatically taken care of by the gettext tools when a translator
refreshes the po file. The gettext tools compare what is already
translated (indexed with the English string as key) and compares it to
the current state of the files, and marks messages that are changed,
added, etc.
Also, we already have web status pages that have the percentage of
completeness of the translations of individual GNOME CVS modules, the
web site could easily be added to these status pages.


> > > Now, if we think about the fact that if the template
> > > system works as it should, and actual PHP functions are externalized,
> > > then there won't be any common elements between the different language
> > > pages (apart from headers and footers to call templates.)
> > >
> > > So why not just use different pages (PHP files) for different languages?
> >
> > Because it sucks. It's very much non-maintainable. How do you get
> > notification of changes? If random hacker X spots an error on the site
> > and commits a fix to cvs, how is translator Y[1-40] to know that spot Z
> > on page W changed, without diffing the entire site periodically, and
> > manually inspect all diffs, and on top of that try to insert
> > corresponding changes in their translated pages? Translators want to
> > translate, not spend most of their time trying to track changes.
> 
> Like I mentioned, why not keep track of what english text files have changed
> (md5sum on PO files?) and requiring translator input to convert strings to
> their locale?  Then they strings can be updated when the translator gets around
> to it, but at least they're flagged.

This is taken care of by the po format, no need to re-invent.


> > gettext/xml-i18n-tools/PO format solves these fundamental problems. We
> > have discussed it repeatedly on this list, but you just continue to
> > ignore the problem.
> 
> We need to try a few things out to see what works before committing ourselves.
> Why not code up a page in your preferred solution, put it up for review and
> discussion, and then we can continue.

Someone replied to me in private some months ago, commenting on how they
use PHP+gettext on their site. I'm attaching the mail.


> What we really need is the initial php templates for Joakim's html screens.  We
> can then hack till sunrise and try out some solutions before deciding upon one.

Ok.


Christian

--- Begin Message ---

• From: cgabriel softwarelibero org (Christopher R. Gabriel)
• To: Christian Rose <menthos menthos com>
• Subject: Re: PHP+gettext (was Re: My stab at the templates)
• Date: Fri, 29 Jun 2001 21:33:37 +0200

    Christian> A slightly modified example from the php gettext page:

    Christian> <?php // the following will be common for every page
    Christian> and could be put in a // common inclusion file.

    Christian> // Set language to German. This would obviously be
    Christian> handled by // a system for choosing language and/or
    Christian> using the one the // browser supplies.  putenv
    Christian> ("LANG=de"); // use all the locale variables. This can
    Christian> be used for printing numbers // correctly (decimal
    Christian> points/commas) and so on.  setlocale(LC_ALL, ""); //
    Christian> Specify location of translation tables bindtextdomain
    Christian> ("gnomeweb",
    Christian> "./path-to-where-the-language-catalogs-are"); // Choose
    Christian> domain textdomain ("gnomeweb");

    Christian> // This is how translations will be used in the
    Christian> pages. _() is a shortcut // for gettext() and will show
    Christian> the translated message.  echo _("Welcome to Gnome
    Christian> Web")."<BR>"; echo _("This should all be translated. If
    Christian> you see this message in the language you entered, it
    Christian> works"); ?>

    Christian> That should be it. Whenever you add new content to the
    Christian> site, you only have to put strings that you will show
    Christian> inside _() and it should work.

    Christian> Granted, I haven't tested that gettext in php works. If
    Christian> anyone wants something to do... If you want help, just
    Christian> ask. Or I'll have to wait until I have the time to test
    Christian> this... :(

I'm using this extensively on http://furbo.firenze.linux.it, and it
works really fine. The code is available at
http://cvs.firenze.linux.it/cgi/viewcvs.cgi/furbo/

Cheers,
-- 
Christopher 

	There's an interference between the keyboard and the chair.

--- End Message ---