[xliff-tools] PO Representation Guide: The PO Header

[Rodolfo M. Raya]

On Fri, 2005-02-11 at 10:57 +0100, Asgeir Frimannsson wrote:

> On Friday 11 February 2005 00:25, Rodolfo M. Raya wrote:



> > 1) I will review the guide during the weekend. You can expect more


Hi,

Here are a few comments about the PO Representation Guide:

1.1. General Structure


        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.


1.2 PO Header

        
        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.
        

1.2.4. Alternative 4: Using custom namespace


        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.

1.3. Domain


        Gettext manual does not mention domains in the description of PO
        format. See
        http://www.gnu.org/software/gettext/manual/html_node/gettext_9.html#SEC9
        
        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.

1.4.1.1. Translator Comments


        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 "po-file", 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.


1.4.1.2. Automatic Comments

        
        In my own experience, automatic comments never provided
        important context information. I would leave them in the
        skeleton. 

1.4.1.3. Reference


        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. 
        

1.4.1.4. Flag


        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.
        

1.4.3. Plurals


        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.
        

References


        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.
        

These are the first impressions. Don't take it as pure criticism.

Regards,
Rodolfo
-- 
Rodolfo M. Raya <rodolfo at heartsome.net>
Heartsome Holdings Pte. Ltd.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xliff-tools/attachments/20050214/be7433fa/attachment.html