Re: [Po4a-devel]Documentation review (fwd)
by Jordi Vilalta
Hi,
Today I was updating the catalan documentation and I've found a posible update
in the original:
diff -u -r1.31 po4a.7.pod
--- doc/po4a.7.pod 6 Nov 2004 19:08:01 -0000 1.31
+++ doc/po4a.7.pod 25 Dec 2004 19:26:05 -0000
@@ -872,7 +872,7 @@
Yes, in po4a, each paragraphs are translated separately (in fact, each
module decides this, but all existing modules do so, and yours should also).
-There is two main advantages to this approach:
+There are two main advantages to this approach:
=over 2
This made me remember the documentation review we were talking about one month
ago. Are there any news? Should this patch be added to the complete review? (I
don't remember if it was already there).
Regards,
Jordi Vilalta
19 years, 11 months
[Po4a-devel]Call for a (La)TeX module
by Martin Quinson
Hello,
I think there is a cruel need for a TeX module in po4a. This is the last
major documentation format missing to our panel, and people keep asking
about it. Nicolas (CCed) mailed Denis and me privately about that a week
ago, Nekral mailed me yesterday, and so on.
This format family may allow us to deal with texinfo documentation (all GNU
documentation), with book translators (like Nicolas) and maybe even with the
Python documentation (I trust Nekral on this one). And, more important than
all the rest, I'm tired of translating my presentations and articles
manually :)
The problem that kept me away from doing this until now is that as groff,
tex is a programming language in which you can define new macros. It's even
worse since authors do actually define macros (in groff, a few steal some
classical macros here and there. most people don't bother).
As with the other formats, po4a do not intend to become a full featured
format interpreter (à la HeVeA). It just intend to parse it and split the
input in msgids. I have some ideas about how to do so, but it's really
impossible for me to start a new module implementation. So, I'll explain my
plans here, and hope that someone will step in...
For [the rare] documents not defining any new macros and sticking to
unadulterated LaTeX, it should be rather easy to build a first prototype
simply splitting on limits between TeX's vertical and horizontal modes.
- As usual (hello Yves), you need to distinguish between inline tags (ups,
macros), which you ignore (such as textit or footnotesize or $bla$), and
formating ones, for which you translate the argument (such as \section,
\subsubsection or $$bla$$).
- Translate separately the content of all environment.
- Some macros need a more complex handling, I'm sure.
- Translate separately each item (of a itemize and associate).
- Naturally translate separately each paragraph separated by empty lines.
- Ignore stuff like \medskip, since they are formating only.
Hint: it's used in vertical mode. (if there is some \newpage, I guess
you're dead)
And so on and so far. I belive in this approach for simple documents. There
is two main jobs here :
- write a proper parser, which can detect macros, separate their arguments,
etc. This may be the more difficult part. tex is full of \ and { all
around the place. You'll have to protect them, and to come up with a
usable way to determine the } corresponding to a given { (so that the
inbetween can be treated as a macro argument).
Classical constructions (item) should be dealed with in there. All the
rest should be passed to macro handler just as in the man module.
- read a latex definition and write the right handlers for the right macro.
There will be a bunch of dupplicated work if you don't do as in the man
module (or come up with a better idea, of course).
Once this is done, you'll be able to deal with documents with no
\newcommand. For new definitiones, I guess that the only viable idea is to
go for specifically formated comments in the document (lines begining with
'%po4a:' ?) to explain which category each macro belongs to. You may even
want to allow the interpretation of perl code embeeded into the document, if
you're not concerned about security *at all*.
If you want to give it a try, you're welcome, anywho you are. Just check the
documentation to see how po4a works.
man Locale::Po4a::TransTractor -> root of the project.
man Locale::Po4a::Sgml -> some ideas about the categories; file inclusion.
man Locale::Po4a::Man -> some ideas about the macro handler mecanism.
Then, mail us. Then start coding.
That's all I can think about at 6.30 am in a night train bringing me to yet
another job interview...
Please comment/forward/react.
Mt.
20 years
[Po4a-devel]Nested blocks with Xml.pm
by Yves Rutschle
Hi all,
I started looking at using Xml.pm for Xhtml last night.
Is there an example somewhere of how one would go at
processing nested blocks with Xml.pm? As it is, having
defined the 'block' tags and 'inline' tags, it would produce
only one msgid for, e.g.:
<div>
<h1>blah blah</h1>
<p>This is a paragraph</p>
</div>
because <div> created a block and Xml.pm doesn't descend
into blocks (as I understand it -- I may be confused).
Y.
20 years
[Po4a-devel]Two small issues with Po.pm
by Nicolas François
Hello,
There is a first issue which causes a bad formatting of the po4a.7 and
Locale::Po4a::TransTractor manpages:
Here is an example:
http://po4a.alioth.debian.org/es/Locale/Po4a/TransTractor.html#DESCRIPCION
(at the end of this section, the "bone" is broken)
This is caused by a line ending by a \ in a no-wrap paragraph.
The Po unescape function replace ([^\\])\\n by $1\n
I think it should instead replace "even number of \ followed by \n"
thus s/([^\\](\\\\)*)\\n/$1\n/g;
(I'm joining Po.pm.escape.patch)
If you think it is the right way to fix this issue, then I will also
change other similar regular expressions in this module (there are many
others).
The second issue is one of the problems detected by the WDIFF category of
the testsuite (some text is present in the original, but not in the
translation, or the contrary).
If a man page contains something like that (in a wrapped paragraph):
\fP
foo
then the font stack may "delay" the font modifier, and po4a generates the
following paragraph: "\nfoo". The result of gettext with this msgid is
always a null string.
I will fix the Man module so that the empty line will be pushed without
translation, but the Po module may need the second patch.
(I'm joining Po.pm.defined_empty.patch and foo.1, which trigger this
issue)
Both patches work, but I'm not sure of my perl and I would prefer you have
a look at them.
Regards,
--
Nekral
20 years
[Po4a-devel][PATCH] Stats of empty files
by Yves Rutschle
Hi all,
If a file has no msgids in it, po4a decides to set its "completed" stat to 0.
But if there are no msgids, then the file really is 100% translated:
diff -u -r1.30 Po.pm
--- lib/Locale/Po4a/Po.pm 27 Nov 2004 01:08:56 -0000 1.30
+++ lib/Locale/Po4a/Po.pm 4 Dec 2004 13:40:56 -0000
@@ -689,7 +689,7 @@
sub stats_get() {
my $self=shift;
my ($h,$q)=($self->{gettexthits},$self->{gettextqueries});
- my $p = ($q == 0 ? 0 : int($h/$q*10000)/100);
+ my $p = ($q == 0 ? 100 : int($h/$q*10000)/100);
# $p =~ s/\.00//;
# $p =~ s/(\..)0/$1/;
(Yes, I have a couple of files that need to go through the translation process
for consistency's sake, yet have no content to speak of)
Y.
20 years
[Po4a-devel]Re: [Po4a-commits] po4a/po/pod fr.po,1.40,1.41
by Martin Quinson
On Sun, Nov 21, 2004 at 10:39:28AM +0000, Nicolas FRAN??OIS wrote:
> Update of /cvsroot/po4a/po4a/po/pod
> In directory haydn:/tmp/cvs-serv17739/po/pod
>
> Modified Files:
> fr.po
> Log Message:
> It really needed a pass through a spell checker.
:) Sorry about that.
You could ask for a review on the debian french l10n list, maybe. It's not
debian only, but it's far more used within debian than out there.
Bye, Mt.
20 years
