Re: Handling Translations



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,








[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]