MediaWiki talk:RefToolbar.js/Archive 1

Bugfix for autofilling of authors
Came across a bug upon porting to Norwegian Wikipedia. According to RefToolbar_2.0 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. I've tested the diff locally on nowp, and it should work fine. – Danmichaelo (talk) 15:46, 26 March 2012 (UTC)


 * 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.  Ron h jones (Talk) 21:24, 1 May 2012 (UTC)
 * The above is a diff, of similar style to those seen at (for example 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:


 * is to become:


 * -- Red rose64 (talk) 21:50, 1 May 2012 (UTC)


 * 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)
 * 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 . Anyway, I do like the "add additional author" proposal. -- Red rose64 (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 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: Uncaught TypeError: Cannot call method 'addMessages' of undefined That code should not be executed if  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. —Th e DJ (talk • contribs) 09:55, 9 October 2012 (UTC)
 * Now it changed to Uncaught Error: Unknown dependency: reftoolbar-base, caused by this call to

// 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. —Th e DJ (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
 * 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, but it should explicitly require the module   where this is defined
 * A command  to get the code from MediaWiki:Gadget-refToolbarBase.js, where   will be defined.
 * I don't remember if  is asynchronous, but if it is, the script MediaWiki:RefToolbar.js (which uses   and also load MediaWiki:RefToolbarMessages-en.js), NoDialogs.js & Legacy.js should be loaded inside of a callback (for this,   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 &mdash; some of which I've posted above &mdash; 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:

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: So there should ideally be some way to specify local field names as well, say,. – Danmichaelo (talk) 17:08, 26 March 2012 (UTC)
 * en:MediaWiki:RefToolbarMessages-en.js : 'cite-accessdate-label' : 'Access date'
 * en:MediaWiki:RefToolbarMessages-no.js : 'cite-accessdate-label' : 'Besøksdato'
 * no:MediaWiki:RefToolbarMessages-en.js : 'cite-besøksdato-label' : 'Access date'
 * no:MediaWiki:RefToolbarMessages-no.js : 'cite-besøksdato-label' : 'Besøksdato'

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


 * Please see MediaWiki_talk:RefToolbar.js 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 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  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 "&amp;#39;" although that's really ugly. Another workaround might be  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, please add Portuguese translations from pt:MediaWiki:RefToolbarMessages-pt.js. Helder 12:37, 6 February 2013 (UTC)
 * BTW: Since the documentation recomends copying 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
 * to
 * 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 above). Helder 13:39, 6 February 2013 (UTC)
 * 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 above). Helder 13:39, 6 February 2013 (UTC)
 * 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 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:

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 [//en.wikipedia.org/w/index.php?title=MediaWiki:RefToolbar.js&oldid=532150114&diff=537380860&diffonly=1 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 [//en.wikipedia.org/w/index.php?title=MediaWiki:RefToolbarMessages-en.js&oldid=537085456&diff=537380480&diffonly=1 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?
 * The language preferences dropdown box on the English Wikipedia suggests that the Brazilian Portuguese language code is "pt-BR" instead of "pt-br". Agree?


 * 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.
 * 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. 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  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. 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 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 [//en.wikipedia.org/w/index.php?title=MediaWiki:RefToolbar.js&oldid=532150114&diff=534188000 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, 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)
 * ✅, 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. &mdash; 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. &mdash; 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)
 * Red information icon with gradient background.svg 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 - did you post the same problem twice in error? -- Red rose64 (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, Yes check.svg 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 -. I think the new end of CiteTB.autoFill should look like this: 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? &mdash; 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):

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, 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 [//en.wikipedia.org/w/index.php?title=MediaWiki%3ARefToolbar.js&diff=608543114&oldid=606473141 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 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 Teahouse/Questions 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)



.

.

.

.

.


 * ✅, 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
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)
 * ✅, 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 T122755. [/w/index.php?search=insource%3A%2F(mw.util|mw.notify)%2F+-loader.using&title=Special:Search&fulltext=1&ns8=1 List more pages to check].

If you have questions or need help, please ask at 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. This is due to one or more of the following:  Is it important that this syntax be used, or would something like    (etc.) work just as well? -- Red rose64 &#x1f339; (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 ? 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? -- Red rose64 &#x1f339; (talk) 19:35, 19 September 2019 (UTC)
 * I requested this on the Reftoolbar talk page in July 2017 (didn't get a satisfactory response)
 * I requested it again in May 2019 (got no reply)
 * 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)


 * Tumbleweed in motion.webm Update 12:15, 31 October 2019 (UTC) — I see that, after years of me requesting this, someone has finally added a  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 to per News/Toolforge.org --Ahecht (TALK PAGE ) 16:03, 9 July 2020 (UTC)
 * ✅ — xaosflux  Talk 16:07, 9 July 2020 (UTC)