MediaWiki talk:Common.js/Archive 1

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Subpages

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 [http://he.wikipedia.org/wiki/%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:%D7%A2%D7%A8%D7%9F ערן]
  */

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
        switch(wgUserLanguage)
        {
         case "he": // Hebrew
          subpages = "דפי משנה";
          break;
         case "de": // German
          subpages = "Subpages"; // pls translate
          break;
         case "fr": // French
          subpages = "Subpages"; // pls translate
          break;
        }
        aNode.appendChild(document.createTextNode(subpages));
        var subpagesLink='http://he.wikipedia.org/wiki/Special:Prefixindex/' + wgPageName +'/';
        aNode.setAttribute('href' , subpagesLink);
        liNode.appendChild(aNode);
        rcntChngsLnkdNode.appendChild(liNode);
    }
}
addOnloadHook(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') {
  uploadDescription.focus();
  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';
    break;
   default:
    uploadDescription.value = doubleBracket + 'Information\n|Description=\n|Source=\n|Date=\n|Author=\n|Permission=\n|other_versions=\n}}\n';
    break;
  }
 }
}
addOnloadHook(loadAutoInfomationTemplate);

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 he.wiki it basicly means "go for it, nobody objects". I say - add it (as I did in he.wiki), 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'));
  }
 }
}
addOnloadHook(userUploadsLink.install);

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'));
  }
 }
}
addOnloadHook(myUploadsLink.install);

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=="http://commons.wikimedia.org/wiki/Special:Upload") 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)

includePage

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 ) {
        watchlistMessage.style.display = "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");
     watchlistMessage.style.display = "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)

{{editprotected}}

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)

importScript

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)

ca

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)

gl

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)

et

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

addEvent

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)

{{editprotected}}

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, 15.4.4.11.) 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 http://commons.wikimedia.org/wiki/File:Broken_svg_test.svg?withJS=MediaWiki:CheckThumb.js . 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: 

importScript('MediaWiki:AjaxTranslation.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)

getISODate

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)

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 www.toolserver.org..." 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)

Editnotice

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:

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. ✓ Done –Krinkletalk 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)

POTY

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)

Localization

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

Please, add localization for Portuguese in the scripts:

i18n_edittools
      'pt': 'Usar edittools antigo',
      'pt-br': 'Usar edittools antigo'
UploadForm_loadform
  'pt': 'Usar a nova lógica do formulário de carregamento',
  'pt-br': 'Usar a nova lógica do formulário de carregamento',
UploadForm_newlayout
  'pt': 'Usar a nova aparência do formulário de carregamento',
  'pt-br': 'Usar a nova aparência do formulário de carregamento',
subPagesLink
  'pt': 'Subpáginas',
  'pt-br': 'Subpáginas',
JSconfig.registerKey('subPagesLink'
  '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',
os_suggest_width
  '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){
        importScript('MediaWiki:Edittools.js');
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 ആയി ലഭ്യമാകുന്ന മറ്റ് വലിപ്പങ്ങൾ: ';
            break;

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

✓ Done – Kwj2772 (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

javascript:alert('MediaWiki:FOO.js'.match("^MediaWiki:[^&<>=%]*\.js$"))

, it is also matching unwanted pages, as in:

javascript:alert('MediaWiki:FOOjs'.match("^MediaWiki:[^&<>=%]*\.js$"))

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

javascript:alert('MediaWiki:FOOjs'.match("^MediaWiki:[^&<>=%]*\\.js$"))
javascript:alert('MediaWiki:FOOjs'.match(/^MediaWiki:[^&<>=%]*\.js$/))

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)

importScriptURI

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)

MediaWiki:JQuery-makeCollapsible.css

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)

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:"]');
with
$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.)

Operating
system

Browser
 Microsoft Windows or Linux macOS
Internet Explorer Press Ctrl+F5
Mozilla Firefox Hold down ⇧ Shift while clicking Reload
(or press Ctrl+F5 or Ctrl+⇧ Shift+R) 		Press ⌘ Cmd+R (reload page) or
⌘ Cmd+⇧ Shift+R (reload page and rewrite cache)
Opera Press Ctrl+F5 or ⇧ Shift+F5
Konqueror
Apple Safari Hold down ⇧ Shift+Alt while clicking Reload
Press Ctrl+R Press ⌘ Cmd+⌥ Option+E (clear browser cache)
or ⌘ Cmd+R (update)
Chrome Press Ctrl+F5 or ⇧ Shift+F5
or hold down ⇧ Shift while clicking Reload 		Press ⌘ Cmd+F5 or ⇧ Shift+F5
or 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)

Updates

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)

{{editprotected|technical=yes}}

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)

Edittools-legacy

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') {
  importScript('MediaWiki:Edittools-legacy.js');

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

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

Be-tarask

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 http://deployment.wmflabs.org/commons_wiki/w/index.php?title=MediaWiki:Common.js 

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: http://en.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki%3AGadgets-definition&action=historysubmit&diff=54891&oldid=21968 and you might also want to see http://en.wikipedia.beta.wmflabs.org/w/index.php?title=MediaWiki%3ACommon.js&diff=54893&oldid=10825 -- ☠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 */
...at the top of Common.js, and:
/* Close dependency loader */
} );
/* DO NOT ADD CODE BELOW THIS LINE */
...at 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') + '.wikibooks.org/wiki/' + 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: 'این تصویر به صورت پی‌ان‌جی در اندازه‌های دیگر نمایش داده‌شد',

with 

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)

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"

{{Editprotected}} 

/** CSS validator ****************
 *
 * Author: [[User:Kwj2772]] ******
 *
 * License: Creative Commons Attribution-ShareAlike (BY-SA) 3.0 */
 
function validateCSS() {
    var validator = 'http://jigsaw.w3.org/css-validator/validator?&usermedium=all&warning=1&lang=en&uri=' 
    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)) {
        addOnloadHook(validateCSS);
}

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)

✓ Done −ebraminiotalk 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)

✓ Done −ebraminiotalk 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)

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

bn

{{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', '//toolserver.org/~delinker/index.php?image=' + filename);

Into: 

     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', '//toolserver.org/~delinker/index.php?image=' + 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

Hi,

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) 

	newContentLoaded.add(launch);
	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)

Japanese translation at Subpages

{{Editprotected}} 

*** 12:23, 14 October 2016‎
--- my edit
***************
*** 266,267 ****
--- 266,268 ----
    'is': 'Undirsíður',
+   'ja': '下位ページ',
    'ko': '하위 문서 목록',
***************
*** 314,315 ****
--- 315,317 ----
   'id': 'Tampilkan Sub halaman di kotak perkakas',
+  'ja': 'ツールボックスに「下位ページ」リンクを表示',
   'min': 'Tunjuakan Sublaman pado kotak pakakeh',

Thank you. Darklanlan (talk) 16:14, 17 December 2016 (UTC)

✓ Done --jdx Re: 17:43, 17 December 2016 (UTC)

Spanish translation

{{Edit protected}}

  • en: 'This image rendered as PNG in other widths: ' --> es: 'Esta imagen renderizada como PNG en otros tamaños: '
  • 'en': 'Subpages', --> 'en': 'Subpáginas',

Thanks. --Metrónomo's truth of the day: "That was also done by the president" not an excuse. 03:18, 7 October 2016 (UTC)

✓ Done The second one seems already done --Zhuyifei1999 (talk) 12:24, 14 October 2016 (UTC)

Esperanto Translation

{{Edit request}}

[en] → [eo]
Subpages → Subpaĝoj
Show a Subpages link in the toolbox → Montri subpaĝan ligilon en la ilaro
This image rendered as PNG in other widths:  → Ĉi tiu bildo en la aranĝo PNG kun aliaj larĝoj: 

(I am a registered Translatewiki translator but found no way of submitting these translations there.)

-- Renardo la vulpo (talk) 16:09, 16 July 2016 (UTC)

The three strings are in three separate variables. There is already a language definition for 'eo' itself and an entry for "Subpages" (in var subPagesLink). The "Show a Subpages..." text is in a JSconfig.registerKey call and the "This image rendered..." text is in var i18n (though it appears to be a regular space not &ampnbsp;). ✓ Done Added the 'eo' entries to these two last lists. DMacks (talk) 04:02, 22 July 2016 (UTC)

Croatian translation

{{Edit protected}}

'en': 'Show a Subpages link in the toolbox' -> 'hr': 'Prikaži poveznicu na podstranice u pomagalima'

en: 'This image rendered as PNG in other widths: ' -> hr: 'Prikaži sliku u PNG formatu u ostalim veličinama: '

Thanks.--Ma▀▄Ga 09:53, 22 June 2016 (UTC)

✓ Done Thank you! café --Hedwig in Washington (mail?) 03:24, 25 June 2016 (UTC)

Question about edittools

May I have some informations on how to add editools to the edit bar (for it wikipedia)?. Thanks a lot--Pierpao.lo (listening) 13:55, 17 April 2016 (UTC)

@Pierpao You need install MediaWiki:Edittools.js:
/**
 * Edittools
 * Formatting buttons for special characters below the edit field
 * Also enables these buttons on any textarea or input field on the page.
 * Maintainer: [[c:User:Lupo]]
**/
if ($.inArray(mw.config.get('wgAction'), ['edit', 'submit']) > -1 || mw.config.get('wgCanonicalSpecialPageName') === 'Upload')
	mw.loader.load('//commons.wikimedia.org/w/index.php?title=MediaWiki:Edittools.js&action=raw&ctype=text/javascript&maxage=604800&bcache=1')
I also agree to don't remove the original bottom Edittools (per option) maybe I could rewrite the script for this (it is also bit old). ↔ User: Perhelion 22:15, 17 April 2016 (UTC)
Thanks a lot User: Perhelion. Kind regards--Pierpao.lo (listening) 22:47, 17 April 2016 (UTC)
@Perhelion: why doesn't work on kkwiki? --Arystanbek (talk) 05:35, 7 October 2016 (UTC)

Already done! --Arystanbek (talk) 06:24, 7 October 2016 (UTC)

Vietnamese translation

{{Edit protected}}

Please translate the following into Vietnamese (vi):

Subpages
Trang con
Show a Subpages link in the toolbox
Hiển thị liên kết Trang con ở hộp Công cụ
This image rendered as PNG in other widths: 
Hình này được kết xuất ở dạng PNG có chiều ngang khác: 

Thanks!

 – Minh Nguyễn 💬 18:21, 21 September 2015 (UTC)

✓ Done Awesome! Thank you! Steinsplitter (talk) 18:25, 21 September 2015 (UTC)

importScriptURI

The line 

window.importScriptURI = function ( uri ) {

is causing a warning on every page: Use of "importStylesheetURI" is deprecated. Use mw.loader instead. Helder 16:50, 26 May 2015 (UTC)

@He7d3r: Thanks for reporting! Would be helpful if you can provide the fix foe this. :-). --Steinsplitter (talk) 17:28, 26 May 2015 (UTC)
I mean we can simple delete them, this function was only an hack anyway against the deprecation warning. ↔ User: Perhelion (Commons: = crap?)  17:49, 26 May 2015 (UTC)
+1 for removing. It was added in 2011, when we still didn't have the warning showing up in the console of users who didn't migrate their code. Helder 18:11, 26 May 2015 (UTC)
✓  Done --Steinsplitter (talk) 09:55, 28 May 2015 (UTC)

subPagesLink - Tuvan translation

{{Edit request}} Please add Tuvan translation in the subPagesLink section: 

'tyv': 'Адакы арыннар',

--Kaganer (talk) 13:11, 12 June 2014 (UTC)

✓ Done --Steinsplitter (talk) 13:20, 12 June 2014 (UTC)

importScript fails in IE8

I found that on test.wiki, the code if (typeof page === 'string') in importScript, makes the function fail in IE8. I don't know if it is causing the same problem here (haven't checked), but if that check isn't necessary, it should probably be removed. — Edokter (talk) — 21:10, 22 October 2012 (UTC)

Easy configuration

With more and more extensions added to the javascript files I thought it might be a good idea to create a common configuration mechanism. I created a mechanism with an easy API to register config variables, read and write them in cookies, and add form elements to the preferences page (where the user expects them). Check it out at MediaWiki:JSconfig.js. --Dschwen 09:00, 25 April 2007 (UTC)

I know this is an old section, but anyway: considering that the use of cookies are not as persistent as the gadgets (since the preferences are not kept when we change of computer), what about just using the Gadgets section for adding the options and, if needed, use a JS to move the option from that section to another one in the Special:Preferences page (this is just for organization of the page, but not really a big problem). This would help us to deal with problems like the one mentioned at MediaWiki_talk:Edittools#Disappeared. Helder 19:35, 14 November 2010 (UTC)
Sounds like a good idea, and not hard to implement either. I'll see what I can write up--DieBuche (talk) 20:12, 14 November 2010 (UTC)
& done--DieBuche (talk) 08:55, 15 November 2010 (UTC)
What about having also a section <legend>Gadgets</legend> in the end of each section of preferences page to which were moved/added options via jsconfig? This would make the skin to be more consistent.
Could you also add these localizations to MediaWiki:Gadget-OldEdittools/pt and MediaWiki:Gadget-OldEdittools/pt-br? Similarly, the translations of MediaWiki:Gadget-OldUploadForm which are in Common.js could be moved to the subpages of that MediaWiki message. Sorry, they are the negation of of each other: there is the option to "Use the old-style upload form layout" in gadgets and "Use new upload form layout" is also added by jsconfig. Aren't they mutually exclusive and redundant?
Another thing: for anonymous users, there is the option of creating something similar to wikt:Project:Wiktionary:Per-browser preferences. Helder 12:45, 15 November 2010 (UTC)

i18n in a separate file

i18n objects make this page kind of big. I suggest we take an approach already outlined in Mediawiki:Monobook.js: 

if (wgUserLanguage != 'en')
  document.write('<script type="text/javascript" src="/w/index.php?title=MediaWiki:Common.js/'
  +wgUserLanguage+'&action=raw&ctype=text/javascript"></script>');

Then all translations for all functions will be in separate files, and this will make it easier to submit new translations as well. — Alex Smotrov 20:37, 13 June 2007 (UTC)

I think this is a good idea, although I didn't quite understand where you intend to keep all the tranlastions. Are you saying we should open a 'MediaWiki:Common.js/he' for each language? Does this mean that we can get rid of the i18n's and instead use a regular var that will be declared in said subpage? BTW, what it the meaning of "i18n"? Yonidebest Ω Talk 12:19, 14 June 2007 (UTC)
en:i18n :-). I'd suggest a hash/object just like the i18n var only not indexed by language, but by message_id. The solution from Monobook.js/lang is unsatisfactory as it increases the chance of variable name clashes. --Dschwen 14:16, 14 June 2007 (UTC)
You define all text variables in main file Common.js (whatever way). Then in Common.js/lang you only change their values: so I don't see how having these language subpages can increase that chance. — Alex Smotrov 15:06, 14 June 2007 (UTC)
Yeah, its not the subpages that increase the risk, ist the load of global variables. They are visible to the other script files too, like the users monobok.js for example. IMO it is just good coding practice to minimize the amount od global variables. --Dschwen 20:05, 14 June 2007 (UTC)

I don't see why we can't use Alex's code in Commons.js and then have the lang subpages include the following code (MediaWiki:Common.js/en for example): 

i18n :
 {
  'subPagesLink'    : 'Subpages',
  'userUploadsLink' : ( 'User Uploads', 'Show upload list of this user' ),
  'myUploadsLink'   : ( 'my uploads', 'Show my upload list' ),
  'licenseChecker'  : 'The selected licensing is <b>unacceptable on Wikimedia Commons</b> and will lead to the <b>deletion</b> of your upload!'
 }

Is this what you ment, Dschwen? Yonidebest Ω Talk 21:41, 15 June 2007 (UTC)

PNGfix

Now that all bugs are ironed out, en:MediaWiki:Common.js succesfully implemented the PNGfix script, allowing IE 5.5 and IE6.0 to show PNGs (and SVGs) with full transparency support. So I propose to implement this script here as well. — Edokter • Talk • 13:38, 12 September 2007 (UTC)

Please add the following to MediaWiki:Common.js:

[Old code removed]

Superfluous. That's already achieved by fixalpha() on http://commons.wikimedia.org/skins-1.5/common/IEFixes.js Please explain why is this better (and such imprvment should be added to that file). Platonides 19:39, 13 September 2007 (UTC)
Fixalpha() is only used to display the logo. The devs never implemeted it for use on inline PNGs. But I agree that IEFixes.js would be a better place. You may want to follow the thread here. The script isn't quite done yet anyway, so forget it for the time being. — Edokter • Talk • 21:14, 13 September 2007 (UTC)
Edokter - funny how you said "bugs are ironed out" when the bug reports only started to come ∴ Alex Smotrov 14:39, 14 September 2007 (UTC)

Update: Changed code to latest by User:Remember the dot (15-09). — Edokter • Talk • 09:53, 15 September 2007 (UTC)

I see. Can you point to an image being fixed by this snippet? Platonides 13:02, 18 September 2007 (UTC)

PNGfix V1.1

PNGfix has been disabled on Wikipedia due to caching problem in one of the squids. The script is now on ice indefenitely. — Edokter • Talk • 22:51, 10 October 2007 (UTC)

The script is back on and working beautyfully on en.wikipedia, now with support for imagemaps. See en:Mediawiki:Common.js for the code. — Edokter • Talk • 17:50, 17 October 2007 (UTC)
Uh ... I wouldn't say "beautyfully" when the script required about 20 changes live on Common.js, and the last edit was made just today. Personally, I would wait a lot more before implementing that script anywhere ∴ AlexSm 20:27, 18 October 2007 (UTC)
It had growing pains, but most edits were optimizations and additions like support for background images and imagemaps. The latest version has also been running in my monobook for the past month prior to the last edit, so rest asured, if there were still issues, I'd know. — Edokter • Talk • 22:01, 19 October 2007 (UTC)

Still going strong

The script has been running on en.wiki about 1.5 years without change and without complaints. How about it? — Edokter • Talk • 17:16, 13 April 2009 (UTC)

Main page title

I saw Talk:Main Page#Tabs appear on the main page talk a little while back. Resolving the issue is straightforward enough: Just editing this page to include a similar exception code as is used on en.wp. However, I'm a bit leery of just doing it due to the multilingual situation. All the main pages should get a similar exception, which would make the addition quite bulky. Furthermore, we I don't think we would want the Main Page to say "main page" if the user is set up to French, or Accueil to be labelled "Accueil" for a English user.

Given this I'm not sure if its worth implementing and how best to given the internationalisation issues.--Nilfanion 00:24, 11 February 2008 (UTC)

Search default

A while ago a proposal to switch the default action of the search box from go to search passed unanimously. A bug got filed, nothing happened, somebody inquired on the COM:AN, and I wrote a javascript bit to switch the default button. This should be in common.js per community consensus. But I need some feedback whether this is working for everybody. Please help me by activating the gadget Change the default on the searchbox from Go to Search under Improved navigation. Thanks. --Dschwen (talk) 20:54, 23 March 2009 (UTC)

  • Works in FF 3.0.7, Safari 3.2.2 (WebKit 525.28.1) (doesn't highlight the default button), Opera 9.6.3. It crashed in IE 6 because you cannot change the type of an existing form element. I've fixed that, but IE 6 still invokes "go" when you hit enter in the search box. Might need an additional onkeyup handler on searchInput that would issue a click() on the search button when enter/return is hit, but that might conflict with the autosuggestion feature. I've tested with both autosuggestions on and off. Lupo 09:04, 24 March 2009 (UTC)
  • Added the keydown handler. Luckily, mwsuggest.js doesn't do anything with enter, so we don't get a conflict. Verified to work now in FF 3.0.7, Safari 3.2.2 (WebKit 525.28.1) (doesn't highlight the default button), Opera 9.6.3, and in IE 6, both with and without live suggestions. Lupo 12:10, 24 March 2009 (UTC)

var extraJS

Does any other JavaScript at the Commons rely on this variable existing and being set? If not, we could eliminate it. Lupo 11:11, 27 February 2010 (UTC)

Hopefully the whole script will be wrapped in a closure by RL soon. -- Rillke(q?) 14:49, 19 July 2013 (UTC)

InterProject

Is there any skin where InterProject doesn't work? If so, I think that it would be easier to simply add it here, instead of having several different skin pages only for this. We could for example use something like this: 

if (skin != "first skin where InterProject doesn't work" && skin != "second skin where InterProject doesn't work")
importScript('MediaWiki:InterProject.js);

This would make it easier to maintain it, because one wouldn't need to edit several pages at once when something about it changed (never say "never"). --The Evil IP address (talk) 15:41, 26 April 2010 (UTC)

It doesn't work on the Classic, Cologne Blue and Nostalgia skins, since they don't have the same portlet structure as the newer skins. However, you're right that we could just check for those skins and skip it. Also, the current version does contain some code to undo the CSS changes if it can't find a place to install the fake portlet, which should make it more or less safe to run even on incompatible skins.
While we're at it, we could also move the code directly into Common.js to save one importScript() call. Actually, we have quite a few .js pages that we could do the same thing with. If we're going to be pasting a lot of code into Common.js, though, someone ought to clean up the section structure (i.e. ensure that the code is divided into logical and (mostly) independent sections, that every section is preceded by a standard header describing its purpose and main author(s)/maintainer(s), and that any dependencies between sections are documented). Enwiki used to do that pretty well in their Common.js, though I see that their standards have also slipped a bit lately. —Ilmari Karonen (talk) 21:19, 26 April 2010 (UTC)
I think it would be great to merge them here. This would make it easier to directly see the code and make changes to it, instead of needing to go to another page. Concerning the original topic, I think the following code should do it, right?: --The Evil IP address (talk) 18:04, 29 April 2010 (UTC)
if (skin != 'standard' && skin != 'cologneblue' && skin != 'nostalgia') {
(insert code from MediaWiki:InterProject.js here)
}
Yes, that should do the trick. Oh, except that the internal name of the Classic skin is, confusingly enough, "standard". Fixed. —Ilmari Karonen (talk) 20:58, 29 April 2010 (UTC)

on error

That new onerror logger kept producing "Error: undefined at line undefined: [object Event]" for me on Safari. I couldn't figure out how to fix it, so I removed it for now, and I don't see any errors on the Console. Never had this issue with the old logger (producing errors, while I have no errors on console). TheDJ (talk) 12:37, 18 February 2011 (UTC)

Internationalization - i18n

Looking around through the scripts on commons, I discovered that every script uses it's own mechanism:

Therefore, I suggest creating one script containing all the translation-strings for each language. This has several advantages:

  • smaller scripts
  • reusable translations
  • less scripts and a central place for them

Are there any objections or support? -- RE rillke questions? 20:56, 29 May 2011 (UTC)

The next MW version will add support for i18n string loading, which will be bundled through ResourceLoader, so it's not an additional script anymore. Not sure if it's really worth the truble to bundle them till then--DieBuche (talk) 21:15, 29 May 2011 (UTC)
Then, it's probably not worth to change it. Do you think about mw:ResourceLoader/Migration_guide_for_extension_developers#Internationalization? What we'll have to change in our scripts? Where will the translation-strings come from? Thank you. -- RE rillke questions? 21:29, 29 May 2011 (UTC)

jQuery UI

{{Edit request}} The button one should be: 

button = $( '.ui-button', $c );

Note the $c. This means to search for descandants of the new content ($c). Superm401 - Talk 21:15, 13 November 2013 (UTC)

What is the benefit of doing so? Okay, it was slightly faster in a small performance test but isn't RL supposed to load modules only once? -- Rillke(q?) 21:47, 13 November 2013 (UTC)
It should indeed be faster. I think this is mainly because jQuery (or, for modern browsers, the browser APIs jQuery calls) only has to check elements under $c, rather than the whole HTML document. Like you said, it probably isn't a huge difference, but there's no downside.
Also, wikipage.content fires in multiple scenarios, including regular loads, live preview and VisualEditor. If $c is passed in, it doesn't matter when the new content actually hits the DOM, so it's more obvious to readers of the code.
It's true that modules will only load once even if you call using multiple times, though there is some code using goes through before checking that. Superm401 - Talk 08:14, 14 November 2013 (UTC)

MediaViewer decision for local administrators

en:User:MZMcBride posted the following comment on :en[6]:

As far as I can tell, putting the following code into MediaWiki:Common.js should do the trick:
mw.config.set("wgMediaViewerOnClick", false);
This makes the decision to enable or disable Media Viewer within the purview of local site administrators. There are a variety of ways to make this code conditional, such as only applying it to users who use a particular skin (Vector, Monobook, etc.), users who are in a particular user group (autoconfirmed, sysop, etc.), users with a specified edit count or account registration date, and much more!

--Túrelio (talk) 20:09, 10 July 2014 (UTC)

 Info That has been reverted by Eloquence because he believes that only a subset of the community shared their opinion in the RfC, if I understood correctly.
And:
MatmaRex: rillke: eh, that workaround was pretty broken
MatmaRex: whether it should be disabled or not is a separate matter, but it definitely shouldnt be disabled that way
Further information at en:Wikipedia_talk:Media_Viewer/June_2014_RfC#Decision_for_local_administrators
-- Rillke(q?) 21:13, 10 July 2014 (UTC)

TypeError: divs.forEach is not a function

User:Krinkle I think there might be a problem with your recent changes today. Not all browsers we support, support forEach on NodeLists e.g. older Chrome versions and IE 11. Jdlrobson (talk) 01:16, 18 April 2021 (UTC)

Fixed in Special:Diff/553982799 AntiCompositeNumber (talk) 16:30, 19 October 2021 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. AntiCompositeNumber (talk) 16:30, 19 October 2021 (UTC)

addPortletLink

@Jon (WMF), Lucas Werkmeister: It's well past the dates noted in the addPortletLink deprecation notification. Any reason it shouldn't be removed? AntiCompositeNumber (talk) 20:05, 17 October 2021 (UTC)

@AntiCompositeNumber ✓ Done in Special:Diff/599501282 – still has 346 uses according to search, but given that the function was already no longer working, the utility of shipping less JavaScript to all visitors ought to outweigh the inconvenience to those remaining users by now. Lucas Werkmeister (talk) 20:31, 17 October 2021 (UTC)
Thank you!
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. AntiCompositeNumber (talk) 16:26, 19 October 2021 (UTC)

JSconfig - Can't work anymore

Since any site-JavaScript admins and users can edit is disabled on Special:Preferences, JSconfig can't work as it should. Just test for JSconfig to confirm.

Therefore I suggest removing the code from Common.js and from all search-results. -- RE rillke questions? 14:47, 5 January 2012 (UTC)

Indeed, these should become separate ResourceLoaderified gadgets that can be enabled from their respective category on Special:Preferences#mw-prefsection-gadgets instead. –Krinkletalk 00:49, 6 January 2012 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. AntiCompositeNumber (talk) 16:13, 20 October 2021 (UTC)

function SVGThumbs() redundant

This function is completely duplicating core functionality. There is a duplicate set of links on file pages to render SVG images as different-sized PNG. I think it should be removed. -- [[User:Edokter]] {{talk}} 13:14, 4 July 2015 (UTC)

@Edokter: ✓ Done Thanks! :-) --Steinsplitter (talk) 13:44, 4 July 2015 (UTC)
Based on Commons:Village pump#SVGs as PNGs I reverted the removal for now. It needs to be discussed first. --Leyo 21:51, 7 July 2015 (UTC)
 pro removal. Unnecessary clutter for 99.99% of the visitors. -- Rillke(q?) 21:54, 7 July 2015 (UTC)
Not until the core functionality has been improved. 
Size of this preview: 800 × 568 pixels. Other resolutions: 320 × 227 pixels | 640 × 454 pixels | 1,024 × 727 pixels | 1,280 × 908 pixels.
Shortcomings include:
  • I does not say that the preview and the other resolutions are in the PNG format, whereas the original file is an SVG. On the other hand, the text in the script discussed here (This image rendered as PNG in other widths) is much more clear in this aspect.
  • 1,280 × 908 pixels is too small (e.g. for being used in print, in PowerPoint, etc.) for being the highest resolution offered.
  • The font size is too small for being read easily by elderly people.
--Leyo 22:11, 7 July 2015 (UTC)
 pro I'm also for removing this "hack", because it looks like a hack only. We have double lined redundant functionality which looks a bit unsettling/disturbing and unprofessional. But I agree to improve the core functionality. So we need a Phab task. ↔ User: Perhelion (Commons: = crap?)  07:28, 8 July 2015 (UTC)
The choice of sizes is controlled by mw:Manual:$wgImageLimits. If you want to change it, file a phabricator task linking to concensus for the new values (Note that config option affects all types of images). For the text of the line - that's controlled by mediawiki:show-big-image-other (Although that value doesn't have access to the file type of the preview. That could be changed though). How would you like that line to be phrased? Bawolff (talk) 08:37, 8 July 2015 (UTC)
@Bawolff: What!? No. We don't need consensus to port a js to mw. --Steinsplitter (talk) 09:20, 8 July 2015 (UTC)
@Leyo: Sorry, i haven't noticed that this is a 1x1 replacement. --Steinsplitter (talk) 09:21, 8 July 2015 (UTC)
Steinsplitter, linking to this and the village pump discussion should be "consensus satis" :) -- Rillke(q?) 09:33, 8 July 2015 (UTC)
Concensus is needed to change any mediawiki config for commons (or any other wiki for that matter), which includes the default other thumbnail size mw suggests on image pages. That's always been the case. Bawolff (talk) 01:16, 9 July 2015 (UTC)
No. Using common sense should be enough. Absolutely no need to over-bureaucratise this process. Looks like devs at Frisco are just putting stones in volunteers work. This is frustrating... --Steinsplitter (talk) 10:15, 9 July 2015 (UTC)
What's common sense to one person isn't common sense to another. Its always been the case that making changes to a specific wikis config requires some sort of agreement on that wiki (Some exceptions apply, like e.g. $wgCopyUploadDomains changes, but this hardly seems an exception). Bawolff (talk) 10:49, 9 July 2015 (UTC)
If we are spammed with inappropriate files from such a domain — as long as everything goes well, no one will complain… Back to topic: Do you already have an implementation of the required changes in MediaWiki in front of your imaginary eye? -- Rillke(q?) 20:12, 9 July 2015 (UTC)
https://gerrit.wikimedia.org/r/225682 Bawolff (talk) 11:08, 19 July 2015 (UTC)

@Bawolff: I thought that you as native English speaker or Edokter may have a good suggestion for the phrasing. --Leyo 16:46, 8 July 2015 (UTC)

Leyo: Would "Size of this PNG preview: 800 × 568 pixels. Other resolutions: 320 × 227 pixels | 640 × 454 pixels | 1,024 × 727 pixels | 1,280 × 908 pixels." satisfy your concerns? Bawolff (talk) 04:41, 9 July 2015 (UTC)
I am not sure if readers who are not familiar with SVG would unterstand why there is a different file type. Maybe something including Size of this preview rendered as PNG or even Size of this preview (SVG rendered as PNG) would help make things more clear? --Leyo 09:48, 9 July 2015 (UTC)

 Support removal. Helder 17:30, 9 July 2015 (UTC)

@Edokter: I don't think the additional resolutions are helpful. I just wonder if the JS (sorry for my zero knowledge of scripting) is capable of detecting the nominal (native in fact) width of the source SVG and then provide the PNG link of that resolution. Often time the text in the PNG render is off when the resolution isn't native to the source SVG. -- Sameboat - 同舟 (talk · contri.) 08:01, 10 July 2015 (UTC)
Javascript has no access to the image data. The core functionality does, so it can report the native size and derived resolutions. The javascript in Common.js only presents a few pre-set resolutions. -- [[User:Edokter]] {{talk}} 15:48, 10 July 2015 (UTC)
@Leyo: This is a very ugly hack and this should be removed asap. Maybe you like to file a bug on phabricator:? --Steinsplitter (talk) 16:00, 10 July 2015 (UTC)
No, the issues above need to be solved first. --Leyo 16:17, 10 July 2015 (UTC)
I mean that you file for this issue a bug on phabricator :-). --Steinsplitter (talk) 16:35, 10 July 2015 (UTC)
I'm sorry... What issues? You simply don't like the provided resolutions? What? I find the duplicate functionality, and the incurred payload that comes with it, a far greater issue then anything else. -- [[User:Edokter]] {{talk}} 18:02, 10 July 2015 (UTC)
This is very minimal JS and the "incurred payload" is very minimal. The JS has been here for 3 years, another week or two for calm discussion isn't going to hurt anything. Offnfopt(talk) 18:28, 10 July 2015 (UTC)
+1. Edokter, for the three issues you just need to scroll upwards. --Leyo 20:34, 10 July 2015 (UTC)
Those are really nitpicky, aren't they? I notice no one has files a bug yet. If you don't intend to address these issues in core, this hack should't be here. -- [[User:Edokter]] {{talk}} 10:07, 11 July 2015 (UTC)
They are not at all nit-picky. --Leyo 22:08, 12 July 2015 (UTC)
@Edokter: So that's impossible to detect the content of the file description page either (width figure between "norminally" and the multiplication sign). Indeed I prefer change to the core software instead of hack with additional JS. Has anyone filed a suggestion to phabi already? -- Sameboat - 同舟 (talk · contri.) 03:06, 11 July 2015 (UTC)
Not me at least (I have never done this). But first, we need to come to a conclusion on the three issues mentioned above. --Leyo 07:30, 11 July 2015 (UTC)
Tracked in Phabricator
Task T106263

So umm, what additional sizes do people want. I suggest 2048px and 3200px. I also filed a bug for this at phab:T106263. Bawolff (talk) 11:08, 19 July 2015 (UTC)

Thanks. I'm fine with these suggested sizes. Concerning size: What about having it in the same size as Original file ‎(SVG file, nominally 506 × 337 pixels, file size: 23 KB)? --Leyo 14:40, 19 July 2015 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. AntiCompositeNumber (talk) 16:05, 20 October 2021 (UTC)

Phase out duplicate SVGThumbs feature

This JavaScript customisation has been obsoleted by a near-identical feature that was developed by the community and added to MediaWiki in 2010 (phab:T8834). Our JS code was marked as "deprecated" in 2011 with edit Special:Diff/53837352. The MediaWiki feature was further improved by Brian Wolff in July 2014. The slower and jumpy JavaScript version we still have, was subsequently on-wiki (archive), and then removed (Special:Diff/164972783). It restored after following a discussion in July 2015 because it wasn't exactly the same.

As a result, over the past five years users are presented with two similar series of links, the latter of which pushes down the page a bit about a second after the page first appears. E.g. on File:Example.svg:

PNG preview of this SVG file: ….
Other resolutions: 240×240 pixels | 480×480 pixels | 768×768 pixels | 1,024 × 1,024 pixels
This image rendered as PNG in other widths: 200px, 500px, 1000px, 2000px.

What I've done today:

  • Unblocked phabricator task T106263, which was about adding "2048" to the list. There were performance concerns blocking this task until now, which I believe I've adequately addressed.
  • Drafted code change 680765, which implements this. Hopefully deployed within a week or two.
  • I've changed our JavaScript code to emulate what it will look like. Namely that it adds a 2048px link to the list (localised and all), and no longer adds the duplicate line as it did before. One of the things this fixes is that the numbers are now localised for non-Latin languages (try uselang=ar where it shows ٢٬٠٤٨ × ٢٬٠٤٨ instead of 2048 × 2048), and displayed in the correct order for right-to-left languages (previously it was always in the English order, thus reading from large to small for Arabic).

I've made this change today rather than waiting for the deployment, both to show you (almost) exactly what it will looks like, as well as to hear any feedback or concerns now rather than after the real code is deployed. That way, I can still easily and quickly respond to issues in real-time, and possibly revert if needed. --Krinkle 19:56, 17 April 2021 (UTC)

@Krinkle With gerrit:680765 merged and phab:T106263 close, this code is now a noop. Any objections to taking it out? AntiCompositeNumber (talk) 21:03, 12 September 2021 (UTC)
@AntiCompositeNumber: None, go ahead! Thanks, --Krinkle (talk) 23:41, 12 September 2021 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. AntiCompositeNumber (talk) 16:05, 20 October 2021 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=MediaWiki_talk:Common.js/Archive_1&oldid=708100206"