MediaWiki talk:Common.js/Archive 1

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Archive This is an archive of past discussions. 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.



This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Please add the following code:

/** Adds a link to subpages of current page *********************************** 
  *  Writen by [ ערן]

function subPagesLink()
    if ((document.getElementById("t-recentchangeslinked") || document.getElementById("t-whatlinkshere")) && wgNamespaceNumber != 0 && wgNamespaceNumber != 6 &&  wgNamespaceNumber != -1 &&  wgNamespaceNumber != 14)
        var rcntChngsLnkdNode = document.getElementById("t-recentchangeslinked");
        if (rcntChngsLnkdNode == null) rcntChngsLnkdNode = document.getElementById("t-whatlinkshere");
        var aNode = document.createElement('a');
        var liNode = document.createElement( 'li' );
        var subpages = "Subpages"; // default: en
         case "he": // Hebrew
          subpages = "דפי משנה";
         case "de": // German
          subpages = "Subpages"; // pls translate
         case "fr": // French
          subpages = "Subpages"; // pls translate
        var subpagesLink='' + wgPageName +'/';
        aNode.setAttribute('href' , subpagesLink);

Thanks, Yonidebest Ω Talk 21:44, 18 April 2007 (UTC)

Where would that be useful apart from the User namespace? --Dschwen 21:49, 18 April 2007 (UTC)
Many places. Every page that has subpages. On a multilanguage site it is most usfull as many pages are translated on subpages. Yonidebest Ω Talk 22:08, 18 April 2007 (UTC)
I agree, it's quite useful, in fact I use it all the time on he. Yonatan talk 22:10, 18 April 2007 (UTC)
Indeed. That's where I got it from :-) Yonidebest Ω Talk 22:11, 18 April 2007 (UTC)
I added local translation for "Subpages". More options can be added. Yonidebest Ω Talk 17:21, 21 April 2007 (UTC)

This script could:

  • be less complicated to understand: there's no need for subPagesLink object
  • allow us to look for subpages im the main space 0
  • check wgNamespaceNumber first and then use document getElementById just two times (not four) — this would make it both smaller and faster
  • use addPortletLink function from wikibits.js
  • not put <li> inside other <li> — this is probably incorrect from standarts point of view, and it looks differently in different browsers
  • use relative link '/wiki/Special:Prefixindex/'...; this would also prevented "he/commons" mistake earlier

Alex Smotrov 16:50, 23 April 2007 (UTC)

Some valid points. I'll go over the code again. The object will stay though, it doesn't make the code harder to understand, and adds a namespace for the translations hash. --Dschwen 18:07, 23 April 2007 (UTC)
How about that? Thanks again for the pointer to addPortletLink, I really have to make myself a quickref to wikibits.js (and ajax.js). Could you maybe provide another translation for the subpages link by any chance? --Dschwen 21:10, 23 April 2007 (UTC)
Thank you, it looks much better now, especially after I've taken a look at the local MediaWiki:Monobook.js file, that one is a real mess ;)
A also suspect that t-recentchangeslinked is mostly present on the same pages as t-whatlinkshere, so one of the checks is probably unnecessary.
And I also have a say about JSconfig: I'm not saying it's bad, I just don't see the point when you can simply use something like if (window.NoAutoInformationTemplate) return, and don't forget that people will copy the code of your functions to their local Common.js and then stumble on undefined JSconfig.
The translation for Russian: 'ru': 'Подстраницы',
Alex Smotrov 23:49, 23 April 2007 (UTC)
Ok, I added the translation and removed the RelatedChanges check. Concerning the JSconfig, by local common.js you mean other wikis? Hm, I didn't think about that. But when I'm weighing the benefits (encapsulatuion and central declaration of the config object) against that possible drawback (people ripping out half the JS without reading the first few lines of the file :-) ) I'm inclined to leave the JSconfig object. On the other hand , I could also create a cookie based extension to the my preferences page. That would be an even more userfriendly solution. --Dschwen 06:15, 24 April 2007 (UTC)
I fixed a minor bug causing this script to not work with the secure server. Esby (talk) 19:03, 18 February 2010 (UTC)

Information template

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Please add the following code:

/** Function that adds the [[Template:Information]] to upload form automaticly ************** 
  *  Writen by [[User:Yonidebest]]

function loadAutoInfomationTemplate()
 uploadDescription = document.getElementById('wpUploadDescription');
 var tripleTilda = '~~' + '~';
 var doubleBracket = '{' + '{';
 if(uploadDescription != null && wgUserLanguage != 'fromflickr' && wgUserLanguage != 'fromwikimedia' && wgUserLanguage != 'fromgov') {
  switch(wgUserLanguage) {
   case "ownwork":
    uploadDescription.value = doubleBracket + 'Information\n|Description=\n|Source=self-made\n|Date=\n|Author= MyName (' + tripleTilda + ')\n|other_versions=\n}}\n';
    uploadDescription.value = doubleBracket + 'Information\n|Description=\n|Source=\n|Date=\n|Author=\n|Permission=\n|other_versions=\n}}\n';

Thanks, Yonidebest Ω Talk 22:11, 18 April 2007 (UTC)

This code automatically adds the information template into the upload form I suppose... I think we should get more opinions about it before it's added. Yonatan talk 22:14, 18 April 2007 (UTC)
Exactly. That's what it says in the desc above. I raised the issue in the Village pump and got no response. In it basicly means "go for it, nobody objects". I say - add it (as I did in, and then we will see if the community like the idea. It is very convenient. Yonidebest Ω Talk 22:21, 18 April 2007 (UTC)
I've had something like this in my monobook.js for a long time. I edited the code above to use addOnloadHook. --Dschwen 22:34, 18 April 2007 (UTC)
Does it work with addOnloadHook? I am not sure addOnloadHook and AddLoadEvent act at the same time. Yonidebest Ω Talk 22:39, 18 April 2007 (UTC)
Same thing. --Dschwen 06:23, 19 April 2007 (UTC)

Why is it disabled for the ownwork form though? I suppose I'll add it tomorrow since I'm going to sleep now. Yonatan talk 22:45, 18 April 2007 (UTC)

I though it would be best to start small. In anycase, I added the ownwork with switch, so that more options can be added easily in the future. Yonidebest Ω Talk 23:08, 18 April 2007 (UTC)
Could someone change it so that it recognises XXownwork and XXfromwikimedia where XX is a language code. --Steinninn 19:50, 17 September 2007 (UTC)

moved addEvent

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

I moved the addEvent function out of teh object it resided in so it can be used by other extensions as well. The Function attaches an event handler to a specific object and is cross browser compatible. The existing function hookEvent attaches a global Event handler and leaves all the dirty work of sorting out the target object to the user, which is much more uncomfortable (and cost me a great deal of nerves alredy...). —Preceding unsigned comment added by Dschwen (talk • contribs) 08:56, 25 April 2007 (UTC)

User uploads link

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

{ { editprotected}} Please add the following code and make sure it works:

var userUploadsLink =
 // Translations of the menu item
 i18n :
  'en': ( 'User Uploads', 'Show upload list of this user' )  // default
  'de': ( 'Dateien dieses Benutzers', '' ) // please translate
  // 'es': ( '', '' ) // please translate
  // 'fr': ( '', '' ) // please translate
  // 'it': ( '', '' ) // please translate
  // 'ru': ( '', '' ) // please translate
  'he': ( 'העלאות המשתמש', 'הצג את רשימת ההעלאות של משתמש זה' )
 install: function()
  // honor user configuration
  if( !JSconfig.userUploadsLink ) return;

  // only in User talk & User namepsaces 
  if ( (wgNamespaceNumber == 2 || wgNamespaceNumber == 3) && document.getElementById('t-emailuser') )
   var useruploadsText = userUploadsLink.i18n[wgUserLanguage][0] || userUploadsLink.i18n['en'][0];
   var useruploadsToolTip = userUploadsLink.i18n[wgUserLanguage][1] || userUploadsLink.i18n['en'][1];
   var useruploadsLink ='/w/index.php?title=Special:Log&type=upload&page=&pattern=&limit=100&offset=0&user=' + wgTitle;

   addPortletLink( 'p-tb', useruploadsLink, useruploadsText, 't-useruploads', useruploadsToolTip, '', document.getElementById('t-emailuser'));

var myUploadsLink =
 // Translations of the menu item
 i18n :
  'en': ( 'my uploads', 'Show my upload list' ),    // default
  // 'de': ( 'meine Dateien', '' ), // please translate
  // 'es': ( '', '' ) // please translate
  // 'fr': ( '', '' ) // please translate
  // 'it': ( '', '' ) // please translate
  // 'ru': ( '', '' ) // please translate
  'he': ('ההעלאות שלי', 'הצג את רשימת ההעלאות שלי' )
 install: function()
  // honor user configuration
  if( !JSconfig.myUploadsLink ) return;

  if ( document.getElementById("pt-logout") )

   var myuploadsText = myUploadsLink.i18n[wgUserLanguage][0] || myUploadsLink.i18n['en'][0];
   var myuploadsToolTip = myUploadsLink.i18n[wgUserLanguage][1] || myUploadsLink.i18n['en'][1];
   var myuploadsLink ='/w/index.php?title=Special:Log&type=upload&page=&pattern=&limit=100&offset=0&user=' + wgUserName;

   addPortletLink('p-personal', myuploadsLink, myuploadsText, 'pt-myuploads', myuploadsToolTip, '', document.getElementById('pt-logout'));

Thanks, Yonidebest Ω Talk 22:22, 9 June 2007 (UTC)

It appears not to work. I get userUploadsLink has no properties in my error console. -- Bryan (talk to me) 14:45, 10 June 2007 (UTC)
Oh, oops. Now? Yonidebest Ω Talk 14:55, 10 June 2007 (UTC)
Done, works. -- Bryan (talk to me) 16:21, 10 June 2007 (UTC)
Hmm, I have modified the script so that the link will apear after the regular contirbutions link. Please update the script. Thanks, Yonidebest Ω Talk 11:41, 11 June 2007 (UTC)
I get a link that shows my own uploads whichever user page I visit. This is contrary to the behaviour of the User contributions link. --Dschwen 13:20, 11 June 2007 (UTC)

Yonidebest: if you want the link to appear after 'User contributions' the last parameter of addOnloadHook (sorry, made a stupid mistake) addPortletLink() should be not 't-contributions' but document.getElementById('t-emailuser').
Also, I totally agree with Dschwen: other links in the toolbox relate to the current page, not to the logged in user. So, you either:

  • put your new link into 'p-personal' portlet, or
  • make the link show uploads of the user who's page you're on: change wgUserName to wgTitle

Alex Smotrov 15:17, 11 June 2007 (UTC)

Umm…any response? Some other things to correct:

  • wgNamespaceNumber should be 2 and 3 (not 1 and 2)
  • wgNamespaceNumber should be checked first (and if you already found document.getElementById('t-contributions') then checking wgNamespaceNumber is probably unnecessary
  • 4th argument for addPortletLink() should be new unique id, not the same 't-contributions' (I'm talking about the current version in MediaWiki:Common.js)

Alex Smotrov 13:38, 13 June 2007 (UTC)

I changed the code above to reflect your suggestions. wgTitle will probably blow up on subpages though... --Dschwen 16:20, 13 June 2007 (UTC)
Sorry I didn't answer - I was busy. In any case - your changes are totally acceptable. I have thus added another function that adds a link to the p-personal list. I also fixed the subpages of wgTitle problem. Regards, Yonidebest Ω Talk 18:53, 13 June 2007 (UTC)
Three things
  1. Make it into one procedure, two addOnloadHook calls are one too much and both extensions perform similat tasks
  2. Make the tooltip translatable (see myUploadsLink).
  3. Make it all disabled by default. I have not missed these functions yet and if I need them I won't mind an extra click. The myUploads is a bit redundant anyways, there is the gallery tab on my userpage. --Dschwen 19:29, 13 June 2007 (UTC)
If you make them disabled by default then there's no sense adding them here at all. Putting JSconfig.userUploadsLink=true into one's monobook.js is as much diffucult as putting e.g. includeScript('MediaWiki:UserUploads.js')
I also made a few corrections to both scripts above. P.S. There is no 't-contributions' on user subpages. — Alex Smotrov 20:37, 13 June 2007 (UTC)
Alex, I learn a bit more everyday ;-) I changed the script so that it will apear on subpages. Do you think we should add a t-contributions link while we at it?
Dschwen, 1- I thought it be best if these were two procedures so that users can decide whether or not they want eash link. I don't mind if these are combined. 3 - I agree with Alex on this. If it's disabled by default there is no point adding this procedure here. Also, as this project is mainly based on uploads, I think that this link is pretty usefull and that not many users know they can find their name in the upload log. Also, the upload log has an advantage - it shows also the deleted images, unlike the contirubs list that show only undeleted contribs. Cheers, Yonidebest Ω Talk 12:13, 14 June 2007 (UTC)
Personally, I do not see the point in adding anything on subpages, I mean, how often does average user visit user subpages? P.S. Anyway, to get user name anywhere in user namespace you could use wgTitle.split('/')[0]Alex Smotrov 15:06, 14 June 2007 (UTC)
I second that. It's just code bloat and introduces a new unexpected interface paradigm. --Dschwen 20:06, 14 June 2007 (UTC)
OK, I removed the link from the subpages. Yonidebest Ω Talk 21:28, 15 June 2007 (UTC)

Upload page

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)
  • This last edit is a very strange way to hide that element. Please move the code into MediaWiki:Upload.js and use usual DOM techniques. Also, actually adding an id to that element might help
  • Please remove unnecessary <source> from here and MediaWiki:Upload.js
  • if(window.location.href=="") in MediaWiki:Upload.js looks unnecessary

Alex Smotrov 14:39, 14 September 2007 (UTC)

  1. Done. That already had an id.
  2. <source> tags keep the format on diffs (bugzilla:10871).
  3. Removed.
[1] Platonides 21:25, 15 October 2007 (UTC)

Which pages do I have to edit in order to add the template "Information" automaticaly in the textbox when uploading an image? I want to implement this tool on ro.wp --Alex:D 16:13, 19 January 2008 (UTC)


This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Shouldn't function includePage keep track of which files are already included to avoid including a file twice? Similar to function includeScript in en:MediaWiki:Common.js. Lupo 09:55, 24 October 2007 (UTC)

importScript was introduced rev:35064 in wikibits.js () making includePage obsolete! It also keeps track of already imported files.--Dschwen 16:39, 22 May 2008 (UTC)

Watchlist-details message

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

I'd like to add this; it will allow a dismissable message in MediaWiki:Watchlist-details, which is useful instead of the sitenotice for things which are only relevant for registered users. – Mike.lifeguard | @en.wb 04:38, 10 April 2008 (UTC)

/** Add dismiss button to watchlist-message *************************************
  *  Description: Hide the watchlist message for one week.
  *  Maintainers: [[w:User:Ruud Koot|Ruud Koot]]
 function addDismissButton() {
    var watchlistMessage = document.getElementById("watchlist-message");
    if ( watchlistMessage == null ) return;
    if ( document.cookie.indexOf( "hidewatchlistmessage=yes" ) != -1 ) { = "none";
    var Button     = document.createElement( "span" );
    var ButtonLink = document.createElement( "a" );
    var ButtonText = document.createTextNode( "dismiss" );
    ButtonLink.setAttribute( "id", "dismissButton" );
    ButtonLink.setAttribute( "href", "javascript:dismissWatchlistMessage();" );
    ButtonLink.setAttribute( "title", "Hide this message for one week" );
    ButtonLink.appendChild( ButtonText );
    Button.appendChild( document.createTextNode( "[" ) );
    Button.appendChild( ButtonLink );
    Button.appendChild( document.createTextNode( "]" ) );
    watchlistMessage.appendChild( Button );
 function dismissWatchlistMessage() {
     var e = new Date();
     e.setTime( e.getTime() + (7*24*60*60*1000) );
     document.cookie = "hidewatchlistmessage=yes; expires=" + e.toGMTString() + "; path=/";
     var watchlistMessage = document.getElementById("watchlist-message"); = "none";
 addOnloadHook( addDismissButton );
I suggest putting this into a separate page and only include it if the current page is the Watchlist. --Dschwen 12:19, 10 April 2008 (UTC)
Yes, that's the idea. Will do it soon unless there's objections. – Mike.lifeguard | @en.wb 02:28, 23 May 2008 (UTC)

It is at MediaWiki:Watchlist-details.js, but needs localization before being implemented. The code in Common.js is currently commented-out until this happens. – Mike.lifeguard | @en.wb 15:20, 25 May 2008 (UTC)

hasClass is not defined

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)


Please either revert this edit or also copy the hasClass() function from enwiki. Currently the call to an undefined function is breaking all the site javascript. —Ilmari Karonen 13:07, 10 May 2008 (UTC)

Done. Things look to be working now. – Mike.lifeguard | @en.wb 14:44, 10 May 2008 (UTC)

What do we need collapsible tables for ... =

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

... When we already have basically the same functionality for collapsible DIV sections.

I'd strongly suggest thinking about this edit again. It adds 50% size to common.js for little benefit. We should not copy every scrap of JS from en wikipedia just because it's cool. Aadditions of this magnitude should at least be put up for discussion on this page. --Dschwen 01:42, 12 May 2008 (UTC)

Agreed. What's wrong with divs? My guess is people are disappointed they can't copy'n'paste every en.wp template and have them work here. Which is another reason not to have collapsible tables. Rocket000 04:17, 12 May 2008 (UTC)
Ok, I removed it again. The additions were actually breaking the existing div hiding. --Dschwen 13:23, 12 May 2008 (UTC)


This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

importScript was introduced rev:35064 in wikibits.js () making includePage obsolete! It also keeps track of already imported files. I left a bulletin on about 160 user pages, asking them to replace includepage with the new native importScript function. I'll be gone next week and when i return I'll start phasing out includePage (either just remove it from Common.js, or make it add an obnoxious banner, asking people to replace it :-), or ..even better, create a one click replacement script, which performs the change for the users... ). --Dschwen 16:13, 23 May 2008 (UTC)

Please do an annoying prompt or something for a while before depreciating it. – Mike.lifeguard | @en.wb 15:09, 25 May 2008 (UTC)
I suggest changing includePage to call importScript, and alerting users with a JsMsg() that they are running a script that needs to be upgraded, together with a link to a page that points them to the people who can help them (admins with JS knowledge). TheDJ 15:56, 25 May 2008 (UTC)
You can do this silently (but I would like a message so people update their code) like this. – Mike.lifeguard | @en.wb 19:41, 25 May 2008 (UTC)
Ok, I just changed the remaining 30-40 user javascripts to use importScript. i did a mass-notification back in may, but only 60-70% acted on that. Anyhow, includePage is gone now. --Dschwen (talk) 19:23, 6 August 2008 (UTC)

Translation for the toolbox menu

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)


Please, add at "var subPagesLink =" 'ca': 'Subpàgines', for a translation to Catalan interface. --V.Riullop 11:01, 28 May 2008 (UTC)

Done; you may use {{editprotected}} to request edits to protected pages in the future. – Mike.lifeguard | @en.wb 11:44, 28 May 2008 (UTC)
Thanks. I've added this advise at Commons:Help page maintenance. --V.Riullop 12:23, 28 May 2008 (UTC)


Can you add in "var subPagesLink": 'gl': 'Subpáxinas', for the Galician translation? Thanks a lot! --Toliño (talk) 11:33, 30 June 2008 (UTC)

{{Editprotected}} --Toliño (talk) 11:33, 30 June 2008 (UTC)

✓ Done Waldir talk 20:58, 8 July 2008 (UTC)


{{editprotected}} Also at subPagesLink, please add the following i18n line:

'et': 'Alamlehed',

Thank you! 20:07, 2 August 2009 (UTC)

✓ Done, thanks. Pruneautalk 10:17, 3 August 2009 (UTC)

withJS alert

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

{{editprotected}} Using alert() (current Common.js) doesn't seem like a good idea, as it's too easy to construct a confusing link like this one. Please remove it. —AlexSm 16:51, 30 June 2008 (UTC)

Yeah, alert is a bit annoying. What about using jsMsg from wikibits.js? --Dschwen (talk) 19:25, 30 June 2008 (UTC)
I thought about that function too, but it uses innerHTML, so something like jsMsg('<style>body {background:red}</style>') will work. Instead of trying to make it safe, I would suggest to silently ignore invalid withJS parameters. —AlexSm 03:48, 1 July 2008 (UTC)
Also, I think simply using importScript('MediaWiki:'+extraJS) would make a better code, but I guess it's too late to change at this point. —AlexSm 03:48, 1 July 2008 (UTC)
Do not silently ignore invalid withJS parameters. I actually was very glad that I did get a big fat alert when I mistakenly had invalid withJS parameters when developing MediaWiki:UploadForm.js. Lupo 06:45, 1 July 2008 (UTC)
Then maybe a simple jsMsg('Invalid <tt>withJS</tt> URL parameter was ignored') ? —AlexSm 04:41, 2 July 2008 (UTC)

Please re-add {{editprotected}} when you have precise code to add or change.  — Mike.lifeguard | @en.wb 01:00, 14 August 2008 (UTC)

✓ Done Uses jsMsgAppend now. Lupo 11:29, 27 February 2010 (UTC)


This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

{{editprotected}} Please replace addEvent() with practically the same addHandler() defined in wikibits.js, and remove removeEvent() as it's not used. —AlexSm 16:51, 30 June 2008 (UTC)

Are you positive it is the same? Is the scope (the this variable) the same in the handler for both implementations? I remember when I added addEvent it had advantages over addHandler at that time, I just cannot remember the details... --Dschwen (talk) 19:23, 30 June 2008 (UTC)
Well, it the same with the current usage. As long as nobody uses this keyword in global JS files, I don't think there's a good reason to redefine addHandler() that's adequate for the job. P.S. If you agree that addEvent() is to be removed, MediaWiki:Upload.js and MediaWiki:Edittools.js have to be changed to use addHandler() first. —AlexSm 03:48, 1 July 2008 (UTC)
Indeed this will be different on IE when using addHandler. However, I usually don't rely on this being set in event handlers; I prefer to manually get the target DOM object from the event itself. Note that if this is removed, MediaWiki:UploadForm.js (and also MediaWiki:UploadFormTest.js) would also need to be changed. Due to caching, people might get for some time inconsistent JS (old cached upload scripts still using addEvent, but already new Common.js that doesn't have this function anymore). That would break our upload form, and must be prevented at all costs. Hence you cannot just remove addEvent. At the very least make it a rename of addHandler, like var addEvent = addHandler;. Then go replace all occurrences of addEvent, and a few months later, remove addEvent altogether. Lupo 06:43, 1 July 2008 (UTC)
But having a sensible this saves work. I really don't feel like rechecking every user script for the use of addEvent. Our Javascript id in pretty good shape. So for now we can live with those functions in it. --Dschwen (talk) 02:33, 2 July 2008 (UTC)
Of course I meant that dependant files have to be fixed first. The search shows that the only userscripts affected are User:Dschwen/ImageBoxes.js and User:Lupo/edittools.js, everywhere else the function is defined in the code. And the longer you keep global unnecessary code, the more difficult it will be to remove. —AlexSm 04:41, 2 July 2008 (UTC)
As we've pointed out above, there is a difference regarding this, and it's used in heavily used global scripts, not just user scripts. (Incidentally, User:Lupo/edittools.js is just a development copy of MediaWiki:Edittools.js.) Once we'll have in wikibits a true replacement that preserves behavior across browsers, we can make addEvent an alias to that new site-wide function, but until then, let's leave it as it is. Lupo 06:38, 2 July 2008 (UTC)
Unless I miss something, "this" is not currently used in MediaWiki:Edittools.js or MediaWiki:Upload.js or MediaWiki:UploadForm.js. With all due respect, I don't think it's a good idea to fill Common.js with functions "for future use", in case someone would like to utilize them in some distant future. Same goes for removeEvent(). —AlexSm 21:34, 2 July 2008 (UTC)
Yeah, Alex, you are right (I'd almost say like always when it comes to JavaScript). I looked over my stuff and every time I use addEvent I added it to my objects as a member function anyways (yay code duplication :-( ). Since this isn't curreently used (User:Dschwen/ImageBoxes.js is an experiment anyways), we should a) make addEvent an alias to addHandler, b) Lobby for the modification of wikibits.js to include the useful this behaviour, c) replace addEvent with addHandler in our code. What do you guys think? --Dschwen (talk) 20:01, 9 July 2008 (UTC)

what happened to specialSsearchEnhanced

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

what happened to specialSsearchEnhanced, it is deactivated. When dis that happen? Is it broken on the toolserver, did we decide to toss it now that the build-in search shows thumbs? --Dschwen (talk) 12:19, 6 August 2008 (UTC)

Ok, it was disabled in march by bryan [2], I wonder what is broken about it. --Dschwen (talk) 16:51, 6 August 2008 (UTC)

Dismiss watchlist notice

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

I've just added some .js which should allow watchlist notices to be dismissed. If it breaks anything please revert & accept my apologies (script courtesy of Mike.L). --Herby talk thyme 15:29, 15 August 2008 (UTC)

We already have that very piece of code in MediaWiki:Watchlist-details.js. But it was deactivated since it needs i18n. Also this shoul only bee loaded/hooked on Special:Watchlist anyways. Reverted. But we should talk/do something about i18n. --Dschwen (talk) 15:47, 15 August 2008 (UTC)
Fair enough - however it worked for me. If people are going to use the Watchlist notice should there not be a way of getting rid of it? --Herby talk thyme 15:57, 15 August 2008 (UTC)
Yes, it should be dismissable. I'd say enable it and i18n comes later (or we can choose an icon, though that can't communicate the 7 days thing). I'll poke it shortly soon.  — Mike.lifeguard | @en.wb 16:00, 15 August 2008 (UTC)
Should work now. While testing I discovered that the current Watchlist message is not translated so only en users are getting it. I don't know abt. the icon though. How would you convey 'hide this message for one week' in a pictogram? --Dschwen (talk) 16:34, 15 August 2008 (UTC)
Well you can do an upward-pointing arrow/triangle to signify "hide this" but I don't think we can do the 7 days part. Still, having that as a default for yet-to-be-translated languages would be excellent.  — Mike.lifeguard | @en.wb 19:22, 15 August 2008 (UTC)
Something like ▲  — Mike.lifeguard | @en.wb 19:38, 15 August 2008 (UTC)

Dshuf bias

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)


The current dshuf() implementation, using Math.random() inside a comparator, is likely to be biased on most sort() implementations. The bias is subtle, and not likely to be easily noticeable without statistical analysis, but it would be nice to do it right. Please backport these changes from en.wikipedia to fix it. —Ilmari Karonen (talk) 19:12, 24 December 2008 (UTC)

I don't quite see where the bias is supposed to come from. It is pretty obvious that any sorting algorithm will have to evaluate Math.random() for a comparison involving each element at least once. Depending on the efficiency of the sort algorithm some elements may appear more than once in comparisons. Your modified algorithm ensures that the score-value is alway taken to be the same, while the old implementation effectively assigns new random score values at each comparison. Where is the bias supposed to arise here? Whether it is the same, or it is random, there shouldn't be any bias in either case. What am I missing? --Dschwen (talk) 18:38, 25 December 2008 (UTC)
Consider the case of sorting three items: A, B and C. A reasonable sort implementation might end up doing something like this:
  1. Compare A and B.
  2. Compare C with the smaller of A and B.
  3. If C is larger than the smaller of A and B, compare it with the larger one too.
Now consider where C will end up if we use a random comparator. The first comparison, between A and B, obviously makes no difference for C. The second comparison, however, will rank C below both A and B with probability 1/2, not 1/3 as it should be for an unbiased shuffle. The rest of the time, C will end up ranked highest or in the middle, with probability 1/4 either way.
If you think you have a better way to sort three items, try it out: whatever method you choose, you will almost certainly not get a probability of 1/3 for item C ending up last (or indeed for any item ending up in any position, as you should). Or you might want to look at w:Fisher-Yates shuffle and particularly reference #7 in it. —Ilmari Karonen (talk) 23:08, 25 December 2008 (UTC)
The core of the problem is that the comparefn implementation using just random is not a consistent comparison function, so that the result of array.sort is implementation-defined, anyway. (See ECMA 262, I fixed the js code. --Mormegil (talk) 12:33, 26 December 2008 (UTC)
You are right. Amazing. Counter-intuitive. But that stupid three door game-show problem should have taught me... --Dschwen (talk) 14:49, 26 December 2008 (UTC)

Show error messages instead of broken thumbnails

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

If the rendering of a thumbnail fails, the server generates an error message instead of a valid image. As of now this makes the preview on the image page appear broken, without giving a reason. I wrote a little proof of concept script that replaces these broken thumbnails with the server generated error message. Check out . I have found it to be working in Firefox. Konqueror and Opera do not allow detection of the broken thumbnail. IE is not yet tested. The script is very short and persumably fast. It fails gracefully (as far as I have tested), so it might be worth to include this by default. --Dschwen (talk) 22:17, 7 April 2009 (UTC)

Sigh. Tested and adapted to detect broken thumbnails in IE7. But it does not show the server error message with useful information, and instead presents the user its own dumbed down error message with zero information content. What an annoying piece of junk. --Dschwen (talk) 22:36, 7 April 2009 (UTC)

SVG files: links to rendered PNG images

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Many users are not familiar with using SVG images available on Commons in office applications, etc. This is particularly true, if the base size is small (example). Therefore, I suggest adding links to rendered PNG images in different sizes to the image page. Slomox has added a script doing this to his monobook. An adapted version of it has gone live in de-WP one week ago. I would suggest also adding it on Commons.
There would also be the possibility to add other features to SVG image pages at the same time: Commons:Village pump/Archive/2009May#SVG Images. --Leyo 14:34, 11 June 2009 (UTC)

The first part just went live. Other features would need to be discussed. --Leyo 19:12, 1 July 2009 (UTC)
This was a great idea. Thanks. Rocket000 (talk) 22:51, 4 July 2009 (UTC)

We are now officially living in the future

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

It seems that, back in 2007 when the JSConfig framework was being developed, somebody decided that "Thu, 2 Aug 2009 10:10:10 UTC" would make a nice and distant expiry date for the cookie those preferences are stored in.

Well, August 2 came and went. It seems it took a few weeks before anybody noticed.

And people wonder what the folks who used two-digit dates back in the 1990s were thinking... —Ilmari Karonen (talk) 21:29, 19 August 2009 (UTC)

D'Oh!!!!!! My bad. And I actually got pretty annoyed from going to the preferences all the time and setting my upload form preferences every time I restarted my browser. Blamed it on Konqueror :-). --Dschwen (talk) 23:56, 6 September 2009 (UTC)

POTY script

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Do we still need to be loading User:Kalan/poty.js? Rocket000 (talk) 23:51, 6 September 2009 (UTC)

Probably not (though that's really just a guess), but if we're going to reuse it this year it may not be worth removing. Especially as any changes to the site JS take up to a month to fully spread anyway. What we should do, however, if we want to reuse the script, is change the regexps at the bottom to get rid of the hardcoded "2008". —Ilmari Karonen (talk) 12:25, 7 September 2009 (UTC)
Yeah, we all know hardcoded dates are bad... :-) --Dschwen (talk) 13:33, 7 September 2009 (UTC)

Ajax translation of templates

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Please add the script for ajax translation of templates to the common.js:


After doing so use Ctrl+R or Ctrl+F5 to refresh the JS cache in your browser. Now find an image that contains GFDL or CC license and click a language link in the license template: the template would be translated without need to refresh. ערן (talk) 09:40, 12 September 2009 (UTC)

BTW, checked in both FF 3.5 and IE 8.0. ערן (talk) 09:41, 12 September 2009 (UTC)
I think it would be better if {{translated tag}}s are hidden. :) Kwj2772 (msg) 12:05, 12 September 2009 (UTC)
There is no way to identify the {{translated tag}}, unless the template will use some class to identify itself (Template talk:Translated tag). ערן (talk) 14:27, 12 September 2009 (UTC)
I think it should be possible to show the templates as they would actually look transcluded, omitting anything in <noinclude> tags, by using API action=parse. —Ilmari Karonen (talk) 15:04, 12 September 2009 (UTC)
Also, don't use Ajax for anything like this; IE6 users may get annoying alerts about whether to allow ActiveX execution (XHR is available on IE6 only as an ActiveX component), and it may not work at all on older browsers. Use importScriptURI with a callback instead. Lupo 15:36, 12 September 2009 (UTC)
Lupo, what do you mean with importScriptURI with callback? ערן (talk) 17:30, 12 September 2009 (UTC)
See mw:API:Data formats#Output. When using the API with format=json, it's possible to specify the name of a JavaScript function that will be called with the returned data as its argument when the output is evaluated. That makes it possible to simply pass an API query to importScriptURI() instead of having to use XMLHTTPRequest. —Ilmari Karonen (talk) 20:52, 12 September 2009 (UTC)
Thanks. I've rewritten the calling to server using this trick. ערן (talk) 19:18, 13 September 2009 (UTC)
I've fixed the script to use API action=parse as Ilmari Karonen suggest and now {{translated tag}} doesn't appear. I've also added check for AJAX suuport (using wfSupportsAjax) to prevent problems in browsers which don't support AJAX. ערן (talk) 17:29, 12 September 2009 (UTC)
wfSupportsAjax still doesn't avoid the alert on IE6 with certain "security" settings. Lupo 21:20, 12 September 2009 (UTC)
OK fixed it using importScriptURI. ערן (talk) 19:18, 13 September 2009 (UTC)
What is the benefit of this? --Dschwen (talk) 21:55, 12 September 2009 (UTC)
It's interface sugar. Personally, I think it's a good idea. (Though I haven't actually tried out the script yet.) Getting sent off to an obscure subpage in the bowels of the Template namespace when one just wanted to see a license tag in one's own language is both inconvenient and contrary to the principle of least surprise. We should not be exposing implementation details of the autotranslate system in such an in-your-face way if we can avoid it, and it looks like with this script we can. —Ilmari Karonen (talk) 09:58, 13 September 2009 (UTC)
That is for not logged in users? It would be better to set their ui language automatically to their browser preference. That would enhance the whole site rather than just adding some (imo) gimmicky "sugar". --Dschwen (talk) 01:15, 14 September 2009 (UTC)
See the relevant thread on wikitech-l. --Mormegil (talk) 09:46, 14 September 2009 (UTC)
I'd say it's for everyone who currently ever uses the language links. After all, there are reasons why we have those under all the translated templates:
  • As you note, non-logged-in users see everything in English by default, so they need some way to change the language.
  • Not every template is translated to every language yet (and in practice never will be). Users looking at a template that isn't translated to their preferred language see it in the default fallback language (often English), but may prefer to view it in some other language that they understand better.
  • Translations may be wrong, outdated or badly written. Thus, users may wish to compare the text of templates in different languages. Also, users who can't fully understand any of the languages available may still be able to make sense of the message by comparing several translations.
  • Finally, the links are useful for editors looking for translations to update or improve, or for translators wishing to compare existing translations before writing a new one.
In all these cases, it would seem to me that a JavaScript enhancement that allowed the translations to be viewed immediately without going to a different page could be quite convenient. —Ilmari Karonen (talk) 21:38, 17 September 2009 (UTC)
OK, i've improved the code thanks for code review made by lupo and I think it's ready for use. can it be added to the common.js now? thanks, ערן (talk) 06:55, 18 September 2009 (UTC)
Code looks OK now. Only things I'm still usure about is whether the timestamp in the API URL is really needed (but that's a really minor issue), and what templates use this class "layouttemplate". I won't activate it, though, because I'll be away for the next three weeks and thus would be unable to correct any problems that might surface. If someone else wants to take the responsibility that's fine by me. Lupo 09:15, 18 September 2009 (UTC)
I've done the first step, i.e. moving the code to MediaWiki:AjaxTranslation.js. It can be tested by appending "?withJS=MediaWiki:AjaxTranslation.js" to any file page URL. It seems to work fine for me (on Firefox 3), but I'd like to see as many people as possible test it on different browsers. If no unexpected problems appear, I'll enable it globally in a few days. To ערן: if you have any modification you want to make to the code, let me know (or ask some other admin to help). —Ilmari Karonen (talk) 10:34, 19 September 2009 (UTC)
Can you please enable it/import the js in common.js. thanks, ערן (talk) 16:56, 28 September 2009 (UTC)
✓ Done. Now we'll just have to wait for the inevitable flood of bug reports. :) —Ilmari Karonen (talk) 22:37, 9 October 2009 (UTC)
...and reverted immediately pending further debugging. :( Something's broken with that script — it looks like the templateName variable doesn't get set properly, causing all the links to simply produce "{{}}" as their output. —Ilmari Karonen (talk) 22:45, 9 October 2009 (UTC)
OK, I think I've fixed it now: a recent change to use external links instead of normal wikilinks on a lot of templates had broken it. I've made it support both kinds of links, and also made it a little more robust against any such problems that might occur in the future. I'd rather like someone using IE to test it before I re-enable it, though. —Ilmari Karonen (talk) 23:50, 9 October 2009 (UTC)
How do we install this at Template:CatDiffuse/layout? Please see:
Template talk:CatDiffuse/layout#Auto-translation and
Template talk:CatDiffuse/layout#Translation for non-logged-in users
--Timeshifter (talk) 23:45, 18 October 2009 (UTC)

Can it be reenabled please? I've checked it both in FF and IE8. ערן (talk) 09:38, 18 December 2009 (UTC)

I can only support this. This is in my opinion exactly what we need: We shouldn't lead the people to template pages to view licensing texts and the like, but they should rather be able to stay on the file description page. As the script worked for me as an unregistered user (I assume that it's not working with my account due to the evil navigation popups scripts which is known to prevent Commons scripts from properly working), so unless there's some bug report or a "no" for another reason, I'll enable this script as a "christmas present" here on Commons. --The Evil IP address (talk) 19:10, 22 December 2009 (UTC)
Either the template or the script should be improved to also work on {{PD-Art}}. It currently only works for the license template inside PD-Art, which results in an inconsistent user experience. Lupo 09:14, 24 December 2009 (UTC)
Should work now, I believe. --The Evil IP address (talk) 09:37, 24 December 2009 (UTC)

I reported some issues I noticed with this script on MediaWiki talk:AjaxTranslation.js. Jean-Fred (talk) 14:41, 27 December 2009 (UTC)

I don't want this, how do I disable this? Multichill (talk) 22:31, 1 January 2010 (UTC)

I've added a quick-and-dirty option to disable this feature by adding
window.disableAjaxTranslation = true;
to your monobook.js or vector.js. If there are more than one or two users who want this, it would probably be a good idea to make it a Gadget. —Ilmari Karonen (talk) 05:20, 2 January 2010 (UTC)


This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

{{editprotected}} I'd like to add this function.

function getISODate() { // UTC
    var date = new Date();
    var dd = date.getUTCDate();
    if (dd < 10) { dd = "0"+ dd.toString(); }
    var mm = date.getUTCMonth()+1;
    if (mm < 10) { mm = "0"+ mm.toString(); }
    var YYYY = date.getUTCFullYear();
    ISOdate = YYYY + '-' + mm + '-' + dd
    return (ISOdate);

It will be useful to normalize date used by script (e.g. Flickrreview script) Kwj2772 (msg) 06:52, 4 October 2009 (UTC)

  • ✓ Done - Huib talk 10:16, 4 October 2009 (UTC)

SVG thumbnails

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Hi, in the course of adding the SVG thumb code of Commons to the English Wikipedia, we discovered some issues. The English Wikipedia now uses this code. The discussion took place here. Of particular importance is the usage of thumb.php of which Tim Starling said the following:

  • "thumb.php is broken and should really be a 403 if you access it from outside the server cluster"
  • "if you use thumb.php, it's forwarded to the general cluster, not the image scaling cluster"
  • "so all the fonts will be broken and it'll be cached forever like that"

I think it is therefore very much a priority to stop using the thumb.php urls for the code as soon as possible. The English Wikipedia code:

  • works with thumbs of both local and shared repos
  • uses the image scaling cluster
  • works on the secure server
  • tested with IE 5.5 and most other browsers

TheDJ (talk) 23:14, 27 November 2009 (UTC)

✓ Deployed. Kwj2772 (msg) 03:19, 28 November 2009 (UTC)
I note that on en.wp we had chosen a slightly different position (under the fullmedia link, instead of above it). I'm not sure what the Commons editors prefer, but be aware that someone might complain about that. TheDJ (talk) 13:16, 28 November 2009 (UTC)

Click tracking

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

User:Flominator has switched on a hack by Magnus to do click tracking for external links via the toolserver. I ask that this be undone ASAP. First, this implementation may break if other scripts add onclick handlers to external links. Second, for me, it breaks some external links, such as this link to the Library of Congress. When I click on this link, loading the page gets stuck: the page doesn't load and the browser keeps indicating "Transferring data from" until a timeout occurs. Lupo 14:26, 30 December 2009 (UTC)

A right-click on that link and then choosing "Open in a new tab" works, BTW, but seems to bypass the toolserver altogether. Browser: FF 3.0.5, Skin: monobook. Lupo 14:27, 30 December 2009 (UTC)
Agree. I'll undo this change. The code definitely needs fixing. --Dschwen (talk) 16:23, 30 December 2009 (UTC)
P.S.: just linking to an off-wiki discussion about this is not satisfactory either. This should have been announced here to allow for a code review first. --Dschwen (talk) 16:29, 30 December 2009 (UTC)
Furthermore I propose to run the script randomly with a 1% chance only. That should still be plenty of statistics. --Dschwen (talk) 16:27, 30 December 2009 (UTC)
A better way to do this (assuming it's considered desirable at all) would be to have the toolserver script issue a HTTP 302 redirect to the target URL, and then just change the links to point to the toolserver script directly. This would also allow the possibility of a JavaScript-free implementation as a MediaWiki extension, should such a thing be wanted.
Anyway, even if the script is written to fully comply with the Wikimedia privacy policy, people are going to worry about their clicks being reported to an external site, even if it's just the toolserver. If this is done at all, the implementation should be reviewed and approved by Wikimedia staff first (which doesn't appear to be the case here), and it should be made very clear to users that this has been done. An implementation as a MediaWiki extension could help here, as the tracking code then wouldn't have to reside on an external server. —Ilmari Karonen (talk) 05:01, 31 December 2009 (UTC)


This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

The most recent buggy edit to this script makes me want to have an editnotice here (but not on non-JS files in the MediaWiki namespace) that says something like the following:

Commons-emblem-hand-orange.svg Any edits here will have an effect on all users of Wikimedia Commons using any skin, whether logged-in or not.
Did you test the changes you want to make?

Make sure that any edits you make to this page are absolutely correct. Changes on this page become effective immediately (but due to caching, it takes 30 days until the changes are effective for everyone). The slightest syntax error, or runtime errors, may affect many people out there, and may make other scripts like gadgets fail.

Make sure by testing beforehand that you do not introduce errors here. If you're not 100% certain, leave now and test your modifications in your own monobook.js, vector.js, or other user script file. Don't forget to test on Internet Explorer, too.

Not to pick on the editor in this case—it happens to the best—but such carelessness has far-reaching effects because it'll take 30 days until people who got the incorrect version will have the corrected version automatically. Even if it's fixed within one or a few minutes, countless people out there will have gotten the wrong version and will now, for 30 days, have a Commons that doesn't work as it should. (Unless they clear their browse's cache manually, which only very few will do.) In particular, these people will have an unadorned upload form without license checks...

How can we add this editnotice or a similar one to MediaWiki:Common.js? Using MediaWiki:Common.js/Editnotice didn't work, and changing MediaWiki:Editinginterface would make the message appear on all pages in the MediaWiki namespace. Lupo 19:50, 18 February 2010 (UTC)

Try MediaWiki:Editnotice-8-Common.js -- User:Docu at 20:05, 18 February 2010 (UTC)
Hmm, that doesn't seem to work. Multichill (talk) 20:15, 18 February 2010 (UTC)
Maybe a "-" or a space is required instead of ".". Syntax is a bit special. -- User:Docu at 20:30, 18 February 2010 (UTC)
MediaWiki:Editnotice-8-Common.js would have worked if we had subpages in namespace 8, but we don't. However, I've now set up MediaWiki:Editnotice-8 so we can now use MediaWiki:Common.js/Editnotice, and indeed it works. Thanks, I learned something new. Lupo 21:57, 18 February 2010 (UTC)
I recall en:MediaWiki:Editnotice-0-Loch Ness working, but that namespace didn't have subpages. -- User:Docu at 22:10, 18 February 2010 (UTC)
Yes, but that was deleted, and the code for this feature was removed by Domas on March 10, 2009 in r48276. Since then, this only works in namespaces that do have subpages, which apparently was an oversight: it shouldn't work at all; one should always use the transclusion trick we use in the Editnotice-\d messages. Lupo 07:27, 19 February 2010 (UTC)
P.S.: some documentation is at en:Wikipedia:Editnotice. Although it does describe the system used at the English Wikipedia, it's still useful to learn to understand how this can be made to work. Lupo 07:40, 19 February 2010 (UTC)
WP used to have (and probably still has) some quite interesting edit notices. Generally they condense the type of stuff people add to articles (and get reverted later). Anyways, interesting thread on r48276. This explains why MediaWiki:Editnotice-4-OTRS-Noticeboard still works. -- User:Docu at 09:50, 19 February 2010 (UTC)

withJS ignore characters after #

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Could we ignore charters after the pound ie something like adding [^&#] to the getParamValue match to ignore after #

function getParamValue( paramName, url) 
 if (typeof (url) == 'undefined' ) url = document.location.href;
 var cmdRe=RegExp( '[&?]' + paramName + '=([^&#]*)' );
 var m=cmdRe.exec(url);
 if (m) {
  try {
   return decodeURIComponent(m[1]);
  } catch (someError) {}
 return null;

--Mdale (talk) 03:32, 24 February 2010 (UTC)

Wouldn't we need to make the first sub-match non-greedy in this case? Or exclude '#' from the first character set? Seems to me your proposal would match "MediaWiki:Foo.js#Something_else.js#Bar" as "MediaWiki:Foo.js#Something_else.js" and "#Bar". The regexp would thus need to be either "^(MediaWiki:[^&<>=%]*?\.js)(#.*)?$" or "^(MediaWiki:[^&<>=%#]*\.js)(#.*)?$". Lupo 08:49, 24 February 2010 (UTC)
Your right. Putting "MediaWiki:Foo.js#Something_else.js#Bar".match("^(MediaWiki:[^&<>=%]*?\.js)(#.*)?$") into firebug we get "MediaWiki:Foo.js" for the first match. I have updated the suggested regular expression above. --Mdale (talk) 03:34, 25 February 2010 (UTC)
Oh, and the backslash should be doubled, otherwise it'll also match "MediaWiki:Foojs" (without the dot). Lupo 08:26, 25 February 2010 (UTC)
Besides this change, it seems to me that anyway getParamValue should be fixed to only look in the search part of the href. /([^?#]*)(\?[^#]*)?(#.*)?/ should give submatches for protocol/host/port/path, search, and hash. Or the regexp within getParamValue is changed to '[&?]' + paramName + '=([^&#]*)'. Though that would still match within the hash, but that's probably a pathological case that can be ignored. (Parameters are supposed to be encoded, and encodeURIComponent does encode "#", so we don't get problems with parameters that are supposed to contain a hash sign themselves.) Lupo 08:15, 25 February 2010 (UTC)
I've done the backslash doubling, but I think omitting the hash part of the URI should really be done in getParamValue as indicated above. That's a far cleaner and much less verbose change that will have the desired effect. Lupo 10:48, 25 February 2010 (UTC)
Agreed. In mwEmbed land I just use something like mw.parseUri( document.location ).queryKey['paramName'] ... but will have to wait until that makes its way into the software. I updated the proposal to update getParamValue above to ignore stuff after # for the value. Lupo if that single char modification looks good it would be good to plop it in.--Mdale (talk) 01:31, 27 February 2010 (UTC)
✓ Done with the single-character change from "[^&]" to "[^&#]". I've also cleaned up this getParamValue and withJS stuff a little. Lupo 11:11, 27 February 2010 (UTC)

$j undefined

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

This sitenotice translation stuff breaks on monobook. Please note that on monobook, you don't have jQuery. Test your stuff before changing anything here! There's even a big flashy editnotice on MediaWiki:Common.js telling you to do so, so why don't you?? Lupo 21:10, 6 April 2010 (UTC)

Why would you need javascript if you can just update Special:PrefixIndex/MediaWiki:Sitenotice? Multichill (talk) 21:21, 6 April 2010 (UTC)
I'm sorry for the inconvenience. I read the box, but I thought that the skins only use a different design and not different javascripts. As it worked in Vector, I thought it would do the same elsewhere. Apparently I was wrong and you can be sure that I will really test scripts before I implement them (e.g. how I did it when adding MediaWiki:MainPages.css into MediaWiki:Monobook.js and MediaWiki:Vector.js). AFAIK, using the subpages of MediaWiki:Sitenotice doesn't yet work (i.e. it's not shown to the users). --The Evil IP address (talk) 21:29, 6 April 2010 (UTC)
Hehe. Can happen. That's exactly why there is this editnotice: even seemingly small changes can go wrong in subtle ways. If it works in one browser or skin, that's no guarantee that it'll work in other browsers or skins. Lupo 10:12, 7 April 2010 (UTC)

Here's a version of that translation code that doesn't depend on jQuery:

// Sitenotice translation for all skins, not dependent on jQuery
addOnloadHook (function () {
  var siteNotice = document.getElementById ('siteNotice');
  if (!siteNotice) return;
  var firstPara = siteNotice.getElementsByTagName ('p');
  if (!firstPara || firstPara.length == 0) return;
  firstPara = firstPara[0];
  var toReplace = firstPara.parentNode;
  if (!toReplace) return; // Paranoia.
  var s = document.createElement ('script');
  s.src = wgServer + wgScriptPath
        + '/api.php?action=parse&pst&text={{MediaWiki:Sitenotice}}&uselang=' + wgUserLanguage
        + '&format=json&callback=window.translateSitenotice';
  s.type = 'text/javascript';
  var head = document.getElementsByTagName('head')[0];

  function doTranslation (json) {
    if (json && json.parse && json.parse.text) {
      while (toReplace.firstChild) toReplace.removeChild (toReplace.firstChild);
      toReplace.innerHTML = json.parse.text['*'];
    head.removeChild (s);

  window.translateSitenotice = function (json) { doTranslation (json); };
  head.appendChild (s);

Tested in Firefox 3.5.5, "standard" and "monobook" skins; in IE8, same skins, and in Safari 4.0.4 (6531.21.10) (Mac), same skins. If you want to use that, please test in the vector skin and on Opera, too. It should work there, too, but as the previous attempt has shown, better test once too often. On vector, use either the jQuery method, or this one, otherwise you'll do the translation twice (which is inefficient, but doesn't do any harm otherwise). Lupo 10:12, 7 April 2010 (UTC)

However, I must echo Multichill's question: why do you use {{LangSwitch}} at all in MediaWiki:Sitenotice? I think if you used normal subpages (MediaWiki:Sitenotice/fr, MediaWiki:Sitenotice/de, and so on), all this localisation would be done automatically by the server. Lupo 14:08, 7 April 2010 (UTC)
Tested in my monobook.js in Opera 9 (Mac).
@Lupo: Smart to use the API, that saves a few kb's of download compared to a regular load and extracting the pagecontents like I did in Vector. I'll copy the API-url to the jQuery script. If someone could test Opera 10 and/or Opera on a PC this can go live. –Krinkletalk 14:13, 7 April 2010 (UTC)
OK. Has been moved in MediaWiki:Monobook.js now. –Krinkletalk 00:59, 9 April 2010 (UTC)
Why only monobook? What about people using standard, chick, cologneblue, modern? If you want to be sure it doesn't run on vector, just add "if (skin != 'vector')" around the whole thing. Or simply remove the jQuery implementation in vector.js. Lupo 06:08, 9 April 2010 (UTC)
Obviously, my mistake. ✓ DoneKrinkletalk 05:23, 10 April 2010 (UTC)

Add links to CommonsDelinker log to deletion log entries

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

One side effect of all these recent sexual content deletions is that I realized that the CommonsDelinker log page, which contains useful information about prior usage of deleted files, is both hard to find and hard to search (you have to type the filename exactly as it's logged — underscores for spaces, no "File:" prefix and upper case first letter). To make finding this information a little easier, I wrote a script to append direct links to the delinker log to deletion log entries for files. I think it might be a good idea to deploy this script globally, but I'd like to try asking for some second opinions (and testing) before just going ahead with it. So, what do you think? Would this be a useful addition to Common.js? —Ilmari Karonen (talk) 12:26, 8 May 2010 (UTC)

As no-one seems to have objected, I've gone ahead and added the code to Common.js. If you find any problems with it or would like to suggest improvements, please let me know. —Ilmari Karonen (talk) 16:25, 8 May 2010 (UTC)
I hope this supports i18n, I expect this will be useful for checking. Thanks. – Kwj2772 (msg) 16:45, 8 May 2010 (UTC)
There's no i18n at the moment, but it shouldn't be hard to add. I'm not quite sure what the best way to do it would be, though, as there doesn't seem to be a standard way to do it. Some existing scripts seem to use just a big ol' array of string embedded in the code, but I think a cleaner solution might be to define a set of English strings here as a global variable (e.g. window.commonsDelinkerLogLinksI18n) and letting it be overridden in the Common.js/xx subpages. In fact, maybe I should go ahead and just define one global i18n object (would window.i18n be OK?) for all scripts to use. —Ilmari Karonen (talk) 16:57, 8 May 2010 (UTC)


This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Please change 'poty2008' to 'poty-voting': this will enable user:Kalan/poty.js, a script for greatly increasing the convenience of POTY voting that was used a year ago. — Kalan ? 21:23, 14 May 2010 (UTC)

Yes, I am one of these paranoid persons. Why importing a script that will be often used in future from user-namespace. Please move the script to MediaWiki-Namespace thus User:Kalan will not be the only one, able to edit this script and as the MediaWiki-Namespace is supposed to be a guarantee for not-containing malicious code. Thank you. -- RE rillke questions? 21:09, 1 May 2011 (UTC)

It is not nice, but I see no big problem here. .js files in user namespace are only editable by the user and sysops. So it is like a fully protected .js file in Commons namespace +Kalan can edit it. So it just comes down to the question if you do or do not trust Kalan as much as any(!) sysop here. ;-) Kalan is "Editor; Sysop" on ruwiki and so on. Seems fine for me. In addition he had maintained the script since poty 2008. If the script would be in Commons namespace it would be a problem since he could not edit it. So everytime he wants to change it he needs an admin. Cheers --Saibo (Δ) 23:37, 1 May 2011 (UTC)

Proposal to change MediaWiki:Quick-delete-code.js to MediaWiki:AjaxQuickDelete.js

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

I was a bit dissatisfied with the current script, since it opens 3 or 4 new windows/tabs, which afterwords have to be saved. Especially new users might forget to save (thus we have on more incomplete RfD) & the sudden flood of pages might be confusing or irritating. I wrote a new script, based mainly on one by Ilmari Karonen. This script doesn't use the normal edit functions, but the wiki API to edit the pages. This has the following advantages:

  • Inline progress indicator
  • No new tabs/windows
  • Notify all users who have uploaded a new version, not just the latest one
  • Should be a bit quicker in execution time
  • Less incomplete RfD
  • Edit conflicts are impossible, since we use a special API call (appendtext)

I tested it in IE 7&8, Firefox 3.6, Chrome 4&5, Safari 4&5 in Vector and Monobook. The extended version, which can be enabled as gadget, would also work with this script OOB. --DieBuche (talk) 22:17, 9 July 2010 (UTC)

Basically, I'm all in favor of switching, but the new version still has a lot of TODO's in the code that should be solved. In particular not notifying bots should be done before enabling this. And for addToolLink, you'll need an importScript of MediaWiki:Utilities.js somewhere. Lupo 07:47, 10 July 2010 (UTC)
Ok, I'll have a look how to do the bot detection. addToolLink probably just worked for me because MediaWiki:Utilities.js had been imported by another script.--DieBuche (talk) 09:50, 10 July 2010 (UTC)
Notifier.js does contain bot detection code. Lupo 12:02, 10 July 2010 (UTC)
Added the botdetection now. The code is mainly based on yours & I added some credits for that. I also consoled two api calls into one, so it should be a tiny bit faster. One question though: Is the doubleencoding fix necessary, i can't remember ever having seen something like this. --DieBuche (talk) 13:06, 10 July 2010 (UTC)
Some smaller stuff ({{nobots}} respect etc.) is done--DieBuche (talk) 16:33, 10 July 2010 (UTC)
I think unfortunately the double encoding fix is still needed. It was a bug in Magnus's first version of the CommonsHelper upload bot (I think since he switched to CommonsHelper2, it no longer occurs), and we still have files that were uploaded through this bot and where the user names are encoded twice. See the report at MediaWiki talk:Titleblacklist#User name on Commons. That report was about File:Marcus Caelius.jpg. Lupo 08:31, 11 July 2010 (UTC)
I see. I tried to find an image transferred by a user with a non-latin name, but couldn't find one quickly. I added your encoding fix function to the script. --DieBuche (talk) 12:27, 11 July 2010 (UTC)
Added more smaller changes (The user himself is not notified if he nominates his own pictures; possible errors are displayed in a div. Any more issues you see?--DieBuche (talk) 22:41, 12 July 2010 (UTC)
Ok, now that the script follows redirects as well, all important TODOs are fixed. Anything else you'd like to see before deployment?--DieBuche (talk) 19:29, 20 July 2010 (UTC)
This page has been deleted on November 4, 2009 --Ida Shaw (talk) 09:17, 23 July 2010 (UTC)
? I see it perfectly fine; and it's still imported from common.js (see the line: importScript('MediaWiki:Quick-delete-code.js'); )--DieBuche (talk) 10:10, 23 July 2010 (UTC)

Always secure

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

There has been a request on the Village pump, to enable the alwayssecure script, just as on the English and the German Wikipedia. en:MediaWiki:Common.js/secure.js, de:MediaWiki:Common.js/secure.js. This makes sure that people using the secure server don't accidentally navigate to a non secure version of the site. Only a bandage of course, but it's better than nothing. TheDJ (talk) 21:19, 30 July 2010 (UTC)

JQuery $j,$ addOnLoadHook

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

What is the current status of wikibit's addOnLoadHook being replaced with $j(document).ready(..) ? Is it $ or $j ? What is happening here? Is the JQuery construct functionally identical to addOnLoadHook? It seemed to me during initial testing that the JQuery construct leads to much later execution, is that true? Is addOnLoadHook deprecated now? The current situation is a bit murky and that is not good for script development. Can we rely on JQuery being available in every skin now or not? --Dschwen (talk) 16:39, 8 November 2010 (UTC)

They are not equivalent, at lest in this case (also noted at pt.wikibooks). But I think they should be. Helder 16:54, 8 November 2010 (UTC)
Yes, hooks registered using addOnloadHook() normally run before those registered using $(document).ready(). This is because all MediaWiki skins contain the following piece of code just before the </html> tag:
<script type="text/javascript">if (window.runOnloadHook) runOnloadHook();</script>
This runs the hooks registered using addOnloadHook() just before the document parsing has finished, while jQuery (which doesn't have access to such tricks) has to wait until the "DOMContentLoaded" event fires after the parsing is complete. Apparently this is worse on IE, where the "DOMContentLoaded" event doesn't exist and jQuery has to use a slower workaround. The same page suggests that it should be possible to modify the code that calls runOnloadHook() to also call jQuery.ready(), thus making both equally fast; in fact, I've had code doing effectively just that in my vector.js for months now, and it seems to work without problems (although I haven't done much cross-browser testing with it yet). —Ilmari Karonen (talk) 17:28, 8 November 2010 (UTC)
Well, ok, but apparently people are going around deprecating addOnloadHook in our scripts. So my original question still stands, is it really deprecated, and are we ready to move to JQuery? --Dschwen (talk) 18:04, 8 November 2010 (UTC)
And why is .ready always used with an anonymous function, even if the latter only wraps a single function call? --Dschwen (talk) 21:04, 8 November 2010 (UTC) P.S.: see here --Dschwen (talk) 21:07, 8 November 2010 (UTC)
One problem is that if you do something like $(document).ready( someObject.method );, and the method uses the this keyword, it will not point to someObject when it is run through the ready event handler. Wrapping the call in an anonymous closure fixes that. Also, I'd consider defining callbacks as named functions in the global scope (as in the example you linked to) to be bad form, since it pollutes the window object. —Ilmari Karonen (talk) 21:28, 8 November 2010 (UTC)
Well sure, that's why I wrap my code in objects. But here we have namespace pollution and an anonymous function and no use for this. But you are right, when done correctly all points come together and the this issue could be important. Thanks. --Dschwen (talk) 21:38, 8 November 2010 (UTC)
We are in the process of replacing the functionality of wikibits.js, which along with all other JS in the skins/common/ folder is [mw:ResourceLoader/JavaScript_Deprecations being deprecated]. If possible, try and switch over to using the functionality of the mediaWiki and jQuery objects. There is no firm date on which we will actually disable/remove wikibits or other deprecated code - but we do plan to eventually do that. Obviously it is critical that all code has been ported before that happens, but the sooner it happens, the sooner we can stop sending that extra code to the client, making the site faster and cheaper to run. Trevor Parscal (talk) 21:37, 9 November 2010 (UTC)


This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Please, add localization for Portuguese in the scripts:

      'pt': 'Usar edittools antigo',
      'pt-br': 'Usar edittools antigo'
  'pt': 'Usar a nova lógica do formulário de carregamento',
  'pt-br': 'Usar a nova lógica do formulário de carregamento',
  'pt': 'Usar a nova aparência do formulário de carregamento',
  'pt-br': 'Usar a nova aparência do formulário de carregamento',
  'pt': 'Subpáginas',
  'pt-br': 'Subpáginas',
  'pt': 'Exibir um link para as subpáginas no menu de ferramentas',
  'pt-br': 'Exibir um link para as subpáginas no menu de ferramentas',
  'pt': 'Personalizar a largura da caixa de sugestões AJAX',
  'pt-br': 'Personalizar a largura da caixa de sugestões AJAX',

Thanks! Helder 21:24, 9 November 2010 (UTC)

By the way, Edittools should also be loaded when the action is 'submit':
    if (wgAction=='edit' || wgAction=='submit' || wgNamespaceNumber == -1){
And the regex for inserting the CSS validator should test ".css" at the end of the title, with /\.css$/i.
Helder 21:31, 9 November 2010 (UTC)
Done. I'll have a look at your other edittools improvements tomorrow--DieBuche (talk) 22:07, 9 November 2010 (UTC)

Language Select Bug

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

I guessed a new bug there. I hope it will be fixed soon; this is just a note as this disc is watched by more. -- Bergi 17:50, 14 November 2010 (UTC)

Fixed & thanks for reporting--DieBuche (talk) 18:05, 14 November 2010 (UTC)

Malayalam translations

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

{{editprotected}} Please include these Malayalam tranlsations,

subPagesLink :

  'ml': 'ഉപതാളുകൾ',

JSconfig.registerKey('subPagesLink', true, :

 'ml': 'പണിസഞ്ചിയിൽ ഉപതാളുകൾക്കുള്ള കണ്ണി പ്രദർശിപ്പിക്കുക', 

JSconfig.registerKey('UploadForm_loadform', true, :

 'ml': 'പുതിയ ആശയമനുസരിച്ചുള്ള അപ്‌ലോഡ് ഫോം ഉപയോഗിക്കുക',

JSconfig.registerKey('UploadForm_newlayout', true, :

 'ml': 'പുതിയ രൂപരേഖയിലുള്ള അപ്‌ലോഡ് ഫോം ഉപയോഗിക്കുക',

Thank you--Praveen:talk 13:25, 14 December 2010 (UTC)

also add:
        case 'ml':
            ptext = 'ഈ ചിത്രം PNG ആയി ലഭ്യമാകുന്ന മറ്റ് വലിപ്പങ്ങൾ: ';

in function SVGThumbs(). Thank you--Praveen:talk 17:16, 14 December 2010 (UTC)

✓ DoneKwj2772 (msg) 09:44, 24 December 2010 (UTC)

LargeImage linkswap disabled

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

I disabled largeimage-linkswap function because that function blew up full resolution links of all raster images. That was obviously not intended way of running that script. Best regards. – Kwj2772 (msg) 04:54, 6 January 2011 (UTC)

Whoops, ok, I guess I need to debug this further. Sorry. --Dschwen (talk) 19:23, 6 January 2011 (UTC)

Bug in REGEX

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

{{editprotected}} Although the current regex used in extraJS function matches the desired pages, as in


, it is also matching unwanted pages, as in:


I think it should be fixed to either of this options (possible the second one):


Couls someone fix it, please? Helder 00:22, 10 January 2011 (UTC)

✓ Done, thanks. --Dschwen (talk) 16:18, 10 January 2011 (UTC)
Darn. I had corrected that nearly a year ago,[3] but somebody broke it in October 2010.[4] Thanks for fixing it again. Lupo 16:44, 10 January 2011 (UTC)


This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

The following mapping is wrong:

window.importScriptURI = mw.loader.load;

Previously, importScriptURI also could load from URIs without protocol and server part (built just using wgScript or wgScriptPath instead of wgServer + wgScript or wgServer + wgScriptPath + ...). Hence the correct mapping would be

window.importScriptURI = function (uri) {
  if (uri && uri.indexOf (wgScriptPath + '/') === 0) {
    mw.loader.load (wgServer+uri);
  } else {
    mw.loader.load (uri);

Or alternatively rewrite mw.loader.load to not just test for "http" and "https", but also to allow URIs starting with wgScriptPath. Lupo 10:30, 21 February 2011 (UTC)

Nice catch! I was going to use mw.util.expandUrl, but I noticed that wasn't alive yet, and then forgot about it. Added it now and patched importScriptURI. –Krinkletalk 11:58, 21 February 2011 (UTC)


This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Shouldn't this be loaded with "&ctype=text/css" instead of "&ctype=text/javascript"? Firefox complains : was not loaded because its MIME type, "text/javascript", is not "text/css". Lupo 09:36, 28 February 2011 (UTC)

Pictogram voting keep.svg Fixed. Yet another reason to implement client-side modules native in ResourceLoader as soon as possible. This is the first thing on the list for ResourceLoader 2.0. For now they can be done manually with importStylesheet or mw.loader.load. Both with the disadvantage of being action=raw (unminified, seperate, individual, lesser-cached requests). Thanks for noticing, I had passed text/css to mw.loader.load but not to index.php, it needs both. Thanks, –Krinkletalk 09:57, 28 February 2011 (UTC)

bryan identified this as the cause of our IE crashtest. Maybe we need a browser switch here and disable only for IE. Or find the real cause. ;) Cheers --Saibo (Δ) 14:33, 28 February 2011 (UTC)

A bug with IE8 has been fixed in SVN rev:82963, and updated on Commons, and script re-enabled. Tested in Windows XP with IE8. –Krinkletalk 21:38, 28 February 2011 (UTC)
And you're sure nobody has still an old version of the script in the browser cache? See this report... Lupo 22:08, 28 February 2011 (UTC)

changes to rendering of collapsible templates

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Does anybody here can help with this discussion? --Jarekt (talk) 16:28, 7 April 2011 (UTC)

Was fixed in CollapsibleTemplates.css -- RE rillke questions? 16:37, 1 September 2011 (UTC)
This section was archived on a request by: RE rillke questions? 16:37, 1 September 2011 (UTC)

Document ready

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

If I understood correctly the code added in this edit should be inside of a $(document).ready(...) block like this:

$(function () {
    //Code here

so that it is only executed when the document is ready. What do you think? Helder 17:41, 12 May 2011 (UTC)

That would actually break it, unless you change MediaWiki:ImageStack.js as well. That code uses a document.ready handler as well, which will already have fired, so it would never be executed. --Dschwen (talk) 01:47, 13 May 2011 (UTC)
But how can $("div.ImageStack").length be true if the document is not ready? I mean, isn't necessary to wait until a page is ready before we try to access elements like that div? Helder 13:24, 18 May 2011 (UTC)
{{Imagestack}} works fine. Proposed answer: All scripts are loaded after the actual content. New issue: But the question is, whether this will be the same in future and the same on all browsers. -- RE rillke questions? 14:00, 18 May 2011 (UTC)
document ready is fired after all images and scripts are initialized. The DOM is finished (and accessible) before it even starts to load the scripts (they're at the bottom), so it safe in all environments. They will very likely be bottom-loaded in the future, since that's best practice for a lot of reason (including overall loading speed)--DieBuche (talk) 21:08, 29 May 2011 (UTC)
It's actually perfectly safe to use $(function () { ... }) (or $(document).ready(function () { ... })) even after the document has finished loading: jQuery detects this and just runs the code immediately. And indeed, any code relying on the DOM being fully available should technically be wrapped in such a manner, to make sure it doesn't run too early. However, DieBuche is also right that moving of scripts to the end of the document in recent MediaWiki versions pretty much eliminates the chance of premature execution anyway. —Ilmari Karonen (talk) 21:19, 29 May 2011 (UTC)

Swedish localization

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

{{editprotected}} Please add these text strings:

Under "Translations of the menu item"

'sv': 'Undersidor',

Under "JSconfig.registerKey('subPagesLink'"

'sv': 'Visa en länk för undersidor i verktygslådan',

Under "talkTextLocalization"

sv: 'Diskussion',

Thank you! // WikiPhoenix (Talk) 15:43, 1 June 2011 (UTC)

Done. Jafeluv (talk) 07:34, 7 June 2011 (UTC)

Link to delinker log broken in some cases

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

The link to the delinker log is broken in some cases (example: broken link). It might be caused by the presence of File: in the deletion reason. --Leyo 20:13, 7 July 2011 (UTC)

Suggestion: Therefore replace
$match = $( this ).find('a[title*="File:"]');
$match = $( this ).find('a[title^="File:"]');

-- RE rillke questions? 15:07, 26 July 2011 (UTC)

I did so, but I cannot see any change. --Leyo 15:18, 26 July 2011 (UTC)

Please purge your browser’s cache. (You only need to do it once.)

Internet Explorer: press Ctrl+F5, Firefox: hold down Shift while clicking Reload (or press Ctrl+ Shift+R), Opera/Konqueror: press F5, Safari: hold down Shift+alt while clicking Reload, Chrome: hold down Shift while clicking Reload Here, I can see the changes. But I've no access to your undelte link. -- RE rillke questions? 15:25, 26 July 2011 (UTC)

I certainly purged the cache, but the links only work now. No idea why. --Leyo 15:54, 26 July 2011 (UTC)
If you purge the cache immediately after saving you get the old version from the server sometimes. -- RE rillke questions? 17:01, 26 July 2011 (UTC)
That might have been the case. Thank you. --Leyo 17:29, 26 July 2011 (UTC)


This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

{{editprotected}} Hi!

Could someone apply these changes to the script?

  • The wg** variables are now accessed through mw.config.get('wg...');
  • Added some Portuguese translations which were missing;
  • Used $.inArray for repetitive tests of the same variables;
  • Used strict comparisons to '' and to false;
  • Some links now are created by mw.util.wikiGetlink;

Helder 20:38, 9 August 2011 (UTC)

✓ Done. – Adrignola talk 19:12, 26 August 2011 (UTC)

relative URLs

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)


A suggestion by DavidL from Commons:Administrators'_noticeboard following. As I do not know if it would break something I redirect this request to this page. ;-) Cheers --Saibo (Δ) 02:49, 1 November 2011 (UTC)

remove all http: prefixes for the following lines :

Done--DieBuche (talk) 07:35, 1 November 2011 (UTC)
Thanks. --DavidL (talk) 15:48, 1 November 2011 (UTC)


This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

I notice this in Common.js:

//REMOVEME in 1.18, since all toolbars will use $.fn.textSelection
 if (typeof $.fn.textSelection == 'undefined') {

Perhaps someone familiar with the issue could remove it, if it's now redundant. Rd232 (talk) 22:31, 12 November 2011 (UTC)

Thanks for reminding me. Done --DieBuche (talk) 10:04, 13 November 2011 (UTC)

Length of image filenames visible in categories

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Please see: Commons:Village pump#Need to be able to read more of the filename of images in categories. --Timeshifter (talk) 10:58, 2 December 2011 (UTC)

Shouldn't be in common.js. Should be a (default) gadget to enable people to switch it off easily. --Saibo (Δ) 16:05, 2 December 2011 (UTC)
Now available under Category tools -> Long Image Names in Categories. Shouldn't be on by default til it's been tested a bit and there is community agreement for it. Rd232 (talk) 16:31, 2 December 2011 (UTC)
Thanks! I found it here: Special:Preferences#mw-prefsection-gadgets in the section called "Interface: Files and categories". Category:Maps and its subcategories is a good place to see how much more helpful it is to be able to see the full filename of images. I suggest turning it on by default for a little bit. I bet people will soon appreciate it, and there will be little desire to have it turned off by default. --Timeshifter (talk) 07:18, 4 December 2011 (UTC)

Usergroup specific JS/CSS

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

MediaWiki 1.18 has usergroup specific JS and CSS. It's more efficient to use these than to use the existing system of loading via Common.js and showing only to those groups. I'm not sure exactly what changes need to happen; it's already been done on en.wp. See en:MediaWiki_talk:Common.js/Archive_19#Group-specific_JS_and_CSS. Rd232 (talk) 08:52, 19 December 2011 (UTC)

I tried MediaWiki:Group-sysop.css but it doesn't work?! -- RE rillke questions? 15:24, 5 January 2012 (UTC)
ok, seems to be the same problem as on en.wp: "but the messages actually loaded are MediaWiki:Group-Sysop.css." -- RE rillke questions? 15:40, 5 January 2012 (UTC)
No, created both MediaWiki:Group-Sysop.css and MediaWiki:Group-sysop.css but with no result. -- RE rillke questions? 16:03, 5 January 2012 (UTC)
The latter is correct. With ResourceLoader, it usually takes a few minutes to catch on. Edokter (talk) — 19:14, 5 January 2012 (UTC)
I see your rillketest. Red text on blue background... lovely! :) Rd232 (talk) 19:54, 5 January 2012 (UTC)
Still don't see it. Seems to me the system does not like me. -- RE rillke questions? 20:39, 5 January 2012 (UTC)
Have you tried emptying your cache? Edokter (talk) — 01:13, 6 January 2012 (UTC)
I found the error now. It was in my User:Rillke/common.css. The last ; stoppt the browser interpreting further and the sysop-code was appended after that. Sorry. Stupid mistake. -- RE rillke questions? 12:24, 6 January 2012 (UTC)
I see red text on a blue background, so MediaWiki:Group-sysop.css is correct. –Krinkletalk 00:46, 6 January 2012 (UTC)
Thanks for circus-testing ;-) -- RE rillke questions? 12:24, 6 January 2012 (UTC)
Yes check.svg Resolved

Usergroup-specific CSS moved by Rillke. Rd232 (talk) 18:48, 9 January 2012 (UTC)


This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Since mw.config.get('wgUserLanguage') gives the current language without a fallback check, both be-tarask and be-x-old are provided:

// for var subPagesLink.i18n
   'be-tarask': 'Падстаронкі',
   'be-x-old': 'Падстаронкі'

// JSconfig.registerKey('subPagesLink', true....
  'be-tarask': 'Паказваць спасылку на падстаронкі ў панэлі інструмэнтаў',
  'be-x-old': 'Паказваць спасылку на падстаронкі ў панэлі інструмэнтаў'

// var talkTextLocalization
   'be-tarask': 'Абмеркаваньне',
   'be-x-old': 'Абмеркаваньне'

// after "p.className = 'SVGThumbs';"
   'be-tarask': 'Гэтая выява ў фармаце PNG у іншых памерах: ',
   'be-x-old': ''Гэтая выява ў фармаце PNG у іншых памерах: '

Thank you! Wizardist (talk) 23:43, 7 January 2012 (UTC)

✓ Done  ■ MMXX  talk 01:02, 8 January 2012 (UTC)

MW 1.19

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

The following causes an error on

window.addPortletLink = mw.util.addPortletLink;

So wrapping?

mw.loader.using('mw.util', function() {
 window.addPortletLink = mw.util.addPortletLink;
 // ...

-- RE rillke questions? 14:54, 9 January 2012 (UTC)

Krinkle fixed it on wmflabs: and you might also want to see -- MarkAHershberger(talk) 05:16, 14 January 2012 (UTC)
This shows one more that the whole MW-stuff is not easy. It failed at the first occurence of $. mw.util.$content is still null, even when ivoked from inside a $(function(){ . -- RE rillke questions? 11:18, 14 January 2012 (UTC)
The correct construct for declaring mw.util dependency is:
/* Dependency loader (all code is wrapped in the callback) */
mw.loader.using( 'mediawiki.util', function() {
/* End dependency loader */ the top of Common.js, and:
/* Close dependency loader */
} );
/* DO NOT ADD CODE BELOW THIS LINE */ the bottom. This is now active on enwiki (both beta and live). Also, do not use function( $ ) as shown in the diff from the beta installation; mw.loader.using does not pass anything to the callback (if it would, it would overwrite the jQuery alias!). Edokter (talk) — 15:43, 17 January 2012 (UTC)
Forget I said that. Wrapping hides everything from the global scope. We need another way of preloading mw.util. Edokter (talk) — 17:30, 17 January 2012 (UTC)
OK, there is a solution for that as well; any function that needs to be visible to the 'outside' needs to be declared as window.functionName = function() { code };. The beta enwiki is now faultfree. Edokter (talk) — 01:51, 19 January 2012 (UTC)
I still don't understand why we should do a meaningless job to add this code to MW messages. Isn't it possible to add systemetically, by MediaWiki software? – Kwj2772 (msg) 16:01, 17 January 2012 (UTC)
Not js in MW-space only; all users using importScript or even (mw.util.)addPortletLink in their .js will be surprised if this goes live. Whahahahaha. -- RE rillke questions? 16:39, 17 January 2012 (UTC)
Not really. Wikibits.js isn't going anywhere soon, so these mapping are essentially pointless. The can be safely removed. But any userscript that uses mw.util or other modules, will indeed need to declare those dependencies as shown above. Edokter (talk) — 01:51, 19 January 2012 (UTC)
bugzilla:33760. importScript is a very often used function and depends on mw.util. If you tell the users to wrap their js inside the code above, they must update all /(\s|;)var\s+/ to $1window. that should be in global/window-scope. Perhaps we should write a bot if nothing changes before deployment. I think they will be surprised if it won't work anymore and they get "mw.util is undefined", instead ;-) -- RE rillke questions? 21:36, 19 January 2012 (UTC)
About the removing of wikibits.js, see bugzilla:33836. Helder 13:06, 20 January 2012 (UTC)

Links to Wikipedia

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

On every File:-page there is a link to a corresponing page on a version of Wikipedia. But since I am mainly not a Wikipedian, but a Wikisourcian, I would prefer a link to 'my' project instead. How can I do that? -- Lavallen 09:59, 1 May 2012 (UTC)

Hmmm. There is no way to detect your home-wiki without an extra XHR. So it will be a personal solution for you. BTW, the link is created from MediaWiki:Gadget-ExtraTabs2.js.
To change the link, put the following in your User:Lavallen/common.js:
if (6 === mw.config.get('wgNamespaceNumber')) mw.loader.using(['ext.gadget.ExtraTabs2'], function() {
	$('#ca-wppage').find('a').attr('href', '//' + mw.config.get('wgUserLanguage') + '' + mw.config.get('wgPageName'));
-- RE rillke questions? 10:31, 1 May 2012 (UTC)
Works fine, Thank You!!! -- Lavallen 10:52, 1 May 2012 (UTC)

Localisation for sl

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

Please, add the following translations for sl:

  • at 'JSconfig.registerKey('subPagesLink': " 'sl': 'Med pripomočki prikaži povezavo na podstrani', "
  • at 'localizeSignature': " sl: 'Pogovor' "
  • at 'function svgAltSize(w, title)': " 'sl': 'Prikaži to sliko v PNG-zapisu v drugih velikostih: ',

Thank you. --Eleassar (t/p) 07:52, 16 October 2012 (UTC)

✓ Done -- Rillke(q?) 15:52, 16 October 2012 (UTC)
Although I have cleared my cache, I still can't see the translation. --Eleassar (t/p) 16:01, 16 October 2012 (UTC)
In Firefox one has to Strg+ Shift+del and then delete the cache only for ever. Simple Shift+F5 or similar might not be enough. I can ensure that I see Prikaži to sliko v PNG-zapisu v drugih velikostih: 200px, 500px, 1000px, 2000px. at file pages. -- Rillke(q?) 16:08, 16 October 2012 (UTC)
Oh, sorry. It's ok; this was intended for another message. In any case, thanks for the tip. --Eleassar (t/p) 16:11, 16 October 2012 (UTC)

Chinese localization

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

{{edit request}} 'en': 'Subpages', // default --

'zh-hans': '子页面',
'zh-hant': '子頁面',

'en': 'Show a Subpages link in the toolbox', // default--

'zh-hans': '在工具箱显示一个子页面的链接',
'zh-hant': '在工具箱顯示壹個子頁面的鏈接',

'be-tarask': 'Абмеркаваньне',--

'zh-hans': '留言',
'zh-hant': '留言',

en: 'This image rendered as PNG in other widths: ',--

'zh-hans': '该图像转换为PNG格式的其他尺寸:',
'zh-hant': '該圖像轉換為PNG格式的其他尺寸:',

--Lee凡其Fanchy 19:27, 3 January 2013 (UTC)

✓ Done! Béria Lima msg 21:43, 3 January 2013 (UTC)

Farsi translation fix

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

{{Edit request}} Please fix the Farsi translation:

  • replace
fa: 'این تصویر به صورت پی‌ان‌جی در اندازه‌های دیگر نمایش داده‌شد',


fa: 'رندر پی‌ان‌جی این تصویر در اندازه‌های دیگر: ',

Thanks -- Meisam (talk) 14:10, 14 January 2013 (UTC)

✓ Done -- Rillke(q?) 13:10, 18 January 2013 (UTC)

Indonesian & Minangkabau localizations

This section was archived on a request by: Rillke(q?) 14:49, 19 July 2013 (UTC)

{{editprotected}} Please add localizations for "id" & "min"

// Translations of the menu item
   'id': 'Sub halaman',
   'min': 'Sublaman',

// JSconfig.registerKey('subPagesLink', true....
  'id': 'Tampilkan Sub halaman di kotak perkakas',
  'min': 'Tunjuakan Sublaman pado kotak pakakeh',

// var talkTextLocalization
   'id': 'bicara',
   'min': 'maota',

// after "p.className = 'SVGThumbs';"
   id: 'Gambar ini dijadikan PNG dengan lebar berbeda: ',
   min: 'Gambar ko dijadian PNG jo leba babedo: ',

Kind regards,  Ę-oиė  >>>  ™ 08:18, 17 May 2013 (UTC)

  • ✓ Done, thanks for helping! odder (talk) 11:19, 17 May 2013 (UTC)

Request translations of text to cy

This section was archived on a request by: Rillke(q?) 14:05, 19 July 2013 (UTC)

{{editprotected}} Please add localizations for "cy"

// JSconfig.registerKey('subPagesLink', true....
  'cy': 'Dangos cyswllt i Isdudalennau yn y blwch offer',

// var talkTextLocalization
   'cy': 'Sgwrs',

// after "p.className = 'SVGThumbs';"
   cy: 'Caiff y ddelwedd hon ei chynhyrchu mewn PNG yn y lled canlynol: ',

Lloffiwr (talk) 12:34, 19 July 2013 (UTC)

✓ Done Thanks for your help. -- Rillke(q?) 14:05, 19 July 2013 (UTC)

"Redirects" link in sidebar

Would it be a good idea to include a link in the sidebar under "subpages" that links to a listing of all the redirects to the current page? For example, it's possible with: {{fullurl:Special:WhatLinksHere/{{FULLPAGENAME}}|hidetrans=1&hidelinks=1}}. I would add it if I knew how. Rocket000 01:11, 4 June 2008 (UTC)

Possible but not needed. For "Subpages" you had to go to "Special pages", then PrefixIndex, then paste the page name, so the JS shortcut is very convenient. The suggested "redirects" link would not be as useful, because "What links here" is right here on every page. —AlexSm 16:51, 30 June 2008 (UTC)
This section was archived on a request by: whym (talk) 11:44, 30 September 2013 (UTC)

Add tab "validate CSS"


/** CSS validator ****************
 * Author: [[User:Kwj2772]] ******
 * License: Creative Commons Attribution-ShareAlike (BY-SA) 3.0 */
function validateCSS() {
    var validator = '' 
    var uri = wgServer + wgScript + '?title=' + wgPageName + '&action=raw&ctype=text/css'
    var encodeduri = encodeURIComponent(uri);
    var y = addPortletLink('p-cactions', validator + encodeduri, 'validate CSS', 'ca-validatecss',
                           'validate CSS', 'v', null);
if (wgTitle.match(/\.css/i) && (wgNamespaceNumber == 2 || wgNamespaceNumber == 8)) {

This script add the tab "validate css" when you visit css page. Now administrators don't have to type the address for validating Cascading stylesheet. To support some strange system like MediaWiki:Monobook.css/de, I intentionally removed "$". best regards.--Kwj2772 (msg) 12:51, 21 March 2009 (UTC)

This should be made a gadget. --Dschwen (talk) 21:47, 21 March 2009 (UTC)
And ✓ Done. Listed under Maintenance in the Gadgets section. --Dschwen (talk) 21:51, 21 March 2009 (UTC)
This section was archived on a request by: whym (talk) 11:44, 30 September 2013 (UTC)

Update window.wpAvailableLanguages

{{editprotected}} Please update the window.wpAvailableLanguages line with the new content of [5]. --Nemo 08:47, 3 April 2013 (UTC)

✓ Done -- Rillke(q?) 09:13, 3 April 2013 (UTC)
This section was archived on a request by: whym (talk) 11:44, 30 September 2013 (UTC)

Armenian translations

{{editprotect}} Please add the following translations:

var subPagesLink = {
        'hy': 'Ենթաէջեր',

JSconfig.registerKey('subPagesLink', true, {
        'hy': 'Ցույց տալ «Ենթաէջեր» հղումը գործիքների տուփում',

var talkTextLocalization = {
        'hy': 'Քննարկում',

var p = document.createElement('p');
        'hy': 'Այս պատկերը մատուցված որպես ՓիԷնՋի այլ լայնքերով՝ ',

Thank you, Chaojoker (talk) 18:55, 10 August 2013 (UTC)

✓ Doneebraminiotalk 13:36, 15 August 2013 (UTC)
This section was archived on a request by: whym (talk) 11:44, 30 September 2013 (UTC)

Serbian translation

{{editprotect}} Please add the following translations:

var subPagesLink = {
        'sr': 'Подстранице',

Thank you, --Milićević (talk) 17:12, 11 August 2013 (UTC)

✓ Doneebraminiotalk 13:36, 15 August 2013 (UTC)
This section was archived on a request by: whym (talk) 11:44, 30 September 2013 (UTC)

Turkish translated

{{editprotected}} Please add localizations for "tr"

// var subPagesLink = {
  'tr': 'Altsayfalar',

// JSconfig.registerKey('subPagesLink', true, {
   'en': 'Araç kutusunda alt sayfalara bir bağlantı gösterir',

// var talkTextLocalization = {
   'tr': 'Tartışma',

// var i18n = {
   tr: 'PNG olarak işlenen bu görüntünün diğer genişlikleri: ',

Thanks.--i.е. v-mail 02:10, 26 August 2013 (UTC)

✓  Face-smile.svg Thank you −ebraminiotalk 12:22, 26 August 2013 (UTC)
This section was archived on a request by: whym (talk) 11:44, 30 September 2013 (UTC)


{{Edit protected}}Please add bn translations..

i18n: {
'bn': 'উপপাতাসমূহ',

JSconfig.registerKey('subPagesLink', true, {
'bn': 'সরঞ্জাম-এ উপপাতাসমূহের লিঙ্ক দেখাও',

var talkTextLocalization = {
'bn': 'আলোচনা',

var i18n = {
bn: 'এই চিত্রটি অন্যান্য প্রস্থের মধ্যে PNG হিসেবে রূপান্তরিত: ',

--Aftab1995 (talk) 14:16, 27 August 2013 (UTC)

✓ Done Thanks for helping! Jean-Fred (talk) 14:47, 27 August 2013 (UTC)
This section was archived on a request by: whym (talk) 11:44, 30 September 2013 (UTC)

urlencode global usage / delinker log links

{{editprotected}} See bugzilla:53861. On File:Diallob&w.jpg, the & is not being escaped properly. You can change the following lines to fix this:

     guLink.attr('href', mw.util.wikiGetlink( 'Special:GlobalUsage' ) + '?target=' + filename );
     guLink.attr('title', 'Current usage of ' + filename + ' on all Wikimedia projects');
     cdLink.attr('href', '//' + filename);


     guLink.attr('href', mw.util.wikiGetlink( 'Special:GlobalUsage' ) + '?target=' + encodeURIComponent(filename) );
     guLink.attr('title', 'Current usage of ' + filename + ' on all Wikimedia projects');
     cdLink.attr('href', '//' + encodeURIComponent(filename));

Thanks! Legoktm (talk) 13:02, 9 September 2013 (UTC)

Done. Thanks for your help! -- Rillke(q?) 14:07, 9 September 2013 (UTC)
This section was archived on a request by: whym (talk) 11:44, 30 September 2013 (UTC)

Phase out newContentLoaded


Please phase out this new global variable newContentLoaded as soon as possible. It makes code harder to understand (non-standard, not compatible with anything on other wikis, nobody will know about it), and introducing globals with such generic names is generally a bad idea.

Also what is the purpose of it? This is exactly why I developed mw.hook in MediaWiki core (more specifically the wikipage.content event). To cover exactly this case where you want to use an event that can be triggered multiple times (unlike plain DOM-ready) for cases like LivePreview.

You do seem to be using mw.hook indirectly. Considering this newContentLoaded-method was only recently created here to fix a bug (the bug where code didn't run again on live preview) that wasn't fixed by other means before that, it would've been nice if you had attempted to file a bug first for whatever it is you need that makes you not want to use this directly (if you did file a bug, please link it below).

If there are cases where wikipage.content is not being fired yet and you have other events that you'd like to forward to it, feel free to .fire that directly, that's what it's there for.

Let me know how I can help. Thanks! –Krinkletalk 17:08, 17 July 2013 (UTC)

	if (mw.util.$content) launch(mw.util.$content);
This pattern also seems odd to me. This shouldn't have to be repeated everywhere. mw.hook uses a once "memory" to allow one to just add it, and if it's already there, it will be immediately invoked and if not, it'll be invoked (first, or again) whenever the event is fired. You can reproduce this even in newContentLoaded by giving $.Callbacks the "memory" flag, and calling .fire from Common.js accordingly. –Krinkletalk 17:15, 17 July 2013 (UTC)
Bugzilla:30713 needs to be fixed properly first. Then, I am inclined to remove it. But I will not add listeners to jQuery events on mw to each script. -- Rillke(q?) 20:38, 17 July 2013 (UTC)

Thanks for all the help here. -- Rillke(q?) 21:48, 13 November 2013 (UTC)

This section was archived on a request by: Rillke(q?) 21:48, 13 November 2013 (UTC)