MediaWiki talk:Common.js/Archive 8

Global JS/CSS "safe" now

{{editprotected}} Looks like developers did the same thing for global JS/CSS files as they already did before for personal js/css files: now the whole page is shown inside <pre class="mw-code mw-js"> tag, which means nothing is going to work inside and we can remove all templates (e.g. {{Interwiki-all}} in MediaWiki:Monobook.css and MediaWiki:Common.css), [[User:]] links, headings, <pre> tags and so on. However, there is still one little reason to keep <source> tag: you can trasclude the file on another page and then still enjoy it with syntax highlighting ∴ Alex Smotrov 22:29, 27 June 2007 (UTC)

For highlighting add both </pre> before <syntaxhighlight ...> and <pre> after </syntaxhighlight> tags.--AlefZet 21:57, 28 June 2007 (UTC)

Well, that was my first idea as well, but it doesn't work since Mediawiki simply replaces all < into &lt;. Note that this doesn't happen immediately after saving (I have no idea why), so if markup on js/css pages seems to work for you, just wait a little and it won't ;) ∴ Alex Smotrov 22:13, 28 June 2007 (UTC)

Now it <pre> with syntax highlighting, which is nice. Still, no markup works inside, so it's better to remove it ∴ Alex Smotrov 16:15, 29 June 2007 (UTC)

 Fixed _→AzaToth 17:07, 29 June 2007 (UTC)

If you still want to see it with all the bells and whistles (parsed wikicode), try a diff, like: &oldid=141424535&diff=. --Splarka (rant) 07:05, 30 June 2007 (UTC)

There is ongoing discussion about this on bugzilla (bugs 10196, 10314, 10410, 10422), so don't be surprised if it changes again soon. --ais523 15:39, 2 July 2007 (UTC)

Make "Upload file" more like on commons

{{editprotected}} There are a few things that I would like to propose for en: when uploading files. Most of these are not original ideas. I could provide a link to where they were first proposed but I don't think it's that important. I think they can be done with js of some kind.

1. Remove the "Upload file" link in the "toolbox" and move the "File upload wizard" into the "toolbox". I believe this has been done on zh: and can probably be done here with js.
2. Have the {{information}} preloaded into the editbox, again, much like at commons, and much of the info filled out. It has been suggested rather to have a link that will fill it in if needed, but personally I don't like the later idea. Having it automatically in the editbox will give people a better idea of what info is needed. I have located how it was done on commons, it is a simple js here.
3. A small thing is to have the editbox 50% larger, or more.

This same message went trough the Village Pump (Make "Upload file" more like on Commons) without anyone noticing. So I thought I'd add it here. --Steinninn 16:03, 4 July 2007 (UTC)

These sound like good ideas, get consensus for them then re-enable the template. Thanks, GDonato (talk) 12:53, 6 July 2007 (UTC)

I already posted it at the village pump, what more do you need? --Steinninn 13:55, 6 July 2007 (UTC)

Unfortunately, I am unwilling to make such changes without agreement of the community. The only thing I would say is trying re-listing, possibly at WP:VPT too. GDonato (talk) 18:32, 6 July 2007 (UTC)

Search images

I have just reverted Martinp23's addition of the search engine images. Adding images like these violates our fair use policy and may be interpreted as ads. Sean William 22:46, 19 May 2007 (UTC)

Agreed. ^(H) 22:50, 19 May 2007 (UTC)

Likewise. I factored the images out, but apparantely I'm not allowed to do that, so putting this reversion up for discussion - to be clear, the ideal way to give the external searches would be server-side, in the mediawiki text, but as no params are available in the relevant text, something client side is required. This has been requested in various places, including WP:AN (which, incidentally, is where I decided to add the images code, from fr.wiki, as a favour - still somewhat sick at the hostility of some to an easily reversible mistake...). The removal of the code which I changes is reverted here. Martinp23 00:21, 20 May 2007 (UTC)

Unfortunately any code pasted here is not easily reverted as it can stayed cached in visitors' browser cache for weeks. Any mistakes in the code can cause anything from annoying popups to appear to all pages on Wikipedia showing up blank during that time. From the simple cut 'n paste job you did I assumed you are not familiar with Javascript yourself, while adding executable code to one of the most visited websites is something that should not be doen without a little care. There are usually enough people hanging around on this page who van evaluate (and perhaps improve the code) on it's correctness, performance impact, maintainability etc. This was not meant as a hostile action, but as necessary caution. A reaction you can sometimes expect when being bold. —Ruud 13:27, 20 May 2007 (UTC)

I understand your reasons, but should note that this wasn't a "simple cut-and-paste job" - in fact I did test my extensive changes to the code in my personal monobook.js before adding it here - the code below (as I added) is somewhat different from the code on fr.wiki, but I of course do invite people to look over (and inevitably improve) it. Martinp23 14:37, 20 May 2007 (UTC)

Okay, better safe than sorry was my motto here. No hurt feelings I hope. —Ruud 18:59, 20 May 2007 (UTC)

Not at all! Thank you for your diligence in taking that care. Feel free to re-enter the js when/if you feel it has been suitably reviewed. Martinp23 19:25, 20 May 2007 (UTC)

I support the image free version. Good idea. ^(H) 19:28, 20 May 2007 (UTC)

See my note below. I'm not a fan, but at least I can do onloadFuncts.splice(onloadFuncts.indexOf(SpecialSearchEnhanced3), 1). Gracenotes^T § 19:41, 20 May 2007 (UTC)

Proposed code for search page

 /** Search page improvements ******************************************************

 * Amélioration de la page de recherche v3
 * Auteur : Marc Mongenet
 * Sous licence GFDL & GPL<nowiki>

 * Improvement to search page
 * Authour: Marc Mongenet (from fr.wiki)
 * Licensed GFDL and GPL
 * Modified for en-wiki by Martinp23
 */
function SpecialSearchEnhanced3() 
{

 function SearchForm(search_action_url, engine_url, engine_name,
                     search_field_name, search_field_value, site_field_name, site_field_value)
 {
   var span = document.createElement("div");
   span.style.marginRight = "1em";
   span.style.width="100%";
   span.style.whiteSpace = "nowrap";
   
   var form = document.createElement("form");
   form.method = "get";
   form.action = search_action_url;
   form.style.display = "inline";
   span.appendChild(form);

   var input = document.createElement("input");
   input.type = "hidden";
   input.name = search_field_name;
   form.appendChild(input);

   var site = document.createElement("input");
   site.type = "hidden";
   site.name = site_field_name;
   site.value = site_field_value;
   form.appendChild(site);

   form.onsubmit = function() {
     input.value = document.getElementById("lsearchbox").value;
   }


   var submit = document.createElement("input");
   submit.type = "submit";
   submit.style.margin = "3px";
   submit.value = "Use " + engine_name + " search";
   form.appendChild(submit);

   return span;
 }

 if (typeof SpecialSearchEnhanced3Disabled != 'undefined') return;
 if (wgPageName != "Special:Search") return;

 var mainNode = document.getElementsByTagName("form");
 if (!mainNode) return;
 mainNode = mainNode[0];
 mainNode.appendChild(document.createElement("center"));
 mainNode = mainNode.lastChild;

 var searchValue = document.getElementById("lsearchbox").value;
 var engine;
 engine = SearchForm("http://www.google.com/search", "http://www.google.com/", "Google",
                     "q", searchValue,
                     "as_sitesearch", "wiki.riteme.site");
 mainNode.appendChild(engine);
 engine = SearchForm("http://www.wikiwix.com/", "http://www.wikiwix.com/", "Wikiwix",
                     "action", searchValue,
                     "lang", "en");
 mainNode.appendChild(engine);
 engine = SearchForm("http://search.live.com/results.aspx", "http://search.live.com/", "Windows Live",
                     "q", searchValue,
                     "q1", "site:http://wiki.riteme.site");
 mainNode.appendChild(engine);
 engine = SearchForm("http://en.search.yahoo.com/search", "http://en.search.yahoo.com/", "Yahoo!",
                     "p", searchValue,
                     "vs", "wiki.riteme.site");
 mainNode.appendChild(engine);
}
addOnloadHook(SpecialSearchEnhanced3);

/* End of search page */

Drop-down approach

{{editprotected}}

Hm... could we possibly keep the buttons down to a minumum? Mere links would be good, I think. I mean... I dislike them: too large, and too many of them. Gracenotes^T § 19:23, 20 May 2007 (UTC)

I agree, a drop-down list should be used to let the user select which search engine he wants to use (defaulting to MediaWiki's internal search engine). —Ruud 19:49, 20 May 2007 (UTC)

What I think would look nice would be to have them as links instead of buttons, and to have them side-by-side instead of one-under-the-other, to save screen space. Tra (Talk) 20:40, 20 May 2007 (UTC)

I personally like Ruud's solution: all it requires is creating a menu, and then changing the action of the form when the selection is changed. And only one form is required. Gracenotes^T § 20:57, 20 May 2007 (UTC)

This code might work, if anyone's in favor of it, and if it works on all browsers:

Proposed code by Gracenotes

if (wgPageName == "Special:Search") {
	var searchEngines = [];
	addOnloadHook(SpecialSearchEnhanced);
}

function SpecialSearchEnhanced() {
	var createOption = function(site, action, mainQ, addQ, addV) {
		var opt = document.createElement('option');
		opt.appendChild(document.createTextNode(site));
		searchEngines[searchEngines.length] = [action, mainQ, addQ, addV];
		return opt;
	}
	var searchForm = document.forms['search'];
	var selectBox = document.createElement('select');
	selectBox.id = 'searchEngine';
	searchForm.onsubmit = function() {
		var optSelected = searchEngines[document.getElementById('searchEngine').selectedIndex];
		searchForm.action = optSelected[0];
		searchForm.lsearchbox.name = optSelected[1];
		searchForm.title.value = optSelected[3];
		searchForm.title.name = optSelected[2];
	}
	selectBox.appendChild(createOption('MediaWiki search', '/w/index.php', 'search', 'title', 'Special:Search'));
	selectBox.appendChild(createOption('Google', 'http://www.google.com/search', 'q', 'as_sitesearch', 'wiki.riteme.site'));
	selectBox.appendChild(createOption('Yahoo', 'http://search.yahoo.com/search', 'p', 'vs', 'wiki.riteme.site'));
	selectBox.appendChild(createOption('Windows Live', 'http://search.live.com/results.aspx', 'q', 'q1', 'site:http://wiki.riteme.site'));
	selectBox.appendChild(createOption('Wikiwix', 'http://www.wikiwix.com/', 'action', 'lang', 'en'));

	searchForm.lsearchbox.style.marginLeft = '0px';
	var lStat = document.getElementById('loadStatus');
	lStat.parentNode.insertBefore(selectBox, lStat);
}

The only problem is that "fulltext=search" is submitted as part of the query, since that's the name/value of the submit button. Gracenotes^T § 02:32, 23 May 2007 (UTC)

Could we add Wikiwix to that? It has been requested on AN and not objected to there, and the development team for that have (AFAIK) gone to great lengths to ensure a quick and very accurate search, optimised to Wiki*edia projects. Martinp23 09:48, 23 May 2007 (UTC)

Done. Feel free to change the order. Gracenotes^T § 17:10, 23 May 2007 (UTC)

I've requested the changes; does anyone object for any reason? Gracenotes^T § 21:26, 23 May 2007 (UTC)

Done. Cheers. --MZMcBride 23:34, 24 May 2007 (UTC)

The code for Mediawiki search fails when using the secure server. It brings up secure.wikimedia.org/w/index.php which leads to a "Wiki does not exist" message. Can someone make the script check for secure.wikimedia.org and change the Mediawiki search URL accordingly? Resurgent insurgent 01:25, 26 May 2007 (UTC)

The code that says '/w/index.php' should be changed to wgScriptPath + '/index.php'. Mike Dillon 01:40, 26 May 2007 (UTC)

Done. Purge and all that.... Cheers. --MZMcBride 02:06, 26 May 2007 (UTC)

{{editprotected}}

Is it all right if someone changes "as_sitesearch" to "sitesearch" for the Google drop-down item in this script, which produces this search rather than this one? The former is a bit cleaner, and less confusing for people who are less familiar with Google. Thank you, Gracenotes^T § 00:40, 9 June 2007 (UTC)

Done. Cheers. --MZMcBride 01:11, 9 June 2007 (UTC)

CJK character problems with Yahoo!

There's some problems when searching some terms including the CJK characters when searching using the Yahoo! option. And I've found out that a field name and a value is required in addition of the existing search term that using the Yahoo! sarch engine. i.e. the [ei=utf-8] is required when a Yahoo! search engine is selected. Any idea how to solve this issue? Shinjiman ⇔ ♨ 13:46, 9 July 2007 (UTC)

It would require a bit of tweaking to the script since it assumes that there is only one additional parameter besides the free text field used for the search term. For Yahoo!, this is currently being used for vs=wiki.riteme.site. The code would have to be changed to add a hidden element to the form for the ei parameter on submit, which would significantly alter the structure of the code. Mike Dillon 02:24, 10 July 2007 (UTC)

small replace() bug

{{editprotected}}

The definitions of importScript and importStylesheet call page.replace( ' ', '_' ), but this will only replace the first space in page, without touching the rest.

This is not a big deal, because Wikipedia generates a 301 Moved Permanently for the spaced URL, but the code should probably be corrected to page.replace(/_/g, ' '), for neatness and efficiency. --Piet Delport 01:42, 5 July 2007 (UTC)

That is, switch that around, page.replace(/ /g, '_') (or page.replace(/\s/g, '_')). Gracenotes^T § 04:13, 5 July 2007 (UTC)

Y Done (after testing the relevant expressions). (There are certainly a lot of ways to express the intended concept; I went for / /g in the actual change, but when writing my own code I often use /\ /g (which is correct in both JavaScript and Perl, even when using Perl's /x modifier) or even split(" ").join("_") (which has the advantages of accepting non-literal strings). --ais523 17:22, 6 July 2007 (UTC)

Right, my copy&paste mistake. --Piet Delport 10:14, 11 July 2007 (UTC)

JavaScript framework

Has anyone ever thought about using a JavaScript framework (ex. jQuery) to make it easer for people to create plugins for MediaWiki? It would also make this page allot nicer and easer to read. — 12.65.6.217 22:19, 7 July 2007 (UTC)

While that may be true, it would also add another 20k of overhead to the site JavaScript. I'm not sure if the readability benefit is enough, since 99.9% of the people for whom this code executes will never even know about it, let alone read it. Mike Dillon 14:54, 14 July 2007 (UTC)

Please discuss first

Another sudden addition to global JS file… please please stop doing that. I'm starting to feel that some pages need to be protected from admins. How secure is it to have the code executed from someone's toolserver account? As far as I understand, there is no even "edit history" there. Also, will toolserver handle the load? And even after looking, I can't find where this was discussed ∴ Alex Smotrov 05:31, 14 July 2007 (UTC)

Mindspillage and Gmaxwell are both Foundation insiders, so there's a good chance the decision took place somewhere off-wiki. Since this seems to be related to geographic targeting of the contents of the sitenotice, I'm surprised this wasn't done as a MediaWiki extension. Regardless, I couldn't get it to produce any code, so it's unclear exactly what it does anyways. Mike Dillon 14:52, 14 July 2007 (UTC)

I haven't figured it out yet either, though I doubt it is anything though up by the board as in that case it likely would have been a MediaWiki extension. —Ruud 16:21, 14 July 2007 (UTC)

Also, since this was presumably added to other Wikipedias besides enwiki, it should probably check wgCanonicalSpecialPageName instead of wgPageName to allow the code to be the same everywhere (since I assume no amount of bitching will result in there actually being a discussion about this). Mike Dillon 14:55, 14 July 2007 (UTC)

Hope this doesn't break the toolserver, Brion did a study once showing the average user views about two pages per CSS reload. —Ruud 16:02, 14 July 2007 (UTC)

If it is only being loaded on the watchlist shouldn't be too much of a problem.

Looks like this was causing the watchlist page load to take a really long time for at least one user. See WP:VPT#watchlist and tools.wikimedia.de. Mike Dillon 18:12, 14 July 2007 (UTC)

I trust Gmaxwell's programming skillz and Kat's judgment, but as the change may be causing difficulties (folks on IRC are confirming that those difficulties left when I rv'd). And I'm (personally) not a fan of the garish meetup notice, but that's ultimately not my decision, of course - just wondering if it was discussed anywhere. --Jeffrey O. Gustafson - Shazaam! - <*> 19:45, 14 July 2007 (UTC)

This just once again highlights the disparities between "policy" and reality. Does WP:CON even matter we're subject to the "judgement" of Wikimedia Foundation board members and developers? As for "programming skillz", that's hardly the issue here; it seems more like a lack of foresight that the use of an unclustered, non-load balanced, and geographically isolated server prone to latency issues ended up causing performance problems for our global audience. I'm sure that the complaints that were actually heard (both on IRC and on WP:VPT) are a small fraction of the affected users. Mike Dillon 20:02, 14 July 2007 (UTC)

Why was this change reverted? I do not see any concrete explanation for the change in the above text. I checked on IRC and no one is complaining about anything there. As far as garish notices go, the notice is only displayed to users which geolocate to a region along the eastern US, and the notice can easily be dismissed with a single click. I have a native mediawiki implementation... but wouldn't you agree that it would be useful to test the usefulness of a feature before making it a permanent part of the site and codebase? I am not sure of the value of this feature, which is exactly why I put in a partial implementation before outright forcing it on you.

Speaking as root on toolserver, there is no load issue there. The notice is only resulting in about 10,000 pageviews per day.

I'd be very interested in knowing how this caused a problem for anyone: The external page isn't loaded until the watchlist is loaded, and I tested it with toolserver blackholed with no impact in load time.

Pardon my irritation and disgust but I consider this to be an example of how English Wikipedia is socially ill: Most any movement away from the status-quo is reverted, based not on fact, but instead on pure conjecture and an apparent infantile response to authority which happens here most of the time when any change hasn't been personally approved by any of hundreds of people of have the access needed to revert it. Consensus doesn't mean "I must personally approve every change", and anyone who thinks otherwise is a harm to our community. I have to say that, as a developer, the English Wikipedia community is by far the least satisfying to work with of all the Wikimedia communities. Your needlessly confrontational responses to all concerns makes me feel like I'm wasting my time doing anything to help.--Gmaxwell 00:54, 15 July 2007 (UTC)

Here's my understanding of the problem. It looks like for certain people, anything being loaded from tools.wikimedia.de is really slow. Since the onload hooks run after the main content of the page has loaded, the lag shouldn't impact any core functionality, but it would prevent any user scripts from loading, since those onload hooks would have been added after the one for the geotargeting. The one specific complaint I saw was that the browser was trying to load something from tools.wikimedia.de for a long time; there were no specific complaints about user scripts or anything else by that user. The other thing I heard, which is what caused this to be reverted, was that people were complaining on IRC. I don't know what those complaints were, but they were enough to cause Jeffrey O. Gustafson to revert.

As for your disgust, all I have to say is that the need for on-wiki involvement in decisions is needed precisely to avoid the sort of knee-jerk reaction you're talking about. If these things were discussed and people knew they were happening, the people who are actually active on this wiki would be able to better deal with things when they break. It's regrettable that English Wikipedia is not satisfying to work with as a developer, but it is much larger in scale than the other wikis, and it's not surprising that your actions end up getting more scrutiny here. Mike Dillon

Mike, It's not a matter of scrunity.. I love feedback, but there was no material feedback here. My dissatisfaction is because Enwiki appears to be angered by a failure to personally consult hundreds of people, an impossible task... What exact objective comments could you have possibly made prior to implimenation? Problems happen, but beyond a basic level of testing and oversight, the best way to find them is in production.

Jeffery, on the IRC complaint front I've found Steel359, he had clearly broken user js which was overriding the onloadhook function with something clearly broken, he's fixed. It's only dumb luck that nothing else broke it before now. If you heard from anyone other than him, please let me know.--Gmaxwell 01:49, 15 July 2007 (UTC)

I think it's mostly a matter of visibility for decisions made off-wiki. I'm not asking anyone to consult hundreds of people when the decisions aren't in obvious conflict with established concensus, I just think things like this deserve at least a mention on this talk page and on WP:VPT. I also apologize if my initial rant about WP:CON was a little caustic.

As for objective feedback, I doubt that I would have thought of the tools.wikimedia.de access issues if this had been discussed/proposed, but when they came up, I remembered other people having had them in the past. I mainly think that making a note before implementing the change would have avoided hard feelings and could have gotten some extra eyes on the lookout for potential problems before they started happening. In other words, I think you're right that certain problems won't be found until something goes to production, but I'm convinced that it's best to try to have someone watching when that happens. Mike Dillon 04:49, 15 July 2007 (UTC)

Tools.wikimedia.de isn't accessibly to any host which thinks it has IPv6 connectivity but instead has broken IPv6 connectivity. With that in mind the code was setup in a way which still works if a connection to that host isn't possible. Of course, as of yet there were no real problems and the feature is still out... so we're learning nothing. You've also managed to reduce my interest in helping this project. Congratulations. --Gmaxwell 06:32, 15 July 2007 (UTC)

Just to be clear, what I said about user scripts not loading was overstated and not entirely correct. I think the only side effect of waiting for the call to tools.wikimedia.de to time out will be that any scripts or stylesheets added in an onload hook will not be loaded until the tools.wikimedia.de call times out. This is a pretty marginal case since most onload hooks just have code to execute and new scripts/styles are usually imported outside of the onload hook itself which means the associated resource will have been loaded before the onload hooks execute. Mike Dillon 15:10, 15 July 2007 (UTC)

The no reason to revert stance doesn't appear to be much differant from the why was this ever added stance. If for nothing else, users accessing the english wikipedia may wonder why they have a script loading from a german domain. Additionally the only documentation delivered with it is "Allows for geographic targeting of watchlist notices", which doesn't explain much to even experienced editors what is really going on here. If new off-site scripts are going to be included, can they include onsite documentation (or a link to meta, or somewhere else on-wiki)? — xaosflux ^Talk 01:25, 15 July 2007 (UTC)

Could you please ask an actual question? I'm not sure exactly what you want to know. --Gmaxwell 01:49, 15 July 2007 (UTC)

Mmm, OK..if you want a Q: and A format:

1. What does this particular change implement?

It impliments a watchlist notice which depends on your location on the earth as determined by a free geolocation database. The comment put in on this said as much.

1. Why do we need to load something from another domain here?

Because I thought putting it in a way which didn't permanently commit us to the feature was better than forcing it on the community. I see I was mistaken. Had the feature simply been put into mediawiki without community input I would not have been subject to this hostility, and we would still be learning about its effectiveness.

1. Is this something that could be worked in to the interface or software, rather than being off-loaded?

Please read my comments above. I addressed this earlier. Further, I've yet to see any actual problem with the software being held externally to mediawiki proper. Can you please articulate your concerns on this front?

1. How can this be better documented so that everyone knows what is going on here and in the future for off-loaded scripts?

   I'd suggest a project page documenting this new code-set referenced from a comment code if loading scripts from other servers is required. — xaosflux ^Talk 03:42, 15 July 2007 (UTC)

Thank you, — xaosflux ^Talk 03:42, 15 July 2007 (UTC)

Understand that it is currently a test to determine the usefulness. At this point you may now be asking me to expend more work to justify my code to you personally than was required for the entire implementation. The operation is fairly simple, and nearly self-explanatory. The addition to common.js loads a script from a cgi which depends on the location of the browser loading it. That script displays a notice. I have a mediawiki implementation, but without experience using the feature I don't know how location ranges can be most usefully specified. I was hoping to gain experience with DC and NYC, but it appears that you have decided to not permit me to do so.

Frankly I am disinclined to spend several more hours justifying a rather simple feature which has already been removed for no particular reason. If you don't want it fine, but please adjust the pages to make it clear that the English Wikipedia is not open to contributions because you have personally decided that it shouldn't be.--Gmaxwell 06:32, 15 July 2007 (UTC)

What is the reason for the change? What is it supposed to do? --- RockMFR 02:45, 15 July 2007 (UTC)

Greg can correct me if I'm wrong, but I believe it uses the user's IP address to determine whether they are in a region with an upcoming Meetup and alerts them with a dismissable message. It may be limited only to the Washington DC meetup at the moment. Mike Dillon 04:49, 15 July 2007 (UTC)

So it's passing IP information about active editors to another server? How does providing this type of information to the toolserver play with the privacy policy? — xaosflux ^Talk 05:59, 15 July 2007 (UTC)

It's loading a page from another Wikimedia system. The same way many of other things do here, for example the mediaplayer, which has been in service for a very long time. Furthermore, no information which connects a specific editor to an IP is transfered, which is far more than many of our other internal features. Why do you have the access required to revert this change if you can't see for yourself exactly what it is doing in that regard? --Gmaxwell 06:32, 15 July 2007 (UTC)

When using media players, etc our users are making a specific request to leave en: and connect to the other server. When loading their watchlist, they are not generally not even going to be aware of this connection. As this is also executing off-site, what it is doing there is beyond review here, thus my request for documentation to be published. This certainly doesn’t mean that I’m assuming something bad is happening either. To answer your “why”, while I, and >1000 others here, have access to change this page, it is not a page I normally update (and I did not revert it), we have administrator accounts for many more reasons that updating javascript and that should be blatantly obvious. Site administrators have a variety of skills, and while javascript coding is not one of my strong points, networking and privacy are. — xaosflux ^Talk 06:56, 15 July 2007 (UTC)

"while javascript coding is not one of my strong points, networking and privacy are", can you please provide some evidence of these skills? My experience with your trackrecord indicates otherwise... In numerous occasions you have objected to actions taken by users on technical grounds, such as "system load", which had no baring in reality.--Gmaxwell 17:31, 15 July 2007 (UTC)

So, we've now had hours of discussion... and no one has brought up any concrete examples of problems. Would some third party be interested in restoring my faith in English Wikipedia by restoring the code so that I can continue to learn useful things about its performance? Thanks. --Gmaxwell 06:38, 15 July 2007 (UTC)

There appear to be a few things outstanding: How it will benefit our editors?, How will this content (new messages) be managed?; What is the expected amounts of false positives and false negatives expected from a geo-coded rsult? Is the geo-location being performed on the tool server itself, or being farmed out to another server? All of these leadto: Where have we shown a consensus that we want to run this? Making interface changes simply to run an experiment to "learn useful things" seems to be pushing it. — xaosflux ^Talk 06:56, 15 July 2007 (UTC)

FWIW, I'm never going to personally add this, but will also not remove it if another admin does add it. — xaosflux ^Talk 06:58, 15 July 2007 (UTC)

"How it will benefit our editors?" I think this point has been sufficiently explained, already. Are you just asking in order to make sure I've filled out Form #XBR1952 in triplicate, or are some useful applications of this notice not already obvious to you? I'd be less skeptical about your question were it not for the fact that the notice was already in use in a way which was clearly beneficial.

"Is the geo-location being performed on the tool server itself?" I already explained where it is being run, nothing is being 'farmed out' anywhere else.

I expect a fairly high false negative rate (missing people it should match), and a smaller but substantial false positive rate (matching people it shouldn't) for matching at the city level. Accuracy at the Continent level is very good. For the application here, targeting notices, the accuracy is quite acceptable. The primary purpose is to avoid displaying a notice to thousands of people who will not be interested in it for the sake of reaching hundreds of people who will be very interested in it. If a some of the audience misses it the result is still better than no notice at all, and if some extra people see it who shouldn't and then hit the hide button the result is still better than running a message for everyone.

Where have you shown there is consensus not to run it? It's a stretch to call this an interface change... it's a notice only on Special:Watchlist, but because of technical reasons it can only be accomplished by editing here. It is not reasonable to call this a site impacting change, since it is very clearly limited to a single page. I don't see any justification for the super-ordinary definition of consensus you seem to be demanding here.--Gmaxwell 17:10, 15 July 2007 (UTC)

Has anyone considered how freaked out some users might get if they see a box on their watchlist saying "come to the meetup in Washington DC blah blah blah" and they have no idea how Wikipedia knows where they live? Does the notice explain how this is being done? --- RockMFR 08:43, 15 July 2007 (UTC)

It didn't have to because it looks like a notice which would be displayed to everyone. No one whos actually seen it has asked, no doubt they just assumed that everyone is seeing it. Considering that no actual harm is done wouldn't it be more useful to wait until someone is actually freaked before spending too much time speculating about something which may never happen?--Gmaxwell 17:10, 15 July 2007 (UTC)

Reverted; see my summary (in the history [1]) for more information. Cbrown1023 talk 17:51, 15 July 2007 (UTC)

So I suppose I should leave a comment, since I added it in the first place. I note that this wasn't a "foundation insider" action or anything, just a normal action on behalf of a legit user since the page is only editable by admins.

I don't see anything wrong with the feature. (OK, actually, I think it's a cool idea, and I mentioned it at the meetup I was at yesterday -- the sort of audience to which it is targeted -- and they thought it was pretty cool also.) There's no privacy issues beyond normal operation: no one is able to associate a user with an IP from it; I suppose you do have to trust that toolserver is not evil (as you do with anything on toolserver), but toolserver is administered by people who are all personally known to WMF and trusted not to abuse that access, in the same way that core WMF server admins are.

I also admit that I think we need a cultural shift toward people being more accepting of just trying things and seeing what happens. (Especially changes that only affect users who are already active and informed, like something that only appears on a watchlist.) I kind of miss the project I joined several years ago, which was somewhat more open to that.

I haven't heard reports of anyone having issues with it from people whose user .js isn't borked... it's probably useful for those people to find out that they need to fix their user .js! Toolserver load is not significant.

And I do see a benefit to the users who see it. Certainly it looks like it had an effect on the page it was tested on. It's hard to target users who might be in a particular area, who don't think to list themselves in a category or who don't watch the meetup page; I think with the recent discussions about more local chapters and what the right regions are for those, this could have a good effect on letting people know what's out there off the wiki and getting people involved in local initiatives.

So I don't have any interest in getting into a huge war over this; it's not a pastime I enjoy. But I think it's a really cool feature with a lot of potential, and I am disappointed at the response here being as negative as it is when I've seen almost no negative response from the people targeted by the notices. Kat Walsh (spill your mind?) 18:09, 15 July 2007 (UTC)

Just trying things is one thing, if the people who are trying them are around to fix them if they break. Nobody's code is perfect and sometimes things break in unexpected ways in a production environment. In this case, the breakage turned out to not be a huge deal. The other thing is that the people who are active on this wiki were not informed, so how would anyone have known to fix it if the problems had been more drastic? The site JavaScript is a special case when it comes to just trying things because of heavy caching and the fact that some problems end up impacting everyone. I know that the dev team doesn't release the latest code from SVN without someone keeping an eye out for problems, so why should the communication/monitoring be any less for on-wiki changes that have the potential to affect everyone? Mike Dillon 19:17, 15 July 2007 (UTC)

Yet Jeffrey managed to remove it without difficulty when he suspected a problem. ... and of course it was being tracked, which is why I noticed that it stopped working when it was removed, since no one bothered leaving a courtesy note to me or Kat on the subject.

I understand your point, but I think it would be better made using an example of something that actually caused problems, because without an example we're just left speculating. We could spend all day countering each other's speculation with additional speculation, but that wouldn't be productive.

Reality is that the change included a basic level of documentation at the moment it went in... Perhaps it was not enough, but since no one saw fit to contact the names listed in the documentation that was provided, I have a hard to believing that saying anything more would have made a difference.--Gmaxwell 19:52, 15 July 2007 (UTC)

I'd like to wind this up, since the code is back in and there's nothing more to decide, but I'd like to note that an edit summary doesn't have the visibility of a note on a page like this one or WP:VPT. Someone probably should have contacted you directly, but for my part I thought you had admin access as a developer and it wasn't really clear to me why Kat made the actual change, so it wasn't apparent that the change was being monitored. Mike Dillon 23:04, 15 July 2007 (UTC)

Gmaxwell: I don't see how this particular example supports your "Wikipedia socially ill" theory. The thing is, this page is special, "be bold" does not apply here, and yes, status-quo on this page is better than new stuff, because of it's potential impact.

Personally, I don't any have problems with this testing. Had you included some basic support information, like "created by experienced coder, here's sample code generated by geonotice.py, the code is tested in browsers xxx and zzz, I'm monitoring the usage on the toolserver and any potential complaints on forums" - I wouldn't even start this thread.

P.S. I finally saw the notice myself, here's the code below ∴ Alex

Smotrov 15:21, 16 July 2007 (UTC)

The "potential impact" was to a single page in this case, one which is higher traffic than many but lower traffic than many pages we have open to editing by anons.

The popup media player used on many projects (including en) is viewed by 8x the number of distinct IPs per day as the watchlists and is far more invasive, far more kludgey, and far more dependent on the development host. The next version of my implementation will remove most of those issues... but the fact remains that no one is complaining about that because it doesn't happen to cross into a realm that someone on enwiki had decided is theirs to control.

And, of course, there was no impact. Yet you're still happy to stipulate additional requirements after the fact... According to you, I was required to have stated "created by experienced coder, here's sample code generated by geonotice.py, the code is tested in browsers xxx and zzz, I'm monitoring the usage on the toolserver and any potential complaints on forums"... Of course, had I actually stated thse, you would also be demanding that I perform yet another undocumented task. The text that was added to the page described what it does, and who you can ask about it. Yet when there were questions, no one asked me or the person who added it. It was reverted and you complained here that you weren't consulted.

Your first comments were "what about security?" and "load!" The latter is a line of thinking which is commonly invoked in a manner totally divorced from reality on enwiki as a bogus reason for opposing something, but the former has the possibility of some reasonable dialog, and if only you'd actually bothered asking me I would have been glad to answer your questions.

But even after that you feel the need to add hurdles to justify your postion. Now you have a nice little laundry list of tasks that should have been completed, some of which arguably were, and the rest of which are documented nowhere.

When we have multiple users demanding that every change be subjected to their own personal and often capricious obstacle course, it stunts progress, irritates contributors, and generally screws things up. It is a social ill, and like most other social ills it isn't the product of single outrageous actions but instead is a pattern of actions by many people over a long time which taken together are a harm to the community and, more importantly, our mission.

Obviously your intent is not to cause harm, and taken alone your actions would not be harmful enough to deserve mention. However, when we consider hundreds of other users also acting in similar ways the result clearly is harmful. Despite having the largest technical/semi-technical community by far enwiki's progress is stunted, or at least thats the view of myself and some other technical folks.--Gmaxwell 18:21, 16 July 2007 (UTC)

Please do not mix together two different points in my comment above. "Potential impact" referred to your "people being more accepting", about changes in general (you started those generalizations).

I did not say "you're requred to provide documentation", but that would be a nice thing to do; and be realistic - someone else would have asked anyway; and I don't see why this page is less suited to ask questions than your talk page ∴ Alex Smotrov 20:04, 16 July 2007 (UTC)

if (!document.cookie.match('hidedcn=1')){
 insertsub=document.getElementById("contentSub")
 insertsub.innerHTML = insertsub.innerHTML + 
'<div class="plainlinks" id="WN_DCN" style="width:98%; margin:5px auto 0; background:transparent; text-align:right;"><font size="+1" color="#000000">The next <a href="http://wiki.riteme.site/wiki/Wikipedia:Meetup/DC_2">Washington DC meetup</a> is Saturday the 21st.<br/></font><i>You\'re invited! [<a href="#" onClick="var date = new Date(); date.setTime(date.getTime()+86400000);document.cookie = \'hidedcn=1; expires=\' + date.toGMTString() + \'; path=/\';document.getElementById(\'WN_DCN\').style.visibility = \'hidden\';return false">hide</a>]</i></div>'
}

I notice this is accessing some python script, which generates that JavaScript code for some people. I don't see any documentation or code for the python script makes use of our IP address information. Gmaxwell is a trusted and experienced user, who I'm sure wouldn't misuse any of that information. Nonetheless, I think people would be reassured if the python source code was provided. --Aude (talk) 17:02, 16 July 2007 (UTC)

Not only is the code available to all the other developers, it's also been available at the same URL with all the other toolserver cgi-bin directory source I have there. http://tools.wikimedia.de/~gmaxwell/cgi-bin-source/. Sure there isn't a blinking flashing URL to it because there is nothing to it. I have another less trivial implimentation in C with configuration fed from a MW extension which won't be done until I think I understand what we need in terms of configuration.--Gmaxwell 18:21, 16 July 2007 (UTC)

It helps to know what the python script does, and how it uses the IP address, for those concerned about privacy (not trivial). Also, helps to know what it uses to map IP addresses to locations, and see why I'm not getting the watchlist notice. GeoLiteCity maps my IP address to a different state (not within the geonotice area) than where I'm actually located and a different state than what shows up when I look at dnsstuff (also off quite a bit, but within the geonotice area). --Aude (talk) 20:05, 16 July 2007 (UTC)

The commercial geocity database is much better, though none of them are perfect. At home it locates me to within two miles of my house, while I'm in the office it thinks I'm in California. (even though the arin whois for my office netblock has the right address, and the GeoIP city gets it right). I'd consider using the commercial geoip city database instead, but there is a valid philosophical issue with using anything thats not reasonably open and no-cost for the operation of our site.

One possible improvement would be introducing an additional user preference where you could specific one or more alternative locations, but then thats collecting additional private data that we would have to worry about protecting, and it is not clear how many things we'll use location data for. Notices are an obvious thing, and we could do a "Recently changed subjects near me" feature as well, but beyond that the applications are fairly slim. Nothing that I can come up with absolutely requires accurate location data.--Gmaxwell 21:06, 16 July 2007 (UTC)

Possibly, user categories might be useful. Though, I know there are userboxes that say "User:X lives or hails from Maryland". Then you get people who were born in Maryland, but no longer live there. Nothing private about these, though we would want to distinguish "lives in" from "hails from". --Aude (talk) 21:15, 16 July 2007 (UTC)

"Technical restrictions" title fix

The "Technical restrictions" title fix can be removed due to the new magicword {{DISPLAYTITLE:correct page name}}. It functions exactly the same as the "Technical restrictions" title fix does (it only displays as long as the displayed title is a valid link to that page). We need a bot to update all the pages to use this instead of the js class and then we can remove it from here. 81.34.54.162 18:24, 17 July 2007 (UTC)

Since most if not all of the additions of the RealTitle id are done by templates, it should be possible to change this without a bot by just putting {{DISPLAYTITLE:{{{1}}}}} into the relevant templates. Mike Dillon 20:21, 17 July 2007 (UTC)

Looks like this has already been done for {{lowercase}}. Mike Dillon 20:23, 17 July 2007 (UTC)

It's not as simple for {{wrongtitle}}, for example see P*U*L*S*E (film): the javascript code is smart enough not to replace the heading but it does replace the page title, also the template shows "The correct title is …" message. P.S. This seems to be a revision which enabled {{DISPLAYTITLE:}} ∴ Alex Smotrov 16:20, 18 July 2007 (UTC)

Administrator.js

Perhaps we should create MediaWiki:Administrator.js which can contain various scripts only useful for admins, which is then loaded from here only if the user has the sysop flag set in wgUserGroups. THat would allow us to add features less or not useful for normal readers and editors without burdening them interface or bandwidth-wise. —Ruud 10:21, 28 May 2007 (UTC)

User:^demon's "CSD reasons" script is a good example of something that might be useful there. CMummert · talk 12:20, 28 May 2007 (UTC)

That could easily be done. We'd import MediaWiki:Administrator.js iff their wgUserGroups array contains "sysop" ^demon^{[omg plz]} 22:22, 29 June 2007 (UTC)

I went ahead and implemented this, the file is at MediaWiki:Sysop.js. ^demon^{[omg plz]} 15:13, 24 July 2007 (UTC)

You could also mention bugzilla:10666… As for the code

• does if("sysop" in wgUserGroups) really work
• are you sure &ctype=text/javascript is not required
• opt-out would probably be a nice thing ( … && !window.disableSysopJS)

∴ Alex Smotrov 15:34, 24 July 2007 (UTC)

The in syntax requires JS 1.4 (e.g. won't work in IE5 or below). I'd also just use importScript to include the file, keeps everything in one place (so you don't forget the ctype etc.) —Ruud 16:29, 24 July 2007 (UTC)

for ( var g in wgUserGroups ) if ( wgUserGroups[g] == "sysop" && !window.disableSysopJS ) importScript( "MediaWiki:Sysop.js" );

Let's get back to the in part. wgUserGroups is not an object, it's an array. This code simply doesn't work for me in Firefox 1.5 / Opera 9.2 / IE6. Also, for anons var wgUserGroups = null and all 3 browsers report Javascript error. This needs to be fixed asap.

Your code seems okay to me, except I would add if (wgUserGroups) in the beginning to speed it up for anons a little ∴ Alex Smotrov 17:15, 24 July 2007 (UTC)

Are you completely sure about that? Objects in javascript can be treated a associative arrays, so one would expect that the reverse would also hold. —Ruud 20:30, 24 July 2007 (UTC)

Array in Javascript is not "Associative" by itself, I think this article should explain it better than me. In any case, javascript:alert("user" in wgUserGroups) (in browser address field) shows false in all browsers I tried.

By the way, everybody seems to have their own version of "call Sysop.js" code, here's mine: if (wgUserGroups && (wgUserGroups[0] == "sysop" ) && !window.disableSysopJS). Advantages: most simple and efficient; works right now; if it stops working, people who notice will be able to fix it :) ∴ Alex Smotrov 03:49, 25 July 2007 (UTC)

Personally I just use something like wgUserGroups.join(' ').indexOf('sysop'). --Splarka (rant) 07:16, 25 July 2007 (UTC)

Please set NavigationBarShowDefault = 0

{{editprotected}}

I found the instructions that all changes to Common.js must be discussed on the Village Pump, so I have moved this request there. All discussion should take place there. ←Ben^B4 01:35, 25 July 2007 (UTC)

I dont think it was such a good idea to cross-post (a notice and a link imho would be better) ∴ Alex Smotrov 03:49, 25 July 2007 (UTC)

Agreed, moved. ←Ben^B4 04:54, 25 July 2007 (UTC)

If consensus develops, then add an editprotected request again. — Carl (CBM · talk) 01:01, 27 July 2007 (UTC)

This bug fix has two supporters and no dissent -- the exact change requested is the section at that VP/T archive link. ←Ben^B4 00:27, 8 August 2007 (UTC)

Done. Cheers. --MZMcBride 03:45, 8 August 2007 (UTC)

Thanks. I believe I've fixed all of the docs and repercussions, modulo some remaining editprotects. ←Ben^B4 12:07, 8 August 2007 (UTC)