MediaWiki talk:Common.js

This interface message is documented at mw:Manual:Interface/Common.js.

Discussion

importExternalScript

Can we remove this function? It's an exact copy of importScriptURI and is only used

• User:Polyglot/monobook.js
• User:Karelklic/monobook.js

--Bequw → τ 19:24, 4 February 2010 (UTC)

Should be fine, might want to leave them (and Hippietrail who instated the function I think) a note. Conrad.Irwin 19:47, 4 February 2010 (UTC)

Neither of the scripts above are still using importExternalScript. Perhaps it could be deleted now. Kaldari 21:13, 31 March 2011 (UTC)

So would anyone object if I delete importExternalScript now? Kaldari 00:13, 2 April 2011 (UTC)

pre tags

Is there any reason that here we enclose sections between headers with <pre> tags to rather than <syntaxhighlight lang="javascript">? We'd get syntax highlighting on preview (and editing MediaWiki:JavascriptHeadings.js seems easy). --Bequw → τ 13:59, 2 March 2010 (UTC)

It's probably a convention that pre-dates (what pun?) the <source> tag, it's also considerably shorter. Supporting both in JavascriptHeadings.js would seem most sensible. Conrad.Irwin 15:01, 2 March 2010 (UTC)

Re: <syntaxhighlight> or <source>: yes, please do. Re: editing MediaWiki:JavascriptHeadings.js: can we change it to just ignore these tags, and go solely based on == and such? It currently takes a bit of effort to keep the edit-links correct at MediaWiki:Common.js — it regularly happens that one section will be missing a tag, and then every section after it has an edit-link that's off by one — and I just don't see the need for that. (I haven't really investigated, though; maybe there's reason I haven't noticed?) —Ruakh_TALK 15:38, 2 March 2010 (UTC)

Well, they aren't treated as headings inside <pre> tags. However, if all tags are removed, it should still work. Conrad.Irwin 17:01, 2 March 2010 (UTC)

Extra browser compatibility

I've added indexOf() to Array.prototype for compatibility (Note: the in operator should not be used to loop over array elements as it will erroneously pick up the prototype methods). Do we want to add any others? Or do something full-blown like w:MediaWiki:Gadget-JSL.js? --Bequw → τ 17:41, 2 March 2010 (UTC)

I have re-removed it, there is plenty of code around that relies on for ( .. in ..) (not least the copies User:Visviva/pretext.js which is the original version of the code you fixed on my page - we should put that into this page). Additionally, we don't want to add anything else like this; adding methods to prototypes for built in objects makes code much harder to copy and paste (which does happen); as it's not possible to analyse dependencies by looking at the source (it's particularly bad when it will work in some browsers, but not IE). Conrad.Irwin 19:11, 2 March 2010 (UTC)

I see it as a trade-off since w/o the prototype function(s) it's hard to get copy&pasted code to work because of js support in IE. If I had my druthers, the plenty of code would be fixed to use vanilla indexing allowing future editors to target more recent versions of js. But maybe that's a pipe-dream. --Bequw → τ 20:04, 2 March 2010 (UTC)

Right, but when you modify the prototype, there are few outward signs that they are missing bits of code - calling a global function that is missing is much easier to spot. I think we are supposed to be getting jQuery at some point, so maybe then we can use $.inArray() for this instead (until then, hacks include ",1,2,5,".indexOf(","+n+",") or {1:1,2:1,5:1}[n]). Conrad.Irwin 20:14, 2 March 2010 (UTC)

Collapsible tables

I would like to copy over the collapsible tables feature from Wikipedia. It would make working with declension tables and such a lot simpler. The relevant code is in my monobook.js and monobook.css and has not been edited in any way (it's just copy-pasted from here and here). An example of it in use is User:CodeCat/nl-conj. --CodeCat 14:30, 12 March 2010 (UTC)

I am not hugely in favour of having two different approaches to hiding things, perhaps we can modify the existing NavFrames to support tables as well (it is in a horribly mess at the moment, largely my fault). If we are to copy this code here too, it should be fixed so that clicking anywhere in the header (except on links) toggles the table, just as NavFrames have been so fixed. Certainly your version looks neater than Template:nl-conj, but I would suggest that is more of an argument against trying to over-colourize rather than an indication that we need table hiding. Conrad.Irwin 14:47, 12 March 2010 (UTC)

The issue with NavFrames is that it requires a two redundant wrapper divs. A div always fills the full width of the screen even if the content isn't that wide. Tables don't have that problem, so collapsible tables are more suited to inflection tables I think. --CodeCat 17:07, 12 March 2010 (UTC)

Here you can see the problem I'm talking about: Template:nl-conj-base. The div should increase width to fit its contents but instead it creates a scrollbar. I don't know a way to fix this, but it worked just fine with collapsible tables. So it would save a lot of headaches if it were implemented. --CodeCat 17:01, 16 March 2010 (UTC)

If you float it left you will get the width behaviour you want (then add a {{-}} to stop it overlapping). Note that the min-width stuff you have put into nl-conj-base does not work on IE6, nor IE7 or IE8 (I think they require you to set a width: as well). I wonder if there's a proper fix for this..., given that Wikipedia doesn't have it, I guess not. Conrad.Irwin 17:12, 16 March 2010 (UTC)

Solving it by floating seems rather hacky, and hacks have a tendency of breaking later under strange circumstances. So I still think allowing collapsible tables (or better yet, collapsible anything) would be a good idea for the future, especially as it works well on Wikipedia. I think I have it working now anyway, thanks for the help. --CodeCat 17:31, 16 March 2010 (UTC)

Per-page js/css?

Wikinews has an interesting system to have per-page js or css, automatically importing Mediawiki:Common.js/PAGENAME or Mediawiki:Common.css/PAGENAME where available. Perhaps we should have that system here too? --Yair rand (talk) 03:30, 16 August 2010 (UTC)

Do you see where we could use it? By my count we only condition the loading of additional JS for the following pages

• Help:Tips_and_tricks
• Special:Search
• Wiktionary:Main_Page
• Wiktionary:Per-browser_preferences

I'd imagine the cost of a lookup on every page-load would outweigh the benefits. I think it's a great feature for wikibooks where you could have educational/interactive scripts on each section. --Bequw → τ 04:35, 24 August 2010 (UTC)

Perhaps it would make sense to have it load per-page js/css while outside the main namespace. While currently only four pages use specific JS, there is the potential for many more. Portal-ish pages, certain project pages, and some appendices might be able to make use of the additional control, and some help pages might be designed with javascript (interactive tutorials, perhaps?). I'm also very annoyed at the fact that there is no simple way to demonstrate proposed Javascript or CSS. (See for example MediaWiki talk:Common.css#Possible change to expandable tables, where no one can see what it is I'm proposing unless they add the code to their monobook.css.) --Yair rand (talk) 05:14, 24 August 2010 (UTC)

We don't have very much per-page or even per-namespace JS. What JS there is now can be included in Common. If so much is added to Common that it becomes unwieldy, I think it'd make sense to split it off, but until that happens I don't see why we should.​—msh210℠ (talk) 15:38, 24 August 2010 (UTC)

How about loading a page-specific script only if a tag with a specific id is on the page? (addOnloadHook(function(){if(document.getElementById('loadscript')){importScript('Mediawiki:Common.js/'+wgPageName)}})) --Yair rand (talk) 10:11, 24 November 2010 (UTC)

We don't have very much per-page or even per-namespace JS. What JS there is now can be included in Common. If so much is added to Common that it becomes unwieldy, I think it'd make sense to split it off, but until that happens I don't see why we should.​—msh210℠ (talk) 16:17, 24 November 2010 (UTC)

WiktionaryDisableAutoRedirect

Where and how is the cookie WiktionaryDisableAutoRedirect set? It's used to disable the auto-redirect feature. Malafaya 15:01, 16 August 2010 (UTC)

See WT:Per-browser preferences, the option labelled "Disable the javascript redirect between pages that differ only in case." --Bequw → τ 18:12, 16 August 2010 (UTC)

Thanks. The page says "You must have JavaScript and cookies enabled to set your browser-specific English Wiktionary preferences." but I have both enabled in Firefox 3.6.8... Malafaya 21:31, 18 August 2010 (UTC)

Works for me. Do you have the very top checkbox enabled? It won't stop internal search redirection (like entering "Bookshelf" in the search box), just ones where you link directly to the uppercase form (ie Bookshelf) or where you type that same URL into your location bar. --Bequw → τ 04:32, 19 August 2010 (UTC)

The prefs stopped working for some people right after the page was moved. You might have to purge your cache in order for the update of Common.js to take effect. --Yair rand (talk) 04:37, 19 August 2010 (UTC)

rare skins

How much do we care about making scripts work in anything but Monobook & Vector? We obviously don't strive for full functionality, but do we try to prevent JS errors or page-visible errors? I've found that collapsible box can't collapse in standard, cologneblue, modern and nostalgia. I've also found that we produce JS errors for those same skins (usually in visibility toggling & make_tab_red()). --Bequw → τ 04:41, 24 August 2010 (UTC)

Dunno about anyone else, I would say that I care a little bit: if someone points out a specific problem, I would put in a bit of effort to try to fix it, but if I'm making a change, I won't bother to test it in those skins, and I won't feel like I've "messed up" if it turns out to break something in one of them. —Ruakh_TALK 02:36, 27 August 2010 (UTC)

User:Conrad.Irwin/editor.js

Please remove this as the trial run has ended: TeleComNasSprVen 04:48, 27 October 2010 (UTC)

/** Trial run 2009-04-14. Please disable if causing problems. **/

Using localStorage instead of cookies

Proposal: Replacing the existing setCookie and getCookie functions with this:

function setCookie(cookieName, cookieValue) {
 if('localStorage' in window){
  localStorage[cookieName] = cookieValue
 }else{
  var today = new Date();
  var expire = new Date();
  var nDays = 30;
  expire.setTime( today.getTime() + (3600000 * 24 * nDays) );
  document.cookie = cookieName + "=" + escape(cookieValue)
                  + ";path=/"
                  + ";expires="+expire.toGMTString();
  // We need to delete the more specific paths for the next while. Safe to remove this by July 2011, if not before.
  document.cookie = cookieName + "=" + ";path=/w" +
   ";expires=Thu, 01-Jan-1970 00:00:01 GMT";
  document.cookie = cookieName + "=" + ";path=/wiki" +
   ";expires=Thu, 01-Jan-1970 00:00:01 GMT";
 }
}

function getCookie(cookieName) {
  if('localStorage' in window)
    return localStorage[cookieName]||'';
  var start = document.cookie.indexOf( cookieName + "=" );
  if ( start == -1 ) return "";
  var len = start + cookieName.length + 1;
  if ( ( !start ) &&
    ( cookieName != document.cookie.substring( 0, cookieName.length ) ) )
      {
        return "";
      }
  var end = document.cookie.indexOf( ";", len );
  if ( end == -1 ) end = document.cookie.length;
  return unescape( document.cookie.substring( len, end ) );
}

--Yair rand (talk) 21:34, 16 January 2011 (UTC)

Since this change would ordinarily wipe everyone's preferences, we should probably also have something like this to switch over everyone's prefs to localStorage:

function switchCookiesToLocalStorage()
{
  var q=['WiktPrefs','Visibility','WiktPrefPatrolRefresh','preferencesEditorJs','WiktPrefPatrolFast','WiktNearbyPagesNavbar','WiktionaryPreferencesTimeUTC','WiktionaryPreferencesTickClock','WiktionaryPreferencesShowNav','WiktionaryDisableAutoRedirect','WiktNearbyPagesLangHeadings','WiktNearbyAlwaysLTR']
  for(var i in q){
    if(document.cookie.indexOf(q[i]+'=') != -1){
      localStorage[q[i]] = document.cookie.substr(document.cookie.indexOf(q[i]+'=')).match(/[^=]*(?=[;$])/)
    }
  }
  localStorage.switchedtoLS = 1
}

if('localStorage' in window && localStorage.length==0 && document.cookie){
  addOnloadHook(switchCookiesToLocalStorage)
}

It could be eliminated after about a month when everyone's prefs have been switched over to localStorage. --Yair rand (talk) 00:59, 18 January 2011 (UTC)

What would the trade-off be? Do we want to be able to store more data? From what I've read, localStorage doesn't expire its data like cookies do, so that's a mild benefit. --Bequw → τ 14:32, 18 January 2011 (UTC)

That, and that the system of storing data in cookies in annoyingly complicated. Also, cookies (I think) are pointlessly sent to the servers all the time, when its only purpose is to be stored locally so that the browser can do some javascript. --Yair rand (talk) 17:50, 18 January 2011 (UTC)

Fewer users have localStorage than have cookies (even IE7 and Firefox 3.0 didn't have localStorage). When it is present it gives you 5MB of persistent storage, vs a few kilobytes for cookies, so it may be worth using in addition thereto. Conrad.Irwin 08:03, 19 January 2011 (UTC)

Don't you guys want to eventually migrate from using Wiktionary:PREFS to using Gadgets? That way you wouldn't have to store anything. Also, LocalStorage is usually used for things like image and data caching. I don't really see much of an advantage to using it over cookies for storing small values, as you can easily set cookies to last for several years (although this is not a good idea in my opinion, as you end up with useless cookie-cruft in the long term). Kaldari 18:34, 3 April 2011 (UTC)

We use cookie-based preferences for other things besides just WT:PREFS; our show-hide infrastructure, for example. —Ruakh_TALK 18:56, 3 April 2011 (UTC)

importScript

Is there any reason we need a redundant copy of importScript() here? Kaldari 20:04, 31 March 2011 (UTC)

If you could give details on where the "core" copy is, so the locals can examine it, can confirm that it's the same as our copy, can confirm that it applies to all skins, etc., then we can judge for ourselves whether our copy is actually redundant and should be removed. (I don't particularly doubt it, but a second pair of eyes never hurts.) —Ruakh_TALK 20:09, 31 March 2011 (UTC)

My apologies for not discussing this first. I'm trying to help clean up the custom JS across all the wikis, but obviously I shouldn't treat en.wiktionary the same as the smaller projects. The code is in skins/common/wikibits.js. It's basically the same as the code here except it doesn't have the extra parameters. I wasn't able to find any examples of any script here that actually uses the extra parameters, but if there are, let me know and I'll be happy to update them. I should also mention that at this point importScript is not only redundant, but also deprecated. People should not be using this style of Javascript loading at all anymore, but should be using mediaWiki.loader instead. But that's neither here nor there. Kaldari 21:04, 31 March 2011 (UTC)

I really hope you're not talking about mediaWiki.loader.load, because that function is utterly awful. --Yair rand (talk) 22:03, 31 March 2011 (UTC)

Depends on what you're trying to do, but regardless, importScript() was moved into core specifically so that every wiki doesn't have to have it's own custom version, so I would recommend deprecating the one here, as well as deleting importExternalScript() (which seems to be completely unused). Kaldari 22:16, 31 March 2011 (UTC)

BTW, it does look like there are a few people using the extra parameters, for example User:Korodzik/monobook.js. Kaldari 22:21, 31 March 2011 (UTC)

Yes, WT:ACCEL says to add importScript('User:Lupin/autoedit.js', 'en.wikipedia.org','46637295');. --Yair rand (talk) 22:24, 31 March 2011 (UTC)

The problem that that oldid param was created to workaround was fixed back in 2008. Since the instructions were never updated, the workaround is now a bigger problem than the original problem :( Kaldari 22:53, 31 March 2011 (UTC)

What the heck is Wiktionary:PREFS? Are you guys not using Gadgets at all? Kaldari 22:45, 31 March 2011 (UTC)

I feel like I just looked into the abyss: User:Hippietrail/custom.js. I guess you guys have gone way off on your own as far as site Javascript. Why did you guys abandon using Gadgets? Kaldari 23:13, 31 March 2011 (UTC)

PREFS predates gadgets by several years, I think. A lot of people prefer PREFS because it's cookie-based, and can be used by IPs. --Yair rand (talk) 23:29, 31 March 2011 (UTC)

I could see the advantage for IPs, but surely a cookie-based system would be a lot less convenient for everyone else. Everytime you switch computers or browsers, or clear your cookies, or wait 30 days, you would have to reset them all. Has anyone proposed migrating these scripts to Gadgets instead? It would also lower the overhead for page loading. Kaldari 23:39, 31 March 2011 (UTC)

It's been proposed before, see Wiktionary talk:Per-browser preferences#Move to Gadgets tab in Special:Preferences ?. --Yair rand (talk) 23:50, 31 March 2011 (UTC)

(Also, gadgets have a tendency to mess up. My gadget preferences have been frozen for quite a while. --Yair rand (talk) 23:36, 31 March 2011 (UTC))

What do you mean by "frozen"? Kaldari 23:39, 31 March 2011 (UTC)

None of the preferences can change. I check some boxes, click "Save", and as soon as it says "Your preferences have been saved." the boxes are unchecked and the preferences haven't changed. --Yair rand (talk) 23:45, 31 March 2011 (UTC)

Weird. You may want to try Special:Preferences/reset. This often fixes problems like that, but the downside if you have to set all your preferences again. Kaldari 23:48, 31 March 2011 (UTC)

I tried it. Didn't help. I'm not the only one having this issue, btw, and I suspect that gadgets are frozen for everyone. --Yair rand 23:54, 31 March 2011 (UTC)

They work fine for me. I wonder if some user script is interfering somehow. Kaldari 00:11, 1 April 2011 (UTC)

Main Page fixes

I would like to suggest replacing:

if ( wgPageName == 'Wiktionary:Main_Page' && !( wgAction == 'view' || wgAction == 'submit' ) ){
  addCSSRule('.firstHeading','display: block !important;');
  addCSSRule('#contentSub','display: inline !important;');
 
} else if (wgPageName == 'Wiktionary:Main_Page' || wgPageName == 'Wiktionary_talk:Main_Page') 
    addOnloadHook(function () {
        mw.util.addPortletLink('p-lang', 'http://meta.wikimedia.org/wiki/Wiktionary#List_of_Wiktionaries',
                 'Complete list', 'interwiki-completelist', 'Complete list of Wiktionaries')
        var nstab = document.getElementById('ca-nstab-project')
        if (nstab && wgUserLanguage=='en') {
            while (nstab.firstChild) nstab = nstab.firstChild
            nstab.nodeValue = 'Main Page'
        }
    }
)

with:

if ( wgPageName == 'Wiktionary:Main_Page' && !( wgAction == 'view' || wgAction == 'submit' ) ){
    mw.util.addCSS( '.firstHeading { display: block !important; }' );
    mw.util.addCSS( '#contentSub { display: inline !important; }' );
}

if (wgPageName == 'Wiktionary:Main_Page' || wgPageName == 'Wiktionary_talk:Main_Page') {
    $(function () {
        mw.util.addPortletLink('p-lang', 'http://meta.wikimedia.org/wiki/Wiktionary#List_of_Wiktionaries',
                 'Complete list', 'interwiki-completelist', 'Complete list of Wiktionaries');
        var nstab = document.getElementById('ca-nstab-project');
        if (nstab && wgUserLanguage=='en') {
            while (nstab.firstChild) { nstab = nstab.firstChild; }
            nstab.nodeValue = 'Main Page';
        }
    });
}

This removes some deprecated functions and fixes the weird logic - there's no reason that the tab shouldn't be changed on the Main Page if you're doing something like purging or viewing history. Kaldari 19:23, 3 April 2011 (UTC)

document.getElementById is a deprecated function? Deprecated by whom? —Ruakh_TALK 19:29, 3 April 2011 (UTC)

No, I just changed that one so the code would be more concise. Kaldari 20:48, 3 April 2011 (UTC)

IMO, changing simple JS into complicated jQuery is never a good idea, even if it makes it a couple bytes shorter. In this particular case, the JS you suggested wouldn't even work, because jQuery objects aren't actual nodes and don't have regular node properties, and jQuery objects return boolean true even if there are no matches. (There's also a ) at the end of your code instead of a }, btw.) --Yair rand 21:06, 3 April 2011 (UTC)

My bad, fixed now. Kaldari 21:21, 3 April 2011 (UTC)

. . . and, I now see that "addCSSRule" is a function that we were defining, and that a non-Wiktionarian deprecated a month and a half ago, in this edit, turning it into a wrapper function for mw.util.addCSS. I wonder if any testing went into that? Or if someone at least read through the function to make sure they understood its behavior? (And the same goes for the other changes in that edit.) —Ruakh_TALK 22:20, 3 April 2011 (UTC)

rickrolling

What's with the rickroll edit war? Is this some extra late April Fools joke? Nice job with the obfuscation, BTW :) Kaldari 21:03, 3 April 2011 (UTC)

MediaWiki:Common.js/IE60Fixes.js

   // Import scripts specific to Internet Explorer 6
   if (navigator.appVersion.substr(22, 1) == "6") {
       importScript("MediaWiki:Common.js/IE60Fixes.js")
   }

The above lines, from the section "Scripts specific to Internet Explorer", seem to import MediaWiki:Common.js/IE60Fixes.js, which does not exist, for users using IE6. Anyone know what this is about? --Yair rand 07:04, 13 June 2011 (UTC)

"don't react when a subitem is clicked" for NavBoxes

Why does clicking on subitems of NavHeads not expand the box? This causes problems for NavHeads with words that need to have a surrounding span to have a lang parameter set. Couldn't the rule just be limited to links? --Yair rand (talk) 00:53, 13 September 2012 (UTC)

I strongly agree. This has always bothered me, I don't know why I've never bothered to set about fixing it. —Ruakh_TALK 00:56, 13 September 2012 (UTC)

Done. --Yair rand (talk) 16:59, 14 October 2012 (UTC)

IE8 problem

The doRedirect function, namely this code

        var target = jQuery('#did-you-mean a').html(),
            pagetitle = jQuery('h1').first().text().trim();

throws a JS script "object does not support property" on every page load. Malafaya (talk) 10:14, 18 September 2012 (UTC)

I was suggested to use

pagetitle = jQuery.trim(jQuery('h1').first().text());

instead. Malafaya (talk) 10:47, 18 September 2012 (UTC)

Changing the addition namespace tabs for articles

I am interested in creating an additional namespace tab for articles, as appears here with the citation tab and namespace. This will be for another wiki that I plan to create, which will be a peer reviewed history wiki that limits editing of main articles to approved user groups. The talk page will remain open to anyone who suggests changes, and I plan to add an additional draft namespace in addition to the talk namespace that will allow all users to edit a draft version of the article without allowing any user to make changes to the article itself.

How do I modify the the JS for the additional tab to make it function with the draft namespace?

Inquisitor Sasha Ehrenstein des Ordo Scharzenkommando 18:52, 13 November 2012 (UTC)

Geonotice

@Kephir, @Dominic: the code which loads the geonotice was copied from w:en:MediaWiki:Common.js/watchlist.js, but since then they stopped loading data from toolserver, so I think the code

importScriptURI('http://toolserver.org/~para/geoip.fcgi');
addOnloadHook(function() { importScriptURI('http://en.wiktionary.org/w/index.php?title=MediaWiki:Geonotice.js&action=raw&ctype=text/javascript&maxage=3600'); });

should be updated to

$( function() {
	mw.loader.load( '//en.wiktionary.org/w/index.php?title=MediaWiki:Geonotice.js&action=raw&ctype=text/javascript' );
} );

Or it could just be removed, since it was not used in the last few years. Helder.wiki 21:41, 25 July 2014 (UTC)

See also w:en:Wikipedia:Village pump (technical)#Migrating Geonotice to a gadget for an implementation of this as a gadget. Helder.wiki 13:34, 27 July 2014 (UTC)

What is a geonotice and why would I need one? — Keφr 14:50, 27 July 2014 (UTC)

@Kephir: this is documented on w:en:Wikipedia:Geonotice. Helder.wiki 15:37, 27 July 2014 (UTC)

As a friendly side note, User:Helder.wiki: because your signature does not link to your Wiktionary user page, I fail to get pings from you (and so does User:Dominic). I suggest you change that. (Never mind it makes you look like a tourist from a foreign wiki, which we tend not to appreciate very much. And my signature reformatter chokes on it.) — Keφr 16:12, 27 July 2014 (UTC)

Done. Helder 03:11, 28 July 2014 (UTC)

Anonymous users

@Kephir: Isn't better to use mw.user.isAnon() instead of a custom test mw.config.get('wgUserGroups').indexOf('user') === -1? Helder 11:52, 21 September 2014 (UTC) PS: IE8 does not have indexOf for arrays

Maybe. I never noticed that function exists. Though well…

      mw.user.isAnon.toString()
/*=*/ "function (){return user.getName()===null;}"
      mw.user.getName.toString()
/*=*/ "function (){return mw.config.get('wgUserName');}"

…so I am not convinced it makes a huge difference, really. In fact, I suspect using mw.user would require me to declare a dependency on some ResourceLoader module (mw.config does not, as far as I know), and I could speculate whether wgUserName could some day contain the user's IP, which would make the built-in check worse. (Sucks to be an IE8 user, I guess. But MediaWiki has a built-in ECMAScript 5 shim library, so I think it should work even for them.) — Keφr 12:06, 21 September 2014 (UTC)

@Keφr: Yes, the function is part of the module mediawiki.user, but it is a supported way (with qunit tests) to detect if the user is anonymous (and is used by core itself), the built-in check will certainly be updated to match any eventual change to the value of wgUserName (creating a custom test will requiring updating it to match that hypothetical change).

As for the built in shim, it won't be loaded unless you add a dependency on module es5-shim. Helder 14:04, 21 September 2014 (UTC)

Category fixes problem

diff: content.replace(/^Requests for (?:verification|deletion|cleanup) in (.+) entries$/, "$1");

I think the conditions under which this code is to be executed should be more strict. At Category:Requests concerning Swedish, it currently transforms three separate categories into the unhelpfully terse "Swedish". @Daniel Carrero, Dixtosa, Giorgi Eufshi —suzukaze (t・c) 07:37, 22 September 2017 (UTC)

I have added a check. I hope it is not too strict. Dixtosa (talk) 13:18, 23 September 2017 (UTC)

Mobile site

The Hidden Quotes script isn't being run on the Mobile site, where I think it would be quite useful. Should it be moved to a default hidden gadget with targets=desktop,mobile? --Yair rand (talk) 19:23, 12 September 2018 (UTC)

See also Wiktionary:Grease pit/2018/September#Mobile_display_of_Chinese_characters_-_every_infobox_is_expanded, about possibly migrating/copying some other code that shows/hides content. I recall that some similar code (for the inflection-table View Switcher) didn't work on the mobile site the last time we tried to copy it over to MediaWiki:Mobile.js. In fact, it seems like the quote-hiding code is present there(?) so it should be running... - -sche (discuss) 21:26, 12 September 2018 (UTC)

@-sche: I don't see the quote-hiding code anywhere on Mediawiki:Mobile.js. --Yair rand (talk) 22:58, 12 September 2018 (UTC)

Oh, I see, the "hide ▲" functionality that's included there is (only?) for translations tables and the like. Well, I'd be in favor of copying the quotation-hiding code over. - -sche (discuss) 23:28, 12 September 2018 (UTC)

viewSwitching toggle label

It would be nice if we could specify the text used in the toggle link of viewSwitching. I think this bit of code would accomplish that: if (className[0] == 'vsButtonText') { showButtonText = hideButtonText = className[1];}. @Dixtosa, -sche, Erutuon, is that something that can be added? --Victar (talk) 17:09, 21 November 2018 (UTC)

Hmm, the code doesn't seem quite correct. showButtonText plus a comma just accesses a variable with no effect. To use the second hyphen-separated part of the class name as the text for both the show and hide buttons: showButtonText = hideButtonText = className[1].

Do you want to be able to specify separate show and hide text? Perhaps hide text could be set to className[2] if that is present, otherwise to className[1], so you can use either vsButtonText-showText-hideText or vsButtonText-showAndHideText as class name.

Probably should account for the case in which className[1] is undefined or empty. Would it be better to use the default text or have the button be invisible? — Eru·tuon 22:20, 21 November 2018 (UTC)

@Erutuon, just specifying the one label for both showButtonText and hideButtonText is fine for my needs, but if you think people would benefit from having the option for both, go for it. Thanks! --Victar (talk) 18:12, 21 November 2018 (UTC)

@Victar: I'm not an interface admin, so am just offering thoughts on the code. — Eru·tuon 06:09, 22 November 2018 (UTC)

Ah. @Dixtosa, -sche? --Victar (talk) 06:15, 22 November 2018 (UTC)

Yes, that can be added. What's the best use case for it though? Dixtosa (talk) 10:18, 23 November 2018 (UTC)

Best case? I mean, I'd like to use it the module I'm working on, but I can see people making use of it elsewhere. --Victar (talk) 05:26, 25 November 2018 (UTC)

Ok whatever. I have added the support of customizable texts. This shows how they are customized. Dixtosa (talk) 16:30, 25 November 2018 (UTC)