3:49 p.m.
On Mon, Sep 27, 2004 at 11:16:39AM +0200, Martin Quinson wrote:
On Sun, Sep 26, 2004 at 06:03:54PM +0200, Nicolas François wrote:
> On Fri, Sep 24, 2004 at 01:28:23AM +0200, Martin Quinson wrote:
> > On Wed, Sep 22, 2004 at 11:19:30PM +0200, Nicolas François wrote:
>
> Alioth is up and running again. Here is my account: nekral-guest.
Done. You have the commit right. Please use it, but do not abuse it :)
OK, thank you. I've started using it:
- one fix in the patch you committed for me
- documentation of the scripts
If you want we can stick to the current model for a while, where I
review
and commit your patches. But I gave you the cvs commit right so that at
least trivial changes (such as the usage of the testsuite stuff) can go
faster.
For the biggest parts, I will send a patch to the list for a review.
> My problem was: Ok, I recognized a comment inside a paragraph,
what
> should I do with this comment ?
> Can I show it in the po (and how?)? Is there any interest in doing this?
> Can I just trash the comments?
I'd say: push it to the po file. The only issue is that it shows a flaw in
po4a. Modules have no way [I could remember of] to push comments into the po
file :-/
Ok, I've added one. It's not tested yet, but if you pass "comment"
=>
"your_comment" at the end of the translate arguments, it should do the
trick. Now, we should integrate this cleanly into the man module (having a
variable dedicated to the storage of the comments, and used when pushing
translations), but I don't want to interfer with your current changes in
that file.
Nice. I will try it and see if it can be useful for the translators (I'm
wondering if there isn't too much comments in some man pages)
> > > + nested_fonts
[...]
I've got a font stack now.
It works fine with the regression tests. It may need some more tests at
the po level (see if the po is OK)
Do you want all the \f font modifiers to disappear from the po?
If this is the case, I will add some marks for others fonts (I've already
added a CW for the Constant Width font).
Do you think \s-1 (reduce the size by one point) should be given to the
translators? Is S<-1> better?
If you don't mind I'll let it maturate on your side. I've
so little time
myself...
> 1) change all font modifiers (e.g. .B, .RI,...) to the corresponding \f
> I'm thinking of doing this in shiftline (any objection ?), because I
> need to handle these lines in parse, in the .TP, .SH, and maybe other
> macro subroutines.
overiding shiftline could be a good idea. You may want to handle some parts
of the chaos in a "upper layer". But please make sure to document this.
Overriding shiftline works fine. There is however a possible issue: it may
break unshiftline (I will probably override it with a die, or add a FILO
stack of the unshifted lines, which will be used by shiftline).
I'm also wondering which ref I should return when multiple lines have been
shifted with the Transtractor shiftline.
> Do you think the .so/.mso part is OK ?
Nope, it's not. But you had no way to know it. Btw, I commited all the others.
For the sgml module, the policy is to include all the translations in only
one po file, no matter how many source file there is. This is because it's
very difficult to parse a sgml sub-file alone. Where it's included in the
main document is important, as long as the entities defined in the prolog of
the main document, and so on.
So, I'd like to follow the same policy for the man pages. I know that it
will result in dupplicate in the translations, but, well, translators can
use compendiums.
The prefered handling of .so is thus to read the included file, and then
unshift all its lines (begining by the end, of course) into the
transtractor. Of course, this should be a function of the TransTractor
itself such as includefile($). But we didn't agree with Jordi on the
function prototype and syntax before my vacations...
If the file only consist in a .so (majority of the man pages which use a
.so), a warning/die could be use to recomment to only copy the original
file / make a symlink.
.mso are probably not translatable (they include tmac files, i.e.
definition of macros)
To increase the number of man pages used by the regression test, I added a
-M option to po4a-normalize (to specify the master charset).
I would appreciate if somebody more used to po4a could have a look at
which options could be useful for po4a-normalize.
I attach to this mail the following patches:
Man.pm.splitargs.patch
add a splitargs function (which is at this time hardcoded in parse)
This patch is just a code reorganization. It should not change
anything (I need this function in another place, and it may
simplify the parse function).
All the code from the splitargs function comes from the parse
function.
The regression test doesn't show any difference.
Man.pm.splitargs.fonts.patch
(have to be applied after the previous one)
add the font stack
it mostly consist in a do_fonts function, called in pre_trans.
There is also set_regular and set_font.
If you think something need more comments, please tell me.
I've used static variables, but I'm not sure it is the right way
to do this.
I've also changed a little bit the handling of .B and .BI macros
(they return to the Roman font, not the previous font).
Here are the results of the regression tests:
dir1:splitargs
dir2:splitargs.fonts
dir1\dir2 IGN OK OK2 WOK1 WOK2 WOK3 PBS WDIFF
IGN 1734 0 0 0 0 0 0 0
OK 0 124 0 0 0 0 0 0
OK2 0 0 1588 0 0 1 4 0
WOK1 0 0 0 107 0 0 1 0
WOK2 0 0 0 0 222 1 2 0
WOK3 0 1 13 2 2 318 6 0
PBS 0 1 132 10 41 55 596 12
WDIFF 0 0 0 0 0 0 0 52
total: 5025 | 5025
Man.pm.splitargs.fonts.shiftline.patch
(have to be applied after the previous one)
add a shiftline function
It mostly uses code from the parse function (continuation after a
It permit (or will permit) to benefit from this part of the parse
function in some macro subroutines. (e.g. at this time, a ".B"
macro called after a TP (groff's indented paragraph with label) is
kept in the po, instead of providing a B<...> to the translator)
Here are the results of the regression tests:
dir1:splitargs.fonts
dir2:splitargs.fonts.shiftline
dir1\dir2 IGN OK OK2 WOK1 WOK2 WOK3 PBS WDIFF
IGN 1734 0 0 0 0 0 0 0
OK 0 126 0 0 0 0 0 0
OK2 0 0 1729 1 0 0 1 2
WOK1 0 0 0 118 0 0 1 0
WOK2 0 0 0 0 265 0 0 0
WOK3 0 1 8 3 7 353 1 2
PBS 0 0 0 0 0 0 609 0
WDIFF 0 0 0 0 0 0 4 60
total: 5025 | 5025
These patches introduce some issues (for a dozen of pages). These issues
are under control, and will be fixed later (I wanted to keep those patches
as simple as possible).
These patches mostly allow more pages for translation, and further
corrections.
Any comment (even stylistic) will be appreciated.
Subroutines' name and position can also be changed before inclusion in CVS.
Kind Regards
--
Nekral