MediaWiki talk:Common.js/Archive 16

Archive 10

←

Archive 14

Archive 15

Archive 16

Archive 17

Archive 18

→

Archive 20

Namespace tab

Can the hack that caused the "article" tab to display "main page" on the main page be put back in? Maximillion Pegasus (talk) 00:21, 6 January 2009 (UTC)

No. The hack is unacceptable. If this problem is to be resolved, either move the main page to a namespace with a more appropriate tab or edit MediaWiki:Nstab-main to be less specific. See #Main Page tab above. —Remember the dot ^(talk) 04:52, 6 January 2009 (UTC)

Shuffle for election candidates

The election was months ago, can the "dshuf" code be removed? —Remember the dot ^(talk) 17:51, 10 January 2009 (UTC)

Oh dear. How did we forget to remove that? Please do so. (Be sure to remember the addOnloadHook bit as well. :-) --MZMcBride (talk) 22:34, 10 January 2009 (UTC)

Done. I also removed the function name "mainPageAppendCompleteListLink" - since the function should only be called once, there is no point in adding overhead by giving it a name. —Remember the dot ^(talk) 23:07, 10 January 2009 (UTC)

Modernista revisited

I e-mailed Mike Godwin, the Wikimedia Foundation's general legal counsel, asking him what to do about Modernista's trademark infringement. I suggested using JavaScript to blank any page viewed through Modernista, and he replied "I'm ready to resort to any technical measure." So, I'd like to replace the Modernista referrer with the following code:

if (/modernista\.com/.test(document.referrer)) {
    document.removeChild(document.documentElement)
}

Hopefully that will prompt Modernista to rethink their site. —Remember the dot ^(talk) 18:11, 10 January 2009 (UTC)

No objection from me. --MZMcBride (talk) 22:26, 10 January 2009 (UTC)

Done. —Remember the dot ^(talk) 23:08, 10 January 2009 (UTC)

Uhm... what's the problem here, or did I miss something? What they are doing might not be very nice (although I don't really see a problem with it honestly). But does that warrant adding something to the global JavaScript? How many people visit their site anyway? —Ruud 23:52, 11 January 2009 (UTC)

We've had something in the global scripts to react to their site for months now. Previously it just added a warning message, but now we blank the page; it's just a slight escalation, we're not going from scratch. I fully support the idea, and not just because Godwin Said So, although that is a very compelling justification to take action. Happy‑melon 10:20, 12 January 2009 (UTC)

Yeah, but this modernista.com site just a small website, with an original design, drawing maybe 10 vistors a month. Or are they some big, bad, evil, site that is misusing our good name and confusing billions of visitors? —Ruud 16:49, 12 January 2009 (UTC)

The issue is trademark infringement, and I was never a fan of making special JavaScript for them. A legal recourse seems more appropriate to me, but perhaps that's not feasible for one reason or another. —Remember the dot ^(talk) 02:43, 14 January 2009 (UTC)

"Remove these lines"

Is there any objection to removing these lines from Common.js?

            Button.style.styleFloat = "right";    //
            Button.style.cssFloat = "right";      // REMOVE THESE LINES
            Button.style.fontWeight = "normal";   // ON 10 FEBRUARY 2008
            Button.style.textAlign = "right";     // 
            Button.style.width = "6em";           //

They seem to have been replaced by

.collapseButton {         /* 'show'/'hide' buttons created dynamically by the        */
    float: right;         /* CollapsibleTables javascript in [[MediaWiki:Common.js]] */
    font-weight: normal;  /* are styled here so they can be customised.              */
    text-align: right;
    width: 3em;

in MediaWiki:Common.css. —Remember the dot ^(talk) 19:45, 10 January 2009 (UTC)

The code was added today. I'm pretty sure the 2008 bit is a typo (should be 2009). --MZMcBride (talk) 22:31, 10 January 2009 (UTC)

Ah, I see. That makes more sense. —Remember the dot ^(talk) 23:10, 10 January 2009 (UTC)

Lol, whoops! I knew I was going to get something (else) wrong in that update. Thanks for the spot. Happy‑melon 10:53, 11 January 2009 (UTC)

Yes, perhaps. I wrote that code and I probably had a good reason for doing it with JS instead of CSS. I think it breaks IE6, but I can't quite remember anymore. —Ruud 23:38, 11 January 2009 (UTC)

Ohw, and the width of the button should really be xem, where x is the number of characters in the caption (including the brackets). —Ruud 23:47, 11 January 2009 (UTC)

That is a misconception; it should match the 6em width of the v·d·e links. — Edokter • Talk • 00:52, 12 January 2009 (UTC)

No, I wrote that code before that v.d.e links stuff ;) So the v.d.e link width should probably match with the width here. —Ruud 01:59, 12 January 2009 (UTC)

It can't; some templates use the long form of 'view·talk·edit' which just fits in 6em. But maybe there should be some mechanism to customize the width of {{tnavbar}}. — Edokter • Talk • 02:38, 12 January 2009 (UTC)

This is discussed above, 6em is massively too wide; what I did in the code I added to Common.css was to make it 3em by default, and add another declaration to override it back to 6em when inside the .navbox class. Isn't that the best solution for everyone? Or are there other instances where it should be 6em? Happy‑melon 10:17, 12 January 2009 (UTC)

I think it needs to be 6em if you're view Wikipedia using a (nearly) monospaced font. Hmm... actually I seem to be using a wrong definition of Em. My main point was, however, that I think using CSS instead of JS is going to break something. —Ruud 16:52, 12 January 2009 (UTC)

[show]

[show]

[edit]

[edit]

3em is definitely too small for me. The text falls outside the box, even the sans-serif one. —Ruud 17:15, 12 January 2009 (UTC)

[edit]

Of course, what we're actually looking for is width:auto;... :D Happy‑melon 18:38, 12 January 2009 (UTC)

Tested on IE6, applying styles via CSS works fine. Happy‑melon 23:35, 12 January 2009 (UTC)

I've restored the code to Common.js. Remember that we still have 30 days decaching time before we can even think about removing the hardcoded styles, so if we find a catastrophic problem before then, well, we should leave how it is now anyway so that people with modern browsers can still style them! If you can remember why you didn't do it with CSS, Ruud, I'd love to hear it, but my suspicion is that you just didn't think of it, which is a perfectly valid reason! Happy‑melon 11:08, 13 January 2009 (UTC)

I've looked through the edits of November 2006 and while there were some problems with styling and IE6 I don't seem to have tried styling it through the CSS sheet. —Ruud 17:49, 13 January 2009 (UTC)

"please use talk for ALL changes"

I find it somewhat amusing that of my three edits yesterday, the one that made no functionality changes whatsoever was the one to be reverted as "reverted code changes". Does anyone have any actual objections to this edit, which merely realigns the comments sections and moves a few braces around? Happy‑melon 11:11, 11 January 2009 (UTC)

Strike that, I see that MZ did actually revert all my changes, as well as the ones in Common.css. I accept that there is a balance to be struck between manintaining code integrity here and not being overly bureaucratic, but my opinion is that this is somewhat on the 'bureaucracy' side of that line, especially as MZ reverted changes both here and at Common.css that were to improve readability while making no functional changes whatsoever. Thoughts? Happy‑melon 12:50, 11 January 2009 (UTC)

Best practices for editing these pages?

I finally took the time to put words on a page vis how I see our Best Practices in editing system messages, particularly the skin files: WP:EI. I don't think we need anything as pretentious as a policy or guideline to control how we work on these files, but it would be nice to have something to point to to ensure we're all reading from the same song sheet. Comments and criticisms would be very welcome. Happy‑melon 23:06, 11 January 2009 (UTC)

Seems reasonable. Just an observation I've made watching these pages: it's quite pointless in making an undiscussed changes as it always gets reverted. 50% of the time because it's a stupid/pointless/annoying/etc. change that probably has been rejected in that past already. 40% of the time because it's essentially a good change but completely breaks some stuff in a totally unexpected ways. And 10% of time because someone else thinks that it should have been discussed first.

And on a more positive side, pretty much all the scipts added have been significantly improved (faster, better compatibilty, more readable, or just better feature-wise) during the discussion by all the JS savvy people hanging around on this talk page. Looking at it pragmatically, discussing something before making a change in article space is almost always going to be a waste of everybody's time, changing something before discussing it on the interface pages is also almost always going to be a waste of everybody's time. —Ruud 23:36, 11 January 2009 (UTC)

Deleting element without confirming that it exists

{{editprotected}} Line 439:

realTitleBanner.parentNode.removeChild(realTitleBanner)

Should be changed to:

if(realTitleBanner) realTitleBanner.parentNode.removeChild(realTitleBanner);

This is causing javascript errors because certain templates use realTitle successfully enough but do not add the realTitleBanner element. This causes a javascript error which prevents subsequent scripts from running. — CharlotteWebb 17:22, 16 February 2009 (UTC)

Done. --- RockMFR 18:03, 16 February 2009 (UTC)

Two minor changes

I'd like to make two minor changes here. First, removal of the code that is commented with "REMOVE THESE LINES ON 10 FEBRUARY 2009". Second, removal of the comment regarding DisableRealTitle, since this functionality is no longer present. Any objections? --- RockMFR 00:19, 17 February 2009 (UTC)

Just curious, what happened to the disable functionality? --MZMcBride (talk) 00:29, 17 February 2009 (UTC)

Y Done. DisableRealTitle got dropped when I refactored the code last July. I didn't know it was there, but since nobody even noticed it until now it's probably not much of a loss. —Remember the dot ^(talk) 01:40, 17 February 2009 (UTC)

AJAX RC

On many, many other wikis I've seen the AJAX code for automatic RC. Why doesn't wikipedia, the most famous Wiki in the world, have it? If nobody knows what I mean, I can go fetch the JavaScript from my home-wiki. Timeroot (talk) 02:38, 18 February 2009 (UTC)

Where is MediaWiki:Common.js

Where do I find MediaWiki:Common.js, for example in LocalSetting.php or config file. Please help. Xxxsacheinxxx (talk) 15:29, 18 February 2009 (UTC)

For all intents and purposes, it's exactly where you linked to it at. Physically, it's in the database. 「ダイノガイ千？！」^{(Dinoguy1000)} 20:23, 18 February 2009 (UTC)

I think he meant to ask where the file in invoked. — Edokter • Talk • 20:56, 18 February 2009 (UTC)

Added mobile gateway link

I've added a JS bit to add a link for iPhone, iPod Touch, and Android users to switch to the page on our mobile-optimized gateway at http://en.m.wikipedia.org/

This is our new gateway which is replacing the old http://en.mobile.wikipedia.org/ one, and currently is *much* nicer on higher-end mobile browsers. We're hoping to drive some more test traffic there, and do a bigger announcement in the next couple months. (Currently I've set it to only add the link on 25% of page views.)

Please file bugs in Bugzilla for any problems you encounter if you go exploring there! :)

In the future we'll swap this JS linking out for something more permanent. --brion (talk) 01:04, 19 February 2009 (UTC)

I'd like to tweak the wording from "in" to "on" and add a period after the link (div.appendChild(document.createTextNode("."));). Any objections from anyone? --MZMcBride (talk) 08:11, 19 February 2009 (UTC)

Works for me... I've gone ahead and tweaked that as well as bumping up the probabilistic display so it just always shows the link; no load probs yet. --brion (talk) 19:57, 19 February 2009 (UTC)

Technical restrictions bugfixes

I just fixed two minor problems with the "technical restrictions" code:

1. The code did not work on pages outside the main namespace or pages in the main namespace that do not contain at least one wikilink.
2. The code allowed the title bar to display a title completely different from the actual page title. This was particularly a problem for pages like Back and Forth (film), which previously showed up as <---> - Wikipedia, the free encyclopedia. If we can't represent the title properly, let's not pretend to. This is the same sentiment that Brion voiced in bug 12998.

—Remember the dot ^(talk) 21:13, 15 March 2009 (UTC)

Geonotice

There was talk on Wikipedia talk:Geonotice#Restoring geonotice functionality to bring back the unmaintained geonotices in a more community driven way after half a year of disuse. I've implemented it as User:Para/geonotice.js (to be moved into MediaWiki namespace?), which would be called from MediaWiki:Common.js/watchlist.js in two parts:

importScriptURI('http://toolserver.org/~para/cgi-bin/geoip');
importScriptURI('http://en.wikipedia.org/w/index.php?title=User:Para/geonotice.js&action=raw&ctype=text/javascript&maxage=3600');

The first bit inserts the geographical coordinates of the requesting IP in json format in the watchlist page HTML. Hopefully a bit later, the second script compares admin added ranges to the coordinates from the first script and adds the given notice when they fit. There's a possibility for a race condition, but it's not an issue if notices aren't shown on the very first watchlist load. On caching, the geoip tool has max-age 12 hours and the Javascript with the notices has max-age 1 hour. Could people watching this page review? To test, see User:Para/monobook.js --Para (talk) 22:31, 17 March 2009 (UTC)

This looks great, Para. Thanks for your work on this.--Pharos (talk) 18:02, 20 March 2009 (UTC)

I agree. Looking good and will likely be much better maintainable. --TheDJ (talk • contribs) 18:48, 20 March 2009 (UTC)