I highly support this proposal. It essentially solves T278629. Many wikis do suffer from the current limit of 500. The number of pages needing over 500 IFEXIST:s is low, but they exist and are important. Example: https://sv.wiktionary.org/wiki/Wiktionary:Balans_efter_spr%C3%A5k_och_ordklass

function should return an array of mw.title objects, so we can preload the other fields

None of the provided or linked images exposes the alleged bug. So it's probably fixed by stealth. :-D

current behaviour is crap

Just stick to good old ASCII quotation marks.

The logo is active now. Please revert 2024-07-13.

Working link: https://www.mediawiki.org/w/index.php?title=Extension:Scribunto/Lua_reference_manual&diff=prev&oldid=6470970

Shot: https://commons.wikimedia.org/w/index.php?title=File:Bug-in-subheadings-ASCII-62.png
Link: https://eo.wikipedia.org/w/index.php?title=Vikipedio:Alinomendaj_artikoloj&oldid=8650474#Adolf_Hitler_%E2%86%92_Adolfo_Hitlero_kaj_Vladimir_Putin_%E2%86%92_Vladimiro_Putino

The fault is in the proprietary "Ios" and the proprietary "InternerExplorer". I am aware that some of the patents on MP3 expired, still converting Vorbis to (inferior) MP3 is anything else than a gain. As long as users of proprietary stuff are the most privileged group having everything working smoothly and "natively", whereas users of free software and free file formats have trouble, the power of the proprietary companies will not shrink. PNG as a temporary solution until the patent on LZW84 expires, Vorbis as a temporary solution until the patents on MP3 expire, Theora as a temporary solution until the patents on old MPEG expire ... who would want to ever design a free file format under such provisions?

It should not try to convert a free audio file format into an unfree one: T346508.

Agree and strong support. Changing the submicroscopic "i" to "ⓘ" is an improvement. But please add an attribute allowing to override this new "(i)", allowing for empty string to suppress it (so that separate wikitext can be used in order to link directly to Commons).

• The fact that the namespace 4 has different names on different project types of same language makes sharing templates more difficult.
• The fact that the namespace 4 has same name as the site causes confusion. People are trying to create articles in the ns 4 assuming that ns "Wikipedia" is the obvious choice for wikipedia articles. People don't understand it's purpose. This is happening on essentially all wikis, last but not least on Indonesian wikipedia. Are other namespaces such as "Template:" NOT part of Wikipedia too?
• The namespace 4 has most aliases and causes most trouble and confusion. On many wikis we have page titles like Wiktionary/Wiktionary/Wiktionary/Project/Project.
• On wikidata it is difficult to name an item linked to pages in ns 4 because it has many names even in one language. Using the generic "Project:" is possible but it will NOT show like that on any wiki.

The former "Sitetitle" contains "{{SITENAME}}".

The name of ns 5 is currently " Pembicaraan Wiktionary: ".

YES please do decommission "Windows-1252" (and "Windows 11") ASAP.

OK ... T184749 ... does svwikt still contain non-ASCII-and-non-UTF8 text?

This one still fails: https://sv.wiktionary.org/w/index.php?title=MediaWiki%3AHistorywarning&diff=14484&oldid=8261

Logs are broken too: https://sv.wiktionary.org/wiki/Special:Logg/Taylor_49

Swedish wiktionary is still broken. I can't delete pages anymore. Plus some other cosmetical errors. But I still can undelete and protect.

T331906: Add Lua function to read out previous section heading suggests another, possibly cleaner and simpler solution to the same problem.

Indeed T122934 adresses same problem, but this one offers a simpler and cleaner solution avoiding the need for extra code like {{#sectionproperty: declare | lang=en}}.

The translation between language code and language name (discussed at meta page linked above) is already available elsewhere on every decent wiktionary. This is about reading out the RAW heading and nothing else.

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".