Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (How to report a bug). Bugs with security implications should be reported to securitywikimedia.org.

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

« Archives, 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

Gadget for opening search results and suggestions in new tabs

I propose a gadget (in preferences) for opening search results and suggestions in new tabs. I suggest basing it on the JavaScript found here:

• commons:MediaWiki:Search-results-new-tab.js

It works great on both Wikipedia and the Commons. For implementation and more info read the talk page here:

• commons:MediaWiki talk:Search-results-new-tab.js

I also proposed this here:

• Wikipedia:Gadget/proposals#Open search results and suggestions in new tabs - but that page does not seem very active. --Timeshifter (talk) 10:10, 12 April 2012 (UTC)

I started this Bugzilla thread: "Bug 35974 - Preference to open search results and suggestions in new tab".

https://bugzilla.wikimedia.org/show_bug.cgi?id=35974

But that may take a long time. Is there any reason this can't be implemented as a gadget now on English Wikipedia? Many people want it. --Timeshifter (talk) 16:23, 14 April 2012 (UTC)

Advanced search link in sidebar

Putting an "advanced search" (Special:search) link in the sidebar would fix the problem too. People could right-click it to open it in a new tab. Most readers do not know much about how to find stuff on Wikipedia. They try the search form, but soon see that it covers up the page they are looking at. Many people stop using the search form after that, and use Google Toolbar instead for site searches.

But Google Toolbar does not allow one to pick and choose namespaces to search. Special:search does do this. Also, Google no longer makes Google Toolbar for Firefox. So, putting an "advanced search" link in the sidebar would solve many problems. --Timeshifter (talk) 05:35, 23 April 2012 (UTC)

Search link to drop-down menu at top

In preferences there is a gadget (in the appearances section of the gadget tab) called "Add page and user options to drop-down menus on the toolbar." The search link could go there in the drop-down menu. That may be the simplest way to get searches done in a new tab. Also, it does not take up any valuable real estate in the sidebar or at the top. Any thoughts? --Timeshifter (talk) 14:48, 29 April 2012 (UTC)

where did the full-size reference option go?

We used to have a distinction between {{Reflist}}, which displayed notes in small print, and <references/>, which displayed them full size. The latter was useful for footnotes where we didn't want the reader to have to deal with small print. However, the two displays now look the same to me. Is there a reason that they are now apparently redundant? And what can we do where we don't want small print?

Thanks — kwami (talk) 20:45, 17 April 2012 (UTC)

Guessing maybe the change was made because footnotes in print are usually all small? I don't know though. You could use <span style="font-size:115%;"><references /></span> to make them bigger. Equazcion ^(talk) 20:58, 17 Apr 2012 (UTC)

<references /> was styled to the same size as {{reflist}} in December 2010 after a proposal was supported. I am not aware of any other template that used any other size. If you don't like the smaller font, then you can set a personal style with Preferences → Gadgets → Disable smaller font sizes of elements such as Infoboxes, Navboxes and References lists. ---— Gadget850 (Ed) ^talk 21:18, 17 April 2012 (UTC)

We have a number of articles where <references/> was used to not reduce the font size. Sometimes in a Notes section, with regular reduced {{Reflist}} in the references section. This has been for various reasons, for example explaining the pronunciation or native orthography of the head word, where we don't want reduced print because IPA, Arabic, Chinese, etc. can be difficult to read in small print. With this change, we'd need to have a bot search all the articles on WP and manually go through them, which would be a ridiculous amount of work. — kwami (talk) 21:24, 17 April 2012 (UTC)

Examples? ---— Gadget850 (Ed) ^talk 22:48, 17 April 2012 (UTC)

Decipherment of rongorongo. You might argue that the Notes section should be small print, but it went through FA full size, and I think that's a decision to be made for each article. There are others that I've come across, with IPA etc. that really is hard to read in reduced type, but I can't think of any off the top of my head. — kwami (talk) 23:18, 17 April 2012 (UTC)

I don't see the issue, but with my myopia I have excellent near vision. Could you point out some of the specific issues? ---— Gadget850 (Ed) ^talk 00:28, 18 April 2012 (UTC)

Sure, for IPA, Chinese, Arabic, etc. If you have the page set for a comfortable reading size, then when you come across scripts that are more difficult to read, making the font smaller only compounds the difficulty. Take the IPA: often a large number of diacritics, which involve a lot of fine detail. You can't just go by whether or not you have a diacritic, but which diacritic it is. This is difficult when the font is the same size as what is comfortable when reading English orthography. When you reduce the size, then the reader needs to adjust the display of their browser just to read the footnote. And it's not just a matter of having good near vision: when the details of the diacritics fall below the resolution of your monitor, a magnifying glass wouldn't do you any good. Sometimes diacritics are conflated: that nasal vowel disappears, for example, and becomes mid tone instead. Anyway, I think this is a decision to be made in the article, and such decisions have been made with the two reference calls that we had available. Their merger has messed up the formatting of articles that depended on them.

As for Arabic, have you ever seen a multilingual package that included Arabic or Persian? Take a look at the ingredients. You'll notice the Arabic script is not reduced to the same tiny size as Latin, Cyrillic, etc, because it becomes illegible. Similarly with Chinese: when printed small, complex Chinese characters are rendered as solid blobs of ink, again illegible. We sometimes don't want to clutter the lead with foreign scripts, so we relegate them to a footnote, but purposefully do not choose {{Reflist}}, because it make them too small. — kwami (talk) 00:39, 18 April 2012 (UTC)

You state that Decipherment of rongorongo "went through FA full size" - could you please point to the section of either WP:FA Criteria or Wikipedia:Featured article candidates/Decipherment of rongorongo where the font size is mentioned? --Redrose64 (talk) 12:26, 18 April 2012 (UTC)

It wasn't mentioned. It was never an issue. — kwami (talk) 13:12, 18 April 2012 (UTC)

{{reflist}} was created to add formatting to <references/>. Now that <references/> has that formatting inherently, the template {{reflist}} is redundant and should be deleted. Then we can create {{reflist2}} to recapture the original behaviour of <references/>. It all seems rather pointless – can't we just have the expected behaviour back? — kwami (talk) 01:38, 20 April 2012 (UTC)

When I look at the references in Decipherment of rongorongo, I see fish. I do not see IPA, Chinese or Arabic. ---— Gadget850 (Ed) ^talk 01:56, 20 April 2012 (UTC)

What difference does that make? Do you bring up irrelevancies just to be difficult?

What is the point of a modified ref template if it does the same thing as having no template? Since everyone here is so unhelpful, maybe it's best to create a new template and get a bot to convert over instances of <references/>. Utterly pointless, and a wasted server load, but the people who edit the articles should not have their choices overridden remotely, without anyone actually looking at the articles that are affected. — kwami (talk) 05:24, 20 April 2012 (UTC)

I just don't see the problem. I have asked you for clarification, and you brought up the apparently irrelevant IPA, Chinese, Arabic. We can't fix problems we don't understand. This has been "broken" for well over a year. Out. ---— Gadget850 (Ed) ^talk 10:17, 20 April 2012 (UTC)

I have done my best to explain, and don't understand how you could not understand. The examples are things which become illegible in reduced font sizes. The reason they're a problem is that they're illegible. It's straightforward to fix: don't reduce the font size. The standard font reduction is part of {{reflist}}, as it should be. But it should be optional, and the unformatted <references/> tag used to allow that option. Yes, I've been aware of it for a while, but I wasn't sure how to fix it or where to go to get it fixed, and it wasn't on the top of my to-do list. — kwami (talk) 23:13, 20 April 2012 (UTC)

For Chinese, compare full-sized 說解繁體簡筆圓龍舊體 with reduced 說解繁體簡筆圓龍舊體.

For Arabic, compare full ٱلرَّحِيمِبِسْمِ ٱللهِ ٱلرَّحْمٰنِ أَبْجَدِيَّة عَرَبِيَّةتم بیٹھوآپ with reduced ٱلرَّحِيمِبِسْمِ ٱللهِ ٱلرَّحْمٰنِ أَبْجَدِيَّة عَرَبِيَّةتم بیٹھوآپ.

For Cambodian, full យុគលពិន្ទុក្បៀសក្រោមសំយោគសញ្ញាមូសិកទន្ត with reduced យុគលពិន្ទុក្បៀសក្រោមសំយោគសញ្ញាមូសិកទន្ត.

For Tibetan, full སྤུ་གུ་ཚོསྦྲུས་པ་ཡོདམཛོ་མོ་ཁྱོད་གཉིས་ཁྱེད་རང་ཚོ་སྙིང་རྗེ་པོ་སྙིང་རྗེ་པོ་ with reduced སྤུ་གུ་ཚོསྦྲུས་པ་ཡོདམཛོ་མོ་ཁྱོད་གཉིས་ཁྱེད་རང་ཚོ་སྙིང་རྗེ་པོ་སྙིང་རྗེ་པོ་.

For IPA, full ɗ̥ə̂ˀwk͡p̚ʔŋʷjə̌ˀntə̌nɗàːtd̪ˠuːi̯n̠ʲɾˠɛ̝̈vʲən̪ˠˈsˠön̪ˠfˠɑ̟ːʃʲ with reduced ɗ̥ə̂ˀwk͡p̚ʔŋʷjə̌ˀntə̌nɗàːtd̪ˠuːi̯n̠ʲɾˠɛ̝̈vʲən̪ˠˈsˠön̪ˠfˠɑ̟ːʃʲ.

As diacritics become more common, reduced font sizes become more difficult to read. Arabic contains numerous diacritics (pointing), as often does the IPA. Chinese is a problem because of the line density of the characters compared to Latin. Cambodian and Tibetan are problems because the letter size is already reduced to allow stacking. — kwami (talk) 23:48, 20 April 2012 (UTC)

Come on, now, this is clearly an issue of policy (about the correct size of references) and not a technical issue. Participants should go start an RFC is they wish to change the status quo of consistent reflist/reference tag styling. It's not a matter for VPT. - Jarry1250 ^{[Deliberation needed]} 10:28, 20 April 2012 (UTC)

I didn't realize we had a policy on ref sizes. I agree that would be the place to address this. Could you point me to where it is? — kwami (talk) 23:07, 20 April 2012 (UTC)

@Kwamikagami: <references /> does not have all the functionality of {{reflist}}, because when multiple columns are used, or where notes are given identifiers which are not ordinary Arabic numerals, an enclosing <div>...</div> is required to add the applicable CSS classes. For example, here are two notes: which with {{reflist|2|group=lower-alpha}} appear as follows:

But the same two notes when given a <references group="lower-alpha" /> don't produce the desired effect:

As you see, there is only one column, and both notes have numbers, not the intended letters. The {{reflist}} template adds the <div>...</div> which produces the desired formatting. Specifically, it's class="reflist references-column-count references-column-count-2" style="-moz-column-count: 2; -webkit-column-count: 2; column-count: 2; list-style-type: lower-alpha;". We can't expect editors to add all that by hand, therefore {{reflist}} should stay. --Redrose64 (talk) 15:36, 20 April 2012 (UTC)

You have my objection backwards. I understand that {{reflist}} adds functionality, and am not requesting that it be deleted. Since that functionality is optional, there is no problem with it. However, it also adds formatting, and the formatting should be optional. It used to be: if we didn't want the formatting of {{reflist}}, we just used <references/>. However, the formatting of <references/> has now been modified to match {{reflist}}, which means that it is no longer optional. That's what I object to: The formatting should be part of the template, not inherent in all types of notes without distinction. The editors of an article should have the option of allowing notes to be formatted in the reader's default settings. — kwami (talk) 23:07, 20 April 2012 (UTC)

Beg pardon, but with this edit you stated the template {{reflist}} is redundant and should be deleted, so your post immediately above I understand that {{reflist}} adds functionality, and am not requesting that it be deleted leaves me very puzzled. Do you want {{reflist}} deleted, or not? --Redrose64 (talk) 14:48, 21 April 2012 (UTC)

Larger quote: "Now that <references/> has that formatting inherently, the template {{reflist}} is redundant and should be deleted. Then we can create {{reflist2}} to recapture the original behaviour of <references/>. It all seems rather pointless..." He was making a point, not saying he actually wanted {{reflist}} deleted -- though perhaps also at the time was unaware of the extra options it offers. Just a musing: Would there be any huge problem with creating a reflist2 with the original formatting, or adding a parameter to reflist for that? Equazcion ^(talk) 15:07, 21 Apr 2012 (UTC)

Sorry, I've missed a few days.

An example I'm working on now, where it would be nice to have full-sized notes: Bharati braille. There's a mix of Indic scripts in the notes, as well as braille. Especially considering that this page might be of interest to readers with problematic vision!

Yes, something like a "size=full" parameter would be nice. I expect we probably wouldn't want to accept any numeric input as a percentage, as that would just encourage inconsistency, but I should think full-size, like we used to have, shouldn't be a problem.

But that still leaves all the articles with <references/> which were intended to be full size. It would be a nearly impossible task to go through them all. — kwami (talk) 08:27, 26 April 2012 (UTC)

How would you tell if <references /> was used to intentionally give full size? It might have been added before {{reflist}} was invented (24 October 2006); it might have been added by a user who was unaware that {{reflist}} existed; it might have been added by somebody who knew of {{reflist}} but who believed them to be interchangeable. After all, when {{reflist}} was first introduced, it was nothing more than <div class="references-small"><references /></div> - the multiple columns came later. --Redrose64 (talk) 13:22, 26 April 2012 (UTC)

I think we should allow the editors of the article to decide that. We've had the reflist template for 6 years; there's been plenty of time to switch over. Sure, there are articles that haven't been copy edited since then, but we aren't fixing anything by overriding conscious decisions to use the full-size template. — kwami (talk) 08:10, 28 April 2012 (UTC)

Sorry, I didn't see your response. My point was that it doesn't matter if there was or was not a discussion before the size of the references tag's output was changed, it's a fait accompli (and not a recent one either) so the onus is really back on you to convince others of the need to switch it back. That's what an RFC is good for and VPT very bad for. - Jarry1250 ^{[Deliberation needed]} 15:42, 29 April 2012 (UTC)

Unified login

Is it possible to "un-unify" my login? I'm creating accounts all over the place that I don't want. Regards, Whenaxis (contribs) ^{DR goes to Wikimania!} 14:30, 21 April 2012 (UTC)

Why is that a bad thing? If you don't want to edit on, say, German Wikipedia, you don't have to. There are several benefits for these accounts existing, but if you don't use them the main benefit is that it prevents other people from registering the same username as yourself. That way, there won't be any edits made by somebody else who wanted to use the login name Whenaxis - and so you won't get the blame for their bad edits. --Redrose64 (talk) 14:56, 21 April 2012 (UTC)

Hmm. Didn't think of it that way. But, I guess that's an advantageous way of looking at it. Whenaxis (contribs) ^{DR goes to Wikimania!} 21:33, 21 April 2012 (UTC)

No, that's not quite true. If you have a unified account (even if it's only between two projects), nobody can create any accounts with your username on any other Wikimedia Foundation projects. The unneeded accounts are indeed harmless, however. Graham87 09:42, 22 April 2012 (UTC)

Another interesting thing about unified logins is they assign edits to your account if you edited a page that got copied (with attribution) to another Wikipedia. For example, with my edits to German Wikipedia show more than the 2-3 that I have actually made. --kelapstick^(bainuu) 09:53, 22 April 2012 (UTC)

IIRC, they do that even if you didn't unify before the import (technical term), thus meaning that other users could erroneously get credited with your creations. - Jarry1250 ^{[Deliberation needed]} 17:29, 23 April 2012 (UTC)

Suddenly can't perform admin actions

A few minutes ago, I deleted a page as a copyvio. Right now, I'm trying to delete three pages, but none of them are going through: clicking the "Delete page" button simply refreshes the screen and preserves the custom rationale that I've written for one of them. At the same time, I've tried blocking and granting user rights to ThisIsaTest, but neither attempt has gone through. Is this a server issue, or is there potentially some other problem with my connection? Buttons for deleting and protecting are still showing up, so I've not been desysopped randomly; I was also able to edit the sandbox just now. IE8/Windows 7. Nyttend (talk) 13:13, 23 April 2012 (UTC)

And now I was just able to delete them. Now I'm even more confused...Nyttend (talk) 13:15, 23 April 2012 (UTC)

Must have just been a blip in your internet connection or JS settings. Internet Explorer is notorious for not working. Rcsprinter (converse) 11:45, 29 April 2012 (UTC)

Header for Special:Export

How i can use Special:Export for my purposes. I send next header from my app:

string request = "POST en.wikipedia.org/w/index.php?title=Special:Export&action=submit HTTP/1.1\r\n"
		 "Host: en.wikipedia.org\r\n"
		 "Content-Length: 32\r\n"
		 "Content-Type: application/x-www-form-urlencoded\r\n"
		 "Connection: close\r\n\r\n"
		 "catname=&pages=ukraine&curonly=1";

but it render to me page about error:

• HTTP/1.0 400 Bad Request Server: squid/2.7.STABLE9 Date: Mon, 23 Apr 2012 14:45:12 GMT Content-Type: text/html Content-Length: 3111 X-Squid-Error: ERR_INVALID_URL 0 X-Cache: MISS from amssq46.esams.wikimedia.org X-Cache-Lookup: NONE from amssq46.esams.wikimedia.org:80 Connection: close

I need to create tools to replace inwiki links to help in translation. I'm sure what some such tool already exist, but i want to do it myself.--Igor Yalovecky (talk) 17:11, 23 April 2012 (UTC)

Couldn't you just run a GET against https://en.wikipedia.org/w/index.php?title=Special:Export&pages=ukraine&curonly=1 ? Does that work? Are you setting a user_agent? - Jarry1250 ^{[Deliberation needed]} 17:25, 23 April 2012 (UTC)

Hi, thanks for answer. Yes i use User-Agent. Here my request:

string request = "POST en.wikipedia.org/w/index.php?title=Special:Export&action=submit HTTP/1.1\r\n"
				 "Host: en.wikipedia.org\r\n"
				 "User-Agent: MyCoolTool\r\n"
				 "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n"
			 	 "Accept-Language: en-us,en;q=0.5\r\n"
				 "Accept-Encoding: gzip, deflate\r\n"
				 "Content-Length: 32\r\n"
				 "Content-Type: application/x-www-form-urlencoded\r\n"
				 "Connection: close\r\n\r\n"
				 "catname=&pages=Ukraine&curonly=1";

But it changed nothing, the same error page appeared. GET request beahave in the same manner. --Igor Yalovecky (talk) 08:55, 30 April 2012 (UTC)

1.20wmf1 deployment complete

We now have deployed 1.20wmf1 to en.wikipedia.org. See mw:MediaWiki 1.20/wmf1 for details on this deployment. Please let us know if you spot any new issues related to this deployment. Thanks! RobLa-WMF (talk) 18:38, 23 April 2012 (UTC)

Diffs

NOTE: There is now an "old style diffs" gadget: Go to My preferences > Gadgets > Appearance > (X)Display diffs with the old yellow/green colors and design.

The diffs are not easy to see with those color combinations. It was easier to see the red. DrKiernan (talk) 18:46, 23 April 2012 (UTC)

You should, at least, fix "Remove groups: parseinline" on Special:ListGroupRights. Ruslik_Zero 18:47, 23 April 2012 (UTC)

The parseinline bug is now fixed. It was fixed in master but somehow the fix was overlooked and didn't make it into the deployed code. --Catrope (talk) 19:46, 23 April 2012 (UTC)

Commons has a gadget "diffOldStyle: Display diffs with the classic yellow/green color scheme. (currently in testing) [discuss]" which gives the old colour scheme. I can't find it in English Wikipedia. --Redrose64 (talk) 18:49, 23 April 2012 (UTC)

(edit conflict)Yeah, that'd be real nice to have here. These new ones are an absolute eyesore. I understand the whole "accessibility" thing, but these are not easily read by normally-sighted people. A net loss, I'd say. ~~ Lothar von Richthofen (talk) 18:53, 23 April 2012 (UTC)

Agree about the diffs, prefer the old style. Also, my Twinkle is no longer working. --Bongwarrior (talk) 18:51, 23 April 2012 (UTC)

Twinkle stopped appearing for me too. Also, the new diff style really sucks. Reaper Eternal (talk) 19:09, 23 April 2012 (UTC)

Twinkle has just been fixed, I think, thanks to whomever. --Bongwarrior (talk) 19:11, 23 April 2012 (UTC)

Where is the gadget to revert this to the previous style? Keith D (talk) 18:55, 23 April 2012 (UTC)

It's going to be open season for vandalism. You can't read the diffs to see it and there's no Twinkle to fix it. 8-( Andy Dingley (talk) 19:09, 23 April 2012 (UTC)

I fixed Twinkle almost an hour ago. The "open season for vandalism" was pretty short. --Catrope (talk) 19:46, 23 April 2012 (UTC)

well Twinkle still doesn't work for me. IE9. Nasnema  Chat  19:52, 23 April 2012 (UTC)

Twinkle is not fixed. (Firefox). - The Bushranger _{One ping only} 20:02, 23 April 2012 (UTC)

Sorry about that, it turned out I had broken Twinkle after fixing it, or something like that. I fixed it for real a few minutes ago and it's now working for me; this should propagate through the caches over the next ten minutes or so. --Catrope (talk) 20:04, 23 April 2012 (UTC)

Thanks for the quick fix! - The Bushranger _{One ping only} 20:18, 23 April 2012 (UTC)

Creating a page with no edit summary no longer asks for an edit summary, as one is automatically created. I tried it, it works. Finally. ▫ JohnnyMrNinja 19:07, 23 April 2012 (UTC)

All forms of vandelism or bad edits revcert i used before are gone from rollback to restore to previous version etc, it all sicne this update, i am now having to revert each edit which is time comsuming and vandel swill be able to do mass edits quicker then the undo--Andrewcrawford (talk - contrib) 19:34, 23 April 2012 (UTC)

• There's some discussion at Wikipedia talk:Twinkle. "Vandalism fighters", all templates can be done by hand as well. See, for instance, Template:Uw-vandalism4im. Don't forget to "subst". Please proofread your hand-typed messages, haha. Drmies (talk) 19:42, 23 April 2012 (UTC)

No point proof reading i am dsylexic i dnt bother much now as i rarely know the word to choose--Andrewcrawford (talk - contrib) 19:44, 23 April 2012 (UTC)

Some of you might get inspiration for old-style yellow/green diffs from User:Redrose64/common.css - this is a rough botch job that I've thrown together by nicking bits of CSS from Commons until diffs started to look right. I do not guarantee that it won't break something. --Redrose64 (talk) 19:57, 23 April 2012 (UTC)

Thank you! - The Bushranger _{One ping only} 20:05, 23 April 2012 (UTC)

For those of us who are more "technologically challenged", how/where does this script get added? ~~ Lothar von Richthofen (talk) 20:41, 23 April 2012 (UTC)

Big ups to the devs that made the new diff style. Looks awesome! — Bility (talk) 20:08, 23 April 2012 (UTC)

Well, there's always one! I agree with the several people above who find it vile and much harder to read. Can the old style be chosen again? Johnbod (talk) 20:11, 23 April 2012 (UTC)

Me too. Drmies (talk) 20:14, 23 April 2012 (UTC)

I prefer the old style as well. I thought this new one was a bug at first, since it is very difficult to see the actual difs. --Saddhiyama (talk) 20:15, 23 April 2012 (UTC)

I concur; the old style was much better. Until somebody writes a gadget, Redrose's script appears to work (at least in MonoBook/FF5). - The Bushranger _{One ping only} 20:18, 23 April 2012 (UTC)

• Why do the new diffs show up if unchecked in the preferences????? Can't see much with those, no contrast!!!!! FUBAR I'd say!!!! Fix it, fix it...!TMCk (talk) 20:17, 23 April 2012 (UTC)
  • The "new diffs" checkbox was a preview. They're now rolled out as the standard. - The Bushranger _{One ping only} 20:18, 23 April 2012 (UTC)
• I will work on OldDiff gadget very shortly! — Edokter (talk) — 20:22, 23 April 2012 (UTC)
  • Good if you can manage what should've done in the first place b/c if FUBAR is now the standard I petty much can forget about checking diffs as my eye sight doesn't work well with low contrast.TMCk (talk) 20:33, 23 April 2012 (UTC)
    • Done! — Edokter (talk) — 21:41, 23 April 2012 (UTC)
      • Great! Thanks a lot.TMCk (talk) 21:56, 23 April 2012 (UTC)

It's not just the colors! Modified paragraphs are shown with a transparent (white) background, and so the shaded, unmodified paragraphs attract way more attention! Really poor design. Nageh (talk) 20:30, 23 April 2012 (UTC)

I would be much easier to spot modified paragraphs it they were shaded in a taint color, and then the actual modified text were shaded in a darker color. Nageh (talk) 00:01, 24 April 2012 (UTC)

FWIW, this is a very simple CSS change to effect a red-green scheme with a non-transparent background (added to a user's common.css file):

.diffchange { border-radius: 0em !important }
td.diff-deletedline { background: #ffecd8; border-color:#ffc888 !important }
td.diff-deletedline * .diffchange { background: #ffb0a0 }
td.diff-addedline { background: #ecffd8; border-color:#c8ff88 !important }
td.diff-addedline * .diffchange { background: #b0ffa0 }

Let me know if you like it. Nageh (talk) 13:11, 24 April 2012 (UTC)

Please remove this update now and fix it. I can hardly read the diffs. THis is worse than my old signature that the community deemed unreadable. That should say something. I have to scan the diffs for a minute for me to see the changes.—cyberpower ^Chat_{Temporarily Online} 20:37, 23 April 2012 (UTC)

Someone really needs to employ a designer who understands standards... colorblind-viewable contrast (which is what these are) are often hard to view for non-colorblind people. It desperately needs a user setting so as not to break for the non-colourblind. --Errant ^(chat!) 20:44, 23 April 2012 (UTC)

(edit conflict)Now I know how the community felt about my old signature.—cyberpower ^Chat_{Temporarily Online} 20:51, 23 April 2012 (UTC)

I'm not colorblind and I'm not having any problems with the new diff design. I'm actually pretty happy with it. Just thought I'd mention. Equazcion ^(talk) 20:49, 23 Apr 2012 (UTC)

As with any "aesthetic update" on a website, there will be those for and those against it. The difference between Wikipedia and sites like Facebook and Youtube is that here, the users actually get some say in the changes, and can even choose not to have them (I'm still using the old MonoBook skin, for example). One of the reasons why I like this place so much. I think most people here want to have at least the option of using the old diff format, rather than kill the new one with fire. ~~ Lothar von Richthofen (talk) 21:07, 23 April 2012 (UTC)

Yes^^^. Shearonink (talk) 21:22, 23 April 2012 (UTC)

I think I understand the reasoning behind this 'update' but do not think it is ready yet. Among other things, please remove the rounded area borders. They make the page look cheesy. The changes need more thinking. I do not support it at this time. --Shuki (talk) 20:58, 23 April 2012 (UTC)

I still have a patch ready in Bugzilla, but they want me to submit it in Gerrit... and I still have trouble setting up Git on my PC. — Edokter (talk) — 21:02, 23 April 2012 (UTC)

Having a hard time reading the edit-history diffs, not sure if the font was changed or if it is the obvious color-changes of the background. Trying to utilize the edit-diffs is actually kind of painful for me. Shearonink (talk) 21:01, 23 April 2012 (UTC)

I'm sorry, but this modification just makes it harder to view changes/diffs. Please restore the prior form as quickly as is practical. Hullaballoo Wolfowitz (talk) 22:32, 23 April 2012 (UTC)

Came here because diffs have suddenly become hard to read. Is there a way for individuals to switch back to the old style? SlimVirgin ^(talk) 22:35, 23 April 2012 (UTC)

I like the new way but i had it switched on before today.Edinburgh Wanderer 22:36, 23 April 2012 (UTC)

• I'm going to join the minority and say I like the new diff format. I have no trouble with the new colours (and am not colourblind). And with the new diff I've just spotted in an instant something that would have been close to impossible to find before - the removal of a space. I always hated those diffs were you couldn't see what was different -- Boing! said Zebedee (talk) 22:43, 23 April 2012 (UTC)
• Count me in that minority as well. When I first saw the new diffs, I thought something was broken, and then I seriously considered changing my preferences back. But after working with it for a while, I'm starting to find that it is an improvement, at least for me. --Tryptofish (talk) 00:15, 24 April 2012 (UTC)

I'm a little lost reading this topic. I have the default Vector skin. Is there a way to go back to red (not yellow/green) diffs?--Bbb23 (talk) 00:34, 24 April 2012 (UTC)

Yes, see the "Note" at the top of this sub-section for how to change your preferences back. --Tryptofish (talk) 00:48, 24 April 2012 (UTC)

I noticed that, but I thought that wouldn't give me the red color. However, I was wrong - it does. The only "new" thing I've noticed so far (after switching back) is scroll bars, which I don't recall ever seeing before. Thanks for the help.--Bbb23 (talk) 01:05, 24 April 2012 (UTC)

I don't suppose there's any chance for a compromise, is there? I love that subtle changes (punctuation, spacing, etc) are now highlighted, but the color scheme is almost impossible to see. Dull yellow on a duller yellow background? I can't imagine that's visually comfortable even for a colorblind person. -RunningOnBrains^(talk) 08:24, 24 April 2012 (UTC)

• I like the new style, but as everyone else has already said, the colours are really, really, really hard to see. Would it be possible to at least make the colours stronger or something like that? The yellow highlighting is particularly faint and tricky to see (example). I totally appreciate the need to accomodate colourblind users on Wikipedia, but this specific implementation has made a key function much more difficult for everyone else to use. Also, what's with these scrollbars? --Dorsal Axe 08:54, 24 April 2012 (UTC)
• I'd have thought the ideal solution would be to have a preference that allows you to choose your own colours - having used the new diffs some more today, it's much easier to find minor punctuation changes now, but I do think being able to make the colours a bit bolder would be a further improvement - they need to be sufficiently subtle to not obscure the text, but bold enough to be able to see a space, comma, etc, and the optimum will surely vary from person to person. -- Boing! said Zebedee (talk) 09:01, 24 April 2012 (UTC)
• Thanks for the gadget - that's better. I was having trouble with the new style. Also, I didn't like the way the colour followed the text, giving what looked like the bottom of a Tetris game when you were losing badly. The colours were yukky too. I must remember the gadget for when I go into Foreign Parts. Peridon (talk) 12:49, 24 April 2012 (UTC)

  Indeed, the Tetris look is totally distracting. Makes it really hard to detect where a change has actually occurred. Nageh (talk) 15:38, 24 April 2012 (UTC)

• All these "blocks" only create a mess out of a diff, it's now hard to see anything. Previously if something was highlighted it was important, now everything is highlightedfuxx (talk) 18:54, 29 April 2012 (UTC)

Watchlist with Enhanced recent changes pref set

The timestamp no longer lines up with the rest of the line in My watchlist: it's dropped down slightly. Apart from looking ugly this increases the spacing between lines and means I can see fewer lines on the screen. (Vector skin, FF 9.0.1)  —SMALLJIM  19:46, 23 April 2012 (UTC)

As a note, this is fine in MonoBook/FF5. - The Bushranger _{One ping only} 20:06, 23 April 2012 (UTC)

Should have added that this is with "Enhanced recent changes (requires JavaScript)" enabled in the Recent changes tab in Prefs. No problem without this enabled.  —SMALLJIM  20:22, 23 April 2012 (UTC)

Removed vector.js and .css - no change. Fired up ancient copy of IE6 - same problem, but very dependent on text size: smaller leads to much greater drop down.  —SMALLJIM  20:49, 23 April 2012 (UTC)

For enhanced watchlist/recent changes, can you turn the cursor back into pointer over the expander graphic? Thanks. — Bility (talk) 20:31, 23 April 2012 (UTC)

The pointer issue was fixed below, I believe. I take it that no-one else is suffering from dropped timestamps, then?  —SMALLJIM  10:22, 25 April 2012 (UTC)

No sorry, I couldn't replicate this in Monobook or Vector, with or without enhanced recent changes. Try disabling your user JavaScript to check if something in there is causing it. Same with any of the gadgets/options related to time stamps in your preferences. — Bility (talk) 15:18, 25 April 2012 (UTC)

Thanks for checking, Bility. Yes, it's evidently some combination of local factors here - I can live with it. It happens on Recent changes too, of course, but I don't look at that often, so I didn't notice.  —SMALLJIM  08:09, 26 April 2012 (UTC)

For the record, I bodged this by reducing the vertical space made available for the expander arrow from 15px to 10px. Adding

.mw-enhancedchanges-arrow {height: 10px}

to my vector.css did the trick.  —SMALLJIM  20:08, 27 April 2012 (UTC)

Section 0 edit link

The [edit] link for the lead section (see Preferences → Gadgets → Add an [edit] link for the lead section of a page) used to be hard right, just like other section edit links. Now it's hard left, which pushes the page title to the right. --Redrose64 (talk) 19:54, 23 April 2012 (UTC)

Fixed with some edits to MediaWiki:Gadget-edittop.js, although there may be a better way to fix it if someone else wants to take a look. -- WOSlinker (talk) 20:03, 23 April 2012 (UTC)

That should not happen and the fix seems redundant. Browser? — Edokter (talk) — 20:27, 23 April 2012 (UTC)

It only seems to be floating to the right when the editsection span is also within a div with a class of mw-content-ltr. Since the h1 header is not within this, it is not floating to the right.

.mw-content-ltr .editsection {float:right;margin-left:5px}

Could add more css rather than inline style? -- WOSlinker (talk) 20:36, 23 April 2012 (UTC)

.firstHeading .editsection {float:right;margin-left:5px}

I don't know where .mw-content-ltr comes from. Is this a Monobook issue? — Edokter (talk) — 20:41, 23 April 2012 (UTC)

I'm using monobook. Don't know if Redrose64 is or not. -- WOSlinker (talk) 20:43, 23 April 2012 (UTC)

It is a Monobook problem, perhpas due to some tighter CSS. Targeted fix for Monobook. — Edokter (talk) — 20:59, 23 April 2012 (UTC)

I have the same thing, and I'm using Modern skin.Maile66 (talk) 21:15, 23 April 2012 (UTC)

Sorry for the delay - had my dinner, came back to a vast watchlist. Firefox 3.6.28, Monobook. But, it seems to be working as previous at present (i.e. it's hard right). Thanks. --Redrose64 (talk) 21:21, 23 April 2012 (UTC)

Been off my computer since the last post - meaning, computer has been rebooted since. It's still a hard left for me on Modern skin. Firefox 3.6.28 here, also, Windows XPMaile66 (talk) 22:12, 23 April 2012 (UTC)

Here to! Opera 11 and IE9 (purge multiple times for script testing) under secure and "insecure" server using modern skin is also still on the left. :( mabdul 00:16, 24 April 2012 (UTC)

Fixed for monobook & modern skin now. Also works with vector skin. Still not fixed for other skins as they all have slightly different classes. So should we add custom code for each skin? -- WOSlinker (talk) 06:37, 24 April 2012 (UTC)

Everything looks good on mine.Maile66 (talk) 11:32, 24 April 2012 (UTC)

Looks fine on Monobook now - it was irritating me and wasted some time while I tried to find out what I'd done... Personally, I don't care about the other skins. Just keep Monobook working without twiddling with it. I would think most who use it like it as it is. If they didn't, they'd be following the flock to Vector. Peridon (talk) 12:54, 24 April 2012 (UTC)

Twinkle

Hi, I understand something was shut down on Wikipedia. My twinkle is not working, is this the cause of the problem? --Chip123456 (talk) 19:52, 23 April 2012 (UTC)

See the section above. ~~ Lothar von Richthofen (talk) 19:58, 23 April 2012 (UTC)

I haven't been around on wiki for a long time, but today I have noticed that there are still some areas of Twinkle not working. On the Monobook skin (which is the skin that I still use today) I can't click on the additional tabs at the top such as csd, xfd, unlink etc. I'm afraid someone's going to have to do some more fixing to get this problem sorted out! Minima© (talk) 19:04, 24 April 2012 (UTC)

Its definitely still not working on the modern skin. I cant CSD anything nor can i use the welcome functions. The tabs are their but they won't work.Edinburgh Wanderer 19:08, 24 April 2012 (UTC)

Diff irregularities

We're probably in for another round of polarizing diff opinions, but in trying to understand how the new format works I noticed the following behavior on this very page: Why (on Firefox 11 w/Vector) does this diff look different than the very next diff? Orange Suede Sofa (talk) 20:23, 23 April 2012 (UTC)

Because the first diff shows a changed line and the second diff shows an added line. You would see the same effect with the old style. — Edokter (talk) — 20:31, 23 April 2012 (UTC)

TeX broken

I had pointed out some days ago at bugzilla that mangling special symbols (<, >, &) as 1.20wmf1 is doing it is incorrect. What happens now is that, for example, a smaller-than sign (<) gets mangled into the HTML escape code < and then this code gets mangled again to produce <. In particular, this breaks the mathJax user script. Nageh (talk) 20:21, 23 April 2012 (UTC)

Strip markers

The change log notes that an empty <math> tag was fixed, but I think some other problems were fixed as well, possibly in the 1.19 update. See Help:Strip markers, where I tagged the ones I think are fixed, but would like some more confirmation. ---— Gadget850 (Ed) ^talk 20:40, 23 April 2012 (UTC)

What links here

Just noticed that on the output from "What links here" there appears to be a change that shows links via redirects twice. It shows it under the redirect link and directly under the main entry in the hierarchy. The link should only appear once against the main or the redirect that it is using. Keith D (talk) 20:52, 23 April 2012 (UTC)

Can't see that here. On what page is this happening?  —SMALLJIM  21:01, 23 April 2012 (UTC)

Are you sure the article in question doesn't link to the page both directly and via a redirect with two separate links? jcgoble3 (talk) 23:45, 23 April 2012 (UTC)

It is on {{Infobox GB station}} which is including articles that use the redirect {{infobox UK station}} under both. Keith D (talk) 23:54, 23 April 2012 (UTC)

A few userspace tests both here and on Wikia show two things: first, this bug only occurs on transclusions, not wikilinks, and second, this is an old bug, as it manifests on Wikia as well, which is still running MW 1.16.5. jcgoble3 (talk) 01:09, 24 April 2012 (UTC)

This behaviour - where templates transcluded through redirects are listed twice (once under the real name, once under the redirect) - has existed since some time prior to 19 November 2011. That isn't when it started - it's when I first noticed it; and coincidentally, I noticed it with {{Infobox GB station}} as well. --Redrose64 (talk) 11:18, 24 April 2012 (UTC)

OK, just coincidence that I noticed it following the software change. Has a bug report being raised for the problem? Keith D (talk) 21:21, 24 April 2012 (UTC)

I always considered this a feature. :-) It makes it possible to retrieve all the pages that transclude a template without having to worry about whether they go through a redirect. --R'n'B (call me Russ) 13:20, 28 April 2012 (UTC)

Cursor missing - enhanced watchlist

I used to get a special cursor when pointing at the "expand multiple diffs" arrows in the watchlist. That no longer happens, the cursor doesn't change when I'm hovering over them. It still changes to a "question mark" when I hover over a "Nbm..." flag there. I didn't notice just how much I rely on the changed cursor to access the arrow quickly and efficiently. I am using Ubuntu 11.10, Chromium 18.0.1025.151 Elizium23 (talk) 21:24, 23 April 2012 (UTC)

I have this issue also. Firefox 11/Windows Vista/Vector. jcgoble3 (talk) 23:47, 23 April 2012 (UTC)

Requested this be changed above, but will copy here so it doesn't get missed. Please change the cursor back to pointer when hovering expander graphic on watchlists and recent changes. Thanks. — Bility (talk) 02:20, 24 April 2012 (UTC)

Well, I got impatient so here it is if anyone else wants to modify their CSS: .mw-enhancedchanges-arrow { cursor: pointer; } — Bility (talk) 15:36, 24 April 2012 (UTC)

CSS works for me! Excellent, thank you! Elizium23 (talk) 16:33, 24 April 2012 (UTC)

I raised this issue at the Help Desk and they sent me here. I haven't a clue about CSS, so could some kind person give me an idiot's guide to how and where to put the above stuff. TIA. --GuillaumeTell 21:03, 24 April 2012 (UTC)

I placed this in my common.css file under my userspace. Link - User:Elizium23/common.css. The foolproof way to get here is to go to "Preferences->Appearance" and find the link at "Shared CSS/JavaScript for all skins: Custom CSS". You could optionally put it in your skin's CSS instead; there are links at the same Preferences page for those. Edit the file, copy and paste that single line above. You may need to purge your cache when reloading, but probably not, because the watchlist is dynamic content. Elizium23 (talk) 21:22, 24 April 2012 (UTC)

Thanks for this. I've done the copying and pasting and saving, and the result is absolutely identical to yours. I've purged my cache as well. However, I'm still stuck with the unsatisfactory watchlist that displays "n changes" rather than the triangular blue pointer. What have I done wrong? Should I have done something with the <syntaxhighlight lang="css" enclose="none"> that appears in Bility's contribution above? Any help gratefully received. --GuillaumeTell 16:19, 25 April 2012 (UTC)

Paste function within table

I'm having this phenomenon in all tables. Did not notice it until today, so not sure if it's related to this thread. I also upgraded to Firefox 12.0, on my Windows XP. Hawaiian Music Hall of Fame#Individuals is an example. I can paste within blocks of text in the table, but outside the blocks of text, the Paste option grays out. Maile66 (talk) 14:02, 25 April 2012 (UTC)

I was, of course, referring to this happening in the Edit screen. By the way, I figured out a work-around on this, which amounts to fooling the system. Let's say I want to paste at the end of the body of text, which makes the Paste option disappear. If I hit the Space Bar once, it fools the system and let's me paste. An odd thing, and making twice the steps to do a paste. Just want to know if anyone knows what causes this.Maile66 (talk) 17:47, 25 April 2012 (UTC)

Redlinks are blue in MySkin

Tracked in Phabricator
Task T38276

Redlinks to non-existing articles are currently rendered blue in MySkin. See for example "like this one" in the opening line of http://en.wikipedia.org/wiki/Wikipedia:Red_link?useskin=myskin, compared to http://en.wikipedia.org/wiki/Wikipedia:Red_link?useskin=vector. I haven't tested it before but a user at User talk:PrimeHunter#Re : Red links turned to blue says it started 3 days ago so I suspect it's related to 1.20wmf1. PrimeHunter (talk) 12:45, 26 April 2012 (UTC)

Okay, it would appear that turning links red is done in commonElements.css; presumably, then, that used to get loaded automatically (since that dependency isn't declared anywhere AFAICT). With 1.20, dependency rules are being tightened (as I can see to just common.css); so the fix is probably to add a dependency on commonElements.css (and/or its sister files). However, it would probably be worthfiling a bug request so that someone familiar with the resource loader can correct all the factual errors in my analysis first :) - Jarry1250 ^{[Deliberation needed]} 13:09, 26 April 2012 (UTC)

This may be the same as WP:HD#Red links turned to blue. --Redrose64 (talk) 14:45, 26 April 2012 (UTC)

Indeed. The user I referred to is the original poster there. PrimeHunter (talk) 15:32, 26 April 2012 (UTC)

Okay,filed a bug for this. - Jarry1250 ^{[Deliberation needed]} 16:19, 26 April 2012 (UTC)

ForeignDBViaLBRepo: write operations are not supported.

When I attempt to purge File:Project Paperclip Team at Fort Bliss.jpg, I consistently get:

ForeignDBViaLBRepo: write operations are not supported.

Backtrace:

#0 /usr/local/apache/common-local/php-1.20wmf1/includes/filerepo/FileRepo.php(848): ForeignDBViaLBRepo->assertWritableRepo()
#1 /usr/local/apache/common-local/php-1.20wmf1/includes/filerepo/file/LocalFile.php(780): FileRepo->quickPurgeBatch(Array)
#2 /usr/local/apache/common-local/php-1.20wmf1/includes/filerepo/file/LocalFile.php(743): LocalFile->purgeThumbList('mwstore://share...', Array)
#3 /usr/local/apache/common-local/php-1.20wmf1/includes/filerepo/file/LocalFile.php(695): LocalFile->purgeThumbnails(Array)
#4 /usr/local/apache/common-local/php-1.20wmf1/includes/WikiFilePage.php(157): LocalFile->purgeCache(Array)
#5 [internal function]: WikiFilePage->doPurge()
#6 /usr/local/apache/common-local/php-1.20wmf1/includes/Article.php(1793): call_user_func_array(Array, Array)
#7 [internal function]: Article->__call('doPurge', Array)
#8 /usr/local/apache/common-local/php-1.20wmf1/includes/actions/PurgeAction.php(51): ImagePage->doPurge()
#9 /usr/local/apache/common-local/php-1.20wmf1/includes/actions/PurgeAction.php(69): PurgeAction->onSubmit(Array)
#10 /usr/local/apache/common-local/php-1.20wmf1/includes/Wiki.php(483): PurgeAction->show()
#11 /usr/local/apache/common-local/php-1.20wmf1/includes/Wiki.php(277): MediaWiki->performAction(Object(ImagePage))
#12 /usr/local/apache/common-local/php-1.20wmf1/includes/Wiki.php(592): MediaWiki->performRequest()
#13 /usr/local/apache/common-local/php-1.20wmf1/includes/Wiki.php(502): MediaWiki->main()
#14 /usr/local/apache/common-local/php-1.20wmf1/index.php(58): MediaWiki->run()
#15 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...')
#16 {main}

The Commons version purges with no issues. ---— Gadget850 (Ed) ^talk 20:16, 23 April 2012 (UTC)

enwiki version purges with no problem for me. Firefox 11/Vector here. jcgoble3 (talk) 23:49, 23 April 2012 (UTC)

This was fixed in the code. Aaron Schulz 03:00, 24 April 2012 (UTC)

Is there like any possible way we could transcode articles as templates? Like perhaps some kind of page? If not would it be possible to make one? Well thanks anyway.

Walex03. Talking, working, friending. 21:02, 23 April 2012 (UTC)

Any page may be transcluded; to transclude an article you need to insert a colon after the opening braces, as in {{:Wage reform in the Soviet Union, 1956–1962}} --Redrose64 (talk) 21:23, 23 April 2012 (UTC)

Rollback error

Please excuse me if this is in the wrong section.

On occasion, when I'm using rollback and Twinkle, I'm getting an "Unable to proceed" error with a message along these lines:

There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Go back to the previous page, reload that page and then try again.

I started getting this message today and have been getting it ever since. I'm using Firefox version 11.0 on a Mac OS X 10.5.8. I'm not sure if the new MetaWiki software update has anything to do with it. -- Luke (Talk) 01:41, 24 April 2012 (UTC)

Sounds like this is related to the general loss of session data people have been experiencing (since before the update). See #Having trouble staying logged in above. Equazcion ^(talk) 01:55, 24 Apr 2012 (UTC)

Whatever you're experiencing, it's not related to the update as I just succesfully rollbacked an edit here.—cyberpower ^Chat_Absent 02:19, 24 April 2012 (UTC)

I was getting rollback failures similar to that described by LuK3 (they may have been exactly the same) on 14 April 2012, so it's not new. They only happened about four times, and cleared up by themselves. --Redrose64 (talk) 13:09, 24 April 2012 (UTC)

@Cyberpower678: this isn't a rollback, it's a revert (although Twinkle does misleadingly describe it as "rollback", see Wikipedia:Rollback feature#Additional tools). The true rollback feature is not the group of links above the "Latest revision" text, but the single "[rollback]" link to the right of the "(talk | contribs)" links; it goes back to the most recent version made by a different editor instantly, and does not allow a custom edit summary. --Redrose64 (talk) 13:26, 24 April 2012 (UTC)

New "diff" view is horrible and illegible

Please restore the normal "diff" view in bright colors that was so easy to read and discern. This new one with pale blue and even paler beige and otherwise white is ridiculously difficult to read, much less scan. Why do these things get tinkered with without discussion or rhyme or reason? It was perfect the way it has been for years so please restore it. Softlavender (talk) 03:25, 24 April 2012 (UTC)

See #Diffs. You can change back to the old style of diffs by using a gadget, but I think it's unlikely the devs will change the default diff view back. Jenks24 (talk) 03:30, 24 April 2012 (UTC)

Why using a gadget? When it was so much pretty easy before. It is like "Ok, we broke it but here you are a fixing "gadget"" :) this is ridiculous. --Aleksd (talk) 07:07, 27 April 2012 (UTC)

The default behaviour of the diffs was altered by some of the MediaWiki developers (a.k.a. "the devs"). So far as I know, they have not yet said that they "broke it", nor have they offered a gadget in replacement. There is a new gadget, yes, but it was not written by the devs. It was put together by Edokter, a regular contributor to this page. I expect that he noted the many comments, or disliked the new appearance himself - either way, he actually went and did something about it instead of just complaining. --Redrose64 (talk) 20:27, 27 April 2012 (UTC)

Why was it changed? Why won't they change it back? Softlavender (talk) 03:35, 24 April 2012 (UTC)

Someone who follows the mailing lists and so on will probably be able to give you a better answer, but my understanding is that the WMF developers have been trying to make an "improved" diff view for some time now (I believe there were concerns about the old red/green being difficult for people with colourblindness, but don't quote me on it). Anyway, the new diff viewer has been released as part of the mediawiki 1.20 rollout. I'm not saying the devs definitely won't change it back, but I've watched the last few mediawiki rollouts (from maybe 1.16 onwards) and the devs generally don't reverse something unless it's unambiguously wrong – if it's just a preference, and even if that preference is supported by a consensus of editors, they generally won't reverse it because their preference trumps ours. Jenks24 (talk) 04:11, 24 April 2012 (UTC)

I'm all for improvements, but how the heck is this an improvement? Viriditas (talk) 09:38, 24 April 2012 (UTC)

(edit conflict)I wish that this could be a preference option, especially since I find the coloring easier on my own eyes. For now, you can use the "enhanced diff view" gadget (see the Gadgets section of your preferences).--Jasper Deng (talk) 03:32, 24 April 2012 (UTC)

Not clear which preference you are referring to, or which is easier on your eyes. Softlavender (talk) 03:35, 24 April 2012 (UTC)

I mean, I don't mind, but I feel that the diff colors should be something users could set in their preferences.--Jasper Deng (talk) 03:37, 24 April 2012 (UTC)

OK, but for the record, which coloring is easier on your eyes? Softlavender (talk) 03:54, 24 April 2012 (UTC)

The new one.--Jasper Deng (talk) 04:33, 24 April 2012 (UTC)

Of course it is easier on the eyes. And that means, you can't tell what content was changed or removed! Is anyone home? Viriditas (talk) 09:48, 24 April 2012 (UTC)

I also have to ask, Why was this changed? The new diff approach has scrollbars, no idea why, barely visible colorations, and no advice on how to modify these things back. Just change it back and to quote Wikipedia... get CONSENSUS from the community for the change. Forcing it into the project without adaquate explanation isn't a good approach. -- Avanu (talk) 04:05, 24 April 2012 (UTC)

Also, quoting Jenks24 above, who said it is "unlikely the devs will change the default diff view back". If they won't change it back by simple request, then how do we begin a formal request to undo this change? -- Avanu (talk) 04:07, 24 April 2012 (UTC)

The developer community is mostly separate from our community here.--Jasper Deng (talk) 04:33, 24 April 2012 (UTC)

well, as far as I can remember Jimbo has a talk page here, so they are not some separate entity that may not be contacted in no way or should not be questioned on their 'design' :) Besides my own vision is that when you do something you should be interested of how it affects people, that mean in coding too. So they should probably better have some way of getting information of editors visions. --Aleksd (talk) 07:29, 27 April 2012 (UTC)

I wanted to give myself some time to get used to it, but so far I find the new color scheme much more difficult to scan. Before I could just glance at the diffs to get an overall impression. Now I have to study them. — kwami (talk) 04:09, 24 April 2012 (UTC)

Ugh. I completely agree with you, kwami. You know, this also bugs me because I often have to contact OTRS "customers" and abuse-contacts for ISPs, and it's easy to tell them, the text that changed within a paragraph is highlighted in red. Now I guess I'll tell them, what? The text that changed is highlighted in a slightly different color from everything else? Maybe this is just five years of conditioning on my part, and I'm coming off as an old fart, but I'm glad they at least let us switch back. Someguy1221 (talk) 04:21, 24 April 2012 (UTC)

In theory, I like that it shows the addition or removal of spaces, but in practice the shading is so light that I have to peer really closely to find it. I wonder if this couldn't be tweaked to a slightly darker shade. (My vision and color vision are normal.) Rivertorch (talk) 04:28, 24 April 2012 (UTC)

Count me in the "me too" category. I saw the change suddenly this afternoon, then saw the section mashed in with everything else up above, and I said "ok, I'll give it a shot and see if I adjust to it". Unfortunately, I think that the concerns brought up regarding accessibility are valid, since myself and apparently many others share them (which is ironic, considering that accessibility is one of the main reasons to change it). This isn't my first exposure to this diff engine either, since I've seen it on the MediaWiki server for a while now, so it's not as though this is just shock at any change speaking. I'm certainly surprised to see the new diff code in use here though, since the version on MediaWiki seemed so obviously "not ready for prime time". I guess that I should have said something earlier, but I had no clue that rolling it into the updated version of the software was even being considered. Someone seriously dropped the ball on this one.
— V = IR (Talk • Contribs) 04:32, 24 April 2012 (UTC)

Ranting won't help; just have a poll and change it back via Common.css Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 04:51, 24 April 2012 (UTC)

Sometimes it does. In 1.19 they rolled back the diff color changes. [1] Killiondude (talk) 04:55, 24 April 2012 (UTC)

I don't think that we're "ranting" at all. This was all done through CSS? That's more information about this change than has been available before now... and I suspect that it's not the whole story.
— V = IR (Talk • Contribs) 04:57, 24 April 2012 (UTC)

No, it wasn't done via css, but can be "un-done" via css. That was a comment to the people who claim we are slaves to the devs. We're not. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 05:00, 24 April 2012 (UTC)

I don't think that (using CSS to "undo" these diff changes) would be wise at all. Creating a situation where the "left hand" is undoing the work of the "right hand" is never the way to go. We'r enot slaves to developers at all, but if nobody gives them any (constructive) feedback then they're just going to do whatever they think is best.
— V = IR (Talk • Contribs) 05:37, 24 April 2012 (UTC)

The change was done using CSS actually. No changes were made to the diff engine. — Edokter (talk) — 09:45, 24 April 2012 (UTC)

Well, personally I think the new diff view is much better than the old one. Some changes, especially if they included for example only the removal of a single character, such as a . or , were barely visible and this can be seen much better in the new diff view. -- Toshio Yamaguchi (tlk−ctb) 05:52, 24 April 2012 (UTC)

It's shit, but you can change it back via your Preferences. Problem solved. Lugnuts (talk) 09:04, 24 April 2012 (UTC)

Problem solved for editors who just so happen to visit this page at this particular time. Which is what, 0.001% of editors? Softlavender (talk) 09:12, 24 April 2012 (UTC)

Quite right Softlavendar. Lugnuts' response is a little "I'm alright Jackish". This strikes me as one of those changes that looks great on the 50cm desktop screens the developers used, but hasn't been subjected to any usability testing on netbooks. And what's the reason for the change? HiLo48 (talk) 09:29, 24 April 2012 (UTC)

I don't think any explanation has been given, but numerous editors have guessed that it was made to accommodate the colourblind. If that is true one wonders why it couldn't have been the other way around, making it so if you had problems viewing coloured difs on account of colourblindness you could change it in your preferences, considering that at most the colourblind make up 10% of the editors. --Saddhiyama (talk) 09:35, 24 April 2012 (UTC)

"Lugnuts' response is a little "I'm alright Jackish"." Got it in one! Lugnuts (talk) 12:54, 24 April 2012 (UTC)

Oh, common, they change coloring for color-blinded people who cannot see it anyway (there is still red on it)? Should listen to your own logic. And by the way... nobody can see it now... :) that's king of a "successful solution against display discrimination". Adding a '+' to the old view should have been pretty much enough. And what do you mean by developers, this is design, are the developers making design here or designers? Must make it clear. --Aleksd (talk) 07:44, 27 April 2012 (UTC)

(ec) The change was prompted by the fact that red-on-green is incredibly hard to pick out for a non-negligible proportion of humanity (and for another chunk, red-on-yellow lacked the requisite contrast). And no, it wasn't trialled exclusively on 50cm screens, but yes, I'm sure if there are suggestions for tweaking the CSS to display better on narrow screens, they've get adopted. To answer the other points, people who don't like it will come to this page, and will find the instructions on how change it, believe me. Personally, I like the new style. - Jarry1250 ^{[Deliberation needed]} 09:40, 24 April 2012 (UTC)

Bullshit. Most people who don't like probably don't even know this page exists. Massive arrogance/ignorance/lack of perspective on display there. HiLo48 (talk) 20:51, 24 April 2012 (UTC)

Gee, lovely tone you've got there. As someone who routinely helps out on all manner of help desks around Wikipedia, I can only try to reassure you that people who query these kinds of changes anywhere publicly do get an informative response. Admittedly, that leaves two issues (i) if you think that new editors won't know what they're missing (ii) existing editors who notice, don't like the new style, but have no idea how to query that (or know how but don't bother looking into it. I think (i) is genuinely pertinent, (ii) less so. - Jarry1250 ^{[Deliberation needed]} 20:59, 24 April 2012 (UTC)

It's nice that you help people elsewhere. That you see any point in doing that just further shows the silliness of saying "people who don't like it will come to this page..." Most won't. They'll just say to themselves "Yet another unexplained, silly IT change that I never asked for and can't see the point of", be annoyed, and get on with their, now ever so slightly more difficult, lives, thinking even less of IT professionals. NOTE: I'm one too, and I would prefer our image to be improving. HiLo48 (talk) 21:15, 24 April 2012 (UTC)

Worst change ever. Viriditas (talk) 09:42, 24 April 2012 (UTC)

For those (eg Toshio Yamaguchi) who have trouble seeing small changes (eg single character, especially punctuation) but want the old diff scheme: try using wikEdDiff or wikEd (under Preferences, Gadgets, Editing), which give a little "delta" button that shows a "better" diff - I find it helps locate small changes. Mitch Ames (talk) 13:18, 24 April 2012 (UTC)

This has been available as a preference since 21:34 UTC yesterday; you need to switch on Preferences → Gadgets → Display diffs with the old yellow/green colors and design. --Redrose64 (talk) 11:10, 24 April 2012 (UTC)

• In my view, I think the ideal solution would be prefs so people can set their own colours. For me, the new colours work fine and I find them easy to see, but everyone's eyes are different and no fixed colour scheme will please everyone. But apart than the colours, I think the functional changes to the new diff are a great improvement - it's really good to finally be able to see single-character changes and the addition/removal of white space quickly. -- Boing! said Zebedee (talk) 11:56, 24 April 2012 (UTC)

Change it back. New one is much much harder to read. Color is very useful and most computer screens are now color so it's not too radical of an idea to use color, no need to take out color indication of changes.  :-) North8000 (talk) 12:08, 24 April 2012 (UTC)

I also dislike the new default diff. As well as the colours being harder to read (for me), it takes more vertical space. (This example uses 25% more vertical space on my screen.) My eyes are not good, so my video is configured for larger and thus fewer pixels on the screen - extra space used by the coloured border means less text fits on the screen. Mitch Ames (talk) 13:11, 24 April 2012 (UTC)

Btw, the new scheme becomes illegible for people with yellow-blue blindness. If MediaWiki is aiming for the minority then why not aiming for the absolute minority and change it back to a red-green scheme so people with yellow-blue blindness can read the diffs again properly? :) Nageh (talk) 13:25, 24 April 2012 (UTC)

Instead of leaving the default for the average person they handed out eye patches to everyone, incl. the one eyed ones (a minority served at cost of another minority).TMCk (talk) 13:27, 24 April 2012 (UTC)

I don't like the new Diff, but calling the old Diff "better" is like saying that, of the Three Stooges, Curly is the intellectual Stooge. Why do I have to scan an entire paragraph to find that someone changed two spaces to one? See https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Arbitration/Requests/Case/Race_and_intelligence/Review/Proposed_decision&curid=35089626&diff=488988825&oldid=488988590 for an example of the new Diff getting it right (but with hard-to-see pastel shading). --Guy Macon (talk) 15:31, 24 April 2012 (UTC)

Having viewed your linked diff with both the old and the new style I can't really see where it is that the new style is supposed to be getting it right? The edit was just as visible (more of course on account of the colour scheme) with the old style. --Saddhiyama (talk) 15:37, 24 April 2012 (UTC)

Can you give an example of the diff generator getting it wrong for comparison? - Jarry1250 ^{[Deliberation needed]} 15:38, 24 April 2012 (UTC)

The new diff "look" sucks. Please don't force us into it! and make it obvious for new users they have a choice. Electron9 (talk) 19:01, 24 April 2012 (UTC)

I think the last thing newcomers would have on their minds would be the colors of the diffs. --MuZemike 19:29, 24 April 2012 (UTC)

I really don't like the dismissive "there's a gadget!" attitudes here. There's a problem, let's deal with it. Quit trying to dodge the issue and dismiss everyone's concerns, and lets have a discussion in order to come up with an actual resolution. I've removed the condescending "note" that someone placed at the top of this section, since that's not what the section is about, and we all know that there's a gadget already.
— V = IR (Talk • Contribs) 19:02, 24 April 2012 (UTC)

Actually, someone else was arguing they didn't think the availability of the gadget was obvious enough; I'm not sure I can square those two sentiments.

In any case, the availability of said gadget means we could indeed have an informed debate abut the default setting, safe in the knowledge that no-one is bound by that. Maybe even a poll. (Yay, it's Vector all over again.) - Jarry1250 ^{[Deliberation needed]} 20:17, 24 April 2012 (UTC)

So we need to get developer crappy screens to test with, preferable at 800x600 or 1024x768 resolution. — Dispenser 23:55, 24 April 2012 (UTC)

Add me to the list of those who hate this change! While there is an improvement in seeing some changes that were not really visible before, the use of colors makes the new screen virtually useless! If anyone really thinks that this is actually an improvement, make it optional so that those who want it can use it. Vegaswikian (talk) 21:52, 24 April 2012 (UTC)

It is optional - in gadget prefs, "Display diffs with the old yellow/green colors and design" -- Boing! said Zebedee (talk) 22:23, 24 April 2012 (UTC)

Default is not optional. --Aleksd (talk) 07:58, 27 April 2012 (UTC)

• Just in case any devs are reading this thread, I have to agree: it's pretty terrible looking. I'm going to change it back to the old style view. Be sure to let us know if you make any major changes to it, so that we can try it out again. ‑Scottywong| gossip _ 23:08, 24 April 2012 (UTC)
• I just want to say that the css code listed earlier that adds a red-green style with a colored background is a big help. Chris857 (talk) 23:11, 24 April 2012 (UTC)

Developers, these shades are indistinguishable from white
#F3F3F3
#F4F4F4
#F5F5F5
#F6F6F6
#F7F7F7
#F8F8F8
#F9F9F9
#FAFAFA
#FBFBFB
#FCFCFC
#FDFDFD
#FEFEFE

The table on the right shows colors that I cannot tell apart from white in a side-by-side comparison. It gets worse when I adjust brightness, contrast, move the windows to different hotspots, or simply change the viewing angle. Other people have similar experiences. It isn't limited to ancient CCFL LCDs as my netbook LED LCD similar problem. Blacks are better as I can distinguish up to #040404.

This affects all colors, a good approxiation as I can tell from CRT is to simply scale up 5%. So The light gray non-changed background is white. Our text highlight, removed #FEEEC8 appears as #FFFAD2 and #D8ECFF appears as #E3F8FF on my LCD. — Dispenser 23:55, 24 April 2012 (UTC)

CRTs, in my experience, tend to be darker, not lighter, than LCDs... but maybe that's just me. I do have washed-out issues on some of my crappier monitors, though. But those are all LCDs. — Isarra ༆ 00:38, 25 April 2012 (UTC)

I also agree! The previous view was better! --Tito Dutta ^Message 00:53, 25 April 2012 (UTC)

The new dif look is so pretty! And completely useless! I complement the interior designers who created the new look, and ask that they now step aside and yield to someone who actually uses difs in their work around here. HuskyHuskie (talk) 01:44, 25 April 2012 (UTC)

I frequently read Wikipedia on a laptop with a TFT monitor, and I don't always bother to tilt the thing for maximum contrast. It doesn't take much of an off-axis view to cause the pale blue and brown of the new diff style to blend in with the white of the background. --Carnildo (talk) 01:37, 27 April 2012 (UTC)

An alternative maybe

Because I hate change, I previously merged a bunch of the different styles together for my own use back when the first ones were changing over, but perhaps it might work for other folks too? It does seem to also address at least some of the concerns raised about the lot of the previous ones (stuff seems like it would show up for colourblind people; it fits on my damn screen; red stands out enough to see, but has enough black that it's still visible without the red; that bloody highlighting that irks me half to death ain't there; there's a clear distinction between context and diffs; space characters do show up, even if it is subtle), well, uh, what do you think?

Actually that's not quite what I'm using, but this version has less confusing colours (as in, not green and blue). Source is here, though, if anyone wants to use it or yell at me for writing such a horrible stylesheet or make it darker or what have you. — Isarra ༆ 00:38, 25 April 2012 (UTC)

These colors are exactly what I was fighting when I first changed diff colors (though the current version isn't based on my design): red on yellow or green hurts my (as well as other colorblind peoples') eyes. Max Semenik (talk) 22:54, 25 April 2012 (UTC)

Where do we go to get this fixed?

The feedback looks overwhelming here, but where to we go to get it fixed / returned to the previous design? North8000 (talk) 16:50, 25 April 2012 (UTC)

You create a proper RFC, then advertise it across the site. Simple as :) - Jarry1250 ^{[Deliberation needed]} 16:53, 25 April 2012 (UTC)

Thanks. I must have missed the RFC which decided to make the recent big change.  :-) North8000 (talk) 20:02, 25 April 2012 (UTC)

Feedback would be overwhelming here. This is where people complain. People without gripes don't always search for a forum to not-gripe in. ▫ JohnnyMrNinja 20:56, 25 April 2012 (UTC)

I'd support an RFC, but please make it constructive. Screeching "put it back!" isn't very helpful, and is likely to just be ignored (especially since the developers have covered their bets by adding a gadget). We definitely need to get the (default) colors changed, and it would certainly be nice to have the design... er, redesigned slightly.
— V = IR (Talk • Contribs) 21:35, 25 April 2012 (UTC)

I agree with Johnny this is where people come to complain when something is wrong not when they like it. So feedback here is not necessarily reflective of community support. I personally like this change especially for viewing where blank space has been removed which was very tricky to see on the old diff screen. It can be turned off as a gadget equally as much as it could be turned on when the old diff screen was live. Basicly what I'm saying is someone is always going to be alienated here.Edinburgh Wanderer 21:41, 25 April 2012 (UTC)

It's possible to have something very similar to the old diff appearance and show where spaces have been added/removed. Set the OldDiff gadget as noted elsewhere on this page, and then add these two lines either to Special:MyPage/skin.css or to Special:MyPage/common.css:

td.diff-deletedline .diffchange {background-color: #cfc; }
td.diff-addedline .diffchange { background-color: #ffa; }

What this does is to give a different background colour to the red text (which denotes changes), whilst leaving the background of the black text alone. The two colours that I've chosen here mean that changes on the left will get a green background, whilst changes on the right get a yellow background. This produces the following effects:

Default background for unchanged text Green #cfc for old version unchanged text .

Default background for unchanged text Yellow #ffa indicates the new text unchanged text.

i.e. the background colours are exchanged when changed text is shown. You can of course vary those colours. Spaces show up because of the different background colour, even though there is no red text at that position: look just before the full stop of the left-hand side. --Redrose64 (talk) 23:03, 25 April 2012 (UTC)

Yes, yes, yes, we're all well aware that there are a variety of work arounds for adjusting the way that the new diffs look. What does that have to do with the subject of this section? This spamming "fixes" on every section that is even remotely related to the diff change is annoying, if not outright disruptive.
— V = IR (Talk • Contribs) 23:17, 25 April 2012 (UTC)

Please demonstrate that I "spam fixes on every section". Unlike the MediaWiki devs, I don't force you to use any new ideas. People keep posting threads that say, in essence, "I liked the old way, change it back" or "I like some of the new features, but mostly the old". They ask for help: I offer it. If you don't like it, you don't have to take it. This particular suggestion was in response to the comment "especially for viewing where blank space has been removed which was very tricky to see on the old diff screen". I was demonstrating that the old method can be configured to reveal added or removed spaces.

As for the OP's "where to we go to get it fixed / returned to the previous design" - it's bugzilla:. The devs will ignore anything else, including an RFC. But don't complain to me when they close it "WONTFIX". --Redrose64 (talk) 12:23, 26 April 2012 (UTC)

Well, it depends what the intention is. If you want the *default* MediaWiki diff schema to be changed back, Bugzilla is the place to go. I presumed this thread was referring instead to changing the English Wikipedia back, which is a local matter that can be handled by local sysops - you just need an RFC to establish the consensus in the first place. - Jarry1250 ^{[Deliberation needed]} 12:40, 26 April 2012 (UTC)

Please continue to "spam fixes on every section" - particularly the CSS fixup for the recent inaccessible diff change (I wish I had hyper-sensitive eyes like a web designer). It saves the rest of us having to work them out for ourselves and they're certainly needed - and appreciated. Andy Dingley (talk) 12:43, 26 April 2012 (UTC)

Matching spaces is horrible in between text that doesn't match otherwise (the Tetris look mentioned above). The solution is to make the diff a bit smarter: show whitespace diffs when they are not bordering any modified alphanums, otherwise oppress them. Nageh (talk) 23:15, 25 April 2012 (UTC)

• Cosmetic fiddling, introduction of very unwelcome horizontal scrollbars, and yet obvious bugs outstanding for years, whereby diff generator incorrectly flags large chunks of text as having changed when they are actually identical, are still not fixed: [2]. Someone's priorities are not correct. 86.160.221.37 (talk) 03:38, 27 April 2012 (UTC)

Editors are confused

I wanna add to that: editors are finding hard to follow other editors changes and that may rise arguments, I think functionality should not be violated for the mere "design", and who cares of design when this is not on top page but is only for those who follow the content? It really makes editing tricky and blindfolded.

And also design should not be a start of user's arguments. If you cannot follow this simple psychological pattern on your own, I can explain it for you: some things really irritate people and they are (1) not able to read text on paper or screen (too big or too small), (2) being taken something they liked - the previous way of displaying, (3) too much design sometimes rises stupidity - this is always a must in design "don't go on too much design esp. when not needed", maximum functionality and then maximum design not the vice versa, (4) when they don't understand other editor's changes they think the editors are doing something wrong on the page: that rises arguments. Also I don't like the 'new' menus, some other new stuff previously added, and there is an overall change in design now that is not only on diff views that makes it all crappy. I edit wiki just on habit but I'm sure with a little bit more effort like that you can stop people from editing :) if that is not actually the initial intend. --Aleksd (talk) 07:17, 27 April 2012 (UTC)

There we go again

OK I haven't edited for months now, and I haven't developed for weeks, but in al honesty; shouldn't we just call it quits ? Let's just call the Wikipedia software finished and NEVER EVER EVER EVER change it anymore, because no matter what you change, people simply are inconsiderate to anyone else's need other than their own personal rusty taste and go into the 'i'm used to this and whatever anyone else has thought up that I didn't think up just plain sucks'-mode. Really I have had it. Wikipedia is done, over, end-of-life as far as I care. Let's just put it back to MediaWiki 1.14, so the MediaWiki developers can just get on with developing MediaWiki again. Let's just fork the shit because this way MediaWiki will never EVER get anywhere. We should also stop informing the community, since they have a tendency of not reading that information anyway and then complaining about it (clearly demonstrated here). (Yes i'm having a bad day, and yes reading this discussion wasn't helping). —TheDJ (talk • contribs) 09:01, 27 April 2012 (UTC)

With all due respect, since you are having a bad day you should probably have waited before commenting, because you are completely misreading the complaints. Noone has said anything about not updating the Wikimedia software, on the contrary, these updates are badly needed. These particular complaints are about one specific design feature which for the most part obviously has made functionality worse, and as such is fairly controversial. That no ordinary Wikipedia editor has had a chance to provide input or voice their opinion on that particular matter before hand doesn't make it any better. --Saddhiyama (talk) 09:13, 27 April 2012 (UTC)

And by the way, new bigger font is awful, you can go on 90% view in Latin alphabet but Cyrillic looks terrible. Bet developers didn't think of that too, oh, yeah, this time it was not for the color-blinded but for those having myopia but of course you know that only the books for children have that big fonts... oh, well, who cares, you have a bad day. --Aleksd (talk) 10:33, 27 April 2012 (UTC)

DJ, I know that you are a voluntary developer, and I appreciate all the work you spend on this. But with all due respect, and I'm a regular reader of the Signpost and I am more or less trying to follow active discussions that affect Wikipedia in its entirety, but please show me any discussion that was widely publicized (via an RFC or whatnot) on this Wikipedia and where MediaWiki developers were actively seeking input from the community on the further development of the software. In contrast, I had regularly seen discussions where users were complaining about the new diff scheme, suggesting that it only be optional, yet the new scheme has been implemented without any way to switch back. No-one is saying MediaWiki development should be stopped; what we are saying is that before large efforts are being spent on new functionality some feedback should be sought from the community. This would potentially reduce a lot of frustration on both sides. Nageh (talk) 13:54, 27 April 2012 (UTC)

Scroll bars

I followed RedRose's advice to get the old look back, but it doesn't get rid of those distracting scrollbars. I really need the contrast in colors because my eyesight isn't that good and I need all the help I can get.— Vchimpanzee · talk · contributions · 20:13, 27 April 2012 (UTC)

I presume that by "my advice" you mean that you switched on Edokter's new gadget (Display diffs with the old yellow-and-green colors and design). Which scroll bars are these? --Redrose64 (talk) 20:31, 27 April 2012 (UTC)

This is the advice:

This has been available as a preference since 21:34 UTC yesterday; you need to switch on Preferences → Gadgets → Display diffs with the old yellow/green colors and design. --Redrose64 (talk) 11:10, 24 April 2012 (UTC)

This is what I tried, since it was in the discussion.— Vchimpanzee · talk · contributions · 20:45, 27 April 2012 (UTC)

I checked another diff and it didn't have scrollbars. So apparently what I saw to begin with is unique.— Vchimpanzee · talk · contributions · 21:34, 27 April 2012 (UTC)

Vchimpanzee, can you post a photo for that?

Or is that like this or this?

At first I think it's problem of bigger font of Chinese, but now it seems not...Justincheng12345 (talk) (urgent news here) 06:50, 28 April 2012 (UTC)

Cause found in the new CSS (table.diff td div: { overflow: auto }) with comment "As fallback (FF<3.5, Opera <10.5), scrollbars will be added for very wide cells instead of text overflowing or widening." This also casues IE (not FF or Chrome) to display scrollbars seemingly random, so perhaps this should be removed. — Edokter (talk) — 10:15, 28 April 2012 (UTC)

So, FF(newest version) shouldn't get this kind of scroll bars?Justincheng12345 (talk) (urgent news here) 15:43, 28 April 2012 (UTC)

Correct. Tested in FF 12. — Edokter (talk) — 21:41, 28 April 2012 (UTC)

So I'm the special cases..I'm also FF12..Never mind....not a big deal :)....Justincheng12345 (talk) (urgent news here) 12:14, 29 April 2012 (UTC)

I'm on Firefox. No scrollbars. I was on IE9 at home.— Vchimpanzee · talk · contributions · 19:13, 29 April 2012 (UTC)

Thanks for the new diffs

I heard the the new diffs were comiing because of an article in the SignPost a couple months ago. I read about it again at the techblog a couple weeks ago. Then I saw it deployed on the other projects a couple days ago. I like the new color scheme and find them much easier to read. I appreciate all the long hours the devs have put in to this update and just wanted to say thanks for all your work. Thanks. 64.40.54.80 (talk) 14:10, 28 April 2012 (UTC)

What a ridiculous post. I looked at the link provided by the anonymous developer editor in the previous post, and my reading of this Signpost article from only a month ago was that there were still problems, and that any new scheme would go through "a fresh round of discussions which it will have to survive if it is to make it onto Wikimedia wikis". And these discussions were where? And lasted how long? HuskyHuskie (talk) 20:55, 28 April 2012 (UTC)

What a pathetic post. Nobody could predict that the new diff scheme would be the default one with no option to switch back. Nobody could predict how broken the new diff scheme would be, exemplified by this diff. What the Signpost link you posted does show is that changes were being discussed on the wikitech-l mailing list rather than with its users. Nageh (talk) 21:19, 29 April 2012 (UTC)

Wow. I think ya'll's tone could be reduced a bit. Could you imagine talking like this to a real human, in person? --Jorm (WMF) (talk) 21:22, 29 April 2012 (UTC)

If we could do that, why would we be on Wikipedia? ▫ JohnnyMrNinja 21:32, 29 April 2012 (UTC)

Yes, I could imagine talking like this to someone in person, and no, I don't see a reason to tone down my comment. When even the developers understand that some change could be controversial then get to talk with its users if and how it will be implemented! Install it at mediawiki.org and invite users to test it! Even if new releases are first deployed at mediawiki.org, how should we know? Note that this case is not the only reason why I feel that the MediaWiki developers are pretty remote from its users, which I have expressed elsewhere as well. Nageh (talk) 21:45, 29 April 2012 (UTC)

Why would any developer want to engage when this is the style of conversation?--Jorm (WMF) (talk) 21:54, 29 April 2012 (UTC)

I think that's exactly it. You would think that writing content under a free license, that working in a collaborative space that invites anyone to join as equals, you would think it be humbling. Make you realize how replaceable editors are. Instead it is a seething nest of entitlement. There are so many editors that are considerate, or helpful, but their voices tend to get lost in the din. And Heaven forbid you want to make slight changes to functionality!!! Again, people that support or don't care are drowned by "solution in search of a problem" or similar garbage. The only measures that seem to get solid support are those limiting the abilities editors not currently in the community. Developers are paid to improve Wikipedia, and that is what they are attempting to do. No new feature has ever crashed the Wiki. They're worried that new editors aren't staying as long as they used to. If these changes make all of the angry, reactionary editors leave, that's two birds dead. ▫ JohnnyMrNinja 01:12, 30 April 2012 (UTC)

"No new feature has ever crashed the Wiki." Yeah, right. --Redrose64 (talk) 13:01, 30 April 2012 (UTC)

That's exactly the kind of attitude developers seem to be taking. They are like "oh, we are being payed, why should we listen to the opinions of mere voluntary, unpaid editors if they don't please us?". Sorry for the harsh tone, but this is the impression your last post is giving me. I think a lot of criticism presented on this page about the new change is substantial and constructive, so feel free to dismiss my complaint even though I certainly think it is warranted. And I really don't understand why Johnny accuses me of complaining about a change of functionality; what I am complaining about is a reduction of functionality (as exemplified), the seeming pathetic post of the OP in light of this new functionality (apologizes to the OP for my attack), and last but not least the ignorance of developers to user input prior to the deployment of 1.20wmf1 such as with this bug report, which causes TeX output to be broken and was acquitted with "This alone wouldn't be a high priority.". Thinking my complaint was unwarranted? Yeah, alright. I just get the feeling again that developers won't care simply because they don't need to. Sigh. Nageh (talk) 09:46, 30 April 2012 (UTC)

Btw, I am really curious as to why Jorm comments only and solely in this discussion which was not even directed at the developers on this whole page of technical discussions much more directly directed at developers. Nageh (talk) 09:52, 30 April 2012 (UTC)

I commented because the comments left by yourself and HuskyHuskie were rude and I felt that I should point that out. Calling the IP editor's opinion "pathetic" and "ridiculous" is simply rude, and I see it far too often. This style of conversation is exactly why few developers voluntarily engage. It isn't that anyone on staff feels like they're superior, or don't need to listen to volunteers - far from it. It's because of the hostility.--Jorm (WMF) (talk) 16:14, 30 April 2012 (UTC)

There may be the slightest possibility of a tiny chance that my post is exactly what it is. That I like the new diffs and wanted to thank the devs for their efforts. But I could be mistaken. I'll let you be the judge. 64.40.57.160 (talk) 02:29, 30 April 2012 (UTC)

Anon, you may actually be an editor and nothing more. But I would venture to say that most editors who not only read the Signpost regularly, but who also frequent tech blogs, likely have an account and a user name, and would therefore be willing to lend that extra bit of weight to their comments. Given that your reaction is clearly in the minority here, your anon status, combined with your extensive awareness of prior discussions on this matter (discussions which most of us had not heard of), all of this just combines into the possibility that you are something more than a simple editor like the rest of us who comment here. If I'm wrong, sorry, but, contrary to what User:Jorm (WMF) implies, I don't think my tone was in any way out of line. The developers have engineered a change that reduces functionality (not merely "changes" it), and that is naturally frustrating to those editors whose voluntary work is dependent upon a tool which has now been compromised, such as those editors who will now have greater difficulty discerning stealth vandals. HuskyHuskie (talk) 03:45, 30 April 2012 (UTC)

Thanks for the apology, HuskyHuskie. I appreciate it. For the record, I've been editing since 2003. I spend most my time referencing articles and cleaning up BLPs I have a concern about. I rarely stray into meta areas because of WP:ABF issues I've dealt with in the past, but I do offer encouragement to others when I think it will help a situation. That's why I posted the thanks message here. I was obviously wrong about it helping the situation, so if somebody would like to hat this section, I wouldn't mind. Whatever people think is best. 64.40.57.160 (talk) 04:30, 30 April 2012 (UTC)

Well, heaven knows that on several occasions I have unintentionally flared up a situation that I meant to calm down; indeed, much more than this small matter. Sorry for all the fireworks. I would guess that yours, like most today, is a dynamic IP, so I can't say I'll necessarily see you around, but I can say I was glad to have made your acquaintance here today. Happy trails. HuskyHuskie (talk) 04:59, 30 April 2012 (UTC)

Commons images show usage in long deleted articles at en wiki

Tracked in Phabricator
Task T38277

Today I ran onto a Commons image that shows uage in three articles here at en wiki but all three articles were deleted more than two years ago. This is not the first time I ran onto usage in deleted en wiki articles. Does anyone have an idea where to locate the database issue? --Denniss (talk) 10:19, 24 April 2012 (UTC)

Was about to point you to your own thread on Commons for a second there :P The erroneous entries are in globalimagelinks, a table on Commons. Presumably page deletions do not trigger the correct hook? A bug should be filed (or found if not already filed). - Jarry1250 ^{[Deliberation needed]} 11:28, 24 April 2012 (UTC)

I've opened a bug accordingly. - Jarry1250 ^{[Deliberation needed]} 16:31, 26 April 2012 (UTC)

Strange ref error message

Resolved

Here's a little riddle for our tech gurus: why is it that the page Talk:Macedonian language currently has an automatic Cite error warning (for a ref tag used on the page without a following "references" section), but that warning is written in Macedonian? I am seeing a big red error message at the bottom of the page saying "Грешка при цитирањето: Статијата има ознаки <ref>, но не ја најдов потребната ознака {{наводи}} (или <references/>)", which is obviously the mk version of the "There are <ref> tags on this page, but the references will not show without a {{Reflist}} template or a <references /> tag". I've seen that same thing on some other page too. Fut.Perf. ☼ 13:12, 24 April 2012 (UTC)

(Not a tech guru, but I've seen this mentioned before) This is bugzilla:31216. Apparently you can fix it by purging the page. -- John of Reading (talk) 14:09, 24 April 2012 (UTC)

Yes. The cite extension produces messages in the user interface language of the user who last generated a parsed version of the page (i.e., by purging or editing it). The default English-language messages include some magic that automatically hides them on talk pages, but the Macedonian-language version does not. If someone with their interface language set to English edits or purges the page, it gets re-parsed with English-language messages. Ucucha (talk) 15:09, 24 April 2012 (UTC)

I purged it, and the cite error disappeared. jcgoble3 (talk) 17:50, 24 April 2012 (UTC)

Wow. It's a strange, strange wiki. :-) Fut.Perf. ☼ 19:02, 24 April 2012 (UTC)

Edit window changing

When I go to edit a page or section, the edit window appears, and I click into it and start typing. I'm a keyboard watcher, not a touch typist, and often I find that the window has changed font, gone back to the top of the page or section, and my typing has vanished like the morning dew. Sometimes I see it doing this before I start typing, and other times it doesn't change at all. I find this extremely irritating, especially if I am trying to get something in quickly. I use Monobook on Firefox 10.something (they started badgering me about 11 a couple of days after I'd installed 10.something, this being a new machine to me). This has gone on for some time now, but I've only just come in here to complain about diffs (and thank someone for the new gadget as it turns out). I can't see the point of this overlaying of the edit window, especially as both fonts are non-proportional (or monospaced if you prefer). Is there any way of stopping this - don't suggest using Vector - and why does it do it? Peridon (talk) 13:13, 24 April 2012 (UTC)

I've found that it happens in Vector; and it also happens in Monobook, but only when I'm using the whistles-and-bells toolbar. See Wikipedia:RefToolbar - disable the enhanced editing toolbar at Preferences → Editing → Usability features so that you're using RefToolbar 1.0 - does that fix it? --Redrose64 (talk) 16:48, 24 April 2012 (UTC)

I use the toolbar 2.0a - essential for accents, quick nowikiing and so on. (I miss the quick and easy accent entry I had when working on Macs...). I notice that the gadget for changing the diffs back to the old style also does its work by overlaying. Why can't these things replace instead of overlay? And on a sideline, about the toolbar, why can I find no copyright sign in it? I know that it isn't used in article work, but when explaining copyright matters it is embarrassing to have to refer to 'a c in a circle'. Peridon (talk) 17:38, 24 April 2012 (UTC)

All these things are available in the edit tools - this is below the "Save page" etc. buttons, to the right of the drop-down menu. By default (when the menu shows "Insert"), there are the following:

– — ‘’ “” ° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ √ ← → · §

If you select "Wiki markup", you get those plus several others like <nowiki></nowiki>. The other menu options provide other selections; for example, accented letters are mostly under "Latin", whilst © is under "Symbols". The various blue links in there will insert the appropriate symbol or construct at the current cursor position. For those like <ref></ref> which are designed to enclose text, there are two ways of using them: if you just position the cursor and hit <ref></ref> it will insert the construct and leave the cursor in the middle so that you can enter the reference at the proper place; alternatively, you can enter the reference first, mark it with your mouse and then hit <ref></ref>, and the marked text is preceded by the <ref> and followed by the </ref>. --Redrose64 (talk) 19:12, 24 April 2012 (UTC)

Thanks for that. I'd never seen that down there. I've only been here for four years so far... Peridon (talk) 19:44, 24 April 2012 (UTC)

Change notifcations to editors

Further to #New "diff" view is horrible and illegible above - it would be nice if we got explicit notification of these changes (and how to configure them) and/or other new things added to Preferences. The list of "extras" or configuration items seems to grow over time, but I don't know unless I check it occasionally. If we can be notified explicitly of other assorted items (eg WP:PEND), why can't we be notified of changes to the UI? Mitch Ames (talk) 13:27, 24 April 2012 (UTC)

UI changes are generally well trialled in some quarters, if you know where to look (the Signpost for example, where I am responsible for writing them up. Diff colouration was also discussed at length here on VPT a couple of months back following one of my reports.

More notifications is probably better, nevertheless: but how best do you think notifications should be sent out? - Jarry1250 ^{[Deliberation needed]} 14:14, 24 April 2012 (UTC)

I don't want to sound overly touchy but it seems like these updates always affect the scripts and apps like twinkle when they are put out. Most of the time these apps are quickly and easily fixed but that may not always be the case. It seems to me that in most cases the programmers know what types of things in these upgrades might cause problems for the scripts and apps (java changes, changes to the naming schema, etc.) but the apps ans scripts aren't notified until after the fact. I think it would be helpful if the developers had a list of these things that might be affected and drop a note on the talk page a week or so before hand. There can't be more than a couple dozen primary ones (such as AWB, twinkle and the ones under the gadgets tab). Plus it could additionally allow an opt in for users and bot operators who might find it useful. Kumioko (talk) 16:15, 24 April 2012 (UTC)

(On a related issue, note that with RL2 coming in, there will be a central repository across different projects, allowing the global community to benefit from the kind of quick JavaScript maintenance that pervades on en.wp.) I mean, essentially what you're talking about there is a mailing list style notification for release notes, which shouldn't be too tricky if there was demand. More the issue is that (speaking as one of them) maintainers of software built on top of other software don't have the time to -guess what might break; it's easier to just wait and see. - Jarry1250 ^{[Deliberation needed]} 16:33, 24 April 2012 (UTC)

Jarry1250, a simple notification at the top of the page (with a "dismiss" link) when I go to any Wikipedia page the first time (or until I dismiss it) after that notification is posted. (It needs to be any page, not just Main Page, because typically I don't use Main Page, I go straight to My watchlist.) We already get them for some things anyway - eg when the pending revisions trial started. These are simple, not overly obtrusive, easy to dismiss, typically we only see them once. The current notifications are sometimes useful and generally quite acceptable. Mitch Ames (talk) 03:06, 25 April 2012 (UTC)

@Mitch Ames: if you put MediaWiki:Gadgets-definition on your watchlist, you'll be notified when gadgets are added or removed. To be notified when they're amended, you need to watchlist the .css and/or .js pages of the specific gadgets that you're interested in. Each entry in MediaWiki:Gadgets-definition consists of two or more elements, separated by pipes; these elements are partial filenames. The file indicated by first element is the summary text which is displayed at Preferences → Gadgets, the others are the actual gadget code. To form the actual filename, you should ignore any portions inside single square brackets; then the remainder of each element should be prefixed with MediaWiki:Gadget- to make the filenames which comprise the gadget. For example:

• the first entry listed is modrollback|modrollback.js, so its textual summary is at MediaWiki:Gadget-modrollback and the gadget code is MediaWiki:Gadget-modrollback.js
• the one much mentioned above which fixes the diff colours is shown as OldDiff[ResourceLoader]|OldDiff.css, so its textual summary is at MediaWiki:Gadget-OldDiff and the gadget code is at MediaWiki:Gadget-OldDiff.css
• a more complex example is the entry for Twinkle: this is Twinkle[ResourceLoader|dependencies=mediawiki.util,jquery.ui.dialog,jquery.tipsy]|morebits.js|morebits.css|Twinkle.js, so the text summary is MediaWiki:Gadget-Twinkle and the gadget code is the three files MediaWiki:Gadget-morebits.js, MediaWiki:Gadget-morebits.css and MediaWiki:Gadget-Twinkle.js.

All of these may be watchlisted, even if you don't have the user rights necessary to alter them. --Redrose64 (talk) 17:16, 24 April 2012 (UTC)

Thank-you, that could be quite useful. Are there equivalents for tabs other than Gadgets? A sentence or two on Help:Preferences explaining how to monitor for new options would probably be a good idea. Or more likely a sentence pointing to another page with the details (as as you described above). Mitch Ames (talk) 03:10, 25 April 2012 (UTC)

AFAIK, the Gadgets tab is the only one in Preferences which is customisable to any great extent. All the others come from the MediaWiki software. This is why the arrangement of the preferences is pretty much the same for all the Wikipedias in different languages, but the Gadgets tab varies enormously. For example, the Italian Wikipedia has many more gadgets than English (several of them customise the toolbar). By contrast, the Slovak Wikipedia has only five; and the Welsh Wikipedia has none at all. It follows that any changes to the available preferences usually happen at the same time across all the Wikipedias, and coincide with a MedaiWiki rollout; but such rollout doesn't affect the content of the Gadgets tab. --Redrose64 (talk) 19:03, 25 April 2012 (UTC)

• One thing that's been clear for a long while is that the developer community is... opaque, to the regular en.wikipedia community. This isn't even close to the first time that this issue has come up. People point to the Signpost (which is perfectly understandable, especially from Jarry1250 who usually writes it) and the various mailing lists, but those "solutions" rather miss the point. The developer community is very stand-offish. They've successfully limited their exposure to the en.wikipedia community for years, by filtering everything through second hand sources like the Signpost and controllable channels such as the mailing lists. I understand their point of view on this as well, because bogging down the devs with the sorts of discussions that take place on this page wouldn't be a wise use of resources. Still, there's got to be a better way than this.
  — V = IR (Talk • Contribs) 21:46, 25 April 2012 (UTC)

  No, no, that might be true but it's not a fair assessment: it's a two way thing. Developers don't on the whole come here, Wikimedians don't generally go there. So of course there exist devices whereby both groups can meet in the middle (mailing lists, newsletters); it seems unfair to say that things would be better if sod it, you know, they came over here more often, without adding that things would also be better if Wikimedians went over there more often (both being time-consuming activities that the "visiting" party does not enjoy very much). In any case, in my experience developers are often open to suggestions on how to better publicise their activities; pinging VPT with items from http://wikitech.wikimedia.org/view/Software_deployments, perhaps? Or some other concrete proposal? - Jarry1250 ^{[Deliberation needed]} 13:17, 26 April 2012 (UTC)

  Yea, well... Sorry, but I stand by my opinion. I mean, their all "over there" with their own wiki (or is it: this one? Or maybe it's this one?) Even if you do go there, "outsiders" get shouted at for bringing things up all the time (don't even try to deny it), if not simply ignored (the most likely outcome). There isn't supposed to be a divide, but the developer community is decidedly opaque to those who aren't members (and I'd say that it is even to marginal members. I'm hardly completely unfamiliar with the developer community). If anyone wants a concrete suggestion on improving communication, how about creating something similar to the Village Pump on mediawiki.org? I'm sure that there are other ideas that could be developed, if there was a central place to do so (that wasn't a damn mailing list. There's no way I'm posting to a public mailing list.)
  — V = IR (Talk • Contribs) 19:42, 26 April 2012 (UTC)

  I never said I disagreed with you part of the analysis, I was just pointing out that attributing unwelcomeness and unwilling to engage to the other party is to miss how one can be more open and inviting oneself. That said, a VP on MediaWiki.org might be a useful idea. - Jarry1250 ^{[Deliberation needed]} 21:04, 26 April 2012 (UTC)

Possible gliltch with new diff engine

I have received one report that my User:Ohconfucius/script/MOSNUM dates.js script is now working only intermittently for said user. The user uses FF11.0. I also use FF11, but have not been able at all to reproduce the problems reported; I see no other bug reports other than the *ugh, please give me the old diff engine back* variety. So the question is: is this causing problems with other scripts? --Ohconfucius ^¡digame! 15:42, 24 April 2012 (UTC)

The diff engine hasn't changed, only the display; it could be another change in 1.20wmf1, of course, but can't strictly speaking be related. - Jarry1250 ^{[Deliberation needed]} 15:48, 24 April 2012 (UTC)

Im not getting the arrows to expand the groups of edits

With this new change I no longer see the little black arrow next to the article that lets you expand the list of edits to that article. I think its an extra gadget but not sure exactly which one. Either way its not working now. BTW I am currently using IE7. Kumioko (talk) 15:47, 24 April 2012 (UTC)

I flagged this up a couple of days ago at the Help Desk Wikipedia:Help_desk#Watchlist_changes and they advised me to raise the subject here, which I did above at Wikipedia:Village_pump_(technical)#Cursor_missing_-_enhanced_watchlist. User:Elizium23 has been helpful, but the problem still hasn't been solved. I'm on IE8. --GuillaumeTell 16:48, 26 April 2012 (UTC)

Recent changes to the difference screen

I notice the recent changes to the comparison screens when viewing the differences between different pages of an article. The template used in the layout looks nice. Is it available for use in regular pages? It resembles the {{framework}} template I imported from the Italian Wikipedia last year. --Jeremy (blah blah • I did it!) 20:42, 24 April 2012 (UTC)

Failure to open edit window

This is not me, but someone at Wikipedia:New_contributors'_help_page/questions#A_PHP_download_gets_in_the_way has a peculiar problem when trying to edit Wikipedia. Instead of pulling up the edit window, his browser simply downloads index.php and stops. Someguy1221 (talk) 21:49, 24 April 2012 (UTC)

This is probably due to the "Use an external editor" preference being checked, as is explained in this section of the VPT. I have proposed this theory to the complaining user in the second question s/he posted to the New contributor's help page. If this theory doesn't solve the user's problem, then it obviously warrants further discussion. Robert Skyhawk ^{(T C)} 23:07, 24 April 2012 (UTC)

Wikipedia and Smart Phone Power Usage

Quote from [ http://www.newscientist.com/blogs/onepercent/2012/04/bloated-website-code-drains-yo.html ]

"Wikipedia uses a custom file Javascript along with a generic library to collapse and expand the various sections on a page, but much of the library goes unused. By rewriting the site's Javascript to just perform the required function, Thiagarajan and colleagues were able to reduce the energy used from 15 to 9.5 Joules."

"Making similar changes to the CSS files and images, they were able to reduce the total energy used in loading Wikipedia from 35 to 25 Joules, a saving of 29 per cent. They say that as well as making websites fast and good looking, web designers should also take into account the energy used in loading the page" --Guy Macon (talk) 22:26, 24 April 2012 (UTC)

I'm not sure how often devs actually look at this page. If you were interested enough you could poke the appropriate person (Pchang seems to be one such person) or for more widespread developer discussion, create a thread on wikitech-l. Killiondude (talk) 00:55, 25 April 2012 (UTC)

Thanks! --Guy Macon (talk) 00:59, 25 April 2012 (UTC)

Not only we devs look at this page regularly, but also we've been butthurt about that article since it was published, before this report. The authors don't seem to be interested in a more reasonable analysis with real usage patterns, so we're going to publish a rebuttal soon. Keep an eye on Wikimedia Blog! ;) Max Semenik (talk) 07:58, 25 April 2012 (UTC)

This would be an excellent Wikipedia Signpost article. --Guy Macon (talk) 15:29, 25 April 2012 (UTC)

Just what I was thinking, actually. ITN or Tech (that'll be me then), probably. - Jarry1250 ^{[Deliberation needed]} 16:48, 25 April 2012 (UTC)

http://blog.wikimedia.org/2012/04/26/analyzing-mobile-browser-energy-consumption/ ▫ JohnnyMrNinja 00:47, 27 April 2012 (UTC)

Query strings on Wikipedia

I think it would be cleaner if the Edit tab etc. link to, for instance, /wiki/Wikipedia:Village_pump_(technical)?action=edit rather than the verbose /w/index.php?title=Wikipedia:Village_pump_(technical)&action=edit. The former works just as effectively as the latter for some reason, and they already do this on Wikia. Why not here? 68.173.113.106 (talk) 02:12, 25 April 2012 (UTC)

There's been some talk about cleaner URLs; cf. bugzilla:17981. --MZMcBride (talk) 02:46, 25 April 2012 (UTC)

System logging me out

Tracked in Phabricator
Task T37900

Every time I edit today, the system logs me out. I know the problem has been raised previously, but it seems to be much more of a problem today than ever before. I am in the UK. Ghmyrtle (talk) 11:41, 25 April 2012 (UTC)

I've reopened and update bug #35900 accordingly. - Jarry1250 ^{[Deliberation needed]} 12:43, 25 April 2012 (UTC)

I just wanted to add that I have also been getting this problem. It most commonly occurs when I back page to a previously edited page and with Mozilla firefox. I have not had the problem with IE. Kumioko (talk) 16:32, 25 April 2012 (UTC)

I can confirm that this is happening to me too (FF5). It usually happens in this fashion: the page - either loading an article, an edit window, or a preview - loads rather (more) slowly (than usual), and it comes up as if I was logged out. Refreshing "magically" logs me back in. - The Bushranger _{One ping only} 21:35, 26 April 2012 (UTC)

See above at #Having_trouble_staying_logged_in. Btw, I've added it as a suggestion at WP:SIGNPOST. Simply south...... going on editing sprees for just 6 years (as of 28/03/2006) 22:01, 26 April 2012 (UTC)

Old diff gadget

When using the gadget to get the old diff colours, it displays as the new diffs then jumps to the old diff, is there a way to stop the jump between the 2 diffs, the jump in the layout is annoying? Keith D (talk) 13:20, 25 April 2012 (UTC)

That's the way ResourceLoader loads gadgets. I could try loading it in the top queue, but I don't know what the effects are. — Edokter (talk) — 18:07, 25 April 2012 (UTC)

Can't Tap Status Bar to Scroll Up. Bug?

Tracked in Phabricator
Task T38261

Running iOS 5.1 on my iPhone 4S. In Safari, I'm having trouble tapping the status bar to scroll up on most large articles (for example, United States, Cambodia, Tennis) when in mobile view. When I switch to desktop view, everything is normal. Is this bug? I wasn't sure if this issue was worth a bug report. Scott523 (talk) 17:07, 25 April 2012 (UTC)

This issue has been resolved and will be deployed within several days. Max Semenik (talk) 18:20, 26 April 2012 (UTC)

Technical difficulties?

"Sorry! This site is experiencing technical difficulties."

I'm suddenly getting this every time I submit an edit, though I stay logged in, and the edits are being submitted. Anyone else getting this? Equazcion ^(talk) 00:51, 26 Apr 2012 (UTC)

Full text:

Sorry! This site is experiencing technical difficulties.

Try waiting a few minutes and reloading.

(Cannot contact the database server: Unknown error (10.0.6.41)) Equazcion ^(talk) 00:53, 26 Apr 2012 (UTC)

I'm receiving the same error. I can't perform any deletions because of it. — ξ^xplicit 00:54, 26 April 2012 (UTC)

I receive the same error message but my edits seem to be going through. Tiderolls 00:55, 26 April 2012 (UTC)

Seems to be okay for now... Equazcion ^(talk) 01:23, 26 Apr 2012 (UTC)

Failing to connect DB server?

When I do anything involving an edit (rollback or a normal edit), it says there are technical difficulties, specifically that the connection to 10.0.6.41 failed. However, the edit is saved nevertheless.--Jasper Deng (talk) 00:52, 26 April 2012 (UTC)

Sorry for being late to the party, but are you guys all using Internet Explorer 9? Whenever I use it, it does that to me every time I save an edit. Yet the edit goes through. Chrome is much more forgiving overall, though on occasion it does sporadically log me out, then log me back in upon refresh. Calabe1992 03:17, 27 April 2012 (UTC)

I'm on Firefox 12, and only got this during the brief period I reported above. Otherwise I've been fine here. IE8 seems to be working fine here too when submitting edits. I don't have IE9, otherwise I'd test. Equazcion ^(talk) 03:21, 27 Apr 2012 (UTC)

OK, this is weird. The exact issue I described above has just happened again multiple times (logging out then back in) and now I just got a loss of session data while trying to save this edit. Windows 7/Google Chrome here. Calabe1992 03:27, 27 April 2012 (UTC)

I actually just got a loss of session data myself suddenly. I don't think it's related to your ongoing database connection issue, but I could be wrong. Equazcion ^(talk) 03:30, 27 Apr 2012 (UTC)

A separate problem - alternative page

Over the past week I have found that sometimes when I first load a page, the page changes text to Times New Roman and the layout and other things are all over the place. Refreshing the page seems to sort it out. I am just wondering if it is a problem on my end or is it happening to anyone else? Simply south...... going on editing sprees for just 6 years (as of 28/03/2006) 18:46, 26 April 2012 (UTC)

It means that for whatever reason, not all of the CSS files (style sheets) were obtained by your browser, so your browser has fallen back onto its default styling, which for some browsers will indeed be a font similar to Times New Roman.

There seems to be a general problem with slow servers, with various effects: people losing session data, being logged out, images not coming back, etc. Plenty on this further up the page. --Redrose64 (talk) 19:14, 26 April 2012 (UTC)

Version 1.0 Editorial Team

The Wikipedia 1.0 Editorial Team, which organizes offline releases of Wikipedia, has begun working on our next release—the version 0.9. Now we're trying to identify which members are still active and attract new members, so we can start the work. The issues related to the version 0.9 are being discussed here. Please add your comments to the discussion, and let us know here if you would like to be involved. Thank you. Ruslik_Zero 18:51, 26 April 2012 (UTC)

So you're going backwards from 1.0 to 0.9?--ukexpat (talk) 22:52, 26 April 2012 (UTC)

Nope, they're going forwards from 0.8 to 0.9. Graham87 03:00, 27 April 2012 (UTC)

Script/Gadget suggestion

Would it be possible for someone to create a script or gadget that would add a link to the corresponding page when viewing a category? For example, if I am reviewing a category that shows the article it would have something like (t) in parens after it representing the talk page or if I was viewing a category with a talk page it would show something like (A) for the corresponding article? I find it unnecessarily time consuming to have to click on one to get to the other andn it seems like it should be possible to make something like this. Kumioko (talk) 19:37, 26 April 2012 (UTC)

Not sure I understand. It's a one to many relationship between categories and articles. You want a link to an article of the same name as the category? Like a link to United States on Category:United States? — Bility (talk) 22:20, 26 April 2012 (UTC)

I think he wants talk page links next to article links, and article links next to talk page links, no matter which are present in the category listing. That shouldn't be too hard to script. Equazcion ^(talk) 22:28, 26 Apr 2012 (UTC)

I made User:Equazcion/CatListMainTalkLinks :) Equazcion ^(talk) 07:58, 27 Apr 2012 (UTC)

Thats great thanks. That helps a lotKumioko (talk) 14:03, 27 April 2012 (UTC)

"Show differences"

I don't know where else to put this, or if I'm late to this particular party, but for the love of all things Holy, why has the "show differences" function been ruined? Not "changed", "improved", "modified", or "altered", but ruined? It looks like Google+ has been let loose on the Wikiproject, and as such, what used to be clear has been turned obscure and abstract. The changes made are no longer clear, which surely must be the whole point of giving editors the right to see the edits made in such a way? Was this put to a vote? Was there a banner across the top of the screen?

Modernisation for the sake of it often ends, as this has done, with an end product totally at odds with its purpose. When I choose "compare differences", I want to see just that. At the moment, I can see different shades of background. Not good enough. doktorb _words^deeds 22:37, 26 April 2012 (UTC)

Take a look just above you here #New_.22diff.22_view_is_horrible_and_illegible for earlier discussion. Fortunately you can change back to the old way of seeing changes and I did and it works find. MarnetteD | Talk 22:45, 26 April 2012 (UTC)

I am very happy for cutting edge coders thinking of ways to improve the interface. I am sure that to them, adding a revert gadget is a great solution but:

• I will vote for a LTS version over a beta version for production work.
• If I have 15 mins to catch up on my 900 item watch list- I don't want to lose it in Gadget chasing. I think the cutting edge coders forget that the task is creating and maintaining a body of content and the correct approach should have been an opt-in button.
• I haven't time to follow red green pink arguments- but I report that on a Thinkpad R50e Running Ubuntu 10.4LTS the diff beta version doesn't work. Test must always be done on legacy machines.

My objection is the vertical spacing and the bordering of paragraphs that eats too much real-estate.--ClemRutter (talk) 08:27, 27 April 2012 (UTC)

I'm glad it's not just me objecting to the extra vertical space. Mitch Ames (talk) 10:56, 27 April 2012 (UTC)

I also asked about this when the new format was discussed on wikitech mailing list last month. Helder 02:42, 28 April 2012 (UTC)

Interwiki bots think that Austin Maxi is Volkswagen Golf VI

They keep adding the iw link ro:Volkswagen Golf VI to Austin Maxi. I reverted once but then another bot reverted me. Does anyone know what is going on? Δρ.Κ. ^{λόγοςπράξις} 01:35, 27 April 2012 (UTC)

Bad interwiki data on the ro: article (now removed). Two bots feeding from the same source ... the bad ro: data was only added today. Should be at an end now (unless the ro: article is reverted or there are more interwiki bots feeding from a now stale source. --Tagishsimon (talk) 01:47, 27 April 2012 (UTC)

Thank you very much Tagishsimon. It's good to know they are not trying to replace the human editors, at least not yet. :) Δρ.Κ. ^{λόγοςπράξις} 01:53, 27 April 2012 (UTC)

It did look rather ominous. --Tagishsimon (talk) 01:53, 27 April 2012 (UTC)

Indeed. Lol. Δρ.Κ. ^{λόγοςπράξις} 01:56, 27 April 2012 (UTC)

I for one welcome our new botty-bot overlords. - The Bushranger _{One ping only} 02:10, 27 April 2012 (UTC)

I never counted on human collaborators. Resistance may be futile. The situation is more advanced than I thought. :) Δρ.Κ. ^{λόγοςπράξις} 02:27, 27 April 2012 (UTC)

The Romanian article got reverted back to the wrong version by another bot leading to yet another reversion in the en wiki article. Δρ.Κ. ^{λόγοςπράξις} 03:56, 27 April 2012 (UTC)

I've blocked the bots that have modified the page from changing it again for now. Something tells me another bot will try it, however, before this gets addressed. Calabe1992 04:22, 27 April 2012 (UTC)

Good idea. Meanwhile I reverted the bot on ro.wiki on the VW Golf article and moved the interwiki links to the ro.Austin Maxi article, which was created only yesterday. I wonder if that has anything to do with these renegade bots. Δρ.Κ. ^{λόγοςπράξις} 04:51, 27 April 2012 (UTC)

Cool. I have the article on my watchlist, and if no other bots seem to have come after it within the next day (or if someone objects to it for another reason), my tag probably can be removed. Calabe1992 04:56, 27 April 2012 (UTC)

Great. Thanks. Δρ.Κ. ^{λόγοςπράξις} 05:05, 27 April 2012 (UTC)

Removed the tag for now since I'm not seeing any new bot activity. Calabe1992 14:02, 27 April 2012 (UTC)

So long as at least one article with a bad interlanguage link (ILL) exists on any language, a bot will propagate that to all the other languages again - and in the reverse directions too. It's not just one or two bots that do this, there are dozens at it. The trick is to fool the bots into thinking that the link is there, so that they won't try to re-add it; but at the same time, render the link invisible. You do both of these by putting the bad link inside HTML comment tags, like this. You then need to go to each page that is or was linked in other languages (whether that was a good or bad ILL), check for bad ILLs on that article and hide those too, as here and here. Hooray for WP:SUL! --Redrose64 (talk) 19:06, 27 April 2012 (UTC)

Downlevel test wiki

Anyone know of a downlevel version of Wikipedia I can use for test? In troubleshooting some issues, I would like to test some templates on 1.18 or 1.19. https://test.wikipedia.org, https://test1.wikipedia.org and https://test3.wikipedia.org all run 1.20. ---— Gadget850 (Ed) ^talk 15:03, 27 April 2012 (UTC)

Wikia wikis are still running 1.16.5. Will that work? jcgoble3 (talk) 15:24, 27 April 2012 (UTC)

Terms of use banner "close" icon

I'm not sure if this is the correct place to mention this, but every time I see the cross-in-circle for the Terms of Use banner currently sitting atop every page, I mistake it for the superficially similar cross-in-circle icon for a Good Article. Then I find myself wondering why seemingly poor articles are marked as Good :) Is there any chance of changing that close button to use a different icon?  — Amakuru (talk) 15:21, 27 April 2012 (UTC)

Database lag

181 seconds so far. Taking all bets. Equazcion ^(talk) 19:00, 27 Apr 2012 (UTC)

Aw man, it's going down already. Equazcion ^(talk) 19:03, 27 Apr 2012 (UTC)

Display does not correspond to edit

In this diff, note that the italics code — ''No original research'' — in top of the page where the diff is shown, displays incorrectly as No original research in the lower part of the page where the text is shown. --Bob K31416 (talk) 21:43, 27 April 2012 (UTC)

If a template is transcluded more than once without arguments then the result of the first transclusion is copied to the later occurrences for efficiency. This happens with {{reflist}} in Draft 8 and Draft 9. Later in Draft 10 there is a transclusion saying {{reflist|2}}. This has parameters so a real transclusion is performed there instead of copying, and the ref with italics in Draft 9 is shown there. PrimeHunter (talk) 22:11, 27 April 2012 (UTC)

Thank you! --Bob K31416 (talk) 22:34, 27 April 2012 (UTC)

Okay that was impressive. Equazcion ^(talk) 23:25, 27 Apr 2012 (UTC)

Thanks! It had me fooled for a while. The nearly identical references made it tricky. PrimeHunter (talk) 00:48, 28 April 2012 (UTC)

Named refs and #time errors

Got an odd issue with named ref tags and #time functions that error.

If I have the following code (at User:WOSlinker/time ref error):

===Header===
* Text <ref name="fred">Plain Reference</ref>
* Date {{#time:Y-m-d|2011-17-11}}
* Text <ref name="fred"/>

===References===
{{#tag:references}}

and the references generate a cite error.

If I then swap around the two refs then it works or if I fix the #time function so that it does not error then it also works. Looks like a bug to me.

{{date}} also causes hidden errors, so code such as (at User:WOSlinker/date ref error)

===Header===
* Text <ref name="fred">Plain Reference</ref>
* Date {{date|2011-11-11}}
* Text <ref name="fred"/>

===References===
{{#tag:references}}

which contains a valid date still produces a cite error. -- WOSlinker (talk) 22:54, 27 April 2012 (UTC)

I is odd: something is happening under the hood. John of Reading and I have been looking at the same issues; see Help talk:Cite errors#References in video game infoboxes aren't joined up. I was looking at #time errors and added a tracking category and started noticing that {{dts}} and related templates hide the errors messages. I proposed a class at MediaWiki talk:Common.css#Parser function errors to make these visible per personal CSS, but I need to think on that a bit now. ---— Gadget850 (Ed) ^talk 23:06, 27 April 2012 (UTC)

Even more odd is that it works correctly on commons, commons:User:WOSlinker/time_ref_error -- WOSlinker (talk) 23:17, 27 April 2012 (UTC)

Looks like this was caused by my changes to MediaWiki:Pfunc time error. We can't use a template in this interface page to control how the error is triggered like we do with cite errors. I had reverted before while testing other issues, but did not see this issue. There is still some odd interaction with {{dts}} and List-defined references. ---— Gadget850 (Ed) ^talk 01:15, 28 April 2012 (UTC)

That's still a bug. It looks like the problem is that MessageCache (used a few levels inside wfMsgForContent) grabs the global $wgParser, and then calls transformMsg() on it which calls preprocess() (rather than recursivePreprocess()), which calls clearState() on the parser, which of course clears the Cite extension's state. OTOH, I don't know whether replacing the preprocess call with recursivePreprocess would break other things. Anomie⚔ 02:54, 28 April 2012 (UTC)

I can see one mistake. Compare the wikitext on the two lines below to the results.

{{#time:Y-m-d|2011-17-11}} →

{{#time:Y-m-d|2011-11-17}} → 2011-11-17

ISO dates are year, month, and date. I don't think there is a bug here.– Allen4names 03:54, 28 April 2012 (UTC)

Yeah, that's the point of this thread my friend. — Bility (talk) 05:36, 28 April 2012 (UTC)

I think he's saying since the month needs to be the second time value, and there is no month 17, that's why an error is being thrown. Equazcion ^(talk) 07:07, 28 Apr 2012 (UTC)

It's working fine now, with just the time error and no cite error anymore. -- WOSlinker (talk) 08:22, 28 April 2012 (UTC)

Because Gadget850 reverted the change to MediaWiki:Pfunc time error, which is what triggers the bug. Anomie⚔ 19:27, 28 April 2012 (UTC)

You're missing the point. The bug is that when MediaWiki:Pfunc time error transcludes a template, anything that causes an error in the #time parser function also makes MediaWiki forget all references encountered earlier in the page. There may be other things that cause this same problem, BTW. Anomie⚔ 19:27, 28 April 2012 (UTC)

A template works fine in the Cite MediaWiki interface pages, but not in MediaWiki:Pfunc time error and possibly other ParserFunction interface pages. I checked my changes on test.wiki first, but it never occurred to me that it might interfere with references. I am checking to see if this has been reported yet. ---— Gadget850 (Ed) ^talk 12:43, 29 April 2012 (UTC)

Most of the Cite.php messages use wfMsgForContentNoTrans or wfMsgNoTrans, neither of which have this problem, and then if necessary manually call recursiveTagParse on it. If you try using a template in MediaWiki:cite reference link prefix/suffix, you might run into this problem. Anomie⚔ 19:53, 29 April 2012 (UTC)

I meant the Cite.php error messages. Can't see using a template in any of the interface pages used to build a reference. On the gripping hand, I don't see a bug report on this. Since you grok the issue, would you start this one? ---— Gadget850 (Ed) ^talk 20:04, 29 April 2012 (UTC)

I checked this diff and I am sure that any bug reported will be labelled  Won't fix because templates should not be transcluded into MediaWiki namespace. – Allen4names 04:01, 30 April 2012 (UTC)

Intentional proxy delay?

I am currently behind the Great Firewall of China, so I often find it necessary to use a private HTTP proxy to access various websites. This works fine for browsing Wikipedia, but I often find that saving my edits results in unreasonable delays, sometimes as much as several minutes. Is this intentional? Surely it should not apply to legitimate logged-in users. – Smyth\^talk 05:20, 28 April 2012 (UTC)

Also the diff matters

I'm the user of zh-wikipedia, I would like to ask for something.

Does any one of you have encounter this or this? I mean in en-wikipedia.

And that is Firefox+Monobook, if any one has same problem, please leave a message.Justincheng12345 (talk) (urgent news here) 05:24, 28 April 2012 (UTC)

See #Scroll bars, above (the sections immediately above it are also relevant).
— V = IR (Talk • Contribs) 05:46, 28 April 2012 (UTC)

Thank you.Justincheng12345 (talk) (urgent news here) 06:50, 28 April 2012 (UTC)

Request for tool

I am trying to find an easy but reliable way to remove requests for images from articles that have images. Any suggestions or offers of help please comment at User:Traveler100/edit talk - brows article.--Traveler100 (talk) 09:07, 28 April 2012 (UTC)

Loss of session data and slowness issues

April 10-20

Having trouble staying logged in

Is there something wrong with servers? The system keeps logging me out. Sometimes, not all times though, when I click on another page, I'm logged back in. I'm currently using Firefox 11 if that helps. Elockid ^(Talk) 22:37, 10 April 2012 (UTC)

1. Did you try other browsers?
2. Change your password, because that may mean your account is being used somewhere else.--Jasper Deng (talk) 22:41, 10 April 2012 (UTC)

It doesn't work for Chrome as well. I'm also asking because after logging in, the icons of the other WikiProjects don't display. So I'm wondering if there's any correlation with that. I don't think this is a password problem. This occasionally happens but never to this extent. Elockid ^(Talk) 23:03, 10 April 2012 (UTC)

Ugh, looks like a problem with your CentralAuth cookie. Try clearing your CentralAuth cookies and try again.--Jasper Deng (talk) 23:13, 10 April 2012 (UTC)

How do I do that again? Elockid ^(Talk) 00:48, 11 April 2012 (UTC)

Go into Firefox's options, click the Privacy tab, then find the place where it says you can clear cookies. Remove any that have "centralauth" in them.--Jasper Deng (talk) 03:06, 11 April 2012 (UTC)

I'm still having some problems. :( Elockid ^(Talk) 15:52, 11 April 2012 (UTC)

In the worst case scenario your account has been hacked; this often results from being logged in on a second computer somewhere else simultaneously.--Jasper Deng (talk) 17:22, 11 April 2012 (UTC)

Wikipedia:Village pump (technical)/Archive 83#Loss of session data. I think I'll just have wait it out. Elockid ^(Talk) 20:24, 11 April 2012 (UTC)

Ah, that sounds familiar. See Wikipedia:Village pump (technical)/Archive 96#Being logged out unexpectedly: is this the same issue? Please note that your browser losing session data is not the same as being logged out: you're still logged in, you've just been in an edit window for too long without going for any one of "Save page", "Show preview" or "Show changes", so MediaWiki thinks that you've abandoned your edit. My advice is to hit "Show preview" at intervals no longer than 30 minutes. --Redrose64 (talk) 22:28, 11 April 2012 (UTC)

But re-logging in should solve the problem, and apparently it did not or did it?--Jasper Deng (talk) 22:30, 11 April 2012 (UTC)

A bit. More recently, sometimes when I edit, I get error that there was a lost in session data and am logged out (it gives me the warning that my IP will be displayed when saving). This happens even in less than 5 minutes. Clicking on another page, I am logged back in. It's also not just that. Sometimes after clicking on the links to my Watchlist, Contribs, or in Wiki links, I am no longer logged in. However, when going to another page or clicking the back button and then going to another page, I am no longer logged out. I don't have any problems staying logged in other sites such Toolserver, Email, etc. Elockid ^(Talk) 00:59, 12 April 2012 (UTC)

Clicking on any Wikipedia link outside Wikipedia such as clicking a link to Wikipedia from Toolserver or Google logs me out as well. Elockid ^(Talk) 01:13, 12 April 2012 (UTC)

Ugh. Somehow your account got hacked or something.--Jasper Deng (talk) 02:18, 12 April 2012 (UTC)

My alt account doesn't work either. Ugh. This is getting annoying. Elockid ^(Talk) 02:50, 12 April 2012 (UTC)

Something must be messing with your browser then....--Jasper Deng (talk) 02:59, 12 April 2012 (UTC)

I guess I'll try and see whether my alt account has the same problem on a diff computer later. Elockid ^(Talk) 03:05, 12 April 2012 (UTC)

I've just had the "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in." error when I'd been editing a page for less than three minutes. I was definitely logged in both before and after, and my login cookie hadn't expired - I had logged out and logged in again just 16 minutes earlier because of a rollback failure. --Redrose64 (talk) 17:03, 14 April 2012 (UTC)

Happened again after editing for less than 60 secs. --Redrose64 (talk) 18:08, 14 April 2012 (UTC)

• I'm not sure if this is related, but if I leave WP on a page for >5 minutes and then click on, say, the link for my watchlist, it brings up the standard not logged-in page.--Gilderien Talk|Contribs

Im still constantly getting thrown out seems to be a bigger problem here when you combine slowness cant save due to loss of session data and this. Is there a bugzilla thread on this.Edinburgh Wanderer 18:08, 16 April 2012 (UTC)

• I'm getting it randomly tonight - can't edit at all. One second I'm logged in & if I go to another page, I'm logged out. Safari 5.5.1. Truthkeeper (talk) 00:47, 17 April 2012 (UTC)
  • Oddly, it was just fine for me...up until a couple minutes ago, now I'm getting the random logouts. Grr. - The Bushranger _{One ping only} 09:06, 17 April 2012 (UTC)

User:Catrope identified a memcached host with issues as the likely source of the problem, and replaced it with a spare. The issue should be resolved now, please report if you see it again during normal editing. --Eloquence* 19:12, 18 April 2012 (UTC)

Not fixed still doing it. Just happened to me this minute.Edinburgh Wanderer 20:25, 18 April 2012 (UTC)

Yep, still happening, has been all day. — Bility (talk) 21:32, 18 April 2012 (UTC)

If our initial diagnosis is correct, you may still be getting occasional errors until you've manually logged out and logged back in to clear corrupted session information. Can you please confirm that you've done so, and report whether any issues still occur regardless?---Eloquence* 21:46, 18 April 2012 (UTC)

Just went 45 minutes without it logging me out, so hopefully it's gone for good. Thanks, — Bility (talk) 07:20, 19 April 2012 (UTC)

Server issue today?

I'm getting a lot of "Sorry! We could not process your edit due to a loss of session data. Please try again. If it still does not work, try logging out and logging back in." errors while editing this afternoon. Any particular reason for this or is it just random weirdness? - The Bushranger _{One ping only} 21:02, 14 April 2012 (UTC)

I've been getting this on and off for a few days (but not today weirdly). Secretlondon (talk) 21:14, 14 April 2012 (UTC)

Ive been getting that and the severe slowness mentioned above as well on and off since yesterday.Edinburgh Wanderer 21:26, 14 April 2012 (UTC)

Me too: four so far today - the two noted above at #Having trouble staying logged in and two others. The usual workaround of going for "Show preview" before saving simply isn't working. --Redrose64 (talk) 22:03, 14 April 2012 (UTC)

Still having trouble..80.3.25.148 (talk) 16:27, 19 April 2012 (UTC) This is doing my head in. I've tried ten times to log in in ten minutes. What the hell is wrong with the server???????????????80.3.25.148 (talk) 18:49, 19 April 2012 (UTC)

Logging out

I am having problems with staying logged in. I have to keep signing in every few minutes.♦ Dr. Blofeld 10:31, 19 April 2012 (UTC)

According to previous threads, this should have been fixed by now... apparently not. - Jarry1250 ^{[Deliberation needed]} 10:33, 19 April 2012 (UTC)

"If our initial diagnosis is correct, you may still be getting occasional errors until you've manually logged out and logged back in to clear corrupted session information. Can you please confirm that you've done so, and report whether any issues still occur regardless?" (Erik, above) - Jarry1250 ^{[Deliberation needed]} 10:35, 19 April 2012 (UTC)

Its happened 5 times in the last 9 minutes. Right confirm I've logged out manually now and logged in again, we'll see how it goes now!♦ Dr. Blofeld 10:41, 19 April 2012 (UTC)

Happened again and three times since.♦ Dr. Blofeld 11:11, 19 April 2012 (UTC)

Can't log in at all now. Somebody please sort this!80.3.25.148 (talk) 13:08, 19 April 2012 (UTC)

There is already a thread re this further up the page. Edinburgh Wanderer 13:49, 19 April 2012 (UTC)

The current advice is to stick with it until tomorrow, and then rereport as necessary then. - Jarry1250 ^{[Deliberation needed]} 19:37, 19 April 2012 (UTC)

Its been like it today too, in fact I'm having trouble logging in now at all.80.3.25.148 (talk) —Preceding undated comment added 16:46, 20 April 2012 (UTC).

April 20

I keep getting "loss of session data" errors. Logging out and back in again fixes it until the next edit that I want to make, when the problem recurs. Any suggestions? Thanks.--ukexpat (talk) 14:44, 20 April 2012 (UTC)

See my thread above WP:Village pump (technical)#Having trouble staying logged in. I've been having the same problem since then. Elockid ^(Talk) 14:57, 20 April 2012 (UTC)

It's happening off and on. Usually submitting a second time will post the edit. - The Bushranger _{One ping only} 16:13, 20 April 2012 (UTC) Scratch that; now I'm getting the multiple LOSDs and inability to log back in repeatedly...! - The Bushranger _{One ping only} 16:21, 20 April 2012 (UTC)

Just wanted to mention that I haven't experienced this in all the time it's been discussed. Equazcion ^(talk) 16:23, 20 Apr 2012 (UTC)

Its still happening randomly clearly still an ongoing issue.Edinburgh Wanderer 16:42, 20 April 2012 (UTC)

It was temporary, but I tried to log in about eight times after experiencing multiple LOSD errors; the login errors were at first the "unexpected error" type but then changed to something about attempting to prevent login hacks (I wasn't really paying attention to the exact wording, sorry, I probably should have but I was more frustrated at the time!). - The Bushranger _{One ping only} 17:27, 20 April 2012 (UTC)

Is there any update re this. Still happening.Edinburgh Wanderer 21:45, 21 April 2012 (UTC)

Began for me today or yesterday, on two very different computers (Linux with Firefox vs XP with Chrome). Not very frequent, but annoying. Logging out and back in fixes issue temporarily. Chris857 (talk) 03:32, 26 April 2012 (UTC)

April 21

I downloaded Firefox 11 today and now every few minutes I am finding I am having to log in again. Is this happening to anyone else? Simply south...... going on editing sprees for just 6 years (as of 28/03/2006) 22:06, 21 April 2012 (UTC)

I have Firefox 11 (under Windows 7) and have for a while - no problems with log in.--Bbb23 (talk) 22:13, 21 April 2012 (UTC)

So far I've resisted, and have stuck with 3.6.28 - but it nags me at least once a day and is now claiming "URGENT! Your version of Firefox will soon be vulnerable to online attacks. Get the upgrade — it’s fast & free! * Stay safe online * experience faster performance * Enjoy new features You will be prompted once more before being automatically updated." - does anybody know what these "online attacks" will be? Is it worth upgrading or just a load of annoying hassle having to get used to a different interface again? --Redrose64 (talk) 22:57, 21 April 2012 (UTC)

Its likely this is the same problem already detailed above rather than a Firefox issue.Edinburgh Wanderer 23:03, 21 April 2012 (UTC)

(edit conflict)It's basically "the older it is, the more holes hackers will likely have poked in it". As long as it works for you and you have a good antivirus (Microsoft Security Essentials+Malwarebytes' Anti-Malware is the highest reccomended these days, running SpywareBlaster doesn't hurt either), as long as you're not using IE6 you should be good. Firefox 5.0 here...- The Bushranger _{One ping only} 23:04, 21 April 2012 (UTC)

Redrose, I think Firefox's scare tactics and their claim of improved performance are a bit much. That said, I like the v.11 interface (takes up less screen space).--Bbb23 (talk) 23:13, 21 April 2012 (UTC)

Actually I think Edinbugh Wanderer was right and it seems to have been fixed now. Cheers. Simply south...... going on editing sprees for just 6 years (as of 28/03/2006) 23:32, 21 April 2012 (UTC)

April 22

As of right now, it just kicked me out and won't let me log back in. This was preceded by one of those "loss of session" messages. I have Firefox 3.6.25 and Windows XP. Here's the message it's giving me right now when it refuses to let me log in:"Login error There was an unexpected error logging in. Please try again. If the problem persists, it may be because you have cookies disabled, and you should check that they are enabled in your browser settings. "Maile66

OK, whatever it was, just cleared. Temporarily, at least. Something funky was going on there that had nothing to do with Firefox 11.Maile66 (talk) 15:21, 22 April 2012 (UTC)

What I can do this - if it works - Wikipedia is booting me out again and again, always preceded by that "loss of session" messageMaile66 (talk) 15:41, 22 April 2012 (UTC)

I received one of those loss of session data messages, and it did not kick me out. Just thought I'd make things more complicated.--Bbb23 (talk) 16:19, 22 April 2012 (UTC)

Me too, but I think it happens (more often, at least) when you have two edit windows open at once. - The Bushranger _{One ping only} 21:23, 22 April 2012 (UTC)

April 24

This is happening again today - have to log in between screens and lose sessions when in the edit window. Safari. Truthkeeper (talk) 21:21, 24 April 2012 (UTC)

April25

• I use Chrome on my main computer and have no issue with this. On a secondary machine I'm using Firefox today and I've been logged out about 4 times in 10 minutes. Very annoying. Killiondude (talk) 16:55, 25 April 2012 (UTC)

April 26

Hmmm, a few days where everything was back to normal and now it is doing it again, not quite as frequently but frequently enough. Simply south...... going on editing sprees for just 6 years (as of 28/03/2006) 14:53, 26 April 2012 (UTC)

I'm getting the "loss of session data" message again - intermittently.

There's another intermittent problem too - when loading a page, it sometimes sticks showing "Connecting to upload.wikimedia.org..." in the status bar; an examination of the page shows that one or more of the images hasn't come through, but instead shows a placeholder outline only. Sometimes it eventually displays; but sometimes the alt text displays instead. The strange thing is that this happens for images which are being shown at a size which has already been used for the same image - such as a location map on an article about a place, or the little icon at the left-hand end of a stub template. The strangest case is that it's happened with some of the buttons in the RefTools toolbar, which must get shown at the same size thousands of times an hour.

I suspect a server problem, see also #Technical difficulties? below. --Redrose64 (talk) 17:07, 26 April 2012 (UTC)

April 28

It's taking me 4 or 5 goes to make any edits this morning - I keep getting the "loss of session data" message. Are there any activities ongoing that could account for this? Did one of the server clusters have a heavy night :) --Elen of the Roads (talk) 11:16, 28 April 2012 (UTC)

It's an ongoing problem that has affected different users off an on for nearly a fortnight (it's mentioned above in three different sections, for example). WMF staff are on the case, but I don't think "baffled" would be an overstatement - it doesn't seem to be anything obvious at all. Regards, - Jarry1250 ^{[Deliberation needed]} 13:07, 28 April 2012 (UTC)

Began reoccurring for me this morning. Firefox 12.0, WindowsXP. In conjunction with seemingly endless slowness of Wikipedia in general..Maile66 (talk) 14:03, 28 April 2012 (UTC)

Slow

For at least the last couple of days, editing has intermittently slowed to a crawl. Right now it's just this side of intolerable.--Bbb23 (talk) 17:30, 28 April 2012 (UTC)

Same. The slowness seems (for me at least) to be a delay while waiting for an initial response from the server, though once it starts, pages load more or less normally. That initial delay varies from "just enough to lose my train of thought" to "I better load a Simpsons episode, this could be a while". Equazcion ^(talk) 17:40, 28 Apr 2012 (UTC)

LOL. Actually, for me, even sometimes after the wait delay for a response from Wikipedia's servers, the stuff doesn't load right. I've seen a Show preview box that only partly paints while "transferring" date and then takes a while longer to complete (happened just now when I did a Show preview on my comments).--Bbb23 (talk) 17:46, 28 April 2012 (UTC)

And when I was tweaking an article just now that stalling caused it to "eat" seven-eighths of the article! - The Bushranger _{One ping only} 17:54, 28 April 2012 (UTC)

Must've been a late lunch (it's about 2:20 p.m. in Florida). Hope it was digestible - so many articles could cause a severe bellyache.--Bbb23 (talk) 18:23, 28 April 2012 (UTC)

Burrrrrrrrp. Tastes like chicken. - Sgt. Schlock _{One THOOOOM only} 18:29, 28 April 2012 (UTC)

Agree! Horrible slowness making editing very difficult. Is it some new implementation that's causing this? MathewTownsend (talk) 20:46, 28 April 2012 (UTC)

April 29

Still slow editing, and getting "bad tokens" at times when closing AfDs... - The Bushranger _{One ping only} 01:25, 30 April 2012 (UTC)

Came here to add that I've been having problems today and yesterday with extreme slowness, currently so bad that editing is difficult. Also, for the last few hours, my edits have not been saving. I'm getting a message "We could not process your edit due to a loss of session data," when I try to save. When I look at my contribs, sometimes it has saved despite the message, and sometimes not. SlimVirgin ^(talk) 02:46, 30 April 2012 (UTC)

Waiting 45-60 seconds to load or save a page is getting very irritating... That is when you can actually save page without an error. The whole past week has been lethargic hodgepodge of delay. Bgwhite (talk) 05:52, 30 April 2012 (UTC)

Toolserver message

I've been doing some "Expand citations" from my Toolbox. That connects to the Toolserver. I've had a few moments of slower than usual experiences. But now, while I was on the Toolserver page, it gave this message:

"Getting login details ... done. Initializing MYSQL database ... loaded connect script. Will connect when necessary. Initializing ... ... Establishing connection to Wikipedia servers ... Could not log in to Wikipedia servers. Edits will not be committed."

Just thought I'd mention it, in case it's important.Maile66 (talk) 00:55, 29 April 2012 (UTC)

April 30

I didn't think this would be possible, but it's slower today, for me, than it has been since this whole thread began three weeks ago.Maile66 (talk) 16:10, 30 April 2012 (UTC)

Middle-clicking on a link in the Terms of Use banner does not work as intended

When I middle-click one of the links in the for the Terms of Use banner currently sitting atop every page, the link not only gets opened in a new tab (correct behaviour), but also replaces the current tab (which is a bug). There seems to be a Javascript programming error causing this. Please fix this. — Preceding unsigned comment added by 84.187.106.171 (talk) 14:40, 28 April 2012 (UTC)

Modifying/Removing top links

Resolved

If I want to remove some the links that are available at the very top of the pages (like "My Talk", "My Watchlist", "My Contributions"), what should I do ? -- Pg 6475 ^TM 14:44, 28 April 2012 (UTC)

If you go to Special:MyPage/common.css, you can mix and match the following lines (n.b. to regulars: yes, I know you could merge them, but I'm going for simplicity over efficiency here):

li#pt-userpage{ display:none; }
li#pt-mytalk{ display:none; }
li#pt-mysandbox{ display:none; }
li#pt-preferences{ display:none; }
li#pt-watchlist{ display:none; }
li#pt-mycontris{ display:none; }
li#pt-logout{ display:none; }

Each represents the hiding of one of the elements. You may need to refresh your cache (CTRL/CMD-refresh or Shift-Refresh depending on browser) to see the effects. Hope that helps, - Jarry1250 ^{[Deliberation needed]} 14:51, 28 April 2012 (UTC)

(edit conflict) Dammit, I'm too slow. Note that the above code doesn't actually remove the links, but rather hides them from view (my code was almost identical :P ) [stwalkerster|talk] 14:57, 28 April 2012 (UTC)

It works :). Thank you so much. -- Pg 6475 ^TM 15:02, 28 April 2012 (UTC)

screwed up REDIRECT

Hi,

I moved Dordogne (river) to Dordogne River. But I accidentally moved it to Wikipedia:Dordogne River. Now I've made a mess and don't know how to fix it. The correct name is Dordogne River. I don't really understand what's going on. Please help! MathewTownsend (talk) 20:51, 28 April 2012 (UTC)

ps — see (Redacted) MathewTownsend (talk) 20:53, 28 April 2012 (UTC)

An admin just needs to delete the redirect currently at Dordogne River and move the page back there. You can request it at WP:RM in the future, but one of them will probably see the request here. Equazcion ^(talk) 21:01, 28 Apr 2012 (UTC)

I requested an admin's help on their talk page. Equazcion ^(talk) 21:06, 28 Apr 2012 (UTC)

...but it appears someone else fixed it now :) Equazcion ^(talk) 21:07, 28 Apr 2012 (UTC)

Moved. You can also ask for admin-assistance with uncontroversial moves at WP:RM#Requesting technical moves. And that is usually a better option as there was a bit of confusion caused by more than one admin attempting to move the page at nearly the same time. older ≠ wiser 21:11, 28 April 2012 (UTC)

I notice that all three became redirects following the second admin's attempt. I'm confused about how that could've happened, but glad it's restored now. Equazcion ^(talk) 21:13, 28 Apr 2012 (UTC)

Thanks for resolving the issue Bkonrad. Tim! (talk) 21:15, 28 April 2012 (UTC)

I've removed the URL to Special:MovePage &action=submit because it provides no useful information, and could be dangerous if clicked as it stood. --Redrose64 (talk) 21:17, 28 April 2012 (UTC)

(after ec) When I made the first move, that left a redirect behind. The second admin then moved the redirect over the article. I then restored the article.

And in the end, the correct title is the original Dordogne (river). Rivers in continental Europe do not typically include the word "River" in their name and where disambiguation is necessary, "(rivers)" is appended. For example, see Category:Rivers of France. older ≠ wiser 21:20, 28 April 2012 (UTC)

As for how it happened in the first place, the move form Special:MovePage/Dordogne_(river) has two fields at "To new title:". The first is the namespace where you apparently changed from "(Article)" to "Wikipedia". The namespace field is not explained and has caused other moves to a wrong namespace. Perhaps MediaWiki:Movepage-summary should say something. It is displayed at the top of the move form (MediaWiki:Movepagetext-noredirectfixer is displayed afterwards) but is currently blank. PrimeHunter (talk) 21:29, 28 April 2012 (UTC)

yes, that's exactly how I made my mistake. Thanks for identifying it. I was confused looking at the choices when making the redirect, and for some reason I didn't see the correct choice. Thanks! MathewTownsend (talk) 21:32, 28 April 2012 (UTC)

I made the namespace mistake once too, since that dropdown namespace menu was implemented. I wonder if that's been a common problem. Equazcion ^(talk) 21:37, 28 Apr 2012 (UTC)

Wikipedia:Moving a page#How to move a page needs updating with the namespace field. Maybe MediaWiki:Movepage-summary should link to an updated version of Wikipedia:Moving a page. Movepage-summary could also ask users not to move articles before reading Wikipedia:Article titles. This might reduce the number of bad moves. PrimeHunter (talk) 21:57, 28 April 2012 (UTC)

UserSpace editnotices

I am having trouble getting editnotices for my user talk archive pages to work. It seems the page names I've tried are not working. I first tried Template:Editnotices/Group/User talk:Mlpearc/Archive. Then in research I tried to follow this documentation Wikipedia:Editnotice#User and user talk, I guess I'm just not getting the right title format. Can anyone point me in the correct direction. Thanx. Mlpearc (powwow) 03:09, 29 April 2012 (UTC)

User talk:Mlpearc/Archive does not exist. ---— Gadget850 (Ed) ^talk 03:15, 29 April 2012 (UTC)

It sounds like you are trying to make a "prefix" editnotice for pages starting with the string "User talk:Mlpearc/Archive". That's not how it works. You can make a group notice for a full page name and it's subpages. User talk:Mlpearc/Archive 0 and the other archives are subpages of User talk:Mlpearc so you can make a group notice for that at Template:Editnotices/Group/User talk:Mlpearc. If you want something different displayed for Archive subpages and other pages covered by the group notice then you can test the pagename with Help:Magic words#Variables and maybe something from Template:String templates see also text. PrimeHunter (talk) 03:31, 29 April 2012 (UTC)

Prime hunter thank you, I kinda got that duh feeling as I read your reply lol. Yes I would like to have a group notice for my archives that's why (Gadget850 that page doesn't exist) I was leaving the numeral off in hopes to have it display at any number archive. So I think User talk:Mlpearc/Archive 0 would work for archives 1, 2,3, and so on. Thanx to you both, I'll give it a go. Mlpearc (powwow) 03:44, 29 April 2012 (UTC)

You can try something like this at Template:Editnotices/Group/User talk:Mlpearc:

{{#ifeq:{{Str left|{{SUBPAGENAME}}|7}}|Archive|This is an archived talk page. Please make new posts at [[{{NAMESPACE}}:{{BASEPAGENAME}}]].|}}

PrimeHunter (talk) 16:41, 29 April 2012 (UTC)

Thank you PrimeHunter, that work perfectly Mlpearc (powwow) 20:58, 29 April 2012 (UTC)

Link problems

Is there a way I can get [[Rave On!!]] to link properly in the table at The Kentucky Headhunters discography? If I put the title as it is in the table, it breaks — probably reading the exclamation points as table coding. How can I fix this? Ten Pound Hammer • ^{(What did I screw up now?)} 21:59, 29 April 2012 (UTC)

 Fixed Encode the ! as !. ---— Gadget850 (Ed) ^talk 22:10, 29 April 2012 (UTC)

Occasional "mark all changes as read"

Occasionally, I see this button and all of my watchlisted pages that were updated since my last visit boldened, like on Meta. I personally dislike that feature as a waste of time, but what's more interesting is that it only appears sporadically with no relevant entries in the server admin log (on wikitech).--Jasper Deng (talk) 03:28, 30 April 2012 (UTC)

I guess you mean "Mark all pages visited". Do you mean you see it here at the English Wikipedia? mw:Manual:$wgShowUpdatedMarker should be disabled here and at some other large Wikipedias in http://noc.wikimedia.org/conf/highlight.php?file=InitialiseSettings.php:

# #wgShowUpdatedMarker @{
'wgShowUpdatedMarker' => array(
    'default' => true,
    'dewiki' => false,
    'enwiki' => false,
    'eswiki' => false,
    'frwiki' => false,
    'itwiki' => false,
    'jawiki' => false,
    'plwiki' => false,
    'ptwiki' => false,
    'ruwiki' => false,
    'zhwiki' => false,
),
# @} end of wgShowUpdatedMarker

I haven't tested it but meta:User:Erwin/monobook.css may remove the feature if you don't want it. PrimeHunter (talk) 05:41, 30 April 2012 (UTC)

Yeah, I got the same thing that Jasper describes a few hours ago, but after I refreshed my watchlist it disappeared. Weird. 05:48, 30 April 2012 (UTC)

http://wikitech.wikimedia.org/view/Server_admin_log#April_27 has the entry: "18:24 logmsgbot_: reedy synchronized wmf-config/InitialiseSettings.php 'Set wgEnotifWatchlist to true for all wikis. Leaving wgShowUpdatedMarker set to false for all the big wikis'". This shouldn't cause the watchlist button at enwiki but if somebody is changing server settings these days then maybe something temporarily happened. By the way, it's news to me that mw:manual:$wgEnotifWatchlist ("E-mail me when a page on my watchlist is changed" at Special:Preferences) has been enabled at the English Wikipedia. Earlier it has been said that it would cause too many emails. I have just tested that it currently works here. PrimeHunter (talk) 06:34, 30 April 2012 (UTC)

It happened for me yesterday, but earlier than that (about 16:00 UTC). Refreshing put it back to normal with one small difference: if the row represents the most recent revision, it no longer shows (top) at the right-hand end. --Redrose64 (talk) 13:38, 30 April 2012 (UTC)

Shouldn't upload list included deleted files?

I'm trying to sort out some issues with a new editor, which are very confusing for reasons not worth the recounting here, but I do have a specific question:

I looked at the list of files uploaded by the editor

I looked at the editor's talk page, and see some deleted files, not on the upload list.

Shouldn't the upload list include all files, not just ones that have not been deleted?--SPhilbrick(Talk) 13:44, 30 April 2012 (UTC)

They are all at Special:Log/DanDaniels which is linked on "logs" to the right of "uploads" at Special:Contributions/DanDaniels. The log can be reduced to "Upload log" to only see uploads (this user has no other logs except account creation). Your link Special:ListFiles/DanDaniels has additional information about currently visible files. Perhaps the message at the top from MediaWiki:Listfiles-summary should mention the upload log which includes deleted files. PrimeHunter (talk) 14:06, 30 April 2012 (UTC)

Thanks --SPhilbrick(Talk) 14:08, 30 April 2012 (UTC)

Messages for unregistered users

Hi all, I just got a "new message" banner for vandalism by someone else. Now, I'm an irregular but longtime contributor, and I do understand what is going on here, and it doesn't bother me. I do also understand that shared IP address messages are necessarily going to be difficult to deliver. But it does occur to me that this would confuse most people, and we can do better.

So may I suggest that if an unregistered user has not performed an edit during their session, then the "new message" banner ought not to be shown. A "new message" banner would not be displayed unless and until someone tries to make an edit (or logs in). The rationale is:

• most users are simply reading Wikipedia, the messages is certainly not to them, and there is no reason to trouble or confuse them.
• the message will be delivered to someone actually making an edit, so the chances of reaching the right user on a shared IP are actually much increased,
• this seems like a small change (but granted I don't know the Wiki internals),
• the only way a message notification could go undelivered this way is if no user makes any further unregistered edit from that IP address, but that seems like no big loss.

My 2 cents for today. You're welcome, Wikipedia :-) --192.75.48.150 (talk) 15:41, 30 April 2012 (UTC)