Makes perfect sense to me. Perhaps it can be done as part of the "Desktop Refresh" project.

To take into account: not all sitelinks are on Wikidata. There are some local overwrites that still use the in-line way of creating interwiki links. These are likely to stay also long-term. In addition the links between main namespace pages on Wiktionary is created automatically without Wikidata involvement. They are created by the Cognate extension instead.

Should the link always go to the article tab? Or should the history tab point to the history tab of another language?

@Johan I think this is the main question. Can you frame this request from a user need / workflow perspective? It may help clarify some of the open questions.

Interestingly we actually intentionally disabled interlanguage links from the advanced Talk pages on mobile because we thought it might be confusing (i.e. where does it lead?).

In Vector the "tab" has more prominence than on mobile because it's located above the page title. So I think if we went from en/Talk > ja/Talk, or en/History > ja/History I think that would make sense from a system perspective, but not sure if that matches the actual workflow/use case.

Relatedly, we've talked a bit about how it might make more sense for the page title to be above the tabs (instead of below). I think if we went in this direction it would be more clear that you'd get directed to the article tab of the new language, even if you're on Talk/History/etc.

@Ata had a maybe obscure but still interesting use case.

In most cases, I'd see the use case as not having to take the extra step. A couple of examples:

• Looking at the article history of an article in German Wikipedia I realise it's got to be imported from English. I don't want to comb through the history to find the link to the English article, it's quicker to just click on the language link. But, uh, it's not there? Oh. I have to go to the article tab first.
• I want to check out article X in three languages. At the first, I start wondering a thing, and also check out the history tab. Once there I'm confused there are no language links.

But that's just a few things I had in mind when I created the ticket. There might be other reasons I hadn't thought about.

@alexhollender I could ask a bit more widely to see if people have more use cases/opinions, if you'd want that.

@Johan - That would be helpful, thank you! Our main concern when addressing the mobile case was the potential confusion this could lead to for new users who don't have a good understanding of what a language link does. When testing a lot of users mentioned that they did not understand that switching languages leads to to another wiki altogether. I can see that being an argument for adding languages to things like talk and history, but would like to see a few more use cases and discuss a bit more first.

I just realised we do show the "Language" header though, just not the actual language list, and show as if there were no language links from the talk, edit and history tabs. Maybe that can be confusing?

Please merge as appropriate with T30604: Show interlanguage links on associated talk pages too. I think it should go in the direction of the earlier task, but this was linked from Tech News today, so... (You will see other interesting requests mentioning the earlier task as well.)

I like the idea to have the interlanguage links top right, on the same line as the title, with a drop down menu.
For new users when they would see interlanguage link on a talk page they might expect to see a translation of the talk page. Only user testing will tell. So probably linking to the article is less confusing.

Looking at the article history of an article in German Wikipedia I realise it's got to be imported from English. I don't want to comb through the history to find the link to the English article, it's quicker to just click on the language link. But, uh, it's not there? Oh. I have to go to the article tab first.

That's a good point. Also in foreign language it might be hard to find history tab (especially if you switch from LTR to RTL). So switching to history tab directly would be nice.

But also that would make more sense if the language switch wasn't on the sidebar. Links on the sidebar are not related to current tab. So I would say that's just another reason to migrate language switch to tab's area on desktop.

Also use the same icon on mobile and desktop. That would create a nice bridge and enhance UX for both editions of wikis. I.e. you would learn the icon on desktop and it would be easier to find language switch on mobile or vice-versa.

Oh. Note that the area on the right side of title is already used by various icons and maps. Not sure how many wikis have such things but Polish Wikipedia have this for ages.

Would be hard to change. Not impossible, just something to take care of. Probably by moving the existing items to the left (so language switch would be right-most and then the other features would follow to the left).

Another option would be to add the language switch beside the watch icon... Doesn't look great to me, but it's an option 😉

Relatedly, we've talked a bit about how it might make more sense for the page title to be above the tabs (instead of below).

To comment on that. You actually should not do that because of WCAG. Either you would have wrong order of elements (DOM and visual should be the same). Or (if you move h1 in dom) you would have h1 point to navigation, not to content. And so far Wikipedia was exemplary in this area, so probably don't change that 🙂

It is better to link to the same kind of page, for example history et cetera, I think.

But it's better more to display ones that links to each of them. (For example, one that is normal size links to the article page and one that is superscript links to the same kind of page.) And I want users can choose which.

My case was not a common one but let me put it as an example here. In ukwiki there is a traditional template for talk pages of articles translated from another language, with editor ideally putting the id of version the article was translated from. I once had to correct a bunch of incorrectly used version ids. My workflow on desktop looked like this: open the talk page in ukwiki, observe the problematic id → go to the article tab → go to the article history page, look up the creation date → go to article tab → switch languages → go to the history of that page, look up the respective version id → switch languages back → go to the talk page, edit it. (Without the last two steps if using different browser tabs).

Going from history page to history page would be generally useful when dealing with translated articles: there is sometimes a need to check how did the source article looked like at the moment of translation (e.g. to make sense of a badly translated part, to check whether there really was such a part there etc.).

In ukwiki village pump @Olvin suggested that we have a link from a talk page to article (rather that talk-page-to-talk-page). I agree, since talk page discussions might refer to other language versions of articles that editors would want to look up.

A few things to clarify:

• in Vector the language links are being moved to a button/menu in the article header (more info here)
  • @Nux this includes adjusting the location of the coordinates and other article indicators, as you pointed out (T263511)
• do we know if the issue noted by @Qgil in T30604#845992 is still an issue?
• @Johan "Show language links from other tabs than the article tab" — can we rename this for more clarity/specificity to: "Show language links on Talk & History pages"? Or are there others we are aiming to include here?

I've checked several Wikipedias and from what I can tell Talk pages don't have any conflicting elements:

History pages however seem to commonly have a Help button in the location that we're moving the language button to, so we'd need to move that either next to or below the button:

@alexhollender I was only thinking of history and talk, so sounds fine by me. Unless anyone else has a better idea?

Though T47687 is about the edit tab, if we were planning about doing anything about that.

In T262472#6674940, @Johan wrote:

Though T47687 is about the edit tab, if we were planning about doing anything about that.

Ok I'm going to be bold and suggest we handle the edit tab use case separately. cc @ppelberg

Technically it should be possible to add the button to history or edit pages as they concern the same underlying article, but not to talk pages, as from a technical POV the software allows a talk page to be translated and be available in other languages.