Wikipedia:Village pump (technical)

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

wikimedia.org.

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

view · edit

Frequently asked questions (see also: Wikipedia:Technical FAQ)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.

No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an `accesskey` property on it (default to `accesskey="f"` in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.

No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.

If you have problems making your fancy signature work, check Help:How to fix your signature.

If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.

If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

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

RfC concerning template space

Protecting template space and creating a user right

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following list:

Wikipedia proposals

When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

More and more concerns seem to be coming up concerning the template namespace.

I look at a random sampling of templates, and most are at least semi-protected, if not fully protected. This has happened I think due to various concerns about vandalism across many pages by simply editing a particular template.

So with that in mind, I'd like to suggest two things:

1.) that like MediaWiki space, template space be fully protected. We might as well accept that this is the current state of affairs.

2.) the creation of a new userright (template editor or some such) which allows editing in this now-protected template space. This user-right could be given out by admins through whatever process the community subsequently decides.

This also would have the added benefit that I have seen many template coders ask for for YEARS. That while they have no interest in becoming admins, it would be greatly helpful for them to at least be able to edit protected templates. This would do that but without also giving them the ability to edit any protected page, just merely those in templatespace. - jc37 12:13, 29 May 2012 (UTC)[reply]

Support

Me - obviously : ) - jc37 12:13, 29 May 2012 (UTC)[reply]
Conditional support: I support the continued unpacking of the administrator user-right, for those who have no desire to take on the full toolset and to blur the excessive boundaries between non-sysops and sysops. Given that there is some genuine need for a 'template-editor' user right, I am happy to support this proposal. However, I do not see a need for the blanket protection of the template namespace. AGK [•] 17:34, 29 May 2012 (UTC)[reply]
Conditional support - Personally I think people have gone way overboard with protecting and semi-protecting every template they can get their hands on. Since I do not see this changing and in fact only getting worse I feel myself compelled to agree with this proposal. Kumioko (talk) 22:50, 29 May 2012 (UTC)[reply]
Support - There are many templates that just need maintenance. As the project grows and changes so does the need to update and maintain templates. I would go as far as to suggest a Wikiproject to go along with the user right, a GOCE for templates if you will. Mlpearc (powwow) 17:11, 31 May 2012 (UTC)[reply]

Oppose

There are plenty of regular templates, that are either incomplete or have mistakes. A lot IP-based editors edit and help us increase content [proper content]. Protecting high risk templates is fine, but all, isn't good. --Rsrikanth05 (talk) 13:25, 29 May 2012 (UTC)[reply]
Even more: I see IP editors submitting templates through AFC, moreover the majority of templates are either infoboxes or navigation templates and thus not really complex (in the programming) which can be easily created by 'the average editor' which really don't need any more bureaucratic! mabdul 14:39, 29 May 2012 (UTC)[reply]
Except that infoboxes and navboxes are types of templates which are likely to be protected in some way due to widespread use across many pages. - jc37 14:50, 29 May 2012 (UTC)[reply]
Check your watchlist and give me 5 protected nav templates. I only know two! Navigation templates are normally transcluded 3 to ~30 pages and thus protection is only granted because of edit warring and high vandalism (like Template:HTTP) - many infoboxes are also not that often transcluded, yes there are a few big ones, and Thumperward (sry if I misspelled your nick Chris, sry if I miss somebody) was cleaning up them (by TfD') the last few months, but the majority is still unprotected and I also see no reason why they should be protected by default only for the sake of 10 transclusions. mabdul 17:12, 29 May 2012 (UTC)[reply]
If we give the Template: space a protection mechanism similar to that of the MediaWiki: namespace, this will remove the possibility of unprotecting selected pages (if you are an admin, try unprotecting any MediaWiki: page to see what options are available). People without the necessary access level would not just be prevented from editing "regular" template pages, they would no longer be able to edit the subpages in Template: space. This includes the documentation pages, which are rarely protected (I have seen one or two cases of a semi-protected /doc page); and the sandbox and testcases pages, which I have never seen to be protected. --Redrose64 (talk) 14:57, 29 May 2012 (UTC)[reply]
Maybe. but consider: those who might be the ones to edit such pages might be the ones who could easily ask for the userright. Compare this to the prevalence of rollbacker. - jc37 19:55, 29 May 2012 (UTC)[reply]
They might be foreign-language editors who only occasionally visit English Wikipedia for the purpose of adding or amending an interlanguage link (as here). Turn it around: would I have been able to contribute to the беларуская Wikipedia as easily, if that Wikipedia had been set up so that I had to jump through the hoops proposed here? I don't speak Belarusian at all, and can barely read a few words (I only know that беларуская means Belarusian because I stuck it through a translator). What chance would I have of requesting a user right, or even of submitting their equivalent of {{editprotected}}? --Redrose64 (talk) 20:37, 29 May 2012 (UTC)[reply]
Ok, the interlanguage links are tough to argue. (No fair introducing calm logic and reason in a discussion, I thought we were on Wikipedia...lol) - jc37 21:17, 29 May 2012 (UTC)[reply]
If Happymelon's figures below (5% currently protected) are correct, this seems like overkill. You'd effectively be protecting ~400k pages, many of which are currently either wrong, or will soon be out of date. Worm^TT(talk) 15:04, 29 May 2012 (UTC)[reply]
I wouldn't want to see the entire namespace protected or even semi-protected, but if a new user right for editing protected templates (for non-admin obviously) was proposed I'd support that. — Bility (talk) 15:13, 29 May 2012 (UTC)[reply]
I agree with Bility, as protecting the entire template namespace would be complete overkill.--yutsi ^Talk/ Contributions 17:10, 29 May 2012 (UTC)[reply]
Oppose as overkill. The idea of creating a user right to edit at least a subset of protected templates does appear worth exploring. Hullaballoo Wolfowitz (talk) 18:00, 29 May 2012 (UTC)[reply]
Oppose. There's no good reason to protect the entire namespace. Support the creation of a new user right, with the caveat that it is to be used only for editing protected templates and is not meant to be a hurdle to editing the template namespace in general. Orange Suede Sofa (talk) 18:56, 29 May 2012 (UTC)[reply]
Oppose, but agree with Bility that there might be room for a non-admin template editor permission. See updated proposal, below. Van Isaac_WS^contribs 19:58, 29 May 2012 (UTC)[reply]
Oppose - & agree with OSS above, the idea of the user right only for protected templates is a good idea. Skier Dude (talk) 23:33, 29 May 2012 (UTC)[reply]
Oppose - while requiring autoconfirmed to edit base templates (that is, non-subpage Template: namespace pages) is probably a good idea, requiring any higher level as a necessity to editing templates, or including the /documentation pages in the rule, is a problem. A large number of base templates may need full protection (either because of high visibility or because they're very complicated nd easy to mess up by mistake), but most probably don't. עוד מישהו Od Mishehu 08:33, 30 May 2012 (UTC)[reply]
Oppose as most, if not all, navbox templates and low-visibility template have little need to be protected. This would also bother deletion nominations, if even the junk templates were given full protection. — Crisco 1492 (talk) 13:25, 30 May 2012 (UTC)[reply]
Oppose low visibility templates have little need for this. Miyagawa (talk) 18:15, 30 May 2012 (UTC)[reply]
Oppose I've edited literally thousands of templates, and except for a few high-visibility ones, none have been even semiprotected. If the premises for this proposal were accurate, I'd support, but good reasoning needs good data to produce a good argument. Nyttend (talk) 03:48, 1 June 2012 (UTC)[reply]
Oppose, un-wiki. We should attempt to be an encyclopedia that anyone can edit, and so we should never protect any page that doesn't really really need to be protected. —Kusma (t·c) 18:58, 3 June 2012 (UTC)[reply]
Oppose Highly visible templates can be semi-protected or fully-protected, but protecting the whole namespace doesn't seems right. ♛♚★Vaibhav Jain★♚♛ ^Talk ^Email 09:44, 5 June 2012 (UTC)[reply]
Oppose I do not normally edit templates. However, there was an occasion when I discovered that a template (about positrons, if I remember correctly) had been corrupted. It was used in many articles, but no one had fixed it because the nature of the corruption blocked the usual editing process. I found a way around that and reverted to an earlier version which was acceptable. If this proposal was implemented, I doubt that I would have been able to do that. JRSpriggs (talk) 12:21, 5 June 2012 (UTC)[reply]
Oppose I don't see how one could judge whether a person was fitted to be an editor of templates. Deb (talk) 17:17, 5 June 2012 (UTC)[reply]
Oppose seems like overdoing it to protect the entire namespace. — MrDolomite • Talk 17:19, 5 June 2012 (UTC)[reply]
Oppose To many templates are already protected, this would make things worse not better. A root-and-branch review of templatology would be of more use, sprawling infoboxes, navboxes, portals on every page, project links in mainspace (tsk tsk) and so forth, citations in a knot. Rich Farmbrough, 14:44, 6 June 2012 (UTC).[reply]
Oppose. The mechanism to resolve these concerns exists, and is far less draconian than fully protecting a namespace which, in many instances, a non-expert could create a legitimate new template in by copying markup from an existing one. I believe the correct mechanism is to implement Flagged Revisions for the Template: namespace. This works perfectly well on enWN, and no amount of template vandalism can result in things like Featured Articles linked-to from the main page containing vandalism being displayed to non-logged in users. --Brian McNeil /^talk 16:05, 8 June 2012 (UTC)[reply]
Oppose snowball? Arcandam (talk) 16:17, 8 June 2012 (UTC)[reply]
Per Kusma. Rcsprinter (orate) 15:55, 12 June 2012 (UTC)[reply]
Oppose. I don't see any reason to believe that the current system of protecting high-impact templates and allowing edits on others is not working and needs to be adjusted. This is a solution in search of a problem. elektrik SHOOS (talk) 03:04, 13 June 2012 (UTC)[reply]

RfC - proposal for template editor user-right

Ok, based on the above, it sounds like there might be a fair amount of support for the user-right - template-editor

~~This would allow the ability to edit full or semi protected pages, but limiting it to only in template space.~~

This would give the user-right:

allows to edit protected pages (without cascading protection). (editprotected)

This user-right could be given out by admins through whatever process the community subsequently decides.

This also would have the added benefit that I have seen many template coders ask for for YEARS. That while they have no interest in becoming admins, it would be greatly helpful for them to at least be able to edit protected templates. ~~This would do that but without also giving them the ability to edit any protected page (a named concern in the past), just merely those in templatespace.~~ - jc37 20:09, 29 May 2012 (UTC)[reply]

Also, I'd be interested in what you all think about this user-right also having:

Edit other users' CSS files (editusercss)
Edit other users' JavaScript files (edituserjs)

As helpful coders, that just makes sense to me. But I'm of course open to others' thoughts on this. - jc37 20:24, 29 May 2012 (UTC)[reply]

Struck a line, and added the user-right description, based upon information gained in the discussion. - jc37 09:39, 30 May 2012 (UTC)[reply]

Support

Me (again) of course : ) - jc37 20:09, 29 May 2012 (UTC)[reply]
I agree, but I would also support template editors being able to set the protection level in the template namespace as well. My only concern is that template editors should not prematurely deny access by the original template creator(s). If the goal is to help protect the most intricate and arcane namespace in WP, then protection for pages not involved in content disputes (which should always be handled by admins) would probably best be handled by people who really understand the intricacy and arcana. Van Isaac_WS^contribs 20:16, 29 May 2012 (UTC)[reply]
While at first blush I might agree, from long experience, I think that giving out the ability to protect a page - any page, even if just templates - is a drama fest waiting to happen : ) - jc37 20:22, 29 May 2012 (UTC)[reply]
That's a fair point. I just think that the template namespace is the kind of area where it might be hard to find admins who really understand the pages in the first place. How many of the current templates were protected at the request of a template editor - both the general meaning, and someone who would qualify for the new permission - getting an admin who has no clue to do it for them? If we are going to have users that we trust with the keys anyway, it's probably best if they can lock up the place when they're done. Van Isaac_WS^contribs 20:39, 29 May 2012 (UTC)[reply]
Support per my comments above in the previous discussion. Kumioko (talk) 22:54, 29 May 2012 (UTC)[reply]
Support unbundling of all user rights as well as the implementation of this specific proposal. A note of caution though, these templates are fully protected for a reason, and there is potential for abuse when editing user .js and .css pages, so this right should only be assigned to trusted users, not just anyone who is technically capable of coding templates/javascript/css. And although the ability to protect/unprotect may technically go hand-in-hand with editing, I think this should still only be done by admin. Basically there should be a lot of honor code restrictions to the point where you might as well just make these candidates admin, but I'll still support because it's a good idea in theory, even though I don't think MediaWiki is currently sophisticated enough for the nuanced restrictions this would need. — Bility (talk) 23:23, 29 May 2012 (UTC)[reply]
Support anything that puts more tools in the hands of users who will use them to better the wiki. While most users who would qualify for this would qualify for higher positions, this is better suited for those with no interest in getting into the political side of things. -- LWG ^talk 04:36, 30 May 2012 (UTC)[reply]
Support - per my comment in the section above. Mlpearc (powwow) 17:13, 31 May 2012 (UTC)[reply]

Oppose

Quick note; please don't take the lack of interest in discussing this proposal (or its duplicate) as approval. ▫ JohnnyMrNinja 20:58, 29 May 2012 (UTC)[reply]
Oppose Given that there is not only a technical expertise needed for this, but also a relatively wide level of knowledge of policy (protection & else-wise), my thought is that anyone given this right would be a person that fits the qualifications of a sysop. I do see the problem, however, of someone who has the skills for this specific area possibly being put off by the wikidrama & stress of RFA. (OK, not just someone who has the tech skills, but anyone with a modicum of sanity :-o) Skier Dude (talk) 23:45, 29 May 2012 (UTC)[reply]
I'm confused. You supported this idea in the above proposal, why do you oppose it here? - jc37 08:55, 30 May 2012 (UTC)[reply]
Oppose - Especially the editing other users' css and javascript files. There is no need to give out the right to editors to edit protected pages only in Template space; they can copy the code to user space to tinker with it. — Crisco 1492 (talk) 13:22, 30 May 2012 (UTC)[reply]
Was that a promise to be active in processing edit protected requests should your RfA pass then? :P — Bility (talk) 16:03, 1 June 2012 (UTC)[reply]

This is wholly unfeasible for templates that are the slightest bit complex and which often require bits of minor troubleshooting after changes are made. The edit protection process is far too timely. - ʄɭoʏɗiaɲ ^τ _¢ 21:51, 6 June 2012 (UTC)[reply]
Oppose. There may be some merit in the idea of some sort of trusted "senior editor" group but (1) it is a policy question, the technical issues would follow, and (2) I don't like proliferating breakouts for "rollbackers", FlaggedRev "reviewers", "template editors", "protection exemption", etc. There are a few individual rights that make sense to me because they involve technical means for massive action (e.g. bots, importers) and/or non-public information (e.g. edit filter); but in an encyclopedia that anyone can edit there ought to be at most one level of general trust between "confirmed user" and "administrator". ~ Ningauble (talk) 12:42, 5 June 2012 (UTC)[reply]
Administrators are expected to be temperless drones that represent the maturity of the encyclopedia, a trait that many coders lack, myself included. Getting through an RFA is like holding a public consultation meeting in a NIMBY neighbourhood - pile on. - ʄɭoʏɗiaɲ ^τ _¢ 21:51, 6 June 2012 (UTC)[reply]
I agree about RfA, but my point is that I do not support creating 16 different kinds of editors. I have only made a few edits in template space, but if I had to ask for special permission, even in a less onerous process than RfA, I would have made none at all. ~ Ningauble (talk) 19:07, 7 June 2012 (UTC)[reply]
Support in spirit, oppose in reality On one hand I see this as a symptom of the admin bit becoming far more important than it ever was supposed to be. On the other hand, breaking another user right out of it would help both dilute the "power" of adminship, as well as strengthen it. Another concern is that I think that this user right being broken out would encourage even more wide spread protection of templates than there already is, which goes against the spirit of a wiki. So I'm not entirely opposed to this in that I think it addresses a real problem, I'm afraid of the additional problems it creates. The cascading problem brought up below is a technical matter that needs to be addressed as well for a proposal like this. Gigs (talk) 14:01, 5 June 2012 (UTC)[reply]
Oppose per above. I believe that this will result in many template created/hacked in a new "mainspace" like Madonna/navtemplate and then transcluded. This won't solve anything! There is always a workaround! mabdul 18:58, 5 June 2012 (UTC)[reply]
I'm not positive, but I think your comments apply to the nom directly above this nom. This one is merely about creating the user-right template-editor. - jc37 11:26, 6 June 2012 (UTC)[reply]
Why do we need this? Do you often do RC work and recognize vandalism in T-space (or better saying unrecognized v in T space)? mabdul 20:38, 6 June 2012 (UTC)[reply]
Because many editors that are exceptionally good at coding templates, including many of the ones which have since become fully protected under WP:HTA, are not considered worthy of the mop and the additional responsibilities it brings. Protecting pages, banning users, acting as mediators and judges, etc. - ʄɭoʏɗiaɲ ^τ _¢ 21:51, 6 June 2012 (UTC)[reply]

jc, for me at least, I think that this latter proposal would end in a de-facto situation of all of template space being protected, even if it's not technically part of the proposal. The user right being broken out would mean that people would apply protection far more liberally. Gigs (talk) 12:53, 8 June 2012 (UTC)[reply]
Oppose for the same reasoning as with full-protection. The requisite functionality exists within Flagged Revisions, logged-in users can see changes, and IPs not. The ability to set review levels, and have these as userrights, allows more control. There's been extensive discussion on the WM-UK mailing list after template vandalism hit Elizabeth II during the Jubilee weekend. I know the debate on FlaggedRevs in main namespace will rage for a long, long time; in the case of the Template: namespace it seems far more sensible. --Brian McNeil /^talk 16:10, 8 June 2012 (UTC)[reply]
Oppose Arcandam (talk) 16:18, 8 June 2012 (UTC)[reply]
Oppose as stated above: I don't see any evidence to suggest that the current system is broken and needs to be fixed. This is a solution in search of a problem. elektrik SHOOS (talk) 03:09, 13 June 2012 (UTC)[reply]

Discussion

There are about 17,590 protected pages in the template namespace, out of 424,000 pages in total, although that includes documentation, sandbox and testcase pages. So the fraction of pages in the template namespace that are protected is actually very low, maybe 5%, although that is still higher than any other namespace. I wouldn't be adverse to having the template namespace semi-protected, but I think full protection is overkill. Happy‑melon 12:35, 29 May 2012 (UTC)[reply]

I have no idea how MediaWiki namespace is protected. But basically my goal was to simplify things for the devs and just have template space done the same way.

That said, I suppose I would be fine with semi- too. Though when I look how many people uncontroversially have various other admin-given userrights, I don't think that this would be any sort of great hindrance to editing. - jc37 12:44, 29 May 2012 (UTC)[reply]

The mechanism is the same as I mention below for how the template namespace could be protected, but it cannot be overridden in the wiki configuration ($wgNamespaceProtection[NS_MEDIAWIKI] is overridden after the configuration is read). Anomie ⚔ 16:40, 29 May 2012 (UTC)[reply]

I don't think this particular proposal is going to go anywhere, for the reasons Redrose64 has already pointed out. But for the sake of argument, it would be easy to create a new "template-edit" user right and protect the entire namespace so only users with that right could edit the template namespace. All that would need to be done would be to make a shell request to add something like this to the configuration for enwiki:

$wgNamespaceProtection[NS_TEMPLATE] = array( 'template-edit' );
$wgGroupPermissions['template-editors']['template-edit'] = true;
$wgGroupPermissions['sysop']['template-edit'] = true;

And then create a handful of MediaWiki-namespace pages so a correct description shows up on Special:ListGroupRights and so on. And maybe edit some of the messages/templates that display the protection notices, and probably also update some bots (or just give the "template-edit" right to all bots).

It's even easier to semi-protect or fully-protect the entire namespace, all that's needed in the shell request is $wgNamespaceProtection[NS_TEMPLATE] = array( 'autoconfirmed' ); or 'sysop'. Anomie ⚔ 16:40, 29 May 2012 (UTC)[reply]

For that matter, if you wanted to propose creating a level of protection in between "autoconfirmed" and "sysop", you might have trouble with WP:PEREN#Hierarchical structures or the same logic that killed WP:ACTRIAL, but it's still easy enough technically:

$wgRestrictionLevels[] = 'template-edit';
$wgGroupPermissions['template-editors']['template-edit'] = true;
$wgGroupPermissions['sysop']['template-edit'] = true;

It would probably be even more essential here to update messages and templates, as many currently check for either "autoconfirmed" or "sysop" and assume if it's not the one it must be the other. Anomie ⚔ 16:40, 29 May 2012 (UTC)[reply]

Thanks you much for the info! : ) - jc37 19:42, 29 May 2012 (UTC)[reply]

I think a fair amount of ink would be saved if you introduced these proposals as the discussions that they ought to be rather than the invitations to jump straight to a polarising vote that they are. It would allow people to note, for instance, that this has been discussed numerous times before, always with a negative outcome. An important consideration is that it is not technically possible to give users the ability to edit templates that have been cascade-protected without also giving them the ability to implement such protection (otherwise they could just edit the cascade-protected page to transclude whatever template they wanted protected, and achieve the same effect). Happy‑melon 20:36, 29 May 2012 (UTC)[reply]

I'm more than happy to discuss (as I know you know : )

Honestly, the main reason I set the above up this way is I had just come from the arbcom RfCs.

Anyway, as far as protection - I noticed the the ability to edit and the ability to protect a page seem to be the same user-right:

Change protection levels and edit protected pages (protect)

And I also don't know if it's possible to limit this to a single namespace (though from the above, I "think" it's possible).

I also still think the first proposal is a good idea. it's just looking at things from another direction. People are so used to "autoconfirmed" happening automatically, they don't think about the fact that it's actually a bestowed user-right package. - jc37 20:55, 29 May 2012 (UTC)[reply]

Arbcom's methods are so unlike Wikipedia's that it might as well be some other project. It's darned near impossible to follow a discussion there, because you're not allowed to post a response directly below the post that you're responding to - it will always be in a different section, maybe on a different subpage. Anyway - if this and the previous threads are RFCs, why don't I see any {{rfc}} at the top? --Redrose64 (talk) 21:08, 29 May 2012 (UTC)[reply]

ROFL Um right, the template. Well to be honest, I played with it, but the switches seemed to be for various RfC subpages and not the VP, so I didn't. That said, I'll happily claim ignorance, and would welcome help : ) - jc37 21:22, 29 May 2012 (UTC)[reply]

(edit conflict) I think you misunderstood slightly. It's not possible (without recoding MediaWiki) to create a right for "can edit pages protected 'sysop' in X namespace". It is possible to limit editing of an entire namespace to people with a particular right, and it is possible to create a new protection level (which could be used on any page) with a corresponding new right to edit any page protected at that level, and then create an enwiki policy that the new protection level may only be used in the Template namespace. Anomie ⚔ 21:19, 29 May 2012 (UTC)[reply]

Ahhh, thank you for the clarification. Let's focus on the latter option for a minute. How would this affect semi-protection? would these template-protectors be able to semi-protect a page as well? - jc37 21:30, 29 May 2012 (UTC)[reply]

There wouldn't be any "template-protectors", just "template-editors". It's not possible to give someone the ability to protect pages without giving them the ability to edit fully-protected pages, due to the way the "protect" right is also used as the right for editing pages protected for 'sysop'. Anomie ⚔ 01:33, 30 May 2012 (UTC)[reply]

That's why I started calling them protectors above. just wasn't sure how the "levels" of protection worked. Thanks for clearing that up : ) - jc37 08:55, 30 May 2012 (UTC)[reply]

Sorry Happy, but I went through a lot of the pages you linked to above, and it looks like this has really only been seriously discussed once, in May of last year, and it was a much less formal sort of request. I think with a more clear discussion and proposal that we might be able to hash out an acceptable solution. My question to the peanut gallery is whether there is a way of allowing users to edit protect templates, but not cascade protected? Van Isaac_WS^contribs 21:12, 29 May 2012 (UTC)[reply]

It's well-trodden ground because, as noted above, it is not possible to restrict these editing permissions to a single namespace. As such it's no different to creating an "edit protected pages group" or adding a new layer of protection for all pages, both of which have had their own set of discussions (to the point of making WP:PEREN). So the answer 'from the peanut gallery' is as Anomie says: it is possible to create a group which can edit all fully-protected pages that are not cascade-protected, in any namespace; or it is possible to create a protection level and corresponding group, which could technically be implemented on all pages; but there is no way to technically restrict either of these to one namespace. Happy‑melon 21:59, 29 May 2012 (UTC)[reply]

As for the right to edit JS/CSS, it may be worth looking into the new user rights which will be available with mw:Gadgets 2.0. Helder 23:52, 29 May 2012 (UTC)[reply]

Interesting read. But for now, just trying to make this as simple as possible and just suggesting existing user-rights as listed at Special:ListGroupRights. - jc37 08:55, 30 May 2012 (UTC)[reply]

I raised a similar proposal on Commons recently (here), to create a new usergroup with editinterface and editprotected rights. I don't think we need to worry too much about limiting editprotected by namespace; abuse of the right tends to be pretty public and getting kicked out of such a new usergroup will be like removing rollback, not desysopping. So the question becomes more about trusting users to edit potentially dangerous areas (interface, JS, gadgets), which is really down to the procedure for handing out the user right (it was this concern which kiboshed the proposal on Commons). In short, all this stuff about the template namespace is just over-complicating things; the issue is, do we want a "technician"-type usergroup for people who are technically capable but either unable to pass RFA or unwilling to try or unwilling to take on the broader responsibility of adminship? I think it would be helpful - but that's not what's being discussed. PS Why is this at VPT and not WP:VPR? Rd232 ^talk 00:02, 30 May 2012 (UTC)[reply]

The reason it's here is I'm asking about the user-right, not how it will be given out. That's obviously a separate discussion, as I noted above. - jc37 08:55, 30 May 2012 (UTC)[reply]

You're not asking for technical help or information, you're making a proposal which happens to require a change in the software. That's VPR territory, not VPT. Rd232 ^talk 09:42, 30 May 2012 (UTC)[reply]

I don't know if this whole thing should have been on Village Pump or not, but I have a couple of thoughts overall:

About 90% (est) of what I see popping up as new articles by unregistered editors should have never made it past a screening process (which I'm assuming does not exist). I'm just completely amazed by how easy it is to use the "spaghetti cooking method" of creating new articles - throw it against the wall and see if it sticks. Maybe there's a similiar phenomenon happening on new templates. Maybe not. New templates and new articles by unregistered editors should probably have identical screening processes in place. And along those lines, I see little difference between vandalizing articles and vandalizing templates. Protect the ones that need it, just like it is now.
If such a new Template Editor right happens, then I hope some admin thinks I should have that. Templates are a valuable editing tool. Whether or not Template Editor should exist, I'm up in the air about. Maile66 (talk) 12:59, 30 May 2012 (UTC)[reply]

I think that's part of the problem right there. While it is easy for just about anyone to notice and correct vandalism of articles, it requires an amount of skill and knowledge to necessarilly recognize the same in a complex template. Unless someone in the know has a particular template on their watchlist, a template vandalism - accidental or otherwise - may not be recognized for what it is, especially if it will only show up in a subset of transcluding pages. By restricting editing of certain complex templates to people who have demonstrated a level of knowledge, that both helps fight vandalism, and enables template upgrades. As for CSS/JS editing, I don't know enough about it to say one way or the other whether that is necessary or even desirable, so my gut says "no" on that. Van Isaac_WS^contribs 00:51, 31 May 2012 (UTC)[reply]

That logic is backwards. Because only experts can recognize vandalism, only experts should edit? Maybe you mean that we should have more experts. Everyone knows how to undo, and experts aren't made by removing access. How exactly do these editors learn enough to gain the right? Huge surprise this hasn't been "seriously" discussed before. This proposal is contrary to the entire point of this website. I shouldn't need to beg an admin to let me edit a goddamn template when I've been doing fine for years. Fuck that. I understand that this was proposed as a well-intentioned benefit to WP, but the deliberate removal of the rights of editors is not a "fun idea" to be bandied around without reason. Stop trying to limit the rights of new users in unnecessary ways, or if there are valid reasons, please list them in an exact and clear way so they can be addressed. People that deliberately vandalize templates already know their way around WP. Navboxes aren't so precious that they are worth driving away new editors. Most templates are not protected, just the most visible, which is why you're seeing them in the first place. Most of those templates were protected as a preventative measure, and not based on any actual vandalism. Nothing on WP has pissed me off more than creating/expanding a template only to come back and find that I can't edit it, thanks to a proactive paranoid admin. Also, it's pretty bad form to make a proposal on VPT, especially one that will only benefit people that frequent VPT. ▫ JohnnyMrNinja 10:58, 5 June 2012 (UTC)[reply]

Alternative: FlaggedRevs on Template: namespace

With both of the above votes going poorly, why don't you simply enable FlaggedRevs on the template namespace? Doesn't stop editing, just means it needs approved—a simple enough process.

For those not aware, there was template vandalism associated with Elizabeth II during the Jubilee celebrations, when the article was featured. Had FlaggedRevs been on templates, this would not have been possible. --Brian McNeil /^talk 15:02, 8 June 2012 (UTC)[reply]

Considering how much of a clusterf**k the previous sitewide discussion on flagged revisions was, I'm not sure proposing the same idea for a different namespace would be much more successful. But it might be worth a shot anyway. elektrik SHOOS (talk) 03:13, 13 June 2012 (UTC)[reply]

Diff/watchlist difficulties

Tracked in Phabricator
Task T39225

I'm a little puzzled about some recent edits to the Nicole Kidman article. For example this edit is one of several blank edits, which I thought were usually disregarded and shouldn't normally appear in the edit history. Also, when the blank edits showed up in my watchlist, it appeared that the edit added ~72,000 bytes of data (+72,000) although there was no change. --Bongwarrior (talk) 10:19, 30 May 2012 (UTC)[reply]

Odd. One thing that I, as an admin, can check is for deleted revisions (some times an admin may have deleted the page, and selectively restored some versions while leaving out all between 2 identical ones) - and in this case, there aren't any. עוד מישהו Od Mishehu 11:53, 30 May 2012 (UTC)[reply]

Same issue with this edit (and also the preceding one) at Admiralty Arch today. There's nothing in the history or watchlist entries indicating that the edits have been hidden. — Richardguk (talk) 11:57, 30 May 2012 (UTC)[reply]

Are you sure your watchlist didn't say (+73,930)‎ on Nicole Kidman? That's the page size shown in the page history and it says (+73,930)‎ for the blank edits on my watchlist when I enable "Expand watchlist to show all changes, not just the most recent" at Special:Preferences#mw-prefsection-watchlist. Here is another example from Sonia Sotomayor. If the software cannot retrieve the size of the preceding revision then I think it gives the page size as difference like if it had been 0 before. I don't know how MediaWiki identifies null edits so they can be omitted in logs but if it thinks the page size has changed then maybe it will never identify it as a null edit. PrimeHunter (talk) 21:23, 30 May 2012 (UTC)[reply]

Yes, 73,930 sounds right. I couldn't remember the exact number, and I didn't know of an easy way to go back and double check the exact number after I had already reverted the edits. --Bongwarrior (talk) 01:58, 31 May 2012 (UTC)[reply]

grand Theft Auto IV is another one. On the page history, the edits are 0, but on a watchlist they are +125,384 (as if created from zero). ☮Soap☮ 02:18, 1 June 2012 (UTC)[reply]

I was just going to ask about this. I've seen something similar at several articles, most recently Mario Chalmers. If you look at these recent changes, an IP is shown making three consecutive 18,826-byte additions, though the visible changes only account for 45 bytes. Zagalejo^^^ 02:35, 1 June 2012 (UTC)[reply]

~~Is it always three null edits? It seems so.~~ And http://en.wikipedia.org/w/index.php?title=The_Blitz&action=history shows it with an edit summary also repeated three times. It's unlikely he would have made four consecutive edits with the same edit summary. Im guessing that all of these cases are really just one edit apiece under the hood, which for some reason is "echoed" three or so times. ☮Soap☮ 02:37, 1 June 2012 (UTC)[reply]

I just noticed something similar that brought me here to the Pump: This edit, which shows no change in the diff and which didn't change the byte count in the page history, was shown as "+24,991" on my watchlist. The watchlist and history figures agree for the edit immediately preceding it. (I saved a screenshot, if any developer wants hard evidence in all its gory detail.) Rivertorch (talk) 04:38, 1 June 2012 (UTC)[reply]

I saw this earlier today (over 14 hours ago or so): this edit showed to have a change of +23,000k or so to the article (via the indicator on my watchlist) but the actual diff shows nothing. It was perplexing. Killiondude (talk) 06:44, 1 June 2012 (UTC)[reply]

This is what just happened to me about 3 minutes ago. My watchlist showed a (+27,138) change, but that was the size of the article at the time and the history showed 0 change - which is what it seemed to be, I can see no change here. Dougweller (talk) 16:41, 1 June 2012 (UTC)[reply]

Are developers aware of this? That is, has anyone here created a bugzilla report? I don't really care for the search function there. Killiondude (talk) 07:02, 4 June 2012 (UTC)[reply]

Bangalore and Mysore are two articles on my watchlist that have this problem currently -- the + value is the actual size of the article. —SpacemanSpiff 09:13, 5 June 2012 (UTC)[reply]

There is a variation of the problem in this June 1 diff. It's a null edit so it shouldn't have been recorded but unlike other reports, the edit and the predecing edit were by different users: Two bots making the same interlanguage change. Both edits say (+5) on a watchlist. This is correct for the first but the second should have said (0). The watchlist does not claim the page size 174,825 as the size of the change. PrimeHunter (talk) 12:02, 5 June 2012 (UTC)[reply]

I saw similar anomalies on recent changes and article history at Wikiquote yesterday: null edits that should have shown (0) showed up as (+article size). ~ Ningauble (talk) 15:42, 5 June 2012 (UTC)[reply]

Bug logged on 30 May 2012 as Bugzilla:37225. — Richardguk (talk) 01:45, 6 June 2012 (UTC)[reply]

Another instance: this edit showed as (+2,864) in the watchlist, the same as the page size according to its history. --Redrose64 (talk) 14:33, 7 June 2012 (UTC)[reply]

I'm seeing this type of thing on my watchlist a lot now. It's a bit disconcerting. Rivertorch (talk) 04:12, 11 June 2012 (UTC)[reply]

I've just noticed it now with this edit on the 2011 Christchurch earthquake with (+139,895) Simply south...... always punctual, no matter how late for just 6 years 21:36, 12 June 2012 (UTC)[reply]

A fix has been included in MediaWiki 1.20wmf5 (not listed in the change notes), which is set to be rolled out to enwiki between 18:00 and 20:00 UTC on 18 June 2012.

— Richardguk (talk) 01:05, 16 June 2012 (UTC)[reply]

Automated signature on talk page generates bogus edit conflict

I just now had a strange experience while posting a comment on an article talk page. After I hit "submit", I got an "edit conflict" notice. The comparison between the two versions showed that I was supposedly in conflict with myself. The only difference between the two versions was that the existing page showed "--~~~~" after my comment where my edit would have had "--Orlady (talk) 21:47, 3 June 2012 (UTC)". I hope this was an isolated event -- implementation of automated signatures (and template substitutions) should not be interpreted as separate edits that create edit conflicts. --Orlady (talk) 21:55, 3 June 2012 (UTC)[reply]

What happened here was that you double clicked the Save page button. The first click saved your edit and substituted your signature, while the second tried to do the same thing (except that the signature was gong back to how it looked in the edit window: 4 tildes). You can confirm this by doing it again. Make a comment, add tildes, hit save page and then hit save page again before the first edit has fully gone through. You'll edit conflict, and the only different content will be in your sig. Hope this helped :) Nolelover ^Talk^·^Contribs 01:07, 4 June 2012 (UTC)[reply]

I will stick up for Orlady's steady hand (and by implication my own) and suggest that this is actually a software issue. (Even if double clicking is happening the software should compare the post-post-save-transform text with the existing text.) Rich Farmbrough, 16:07, 5 June 2012 (UTC).[reply]

Incidentally I see this error, and I am fairly sure I almost always press alt-shift-s. Rich Farmbrough, 14:47, 6 June 2012 (UTC).[reply]

I believe this is a software issue. This doesn't happen when I double-click save, and it does not happen every time I add my signature and single-click save. It did, however, happen to me again just a few minutes ago. --Orlady (talk) 13:58, 12 June 2012 (UTC)[reply]

Need some help with a template question

On Wikipedia:Database reports/Unused templates/11 starting at 10290 there are a pile of template subpages as can be seen here pertaining to subatomic particles. I have looked through some of them and they do not appear to be needed. Could someone who knows more about templates mind double checking to see if these are needed before I submit them all for deletion? Kumioko (talk) 00:38, 5 June 2012 (UTC)[reply]

I think they're all needed. Template:Subatomic particle calls on those subtemplates when a user inputs certain parameters; e.g., {{subatomic particle|charmed b*}} calls on Template:Subatomic particle/symbol/charmed b* even though that one isn't currently being used anywhere. /ƒETCH COMMS / 02:07, 5 June 2012 (UTC)[reply]

Thanks, so just 2 more questions. Is there a way we can code this template to not need so many of these unused subpages or is there a way we can use some of them? I'm not the greatest template programmer but this doesn't seem like the best way to do this. Kumioko (talk) 03:10, 5 June 2012 (UTC)[reply]

Yes, see note below: "Combining small templates". -Wikid77 11:26, 5 June 2012 (UTC)[reply]

Well, since these subtemplates are not used (even though they may be useful in future), it would make sense to have them on the unused templates list. — This, that, and the other (talk) 10:06, 5 June 2012 (UTC)[reply]

Combining small templates: All of those hundreds/thousands of small templates could be combined into 2 quick templates using #switch to branch by particle name. It would be easy to do, by editing the list of template names into a #switch, where each name becomes a branch entry in the #switch (which can have more than 4,000 branches). Then complete the markup by merely wp:substing each value in the #switch. Create 2 new subtemplates:

Template:Subatomic_particle/getsymbol - with {{{1}}} as ID
Template:Subatomic_particle/getlink - with {{{1}}} as ID

For each #switch branch ("="), put the subst'ed current template name:

charmed b* = {{subst:Subatomic particle/symbol/charmed b*}}

charmed x* = {{subst:Subatomic particle/symbol/charmed x*}}

Then edit Template:Subatomic_particle to invoke those 2 new subtemplates, rather than hashing the particle name into 2 separate special templates (for each particle name). This is a common problem, as several people have been using the Wikipedia pagename database(s) to hash name values for thousands of entries. It would be like creating templates of the form "Template:Initials/John_Smith" to show "J.S." for each of a million people, by creating a million template names to hash by name "John_Smith", rather than have one template "{{Initials|John Smith}}" to pass the name as parameter {{{1}}} and deduce "J.S." from the character string "John Smith". -Wikid77 (talk) 11:26/12:17, 5 June 2012 (UTC)[reply]

Could you give me an example of a template that does this? I would be happy to go in and build one and see if I can solve this puzzle. Kumioko (talk) 12:03, 5 June 2012 (UTC)[reply]

Okay Kumioko, I will create Template:Subatomic_particle/getlink, and then perhaps you could create the other subtemplate, based on that example. Give me a few hours, and I will contact your user-talk page when ready. -Wikid77 (talk) 12:17, 5 June 2012 (UTC)[reply]

Ok thanks, if you could even get it started with the first 5 or 6 I would be happy to finish it once I see how its done. Kumioko (talk) 12:21, 5 June 2012 (UTC)[reply]

Before we create the other subpage "getsymbol" it would make sense to me to simply use Template:Subatomic particle/link and Template:Subatomic particle/symbol. I've also created a sandbox at Template:Subatomic particle/sandbox. --Izno (talk) 13:48, 5 June 2012 (UTC)[reply]

Ok thanks, should we also build a sandbox for the other 2 temporarily until we can get the logic working so we don't break the existing template in the process? Kumioko (talk) 13:51, 5 June 2012 (UTC)[reply]

/link and /symbol aren't actually used by anything except the sandbox. I started those as I thought Wikid was off sleeping or something (confused by UTC for once!). /getlink could be merged to /link. --Izno (talk) 14:06, 5 June 2012 (UTC)[reply]

Oh ok I see that Wikid77 has created the 2 subpages above that he suggested so its fine with me either way. I don't really care what the subpage logic name is I just knew there was a better way to do this than several hundred subpages. Kumioko (talk) 14:16, 5 June 2012 (UTC)[reply]

Outdent: I actually bumped into a parallel set, which I'm not sure if it's being used more or not at Template:SubatomicParticle, and it's already implemented in the way that Wikid has noted is probably the better way to deal with it. --Izno (talk) 14:17, 5 June 2012 (UTC)[reply]

Returning to those older subtemplates would be another option, where Template:SubatomicParticle/link gets the corresponding article name for a particle name. That provides the anchor text in a wikilink "[[anchor|particle symbol]]", so perhaps create a Template:SubatomicParticle/sandbox to use an old version, and see how it functions. -Wikid77 (talk) 14:33, 5 June 2012 (UTC)[reply]

Ah. Slightly different functionality. --Izno (talk) 14:37, 5 June 2012 (UTC)[reply]

New subtemplates ready for use in sandbox version: I created both of them, due to 345 subst'ed parameters before saving. Use these in the testing of Template:Subatomic particle/sandbox:

Template:Subatomic_particle/getsymbol - with {{{1}}} as ID
Template:Subatomic_particle/getlink - with {{{1}}} as ID

Meanwhile, submit the old 345+345 prior subtemplates to WP:TFD, while testing the new version, which I am confident can be done within the day. -Wikid77 (talk) 14:20, 5 June 2012 (UTC)[reply]

Would you mind copying /getlink and /getsymbol to /link and /symbol? Makes more sense in my head. --Izno (talk) 14:37, 5 June 2012 (UTC)[reply]

We have not TFD-discussed replacing existing templates, yet. -Wikid77 (talk) 14:48, 5 June 2012 (UTC)[reply]

Thanks a lot for the help guys. I will submit the MFD in a few minutes and drop a link here in case someone wants to review it. Kumioko (talk) 14:39, 5 June 2012 (UTC)[reply]

Yes, I meant "TFD" to discuss the prior 690 subtemplates. -Wikid77 (talk) 14:48, 5 June 2012 (UTC)[reply]

I knew what you meant. I submitted a separate one for the Link and Symbolk subpage groups here. I do notice that including redirects there are 565 Link subpages and 590 Symbol subpages so if there are only 345 on the new pages you created there might need to be some adjustments. Kumioko (talk) 14:58, 5 June 2012 (UTC)[reply]

I am updating those #switch structures (of 345) to handle the full 589 particle names, using 589 subst'ed template calls, and then we can get both lists to support the same 589, or note the differences. -Wikid77 17:29, 5 June 2012 (UTC)[reply]

Awesome thanks. Kumioko (talk) 17:30, 5 June 2012 (UTC)[reply]

Massive switch statements are very inefficient. Rich Farmbrough, 15:00, 5 June 2012 (UTC).[reply]

Sorry Rich I should have been more descriptive in the TFD for what my perception of inefficient is. I'm not just speaking from a system efficiency standpoint but also usability from a user perspective. For one, having about 1100 subpages makes it rather hard to check for problems when you have to switch back and forth (at least to me in my limited technical mind). Also, hundreds of these subpages are showing up in places like Database reports/unused templates so IMO if we are going to keep the functionality, which I believe we need, we should do so without having a huge number of templates. Of course this is just my opinion from a limited technical viewpoint and there may well be valid reasons why it needs to be kept as is but I can't see it. Kumioko (talk) 15:08, 5 June 2012 (UTC)[reply]

When you say "check for problems" do you mean "seeing a problem, to check where it lies" or "hey! let's check for problems!"

And as to the database report, I have some issues with that. The main reason to delete templates is to free up their names, name-space pollution is a significant problem that we should be addressing, but the no-brains stop us. These templates live in their own corner of the template namespace, where they harm no-one (the same is true of most of the other systemic template names, possible excepting the element infoboxes). Deleting all templates that are "unused" is rather like going into a workshop and throwing away all the tools that are unused, within a few minutes nothing will be made.

Nontheless I have provided dummy uses of all those templates, and so they will be absent from the next run of the report.

Now as far as the use of the template and rendering time are concerned, it was a long time ago that I re-organised the subatomic particle templates, (and I was very busy catching up with 20 years progress in the field) so I don't remember exactly how they work, but the way to test is to produce a page that calls, say 200 subatomic entities symbols, and another page that uses the proposed method. The rendered pages contain embedded html comments (i.e. we force all users of our projects to download waste bytes) that give the rendering time.

All the best, as ever,

Rich Farmbrough, 15:58, 5 June 2012 (UTC).[reply]

Allow for subst'ing of particle symbols: I think an acceptable improvement would be to instruct editors to use wp:subst'ed template calls, to use prefix "subst:" to evaluate the large 590-branch #switch and just store the direct symbol template in an article:

User types: {{subst:Subatomic particle|alpha++|link=yes}}
Text shows: [[Alpha particle|{{Physics particle|α|TR=++}}]]

Using the efficiency tactic of the 80/20 Rule, then only the 20% of the most-read of those subatomic articles would need to use subst'ed templates. If we really want to get efficient, remove overhead from articles such as "Main_Page" (read 7.3 million times per day); removing any unneeded templates or shrinking images, there, would produce a benefit 7.3 million times per day, 51 million times per week. And you know there are always inefficiencies in something like "Main Page". -Wikid77 (talk) 16:22, 5 June 2012 (UTC)[reply]

There are some good points here and I really didn't mean to turn this into a verbal snowball fight. I agree Rich that there is no "harm" in these templates sitting there unused however using the garage analogy you did my garage is fairly small and will only hold so much so after a while I need to clean up some of the clutter and get rid of some of the stuff I haven't used or probably won't. Same principle applies here. After several years of operation Wikipedia is building up a lot of clutter in areas like the Template and Category namespaces and things like the template/subtemplate structure above with hundreds of unused templates and subpages going unused (and many just uneeded) make things messy and confusing. You are correct there are some editors that would let this crud pile up in perpetuity but if there is a way to make this mess a little less messy then I am all for it. Of course I am ok with the decision to leave things as is if thats what happens but I think, in this case, that using the #switch logic that Wikid came up with is better than 1100+ subpages. Thats 1100 subpages that potentially have to be changed, maintained and understand by mere mortals who might attempt to use them. In reply to Wikid I agree if there are efficiencies that would help the main page we should try and use them. The site needs all the help it can get and even though we don't need to "worry" about server/harddrive space management per sey if there are better ways to do things that help those then we should IMO. These things are a finite resource and although the cost is minimal the cost does exist. Kumioko (talk) 17:29, 5 June 2012 (UTC)[reply]

Of course subst:ing is an efficient solution (and may have already happened in many cases). My only tiny reservation is that it may be a smidgen less translate friendly. Rich Farmbrough, 14:51, 6 June 2012 (UTC).[reply]

Sorry Rich I'm not sure what you mean by translate friendly. Could you explain?Kumioko (talk) 15:02, 6 June 2012 (UTC)[reply]

Sure. Should we wish to translate some articles into another language, as happens from time to time, the links and any names in the templates will only need to be translated once.

On size etc: every 8 edits to this page cost about 1M headline database storage, which probably compares unfavourably with the {{Subatomic particle}} system as a whole.

On performance I created a page to compare with the serving time of {{Subatomic particle/link}} (.3 - .5 seconds) with a switch based equivalent. The page refuses to save so badly it does not even generate an error message. It is of course pretty large, I will attempt other strategies.

Rich Farmbrough, 15:21, 6 June 2012 (UTC).[reply]

OK 10.175 seconds is the serve time for the test page at [[1]] -which, incidentally, is doing much less than {{Subatomic particle/link}} i.e. it is not generating links, running "lcase" or anything just doing the simplest switch processing, an yet takes about 20-30 times as long. Rich Farmbrough, 15:29, 6 June 2012 (UTC).[reply]

That does make sense but I still think that eventhough we take a performance hit in the sense of server load, the positive of having to try and keep the 1200 pages maintained and used is less. I also think that the template logic is more understandable and easy to follow and modify (add/remove.change) as needed. I also think that the adverse of your argument is that given the space it takes for the 1200 subpages we probably balance out and maybe even gain some by not having all the subpages. I do understand what you are saying though. Kumioko (talk) 16:31, 6 June 2012 (UTC)[reply]

Optimizing speed and anti-vandalism: Obviously, the 2 large combined templates will be easier to check for hacked edits, by diff comparison, rather than scanning all 1,156 subtemplates for improper changes. Many people forget about the nightmare of how minor changes are dropped somewhere into a thousand pages which people rarely watch. Meanwhile, I am working to make the large #switch structures faster, based on what Rich Farmbrough has noted above, in testing 347 runs of a template containing a large #switch. So far, the /getsymbol template seems to run only twice (2x) as slow, compared to loading the current 589 {Subatomic_particle/symbol/...} subtemplates. I noticed that the "mw" servers seem to process the page faster, when checking load times by browser View-Source of each run of the formatted page. Of course, the load time does not evaluate how other users are affected when a page loads 589 templates, while they are trying to load and format articles which they want to view. As Kumioko noted above, when comparing the overhead to load, view or anti-vandal check those 1,156 subtemplates, then overall, the system might use less resources to just process the large #switch structures, while not having the 1,156 active subtemplates in operation any longer. However, I too have noted the warnings from Rich about slow processing of large #switch structures, so I am working to calculate an accurate impact estimate on the run-time data, rather than ignore potential performance problems. -Wikid77 (talk) 19:00, 6 June 2012 (UTC)[reply]

The anti-vandal thing is, of course, a good point. They will show up on my watchlist, I suppose, or related changes of the page Subatomic particles/links. I don't think they are particular vandal targets. We could really do with some metrics on this sort of thing. I have also been thinking (in any case) of some other mechanisms, on and off wiki, which may help, but to avoid WP:BEANS I won't describe them right now. Rich Farmbrough, 19:29, 6 June 2012 (UTC).[reply]

Tests show Subatomic_particle/sandbox 50% slower: After running several tests against the prior Template:Subatomic_particle, the sandbox version seems to run only 50% slower, on average, to process 500 subatomic particle names. I have a page of test cases:

User:Wikid77/Test_500_particles - 500 cases +another 89 optional

When running performance benchmarks, the minimum run times compared as 13.5 seconds for the sandbox 500 cases versus minimum 8.9 seconds for the original 500 testcases, or 1.51% longer. However, due to various server delays, the processing often ran over 16 seconds for the sandbox 500 cases, which might be more representative of actual response time: a longer template will be subjected to longer delays in server overhead. Gone are the days when a loop of 100,000 iterations would run the same length every time on a similar machine! I will run some tests, later at night, to see if the benchmark minimum of 13.5 seconds goes any lower. The original template is limited to the "500 expensive parser functions" due to using #ifexist (which has run extremely fast in the actual testing). Hence, the full 589 testcases could be run for the sandbox version, but not with the original template. -Wikid77 (talk) 20:27, 6 June 2012 (UTC)[reply]

Small tests show sandbox template often 2x faster: As I suspected, with moderate usage of the template, then the new sandbox version can run much faster than the original. I ran a test of the following 11 particle names:

positron = {{Subatomic particle/sandbox|positron}}
electron = {{Subatomic particle/sandbox|electron}}
neutron = {{Subatomic particle/sandbox|neutron}}
muon = {{Subatomic particle/sandbox|muon}}
kaon = {{Subatomic particle/sandbox|kaon}}
proton = {{Subatomic particle/sandbox|proton}}
sigma = {{Subatomic particle/sandbox|sigma}}
gluon = {{Subatomic particle/sandbox|gluon}}
photon = {{Subatomic particle/sandbox|photon}}
rho = {{Subatomic particle/sandbox|rho}}
gluon0 = {{Subatomic particle/sandbox|gluon0}}

The results showed a minimum benchmark time of 0.439 seconds for running those 11 sandbox cases, whereas the original template in 11 cases often ran as 0.7, 0.8 or even 1.1 seconds, as double the time of the new sandbox version, which uses the giant #switch structures (with 589 branches each). I think this example clearly illustrates that even a large #switch structure, when run only "11 times" per page, could run much faster than special, tiny templates tediously optimized to just one-line each. The most likely explanation is that the fluctuating overhead in the server processing just completely overshadows the time needed to process "11 times" through a large #switch structure of 589 cases. As shown with the 500-testcase example, above, the large #switch structures can be 50% slower when used 500x times per page. However, in typical usage of just "11 times" per page, a large #switch can run twice (2x) as fast as the optimized, special, tiny templates of 1-line each. Hence, the sandbox version of Template:Subatomic_particle was able to run twice as fast as the original template, when not pushed as an extreme case of 500 transclusions on one page. Caveat: This test only applies to occasional articles with "11 times" running a large #switch structure; if most articles began using huge #switch logic, then overall results might slow by 1-5%, as articles began to compete more for time. -Wikid77 (talk) 21:40, 6 June 2012 (UTC)[reply]

It seems to me that there are good points on either side of this debate. Rich is right, #switches are ineffient. The further down the #switch you have to go the more inefficient they get; hence Wikid's placement of the more commonly needed symbols at the top. This shows up in the preprocessor node count (which can be seen when you view the page's source code). For particles toward the top of the list the live version and the sandbox version are roughly on par with respect to this count. As you go down the list they diverge. For particles towards the end of the list the sandbox preprocessor node count has grown to about nine times that of the live version. On the other hand, using a #switch does remove the "need" for the #ifexist (another expensive piece of code limiting the number of calls to 500 per page). The #ifexist allows the template to crash gracefully, i.e. give an error message if the input is not supported (so we don't completely need it, if it becomes a problem, it could be ditched and let the template crach ungracefully). As for maintaining & protecting the subtemplates from vandalism, Rich notes that they're on his watch list (but what if, Heaven forbid, he should die), they could be protected & do we expect them to need maintaining (are particle symbols going to be changed anytime soon? perhaps the articles on them may evolve (merge/split/move), though). I think Rich has solved the problem of their showing up on the unused template lists (it would be nice if there were another way to do this). One thing puzzling me about both approaches is why you're calling {{physics particle}}. Why, for example, use {{Physics particle|p}} when p would do? JIMp_talk·cont 07:36, 7 June 2012 (UTC)[reply]

Rich doesn't need to die for him to be unable to act on his watchlist. The Arbs have twitchy fingers. Rich can't even correct a spelling mistake without somebody calling "foul".

Anyway, {{physics particle|p}} doesn't do much apart from wrapping the letter "p" in a .... But this is a minimal example: the template takes several parameters |anti= |BL= |BR= |link= |TL= |TR=, five of which add various symbols, the other allows a wikilink. For example: {{physics particle|p|link=proton|TR=+}} →
p⁺
--Redrose64 (talk) 13:19, 7 June 2012 (UTC)[reply]

Yes, the proton example is minimal but the principle remains the same. If speed is a concern, we could speed things up by using plain code. I'll try elaborate below. JIMp_talk·cont 05:01, 8 June 2012 (UTC)[reply]

It should be noted that Rich is currently blocked for a month and without delving to deep into the many problems I have with the ruling, the vagueness of its written inclines me to believe that this will not be a singular event. Aside from that I don't like relying on a single point of failure (in this case Rich's watchlist) for a deterrant for vandals not to alter a template for a few laughs. Kumioko (talk) 13:23, 7 June 2012 (UTC)[reply]

I have never understood the ruling that a "30-day block" is needed when most people will change tactics after a 24-hour block, and do things differently afterward. However, I have tried to reduce other blocks and then get accused of "meat puppet" so I will let others decide that issue. -Wikid77 19:13, 7 June 2012 (UTC)[reply]

No, well, a block would also prevent his fixing vandalism (as would an number of other things, his going camping, getting lost at sea, going to gaol, going on a mission to Mars, ...). Protection might work but it does have the disadvantage of making positive edits more difficult (Rich, being desysopped, wouldn't be able to work on them if they are fully protected). And, of course, there's no way of stopping vandals from adding subtemplates for bogus particles and then using the template to disguise vandalism (hope I'm not giving them any ideas). JIMp_talk·cont 00:09, 8 June 2012 (UTC)[reply]

Note also, of course, that whilst he's blocked he can't defend his version of the template here nor at the TDF. JIMp_talk·cont 00:21, 8 June 2012 (UTC)[reply]

Optimizing Template:Subatomic_particle for speed and portability: Now that tests have confirmed the sandbox version can run faster than the original Template:Subatomic_particle, for limited use as "11 times" per article, I have continued to optimize the #switch structure to speed the top 80 particle names. At this point, we can move ahead with further benefits. The most obvious will be:

Reducing the 1,156 templates to 2 templates, for all known cases.
Fixing missing cases, or mismatched names.
Easier proofreading of formatting all "589" particle names.
Easier removal of unlikely "artificial" names in the list.
Easier reformatting all "589" particle names for a future format.
Automatic counts of linked versus non-linked symbols as 2 template names.
Easier interwiki translation (Spanish?, Swedish?) as 2 templates, not 1,180 projected.

Already, I have proofread most of the 589 entries to ensure the correct wikilink format. Also, I have pinpointed 26 formatting errors, among the current 589 particle names. The heaviest usage of particle symbols is made by Template:Particles, being transcluded into over 140 pages. The usage of symbols is currently "forced" in the sense that only some atomic articles show symbols, at all, and hence, the symbols are not "required" to describe issues in particle physics. For example, common articles "Gluon" and "Hadron" did not use the template, at all, while "Pion" contained 66 transclusions of pion particles and related. From that standpoint, this template has catered to a limited use of symbols, rather than being a "workhorse template", and instead it is a specialized-symbol template, currently in limited use. Based on this background, I have noted these issues in Template_talk:Subatomic particle/getsymbol. -Wikid77 (talk) 19:13, 7 June 2012 (UTC)[reply]

Because Rich created these templates, was part of the discussion before his block and because he is intimately familiar with how they function and why I am going to say, in case he is watching, that I would be glad to post his comments if they were to show up in my Email for this discussion. :-) I do believe that this is in keeping with the intent of the block and IMO still allows us to proceed without jeopardizing any potential unintended consequences. If anyone has a problem with this, please let me know so that we can mitigate any concerns. Kumioko (talk) 01:55, 8 June 2012 (UTC)[reply]

That sounds fair. JIMp_talk·cont 06:25, 8 June 2012 (UTC)[reply]

A couple of suggestions which apply to both versions.

Both Rich's version and Wikid's version start out with an #ifeq to check whether or not to link. What if we saved the #ifeq till later, till after we've figured out what the particle is? By doing so we wouldn't need one subtemplate or six hundred subtemplates for linked particle symbols and another or another fifty dozen for unlinked ones. Instead we could put the #ifeq on each particle subtemplate or each line of the #switch. Of course, that's a lot more #ifeqs to type but only one will need to be evaluated at a time so there'd be no effect on the template's speed. Rich's version would then need only thirty score subtemplates and Wikid's wouldn't even need any. On the other hand, we could eliminate this #ifeq altogether and make the value of the linking parameter part of the subtemplate name (e.g. Template:Subatomic particle/blahblah/linkyes vs Template:Subatomic particle/blahblah/linkno) but we'd keep the same number of subtemplates. JIMp_talk·cont 06:25, 8 June 2012 (UTC)[reply]

Both Rich's version and Wikid's version use {{physics particle}}. As mentioned above, in the case of {{subatomic particle|p}} this does nothing useful. So we're better off just using p. Yes, this is a minimal example, though. So what about the case of {{subatomic particle|proton+|link=yes}}? Here {{physics particle|p|link=proton|TR=+}} is used. What happens next?

builts the particle symbol
- checking whether any superscripts or subscripts are needed to the left,
- checking whether an overline is needed (for antiparticles) and
- checking whether any superscripts or subscripts are needed to the right
 - and since a superscript is needed it calls {{su}} which adds the superscript "+" using
 + 
 (note the  , unnecessary in this case since there is no subscript),
sends the symbol and link along to {{OptionalLink}} and
puts the whole lot within a ....

checks (again) whether to link the symbol
- and since a link is desired it calls {{InternalLink}}.

produces the link and adds an unecessary  (this is intended to stop any connected text from also being linked but is redundant since the thing is already in a span).

In the end we have the following code.

<span class="unicode;" style="white-space:nowrap;">[[proton|p<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:0.8em; line-height:1.2em;  font-size:85%; text-align:left;"><!--
  -->+<br /><!--
  --></span>]]<span></span></span>

Which could be cleaned up like this.

<span class="unicode;" style="white-space:nowrap;">[[proton|p<span style="display:inline-block; margin-bottom:-0.3em; vertical-align:0.8em; line-height:1.2em;  font-size:85%; text-align:left;">+</span>]]</span>

The following is the NewPP limit report for the above code.

Preprocessor node count: 3/1000000

Post-expand include size: 0/2048000 bytes

Template argument size: 0/2048000 bytes

Highest expansion depth: 1/40

Expensive parser function count: 0/500

Compare this to the NewPP limit report for {{physics particle|p|link=proton|TR=+}}

Preprocessor node count: 66/1000000

Post-expand include size: 1044/2048000 bytes

Template argument size: 323/2048000 bytes

Highest expansion depth: 11/40

Expensive parser function count: 0/500

It seems that almost all of (Rich's) {{subatomic particle|proton+|link=yes}}'s preprocessor node count, post-expand include size, template argument size and highest expansion depth is due to the use of {{physics particle}}.

Here's the NewPP limit report for {{subatomic particle|proton+|link=yes}}.

Preprocessor node count: 75/1000000

Post-expand include size: 1682/2048000 bytes

Template argument size: 169/2048000 bytes

Highest expansion depth: 13/40

Expensive parser function count: 1/500

Compare that to the NewPP limit report for {{subatomic particle|proton+/sandbox|link=yes}} which currently calls {{Subatomic particle/link/proton+/sandbox}} which has the plain code instead of the {{physics particle}} call.

Preprocessor node count: 21/1000000

Post-expand include size: 873/2048000 bytes

Template argument size: 33/2048000 bytes

Highest expansion depth: 6/40

Expensive parser function count: 1/500

JIMp_talk·cont 06:25, 8 June 2012 (UTC)[reply]

With usage likely to remain below 100 template symbols per article, then the node count seems acceptable as it has been, without changes there. -Wikid77 22:15, 9 June 2012 (UTC)[reply]

True, but if we're looking for speed, the more we simplify the template, the quicker it should get. Here's a single-page version based on the double switch (mentioned below), on moving the #ifeq and on using plain code. I think this will prove to be faster still. Here are the NewPP limit reports for 500 particles using these three versions.

NewPP limit report for {{subatomic particle}} (live version)

Preprocessor node count: 34596/1000000

Post-expand include size: 792249/2048000 bytes

Template argument size: 93125/2048000 bytes

Highest expansion depth: 13/40

Expensive parser function count: 500/500

NewPP limit report for {{subatomic particle/sandbox}}

Preprocessor node count: 73630/1000000

Post-expand include size: 886469/2048000 bytes

Template argument size: 98839/2048000 bytes

Highest expansion depth: 14/40

Expensive parser function count: 0/500

NewPP limit report for {{subatomic particle/sandbox2}}

Preprocessor node count: 45354/1000000

Post-expand include size: 313660/2048000 bytes

Template argument size: 11428/2048000 bytes

Highest expansion depth: 6/40

Expensive parser function count: 0/500

JIMp_talk·cont 06:53, 11 June 2012 (UTC)[reply]

I have created another sandbox version sort of half-way between {{subatomic particle/sandbox}} and {{subatomic particle/sandbox2}} in the sense that it doesn't use other {{physics particle}} (and all the other templates which that subsequently calls) but does call its own subtemplates. As expected it fairs somewhere between {{subatomic particle/sandbox}} and {{subatomic particle/sandbox2}} in terms of template limits.

NewPP limit report for {{subatomic particle/sandbox3}}

Preprocessor node count: 57676/1000000

Post-expand include size: 468799/2048000 bytes

Template argument size: 19987/2048000 bytes

Highest expansion depth: 7/40

Expensive parser function count: 0/500

Of course, eliminating {{physics particle}} goes completely in the opposite direction to what's suggested below. 06:15, 12 June 2012 (UTC)

If we want to get {{physics particle}} when we subst {{subatomic particle}}, here's an idea. We could still eliminate all subtemplates of {{subatomic particle}} by putting the #ifeq on the main page (as I've been sugesting) and use the link parameter in the {{physics particle}} call. I've replaced the direct code in {{subatomic particle/sandbox2}} with an example of what I'm talking about.

NewPP limit report for the new {{subatomic particle/sandbox2}}

Preprocessor node count: 69458/1000000

Post-expand include size: 693315/2048000 bytes

Template argument size: 93125/2048000 bytes

Highest expansion depth: 13/40

Expensive parser function count: 0/500

We are, of course, back to the kind of numbers we have with {{subatomic particle/sandbox}} (a very slight improvement) but much of this is probably due to inefficencies in {{physics particle}}. JIMp_talk·cont 08:22, 12 June 2012 (UTC)[reply]

Speed is even faster with subst'ed names: Although template {Subatomic_particle} would be somewhat faster when replacing all uses of "{Physics particle|B}" with the plain span-tags (for class="unicode;" style="white-space:nowrap"), the fastest results come from wp:subst'ing to keep the "{Physics particle|B}" in the article text. Using Template:Physics_particle, directly, is faster than optimizing {Subatomic_particle}, so when speed is an issue, then the tactic is to use subst'ing or direct coding to have "{Physics particle|B}" in the article text, as twice as fast (2x) as optimizing {Subatomic_particle}. Again, using "{Physics particle|B}" has been the best method, and using other templates has been a forced, artificial change in writing those articles. -Wikid77 00:01, 12 June 2012 (UTC)[reply]

Yes, substing {{subatomic particle}} such to leave {{physics particle}} in the text would be preferable. JIMp_talk·cont 06:15, 12 June 2012 (UTC)[reply]

New sandbox version optimized 20% faster than original: I have further modified the Template:Subatomic_particle/getsymbol and /getlink subtemplates, to further speed the search, by hashing on the 1st letter of the particle name, to then branch to a smaller #switch for each major letter: b, c, d, s, t or others. That reduces the worst-case search to nearly 589/6, as only about 98 names to search, or roughly 6x times faster there, almost 2x faster overall, which is even 20% faster than the original. Because the initial speed difference was an issue, in perhaps keeping the prior 1,156 subtemplates if the sandbox version was much slower, the recent optimization for the sandbox to run now 20% faster, than the original 1,156 tiny subtemplates, tilts the decision clearly in favor to use the 2 quicker, updated subtemplates, rather than maintain the 1,156 slower, unfinished, undocumented subtemplates. Meanwhile, the analysis of this situation has revealed how #switch structures of 100 branches, each, can outperform 1,200 one-line templates to display a symbol selected by name, as split into 2 groups of 600 names, with 6-way #switches into sub-switches of 100-branch groups. Extension of this tactic, to process problems of 2,000 names, seems like an efficient strategy, rather than have 2,000 tiny templates to maintain, or copy when porting for interwiki translation. -Wikid77 22:15, 9 June 2012, revised 01:46, 11 June 2012 (UTC)[reply]

Implications for improving Template:Physics_particle: As noted above, the best tactic, for articles on particle physics, has been to continue using "{Physics particle|B}" which has been the fastest method, and using other templates has been a forced, artificial change in writing those articles. Although {Subatomic_particle} will be greatly improved by combining all 1,156 subtemplates into 1 or 2, the optimization of {Physics_particle} should also be sought. In particular, dropping the nowrapping (rarely needed) would be an easy improvement, where an option could be added to "w=n" (for wrap=no) when a user wanted the template to nowrap results, in the very, very rare cases when needed. Otherwise, users could just force {nowrap|xx} (or {j|xx} to join) text, as another alternative. So, I think drop the extra markup:

Unless option w=n, omit:

Omitting that nowrap text would make using "{Physics particle|B}" about twice as compact, such as in large tables which could list extensive combinations of atomic particles. -Wikid77 00:01, 12 June 2012 (UTC)[reply]

I'm not sure that the no wrap is rarely needed. Super/subscripts seem to wrap. But there are plenty of other places where {{physics particle}} could be sped up. JIMp_talk·cont 06:15, 12 June 2012 (UTC)[reply]

MediaWiki:Sp-contributions-footer-anon

After the IPv6 roll out today, I noticed that some of the tools linked within the Template:Anontools which is used on MediaWiki:Sp-contributions-footer-anon and on MediaWiki:Anontalkpagetext aren't working with IPv6. Now there are two ways in which we could get that fixed, both would require a switch to differ IPv4 and IPv6 addresses (maybe {{Strfind short|$1|:|1}}), one would be to create a separate Anontools6 template for IPv6 addresses, the other one to differ that within the current template. The following tools don't work with IPv6 as far as I can see it now: Geolocate, it's Alternate and the Traceroute tool. For the traceroute tool various alternatives can be found on the Internet, but I didn't manage to find one which is fast and can take get parameters (maybe we should create one on the toolserver). Example IPv6 Special:Contributions: Special:Contributions/2A02:2F02:D021:F007:0:0:BC18:F6BC, Special:Contributions/2001:980:1451:1:7149:688C:F192:3318, Special:Contributions/2602:306:CE65:5740:D956:A711:C1AC:A893 - Hoo man (talk) 16:29, 6 June 2012 (UTC)[reply]

Done I decided to make {{anontools}} itself handle the detection of IPv4 versus IPv6, so any other uses besides MediaWiki:Sp-contributions-footer-anon don't have to care about the difference either. If you do find geolocation or traceroute tools that work for IPv6, please do add them (or request they be added) to Template:Anontools/ipv6. Anomie ⚔ 19:31, 6 June 2012 (UTC)[reply]

Tracking a sock puppet from Imperial College, I am pretty sure that I've found another, but the Anontools don't seem to be working for[2] although I just found them on two other IPv6 addresses. Dougweller (talk) 09:12, 11 June 2012 (UTC)[reply]

Ah, found it on the contributions page, but not when creating talk page, although I've found it with other IPv6 addresses. Dougweller (talk) 09:22, 11 June 2012 (UTC)[reply]

The problem there appears to be in MediaWiki:Newarticletext, it uses a hack to try to detect if it's on an IP talk page versus a non-IP talk page, but of course the hack only works for IPv4 addresses. I'm not sure how to fix it, though. Anomie ⚔ 11:55, 11 June 2012 (UTC)[reply]

New feature experiment

The current timestamp

The experimental new timestamp

Hi everyone! I just wanted to give a heads up that the new editor engagement experiments team at the Foundation is starting our first user interface test today.

The purpose of this experiment is to more prominently show when an article was last edited, in order to provide greater transparency about revision histories to both readers and editors. The new timestamp will look like the mockup to the right, and it will be in addition to the current timestamp at the bottom of every article, not a replacement. The key differences are that:

it will be in a more human-readable format, e.g. "Last updated one hour ago", instead of in UTC
it will appear in the upper righthand corner of articles, to the left of any top icons like the FA star
it will link to the history, so you can see the diff if you want (we might test linking to the diff directly in a second round)

For one week, we're going to try presenting the new timestamp to 50% of viewers on a random sample of just under 3,000 articles. This test will exclude redirects, anything with the AFT5 on it, and will not appear to anyone who has checked Preferences → Appearance → Exclude me from feature experiments.

As you can see this pretty small, but there might still be some edge cases we haven't thought of that will produce bugs or conflicts with other elements of an article. In particular, the rare article title that is extremely long (like Fundamental Rights, Directive Principles and Fundamental Duties of India) might overlap at certain sizes of browser window. Please do point out here any replicable errors you find, keeping in mind that this is only running for a week.

Thanks! Steven Walling (WMF) • talk 20:58, 7 June 2012 (UTC)[reply]

Thanks for the heads-up, and I like the idea. Looks nice. I barely ever noticed the timestamp before. Equazcion ^(talk) 21:23, 7 Jun 2012 (UTC)

Glad you like it! P.S. if anyone's interested, there's more documentation on mediawiki.org and Meta. Steven Walling (WMF) • talk 21:25, 7 June 2012 (UTC)[reply]

Would you be so kind to explain me why this is an improvement? Sorry, I am too unimaginative to dream up a usecase in which this is useful. The rationale and hypothesis found on mw:Timestamp Position Modification are not very convincing. Arcandam (talk) 21:33, 7 June 2012 (UTC)[reply]

'Pends on what it links to. The edit window? If so, then it would actually encourage more people to edit. 68.173.113.106 (talk) 21:47, 7 June 2012 (UTC)[reply]

@Arcandam: The "last update" timestamp was always there. There are a bunch of reasons to defend it, but it isn't a new feature. This change just makes it more visible and readable, so whatever good it did, it'll do it more now. Why is it good to show when an article was last updated? While not necessarily an indicator of how current the information is, it does indicate how old the information is -- ie. if the article hasn't been edited in 3 months, then it definitely won't reflect anything that happened in the last 3 months. Equazcion ^(talk) 21:55, 7 Jun 2012 (UTC)

Equazcion explains our point of view perfectly. :) Steven Walling (WMF) • talk 21:58, 7 June 2012 (UTC)[reply]

You guys must've forgotten the reason why the text was small, gray and located in the bottom-left corner in the first place: because almost no one gives a flying cat about that information. It is just not important. This change is not an improvement. You wrote: "whatever good it did, it'll do it more now", but previously it was useful for a tiny minority of users and it did not clutter the interface for those who do not need it. By moving this to the space used for top icons we get an even messier interface, noobs have more stuff to stare at and scratch their heads, and this change is only an improvement for the tiny minority of Wikipedia users who are actually interested in this info; the rest of us are worse off than we were. Arcandam (talk) 22:13, 7 June 2012 (UTC)[reply]

Was it small, gray, and in the bottom-left because no-one gave a flying cat, or did no-one given a flying cat because it was small, gray, and in the bottom-left? The interaction with top icons is a valid concern though. I'm sure it'll be dealt with through testing. Equazcion ^(talk) 22:21, 7 Jun 2012 (UTC)

Both. I hope so. Arcandam (talk) 23:33, 7 June 2012 (UTC)[reply]

Actually I see the mockup already shows the interaction with top icons. Looks okay to me. Equazcion ^(talk) 22:27, 7 Jun 2012 (UTC)

The great thing about running an A/B test with the software is that we will get to have data that helps us answer this question. No one at the Foundation or in the community at large can speak for the hundreds of millions of visitors to Wikipedia and declare that all people care or don't. What we can do is run a test and then share the results, and then have a conversation about what we want to do as a project. Since this is only a seven day test, not a permanent new feature, we don't need to have a large argument yet. ;) Steven Walling (WMF) • talk 22:38, 7 June 2012 (UTC)[reply]

I think its actually a great improvement.Edinburgh Wanderer 22:50, 7 June 2012 (UTC)[reply]

Well, I hope I am wrong, but I rarely look at that info because it is rarely important to me. I've reverted vandalism that was more than a year old. It may be more useful to actually help people understand the way Wikipedia works (e.g. displaying the info: "Click the 'View history' tab at the top of the page to see the time and date of the latest edit") instead of duplicating a tiny subset of the page history functionality. If it links to the latest diff it may be useful, but I don't like the idea of duplicating a link to the history tab. This modification would not remove the timestamp from the footer. This suggestion is in addition to the existing timestamp. Why? Arcandam (talk) 23:08, 7 June 2012 (UTC)[reply]

It's an experiment, Arcandam. There are metrics by which it will be judged. It may work. It may not. It's not obvisouly harmful. What more do we need to know? Why? Because one or more of the team that is charged with improving user engagement thinks it is worth investigating. --Tagishsimon (talk) 23:35, 7 June 2012 (UTC)[reply]

You did not answer my question. Arcandam (talk) 15:17, 8 June 2012 (UTC)[reply]

Hear, hear! We should be thanking the WMF team for letting us know about this experiment before it started, and for actually testing new interface elements before they are introduced generally. IMHO, this is the exactly the way that significant new features should be introduced. To me, this looks like an improvement, but it would be kind of silly to base the design of one of the world's most popular websites on the personal esthetic opinions of a half-dozen self-selected critics. This experiment is a great way to further the evolution of Wikipedia, and we should be commending those who are conducting it, not questioning them. --R'n'B (call me Russ) 12:48, 8 June 2012 (UTC)[reply]

I recommend moving to a country with a dictatorship. Welcome to Wikipedia, where we have a bit more freedom to ask questions. Arcandam (talk) 15:15, 8 June 2012 (UTC)[reply]

You don't think that's a bit over the top? Of course we have freedom to ask questions. We also have the freedom to tell the person who asked the question that they are being unreasonable. Or does freedom end when it is contrary to your opinion? --R'n'B (call me Russ) 19:27, 8 June 2012 (UTC)[reply]

I wasn't entirely serious; I guess I should've used a sarcasm emoticon or something like that. Arcandam (talk) 01:25, 9 June 2012 (UTC)[reply]

One of the other differences I notice, apart from the location change, is that it now specified 'how long ago' the last edit was rather than merely giving the current revision timestamp. I personally think this is a fantastic example of a small change with big positive consequences as our readers will 'get' the idea that WP is being constantly updated much more obviously. So many people ask me in presentations I give how old the info is - this lets me say '2 hours' rather than pull up diffs. Nice work. Witty lama 23:13, 7 June 2012 (UTC)[reply]

IP editors are fed rather old versions of the page (or at least I am, sometimes). Just musing, but what will be the effect here? Mr Stephen (talk) 23:41, 7 June 2012 (UTC)[reply]

I think the new timestamp is a great idea. Could we have that for users too? I very frequently find it useful to know if I am about to leave a comment on a users page that has been inactive for the last 3 years. I would highly recommend this be an optional thing though, some users may not like it and I believe they should have the option to turn it off. Kumioko (talk) 01:48, 8 June 2012 (UTC)[reply]

It is currently on for logged in users as well, it just appears only on a small subset of articles, and since it's a randomized experiment, you might get put into the control group that sees nothing. Thank you for the vote of confidence though! When the test is done, we'll share the results and if folks would like to see this become a permanent feature then we can talk about how to do that. Steven Walling (WMF) • talk 01:56, 8 June 2012 (UTC)[reply]

If I understand this correctly and its for random articles and users then I would recommend making it random for Articles and the editors opt in to be a part of it. If it randomly works for some editors and not others its likely to irritate and confuse them and open a lot of unwanted negative discussion. Some in the community don't cotton to outsiders so to speak and don't like it when things abruptly change with no notice. Kumioko (talk) 02:07, 8 June 2012 (UTC)[reply]

Kumioko - to clarify, are you talking about potentially adding this system to userpages, as in, the user namespace? If so, then I can see the value to this too (on an optional basis), also in some cases for article talkpages. Witty lama 03:56, 8 June 2012 (UTC)[reply]

No, I think he's suggesting that the experiment should be done only for anonymous users on the basis that registered users are more likely to jump to conclusions whilst shooting the messenger in a spiderman costume from the top of the Reichstag. I would say that excluding them from the experiment is not solving the underlying issue, which is how to stop people being so recalcitrant in the first place. Happy‑melon 10:26, 8 June 2012 (UTC)[reply]

That is not what he's suggesting. At least some of the people who work for the WMF are pretty smart; they know why they get criticised once in a while and they know what to do to reduce the amount of criticism in the future. Please be polite. Arcandam (talk) 15:26, 8 June 2012 (UTC)[reply]

Actually your both right. I think that doing something like this on user pages as well so that if someone goes to a user page they can, if they choose, see a message that says this users last edited on X. That way if they haven't edited in four years I don't need to waste my time leaving them a message in some cases. Its also useful for verifying WikiProject activity andn for a variety of other reasons. I also think that if they randomly allow some editors the capabaility to see the last time an article was edited while others cannot and it works in a random way its going to be confusing (they will think its broken or something) and will invite comments. I also agree that too many people are too sensitive to change. Kumioko (talk) 11:21, 8 June 2012 (UTC)[reply]

Well, actually it is the other way around. The WMF has been rather insensitive to the community in the past. The current AFT is a great example. Arcandam (talk) 16:08, 8 June 2012 (UTC)[reply]

Well thats certainly true but in general I think thats ok as long as when they are testing things like this is optional. If they later decide to implement it full spectrum as a "development initiative" then thats different and they should have the authority to do that. We as a community should be able to have some say in being used as guinea pigs for something that may or may not work out but the WMF should have the authority to implement development decisions that affect the "business" of Wikipedia and associated projects. Again to clarify I personally do like this new feature and would happily be a tester but not all would and IMO they should be allowed to opt out. I just noticed that if the individual unchecks the box "exclude me from Feature experiments" that they won't be contacted so that problem is solved. Kumioko (talk) 17:08, 8 June 2012 (UTC)[reply]

True, unwanted stuff is easy to hide with CSS. BTW the good news is that the AFTv5 is a good idea, I hope it will be deployed soon. Arcandam (talk) 01:28, 9 June 2012 (UTC)[reply]

Another recommendation I would have would be to develop a basic test plan that we can use to test these new features rather than the method we have been using were we just though it out and see what happens. It will help to identify and document problems and make the testing look a little less like amateur hour (no offense intended). Something that checks it in different namespaces, using other tools and common scripts, does it affect things like the watchlist or my contribs? Etc. Kumioko (talk) 17:14, 8 June 2012 (UTC)[reply]

There is already a detailed test plan on Meta. All our experimental methodologies and analysis requirements will be documented in detail in the Research namespace there. Steven Walling (WMF) • talk 17:22, 8 June 2012 (UTC)[reply]

Possibly related problem

I have noticed that since yesterday and this test Wikipedia has been responding extremely slowly when using scripts and apps that use the API such as Twinkly and AWB. I think there might be an issue with performance that might need to be looked at. Kumioko (talk) 13:57, 8 June 2012 (UTC)[reply]

Quote: It appears to have been due to the "Editor engagement experiments" extension, it was posting back to the API on every page view. The API should be working again shortly, if it's not already working now. Anomie 04:08, 8 June 2012 (UTC) Arcandam (talk) 15:33, 8 June 2012 (UTC)[reply]

Yes, the extension has been disabled for now. It was hitting the API at an unusually high rate, which combined with the AFT verson 5 testing, overloaded it. Everything should be back to normal now, and it won't get reenabled until we figure out a reliable fix. Steven Walling (WMF) • talk 17:22, 8 June 2012 (UTC)[reply]

the moockups look not bad (at least the top stuff... I don't like the footer and have it 'turned off' with a CSS hack). I can happily confirm: finally after asking many times: the WMF is communicating before they the start doing stuff. +1 mabdul 11:50, 9 June 2012 (UTC)[reply]

Okay, just a heads up that this issue has been fixed and the timestamp experiment is now redeployed for a seven day test. I'll be online for some time if there are any problems, and watching VPT. Steven Walling (WMF) • talk 23:31, 14 June 2012 (UTC)[reply]

Feedback

I'm not a native speaker, but to me "This page was last modified on XXX" means something different than "Last updated XXX days ago". With the first, my impression is "whatever, boring version info" but with the other "wow, the info in this article is pretty much up-to-date and probably reliable". I think "last modified" is far more accurate. This may be just my perception, or a misinterpretation by a majority of readers, but you will never know from the experiment, will you? The other thing is, I don't think the Justification and Research questions for the experiment are very convincing. I don't see why you "expect this experiment to have a minor, indirect impact on editing" - just a highly visible link to the article history will convert readers to editors, really? And "Does a more prominently visible timestamp of the last revision produce a significant increase in clickthrough rates to the history of an article?" just means that you want to collect clickthrough-rates for prominently placed links. Okay, but if you have collected those, and have found out that there is no significant impact on editing (as I presume) - will you then leave it at that, and not continue with your Ideas for next iterations? --Atlasowa (talk) 18:57, 9 June 2012 (UTC)[reply]

The way to A/B test copy differences is try changing it to another version but leaving all other functionality and placement the same. If people generally think the copy needs improvement, then we'd be happy to discuss options for a future A/B test of new text. To answer your last question: since we said up front that we don't expect to show a significant direct impact on editing, that's not the only measure for whether the feature is useful or not. As for the notes placed on the talk page: they were just spur of the moment ideas, not concrete plans for next tests. Steven Walling (WMF) • talk 21:03, 9 June 2012 (UTC)[reply]

Is there any way to explicitly opt-in so I can see this in action (when it gets re-enabled, if it hasn't already)? Equazcion ^(talk) 21:18, 9 Jun 2012 (UTC)

You can see it right now on test.wikipedia.org at the page Test12217. Feel free to edit that page up a storm to see the timestamp change as well. If you don't see it, you were bucketed in the control group; clear your cookies to try again. Steven Walling (WMF) • talk 22:04, 9 June 2012 (UTC)[reply]

Do we need to know the exact number of seconds? Is "less than a minute ago" good enough? Arcandam (talk) 08:07, 10 June 2012 (UTC)[reply]

I never understood the recent trend toward fuzzy lengths of time. How the hell is "1 day ago" worthwhile when it was 46 hours? Or "three months ago" without stating the actual date (which might have been 3 months and 29 days)? Etc. ♫ Melodia Chaconne ♫ (talk) 13:33, 10 June 2012 (UTC)[reply]

Well, the reason is that human beings naturally think of time as "how long ago" or "how far in the future". Doing timestamp math in your head is awful, even if it's your own timezone (let alone trying to convert from UTC to your local time, and then doing the "how long ago" math). In the examples you've given, however, I'd say you're dealing with a buggy implementation of a natural language timestamp system. "46 hours" should translate to "about two days ago" (or even "46 hours ago" - it's generally acceptable to provide time "in hours" to 48), and the second should have either "about four moths ago" or "four months ago", depending on how lenient the parser is. As time gets longer, humans get more forgiving about round off times. "A year ago" is okay when we're talking about "360 days".--Jorm (WMF) (talk) 00:19, 12 June 2012 (UTC)[reply]

Oddly enough, I think I agree. "modified" is definitely more accurate (though less positive) that "updated". In other words, the latter would get more click-throughs, but it's less truthful and should probably be avoided nonetheless. - Jarry1250 ^{[Deliberation needed]} 11:56, 10 June 2012 (UTC)[reply]

Less truthful? That's a stretch. It's only less accurate if you assume the adjective "updated" is not true of the last modification, which is an assumption of bad faith. Steven Walling (WMF) • talk 21:49, 10 June 2012 (UTC)[reply]

It is not bad faith to suggest that not all modifications are updates. Adding a comma to a grossly out-of-date article is not an update, for instance, nor is it bad faith to suggest it is not: I think everyone would acknowledge that. Using "Updated" thus implies a false level of security that the article is indeed up-to-date IMHO. - Jarry1250 ^{[Deliberation needed]} 11:14, 11 June 2012 (UTC)[reply]

Well, I disagree, but as I said above, we'd be happy to talk about A/B tests of different language in future iterations. Once a baseline is established, it's quite easy to run future tests comparing "updated" to any other turn of phrase. It's likely that changing that word alone would have an impact on clickthroughs to the history. Steven Walling (WMF) • talk 18:05, 11 June 2012 (UTC)[reply]

I guess my point was that the effect I'm talking about won't show up in A/B clickthrough rates, it'll only show up if you actually talk to readers. If I thought it would show up I would just let you test it :) - Jarry1250 ^{[Deliberation needed]} 19:41, 11 June 2012 (UTC)[reply]

For the record, I agree with Jarry1250. The overwhelming percentage of edits to articles are not updates; they are, at best, housekeeping, such as categorizations, AWB swaps, template changes, or similar minor tweaks that have no actual bearing on the content. Only a small percentage of the edits to this project actually updates articles. You guys should go back and look at that study done by a former WMF Board of Trustees candidate that showed this, even back in 2006 or 2007. It's probably time to revisit it. Risker (talk) 01:01, 12 June 2012 (UTC)[reply]

I assume you're referring to Aaron Swartz's 2006 study? His research was not about the whether most article edits were of a certain qualitative kind or not, but rather him trying to prove that most work (as measured by characters added) on the 'pedia was not done by the core community. Steven Walling (WMF) • talk 02:19, 12 June 2012 (UTC)[reply]

Personally, I think "modified" is better than "updated" simply for accuracy's sake. But I think both should be tested.--Jorm (WMF) (talk) 02:43, 12 June 2012 (UTC)[reply]

This seems to be a useful feature, but I don't think you're ever going to get anyone to agree that all edits are "updates". That word will only lead to disappointment when new readers look at the edit itself. There's no "bad faith" about it; Wikipedia is, for the most part, a holding pan. Nothing revolutionary is going to happen to William Howard Taft that is going to require "updating", just modification and maintenance. If it makes WMF feel better to test it, go ahead, but the majority of the time "update" is false advertising. ▫ JohnnyMrNinja 04:24, 12 June 2012 (UTC)[reply]

Well, I've passed on the feedback to the entire team, since it seems clear I'm in the minority in disagreeing. In general, I think we're not limited to just those two choices, so before any further iterations or any discussion of permanent deployment, we should give anyone interested a chance to contribute alternative copy. Steven Walling (WMF) • talk 18:52, 12 June 2012 (UTC)[reply]

I think the timestamp might signal something different to new editors, drawing their attention not to the last revision, but to the dynamism and mutability of content. Although the experiment is modest in scope, it will scrutinize a common intuition, which is that we won't get more contributors unless we jostle people out of a mode of passive content consumption. Tinkering with the copy is fine (I don't think anyone feels deeply attached to the current wording), but I worry that it only further obscures the primary objective of the experiment: to enrich community discussions about direction and strategy with evidence such that they increase in wisdom and effect. --Ori.livneh (talk) 09:55, 13 June 2012 (UTC)[reply]

Possible bug

It looks like this might be breaking the View History link on some pages (see this discussion below). 82.132.139.10 (talk) 13:58, 17 June 2012 (UTC)[reply]

possibility to search files local

Hi, I was searching for images locally, but sadly (e.g. searching for 'flickr') there popping up 'too many' commons images. Is there a possibility to include only the local images? mabdul 11:01, 8 June 2012 (UTC)[reply]

I don't know a way with Wikipedia's search. With Google you can try flickr -"This is a file from the Wikimedia Commons" site:http://en.wikipedia.org/wiki/File:. PrimeHunter (talk) 00:13, 9 June 2012 (UTC)[reply]

Thanks, good idea, but sadly doesn't work in my case: I wanted to search at en.wikibooks, but google, Y! and big don't seem to index the images there :/ (search term: 'flickr http://en.wikibooks.org/wiki/' works but only for text, 'flickr http://en.wikibooks.org/wiki/F' no hit) mabdul 12:00, 9 June 2012 (UTC)[reply]

I get 470 Google hits on -"This is a file from the Wikimedia Commons" site:en.wikibooks.org/wiki/File:, but it's not much when wikibooks:Special:Statistics says there are 7460 uploaded files. PrimeHunter (talk) 12:30, 9 June 2012 (UTC)[reply]

Although I only 440 hits, the first 5 hits are from Commons, but I do want files from en.wikibooks... Somehow this search is not working... mabdul 13:50, 15 June 2012 (UTC)[reply]

Editor-save&edit

I see that additional buttons are being added to the Edit page User interface- so while minds are focus can I propose additional fuctionality. I would like a Save& Edit button- that would savethe page I am working on and take me back into the &action=edit mode- rather than the display mode. The reason is that when I am working on a flaky internet connection, doing a major edit to a page it is good practice to save-early save often however pragmatism tells me that it better to just make one save as the line will be invariably down, and I will have to wait for reconnection (or the server will be overloaded). At the moment I need one window of opportunity to do a preview, one to do a save and one to reconnect in editing mode- I can become 50% more productive with a new button- and if the button would allow an edit with rollback- I could omit the preview (but that is another day!). Apologies if this has been discussed before. --ClemRutter (talk) 14:07, 8 June 2012 (UTC)[reply]

This can be done with JavaScript, I think. Ruslik_Zero 19:50, 8 June 2012 (UTC)[reply]

Yes, so can time travel, resurrection of the dead and reversing global warming, I think- but I would like to see a demo in sandbox. So if it can be done, would anyone like to accept the challenge? I am too busy trying to turn_copper_into_gold.js ;) --ClemRutter (talk) 22:07, 9 June 2012 (UTC)[reply]

I just created the tool for you. You can find it at User:Mabdul/saveandedit.js and you can simply 'install' it by adding following line to you Special:MyPage/skin.js:

importScript('User:Mabdul/saveandedit.js'); //adding a new button next to the

Regards, mabdul 01:18, 16 June 2012 (UTC)[reply]

Just what I was looking for. Thanks. I am giving it a spin right now. I let you know if I find any six legged things. :)--ClemRutter (talk) 13:36, 16 June 2012 (UTC)[reply]

I will fix that bug... o.O mabdul 13:39, 16 June 2012 (UTC)[reply]

May statistics gone?

I have checked the May data of random page, and I see the May 2012 data vanished without explanation. What is that? --George Ho (talk) 01:18, 9 June 2012 (UTC)[reply]

I can confirm that they aren't showing, including on different articles. Chris857 (talk) 01:52, 9 June 2012 (UTC)[reply]

Hmm, it seems (fortunately) that it's just a problem with the tool and not with the underlying data, since the files themselves are not zero bytes long (which would indicate a generation problem). Thus, it's worth poking Henrik, but I'm not sure how best to get in touch with him. I vaguely recall some lurkers on here having a contact address (or am I making that up?) - Jarry1250 ^{[Deliberation needed]} 09:28, 9 June 2012 (UTC)[reply]

The classic version seems to have no issues. Someone poked me about issues in the first half of May. I responded that they should email him. He reads (or used to read) his emails somewhat regularly and fix the issues, even if he didn't respond. Killiondude (talk) 19:01, 9 June 2012 (UTC)[reply]

This appears to be fixed. Chris857 (talk) 01:31, 12 June 2012 (UTC)[reply]

Logged Out

A few months ago there was a wide spread issue of people being logged out mid session after a software update. This has started happening again for me, most often when opening new windows. It can be three or four times a session rather frustrating. Is this still happening for anyone else. Edinburgh Wanderer 13:46, 10 June 2012 (UTC)[reply]

Username with trailing wildcard

I just came across the following user:

*telugumoviefan* (talk · contribs · deleted contribs · logs · filter log · block user · block log)

(note: this is not a discussion of that user's behavior or edits at all, just the username). Special:Contributions/*telugumoviefan*, in addition to giving me this specific user's edit-history, also gives me a tree-list of editors matching that given account as a wildcard pattern. This is a result of my enabling MediaWiki:Gadget-contribsrange.js, which is a pretty useful vandal-tracking gadget for its CIDR function (and especially as we all come up to speed on IPv6 ranges, etc). We already prohibit "actual account" usernames that mimic system-user and anon names. Should we expand that to include trailing wildcard? I can't see any value to users to allowing it and it seems prone to causing problems. I've also filed this as a bug against the gadget, but it's a technical concern.

As an accompanying question, is there an API way to find out if a given user is "real" vs anon? There have already been several discussions of ways of flagging anon accounts in histories (the most recent one was within the past few days but I can't find it) given we're not all familiar with the exact "legal" specifier for IPv6. That would at least allow separate controls of wildcard for anon accounts vs exact match (maybe with a toggle in the .js interface) for named accounts that might contain special characters. DMacks (talk) 18:45, 10 June 2012 (UTC)[reply]

Re: Your second question, I don't know of a way to determine whether an editor is anonymous using the API, but most users whose names don't have a "contribs" link attached in the edit history (and therefore have a user ID of 0) will be anonymous. The exceptions are users from 2001/2002 and edits that were imported from other places (e.g. other language versions of Wikipedia). Graham87 01:45, 11 June 2012 (UTC)[reply]

An asterisk is a perfectly valid page title character (except with bugzilla:12974 making it a bit awkward at times) so it is fine in a user name. I used it in contribsrange simply because it was a quick way of indicating a wildcard search (and the collisions would be very rare). If anything, it is just a ~~bug~~ feature in contribsrange. As for the other question, you can query the API with list=users. If the name matches the internal regex for an IP (IPv4 or IPv6, the regex however are not perfect, see 1.2.3.999), it shows "invalid", if it doesn't match it either shows "missing" if unregistered or gives a "userid" if registered. Edit: Added .xxx anon IP, and it works as expected. I don't have an example of a missing imported edit though. --Splarka (rant) 07:28, 11 June 2012 (UTC)[reply]

The script that imported the 2001 edits into the current Wikipedia database operated in September 2002, and if a username for one of those edits wasn't registered, it would make its user ID 0 like an IP address. I've registered almost all of these accounts as I've discovered them, but there were a couple that I could not register due to SUL; an example is Jaime Gonzalez (talk · contribs), who comes up in the API as missing. Graham87 01:46, 12 June 2012 (UTC)[reply]

The Ghost Ship

Hi. Can somebody figure out why when you click the harvard notes it doesn't take you to the books in the bibliography?♦ Dr. Blofeld 08:00, 11 June 2012 (UTC)[reply]

(Mostly) resolved, see my edit summary. - Jarry1250 ^{[Deliberation needed]} 09:15, 11 June 2012 (UTC)[reply]

Thanks. I didn't add the dates to the refs, the other editor did, that explains why it was working yesterday but not today!♦ Dr. Blofeld 10:13, 11 June 2012 (UTC)[reply]

The {{harvid}} template is designed so that the surname(s) and year go into different parameters, and no parentheses are used. When this is done, it will link to a {{citation}} with no |ref= parameter, or to a {{cite book}} which specifies |ref=harv, provided that such template uses |lastn=/|firstn= pairs not |authorn=, and that it correctly uses the |date= and |year= parameters.

So, instead of {{harvnb|Hutchings (2009)|p=201}} you should put {{harvnb|Hutchings|2009}}. To link from this you need to make two amendments to the

{{cite book|last=Hutchings |first=Peter |title=The A to Z of Horror Cinema |url=http://books.google.com/books?id=gMiDnJrnE6MC&pg=PA201 |year=30 September 2009 |publisher=McFarland |isbn=978-0-8108-6887-8 |ref={{harvid|Hutchings (2009)}}}}

(i) amend |year=30 September 2009 to |date=30 September 2009, or alternatively amend it to |year=2009; (ii) amend |ref={{harvid|Hutchings (2009)}} to |ref=harv. --Redrose64 (talk) 13:14, 11 June 2012 (UTC)[reply]

IPv6 schoolblock question

Mikemikev (talk · contribs) is a prolific sockpuppet from Imperial College, frequently attacking other editors. Imperial College is now using IPv6 and we are blocking individual addresses such as 2001:630:12:1072:EC7D:4743:C486:6971 (talk · contribs) and 2001:630:12:100E:FC57:7302:D227:CD50 (talk · contribs) but should we be using range blocks instead? Thanks. Dougweller (talk) 09:26, 11 June 2012 (UTC)[reply]

Probably, but you'd need to careful consider the amount of collateral damage and strike the right balance. See meta:User:Jonathan_de_Boyne_Pollard/Guide_to_blocking_IP_version_6_addresses for more. - Jarry1250 ^{[Deliberation needed]} 09:56, 11 June 2012 (UTC)[reply]

Thanks, I understand most of that except actually the bit about range blocking. Is there any more detailed guidance on how to do with, maybe with examples? I doubt that I'm the only Admin that will need this. Dougweller (talk) 14:37, 11 June 2012 (UTC)[reply]

With IPv6, you want to block the smallest administrative entity you can find that corresponds to that IP address. This is typically a /48 (for organizations) or a /56 (for individuals). Allocations to administrative entities on /64 boundaries are I believe, very rare: /64s should generally correspond to individual LANs inside an organization. For the address in question, whois returns the following:

inet6num: 2001:0630:0012::/48

netname: ICV6NET1

descr: Imperial College London

Since there's nothing to suggest any finer granularity of address assignment, I suggest you should schoolblock the entire IP range 2001:0630:0012::/48, and let the IC sysadmins sort the issue out internally. -- The Anome (talk) 14:48, 11 June 2012 (UTC)[reply]

Update: I've just discovered that range blocks with prefixes shorter than /64 are apparently currently not allowed. This is bad news -- in theory, blocking an organization with a /48 allocation would require up to 65536 different blocks. However, I think it's reasonable to assume in this case that Imperial know what they are doing, and are being reasonably parsimonious with subnet allocation. In which case, we should be blocking just the two /64 subnets: 2001:630:12:1072::/64 and 2001:630:12:100E::/64. -- The Anome (talk) 14:57, 11 June 2012 (UTC)[reply]

Subnets 2001:630:12:1072::/64 and 2001:630:12:100E::/64 now schoolblocked. -- The Anome (talk) 15:02, 11 June 2012 (UTC)[reply]

(edit conflict) In a couple of weeks (with the deployment of MediaWiki 1.20wmf5), you'll be able to block much larger ranges of IPv6 space than the existing limit of /64 (specifically up to /32). Alternatively the change could be made immediately if there was good cause for it. - Jarry1250 ^{[Deliberation needed]} 15:07, 11 June 2012 (UTC)[reply]

Yes please, since the expected problems have already started, can we have it sooner rather than later? We should probably be blocking /56s as our standard IPv6 block -- most ISPs seem to have selected /48 for companies, and either /48 or /56 for consumer connections. (See RFC 6177 for more on this.) Only large companies with multiple sites should need an allocation larger than a /48, and this should show up on whois.

Moreover, except for very, very, rare cases, given the way that IPv6 address assignment works, I can't see that blocking any block smaller than a /64, let alone an individual address, makes any sense at all. Perhaps we should have IPv6 blocks block a minimum of /64 by default? -- The Anome (talk) 15:16, 11 June 2012 (UTC)[reply]

Thanks for all this. Should we be letting people at WP:AN know about this discussion? Dougweller (talk) 15:33, 11 June 2012 (UTC)[reply]

Yes, definitely. If we get our procedures sorted out now, while IPv6 isn't yet much of a problem, we will be ahead of the game. -- The Anome (talk) 15:51, 11 June 2012 (UTC)[reply]

Johnathan's guide on Meta is somewhat erroneous on the topic of rangeblocks. The very reason why IPv6 came into existence on wikis is to avoid collateral damage when one IPv4 address=1 LAN. It is therefore important that we don't rangeblock unless we have a school (people can register at home), a moving proxy, or an active IP hopper within the range. As Jarry1250 said, the rangeblock limit will be lifted when MediaWiki 1.20wmf5 is deployed, allowing up to /32 rangeblocks.--Jasper Deng (talk) 15:59, 11 June 2012 (UTC)[reply]

IPv6 came into existence to deal with the IPv4 address exhaustion problem, and, as a solution to that problem, is indifferent to our blocking issues. In general, we need to block the smallest administrative entity which is not under the end-user's direct control. Unfortunately, blocking on a LAN-by-LAN basis is just what we have to do: someone with access to a IPv6 LAN has in principle up to 2⁶⁴ IP addresses at their disposal, and in many cases will have their network configured in such a way that they will only need to bring an interface up and down to get a new one. Moreover, someone with a /56 IPv6 allocation under their control (ie. most home IPv6 users) will have up to 256 such LANs at their disposal. -- The Anome (talk) 16:21, 11 June 2012 (UTC)[reply]

What if the user is in an office building where its not his own address set? Or if he/she lives with a good-faith contributor? In either case there'd be collateral damage. This is why at most I'd restrict such rangeblocking to home users only, or if it's clear a range is being abused.--Jasper Deng (talk) 16:26, 11 June 2012 (UTC)[reply]

Then their colleagues and housemates will, alas, have a problem. The alternative is not to be able to block IP-hoppin users at all, since they will be able to IP-hop to their heart's content as much as they like within that range. It may be an idea to give them the benefit of the doubt just the once, if their block is not followed by IP-hopping, but given that IP hopping can be as simple a matter as taking an interface up and down without even realising it, I'm not hopeful about this. -- The Anome (talk) 16:31, 11 June 2012 (UTC)[reply]

Not everyone knows how to IP-hop. So therefore a rangeblock should be only done when they demonstrate that they do know how to hop.--Jasper Deng (talk) 16:43, 11 June 2012 (UTC)[reply]

Yes, you're right. I propose the following blocking seqence: first, a /128 individual address; if that doesn't work, the covering /64, and if that doesn't work, either a /56 or a /48 block, as appropriate. We can skip the intermediate /64 if circumstances suggest it would be ineffective. -- The Anome (talk) 17:12, 11 June 2012 (UTC)[reply]

I half-agree on that. This escalating ranges system should only be used when we are uncertain of the kind of allocation the ISP uses. If we do know that then we should just block the default allocation size.--Jasper Deng (talk) 17:14, 11 June 2012 (UTC)[reply]

Best practice currently seems to be issuing /56 or /48 allocations to customers, although I have heard anecdotal reports of /64s being handed out to home users by ISPs. -- 17:24, 11 June 2012 (UTC) — Preceding unsigned comment added by The Anome (talk • contribs)

Even if users get more than /64, in any case most don't use more than one /64.--Jasper Deng (talk) 17:26, 11 June 2012 (UTC)[reply]

Agreed. We have three tiers: non-IP-hopping users, non-technical IP-hopping users who will generally stay on a single LAN, or at most a few LANs (muiltiple WLANs in a single house, for example), and technically proficient malicious IP-hopping users, the last of which we should assume can hop anywhere within any allocation they can get their hands on. -- The Anome (talk) 17:45, 11 June 2012 (UTC)[reply]

There's also the mobile device user jumping on a large Wifi network with more than one /64 subnet.--Jasper Deng (talk) 18:10, 11 June 2012 (UTC)[reply]

Mikemikev is still socking from Imperial College, see [3] from 2001:630:12:1073:3038:610A:F533:DFC1 (talk · contribs). Dougweller (talk) 08:46, 13 June 2012 (UTC)[reply]

Block the /64, and next Monday when 1.20wmf5 comes out, the /48. A college has the right to deny that person access to its network if it wishes to be able to edit anonymously here.--Jasper Deng (talk) 16:48, 13 June 2012 (UTC)[reply]

You can now block ranges up to /19, I backported the relevant change. -- Tim Starling (talk) 01:13, 14 June 2012 (UTC)[reply]

`{{Wide template}}` with extra scrollbar above?

{{Wide template}} adds a scrollbar below the too-wide template. When the template is high, this bar can be out of sight (below screen) in regular page reading. Example: see Periodic table (large version). Is it possible to add (optionally), an extra scrollbar above the wide template? -DePiep (talk) 12:07, 11 June 2012 (UTC)[reply]

No, not easily anyway. The template merely prompts the browser to add scrollbars using the CSS overflow property; the browser chooses where to put them (or to not put them). Thus it would be quite an endeavour to add them at the top. - Jarry1250 ^{[Deliberation needed]} 12:20, 11 June 2012 (UTC)[reply]

Thank you, very clear & clarifying. I read & learn. Any other routes, someone? -DePiep (talk) 20:24, 11 June 2012 (UTC)[reply]

it is possible, but would probably require some extra javascript (see [4]). 198.102.153.2 (talk) 23:53, 11 June 2012 (UTC)[reply]

Good working examples in the link. Is it a feature I could ask, or is that a user-side thing? -DePiep (talk) 12:20, 12 June 2012 (UTC)[reply]

I'd be concerned that using a JS-based trick in a template might start to interfere with usability/accessibility of the site, though that's just me. It's probably best to leave it as a user-side option, either via a browser extension like GreaseMonkey or some custom trickery in vector.js. elektrik SHOOS (talk) 22:14, 16 June 2012 (UTC)[reply]

Strange IP address

Last night, I reverted an edit by a user with what seemed to be a very strange user name. When I went to the user's talk page to leave a message, the only options I was given were automated messages for anonymous users, since WP apparently interprets this as an IP address, but this is like no IP address I have ever seen: 2607:FB90:BEEF:CAFE:0:5EFE:A53:7A62. Can anyone make sense of this? ---RepublicanJacobite_TheFortyFive 14:13, 12 June 2012 (UTC)[reply]

It's the new IPv6 protocol. Reaper Eternal (talk) 14:15, 12 June 2012 (UTC)[reply]

BEEF CAFE, eh? I wonder if "vanity" IP's with words like that are going to be common. There aren't very many words you can spell with just ABCDEF, so space is limited. ☮Soap☮ 01:56, 13 June 2012 (UTC)[reply]

Years ago IBM mainframe programs used to fill unused memory with the hexadecimal characters DEADBEEF so that any useful information that was inserted later could be distinguished from how the memory was when the program started. This required, of course, that the programmer be examining the contents of memory using a debugger. Nowadays programs are usually too big for that to be a useful technique. Jc3s5h (talk) 02:04, 13 June 2012 (UTC)[reply]

Huh. Ya learn somethin' new every day! Thanks for all the responses. ---RepublicanJacobite_TheFortyFive 02:58, 13 June 2012 (UTC)[reply]

I don't know how common, but Facebook's IPv6 addresses contain "face:b00c". Anomie ⚔ 03:02, 13 June 2012 (UTC)[reply]

We have an IPv6 Test wiki, which shows that people can indeed get creative with IPv6 addresses. ^Avic_ennasis @ 05:34, 28 Sivan 5772 / 05:34, 18 June 2012 (UTC)[reply]

User talk:Jereemy

Hello,

May you delete the page User talk:Jereemy ?

Thank you very much. --Jereemy (talk) 18:23, 12 June 2012 (UTC)[reply]

You're not normally allowed delete your principle talk page. It's for people to contact you regarding your edits. What do you want to delete it? — Blue-Haired Lawyer ^t 18:46, 12 June 2012 (UTC)[reply]

See WP:DELTALK. --Redrose64 (talk) 18:56, 12 June 2012 (UTC)[reply]

Database error screwed up my move!

I got a database error while I was in the middle of performing a move for a move request, and the edit history has screwed up. Per the move request, the intended moves should have been moving Bruno Müller (a dab page) to Bruno Müller (disambiguation), and Bruno Müller (Nazi) to Bruno Müller. Currently the edit history for the former Bruno Müller (Nazi) no longer appears. To make matters worse I need to step out and won't be able to deal with this until later, so assistance would be much appreciated.--Cúchullain ^t/c 21:16, 12 June 2012 (UTC)[reply]

Ugh, what were you trying to do there? There shouldn't have been any need to delete anything there except possibly a redirect or two. Anyway, I think I can sort it out. Anomie ⚔ 03:20, 13 June 2012 (UTC)[reply]

Oh, that should sort things out. Anomie ⚔ 03:26, 13 June 2012 (UTC)[reply]

Thank you. I have no clue know what happened; when was able to see the pages again, the disambiguation page had not been moved, and Bruno Müller (Nazi) was at Bruno Müller with all edits deleted. Unfortunately I had to step away and couldn't return for several hours. When I got back I'd gotten several "wtf" messages, so I undeleted the article so it was at least visible. Thanks a lot for sorting it out.Cúchullain ^t/c 03:45, 13 June 2012 (UTC)[reply]

{{S-line}} doesn't work

See the article Fenhu Road Station. I have provided the parameters and created templates it needs. I compared them with other railways, but found nothing wrong. --Makecat _Talk 00:56, 13 June 2012 (UTC)[reply]

I have never liked the {{s-line}} method for producing railway station routeboxes, primarily because of the myriad of bespoke subtemplates that it requires, and the hoops that you have to jump through to get it to work. As far as I can tell, subtemplate {{SZRT stations}} expects there to be a positional parameter {{{1}}}, but {{S-line/side cell}} passes only named parameters into {{SZRT stations}}. --Redrose64 (talk) 09:55, 13 June 2012 (UTC)[reply]

[5] seems to have fixed Fenhu Road Station. Many other stations still need previous and next parameters. PrimeHunter (talk) 10:00, 13 June 2012 (UTC)[reply]

Thanks.--Makecat _Talk 23:54, 13 June 2012 (UTC)[reply]

Suggestion for Dynamic List

I am working on a wiki that tries to overcome the problem of too much time wasted navigating through the different levels of hierarchies when browsing for an interesting article. One solution is to put all the links on a single page and use indented lists (* and # markup) in a tree hierarchy so as to save the viewer the time and effort of navigating through the links. It would be really useful to have a markup syntax so that sub-levels are hidden until clicked open. For example, in the sample markup below, it would be really useful to have a [+] next to Vegetables so that Root Vegetables and everything under are hidden from view until clicked upon. Similarly, there would also be a [+] next to Root Vegetables when it becomes visible.
+ Vegetables
++ Root Vegetables
+++ Carrots
Is there already such a facility or something similar? — Preceding unsigned comment added by Me0815 (talk • contribs) 07:26, 13 June 2012‎

That would be the category system. Go to ‹The template Category link is being considered for merging.› Category:Vegetables and you'll see that the page is divided into three. The bottom section shows those articles directly included in that category, and the middle section shows the subcategories. Each subcategory has a blue or grey triangle to its left; if you click on any blue triangle, it will expand to show a further level of subcategorisation. --Redrose64 (talk) 10:02, 13 June 2012 (UTC)[reply]

If I wanted to display just the link to the category with a blue arrow beside it, is there a parameter I can use such as "show-arrow" in the category link, as in [[:Category:Vegetables|Vegetables|show-arrow]]? Me0815 04:52, 14 June 2012 (UTC)[reply]

The blue arrow is a characteristic of the way that category pages are built. No special coding is provided (or even needed). If the wikicode [[Category:Vegetables]] is placed on a category page, this category appears on ‹The template Category link is being considered for merging.› Category:Vegetables under the 'Subcategories' heading (with a grey or blue arrow alongside); if the same wikicode is placed on a file description page, this file appears on ‹The template Category link is being considered for merging.› Category:Vegetables under the 'Media in category "Vegetables"' heading (in a gallery); and if the same wikicode is placed on any other page, this page appears on ‹The template Category link is being considered for merging.› Category:Vegetables under the 'Pages in category "Vegetables"' heading (with a bullet alongside). --Redrose64 (talk) 09:43, 14 June 2012 (UTC)[reply]

Ok, thanks for all the above information, it helped me understand categories a great deal Me0815 09:41, 15 June 2012 (UTC)[reply]

Template inclusion limit?

Hey there, so I broke up Wikipedia:Userboxes/Games/Video games/Genres into a number of smaller pages located at Wikipedia:Userboxes/Games/Video games/Puzzle, Wikipedia:Userboxes/Games/Video games/Racing, etc. But when I try to include the sub-pages using the double curly braces syntax, the last include (the one at the bottom of the page) doesn't go through. I get the message "Warning: Template include size is too large. Some templates will not be included." I looked on Wikipedia:Template limits for help, but it's not exactly written in the most accessible language. I'm not sure if this is a pre-include or post-include issue.. or what it is.

Can you explain what's going on in this case? And what should I do to remedy the situation, so Wikipedia:Userboxes/Games/Video games/Genres displays all the userboxes that I'm trying to include? I've considered doing substs and doing away with the sub-pages, but I do think it's convenient to have the sub-pages. And even if I include all the userboxes on the same page, wouldn't I run into the same problem? Thanks for your help. CaseyPenk (talk) 20:26, 13 June 2012 (UTC)[reply]

The problem is obviously that you're including too many templates on a page, the solution is obviously not to include so many templates on a single page. Why not just make the main pages link to the subpages?

If you subst the subpages, it may still work, because you're doing away with one level of template expansion. With a few more userboxes, you're likely to again hit the limit, though. Ucucha (talk) 20:44, 13 June 2012 (UTC)[reply]

I've been resisting using the parent as a landing page, because most userbox types are self-contained without any sub-pages (e.g. Health. ethnic groups) Thanks for letting me know. CaseyPenk (talk) 21:07, 13 June 2012 (UTC)[reply]

Custom colours in My Watchlist, and possibly other pages

Is there a way I can customise the colours of text and/or background in specific places on Wikipedia? For example, I have trouble distinguishing between the "link not yet followed' blue and the "link has been followed" purple when both appear on the light blue background of My Watchlist. (I use those colours to determine which diffs I've reviewed and which have not.) I'm using MonoBook skin and Mozilla Firefox. Setting colours in Firefox and telling it not to let the website override them solves the problem - but then I lose all background colours which makes page version diffs useless. I presume I can put something in my Custom CSS to set specific colours in specific circumstance, but I don't know how. An example would be helpful, in the first instance for foreground of links-followed and links-not-yet-followed and background of My Watchlist, but hints as to what other pages I can change would also be good. Thanks, Mitch Ames (talk) 12:32, 14 June 2012 (UTC)[reply]

Hey Mitch. Okay, so I'm not sure how familiar you are with CSS, but to change the display of things on your watchlist only you prepend the selector name with ".mw-special-Watchlist ", where "mw-special-Watchlist" is listed as one of the classes of the body tag when you do right-click > View Source. For example to change the background of Special:Watchlist to white, you add to you custom CSS:

.mw-special-Watchlist div#content{ background: white; }

and to change the colour of visited links (to black, for example) you can use:

.mw-special-Watchlist div#content a:visited{ background: black; }

Hope that helps, - Jarry1250 ^{[Deliberation needed]} 12:49, 14 June 2012 (UTC)[reply]

That did the trick. Thanks. Mitch Ames (talk) 11:48, 15 June 2012 (UTC)[reply]

fill in citation from ISBN, DOI, etc.

What Wikipedia script/gadget/toolserver item allows me to enter only {{cite book|isbn=1234}} and have the tool fill in the rest using available databases on the web? I thought User:Citation bot did this, but apparently not. Riggr Mortis (talk) 02:37, 15 June 2012 (UTC)[reply]

I've usually used the various incarnations of RefTools, which work slightly siffernetly, you hit ref, then for (say) a cite book you put in an ISBN (or in another incarnation, a Google Books URL), for a cite journal you put in a DOI -- and there's a button next to those fields which fill in the rest. This section shows you the three available versions and what settings to use to get each, I actually find 1.0 easier to use than teh rest. Not quite what you wanted, but maybe good enough. --j⚛e decker ^talk 02:42, 15 June 2012 (UTC)[reply]

[ec] That is what I wanted, thanks. I'm so old school I never look at toolbars and friendly UI add-ons. However, it's not working either, for me: it simply "throbs" forever. Previous to this post I found [6] which does the same thing (won't complete). Admittedly I'm trying it for a single ISBN, Oh well. Riggr Mortis (talk) 03:01, 15 June 2012 (UTC)[reply]

Riggr Mortis, you can try User:Δ/Google Books.js. Hazard-SJ ✈ 02:56, 15 June 2012 (UTC)[reply]

Wikipedia incredibly slow

What's going on? Loading a page takes like 20 seconds and when the page finally comes up it doesn't render correctly. -- Toshio Yamaguchi (tlk−ctb) 11:49, 15 June 2012 (UTC)[reply]

Seems to be okay again. Perhaps it was just my internet connection. -- Toshio Yamaguchi (tlk−ctb) 12:06, 15 June 2012 (UTC)[reply]

I just had the full page skin come out and it stall, its not just you. OK now though.♦ Dr. Blofeld 12:07, 15 June 2012 (UTC)[reply]

Same here but things still look bad here (assuming scarlet "critical"s are a bad thing!). Thincat (talk) 13:19, 15 June 2012 (UTC)[reply]

Anchor doesn't work right

For some reason, Egyptian parliamentary election, 2011–2012#Dissolution doesn't work properly in Firefox. Instead of opening to the correct section, it goes midway through the refs (after briefly) going to the right place. I assume one of the tables or piecharts is messing things up, but I am at a loss as to which one and why.

Link is currently on the mainpage, so a fix would be nice if possible. --ThaddeusB (talk) 15:01, 15 June 2012 (UTC)[reply]

It's caused by the collapsed table in Egyptian parliamentary election, 2011–2012#PR per governorate and district. It changes size after the browser has computed where to place you. It's a common issue with section links from other pages. You can click in the address bar and press Enter to make the browser recompute where to place you. PrimeHunter (talk) 15:14, 15 June 2012 (UTC)[reply]

IDEA : Automate DEFAULT Disambiguation on (internal wikipedia) links based on ARTICLE CONTEXT

If I am adding to an article on economics and I say "/[/["depression"/]/]", I am probably refering to an article economic depressions like the great depression. If I'm adding to an article on psychology, I'm probably refering to the mood disorder. This obviously isn't always the case, but it'd be nice if "[[" links in articles could have CONTEXT BASED DEFAULT DISAMBIGUATION (rather than by default sending you to a disambiguation page). —Preceding unsigned comment added by 199.96.107.58 (talk) 18:52, 15 June 2012‎

The great difficulty here would be "how should context be determined"? --Redrose64 (talk) 22:38, 15 June 2012 (UTC)[reply]

As an example, say I'm editing an article on a type of stone. Part of the article will be about geology, so depression (geology) might be relevant. However, another section may be about the industry surrounding it, so depression (economics) would be appropriate. It becomes quite difficult to guess exactly what context should be used without a human being in the loop. Chris857 (talk) 16:14, 16 June 2012 (UTC)[reply]

Search function for books returns null or incorrect result

I've created several Wikipedia:Books, and notice that in my latest addition (Medici, with "Renaissance" and "Italian Renaissance" categories), when I search for the book I get a null result. Is there a structural issue with how the search functions searches books?

Example: from Wikipedia:Books, search on "Medici", (without the quotes), and see that the returned results do not include the desired book. I note that the search function appears to search the Book namespace, so to double-check, I do an advanced search, unchecking all boxes except "Book", which returns the same result — so the search algorithm appears the same in both instances, but it does not return the book I want.

I check the category Wikipedia books: community books with errors list (it was saved in the community namespace), and the book is not listed there, a good thing.

Next, I return to Wikipedia:Books and search again, this time for "Renaissance", with the idea the search should return all books with that keyword in the title or in that category, and the result does not include the book needed. (It does appear if I look specifically in Category:Renaissance or Category:Italian Renaissance.)

So I return to Wikipedia:Books and click on Browse all 9,231 Wikipedia books and am directed to a category list, which does not include the assigned book category (Renaissance, or Italian Renaissance), so I can't find it this way either.

Next, I return to Wikipedia:Books and instead of searching, I select the All 2,546 community-maintained books link, navigate to "M", and there I finally see the book.

A general user would have an extraordinarily difficult time trying to find a book by any of these methods, since general users are likely not inclined to click on a link that would, by its own description, return thousands of results. Users should be able to find books more easily than this. Thanks — Sctechlaw (talk) 00:13, 16 June 2012 (UTC)[reply]

Book:Medici was created 15 hours ago and hasn't been indexed by the search function yet. See Help:Searching#Delay in updating the search index. PrimeHunter (talk) 00:45, 16 June 2012 (UTC)[reply]

It's indexed now. PrimeHunter (talk) 10:58, 16 June 2012 (UTC)[reply]

Sysadmin

I asked this at WP:BN (because I thought hopefully someone there might know), but it just occurred to me that asking here might be a good idea.

How would one contact a sysadmin? - jc37 01:05, 16 June 2012 (UTC)[reply]

Every time I've seen this asked at VPT the response has been IRC is the way to go. If you don't use IRC, then I don't know ... maybe one of the mailing lists? Jenks24 (talk) 01:20, 16 June 2012 (UTC)[reply]

You could leave a comment at one of the posts on http://blog.wikimedia.org/c/technology/. I think the sysadmins reply to those. Equazcion ^(talk) 01:56, 16 Jun 2012 (UTC)

You could also leave a user talk message for a user at http://wikitech.wikimedia.org. Also see http://meta.wikimedia.org/wiki/Wikimedia_Forum. Equazcion ^(talk) 02:01, 16 Jun 2012 (UTC)

If you don't use IRC, use iRC. It really is the best way. Specifically, use http://webchat.freenode.net and connection channel #wikimedia-tech, then ask away. Be prepared to have to wait and/or come back and ask again; if it's urgent, prefix with !sysadmin and people should come running. - Jarry1250 ^{[Deliberation needed]} 13:52, 16 June 2012 (UTC)[reply]

Thank you. I managed to finally figure out how to get there (irc).

And thank you for the advice, I appreciate it : ) - jc37 14:26, 16 June 2012 (UTC)[reply]

Edit Counter

I'm wondering how to safely make this page: User:TruPepitoM/EditCounterOptIn.js without any malicious content. Thank you. TruPepitoM (talk) 03:03, 16 June 2012 (UTC)[reply]

Just write anything you like in it. That warning is only for pre-existing scripts that you received from an unknown source. Graham87 04:15, 16 June 2012 (UTC)[reply]

The warning is applied to any page ending in .js, whether it's malicious or not. Chris857 (talk) 16:16, 16 June 2012 (UTC)[reply]

`.wiki` top-level domain

For your information, the CEO of AboutUs.org has applied for the .wiki top-level domain.^[7] I would have expected Wikia to apply as well, but apparently they didn't. —Ruud 10:16, 16 June 2012 (UTC)[reply]

Stupid bug to fix in the Wikipedia home page

Hello folks !

Please see and hear that bug in the Wikipedia home page.

Can someone fix that stupid bug, caused by stupid JavaScript I guess ?

Thanks,

--Nnemo (talk) 17:25, 16 June 2012 (UTC)[reply]

You entered SYRIZA and were redirected to Coalition of the Radical Left. What's wrong with that? --Redrose64 (talk) 18:13, 16 June 2012 (UTC)[reply]

Finish watching the cast. --Izno (talk) 18:15, 16 June 2012 (UTC)[reply]

This is recreatable on Windows as well with the appropriate keyboard shortcut. I wonder why the shortcut and the back button exhibit different behaviours? - Jarry1250 ^{[Deliberation needed]} 18:21, 16 June 2012 (UTC)[reply]

No. Absolutely no idea what I'm supposed to be watching for here. --Redrose64 (talk) 18:33, 16 June 2012 (UTC)[reply]

Special Search is loaded via javascript when the user never desired to go there. How did you miss that part...? --Izno (talk) 18:35, 16 June 2012 (UTC)[reply]

As below. I know that pressing Alt+⇧ Shift+F then ↵ Enter will invoke Special:Search. But I have no idea what keys are being pressed by Nnemo; I see a mouse pointer which is largely stationary, but occasionally moves to click on e.g. the puzzleball. --Redrose64 (talk) 19:01, 16 June 2012 (UTC)[reply]

Nnemo's video has speech which states that only back is pressed. Including "and hear" in the link name was a weak indicator that sound is needed. Lots of people (including me) usually have sound turned off when they browse. PrimeHunter (talk) 19:36, 16 June 2012 (UTC)[reply]

It doesn't happen to me in any of five tested browsers: Firefox, Internet Explorer, Opera, Google Chrome, Safari. It looks like your browser sends an Enter key signal after you go back. Pressing Enter in the search box with no content goes to the search page your video displays. Pressing Enter was the last thing you did before leaving the Main page. Perhaps your browser remembers that and for some reason automatically sends an Enter signal when you go back? Which browser is it? Do you go back with a keyboard shortcut? PrimeHunter (talk) 18:37, 16 June 2012 (UTC)[reply]

Yes, if you listen to the audio Nnemo's using the keyboard shortcut Alt+Shift+<- (or the Mac equivalent, rather). As I posted above, only if you use the keyboard shortcut can you recreate this. - Jarry1250 ^{[Deliberation needed]} 20:51, 16 June 2012 (UTC)[reply]

IBM PC keyboard (Windows, ANSI US layout) v t e
Esc	F1	F2	F3	F4	F5	F6	F7	F8	F9	F10	F11	F12	PrtScn/ SysRq	Scroll Lock	Pause/ Break

													Insert	Home	PgUp	Num Lock	∕	∗	−
													Delete	End	PgDn	7	8	9	+
																4	5	6	+
														↑		1	2	3	Enter
													←	↓	→	0 Ins		. Del	Enter

There is still nobody reporting this problem who have said which browser they use. I have a Windows PC with the 5 largest browsers and a normal IBM-like keyboard similar to the above. All 5 browsers go back on Alt+← or ← Backspace, as listed at Table of keyboard shortcuts#Browsers / Go menu. After testing all 5 with several different key shortcuts I have finally been able to reproduce the problem. All 5 work with ← Backspace. All 5 work with Alt+← when the "normal" left arrow to the right of the right side Ctrl is used. 3 of them work with Alt+← when the left arrow on the 4 on the numeric keypad is used: IE, Chrome, Opera. 2 of them give the reported problem with Alt+← when that key is used: Firefox and Safari. It's apparently because the key combination is an Alt code which is not disabled by the browser when it goes back. So the affected browsers perform two actions on the same key combination: First they go back and then they write the Alt code in the search field and trigger a search. PrimeHunter (talk) 21:57, 16 June 2012 (UTC)[reply]

Apologies, I meant to imply that I tested Windows+Safari, and could reproduce. I cannot reproduce this in Windows+Firefox, however. - Jarry1250 ^{[Deliberation needed]} 01:31, 17 June 2012 (UTC)[reply]

I can reproduce the bug in Safari 5.1.7 under OS X Lion. In the video, he was using Safari on either Leopard or Snow Leopard. For some reason, when using the standard keyboard shortcut (⌘ Cmd+←) to go back, occasionally it will briefly load the home page, but then redirect to Special:Search. Curiously, it doesn't exist in either Chrome 20 or Firefox 14, so it appears to be Safari on Mac-specific. elektrik SHOOS (talk) 22:28, 16 June 2012 (UTC)[reply]

Very weird Wikimedia Traffic Analysis Report - Operating Systems

Hi. The page http://stats.wikimedia.org/archive/squid_reports/2011-12/SquidReportOperatingSystems.htm Seems to give an estimated market share of operating systems as they access Wikimedia. However, how reliable is it? What is the meaning of "Linux Other"? And since Linux Other has more share than the most popular Linux distro, it seems that the margin of error is huge... for all we know, maybe all Linux Other boxes are Fedora, and therefore Fedora is more popular than Ubuntu... What's more, the usage of Mint, Debian and Kubuntu are listed as 0.01% each, which is 67 times lower than Ubuntu. Ubuntu may be popular, but not so much. If you can answer my questions, I could perhaps use these numbers in the articles for each Linux distro. -- Jorge (talk) 02:32, 17 June 2012 (UTC)[reply]

Presumably the "Other" row contains user agents like "Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0": no distro specified. Anomie ⚔ 03:51, 17 June 2012 (UTC)[reply]

But which distros use that generic UA?

And how useful are the Wikimedia OS stats with so much uncertainty?

I ask because because those stats are used in Ubuntu_(operating_system)#Critical_reception -- Jorge (talk) 13:44, 17 June 2012 (UTC)[reply]

Remember also that an end user might get their browser direct from upstream rather from their distro, and that some might spoof their user agent to appear to be a more mainstream browser/OS for various reasons. A quick glance at http://svn.wikimedia.org/viewvc/mediawiki/trunk/wikistats/ also indicates that those stats just look for the literal distro name, e.g. they don't bother to try to count Iceweasel as being (most likely) Debian. Anomie ⚔ 16:41, 17 June 2012 (UTC)[reply]

Error in parser function

OK, aren't parser functions supposed to trim the output? And even if not, I can't figure out why I'm getting an extra carriage return in the output. This is causing major problems for a template I'm writing on Commons, because a carriage return interrupts a link. Let me show you:

Take this parser function: [[{{#ifeq:{{{1}}}|:|Main Page|{{{1}}}}}]] (that is, if parameter 1 is equal to simply a colon, then display "Main Page", otherwise display parameter 1).
Now, for {{{1}}} = :wiktionary:, it generates [[{{#ifeq::wiktionary:|:|Main Page|:wiktionary:}}]]. This is interpreted to [[

wiktionary:]] (notice the carriage return), when it should be interpreted to [[:wiktionary:]], i.e., wiktionary:.

Am I reading this, wrong, or is there a bug? Why is it adding an extra carriage return in the ifeq function? Magog the Ogre (talk) 08:17, 17 June 2012 (UTC)[reply]

See Wikipedia:Advanced template coding#MediaWiki wiki-formats the clauses inside #if and bugzilla:12974. Your example could move the link brackets into the parameters to avoid the leading colon: {{#ifeq:{{{1}}}|:|[[Main Page]]|[[{{{1}}}]]}}. PrimeHunter (talk) 09:57, 17 June 2012 (UTC)[reply]

The text at that link is impossibly thick to read. I'll simply have to make use of your solution and move along. Or will it also cause the link to be moved down by a line as well? We can't have the link on the next line. Magog the Ogre (talk) 10:17, 17 June 2012 (UTC)[reply]

My solution doesn't move down a line. The trick is to avoid that the parser function parameters can start with any of *#:;. My solution always starts with [. PrimeHunter (talk) 11:08, 17 June 2012 (UTC)[reply]

Note: It's OK to start with these characters in the input parameters, in your case {{#ifeq:{{{1}}}|:|. The problem is in the return parameters. PrimeHunter (talk) 11:19, 17 June 2012 (UTC)[reply]

Tab "history" doesn't work

On the article Das Käthchen von Heilbronn, the tab "history" doesn't work; it produces the message "Bad title". The tabs "talk" and "edit this page" work. I can get to the history by manually entering the URL https://en.wikipedia.org/w/index.php?title=Das_Käthchen_von_Heilbronn&action=history to the URL (click here). The same action works on a very similar page, Das Käthchen von Heilbronn (opera). Why is it so, and how can it be fixed? Baffled, Michael Bednarek (talk) 10:16, 17 June 2012 (UTC)[reply]

It works for me. Which url do you get by clicking history? I get http://en.wikipedia.org/w/index.php?title=Das_K%C3%A4thchen_von_Heilbronn&action=history. Does that work for you? What is your skin? Try it when you are logged out. PrimeHunter (talk) 11:13, 17 June 2012 (UTC)[reply]

Works in Chrome, Mozilla and IE, Vector.--Gilderien Chat|List of good deeds 11:16, 17 June 2012 (UTC)[reply]

I may not have made myself clear. The "click here" link above works; I included it as a clickable link of the preceding text which I entered manually into the browser. What doesn't work is the tab "history"; it produced the URL https://en.wikipedia.org/w/index.php?title=Das_K%25C3%25A4thchen_von_Heilbronn&action=history (click here). This is here true for Firefox and IE, logged in or not; Chrome (21.0.1171.0) works -- Michael Bednarek (talk) 11:40, 17 June 2012 (UTC)[reply]

Oh right, ok, sorry, mis-read that.--Gilderien Chat|List of good deeds 12:02, 17 June 2012 (UTC)[reply]

Okay, so it seems to be a bug in the LastModified extension, which is double-percent-encoding its input title. I'll bug someone on IRC. - Jarry1250 ^{[Deliberation needed]} 13:34, 17 June 2012 (UTC)[reply]

The article Das Käthchen von Heilbronn seems to be part of the new experimental time stamp test described above as the interface has the new timestamp in the top right corner. However Das Käthchen von Heilbronn (opera) doesn't appear to be part of the test. Don't know if it's relevant but seems a bit of a coincidence if not. 82.132.139.73 (talk) 13:46, 17 June 2012 (UTC)[reply]

No, it's definitely relevant: as I say, it's a problem with the LastModified extension that powers the "experimental time stamp test". - Jarry1250 ^{[Deliberation needed]} 14:45, 17 June 2012 (UTC)[reply]

The history tab on Das Käthchen von Heilbronn worked for me in three tested browsers but I didn't have the new timestamp. #New feature experiment above says "we're going to try presenting the new timestamp to 50% of viewers". The bug apparently only affects those 50%. I don't know how the 50% are chosen but I have now tried a fourth browser and then I got the time stamp and bug. The bug (and the time stamp) disappeared when I enabled "Exclude me from feature experiments" at Special:Preferences#mw-prefsection-rendering. PrimeHunter (talk) 15:05, 17 June 2012 (UTC)[reply]

This is a strange bug, since I can replicate the error when visiting that page, but not on other pages with the timestamp experiment on them, like Ryu and Goldberg Variations. I will pass on the bug report regardless of course. Steven Walling (WMF) • talk 03:57, 18 June 2012 (UTC)[reply]

It's happening because of the special characters in the page name (in this case, the dotted "a"). The code is double-encoding the URL, which makes it a bad title - which is why you won't see it on pages that are "straight" ascii.--Jorm (WMF) (talk) 04:41, 18 June 2012 (UTC)[reply]

The "ä" in the title of Das Käthchen von Heilbronn alone does note explain why the same faulty behaviour does not occur with Das Käthchen von Heilbronn (opera). -- Michael Bednarek (talk) 10:33, 18 June 2012 (UTC)[reply]

According to anon Das Käthchen von Heilbronn is part of the test, Das Käthchen von Heilbronn (opera) is not. Taemyr (talk) 10:37, 18 June 2012 (UTC)[reply]

Transcluding a magic word

I used magic word {{REVISIONTIMESTAMP}} in a template. As documented, mw:Help:Magic words, when transcluded it takes the value of the receiving page, not the template's page. Is there a way to change that (so as to reflect in transclusion: This template was last edited on ...)? Details & example here. -DePiep (talk) 16:12, 17 June 2012 (UTC)[reply]

Oh, if only. A related problem is that of {{PAGENAME}} meaning that any template which has {{navbar}} links must be told what its own name is, in order for those links to work. --Redrose64 (talk) 17:30, 17 June 2012 (UTC)[reply]

Delinking dates

I was asked to post this notice here and several other places. I have started a discussion at Wikipedia talk:Manual of Style/Dates and numbers#Delinking dates on delinking dates using an AWB bot. Input is always appreciated. Hmains (talk) 19:33, 17 June 2012 (UTC)[reply]

Reference desk archive search function broken?

Hey, is the Ref Desk archive search function broken or something? I can't get it to work. Wikipedia:Reference desk/Archives and type a common term in the search box, and it doesn't search. It tries to make me create a page instead. Any clue as to what happened? This worked up until a few weeks ago. --Jayron32 01:39, 18 June 2012 (UTC)[reply]

It's not working because all prefix: searches aren't working at the moment, it seems. I'm not sure why that is though. Equazcion ^(talk) 02:09, 18 Jun 2012 (UTC)

Scrap that, only some prefix: searches aren't working right now. this one doesn't work, but this one does. Equazcion ^(talk) 02:11, 18 Jun 2012 (UTC)

Okay now they all seem to work, including the reference desk archive search. Equazcion ^(talk) 02:13, 18 Jun 2012 (UTC)

API question relating to recent uploads

What is the best way to get a list of all the uploaded files in a certain time range in the API? Currently, my bot is using the logevents action (e.g., [8]), but to my dismay, I realized that it is not including bot uploads, which is a deal-breaker.

Is there a way to do this?

PS. It would be nice if the this method were able to look back further than logevents (i.e., ~1 month on Commons), but currently that is second in importance.

Magog the Ogre (talk) 02:57, 18 June 2012 (UTC)[reply]

Two comments:

Why do you think it is ignoring bots? For example, the sixth item in the query you link (commons:File:Lsuaerial.jpg) appears to be an upload by commons:User:File Upload Bot (Magnus Manske), which seems to be a bot.
You are not using logevents, you are using recentchanges. A logevents query would be something like [9], and can go back very far indeed.

HTH. Anomie ⚔ 03:40, 18 June 2012 (UTC)[reply]

Spontaneous page blanking

This is kind of a hard problem to describe, so bear with me. My problem is basically that, whenever I've tried to edit a page in Firefox (in roughly the past week), the editing page will load up just fine, but after a few seconds the editing field will spontaneously delete itself, with no kind of input from me via keyboard or mouse. In order to stop this from happening, I have to wait until the editing page is only partially loaded, and manually stop my browser from loading the rest of it. Once that's done I can usually edit it fine, but it still occasionally goes screwy shortly after I click "Save Page" (I've blanked at least two pages so far because of this problem).

I can easily solve this problem by editing in Internet Explorer, and I guess that's what I'll be doing for now, but Internet Explorer is also, you know, Internet Explorer. I'm running 64-bit Windows 7 on a new-ish HP laptop, if any of that matters. Evanh2008 ^{(talk|contribs)} 06:08, 18 June 2012 (UTC)[reply]

RfC concerning template space

Protecting template space and creating a user right

Support

Oppose

RfC - proposal for template editor user-right

Support

Oppose

Discussion

Alternative: FlaggedRevs on Template: namespace

Diff/watchlist difficulties

Automated signature on talk page generates bogus edit conflict

Need some help with a template question

MediaWiki:Sp-contributions-footer-anon

New feature experiment

Possibly related problem

Feedback

Possible bug

possibility to search files local

Editor-save&edit

May statistics gone?

Logged Out

Username with trailing wildcard

The Ghost Ship

IPv6 schoolblock question

{{Wide template}} with extra scrollbar above?

Strange IP address

User talk:Jereemy

Database error screwed up my move!

{{S-line}} doesn't work

Suggestion for Dynamic List

Template inclusion limit?

Custom colours in My Watchlist, and possibly other pages

fill in citation from ISBN, DOI, etc.

Wikipedia incredibly slow

Anchor doesn't work right

IDEA : Automate DEFAULT Disambiguation on (internal wikipedia) links based on ARTICLE CONTEXT

Search function for books returns null or incorrect result

Sysadmin

Edit Counter

.wiki top-level domain

Stupid bug to fix in the Wikipedia home page

Very weird Wikimedia Traffic Analysis Report - Operating Systems

Error in parser function

Tab "history" doesn't work

Transcluding a magic word

Delinking dates

Reference desk archive search function broken?

API question relating to recent uploads

Spontaneous page blanking

`{{Wide template}}` with extra scrollbar above?

`.wiki` top-level domain