RE: [xliff-comment] XLIFF vs. PO vs. Trolltech

[bryan.s.schnabel@tektronix.com]

Hello Oswald Buddenhagen,

Thank you for your detailed note, and for giving us the opportunity to review the work Trolltech is embarking on.

We will review your message, come to consensus in the TC, and provide feedback.

Thank you for this opportunity,

Bryan Schnabel
Co-chair OASIS XLIFF Technical Committee

-----Original Message-----
From: Oswald Buddenhagen [mailto:oswald.buddenhagen@trolltech.de]
Sent: Friday, May 16, 2008 10:05 AM
To: xliff-comment
Subject: [xliff-comment] XLIFF vs. PO vs. Trolltech


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

--
This publicly archived list offers a means to provide input to the
OASIS XML Localisation Interchange File Format (XLIFF) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: xliff-comment-subscribe@lists.oasis-open.org
Unsubscribe: xliff-comment-unsubscribe@lists.oasis-open.org
List help: xliff-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/xliff-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xliff