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

noreferrer for Wikipedia

See also: User_talk:Jimbo_Wales/Archive 123 § noreferrer_for_Wikipedia

Are there any plans to enable noreferrer on Wikipedia since there are browsers that support it? (There are also non-standard, browser specific methods to hide referrers).

For non-tech folks, when you are on the insecure wiki (http not https), and you click on an external link on the wiki, the external site you visit gets a copy of the wiki url you came from. For example, if you click on an external link in the reference section of any page, such as Banana, the site you go to will know you came from the url http://en.wikipedia.org/wiki/Banana .

Several privacy issues arise with allowing referers:

• If a low-traffic page is viewed, and an external link followed, if the person comments about a recent development on the page, it may be possible to link the ip to the editor.
• If a person visits the domain name or service repeatedly from the wiki, it may be possible to profile the individual.

Is it beneficial to let websites know the specific page from which a user is coming from or should privacy take precedence? Smallman12q (talk) 22:56, 11 January 2013 (UTC)

noreferrer - Discussion

This "referrer" feature, on any site, in any circumstance, is a disgraceful breach of privacy. I was appalled when I first learned of it. I think most people don't even know it exists. 86.176.208.123 (talk) 23:57, 11 January 2013 (UTC)

It's used in web analytics...something most people don't understand beyond buzzwords.Smallman12q (talk) 00:03, 12 January 2013 (UTC)

(edit conflict) To play devil's advocate for a second, HTTP referrers are useful to website operators to discover who links to them (search engine link searches might not find Wikipedia because our external links are marked "nofollow"). Website operators are often knowledgeable on the subject of the linking article (that's why we linked to the site), and seeing Wikipedia linking to their site would probably inspire them to check out the article. Some proportion of these, being knowledgeable on the subject, would go on to improve the article or suggest improvements on the talk page.

On the other hand, link spammers could use referrers from Wikipedia to gauge the success of a link-spamming campaign. (However, there are other techniques to do this without using referrers.)

IMO, one set of pages that absolutely needs "noreferrer" would be deleted pages viewed by administrators (ditto for oversighted pages viewed by oversighters). If an administrator clicked an external link, the referrer would leak information about the deleted page (e.g. the page title, the timestamp of the revision, and that it linked to that site). This would be particularly harmful for pages where even the page's title has been oversighted (e.g. as a BLP violation).

Also, if you are concerned about your own privacy, it is possible to turn off referrers globally (not just from Wikipedia), using a browser setting or add-on (how depends on your browser). Note that some websites won't work without referrers (e.g. this link requires a referrer to work). – PartTimeGnome (talk | contribs) 00:46, 12 January 2013 (UTC)

Such an interesting dilemma! I'm a federal employee (and of average tech abilities), and as we boot up our computers we get a message about "no expectation of privacy" on our workstations. After seeing this for 15 years I've internalized the message, and assume that everything I do on the internet is public. And forgive me, I'm beginning to think that none of us should assume any level of privacy on the internet. That actually seems the safest, really. This leads me to understand that the internet is a giant advertising machine, and because I want to track where webusers come from to get to my educational site (so I can serve them better) I also know that someone is tracking me, as I buy dog beds for the local no-kill shelter on Groupon. And I'm ok with that, because I can't have it both ways.

Again, as someone creating an educational website I want to know when/if Wikipedia and the sister projects are sending me webusers - I can then strengthen my relationships with the referring websites (like we are doing here), and learn which uploaded files get used, and which don't, so I can be nimble and respond accordingly. Bdcousineau (talk) 01:08, 12 January 2013 (UTC)

No opinon on the current subject, but the fact that privacy on the web is very low, does not mean nothing should be done to improve it (that's a general rule, and one of the poorest common arguments I usually see: "given X is already bad, there is no problem in making it worse") - Nabla (talk) 01:18, 12 January 2013 (UTC)

• I've rephrased the request on WP:CENT to emphasise that this is a request to disable something used by Wikipedia web browsers as part of a common standard, rather than starting from a status quo of its absence. I can understand that in some circumstances there are limited privacy implications, but these circumstances seem fairly limited and unusual. Andrew Gray (talk) 17:14, 12 January 2013 (UTC)

Your formulation "disable something used by Wikipedia as part of a common standard" makes it sound like Wikipedia is actively doing something now to pass referrer information. I'm not sure how it works but isn't the standard that a website does nothing at all and the browser by itself passes referrer information? And then a website can choose to add code to request browsers to not pass the referrer? PrimeHunter (talk) 00:56, 13 January 2013 (UTC)

Yes, you're right - corrected. Andrew Gray (talk) 13:31, 13 January 2013 (UTC)

• Comment. Aren't these descriptions the wrong way round? How can support for "noreferrer" mean that "Wikipedia should have referers"? Ditto the one below. — Preceding unsigned comment added by 86.129.18.113 (talk) 18:35, 12 January 2013 (UTC)
  • Comment Agree with 86.129.18.113. The wording is confusing enough to render this useless. - Nabla (talk) 23:26, 12 January 2013 (UTC)
    • Per the above two comments (moved from the support section), I've swapped support and oppose and updated the description at the top of each section to be a little more verbose. Hopefully things are a bit clearer now. (I also updated James086's !vote to reflect support and oppose have swapped meanings.) – PartTimeGnome (talk | contribs) 00:55, 13 January 2013 (UTC)
      • Thanks - Nabla (talk) 20:30, 13 January 2013 (UTC)

• Smallman, perhaps you can write up the code that allows an editor to opt in to a noreferrer feature and we can iVote whether to place that option in Special:Preferences. The noreferrer feature could work both in logging into Wikipedia (erase the URL from where you came into Wikipedia) and in clicking on external links in Wikipedia (prevent the target site from learning the Wikipedia URL source that referred to the target site.) -- Uzma Gamal (talk) 09:19, 13 January 2013 (UTC)

  I've just tried the following and it seems to work. -- WOSlinker (talk) 09:59, 13 January 2013 (UTC)

$("a.external").attr("rel", "noreferrer");

• Regarding Uzma's bit about erasing the URL from which a user enters Wikipedia, I don't think the WMF record this in a way that threatens privacy. Looking at the requests by origin report, it seems they only keep the domain name of the referer (not the full URL), and do not associate this with an IP address or username. Looking at the CheckUser documentation, CheckUsers cannot see referers either. It is possible that server logs accessible to developers might have them. If this were the case, it would be a topic for a separate discussion; this RFC is about referers sent to external sites, not those received by Wikipedia. – PartTimeGnome (talk | contribs) 15:04, 13 January 2013 (UTC)

• Someone below mentioned that there are reasons why referers exist, so I decided to look them up. I've taken the below snippets from the HTTP 1.0 specification, to better inform this discussion.

This allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance.

...

Note: Because the source of a link may be private information or may reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referer field is sent. For example, a browser client could have a toggle switch for browsing openly/anonymously, which would respectively enable/disable the sending of Referer and From information.
— Berners-Lee, T.; Fielding, R.; Frystyk, H. (1996). "Referer". Hypertext Transfer Protocol -- HTTP/1.0. sec. 10.13. doi:10.17487/RFC1945. RFC 1945. {{citation}}: Unknown parameter |month= ignored (help)

– PartTimeGnome (talk | contribs) 22:27, 15 January 2013 (UTC)

It's a little sobering that it's taken fifteen years for the private "toggle switch" idea to become common... Andrew Gray (talk) 12:10, 16 January 2013 (UTC)

The toggle switch was proposed in the HTTP/1.1 Protocol:

The Referer header allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can be abused if user details are not separated from the information contained in the Referer. Even when the personal information has been removed, the Referer header might indicate a private document's URI whose publication would be inappropriate.

...

We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending of From and Referer information.
— Berners-Lee, T.; Fielding, R.; Frystyk, H. (1999). "Transfer of Sensitive Information". Hypertext Transfer Protocol -- HTTP/1.1. sec. 15.1.2. doi:10.17487/RFC2616. RFC 2616. {{citation}}: Unknown parameter |month= ignored (help)

Also, for there have been proposals of a referrer alternative providing only the scheme, host, and port of initiating origin. Smallman12q (talk) 16:09, 16 January 2013 (UTC)

Though I didn't quote that part earlier, the exact same text appears word-for-word in section 12.4 of the earlier HTTP/1.0 spec. – PartTimeGnome (talk | contribs) 22:36, 16 January 2013 (UTC)

For those folks who believe HTTPS is the panacea, referers are sent on https -> https connections but not on https->http connections.

Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.terface be provided for the user to enable or disable the sending of From and Referer information.

— Berners-Lee, T.; Fielding, R.; Frystyk, H. (1999). "Transfer of Sensitive Information". Hypertext Transfer Protocol -- HTTP/1.1. sec. 15.1.3. doi:10.17487/RFC2616. RFC 2616. {{citation}}: Unknown parameter |month= ignored (help)

That means that when you click on a secure site from the secure wiki, you will send a referer. HTTPS will only prevent sending a referer to http sites.Smallman12q (talk) 16:54, 25 January 2013 (UTC)

noreferrer - Support

Wikipedia should enable noreferrer, so that referers are not sent to external sites:

• Support - Changes should be made in the best interests of readers and editors, not external sites. I think our users are more important than the owners of sites we link to. James086^Talk 15:21, 12 January 2013 (UTC)

  Wikipedia sends referers to external sites now. The proposal is to stop doing this, not to add it. (James' comment previously referred to adding referers to Wikipedia, but he has since corrected this.) – PartTimeGnome (talk | contribs) 00:55, 13 January 2013 (UTC)

• Support - Wikipedia should take every reasonable step to ensure that it doesn't violate the privacy of any person. Telling other sites that the use rhad previously visited Wikipedia, let alone a specific Wikipedia page, is clearly such a violation. עוד מישהו Od Mishehu 14:18, 13 January 2013 (UTC)

There has been some confusion here about how referrer works but Wikipedia doesn't tell anything to other sites now. It's browsers which usually by themselves tell a site where the browser came from. The proposal is to make Wikipedia ask browsers to not tell they came from Wikipedia. I think few sites do that currently so when you surf, a website usually knows where you came from. PrimeHunter (talk) 19:56, 13 January 2013 (UTC)

Whether it's Wikipedia, or the user's own browser doing stuff behind the user's back, is irrelevent. If Wikipedia can prevent such action from being taken behind the user's back, it should. עוד מישהו Od Mishehu 13:00, 15 January 2013 (UTC)

• Support seems like since we do nofollow this would be logical too. That said, I don't think we should get all paranoid about the reasoning: the sky isn't going to fall because website A knows it's been linked to from website B, and any site likely to do something sinister with that info probably shouldn't be linked to on WP anyway. Andrew Lenahan - Starblind 22:24, 13 January 2013 (UTC)

  Nofollow serves an actual purpose: it takes away the SEO incentive for people to spam their links here. Noreferrer does not have any such purpose. Anomie⚔ 22:31, 13 January 2013 (UTC)

• From what I understand, for the people that care, this is a positive. For the people that don't care, there's no effect at all. Therefore, I support. Sven Manguard Wha? 01:27, 15 January 2013 (UTC)
• Support. If Wikipedia can ask browsers to not reveal that our users have visited a page on Wikipedia, we should do so, for the same reasons we use nofollow on links. Some external sites will use this information for "wikipedia optimization" to the detriment of our attempts to reduce COI problems. --Guy Macon (talk) 20:10, 16 January 2013 (UTC)
• Support and completely disagree with opposes I have read. We cannot control other sites or individual browsers, but we can do this. --Nouniquenames 04:25, 17 January 2013 (UTC)
• Support. Wikipedia should not be an ad click enabler. 5.12.84.224 (talk) 19:54, 17 January 2013 (UTC)
• Support per Od Mishehu and Guy Macon. The web was a much smaller and saner place when this sort of tracing capability was introduced. The time to opt out is past due. ~ Ningauble (talk) 16:21, 18 January 2013 (UTC)
• Support Referers might have been an ok idea in the CERN era of an academic-operated, research-oriented web. In today's advertiser and user-profiling web, they are evil and should be suppressed whenever possible. 67.117.146.66 (talk) 08:43, 25 January 2013 (UTC)
• Support since as Sven said "for the people that care, this is a positive. For the people that don't care, there's no effect at all". Helder 11:15, 25 January 2013 (UTC)
• Support None of their business who goes where. Too much of that going on. Peridon (talk) 21:33, 25 January 2013 (UTC)

noreferrer - Oppose

Wikipedia should continue to allow referers to be sent to external sites:

• This is pointless paranoia. The few people who are concerned should either avoid clicking external links, install a browser extension to block/falsify the referrer, or use the Javascript snippet WOSlinker posted above. Anomie⚔ 15:45, 13 January 2013 (UTC)
• Agree with Anomie above. Anyone who is worried about a site knowing they got there by following a link in Wikipedia should be even more worried about links on other sites and install or activate referrer blocking in their browser. Kiore (talk) 08:50, 14 January 2013 (UTC)
• Referrer isn't as big of a privacy breach as people think. It's also useful for certain sites, such as when I was working on my edit counter. I'll bring up an anecdotal example of why referrer was helpful: The tool was getting hit hard in basically a DOS attack. It was causing my email to get spammed, the tool was getting throttled, and by looking at the referrer, I found which page the attack was coming from, and was able to solve it. It's near impossible to get anything bad out of the referrer, and when a site really needs it, like I did, it's useful to have. (X! · talk)  · @957  ·  21:57, 14 January 2013 (UTC)
• This is just a lot of FUD to me. Referrers are mostly harmless (especially coming from Wikipedia). Legoktm (talk) 01:33, 15 January 2013 (UTC)
• Let's not mess up the way the Internet was designed to work. There are reasons the referrer exists, and there is no reason to remove that en masse. Prodego ^talk 07:52, 15 January 2013 (UTC)
• This is stupid. It gives people a false sense of privacy while breaking an important part of the HTTP protocol. --Chris 11:58, 15 January 2013 (UTC)
  • The Referer header is optional; omitting it does not break the protocol. The proposed technique for disabling it is part of HTML5, not some hack. However, I do think it would be an abuse of rel="noreferrer" to turn it on globally. The use intended by the HTML5 authors was to block referers from private pages, to avoid leaking private information. – PartTimeGnome (talk | contribs) 22:47, 15 January 2013 (UTC)
    • For more detailed info, see The rel attribute of HTML5. --Redrose64 (talk) 23:05, 15 January 2013 (UTC)
• I agree with what all the "opposers" before me have said. The only "sure" way to do this, would be for the user to do it in his UA settings, not trying to enforce a one-size-fits-all "solution" by mucking about with Wikipedia (which probably wouldn't work anyway). ⇔ ChristTrekker 14:22, 15 January 2013 (UTC)
• So, if you visit a website, your IP is transmitted to them anyway. All that putting noreferrer on it does is deny the site owner useful information about who is linking to their site. So, oppose. —Tom Morris (talk) 20:48, 15 January 2013 (UTC)
• Oppose, It is in the HTTP protocol for a reason, it is useful, people can block this on a case by case basis using scripts so removing noreferrer for the whole site seems pointless and wrong. ·Add§hore· ^{Talk To Me!} 21:20, 15 January 2013 (UTC)
• Oppose, it's standard, useful for web analytics, and if the user doesn't want to people to know where they've been, they can disable it themselves/use the secure server. --SarekOfVulcan (talk) 11:50, 16 January 2013 (UTC)
• X! shows that these can be useful --Guerillero | My Talk 08:54, 18 January 2013 (UTC)
• Oppose per Tom, Sarek et al. Johnbod (talk) 12:00, 18 January 2013 (UTC)
• Oppose 1) Referrers are part of the structure of the Web. Wikipedia should work with the web protocols, not against them. 2) One way to measure the success of partnerships with GLAMs and other organisations is for them to see how many referrals they get via Wikipedia. This is important: one of the drivers of the growing academic respectability of Wikipedia is that people who run scholarly journals or online archives are seeing how much Wikipedia is driving their traffic. MartinPoulter (talk) 19:23, 19 January 2013 (UTC)
• I'd rather see HTTPS by default for logged-in users. --MZMcBride (talk) 01:54, 21 January 2013 (UTC)
• Oppose per MartinPoulter. the wub "?!" 14:05, 22 January 2013 (UTC)
• Oppose - Sarek sums it up beautifully. As we are the Worlds fifth largest (and by far the most visible) website out there, it's up to us to lead the way in standards. There is a simple solution to this: Edit the Special:LoginUser page to briefly mention noreferrer in the explanation field. -T.I.M^(Contact) 01:19, 24 January 2013 (UTC)
• Oppose; there are no genuine privacy benefits, and there are a number of entirely legitimate technical reasons why that header is useful. Users genuinely concerned about following links should use the privacy extension of their browsers or retype URLs, not rely on specific sites using noreferrers. — Coren ^(talk) 03:33, 25 January 2013 (UTC)
• Oppose per Anomie, Sarek, Martin, Tom. If we are really concerned about users privacy under the belief they cannot take care of it themselves, we should enable HTTPS by default as MZMcBride and Edoktor have suggested. Nil Einne (talk) 07:03, 25 January 2013 (UTC)
  • Comment Referers are still sent when the url is https. Also, https doesn't help much with privacy of page views if someone can snoop the TCP traffic (since the lengths of the pages are still observable through the encryption, and that goes a long way towards identifying the pages). Https is useful for protecting passwords but that's about it. It has nothing to do with this referer issue and is a red herring. And the idea of asking users to log in and set a profile option to turn off referers is unhelpful: logging in correlates all of the person's pageviews together (a privacy problem in its own right), and anyway the vast majority of visitors never log in or edit (that's that #5 website in the world thing: non-logged-in read-only users). It would be ok to have a login option to turn the referers on for users who want to send them. 67.117.146.66 (talk) 08:54, 25 January 2013 (UTC)

    • Clarification: Referers are sent when following a link from one HTTPS site to another, but are not sent when following a link from an HTTPS site to a plain HTTP one. (I think this is what you meant; I'm just making it a bit clearer.)

      As well as passwords, HTTPS is useful to protect login cookies (which can be used to impersonate a logged-in user if discovered). HTTPS can also effectively protect non-public content, such as deleted pages being viewed by administrators. – PartTimeGnome (talk | contribs) 23:34, 25 January 2013 (UTC)

noreferrer - Neutral

• Ah, crap. Are we hosting an RFC here, not at WP:VPR? If we get a flood of !votes, I may need to unwatch this page. --Redrose64 (talk) 16:25, 12 January 2013 (UTC)
  • Perhaps, for that reason, any RfC, poll or whatever, likely to attract a large turnout, should be on its own sub-page? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:57, 14 January 2013 (UTC)
• This issue seems slightly paranoia. Anyway, it will also be moot once Wikipedia switches to https-only, as clicks from secure sites never send referrers. — Edokter (talk) — 09:34, 13 January 2013 (UTC)
• Normally I'd favor any efforts by a site to protect its users' privacy. In this case, since concerned users already have ways to strip or forge referrers on their own (several methods are mentioned here), I don't see a compelling need for any action on Wikipedia's end. Kilopi (talk) 05:30, 15 January 2013 (UTC)

• I'm leaning towards oppose. Referers provide useful information for webmasters, which most sites do not use in a way that threatens privacy. Users should decide for themselves whether or not they want to provide referers to websites and use their browser settings (or add-ons) to control this. (I acknowledge that browser makers could do more to make privacy options clear to users.) I also regard the proposal as abusing the "noreferrer" feature, as the HTML5 authors did not intend it to be used across a whole site.

  However, I'm putting myself down as neutral because I think the noreferrer feature should be used in limited circumstances. When someone with permission to view an oversighted (or deleted) page clicks an external link, a referer should not be sent. Some websites make referer logs public, and hence could expose article titles that have been suppressed on Wikipedia. Given that a common reason for suppression of a title is a BLP problem, we should do everything we can to prevent such titles being sent to other sites. Protecting non-public information such as this is the intended use of noreferrer. – PartTimeGnome (talk | contribs) 23:30, 15 January 2013 (UTC)

• Question: http://wiki.whatwg.org/wiki/Meta_referrer gives four possible values for using referrer in a meta tag (never, always, origin, default). Are we talking about adding a meta tag to our HTML or adding something to the HTTP headers? If the latter, are those four values available in the HTTP header? --Guy Macon (talk) 20:34, 16 January 2013 (UTC)
  • Thus far, this proposal has discussed adding the HTML5 rel="noreferrer" to every link. Using the meta tag would be another way to achieve the same end. I am unaware of an HTTP header that would have the same effect. If we were to go ahead with this, it might be worth investigating which method has the best support amongst browsers (or just use both to be extra certain). – PartTimeGnome (talk | contribs) 22:47, 16 January 2013 (UTC)
    • If we can make it work, the "origin" option has a lot going for it. It tells the linked-to page that the link came from en.wikipedia.org without saying what page on Wikipedia. --Guy Macon (talk) 06:58, 17 January 2013 (UTC)
      • Special:Linksearch would still identify the originating page with high accuracy. Most extlinks aren't on large numbers of pages. 67.117.146.66 (talk) 09:00, 25 January 2013 (UTC)

Uploaded file summary

At some point (circa July 2012 ?) a number of files began showing up with the Permission field for their {{Information}} templates filled with "Evidence: Will be provided on request.". See e.g. File:Acumen International.png. Does anyone know why that started showing up with those files? VernoWhitney (talk) 20:45, 16 January 2013 (UTC)

The phrase appears in MediaWiki:FileUploadWizard.js, so it's probably shown as one of the selectable options. -- John of Reading (talk) 20:51, 16 January 2013 (UTC)

Why is that even an option? If the copyright owner has given appropriate permission, it should be provided to OTRS without being requested and if it isn't the image should be deleted; and they certainly should not be tagged for moving to Commons. Otherwise we will have even more images with unconfirmed copyright status and that is not a good thing.--ukexpat (talk) 20:58, 16 January 2013 (UTC)

Looking through the history, apparently it used to be "The license agreement will be forwarded to OTRS shortly" which is on a few hundred images which have already been moved to commons and a few hundred more locally. VernoWhitney (talk) 21:18, 16 January 2013 (UTC)

I asked Future Perfect at Sunrise to weigh in here since they're the primary editor. I also have discovered that this same topic has come up before at Wikipedia talk:File Upload Wizard/Archive 3#Letting through too many images without permission, Wikipedia talk:File Upload Wizard/Archive 2#Evidence: Will be provided on request., and commons:Commons:Administrators' noticeboard/Archive 36#A general licensing point. Should this discussion perhaps be moved elsewhere (no 'right' place springs to mind) to figure out if this is the most desired behaviour? VernoWhitney (talk) 21:44, 16 January 2013 (UTC)

Yep, I'm the culprit here; I put these options into the upload form when I wrote it last year. My thoughts were these:

• In my understanding, this was the previous policy status quo: we don't force people to provide evidence the moment they do their uploads; they just need to make a plausible assertion of licensing and we tell them their images might get deleted if they can't provide evidence if and when challenged. When I wrote the form, I didn't want to create the impression it was sneakily introducing new, stricter policies.
• While most such images certainly should be challenged (and I as well as others actually tag most of them with "no-permission" routinely), I believe there are situations where a reviewer might legitimately take an uploader's word for it and accept an assertion of licensing without evidence, on assumption of good faith. I, for instance, occasionally do that with COI editors, when it is obvious from an uploader's editing profile that they are acting as the article subject's representative.
• Most importantly, I believe this option is useful because it gives problematic uploaders a relatively simple way of admitting a file isn't their own. If we didn't have this option, many of these uploaders would choose to lie instead and tag the files as "own work", which would make copyvios much more difficult to detect.

By the way, I would guess most of the ones that have turned up on Commons with the "will be provided" option were not moved there, but uploaded directly to Commons from our WP:FUW form. That option was disabled some time in July, I think.

For previous discussion of this option, see Wikipedia talk:File Upload Wizard/Archive 2#Evidence: Will be provided on request.. Fut.Perf. ☼ 22:02, 16 January 2013 (UTC)

A quick look at the files in Category:Files licensed by third parties that have the "on request" annotation shows that there are probably hundreds that should be challenged. I tagged a few yesterday but ran out of steam. If we are so tough on potential copyvios elsewhere, why are we not showing the same rigour here? Personally, I think that option should be rewritten to immediately tag the image with {{di-no permission}} so that the uploader is put on immediate notice that permission must be provided. As for COI editors, why should they be exempt? If they have have appropriate permission they should have to provide it or face deletion just like everyone else.--ukexpat (talk) 17:32, 17 January 2013 (UTC)

I often see people uploading images as "own work" although the images obviously aren't own works. If this feature in the upload wizard makes copyright violations easier to discover, then I think that it is a good thing. However, maybe this option could tag the files with {{subst:npd}} automatically? There are other "bad" templates such as {{permission from license selector}}, but files with that template automatically get {{db-f3}} and don't require someone else to go through the files and tag it manually.

I don't like the idea of assuming good faith for file copyrights. While it is unlikely that a contributor with a good standing would try to violate copyright, it is possible that other people might not know this and then tag the file with "no permission" in 5 or 10 years. If the contributor no longer is around, the file would then be lost. It is better to sort out the OTRS part now while the contributor still is around. --Stefan2 (talk) 11:26, 19 January 2013 (UTC)

I like the idea of making it auto-tag it for speedy deletion just like the permission-for-Wikipedia-only option (although I didn't see that option at all just now while glancing through the FileUploadWizard.js). F11 deletion requires notification of the uploader, though. Would that be satisfied just by an explanatory template on the file page itself like the template you pointed out, or would we need to get a bot involved if we change to that option? VernoWhitney (talk) 16:24, 21 January 2013 (UTC)

Well, if the file is going to be tagged as {{subst:npd}}, the uploader needs to be notified about this, but not necessarily on his talk page. He will most likely look at the file information page after uploading the file, and there it will say that permission needs to be sent to OTRS. Wouldn't that be enough? The upload wizard could also be designed to automatically put a notice on the uploader's talk page using the uploader's own account. --Stefan2 (talk) 22:16, 21 January 2013 (UTC)

I've asked at Wikipedia talk:Criteria for speedy deletion#Question about notification requirement for F11 for some more input regarding this. VernoWhitney (talk) 17:10, 23 January 2013 (UTC)

I came here following Stafan2's note at WT:CSD, having not previously been aware of this discussion. Personally, I think that if a user has state that they will provide evidence "on request", we must assume good faith that they will provide it when requested. As an absolute minimum, we must therefore explicitly request that permission before or at the same time as tagging for speedy deletion - in other words the speedy deletion clock must not start until the permission has been requested. This brings up the second question about what constitutes adequate notice, and for me the minimum must be notices on the file page and the user talk page. I say this because any user familiar with Wikimedia wikis, and likely other people too, will have an expectation that any requests specifically for them to be made on their user talk page. Thryduulf (talk) 03:07, 24 January 2013 (UTC)

parser function admin

Is there a parser function which could be used in a template to alter behavior if was posted on admin or non-admin's talk page? NE Ent 19:28, 17 January 2013 (UTC)

No. --MZMcBride (talk) 20:49, 17 January 2013 (UTC)

Actually, it might be possible, considering that Template:Adminstats only shows for admins. (X! · talk)  · @289  ·  05:55, 18 January 2013 (UTC)

{{#if:{{adminstats|{{{1}}}}}|{{{1}}} is an admin|{{{1}}} is not an admin}} would probably work, if placed on a userpage. (X! · talk)  · @292  ·  06:01, 18 January 2013 (UTC)

The claim that Template:Adminstats only shows for admins is untrue: try logging out and viewing either Template:Adminstats or Template:Adminstats/X! - it's visible.

The second idea doesn't work for all users (whether admin or not), see User:Redrose64/Sandbox11. The problem is that it relies on the existence of a bot-generated template, and that template is only generated for admins who have asked for it. Further, it is not deleted if an admin is later de-sysopped. --Redrose64 (talk) 13:02, 18 January 2013 (UTC)

What you can do, is ADD information that is only visible to admins. You can use the css class sysop-show, which should make that CSS block only visible for sysops (but the content will always be in the HTML). Example: the answer of the question is 42, but hidden for most users. —TheDJ (talk • contribs) 22:05, 22 January 2013 (UTC)

Struck part of my last comment because somebody's requested creation of Template:Adminstats/Redrose64 which didn't exist when I set up my test. --Redrose64 (talk) 22:35, 22 January 2013 (UTC)

Cyberbot will automatically create adminstats for administrators if it finds a link {{adminstats|adminname}}, as it did in your sandbox. Therefore in effect, you requested it yourself :-)   An optimist on the run! 22:42, 22 January 2013 (UTC)

Actual image locations

I have a quick question about the locations of the actual images for files. Lets take File:SummitArenaAndConventionCenter.jpg as an example. The URL it says the image is at is http://upload.wikimedia.org/wikipedia/en/6/6b/SummitArenaAndConventionCenter.jpg . Everything here makes sense and I was just wondering if the '6/6b' part of the URL ever changes from image to image? ·Add§hore· ^{Talk To Me!} 17:18, 18 January 2013 (UTC)

Yes, they're (i) the first character and (ii) the first two characters of the image's hash code. Each character can be in the ranges 0-9a-f, so there are 16 possibilities for each, therefore the chance that these characters are the same for any two images is 1 in 256. I don't know which hashing algorithm is used: it might be MD5, SHA-2, or something else. --Redrose64 (talk) 17:36, 18 January 2013 (UTC)

Thanks! ·Add§hore· ^{Talk To Me!} 17:37, 18 January 2013 (UTC)

It's MD5. See mw:Manual:Image Administration#Data storage. http://md5-hash-online.waraxe.us/ says SummitArenaAndConventionCenter.jpg has MD5 hash 6b31f364001ca46f7b6efd0f53acc0f7. PrimeHunter (talk) 18:00, 18 January 2013 (UTC)

Yes, I knew it had come up before, so after posting the above, I've been back through the archives and found your post at Wikipedia:Village pump (technical)/Archive 98#Some images appearing red. --Redrose64 (talk) 18:10, 18 January 2013 (UTC)

(edit conflict) I think the MD5 hash is called internally from FileRepo::getHashPathForLevel().

In wikitext, the {{filepath:...}} parser function returns the URL for any specified file – but only if it has already been uploaded. For example: [{{filepath:SummitArenaAndConventionCenter.jpg}} this] produces‎ this link.

But bypassing the file description page by linking to the file directly might breach the attribution requirements of the file authors, so a conventional File: link is usually appropriate.

Presumably the subdirectories are used so that multiple servers can store files instead of having them all in one location. For 1 in 256 files, the path will contain ".../a/ad/...", which has sometimes confused adblockers into not displaying those files. — Richardguk (talk) 18:36, 18 January 2013 (UTC)

Media:SummitArenaAndConventionCenter.jpg gives a direct link to the uploaded file instead of the file page. PrimeHunter (talk) 20:09, 18 January 2013 (UTC)

Thanks everyone! ·Add§hore· ^{Talk To Me!} 21:19, 18 January 2013 (UTC)

Just to clarify: "the first two characters of the image's hash code" - the digits are the md5 sum of the image's file name (not the hash code of the image). 129.173.209.17 (talk) 15:57, 21 January 2013 (UTC)

Wikimedia sites to move to primary data center in Ashburn, Virginia. Read-only mode expected.

This is complete now. Philippe Beaudette, Wikimedia Foundation (talk) 11:24, 23 January 2013 (UTC)

(Apologies if this message isn't in your language.) Next week, the Wikimedia Foundation will transition its main technical operations to a new data center in Ashburn, Virginia, USA. This is intended to improve the technical performance and reliability of all Wikimedia sites, including this wiki. There will be some times when the site will be in read-only mode, and there may be full outages; the current target windows for the migration are January 22nd, 23rd and 24th, 2013, from 17:00 to 01:00 UTC (see other timezones on timeanddate.com). More information is available in the full announcement. If you would like to stay informed of future technical upgrades, consider becoming a Tech ambassador and joining the ambassadors mailing list. You will be able to help your fellow Wikimedians have a voice in technical discussions and be notified of important decisions. Thank you for your help and your understanding. Guillaume Paumier, via the Global message delivery system (wrong page? You can fix it.). 15:12, 19 January 2013 (UTC)

Bots, archive links to web pages

Hello, may I ask - are there in the English Wikipedia bots that automatically archive links, as many web pages often are inaccessible? Russian Wikipedia has w:ru:Участник:WebCite Archiver. Examples of his work: [1] [2]. Are there any similar job in the English Wikipedia? Thank you.--Ворота рая Импресариата (talk) 06:46, 20 January 2013 (UTC)

User:WebCiteBOT went inactive a while back, and User:Lowercase sigmabot III never heard a response back from the webcite team, so unfortunately not. Legoktm (talk) 06:49, 20 January 2013 (UTC)

• Thank you. And how, then, on the English Wikipedia solve the problem of the dead links and move permanent links to external web sites? This is a common problem, and the archive manually all of the links for a very long time.
  
  Oh, and is there a manual to bots, You indicated? If they can work in other wiki-projects? Thank you.--
  ↑‡‡К воротам рая Импресариата‡‡↑
  06:43, 21 January 2013 (UTC)

That is not an acceptable WP:SIGNATURE doktorb _words^deeds 06:47, 21 January 2013 (UTC)

We use {{dead link}} to mark dead links where necessary and often add links to pages archived in The Wayback Machine. Beyond that, I'm not sure if we do anything. – Philosopher ^{Let us reason together.} 11:52, 21 January 2013 (UTC)

Preventing Group Account Names

Not sure if this is the right place - but once upon a time, a person creating an account saw the contents of the page MediaWiki:Fancycaptcha-createaccount. However I've seen an large increase of messages at OTRS from people who do not understand why they have been blocked because they have used a name of their business, etc. - they certainly have never heard of the user name policy. I did try the create account with another PC and found that the message is no longer displayed - all they get is a tiny link on the Username box that says "(help me choose)" - I can assume you that they do not click the link, they don't want help in choosing, they have already made up their decision. Is there some way we can get the little explanation box back? It would stop lots of new editors getting rather upset at being blocked for a reason that has never been explained to them.  Ronhjones  ^(Talk) 02:17, 21 January 2013 (UTC)

If you log out then click this link, you'll see that MediaWiki:Signupstart, which is currently blank, is displayed at the top of the page. Perhaps you could use that? jcgoble3 (talk) 04:26, 21 January 2013 (UTC)

I suggest you talk to Steven (WMF) (talk · contribs) before redesigning the "create account" page. See this VPT archive. -- John of Reading (talk) 07:15, 21 January 2013 (UTC)

I've requested that he comment here. – Philosopher ^{Let us reason together.} 11:45, 21 January 2013 (UTC)

Thanks John and Philosopher for the heads up. I really appreciate being invited to chime in on interface issues like these. I have a longer explanation about the message, why we removed it, and the testing data etc., but in the short term I just wanted to note that the current interface of the signup page won't display any contents of MediaWiki:Fancycaptcha-createaccount, except to users that have JavaScript disabled or who won't accept cookies, who get the old version for now. For now I wouldn't recommend trying to use new messages such as MediaWiki:Signupstart, as we haven't tested to see if overwriting defaults in that or other messages will break the styling of the new signup page. I do have some suggestions for how we might address the issue Ron brings up, and also wanted to say that Ron approaching the issue with the goal of lessening headaches for new people unfamiliar with our rules is admirable. Talk soon, Steven Walling (WMF) • talk 06:09, 22 January 2013 (UTC)

Okay, following up, let me give you some bullet points on why we made the change we did, and why I don't recommend placing another list of "do not" items about usernames. Forgive me for being verbose...

• First up: MediaWiki messages like Fancycaptcha-createaccount are meant to describe elements of the interface, and as you can tell by the title, the purpose of that message was to describe the CAPTCHA. Having it be used to provide warnings about username policy was technically a misuse of the message.
• We get more than a hundred users signing up every hour, and thousands per day. When looking at from that high level view, you can tell that it is unlikely that all of these users need to see several paragraphs and five bullet points about username policy. The sheer number of registrations vs. username blocks every week makes this clear.
• The current version of the page, which we ran as a side-by-side test to half of visitors to the signup page, produced a 4% increase in people successfully registering, and no statistically significant increase in the rate at which new accounts were blocked (for any reason). That sounds small, but at the seasonal rate of account creation for that week-long test, we netted more than 2,700 additional people. When comparing that gain to the potential for any confusion among people who are going to be blocked either way, the end decisionw was a clear one to us. Removing excess instruction and warnings is one important part of making the signup process easier on the majority of people.
• The system for dealing with bad usernames ultimately needs to be redone. As tracked in bug 32330, our current thinking is that in the long run, we are going to let admins force a username reset which the user completes before they are allowed back in to their account. This is much more elegant than blocking and forcing users to create a new account.
• The "help me choose" language in the link was suggested by an editor, over the version we originally had which as "username policy". I'm totally open to suggestions about changing the description of that link.

Anyway, the other reason I ask about actual stats on the increase in OTRS email is because we are coming out of the holiday season. As you can see from data like this, every year around Christmas and New Years, we see a very large dip in all account creations. The increase you may be feeling is almost certainly in part due to the fact that the overall number of registrations is increasing again, slowly but surely. Steven Walling (WMF) • talk 20:01, 22 January 2013 (UTC)

I've added a comment to bugzilla:32330 with two features that are essential to any such change. – Philosopher ^{Let us reason together.} 18:08, 24 January 2013 (UTC)

Pending Changes disagreeing with itself

Crosseyed?

Special:PendingChanges recently referred me to a pending change at Deaths in 2013 (edit | talk | history | protect | delete | links | watch | logs | views) (which I'd reviewed the previous edit to, but I don't think that has anything to do with what happened). However, when the diff loaded, it told me that it had already been accepted. Yet the history told me that the two edits (an addition by an IP and its subsequent reversion by Eyesnore (talk · contribs)) were still pending. I raised the issue on IRC, where several other editors saw the same issue; Legoktm (talk · contribs) deprecated the revisions and re-accepted them, and as far as I can tell, that fixed everything. Here's the problem, though: the review log shows that Eyesnore's revert was auto-accepted. But everything I can find on the subject says that the only edit auto-accepted following a still-pending edit is rollback executed by a reviewer. Eyesnore's a rollbacker, but not a reviewer. So am I mistaken, and are rollbackers' reverts in fact auto-accepted, or is there a bug in the system? — PinkAmpers&^{(Je vous invite à me parler)} 06:25, 21 January 2013 (UTC)

According to Special:ListGroupRights, Eyesnore's status as a rollbacker should not have permitted him to be auto-reviewed (although there could be a bug that permits it). MBisanz ^talk 06:33, 21 January 2013 (UTC)

It also might check the SHA1 and if they are the same from a already approved edit it might auto-except that. Werieth (talk) 14:32, 21 January 2013 (UTC)

Selectively hiding watchlist notices

Is it possible to hide watchlist notices by type? I'm not interested in seeing notifications of upcoming meetups, which occur frequently. — Hex (❝?!❞) 13:47, 21 January 2013 (UTC)

It is possible to hide individual geonotices (see MediaWiki:Geonotice.js), for example the current UK meetup one may be hidden by setting

#geonoticeUKFeb2013Meetups { display: none; }

in your Special:MyPage/common.css, but since that ID will probably change when the March meetups begin to be shown, it's easier to go for the [hide] link. Alternatively you can hide all geonotices on a permanent basis using

.geonotice { display: none; }

instead. --Redrose64 (talk) 15:13, 21 January 2013 (UTC)

Great - thanks. I wasn't aware of the workings of geonotices before. — Hex (❝?!❞) 15:17, 21 January 2013 (UTC)

weblinkchecker.py

Sorry, I do not work with weblinkchecker.py . :-( Examples: 1, 2. The code of weblinkchecker.py I copied from JeffGBot, adding information for the Russian Wikipedia. What I did wrong? Thanks.--Ворота рая Импресариата (talk) 14:33, 21 January 2013 (UTC)

Run it again over the same page in a week, it will then report dead links. Werieth (talk) 15:15, 21 January 2013 (UTC)

The title of the George Galloway article is italicised

Here is the discussion with further information [3]. Govgovgov (talk) 15:46, 21 January 2013 (UTC)

I jerry-rigged a solution by using {{DISPLAYTITLE}} after the radio show infobox. If someone can think of a better way, feel free to do so. Ryan Vesey 15:52, 21 January 2013 (UTC)

The proper fix was to use the right right parameter name italic_title for {{Infobox radio show}}.[4] PrimeHunter (talk) 23:40, 21 January 2013 (UTC)

Curiosity concerning stats.grok.se

As some of you may or may not know, I previously went by the Wikipedia alias of Backtable. My former userpage was deleted on January 4, 2013, as per my own request. Ever since then, stats.grok.se has reported a sharp increase in views of my deleted userpace, starting when the page got deleted. Stats.grok.se reports hundreds of post-deletion views per day, even though not getting 10 pre-deletion views per day was nothing unusual. Is this an error on behalf of the viewcounter, or is there an otherwise reasonable explanation for the uncanny increase in views? I know I haven't been viewing it that much.

Also, I did send an e-mail to Henrik about this, as was recommended here, but that user has not been very active on Wikipedia as of recent. I also e-mailed another administrator about the viewcount anomaly, and the administrator referred me here. Mungo Kitsch (talk) 22:14, 21 January 2013 (UTC)

Purely a guess, but could it be bots external to Wiki, e.g. Googlebots, trying to spider your page repeatedly when they can't find it?  An optimist on the run! 14:57, 23 January 2013 (UTC)

I'm unfamiliar with bot practices, but I would venture to consider your guess possible. I found this page, and I may instill some of its suggestions to hopefully reduce viewcount. Mungo Kitsch (talk) 03:12, 24 January 2013 (UTC)

Template talk:Wikimedia for portals

See: Template talk:Wikimedia for portals#Wikivoyage. Is there a way to add a yes/no function to this template, to what will display, kind of along the lines of Template:Sisterlinks, except that it is horizontal, instead of vertical. Thanks, --Funandtrvl (talk) 22:39, 21 January 2013 (UTC)

If you mean how to make it not to display Wikivoyage, that is {{Wikimedia for portals|voy=-}}. Ruslik_Zero 13:23, 22 January 2013 (UTC)

Thanks, I just see that now. I'm going to change the dash to "no", to match the way the Sisterlinks template works, it seems more clear-cut that way. The dash is very vague to what it does. --Funandtrvl (talk) 17:38, 22 January 2013 (UTC)

Feedback appreciated on edit request

I've filed an edit request to incorporate {{Pp-pc1}} (though not {{Pp-pc2}}) into {{Pp-meta}}, in keeping with other protection templates. I believe it to be fairly non-controversial, as does Salvidrim, who's reviewing the request, but he's suggested that I seek comment from other editors before he carries out (or doesn't carry out) the changes. I agree that this is a good idea, and would be very grateful if some editors experienced in template markup could look over my work, both to make sure that I haven't screwed anything up and to comment on whether or not it's a good idea regardless. If necessary I can open an RfC, but it seems simpler to just fish for some feedback here. — PinkAmpers&^{(Je vous invite à me parler)} 06:37, 22 January 2013 (UTC)

Data center migration

Hi; just a quick reminder that the planned data center migration (see above) is happening today, in about 2.5 hours now. guillom 14:41, 22 January 2013 (UTC)

You mean it's not started yet? Wikipedia has been slow all day here in the UK. --Redrose64 (talk) 15:11, 22 January 2013 (UTC)

No, it won't start before 1.5 hour. Is it better now? guillom 15:25, 22 January 2013 (UTC)

Does that mean no edit (in either talk namespace or article space) will be possible? -- Toshio Yamaguchi 18:18, 22 January 2013 (UTC)

Yes, for some time saving any edits will not be possible. --AKlapper (WMF) (talk) 19:02, 22 January 2013 (UTC)

The watchlist notice says "Wikimedia sites will be periodically in read-only mode early this week." So inbetween there will be periods where editing is possible? -- Toshio Yamaguchi 18:22, 22 January 2013 (UTC)

Well, starting at 1740 today, there was a span of about half an hour where no edits at all were possible (ending ten minutes ago or so), but we're making edits now, so I guess the answer to both your questions is "yes." :) Writ Keeper ⚇♔ 18:25, 22 January 2013 (UTC)

All sites were in read-only mode for ~30 minutes, but the migration was completed successfully. We don't expect any further related editing interruptions. Asher Feldman 00:36, 23 January 2013 (UTC)

Don't save my change yet!

When I am editing an edit summary, if I accidentally press return the edit is saved, like this.

Is there a way to disable this functionality? Either through configuring Wikipedia or my browser.

Yaris678 (talk) 18:18, 22 January 2013 (UTC)

Hey, Yaris! You could try this script that I just wrote (not wholly by myself); I haven't tested it completely for cross-browser shenanigans, but I think it should work. Writ Keeper ⚇♔ 19:34, 22 January 2013 (UTC)

Jarry1250 (talk · contribs) provided me with a one-line fix which you can find in my vector.js. It seems to work. -- John of Reading (talk) 19:55, 22 January 2013 (UTC)

Cool. Thanks guys. I'll have a go with one of these tomorrow. Yaris678 (talk) 22:48, 22 January 2013 (UTC)

I have applied Jarry1250's code to my monobook.js and it seems to work. (I use the monobook skin, not vector.) Thanks guys! Yaris678 (talk) 11:37, 23 January 2013 (UTC)

Removing markup

Hi - is there a template or parser function that will strip wiki mark-up from text, just leaving raw text?  An optimist on the run! 18:29, 22 January 2013 (UTC)

No. Though if you give further details about what you're trying to accomplish, there may be another solution available. --MZMcBride (talk) 19:03, 22 January 2013 (UTC)

Ok, it's rather complicated, but here goes: I use a personalised {{information}} template on Commons, and want to put an anchor link in it to the licence section. This uses the header {{int:license}}. This gives a different title depending on a user's language preference. The obvious solution, which I've tried, is to link to [[#{{int:license}}]], which works for en-gb (my preference), but causes problems for the default en language. This is because {{int:license}} expands to [[Commons:Copyright tags|Licensing]] for en, containing a link. When this is transcluded into the anchor link, it produces nested square brackets, breaking the template. I want to strip the mark-up from {{int:license}}, so that it leaves [[#Licensing]] for English users. I can't just link to [[#Licensing]] directly, as it wouldn't work for users with other languages set. I could get around the problem by having a special case if {{int:lang}}=en, but there may be other languages that also have links in the header.

Any suggestions?  An optimist on the run! 19:25, 22 January 2013 (UTC)

Set an WP:ANCHOR. For example, <span id=Licensing /> --Redrose64 (talk) 19:32, 22 January 2013 (UTC)

^ This, basically. Though Commons really ought to have canonical anchors for these standard sections. --MZMcBride (talk) 19:36, 22 January 2013 (UTC)

Or instead of a raw <span> tag, use commons:Template:Anchor. jcgoble3 (talk) 19:38, 22 January 2013 (UTC)

I'd thought of that, but hoped to avoid having to edit all my images (over 200), having only just gone through them all to add the header in the first place. Oh well, AWB makes it easier. Thanks for your help.  An optimist on the run! 21:00, 22 January 2013 (UTC)

Here's a proof-of-concept that it can be done, though the technique is probably too clunky for widespread adoption:

• An undocumented quirk of the {{anchorencode:...}} magic word causes it to extract the dot-encoded displayed text from a wikilink, making it possible to link to the relevant section, so {{anchorencode:[[#Foo|Bar baz?]]}} will produce Bar_baz.3F
• There doesn't seem to be a way to extract Foo or the unencoded Bar baz?.
• Because the extracted display text is always dot-encoded, it needs piping to prevent non-ASCII text and punctuation from displaying oddly. Fortunately, in this case it's possible to cheat by piping int:version-license which happens to have the same intended meaning as int:license but uses only unlinked plain text – at present! (The display texts of the two messages are not identical in every language, so it is not possible to link with the simpler unpiped [[#{{int:version-license}}]].)
• So the following should work:

  [[#{{anchorencode:{{int:license}}}}|{{int:version-license}}]]
  

There's a working example at commons:User:Richardguk/int anchor test which you can test by appending the uselang parameter to the URL.[5][6][7][8][9] But the fact that it can be done by this obscure workaround doesn't mean that it ought to be done! In particular, links could break if there were changes to the internal workings of {{anchorencode:}} or to the format of int:version-license messages. But it is an interesting demonstration of wikitext's quirks.

— Richardguk (talk) 01:46, 23 January 2013 (UTC)

secedit script listed as obsolete but...

This script from 2007 has been listed as obsolete by the user scripts project. However, I bumped into it and tried it out and it seems to work just fine in Firefox 18.0.1. Might this be erroneous? Can some other people with other configurations try out the script to see if it works? ResMar 18:55, 22 January 2013 (UTC)

I don't know, but "obsolete" might mean "made unnecessary" rather than "no longer working". Grandiose (me, talk, contribs) 19:29, 22 January 2013 (UTC)

The script is no longer necessary. It was written at a time when there were no "edit" links for article sections in Wikipedia and the only way to edit a section was to open the entire article. — Quicksilver^{T @} 19:34, 22 January 2013 (UTC)

The listing specifically states that it has been "Broken by MediaWiki changes". While there is a live preview option under editing preferences, as well as an Ajax preview script, neither of them works inline in the same manner as this one - ae. they both take you to a new webpage. Maybe it's been rendered obsolete by something better, but I haven't found it yet... ResMar 19:42, 22 January 2013 (UTC)

Hold up, that's not how it works. It changes the interface so that clicking on the edit button opens an inline editing interface, without switching to a &section= editing page, and allows you to do all the usual stuff without changing web urls. ResMar 19:46, 22 January 2013 (UTC)

Hmm in the latest Chrome it doesn't work most of the time and when it does it edits the section below.--Gilderien Chat|List of good deeds 20:41, 22 January 2013 (UTC)

It's been possible to edit article sections since at least July 2003. Graham87 14:57, 23 January 2013 (UTC)

Images not rendering

Tracked in Phabricator
Task T46319
Resolved

I've uploaded ~800 images as part of Commons:Batch_uploading/AELG. While image metadata is visible for all the images, some of them do not have a preview/don't thumnail: File:Eulalia Agrelo Costas (AELG)-1.jpg, File:Valentín Arias (AELG)-1.jpg, etc.. When I click on File:Eulalia Agrelo Costas (AELG)-1.jpg for the full image, it shows up fine, however, the preview thumbnail says "Error generating thumbnail The source file for the specified thumbnail does not exist." Anyone know how to fix this?Smallman12q (talk) 01:25, 23 January 2013 (UTC)

This has been happening for a while now, Wikipedia:Purge has some instructions that may solve the problem, these may fix but but don't expect the results to be quick as I noticed a similar problem with File:Moorhouse in Cumbria - geograph.org.uk .jpg in the Moorhouse, Cumbria article a few days ago and the thumbnail wouldn't display at the correct size in the article until several hours later (adding the "?1" to the url would work for the image, but the syntax used in articles doesn't allow that. The full size images of your uploads are appearing correctly. Peter James (talk) 01:37, 23 January 2013 (UTC)

In general we face some on-and-off thumbnail issues, see the list under "Depends on:" bugzilla:41371. Bug 41130 (server caches) comes to my mind but mostly people from North America are affected, while I can reproduce the problem here and am based in Europe. As recommended by Peter I'd wait a few hours, and if the issue still happens I'd file a bug report in the bugtracker (I'll happily do that). --AKlapper (WMF) (talk) 11:40, 23 January 2013 (UTC)

It looks like something broke on the wiki side from 19:14, 22 January 2013 to 19:17, 22 January 2013. All of the files in between don't render. It's only a few minutes, but the bot does 10-15 files/minute. See listfiles on commons for the bot for the empty rendering spaces.Smallman12q (talk) 23:47, 23 January 2013 (UTC)

Maybe it has something to do with the data migration that was happening yesterday. The Anonymouse (talk | contribs) 23:56, 23 January 2013 (UTC)

19:14, 22 January 2013 to 19:17, 22 January 2013 was definitely data migration time and we were read-only for 33 minutes at that time. See the announcement. --AKlapper (WMF) (talk) 11:40, 24 January 2013 (UTC)

On the other hand, I also see very similar issues with thumbnails that were not created around that time. I'll try to find a developer to discuss with. --AKlapper (WMF) (talk) 12:58, 24 January 2013 (UTC)

Resolved

-It's been fixed thanks!Smallman12q (talk) 03:14, 25 January 2013 (UTC)

-Speaking of thumbnails: I updated two images on the Commons, which were updated on WP the next day, but not in the article (Puget Sound faults); purging my cache did not help. I now see that it is the thumbnail version that is not updating. Changing the "upright" parameter to a different size appears to force a new rendering. But invoking the image at the old size gets the old version of the image. I suspect that each size of an image in use is stored as a separate file, and these are not being updated when the source image is changed. ~ J. Johnson (JJ) (talk) 23:19, 24 January 2013 (UTC)

Your bug is a bit different in that you have stale thumbnails, whereas my bug had no thumbnail. Thumbnails are cached. The server cache for your images could be stale. Did you try Wikipedia:Purge? (Go the image file on commons, add ?action=purge to the url and hit enter).Smallman12q (talk) 03:14, 25 January 2013 (UTC)

Yes, that worked. Even though the latest image had been promoted to WP, I gather that some derivative process (for the thumbnails?) did not complete, and re-promoting it from Commons restarted all that. I wonder if this should done with all recently uploaded images. ~ J. Johnson (JJ) (talk) 23:53, 25 January 2013 (UTC)

There is a similar problem with File:The_cave_video_game_cover.png, a new version has been uploaded but the old image is displayed with the new image's dimensions. Purge has no effect. Reverting, and then restoring the image has no effect. Adding the purge command to the image url will display the correct version of the image, but it has no long lasting effect. It may be worth investigating if there is a chance that this could be affecting all images uploaded during the fault period. - X201 (talk) 11:34, 25 January 2013 (UTC)

Same problem as described by X201 here: File:Grail browser on Linux.png --Morn (talk) 12:04, 25 January 2013 (UTC)

P.S. Seems to be fixed now… --Morn (talk) 01:05, 26 January 2013 (UTC)

No it isn't. Just follow the link to The Cave image above, scroll down to the File History and look at what should be shown as the Current Image. It's still broken. - X201 (talk) 15:24, 26 January 2013 (UTC)

Users reporting site time issues and delay in visible update of edits

Hi. At Talk:Main Page, a couple of users are reporting that the site is rendering for them as 22 Jan, despite them living in Europe, where it's currently 23 Jan. Hence, they're seeing yesterday's TFA. NB I live in the UK and all seems fine to me. --Dweller (talk) 11:58, 23 January 2013 (UTC)

• Yes, I was the first poster on main page, the Main Page definitely doesn't update for me. Firefox 9.0.1 and 10.0.2 here. Windows XP 2002 SP3. France. F5, CTRL+F5, restarting the computer doesn't work, and I have this problem on different computers. I'm stuck on Jan 22, which was a rather miserable day for me :D BTW is this problem related to the one I have on Commons ? The Commons Main Page doesn't update regularly for me either, I have to force it by switching to mobile view and back. Thank you, have a nice day. 130.79.37.169 (talk) 12:11, 23 January 2013 (UTC)

Thank you, reported.  :) Philippe Beaudette, Wikimedia Foundation (talk) 14:28, 23 January 2013 (UTC)

Thanks, Philippe. --Dweller (talk) 14:31, 23 January 2013 (UTC)

I'm having the same problem and I'm in the UK. The main page should be 23rd January. Why is yesterday's page loading instead? I've never had this problem on Wikipedia before. TurboForce (talk) 14:41, 23 January 2013 (UTC)

This is a confirmed problem related to the eqiad migration, and operations is working on it now. Hopefully should be resolved shortly. ^demon^{[omg plz]} 14:43, 23 January 2013 (UTC)

Thanks. While this glitch may be annoying for those it's affecting, it's remarkable that the migration has had such little impact. Virtual coffee and chocolate to all the developers from me. (I presume that American IT people depend on similar foodgroups to their British cousins). --Dweller (talk) 14:46, 23 January 2013 (UTC)

This was a routing problem relating to page purges, and it's now been fixed (and primarily affected European users). Any affected pages can be purged and should show up properly for all users. ^demon^{[omg plz]} 15:02, 23 January 2013 (UTC)

Concur with Dweller. I can honestly say that if I hadn't read about the migration, I wouldn't have noticed a thing. Well done!  An optimist on the run! 15:16, 23 January 2013 (UTC)

This problem is still ongoing, at least for me here in the UK. Many pages will show their 22 Jan version in read mode even if later edits have been made. The edits can be seen in edit mode, but will not appear in normal read mode. Neither do they show up in the history view. It's the same for the talk pages. 78.146.235.71 (talk) 04:04, 24 January 2013 (UTC)

The problem is still ongoing, I posted to Talk:Main Page about one of the sections not updating. and was pointed to here. (The DYK section is not updated for unlogged visitors.) It's probably not just the front page. Yesterday I made 2 edits to an article. I could see them in my contributions, but they weren't present in the article's revision history and in the article itself. (Even when I was logged in.) When I returned to Wikipedia today, they were there. --Moscow Connection (talk) 05:08, 24 January 2013 (UTC)

By the way, when I log out, no recent modifications on any pages seems to be shown. In the revision history too, I see an older version without newer edits. I try to purge pages, but nothing helps. When I log in, I can see everything. --Moscow Connection (talk) 05:50, 24 January 2013 (UTC)

2 examples of what I see when I log out:

• On the front page the "Did you know..." section is from 08:00, 23 January 2013
• At Template:Did you know, I am shown the revision from 16:00, 22 January 2013. Purging doesn't help. --Moscow Connection (talk) 06:19, 24 January 2013 (UTC)

This glitch is still active in Germany. Although our location is 0730 UTC on 24 Jan the main page shows 1630 UTC 23 Jan. And the Talk page shows a completely different UTC. Purging the pages does not work at all. — Preceding unsigned comment added by 155.56.68.216 (talk) 06:47, 24 January 2013 (UTC)

Still an issue UK 11:46gmt 24JAN2013, main page shows 23JAN data, tried all the purges etc, viewing vis USA proxy shows correct date data. — Preceding unsigned comment added by 213.104.131.116 (talk) 11:47, 24 January 2013 (UTC)

Issue is still active as of 1530 GMT 24 January in Netherlands on IE and Firefox, purging etc. no effect. Site still is showing 23 January information. This seems to only be the case with en.wikipedia.org, nl, fr and de versions working fine. — Preceding unsigned comment added by 94.210.0.175 (talk) 15:35, 24 January 2013 (UTC)

The glitch is still ongoing (for those not logged in). Many pages still shown in their January 22 or 23 state. This must be causing pretty serious problems. What is being done about it? 78.146.235.71 (talk) 21:40, 24 January 2013 (UTC)

• This seems to still be ongoing for many users: OTRS Ticket #s 2013012410012095, 2013012510003923, 2013012510003558, 2013012510004002, 2013012510003094. All of them came in within the last 16 hours. Ks0stm ^{(T•C•G•E)} 09:40, 25 January 2013 (UTC)
• Verified from a PC other than my own in Oxford, England (IP address 195.171.xxx.yyy) using IE8 under Windows XP; at 10:15 UTC today the main page showed: TFA - Skye; DYK - 16:00, 23 January 2013 (European birch aphid etc.); OTD - January 23; TFP - Executive Mansion.

I then went to one of these articles, followed links to about five pages deep, then backed out to the main page - and saw that it was now showing the correct information for January 25 (TFA - Pinguicula moranensis; DYK - 2012 Race of Champions, Abel Schr›der/Vester Egesborg/Undløse/St Martin's, Make the World Move, Thomas Aquinas Dictionary, Dima Yakovlev Law, Ian McKeever, Detroit's population increased over 1,000 times). --Redrose64 (talk) 13:50, 25 January 2013 (UTC)

This is geting ridiculous. This morning (25th) the main page was showing the correct date and I thought that at last all the problems had been fixed. This afternoon I visit it again, and its back to showing the 23rd! Come on, guys. You're losing technical credibility, here. — Preceding unsigned comment added by 195.59.43.240 (talk) 14:33, 25 January 2013 (UTC)

I've moved the off-topic discussion of centre-aligned and shrunken text to the correct section, Egads!!, below. – PartTimeGnome (talk | contribs) 23:18, 25 January 2013 (UTC)

FYI, running Google Chrome on a Mac, & here, no issues with Main Page (where it's 25 Jan) nor any other pages so far. TREKphiler ^{any time you're ready, Uhura} 17:54, 25 January 2013 (UTC)

I actually had an issue with safari on mac just now... was switching in and out of private mode for work at WP:OP and noticed that I was seeing different versions of that page depending on whether I was logged in or logged out.... The last edit visible was from Jan. 18, but there were no edits to the page between then and the 22nd. One interesting commonality is that both the main page and WP:OP both use subpages..... Sailsbystars (talk) 18:22, 25 January 2013 (UTC)

It also affects the Japanese Wikipedia. I've just noticed. I can't see the latest edits and the latest enties in the edit history when I log out. Two examples:

• The latest entry I see is from 16:56 January 22, 2013
• ‎The latest entry I see is from 23:53 January 24, 2013 --Moscow Connection (talk) 19:59, 25 January 2013 (UTC)

Getting this when accessing the main page while not logged in using Safari v6.0.2 on MacBook Pro running OSX v10.8.2. Hitting refresh initially gave the page from 24th, but subsequent refreshes bring up the page from the 23rd. A Windows 7 Professional PC, on the same router, running Firefox v18.0.1 shows the correct page when not logged in. Pendleboater (talk) 20:17, 25 January 2013 (UTC)

Well spare a thought for us closer to the international date line! Here in New Zealand we ALWAYS have to wait about 12 hours to get an update for the new day for ALL of the wiki sites. Do you here all of us complaining about it? NO you don't (well I did mention somewhere that we should change the server time to the date line time). . -- Alan Liefting (talk - contribs) 20:44, 25 January 2013 (UTC)

I'm from Germany and I notice this problem also in de.wp es.wp en.wp ... It is not just a problem with the main page. In a lot of articles I see old versions and an old revision history without edits from 25th and 24th January. --93.209.87.114 (talk) 21:09, 25 January 2013 (UTC)

Maybe you should stop telling in the headline that this is just a problem with the main page (who looks every day at the main page and who really cares if the main page shows an older version?). If the problem would be that just the main page is not updated, this would not be a big problem. But I (and apparently a lot of other people) can not see the new versions of millions of articles in all languages. I already saw an article with vandalism which was reverted but I have to see the vandalised version of the article and can not fight it because of this problem. This seems to be a very serious problem and I would feel better when someone of the technical team would explain what is happening here and if they can fix the problem. Ironically I can see the new version of a page (for a limited period of time) after I have edited it. --93.209.69.102 (talk) 21:44, 25 January 2013 (UTC)

The main page problem began very recently, and has affected many users whether logged in or not. By contrast, users who are not logged in have always been served cached copies of most pages, primarily for reasons of speed. --Redrose64 (talk) 21:54, 25 January 2013 (UTC)

But now even when the cache is purged 2 day old versions of articles are shown. I read and edit in a lot of languages of Wikipedia since years and this never happened before. --93.209.69.102 (talk) 21:58, 25 January 2013 (UTC)

I have experienced this problem in the UK as well for the last couple of days, and it's still active. Best way I found of viewing most recent updates, which works, is by going around all cache records on my computer. In other words, refreshing the page won't work. But going around cache does, which, while the problem lasts, can easily be done by pressing Ctrl+F5. Whichever page you're viewing should refresh properly and display the latest updated version. The same thing works for Talk pages and View History. It has worked for me consistently since the problem started, which seems to indicate that the cause is a temporary misinteraction of WP pages with cache. Just refresh with Ctrl+F5 each time you open a page, and the content will be updated. I hope this helps. — Preceding unsigned comment added by 94.170.99.72 (talk) 22:20, 25 January 2013 (UTC)

For what it's worth, Squid has had issues for weeks (maybe months). Logged-out users are constantly served old versions of pages and it doesn't have anything to do with the recent data center migration. I suspect the reason the issues have persisted for so long is that most editors (read: people capable of properly complaining) are logged in. But if you look at any reasonably active page (think: noticeboard) while logged out, you'll quickly notice discrepancies between the date of the most recent edit and the "this page last modified" timestamp. --MZMcBride (talk) 22:23, 25 January 2013 (UTC)

The revision history is also outdated. I never noticed such an issue before. --79.216.60.212 (talk) 22:35, 25 January 2013 (UTC)

I reported a related squid issue in August 2011[10]. I didn't say it at the time, but the <ahem> educational pages like ANI served a couple days old content (up to week old for RFA)... it would have sounded a bit strange to complain that ANI was doing re-runs. I don't think I have had to use the history tab to bypass the cache since spring 2012, maybe. In any case, the cache oddities go back a long way. 88.148.249.186 (talk) 05:59, 26 January 2013 (UTC)

I am living in Australia, and the site is rendering as the 25th, when it is the 26th, Australia Day. 124.168.188.25 (talk) 22:37, 25 January 2013 (UTC)

This has been going on for days now and it isn't getting any better! Why haven't those trying to fix this at least posted some update about what they are doing about it? 92.24.102.136 (talk) 00:00, 26 January 2013 (UTC)

I'm in Belgium and it has been January 23rd for two days now, according to the Main Page. It's Jan 26th, 1:15AM, BTW. — Preceding unsigned comment added by 91.182.220.9 (talk) 00:17, 26 January 2013 (UTC)

• I am told that this should now be fixed (just got the email), they asked if we could take down the notice but I'll leave that up for others if it seems like we're all set in the purge catch up. If people are still seeing issues please let me know. I'm told that it was a "evil multicast forwarding router bug" Jalexander--WMF 01:32, 26 January 2013 (UTC)
  • I've removed the sitenotice. Even with the issues described, a sitenotice seems like it was massive overkill.--ragesoss (talk) 02:02, 26 January 2013 (UTC)
    • This is still going on. For example: FC Barcelona - the last edit I can see in the revision history is from 21 January. I never had this problem before. Most articles which where edited since 22 January are not shown with their recent versions. Even purge does not help. Only editing. Crazy thing: When I edit a page (or when I make a 0-edit) I can see the recent revisions. But when I delete the cookies in my browser the recent revisions disappear. --79.216.49.235 (talk) 02:21, 26 January 2013 (UTC)
      • Template:Date shows the 22nd for me. Biosthmors (talk) 03:21, 26 January 2013 (UTC)
      • Well not after a purge. It updated to the 26th. Biosthmors (talk) 03:22, 26 January 2013 (UTC)

An anonymous browser request just now for Main page (lowercase "p", which redirects to Main Page) from Europe is still showing 22 January:

Extended content

HTTP request: GET /wiki/Main_page HTTP/1.1 Cache-Control: max-age=0 If-Modified-Since: Tue, 22 Jan 2013 02:02:00 GMT HTTP response: HTTP/1.0 304 Not Modified Date: Tue, 22 Jan 2013 02:34:05 GMT Last-Modified: Tue, 22 Jan 2013 02:02:00 GMT Age: 351590 X-Cache: HIT from amssq39.esams.wikimedia.org X-Cache-Lookup: HIT from amssq39.esams.wikimedia.org:3128 X-Cache: MISS from knsq29.knams.wikimedia.org X-Cache-Lookup: MISS from knsq29.knams.wikimedia.org:80 HTML source: <!-- Saved in parser cache with key enwiki:pcache:idhash:15580374-0!*!0!!*!4!* and timestamp 20130122020202 --> <!-- Served by srv275 in 0.165 secs. --> For comparison, the actual main page (Main Page, capital "P") is showing 26 January when requested anonymously, but still showing the MediaWiki:Sitenotice even though the notice was blanked 2.5 hours ago: <!-- Saved in parser cache with key enwiki:pcache:idhash:15580374-0!*!0!!*!4!* and timestamp 20130126011833 --> <!-- Served by mw1094 in 0.170 secs. -->

Is this related to the relatively large job queue (currently around 400,000 and risen over the past few hours)? Not sure if the cache will now be updated routinely as the job queue is processed in due course, or if the stale pages indicate an ongoing fault.

— Richardguk (talk) 04:52, 26 January 2013 (UTC)

It's not solved. Only the main page seems up to date, everything else isn't. For example, I tried to purge Template:Did you know, but no luck - I still see the revision from 16:00, 22 January 2013 when I log out. (But the main page shows the latest DYK, it is up to date.) I also see the same outdated revision histories, nothing has changed. --Moscow Connection (talk) 05:52, 26 January 2013 (UTC)

I tried purging Template:ITN-Update and Template:DYK-Refresh but it still shows the time as 01:42 UTC even though I live at UTC+4 and the time here is nearly 10:00am, so therefore the clock should be about 6:00am. It's not a huge problem (at least it shows the correct date!) but the clock still seems to be a few hours behind here. - a boat that can float! (watch me float) 06:02, 26 January 2013 (UTC)

Yep, I still have to rely on versions from January 22/23 and then forward diff by diff to get the later changes - I purged the browser: no effect, neither on en.wp nor de.wp or es.wp, regards --Jan eissfeldt (talk) 08:54, 26 January 2013 (UTC)

Nothing got better. A lot of pages are just visible until 22/23 January and some pages updated but then they stopped again at 24 or 25 January (like probably the main page stops at 26 January?) For example the Main page of the French Wikipedia has also still this problem. But this problems concerns not just the unimportant mainpages. It concerns the about 1 billion pages in all wikipedia languages When you edit a page OR sign in you see the current version. But as soon as you delete your cookies you see again versions which are outdated since up to four days. --93.209.82.159 (talk) 10:26, 26 January 2013 (UTC)

I'm in the US and I had the outdated pages problem only when I was not logged in. When I was logged in, I didn't notice any problem. --Bob K31416 (talk) 12:18, 26 January 2013 (UTC)

Re Redrose64's comment, "The main page problem began very recently, and has affected many users whether logged in or not. By contrast, users who are not logged in have always been served cached copies of most pages, primarily for reasons of speed." — How often are cached copies updated? --Bob K31416 (talk) 13:54, 26 January 2013 (UTC)

It seems to me that although edit history is outdated, main page and other pages (like Northern Mali conflict (2012–present), whose edit history shows only edits before 24th, but the page clearly mentions things that happened on that date). 94.92.6.136 (talk) 14:01, 26 January 2013 (UTC)

The revision history is often more outdated and does not show the revision which appears. But also the revision which appears is often outdated since days. --Yoda1893 (talk) 19:40, 26 January 2013 (UTC)

• I just want to let everyone know that we've poked all the right people, hopefully they can keep tracking down the issue :-/ Jalexander--WMF 15:37, 26 January 2013 (UTC)

Tracked in Phabricator
Task T46360

Hi folks - I'm the person who solved the problem before. Our purging infrastructure works by sending multicast purge requests to the cache boxes. To purge between the US and Europe, since we have private IPs plus we can't use private multicast ranges across other peoples networks, we have a relay that converts the multicast requests to unicast. Basically what happened is that one of the routers in Tampa had a stale entry in its multicast forwarding table, preventing the multicast tree for that group from being built up to the new datacenter in Ashburn. When we switched the mastership over, purge requests were then sourced from Ashburn, showing us this "fun" bug. This means that all purge requests that should have been sent to Europe had been basically "black holed." Since the relay machine saw no traffic, it was unable to relay those requests, and the nature of purge requests means that the servers which request the purges aren't waiting for an "ack." Therefore all of the purge requests have been lost in time, and wil not be "caught up." All new purge requests will be sent properly. Purging stale pages should fix the problem. This problem should only have been seen in the European caching center and therefore only visible to visitors from Europe. If see a stale page, please append ?action=purge to the page, forcing a purge. If this still does not fix the issue, please file a bug on bugzilla https://bugzilla.wikimedia.org/ LeslieCarr (talk) 17:03, 26 January 2013 (UTC)

The problem is still alive and kicking, LeslieCarr. For instance, I can only see your preceding entry on this page in edit mode. It does not show up in the ordinary article. Refreshing with "?action=purge" has no effect, either on this page or any other I try. Unfortunately, I'm not sufficiently technical to understand how to file a bug on bugzilla. (I'm probably not alone in this!) The worst effect of this problem isn't the minor inconvenience that articles are slightly out-of-date but that the history revision pages aren't updated (the "?action=purge" command isn't even recognized there!). This must be causing absolute havoc with conflicting edits, especially by the many editors who might still be completely unaware of this problem. 92.24.97.99 (talk) 17:50, 26 January 2013 (UTC)

Purge still does not have any effect when I'm not logged in. I reported bugzilla:44391 --Yoda1893 (talk) 19:36, 26 January 2013 (UTC)

• Thanks Yoda1893 -- It looks like the multicast bug has bitten us again - i will be spending some time on the routers today to try and fix this — Preceding unsigned comment added by LeslieCarr (talk • contribs) 19:45, 26 January 2013 (UTC)

Related report in the bugtracker is bugzilla:44360. --AKlapper (WMF) (talk) 19:53, 26 January 2013 (UTC)

Email notification

Hi, I've probably done something completely wrong but my email notifications of changes to watched pages seemed to suddenly stop yesterday evening; it had been working correctly until then. I have checked everything is still all ticked in 'preferences' in case I'd inadvertently changed something. To check that the email address was working I even sent myself an email from my alternative email which came through. I also tried sending myself an email from Wikipedia using the email this user facility, which hasn't arrived either. I use a Mac (if that makes any difference). I hope I'm managing to explain this query correctly! SagaciousPhil - Chat 15:03, 23 January 2013 (UTC)

Based on the comments in the #wikimedia-operations channel, it should be fixed now. Legoktm (talk) 15:22, 23 January 2013 (UTC)

Wow, thanks for such a speedy response! I'm still not getting anything through, I picked up your reply by constantly checking my watch list (I know - obsessive/compulsive springs to mind!). At least it's a relief to know it's unlikely to be something I've done and I'll just wait patiently as I'm not technical enough to know how to work the operations channels. SagaciousPhil - Chat 15:31, 23 January 2013 (UTC)

By the way, notifications were delivered a few hours later, within the end of the day (at least for me). --Nemo 13:40, 24 January 2013 (UTC)

Broken link at http://www.wikipedia.org/

When English is selected from The Wikipedia landing page it generates an error stating "No site configured at this address". Its been doing this for a few days.

When English is selected it tries to link to: http://en.wikipedia.org/ and I think it should be http://en.wikipedia.org/wiki/Main_Page. Kumioko (talk) 20:54, 23 January 2013 (UTC)

That's odd, http://en.wikipedia.org/ takes me to the main page whether I click the link on the landing page or enter it to the address bar (it automatically adds wiki/Main_Page as soon as the browser follows the link). The landing page works as I'd expect for me in Chrome and IE9. James086^Talk 20:59, 23 January 2013 (UTC)

(edit conflict) Ditto, working for me. Writ Keeper ⚇♔ 21:00, 23 January 2013 (UTC)

Are you using Firefox? If so try this? James086^Talk 21:03, 23 January 2013 (UTC)

Working properly in Firefox 18.0.1/Windows 8. jcgoble3 (talk) 21:26, 23 January 2013 (UTC)

That's interesting. I've tried it on 2 different computers with IE and Firefox and it doesn't work here. I also tried clicking the other links around the globe and they work, just not the english one. Kumioko (talk) 21:27, 23 January 2013 (UTC)

What URL does it lead you to? What HTTP headers and what HTML are you receiving? Ucucha (talk) 21:31, 23 January 2013 (UTC)

As I mentioned above it leads me to http://en.wikipedia.org/ and then generates a blank white page with "No site configured at this address". Its no big deal if no one else is having the problem. I've also already cleared my cache and my recent history. I even tried to restart my computer. I just thought it was something to do with the Server move from Fl to Va. Kumioko (talk) 21:34, 23 January 2013 (UTC)

Link http://en.wikipedia.org/ works fine for me redirects to http://en.wikipedia.org/wiki/Main_Page.Moxy (talk) 21:39, 23 January 2013 (UTC)

Redirect OK here, US user, Firefox 18.0.1, Windows 7 Ultimate N x64, no extensions installed that are affecting Wikipedia (I even disabled AdBlock for Wikipedia, even though Wikipedia has no ads). 50.46.184.47 (talk) 23:38, 25 January 2013 (UTC)

I suspect this is fixed now - could you check and let me know? Philippe Beaudette, Wikimedia Foundation (talk) 14:09, 26 January 2013 (UTC)

Hold the champaign

Special:Preferences gives my "Registration time" as 14:22, 16 October 2003; yet http://toolserver.org/~tparis/pcount/index.php?name=Pigsonthewing&lang=en&wiki=wikipedia says I made my first edit on Jan 26, 2003 08:34:04 - which is correct? Could the issue arise because the January edit was deleted? Should I, like the Queen of England, celebrate two "birthdays"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:28, 24 January 2013 (UTC)

Actually, your first deleted edit (according to Special:DeletedContributions) was to Be in Birmingham 2008 on October 17, 2003. I'm not sure what the January 26 edit would be—possibly a database inconsistency. Ucucha (talk) 16:32, 24 January 2013 (UTC)

Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:46, 24 January 2013 (UTC)

For people who registered before September 2005, the Registration time was populated from the first edit at the time it was populated. There are other ways to determine the registration date for such affected people. MBisanz ^talk 17:57, 24 January 2013 (UTC)

You probably moved a page over a redirect when the bug described in the second-last paragraph of the section about moving over a redirect was in force. The edit may have since been nuked because somebody moved the page back over it (i.e. changing the title back to what it was before your page move). The errant edit is probably somewhere in the old dumps. Graham87 13:03, 25 January 2013 (UTC)

Sorry to add a "me too", but this is still not resolved. Is there a publicly available link that shows what is going on, and that someone is actually working on this? 46.115.53.225 (talk) 14:15, 26 January 2013 (UTC)

I don't think that you intended to post to this thread, which is about this tool. I suspect that you wanted to post to #Users reporting site time issues and delay in visible update of edits a few sections above. --Redrose64 (talk) 15:11, 26 January 2013 (UTC)

Text and redirect in redirect page

In this article Fxall (or in this version of the article) and IP editor added some text without removing the redirect tag (go to edit mode to see)! Ignoring their formatting error, shouldn't the text in that page break the redirect? Or any changes recently? --Tito Dutta (talk) 16:29, 24 January 2013 (UTC)

No, MediaWiki simply ignores all text after a #redirect line. Ucucha (talk) 16:33, 24 January 2013 (UTC)

To clarify, it does parse templates, and uses category and interwiki links appropriately. It just doesn't display any of the text after the redirect line, although it once did. — Carl (CBM · talk) 16:35, 24 January 2013 (UTC)

I think a more important issue is the added text is promotional and a blatant copyvio of www.fxall.com/about. I have removed it. Chris857 (talk) 20:31, 24 January 2013 (UTC)

Special:StudentActivity

Tracked in Phabricator
Task T40095

Tracked in Phabricator
Task T45786

Special:StudentActivity is giving me a most unhelpfully vague error message:

[a7fd4997] 2013-01-24 17:57:26: Fatal exception of type MWException

What is needed to a) fix the problem and b) de-mystify the error message for when it appears in the future? – Philosopher ^{Let us reason together.} 18:12, 24 January 2013 (UTC)

I would try through WP:BUGZILLA or a note on Wikipedia:Education noticeboard. MBisanz ^talk 18:17, 24 January 2013 (UTC)

The unhelpful error message is presumably for security and privacy protection; the server admins will probably have access to the full error message, which may include sensitive data. Ucucha (talk) 21:49, 24 January 2013 (UTC)

Admin can't see revdel'd revisions

I seem to be unable to check out the revdel'd revisions at Derby sex gang. I don't even get to check the box for selecting a revision. I'm an admin; I was logged in; it usually works. What happen? Bishonen | talk 21:00, 24 January 2013 (UTC).

Oversight. Writ Keeper ⚇♔ 21:01, 24 January 2013 (UTC)

We have an admin who doesn't know how oversight works? My Wikipedia confidence meter just went up! —  dain- talk   22:36, 25 January 2013 (UTC)

content not refreshing from Hungary, using ipv6.

Hi,

I have tried firefox, opera, chrome, reload, private browsing, f5, ctrl-f5, but i still see the state of the main page as it was on the 23rd of january. It seems that a squid needs a kick.

Extended content

GET /wiki/Main_Page HTTP/1.1 Host: en.wikipedia.org Connection: keep-alive Cache-Control: max-age=0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17 Accept-Encoding: gzip,deflate,sdch Accept-Language: hu-HU,hu;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.3 Cookie: centralnotice_bucket=1-4.2; clicktracking-session=HBszflapTPzHCS9W0J1TpTXaa5HZfSrvq; mediaWiki.user.bucket%3Aext.articleFeedback-tracking=10%3Atrack; mediaWiki.user.id=57FUr6tSm2LJWGc2cBerv7Qv2Qrl8UCD If-Modified-Since: Wed, 23 Jan 2013 14:58:51 GMT HTTP/1.1 304 Not Modified Server: nginx/1.1.19 Date: Fri, 25 Jan 2013 04:24:38 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive Last-Modified: Wed, 23 Jan 2013 14:58:51 GMT Age: 134746 X-Cache: HIT from amssq43.esams.wikimedia.org X-Cache-Lookup: HIT from amssq43.esams.wikimedia.org:3128 X-Cache: MISS from amssq44.esams.wikimedia.org X-Cache-Lookup: HIT from amssq44.esams.wikimedia.org:80 Via: 1.0 amssq43.esams.wikimedia.org:3128 (squid/2.7.STABLE9), 1.0 amssq44.esams.wikimedia.org:80 (squid/2.7.STABLE9) GET /w/index.php?title=MediaWiki:Gadget-ReferenceTooltips.js&action=raw&ctype=text/javascript&508635914 HTTP/1.1 Host: en.wikipedia.org Connection: keep-alive Cache-Control: max-age=0 Accept: */* If-Modified-Since: Wed, 22 Aug 2012 16:12:35 GMT User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17 Referer: http://en.wikipedia.org/wiki/Main_Page Accept-Encoding: gzip,deflate,sdch Accept-Language: hu-HU,hu;q=0.8,en-US;q=0.6,en;q=0.4 Accept-Charset: ISO-8859-2,utf-8;q=0.7,*;q=0.3 Cookie: centralnotice_bucket=1-4.2; clicktracking-session=HBszflapTPzHCS9W0J1TpTXaa5HZfSrvq; mediaWiki.user.bucket%3Aext.articleFeedback-tracking=10%3Atrack; mediaWiki.user.id=57FUr6tSm2LJWGc2cBerv7Qv2Qrl8UCD HTTP/1.1 304 Not Modified Server: nginx/1.1.19 Date: Fri, 25 Jan 2013 04:24:38 GMT Content-Type: text/javascript; charset=UTF-8 Connection: keep-alive Last-Modified: Wed, 22 Aug 2012 16:12:35 GMT Age: 23 X-Cache: HIT from amssq37.esams.wikimedia.org X-Cache-Lookup: HIT from amssq37.esams.wikimedia.org:3128 X-Cache: MISS from amssq40.esams.wikimedia.org X-Cache-Lookup: HIT from amssq40.esams.wikimedia.org:80 Via: 1.0 amssq37.esams.wikimedia.org:3128 (squid/2.7.STABLE9), 1.0 amssq40.esams.wikimedia.org:80 (squid/2.7.STABLE9)

— Preceding unsigned comment added by 2001:470:1F09:64B:213:E8FF:FEC5:70A5 (talk) 04:43, 25 January 2013 (UTC)

See discussion above: #Users reporting site time issues and delay in visible update of edits jcgoble3 (talk) 05:17, 25 January 2013 (UTC)

When it will start to work archivebot.py and weblinkchecker.py?

1) archivebot.py

I put in the parameters

|algo = old(1d)

Several days have passed, but still appears

Processing 10 threads There are only 0 Threads. Skipped

When it will be back up?

2) weblinkchecker.py

I set the parameter-day:1 several days have Passed, but the bot is doing nothing.

And the errors are gone. I think that the problem is not only in my family file, because the same error occurs when I run the bot in Russian Wikipedia.

http://pastebin.com/x1zQipmU

Thanks.--Ворота рая Импресариата (talk) 12:18, 25 January 2013 (UTC)

What's changed about images placed on the left?

In the past couple of days I've noticed that images placed on the left are no longer rendered where they should be. I haven't completely parsed the problem yet, but it appears that if a left-hand image is listed before any right-hand image it will be properly placed, but if it's coded after a right hand image, it gets pushed down to below that image, even if the right-hand image is pushed down by, for instance, an infobox. This is totally new. The left hand image used to render where it came in the coding, even if the right-hand image had to shift down because some other item was in its way.

What's changed? Beyond My Ken (talk) 13:04, 25 January 2013 (UTC)

I've put an example of the problem in my userspace, at User:Beyond My Ken/temp, taken from the Yonkers article. Note that there are three right-hand images which begin just before the "Northwest Yonkers" section. Then there are two left-hand images which should appear at the beginning of the "Southeast Yonkers" section, because that is where they are place in the coding. Instead, those images don't start until the top of the third right-hand image, so they are pushed down the page out of the section they're intended to be connected to. If the left-hand images were coded before the right-hand images, they would appear where they were placed, and the right-hand images would appear in the correct place also. (Feel free to play around with the page to verify this for yourself.) This is different from how image placement used to work, and it's not an improvement. Beyond My Ken (talk) 13:32, 25 January 2013 (UTC)

This has been normal behaviour for a very long time. Images are always rendered in the same order that they appear in the wikicode. --Redrose64 (talk) 13:33, 25 January 2013 (UTC)

I'm sorry, but that is not the case. A large proportion of the work I do is in page layout, and the images have never rendered in this fashion until recently, nor should they. Images used to (and should) render where they are put in the code, with the right and left images not interlinked in any way, which appears to be the case now. There's no reason that an image on one side of the page should be dependent on the position on an image on the other side of the page, and once they were not, but now they are in some fashion.

BTW, I've checked this under Firefox, Chrome, IE, Safari and Opera, both logged in and logged out, so this is not a browser-dependent problem, not is it anything to do with my settings. Beyond My Ken (talk) 13:44, 25 January 2013 (UTC)

See Wikipedia:Village pump (technical)/Archive 107#Layout funny in particular the rules for floating elements. I've been posting replies to similar questions here and on other talk pages for well over two years; my posts normally included the two words "pushed down" but I don't know of an easy way to go through nigh on 72,000 edits looking for the ten or so posts of that nature to see when I first described it. --Redrose64 (talk) 14:11, 25 January 2013 (UTC)

Could this be caused by your browser switching to CSS or HTML5 standard layout rules? "The outer top of a floating box may not be higher than the outer top of any block or floated box generated by an element earlier in the source document." (CSS2, emphasis added.) Wikipedia switched to HTML5 last year, but I think Internet Explorer initially included Wikipedia on a transitional list of websites to render in quirks mode, and the layout mode can also be affected by user preferences. So different browsers will have applied different layout rules at different times. — Richardguk (talk) 15:18, 25 January 2013 (UTC)

Detecting interwiki links

Is there a way to detect which articles (in a category) have interwiki links on them? I'd like to generate a "priority list" for translation of the articles in a certain category to other Wikipedias, and "have they already been translated somewhere" would be a very useful thing to know. – Philosopher ^{Let us reason together.} 17:06, 25 January 2013 (UTC)

Would this tool help? It's intended for finding articles not translated into a particular language, but it might be practical for your purpose. Andrew Gray (talk) 17:11, 25 January 2013 (UTC)

Got it! If you search for an invalid language code like "xx" as the target, you'll get all articles with any interwikis, sorted by most translated. This search returns 69 articles from the 107 in Category:Presidents of the Oxford Union, ranging from one with 91 interwikis to 20 with only one. Andrew Gray (talk) 17:25, 25 January 2013 (UTC)

That isn't working for me - I wonder if the tool can't process categories with parentheses in their names, maybe? – Philosopher ^{Let us reason together.} 01:36, 26 January 2013 (UTC)

You can also get this information (probably with more options) from querying the toolserver database. I can run queries for you if you want. Legoktm (talk) 17:55, 25 January 2013 (UTC)

That'd be great! What I want for this project is a list of the members of Category:Iowa_(government)_articles that do and that don't have a version in another Wikipedia. If it's not too much more work, a list sorted by how many interwiki links are on them would be better, but the set's small enough that that probably doesn't matter. – Philosopher ^{Let us reason together.} 01:36, 26 January 2013 (UTC)

IW links will change when we get Wikidata soon. For example, the IW links for United States will be centrally stored at d:Q30. See Wikipedia:Gadget/proposals#Display Wikidata Info on Wikipedia for a script to link pages to their Wikidata page. — Preceding unsigned comment added by Gadget850 (talk • contribs) 01:57, 26 January 2013 (UTC)

Egads!!

Technical glitch when a nice individual implemented something requested at AN. Fixed now - nothing more to see
The following discussion has been closed. Please do not modify it.
Cowabunga, dude Suddenly, everything's centered, in small text, and the navigation bar on the left is below all the page content. - The Bushranger One ping only 17:47, 25 January 2013 (UTC) Ditto with Monobook and Firefox. I'm so glad it's not just me. :) SlimVirgin (talk) 17:48, 25 January 2013 (UTC) I am experiencing the same issue with Chrome, though not consistently. §everal⇒|Times 17:49, 25 January 2013 (UTC) Switched from Monobook to Classic and back (on Chrome) and the problem disappeared. Ritchie333 (talk) (cont) 17:49, 25 January 2013 (UTC) Same here with chrome and the default layout!--TKK bark ! 17:49, 25 January 2013 (UTC) Now back to normal for me. SlimVirgin (talk) 17:50, 25 January 2013 (UTC) Ditto with IE. Alden Loveshade (talk) 17:50, 25 January 2013 (UTC) hide the banner at the top, then refresh the page. Frietjes (talk) 17:51, 25 January 2013 (UTC) Fixed now here too. - The Bushranger One ping only 17:52, 25 January 2013 (UTC) Looks like all text is centered, small, and the menu on the left is pushed below all content. Imagine it's something being looked into already but makes me scared of Wikipedia! Cheers. Andre666 (talk) 17:48, 25 January 2013 (UTC) if you close the "notice" at the top of the page, then reload, the problem goes away. someone forgot to close a tag up there. see the threads above and below. Frietjes (talk) 17:50, 25 January 2013 (UTC) Who ever put up that new banner on the Main page not updating has caused all text to appear small and centered! Please guys, a bit of professionalism. On a technical note, I'm using Chrome on Windows 7. 88.170.241.162 (talk) 17:49, 25 January 2013 (UTC) I was just about to report this. A workaround is to hide the banner and refresh the page. The Anonymouse (talk | contribs) 17:49, 25 January 2013 (UTC) Looks like it has been  Fixed. The Anonymouse (talk | contribs) 17:52, 25 January 2013 (UTC) Several Wikipedia articles are being presented in a centered text format (as if they were being edited to have a central alignment). When the history of the page is viewed, the articles return to normal formatting. Due to the widespread appearance of this effect, I doubt that it is intentional mal-editing. I have viewed Wikipedia on several browsers and two different laptops to rule out any system issues. It appears that this is a Wikipedia-related glitch and not a problem with my personal computers. Are there any other individuals experiencing this odd formatting? — Preceding unsigned comment added by 76.189.156.116 (talk) 17:50, 25 January 2013 (UTC) hide the banner at the top, then refresh the page. see the threads above. Frietjes (talk) 17:52, 25 January 2013 (UTC) (edit conflict)Mentioned above; it was a broken close tag in the technical notice banner at the top of the page. Fixed now; doesn't need to be closed first. - The Bushranger One ping only 17:53, 25 January 2013 (UTC) I don't know why or if anyone else is having this problem or not (I don't have time to read through everything people have said right now), but all of the content in every page on Wikipedia is showing up in smaller font than normal, and is centered in the middle of the page for some reason. Even the "Save page", "Show preview", and "Show changes" buttons are centered on my screen as I'm posting this. I've already checked some of the settings of my browser (including zoom, which is at 100%), and I don't think it's my fault. I'm pretty sure the sidebar and top bar are still their normal sizes, though. Alphius (talk) 17:51, 25 January 2013 (UTC) hide the banner at the top, then refresh the page. see the threads above. Frietjes (talk) 17:52, 25 January 2013 (UTC) (edit conflict)Mentioned above; it was a broken close tag in the technical notice banner at the top of the page. Fixed now; doesn't need to be closed first. - The Bushranger One ping only 17:53, 25 January 2013 (UTC) Thanks for the quick response! Alphius (talk) 17:56, 25 January 2013 (UTC) My contributions are centered. It looks weird. IE9 and whatever the default was back in 2007. I think that's Monobook.— Vchimpanzee · talk · contributions · 18:04, 25 January 2013 (UTC) And now my contributions look normal. I didn't do anything.— Vchimpanzee · talk · contributions · 18:06, 25 January 2013 (UTC) Why should this be advertised in every article and create panic if it is about Main Page only?···Vanischenu「m/Talk」 18:09, 25 January 2013 (UTC) For the "why" question, see discussion at WP:AN, section "Do we need a site notice regarding the main page update problem?". The centering was my fault; I forgot to close a <!-- comment -->. Someone else closed it a few minutes later, thus explaining the contributions looking normal. Nyttend (talk) 18:24, 25 January 2013 (UTC) Thank you. (Actually, I liked the way it appeared. I thought that a major change was coming, something like LiquidThreads.) Thanks for your kind reply.···Vanischenu「m/Talk」 18:59, 25 January 2013 (UTC)

Center-aligning and shrinking the text was my fault. Nyttend (talk) 17:58, 25 January 2013 (UTC)
The following discussion has been closed. Please do not modify it.
Below moved from Users reporting site time issues and delay in visible update of edits above. – PartTimeGnome (talk | contribs) 23:18, 25 January 2013 (UTC) My pages are center-aligned. Huh. --Golbez (talk) 17:47, 25 January 2013 (UTC) That has been fixed. —Kusma (t·c) 17:51, 25 January 2013 (UTC) All the pages in article namespace appear centre-aligned and in a smaller font. Anir1uph | talk | contrib 17:51, 25 January 2013 (UTC) OH MY GOD GUYS WHAT DID YOU DO. it's updated for me but the font is tiiiny (8pt?) and there's ugly bullet points everywhere and pages are randomly center-aligned omg what happened god help us all Anyway, the navigation sidebar also got bumped to the bottom of the page for me, so there's like a big blank spot where the navigation bar is supposed to be. — NovaDog — (contribs) 17:52, 25 January 2013 (UTC) I just came here to mention the center alignment as well, I found that the siteNotice div is not being closed until the very bottom of the page, so its "text-align: center" style is covering everything. There's a comment in the code with "/sitenotice" right after the mw-dismissable-notice div where I guess it should be closed, but isn't. Onlynone (talk) 17:56, 25 January 2013 (UTC) Issues with the font size and alignment are all my fault. Someone requested an editnotice at WP:AN, so I created it, but I included a <!-- comment and forgot to close it with a -->, so the small size and centered text of the editnotice ended up applying to the entirety of every page. Nyttend (talk) 17:58, 25 January 2013 (UTC) 2013/01/25 This page http://en.wikipedia.org/wiki/MSC_Divina displays center-aligned and small font. — Preceding unsigned comment added by 69.156.63.180 (talk) 20:28, 25 January 2013 (UTC)

How to fix Portal: Current Events

Portal>Current Events are not being updated on Main Page after user edit.

Simply go and undo previous edit by different ip

Refresh main page and the undone edit will be shown.

17:50, 25 January 2013 (UTC) 187.12.26.206 (talk) 17:50, 25 January 2013 (UTC)

Please see Users reporting site time issues and delay in visible update of edits above. – PartTimeGnome (talk | contribs) 23:20, 25 January 2013 (UTC)

Edits not in article

Edits in several articles show up in the edit history complete with renderred article underneath but not in the article under the article tab. This has happened in several articles and despite rebooting, refreshing my browser IE9, the edits refuse to show up. I attempted to do a minor edit to one that presented this problem and it appeared in the article but disapeared when I re-accessed the page, next time. One of the later special effects is the last edit line in the edit history has disappeared too. Good luck with this one. I believe this happenned last fall, also. Not in article talk page.[11], Not even in edit history page unless you slide to next [12]. 174.118.142.187 (talk) 22:35, 25 January 2013 (UTC)

They're back! Pays to complain? :) 174.118.142.187 (talk) 22:38, 25 January 2013 (UTC)

Please see Users reporting site time issues and delay in visible update of edits above. – PartTimeGnome (talk | contribs) 23:20, 25 January 2013 (UTC)

And now the problem is back on another machine! Spoke too soon! Thanks. I read that and figured that problem was a fixed one from the past. LOL 174.118.142.187 (talk) 23:54, 25 January 2013 (UTC)

why can i not hide this

its Due to a technical issue, some users are receiving outdated versions of pages, including the main page. Please see the village pump for details. i want to hide it i have read it alot today 65.175.255.73 (talk) 00:54, 26 January 2013 (UTC)

It appears to be perfectly hidden to me. For you, is there no hide button at all, or is it simply not working? Someguy1221 (talk) 00:55, 26 January 2013 (UTC)

Remembering to hide the message presumably requires the browser to have JavaScript and cookie-saving enabled. So some users will see the message again each session (if they have only session. cookies enabled) or all the time (if they have cookies disabled). — Richardguk (talk) 01:06, 26 January 2013 (UTC)

The village pump to see for details is this page – see "Users reporting site time issues and delay in visible update of edits" above. Please add your comments on this issue to the end of that section. Do not fragment the discussion by creating new sections on the same issue.

To add to an existing section: Click the "edit" link to the right of the section heading, scroll to the bottom of the edit box, then add your comments at the end of the edit box. – PartTimeGnome (talk | contribs) 21:51, 26 January 2013 (UTC)

New toolbar

I've just started getting a new toolbar popping up at the right margin of some pages - "Show metadata", "Send appreciation...", etc. I can dismiss it, but it still shows up on other pages. How can I make it go away and never reappear? -- Boing! said Zebedee (talk) 13:41, 26 January 2013 (UTC)

Oh, I did recently view the new "New pages patrol" thing, and I see one of the tools in the new toolbar is "Go to the next page in the queue". Has viewing the new patrol thing left me with this toolbar? -- Boing! said Zebedee (talk) 13:42, 26 January 2013 (UTC)

This is Page Curation. You might ask at the link provided. When you access Special:NewPages, at the top of the page it talks about Page Curation. — Maile (talk) 13:46, 26 January 2013 (UTC)

Ah, thanks - I'll go ask there. -- Boing! said Zebedee (talk) 13:47, 26 January 2013 (UTC)

If you click the small "x" in the corner of the toolbar, it'll vanish, until such time as you visit Special:NewPagesFeed, which triggers it again. Andrew Gray (talk) 21:13, 26 January 2013 (UTC)

Edit Count

According to My Preferences, this was my 10,000th edit. However, according to X!'s edit counter, it was my 10,046th. Which is correct and why? --Gilderien Chat|List of good deeds 19:39, 26 January 2013 (UTC)

And according to Wikipedia:List of Wikipedians by number of edits/5001–6000 you had 10,109 edits when the list was last compiled at 04:52 on 23 January 2013. None of the figures is ever right - I have often had a spread of over 1000 across the three figures - so gave up bothering about the numbers - they don't make you a better editor. Arjayay (talk) 19:53, 26 January 2013 (UTC)

Oh ok thanks. I am aware that editcountitis is not a good thing, but wished to record my 10,000th edit. I had thought I remembered from somewhere that the My Preferences is more accurate, have you heard this (or contrary) as well? --Gilderien Chat|List of good deeds 20:12, 26 January 2013 (UTC)

See Wikipedia:Edit count.—Wavelength (talk) 20:47, 26 January 2013 (UTC)

At Wikipedia:List of Wikipedians by number of edits, something happened to the data that it's prepared from (it uses one of those rosemary/thyme things) in August 2012. Previous to then, it was known to read too low; but in August, many figures rose by unusual amounts, and since then, many edit counts (but not all) read far too high when compared to the ones at Preferences, X!'s Edit Counter, WikiChecker or River's Edit Counter. My own count at Wikipedia:List of Wikipedians by number of edits got boosted by around 2000 edits in August, and as of 23 January 2013 was reading either 633 or 1274 too high compared to X!'s Edit Counter, depending on whether Wikipedia:List of Wikipedians by number of edits counts deleted edits or not. --Redrose64 (talk) 21:11, 26 January 2013 (UTC)