Change 896419 had a related patch set uploaded (by Samtar; author: Samtar):

[mediawiki/extensions/CentralAuth@master] SpecialContributionsHookHandler.php: Add ContributionsToolLinksHook

https://gerrit.wikimedia.org/r/896419

Change 898812 had a related patch set uploaded (by Majavah; author: Majavah):

[mediawiki/extensions/CentralAuth@master] SpecialCentralAuth: add pointer towards lock logs on meta

https://gerrit.wikimedia.org/r/898812

Change 898813 had a related patch set uploaded (by Majavah; author: Majavah):

[mediawiki/extensions/WikimediaMessages@master] Add override for centralauth-admin-log-otherwiki

https://gerrit.wikimedia.org/r/898813

Change 896419 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] SpecialContributionsHookHandler.php: Add ContributionsToolLinksHook

https://gerrit.wikimedia.org/r/896419

Change 898812 merged by jenkins-bot:

[mediawiki/extensions/CentralAuth@master] SpecialCentralAuth: add pointer towards lock logs on meta

https://gerrit.wikimedia.org/r/898812

Tagging User-notice as this change is:

• a completion of a CWS proposal
• may conflict with some user scripts which already add the CentralAuth link (imho, this "conflict" will be "two links appear")

I have already added a draft of this to Tech News 2023/12

Change 898813 merged by jenkins-bot:

[mediawiki/extensions/WikimediaMessages@master] Add override for centralauth-admin-log-otherwiki

https://gerrit.wikimedia.org/r/898813

The new link looks odd because all other links in the tool use lowercase form, including those added by extensions like Abuse Filter and Nuke. Not sure why Central Auth didn't follow that

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.

Hi! Thanks for adding the link to CentralAuth, however, this isn't really an useful change for me (and believe some other stewards too), as we we only should make global account operations from Meta, to facilitate central logging.

Unfortunately, this change forces me to hide the added centralauth link, to avoid from accidentally accessing centralauth on the wrong wiki and accidentally locking there (I've done that before). This is not ideal, because AFAICS the only way to hide the link in full relies on the link's relative position in the tool menu, which is not a good long-term solution (I can target mw-contributions-link-centralauth via CSS, but that leaves a dangling pipe in there; the parent span has no class/ID to target).

I've read through the discussion on the patch, and the main concern seems to be language switching. In my opinion, this can be reasonably resolved via ?uselang=XXX, where XXX is user's current language. Granted, it'll only work for whenever the user clicks the link (and not if they navigate to somewhere else on Meta, or a different wiki), but I think that's good enough?

CC @taavi @TheresNoTime @Legoktm @Tgr @Zabe who discussed this topic on the patch.

In T331743#8727913, @Urbanecm wrote:

Hi! Thanks for adding the link to CentralAuth, however, this isn't really an useful change for me (and believe some other stewards too), as we we only should make global account operations from Meta, to facilitate central logging.

Unfortunately, this change forces me to hide the added centralauth link, to avoid from accidentally accessing centralauth on the wrong wiki and accidentally locking there (I've done that before). This is not ideal, because AFAICS the only way to hide the link in full relies on the link's relative position in the tool menu, which is not a good long-term solution (I can target mw-contributions-link-centralauth via CSS, but that leaves a dangling pipe in there; the parent span has no class/ID to target).

I've read through the discussion on the patch, and the main concern seems to be language switching. In my opinion, this can be reasonably resolved via ?uselang=XXX, where XXX is user's current language. Granted, it'll only work for whenever the user clicks the link (and not if they navigate to somewhere else on Meta, or a different wiki), but I think that's good enough?

CC @Majavah @TheresNoTime @Legoktm @Tgr @Zabe who discussed this topic on the patch.

For your specific usecase, I'd recommend User:Tks4Fish/CARedirect.js.

In T331743#8728101, @TheresNoTime wrote:

For your specific usecase, I'd recommend User:Tks4Fish/CARedirect.js.

Thanks for the advice. I've CAWhoisProxy.js by Tks4Fish installed, which provides a CA link that goes to meta, so I just ended up disabling the link added by MediaWiki. I find it more convenient than always hopping through a JS redirect.

In T331743#8727913, @Urbanecm wrote:

I can target mw-contributions-link-centralauth via CSS, but that leaves a dangling pipe in there; the parent span has no class/ID to target

Ideally we'd get rid of the spans, and just use a list of <a>s with display:list-item or some such. Less ideally, you can use span:has(> .mw-contributions-link-centralauth) (as long as you aren't using Firefox).