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

[Rodolfo M. Raya]

On Thu, 2005-02-10 at 21:44 +1000, Asgeir Frimannsson wrote:
> Hi all,

Hi,

> The only field I can see possibly belonging in the XLIFF file is 
> Project-Id-Version, which can be split up to represent the product-
name and 
> product-version attributes of the <file> element. But I don't think we
should 
> put a restriction on this and put it in the guide, as some
localisation 
> processes might want other values in these fields.
> 
> Rather, I would like to see the whole header abstracted and put in
the 
> skeleton. This causes problems when converting POT files, having to
manually 
> edit headers after translation but I can't see a better solution
(other than 
> e.g. building more logic into filter implementations to auto-modify
headers)

IMHO, PO header should be treated as what it is: just another
translatable message, but making changes to what you wrote in the guide.

The following is an extract from the guide:

        
  <source xml:space="preserve">
    # SOME DESCRIPTIVE TITLE.
    # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER
    # This file is distributed under the same license as the PACKAGE
package.
    # FIRST AUTHOR &lt;EMAIL at ADDRESS&gt;, YEAR.
    #
    #, fuzzy
    msgid ""
    msgstr ""
    "Project-Id-Version: PACKAGE VERSION\n"
    "Report-Msgid-Bugs-To: \n"
    "POT-Creation-Date: 2004-11-11 04:29+0900\n"
    "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
    "Last-Translator: FULL NAME &lt;EMAIL at ADDRESS&gt;\n"
    "Language-Team: LANGUAGE &lt;LL at li.org&gt;\n"
    "MIME-Version: 1.0\n"
    "Content-Type: text/plain; charset=CHARSET\n"
    "Content-Transfer-Encoding: 8bit\n"
  </source>
  
You included comments in the <source> element and that's wrong. Comments
should be part of a <note> element attached to the <trans-unit> element.

You also included a flag inside the source (the line that states that
the entry is a fuzzy one) and that should be considered as the value of
the "approved" attribute of the <trans-unit>. If the message is set to
fuzzy, then the <trans-unit> element should have the "approved"
attribute set to "no". If the fuzzy flag is not present, then the
message should be considered translated.


> Further, how to represent a PO header or any other information in the
skeleton 
> should be totally implementation dependent, and not defined in the
guide.

If you put the header in a translation unit, you don't need to treat it
in a special way. 

> Implementations would need to take care when converting PO files
though, as 
> the character set is specified in a header field. But filters should
be able 
> to deal with that by a) imposing restrictions on character sets (e.g.
utf-8 
> only), or b) parsing the charset field of the header and do the
conversion to 
> the XML character set, or c) manually specify the PO character set on 
> conversion.

Heartsome's tools assume that PO files are always in UTF-8 and that's
the preset encoding. Nevertheless, the user is able to override the
default value (I once found a PO file encoded in ISO-8859-1 in Fedora).

> Any comments?

Two comments: 

1) I will review the guide during the weekend. You can expect more
comments on Monday.

2) I did not send the required info because our headquarters in
Singapore were closed for Chinese New Year and my local office in
Uruguay was also on holidays (carnival). I'm waiting for a definition on
the license, which should be ready by Friday.

Regards,
Rodolfo
-- 
Rodolfo M. Raya <rodolfo at heartsome.net>
Heartsome Holdings Pte. Ltd.