[Bug 28257] [webvtt] start/end linked to left/right [I18N-ISSUE-422]


--- Comment #37 from Silvia Pfeiffer <silviapfeiffer1@gmail.com> ---
(In reply to Simon Pieters from comment #36)
> I don't like baking in LTR semantics for this one thing when the rest of
> WebVTT is agnostic to LTR vs RTL.

Yeah, I tend to agree. Maybe here consistency should go ahead of the
translation use case. If a box is not expected to move, it has to be explicitly

> > Leaving it centered is also wrong, too. For RTL text that is in a 50% box
> > and start aligned, it should be positioned at the right edge if there was
> > not the translation use case.
> I'm not really convinced it's wrong. A cue can contain *both* LTR and RTL
> text, on different lines. Which side is the correct one in such a case?

That's a third use case: LTR, RTL, and then mixed. If it was just RTL, right
edge alignment would be correct.
Mixed text with 'align:start' is Example 15 and we haven't really made an
example for when the size is restricted also. I guess mixed text should be
center aligned.

> Also consider if we were to add align:justified. Then text is aligned on
> both sides, regardless of directionality. Where should the box be?

That should certainly be a centered box.

> Since center is the default, and there's no clear right answer, I still
> think center is the best choice.

Only for mixed directionality. I think for purely RTL, center is as wrong as
for purely LTR.

> > Alternatively, we could ignore the translation use case and say that if you
> > have intended to explicitly position the box on the left, you have to put a
> > 'position:0%' on it, too, otherwise the box might move if the text
> > directionality changes. A validator could even raise a warning in this case.
> I think if we want captioners to explicitly position their boxes, it is
> better to let the default position be center for all alignment values.
> Having heuristics and then advice against using it makes little sense to me.

Not advising against them. Only advising that in one particular case they have
to be careful that it has the expected consequence.

> Translations seems like a very common use case, and sometimes it will be
> automated; if we go this route I would expect the net result will be that
> users see translated subtitles where the cues' positions are on the opposite
> side.

We are optimising for a small part of the translation problem though: one where
we have 'align:start' and LTR text initially and then RTL text after

As a consequence of optimising for this, we are making the default rendering of
the common "align:left/right size:50%" case very confusing and forcing extra
markup onto it:
* "align:left size:50% position:0%" or
* "align:right size:50% position:100%".

This is in contrast to merely adding position to the 'align:start/end' case
like this:
* "align:start size:50% position:0%"
* "align:end size:50% position:100%"

If we keep the heuristic, we could even go as far as requiring 'position' to be
added when 'align:start/end' is used - at least then there's a conformance
error and we require explicit expression of intent by the captioner.

You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 16 February 2016 10:54:04 UTC