After a bit of poking around, it appears the underlying issue is with the website, which (depending on user-agent) will send a redirect to google.com.hk. It has the same behavior in curl:

The project directory on Toolforge doesn't appear to have any code:

This is a result of a slight change in the HTML structure of headings. Previously, they looked like this:

I'm having trouble setting up a dev environment on my local machine, but I'm fairly confident that the problem here is with https://github.com/MusikAnimal/pageviews/blob/1852ad6160e463113adca1e1a1333adbecd58384/javascripts/shared/pv.js#L1570. It's only running URL-encoding on a select subset of characters that doesn't include =, (, or /. I don't immediately see why the URI-encoding can't be unconditional (or better yet, use URLSearchParams rather than doing the encoding manually), but unless I can get a test environment up I can't make a PR.

The issue appears to be at https://gerrit.wikimedia.org/g/mediawiki/extensions/GrowthExperiments/+/master/modules/ext.growthExperiments.Homepage.NewImpact/components/NoEditsDisplay.vue#36; the message (growthexperiments-homepage-impact-scores-thanks-info-text) is missing its second argument.

Looking at the page history InternetArchiveBot didn't do anything wrong here; it just added an archive URL to a dead link, like it's supposed to do. If the bus line doesn't currently exist, edit the article to say so. If it never did, you can nominate it for deletion and take it up with Argenbart, the person who created the page back in 2014‎. In any case, this isn't a software bug.

This ticket doesn't pertain to any Wikimedia-associated software, so this isn't the right place for your question. If you want Arduino help, try asking your question on https://arduino.stackexchange.com or https://forum.arduino.cc

This ticket doesn't pertain to any Wikimedia-associated software, so this isn't the right place for your question. If you want Arduino help, try asking your question on https://arduino.stackexchange.com or https://forum.arduino.cc

I can connect now. Thanks!

Root cause seems to be that the build process draws the statistics from https://pagecounts.toolforge.org/pagecounts.json, which hasn't been updated to the sharding introduced in T306589, and so only gets one of the shards (which is also why the number is almost exactly one order of magnitude too small). https://github.com/MaxSem/pagecounts/pull/2 updates the query to deal with this; @Jdrewniak and @MaxSem are maintainers of the Toolforge tool.

@Magnus: No, but that's being worked on; see T254636

@Orlodrim: see T315063; the table will be dumped, but some required work hasn't been done yet. In the meantime, the table is available in the Toolforge database replicas.

The root cause here is that templates like {{If autoconfirmed}} use the autoconfirmed-show and unconfirmed-show CSS classes (among others), which are set to their defaults in MediaWiki:Common.css and MediaWiki:Mobile.css and then overridden in MediaWiki:Group-autoconfirmed.css. Similar things hold for the other groups. As far as I can tell, the app doesn't load this CSS

Due to this diff; it's just a punctuation fix, not anything that modifies the meaning of the footer.

Verified that this bug no longer occurs (with the same revision of the app, though the fix wasn't in the app itself)

API response is now correct

This is noted on enwiki at Wikipedia:Mobile communication bugs linking to T274359, suggesting that it's a Parsoid caching issue; I'm not sure whether that's closely related enough to consider it a proper duplicate. For what it's worth, I can also reproduce this on my phone (same release version as Samtar above) and get what appears to be the same revision. Just loading the page via the Parsoid API does the same.

Huh, that's weird; it's started working for me as well. Maybe I just forgot to clear my cache after uploading a new version?

It's been two days and I'm getting the same error when trying to add dag:Finland to Q33 (and I am autoconfirmed; it's not the protection)

This sounds like list-defined references, which are an existing feature that are relatively close to LaTeX's format of having a short identifier followed by the full text at the end.

I can reproduce all these with Zotero 5.0.96; likely a different version than Wikimedia has deployed, but probably an upstream issue.

I think this may be primarily Google's problem, but I'll also note that this doesn't seem to be exclusive to the mobile site; see this enwiki VPT section for another instance of a page with NOINDEX and in robots.txt appearing in Google search results.

I just opened https://github.com/zotero/translators/pull/2326 upstream, which should take care of the problem.

Category:Past proposed deletion candidates has talk pages of articles that survived proposed deletion. For getting articles that were actually deleted, it should suffice to go through the deletion log looking for PROD or a link to Wikipedia:Proposed deletion.

I have run into what seems to be the same problem. To reproduce with the first example on the ZoomViewer docs, when I open this image I get the exact error above ("No response from server iipsrv.fcgi"). This happens with every image I have tried. I'm using Firefox 78 on Fedora 31.

It's consistently working for me now. Thanks!

After some experimentation, I found that this query fails while this query works. The only difference is the order of the URL parameters (in the first, the empty subject is at the beginning, while in the second, it's at the end). No idea what would cause that to matter, though.