public inbox for [email protected]
help / color / mirror / Atom feedFrom: Peter Eisentraut <[email protected]>
To: Dave Page <[email protected]>
To: Alexey Borzov <[email protected]>
To: [email protected]
Subject: Re: A briefing is needed...
Date: Thu, 15 Jan 2004 00:20:26 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
Dave Page wrote:
> 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.
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.
view thread (16+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: A briefing is needed...
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox