Jump to content

Wikipedia:Village pump (technical)/Archive 86

Add links
From Wikipedia, the free encyclopedia
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216

Sometimes see pages without any CSS for a split-second?

Sometimes, for some reason during when a page is loading, I'll see the page for a split-second without any CSS whatsoever. So, the background would be white, and the text would be pretty big and take up 100% of the width—similar to how the wiki would look to a mobile browser. This shouldn't be happening since CSS applies pretty quickly, especially since it should be cached by my browser. Is anyone else experiencing this? When a page loads for me, it now does so in three, recognizable steps: load the content; apply global/user CSS; apply user JS. I can see a page transform through each process. Gary King (talk · scripts) 19:16, 17 February 2011 (UTC)

Here's a screenshot to show what I'm seeing. I just so happen to hit the Stop button while the page was loading to catch this moment. Gary King (talk · scripts) 21:54, 17 February 2011 (UTC)
I'm getting the same thing. Overall the page loading seems a little slower, but maybe that's just do the jumping formatting.   Will Beback  talk  22:08, 17 February 2011 (UTC)
Page loading seems perhaps a tad faster for me, actually, which was the whole point of 1.17 so I guess they kind of succeeded. However, by far the biggest culprit for slow loading time is server-side rendering, which has always been the cause of the slowness. I assume that things are already cached as much as possible but really, about 80% of loading time is still spent on the server-side. Gary King (talk · scripts) 00:15, 18 February 2011 (UTC)
There's no "sometimes" about it for me: there's always a one-to-two-second delay from when the page text shows up to when the formatting shows up, with the side effect that section links are only approximations. --Carnildo (talk) 00:16, 18 February 2011 (UTC)
Still happening, hmph. Gary King (talk · scripts) 01:30, 20 February 2011 (UTC)

Gadgets stopped working

Pop-ups, clock/purge, blackscreen have stopped working. Were working earlier today. Monobook, Chrome, WinXP. DuncanHill (talk) 21:08, 17 February 2011 (UTC)

Hmm, and now they are back but not when in the edit screen. Predictive search also not working. DuncanHill (talk) 21:28, 17 February 2011 (UTC)
Gadgets and predictive search are working for me in Monobook, even in the edit screen. Gary King (talk · scripts) 21:56, 17 February 2011 (UTC)
Related to my note above? See here - do you use any scripts that use wgVectorEnabledModules? Run the page in firefox and bring up a Java console window and you should be able to find the error.  7  22:42, 17 February 2011 (UTC)
I have no idea if I run anything that uses wgVectorEnabledModules, whatever they are. How would I know if I did. I really don't want to have to download and install yet another browser - . Anyway, gadgets are now coming and going randomly. Added to the much slower page-loading since the upgrade, I think I might as well call it a day. DuncanHill (talk) 16:28, 18 February 2011 (UTC)

Finding permanent url

I don't know if this is the right place to inquire about this issue. If not, then please refer me to the relevant page. Here is the problem I am faced with. I wanted to add a reference to the Farouk Sultan article. More specifically, I wanted to provide a link to his CV page located in the official website of the Supreme Constitutional Court of Egypt. The problem is that the page is written in Javascript, and opens only in Internet Explorer (not Firefox). The specific url of the page is not displayed in the address box. I would like to know how to find the specific permanent url of the CV page so as to be able to link back to it in the aforementioned Wikipedia article.

  • Here is the main page with a list of all the members of the court: http://www.sccourt.gov.eg/CourtMembers/CurrentCourt.asp
  • Farouk Sultan's photograph is the first one displayed on the page (see enlarged version). When I click on the Arabic-language name below his photograph, his Arabic-language CV page opens. However, instead of getting a normal url starting with http, this is what I get:
    javascript:memberCv(95,'%D8%A7%D9%84%D8%AA%D8%B4%D9%83%D9%8A%D9%84_%D8%A7%D9%84%D8%AD%D8%A7%D9%84%D9%89_%D9%84%D9%84%D9%85%D8%AD%D9%83%D9%85%D8%A9');
  • My question is: how can I manage to find the permanent url linking to the CV page?

I'm not sure if I have made myself fully understood. If things are not clear, then please tell me so I can rephrase myself. Regards. --BomBom (talk) 00:52, 18 February 2011 (UTC)

Yeah, I hate websites that use that kind of design.
Looking at various CVs, it looks like they use a single URL -- http://www.sccourt.gov.eg/CourtMembers/memberCv.asp -- to display each member's CV. I looked at the Javascript code for the main page, and saw that the main page has a memberCv function that sends a POST request to the CV page with a couple of parameters, one of which is named MemberId, to tell it which CV to display; since it's a POST request, there's no URL querystring shown in the address bar on the CV page. The Javascript code you posted for the link calls the memberCv function with the MemberId set to 95 and the other parameter set to some Arabic text.
The good news is that, according to my testing, the CV page can be accessed with a GET request (which enables a querystring), so I constructed a URL with the querystring (including a MemberId -- the other parameter, which was the same for all the members, appears to be unnecessary) manually added. Here you go: http://www.sccourt.gov.eg/CourtMembers/memberCv.asp?MemberId=95
Lucky Wizard (talk) 02:41, 18 February 2011 (UTC)
Well, I think "Wizard" is the right word rather than "Lucky". If I had spent my whole life studying the problem I would never have come up with that! Thincat (talk) 18:26, 18 February 2011 (UTC)
I agree with Thincat. I would have never been able to find the URL all by myself. Thanks a lot, Lucky Wizard! --BomBom (talk) 13:08, 19 February 2011 (UTC)

Unblockself permission

Who can assign or remove the "unblockself" permission that's mentioned in the new release notes? When I look at another admin's user rights management page, I don't see such a permission either in the list of rights that I can change or in the list of rights that I can't change. Nyttend (talk) 01:46, 18 February 2011 (UTC)

All admins already have it. It's in Special:ListGroupRights as part of the admin package. The only way to remove it is to modify the server configuration. T. Canens (talk) 01:58, 18 February 2011 (UTC)
You don't assign individual permissions, you assign groups that contain those rights. Special:ListGroupRights lists each group and the rights those groups have. Reach Out to the Truth 05:02, 18 February 2011 (UTC)
Hmm, okay; thanks for the help. Other than removing the "edit" permission from the occasion vandal or spammer, I virtually never modify permissoins. Nyttend (talk) 04:27, 20 February 2011 (UTC)

Editing page visuals

I'm not sure this has been discussed before on this page. I use Firefox. Both phenomenons are cleared temporarily (and only temporarily) by selecting "Preview". Never had this problem until the recent changes. These two things have been happening for a day or two:

  • When editing, sometimes, too frequently now, when I place the mouse cursor somewhere on the page, the blinking cursor disappears, leaving me to wonder if it's where I want to be on the page. I figure out where I am by hitting the Spacebar and watching the text move. This phenomenon clears up if I do a "Preview".
  • The Insert Link option works fine, but goes a little whacked after one or two uses. I can insert link #1, perhaps even #2 and #3. But at some point when I select the link button, the popup is so large it engulfs my page to the point I can't move it from side to side to see what I'm bringing up. This never happens on the first "link" of the edit, or the first "link" after a "Preview". Clicking on "Preview" clears the oddity, but only until I want to insert more than one or two links.
Maile66 (talk) 12:54, 18 February 2011 (UTC)

I find the editing page has been jerky & jumpy since yesterday. When one adds or deletes words while editing or posting (even in edit summaries), the thing jumps at the touch of any keys. GoodDay (talk) 14:04, 18 February 2011 (UTC)

Oh, yeah...and the jumping. I thought it was just me. Thanks for mentioning that.Maile66 (talk) 14:13, 18 February 2011 (UTC)
I'm experiencing the same issue ("jerky & jumpy") with Internet Explorer. -- Black Falcon (talk) 20:29, 18 February 2011 (UTC)
We're also getting reports of that at the Vietnamese Wikipedia. – Minh Nguyễn (talk, contribs) 19:42, 19 February 2011 (UTC)

Google Chrome

I don't see anything in the Pump search regarding this specific issue, so: Can someone comment on (or point me to) any known issues in editing with Google Chrome? Specifically, I am seeing the insertion of additional line breaks and, in a few case, extra indentions upon saving comments. I am kind of "forced" to use Chrome on one of my main access computers, so changing back to Mozilla (in which I had no problems) or something else is not really an option. David Able 18:36, 18 February 2011 (UTC)

Also have twinkle issues for me; will not open user talk pages after reverting edits. --Perseus8235 19:15, 18 February 2011 (UTC)
Did you get an error message of any kind? Did it say "We received no revision; something is wrong. Bailing out!" ? —Soap— 16:08, 19 February 2011 (UTC)

Search box not clearing prompt text

If I click in the search box before the page finishes completely loading, the string "Search" goes black and becomes part of my query instead of vanishing as it should. This is clearly due to resource loader not loading the script that clears the box until the end of the page. It's very annoying because I frequently open a new tab with just my user page to give me a new search box when I need to bring up something in addition to whatever I have open. I recommend that we delete the "Search" prompt from the box on initial load. Once the java script is loaded, it can then fill in the prompt text because it will be in control to also remove it should the user click on the box. I'm running FF 3.6.13 and this never happened prior to MediaWiki 1.17. —UncleDouggie (talk) 04:56, 19 February 2011 (UTC)

Issues with "Search" becoming real text were reported on bugzilla at least 4 times (including my own report), see bugzilla:25683. Meanwhile, the following code in your vector.js will allow you to open search results in a new tab by pressing Shift-Enter (or Shift-Click on dropdown suggestion):
$j(function(){
 $j('#searchform').bind('keyup keydown mousedown', function (e){ 
   $j(this).attr('target', e.shiftKey?'_blank':'')
 })
})
— AlexSm 05:23, 19 February 2011 (UTC)
Wow, more magic Javascript to go horribly wrong during the next MediaWiki "upgrade". :-) Thanks! —UncleDouggie (talk) 08:47, 19 February 2011 (UTC)

Featured article tools not appearing at FAC nominations

For some reason, the toolbox and article links template are no longer appearing at FAC noms: compare Wikipedia:Featured article candidates/Irresistible (Jessica Simpson song)/archive1 to Wikipedia:Featured article candidates/Me and Juliet/archive1. I suspect it has something to do with the code at Wikipedia:Featured article preload. Can somebody take a look? Dabomb87 (talk) 17:07, 19 February 2011 (UTC)

The problem is with the new version of MediaWiki, the sixth entry under "Bug fixes in 1.17" is "Preload parser now parses <noinclude>, <includeonly> and redirects.". Before 1.17, a preload would not parse these tags, so they would just appear with their content fully intact. Unfortunately the featured article preload had relied on this "bug"/"feature" to allow the transclusion of the tags themselves, most importantly the <noinclude> tag, which previously allowed the toolbox to be loaded surrounded by noincludes, so it would appear on the review page but not on the main candidates page. I'm looking into a solution. Intelligentsium 18:07, 19 February 2011 (UTC)
I've come up with something that, while not pretty and indeed rather barbaric, should work. You can check my work at [1]. Intelligentsium 18:29, 19 February 2011 (UTC)
The rather less horrible <noin<noinclude/>clude> also works. This change actually allows the preload to be made less hackish, not more, as you can eliminate the use of {{void}} for the reverse process (genuinely wanting something to be shown only on the page itself, and not included when it's used as a preload). Happy‑melon 19:11, 19 February 2011 (UTC)
Well, it's working now. Thanks for your help. Dabomb87 (talk) 01:51, 20 February 2011 (UTC)
Mentioned above, BTW. Anomie⚔ 01:55, 20 February 2011 (UTC)

importScript > mw.loader.load

I'm trying to replace (soon to be) deprectated code in my vector.js page, but mw.loader.load does not work as expected. Does it expect a full URL? — Edokter (talk) — 23:53, 19 February 2011 (UTC)

It looks like it requires the argument to start with "http://" or "https://". Gary King (talk · scripts) 01:00, 20 February 2011 (UTC)
Though deprecated, it is expected that a next version of resource loader (which will be more focused on userscripts) will bring a true replacement for importScript(). also, importScript() is so widely used that any definitive deprecation of it will be a huge amount of work, so a few extra won't really hurt. Of all the deprecations in the JS core, replacing importScript() is most likely the least important one. —TheDJ (talk • contribs) 01:16, 20 February 2011 (UTC)

Transclusion of Special:Watchlist

How can I transclude Special:Watchlist onto my userspace? I want to make a page with my article alerts, watchlist for the past 12 hours, and other useful stuff that I make use of commonly. However, transcluding Special:Watchlist creates a plain link to it.

How can I do this? If it can't be done, can we make it possible? Even if it just transcludes the watchlist of the user looking at it (or "you are not logged in" for IPs), that would work for privacy concerns. - ʄɭoʏɗiaɲ τ ¢ 02:54, 14 February 2011 (UTC)

I don't believe it's currently possible, perhaps the reason being that if someone were to come across a random page that shows their watchlist, then they'd be quite alarmed. That's why nothing that is personalized to a single individual can be entered onto any page. Gary King (talk · scripts) 07:13, 14 February 2011 (UTC)
Seems a silly reason. They'd come to the village pump and be informed that "somebody is transcluding special:watchlist. Whoever is viewing it will see their own watchlist." The ability to create a customized watchlist with your own gadgets. - ʄɭoʏɗiaɲ τ ¢ 14:43, 14 February 2011 (UTC)
Not silly at all. Imagine browsing Facebook and seeing comments from your profile posted on another person's profile, or your email from Gmail posted on another person's Google profile. If you browsed around here and came across Example and it showed your watchlist because a vandal transcluded it, and you were a newbie and so never heard of the village pump (I can certainly attest that it's quite difficult to find, considering someone had to point me there early in my wiki days when I screwed up a few times), then it can be quite difficult to grasp that someone merely "transcluded" your watchlist to a page. It's also hard for a newbie to explain what exactly is going on when the page looks a bit different to everyone who sees it. Gary King (talk · scripts) 16:09, 14 February 2011 (UTC)
The real reason it can't be done is because it would break caching. The transcludable special pages are the ones that don't have different output depending on which user visits them. Mr.Z-man 23:26, 14 February 2011 (UTC)
Anyway, methods of achieving your desired effect:
  1. Write a script to querying the API and insert it into the page. Unfortunately, the parse API is rather broken [2]. Using iframe or AJAX also works.
  2. Create a sub-page linking to page and use {{Special:RecentChangesLinked/User:Floydian/Watching}}. More cumbersome to add pages.
  3. Just use bookmarks or have a script to add links/HTML to Special:Watchlist.
See guys that wasn't so hard. — Dispenser 02:45, 15 February 2011 (UTC)
The API has a specific method for grabbing the watchlist [3] Platonides (talk) 20:43, 15 February 2011 (UTC)
Er... Ok, I get 2 and 3... But how do I call a php script from within wiki? Would it be something I'd write into my .js?
Better yet, are there any examples of code calling the API onto a wiki page that I can take a look at? - ʄɭoʏɗiaɲ τ ¢ 15:09, 18 February 2011 (UTC)
(e/c)You have to write a JavaScript to get your watchlist from the API (https://secure.wikimedia.org/wikipedia/en/w/api.php?action=query&list=watchlist) then parse that, and dynamically add it to wherever you want it added in Wikipedia. —TheDJ (talk • contribs) 15:20, 18 February 2011 (UTC)
Gah! I can't wrap my head around javascript. It's the most confusing programming language to me. It doesn't help that the way it must be implemented on wikipedia just makes my brain explode. Just put a script on the page doesn't work, it just displays it as a piece of code. You can't just call a script from a page either, because that requires a script to call the script function. Its seems you have to set up the javascript to (using that script) detect when you are on the correct article, and insert it onto the page in the correct place.
User:Floydian/callwatchlist.js is one of a few attempts. I've tried longer more complicated codes that have a bunch of stuff that makes no sense on them. I've tried ajaxinclude, function include, plain ol' include, and the results is it displays the link of the api query. - ʄɭoʏɗiaɲ τ ¢ 20:02, 18 February 2011 (UTC)
Anyone that can point me in the right direction / bump to avoid archival - ʄɭoʏɗiaɲ τ ¢ 22:44, 19 February 2011 (UTC)
User:Animum/watchlistUpdate.js is an interesting script I found, that automatically updates your watchlist. So, you can use that as a basis on determining how to fetch your watchlist, and then it can be manipulated with JS afterward. Gary King (talk · scripts) 01:27, 20 February 2011 (UTC)
I have created a script for you: User:Svick/transcludeWatchlist.js. To use it, put importScript('User:Svick/transcludeWatchlist.js'); to your skin.js page. To transclude it on a page, use the code <div id="transclude-watchlist" /> like here. The appearance is based on normal watchlist (although far from the same) and can be tweaked by changing the result.innerHTML += … line (but you'd have to create your own copy of the script, since you can't edit other people's javascripts). Svick (talk) 02:16, 20 February 2011 (UTC)
Oh wow! Thank you! I was trying... but what I was getting was a page that loaded, then went blank and displayed "function toString() { [native code] }function toString() { [native code] }"... Like I said, javascript kills me. Again, thank you very much! - ʄɭoʏɗiaɲ τ ¢ 03:45, 20 February 2011 (UTC)
Would someone mind adding to the code, to make the watchlist auto-refresh, and open links in a new tab? I sort of guessed at User:JohnnyMrNinja/AppTab.js, but I don't actually know JS so I'm not surprised it didn't work. ▫ JohnnyMrNinja 04:50, 20 February 2011 (UTC)
I have added the ability to auto-refresh. Just add something like transcludeWatchlistReloadTime = 60; // 1 minute to your Special:MyPage/skin.js. To enable opening links in new tab or window (depends on browser settings) use transcludeWatchlistNewWindow = true;, but it currently doesn't work for links in edit summaries. Svick (talk) 14:41, 20 February 2011 (UTC)

Some revisions didn't make 1.17

It seems the changes to the diff-engine didn't make it into 1.17, especially revisions 75658 and 75662, which would have fixed some minor display issues in diffs. Were they entered in the wrong branch? — Edokter (talk) — 14:07, 16 February 2011 (UTC)

They were reverted because they changed the wrong piece of software: Wikipedia uses wikidiff2, not the PHP difference engine. The fixes were ported to the latter, but I don't know if it's been upgraded. I'll ask. --Catrope (talk) 15:14, 16 February 2011 (UTC)
DifferenceEngine.php was renamed to WikiDiff.php; the patches are still there. — Edokter (talk) — 15:02, 20 February 2011 (UTC)

Speedy-deleting oddity

(boldly moved from WP:AN, Magog the Ogre (talk) 00:56, 17 February 2011 (UTC))

I am an admin. Until recently, when I speedy-deleted a page, the start of the contents of the text box created by the speedy-delete tag, appeared on the deletion window as the reason for the deletion. That saved much time. But, after today's Wikipedia downtime, the reason for the delete always appears as "Other reason", and I must type a reason in. Anthony Appleyard (talk) 23:25, 16 February 2011 (UTC)

This seems to be an erratic problem, it works fine for me. What skin are you using? Have you tried purging your cache? Happy‑melon 23:28, 16 February 2011 (UTC)
This is happening for me as well. The original tagger's deletion criteria no longer appears when I hit the 'delete' tab from the article page. --Jezebel'sPonyobons mots 00:06, 17 February 2011 (UTC)
That's not been working for a while now but at least I can pick one of the reasons from the box rather than having to type it in. CambridgeBayWeather (talk) 00:43, 17 February 2011 (UTC)

I'm quite sure this is a bug related to the Mediawiki upgrade to 1.17, correct? Magog the Ogre (talk) 00:57, 17 February 2011 (UTC)

  • Not a cache problem - I have tried three different browsers - all the same. One clue: in Firefox when I go into the delete screen, I get the message "Transferring data from meta.wikimedia.org" which does not go away. — RHaworth (talk · contribs) 01:32, 17 February 2011 (UTC)
  • Just a note, but clicking on the word "deletion" inside of the templates still auto-populates the deletion summary, with the added benefit of automatically including information in the template, such as the URL for a copyvio. Cheers, everyone. lifebaka++ 02:02, 17 February 2011 (UTC)
  • I get the same "Transferring data from meta.wikimedia.org" message in my browser's status bar that doesn't go away even though the page is finished loading. But it happens on every page for me, not just the delete screen. I also can't get the revisionjumper gadget to work.. -- œ™ 02:14, 17 February 2011 (UTC)
  • I just tried to do a speedy delete, and I clicked various occurrences of the word "deletion" on the page to be deleted and in the deletion window, and the reason for deletion stayed as "Other reason". I use Firefox. Anthony Appleyard (talk) 06:38, 17 February 2011 (UTC)

Broken MediaWiki:Sysop.js loading perhaps ? —TheDJ (talk • contribs) 07:27, 17 February 2011 (UTC)

$(document).ready not working in edit mode

I have this script and tested with alert, which is not firing in edit mode, this worked before 1.17version. Kindly help me to fix. -- Mahir78 (talk) 16:14, 18 February 2011 (UTC)

Still waiting for a help. -- Mahir78 (talk) 06:36, 19 February 2011 (UTC)
Does $(function () {alert("It works!";}); work? – Minh Nguyễn (talk,

contribs) 19:44, 19 February 2011 (UTC)

I commented jquery - UI file, which is now defaulted with the new version 1.17. Now it works. Thanks Minh Nguyễn. Both $ and $j works. -- Mahir78 (talk) 07:49, 20 February 2011 (UTC)

Old Username stticking around in watchlist

My watchlist currently shows User:Bot337 as the last person to edit WT:CHUU. They've gone through a rename however, and are now just User:336, although my watchlist still shows their old username. This is on the latest Firefox 4 beta. I don't think this is a cache error, I've cleared my cache and it still does it. I probably should have taken this to bugzilla, but I thought I'd get input from the pump first. demize (t · c) 01:57, 19 February 2011 (UTC)

The rename appears to be very recent. Sometimes, they take a while for everything to be updated. /ƒETCHCOMMS/ 04:24, 19 February 2011 (UTC)
I'm aware of that, it just seems odd, and it showed as User:336 in the history, but as User:Bot337 in my watchlist (and still does). If it stays this way, I may take it to bugzilla, since it's unexpected behavior, but the page will probably drop off my watchlist soon. demize (t · c) 00:57, 20 February 2011 (UTC)
I think that is because the watchlist is generated from a recent changes feed, which is not updated with changes like user renames. For example, when a page is edited and then moved, your watchlist will also show the pre-move edits under the old name. Ucucha 18:59, 20 February 2011 (UTC)
That would make sense, but in my opinion (to make things less confusing) things like username changes should be updated in it. Page moves being updated would be more confusing, however, and I don't think it would be easy to make certain things update while others not, and making anything update would probably be hard on the server. Thanks. demize (t · c) 19:11, 20 February 2011 (UTC)

DEFAULTSORT sort keys and talk pages

The {{DEFAULTSORT:}} magic word sets a WP:SORTKEY. This affects only the category sorting for the page upon which it is placed, and not that of the associated talk page (see, for example, the cats of Charles Burrell & Sons, where the page is sorted under B, and of Talk:Charles Burrell & Sons, which is sorted under C), so I know that the sort key is definitely not inherited by the talk page. Is this non-inheritance (a) a MediaWiki limitation; (b) a deliberate omission for performance reasons; (c) a bug that can be fixed or (d) a feature which it's possible to implement? If it were possible it would do away with the need for (virtually?) every WikiProject banner template to provide a |listas= parameter. --Redrose64 (talk) 20:51, 19 February 2011 (UTC) amended Redrose64 (talk) 21:07, 19 February 2011 (UTC)

I think (d) is correct, but it may be hard to do it or do it efficiently, so (a) and (b) might be on the right track too. I think you should try filing a bugzilla request and see where it goes. Svick (talk) 21:20, 19 February 2011 (UTC)
bugzilla:27596 raised. This was my first Bugzilla ticket, so I hope I've done it correctly. --Redrose64 (talk) 21:29, 20 February 2011 (UTC)

IP user subpages?

A discussion at WP:AN has made me wonder: is it possible for IPs' userspace to have subpages? I've never seen an IP with a userpage (presumably because they can't create pages in userspace?), let alone subpages thereof or talk subpages. I'd like to try creating one, but I don't feel like testing live pages if someone already knows the answer. Nyttend (talk) 04:29, 20 February 2011 (UTC)

There should be no reason why not. I admit I've never seen an archive of an IP's talk page either, but there are some highly active users with static IP's, so either they're deleting their old talk page content manually or they're out there somewhere. —Soap— 12:50, 20 February 2011 (UTC)
IP's can have both user pages (must be created by an account) and talk archives. See for example User:87.58.61.162 and User talk:74.178.230.17/Archive. I haven't seen non-talk user subpages for IP's but they must be possible. PrimeHunter (talk) 13:40, 20 February 2011 (UTC)
Indeed such pages do exist. There is 1504 subpages of User or User talk pages of anonymous users (the parent page itself doesn't exist oftentimes). Examples include User:110.175.42.35/Shannon is totally cool, User:130.216.172.138/Republican Movement in New Zealand and User talk:116.14.26.124/Polychora. Svick (talk) 15:03, 20 February 2011 (UTC)
Note that userpages for IP users are rather less useful than userpages for registered users, as the interface normally links to the contributions page for the IP instead of to the (usually non-existent) userpage. Anomie⚔ 15:22, 20 February 2011 (UTC)
It appears that both user pages and user subpages need to be created by a registered user. Once they exist, IPs can edit them, unless the pages are semiprotected. To verify this, log out and notice which pages present you with 'View source' tabs rather than 'Edit' tabs. Sometimes you will get 'Unauthorized' when trying to start a page with an IP. These experiments don't require making actual edits with an IP. EdJohnston (talk) 20:17, 20 February 2011 (UTC)
No, I edit alot under an IP and I can't! Not even a vector.js! --173.49.140.141 (talk) 20:31, 20 February 2011 (UTC)
Per Special:ListGroupRights, Everyone (Including IPs) can create talk pages - "All: Create discussion pages (createtalk)" However, only Users (i.e., registered accounts) can do otherwise - "Users: Create pages (which are not discussion pages) (createpage)" Hope that helps.Avicennasis @ 21:44, 16 Adar I 5771 / 20 February 2011 (UTC)

A couple of days ago, my links stopped being underlined, which is making editing more awkward. My preferences say always underline links. It's only happening on Wikipedia, it's with all browsers, and it's only on Monobook. Does anyone know what might be causing it? SlimVirgin TALK|CONTRIBS 12:18, 20 February 2011 (UTC)

#Links_aren.27t_being_underlined. Please remember to search the page before you post new questions. —TheDJ (talk • contribs) 12:28, 20 February 2011 (UTC)
Will copy my comment there, sorry. SlimVirgin TALK|CONTRIBS 17:59, 20 February 2011 (UTC)

Wierd clash of monoboo/vector and loos of java scripts

I'm using Google Chrome (latest version) and Monobook. The background just turned white (in every namespace) and I've lost every single one of my java scripts (from big things like Twinkle and popups to some much smaller ones). HJ Mitchell | Penny for your thoughts? 20:28, 20 February 2011 (UTC)

Oh, it's back now, but that was very weird. HJ Mitchell | Penny for your thoughts? 20:28, 20 February 2011 (UTC)
Same with me when I was logged in. --173.49.140.141 (talk) 20:30, 20 February 2011 (UTC)

Very strange behavior

Blood+ is the only page where I have see this and only when I am logged out. There are no tabs at the top and no sidebar. I use Mozilla Firefox 3.6 and Google Chrome 9.0. Has anyone else encountered this? – Allen4names 22:21, 20 February 2011 (UTC)

Looks fine to me logged out on Safari 5.3, Chrome 9.0, and Firefox 3.6.13 on Mac OS X 10.5.8. When you load the page, do the sidebar and tabs show for a moment before disappearing? Ucucha 22:31, 20 February 2011 (UTC)
It seems to have been fixed (using Chrome) but I will check again using firefox after I log out. – Allen4names 22:37, 20 February 2011 (UTC)
I logged out and nothing seems wrong now. Very strange. – Allen4names 22:39, 20 February 2011 (UTC)

Page background colors not working with Vector

I had just learned how to change my page background so that I can tell when I'm logged in/out, but a couple days back I realized everything has reverted to white. Even when I change the hexacode in my vector.css page, I can't get the colors to show up in the preview--whereas it could do that last week. This is a problem on every computer I've used and it doesn't matter which browser. help! Aristophanes68 (talk) 01:16, 21 February 2011 (UTC)

Some CSS has changed that requires some more specific CSS declaration on your part. I've fixed it in your vector.css. (BTW. It seems yo have the whole of common.css copied in your vector.css; this is generally not needed, and there is a lot of deprecated code in there. You only need to put any changed CSS in your vercotr.css.) — Edokter (talk) — 01:51, 21 February 2011 (UTC)

something wrong with this page

http://wiki.riteme.site/wiki/Mikhail_Bulgakov —Preceding unsigned comment added by 173.183.64.225 (talk) 01:19, 21 February 2011 (UTC)

What's the problem? Nothing on that page strikes me as particularly odd. Reach Out to the Truth 01:24, 21 February 2011 (UTC)
Ditto - anything more specific? Skier Dude (talk) 03:54, 21 February 2011 (UTC)

See above. I've force-refreshed, I've gone into my preferences and set from 'Always' to 'Never' and back again, and still links aren't being underlined. --Golbez (talk) 14:31, 16 February 2011 (UTC)

They underline fine for me. Have you checked your browser settings? — Edokter (talk) — 14:34, 16 February 2011 (UTC)
Broken for me since the upgrade too. Not a browser issue. tedder (talk) 14:42, 16 February 2011 (UTC)
Me as well. I haven't changed a thing considering it happened sometime while I slept. ♫ Melodia Chaconne ♫ (talk) 14:45, 16 February 2011 (UTC)
What browser are you using? — Edokter (talk) — 14:57, 16 February 2011 (UTC)
Firefox 3.6.13. No browser settings were changed between yesterday and today. --Golbez (talk) 15:00, 16 February 2011 (UTC)
3.6.13 here too. I fired up Chrome and it's broken there too. tedder (talk) 15:02, 16 February 2011 (UTC)
I have FF 3.6.13 as well. But IE Tab also doesn't underline them. ♫ Melodia Chaconne ♫ (talk) 15:01, 16 February 2011 (UTC)
What skin are you guys using ? —TheDJ (talk • contribs) 16:26, 16 February 2011 (UTC)
MonoBook. tedder (talk) 16:31, 16 February 2011 (UTC)
Same for me, no underlining under Firefox or IE 8.0 using the MonoBook skin. Beyond My Ken (talk) 17:48, 16 February 2011 (UTC)
Same here, I'm on Minefield (Firefox 4 pre-release) and Monobook. -- King of ♥ ♦ ♣ ♠ 18:21, 16 February 2011 (UTC)
Same for me, on Monobook and no underlining on both Opera 11.01 and Chrome 9.0.597.98. Nate • (chatter) 21:28, 16 February 2011 (UTC)
Filed as bugzilla:27468. —TheDJ (talk • contribs) 20:35, 16 February 2011 (UTC)
This is still a problem (I dunno how much who's changing what, granted), and honestly it gives me a headache. ♫ Melodia Chaconne ♫ (talk) 14:37, 17 February 2011 (UTC)
Since it's only a visual bug, it will get low priority from people. We can fix this in two weeks if we have to, more important broken things require attention atm. —TheDJ (talk • contribs) 19:42, 17 February 2011 (UTC)
Low priority? Huh. Some people won't edit Wikipedia until you bother to fix it. --Ghirla-трёп- 21:11, 17 February 2011 (UTC)
Meanwhile, plenty of other people will. No need to take it personally, but minor interface issues (on the no-longer-default skin) are just lower on the priority list than some of the other upgade-related issues. That doesn't mean that the people having the issues are lower priority, just that fixing underlined links isn't the most important thing. In the meantime, I'd think tweaking your monobook.css page would fix it. (yes, it's not the best long-term solution, but it'll work in a pinch) EVula // talk // ☯ // 21:17, 17 February 2011 (UTC)

For the moment you can add a { text-decoration:underline !important; } to your monobook.js (or inject the same using appendCSS or GM_addStyle). ―cobaltcigs 21:47, 17 February 2011 (UTC)

Doesn't seem to fix it. ♫ Melodia Chaconne ♫ (talk) 23:08, 17 February 2011 (UTC)
I meant .css, oops. ―cobaltcigs 00:30, 18 February 2011 (UTC)

Oh I see what you did. You need the “a” in front as it represents the tag-name of the links, to wit: 

a { text-decoration:underline !important; }

―cobaltcigs 00:33, 18 February 2011 (UTC)

Thanks very much for that work-around. I certainly understand why the developers would downgrad the problem in favor of other, more pressing fixes, but it was surprisingly difficult to edit without the underlines! Beyond My Ken (talk) 01:01, 18 February 2011 (UTC)
Yes, THIS seems to work. Thanks. ♫ Melodia Chaconne ♫ (talk) 01:12, 18 February 2011 (UTC)
Thank you! Sorry, I'm one of those who is still stubbornly stuck in 2006 and need the woobie that is underlining. Nate • (chatter) 10:16, 18 February 2011 (UTC)
Adding a { text-decoration:underline !important; } made no difference for me. SlimVirgin TALK|CONTRIBS 18:05, 20 February 2011 (UTC)
Ah, to .css, yes it did. Thank god, links are back! It's quite hard to edit without them. SlimVirgin TALK|CONTRIBS 18:07, 20 February 2011 (UTC)
But now my font in edit mode and preview has changed. :( SlimVirgin TALK|CONTRIBS 20:29, 20 February 2011 (UTC)
Hey Slim, see section below #Edit box font forced to Courier. 68.69.54.2 (talk) 18:00, 21 February 2011 (UTC)

Incidentally, has anyone said what the big benefit we're getting from this software upgrade is, that justified the multiplicity of problems created? Is this an upgrade for the sake of an opgrade, or what? Beyond My Ken (talk) 11:01, 18 February 2011 (UTC)

Yes developers spend a couple of hundred thousand hours of their collective time because they are plain bored and ponder whole days about how to mess up your life with a little missing line. The links have been posted a couple of times on this page and many other places, I'm all out of silver platters though, so please go look for them yourself. —TheDJ (talk • contribs) 11:06, 18 February 2011 (UTC)
Dude, I understand that you're getting frustrated, but seriously, you're coming across as a total dick at times. Comments like that don't help anything. EVula // talk // ☯ // 21:43, 18 February 2011 (UTC)
I know. I just get tired of answering the same question over and over and people demanding to be informed while they don't invest time to inform themselves by following the channels that are provided for informing them. It's not OK of me though, I should know better. Luckily the software switch will soon be over, and I can descend from my developer role back to my reader role and comment from afar, how editors haven't yet finished writing their articles before putting them online, that they haven't had their prose reviewed by an expert yet, that there are lots of errors, 'destroying' peoples lives, that there are many missing articles and that 'the editors' aren't correcting those problems soon enough. </trying to communicate my frustration to a domain the average editor might understand> —TheDJ (talk • contribs) 23:43, 18 February 2011 (UTC)
I certainly sympathise with TheDJ's frustration, and I think he makes an excellent analogy to justify it. A lot of people here are not accepting of the fact that MediaWiki is a volunteer-led free-content project just like the English Wikipedia, and that its volunteers deserve to be treated exactly the same way for its inadequacies as editors here are. There is no fundamental difference between a bug in a MW module which has not yet been fixed, and a factual error on an enwiki article which has not yet been corrected. My additional point would be that the MediaWiki world does not revolve around enwiki, that while it might be the patriarch of MediaWiki instances, it is not special. The MediaWiki developers are playing to a much wider audience with this update than the watchers of this village pump; enwiki is to MediaWiki as an enwiki reader is to this project. Editors of this project are appreciative of polite and constructive comments on where the project warrants improvement, and encourage such points to be raised in appropriate forums; editors often jump straight to correcting such issues when it is simple for them to do so. Enwiki editors are not appreciative of aggressive denigrations of the work the project has already done; they do not tolerate rudeness directed at the good-faith actions of its contributors; and while agreeing that the project is imperfect and incomplete, they do not accept that the world will end as a result of those imperfections not being immediately rectified. Do not treat MediaWiki developers as enwiki's playthings, treat them as established members of an entirely separate free-content project with related but entirely separate goals to enwiki. Treating them in the same way as you treat Commons editors would be a good way of thinking about it. Happy‑melon 14:04, 20 February 2011 (UTC)
Hang on, though, HM, when an article is messed up, it affects only that article. I've spent hours trying to work out what happened to the underlining. I updated my browser, checked other browsers, sat staring at preferences, asked friends for help, etc etc. It's a minor thing, I know, but it's a time-consuming minor thing, and multiply those hours by the large number of editors who did it, and are probably still doing it, unaware of this thread. So some understanding on both sides would be good. SlimVirgin TALK|CONTRIBS 20:34, 20 February 2011 (UTC)
Indeed, it might have been a significant disruption to you, a minor thing which is nonetheless disproportionately inconvenient and problematic. In much the same way that a factual error in an article can be disproportionately damaging to those who read it and mistakenly believe it. No one is denying that issues like these are problematic and need to be fixed in the fullness of time. But while no one denies that the issues tracked by CAT:B are problematic and need to be fixed in the fullness of time, there is a recognition that enwiki editors are only human and that it is not reasonable to expect either all errors, or errors which affect a given reader, to be fixed immediately.
Enwiki's audience is its readership, a small fraction of which will have been negatively affected by any given imperfection in the project. MediaWiki's 'audience' are individual wikis, the 850 Wikimedia wikis, the 165 thousand Wikia wikis, Citizendium, Uncyclopedia, the UN Development Program wiki, countless known and unknown private wikis, public wikis, documentation wikis, internal company wikis, and so on. There are many more active wiki installations, each with its own community large or small, than there are active editors across all Wikimedia projects. That's the understanding, the sense of perspective, which some people are lacking. The developers are extremely sympathetic to the issues you identify with the new software; indeed identifying and fixing them is the purpose of the MediaWiki project. All you need to do is present such issues politely and clearly, much as a enwiki reader would point out a flaw in an article, or you as an enwiki editor would point out a flaw on Commons or another project. Happy‑melon 10:47, 21 February 2011 (UTC)
And then wait for the requisite number of years or decades until someone possibly gets round to addressing your issue... --Kotniski (talk) 14:15, 21 February 2011 (UTC)
HM, I've never managed to get a response from a developer about a technical problem; at least not from someone who I know to be a developer. Perhaps as they are reading this: the other thing that happened yesterday is that my font changed in edit mode, and I can't seem to fix it. Is that also connected to the recent changes? SlimVirgin TALK|CONTRIBS 02:08, 22 February 2011 (UTC)

[Copying this from below, as I didn't see this thread}

A couple of days ago, my links stopped being underlined, which is making editing more awkward. My preferences say always underline links. It's only happening on Wikipedia, it's with all browsers, and it's only on Monobook. Does anyone know what might be causing it? SlimVirgin TALK|CONTRIBS 12:18, 20 February 2011 (UTC)

Fix

I've found the cause for this problem, and a fix, review and deploy are awaiting, but I think we should see this fixed no later than monday evening european time. —TheDJ (talk • contribs) 16:44, 20 February 2011 (UTC)

Fix deployed. —TheDJ (talk • contribs) 21:02, 20 February 2011 (UTC)
Thanks a lot - I can properly see links again in both en: and cs:. :-) --Miaow Miaow (talk) 15:35, 21 February 2011 (UTC)

The new edit box

...sucks. How can I change it back? Ten Pound Hammer, his otters and a clue-bat • (Otters want attention) 20:56, 16 February 2011 (UTC)

Agreed. Why does it take huge amounts of consensus to activate even the tiniest useful features, yet all these garbage front-end visual changes are shoved down our throats with asking? Change the vertical linespacing to the same as the regular edit window and get the vector-style tool bar out of monobook. - ʄɭoʏɗiaɲ τ ¢ 21:00, 16 February 2011 (UTC)
See Wikipedia:Village pump (technical)/Archive 131#Editing above. -- Whpq (talk) 21:09, 16 February 2011 (UTC)
(e/c)Because errors are made and not everything can be fixed after an error. See comments by catrope in #Editing. And for the last FREAKING TIME assuming some god damn good faith on part of the developers. OR F'ing leave. —TheDJ (talk • contribs) 21:10, 16 February 2011 (UTC)
I mean it by the way, I have totally had it with people complaining about the work that the developers are doing. I've warned some of these people multiple times on this page, I can't believe I would have to go towards throwing official warnings on talk pages and entering the process towards a block of a user, don't make me go that way. You people should know better. —TheDJ (talk • contribs) 21:14, 16 February 2011 (UTC)
By all means, and lose your privileges for making a shitty decision based on your emotional reaction to the situation. I have every right to complain and assert that no consensus was attained to make such changes. I have every right to assert that the new appearance looks shitty in my eyes. Please, start blocking users by this reasoning so we can open an WP:RFC/U and you can become a regular user. Developers act on a job that is given to them. Who told the developers to do this? That's who I am criticizing, not the developers that merely programmed the code as they were instructed to. - ʄɭoʏɗiaɲ τ ¢ 22:19, 16 February 2011 (UTC)
And don't vandalize my talk page either, TheDJ. Disagreeing with others opinion is not assuming bad faith. Nobody has to like what the developers make. We aren't obligated to applaud what they put out. Just as you placed a warning on my page, I have now placed one on yours; both are equally unwarranted. - ʄɭoʏɗiaɲ τ ¢ 01:50, 17 February 2011 (UTC)
If we required consensus for each and every little thing (including wiping one's butt), then nothing new would ever get implemented due to the fact that some people just don't like change, period. –MuZemike 21:13, 16 February 2011 (UTC)
And that's why reftools still isn't turned on by default, despite actual consensus? You're right, people don't like change. The correct action to such a situation is to give users the option of "upgrading" to the new appearance. - ʄɭoʏɗiaɲ τ ¢ 22:19, 16 February 2011 (UTC)
The reason RefTools have not been turned on is that we were waiting for the 1.17 rollout to happen to enable it. But don't let the facts get in the way of a good rant. Titoxd(?!? - cool stuff) 01:59, 17 February 2011 (UTC)
I think the point is that this change is seen as an attempt to "Vectorize" the monobook style. It seems bizarre why this change would be made in the first place. At the very least, these types of changes should be opt-in, not opt-out. SnottyWong confer 21:15, 16 February 2011 (UTC)
Read !!!!!. —TheDJ (talk • contribs) 21:20, 16 February 2011 (UTC)
DJ, I know this is stressful on your end, and the unnamed developers. Sometimes, unless somebody like you puts that directive about "Read!!!", it's not always easy to find on this page who is saying what that impacts one's particular case. And sometimes...the issue is not about this upgrade, but it just seems to be. So, thanks to the developers and what they are trying to accomplish. Hope it gets better for us all.Maile66 (talk) 21:42, 16 February 2011 (UTC)

FWIW - I was dismayed to find the new toolbar when I logged in; but found what I needed here to unclick the button I had set in my preferences & it's back. So, no big deal, really. As long as we can get back the toolbar we're used to seeing, life is good. Truthkeeper88 (talk) 22:25, 16 February 2011 (UTC)

I totally agree. Thanks to the other users who helped me retrieve my sanity by actually making the effort to explain what to do to get it working properly again. I am, however, concerned about the hundreds of users who must be having the same experience and the same difficulty in tracking down a sensible answer. Deb (talk) 08:23, 17 February 2011 (UTC)
Yeah, it seems really bizzare that they would enable this for everyone again. Surely the only people who had it disabled in the first place are the people who want it disabled? --Dorsal Axe 21:24, 17 February 2011 (UTC)
If you would read the other section linked by TheDJ above, you'd see this was an accident affecting about 15% of the users who had turned off the new toolbar, and it happened because I was totally wrong about the cause of a bug I was trying to fix. We change the default value of a preference sometimes (affecting all users who had set the preference to the old default), but I don't think we would ever change the preferences of users who consciously opted out of a feature that some people seem to hate with a passion; we're not evil, you know ;) --Catrope (talk) 22:57, 17 February 2011 (UTC)
Ah, good to know. Both the cause, and the evil thing. :p Thanks for having the patience to put up with us unruly masses. --Dorsal Axe 21:30, 21 February 2011 (UTC)

SVG not rendering

Resolved
 – U+003F? 16:08, 21 February 2011 (UTC)

no longer displays for me on any of the (many) pages that use it. I'm running firefox (3.6.13). Any ideas what's happening? U+003F? 10:42, 17 February 2011 (UTC)

I think I've seen it mentioned somewhere that Mediawiki 1.17 is more picky about SVG namespace declarations than 1.16. So maybe that's the problem? --Morn (talk) 11:52, 17 February 2011 (UTC)
I've fixed it. The issue was that the SVG tags used <svg:something> instead of just <something>. --Morn (talk) 12:59, 17 February 2011 (UTC)
Could you fix Commons:File:Current event template.svg as well? — Edokter (talk) — 13:22, 17 February 2011 (UTC)

Remark: what a shame that mediawiki decided to discard all the changes prior to yours today, Morn. Check it out: commons:File:Soccerball current event.svg#filehistory Magog the Ogre (talk) 13:53, 17 February 2011 (UTC)

All old versions are still there; MediaWiki just refuses to render them. — Edokter (talk) — 13:42, 17 February 2011 (UTC)

Oh, right, invalid SVG. Duh. Magog the Ogre (talk) 13:53, 17 February 2011 (UTC)

Uh oh, quite a few other icons are broken too: http://commons.wikimedia.org/wiki/Time-related_icons#Sports Not good. This whole 1.17 upgrade is really an epic fail so far. --Morn (talk) 14:03, 17 February 2011 (UTC)
You don't have to fix the svg:svg case. That is actually a bug in the parser, that i have already fixed and that simply needs to be deployed yet. The cases of missing xmlns namespaces are a problem (these svgs will display an error in you open them in safari). Look in my Commons contribution history to see how to fix cases like that. A texteditor and some googling will do the trick. —TheDJ (talk • contribs) 14:50, 17 February 2011 (UTC)

Weird grey bar

I suddenly seem to have this weird grey bar appearing at the top of every page. It's pretty annoying. Just wondering if it's related to anything that's been changed recently? Or perhaps caused by a moment of dumb on my end? --Dorsal Axe 21:13, 17 February 2011 (UTC)

Could that be another Monobook problem? I use Vector and can't see what you mean. Jared Preston (talk) 21:18, 17 February 2011 (UTC)
Well that's the one. Can't seem to get rid of it though. Appears in both Monobook and Vector too.--Dorsal Axe 21:33, 17 February 2011 (UTC)
But the solution there is to use some JS code. Since JS code is now at the bottom of the pages (whatever that means, I'm not tech-savvy enough to comprehend), then that grey bar will always load before vanishing again – like the watchlist banners. I'm not sitting in the same boat as Dorsal Axe, but can imagine that must be quite annoying and at the very least a major distraction. What is causing the grey bar exactly? Jared Preston (talk) 21:38, 17 February 2011 (UTC)
Right, both this and the amazing swerving logo have shown up on my Monobook in the last two days. Presumably the same is true for everyone who uses Monobook? Shouldn't this be fixed by whoever made the changes to the code in the last two days? All Hallow's Wraith (talk) 21:40, 17 February 2011 (UTC)
I've never seen that grey bar and I've been using Monobook for years now. Gary King (talk · scripts) 21:55, 17 February 2011 (UTC)
Allright, the grey bar has vanished, at least on my monobook. The swerving logo is still here, though. Any chance it'll disappear too? All Hallow's Wraith (talk) 22:27, 17 February 2011 (UTC)
The grey bar has also vanished for me too now. Very strange.--Dorsal Axe 22:37, 17 February 2011 (UTC)
Dorsal, are you having problems with your logo? Is it starting out a bit to the left and then moving to the right a few seconds later? (the Wikipedia logo) All Hallow's Wraith (talk) 22:44, 17 February 2011 (UTC)
Can't say I've noticed the logo thing. :/ --Dorsal Axe 21:32, 21 February 2011 (UTC)
So, that's it, is it - the logo thing is permanent? Or what? Who is it that keeps making these brilliant changes that make everything slower and then doesn't stick around to explain them? All Hallow's Wraith (talk) 07:49, 18 February 2011 (UTC)

Question marks appended to redlinks?

It seems that redlinks now have a question mark appended to the end of them by default. Why was this done? Adding punctuation to a link creates confusion and ambiguity in articles. For instance, consider how silly these sentences with redlinks look:

  • In 1960, the internet was invented by Al Gorbechev. He asked, "What is the purpose of all these redlinks?"

Did someone decide that coloring the links bright red wasn't sufficient to identify a link with no destination? Again, these types of changes should be opt-in, not opt-out, although I don't even see an option to opt-out of it. I'm sure there is probably some custom CSS that you could append to your monobook.css, but that's not the point. The average casual reader here will almost certainly be confused by these question marks, and they will certainly not be interested in looking at css code. Was this change discussed somewhere? SnottyWong confer 22:11, 17 February 2011 (UTC)

Perhaps it's a bug from the upgrade and you need to clear your cache? I see no question marks after redlinks, and I checked both logged in (using my custom CSS and Monobook skin) and logged out (Using "normal reader" CSS and Vector skin.) Avicennasis @ 22:40, 13 Adar I 5771 / 17 February 2011 (UTC)
Ditto, I'm not seeing that, either. There's a user preference that makes redlinks appear as plain text with a question mark (found on the "Appearance" pane under "Advanced options"), but I don't think I've ever see what you're describing.--Fyre2387 (talk • contribs) 22:49, 17 February 2011 (UTC)
Hmm. Well, if I use Firefox the question marks go away. But I can't get them to go away in Chrome, even after clearing the cache and following all instructions at WP:BYPASS. Using Chrome 9.0.597.98. What I see is the entire word is red, and there is a red question mark appended to the end of the word. The whole thing (word + question mark) is the hyperlink. SnottyWong comment 23:06, 17 February 2011 (UTC)
I would try opening an incognito window and look at a page with redlinks. You'll be logged out in that window, and there will be no cache or anything else to interfere, due to how incognito works. If you don't see question marks in that window, stay on the page and log in, and see if they come back. Avicennasis @ 23:10, 13 Adar I 5771 / 17 February 2011 (UTC)
Opened incognito window, question marks were gone. Logged in while still incognito, question marks came back. In my prefs, I'm using monobook and I have the "Format links to non-existent pages like this (alternative: like this?)" option un-checked. Any ideas? SnottyWong squeal 00:44, 18 February 2011 (UTC)
I checked in my prefs (also monobook) and I had that box checked. When I un-checked it, I saw the question mark after the redlink, as part of the link. Re-checking it returned them to normal (without the question mark.) So, I would actually put a check in that box, and see what they look like. (May have to bypass cache blah blah blah.) Avicennasis @ 00:50, 14 Adar I 5771 / 18 February 2011 (UTC)
Yep, the box has to be checked. Jared Preston (talk) 01:03, 18 February 2011 (UTC)
Ok, that seemed to work. That was weird. Before I checked the checkbox, it was reading: "Format links to non-existent pages like this? (alternative: like this?)", which is why I didn't check it originally. However, after checking the checkbox, now it reads correctly: ""Format links to non-existent pages like this (alternative: like this?)". Anyway, problem solved. Thanks for the help! SnottyWong spout 15:29, 18 February 2011 (UTC)
It's supposed to be checked if you want red links to be red. That's the intended behaviour. The "alternative" is what you get if you don't check the box. Both have to be shown for the user to make an informed decision. Since that preference is selected via checkbox option, both link styles are shown to the user as part of the same label. I wonder if that preference can be changed to use radio buttons, so that the two styles are displayed separately from each other. I'll try poking at Preferences.php and see what I can do. Reach Out to the Truth 00:04, 21 February 2011 (UTC)
Oh yeah, and after setting it I see that it does look different in the preferences. I imagine people generally set it and forget it, or after realizing the effect it has they rush back to their preferences and click the box again without rereading it . Reach Out to the Truth 03:11, 21 February 2011 (UTC)
Broken link formatting options presented with radio buttons

Okay, I messed around with Preferences.php and managed to make this. It uses radio buttons instead of a checkbox. Does this look better? Reach Out to the Truth 03:11, 21 February 2011 (UTC)

Perhaps we should just kill that option? It's from the 2001-2004 days, it's highly confusing for people and probably just a super small amount of people are using it. —TheDJ (talk • contribs) 08:52, 21 February 2011 (UTC)
I think removing the option is probably the best bet. Using nonstandard formatting for wikilinks to nonexistent pages can be done with javascript if anyone actually wants to do that. Also, the standard formatting is so ingrained in everyone's consciousness anyhow that I just completely blanked out for a minute attempting to write the previous sentence without the word "redlink". — Gavia immer (talk) 09:17, 21 February 2011 (UTC)
Yeah, I'd be fine with removing it too. It's confusing and useless to most people. Those who do want it can recreate this behaviour with custom JavaScript or even CSS (:after). bug 27619 Reach Out to the Truth 03:11, 22 February 2011 (UTC)

Hello. Does anyone have some information about <gallery> since the Feb.17th update ? It is now aligned on the left and one has to add <center> everywhere, or is it temporary ? Thanks, Jack ma (talk) 06:56, 18 February 2011 (UTC)

I'm quite sure that gallery has always been left aligned. Perhaps you are confusing with one of the many gallery templates ? Someone correct me if I'm wrong. —TheDJ (talk • contribs) 08:47, 18 February 2011 (UTC)

It is implemented as a list instead of a table, which I’m pretty sure is new. More strangely it forces a white background to stretch all the way across the screen. Could someone kindly get rid of that? See screen-shot. Thanks. ―cobaltcigs 17:38, 18 February 2011 (UTC)

That is new indeed, but the alignment has not changed, which is what the question was about. I think the white background was already made transparent in trunk. commit "Took out fix for bug #27458 (“<gallery> has a white background now”) since bug conflicts with a fix for bug #26470". Ok, that even has me confused. Will look further into it tomorrow. —TheDJ (talk • contribs) 01:23, 19 February 2011 (UTC)

For the moment, could we address this locally by using ul.gallery { background-color:transparent; }? In any case making the gallery float in the center (without clumsily centering everything inside it) would require setting an arbitrary width other than the new default of 100% (which is different from the old default of 4× the cell width). ―cobaltcigs 04:05, 19 February 2011 (UTC)

As well as no longer being centered when using the <center> tag, which used to center the gallery in the available space (for instance, between the left margin and an infobox's left edge), gallery images are no longer being formatted by widths="XXpx" and heights="XXpx". This is under both FireFox and IE, with both monobook and vector skins. Beyond My Ken (talk) 21:06, 19 February 2011 (UTC)

After a little more investgation, it seems to be the "perrow" variable which is messing with the centering, and only in spaces constricted by infoboxes. Here's a sample gallery in which the image sizes have been overrridden by "widths" and "heights", but no "perrow". It centers properly the the space between the left margin and the infobox:
35 East Wacker
Alternative namesPure Oil Building
North American Life Building
Jewelers Building
General information
TypeCommercial offices
Location35 E. Wacker Drive
Chicago, Illinois
Construction started1925
Completed1927
Height
Roof159.41 m (523.0 ft)
Technical details
Floor count40
Design and construction
Architect(s)Joachim G. Giaver
Frederick P. Dinkelberg
Main contractorStarrett-Dilks Company

Here's the same gallery, with the "perrow" set to 3. It no longer centers in the space:

Both galleries center properly when there's no infobox:

I hope this helps to locate the problem. Beyond My Ken (talk) 21:34, 19 February 2011 (UTC)

Things fall apart, the <center> cannot hold. It does not noticeably center the gallery as a whole because the gallery now has 100% width unless otherwise specified. This is clearly evidenced by the long white banner seen above and in bugzilla:27458. Whilst deprecated the <center> element does center the individual cells within this horizontal space, with the caveat that a trailing partial row will be centered differently. It also centers the text in the image thumbnails, which is surely undesirable. To center a gallery as if it were a table I suppose you’d need to constrain the width to roughly 162px times the desired number of photos per row.

No really, don’t do this

Choosing what how many cells per row would be appropriate requires guessing screen-size and is therefore a fool’s game. I’m pretty sure the entire point of abandoning tables/cells is to make the thumbnails wrap along to subsequent rows much like plain text (within whatever horizontal space is available rather than forming a strict grid based on a poor estimate). Thus I advise against using the above code and defeating that purpose. ―cobaltcigs 21:32, 19 February 2011 (UTC)

Since we posted at virtually the same time, could you re-jigger your explanation with reference to the samples I gave above? Beyond My Ken (talk) 21:38, 19 February 2011 (UTC)

Hmm, upon further observation I see the max-width property is exactly how the perrow pseudo-attribute is implemented. Get the firebug extension and you’ll see what I mean [4]. The other thing I noticed is that using perrow causes a noticeable over-estimation of the required width (for the specified number of cells at the specified size). Normally one would be able to fine-tune this, except that existing CSS properties are discarded completely, see:

collapsed again for readability 
Using: <gallery perrow="4" style="max-width:648px; margin:auto; background:green; border:1px solid orange; text-decoration:blink; font-size:200%;">

The resulting style attribute is malformed, too wide, and missing the desired properties: 

<ul class="gallery" style="max-width: 680px;_width: 680px;">

Is there a bugzilla ticket for this? ―cobaltcigs 22:01, 19 February 2011 (UTC)

Let's see.
  1. It's intentional that the gallery is now free flow in width. That this may affect rendering is logical and expected. Free flow full width galleries have been one of the longer standing feature requests that is now finally implemented.
  2. <center> is deprecated HTML and we should avoid using it (HTML5 doesn't even support it anymore).
  3. <gallery> has never supported a style= argument. Note that it is a wikicode extension, not HTML. It could, but no one has implemented that so far. Might be something to file a bugzilla ticket about.
  4. Due to the new full width, the caption is now not properly aligned at times bugzilla:27540
  5. the malformedness of the perrow css is intentional in order to support browsers (mostly IE) that don't have max-width support.
  6. the perrow width is indeed overestimated for some reason. bugzilla:27577.
—TheDJ (talk • contribs) 01:12, 20 February 2011 (UTC)
  1. Good.
  2. Yes, I already remove it wherever I find it.
  3. <gallery> appears to support style attributes without unexpected tampering in other cases (as long as perrow is not used), see below:
  4. Not sure what you mean, but ok.
  5. Tsk, tsk, tsk.
  6. Thanks.

Gallery style example: 

<gallery style="background-color:lightgreen; border:3px solid black; text-decoration:blink;">
<ul style="background-color: lightgreen; border: 3px solid black; text-decoration: blink;" class="gallery">

―cobaltcigs 11:41, 20 February 2011 (UTC)

Ah, now I understand. Fixed in r82538 —TheDJ (talk • contribs) 21:32, 20 February 2011 (UTC)
Fix for the broken styles on perrow now deployed. —TheDJ (talk • contribs) 21:54, 21 February 2011 (UTC)

How are code updates scheduled?

This MediaWiki code patch applies HREFLANG to links to other-language Wikipedias. How can I tell when, or whether, it will be applied here? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:41, 19 February 2011 (UTC)

It's live right now in the 1.17wmf1 branch, which all Wikimedia projects are currently running. Reach Out to the Truth 20:53, 19 February 2011 (UTC)
How come I don't find the string "hreflang" anywhere in the source of pages with such links, then? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:21, 19 February 2011 (UTC)
You can see that particular change in action on zh: for instance. If you look at the source of pages there, you will see that there are now link elements for the different variants, that carry the hreflang string. That is all that that patch changed. —TheDJ (talk • contribs) 00:46, 20 February 2011 (UTC)
Thank you; but by here, I mean en.wikipeida. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:19, 20 February 2011 (UTC)
The English wikipedia doesn't have any language variants to link to, so you wouldn't expect to see any change here. Are you sure you understand what that revision is supposed to change? Happy‑melon 11:47, 20 February 2011 (UTC)
To clarify "This MediaWiki code patch applies HREFLANG to links to other-language Wikipedias" is incorrect, should be "it applies HREFLANG to <link> elements (not weblinks, which would be <a> elements) of other-language variants of Wikipedias". It basically makes sure that google understands that the chinese variants urls are indeed duplicate content, but not to be ignored duplicates, because they are in other userlanguages. —TheDJ (talk • contribs) 11:59, 20 February 2011 (UTC)
Apparently not, Happy-melon; though it was that change to which I was referred when I asked about adding HREFLANG and rel="alternate to one or other of two types of link. For example, the en.wikipedia article Birmingham has a link, <a href="http://de.wikipedia.org/wiki/Birmingham" title="Birmingham">Deutsch</a> to which such attributes could be applied; and could have <link rel="copyright" href="http://de.wikipedia.org/wiki/Birmingham" rel="alternate" lang="DE" hreflang="DE"</link>. Adding one or both of these would facilitate auto-detection. That said, my principle question here was "how can I tell when, or whether, [a given change] will be applied here?" Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:14, 20 February 2011 (UTC)
This is a rather long story:
  1. Almost all commits go onto trunk. Most recent commits, browse trunk.
  2. A bugticket is usually considered closed and fixed, as soon as the change is made to trunk
  3. Every commit has a number. This is just an index number. It is usually added to the ticket when the ticket is closed
  4. Every commit than has to be reviewed. For example, this recent change shows as status "new", and some (senior) developer other that the committer needs to mark the commit as "ok" or "resolved". Every developer can leave questions and observations about the change there as well.
  5. Some commits require later commits (related fixes, fragmented work, whatever). The directly related commits are listed just above the comments under Follow up revisions.
  6. Now before something goes live, it has to be moved to the current wmf branch. At the moment, the current wmf branch is 1.17wmf1 chronologically browse
  7. For this move to happen, someone (usually the original committer) adds the 1.17wmf1-tag to the original commit. The tags are listed at the top of the review page of the commit. Usually only critical bugfixes are eligible for direct deployment. Non-critical issues and new features will eventually end up in the next version (atm 1.18). At the moment the commits also often get the 1.17-tag to indicate the change should also be backported to the 1.17 branch that will at some point form the actual 1.17 release (1.17wmf1 is a prerelease of 1.17)
  8. Then one of the WMF senior developers (Usually Tim Starling, Roan Kattouw (catrope) or Trevor Parscal) will go trough the list of 1.17wmf1-tags and decide which of those commits require actual deployment to WMF sites. They do this on their own schedule, whenever they see it fit or are able. They do a second review to determine immediacy, importance, and affect of the commit. If they are unsure of the performance of something for instance, they might skip one of the items in the list and take care of it at a later time.
  9. Eventually at some arbitrary time, they either OK the change for WMF, or they deny the change. When they deny, they just remove the 1.17wmf1-tag from the review page. If they approve, they also commit the change to the 1.17wmf1 branch. The change then gets a new commit number.
  10. This new commit number usually will show up in the original commit as a "Follow up revision", below the Diffs, and above the comments of the review page. It usually has the following format: 'branch where was moved to: MFT (moved from trunk), revisions number(s) that were moved'.
  11. This new commit then needs to be deployed to the actual websites, usually done at the same time as moving the commit to the wmf branch. Often this is logged on server admin log, but not always.
  12. The Special:Version page lists the version the servers are running (again 1.17wmf1), and the last commit/revision upon that version. commit/revision numbers of different MediaWiki versions are mixed, so the 'height of the number' says nothing about wether a commit was deployed, it only indicates that something newer has been deployed, but without looking at the total record, you can't really be sure what that is.
So 'what is deployed' is a rather big puzzle, and 'when is something deployed' is 'whenever the senior WMF devs decide is appropriate, but after something has been tagged as '1.17wmf1'. Does that answer your question ? —TheDJ (talk • contribs) 19:49, 20 February 2011 (UTC)
I can't speak for Andy, but I found that explanation really helpful - how the live code is controlled has been confusing me for a while. Thanks! the wub "?!" 12:02, 21 February 2011 (UTC)

I think what you are looking for would be this bugzilla request: bugzilla:4901. —TheDJ (talk • contribs) 19:49, 20 February 2011 (UTC)

Stop adding the spaces in headers by default

First I am assuming this should go here because it may require one of the wikimedia programmers action if approved but if need be Ill move it just let me know.

I would like to propose that we stop adding spaces to the headers of content when we create them. For example whenever a new section or article is created using Wikipedia by default it ads a space between = and the wording of the title like this == Title == rather than this: ==Title==.

This makes the article look sloppy and for some editors more difficult to read. This also adds more bytes to the content and its history every time the article is saved which takes up more space on the servers. Individually 5 spaces doesn't hurt the article but multiple that by 3.5 million articles on the English Wikipedia alone and then times that by 10 saves (many articles have hundreds of saves) and you are left with several GB's of storage saved.

If this is determined to be too difficult or if it doesn't meet consensus for a widespread change as a compromise please allow the individual editor an option under preferences or as a gadget to eliminate the spaces by default if they do not want to add them. --Kumioko (talk) 14:01, 20 February 2011 (UTC)

No, just no. Read Wikipedia:Don't_worry_about_performance. Not specifically relevant, but it's on the same track. Don't even bother starting to make that change. Reedy (talk) 14:14, 20 February 2011 (UTC)
I don't see the point. The article looks the same with or without spaces inside section heading and I find the added spaces makes the subsection heading more readable in the edit window. There is no "savings" in removing the white space because the HTML will be rendered the exact same way. In fact, editing to remove the spaces creates another copy of the articles on the servers which actually "wastes" more space in the process. And finally, there is WP:PERFORMANCE, which states that we should not worry very much about the site performance, which includes any "disc storage". —Farix (t | c) 14:16, 20 February 2011 (UTC)
Also, see mw:Manual:$wgCompressRevisions. Which is enabled on all WMF wiki's (see [5]). Reedy (talk) 14:17, 20 February 2011 (UTC)
@Reedy. Yes it doesn't save much on the individual articles but as a whole it makes a difference of time. Also, this isn't just for space but for readability.
@Farix Yes it looks the same when your reading it but when you edit the article and there are spaces around everything its hard to read and messy and at least for me and some other editors so I admit that might be different for others but why should one group of editors be forced to view it the same way as the other. Can't we both have what we want? We do that everywhere else on WP. I am also not saying that we should go removing all the spaces as its own edit. What I am saying is that we should at least have the option as editors whether we want them or not. As things are now I have to manually remove them from the articles I create or maintain regularly and I think I should have the option at least when I create an article or section to remove them by default rather than be forced to do it manually. I also think that removing them along with another more significant edit should be allowed. The benefit of this change isn't just for saving space but for readability when editing. --Kumioko (talk) 14:31, 20 February 2011 (UTC)
The MOS permits both section headings with and without spaces and an ArbCom ruling prohibits changing from one excepted style to another without a substantial reason. (And I don't see any substantial reasons for removing the whitespace.) So no, you shouldn't be removing those whitespaces while making another edit to begin with. —Farix (t | c) 14:42, 20 February 2011 (UTC)
Background: Kumioko has been pushing this in various forums for a while now, and has recently had AWB access removed for making this and other trivial changes. See Wikipedia:Bots/Requests for approval/Kumioko and WP:ANI#Kumioko and AWB access for details. I'm glad to see Kumioko finally bring this up for real discussion instead of it being a side issue when he is being criticized for making all sorts of automated edits against consensus. Anomie⚔ 15:40, 20 February 2011 (UTC)
As for the proposal, I still oppose it. "Makes the article look sloppy", if we assume 'article' means 'wikitext of the article', is a matter of opinion, and the opinion that lacking the spaces makes the wikitext look sloppy is equally valid. "Makes the article [...] for some editors more difficult to read" works exactly as well as an argument against removing the spaces. If the storage for these spaces were an issue, the people whose job (paid or volunteer) it is to actually monitor that sort of thing would certainly tell us; until then we shouldn't worry and random speculation on the topic is not a convincing argument. Allowing individual editors to randomly change header spacing will just clutter diffs and annoy everyone, which is certainly not worth the reduction in a minor annoyance for a few editors. So it all comes down to keeping the status quo or forcing everyone to change because of a minority who just doesn't like it; we may as well keep the status quo and save the hassle of changing. Anomie⚔ 15:40, 20 February 2011 (UTC)
I appreciate you taking the time to comment but I wasn't making automated edits and they weren't against consensus. Just 1 editor so please don't try and diminish my credibility over 1 rogue editor who disagreed with an edit I made. --Kumioko (talk) 15:47, 20 February 2011 (UTC)
  • Oppose - I specifically make a point of doing the following when I rewrite an article, all of which have no impact on the resulting page:
    • Adding spaces between the = and the header title
    • Making citations vertically formatted with the = signs all lined up, and a blank link after the {{cite foo}}, but before the first parameter
    • Adding a blank line at the end of a section before the next header
    • Starting text following a citation template on a new line
  • This makes the edit window cleaner, far easier to read and much more organized. Regardless of the result of any discussion, I will continue to do so per WP:IAR as it is an improvement; nobody can argue that the opposing formats are easier to read and back it up with logical reasoning (unless your computer is switching whitespace to square blocks). Anyone who has meddled with wikipedia templates knows the pain. - ʄɭoʏɗiaɲ τ ¢ 16:08, 20 February 2011 (UTC)
For what its worth I completely agree with the last three points and do those myself. --Kumioko (talk) 16:14, 20 February 2011 (UTC)
@Floydian: arranging citation templates like that is fine if they are newly added, and also are added to the end of an existing paragraph. If a multi-line template is added in the middle of an existing paragraph, or an existing template which was previously laid out in-line is reformatted as multi-line, it makes diffs more difficult to read. This is because the later part of the paragraph is now on a different line, so now shows on the left as red-on-yellow removed text, and on the right as black-on-green newly-added text. It's hard to decide if that portion is the same as before or not: see this diff for example - is the sentence beginning "During the 1960s ..." the same or different? What has been added to or removed from the {{cite book}}? It's hard to tell. In fact not one thing changed in the paragraph, save for the insertion of line breaks into the {{cite book}}, so it's a complete waste of time, both for the editor who did it, and for me when I examine it carefully looking for changes. Please don't insert unnecessary line breaks, and please don't reformat templates, whether these be citation or anything else. --Redrose64 (talk) 16:46, 20 February 2011 (UTC)
I can regularly achieve the same effect by adding a new line of text to an article, or by rewriting a single sentence in the middle of a paragraph. The diff tool doesn't always work that well. Keep in mind that I'm doing this often in the process of expanding the article three to five times its current size. If you're relying on diffs at that point, you're just setting yourself up for a headache. Following this advice would also mean that if someone inserts a horizontally-formatted citation mid-paragraph in an article that otherwise has vertically-formatted citations, it would have to be left to avoid confusing someone reading the resulting diff? The community will suffer under my tyranny then, I suppose. - ʄɭoʏɗiaɲ τ ¢ 17:15, 20 February 2011 (UTC)

FWIW, I find the spaces make the edit window slightly harder to scan. But it seems to be a matter of taste, so let's not worry about it. Rd232 talk 16:55, 20 February 2011 (UTC)

It is a small thing, == are delimiters like () [] {} <> and we don't put spaces inside those. FWIW the actual usage in mainspace is 5:1 in favour of no spaces, which given that all the tools produce spaces is quite remarkable. Rich Farmbrough, 20:07, 20 February 2011 (UTC).
The lack of spaces really bugged me when I started editing years ago and I would add them if other headings with spaces already existed. Now I much prefer the look with no spaces. My theory is that people resist the no space look at first because they aren't used to seeing any other text formatted that way. However, after lots of editing, we learn that the unnatural look is a benefit because the headings jump out from the body when quickly scanning the page. WP:wikEd helps somewhat by rendering headings in bold, but body text can also be bold and I find the ==look== even more visually striking than bold. —UncleDouggie (talk) 09:24, 21 February 2011 (UTC)

PDF icon changed

Resolved
 – Redrose64 (talk) 19:14, 20 February 2011 (UTC)

It seems that the PDF icon has changed, perhaps this was MediaWiki 1.17, perhaps it wasn't, but I only noticed it today. Links ending in .pdf (whether bare, enclosed in single square brackets (such as this one) or formatted using {{cite web}}) formerly displayed with the red-and-white curly thing that we associate with Adobe. Now they show what appears to be a generic "document" icon. This is the same in IE7, Firefox 3.6, Chrome 9 and Opera 11 - the only difference that I notice is that it's grey in Vector, light blue in Monobook. --Redrose64 (talk) 16:20, 20 February 2011 (UTC)

The Adobe PDF icon is copyrighted. —TheDJ (talk • contribs) 16:36, 20 February 2011 (UTC)
Where did this come from? There were several discussions on Commons about the use of a pdf icon, each time resulting in the understanding that it's use was not infringing in any way. — Edokter (talk) — 16:51, 20 February 2011 (UTC)
{{SCOTUSLinks}} may need updating as it has a hardcoded icon. -- WOSlinker (talk) 17:24, 20 February 2011 (UTC)
The file in that template is Image:Icons-mini-file acrobat.gif which is held on commons; and commons takes a very dim view of copyright violations. It appears to be tagged as Copyrighted free use. --Redrose64 (talk) 17:30, 20 February 2011 (UTC)
"Dim view"? Commons takes copyright very serious. It's trademark that's is treated more loosely. And since trademark is outside the scope of any copyright policy, there should be no problem here. — Edokter (talk) — 18:19, 20 February 2011 (UTC)
You seem to misunderstand the phrase. From the OED: "take a dim view of" = "regard with disapproval". --Redrose64 (talk) 19:19, 20 February 2011 (UTC)
That image passed a deletion request. And it is still defined in MediaWiki:Common.css. The audio icon defined in Common.css has changed as well. ---— Gadget850 (Ed) talk 18:13, 20 February 2011 (UTC)
Icon defined in Common.css Icon now showing
http://example.org/x.ogg
http://example.org/x.pdf
That speaker icon in Common.css is for the Listen template, not for links to audio fragments. —TheDJ (talk • contribs) 18:48, 20 February 2011 (UTC)

I was mistaken, the PDF logo is actually a local change we have here on en.wp. It was broken due to higher CSS specificity of some skin elements after 1.17 and Krinkle has removed it on top of that, because he thought it was the same icon as the skin provided icon. —TheDJ (talk • contribs) 18:45, 20 February 2011 (UTC)

 Done now working again --Redrose64 (talk) 19:14, 20 February 2011 (UTC)
The css icon decleration looked much alike, since having two dozen selectors for an icon that is already defined in core is a significant ( ~ 800 bytes per page view on first hit), I removed as duplicate. However I didn't notice the icon was a different one though. Perhaps this kind of icon swapping should be done in MediaWIki core ? Although the Acrobat icon may be a problem, if it's not a problem on Commons and as icon on wmf wikis, it shouldn't be a problem in MediaWiki core and vica versa (if it is a problem, it shouldn't be on Commons either). For the record, the current icon for PDF links in MediaWiki (without the en.wikipedia override) is http://bits.wikimedia.org/skins-1.17/vector/images/document-icon.png Krinkle (talk) 15:40, 21 February 2011 (UTC)

An odd bug

An odd bug has appeared recently. When I am on some language version (like serbian, czech, polish), sometimes it is hard for me to remember/know/use all the local names their namespaces. That is why I always use these names (Wikipedia, Template, User) in English. But now, when I enter some pagename to Search window with prefix Wikipedia: instead of getting to some page, I am redirected to english Wikipedia. This cripples my work quite a lot. Is there some way how to remove this bug, or some setting how to bypass this? I know there were some difficulties because of the software update, but I think lot of these were resolved. This one, however, wasnt. Thank you. --Aktron (t|c) 18:43, 20 February 2011 (UTC)

I get the same result. You should use "Project:" instead of "Wikipedia:"—that does work. Ucucha 18:51, 20 February 2011 (UTC)
Just to explain a little, there are canonical namespace names, namespace aliases and the actual localized namespace name. names like Template:, File:, Project:, User: etc. are the canonical namespace names (as well as the localized names for the English language projects). This bug you encountered most likely was on a wiki that wasn't part of the Wikipedia family, rather a Wiktionary, Wikisource, Wikibooks etc. Over ther you can either use the canonical 'Project', '(Projectname)' (eg. Wiktionary) as alias, or the actual localized version "ויקימילון" (Hebrew Wiktionary). wikt:he:Project:Test wikt:he:Wiktionary:Test wikt:he:wikipedia:Test. Krinkle (talk) 15:50, 21 February 2011 (UTC)

What's happening?

Within the last few minutes, rendering is all screwed up. Firefox using Monobook. Article elements are all over the page. Beyond My Ken (talk) 20:24, 20 February 2011 (UTC)

I'm getting "Simple"...now monobook?! --173.49.140.141 (talk) 20:25, 20 February 2011 (UTC)
Now vector?! --173.49.140.141 (talk) 20:25, 20 February 2011 (UTC)
Now it's some weird skin? --173.49.140.141 (talk) 20:26, 20 February 2011 (UTC)
Same thing happened to me, but in the process of typing this up it appears to have resolved itself. I'd be curious to hear what happened. –Grondemar 20:27, 20 February 2011 (UTC)
Resolved for me as well. Beyond My Ken (talk) 20:29, 20 February 2011 (UTC)
Ah! Just noticed that links are underlined again in Monobook, so perhaps it was a changeover. Beyond My Ken (talk) 20:32, 20 February 2011 (UTC)
Roan deployed the underline fixes yes. Something went wrong for a sec, but quickly restored. —TheDJ (talk • contribs) 21:01, 20 February 2011 (UTC)
I'm happy to have the underlines back, my thanks to the developers for that, and I'm glad the SNAFU was so short-lived. Beyond My Ken (talk) 07:25, 21 February 2011 (UTC)

Post-rollback redirect broken

When I rollback an edit by an account with spaces in its name, I get redirected to an incorrect contribution page with plus signs instead of spaces in the username. For example, after two rollbacks on User:Ucucha/sandbox I get redirected to https://secure.wikimedia.org/wikipedia/en/wiki/Special:Contributions/Ucucha%2Btest%2Baccount. I'm not sure whether this is an error introduced by MW1.17, but I think it is. (Of course, I have the " After rolling back an edit, automatically open the contributions of the user rolled back." gadget enabled.) Ucucha 21:41, 20 February 2011 (UTC)

I found the cause and reported it at mw:MediaWiki talk:Gadget-modrollback.js. Ucucha 21:49, 20 February 2011 (UTC)
The cause isn't in Wikipedia's javascript but in the software core. It falsely puts the username in the url with a '+' where a space would normally be (whereas in the wiki-way this is encoded into an underscore). Opened bugzilla:27606 (rawurlencode, urlencode, wfUrlencode). Krinkle (talk) 15:20, 21 February 2011 (UTC)

Wikimedia prototype wiki vandalized

Hi. I'm not sure whom to contact, so if you have any idea feel free to contact the right person for me.

The page http://prototype.wikimedia.org/sandbox.4/Main_Page is being vadalized by a spam bot. Could someone protect the page or something ? Cheers, Dodoïste (talk) 23:20, 20 February 2011 (UTC)

Interesting. You have to solve a CAPTCHA when creating an account, but not when adding external links. Bad configuration. Are they hitting any other pages, or just the main page? Either way, WEST Regau is on the case. Reach Out to the Truth 01:22, 21 February 2011 (UTC)
They've been globally blocked, but as there is no SUL on that wiki, IDK if steward actions reach that. /ƒETCHCOMMS/ 05:31, 21 February 2011 (UTC)
So far only the main page is affected by this spam bot. Thanks to WEST Regau then. Cheers, Dodoïste —Preceding unsigned comment added by 83.173.207.141 (talk) 08:21, 21 February 2011 (UTC)

Pages using Template:Outdent are freezing my browser

I hope this works - I had to open this edit window by directly typing the URL because due to the nature of my problem I am unable to open a usable version of the page itself. I am using the native Android browser v2.2 on my Droid2 to view and edit Wikipedia. I have been using for a good while without having any major issues. However starting in the last day or so the browse will freeze up on any page that uses the {{outdent}} more than once. I can scroll and read the page, but the outdents themselves remain invisible and I can't navigate away from the page by any means, neither clicking on links, hitting the back button, nor typing the address bar will work. I have to go into the operating system settings and force close the browser and restart it. I was having no issues Saturday evening, but today I'm stuck. The size of the page doesn't seem to be an issue; I can navigate the larger articles and help pages, but I get stuck on the outdent template page itself. I don't think I got a recent browser or OS update, have there been any changes on the Wikipedia end? Thanks! —Elipongo (Talk contribs) 04:44, 21 February 2011 (UTC)

Yes, an upgrade to MW 1.17. I don't know if it's related or not, though. I don't know why the template would cause you problems. It only outputs text. Gary King (talk · scripts) 04:51, 21 February 2011 (UTC)
I'm still having the issue. I've redacted my statement above because I was mistaken, a single use of Outdent causes the problem. I've also tried changing to simple & monbook skin and there's no change in the problem. I discovered the problem when I made this edit adding an outdent to the discussion. I see that Outdent uses the padleft magic word, could that be the problem? —Elipongo (Talk contribs) 18:04, 21 February 2011 (UTC)
That seems unlikely, since your browser wouldn't see that magic word. Is it perhaps related to the special characters the template uses? Do you have the problem with the page User:Ucucha/sandbox? Ucucha 18:11, 21 February 2011 (UTC)
Nope, your sandbox works fine for me. —Elipongo (Talk contribs) 18:25, 21 February 2011 (UTC)

Bugs

Just want to say thanks to whever fixed most of the recent bugs. Simply south...... 10:38, 21 February 2011 (UTC)

County municipality templates should populate out the individual municipality links under "What Links Here". The last page I created where this worked correctly was Morman Mill, Burnet County, Texas on Feb 13. When I created Quihi, Texas and Estacado, Texas on Feb 19, the county municipality templates were no longer populating out the individual municipality links under "What Links Here". They should, and they haven't after waiting two days for it to occur.Maile66 (talk) 11:20, 21 February 2011 (UTC)

Probably related to the job queue—that is, you'll have to wait a little. Ucucha 15:30, 21 February 2011 (UTC)
Thanks for the answer. What is "a little" by your terms? It's been two days already, so does this mean a week or more? Maile66 (talk) 16:36, 21 February 2011 (UTC)
I'm not sure; based on my recent experience with Nelsonia, it may be as much as five days. You can also make null edits to article to clean up the whatlinkshere page. Ucucha 16:44, 21 February 2011 (UTC)
Ok, Thanks. I had already done experimental null edits with a couple of municipalities on the templates. That worked as far as making those specific municipalities show up on "What Links Here". But those experiments did not free up all the municipalities on the templates. Nor did doing null edits on the templates. Doing null edits on Estacado and Quihi did nothing at all. But thanks for some kind of answer there. Maile66 (talk) 17:00, 21 February 2011 (UTC)
Which links exactly did not show up on what Whatlinkshere page? Ucucha 17:56, 21 February 2011 (UTC)
  • For Quihi, Texas, there is this Medina County, Texas municipalities navbox at the bottom of the page. Normally, when I set up a new page and put that kind of navbox at the bottom, all the cities and communities listed in that navbox will populate out individually on "What Links Here". That didn't happen, except where I where I experimented with the null edit on the town of Castrolville.
  • For Estacado, Texas. the navbox communities that should have populated out concern these two navboxes Crosby County, Texas and Lubbock County, Texas. Those municipalities also did not populate out individually on "What Links Here". Only the individual municipalities where I experimented with a null edit populated.
    • The reason these nav boxes populate out, is because the appropriate county navbox is also on each of the municipalities listed in the navbox. As long as that is true, and it is, the individual populating of the cities and towns happens on all their "What Links Here". The only place that is missing is on Quihi and Estacado.
Maile66 (talk) 18:24, 21 February 2011 (UTC)

Null edits

As of right now, the system is not even processing null edits. It goes through the motions, but in the history page or watch list, it's as if nothing happened. Maile66 (talk) 22:54, 21 February 2011 (UTC)

Well, that's pretty much the definition of a null edit: "A null edit will not record an edit, nor make any entry in the page history or in Recent Changes, [watchlists] etc." Intelligentsium 23:58, 21 February 2011 (UTC)
Yes. I think you've found all there is to be found out about the issue: if you do a null edit on an article, it'll show up on other articles' whatlinkshere lists, and otherwise you'll have to wait for the job queue to catch up. Ucucha 00:01, 22 February 2011 (UTC)
Ah.... Maile66 (talk) 00:10, 22 February 2011 (UTC)

Problems displaying changes

Is anyone else having problems of changes being displayed following an edit since the software update? Many times after saving an edit to a page the unedited page is displayed again. Purging the page usually gets the edited page to display but sometimes it takes several purges to get the updated page to show. Keith D (talk) 19:08, 21 February 2011 (UTC)

Yes, but not exactly as you are. My issue is when I re-assess a page on the Talk page, it is supposed to instantly show up on the assessment display at the top of the main page. Since the software update, the change will not show up for hours - not until Wikipedia clicks over to a new day. Almost like magic, the minute UTC time is a new day, the changes show up. And not a minute before then.Maile66 (talk) 19:18, 21 February 2011 (UTC)

Confused about editing image description

I'm trying to add a little descriptive text to an image here: http://wiki.riteme.site/wiki/File:Rideau_Canal.jpg

But when I click into that page, I see "Create", not "Edit". I tried Create, but that's not what I want. Ideas? Maury Markowitz (talk) 22:08, 21 February 2011 (UTC)

The file is at the Commons: commons:File:Rideau Canal.jpg. Lupo 22:11, 21 February 2011 (UTC)
Ahhh! Perhaps we could have an "edit on the commons" button or such? Maury Markowitz (talk) 22:14, 21 February 2011 (UTC)
I see a gray box right under the image that tells you it's actually on commons and with a link to it there. The weirdness is how seemlessly the commons stuff passes through into the en.wp interface, confusing I bet! DMacks (talk) 22:16, 21 February 2011 (UTC)
And the Wikipedia edit notice at the edit/create page also links to the Commons page. – ukexpat (talk) 22:19, 21 February 2011 (UTC)
... unless he has non-default language set in preferences; the sure proof link to see the message is this. One could suggest a better wording at MediaWiki talk:Newarticletext. P.S. By the way, German Wikipedia changes "create" link to point to Commons with some javascript. — AlexSm 22:22, 21 February 2011 (UTC)
(edit conflict) If the image is set up properly on commons, it will have section headings, each with it's own [edit] link, which will edit the commons file not the phantom en:wp file. This image has such headings, so click the edit link to the right of the "Summary" heading. --Redrose64 (talk) 22:24, 21 February 2011 (UTC)

When undoing an edit, edit summary is not "recognized" when edit summaries are required

In my Preferences, I have enabled "Prompt me when entering a blank edit summary". If I click on "undo" on an edit, then don't modify anything and just hit "Save page", then I am told that "You have not provided an edit summary." even though the default undo edit summary is there. I can merely just hit "Save page" again on the warning page, and the edit summary appears. This appears to have begun happening since MediaWiki 1.17. Is anyone else experiencing this? Gary King (talk · scripts) 04:49, 21 February 2011 (UTC)

I normally have the switch turned off, but I turned it on to check, and undid one of the last edits, and it saved properly. (Firefox, Monoboox). Beyond My Ken (talk) 07:31, 21 February 2011 (UTC)
Okay thanks; I'll go through my scripts then. Gary King (talk · scripts) 16:08, 21 February 2011 (UTC)
Undo worked fine just now, so it was probably just a temporary glitch. Perhaps session data was lost for that moment, which sometimes, although pretty rarely, happens to me. Gary King (talk · scripts) 03:32, 22 February 2011 (UTC)
I'm not sure if it's directly related (since these tickets primarily focus on preloading summaries via the url parameter, rather than internally preloaded summaries such as those from the Undo-button), but check out bug 24295 and bug 17416. Krinkle (talk) 13:25, 22 February 2011 (UTC)

RevDel'd page history font color for admins

So it used to be that when everyone looked at a page history with deleted revisions, they would show up as grey. Now, admins see blue links that are struck. How can I get it back to just grey; it's easier to read IMO? Regular users still seem to see the grey. /ƒETCHCOMMS/ 17:34, 22 February 2011 (UTC)

Italicize part of the article title

For articles List of Case Closed manga volumes, List of Case Closed volumes (1–20), List of Case Closed volumes (21–40), List of Case Closed volumes (41–60), and List of Case Closed volumes (61–current), I want to italicize Case Closed which is at the middle of these titles. Since all the articles share the same introductory text, I made a template {{Case Closed manga introduction}}. The template successfully makes the title of List of Case Closed manga volumes become what I expected, but the titles of the other four articles doesn't change.

After some testing, I found that it is because {{str index/getchar}} doesn't contain "–" so all the string manipulation templates can't recognize the symbol. Of course given the number of involved articles is so small I can do the task manually, but I'm curious about the inclusion criteria of {{str index/getchar}} as I can't find any discussion and whether there is any alternative method to italicize only the middle part of the article title. --Quest for Truth (talk) 22:44, 22 February 2011 (UTC)

I think the issue is that the hyphen in the title is a long hyphen. You can more easily see this if cut-and-paste the URL into plain test. For instance, one of the pages then shows up as http://wiki.riteme.site/wiki/List_of_Case_Closed_volumes_(1%E2%80%9320) and the long hyphen is encoded as %E2%80%93 . --Rootover (talk) 07:36, 14 March 2011 (UTC)

Portal: namespace

Hi. We'd like to start creating portals on cy, but we're not sure how to go about it. Do we keep the Portal: namespace, or would we use the native Porth: namespace? Bencherlite suggested I ask here before commencing (discussed here). Thanks. -- Xxglennxx (talk • cont.) 00:09, 23 February 2011 (UTC)

It doesn't look like cy: actually has a portal namespace at the moment. I think you'll have to ask for one to be added at bugzilla. Ucucha 00:18, 23 February 2011 (UTC)

Impossible to save edits in Firefox.

Starting a few minutes ago, it is impossible to save edits in Firefox, so I am now using Internet Explorer. For example, if I try to click save on Ilha do Cardoso, it loads a blank page with a soft hyphen for the title and http://wiki.riteme.site/w/index.php?title=Ilha_do_Cardoso&action=submit as the URL. The same thing happens on every page on the English Wikipedia, but I can still save pages on the German Wikipedia using Firefox.— Preceding unsigned comment added by Turnnewly (talk • contribs) 01:53, 23 February 2011 (UTC)

Sockpuppet. →♠Gƒoley↔Four♣← 02:06, 23 February 2011 (UTC)

WP 1.0 bot co-maintainer wanted

I'm looking for a co-maintainer for User:WP 1.0 bot. This is the bot that tracks WikiProject article assessments. It is also closely involved with the Wikipedia:Version 1.0 Editorial Team that produces packaged DVDs of selected Wikipedia articles. The bot itself runs on the toolserver, as does the web interface that allows users to query the assessment data. It's written in PERL at the moment, but the data is stored in a proper database on the toolserver where it can be accessed by tools in any language.

What I'm looking for is someone who is interested in contributing to the WP 1.0 project or being a co-maintainer of the bot. The bot code was rewritten about a year ago, and is stable, but there are many features and improvements that could be made. I'm happy to give commit access to anyone who wants to contribute to it, and in particular I'm looking for a co-maintainer to share admin access to the bot's account. I think it's not ideal to have such a key bot dependent on a single bot operator.

This is a big project - there are over a thousand WikiProjects that rely on the bot, and the bot is one of the few that has made over 1,000,000 edits. I have always found it interesting and satisfying to work on, but it's grown enough that I think additional maintainers would be helpful. I would be happy to mentor and help new maintainers learn how the system is designed.

To avoid spamming this board too much, please feel free to respond or ask questions on my talk page if you're interested. — Carl (CBM · talk) 02:46, 23 February 2011 (UTC)

Layout problem with class "infobox bordered"

I just noticed a weird effect in the infobox generated by {{chembox}}: there is no hairline border on the right edge of it (vector, firefox-3.6.13 on WinXP). I can't say when it started, but it looked unusual enough and caught my eye quickly that it's likely a very recent change. I narrowed it down to a simple reproducible situation of a table that is class="infobox bordered" that has style="border-collapse: collapse;" (the default for this class). Using other infobox classes or setting border-collapse to a different value cures it (diff). Depending on what other things are on my interface, sometimes other edges are missing. When I had a "you have new talkpage comments" box, I think the bottom and right were missing in preview-mode while editing, whereas the top and left were missing when the page was displayed in read-mode (not 100% sure of which pairs were which, I forgot to screenshot while hacking on it). DMacks (talk) 03:58, 23 February 2011 (UTC)

Disappearing comment

I just commented at Talk:Walter Raleigh, and while the comment is shewing up in the edit history it is invisible on the page. When you open the section to edit, it's there, it just doesn't shew when you look at the page ordinarily. DuncanHill (talk) 23:06, 22 February 2011 (UTC)

Looks like the same problem I reported above Problems displaying changes. Keith D (talk) 00:12, 23 February 2011 (UTC)
Probably server lag. Does a WP:PURGE fix it? – ukexpat (talk) 14:23, 23 February 2011 (UTC)
If the same problem I reported then sometimes a purge will clear it. Keith D (talk) 22:39, 23 February 2011 (UTC)

Lead section [Edit] gadget

The gadget allowing editing of the lead section of articles is no longer functional. I know that this was working earlier today (I used it earlier!), so I'm here asking "what the hell?" did someone roll out a patch earlier today, or something? How can I get the gadget working again?
— V = IR (Talk • Contribs) 04:38, 23 February 2011 (UTC)

This edit broke it, any sysop can fix it by changing pt-br to 'pt-br' in quotes.— AlexSm 04:55, 23 February 2011 (UTC)
Facepalm Facepalm
...you know, this may actually make me apply for WP:RfA (*Raises eyebrow*)
— V = IR (Talk • Contribs) 05:04, 23 February 2011 (UTC)
Fixed. Thanks AlexSM! DMacks (talk) 05:23, 23 February 2011 (UTC)
Yes, thank you!
— V = IR (Talk • Contribs) 05:38, 23 February 2011 (UTC)
I tested that edit in both Chrome9 and IE8 without problem. Was it apparent only in Firefox? — Edokter (talk) — 11:57, 23 February 2011 (UTC)
I observed that it was broken and that this edit fixed it. I was using WP vector theme running on Firefox3 on Windows. DMacks (talk) 13:29, 23 February 2011 (UTC)
Edokter I just tried Chrome9 and IE8 and they both do not accept this syntax either: in Chrome open Tools->Developer tools, in Console try obj = {a-b:5} (result: SyntaxError), compare to obj = {a:5} which works. — AlexSm 15:21, 23 February 2011 (UTC)

"configrevisionjumper is not defined"

This problem has been for a while, even before the switch to MediaWiki 1.17. When selecting the Revision Jumper from the Preferences I get the following javascript error in the Firefox Error Console: "configrevisionjumper is not defined", and the extension is not working. Anyone know what to do about it? Nageh (talk) 09:22, 23 February 2011 (UTC)

Gadget code MediaWiki:Gadget-revisionjumper.js calls dewiki gadget de:MediaWiki:Gadget-revisionjumper.js. Dewiki gadget needs extra file de:MediaWiki:Gadget-revisionjumper-config.js which used to be called with absolute path (de.wikipedia.org/...) but since Jan 8, 2011 the path is relative (wgServer) and since there is no local file MediaWiki:Gadget-revisionjumper-config.js the enwiki gadget fails. — AlexSm 15:45, 23 February 2011 (UTC)
So can someone set up this file? It's kind of a bad joke when an extension is officially supported by the Preferences menu but then doesn't work. Thanks for the explanation, btw. Nageh (talk) 16:14, 23 February 2011 (UTC)
I've fixed it. Sorry, —DerHexer (Talk) 16:36, 23 February 2011 (UTC)

Turning on refTools for everyone

Per the overwhelming consensus at this discussion at Village pump (proposals), I will be turning on refTools for all editors today. If this causes any problems, please revert the additions at MediaWiki:Common.js/edit.js. Thanks. Kaldari (talk) 19:08, 23 February 2011 (UTC)

Will this have any effect on users not using the enhanced toolbar? –xenotalk 19:11, 23 February 2011 (UTC)
Yes, they should see the older version of refToolbar. Kaldari (talk) 19:22, 23 February 2011 (UTC)
Will there be any way to suppress it? –xenotalk 19:26, 23 February 2011 (UTC)
Yes, see Wikipedia:RefToolbar 2.0#Disabling. Kaldari (talk) 19:32, 23 February 2011 (UTC)
Thanks. –xenotalk 19:38, 23 February 2011 (UTC)
Actually it looks like the disabling mechanism might not work due to the loading order. Looks like I'll need to figure out something else... Kaldari (talk) 21:35, 23 February 2011 (UTC)
Fixed. Kaldari (talk) 22:18, 23 February 2011 (UTC)
This seems to have made the citation templates no longer work for me. I've explained to Kaldari on his page; see here. Would it not make sense to let people switch these things on and off in their preferences as they choose to? SlimVirgin TALK|CONTRIBS 21:48, 23 February 2011 (UTC)
I'm not convinced this is related to the new universal refTools code. Your screenshot was of the gadget version (which prevents the universal version from loading). In addition, you said that the problem persisted even after you disabled the new script explicitly. Kaldari (talk) 22:18, 23 February 2011 (UTC)
Looks like the problem was a conflict with the experimental "Enable preview dialog" feature. Kaldari (talk) 01:08, 24 February 2011 (UTC)

bug with "contributors"

There is a bug with "contributors", the toolserver WikiSense under "file history". I followed the links and set up an account to report the error, but I couldn't find any way to actually report it.

The problem is that if you go to "history" and "contributors" on Tom Clancy's Splinter Cell: Checkmate, it lists some contributors (including me) that did not contribute to this article, but to checkmate instead. (I don't know what else to do about reporting this.) Bubba73 You talkin' to me? 04:11, 24 February 2011 (UTC)

It's not correctly processing everything before the colon, I think. If you said you made a JIRA account, go to this page, log in, click "bug" at the top right, and go on from there. Otherwise, try contacting the tool maintainer directly; JIRA is just preferable because it keeps track of everything. /ƒETCHCOMMS/ 04:23, 24 February 2011 (UTC)


I created an account about an hour ago, but it won't let me log in, and when I tell it that I'm having problems logging in, it doesn't find me. Bubba73 You talkin' to me? 04:40, 24 February 2011 (UTC)
Well, I got logged in and found "bug" under "create issue". Bubba73 You talkin' to me? 04:45, 24 February 2011 (UTC)

Jumping to the wrong section

I've had several incidents since the MediaWiki upgrade where clicking a section link from a different article or an edit summary takes me to the section immediately after what is in the link. When it happens, it will often keep happening on the same link several times and then it starts working once I have clicked any item in the TOC of the destination article. Once it starts working, I can't induce another failure even if I close the tab completely and reopen it. It just happened to me on Talk:Scientology#Call_Hubbard_a_.22Science_fiction_writer.22, which I clicked on from the edit summary by RUL3R in the page history. —UncleDouggie (talk) 20:48, 18 February 2011 (UTC)

So if I understand correctly, you clicked on that link and landed at "Image for Auditing subsection" ? Which browser are you using ? —TheDJ (talk • contribs) 00:02, 19 February 2011 (UTC)
Yes, that's right. I'm using FF 3.6.13. It's got to be something with the browser jumping to the section before all the scripts run at the end with ResourceLoader and that somehow repositions the cursor. Others have reported strange jumpy behavior. In this case, I didn't scroll the window at all, it just immediately went to the wrong section. It happened more than once and on the subsequent incidents I was very careful to not scroll. Unfortunately, it corrected itself before I could get into serious troubleshooting. —UncleDouggie (talk) 08:27, 19 February 2011 (UTC)
When completing the edit of this very section, I first see the properly formatted #MediaWiki software and scripts section and about 1 second later it jumps down to this section. That's probably due to the auto collapsing of the header FAQ. Perhaps I had something similar but it didn't reposition to the proper location for whatever reason. My browser is running a little slow at the moment because I probably have 40 tabs open, but it was never a problem before the MediaWiki upgrade. I guess it's time to save off all the stuff I have in progress and restart. —UncleDouggie (talk) 08:38, 19 February 2011 (UTC)
Ah right of course. It's a bit of a Firefox bug, but an annoying one for sure. Something we might be able to fix in the collapsing code though. (Remember that the collapsing code is an en.wp extension and not part of the MediaWiki software.) —TheDJ (talk • contribs) 09:13, 19 February 2011 (UTC)
I am experiencing the same issue on this pump since the 1.17 upgrade. Svick (talk) 21:10, 19 February 2011 (UTC)
I've got something similar and I'm using Google Chrome. When I navigate to a section (on pages with no collapsed text or anything like that), it first jumps to the right section and then, when the browser stops loading, jumps a section or two up the page. HJ Mitchell | Penny for your thoughts? 20:34, 20 February 2011 (UTC)
After lots of testing, I finally figured out what's happening. Any script that modifies the page can cause this behavior. It's a race between the page updates and the section jump. Before ResourceLoader, page updates usually won. Now it's a 50/50 proposition and it's worse if your network connection is congested because the scripts take longer to load. The biggest culprit for long talk pages is the gadget "comments in local time.js" because it changes so much text on the page. I run an enhanced version of the gadget, but the same thing happens with the stock version. Since I have my own copy, I made a quick change that has fixed the problem most of the time, although a big jump still happened once when my wireless link was overloaded running a backup. When I had this script disabled entirely, I still saw an occasional jump of a few lines. The culprit may have been the steward election banner that I hadn't dismissed in Safari where I was testing. Also strangely, in FF the jumps are always past the desired section and in Safari they are always before the desired section. I give up on that one. —UncleDouggie (talk) 07:32, 21 February 2011 (UTC)
Is there some script writer we could coerce ask to fix that script for the general population who uses it? The page jumping is really annoying. :-( Killiondude (talk) 03:00, 23 February 2011 (UTC)
It is doing the same for me (in Firefox), and is driving me nuts. It can't exactly help the newcomers, who already have to deal with an interface that you need to understand in order to figure out how to complain that you don't understand it... AndyTheGrump (talk) 03:17, 23 February 2011 (UTC)
The problem with section links was also reported by Carnildo in this topic. I also notice the problem from time to time (in FF and/or Chrome). Helder 23:08, 24 February 2011 (UTC)

Insert section when editing de-linked

Is that just my computer or has WP been "improved" by restricting the usability of the editing section? There is no more drop down menu to choose from, an everything that could be inserted has been de-linked. Instead of clicking on the four tildes to insert a signature, I have to copy+paste it now, and the same goes for anything else. I haven't changed anything in my preferences or in my browser settings, so a change in the source seems to be the only reasonable guess. Can this be changed back in any way? Best, Trigaranus (talk) 07:50, 23 February 2011 (UTC)

In Preferences, go to the Editing tab and uncheck "Enable enhanced editing toolbar". That will give you the old editing toolbar back. Isn't it easier to just type out ~~~~ than to copy and paste it, though? Gary King (talk · scripts) 18:09, 24 February 2011 (UTC)

Page removed from watchlist

Resolved
 – Discussed on IRC at #Wikimedia-tech. There was a bug. Fix should be deployed out shortly. Thanks, West.andrew.g (talk) 16:23, 24 February 2011 (UTC)

I think this problem pertains to the transition to 1.17 -- as this behavior started up around that time, and was absolutely fine in the weeks/months before. Previously, page Wikipedia:STiki/revert_count was on my watchlist. After the transition, it is off my watchlist. I add it again, it disappears again. It's disappearance seems to correspond to whenever the page is edited. The page is edited nightly by a script (which uses my credentials). What is going on here? I didn't notice any API changes that would have caused this. Thanks, West.andrew.g (talk) 16:13, 23 February 2011 (UTC)

That script probably sets the watchlist action to unwatch it. ΔT The only constant 16:39, 23 February 2011 (UTC)
Negative. It's just a simple edit -- no such parameter is passed -- and there has never been a "this article needs to keep being watched" flag? Thanks, West.andrew.g (talk) 16:54, 23 February 2011 (UTC)
UncleDouggie -- saw you posted on this but then retracted. Can you provide any insight? Thanks, West.andrew.g (talk) 19:22, 23 February 2011 (UTC)
I forgot that I had done a mass purge of user talk pages from my watchlist a few days ago and I had removed the page at that time. —UncleDouggie (talk) 05:23, 24 February 2011 (UTC)
Also, added to the watchlist of my alternate account. We'll see what happens when the update occurs at 5:00UTC. Thanks, West.andrew.g (talk) 01:06, 24 February 2011 (UTC)
It was NOT removed from the watchlist of my alternate account, only the one making the edit. Reading the API Documentation, nothing has changed. Typically I have "&watchlist=preferences" (by default). I explicitly changed it to "&watchlist=nochanges" -- and the page was still removed from my watchlist. Something very funny going on here.... Thanks, West.andrew.g (talk) 06:30, 24 February 2011 (UTC)

Given what I observed above, this might be the cause for more concern. I don't know how often pages get edited via "api.php" -- but what if it were the case that every time someone edited a page in this fashion, it de-watch-listed it (if it were watchlisted)? You'd think this would have been noticed by now -- but the tools that use "api.php" are often anti-vandal ones (and not JavaScript tools like Twinkle, which per the controversy below, seem not to be using "api.php"). Because the tools are patrol tools, users are often patrolling arbitrary topics, so the number of times a patrolled page is a watchlisted one may be rare (and then actually noticing the de-watch-listing would require a keen eye). Thoughts? Thanks, West.andrew.g (talk) 15:24, 24 February 2011 (UTC)

Confirmed; bigger issue. I just added the sandbox to my watchlist, and made an "api.php" edit to the sandbox. The sandbox was no longer on my watchlist after this edit. This is a change in functionality obviously related to the 1.17 transition. The "watchlist" flag is seemingly ignored. Thanks, West.andrew.g (talk) 15:24, 24 February 2011 (UTC)

Twinkle problem

Is anyone else having problems with Twinkle? Whenever I try to use it this morning, it gets as far as "User talk page modification: data loaded..." before just sitting there doing nothing. I even tried removing it from Preferences>Gadgets then re-adding it, no dice. - The Bushranger One ping only 16:19, 23 February 2011 (UTC)

Yes, it's dead for me as well. Someone must be trying to fixing something. —UncleDouggie (talk) 16:38, 23 February 2011 (UTC)
Yep; I'm getting "data loaded..." and then nothing. The Blade of the Northern Lights (話して下さい) 17:08, 23 February 2011 (UTC)
Making it hard for me to revert vandalism, I shall give up for a while. Dougweller (talk) 19:11, 23 February 2011 (UTC)
Evidently, Twinkle isn't the only javascript-based tool that's out of order right now. The ARV tool that I often use to report vandals is also broken. I wonder how many other javascript-based tools are also experiencing technical difficulties at this moment. --SoCalSuperEagle (talk) 20:46, 23 February 2011 (UTC)
Reported at, surprise surprise, Wikipedia talk:Twinkle/Bugs. The ARV tool is part of Twinkle, IIRC. – ukexpat (talk) 21:06, 23 February 2011 (UTC)
Yes, Twinkle does have its own ARV feature, but I was referring to a separate ARV tool that was developed by Lightdarkness. I just took a little peek at the actual javascript coding for that tool and noticed that it also depends on the so-called "editform" element that Twinkle relies on. (The error messages that Twinkle has been displaying today specifically mention the "editform" element.) So basically, it seems that just about any javascript-based tool that relies on the "editform" thing would be affected by the issue that's caused Twinkle to stop functioning normally. --SoCalSuperEagle (talk) 22:02, 23 February 2011 (UTC)
Just to say, I'm having the same problem with Twinkle. DuncanHill (talk) 04:36, 24 February 2011 (UTC)

I have successfully upgraded the standalone ARV tool to use the API. My working version can be found at User:UncleDouggie/aiv.js. Now we just need to fix Twinkle! My changes to the ARV tool were rather extensive. However, if Twinkle is modular enough, perhaps I can easily deploy the same fix? I'll go start looking at it. —UncleDouggie (talk) 11:51, 24 February 2011 (UTC)

MW suddenly ignoring "line-height" CSS property

On my Canadian postal code list pages, such as List of A postal codes of Canada, I set the CSS "line-height" property to a certain amount to maximize the amount of text that would fit on the screen. But now, suddenly the page has been rendering with too much leading space per line, as if the line-height was set to "200%" when I specified "125%". Can this be fixed? I'm using the Monobook skin. --  Denelson83  23:22, 23 February 2011 (UTC)

Line-height looks fine on that page. The 125% is applied to the text in each cell as you have set it, according to my browser. It doesn't look like 200% for me. Gary King (talk · scripts) 18:05, 24 February 2011 (UTC)
Hey, it's suddenly fixed on my screen. No idea why it went like that in the first place... ¬_¬ --  Denelson83  23:40, 24 February 2011 (UTC)

"Compare selected revisions" = RevDelete

When I attempt to compare any two revisions of a page by using the "Compare selected revisions" button, it takes me to an error page:(URL)

You have either not specified a target revision(s) to perform this function, the specified revision does not exist, or you are attempting to hide the current revision. Return to Main Page

Is anyone else seeing this? I am using monobook on IE7. decltype (talk) 08:16, 24 February 2011 (UTC)

Use the radio buttons te selct revision to compare (left button), use the checkboxes to select the revision you want to (un)delete (right button). Not selecting any checkbox and clicking the (un)delete button will result in this error. — Edokter (talk) — 13:43, 24 February 2011 (UTC)
I had a similar problem when RevDelete first came out. When I selected two radio buttons and pressed enter, the "Del/Undel selected revisions" button was capturing the enter action. I am not able to reproduce such behavior now. (I am presently running monobook in Firefox.) -- Tom N (tcncv) talk/contrib 21:27, 24 February 2011 (UTC)

I'm not sure if this is the right place for this, but I'm detecting a pretty serious problem tonight. It seems many reflinks have been merged within the last day or so (I don't know exactly when this happened, but I just noticed it a few minutes ago). I've checked the history pages and I can see it's not something that anyone has done manually on the pages I'm watching, but it's obviously something within the automated system that's changed. As I'm sure most people know many pages have more than one reflink to the same site - for example when a celebrity has been nominated for an Emmy Award several times. The reference SITE is the same as other reflinks on the page, but the actual LINK is different. The same is true for interviews - for example - A star will do an interview with Variety, and then 2 or 3 years later will do another DIFFERENT interview with them. In these instances I have usually used a single quote (') to distinguish one reflink from another when I create or add reflinks to pages. If there are three different reflinks to the same site then I use three single quotes, etc, like this - (these are modified so the reflinks will show up as text, and I've removed the rest of the reftags and actual link portions of the reflinks, just to give you the idea of what I'm talking about) -

< ref name="Kids' Choice Awards">

< ref name="Kids' Choice Awards'">

< ref name="Kids' Choice Awards''">

< ref name="Kids' Choice Awards'''">

- This method has always worked fine for me to separate different reflinks to the same site on a single Wikipedia page, until today where I notice all 4 of the above reflinks are now recognized as the SAME and have been automatically "merged", which makes them completely useless. As you can imagine, whatever this new change was has totally messed up dozens of reflinks on literally dozens of pages I've written and/or added reflinks to (some pages that had 40 reflinks yesterday, now show 25 reflinks due to the "merging"). I'm sure the pages I've worked on aren't the only pages affected by this change and I believe reflinks are the probably the most important element on Wikipedia to insure the integrity of the information provided here, so I'm curious - is this just a temporary "bug" or is this a permanent change that will mean I now need to go back in and fix every single page I've ever written, edited, or sourced? I'm hoping this isn't permanent or can be easily changed back because this would literally take me HOURS to go back and fix on every page I've ever edited (especially the extremely long ones with 40 or 50 or more reflinks). Time that would obviously be better spent improving NEW pages, instead of "fixing" dozens of old ones that were just fine a couple of days ago. --- Crakkerjakk (talk) 08:28, 24 February 2011 (UTC)


Can you give an example of a page where it's a problem? It may be that something has changed so that the ' character is not recognised in the reference names. If they do have to fixed manually, you should consider asking someone with WP:AWB to do it for you, as they'll be able to semi-automate it. SmartSE (talk) 10:39, 24 February 2011 (UTC)
Sure, one page that's a good (easy to review) example is the =Awards= section of the iCarly page. It's a Nickelodeon sitcom that has been nominated for multiple awards. I've just updated the Awards wikitable there within the last week with a bunch of reflinks (many of which all linked to different pages on the same sites - the Emmy Awards site, the Kids Choice Awards site, the Young Artist Awards site, etc.) All the links were separate as recently as yestrerday (I know this for a fact because I check reflinks for errors before I save any changes I make), but are now all merged, so that every Emmy Award reflink is "merged" with the first, every Kids Choice Award reflink is merged with the first, etc. That's a good place to just take a glance at what I'm talking about since all the reflinks in that case are listed in a relatively small wikitable. Of course the REAL problem is where links have been merged within the body of long articles I've written (where there are 40 or 50 reflinks on the page and many single reflinks were deliberately cited as many as 10 or 15 times within the article appearing in the "abcdefg" sequence in the =Reference= section, even BEFORE this recent "merging"), so I'm hoping this is part of the same bigger change that's been causing other problems here within the last day, and will be reverted, but if not then I'd definitely like to have someone do it who can semi-automate it. I'd just like to find out if this is a permanent change or if it's just temporary and will be fixed - before I go through my entire editing history to make a list of EVERY page I've ever edited that now has this problem. --- Crakkerjakk (talk) 11:00, 24 February 2011 (UTC)
I was looking at this, confirming your description, and now the problem has just this moment gone away. The {{sfn}} problem mentioned below seems to have cleared at the same time. Thincat (talk) 13:33, 24 February 2011 (UTC)
Yes, you're right. I've just checked several pages, and the problem seems to have vanished just as quickly as it appeared. If anyone has info as to what caused this problem and why (so I know for future reference in case it ever happens again), please make a note here to let me know. Thanks --- Crakkerjakk (talk) 13:43, 24 February 2011 (UTC)
I think it had to do with the change to HTML5, which seems to have been reverted. When HTML5 mode is enabled, the it changes runs of whitespace, single-quote, double-quote, underscore, ampersand, octothorpe, and/or percent sign to a single underscore, and then trims leading and trailing underscores. In HTML4 mode, it replaces all these characters (and many more) with a variation on percent-encoding that uses periods instead of percent characters. Anomie⚔ 14:07, 24 February 2011 (UTC)
This encoding change is also evidently behind #Problem with template:cite doi above. LeadSongDog come howl! 14:30, 24 February 2011 (UTC)
Ok, I get the gist of it, but I'm still kinda new to all of this - so I guess my final question(s) is this - Does the switch from HTML4 to HTML5 happen often? Or is it just a switch that happens occasionally for relatively short periods of time in the middle of the night for "maintenance" purposes? Or is there a plan in the works to switch to HTML5 permanently sometime in the future? Basically, do I need to think about fixing these reflinks now while I have them separated out and easy to identify before they're "merged" again permanently? --- Crakkerjakk (talk) 14:35, 24 February 2011 (UTC)
I would imagine the plan is that it eventually get switched permanently - and that this switch would have been permanent if it hadn't thrown up so many problems. Rich Farmbrough, 16:53, 24 February 2011 (UTC).
I see you've gone in and fixed all similar reflinks. Thank you Rich. --- Crakkerjakk (talk) 22:10, 24 February 2011 (UTC)
Personally, I'd suggest using something more descriptive to distinguish the links -- dates, for example. --SarekOfVulcan (talk) 18:55, 24 February 2011 (UTC)
Dates would work except many sites don't "date" their pages - Like the Emmy Awards site just shows the year, but even then - I'm often citing best TV show, best actor, best actress, etc, all different pages, but from the same year, so dating doesn't work. I know I originally did try and use numbers to distinguish reflinks to the same site (Emmy Awards 1, Emmy Awards 2, Emmy Awards 3, etc), but for some reason not all the numbers were showing up (although it was relatively early on in my time editing here when I first noticed reflinks to the same site would automatically be merged without something in the site name to make them different, so I could have been doing something wrong at the time). I try to be relatively descriptive in the reflink titles, so I just didn't see a need to go into elaborate detail with the site name since that would make every reflink a mile long (which I find incredibly annoying), and using the single quote (') seemed to be an easy fix (at the time). I see Rich has fixed the problem by going with my original idea of numbering the site names with 1, 2, 3, and that seems to work, so I'll just go back to doing that from now on, now that I know certain symbols could cause a problem down the line. --- Crakkerjakk (talk) 22:10, 24 February 2011 (UTC)

Problem with valign=bottom

From User:Headbomb/Thingy
click to show

User:Headbomb/Thingy

The first table has valign:bottom; and doesn't align properly. The second as valign:top; and aligns properly. What gives? Headbomb {talk / contribs / physics / books} 09:17, 24 February 2011 (UTC)

They don't align properly because each of those colored bars has an equally-sized table row beneath them, but I can't seem to trace its origin. — Edokter (talk) — 13:20, 24 February 2011 (UTC)
Found it; you forgot the datacell ("|") delimiters. — Edokter (talk) — 13:32, 24 February 2011 (UTC)
Good catch, many thanks. Headbomb {talk / contribs / physics / books} 16:27, 24 February 2011 (UTC)

{{Sfn}} error

I have noticed on pages like Serial killer that are using {{Sfn}} the coding is all messed up...This are not new additions but long standing coding that is now just messed up. See also War of 1812#United States expansionism for an example. Moxy (talk) 09:30, 24 February 2011 (UTC)

It looks to me that the problem has cleared. I wonder if this is (was) associated with that above at #Merged_Reflinks. Thincat (talk) 13:38, 24 February 2011 (UTC)
It looks like it was related to the change from HTML4 to HTML5 modes. In HTML4 mode, wikitext characters get escaped in the anchor name, e.g. <ref name="foo [[bar]]" /> generates wikitext like <sup id="cite_ref-foo_.5B.5Bbar.5D.5D_0-0" class="reference">[[#cite_note-foo_.5B.5Bbar.5D.5D-0|[1]]]</sup>; note the brackets have changed to ".5B" and ".5D". In HTML5 mode, these characters aren't escaped, generating <sup id="cite_ref-foo_[[bar]]_0-0" class="reference">[[#cite_note-foo_[[bar]]-0|[1]]]</sup> instead, with brackets inside the attempted wikilink. Since brackets cannot actually appear inside a wikilink, boom. Anomie⚔ 14:18, 24 February 2011 (UTC)
Yep. Broke {{singlechart}}, too.—Kww(talk) 16:26, 24 February 2011 (UTC)

Filed as bugzilla:27694 —TheDJ (talk • contribs) 20:46, 24 February 2011 (UTC)

Proposal re Prod process

I made a proposal for a minor change to Cydebot so that the admin dashboard list of Prods would be correct. The obvious candidate for making the change is Cyde, but my understanding is that Cyde is no longer action. I proposed the change on the talk page of Admin dashboard, but that page isn't getting a lot of traffic, and is languishing. Any suggestions? The requested change is trivial and I think noncontroversial, but I don't have the technical ability to do it. (To summarize the proposal - I think the list of prods should be those eligible now for deletion, not those whose eligibility will come up sometime in the next 24 hours.)--SPhilbrickT 15:53, 24 February 2011 (UTC)

Commented there. Rich Farmbrough, 17:37, 24 February 2011 (UTC).

Broken table

Is the table in this article broken? --Highspeedrailguy (talk) 17:57, 24 February 2011 (UTC)

Yes it was broken. I fixed it. Gary King (talk · scripts) 18:02, 24 February 2011 (UTC)
And I removed the rowspans and center aligns that weren't working or needed. ---— Gadget850 (Ed) talk 18:06, 24 February 2011 (UTC)

Transcluded text from Template:R from incorrect name missing from Wikipedia:Template messages/Redirect pages##I to M

The {{{1|''the redirect target''}}} displayed message does not seem to appear on the page it's meant to be transcluded onto. :| TelCoNaSpVe :| 03:58, 25 February 2011 (UTC)

Wikipedia:Template messages/Redirect pages#I to M uses {{Tlrow}} which calls the redirect template {{{1}}} with {{{{{1|tlrow}}}|{{{2|}}}|{{{3|}}}...}}}. Here {{{2|}}} passes an empty unnamed parameter instead of no unnamed parameter. The empty unnamed parameter is picked up by {{{1}}} in {{{1|''the redirect target''}}} and correctly "displayed" (as an empty string). I don't know whether {{Tlrow}} can be modified to not add empty unnamed parameters when it's called without unnamed parameters. In this particular case, the table at Wikipedia:Template messages/Redirect pages#I to M could be forced to show the same as {{R from incorrect name}} currently does by replacing {{Tlrow|R from incorrect name|category=Redirects from incorrect names}} with {{Tlrow|R from incorrect name|''the redirect target''|category=Redirects from incorrect names}}. But it wouldn't be stable if {{tl|R from incorrect name}} is edited to display something else. PrimeHunter (talk) 04:50, 25 February 2011 (UTC)

Table show/hide disfunction

If I am on the right place: when asking for an uncollapse, it does not happen and my screen jumps to top-of-page. Example: (see also page Unicode character property):

General Category (Unicode Character Property)[a]
Value Category Major, minor Basic type[b] Character assigned[b] Count[c]
(as of 16.0)		 Remarks
 
L, Letter; LC, Cased Letter (Lu, Ll, and Lt only)[d]
Lu Letter, uppercase Graphic Character 1,858
Ll Letter, lowercase Graphic Character 2,258
Lt Letter, titlecase Graphic Character 31 Ligatures or digraphs containing an uppercase followed by a lowercase part (e.g., Dž, Lj, Nj, and Dz)
Lm Letter, modifier Graphic Character 404 A modifier letter
Lo Letter, other Graphic Character 136,477 An ideograph or a letter in a unicase alphabet
M, Mark
Mn Mark, nonspacing Graphic Character 2,020
Mc Mark, spacing combining Graphic Character 468
Me Mark, enclosing Graphic Character 13
N, Number
Nd Number, decimal digit Graphic Character 760 All these, and only these, have Numeric Type = De[e]
Nl Number, letter Graphic Character 236 Numerals composed of letters or letterlike symbols (e.g., Roman numerals)
No Number, other Graphic Character 915 E.g., vulgar fractions, superscript and subscript digits, vigesimal digits
P, Punctuation
Pc Punctuation, connector Graphic Character 10 Includes spacing underscore characters such as "_", and other spacing tie characters. Unlike other punctuation characters, these may be classified as "word" characters by regular expression libraries.[f]
Pd Punctuation, dash Graphic Character 27 Includes several hyphen characters
Ps Punctuation, open Graphic Character 79 Opening bracket characters
Pe Punctuation, close Graphic Character 77 Closing bracket characters
Pi Punctuation, initial quote Graphic Character 12 Opening quotation mark. Does not include the ASCII "neutral" quotation mark. May behave like Ps or Pe depending on usage
Pf Punctuation, final quote Graphic Character 10 Closing quotation mark. May behave like Ps or Pe depending on usage
Po Punctuation, other Graphic Character 640
S, Symbol
Sm Symbol, math Graphic Character 950 Mathematical symbols (e.g., +, −, =, ×, ÷, √, ∊, ≠). Does not include parentheses and brackets, which are in categories Ps and Pe. Also does not include !, *, -, or /, which despite frequent use as mathematical operators, are primarily considered to be "punctuation".
Sc Symbol, currency Graphic Character 63 Currency symbols
Sk Symbol, modifier Graphic Character 125
So Symbol, other Graphic Character 7,376
Z, Separator
Zs Separator, space Graphic Character 17 Includes the space, but not TAB, CR, or LF, which are Cc
Zl Separator, line Format Character 1 Only U+2028 LINE SEPARATOR (LSEP)
Zp Separator, paragraph Format Character 1 Only U+2029 PARAGRAPH SEPARATOR (PSEP)
C, Other
Cc Other, control Control Character 65 (will never change)[e] No name,[g] <control>
Cf Other, format Format Character 170 Includes the soft hyphen, joining control characters (ZWNJ and ZWJ), control characters to support bidirectional text, and language tag characters
Cs Other, surrogate Surrogate Not (only used in UTF-16) 2,048 (will never change)[e] No name,[g] <surrogate>
Co Other, private use Private-use Character (but no interpretation specified) 137,468 total (will never change)[e] (6,400 in BMP, 131,068 in Planes 15–16) No name,[g] <private-use>
Cn Other, not assigned Noncharacter Not 66 (will not change unless the range of Unicode code points is expanded)[e] No name,[g] <noncharacter>
Reserved Not 819,467 No name,[g] <reserved>
  1. ^ "Table 4-4: General Category". The Unicode Standard. Unicode Consortium. September 2024.
  2. ^ a b "Table 2-3: Types of code points". The Unicode Standard. Unicode Consortium. September 2024.
  3. ^ "DerivedGeneralCategory.txt". The Unicode Consortium. 2024-04-30.
  4. ^ "5.7.1 General Category Values". UTR #44: Unicode Character Database. Unicode Consortium. 2024-08-27.
  5. ^ a b c d e Unicode Character Encoding Stability Policies: Property Value Stability Stability policy: Some gc groups will never change. gc=Nd corresponds with Numeric Type=De (decimal).
  6. ^ "Annex C: Compatibility Properties (§ word)". Unicode Regular Expressions. Version 23. Unicode Consortium. 2022-02-08. Unicode Technical Standard #18.
  7. ^ a b c d e "Table 4-9: Construction of Code Point Labels". The Unicode Standard. Unicode Consortium. September 2024. A Code Point Label may be used to identify a nameless code point. E.g. <control-hhhh>, <control-0088>. The Name remains blank, which can prevent inadvertently replacing, in documentation, a Control Name with a true Control code. Unicode also uses <not a character> for <noncharacter>.

-DePiep (talk) 22:03, 16 February 2011 (UTC)

Collapsable and Sortable don't mix very well. — Edokter (talk) — 22:28, 16 February 2011 (UTC)
Metoo: seems to be related (so: combination => bug) -DePiep (talk) 23:39, 16 February 2011 (UTC)
Since? -DePiep (talk) 22:29, 16 February 2011 (UTC)
This is probably caused by a conflict between MediaWiki:CollapsibleTemplates.js and the new MediaWiki 1.17 JS code. Kaldari (talk) 22:29, 16 February 2011 (UTC)
Sorry, that's on Commons. The code here is in MediaWiki:Common.js. Kaldari (talk) 22:32, 16 February 2011 (UTC)
Well, it looks like it is introduced (broken) by 1.17. What do we do? -DePiep (talk) 22:34, 16 February 2011 (UTC)
Best ask Krinkle, he made some modifications to common.js today. — Edokter (talk) — 22:53, 16 February 2011 (UTC)
Are we 100% sure this ever worked ? —TheDJ (talk • contribs) 22:57, 16 February 2011 (UTC)
Yes, it worked. btw, I asked Krinkle at their Commons talkpage. -DePiep (talk) 23:01, 16 February 2011 (UTC)
Eh, TheDJ, why the question? Anything strange in template's history or usage? -DePiep (talk) 23:16, 16 February 2011 (UTC)
Because I wanted to make sure that we weren't misdiagnosing a problem. And we were, the root problem was always there, it was just less visible before. —TheDJ (talk • contribs) 14:15, 20 February 2011 (UTC)
Strangely, this bug doesn't happen if you're looking at the table in an edit preview, only on live pages. Kaldari (talk) 23:34, 16 February 2011 (UTC)
Come to think of it, this probably is because the sortable code breaks the collapse code. Krinkle will probably deal with that tomorrow. load order will probably matter in this case. —TheDJ (talk • contribs) 23:47, 16 February 2011 (UTC)
The sortable code hasn't changed and is deprecated (soon to be replaced, for now the legacy ts_sortable will just continue to work). The collapsing code is not part of core and made on Wikipedia. Neither has changed recently, so I'm not sure how I can be of help. I doubt this ever worked. Since there's a lot of my agenda right now so I'm going to skip this for now since it's deprecated. The new collapser part of core (will be released in 1.18 or sooner) works fine with the tablesortable code as you can see on this demo page which has sortable and collapsible tatbles and what not all working fine. Krinkle (talk) 19:34, 17 February 2011 (UTC)
Again, yes it did work. Very unsympathic, this suggestion (and no more than that) (earlier written by TheDJ here), that it might not have worked before. If you doubt it, please reinstate the previous situation. E.g. the template here did sort&hide well since last August. Other formerly well functioning templates: {{Bidi Class (Unicode)}}, {{Unicode blocks}}, {{ISO 15924 script codes and Unicode}}. This is just my own catalog.
Whatever the code background, it was broken recently. "deprecated" is no reason to break it. "is not part of core" is not so either.
In general: a working thing is broken. So we should restore somehow. If Krinkle is short in time, just revert or ask someone else. -DePiep (talk) 20:02, 17 February 2011 (UTC)
This is probably caused by the JS using killEvt() which is deprecated now. See http://www.mediawiki.org/wiki/ResourceLoader/JavaScript_Deprecations. Kaldari (talk) 05:17, 18 February 2011 (UTC)
So: deprecated yes, unavailable no. If I read the link well, the deprecated functions are still available now (in 1.17), but not for ever. This gives "us" the time to replace then with modern variants. All right then. Replace with something new if and when it works, I'd say. On top of this, is it required to push these changes while 1.17 is rolled out as it is? Is there something in this development-to-production stream I do not get? -16:55, 18 February 2011 (UTC)

I have an explanation. This edit replaced addOnloadHook(createCollapseButtons) (which means onload these days) with $(createCollapseButtons) (which means $(document).ready) making it run a bit sooner than before. As a result, sortables_init() from wikibits is now executed after createCollapseButtons() and the code cell.innerHTML += ... of course removes the handler. — AlexSm 18:29, 18 February 2011 (UTC)

Is there any way to fix this problem? Lonelydarksky (暗無天日) contact me (聯絡) 09:32, 19 February 2011 (UTC)
Sure, just ask any sysop to revert that particular change: addOnloadHook() is going to stay with us for a while. Another option is to switch collapsible code back to href=javascript just like in other type of collapsible (NavigationBar). P.S. Looks like the sortable innerHTML issue was fixed in wikibits.js but did not make it to 1.17. — AlexSm 19:27, 19 February 2011 (UTC)
What is sysop? Probably theDJ, Kaldari, Krinkle, maybe even Edokter -- all present in this thread, should have reverted at first notice, instead of deflecting. But hey, they seem to have toes. -DePiep (talk) 20:28, 19 February 2011 (UTC)
The fix for the old sortables code is marked for deployment to the live website. But it's weekend, and system administrators have weekends as well. Roan already worked 6 hours in his spare upaid volunteer time yesterday, to take care of some important issues, but he did not yet get around to this one. —TheDJ (talk • contribs) 14:13, 20 February 2011 (UTC)
Oh, it's weekend now. That explains it all. Very amateuristic to mention that as an explanation for untested changes. I posted here Wednesday. Very disappointing you introduce the personalised approach, TheDJ. -DePiep (talk) 21:22, 20 February 2011 (UTC)

In order to keep things related to this central, I will respond to this message over here. I apologize if I broke anything during my "migration"-edit. My intention was and still is to prepare the wikis for the upcoming change. Some may think that moving away from deprecated functions now is too soon, but I don't think so. Right now we can move away from them and move back and forth whenever we want, because both old and new are available now. Therefore this is, in my opinion, the perfect time to atleast attempt to switch, and test to see if everything still works like it should. Anything that broke ? Revert me, please do so, and then let me know what exactly broke with 1.17 and/or my edits. I love bug reports (that is, if something brakes, I rather hear about it so that it can be prevented in the future then it be silently fixed).
AlexSm is right in that the replacing of HTML is cause (atleast one of the causes) of any handlers being removed (such as collapsing and/or sortable clickable images and texts). I noticed during the development of another plugin in MediaWiki that it was being canceled somehow in table cells. It was caused by innerHTML and was fixed in trunk (rev:78893) which I've tagged to be merged to the live site, this will hopefully fix this!

I didn't mean to sound uncaring about this problem, but I can't fix everything everywhere and this particular script issue does not seem to be caused by something I did. I'm happy to check it out and perhaps be able to fix it, however from what I can see this issue may not have been noticed before but is not new and doesn't occur in most cases. Since a jQuery plugin has added to the repository (jquery.makeCollapsible) which does not seem to have any of the bugs, it would make sense to migrate to that instead of fixing or rewriting the current script. If you like I could install jquery.makeCollapsible locally on en.wikipedia (as it was not deployed) so you can check it out and start using it. That way, when it is deployed for real, it can simply be removed and everything will still work great. Let me know what you think, thanks, Krinkle (talk) 22:23, 19 February 2011 (UTC)

Pardon me if I appear ignorant about what's going on. I'm under the impression that somebody recently introduced new changes to the original script or something, and that resulted in the problem with the collapsible and sortable functions. Am I correct? Anyway, I hope the experts can fix the problem as soon as possible. Thanks. Lonelydarksky (暗無天日) contact me (聯絡) 07:33, 20 February 2011 (UTC)
No, that's not correct. The problem addressed here when a table is both wanted to be handled by the tablesortable-script and the collapsibletable-script is not new. Due to the recent changes people are testing scripts and this bug was finally found, but I'm fairly sure that this is not a new bug. Anyway, the new makeCollapsible module is a lot more flexible, can collapse both devisions, tables and lists and is also localized by using interface messages and works together with the sortable script. See it live here. Krinkle (talk) 13:27, 20 February 2011 (UTC)
Actually, the load order changes from ResourceLoader are probably what made this issue more visible and possibly affecting more browsers. But I'm guessing there. —TheDJ (talk • contribs) 14:08, 20 February 2011 (UTC)
I still don't see why you both refuse to change that line back to addOnloadHook, be it for a day or for a week. You did not even try to estimate how many articles are affected right now, instead you just explain how nice everything will work in the future. — AlexSm 14:44, 20 February 2011 (UTC)
Krinkle, I don't mind or know about code, I don't, cannot and will not edit or revert in Commons. I am an editor here, who stubled upon the bug I reported here. Now, I'll repeat it: it did work. The example page in my OP, and the example templates I mentioned here later on, I build and tested and used: as expected. It is getting annoying (to state it friendly) the you keep suggesting that there was "an issue" ot that is was an existing bug; TheDJ suggesting the same. Then, krinkle, you repeat something about "deprecation". Whatever that may be, that is not an argument to introduce breaking code. End of argument. Also, what you call "testing", is now actually in production code here at en.wikipedia.
The procedure is quite simple: it failed in production, so revert. Then there is time to improve & test before reintroduce. -DePiep (talk) 21:34, 20 February 2011 (UTC)
I have tested this, extensively, for weeks. On test.wikipedia, test2.wikipedia, translatewiki.net and (even before all that) on my own wiki server. I have not changed English Wikipedia's Common.js (not Commons ) to "see if it works" or "testing". I changed it so that edgecases are discovered, which, afaik, it didn't reveal (except maybe this thread). Also, not untill now do I read that this problem was made worse by my edit (- addOnloadHook( createNavigationBarToggleButton );   + $( createNavigationBarToggleButton );), if somebody had mentioned so earlier I would have reverted that part of my edit, sorry if I missed that. Anyway, my fix to the sortable-code is now live, so this bug should be dead now. Greetings, Krinkle (talk) 10:47, 21 February 2011 (UTC)
I explained it in this edit and even put it on the left (with no indentation) to make it more visible. Well, doesn't matter now. — AlexSm 19:22, 21 February 2011 (UTC)

 Done The fix for this issue has been deployed. —TheDJ (talk • contribs) 21:35, 20 February 2011 (UTC)

Thank you. -DePiep (talk) 21:37, 20 February 2011 (UTC)
For the record, deployment of the fix is done by Catrope, recorded as rev:82533 - which was originally committed as rev:78893. Krinkle (talk) 10:47, 21 February 2011 (UTC)
Then have that record show my compliments to Catrope too. -DePiep (talk) 11:23, 21 February 2011 (UTC)

Sorting at Template:US executions is now broken for me (clicking sort links leads the browser to jump to the top of the page) on Firefox 3.6.13 for the second and third columns (sorting on the first column works fine). Ucucha 14:40, 21 February 2011 (UTC)

This is related to the use of class='sortbottom' in that table. Ucucha 14:44, 21 February 2011 (UTC)
Cause found bugzilla:27339. —TheDJ (talk • contribs) 15:55, 21 February 2011 (UTC)
Thanks, but the link you gave is to a tracking bug—what is the specific bug report? Ucucha 15:57, 21 February 2011 (UTC)
Lol, sorry about that, bugzilla:27608 —TheDJ (talk • contribs) 16:00, 21 February 2011 (UTC)

I noticed that the problem has been fixed. Many thanks to those who fixed it. Lonelydarksky (暗無天日) contact me (聯絡) 15:35, 25 February 2011 (UTC)

Interface issues

The recent MediaWiki 1.17 release caused a number of problems on my editing interface. By the way, I'm using monobook. First, vertical strip along the left side of the page is unusually shifted down (see screenshot). Can anything in my monobook.js (possibly the script labeled "Personal toolbox - from http://wiki.riteme.site/wiki/User:Brian0918/monobook.js", which appears below the standard links on the left hand side) be modified to fix this? Also, I got the old toolbar (for monobook) back by unclicking the options under "editing" in preferences, but the Wikipedia:RefToolbar 1.0 button shows up on the far left instead of the right. Any code to fix this? Thanks in advance, Goodvac (talk) 04:24, 17 February 2011 (UTC)

Right, I'm using MonoBook too, and the logo on the top left starts off a bit left and then moves right every time I open a new page, which slows down the opening. All Hallow's Wraith (talk) 06:14, 17 February 2011 (UTC)
Just try removing components that you think are problematic. That or using a JS console/debugger is likely the only thing you can do about it. The more work you do to prepare and pinpoint the problem, the less time other admins or myself have to invest to help you. —TheDJ (talk • contribs) 07:25, 17 February 2011 (UTC)
How do I remove compnents I think are problematic? The logo? I can remove that? All Hallow's Wraith (talk) 08:40, 17 February 2011 (UTC)
Yes you can remove the logo but the problem will still persist. My logo is switched off and i'm also having the same problem. Plus all my interwiki links are gone. ќמшמφטтгמtorque 09:55, 21 February 2011 (UTC)

You edit your skin script page, and remove everything. No more userscripts, means no more user scripts messing things up. Then you just copy and past and test till you find what script specifically in our skin script page was causing the problem. —TheDJ (talk • contribs) 17:38, 17 February 2011 (UTC)

I've never touched my skin script page before. What is the code that would make the logo stop moving (or rather show up correctly the first time), and the code that would remove this newfangled grey bar? All Hallow's Wraith (talk) 21:41, 17 February 2011 (UTC)
I found what was causing the problem: User:Omegatron/monobook.js/floatingSidebar.js. Now is there a way to modify that to be compatible with the recent update? Goodvac (talk) 09:34, 19 February 2011 (UTC)
The problem might be caused by the horizontal box at the bottom of any page on monobook, the one with the yellow border containing wikimedia foundation logo on the left, media wiki logo on the right and some info in between. This box is overlapping the floating sidebar. I dont think it was overlapping before this problem arose. ќמшמφטтгמtorque 14:11, 21 February 2011 (UTC)

The floating sidebar script has been fixed. I do notice though that the footer in monobook changed since the update; it now spans all the way to the left, while it used to align with the content. It turns out that is only the case in IE6 and IE7. — Edokter (talk) — 13:45, 25 February 2011 (UTC)

Problem with template:cite doi

Something has gone wrong with this template even though nothing has been done to it today AFAICT. The templates have been made by a bot, for example Template:Cite doi/10.1111.2Fj.1744-7429.2007.00354.x but for some reason a lot of them are not transcluding, as can be seen here. Any idea what this could be caused by? SmartSE (talk) 17:31, 23 February 2011 (UTC)

They are not transcluded because they have not been created yet. Ruslik_Zero 18:52, 23 February 2011 (UTC)
They have been that's what I don't get - the example I gave above exists but is not appearing as reference 9 in the list. {{cite jstor}} which redirects to {{cite doi}} is working fine though which makes it even more strange (see for example ref 2 in the list linked to). SmartSE (talk) 19:03, 23 February 2011 (UTC)
There appears to be a problem with the citation bot expanding cite jstor – see discussion. Rjwilmsi 19:31, 23 February 2011 (UTC)
It was broken by the MediaWiki 1.17 rollout change to urlencode. LeadSongDog come howl! 05:53, 24 February 2011 (UTC)
Should now be fixed.LeadSongDog come howl! 16:44, 25 February 2011 (UTC)

Suppressing day of the week with comments in local time gadget

Resolved

OK, this may sound like a dumb question, but I'm almost completely Java-illiterate, so here goes. I recently started using the Comments in Local Time gadget. Very nice little feature. The conversion to my timezone is great; however, it also adds the day of the week (Monday, Tuesday, etc) to the timestamp, which I don't care for. Is there any way to suppress that, but leave in the yesterday/today bit?--Fyre2387 (talk • contribs) 00:17, 25 February 2011 (UTC)

Doesn't look possible at present, but you could probably ask for a configuration toggle at Wikipedia talk:Comments in Local Time. –xenotalk 00:20, 25 February 2011 (UTC)
I already did it long ago, along with a bunch of other features. See User_talk:Gary_King/comments_in_local_time.js. —UncleDouggie (talk) 01:52, 25 February 2011 (UTC)
Ah. Nice work - perhaps the codebases should be synched and the doc updated. =) –xenotalk 02:05, 25 February 2011 (UTC)
Gary King wasn't interested in a merge after I made the changes. I just rolled in one bug fix from his version into mine. His other recent changes have been cosmetic I believe. —UncleDouggie (talk) 02:45, 25 February 2011 (UTC)
I wouldn't really say that is an absolutely denial of interest, maybe he just forgot to merge the changes in? Given that this is a gadget, it should be subject to good faith improvements. If you make your version of the script completely backwards compatible (so that existing uses do not notice any change in behaviour), I'll merge the changes in. –xenotalk 14:03, 25 February 2011 (UTC)
I have made my version 100% backwards compatible and merged in all updates made by Gary King since I did the fork. Here's the diff from the current gadget baseline. I removed one of the TODO items because I already made that fix as part of my updates. Once the gadget is updated, I will update the documentation to add usage of the new options. —UncleDouggie (talk) 18:09, 25 February 2011 (UTC)
Changed merged in this edit. Revert if any issues pop up. –xenotalk 18:28, 25 February 2011 (UTC)
Documentation update is complete. —UncleDouggie (talk) 20:41, 25 February 2011 (UTC)
Works perfectly, thanks much!--Fyre2387 (talk • contribs) 22:50, 25 February 2011 (UTC)

urldecode

Anyone knows what happened to the urldecode function (it was part of the StringFunctions extension)? urlencode was dropped from the extension since it's a core/built-in function now:

  • {{#urlencode:Hellooo nurse!}} → {{#urlencode:Hellooo nurse!}}
  • {{urlencode:Hellooo nurse!}} → Hellooo+nurse%21
But urldecode has simply vanished:
  • {{#urldecode:Hellooo+nurse%21}} → {{#urldecode:Hellooo+nurse%21}}
  • {{urldecode:Hellooo+nurse%21}} → {{urldecode:Hellooo+nurse%21}}
--Amazeroth (talk) 10:28, 25 February 2011 (UTC)
Stringfunctions was never enabled in Wikipedia, so this could not have worked before. —TheDJ (talk • contribs) 13:25, 25 February 2011 (UTC)
I see, thanks. Yet my question remains: Is there really no urldecode function available at all? --Amazeroth (talk) 13:48, 25 February 2011 (UTC)

"Updating search index" out of order?

Every search result is dated to the 20 February 2011 or older. Is it possible, that somebody check the bot??? THX --Pitlane02 talk 11:21, 25 February 2011 (UTC)

This was also reported yesterday further up the page - anyone got any clues about how to investigate/fix the index updates? Gonzonoir (talk) 15:22, 25 February 2011 (UTC)
This bug is responsible. I've skipped page indexing for those pages last changed between 4:26 and 5:26am UTC on 20 Feb, and it should catch up during today and tomorrow. --rainman (talk) 22:49, 25 February 2011 (UTC)

$.post().complete is not a function

I tried to use .complete() in post but throws error. also i get error if i use $('

').dialog() (not a bug in edit mode) -- Mahir78 (talk) 16:28, 25 February 2011 (UTC)

If I understand jQuery.post correctly, you'll be able to use $.post(...).success with jQuery 1.5, while right now $().jquery shows "1.4.2" here. I think dialog mode is only included in edit mode (with " Enable dialogs for ..." in preferences) intentionally because it has no use otherwise. You could try something like mw.loader.using('ext.wikiEditor.dialogs', your_function) as described at mw:ResourceLoader/Default modules#mediaWiki.loader. P.S. I'm not sure but maybe these questions are better asked at WT:WikiProject User scripts. — AlexSm 19:00, 25 February 2011 (UTC)

New User Edits

That's it - I call shenanigans. I've brought up the issue of new users all creating the same userpage, but no one there seems to know about this. Is this a new software implementation that makes a new editor's first edit to their user page? I cannot believe this is a school project, as it has been going on for the better part of a day. Any insight would be valuable. TNXMan 20:51, 25 February 2011 (UTC)

As I posted there, they may be sleeper accounts, created early and using boilerplate user pages and then used later on when needed. It is very unlikely to have anything to do with the software, considering only about 5% of new accounts have this user page rather than 100% of them. Gary King (talk · scripts) 21:03, 25 February 2011 (UTC)
All of this could be the same person: this sockpuppet blocked today, see his first edit. A userpage makes the user appear as a blue link in recent changes and might get him less attention from some patrollers. — AlexSm 21:20, 25 February 2011 (UTC)
While that person is indeed User:Crouch, Swale, they are Red X Unrelated to other accounts with the same userpage. TNXMan 21:26, 25 February 2011 (UTC)

It is a software feature, please AGF

Just created an alternate account, User:DuncanHillTestAccount. On creation, the first thing you are presented with is a big button saying "now create your userpage". Click it, and it opens the edit box ready filled in with the intro stuff we are seeing on these new userpages. DuncanHill (talk) 21:38, 25 February 2011 (UTC)

Thanks good to know thats interesting. Now if they could just do that for the talk page of articles when they are created! --Kumioko (talk) 21:45, 25 February 2011 (UTC)
So where is it coming from in case we want to update the template? I have a problem with the first item being "Recommendations for your user page". User pages shouldn't be the most important thing we ask new users to deal with. Also, does this mean we need to strip down the welcome templates to remove redundancy? —UncleDouggie (talk) 21:57, 25 February 2011 (UTC)

The announcement was here: Wikipedia:MediaWiki messages#Account creation tests, the system message is MediaWiki:Welcomecreation. — AlexSm 21:54, 25 February 2011 (UTC)

While I'm glad there was an announcement, perhaps next time it would be better to announce it on a more highly watched page. That talk page is watched by 53 people. Perhaps this page or the admin's noticeboard would be a better choice? TNXMan 21:58, 25 February 2011 (UTC)
(ec) A message that nobody sees is not, properly speaking, an "announcement". — Gavia immer (talk) 22:00, 25 February 2011 (UTC)

IPv6

Now, what will Wikipedia do when IPv6 gets deployed?Jasper Deng (talk) 21:45, 25 February 2011 (UTC)

Here are some notes on the transition. Gary King (talk · scripts) 21:49, 25 February 2011 (UTC)

I was told there was no talk page

I created User talk:64.223.114.116 after seeing that the IP's vandalism had been reverted. For some reason, when I saved the edit, instead of the talk page, I got the message that appears when the talk page hasn't been created yet. I think the format was the one used for IPs who can't create articles. Is this a bug? I went back and saved my edit again, and all was fine. Except, after previewing, I had decided to give the IP the benefit of the doubt and somehow my original edit got saved. It turns out the person made the same edit three times with three different IPs, so the second-level warning was not inappropriate.Vchimpanzee · talk · contributions · 22:27, 25 February 2011 (UTC)

When you clicked "Save" and saw "not created" page you just had to reload that page from the server to see your successfull edit. This seems to happen a lot lately. — AlexSm 22:38, 25 February 2011 (UTC)

Wikipedia as a workflow tool

(I don't know if this is the right place for this). I always wondered. Wikipedia is a "Workflow tool" par excellence. A lot of the activities in Wikipedia can be described as process (albeit loose processes). AFD, FAC, RFA... In addition, content pass by different states: Articles can have as state "FAC", "FA", "Nominated for deletion"... However, there's a total abscence of support of workflow by mediawiki software (Actually, I started this post, after noticing how nominating an article for deletion is a daunting task, which can be done in one click given the right tool support). Has there been any discussion, or proposal about evolving the software to support workflow? And if yes, could someone explain, while there hasn't been any progress toward this road (The strategy wiki fails to mention this issue). Thank you --Eklipse (talk) 22:37, 25 February 2011 (UTC)

there are tools for that see WP:TWINKLE ΔT The only constant 22:39, 25 February 2011 (UTC)

More than Twinkle is broken

There are several threads above and numerous comments on the Twinkle talk page that indicate that something changed today that broke a number of tools, including:

This would seem to indicate that the something changed in the core system (pardon me if I have used the wrong term here). Looking at Twinkle activity in particular, it appears that something changed on 23 February between 15:40 and 16:12 (UTC). I noticed some changes in the MediaWiki namespace [[6]} relating to refTools, but the timing appears after-the-fact. I'm not sure what else might have changed.

I think it would be helpful to those looking into these problems if someone in the know (i.e., more knowledge than I) could identify what changed in this timeframe that could event remotely be the cause of such problems. I also think it would be wise to temporarily undo any such changes until a workaround can be developed. Having these anti-vandalism tools off-line is not good for the project. -- Tom N (tcncv) talk/contrib 04:05, 24 February 2011 (UTC)

IDK what caused it (1.17 update?) but I think not using scripts is good for people. We didn't all have cell phones ten years ago and we dealt with it. Manually adding boilerplates takes longer but it prompts me to write a personal message instead—why not, given that I'm already opening up the edit window? /ƒETCHCOMMS/ 04:17, 24 February 2011 (UTC)
For most of us, it's bad, because it gives the vandals a leg up. - The Bushranger One ping only 04:32, 24 February 2011 (UTC)
And if you were a bad a typist as I, I believe you also would have a greater appreciation for these tools. And yes, I often go out of my way to write personalized notes when I find new potentially constructive editors struggling against policy, but when I come across the "Zak's a fag" style edits, I prefer to minimize my effort. BTW, I don't use a cell phone (although I do keep a pay-by-the-minute deal that I keep charged for emergency use). That's about $500/year more toward my retirement. (Grin) -- Tom N (tcncv) talk/contrib 04:44, 24 February 2011 (UTC)
Writing a personalised message to a vandal takes a lot of time, better spent at reverting actual vandalism. The amount of vandalism is so high that we simply don't have the luxury of writing individual messages to vandals. Look at the ANI thread asking for more vandal fighters. Dr.K. λogosπraxis 05:20, 24 February 2011 (UTC)
If you don't want to write a personalized message you could use a warning template from WP:Template messages/User talk namespace#Warnings. Powergate92Talk 05:54, 24 February 2011 (UTC)
Yep. Been there, done that. And multiple times too. Still, I hope you realise the one-button convenience and speed of Twinkle is unmatched compared to manually adding/substituting templates and adding headers. Dr.K. λogosπraxis 06:06, 24 February 2011 (UTC)

Explanation: looks like all of this is caused by developers switching DOCTYPE on all pages to HTML5 doctype (look at the HTML source: it's <!DOCTYPE html> right now), just like it happened in 2009. Btw, all theese tools should have switched to API a long time ago... — AlexSm 04:47, 24 February 2011 (UTC)

Thanks for the info. So what are the chances of them granting a reprieve? And to whom should we make the request? -- Tom N (tcncv) talk/contrib 04:54, 24 February 2011 (UTC)

This has set vandal education back to the stone age. Dr.K. λogosπraxis 05:20, 24 February 2011 (UTC)

Could someone post some guidelines by which we might distinguish the workaday effort of "developers," which screw things up, stop various tools from working, and hamper us volunteers in our efforts to maintain and improve the encyclopedia, from possible malicious actions of hackers which have the same regrettable effects in making everyone's life difficult? Developers untested and capricious "improvements"/malware, tomato/tomahto. I wasted a lot of time just trying to get Twinkle to work to post a vandal warning. Edison (talk) 05:34, 24 February 2011 (UTC)
The workday of a developer? I imagine it's something along the lines of work > work > more work > get complained at > do a bit more work > get complained at some more. Here we have the developers keeping Wikipedia up-to-date and making major improvements to the way in which it "works". And yet people seem to not be capable of even giving them even the smallest amount of gratitude. If a few out-dated scripts break while doing so, it's really something for the script writers to fix (as I'm sure they will). And in the long run it will actually result in better scripts, hopefully using the API as Alex mentioned. There is a reason we have an API... If all programs had been using that all along as they are intended to, then they wouldn't run into problems as that is almost always backwards compatible and rarely changes anyway. - Kingpin13 (talk) 06:37, 24 February 2011 (UTC)
Yes, if the tools had been using the API..., but reality is that some well-established tools don't and these are tools are an important part of anti-vandalism efforts. And while these tools are broken, the RCPs that normally use them are not doing their job, or are doing so in a reduced manner. I do agree that these scripts should be updated to use the API, but this may take a few days or weeks to update and properly test. Now that we know the changes have had an adverse impact (even if not the fault of the developers), I see no harm in asking if the changes can be temporarily rolled back to give the script writers time to adapt and allow the RCPs to continue their work. I don't think a "tango-sierra - they should have known better" approach is the way this should be handled. As for the developers, I have the utmost respect for the work they do and I applaud their efforts at implementing new features and keeping the system updated with improved technologies. My understanding is that, except for a core group, most of them are volunteers too. -- Tom N (tcncv) talk/contrib 07:49, 24 February 2011 (UTC)
Well to be fair they've been aware for years that they should be using the API (e.g. see here), but on the other hand it's not simply a matter of snapping one's fingers and suddenly using the API. I doubt it would be feasible to temporarily revert the update in the meantime, however, there are alternatives to twinkle and other js anti-vandalism tools. For those who are interested, the actual place the tool is breaking is here, on the "var form = doc.getElementById( 'editform' );" line. Also here's a discussion from a while ago which seems to be along the same lines. - Kingpin13 (talk) 08:33, 24 February 2011 (UTC)
Update: User|BarkingFish has posted on the Twinkle talk page that "the HTML5 switch on, has been switched off." UncleDouggie has made extensive changes to the stand-alone ARV tool to switch to the API, and is looking at Twinkle. (Thanks UncleDouggie!) May I suggest that someone with the necessary back-end (toolserver?) access scan userspace for other .js scripts that contain similar not-long-to-live constructs, such as the getElementById('editform') snippet that Kingpin pointed out above. I expect that there may be many scripts out there that have copied the techniques of others, and it would be wise to notify the owners/maintainers that conversion to the API is essential for continued operation. A deadline for compliance can be negotiated with the development team. -- Tom N (tcncv) talk/contrib 14:43, 24 February 2011 (UTC)
Would someone please come up with a temporary fix for this problem? We Wikignomes are pretty useless without these tools. – ukexpat (talk) 14:34, 24 February 2011 (UTC)
Looks like Twinkle is back in business, at least the warning part. Haven't tried all aspects. Favonian (talk) 14:39, 24 February 2011 (UTC)

I have only fixed the warning module so far. I'll try to get CSDs up next, but I'm going to run out of time for today very shortly. More details here. —UncleDouggie (talk) 16:17, 24 February 2011 (UTC)

The RFPP reporting module is not functioning. Message: "Requesting protection of page: The marker that identifies where the protection request is supposed to be added on WP:RFPP could not be found. Aborting" Dr.K. λogosπraxis 03:45, 26 February 2011 (UTC)

Fixed. Someone broke the heading order on WP:RPP. —UncleDouggie (talk) 06:57, 26 February 2011 (UTC)
Thank you. Great job. I'll keep an eye for these headings from now on. Dr.K. λogosπraxis 07:12, 26 February 2011 (UTC)

Jumping page

I have just added a post about half way down this page. Having pressed "save page" the screen shows the post I have added, then, after a few seconds, jumps to a point on the page about 2 or 3 screens lower down. I know there are extremely annoying jumps when the banners appear, but this huge jump leaves me lost. Is this likely to be resolved? or can it be avoided? (IE8 XP Vector if it matters)
Arjayay (talk) 18:13, 24 February 2011 (UTC)

Are you using the gadget to convert timestamps to local time? I did an update to it a few days ago that seems to have helped for me, but it's not 100%. If you don't use that, something else is happening. It's all due to the implementation of ResourceLoader. —UncleDouggie (talk) 20:05, 24 February 2011 (UTC)
No, my local time is UTC (+/- a nanosecond or two) - Arjayay (talk) 08:59, 25 February 2011 (UTC)
This same "jumping" problem is happening to me too, but only on this page. I'm not having the same problem when clicking links to #sub-sections on any article pages. --- Crakkerjakk (talk) 00:23, 25 February 2011 (UTC)
I think it may be because the box at the top of this page is big, and includes a collapsed box for "Frequently Asked Questions (FAQ)". When loading the page, the text appears, then the main box appears, then the full FAQ list appears, before the FAQ list automatically collapses to a "show" box. This seems to give a huge displacement - far more than the line or two of the normal "banner" that appears on most pages.
As previously noted, the banner arrives annoyingly late, so you often end up clicking on the wrong thing, as the page jumps just as you click. The banner and boxes did not cause a jump until the new software, is it an intrinsic fault of the Resource Loader? (It is a major annoyance), or can it be fixed? Arjayay (talk) 08:59, 25 February 2011 (UTC)
I have to amend my previous post that article pages aren't "jumping". Now that I look closely, I see that there is a slight jump when clicking #links to sub-sections on article pages like this #link to the =Operation= section of the Wikipedia page for example, but it's just an inch or so, as opposed to the huge jump here. You can see in that link that the =Operation= section lines up properly at the top of the screen at first, but then jumps down slightly. Part of the huge jump here on the Village pump page may be partly due to the sheer length of the page, as well as the other reasons you've stated, but I just thought I'd mention that there is a slight jump on all pages - it's just a relatively small jump on most article pages, so I didn't notice at first, but it is happening everywhere. --- Crakkerjakk (talk) 10:29, 25 February 2011 (UTC)
There's more information in a prior topic. Is anyone having problems with large jumps on article pages? We know of several culprits for Wikipedia and Talk pages, but there's not much we can do, at least not that we know about yet, given the new ResourceLoader. If someone can figure out the inverted behavior between FF and Safari, it might give us more clues. —UncleDouggie (talk) 06:31, 26 February 2011 (UTC)
I just edited #Gadgets stopped working again. On saving, instead of the section header appearing top of the browser pane, it actually displayed the very bottom of the page, as if I'd pressed the "End" key. The address bar showed the correct http://wiki.riteme.site/wiki/Wikipedia:Village_pump_%28technical%29#Gadgets_stopped_working_again link. Windows XP, Firefox 3.6.13, Monobook. --Redrose64 (talk) 18:15, 26 February 2011 (UTC)
I can replicate Crakkerjakk's problem, and I know what causes it; and the problem is not specific to the Wikipedia#Operation section. It's caused by the collapsible "screenshot" section in the infobox, which is first displayed as uncollapsed, then the CSS kicks in and it collapses. This causes the infobox to get both shorter and narrower: the narrowing lengthens the lines in the lead section, so there are fewer of them; therefore the TOC moves upward a bit, taking the rest of the page with it. Go to Wikipedia and (in Firefox, IE7 Chrome or Opera at least) press F5, observing the effect; try it two or three times. Try the same at Wikipedia#toc as well. --Redrose64 (talk) 18:28, 26 February 2011 (UTC)
You're absolutely right. See my detailed testing. —UncleDouggie (talk) 23:38, 26 February 2011 (UTC)

Might as well bring the discussion back to this section where it belongs now that we have a better idea what's going on. Here's a summary of my tests following a null edit half way down this page:

  • FF 3.6.13: Sometimes briefly flashes the the correct section, jumps several screens down the page for about 3 seconds, then jumps back to the correct section, but only if you don't scroll the mouse in the meantime.
  • FF 4.0b12: Jumps to the start of the page for 3 seconds, then jumps to a point several screens past the correct section, but only for about 0.5 seconds, then jumps to the correct section. Overall, this version of FF is much faster than 4.0b11 and light years ahead of 3.6.13. I can't believe how responsive all of Wikipedia has become. It seems like this will solve many of our problems because JavaScript loads and runs so much fater as well.
  • Opera 11.01: Jumps to the start of the page for 3 seconds, then does two jumps to strange points on the page that are fully displayed but for long enough to really tell where they are, then jumps to a point several screens down from the correct section. Never gets to the correct section at all, unless it was one of those fast jumps. Overall, it's fast but it feels erratic with the jumping all over the place.
  • Safari 5.03: Jumps to the start of the page for 3 seconds, then jumps to the correct section for 2 seconds, then jumps back a partial page.
  • Chrome 9.0.597.102: Award for the longest version number. Same behavior as Safari, which isn't surprising since they have the same engine.

Conclusion: Use FF 4.0b12. —UncleDouggie (talk) 06:08, 27 February 2011 (UTC)

I would like to revisit this issue. #What Links Here, as absolutely nothing has been resolved since the problem arose on February 19. The job queue page says it will expand templates. The failure of expansion of the County municipality navbox templates is exactly the issue. Previously, if I created a new municipality page and included the template, the template would automatically expand in "What Links Here" by the time I had finished editing. That failed to happen with Quihi, Texas and Estacado, Texas. 6 days later, the only expansion on those specific ones, are where I did null edits on a few of the template municipalities. The remainder of those two templates remain unexpanded. This kink now seems the rule, not the exception. I had the same issue when I set up Click, Llano County, Texas - the municipality navbox template did not expand. To get around it, I did the null edits on every single municipality within the template. But an editor should not have to do that every time. Something changed inbetween February 19 and February 13, when I set up a new page where a template automatically expanded. I believe the new software happened in that time frame. Maile66 (talk) 13:15, 25 February 2011 (UTC)

I think the job queue's broken. This would be consistent with one of the topics in a thread which I recently raised at Help talk:Job queue#Where's it gone?. --Redrose64 (talk) 15:20, 25 February 2011 (UTC)
Hmmmmm....interesting how on the Help talk:Job queue, there's very seldom a reply to any issue posted. All the way back to 2009. Maile66 (talk) 16:11, 25 February 2011 (UTC)
It seems that the job handlers had been down for a couple of days. http://wikitech.wikimedia.org/view/Server_admin_log "2:36 apergos: job queue reported slower than molasses, checked the job runners and there was one host running something. I did not restart the job runners though because the package has not been updated for 1.17 and was using the pre-1.17 deployment codebase. woops." Follow bugzilla:27727 for the progress. —TheDJ (talk • contribs) 14:30, 26 February 2011 (UTC)
Thanks for your help on this. Maile66 (talk) 23:51, 26 February 2011 (UTC)

Reference formatting change?

Why did we need to change cite.php to use letters instead of numbers? Such a change messes up formatting for many notes, such as seen in St. Anthony's Catholic Church (Padua, Ohio) — unlike when numbers were used for <ref> citations, you can't easily distinguish the content comment (following the first occurrence of "Padua" in the text) from one of the citations to the first reference. Nyttend (talk) 15:00, 25 February 2011 (UTC)

A mistake surely The inline cites are lettered and the references numnbered. Thincat (talk) 15:06, 25 February 2011 (UTC)

((edit conflict))

This is what I mean...

Okay, I've only just realised this, but apparently inline citations using <ref> now result in letters being displayed, sort of like this[a] when it used to be like this.[2] I don't really like the change, but what the hell, I can live with it. However, when using {{reflist}} to display the references, they still display with numbers to refer to the citations, even though the inline bits are now letters. So either the change to the inline citations needs to be reverted, or reflist and associated templates need updating. And can anyone please enlighten me on when this change was made? Thanks. Strange Passerby (talk • contribs • Editor review) 15:07, 25 February 2011 (UTC)

I just noticed the change as well. Anyone know where this was discussed / if it was discussed? Jujutacular talk 15:12, 25 February 2011 (UTC)
It's back to normal now. --Redrose64 (talk) 15:12, 25 February 2011 (UTC)
Indeed. I'd really like to know where the actual change was implemented (for my own curiosity). Jujutacular talk 15:14, 25 February 2011 (UTC)
Weirdly, it seems to be so on some pages but not all – Sam Oldham, seen in my screenshot above, still shows the letter format of cites, while another of "my" articles, List of 1952 Winter Olympics medal winners, appears to show numbers for cites... Strange Passerby (talk • contribs • Editor review) 15:15, 25 February 2011 (UTC)
I see numbers on Sam Oldham. Try WP:BYPASS, failing that, WP:PURGE. --Redrose64 (talk) 15:17, 25 February 2011 (UTC)
Good idea; purging worked. Although like Jujutacular I'd like to know where and why it was changed... Strange Passerby (talk • contribs • Editor review) 15:20, 25 February 2011 (UTC)
This is my fault. I was working on the feature described below and the documentation in bugzilla was sketchy. It looks like MediaWiki:Cite link label group- changes the default labels for all in-text cite links, nut just the "footnote" group as I was lead to believe. ---— Gadget850 (Ed) talk 15:56, 25 February 2011 (UTC)
Added an editnotice to reduce the chances of my gaff being repeated. ---— Gadget850 (Ed) talk 16:00, 26 February 2011 (UTC)
Weird. That page (since moved to MediaWiki:Cite link label group-footnote) doesn't seem to be part of the list of system messages. — Edokter (talk) — 16:33, 25 February 2011 (UTC)
Now at @alpha per discussion below. ---— Gadget850 (Ed) talk 16:00, 26 February 2011 (UTC)
How is AllMessages populated? MediaWiki:Cite link label group pages are not defined by default. ---— Gadget850 (Ed) talk 16:40, 25 February 2011 (UTC)

Notes

The Sun is pretty big,[@alpha 1] but the Moon is not so big.[@alpha 2] The Sun is also quite hot.[@alpha 3]

Notes
  1. ^ Miller, E: The Sun, page 23. Academic Press, 2005.
  2. ^ Brown, R: "Size of the Moon", Scientific American, 51(78):46
  3. ^ Miller, E: The Sun, page 34. Academic Press, 2005.

Full documentation is currently at Wikipedia:Manual of Style (footnotes)/Cite link labels.

To do:

  • Decide how to use this within the context of footnotes
  • Need someone to check MediaWiki:Cite link label group-@greek (only admins can edit these)
  • Decide if "footnote" is an appropriate name for the alpha default
  • Decide if the footnote group currently at MediaWiki:cite_link_label_group-@alpha should be lower, upper or mixed; we can create all if needed
  • Tweak documentation as needed and merge into the main

Technical stuff that I will deal with

  • Create a help page for the error message— started at Help:Cite errors/Cite error no link label group
  • Update the error message to link to the error page— Can't use a wikilink as the error message is classed as a reference
  • Link the error message talk page to the central page— done

---— Gadget850 (Ed) talk 15:39, 25 February 2011 (UTC)

First of all, is this related to the above thread? (i.e. every citation on every page was appearing as letters for about 15 minutes). Second: the reference at the bottom of the page needs to be the same format as the citation above. It is quite confusing to follow a letter citation to a numeric reference. Jujutacular talk 15:50, 25 February 2011 (UTC)
Yes— my fault. It should clear up quickly. ---— Gadget850 (Ed) talk 15:58, 25 February 2011 (UTC)
The reference list is an ordered list and uses numbers that don't match the in-text cite labels. Added to T24265. ---— Gadget850 (Ed) talk 18:34, 25 February 2011 (UTC)

<3 --Golbez (talk) 22:49, 25 February 2011 (UTC)

A couple of things:
  1. I don't think that footnote is an appropriate name for a special-case usage such as this — ditto for all similarly normal-seeming names. There's too much chance of that name being used by an editor expecting it to work as a normal (i.e. not special-case) group name. Also, special-case group names defined at some distant-future point (e.g. greek, crylic) risk breaking articles which used those names as normal group names before they (suddenly and, to many editors, mysteriously) begin behaving in a special-case fashion. One solution might be to adopt a naming convention for this class of special-case group names and deprecate those names by convention for normal plain-vanilla group name usage. One convention which seems workable would be to require group names for this special-case usage to begin with commercial-at character (e.g., @footnote and @greek).
  2. One useful application which I see for this is footnoting tables using the familiar cite-php <Ref ... method rather than the more complicated WP:Footnote3 method. However, I would expect that there would be some articles having multiple tables needing footnotes. As I understand it, this could be dealt with by creating some number of available groups using the same footnoting characters (e.g., group=@footnote1, group=@footnote2, etc., all identical to the exampled footnote group), but I wonder if this could somehow be done without requiring an admin to step in to create, say, the next five groups when the ones then existing aren't enough for some article. Perhaps a special-case suffix could cause reuse of a base group (that is, have a group named @footnote which picks the footnote numbering characters, and which could be reused by specifying group names like group=@footnote#1, group=@footnote#2, etc.).
I hope I've explained that in an understandable manner. It'll read like gibberish to some, but I'm guessing that it'll be clear to Gadget50 (Ed). Wtmitchell (talk) (earlier Boracay Bill) 07:08, 26 February 2011 (UTC)
I had been pondering the naming scheme and using @ makes sense if it is allowed in the MediaWiki namespace (I will find out). As to point 2: this should not be an issue. When you use any parameter within {{reflist}} or <references>...</references> then it closes the reference list, and the use of |group= will certainly do this. Thus the references from one table will not get stuffed into the reference list for another. ---— Gadget850 (Ed) talk 15:05, 26 February 2011 (UTC)
Changed the existing groups to @alpha and @greek. I am going to add table examples to the doc page. Added @numeric. Example:
05/08 4266 7828 7282[@numeric 1] 1105 224[@numeric 1] 161 916 [@numeric 1] 506 231 4127 6190 6487[@numeric 1] 1139 241 205 1165 478 301
04/08 4127 6190 6487 1139 241 205 1165[@numeric 1] 478 301[@numeric 1] 4266 7828 7282 1105[@numeric 1] 224 161 916[@numeric 1] 506 231
  1. ^ a b c d e f g h Elk, Anne (November 16, 1972). Anne Elk's Theory on Brontosauruses.

Gadgets stopped working again / Page jumping

My gadgets have stopped working again (clock/purge, popups, blackscreen) also the predictive search thing has stopped. They do work when I'm in the edit screen. DuncanHill (talk) 23:52, 25 February 2011 (UTC)

What browser/version are you using? Have you tried purging your cache? {{Nihiltres|talk|edits|⚡}} 01:16, 26 February 2011 (UTC)
Monobook, Chrome, WinXP. Will give that a try. DuncanHill (talk) 01:18, 26 February 2011 (UTC)
Purging seems to have fixed it for now, but it is happening very often since the "up"grade. DuncanHill (talk) 01:22, 26 February 2011 (UTC)
Ditto. If even happens after not just purging, but restarting the computer. In fact, it tends to happen there more frequently, at least for me with Safari on a Mac. As far as a non-technical person like me can tell, it's the slow loading of Javascript. DGG ( talk ) 02:54, 26 February 2011 (UTC)
I'm on Safari on a Mac, and I haven't seen a problem like this at all yet… {{Nihiltres|talk|edits|⚡}} 03:09, 26 February 2011 (UTC)
Clearing your cache will most likely resolve this, from how you guys have explained it. Restarting your computer or browser shouldn't change anything, though. It does seem to sound like perhaps that the JavaScript is taking too long to load. Since 1.17, JS is loaded after the page rather than before, which allows the page to load and then the browser loads the JS, which is why you might be viewing a page with no JS functionality enabled—because it's still loading. I suppose that's better than staring at a blank page waiting for the JS to load first, though. Gary King (talk · scripts) 04:44, 26 February 2011 (UTC)
Purging your cache should in theory make this worse because all the scripts have to be completely reloaded from the server. When I purge, it takes an extra 5 to 10 seconds for my scripts to run. So why is purging helping in this case? There must be something we don't understand here. By the way, my purges were all for debugging purposes, I haven't actually seen this problem since we escaped the HTML 5 black hole. —UncleDouggie (talk) 05:54, 26 February 2011 (UTC)
JavaScript does seem to be making Wikipedia browsing very slow recently. I just turned it off altogether and it makes such a difference, that I'm half tempted to leave it off for Wikipedia, even though it ruins the display of a number of things. - Kingpin13 (talk) 06:23, 26 February 2011 (UTC)
I don't see RefTools when I'm editing, maybe all the gadgets are failing for me? I'm on Safari/Mac. Tried emptying cache, no change. First Light (talk) 07:02, 26 February 2011 (UTC)
Purging works for me most of the time, anyhow. I suppose that's mostly after I edit a script, though, so purging works well since it reloads everything from scratch. It only needs to be done once, and yes it takes longer to load, but at least the scripts do eventually load. JavaScript then loads faster after that, as it should. Gary King (talk · scripts) 17:34, 26 February 2011 (UTC)
I have two gadgets set:
  • Add a "Purge" tab to the top of the page, which purges the page's cache when followed.
  • Add an [edit] link for the lead section of a page
I've not yet come across a situation when I wanted to go for "*" (purge) only to find that it was missing, but sometimes the lead section [edit] link doesn't appear: pressing F5 to reload the page causes it to show, and I've not needed to use any methods more drastic than that. Windows XP, Firefox 3.6.13, Monobook. --Redrose64 (talk) 18:07, 26 February 2011 (UTC)
It sounds like FF sometimes isn't getting a response from the server on the load of your last script. This could be load related or a bug in ResourceLoader. It might be useful for you to install the Firebug add-on, but you would need to keep firebug open in a background window until the problem occurs so you can see what got loaded without first needing to let Firebug do it's own reload. I'm not positive, but perhaps you will see an entry for the script in the Firebug script list, but there won't be any content when you select it. I haven't personally used Firebug for this purpose before, so perhaps others have some thoughts. —UncleDouggie (talk) 22:47, 26 February 2011 (UTC)
Yikes, it just jumped to the end of the window on me when I saved the last change, just as you reported down in another thread. I'm doing this edit with Firebug running to see if I can repeat it. —UncleDouggie (talk) 22:50, 26 February 2011 (UTC)
The JS loading sequence (and speed) does seem relevant--it first loads as it would without the javascript gadgets, and then redraws the page with them. This is very disconcerting. DGG ( talk ) 22:54, 26 February 2011 (UTC)
That time I made sure not to touch anything after clicking Save. It reloaded the page, jumped to the very end of the window, and 3 seconds later jumped back to this section. The previous time I probably scrolled the mouse while it was at the end of the window, which may have canceled the jump back to here. My guess is that this sequence has always happened, but prior to ResourceLoader the display of the end of the page was hidden from us and therefore immune to the jump back being canceled by hitting the mouse. Trying it again now... —UncleDouggie (talk) 22:56, 26 February 2011 (UTC)
This time it initially showed the proper section, which may have been from cache it was so fast, jumped to the end a few seconds later, I scrolled the mouse slightly, and it didn't jump back. —UncleDouggie (talk) 22:58, 26 February 2011 (UTC)
Jumped to end, I moved my mouse without scrolling, and it jumped back to this section. BTW, FF 3.6.13, OS X 10.6.6, but I have just about every platform if needed. —UncleDouggie (talk) 23:01, 26 February 2011 (UTC)

More clues. When I edit a section 15% of the way down this page, it jumps the equivalent of 0.75 screens in my window and then returns to the correct location if I don't scroll the mouse. The text portion of my window is currently 9.5 inches. When I edit a section 50% of the way down the page, it jumps 2.25 screens. When I make an edit 75% of the way down the page, it jumps by 3.5 screen. When I edit this section, near the end of the page, it jumps by a full 4 screens, which is all the way to the end of the page in my case. Conclusion: The amount of the jump is directly proportional to the location of the section being edited. Next question: Is the jump dependent on the total length of the page or just the relative position? —UncleDouggie (talk) 23:19, 26 February 2011 (UTC)

A null edit to archive 85 of this page, done 50% of the way down a 60 screen page, caused a jump of only 0.75 screens. 25% of the way down that page is a collapsed box that is 1 screen tall. I don't understand the 0.75 vs. 1.0, but I'm going to overlook that for now. On this page, the FAQ fully expanded is 0.75 screens tall, exactly equal to the jump I observed with my 15% edit. There is another collapsed box 1.5 screens tall before the page midpoint, which explains the 2.25 screen jump. And yet another one 1.25 screens tall to explain the 3.5 screen jump. I didn't see anything else to explain the 4 screen jump, but there's enough of a pattern here to conclude that the jumps are all caused by collapsed elements. And there's probably not a damn thing we can do about it in a ReourceLoader world, short of getting the devs to move the CSS back up to the top. —UncleDouggie (talk) 23:34, 26 February 2011 (UTC)

Tests with Safari 5.0.3: Following an edit, it first shows the very top of the page for 3 seconds, then jumps to the correct section, and finally it usually backs up some amount. Editing 15% of the way down, there was no visible jump back, but the screen did a very fast refresh, almost like a glitch where it normally jumps back. Editing 50% of the way down this page, the jump back was 0.17 screens. Editing 85% of the way down, the jump back was 0.25 screens. Very different behavior from FF 3.6.13. It will probably be different in every browser we try. —UncleDouggie (talk) 23:59, 26 February 2011 (UTC)

UncleDouggie: please stop making tests edits to this page. First, real null edits (which are not the edits you're making) would be enough because they show the same behavior. Second, if you do need to make test edits please to in on your own subpage. — AlexSm 00:04, 27 February 2011 (UTC)
Sorry, I used the wrong term. They were dummy edits and I did a preview on each one to verify that there was no change, including to the line spacing. Nevertheless, I have reverted the whole batch out of the utmost caution. <eggonface>It turns out that a true null edit does the exact same jumping! I didn't even think to try it because I figured that loading the new version of the page was somehow causing the problem.</eggonface> While I normally do test in my own userspace, there seemed to be something special about this page that wasn't as predictable elsewhere, although with the benefit of hindsight it is possible to reproduce the failure. —UncleDouggie (talk) 01:09, 27 February 2011 (UTC)

Value #expr: 1.2.3.4.5.00 is 1.2

Are there any plans to change parser function #expr to treat multiple dots as being an invalid number? Currently, the value of 1.2.3.4.5.00 in wiki-math is:

{{#expr: 1.2.3.4.5.00}} → 1.2
{{#expr: 1.2.3.4 + 100}} → 101.2
{{#expr: 1.2.3,4.5.00}} → Expression error: Unrecognized punctuation character ",".

I was thinking 1.2.3.4 might generate an "expression error" because I was planning to detect a European million "1.000.000" (#expr value 1.0) as invalid, to be reformatted as "1,000,000". However, I realize "one man's bug is another man's neat feature" and we often use bizarre MediaWiki bugs to create kludge features all the time, to provide faster results for our readers. Perhaps someone already treats a numeric date "2.26.2011" as 2.26, so they might think dropping ".2011" is a neat feature of #expr. Meanwhile, we have Template:Valid to check if numbers are valid:

{{Valid| number= --12345.00}} → false {{Valid| number= 12345.00 }} → true
{{Valid| number=1.2.3.4.5.00}} → false {{Valid| number=1.000.000}} → false

So, {Valid} realizes the number is invalid, and I could use similar logic to detect "1.000.000" for reformatting. There's no hurry on this, just curious. -Wikid77 08:30, 26 February 2011 (UTC)

Page layout problems

Hi, in http://wiki.riteme.site/w/index.php?title=South_Georgia_and_the_South_Sandwich_Islands&oldid=415969089 I see a large blank space breaking the lead section (specifcally, between "The total land area of the territory is 3,903 square kilometres (1,507 sq mi)" and "There is no native population on any of the islands" is a whole screen's worth of blank space). I know that the alignment of text with picture is what's causing it, and I know various things to try that will fix it. The puzzle is that I see problems very similar to this over and over and over again in many different Wikipedia articles -- I mean, like hundreds of times -- often (though not in this case) that have gone uncorrected for a long time. I think I asked about this one before, and it was suggested that different browsers lay out the page differently, so that many people did not see the problem. However, my recollection is a bit hazy. What I would like to do is establish again whether this problem is browser specific. I am using IE 8. Could others take a look in different browsers and report what they see? 86.176.210.29 (talk) 12:59, 26 February 2011 (UTC)

There is no gap in Firefox 3.6.13, Google Chrome 9 or Opera 11.01, but in IE7 the gap is there. Specifically, since the image File:South Georgia Photo by Sascha Grabow.jpg is right aligned, it is pushed down the page by the infobox. The paragraph beginning "There is no native population on any of the islands" is in the wikicode just after this image, and IE insists on vertically-aligning that text with the upper edge of the image, so the gap occirs immediately before this. The easiest fix is to align that image left instead of right. --Redrose64 (talk) 13:25, 26 February 2011 (UTC)
Thanks. I would like to propose that this problem is investigated further by the technical guys to see whether Wikipedia's code generation can be tweaked so that all common browsers display the same thing in such cases. My guess is that in many cases that I've encountered, the person who made the edit was using a non-IE browser and had no idea that it broke the layout in IE. This is probably why such layout errors are so common. 86.176.210.29 (talk) 14:05, 26 February 2011 (UTC)
  • Major typesetting problem: I will write a short essay "WP:Avoiding text gaps" to help people be aware of the text-gap problems and ways to avoid them. This is very frustrating because "all" IE browsers (at least from IE6 to IE8) show a large text-gap beside nearby non-stacked images, on wider windows. Plus, some people deliberately use CSS options which cause those large, awkward text-gaps, deliberately ignoring (yes) the trashy affect on IE browsers. If an image-box were set to float around the text, then the images would tend to amass into a page-wide gallery, so that is only a partial solution. However, using {{floatbox|image}} might be a very quick fix when adjusting only 1 image. For that article ("South Sandwich Islands"), I used "|thumb|left" followed by word-joining {{j|There is no}} to no-wrap that phrase for avoiding 1-word-per-line wrapping after a left-side image on narrow windows. I agree that the problem appears in hundreds of articles, and is probably the most trashy typesetting glitch for readers using IE: those large text-gaps make Wikipedia seem extremely unstable on IE browsers. -Wikid77 15:33, 26 February 2011 (UTC)

Too small font in secure server while using Mozilla Firefox

I'm experiencing shrinked font-size in secure server in Mozilla Firefox 3.6.13. This issue does not happen in my Internet Explorer 8. Is there any problem in my browser or server, or MediaWiki CSS? It happens Korean Wikipedia, Wikimedia Meta-Wiki, Wikimedia Commons as well as English language Wikipedia. Best regards. Kwj2772 (talk) 14:11, 26 February 2011 (UTC)

You probably (accidentally) set your font-size in Mozilla with (ctrl-scrollwheel). Mozilla remembers fontsize settings per site. Simply reset to 100% while you are on the secure server. — Edokter (talk) — 15:36, 26 February 2011 (UTC)
That works. Thanks! Kwj2772 (talk) 15:51, 26 February 2011 (UTC)

Plan to reduce Template:Convert

11-Feb-2011: The essay about redesigning Template:Convert, to use condensed subtemplates, rather than 3,400 (of 24,000 needed) is titled "WP:A plan to reduce Convert subtemplates".
Currently, {Convert} is a vast contraption, so immensely huge that no single person really understands all of it, and parts of Convert are used (incorrectly) deep in the innards of some other templates, but never used directly by people writing articles. Hence, the improvements to Convert are chasing a moving target, of over 15 types or sub-families of conversion formats.
The redesigned, extended prototype has suffix "-x" as Template:Convertx which would allow comma=in, comma=out, comma=off, and other new features:

  • {{convertx|9,250|km|mi|comma=in}} → {{convertx|9,250|km|mi|comma=in}}
  • {{convertx|9,250|km|mi|comma=out}} → {{convertx|9,250|km|mi|comma=out}}

The only hope is this hybrid approach which "morphs" the current Convert subtemplates into updated forms, which allow passing new parameters to handle the new options. Essentially, each unit (such as: ft, m, km, sqft, oz-f) would choose between the new or old style of processing conversions. Unused units would not change (because who cares). The performance overhead is perhaps 5 levels lower for the expansion depth, but about 100 bytes more in post-expand size, for the new features, such as Convert using 300 bytes when Convertx would use 400 bytes of post-expand size. -Wikid77 05:46, 11 February 2011 (UTC)

"Comma in" and "comma out" contradict everything about proper number formatting and WP:MOSNUM. If you want to write 9250 km, then you need to write 5720 mi. Mixing styles is not appropriate. Headbomb {talk / contribs / physics / books} 06:05, 11 February 2011 (UTC)
Yes, I think mixing of styles was requested by people wanting to put direct quotes from some ignorant imbecile like Isaac Newton, or Max Planck, or Albert Einstein, who only spoke 5 languages, and did not understand the life-critical importance of using commas. Those guys never did anything more than develop reflector telescopes, or Planck's law, or relativity theories (E=mc^2). There's even talk of how they wrote unformatted equations, by hand, without using the Unicode &minus! Perhaps if WP:MOSNUM had existed centuries ago, then those guys could have been stopped, most certainly, before they became notable. -Wikid77 13:18, 11 February 2011 (UTC)
Yeah, and if you want to quote them verbatim, you don't need convert templates, because I doubt Newton et al. wrote things like "A sphere of {{convertx|9,250|km|mi|comma=in}}, ...". If an editorial note, parentheses should not be used for this, but rather square brackets. "A sphere of 9250nbsp;km [5,750nbsp;mi / 5750 mi], ..." And take that crass attitude of yours elsewhere. Headbomb {talk / contribs / physics / books} 15:06, 11 February 2011 (UTC)
  • Sorry, I thought the joke was obvious, but I should have said how Template:Convert, for years, has been used inside direct quotations, with equivalent amounts in editorial brackets "[ ]" despite no commas in the quoted text. -Wikid77 14:12, 14 February 2011 (UTC)
This outburst is not helpful to your cause, and I think you know it. You should be encouraging people to focus on the issue at hand, not encouraging them to follow you down a tangent. Happy‑melon 13:57, 11 February 2011 (UTC)
I guess I forgot how some people dislike jokes about WP:MOS. Perhaps I should have said that Convert supports conversions going back over 3,000 years ago, with or without commas in their stone carvings. -Wikid77 14:12, 14 February 2011 (UTC)
Any plans on using the convert extension mentioned in Wikipedia:Wikipedia Signpost/2011-01-31/Technology report? -- WOSlinker (talk) 13:24, 11 February 2011 (UTC)
I was planning on starting a discussion about that soon on Template talk:Convert, but there are a few more features I wanted to implement and stabilise in it [the extension] first. Happy‑melon 13:57, 11 February 2011 (UTC)
  • Template:Convert currently allows dynamic definition of thousands, and thousands, of new units (within a few minutes each), depending on which measurement units are used in each culture, as described in millions of articles of the other-language Wikipedias. We recently added the famous Egyptian cubit, and also added the French arpent (there are other arpents, both linear and square), due to widespread use in French colonial culture. Google estimates 143 million webpages about the word "measurement", but Convert also handles calendar dates, gun-barrel calibre, and musical notes, so we had to make Convert be a highly dynamic system, to allow users to add new units every hour of the day, and convert the words, not just numbers. Reality is so much more complex than just a list of 400 or 900 commonly used units. -Wikid77 14:12, 14 February 2011 (UTC)
  • When reducing the internal structure of Convert, then some new features will also be added. For example, numbers will be displayed up to whole billions, with end-zeroes, to allow showing $billions of dollars, but then use scientific notation for larger amounts. For example, converting billions of dollars-per-pound:
• {{convert|32,000,000,000|$/lb}} → $32,000,000,000 per pound ($7.1×1010/kg)*
Adding new features, while reducing the structure, will take full advantage of changing the fully-protected subtemplates in Convert, to test both the reduction of old subtemplate structures, as well as adding the new features, at the same time. -Wikid77 17:50, 18 February 2011 (UTC)

Somebody should write an extension/parser-function for converting units. 68.69.54.2 (talk) 18:14, 21 February 2011 (UTC)

  • That is like saying someone should write a parser-function to check spelling in 250 languages: some misspellings are valid words in other languages, and there are always new words to be added. Using parser-functions can only solve small parts of the conversion issues, such as calculating the raw numbers, determining the input precision, rounding to have end-zeros ("00"), formatting fractions (1 15⁄32), and inserting decimal point or decimal comma (as done now by using {{formatnum:4300.65}} in each other-language wikipedia). Meanwhile, Wikipedia must make preparations for more rare engineering measurements, or comprehensive historical articles, where rare units are used many times. Hence, the biggest problem has been to simplify adding hundreds of new unit names, such as cubit or arpent or scruple (20 grains), where typical users could easily set the conversion formula for a new unit. Currently, there are numerous problems in other wikipedias, such as French Wikipedia, with a wrong formula, wrong spelling, and incorrect wikilink for gram-to-pound (gramme à livre):
        • WAS: {{fr:Modèle:Conversion|454|g|lb}} → 454 grams (205 930,93598 livre |lb)
        • NOW: {{fr:Modèle:Conversion|454|g|lb|2}} → 454 grammes (1 lb)
    The French spelling should be "454 grammes" and the incorrect formula caused it to miss 454 g is actually "1 lb" (not 205,930.9...). To avoid all those numerous problems, the English Wikipedia has used a "brilliantly ingenious" system of dynamic templates (since October 2007), allowing any user to add a new unit (as just 1 subtemplate), and set the formula, spelling and wikilinks in just one spot, rather than sleuthing the other formulas and logic needed to interface a new unit with older units. A new unit can be added, live, into English Wikipedia without affecting the prior 2 million conversions already in other articles. By comparison, some wikipedias must typically modify many parts of their template structure, such as 15 places to add a new unit into French Wikipedia's template "Modèle:Conversion" to handle "gramme" (hence explaining why the French WP template still has errors in some of those 15 parts). More later.
    UPDATE: I have fixed the French template (fr:Modèle:Conversion) for grammes, livres, onces (pounds & ounces), but then an admin fully-protected the template, thwarting the correction of spelling as "mètre" or other problems. -Wikid77 14:55, 23 February 2011, revised 12:02, 27 February 2011 (UTC)

Search index not being updated?

It seems that the index for the search function is about three days behind what's in the articles, and not gaining any ground at all. Does the operator who monitors the index updating ever read this page? My pathetic little WikiGnome activities really start to bog down when this happens. Chris the speller (talk) 00:28, 24 February 2011 (UTC)

Raised the same thing at WP:Help_desk#Search_Index it's feast or famine, we'll get swamped when it does update.
Arjayay (talk) 17:54, 24 February 2011 (UTC)
I also asked on the Help Desk if there a way to arrange search results in order?
I use the search index to find mis-spellings, but some are "correct" being redirects, quotes, deliberate, or part of File or URL names e.g. "rythm" which currently has 56 "correct" mis-spellings. When a search returns 57, finding the extra one is labourious. If they could be ordered according to date of last revision, the new entry would be at or near the end.
Arjayay (talk) 18:04, 24 February 2011 (UTC)
The stinkin' updater appears to be rolling again, though it will probably take a day or two to catch up. Chris the speller (talk) 13:54, 26 February 2011 (UTC)

Well, it didn't get very far, after all. Maybe an operator will take notice (and take pity) if we throw a limerick or two in here:

The updater of searches is fickle;
Its output is down to a trickle.
Hey, I'm working for free,
And I'm sad as can be.
This WikiGnome's still in a pickle.

Chris the speller (talk) 05:57, 27 February 2011 (UTC)

What do you mean by "didn't get very far"? The index is updated every morning, and as far as I see all edits from yesterday (in UTC time) are properly indexed.--rainman (talk) 11:43, 27 February 2011 (UTC)
Yes, now it looks like everything got indexed, but the index was at least three days behind at the time I posted the limerick. Almost six hours had passed by the time you checked it. Looks like poetry did the trick. Chris the speller (talk) 15:10, 27 February 2011 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_86&oldid=1147981579"