Re: Handling Translations

[Joshua Eichorn <jeichorn mail JoshuaEichorn com>]

All right i have a quick sample online with what i've been messing with.

http://gnome.joshuaeichorn.com/  You should actually see a website now 
since i should have the virtual host rules setup right.

I'll be out of from friday to monday so i won't be doing any more coding 
on this til next week but i should still be checking my
mail and i'm going to try to tackle setting up a script to run the 
xml-i18n-tools tonight.  If anyone want to help i'll be on irc.gnome.org
#webgeeks

Also the site states what needs work and how to set it up for yourself.
-joshua eichorn
Christian Rose wrote:

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