The problem has now gone away for me. I've also only checked in Firefox 67, though.

Is this primarily for the English Uncyclopedia? It sounds like it (or something like it) could be useful for the proposed Wikimedia talk page improvements, although obviously that project is still in the planning phases.

@Isarra Is the change to the checkbox styling (i.e. the display:block CSS) intentional? In the other skins they display on a single line.

I meant an extra parameter in the templatedata

@Samwilson As a practical matter, the assumption of ISO 8601 for dates is a design flaw in TemplateData, and as such a design flaw in TemplateWizard. I don't know how it was decided. For a new system it seems sensible, but I don't think anyone is going to be pushing for millions of dates (on hundreds of different projects) to be reformatted just so the software knows how to deal with them.

• Because the English Wikipedia uses either DMY or MDY depending on the article, in the case of a single parameter accepting a date, it would be pointless to force users to include an extra parameter to indicate how a date should be formatted, rather than letting the template add the microformats and leave the text intact.
• Partly because almost all of the English Wikipedia's templates were developed before the introduction of Scribunto in 2013, many of the templates which do accept ISO 8601 dates (e.g. {{Birth date}}) do so by receiving the year in the first parameter, the month in the second and the day in the third (|df=y indicates a DMY date; default is MDY). It would probably be considered extremely disruptive to change that now for no real benefit.
• Also partly because of the late introduction of Scribunto, virtually all infobox templates (at least on the English Wikipedia) require the use of these helper templates and would not apply any formatting if a raw ISO 8601 date were used in their place.
• Most dates do not need microformats in the first place, and citations cannot include microformats, so there would be little point in autoformatting such dates. What is entered is usually what is shown on the page.

The reason that it works is that Template:Graph:Chart/styles.css contains a CSS fix (thanks to @Yair_rand). It would be sufficient to include only the TemplateStyles CSS instead of the whole template.

From the duplicate issue: I would have thought the problem was (at least partly) this CSS –

That exact CSS now appears to have broken mapframes; see T221781: Mapframe map thumbnails are unclickable, and full screen map cannot be loaded / T221439: Static mapframe not clickable in 1.34.0-wmf.1 .

A clarificatory note: The "API" table row is somewhat misleading, since it doesn't really refer to actual APIs, but it essentially tries to reflect whether it would be possible to script archival without the website operators' explicit permission. Of course, for archival projects with Wikimedia backing, this would probably be a non-issue.

• The Wayback Machine allows for fairly easy scripting, since the original Save Page Now is served with HTML (with the URL format https://web.archive.org/save/https://example.com). Both list-based and recursive archival can be performed using even the command line (I've archived a large amount of content with one-liners and lists of URLs). The new Save Page Now would be more difficult to script, since both POST requests and browser JavaScript support would be required.
• archive.is/archive.today can prevent scripted archival by leaving requests stuck at the /submit page, but it is possible to script both list-based and recursive archival, although this is still limited compared to IA/Wayback.
• Webrecorder's software is open-source and would allow for in-house archival, although it is also possible to script archival by accessing URLs in the format https://webrecorder.io/record/https://example.com through a modern JavaScript-supporting browser. The latter approach is, again, more limited than IA/Wayback, and the website structure would make it difficult for others to find the archived content.
• WebCite could probably be scripted, but I would avoid doing so because the site just doesn't work very well.
• Perma.cc has such a small per-user limit that scripting archival would be almost pointless.

@Marsupium Have you tried using the wmflabs tool wikidata-externalid-url? I used it for the formatter URL for Twitch game ID (P4467) in September because of the space issue, and it worked without any changes to the actual Toolforge code.

There's no error code visible on the page or in the page source. The issue occurs because of the timeout, and the timeout is deliberately executed by the server, so it wouldn't make sense to have an exception hash.

Should T221380 be merged or made a subtask? It seems like the same issue, but I wouldn't be able to know.

@Framawiki It sounds like the same issue but I'm not totally sure.

A few months ago, the Internet Archive released a "beta" Save Page Now, which has a larger feature set (including archiving all links on a page) and is capable of archiving content that the original Save Page Now either can't archive (e.g. Facebook, gov.hk) or refuses to archive (e.g. Snopes, although content can't be viewed). I've updated the table to reflect this.

Is the cat configurable (I'm guessing it's not)? A grey version of e.g. the Wikipedia logo could be a nice touch.

The newer CSS still looks a bit weird. The headers are much larger relative to the rest of the text, the GeoHack coordinates don't display correctly, and there are still a few places where there isn't enough padding.

Would it be easier (relatively speaking) to make the header come down when the user scrolls up or moves their cursor up to the top (and maybe on mobile, if a touch event is registered at the top of the screen and no links are clicked)?

The issue isn't really that the font is unreadable or terrible, since it's almost exactly the same as what Vector looks like on a computer without Helvetica installed. It's just not really consistent with what "Timeless" looks like, since the skin is supposed to look less cramped and less... 2000s (for lack of a better descriptor) than Vector and Monobook.

Most Linux distributions have Liberation Sans, don't they? Or at least one sans-serif font that's not Arial, I would think.

It turns out that the server doesn't abandon the query if wget immediately retries the request, even though the server returns a 500 error.

Also, a lot of things (e.g. the "From date"/"To date" boxes) are too close to each other.

It doesn't prevent me from doing anything, but it looks a bit like someone tried to slap too much Vector into it. (It's possible that it's partly because I don't really like Arial, but the different CSS does significantly affect how nice the skin looks for me.)

I think a complete reset could require looking at every diff that links to the properties as well, since I've definitely edited some of the relevant statements more than once.

In T221348#5123114, @Aklapper wrote:

It is unclear to me what you expect to see where.

I'm upgrading the priority, since this seems to be fairly fundamental functionality and shouldn't be resulting in a timeout.

Also, it seems that if you change it back to the original, the old thumbnail is reused.

I don't think a checklist would be easily maintainable. Perhaps a three-character limit for arbitrary subdomains, plus a separate whitelist (or alternately one regular expression with both)?

For the record, the information in T108602#2112942 no longer appears to be accurate, although the extension does now normalize such URLs as a result of the commit.

I believe the original issue might have been fixed.

Since the task was declined and the extension has been deployed, I have been using a shell script to generate short URLs for all of the project homepages. It should be done in about two hours.

This actually works on meta.wikimedia.org, but an error is still generated and the URL is not normalized (see T220718).

Oh, okay. If files are only broken if they contain invalid bytes (not just encoding="iso-8859-1") then actual thumbnail errors will probably be a little less rare.

Just for clarification:

• Does resvg accept viewBox="0 0 500 500" without other dimension attributes? librsvg doesn't recognize this (example) and reads it as 512 × 512.
• Does resvg accept SVGs without an XML header (I don't remember any specific examples at the moment) or without any encoding specified (example)? Both work with librsvg.

Just noting, if resvg doesn't support non-UTF-8 files or files with no size (per the table) then it'll probably break a lot of existing files unless they're all fixed before it's implemented (if ever). UTF-8 didn't become the most popular encoding until around 2009 (per enwiki), and there are still a lot of older SVGs lying around.

If adding new functionality (i.e. changing the database structure) is out of the question:

• Would it be appropriate to temporarily increase the minimum character length, to leave open the possibility of creating the links to project home pages?
• Otherwise, would it be appropriate to remove the Easter eggs using the extension's interface?

Is it impossible because it is prohibitively difficult to patch the code, or for some other technical reason? We know it's definitely possible in theory, because, well, existing URL shortening websites can create custom URLs, so we can't just claim that it's not possible (or not desirable).

I did consider creating a new task to address the reservation of URLs other than the 1-character short URLs which are currently assigned, since the task was originally only about changing the Easter eggs, but I decided not to since it would be disruptive to the conversation.

We are not opening a domain registry or something like this here.

Out of interest, is there any particular reason $ was added to the list, and was there a reason 2 was omitted? (I can't find any documentation on how these parts of the extension work.)

@Ladsgroup Does the extension not allow the creation of custom links altogether? I'm confused by this, since it was evidently possible to create https://w.wiki/$.

I agree that this isn't extremely important, although the first "testing" URLs could be seen to have or to indicate certain symbolic value (hence my earlier comment proposing that it would be seen to reflect systemic biases). Similarly, the very lowest-numbered Wikidata items (universe, human, happiness, etc.) appear to have strong symbolic value and are reflective of the developers and their intentions, although those items might have a higher visibility than these URLs would.

As a hypothetical idea, would it be prohibitively difficult to empty the database (or even reinstall the extension) and recreate the appropriate links, if it is desirable to remove the Easter eggs?

@TheDJ The Internet Archive don't collect them, the Archive Team do (the data is sent to Internet Archive servers). Usually they do this by sequentially or randomly checking every possible alphanumeric combination, although perhaps the complete list of URLs could be given to them instead to save some time for them, since WMF own the database.

This discussion indicates that changing URLs directly in the database causes severe caching issues, but is the only way to change existing URLs. This may contradict the information given on the main information page, which indicates that stewards have the ability to delete all links. Clarification would be appreciated.