Re: [xliff] RE: Call for dissent on BIDi solution Re: [xliff] bidi

["Dr. David Filip" <David.Filip@ul.ie>]

Thanks for explaining, Fredrik

Re ph, what I meant was addressed by Yves, i.e. encoding the directionality of the placeholder content (that is not part of the extracted translatable content)  rather than its vicinity. I agree this can be handled with data if needed.

Now regarding <ec>

I understand what you say about decreasing the stack level rather than increasing..

But I think that is the matter of the UAX#9 and not of XLIFF

We can of course include an informative warning that this is how the dir should work on <ec> if UAX#9 is to be implemented properly.

But we do not say anything about increasing stack level on <pc> or <sc> either, we are just making a normative reference to UAX#9.

Everything considered, I believe that the </ec> expressivity should not be hindered in cases when it is isolated and the inline metadata solution should be as consistent as possible, we do allow fs and slr on isolated <ec> after all..

Rgds

dF

Dr. David Filip

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

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

http://www.cngl.ie/profile/?i=452

mailto: david.filip@ul.ie

On Fri, Dec 20, 2013 at 2:48 PM, Estreen, Fredrik <Fredrik.Estreen@lionbridge.com> wrote:

Hi David,

 

As far as I remember my reasoning for the current setup was that the base method to specify directionality inline was to use the Unicode control codes. In addition to that I wanted XLIFF to be able to create tagging for the commonly occurring idioms in XML formats including XHTML / HTML5 without complicating the processing for XLIFF tools. In those formats spans of some form can have directionality attached, that can be encoded without control characters using <pc>/<sc>+<ec> for complete spans and as <sc> for the start of an orphaned span.

 

If we were to allow directional control on <ec> it would logically mean the end of an existing span that would cause a direction change. That would be hard to model in a straight forward way together with the Unicode BiDi algorithm. In that algorithm such an operation would normally reduce the stack level (ie level 9 -> level 8 for example). If we wanted to preserve that we would need to start at a higher level then what is usual when beginning the paragraph. Or we would prescribe modeling the end of a span as instead increasing the nesting and therefore increasing the stack level. That is of course technically possible but not intuitive. With control codes it is left up to the extractor / modifier to use the appropriate form.

 

<ph> was not given directionality as I did not find it common that placeholder elements was used to describe directionality of following content. It was either spans or plain control characters, that might have changed since then. In the cases placeholders had directionality it was with respect to the thing they represented not the following text.

 

Regards,

Fredrik Estreen

 

From: xliff@lists.oasis-open.org [mailto:xliff@lists.oasis-open.org] On Behalf Of Dr. David Filip
Sent: den 20 december 2013 15:30
To: Dr. David Filip
Cc: Yves Savourel; xliff@lists.oasis-open.org
Subject: Re: [xliff] RE: Call for dissent on BIDi solution Re: [xliff] bidi

 

Another question, suggestion,

I believe that dir should be allowed on isolated <ec> elements? not only <pc> and <sc>

Dr. David Filip

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

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

http://www.cngl.ie/profile/?i=452

mailto: david.filip@ul.ie

 

On Fri, Dec 20, 2013 at 2:24 PM, Dr. David Filip <David.Filip@ul.ie> wrote:

Yves, working on it,

 

But have a question for the Inline SC I guess

 

Why is dir not allowed on <ph>? I know it does not enclose content, but can be useful nevertheless for Extractor/Merger?

Dr. David Filip

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

LRC | CNGL | LT-Web | CSIS

University of Limerick, Ireland

telephone: +353-6120-2781

cellphone: +353-86-0222-158

facsimile: +353-6120-2734

http://www.cngl.ie/profile/?i=452

mailto: david.filip@ul.ie

 

On Fri, Dec 20, 2013 at 1:10 PM, Yves Savourel <ysavourel@enlaso.com> wrote:

Hi David, all,

> We might want to say that our inline spans and pairs
> should be interpreted as the isolates rather than the the
> embeddings if transformed into plaintext.
> So this would be an addition to our Directionality section.

Doing edits in the specification is a pain, so maybe, to save some time and efforts, you could post an email with the proposed text,
and we can dissent or not on it.

Currently the paragraphs about inline content are like this:

[[
...
The <pc> and <sc> elements have an OPTIONAL attribute dir with a value ltr or rtl. The default value is inherited from the parent
<source>, <target>, or <pc> element, in which the respective element is located.

Adding bidirectional information in the text content is done using the Unicode bidirectional control characters [UAX #9].

In addition, the <data> element has an OPTIONAL attribute dir with a value ltr or rtl that is not inherited. The default value is
ltr.
]]

What would be the new text?

Thanks,

-yves



---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php