Subject: Re: A briefing is needed...

From: Euler Taveira de Oliveira <[email-masked]>
Date: Wed, 14 Jan 2004 18:27:50 -0200

Hi all,

> > The internationalization system I see in CVS right now 
> > doesn't look very well thought out.  Separating the text from 
> > the context where it will appear will not make the site very 
> > maintainable.  
> 
That's what I think. When it is a simple website it is OK, but when it's a Portal, IMHO it's a pain in the neck.

> Hmm, we use gettext on the pgAdmin site (and keep the text in the
> context in which it will appear) and I find the site a real pain to
> maintain. The old site (although only in English) was much easier to
> maintain - it kept content in a db and used a single php script to
> display all pages bar a few odd scripts.
> 
Yep, I know the gettext extension for php is not a real solution for translation. But I think it's the right thing. I'm working in an extension of gettext to made the support of internationalization to markup languages (XML, HTML, SGML, etc). Maybe it improve the gettext scenario.

Another idea:
1) use index.html.en, index.html.de, index.html.pt_BR for static pages;
2) grad browser language and use it in the dinamic pages;

PS> I just code the Weekly News extension for the website and I will post it tomorrow for comments. It's based in the actual design.

Regards,

-- 
Euler Taveira de Oliveira
euler (at) ufgnet.ufg.br
Desenvolvedor Web e Administrador de Sistemas
UFGNet - Universidade Federal de Goiás

---

From: Peter Eisentraut <[email-masked]>
Date: Thu, 15 Jan 2004 00:20:26 +0100

> display all pages bar a few odd scripts.

Gettext via PHP isn't a terribly good system.  But the idea proposed 
elsewhere, to maintain the content in XML and extract the strings from 
there is a very promising approach and not terribly hard to implement.  
XML could of course mean XHTML, but you might even consider a small 
abstraction layer above that and include the common parts in the 
transformation process.  (XSLT being aware of processing instructions 
should allow handling PHP as well.)

> > Plus, it doesn't look like this system is
> > going to have a lot of external tool support for editing,
> > verifying, and updating translations.
>
> External like poEdit or kBabel or external like an admin page (as
> opposed to updates through psql)? There will certainly be the latter.

A web admin page to manage translations doesn't sound very efficient.  
The final web page will have thousands of strings to translate and will 
hopefully see frequent updates.  With existing tools that translators 
are used to (say, poEdit or KBabel), this can be managed very 
efficiently.  With a web interface, translators are going to sit there 
forever and have no ease of use.  Plus, you're going to have to invent 
access control and version control all over again.  Translation 
management tools are not just editors.  They allow access to compendia, 
do spell checking, syntax checking, allow for automatic merging of 
updates, handle encoding issues, have integration with CVS, and more 
things.

I'm not saying gettext is perfect for this job.  We could take a closer 
look at WML or something completely different.  But the criteria

(1) keep the text close to the context,
(2) keep the original text close to the translated text,
(3) tool support for translators,

are essential for both web site maintenance and translation maintenance.