Wikipedia:Village pump (technical): Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 00:07, 28 August 2014

Table of contents
First discussion
End of page
New post

Shortcuts

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

wikimedia.org or filed under the "Security" product in Bugzilla.

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: Wikipedia:Technical FAQ)

Click "[show]" 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 Wikipedia services, see Reporting a connectivity issue.

« Archives, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

New superprotect protection level, coming to your wiki soon

It appears as though the Wikimedia Foundation is planning to add a new protection level to the configuration of Wikimedia wikis so as to prevent every single user—including local administrators—from editing certain wiki pages.

My understanding of the change is that, once deployed to Wikimedia servers, it will require a new superprotect user right to be able to edit pages protected at the superprotect level. The user right is not assigned to any user group yet, but there is little doubt that it might be assigned to some group in the future.

The description of the patchset is as follows:

Add a new protection level called "superprotect"

Assigned to nobody by default. Requested by Erik Möller for the purposes
of protecting pages such that sysop permissions are not sufficient to
edit them.
Change-Id: Idfa211257dbacc7623d42393257de1525ff01e9e

Comments, including those from @Eloquence, are welcome and, indeed, encouraged. odder (talk) 13:28, 10 August 2014 (UTC)[reply]

Additional details here.--Eloquence * 13:30, 10 August 2014 (UTC)[reply]

How nice, another way to force things on the community when we don't want them. Intentionally designed to be used to fight off a recalcitrant community! Wikipedia:Arbitration/Requests/Case/Media Viewer RfC/Proposed decision has a header saying that the proposed decision is due tomorrow; let us hope for a decision enforcing the distance between the community and WMF members who put themselves above it. Nyttend (talk) 13:36, 10 August 2014 (UTC)[reply]

When the community manipulates the software in an irresponsible method, then it is logical that at some point those responsible for it's health will intervene. That was actually known and explained many times before, but not required before to exercise. BTW. No one is happy with this.... certainly not the devs. —TheDJ (talk • contribs) 14:09, 10 August 2014 (UTC)[reply]

When the community manipulates the software in an irresponsible method - The only body who should decide what is "responsible" and "irresponsible" in this respect is the community itself.--cyclopia ^speak! 14:52, 10 August 2014 (UTC)[reply]

While I'm not completely happy with this, I support the concept behind it, especially as some sort of code review will be introduced. Yes, we have some admins experienced with js here, but I feel allowing all of them, including those who no nothing about js (or CSS) to edit site-wide .js and .CSS pages is just asking for trouble. Far far better to leave it to the devs, who ~~(apparently)~~ know what they're doing to deal with the technical side, and for us to worry about content. Of course, of this was introduced under different circumstances (ie. after vandalism of common.js) no one would bat an eyelid. --Mdann52talk to me! 14:25, 10 August 2014 (UTC)[reply]

It should be noted that as far as I know, there is no immediate reason to use this protection level on English Wikipedia right now.... —TheDJ (talk • contribs) 14:31, 10 August 2014 (UTC)[reply]

@TheDJ: What happens when the devs manipulate the software in an irresponsible method? Mdann52 expresses an opinion not shared by many of us. --NeilN ^{talk to me} 14:43, 10 August 2014 (UTC)[reply]

What happens? Appeal to the WMF to reverse, per WP:CONEXCEPT. Alanscottwalker (talk) 15:15, 10 August 2014 (UTC)[reply]

"Irresponsible" admin changes can be reversed in minutes. Irresponsible dev changes (done for the "good of the community") can take weeks to reverse and sometimes only by an admin forcing their hand. --NeilN ^{talk to me} 15:38, 10 August 2014 (UTC)[reply]

Well, work on a privately owned domain has its little ups and downs, no doubt -- no use pretending one is not on a privately owned domain. Alanscottwalker (talk) 16:02, 10 August 2014 (UTC)[reply]

The site belongs to the WMF - legally speaking, they can run it any way they want to. (See also Wikipedia:Free speech.) You can always create a fork if you want (but you would need a big server farm to do that properly). Personally, I'd like to hear more about the kind of situations that the WMF would use this protection level in. The thing that springs to mind immediately is the JavaScript code that blocked VisualEditor, but I'm wondering if the WMF would use this protection level in other situations as well. — Mr. Stradivarius ^{♪ talk ♪} 15:34, 10 August 2014 (UTC)[reply]

In that case, the ED should cut the crap about "working for the users". --NeilN ^{talk to me} 15:41, 10 August 2014 (UTC)[reply]

@NeilN: I'm guessing that ED stands for Executive Director? — Mr. Stradivarius ^{♪ talk ♪} 15:53, 10 August 2014 (UTC)[reply]

@Mr. Stradivarius: Yes. I'll have to look for a transcript if you want but in her early days Tretikov emphasized the WMF should be working for the users. --NeilN ^{talk to me} 16:03, 10 August 2014 (UTC)[reply]

(edit conflict) :I can sort of see why this might be justified, per Mdann52, but the timing is awful. Have some egos been bruised? TheDJ, what was "actually known and explained many times before"? The specific superprotect proposal? Where? When? And if it was "not required before to exercise" and apparently "there is no immediate reason to use this protection level on English Wikipedia" then surely it is still not required, so what has changed? Unless your point is that something has happened on a non-English WP. - Sitush (talk) 15:40, 10 August 2014 (UTC)[reply]

@Sitush:, it has: de:MediaWiki:Common.js, in the grips of a wheel war over Media Viewer was just super-protected. Writ Keeper ⚇♔ 16:01, 10 August 2014 (UTC)[reply]

Writ, I can understand most of the code but I'm not a German reader - far too structured a language for someone used to dealing with Indian English ;) Has de-WP had a similar clash over scripts with the WMF over MediaViewer as was happening here? Does this mean that the WMF have managed yet again to upset members in two of its largest projects with the same "improvement"? - Sitush (talk) 16:57, 10 August 2014 (UTC)[reply]

I'm no better at German than you are; I only know of this because it was mentioned in the comments for this feature at gerrit. It would certainly seem so, though. It's the same code change to disable the Media Viewer that Peteforsyth tried here. Writ Keeper ⚇♔ 17:03, 10 August 2014 (UTC)[reply]

A dewp sysop, per the results of the RfC added the code to disable MediaViewer to Common.js and it was reverted and led to a wheel-war and Common.js is now super-protected there. --Glaisher (talk) 17:08, 10 August 2014 (UTC)[reply]

Thanks, both. It strikes me that the WMF developers need to explain better and probably listen more. It won't be much good having snazzy bells and whistles if you've got no core users. Equally, there are probably some people among the users who need to listen a bit more. - Sitush (talk) 17:12, 10 August 2014 (UTC)[reply]

Since apparently the WMF has decided we shouldn't talk about this at WP:AN, I'll duplicate my comment here: So much for trying to build trust between the devs and the community. Monty₈₄₅ 15:51, 10 August 2014 (UTC)[reply]
- I'm just trying to keep the discussion centralised. I'm just as happy to have the discussion happen on WP:AN as here, but it was started here first and it's good to have all the comments collected in one place. :-) --Dan Garry, Wikimedia Foundation (talk) 19:01, 10 August 2014 (UTC)[reply]
I can't say this surprises me; when the community goes so far as to implement flawed code that breaks things on the site just to spite the WMF's deployment of a feature, it's understandable that the WMF would implement something that keeps people from doing that again. Can this be misused by the WMF? Yep, and I'd like to see actual policy made by the WMF to govern when its employees can use it. But given past history of the communities' responses to software rollouts, is it unreasonable for this feature to exist and be occasionally used? Nope. Though I must say that I suspect 90% of these clashes could be prevented much more easily by a small set of certain people both community-side and WMF-side being topic-banned from software rollout discussions. But I suppose that would be too confrontational when we can just mess back and forth with software instead. A fluffernutter is a sandwich! (talk) 16:06, 10 August 2014 (UTC)[reply]

I see nothing wrong with the feature in itself, it could be legitimately used to enforce an OFFICE action on an article that needs to be locked down as a stub until legal issues are resolved.

However if it is used to prevent consensus from being enforced I will likely find a project that is serious about the concept of consensus based editing. I don't want to see the community coming to an agreement that a page should change only to find that someone with "superrights" has prevented it by fiat. Chillum 17:15, 10 August 2014 (UTC)[reply]

I don't think this is about articles. It's about forcing software. - Sitush (talk) 17:19, 10 August 2014 (UTC)[reply]

I was stretching the imagination as to how this could be used other than to override consensus. If the foundation continues the pattern of overriding consensus by technical fiat I will volunteer elsewhere. You cannot have 99.999% of the value of your project come from volunteers and then decide that their view can be disregarded with the flip of a switch. Not if they want me to stay. Chillum 17:31, 10 August 2014 (UTC)[reply]

Yep. I wonder if some people at de-WP might decide to take some co-ordinated time off. I think I would if it happened here. - Sitush (talk) 17:35, 10 August 2014 (UTC)[reply]

Historically when one party does all the work and the other has all the power "co-ordinated time off" has been very effective. Damn, it sure is sunny out there... Chillum 17:41, 10 August 2014 (UTC)[reply]

I suppose I am in the minority here of agreeing with most of the WMF's recent implementations. Sure, they had bugs, but so do many off-the-shelf products produced for far higher budgets. Sure, I didn't like VE or MW when they were first released, but just like changes to other sites, I've grown to see how they can be beneficial to both readers, which is a far far bigger pool old people than editors will ever be. Yes, it causes us some inconvenience (shock - 1 extra click to get onto file pages), but we need to put this into context. Using js hacks to suppress stuff appearing helps nobody; However, without greater reader participation in RfC's, we should be careful what we do moving forward. MW had an opt-out button; don't like it? That's what the button was there for. However, I do feel the foundation needs to listen to editors more, and maybe roll out software changes more gradually, taking editor and reader feedback into account. --Mdann52talk to me! 17:28, 10 August 2014 (UTC)[reply]

It took me ages before I realised that there was an opt-out button. That is part of the problem and it is one that is likely to get worse as more and more bells and whistles are added. - Sitush (talk) 17:31, 10 August 2014 (UTC)[reply]

@Sitush: I agree with the point about too many new features being added on. However, in terms of design, Wikipedia is years behind most other websites. However, the main issue of hacky js being used remains; taking the de example, specify meaning people had to do another js hack to turn it back on, and preventing logged-out users using it even if they wanted too. --Mdann52talk to me! 17:56, 10 August 2014 (UTC)[reply]

I'd argue that this should be delegated much the same as the edit-filter, requiring a special group, but available for assignment-there are some interface pages that most admins want nothing to do with, but could otherwise be very disruptive to edit without really knowing what you are doing. — xaosflux ^Talk 17:29, 10 August 2014 (UTC)[reply]

If the community could decide who had access to this tool then that would make sense. I would be consensus driven. If it is something for the foundation only then it is a problem. Chillum 17:32, 10 August 2014 (UTC)[reply]

That depends on what community you are thinking about. The WMF has multilingual participation that has mechanisms for user persuasion of the Foundation (even actual votes in some areas), but also a structure for organizational decision making -- an analogy, locally, is Arbcom whose decisions are also not subject to consensus, per CONEXCEPT. Alanscottwalker (talk) 18:41, 10 August 2014 (UTC)[reply]

The fact that this new protection level is coming at the behest of Engineering chief Erik Möller rather than the legal department indicates to me that this user right is going to be used as a mechanism to shove VE and Flow down our throats, not as a content-locking device. Carrite (talk) 17:54, 10 August 2014 (UTC) Last edit: Carrite (talk) 17:56, 10 August 2014 (UTC)[reply]

Well, judging by recent events on de-WP (machine translation on Writ's page), the "group" who have been assigned the superprotect status there may consist of one person. - Sitush (talk) 18:32, 10 August 2014 (UTC)[reply]

Not a group of one, sorry. JEissfeldt also superprotected it earlier. - Sitush (talk) 18:40, 10 August 2014 (UTC)[reply]

Will the superprotect right protect de.wiki from vandalism when all their administrators withdraw their services in protest? –xeno^talk 18:36, 10 August 2014 (UTC)[reply]

Obviously not. But I'm sure the WMF have thought that through carefully. They always do. If I shake my head any harder it's likely to fall off. Wow. Begoon ^talk 18:41, 10 August 2014 (UTC)[reply]

arbitrary break

(edit conflict) I support the addition of this new protection level to be used for BLACKLOCK enforcement as it will prevent administrators from doing things they shouldn't, especially those due to some kind of edit conflict that gets overlooked or some other accidental reasoning (surely none of them would do these things intentionally no, I'm not being sarcastic). As far as them adding such a thing to force software changes on the community, they quite simply wouldn't use it for this purpose (because they should know it would never work unless they are going to lock down nearly the whole wiki to enforce it). If we play out an instance like JavaScript code that blocked VisualEditor, which I would like to point out the the code added by our administrator was flawed and poorly executed, and once reverted by the devs it ended there and there was no edit warring, so there was no need for this protection to be applied (if it had existed). For the sake of argument though, lets say they locked MW:Common.js for this, they would also have to lock all four MW:Skin.js, MW:Gadgets-definition, and every script that is imported on each of those pages. They are just not going to go through all of that trouble. Can we please assume some good faith on the part of the developers here? — {{U|Technical 13}} ^{(e • t • c)} 18:44, 10 August 2014 (UTC)[reply]

er, yeah... You may not have read the discussion, "adding such a thing to force software changes on the community" is the only reason it's been used so far, at de.wp, and Erik clearly explains that is its purpose in the mailing list discussion he links. Do try and keep up, there's a good chap. Nobody has said it's foolproof, in fact, on the mailing list the very flaws you mention are pointed out. It's a poor implementation - no surprises there. Its purpose, however, is in no doubt I can see. Begoon ^talk 18:50, 10 August 2014 (UTC)[reply]

Begoon - do try and behave in a friendly, collegial manner. Nick (talk) 19:03, 10 August 2014 (UTC)[reply]

Of course, Nick. Perhaps I am too harsh sometimes in defending myself and others from accusations of assuming bad faith that could have been avoided by a little research. I'll bear your advice in mind. Thanks. Begoon ^talk 19:07, 10 August 2014 (UTC)[reply]

or perhaps I just read it differently than you. or perhaps you missed the point of my post. All that I was saying is that this new level has the potential to be used for a good purpose (when used to enforce blacklock legal issues) and has no effect when trying to be used for the wrong purpose (like trying to force something on the community) because there are just way too many ways to circumvent it (per Edokter and the admin on de that deleted and restored the page (without protection, which I'm sure WMF staff will fix)). — {{U|Technical 13}} ^{(e • t • c)} 19:27, 10 August 2014 (UTC)[reply]

Yeah, probably I missed your point. It's pretty hard to assume it was introduced for the good reasons you speculate, though, when it was immediately used for what you rightly say it isn't any good for, especially given Erik's clear statement of intent. Hey ho. No good will come of this - of that I remain sure. Begoon ^talk 19:37, 10 August 2014 (UTC)[reply]

@Technical 13: "deleted and restored the page"... FYI, now they can't: gerrit:153345 Circumventing those protections in "illegal" ways is shortsighted. Zhaofeng Li [talk... contribs...] 00:31, 12 August 2014 (UTC)[reply]

Well, like I said, I expected it was something that would quickly get patched... — {{U|Technical 13}} ^{(e • t • c)} 00:44, 12 August 2014 (UTC)[reply]

Technical 13, please don't repeat the misstatements that were made: the JS change that disabled Visual Editor did exactly what it was intended to do. That Erik and James later made a series of false statements in an effort to pretend that there was a problem with the change doesn't mean that you should repeat the false statements. The patch prevented anyone from turning on Visual Editor prior to making at least one edit with conventional Wikitext. Given that anyone using Visual Editor needed to be intimately familiar with Wikitext in order to recognize and correct the file corruptions it made, that was a quite reasonable restriction.—Kww(talk) 19:27, 11 August 2014 (UTC)[reply]

I'm going to emphasize the disclaimer here: what I write here are entirely my personal views and in no way represent anything at all official. Yes, the whole idea of staff-only superprotection sucks, and I'd really rather have seen more moderate elements on dewiki emergency-desysop the admin there who was wheel-warring to add a JS hack that appears to have gone well beyond what I've heard (mainly via Google Translate) is the actual vote result at that project. Instead any moderate elements seem to have been mostly silent while reactionaries pat each other on the back. But "oh noes! teh WMF is stealing our autonomiez!" won't do any good, because they're not. The purpose of the WMF isn't to simply be a hosting provider for Wikipedia or to serve the will of the editors. It's to collect, develop, and disseminate educational content effectively and globally, in particular by providing infrastructure and organizational framework for us to create that content. Maybe we disagree with some of the infrastructure (VE, MediaViewer, Flow, etc) they're providing, but it's not our right to overrule them any more than it's their right to interfere in the content of articles. But we can work with them and try to reach a consensus on what the best course might be. In truth, we're not even two separate groups, both because many of "us" are also "them" and because "us" is far from being only one group.
I doubt this superprotection is really a step on the way to code review for site JS and gadgets, although the need for it may spur that project. Instead, I see it as a reaction to certain admins actively breaking things in the name of "consensus" among a relative handful of radical editors who can't handle unchecking a checkbox in their preferences over the silent consensus of thousands of users who enabled the beta feature and who responded to the surveys. And I'm sure this breaking of things does nothing to "force" the WMF to listen; despite claims to the contrary, I greatly doubt (no, I have no personal knowledge of this either way) that the VE-disable hack really forced the WMF to back down. Rather I believe than the actual errors that were being introduced into pages (which is something tangible, not just WP:IDONTLIKEIT and typical-mind-fallacy-based arguments) and a realization that they weren't going to be able to be fixed quickly did it and the public outcry served to bring attention to those real issues. Code review for site JS has been discussed, along with discussions of a central repository for gadgets, templates, modules, and the like (Commons-like, but not Commons), but it'll almost certainly be run mainly by volunteers rather than staff paid for that purpose.
So what does this new ability for superprotection actually mean for us? If we can manage to work with the WMF instead of letting demagogues speak and act for us, probably absolutely nothing. Sure, some of us may not like some of the new features being rolled out—I myself will likely never use VE (I like wikitext) and I'm skeptical of Flow, but I see how both of these could be good for newbies and I know (and this is from personal knowledge) they're being developed in good faith. But we'll get nowhere by trying to assert rights that we never in fact or in theory actually ever had. We need to try to compromise, to show the WMF when they sometimes go wrong instead of constantly crowing it without evidence, and to admit that sometimes we may be wrong as well. Anomie ⚔ 19:19, 10 August 2014 (UTC)[reply]

With VE the WMF/dev clearly overreach themselves. The software was not ready for beta, they should have waited a year, VE is now much closer to the state where it could be made a default. Unfortunately the handling of relations mean VE uptake is less than 1% of all edits[1] the banner appeal does not seem to have made a dint in this, and there is a good chance VE will be effectively dead on en.wikipedia for many years to come. I've no doubt the devs would have used super-protection to force VE on the community. Rather than these technical measures the WMF need to work with the community, move at the speed of the community, have senior people spend much more time on the various wiki guiding products through each wiki's processes. The reason wikipedia took off was Jimbo took the time to discus things at length with the community, this is a lesson the WMF has forgotten. Any other path will alienate the community, encourage more people to leave and actually be counter productive to its stated aims of boosting the number of editors.--Salix alba (talk): 20:25, 10 August 2014 (UTC)[reply]

If this protection level is for interface pages, maybe editinterface could be used instead, separating it from sysop and making it available to fewer users. The new protection level could then be used for something between semi and full protection, where it is more needed, making it possible to give users ability to edit protected articles such as New York Institute of Technology that are in need of improvement without also giving unnecessary access to deleted revisions and editing of protected templates and scripts. There's one thing that isn't clear from the links I've seen: "superprotect" is added as a permission, and as a protection level, but where is it specified which permissions are needed to protect at each level ("superprotect", "sysop", "autoconfirmed" or others)? Peter James (talk) 23:44, 10 August 2014 (UTC)[reply]

First off, i have no particular opinion pro or con the MediaViewer. I don't much use it, though it now becomes clear why my browser started acting up last May.

However, I think the introduction of new privileges is the worst possible solution to any given problem, especially if its use flies in the face of the opinions of the wikipedia communities. It's use over a bug-ridden piece of new software isn't just the worst possible solution, it's positively disingenious, since it adds futher strain to the relation between communities and the ones who claim to serve us, especially given the way WMF saw fit to handle the situation on de.wiki. (and yes, I do read German and do not rely on google's garbled version).

This is the second time WMF screwed up. It's vocal opposition to the European "Right to be forgotten" policy here and here is not just a hyperbole and, frankly, silly, it usurps the political views of contributors and speaks on behalf of the communities without consulting them.

It is WMF's job to facilitate the encyclopedia and other projects, it is not it's job to ram it's decisions down the throat of various communities, unless there are sound legal reasons to do so (i.e. a court order or clear violations of laws). ANY other reason is unacceptable. Kleuske (talk) 13:03, 11 August 2014 (UTC)[reply]

"It's the WMF's job . . ." That's an opinion, and it may or may not be valid, but anyone must realize upon reflection, the foundation will have its own opinions about doing its job. It is "its job", after all. Alanscottwalker (talk) 14:56, 11 August 2014 (UTC)[reply]

They are very much entitled to that, no argument there, as I am entitled to voice another opinion. I do object to the "L'Etat? C'est moi!"-attitude. displayed in this use of technical measures to enforce a change concerning a, shall we say, not generally well-receiv'd piece of software. This does not engender a great amount of confidence in WMFs social skills. Skills i would deem fundamental, given its mission statement. Kleuske (talk) 16:13, 11 August 2014 (UTC)[reply]

I'm assuming that the German RfC did have consensus to reject MediaViewer in some way. The much-vaunted but useless civility policy, anyone? What can be more incivil than over-riding consensus? It isn't always about naughty words. - Sitush (talk) 17:18, 11 August 2014 (UTC)[reply]

The figure being widely 'cited' is that there was a 75% majority in support of disabling Media Viewer as the default for logged-in users. Revent^talk 22:03, 11 August 2014 (UTC)[reply]

For the curious... de:Wikipedia:Meinungsbilder/Medienbetrachter, results: pro:190 (72.5%), con: 72 (27.5%). Kleuske (talk) 11:00, 12 August 2014 (UTC)[reply]

@Peter James: "superprotect" wouldn't make sense as a level between autoconfirmed and full protection, because that wouldn't really merit the "super-" prefix. But there's nothing stopping the creation of such a level with a more appropriate name besides the need for community consensus, exactly as was done to create template protection. And for what it's worth, it's already possible (and easy from a technical standpoint) to create a group that could edit fully-protected pages (but not cascade-protected pages) without them having all the rest of the admin toolkit, but that sort of idea has already been discussed and rejected several times.
As for permission to protect at a level, the 'protect' right gives the ability to apply and remove protection at any level you can edit through (e.g. it would be impossible to give a user the ability to both apply/remove semi-protection and to edit fully-protected pages without also giving them the ability to apply/remove full protection). Anomie ⚔ 13:33, 12 August 2014 (UTC)[reply]

Some party hack decreed that the people
had lost the government's confidence
and could only regain it with redoubled effort.
If that is the case, would it not be simpler,
If the government simply dissolved the people
And elected another? --John (talk) 18:28, 11 August 2014 (UTC)[reply]

I considered the previous controversy over Eric's actions overblown. But this really does seem to be a God complex in operation. All the best: Rich Farmbrough, 22:22, 11 August 2014 (UTC).

Just out of curiosity, which wrong version of the German Wikipedia was super-protected? —Neotarf (talk) 00:06, 12 August 2014 (UTC)[reply]

The WMF's. Jackmcbarn (talk) 00:15, 12 August 2014 (UTC)[reply]

Moller has been blocked on de.wiki btw, so that is a good start. Tarc (talk) 00:25, 12 August 2014 (UTC)[reply]

This is probably a better link for it.—Neotarf (talk) 00:36, 12 August 2014 (UTC)[reply]

Wanna bet the WMF coders will pronto add a hack so one can edit while blocked if one has superprotect rights? Probably the next thing is going to be superblock rights that can't be undone by admins, so the WMF can have something to get rid of admins they don't like. JMP EAX (talk) 08:15, 12 August 2014 (UTC)[reply]

I am really curious why the WMF is putting so much effort into making volunteers (especially admins) feel they are not welcome unless they agree with the party line. It seems Erik deliberately decided to use this opportunity to show who is in charge (he is too smart to do something like this accidentally).
Anyway, enough of my surprise and sadness. How to go forward from here isn't easy. It is clear that we need better communications channels between developers and community, but maybe we also need a less change-adverse decision process allowing the community to agree on implementing new features. Using RfCs after flawed software has been deployed and without an easy way to just revert the change (the well-proven wiki way to radical change: BOLD-REVERT-DISCUSS) isn't a very good model to build mutual trust, as has been demonstrated in the last couple of failed software roll-outs. In any case, "the community" is difficult to talk to, and perhaps we should move towards something like representative democracy so that these issues could be calmly and rationally discussed (ArbCom, our only elected group, specifically wasn't elected to decide the future of Wikipedia, but just to serve as its court). Not clear if something like this can help to restore trust between WMF and community, but the current build-up of distrust should not continue much longer. —Kusma (t·c) 12:21, 12 August 2014 (UTC)[reply]

Your second paragraph is right on. If communication is the issue, our focus needs to be on better ways for the community to communicate. (Your first paragraph seems overblown, there is in fact very little admins are resisted in doing from that quarter, and it seems some admins get overly offended, when someone says, 'ah, no' to them in very limited areas). Alanscottwalker (talk) 14:01, 12 August 2014 (UTC)[reply]

After all the other Erik/Eloquence "miscommunication" about MediaViewer, he says about superprotect "If such a conflict arises, we're prepared to revoke permissions if required." Clearly, the WMF doesn't feel it needs to listen to editors anymore. Chris Troutman (talk) 14:32, 12 August 2014 (UTC)[reply]

Well, that would be a matter of clearer communication; as for "listen", that just simply does not always lead to "agree". Alanscottwalker (talk) 14:38, 12 August 2014 (UTC)[reply]

Nobody seems to have mentioned the RfC on Superprotect rights at Meta yet, so I will. --Redrose64 (talk) 15:02, 12 August 2014 (UTC)[reply]

If the WMF want to be wikigods, let them write the content and clean up the vandalism too.--Cube lurker (talk) 16:35, 12 August 2014 (UTC)[reply]

Eloquence has actually responded to inquiries about this on his page here be aware it's all in German. I was able to translate some of it via bing, but it would be better if a native German speaker took a look . Kosh Vorlon 18:10, 13 August 2014 (UTC)[reply]

Absolutely shocking behavior by the WMF and this is likely to be the final nail in the coffin of me actively editing or being an admin here. I had already wound down due to previous things they've done but I see no way back now. I'm actually not against the idea of superprotect however the way it has been introduced, with no discussion and virtually no notice, is shocking and shows a complete disrespect for editors and admin. Without software and support people this site would collapse. Without volunteer admins and editors likewise. The sooner the WMF realise this and stop letting the first group so seriously annoy the second the better. I had actually started a draft RfC in my user space for withdrawing labour over the VE issue and now from what I read above it appears de.wiki are considering something similar. It does now seem only a matter of time before something like that happens on one of the big sites and then maybe the WMF will finally properly appreciate us. They certainly aren't going to be happy - I can't imagine the press will be good for them. Dpmuk (talk) 23:19, 13 August 2014 (UTC)[reply]

RE Kosh Vorlorn - A few days ago, on the German Wikipedia some admin tried to execute the result of an RfC which ended 190 to 72 for making it opt-in instead of opt-out (similar to what happened here on en.wiki), but there was already some sort of protection in place. So the admin hacked it and disabled it completely. This led to a wheel war with WMF employees and then the Superprotect right was created and used on the MediaViewer. The right's description says that only WMF employees can get it, nobody else is eligible. In the above linked discussion, Eloquence uses again the "silent-majority-fallacy": 260 voters can not represent 250 million readers/month. The other participants in the discussion say that Eloquence is arrogant, and uses empty politician's talk; and that the WMF developpers are unwilling to hear the community, and incapable to develop any new feature without flaws, and can not implement anything without drama. Kraxler (talk) 16:25, 15 August 2014 (UTC)[reply]

Erik Möller/Eloquence is still blocked, block is for 1 month beginning on August 11. The other WMF admin involved in the wheel war, Jan Eissfeldt has been recalled, and under the rules of de.wiki must start an RfA within 30 days, or gets desysopped by default. Kraxler (talk) 16:42, 15 August 2014 (UTC)[reply]

For the curious, here's the latest developments on this issue, off-en.wikipedia:

As of 17:05, 19 August 2014 (UTC), an RfC about superprotection has received over 700 votes on the matter. These votes break down as follows:

With regard to 4 statements (translation possibly poor, please fix) [Note: translation is ok. Kraxler]:

The WMF is petitioned to remove superprotection from all pages on the German language Wikipedia, immediately.

Yes: 590, No 92, abstention 24.

The WMF is prompted to remove the superprotection right from the Staff group, immediately.

Yes: 457, No 73, abstention 31.

The WMF is prompted to reverse the software change(s) which introduced the superprotection right in short term (e.g. with the next software update).

Yes: 338, No 99, abstention 81.

The WMF is prompted to assign new group rights, that may applied to block elected rights-holders (i.e. administrators, bureaucrats, check users, Oversighters, stewards), only to user groups whose members were also elected by the local (or, where appropriate, international) community.

Yes: 327, No 73, abstention 79.

(Comment if you could get 700 people to express an opinion on an RfC at the English Wikipedia, it would be a record. And the German Wikipedia is smaller than the English. The Foundation would ignore this RfC only at their peril.)

The RfC about superprotection at Meta continues, although the discussion there has been slowing down.
A parallel discussion on Lila's user page on Meta. It appears to be a rather productive one, with Lila asking for suggestions in specific areas to prevent a clash like this between the communities & WMF in the future. -- llywrch (talk) 18:50, 19 August 2014 (UTC)[reply]
A "caricature". . .

File:Superprotect_caricature_image.jpg Tito☸Dutta 06:51, 21 August 2014 (UTC)[reply]

Ugh, that's just FUD. And huge and ugly, so I've linkified it for you. If you want caricatures, File:WMF building wiki wall in August 2014 caricature.jpg shows some creativity and depicts a valid viewpoint (even though I personally disagree with that viewpoint) instead of ridiculous fear-mongering. Anomie ⚔ 13:20, 21 August 2014 (UTC)[reply]

Proposal No. 1 on the German WP has already over 650 yes votes. There is now an open letter at Meta which can be signed by those who agree with it. Kraxler (talk) 17:19, 21 August 2014 (UTC)[reply]

This will be the equivalent of an Office action, I'd assume. 75.151.153.97 (talk) 16:07, 23 August 2014 (UTC)[reply]
IMO, including common JS and CSS as editor configurable features was a mistake in the first place, so I'm inclined to support measures that correct it. Protonk (talk) 14:52, 27 August 2014 (UTC)[reply]

Superprotect update

Erik & Lila have posted a statement concerning Superprotect on the German Wikipedia here. An English translation can be found here. The TL;DR version is that after hearing from the communities, they rolled it back. -- llywrch (talk) 20:22, 27 August 2014 (UTC)[reply]

Citations with title parameter in rtl language, beginning with numbers: Display issue and workaround

Citations with a title parameter in a right-to-left language such as Hebrew, that begin (on the right) with a number (which itself is left-to-right) have trouble displaying the foreign and English-translated titles correctly. In this example, the Hebrew number 12 is intentionally translated as 13 to make the errors clearer. In the markup, the Hebrew title begins (on the right) with the number 12, but it incorrectly displays in the editing screen, and here shown literally with <nowiki>, with the number on the left. (This problem is not confined to citations, but exists throughout Wikipedia, and is beyond the scope of this issue.) {{cite web}} is used here, but the same problem appears with other cite templates including {{cite news}}.

The two citation bugs are:

Without the English title protected by <span dir="ltr">, the English number moves into the Hebrew title.
Without the Hebrew title protected by <span lang="he" dir="rtl">, the Hebrew title displays with the number on the left instead of the right.

Markup text	Displays as
`{{cite web \|author=Tova Green \|date=6 May 2010 \|title=12 ימים\|language=he \|trans_title=13 days \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}`	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)
`{{cite web \|author=Tova Green \|date=6 May 2010 \|title=<span lang="he" dir="rtl">12 ימים</span> \|language=he \|trans_title=13 days \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}`	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)
`{{cite web \|author=Tova Green \|date=6 May 2010 \|title=12 ימים \|language=he \|trans_title=<span dir="ltr">13 days</span> \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}`	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)
`{{cite web \|author=Tova Green \|date=6 May 2010 \|title=<span lang="he" dir="rtl">12 ימים</span> \|language=he \|trans_title=<span dir=ltr>13 days</span> \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}`	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)

—Anomalocaris (talk) 01:42, 18 August 2014 (UTC)[reply]

Is the fourth example the one that is displayed correctly? It looks like adding a span dir="ltr" declaration automatically for |title= parameters when ltr languages are declared in |language= might do the trick. I have paged the folks who know the details of the Lua code that underlies most of the cite/citation templates. – Jonesey95 (talk) 16:38, 18 August 2014 (UTC)[reply]

Jonesey95: Yes, the fourth example is the one that is displayed correctly. As I say, the workaround involves mucking with both the |title= and the |trans_title= parameter. Whatever the difficulties in handling rtl languages in the title parameter (or anywhere else), the |trans_title= parameter shouldn't need additional script for ordinary English to display correctly. —Anomalocaris (talk) 06:41, 19 August 2014 (UTC)[reply]

I'm not thinking that this is a CS1 problem. I think I can duplicate the problem outside of a CS1 template by simply copying the Hebrew characters from one of these citations and pasting them into this edit window:

ימים

If I then put the cursor at the right end of the Hebrew string and type any letter on my keyboard ('a' in this case)

ימיםa

then the character is placed to the right of the Hebrew string. This is how it should work, correct? If I repeat the above experiment but instead type a number ('9'), the number is placed at the left of the Hebrew string:

ימים9

From this I think that I can conclude that the problem lies elsewhere than in CS1.

—Trappist the monk (talk) 19:01, 18 August 2014 (UTC)[reply]

Trappist the monk: You are right that the behavior in my second bullet point is not confined to |title= parameters of {{cite}} templates. It's a problem throughout Wikipedia, and it's actually the behavior you would expect. If you have Hebrew embedded in an English stream, and the Hebrew begins with a number, the displaying software has no way of knowing that the number is part of the Hebrew (and therefore has to be on the right of it) unless some additional markup brackets the number together with the Hebrew. So my second bullet is not really a bug. One could argue with the |language= parameter set to a rtl language the |title= parameter should be assumed to be rtl. Unfortunately Wikipedians do not strictly follow this rule. There are many instances where the |title= parameter is the English-translated title even when the |language= parameter is set to an rtl language such as Hebrew. So I would advise against any special treatment for the |title= parameter to fix the second bullet "bug". But the first bullet really is a bug. Plain English shouldn't need additional markup to display correctly.—Anomalocaris (talk) 06:41, 19 August 2014 (UTC)[reply]

Module:Citation/CS1 simply concatenates |title=, |trans-title=, and appropriate punctuation into an internal variable Title. This variable is used either as-is, or as the display text for |url= when the code renders the citation:

[http://MaybeSo.com/12days.html "12 ימים" [13 days]]

If an editor wraps the content of |title= in <bdi>...</bdi>, the concatenated result is correct.

[http://MaybeSo.com/12days.html "<bdi lang="he" dir="rtl">12 ימים</bdi>" [13 days]]

It occurs to me that the module could automatically wrap every |title= with <bdi>...</bdi> tags regardless of language. This problem isn't limited to digit-initial |trans-title=. This:

{{cite book |title=ימים |volume=2}}

produces this:

ימים. Vol. 2.

with <bdi>...</bdi> we get

ימים. Vol. 2.

I'll experiment with having the module wrap |title= values after I make a currently pending update to the live module code. I will post my results at Help talk:Citation Style 1.

—Trappist the monk (talk) 12:04, 19 August 2014 (UTC)[reply]

I think <bdi> should fix it; see Help:HTML in wikitext#bdi. Have to check browser support though.

Markup	Renders as
{{cite web \|author=Tova Green \|date=6 May 2010 \|title=12 ימים\|language=he \|trans_title=13 days \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)
{{cite web \|author=Tova Green \|date=6 May 2010 \|title=<bdi lang="he" dir="rtl">12 ימים</bdi> \|language=he \|trans_title=13 days \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)
{{cite web \|author=Tova Green \|date=6 May 2010 \|title=12 ימים \|language=he \|trans_title=<bdi dir="ltr">13 days</bdi> \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)
{{cite web \|author=Tova Green \|date=6 May 2010 \|title=<bdi lang="he" dir="rtl">12 ימים</bdi> \|language=he \|trans_title=<bdi dir=ltr>13 days</bdi> \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)

-- Gadget850^talk 01:00, 19 August 2014 (UTC)[reply]

Gadget850: Yes, it appears that <bdi> works better than <span>. If the rtl |title= parameter is tagged with bdi, the English |trans_title= parameter displays correctly without additional markup. But still, protecting the rtl |title= parameter with <span> should also work, and the second bullet is still a bug in my opinion. —Anomalocaris (talk) 06:41, 19 August 2014 (UTC)[reply]

Either of these solutions will bugger up the COinS metadata. Here's the COinS title when it's wrapped with <bdi>...</bdi>:

&rft.btitle=%3Cbdi+lang%3D%22he%22+dir%3D%22rtl%22%3E12+%D7%99%D7%9E%D7%99%D7%9D%3C%2Fbdi%3E

—Trappist the monk (talk) 12:04, 19 August 2014 (UTC)[reply]

I knew that would happen, but it does show a route to the solution. I logged a feature request some time ago for better language support, including RTL support. <bdi> was whitelisted since that request. We should not need to do anything to 'trans_title' as it should be English. -- Gadget850^talk 12:52, 19 August 2014 (UTC)[reply]

Just notice the the last example uses dir=ltr missing the quotes so it doesn't do anything.

The issue occurs because 'title' and 'trans_title' are combined to create the link. Looking at this, I can't see a downside of wrapping the title in <bidi> in the template to isolate the directionality of 'title' from 'trans_title'. If we add that, then we should go on and add the language code as well, which has been on the suggestion list for a while. -- Gadget850^talk 12:23, 24 August 2014 (UTC)[reply]

Wikipedia cannot assume that the |title= parameter is entered in the language declared in the |language= parameter. Wikipedia editors sometimes translate the title to English when using the |language= parameter. I do this myself sometimes, especially if the title is just a name or otherwise the same in English and Hebrew, such as "Halleluyah". So I would advise against adding language codes around the |title= parameter, and <bdi>...</bdi> codes should not specify the direction. —Anomalocaris (talk) 00:59, 25 August 2014 (UTC)[reply]

Then we can't fix the issue with italicized Asian characters in a title. -- Gadget850^talk 10:29, 25 August 2014 (UTC)[reply]

There has been no discussion under this heading of italicized Asian characters in a title. This is a discussion of rtl languages mixing with various symbols such as numbers and whether those symbols appear to the left or right of rtl language characters. —Anomalocaris (talk) 04:24, 26 August 2014 (UTC)[reply]

Coordinates issue in infoboxes

This page in a nutshell: When infobox template data is dumped to the database dumps, it does not always include the directional parameter (when it is hard-coded). This means that someone using the data from the database will not come up with the right coordinates if they simply use the data.

I am in correspondence with a representative of Microsoft regarding information in Wikipedia:Database download. I am not familiar with those dumps, but assume someone in this forum is familiar with them.

Microsoft uses data from the database dumps in connections with Bing maps.

The challenge is that Wikipedia editors have created several versions of infobox templates, which handle coordinate data in different ways.

Some templates use the convention that longitude values west of Greenwich should be entered with a negative sign in front of the degrees. Other templates use the convention that such location should use a positive value for degrees, but include a parameter such as longEW which should be used with an entry of "E". (Mutatis mutandes for latitude)

I believe that this, so far, is not an issue. It is merely a need to establish two cases, with case one between a templates with a directional indicator set to either E or S or both, and case two, where degrees are entered with a negative sign.

However, we have some less well-designed templates.

For example, there is a template for South African towns {{infobox South African town}}

(The issue also applies to at least one template for Australia.)

The problem is that the template uses the directional parameter, but has hard-coded it within the template, on the not unreasonable assumption that all towns in South Africa should have latNS=S and longEW=E

Note that this does not cause a problem in the template or the article. The coordinates are rendered correctly.

However, what has been told to me is that when the data is dumped to the database dumps, it does not always include the directional parameter (when it is hard-coded). This means that someone using the data from the database will not come up with the right coordinates if they simply use the data.

One option is to identify all infobox templates and find out which ones have hard-coded directional values. With this information, a case 3 could be cleanly identified. I have no idea how many there are or how to find them.

The meta-question is who has the responsibility for "fixing" the issue. One argument is that there is not a problem in Wikipedia, and therefore there is no problem to fix.

Another argument is that the datadumps are a Wikipedia "product" and if they are not usable as is, we have some interest in addressing problems.

I see two paths for fixing the dumps:

Identify a list of all templates with hard-coded directional parameters so that a third party user can made necessary adjustments
Identify a coherent paradigm for template design, and ask someone to change templates not in conformance.

Option 1 is easier in the short term, I think, but I do not know how to do it. Option 2 is a better long-term solution, in my opinion, but maybe one that will be vetoed by the community.--S Philbrick (Talk) 21:52, 18 August 2014 (UTC)[reply]

Yes, one of our 'wonderful' hacks, that has served us well and others not so much :) Luckily, we have most of this data parsed into a separate database now, using the {{#coordinates}} function of the GeoData extension. I think that is a better way forward. I'm pinging some engineers that might be able to help, and otherwise I'll forward to wikitech-l mailing list. —TheDJ (talk • contribs) 22:58, 18 August 2014 (UTC)[reply]

Indeed, GeoData/Wikidata is the way to move forward in this situation. I don't think that we should care about uses of dumps for things other than loading them into MediaWiki. Instead, we should refer people to the proper ways to access our data. Max Semenik (talk) 00:20, 19 August 2014 (UTC)[reply]

In other words, can you forward it to msemenik

wikimedia.org? Max Semenik (talk) 00:34, 19 August 2014 (UTC)[reply]

@MaxSem: I forwarded it. I'm not sure you will get the whole stream, but it is Ticket:2014080510001771 if you want all the back and forth.--S Philbrick (Talk) 01:52, 19 August 2014 (UTC)[reply]

Yet another reason to replace overly-specific infoboxes with more generic examples; in this case {{Infobox settlement}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:31, 19 August 2014 (UTC)[reply]

It would be good sense to sign-check the data on import anyway. And certainly there are many other ways to get the coordinates to confirm. Wikipedia, especially a snapshot thereof is not a great source for coordinates where accuracy is important. For statistical work its pretty good though.

All the best: Rich Farmbrough, 22:39, 20 August 2014 (UTC).

I would agree with the others who have mentioned that Wikidata is probably the way to do this going forward. Zell Faze (talk) 23:42, 25 August 2014 (UTC)[reply]

What's up with Firefox and security certificates?

A couple of hours ago I had no problem editing with Firefox, my preferred browser for that purpose. I got back on, opened it up and clicked the bookmark. Instead of the Main Page, I got a message telling me it had an untrusted security certificate. I jumped through all the hoops it held up to get there, only to get the lower-tech, early 2000s version of the Main Page that sometimes comes through when there are technical problems on our end (usually cleared up pretty quickly). I have not been able to get it back yet and this seems to be affecting all Foundation sites.

I suspect the problem is with Firefox (version 31.0, the newest), as the same problem has affected Twitter as well, and I highly doubt they let their certificates lapse. Anyone know anything about this? Daniel Case (talk) 16:09, 20 August 2014 (UTC)[reply]

I'm using 31.0 as well and have had no problems. Black Kite (talk) 17:04, 20 August 2014 (UTC)[reply]

Do the certificates look legit? Max Semenik (talk) 17:18, 20 August 2014 (UTC)[reply]

If you go into more information/details in firefox about the certificate, what are the fingerprints? For reference, the sha1 fingerpint for wikipedia should be 87:A6:CC:C9:08:A0:0B:4F:B0:66:31:B2:4B:24:3F:39:82:FA:E0:30 . Bawolff (talk) 18:12, 20 August 2014 (UTC)[reply]

This is what it's telling me is there as the SHA1 fingerprint: 4E:E3:0C:BB:9D:21:E1:00:C1:06:1C:86:00:59:5A:0F:71:C1:52:81 Daniel Case (talk) 22:52, 20 August 2014 (UTC)[reply]

Seeing they doesn't match, you may be a victim of the Man-in-the-middle attack where a peer tries to intercept your traffic. It happens commonly in workplaces. Try to use another connection or check your computer for viruses. Do not use the connection for online banking. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=460374 Zhaofeng Li [talk... contribs...] 18:46, 22 August 2014 (UTC)[reply]

Well that's interesting... Who's the certificate issued by, issued to, etc? Somebody is certainly spying on your connection, maybe looking at who the cert is issued by will give you a hint if its some web filter sort of thing, or if its actually somebody malicious. Bawolff (talk) 18:58, 22 August 2014 (UTC)[reply]

The "2001 version" is what happens when the CSS files don't load. Did you try it with other browsers? Other internet connections? It could be a restriction placed on your network. KonveyorBelt 18:27, 20 August 2014 (UTC)[reply]

It's fine with other browsers. I'm using Chrome to edit right now. And IE has checked out fine. But Firefox is still screwing me over. Daniel Case (talk) 19:21, 20 August 2014 (UTC)[reply]

From the menu bar, try Tools → Options → Advanced → Network. In that, go for: Cached Web Content → Clear Now (this may take several minutes) and then: Offline Web Content and User Data → Clear Now (this also may take several minutes). Then go back to the problem page and Ctrl+F5. --Redrose64 (talk) 20:56, 20 August 2014 (UTC)[reply]

Did all that ... no change. Daniel Case (talk) 22:58, 20 August 2014 (UTC)[reply]

I guess everyone lost interest in this one? I'm still having the issue. Daniel Case (talk) 16:24, 22 August 2014 (UTC)[reply]

Not necessarily lost interest... I'm out of ideas, and I suspect other people may be too. --Redrose64 (talk) 18:14, 22 August 2014 (UTC)[reply]

Its probably because firefox is detecting someone is intercepting the connection (aka MITM attack), and is refusing to load stylistic information as a security precaution. Bawolff (talk) 18:58, 22 August 2014 (UTC)[reply]

Problem solved: That was it. I just purged a bunch of crapware my son had unknowingly installed in the last couple of days. It's back to normal. I am getting the right fingerprint. Never mind ... Thanks everyone. Daniel Case (talk) 04:24, 23 August 2014 (UTC)[reply]

I use Firefox (version 31.0) and haven't had a bit of trouble with anything. In fact, some bothersome kinks in the prior version (after the massive redesign that made me unhappy) have been remedied. So I'm back to my old happiness level with it. Maybe something about your security settings? (Just a guess as I'm no Firefox guru.) Or uninstall and reinstall? Parabolooidal (talk) 18:28, 22 August 2014 (UTC)[reply]

Google showing wrong title in search results

If I google "Leader of ISIS," Abu Bakr al-Baghdadi (expelled) is the third result. Similarly Saint Charles Preparatory School, Columbus is a result for "Saint Charles Preparatory School." The words "expelled" and "Columbus" do occur in each respective article. Maybe there isn't much we can do but let Google know. Mark Schierbecker (talk) 07:04, 21 August 2014 (UTC)[reply]

Probably a Google indexing problem, which presumably will be fixed when Google next reindexes the pages. Not sure what caused it though as the titles displayed in the Google results appear never to have been the titles of Wikipedia articles.--ukexpat (talk) 19:59, 21 August 2014 (UTC)[reply]

https://support.google.com/webmasters/answer/35624?hl=en says: Google's generation of page titles and descriptions (or "snippets") is completely automated and takes into account both the content of a page as well as references to it that appear on the web. ... If we’ve detected that a particular result has one of the above issues with its title, we may try to generate an improved title from anchors, on-page text, or other sources. {{Al-Qaeda}} has an unpiped link saying "Abu Bakr al-Baghdadi (expelled)". {{Roman Catholic Diocese of Columbus}} has a piped link saying "Saint Charles Preparatory School, Columbus". Navboxes are displayed on many pages which probably makes them more likely to influence Google. Wikipedia uses the page name in the html title tag but I guess Google can still consider other factors, although I'm a little surprised they also used an unpiped title. It the page name had been the full html title then maybe Google would be more likely to use it, but we say <title>Abu Bakr al-Baghdadi - Wikipedia, the free encyclopedia</title>. Once Google decides not to include "Wikipedia, the free encyclopedia" on every page, they may be more likely to make other adaptations. I don't think we should change anything or contact Google. PrimeHunter (talk) 22:38, 22 August 2014 (UTC)[reply]

Okie dokie. Thanks for the info. Mark Schierbecker (talk) 20:17, 23 August 2014 (UTC)[reply]

My bad

Today I unintentionally damaged an article with this edit. I take responsibility for the error, for not reviewing my edit properly, yet I wonder if a technical bug exists as well. Currently I have been experiencing issues with my internet connection. In this example the page never fully loaded yet it allowed me to change and save the half loaded page as if I had removed the missing portions. It seems to me that the system shouldn't accept a request to save changes until the page, or section, has fully loaded. I will appreciate seeing any replies. Thank you.—John Cline (talk) 15:39, 21 August 2014 (UTC)[reply]

It shouldn't. Incoming, there will be a field missing then, causing an error. On save there should also be checks. Pondering. do you perhaps have wikEd or a live preview/edit script enabled ? —TheDJ (Not WMF) (talk • contribs) 19:16, 21 August 2014 (UTC)[reply]

I have pop-ups enabled if that is a factor.—John Cline (talk) 09:20, 22 August 2014 (UTC)[reply]

John, do you remember whether you were editing a single section or the whole page? WhatamIdoing (talk) 00:42, 24 August 2014 (UTC)[reply]

I was editing the whole page.—John Cline (talk) 13:48, 25 August 2014 (UTC)[reply]

There are two ways to send information about changes back to the server: one is to send just the lines that you've changed (and enough stuff around them to make it possible to resolve edit conflicts) and the other is to send the whole page back. In the second case, if your connection got cut halfway through, then perhaps (I think?) it might assume that you'd intentionally removed all the "missing" lines.

User:Jdforrester (WMF), do you think that's what's happening? If so, I'd like to talk to you about changing that process, so that even if you edit the whole page, only the lines that are being changed need to be sent back. Whatamidoing (WMF) (talk) 18:25, 25 August 2014 (UTC)[reply]

That's probably pointless (at least in the context of this issue). Like TheDJ said, MediaWiki already sends some "markers" at the end of the article text, which make it impossible to save an edit if the text was "cut off" in transit. This must have been caused by some bizarre accidental click or a browser bug (or computer pixies). If it's not reproducible, I don't think anyone should spend too much time investigating it – the likelihood of figuring out the problem looks really, really low :) Matma Rex talk 18:33, 25 August 2014 (UTC)[reply]

But it might make saving the page faster, if the wikitext editor wasn't sending the entire text back when only a couple of lines were changed. Whatamidoing (WMF) (talk) 19:34, 26 August 2014 (UTC)[reply]

Letter petitioning WMF to reverse recent decisions

The Wikimedia Foundation recently created a new feature, "superprotect" status. The purpose is to prevent pages from being edited by elected administrators -- but permitting WMF staff to edit them. It has been put to use in only one case: to protect the deployment of the Media Viewer software on German Wikipedia, in defiance of a clear decision of that community to disable the feature by default, unless users decide to enable it.

If you oppose these actions, please add your name to this letter. If you know non-Wikimedians who support our vision for the free sharing of knowledge, and would like to add their names to the list, please ask them to sign an identical version of the letter on change.org.

-- JurgenNL (talk) 17:35, 21 August 2014 (UTC)[reply]

In the interest of NPOV, where can we sign a petition supporting the Foundation if we have an opposite point of view from German chapter? --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 07:14, 22 August 2014 (UTC)[reply]

@Piotrus: You'll have to start another page for that. The page he links to is just an open letter he is asking for signatures on. Zell Faze (talk) 00:08, 26 August 2014 (UTC)[reply]

Wrong footer link

At the mobile website https://en.m.wikipedia.org/wiki/Main_Page there are links to the terms of use and to the privacy policy. The terms of use link goes to the mobile website whereas the privacy policy link goes to the desktop website. Shouldn't both point at the mobile website? --Stefan2 (talk) 22:20, 22 August 2014 (UTC)[reply]

And if you manually open mobile version of privacy policy, the "In other languages" template is quite ugly (compare with the terms of use one, which is good).--fireattack (talk) 00:08, 24 August 2014 (UTC)[reply]

You just answered Stefan2's question :) The privacy policy page has a lot of complex text & templates that weren't formatted with mobile in mind; it and several other pages like it on WMF wiki are currently set to display in desktop-only. We do hope to reformat those pages in a more mobile-friendly way at some point in the not-too-distant future, but until then the desktop view is actually a bit more readable. Cheers, Maryana (WMF) (talk) 16:51, 25 August 2014 (UTC)[reply]

Interestingly, if I visit foundationwiki using my phone instead of using my computer, immobile foundationwiki automatically redirects to mobile foundationwiki, so I end up on the mobile version anyway. --Stefan2 (talk) 18:06, 25 August 2014 (UTC)[reply]

Edit conflict?

The past day or so, I have received the "edit conflict message" almost every post I have written. When I then cancel editing and look at the page in question, it turns out that my edits have been saved. Is this a problem on my side, or does anyone else see it? YohanN7 (talk) 07:37, 23 August 2014 (UTC)[reply]

I have encountered that maybe half a dozen times, which was maybe 25% of my edits. HiLo48 (talk) 08:06, 23 August 2014 (UTC)[reply]

Specific examples (diffs of articles where this happened) plus browser information welcome. --AKlapper (WMF) (talk) 13:48, 23 August 2014 (UTC)[reply]

I have had the same problem, quite often. --P123ct1 (talk) 11:09, 24 August 2014 (UTC)[reply]

I get it occasionally - when I think I've saved my edit, but nothing happens for a while, I some times try again, and I some times get this. I don't think I've gotten it under other circumstances. עוד מישהו Od Mishehu 12:18, 24 August 2014 (UTC)[reply]

I've mentioned this before. See [2]. Dougweller (talk) 12:46, 24 August 2014 (UTC)[reply]

Are the Wikimedia projects affected by the over one billion stolen passwords?

Are the Wikimedia projects affected by the over one billion stolen passwords reported by The New York Times on 5 August 2014 in the article "Russian Hackers Amass Over a Billion Internet Passwords"? --Bensin (talk) 15:09, 23 August 2014 (UTC)[reply]

I've seen nothing in staff e-mail about this, so I assume that the answer is "no". If I'm wrong, then I expect it to be announced promptly. Whatamidoing (WMF) (talk) 00:48, 24 August 2014 (UTC)[reply]

@Whatamidoing (WMF): Thank you for answering. Considering the vast amount of passwords, can the WMF make a statement whether Wikimedia projects are affected or not? (As opposed to "passive" silence.) --Bensin (talk) 10:05, 24 August 2014 (UTC)[reply]

I'm fairly sure that I'd have heard about it, and to my knowledge we have no such password breach. Philippe Beaudette, Wikimedia Foundation (talk) 19:34, 24 August 2014 (UTC)[reply]

I believe that Philippe's "fairly sure" is pronounced "if a password breach is discovered, and no one promptly informed the Legal and Community Advocacy team, then heads will roll".

(LCA has to deal with legal compliance about data and privacy protection.) Whatamidoing (WMF) (talk) 18:11, 25 August 2014 (UTC)[reply]

I'm skeptical the breach even took place or was anywhere close to the reported scale. See schneier on the subject or here for another pretty convincing skeptical take. Protonk (talk) 15:01, 27 August 2014 (UTC)[reply]

iPhone app bugs

Where's the proper place to report bugs with the new iPhone app? For example, on Batman: Assault on Arkham,

the title of the article is not italicized
the {{track listing}} table has a few empty blank fields

Thanks! GoingBatty (talk) 15:20, 23 August 2014 (UTC)[reply]

Hey GoingBatty. You can report bugs in the apps on Bugzilla in the Wikipedia App product. As to the specific issues you mentioned, the first issue you mentioned is documented in bugzilla:67492. The second is a general issue that we're having with tables that we've not found a good solution to yet. Many tables are defined in such a way that they only really display properly on desktop. Short of rewriting every table on every single Wikipedia to be more mobile friendly (which would take years), we're having to implement little hacks on a case-by-case basis to try to make tables display sensibly, so it's not surprising that you found a table that displays suboptimally. Thanks for reporting these issues. --Dan Garry, Wikimedia Foundation (talk) 16:12, 23 August 2014 (UTC)[reply]

Standalone version of meta:WikiMiniAtlas or alternative?

I'm not sure if this topic suits here. If not, feel free to move it.

To me, meta:WikiMiniAtlas is a great tool to check available Wikipedia articles based on map/location, especially when Google Maps removed Wikipedia layer since 2013. But as now, it's just a small tool and you need to open a random page (with location/GEOCODE) to active it which is somehow annoying. Is there any standalone version of this tool, or similar tool/website like it? Thanks. --fireattack (talk) 00:04, 24 August 2014 (UTC)[reply]

Article traffic statistics incorrect

From Wikipedia article traffic statistics:

Air_France_Flight_447 has been viewed 33794 times in the last 30 days. This article ranked 48 in traffic on en.wikipedia.org.

France has been viewed 276676 times in the last 30 days. This article ranked 234 in traffic on en.wikipedia.org.

Something obviously wrong here. 86.130.67.100 (talk) 01:36, 24 August 2014 (UTC)[reply]

It is not wrong, because the statement "This article ranked X in traffic on en.wikipedia.org." covers views over a long period of time, as opposed to the current views shown, which cover the last 30 days. 2Flows (talk) 12:00, 24 August 2014 (UTC)[reply]

The wording is wrong then. With the current wording/presentation, it is obvious that one will assume the ranking is based on the data that has just been given. It should say something like "This article ranked 48 in traffic on en.wikipedia.org, based on [explain criteria]". 86.151.119.38 (talk) 13:14, 24 August 2014 (UTC)[reply]

The rank appears to be based on http://stats.grok.se/en/top which currently says "Most viewed articles in 201403". It's an external tool controlled by a user who can be contacted at User talk:Henrik, but he doesn't always reply. PrimeHunter (talk) 00:49, 25 August 2014 (UTC)[reply]

Contributions Ranking

Is any tool available on English wikipedia which is tell about specific user's rank by contributions? This tool only shows top 50 users by contributions.Prateek Malviya^•✉•✎ 10:40, 24 August 2014 (UTC)[reply]

WP:TOP5000 and WP:TOP10000 are probably what you're looking for. 2Flows (talk) 11:58, 24 August 2014 (UTC)[reply]

Is below 10000 rank list is not available? I have 1300 contribution.Prateek Malviya^•✉•✎ 00:51, 25 August 2014 (UTC)[reply]

Nope, there are no lists that go below the top 10,000. Graham87 01:48, 25 August 2014 (UTC)[reply]

Ok! thanks for information.Prateek Malviya^•✉•✎ 03:55, 25 August 2014 (UTC)[reply]

Footnote problem

I am having great difficulty with a set of footnotes in Islamic State of Iraq and the Levant. I have tried several times to repeat these footnotes in another section, but each time it fails, and I cannot see where the problem is. I have used the "ref name" method, which I have never had a problem with before.

The set of footnotes appears at the end of the sentence "... as a terrorist organization." in the first paragraph of the Lead. I need to repeat them at the end of the sentence ending "... have called IS a terrorist organization." in section 13, "Designation as a terrorist organization". I have added <ref name="Name"> to the first cite and <ref name="Name"/> to the second cite. This is the set as it appears in the Lead (several "/>" ref"s as those footnotes appear several times in the article (see "References"):-

<ref name="TranTop">...<ref name="ListerTop"/>...<ref name="McCoyTop"/>...<ref name=”CoughlinTop”>...<ref name=”IranTop”>.

Every time I save after inserting the set in section 13 in this way:

a red "cite error" message appears, and I cannot see where I am going wrong. Can someone help, please? --P123ct1 (talk) 11:05, 24 August 2014 (UTC)[reply]

In the references you added to the last section, the reused "TranTop" reference should be <ref name="TranTrop"/>. An opening tag in XML (e.g. <ref name="foo">) needs to be closed by a corresponding closing tag (e.g. </ref>); an "empty" tag such as <ref name="foo" /> (note the slash) doesn't. SiBr₄ (talk) 12:02, 24 August 2014 (UTC)[reply]

See WP:REFNAME for details on using a source more than once. -- Gadget850^talk 12:11, 24 August 2014 (UTC)[reply]

I obviously overlooked that I had not put in the slash in the second "TranTop" reference. I checked and double-checked, but still managed to miss it! --P123ct1 (talk) 12:21, 24 August 2014 (UTC)[reply]

I think it's because someone used unicode quotes to name the refs, and the parser includes them in the ref name (as normal quotes are optional). Now when I replaced the quotes with proper ones, I could save it without an error [3]. 2Flows (talk) 12:17, 24 August 2014 (UTC)[reply]

I see what happened now, and what you mean by "unicode" and "normal". I had seen this problem in wikitext before, but didn't think to check it in this instance. Thanks very much for adjusting those footnotes. --P123ct1 (talk) 12:52, 24 August 2014 (UTC)[reply]

(edit conflict) I've previewed the page with the ” marks (the ones 2Flows calls "Unicode quotes") instead of the "proper" " quotes, and it does cause cite errors. The "Unicode" quotes are not included in the ref name, however; the "name" parameter is just omitted entirely and a "malformed or bad name" error is given. These errors should be fixed if all ” quotes are converted to "s. SiBr₄ (talk) 12:57, 24 August 2014 (UTC)[reply]

Thanks, SiBr₄, I understand it all now. I have inserted that second set of footnotes successfully now. I struggled to understand why the wikitext looked exactly the same for both of them, but I see now the difference only show up in the diffs. Is there any way of doing a global conversion of the unicode ” marks to the " marks in the wikitext of this article? I have seen people do it piecemeal, but there must still be a lot of unicode versions still there. --P123ct1 (talk) 13:50, 24 August 2014 (UTC)[reply]

@P123ct1: At the far right of the "Advanced" toolbar above the edit window, there is a handy find&replace tool that will help replace all occurrences of the ” character in a single article. SiBr₄ (talk) 13:58, 24 August 2014 (UTC)[reply]

@2Flows, P123ct1, and SiBr4: All quotemarks are Unicode; the "normal" double quote - that I've used in this sentence - is at Unicode code point U+0022. The usual terms are straight/curly, or typewriter/typographic, see MOS:QUOTEMARKS#Quotation characters. Curly quotes are U+201C (opening) and U+201D (closing). There's also a character which looks like there, but is different again: the double prime U+2033. Always use the straight (or typewriter) kind.

But there was another problem, unrelated to quotemarks, in this edit: the first ref, <ref name="TranTop"> was unclosed. The next two were fine; the last two had the wrong quotation character (U+201D instead of U+0022). --Redrose64 (talk) 14:24, 24 August 2014 (UTC)[reply]

@Redrose64: Yes, I commented on how I had forgotten to close the ref in "TranTop". I was puzzled when there were still problems after I did close it, but all has been resolved now. "Straight" and "curly" is much more easily understandable! Is it safe to do a global search&replace to replace all "curly"s with "straight"s in this article? Are there any pitfalls or unforeseen problems to watch out for? --P123ct1 (talk) — Preceding undated comment added 14:40, 24 August 2014 (UTC)[reply]

@P123ct1: Yes, a replacement of curly quotes with straight ones would be completely safe. Graham87 01:44, 25 August 2014 (UTC)[reply]

@Graham87:: I will have to find out the combination of keys for a curly quote mark as it is not on my keyboard. Can I use that with the search&replace tool on the "Advanced" edit strip on the edit page, or will it only work with normal keyboard letters? Do you know what combination of keys Windows 7 gives a curly quote mark? I am having difficulty finding out. --P123ct1 (talk) 07:59, 25 August 2014 (UTC)[reply]

@P123ct1: To type curly quotes, hold the alt key and type 0147 on the num pad (for “) and 0148 (for ”) 2Flows (talk) 08:09, 25 August 2014 (UTC)[reply]

It doesn't work on my keyboard, but thanks. I'll ask at the Computing Reference desk. --P123ct1 (talk) 08:30, 25 August 2014 (UTC)[reply]

@P123ct1: Easier is to just select one from the page (or from this thread) and copy-paste it into the search&replace box. SiBr₄ (talk) 10:53, 25 August 2014 (UTC)[reply]

@SiBr4: Why on earth didn't I think of that? My brain isn't working! --P123ct1 (talk) 11:01, 25 August 2014 (UTC)[reply]

Wikiblame search history tool

Lately this tool sometimes does not work. Sometimes when the search seems to have ended, there is no result; the search has not completed, as there is no "found at" message. Sometimes it says "not found" at the end of a search, but I have put the search to start from the current date and go back, and even on maximum "500", which is way earlier than the date I know the words searched were inserted, it says "not found". I have been using the binary method. Is the tool faulty? --P123ct1 (talk) 11:44, 24 August 2014 (UTC)[reply]

Where to find that tool so I could try to reproduce? --AKlapper (WMF) (talk) 15:24, 24 August 2014 (UTC)[reply]

If you go to the "View history" pages of an article, it says "Revision history search" at the top. Click on that and it brings you to the Wikiblame tool. --P123ct1 (talk) 18:08, 24 August 2014 (UTC)[reply]

Have you had success with it in the past? I've never been able to get useful information out of it. WhatamIdoing (talk) 18:15, 25 August 2014 (UTC)[reply]

Yes, but it is a bit hard to understand how it works. I don't understand the lines in blue at the bottom, which say "Search", for example - does that mean I must search? etc. Really it only works half of the time. Hedonil has come up with a brilliant new "Search history" tool, much better, though it hasn't been working lately, but should be up and running again soon. [4]. The link for this gadget is =. --P123ct1 (talk) 01:30, 26 August 2014 (UTC)[reply]

Script errors

The article Karnataka is littered with script errors stating "The time allocated for running scripts has expired." This is a featured article, and has only recently begun transcluding {{error}}s. Has a recent module change caused this? Help with debugging from Lua experts would be appreciated. Thanks, Wbm1058 (talk) 12:56, 24 August 2014 (UTC)[reply]

Oh, I see: Help:Lua debugging #Occasional timeout errors. It appears that Lua may be "tired". Wbm1058 (talk) 13:01, 24 August 2014 (UTC)[reply]

A dummy edit to force the replacement of the page with a clean Lua run did not solve the issue. Wbm1058 (talk) 13:16, 24 August 2014 (UTC)[reply]

Module:Citation/CS1 doesn't like the question mark that is part of the url like this one http://books.google.com/books?id=jPR2OlbTbdkC&pg=PA757#v=onepage&q=&f=false when it's used as part of |page=. Working on a solution.

—Trappist the monk (talk) 13:45, 24 August 2014 (UTC)[reply]

I've reverted the module to the March 30 version in the meantime; the script errors in Karnataka are now gone. If anyone notices them on other pages then purging the page should fix it. — Mr. Stradivarius ^{♪ talk ♪} 13:53, 24 August 2014 (UTC)[reply]

Current version of the module with the function get_coins_pages () disabled while I noodle out what's wrong.

—Trappist the monk (talk) 14:06, 24 August 2014 (UTC)[reply]

@Trappist the monk: If you want to preview how Karnataka looks with the module sandbox, you might find User:Jackmcbarn/advancedtemplatesandbox.js useful. — Mr. Stradivarius ^{♪ talk ♪} 14:09, 24 August 2014 (UTC)[reply]

I believe that the problem is fixed. The function get_coins_pages() strips urls from the |page= parameters so that these urls don't corrupt the COinS metadata. get_coins_pages() uses string.match to create a pattern that it then feeds to string.gsub which replaces the pattern in the |pages= value with a null string. The problem is that the pattern used by string.gsub isn't a literal string so the Lua magic pattern characters are treated as magic characters. I've added pattern = pattern:gsub("([%^%$%(%)%%%.%[%]%*%+%-%?])", "%%%1"); which escapes the magic characters.

This fix has been made to the sandbox code but not to the live code. The fix will be applied to the live code at the next update whenever that occurs.

The offending CS1 citation now works properly:

Jain, Dhanesh; Cardona, George (2003). Jain, Dhanesh; Cardona, George (ed.). The Indo-Aryan languages. Routledge language family series. Vol. 2. Routledge. p. 757. ISBN 0-7007-1130-9.{{cite book}}: CS1 maint: multiple names: editors list (link)

It's good that this citation showed up the problem because it shouldn't have. The book doesn't have preview at Google books so the url as part of |page= is unnecessary and misleading.

—Trappist the monk (talk) 15:31, 24 August 2014 (UTC)[reply]

Thanks Ttm for the link. This was the problem I had with the Ultra article before I identified the editor problem (see here). Google books access is not static, access rights vary from country to country and also from time to time -- which is why it is better to use the Internet Archive site for those books that are in the public domain and have a copy on their site. -- PBS (talk) 11:42, 26 August 2014 (UTC)[reply]

Find & replace tool

@SiBr4:: Unfortunately, for some reason the find&replace tool you mentioned in "Footnote problem" above doesn't work on my laptop in either IE11 or Firefox and Windows 7. I have asked the VP HD about it, but the query was never resolved. I can't look it up in the archives as I cannot remember the name I gave the query. Basically, when doing a manual search&replace, the box sits in the middle over the text, so I cannot see if it is hiding a found word as the page scrolls down, and if I move the box to the side, the box disappears upwards as the page scrolls down on subsequent finds. Also, after the first find, it doesn't always highlight the subsequent words. Is the problem at my end? --P123ct1 (talk) 14:27, 24 August 2014 (UTC)[reply]

The archived thread is /Archive 129#Search & Replace tool. The tool works fine for me; it does hide highlighted words sometimes, but it stays in the same place unless I'm moving it myself (Win 7, FF 31.0). SiBr₄ (talk) 14:39, 24 August 2014 (UTC)[reply]

I see what I have been doing wrong now. It does work. --P123ct1 (talk) 18:03, 24 August 2014 (UTC)[reply]

Is "Email this user" on the blink?

Is there a known current problem with the server handling email to users? Someone who tried to send mail to me got their message bounced back even though my registered email address is correct and working correctly. Roger (Dodger67) (talk) 17:41, 24 August 2014 (UTC)[reply]

I am the user who attempted to send an email message to Roger. I received a bounce-back error message from the Wikimedia email server, which I would be happy to forward to someone if it would help. Dirtlawyer1 (talk) 17:43, 24 August 2014 (UTC)[reply]

@Dodger67 and Dirtlawyer1: If the sender's email address is one from Yahoo, these have been bouncing for some weeks now. I believe that in the last few days, a similar problem has affected mails where the sender's email address is one from gmail. See e.g. Wikipedia:Village pump (technical)/Archive 127#email, Wikipedia:Village pump (technical)/Archive 129#Gmail labelling Wikipedia email suspicious --Redrose64 (talk) 09:58, 25 August 2014 (UTC)[reply]

Yes, mine is a Yahoo address. And, I had problems sending email through the Wikimedia system a couple of weeks ago, too. Dirtlawyer1 (talk) 10:01, 25 August 2014 (UTC)[reply]

I'm a Gmail user, I do remember getting one Wikimedia mail that was tagged as possible spam, but since I "untagged" it as "not spam" others have arrived without problem - except for Dirtlawyer's one. Roger (Dodger67) (talk) 10:41, 25 August 2014 (UTC)[reply]

With regard to Yahoo there is bugzilla:56414 but I am also aware of DMARC policy issues with Microsoft mail services (Hotmail etc). bugzilla:46640 and bugzilla:56413 need to get fixed (and are being worked on) to solve the underlying problem. --AKlapper (WMF) (talk) 11:42, 25 August 2014 (UTC)[reply]

plainrowheaders

I have a question: when the plainrowheaders class should be used for tables (with the scope="col" and scope="row")? --Edgars2007 (talk/contribs) 18:59, 24 August 2014 (UTC)[reply]

It is just a layout preference. You can read more here Wikipedia:Manual of Style/Accessibility/Data tables tutorial#Layout of table headers. 2Flows (talk) 19:18, 24 August 2014 (UTC)[reply]

Thanks. --Edgars2007 (talk/contribs) 20:33, 24 August 2014 (UTC)[reply]

What on Earth?

I found one of my tabs was on the following url (without the ellipsis of course)

http://lookup-api.apple.com.edgesuite.net/en.wikipedia.org/wiki/Wikipedia:...

This looks potentially nasty, as it appears to funnel everything through that host - including passwords, tokens, cookies etc.

Edge suite is a content platform from Akamai Technologies.

Any more info? All the best: Rich Farmbrough, 22:15, 24 August 2014 (UTC).

@Rich Farmbrough: Do you remember what page were you browsing before you found yourself at that URL? My guess is that it's a link from an outside website, but it's hard to know without more details. — Mr. Stradivarius ^{♪ talk ♪} 02:16, 25 August 2014 (UTC)[reply]

I was cleaning up browser tabs, some of which have been open since March 2013, so the chance of me remembering is slight. Thanks for the suggestion, though! All the best: Rich Farmbrough, 02:42, 25 August 2014 (UTC).

My first guess would be Apple's Dictionary app, but it really is a guess —TheDJ (Not WMF) (talk • contribs) 08:57, 25 August 2014 (UTC)[reply]

CSD log

Dear editors: Because there are so many things to know about Wikipedia, and some of the instruction pages are so long and complicated, it's easy to miss things. I had no idea of the existence of the Twinkle CSD log until after I became and admin and started seeing other editor's logs listed in the "What links here" of pages I was planning to delete. Do I need one? Is there a tool that creates a retroactive CSD log? —Anne Delong (talk) 01:00, 25 August 2014 (UTC)[reply]

You don't need to have one, and there isn't a tool to create one retroactively. You can enable your CSD log in your Twinkle settings for pages you tag in the future, but the only way to have it cover pages that you have already tagged is to add them manually. — Mr. Stradivarius ^{♪ talk ♪} 02:10, 25 August 2014 (UTC)[reply]

Thanks, Mr. Stradivarius. —Anne Delong (talk) 02:36, 25 August 2014 (UTC)[reply]

"bgcolor" issue

Tracked in Phabricator
Task T68413

A few months ago, I put a question before the VPT asking why the Wiki markup bgcolor="#XXXXXX" was no longer working on mobile devices. An explanation was given and an alternative markup, style=background-color:"#XXXXXX" was given. I have since applied this to some articles, but recent discussions with other users have revealed the scope of the problem.

I tend to limit my editing to a select subset of pages, namely those related to Formula 1. This bgcolor issue affects sixty season articles, over a thousand driver articles, fifty or more team articles, and dozens of car articles. And that's just Formula 1 - apply it to every form of motorsport and related article, and the tally quickly runs into the tens of thousands. I cannot even begin to fathom where else this markup might be used regularly, much less the volume of affected articles.

This is an issue that only affects mobile users; PC browsers, as far as I am aware, are fine. But we at the Formula 1 WikiProject tend to try and edit in such a way that we accommodate both regular and mobile users (if these needs conflict, regular users get priority). As such, I'm here to lobby for recognition that this is (potentially) a Wiki-wide problem, and to try and come up with some solutions from the community, most likely in the form of a bot. Prisonermonkeys (talk) 05:07, 25 August 2014 (UTC)[reply]

This is a long standing issue, but it is discussed at a software level. One potential solution is that "bgcolor", while obsolete in HTML, will remain valid in wikitext and would automatically be converted to CSS, so that it works on all platforms. -- [[User:Edokter]] {{talk}} 07:52, 25 August 2014 (UTC)[reply]

See also the past RfC at VPR, and this archived VPT thread. Also, the CSS markup above should be style="background-color:#XXXXXX". SiBr₄ (talk) 11:11, 25 August 2014 (UTC)[reply]

I didn't notice the mentioned VPT thread was also opened by you. Nevertheless, it's good to have a link to it here. SiBr₄ (talk) 11:30, 25 August 2014 (UTC)[reply]

@Edokter: @SiBr4: Do you think there's likely to be any site-wide solution/action on this within, say, the next couple of months? (Given the fact that it's a "long standing issue" and the bugzilla bug hasn't been updated since mid-June, my guess is no). Because if not, the Formula One WikiProject might consider implementing a local solution, e.g. getting a bot to go through and update the markup for all the articles within the project's scope. DH85868993 (talk) 22:13, 25 August 2014 (UTC)[reply]

Cite templates

I sometimes clean up footnotes and notice that some have "author" instead of "last name/first name". Are those formed using an old template? If so, could it be removed, please, so that references always come out with author surname first, comma, first name last? It seems some editors have that old template as default.. Perhaps it is not as simple as that. --P123ct1 (talk) 08:35, 25 August 2014 (UTC)[reply]

No, it's not as simple as that. If we were to remove the parameter, we would need to convert all the existing transclusions to use the |first= and |last= parameters, and that can't be done reliably by a bot. It's hard for a computer to work out whether the author is "Last, First" or "First Last" (especially if someone has forgotten to include the comma). There are also a lot of names that could be ambiguous. For example, it's easy for a human to look at "Ludwig van Beethoven" and see that it should be "Beethoven, Ludwig van" rather than "van Beethoven, Ludgwig", but that task is not easy for a computer. So if we did want to remove the |author= parameter we would have to do it by hand. — Mr. Stradivarius ^{♪ talk ♪} 10:01, 25 August 2014 (UTC)[reply]

@P123ct1: It's not an old template but a permitted parameter alias. Sometimes, as with names like Ban Ki-moon, the family name comes first, and the given name last. These should always be given as |author=Ban Ki-moon because |first=Ban |last=Ki-moon puts the family name into the given name parameter (and vice versa), whereas |last=Ban |first=Ki-moon would add an undesirable comma. Then there are also cases where a split would always be incorrect, such as corporate authors. There has been plenty on this on other discussion pages e.g. Template talk:Citation/Archive 6#Lastname, Firstname. --Redrose64 (talk) 10:26, 25 August 2014 (UTC)[reply]

Thanks. Hadn't thought about the Ban Ki-moon problem and foreign names where surnames come first. I wonder how those whose cite templates have last name/first name cope with that. I hope they see sense and put it all in one or the other. --P123ct1 (talk) 10:58, 25 August 2014 (UTC).[reply]

'author' is an alias for 'last' so there really is not an issue. -- Gadget850^talk 12:32, 25 August 2014 (UTC)[reply]

Here's a link to the template documentation for cite book about this parameter. If you are interesting in cleaning up author names in footnotes. One error that lands pages in Category:Pages containing cite templates with deprecated parameters is deprecated use of "coauthors". Many thousands of pages need fixing here. The names in "coauthors" should instead use the last/first system. Jason Quinn (talk) 20:43, 26 August 2014 (UTC)[reply]

Tech News: 2014-35

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

VisualEditor news

There was a error when you put your cursor directly after a reference list. It is now fixed. [5]
You can now add colors to links in the editor using gadgets. You can do this to see links to redirects or disambiguation pages. [6]
If you use Internet Explorer, you will soon be able to use VisualEditor. [7] [8] [9]

Future software changes

The latest version of MediaWiki (1.24wmf18) is on test wikis and MediaWiki.org since August 21. It will be on non-Wikipedia wikis on August 26, and on all Wikipedias on August 28 (calendar).
After August 26, you will have a central JavaScript and CSS page. They will be on Meta-Wiki and will work on all wikis. Read more on the help page. [10]

Tech news prepared by tech ambassadors and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

09:21, 25 August 2014 (UTC)

WikiWand, images and blockquotes

File:Night with quote box.jpg

{{Quote box}} has more features, but the images push the text out of the way, and the blockquotes end up paragraphs lower than intended.

I've been looking at some of our articles through WikiWand, and they really do look better, especially with the larger images and the pale-grey blockquotes.

I'm currently trying to edit Night (book) to look more like its WikiWand version. One of the issues I'm struggling with is how to create coloured blockquotes around images using {{quote}} or {{quote box}}. Sometimes they work, and sometimes the quote goes spinning off into weird places, several paragraphs below where I intended it, even splitting paragraphs in two.

Does anyone know how to exercise more control over blockquote placement around images so that we can have different colours, widths and fonts? SlimVirgin ^(talk) 16:05, 25 August 2014 (UTC)[reply]

I installed it because I trust your name, and was disappointed to see that the articles are not current. Thank you for the tip.

But if I use the menu in the header, I can edit via the familiar way, and I was able to see some current changes.

Wow. power projection looks fantastic. --Ancheta Wis (talk | contribs) 16:51, 25 August 2014 (UTC)[reply]

Hi Ancheta, it looks great, doesn't it? (The articles I've looked at have been current, btw). Take a look at List of colors and Ezra Pound. SlimVirgin ^(talk) 17:24, 25 August 2014 (UTC)[reply]

By "coloured blockquotes" do you mean something like {{Centered pull quote}}? -- Gadget850^talk 17:27, 25 August 2014 (UTC)[reply]

{{Quotation}} probably does what you want. WhatamIdoing (talk) 18:23, 25 August 2014 (UTC)[reply]

Gadget, thanks but that produces something different. WAID, {{Quotation}} has the same conflict with images as {{Quote box}} (the former sometimes ends up behind the image, while the latter pushes it out of the way). There is something odd about the way images are displayed on WP and it has caused problems for years. The question is how can we produce blockquotes (and other design features) the way WikiWand does, without these image clashes.

WAID, do you know who is in charge of design for the Foundation? Perhaps we could ping that person for advice. Pinging Missvain, as I know she has talked about design a lot. I'd love to know who we need to ask and what we need to ask for. SlimVirgin ^(talk) 18:34, 25 August 2014 (UTC)[reply]

I think User talk:Jaredzimmerman (WMF) would be the relevant director. User:Jorm is working on Winter, so he's probably the best designer to talk to. There's some work in train (October?) to change the design of all image boxes, but I don't remember who is working on that. Fabrice is probably the PM for it. Whatamidoing (WMF) (talk) 19:49, 26 August 2014 (UTC)[reply]

{{Stack}} may be useful here. -- Gadget850^talk 19:35, 25 August 2014 (UTC)[reply]

And if it is, we could add the functionality into {{quotation}}. -- Gadget850^talk 19:54, 25 August 2014 (UTC)[reply]

Would you be willing to do that, Gadget? (I ask that not knowing how much work it is.) We need to be able to remove the border or change the thickness, change colour, change width – everything that {{quote box}} does. Or else fix quote box so that it doesn't move images. SlimVirgin ^(talk) 20:00, 25 August 2014 (UTC)[reply]

Please don't use {{Stack}}. It's an ugly workaround and needs to be avoided whenever possible. —TheDJ (Not WMF) (talk • contribs) 21:18, 26 August 2014 (UTC)[reply]

@SlimVirgin: you may find some designers on mail:design. Helder 20:33, 25 August 2014 (UTC)[reply]

Many thanks, Helder! SlimVirgin ^(talk) 20:55, 25 August 2014 (UTC)[reply]

Gadget850, as you seem to know what you're doing, could I ask you to help with something?

I am thinking of asking the Foundation formally somewhere (perhaps on Bugzilla, if that's the right place) to create tools for us so that we can create articles that look more like WikiWand.

I first want to make sure that we can't already do it with the tools we have. I've spent hours struggling with Night (book) (particularly Night (book)#Sighet ghettos) to juggle the blockquotes and the images, but I can't get them to sit right. Here is one example of what happens. If you look at the block quote beginning "The barbed wire which fenced us in ..." that is supposed to come after "the windows on the non-ghetto side had to be boarded up." But instead it jumps several paragraphs, and positions itself in the middle of another quote.

Would you mind briefly trying to position the block quotes (with a grey background and no border) in that section with the images, just in case I'm missing something? If you can't manage it, can you tell me what we need to ask the Foundation to create for us, so that this kind of thing can be done relatively easily? SlimVirgin ^(talk) 20:52, 26 August 2014 (UTC)[reply]

BTW. if anyone is bored... There should be some serious weeding/deletion/replacement done in Category:Quotation_templates. About half the templates are duplicates or easily replaceable variants. Really just too many cruft there, what are you supposed to use as a user ? —TheDJ (Not WMF) (talk • contribs) 21:05, 26 August 2014 (UTC)[reply]

Anything that is <blockquote> based should now no longer overlap with images on the mobile site (we might propagate that change into the entire site, it seems like a sane idea, but let's test it on mobile first). Anything that is table based (like cquote variants), should probably be avoided. Also I see you experimented with a few quotes that were left floating, which is probably not what you wanted. You wanted left aligned, that is different than left floating (unfortunately many template params are incorrectly named on this front, so it can be hard to tell without pulling out a web inspector or reading the template code). —TheDJ (Not WMF) (talk • contribs) 21:26, 26 August 2014 (UTC)[reply]

Hi Derek-Jan, my problem (which I share with a lot of editors) is that I can't describe what I want, and I don't understand the language (floating, aligned, blockquote, cquote, table-based). I can only point to the outcome I'd like to achieve, which is the WikiWand look (right), so that I can place blockquotes in text boxes, with borders and no borders, different colours, different widths, where I want to place them, including next to images.

It has been a problem for years on WP that we can't do this. I've often seen editors struggling to try to produce something decent looking. We'd love to be able to write for a professional-looking publication. The typography refresh was great, as are the hovercards and the way thumbnails are shown now without the borders. And I love the look of the mobile site. Allowing us to move images and block quotes around more easily would be wonderful too.

I've written on the gender gap task force page that I see this as an editor-retention – and specifically a gender gap – issue, because I think the fiddly nature of trying to change the look of anything on a WP page is discouraging (for anyone, but I'd say especially for women). So the question is whether the Foundation might be willing to devote some resources to this. Who do we ask, and where, and what should we ask for? Pinging Erik in the hope he can advise. SlimVirgin ^(talk) 23:30, 26 August 2014 (UTC)[reply]

Jumping in to second what SV has said above. I would think that it shouldn't be difficult for block quotes to have background shading and it shouldn't be difficult to have markup to specify whether a blockbox should be left/right aligned. The default for a <blockquote></blockquote> is center aligned, without background shading, and it never center aligns well if an image is in the vicinity (in other words only indents once, when a second indent is required if butting up against an image). If that helps, in terms of SV is trying to say. Victoria (tk) 00:17, 27 August 2014 (UTC)[reply]

SlimVirgin, please have a look at this Old revision of my sandbox and see if that will do approximately what you want. It'd just be a matter of copying and pasting the ugly div line before every block quote, and typing the closing div tag at the end. It's not perfect: I don't know how to make the blocks automatically full-width when nothing is on the right hand side, or to make them narrower when there is no text filling the full width (instead, they're all set to the width that seems to work if there's a regular-width image on the right-hand side; you can manually change that by adjusting the "20em" in the right margin code). However, I think it might be a little closer than what you've got, and perhaps someone else will be able to improve on it.

If you want more 'air' around the quotations (to have them indented more, either left or right), then that would be easy to add. WhatamIdoing (talk) 05:58, 27 August 2014 (UTC)[reply]

I'm not SV, but decided to reply here anyway. For those of us who work here as volunteers writing content, and particularly for those of us who write about literature, blockquotes are almost impossible to avoid, yet most of us know that they're ugly and hard to format. I'd think it wouldn't be difficult to create a blockquote template with an option to align left, right or center, that would highlight the quote with background shading, that gives and option to change the color, and an option to change the width accordingly - necessary when in the vicinity of an image. We have a gazillion templates that do all kinds of things in article space and in talk space - right down to wikibreak and barnstar templates - yet something that's really a necessity in many many articles is lacking. It is discouraging to see that Wikiwand formats these so nicely but it's so hard for us to do here with the existing UI. Victoria (tk) 19:15, 27 August 2014 (UTC)[reply]

WhatamIdoing, thank you so much for this – your sandbox looks exactly like the thing I was trying to achieve. I'll take some time today to try to apply it to the whole article.

As Victoria says, for people writing content it's really hard to find the technical help if we don't know how to write code ourselves, or know how to choose between the various templates. It seems – for the most part (with apologies to the exceptions) – that WP volunteers with technical skills have not focused on design, and editors who care about the look of pages may not have the technical background. The question is how we can encourage the Foundation to bridge the gap so that all editors have access to tools to make pages look good. SlimVirgin ^(talk) 19:55, 27 August 2014 (UTC)[reply]

The main problem with the approach taken by WhatamIdoing at 05:58, 27 August 2014 is that the chosen dimensions might not suit everybody's setup. The blockquote is constrained to avoid the images by setting its right margin to 20em; but are the images necessarily 20em (or just under) wide? If they're |thumb images, they might be anything from 120px to 300px wide (depending on the setting at Preferences → Appearance), plus the frame that goes with a |thumb image. The relationship between dimensions measured in em and those measured in px is inexact, and depends on several factors ranging from the hardware characteristics to the installed fonts. --Redrose64 (talk) 23:52, 27 August 2014 (UTC)[reply]

Islamic State of Iraq and the Levant

I think something may have gone wrong with the "View History" pages on this article. I made a revert at 16.07 ~~c.4.09~~ UTC today which showed up in the text and is listed on the "View History" page. Since then I have been reverted, but there is absolutely no record of this on the "View history" page. What can have happened? --P123ct1 (talk) 17:53, 25 August 2014 (UTC)[reply]

My revert disappeared at 17.09 UTC on an edit by TimIsTimIs which was not a revert. He joined Wikipedia on 23rd August and I wonder if he mistakenly did his edit on an earlier version of the page and saved that version. --P123ct1 (talk) 18:29, 25 August 2014 (UTC)[reply]

Other people's edits have been lost as well. --P123ct1 (talk) 18:48, 25 August 2014 (UTC)[reply]

@P123ct1: What happened is that TimIsTimisTimIsTim (talk · contribs) went to the last version that they had personally saved, the one of 21:45, 24 August 2014, and edited that. Upon saving their change, it effectively wiped out all intervening changes. See this diff. --Redrose64 (talk) 19:59, 25 August 2014 (UTC)[reply]

@Redrose64: Thanks. This is what I suspected. So a simple revert of his edit at 17.09 UTC today ought to solve the problem. --P123ct1 (talk) 20:17, 25 August 2014 (UTC)[reply]

That's the starting point. But bear in mind that such an action will nullify all edits made subsequently to the one that you intend to revert, so those will need to be re-examined to see if thy should be re-done. --Redrose64 (talk) 20:26, 25 August 2014 (UTC)[reply]

Environmental categories

See also User talk:Alan Liefting#Environmental categories (version of 09:35, 24 August 2014).

Can someone please make (1) Category:Environmental organizations by year of establishment and (2) Category:Environmental organizations by year of disestablishment, with templates similar to those used for Category:Environment by year and Category:Protected areas by year of establishment? (I made the first one, but not with a template.)
—Wavelength (talk) 19:49, 25 August 2014 (UTC)[reply]

Global settings

As there will be global js/css pages, I was wondering if magic things can be done to:

disable VisualEditor
set Monobook as skin
set the old toolbar

Yes, I am old fashioned guy with old computer :) --Edgars2007 (talk/contribs) 22:19, 25 August 2014 (UTC)[reply]

Probably, but likely not very soon. The task is tracked as Template:Bug. Some work has actually been done on this (see mw:Extension:GlobalPreferences and latest comments on the bug), but it's far from finished. Matma Rex talk 22:27, 25 August 2014 (UTC)[reply]

Hmm, Tech news are lying? ;D --Edgars2007 (talk/contribs) 22:30, 25 August 2014 (UTC)[reply]

@Edgars2007: Personal global CSS/JS and personal global preferences are totally different; it's generally not a good idea to make preference settings at page-load time with user-JS (though theoretically it's possible), which is what each of the bullet points you asked about are, and which Matma Rex was talking about. Personal global CSS/JS will indeed be live cluster-wide as of tomorrow. Jdforrester (WMF) (talk) 23:49, 25 August 2014 (UTC)[reply]

Could this possibly be screwing up my edit window? Several Twinkle tabs either don't load or don't work, the edit window doesn't load as it normally does (but if I use "preview", it seems to work better)? I'm basically js/css illiterate, mostly having copied stuff from other users... --Randykitty (talk) 11:30, 27 August 2014 (UTC)[reply]

@Randykitty: Yes, possible because your global.js loads adapted Twinkle scripts. You could disable your global.js for enwiki by wrapping the code of your global.js with

if ( mw.config.get('wgDBname') !== "enwiki" ){<--code here-->}

. Or if you want to disable it on multiple wikis, you can wrap it with the code which I use at m:User:Glaisher/global.js third line. --Glaisher (talk) 11:41, 27 August 2014 (UTC)[reply]

Thanks, looks like this works! --Randykitty (talk) 12:38, 27 August 2014 (UTC)[reply]

Wikipedia email Gmail note

Tracked in Phabricator
Task T58414

Tracked in Phabricator
Task T66795

Tracked in Phabricator
Task T66818

I have got a Wikipedia email just now. The content is a usless canvassing, but, the thing I want to bring into attention, Gmail is showing a note "This message may not have been sent by: khabboos@gmail.com Learn more Report phishing". Screenshot Tito☸Dutta 16:36, 26 August 2014 (UTC)[reply]

I've received similar messages, including one attached to the copy of an email I sent to another Wikipedian through "Email this user". This might have something to do with either the amount of mail being sent to gmail through a specific WMF server, or an out-of-date security certificate. There have been periodic problems with other email services (Yahoo in particular) rejecting emails from WMF servers because of "spam complaints", resulting in broad swaths of the community not receiving any emails from WMF servers. As I recall, there was some intervention from Operations in the past with Yahoo, and it may be necessary for Gmail as well. Risker (talk) 16:41, 26 August 2014 (UTC)[reply]

No, it's just because the email wasn't, in fact, sent by khabboos@gmail.com: it was sent by Wikipedia itself, and the server is spoofing the From: field just to make it look like it's coming from khabboos. Gmail picks up on the spoofing and adds that note to warn you that it was spoofed--in the context of Wikipedia mails, it's nothing to worry about, but in others, it could be important to know. This is a known issue with the way that "Email this user" works; in fact, I think there was another VPT thread about it not too long ago. Writ Keeper ⚇♔ 16:54, 26 August 2014 (UTC)[reply]

Interesting. I've never had that spoofing flag until the last few days, although I've seen it on plenty of other gmails. Risker (talk) 17:13, 26 August 2014 (UTC)[reply]

Yeah, I think it's because Gmail is only just starting to crack down on such things. I don't think they've really cared before. Writ Keeper ⚇♔ 17:20, 26 August 2014 (UTC)[reply]

Also #Is "Email this user" on the blink? above, and threads linked from that. --Redrose64 (talk) 09:08, 27 August 2014 (UTC)[reply]

ia.wikipedia.org

Can someone help with this request. I am unable to identify where the problem is after a cursory look. (See, for instance, w:ia:America_del_Sud—the show button does not work). Ruslik_Zero 19:44, 26 August 2014 (UTC)[reply]

Pending changes oddity

I set up James Foley with pending changes but nothing is shown in the log. Additionally if you look at the page history at 01:44 25 August 2014 and down that User:Worldedixor made a series of edits that were automatically accepted as they should have been. Then scroll back up to 16:59 26 August and Worldedixor's edit was not accepted and had to be approved. But Worldedixor is autoconfirmed. CBWeather, Talk, Seal meat for supper? 20:51, 26 August 2014 (UTC)[reply]

Thank you CBWeather. I would really like to know what happened. Thank you all. Worldedixor (talk) 21:00, 26 August 2014 (UTC)[reply]

The page was subsequently moved - a page move does not move the log entries, so they're still on the old page name, here they are. --Redrose64 (talk) 09:32, 27 August 2014 (UTC)[reply]

Notifications

Part of the above. Worldedixor left me a message on my talk page but I didn't get the notification. The only way I knew about it was when I got the email. CBWeather, Talk, Seal meat for supper? 20:51, 26 August 2014 (UTC)[reply]

That would be this post. Are your settings at Preferences → Notifications set appropriately? That is, do you have either: (a) a tick in the "Email" column for the "Talk page message" row, or (b) a tick against "Show talk page message indicator in my toolbar"? If so, WT:NOTIFICATIONS is where problems like this are usually posted. --Redrose64 (talk) 09:32, 27 August 2014 (UTC)[reply]

Another possibility: is there a chance that you were viewing your talk page at the time that the new message was posted to it? I know that the simple act of visiting your own talk page will cancel the "you have new messages" orange bar, and I think that it will also mark any "... left a message on your talk page in ..." notifications as actioned. Not certain on that though. --Redrose64 (talk) 09:54, 27 August 2014 (UTC)[reply]

Draft pages polluting content categories

The new WP:DRAFTS namespace is yet another cause of pollution of content categories. As an example Category:Indonesia is full of draft pages. They should not be able to be saved into content categories at all. Automated means cannot be used to prevent them from being saved into content categories since they are not defined in software. Would it be possible to automatically strip category links (i.e. comment out or whatever) from saved Draft namespace pages? -- Alan Liefting (talk - contribs) 05:35, 27 August 2014 (UTC)[reply]

Agreed that this is a problem. Maybe we can modify the category code to allow filtering namespaces allowed inside a category. Then when a draft page is moved to mainspace, the previously ignored category tags will automatically work and no modification is needed. I think this is a better alternative to stripping the links (which will require the mover to re-add them later). Zhaofeng Li [talk... contribs...] 06:05, 27 August 2014 (UTC)[reply]

A bot was approved to work on this. @GoingBatty: Is this bot task running? -- John of Reading (talk) 06:27, 27 August 2014 (UTC)[reply]

Drafts should never get into content categories in the first place. -- Alan Liefting (talk - contribs) 08:27, 27 August 2014 (UTC)[reply]

They shouldn't, but they do. What seems to happen is that a relatively-inexperienced user wishes to create an article - say, a biog of their favourite sports star - so they go through article wizard to create a page in Draft: space. But instead of writing from scratch, they copypaste the biog of a different person (one who plays the same sport, possibly one who plays for the same country or team), and then change the names, dates, physical attributes, scores etc. as appropriate. In so doing they will often amend the "People born in ..." categories to match the known information, but don't realise that these cats are inappropriate for draft space. I worked this out after coming across a number of drafts (several per week) all bearing {{pp-move-indef}} (which shouldn't be on any unprotected page, which virtually all drafts are, and especially not on a page which is intended to be moved at a later date), and often {{good article}} as well (which can, by definition, never be on a draft). --Redrose64 (talk) 09:21, 27 August 2014 (UTC)[reply]

@Alan Liefting and John of Reading: Yes, my bot has been commenting out article categories from drafts, and I just ran it for Category:Indonesia. The hard part is finding which article categories are polluted with draft pages. For user pages, I refer to the great weekly Wikipedia:Database reports/Polluted categories report, and then use the same report for draft pages. I just submitted a request for a similar report specific for draft pages. Thanks! GoingBatty (talk) 14:19, 27 August 2014 (UTC)[reply]

Why not just run alphabetically through all pages in draft space? bd2412 T 14:26, 27 August 2014 (UTC)[reply]

@BD2412: How would you suggest creating a list of all pages in draft space? GoingBatty (talk) 21:18, 27 August 2014 (UTC)[reply]

I would start by looking here, at the special pages list of "All pages with prefix (Draft namespace)". bd2412 T 21:21, 27 August 2014 (UTC)[reply]

(edit conflict)@BD2412: Finding the pages in draft space is easy, the hard part is identifying content categories as such, or more generally, determining if a given category is appropriate for draft space or not.

@GoingBatty: Instead of commenting out the category links or applying the colon trick, would it make sense to wrap content categories in {{main other}}? That way the categorization would be activated automagically once the page is moved to main space. — HHHIPPO 21:26, 27 August 2014 (UTC)[reply]

@Hhhippo: That's a creative option not listed at Wikipedia:Drafts#Preparing drafts. Would it be appropriate to ask at Wikipedia talk:Drafts? GoingBatty (talk) 22:07, 27 August 2014 (UTC)[reply]

Alan Liefting, draft pages should be in content categories for wikiproject people to pick them up in the first place. Contact of people with deep knowledge of a topic with the relevant newcomers is important.

That this software or people did not install this extension or some code with similar functionality seems odd. You'd be able to view fresh category members limited to a namespace at ease. --Gryllida (talk) 23:17, 27 August 2014 (UTC)[reply]

@Alan Liefting: I can see some benefit to that, but it goes against the current guidance at Wikipedia:Drafts#Preparing drafts. You might want to propose this at Wikipedia talk:Drafts. Thanks! GoingBatty (talk) 23:50, 27 August 2014 (UTC)[reply]

Government parameter in Template:Infobox country and Template:Infobox former country

MfD

Dear editors: I have recently become aware of an interesting statistical tool, AfD Stats. Is there a similar tool available for WP:MfD? —Anne Delong (talk) 11:42, 27 August 2014 (UTC)[reply]

Special Diff

@Edgars2007, Johnuniq, Mr. Stradivarius, and Anomie: bug 23489 seems to be related to WP:Village pump (technical)/Archive 129#Special Diff. Helder 12:43, 27 August 2014 (UTC)[reply]

Setting up email alerts for changes on watchlist

I'm talking to a new editor who's using an iPad. Can someone please lay out how to set up email alerts using an iPad, please? --Anthonyhcole (talk · contribs · email) 14:39, 27 August 2014 (UTC)[reply]

@Anthonyhcole: Presuming the new editor is using Safari, they are likely taken to the Wikipedia mobile site - en.m.wikipedia.org. At the bottom of the page, they can click on the Desktop link to get to en.wikipedia.org. Then they can log in, click Preferences at the top right, and click on the Notifications tab.

I don't think they can do this if they're using the Wikipedia app. GoingBatty (talk) 00:07, 28 August 2014 (UTC)[reply]

Dispenser's tools are down again

You may have already noticed that User:Dispenser's tools (e.g. Reflinks, Dab solver) are down again - see User:Dispenser/Toolserver migration and User talk:Coren. I've temporarily commented out the links from {{Cleanup-bare URLs}} and {{Dablinks}} to Dispenser's tools, and will be happy to reinstate them once this issue is resolved. GoingBatty (talk) 00:00, 28 August 2014 (UTC)[reply]

@@ Line 729: / Line 729: @@
 I'm talking to a new editor who's using an iPad. Can someone please lay out how to set up email alerts using an iPad, please? --[[User:Anthonyhcole|Anthonyhcole]] ([[User talk:Anthonyhcole|talk]] · [[Special:Contributions/Anthonyhcole|contribs]] · [[Special:EmailUser/Anthonyhcole|email]])  14:39, 27 August 2014 (UTC)
+:{{ping|Anthonyhcole}} Presuming the new editor is using Safari, they are likely taken to the Wikipedia mobile site - en.m.wikipedia.org.  At the bottom of the page, they can click on the Desktop link to get to en.wikipedia.org.  Then they can log in, click Preferences at the top right, and click on the Notifications tab.
+:I don't think they can do this if they're using the Wikipedia app.  [[User:GoingBatty|GoingBatty]] ([[User talk:GoingBatty|talk]]) 00:07, 28 August 2014 (UTC)
 == Dispenser's tools are down again ==

Markup text	Displays as
`{{cite web \|author=Tova Green \|date=6 May 2010 \|title=12 ימים\|language=he \|trans_title=13 days \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}`	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)
`{{cite web \|author=Tova Green \|date=6 May 2010 \|title=<span lang="he" dir="rtl">12 ימים</span> \|language=he \|trans_title=13 days \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}`	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)
`{{cite web \|author=Tova Green \|date=6 May 2010 \|title=12 ימים \|language=he \|trans_title=<span dir="ltr">13 days</span> \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}`	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)
`{{cite web \|author=Tova Green \|date=6 May 2010 \|title=<span lang="he" dir="rtl">12 ימים</span> \|language=he \|trans_title=<span dir=ltr>13 days</span> \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}`	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)

Markup	Renders as
{{cite web \|author=Tova Green \|date=6 May 2010 \|title=12 ימים\|language=he \|trans_title=13 days \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)
{{cite web \|author=Tova Green \|date=6 May 2010 \|title=<bdi lang="he" dir="rtl">12 ימים</bdi> \|language=he \|trans_title=13 days \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)
{{cite web \|author=Tova Green \|date=6 May 2010 \|title=12 ימים \|language=he \|trans_title=<bdi dir="ltr">13 days</bdi> \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)
{{cite web \|author=Tova Green \|date=6 May 2010 \|title=<bdi lang="he" dir="rtl">12 ימים</bdi> \|language=he \|trans_title=<bdi dir=ltr>13 days</bdi> \|publisher=Maybe So \|url=http://MaybeSo.com/12days.html \|accessdate=15 May 2010}}	Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. `{{cite web}}`: Unknown parameter `\|trans_title=` ignored (`\|trans-title=` suggested) (help)