Hello. I'm following the po4a development for some months. I think that it has so much future, since it's well structured and it can ease a lot the work of translating documents. Good job ;)

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

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)

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.

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)

The inclusion entities are also important, but if we could treat each file alone it would be good enough for now :) 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. It's what I've noticed from the first experience with po4a. It would be very nice if these things could be worked out, because those could enable people to use po4a with the most commonly used DocBook features.

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...

> 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).

> 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...

> 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?

> 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.

On Wed, Apr 21, 2004 at 11:44:34PM +0200, Jordi Vilalta wrote: > 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. [...] > > > 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: [...] > 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. Erm, I prefer not to detail what exactly it looks for ;) Let's say that the CVS version is "a bit broken". Let me commit what I have locally, and it should do the trick.

> Here's what I've tried: > ... > <!ENTITY aaa "aeiou"> > ]> > ... > <para> > &aaa; > </para> > ... > > and in the po generated by po4a-gettextize: > > # type: <para></para> > #: kk.xml:26 > msgid "&aaa;" > msgstr "" And you got nothing, right? po4a skips the generation of msgid containing an entity only (or tags only). It will now issue a warning when such optimizations are done. Thanks for the repport. [At least this is what I planned, but the msgid containing spaces along with entities where not detected. This is also fixed]

It was furthermore impossible to translate the content of the entity because it was not implemented. This will be fixed as soon as I find the time to commit my local version into the CVS. At least, I hope so ;)

> > > 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. If that's legal (ie, if nsgmls accepts it, I'll have to accept it. Again, please fill a bug about this (another one). Do not forget to attach a example file being valid, but refused by po4a. For example, are you sure that it's %common; and not &common; ?

> po4a skips the generation of msgid containing an entity only (or tags only). > It will now issue a warning when such optimizations are done. Thanks for the > repport. [At least this is what I planned, but the msgid containing spaces > along with entities where not detected. This is also fixed] Now it seems to skip this kind of msgids (the version I tried some days ago didn't), but it has an irregular behavior. I've done the following (meaningless) test:

When watching the contens of the msgids, it seems that it skips only the inclusion entities that it knows, and gives the "substitution" entities up:

I think there are 2 alternative ways to treat these cases better: 1) Exclude all entities-only messages (any number, known or unknown) 2) Include the whole messages that have more than 1 entity (known or unknown), because in some languages it may be interesting to change the order of some of them.

hmmm, now I was thinking about the standard entities that define special characters, as &acute; and I've seen that they're also excluded if there's something like <title>&Acute;</title>. Seeing this, I prefer not to exclude any entities. In some cases it can be a little annoying for the translators, but else, there could be some untranslateable strings.

> > <!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. > > If that's legal (ie, if nsgmls accepts it, I'll have to accept it. Again, > please fill a bug about this (another one). Do not forget to attach a > example file being valid, but refused by po4a. For example, are you sure > that it's %common; and not &common; ? nsgmls accepts them, and it parses the included files (it has given some errors in the included files ;) The %something; entities are a different kind. I don't know all their properties, but they're expandable into the doctype header (and standard entities aren't). I'll fill the bug in a while.

Hello, On Mon, 24 May 2004, Martin Quinson wrote: > [...] > On Fri, May 07, 2004 at 03:43:38PM +0200, Jordi Vilalta wrote: > > > po4a skips the generation of msgid containing an entity only (or tags only). > > > It will now issue a warning when such optimizations are done. Thanks for the > > > repport. [At least this is what I planned, but the msgid containing spaces > > > along with entities where not detected. This is also fixed] > > > > Now it seems to skip this kind of msgids (the version I tried some days > > ago didn't), but it has an irregular behavior. I've done the following > > (meaningless) test: > > When I redo the test, I got something corresponding to what I expect: > ====[/tmp/a]==== > <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" > "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ > <!ENTITY chap SYSTEM "chapter1.xml"> > <!ENTITY chap2 SYSTEM "chapter2.xml"> > <!ENTITY aaa "contens of aaa"> > <!ENTITY bbb "contens of bbb"> > <!ENTITY ccc "contens of ccc"> > ]> > > <book> > &chap0; > &chap; > &chap2; > &aaa; > &chap3; > &bbb; > &chap; > &ccc; > &aaa; > </book> > ====[/tmp/chapter1.xml]==== > [content of chapt1] > ====[/tmp/chapter2.xml]==== > [content of chapt2] > ====[generated po file]==== > # SOME DESCRIPTIVE TITLE > # Copyright (C) YEAR Free Software Foundation, Inc. > # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR. > # > #, fuzzy > msgid "" > msgstr "" > "Project-Id-Version: PACKAGE VERSION\n" > "POT-Creation-Date: 2004-05-24 14:10-0700\n" > "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" > "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" > "Language-Team: LANGUAGE <LL(a)li.org&gt;\n&quot; > "MIME-Version: 1.0\n" > "Content-Type: text/plain; charset=CHARSET\n" > "Content-Transfer-Encoding: ENCODING" > > # type: definition of entity &aaa; > #, no-wrap > msgid "contens of aaa" > msgstr "" > > # type: definition of entity &bbb; > #, no-wrap > msgid "contens of bbb" > msgstr "" > > # type: definition of entity &ccc; > #, no-wrap > msgid "contens of ccc" > msgstr "" > > # type: <book></book> > msgid "" > "&chap0; [content of chapt1] [content of chapt2] &aaa; &chap3; &bbb; [content " > "of chapt1] &ccc; &aaa;" > msgstr "" > ====[end of files]==== > > The type line looks ok to me, and there is no reference line for entity > definition. That way, it is not broken ;) Well, the problem here was with the chapter?.xml files. With your files I get the same result as you, but when changing their content to: <chapter><title>ch.1</title> <para>content 1</para> </chapter> I get this (mad) output po file: ... # type: <title></title> #: a.xml:12 chapter2.xml:1 msgid "ch.1" msgstr "" # type: <para></para> #: a.xml:12 chapter2.xml:1 msgid "content 1" msgstr "" # type: <title></title> #: chapter1.xml:1 msgid "ch.2" msgstr "" # type: <para></para> #: chapter1.xml:1 msgid "content 2" msgstr "" # type: </chapter><chapter> #: chapter2.xml:1 msgid "&aaa; &chap3; &bbb;" msgstr "" # type: </chapter></book> msgid "&ccc; &aaa;" msgstr "" It seems that when inserting the content of the included file, it's parsed in the main file, and it gets this behavior (and the wrong type lines).

Also, I don't like the substitution of the content here: "&chap0; [content of chapt1] [content of chapt2] &aaa; &chap3; &bbb; [content " "of chapt1] &ccc; &aaa;" As you see, the content of chapter1 appears twice (must be translated twice). Instead of this, I think that inclusion entities should be treated like the substitution entities (the content is translated once, and their appearances should be left as they are): &aaa; appears twice in this msgid, and its content is only translated once.

Now I've still tried to complicate it a little more. I've tried to put some tags into a substitution entity (I've used it in real documents) and then, the entity disappears from the generated po.

I am sorry about that, but I modified some of the strings. In fact, I partially translated them to french in order to review the original, and corrected what I thought necessary.

I'll commit that ASAP, and I hope you didn't advance this translation too much. If yes, I hope that gettext will be able to reuse most of your work despite my butchery.

On Sat, May 01, 2004 at 08:56:10PM +0200, Jordi Vilalta wrote: [...] > > I'll commit that ASAP, and I hope you didn't advance this translation too > > much. If yes, I hope that gettext will be able to reuse most of your work > > despite my butchery. > > > > I've had to touch almost every string, but on most only had to remove the > last newline. I've attached the finished translation of po/bin/po4a.pot to > spanish to this mail. > > Now I don't have many time for this. When I have some free time I'll try > to advance the translation of po/pod/po4a-pod.pot. If someone else wants > to continue this, drop me a line to coordinate our efforts. Hi Jordi, many thanks, your file has been committed. Hopefully the pot file will not change too much now ;)