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: TMX 2.0 does not have an inline element to store content? (RE:[xliff] Wiki Document related to "Generic Inline Markup")

Hi Rodolfo,

Thanks for the reply. This is good and constructive.

So I think your answer to my question about the two examples (below), is "(A) is good and (B) is against the TMX requirements.":

<p>This is a <b>FUN</b> game</p> (<b> is an element)

Now it is not:
(A) <seg>This is a <itag pos='start' type='b' />FUN<itag pos='end' type='b' /> game</seg>

Now it is:
(B) <seg>This is a <itag type='b'>FUN</itag> game</seg>

Hmmm. I guess that helps me to form my position on the matter.

As for your question to me, how would I markup your Word HTML sample in XLIFF?, I see no difficulty.  I would just not worry about the unbalanced way Word marks up the bold element.  It is well-formed.  So I would just capture the empty element the same way I would any other element (why should I bother with its intent? It will survive the round trip completely intact):

<trans-unit resname="p" w:rsidR="00C93CE8" w:rsidRDefault="00F331AC">
   <g ctype="r">
      <g ctype="t" xml:space="preserve">Hello </g>
   <g ctype="r" w:rsidRPr="00F331AC">
      <g ctype="rPr">
         <x ctype="b"/>
      <g ctype="t">bold </g>
   <g ctype="r">
      <g ctype="t" xml:space="preserve"> world.</g>

(ignoring complexity added with namespaces for the moment, and leaving off required attributes for simplicity)



-----Original Message-----
From: Rodolfo M. Raya [mailto:rmraya@maxprograms.com]
Sent: Monday, April 06, 2009 2:11 PM
To: Schnabel, Bryan S
Subject: Re: [xliff] Wiki Document related to "Generic Inline Markup"

On Mon, 6 Apr 2009 13:16:17 -0700
<bryan.s.schnabel@tektronix.com> wrote:

> Here are the two items that jumped out at me.
> You said:
> > Section 3.5: in TMX the idea of an inline tag
> > is to have a container for markup. This section
> > is against the requirements of TMX.
> {Schnabel - This comment is problematic for me. I hope it's just a
> matter of me not understanding what you mean.  It kind of sounds like
> you're saying the *only* way TMX wants to use inline elements is as a
> container for markup.

Hi Bryan,

TMX 2.0 has 3 inline elements:

 * <itag>, for holding formatting data. This element is either empty or
   contains formatting markup.

 * <hi>, for holding optional information, like terminology. This
   element can contain translatable text and tools are not required to
   understand or use this element, except when it delimits text that
   should not be translated.

 * <sub>, ugly thing required in some cases by some tools.

The only uses expected for <itag> are: container for markup or
placeholder indicating where markup should be. It is not designed to
directly contain translatable text.

In a previous draft, there was a tag (ph) that contained translatable
text and beginning/ending markup was stored in attributes. This was
discarded by OSCAR TC.

Looking back, I reconize that storing markup in attributes is not a
good idea because markup can span several lines of text, like in .docx
or InDesign files.

This simple HTML fragment: <p>Hello <b>bold</b> world.</p> is
represented in Word 2007 with this code:

<w:p w:rsidR="00C93CE8" w:rsidRDefault="00F331AC">
    <w:t xml:space="preserve">Hello </w:t>
  <w:r w:rsidRPr="00F331AC">
    <w:t xml:space="preserve"> world.</w:t>

TMX 2.0 permits to simplify this inline tag soup with 2 <itag> elements.

I use two <ph> tags to represent that mess in my XLIFF filter.

How would you like to represent it in XLIFF 2.0?

Rodolfo M. Raya <rmraya@maxprograms.com>

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