[Po4a-devel]Some comments

[Jordi Vilalta]

Hi.

Sorry for the delay in this answer, currently I'm busy with the 
university, so I won't be very active. I'll try to work in the 
translations when I'll have more free time.

On Wed, 14 Apr 2004, Martin Quinson wrote:

> On Tue, Apr 13, 2004 at 08:03:51PM +0200, Jordi Vilalta wrote:
>
> [skip intro]
> 
> > Recently I tried the po4a-gettextize with a DocBook XML document that I'm
> > starting to write and I found some problems. (I'm also newbie in DocBook, 
> > so some of the following issues may not be po4a problems)
> > 
> > At first it gave me the next error:
> > 
> > Argument "pi" isn't numeric in sprintf at 
> > /usr/lib/perl5/site_perl/5.8.2/Locale/Po4a/Sgml.pm line 618, <IN> line 2.
> > Use of uninitialized value in sprintf at 
> > /usr/lib/perl5/site_perl/5.8.2/Locale/Po4a/Sgml.pm line 618, <IN> line 2.
> > ossa-pre/index.xml:1:0: Unknown SGML event type: 
> > 
> > Then I deleted the first line, which is xml specific:
> > <?xml version="1.0"?>
> > and this error disappeared. Apart from this line, the rest is a valid SGML 
> > DocBook. Would there be an easy way to auto-detect and bypass it? (Then 
> > I think you could officialy say that po4a supports DocBook XML documents 
> > at the same level as DocBook SGML)
> 
> I just commited a fix to the CVS. If this line is found when trying to use
> the SGML backend, it will write the following warning: 
> 
> po4a::sgml: /tmp/sag.sgml seems to be a XML document. It will be attempted to handle it as a SGML document.
> po4a::sgml: Feel lucky if it works, help us implementing a proper XML backend if it does not.
> 
> and then try to proceed as if this line where not there. But I agree with
> Denis, pretending that we support XML because of this crude hack would be an
> error. It's not even documented yet, and I'm not sure I really want to
> document it...
> 

It detects if there is that line, but now it seems it fails when 
searching for the DTD:

File kk.xml have an unknown DTD
Supported for now: debiandoc, docbook.

It may be that it is still watching at the first line of the file, not the 
second.

> > About the entities there are some issues. The first one is in the included 
> > files, which I think it's already been reported (bug #300591). It repeats 
> > the following lines infinitely:
> > 
> > substr outside of string at 
> > /usr/lib/perl5/site_perl/5.8.2/Locale/Po4a/Sgml.pm line 226.
> > Use of uninitialized value in string eq at 
> > /usr/lib/perl5/site_perl/5.8.2/Locale/Po4a/Sgml.pm line 227.
> > Use of uninitialized value in string eq at 
> > /usr/lib/perl5/site_perl/5.8.2/Locale/Po4a/Sgml.pm line 228.
> > Use of uninitialized value in concatenation (.) or string at 
> > /usr/lib/perl5/site_perl/5.8.2/Locale/Po4a/Sgml.pm line 229.
> 
> This is now fixed (in CVS).
> 

Yes, it seems solved :)

> > The other one is about standard entities (simple code expansions), whose 
> > contens should mostly be translated. It seems that currently they're 
> > simply ignored. They can have some difficulty in parsing, because they can 
> > contain directly the text to be translated, or some kind of tags, that 
> > should also be parsed. It's important to be able to easily translate 
> > entities, because they are widely used for repeated fragments of text. (At 
> > the beginning it could be nice to get all the string of the entity to 
> > translate)
> 
> Uhm. Are they expended in the text to translate (my intention) or really
> ignored? I know that a really proper mecanism to translate them would be
> needed, but in the meanwhile, I was thinking that expending them in the text
> would be better than ignoring them. I tryied to re-read the source code to
> see what is done in there, but it is made rather complicated by the
> inclusing entities handling, which is far from being trivial.
> 
> Could you please retest the regular entities to see exactly how they are
> handled ? If they are ignored, could you please open a bug on the web site
> attaching a simple example file? I know I could do so myself, but I'm really
> really short of time...
> 

In the last mail I only had entities in included files, so it could be an 
issue for the included files.

Today I've tried it again with entities defined in the same file, and it 
seems to be ignored again. As I said, I'm also very new with DocBook, so 
it can be that I'm doing something wrong. Here's what I've tried:

in the source:

...
<!ENTITY aaa "aeiou">
]>
...
<para>
&aaa;
</para>
...

and in the po generated by po4a-gettextize:

# type: <para></para>
#: kk.xml:26
msgid "&aaa;"
msgstr ""

> > The inclusion entities are also important, but if we could treat each file 
> > alone it would be good enough for now :)
> 
> Inclusion entities are handled... What was your problem when using them?
> 

Well, last day I only tried that with included files that had entities 
including other files... It wasn't handled. I used the following
construction:

...
<!ENTITY % common SYSTEM "common.ent">
%common;
]>

I don't know if it's somewhat strange. The DocBook parser accepts it. 
The common.ent file has only entities, which are extended in the main 
document definition. Now I've tried to include a file with:

<!ENTITY chapter SYSTEM "chap1.xml">
]>
...
&chapter;

and its contents now appear on the .po as expected.

> > I've also found that there may be some attributes important to translate 
> > (such as the "lang" one), and it seems to be ignored for now.
> 
> Yeah, ignoring them is bad. but the parser used for now does not give simple
> access to them. I dunno what to do.
> 

Don't worry, that's a minor thing if the rest gets working ;)

Thanks for your attention.

Regards,

Jordi Vilalta