We divert one of our experienced high-wage-value workers to make this edit.... instead of doing whatever other work they would have done.

I would disagree with two of the assumptions here:

• That Wikipedia editors won't decide to spend more time editing because of such concerns being raised. Contributors typically don't spend 100% of their free time editing, and hypothetically an increase in the number of such valid concerns could encourage a contributor to spend some more time fixing those issues.
• That editors would need to be diverted to resolve the issue. Some editors specifically find value in helping new users (e.g. regulars at the help desk), so it's possible that they would actively seek out such comments on talk pages (e.g. by filtering recent changes to find such comments).

It seems sort of inevitable that if a tool is made easier to use there will be more unproductive things done with it (simply because it will be easier). Perhaps it would be better to, e.g.,

• measure if such edits are being successfully reverted,
• consider methods of actively reducing the rate of such edits.

(For this reply I'm assuming that the <span ...>...</span> is being saved directly into the wikitext, since this seems to be implied.)

Is the current plan to eventually allow tables to be used without any additional syntactical/formatting difficulty (i.e. would it definitely be possible by version 3)? If so, would changes to the parsing of talk pages be made in the first version?

In T235923#5658799, @matmarex wrote:

In T235923#5639667, @Jc86035 wrote:

I feel like it should be obvious that ideally a wikitext table should just work like it normally would? It is technically possible to indent a table in the current software using current discussion formatting conventions, though I think until recently I always used {{outdent}} because I didn't realize that you could do this. (Nevertheless, the use of the table forces the list to end, even if additional list items are placed directly below.)

I think you're describing just putting the table non-indented after the list item? Which would be a solution to our problem, I guess, but it isn't a great solution. It's not possible to actually indent a table, as far as I know, unless you use HTML syntax for either the list or the table (which is another not-great solution).

I feel like it should be obvious that ideally a wikitext table should just work like it normally would? It is technically possible to indent a table in the current software using current discussion formatting conventions, though I think until recently I always used {{outdent}} because I didn't realize that you could do this. (Nevertheless, the use of the table forces the list to end, even if additional list items are placed directly below.)

I think the easiest way to avoid the transclusion problem, while still using such a parser function, would be to insert the complete HTML of the signature into a parameter of the parser function (or to include it before/after the parser function) and add any other necessary user/revision data in other parameters upon page save. While this would introduce redundancy, it would presumably be easier to implement without breaking certain things; e.g. if the user ID is included as a separate parameter, the new talk page interface could link to the user's current userpage regardless of what username is stored in the signature. (I imagine this could cause issues if talk page discussions were imported between wikis, though...)

Thanks for the link. I hadn't noticed that task.

The syntax that I suggested back in February (during the phase 1 consultation) was:

>4*
[arbitrary wikitext] ~~~~

The number(s) would indicate the indentation level, and the list item after the number(s) would indicate some sort of comment styling (as opposed to being directly analogous to the current list item markers). Use of the new syntax would perhaps be optional (i.e. >4* could be omitted in place of **** or :::*). The metadata would be provided entirely by attributes within an extension tag in the signature (as proposed in T230653).

More or less, an experienced user is going to want to be able to save this sort of comment through any of the available editing interfaces, regardless of the level that the comment is nested at, using the syntax that they learned years ago (or something very close to that).

How is the syntax to get into the page source? Is it going to be saved directly or is something like an extension tag going to generate the HTML?

"Junior contributor" and "senior contributor" strike me as terms that will be confusing and/or have unintended implications (e.g. that users with 500+ edits are unambiguously regarded as having higher seniority), especially since this seems to be the first time they've been used in a MediaWiki context. While I think it does make sense to use the terms, it would probably be worth explicitly defining their meanings whenever they're used (or, alternately, replacing them with more common and/or less ambiguous terms like "experienced contributor").

Would this be generated by an extension tag or parser function, or would that HTML be directly saved into the page by the editor? The former approach would presumably be cleaner in terms of the wikitext source code.

While I am a Flow user and have it enabled on my Wikidata talk page, I do have some reservations about using VE directly without any alternative. I think it's likely that users will complain that there is no non-JS option (see e.g. VE vs. 2010 editor; Old Reddit vs. New Reddit). Furthermore, considering the relatively troubled history of VE, I imagine that it will inevitably face extra scrutiny from experienced users, and it would be disappointing to see this also get stuck in beta indefinitely.

I think it's possible that the inline "reply" button might not be visible enough, since it just looks like a normal link enclosed in parentheses. Perhaps it could be given different formatting to allow it to be distinguished more easily?

This seems like something that could be easily broken by signature customization and possibly page formatting. I imagine matching signature output would work reasonably well if users are cooperative, but that may not always be the case, and it would be preferable to avoid things that don't work with what is currently allowed.

Could you be more specific about what this would entail? (I'm assuming based on your title that you're requesting something different to that proposed in the linked proposal, as the proposal is for archival being requested automatically as soon as an edit is made.)

• It's already possible to archive individual URLs to the Wayback Machine using e.g. Firefox/Chrome extensions (or, of course, the Internet Archive website). Since equivalent functionality already exists outside of MediaWiki/gadgets/user scripts, this would only provide additional functionality for mobile users.
• On the other hand, there is likely a use case for archiving all of the external links in an article; in addition to being less tedious than the former approach, additional functionality (e.g. screenshots, recursive archival) could be accomplished through use of the new Wayback Machine Save Page Now software and its API. It's possible it could be done using a gadget or user script, but I'm not sure if it would be fine from a security standpoint.

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