No problems.

No problems.

@Lydia_Pintscher This can be added too.

No problems.

No issues.

No problem whatsoever, feel free to add at any time.

Hi @UOzurumba! I'm here because of your message on no:Wikipedia:Notiser from earlier today.

I can not reproduce this at the moment – it shows in the expected language (Japanese, my user language and English) in all three examples from the description.

For anyone reading this, the reason this is not been merged or fixed is because of an unexpected problem with the CategoryTree extension (MediaWiki-extensions-CategoryTree); the patch above removes prefixes from category names in the normal category view, but when the CategoryTree extension is installed (as it is by default on all Wikimedia wikis), that extension "overrides" that and uses the prefixed category names. I have yet to find a solution to that.

Closing this since there has been no update. Feel free to reopen if it still happens and you can provide some more detail, @NPRB. :-)

Hi, I'm here regarding the change that was made on nowiki (presumably also on several other wikis) linking to this task.

@Patafisk Those are not directly related, no.

What does your user-config.py look like? (Remember to remove any confidential information if you paste it here.)

Interwiki links to external websites, like the [[google:]] interwiki link, are handled by the Interwiki map on Meta. The right place to ask for this (if it is still wanted) is at its talk page.

This could be solved with a Javascript that is loaded from those wikis' MediaWiki:Common.js. Stewards (and maybe also global interface administrators) can still edit those wikis to add that. I could have a go at creating a script to do this this weekend.

(Removing the visual editor project tags, since this was an on-wiki Javascript issue not really related to any of those projects.)

Should be fixed with this edit. That page has a lot of unnecessary stuff, and was created by a user I am pretty certain doesn't know any Javascript – meaning it was just copypasted from somewhere else. I think the vast majority of the stuff in there is not used at all by the Khowar Wikipedia in the Incubator, so it may be best to just delete it entirely.

It has been done now – all categories with lowercase initials were moved to uppercase, and all articles within them have been moved to the new categories.

It works like it should for me in the Incubator. Tested in both Firefox and Edge (on Ubuntu).

Fixed with this edit. Thank you very much to @Samwilson for helping to find a solution!

Where do you see this? For me, it is already at the bottom.

@Zblace Sorry for the lack of reply! I think the solution of using a different language tag in the HTML and for the subdomain should work, but there are a few technical hurdles in the way that I am not sure how to solve. I don't think there is any rush in fixing this for the time being though, it would be more of an issue once the Wikivoyage is approved.

@Nikerabbit Sounds good to me, yeah.

I can help to fix those automatically with my bot, that will only take me a few minutes.

It's a feature, not a bug. :-)

You can test it here: https://incubator.m.wikimedia.beta.wmflabs.org/wiki/Wp/tg/T302200
It seems to be working as it should now (compare with a Tajik page on the actual Incubator, like e.g. https://incubator.m.wikimedia.org/wiki/Wq/tg/%D0%91%D0%BE%D0%B1%D0%BE%D2%B7%D0%BE%D0%BD_%D2%92%D0%B0%D1%84%D1%83%D1%80%D0%BE%D0%B2 ).

@Bennylin Hi! A page isn't counted (for the sake of statistics in Special:Statistics and {{NUMBEROFARTICLES}}) until it has at least one [[internal link]], see https://www.mediawiki.org/wiki/Manual:Article_count . All the pages that were in the Incubator have been imported (you can verify it in Special:AllPages), but most of them don't seem to meet this criteria of having at least one link. I would suggest the community works on this, as internal links are a big part of what makes wikis wikis. :-)

In T319052#8481650, @TheDJ wrote:

I'm not against fixing legacy vector and monobook in this ticket as well, but I do think those should be separate patches.

That looks good in Vector-2022, but the titles are still overflowing in Vector and Monobook:

• https://patchdemo.wmflabs.org/wikis/d7e4e189a6/wiki/AS1f000S11a20S19220S1ce20S1ce20S19220S1fb20S11502M518x603S1f000483x398S11a20497x417S19220497x451S1ce20496x474S1ce20496x508S19220497x542S1fb20497x565S11502482x588?useskin=vector
• https://patchdemo.wmflabs.org/wikis/d7e4e189a6/wiki/AS1f000S11a20S19220S1ce20S1ce20S19220S1fb20S11502M518x603S1f000483x398S11a20497x417S19220497x451S1ce20496x474S1ce20496x508S19220497x542S1fb20497x565S11502482x588?useskin=monobook

The task this was closed as a duplicate of is (now) specifically about tables with alternating colors, which doesn't match this bug. The other task mentioned there, T284327, is about other types of tables, which also doesn't match this. Thus reopening; please feel free to close it again if there is another more suitable task specifically for images with transparent backgrounds.

I haven't made any changes to it, and it's the standard version (version number is in the task). The device is a Nokia X20, Android 12.

Just pressed the picture itself, and this comes up:

… and it has been fixed. :-)

Not only in Mobile Frontend, it happens in Vector-2022 too:

Yeah, sorry, I tested making this change and forgot to change it back. That would be a workaround to solve the issue temporarily for this specific case, but it's a hack.

BTW, this is most noticeable with the watchlist (because that's the most used one, I suppose), but it also happens for the other accesskeys in the personal tools menu: . for going to your userpage, n for your user talk, and y for your contributions page, Not very surprising, but good to kind in mind nonetheless.

Oops, that's on me. I must have pasted in the wrong thing when changing the message a while back.

That's what I suspected too, but I looked for a long time without finding anything. I was able to replicate the issue in my sandbox in enwiki, I will update the task to reflect what I've found.

It seems that the problem appears when the template {{filmlenker}} is followed by {{autoritetsdata}} (even with intermediate line breaks) and {{autoritetsdata}} outputs empty content (or only a category, in this case). If you enter some text between them, the categories show up again. Additionally, the {{autoritetsdata}} template is not displayed in VE at all when it is empty.

@Aklapper I'm not quite sure about the tags used for this task, I would be grateful if you could take a look at them.

The reason it only focuses is that there are three elements with the same accesskey on the page, as evidenced by doing $( '[accesskey=l]' ); in the browser console: One is the button that is visible at the top of the page, while the two others are present, but always hidden (presumably because there is a button). The second one is within the p-personal menu (the one in the header), while the third one is within p-personal-sticky-header (the one in the sticky header).

Thank you @santhosh!