Re: Localization Structure Model

[Owen Taylor <otaylor redhat com>]

Joakim Ziegler <joakim helixcode com> writes:

> On Wed, Nov 15, 2000 at 10:56:43PM -0600, Steve Fox wrote:
> > Joakim Ziegler wrote:
> 
> >> Now, localizing appindex entries is a separate issue, but for localizing
> >> general page content, the best thing to do if we're using PHP is probably
> >> defining some functions like l10n_text_start(language) and
> >> l10n_text_end(), and put blocks of text between pairs of these functions.
> >> It's then really easy to pick the right one, since l10n_text_start just
> >> checks if language is the same as the current language, and if not,
> >> suppresses the output.
>  
> > I like the idea of function usage. So they would grab the page text from
> > a file? Would we use XML?
> 
> In the simplest form, the file would look something like this:
> 
> <? l10n_text_start("english"); ?>
> A rose is a rose is a rose.
> <? l10n_text_end();
> 
> l10n_text_start("latin"); ?>
> Rosa rosa rosa est est.
> <? l10n_text_end(); ?>
> 
> I all places where you'd want to put text blocks. This is probably not the
> *best* way of doing it, but it's a decent example of how simply it can be
> done. I'll leave it as an exercise for the reader to figure out what
> l10n_text_start() and l10n_text_end() look like.
> 
> Please consider this a counterpoint to the "Everything in an SQL database"
> school of thought, not a proposal for an actual implementation.

While I admire the idea of everything-inline, everything-PHP, 
in practice I believe that it falls somewhat short of being
workable for translation:

 * It puts a unecessary burden on the person generating content 
   to skim over not only clunky start and end tags, but also
   all the other languages in between.
 * The failure modes (localized text missing or with an 
   old translation) will make us look very unprofessional.
 * It does not lend itself to automated check tools.

Here a rough suggestion for a scheme, that combines a pure PHP
original sites with a simple build process that does the 
mechanics of translation.

 * In the main CVS directory, we include only English, but insert
   translation markers, perhaps something like:

 <?l10n item?>
 A rose is a rose is a rose
 <?l10n /item?>
 
   [ And use the <?php ... ?> syntax for PHP code ]

 * Then, for each language where we have a translation of the
   site, we create a CVS module with parallel structure - 
   so corresponding to gnomeweb/poem.php3 we have
   gnomeweb-lt/poem.l10n.

   In this file, we have, something like:

   <l10n:item>
   A rose is a rose is a rose
   <l10n:trans>
   Rosa rosa rosa est est.
   </l10n:item>    

 * When a commit happens to the gnomeweb module, a commits scripts
   checks out a copy of the English version and make it live, but we
   also run a perl script that goes through each translated site and makes
   subsitutions from the .l10n files.

   If it finds an item without a translation, it does _not_  
   simply leave it untranslated, what it does is abort the
   process, leave the old site there, and send mail to the
   localized site's maintainer.

   If the translation succeeded, it then takes the newly 
   substituted site and make it live.

   [ For localized sites hosted away from the main gnome.org server,
     we'd need to distribute this process - not that hard with a bit
     of procmail or a nightly cron job ]

I think it is very bad to have localized sites slowly get corrupted
or filling with English over time. Much better to simply have
it freeze in the last-known-good state. 

Regards,
                                        Owen