XLIFF vs. PO vs. Trolltech

[Oswald Buddenhagen <oswald.buddenhagen@trolltech.de>]

Hello *,

Trolltech is looking into implementing/improving XLIFF support in Qt's 
Linguist tool chain. Interoperability with PO files is an item, too.
This is what I've come up with. Please sanity-check it, so we don't set
a faulty de-facto standard in case we go for it. ;)

- The PO representation guide says that everything should be put into one 
  <file> element and PO references should be represented as <context 
  context-type="sourcefile">. This is in accordance with the XLIFF spec 
  (see "sourcefile" value doc). However, that means that if I create an .xlf 
  file directly from sources I get a different representation than if I create 
  a .po file and convert it to .xlf later. I find this inconsistency not
  justified, so I think I would opt for the "native" representation with
  multiple <file> elements. Only if the PO message has additional references
  to other files, sourcefile contexts would be used.

- Gettext's new msgctxt keyword was brought up before. Incidentally, the
  <comment> element in Qt's own .ts files maps pretty well to it. There 
  is no standardized mapping for .xlf yet, though. I would pick up a
  previously suggested approach and do it like that:

      <trans-unit>
        <source>foobar</source>
        <target>irgendwas</target>
        <context-group purpose="match information">
          <context context-type="x-gettext-msgctxt" match-mandatory="yes">some 
context info</context>
        </context-group>
      </trans-unit>

  For plural forms, the context would be attached to the plural group.
  The exact value for purpose= is not clear to me - the values suggested
  seem to refer to TM only. I think I would simply skip the purpose ...

- .ts files know a <context> element. I consider it stronger than msgctxt: it
  is not optional; every message is in a context. Therefore I would map it to
  nested groups:

      <group restype="x-trolltech-ts-context">
        <context-group purpose="match information">
          <context context-type="x-trolltech-ts-context" 
match-mandatory="yes">the 
context</context>
        </context-group>
        <trans-unit .../>
      </group>

  FWIW, the mapping to PO would be via a magic extracted comment:
  #. ts:context <the context>

- As the repr. guide says, .po files do not encode the (target) language.
  Therefore I would add an X-Language: header to the initial msgstr. It would 
  be implanted and extracted during conversion. When converting from an .xlf
  file which does not have a first message that seems to be a .po file header,
  a message would be generated and marked with X-Virgin-Header:; if this
  header is found on converting back, the message would be zapped.

- Gettext's #| msgid (previous source in fuzzy translation) would be mapped
  to <alt-trans> elements as suggested on this list before: Each previous
  source is tacked onto a current source. If more previous sources than
  current sources exist (plural to singular "downgrade"), the source gets two
  alt-trans elements, the second one with an empty target marked with
  restype="x-dummy".
- Gettext's #| msgctxt would get mapped just like msgctxt, only that the
  context-type would be x-gettext-previous-msgctxt.

- Contrary to the guide, I would store obsolete messages, marking the
  <trans-unit> resp. the containing plural <group> with translate="no".
  I see no harm in doing this and it yields a more faithful conversion.
  The messages would go into a <file> with the imaginary original name
  Obsolete_PO_entries.

- The guide does not specify how to map fuzzy plurals. I guess one should
  require approval of all <trans-unit>s in the <group> for non-fuzziness.

Does this sound OK?
TIA for any input.

Regards,
-- 
Oswald Buddenhagen

Trolltech GmbH
Rudower Chaussee 13 
12489 Berlin
Germany

Fon:	+49 (030) 6392 3255
Fax:	+49 (030) 6392 3256