This is an archive of past discussions about MediaWiki:RefToolbar.js. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
{{editprotected}}
Came across a bug upon porting to Norwegian Wikipedia. According to Wikipedia:RefToolbar_2.0#Autofilling the script checks for three different situations for inserting authors, but currently only the first works. The problem is that ($j('.classname')) always evaluates as true, even if no objects with such a class exists, since an empty array also evaluates as true. There was also a mixup of the variables i and j. And third, I switched from colon to semicolon to separate multiple authors.
Not done Not happy about adding just a small lump of code to a big page (miss one bracket and it all goes very wrong), and what's with these "@@ -498,10 +498,10 @@" - are they really required? I've never seen those before in js. I've made a full copy of the main page at MediaWiki talk:RefToolbar.js/sandbox - please edit that, then we can just do a block copy and replace. Much safer. Ronhjones (Talk)21:24, 1 May 2012 (UTC)
The above is a diff, of similar style to those seen at rev: (for example rev:115083 which shows a one-line change to a .js file). The "@@ -498,10 +498,10 @@" are not code to add, but line number indicators. There are three of them, so there are three chunks of code to amend. This is the third such, so the third amendment consists of leaving lines up to and including line 498 alone, and making amendments to the next ten. The lines to remove are those preceded by a minus and shown in red, whilst those to add are preceded by a plus and shown in green. Lines where there is no change have neither a plus nor a minus and are shown in black. So, the existing code that looks like this:
Ok, here is a diff to the sandbox. The changes are:
length is needed, since jQuery returns an empty array when a DOM element doesn't exist, and that evaluates to True.
fixing mixup of is and js in the loop
authors separated by semicolon, since first and lastnames are separated by ordinary colon.
None of the changes should be visible on English Wikipedia with the current configuration (which is probably why they haven't been fixed before). – Danmichaelo (talk)07:48, 2 May 2012 (UTC)
Thanks for the bug fixes! I've implemented the changes as requested. Please test it out and let me know if it's working for you. Kaldari (talk) 07:58, 2 May 2012 (UTC)
In the code, there are 2 different lines '$j('.'+cl+'coauthors').val(coauthors.join(', '));'. Are you sure I should only change one of them? Kaldari (talk) 18:08, 2 May 2012 (UTC)
This is one of the great tools on Wikipedia. I was recently reading {{Cite/doc}} and an idea for an improvement occurred to me. First, the "coauthors" parameters is deprecated yet the RefToolbar is still encouraging people too use it. The rational for the deprecation is that coauthors are already covered by author1, author2, and so on. This seems sound reasoning to me. I use the Reftoolbar a lot and of the inconviences is having to cite multiple authors. Here's my idea. Have a small clickable "add additional author" link below the "last" and "first" fields. Upon clicking of this link it adds boxes for the next author! For example, the first click would add fields for "last2" and "first2". Another click would add fields for "last3" and "first3". The size of the form would grow with each click but that's okay. The script would have to be smart enough to know to stop at the maximum number of authors, of course. To somebody's whose javascript-foo is sharp, this should be a very easy modification. It adds needed functionality while fixing a deprecation issue. Comments? Jason Quinn (talk) 02:42, 23 August 2012 (UTC)
The following are usability improvment ideas for the cite template entry forms in the Reftoolbar 2.0b:
General comments
The url and accessdate parameters are partners. They should be adjacent in all the cite forms. My opinion is that having the url field on the left and the accessdate field on the right makes the most sense.
The page, pages, and quote parameters are a logical group. They should all be adjacent.
Clicking "Show/hide extra fields" should append the extra fields. Currently the extra fields get inserted before the ref name and ref group fields. This unnecessary makes the UI more confusing for no added benefit.
All the forms need more tooltips, especially for the potentially confusing template parameters
The title field is generally the most important, even more important than authors. It should appear on the top of the form. Since titles can be long, I think it should span both columns of the form; in other words, it should be on its own line. This applies to all the forms.
I am a strong believer that mw:Reference Tooltips is giant leap forward in usability of references in articles. It's the future. The "quote" parameter becomes amazing useful in conjunction with it. The quote parameter has been under-utilized on Wikipedia cite templates. It needs to be emphasized more. It should not be buried away as a hidden field by default. Also like with the title parameter, I think it deserves the single-line column spanning treatment (since quotes can be long).
Cite Web form
The "extra" fields show deprecated coauthors parameter
Why is their not date field in the default form? That seems very important to me, especially for a web cite. There's only accessdate.
title is a mandatory field. Why is this? Why do none of the other forms have mandatory fields? Should there be?
Cite book
another coauthors usage
Cite journal
another coauthors usage
These are just a few thoughts. All these things should be very easy to change. I think it would make the forms much more user friendly. Jason Quinn (talk) 23:12, 26 September 2012 (UTC)
Error: mw.usability is undefined
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
Please check the dependencies used by this (default) gadget, because the line
Actually mw.usability doesn't even exist anymore. Should be mw.messages these days I think. Anyway, I think I fixed it by properly setting the dependency between reftoolbar base (which defines mw.usability ) and the other modules. See this edit. —TheDJ (talk • contribs) 09:55, 9 October 2012 (UTC)
Now it changed to Uncaught Error: Unknown dependency: reftoolbar-base, caused by this call to mw.loader.using
// Enhanced editing toolbar is on with dialogs. Load standard refToolbar.
mw.loader.using( ['ext.wikiEditor.toolbar', 'reftoolbar-base'] , function () {
I reverted. Would have been nice if someone else had done so..... OK, i can't fix this right now, it's inherently broken because the dependencies are not declared, and if that change of mine doesn't work, then I don't know how to do that properly. —TheDJ (talk • contribs) 19:14, 9 October 2012 (UTC)
Ok, we have:
MediaWiki:Common.js, which is loaded by default and whose content is currently wrapped with mw.loader.using( 'mediawiki.util', ...)
Who considers themselves maintainers of this extension? Are there any official WMF maintainers? I have many ideas for how it could be improved — some of which I've posted above — that should be extremely easy for somebody who's familiar with the codebase. Maybe here isn't the best place to propose them. My ideas not have received any replies except for Redrose's supportive comment. Is there a better place to suggest them? If the WMF isn't directly involved with its maintenance, why not? It seems like a very high reward-to-effort project. Jason Quinn (talk) 21:01, 21 November 2012 (UTC)
The current way to add locales is wrong. It should be better to use a HotCat-like model, with a local defaults page. --Locosepraix03:09, 25 March 2012 (UTC)
Another issue is that the messages are bound to closely to the field names. We have localised Template:cite web into no:Kilde www with Norwegian field names. For instance accessdate is besøksdato. Then a double set of messages is needed:
Please see MediaWiki_talk:RefToolbar.js#Portuguese_translation for a similar discussion regarding Portuguese. I think the Norwegian request can be fulfilled similarly. The suggestion is to generalize the default to use the default langauge of the wiki, which solves the concern of Locos. Danmichaelo's concern about the doubled field names however is not solved currently but could be at a future date. Jason Quinn (talk) 03:10, 10 February 2013 (UTC)
CiteTB.getQuotedString useless substitute line
The function object CiteTB.getQuotedString
// Returns a string quoted as necessary for name/group attributesCiteTB.getQuotedString=function(s){varsp=/\s/.test(s);// spacesvarsq=/\'/.test(s);// single quotesvardq=/\"/.test(s);// double quotesif(!sp&&!sq&&!dq){// No quotes necessaryreturns;}elseif(!dq){// Can use double quotesreturn'"'+s+'"';}elseif(!sq){// Can use single quotesreturn"'"+s+"'";}else{// Has double and single quotess=s.replace(/\"/g,'\"');return'"'+s+'"';}}
has a bug in the "else" section. The function's purpose is to put quotes around certain strings when they are necessary for that string to be used as the value of an HTML parameter. The line s = s.replace(/\"/g, '\"'); does a global search-n-replace but it replaces double quotes with double quotes. It appears that single quotes were intended for the search instead of double quotes. (Alternatively, double quotes could be replaced with single quotes.) [This function is easily tested by typing into the "ref name" field of one of the cite templates. Doing this you easily see that typing a mixture of single and double quotes can mess up the quoting on the generated reference string.] A fix might be to replace single quotes (aka apostrophes) with the HTML apostrophe code "'" although that's really ugly. Another workaround might be s = s.replace(/\'/g, '\"'); but this changes what the user entered. The most conservative change would be to simply comment the line out. I intend to implement choose one of these choices (probably replace single quote with double) and implement it if no comments are given. Jason Quinn (talk) 03:41, 10 February 2013 (UTC)
Portuguese translation
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The result on English Wikipedia (and other English wikis) will be the same, but it will default to the content language for non-English wikis, which makes more sense (see also #Provisions for Norwegian above). Helder13:39, 6 February 2013 (UTC)
Hi, Helder. I believe you wish the relevant section of code to be changed to look like the following:
switch(wgUserLanguage){case'de':// GermanvarRefToolbarMessages=importScript('MediaWiki:RefToolbarMessages-de.js');break;case'en':// EnglishvarRefToolbarMessages=importScript('MediaWiki:RefToolbarMessages-en.js');break;case'pt':// PortuguesevarRefToolbarMessages=importScript('MediaWiki:RefToolbarMessages-pt.js');break;default:// default language of wikivarRefToolbarMessages=importScript('MediaWiki:RefToolbarMessages-'+mw.config.get('wgContentLanguage')+'.js');}
The snippet has three changes: the generalization you mention, the edition of an explicit "en" case, and the edition of an explicit "pt" case. This will require me to create MediaWiki:RefToolbarMessages-pt.js here at the English Wikipedia, which I will copy from the pt:MediaWiki:RefToolbarMessages-en.js (which, despite the name is currently in Portuguese). Please confirm that this is what you are asking to be done and discuss your thoughts on the new code. At the present I am slowly digesting how the Reftoolbar works globally. Forgive me if I move slowly on this even after you confirm. I just got my ability to edit protected pages so I wish to make sure I don't screw anything up on my first tries. Jason Quinn (talk) 05:40, 8 February 2013 (UTC)
The language preferences dropdown box on the English Wikipedia suggests that the Brazilian Portuguese language code is "pt-BR" instead of "pt-br". Agree?
varRefToolbarMessages;switch(wgUserLanguage){case'de':// GermanRefToolbarMessages=importScript('MediaWiki:RefToolbarMessages-de.js');break;case'pt':// Portuguesecase'pt-BR':// Brazilian PortugueseRefToolbarMessages=importScript('MediaWiki:RefToolbarMessages-pt.js');break;default:// default language of wikiRefToolbarMessages=importScript('MediaWiki:RefToolbarMessages-'+mw.config.get('wgContentLanguage')+'.js');}
I like your code suggestion and will make the change after you comment about the language code and there's been a little while for others to comment. Jason Quinn (talk) 02:43, 10 February 2013 (UTC)
I just noticed there's a very similar discussion about Norwegian above. I have contacted those people to let them know that some changes may be made on this. Might as well add Norwegian too while we are at it. Jason Quinn (talk) 03:16, 10 February 2013 (UTC)
Here the code has to be "pt-br" instead of "pt-BR" because it need to match the value from wgUserLanguage.
I was thinking, we could try to keep the code small even if we add more translations in the future:
This way, the only thing needed when a new translation is available is to add a new pair of language codes.
As an aside, when the script is used in other wikis, and the user language is one of those listed in this enwiki page (either in the switch or the langMap version), it will load "translations" pages, but these may not be available for the wiki's customized version. Helder10:58, 10 February 2013 (UTC)
Ideally, we could test if the import script fails, which would make the code much better and more portable. First we'd test the wgUserLanguage import, if it fails we'd test the default wiki language import, if that fails, we'd use English, whose MediaWiki:RefToolbarMessages-en.js file we will require for all ports. Do you know if there's a way to do this? The "importScript" command is apparently a Mediawiki command. My practical experience with the javascripts on Wikipedia is just beginning. Jason Quinn (talk) 20:22, 10 February 2013 (UTC)
The importScript call is not cheap, so we should do as few of these as possibly (ideally, none, but this would require Gadgets 2.0, which is expected to come with support for MediaWiki messages for i18n).
What do you mean by "we will require [the MediaWiki:RefToolbarMessages-en.js file] for all ports"? The pt and nb ports can't use enwiki's MediaWiki:RefToolbarMessages-en.js, because the template parameters differ from wiki to wiki, and as Wizardist said in the other thread, "the messages are [currently] bound to[o] closely to the field names". Helder21:25, 10 February 2013 (UTC)
I've marked this request as "answered", even though it hasn't really been answered. Please see my comment in #Migration above for my reasons and for further steps you can take to get your edits implemented. Best — Mr. Stradivarius♪ talk ♪08:33, 25 March 2013 (UTC)
Migration
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I've marked this request as "answered", although I know it hasn't actually been answered. It's almost two months since this request was made, and it has become painfully apparent that none of the admins who patrol CAT:EP are able to review JavaScript requests. So I think you will get a much better response if you simply ask an admin who knows JavaScript to make the edit for you. I did try and raise this on VPT, but I didn't receive a response. Sorry to have to make you jump through hoops like this, but I just can't think of any other useful way to get these requests answered. Three admins who you might ask are Jason Quinn (who has also commented below), Ruslik0, and Anomie if they are around. Or if you can get any users who aren't admins and who know JS to give the ok (Legoktm?), then you can ask me on my talk page and I will make the actual edit. Feel free to mark the request as unanswered again if you want - I won't revert you or anything - but I don't think it will actually have any effect. Best regards — Mr. Stradivarius♪ talk ♪08:33, 25 March 2013 (UTC)
Done, as no one answered in a while I took care of this now and updated the script according to the suggested code and JSHint - Hoo man (talk) 20:06, 4 April 2013 (UTC)
Help > Discussion throwing parse errro
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
The example given under "Help > Discussion" is throwing a parse error: "wikieditor-toolbar-help-content-signaturetimestamp-result: Parse error at position 19 in input" Jason Quinn (talk) 06:30, 2 October 2012 (UTC)
Is this resolved now? Is it related to discussion below? Unless there is a specific request, I can't really help you. So disabling for now. — Martin (MSGJ · talk) 17:48, 29 October 2012 (UTC)
No. It's still doing the same thing. It is not related to the discussion below. The specific request is self-explanatory: please fix the parse error. The error is easy to see under "Help > Discussion" and then look in the "What you get" section. Jason Quinn (talk) 06:03, 6 November 2012 (UTC)
Your request is not specific because it does not tell me how this error can be fixed. You could try posting at WP:VPT to see if anyone is familiar with this script. — Martin (MSGJ · talk) 10:14, 6 November 2012 (UTC)
As it turns out, this isn't a RefToolbar problem but a known WikiEditor issue. It is Bug 42107. At the time I wrote this I didn't realize that the Reftoolbar is just an additional button on WikiEditor. Jason Quinn (talk) 04:03, 12 May 2013 (UTC)
This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
I fixed one issue in the lookup.php script in which dates where the month/day weren't zero-padded to 2 digits didn't work. While working on that, I also noticed that some journals don't actually provide the full date with their DOI information, only giving year/month. So JS assumes you're referring to the first of the month. Now this needs to be modified to support using year/month when the full date isn't available. I've already made the fixes to lookup.php, and kept it backwards compatible for caching. You can see the new output here - [1]. I think the new end of CiteTB.autoFill should look like this:
if(type==='pmid'||type==='doi'){if(type==='doi'&&data.fulldate){varDT=newDate(data.date);$('.'+cl+'date').val(CiteTB.formatDate(DT));}elseif(type==='doi'&&!data.fulldate){if(data.month){// lookup.php sets month to false if it isn't provided$('.'+cl+'month').val(CiteTB.getOption('months')[parseInt(data.month)]);}$('.'+cl+'year').val(data.year);}else{$('.'+cl+'date').val(data.date);}$('.'+cl+'journal').val(data.journal);$('.'+cl+'volume').val(data.volume);$('.'+cl+'issue').val(data.issue);$('.'+cl+'pages').val(data.pages);}elseif(type==='isbn'){$('.'+cl+'publisher').val(data.publisher);$('.'+cl+'location').val(data.location);$('.'+cl+'year').val(data.year);$('.'+cl+'edition').val(data.edition);}};
This should set month/year if fulldate is false, otherwise set date. I'd just like to have some other eyes on the code for this to make sure nothing is broken. I may also fix the PMID autofiller too in the future. Mr.Z-man19:59, 12 October 2013 (UTC)
Thanks for doing this. I'm not sure if any of the admins who patrol CAT:EP are familiar with java script, so using the {{editprotected}} is perhaps not the best way to attract attention! Can you ask someone to help with this? — Martin (MSGJ · talk) 10:01, 14 October 2013 (UTC)
(results from using an incorrect ISBN and using autofill). Also, Firefox Dev Toolbar seems to think that each autofill uses four asynchronous requests in an old version of Firefox 15, but I can't recreate on a newer version. - Jarry1250[Vacationneeded]15:42, 15 November 2013 (UTC)
Insertion of blank / wikEd compatibility
The cite-form-submit function currently adds a blank after the template by using a preceding 'peri' addition (showing only one of two places in the code):
This breaks compatibility with wikEd and is a rather strange way to add the blank ('peri' is for example/prefilled text added at cursor position that gets selected). I would like to change the code so that the space is added by a 'pre' call after template addition. I have tested it and it positions the cursor exactly the same position:
Actually, I have no idea why this space has to be added in the first place. It usually has to be removed manually. Also, none of the other toolbar buttons adds blanks after inserted code. Therefore, I suggest to remove the blank addition altogether. Mr.Z-man, KaldariJason Quinn: are you OK with that? Cacycle (talk) 13:23, 7 May 2014 (UTC)
(copied from enwp -- not sure of the best place to report)
Hi,
If you go to extra fields in cite book, and try to add the "article=" field, it changes it to "authorlink1" instead on rendering. These are two very different things :) -- phoebe / (talk to me) 05:34, 8 September 2014 (UTC)
RefToolbar.js does not show any citation templates due to TypeError
Quotes are optional if the only characters used are letters A–Z, a–z, digits 0–9 and the symbols !$%&()*,-.:;<@[]^_`{|}~
Inclusion of any other characters, including spaces, requires that the name be enclosed in double straight quotes (")
CiteTB.getQuotedString only checks for spaces, single quotes and double quotes.
Confusingly, it appears that with disallowed characters like é, the original ref definition works without quotes but the ref can only be reused if the original definition and reuse both have quotes. See examples below. Cite errors are not displayed in MediaWiki talk. Copy it elsewhere to see the error messages. PrimeHunter (talk) 10:45, 1 June 2014 (UTC)
<ref name=Linné>{{cite book||title=This ref has name=Linné and can be displayed but not reused}}</ref>:
[1]
There have been three threads raised at WP talk page here and here and here.
Will not autofill using pmid parameter anymore. Only works with doi. Can this be fixed please? Super valuable tool; i really miss this. Thanks. Jytdog (talk) 21:20, 15 November 2016 (UTC)
When using the Grammarly Extension, the reference tool bar does not work properly. The pull down menu is hidden behind the text box. Can this be fixed?
One disadvantage of RefToolbar is that it currently only supports the default CS1 author format (|first1=, |last1=, ...). Many science related articles in contrast use Vancouver system formatted authors. These were previously specified by the deprecated|author(s)= parameter that is systematically being replaced with |vauthors= (currently used in 41,574 articles). If RefToolbar is used to insert citations into an article that already uses |vauthors=, an inconsistent citation style is introduced which is contrary to WP:CITEVAR. Hence I would like to request that an vauthors option be added to RefToolbar. This should be straight forward to implement if the PMID is used for autofilling as RefToolbar is already returning Vancouver style first name initials from the PubMed database. Boghog (talk) 02:37, 27 December 2016 (UTC)
I would like to request an additional feature with RefToolbar. In the Web Citation popover, can we please have a checkbox (or a select menu) to specify url-status=dead/live? I can fill in Archive URL and Archive Date in the form, but after I have inserted the reference into the article, I have to go in and type the "deadurl" bit manually, which is a bit fiddly.
This is the 5th time I have requested this, so I would really appreciate an answer - if it is possible of not, and if someone is able add this feature. Thank you. Cnbrb (talk) 14:00, 19 September 2019 (UTC)
I then decided nobody was interested so I posted the request on the Village Pump technical (totally ignored)
I tried again on the Reftoolbar talk page 2 weeks ago (got no reply)
then followed the instruction on the Village Pump to post feature requests on Phabricator, and posted my feature request on Phabricator; I was politely told that I shouldn't post feature requests on Phabricator but on the Wikipedia talk page.
...and now I am trying my luck here as it seems Reftoolbar enjoys two talk separate talk pages. Maybe today will be my lucky day? Cnbrb (talk) 21:58, 19 September 2019 (UTC)
It's been a month now. Would anyone please like to do me the courtesy of replying?
🔲 Yes it can be done
🔲 No it can't be done
🔲 Thanks for your constructive idea, we'll give it some thought
20:36, 21 October 2019 (UTC)
Live footage of Wikipedia talk page activityUpdate 12:15, 31 October 2019 (UTC) — I see that, after years of me requesting this, someone has finally added a Url-status field to the citation popoup. My preference would have been for a radio button/checkbox interface, but I guess I can't be too picky. I do not know who to thank for this, but whoever did it, THANK YOU. It's a pity nobody has been prepared to acknowledge a reasonable feature request on the various talk pages, but I'm glad it's done at last. Cnbrb (talk) 12:15, 31 October 2019 (UTC)
Not done Not happy about adding just a small lump of code to a big page (miss one bracket and it all goes very wrong), and what's with these "@@ -498,10 +498,10 @@" - are they really required? I've never seen those before in js. I've made a full copy of the main page at MediaWiki talk:RefToolbar.js/sandbox - please edit that, then we can just do a block copy and replace. Much safer. Ronhjones (Talk) 21:24, 1 May 2012 (UTC)
Done, as no one answered in a while I took care of this now and updated the script according to the suggested code and JSHint - Hoo man (talk) 20:06, 4 April 2013 (UTC)
Not done: I don't see that word here. I did fix MediaWiki:RefToolbarMessages-en.js because of your note at MediaWiki talk:RefToolbarMessages-en.js#Edit request on 7 October 2013 - did you post the same problem twice in error? --Redrose64 (talk) 11:41, 7 October 2013 (UTC)
Done. — Mr. Stradivarius ♪ talk ♪ 14:12, 7 October 2013 (UTC)
