@Isarra I'm not sure if there's already a ticket for this, but GeoHack coordinates are misaligned again for me (possibly because of the recent change to where the language links are displayed). It looks like this is because the position is now set based on the top of the prose, so the coordinates usually end up floating above the infobox area. I also have the XTools gadget turned on, which adds additional vertical space between the h1 line and the start of the prose.

Safari 12.1.2 on macOS 10.14.6; video captured and edited using QuickTime Player; audio redirected using Soundflower; exported using ffmpeg.

Firefox 68.0.2 on macOS 10.14.6; video captured and edited using QuickTime Player; audio redirected using Soundflower; exported using ffmpeg.

There's four-sevenths of a second between each beat, and I don't think the delay exceeds that.

I've reported this in the librsvg issue tracker.

I've checked all of the Wikivoyages' logos. Two of the logos (el, uk) seem to be raster-only; should they be redrawn/vectorized as SVGs?

@LadyofShalott remarks on Wikipedia:Village pump (miscellaneous) on enwiki that the survey keeps reappearing even though she has already responded to the survey.

I don't think it is. Only one of the issues in the search has been updated in the past six months, and it seems to be completely unrelated.

Other examples of this problem (probably simpler examples, in fact, since there's only one mask in each image) are File:BSicon uetkKRZ3+lto.svg and File:BSicon evKRZ3+1o.svg. In the original revisions of both images, attributes on a <g/> element result in the opacity of a <path/> element being inadvertently reduced.

See also T209243: Protection of classes of Wikidata items based on attributes of their statements; it might be more practical to (either additionally or alternately) allow protection of classes of statements (e.g. based on property). This would be somewhat similar to how MusicBrainz requires 7-day review periods for all edits to certain types of data.

Is there an existing procedure for reflecting the page moves and deletions that will occur during the period that Wikidata is read-only?

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).