RE: [xliff-inline] Id attribute between source and target

[David Walters <waltersd@us.ibm.com>]

In the XLIFF 1.2 Specification, there is this example which uses inline XLIFF elements which replace the original source info.  This is the scenario I was think about.

Example: This example shows how content with clonable <g> may be localised:

<source>This is a <g>sentence. It has</g> markup.</source>

The translation into "Yoda-English" would be:

<target>A <g>sentence</g> this is. Markup <g>it has</g>.</target>

A more complete example including required attributes would be:

<source>This is a <g id="1">sentence. It has</g> markup.</source>
<target>A <g id="1">sentence</g> this is. Markup <g id="1">it has</g>.</target>

If a translator is duplicating an existing inline element, I would assume that the same ID value would be used rather than creating a new ID value.  Otherwise, the process to recreate the original source file would not know how to handle the new <g> element.



If you were using inline elements which encapsulate the original source info, then it would be something like this:

<source>This is a <bpt id="1">&lt;b&gt;</bpt>sentence. It has<ept id="1">&lt;/b&gt;</ept> markup.</source>
<target>A <bpt id="1">&lt;b&gt;</bpt>sentence<ept id="1">&lt;/b&gt;</ept> this is. Markup <bpt id="2">&lt;b&gt;</bpt>it has<ept id="2">&lt;/b&gt;</ept>.</target>

If a translator is duplicating an existing inline element, I would assume that a different ID value would be used so that the new <bpt> and <ept> elements could be tied together.




If translators need to make more extensive changes (like you mentioned for Asian languages), the editor would have to know about the original source file format.  This seems to contradict the goal that handling the XLIFF file is supposed to be format-neutral and should not need to know what the source format is.  Should XLIFF has a more graceful way of handling this situation?


David

Corporate Globalization Tool Development
EMail:  waltersd@us.ibm.com           
Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721

CHKPII:                    http://w3-03.ibm.com/globalization/page/2011
TM file formats:     http://w3-03.ibm.com/globalization/page/2083
TM markups:         http://w3-03.ibm.com/globalization/page/2071

"Estreen, Fredrik" ---10/19/2011 03:29:47 PM---Hi David, There are many situations where this could be needed. And in all cases either the translat

From:	"Estreen, Fredrik" <Fredrik.Estreen@lionbridge.com>
To:	David Walters/Rochester/IBM@IBMUS
Cc:	"xliff-inline@lists.oasis-open.org" <xliff-inline@lists.oasis-open.org>
Date:	10/19/2011 03:29 PM
Subject:	RE: [xliff-inline] Id attribute between source and target

---

Hi David,

There are many situations where this could be needed. And in all cases either the translator or the tool being used need to understand the native codes. The most common case is to simply clone an existing tag. Such as <b> for bold.

Äter <b>katter möss</b>?
Do <b>cats</b> eat <b>mice</b>?

here I have translated a sentence from Swedish to English where all animals are in bold and since the verb moved in between the the two animals I had to create two bold runs instead of one.

Another common situation is with Asian scripts. They do not make use of emphasis styles such as bold or italic. Instead you use special characters, a different font or type size to express the emphasis. This can sometimes get messy. 

The fact that in some situations the translator really want to see the underlying code is an obstacle to properly support the Xliff files of other tools in an editor in many cases.

Regards,
Fredrik Estreen
________________________________________
From: xliff-inline@lists.oasis-open.org [xliff-inline@lists.oasis-open.org] on behalf of David Walters [waltersd@us.ibm.com]
Sent: Wednesday, October 19, 2011 9:13 PM
To: Estreen, Fredrik
Cc: xliff-inline@lists.oasis-open.org
Subject: Re: [xliff-inline] Id attribute between source and target

In what situations would a translator be adding new tags to the target text which do not exist in the source text?  How does the tool which converts the XLIFF information into the required output file format know how to handle these new items, or is it expected that the translator knows how to add inline XLIFF elements with the correct encapsulated text?

An example would  be helpful.

David

Corporate Globalization Tool Development
EMail:  waltersd@us.ibm.com
Phone: (507) 253-7278,   T/L:553-7278,   Fax: (507) 253-1721

CHKPII:                    http://w3-03.ibm.com/globalization/page/2011
TM file formats:     http://w3-03.ibm.com/globalization/page/2083
TM markups:         http://w3-03.ibm.com/globalization/page/2071


[Inactive hide details for "Estreen, Fredrik" ---10/19/2011 11:52:55 AM---Hi, When reading through the current working draft I s]"Estreen, Fredrik" ---10/19/2011 11:52:55 AM---Hi, When reading through the current working draft I started thinking about the wording regarding th



From:

"Estreen, Fredrik" <Fredrik.Estreen@lionbridge.com>


To:

"xliff-inline@lists.oasis-open.org" <xliff-inline@lists.oasis-open.org>


Date:

10/19/2011 11:52 AM


Subject:

[xliff-inline] Id attribute between source and target


Sent by:

<xliff-inline@lists.oasis-open.org>
________________________________



Hi,

When reading through the current working draft I started thinking about the wording regarding the ID of inline codes in the target.

“The value of the id attribute for this code in the target MUST be the same as its corresponding code in the source.”

I think we might need to reword this to allow new tags with unique Id’s in the target that do not exist in the source. This is very common for some languages. Something like:

“The value of the id attribute for this code in the target MUST be the same as its corresponding code in the source if it has one. If it does not have a corresponding code in source it’s id must be unique within both source and target.”

Regards,
Fredrik Estreen

[attachment "graycol.gif" deleted by David Walters/Rochester/IBM] [attachment "ecblank.gif" deleted by David Walters/Rochester/IBM]