[Po4a-devel]New solution to translate XML using po files

Jordi Vilalta jvprat@wanadoo.es
Sun, 17 Apr 2005 13:23:43 +0200 (CEST)


Hi,

On Wed, 23 Mar 2005, Martin Quinson wrote:
[...]
> From what I can see, the entities are rewritten before the content is
>  extracted to po files. This is bad because it will unnecessary fuzzy the
>  strings when the entity content change. In po4a/sgml, entities are
>  translated separately, and then the entities are preserved into msgids. I'm
>  not sure about po4a/xml.

Entities are still not handled in the xml module :(

>  The most interesting point is that they provide an heuristic for automatic
>  tags classification. Maybe from dtd, I only glanced the code. But at the
>  same time, they provide specific "modes" for the dtd they use (docbook and
>  gnomesummary). If it works, it's exactly what I'm dreaming of since years.
> 
> 
>  I think that it could be interesting to :
>  - see whether we can reuse their automatic classification heuristic

I'm not used with python, so I'll leave it to other skilled programmers ;)

>  - build a gnomesummary module from their one (it looks really easy to do)

If it should only contain the translateable tags, it's so easy to do. 
(attaching it to my TODO list...)

>  - contact the authors to see whether they would accept to merge our efforts
>    since it's also python based, we may well get the same result than with
>    the translate project (both parts willing to merge, none willing to
>    switch the programming language, and no change as result), but it worth
>    trying...
> 
>  Your advice?

My vision is that all these efforts have to merge, and I propose the following 
long term steps:

- First, we (all the involved projects) should define a common interface
   (extending the TransTractor one, for example) that would be able to
   handle all the posible file formats (more than one translation on the
   same file, etc.)
- Second, we should implement the new kernel app that is able to handle
   everything defined in the first step using plugins.
- Third, each project could build his own file format plugins in their
   preferred language.

>  PS: I dream of Perl6, which will make possible the code sharing between
>  perl, python and even java ;)

I support C/C++ for the kernel app, which has interfaces to lots of other 
languages, and it could also bring us some more performance.

Maybe all this is like an utopia, but I think it's the way to go. If we decide 
to follow one of these roads we should tell the other projects.

The main spanish translators group has proposed a small encounter of the 
translation efforts (translators themselves and tools' developers) for next 
summer. I think it could be a nice event to talk about all these issues. I'll 
be forwarding all the information I get about it.

Regards,

Jordi Vilalta