In T332341#8724621, @matej_suchanek wrote:

The right page to report is fr:Vodava; https://fr.wikipedia.org/wiki/Vodava

I disagree. How do you know the page will have that title?

It's not possible to programmatically know what the exact title would be in any foreign wiki.
The next best thing is to assume the title would be the same as the title of the originating page linked to current data item. If you've a better suggestion, that would be good.

Additionally, I agree with this comment, I think 'global account info' would have been better. "CentralAuth" is cryptic to average user. It seems very developer-centric and is quite hard or even impossible to properly translate in many languages.

It has been fixed in 1.40 (851694), but not in older releases.

Previous tasks T17088: Categories should not be able to include themselves, T37221: Categories can contain themselves, T22379: A category has been categorised to itself

@phuedx, my comment was added over 2 years ago, so it's not surprising the issue has been fixed in the meantime. I was using Google Chrome at the time I uploaded the above screenshot. It's fixed now in Vector, but yes, it's still an issue for Vector-2022

[{{fullurl:An Article|action=render}} Render] wikitext make an external link, and It seems to be harmful in some context to readers

You can remove the external link symbol, otherwise the link has no difference with the supposed internal link

Hi @Bovlb, it's been 3 years and I'm not sure if I can remember what happened there. However, I boldly tested the link now on Wikidata and it was correctly rejected by the spamfilter.

Thanks @matmarex.

It works for me. Query: https://w.wiki/6P8Q Result: https://w.wiki/6P8S.

The incorrect argument was introduced from this change 908e387e3618.

The notice is correctly centered in Minerva, and other notices look fine. For this particular notice, it comes with inline styles (metawiki) which are overriding Minerva styles.

I guess this is already done at some point? cf. T329957#8625589

You can add comment (if that's necessary) on the patch here https://gerrit.wikimedia.org/r/c/phabricator/extensions/+/236417

The error means you do not have access to do that. Why do you want edit it?

In T329367#8607170, @matej_suchanek wrote:

It does not display on https://en.wikipedia.beta.wmflabs.org/wiki/Special:Contributions?safemode=1, so it seems to be some local customization.

This seems to be working as intended. Navigating to ?action=edit signifies clear intention to edit, irrespective of what follows that.

Seems to be caused by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/882208

Done in af2c58278921

Is this actionable? It seems all the patches, save one, have been merged.

Closing since it's intended behavior

If there is a section #mw-pageinfo-linter within &action=info then link that headline aut idem to the related Special:LintErrors?pagename= page.

The section header is generated in core and is always text; currently there's no way for Linter to change it to a link server-side.

In T328745#8586316, @Cabayi wrote:

Thanks Ammarpad. That sorted it.
It worked once we also created https://arbcom-en.wikipedia.org/wiki/MediaWiki:Editnotice-0

I hope you understand that's a namespace-level notice, so it will appear on all pages in namespace 0. (Task description shows you probably want it for https://arbcom-en.wikipedia.org/wiki/Appeals/2023 only)

A lot of reference is given to (what appears) enwiki here; please note that editnotice system is heavily customized on enwiki and now is quite different (for the user) from the core actual design.

(For code review)

Expected: Return to the first URL as it does on desktop.

Maybe it used to? I think it no longer does

These files are missing on disc (or have archived versions that are) and so cannot be deleted (since the deletion code requires a file to exist first). From the code, it seems it's already known that some files are irretrievably lost on Wikimedia servers; for instance in code comment shown T244567#6518947 which is still in source. That's the first problem.

To make the query work in Postgres will require DISTINCT ON expression (instead of DISTINCT) which SelectQueryBuilder does not seem to support. Alternately, I think you need to grab all the simple select result and manually filter unique values.

In T327661#8555923, @Tgr wrote:

Did this start happening recently? It seems to be caused by the core signup styles but those haven't change for a long time.

No idea. I was about to say I used to see the form centered, but maybe all I was seeing was Special:Login and not Special:CreateAccount. The latter is of course very rarely-used page (by existing editors).

I'm not sure what "the box below" is supposed to refer to

Here's the box (below the text). I think it's VE here that should reword the text since it's repositioning the message which makes it to lose context.

Enwiki modified the core message mw:MediaWiki:Emailsenttext, with a parameter it does not support.

The above is true. Inversion only works when you select a namespace. Inversion for 'all' will mean showing nothing, which does not make sense.

I did mention that I used 'preview' link in my comment, I didn't come across the banner normally. So given this explanation by @Pcoombe, I think there's no device targeting bug with CN here.

In T310679#8007917, @Jdlrobson wrote:

Per https://phabricator.wikimedia.org/T242195#5786788 the real issue here is these links should not be using this class. The red link is used for pages that don't exist. The contributions page does exist and shouldnt be red just because the user page link doesn't.

This was supposed to be fixed by T242195. It probably regressed.

This has been fixed in r802816.

Please let's follow T267921: Roll out the Toolbox link for URL Shortener in Wikimedia sites for enabling the feature on Wikimedia prod wikis since it already exists.

This is already available in the extension. It's purposely disabled on Wikimedia wikis

You should use the beta https://codesearch-beta.wmcloud.org/ which has that feature and a lot more.