Misplaced Pages

Revision as of 06:45, 21 January 2013

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

• WP:VPT
• WP:VP/T
• WP:TECHPUMP
• WP:PUMPTECH

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.

view · edit Frequently asked questions (see also: Misplaced Pages:Technical FAQ) Click "" next to each point to see more details. If something looks wrong, purge the server's cache, then bypass your browser's cache. This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown. No, we will not use JavaScript to set focus on the search box. This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences. No, we will not add a spell-checker, or spell-checking bot. You can use a web browser such as Firefox, which has a spell checker. If you have problems making your fancy signature work, check Help:How to fix your signature. If you changed to another skin and cannot change back, use this link. Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem. If an image thumbnail is not showing, try purging its image description page. If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear. For server or network status, please see Wikimedia Status. If you cannot reach Misplaced Pages services, see Reporting a connectivity issue.

Village pumps

policy

tech

proposals

idea lab

WMF

misc

• Refining the administrator elections process
• Blocks for promotional activity outside of mainspace

• view
• edit
• history
• watch
• archive
• talk
• purge

noreferrer for Misplaced Pages

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Misplaced Pages technical issues and templates Misplaced Pages policies and guidelines When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Are there any plans to enable noreferrer on Misplaced Pages 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/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 Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages), 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 Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages as part of a common standard" makes it sound like Misplaced Pages 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 "Misplaced Pages 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 Misplaced Pages (erase the URL from where you came into Misplaced Pages) and in clicking on external links in Misplaced Pages (prevent the target site from learning the Misplaced Pages 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 Misplaced Pages, 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 Misplaced Pages. – 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)

noreferrer - Support

Misplaced Pages 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 15:21, 12 January 2013 (UTC)

  Misplaced Pages 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 Misplaced Pages, but he has since corrected this.) – PartTimeGnome (talk | contribs) 00:55, 13 January 2013 (UTC)

• Support - Misplaced Pages 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 Misplaced Pages, let alone a specific Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages ask browsers to not tell they came from Misplaced Pages. 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 Misplaced Pages, or the user's own browser doing stuff behind the user's back, is irrelevent. If Misplaced Pages 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 Misplaced Pages can ask browsers to not reveal that our users have visited a page on Misplaced Pages, 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. Misplaced Pages 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)

noreferrer - Oppose

Misplaced Pages 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 Misplaced Pages 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 Misplaced Pages). 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 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 Misplaced Pages (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· 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. Misplaced Pages 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 Misplaced Pages. This is important: one of the drivers of the growing academic respectability of Misplaced Pages is that people who run scholarly journals or online archives are seeing how much Misplaced Pages 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)

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 Misplaced Pages 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 Misplaced Pages'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 Misplaced Pages. 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/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 Misplaced Pages. --Guy Macon (talk) 06:58, 17 January 2013 (UTC)

Pending changes

Why does the pending changes add-in display "Accepted (latest)" - this is just noise, if there are no pending changes, it's like a normal page. Rich Farmbrough, 00:27, 13 January 2013 (UTC).

I'm not sure. Perhaps it is intended to explicitly tell readers (of course, editors are readers too), "Everything has been reviewed". However, I can see why you might think it's clutter. Superm401 - Talk 00:38, 13 January 2013 (UTC)

Sometimes the "accepted" version is in fact a bad version; this provides the means to both view the review log, and to un-accept the change. --Redrose64 (talk) 10:07, 13 January 2013 (UTC)

That applies to every page, pending change or not. Lugnuts 18:10, 16 January 2013 (UTC)

True: but where else might we find a link to the review log without going through Special:Log and filling in the form? It's not in the logs for the page. --Redrose64 (talk) 18:49, 16 January 2013 (UTC)

Show/hide links kicking me back to top of page

On Lance Armstrong, whenever I click "show" or "hide" in either the "medal records" section of the infobox or on "voided results" under the "Palmares" section, I get kicked all the way back to the top of the page, and my address bar shows that a # has been appended to the URL. This does not happen when opening or closing navboxes at the bottom of the page. Firefox 18.0, Vector, and Windows 8. jcgoble3 (talk) 23:16, 15 January 2013 (UTC)

Also happening for me on various pages such as this. Windows 7, IE9 and Chrome. James086 23:32, 15 January 2013 (UTC)

I have been having that problem with an outdated Firefox version (v11?) + Vector + Windows 7 on any show/hide link, and the same problem as Jcgoble3 for those specific show/hide links mentioned, in Firefox 18 + Vector + Windows 7. I don't expect a fix for the old version of Firefox, but it's probably the same problem. I can only assume this is related to the weekly rollout of a new version of software, but why were these affected? --Izno (talk) 01:21, 16 January 2013 (UTC)

Guessing that this is caused by this edit to MediaWiki:Common.js on 14 January 2013. I have asked about this at MediaWiki talk:Common.js#Fix href of NavToggle. — Richardguk (talk) 11:06, 16 January 2013 (UTC)

User:Anomie has just made an edit to MediaWiki:Common.js which should have fixed this. You might need to clear your cache to avoid a delay before your browser notices the revised javascript . — Richardguk (talk) 21:41, 16 January 2013 (UTC)

Category link is of no use

The actual "Category" link on all pages goes to Special:Categories. This page is of next to no use to readers, the bulk of our "clients". Can the MediaWiki software be changed so that it goes to Help:Categories? Help:Categories is a reader help page that is deliberately kept simple and not encumbered with project related stuff. If the MediaWiki software cannot be changed then Help:Categories should be in a prominent place on the Special:Categories page. -- Alan Liefting (talk - contribs) 08:11, 16 January 2013 (UTC)

The link is set by pagecategorieslink, which currently defaults to "Special:Categories". There used to be a customised enwiki link (deleted in 2008 with the log summary: "Now updated in MediaWiki defaults"). So the above proposal could easily be implemented on enwiki if editors support it. (Changing the link for all wikis would need a bugzilla request to edit the default value in languages/messages/MessagesEn.php.) — Richardguk (talk) 11:26, 16 January 2013 (UTC)

(e/c)That change could be accomplished by creating MediaWiki:Pagecategorieslink with the content Help:Categories. Help:Categories seems like a useful page - I agree with the suggestion. – Philosopher  11:33, 16 January 2013 (UTC)

Shall we be bold and have it done or should it be discussed? I think we should go for it (but I have to say that ). It can alway be undone if there are objections but I would be surprised if there will be any. -- Alan Liefting (talk - contribs) 20:12, 16 January 2013 (UTC)

I'd let it wait a few days for comments, since it's such a wide-ranging change. If no one objects in a few days, ping me (or another admin) and I'll make the change. – Philosopher  00:40, 17 January 2013 (UTC)

I should have notified the categorisation WP. I will do it now. -- Alan Liefting (talk - contribs) 02:52, 17 January 2013 (UTC)

Makes sense to me. Go for it. postdlf (talk) 04:43, 17 January 2013 (UTC)

• This seems like a great idea, full support from me. Ryan Vesey 05:05, 17 January 2013 (UTC)

What the heck is autochecked? (Round Two)

There have been several discussions recently about what exactly the 'autochecked' user rights group does. Special:ListGroupRights says Have one's own revisions automatically marked as "accepted" (autoreview), but it's unclear if this applies just to Pending Changes Level 1, or to Level 2 as well. In the previous discussions I was informed that its primary purpose was related to PC2, but I was a bit confused, namely by the fact that the phrasing would seem to imply that Autochecked wouldn't work on a PC2 article. And since I thought this could be relevant to the PC2 discussion over at AN, I thought it would be useful to figure out. So, I asked Prodego if he'd mind adding Autochecked to my alt account, User:FRC&AND. I made several test edits, two to Misplaced Pages:Pending changes/Testing/1 (PC1) and two to Misplaced Pages:Pending changes/Testing/4 (PC2). And, surprisingly, neither pair was automatically accepted (reviewing logs: ). So, umm, what's up with this? Is this some sort of bug, or does it have something to do with how we've configured PC, or did I just screw something up in testing this? — Francophonie&Androphilie 08:30, 16 January 2013 (UTC)

Before it went live back in December, I made quite a few test edits (both with and w/o reviewer) on the test pages. None of them worked the way they should have. I think the test pages are just very very buggy for some reason. Theoretically, the software doesn't differentiate between the autoreview right a reviewer has, and one a "autochecked" user has. So it's kind of like giving them the ability to edit PC2 pages without being able to review other edits, i.e. it may be useful for someone who's working on a PC2 page a lot and doesn't wish to flood #wikipedia-en-pc with their changes (or Special:PendingChanges). I think that it may help in the inevitable RfC on PC2 to get editors to agree with PC2, but not sure. Does that help a little bit? gwickwire_edits 18:43, 16 January 2013 (UTC)

Hmmm. It also occurs to me that this could be because the account isn't autoconfirmed. Would an admin mind confirming it? This would also allow me to try making a dummy edit to one of the PC2-protected articles, if it really just is that the sandboxes are buggy. (Though I obviously will only do that as a last resort, and in a way with no visible effect on the article.) — Francophonie&Androphilie 19:24, 16 January 2013 (UTC)

No problem, User:FRC&AND is now confirmed. James086 00:47, 17 January 2013 (UTC)

Portal Links

Hi. Can anyone see the extra space right side of portal links on this page? My browser is Google Chrome 25.0.1364.29. Is it a Chrome bug or a Misplaced Pages bug? –ebraminio 12:13, 16 January 2013 (UTC)

I see it too in Chrome. Chris857 (talk) 16:38, 16 January 2013 (UTC)

I'm not seeing it in Firefox 18.0. Probably a Chrome issue. jcgoble3 (talk) 19:10, 16 January 2013 (UTC)

No issue for me. Though I'm on Chrome OS, which is always a few releases behind the PC/Mac versions. Are you on beta channel or stable channel, though? (Or *shudder* devoloper or *shudders more* canary?) — Francophonie&Androphilie 19:28, 16 January 2013 (UTC)

Yes, I think I see it.

There is no problem with just a single United States portal link.

The problem is with Indigenous peoples of North America, seems that title is long enough to cause it to wrap to a second line:

Chrome Version 24.0.1312.52 m —Wbm1058 (talk) 19:59, 16 January 2013 (UTC)

If you play with the undocumented |boxsize= parameter in the {{Portal}} template, you can eliminate the right side white space.

This seems to work: {{Portal|Indigenous peoples of North America|United States|boxsize=175}}

—Wbm1058 (talk) 20:26, 16 January 2013 (UTC)

When I look at this in Microsoft Internet Explorer, the first and last of the four portal boxes on the right appear identical to me. Not so in Chrome – Wbm1058 (talk) 20:59, 16 January 2013 (UTC)

Absolute max-width and width properties are not supposed to be specified together, so there might be a better solution than supplying a width via |boxsize=.

I think the problem is with the way Chrome applies the "max-width:175px;" style which {{Portal}} applies to the table containing the portal links, because the table is surrounded a div element of unspecified size.

One solution might be to move the max-width property from the table styling to the div styling in the previous line of the template code.

— Richardguk (talk) 21:31, 16 January 2013 (UTC)

I've filed a bug for it. Thanks –ebraminio 14:38, 17 January 2013 (UTC)

Brief read-only test on English Misplaced Pages in 25 minutes

In preparation for the migration to the Virginia datacenter, we're performing a brief (less than 5 min) read-only test of English Misplaced Pages. This is in anticipation of what could be longer read-only time next week as we're migrating. Apologies in advance for the inconveniece. -- RobLa-WMF (talk) 20:36, 16 January 2013 (UTC)

Just to make sure this is clear, 25 minutes from now Misplaced Pages will go into read only mode for 5 minutes. Then next week the Wikimedia servers are being moved and Misplaced Pages will be in read only mode at random times on the 22nd, 23rd, and 24th? Ryan Vesey 20:42, 16 January 2013 (UTC)

Yup, more or less. We're running a little bit behind for today's test (hence why I'm able to leave this comment). Next week, the migration starts in earnest at 9am PST on January 22nd. If we're extremely lucky, that goes smoothly and we're done in an hour (though we're planning on file storage work affecting images/media on January 23rd). This is a tough enough job that we're almost certainly not going to be lucky, though, so expect things to be bumpy. -- RobLa-WMF (talk) 21:07, 16 January 2013 (UTC)

might be a good idea to off (IOW, remove) the "edit" links on pages and sections, say, 10 minutes or so before the "read only" mode takes effect. this will reduce the number of people who will lose work because suddenly the "save" button does not work.

a site-notice will also help, i guess. peace - קיפודנחש (aka kipod) (talk) 21:31, 16 January 2013 (UTC)

PST? Can we please keep all timings in notifications such as this in UTC. Arjayay (talk) 19:13, 17 January 2013 (UTC)

For the record, 9am PST = 17:00 UTC. jcgoble3 (talk) 19:20, 17 January 2013 (UTC)

Uploaded file summary

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

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

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

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

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

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

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

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

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

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

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

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

Slowness, outages etc.

Yesterday was a bummer with incredible slowness and one brief outage. Today, it's not as slow as yesterday, but still slower than it should be on Saving. In checking the Signpost, this does not seem to be the target period for issues created by the primary data switchover. I'm thinking it's not just me. But is this going to improve soon? — Maile (talk) 16:22, 17 January 2013 (UTC)

Yes, it gets better. --MZMcBride (talk) 16:58, 17 January 2013 (UTC)

The brief outage (of editing facilities) was testing for the data switchover. See #Brief read-only test on English Misplaced Pages in 25 minutes above. – PartTimeGnome (talk | contribs) 22:10, 17 January 2013 (UTC)

Thanks for the explainer. — Maile (talk) 00:49, 18 January 2013 (UTC)

Could this have anything to do with why two images I updated on Commons, said updates becoming visible in WP File space almost immediately, are not being updated in an article? ~ J. Johnson (JJ) (talk) 22:33, 17 January 2013 (UTC)

Probably unrelated. Image thumbnails not updating has been a recurring problem for a while now. See also #clearing cache for images above. – PartTimeGnome (talk | contribs) 23:18, 17 January 2013 (UTC)

Thanks. ~ J. Johnson (JJ) (talk) 00:06, 18 January 2013 (UTC)

Number of page watchers tool deprecated

Hi. It's now possible to view the number of page watchers via the "info" action. For example, at <https://en.wikipedia.org/search/?title=Main_Page&action=info>, you can see that Main Page has over 76,500 page watchers. In the coming weeks, I'll be deprecating the watcher tool. --MZMcBride (talk) 17:00, 17 January 2013 (UTC)

How can we find and use the "info" action?—Wavelength (talk) 17:37, 19 January 2013 (UTC)

I was working on a new link in the left toolbar, but I now see that 'Page information' has been added. --— Gadget850 (Ed) 18:01, 19 January 2013 (UTC)

It's in the "toolbox" group. --Redrose64 (talk) 19:02, 19 January 2013 (UTC)

Thank you.—Wavelength (talk) 21:47, 19 January 2013 (UTC)

parser function admin

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

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

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

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

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

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

template editing - what tool?

Is there a tool used by template editors, to do things like syntax checking and highlighting? My eyes are crossing, from counting curly brakcets! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:34, 17 January 2013 (UTC)

Notepad++ can highlight matching brackets for you, which is a start. -- John of Reading (talk) 19:42, 17 January 2013 (UTC)

User:Ais523/bracketmatch.js and Preferences → Gadgets → Dot's syntax highlighter. --— Gadget850 (Ed) 20:21, 17 January 2013 (UTC)

Off-wiki, there are loads of text editors that support MediaWiki syntax. See Misplaced Pages:Text editor support. Steven Walling (WMF) • talk 20:31, 17 January 2013 (UTC)

CodeEditor, which is really just a wrapper for Ace (editor), may help one day. --MZMcBride (talk) 20:51, 17 January 2013 (UTC)

Scripted formatting not working on some pages

Many of the script-based formatting functions have suddenly stopped working for me. My watchlist looks as it does in a very old browser: all in plain text—sidebar & page-top links included—and multiple edits to the same page are all shown instead of being summarized with disclosure triangles as usual. My Preferences page doesn’t show the usual row of tabs at the top: everything appears in one long page. Collapsed content is displayed by default instead of being hidden. The widget that lets me preview pages by hovering over links (I forget its name) has also stopped working. I’ve tried quitting & relaunching my browser: no difference. The Edit page here looked normal when I started, but now that I’ve clicked “Show Preview” it also has lost the sidebar, backgrounds, and page-top links. Any suggestions as to what may have gone wrong?—Odysseus1479 (talk) 03:28, 18 January 2013 (UTC)

Try to clear your entire cache. PrimeHunter (talk) 03:53, 18 January 2013 (UTC)

I think this is the CSS failing to load. I got that a lot when I was with Talk Talk. Rich Farmbrough, 09:41, 18 January 2013 (UTC).

Redlink categories

Is there a tool that can easily locate articles with redlinked categories? I seem to see that a lot lately. Ten Pound Hammer • 03:39, 18 January 2013 (UTC)

Special:WantedCategories Werieth (talk) 03:42, 18 January 2013 (UTC)

Warning, I was arbcommed for creating redlinked categories. YMMV Rich Farmbrough, 09:38, 18 January 2013 (UTC).

I thought you were arbcommed because somebody noticed that in two consecutive edits you made exactly the same spelling correction to two different articles, which they construed as "making automated edits". --Redrose64 (talk) 11:41, 18 January 2013 (UTC)

See Misplaced Pages:Database reports/Categories categorized in red-linked categories

and Misplaced Pages:Database reports/Deleted red-linked categories

and Misplaced Pages:Database reports/Red-linked categories with incoming links.

—Wavelength (talk) 17:23, 18 January 2013 (UTC)

Chronosort what-links activity

Is there a way to sort pages linked by "what links here" in the order of date-time when the link was last added (to cover the case of multiple links) ? Any external tools? Shyamal (talk) 03:59, 18 January 2013 (UTC)

This would be relatively resource intensive, so I think you would need to request something from a toolserver user. I am not aware that any such tool exists right now. Rich Farmbrough, 10:26, 18 January 2013 (UTC).

I don't think it's possible. The information you're looking for isn't stored in the pagelinks table, at any rate. Graham87 12:34, 18 January 2013 (UTC)

I agree that it is resource intensive but it is more or less like the pagelinks table combined with a blame feature. Shyamal (talk) 14:10, 18 January 2013 (UTC)

Logged out

Over the last 48 hours I have been logged out about 8 times. Anything odd going on? Rich Farmbrough, 09:37, 18 January 2013 (UTC).

Also happening to me every few hours ·Add§hore· 19:50, 18 January 2013 (UTC)

Over the last few weeks, I've had it happen to me a few times. Hasn't happened lately, until today. Keeps kicking me out off and on. — Maile (talk) 00:29, 20 January 2013 (UTC)

Templates with “-“ in the name in diffs

The new diff web interface (since 1.20) works incorrectly with hyphens in the name of a template, as one can see at . Namely, it generates wrong /Template:-link and title. For “{{Box-drawing sample}}”, I get an HTML code:

<div><span class="diffchange diffchange-inline">
	<a href="//en.wikipedia.org/Template:Box"
	 style="text-decoration: none; color: inherit; color: expression(parentElement.currentStyle.color)"
	 title="Template:Box">{{Box</a></span>
	-<span class="diffchange diffchange-inline">drawing</span>
	 <span class="diffchange diffchange-inline">sample}}</span>
</div>

Should I post it to Bugzilla? Incnis Mrsi (talk) 10:03, 18 January 2013 (UTC)

I don't think thats a bug. It's comparing those hypens to the ones in <!--, hence no highlighting. Legoktm (talk) 10:54, 18 January 2013 (UTC)

What "no highlighting"? I said that it generates wrong href and title, did you read the post? Incnis Mrsi (talk) 11:00, 18 January 2013 (UTC)

I assume you're talking about the WikiEd diff viewer (which links templates), not the standard MediaWiki one (which does not). If so, this isn't the kind of thing which should be posted to Bugzilla. Instead, follow the bug report guide at User talk:Cacycle/wikEd - Kingpin (talk) 11:12, 18 January 2013 (UTC)

Thanks, I forgot that this feature is not a standard one. Incnis Mrsi (talk) 11:15, 18 January 2013 (UTC)

You also forgot your manners. There's no need to use excessive letter-spacing. It makes you look like a jackass. Sometimes we mis-read or overlook parts of a post. It's part of being human. Repeating yourself with emphasis is fine, just try to be nice about it. :-) (And, for what's worth, the title and href attributes you pasted above look fine to me. I don't doubt that there's a bug, I just think you didn't report the bug very well. ;-) --MZMcBride (talk) 03:51, 19 January 2013 (UTC)

keeping all interwiki bots away from an article

Lads, quick question, is there any way to prevent all interwiki bots from touching an article? Is there any tag or template or something that you can put in an article so that interwiki bots will leave it alone? Thanks very much, Azylber (talk) 11:30, 18 January 2013 (UTC)

{{nobots}} will do the trick. Legoktm (talk) 11:34, 18 January 2013 (UTC)

Hi Legoktm, thanks very much for your quick answer. I take it there's nothing specific for interwikis. But this will do! Cheers, Azylber (talk) 11:42, 18 January 2013 (UTC)

I think there is something specific for Pywikipediabots, which do most of the interwiki work. BUt it is useful to resolve the underlying issues with these cases. Last time I looked we had two or three articles where interwikis were a problem, prevented by {{Nobots}}, and they were all amenable to solution. Rich Farmbrough, 12:03, 18 January 2013 (UTC).

Aha. To block just interwiki bots, you can use {{nobots|interwiki}}. It was introduced by xqt in pyrev:10774. The documentation on the template should probably be updated. Legoktm (talk) 12:11, 18 January 2013 (UTC)

Cool. And one more little (albeit perhaps silly) question: is that template with the new "interwiki" parameter supported across all of Misplaced Pages? (i.e. across all languages) Azylber (talk) 12:45, 18 January 2013 (UTC)

Yes. All pywikipedia interwiki bots will support it unless the bot operator decides to override it. Legoktm (talk) 12:52, 18 January 2013 (UTC)

This also works for other scripts by its script name e.g. {{nobots|redirect}} for redirect bot etc.  @xqt 14:00, 18 January 2013 (UTC)

Hi lads, thanks a lot for all your useful answers! Azylber (talk) 11:30, 19 January 2013 (UTC)

By the way, this will become moot in a month when Wikidata comes into play. --Rschen7754 19:58, 18 January 2013 (UTC)

How is it going to deal with N to N relationships between a given pair of languages? Azylber (talk) 11:31, 19 January 2013 (UTC)

Actual image locations

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

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

Thanks! ·Add§hore· 17:37, 18 January 2013 (UTC)

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

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

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

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

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

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

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

Thanks everyone! ·Add§hore· 21:19, 18 January 2013 (UTC)

Green pop up from Commons

"Vote for your favorite picture in the Commons 2012 Picture of the Year contest" is a green banner pop up appear at the top of pages. Not good. It could so easily be taken as a virus. As you scroll down, that pop up stays and obscures text on the page. How do we disable that? — Maile (talk) 00:13, 19 January 2013 (UTC)

Also it seems to appear infront of certain page items and behind others. ·Add§hore· 00:15, 19 January 2013 (UTC)

Yeah, and if you want to go to Preferences or something on that line, it totally obscures it so you can't access your own settings. — Maile (talk) 00:16, 19 January 2013 (UTC)

Yes, it's blocking stuff on my pages also. Can we get rid of it?--Arxiloxos (talk) 00:18, 19 January 2013 (UTC)

How many redirects are there on en.wp?

As part of the various statistics I run over Misplaced Pages page view data (e.g., WP:5000), I've observed that for every 10-day table I produce, I have 80 million rows, where rows are "viewed items". I only process en.wp and exclude any items that contain a semicolon (which should limit things to article namespace). English Misplaced Pages only has about 4.5 million articles. I know that titles before redirection are included in this raw data, but I don't feel it can possibly account for the massive jump up to 80 million items. Thoughts? Thanks, West.andrew.g (talk) 04:24, 19 January 2013 (UTC)

5.7 million, give or take . Dragons flight (talk) 04:41, 19 January 2013 (UTC)

(ec) 5865826 ·Add§hore· 04:42, 19 January 2013 (UTC)

There are many articles that have a ":" in their titles. If you are using the same summary data I used then you have a sufficiency of page names, times 10 days. You will also have a serious number of double escaped wrongly escaped and other cruft in there (I cleaned most of this up but I wonder if that actually is good methodology). Not to mention any attempts to access deleted pages or deleted redirects, or otherwise non-existent pages (by URL of course). Rich Farmbrough, 06:27, 19 January 2013 (UTC).

Reflist citations in article talk pages

I've made some responses to other editor's comments on article talk pages in which I've attempted to cite sources the same way I would in the article itself. Unfortunately, upon saving those comments, the reflist template seems to appear and/or disappear in random locations, including in the middle of completely unrelated sections, which makes the talk page itself extremely confusing to view, which I assure you, is not my intent. Talk:Padmasambhava is probably the best example of this.

I know I must be doing something wrong here, but honestly have no idea what. I can't imagine there aren't already guidelines in place to handle source citations on article talk pages, but must admit: I haven't yet managed to find them. Any guidance would be very much appreciated.  :^) :^)

Thanks, ༺།།ༀ་ཨཱཿ་ཧཱུྃ།།འཚེར།།xeltifon།།སར་ཝ་མང་ག་ལམ།།༻  09:55, 19 January 2013 (UTC)

I can't see what is going on either but multiple reference lists in any page need delicate handling. See Template:Reflist#Multiple_uses and Help:Footnotes#Multiple_reference_lists. Why not try avoiding using footnote style at all but simply have bare URLs or a list of formatted references truly in line and not as a footnote? If you use some gadget to format your references, simply remove the <ref> and </ref> from each one before saving. Thincat (talk) 12:06, 19 January 2013 (UTC)

After the error about missing reflist was added, the message started appearing on talk pages and a lot of editors got upset, so we now suppress it on talk pages. The downside is that you can't see that someone added footnotes elsewhere without a reflist. As Thincat referenced, using multiple reflists can be tricky. Basically, you need {{reflist-talk|close}} to close each reflist. {{reflist-talk}} is just a variant of {{reflist}} for talk pages that adds a box to offset the refs. If you want to see the error messages, on a talk page, see Template:Broken ref#Showing cite errors on other pages. I refactored the page in question to fix the issues. --— Gadget850 (Ed) 13:15, 19 January 2013 (UTC)

Javascript redirects for Special:MyPage/skin.css or Special:MyPage/skin.js not working

Special:MyPage/skin.css and Special:MyPage/skin.js used to redirect to my appropriate skin file say Special:MyPage/vector.js. Now they take me to an error page saying "Looking for your skin file?" which says I might not have javascript enabled, I do. Is there something broken with the page? I'm using the latest google chrome on a mac.--Salix (talk): 10:18, 19 January 2013 (UTC)

Should be fixed now. A change in Common.js introduced some strict evals that caused false negatives. — Edokter (talk) — 11:19, 19 January 2013 (UTC)

Bigdelete restriction not working in page moves?

I recently moved a big page with many revisions (2008 South Ossetia war → Russia-Georgia war, 11,833 revisions, plus its talk page with 13,592 revisions, plus multiple talk archive pages). In doing so, I got a "bigdelete" error message ("You do not have permission to move this page, for the following reason: This page's edit history exceeds 5,000 revisions. To prevent accidental disruption, its deletion is restricted to stewards"), although the message didn't say which of the pages in question it referred to. It must have referred to one of those pages itself, as I'm pretty certain there wasn't such a big history on any of the target locations that had to be technically deleted to make way. But whatever it was, despite the warning, all the pages were in fact moved normally.

Questions:

1. Is it true that the "bigdelete" restriction of 5,000 revisions is meant to apply not just to deletions but also to moves?
2. How come I could still perform these actions, as a normal administrator? Fut.Perf. ☼ 11:43, 19 January 2013 (UTC)

That's weird. For what it's worth, I just got a Wikimedia timeout error when I moved the same pages to the title "Russia–Georgia war" (with the correct dash). I don't think the Wikimedia sysadmins would want us doing too many more experiments of this nature. :-) Graham87 13:16, 19 January 2013 (UTC)

As far as I know "bigdelete" applies only to deletions (and restorations), not to moves. The above page was moved successfully despite a timeout error. Ruslik_Zero 18:25, 19 January 2013 (UTC)

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

(Apologies if this message isn't in your language.) Next week, the Wikimedia Foundation will transition its main technical operations to a new data center in Ashburn, Virginia, USA. This is intended to improve the technical performance and reliability of all Wikimedia sites, including this wiki. There will be some times when the site will be in read-only mode, and there may be full outages; the current target windows for the migration are January 22nd, 23rd and 24th, 2013, from 17:00 to 01:00 UTC (see other timezones on timeanddate.com). More information is available in the full announcement.

If you would like to stay informed of future technical upgrades, consider becoming a Tech ambassador and joining the ambassadors mailing list. You will be able to help your fellow Wikimedians have a voice in technical discussions and be notified of important decisions.

Thank you for your help and your understanding.

Guillaume Paumier, via the Global message delivery system (wrong page? You can fix it.). 15:12, 19 January 2013 (UTC)

Icon floats to the top of my talk page

The Guild of Copy Editors' newsletter notices (example here) include a Guild of Copy Editors icon, which is supposed to appear on the right side of the notice. But on my browser (Firefox 3.6.28), the icon appears in the upper right corner of the talk page.

I see this problem on every page that has a GOCE notice, whereas other users don't (discussion here). I've determined that the problem isn't my Misplaced Pages settings by logging in on a different computer, where the problem doesn't appear. But on my preferred computer and browser, the only way to keep an icon from floating to the top of the page is to have another GOCE notice above it, in which case the uppermost icon floats to the top and the others stay where they're supposed to be. The bug is minor, but a bit annoying. Does anyone know how to stop it? A. Parrot (talk) 21:52, 19 January 2013 (UTC)

You are long overdue for an upgrade to Firefox. The automatic updater in 3.6 and earlier only picked up minor updates and doesn't download or notify you of major updates, which you have to go to http://www.firefox.com to obtain manually. The current version (18.0.1) displays the icon correctly. jcgoble3 (talk) 22:25, 19 January 2013 (UTC)

Sigh. I can't update any farther because of a long string of backward compatibility issues. I suppose I'll just have to live with it. A. Parrot (talk) 00:23, 20 January 2013 (UTC)

Bar above edit box

Hi there all! Is there a way I can get rid of the bar that appears above the edit box? When loading a page for edit I start typing but after a second or two the bar appears and takes focus away from my edit box. I never really use it so is there a lovely bit of js or css I could use to remove it? Cheers. ·Add§hore· 22:37, 19 January 2013 (UTC)

Try turning off "⧼tog-showtoolbar⧽" under Preferences → Editing → General options. – PartTimeGnome (talk | contribs) 23:58, 19 January 2013 (UTC)

Found it! Not under Advanced options but Usability features and unticking 'Enable enhanced editing toolbar' and 'Enable dialogs for inserting links, tables and more'. Cheers! ·Add§hore· 02:00, 20 January 2013 (UTC)

Are self-contained footnotes in template possible?

I was trying to add footnotes to the Template:Kim Jong-il family chart. But I quickly discovered that having footnotes and a reflist tag in a Template throws an error on the article when the template is used. How can I achieve what I was trying to achieve? Jason Quinn (talk) 01:02, 20 January 2013 (UTC)

I see your Reflist was in <noinclude>...</noinclude>. If you only want the references to be displayed on the template page then place each <ref>...</ref> inside a <noinclude>...</noinclude>. Or do you also want the references to be displayed in articles using the template? PrimeHunter (talk) 01:20, 20 January 2013 (UTC)

I re-added the ref and placed it in <noinclude>...</noinclude> tags while PrimeHunter was responding. If that's what you were after, then it should be solved. jcgoble3 (talk) 01:28, 20 January 2013 (UTC)

I was hoping to have the references also show in the article too. At this point, I'm curious if it can be done. I've desired this ability in the past too. Your idea is an improvement, and if what I want isn't possible, I'll keep your idea. Jason Quinn (talk) 01:50, 20 January 2013 (UTC)

PS I also realized that I screwed up the nested of the noinclude tags. I didn't want the reflist tag inside the noinclude scope. I fixed that but the referneces still don't appear on the article. Actually, I think I'm okay with references only appearing when the template is viewed as per Jcgoble3's solution. But I am still curious if what I was asking can be done. Jason Quinn (talk) 01:57, 20 January 2013 (UTC)

PPS I figured it out. My problem was caused because I lost track of the noinclude. It's the simple solution: just add a ref and add a reflist and it works. My first reflist was noincluded so there were problems but I didn't noticed it wasn't included. Mea culpa. I'm tired. Thanks for the replies. Jason Quinn (talk) 02:02, 20 January 2013 (UTC)

Suppressing Article Feedback tool on dabs

Hi. I've been seeing the feedback tool (v4 mostly) on a lot of dab and set index pages, where they aren't really helping at all. Is there a magicword or something that can be used to suppress their appearance? Intelligentsium 04:46, 20 January 2013 (UTC)

I believe applying Category:Article Feedback Blacklist should remove the feedback tool. You may want to check if there's a common template used by many or all of the pages in question, but no others (such as a specialized disambig or set index template), and add the category to that template instead. jcgoble3 (talk) 05:29, 20 January 2013 (UTC)

{{Disambiguation}} should be transcluded on most of them, so adding the template to the category should hide them all. (edit: actually, disambig already has the category. Do you have examples of disambig pages with AFT on them?) (X! · talk)  · @294  ·  06:03, 20 January 2013 (UTC)

Hm... the examples I've seen have all been set indices and disambiguations that are mistakenly marked as such. I'm going to add the {{surname}} template to that category also then. Intelligentsium 06:10, 20 January 2013 (UTC)

Er... oops heh heh, that template is protected. Would an admin kindly do it (I don't think a formal request is necessary)? Intelligentsium 06:12, 20 January 2013 (UTC)

The problem with adding the category to the surname template is that surname pages often have content alongside the disambiguation, which causes issues. (X! · talk)  · @301  ·  06:13, 20 January 2013 (UTC)

I see your point. However, I don't believe pages like Spiridonov which are essentially dabs and probably will never become anything more need the feedback tool (pages like Smith (surname) on the other hand, do). The vast majority of pages on which {{surname}} is transcluded seem to fit this latter description. Is there an alternative solution that doesn't involve large-scale changing of pages? Something based on the page's size perhaps? Intelligentsium 06:23, 20 January 2013 (UTC)

I feel as if it's one of those things that should get its own parameter, and then added to the articles that need it. (X! · talk)  · @310  ·  06:26, 20 January 2013 (UTC)

Yes, that was my first thought too, but even if the default were set to no feedback, there may be hundreds of pages with content that it would have to be added to (a drop in the bucket compared to the 21000 or so that use the template, but still). The alternative of course, it to use feedback as the default and suppress feedback as needed when spotted (obviously I'm not going to bring ~20000 pages into compliance all at once) but sheer scale would be a constraint to how effective this could be. (The set indices also do not generally get a lot of hits, so some of them will inevitably be missed). Still, this isn't exactly a mission-critical feature and the wiki will not die if a page that should not have feedback has it enabled, or vice versa. Intelligentsium 06:41, 20 January 2013 (UTC)

Bots, archive links to web pages

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

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

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

Crawler bots effect on page views

Following on from a query made to the cultural-partners mailing list, I'm curious about this, which no doubt has been discussed before. How best to estimate the number of page views that are actually bots? Is it a fixed number for all articles, or will it vary with the popularity of the article? User:Mike Peel pointed to this page, showing about 15% of ?all Wikimedia page requests are from bots, but what does this mean for the average en:WP article? Johnbod (talk) 16:25, 20 January 2013 (UTC)

Preventing Group Account Names

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

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

Useful links disappeared from botton of Nostalgia skin

Ever since early December 2012, the English Misplaced Pages does not have the row of handy links at the bottom of pages any more. It looks like this only applies to the Nostalgia skin, which I use. It also only seems to have happened to a few wikis, (e.g. these links that use Nostalgia on English and German, but not on French or meta). I was wondering if anyone knows why it happened, and if there is any chance of some of the links being restored. The links I am talking about are the ones that look like

Edit this page | Watch this page | Discuss this page | Page history | What links here | Related changes
| Move this page

I use the Nostalgia skin because it seemed the simplest way to get rid of the left-hand margin and avoid overriding browser fonts. I most often used this row of links to see if a page was on my watch list, to change the watchlist status, and for the “What links here” function. Recently I have been resorting to typing in the URLs manually. Vadmium (talk, contribs) 04:21, 21 January 2013 (UTC).

Pending Changes disagreeing with itself

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

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

• Misplaced Pages noticeboards
• Pages automatically checked for accidental language links
• Misplaced Pages requests for comment