MHonArc v2.5.0b2 -->

















xliff message






[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]








Subject: RE: [xliff] Fwd: Updated XLIFF 1.1 Representation Guide for Gettext PO




From: "Doug Domeny" <ddomeny@ektron.com>
To: "'Paul Gampe'" <pgampe@redhat.com>,<xliff@lists.oasis-open.org>
Date: Tue, 19 Jul 2005 12:08:55 -0400






All,

The profile looks great. It definitely shows a lot of good work. I'm very
pleased with the quality of the profile. I'm not experienced in PO files,
but have a couple comments regarding use of the XLIFF <ph> tags.

Section 3.4 Handling of Escape Sequences in Software Messages

Escape sequences for common control character like newline ('\n') are
represented in XLIFF using the <ph> element, as in <ph id='1'
ctype='lb'>\n</ph>. 

This approach closely couples the translation of the human language with the
computer language used to render it. I believe a more abstract
representation would allow better separation between human and computer
language. For example,

<x id='1' ctype='lb' />

Then the translation is applicable to any computer language that can render
a line break, whether it uses '\n', or other notation.

Section 5.6.3 X-format

Similarly, the "%s" and "%d" notations are kept in the XLIFF <ph> tag as <ph
id="1" ctype="x-c-param">%s</ph>, where the ctype attribute value specifies
the computer language of the notation (as listed in Table 4).

For example,

<x id="1" ctype="x-string-param" />

Here I realize that the format may be more complex. For example, an ANSI C
format may be "%+03.2ld". In this case, it seems appropriate to keep the
format within <ph> tags. It wouldn't be required because the format could be
stored in the skeleton file. However, for convenience, keeping it in the
<ph> is reasonable.



Your comments and comments from the rest of the XLIFF committee are welcome.

Regards,
 
Doug Domeny