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

[Asgeir Frimannsson]

On Tue, 15 Feb 2005 07:19, Rodolfo M. Raya wrote:
> Here are a few comments about the PO Representation Guide:
>
> 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.

There are a few issues with this approach (hope I'm not repeating myself to 
much):
1) Translators still need to know the PO file format. 

When outsourcing translations to translation agencies etc, it would be 
prefferable to be able to abstract this PO-related information. As new 
community translators join, they will also not know the PO file format, but 
only be concerned with the actual translation.

2) The PO header contains meta-data not translation units.

The only fields I can see most translators possible editing are:
- Initial (# style) Comments
- Last-Translator

This leaves the following fields that are normally not changed by translators:
- Project-Id-Version
- Report-Msgid-Bugs-To
- POT-Creation-Date
- PO-Revision-Date
- Language-Team
- MIME-Version
- Content-Type
- Content-Transfer-Encoding
- Plural-Forms

In addition to these, user-defined variables are commonly used (often prefixed 
with X-..).

What we're trying to do if we include the header as a translation unit, is to 
add support for meta-data that XLIFF either doesn't support, or support in a 
different way (e.g. Last-Translator can be extracted from 'contact-name' and 
'contact-emai'l attributes of a particular <phase> element). 

When projects eventually start using XLIFF, there will be a need to store 
project specific meta-data similar to that in the PO header, but this might 
not be stored in the XLIFF file. As XLIFF and open source localisation 
evolves, we might even see individual projects using several XLIFF files (or 
<file>s) and not only PO-generated XLIFF representations, but also other 
file-formats represented in XLIFF, and there is a need for meta-data on a 
higher level than the <file> element, and XLIFF does not support this. 

> 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.

Agree on this one, as we also discussed earlier on the gnome-18n list. 

cheers,
asgeir