[xliff-tools] The PO header

Asgeir Frimannsson asgeirf at redhat.com
Mon Feb 21 20:07:12 PST 2005


On Thu, 17 Feb 2005 01:01, Bruno Haible wrote:
> 1.2 PO header
>
> I would go for alternative 4.

The PO header [together with plural forms] is what has given me the most 
headache in this project :) Rodolfo has made a strong case for option 2, 
which is also the most 'compatible' approach in regards to current [PO] 
practices, as it ensures that translators can modify the header as a normal 
translation unit. The main benefit I see of alt 4 over Alt 1 is that it 
enables [custom] tools and XML processors to modify header information, and 
makes it possible to not use a skeleton, but backconvert to PO only using the 
information in the XLIFF file. 

Now back to the representation guide. One solution is to not enforce any one 
way of dealing with the PO header, but rather present various options of 
doing it. The in-progress HTML Representation Guide had a similar problem 
[http://lists.oasis-open.org/archives/xliff/200502/msg00007.html]. In that 
case, the solution was to reccomend one approach, but also present the other 
approach.

> Alternative 1 has the drawback that it loses information.

Information would not be lost, but would be protected in the XLIFF-part of the 
localisation process. When converting back to PO, the header would be exactly 
as it was before conversion.

>
> Alternatives 2 and 3 have the drawbacks that
>   - They are against the principle of XML, in particular they don't allow
>     an XSLT access to the individual header elements.
>   - They ignore the definition of the XLIFF <header> element, which is:
>     "The <header> element contains metadata relating to the <file>
> element." This is precisely the role of the PO file header as well.

Well, the <header> contains metadata relating to the <file> element, but the 
<file> element contains an _extracted_ original document. The question is, 
should the PO header be extracted? I don't have a clear answer :)

> Details in alternative 4:
>
>    <po:po-revision-date>2005-02-01 12:00+0900</po:po-revision-date>
>
> This should be replaced by
>
>    <file date="2005-02-01 12:00+0900">

From the XLIFF spec: "The optional date  attribute is used to specify the 
creation date of this XLIFF file." This attribute is meant for XLIFF-specific 
meta-data, and not meta-data from the original source-file. So it specifies 
the timestamp when you converted between PO and XLIFF, not when the PO file 
was revised. But on backconversion, it would make sense to update 
PO-Revision-Date to the current timestamp?

Thinking along these lines, it's also possible to make use of the product-name 
and product-version attributes, representing Project-Id-Version.

>    <po:mime-version>1.0</po:mime-version>
>    <po:content-type>text/plain charset=utf-8</po:content-type>
>    <po:content-transfer-encoding>8bit</po:content-transfer-encoding>
>
> These can be dropped.

In back-converting to PO, would you then automatically insert this info, or 
store it in the skeleton file?

> The comments of the PO file header, which usually come from the translator,
> should IMO go into a <note> under the <header> element.

yep. If going for option 4, I agree with this one.

cheers,
asgeir


More information about the xliff-tools mailing list