[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

--- Comment #19 from Glenn Adams <glenn@skynav.com> ---
(In reply to Silvia Pfeiffer from comment #17)
> 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.

This is insufficient in general (but see more below). A cue may be a mixture of
LTR and RTL strong directionality characters, in which case there is no
generally acceptable way to determine the cue's default directionality, in
which case an author specified property is required.

> 
> 
> > 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.

While it is true that each cue's text could be wrapped in a RLE/PDF or LRE/PDF
pair, this does not actually affect the cue's default directionality, but
merely the embedding level of the text so wrapped.

If there are style properties that apply to the cue as a whole, and those
properties require the use of a default directionality to resolve their
computed value, e.g., the computed value resolved from 'start', 'end', etc.,
then use of Bidi controls in the text will not suffice.

> 
> 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 on the CC list for the bug.

Received on Thursday, 1 October 2015 02:16:50 UTC