Page MenuHomePhabricator

In the "New video player" beta feature, Subtitle and Quality lists are forced to LTR direction
Closed, ResolvedPublicBUG REPORT

Description

To reproduce:

  • Enable the New video player on Commons.
  • Go to https://commons.wikimedia.org/wiki/File:Edit_Button.ogv?uselang=he (this will show the page with Hebrew UI language)
  • Play the video.
  • Click the Subtitles button.
  • Problem 1: Look at items for languages "brezhoneg", "cymraeg", "deutsch": they are rendered incorrectly.
  • Click the Quality button.
  • Problem 2: The letter "p" is separated from the numbers.

The reason for this is probably that the whole vjs-control-bar element is forced to have the LTR direction in HTML. This is mostly fine, because media players are usually oriented from left to right even for users of RTL languages. However, the <ul> elements that display the menus for these two buttons must have the RTL direction when the user interface is in an RTL language.

This works correctly in the non-beta video player, so this would be a regression.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Iniquity changed the subtype of this task from "Task" to "Bug Report".

Change 752224 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/extensions/TimedMediaHandler@master] Fix directionality of videojs interface text elements

https://gerrit.wikimedia.org/r/752224

TheDJ triaged this task as Low priority.

oh no now the subtitle menu is broken of course.. ugh.. i might have to go upstream and get language codes added...

right.. so the problem is of course that we have ltr text fragments in the same textfragments as the rtl text.. and then for the resolution switcher these are even joined with text adjacent numbers.....

@Mooeypoo if you have some time, i'd love to pick your brain on this.
The problems are as follows:

  1. Our strings (incl rtl strings) are embedded in a ltr container.
  2. The resolution menu has ltr text fragments like: 360p and 1080p embedded into potentially rtl language strings
  3. The language menus have multiple languages (of which we do not know the language code as an attribute)
  4. The library generate UI that does not take multiple languages into account
  5. We sort of can only modify the strings and the CSS, not the structure of the generated html (at least not easily)

So i started by settings the direction:rtl on all spans that are UI text when the userlanguage is rtl.
This actually seems to fix everything in Chrome.. But in Safari my ltr string "English (en)" then becomes "(English (en"

So I tried playing with unicode-bidi but that didnt' really seem to help either. Is the only solution to insert RLM LRM markers into the strings themselves in that case (considering i can't fully control the dom)?

@Mooeypoo if you have some time, i'd love to pick your brain on this.

I'd love to try, but this is an interesting problem... I admittedly did not have a chance to go over any of the code yet, so I'm mostly offering some guesses here for now based on previous experience.

The problems are as follows:

  1. Our strings (incl rtl strings) are embedded in a ltr container.
  2. The resolution menu has ltr text fragments like: 360p and 1080p embedded into potentially rtl language strings
  3. The language menus have multiple languages (of which we do not know the language code as an attribute)
  4. The library generate UI that does not take multiple languages into account

(... eh. Unfortunately not uncommon.)

  1. We sort of can only modify the strings and the CSS, not the structure of the generated html (at least not easily)

So i started by settings the direction:rtl on all spans that are UI text when the userlanguage is rtl.
This actually seems to fix everything in Chrome.. But in Safari my ltr string "English (en)" then becomes "(English (en"

So I tried playing with unicode-bidi but that didnt' really seem to help either. Is the only solution to insert RLM LRM markers into the strings themselves in that case (considering i can't fully control the dom)?

Unfortunately in my experience the unicode-bidi directive doesn't always work as consistently as <bdi> tags or control points. Since it sounds like you can't add html tags (my initial suggestion would've been to add <bdi>) then my suggestion is to do that in the translation string itself.

There's the magic word bidi in translatewiki/translations that wraps around text or (more often) parameters: {{bidi:$1}} this wraps the result in isolation control points.... perhaps this can help?

Ok, applied bidi to some of the strings of TMH: https://translatewiki.net/w/i.php?title=Special:Translate&group=ext-timedmediahandler-user&language=he&filter=&optional=1&action=translate

We will see how that pans out exactly. Also still needs to be done for the other rtl languages of course and the patch is required as well.

Ok, applied bidi to some of the strings of TMH: https://translatewiki.net/w/i.php?title=Special:Translate&group=ext-timedmediahandler-user&language=he&filter=&optional=1&action=translate

We will see how that pans out exactly. Also still needs to be done for the other rtl languages of course and the patch is required as well.

Yeah, if this works out I'd add it to the other RTL languages, but also probably to the qqq for changed/newer translations to not forget it... I do hope this works!

  1. The resolution menu has ltr text fragments like: 360p and 1080p embedded into potentially rtl language strings

I'm quite sure that these numbers and even the letter p after are not a problem by themselves. Putting them in {{BIDI}} is probably unnecessary.

  1. The library generate UI that does not take multiple languages into account

This sounds like the main problem :)

So i started by settings the direction:rtl on all spans that are UI text when the userlanguage is rtl.

Good start.

This actually seems to fix everything in Chrome.. But in Safari my ltr string "English (en)" then becomes "(English (en"

This bug had been one of the most annoying things for RTL languages for many years. The handling of parentheses was changed in the standard of the Unicode bidi algorithm in ~2013 thanks to a proposal from Microsoft that made parentheses appear correctly most of the time with zero effort from developers or users. These changes were good, and they were implemented in Gecko in ~2016 and in WebKit in ~2019 (or maybe only in Blink?). I guess that Safari uses an old version of WebKit. Microsoft, Mozilla, and Google tend to be better than Apple at implementing i18n things :/

If the rest of the string is in an element with dir="rtl", then putting the language name ("English") in a <bdi> tag should fix this. It's probably possible to do it with {{BIDI}} in the message, but it's a bit too manual to do it for every language. Can it be added to the default message?

Change 752224 merged by jenkins-bot:

[mediawiki/extensions/TimedMediaHandler@master] Fix directionality of videojs interface text elements

https://gerrit.wikimedia.org/r/752224