[Po4a-dev]. TransTractor.pm: the future of po4a modules (+ i'm MIA till next week)

[Martin Quinson]

Hello,

Unfortunately, I have to make a presentation for my PhD thesis monday, and I
did not begin to prepare it, so I guess I won't have any time to work on
po4a until next week. 

This message explains where I stand right now, and where i'm going.

As you can see from the commit messages, I'm reworking the internals of
po-pod in order to extract the generic parts in a module called
TransTractor.pm (available in liblocale-po4a-perl).

The idea is that each module implements a parser, ending with 
 $self->pushline("UNTRANSLATED PARTS".$self->translate($paragraph));
 
That way, the string passed to ->translate() can be extracted to a po file,
and can in the same call be translated to the output document. I hope that
it will allow us to write new modules very quickly. Here is an example from
the doc:

    The following example parse a list paragraphs begining with "<p>". For
    sake of simplicity, we assume that the document is well formatted, ie
    that '<p>' tags are the only tags present, and that this tag is at the
    very begining of each paragraph.

     sub parse {
       PARAGRAPH: while (1) {
           $my ($paragraph,$pararef,$line,$lref)=("","","","");
           $my $first=1;
           while (($line,$lref)=$document->shiftline() && defined($line)) {
               ($line,$lref)=$document->shiftline();
               if ($line =~ m/<p>/ && !$first--; ) {
                   # Not the first time we see <p>. 
                   # Reput the current line in input,
                   #  and put the builded paragraph to output
                   $document->unshiftline($line,$lref);
              
                   # Now that the document is formed, translate it:
                   #   - Remove the leading tag (which shouldn't get translated)
                   $paragraph =~ s/^<p>//s;

                   #   - push to output the leading tag (untranslated) and the
                   #     rest of the paragraph (translated)
                   $document->pushline(  "<p>"
                                       . 
$document->translate($paragraph,$pararef)
                                       );

                   next PARAGRAPH;
               } else {
                   # Append to the paragraph
                   $paragraph .= $line;
                   $pararef = $lref unless(length($pararef));
               }
           }
           # Did not got a defined line? End of input file.
           return;
       }
     } 

And that's all you need to rewrite to get a module handling gettextization,
updating-of-po and translations (with use of addendum) !!

Currently, it seems to work, and I'm hacking po-pod to use it, and still
work as well as previous version. 

I just commited a preversion of Man.pm, which use this interface to
translate man pages. It shouldn't even compile for now, but the idea is
here, and I want to make sure I won't have to rewrite it in case of harddisk
failure here. The main problem with it (beside the fact that I didn't update
it to reflect recent work on TransTractor) is that it does not understand
all roff macros, but it is easy to correct it, because of the easy
extensible design used.

May you have a look at the documented interface of TransTractor and see if
there is some problems with it ?


In my mind, we are going to several types of po4a modules, depending on
several factors:
 - when the translation is used. I guess we should limit ourselves to
   compilation time, and let the plain gettext handle runtime. But
   TransTractor could be used to write easily extractors for runtime
   translations -- look at debconf.
 - wheather the translated document contains only one translation, like for
   all documentation format I know, or all translations, like debconf or
   .desktop files (i know we shouldn't handle .desktops, since intltools do)
   
All compilation time translation with only one language per file modules are
my preliminary target. It will allow us to have all documentation types
(pod, man, texinfo, debiandoc, xml, ...).

At the end of the documentation of TransTractor, there is an idea on how to
handle formats with more than one language per produced file (pretty easy,
but needs to be done)...
   


'till next week, Mt.

-- 
The most exciting phrase to hear in science, the one that heralds new
discoveries, is not "Eureka!" (I found it!) but "That's funny ..."
          --- Isaac Asimov