You can use {{NAMESPACENUMBER}} to avoid gender distinction or namespace renames when comparing things in wikitext

The regression has happen in https://gerrit.wikimedia.org/r/c/mediawiki/core/+/819148

The old code for the parser variable was using Language::getNsText which does no gender distinct, the new code is using Title::getNsText, which does

You can use {{NAMESPACENUMBER}} to avoid gender distinction or namespace renames when comparing things in wikitext

Of course I could, but it doesn't make it better -- either way there is need to find and edit all the occurences. Better to fix the bug.

13049 pages to check in ruwiki, it's impossible.

German and Portguese wikis have an exhaustive gender distinction as well, and it is widely used to address accounts in a proper way.

I am afraid the old behaviour is to be produced with previous function calls, otherwise we get trouble with our wives.

However, I cannot find any difference in German Wikipedia; everything fine and as expected and as before.

tl;dr: It's not clear this is a bug and not a bug /fix/. Apparently {{NAMESPACE}} was returning the wrong gender for female users' pages "for ever", and we (inadvertently? finally?) fixed it.

Details:

Before https://gerrit.wikimedia.org/r/c/mediawiki/core/+/819148 {{NAMESPACE}} gave a different result from {{NAMESPACE:{{PAGENAME}}}}. But in general it is expected that magic words without an argument use "the current page" as the default argument; cf {{{PAGESIZE}}, {{REVISIONYEAR}}, etc. So it is "expected" that {{NAMESPACE}} gives the namespace of the current page. If the current page belongs to a female user, then the namespace of the current page will be gendered to match.

{{NAMESPACE:{{PAGENAME}} always gave the proper gendered namespace, so this isn't "new".

We could special-case the "zero-arguments" form of {{NAMESPACE}}, so that it behaves differently than {{PAGENAME}}, {{PAGENAMEE}}, {{FULLPAGENAME}}, {{FULLPAGENAMEE}}, {{SUBPAGENAME}}, {{SUBPAGENAMEE}}, {{ROOTPAGENAME}}, {{ROOTPAGENAMEE}}, {{BASEPAGENAME}}, {{BASEPAGENAMEE}}, {{TALKPAGENAME}}, {{TALKPAGENAMEE}}, {{SUBJECTPAGENAME}}, {{SUBJECTPAGENAMEE}}, {{PAGEID}}, {{REVISIONDAY}}, {{REVISIONDAY2}}, {{REVISIONMONTH}}, {{REVISIONMONTH1}}, {{REVISIONYEAR}}, {{REVISIONTIMESTAMP}}, {{NAMESPACENUMBER}}, {{TALKSPACE}}, {{TALKSPACEE}}, {{SUBJECTSPACE}}, {{SUBJECTSPACEE}}, and {{CASCADINGSOURCES}}, all of which use {{PAGENAME}} as the first argument in their zero-argument form. But I'd rather not add a special case: why would you want to deliberately use the "wrong" gender for the current page? The fact that German wiki (at least) doesn't display any regression here seems to indicate to me that they stumbled across this bug some time ago and must have deliberately used {{NAMESPACE:{{PAGENAME}}}} in order to ensure that the namespace was properly gendered, a workaround which shouldn't be necessary. As state, if you're comparing based on page name it is expected that you use {{NAMESPACENUMBER}}.

If you *do* want the zero-argument form to be gender-neutral, for some reason, should {{NAMESPACEE}} behave the same way?

(See also T314077.)

@IKhitron: could you describe further what you meant by:

For now I've edited some system messages from "...|draft|user|..." to "...|draft|user|female user|...", but I hope it will be fixed.

Seeing the specific templates and/or messages involved would help; we could also suggest ways of either fixing the templates, adding specific cases to Extension:Linter, or otherwise automating update of affected wikitext.

In T320894#8323060, @cscott wrote:

@IKhitron: could you describe further what you meant by:

For now I've edited some system messages from "...|draft|user|..." to "...|draft|user|female user|...", but I hope it will be fixed.

Yap. Here you are. Do you need me to translate it?

Seeing the specific templates and/or messages involved would help; we could also suggest ways of either fixing the templates, adding specific cases to Extension:Linter, or otherwise automating update of affected wikitext.

Please don't. As I said more than once, it's tens of thousands of pages. The only fix here is to return the magic word to the status-quo.

(History: {{NAMESPACE}} as a parser function called Title::getNsText() from the very start when it was added in 2009 a01e8619681f7612ff56be1e1c4931391bf9902c, which was https://github.com/wikimedia/mediawiki/blob/a01e8619681f7612ff56be1e1c4931391bf9902c/includes/Title.php#L570 at the time, but that didn't get gender distinctions until @Nikerabbit added it in 7694c67c99fbc0eec72f5b8df18b45d529d9651b in 2011. At the time of that patch the *parser function* {{NAMESPACE:....}} called Title::getNsText() and thus would get gender distinctions, while the *magic word* {{NAMESPACE}} called $wgContLang->getNsText( $this->mTitle->getNamespace() ) ) and thus didn't get those distinctions. I'd like @Nikerabbit to weigh in w/r/t his intent & desire here.)

The main priority was the forms displayed in the URL and in other places where formatted page names are displayed. It's probably my oversight to not consider the behavior of the magic words which now presents the fix as a breaking change.

I see compelling reason for the change, so the question is how can we support the migration to not cause unreasonable burden.

I am not aware of any other with empty parameter, but {{NAMESPACE:}} might be a bridge for migration.

• This one is the function call with new behaviour.
• {{NAMESPACE}} is the 2006 behaviour.
• Those who want the new formatting for current page may insert a : and get the new result.
• Currently {{NAMESPACE:}} is rendered as empty string.