Change 356507 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/extensions/MobileFrontend@master] Replace MFContentNamespace with wgContentNamespaces

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

Change 357426 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[operations/mediawiki-config@master] Update ContentNamespaces for Commons Wiki

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

Added to evening swat (https://wikitech.wikimedia.org/wiki/Deployments#Week_of_June_5th)

Change 356507 merged by jenkins-bot:
[mediawiki/extensions/MobileFrontend@master] Replace MFContentNamespace with wgContentNamespaces

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

Change 357426 merged by jenkins-bot:
[operations/mediawiki-config@master] Update ContentNamespaces for Commons Wiki

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

Mentioned in SAL (#wikimedia-operations) [2017-06-06T23:12:41Z] <thcipriani@tin> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:357426|Update ContentNamespaces for Commons Wiki]] T167077 (duration: 00m 46s)

It works! https://commons.wikimedia.org/wiki/Special:Nearby

FYI, https://gerrit.wikimedia.org/r/357426 will have a HUGE effect on the "article count" of Commons. Already, it has caused the count of content pages (seen at, say, commons:Special:Statistics) to more than double in the last week -- see the "discussion" (so far, just me talking to myself) at https://commons.wikimedia.org/wiki/Commons:Village_pump#Content_pages .

In fact, by the current definition, the "true" content page count of Commons "should be" something in the millions, probably. This means the wiki will need to be recounted from scratch to get an observed count even remotely close to the true value.

Was this change actually discussed on Commons before it was made?

Hi @Dcljr

Please accept my sincere apologies! I hadn't realised this value also touched Special:Statistics. I naively thought it only touched Special:Random and thought the config value was un-intentional. Of course, if I'd known that I would have discussed on Commons.

To check I understand the problem :

• Does this just impact the count on Content pages value on Special:Statistics ?
• What's the reason why file pages are not included in that count?
• Does this impact Commons in any other ways besides Special:Statistics?

I'm not sure I understand all of your questions.

Q1: If you mean as opposed to impacting any other value on Special:Statistics then yes, I believe it only affects "Content pages".

Q2: Until the change to make the File: namespace a content namespace, File: pages would naturally not count as content pages. If you mean "politically" why was that decided in the first place, then I have no idea. If you mean technically why are they not all _now_ counted, it's because counts only change when something is done on the wiki itself (page creation, deletion, modification) that could potentially change the count. Since the vast majority of File: pages are not being changed in any way, their new status as content pages is not being "recognized" by the software. But _newly_created_ File: pages (containing at least one wikilink — say to the user page of the "author") _are_ adding to the count; and, presumably, deleted File: pages (that contained wikilinks) are now lessening the count; and File: pages that are changing from having wikilinks to having none, or vice-versa, are now decreasing or increasing the count, as appropriate. (However, count-lessening actions to any File: page that has not previously been counted as content is another source of count inaccuracy. Like I said, only a complete recount from scratch would fix the count and ensure that it is reasonably accurate going forward.)

Q3: I don't know. The content-page count (on SpecialStatistics or via API query) is the only impact I know of (aside from the _intended_ impact, of course, which I didn't know about until I read this task report).

Note that I'm not saying the Commons community will necessarily care about the change to content-page counting. I don't know. (Admittedly, no one has responded to my Village pump post about this in the last 16 hours. In the past when I've pointed out [on Meta] major changes to / inaccuracies in the way MediaWiki counts "articles", no one really seemed to care, and no changes were made as a result [AFAIR]. So that may be the case this time, too.)

My own view is that "content" on Commons does, in fact, consist of its files, so it makes some sense to count File: pages as content pages. However, before the change there was a (sort of nice) distinction between uploaded files ("Files") and "gallery" pages in the main namespace containing at least one link ("Content pages"), whereas now the two counts are confounded. Also, the distinction between File: pages that contain links vs. those that don't may not be a useful one, so the community may want to discuss whether to switch to the "any" count method (counting all pages in all content namespaces, not just those with links). Or they may not. We'll see, I suppose…

EDIT: BTW, I could be wrong about any of this with respect to how the MediaWiki software behaves. As a "normal wiki user", I have no particular knowledge about the inner workings of MW beyond what I've gleaned from researching changes to article counting in the past (as alluded to above).

In T167077#3352871, @Dcljr wrote:

I'm not sure I understand all of your questions.

Hello! Seems like you understood them well. Thank you.

Q1: If you mean as opposed to impacting any other value on Special:Statistics then yes, I believe it only affects "Content pages".

Thanks for this clarification.

Q2: Until the change to make the File: namespace a content namespace, File: pages would naturally not count as content pages. If you mean "politically" why was that decided in the first place, then I have no idea. If you mean technically why are they not all _now_ counted, it's because counts only change when something is done on the wiki itself (page creation, deletion, modification) that could potentially change the count. Since the vast majority of File: pages are not being changed in any way, their new status as content pages is not being "recognized" by the software. But _newly_created_ File: pages (containing at least one wikilink — say to the user page of the "author") _are_ adding to the count; and, presumably, deleted File: pages (that contained wikilinks) are now lessening the count; and File: pages that are changing from having wikilinks to having none, or vice-versa, are now decreasing or increasing the count, as appropriate. (However, count-lessening actions to any File: page that has not previously been counted as content is another source of count inaccuracy. Like I said, only a complete recount from scratch would fix the count and ensure that it is reasonably accurate going forward.)

Yeh the question was more with regards to the political decision. I couldn't find any record of why it was this way and if changing it back I'd like to make sure we explain why it's this way so nobody inadvertently changes it again. Also I'm curious if the original reasoning still stands - as it might have been a workaround for the technology at the time which has since improved. The thing that was interesting to me was that Commons hardcodes a link to Special:Random/File in the navigation menu. The wgContentNamespace value applies to the default results of Special:Random and this link seems to imply "File" is a content page.

It seems either way - whether we revert the change or keep it, we'll need to recount them to fix it - I can definitely explore how we can do this with ops once we've worked out the correct action to take.

Q3: I don't know. The content-page count (on SpecialStatistics or via API query) is the only impact I know of (aside from the _intended_ impact, of course, which I didn't know about until I read this task report).
Note that I'm not saying the Commons community will necessarily care about the change to content-page counting. I don't know. (Admittedly, no one has responded to my Village pump post about this in the last 16 hours. In the past when I've pointed out [on Meta] major changes to / inaccuracies in the way MediaWiki counts "articles", no one really seemed to care, and no changes were made as a result [AFAIR]. So that may be the case this time, too.)

I'm still not seeing any replies - is there anybody we could ping to get input from on this? It would be useful to hear more about the history and other people's opinions on what to do here and why content namespace previously excluded files. Sorry again for this disruption to the statistics count and thanks for all your helpful input so far!

Regarding the hardcoding of "Special:Random/File" in the navigation menu: this is because most people at Commons care about files more than galleries, so the link was made to bring up a random file rather than a random gallery. Ironically, this could be seen as an argument in favor of the change you made (since it illustrates how File has been ''de facto'' treated as if it were a content NS) or as an argument against the change (as the intent was to treat files differently from galleries). Again, I don't know what the "consensus" will be at Commons, but I have posted a more explicit request for relevant input at the Commons' Village pump and pointed to it from a few key places around the wiki.

@Dcljr that's great! thank you so much. Let's check in in about a week or so and we'll work out next steps.

I've opened T169822 to update the article count. At least then the value will be reporting something correct.

The logic inside Special:Shortpages takes all content namespaces (https://github.com/wikimedia/mediawiki/blob/master/includes/specials/SpecialShortpages.php#L46). As NS_FILE became a content namespace (rOMWC6d0d005d238810d0eaec8e65f55f7431f1eabe67) Special:ShortPages will always include file pages in report.

There are couple possibilities here:
a) hardcode skipping NS_FILE inside SpecialShortPages which is probably bad, but most of pages inside NS_FILE are short
b) introduce new config var that defines a list of namespaces to include on SpecialShortPages page
c) use ShortPagesQuery hook and remove NS_FILE only on commons wiki (it may read a config variable what to not include in the report)
d) do nothing as NS_FILE is a content namespace in commons wiki.