When pressing the "today" button in the "access date" field (and other date fields), the tool defaults to the yyyy-mm-dd format. Is there a way to switch to other formats acceptable under MOS:DATE, such as mdy or dmy dates? feminist (talk) 07:09, 7 February 2020 (UTC)[reply]
Yes, I'd definitely like this to be implemented as well. I hate it when Wikipedians using ProveIt disregard an article's preferred date format template and continue to change all dates in references into the yyyy-mm-dd format. Happily888 (talk) 04:04, 1 January 2022 (UTC)[reply]
When citing YouTube videos (per WP:PRIMARYCARE), "YouTube" should be in the "website" or "work" section, not the "via" section. "Via" is how the source was created, while "website" and "work" are self-explanatory. An example of "via" would be Gale; Gale has the ability to export citations, so when they're imported to Wikipedia, they should say "via Gale". An example of a website or work would be Fox News; Fox News is a website, where the content was published, so it should say "Fox News". I'm explaining all of this because Walter Görlitz used ProveIt to move "YouTube" to the "via" section in citations to Steve Terreberry. L33tm4n (talk) 01:37, 12 July 2021 (UTC)[reply]
@L33tm4n: No, I did not use ProveIt to move "YouTube" to the "via", that is the correct place for it to be placed. YouTube is not the source. YouTube is a self-publishing platform and not the publisher itself. Walter Görlitz (talk) 02:52, 12 July 2021 (UTC)[reply]
@Walter Görlitz: (Tag: ProveIt edit) – This is the tag that's used in one of your edits, "I'm going to fix this again, please don't break it again.- Reference edited with ProveIt, Script-assisted fixes: per CS1 and MOS:ITALICS". Also, the "publisher" section is not for the website itself, but rather the publisher of the website. Plus, if it's a self-publishing platform, it can go in the "website" or "work" section (YouTube is a website), and it won't need a publisher name next to it. And like I said before, "via" is how the source was created, not for the name of the website; Twitter created a proper method of citing tweets, so they include "via Twitter" in citations of tweets. L33tm4n (talk) 12:27, 12 July 2021 (UTC)[reply]
Your statements about my actions are correct. Your statements about how YouTube should be listed in a reference are not. YouTube should in the via= parameter. This tool correctly moves it there. While it is a website, that is not the correct parameter. It is most certainly not a work. You should be raising this as a question at a citation template not demanding a change from this tool or from me. Walter Görlitz (talk) 16:57, 12 July 2021 (UTC)[reply]
In fact, now that I have had a bit of time I looked at Template:Cite web. The via= parameter states that it should be used for the "name of the entity hosting the original copy of the work, if different from the publisher." It then lists YouTube as valid use here. The problem that the subject in your example is also the publisher (a self-published work) which is why I nominated the article for deletion so long ago. Walter Görlitz (talk) 23:45, 12 July 2021 (UTC)[reply]
@Walter Görlitz: But we're using Template:Cite AV media, not Template:Cite web. I'm using a paragraph explaining "via" to prove my earlier point, "Name of the content deliverer (if different from publisher). via is not a replacement for publisher, but provides additional detail. It may be used when the content deliverer presents the source in a format other than the original (e.g. NewsBank), when the URL provided does not make clear the identity of the deliverer, where no URL or DOI is available (EBSCO), or if the deliverer requests attribution."
"via is not a replacement for publisher, but provides additional detail." – YouTube is the name of the publisher. Also, what you're failing to acknowledge is the en-dash separating "via" in the same sentence as the retrieval date; because of this, we can conclude that "via" is how the source was retrieved, not the name of the website/publisher. L33tm4n (talk) 01:15, 13 July 2021 (UTC)[reply]
And that's the wrong template even for that. That template is for physical media such as vinyl recordings, DVDs, etc. At best you should be using {{cite web}} for YouTube videos. Regardless, {{Cite AV media}} has the same criteria: via: name of the content deliverer. In short, Terreberry is the publisher, not YouTube. It does not matter one bit which template you use, the works are self-published and YouTube is simply the way the publisher is pushing the content to the planet.
PRIMARYCARE makes no claim to support your position. No template supports it. YouTube is not publishing anything, they are simply a medium that others use to publish works. Whenever YouTube is encountered as a source, it should be in the via= parameter. Walter Görlitz (talk) 01:54, 13 July 2021 (UTC)[reply]
@Kailash29792 Hi! I just added basic template data documentation for the "via" parameter (diff). It should start appearing in ProveIt in the next few hours (due to cache delays). Feel free to improve the documentation as you see fit! Sophivorus (talk) 15:16, 9 May 2022 (UTC)[reply]
This gadget should be used only in articles that do not have cited sources
Use of this gadget is creating strange, unnecessary changes to citation templates. It's screwing around with the order of parameters, capitalizing templates, adding quotation marks to refnames when under Template:Refname rules the marks are optional if a refname meets the specific guideline, and other alterations to citation templates that were not problematic beforehand. This gadget is a cosmetic tool that satisfies OCD editing, but nothing else. Pyxis Solitary(yak). L not Q. 09:20, 23 August 2021 (UTC)[reply]
Small bug
I noticed that this gadget attempted to change |author= into |last= and |contribution= into |chapter=. Per the documentation at {{cite book}}, these are not precisely the same. {{u|Sdkb}}talk08:40, 15 October 2021 (UTC)[reply]
I've run into the problem with |contrbution= and |chapter=, as well. Writing the foreword or introduction to another author's book calls for |contribution=; writing a chapter in an edited work calls for |chapter=. The two are definitely not the same and ProveIt should not make that substitution as |contributor= and its related parameters require |contribution= to be present, not |chapter=.
If proveit is renaming-parameters-just-to-rename-parameters, it should stop doing that. cs1|2 aliases are there primarily for user convenience, context, and semantics; |author=Jon Smyth is not the same as |last=Jon Smyth so changing the former to the latter is semantically incorrect and proveit should not make that kind of a change. An author's 'contribution' to an edited work may be stated in |contribution= or in |chapter= or in |entry= or in |article= or in |section=; the choice of which of these to use is the prerogative of the en.wiki editor who writes the citation; proveit should not arbitrarily override the en.wiki editor's choice of parameter name. In the specific case of |contributor= and |contribution= the former requires the latter so proveit renaming-parameters-just-to-rename-parameters breaks these citations.
I suspect that this-parameter-requires-this-other-parameter is not functionality supported by templatedata. If it does not, then it is proveit that needs fixing (which is not to say that templatedata shouldn't also be fixed...).
At first glance (literally, my first look at TemplateData of any kind), there is something strange in the notes as it says, "For the contribution alias, see contributor-last", but "contributor-last" is never mentioned on the page. I don't know why "contribution" is mentioned as an alias of "chapter as it functions entirely differently than "chapter" does. It really functions more like "others" than it does "chapter" except that it must be paired with "contributor" or its component parts "contributor-last" and "contributor-first". In the long run, it could be that "contribution" and "contributor" should just be folded into "others" or vice versa. Xenophore; talk18:47, 13 May 2022 (UTC)[reply]
Apostrophes in ref names
I frequently use the Normalize references feature, and for a while now I have been noticing that ProveIt has a problem with apostrophes in named references. Basically, if a ref name contains an apostrophe, for example <ref name="T'Challa">, hitting Normalize references will inadvertently convert it to <ref name="T">, omitting any text after the '. Does anyone know how to fix this? InfiniteNexus (talk) 05:53, 9 April 2022 (UTC)[reply]
This could be fixed using this regex: <\s*ref[^n]*name\s*=\s*(["'])((?:(?!\1).)*)\1?[^>]*> but the match goes to the second group, so the other line has to be: return match[ 2 ];, the explanation can be found here —Arthurfragoso (talk) 14:44, 21 May 2022 (UTC)[reply]
@Arthurfragoso Thanks! I tested your regex and it works fine except for cases where there's neither single nor double quotes, e.g. <ref name=Foo> which are valid and fairly common. I couldn't quite understand or fix your regex but if you're able to do so I'll be more than happy to deploy it, cheers! Sophivorus (talk) 13:36, 11 June 2022 (UTC)[reply]
@Sophivorus: First I found this solution: <\s*ref[^n]*name\s*=\s*(["'])?((?:(?!\1\W\D).)*)\1?[^>]*> It is short and clean, but it would not work for non-roman characters. Maybe there could be a way using conditionals in regex but I just ended up doing another way: <\s*ref[^n]*name\s*=\s*(?:(?:(["'])((?:(?!\1).)*)\1)|([^\s>]*))[^>]*>, when it has apostrophes it will be in group 2, when it does not, it will be in group 3. (so you can use return match[2] || match[3]; This regex will also work nice with <ref name=a group=b>, but not <ref name= group=b>. Also note that it will match with <ref name=""> and <ref name=> but not with <ref>. —Arthurfragoso (talk) 22:26, 13 June 2022 (UTC)[reply]
Yes please keep helping me in prove my page I allso need spell check much guid
Yes thank you for all the help that you are putting in to protecting and building me a good platform I need much guidance and and also a little warning more about trickery thank you I don't know what is Google platform of showing me when they pop in how do I stop them popping in or how do I know what is trickery and what ain't 172.58.99.242 (talk) 06:29, 21 May 2022 (UTC)[reply]
adding names to list of ProveIt users might be broken
I don't feel any need to be included in the category of ProveIt users, but I thought I'd let someone know that I've had the template on my user page for years and for whatever reason the code never picked up my name, which makes me wonder how many other users there might be, in addition to those who were listed in the category? I love the tool! Wish more people used it. NewsAndEventsGuy (talk) 18:03, 3 June 2022 (UTC)[reply]
@NewsAndEventsGuy Hi! The issue is that your user page redirects to your talk page, and the ProveIt userbox, like all other userboxes, only categorizes user pages. If you look, you'll notice that your other userboxes aren't categorizing you either. You can either create a user page distinct from your talk page, or keep your user page as a redirect but move your userboxes there, or forget all about this. Cheers! Sophivorus (talk) 00:33, 14 June 2022 (UTC)[reply]
@Matthewrb Hi, thanks for the report. Unfortunately disabling stuff from your common.js is not really possible right now because the gadget loads after your common.js. However, I simplified the logic of the gadget so that now it only adds a summary if there's no current summary. Hopefully, it shouldn't cause more trouble (the new version may take some minutes or hours to get through the cache). Cheers! Sophivorus (talk) 18:44, 26 August 2022 (UTC)[reply]
Hi, first off just wanted to say thanks for making this awesome gadget. I noticed two things though that might be helpful. First off, if loading from doi, the PMC parameter will be filled with the correct PMC number but will have PMC appended to the front of it. So if PMC ID is 5687451, then loading by doi will fill the PMC parameter with PMC5687451 (which will cause a minor maintenance error and the PMC external link won't work). If loading by PMID, everything works fine. But if you try loading by PMC ID number alone, it'll load data from the paper with that PMID; so with the previous example where PMC is 5687451, if you try to load based off that, it'll actually populate with the data from the paper whose PMID is 5687451. But if you punch in "PMC5687451", it'll load everything correctly, including PMC lol.
The other thing is the first name and last name parameter. If filling in the last name and first name parameter, it'll fill last= and first=. I've seen some bots go about tidying that up by changing it to last1= and first1=. All the subsequent fields work fine so if I manually filled in Last Name 2 with "Smith" in ProveIt, it'll be entered in wikitext as last2=Smith. I'm not entirely sure if it's a problem or not but just wanted to bring it up. Thanks again!! Jasonkwe (talk) (contribs) 01:45, 15 September 2022 (UTC)[reply]
Website error
Hello! Thanks for such a useful tool on this site. One site I frequently use with ProveIt is [1]. The site errors out now with the tool and it requires manual edits. What is odd that the same network has a site called Pro-Football-Reference.com, which works fine. Just wanted to see if anything could be done. Thanks. Red Director (talk) 18:26, 15 October 2022 (UTC)[reply]
Capitalising citation template names
Currently ProveIt capitalises the word cite in template names e.g. "Cite web" or "Cite book" however I think this should either be turned off or switched to lower case (At least for en wikipedia, I can't speak for the others). After all, the inbuilt RefToolbar most people now use to add references uses the lower case "cite" and the template documentations also list all the examples using the lower case "cite". – Mesidast (talk) 15:14, 5 January 2023 (UTC)[reply]
Normalisation doesn't work with Vector redesign.
Using the vector redesign, which is now the default on the english wikipedia: hitting the normalise button in proveit causes it to instead remove all the references that the gadget attempts to edit. I haven't tested the other features yet but I would be personally wary about doing so if normalisation is so obviously broken. - nathanielcwm (talk) 03:42, 24 January 2023 (UTC)[reply]
When you press the "normalise everything" button, it changes the parameters last1 and first1 to just last and first. I'm not sure whether this a bug or even if it means anything, but just incase I thought I'd mention it. greyzxqtalk19:41, 12 February 2023 (UTC)[reply]
Meaningless. |last= is an exact alias of |last1=. There is no benefit to making this change. And, there are other tools (User:Citation bot comes to mind) that change |last= to |last1= – also a meaningless change. Because the change is meaningless, this tool should stop making these changes.
When normalizing references with ProveIt, the |website= parameter is placed after |access-date= when using {{Cite web}}, but then |magazine= is moved to between |url-status= and |archive-url= when using {{Cite magazine}}, and for some reason |newspaper= is incorrectly converted to |work= and moved to between |title= and |url= when using {{Cite news}}. For consistency's sake, please consider having |website=, |magazine=, |newspaper=, |work=, |publisher=, |agency=, and all other aliases be placed after |access-date= on all citation templates. Thanks. InfiniteNexus (talk) 05:00, 24 February 2023 (UTC)[reply]
For the record: |website=, |magazine=, |newspaper=, and |work= along with |journal= are aliases of |periodical=. |agency= and |publisher= are not aliases of each other nor are they aliases of |periodical=.
cs1|2 does not care about the order of parameter placement in the wikitext of a template. For me, I think that |agency= should follow the author name-list in {{cite news}} templates; the periodical aliases should follow the |title= parameter in {{cite journal}}, {{cite magazine}}, {{cite web}} templates; and |publisher= (if present in periodical templates) should follow the periodical parameter or |location= in non-periodical templates. No doubt others think differently so no matter which ordering is chosen, someone will object so one has to wonder if attempting to 'fix' the OP's complaint will be worth the effort.
I'm referring to web citations. If using {{Cite web}}, ProveIt uses {{Cite web |last= |first= |date= |title= |url= |url-status=live |archive-url= |archive-date= |access-date= |website=}}; if using {{Cite news}}, ProveIt uses {{Cite news |last= |first= |date= |title= |work= |url= |url-status=live |access-date= |archive-url= |archive-date=}}; if using {{Cite magazine}}, ProveIt uses {{Cite magazine |last= |first= |date= |title= |url= |url-status=live |magazine= |archive-url= |archive-date= |access-date=}}. That is terribly inconsistent. InfiniteNexus (talk) 18:02, 24 February 2023 (UTC)[reply]
In this test edit, the previous revision uses a consistent parameter order. You can see what happens when you click "Normalize references", which I thought was supposed to make all citations consistent. InfiniteNexus (talk) 18:04, 24 February 2023 (UTC)[reply]
@1AmNobody24 Hi! Well, it seems to me that the "website" parameter isn't required under all circumstances, so it shouldn't be marked as required and I just unmarked it. Proveit should catch up in a few minutes. Could you confirm is the error persistes then? Cheers! Sophivorus (talk) 11:24, 12 May 2023 (UTC)[reply]
Hi Sophivorus, 'Name of the website' isn't shown in bold anymore, but the CS1 Error still remains if I add the website. Should the status at Template:Cite_ssrn/doc#TemplateData be changed to optional instead of suggested, so it only shows up after hitting 'Show all fields'? Nobody (talk) 11:40, 12 May 2023 (UTC)[reply]
If you look at Template:Cite ssrn § TemplateData you will see a long list of error messages among which is |website= is not a valid parameter. {{cite ssrn}} does not support |website= so that parameter should not appear in the TemplateData. To avoid having my butt chewed (again) because I changed TemplateData, I wrote a Lua script to highlight errors in the TemplateData. The error messaging worked to fix the errors in the TemplateData of the big-four ({{cite book}}, {{cite journal}}, {{cite news}}, {{cite web}}) and many others. Some templates still lag behind. The thing to do is to fix the TemplateData but because of the aforementioned butt chewing, I shall not be the editor to make those fixes.
Hi Trappist, I went ahead and did this[2], which I suggested above: Should the status at Template:Cite_ssrn/doc#TemplateData be changed to optional instead of suggested, so it only shows up after hitting 'Show all fields
It works as intended for ProveIt so I would call this
This toggle appears behind the exact same location as the ProveIt toggle. Is there a way for the ProveIt toggle to shift to the left under Vector 2022? Aaron Liu (talk) 22:42, 14 June 2023 (UTC)[reply]
Thanks! Is there a way to change this so it is at its normal position when the button isn't there i.e. when the viewport is too small? Aaron Liu (talk) 20:55, 15 June 2023 (UTC)[reply]
@Aaron Liu Not sure what you mean, but perhaps something along the following lines:
I have been having problems using ProveIt and I am not sure why. When I select the [ProveIt] button in the bottom right place on my screen, I get a dialog box to add a reference or bibliography, but it doesn't show the list of citation templates and says [no template].
Every now and again, I will see a [reload] or [load] button above ProveIt. And if so, it sometimes fixes the issue.
At the moment, ProveIt or load function + ProveIt are working about 10% of the time. I tried using the classic ProveIt function, but that's not working at all. What can I do to fix it? Or is there a better option for formatting multiple kinds of citations?
I have appended &withJS=MediaWiki:Gadget-ProveIt.js&withCSS=MediaWiki:Gadget-ProveIt.css to Wikipedia URLs, and enabled and disabled ProveIt in preferences, but there is no change and appending &withJS=MediaWiki:Gadget-ProveIt.js&withCSS=MediaWiki:Gadget-ProveIt.css yields "Wikipedia does not have an article with this exact name". I have also tried to follow the instructions on the install page. Chamaemelum (talk) 23:41, 5 July 2023 (UTC)[reply]
@Chamaemelum If the problem is only with the first URL, then the cause may be that it's malformed. The &withJS=MediaWiki:Gadget:ProveIt.js&withCSS=MediaWiki:Gadget-ProveIt.css must follow some other query string parameter, such as action=edit when editing a page. See Query string#Structure for more. I just edited the documentation to clarify this, since it lent itself to confusion. Kind regards, Sophivorus (talk) 13:58, 7 July 2023 (UTC)[reply]
Thanks! Sorry about that. Interesting that it still doesn't show up automatically when I'm logged in with it installed, though. Chamaemelum (talk) 14:06, 7 July 2023 (UTC)[reply]
The ProveIt logo showed up in the bottom right-hand corner of my screen for the first time, and at the same time, it immediately froze the page and my computer kernel panicked, restarted twice, and froze an additional time. Really weird, but I guess that's just me. I have a standard, new computer and browser. Chamaemelum (talk) 23:54, 7 July 2023 (UTC)[reply]
I really like ProveIt, but I very often find the result fails validation in the cite template with
{{cite journal}}: Check date values in: |date= (help)
The ProveIt tool inserts a date like 2009-01, cite flunks it, so I have to manually edit to 2009-01-01.
Can ProveIt just put a valid date in? I always us DOI inputs, so the date is whatever the publisher offered, typically only a month not a day. Johnjbarton (talk) 17:20, 12 July 2023 (UTC)[reply]
Feature request: auto fetch data from web.archive API
As there is an option in the Automatic Reference field and the "Load" button, it would be great if there were something like a "Get latest web.archive data" button on front of the URL field. It could use their API as described at [3] to get the latest archive URL and date, it would be really helpful. :) — Arthurfragoso (talk) 10:52, 14 July 2023 (UTC)[reply]
I asked Claude AI to implement the changes, but I still had to do some manual changes. A bit hackish, but it works. Add the following code:
if (inputName === 'url') {
$button = $('<button>').text('getArchive');
$div.prepend($button);
$button.on('click', $input, function(event) {
$.getJSON('https://archive.org/wayback/available?url=' + encodeURIComponent(event.data.val()))
.done(function(data) {
// Check if archived
if (data.archived_snapshots.closest) {
// Get closest snapshot
var snapshot = data.archived_snapshots.closest;
var curstatus = $('#proveit [name=url-status]');
// Populate fields
if(!curstatus.val()) {
curstatus.val('live');
}
$('#proveit [name=archive-url]').val(snapshot.url.replace(/^http:\/\//, "https://"));
$('#proveit [name=archive-date]').val(snapshot.timestamp.slice(0, 8).replace(/(\d{4})(\d{2})(\d{2})/, '$1-$2-$3'));
} else {
alert('URL not archived');
}
})
.fail(function() {
alert('Error accessing Wayback Machine API');
});
});
}
just before the if ( paramData.type === 'date' ) {
@Arthurfragoso Hi! I just implemented an Archive button based on your code. Unfortunately your code makes several assumptions about the names of parameters and only works for the English Wikipedia, so I had to modify it to make it cross-wiki, which for now means it only shows you the archived URL and you have to copy it to the appropriate field. But it's way better than nothing and at least it works for all wikis. Sophivorus (talk) 14:59, 20 July 2023 (UTC)[reply]
If this tool works for {{cite book}} then, if we apply the same wikilink 'trick', this tool should also work for {{cite map}}. Seems to me that the correct 'fix' here is to make {{cite map}} like {{cite book}}. Someone who uses this tool should make that test and report back.
ok i did it to match {{cite map}} like {{cite book}} - it had been a while since I'd edited doc pages when I made the edit request and I was a bit rusty. Right now it's still saying "no template data," but iirc it's pretty typical for changes to need time to propagate through the wiki before it can be tested. -Furicorn (talk) 04:04, 25 November 2023 (UTC)[reply]
@ActivelyDisinterested I think not. I just tried editing the old version of the article and editing the reference with ProveIt, and the date disambiguation was preserved. Thus, I think its removal was a mistake by the editor, rather than ProveIt. Sophivorus (talk) 13:41, 4 October 2023 (UTC)[reply]
I am once again asking for {{Cite magazine}} and {{Cite news}} to place |magazine= and |newspaper= after |access-date=, as {{Cite web}} currently does with |website= and |publisher=. This is the only parameter whose placement ProveIt is inconsistent with when normalizing references. InfiniteNexus (talk) 22:39, 19 November 2023 (UTC)[reply]
Will ProveIt allow an editor to publish an edit using it if the only function it is performing is the reordering of template parameters? This would seem to violate WP:COSMETICBOT if so. I've seen it come close: in this diff, it reorders some template parameters while misparameterising two values, doing nothing constructive.A follow up thread related to the OP here is active at Help talk:Citation Style 1#Consistency in parameter order, should the maintainers wish to engage. Happy Friday, Folly Mox (talk) 11:49, 24 November 2023 (UTC)[reply]
I'd gently suggest that disabling the functionality to publish edits that solely reorder parameters be incorporated into future builds. Not all editors using the gadget will be familiar with bot policy, and it seems safer to prevent that behaviour in the software than to course-correct editors through education. Folly Mox (talk) 12:23, 24 November 2023 (UTC)[reply]
.svg){kind=small}
Resolved
