htdocs and gettext

[Neil Williams]

On Monday 23 January 2006 5:04 pm, Josh Sled wrote:
> On Mon, 2006-01-23 at 16:33 +0000, Neil Williams wrote:
> > OK. I've got gettext working with PHP to translate a single website using
> > as many PO files as we can create.
>
> Awesome.

:-)  It's not ready to commit as a demo yet, but it does work locally.

> If we're going to "bake" the site via some script "compilation" step,
> then can we get away from using PHP entirely?  :)

Umm, no. If anything, PHP becomes a little more important as although the 
TRANSLATIONS are handled via PO, the CONTENT strings now need to be wrapped 
in php functions.

<h1><?php echo _("Welcome to GnuCash.org")?></h1>
instead of
<h1>Welcome to GnuCash.org</h1>

It means that those altering the original content need to be a little careful 
in their edits (to retain the string and bracket markers). e.g. translatable 
content that includes quote marks should use the SGML entity: &quot; It's 
safer than expecting \" to be preserved through all translations.

We aren't "baking" or compiling the site in the way you infer. The content 
strings remain more or less intact - so that there is only ever one 
index.phtml - but the server loads the translated strings during the PHP run. 
It's runtime translation, much as gettext does already.

All the preparation of the translations happens prior to the svn commit - svn 
will contain the translated binaries, just like it contains the binary 
images. I know this goes against the grain for those more used to automake.

> Also, does it then make sense to structure the files so that we can
> configure Apache can do language content-negotiation?

At present, I'm looking at browser/PHP language negotiation and direct link 
fall back.
http://www.grep.be/data/accept-to-gettext.inc

> <http://httpd.apache.org/docs/2.0/content-negotiation.html>  It would
> basically mean a different structure; one like:
>
>  htdocs/www/index.html.en
>  htdocs/www/index.html.de
>  htdocs/www/index.html.[...]
>  htdocs/www/features.html.{en,de,...}

But gettext doesn't work that way - it would mean generating all those pages 
manually at each svn commit. So far, the delay in loading the pages is not 
significant. That structure would replace 12 .mo files with 144 translated 
copies of the same page. Some of these pages are BIG!

It's the same mechanism, just implemented in the PHP instead of the server. 
You still need the same fallback with the apache structure for those people 
whose browsers don't contain the correct language variable. Both methods rely 
on detecting what the browser supports - the PHP method uses one binary file 
and one text file for each translation and a single content page for all 
languages. The Apache method uses one page for every possible permutation of 
language and content. AFAICT, PHP uses N+(L*2) where N is the number of 
content pages and L the number of languages; Apache would seem to use N*L.

There are 234 phtml pages, 155 text files and 25 php scripts in the current 
design. With 5 languages, the PHP method could mean 424 files; the apache 
method (if I'm reading it right) would mean 2,070.

> > To protect the .svn directories below www/, this snippet should be added
> > to the virtual host config:
> >         <Directory /opt/svn/htdocs/www/*/.svn>
> >                 Order Deny,Allow
> >                 deny from all
> >         </Directory>
>
> I suppose this, or maybe using `svn export` so the .svn files aren't
> even created?

That's wasteful - there are lots of components of the new site that never need 
to be replaced and deleting those (so that export won't complain) then 
re-creating them is more than a little pointless. (Unless svn export has 
solved the cvs problem of exporting to an existing directory.)

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20060123/d7af8cd5/attachment.bin