Page MenuHomePhabricator

[TypeaheadSearch] Support lang and dir attributes for text nodes within MenuItem component
Closed, ResolvedPublic

Description

Summary

As noted in the parent task, TypeaheadSearch results on wikidata.org may contain text in different languages (for label, description and alias). We need to ensure that:

  1. Each piece of text is wrapped in an element with the lang attribute set to the language code of the text, for a seamless experience with screen readers
  2. Text directionality is handled in a way that provides a consistent and readable user experience

UX considerations

See the comments on this task; particularly those from @Mooeypoo and @Ladsgroup (RTL language speakers) and @Sarai-WMDE (designer for this component) for details on what's ideal, expected, and practical. Baseline implementation will be to respect the UI direction for all menu items (to avoid a zig-zag effect on the overall alignment), then wrap each text piece in a <bdi> tag (to automatically render the text in the appropriate direction without influencing or being influenced by adjacent text or the UI direction).

Technical details

The wbsearchentities API already provided the lang attribute of the thing that matched the search query via the match property (e.g. if an alias of an item matched the query, the alias and its language were provided). It has recently been updated (see T104344) to include a display property with the lang of the label and description as well. A sample item returned by the API with a matching alias looks like this:

{
  "id": "Q2389931",
  "title": "Q2389931",
  "pageid": 2308845,
  "display": {
    "label": {
      "value": "Arius arenarius",
      "language": "en"
    },
    "description": {
      "value": "species of fish",
      "language": "en"
    }
  },
  "repository": "wikidata",
  "url": "//www.wikidata.org/wiki/Q2389931",
  "concepturi": "http://www.wikidata.org/entity/Q2389931",
  "label": "Arius arenarius",
  "description": "species of fish",
  "match": {
    "type": "alias",
    "language": "en",
    "text": "Sand catfish"
  },
  "aliases": [
    "Sand catfish"
  ]
}

The dir attribute would need to be looked up—WMDE has done this in termbox via a custom directive.

Special thanks to @Michael for clearly outlining this approach in previous discussions!

Acceptance criteria

  • Add a match property to SearchResult so a matching alias can be included in a search result if one exists
  • Update SearchResult type to include optional language data for label, match, and description
  • Update the MenuItem component to support appending a match string to the label so we can render matching aliases
  • Update the MenuItem component to support adding lang attributes and <bdi> wrappers for label, match, and description
  • Update the Wikidata TypeaheadSearch demo on the Codex docs site to demonstrate these new features. This can serve as a simplified example of the eventual implementation of TypeaheadSearch on wikidata.org.

Event Timeline

So a MenuItem can have a label, a match (e.g a Wikidata alias), and a description. This task covers supporting a lang and dir attribute for each of those things. It's clear to me what a MenuItem should look like in a purely LTR or RTL context. But what about the following scenarios?

  1. UI has one direction but all text nodes of a MenuItem have the other. For example, the UI direction is LTR but the MenuItem has an RTL label, match, and description. Should the entire MenuItem appear to be in RTL?
  2. MenuItem has mixed directionality. For example, an RTL label and description, but an LTR match

@Sarai-WMDE / @Michael is this something that you've dealt with already with Wikibase, or is this more of a hypothetical that we need to design for?

Change 775952 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] MenuItem: Support language attributes

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

So a MenuItem can have a label, a match (e.g a Wikidata alias), and a description. This task covers supporting a lang and dir attribute for each of those things. It's clear to me what a MenuItem should look like in a purely LTR or RTL context. But what about the following scenarios?

  1. UI has one direction but all text nodes of a MenuItem have the other. For example, the UI direction is LTR but the MenuItem has an RTL label, match, and description. Should the entire MenuItem appear to be in RTL?
  2. MenuItem has mixed directionality. For example, an RTL label and description, but an LTR match

@Sarai-WMDE / @Michael is this something that you've dealt with already with Wikibase, or is this more of a hypothetical that we need to design for?

It probably won't make much difference to the core of your question, but I would expect case 1 more often to be the other way round: The UI RTL, for example in Persian, but the MenuItem has an LTR label, match, and description, for example in English, because English is the final fallback.
An example would be to search for a specific well-known church in my hometown of Dresden in Persian: https://www.wikidata.org/w/index.php?search=Church+of+Our+Lady+Dresden&title=Special:Search&profile=advanced&fulltext=1&ns0=1&ns120=1&ns146=1&uselang=fa

And this is what it currently looks like in the searchbox:

image.png (526×428 px, 50 KB)

(without any language or directionality markup in the MeunItems) This used to not have any language markup, but now partly does, thanks to @Lucas_Werkmeister_WMDE adding that in 772372

I don't speak any RTL languages, so I can't say if one would expect the purely LTR menu-items to be displayed as such. Also, this might look worse with numbers and punctuation in it? I'll try to find an example for that.

I don't know how much the RTL-speaking community cares about this, I'm not involved in that. @Lydia_Pintscher would probably know more there :). But as I understand it, the goal is to target smaller language communities more in the future, and so good language support might be nice? But I'm not a product person.

In conclusion: it is probably not just a hypothetical, but so far we hadn't dealt with it, but rather most (all?) of us were oblivious to it or didn't see it as very pressing relative to some other things.

So a MenuItem can have a label, a match (e.g a Wikidata alias), and a description. This task covers supporting a lang and dir attribute for each of those things. It's clear to me what a MenuItem should look like in a purely LTR or RTL context. But what about the following scenarios?

  1. UI has one direction but all text nodes of a MenuItem have the other. For example, the UI direction is LTR but the MenuItem has an RTL label, match, and description. Should the entire MenuItem appear to be in RTL?

This isn't QUITE normalized online, but it would be generally simpler (for you to set the "larger" context AND for users, honestly, in my opinion, to go through a list) if all items are aligned to the same side -- while keeping the language itself properly rendered.

This, however, is not something that is always done online -- you see instances of lists having LTR items aligned left and RTL items aligned right; it's not wrong to do it that way especially when we talk about a menu. There's an argument to be made about wider-screen elements where the different alignment can cause the reader to literally move their heads from side to side, but generally a menu item is fairly thin enough to not really have that problem, so this is probably more a design choice.

I personally prefer all aligned the same, but I can't say this is "what everyone's expecting" or what everyone's even doing online.

  1. MenuItem has mixed directionality. For example, an RTL label and description, but an LTR match

Yes, in fact, I was going to warn that I suspect you will have those with the wikidata item (?) if you have a name in RTL, but the wikidata is the identifier, then Qxxxxx will be LTR'ed.

In any case, even without that you may well get mixed directions in each of those, so, considering that fact and my point above about alignment, what I'd recommend doing is "just" making sure each one of those bits of text is bidi-isolated.

You can get that effect by adding <bdi> tags around the text. This would mean that the rendering (LTR/RTL) will be automatic based on the string given -- no matter what the general (or specific) directionality is of the page or larger context, and no matter the alignment of the text.

This is what we do in most UI elements, and works well for 99% of cases, especially when you can't really tell what the structure/content of the pieces of text are. If you encounter edge cases, you can deal with those later.

  1. UI has one direction but all text nodes of a MenuItem have the other. For example, the UI direction is LTR but the MenuItem has an RTL label, match, and description. Should the entire MenuItem appear to be in RTL?
  2. MenuItem has mixed directionality. For example, an RTL label and description, but an LTR match

I would just reiterate @Mooeypoo's advice. From purely a user experience perspective, list/menu items should display consistent justification, and follow the alignment dictated by the language set for the whole user interface (via browser or project/page). Of course, the intrinsic directionality of individual words and elements (e.g. icons) should be respected (regardless of alignment), in order to make sure they're properly rendered.

I don't know how much the RTL-speaking community cares about this, I'm not involved in that. @Lydia_Pintscher would probably know more there :). But as I understand it, the goal is to target smaller language communities more in the future, and so good language support might be nice? But I'm not a product person.

In conclusion: it is probably not just a hypothetical, but so far we hadn't dealt with it, but rather most (all?) of us were oblivious to it or didn't see it as very pressing relative to some other things.

Yes confirmed. Not just a hypothetical as Michael's screenshot demonstrates. We have quite the mix of directionality between different items in the selector and within one item in the selector I fear, especially for anyone not using Wikidata in latin script due to the final fallback to English.

Thanks, everyone, for your thoughtful comments, examples, and suggestions!

I think we should move forward with keeping all menu items justified according to the interface direction, given the feedback here. We can always reevaluate if we get more feedback from RTL readers.

In terms of mixed directionality, the screenshot @Michael posted is fairly close to what will happen if we wrap the label, match, and description in <bdi> tags. One minor difference is that, in the Wikidata example, the label's language is added as an attribute to an element that wraps both the label and the match, so there's no differentiation there. You can see this with the "Liebfrauenkirche" result. This label comes back with the language code en (presumably because this is the label's value in English and English is a fallback for Farsi while German is not), so the whole line is wrapped in an element with lang="en" and is therefore all readable left-to-right:

image.png (114×608 px, 24 KB)

However, in this screenshot of the Codex TypeaheadSearch component, you can see that the label and match maintain the same order no matter what the languages are, so they arguably appear "backward" for this specific item:

Screen Shot 2022-04-05 at 4.00.55 PM.png (910×980 px, 151 KB)

I suppose we could check to see if the language and match have the same lang code, and wrap them together if that's true. But you could also argue that the consistency of the current state is better.

I've updated the patch associated with this task to include <bdi> tags around each piece of text within a Menuitem. Please let me know if you have further feedback, either here or in the patch!

STH changed the task status from Open to In Progress.Apr 15 2022, 9:14 PM
STH triaged this task as Medium priority.

Change 775952 merged by jenkins-bot:

[design/codex@main] MenuItem: Support language attributes

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

Tried some searches, translations, and language combinations in RTL/LTR, and everything works nicely! I agree that the inverse order of the label and alias actually makes sense (in terms of consistency) in the RTL context. Still, would like to wait to get a thumbs up from @Michael and @Lydia_Pintscher.

Tried some searches, translations, and language combinations in RTL/LTR, and everything works nicely! I agree that the inverse order of the label and alias actually makes sense in the RTL context. Still, would like to wait to get a thumbs up from @Michael and @Lydia_Pintscher.

I'd like to defer to someone who actually uses a RTL language :P @Ladsgroup, maybe?

Bidi behavior in internet doesn't follow a pattern. This is an example from my daily experience:

  • Some just doesn't care, if your interface language is LTR, you see text as LTR and other way around.
  • Telegram text editor cares about the first character, if it's RTL, the whole line will be RTL
  • Gmail editor makes the text RTL if you have even one RTL strong[1] character in that line.
  • Twitter has a majority system, if number of RTL characters reaches a certain threshold in that line, the text suddenly jumps to the other side.

From what I've seen in most places, each line gets judged individually (like Gmail/Twitter)

If we want to bring that to here, my suggestion would be to make the text LTR in the RTL env if it's all components are LTR (label, desc and alias) which would make the list jump between left and right and I hope it should be fine given the small width of the search menu but if the width is large enough, it'll make the reader's eye to zigzag and that's not that good and all being RTL (status quo) would be my second choice.

HTH

Thanks for sharing your experience and recommendations, @Ladsgroup!

Regarding lists and menus specifically, that occasional interruption of the reading pattern that generates a more pronounced zigzag is something that I believe we should try to avoid. I lack any RTL native experience, but speaking strictly from a design perspective, keeping the content of list items aligned and ordered consistently is a recommended practice to make lists easier to scan. Order should be defined by alignment to avoid disrupting the user focus, which should be on the content as much as possible.

STH renamed this task from Support lang and dir attributes for text nodes within MenuItem component to [TypeaheadSearch] Support lang and dir attributes for text nodes within MenuItem component.Apr 25 2022, 4:56 PM
AnneT removed AnneT as the assignee of this task.Jun 2 2022, 2:08 PM
EUdoh-WMF subscribed.

Language and directionality implementation look great, thanks for the testing assistance Roan and Anne!

DAbad claimed this task.
DAbad subscribed.

closed