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.

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.

In T104660#1538063, @Jdlrobson wrote:

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.

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.

In T104660#1551998, @Nemo_bis wrote:

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?

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?

@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?

In T104660#1538303, @Ricordisamoa wrote:

In T104660#1538063, @Jdlrobson wrote:

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.

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.

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.

In desktop improvements we worked around this but we still need a longer term plan for mobile.