• 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

I'm thinking on implementing a solution that mimics the standard reference list on Wikipedia articles, that is: a little arrow next to each reference that takes you to the reference without opening it, and little letters that take you to the citations, again without opening the reference for editing.

I recently updated the ProveIt gadget so that it now supports the 2017 wikitext editor. However, one functionality I haven't been able to carry over is tagging the edits.

Fixed, thanks for the reports!

I evaluated this once more. Again, the difficulties seem to outdo the benefits. Deciding which fields should remain full-width and which ones half-width would require more fields in the ProveIt template map, which would require many difficult-to-explain edits to the template data of many wikis. Also, this two-column layout is not mobile-friendly and mobile support is on the roadmap.

This has been fixed for a while.

I have studied this issue and unfortunately it's not easy to fix. The tooltip hides behind the header because the entire form hides behind the header, so changing that would mean removing the tooltips from the form HTML and somehow getting them to show in the right place (a nightmare) or maybe hiding the form with z-index techniques rather than overflow techniques, which again is much harder and bug-prone.

@kostajh I won't reopen, but it seems a shame that Flow will not work with mod_security, not because of any real security issue, but because a tiny version number is encoded in such a way that mod_security confuses it with SQL Hex encoding.

This was bug with the Poncho skin, not the PageForms extension. I've fixed it now, sorry for the misleading tag and title.

Hi! I added the templates to the list of available templates, and created some basic template data for them.

Now yes, this should be fixed, thanks for the report!

@OriHoch I'm so happy you decided to take on fixing this tool! Having so many different watchlists is a daily pain. Please keep it up!

Minimize requests (maybe). Not much else. I agree this is the lowest priority now, cheers!