[Bug 28266] [webvtt] 6.2.1 processing model handling of bidi [I18N-ISSUE-432]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=28266

Silvia Pfeiffer <silviapfeiffer1@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WORKSFORME

--- Comment #17 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
After discussion with several internationalisation users at FOMS came to the
conclusion that there is no immediate need for change. Explanations follow:

(In reply to Silvia Pfeiffer from comment #0)
> Feedback by Addison Phillips from W3C I18N group:
> http://lists.w3.org/Archives/Public/public-tt/2015Mar/0065.html
> 
> I18N comment: https://www.w3.org/International/track/issues/432
> 
> 6.2.1 Processing model
> http://www.w3.org/TR/2014/WD-webvtt1-20141111/#h4_processing-model
> 
<..>
> It would be helpful to the author to be able to set the default base
> direction for a whole WebVTT file to rtl.


There doesn't seem to be a need for this, since the text of the cue itself
through UTF-8 characters already determines the directionality.


> It would also be helpful if the author could set the base direction for each
> cue explicitly, since the Unicode paragraph detection algorithm can be
> fooled by a paragraph that starts with a strong LTR character, but is
> actually a RTL paragraph (or vice versa), eg. "نشاط التدويل is how you say
> 'i18n Activity' in Arabic."

This problem has been acknowledged. However, there is already a means to
address this by using the UTF-8 RLO, LRO, RLE and LRE characters. These do
explicit directionality overrides in contrast to &lrm; and &rlm; which provide
only hints to the algorithm.

WebVTT generally prefers the use of a single means of specifying directionality
and prefers the use of UTF-8 characters to specify this over explicit markup.
Therefore, we regard this issue as being addressed.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Wednesday, 30 September 2015 22:59:30 UTC