<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.3.2"> </HEAD> <BODY> On Fri, 2005-02-11 at 10:57 +0100, Asgeir Frimannsson wrote: <BLOCKQUOTE TYPE=CITE> On Friday 11 February 2005 00:25, Rodolfo M. Raya wrote: </BLOCKQUOTE> <BLOCKQUOTE TYPE=CITE> > 1) I will review the guide during the weekend. You can expect more </BLOCKQUOTE> Hi, Here are a few comments about the PO Representation Guide: 1.1. General Structure <BLOCKQUOTE> The last paragraph states that the guide does not define how to structure skeletons. I believe that it is important to define a common format for the skeleton as there will be different implementations of the PO filters. The guide is intended as a standard, so it should rule all aspects related to XLIFF <-> PO conversion. </BLOCKQUOTE> 1.2 PO Header <BLOCKQUOTE> As mentioned in other messages, I suggest treating the header as a regular translation unit. Due to its particularities, the corresponding <source> element would be empty and the credits that translators should update would be displayed in the <target> element. This isn't an obstacle for XLIFF editors and simplifies filter building a lot. </BLOCKQUOTE> 1.2.4. Alternative 4: Using custom namespace <BLOCKQUOTE> IMO, custom namespaces should be discouraged completely, unless the goal of the project includes writing XLIFF editors able to use the custom namespaces. The reason is simple: there is no guarantee that other tools will support support custom tags. </BLOCKQUOTE> 1.3. Domain <BLOCKQUOTE> Gettext manual does not mention domains in the description of PO format. See  <A HREF="http://www.gnu.org/software/gettext/manual/html_node/gettext_9.html#SEC9">http://www.gnu.org/software/gettext/manual/html_node/gettext_9.html#SEC9</A> If there is another authoritative description of PO file format, it should be mentioned in the guide. Grouping related translation units is OK, but there must be some standard or specification to follow for that. </BLOCKQUOTE> 1.4.1.1. Translator Comments <BLOCKQUOTE> Translators can add comments at translation time. Those comments are useful while the translation is in course, but they are lost when the POT file is updated and used to generate new PO files. Comments added to the XLIFF file at conversion time may have the "from" attribute set to <TT>"po-file"</TT>, but there is no need to restrict the  values of the "from" attribute. An example: Heartsome's TM system stores translator comments in the database; if after conversion I retrieve translations from my own TM, I have my own comments back; my comments usually have the "from" attribute set to "rmraya". When writing comments back in the translated PO file, the origin of the comment is lost, so it does not make sense to enforce an origin. </BLOCKQUOTE> 1.4.1.2. Automatic Comments <BLOCKQUOTE> In my own experience, automatic comments never provided important context information. I would leave them in the skeleton. </BLOCKQUOTE> 1.4.1.3. Reference <BLOCKQUOTE> References are garbage and should be confined to the skeleton. Translators able to read source code are also able to search the sources using grep or find for occurrences of the text being translated. </BLOCKQUOTE> 1.4.1.4. Flag <BLOCKQUOTE> Flags for "c-format" or other formats should be stored in the XLIFF file, perhaps in a <prop> element. They are needed to rebuild the flag line of the translated document. The presence or absence of the fuzzy flag in the translated document should be determined from the status of the translation. </BLOCKQUOTE> 1.4.3. Plurals <BLOCKQUOTE> Plurals are a nightmare. Once a skeleton is written translators should not be able to add new segments in the XLIFF file. I don't have a decent solution for handling plurals at this moment, but it certainly deserves some thoughts and definitions. </BLOCKQUOTE> References <BLOCKQUOTE> A definition of PO format or a link to an agreed standard definition of PO format must be included in this section. Definitions of the standards used in language related attributes are essential. XLIFF specs says that language codes are not case sensitive and also recommends following RFC3066; this RFC recommends the ISO 639 codes, which are case sensitive (lower case). Right now almost all Open Source projects working with PO files use ISO 639-1 codes. The adopted language standard must be clearly stated, to avoid potential conflicts with  tools that use custom codes. </BLOCKQUOTE> These are the first impressions. Don't take it as pure criticism. Regards, Rodolfo <TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%"> <TR> <TD> -- Rodolfo M. Raya <<A HREF="mailto:rodolfo@heartsome.net">rodolfo@heartsome.net</A>> Heartsome Holdings Pte. Ltd. </TD> </TR> </TABLE> </BODY> </HTML>