Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia:VP/T)
Jump to: navigation, search
  Policy   Technical   Proposals   Idea lab   Miscellaneous  
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 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.

« Older discussions, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129
Centralized discussion
Proposals Discussions Recurring proposals

Note: inactive discussions, closed or not, should be archived.

New superprotect protection level, coming to your wiki soon[edit]

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)

Additional details here.--Eloquence* 13:30, 10 August 2014 (UTC)
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)
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 (talkcontribs) 14:09, 10 August 2014 (UTC)
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.--cyclopiaspeak! 14:52, 10 August 2014 (UTC)
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)
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 (talkcontribs) 14:31, 10 August 2014 (UTC)
@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)
What happens? Appeal to the WMF to reverse, per WP:CONEXCEPT. Alanscottwalker (talk) 15:15, 10 August 2014 (UTC)
"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)
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)
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)
In that case, the ED should cut the crap about "working for the users". --NeilN talk to me 15:41, 10 August 2014 (UTC)
@NeilN: I'm guessing that ED stands for Executive Director? — Mr. Stradivarius ♪ talk ♪ 15:53, 10 August 2014 (UTC)
@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)
(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)

────────────────────────────────────────────────────────────────────────────────────────────────────@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)

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)
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)
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)
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)
  • 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. Monty845 15:51, 10 August 2014 (UTC)
    • 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)
  • 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)

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)

I don't think this is about articles. It's about forcing software. - Sitush (talk) 17:19, 10 August 2014 (UTC)
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)
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)
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)
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)
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)
@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)
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)
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)
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)
  • 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)
  • 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)
  • Not a group of one, sorry. JEissfeldt also superprotected it earlier. - Sitush (talk) 18:40, 10 August 2014 (UTC)
  • Will the superprotect right protect from vandalism when all their administrators withdraw their services in protest? –xenotalk 18:36, 10 August 2014 (UTC)
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. Begoontalk 18:41, 10 August 2014 (UTC)

arbitrary break[edit]

  • (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}} (etc) 18:44, 10 August 2014 (UTC)
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. Begoontalk 18:50, 10 August 2014 (UTC)
Begoon - do try and behave in a friendly, collegial manner. Nick (talk) 19:03, 10 August 2014 (UTC)
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. Begoontalk 19:07, 10 August 2014 (UTC)
  • 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}} (etc) 19:27, 10 August 2014 (UTC)
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. Begoontalk 19:37, 10 August 2014 (UTC)
@Technical 13: "deleted and restored the page"... FYI, now they can't: Circumventing those protections in "illegal" ways is shortsighted. Zhaofeng Li [talk... contribs...] 00:31, 12 August 2014 (UTC)
  • Well, like I said, I expected it was something that would quickly get patched... — {{U|Technical 13}} (etc) 00:44, 12 August 2014 (UTC)
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)
  • 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)
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)
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)
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 (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)
"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)
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)
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)
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. Reventtalk 22:03, 11 August 2014 (UTC)
For the curious... de:Wikipedia:Meinungsbilder/Medienbetrachter, results: pro:190 (72.5%), con: 72 (27.5%). Kleuske (talk) 11:00, 12 August 2014 (UTC)
@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)
  • 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)
  • 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 Farmbrough22: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)

The WMF's. Jackmcbarn (talk) 00:15, 12 August 2014 (UTC)
Moller has been blocked on btw, so that is a good start. Tarc (talk) 00:25, 12 August 2014 (UTC)
This is probably a better link for it.—Neotarf (talk) 00:36, 12 August 2014 (UTC)
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)
  • 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)
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)
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)
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)
Nobody seems to have mentioned the RfC on Superprotect rights at Meta yet, so I will. --Redrose64 (talk) 15:02, 12 August 2014 (UTC)
  • 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)

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)

  • 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 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)
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, 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)
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 must start an RfA within 30 days, or gets desysopped by default. Kraxler (talk) 16:42, 15 August 2014 (UTC)

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):

  • 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)
  • A "caricature". . .
Superprotect caricature image.jpg

TitoDutta 06:51, 21 August 2014 (UTC)

Islamic State of Iraq and the Levant (ISIS)—technical problem[edit]

I need to report what looks like a software problem on this page. It is being heavily edited given the current crisis, and today something has gone badly wrong with the Edit Page text and wikicode in section 9.5 "2014 events", in the entries after 8 August 2014. The entries appear normally in the regular text, but on the Edit Page they are all written backwards! I hope you can find someone to sort this out today, because at the present rate several entries a day are being made to this section and subsequent edits may compound the problem. --P123ct1 (talk) 14:44, 12 August 2014 (UTC)

Fixed. There were some stray bi-directional override characters in the title field of one of the citation templates. I've removed them and copied the the title directly from the news site. — Mr. Stradivarius ♪ talk ♪ 15:10, 12 August 2014 (UTC)
Mr. Stradivarius: Thanks very much! I don't know the first thing about software, but your reference to "bi-directional unicode" I think confirms what I suspected, that this glitch had something to do with all the Arabic script (which reads from right to left) that was in the wikitext around that point. --P123ct1 (talk) 17:12, 12 August 2014 (UTC)
Yes and no: it wasn't the Arabic itself, but rather an invisible character that says "from this point, read the text from right to left". Just adding Arabic to a page won't have that effect on English text, although the Arabic itself will display from right to left. — Mr. Stradivarius ♪ talk ♪ 02:34, 14 August 2014 (UTC)
Except that when deleting Arabic text (within a basic English text) there are switches back and forth in direction of movement, sometimes several, as you highlight the script to be deleted. --P123ct1 (talk) 01:11, 18 August 2014 (UTC)
@P123ct1: That's just because the text is Arabic. The original issue you brought here was different - it was an actual extra character. — Mr. Stradivarius ♪ talk ♪ 01:47, 18 August 2014 (UTC)
I see. Thanks! --P123ct1 (talk) 07:14, 18 August 2014 (UTC)

Autoconfirmed flag: Change from "4 days after registration" to "4 days of activity"[edit]

After a recent report of vandalism by a sleeper account (Wikipedia:Administrators'_noticeboard/Incidents#Gnuuu_editor_behavior my question here is how easy could it be to change requirement for "4 days after registration" to "4 days of activity". I guess this was the intended requirement anyway. -- Magioladitis (talk) — Preceding undated comment added 09:43, 14 August 2014 (UTC)

Probably not incredibly hard from a coding standpoint, but sleeper accounts still have to make 10 edits to become autoconfirmed, so ill-meaning users will just spread their qualifying edits over four days while well-meaning users may be confused or stymied. –xenotalk 09:49, 14 August 2014 (UTC)
The first question would be... what kind of activity and are we allowed to track it.. —TheDJ (talkcontribs) 09:53, 14 August 2014 (UTC)
@Xeno, TheDJ: By activity, I mean editing that expands in 4 different days. Of course there is always a way to abuse these things but at least it is a start for lazy vandals. It's only a minor improvement for starts. -- Magioladitis (talk) 11:13, 14 August 2014 (UTC)
The question is whether the improvement in vandal-stopping would be worth the added complexity of having to scan the revisions table to determine "active" days. Anomie 11:19, 14 August 2014 (UTC)
Anomie I don't know how complex is. That's why I posted it here. My guess is it should not be that complex but it's really a guess. -- Magioladitis (talk) 11:26, 14 August 2014 (UTC)
Not really sure either, but one doesn't need to work on a definition of "active" I assume it is meant to be any edit. So one has to review the edits created to make sure that there are four different days. If they make 10 edits on day one, then no more, they never become autoconfirmed. 10 on day one, then try something on day five, they are not yet autoconfirmed. It is wortth asking how hard this is, it doesn't sounds like it should be hard, though admittedly a bit harder than just counting elapsed days and counts.--S Philbrick(Talk) 14:56, 14 August 2014 (UTC)
if its not hard to code then its definitely worth doing, but i assume by activity you mean edits not logging in.Blethering Scot 21:51, 14 August 2014 (UTC)
The code is easy probably. It's the performance problem that would make it hard. Parsing the RC table to measure the activity on en.wp would probably 'not work'. So you would have to add a field to the database that you use to keep some sort of average and update that or something, instead of parsing the entire table on every edit. —TheDJ (talkcontribs) 09:00, 15 August 2014 (UTC)
  • Leaving aside the performance problems and the software complexity, I strongly disagree this is "definitely worth doing" - it has clear detrimental effects. "Four days and ten edits" is reasonably clear - you know that if you register on Monday lunchtime and make enough edits you'll be able to edit protected pages or move pages by Friday afternoon. But if it's "ten edits on each of four days"... well, whose days? I can imagine that trying to work out if you've made edits on four UTC calendar days is going to be a pretty convoluted task if you're in California or New Zealand. Meanwhile, it's an entirely passive right - you can't tell if you're autoconfirmed without trying to do something and seeing if it works - so no way to tell if you've passed the threshold yet.
Result: something that will specifically annoy and confuse new users... the people we're doing really bad at retaining already. Keep any editing triggers like this simple, please. Andrew Gray (talk) 18:31, 15 August 2014 (UTC)
No one has proposed "ten edits on each of four days". It would be better to state, "at least one edit on each of 4 different days, and at least 10 in total.--S Philbrick(Talk) 22:27, 18 August 2014 (UTC)
Andrew Gray read the clarification given by S Philbrick. I propose that we change to "at least one edit on each of 4 different days, and at least 10 in total". -- Magioladitis (talk) 19:21, 19 August 2014 (UTC)
Apologies - I understood the proposal but misphrased it when replying! The complexity of going to an edits-per-day system (regardless of the magnitudes) is something that I think will confuse and annoy new users, and is best avoided. If we wanted to just update the required number of days or edits, I'd still disagree but it would at least be easy to explain to the people affected... Andrew Gray (talk) 19:45, 19 August 2014 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I am no coding expert, but I would strongly support increasing the time served and the number of edits required before the autoconfirmed "flag" is awarded. I've seen a lot of vandalism on older, lesser patrolled articles, as well as a lot of hoaxes at AfD. Virtually all of the vandals and hoaxsters are newly created accounts that did not even both to create a rudimentary user page. So much so, in fact, that when I see edits by newly created "red link" users on certain articles, my suspicion is immediately drawn to them. Given the frequency of such occurrences on certain articles, I strongly suspect that many newly registered vandal accounts are repeat customers. Forty to 50 good edits (or at least non-vandalism edits) seems like a sensible minimum prerequisite for autoconfirmed status. Just my two cents worth. Dirtlawyer1 (talk) 19:41, 19 August 2014 (UTC)

The software already has a built-in method that would allow us to change "4 days since registration" to "4 days since their first edit". Anything more complicated than that would need new code. Jackmcbarn (talk) 03:43, 20 August 2014 (UTC)
Actually, one of the easiest ways to detect a sock is the burst of 10 edits happening over the course of 3 minutes followed by a long gap (sometimes years, even). I'm not sure that complicating that telltale would be worth the marginal gains.—Kww(talk) 03:58, 20 August 2014 (UTC)
Kww, have you encountered many "sleeper" socks? Dirtlawyer1 (talk) 17:21, 20 August 2014 (UTC)
Hundreds.—Kww(talk) 00:13, 21 August 2014 (UTC)
Kww, I have often wondered about such, as I have seen repeat "red link" users return to the same or similar articles, with similar agendas. Perhaps I'm not just paranoid after all. Dirtlawyer1 (talk) 00:31, 21 August 2014 (UTC)
A recent example is this which shows a single edit in February 2007, then nothing for 7 12 years! Johnuniq (talk) 06:22, 21 August 2014 (UTC)

Section edit links missing[edit]

Does anyone know why all the edit section links (except the first) disappeared after I made this edit on Module talk:Sidebar? -- [[User:Edokter]] {{talk}} 19:48, 14 August 2014 (UTC)

Your signature contains bare double closing braces, which will terminate any unclosed template earlier in the page. There are two instances of {{A, B}, {C, D}...} in Module talk:Sidebar#More sophisticated default width setting?. However, the section edit links are there now. --Redrose64 (talk) 20:51, 14 August 2014 (UTC)
So technically, it's not my fault :) I fixed those openings though. -- [[User:Edokter]] {{talk}} 21:01, 14 August 2014 (UTC)
Edokter Your signature still contains unmatched curly braces that may disrupt pages. Mind throwing some nowiki tags around them if you really want them? — xaosflux Talk 22:41, 18 August 2014 (UTC)
Disregard, see you've thrown code tags in there. — xaosflux Talk 22:42, 18 August 2014 (UTC)
<code> doesn't disable wikicode like <pre> does. And while my sig doesn't contain opening braces, it should never be the cause of any disruption. But I'll see what I can do to prevent it. -- [[User:Edokter]] {{talk}} 22:46, 18 August 2014 (UTC)
I use &#123;{, &#124;, and &#125;} instead of {{, |, or }} in my signature to prevent double braces occurring in it. {{Nihiltres|talk|edits}} 06:42, 19 August 2014 (UTC)


I need help on adding Austrian German parameters into Template:lang-de, so I don't need to use Template:lang-de-AT, which is (nearly) useless waste of space. Since "lang-de" is locked, I need some help here on inserting "Austrian German" language into the template's sandbox. As for consensus, well... I'll be notifying related WikiProjects. --George Ho (talk) 20:15, 14 August 2014 (UTC)

If by "locked" you mean protected, then yes, Template:Lang-de is protected, but its sandbox isn't. --Redrose64 (talk) 20:53, 14 August 2014 (UTC)
Well, we have been using Wiki-jargon nowadays, and I really do mean main template page, not "sandbox". --George Ho (talk) 20:58, 14 August 2014 (UTC)
So what you want is some sort of parameter, perhaps |variant=at or some such like that? Are there other variants of German that you should roll into this same template? Right now the sandbox is the same as the live template so there is nothing for anyone to do until you make some sort of change to the sandbox version.
Trappist the monk (talk) 22:16, 14 August 2014 (UTC)
Unfortunately, I don't know how to add it or change it. I'm not good right now at complex stuff. I'm waiting for somebody... A super-expert, maybe. --George Ho (talk) 23:07, 14 August 2014 (UTC)
(edit conflict) In your opening post you say you want to do this so you don't need to use Template:lang-de-AT, which is (nearly) useless waste of space. Can you explain why {{lang-de-AT}} is (nearly) a waste of space? If there are legitimate reasons why {{lang-de-AT}} is (nearly) a waste of space, then certainly we should do something about it. There are those who might say that {{lang-de-AT}} is a fork of {{lang-de}} and on that basis alone would argue that there is sufficient reason to merge the two templates. For such simple templates, I don't see that there is much to be gained by merging them – {{lang-de}} has been stable since October 2012 and {{lang-de-AT}} has been stable since its creation in January 2013.
Trappist the monk (talk) 23:41, 14 August 2014 (UTC)
This template requires a user to search for Austrian-related articles and research a difference between Standard German and Austrian German. Well... I haven't met one German language expert yet. I haven't studied German dialects at all, and I don't think you did either. Of course, that wouldn't be the (main) reason, is it? The template itself is a waste of space ever since creation. Also, there is no "lang-de-CH" currently, and, if created, which one is Swiss? --George Ho (talk) 00:03, 15 August 2014 (UTC)
Isn't it the other way round? A user requires {{lang-de-AT}} for Austrian-related articles. The template makes no requirements on the user (except to type its name correctly etc). You're right, I'm no German scholar, though I fail to see how that is relevant to this discussion. Once again you've declared that {{lang-de-AT}} is a waste of space without giving us anything to support that assertion.
Perhaps, WP:TFD is the best solution to this problem.
Trappist the monk (talk) 00:38, 15 August 2014 (UTC)
I concur, but I've nominated "lang-en-XX" templates for deletion, and I don't want to nominate too many at this time. --George Ho (talk) 03:22, 15 August 2014 (UTC)
Are there other "lang" templates that work like this? If not, it probably does not make sense to fork this template by adding parameters to it. It's better to have one template per language unless you're going to redo the whole set of similar templates wholesale.
In other news, "de-AT" does not appear to be a valid ISO 639 language code, and Austrian German does not appear to have its own ISO 639 code, at least from my searching on the LOC's web site. It is cited elsewhere as a valid ISO code, but not at what appears to be the canonical source. All codes appear to be two or three letters (e.g. "de" for German and "gsw" for Swiss German).
In other other news, this template appears to be used in exactly one article. If you wanted to make an end run around modifying the lang-de template, you could make it so that the lang-de-AT template is not used in any articles, then take it to TFD with some of the above information. – Jonesey95 (talk) 23:21, 14 August 2014 (UTC)
Not a fork as I understand Editor Goerge Ho's request; rather, it's adding functionality to {{lang-de}} so that {{lang-de-AT}} becomes excess to requirements.
Trappist the monk (talk) 23:44, 14 August 2014 (UTC)
It still wouldn't be, though. There's nothing "excess" about having a simple template with no parameters do what Ho wants to do with more parameters in a complex template. For the end-user editor the only difference will be having to abandon {{lang-de-at}} for {{lang-de}}. Since the latter is longer, has more complicated syntax, and requires more server parsing, it is the one that's excess to requirements.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:02, 19 August 2014 (UTC)
The discussions at Wikipedia:Templates for discussion/Log/2014 August 13#Template:Lang-en-GB (and the next few threads) may give some insight here. --Redrose64 (talk) 10:53, 15 August 2014 (UTC)
Jonesey95, this isn't covered by the ISO 639 varients. 639 is only for saying what the two or three letter codes will be. This is actually covered by RFC 5646. This link from does the best explanation. Skip down to the "The region subtag" section, about 60% the way down the article. They give an example of how these codes are constructed and mention AT. German Wikipedia also uses these tags... they have six lang type templates for German. Vorlage:DeS (German), Vorlage:GswS-ch (German-Swiss), Vorlage:BarS (Bavarian) and three for old versions of German. No Austrian (that I could tell). Bgwhite (talk) 00:54, 16 August 2014 (UTC)

I did it; I managed to add variety. However, it probably still needs a little work. I could add Standard German, Swiss German, and other examples of German varieties. --George Ho (talk) 19:27, 18 August 2014 (UTC)

  • There isn't anything "wrong" with {{lang-xx}} parameters supporting a |variety= parameter (other than "variety" is a Wikipedianism and not a linguistic term); I support the idea, if it's done very carefully, with a switch test. Even if it's done right, it's still not a rationale for deleting templates than anyone familiar with language codes will expect to exist. If we don't care about the parser overhead, the {{lang-xx-YY}} versions can be replaced with calls to {{lang-xx|variety=YY}}, but only after the {{lang-xx}} has been set up to support |variety= and is doing so correctly for any plausible variety. This is a self-correcting issue with separate templates for varieties, because they'll redlink if they don't exist; by contrast, using {{lang-en}} will produce a seamless template result but no useful metadata. The main reason we have these separate templates is to force the generation of valid metadata, because what comes out of the template has to be valid language code; we cannot trust editors to input whatever they think a code is or should be into such a template, because they will frequently guess wrong. Note also that {{lang-en}} is essentially a shell, a placeholder for technical reasons, so this proposition won't work at all for migrating {{lang-en-GB}}, etc., to {{lang-en}}; the latter does not use {{Language with name}}, so it does not generate any language metadata at all (on Those must therefore remain separate templates, or {{lang-en}} has to get very complicated, to use completely different code depending on whether it has a |variety= specified or not, which defeats the purpose of all this "let's simply thing" stuff. Which really hasn't been simplifying anything but causing mess and heat.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:02, 19 August 2014 (UTC)
Without the array extension it would become a crazy mess that would have to iterate possibilities (of which there are many thousands possible). Every time one needed to be added it could break all the others if not done properly. Chances of that would become more likely to the more that was added. Separating them also has the benefit that if vandalism occurs it only affects 1 language instead of all of them. Also, the bigger 1 template got the longer it would take to execute because of all the conditionals vs simply executing a simple quick template for each case. Until array extension arrives (if ever) the current method is by far the best solution. JMJimmy (talk) 13:52, 19 August 2014 (UTC)
By "array extension" I guess you mean mw:Extension:Arrays? We have Scribunto now, so extensions for complicated parser functions aren't likely to be added. Anomie 14:58, 19 August 2014 (UTC)
Remember it is good to be consistent with {{Lang|de-AT}} and the {{Icon}} family of templates. Creating a new sub-structure for variety, and another for script could get complicated. It also consumes far more resource than a simple solution. I notice a massive increase in template complexity over the last couple of years, notably in templates where it actually matters. All the best: Rich Farmbrough22:18, 20 August 2014 (UTC).

See also[edit]

FYI: Pointer to relevant discussions elsewhere

George Ho has been raising related issues in a number of different forums. Participants here may wish to synch their input at these other related threads (most of which deal with {{lang-xx-YY}} templates in particular, while the one at WT:NOT is more general):

 — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:02, 19 August 2014 (UTC)

Why do RFCs produce external links?[edit]

I was looking at an article which had the External links header set and was surprised to find the many external links in the article were produced automatically by the system. If I put RFC 2722 in an article, it produces a link without any markup and even if it's totally spurious (e.g. RFC 147238) I still get one. I can only suppress it (RFC 2722) with difficulty. Is this just a techie use that shouldn't be in the production MediaWiki? Chris55 (talk) 09:53, 15 August 2014 (UTC)

WP:RFCAUTO --NE2 10:07, 15 August 2014 (UTC)
Hmm, thanks, that might be appropriate for ISBNs and PMIDs which have a purely referential function, but RFCs are often referred to in discussions, as on the page cited above. Also the ISBN marker generates an internal not an external link; and the use of rfc=, isbn=, pmid= in the citation templates produces both an internal (explanatory) and an external link which is better than the blunderbuss approach of WP:RFCAUTO. And why hasn't this been extended to DOI which seems very similar? Seems to me this mechanism should be reviewed. Chris55 (talk) 10:42, 15 August 2014 (UTC)
This behavior dates back to 2001 or so when people weren't really thinking about consequences the features they were introducing would have more than ten years later :) There is actually a bug calling for a review of this, bug 26207, but it has been filed over three years ago and hasn't seen much action either. Matma Rex talk 00:07, 16 August 2014 (UTC)
See Help:Magic links. ISBN links to Special:BookSources which is an internal link. RFC and PMID are external links. --  Gadget850 talk 01:26, 16 August 2014 (UTC)
This was also questioned on Portuguese Wikipedia some time ago. Helder 17:35, 16 August 2014 (UTC)
Having read all that, it's amazing it's still in core. But less amazing that nobody's thought to update it to include DOI. It would need some determination to remove this 'feature' altogether, though it clearly should be templated. But I have to agree with the 'goofy' comment. Chris55 (talk) 20:52, 16 August 2014 (UTC)

Gmail labelling Wikipedia email suspicious[edit]

Eg leaving the message "This message may not have been sent by: name removed Learn more Report phishing". User:Ponyo also noticed this in an email I sent him from Wikipedia. Dougweller (talk) 15:26, 15 August 2014 (UTC)

It technically is a suspicious email because it was not sent by name removed - Wikimedia is spoofing the sender. My belief is it should come from a Wikimedia email address and use reply-to or cc: to provide the Wikipedia-user's email address to the recipient. –xenotalk 15:58, 15 August 2014 (UTC) p -> m
(edit conflict) This is not uncommon, I get it too as a gmail user. The sender is on a Wiki server (e.g. but the mail is sent "From" a gmail address. Gmail is only suspicious because it's not from one of their servers. One solution is for the system to set the "Reply-to" field to the sender's address, but not necessarily the From field. Chris55 (talk) 16:14, 15 August 2014 (UTC)
There might be less problems once bugzilla:64795 and its related tickets gets fixed. --AKlapper (WMF) (talk) 19:58, 15 August 2014 (UTC)
Thanks all. I mentioned it because this seems to be a new development. It's never happened to me before this month, and it's surprised at least one other editor who gets a lot of Wikipedia mail. Dougweller (talk) 11:01, 16 August 2014 (UTC)
Gmail and Yahoo have increasingly become stringent on how email accounts are used, so it will take a bit for the rest of the world to catch up. Wikipedia is not the only website running into these kinds of errors. —TheDJ (talkcontribs) 12:16, 17 August 2014 (UTC)

Edit MediaWiki:Titleblacklist-forbidden-new-account-invalid, MediaWiki:Titleblacklist-forbidden-new-account[edit]

In Special:UserLogin, messages will be shown as raw text. Since these two pages contain wiki markup, they need to be fixed. Here is an example of current text:

Login error                                             
<<table id="mw-protectedpagetext" class="plainlinks fmbox fmbox-warning" role="presentation"><tr><td class="mbox-text">
The user name "Dtac - Building Knowledge to Thai Society" <a href="/wiki/MediaWiki_talk:Titleblacklist"
title="MediaWiki talk:Titleblacklist">has been blacklisted</a> from creation. The Wikipedia
<a href="//" class="extiw" title="mw:">software</a> does not allow names that are greater than or
equal to 40 characters in length, has the same character repeat more than 10 times in a row, or use certain invalid
characters. Please select another username that complies with these restrictions, or if you need assistance, you may file
a request at <a href="/wiki/Wikipedia:Request_an_account" title="Wikipedia:Request an account">
Wikipedia:Request an account</a>.</td></tr></table>>

See also bugzilla:43358 --Nullzero (talk) 18:38, 15 August 2014 (UTC)

@Nullzero: Are you asking to convert the wikitext of those two pages to raw HTML? That bug has been fixed a long time ago and those two messages render fine for me at Special:Login/signup. --Glaisher (talk) 12:40, 16 August 2014 (UTC)

Special Diff[edit]

I was wondering about this one: if I link with Special:Diff to some revision and the article/revision gets deleted, if there's a possibility, that one day this Special:Diff link can link to another article (in other words: are the revision numbers unique and don't get some other targets if page/revision is deleted). And (also in deleted pages/revisions) what about the thing, when I really don't know at least which page I'm viewing (example: Special:Diff/111111111111). If one would use the old system, then I would at least know which page the discussion is going around if the page is getting deleted (form the URL) but otherwise I don't know that. Some thoughts? --Edgars2007 (talk/contribs) 05:13, 16 August 2014 (UTC)

The title is ignored—try these links:
The numbers used will never change (and are not reused if the page is deleted); you can always pipe a link:
[[Special:Diff/603606601|Wikipedia:Editnotice edit 10 April 2014]]Wikipedia:Editnotice edit 10 April 2014
Johnuniq (talk) 06:17, 16 August 2014 (UTC)
Ok, yes, but I think nobody would especially change the title for the url to mislead the other person (if we are talking about those links you gave) :) And actually I haven't seen so much normal describes for Special:Diff (usually it is like It was done with [[Special:Diff/603606601|this edit]]). And is it possible to know where the number goes (for the deleted pages), at least for admins? Then they could undelete page or tell to non-admins what was the changes. For the old system it is symple, for the Special:Diff - not (I would need to ask to undelete everything :D ). --Edgars2007 (talk/contribs) 06:34, 16 August 2014 (UTC)
I've just tested this using my admin account, and it turns out to be a little complicated. If you use the standard diff URL with the title, then you get a message saying "View or restore n deleted edits?"; the text "n deleted edits" is linked to Special:Undelete for the page that the diff belonged to. (The message is made of MediaWiki:Thisisdeleted and MediaWiki:Restorelink.) There is also another message below it that says "One revision of this difference (nnnnnnnnn) was not found. This is usually caused by following an outdated diff link to a page that has been deleted. Details can be found in the deletion log." The text "deletion log" is linked to the page's deletion log, and the "nnnnnnnnn" text is unlinked. (The message itself is provided by MediaWiki:Difference-missing-revision.)

If you use [[Special:Diff/nnnnnnnnn]], then you only get MediaWiki:Difference-missing-revision, not MediaWiki:Thisisdeleted - the link to Special:Undelete for the deleted page disappears. Also, the deletion log link becomes the deletion log of the Main Page. However, the (nnnnnnnnn) in MediaWiki:Difference-missing-revision gets linked to the deleted text of the diff (also, confusingly enough, supplied by Special:Undelete, but with some different URL parameters). So it's still possible to tell which page the diff belonged to.

If you use the standard diff URL but fake the title parameter, you only get MediaWiki:Difference-missing-revision, not MediaWiki:Thisisdeleted. The deletion log is also for the fake title that we used. And the nnnnnnnnn text is not linked, so there's no way to tell what page the diff was from.

Because MediaWiki can check that the title is fake, it must be able to tell what the correct title is. For that reason, it must also be possible to change the software so that the error message is displayed the same way for all three of these scenarios (and probably more scenarios that I haven't thought of as well). You'd have to ask one of the devs how exactly to do that, though. — Mr. Stradivarius ♪ talk ♪ 07:29, 16 August 2014 (UTC)

Bugzilla? --Edgars2007 (talk/contribs) 12:31, 16 August 2014 (UTC)

@Mr. Stradivarius: I stumbled across the amazing Special:Redirect and am wondering what it does with a deleted revision id. The docs on the special page show two examples:

Would someone please provide a pageid for a deleted page and a revid for a deleted revision so we can try it. What does it show for an admin? Johnuniq (talk) 10:53, 18 August 2014 (UTC)

Deleted pages don't really have a page_id, but Special:Redirect/page/41104910 and Special:Redirect/revision/582012795 should correspond to a recent delete by User:AnomieBOT III of the former redirect Template:Misarchiving welcome here. For an admin, it shows error messages which are presumably the same as for a non-admin. Anomie 11:19, 18 August 2014 (UTC)
Thanks, although it's disappointing that the magic of Special:Redirect does not extend to showing something useful, such as the "A page with this title has previously been deleted" log extract seen when visiting the title of a deleted page. Johnuniq (talk) 12:34, 18 August 2014 (UTC)

<span> tag as template parameter[edit]

I'm trying to create my first second userbox template, and I need it to support an HTML <span> tag as parameter 1. I can't get it to do the substitution, possibly because the tag is being resolved too early in the process and the result is not a valid template parameter.

The template is here and the transclusion is here. Correct answerer will have my eternal gratitude.   Mandruss |talk  10:01, 16 August 2014 (UTC)

The problem is that an "=" sign is used in the signature. Try either replacing it with {{=}} or &#61;, or using a named parameter (|1=~~~). SiBr4 (talk) 11:10, 16 August 2014 (UTC)
Got it using a named parameter (but went with a parameter name that's a little user-friendlier than "1"). ¡Gracias!   Mandruss |talk  11:29, 16 August 2014 (UTC)
(edit conflict × 2) Using the {{=}} template or &#61; Unicode escape inside HTML tags doesn't appear to work at all. SiBr4 (talk) 11:34, 16 August 2014 (UTC)

Merging two interwikilinks? (request for assistance)[edit]

I wanted rapidly to link Rotator cuff tear to it:Tendinite della cuffia dei rotatori. While this sort of task used to be quite straightforward, following the introduction of Wikidata it's frankly gone beyond my paygrade. After messing around for some time, I got told (I think) to merge Q7370333 with Q3983414, but no obvious indication on how to do that. (talk) 11:32, 16 August 2014 (UTC)

I've merged them now. IMO, managing interwiki links are easier with Wikidata than the old method. You can use d:Special:mergeitems. See d:WD:MERGE for help on merging two items. --Glaisher (talk) 12:01, 16 August 2014 (UTC)
Thank you for doing that Glaisher, and also for pointing to the link (though as a logged-out ip I don't get to see it). Nowadays, I frequently find difficulty doing this sort of task, especially when there's not a simple one-to-one correspondence between articles in different languages. (talk) 12:09, 16 August 2014 (UTC)
You can't use d:Special:Mergeitems? It's available to IPs as well. I just checked that myself. --Glaisher (talk) 12:13, 16 August 2014 (UTC)
Oops, sorry, my misreading - my attention was focused elsewhere. (talk) 12:50, 16 August 2014 (UTC)
Glaisher, the link for help is d:Help:Merge not d:WD:MERGE :) And thanks also from me for the link to d:Special:mergeitems – I always have problems with that. --Edgars2007 (talk/contribs) 12:20, 16 August 2014 (UTC)
@Edgars2007: Apparently namespace aliases don't work cross-wiki with interwiki links and URLs If you typed WD:MERGE at the Wikidata search bar, it would redirect to that page. --Glaisher (talk) 12:24, 16 August 2014 (UTC)
The search bar finds the alternative capitalization d:WD:Merge, while links need correct case in the title (except for the first letter (unless the wiki is set to case-sensitive titles, like Wiktionary's mainspace)). Thus, d:WD:Merge links to d:Help:Merge as expected. Anomie 14:07, 16 August 2014 (UTC)
Indeed. Thanks, --Glaisher (talk) 15:48, 16 August 2014 (UTC)

Help with highlightText, again[edit]

I've reported this at bug 67784 Per Wnt: "I see ... some version (I don't know if it's the most recent for sure) of the highlightText at [2] with the infamous split-on-space at line 12." That's exactly it ... I'm hoping that all I need is a function (residing in or outside of Mediawiki) identical to highlightText, with (I'm guessing) the space in pat.split(" ") in line 12 replaced by a tab character. (Or, getting rid of the parsing entirely so I can pass an array of strings would be fine.) Any help? - Dank (push to talk) 03:53, 17 August 2014 (UTC)

Bug in 'Sandbox' link colouring[edit]

Hi all. The 'Sandbox' link in the top-right corner has a bug in that it always appears in the blue 'link exists' colour, even if the sandbox doesn't exist. This goes against the user interface standard of links to pages that don't exist appearing in red (as the user page / talk page links in the same section do). Particularly given that this is a link that's useful for newbies, it is important that it should match the interface standard, and the link should be changed such that it appears in red if the sandbox doesn't yet exist.

I tried reporting this on bugzilla, as I thought it was a basic UI element, but it turns out that this link is added by javascript through MediaWiki:Gadget-mySandbox.js. As such, I guess there's two ways forward:

  1. Could someone that is more knowledgeable than me with javascript fix the problem here?
  2. Should we ask the WMF to implement the 'sandbox' link directly in MediaWiki rather than using a javascript hack to do it? That would also avoid the 'jumpiness' bug - when you load a page, the javascript runs slightly after the page is displayed, such that the user page / user talk page links jump to the left when the sandbox link appears.

The second option would need community consensus before being requested, I believe, so I'd like to ask if there is that consensus here?

Thanks. Mike Peel (talk) 09:43, 17 August 2014 (UTC)

Also see this bug entry - the second option might happen anyway. Thanks. Mike Peel (talk) 09:46, 17 August 2014 (UTC)
To get the link to be colored according to the target page's existence, we'd need to fire off an API query to actually check for that. And we'd either need to cache the result locally or repeat that query on every pageview. All this effort seems to me excessive for adding a simple link to a sandbox page. Anomie 10:34, 17 August 2014 (UTC)
Thanks Anomie. So option 2 is the best approach here, then? Thanks. Mike Peel (talk) 10:43, 17 August 2014 (UTC)

How to add image to infobox[edit]


I've tried and tried to add an image to the infobox of Takht-i-Bahi, including copying the info box of Rohtas Fort and just changing the information to fit, but no dice. What is it that I'm not seeing? Thanks, Parabolooidal (talk) 20:09, 17 August 2014 (UTC)

I have placed a placeholder image to the infobox, just replace the file name to the image you want. Mlpearc (open channel) 20:17, 17 August 2014 (UTC)
hummm, I did that and it didn't work exactly. I put File:Takht-i-Bahi3.jpg in File:Example.jpg and it turned out huge. If I take it out of the brackets [[ ]], like usually infoboxes do, it doesn't show up. Could you stick an image in there for me? Once one is in there, then I could switch if it doesn't look right. Thanks, Parabolooidal (talk) 20:42, 17 August 2014 (UTC)
I've added it with "220px" for the size. -- John of Reading (talk) 21:09, 17 August 2014 (UTC)
Thanks so much! I've learned something new. Best, Parabolooidal (talk) 21:36, 17 August 2014 (UTC)

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

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= |accessdate=15 May 2010}} Tova Green (6 May 2010). "12 ימים" [13 days] (in Hebrew). Maybe So. Retrieved 15 May 2010. 
{{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= |accessdate=15 May 2010}} Tova Green (6 May 2010). "12 ימים" [13 days] (in Hebrew). Maybe So. Retrieved 15 May 2010. 
{{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= |accessdate=15 May 2010}} Tova Green (6 May 2010). "12 ימים" [13 days] (in Hebrew). Maybe So. Retrieved 15 May 2010. 
{{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= |accessdate=15 May 2010}} Tova Green (6 May 2010). "12 ימים" [13 days] (in Hebrew). Maybe So. Retrieved 15 May 2010. 

Anomalocaris (talk) 01:42, 18 August 2014 (UTC)

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)
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)
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)
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:
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)
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)
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:
[ "12 ימים" [13 days]]
If an editor wraps the content of |title= in <bdi>...</bdi>, the concatenated result is correct.
[ "<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:
ימים 2. 
with <bdi>...</bdi> we get
ימים 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)
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= |accessdate=15 May 2010}}
Tova Green (6 May 2010). "12 ימים" [13 days] (in Hebrew). Maybe So. Retrieved 15 May 2010. 
{{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= |accessdate=15 May 2010}}
Tova Green (6 May 2010). "12 ימים" [13 days] (in Hebrew). Maybe So. Retrieved 15 May 2010. 
{{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= |accessdate=15 May 2010}}
Tova Green (6 May 2010). "12 ימים" [13 days] (in Hebrew). Maybe So. Retrieved 15 May 2010. 
{{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= |accessdate=15 May 2010}}
Tova Green (6 May 2010). "12 ימים" [13 days] (in Hebrew). Maybe So. Retrieved 15 May 2010. 

--  Gadget850 talk 01:00, 19 August 2014 (UTC)

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)
Either of these solutions will bugger up the COinS metadata. Here's the COinS title when it's wrapped with <bdi>...</bdi>:
Trappist the monk (talk) 12:04, 19 August 2014 (UTC)
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)

Incorrect category total[edit]

Category:All Wikipedia level-3 vital articles states that it contains 879 articles, but by navigating through the 5 pages in the category, I count 200 + 200 + 200 + 200 + 89 = 889 articles. Am I missing something incredibly obvious, or is there a bug in the page counting algorithm? Malerisch (talk) 03:31, 18 August 2014 (UTC)

It almost certainly means that the process that calculates the total number hasn't been chached in the time that ten article were added to the category. A lot of calculations on Wikipedia lag current statistics (e.g. ages in BLP infoboxes) by up to two months. Without knowing exactly how category populations are tabulated, I would suggest purging the cache on the category page and see if that doesn't work. VanIsaacWScont 04:40, 18 August 2014 (UTC)
I tried making a null edit, but that didn't fix the count. I also don't think it's a cache issue: I temporarily removed {{Vital article}} from Talk:History of East Asia, and the category now states that it contains 878 articles, which is still 10 off. I'm certain that my count is correct though (it's not hard to check either), so I'm not sure where the discrepancy comes from. Malerisch (talk) 05:54, 18 August 2014 (UTC)
Hmm, if it's responding to removal of a member, that doesn't look like a cache issue. So I thought it might be a human counting issue: I went in and copied the whole category list to notepad++ and had it count the number of items, and there are definitely 10 more articles than the category page says there are. I will not make a similar assessment of the 8700+ level-4 vital articles category, but both levels 1 and 2 have correct counts. I honestly have absolutely no clue what the hell is going on here. VanIsaacWScont 06:43, 18 August 2014 (UTC)
I think this is the same problem as Wikipedia:Village pump (technical)/Archive 128#Negative category membership counts. SiBr4 (talk) 08:19, 18 August 2014 (UTC)
It seems this is a very old bug. VanIsaacWScont 08:57, 18 August 2014 (UTC)
Good to know that it's been documented, at least. Thanks for finding the bug report! For the record, I counted up the number of articles in Category:All Wikipedia level-4 vital articles using API:Categorymembers and got a total of 8,759 articles, which is 12 more than the category says it contains (8,747). Malerisch (talk) 14:47, 18 August 2014 (UTC)
FWIW, This problem happened to me as I was clearing out the error tracking category Category:Pages with archiveurl citation errors‎ a few months ago. There was a persistently high count displayed, about 100 articles higher than the actual number, for many months until I reduced the article count to under 200 (a single screen). Once I got the count under 200, the count was fixed and has remained so. I suspect that there is some sort of different math that happens when there is more than one screen's worth of articles in the category. It would be nice to have a way to purge the category count. – Jonesey95 (talk) 16:42, 18 August 2014 (UTC)
Yes. Looking through some of the bug reports, it looks like they changed the behavior several years ago to updated the count automatically with every edit when it was under 200, since the overhead was small enough that the table lookup wasn't much of a savings of just doing the count itself. But it still does a full count only occasionally for categories with over 200 population, and normally just gets the value from the table, while additions or removals of the category just increments or decrements the table value (which is where the errors get introduced). VanIsaacWScont 23:23, 18 August 2014 (UTC)

Tech News: 2014-34[edit]

07:17, 18 August 2014 (UTC)

Text link to image[edit]

Is there markup to create a text link to an image on Commons, where the text is some arbitrary word or phrase? In other words, the equivalent of a piped wikilink to a page, but for an image?   Mandruss |talk  11:10, 18 August 2014 (UTC)

[[c:File:Example.jpg|Click here]] gives Click here. If you want such a link to be created to a local file, you could use [[:File:Example.jpg]].--Glaisher (talk) 11:16, 18 August 2014 (UTC)
Got it, thanks!   Mandruss |talk  11:19, 18 August 2014 (UTC)

Apostrophe in italic words?[edit]

I am told I need to put foreign language words in italics, and I should use two single quotes to do this. So how do I enter "Luftwaffe's" as in "the Luftwaffe's latest fighter design"? Maury Markowitz (talk) 15:58, 18 August 2014 (UTC)

@Maury Markowitz: the ''Luftwaffe'''s latest fighter design should do it. If that clashes with other apostrophes on the page you can use the <i>Luftwaffe</i>'s latest fighter design. — Mr. Stradivarius on tour ♪ talk ♪ 16:06, 18 August 2014 (UTC)
The former does not work, it causes bolding across the entire section. Is <i> really the solution here? Maury Markowitz (talk) 16:11, 18 August 2014 (UTC)
@Maury Markowitz: The former doesn't work? Luftwaffe's latest fighter design. <-- That used the same markup, but it doesn't cause the whole section to be in bold. --Glaisher (talk) 16:34, 18 August 2014 (UTC)
I think he meant that it italicizes the apostrophe. That's why WP:MOS asks for {{'}} or {{'s}}, which is a pain to type, so yes, it would be great if someone could fix this. - Dank (push to talk) 16:36, 18 August 2014 (UTC)
the ''Luftwaffe''{{'}}s latest fighter design is the MOS-recommended way to do this, I believe. It results in: the Luftwaffe's latest fighter design. – Jonesey95 (talk) 16:46, 18 August 2014 (UTC)
Perfect, thanks! Perhaps I am confused, but I seem to recall the "natural" format used to work just fine, after an upgrade circa 2006? Maury Markowitz (talk) 16:57, 18 August 2014 (UTC)
@Maury Markowitz: I'm guessing other apostrophes on the same line interfered with the first syntax that I posted. Could you give a diff that shows the unwanted bolding that you mention? The other apostrophes can be added by templates, so they might not be immediately obvious. We will need an example to see exactly what is going on. Also, Dank, the apostrophe doesn't appear italicised to me when I type Luftwaffe's - are you sure that's what you're seeing? — Mr. Stradivarius on tour ♪ talk ♪ 00:01, 19 August 2014 (UTC)
Compare that apostrophe with the ones produced by {{'}} above ... it slants, they don't. - Dank (push to talk) 00:11, 19 August 2014 (UTC)
@Dank: Ah, you're right. In the HTML output, ''Luftwaffe'''s expands to <i>Luftwaffe'</i>s, and ''Luftwaffe''{{'}}s expands to <i>Luftwaffe</i><span style="padding-left:0.1em;">'</span>s. The apostrophe must appear straight to me because of my font. — Mr. Stradivarius ♪ talk ♪ 02:16, 19 August 2014 (UTC)

@Mr. Stradivarius: I think I may have cause some unnecessary confusion originally, because the non-working version of the string I originally posted had the non-italic "S" at the end. So it was double-quote at the front and triple at the back, which doesn't work. Dank's solution does work, but to be honest, I punted and just put the whole thing italics - after 20000 words I figured I could let that slide :-) Maury Markowitz (talk) 14:22, 19 August 2014 (UTC)

@Maury Markowitz: From your description of the whole paragraph becoming bold it still sounds like there is an unresolved template issue somewhere, though. Could you let us know where you noticed this? A diff would be most helpful, but just the article and paragraph would be a good start. — Mr. Stradivarius ♪ talk ♪ 22:59, 19 August 2014 (UTC)
@Mr. Stradivarius: Sure, it was in the AI Mk. IV radar article. Go back to any version just after the initial creation and you'll see some variation. Maury Markowitz (talk) 21:17, 20 August 2014 (UTC)

Stray brackets[edit]

Can anyone figure out why stray brackets are appearing at the top of Interstate_94_in_Michigan#Exit_list? Ten Pound Hammer(What did I screw up now?) 17:08, 18 August 2014 (UTC)

I found that {{ occurs in 219 places, and }} occurs in 220 places.
Wavelength (talk) 17:30, 18 August 2014 (UTC)
Thanks, captain obvious. I want to know why it's showing up. Ten Pound Hammer(What did I screw up now?) 17:43, 18 August 2014 (UTC)
Removed. Was added in this edit: line 623. --Glaisher (talk) 17:53, 18 August 2014 (UTC)

Coordinates issue in infoboxes[edit]

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:

  1. Identify a list of all templates with hard-coded directional parameters so that a third party user can made necessary adjustments
  2. 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)

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 (talkcontribs) 22:58, 18 August 2014 (UTC)
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)
In other words, can you forward it to Max Semenik (talk) 00:34, 19 August 2014 (UTC)
@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)
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)
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. Face-smile.svg All the best: Rich Farmbrough22:39, 20 August 2014 (UTC).

Coordinate map issues[edit]

Hey there - through OTRS, I've been talking to a user who has had issues with the coordinate map that appears in the infobox of city articles, specifically McClure, Illinois. The map and its red coordinate point appear fine in the article, but when the user goes to print it (through both the Windows 8 printing interface and Wikipedia's own page printing option), the coordinate is located up in the middle of the map. Tried searching for previous bugs, but I'm not too familiar. Any idea what could be going on? Known bug? Compatibility issue? Thanks! ~SuperHamster Talk Contribs 23:06, 18 August 2014 (UTC)

I can't reproduce this in Firefox or Chrome. Perhaps this is an Internet Explorer issue? Seeing as it's working for me, I also doubt it's an issue with Module:Location map, although Jackmcbarn may still be interested in this report. — Mr. Stradivarius ♪ talk ♪ 13:22, 19 August 2014 (UTC)
@SuperHamster: Perhaps you could ask the user what browser they were using at the time? That would help us narrow things down. — Mr. Stradivarius ♪ talk ♪ 13:24, 19 August 2014 (UTC)
@SuperHamster: This is probably not it, but I note that the template has more than one set of coords, one filled in, one blank. Any chance the print option is picking up the wrong set, and trying to locate at zeros, which might default to the middle?--S Philbrick(Talk) 13:31, 19 August 2014 (UTC)
@Mr. Stradivarius: @Sphilbrick: Thanks for commenting, guys. I asked the user what browser they're using, and if it's IE whether it's in desktop mode or metro mode (in case the user still happens to be using Windows 8 and not 8.1). ~SuperHamster Talk Contribs 15:43, 19 August 2014 (UTC)
@Mr. Stradivarius: @Sphilbrick: User is using the desktop version of IE in Windows 8. I re-downloaded the browser myself (bleh) and tested it, and experienced the same issue the user was having when doing a print-preview. I uploaded a screenshot at File:Map printing glitch.png showing the glitch. The same thing appears to happen for East Cape Girardeau, Illinois and Tamms, Illinois, both of which displayed the dot much farther up than it should be. Park Forest, Illinois also showed a bit of variation by a few pixels, with the dot appearing lower than it should have. No idea what's going on beyond that; I'll try experimenting some more. ~SuperHamster Talk Contribs 18:00, 19 August 2014 (UTC)
Surely it cannot be coincidence that all of those examples are using the template Geobox|Settlement. Can you look at one with a different template, to confirm or reject that it is a combination of that template and browser combination?--S Philbrick(Talk) 18:08, 19 August 2014 (UTC)
@Sphilbrick: Hah, just did that - Cleveland appears just fine. To summarize, looks like the issue is variation in the vertical placement of coordinates when using Geobox|Settlement. ~SuperHamster Talk Contribs 18:32, 19 August 2014 (UTC)
@Mr. Stradivarius: @SuperHamster: @Sphilbrick: The problem is that Template:Geobox doesn't use Module:Location map to draw its maps. It uses its own (buggy) code. Converting it to use Module:Location map will fix it. I'll try to do that myself at some point, but anyone else can feel free to try if they want it fixed sooner. Jackmcbarn (talk) 03:37, 20 August 2014 (UTC)

Protection level selection[edit]

Does anybody know why the list of protection levels at the "protect" tab was altered? It used to be "Allow all users"; "Allow only autoconfirmed users"; "Allow only template editors and admins"; "Allow only administrators" - an ascending sequence. Now, "Allow only template editors and admins" appears first, with the others following in the traditional order. Quite apart from the fact that the sequence is illogical, it used to be possible to quickly check the prot level of a page by clicking the "change protection" tab and glancing at the lists - any list where the bar was not at the top meant that a protection was in force. Now, I have to stop and read what it says. It also means that if I want to lower the prot level from semi-prot to unprotected, it's all too easy to raise it to template-protected by accident. --Redrose64 (talk) 00:10, 19 August 2014 (UTC)

Because the superprotection deployment was slightly botched (bug 69640 This has a patch pending: gerrit:154376 – reading the discussion on it, especially the opposing votes, provides valuable insight into the dealing of our community. Matma Rex talk 00:16, 19 August 2014 (UTC)
Aha, so the bug actually came in with gerrit:153302. --Redrose64 (talk) 11:56, 19 August 2014 (UTC)

Making a template[edit]

On my userpage I have a set of instructions that I drew up—see [13]—which I would like to turn into a template that I can use in text generally. How do I do this? --P123ct1 (talk) 10:15, 19 August 2014 (UTC)

Put just the text you want on a separate page, for example User:P123ct1/My template. To use that page as a template, type in {{User:P123ct1/My template}} on any page. — Mr. Stradivarius ♪ talk ♪ 12:57, 19 August 2014 (UTC)
I did that, but when I typed it in, all that came up was "User:P123ct/My template", in faint red. Have I missed out some code somewhere? --P123ct1 (talk) 13:41, 19 August 2014 (UTC)
You've put it on User talk:P123ct1/My template rather than User:P123ct1/My template -- WOSlinker (talk) 13:46, 19 August 2014 (UTC)
I don't know how I managed that! Works perfectly now. Thanks. If I wanted to make a second template, where else could I put the text? You can't use the user "my template" page again, can you? --P123ct1 (talk) 14:18, 19 August 2014 (UTC)
You can call the page whatever you want. Create at User:P123ct1/anything and use with {{User:P123ct1/anything}} -- WOSlinker (talk) 14:25, 19 August 2014 (UTC)
Better to use descriptive names for each template you create, for example by moving the first template to User:P123ct1/Footnotes or something similar. SiBr4 (talk) 14:55, 19 August 2014 (UTC)
I've got the hang of it now. Thanks for everyone's help. --P123ct1 (talk) 15:22, 19 August 2014 (UTC)

Unable to view a video on Mac![edit]

I am using Safari 6.0.2. When i view a video it will say that i must install a new version of Java to do so. After i install it, when i view the video it will say that the site is not on the "whitelist" and the video cannot be viewed. When i found and edit the "whitelist" it will say that the video comes from and you need to whitelist this too. But, after i add to the whitelist, it will still say " is not on the 'whitelist'." After i exit the browser and open it again, when i view the same video it will say "You must install a new version of Java" again. I am using version 7 update 67 after my last update(It still says "version 7 update 67 is the most recent version of Java.") Please notify me on my talk page when you answer.S/s/a/z-1/2 (talk) 11:00, 19 August 2014 (UTC)

@Ssaz 12: I don't think that this is a VPT matter, have you tried WP:RD/C? --Redrose64 (talk) 11:47, 19 August 2014 (UTC)
This post is about viewing a video on Wikipedia.S/s/a/z-1/2 (talk) 12:00, 19 August 2014 (UTC)
This is probably about the Cortado applet which is the fallback for older systems. Does the "whitelist" refer to your browser settings as covered in ? Wondering if the error "You must install a new version of Java" is triggered by the Cortado applet or the Safari browser. --AKlapper (WMF) (talk) 12:09, 19 August 2014 (UTC)
Video on Safari is a mess. Might be better to use Firefox or Chrome. It seems that applet is now starting again (I think for a while we skipped the plugin altogether and just made the user download the file in Safari). I'm hoping that is in preparation of signing it so that it becomes at least a bit usable again on Safari, but i'm not sure. Bawolff might know. —TheDJ (talkcontribs) 12:36, 19 August 2014 (UTC)
Our cortado applet is pretty broken currently. is wrong, the applet isn't signed, etc. At this point I would recommend just downloading the video from the image description page, and viewing in an external program (like VLC). Or using chrome. Sorry for the suckiness :S. Bawolff (talk) 17:36, 19 August 2014 (UTC)

Hedonil's new search history tool[edit]

I have left a message on Hedonil's Talk page about his new search history tool, and from the date of his last message, it looks as if he may be away. So can anyone else help, please? This is the message I left:

"I am having trouble with your new gadget. Sometimes it works, sometimes it doesn't, and quite often it comes up with a message saying "Internal error", "The URI you have requested, /xtools/blame/?, appears to be non-functional at this time." What is happening? Hope you can fix it soon, as it is such a good tool and I rely on it!"

--P123ct1 (talk) 16:20, 19 August 2014 (UTC)

Replied on talk page. In short: Preparations for an repository update, so that OpenSource isn't just claimed but proven. btw. X! Edit Counter is now fully restored and better than ever since 2008 (and it's hard to beat a legend). All other modules should also be alive and kicking again. Cheers --Hedonil (talk) 02:41, 20 August 2014 (UTC)

Animated gifs and "thumb"[edit]

In some articles like Parallel curve an animated gif plays automatically even though it's in a "thumb" disposition, but in others like Osculating_circle#Lissajous_curve I had to remove "thumb" for it to play automatically. Can someone explain what the reason/rule is? JMP EAX (talk) 17:15, 19 August 2014 (UTC)

Big GIF images (where width*height*number of frames > 6*10^7) won't be animated, small ones will be. It has nothing to do with thumb disposition. If a GIF image is too big to be animated, there should be a warning on its image page. Bawolff (talk) 17:38, 19 August 2014 (UTC)
That's not my experience. Using Google Chrome, this old version of the Osculating circle, which uses "thumb", is not animated. Simply removing "thumb" resulted in the animation being played in the article. JMP EAX (talk) 14:33, 20 August 2014 (UTC)
Oh. If you don't use thumb, and don't specify a width (e.g just do [[File:Foo.gif]]), then MediaWiki won't try to shrink the file, and just use the original version, which is animated. This particular image is somewhat of a special case, it appears it was uploaded when the limit for animating the thumbs was much lower, so sizes that were first viewed before the limit was increased are still, but sizes that were first viewed after the limit was increased are animated. I purged the image, which should now make it animated in all sizes (May have to ctrl+r refresh the page to clear your browser cache). Bawolff (talk) 17:57, 20 August 2014 (UTC)

Wikibreak broken[edit]

My attempt at an enforced wikibreak here is not working. Previewing changes logs me out, while actually saving has no effect beyond changing the text. And neither prevents me from logging back in. I'm using Safari 7.0, which is little funny about various issues. Hairhorn (talk) 17:58, 19 August 2014 (UTC)

Going to give wastenotime a try. Hairhorn (talk) 16:17, 20 August 2014 (UTC)

"Unused" list defined reference error is unnecessary and obnoxious[edit]

Someone made a half-hearted attempt to split off part of Shooting of Michael Brown into 2014 Ferguson unrest and the "list-defined references" someone imposed are -- as always -- a pain in the ass. I have little sympathy for using them at all, let alone those who go in and make a page of edits like at Shooting of Michael Brown as they convert, laboriously, everything into their favorite arcane format... seemingly deleting references they don't like as they go along -- or is it just reorganization? can I even tell? But I don't want to argue all that right now. I just want to complain about the way that 2014 Ferguson unrest looked as of [14] with a page of bold red errors because someone committed the heinous crime of having some data in the article that isn't actually being displayed.

One recommended fix for which, according to the Help:Footnotes or Help:Cite errors/Cite error references missing key, is to comment out the unused references, which simply makes the unused information in the article text slightly longer. (Here is what someone actually did: [15])

I'm not saying it wouldn't be "kind of useful" to have a debug option where you can preview an article and see the unused refs highlighted this way, but as a matter of routine article development, as seen here in the field, it is just a needless obstacle. Wnt (talk) 18:50, 19 August 2014 (UTC)

It was a conscious design decision by the developer who implemented List-defined references. The reasoning was that you should not have references that were unused. If there is consensus, we do have the capability to suppress the error entirely. If you with to pursue this, start a RFC. --  Gadget850 talk 21:21, 19 August 2014 (UTC)
And List-defined references were a request on Bugzilla, as were the Automatically generated reference lists. When the developers operate without input, they give what is asked for, which is not necessarily what we really want. --  Gadget850 talk 22:30, 19 August 2014 (UTC)
"you should not have references that were unused" means "you should not have WP:General references". WhatamIdoing (talk) 16:57, 20 August 2014 (UTC)

Is there an anti-ITALICTITLE?[edit]


Congress on Research in Dance displays with an italic article title to me for some reason, whereas it shouldn't, according to MOS (it's the name of a group, not of a scholarly journal). Is there a way to stop articles from having italic titles? Thanks. It Is Me Here t / c 18:55, 19 August 2014 (UTC)

Never mind, it turns out it was coming from {{Infobox journal}}. It Is Me Here t / c 18:59, 19 August 2014 (UTC)

Make all redirects soft using JS[edit]

If I wanted to make all redirects soft (i.e. they don't redirect), how could I go about doing that with JavaScript? I'm looking to do this in order to repair or refine redirects en masse. Thanks. 23W 21:39, 19 August 2014 (UTC)

A link to a redirect has the class .mw-redirect. Look for links with that class and append ?redirect=no to the link. You may also want to look at User:Anomie/linkclassifier; it may already suit your needs. -- [[User:Edokter]] {{talk}} 21:53, 19 August 2014 (UTC)
@Edokter: I can't seem to get it to work. Am I supposed to do var redirect = document.getElementsByClassName("mw-redirect"); redirect.href += "?redirect=no"; or something entirely different? I've already customized my CSS to show redirects as green. 23W 22:41, 19 August 2014 (UTC)
@23W: Probably the best way to do this is though JQuery. $("").attr("href", function(count, value){return value + "?redirect=no";}) should do it. Writ Keeper  23:05, 19 August 2014 (UTC)
@Writ Keeper: This works perfectly. Thank you! 23W 23:12, 19 August 2014 (UTC)

What's up with Firefox and security certificates?[edit]

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)

  • I'm using 31.0 as well and have had no problems. Black Kite (talk) 17:04, 20 August 2014 (UTC)
Do the certificates look legit? Max Semenik (talk) 17:18, 20 August 2014 (UTC)
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)
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)
  • 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)
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)
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)
Did all that ... no change. Daniel Case (talk) 22:58, 20 August 2014 (UTC)

"Old templates"[edit]

Those naughty Wikipedians have created a bunch of templates that are not ready for Visual Editor! Maybe the Foundation should clear out some of the "old templates"...

See this brief conversation with Lila on Meta for some curious perspective.

All the best: Rich Farmbrough22:32, 20 August 2014 (UTC).

Images do not load[edit]

Hello! Since yesterday I'm unable to load any images from Wikipedia, their loading simply times out. Of course, I've tried different browsers and such standard "debugging" stuff, unfortunately with no results. Additionally, loading of JavaScript files seems to be much slower than usual, but that might be the result of troubles with loading images. Any help would be appreciated, and of course please let me know which further information is needed from my side. — Dsimic (talk | contribs) 05:42, 21 August 2014 (UTC)

Google showing wrong title in search results[edit]

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)