Page MenuHomePhabricator

Basic support for a responsive language selector
Open, In Progress, HighPublic

Description

Different steps of the Section Translation process (T243495) require language selection. This is an opportunity to create a standard language selection component in Vue that other products could reuse (T287860). This ticket captures the basic behaviour to support language selection.

Overview

The language selector shows a list of languages available for the user to select. Languages are listed using their name in their own language (i.e., the autonym). The number of languages provided in the selector is variable and can be potentially large. The selector supports searching, surfacing frequent languages, and adjusting the layout to the number of languages.

Overview Copy 22.png (768×1 px, 72 KB)

Overview of the selection process:

  • Open the selector. The language selector opens after the user taps on an action (e.g., button) or selection (e.g., drop-down) control. The design of these entry points is out of the scope of the current task. A button can be used for testing purposes.
  • Search. The user types a search query that filters the list of languages shown.
  • Select a language. Taping on a language from the list completes the selection. Closing the selector automatically and making the selected value available to the product using the selector.
  • Close the selector. The selector closes when taping outside the selector, pressing "esc" key or with a close action available on narrow screens. This cancels the selection.

Overview Copy 24.png (768×1 px, 63 KB)

Responsive layout

The layout is adapted to the following factors:

Number of languages

  • 0–9 languages. Suggested languages are hidden. The list of languages has no label, and uses one column.
  • 10-29 languages. Suggested languages are shown using 2 columns. The list of languages uses one column. Both lists are labelled.
  • 30 or more languages. Suggested languages are shown. The lists of suggested and all languages use 3 columns (on wide screens). Additional space is added after each block of 5 rows.
0–9 languages10-29 languages30-* languages
short.png (310×348 px, 11 KB)
default.png (310×348 px, 19 KB)
3cols-and-suggested.png (448×512 px, 40 KB)

Screen size

  • Narrow screen. The selector is shown as a full screen dialog. The list of all languages always uses one column.
  • Wider screen. The selector is shown as a dialog over existing content. The list of all languages can use one or three columns depending on the number of languages (see above). The length of the selector will adapt to the available languages with a max height of 312px.
Wide screenNarrow screen
Group.png (572×904 px, 41 KB)
mobile.png (669×348 px, 34 KB)

Product preferences

  • Option to hide suggested languages. Suggested languages are shown by default when there are 10 languages or more available. However, this list is optional and apps have the option to hide the suggested languages list. In such case, the list of all languages will be shown without a title label.

The layout specifications for the different cases are captured below:

Layout spacing.png (768×1 px, 88 KB)
Layout spacing narrow.png (768×1 px, 60 KB)

Styling notes

Some notes on styling for the different pieces of the selector.

Main panel:

  • Background: white (Base100)
  • Border: 1px in Base70 with 2px radius.
  • Shadow: Base0 at 25% opacity 1px down, 2px of blur

Text styles:

  • Default: Standard body text (sans-serif 16 px in Base10)
  • List title ("suggested", "All languages"): Base30

Header:

  • Separator lines: 1px in Base70

Search bar:

  • Shadow: Base0 at 25% opacity 1px down, 2px of blur
  • Border radius: 2px radius on top corners, straight corners at the bottom.

Hover and focus states

Group.png (316×354 px, 21 KB)

  • Search bar focus state will use the 2px Accent50 border, the standard for input boxes.
  • Language in the list are highlighted with a Base80 on hover.

Search

We may want to reuse existing search components.

Considerations for search:

  • The search box gets the input focus automatically when the selector is opened.
  • User input filters the list of languages based on prefix search as the user types. Search will be case insensitive. When searching, only the search results are displayed (no separate list for "suggested"). See example below.
  • Searching should not change the dialog width. If a wide three-column version of the dialog is shown based on the large number of languages shown initially, searching should not result in the dialog to become narrow despite reducing the number of languages displayed. This avoids unnecessary distraction (as described in T286514).
  • The search API for the current language selector can be reused to support flexible search capabilities (e.g., finding a language name written in any other language)
  • Type-ahead autocompletion will add text after the search term to complete it when a matching language is found. For example, when typing "engli" the autocompletion text will show "sh" in grey to suggest "English" to the user.
  • The search text is cleared when the selector gets closed. That is, previous searches should not remain visible when the selector is opened again.

filtered.png (310×348 px, 8 KB)

Suggested languages

  • The selector displays up to six suggested languages, using two or three columns depending on the number of languages (see responsive layout section).
  • By default suggested languages
  • Apps opening the selector can provide their own list of suggested languages, or hide the list.
  • When suggested languages are not show (or the list is empty), the list of "all languages" will have its title hidden.

Keyboard and pointer support

  • "Esc" key would cancel the selection and close the selector.
  • Arrow keys can be used to move through the options. The active item will be shown with a Base80 background.
  • "Enter" would confirm the selection. Selecting the first results while searching, or the focused element while moving through the options.
  • Hovering a language will show it with a Base80 background.

Group.png (316×354 px, 21 KB)

Sorting languages

Languages order considers their script and their label:

  • Languages are ordered based on the alphabetical of their label (which is the autonym by default).
  • All languages based on one script family are displayed before the languages of a different script. The order of the script families is defined in language data library.

Multiple columns use vertical lists:

  • Columns are divided in blocks of 5 items listed vertically.
    • Suggested languages area displays only 2 items per column since the area is limited to a total of six options.
  • Once all columns are completed, a gap (24px) separates the next block of columns.

The ordering through multiple columns is organized to optimize the scan line. That is, reducing the number of saccades (eyes jumping to the next line). This is illustrated in the image below:

Layout spacing narrow Copy.png (768×1 px, 130 KB)

Further context

This ticket covers only the basic aspects for the selector. Additional usecases requiring additional information, actions, or selection modes will be supported in separate tickets:

For a deep dive on how all these fit together you can check this document.

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

Change 635505 abandoned by Santhosh:
[mediawiki/extensions/ContentTranslation@master] POC: Renderless language selector and custom selectos based on it

Reason:
It was just POC

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

I'm excited over all this changes. I want to know how suggested languages will be chosen? Will it be universal, language dependant or from the user's most visited languages? The three concepts have different social issues, but I would like to know how this can be improved.

I'm excited over all this changes. I want to know how suggested languages will be chosen? Will it be universal, language dependant or from the user's most visited languages? The three concepts have different social issues, but I would like to know how this can be improved.

For the suggested languages we have used in the past an approach that combines multiple criteria and gives priority to the criteria that is more directly connected with the user actions. First, consider the previous choices that the user made in the past (e.g., users switching between English, Korean and Japanese frequently will have those as suggested languages). In case we need to show more suggested languages, the info from the browser language can be included, etc. There is a complete list of the criteria used for the current list of languages. Criteria less directly connected to the user (based on broad location or most spoken languages) is only used as the last resort.

One important consideration is that for the case of switching languages on Wikipedia, the number of languages we show depends on the languages in which the language is available, which will limit the criteria that can be applied. That is, users switching between English, Korean and Japanese frequently may not get any of those options for a particular article that is only available in Portuguese, Spanish and Tagalog.

The above is how our current APIs work and the initial idea is to reuse them. Since the context here is different we may have less of a need to fill a fixed number of slots for the suggested languages. In this process of review for the selector we are open for new ideas on how to make this aspect work better.

Change 695239 had a related patch set uploaded (by Santhosh; author: Santhosh):

[mediawiki/extensions/ContentTranslation@master] Use language-data package for language selectors and autonyms

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

Change 695239 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] Use language-data package for language selectors and autonyms

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

Change 698149 had a related patch set uploaded (by Santhosh; author: Santhosh):

[mediawiki/extensions/ContentTranslation@master] CX3: Introduce responsive language selector

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

This is first iteration and not all features are covered.

What is done:

  • The language selector component with slots for results, noresults
  • Search API integration
  • Uses language-data
  • styling as per design spec(This need further validation)
  • Suggested languages feature
  • Closes on escape key, selects on enter key
  • Columns and breaks as per screen width and available languages
  • Sorting by autonyms
  • Integration to article selector

Not done:

  • Arrow key based selection
  • Auto completion in search field

Screenshots

Narrow screen

image.png (732×411 px, 39 KB)
image.png (732×411 px, 5 KB)

Wide screen

image.png (711×600 px, 62 KB)
}
image.png (711×600 px, 54 KB)
image.png (709×604 px, 67 KB)
image.png (709×604 px, 7 KB)

This is first iteration and not all features are covered.

What is done:
[...]

Impressive list for a first iteration!
Thanks for the update, Santhosh.

Change 698453 had a related patch set uploaded (by Santhosh; author: Santhosh):

[mediawiki/extensions/ContentTranslation@master] SX Language selector: Keyboard support

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

Change 698149 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] CX3: Introduce responsive language selector

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

Change 698453 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] SX Language selector: Keyboard support

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

Change 699161 had a related patch set uploaded (by Santhosh; author: Santhosh):

[mediawiki/extensions/ContentTranslation@master] SX Language selector: Autocompletion support

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

Change 699161 merged by jenkins-bot:

[mediawiki/extensions/ContentTranslation@master] SX Language selector: Autocompletion support

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

Pginer-WMF raised the priority of this task from Medium to High.Jul 12 2021, 9:39 AM

Based on the comments from T286514, I added the following to the spec:

  • Searching should not change the dialog width. If a wide three-column version of the dialog is shown based on the large number of languages shown initially, searching should not result in the dialog to become narrow despite reducing the number of languages displayed. This avoids unnecessary distraction (as described in T286514).

This seems to be already the current behaviour based on the demo, but I thought it was worth it to capture it more explicitly in the "search" section.

@Pginer-WMF I tested this using SX, if that's not the right element to test please let me know.
I found 3 discrepancies with the designs:

  • elements not aligned
    image.png (250×458 px, 11 KB)
  • "Search for a language" text instead of "Search languages"
  • missing separator text
    image.png (272×216 px, 19 KB)

do I file new tasks for any of these or these issues are dealt in the next tasks?

Pginer-WMF renamed this task from Support for a responsive language selector to Basic support for a responsive language selector.Aug 2 2021, 1:00 PM
Pginer-WMF added a subscriber: EChukwukere-WMF.

Moving to QA for a detailed review by @EChukwukere-WMF. This ticket captures many aspects of the new language selector (behaviour, styling, layout, spacing, etc.). We want to make sure that the current implementation present in Section Translation aligns with those details or the missing ones are captured in separate tickets to be implemented in the future (note that some of the later were listed in T253303#7252578 already).

@santhosh You did mention earlier that that the "Arrow key based selection" was not implemented in the first iteration. I want to know if it was later implemented as I did mark this as failed. Let me know if it will be part of the deliverable for this story

@Pginer-WMF I did mark a couple of the Acceptance criteria under this story as failed and will probably move it back to dev
see attached

Feedback
I did also discover other things that does not have to be under this deliverable but can go into future tickets. They are quality ( more of UI/UX) issues that will need attention as we dive deeper. Please advise on what you decide to do

see attached

@santhosh You did mention earlier that that the "Arrow key based selection" was not implemented in the first iteration. I want to know if it was later implemented as I did mark this as failed. Let me know if it will be part of the deliverable for this story

Keyboard based navigation support was later added in this commit https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ContentTranslation/+/698453/

@santhosh ok if that's the case , it does not seem to work. I can move this out of the QA column back to dev. please see the attachments

let me know what you think.

KartikMistry changed the task status from Open to In Progress.May 11 2022, 10:43 AM

@Pginer-WMF It is unclear on what is remaining on this ticket. Since this is not an active area we are working these days, I suggest we either close or park it out of current sprint.

@Pginer-WMF It is unclear on what is remaining on this ticket. Since this is not an active area we are working these days, I suggest we either close or park it out of current sprint.

Ok. Let's move it to the backlog.
For future reference there are a couple of missing pieces identified by Emeka in T253303#7880877.
When we focus on this again, I'll take another look and create follow-up tickets as needed based on that.

@Pginer-WMF Yes we can close this ticket and reopen bugs based on the comments I made above. Thank you