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

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)

• Note: bugzilla:44512, if resolved, will implement a feature that would allow the addition of rel="noreferrer" on the backend software. — Parent5446 ☯ ^{(msg email)} 18:06, 30 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)
• Support This should be an explicit Opt-In, not Opt-Out, choice. Unless readers are aware that the site can see their URL, this is not an acceptable practice. RolandR (talk) 21:22, 30 January 2013 (UTC)
• Support, privacy is good. Stifle (talk) 19:43, 31 January 2013 (UTC)
• Support—It may not be much, but it couldn't hurt.—Kelvinsong (talk) 18:34, 2 February 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)

• Opppose Per X! and MartinPoulter. Ryan Vesey 01:28, 1 February 2013 (UTC)
• Oppose per MartinPoulter. --99of9 (talk) 03:28, 1 February 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)

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)

They always call soccer football, we had great disc jockeys that are never on here, and American kids are not learning how to spell the words properly. — Preceding unsigned comment added by 75.18.161.228 (talk) 09:21, 31 January 2013 (UTC)

Huh? jcgoble3 (talk) 20:19, 31 January 2013 (UTC)

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

Tracked in Phabricator
Task T46391

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[1]. 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)

The main page of en.wp did not update to January 27 (when not logged in and without cookies) until now. The problem which concerns all pages in every language concerns now again also the main page of en.wp. purge does not work. --79.216.49.61 (talk) 03:05, 27 January 2013 (UTC)

Just so you know, I am seeing January 26, 2013 (UTC) as the current date in the "On this day..." section while not logged in. Refreshing nor purging the page seems to have an effect on what I see. It is currently January 27, 2013, 10:06 here in the Czech republic, so the correct UTC time should be January 27, 2013, 9:06 UTC. I am running Firefox 18.0.1 on Mac OS X 10.6.8. I also checked the Czech and Slovak main page, however they both seem to show the correct date, so the problems appears to be specific to the English Wikipedia. 83.208.213.135 (talk) 09:06, 27 January 2013 (UTC)

Okay, so right after I posted that comment, I went back to the main page, refreshed it, and now it shows January 27 for me. I don't know what caused it, but it must have happened in the last ten minutes maximum. The only thing that comes to my mind is the actual action of previewing and posting the previous comment here. Couldn't that have affected the process and somewhat forced the main page to purge when ?action=purge didn't? 83.208.213.135 (talk) 09:14, 27 January 2013 (UTC)

When your cookies are deleted or you use another browser it will be again January 26 on the main page and a lot of articles will show you revisions from January 26, January 25, January 24, January 23 or January 22. For example at List of Spanish football transfers winter 2012–13 the current version contains transfers until January 26. But as European IP (without having edited or when you edit and delete cookies) you can only see transfers until January 24 and the revision history shows only edits until January 22. --79.216.48.157 (talk) 10:45, 27 January 2013 (UTC)

Its still ongoing here - even with purging. And its not only the main page - its all pages. One reason that many people might not be reporting this is that its hard to see whats going on or not, as this discussion is only visible once you edit the entire page. There is a lot of not quite right information going around, as everyone is seeing a slightly different view of the problem. FWIW, Firefox 10.0.07, Debian testing, cookies disabled, javascript disabled.46.115.99.15 (talk) 10:24, 27 January 2013 (UTC)

• I don't know whether this is related, but Wikipedia:Today's featured article/Tomorrow is currently showing me the Featured Article from January 24 (i.e. it's showing what it should be showing on January 23) and nothing I can do (refresh, purge etc.) can fix it. This also occurs when I am logged out, and I've also just tried it on my phone (via 3G, so a different IP address) and it's the same there as well. Black Kite (talk) 11:00, 27 January 2013 (UTC)

I'm getting the correct January 28 one (about Jane Austen). I think that the reason that some Europeans are reporting "still broken" where others are reporting "no, it's all OK now" is because there is more than one server, some of which are fully up to date - and of those that are stuck in the past, they are not all "behind" to the same degree. If you retrieve a page which is clearly out of date, it might have come from a particular server (let's call it "A"); then if you go away and come back (or somebody else retrieves the same page), it might now come from server "B" which yields a different cached copy, which may be up to date. So, "A" needs maintenance whereas "B" might not. --Redrose64 (talk) 15:02, 27 January 2013 (UTC)

• Relate or not, it become impossible to update old .svg. No purge method seems to work. On Commons, en, fr. Thumbs generated remain unchanged. file description page keeps the 6 year old png (from SVG). Update histories do not always include recent updates. Any infromation / advise welcome - thank you [Firefox and Chrome on XP) Eurocommuter (talk) 15:44, 27 January 2013 (UTC)

I can confirm this (SVG uploads not working). I am trying to edit (remove drop shadow) from File:GOP Logo1.svg, a file hosted on WP for licensing reasons. I can locally confirm that the rsvg library and Firefox render the new SVG source correctly. But after I first uploaded the fixed version to WP, the cached PNG thumbnail did not update. Before, I've encountered this with malformed SVGs, so I optimized the SVG to make it very simple and again verified it renders with Firefox and rsvg. After uploading the second .SVG source, the first upload's PNG thumbnail did suddenly refresh, however. But it does not help, because the most recent file's PNG cache remains un-updated. I am editing from Europe through the .NL servers --hydrox (talk) 00:33, 28 January 2013 (UTC) ed Sweet, purging the server cache worked! --hydrox (talk) 23:39, 28 January 2013 (UTC)

Unfortunately I'm in no position to immerse myself into this. Just want to report that the problem persists here. Both articles and histories are up to at least two days old, but just in some pages, and the "edit" tabs seem to be updated. I've purged, tried different browser, all of that. 83.253.228.202 (talk) 18:28, 28 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)

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.[2], Not even in edit history page unless you slide to next [3]. 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)

Main Page updates

I'm still having problems with main page note showing correctly. In UK and it is 27th Jan but main page is from 26th. Using XP with Firefox. — Preceding unsigned comment added by 79.69.251.91 (talk) 18:16, 27 January 2013 (UTC)

Latest update from Operations

Hey all :). So, I've just been talking to Leslie Carr, one of our more awesome Ops engineers - and by 'awesome' I mean 'she spent 8 hours being batted around tech support and developers at the company that makes some of our hardware, and even more troubleshooting'. She's been working literally non-stop on this since Friday, and is incredibly sorry about both the problem and the fact that it's taking so long. Hopefully we'll have it resolved soon: in the meantime, thank you to all of you for your patience, and to Leslie for her hard work :). I'll let you know as soon as we have an update. Okeyes (WMF) (talk) 01:11, 28 January 2013 (UTC)

Thank you for the feedback, and thanks to you and awesome Leslie and everyone else for keeping the technology tamed and helping to turn our random edits into a world class resource! — Richardguk (talk) 02:01, 28 January 2013 (UTC)

And thanks for the lovely words! They're much appreciated :). Okeyes (WMF) (talk) 17:28, 28 January 2013 (UTC)

• Apparently the problem /should/ hopefully be fixed; try ?action=purge to clear old versions, and they should filter out over time naturally as the cache updates :). Let me know if it doesn't work. Okeyes (WMF) (talk) 04:43, 28 January 2013 (UTC)

I just checked another user's talk page where I had edited. Nothing yet. I made a minor edit and the combined edits result showed up on the talk page. After exiting and reloading the talk page it is gone again. hmmmmm... very strange. Actually this edit doesn't even show in the edit history page. Best and luck to you. 174.118.142.187 (talk) 16:13, 28 January 2013 (UTC)

Did ?action=purge, added to the URL, not work? Okeyes (WMF) (talk) 16:52, 28 January 2013 (UTC)

"?action=purge" didn't do anything for me. Well first I had to know where to put the option text. LOL I have purged my caches a few times (shift <F5> and shift <browser refresh> on each page this has happenned to me. I cannot see your response, above on the page and I still do not see my minor indent edit to my own message, yet. I see them all in this edit text box and once I hit "Save Page" but when returning they do not exist again. 174.118.142.187 (talk) 18:19, 28 January 2013 (UTC)

Now this page seems to be fine and fully updated but the user's talk page this edit still does not appear from 4-5 edits back. When I added the purge to the URL it came back with a purge request confirmatiion box, both times (that did not occur ever on this WP:VPtech page) and yet still old news. I think there may be some selective eHarrassment from the system at selective places. :) 174.118.142.187 (talk) 18:42, 28 January 2013 (UTC)

I can see the latest edit in the revision history. But it doesn't change the way the page is rendered anyway. To purge edit histories, add "&action=purge", not "?". (The question mark is already there.) --Moscow Connection (talk) 21:54, 28 January 2013 (UTC)

It gets better with that one... "Search for "Wikipedia:Village pump (technical)&action=purge" in existing pages of namespace Wikipedia.". Looks like incorrect syntax using a string concatenation operator? The "?" works and is not already there in any page I have seen. Thanks 174.118.142.187 (talk) 22:12, 28 January 2013 (UTC)

I was talking about revision histories, which look like "http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)". Since your latest edit would have been invisible on the page anyway, I thought maybe you wanted to just see it in the revision history and couldn't. To purge edit histories, add "&action=purge". It worked for me. (That's what I meant.) --Moscow Connection (talk) 22:22, 28 January 2013 (UTC)

(Or maybe, when an article is purged, its revision history is purged too. I tried to purge a page now and its history became updated.) --Moscow Connection (talk) 22:31, 28 January 2013 (UTC)

• Purging works for me now. I'm in Russia. I've also purged some edit histories, adding "&action=purge" to the URL, and they updated. --Moscow Connection (talk) 21:41, 28 January 2013 (UTC)

Er... sorry to spoil your fun, but it isn't possible to purge edit histories separately from the article. The URL for a page history looks like this: https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=history. If you add &action=purge to that, it will have two action= parts. MediaWiki resolves the duplication by ignoring all instances of action= except the last one. Hence the effect is the same as if you had just added ?action=purge to the URL of the article itself. (You might be right about purging an article also purging its history. I've never had to deal with an out-of-date edit history before.) – PartTimeGnome (talk | contribs) 23:02, 28 January 2013 (UTC)

I thought that I maybe actually purged the article and the history simultaneously. That's why I added a note (two replies above, in brackets.) But anyway, the history was outdated and the purge worked. --Moscow Connection (talk) 23:17, 28 January 2013 (UTC)

I see now. There was one "action" already. So I purged the article and both the article and its history were updated. There was no fun involved, cause I updated all the other articles the usual way and noticed that their histories become updated too. --Moscow Connection (talk) 23:29, 28 January 2013 (UTC)

• See Query string for more on why & sometimes doesn't work but ? does. In brief: use a ? unless the URL already has one, in which case use a & --Redrose64 (talk) 22:41, 28 January 2013 (UTC)
• A purge takes more time to appear now. I purged a page and the page took over 30 seconds or so to actually update. I had already thought that the problem returned and was going to post here when I checked and the latest edit was there. --Moscow Connection (talk) 06:19, 29 January 2013 (UTC)
• New feature announcement: New edits sometimes don't appear in the edit history until the page is purged. It was the case with articles, but now with edit histories too. I've just seen a fresh out-of-date revision history. An edit made on January 29 (after the purge problem was fixed) didn't appear neither in the article, nor in the revision history until I purged the page. Like PartTimeGnome, I had never seen an out-of-date edit history before January 22. Did outdated revision histories (like outdated articles that need purging) become a new feature of Wikipedia? But the way, I could see the edit in the user contributions.--Moscow Connection (talk) 06:19, 29 January 2013 (UTC)

  Oooh :(. This is weird; I'll talk to Leslie again (tomorrow. She's taking today off due to the working-for-8-days-in-a-row thing) Okeyes (WMF) (talk) 17:01, 29 January 2013 (UTC)

  • Are we going to have to purge all articles or will this fix itself on its own? Cal Rein appears to have been fixed once I purged it, but it had been deleted 7 days previously and was still displaying. – Philosopher ^{Let us reason together.} 17:19, 29 January 2013 (UTC)

• This is still happening ocasionally for me. It was on a talk page with another person's edit. The purge command on the URL worked (I got confirmation boxes both timees) but it took about 15-20 minutes, and three or four browser refreshes to get my copy of the page to reflect the edit from hours back. 174.118.142.187 (talk) 15:06, 30 January 2013 (UTC)

• Yep, happened today again - but only once, thanks to and for doubtlessly hard work done - on Meta, where I initially was forced to access Micru's replies via the history, best regards --Jan eissfeldt (talk) 22:10, 30 January 2013 (UTC)

Template error

Can someone check the template that generates the "we're currently having trouble with the main page" blurb? It appears to be causing the text on the page below where it is transcluded to be in small and centered text (in Chrome for Mac, at least), making the site effectively unreadable. Looks like an unclosed tag or two. Thank you. 94.192.225.169 (talk) 19:24, 30 January 2013 (UTC)

This is the issue described at #Egads!! below. You must be accessing a cached copy of the pages: the problem you describe was fixed five days ago, and the whole message was taken down four days ago. I suggest that you clear your browser cache. --Redrose64 (talk) 19:52, 30 January 2013 (UTC)

First time I'd ever visited the page in question, so nothing in the cache. Not using a proxy server either. Perhaps just one of those internetty things that happen and thus not my fault and not worth the slap down reply. Thanks. 94.192.225.169 (talk) 19:57, 30 January 2013 (UTC)

It's all still happening to new edits and events. Even the message appears and disappears randomly in the same pages. The message went from just the "main page" to "main page and others" and now back to "main page" again, when it appears. Tese are the same pages I have been to dozen times without a message. Still needs some unhacking, yet. 174.118.142.187 (talk) 20:57, 30 January 2013 (UTC)

Revision history is outdated while the article is up to date

Something strange is going on. This happens when I'm not logged in, I'm in Russia. This article この街 (森高千里の曲) in the Japanese Wikipedia is up to date, but its edit history is not showing the 3 latest edits, made on January 30 (UTC). The latest edit listed is from January 23. (History. These edits: [4] [5] [6] are not listed.) I didn't try to purge the page now cause I wanted to show the problem. When I log in, the problem disappears. --Moscow Connection (talk) 02:32, 31 January 2013 (UTC)

Update: While I was writing this, another edit was made, and the article and the history became up-to-date. --Moscow Connection (talk) 02:36, 31 January 2013 (UTC)

Another up-to-date article with out-of-date history in the Japanese Wikipedia: 湾岸ワンダーダーリン/ラズベリーラブ. When I'm not logged in, I can still see the latest revision of the article, but the article history doesn't show the latest edit, made on January 28 (UTC). (There were only 3 edits, on January 13, 25 and 28.) (When I log in, I can see the edit in the history.) I notice problems only in the Japanese Wikipedia simply because I don't edit much lately and don't have an opportunity to notice much. --Moscow Connection (talk) 08:06, 31 January 2013 (UTC)

Question is if this still happens after a purge... --84.42.203.5 (talk) 04:31, 1 February 2013 (UTC)

No, for me it doesn't happen after a purge. Articles don't update immediately aftar I purge them, but eventually, in a few seconds or minutes, they do update. I didn't purge the last example intentionally, though. So anyone can check if they see more than two edits in the history here: [7]. --Moscow Connection (talk) 16:17, 1 February 2013 (UTC)

(For me it doesn't, but I haven't spent that much time in Wikipedia lately to be sure everything is fixed. People in the section "Template error" above say that for them the problem with pages that won't purge persists.) --Moscow Connection (talk) 16:17, 1 February 2013 (UTC)

Image revisions not appearing in articles

I have noticed several updated images I have uploaded recently, along with one uploaded by another user, that are still appearing in articles with the original revision. The original revision of File:P&O Cruises Australia.png was appearing in the article infobox in a stretched form but has now been replaced by a vector file. File:DVLA.svg is still appearing in the Driver and Vehicle Licensing Agency article as the old logo rather than the new version that was uploaded on 28 January. File:Edinburgh Airport logo.png was still appearing with the old logo so I replaced it with another upload under a different filename. File:Costa Cruises Logo.png still shows the original revision without transparency. The images I have uploaded all come up in my file list with the updated revisions. Cloudbound (talk) 14:04, 1 February 2013 (UTC)

Regex for replacing wikilink with absolute link

I'm doing commons:Commons:Bots/Requests/Smallbot_8#Discussion and some of the pages have wikilinks. As those pages will be copied over to a different wiki, those wikilinks will no longer be valid. As such, I'd like to replace the wikilink with the absolute link (a->a). I'd prefer python 2.7 syntax, but other formats would be fine.Smallman12q (talk) 00:46, 28 January 2013 (UTC)

Wikilink parsing isn't easy. There are a lot of edge cases. Probably best to use MediaWiki's built-in parser for this. --MZMcBride (talk) 18:30, 28 January 2013 (UTC)

Would you also want links in the form [[Page|title]] represented as [//en.wikipedia.org/wiki/Page title]?  Hazard-SJ  ✈  01:57, 31 January 2013 (UTC)

Yes. It's not necessary for this upload, but an available implementation of such a function would be useful. Smallman12q (talk) 22:48, 1 February 2013 (UTC)

What is your favorite color?

Does anyone know what the code is for the exact shade of grey which is the background-color of the Table of Contents that sits at the top of pages with more than 3 sections, e.g. this very page?

Eyeballing it, thru trial and error, I approached it to something like 0xF9F9FA (the border is just plain old 0x000000):

This is 0xF9F9FA

But I'd like the exact code. Do you know it off the top of your head? If not, how do I find that out? And while we're at it, what is the code for the shade of grey of the border of the Table of Contents? Signed: Basemetal (write to me here) 07:21, 28 January 2013 (UTC)

The background is #F9F9F9, and the border is #AAAAAA (or #AAA). --Yair rand (talk) 08:15, 28 January 2013 (UTC)

(If you use Chrome, you can right-click on an element and open "Inspect element" to find out the effective styles. Similar tools exist for other browsers.) --Yair rand (talk) 08:17, 28 January 2013 (UTC)

Thanks a lot Yair rand for info and the tips. Thanks to you I'm moving up one step. No more eyeballin that old screen :-). Cheers. Signed: Basemetal (write to me here) 08:28, 28 January 2013 (UTC)

Really, the RGB values are equal??? To me it looks subtly but unmistakeably bluish. --Trovatore (talk) 08:24, 28 January 2013 (UTC)

Never mind; I didn't realize we were talking about the TOC. I thought we were asking for the background color for the discussion section. --Trovatore (talk) 08:26, 28 January 2013 (UTC) It looks like that one is 0xF8FCFF, which at least someone out there refers to as "ghost white". Is that right? --Trovatore (talk) 08:35, 28 January 2013 (UTC)

The pale blue background for this page is   rgb(248, 252, 255) (or #F8FCFF in the old money). GhostWhite   has slightly less green - #F8F8FF or rgb(248, 248, 255). --Redrose64 (talk) 11:58, 28 January 2013 (UTC)

OS X comes with a built-in tool for determining colors called DigitalColor Meter. For Windows, you can download a free tool called ColorPix. --MZMcBride (talk) 18:29, 28 January 2013 (UTC)

Thank you MZMcBride. ColorPix works on any part of the display whereas Yair rand's advice only works in a Chrome window, right? Incidentally I tried to use Yair rand's method but it only works in some areas of a Chrome window. I click the right button of the mouse, I get a pop-up and I choose "Inspect element". I get the HTML windows. I open the "Styles" window. For some areas of a Chrome window

element.style {

}

contains the data I want, background color, etc., but in most of the cases (and in particular in the case of the TOC)

element.style {

}

is just an empty structure. Only once, I don't know what I did, the pop-up I got (the HTML window was already open so I had already done "Inspect element" once) had only two choices (one of them being "Inspect element" again) and when I chose that again I got an

element.style {

}

with the data I wanted in the "Styles" window. But that happened only once and I could never reproduce the sequence of actions I took to get to that point. So what am I doing wrong? How do I get the background color for any part of a Chrome window with "Inspect element"? How come for now it works only for some parts of the window? Signed: Basemetal (write to me here) 07:55, 29 January 2013 (UTC)

In this case, the relevant style is applied to the <table> element. Once you click on the element, you should see a section below the element.style section titled "Matched CSS rules", which will include styles other than those directly applied using the style attribute. Alternatively, you could expand the "Computed style" section. --Yair rand (talk) 08:07, 29 January 2013 (UTC)

Thanks again Yair rand. Got it. Signed: Basemetal (write to me here) 08:59, 29 January 2013 (UTC)

Noindex not working?

Wikipedia:WikiProject Abandoned Drafts/Suzanne M. Olsson - if you search for her name, this noindexed page is the first to show up on Google.[8]. Dougweller (talk) 14:30, 28 January 2013 (UTC)

Actually, it's the talk page appearing on google, not the article page. Adding noindex on the talk page should resolve the problem. — Edokter (talk) — 15:03, 28 January 2013 (UTC)

Agh, thanks. Dougweller (talk) 11:35, 29 January 2013 (UTC)

UI: page layout compromise needed

Resolved

There is a parallel discussion at WT:ELEMENTS#Names in basic PT --Redrose64 (talk) 22:15, 28 January 2013 (UTC)

re: The OP here links to that discussion. Actually, it died 2 1/2 weeks ago and now points to VPT. -DePiep (talk) 22:31, 28 January 2013 (UTC)

About the iconic {{Periodic table}}. A reader noted in feedback that the element names should be there, and rightly so. I've come up with {{Periodic table/sandbox}}. Now width (horizontal px) is the issue. I squeezed out a lot. Still, when on screen 1024x768 (like old tubes), it is too wide. Column 18 ends up next to the page ("canvas"?). My question is: what to do? Is that wide overflow acceptable? Use {{wide template}}? Any other tricks re width? Project discussion at here. -DePiep (talk) 18:48, 28 January 2013 (UTC)

The names are there; they show up as tooltips. You version also looses the borders that denote some key properties. I'm sure the width was a consideration for the current design. None of the tables in print I have ever seen have the full element names. — Edokter (talk) — 20:04, 28 January 2013 (UTC)

Tooltips (aka mousehover): WP:ACCESS#Text says: Do not use techniques that require interaction to provide information, such as tooltips or any other "hover" text..

Borders that denote some key properties: the border I removed only signs one property (natural occurrence). Compared to the name, such a "key property" is way less relevant, and I deliberately offered it. Really, if one can't find an element (but for hovering over 100), such a property is completely useless (and of course: that might be re-added somehow by using vertical space; is what I have been trying).

"I'm sure the width was a consideration for the current design." - How to reason with that? I have considerations too.

"None of the tables ... in print ... have names" - not convincing they should be left out. Maybe internet offers new possibilities.

See also below. -DePiep (talk) 21:59, 28 January 2013 (UTC)

(edit conflict) The element names are already present; hover your mouse over a symbol like H and it shows as a tooltip (at least, it does in Firefox; IE might have its own ideas). --Redrose64 (talk) 20:06, 28 January 2013 (UTC)

Mousehover: see above me re Edokter. It is a secondary way of providing info. Hope you are not looking for Tungsten. -DePiep (talk) 21:59, 28 January 2013 (UTC)

The full names are too much for the main table which becomes too large. Periodic table (large version) displays {{Periodic table (large version)}}. Wide periodic table (large version) displays {{Periodic table (wide large)}}. Extended periodic table (large version) displays {{Periodic table (extended, large)}} and {{Periodic table (Pyykkö model, large)}}. They all include full names. PrimeHunter (talk) 20:33, 28 January 2013 (UTC)

Yes, that is what I wrote: it became too wide. But at least my sandbox version only has one column (18) spoiling in a specific situation (lowres screen). A sort of tradeoff on what is acceptable is what I am looking for. Having to click into the blind to get primary information is not WP:ACCESS. -DePiep (talk) 21:59, 28 January 2013 (UTC)

@Edokter, Redrose64, PrimeHunter. I think the element name should be in the table at first sight. It is primary information. Not every reader knows what the symbols are for gold, silver, mercury, phosphorus -- not the most obscure elements. Mousehover and click-more is a secondary way for readers, they don't find what they look for (sure "but somewhere else the information is"). Apart from Edokter's "I have never seen it" I have read no argument against adding names for information reasons. My question was "how could it be done", not "why not". -DePiep (talk) 21:59, 28 January 2013 (UTC)

It can't be done; there simply isn't enough space, as you can see in all the other versions. Your version has the names printed so small they are almost illegible, which is an accessibility issue in its own. — Edokter (talk) — 22:39, 28 January 2013 (UTC)

These other (wider) versions clearly were not designed to match the width constriction, and they do not suggest so. And so they do not prove it is impossible (anyway they do not try {{shy}}). Seems like PrimeHunter improved the sandbox [9], even when I set the font-size from 80% to 85% for legibility. Apart from darmstadtium (110), I see this issue gone in 1024x768 screen. -DePiep (talk) 10:30, 29 January 2013 (UTC)

Yes, but still no borders. And what about 800x600 screens? And mobile devices? There will always be limitations. Just because it now fits on 1024x768 does not mean the problem no longer exists. — Edokter (talk) — 10:47, 29 January 2013 (UTC)

About using the the border: above I explained that their informative value is less than the element name, so I choose accordingly in the trade-off. That property is descriptive, not identifying. Adding your argument (not mine): that information is in the tooltip text. Next: 1024x768 is the smallest screen size to be checked as per WP:ACCESS. As for mobile devices: I found no mobile-specific guidelines for wiki pages. Maybe you can point to them. As I understand it, well crafted CSS and tags should cover that. -DePiep (talk) 11:10, 29 January 2013 (UTC)

Trading one piece of information for another is not a solution. The occurence info is just as vital. And as PrimeHunter has pointed out: the other periodic table templates do contain the full names, which is linked to where ever the basic template is used. The table as it is does conform to WP:ACCESS; abbrivations (which is what the symbols are) are exempt from the 'hovering' rule. — Edokter (talk) — 15:16, 29 January 2013 (UTC)

I traded (the presentation of) information with different qualities. I never claimed the current version is not WP:ACCESS. They are not abbreviations they are symbols (Au for gold), and I am not dropping or disputing them. Now that you state that these other (way wide) templates do correctly show the names, why would you not let the basic one get wide too (like saying "hey you can't go wide, and by the way these other wide templates are fine")? My point of question was and is to combine the goodies of these two. I was just asking for some thinking along, just about a sandbox. In general, can you tell me what went wrong here? Why do you think of new objections by the hour, without paying attention to my earlier responses? Can you please step over some kind of 'I don't like' treshold, and point to possible improvements. That would be helpful. -DePiep (talk) 16:34, 29 January 2013 (UTC)

I can't see any possible improvement here without sacrificing other information. What you want is basically have one of the wide templates (with names) fit into the 1024 boundary. Making the basic template go wider is simply redundant to the ohter existing templates. — Edokter (talk) — 17:10, 29 January 2013 (UTC)

OK, so you could not see it happening, but that is not a reason to conclude and argue it should not be tried. Just a note saying so would have done then, leaving it to others to search further. And actually it did happen. Shortcutting all argumentation, I can say the need for some compromise solution, I was looking for here, is gone: the current sandbox version combines all requirements. That is: the infomation fits within the 1024 screen. Looks like problem is solved. -DePiep (talk) 16:45, 30 January 2013 (UTC)

Can't say I like that solution either; now the table is in danger of not fitting the 768-pixel vertical boundary. Just what is wrong with the current template? — Edokter (talk) — 19:56, 30 January 2013 (UTC)

Sigh. There is no vertical border, it's a page. And what is wrong? Full circle, start from top. -DePiep (talk) 22:16, 30 January 2013 (UTC)

Look, it's just not going to work. {{Periodic table}} is built to fit comfortably on any page at the cost of element names, while the wide tables provide all information, including the element names, but those require more space, which means they do not fit 1024. There is simply no 'one size fits all' solution here. — Edokter (talk) — 23:24, 30 January 2013 (UTC)

Edokter, it already is working and showing for a few days. I do not understand why you keep repeating that it won't fly while it is already sitting there in a tree. And my original question here is resolved. Even better: it didn't need a compromise (wrt contradicting requirements). So we might as well close it as resolved here. -DePiep (talk) 15:56, 31 January 2013 (UTC)

I suggest taking this up at Template talk:Periodic table or Wikipedia talk:WikiProject Elements to see if it will gain any support. Technical issues aside, I'm pretty sure the current sandbox version won't fly, there are too many inconsistencies with the other tables, the legend no longer matches and takes it too much space. — Edokter (talk) — 16:53, 31 January 2013 (UTC)

"Compare selected revisions" bug or feature?

Have you noticed that it is impossible to Compare selected revisions if the two revisions you wanna compare reside on two different pages of the list of revisions? For instance if you chose to display 20 revisions per page then it is impossible to compare the latest revision and the 21st latest revision (or even the 20th latest revision and the 21th latest revision because the 20th latest and the 21st latest are displayed on different pages). Of course you can always change the number of revisions displayed on each page to get around that but that's very inconvenient and time consuming. And my point remains that this is not how things should behave in my opinion. Is this behaviour intentional or is is a bug? Signed: Basemetal (write to me here) 00:54, 29 January 2013 (UTC)

Hi. You know you can click the "(cur)" link next to any revision to see the diff between that revision and the current version of the page, right? So it doesn't matter what your pagination is set to if the goal is only to diff to the current revision.

Pagination is better than the alternative: attempting to display every revision in the same browser window. That would be pretty awful for any large page history.

I don't see a bug here, but perhaps you could elaborate on what you envision for a better implementation? --MZMcBride (talk) 01:27, 29 January 2013 (UTC)

What I think would be more convenient is that the two top "bullets" (what do you call them actually?) to the right of "(cur | prev)" are not automatically selected and do not automatically turn blue when you click for a new page of results. This way you could pick say the 5th most recent on the first page of results. The "bullet" turns blue indicating that this is the more recent version you want to compare. Then you click for new results, 1, 5 or 10 results pages later (depending on the length of the revision history of course) and you choose, say the 125th most recent version. Then you click the "Compare selected versions" button and you get the diffs between the 5th most recent and the 125th most recent version. Why you would want that is your problem. If people start arguing on the basis of "Who would ever want that?" there's no point. The question is, is there any downside to things working that way? I don't see any. Anyway, the way it works now is that you type for a new result page and the selection on your previous page is forgotten: the two most recent revisions in that page get selected and their "bullets" turn blue automatically. I hope what I am trying to describe here is clear. At least it could be an option in your "Preferences" if you would like those things to get reset any time you click for a new result page or instead work the way I am trying to describe here. Signed: Basemetal (write to me here) 05:44, 29 January 2013 (UTC)

A better question is, why should a developer spend time on such a feature? Unless you are planning to do the work yourself, "Who would ever want that?" is one question to answer if you want to convince a developer to make changes for you. Using someone's time to make the changes is a downside. Also, the additional complexity introduced by software changes should be considered. Preferences is already a mess with lots of options, I'd prefer to avoid adding more if it can be avoided... – PartTimeGnome (talk | contribs) 22:04, 31 January 2013 (UTC)

Getting rid of pagination is of course not a method I'd consider sensible of giving people the option of comparing any revision to any other. That goes without saying. Signed: Basemetal (write to me here) 05:59, 29 January 2013 (UTC)

No, it seems perfectly normal and acceptable for 99.5 percent of uses. It would seem odd to need to perform this whether systematically (or often enough) to warrant such a feature for everyday use. If you want to find the difference between two versions separated by a relatively long period of time, you can also do so by selecting a larger number of versions – you can do any of 20, 50, 100, 250, 500 in the history by simple click (or almost an infinite number if you change it from within the url bar of the browser) and then diff your two versions. -- Ohconfucius ^{ping / poke} 02:11, 29 January 2013 (UTC)

Well yes, you can do that say in the URL bar of the browser, but first you would have to get the 9 digit revision id for the two revisions you want to compare. I don't see it in my results page when I click "View history". And even if there is a way to conveniently get those ids (is there?) I find it more convenient to not have to mess with the URL, you can always make mistakes while typing. The click of a mouse is always the more convenient option. Most of all, I don't see why the behavior I am suggesting for those "bullets" would not be as natural and intuitive and more convenient than the present one (and it could of course be provided as an option only in your "Preferences"). Incidentally why was it considered necessary that the two "bullets" once you have selected them and made them turn blue need to not be on a line with each other, that is why does the more recent revision have to be offset to a location that is on a line to the right of the line of the older revision? Why was that considered useful? To rephrase this: why does the x-coordinate of the bullet of the newer revision need to be to the right of the x-coordinate of the bullet of the older revision? Whew. Is what I am trying to say here clear? Signed: Basemetal (write to me here) 05:44, 29 January 2013 (UTC)

The simplest way I know of getting a revision number is to look at the oldid parameter in the URL of the linked timestamps in the history list. Sometimes I wonder if it would be nice to have them more visible, but maybe that would just confuse or alienate people. Also, check out the User:DerHexer/revisionjumper gadget; you can enable it in the Special:Preferences#mw-prefsection-gadgets. I recently used it to track down and compare revisions over hundreds of edits.

 Also, I think I understand what you mean about the positioning of the old and new revisions. I believe the left-hand column is meant for selecting the old revision, and the right-hand column is for the new revision. If you manage to swap these around (maybe if inhibit Java Script?) you’re going to be comparing the old revision as if it were newer than the new revision, and the differences will be the opposite of normal (removing text that was actually added, etc). Vadmium (talk, contribs) 06:25, 29 January 2013 (UTC).

Yes, but why do those "bullets" need to be in two columns? Of any two revisions only one can be the older and the other the newer. I don't see how there could be any confusion there. A revision is newer than another one simply by virtue of it being later. Couldn't the "bullets" all be in one column? (Is no one gonna tell me what those things are really called?) Signed: Basemetal (write to me here) 07:13, 29 January 2013 (UTC)

Now I seem to remember they're called "radio buttons". Is that correct? Signed: Basemetal (write to me here) 09:23, 29 January 2013 (UTC)

They are indeed radio buttons: and one of the features of the radio button is that in any given group, only one may be selected - all the others of the group must be deselected. Therefore, to have two buttons selected at the same time requires them to be in different groups - hence the two columns, one for each group.

When Ohconfucius put "you can do any of 20, 50, 100, 250, 500 in the history by simple click (or almost an infinite number if you change it from within the url bar of the browser) and then diff your two versions", this didn't refer to the revision numbers of a page diff (as used in the &diff= and &oldid= fields), but to the &limit= field of the revision history itself. Let's say you are viewing http://en.wikipedia.org/w/index.php?title=Radio_button&action=history - by default, this shows 50 entries. You can change it to 20 by clicking 20 - or you can do exactly the same by appending &limit=20 to the URL. This works for any positive integer up to 5000. --Redrose64 (talk) 10:00, 29 January 2013 (UTC)

There's also Special:ComparePages, of course. --MZMcBride (talk) 20:01, 29 January 2013 (UTC)

Using Italic or Bold in your section title seems impossible if you create the new section by choosing "New section" at the top of the page

Have you noticed that if you want to add a section to a talk page and you do it by choosing the "New section" button at the top of the page, it is impossible to use Italic or Bold in the title of the section. Whereas it is perfectly possible to do if you create the new section "manually" by simply editing the whole file and inserting a line ==<new section name here>== like I just did here and in the title of another new section above. So, bug or feature? Signed: Basemetal (write to me here) 01:03, 29 January 2013 (UTC)

Why would you want to? Italics and bold don't really belong in section titles (✉→BWilkins←✎) 01:07, 29 January 2013 (UTC)

Italics are sometimes appropriate in section headings. You see this a lot in articles about authors, where specific works may be considered watersheds or otherwise appropriate for a section heading (for example, this). Regards, Orange Suede Sofa (talk) 01:19, 29 January 2013 (UTC)

Not true anyways. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 01:14, 29 January 2013 (UTC)

Yeah, the premise of the question is just false. It's perfectly possible to type apostrophes/inverted commas/single quotation marks into the section header field. I guess you can't actually click the Bold text or Italic text buttons, but does anyone actually use those? Evanh2008 ^{(talk|contribs)} 01:24, 29 January 2013 (UTC)

I do. But you're right I did not realize it was only the shortcut buttons that didn't work. Of course I did not say that you couldn't have bold and italic in the section header (my own section header had them, didn't you notice?) but only that you could not get them by using the "New section" button, and I did not try to insert myself the '' and ''' markers by hand. Signed: Basemetal (write to me here) 04:54, 29 January 2013 (UTC)

Basemetal, see the section below. When I saw your post, my tablet did not render italics (I use Puffin), so I had to fire up my PC to make sure the italics were rendered for Wikipedians in general. --Ancheta Wis   (talk | contribs) 03:24, 29 January 2013 (UTC)

Basemetal, thank you for adhering to the expectation that one does not delete the posts of another editor. We could just wait for the bot to archive quiescent sections. Would that be OK with you? --Ancheta Wis   (talk | contribs) 12:20, 29 January 2013 (UTC)

Is it possible that some browsers don't render bold and italic formatting within header tags? It seems clear that MediaWiki handles them fine. Ucucha (talk) 03:43, 29 January 2013 (UTC)

Ucacha, I think it is the Puffin browser that does not render italics, in general, and not just within section headers. I live with it because my device is "instant-on" and generally more convenient for me to read Wikipedia. That said, I have to be very careful with my touches. --Ancheta Wis   (talk | contribs) 12:29, 29 January 2013 (UTC)

test test2

x Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 01:14, 29 January 2013 (UTC)

Congratulations. Is it ok now to ask you to delete your test section? Or I can do it for you if you prefer. Signed: Basemetal (write to me here) 04:44, 29 January 2013 (UTC)

italic and bold

Test. I entered the title under 'New Section'. --Ancheta Wis   (talk | contribs) 01:24, 29 January 2013 (UTC)

But not by using the shortcut buttons. Is it ok to delete this test section now? Signed: Basemetal (write to me here) 04:46, 29 January 2013 (UTC)

Who sez "new section" cannot be italicised or bolded?

I created this as a new section to test the assertion immediately above. In successfully doing so, I have demonstrated that it is indeed possible to italicise and bold text in headings. However, if Basemetal is seeking to use the shortcuts immediately above the edit window to perform a one-click insertion, it's true they don't work. But how is that really a problem? -- Ohconfucius ^{ping / poke} 02:00, 29 January 2013 (UTC)

The assertion was not of course that you can't have bold or italics in a section header (my own section had bold and italics in it!) but only that you can't have it if you create the new section with the "New section" button and you are perfectly right I only tested the shorcut buttons I did not try to insert the markers '' and ''' myself by hand. Is this really a problem? What is really a problem, except death and taxes? It would be nice if they did. Do those shortcuts have a good reason not to work? Signed: Basemetal (write to me here) 04:40, 29 January 2013 (UTC)

• I just converted a bunch of the successful test sections into level 3 headers in order to keep the page organized. Legoktm (talk) 09:16, 29 January 2013 (UTC)

See also MOS:BOLD where it says "Bolded headings, though technically possible, are not appropriate." --Redrose64 (talk) 10:09, 29 January 2013 (UTC)

Did something go kablooey again?

It does not look like collapsible things are currently collapsible (i.e. in the sidebar and for subcategories) and the suggested edit summaries have disappeared. AutomaticStrikeout (T • C) 03:25, 29 January 2013 (UTC)

My watchlist is now indented funny. The collapsible items with arrows are indented further than those without, so it looks like this:

20:33 Dominican Order‎ (diff | hist) . . (+35)‎ . . Nguoibattudocco (talk | contribs) [rollback]

> 20:19 Jessica Brown Findlay‎‎ (7 changes | hist) . . (+84)‎ . . [Utahredrock‎ (7×)]

19:12 Over the Hedge (film)‎ (diff | hist) . . (+4)‎ . . 174.94.50.250 (talk) (→‎Plot: ) [rollback]

Where it used to be the case that all of the timestamps would line up in the same column, making it much easier to read the list quickly. Now it is much harder. Why the change? Elizium23 (talk) 03:39, 29 January 2013 (UTC)

Also, it doesn't look like scripts or Twinkle are working. AutomaticStrikeout (T • C) 03:54, 29 January 2013 (UTC)

I got it fixed by bypassing my cache. AutomaticStrikeout (T • C) 04:53, 29 January 2013 (UTC)

My watchlist issue has now fixed itself with little or no intervention from me. Thanks for the attention, though. Elizium23 (talk) 01:23, 31 January 2013 (UTC)

Image refusing to update

I mentioned this further up the page, but since the Solved tag was put on the general problem this related, but specific, one hasn't received any attention. So I'm relisting here as the problem persists.

There is a problem with File:The_cave_video_game_cover.png(hovering over this link shows the correct image, clicking it or going to the article doesn't), 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. Re-uploading the image has no effect either. Could someone fix this please? - X201 (talk) 11:21, 29 January 2013 (UTC)

I've found this is some sort of caching issue, i.e. it resolves itself in time. Annoying, I know. Grandiose (me, talk, contribs) 13:51, 29 January 2013 (UTC)

Thanks. What sort of time-scale? Its getting close to being a week. - X201 (talk) 14:55, 29 January 2013 (UTC)

Well in my case a couple of days... obviously I can't be certain that something more complicated is not happening in your case. I wonder if anyone else has any ideas. Grandiose (me, talk, contribs) 15:23, 29 January 2013 (UTC)

Depending on the issue, this can actually last indefinitely, at least until WMF Ops completes a difficult image handling change. Of course, it might also go very shortly (I think it's gone now? for me at least). See bugzilla:41130#c18 for a workaround if it doesn't. - Jarry1250 ^{[Deliberation needed]} 15:30, 29 January 2013 (UTC)

Fixed: Thanks. Just in case anyone else is having the same problem, I followed comment 24 in the link that Jarry provided above, and that fixed it. - X201 (talk) 10:56, 31 January 2013 (UTC)

Logs

I know this makes it easier for newbies to understand log entries, but how can I revert the new log format to the old one:

New format:

• [Edit=Block new and unregistered users] (expires 07:31, 30 January 2013 (UTC)) [Move=Block all non-admin users]

Old format:

• ‎[edit=autoconfirmed] (expires 01:29, 27 January 2013 (UTC)) ‎[move=sysop] (indefinite)

Werieth (talk) 19:45, 29 January 2013 (UTC)

I don't think you can, unless the devs revert whatever they did to the MediaWiki software yesterday at about 19:10 UTC - see here --Redrose64 (talk) 20:18, 29 January 2013 (UTC)

There isn't some CSS or JavaScript hack I can use? the new format is obnoxious. Werieth (talk) 20:57, 29 January 2013 (UTC)

What they did was upgrade enwiki from 1.21wmf7 to 1.21wmf8. The particular change being complained about appears to be this one, FYI. I don't think it was done for newbies so much as other languages, so that for example arwiki could see something like "[تعديل=امنع المستخدمين الجدد وغير المسجلين]" in their logs instead of "[edit=autoconfirmed]". Note that won't go live on arwiki until tomorrow, but you can see it now on non-Wikipedia projects such as de:wikt:Special:Log/protect. Anomie⚔ 21:35, 29 January 2013 (UTC)

I think this is actually less useful phrasing, because "new" is undefined while "autoconfirmed" has a definition. If there was a way to wikilink the "autoconfirmed" and "admin" (instead of sysop) text, that'd be best. Is this a change directly to the MediaWiki software or is there a MediaWiki: namespace file that can be changed? – Philosopher ^{Let us reason together.} 19:56, 30 January 2013 (UTC)

Additionally, I don't think it's beyond the realm of possibility that some (perhaps those less than proficient in English) could interpret it as "if you try to edit the page, you will be blocked". But hold on... if it's localized now, does that mean that we can change what it says? Because then we could compromise on something like [edit=Autoconfirmed users only] - new users would understand what it means, but we wouldn't feel like MediaWiki is treating us like toddlers. — PinkAmpers&^{(Je vous invite à me parler)} 16:08, 2 February 2013 (UTC)

Well, sort of. The messages are MediaWiki:protect-level-autoconfirmed and MediaWiki:protect-level-sysop. But there are two potential issues: 1, the messages are resolved when the page is protected, so it could be changed going forward but existing logs will still have the old text. And 2, these messages are the same ones used in the protection form itself, so whatever changes are made will be reflected there too. Anomie⚔ 21:09, 2 February 2013 (UTC)

To do list script

Does anyone know if a script exists where I could add an article to a to do list of sorts? When I come across an article I want to improve, I tend to add it to my watchlist, but pages that aren't actively edited don't show up. What I'd like is if there was a script so I could click a button and it would add it to some sort of articles to improve page in my userspace. I know I could manually create that, but it would be a lot easier with some type of script. Ryan Vesey 21:51, 29 January 2013 (UTC)

Pending changes technical issue

I have reviewer rights, but a little bit ago I had to accept my own edit on the Lea Michele bio. Just now I saw another reviewer experience the same issue on the Super Bowl article. Both times it seems to be a result of us using Twinkle to revert an edit.--The Devil's Advocate _{tlk. cntrb.} 21:53, 29 January 2013 (UTC)

As I understand it, MediaWiki only auto-accepts a revision if the revision immediately before it was accepted. The edit you reverted was not accepted, hence neither was yours. I think there is an exception if you use the rollback feature to revert to an accepted revision, in which case your edit would be auto-accepted (I'm not certain on this). Since you don't have rollback rights, I'm guessing this was a standard revert. – PartTimeGnome (talk | contribs) 22:22, 31 January 2013 (UTC)

A new bug when developing a category

Hello,

Today, I encounter a new bug in Wikipedia when I develop a category. With Safari Mac. I go at en.wikipedia.org/wiki/Category:Films_set_in_Poland. I click on the + to develop the category History of Poland on film. And I get this insult message :

“categorytree-collapse-bullet: Parse error at position 0 in input:”

Thank you for correcting that bug.

--Nnemo (talk) 21:56, 29 January 2013 (UTC)

I have Chrome on XP, and did not see the issue. Chris857 (talk) 03:36, 30 January 2013 (UTC)

I cannot reproduce with Firefox 17 on Linux either. Maybe try http://en.wikipedia.org/wiki/Wikipedia:Bypass_your_cache --AKlapper (WMF) (talk) 14:46, 30 January 2013 (UTC)

I reproduce the bug with Chromium 18, on Linux Ubuntu, on another computer, in another city. --Nnemo (talk) 11:56, 31 January 2013 (UTC)

Is the '+' you refer to literally a '+'? I think for most people it's been a blue triangle for a long time now. - Jarry1250 ^{[Deliberation needed]} 12:07, 31 January 2013 (UTC)

I still get [+] on all category pages. The bug affects all such categories (i.e. with three layers - the + is to expand a subcategory). I do not get it when logged out because then I get served triangles as suggested. Grandiose (me, talk, contribs) 12:27, 31 January 2013 (UTC)

Can you check if disabling your user script in Special:MyPage/common.js solves the problem? — Edokter (talk) — 12:57, 31 January 2013 (UTC)

This may be bugzilla:44459. If so, the fix is in progress. Superm401 - Talk 07:34, 1 February 2013 (UTC)

Does this tool exist already?

From a comment on WT:MED, is there such a a thing to auto generate a list of article rating by date. E.g., start class articles rated between Jan 1st 2010 and Jun 31st 2010...ty for advice. Lesion (talk) 22:23, 29 January 2013 (UTC)

Or June 30th even =D Lesion (talk) 22:25, 29 January 2013 (UTC)

I would drop a request at WP:1.0 or at WP:DBR. --Izno (talk) 13:20, 30 January 2013 (UTC)

will do, thanks. Lesion (talk) 13:26, 30 January 2013 (UTC)

What's up with the extra space after external links?

For several days at least I've been seeing an extra space after external links, and no icon for non-html doc links like pdfs, etc.. This results in commas and periods being misplaced, and the general look of amateur coding. Is this an ongoing problem that everyone but me is already aware of? I'm using Monobook, but I notice the issue when not logged in as well. — Sctechlaw (talk) 04:33, 30 January 2013 (UTC)

Like when there is a link to the Wikipedia portal? I don't know about non-HTML results but it works for me using Firefox. Check to see if your browser is using CSS. – Allen4names (IPv6 contributions) 06:26, 30 January 2013 (UTC)

Yes and yes. Disabling this stylesheet resolves the space issue (but also disables most WP styles too), so I'm wondering if that stylesheet was recently changed? This occurs in Firefox 18.01 on Win7-64 for me, haven't looked recently on other boxes. — Sctechlaw (talk) 15:56, 30 January 2013 (UTC)

Actually, the icons do appear, but when there is no icon, that's when the extra space appears. — Sctechlaw (talk) 16:41, 30 January 2013 (UTC)

(edit conflict) the stylesheet you point to is basically an agglomeration of many individual stylesheets. the "resourceloader" will do that. if you want to investigate, you should probably add "?debug=1" (or "&debug=1", depending whether the address line already contains a "?") to the address line. this will cause each stylesheet (and btw, also each script) to be loaded separately, so you'll be able to disable them one by one to find out which of them causes the issue. peace - קיפודנחש (aka kipod) (talk) 16:46, 30 January 2013 (UTC)

Ok, thanks for that; more info now:

• When I'm not logged in, I see no icons for external links that should have them, e.g., DOC, PDF, HTTPS (for a linked secure page), etc.. I also see an extra space after every external link.
• When I am logged in, I see the icons on links that should have them, but on external links that should not have any icon (plain HTTP links to an html-type document), there remains an extra space. Disabling this stylesheet resolves the issue, but also disable most WP styles. I hope this information helps resolve the problem.

— Sctechlaw (talk) 19:15, 30 January 2013 (UTC)

Here is a screenshot of what I see when I'm logged in.

— Sctechlaw (talk) 19:41, 30 January 2013 (UTC)

Only thing I see is the external-link icon missing. First thing to try is disable any user script and gadgets one-by-one to see if that fixes the problem. Most likely cause is that one of them may load conflicting CSS that causes the icon to diappear. — Edokter (talk) — 19:50, 30 January 2013 (UTC)

Here is a second screenshot (from Apple Inc. litigation footnote #52.) User scripts and gadgets are not "on" when one is not logged in, so that cannot be the issue. I did disable all Firefox add-ons in case that was the issue. but it had no effect. — Sctechlaw (talk) 20:23, 30 January 2013 (UTC)

Narrowing things down further, (1) there appears to be a stylesheet problem with the "Lock" icons for secure links when not logged in, and (2) same issue for non-secure external links whether logged in or not. In other words, when there is no lock icon to be used according the cascade, it leaves a space, and it shouldn't. — Sctechlaw (talk) 20:19, 30 January 2013 (UTC)

The space you see is reserved for the external link icon you can't see. There's nothing wrong with that space except for the absence of the icon that should be in it. Click here to view the icon directly. Can you see the icon if you click that link? If not, what do you see instead? – PartTimeGnome (talk | contribs) 22:39, 31 January 2013 (UTC)

Yes, I can see it from the direct link, that works fine. — Sctechlaw (talk) 23:19, 31 January 2013 (UTC)

But, the cascade is still broken: when logged out there is no lock icon, just a space; and when logged in or out there is no external link icon showing up, just a space where it should be. It wouldn't be so annoying if it didn't make things look so bad, as in image 2. Anybody? — Sctechlaw (talk) 11:32, 1 February 2013 (UTC)

I'm afraid there is no clear solution, as no one is able to reproduce the bug. — Edokter (talk) — 11:58, 1 February 2013 (UTC)

Try using differt skins. It looks like you are using Monobook so try Vector instead. This may be a problem with one of the servers returning a 401, 404, or other error so finding out what skin you are using and what server (do a host lookup) can help. – Allen4names (IPv6 contributions) 02:28, 2 February 2013 (UTC)

Allen, this occurs whether logged in or not, so I'm pretty sure it's not a matter of skin choice. The only difference I see when when I'm logged in is that the lock icons for secure links show up but the icon for standard external links does not. When I'm not logged in, neither of them show up. — Sctechlaw (talk) 18:15, 2 February 2013 (UTC)

Article and talk page are different

The article Heritage Auctions' talk page is at Talk:Heritage Auction Galleries. The article and talk page were moved in 2009, and for some reason Cluebot reverted the move of the talk page. I haven't been able to figure out how to move articles over redirects, and I'm not sure what to do since the talk page doesn't match the article. Can someone fix this? Ryan Vesey 13:45, 30 January 2013 (UTC)

Fixed, I just used the normal move process. Werieth (talk) 14:01, 30 January 2013 (UTC)

Double click to edit not working

I have always used double click to edit, but it has stopped working (XP, IE8, Vector).
I first noticed it a couple of days ago and assumed it was a temporary glitch, but it is still not working. Yes I have purged, and rebooted, and I haven't touched my JavaScript, whilst other things relying on Java - such as the edit toolbar - are still working.
Arjayay (talk) 18:44, 30 January 2013 (UTC)

It was working a few minutes ago - came to this page to report this, double click and.... It's not working again. - Arjayay (talk) 09:13, 31 January 2013 (UTC)

In my case it’s the right-click on section titles that isn’t working; I’ve resorted to turning the “[edit]” links back on in Preferences.—Odysseus1479 (talk) 03:59, 31 January 2013 (UTC)

How much does Pending Changes slow down load-times?

The load times on Deaths in 2013 are excessively long, and editors have even converted all of the references to the basic <ref> </ref> format, to avoid the delays from using citation templates, but this has not sped things up very much. How much of this extreme slowness is down to the use of Wikipedia:Pending changes, rather than semi-protection?
Arjayay (talk) 18:56, 30 January 2013 (UTC)

The preview and purge times are about the same (logged in and out), so it's not slowing the page down really. Aaron Schulz 20:27, 30 January 2013 (UTC)

Thanks - It has always been a slow page, but is now particularly slow, despite attempts to speed thinsg up. - Arjayay (talk) 08:59, 31 January 2013 (UTC)

You can also try adding ?forceprofile=true to URLs (not POST requests though) and clicking "view source" to look for any intersting profiling data. Aaron Schulz 23:35, 1 February 2013 (UTC)

Repeating table headers for long tables

A reader 2013012910008948 notes that the tables in Comparison of e-book readers are quite long. When one scrolls down, one can no longer read the headers.

If the table were not sortable, it might be straightforward, though tedious, to include headers in several places, but that won't work well with a sortable table. Many spreadsheets have the ability to freeze the top row, so they remain on screen while you scroll down, but I'm not aware that Wikipedia's table rendering can do that.

For some long tables such as List of Manchester United F.C. players, this feature might not be needed, because after looking at the headers once, you can understand the meaning of each rows' entries even after the header is scrolled off the screen. However, in the case of Comparison of e-book readers, that isn't as easy to do, so it would be nice if there were some way to repeat the header or freeze it.

Does anyone have any thought on how to improve these tables?

(I did a search on table headers, but I didn't find that this has been discussed.)--SPhilbrick(Talk) 19:28, 30 January 2013 (UTC)

Hi Sphilbrick, I'd be curious if something is available technically, but that wouldn't be the way I'd go with that particular table. I'd probably instead break up that one huge table into several smaller sub-tables, each with their own header. Find some logical thing to use to partition that big table off into smaller tables.... would a reader really need to compare all of those rows together like that? Zad68 19:38, 30 January 2013 (UTC)

I think this is the same issue discussed some time ago at Wikipedia:Village pump (technical)/Archive 103#Was my intermediate-header issue addressed?... --Redrose64 (talk) 19:36, 30 January 2013 (UTC)

Template:Units

Hi, Template:Units badly needs a usage section with available unit abbreviations, and examples. Thanks --Taranet (talk) 23:07, 30 January 2013 (UTC)

Probably better to use Template:Infobox unit. -- WOSlinker (talk) 23:16, 30 January 2013 (UTC)

I've created a doc page, with a blank template. It's a nasty infobox; none of the parameters are optional. For future ref, requests like this are best sent to WT:Infobox. --Redrose64 (talk) 09:59, 31 January 2013 (UTC)

T:Units should probably be TFDd. --Izno (talk) 13:54, 31 January 2013 (UTC)

Edit needed at Special:Log/newusers

We've been discussing how to better communicate to users about reporting usernames at WT:UAA. It has come up that the new users log page is one of the places where the message does not quite jive with best practices. How does one edit a page like that? Beeblebrox (talk) 23:31, 30 January 2013 (UTC)

By editing MediaWiki:Newuserlogpagetext. Someguy1221 (talk) 23:33, 30 January 2013 (UTC)

Awesome, thank you. For future reference, how is it that you even figured that out? There's no clue when viewing the page. Beeblebrox (talk) 23:50, 30 January 2013 (UTC)

[10]. The third gadget under the "Advanced" header in your preferences' Gadgets tab gives you a link to do this automatically. Ucucha (talk) 00:07, 31 January 2013 (UTC)

Cool, thanks. Beeblebrox (talk) 00:29, 31 January 2013 (UTC)

Messed up dates on mobile

Last night the birthdays in infoboxes on my phone started to be messed up. For example Al Gore shows:

(1948-03-31) March 31,1948 (age 64)

which is really annoying to have the numbers as well as the date. When I view a mobile page on my computer though there is no problem. How do I fix it? CTF83! 23:57, 30 January 2013 (UTC)

{{birth date and age|mf=yes|1948|3|31}} generates this in order to be sortable by birth date when it's used in a table column:

<span style="display:none"> (<span class="bday">1948-03-31</span>) </span>March 31, 1948<span class="noprint ForceAgeToShow"> (age 64)</span>

Text in <span style="display:none">...</span> is not supposed to be displayed but apparently your phone doesn't know this. I don't know how to fix it on your phone. It has been used in the template since 2007.[11] Did you change something in the phone software recently? I suppose we could add an optional template parameter to say "Don't generate a hidden sortable date", but I'm not sure we should cater to issues like this if it isn't widespread. PrimeHunter (talk) 02:00, 31 January 2013 (UTC)

If the text is not needed, the template should not generate it. Throwing in extra text, even if it's marked display:none, will slow down page load and confuse search engines, Dillo users, and anyone when the site CSS fails to load. The real solution here would be to turn the extra content generation off by default and add a parameter to {{birth date and age}} to re-enable it. —Remember the dot ^(talk) 02:09, 31 January 2013 (UTC)

No, I haven't changed anything, that's what caused my perplexity, I thought it was vandalisim. CTF83! 04:11, 31 January 2013 (UTC)

That won't work either. The MobileFrontEnd extension strips all inline CSS, so any mechanism for hiding/unhiding certain parts will fail on mobile. This affects nearly every template, and IMO was a bad design decision for MobileFrontEnd. — Edokter (talk) — 09:55, 31 January 2013 (UTC)

da hell?

Hey, look at Parenthood (2010 TV series)#Braverman family tree Right below the tree the string "Or is it?" appears, but I can't find that string anywhere in the source of the article or the template. What gives? Herostratus (talk) 02:12, 31 January 2013 (UTC)

It disappeared when I purged the page so I guess it was caused by a template which has been fixed. PrimeHunter (talk) 02:20, 31 January 2013 (UTC)

Huh, OK, thanks. Herostratus (talk) 03:57, 31 January 2013 (UTC)

I was wrong. The page history shows it was in the article source but removed 27 January.[12] The old version must have been displayed, probably related to #Users reporting site time issues and delay in visible update of edits. PrimeHunter (talk) 10:57, 31 January 2013 (UTC)

Weird image issue...

When I try to move File:USS_Admiral_W._L._Capps_(AP-121).jpg to Commons, I get a NoScript cross-site scripting warning, and there's a space before the ".jpg" in the CommonsHelper boxes. Also when I click through to Commons from File:USS Admiral R. E. Coontz AP-122.jpg and File:USNS General Daniel I. Sultan T-AP-120.jpg, I get the space before the ".jpg", the cross-site scripting warning, and a "this file doesn't exist" Commons page? - The Bushranger _{One ping only} 04:44, 31 January 2013 (UTC)

• Also File:USNS General Edwin D. Patrick (T-AP-124).jpg and File:USS Admiral E.W.Eberle (AP-123).jpg. I was able to move File:USS Admiral Hugh Rodman (AP-126).jpg to Commons without a problem though. Perhaps it's the presence of a period in the filename before the .jpg? - The Bushranger _{One ping only} 04:50, 31 January 2013 (UTC)
  • Fairly certain it's the presence of a period in the filename (or perhaps period-and-space), as File:USS Admiral W. S. Sims (AP-127).jpg displayed the same aberrant behavior. - The Bushranger _{One ping only} 04:51, 31 January 2013 (UTC)

Asynchronous uploads/api usage

Tracked in Phabricator
Task T46584

Can bots do asynchronous requests to the wikipedia api? For example several uploads simultaneously through the commons api or is this frowned upon? Would there be a performance benefit? I have a 100 Mbit/s line and so I'd like to know if doing simultaneous uploads would be worthwhile. Smallman12q (talk) 22:04, 31 January 2013 (UTC)

Yes, it should be fine if you don't use too many threads (I'd stop at three). Are you able to saturate the connection with only one thread? MER-C 08:30, 1 February 2013 (UTC)

Heyyy! Don't give people advices for following which they might get hardblocked by IP. The official policy states it clearly: one request at a time. Max Semenik (talk) 12:46, 1 February 2013 (UTC)

Huh? That page doesn't look like a policy -- the sole author does not seem to be listed here (in fact, the author is banned on en.wp). Almost nothing links to that page; if it is policy you really should publicise it more. I searched wikitech, and CPUs have come a long way since this was posted nearly six years ago. MER-C 14:00, 1 February 2013 (UTC)

I've filed bugzilla:44584 for guidance...there should an official policy. @MER-C, I'm not able to saturate the line with only one thread. (The line is part of a wider shared line, but I'm guaranteed that minimum).Smallman12q (talk) 15:09, 1 February 2013 (UTC)

Refs

Someday I hope we won't have to manually include the references/notes section(s) at the bottom of articles, and that sfn will look like: {{sfn|isbn=|p=|some text}} or {{sfn|doi=|p=|some text}} that will produce what the harvnb/citation combo does today.

While I'm wishing, it would be cool for wp to put the refs/notes/see/external stuff on a separate tab automatically, and move cites out of the notes and not require editors to deal with organizing any of that nor ordinary readers to have it lard up their articles with it.

Obviously, if this conversation belongs elsewhere, I'd appreciate a tip!

Cheers. Lfstevens (talk) 01:37, 1 February 2013 (UTC)

Today's article for improvement and the main page

The development for TAFI has progressed significantly over the last few weeks, and we are preparing to launch the new feature on the main page when it can be properly implemented (target date Feb 9th at 0:00 UTC, but subject to change). Concensus was established that the TAFI content should be placed below the DYK content. A key part of this is the concensus to display one of a group of several articles (7 at this time), shown randomly. One implementation of this can be seen on the example page. It requires the user manually click the purge button, and I do not know if there is another way to do this sort of thing.

As far executing this implementation on the Main Page, one editor suggested that "the simplest approach is to use a new set of seven dated subpages each week (which can be created and prepared as far in advance as desired). When the date arrives, the update will occur automatically." Being more accustomed to my work in the textile industry, I have no clue when it comes to these matters. From what I gather, items to appear on the Main Page first go through Wikipedia:Main Page/Tomorrow, and this can be used to transclude the relevant article blurbs to the page. I am looking for assistance from technically minded individuals that can help in implementing this on the Main Page. --NickPenguin_(contribs) 01:58, 1 February 2013 (UTC)

In general, I think the whole project would benefit from some technically inclined people, we need some assistance on the backend. See the talk page for more details. --NickPenguin_(contribs) 03:49, 1 February 2013 (UTC)

There is no way that consensus is sufficient to modify the main page. Without feedback from hundreds of editors, the main page should not be touched. There needs to be a discussion linked form the watchlist notice, in addition to CENT and the other usual pages, before you can do this. Prodego ^talk 04:19, 1 February 2013 (UTC)

I believe we did go an RfC, which was also at CENT and other places, though I am not sure anybody mentioned going through the Watchlist notice. The proposal was passed by consensus at the Village Pump(Proposals), which I believe is the page where any such proposal is to be passed.

In any case, is there something else that we ought to be doing before TAFI can make it to the Main Page? If so, what? [Just a casual count revealed 50+ editors voting on the original proposal] TheOriginalSoni (talk) 07:27, 1 February 2013 (UTC)

There most definitely was an RFC, and actually the second posting is still up at CENT right now, seeking wider input. --NickPenguin_(contribs) 14:00, 1 February 2013 (UTC)

I think there should be a final poll, with the format decided, and then that linked from the watchlist notice. Prodego ^talk 06:04, 2 February 2013 (UTC)

Include (default not checked) case-sensitive option when WP:SALTing pages

Include a checkbox to have a SALT article creation protection be case sensitive or not. The option would say "Case-sensitive" and it would not be checked by default. This is useful in situations where multiple users may create differently capitalized article names to get around the protection. However, a SALT might need to be case-sensitive in some situations as well, so that's why it's an option. I believe this would be relatively easy to implement; simply adding a .lowercase() on both the filters and the article name being checked, and then comparing them, would do the trick. Vacation9 04:07, 1 February 2013 (UTC)

This is nigh impossible to do. However, the same effect can also be achieved via the title blacklist. Prodego ^talk 04:11, 1 February 2013 (UTC)

Why is it impossible to do? If the change is made to MediaWiki it isn't. This is a feature that with no doubt would be extremely useful across all wikis. The majority of salted pages should be not case sensitive anyway. Vacation9 04:13, 1 February 2013 (UTC)

Page protection is a per page setting, and a property of the page. There is no more relation between Example and ExAmple, then between any other page. You would have to check the database for every page with every case permutation individually (perhaps there is some way to do case insensitive LIKE in SQL, in which case it isn't too bad), and then query the properties of completely different pages to see if any are protected, and if this option is set. That's no good, especially to duplicate existing functionality. Prodego ^talk 04:23, 1 February 2013 (UTC)

Maybe it would be a difficult, but I don't think it's duplicate functionality persay; we're talking about thousands of pages that people who might not be familiar with Regexes would need to add to the title blacklist. I see your point though. Vacation9 04:31, 1 February 2013 (UTC)

What page do I edit to update this template's documentation?

I'm looking at the documentation for Template:Uw-unsourced3. At the bottom there's a little table that shows the different warning levels available. For Template:Uw-unsourcedn where n in [1, 2, 3] it says incorrectly that Template:Uw-unsourced4 is N/A. There actually is a Template:Uw-unsourced4. I want to update the documentation to fix this, but I cannot figure out what page I need to edit to do it! Note Please, I'm looking for someone to tell me how to figure it out so I can learn, I'm not asking to have it done for me! Help appreciated, cheers... Zad68 16:21, 1 February 2013 (UTC)

It uses a centralised doc page. Before altering that, I suggest that you discuss the matter at Wikipedia talk:WikiProject user warnings because the omission may be deliberate. --Redrose64 (talk) 16:46, 1 February 2013 (UTC)

(edit conflict) I’m not going to do it myself since you asked. If you view the source of the template, you’ll see that the documentation comes from {{Templatesnotice|series = uw-unsourced|max = 3|s1 = uw-unsor3}}. A bit of common sense confirmed by experiment shows that raising the max parameter to 4 does the job.—Emil J. 16:58, 1 February 2013 (UTC)

problem opening wikipedia

my browser (explorer 8) on my pc (windows XP SP2) makes me see every site normally,except wikipedia. The issue occurred yesterday and it seems not solved yet. your site appears to be running,but is extremely slow and often can't load photos or heavy pages. it seems strange,as a few days ago it was going wonderfully. — Preceding unsigned comment added by 87.21.32.151 (talk) 17:49, 1 February 2013 (UTC)

Same here, but my browser is Google Chrome. Someone should fix this problem ASAP. — Preceding unsigned comment added by 77.30.151.22 (talk) 18:06, 2 February 2013 (UTC)

thanks a lot for answering. not fixed yet,and it seems getting worse. could it depend on the new signal enhancer I bought to improve the wi-fi signal? I thought about it as the sole action I made in these days,but wikipedia is the only site affected. other sites are ok. if it helps the problem occurred in Italy.

New feature: guided tours

I've been writing a lot about this lately, so I am going to be brief, but I just wanted to give folks a heads up about the first, preliminary release of a new feature from the editor engagement experiments team: interactive guided tours. You can read more about this in the following places...

• Help:Guided tours - a very basic page I could use help expanding
• Our blog post about the launch
• MediaWiki.org documentation, including guidelines for designing a tour, if you're technically inclined

We're only using this feature in a couple experimental places right now, but it has a lot of potential to do good, if used carefully. Please let me know if you have any questions, especially about creating tours. Me and the developers on the team would be happy to walk you through the process. Steven Walling (WMF) • talk 18:21, 1 February 2013 (UTC)

File redirects broken

File:Army flag.gif was renamed to File:Flag of the United States Army (1775).gif on commons but it seems to have broken something as the file no longer displays, I have also tried creating the local page as a redirect and it too isnt working. Werieth (talk) 18:44, 1 February 2013 (UTC)

I've created a blank page at the target so the redirect page works, but the file still doesn't display. Peter James (talk) 19:10, 1 February 2013 (UTC)

I think it's because you created the redirect on Wikipedia. If the image is on Commons, I believe that the redirect must be on Commons too. --Redrose64 (talk) 19:15, 1 February 2013 (UTC)

Works perfectly after I deleted unnecessary pages. Ruslik_Zero 19:30, 1 February 2013 (UTC)

All I am getting is a missing file display:

Werieth (talk) 19:32, 1 February 2013 (UTC)

I also see a red link. I'm in Denmark, Europe. The file display also fails for me with a red link at commons:User:PrimeHunter/sandbox, but a wikilink to the file is blue and works. PrimeHunter (talk) 19:54, 1 February 2013 (UTC)

I have tested three other recently moved Commons files at commons:User:PrimeHunter/sandbox. All three fail in the same way so I guess file moving is currently broken at Commons. A file moved longer ago had no problems. PrimeHunter (talk) 20:14, 1 February 2013 (UTC)

• Can someone file a bugzilla ticket? Werieth (talk) 20:53, 1 February 2013 (UTC)

I've reported the same issue at WP:Help desk § ArmyFlagAlanM1201302012249Z. It seems, after the edit request for {{Country data USA}} was performed, there remain 53 articles that link to the old file. ImageRemovalBot (incorrectly) removed the links (instead of moving them) from 23 other files. —[AlanM1(talk)]— 23:09, 1 February 2013 (UTC)

I guess ImageRemovalBot got the same false message as us that the file doesn't exist, and the bot reacted like it's supposed to react for files that don't exist: Remove them. PrimeHunter (talk) 02:34, 2 February 2013 (UTC)

CommonsDelinker replaced Army flag.gif above with the new name as well. This caused the image to display correctly. I've undone the bot here, since that is supposed to be an example of using the redirect, not using the new name directly. – PartTimeGnome (talk | contribs) 15:31, 2 February 2013 (UTC)

This is strange... After undoing the bot, the image redirect displays correctly now, even though it used to be a red link for me. Even if I look at an older version of this thread that didn't work before, I see the image correctly. It might have been a caching issue of some sort. – PartTimeGnome (talk | contribs) 15:39, 2 February 2013 (UTC)

It appears to vary which of the file redirects are working. Army flag.gif also works for me now, both here and at commons:User:PrimeHunter/sandbox, but the three other examples still don't work. I tried to track down when the problem started by previewing Commons files moved at different times yesterday, but I couldn't come to a conclusion because it sometimes varied between previews whether a given redirect worked. PrimeHunter (talk) 16:12, 2 February 2013 (UTC)

All examples worked now after the page was purged. PrimeHunter (talk) 18:59, 2 February 2013 (UTC)

Help creating template for fractions

Hello CSS/Wikimarkup experts,

I would like to create a general template to display inline calculations or simple formulas, e.g. 9 \times 103 \times 4. Template:frac and Template:fraction don't put the numerator above the denominator. I know I can use the LaTeX math feature, such as used in Template:DentalFormula here, but

1. The font does not match the normal text font face and size.
2. It doesn't resize correctly when I resize the text.

I've experimented with some CSS to produce this:

9 × 10

3 × 4

(although I wrote the raw HTML here, it will be transcluded from a template). This works on my Firefox 18 browser, as long as I wrap the entire paragraph in a div (as is done here).

If not, the p tag closes, the table is displayed as a separate block:

9 × 10

3 × 4

, then the rest of the text appears in a separate p tag.

Is there a way to avoid that? Or is there another way to inline such fractions?

Thanks, cmɢʟee୯ ͡° ̮د ͡° ੭ 20:46, 1 February 2013 (UTC)

The simple answer is: use the math/LaTeX markup. It is rubbish right now as you rightly point out, but if you use some crazy HTML/CSS-based solution for some formulas but not others, then fixes made to the math/LaTeX extension in future (e.g. install MathJax, anyone?) won’t apply to your fancy template. — Timwi (talk) 20:50, 1 February 2013 (UTC)

Aha! Turns out MathJax is actually supported, but you have to rummage through the preferences first and find a well-hidden option. Go to Preferences, Appearance, and then at the bottom choose MathJax. — Timwi (talk)

{{sfrac}} is what you want: 9 × 10/3 × 4 — Edokter (talk) — 22:26, 1 February 2013 (UTC)

Many thanks! {{sfrac}} is exactly what I need (and more!) cmɢʟee୯ ͡° ̮د ͡° ੭ 12:25, 2 February 2013 (UTC)

These templates do not display correctly in pdf files because apparently our pdf creator knows nothing about 'inline-block' display option. Ruslik_Zero 16:28, 2 February 2013 (UTC)

There are many templates that have this problem. That doesn't mean they should be excluded from use. These templates use ordinairy HTML/CSS, which any PDF converter should be able to handle. — Edokter (talk) — 18:34, 2 February 2013 (UTC)

PDF rendering problem - same as another report, or different?

An email received by Wikimedia noted a problem rendering an article as PDF. The article is House of Medici

I tried it myself, and thought it was successful, but when I open the file, it reads:

WARNING: Article could not be rendered - outputting plain text. Potential causes of the problem are: (a) a bug in the pdf-writer software (b) problematic Mediawiki markup (c) table is too wide

I do see bug in rendering page as PDF. That note a bug identified, and marked as fixed, although when I go to the bug report, it appears to be fixed, but not yet deployed.

I would like to point the reader to this discussion.

I hope someone can identify whether:

• The problem with House of Medici is the same as in the bug_in_rendering_page_as_PDF, and is not yet fixed (from the stand-point of the reader) but is expected to be deployed at some time in the future, or
• The problem with this file is known, and there is a work-around, or
• this problem is new, and needs to be reported, or
• there is some other way to generate the pdf--SPhilbrick(Talk) 21:37, 1 February 2013 (UTC)

Can someone check this on an iPhone?

List of names of the Seven Dwarves has an EL to [13]. This looks fine to me but I've got an OTRS ticket 2013012910001212 and I'm told that on an iPhone, using Safari, this has very graphic images. Thanks. Dougweller (talk) 21:54, 1 February 2013 (UTC)

I can confirm that the page has been hijacked. Werieth (talk) 22:00, 1 February 2013 (UTC)

I've accessed it on my Windows Phone 7.5, and it redirects me twice, to some sites that on first look seem to be either sex/dating/pornography sites. Based on this, and the comments above, I've removed the link. Even though it's the only reference, I'm sure someone can find a more reliable source. Thank you for bringing this to our attention. gwickwire^talk_edits 23:48, 1 February 2013 (UTC)

Doing some investigation I discovered that http://resources.infolinks.com/js/infolinks_main.js is an included javascript and that it is the source of the hijacking. Werieth (talk) 03:09, 2 February 2013 (UTC)

Looks like that to me as well. I'll see what I can do regarding that JS on other links on Wikipedia. gwickwire^talk_edits 03:18, 2 February 2013 (UTC)

Thanks everyone. I've written to infolinks. Dougweller (talk) 06:48, 2 February 2013 (UTC)

Messed-up block message

Tracked in Phabricator
Task T27592

Seeing that User:Darkness Shines has retired, I was curious to see when he started editing, so I went to Special:Contributions/Darkness Shines and told it to show his earliest contributions. To my surprise, the block log changed: instead of displaying his current one-week block, it displayed the following block message:

02:23, 5 January 2012 Magog the Ogre (talk | contribs | block) blocked Darkness Shines (talk | contribs) (account creation blocked) with an expiry time of 24 hours (Edit warring: Taliban)

What's going on with the log? And is it something that needs work, or should it be forgotten? This reminds me of seeing reports in the past of people who were recorded as being blocked even though their blocks had expired. IE8/Windows 7/Monobook, though that's probably irrelevant. Nyttend (talk) 00:54, 2 February 2013 (UTC)

In addition, this page seems to indicate that he is not blocked.--Gilderien Chat|List of good deeds 01:04, 2 February 2013 (UTC)

Everything seems to be functioning fine for me except for one of the blocks I made today (The system thinks that Saturday is a specific date on 1970 but when changing the block, the expiry was correct). @Gilderien, if you remove the underscore, the block is displayed. Elockid ^(Talk) 01:07, 2 February 2013 (UTC)

Ah ok thank you. I didn't think it mattered whether an underscore was in the place of a space, and that is how it appeared using the User/Page information drop-down gadget.--Gilderien Chat|List of good deeds 01:14, 2 February 2013 (UTC)

I saw nothing odd when I made the block...I even missed his meltdown --(✉→BWilkins←✎) 01:42, 2 February 2013 (UTC)

It's exactly what you pointed out: when you click to show the earliest contributions, it also changes the block log extract to display the earliest block instead of the most recent. I'm sick of seeing this bug, why hasn't anyone fixed it already? Anomie⚔ 02:28, 2 February 2013 (UTC)

Ambiguous contributions link

I know this has been discussed before, (here), but I'm getting sick to death of the ambiguous "contributions" link in my sidebar in classic skin. I repeatedly find myself clicking it when I want to check another user's contributions, and seeing my own instead. I thought I'd get used to it in time, but it's not happening. I never used to do this when it was "my contributions", so it's just the ambiguity that's throwing me. When this was raised before, someone came up with a css tweak, which I've tried in my common.css page, but it doesn't work in classic skin. Any suggestions?  An optimist on the run! 07:46, 2 February 2013 (UTC)

The following CSS should work for the Classic skin:

#quickbar a[title="Special:Contributions"] {
  content: "My contributions";
}

It's probably best to put this in your standard.css file rather than common.css, since the above only works with Classic. – PartTimeGnome (talk | contribs) 15:21, 2 February 2013 (UTC)

That doesn't seem to work for me :-(   An optimist on the run! 15:34, 2 February 2013 (UTC)

Try this:

#quickbar a[title="Special:Contributions"]:before {content: "My "}

Worked in vector and monobook classic for me. (I think the CSS property "content" can only be used with a :before or :after selector.) Writ Keeper ⚇♔ 15:51, 2 February 2013 (UTC)

My code works in Opera 12, but it is possible that Writ Keeper is right with regards to using content: in other browsers. (Edit: Writ Keeper updated his comment before I saved, so the following mention of #pt-mycontris makes no sense now.) #pt-mycontris is specific to Vector though, so won't work with Classic. Below is a combination of both of our CSS that might work:

#quickbar a[title="Special:Contributions"]:before { content: "My " }

It's also possible that your browser doesn't like the title= selector I am using (I know it doesn't work in IE6; it should work in later versions of IE). If that is the case, I can't think of anything else to try, since Classic is rather lacking in the IDs and classes I would use in other skins. – PartTimeGnome (talk | contribs) 16:01, 2 February 2013 (UTC)

That fixes it - thanks (I'm using Firefox).  An optimist on the run! 16:04, 2 February 2013 (UTC)

Possible bug?

[14]

Clicking on previous version gives me a version in 2010!Curb Chain (talk) 09:48, 2 February 2013 (UTC)

What were you expecting? Legoktm (talk) 09:57, 2 February 2013 (UTC)

The previous/next version links go to the revision of the article with the previous/next revision ID number, not the previous/next revision by timestamp. Because I imported that July 2001 revision into the Wikipedia database from the Nostalgia Wikipedia in May 2010, the July 2001 edit has a revision ID number typical of edits from May 2010. This problem is tracked in Bugzilla as bug 2930. Graham87 10:53, 2 February 2013 (UTC)

"RFC" autolinks

Has something changed recently such that the letters "RFC" followed by a number will automatically link to ietf RFCs? For example, here under the Computing section. I hadn't noticed this behavior before. older ≠ wiser 17:50, 2 February 2013 (UTC)

It's been set up this way for a while, in the same way as ISBN autolinking. I'm not sure how long it's been enabled, but I believe several years. Andrew Gray (talk) 18:10, 2 February 2013 (UTC)

Seems a little odd, as "RFC" is used in other contexts other than ietf. older ≠ wiser 18:22, 2 February 2013 (UTC)

RFC "magic links" have been a MediaWiki feature since 2004. Documented at Help:Magic#RFC, Help:Link#ISBN, RFC and PMID automatic links and mw:Manual:RFC. The decision to implement special links for RFCs probably reflects the greater significance that IETF and RFCs had at that time among typical internet users and Wikipedia editors. — Richardguk (talk) 18:53, 2 February 2013 (UTC)

your edit saved

how to enable this message "your edit saved" after having edited any page in another wiki e.g. urdu wiki? محمد شعیب (talk) 17:54, 2 February 2013 (UTC)

The feature is called "Post-edit feedback", and, once the target (e.g. Urdu) community had agreed upon its installation, take that request to //bugzilla.wikimedia.org . I'm sure it's not too difficult to configure, though localisation work might be required. - Jarry1250 ^{[Deliberation needed]} 17:58, 2 February 2013 (UTC)

thanks for quick reply and help :) محمد شعیب (talk) 18:05, 2 February 2013 (UTC)

Template problem

Hi, the {{Coastal settlements}} template was modified in early December and the link to the category appears not to be working. I cannot see what the problem is, may be you cannot substitute in the parameter as it is trying to do. Can anyone fix-it? Keith D (talk) 18:13, 2 February 2013 (UTC)

AFAICT it's the just the presence of curly brackets that break it i.e. it's just the documentation usage that's broken. Or was that what you meant? - Jarry1250 ^{[Deliberation needed]} 19:04, 2 February 2013 (UTC)

Template seems to be working fine. Do you have a link where the problem is apparent? — Edokter (talk) — 19:14, 2 February 2013 (UTC)

The problem shows on Tunstall, East Riding of Yorkshire. Keith D (talk) 20:20, 2 February 2013 (UTC)

The documentation for the place parameter says "DO NOT WIKILINK". Are there problems on pages without wikilinks? PrimeHunter (talk) 20:26, 2 February 2013 (UTC)

(edit conflict) As presently coded, {{Coastal settlements}} expects |place= to contain plain text without wikimarkup, because it applies wikimarkup to that text. At Tunstall, East Riding of Yorkshire, there is |place=the [[East Riding of Yorkshire]] - you are getting a page link inside a category link, which is forbidden - the only links which may contain other links are file links, where the caption text may be wikilinked. --Redrose64 (talk) 20:29, 2 February 2013 (UTC)

Thanks for that, I thought that previously it had been working OK but may be I was mistaken. Keith D (talk) 22:00, 2 February 2013 (UTC)

Rate vs. Help

Raymarcbadz (talk · contribs) has a curious habit: if he creates a page and it comes up with an "help improve this page" box at the bottom, he requests its deletion and re-creates it so that a "rate this page" box will appear instead. See this dialogue headed "articles for deletion". We have told him that his behaviour is obsessive but for my own interest can someone please tell me what determines which box comes up. Is it possible to change the box or suppress it altogether? — RHaworth (talk · contribs) 22:21, 2 February 2013 (UTC)

Billboard ID

Due to a site revamp, I'm having to rework {{singlechart}} and {{albumchart}}. The core of the problem is that to reference a Billboard chart for an individual artist, you need to know a six digit magic number. Billboard just changed them all, and I'm having to figure out how to update thousands of hardcoded magic numbers. I've done the search, and now know that there are approximately 14,000 artists that have both a Wikipedia article and a Billboard chart. More like 1000 actually have an existing call to singlechart or albumchart.

The brute force way to fix things is just take my updated list of 14,000 artists and throw it into {{BillboardID}}. That way, I can ignore the artistids being passed in to the templates, look up the magic number based solely on artist name, and only have one place to update when the numbers get changed. I suspect that something, somewhere, something is going to break if I do that.

My first thought is to break it into submacros based on the first two characters of the artist name, so that BillboardID is just a big switch statement that calls BillboardIDAA, BillboardIDAE, BillboardIDAQ .... BillboardIDZZ. What I don't know is the way the templates actually get processed internally. If I did that, would I still wind up loading all 14,000 artists every time as the template expanded?

My second alternative is to set up a special website that redirects you to the appropriate chart based on a database lookup. I'm not eager to pay money to do it, and feel queasy about setting up a universal redirection service to someone else's website. That's why I'd really like to figure out a decent way to do it inside a template.—Kww(talk) 04:48, 3 February 2013 (UTC)