Page MenuHomePhabricator

List of translations from <languages> tag is not mobile-friendly
Closed, DuplicatePublic


On a phone, visit a page from a multilingual wiki with a lot of translations, e.g. .

Result: The list of languages generated by the <languages> parser extension tag fills the first screen.

It would be more consistent if instead the languages triggered a [Read in other languages] button at the bottom of the page the way e.g. has a [Read in other languages] button (which links to, which offers the languages).

For that matter, why doesn't the available set of translations appear on desktop in the navbar where skins show interwiki links in other languages? Maybe if the <languages> tag hooked into, I think, language->getVariants(), the translations of a page would appear "for free" ☺in the expected location in both desktop and mobile.


Related Gerrit Patches:
mediawiki/extensions/Translate : masterWIP: Populate langlinks in langlinks table

Event Timeline

Spage raised the priority of this task from to Needs Triage.
Spage updated the task description. (Show Details)
Spage added subscribers: Spage, Jdlrobson.
Restricted Application added a project: Readers-Web-Backlog. · View Herald TranscriptJul 21 2015, 1:53 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Ideally these could be delivered in the language button. Could these work similarly to interwiki links and get returned via the following query: (?)

					action: 'query',
					meta: 'siteinfo',
					siprop: 'general|languages',

That wouldn't help, meta=siteinfo + languages as siprop returns "only" all supported languages and language codes. The importnat thing in this query would be prop=langlinks:

action: 'query',
meta: 'siteinfo',
siprop: 'general|languages',
prop: 'langlinks',
llurl: true,
lllimit: 'max',
titles: title,

And the answer is: no :(

Maybe the Translate extension (that's the source of this list) can populate the language links into the langlinks table? That should be possible with the LinksUpdate hook.

Jdlrobson set Security to None.

Any ideas language engineering peeps? Is there a reason these two things are different and can't be the same?

Change 226105 had a related patch set uploaded (by Florianschmidtwelzow):
WIP: Populate langlinks in langlinks table

^ This change basically does the work (with some further work needed). Before I invest further work, I would welcome feedback from language engineering, because it's possible there are side effect's I haven't considered, yet :)

There is

I am highly skeptical about the interlanguage approach. It has lot of tech debt, it doesn't support progress markers, it doesn't support localised language names, it is not giving enough visibility to the language options and we know it is going to change in the future (with compact language links or something else).

Having said that maybe there is a compromise to make here to accommodate mobile users with small effort while not affecting non-mobile users.

Doesn't the compact language links is based on the langlinks as a base?

Ok, that all sounds reasonable, for desktop :) Is there maybe another way you can think about, to access a code->language|link map for a specific page?

Would you think (yeah, that's really drstically) it's possible to "just" hide the language block for mobile users is a good idea?

What happens if we add to languagelinks table in wiki such as metawiki? Are they displayed on the sidebar or not? It would be confusing to have two language lists there, but if they do not show up we could just hide the in-page version in mobile and have mobile to use that data?

I could also make an API changes to make it easier to fetch language versions (in theory you can get it via messagegroupstats already) but somebody needs to use that data.

What happens if we add to languagelinks table in wiki such as metawiki? Are they displayed on the sidebar or not? It would be confusing to have two language lists there, but if they do not show up we could just hide the in-page version in mobile and have mobile to use that data?

I wasn't sure about that, so i tested it (i'm honest: I don't really know, how (technically) the language list in the sidebar is generated). I marked a local test page for translation and added some languages (to be more accurate, it was espanol, deutsch and one other (and english as a source language)) with the change i already uploaded. After that, the needed langlinks were added and reachable via the langlinks api.

Now I have imported the interwiki sql file into the local db and purged the parser cache of the test page (with a null-edit). The list created by the languages hook listed all expected languages and the list in the sidebar was empty. To be sure, that interwiki links would work, I added [[de:Hauptseite]] at the top of the page and saved it. Now i had the 3 languages (espanol, german and english) in the languages-hook list and one (Deutsch) in the sidebar with target dewiki/Hauptseite.

So, if I haven't forget something, there seems to be another magic somewhere and it would work to show the language list on desktop like it is already. In mobile we can hide the list with css and use the data returned by the langlinks api.

Sorry, if this is a bit confusing :)

It seems architecturally these two things should share something in common but right now seem to be separate entities.

If I ask the API for different language versions of a page regardless of whether they are implemented as language links or not I would expect them to be returned by the API.

Likewise I would expect them to consistently be in the left menu. Otherwise you are introducing a confusing UI and making it harder and less logical for people to find languages on our sites.

Is there a task anywhere to refactor the languages code? It's a big task yes.. but that's what we are here to do - not workaround problems! :)

The language list has been like this for years (since the beginning of page translation feature). It's not good but not that confusing on desktop as the intersection of wikis using interlanguage links and page translation is mostly empty.

There is T64702 as well.

Maybe I can hook into the langlinks API.

I already argued above that interlanguage currently provides worse user experience. I am not aware of anyone having time to refactor interlanguage links and <languages/> this year. Do you?

Amire80 triaged this task as Low priority.Jul 22 2015, 2:24 PM

There is T64702 as well.

AFAIK interwikis in sidebar are not supported by MobileFrontend either.

There is no sidebar in Minerva skin in MobileFrontend. Instead interwikis are collapsed inside a JavaScript overlay and available on the special page - - for non-js users.

Partly to decrease size of HTML, partly to provide a better experience (note there is talk about making this language button more accessible in T97377)

Yep, so T64702 should probably be declined if we want to fix this one.

Jdlrobson moved this task from Backlog to Epics on the MobileFrontend board.Aug 4 2015, 6:33 PM

Change 226105 abandoned by Florianschmidtwelzow:
WIP: Populate langlinks in langlinks table

currently not working on it.

ggellerman moved this task from 2016-17 Q2 to 2014-15 Q4 on the Readers-Web-Backlog board.
Kaganer added a subscriber: Kaganer.Oct 8 2017, 8:58 PM

I am going to be bold and mark this as a duplicate of T64702: Extension:Translate's languages box should look like interwiki language links, because this is how it looks like in Timeless in mobile view: