[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]