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.

I think this can be closed since the above-mentioned patch was merged (and is now live). Further improvements should come with T395997.

I don't like doing this, but it's been 5 years since this bug was reported and it's still happening. Any chance of prioritizing fixing it?

Suggested wording:

I think this can be closed. The most pragmatic way of solving the other issue I mentioned in my previous comment 3 years ago is by creating MessagesXx.php files with $dir (or whatever) info as needed.

In T406165#11329286, @matmarex wrote:

This should avoid @Tacsipacsi's concerns about changing the messages, and still fix the issue.

I got the same warning in a gadget I just made, where I had followed the examples for CdxPopover of setting :anchor="currentTrigger" and initialising currentTrigger to ref( null ).

This happened when I tried to create https://no.wikipedia.org/w/index.php?title=MediaWiki:Gadget-quickBlock/Main.vue&action=submit . I also tried creating it with just the boilerplate content instead of what I was actually adding, with the same result. I also tried creating it as a .js page, then moving it to the .vue name and changing the content model, and it failed with the same error at that last step.

As far as I know, $wgExtensionMessagesFiles still exists because it supports three things: namespace translations, special page name translations (aliases), and magic word translations.

In T345737#9229575, @Ammarpad wrote:

This task (just like T196861) is also duplicate of T164357 (which is the oldest task).

Not a duplicate of that task. But I can't reproduce either.

No, I think that's it for now, I haven't identified any other obvious candidates for improvement in this area.

Thanks!

Thanks for the review, @Lucas_Werkmeister_WMDE! Should I just close this task now, or should we wait for deployment and/or testing?

In T389939#11286968, @Jdlrobson-WMF wrote:

Perhaps this could be resolved by a new uselang subpage e.g. Special:MyLanguage/uselang/{pagename} ?

In T63547#11288257, @Bugreporter2 wrote:

Would you consider doing the same for Special:TalkPage/ ? I added a feature request for this somewhere...

In T396286#11288453, @Tacsipacsi wrote:

In T396286#11288450, @Zolgoyo wrote:

a separate Wikipedia is not possible, we don't have a separate language code.

You do have a separate language code: crh-ro counts as a language code.

Boldly setting to UBN! because of the consequences of this bug (missing references on thousands of pages across wikis – for the Norwegian Bokmål Wikipedia's case, it's in the order of hundreds of thousands of pages; no idea about the Hungarian Wikipedia).

Note: This edit fixes the issue for the most commonly used module that fetches references in the Norwegian Bokmål Wikipedia. However, that's just one module on one wiki – who knows how many other things are impacted by this?

In T406114#11246826, @Esanders wrote:

@Krinkle Could we allow the skin to specify a default scroll-padding-top and then render that really early (e.g. an inline <style> tag in the <head>)?

Sorry, I think I misunderstood the problem here. They're similar, but not the same.

The README in the MWStake repo says "If the skin is no longer supported and does not work with any supported version of MediaWiki, it should be removed. ". Since DarkVector's last update (at least according to it's MW skin page) was in November 2022, just before the release of 1.39 LTS (which is EOL this December), it presumably works with that version, but I'm not sure how to properly check for the newer supported versions.

I'd like you to reconsider this, if that's okay.

GitHub patch that adds notheme skin-invert to the ULS menu element as a stop-gap measure until the ULS rewrite happens: https://github.com/wikimedia/jquery.uls/pull/526

GitHub patch that adds notheme skin-invert to the ULS menu element as a stop-gap measure until the ULS rewrite happens: https://github.com/wikimedia/jquery.uls/pull/526

GitHub patch that adds notheme skin-invert to the IME selector as a stop-gap measure until the ULS rewrite happens: https://github.com/wikimedia/jquery.ime/pull/842

Abandoned the now-stale patches, since there is a ULS rewrite on the steps – better to wait for that, I think.