Page MenuHomePhabricator

RFC: Suitable default for accessing language links on all skins
Open, HighPublic

Description

  • Affected components: TBD.
  • Engineer for initial implementation: TBD.
  • Code steward: TBD.

Motivation

Currently Vector prints a list of languages in the left of the screen in the sidebar. This is accessible to users with and without JavaScript. With JS we hide this list so although it is in the HTML it is never shown to users.

An update to Vector will move the languages feature to a more prominent place in the UI - in the top right corner. With JavaScript enabled it will display a popup via the UniversalLanguageSelector.

Currently displaying languages in a usable way to non-JS users using responsive skins is tricky.

  • On Timeless the language button fails to work without JavaScript enabled.
  • On Minerva the language button links to Special:MobileLanguages - a special page provided by MobileFrontend..
  • On Minerva without MobileFrontend installed the language button fails to work without JavaScript enabled.
  • On responsive Vector the list is at the bottom of the page - so not only does the user have to scroll there but they then need to find the language they desire.
Requirements

(Specify the requirements that a proposal should meet.)


Exploration

Rendering the list of languages at the bottom of the page.
Pros: 1) Easy technical solution (HTML) 2) Potential SEO benefits (difficult to measure)
Cons: 1) List of languages looks out of place and unsightly 2) Pages with lots of languages would obscure access to other elements on the page 3) May need to be hidden for JS users to provide a better experience 4) Adds unnecessary weight to the page bloating HTML size.

Move Special:MobileLanguages to core
Pros: 1) Easy technical solution (a link) 2) Code already exists 3) Performance 4) No need to worry about styling of list for JS users 5) Addressable (has own URI)
Cons: 1) Potential SEO downsides 2) not compatible with find on page for specific language name.

MobileLanguages

The parameter given to the page is the page to retrieve languages from.
For example:
https://en.m.wikipedia.org/wiki/Special:MobileLanguages/San_Francisco

Recommended solution

I recommend we move Special:MobileLanguages to core and renaming to Special:Languages. In Vector for non-JS users we will fallback to this page.

This page renders a list of languages. While the page may be difficult to navigate I think there are possible design improvements to group elements and make use of collapsible elements that work without JS (e.g. checkbox hack) if we wish.

Thoughts? Are there any concerns with doing this?

Event Timeline

Jdlrobson claimed this task.
Jdlrobson raised the priority of this task from to Lowest.
Jdlrobson updated the task description. (Show Details)
Jdlrobson added subscribers: Glaisher, Moushira, Tgr and 11 others.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 2 2015, 11:44 PM

Maybe we can use this as a fallback for non-JavaScript clients when the current interlanguage list is replaced with a compact language selector. Before that happens I think you would be the only user of the special page.

Nemo_bis updated the task description. (Show Details)Jul 8 2015, 9:32 AM
Nemo_bis set Security to None.
Nemo_bis added a subscriber: Nemo_bis.

Jon, it would be useful to clarify what MobileFrontend's requirements are before it can use a standard language selection facility such as jquery.uls or the ULS interlanguage links.

@Nemo_bis mainly it solves the problem of the large amount of HTML generated by supporting up to 200 languages. In mobile we aim to reduce the HTML we send down the wire as much as we possibly can and we do this by using JavaScript (currently a mobile specific module but there is no reason with some work it couldn't use ULS). This would help skin developers in the mean time as it will allow them more flexibility about how they surface languages.

This would be a non-JavaScript fallback. As @Nikerabbit states in the future this could be used for ULS.
We currently have this use case, so I'd be keen to get this more visible so when @Nikerabbit needs it is available and no one re-invents the wheel.

Not sure why the thumbs down from @Ricordisamoa - I'm not sure how making languages more accessible is a bad thing.

kaldari removed a subscriber: kaldari.Aug 14 2015, 1:34 AM

Not sure why the thumbs down from @Ricordisamoa - I'm not sure how making languages more accessible is a bad thing.

"Compact interlanguage links" only work with JavaScript, so I'm not sure why desktop users need a non-JavaScript fallback.

MaxSem removed a subscriber: MaxSem.Aug 17 2015, 7:43 PM

the large amount of HTML generated

AFAIK, this assumption about large amounts of HTML has never been field-tested. What's the actual payload and what is the threshold that must not be crossed?

This would be a non-JavaScript fallback. As @Nikerabbit states in the future this could be used for ULS.

MobileFrontend developers could/should submit patches for https://github.com/wikimedia/jquery.uls to have such HTML fallback, especially as you already have Special:MobileLanguages as starting point.

MobileFrontend developers could/should submit patches for https://github.com/wikimedia/jquery.uls to have such HTML fallback, especially as you already have Special:MobileLanguages as starting point.

That makes no sense as jquery.uls is library written in JavaScript. Did you mean the ULS extension?

Jdlrobson moved this task from Backlog to Team:Growth on the MobileFrontend board.Nov 4 2015, 5:01 PM
Nemo_bis edited projects, added I18n; removed Language-Team.Dec 5 2015, 10:57 AM
Danny_B moved this task from Unsorted to Move on the Technical-Debt board.Jan 23 2016, 1:25 AM
jhobs raised the priority of this task from Lowest to Medium.Dec 1 2016, 9:42 PM

This proposal is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

This got 10 votes in the wishlist (#43) @Tgr is this something we could work with you to achieve this quarter?

Tgr added a comment.Mar 6 2017, 10:47 PM

@Jdlrobson to me a special page does not seem all that useful since most pages wouldn't want to show a bare languages page (it makes sense for a minimalistic mobile view but in general it's not great UX) but rather some kind of dynamcally loaded content like Compact Language Links does. Maybe a set of helper classes that can render a partial or full list of languages or return structured data about them, so that MobileFrontend can create a special page with a minimal amount of boilerplate code, and ULS can reuse it?

Jdlrobson moved this task from Backlog to Later on the Readers-Web-Backlog (Tracking) board.

Not sure why the thumbs down from @Ricordisamoa - I'm not sure how making languages more accessible is a bad thing.

"Compact interlanguage links" only work with JavaScript, so I'm not sure why desktop users need a non-JavaScript fallback.

This assumes vector skin. Other skins including Minerva do not run compact interlanguage links.
As part of the desktop refresh project, one of the goals I've heard is that languages are not as prominent as they should be. In one mock I have seen "read in another language" in the top right of the screen. If this does happen, we'll need a fallback for non-JavaScript users who click that button. Rather than reinventing the wheel, having a common special page seems appropriate here.

Jdlrobson updated the task description. (Show Details)Oct 9 2019, 4:34 PM
Restricted Application added a subscriber: Masumrezarock100. · View Herald TranscriptNov 5 2019, 5:42 PM
Jdlrobson moved this task from Inbox to Next up on the User-Jdlrobson board.Nov 5 2019, 5:42 PM
Jdlrobson moved this task from Next up to OKR Backlog on the User-Jdlrobson board.
Jdlrobson renamed this task from Special:MobileLanguages should be in core and called Special:Languages to RFC: Provide a suitable fallback for language access on all skins.Jan 31 2020, 10:04 AM
Jdlrobson raised the priority of this task from Medium to High.
Jdlrobson added projects: Timeless, TechCom-RFC.
Jdlrobson updated the task description. (Show Details)

A lot has changed since T104660#1423974 that Minerva is the only beneficiary of a non-JS language switcher - I think Timeless would benefit from such a special page as will Vector as we proceed with the desktop improvements project.

As part of this project,. I'd like to move the functionality of Special:MobileLanguages into core so that we can provide a non-JavaScript fallback for accessing languages across skins in MediaWiki. I've marked as an RFC as guidance from other skin developers e.g. @Isarra (to gather any additional requirements or other solutions) and the language team e.g. @Nikerabbit would be useful to get a sense of the technical challenges (if any)

I see the current Special:MobileLanguages page uses ApiMain to access languages, so I suspect as part of this change we may need to replace that with some PHP services.

While the sidebar can be omitted in its entirety by the skin, the language list being displayed in the sidebar isn't exactly a skin-level decision right now. As most skin components (page heading, sub title, page indicators, body content) the sidebar is a primitive in the skin system and displayed by most skins. The exact HTML structure used is in the hands of the skin, but the array used to inform its contents comes from core.

Having said that, moving it (within core) to a different primitive seems fine. Based on the mock up, it looks like the proposal is to make the element a Page indicator, this is the same position we use for the "Help" icons shown on some special pages.

I will note that being included in HTML , working for Grade C (without JavaScript), and being performant are not mutually exclusive. For example, there are numerous ways to make an element's visibility toggled using pure CSS. See the "Table of contents" and "More actions" toggles for example (in Vector) and also Minerva's recently refactored hamburger menu. In terms of rendering speed, remember that all major browsers use stream parsing and lookahead parsing. This means that any additional payload at the bottom of the HTML has effectively zero rendering impact in terms of speed – comparable to an async JavaScript request.

TechCom accepted this RFC in the last triage meeting. I noted that it could do with a clearer problem statement that outlines what product/design decisions have been made already and what the requirements are for the technical solution. This would allow participants to better evaluate the proposed solutions and know what other solutions might make sense to propose.

Demian added a subscriber: Demian.

Having said that, moving it (within core) to a different primitive seems fine. Based on the mock up, it looks like the proposal is to make the element a Page indicator, this is the same position we use for the "Help" icons shown on some special pages.

I don't think that is the plan. I've not seen any mocks including page indicators and highly doubt they'd be included together in the same grouping (they weren't in Minerva for example).
Edit: Mock with indicators

For example, there are numerous ways to make an element's visibility toggled using pure CSS. See the "Table of contents" and "More actions" toggles for example (in Vector) and also Minerva's recently refactored hamburger menu.

Yes this will be considered...

In terms of rendering speed, remember that all major browsers use stream parsing and lookahead parsing. This means that any additional payload at the bottom of the HTML has effectively zero rendering impact in terms of speed – comparable to an async JavaScript request.

... but my gut feeling says to get this to work the languages HTML will need to be at the top of the page and that such a solution will not be practical. At least that was an issue we ran into while working with the main menu in Minerva.

TechCom accepted this RFC in the last triage meeting. I noted that it could do with a clearer problem statement that outlines what product/design decisions have been made already and what the requirements are for the technical solution. This would allow participants to better evaluate the proposed solutions and know what other solutions might make sense to propose.

Can you clarify what accepted means in this context?
We will have more details closer to the time we begin this work.

As most skin components (page heading, sub title, page indicators, body content) the sidebar is a primitive in the skin system and displayed by most skins. The exact HTML structure used is in the hands of the skin, but the array used to inform its contents comes from core.

I think this RFC will require revisiting that e.g. making new primitives available. I will have more implementation details closer to when we work on this.

ovasileva moved this task from Incoming to Needs Prioritization on the Readers-Web-Backlog board.
Moushira removed a subscriber: Moushira.Feb 19 2020, 9:28 PM
Krinkle renamed this task from RFC: Provide a suitable fallback for language access on all skins to RFC: Suitable default for accessing language links on all skins.Apr 3 2020, 10:03 PM
Krinkle updated the task description. (Show Details)
Krinkle moved this task from Under discussion to P1: Define on the TechCom-RFC board.