Wikipedia:Village pump (technical)

This is an old revision of this page, as edited by 86.130.67.100 (talk) at 01:36, 24 August 2014 (→‎Article traffic statistics incorrect: new section). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.


Latest comment: 10 years ago by 86.130.67.100 in topic Article traffic statistics incorrect
 Policy Technical Proposals Idea lab WMF 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 security@wikimedia.org or filed under the "Security" product in Bugzilla.

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.


New superprotect protection level, coming to your wiki soon

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

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

The description of the patchset is as follows:

Add a new protection level called "superprotect"

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

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

Additional details here.--Eloquence* 13:30, 10 August 2014 (UTC)Antwort
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)Antwort
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)Antwort
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)Antwort
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)Antwort
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)Reply
@TheDJ: What happens when the devs manipulate the software in an irresponsible method? Mdann52 expresses an opinion not shared by many of us. --NeilN talk to me 14:43, 10 August 2014 (UTC)Antwort
What happens? Appeal to the WMF to reverse, per WP:CONEXCEPT. Alanscottwalker (talk) 15:15, 10 August 2014 (UTC)Antwort
"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)Antwort
Well, work on a privately owned domain has its little ups and downs, no doubt -- no use pretending one is not on a privately owned domain. Alanscottwalker (talk) 16:02, 10 August 2014 (UTC)Reply
The site belongs to the WMF - legally speaking, they can run it any way they want to. (See also Wikipedia:Free speech.) You can always create a fork if you want (but you would need a big server farm to do that properly). Personally, I'd like to hear more about the kind of situations that the WMF would use this protection level in. The thing that springs to mind immediately is the JavaScript code that blocked VisualEditor, but I'm wondering if the WMF would use this protection level in other situations as well. — Mr. Stradivarius ♪ talk ♪ 15:34, 10 August 2014 (UTC)Antwort
In that case, the ED should cut the crap about "working for the users". --NeilN talk to me 15:41, 10 August 2014 (UTC)Antwort
@NeilN: I'm guessing that ED stands for Executive Director? — Mr. Stradivarius ♪ talk ♪ 15:53, 10 August 2014 (UTC)Reply
@Mr. Stradivarius: Yes. I'll have to look for a transcript if you want but in her early days Tretikov emphasized the WMF should be working for the users. --NeilN talk to me 16:03, 10 August 2014 (UTC)Reply
(edit conflict) :I can sort of see why this might be justified, per Mdann52, but the timing is awful. Have some egos been bruised? TheDJ, what was "actually known and explained many times before"? The specific superprotect proposal? Where? When? And if it was "not required before to exercise" and apparently "there is no immediate reason to use this protection level on English Wikipedia" then surely it is still not required, so what has changed? Unless your point is that something has happened on a non-English WP. - Sitush (talk) 15:40, 10 August 2014 (UTC)Reply

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

Writ, I can understand most of the code but I'm not a German reader - far too structured a language for someone used to dealing with Indian English ;) Has de-WP had a similar clash over scripts with the WMF over MediaViewer as was happening here? Does this mean that the WMF have managed yet again to upset members in two of its largest projects with the same "improvement"? - Sitush (talk) 16:57, 10 August 2014 (UTC)Antwort
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)Antwort
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)Antwort
Thanks, both. It strikes me that the WMF developers need to explain better and probably listen more. It won't be much good having snazzy bells and whistles if you've got no core users. Equally, there are probably some people among the users who need to listen a bit more. - Sitush (talk) 17:12, 10 August 2014 (UTC)Reply
  • Since apparently the WMF has decided we shouldn't talk about this at WP:AN, I'll duplicate my comment here: So much for trying to build trust between the devs and the community. Monty845 15:51, 10 August 2014 (UTC)Antwort
  • I can't say this surprises me; when the community goes so far as to implement flawed code that breaks things on the site just to spite the WMF's deployment of a feature, it's understandable that the WMF would implement something that keeps people from doing that again. Can this be misused by the WMF? Yep, and I'd like to see actual policy made by the WMF to govern when its employees can use it. But given past history of the communities' responses to software rollouts, is it unreasonable for this feature to exist and be occasionally used? Nope. Though I must say that I suspect 90% of these clashes could be prevented much more easily by a small set of certain people both community-side and WMF-side being topic-banned from software rollout discussions. But I suppose that would be too confrontational when we can just mess back and forth with software instead. A fluffernutter is a sandwich! (talk) 16:06, 10 August 2014 (UTC)Reply

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

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

I don't think this is about articles. It's about forcing software. - Sitush (talk) 17:19, 10 August 2014 (UTC)Antwort
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)Antwort
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)Antwort
Historically when one party does all the work and the other has all the power "co-ordinated time off" has been very effective. Damn, it sure is sunny out there... Chillum 17:41, 10 August 2014 (UTC)Reply
I suppose I am in the minority here of agreeing with most of the WMF's recent implementations. Sure, they had bugs, but so do many off-the-shelf products produced for far higher budgets. Sure, I didn't like VE or MW when they were first released, but just like changes to other sites, I've grown to see how they can be beneficial to both readers, which is a far far bigger pool old people than editors will ever be. Yes, it causes us some inconvenience (shock - 1 extra click to get onto file pages), but we need to put this into context. Using js hacks to suppress stuff appearing helps nobody; However, without greater reader participation in RfC's, we should be careful what we do moving forward. MW had an opt-out button; don't like it? That's what the button was there for. However, I do feel the foundation needs to listen to editors more, and maybe roll out software changes more gradually, taking editor and reader feedback into account. --Mdann52talk to me! 17:28, 10 August 2014 (UTC)Antwort
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)Antwort
@Sitush: I agree with the point about too many new features being added on. However, in terms of design, Wikipedia is years behind most other websites. However, the main issue of hacky js being used remains; taking the de example, specify meaning people had to do another js hack to turn it back on, and preventing logged-out users using it even if they wanted too. --Mdann52talk to me! 17:56, 10 August 2014 (UTC)Reply
I'd argue that this should be delegated much the same as the edit-filter, requiring a special group, but available for assignment-there are some interface pages that most admins want nothing to do with, but could otherwise be very disruptive to edit without really knowing what you are doing. — xaosflux Talk 17:29, 10 August 2014 (UTC)Reply
If the community could decide who had access to this tool then that would make sense. I would be consensus driven. If it is something for the foundation only then it is a problem. Chillum 17:32, 10 August 2014 (UTC)Antwort
That depends on what community you are thinking about. The WMF has multilingual participation that has mechanisms for user persuasion of the Foundation (even actual votes in some areas), but also a structure for organizational decision making -- an analogy, locally, is Arbcom whose decisions are also not subject to consensus, per CONEXCEPT. Alanscottwalker (talk) 18:41, 10 August 2014 (UTC)Reply
  • The fact that this new protection level is coming at the behest of Engineering chief Erik Möller rather than the legal department indicates to me that this user right is going to be used as a mechanism to shove VE and Flow down our throats, not as a content-locking device. Carrite (talk) 17:54, 10 August 2014 (UTC) Last edit: Carrite (talk) 17:56, 10 August 2014 (UTC)Reply
  • Well, judging by recent events on de-WP (machine translation on Writ's page), the "group" who have been assigned the superprotect status there may consist of one person. - Sitush (talk) 18:32, 10 August 2014 (UTC)Reply
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)Reply

arbitrary break

  • (edit conflict) I support the addition of this new protection level to be used for BLACKLOCK enforcement as it will prevent administrators from doing things they shouldn't, especially those due to some kind of edit conflict that gets overlooked or some other accidental reasoning (surely none of them would do these things intentionally no, I'm not being sarcastic). As far as them adding such a thing to force software changes on the community, they quite simply wouldn't use it for this purpose (because they should know it would never work unless they are going to lock down nearly the whole wiki to enforce it). If we play out an instance like JavaScript code that blocked VisualEditor, which I would like to point out the the code added by our administrator was flawed and poorly executed, and once reverted by the devs it ended there and there was no edit warring, so there was no need for this protection to be applied (if it had existed). For the sake of argument though, lets say they locked MW:Common.js for this, they would also have to lock all four MW:Skin.js, MW:Gadgets-definition, and every script that is imported on each of those pages. They are just not going to go through all of that trouble. Can we please assume some good faith on the part of the developers here? — {{U|Technical 13}} (etc) 18:44, 10 August 2014 (UTC)Reply
er, yeah... You may not have read the discussion, "adding such a thing to force software changes on the community" is the only reason it's been used so far, at de.wp, and Erik clearly explains that is its purpose in the mailing list discussion he links. Do try and keep up, there's a good chap. Nobody has said it's foolproof, in fact, on the mailing list the very flaws you mention are pointed out. It's a poor implementation - no surprises there. Its purpose, however, is in no doubt I can see. Begoontalk 18:50, 10 August 2014 (UTC)Antwort
Begoon - do try and behave in a friendly, collegial manner. Nick (talk) 19:03, 10 August 2014 (UTC)Antwort
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)Reply
  • or perhaps I just read it differently than you. or perhaps you missed the point of my post. All that I was saying is that this new level has the potential to be used for a good purpose (when used to enforce blacklock legal issues) and has no effect when trying to be used for the wrong purpose (like trying to force something on the community) because there are just way too many ways to circumvent it (per Edokter and the admin on de that deleted and restored the page (without protection, which I'm sure WMF staff will fix)). — {{U|Technical 13}} (etc) 19:27, 10 August 2014 (UTC)Reply
Yeah, probably I missed your point. It's pretty hard to assume it was introduced for the good reasons you speculate, though, when it was immediately used for what you rightly say it isn't any good for, especially given Erik's clear statement of intent. Hey ho. No good will come of this - of that I remain sure. Begoontalk 19:37, 10 August 2014 (UTC)Reply
@Technical 13: "deleted and restored the page"... FYI, now they can't: gerrit:153345 Circumventing those protections in "illegal" ways is shortsighted. Zhaofeng Li [talk... contribs...] 00:31, 12 August 2014 (UTC)Reply
Technical 13, please don't repeat the misstatements that were made: the JS change that disabled Visual Editor did exactly what it was intended to do. That Erik and James later made a series of false statements in an effort to pretend that there was a problem with the change doesn't mean that you should repeat the false statements. The patch prevented anyone from turning on Visual Editor prior to making at least one edit with conventional Wikitext. Given that anyone using Visual Editor needed to be intimately familiar with Wikitext in order to recognize and correct the file corruptions it made, that was a quite reasonable restriction.—Kww(talk) 19:27, 11 August 2014 (UTC)Reply
  • I'm going to emphasize the disclaimer here: what I write here are entirely my personal views and in no way represent anything at all official. Yes, the whole idea of staff-only superprotection sucks, and I'd really rather have seen more moderate elements on dewiki emergency-desysop the admin there who was wheel-warring to add a JS hack that appears to have gone well beyond what I've heard (mainly via Google Translate) is the actual vote result at that project. Instead any moderate elements seem to have been mostly silent while reactionaries pat each other on the back. But "oh noes! teh WMF is stealing our autonomiez!" won't do any good, because they're not. The purpose of the WMF isn't to simply be a hosting provider for Wikipedia or to serve the will of the editors. It's to collect, develop, and disseminate educational content effectively and globally, in particular by providing infrastructure and organizational framework for us to create that content. Maybe we disagree with some of the infrastructure (VE, MediaViewer, Flow, etc) they're providing, but it's not our right to overrule them any more than it's their right to interfere in the content of articles. But we can work with them and try to reach a consensus on what the best course might be. In truth, we're not even two separate groups, both because many of "us" are also "them" and because "us" is far from being only one group.
    I doubt this superprotection is really a step on the way to code review for site JS and gadgets, although the need for it may spur that project. Instead, I see it as a reaction to certain admins actively breaking things in the name of "consensus" among a relative handful of radical editors who can't handle unchecking a checkbox in their preferences over the silent consensus of thousands of users who enabled the beta feature and who responded to the surveys. And I'm sure this breaking of things does nothing to "force" the WMF to listen; despite claims to the contrary, I greatly doubt (no, I have no personal knowledge of this either way) that the VE-disable hack really forced the WMF to back down. Rather I believe than the actual errors that were being introduced into pages (which is something tangible, not just WP:IDONTLIKEIT and typical-mind-fallacy-based arguments) and a realization that they weren't going to be able to be fixed quickly did it and the public outcry served to bring attention to those real issues. Code review for site JS has been discussed, along with discussions of a central repository for gadgets, templates, modules, and the like (Commons-like, but not Commons), but it'll almost certainly be run mainly by volunteers rather than staff paid for that purpose.
    So what does this new ability for superprotection actually mean for us? If we can manage to work with the WMF instead of letting demagogues speak and act for us, probably absolutely nothing. Sure, some of us may not like some of the new features being rolled out—I myself will likely never use VE (I like wikitext) and I'm skeptical of Flow, but I see how both of these could be good for newbies and I know (and this is from personal knowledge) they're being developed in good faith. But we'll get nowhere by trying to assert rights that we never in fact or in theory actually ever had. We need to try to compromise, to show the WMF when they sometimes go wrong instead of constantly crowing it without evidence, and to admit that sometimes we may be wrong as well. Anomie 19:19, 10 August 2014 (UTC)Reply
With VE the WMF/dev clearly overreach themselves. The software was not ready for beta, they should have waited a year, VE is now much closer to the state where it could be made a default. Unfortunately the handling of relations mean VE uptake is less than 1% of all edits[1] the banner appeal does not seem to have made a dint in this, and there is a good chance VE will be effectively dead on en.wikipedia for many years to come. I've no doubt the devs would have used super-protection to force VE on the community. Rather than these technical measures the WMF need to work with the community, move at the speed of the community, have senior people spend much more time on the various wiki guiding products through each wiki's processes. The reason wikipedia took off was Jimbo took the time to discus things at length with the community, this is a lesson the WMF has forgotten. Any other path will alienate the community, encourage more people to leave and actually be counter productive to its stated aims of boosting the number of editors.--Salix alba (talk): 20:25, 10 August 2014 (UTC)Reply
If this protection level is for interface pages, maybe editinterface could be used instead, separating it from sysop and making it available to fewer users. The new protection level could then be used for something between semi and full protection, where it is more needed, making it possible to give users ability to edit protected articles such as New York Institute of Technology that are in need of improvement without also giving unnecessary access to deleted revisions and editing of protected templates and scripts. There's one thing that isn't clear from the links I've seen: "superprotect" is added as a permission, and as a protection level, but where is it specified which permissions are needed to protect at each level ("superprotect", "sysop", "autoconfirmed" or others)? Peter James (talk) 23:44, 10 August 2014 (UTC)Antwort
First off, i have no particular opinion pro or con the MediaViewer. I don't much use it, though it now becomes clear why my browser started acting up last May.
However, I think the introduction of new privileges is the worst possible solution to any given problem, especially if its use flies in the face of the opinions of the wikipedia communities. It's use over a bug-ridden piece of new software isn't just the worst possible solution, it's positively disingenious, since it adds futher strain to the relation between communities and the ones who claim to serve us, especially given the way WMF saw fit to handle the situation on de.wiki. (and yes, I do read German and do not rely on google's garbled version).
This is the second time WMF screwed up. It's vocal opposition to the European "Right to be forgotten" policy here and here is not just a hyperbole and, frankly, silly, it usurps the political views of contributors and speaks on behalf of the communities without consulting them.
It is WMF's job to facilitate the encyclopedia and other projects, it is not it's job to ram it's decisions down the throat of various communities, unless there are sound legal reasons to do so (i.e. a court order or clear violations of laws). ANY other reason is unacceptable. Kleuske (talk) 13:03, 11 August 2014 (UTC)Antwort
"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)Antwort
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)Antwort
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)Antwort
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)Antwort
For the curious... de:Wikipedia:Meinungsbilder/Medienbetrachter, results: pro:190 (72.5%), con: 72 (27.5%). Kleuske (talk) 11:00, 12 August 2014 (UTC)Reply
@Peter James: "superprotect" wouldn't make sense as a level between autoconfirmed and full protection, because that wouldn't really merit the "super-" prefix. But there's nothing stopping the creation of such a level with a more appropriate name besides the need for community consensus, exactly as was done to create template protection. And for what it's worth, it's already possible (and easy from a technical standpoint) to create a group that could edit fully-protected pages (but not cascade-protected pages) without them having all the rest of the admin toolkit, but that sort of idea has already been discussed and rejected several times.
As for permission to protect at a level, the 'protect' right gives the ability to apply and remove protection at any level you can edit through (e.g. it would be impossible to give a user the ability to both apply/remove semi-protection and to edit fully-protected pages without also giving them the ability to apply/remove full protection). Anomie 13:33, 12 August 2014 (UTC)Reply
  • Some party hack decreed that the people
    had lost the government's confidence
    and could only regain it with redoubled effort.
    If that is the case, would it not be simpler,
    If the government simply dissolved the people
    And elected another? --John (talk) 18:28, 11 August 2014 (UTC)Reply
  • I considered the previous controversy over Eric's actions overblown. But this really does seem to be a God complex in operation. All the best: Rich 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)Reply

The WMF's. Jackmcbarn (talk) 00:15, 12 August 2014 (UTC)Reply
Moller has been blocked on de.wiki btw, so that is a good start. Tarc (talk) 00:25, 12 August 2014 (UTC)Antwort
This is probably a better link for it.—Neotarf (talk) 00:36, 12 August 2014 (UTC)Antwort
Wanna bet the WMF coders will pronto add a hack so one can edit while blocked if one has superprotect rights? Probably the next thing is going to be superblock rights that can't be undone by admins, so the WMF can have something to get rid of admins they don't like. JMP EAX (talk) 08:15, 12 August 2014 (UTC)Reply
  • I am really curious why the WMF is putting so much effort into making volunteers (especially admins) feel they are not welcome unless they agree with the party line. It seems Erik deliberately decided to use this opportunity to show who is in charge (he is too smart to do something like this accidentally).
  • Anyway, enough of my surprise and sadness. How to go forward from here isn't easy. It is clear that we need better communications channels between developers and community, but maybe we also need a less change-adverse decision process allowing the community to agree on implementing new features. Using RfCs after flawed software has been deployed and without an easy way to just revert the change (the well-proven wiki way to radical change: BOLD-REVERT-DISCUSS) isn't a very good model to build mutual trust, as has been demonstrated in the last couple of failed software roll-outs. In any case, "the community" is difficult to talk to, and perhaps we should move towards something like representative democracy so that these issues could be calmly and rationally discussed (ArbCom, our only elected group, specifically wasn't elected to decide the future of Wikipedia, but just to serve as its court). Not clear if something like this can help to restore trust between WMF and community, but the current build-up of distrust should not continue much longer. —Kusma (t·c) 12:21, 12 August 2014 (UTC)Reply
Your second paragraph is right on. If communication is the issue, our focus needs to be on better ways for the community to communicate. (Your first paragraph seems overblown, there is in fact very little admins are resisted in doing from that quarter, and it seems some admins get overly offended, when someone says, 'ah, no' to them in very limited areas). Alanscottwalker (talk) 14:01, 12 August 2014 (UTC)Antwort
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)Antwort
Well, that would be a matter of clearer communication; as for "listen", that just simply does not always lead to "agree". Alanscottwalker (talk) 14:38, 12 August 2014 (UTC)Reply
Nobody seems to have mentioned the RfC on Superprotect rights at Meta yet, so I will. --Redrose64 (talk) 15:02, 12 August 2014 (UTC)Reply


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

  • Absolutely shocking behavior by the WMF and this is likely to be the final nail in the coffin of me actively editing or being an admin here. I had already wound down due to previous things they've done but I see no way back now. I'm actually not against the idea of superprotect however the way it has been introduced, with no discussion and virtually no notice, is shocking and shows a complete disrespect for editors and admin. Without software and support people this site would collapse. Without volunteer admins and editors likewise. The sooner the WMF realise this and stop letting the first group so seriously annoy the second the better. I had actually started a draft RfC in my user space for withdrawing labour over the VE issue and now from what I read above it appears de.wiki are considering something similar. It does now seem only a matter of time before something like that happens on one of the big sites and then maybe the WMF will finally properly appreciate us. They certainly aren't going to be happy - I can't imagine the press will be good for them. Dpmuk (talk) 23:19, 13 August 2014 (UTC)Reply
RE Kosh Vorlorn - A few days ago, on the German Wikipedia some admin tried to execute the result of an RfC which ended 190 to 72 for making it opt-in instead of opt-out (similar to what happened here on en.wiki), but there was already some sort of protection in place. So the admin hacked it and disabled it completely. This led to a wheel war with WMF employees and then the Superprotect right was created and used on the MediaViewer. The right's description says that only WMF employees can get it, nobody else is eligible. In the above linked discussion, Eloquence uses again the "silent-majority-fallacy": 260 voters can not represent 250 million readers/month. The other participants in the discussion say that Eloquence is arrogant, and uses empty politician's talk; and that the WMF developpers are unwilling to hear the community, and incapable to develop any new feature without flaws, and can not implement anything without drama. Kraxler (talk) 16:25, 15 August 2014 (UTC)Reply
Erik Möller/Eloquence is still blocked, block is for 1 month beginning on August 11. The other WMF admin involved in the wheel war, Jan Eissfeldt has been recalled, and under the rules of de.wiki must start an RfA within 30 days, or gets desysopped by default. Kraxler (talk) 16:42, 15 August 2014 (UTC)Reply

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

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

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

  • The WMF is petitioned to remove superprotection from all pages on the German language Wikipedia, immediately.
Yes: 590, No 92, abstention 24.
  • The WMF is prompted to remove the superprotection right from the Staff group, immediately.
Yes: 457, No 73, abstention 31.
  • The WMF is prompted to reverse the software change(s) which introduced the superprotection right in short term (e.g. with the next software update).
Yes: 338, No 99, abstention 81.
  • The WMF is prompted to assign new group rights, that may applied to block elected rights-holders (i.e. administrators, bureaucrats, check users, Oversighters, stewards), only to user groups whose members were also elected by the local (or, where appropriate, international) community.
Yes: 327, No 73, abstention 79.
(Comment if you could get 700 people to express an opinion on an RfC at the English Wikipedia, it would be a record. And the German Wikipedia is smaller than the English. The Foundation would ignore this RfC only at their peril.)

File:Superprotect_caricature_image.jpg TitoDutta 06:51, 21 August 2014 (UTC)Reply

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

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

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

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)Antwort
The first question would be... what kind of activity and are we allowed to track it.. —TheDJ (talkcontribs) 09:53, 14 August 2014 (UTC)Reply
@Xeno and 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)Antwort
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)Antwort
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)Antwort
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)Antwort
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)Antwort
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)Reply
  • 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)Antwort
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)Antwort
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)Antwort
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)Reply

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

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)Antwort
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)Antwort
Kww, have you encountered many "sleeper" socks? Dirtlawyer1 (talk) 17:21, 20 August 2014 (UTC)Antwort
Hundreds.—Kww(talk) 00:13, 21 August 2014 (UTC)Antwort
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)Antwort
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)Antwort
Wow. Some folks clearly have (a) a compulsion to vandalize, and (b) way too much time on their hands. Like I said above, I am immediately suspicious of any newly registered "red link" user who edits certain articles that are frequented by vandals. I wish there were an easy solution . . . . Dirtlawyer1 (talk) 18:25, 21 August 2014 (UTC)Antwort

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

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)Antwort
So technically, it's not my fault :) I fixed those openings though. -- [[User:Edokter]] {{talk}} 21:01, 14 August 2014 (UTC)Antwort
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)Antwort
Disregard, see you've thrown code tags in there. — xaosflux Talk 22:42, 18 August 2014 (UTC)Antwort
<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)Antwort
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)Reply

Template:lang-de/sandbox

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

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)Antwort
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)Antwort
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)Antwort
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)Antwort
(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)Antwort
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)Antwort
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)Antwort
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)Reply
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)Antwort
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)Antwort
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)Antwort
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)Reply
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 w3.org 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)Reply

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

  • 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 en.wiki). 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)Antwort
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)Antwort
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)Reply
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

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

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

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

The two citation bugs are:

  • Without the English title protected by <span dir="ltr">, the English number moves into the Hebrew title.
  • Without the Hebrew title protected by <span lang="he" dir="rtl">, the Hebrew title displays with the number on the left instead of the right.
Markup text Displays as
{{cite web |author=Tova Green |date=6 May 2010 |title=12 ימים|language=he |trans_title=13 days |publisher=Maybe So |url=http://MaybeSo.com/12days.html |accessdate=15 May 2010}} Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. {{cite web}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
{{cite web |author=Tova Green |date=6 May 2010 |title=<span lang="he" dir="rtl">12 ימים</span> |language=he |trans_title=13 days |publisher=Maybe So |url=http://MaybeSo.com/12days.html |accessdate=15 May 2010}} Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. {{cite web}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
{{cite web |author=Tova Green |date=6 May 2010 |title=12 ימים |language=he |trans_title=<span dir="ltr">13 days</span> |publisher=Maybe So |url=http://MaybeSo.com/12days.html |accessdate=15 May 2010}} Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. {{cite web}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)
{{cite web |author=Tova Green |date=6 May 2010 |title=<span lang="he" dir="rtl">12 ימים</span> |language=he |trans_title=<span dir=ltr>13 days</span> |publisher=Maybe So |url=http://MaybeSo.com/12days.html |accessdate=15 May 2010}} Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. {{cite web}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)

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

Is the fourth example the one that is displayed correctly? It looks like adding a span dir="ltr" declaration automatically for |title= parameters when ltr languages are declared in |language= might do the trick. I have paged the folks who know the details of the Lua code that underlies most of the cite/citation templates. – Jonesey95 (talk) 16:38, 18 August 2014 (UTC)Antwort
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)Antwort
I'm not thinking that this is a CS1 problem. I think I can duplicate the problem outside of a CS1 template by simply copying the Hebrew characters from one of these citations and pasting them into this edit window:
ימים
If I then put the cursor at the right end of the Hebrew string and type any letter on my keyboard ('a' in this case)
ימיםa
then the character is placed to the right of the Hebrew string. This is how it should work, correct? If I repeat the above experiment but instead type a number ('9'), the number is placed at the left of the Hebrew string:
ימים9
From this I think that I can conclude that the problem lies elsewhere than in CS1.
Trappist the monk (talk) 19:01, 18 August 2014 (UTC)Antwort
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)Antwort
Module:Citation/CS1 simply concatenates |title=, |trans-title=, and appropriate punctuation into an internal variable Titel. This variable is used either as-is, or as the display text for |url= when the code renders the citation:
[http://MaybeSo.com/12days.html "12 ימים" [13 days]]
If an editor wraps the content of |title= in <bdi>...</bdi>, the concatenated result is correct.
[http://MaybeSo.com/12days.html "<bdi lang="he" dir="rtl">12 ימים</bdi>" [13 days]]
It occurs to me that the module could automatically wrap every |title= with <bdi>...</bdi> tags regardless of language. This problem isn't limited to digit-initial |trans-title=. This:
{{cite book |title=ימים |volume=2}}
produces this:
ימים. Vol. 2.
with <bdi>...</bdi> we get
ימים. Vol. 2.
I'll experiment with having the module wrap |title= values after I make a currently pending update to the live module code. I will post my results at Help talk:Citation Style 1.
Trappist the monk (talk) 12:04, 19 August 2014 (UTC)Reply
I think <bdi> should fix it; see Help:HTML in wikitext#bdi. Have to check browser support though.
Markup Renders as
{{cite web |author=Tova Green |date=6 May 2010 |title=12 ימים|language=he |trans_title=13 days |publisher=Maybe So |url=http://MaybeSo.com/12days.html |accessdate=15 May 2010}}

Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. {{cite web}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)

{{cite web |author=Tova Green |date=6 May 2010 |title=<bdi lang="he" dir="rtl">12 ימים</bdi> |language=he |trans_title=13 days |publisher=Maybe So |url=http://MaybeSo.com/12days.html |accessdate=15 May 2010}}

Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. {{cite web}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)

{{cite web |author=Tova Green |date=6 May 2010 |title=12 ימים |language=he |trans_title=<bdi dir="ltr">13 days</bdi> |publisher=Maybe So |url=http://MaybeSo.com/12days.html |accessdate=15 May 2010}}

Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. {{cite web}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)

{{cite web |author=Tova Green |date=6 May 2010 |title=<bdi lang="he" dir="rtl">12 ימים</bdi> |language=he |trans_title=<bdi dir=ltr>13 days</bdi> |publisher=Maybe So |url=http://MaybeSo.com/12days.html |accessdate=15 May 2010}}

Tova Green (6 May 2010). "12 ימים" (in Hebrew). Maybe So. Retrieved 15 May 2010. {{cite web}}: Unknown parameter |trans_title= ignored (|trans-title= suggested) (help)

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

Gadget850: Yes, it appears that <bdi> works better than <span>. If the rtl |title= parameter is tagged with bdi, the English |trans_title= parameter displays correctly without additional markup. But still, protecting the rtl |title= parameter with <span> should also work, and the second bullet is still a bug in my opinion. —Anomalocaris (talk) 06:41, 19 August 2014 (UTC)Antwort
Either of these solutions will bugger up the COinS metadata. Here's the COinS title when it's wrapped with <bdi>...</bdi>:
&rft.btitle=%3Cbdi+lang%3D%22he%22+dir%3D%22rtl%22%3E12+%D7%99%D7%9E%D7%99%D7%9D%3C%2Fbdi%3E
Trappist the monk (talk) 12:04, 19 August 2014 (UTC)Antwort
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)Antwort

Incorrect category total

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

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)Antwort
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)Antwort
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)Reply
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)Antwort
It seems this is a very old bug. VanIsaacWScont 08:57, 18 August 2014 (UTC)Antwort
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)Antwort
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)Antwort
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)Reply

Apostrophe in italic words?

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

@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)Antwort
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)Antwort
@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)Antwort
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)Antwort
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)Antwort
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)Antwort
@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)Antwort
Compare that apostrophe with the ones produced by {{'}} above ... it slants, they don't. - Dank (push to talk) 00:11, 19 August 2014 (UTC)Antwort
@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)Antwort

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

@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)Antwort
@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)Antwort
You can also use ''Luftwaffe''<nowiki />'s → 'Luftwaffe's; You could also insert an empty HTML comment or a zero-width space. Personally I prefer {{'}} because I believe we should avoid tag mark-up and HTML as much as possible, also it adds a tiny bit of leading (using style attributes, a hair space might be better).
All the best: Rich Farmbrough11:13, 22 August 2014 (UTC).
Or if it really causes problems avoid the apostophe altogether and reword the sentence "the lastest fighter design of the Luftwaffe". That was the solution for problems with apostrophes taught to me in grammar lessons many years ago. Nthep (talk) 11:20, 22 August 2014 (UTC)Reply
The problem with a hair space is that it will be included in a copy-paste, which can be annoying for the person copying-and-pasting. Anomie 11:22, 22 August 2014 (UTC)Reply

Coordinates issue in infoboxes

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

Yes, one of our 'wonderful' hacks, that has served us well and others not so much :) Luckily, we have most of this data parsed into a separate database now, using the {{#coordinates}} function of the GeoData extension. I think that is a better way forward. I'm pinging some engineers that might be able to help, and otherwise I'll forward to wikitech-l mailing list. —TheDJ (talkcontribs) 22:58, 18 August 2014 (UTC)Antwort
Indeed, GeoData/Wikidata is the way to move forward in this situation. I don't think that we should care about uses of dumps for things other than loading them into MediaWiki. Instead, we should refer people to the proper ways to access our data. Max Semenik (talk) 00:20, 19 August 2014 (UTC)Reply
In other words, can you forward it to msemenik wikimedia.org? Max Semenik (talk) 00:34, 19 August 2014 (UTC)Antwort
@MaxSem: I forwarded it. I'm not sure you will get the whole stream, but it is Ticket:2014080510001771 if you want all the back and forth.--S Philbrick(Talk) 01:52, 19 August 2014 (UTC)Reply
Yet another reason to replace overly-specific infoboxes with more generic examples; in this case {{Infobox settlement}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:31, 19 August 2014 (UTC)Reply
It would be good sense to sign-check the data on import anyway. And certainly there are many other ways to get the coordinates to confirm. Wikipedia, especially a snapshot thereof is not a great source for coordinates where accuracy is important. For statistical work its pretty good though.   All the best: Rich Farmbrough22:39, 20 August 2014 (UTC).

Coordinate map issues

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

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)Antwort
@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)Antwort
@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)Antwort
@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)Reply
@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)Antwort
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)Antwort
@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)Antwort
@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)Reply

Protection level selection

  Resolved

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

Because the superprotection deployment was slightly botched (Template:Bug). 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)Antwort
Aha, so the bug actually came in with gerrit:153302. --Redrose64 (talk) 11:56, 19 August 2014 (UTC)Reply

Making a template

On my userpage I have a set of instructions that I drew up—see [2]—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)Reply

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)Antwort
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)Antwort
You've put it on User talk:P123ct1/My template rather than User:P123ct1/My template -- WOSlinker (talk) 13:46, 19 August 2014 (UTC)Antwort
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)Antwort
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)Antwort
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)Antwort
I've got the hang of it now. Thanks for everyone's help. --P123ct1 (talk) 15:22, 19 August 2014 (UTC)Reply

Unable to view a video on Mac!

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 bits.wikimedia.org and you need to whitelist this too. But, after i add bits.wikimedia.org to the whitelist, it will still say "bits.wikimedia.org 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)Reply

@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)Antwort
This post is about viewing a video on Wikipedia.S/s/a/z-1/2 (talk) 12:00, 19 August 2014 (UTC)Antwort
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 http://support.apple.com/kb/HT5678 ? 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)Antwort
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)Antwort
Our cortado applet is pretty broken currently. https://upload.wikimedia.org/crossdomain.xml 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)Reply

Hedonil's new search history tool

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/?project=en.wikipedia.org&article=Islamic+State+of+Iraq+and+the+Levant&text=agreed+to+supply+Kurdish+forces, 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)Reply

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

Animated gifs and "thumb"

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

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)Antwort
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)Antwort
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)Antwort
Thanks. Than explains it then. JMP EAX (talk) 18:28, 21 August 2014 (UTC)Reply

Wikibreak broken

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

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

"Unused" list defined reference error is unnecessary and obnoxious

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 [3] 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: [4])

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

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)Reply
And List-defined references were a request on Bugzilla, as were the Template:Agrl. 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)Antwort
"you should not have references that were unused" means "you should not have WP:General references". WhatamIdoing (talk) 16:57, 20 August 2014 (UTC)Reply
The fundamental problem is not the "list defining" feature, nor the feature to report unused references, but the used of the "named" refs (in the form of "<ref name= ...>"). Named refs supposedly solve the problem of how to reuse a reference, but tend to create problems where slave refs are dependent on master refs in other sections. It is the use of named refs that are obnoxious. And unnecessary. ~ J. Johnson (JJ) (talk) 20:48, 21 August 2014 (UTC)Reply

Is there an anti-ITALICTITLE?

  Resolved

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

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

Make all redirects soft using JS

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

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)Antwort
@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)Antwort
@23W: Probably the best way to do this is though JQuery. $("a.mw-redirect").attr("href", function(count, value){return value + "?redirect=no";}) should do it. Writ Keeper  23:05, 19 August 2014 (UTC)Antwort
@Writ Keeper: This works perfectly. Thank you! 23W 23:12, 19 August 2014 (UTC)Reply

What's up with Firefox and security certificates?

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

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

Do the certificates look legit? Max Semenik (talk) 17:18, 20 August 2014 (UTC)Antwort
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)Antwort
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)Antwort
Seeing they doesn't match, you may be a victim of the Man-in-the-middle attack where a peer tries to intercept your traffic. It happens commonly in workplaces. Try to use another connection or check your computer for viruses. Do not use the connection for online banking. See also: https://bugzilla.mozilla.org/show_bug.cgi?id=460374 Zhaofeng Li [talk... contribs...] 18:46, 22 August 2014 (UTC)Antwort
Well that's interesting... Who's the certificate issued by, issued to, etc? Somebody is certainly spying on your connection, maybe looking at who the cert is issued by will give you a hint if its some web filter sort of thing, or if its actually somebody malicious. Bawolff (talk) 18:58, 22 August 2014 (UTC)Reply
  • The "2001 version" is what happens when the CSS files don't load. Did you try it with other browsers? Other internet connections? It could be a restriction placed on your network. KonveyorBelt 18:27, 20 August 2014 (UTC)Reply
It's fine with other browsers. I'm using Chrome to edit right now. And IE has checked out fine. But Firefox is still screwing me over. Daniel Case (talk) 19:21, 20 August 2014 (UTC)Antwort
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)Antwort
Did all that ... no change. Daniel Case (talk) 22:58, 20 August 2014 (UTC)Reply

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

Not necessarily lost interest... I'm out of ideas, and I suspect other people may be too. --Redrose64 (talk) 18:14, 22 August 2014 (UTC)Antwort
Its probably because firefox is detecting someone is intercepting the connection (aka MITM attack), and is refusing to load stylistic information as a security precaution. Bawolff (talk) 18:58, 22 August 2014 (UTC)Antwort
Problem solved: That was it. I just purged a bunch of crapware my son had unknowingly installed in the last couple of days. It's back to normal. I am getting the right fingerprint. Never mind ... Thanks everyone. Daniel Case (talk) 04:24, 23 August 2014 (UTC)Reply
  • I use Firefox (version 31.0) and haven't had a bit of trouble with anything. In fact, some bothersome kinks in the prior version (after the massive redesign that made me unhappy) have been remedied. So I'm back to my old happiness level with it. Maybe something about your security settings? (Just a guess as I'm no Firefox guru.) Or uninstall and reinstall? Parabolooidal (talk) 18:28, 22 August 2014 (UTC)Reply

"Old templates"

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

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

It sounds like a problem between you and Wikipedia. Have you tried with a different computer (or mobile device) on the same network ? Tried restarting your modem ? If that's the same, then the problem probably lies at your ISP or something. —TheDJ (talkcontribs) 08:41, 21 August 2014 (UTC)Antwort
I've already tried a few things, including restarting my ADSL box, unfortunately to no avail. It could be something up to my ISP (and most probably it is), but the strange thing is that I see no such issues when accessing other web sites. — Dsimic (talk | contribs) 09:16, 21 August 2014 (UTC)Antwort
That doesn't say much. The Internet is a web of webs, one part can break without affecting others. —TheDJ (talkcontribs) 10:06, 21 August 2014 (UTC)Antwort
I'm very well aware of that. :) Anyway, the images work now. — Dsimic (talk | contribs) 04:39, 22 August 2014 (UTC)Reply

Google showing wrong title in search results

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

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

I just created "This article ranked 1609 in traffic on en.wikipedia.org. "

I just created Promod, an article on a notable but not very remarkable major fashion chain (1,000 stores, gross sales of 1 billion euros, blablabla). The article fills a major need though, considering that it is "ranked 1609 in traffic on en.wikipedia.org."[5]!

Now, I'm more than aware of the problems with page views, and the very improbable hits some pages get, but this one doesn't seem to match any of the usual patterns, and gets an extremely constant number of views per day (I guess the variation is caused by real people actually looking for this article). Any guesses on where the page views are coming from in this case? In any case, it vastly increases the total number of page views on articles I created :-) Fram (talk) 10:17, 21 August 2014 (UTC)Reply

(What Links Here has too few links to be the cause?)
Maybe people who checked fr:Promod and replaced "fr" with "en" in the title? --Enric Naval (talk) 10:50, 21 August 2014 (UTC)Antwort
It does not look like the came from fr:Promod, that has only been looked at 1816 times in the last 90 days[6]. GB fan 11:02, 21 August 2014 (UTC)Reply
The page has had (almost exactly) 5400 views per day every day since February 27, 2014. This is a sure indication that the views are coming from a bot, and I will guess it is looking for Call of Duty 4 Promod, whose new major version was released the same day as the views started (Feb 28). Or (very unlikely) just a lot of gamers wondering why their favorite mod isn't on Wikipedia. 2Flows (talk) 19:19, 22 August 2014 (UTC)Reply

My bad

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

It shouldn't. Incoming, there will be a field missing then, causing an error. On save there should also be checks. Pondering. do you perhaps have wikEd or a live preview/edit script enabled ? —TheDJ (Not WMF) (talkcontribs) 19:16, 21 August 2014 (UTC)Antwort
I have pop-ups enabled if that is a factor.—John Cline (talk) 09:20, 22 August 2014 (UTC)Antwort
John, do you remember whether you were editing a single section or the whole page? WhatamIdoing (talk) 00:42, 24 August 2014 (UTC)Reply

Letter petitioning WMF to reverse recent decisions

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

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

-- JurgenNL (talk) 17:35, 21 August 2014 (UTC)Reply

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

Process ideas for software development


Hello,

I am notifying you that a brainstorming session has been started on Meta to help the Wikimedia Foundation increase and better affect community participation in software development across all wiki projects. Basically, how can you be more involved in helping to create features on Wikimedia projects? We are inviting all interested users to voice their ideas on how communities can be more involved and informed in the product development process at the Wikimedia Foundation.

I and the rest of my team welcome you to participate. We hope to see you on Meta.

Kind regards, -- Rdicerb (WMF) talk 22:15, 21 August 2014 (UTC)Reply

--This message was sent using MassMessage. Was there an error? Report it!

MAC anons

So what's up with those MAC anon's I see every now and then (ex. 2602:306:CD54:C180:A849:3C3F:EDB9:5E6 (talk · contribs))? Is there some kind of IP-alt way to edit with a MAC instead of an IP address showing? --Piotr Konieczny aka Prokonsul Piotrus| reply here 07:10, 22 August 2014 (UTC)Antwort

Those are actually IPv6 addresses. They're simply the next iteration of IP addresses that are slowly becoming the norm, with IPv4 being the one you and I are used to right now. ~SuperHamster Talk Contribs 07:18, 22 August 2014 (UTC)Antwort
Also, MAC addresses are six bytes, such as 01:23:45:67:89:ab (and you don't need to have an Apple to have a MAC address); IPv6 are much longer, at 16 bytes. By comparison, the old IPv4 addresses are only 4 bytes. --Redrose64 (talk) 10:27, 22 August 2014 (UTC)Reply

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

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

Edit conflict?

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

I have encountered that maybe half a dozen times, which was maybe 25% of my edits. HiLo48 (talk) 08:06, 23 August 2014 (UTC)Antwort
Specific examples (diffs of articles where this happened) plus browser information welcome. --AKlapper (WMF) (talk) 13:48, 23 August 2014 (UTC)Reply

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

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

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

iPhone app bugs

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

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

Thanks! GoingBatty (talk) 15:20, 23 August 2014 (UTC)Reply

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

Standalone version of meta:WikiMiniAtlas or alternative?

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

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

Article traffic statistics incorrect

From Wikipedia article traffic statistics:

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

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