We may like to make it a thing where a user, via a new fourth and fifth option, can select what gender they would not like the software to refer to them as. For example, the options presented by MediaWiki:Yourgender (which hopefully does become the new standard) would be as follows:

• Unspecified: Use gender-neutral terms when possible (e.g. "their contributions") (default)
• Use feminine terms when possible (e.g. "her contributions")
• Use masculine terms when possible (e.g. "his contributions")
• Do not use feminine terms (e.g. "their contributions") (for languages where the gender neutral is impossible, masculine forms may be used)
• Do not use masculine terms (e.g. "their contributions") (for languages where the gender neutral is impossible, feminine forms may be used)

With the implementation of T242184, this task has been made fundamentally obsolete. I have therefore closed it as resolved.

This is probably happening on the Cargo side. The same thing happened when I tried to store ref tags:
Legislation:British Library Act 1972 S.1 (GBR)

The badge for "WMF Cloud Services" which links here has been present at some point since this task has been opened.

In T6845#6782018, @sbassett wrote:

In T6845#6781431, @MJL wrote:

@sbassett Why haven't audio captchas just been used as a stop-gap measure for the largest language projects? That part just doesn't make sense to me.

Without leveraging a large commercial product (reCaptcha, hCaptcha, etc.) or finding a robust FLOSS alternative (which doesn't really exist at the moment AFAIK), this would likely be a large and complex project, especially given the existing issues around prioritization and ownership of Wikimedia's current captcha system at the WMF. I don't really mean this as an excuse, but more as a qualifying statement on the reality of the current situation.

@sbassett Why haven't audio captchas just been used as a stop-gap measure for the largest language projects? That part just doesn't make sense to me.

In T212313#6611889, @Amire80 wrote:

If MediaWiki messages can be different in a way that can't be covered by en (or en-gb), then we can have it as a user interface language similarly to en-gb, en-ca, etc., and if I'm not mistaken, this will automatically apply also to monolingual codes.

I would prefer to see that outcome in all honesty. Indian English has millions of speakers worldwide and is much more popular than British or Canadian English. I never really understood why users shouldn't be allowed to use it for their interface language setting.

Do you have a link to the onwiki discussion where there was consensus for this user right?

In T212313#6611541, @Amire80 wrote:

Are there any examples of where the values in "English" and in "Indian English" would be different?

This would be extremely nice if wikis were able to configure the magic links in order to create their own use-cases for them if so desired. For example, WikiLaw could use that extension to automatically generate links in citations to different legal codes.

In T266427#6594117, @Daimona wrote:

Aside from this, is there any remaining bug to cover in this specific task?

Can you please provide detailed reproduction steps? It works as expected for me if I:

• Go to Special:AbuseFilter/test
• Insert "old_size === 0" as rule
• Submit the form
• Verify that it matches Special:RecentChanges

In T266427#6579501, @Daimona wrote:

It would help to know what version of MediaWiki you're talking about. The same exact issue you're mentioning was fixed a few weeks ago with rEABF2e13d58c748974b37e95109de031acb8f4c78180. I'm also correctly seeing page creations on itwiki.

Oh, got it! Sorry about that!!

Couldn't we just use qdw (query data wiki) like how Translatewiki.net uses qqq? It seems like the pretty obvious solution to this to me.. It'll also provide an end-run around T140131.

I made this task on a whim without any expectation that people would actually review it. I can't believe there's a chance it might get implemented! [0_0]

In T255080#6213170, @Reedy wrote:

Making Special:Preferences take a string for pronoun is pretty easy; no DB schema changes would be needed

How we should then support them in {{GENDER: then seems potentially harder...

Also, what about the templates? Should I just import all those which don't exist on scowiki and you will figure out the rest?

A user on enwiki was blocked over this issue a while back. I'm declining this task since there doesn't seem to be consensus that custom timestamps are valid signature options.

In T247172#5951828, @Bugreporter wrote:

• If wikt:sco: could target to w:sco:define: that'd be nice.

It is possible using way similar to https://gerrit.wikimedia.org/r/#/c/operations/puppet/+/393289/, but you should decide whether:

• All wikt:sco: pages redirects to same sco: page (e.g. https://sco.wiktionary.org/wiki/test -> https://sco.wikipedia.org/wiki/Define:Main Page) - "funnel"
• All wikt:sco: pages redirects to correspending sco: page (e.g. https://sco.wiktionary.org/wiki/test -> https://sco.wikipedia.org/wiki/Define:test) - "rewrite"

In T247172#5951830, @Bugreporter wrote:

Should we also set $wgCapitalLinkOverrides? Note it is not currently set in any wikis with a "word" namespace (currently alswiki, barwiki, pflwiki). cf T173668

I came across this enwiki citation, and I wanted to share. I guess it happens there, too.

In T245708#5899926, @DannyS712 wrote:

Should just be added to Sagittarius+/Capricorn regex

I have to say, I only filed this because I have never used Capricorn. For the most part, I've always had a custom implementation of Sagittarius + that later became Archer. I don't know if that could be fixed or not, though?

@Paladox Do you want me to commit the change or do you want to take care of this yourself?

In T37704#5833304, @Jdlrobson wrote:

3. They encourage UI inconsistency across the site e.g. blue buttons and yellow buttons and green buttons!)

Please bring back green buttons. Thanks, T110555.

In T49544#5834946, @thiemowmde wrote:

There is a number of tools, gadgets, user script, and whatnot that work with references. If any of these contains a selector that requires the element name span, this tool is going to break without notice.

Ah, well then I'll just remove myself then. :/

@Dcljr Oh, well then would this be a patch-welcome then?

@Alex_brollo I am independently able to confirm that Author: pages are indeed considered namespace 0. See File:Capture-Author.png.

@Xover I'm not a coder, but I'm willing to spend some time looking at things. I'll see if I can at least isolate the problem for why this bug occurred, then that should expedite the solution hopefully. We'll see what happens.