MediaWiki talk:Common.js/Archive May 2007

From Wikipedia, the free encyclopedia

[edit] Tooltip for dismiss watchlist link

How about adding a "title" attribute to the dismiss watchlist link to create a tooltip:

ButtonLink.setAttribute( "title", "Hide watchlist message for one week" );

This way, normal users have a chance of seeing that "dismiss" will hide the message for one week, instead of blindly clicking on it (or avoiding it for fear of permanently dismissing the message). What would be really cool would be to make the message dismiss until the text was changed. This would be pretty easy to do if there was a built-in MD5 function or some other sort of hash or checksum derived from the message that could be used as the value of the cookie instead of "yes". That way the code could tell if the message that was dismissed was the same as the current message. Mike Dillon 14:09, 31 March 2007 (UTC)

Admins tend to tweak the message several times while it is displayed so that approach would likely not be very effective. Adding a unique id/class for each different message might work, though. —Ruud 16:37, 31 March 2007 (UTC)

[edit] Query strings

{{editprotected}} I have made a querystring function in my morebits.js, wonder if you think it should be included here? _→AzaToth 19:45, 1 April 2007 (UTC)

/**
* Maps the querystring to an object
*
* Functions:
*
* QueryString.exists(key)
*     returns true if the particular key is set
* QueryString.get(key)
*     returns the value associated to the key
* QueryString.equals(key, value)
*     returns true if the value associated with given key equals given value
* QueryString.toString()
*     returns the query string as a string
* QueryString.create( hash )
*     creates an querystring and encodes strings via encodeURIComponent and joins arrays with | 
*
* In static context, the value of location.search.substring(1), else the value given to the constructor is going to be used. The mapped hash is saved in the object.
*
* Example:
*
* var value = QueryString.get('key');
* var obj = new QueryString('foo=bar&baz=quux');
* value = obj.get('foo');
*/
function QueryString(qString) {
 this.string = qString;
 this.params = {};

 if( qString.length == 0 ) {
 return;
 }

 qString.replace(/\+/, ' ');
 var args = qString.split('&');

 for( var i in args ) {
 if( typeof( args[i] ) != 'string' ) {
 continue;
 }
 var pair = args[i].split( '=' );
 var key = decodeURIComponent( pair[0] ), value = key;

 if( pair.length == 2 ) {
 value = decodeURIComponent( pair[1] );
 }

 this.params[key] = value;
 }
}

QueryString.static = null;

QueryString.staticInit = function() {
 if( QueryString.static == null ) {
 QueryString.static = new QueryString(location.search.substring(1));
 }
}

QueryString.get = function(key) {
 QueryString.staticInit();
 return QueryString.static.get(key);
};

QueryString.prototype.get = function(key) {
 return this.params[key] ? this.params[key] : null;
};

QueryString.exists = function(key) {
 QueryString.staticInit();
 return QueryString.static.exists(key);
}

QueryString.prototype.exists = function(key) {
 return this.params[key] ? true : false;
}

QueryString.equals = function(key, value) {
 QueryString.staticInit();
 return QueryString.static.equals(key, value);
}

QueryString.prototype.equals = function(key, value) {
 return this.params[key] == value ? true : false;
}

QueryString.toString = function() {
 QueryString.staticInit();
 return QueryString.static.toString();
}

QueryString.prototype.toString = function() {
 return this.string ? this.string : null;
}


QueryString.create = function( arr ) {
 var resarr = Array();
 for( var i in arr ) {
 if( typeof arr[i] == 'object' ){
 var v =  Array();
 for(var j in arr[i] ) {
 v[j] = encodeURIComponent( arr[i][j] );
 }
 resarr.push( encodeURIComponent( i ) + '=' +  v.join('|')  );
 } else {
 resarr.push( encodeURIComponent( i ) + '=' + encodeURIComponent( arr[i] ) );
 }
 }

 return resarr.join('&');
}
QueryString.prototype.create = QueryString.create;

Looks great, but do we really need it? It's long, and each load is an unnecessary drain on the servers if its relatively unused. —METS501 (talk) 20:03, 1 April 2007 (UTC)

I don't know how much extra load it will generate to just load the script, but it won't execute anything unless used. _→AzaToth 20:05, 1 April 2007 (UTC)

I was referring to the load from loading it. It's 2,837 bytes, which means over millions of loads, it starts to add up. See [1] for the server breakdown: css and js eat almost as much bandwith as pure article views. —METS501 (talk) 20:10, 1 April 2007 (UTC)

That are only the static CSS and JS files, not ones editable on-wiki. No idea if those significantly contribute to the bandwidth usage as well? —Ruud 21:02, 1 April 2007 (UTC)

What does it do? At first glance it doesn't seem to have any use outside of other user-scipts (which can just as easily import it themselves.) —Ruud 21:02, 1 April 2007 (UTC)

Also, does Common.js really need OOP techniques? The smaller is the better, imho — Alex Smotrov 21:29, 1 April 2007 (UTC)

That's just a minor thing, the idea first is to only parse the query string once. second point is to use correct encoding, as some has been using wrong function for that (window.escape()), and to do it transparent. _→AzaToth 21:34, 1 April 2007 (UTC)

For something unlikely to be used often, wouldn't it be just as well to put the burden on the client side (extra parsing) rather than on the servers (extra bandwidth for longer code)? See below (obviously just an example). --Splarka (rant) 07:18, 2 April 2007 (UTC)

function queryString(p) {
    var re = RegExp('[&?]' + p + '=([^&]*)');
    var matches;
    if (matches = re.exec(document.location)) {
        try { 
            return decodeURI(matches[1]);
        } catch (e) {
        }
    }
    return null;
}

The above is basically from Lupin's popups, no? Or somewhere else before that, given the nature of much javascript code. Now, my opinion really doesn't matter here (not really that professional a javascript coder), but it might be useful to have one standardized function related to query strings, since a lot of scripts need them, and said scripts have their own query functions. So if those scripts are used together, you have (possibly) three or four query string functions altogether, which doesn't strike me as that efficient. Creating and getting query strings sounds useful; the rest, not as much. Gracenotes^T § 14:29, 2 April 2007 (UTC)

As WP:TW is probably the only script as of yet using QueryString (by some freak coincident), the number of calls to QueryString as of yet is 59 times. _→AzaToth 14:45, 2 April 2007 (UTC)

I have added an {{editprotected}} to the top of the page. So, which parts of this are we going to implement? All of it? Static? Object? Certain methods, and not others? Gracenotes^T § 19:37, 4 April 2007 (UTC)

I think this is the sort of thing that is more appropriate for WP:US. Maybe I'm missing the point, but I don't see why this needs to be in the site-wide js, unless it is likely to be used by a general reader or editor. CMummert · talk 16:55, 5 April 2007 (UTC)

I agree with this. —Ruud 20:41, 5 April 2007 (UTC)

Sorry, I was away a bit. My only problem with this is that I need query string scripts, so I'll have to include my own. And if someone else needs to include them, they'll have to include their own. And all these functions for doing the same thing need to load, rather than having one standardized function. No matter, eh. Gracenotes^T § 22:53, 7 April 2007 (UTC)

No, importScrtipt will only load a script once, even if it is included multiple times. —Ruud 11:17, 8 April 2007 (UTC)

Do you know of a library that has this code? Gracenotes^T § 19:24, 8 April 2007 (UTC)

Uhh... AzaToth just wrote the code? He now only has to locate it somewhere (in his userspace or at WP:US for example) in list it at WP:US. —Ruud 19:46, 8 April 2007 (UTC)

Yeah, it doesn't exist now. Gracenotes^T § 22:45, 8 April 2007 (UTC)

As to show you why it's so "complicated", I'm using it for example to create things like this (though I'm usually tries to make it asyncronus, it's syncrone here for the ease of typing):

var query = {
 'title': 'User talk:' + user,
 'action': 'submit'
};
xmlhttp = sajax_init_object();
xmlhttp.overrideMimeType('text/xml');
xmlhttp.open( 'GET' , wgServer + wgScriptPath + '/index.php?' + QueryString.create( query ), false);
xmlhttp.send( null );

form = xmlhttp.responseXML.getElementById('editform');

var postData = {
 'wpMinoredit': form.wpMinoredit.checked,
 'wpWatchthis': form.wpWatchthis.checked,
 'wpStarttime': form.wpStarttime.value,
 'wpEdittime': form.wpEdittime.value,
 'wpAutoSummary': form.wpAutoSummary.value,
 'wpEditToken': form.wpEditToken.value,
 'wpSummary': summary,
 'wpTextbox1': text
};
xmlhttp = sajax_init_object();
xmlhttp.overrideMimeType('text/xml');
xmlhttp.open( 'POST' , wgServer + wgScriptPath + '/index.php?' + QueryString.create( query ), false);
xmlhttp.setRequestHeader('Content-type','application/x-www-form-urlencoded');
xmlhttp.send( QueryString.create( postData ) );

Another example could be to check if we are "editing" the page:

var isEditing = QueryString.equals('action', 'edit');

A third common example of you want to do, is when you want to grab data from a link:

var query = new QueryString( node.getAttribute('href').split('?',2) );
var rev = query.get('oldid');

This is just simple examples, and I made it extensive, so it would be easy to parse/create query strings. one good thing is that it takes care of encoding automatically, for example

QueryString.create({'foo bar':['a','123!"#åäö']}) 

becomes

"foo%20bar=a|123!%22%23%C3%A5%C3%A4%C3%B6" 

vice versa_→AzaToth 23:32, 7 April 2007 (UTC)

I think that it looks like a very useful script for WP:US. I don't see how it would help to have it in the sitewide monobook.js, since it seems that the only people who will use it will do so from scripts they are already adding to their personal monobook.js. If there were some function coded into a standard template that required it, that would be an argument in favor. Of course there is also the magic word {{urlencode}} built into mediawiki. CMummert · talk 23:22, 8 April 2007 (UTC)

[edit] Better search engine

After requests from WikipediaSearch.net I copied the enhanced search JavaScript from fr:; feel free to revert or alter. David.Monniaux 20:14, 10 April 2007 (UTC)

Umm...how difficult would it be to announce and discusss it first? The code could be shorter and more readable. Formatting could definitely be better. And all those sites can now track Wikipedia visitors because of the pictures. — Alex Smotrov 20:24, 10 April 2007 (UTC)

This was apparently announced and discussed before. David.Monniaux 20:29, 10 April 2007 (UTC)

Where? It doesn't seem to have been announced here or at Wikipedia:Village pump (technical). Mike Dillon 20:33, 10 April 2007 (UTC)

What in the bejesus was that? Do away with the advertising, even for other free services thank you very much. And get the alignment right. Splash - tk 23:01, 10 April 2007 (UTC)

Sorry for my english is poor.

I am the french editor of the http://www.wikipediaondvd.com, and also of http://www.wikipediasearch.net.

And I want to show you the difference beetwen our engine and the engine of wikipedia :

http://en.wikipedia.org/w/index.php?title=Special%3ASearch&search=nasa&fulltext=Search

http://www.wikipediasearch.net/index.php?action=nasa&lang=en

You can see the related vocabulary that is helping the internaute to find what is want like this :

http://www.wikipediasearch.net/index.php?lang=en&action=nasa%20astronaut

So really, i think that it is for that we have a better search.

We improve our engine every day at the end of the week we have got a very nice version to propose.

Bye

Pmartin76 01:05, 11 April 2007 (UTC)

The search looks nice, but that doesn't change the fact that there needs to be concensus to add it. Using Special:Linksearch/*.wikipediasearch.net, I only see discussion on one user's talk page and a single mention at Wikipedia talk:Version 0.5. Using a link search for wikipediaondvd.com finds a few more places this may have been discussed, although nothing with much visibility. It also looks like this was also added into the interface text at MediaWiki:Searchnoresults on April 7. Mike Dillon 02:36, 11 April 2007 (UTC)

There is something weird here. I was contacted on IRC by User:DragonflySixtyseven who told me that the matter had been discussed and all was needed was a technical fix, which he didn't feel comfortable doing because he did not know how to hack JavaScript. David.Monniaux 05:10, 11 April 2007 (UTC)

I was thinking that the concensus are find on saturday afternoon on IRC, i speak with User:DragonflySixtyseven and he told me that we can modify the page of the namespace 8, I was explain to User:DragonflySixtyseven that the community are very happy to see our engine http://fr.wikipedia.org/wiki/Special:Linksearch/*.wikipediasearch.net Pmartin76 05:32, 11 April 2007 (UTC)

It doesn't help that PMartin76's English isn't the best, and that I was feeling sickly all weekend. If this is inappropriate, revert it. DS 13:31, 11 April 2007 (UTC)

[edit] Sorting

I plan to add a bug fix for sorting tables, like I have done on Meta, to allow sorting of numbers with more than one thousands separator, see m:MediaWiki:Common.js. Any comments?--Patrick 13:47, 11 April 2007 (UTC)

Compare Help:Sorting#Making_variable-length_numbers_with_thousands_separators_sortable with m:Help:Sorting#Making_variable-length_numbers_with_thousands_separators_sortable.--Patrick 14:06, 11 April 2007 (UTC)

I added it.--Patrick 12:12, 12 April 2007 (UTC)

[edit] Proposal: Short button captions for collapse tables

Can you add a shorter caption version of the collapse buttons? Maybe [+/-] instead of [show/hide]? Geva Zeichner 12:52, 14 April 2007 (UTC)

No, it's not intuitive and the TOC uses show/hide as well. Most people prefer show/hide (there was a shorter version in the past.) —Ruud 14:40, 14 April 2007 (UTC)

Is it possible to make it as an option (for those crowded places)? Geva Zeichner 17:14, 14 April 2007 (UTC)

Also, why is Button.style.width = "6em" so wide? it takes also a lot of space. Geva Zeichner 13:29, 14 April 2007 (UTC)

This is a safe upperbound on the maximum length a six character label can take up. Is it causing a problem somewhere? —Ruud 13:51, 14 April 2007 (UTC)

Please have a look at my sandbox. As you can see, the show/hide button that I'm trying to put in the template, takes too much space. Geva Zeichner 14:05, 14 April 2007 (UTC)

I didn't really design this with infoboxes in mind. I could make some changes to make it work better with those. You should seriously consider if you really want to put that much information in an infobox though. In a lot of situations all the information is shown (when printing an article, when using text-to-speech software, when using browser that doesn't fully support CSS or JavaScript, ...) so the fact that it can be hidden shouldn't be part of that consideration at all. —Ruud 14:40, 14 April 2007 (UTC)

I didn't think about it until now. But still, I am convinced that the option should exist. For some public figures that amount of information isn't too much at all. And for those, printing it all out actually sounds just right. When necessary, the information could be simply not included at all.
It would be great if you can make the changes to better the button's look in infoboxes. Geva Zeichner 17:11, 14 April 2007 (UTC)