[Po4a-devel]Some comments

[Martin Quinson]

--bKyqfOwhbdpXa4YI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 13, 2004 at 08:03:51PM +0200, Jordi Vilalta wrote:
> Hello.
>=20
> I'm following the po4a development for some months. I think that it has s=
o=20
> much future, since it's well structured and it can ease a lot the work of=
=20
> translating documents. Good job ;)

Thanks a lot.

> I would like to help in the development, but I've never used Perl :(
>=20
> Then I thought about translating the po4a itself to spanish (es) and=20
> catalan (ca). I've seen po/bin/po4a.pot and po/pod/po4a-pod.pot. May I=20
> translate both? And something else?

Nope, tranlating those two files would be a great improvements, since having
a program intended to help the translators not translated is not very
professionnal...=20

Please repport any inconsistency or error you may found in the process, so
that we can improve the english version.

> 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,=
=20
> so some of the following issues may not be po4a problems)
>=20
> At first it gave me the next error:
>=20
> Argument "pi" isn't numeric in sprintf at=20
> /usr/lib/perl5/site_perl/5.8.2/Locale/Po4a/Sgml.pm line 618, <IN> line 2.
> Use of uninitialized value in sprintf at=20
> /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:=20
>=20
> Then I deleted the first line, which is xml specific:
> <?xml version=3D"1.0"?>
> and this error disappeared. Apart from this line, the rest is a valid SGM=
L=20
> DocBook. Would there be an easy way to auto-detect and bypass it? (Then=
=20
> I think you could officialy say that po4a supports DocBook XML documents=
=20
> 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:=20

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 backe=
nd 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...

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

This is now fixed (in CVS).

> The other one is about standard entities (simple code expansions), whose=
=20
> contens should mostly be translated. It seems that currently they're=20
> simply ignored. They can have some difficulty in parsing, because they ca=
n=20
> contain directly the text to be translated, or some kind of tags, that=20
> should also be parsed. It's important to be able to easily translate=20
> entities, because they are widely used for repeated fragments of text. (A=
t=20
> the beginning it could be nice to get all the string of the entity to=20
> 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...

> The inclusion entities are also important, but if we could treat each fil=
e=20
> alone it would be good enough for now :)

Inclusion entities are handled... What was your problem when using them?

> I've also found that there may be some attributes important to translate=
=20
> (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.

> It's what I've noticed from the first experience with po4a. It would be=
=20
> very nice if these things could be worked out, because those could enable=
=20
> people to use po4a with the most commonly used DocBook features.

I did my best to fix some of the issues. Thanks for repporting them, and for
your interest in that project. Please continue to provide us feedback.

Bye, Mt.

--=20
Ian Fleming was a UNIX fan! How do I know?=20
Well, James Bond had the (license to kill) number 007,
i.e., he could execute anyone!

--bKyqfOwhbdpXa4YI
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAfYSdIiC/MeFF8zQRAufSAJ9yOcudYLcUeTJsbDBaXlRgV23JRACgzXBm
xyGymLz8c03sGXTy7/44T14=
=Y0mV
-----END PGP SIGNATURE-----

--bKyqfOwhbdpXa4YI--