This is not the same issue. Related, but different.

@satdeep_gill, @Aafi, @Khaatir: Could you provide translations for this namespace?

(Stalled on missing translations)

Hi all, Incubator extension maintainer here.

I didn't notice this task until today, when T405555 was completed, which I guess is a subset of this task.

Ah, thanks! Didn't find it before, guess I searched for the "wrong" thing.

Quick-and-dirty screenshots of what my above comment could look like:

In T414468#11643713, @Nikerabbit wrote:

My thoughts: put the language name first (translated if available) followed by the language code. A small dash or dot as a separator would ad minimal clutter. Parenthesis are already used in many language names so maybe those could be avoided. This likely works well for multiselect and no-JS select. Use this as default everywhere. Code provides way to override this default if needed.

Cannot reproduce, I think we can safely assume this was solved somehow in the 12 years that have passed since this was reported.

The discussion was started today, so we should wait for ~7 days before implementing.

I don't think PageImages being under code stewardship (T252249) means it can't be deployed to other wikis, it just means no new feature requests will be accepted at the moment. After all, it is enabled by default for almost all wikis (except Wikibooks and Wikisource), so enabling it for hewikisource should be unproblematic, as I understand it.

In T370943#11498325, @Jdlrobson-WMF wrote:

This looks like it's been fixed by the moderator tools team with their work in T402297 (or this patch merged by Bernard). Can be QAed in production and on https://en.wikipedia.beta.wmcloud.org/w/index.php?title=Polar_bear&diff=664870&oldid=664780&minervanightmode=1

See also T415679: MultiselectLookup hijacks Enter presses inside forms, which might be considered a blocker for implementing MultiselectLookupLanguageSelector adaptation.

I'm not sure how an empty header (with just a space in it) is preferrable to no header. Functionally, there isn't really a difference between what happens when that header is removed, and what happens on normal wikitext pages, which typically have an intro section before the first (sub)header. An alternative approach would be to hide the empty header with CSS, but I prefer just removing it from the output instead.

How about something like this? Quick mockup made in browser developer tools.

Great, thanks for checking! Closing this then.

@Mdktb: Ah, thanks for letting me know! It was a stupid mistake, should be fixed now with this edit. I had used null, which means "reset to the default setting", but since the gadget was on by default, it would effectively switch it on and not off. You might need to do a hard refresh (Ctrl+F5) to get the new version; please test and let me know if it works for you now.

I don't really know which project to tag this with, so just adding some that might be relevant. Feel free to adjust as needed!

FYI, I was able to create the page, with the Vue content model, a couple days after this task was filed: https://no.wikipedia.org/w/index.php?title=MediaWiki:Gadget-quickBlock/Main.vue&action=history

Ah, I didn't know that (hadn't tried). Sure, absolutely no rush in fixing this in the frontend, especially if it already kinda works as expected.

Great! Thanks for reviewing and checking. :-)

All done 👍

@Sneha This is what it looks like in my localhost wiki when I scroll down on a long page, and then refresh. Using the current master branch of the Vector skin repo.

On the suggestion of @Nikki, I went with the approach of creating a gadget (planned to be default on for everyone). It uses three MediaWiki messages, which were just merged, so the gadget can be deployed after next week's train arrives. Gadget code: JavaScript, Vue. The banner will only be shown if a user has set a test wiki language in their preferences, and that language is available as an interface language, and the user uses a different interface language. If the user clicks the "close" button in the banner, the gadget will disable itself (can be re-enabled again in preferences).

Closing since the patch mentioned above was merged and deployed.