Page MenuHomePhabricator

Metadata within topic containers gets jumbled when switching between languages
Closed, ResolvedPublic

Assigned To
Authored By
ppelberg
Apr 2 2022, 12:38 AM
Referenced Files
F35288174: rect24-87.png
Jun 30 2022, 12:29 AM
F35049997: image.png
Apr 13 2022, 3:41 PM
F35049993: image.png
Apr 13 2022, 3:41 PM
F35049995: image.png
Apr 13 2022, 3:41 PM
F35050006: image.png
Apr 13 2022, 3:41 PM

Description

Issue

  1. Visit a wiki that has been configured to support LTR languages*
  2. Navigate to a talk page where Topic Containers are enabled
  3. Change the "Display language" to a RTL language that uses Western Arabic numerals (e.g. Hebrew)
  4. Notice the interface elements that used to appear on the left side of the screen now appear on the right (e.g. the site's search field)

Actual

  1. ❗️ Notice the numerals that appear within the Topic Container appear after the text labels rather before them (read: "comments 4")

Expected

  1. ✅ Notice the numerals that appear within the Topic Container appear before the text labels rather before them (read: "4 comments")

*This also happens if you visit a wiki configured to support RTL languages and change the "Display language" from an RTL to an LTR language using Western Arabic numerals.

NOTE: this issue will not occure if the translation puts text before the text (e.g. if the English translation was There are $1 comments instead of $1 comments, the metadata would display correctly).

Open questions

  • 1. Should Topic Containers be treated as a singular piece of interface that should maintain the directionality of the interface language? Meaning: all units, actions and metadata, would be aligned opposite of the content in the cases this ticket covers.
  • 2. Should each piece of metadata (last comment, number of people in discussion) be treated as an individual unit that flows in the same direction as the content language? Note: this is how [edit ] and [edit source] buttons are treated.
  • 3. What does precedence say? How does VE handle this case?

Done

  • Expected behavior is implemented

Thank you to @Tacsipacsi for reporting this issue: Topic:Wse3oklohvbmozfx.

Event Timeline

This is not necessarily an obvious fix. The line between content and interface is somewhat blurred with interface added to headings, as the heading text itself is part of the content.

There is already and existing "bug" here in that the section [ edit ] links are shown in the content direction, although because this isn't usually a problem because of the bidi algorithm. If you add a digit to the section edit link, you can see it is rendered incorrectly, e.g. setting to "1 edit" creates:

image.png (209×523 px, 28 KB)

Another manifestation of this issue is seen with multiple edit links. Here "edit" should be "first" before "edit source", so arguable on the right. Also because the padding is flipped, there is a missing space between the square brackets and the links:

image.png (41×184 px, 3 KB)

If we set the metadata wrapper to the correct directionality, then the text alignment (correctly changes), but may be considered confusing:

image.png (287×1 px, 70 KB)

We could set the direction on each metadata item individually:

image.png (171×762 px, 28 KB)

However the buttons are now showing LTR content, but in an RTL order (# of comments is last)
While this looks okay at the moment, because the items are somewhat independent, it is not necessarily always going to work well if our design added any visual connection between the items, or there was some meaning to the order they appeared.

We could set the direction on each metadata item individually:

image.png (171×762 px, 28 KB)

However the buttons are now showing LTR content, but in an RTL order (# of comments is last)
While this looks okay at the moment, because the items are somewhat independent, it is not necessarily always going to work well if our design added any visual connection between the items, or there was some meaning to the order they appeared.

As you noted for the edit links, it may even be desired. If you however want to proceed with the reverse order (by setting the directionality on the wrapper element), what about something along these lines?

:dir(rtl) > .ext-discussiontools-init-section-wrapper-metadata {
	text-align: right;
}
:dir(ltr) > .ext-discussiontools-init-section-wrapper-metadata {
	text-align: left;
}

(In production you would of course use something with slightly better browser support.)

Notes/outcomes from 17 May conversation with @Esanders

  1. People are most likely to experience this issue at multi-lingual wikis that default to English (e.g. meta and mediawiki)
  2. In line with "1.", I'm removing this task as a blocker to the initial partner wiki deployment
  3. There are a series of open questions we'll need to answer before we can address this issue (see ===Open questions in task description)
matmarex subscribed.

This is still an issue, and worse, in the current design (T311663). We definitely need to do something.

If we set the metadata wrapper to the correct directionality, then the text alignment (correctly changes), but may be considered confusing:

image.png (287×1 px, 70 KB)

We could set the direction on each metadata item individually:

image.png (171×762 px, 28 KB)

However the buttons are now showing LTR content, but in an RTL order (# of comments is last)
While this looks okay at the moment, because the items are somewhat independent, it is not necessarily always going to work well if our design added any visual connection between the items, or there was some meaning to the order they appeared.

I think either of these would be reasonable. To rephrase:

  • Solution #1 is to make the whole metadata wrapper use interface direction.
  • Solution #2 is to make the metadata wrapper use content direction, and make each label/control in it use interface direction.

As someone who doesn't speak an RTL language, I'm leaning towards #1 because:

  • On some discussion pages you already have horizontal "slices" in differing directionalities (e.g. a village pump page that mixes normal discussions and WMF announcements), and our metadata wrapper is just another slice.
    rect24-87.png (1×2 px, 219 KB)
    (Now, this is still confusing, but I feel like that's just the normal state with mixed-directionality content.)
  • It is easier to implement and reason about if we need to make any other design changes.
  • It resolves T311663 too in a natural way.

We should definitely be open to feedback from anyone actually using the wikis that way, and switch to #2 if it feels more natural to them. (Or to some different approach, but I don't see any other good ones.)

Change 809728 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] Use interface language direction for topic metadata wrapper

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

Change 809728 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Use interface language direction for topic metadata wrapper

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