Do you believe that if someone opens a Wikidata item with 100
sitelinks, Wikidata should query all 100 Wikipedia projects every time?

Can this maybe get closed now? There are plenty of non-urgent bug-items about the same thing, and one more is still open:

Adding Wikidata badges in Wikidata via a bot needs one bot approval within Wikidata
Adding a magic word to existing redirects would require a bot request on every Wikimedia project

T299823: Regularly run recountCategories.php on Wikimedia wikis via systemd timer

SUPPORT, all wikis, once per month.

If it is valid then it is a dupe of T85696: Allow action=purge to recalculate the number of pages/subcats/files in a category.

The script was run again on all public WMF wikis due to T299244: Deleted pages are not being removed from links tables, which also messes up category counts.

Right ... quit ping-spamming, and make sure to give a support vote after 2022-01-28: https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Wikidata/Do_not_follow_sitelink_redirects_when_redirect_badge_is_used#VALIDREDIRECT

don't need arbitrary padding

T2986: [tables] Please implement COL, COLGROUP unresolved since year 2004

Fixed 3 typos: https://meta.wikimedia.org/wiki/Requests_for_comment/Resolve_massive_copyright_infringement_on_Wiktionary_in_Esperanto

I still think that a magic word is the preferable approach, irrespective of progress with the temporary fix with many badges. Discard the badges and use VALIDREDIRECT instead. Let wikidata autodetect "redirect to page" vs "redirect to section" and display appropriate icon, and autodetect VALIDREDIRECT too with a tri-state verdict "intentional redirect" vs "dubious redirect" (redirect but magic word missing) vs "misuse of VALIDREDIRECT" (target is an empty page, or a redirect, or a page (not section) not linked to wikidata). I do not see the point with "Q16956589" either. Make it as simple as possible. The originally intended solution with 2 independent badges allows for a large number of dubious states.

I don't know whether this batching would be possible for pagesincategory queries too. If YES then it is the preferred fix. I have an alternative idea that I would put into a separate task if batching is possible for ifexist only.

Hello ... thanks for answering. Allowing to batch "ifexist" calls from LUA (unlimited or at least high number of pages for the cost of one) would be a great thing. This explains why there can be more than 500 links and they still have right colour, whereas "ifexist" stops working.

The script has been applied to -eo- wiktionary and the broken categories seem fixed. Now we can think about a more permanent solution for the problem, in the form of of running this script regularly or upon request, or by other means. Another wiki badly needing this was commons. See T85696.

The title of this task "Run populateCategory.php" is presumably incorrrect (T170737):

Closing as dupe of T85696, again.

Possible fixes:

• a) run the script now on all public WMF wikis (will fix categories broken for now, will not prevent the wrong counts from re-appearing)
• b) run the script now, and re-run it regularly or at least occasionally, or establish a way to request running it on a particular wiki
• c) add a check against ZERO before decrementing the counter, making it impossible for the counts to become negative (removes the most prominent and most silly symptome of the bug, particularly if a) is performed subsequently, but will not fix false positive counts for empty categories, less useful alone, sufficiently useful together with b))
• d) Allow "action=purge" to recalculate the number of pages/subcats/files in a category (very useful, let users fix those categories that bother them)
• e) fix the flawed logic (see above T85696#2079552 by "PleaseStand") causing this bug (most difficult strategy?) and perform a) then

Running this script will not prevent the problem from re-appearing after some time, but it will make the values correct for now at least. There are other ideas around, most notably "Allow action=purge to recalculate the number of pages/subcats/files in a category". From the discussion above it's unclear why this is "stalled". It is clear that it is assigned to nobody and nobody is working on this, closing as dupe of T85696.

YES this still needs to be done. Many wikis are broken.

Closing this in favor of T85696 because the very same problem occurrs on other wikis, and nobody is working on this task.

Closing this in favor of T85696 because the very same problem occurs on wikipedia, wiktionary and other wikis.

IMHO the priority of this task should be increased given the large number of complaints and redundant duplicate tasks about the very same problem.

This problem seems to exist on all wikis and has been causing complaints for over 10 years. Closing this in favor of T85696: Allow action=purge to recalculate the number of pages/subcats/files in a category. The negative record is -12 for now.

SUPPORT. Reevalutae the category, including the sortorder.

https://eo.wiktionary.org/wiki/nobela https://vortaro.net/#nobelo_kd piracy (can be found in PIV, cannot be found in PV)

Removing All-and-every-Wiktionary as this is not about all Wiktionaries

I am the malicious sysop deleting articles all the time. There is a large number of such articles, and there are several ways to search for them. It will take years to get rid them all, as I want to add useful content and improve quality of the project besides only deleting.

Support. Discard the badges and use __VALIDREDIRECT__ instead. Let wikidata autodetect "redirect to page" vs "redirect to section" and display appropriate icon, and autodetect __VALIDREDIRECT__ too with a tri-state verdict "intentional redirect" vs "dubious redirect" (redirect but magic word missing) vs "misuse of VALIDREDIRECT" (target is an empty page, or a redirect, or a page (not section) not linked to wikidata). I do not see the point with "Q16956589" either. Make it as simple as possible. The originally intended solution with 2 independent badges allows for a large number of dubious states.

I assume removing the badge from a sitelink should be disallowed if the target page is (currently) a redirect?

4 years later. A solution is needed for " https://sv.wiktionary.org/wiki/When_in_Rome,_do_as_the_Romans_do. " vs " https://en.wiktionary.org/wiki/when_in_Rome,_do_as_the_Romans_do ". Either by allowing linking to redirects, or by some other trick. Most wiktionaries have restrictive policies when it comes to redirects. For example "colour" redirecting to "color" is prohibited on many wiktionaries and thus probably not an issue. Those are NOT same pages. But "When_in_Rome,_do_as_the_Romans_do." and "when_in_Rome,_do_as_the_Romans_do" are same. There is no obvious solution about how to deal with proverbs on wiktionaries. EN wikt has a policy to remove final punctuation and avoid capitalization of beginning letter of a sentence, thus the lemma form is " when_in_Rome,_do_as_the_Romans_do ". SV wikt has a policy resulting in " When_in_Rome,_do_as_the_Romans_do. " (uppercase "W" and dot at the end). Those are SAME LEMMAS and should thus be linked to each other. Unfortunately automatically adjusting the letter case is not possible as it would result in a huge number or false positives. Allowing automatic interwiki linking to redirects would allow to solve the problem manually by creating redirects on both sides. I do not see any better "magic" solution now. If there is an issue with false positives then the interwiki linking to redirects can be restricted to pagenames containing at least one space. This would rule out a mess of "color" and "colour" and "colow" as pointed above. I consider "Cognate" as highly preferable to manual explicit interwiki links (as used before 2017) but this issue with proverbs needs to be solved.

4 years later. A solution is needed for " https://sv.wiktionary.org/wiki/When_in_Rome,_do_as_the_Romans_do. " vs " https://en.wiktionary.org/wiki/when_in_Rome,_do_as_the_Romans_do ". Either by allowing linking to redirects, or by some other trick. Most wiktionaries have restrictive policies when it comes to redirects. For example "colour" redirecting to "color" is prohibited on many wiktionaries and thus probably not an issue. Those are NOT same pages. But "When_in_Rome,_do_as_the_Romans_do." and "when_in_Rome,_do_as_the_Romans_do" are same. There is no obvious solution about how to deal with proverbs on wiktionaries. EN wikt has a policy to remove final punctuation and avoid capitalization of beginning letter of a sentence, thus the lemma form is " when_in_Rome,_do_as_the_Romans_do ". SV wikt has a policy resulting in " When_in_Rome,_do_as_the_Romans_do. " (uppercase "W" and dot at the end). Those are SAME LEMMAS and should thus be linked to each other. Unfortunately automatically adjusting the letter case is not possible as it would result in a huge number or false positives. Allowing automatic interwiki linking to redirects would allow to solve the problem manually by creating redirects on both sides. I do not see any better "magic" solution now. If there is an issue with false positives then the interwiki linking to redirects can be restricted to pagenames containing at least one space. This would rule out a mess of "color" and "colour" and "colow" as pointed above. I consider "Cognate" as highly preferable to manual explicit interwiki links (as used before 2017) but this issue with proverbs needs to be solved.

Sorry for the late answer. Indeed it works well and this "bug" can remain CLOSED.

'''UPDATED''': Indeed now it works well if I AM NOT LOGGED IN ... only 0 and 102 are preselected. But when logged in still all namespaces are preselected. This does not happen on for example Swedish wiktionary. The request was not to completely remove the possibility to search in them, only to remove them from the preselection. And the patch added only 102 and did not remove the other ones. I don't know why they are preselected when I am logged in. No longer a major issue, but still strange.

Thanks ... I see that the patch has already been applied and works. The namespace 102 has been added (the most important part of the request), the large amount of obscure namespaces (other than 0 and 102) have not been removed (the less important part).

I have sort of a consensus now (3 YES votes, one of them is mine after 5 days, started Nov-09):

Works, thanks.

Looks great now. Can de deployed.

The reason is that "Aldono" and "Modulo" are substantives whereas "Uzanta" is an adjective.

Sorry for a minor comment: instead of "103 => 'Aldono_diskuto'" it should be "103 => 'Aldono-Diskuto'" (dash and uppercase "D") consistent with for example "Modulo-Diskuto" (not with "Uzanta_diskuto").

It works, thanks. [https://id.wiktionary.org/w/api.php?action=query&titles=Lampiran:Daftar_isi&prop=pageprops]

Can we get the patch enabled now?

OK, I can see the change.

Yes.

Fixed my mistake. I lack access rights to fix the "bug".