Do you believe that if someone opens a Wikidata item with 100
sitelinks, Wikidata should query all 100 Wikipedia projects every time?
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
May 22 2022
May 15 2022
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
Jan 23 2022
SUPPORT, all wikis, once per month.
Jan 22 2022
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.
Jan 21 2022
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.
Jan 14 2022
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
Sep 30 2021
don't need arbitrary padding
T2986: [tables] Please implement COL, COLGROUP unresolved since year 2004
Sep 29 2021
Sep 20 2021
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.
Aug 9 2021
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.
Aug 2 2021
Jul 10 2021
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.
Jun 23 2021
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):
Jun 5 2021
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.
May 24 2021
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.
May 22 2021
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.
May 19 2021
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.
Apr 6 2021
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.
Mar 31 2021
I assume removing the badge from a sitelink should be disallowed if the target page is (currently) a redirect?
Mar 28 2021
Mar 27 2021
Feb 9 2021
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.
Feb 7 2021
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.
Dec 1 2019
Nov 29 2019
Sorry for the late answer. Indeed it works well and this "bug" can remain CLOSED.
Nov 21 2019
'''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.
Nov 20 2019
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).
Nov 14 2019
I have sort of a consensus now (3 YES votes, one of them is mine after 5 days, started Nov-09):
Nov 9 2019
May 1 2019
Works, thanks.
Apr 28 2019
Looks great now. Can de deployed.
Apr 26 2019
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").
Apr 21 2019
Apr 9 2019
Apr 3 2019
Can we get the patch enabled now?
Mar 28 2019
OK, I can see the change.
Mar 22 2019
Yes.
Mar 21 2019
Fixed my mistake. I lack access rights to fix the "bug".