OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Fw: [xliff-comment] XLIFF vs. PO vs. Trolltech



Hi,

The message included below confirms that we need to update the
guidelines for converting PO files to XLIFF.

Best regards,
Rodolfo 
-- 
Rodolfo M. Raya <rmraya@maxprograms.com>
http://www.maxprograms.com

========================================

Date: Fri, 16 May 2008 19:05:11 +0200
From: Oswald Buddenhagen <oswald.buddenhagen@trolltech.de>
To: xliff-comment <xliff-comment@lists.oasis-open.org>
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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]