Would it be easier (relatively speaking) to make the header come down when someone scrolls up or moves their mouse 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.

I think a complete reset could require looking at every diff 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, but an error is still generated and the URL is not normalized (see T220718).

Oh, okay. If the UTF-8 support only breaks if a file contains invalid bytes (not just encoding="iso-8859-1") then actual file breakages will probably be much less rare.

Just for clarification:

• Does resvg accept viewBox="0 0 500 500"? 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 files or files with no size (per the table) then it's probably going to break a lot of existing files unless they're all fixed before the implementation. UTF-8 didn't become the most popular encoding until around 2009, 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, 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)?

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 have a higher visibility than these URLs would.

As a hypothetical idea, would it be prohibitively difficult to empty the database 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.

I have temporarily fixed this by removing the flag from all of the scripts and using the system's version of wget.

As an example, I tried removing as many spaces as possible from the score at Wikidata:Property proposal/quotation or excerpt (music). I got it down to 387 characters, but the score comprises just 5.33 bars of Für Elise. A higher limit would almost certainly be needed for many PD scores (particularly those with more than one staff and those with lyrics).

Oh, I didn't. I didn't realize that a gadget change would propagate immediately.

The interface buttons have returned without explanation.

I've filed a Firefox bug.

Considering that the mobile site has a column width of 280px for wikibase-statementgrouplistview and the desktop site's wikibase-snakview-body is 417px wide at maximum, using a zoom as well as a page size might be appropriate. (Alternately, the mobile site could use a different page size, but that might open a few cans of worms.)

I've tried testing the scores from the linked Wikipedia article at Q405798 on beta. The page resizing seems to work, although a different size might be better.

The only way I know of making the score narrower is to set the page size of the score (e.g. #(set-default-paper-size "b6"); I used this in an article).