I cleaned up all the templates on enwiki that were broken by this change, but I'm seeing ~800 other pages on enwiki that would likely need script/bot cleanup as they either use [[toolforge:]] or {{fullurl:toolforge:}} with special characters: https://en.wikipedia.org/w/index.php?search=insource%3Atoolforge+insource%3A%2F%28fullurl%3A%7C%5C%5B%5C%5B%29tool%28forge%7Clabs%29%3A%5B%5E%5C%7C%5C%5D%5D*%5B%5C%3F%5C%26%5C%3D%5D%2F&title=Special%3ASearch&profile=advanced&fulltext=1&ns0=1&ns1=1&ns2=1&ns3=1&ns4=1&ns5=1&ns6=1&ns7=1&ns8=1&ns9=1&ns10=1&ns11=1&ns12=1&ns13=1&ns14=1&ns15=1&ns100=1&ns101=1&ns118=1&ns119=1&ns126=1&ns127=1&ns710=1&ns711=1&ns828=1&ns829=1&ns1728=1&ns1729=1

@bd808 That was potentially a bad example, as the php script is doing some custom parsing of the URL so it works with or without a ?, but it's also a case where the script URLDecoding the URL before parsing the parameters wouldn't work because it would break a case such as https://randomincategory.toolforge.org/?category=Texas_A%26M_University

With my randomincategory tool (https://randomincategory.toolforge.org/), interwikilinks such as [[toolforge:randomincategory/Pending_AfC_submissions&server=en.wikipedia.org&namespace=2!118&type=page|Random submission]] had been working for several years, but seem to have stopped working because the &s and =s are now getting url encoded. Is that due to the recent patch by @bd808?

Is this still waiting on T246960 (which was supposed to have been revisited in Q3 2021)?

Another discussion on enwiki: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Explicit_images_in_search_autocomplete_for_%22human%22

In T291691#11247529, @DLynch wrote:

In T291691#11240439, @SD0001 wrote:

For users who set editing mode to "Remember my last editor", would using this feature cause VE to be remembered?

It would. That could probably be changed, though I can see an argument for it going either way.

Adding @Samwilson, who authored the above patch.

I've been running a mirror of Steinsplitter's GlobalUsageCount tool at https://globalusagecountmirror.toolforge.org since the original has been down since the grid engine shutdown, and my mirror is the one currently being linked to by various Commons interface messages. Some other bugs have come to light that would require changes to the source code (missing translation detection was broken by changes mediawiki's 404 pages), and I don't really want to be running a mirror that has significant changes from the original. If possible I'd like to be added as a maintainer of the main globalusagecount tool so I can update it and get it running again under k8s. I contacted Steinsplitter on wiki and by email a couple of weeks ago, but he's rarely active and has not responded.

In T377663#10244690, @SD0001 wrote:

It's a universal feature of code editors. I don't think a toggle button is necessary here. Adding user preferences for everything is not sustainable. Besides, there's no easily recognisable icon for autocompletion.

In T373543#10101499, @Novem_Linguae wrote:

How does one subscribe to a page? I thought subscriptions were only for level 2 headings.

Anyone know why I got an email saying that I own a Cloud VPS project called "tools" that is going to be shut down? Did this go out to everyone with a Toolforge account?

I'll add that I'd also prefer Select2 as an alternative to Chosen not only because it's not deprecated, but because Select2's appearance is a closer match to OOUI than Chosen's, and Select2 has the ability to use custom themes if someone were to write an OOUI theme in the future. I'm tagging MediaWiki-ResourceLoader as Chosen is included as one of the core modules but Select2 is not.

The only other alternative that would behave as intended for cases like that Cyrillic military base would be to write an algorithm that would analyze the default name and try to determine the predominant character set, and then only apply Rule 3 if it doesn't match the current language. There are all sorts of corner cases we'd have to deal with, like https://www.openstreetmap.org/relation/4610904 where the default name included both Latin and non-latin versions, which may be preferable to a hypothetical Serbian version.

Another example: https://maps.wikimedia.org/#15/40.7379/-73.9819 displays the default English names for places in New York

I updated the description. Any tools that rely on database replicas, including all toolforge tools that rely on data not available through the API, are affected by this.

For those not on the mailing list, the message from MMiller on February 6 was:

I have submitted a pull request to bring to code up to Python 3.9 which should allow it to run on kubernetes, and have a proof-of-concept running at http://afdstats2.toolforge.org. No response from the maintainers yet.

Fun fact: 2.44.10 is older now (4.5 years) than 2.40.2 was when this task was first opened (4.1 years).

https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Thumbnails_not_generating

In T5593#8664998, @Cmglee wrote:

Network bandwidth is a significant issue. A couple years ago there was an estimate of average SVG file size that was several hundred thousand bytes. A PNG thumbnail is probably less than 40 kB.

This is especially problematic with maps. For other SVG files, several users e.g. Sarang, Mrmw, TSamuel and cmglee have been actively compressing overly large files.

@VirginiaPoundstone, as far as I'm aware, it's not so much that Thumbor is dependent on features of Debian 9 (Stretch) and is incompatible with Debian 10 (Buster) or 11 (Bullseye), it's that currently running on Stretch requires us to use obsolete and buggy versions of other libraries such as librsvg. lt's mostly a matter of setting up and configuring Thumbor on a Bullseye instance, although there are some modifications that would be needed to support the latest versions of librsvg, as documented at T265549.

@Legoktm for an input list of arbitrary length, that would result in the possibility of getting an output of "1, or 2", which is not desired. Serial commas should only be used in lists of three or more items. You then end up with something like =mw.text.listToText(list, nil, #list > 2 and ", or " or " or ") which is starting to get pretty unwieldy for something required by pretty much every English style guide.

As a note, my proposed image also reduced the font size of the "Latest comment" line to help distinguish it from the first comment.

I know that this change has been reverted, but for future reference, while the new icon usually appears to me as:

I agree with Nikki here that the arrow should be leaving the box, not pointing to the corner.

Which images on the bad-image-list on enwiki are there because they are perfectly innocent images that are being spammed across wikipedia? The only ones I see on there are there because (a) they are inappropriate except in specific contexts or (b) they are non-free images and Wikipedia policy only allows them to appear on pages for which there is a fair-use rationale in place. Neither of those situations are images we want in search results. I've seen innocent images requested on the talk page from time to time, but those requests are almost always declined (and that sort of vandalism is typically taken care of with a block or an edit filter).

The Bad-image-list is based on each individual community's consensus. I'm pretty sure that the consensus in most english-speaking areas is that graphic sexual imagery is inappropriate in some contexts, which is why enwiki put those images on their bad-image-list. If fawiki found the consensus to put all images of women on their bad-image-list, then those images shouldn't show up in their search results either.

I don't think its as hotly controversial as you make it out to be. There's a vast difference between showing potentially controversial images in context (which is what that referendum was about), where they are carefully placed and vetted by human editors, and an automated tool trying to guess what pictures it should show in popups and search results that ends up showing pictures of anal sex to kids as they are typing in the name of the city where Disneyland is located. There is no requirement that search results or popups contain images (and on desktop there have been no images in search results since the founding of Wikipedia), so no harm is done if the occasional false positive slips through, and those images of bunnies or assholes will still be present in the appropriate articles.

Another request for this on enwiki: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&diff=prev&oldid=1100413658

In T10571#130430, @Qgil wrote:

Why would editors need this? Editors look after good or bad edits, but these different types of "complex" diffs cannot make such distinction. Besides, it would take a lot of extra space in the history.

I believe this is a wontfix.

I am also seeing it only on https://refill.toolforge.org, not the ng site. Whether I get the "request this server could not understand" message or the 502 error seems to be based on the length of the input. If I paste in your example 42 times I get a 502 error, but if I only paste it in 41 times I get the other error page.

In T306246#8008661, @ovasileva wrote:

Trying to catch up here. What happened to the suggested solution of transcluding of MediaWiki:Bad image list on MediaWiki:Pageimages-denylist? It seems like the most reasonable way forward. It meets the English Wikipedia use case, while also giving flexibility to other projects that want to fine-tune page images with a feature-specific list.

What are the current blockers to moving forward with that?

I'm confused as to why "What links here" is in that label at all -- we already know what page we're on because the box sits right below the h1 that says "Pages that link to "X"". The label should be clear and unambiguous, something like "Advanced options" (and frankly this applies to "Special:Contributions" as well, as the box isn't for searching since we already did that, it's for setting advanced search options).

@Arthurfragoso, the only issue is that font rendering can be wildly inconsistent between devices and browsers. It can cause labels to not line up correctly, text to overlap, or even certain characters not to show up. Sure, best practice may be to convert raw text to paths, but there are lots of cases where that isn't practical or desirable (especially if an SVG file needs frequent edits or updates).

In T306246#7898606, @TheDJ wrote:

Idea: We change PageImages to take into account the badimagelist automatically and mark all images on the badimage list as "non-free"-candidates for the purpose of PageImages (Pageimages always selects a 'free' and/or a 'non-free' candidate). This means the image will not be used in lists that get used outside of the page itself.

It's a bit of a hack, but would be quite effective I think.

In T307482#7900257, @bd808 wrote:

Per https://www.mediawiki.org/wiki/Phabricator/Project_management#Priority_levels: UBN! is reserved for isses meeting the guidelines at https://wikitech.wikimedia.org/wiki/Deployments/Holding_the_train#Issues_that_hold_the_train.

In T306246#7878200, @Jdrewniak wrote:

From my reading of this ticket, it seems that transcluding {{MediaWiki:Bad image list}} into MediaWiki:Pageimages-denylist could be the easiest solution here, as @Ahecht suggests.

In T306246#7864393, @Jdlrobson wrote:

Please also read the format https://www.mediawiki.org/wiki/Extension:PageImages#Configuration

In T306246#7862924, @AlexisJazz wrote:

MediaWiki:Pageimages-denylist just doesn't seem to work at all for this purpose. Until we can figure out if/how that's supposed to work, we can't test if transclusion works. If that would work, that would be acceptable.

After reviewing the code for both pageimages and MobileFrontend, it looks like the easiest solution is just to transclude {{MediaWiki:Bad image list}} into MediaWiki:Pageimages-denylist on Wikis where it is desirable to have the former blocked from search results. No need for manually copying one over to the other, no need for a bot. I don't have access to test this, but from the source code it should work.

The image was never added to https://en.wikipedia.org/wiki/MediaWiki:Pageimages-denylist. Once it is, per https://www.mediawiki.org/wiki/Extension:PageImages#Can_I_exclude_certain_page_images?, you will need to change a link on the article to force it to refresh the page image. Purging isn't enough.

In addition to all the reasons AlexisJazz mentioned, if this also fixes the embarrassingly bad thumbnail quality when the source image is too wide, I'm all for it. The quality problem could be fixed right now by changing background-size: auto 100%; to background-size: auto; in list-thumb.list-thumb-y, but I suppose that's not being done because it causes a lot of whitespace around wide images. If we have category icons of a known reasonable aspect ratio, we can treat them the way we treat the placeholder image and load the actual SVG at a fixed size instead of a stretched rasterized version.

My RandomInCategory tool on toolforge was affected by this as well since it's using the standard PHP 7.3 installation on toolforge. I fixed it by changing $jsonFile = file_get_contents($queryURL) to :

In T294484#7464023, @AntiCompositeNumber wrote:

The Python 3 upgrade is trickier. Upstream released an alpha version with Python 3 support (Thumbor 7) in February 2020, but has had very little activity since (none in the last 6 months and no releases of any kind in the last 18 months).

Stretch was supposed to be phased out by June 2021 per https://wikitech.wikimedia.org/wiki/Operating_system_upgrade_policy, and will be EOL in less than 6 months (June 30, 2022) per https://wiki.debian.org/LTS. Is any work being done on this?

Ugg. That seems like a massive oversight for an organization with $157 million in revenue and a >$100 million endowment.

@Aklapper Are there any plans to upgrade to librsvg 2.42 or greater? It's been over three years since its release.

Sorry for adding to a declined task, but I have a js script I want to run periodically via node.js, but I can't just use the "nodejs" command because that runs node.js v8, and I need v10. I have been running it using
webservice --backend=kubernetes node10 shell nodejs ~/www/js/wikiprojects.js. How can I run this via crontab, since running that command as-is gives me the -bash: /usr/bin/webservice: No such file or directory error?

What is the alternative for displaying math symbols not supported by TeX in such a way that the app doesn't render them invisible? See T182127

There are some wiki pages that still do not display correctly in dark mode.

Then use single vs. double underlines, or some other feature that doesn't sacrifice readability in favor of navigability.

As mentioned before, all of the proposed colors fail the WCAG AAA accessibility criteria of a 7:1 contrast ratio for normal text. We shouldn't be sacrificing accessibility in actually being able to read the text to make links stand out more. If you want to make links stand out, there is a standard way that that has been done since the beginning of the internet: underlining them.

Thanks. I updated the version on githhub to do better validation of lang and urlencode title=. I'm not sure how to validate the nouns and adjectives, since those lists are designed to be customizable.

@sbassett I am, unless @Legoktm has any other issues with the code.

Sandbox version pushed to the live website.

Good catch. I was wondering why the <nowiki> wasn't being displayed as a change. I agree that, if the previous tag was being ignored by the parser because it was unclosed, adding a reply should try to keep that status-quo.

I had a little time and put together a revision: https://github.com/zanhecht/ircredirect/blob/main/index.php. It's also live at https://ircredirect.toolforge.org/sandbox/.

• The first bug is a relatively easy fix.