maybe a bug in recountCategories.php, which runs once every month (at 1st day 4:00).
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Today
Thu, Aug 29
Mon, Aug 26
Mon, Aug 19
Thu, Aug 15
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.
Mon, Aug 5
Sun, Aug 4
Aug 2 2024
Jul 31 2024
Declining for now. Please reopen if this is technically possible while still semantically correct.
Jul 27 2024
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.
Jul 26 2024
Jul 25 2024
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.
Jul 23 2024
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}})
Jul 1 2024
I would also appreciate this feature, and humbly request that this feature be bumped higher in priority. Thank you!
Jun 17 2024
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
Jun 14 2024
Jun 6 2024
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
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"
Change #1039746 had a related patch set uploaded (by Jforrester; author: Jforrester):
[operations/mediawiki-config@master] Revert "commonswiki: Enable numeric wgCategoryCollation"
Jun 3 2024
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
Jun 2 2024
Change #1037942 had a related patch set uploaded (by Ebrahim; author: Ebrahim):
[operations/mediawiki-config@master] Enable numeric sorting for Persian
Change #1037940 merged by jenkins-bot:
[operations/mediawiki-config@master] beta: Enable numeric sorting for Persian
Change #1037940 had a related patch set uploaded (by Ebrahim; author: Ebrahim):
[operations/mediawiki-config@master] Enable numeric sorting for Persian in labs
May 24 2024
Invalid - was due to an errant template.
May 22 2024
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.
May 18 2024
May 14 2024
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
May 12 2024
May 11 2024
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.
May 8 2024
May 6 2024
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.
Apr 30 2024
Apr 10 2024
Apr 6 2024
Apr 4 2024
Apr 3 2024
Apr 2 2024
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
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.