From mquinson at ens-lyon.fr Fri Jun 4 15:14:14 2004 Content-Type: multipart/mixed; boundary="===============8651593440143813946==" MIME-Version: 1.0 From: Martin Quinson To: devel at lists.po4a.org Subject: Re: [Po4a-devel]Some comments Date: Fri, 04 Jun 2004 14:14:34 -0700 Message-ID: <20040604211434.GK21926@manitee.cs.ucsb.edu> In-Reply-To: Pine.LNX.4.58.0406041308260.20843@r2d2.localdomain.com --===============8651593440143813946== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Fri, Jun 04, 2004 at 01:45:31PM +0200, Jordi Vilalta wrote: > 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 ta= gs only). > > > > It will now issue a warning when such optimizations are done. Thank= s 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 da= ys = > > > ago didn't), but it has an irregular behavior. I've done the followin= g = > > > (meaningless) test: > > = > > When I redo the test, I got something corresponding to what I expect: > > =3D=3D=3D=3D[/tmp/a]=3D=3D=3D=3D > > > "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [ > > > > > > > > > > > > ]> > > = > > > > &chap0; > > &chap; > > &chap2; > > &aaa; > > &chap3; > > &bbb; > > &chap; > > &ccc; > > &aaa; > > > > =3D=3D=3D=3D[/tmp/chapter1.xml]=3D=3D=3D=3D > > [content of chapt1] > > =3D=3D=3D=3D[/tmp/chapter2.xml]=3D=3D=3D=3D > > [content of chapt2] > > =3D=3D=3D=3D[generated po file]=3D=3D=3D=3D > > # SOME DESCRIPTIVE TITLE > > # Copyright (C) YEAR Free Software Foundation, Inc. > > # FIRST AUTHOR , 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 \n" > > "Language-Team: LANGUAGE \n" > > "MIME-Version: 1.0\n" > > "Content-Type: text/plain; charset=3DCHARSET\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: > > msgid "" > > "&chap0; [content of chapt1] [content of chapt2] &aaa; &chap3; &bbb; [c= ontent " > > "of chapt1] &ccc; &aaa;" > > msgstr "" > > =3D=3D=3D=3D[end of files]=3D=3D=3D=3D > > = > > 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: > = > ch.1 > content 1 > > = > I get this (mad) output po file: > = > ... > # type: > #: a.xml:12 chapter2.xml:1 > msgid "ch.1" > msgstr "" > = > # type: > #: a.xml:12 chapter2.xml:1 > msgid "content 1" > msgstr "" > = > # type: > #: chapter1.xml:1 > msgid "ch.2" > msgstr "" > = > # type: > #: chapter1.xml:1 > msgid "content 2" > msgstr "" > = > # type: > #: chapter2.xml:1 > msgid "&aaa; &chap3; &bbb;" > msgstr "" > = > # type: > msgid "&ccc; &aaa;" > msgstr "" > = > It seems that when inserting the content of the included file, it's parse= d = > in the main file, and it gets this behavior (and the wrong type lines). = Yes, it is inlined in the main document before parsing. It is needed to take care of the conditional inclusions. Yes, the reference is a bit wrong in that case. There is a fuzziness of a few lines. I dunno where it comes from, and that's #300589 on alioth. But I don't get why you say it's a mad file. The type lines are perfectly valid. Take "&aaa; &chap3; &bbb;", for example. It is placed out of any tag, and ends to be between a "" and a "". So, that's not po4a which is wrong with the type line, that's the file which is wrongly formated... If you do not agree, what would be a valid file for you ? > Also, I don't like the substitution of the content here: > > "&chap0; [content of chapt1] [content of chapt2] &aaa; &chap3; &bbb; [con= tent " > "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 treate= d = > 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. Yes, but it only comes from the fact that this example is very very (very) artificial. When you do unsane stuff such as creating only one file containing only a few words (ie, using a file to render the functionnality of substitution entities) such as I did in this example, you cannot expect to get sane results, can you ? In regular use, each file will contain a bunch of tags, which will thus be parsed separately. Moreover, I'd prefer not to care about people including the same file twice in the same master document. That's insane. > 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. Sure, if there is only one tag per substitution entity, the optimisation applies. If it's not the case, please come up with some example ;) Bye, Mt. -- = Dans la france profonde, il y a surtout des sp=C3=A9l=C3=A9ologues. -- Le Chat --===============8651593440143813946== Content-Type: application/pgp-signature MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuMi40IChHTlUv TGludXgpCgppRDhEQlFGQXdPWTZJaUMvTWVGRjh6UVJBcFcvQUowWWZ5aHd6Yk1rR294ZGtYQ2pO S1JIM1YrNWpnQ2d2dm42Ckg0Q3ZPa1AwWXVFR3NzTzRhNnkzRHVRPQo9cjdCSwotLS0tLUVORCBQ R1AgU0lHTkFUVVJFLS0tLS0K --===============8651593440143813946==--