MediaWiki talk:RefToolbar.js/Archive 1

Archive 1

Bugfix for autofilling of authors

{{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.

--- MediaWiki-RefToolbar.js	2012-03-26 16:59:47.000000000 +0200
+++ MediaWiki-RefToolbar2.js	2012-03-26 17:37:53.000000000 +0200
@@ -469,7 +469,7 @@
 CiteTB.autoFill = function(data, template, type) {
   var cl = 'cite-'+template+'-';
   $j('.'+cl+'title').val(data.title);
-  if ($j('.'+cl+'last1')) {
+  if ($j('.'+cl+'last1').length != 0) {
     for(var i=0; i<data.authors.length; i++) {
 	  if ($j('.'+cl+'last'+(i+1)).length) {
 	     $j('.'+cl+'last'+(i+1)).val(data.authors[i][0]);
@@ -483,7 +483,7 @@
 		break;
 	  }
 	}
-  } else if($j('.'+cl+'author1')) {
+  } else if($j('.'+cl+'author1').length != 0) {
     for(var i=0; i<data.authors.length; i++) {
 	  if ($j('.'+cl+'author'+(i+1)).length) {
 	     $j('.'+cl+'author'+(i+1)).val(data.authors[i].join(', '));
@@ -498,10 +498,10 @@
 	}
   } else {
     var authors = [];
-	for(var i=0; j<data.authors.length; j++) {
-	  authors.push(data.authors[j].join(', '));
+	for(var i=0; i<data.authors.length; i++) {
+	  authors.push(data.authors[i].join(', '));
 	}
-	$j('.'+cl+'authors').val(authors.join(', '));
+	$j('.'+cl+'authors').val(authors.join('; '));
   }  
   if (type == 'pmid' || type == 'doi') {
     if (type == 'doi') {

I've tested the diff locally on nowp, and it should work fine. – Danmichaelo (talk) 15:46, 26 March 2012 (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)

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:

 	}
   } else {
     var authors = [];
	for(var i=0; j<data.authors.length; j++) {
	  authors.push(data.authors[j].join(', '));
 	}
	$j('.'+cl+'authors').val(authors.join(', '));
   }  
   if (type == 'pmid' || type == 'doi') {
     if (type == 'doi') {

is to become:

 	}
   } else {
     var authors = [];
	for(var i=0; i<data.authors.length; i++) {
	  authors.push(data.authors[i].join(', '));
 	}
	$j('.'+cl+'authors').val(authors.join('; '));
   }  
   if (type == 'pmid' || type == 'doi') {
     if (type == 'doi') {

--Redrose64 (talk) 21:50, 1 May 2012 (UTC)

Ok, here is a diff to the sandbox. The changes are:

1. length is needed, since jQuery returns an empty array when a DOM element doesn't exist, and that evaluates to True.
2. fixing mixup of is and js in the loop
3. 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)

Thanks Kaldari. Forgot one semicolon (sandbox diff) to make it à jour with my local version. – Danmichaelo (talk) 08:15, 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)

Sorry, didn't notice the other one. Yes, both should be changed. – Danmichaelo (talk) 10:39, 3 May 2012 (UTC)

Done. Kaldari (talk) 05:50, 11 May 2012 (UTC)

Ideas for improvement

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)

|coauthors= is described as deprecated, but using it will not put the page into Category:Pages containing cite templates with deprecated parameters. Anyway, I do like the "add additional author" proposal. --Redrose64 (talk) 08:27, 23 August 2012 (UTC)

Tweaks to make tool better

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

Please check the dependencies used by this (default) gadget, because the line

mw.usability.addMessages( { 

from MediaWiki:RefToolbarMessages-en.js is causing the following error on Google Chrome 22.0.1229.79:

That code should not be executed if mw.usability is not defined. Helder 12:10, 8 October 2012 (UTC)

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 , 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 () {

Helder 15:42, 9 October 2012 (UTC)

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', ...)
• When the user is in edit/submit mode, common.js loads MediaWiki:Common.js/edit.js.
• There, we have on document ready:
  • Some calls to mw.user.options.get, but it should explicitly require the module user.options where this is defined
  • A command importScriptURI to get the code from MediaWiki:Gadget-refToolbarBase.js, where mw.usability will be defined.

I don't remember if importScriptURI is asynchronous, but if it is, the script MediaWiki:RefToolbar.js (which uses mw.usability and also load MediaWiki:RefToolbarMessages-en.js), NoDialogs.js & Legacy.js should be loaded inside of a callback (for this, importScriptURI could be replaced by $.getScript(url, callback);, because mw.loader.load doesn't accept a callback)

Helder 00:34, 10 October 2012 (UTC)

Maintainers? WMF involved?

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)

A look at the history shows it was made by User:Kaldari - why not drop them a note at User talk:Kaldari 00:38, 23 November 2012 (UTC)

Provisions for Norwegian

Can you add provisions for Norwegian to the script? Code can be something like:

// Load local data - messages, cite templates, etc.
$j(document).ready( function() {
  switch( wgUserLanguage ) {
    case 'de': // German
      var RefToolbarMessages = importScript('MediaWiki:RefToolbarMessages-de.js');
      break;
    case 'no': // Norwegian
    case 'nb': // Norwegian Bokmål
      var RefToolbarMessages = importScript('MediaWiki:RefToolbarMessages-nb.js');
      break;
    default: // English
      var RefToolbarMessages = importScript('MediaWiki:RefToolbarMessages-en.js');
  }
});

An unfinished Norwegian message version is at no:MediaWiki:RefToolbarMessages-nb.js and can probably also be maintained there. ZorroIII (talk) 20:42, 23 March 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. --Locos epraix 03:09, 25 March 2012 (UTC)

Agree. So far, as a workaround, we've made no:MediaWiki:RefToolbarMessages-en.js act as a local defaults, but that's not very elegant :) – Danmichaelo (talk) 17:08, 26 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:

1. en:MediaWiki:RefToolbarMessages-en.js : 'cite-accessdate-label' : 'Access date'
2. en:MediaWiki:RefToolbarMessages-no.js : 'cite-accessdate-label' : 'Besøksdato'
3. no:MediaWiki:RefToolbarMessages-en.js : 'cite-besøksdato-label' : 'Access date'
4. no:MediaWiki:RefToolbarMessages-no.js : 'cite-besøksdato-label' : 'Besøksdato'

So there should ideally be some way to specify local field names as well, say, fields['accessdate'] = besøksdato. – Danmichaelo (talk) 17:08, 26 March 2012 (UTC)

May anyone provide update upon the subject? Wizardist (talk) 23:33, 8 January 2013 (UTC)

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 attributes
CiteTB.getQuotedString = function(s) {
  var sp = /\s/.test(s); // spaces
  var sq = /\'/.test(s); // single quotes
  var dq = /\"/.test(s); // double quotes
  if (!sp && !sq && !dq) { // No quotes necessary
    return s;
  } else if (!dq) { // Can use double quotes
    return '"'+s+'"';
  } else if (!sq) { // Can use single quotes
    return "'"+s+"'";
  } else { // Has double and single quotes
    s = 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

As suggested on Wikipedia talk:RefToolbar/2.0/Archive 2#Ported to portuguese, please add Portuguese translations from pt:MediaWiki:RefToolbarMessages-pt.js. Helder 12:37, 6 February 2013 (UTC)

BTW: Since the documentation recomends copying Wikipedia:RefToolbar/2.0/porting when porting the script to another wiki, and that script loads MediaWiki:RefToolbar.js from enwiki (not a local copy), please change

'MediaWiki:RefToolbarMessages-en.js'

to

'MediaWiki:RefToolbarMessages-' + mw.config.get( 'wgContentLanguage' ) + '.js'

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). Helder 13: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': // German
      var RefToolbarMessages = importScript('MediaWiki:RefToolbarMessages-de.js');
      break;
    case 'en': // English
      var RefToolbarMessages = importScript('MediaWiki:RefToolbarMessages-en.js');
      break;
    case 'pt': // Portuguese
      var RefToolbarMessages = importScript('MediaWiki:RefToolbarMessages-pt.js');
      break;
    default: // default language of wiki
      var RefToolbarMessages = 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)

I think the code can be improved as in this new version I copied to the sandbox. Besides, the code at ptwiki has changed a little, since we configured it for use with the Portuguese templates, so you should take the translation from sandbox instead of pt:MediaWiki:RefToolbarMessages-en.js (but the credit for the translation still goes to GoEThe) . Helder 13:39, 9 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?

var RefToolbarMessages;
switch( wgUserLanguage ) {
    case 'de': // German
        RefToolbarMessages = importScript('MediaWiki:RefToolbarMessages-de.js');
        break;
    case 'pt': // Portuguese
    case 'pt-BR': // Brazilian Portuguese
        RefToolbarMessages = importScript('MediaWiki:RefToolbarMessages-pt.js');
        break;
    default: // default language of wiki
        RefToolbarMessages = 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:

var langMap = {
        'de': 'de', // German
        'pt': 'pt', // Portuguese
        'pt-br': 'pt', // Brazilian Portuguese
        'nb': 'nb', // Norwegian Bokmål
        'no': 'nb', // Norwegian
    }[ mw.config.get('wgUserLanguage') ] || mw.config.get('wgContentLanguage'),
    RefToolbarMessages = importScript('MediaWiki:RefToolbarMessages-' + langMap + '.js');

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. Helder 10: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". Helder 21:25, 10 February 2013 (UTC)

This bug also affects the Galician Wikipedia: Wikipedia talk:RefToolbar#Gadget not working on gl.wikipedia. Helder 13:14, 17 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

Could someone apply these changes to the code? Helder 17:20, 21 January 2013 (UTC)

Please don't use mediaWiki.util without declaring it as dependency somehow. - Hoo man (talk) 19:19, 21 January 2013 (UTC)

Not done until you address Hoo man's comment. --Closedmouth (talk) 11:01, 30 January 2013 (UTC)

MediaWiki:RefToolbar.js is imported from MediaWiki:Common.js/edit.js, which is imported from MediaWiki:Common.js, and this already happens inside of a call to mw.loader.using( ['mediawiki.util', ... ), so this would not make any difference in this case. What would improve the situation is adding the missing dependency I suggested above (user.options). Helder 13:23, 30 January 2013 (UTC)

• 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

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)

Mutiple

Just a typo - "Mutiple refs are given the name" should be "Multiple" -- John of Reading (talk) 11:18, 7 October 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)

Sorry, I was trying to get MediaWiki:RefToolbarLocal.js fixed. I didn't notice that its talk page redirected here. -- John of Reading (talk) 12:45, 7 October 2013 (UTC)

Ok, Done. — Mr. Stradivarius ^{♪ talk ♪} 14:12, 7 October 2013 (UTC)

Date fix for DOI autofill

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) {
      var DT = new Date(data.date);
      $('.'+cl+'date').val(CiteTB.formatDate(DT));
    } else if (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);
  } else if (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-man 19: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)

Bug

TypeError: data.authors is undefined

https://en.wikipedia.org/w/index.php?title=MediaWiki:RefToolbar.js&action=raw&ctype=text/javascript Line 482

(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 ^{[Vacation needed]} 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):

        buttons: {
          'cite-form-submit': function() {
            $.wikiEditor.modules.toolbar.fn.doAction( $(this).data( 'context' ), {
              type: 'encapsulate',
              options: {
                peri: ' '
              }
            }, $(this) );
            var ref = CiteTB.getRef(false, true);
            $(this).dialog( 'close' );
            $.wikiEditor.modules.toolbar.fn.doAction( $(this).data( 'context' ), {
              type: 'encapsulate',
              options: {
                pre: ref
              }
            }, $(this) );
          },

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:

        buttons: {
          'cite-form-submit': function() {
            var ref = CiteTB.getRef(false, true);
            $(this).dialog( 'close' );
            $.wikiEditor.modules.toolbar.fn.doAction( $(this).data( 'context' ), {
              type: 'encapsulate',
              options: {
                pre: ref
              }
            }, $(this) );
            var ref = CiteTB.getRef(false, true);
            $(this).dialog( 'close' );
            $.wikiEditor.modules.toolbar.fn.doAction( $(this).data( 'context' ), {
              type: 'encapsulate',
              options: {
                pre: ' '
              }
            }, $(this) );
          },

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, Kaldari Jason Quinn: are you OK with that? Cacycle (talk) 13:23, 7 May 2014 (UTC)

I have implemented and tested the proposed change (see diff). Cacycle (talk) 13:37, 14 May 2014 (UTC)

author link bug

(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

Please see phab:T109781 for more information. Thanks! --AKlapper (WMF) (talk) 13:18, 21 August 2015 (UTC)

ref names needing quotes

This is based on a report at Wikipedia:Teahouse/Questions#Methinks there is a bug. WP:REFNAME says:

• 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>:

<ref name=Linné />.

<ref name="Linné" />.

<ref name="CarlLinné">{{cite book||title=This ref has name="CarlLinné" and can be reused}}</ref>.

<ref name="CarlLinné" />.

<ref name=CarlLinné />.

 Done, pls check--Ymblanter (talk) 11:07, 30 January 2016 (UTC)

Autofill for journals request - pmc

Could the autofills for journals also include pmc when it is available? Have to add that manually now. Thanks. Jytdog (talk) 21:27, 15 November 2016 (UTC)

Autofill for journals is broken

Tracked in Phabricator
Task T150821

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)

@Jytdog and Doc James:  Done, courtesy of Community Tech! Kaldari (talk) 02:05, 16 November 2016 (UTC)

Thanks!!!!!!!!!!!!!!!!!!!!!!! Jytdog (talk) 02:16, 16 November 2016 (UTC)

Perfect. The community tech team really rocks :-) Doc James (talk · contribs · email) 04:24, 16 November 2016 (UTC)

Issue with Grammarly Extension

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?

TheBigJagielka (talk) 15:55, 3 May 2017 (UTC)

Support for |vauthors=?

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 prefer that we not introduce multiple citation styles into RefToolbar. Kaldari (talk) 16:25, 3 May 2017 (UTC)

Broken JavaScript

MediaWiki developers found that this page probably breaks JavaScript for users (example: not seeing the buttons when editing a page). You probably need to edit this .js page and/or MediaWiki:Gadgets-definition as in the examples at phabricator:T122755. List more pages to check.

If you have questions or need help, please ask at phabricator:T164242. You can login with your wiki account. Best wishes, Nemo 09:49, 14 May 2017 (UTC)

I added "mediawiki.util" as an explicit dependency of the gadget. Kaldari (talk) 10:02, 14 May 2017 (UTC)

Self-closed HTML tags

The main page is appearing in Category:Pages using invalid self-closed HTML tags. This is due to one or more of the following:

<option />
<div id="cite-nref-preview-label" style="display:none;" />
<div id="cite-namedref-preview" style="padding:0.5em; font-size:110%" />
<span id="cite-parsed-label" style="display:none;" />
<div id="cite-namedref-parsed" style="padding-bottom:0.5em; font-size:110%" />
<a href="#" id="cite-nref-parse" style="margin:0 1em 0 1em; display:none; color:darkblue" />
<div id="cite-errorcheck-heading" />
<ul id='cite-errcheck-list' />
<table id="cite-err-report" style="width:100%; border:1px solid #A9A9A9; background-color:#FFEFD5; padding:0.25em; margin-top:0.5em" />
<tr style="width:100%" />
<th style="width:60%; font-size:110%" />
<th style="text-align:right; width:40%" />
<a id="cite-err-check-close" />
<tr style="width:100%;" />
<td style="text-align:center; margin:1.5px;" />
<tr style="width:100%;" />
<td style="border: 1px solid black; margin:1.5px; width:60%" />
<td style="border: 1px solid black; margin:1.5px; width:40%" />

Is it important that this syntax be used, or would something like

<option></option>
<div id="cite-nref-preview-label" style="display:none;"></div>
<span id="cite-parsed-label" style="display:none;"></span>
<a href="#" id="cite-nref-parse" style="margin:0 1em 0 1em; display:none; color:darkblue"></a>
<ul id='cite-errcheck-list'></ul>
<table id="cite-err-report" style="width:100%; border:1px solid #A9A9A9; background-color:#FFEFD5; padding:0.25em; margin-top:0.5em"></table>
<tr style="width:100%"></tr>
<th style="width:60%; font-size:110%"></th>
<td style="text-align:center; margin:1.5px;"></td>

(etc.) work just as well? --Redrose64 🌹 (talk) 10:40, 28 July 2018 (UTC)

Feature request

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)

Where are the four previous requests? --Redrose64 🌹 (talk) 19:35, 19 September 2019 (UTC)

1. I requested this on the Reftoolbar talk page in July 2017 (didn't get a satisfactory response)
2. I requested it again in May 2019 (got no reply)
3. I then decided nobody was interested so I posted the request on the Village Pump technical (totally ignored)
4. I tried again on the Reftoolbar talk page 2 weeks ago (got no reply)
5. 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.
6. ...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 activity

Update 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)

Interface-protected edit request on 9 July 2020

Change

var url = '//tools.wmflabs.org/reftoolbar/lookup.php?'

to

var url = '//reftoolbar.toolforge.org/lookup.php?'

per wikitech:News/Toolforge.org --Ahecht (TALK
PAGE) 16:03, 9 July 2020 (UTC)

 Done — xaosflux ^Talk 16:07, 9 July 2020 (UTC)