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.

In T72470#6935908, @doctaxon wrote:

How have I to change something like this in my user script to prevent breaking it soon:

Why can't there be three options "Enabled", "Disabled", and "Default", to separate users who deliberately turned off the tool from those that hadn't seen the settings?

@Izno Thanks, I don't know why I didn't see that in my search.

Beyond that, I don't think it's something we should use for end-users as for the most part these errors are inconsequential to them (whatever is broken isn't something they want, need, or know about), and not in their realm to understand or know how to do anything about.

In T41395#6308522, @Steel1943 wrote:

If I'm reading this correctly, the issue I see with approaching the problem in that manner, specifically via resolution "(b)", is that it would erroneously disable pages when viewing talk page archive subpages.

That brings up perhaps the most important use case: the talk page of a mainspace article with a slash in it, such as [[Talk:AC/DC]], [[Talk:n/a]], [[Talk:R/K selection theory]], [[Talk:9/11 Commission Report]], [[Talk:S/PDIF]], etc.

In T247432#6052048, @bd808 wrote:

That seems like it would be a good way to handle this if we were starting from a green field. The system I am proposing in T247432#5961170 is more work for the web browser (adds a redirect), but it has the nice properly of preserving the syntax of existing interwiki links to Toolforge things. I haven't looked, but that would probably be possible with a hook as well. As a Toolforge maintainer I somehow lean more towards solutions that leverage Toolforge than things that need to be deployed in the Wikimedia prod servers though. :)

I agree that the current icon is completely unintuitive. This is my suggestion for the best way to indicate highlighting without using any color:

In T5324#6188481, @Agabi10 wrote:

@Dvorapa the only reason for not merging it AFAIK is that it's not clear if this should be resolved or declined.

I think this problem has gotten significantly worse for "Special:RandomInCategory/Pending AfC submissions" since that villiage pump thread. As the category was reduced from 4,500 pages down to 1,350 based on reviews of "random" drafts, the large timestamp gaps have grown more prominent. I just ran it 25 times, and I got (in order):

@KylieInTheSkylie You linked to a redirect without a talk page.

@Agabi10 the tech news item was posted and has long since been archived. What's the path forward?

@Izno this would be for going from Talk to Article, not the other way around. I'm not aware of any cases where multiple talk pages redirect to a core talk page whose accompanying article page is a redirect.

@Johan, I think that's a little difficult to understand. How about "The "Article" tab on talk pages of redirects currently links to the target of the redirect. A change is being considered to have it link to the redirect page itself. You can leave feedback on this."

Why does {{REVISIONID}} now return blank when substed? Shouldn't it at least return '-'?

Currently, the user experience for someone seeing an error message such as the one at https://en.wikipedia.org/sec-warning is quite poor. To find out what they actually have to do (besides "contact IT", which is going to get them nowhere), a user has to scroll past a large list of languages they don't read, find the tiny link to https://wikitech.wikimedia.org/wiki/HTTPS/Browser_Recommendations, and then find the tiny section on that page that applies to them.

It's working again for me as well.

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

This seems to affect creating and editing pages, across multiple wikis (I've tried enwiki and meta), and across multiple accounts (I've tried both my main account and my bot account), with both VE and the wikitext editors.

How long do you expect labsdb1011 to be depooled for. Is this going to be a regular thing?

This doesn't seem to be limited to quarry. Queries (such as https://quarry.wmflabs.org/query/36665) that had been running in about 15 minutes both on quarry and through a bot running https://wikitech.wikimedia.org/wiki/User:Legoktm/toolforge_library (using the toolforge DB replica) are now timing out on both. The issue appears to be with the database servers themselves.

I would agree that the intended behavior of the "Article" button, when on a talk/history page of a redirect, should be to link to the redirect itself. The number of times an editor wants to go directly from the redirect talk page to the redirect target is small compared to the number of times the editor wants to go to the redirect itself.

Only using 40% of the page width for the actual article text seems quite low, and makes the page look cluttered (despite all the whitespace). Vector, by comparison, uses around 80%.

In T192462#4627547, @Lydia_Pintscher wrote:

Is there anything left to do here or can it be closed?

Since potentially tens of thousands differrnt sized thumbnails were affected by this bug, will the server eventually regenerate all of these, or will they need to be purged manually?

Oops, I don't know how those projects got removed...