By the way, can we link these pages to Wikidata? Or somewhere to connect them inside the ULS extension?

@Iniquity what is the criteria for determining if a page can have languages in your opinion ? Is it a site configurable list of namespaces or something else?
In the case of https://ru.wikipedia.org/w/index.php?title=MediaWiki:Edittools it seems that there is nothing stopping me from linking to another language version of MediaWiki:Edittools for example in the software.

Seems like our next step would be to define a list of namespaces that allows for translation. Maybe something like:

(Main/Article) - yes
Talk - no
User - no
Wikipedia - yes
File - no
MediaWiki- no
Template - no
Help - yes?
Category - no
Portal - no
Draft - no
TimedText -no
Module - no

Thoughts? We'd probably have to go through namespace lists across projects as well. Not sure but I've also noticed that within the add languages entrypoint, there is an entrypoint for translation on some namespaces (main) and not on others (talk). @Pginer-WMF - do we know what logic we're using for this? Maybe we could also just copy that?

Since this button also includes the access to language settings, I think it should be shown on all pages. The logic for when to suggest translating the page via CX needs tweaking though. For example it shouldn't say "Add languages" when the page is not expected to be translated.

In T314620#8178403, @Nikerabbit wrote:

Since this button also includes the access to language settings, I think it should be shown on all pages. The logic for when to suggest translating the page via CX needs tweaking though. For example it shouldn't say "Add languages" when the page is not expected to be translated.

Thanks for bringing this point up @Nikerabbit. I had forgotten about the discussion I had with @Pginer-WMF (quite a while ago now) about maintaining a consistent entry point for the language settings. The main comment he wrote about that is here: T273144#6805993. He provided a mockup for how the language switcher should look in this case, with a reduced size:

@ovasileva given the criteria from the language team that the language switcher/tools should be available in a consistent place maybe this task should be more about reducing the size/appearance of the language switcher on pages that don't allow for translation? For example:

page that allows translation	page that doesn't allow translation

I assume we will encounter complexity with pages that already have an element in that space, for example:

recent changes	recent changes with reduced language button

updated talk page	updated talk page with reduced language button

In T314620#8175089, @Jdlrobson wrote:

@Iniquity what is the criteria for determining if a page can have languages in your opinion ? Is it a site configurable list of namespaces or something else?
In the case of https://ru.wikipedia.org/w/index.php?title=MediaWiki:Edittools it seems that there is nothing stopping me from linking to another language version of MediaWiki:Edittools for example in the software.

I think it should be divided into two categories:

1. Pages for which the button is needed for connectivity and as an input to the translator
2. Pages for which the button is needed only for connectivity

Only pages from the main space fall into the first category. In the second, all the rest, including special pages.

In the first category, you need to always display the button, because pages are translated using it. In the second category, you need to show the button only if there is at least one related element in another project.

Also, do not forget that if we turn on the button where it was not there before, then we need to connect the wikibase, for connectivity with sister projects.

In T314620#8179336, @Iniquity wrote:

I think it should be divided into two categories:

1. Pages for which the button is needed for connectivity and as an input to the translator
2. Pages for which the button is needed only for connectivity

There’s a third category: pages where neither of the above two applies, but we still need the button as an entry point for the ULS settings. For example most special pages and most or all talk pages. Actually, this is the case where the current positioning isn’t great: the language switcher was moved from the sidebar (chrome) to the page title, which makes it feel more part of the content—but when it only serves as an entry point for ULS settings, it isn’t part of the content! I don’t have any idea that both resolves this issue and keeps the entry point discoverable, though…

Only pages from the main space fall into the first category.

On Wikipedia. On other projects, it may be different: for example, on Wikisource, we probably don’t want to encourage users to translate works (main namespace) themselves, but we may want to encourage them to translate lists of works (Author namespace); and on multilingual projects like Commons or Meta, ContentTranslation doesn’t make any sense, so no namespaces fall into the first category.

In the second category, you need to show the button only if there is at least one related element in another project.

Otherwise the page falls into the third category, and you still need to show something.

@Nikerabbit, @Pginer-WMF - another way to remove the confusion is to set up a special case for these pages where languages are not available like in

In T314620#8193433, @ovasileva wrote:

@Nikerabbit, @Pginer-WMF - another way to remove the confusion is to set up a special case for these pages where languages are not available like in

. Is this still on the roadmap from the Language team's side?

If this seems a promising direction, I think that makes sense as a follow-up of the current work about entry empty states (T290436). I created a ticket to discuss the specifics in more detail: T316559: Communicate when pages are not supported in other languages in the current language selector

So utility wise: some pages support interwiki language links, but not via wikidata (e.g. user pages) ; so we probably shouldn't remove this there as it is the ONLY place that iw links show for those pages

Did anyone suggest to remove dropdowns that actually contain interlanguage links? I don’t think so; neither those on pages connected to Wikidata nor those on pages that aren’t, or cannot be, connected to Wikidata. The only question is what to do on pages where the dropdown contains no interlanguage links or other useful content.

Note this is a problem with old skins too e.g. Old Vector has a languages section in the sidebar on the very same page, it just happens to be less prominent UI than in Vector 2022 so we're only noticing it now.

From a technical point of view, perhaps the parser should play a role here. All pages in MediaWiki can technically have languages. It seems like there should be some kind of page property/meta data on articles saying that the page shouldn't have languages and perhaps a magic word DO_NOT_TRANSLATE that allows editors to signal this information on exceptions.

I had forgotten about the discussion I had with @Pginer-WMF (quite a while ago now) about maintaining a consistent entry point for the language settings.
@ovasileva given the criteria from the language team that the language switcher/tools should be available in a consistent place maybe this task should be more about reducing the size/appearance of the language switcher on pages that don't allow for translation?

FYI, there is task T319264 regarding a consistent location to access the interface language switcher.

In T314620#8177537, @ovasileva wrote:

Seems like our next step would be to define a list of namespaces that allows for translation. Maybe something like:

This list is not correct. Wikidata defines the dissalowed namespaces on https://www.wikidata.org/wiki/Wikidata:Notability . So, the actual list is

Main/Article - yes
any talk namespace - no
User - no
Wikipedia - yes
File - no
MediaWiki - no
Template - yes, excluding pages ending with ".css", or any subpages with "doc", "xml", "meta", "sandbox", "testcases" or "templatedata"
Help - yes
Category - yes
Portal - yes, but not subpages
Draft - no
TimedText - no
Module - no
translations - no
thread - no
topic - no

Well, looks like there is an opposite bug now - the language selector works in main space only.

I aded a note in T316559#8523433 trying to capture what is current and expected behaviour for different cases. If there are some other cases where behaviour needs to be adjusted, feel free to comment.