maybe a bug in recountCategories.php, which runs once every month (at 1st day 4:00).

In T85372#8815895, @Galobtter wrote:

If T50175 is doable, it's probably the best way to do this. That would enable other functionality and enable wikis to properly customize when they load editnotices.

Declining for now. Please reopen if this is technically possible while still semantically correct.

Note some data models do not support categories (such as items), so having categories on them, while potentially useful, may give users impression that Item pages can be categorized.

The interface message is included in the user language, so it cannot be used for categorization.

Similar to T289404 which was declined

A problem my suggestion has in its current state is that MediaWiki:Scribunto-doc-page-header also appears in doc pages that don't exist. My proposal as suggested would add every possible title to the category, which would be pretty bad. For this reason I propose that the categorisation kicks in only when the page exists.

to get the infobox into some kind of row in the column

Well I feared that something like that is used so it's not so simple to change this in the code which is why I first went to the talk page of the infobox to propose alternatives. However, none of these seem to get implemented or be easier to implement plus changing this in the code would be the proper (instead of workaround) way.

I fear this isn’t possible (but I’d be happy to be proven wrong!): the subcategories use CSS columns, and in my experience elements with columns never wrap floated elements that are outside of the columns element. (I couldn’t find any standard or anything else supporting this, though, it’s just my experience.{{citation needed}})

I would also appreciate this feature, and humbly request that this feature be bumped higher in priority. Thank you!

Mentioned in SAL (#wikimedia-operations) [2024-06-17T20:06:59Z] <jforrester@deploy1002> jforrester: Backport for [[gerrit:1041659|[wikifunctionswiki] Remove right to promote/demote sysops and bureaucrats from staff (T365627)]], [[gerrit:1039767|Add a note that you cannot change wgCategoryCollation easily (T362494 T366809)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-06-17T20:01:57Z] <jforrester@deploy1002> Started scap: Backport for [[gerrit:1041659|[wikifunctionswiki] Remove right to promote/demote sysops and bureaucrats from staff (T365627)]], [[gerrit:1039767|Add a note that you cannot change wgCategoryCollation easily (T362494 T366809)]]

Change #1039767 merged by jenkins-bot:

[operations/mediawiki-config@master] Add a note that you cannot change wgCategoryCollation easily

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

There may be some pages that are wrong, but this should sort itself out as they're re-parsed.

Pagination appears to be working correctly now.

Mentioned in SAL (#wikimedia-operations) [2024-06-06T15:23:02Z] <jforrester@deploy1002> Finished scap: Backport for [[gerrit:1039746|Revert "commonswiki: Enable numeric wgCategoryCollation" (T366809)]] (duration: 13m 58s)

Change #1039767 had a related patch set uploaded (by Jforrester; author: Jforrester):

[operations/mediawiki-config@master] Add a note that you cannot change wgCategoryCollation easily

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

Mentioned in SAL (#wikimedia-operations) [2024-06-06T15:11:34Z] <jforrester@deploy1002> jforrester: Backport for [[gerrit:1039746|Revert "commonswiki: Enable numeric wgCategoryCollation" (T366809)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-06-06T15:09:03Z] <jforrester@deploy1002> Started scap: Backport for [[gerrit:1039746|Revert "commonswiki: Enable numeric wgCategoryCollation" (T366809)]]

Change #1039746 merged by jenkins-bot:

[operations/mediawiki-config@master] Revert "commonswiki: Enable numeric wgCategoryCollation"

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

Change #1039746 had a related patch set uploaded (by Jforrester; author: Jforrester):

[operations/mediawiki-config@master] Revert "commonswiki: Enable numeric wgCategoryCollation"

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

Mentioned in SAL (#wikimedia-operations) [2024-06-03T12:03:18Z] <ladsgroup@deploy1002> Finished scap: Backport for [[gerrit:1037942|Enable numeric sorting for Persian (T329440)]] (duration: 12m 07s)

Mentioned in SAL (#wikimedia-operations) [2024-06-03T11:53:30Z] <ladsgroup@deploy1002> ebrahim and ladsgroup: Backport for [[gerrit:1037942|Enable numeric sorting for Persian (T329440)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)

Mentioned in SAL (#wikimedia-operations) [2024-06-03T11:51:11Z] <ladsgroup@deploy1002> Started scap: Backport for [[gerrit:1037942|Enable numeric sorting for Persian (T329440)]]

Change #1037942 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable numeric sorting for Persian

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

Change #1037942 had a related patch set uploaded (by Ebrahim; author: Ebrahim):

[operations/mediawiki-config@master] Enable numeric sorting for Persian

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

Change #1037940 merged by jenkins-bot:

[operations/mediawiki-config@master] beta: Enable numeric sorting for Persian

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

Change #1037940 had a related patch set uploaded (by Ebrahim; author: Ebrahim):

[operations/mediawiki-config@master] Enable numeric sorting for Persian in labs

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

Invalid - was due to an errant template.

Questions from @Bmueller:

• What are the dependencies (code, and/or people)?
  • "Categories" are a fairly small feature. It builds on general platform concepts like JobQueue, DeferredUpdates, and utility functions, but I don't think this task requires changes to other components or feature behaviours. As such, while not exactly standalone, I'd say it has no code dependencies that we need to be mindful of in this context. In terms of teams, the feature is unowned. The task does not require making behaviour changes besides obvious bug fixes, so no controversial decisions or indirect product impact expected there.
• What is the impact of this?
  • Sustainability: the current implementation is needlessly complex and redundant and yet still seeems to regularly produce inaccurate counts. It is prune to production errors and load problems. e.g. T352628: Fatal exception of type "Wikimedia\Rdbms\DBTransactionSizeError", per @Ladsgroup above.
  • Product experience: The most prominent use category counts, where the number itself is imporant/sensitive, is Wikipedia maintenance categories, and similar "meta" categories on other wikis. The counts are often used to power templates, gadgets, and bots to know when a particular kind of issue has more than 0 articles affecting it. The problem is often that the category will either be zero when it shouldn't be or above zero when it should be zero. To clarify: The problem is not e.g. when a category containing 100+ items and the number being off by a few, which would not be a big problem in that case. We have ~15 duplicate bug reports about this at the moment, dating back several years.
• What would it cost to fix? TBD.

Change #1031526 had a related patch set uploaded (by Theknightwho; author: Theknightwho):

[mediawiki/core@master] Don't convert quotes to HTML tags if used in category sortkeys

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

This issue is more general than just categories. It also makes it impossible to find all the templates that transclude a particular template as is discussed here. This is an issue that can potentially affect all XfD venues since it apples to every link that is between includeonly tags. An example of this is Template:Deleted template, currently at TfD, where WLH missed two of its uses that were between includeonly.

I'd prefer not to include any additional __MAGIC_WORDS__ and instead use case-sensitive {{#parserfunction}} syntax for new additions, as discussed in T204370: Behavior switch/magic word uniformity. The current proposals for "no categories" "but wait some categories" seem quite confusing. One of the benefits of parser function syntax is that we can add arguments! So it seems like {{#cat:Foo|always}} would be (eg) an alternative way to ensure that the page is /always/ added to Category:Foo, instead of making it a property of the category itself. Alternatively, an extensible {{#categoryproperties|always|hidden|....}} on the category page would be more sustainable than a plethora of __HIDDENCAT__ ALWAYSCAT` etc magic words.

In T361632#9682431, @Pppery wrote:

I don't particularly care whether Meta does it. Just wanted to point out that it wasn't a universal trend.

I don't particularly care whether Meta does it. Just wanted to point out that it wasn't a universal trend.

In T361632#9682219, @Tacsipacsi wrote:

In T361632#9682154, @Varnent wrote:

I have not checked all other uses of the extension

I’ve checked them:

Wiki	Translatable categories	/Translations categories
meta.wikimedia.org	1113	1007
foundation.wikimedia.org	204	126
outreach.wikimedia.org	15	13
wikimania.wikimedia.org	10	2
incubator.wikimedia.org	4	2
commons.wikimedia.org	9	2

(all other wikis have zero /Translations categories)

So while it’s almost omnipresent on Meta and used a lot on Governance Wiki, other wikis that have such categories have too few translatable categories to really have established practices (including Commons: over 2000 translatable pages, but only 9 of them are categories!). MediaWiki.org, another wiki with many (almost 1500) translatable categories, has zero /Translations ones.

tldr: Public wikis that use this setup: Foundation GovWiki, Meta-Wiki, Incubator Wiki, Outreach Wiki

In T361632#9682154, @Varnent wrote:

I have not checked all other uses of the extension

In T361632#9682124, @Pppery wrote:

"On wikis with Translate extension installed, a "best practice" of adding /Translations category" is not true. Only Meta AFAIK does this. MediaWiki.org doesn't use a /Translations category at all, and I don't think one is needed.

"On wikis with Translate extension installed, a "best practice" of adding /Translations category" is not true. Only Meta AFAIK does this. MediaWiki.org doesn't use a /Translations category at all, and I don't think one is needed.