Fixed. In order to keep the solution generic, I modified ProveIt so that the "snippet" of the references must come from a required parameter of type "string". In case of Cite Web, since the only two required parameters are "title" and "url", and one is of type "url", it picks out "title". Hopefully this will suffice. As always allow a few minutes for the caches to catch up, cheers!

Well, I took a look at the error log and the extension, but have no clue what's causing the error. The error log only mentions "AnonPrivacy" once and refers to no file from the extension. My best guess is that because AnonPrivacy modifies a bit the HTML structure of RecentChanges, that's triggering an error. So I did my best to minimize changes, hopefully it works.

@Tgr Thanks for taking time off to explain some of the difficulties! I guess all I wanted to say is "perfect is the enemy of good". Whether it's shadow namespaces, bots or scary transclusions, at this point I think any half-working solution would be better than the current situation. Cheers!

Should be fixed now, thanks !

@Tgr That's only with "raw" transclusions. Subtemplates are not required to exist locally when "raw" is not used. But even if using "raw" were necessary, we'd just create the required subtemplates using "raw", and so on. Still fail to understand the issue.

Thanks! With your clue, I was able to figure out the exact steps to reproduce this issue:

I've been reading around this issue and doing some tests in my private wiki, and I fail to understand the reasons for not implementing centralized templates (not talking about gadgets or modules in this comment) using $wgEnableScaryTransclusion

I was thinking on adding an Archive button to the URL fields in the ProveIt gadget interface, similar to the Today button in the date fields that adds today's date, but that would transform a URL like "news.com/new-president-elected" into "archive.org/news.com/new-president-elected" and do the necessary archiving in the background through an API call to archive.org, I guess. I'm not 100% sure if this makes sense or is even possible because I haven't researched it yet, but that was my general idea when I created this task. Thanks for all the useful info though!

After some talk with the WikiJournal user group at Wikiversity, I decided to generalize this extension into InterwikiExtracts, archive WikipediaExtracts, and in some days start a new task for enabling InterwikiExtracts on Wikiversity, this time with the support of the WikiJournal user group. So this task makes no more sense and I'm closing it.

After some talk with the WikiJournal user group at Wikiversity, I decided to generalize this extension into InterwikiExtracts, archive WikipediaExtracts, and in some days start a new task for enabling InterwikiExtracts on Wikiversity, this time with the support of the WikiJournal user group. So this task makes no more sense and I'm closing it.

After some talk with the WikiJournal user group at Wikiversity, I decided to generalize this extension into InterwikiExtracts, archive WikipediaExtracts, and in some days start a new task for enabling InterwikiExtracts on Wikiversity, this time with the support of the WikiJournal user group. So this task makes no more sense and I'm closing it.

Thanks for the quick response, it works perfectly! I configured the mailing list and added links from the Wikidebate project homepages.

https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2019/Citations/Automatic_web_archive

• Cite AV media notes
• Cite conference
• Cite mailing list
• Cite map
• Cite newsgroup
• Cite podcast
• Cite serial
• Cite techreport
• Cite ssrn

If it happens again, please share a screenshot of the JavaScript console, cheers!

I've tested the Citoid service with various books and articles, and I was unable to reproduce this issue. I think the Citoid service has recently improved and now returns all dates in the YYYY-MM-DD format, which I believe is understood by all templates and is becoming standard.

I just tested the OCLC given to reproduce the issue (and a few others too) but something has changed. Now, rather than getting the first and last names reversed, they are both coming together, separated by a comma, like so: "Eskew, Glenn T."

Done in master, will push to production in a couple days.

Done in master, will push to production in a couple days.

Done in master, will push to production in a couple days.

Done in master, will push to production in a couple days.

However, see T234367

This is actually not desirable, because while the browser enforces that users can only write numbers on "number" inputs, and only URLs in "url" inputs, MediaWiki doesn't, and sometimes templates may be suggesting a type but not wanting to enforce it. For example, an "year" field may be of type "number" but allow values such as "400 b. C." which the browser would never allow.

@Esanders That's exactly what I needed, thanks!

Basic RTL support is already in place. But more careful support and attention to detail is still needed.

ProveIt is already localized (translated) to Hebrew. It's not enabled on the Hebrew Wikipedia yet, but it's up to the Hebrew community to do it. This task was useful because Hebrew is a RTL language and RTL support in the ProveIt gadget was (and still is) half-way through. But there're other RTL languages, some of which have ProveIt enabled on their corresponding Wikipedias, and there's T148339 for tracking progress on general RTL support, so this task makes no more sense now.

Localization (that is, translation to particular languages) of the ProveIt gadget is being done through translatewiki.net
The gadget is already localized to about 100 languages, most of which were never linked to this task.
Localizations are pushed periodically to Gerrit by translatewiki.net and the gadget is then able to use the latest translations by querying Gerrit/Gitiles directly.
This task was always more about tracking the enabling of the gadget in new wikis, than localizing the gadget to the languages of said wikis.
But most wikis enable the gadget on their own without going through this task.
This task is useless, and always has been, but now more than ever, so I'm closing it.

The bot is no longer needed since it turns out to be possible to get the latest translations directly from Gerrit/Gitiles

In T123636#5530540, @Whatamidoing-WMF wrote:

Are you trying to do something like what @Reedy did with AWB in T111663: Tag AWB edits? Also, I think ProveIt is on the list at T185382: Add manual tag- messages to Wikimedia Messages for common tools/gadgets.

Given that there already is a visual distinction for raw references (namely, that they don't start with a big bold "Cite whatever") I'm closing this task unless further reasons are given for reopening it.

The latest ProveIt version crucially relies on the "atob" JavaScript method (https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/atob) which is supported by all modern browsers, but Internet Explorer only supports it from version 10 onward. Adding support for older browsers now comes at an unacceptably high development cost. Unless strong reasons are given for adding support for old browsers, this task is unlikely to ever be resolved.

Fixed! See https://ru.wikipedia.org/w/index.php?title=Богомоловые&action=edit for proof and add other "strange" templates to https://ru.wikipedia.org/wiki/MediaWiki:Gadget-ProveIt.js to add support for them too.

The localization to Thai is already done, but it's up to the Thai community whether or not to enable the gadget

Declined until some argument is given