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

Rodolfo M. Raya rodolfo at heartsome.net
Mon Feb 14 08:31:59 PST 2005


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

Hi,

> I think this is the most practical sollution in that it's easy for translators 
> to modify the header (if they have knowledge of PO), and also makes life 
> easier for developing filters. But I'm still not sure if it's a _legal_ way 
> to do it according to the XLIFF Specification. The <trans-unit> element is 
> meant for 'translatable data', and the PO header does not have any 
> translatable data, only informative and technical meta-data. 

Translatable data is anything that needs to be modified by a translator,
including the credits described in the PO header.

> Further, it 
> would cause some garbage in TM's, by having PO headers in the databases when 
> automatically importing approved TUs. 

Any translatable entry in a PO file contains two parts: a "msgid"
section that is copied to the <source> element and a "msgstr" section
that corresponds to the target.

In a PO header the "msgid" section is empty, this means that the source
is also empty. When a segment corresponding to a header is imported to a
TM database it can be ignored or disregarded safely because one of the
languages is an empty entry.




> Yep. For indicating 'fuzzy', should we use the 'state' attribute of the 
> <target> element set to 'needs-review-translation', or the 'approved' 
> attribute of the <trans-unit> element set to 'no'? Also, if we use the 
> 'approved' attribute, should this be set to 'yes' for non-fuzzy messages?

I wrote some comments about the "state" attribute in a previous message.

> Yeah, by having the header in a <trans-unit>, all possible elements of a PO 
> file are covered, and even the need to extract anything to a skeleton is 
> eliminated (but skeletons should be guide-independent anyway, so it's up to 
> implementers if skeltons are used)

Skeletons should not be eliminated. They are important to hold automatic
comments/references generated by the GUI builders like Glade. Automatic
comments are garbage, only comments from the programmer should be kept
in the XLIFF file to provide context information.

More comments when I'm back from lunch.

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


More information about the xliff-tools mailing list