[xliff-tools] PO Repr. Guide: restype attribute for PO Header

[Asgeir Frimannsson]

Hi Tim,

First of all, enjoy your holiday! :)

On Thu, 10 Mar 2005 19:20, Tim Foster wrote:
> I'm a bit uneasy about an empty source string and a full target string
> though, it seems like it's a bit of ad-hoc hackery.
>
> > Cons:
> >  - Yet another feature to build into filters.
>
> Um, I think that strictly speaking, it's not "translatable" - I know the
> translators want to edit this section, but if you hand it to a TM or MT
> system, it'll most likely get confused, unless it knows that this sort
> of res-type trans unit shouldn't be translated, whereupon you loose the
> benefit of XLIFF : the idea is you should only need to write
> format-specific code once, in the filters, not in other translation
> tools down the line.

I agree on this one, as also mentioned in another thread.

> I'd be gunning for sticking this into a <note> element inside the <file>
> <header> element (which is basically analogous to the way it's stored in
> a po file) instead - suggesting that the po-header actually contains
> metadata about the file, rather than normal translatable content.
>
> http://www.oasis-open.org/committees/xliff/documents/xliff-specification.ht
>m#header
r>
> We're not doing this in our filters/editor yet, but it seems like it
> would make more sense (we're currently taking the easy option and
> treating it as a trans unit)

Using a <note> element is IMO also wrong from a spec-adherence point of view, 
as notes are for communication between parties in the localisation process. 

I think what we're struggling to do is to port some of the PO-centric or 
open-source centric localisation workflow features over to XLIFF - some 
features that XLIFF doesn't support. The only elements a translator would 
want to edit is Last-Translator, PO-Revision-Date and maybe the '# ' style 
comment (adding the translators name/email). The rest of the header should be 
provided by the localisation engineer or (in open-source-terms) the language 
coordinator, and this _before_ the PO file is converted to XLIFF. 

[start-theory]

As more tools becomes available, we'll see the pioneers starting to convert PO 
to XLIFF (and back again) in a PO centric localisation process. It would then 
be useful to have the header as a translation unit, as these people will be 
familiar with PO and the header format, and will need to edit these to follow 
the PO-centric localisation workflow. 

When XLIFF becomes mainstream in open source localisation, other means of 
storing project-data (such as list of translators, copyright notices, 
bug-mailing lists, language team) are being used. PO is (maybe) used in the 
build process for conversion to XLIFF, and for generating MO's in the end, 
but only used internally in build systems, and not in the localisation 
process. Translators simply start their localisation tool (or visit their 
favourite localisation portal [e.g. pootle]), retrieve XLIFF files via 
web-services, translate, and submit the files back via web-services, which 
then in turn communicate with the repositories and build systems.

[/end-theory]

Ok, a bit off-topic, but all this to say: It would be beneficial for the 
short-term to have the PO header as a translation-unit, but in the long run, 
I believe the solution is to abstract this (into a skeleton or create 
intelligent filters that can create the neccecary headers on the fly when 
back-converting).

> The pros of putting it into a trans-unit, is that it makes life easier
> for writers of xliff editors (no need to write something that edits or
> displays xliff header metadata), but the cons are it just seems sort of
> wrong, from a spec-adherence point of view.
>
> The pros of putting it into a <header> is that you're sticking more to
> the spirit of the XLIFF spec, but the cons are that back-conversion to
> PO is a little more complex.

Would it help (or make the situation better for TM lookups etc.) if we in the 
filters copy the header msgstr to both <source> and <target>? So a header 
becomes:

<trans-unit id="message_header" restype="x-gettext-domain-header" 
approved="no">
    <source xml:space="preserve">
      Project-Id-Version: MyPackage 1.0
      Report-Msgid-Bugs-To: foo at example.com
      POT-Creation-Date: 2004-11-11 04:29+0900
      PO-Revision-Date: 2005-02-01 12:00+0900
      Last-Translator: Foo Bar &lt;foo at example.com&gt;
      Language-Team: My Language &lt;LL at li.org&gt;
      MIME-Version: 1.0
      Content-Type: text/plain; charset=utf-8
      Content-Transfer-Encoding: 8bit
      Plural-Forms: nplurals=2; plural=n>1;
    </source>
    <target xml:space="preserve">
      Project-Id-Version: MyPackage 1.0
      Report-Msgid-Bugs-To: foo at example.com
      POT-Creation-Date: 2004-11-11 04:29+0900
      PO-Revision-Date: 2005-02-01 12:00+0900
      Last-Translator: Foo Bar &lt;foo at example.com&gt;
      Language-Team: My Language &lt;LL at li.org&gt;
      MIME-Version: 1.0
      Content-Type: text/plain; charset=utf-8
      Content-Transfer-Encoding: 8bit
      Plural-Forms: nplurals=2; plural=n>1;
    </target>
    <note from="po-file">
      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.
    </note>
  </trans-unit>

cheers,
asgeir