Sample Page

I’ve noticed that spaces in URL’s often don’t get escaped properly. For example:

<ref name="book_TheB">{{Cite web
| title = The Bronx, in Bits and Pieces
| author = 
| work = Google Books
| date = 
| accessdate = 2018-02-03
| url = https://books.google.com/books?id=WeVTP3GyFH0C&pg=PA175&lpg=PA175&dq=faile+mansion&source=bl&ots=Gi_ATxuIsJ&sig=nMvLUfi4Y0Ckl8G377s-9IspZqA&hl=en&sa=X&ved=2ahUKEwiC78nhzofZAhWKxFkKHW3nCBgQ6AEwDnoECAsQAQ#v=onepage&q=faile mansion&f=false
| language =  
| quote = 
}}</ref>

The url field has q=faile mansion. The embedded space should be escaped to a + (or maybe some %hex code).

Other than that, this is a truly awesome tool. Thanks for making it available! — RoySmith (talk) 15:54, 3 February 2018 (UTC)[reply]

Thanks for reporting this, it was a mistake to decode the URL like that. It is fixed now. —V111P (talk) 19:22, 23 August 2018 (UTC)[reply]

I have read over the instructions for using this tool. But I am not a webmaster nor an HTLM specialist, I am just a person who wants to create a citation from a newspaper web page, and I still have no idea how to use it. Was hoping for instructions that were geared to a much more generalized audience, one that, for example, does not know what it means to “run a script” on a page (I know what a web page is, and I know how to run a mile, and I have read many scripts, but I do not know how to run a script any more than I know how to read a mile!). Am hoping you can reword things here for the lay user. Please consider it. Thank you! A loose necktie (talk) 08:35, 7 May 2019 (UTC)[reply]

@A loose necktie: Of course I know it’s not super simple to set up. You can try to find easier and more up-to-date instructions on how to create a bookmarklet in your browser elsewhere on the Internet. Basically it’s just a bookmark whose URL (web address) is the code provided (the code starting with javascript:). You can edit any already existing bookmark in your browser and change its URL to that code. Then you click/tap that bookmark on the web page you want to cite. I hope this helps. —V111P (talk) 10:41, 9 May 2019 (UTC)[reply]

@A loose necktie: Hi, it actually is super easy to set up. I do computer support for friends and family, so let’s first ditch all the jargon. This is what you need to do:

• In your second favorite browser, the one you don’t use a lot for editing Wikipedia, go to https://en.wikipedia.org/wiki/User:V111P/js/WebRef
• In your favorite browser open any web page that you haven’t bookmarked yet. Make a bookmark — I put mine on the Bookmarks bar for easy access.
• Right-click the new bookmark and in FireFox go to Properties, in Chrome or Opera to Edit. You’ll see that the first line is headed Name and contains the name of the webpage you just bookmarked. Replace the name of the webpage with whatever makes sense to you, I called my bookmark Wiki WebRef.
• The second line is called Location or URL, depending on your browser. Delete the URL that is in it so that you have a blank line. Go to your other browser and copy the entire text in the green box. Then go back to your main browser and paste this into the Location or URL line of the bookmark. It will look like it won’t fit, but it does.
• Hit Save and you are done!

It really is this easy. Any questions, just let me know. You can also send me an email if you get really stuck and don’t want to discuss it here, but I doubt that you’ll need to.

— Peter NYC (talk) 23:22, 9 May 2019 (UTC)[reply]

@V111P: We have presented a proposal to develop a visual Citoid/Zotero web translator tool, to enable non-technical users collaboratively widen Citoid coverage. I have recently learned about your tool WebRef (thanks to User:Fuzheado) and I see it has a similar goal. We would highly appreciate your thoughts and comments in the discussion page, and your endorsement if you would like to support it. Thank you! —Diegodlh (talk) 23:03, 17 March 2021 (UTC)[reply]

@Diegodlh: Thank you for contacting me. I’m not interested in that project, but I wish you good luck. —V111P (talk) 15:25, 22 March 2021 (UTC)[reply]

At this discussion at WP:VPT, I noted that some tool(s) are adding stuff like {{!}} Thesaurus.com to |title= (see the example citation in that discussion). Another editor in that discussion suggested that this tool does that sort of thing. If it does, please fix the tool. The website name does not belong in |title= ever. Instead, put the website name in its appropriate parameter |website=.

Thank you

—Trappist the monk (talk) 13:23, 6 July 2021 (UTC)[reply]

@V111P: I’m trying to use the “Date formatter” function to set the accessdate to %Y-%m-%d (2021-07-31), but the various variations I can think of myself I get the response that ‘Sorry couldn’t parse that’. 1Veertje (talk) 12:35, 31 July 2021 (UTC)[reply]

@1Veertje: I’ll be adding support for Y-M-D very soon. I just didn’t realize until now that anyone needed it since it seemed to not be recommend by the style guides. (By the way, adding {ping} to an old comment does not work.) —V111P (talk) 10:22, 1 September 2021 (UTC)[reply]

yes I think documentation is outdated. I recently updated the documentation on the Dutch language Wikipedia. The thing that makes the “cite” button in the visual editor possible is the citoid API and it formats dates Y-m-d. The Cite web template than formats it with the full month name if that’s the wiki’s config.^[1] 1Veertje (talk) 11:26, 1 September 2021 (UTC)[reply]

In the English Wikipedia it’s more complicated, because the date format (d-m-y or m-d-y) has to be chosen manually, depending on the article. —V111P (talk) 23:32, 1 September 2021 (UTC)[reply]

No, on the English wikipedia what people should do is either use {{Use mdy dates}} or {{Use dmy dates}}. That way it can be configured once for the entire page. Therefore your bookmarklet should use y-m-d dates as the default. 1Veertje (talk) 15:33, 29 January 2024 (UTC)[reply]

Hi, @V111P! I loved your script and just finished translating it’s code and documentation to portuguese (pt:Usuário:BraunOBruno/WebRef and pt:Usuário:BraunOBruno/WebRef.js). I’m wondering if it’s ok to include it as a interiki link in your page. The same would be done in the translated version. Thank you in advance and thank you for the great tool! BraunOBruno (talk) 18:37, 30 May 2024 (UTC)[reply]

For date’s autoSearchIn, currently [‘meta-i datePublished’, ‘meta date’, ‘meta Date’]

Please add: ‘meta-p article:published_time’, ‘meta article:published_time’ and ‘meta DC.date.issued’

Thank you. 1Veertje (talk) 15:44, 14 March 2026 (UTC)[reply]

It’s been handled 1Veertje (talk) 21:40, 16 March 2026 (UTC)[reply]

Should WebRef’s default date output be changed from DMY-style dates to Y-M-D dates, so that its output can be reused more easily across various language versions of Wikipedia and article-level date formatting can be handled locally by templates and site configuration?

WebRef currently defaults to formatted dates rather than year-month-day output. There is prior discussion on this point above. A practical argument for Y-M-D is that it is easier to reuse across multiple Wikipedias, and it matches the machine-readable style already produced by other citation tools. On English Wikipedia specifically, article-level formatting can already be controlled with templates such as {{Use dmy dates}} and {{Use mdy dates}}. The specific proposed code change is:

 var dateFormatDefault = dateFormatDMY

to

 var dateFormatDefault = dateFormatYMD

1Veertje (talk) 11:08, 18 March 2026 (UTC)[reply]

Yes, all dates should be YYYYMMDD everywhere. Polygnotus (talk) 12:41, 18 March 2026 (UTC)[reply]

Agree with colleague 1Veertje. An advantage of format YYYYMMDD is it can be used easier for ordering and calculating than any other format. GfG, Il tulipano grigio (talk) 14:59, 18 March 2026 (UTC)[reply]

I may be missing something but it looks like there aren’t many people who have installed this script (Special:WhatLinksHere/User:V111P/js/webRef.js & Special:WhatLinksHere/User:V111P/js/webRefSetup.js) so then there is no need to change the original and it can just be forked. Polygnotus (talk) 16:22, 18 March 2026 (UTC)[reply]

it’s a bookmarklet, not a userscript. There’s no telling how many people have it installed since it’s a browser configuration. 1Veertje (talk) 17:34, 18 March 2026 (UTC)[reply]

True, we can’t know how many use the bookmarklet. But the bookmarklet just refers to the script. Polygnotus (talk) 19:38, 18 March 2026 (UTC)[reply]

Please don’t hold RfCs in user talk pages. —Redrose64 🌹 (talk) 20:22, 18 March 2026 (UTC)[reply]

it’s not so much this user’s page as this tool’s documentation page. I get that this is a rule because you don’t want to bombard one user with input about their behavior on their talk page, but that’s not what we’re discussing here. The tool is maintained by them and interface admins. When I previously requested this change via an edit request, it was not acted on, and an earlier discussion with the creator stalled. The aim here is to gather broader input. If there is a more appropriate venue for this discussion, I’m happy to move it. 1Veertje (talk) 20:33, 18 March 2026 (UTC)[reply]

I get that this is a rule It is not listed as a “rule” on WP:RFC.

I would just use javascript:(function(){var d=document,s=d.createElement('script');s.src='//en.wikipedia.org/w/index.php?title=User:Polygnotus/Scripts/WebRef.js&action=raw&ctype=text/javascript&smaxage=43200&maxage=86400';d.body.appendChild(s);})(); which has a few bugfixes. But to do this properly you’d turn it into a Chrome and Firefox plugin and use Citoid (which uses Zotero under the hood). Polygnotus (talk) 21:00, 18 March 2026 (UTC)[reply]

Well, how about Wikipedia talk:WikiProject JavaScript or Wikipedia talk:User scripts? You can hold a discussion on one and leave a note at the other, directing them to the actual discussion. Templates such as {{fyi}} and {{subst:please see}} are available for this. You can also drop similar notes on WP:VPT and Help talk:Citation Style 1 if you’re worried that the first two might not gain sufficient views. —Redrose64 🌹 (talk) 22:41, 18 March 2026 (UTC)[reply]

@Polygnotus:Just to clarify: are you proposing to take over maintenance of this script and move it to a different location? This script has been in use for well over a decade, and likely has a non-trivial user base (even if that is not visible via WhatLinksHere, since it is a bookmarklet). Moving it or replacing it with a fork would therefore have wider impact, and would also need to account for existing localStorage configurations.

In any case, my proposal here is much more limited: to change the default date output from DMY-style formatting to Y-M-D, so that the output can be reused more easily across projects. This does not require structural changes or relocation of the script.

@Redrose64 I guess “please see” would have been more appreciate than an RfC. Do I need to remove the RfC template and replace it with it? 1Veertje (talk) 23:27, 18 March 2026 (UTC)[reply]

I agreed with your proposal, we can ping Izno and ask them to implement that, and then I continued thinking about how to improve things.

are you proposing to take over maintenance of this script and move it to a different location? You are skipping a few steps:

likely has a non-trivial user base Step 1 would be to get some data for that.

Step 2: If so, does something similar exist, e.g. in the form of scripts/bookmarklets/browser extensions? Wikipedia:Cite4Wiki and https://github.com/zhaofengli/citegen and Wikipedia-References-Creator seem pretty similar. Help:Citation_tools possibly lists more.

This script has been in use for well over a decade The script pre-dates the Citoid and meta:Web2Cit services. A more modern version of this script could take advantage of Citoid (which uses Zotero under the hood) and Web2Cit.

Someone should probably check what software exists for this task and figure out what to work on, if any. https://xkcd.com/927/ If there are indeed many people using such outdated tools then it may be a good idea to nudge them towards something better.

Another related idea is that someone should check if we can create some more Zotero/Web2Cit translators. I should probably just take the top 10k domains mentioned on Wikipedia and check which already have translators and if Claude can make some more (with human oversight of course). Polygnotus (talk) 00:23, 19 March 2026 (UTC)[reply]

Not every citation tool works equally well in every situation. The reason I started looking at expanding refDocData is that I use WebRef on articles published by DPG Media, which is the largest newspaper publisher in the Netherlands. Their sites have a hard cookie wall that Citoid cannot get past. In those cases, a metadata-reading bookmarklet remains useful in a way that an API-based tool is not. So I would be cautious about treating “replace this with Citoid/Web2Cit/Zotero-based tooling” as equivalent to the much smaller proposal here, which is simply to improve the existing script’s metadata detection and default date output.

As for usage, there is no obvious on-wiki metric for a bookmarklet. This tool has had a user base for years, as reflected by this talk page and the feedback it received on its creator’s talk page. 1Veertje (talk) 07:01, 19 March 2026 (UTC)[reply]

The ISO 8601 date format would be acceptable for access dates and archive dates, because we can be sure the computer actions those dates describe occurred in the late 20th century or early 21st century, and thus are stated in the Gregorian calendar, as ISO 8601 requires. But publication dates may be in the Julian calendar; this was in use as recently as 1923 for secular purposes and is still in use for some religious purposes. Therefore the ISO 8601 format should not be mandated for publication dates — Preceding unsigned comment added by Jc3s5h (talk • contribs) 18:09, 24 March 2026 (UTC)[reply]

@Jc3s5h I don’t think that concern applies to this proposal. This change does not mandate ISO 8601 for publication dates; it only changes the default output of a tool that retrieves metadata from modern web sources.

In practice, those sources overwhelmingly use the Gregorian calendar, so ISO 8601 is a safe and unambiguous intermediate format. Editors remain free to adjust dates where a different calendar or representation is required.

The benefit here is that ISO 8601 works well as a neutral, machine-readable format that can then be localized by citation templates as needed. That is particularly useful across different language Wikipedias, where formatting conventions vary but templates already handle presentation.

So this is less about prescribing a format for all publication dates, and more about improving the default behavior of a tool for the common case it is designed for. 1Veertje (talk) 19:50, 26 March 2026 (UTC)[reply]

Agree that the Julian/Gregorian issue is probably a very infrequent edge case for web references.

I see the logic behind using YYYY-MM-DD for the dates, but have in the past come across some English Wikipedia editors (both English and American) who really do prefer to have dates spelled out in the source. So I think Izno is right that this could be a controversial change for enwiki users. Perhaps a compromise without forking would be to have it depend on the user’s own language settings? e.g.

var dateFormatDefault = navigator.language.startsWith('en') ? dateFormatDMY : dateFormatYMD;

the wub “?!” 11:08, 7 April 2026 (UTC)[reply]

I find the wub’s comment hard to understand, because it just throws in a line of code with no context. What environment is this? What programming language is this? How can an ordinary Wikipedia editor find out what their “own language setting” is?

Since users are mostly editing existing articles, defaulting to the user’s preferred format isn’t very helpful; the editor needs to conform to the existing format, if it is valid. Jc3s5h (talk) 11:24, 7 April 2026 (UTC)[reply]

@Jc3s5h That is JavaScript and it says:

If the webbrowser of the person who runs this script is set to use some variant of the English language, then use Day Month Year, otherwise use Year Month Day.

This is a great way to confuse and annoy Americans who are used to Month Day Year. Polygnotus (talk) 11:30, 7 April 2026 (UTC)[reply]

Thank you. The best way to handle this I can think of would be to parse the {{use dmy dates}} or similar in the article, and do what it says. But I wouldn’t be surprised if the programming environment these systems operate in would be unable to do that. Jc3s5h (talk) 11:39, 7 April 2026 (UTC)[reply]

Another option is to invade the USA and force them to adopt YMD and, while we’re at it, the metric system. This will be the catalyst for post-scarcity and a golden age for humanity. Polygnotus (talk) 11:47, 7 April 2026 (UTC)[reply]

@Jc3s5h To clarify the scope here: this is not a general proposal about how dates should be represented in articles or across Wikipedia.

This concerns the default output of a specific JavaScript bookmarklet that extracts metadata from modern web pages. In that context, the dates involved are already machine-readable and overwhelmingly Gregorian, so using Y-M-D as an intermediate format is both safe and consistent with existing tools (e.g. VisualEditor/Citoid).

Editors remain responsible for aligning with the date style of the article they are editing, as usual. This change does not alter that.

On the suggestion by @The wub: while adapting to browser language is an interesting idea, it would introduce additional complexity and still not reliably match article-level formatting. In practice, when dates are stored in Y-M-D, citation templates can already localize their display based on templates such as {{Use dmy dates}} / {{Use mdy dates}}.

For that reason, a consistent neutral default (Y-M-D) seems preferable.

Overall, the proposal remains limited to a single default variable in a tool, not a broader change in citation or date policy.

@Izno I also want to clarify that I was not trying to pursue the same decision across multiple venues. The discussion on this page concerns a specific tool change, whereas the discussion at WT:MOSNUM developed into a broader question about how citation dates are treated on enwiki more generally. While there is overlap in subject matter, they are not the same question, but rather related questions at different levels of scope.While there is overlap in subject matter, they are not the same question. 1Veertje (talk) 12:00, 7 April 2026 (UTC)[reply]

Yup, YMD is best, which can then be displayed however the user wants. Polygnotus (talk) 12:03, 7 April 2026 (UTC)[reply]

I think a valid reason for hostility against the ISO 8601 format is grossly simplified description on their website, and requiring readers to pay hundreds of dollars for a copy of the standard in order to read about the pitfalls that turn well-meaning users into liars. Not to mention the lack of an official Backus–Naur form description to avoid endless battles about how to write edge cases. (Disclaimer: I attended a lecture by Backus and was favorably impressed.) Jc3s5h (talk) 12:05, 7 April 2026 (UTC), minor fix 12:09 UT.[reply]

@Jc3s5h Just to clarify: ISO 8601 in this context simply refers to the use of a year–month–day date order (e.g. 2026-04-07). It is already widely used in practice and by existing citation tooling.

No one needs access to the full ISO specification to use or interpret such dates, and this proposal does not depend on any of the more complex or edge-case aspects of the standard.

The scope here remains limited to choosing a consistent and machine-readable default output format for this tool. 1Veertje (talk) 12:09, 7 April 2026 (UTC)[reply]

Publication dates are sometimes stated in the Julian calendar. How about your tool be programmed to refuse to operate if the publication date is before 1 March 1923, the date Greece adopted the Gregorian calendar for secular dates? Jc3s5h (talk) 12:14, 7 April 2026 (UTC)[reply]

That sounds like too much work for a tool that may have a userbase of 1 (we don’t know actual numbers). Polygnotus (talk) 12:19, 7 April 2026 (UTC)[reply]

I do not think “a user base of 1” is a realistic characterization here. Bookmarklet usage is inherently hard to measure on-wiki, but there is clear evidence that this tool has had a real user base over time: its creator received years of feedback and feature requests, the script was adapted on other language Wikipedias, and I have myself instructed multiple editors in using it in workshop contexts precisely because it remains useful for sources such as DPG Media, where the cookie wall makes API-based citation tools unreliable.

So while we may not have exact numbers, the available evidence points to an established user base rather than a purely hypothetical one. That said, I do agree that concerns about Julian-calendar publication dates are entirely irrelevant to this particular tool change. This bookmarklet is used to extract metadata from modern web pages, so the practical question here is simply what the most useful default output format is for that use case.1Veertje (talk) 12:28, 7 April 2026 (UTC)[reply]

@1Veertje The Pageview tool provides data starting from July 2015. So to get a rough idea of the popularity you can look at this. Polygnotus (talk) 19:49, 7 April 2026 (UTC)[reply]

While the pageview numbers are indeed modest, that is expected for a bookmarklet. The data does show consistent use over multiple years, which suggests this is a niche tool with ongoing use rather than something abandoned. 1Veertje (talk) 19:56, 7 April 2026 (UTC)[reply]

@1Veertje The data does show consistent use over multiple years It shows sudden growth in 2019, then a sudden cliff near the end of 2020, then May 2022 a second cliff and it never recovers. Basically no users between 2023 and now (1 to 9 views per month throughout 2023 and most of 2024–2025, with several months at zero).

So I think what we got here is an XY problem, and we need to stop focusing on fixing this tool as the attempted solution (X) and figure out a way to deal with the root problem itself (Y).

The good news is that not all is lost because the idea of a tool that can be used to get data that is not in Citoid/Web2Cit/Zotero is genuinely interesting. The approach of allowing the user to scrape the data is a reasonable approach but, for DPG media specifically, there are also other approaches worth considering.

I may be able to figure something out. It may be possible to extract at least some of the metadata from Common Crawl. If someone was to make a more modern version of this script they would use something like metascraper or open-graph-scraper. Polygnotus (talk) 23:12, 7 April 2026 (UTC)[reply]

Changing one variable does not depend on resolving the broader question of what the “ideal” tool would be. 1Veertje (talk) 06:45, 8 April 2026 (UTC)[reply]

True but this conversation has been derailed so far that its probably best to just post on Izno’s talkpage. Polygnotus (talk) 12:23, 8 April 2026 (UTC)[reply]

Izno has indicated they’re not willing to make this change. As you seem more experienced with interface-admin requests, would you happen to know another interface admin who might be willing to take a look? Given that the proposal is limited to a single default variable and has already received some discussion and support on this page, I would prefer to resolve it directly rather than start a new discussion at WP:IANB. 1Veertje (talk) 15:23, 8 April 2026 (UTC)[reply]

@1Veertje If I were you I would just follow Izno‘s excellent advice. Fork it. No need for intadmins.

Asking other intadmins won’t really work because they will see that Izno has already said that forking is the best option, and they are very very likely to agree with that.

If you prefer you can fork my version here: User:Polygnotus/Scripts/WebRef.js which contains many bugfixes. If you are really worried about preserving a userbase (despite the pageview data showing no one is using it) then the best course of action would be to ask an intadmin to add an alert that says “this script has been deprecated, please install the new version over at…”. Polygnotus (talk) 16:30, 8 April 2026 (UTC)[reply]

I understand the suggestion to fork, but that doesn’t really address how this tool is actually being used in practice.

I’ve been teaching WebRef in workshop settings for several years specifically to work around cases like DPG Media, where cookie walls make Citoid/Web2Cit unreliable. In that context, a bookmarklet is easy to distribute and use without requiring installation of extensions or maintaining separate forks.

While many workshop participants don’t become highly active editors, that doesn’t mean the tool has no users—it reflects the typical pattern of occasional editing and ad hoc tool use. That kind of usage is also not visible in pageview data for a bookmarklet.

Given that, changing a single default variable in the existing script seems like a much smaller and more practical step than fragmenting usage across forks or replacing the tool entirely. 1Veertje (talk) 17:06, 8 April 2026 (UTC)[reply]

@1Veertje But would this forever be the situation? Or would you be OK with saying “we change DMY to YMD now and then in the future we add an alert telling people to update their bookmarklet and those are the last 2 changes we make”? Because its probably not a good idea to bother intadmins for every minor change while refusing to fork indefinitely. Polygnotus (talk) 18:16, 8 April 2026 (UTC)[reply]

I just want the people who I’ve helped out over the years with installing something as peculiar as a bookmarklet to have a slightly better bookmarklet. I have an idea of also adding XPath support for user config so that the author field can automatically be filled for the NRC Newspaper, but that’s two things (supporting XPath and distributing the NRC config). I guess at the next Hackathon I should fork it but now I’ve already presented this bookmarklet at the Hackathon last month. 1Veertje (talk) 18:49, 8 April 2026 (UTC)[reply]

@1Veertje I may be able to ask someone to make those 2 changes I mentioned, but if you keep wanting to make improvements then forking is the only option (it doesn’t make sense to keep pestering intadmins and we have to rip the bandaid off at some point so probably best to do that before your next hackathon/workshop adds another 20 users). So then it would be best to:

• host the script in your userspace, with updated documentation perhaps
• ask an intadmin to add an alert that the script has moved and instructions on how to update the bookmarklet and on how to contact you if they can’t do it

Polygnotus (talk) 19:00, 8 April 2026 (UTC)[reply]

Yes, that sounds reasonable. 1Veertje (talk) 06:15, 9 April 2026 (UTC)[reply]

@1Veertje But, just to be clear, not changing the script to YMD and only doing step 2 which is to add an alert that says “update the bookmarklet, if you don’t know how click here to ask 1Veertje” does not sound reasonable? That would mean just skipping step 1 of the 2 steps I described. What is the point of step 1 if the next step makes it irrelevant? Polygnotus (talk) 23:14, 9 April 2026 (UTC)[reply]

I changed the default to YMD, with an option to choose the other formats as default in the code of the bookmarklet. (There is caching so you may need to set the numbers in the bookmarklet’s code to 0 to see the change). But to be useful with other languages, other changes are needed – most of all, more than one set of month names must be supported, then you would be able to set the month names in the bookmarklet, for example. —V111P (talk) 15:09, 10 April 2026 (UTC)[reply]