We did have some conversations around adding it to other namespaces, but I think for now the expectation is to only display it on the namespaces it appeared before (main, Wikipedia, etc)

The ULS cog currently shows on /all/ pages. This means that the language button shows on all pages.

One possible solution is to disable the cog for now on modern Vector Probably best to do this in ULS but open to ideas on the best approach here. (this is if we still need to retain the status quo for legacy vector.)

Alternatively: we could disable the cog on legacy vector by changing the value of $wgULSPosition

@Rileych @Nikerabbit Hello! The web team is curious to understand the decision to show the ULS cog on all pages. On the longer term we have discussed with Pau about showing the cog inside the UniversalLanguageSelector dialog (like on Wikimedia Commons), but this would mean losing access to that cog on those pages. If that happened what would the impact of that decision be?

On the short term, we are curious about how we should go about moving the cog into the diaog for the in-development version of Vector without breaking compatibility with the existing interface. Do you have any recommendations there on how you would like to see that happen?

Note: we have a meeting next week, but ideally we'd like to talk about instrumentation there, so if this is something we could discuss asynchronously that would be ideal. No worries if not. cc @LGoto

Update: On https://en.wikipedia.beta.wmflabs.org/wiki/Selenium_Echo_link_test_0.37656252268998536 it seems the language label /changes/ and the cog is inaccessible at time of writing despite being displayed.

@Jdlrobson (cc @LGoto )

I touched base with @Nikerabbit and our initial thoughts are that we need to continue to allow users to access to language settings on every page. We will circle back with a more thoughtful answer in the next few business days. @Pginer-WMF for visibility.

We are supporting different language settings, and I think it makes sense to provide consistent entry points for them, surfacing the options that are relevant in each moment. For users interested in changing the UI language it does not make much sense that such option disappears in certain pages. For example, someone reaching RecentChanges page by following a link may need to change the UI language and not finding such option where they are used to can be confusing.

I think the ideal solution would meet the following criteria:

• Unified entry point. Language options are provided closer to each other. In this way users think of such area as the place to adjust language-related stuff.
• Priority to content language. The main usecase seems to be switching content language, so it makes sense to be the most prominent option.
• Access to additional options secondary but consistently available. Even when there is no content to switch it may make sense to still provide access to other language-related options that may apply.

I sketched some ideas on how the selector can be adapted to different circumstances below.

For the last case (special pages) maybe we can also explore to reverse the concepts, making the main entry point about options and access to language settings being one of them. Provided that there are other options that make sense for the list and that we verify that keeping the location consistent is enough for users to still find them:

@Pginer-WMF thanks for the information and mockups.

Backing up a little as I'm still new to all of this: currently the interlanguage links (to switch from one Wikipedia to another) and the language settings (to switch interface and/or input languages), are presented together within the "Language" area in the sidebar. Before discussing what to do going forward I wonder if it might be useful to question whether these two functions should remain coupled together? I of course see how they are related: both deal with language and I imagine both serve multi-lingual people. But from the perspective of frequency of use, and expertise required to understand them, they also seem potentially very different. I don't know much about switching interface/input languages but it seems like a relatively advanced feature and I would assume it doesn't get used anywhere near as frequently as interlanguage links (see T273986). While the interlanguage links were in the sidebar I don't think it mattered much to have this additional functionality as part of it, but since we're moving the interlanguage links to a much more central location I think it matters more (particularly when we get into this conversation about what to do for pages that will never have interlanguage links).

If we do feel like it's important to keep these two functions in one place I think doing something like you proposed here @Pginer-WMF makes sense since it maintains more consistency than just having a gear icon:

To drop the language icon and go only with the gear icon could be misleading seeing as some special pages already have settings menus. And I'm not sure that the consistency of the location (if sometimes it had a language icon, and sometimes a gear icon) would be enough to help people remember what's underneath that button. But again, just to echo the above, I question whether that functionality is worthy of such a prominent location.

[...] I wonder if it might be useful to question whether these two functions should remain coupled together? I of course see how they are related: both deal with language and I imagine both serve multi-lingual people. But from the perspective of frequency of use, and expertise required to understand them, they also seem potentially very different. I don't know much about switching interface/input languages but it seems like a relatively advanced feature and I would assume it doesn't get used anywhere near as frequently as interlanguage links (see T273986). While the interlanguage links were in the sidebar I don't think it mattered much to have this additional functionality as part of it, but since we're moving the interlanguage links to a much more central location I think it matters more (particularly when we get into this conversation about what to do for pages that will never have interlanguage links).

I think your analysis is correct. I'd add a couple additional considerations:

• People don't have a clear distinction of what is content and what is the UI. By default people expect everything to change: they want to access the content in a different language, and once they noticed that the UI also changed a small subset may realize they have a different preference for the UI. Having the UI option disconnected from the main language switch (which changes content + UI by default) has a risks that may be worth checking: A reader may find the UI switch and think that's the main language switch mechanism, resulting in confusion about why the content language is not changing.
• People that need to change the UI language, may be navigating a UI in a language they don't know. For example, checking recent changes in Korean you may want to know how many edits from a certain tool may have problems even if you don't know the language. In order to do that, you need to be able to find your way to change the UI language using a UI in a language you don't understand (I illustrated the example below). This may be a bit of an edge case mainly for maintenance tasks that some advanced editors do across languages (posting a message into another wiki's village pump, updating the image used across languages to a better version, etc.).

@Pginer-WMF - we discussed next steps a bit further yesterday with @alexhollender and @Jdlrobson. I think the main question we're facing right now is whether we want to tie language settings to the language button, with the secondary question on whether we would like to have the language button appear on special pages. I wonder if we can postpone this conversation until the new version of the ULS is ready, as it will incorporate language settings within it. This would mean that for the short term, we will have the following for the new version of vector:

• No settings cog on special pages and action urls
• Language button only appears on the main namespace
• We can add the list of languages to the main page, similar to the way we do this on mobile (https://en.m.wikipedia.org/wiki/Main_Page)

Would this be okay with you in the short term? It would be only for the new version of vector, which will be default on: frwiki, hewiki, euwiki, fawiki, ptwiki, kowiki, trwiki, ptwikiversity, and frwiktionary.

Would this be okay with you in the short term? It would be only for the new version of vector, which will be default on: frwiki, hewiki, euwiki, fawiki, ptwiki, kowiki, trwiki, ptwikiversity, and frwiktionary.

Sounds good. Thanks for the update, @ovasileva.

I believe these changes are related to the disappearance of interlang and interwiki links when an article is edited ($action !== 'view') with the WikiEditor (2010). Can you confirm or disconfirm?