While ISO 8601 is useful for specifying a single point in time, or a calendar day, it isn't immediately to me how I should make tabs/charts where I have monthly data, like e.g. this file. I errorneusly added -31 to the year-month, but now some entries are invalid, as there aren't 31 days in e.g. February. JavaScript's Date constructor will still accept the value, and infer it as March 1st, which might make sense. But it would have been better to reject the data before it entered the system.

Isn't a date type already supported?

@Xqt looks great, thanks! I think the automatic solving could still be done by e.g. a regex parser and a manual interpreter, but that can go in another PR I guess.

The fixes I needed to apply to get pywikibot automatically solving captchas for Haskellwiki are here: https://github.com/ysangkok/fix-wiki-links/blob/master/insc.py#L11

I trust you did consider https://gerrit.wikimedia.org/r/#/c/113759/ ?

I have another implementation strategy idea. We could let the module generate iframe data that would be embedded by base64'ing it. Since iframes do not allow scripting per default (http://www.w3.org/TR/html5/webappapis.html#sandboxScriptBlocked) and the data would not be linkable, this would allow for manually made image-maps in SVG's but still retain security. Old browsers that run scripts in iframes per default, would need mitigation. The format of code in the module could be the same as my previous patch, but a new parser function would be needed. What do you think?

I think the batch flag suggested by Pajn is a good compromise. Batch edits could be shown per default. A compromise seems necessary for AutoList.