Page MenuHomePhabricator

Vector-2022: Try to improve language variant menu selector visibility
Open, MediumPublic3 Estimated Story PointsFeature

Description

It seems considerable to implement the suggestion from the demo picture in T278372 for language variant menu.

image.png (456×1 px, 216 KB)

Event Timeline

Change 908286 had a related patch set uploaded (by Winston Sung; author: Winston Sung):

[mediawiki/skins/Vector@master] Vector-2022: Move language variant menu to the left/right side of interlanguage menu

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

Test wiki created on Patch demo by Jdlrobson using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/b371c53547/w

image.png (712×692 px, 55 KB)

The text inside dropdown menu looks a little bit big, could you make it 14px (the same as text inside "tools" dropdown)?

The text inside dropdown menu looks a little bit big, could you make it 14px (the same as text inside "tools" dropdown)?

It's currently the same font size of the non-JavaScript interlanguage menu.

If we want to make it smaller, I think it's also needed for the interlanguage menu, as I only added the variant menu CSS selectors to the original stylesheet for interlanguage dropdown menu.

image.png (498×1 px, 64 KB)

If we change both of them to 14px, the demonstrated result:

image.png (477×1 px, 59 KB)

Test wiki created on Patch demo by Winston Sung using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/c08839db19/w

  • If there's language variant menu, the language menu would always appear on the top including on main page.
  • When there's variant on the main page, should we:
    • hide the top language button or the bottom interlanguage button, or
    • move variant button to bottom as interlanguage button does, or
    • display interlanguage button in both places?

@Winston_Sung currently the two language menus overlap when JavaScript is disabled. Could we better visually separate those?

image.png (788×484 px, 68 KB)

When there's variant on the main page, should we:

The language button at the bottom of the page is a temporary state that I hope will be removed in future. I think for variants, it would be best to either retain the tab for the main page as it currently is (I think this would probably be best for now) or put them alongside the language menu for consistency.

LGoto set the point value for this task to 3.Apr 17 2023, 5:20 PM

Currently the two language menus overlap when JavaScript is disabled. Could we better visually separate those?

image.png (788×484 px, 68 KB)

For the current approach, I don't think there are easy solution except using hover in CSS, but I don't think that's a good idea.

Currently the two language menus overlap when JavaScript is disabled. Could we better visually separate those?

Another solution would be solving T200142: Create a logo for LanguageConverter to add the icon, and this would make it wider.

For the current approach, I don't think there are easy solution except using hover in CSS, but I don't think that's a good idea.

How about something like:

.vector-menu-content { width: 100%; }
 .vector-page-titlebar > div { margin-right: 8px;}

The key thing is to stop them overlapping.

.vector-menu-content { width: 100%; }

I didn't see anything changed with / without this line.

.vector-page-titlebar > div { margin-right: 8px;}

This is pretty tricky and only work if the label text has more than 3 Han characters, but zh-Hans and zh-Hant labels are only 2 Han characters, and that would increase the margin from 8 px to 28 px.

8 px:

image.png (411×257 px, 22 KB)

28 px:

image.png (415×312 px, 24 KB)

I think it may be better to support the selection of variants integrated as part of a single language selector rather than providing two separate entry points about language selection. Having a single entry point would crowd less the page and will allow for users to switch directly to a specific variant (e.g., a user on English Wikipedia could search for "Traditional Chinese" in the selector to access directly such variant).

This approach was mentioned in T278372#7023626, and there are more detail in the language selector component design documentation. I created a separate ticket focusing on the proposed approach: T334938: Language variants support for the responsive language selector

Variants Overview.png (768×1 px, 83 KB)
Overview Copy 7.png (768×1 px, 77 KB)

I think it may be better to support the selection of variants integrated as part of a single language selector rather than providing two separate entry points about language selection. Having a single entry point would crowd less the page and will allow for users to switch directly to a specific variant (e.g., a user on English Wikipedia could search for "Traditional Chinese" in the selector to access directly such variant).

Then another design issue came up:

  • The language variant menu use the current viewing variant as the menu label
  • The language menu use
    • Vector-2022 skin: "${Interlanguage count} languages"
    • FandomDesktop skin: Local language name
  • How do we provide information about current used language variant without additional clicks (visible by default)?
    • Changed the language menu label to current used language variant
    • Display it elsewhere without clicking the menu

Also, what would be the design for non-ULS interface?

Wht about something like this?

Screenshot 2023-04-18 at 9.24.43 AM.png (499×1 px, 327 KB)

What about something like this?

Screenshot 2023-04-18 at 9.24.43 AM.png (499×1 px, 327 KB)

Looks okay. Any thoughts?

CC:
@Pginer-WMF
@Stang

Wht about something like this?

Another question:

If we use this solution, where should we put p-variants id and .mw-portlet-variants class?

If we use this solution, where should we put p-variants id and .mw-portlet-variants class?

The .mw-portlet-variants class is not really important, only the ID (since it's used for addPortletLink). I'd recommend nesting the list inside an li tag

e.g.

<ul id="p-lang"><li>
<ul id="p-variants"...></ul>
</li>
<li>
<a>lnaguage link one.</a>

See Minerva skin as a reference :
https://zh.m.wikipedia.org/wiki/%E8%A5%BF%E7%8F%AD%E7%89%99#p-lang

What about something like this?

Now it looks strange for "Add languages (Simplified Han, Singapore)".

But if we switch the order to "Simplified Han, Singapore (Add languages)", the place looks like is designated for language name instead of variant name.

Another thought: Use a pipe | instead of round brackets () to separate them.

ovasileva triaged this task as Medium priority.Apr 24 2023, 1:58 PM

Additional thoughts:

  • Probably consider about the design from Timeless skin:
    image.png (847×273 px, 21 KB)

Wht about something like this?

Screenshot 2023-04-18 at 9.24.43 AM.png (499×1 px, 327 KB)

This looks good. It goes in the same direction as some of the ideas proposed for the future language selector with variant support. so I think it could be considered an incremental iteration.
Some aspects to consider:

  • The language selector has already labels for groups of options (when there is a larger number of languages, example below). The same text style can be used to label the section of variants. The groups could be labelled as "Variants for <language name>" and "All languages" (if the rest of languages are in a single group (otherwise using the usual labels: "Suggested languages" "Worldwide", "America"...)
  • For the indication of the variant, I wonder if it may be enough to use a compact code for it. For example, using "33 languages (zh-sg)" (In the example I used small caps, but we can consider a code in the local scripts if it exists). In this way the label to access languages would remain compact while still providing a small reminder of the active variant, an users can just open the selector to find the full name versions.

I exemplified the ideas below:

en.wikipedia.org_wiki_Moon(iPad Mini) (7).png (1×2 px, 868 KB)
en.wikipedia.org_wiki_Moon(iPad Mini) (6).png (1×2 px, 489 KB)

Test wiki on Patch demo by Winston Sung using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/c08839db19/w/

By the way, I think that the design of the mobile interface should be consistent with the desktop one. Currently all variants belong to the "recommended languages" area in the language selector.