Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

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 securitywikimedia.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.

« 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, 214, 215

Can category presence be done by a template?

There are some really clever things that happen when executing templates. Can someone tell me if the presence of [[Category:Category name]] be detected and changed to [[:Category:Category name]]? (note the colon) I want to have such a function on {{AFC submission}} to stop AFCs from polluting content categories. -- Alan Liefting (talk - contribs) 07:54, 16 April 2013 (UTC)

Detection of things that aren't parameters in the template requires JavaScript. Ping me and we'll discuss it. Technical 13 (talk) 11:09, 16 April 2013 (UTC)

Could be detected with a LUA template. -- WOSlinker (talk) 11:41, 16 April 2013 (UTC)

It's "Lua", not "LUA" (cf. <http://www.lua.org/about.html#name>). --MZMcBride (talk) 21:27, 22 April 2013 (UTC)

[edited] I think I disagree. Not about Lua, but that Javascript is required.

{{#ifexist: Category:Non-talk pages that are automatically signed | Category:Non-talk pages that are automatically signed | Category:Non-talk pages that are automatically signed }}

→ Category:Non-talk pages that are automatically signed exists

{{#ifexist: Category:Category name | Category:Category name exists | Category:Category name doesn't exist }}

→ Category:Category name doesn't exist

See mw:Help:Extension:ParserFunctions.

—Trappist the monk (talk) 11:46, 16 April 2013 (UTC)

I'm not sure what you are getting at Trappist. The problem is that when new users are creating AfC articles, they are adding categorization to the pages. We have NO idea what categories they may add, but don't want any of the pages in content categories. It doesn't matter if the categories exist or not. What is wanted is something like:

if ((mw.config.get('wgNamespaceNumber') == 4 || mw.config.get('wgNamespaceNumber') == 5) && mw.config.get('wgTitle').match(/Articles for creation\//){
  if ($('div#catlinks')){
    /* Edit the page and replace /\[\[Category:(.*?)(\|?.*?)?\]\]/gi with [[:Category:$1$2]] */
  }
}

Although I would have to learn a lot more about writing JavaScript for MediaWiki to do that. Technical 13 (talk) 12:00, 16 April 2013 (UTC)

I've written Module:AFC submission catcheck and added it to Template:AFC submission. If any pages are found, they will be added to Category:AfC submissions with categories -- WOSlinker (talk) 12:14, 16 April 2013 (UTC)

I've tried it with Wikipedia talk:Articles for creation/Alexander Karasyov: while the obvious mainspace cats are now commented out, the page remains in the new "with categories" category you created. Perhaps further checks which cats are acceptable and which warrant an inclusion in that new cat are necessary. Fram (talk) 12:26, 16 April 2013 (UTC)

Unfortunatly, because of the way the templates are processed, there is a lag in detection and you need to edit twice to get it to notice the change. -- WOSlinker (talk) 12:33, 16 April 2013 (UTC)

Thanks. An additional null edit did the trick indeed. Useful cat, I used to search these through AWB but this makes life easier. Fram (talk) 12:59, 16 April 2013 (UTC)

WOSlinker, I would rather they never get into content categories at all (and I would hope everyone agrees on this!). We now have a tracking category sitting there with work to be done that may not get done (seen the WP:BACKLOG lately?). BTW, good effort tho. -- Alan Liefting (talk - contribs) 21:31, 16 April 2013 (UTC)

What we've got here is failure to communicate. As I consider Editor Alan Liefting's post a bit more, I wonder if there is a solution. If the goal is to prevent an article in the AFC process from being included in any categories until after the approval process has run its course, then the method I outlined will work if an editor implements it. I'm guessing that the same it true for Editor WOSlinker's solution and for your solution. The problem with all of these is that an editor must act.

If I understand how categories work, and I'm far from expert on them, articles will end up in categories whether anyone reads the article or not. As long as there is a [[Category:Category name]] wikilink in the article source, the article will be categorized. So isn't the question: How do you prevent an article in the AFC process from being categorized? Whatever the mechanism is, it must actually edit the article source to change [[Category:Category name]] to [[:Category:Category name]]. A robot that knows about {{AFC submission}}s? A special quarantine area for AFC articles that inhibits categorization?

—Trappist the monk (talk) 12:55, 16 April 2013 (UTC)

I don't care as to the mechanism. As long as AFCs don't get into content cats I am happy. Having a bot chase after AFCs are submitted that have had categories added is "messy". -- Alan Liefting (talk - contribs) 20:22, 16 April 2013 (UTC)

I think that's not possible without using a bot, and not too messy with a bot, even before submission, since AFC is a well-defined area. The more challenging task would be to de-activate all content category tags on articles developed in user space. — HHHIPPO 21:33, 16 April 2013 (UTC)

Unmm, hang on. Once an AFC is submitted and it contains content categories it is immediately visible by readers perusing categories since it will take a finite and possible lengthy amount of time to remove the categories. The issue of categories in user namespace is quite separate to the AFCs. The polluted category database reports help out with that problem. -- Alan Liefting (talk - contribs) 21:50, 16 April 2013 (UTC)

Incidentally, we have no way of differentiating content categories form maint categories. -- Alan Liefting (talk - contribs) 21:31, 16 April 2013 (UTC)

You're right. Identifying content categories is tricky. It can be done on a WikiProject level, but for all of Wikipedia it would be a nightmare. So you're suggesting to disallow all categories on AFCs? That would probably require an new namespace, probably also software changes. How about making another pollution report for categories that contain both main and project space pages? — HHHIPPO 06:27, 17 April 2013 (UTC)

Maintenance categories should all sit somewhere below Category:Wikipedia administration. -- John of Reading (talk) 07:06, 18 April 2013 (UTC)

Reflist script error?

This revision [1] of Patriots' Day looks fine. Then in this edit [2], two words, "of Hawaii", not even inside ref tags, got removed, and now the article [3] shows "Script error" for all the entries under the "References" heading. What's going on? —Lowellian (reply) 08:33, 16 April 2013 (UTC)

I don't see any errors (in refs or anywhere else, other than a redlink) in that or the version after it (which is current). —[AlanM1(talk)]— 09:08, 16 April 2013 (UTC)

Must have been some sort of transient server error, because the links no longer show the errors that were there earlier. —Lowellian (reply) 09:27, 16 April 2013 (UTC)

Check the history. I fixed it by using mdy dates... as it seems. mabdul 11:07, 16 April 2013 (UTC)

strike that, seems to be an server error. mabdul 11:08, 16 April 2013 (UTC)

Neither {{reflist}} nor Cite use "Script error". --  Gadget850 (Ed) ^talk 13:22, 16 April 2013 (UTC)

I saw the message: it was a LUA error message with extended error message when clicking it. Sadly I didn't copy and pasted it. mabdul 13:34, 16 April 2013 (UTC)

It's "Lua", not "LUA" (cf. <http://www.lua.org/about.html#name>). --MZMcBride (talk) 21:26, 22 April 2013 (UTC)

• Extremely busy servers might hit Lua timeout to show Script error: We have been trying to get the Lua timeout-limit raised from 10 seconds to perhaps 30 seconds, because in very rare cases, when the servers get extremely busy for over 10 seconds during Lua processing, then the Lua clock is charged those 10 seconds, and the next Lua-based template (or #invoke of a Lua function) will detect a past-due timeout, such as 11.3 Lua seconds or such, and then all subsequent Lua functions might show "Script error" as the text stored into the cached form of the top-revision of a page. Unless the page cache is reformatted, such as by changing an embedded template/module, then the red "Script error" text will remain in the cached form (for top revision) and get pulled into each cache-copy which overlays a user's username and skin menus to generate the rendered webpage. In cases where the top-revision shows the Script-error text, try a null-edit. However, in edit-preview, just rerun as another edit-preview, because the occurrence is so rare, for an extremely busy server to be delayed nearly 10 seconds, during a Lua function. In fact, it is so rare that some people might insist "no one" really saw "Script error" in a page that typically uses "0.03" seconds of Lua time, when they really did. This is just a matter of getting the developers to understand how the Lua-clock elapsed time is really affected, can really stretch beyond 10-second timeout, on busy servers. I have two degrees in computer science, and it was a total shock to me as well, but the evidence keeps recurring. -Wikid77 (talk) 18:56, 17 April 2013 (UTC)

Subscript spacing

Has the vertical spacing of subscripts been adjusted recently? I have started to notice in Firefox that subscripts are very low down causing the line spacing to open up on lines that have subscripts. Possibly this is a Firefox rendering problem, but I'm sure it never used to be like this. Internet Explorer doesn't have this problem, the subscripts are almost aligned with the bottom of normal text. SpinningSpark 15:01, 17 April 2013 (UTC)

• Perhaps depends on browser version: What version of Firefox browser are you running? Compare results and try different skins (&useskin=monobook):

For years, the height of superscriptsx seemed excessive, as sitting at the top of lowercase 'n'x, compared to subscripts(x), which were only a half-letter lower (5px?) than flat text, as here: (joggy). Compared to subscript(Texting), the excessive height of some superscripts, perhaps capsABC would even chop the tops off letters in some skins, such as &useskin=monobook.

For years, the height of superscriptsx seemed excessive, as sitting at the top of lowercase 'n'x, compared to subscripts x, which were only a half-letter lower (5px?) than flat text, as here: joggy. Compared to subscript Texting, the excessive height of some superscripts, perhaps capsABC would even chop the tops off letters in some skins, such as &useskin=monobook.

Perhaps newer versions of Firefox lower the subscripts, whereas older versions of Firefox keep the same line-height, regardless of subscripts, and only superscripts had caused Firefox to lower the line level. What browser skins have you compared? -Wikid77 (talk) 17:36, 17 April 2013 (UTC)

I use the Monobook skin and am running Firefox 20.0.1. I have just tried Vector and Classic as well with the same result, that is good in IE (10.0.4) but too low in Firefox. SpinningSpark 22:34, 17 April 2013 (UTC)

Just checked on my notebook which is still running Firefox 19.0.2 (until I restart it). The subscripts look normal in that. SpinningSpark 22:40, 17 April 2013 (UTC)

I see no difference on MacOS X Mountain Lion with FF 19 vs FF 20. Perhaps it is a Windows only issue ? It can also be an issue with the font (or font selection) perhaps. —TheDJ (talk • contribs) 09:45, 18 April 2013 (UTC)

I have now let my notebook upgrade to FF20 so it is on the exact same version and there is no problem there. I have checked the advanced Font settings and they appear to be identical. The only significant difference is that the computer with a problem is Windows 7 and the notebook is XP. But if it's an issue with Windows 7, why is it ok in IE? SpinningSpark 10:55, 18 April 2013 (UTC)

Firefox uses a different method of hardware acceleration on Windows 7 vs Windows XP. On 7, Firefox uses DirectWrite to render fonts. DirectWrite is only available in DirectX 10 or greater, and that version requires at least Windows Vista. On XP, Firefox uses the older GDI technology to render fonts, which provides little to no acceleration.

As Internet Exlporer version 9 and greater also use DirectWrite, it is unlikely the bug is with Windows. It is most likely that there is a problem with Firefox's DirectWrite implementation, so you should probably file a bug at the Firefox Bugzilla. It is possible that Internet Explorer either uses DirectWrite differently or works around a bug in the software. However, that's something for the Firefox developers to figure out.
— trlkly 20:26, 22 April 2013 (UTC)

Why are new edits introducing seemingly random errors into previous page content?

Another user's recent edits to my user talk page have resulted in some peculiar changes to the existing content on that page, for example: diff. This is just related to that one user's edits. Can someone explain what is going on -- and can I/we prevent this from happening in the future? --Orlady (talk) 02:54, 18 April 2013 (UTC)

As a first step, I've posted at User talk:Gregbard#Strange damage to text to ask if there's a simple explanation. -- John of Reading (talk) 07:18, 18 April 2013 (UTC)

I am having intermittent problems with my computer. It is fairly rare, but every once in a while it happens. My apologies for this instance. Greg Bard (talk) 07:21, 18 April 2013 (UTC)

Thanks for looking into this. It appears that this could be some sort of a software problem -- systematically replacing certain characters or strings with something else. I thought it might be related to a strange incompatibility of user font preferences on Wikipedia, but it does sound like the issue was on the user's computer. Since it happened multiple times on my talk page and took an inordinate amount of effort to repair (I couldn't "undo" due to subsequent changes on the page), I wanted to make sure it wouldn't be happening again. I hope that's the case! --Orlady (talk) 14:28, 19 April 2013 (UTC)

The nature of the errors makes me think you likely have malware on your computer, Greg Bard. I am not sure if there is a Wikipedia essay on removing Malware, so I will point you to a guide I've seen multiple people use successfully: [4]. Please follow the instructions there to help make sure that this sort of thing doesn't happen again. Cheers. — trlkly 20:35, 22 April 2013 (UTC)

invisible glitch

Tracked in Phabricator
Task T49438

Theres a serious glitch here with sections going missing. A few days ago some categories had entries mysteriously missing. Now a post by an admin on AN/I is only visible during a diff, but not without the diff. Is this only happening to me? What can i do? Its like shit is mysteriously going missing. Pass a Method talk 03:35, 19 April 2013 (UTC)

Links would help figure out what is going on. EVula // talk // ☯ // 03:45, 19 April 2013 (UTC)

Have you tried purging either your own computer's cache, or the page itself? Someguy1221 (talk) 03:46, 19 April 2013 (UTC)

Never mind, I found it. Masem accidentally deleted my comment. No glitch - just an editor's error. Someguy1221 (talk) 03:49, 19 April 2013 (UTC)

I had my own comments on that article talk page (not the ANI) deleted twice apparently by accident also. And it seems like I'm constantly having edit conflicts even though the others aren't editing that particular section. There isn't something gone wrong recently with how the edit conflict code is processed, is there? (I never use it myself - I back-arrow, copy the text, hit the Editing section.. version in my browser history, and paste into that.) Wnt (talk) 04:01, 19 April 2013 (UTC)

Wait a minute: "new section"? And it overwrote the old material? This should not be allowed to happen. Let's say someone is editing a section. After he presses "Save page," this is what should happen:

1. Acquire a lock on the entire page. If acquisition fails, repeat.
2. Check if anyone else has saved changes to the section being edited. If so, return an edit conflict and release lock. If not, proceed.
3. Combine the current section with all the other sections to fill in the content of the page.
4. Save the page.
5. Release the lock.

Is this not what happens? -- King of ♥ ♦ ♣ ♠ 04:53, 19 April 2013 (UTC)

Not quite right. Firstly, the edited section is combined with the rest of the page before checking for conflicts. MediaWiki determines what you changed by comparing against the previous revision, then applies those changes to what is now the current revision. You only get an edit conflict if MediaWiki is unsure how to apply your changes. This typically happens if another editor changed the same line as you, or changed a line immediately above or below one you had changed.

There is a bit of a difference when using "new section", though. In that case, the section you are adding just gets tagged to the end of the current page. There should be no possibility for an edit conflict or for anything to be removed.

Of course, that's the theory. I've seen several cases of someone accidentally removing a previous comment; I suspect something goes wrong sometimes. I don't think it's anything recent; I've seen it several times over the last few months. – PartTimeGnome (talk | contribs) 21:50, 19 April 2013 (UTC)

But I am not talking about the part that concerns opening up a section to edit, which can take a long time and is what edit conflicts are for. I'm talking about the actual save, which is ideally instantaneous but not so in practice. So what could happen is that two people are editing the last section and creating a new section, respectively, and both save at the same time. The software sees that there are no issues, and what happens is that the second person's revision overwrites the first person's revision. -- King of ♥ ♦ ♣ ♠ 00:16, 20 April 2013 (UTC)

I.e. a lost update problem (though the previous edit isn't really lost in our case, since it can still be retrieved through history). I suspect some problem with locking. I'm interested to see what the devs find on the bug you filed... – PartTimeGnome (talk | contribs) 14:17, 21 April 2013 (UTC)

Visual editor

I had the visual editor enabled in my preferences for testing purposes, and it just changed from giving me an edit tab and a visual editor tab to an edit tab (that is the visual editor) and an edit source tab. Can I switch that back somehow? Ryan Vesey 05:02, 19 April 2013 (UTC)

https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback might be a good place to ask, too. --AKlapper (WMF) (talk) 07:48, 19 April 2013 (UTC)

Tracked in Phabricator
Task T49396

I doubt you can change it back, this is probably in preparation of the full rollout of the editor. I notice that my e-shortcut key no longer works now, that's slightly annoying. And I wonder if we can find a better title than 'edit source'. —TheDJ (talk • contribs) 07:51, 19 April 2013 (UTC)

Bug 47396 concerns the shortcut issue.--Eloquence* 02:32, 20 April 2013 (UTC)

Is there any CSS code that will swap the functionality of "edit" and "edit source", so that "edit" functions as before and "edit source" is renamed "vis ed" and invokes the visual editor? Thanks--ukexpat (talk) 13:52, 19 April 2013 (UTC)

That's actually what I was looking for, is a bit of CSS code. Ryan Vesey 15:20, 19 April 2013 (UTC)

I've seen this also, and found it very confusing. The tab added should be "visual editor", which is explicit for what is after all not yet our usual editor, and does not yet have some key functionality, such as the ability to edit references. I don't want to have to add code to do this: it should be the default behavior. The way I've dealt with it is to remove the preference; I suspect others will do likewise, if the intent was to get more people to use it, it may have the opposite effect. Haven't we learned yet to stop making unannounced changes in the interface, including unannounced changes to widely used test features. — Preceding unsigned comment added by DGG (talk • contribs) 21:45, 19 April 2013 (UTC)

DGG, remember that this is an opt-in only alpha where you're specifically warned that it may be buggy or change. It's not really the same as making an unannounced change to a production interface that everybody depends on or has to opt out of to avoid. Steven Walling (WMF) • talk 19:23, 24 April 2013 (UTC)

The bug status says resolved, but it isn't for us dinosaurs who are still using Monobook - I still see the former "edit" and "edit source" tabs.--ukexpat (talk) 00:53, 24 April 2013 (UTC)

Two reasons for that: first, the last comment on the bug says that the change will not go live until Thursday, and second, that bug only concerns the lack of a tooltip or access key on the edit tabs, not the actual naming of the tabs. jcgoble3 (talk) 01:03, 24 April 2013 (UTC)

OK so back to the previous question: is there some CSS code that can do the "swap" as I asked above? Thanks.--ukexpat (talk) 13:24, 24 April 2013 (UTC)

Probably JavaScript actually. My best guess is:

( function ( $, undefined ) {
 jQuery(document).ready( function(){
$( '#ca-edit' ).find( 'a' ).text('VisualEditor');
$( '#ca-editsource' ).insertBefore($( '#ca-edit' )).find( 'a' ).text('Edit');
} );
} ( jQuery )); // End wrap with anonymous function

Unfortunately I think it gets into a race condition with the creation of the edit source tab so it only renames one of the tabs. There's probably an easy fix but I don't really have the time now, sorry. Hope that helps, - Jarry1250 ^{[Vacation needed]} 13:42, 24 April 2013 (UTC)

Brilliant, works for me. Thanks so much!--ukexpat (talk) 19:12, 24 April 2013 (UTC)

H.264 support

Tracked in Phabricator
Task T41869

Developments since Google reneged on dropping H.264 two years ago, possibly due to acquiring Motorola patents:

• Wikimedia rolls out TimedMediaHandler supporting H.264 transcoding
• WMF releases iPad app without Ogg or WebM support
• Mozilla will support H.264 when the underlying platform supports it
• Debian 7.0 "Wheezy" will decode H.264 media out of the box

Now that every modern platform supports it, so we're too late to pressure anyone into switching. So I suggest three transition phases: 1) Allow H.264 files masquerading as ogv/webm, 2) Allow uploading of H.264 and .mp4 extensions, 3) Enable transcoding to H.264. — Dispenser 05:38, 19 April 2013 (UTC)

This was never about pressuring anyone into switching. It's about Free and open information systems and not opening up ourselves to potential lawsuits by big techonlogy owners. Note that unlike for Mozilla for instance, we ARE part of those underlying systems (esp when it comes to transcoding), so there is quite a different risk assessment. —TheDJ (talk • contribs) 10:34, 19 April 2013 (UTC)

My post was to inform that all major platforms support H.264 video decoding, even Firefox on Debian the corner stop FOSS. H.264 is a "free" and open video codec, but patented (just like GIF). For the US, not even the oldest codec MPEG-1 (1992) is not patent free, and only more patent landmines have been laid. And even when Google purchases license from MPEG LA for everyone, it still doesn't the stop lawsuits. — Dispenser 23:03, 24 April 2013 (UTC)

New deployment date for Wikidata phase 2 (infoboxes)

Hey :)

As previously announced Wikidata phase 2 will be deployed on English Wikipedia next. 11 Wikipedias have already been using it successfully for a few weeks. All other Wikipedias are scheduled to follow 2 days after English Wikipedia. There were some technical issues we had to fix that delayed the last deployment. We now have a new date for it: Monday next week, so 22 of April.

This version is basic and only the start of phase 2 here and will allow using all data from Wikidata, not just the language links as done so far here. This phase will not do any automatic changes to existing articles or infoboxes. It will only be used if editors here change their article accordingly.

As a reminder: We have prepared an FAQ for this deployment and are looking forward to your testing and feedback. You can already test it on test2.

And some more details about how this will work: There are two ways to access the data:

• Use a parser function like {{#property:p169}} in the wiki text of the article on Yahoo!. This will return “Marissa Mayer” as she is the chief executive officer of the company.
• For more complicated things you can use Lua. The documentation for this is here.

We are working on expanding the parser function so you can for example use {{#property:chief executive officer}} instead of {{#property:p169}}. The complete plan for this is here.

Thank you so much for helping us bring Wikidata to all Wikipedias!

Cheers --Lydia Pintscher (WMDE) (talk) 12:55, 19 April 2013 (UTC)

=) ·Add§hore· ^{Talk To Me!} 13:13, 19 April 2013 (UTC)

We really need some automated tools otherwise this will be a complete disaster. I can foresee a huge flood of e-mails to OTRS about this.--ukexpat (talk) 13:55, 19 April 2013 (UTC)

Because of the nature of this change, which if implemented would mean the migration of article content to another site with potentially differing policy on sourcing or inclusion, and which many editors will not know how to edit. Any and All suggested changes of infoboxes to this standard will need a very strong consensus.Nigel Ish (talk) 14:06, 19 April 2013 (UTC)

If the documentation for this phase is as inscrutable as the documentation for Phase 1, then Phase 2 is not ready and should not be released. See WP:Wikidata, Create a new item, and Item by title. From those Phase 1 pages it is clear that Phase 1 documentation is not done (not started) yet.

Wikidata is a complex subject. Non-technical editors will need to be led through the process in a way that they can understand. The documentation as it currently exists may be quite sufficient for those who developed Wikidata, but it is woefully inadequate for the non-technical editor.

At the risk of being overly redundant: Phase 1 isn't ready for release so even thinking about releasing Phase 2 is premature. Don't do it.

—Trappist the monk (talk) 15:14, 19 April 2013 (UTC)

Frankly, documentation is never going to be marked "done" - and actual, practial use of wikidata is likely to substantially change what the documentation needs to cover, as opposed to what it is (in advance) perceived to cover. Wikidata is a wiki - let Phase II be launched, let users flood in, and if they can't find how to do something then, when they work it out, they can add it to the manual. Ironholds (talk) 18:29, 20 April 2013 (UTC)

While I'm excited at the prospect of a central repository for data that is used in multiple articles (like properties of countries, people, companies, public offices, etc.), I, too, am concerned that articles will start to include instead of Marissa Mayer because some small number of people know how to do it, much like the way many templates are now maintainable only by those who speak Lua, which (I'm guessing), is an awful lot smaller number than those who speak WikiML. Until there is a simple (e.g. Ctrl-right-click on ) procedure to create/edit/find these values, extreme caution is necessary. —[AlanM1(talk)]— 23:32, 20 April 2013 (UTC)

There's a request for comment concerning how we should use Wikidata phase 2 at Wikipedia:Requests for comment/Wikidata Phase 2. Please leave your opinions there. MER-C 12:00, 22 April 2013 (UTC)

Different display for readers vs. editors

Is there any existing mechanism, via CSS or otherwise, to vary what content is displayed to logged-in editors vs. general readers? It occurs to me that some of our message boxes and error messages can appear fairly mysterious to the general reader. I'm wondering whether it might sometimes be useful to display a more general information statement to readers while having a different and more focused message shown to editors that explained how to fix the problem. However, I don't think we presently differentiate any content for editors / readers, so I'm unsure if there is any natural way to accomplish such a thing. Of course one would also want to get the community's approval on whether such differences are a good idea in any particular application, but I'm wondering whether they are presently possible in principle or not. Dragons flight (talk) 01:06, 20 April 2013 (UTC)

My first impulse: a hacky way to do it currently is a by-default-enabled CSS/JS gadget. —Theopolisme (talk) 02:08, 20 April 2013 (UTC)

MediaWiki supports the ability to add CSS and JS that is only seen by users in a certain user group, and we use this for admins (see MediaWiki:Group-sysop.js and particularly MediaWiki:Group-sysop.css). The latter of those two shows CSS that is used to show information to admins only (MediaWiki:Common.css sets that class to "display:none" by default, which is overridden by MediaWiki:Group-sysop.css. However, this appears to only be supported for certain user groups, as this list does not show CSS/JS messages for all user groups (interestingly, the list does not seem to recognize MediaWiki:Group-accountcreator.css as a valid MediaWiki message). Autoconfirmed is supported, but not simply user. However, it would likely be simple (I'm guessing) for the devs to set it up for the "user" user group. jcgoble3 (talk) 02:58, 20 April 2013 (UTC)

Maybe Mediawiki:Group-editor.css from your list is meant to be all logged in users? Dragons flight (talk) 06:00, 20 April 2013 (UTC)

Editor is a special group used by Wikinews, but not enwiki. There's many groups on that list that enwiki does not use. Per MediaWiki:Grouppage-user and MediaWiki:Group-user, I believe simply "user" represents all logged-in users, and this is confirmed by going to my preferences, looking at the list of groups I'm in near the top, and clicking on "Users", which takes me to Wikipedia:Why create an account?. And the "user" user group, as noted above, does not seem to have its own JS/CSS pages. jcgoble3 (talk) 06:58, 20 April 2013 (UTC)

It seems that the group 'user' is explicitly excluded from the list of groups to add specific CSS and JS for. I'm not sure if there is a proper reason for this, but that is how it is currently coded. —TheDJ (talk • contribs) 11:28, 21 April 2013 (UTC)

Unnoticed editing

How is it that the preloaded preview template was edited by a new user, and went unnoticed for a good two months? This was causing that user's edits to show up every time you made a new PR. Very odd that no one noticed in TWO MONTHS. Ten Pound Hammer • ^{(What did I screw up now?)} 17:14, 20 April 2013 (UTC)

Because it doesn't have any watchers, which implies that you're not even watching it yourself. No watchers=nobody who cares. --Redrose64 (talk) 17:41, 20 April 2013 (UTC)

But still, the fact that someone else's review comes up whenever you make a new PR… Ten Pound Hammer • ^{(What did I screw up now?)} 18:09, 20 April 2013 (UTC)

Here I come....to watch the page! —Theopolisme (talk) 02:03, 21 April 2013 (UTC)

Too difficult to create username

(I will just copy this from another page):

You must change the policy. It is way too easy to trigger "username is too similar to existing". It happens when it is not that similar and isn't going to confuse anyone. People are running out of names. I tried 5 different names already. 174.236.79.80 (talk) 1:09 pm, Today (UTC−6)

I think name changes take a couple of weeks. You could create a temporary name and if you like Canoe1966 discuss it with Canoe1967. If they don't mind a name similar to theirs, then have admin change your temp one.--Canoe1967 (talk) 1:44 pm, Today (UTC−6)

The inconvenience discourages people from creating an account. 174.236.79.80 (talk) 2:02 pm, Today (UTC−6)

I see your point and sorry for just providing a work around. I don't know if the filter is easily adjustable or whether it needs a policy change. Someone on this page may know or at Wikipedia:Village pump (technical).--Canoe1967 (talk) 2:09 pm, Today (UTC−6)

(end of paste)

IIRC, account creators can override that limitation and create accounts with similar names, although I'd imagine they wouldn't create anything too similar. You can request an account at Wikipedia:Request an account. Chamal ^T•C 22:29, 20 April 2013 (UTC)

Thanks for the quick response. I think the OP feels that the filter may be causing us to lose editors though and may consider that as a work around. Is it adjustable or a policy thing? Could we add a message and link to Wikipedia:Request an account when IPs get the above message?--Canoe1967 (talk) 22:44, 20 April 2013 (UTC)

As an new ACC, I'm not even sure whether Canoe1966 is too similar or not. It's certainly reasonable to assume people will use different numbers after the same name to DAb them, but how similar is too similar (to 1967)? 1966? 1963? 1956? 19xx? 19? It does make more sense if, when told the username is too similar, to follow the ACC process if you feel the name is not too similar (versus creating another name and getting it changed later). It requires a lesser-privileged user, and is likely faster now that the ACC backlog is cleared. —[AlanM1(talk)]— 23:14, 20 April 2013 (UTC)

I just used Canoe1966 as an example in my work around before I knew Wikipedia:Request an account existed. We may wish to either put that link on the error page or loosen the filter. It seems the OP feels we are losing editors because the filter is too tight.--Canoe1967 (talk) 23:49, 20 April 2013 (UTC)

Balancing the caution due to malicious intent against the accessibility for those with beneficial intent is not that easy. Some people do try to create accounts that spoof an admin who blocked them or insult someone else. There is also the concern that people who are active contributors who have nigh the same user name could be confused for each other. Canoe1966 should technically be possible. If you were to attempt Canoel967 (using a lower-case letter L in place of the digit one) it should tell you it is too similar.
Without knowing what 174.236.79.80 (talk) was attempting to register it is impossible to be certain why 5 'too similar' notices were the results of 5 attempts to register an account.
Those with the admin or account creator user right can over-ride the spoofing checks and the title blacklist. (The latter because some proper names in other languages are profane slang in English and other like reasons.) The link to wikipedia:request an account is there but it is presented as an aid for those who have problems with the captcha. Surely it could be presented more clearly as an option for those having issue with the captcha or who believe they are getting a false positive on the spoofing check. delirious & lost ☯ ^~hugs~ 00:14, 22 April 2013 (UTC)

I see the point of the tight filter now. I know User:Jimbo online freaked me out when I first ran into him. Would it be an easy fix to add a more obvious link to wikipedia:request an account when a new name is rejected? I can't see it being controversial and it would be interesting to see if the number of requests increases after the change. This may indicate that we may have lost editors or have some named different than their first choice.--Canoe1967 (talk) 13:30, 23 April 2013 (UTC)

• I took a screen shot of a failed account: File:Account rejected screen 2013.jpg. Can we add the link to wikipedia:request an account inside the pink box? Also what is the 'reason' box for? Does that need to be clarified?--Canoe1967 (talk) 14:48, 23 April 2013 (UTC)

I am going to move this to the bottom as a new issue.--Canoe1967 (talk) 17:16, 23 April 2013 (UTC)

 Done here. Moved below.--Canoe1967 (talk) 17:16, 23 April 2013 (UTC)

Copyright violation box

Dear tech people:

When I am reviewing articles at the Afc, I sometimes come across copyright violations. When I decline a submission for this reason, the dialogue box asks for the URL that has been copied. There's a box to type or paste it in, but it's very small. It's hard to tell if the URL has been entered correctly. Could the box be made wider so that more of the URL would show on the screen? —Anne Delong (talk) 00:30, 21 April 2013 (UTC)

I guess this is about MediaWiki:Gadget-afchelper.js. You can post to Wikipedia:WikiProject Articles for creation/Helper script/Development page#Feedback. PrimeHunter (talk) 00:39, 21 April 2013 (UTC)

With URLs I usually right click and open in new tab from the edit preview to see if the link goes to the correct site page.--Canoe1967 (talk) 01:24, 21 April 2013 (UTC)

I am not sure what you mean. Do you first decline the copyright infringement, and then right click on the URL in the resulting notice? If so, I would prefer to catch the error at an earlier stage. —Anne Delong (talk) 12:30, 21 April 2013 (UTC)

I have left a message as suggested. —Anne Delong (talk) 12:39, 21 April 2013 (UTC)

I have never seen the decline/accept edit screen. I was referring to when I do a regular edit and want to check wikilinks and urls. They can be right-clicked from the preview of the edit section.--Canoe1967 (talk) 13:39, 23 April 2013 (UTC)

Technical proposal idea for the watchlist

While I was in the process of scanning for vandalism in my watchlist, I realized that I was having difficulty looking through my watchlist for vandalism due to the fact that all of the talk pages that I have on my watchlist are showing up as well. In effect, I had a thought, a thought I would like to run through this forum before starting some sort of "official" proposal, since I am under the assumption that this request might require the filing of a bug of some sort...

How feasible would it be to add a "Hide talk page edits" option to the watchlist? Steel1943 (talk) 05:14, 21 April 2013 (UTC)

Well, you can change it to look for specific namespaces; the default is "All". Just set it to "(Article)" and that'd be what you're asking for, I believe. EVula // talk // ☯ // 05:16, 21 April 2013 (UTC)

Not completely. That option only allows viewing of the pages in the "Article" space. I'm looking for an option that allows viewing of all spaces that do not have "talk" in their names all at once. Steel1943 (talk) 05:35, 21 April 2013 (UTC)

A smarter editor than I would be able to tweak User:Markhurd/hidetopcontrib.js, I bet. ~ Amory (u • t • c) 03:47, 23 April 2013 (UTC)

Little help with wikitable

Does anyone know of a more efficient way of centering all the content after Row2-Column3 in this table? (instead of individually centering each cell?) Thanks in advance. :) Rehman 06:16, 21 April 2013 (UTC)

:I'm answering this for two reasons, first is of course to answer your question, and the second is to wonder if anyone else is seeing the extended content that appears to be part of this post but isn't. It seems to have happened at this edit by User:MiszaBot II. Fixed by Editor This, that and the other.

I re-fixed the fix. A section contained three chunks of example output from some external process, each chunk was enclosed in {{cot}}/{{cob}}. One of these chunks contained == {{int:filedesc}} == which MiszaBot II assumed was the start of a new section, so it archived that off and in so doing took the third {{cob}} with it. An unclosed {{cot}} always moves to the bottom of the displayed page. --Redrose64 (talk) 11:59, 21 April 2013 (UTC)

I don't think there is a way to center the content of a single column because the wiki table markup is just an abstraction of the HTML markup which is all row-centric: table row tags <tr>...</tr> hold multiple table data tags <td>...</td> that hold the row's column data. Styling is applied to <td> so for a particular column must be applied individually at each row's column. There is an obvious need, I wonder why it hasn't been addressed.

—Trappist the monk (talk) 10:25, 21 April 2013 (UTC)

If you want to center the majority of all cells in a table then you can start the table with {|class="wikitable" style="text-align:center;", and then left or right align the cells you don't want centered. PrimeHunter (talk) 10:45, 21 April 2013 (UTC)

Thanks Prime. That should do for now I guess. Rehman 11:56, 21 April 2013 (UTC)

Datasift/Tweetmeme crap: heads up for tool maintainers

• 46.236.7.249 - - [21/Apr/2013:06:28:57 -0700] "GET /linksearch.jsp?link=htm2pdf.co.uk HTTP/1.1" 403 300 - "Mozilla/5.0 (compatible; TweetmemeBot/3.0; +http://tweetmeme.com/)" "wikipediatools.appspot.com" ms=297 cpu_ms=23 cpm_usd=0.000034 app_engine_release=1.7.7 instance=00c61b117c992c970338b324421579b708512e
• ...
• 46.236.24.47 - - [21/Apr/2013:06:21:15 -0700] "GET /linksearch.jsp?link=loadmastertrailerco.com HTTP/1.1" 403 300 - "Mozilla/5.0 (compatible; TweetmemeBot/3.0; +http://tweetmeme.com/)" "wikipediatools.appspot.com" ms=245 cpu_ms=23 cpm_usd=0.000034 app_engine_release=1.7.7 instance=00c61b117c992c970338b324421579b708512e

$ whois 46.236.7.249
inetnum:        46.236.7.0 - 46.236.7.254
netname:        DEDIPOWER-DEDICATED-O1FL
descr:          MediaSift Limited

Just a heads up: I've had 1000+ hits from these guys in the last 37 minutes (that's about 1 every two seconds). robots.txt is ineffective, so you will have to hard blacklist them. They're also not paying attention to Wikipedia's robots.txt. This is a social media monitoring company, so there is no reason whatsoever they should be accessing tools (or Wikipedia, for that matter). MER-C 13:58, 21 April 2013 (UTC)

Template:Countyrow error

(Note:The below message was originally posted at Wikipedia talk:WikiProject United States, but the answer might be more likely found here at the Pump. — Maile (talk) 14:16, 21 April 2013 (UTC))

I'd like to draw attention to the bug in List of counties in Nevada for the Carson City entry. Carson City is not a part of any county, so the syntax given is different. However, the way the syntax is right now, "class=Nickname" appears inside the link target, causing the words "Carson City" to link to Carson Cityclass="Nickname", Nevada. The problem may be with Template:Countyrow or with the syntax for its usage on the page. Either way, I'd prefer if someone with a bit more wikicode knowledge would take a look at this; I'm not able to find the problem. Someone the Person (talk) 14:08, 21 April 2013 (UTC)

I fixed it by reverting these two edits. --Redrose64 (talk) 15:06, 21 April 2013 (UTC)

Thank you for taking care of this. — Maile (talk) 19:14, 21 April 2013 (UTC)

Deleted diffs and Fullurl

If we take e.g. [5] in basic, non-Fullurl notation, when I try to represent it in Fullurl as [6], clicking on that second link it seems to drop the &timestamp= parameter. Am I doing something wrong, or is it something to do with the Fullurl mechanism itself? It Is Me Here ^{t / c} 17:50, 21 April 2013 (UTC)

You don't need to separate all the query elements. It should be like this: [7] —TheDJ (talk • contribs) 17:58, 21 April 2013 (UTC)

I see. So, in general, how do you know when to change an & to a |, and when not to? It Is Me Here ^{t / c} 18:01, 21 April 2013 (UTC)

The fullurl syntax is at mw:Help:Magic words#URL data: {{fullurl:page name|query_string}}. Never split the query string. fullurl is a parser function and not a template. It doesn't have named parameters. target=%40field+%28video+game%29&timestamp=20120905222706 in {{fullurl:Special:Undelete|target=%40field+%28video+game%29&timestamp=20120905222706}} is one long unnamed parameter and not an assignment to a fullurl parameter called target. PrimeHunter (talk) 20:50, 21 April 2013 (UTC)

Articles load improperly on Kindle

Tracked in Phabricator
Task T49499

Recently, I've noticed that articles no longer load properly on the older "paperwhite" Kindle that I often use. Just as an article completes loading the page disappears and only the search box with a left-arrow icon remain on screen. If the arrow is clicked the article will then reappear. This happens on every article every time. Have there been some recent global change to the underlying article markup or style sheet? TenebrisCaelo (talk) 18:59, 21 April 2013 (UTC)

Yes there have been changes, thank you for reporting this. Can you get more specific version information on your Kindle ? That would be helpful for the devs. —TheDJ (talk • contribs) 08:03, 22 April 2013 (UTC)

Picked a random article, and Bass guitar looks good on both the Kindle 3 and Kindle Fire. GoingBatty (talk) 23:52, 23 April 2013 (UTC)

Twinkle question

I have rollbacker rights, but I did not ever download Twinkle. Due to a recent edit of mine, I need clarification. I'm being accused of abuse, I think. Please see Talk:Minnie_Fisher_Cunningham. First of all, I was unaware Rollbacker was operated by Twinkle. Secondly, is this true that it shouldn't be used to revert a good-faith edit? Good faith is assumed unless it's vandalism, but the assumption does not mean the reverted edit was correct. I did not accuse this editor of vandalism. If we can't use the Rollbacker rights to revert good-faith edits, then why isn't it limited to strictly vandalism? Please advise. — Maile (talk) 21:07, 21 April 2013 (UTC)

Technically, rollback (native, the button that says [rollback (X edits)] near it) should only be used for pure vandalism. However, WP:TW, which is a gadget that you don't even download and is enabled in your preferences under "gadgets", offers the vandalism rollback (for those without native rollback) and also has a "custom" rollback and an "AGF" rollback. That way, along with a message to the user, you can still easily undo non-constructive edits without calling them outright vandalism. You in fact do have Twinkle installed, and you didn't abuse it at all as far as I'm concerned. It's the other person's problem if they don't want to discuss with you. They did the right thing in piping the link to display differently. I'm not sure if there's an actual problem here now that it's all taken care of. Maybe everyone just needs some tea :) gwickwire^talk_editing 21:15, 21 April 2013 (UTC)

Thank you for the clarification. That particular editor has only been editing since March 10, 2013. But even us seasoned editors sometimes need clarification on how we handle edits. Much appreciated. — Maile (talk) 21:20, 21 April 2013 (UTC)

Title blacklist false positive

I'm trying to move Spring Break…Here to Party (with an ellipsis) to Spring Break...Here to Party (with three periods) per WP:ELLIPSIS, which discourages the use of the ellipsis character. But for some reason, the latter title is flagging the blacklist. However, I can create a page at Spring Break...Here to Party no problem. Any idea why this false positive is popping up? And can someone move the page for me? Ten Pound Hammer • ^{(What did I screw up now?)} 21:29, 21 April 2013 (UTC)

Y Moved. No idea why the title blacklist is catching it, though. —Theopolisme (talk) 22:02, 21 April 2013 (UTC)

Wait... how were you able to do it while TPH was not? It doesn't seem to me that reviewer, account creator, rollbacker, or course online volunteer would give a user extra ability to bypass the title blacklist. -- King of ♥ ♦ ♣ ♠ 22:13, 21 April 2013 (UTC)

Account creator has the ability to bypass the title blacklist, for technical reasons. With that said, could you actually remove the userright, since I'm not active with ACC anymore? —Theopolisme (talk) 22:17, 21 April 2013 (UTC)

Well the line that's catching it is .*\.\.\.H.* <moveonly> which was added by User:NawlinWiki in this edit. they're still active so you could ask them why it's there if your that bothered. Dpmuk (talk) 22:38, 21 April 2013 (UTC)

And right removed - somehow managed to hit save before putting in a reason so if that bothers you let me know and I'll add it and remove it again with a proper reason. Dpmuk (talk) 22:41, 21 April 2013 (UTC)

A "proper reason" would be great, if only to keep everything understandable. Thanks! —Theopolisme (talk) 01:09, 22 April 2013 (UTC)

 Done King of ♥ ♦ ♣ ♠ 05:41, 22 April 2013 (UTC)

HTML5 video notice displaying in Firefox

On the video at Flag of Austria, the notice "For a better video playback experience we recommend a [ html5 video browser]." is being displayed, and the playback button links to the video file. File:Flag-of-Austria-320x240.ogg is Theora, which has been fully supported in Firefox for many years (this is backed up by the compatibility table at HTML5 video#Browser support). I am using the April 13 nightly build of 64-bit Firefox 23.0, which displays the browser's inbuilt Theora player when the video file is opened.

Where is this notice coming from? I'm slightly concerned about the placeholder "[ html5 video browser]" bit (complete with space inside bracket), as well as the fact that it is triggering itself on a browser that supports Theora natively. I've disabled Greasemonkey and do not have AdBlock or NoScript installed, so I don't believe it's an add-on issue.  — TORTOISEWRATH 23:25, 21 April 2013 (UTC)

This message comes from mw:Extension:TimedMediaHandler, which is a MediaWiki extension. (In case you don´t kow what MediaWiki is, then it is a software that powers Wikipedia) The message is at MediaWiki:Mwe-embedplayer-for best experience.--Snaevar (talk) 15:12, 22 April 2013 (UTC)

Toolserver funkiness

Is Toolserver having fits? I had this same error some days ago, and then it went away before I had a chance to post over here. This only happens to me when I'm on Page History and click "External tools: Contributors". No problem with the other external tools there. But the error message it brings up is

"Database Error: User has exceeded the 'max_user_connections' resource (current value: 15) (sql-toolserver) on sql-toolserver/toolserver- failed to connect to WikiList database - failed to connect to WikiList database"

Doesn't matter what page I try that on. I started with Loyal Valley, Texas and got this, and then tried it on my own user page and got the same message. I get this on every page right now, if I click on "Contributors". Chances are, this will resolve itself eventually, but why is it happening? Could this be a glitch with Firefox 20.0.1? — Maile (talk) 23:27, 21 April 2013 (UTC)

Don't know what it would be (presumably some sort of issue), but it certainly looks like a server issue and not an issue with the Fx patch.  — TORTOISEWRATH 23:35, 21 April 2013 (UTC)

Yeah, and the issue cleared itself right now. Wonder what's going on at Toolserver. — Maile (talk) 23:39, 21 April 2013 (UTC)

What's going on at Toolserver is a lack of funds. It's hosted by WMDE who have previously been happy to pay for it, but they don't want to carry on doing that. Plenty on this in the archives for this page - mainly in the last nine months. --Redrose64 (talk) 09:50, 22 April 2013 (UTC)

The Toolserver is bound to disappear during 2013-2014. All tools will move to the Tool Labs which should be much more stable. See mw:Tool Labs/Roadmap en. Darkdadaah (talk) 12:27, 22 April 2013 (UTC)

It's been completely down for the last few hours.--Gilderien Chat|List of good deeds 21:52, 22 April 2013 (UTC)

Userspace "template" border color issue

I am trying to create a "template" in my userspace to use as an award and I want to make the border gold. As you can see here, it is not working. Could somebody please explain what the problem is? AutomaticStrikeout (T • C • Sign AAPT) 01:09, 22 April 2013 (UTC)

border: 3px #FFFDF5 uses a default of "none" for the border-style, since you've left it unspecified. Try border: 3px solid #FFFDF5 instead. Anomie⚔ 01:32, 22 April 2013 (UTC)

That actually didn't fix it, but I used border: 3px solid gold instead and that worked. AutomaticStrikeout (T • C • Sign AAPT) 01:39, 22 April 2013 (UTC)

Curious that it didn't work like that - the CSS 2.1 spec shows that colours may be specified in a number of ways, which include a six-figure hexadecimal RGB value, if that value is prefixed by the # sign, so #FFFDF5 should have worked. Anyway, in relation to that, #white is invalid - to specify the colour white, you have a number of options: these include white and #ffffff Others are available, such as #fff rgb(255,255,255) and rgb(100%,100%,100%). CSS 3.0 (which is not yet supported by all current browsers) also allows several other ways of specifying white, such as hsla(0,0,100%,1). --Redrose64 (talk) 09:47, 22 April 2013 (UTC)

Looking at the history, it did work. Except that AutomaticStrikeout was looking for something like #FFD700 (   ) rather than the very subtle #FFFDF5 (   ). Anomie⚔ 10:50, 22 April 2013 (UTC)

Bug in undeleting 2 pages with many edits

Tracked in Phabricator
Task T45911

• Yesterday I history-merged the pages RZA and GZA (not with each other!). In each, at the end I had to undelete a long list of edits, omitting a few of those edits because they are tramp redirect edits belonging to another editing thread. But whenever I tried that selective undelete, the system acted as if I had made a search among deleted pages, instead of undeleting. But an unselective undelete of all edits under that name, worked. This happened again just now. Anthony Appleyard (talk) 17:19, 21 April 2013 (UTC)
  • I've experienced this problem as well, but I thought it was just a quirk of my screen reader and/or browsers (it happens in Internet Explorer 9, and something similar happens in Firefox (I can't remember the exact details)). Graham87 10:06, 22 April 2013 (UTC)
    • Move from ANI. Graham87 10:09, 22 April 2013 (UTC)
      • The problem you are reporting sounds like a potential issue in the code of the MediaWiki software or the server configuration. If the problem is reproducible, it would be nice if somebody who has this issue could send the software bug to the 'Bugzilla' bug tracker by following the instructions How to report a bug. This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 14:31, 22 April 2013 (UTC)
        • Yeah, I should've thought to serch Bugzilla first ... I thought the "invert selection" feature was specific to the English Wikipedia, and the problem could have therefore been fixed here. Obviously not; it's already been reported as bug 43911. Graham87 10:59, 23 April 2013 (UTC)

CSS help

I need some help with Chrome and position: relative. See Template talk:Anchor#Positioning. --  Gadget850 (Ed) ^talk 12:10, 22 April 2013 (UTC)

Hotcats and infoboxes

Apologies if this has been queried before, I couldn't see it on a quick scan through archived discussions... I note that HotCat doesn't seem to work with my browser when there is more than one navigation box template at the bottom of an article (and sometimes not when there is just one). Is this a known bug? I realise my browser is not the newest (Safari 5.1.7) but I would expect it's new enough that others will be facing the same problem. Thanks in advance - Grutness...wha? 12:38, 22 April 2013 (UTC)

You may wish to post your issue on Wikipedia talk:HotCat. Good luck! GoingBatty (talk) 23:57, 23 April 2013 (UTC)

Done - thanks. Grutness...wha?

Wikidata phase 2 is now live

Heya folks :)

It took a while but phase 2 (infoboxes) of Wikidata is now live here. This enables you to include data from Wikidata in infoboxes for example. For more details about this please see this blog entry. A request for comments is currently ongoing about how to make use of phase 2 on this Wikipedia exactly. Please follow it.

At the same time we have enabled a new feature that lets you add another language link here without having to go to Wikidata if there is no other language listed on Wikidata yet.

Please let me know if you see any issues related to this deployment or have further questions. --Lydia Pintscher (WMDE) (talk) 19:23, 22 April 2013 (UTC)

Where is the new feature please?--ukexpat (talk) 16:41, 23 April 2013 (UTC)

This was partially broken until some hours back, but we fixed it now. You can find it on any page without langlinks on the lower left as "Add links" (eg. on Kebithigollewa Divisional Secretariat). Please notice that it's only available for logged-in users at the moment - Hoo man (talk) 21:46, 23 April 2013 (UTC)

OK so that works for ILLs, is there anything for infobox fields? Thanks.--ukexpat (talk) 00:46, 24 April 2013 (UTC)

Are you sure you want to do this, Dave?

I'm getting "the page is asking you if you want to leave" notices now (using Firefox 5.0) when clicking 'back', or on a link, from an active (i.e. typed-in) edit window. I don't remember this happening before, was something changed? - The Bushranger _{One ping only} 20:38, 22 April 2013 (UTC)

I'm pretty sure this is a feature of your browser and not Wikipedia. Also, if you type in "Daisy" it sings a creepy song. Zad68 20:42, 22 April 2013 (UTC)

It's full of stars! But it hasn't previously done this on Wikipedia, and I haven't changed anything...odd. - The Bushranger _{One ping only} 20:47, 22 April 2013 (UTC)

I found on IE 6.0.2900 SP3, IE 8.0.6001, Chrome 26.0.1410 and FireFox 19.0.2 they all do it, you get the "Are you sure?" when you try to back out of an edited window... and I think you're right it didn't used to do that, but I've seen it doing it for a while, for what feels like at least weeks or months. Not sure now. Zad68 21:08, 22 April 2013 (UTC)

It's definitely done this for at least the past 5 months, and if my memory isn't shot then longer. I remember because there's tons of times I have hit my trackpad outside the editing window, and accidentally hit backspace and I get the saving grace of a warning first... I'm not sure that it's a big deal, but there's probably a JS/gadget to remove it, or if not I'm sure it wouldn't be too hard to make. gwickwire^talk_editing 21:20, 22 April 2013 (UTC)

That's very odd, because I now recall for a fact it wasn't doing it for me yesterday - accidentally hitting "preferences" instead of another tab (just above that) yesterday had me have to scramble to hit 'stop', but today gave me the Hal 9000 act. - The Bushranger _{One ping only} 21:29, 22 April 2013 (UTC)

With Safari on the Mac, I've been getting the "are you sure" at least since June 2012. Seems to just be a browser thing, although perhaps mediawiki has some influence on it (??). —Theopolisme (talk) 21:32, 22 April 2013 (UTC)

Yeah, this has been happening to me lately as well. There's an associated user preference at Special:Preferences#mw-prefsection-editing. I think it may have somehow gotten reset with a recent MediaWiki deployment. --MZMcBride (talk) 21:32, 22 April 2013 (UTC)

The warning requires Javascript to be active, if that's of interest. Johnuniq (talk) 23:26, 22 April 2013 (UTC)

Thanks for finding that. - The Bushranger _{One ping only} 02:18, 23 April 2013 (UTC)

As far as I know, this is a feature that is part of the Vector skin and has been around for as long as Vector. I know it's been around since at least 2010 when I began editing anonymously. jcgoble3 (talk) 01:44, 23 April 2013 (UTC)

Therein lies the rub - I use MonoBook. - The Bushranger _{One ping only} 02:18, 23 April 2013 (UTC)

personally, i love this feature and would not dream to turn it off, but if it bothers you, you can, under "Preferences => Editing => Warn me when I leave an edit page with unsaved changes". as to what happened recently - we can all guess that someone ported this feature from "Vector" to "Core", though this is just speculation, of course. peace - קיפודנחש (aka kipod) (talk) 05:36, 23 April 2013 (UTC)

It was introduced (in Spring 2010) with the Vector skin, where it has always been "opt-out" (as Kipod says, it's at Preferences → Editing → Warn me when I leave an edit page with unsaved changes); it became available in the Monobook skin at the same time, but was "opt-in". --Redrose64 (talk) 08:55, 23 April 2013 (UTC)

I'm suddenly getting it in Monobook on Firefox 18.0.2, which I have been on for some time. I have definitely NOT opted in, and I definitely do not want it. I associate this sort of pop-up with rather more sleazy sites where they want you to stay so they can advertise at you, not with reputable sites where the user is assumed to have at least half a brain. I thank you for your advice, and have opted out again - but would like to deliver a very wet trout to whoever changed the setting. Peridon (talk) 11:01, 23 April 2013 (UTC)

If you used to edit Wikipedia with scripting disabled, you would not have seen the warning. If you have recently enabled scripting, you will now see the warning (if the preference "Warn me when I leave an edit page with unsaved changes" is set, which presumably it is, as you are seeing the warning). Johnuniq (talk) 11:48, 23 April 2013 (UTC)

No, I haven't changed anything with regard to scripting. It was on before. Peridon (talk) 14:06, 23 April 2013 (UTC)

The feature was never "opt-in" for Monobook. The preference was there and checked by default, it just had no effect in skins other than Vector. Gerrit change 56881 moved the feature from the Vector extension to core, and at the same time made effective for all skins rather than just Vector; this change was deployed here as part of 1.22wmf2. Other Vector features, such as the collapsing of the "templates used in this page" and hidden categories lists at the bottom of the edit form, will likely get the same treatment at some point. Anomie⚔ 12:36, 23 April 2013 (UTC)

Why are things that Vector has being put into skins like Monobook? Monobook users use it because they don't like Vector and the way it works. I at least object to having changes like this brought in sneakily to get Monobook to be like Vector. If I wanted Vector. I'd use Vector. I've no objection to Nanny's toys being available to people - just don't force them on the rest of us, those of us capable of deciding to leave a page all by ourselves. Peridon (talk) 14:06, 23 April 2013 (UTC)

forgive my french, but this is just silly. this feature is something that users come to expect from every editor: if i try to close my editor, and it does not matter if it's word, notepad++, kate, or my software development IDE, they will all try to warn me if i have unsaved changes that i'm about to lose by closing it.

this is such an elementary feature that i can't see why someone would whine about it when WP adds it to the functionality. the fact that you can opt out of it makes this whining even more bizarre. the fact that this feature did not work until now in monobook can only be classified as a bug, and whining about mw fixing a bug is not nice. peace - קיפודנחש (aka kipod) (talk) 15:48, 23 April 2013 (UTC)

That's not exactly the same: if you leave a WP edit page without saving the changes you can come back to that page and recover your unsaved changes through the browser history. That doesn't work for typical standalone editors. It even works if you close the browser tab with the edit page, but in this case you don't get a confirmation dialog (should we call this a leftover bug?). Anyway, I don't like it, but since it's opt-out I don't see a reason to call for any changes. (Firefox 20.0 on Ubuntu 12.4, Monobook) — HHHIPPO 19:06, 23 April 2013 (UTC)

if you use either chrome or ff on windoze, linux or android, you definitely get a warning when trying to close the tab (or, for that matter, close the browser). i will be very surprised to learn that it behaves differently for mac, opera or IE. as to the ability of your browser to recover lost work: this is very flimsy, and depends on browser, browser settings, and browsing mode. for instance, if you edit using "private browsing" (or "incognito browsing" in chrome lingo) this functionality is not there. קיפודנחש (aka kipod) (talk) 19:49, 23 April 2013 (UTC)

Sure, the browser history method is not safe enough to justify removing the feature or making it opt-in, it's just good enough for me to opt out. I tried it again with closing tabs, works indeed. What tricked me was that you don't get additional confirmation dialogs if you leave and return several times without making changes in the editor. I guess that's fine, so no leftover bug. — HHHIPPO 20:34, 23 April 2013 (UTC)

I've been getting this on Modern skin. I didn't opt-in to anything, but sure would like to know how to opt-out. It started a week or so ago on the tabs. Firefox 20.0.1. OK, it was just letting me know I was trying to close out of all the tabs at once. Today, it's been happening a great deal, just switching pages. Annoying to have it happen every time I want to leave a Wikipedia page. Please tell me how to opt-out on Modern for good. — Maile (talk) 15:01, 24 April 2013 (UTC) OK, i just went into "Preferences => Editing =>and unchecked "Warn me when I leave an edit page with unsaved changes". That that still doesn't explain why it started happening out of the blue on my browser. I didn't check the "warn me" opt-in recently (altho, admittedly, could have long ago) nor does it explain why it warns me about the tabs or, as of today, warns me when I just want to change pages without being in the edit window. What has Wikimedia done to set this in motion? — Maile (talk) 15:10, 24 April 2013 (UTC)

• Adding to those reporting this as an annoying change. Some time ago, the behavior of preview was changed such that when one backed up out of preview to make further changes, the software did not remove the previously made changes, as it had sometimes often did; from my browser history I saw that it was substituting a moving forward to a new version as if I had made the new changes in the edit window below the preview before hitting preview again. That was very welcome and secured previously made changes against absent-mindedness. This gives at least the appearance of having negated that useful change. If it has, I'd like it undone, please. A scary message that has to be clicked on is in no way a good substitute for not undoing previously performed actions when someone previews - which is something we want editors to do. Yngvadottir (talk) 18:13, 24 April 2013 (UTC)

• Preferences → Editing → Warn me when I leave an edit page with unsaved changes --  Gadget850 ^talk 18:22, 24 April 2013 (UTC)

Only 30 days per login AGAIN?

Can someone tell me why the maximum amount of time a user can remain logged in was reduced back to 30 days from the previous 180 days? Personally, I'd like to never be logged out (as it changes my skin and adds an extra two pages before I can edit), but 180 days was a nice compromise. Did some abuse happen that caused the duration to be reduced again?

I know it is technically possible, as I can still use a cookie editor to keep the login cookie from expiring. However, I had stopped having to do this when I was able to stay logged in for 180 days. I would like the cookie to be allowed to last at least that long. Heck, even 90 days would be superior to the current situation. Needing to log in once a month is far too frequent.

I note that Google also uses a 180 day limit, and the problems that can happen if someone steals your Google account information is much more extensive than happens if someone grabs your Wikipedia account. (Not that either has a remote chance of happening in my case.)

Thanks for looking into this. — trlkly 20:54, 22 April 2013 (UTC)

Hi. Yeah, I noticed this change as well and your post made me curious enough to investigate. The number of days is controlled by a global configuration variable called $wgCookieExpiration. The default value for this variable is 180 * 86400 in MediaWiki core. Wikimedia wikis are (now) overriding this value (cf. <https://noc.wikimedia.org/conf/CommonSettings.php.txt>: "$wgCookieExpiration = 30 * 86400;"). I pinpointed the change to gerrit:54505. I left a comment on that changeset asking Sam why this change was made, as there's no referenced associated bug report or comment explaining the change. --MZMcBride (talk) 21:56, 22 April 2013 (UTC)

Hmmm. I'm surprised it's 30 days, which is much longer than every other site I've ever logged into. Possibly a standard security measure? Actually, logic would suggest that the length of login should be linked to level of permission; so, "regular" editor xxx days, admin 24 hours, checkuser/oversighter/steward even shorter. Risker (talk) 22:11, 22 April 2013 (UTC)

It's set this way due to the privacy policy specifically saying that cookies will be "saved for up to 30 days". The previous period of login persistence of 180 days was unintentionally out of step with the policy. I know the legal team is slowly but surely working toward a draft of a new revision to the policy that they will unveil for a lengthy community discussion period, so keep an eye out for that and advocate for a change if you want something longer than 30 days. Steven Walling (WMF) • talk 22:30, 22 April 2013 (UTC)

Looking into the history a bit, it appears the default setting was 30 days when the current Privacy Policy was adopted in 2008. In August 2011, the default setting for Mediawiki was increased to 180 days (while citing an argument that 30 days was unusually short for comparable sites, though I haven't seen the original discussion). In December 2012, apparently someone noticed that the Privacy Policy and our cookie setting had become out of step, and since changing a legal document like the Privacy Policy is a pain in the ass, the solution now enacted was to restore the 30 days expiration for all Wikimedia sites. Dragons flight (talk) 22:50, 22 April 2013 (UTC)

Yes, that's all correct. We'll take this issue into account in the pending privacy policy revisions, but right now we have to deal with the limitation stated in the current policy -- the language unfortunately doesn't give us much flexibility here. :( --Eloquence* 00:20, 23 April 2013 (UTC)

I'm not sure where "December 2012" came from. Isn't gerrit:54505 the relevant change (from March 2013)? --MZMcBride (talk) 02:35, 23 April 2013 (UTC)

The discrepancy was mentioned on wikitech-l in December, including a comment that it was referred to legal. I don't know why it wasn't resolved till now. Dragons flight (talk) 02:59, 23 April 2013 (UTC)

Ah, I see now. Thanks. Relevant posts: [8] [9]. --MZMcBride (talk) 03:31, 23 April 2013 (UTC)

Thanks for the information. I hope the new privacy policy takes into account that people sometimes voluntarily give up a bit of privacy for convenience. — trlkly 12:47, 24 April 2013 (UTC)

CAPTCHA

I just added a {{reflist}} to an article and had to enter a CAPTCHA. I did not add any EL to the article, but there was an EL in one of the references that appeared due to the {{reflist}}. I don't think that it is necessary to enter a CAPTCHA unless I also add an EL. If it is not a major expense, can this be fixed? Rgrds. --64.85.215.205 (talk) 21:25, 22 April 2013 (UTC)

The external link detector just looks at the rendered version of a page. This avoids people getting around being detected as adding a link if the link is embedded in a template, or partially embedded in a template, or broken up with <includeonly>, or whatever. But that also means you'll be seen as adding a link if you add a {{reflist}}, or happen to be the first to edit a page in the new year when some template generates links with {{CURRENTYEAR}}, or certain other edge cases like that. Anomie⚔ 01:22, 23 April 2013 (UTC)

A "refreshing" change to the CAPTCHA

How it looks on the edit form

How it looks like a MediaWiki login form (only generated by multiple failed password attempts)

Hi all,

Forgive my punning. This an announcement about a new feature associated with the CAPTCHA, namely a small link to refresh the CAPTCHA image without having to fully refresh the page. It looks like the screenshots to the right, and will appear everywhere that the CAPTCHA happens: account creation, the login form (if you fail too many times), and on the edit form given certain cases (like submitting an external link as an IP).

We anticipate that we'll deploy this update Thursday the 25th, barring any last minute technical issues. This is a global change affecting all wikis, but I wanted to drop a special note here because as far as I know, English Wikipedia has the highest rate of account creation requests, of which no small amount are due to an unreadable CAPTCHA. I am sincerely hoping that giving users to cycle through images at a reasonable rate without needing to submit their entire signup form again and again will reduce frustration, and perhaps even the queue for account creators. You can see even from the preceding VPT thread that people find our CAPTCHA annoying...

Many thanks, Steven Walling (WMF) • talk 21:31, 22 April 2013 (UTC)

Nice to finally see this. I'm wondering about the usability aspect of it however. 'Refresh' is rather vague (refresh what?). This is made worse because the element you are refreshing is actually to the left and above the refresh control, which is positioned in line with the inputbox, giving the user the impression it is part of the input box context rather than the 'captcha image' context. something to consider ? —TheDJ (talk • contribs) 21:40, 22 April 2013 (UTC)

Refresh, plus the icon, is fairly universally understood term. I agree the placement of the button isn't perfect, but it's very close, and the reason it's not closer to the image is because of the rather stupid way that FancyCaptcha spits out HTML for the whole thing. The number one place the CAPTCHA is seen is during account creation (so far as I can tell). In our upcoming redesign of that (mockup), we've improved the placement using borders and background color to more clearly associate the refresh with the CAPTCHA. Steven Walling (WMF) • talk 21:47, 22 April 2013 (UTC)

If the mockup is where we are going, then I'm good ! —TheDJ (talk • contribs) 07:52, 23 April 2013 (UTC)

Will there be some reasonable limit to the number of times the "refresh" link can be used, to prevent this from being a vector for brute-forcing (ie for a bot to keep on "refreshing" the CAPTCHA over and over until it finds one it can OCR, thus escaping the usual login attempt throttling)? -- The Anome (talk) 08:02, 23 April 2013 (UTC)

A better question would be: is there any reason to believe these CAPTCHAs are effective at preventing spam? Unlike reCAPTCHA and other implementations, the CAPTCHA used on Wikimedia wikis involves concatenating two common English words using a small, publicly accessible dictionary. The bots are undoubtedly trained to submit a best guess. If the answer is wrong, the CAPTCHA is automatically refreshed post-submit. This presumes that humans aren't being employed to solve the CAPTCHA. If that's the case, it becomes even more useless (arguably actively harmful if it's then only preventing the blind and having no impact on spammers). --MZMcBride (talk) 15:35, 23 April 2013 (UTC)

Anome: we got a review pre-merge of this change from Chris Steipp, the security engineer at WMF, and we agreed with that the throttling should be added outside/regardless of the refresh action, so it has the same effect on manual page refresh. As MZ points out, we have good reasons to suspect our CAPTCHAs are already a pretty weak first line of defense that cause a lot of people grief, and in fact we should probably test our assumptions in this matter at some point. But regardless of the current state of affairs regarding how effective the CAPTCHA is, this enhancement is for humans, many of whom find our CAPTCHAs incredibly frustrating. Steven Walling (WMF) • talk 16:51, 23 April 2013 (UTC)

 Done This is deployed and live now. All seems kosher, but speak up if you catch any errors and we'll file the necessary bugs. Steven Walling (WMF) • talk 22:40, 25 April 2013 (UTC)

CS errors

I have an impression that citation templates have been screwed up recently. For example older articles, particulalrly those without Harvard refs, like Liverpool F.C. now have citation style errors like Missing or empty |title= (while Liverpool F.C. for example does mention the related books, but in a separate ref section). Is there a way to fix it or all such refs should be reformatted? Brandmeister^talk 08:02, 23 April 2013 (UTC)

The new Citation templates have more advanced validation, and this has now been enabled for some of it's elements. This page is using shortened footnotes for some of the references, but without actually using the appropriate templates {{sfn}} for that style. If you follow the help of shortened footnotes, the errors will disappear. —TheDJ (talk • contribs) 08:13, 23 April 2013 (UTC)

PS, that was even explained in the 'help' link that follows the error. People really did put a lot of time in that help system, I think it will be a great new asset for our editors. —TheDJ (talk • contribs) 08:16, 23 April 2013 (UTC)

Note that {{sfn}} is not necessary for shortened footnotes, and gains you little over formatting them manually. And makes it less clear that there's a reference there, since the <ref> tags are hidden. Anomie⚔ 12:42, 23 April 2013 (UTC)

Consider a ref that is presently formatted as <ref>{{cite book |last=Graham |page=14 |year=1985 }}</ref> - that is not how {{cite book}} was intended to be used. Instead this can be rewritten either as <ref>{{harvnb|Graham|1985|p=14}}</ref> or as {{sfn|Graham|1985|p=14}} --Redrose64 (talk) 10:17, 23 April 2013 (UTC)

<- just manually types it in when he uses shortened footnotes, per Anomie. --Izno (talk) 15:46, 23 April 2013 (UTC)

Shortened footnotes explains the various methods you can use, from manual to templates. --  Gadget850 ^talk 08:21, 24 April 2013 (UTC)

I think the templates include some redundant, moot parameters like penciller (in the refs for Terminator (franchise)), etc. Brandmeister^talk 22:06, 24 April 2013 (UTC)

Score !!

Tracked in Phabricator
Task T2189

After many years, one of the most voted and oldest feature requests has been solved. As of today, Wikipedia finally has a renderer for music notation. See Mark's sandbox for an example. Congrats to the original filer xmlizer ! And a thank you to all who helped write the various generations of the extension and those that reviewed the code. —TheDJ (talk • contribs) 08:35, 23 April 2013 (UTC)

More at Help:Wiki markup#Musical notation. --Redrose64 (talk) 10:18, 23 April 2013 (UTC)

There is also a Wikibook in French which could be translated and added to English Wikibooks: b:fr:Introduction à LilyPond. Helder 13:13, 24 April 2013 (UTC)

Is this working? I tried adding the following code to Première rhapsodie:

<score raw=1>
\version "2.11.63"

\score {
  <<
    \new Staff="clar" \relative c'' {
      \clef treble
      \numericTimeSignature
      \time 4/4
      \key aes \major
      
      \mark \markup {\bold \small "Reveusement lent"} 
      R1 | r4 g\p_\markup {\italic \small "doux et expressif"}( bes c)
    }
    
    \new PianoStaff {
      <<
        \new Staff="one" \relative c'' {
          \clef treble
          \key ges \major 
          \numericTimeSignature
          \time 4/4
          
          r4\pp
          << { f2( f'4~) | f1 } \\
             { f,2.~ | f1 } \\
             { s2. | \times 2/3 { e'8\>( ees c~) } c2.\! } >>
        }
        
        \new Staff="two" \relative c' {
          \clef treble
          \key ges \major
          \numericTimeSignature
          \time 4/4
          
          << { f1--~ | f1 } \\
             { s1 | \times 2/3 { e8\>( ees c~) } c2.\! } >>
        }
      >>
    }
  >>
}
</score>

but it failed with the error

Processing `/tmp/MWLP.926c7a5f74a89391d70986be99418a50/file.ly'
Parsing...
Interpreting music... 
Preprocessing graphical objects...
Finding the ideal number of pages...
Fitting music on 1 page...
Drawing systems...
Layout output to `file.ps'...
Converting to PNG...GS exited with status: 9ERROR: In procedure delete-file:
ERROR: No such file or directory

Or is raw=1 not supported here? --SarekOfVulcan (talk) 16:16, 24 April 2013 (UTC)

raw is supported.—Emil J. 16:47, 24 April 2013 (UTC)

First letter capitalization in article titles

According to Wikipedia:Naming conventions (technical restrictions)#Lower case first letter: "The MediaWiki software is configured so that a page title (as stored in the database) cannot begin with a lower-case letter." My question is simple ... Why?... Why is the software configured this way? Blueboar (talk) 12:21, 23 April 2013 (UTC)

As a guess I would say to prevent typos of lower case from showing up. I will phone Mr. Wales and see if there is a hidden agenda on it.--Canoe1967 (talk) 12:25, 23 April 2013 (UTC)

Well... Typos can be dealt with by simply moving the page to a corrected title. But in a few cases (the two most prominent being eBay and iPod) a lower case first letter isn't a typo. (and yes, I know that we can deal with such cases by adding the {{lowercase}} template - which makes the title display properly).

I know that having a lowercase first letter does not interfere with linking to or searching for articles... so I assume it must interfere with something else in the way the MediaWiki software works. Is my assumption correct? If so, what is it?... If not, is it be possible to change the software to allow lowercase first letters (where appropriate)? (note... I am not arguing that we should do this... I am asking if it is technically possible to do it). Blueboar (talk) 12:55, 23 April 2013 (UTC)

A lowercase first letter does not interfere with linking with the current configuration where lower case is automatically changed to upper case. Wiktionary allows both upper and lower case first letter (with lower being far more frequent). There you have to use the right case in wikilinks. For example, [[Dog]] makes a red link in Wiktionary while [[dog]] is blue. It would be very annoying and create loads of errors if Wikipedia had to pipe words like [[Dog|dog]]. The url http://en.wiktionary.org/wiki/Dog does redirect to http://en.wiktionary.org/wiki/dog with a delay. I don't know whether it's possible to configure MediaWiki so [[dog]] automatically goes to Dog if "Dog" exists and "dog" doesn't exist, but allowing that would create inconsistencies. Even if this configuration is possible, I wouldn't support it . PrimeHunter (talk) 13:40, 23 April 2013 (UTC)

• Because 99.9% of "titles" of articles should be capitalized on the first letter, and thus removes the erroneous creation of a) wrongly-titled articles and/or b) duplicate titles? (✉→BWilkins←✎) 13:10, 23 April 2013 (UTC)

Page titles are configured to start with an uppercase letter in $wgCapitalLinks. Turning that option off would make page titles case-insensitive and it would also break case-sensitive links.--Snaevar (talk) 13:59, 23 April 2013 (UTC)

Ah... now we are getting somewhere... let me see if I understand. The only way to allow an initial lower case letter would be to turn off $wgCapitalLinks ... but that would mean making titles and links completely case-insensitive. While we would gain the ability to format eBay directly (using a lower case "e")... we would lose the ability to use capitalization as a disambiguation (the software would lose the ability to distinguish between Red Meat and Red meat... the software would treat both as "red meat"). Is this correct? Blueboar (talk) 15:15, 23 April 2013 (UTC)

No, it’s the other way round. It would make titles and links completely case-sensitive, so that we would have to pipe all links needing a different capitalization than in the page title (e.g., at the beginnings of sentences).—Emil J. 15:24, 23 April 2013 (UTC)

OK... I am confused again... The software currently distinguishes between Red meat and Red Meat... but not between EBay and eBay. So what is going on? Blueboar (talk) 15:28, 23 April 2013 (UTC)

Right; the case of the first letter in a title doesn't matter, but the case of any letter after that does matter. What we would "gain" by changing the flag is the ability to distinguish between eBay and EBay. Right now, because of that convention, those two article titles are really one and the same; they always go to the same page without a need for a redirect or anything, and they can't be separated. (On the eBay page, it would appear that the page is called "eBay" without the caps, but this is just a cosmetic change; internally, the software still refers to it as EBay.) If we turn that flag off, then "eBay" and "EBay" become separate pages. After that first letter, case always matters; EBay and Ebay will always be separate pages, whether that flag is enabled or not. We have Ebay currently redirecting to EBay, but that could be changed by simply editing the Ebay page. Right now, that flag is making the software treat the first letter differently from the rest of the letters; turning that flag off would make the software treat the first letter the same as the rest of the letters.

The question is: do we actually want the ability to distinguish the pages eBay and EBay? All it would mean, for the vast majority of articles, is that we would either have to create a redirect for every page, pointing from the uncapitalized title to the capitalized title or vice versa, or live with annoying piped links like BWilkins's example of [[Dog|dog]] (or [[dog|Dog]]). Plus, we already have a system to disambiguate those kinds of things. So, it's probably much more trouble than it's worth. Does that make sense? Writ Keeper ⚇♔ 15:32, 23 April 2013 (UTC)

No... my question is not "do we want to"... that's a style issue and not a technical issue. My question is: Is there something in the software that prevents us from doing so (whether we want to do so or not)? I am trying to understand the technical reasons why the software can distinguish between Red Meat and Red meat, but can not distinguish between iPad and IPad? Blueboar (talk) 15:43, 23 April 2013 (UTC)

Well then, the answer to your question is no. There is no strictly technical reason that the software cannot distinguish between iPad and IPad in the same way that it does Red Meat and Red meat. But, for stylistic reasons, we've told the software to ignore the difference between iPad and IPad, and so it does. We've told it this through the $wgCapitalLinks flag. So, because we've told it to do this, the software will now always act as though there is no difference between things like iPad and IPad, even though it would otherwise be possible for it to tell the difference (as wiktionary shows). Writ Keeper ⚇♔ 15:50, 23 April 2013 (UTC)

The parameter noted above by Snaevar prevents us from doing so. It makes only the first letter of a title case insensitive, as explained above. To change it would make the first letter case sensitive, but that would break hundreds upon hundreds of links probably. --Izno (talk) 15:51, 23 April 2013 (UTC)

The software itself doesn't distinguish between Red Meat and Red meat; what distinguishes them is that there are two different articles with those titles. It's the same reason that REd meat, ReD meat, Red mEat, Red meAt, and Red meaT are all redlinks. EVula // talk // ☯ // 16:27, 23 April 2013 (UTC)

I think I got it now... thanks. Blueboar (talk) 17:44, 23 April 2013 (UTC)

it's worth noting that the behavior is not always 100% clear or 100% obvious, and not always all part of the system work in total harmony. for instance, this "automatic first letter capitalization" does not work the way you may think it works for subpages: for instance, Wikipedia:Sandbox and Wikipedia:sandbox are the same page (or rather, the second is an "alias" for the first), but Special:MyPage/sandbox and Special:MyPage/Sandbox are not. This can create interesting hitches with some things: for instance, the "template sandbox" extension allows you to substitute sub-pages under the "sandbox prefix" for pages in other namespaces (e.g., if your "sandbox prefix" is "Special:MyPage/sandbox", the extension will substitute "Special:MyPage/sandbox/Module:Blah" for "Module:Blah"). however, even though first-letter-auto-capitalization is performed for "Module:Blah" on both page-name side and invocatin side (i.e., you can invoke it as {{#invoke:blah _or_ as {{#invoke:Blah, and both will work), same auto-capitalization is *not* performed on the subpages: if the subpage you create is "Special:MyPage/sandbox:Module:blah", it will not be substituted, because the system will auto-capitalize the module name on the invocation side, but will not auto-capitalize the subpage name itself (same failure mode for "Special:MyPage/sandbox:module:Blah"). hope this awkwardly-phrased caveat was not too obscure to actually understand what i meant... peace - קיפודנחש (aka kipod) (talk) 15:28, 24 April 2013 (UTC)

Correction: the "automatic first letter capitalization" does not worth the way you may think it works for subpages. :P The subpage name itself isn't the first letter of the article, so it of course (to me, at least) it would matter how it is capitalized. It's the same for websites: apple.com/iphone is the correct URL, but Apple.com/iphone works (because the top-level domain capitalization is irrelevant; aPPle.com/iphone works too), but apple.com/iPhone does not. Replace "top level domain" with "article title" and voila, it behaves exactly the same way. EVula // talk // ☯ // 00:07, 25 April 2013 (UTC)

Add link

I moved this plan from the "Too difficult to create username" section above.

• I took a screen shot of a failed account: File:Account rejected screen 2013.jpg. Can we add the link to wikipedia:request an account inside the pink box? An IP editor claims to have had 5 names rejected and thinks we may lose editors. I don't think they knew that wikipedia:request an account existed. Can we claim 'this method usually takes just a few minutes' and a link to a 'Why similar names are rejected' page? Also what is the 'Reason' box for? Does that need to be clarified?--Canoe1967 (talk) 17:31, 23 April 2013 (UTC)

On the last question, the reason field is only shown to users who are creating an account through that form while logged into another account. The purpose is so that users can state why they are creating multiple accounts (i.e. what part of WP:SOCK#LEGIT does the new account fall under?). Users who are logged out or creating an account for the first time do not see the reason field. jcgoble3 (talk) 19:45, 23 April 2013 (UTC)

If you mean the time it takes to get an account created manually, "just a few minutes" isn't accurate, though it's better than it was. Probably depends on the time of day and other unpredictable factors. The current oldest non-handled request is about 13-hours old. —[AlanM1(talk)]— 20:33, 24 April 2013 (UTC)

I uploaded a new version that shows a screen while I was logged out (cache is slow and may show older version). Could the wording be changed in the pink box and a link to wikipedia:request an account in the pink box as well. It seems they need to fill all the fields out again as well as those captchas that many find difficult. We could also add hours/less than a day type statement. "Acoount creation usually averages less than 12 hours."--Canoe1967 (talk) 23:52, 24 April 2013 (UTC)

Mobile CentralNotice banner going out today to en.m.wp

Reminder that the mobile and fundraising teams are working together on a banner test this week on the English Wikipedia mobile site (en.m.wikipedia.org). The banner will only appear for mobile users who have opted into beta mode, are logged in, and are on an Android phone. In addition to testing out how CentralNotice code runs on mobile, we're using this as an opportunity to market the new Wikimedia Commons app for Android to logged in mobile Android users. You can see the banner here.

If you have any problems or you see the banner show up on the desktop site (this should not happen) please report them to meta:Help_talk:CentralNotice/Mobile. Thanks! Maryana (WMF) (talk) 18:49, 23 April 2013 (UTC)

Twinkle not installed?

I can't seem to be able to use Twinkle on my Wikipedia account. I checked the box that says "Twinkle" in My Prefrences under Gadgets but there still is no TW at the top of articles. The page User:Missionedit/twinkleoptions.js does not exist and WP:Twinkle/Preferences says that Twinkle must be installed in order for me to change my Twinkle prefrences. I tryed purging my catche with no effect. I am using Internet Explorer version 8. Can you help? ~ Anastasia (talk) 19:57, 23 April 2013 (UTC)

And there's your problem, Twinkle doesn't work with IE8 or earlier. If you want to use it with IE you need to upgrade to IE9 or 10 or switch to another browser. NtheP (talk) 20:04, 23 April 2013 (UTC)

Oh, well there you have it. Thanks so much! ~ Anastasia (talk) 00:23, 24 April 2013 (UTC)

Can the preferences page be made sensitive to this to gray out and add an explanatory comment to the enabling checkbox when the user isn't running a compatible browser? —[AlanM1(talk)]— 20:26, 24 April 2013 (UTC)

Mobile CentralNotice Banner (on en.m.wp.o) -- Now Active

As stated above in #Mobile_CentralNotice_Banner_.28on_en.m.wp.o.29 -- banners are now live on the mobile site. If you have any problems please report them to meta:Help_talk:CentralNotice/Mobile. Mwalker (WMF) (talk) 23:40, 23 April 2013 (UTC)

Actually I lied -- we ran into some technical issues so have disabled the code again. Mwalker (WMF) (talk) 23:56, 23 April 2013 (UTC)

Not staying logged-in again

I reported at Wikipedia:Village pump (technical)/Archive 110 § Change in logged-in status that a change appeared to have occurred, allowing me to remain logged in for weeks at a time with a browser session that I didn't close (only hibernated when not in use). As of a few of days ago, it has reverted to its old behavior, requiring me to log in again every day or so. I did perform the latest Win7 and various add-on updates. I updated to FFox 20, though, before the behavior change. Has there been a server change to explain this? —[AlanM1(talk)]— 02:05, 24 April 2013 (UTC)

See above. --Redrose64 (talk) 07:03, 24 April 2013 (UTC)

I'm not sure that the "See above" thread is relevant, since AlanM1 is having to log in again "every day or so". -- John of Reading (talk) 08:02, 24 April 2013 (UTC)

Right. Can someone describe how the "stay-logged-in" process works? Which cookie is it, and how is it used? —[AlanM1(talk)]— 20:17, 24 April 2013 (UTC)

Deleted special page and skins

Hello,

I have noticed over the past few days that this page does not exist. I managed to view it recently, and it can still be viewed on some smaller wikipedias.

I also have noticed that a few skins, such as nostalgia and amethyst, have been deleted too.

Why were they deleted?

Thank you! --TheMillionRabbit 02:54, 24 April 2013 (UTC)

I believe I read that the Active Users page was too demanding on server resources. Those skins were eliminated so that fewer skins have to be supported when it comes to new features. Chris857 (talk) 03:48, 24 April 2013 (UTC)

Re Special:ActiveUsers - I can't find the discussion, but I definitely saw one, and it's basically what Chris857 said. Re skins - see also Wikipedia:Village pump (technical)/Archive 110#Classic skin and CSS and MediaWiki talk:Common.css#Obsolete skin files; I think there were others. --Redrose64 (talk) 07:09, 24 April 2013 (UTC)

For Special:ActiveUsers see also bugzilla:41078. --AKlapper (WMF) (talk) 10:11, 24 April 2013 (UTC)

Mobile wikipedia: "read in other languages" links disappeared?

Resolved

Tracked in Phabricator
Task T49597

Is it intentional? --fireattack (talk) 07:02, 24 April 2013 (UTC)

I doubt it, I reported it in bugzilla. —TheDJ (talk • contribs) 07:33, 24 April 2013 (UTC)

Fixed and deployed. Max Semenik (talk) 15:12, 24 April 2013 (UTC)

Hanging userpages

Tracked in Phabricator
Task T49457

I'm getting an odd effect when trying to access pages in userspace (doesn't affect any other namespace). The pages load, then appear to attempt to refresh, but do so unsuccessfully, leaving the browser hanging. Stoping the page load and hitting the Back button takes me to the correct page. I'm running Firefox 5.0.1. Anyone else spotted this, or know of a solution to it? Yunshui 雲‍水 08:01, 24 April 2013 (UTC)

Seems like the same issue as on Commons. It's reported, will take some time before it's actionable I think. —TheDJ (talk • contribs) 08:26, 24 April 2013 (UTC)

One fix on commons was to disable the wikilove option in prefs and another was right-click and open new window (not tab).--Canoe1967 (talk) 08:29, 24 April 2013 (UTC)

Wikimedia developers are working on this and trying to find the culprit, but haven't succeeded so far. See the bug report that was linked by TheDJ. --AKlapper (WMF) (talk) 10:12, 24 April 2013 (UTC)

While logged in with Firefox 20.0.1 it is not possible for me to open User:TheDJ and User:AKlapper (WMF) in new tabs on English Wikipedia. I can open User:Yunshui and User:Canoe1967 in new tabs. These are users commenting in this thread. I can open them all in the same tab without problems. (Note for techs working on this: I am using https and not http).

The Commons discussion is here: Commons:Village pump#April 21.

The problem is solved when i uncheck "Enable showing appreciation for other users with the WikiLove tab" in my preferences here: Special:Preferences#mw-prefsection-misc. --Timeshifter (talk) 13:12, 24 April 2013 (UTC)

• I believe this is the hanging resolvable by hitting the back button on my browser that I came here to report. I haven't noticed its being restricted to userspace pages, though. (Good that it's been reported, since I found it impossible to figure out what versions of my OS and browser I'm using - Win7 and Firefox something something). Yngvadottir (talk) 18:06, 24 April 2013 (UTC)

Cannot edit user talk pages - but fine elsewhere

At first I thought this was a browser issue, but seeing as my issue is limited to user talk pages only, it may not be...basically, I cannot edit user talk pages. I cannot even access them. As soon as I click on them I get half-a-second of normal display, before the screen goes blank. Mainspace? Fine. Other talk pages? Fine. User talk pages? No chance. Very odd. Help appreciated. GiantSnowman 13:08, 24 April 2013 (UTC)

See #Hanging userpages, above. If you have Wikilove enabled, try turning that off. -- John of Reading (talk) 13:21, 24 April 2013 (UTC)

Perfect, thanks. GiantSnowman 13:47, 24 April 2013 (UTC)

Unable to view user talk pages in firefox (problem with bits.wikimedia.org?)

Today I am unable to view most pages in the user talk namespace (other than my own talk page) - I get a brief flash of then page and then just a blank page while it apparently tries to "Read bits.wikimedia.org" according to the status bar, but the page never completes loading.

This is only happening in Firefox (20.0 on Xubuntu linux) and works fine in Konqueror and Links (the only other browsers I have access to) and is a new problem since last night when it was working fine (e.g. I was able to leave a message at User talk:CACook7).

I do run the NoScript extension but wikipedia.org and wikimedia.org are whitelisted, the script shows no blocked elements and temporarily disabling it does not make a difference. I am able to load the bits.wikimedia.org page (which redirects to www.wikimedia.org) without any issues. Thryduulf (talk) 15:16, 24 April 2013 (UTC)

Look up two or three sections for other reports of this. If you have Wikilove enabled, try disabling it. -- John of Reading (talk) 15:26, 24 April 2013 (UTC)

Thanks, disabling wikilove appears to have solved the problem. Thryduulf (talk) 15:30, 24 April 2013 (UTC)

#Hanging userpages -- You can be happy that you are an en.wp user. Obviously en.wp is more important than Commons. After AKlapper found the posts here, he changed the bugs relating to highest prio. This is the usual attitude towards Commons users. We get their test software first and if we find issues they are not important until they appear here. -- Rillke (talk) 15:32, 24 April 2013 (UTC)

I haven't been able to view lots of user talk pages today, but it is perfectly possible to edit the same pages (by manually adding "?action=edit" at the end of the URL). The wikilove icon is present on the edit page too, so why is the edit form still working? --Stefan2 (talk) 22:30, 24 April 2013 (UTC)

It's not just Firefox - I'm having the same problem with some user talk pages with IE9. Mine seems to be fine, as is User talk:Okeyes (WMF) and User talk:Rillke. However, I see the problem on User talk:Thryduulf and User talk:John of Reading. GoingBatty (talk) 23:55, 24 April 2013 (UTC)

Confirmed that disabling the WikiLove extension fixes the issue. GoingBatty (talk) 00:01, 25 April 2013 (UTC)

Worked for me too - thanks to all the above for identifying disabling WikiLove as a temp fix. -- stillnotelf is invisible 15:19, 25 April 2013 (UTC)

Thanks for the explanation. Is there any way to sign for a notification of when this problem is solved so that WikiLove can be reenabled? I find it very helpful in building a collegial, friendly atmosphere. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 03:51, 25 April 2013 (UTC)

You could add your email address to the bug's cc list. That will send you an email every time there is a change to that bug, including a new comment, which is isn't quite what you are after. The only other thing I can think of is that I can try to remember to put a note on your talkpage when I see it's been fixed, but I can't promise to remember or to be online when it happens. Thryduulf (talk) 09:26, 25 April 2013 (UTC)

Regex wizards wanted

Hey all. Trying to do a little text insertion and, since I'm still a relative newbie when it comes to regex, wondered if you could help. Say I have the following Wikicode:

== *DYNAMIC SECTION TITLE THAT WILL BE PASSED AS A VARIABLE* ==

{{TAFI nom|article=Mario Kart|class=C|pic=y}}
* Subset of the Mario franchise, and a hugely successful series of games in its own right.--[[User:Coin945|Coin945]] ([[User talk:Coin945|talk]]) 15:35, 1 February 2013 (UTC)
# '''Support''' --[[User:NickPenguin|<font color="darkgreen">Nick</font>]][[User talk:NickPenguin|<font color="darkblue">Penguin</font>]]<sub>([[Special:Contributions/NickPenguin|<font color="blue">'''contribs'''</font>]])</sub> 06:03, 7 February 2013 (UTC)
# '''Support''' --[[User:Horai 551|Horai]] [[User talk:Horai 551|551]] 08:55, 7 February 2013 (UTC)
# '''Support''' '''<span style="text-shadow:#808080 0.2em 0.2em 0.2em">[[User:ZappaOMati|<font color="#0000FF">Zappa</font>]][[Special:Contributions/ZappaOMati|<font color="#00FF00">O</font>]][[User talk:ZappaOMati|<font color="#FF0000">Mati</font>]]</span>''' 04:33, 8 February 2013 (UTC)

**I'D LIKE THE TEXT TO BE INSERTED HERE**

==*ANOTHER SECTION TITLE THAT WILL NOT BE PASSED AS A VARIABLE*

I imagine it has to do with some fancy lookahead-behind-and who-knows-where, but I don't really know where to begin. Any help would be appreciated! —Theopolisme (talk) 10:52, 24 April 2013 (UTC)

msg = "text i want to add"
header = "the header thing"
text = page.get()
regex = re.compile("""==\s*?{0}\s*?==(.*?)\n==""".format(header), flags=re.DOTALL)
newtext = regex.sub("""== {0} ==\1 {1}\n==""".format(header, msg), text)

Try that. Legoktm (talk) 11:24, 24 April 2013 (UTC)

In which programming language do you need the code? mabdul 06:23, 25 April 2013 (UTC)

Edit protect request to highly-visible template stalled?

Hi all! About a week ago, the Wikipedia:Route diagram template (RDT) project pushed out two edit requests to modify two highly-visible templates:

• Template talk:BSpx; and
• Template talk:BS-overlap.

However, it seems to me that these two requests were not addressed like other editrequests were, even after I wrote on WP:AN to ask to clear the backlog. May I know is there any special procedure to ask for large-scale modification to protected templates? Also can any administrator with the technical background to take a look on it? Thanks.

The background of this large-scale modification is at WT:RDT#Edit protected request 2013-04-17. — Peterwhy 16:42, 24 April 2013 (UTC)

Oh, I'm aware of it, just as I'm aware of all the other backlogged items at Category:Wikipedia protected edit requests, but I no longer touch anything that isn't 100% clear-cut cast-iron copper-bottomed uncontroversial; and in the case of templates (which these are) tested to destruction. This is because of the criticism that I have received when I fulfilled some requests that hadn't been discussed to death first. See also this discussion, if you have the patience. --Redrose64 (talk) 18:56, 24 April 2013 (UTC)

Hi Redrose, thank you for your response. I agree the original discussion has been quite limited to within WT:RDT, so I would like to know, what we should actually do to gain wider acceptance to this modification? And to eventually get the modification done? — Peterwhy 01:34, 25 April 2013 (UTC)

Admins unfamiliar with what a template does or how it works shouldn't carry out a proposed change without being certain that the change is beneficial, especially when the template is highly-visible. So, at the very least, I (and probably others) would like to see some WP:TESTCASES which both prove that these changes do what they're supposed to do, and also demonstrate that existing usage is not compromised.

I see that the proposed change to {{BSpx}} has been put into {{BSpx/sandbox}}, and that's great; but the proposed change to {{BS-overlap}} is not in {{BS-overlap/sandbox}}. Apparently it's in {{BS-overlap/sandbox2}} but that's more difficult to check since it doesn't have automatic links from the box at the bottom of Template:BS-overlap/doc nor from the {{editprotected}} box at Template talk:BS-overlap#Edit protected request 2013-04-19. The text after that states, rather vaguely, "we will have to modify some more unprotected templates afterwards" without detailing which ones nor in what way. I therefore cannot carry out any tests myself, which again means that testcases are needed.

As a frequent user of RDTs, I know what the overall suite is supposed to do, and for me there is one huge unanswered question: by changing the image size specifier from a height to a width, what will this do to those RDTs (such as this one) which use non-square icons? There are plenty of half-width icons such as   (exdKHSTla); there are also some double-width icons such as  (bvWSL-BS2+lr) (and even a few quarter-width icons like  (cSTRq)); these have had a constant height because {{BSpx}} contains x20px and not 20px - testcases will go a long way toward showing that these still work. --Redrose64 (talk) 06:37, 25 April 2013 (UTC)

Yes, I see I have to address your concerns before getting things changed.

• For location of sandbox of {{BS-overlap}}, that is in {{BS-overlap/sandbox2}}. The second sandbox was created by User:Sameboat before I started to work on this batch of modification, probably from a good intent to avoid erasing the previous content. If you know any way to merge the edit log of sandbox2 back to {{BS-overlap/sandbox}}, please do help to move that.
• For complete front to end test cases, please find them inside WT:RDT#Proposed changes to protected BS-overlap, BSpx. We have made some maps that uses {{BS-overlap/sandbox2}} and {{BSpx/sandbox}}. If you would like to create some tests, use the sandbox directory to find the sandboxes we used for testing.
• "we will have to modify some more unprotected templates afterwards": {{BSrow}}, {{BSrow-sc}}, {{BSrow-2}}, {{BSrow-replace}}, {{BSn}}, {{BSn-2}}, {{BSn-startCollapsible}}, {{BSn-replace}}. Again, these are the templates where sandboxes have been created to test for the new changes.
• Double/half/quarter/3-quarter width: The transition should be smooth, except probably between {{BSpx}} and {{BS-overlap}} are updated and other templates (see above) are updated. Technically, we only move the x of x20px to {{BS-overlap/sandbox2}}. The aim is listed at WT:RDT#About PX parameter and Template:BSpx.

Let me know if you have any other concerns. — Peterwhy 13:53, 25 April 2013 (UTC)

Additional note for the last point: we did not change "the image specifier from a height to a width", we change that from size to height. So this does not conflict with the original intention to add that x to {{BSpx}}. — Peterwhy 15:16, 25 April 2013 (UTC)

Pending release of Echo (notifications)

Hey all :). Tomorrow, if things go according to plan (or next Tuesday if they don't!) we'll be launching Notifications, or Echo, which does what it says on the tin - offers a notifications system for Wikimedia projects. You can read more about what's in the release and what we've got planned on the project page. Once things are launched, we'll be gathering feedback on any bugs, annoyances or features people would like to see - if you'd like to get involved in that (and I sincerely hope you all will!) the best venue is the talkpage.

Thanks! Okeyes (WMF) (talk) 21:43, 24 April 2013 (UTC)

Super! Bennylin (talk) 21:59, 24 April 2013 (UTC)

It's been deferred to Tuesday 4/30.--Eloquence* 02:32, 25 April 2013 (UTC)

"Insert citation" in toolbar

Hi, I want to copy the code to insert citation via toolbar. I noticed it's a special feature not found in my wiki. I can't find it on the usual places (Common.js), anyone know where should I look? Bennylin (talk) 21:58, 24 April 2013 (UTC)

WP:RefToolbar --  Gadget850 ^talk 23:52, 24 April 2013 (UTC)

Book deleter?

I've been using the book creator, & in the last week or so, I've had it wipe out my selections five times, for no apparent reason. If the page selection is interrupted, or the rendering is interrupted, it seems to reset & "lose" the rendering, & forces me to delete & add every page all over again. Last time, I left the rendering in progress overnight, & when I came back in the morning, the rendering was gone, & so was the list of pages. (Before that, at least the list survived.) The only connection I can find is my screensaver going on. Clearly, this system is buggy... TREKphiler ^{any time you're ready, Uhura} 22:30, 24 April 2013 (UTC)

Could you provide a specific example, and steps to reproduce for the problem? --AKlapper (WMF) (talk) 09:04, 25 April 2013 (UTC)

Colorized recent changes

I'm trying to interpret my user contributions page at Wikibooks. I can't find anything on the Wikibooks, Wikipedia, MediaWiki, or Meta projects, about this colorized recent changes scheme. The closest I got was some JavaScript mention...

Recent changes that are pending changes of history pages have a certain color to that item on the list. OK. Does the color have a general meaning as regards recent changes? Wikibooks user contributions pages have a color scheme that has the "pending" color, and it has other colors. — CpiralCpiral 01:20, 25 April 2013 (UTC)

Wikibooks has customized the recent changes to have tag markers coloured in pink. Is this what you mean, or are you referring to some other colour? This is a customization that the wikibooks folks did themselves, and is not a default part of the software. These tags are added by the abuse filter to mark edits which meet certain patterns. See Wikipedia:Tags for info on revision tagging. Bawolff (talk) 16:20, 25 April 2013 (UTC)

Help on creating category page

Hi all if someone could take a look at Category:Rollins College Wikipedians I'm running into 2 problems:

• 1 I inserted a table using the drop down but the userboxes are spreading out horizontally, again would like it to look like a 2 rowed table.
• 2 What is the wiki code for deactivating code, I would like to put the {{ and }} in the code at the top row of the table.

• Thanks again. ^{Market St.⧏} _{⧐ Diamond Way} 02:42, 25 April 2013 (UTC)

This edit seems to have fixed it, though I confess that I don't know why. To stop the parser from interpreting wikicode, surround the text in question with <nowiki>...</nowiki>, as I have done to fix your post above. jcgoble3 (talk) 03:08, 25 April 2013 (UTC)

Thanks jcgoble3! This fixes it. ^{Market St.⧏} _{⧐ Diamond Way} 03:38, 25 April 2013 (UTC)

broken template

Could someone please fix {{repetition-inline}}; there is a trailing pipe "%7c" breaking the link. I couldn't fix it myself. Thanks. Fgnievinski (talk) 07:40, 25 April 2013 (UTC)

Template:Repetition-inline (edit | talk | history | links | watch | logs)

I've made an edit, though there may well be a better target for the "link" parameter. -- John of Reading (talk) 08:06, 25 April 2013 (UTC)

Relinking Google for SSL https

There are still articles linked in Google with secure-server SSL prefix "https:" (rather than "http:"), and the pageviews in stats.grok.se have been down to 75% lower for some of those pages. To unlink and relink article "Parabola" now I have, step 1, renamed it as typical "Parabola (mathematics)" (which Google has indexed with "http:" prefix), while "Parabola" remains a redirect. The plan is to rename "Parabola (mathematics)" back again, and see if that resets and relinks the original title "Parabola" as simple http protocol. Then we can check the pageviews to see if they rise back near 2,500 pageviews/day from the recent 600/day. Questions:

• Should we wait a whole week before renaming back to "Parabola" to relink?
• What has caused some articles to relink as secure https in Google?
• Even if relinked as http protocol, will Google later return to https links?

If we can get confirmation, where "Parabola" can be relinked and return to nearly 4x times higher pageviews, then I would conclude that Google's secure-server https links are hindering users from reading pages. Meanwhile, I am considering to rename back within a few hours, unless someone knows it typically takes several days to reset an https link in Google. -Wikid77 (talk) 11:05, 25 April 2013 (UTC)

What the... ? I've undone this move (which broke the hatnote, by the way): we do not randomly move pages around based on our own personal theories as to how Google works, and I can't even comprehend the problem statement. If you want to experiment, you've got a sandbox to do so. Chris Cunningham (user:thumperward) (talk) 12:20, 25 April 2013 (UTC)

Other editors have been discussing Google's https article-links for some weeks now, but it is a very complex problem which will be difficult for many people to comprehend without weeks of study. Fortunately, this is a wiki, and there are other people to help handle complex issues. -Wikid77 13:22, 25 April 2013 (UTC)

• Double-renaming did not relink article as http protocol: After a period of 2 hours, the article was re-renamed from new http-protocol title "Parabola (mathematics)" back to "Parabola" but that did not immediately reset the Google https link as being http protocol, as would be expected if the old name were deleted, then the rename performed later. -Wikid77 13:22, 25 April 2013 (UTC)

• • File a bugreport in bugzilla with wmf site-requests. They have some contacts in Google. Will probably take long, but it can help. I doubt however that it really does matter a lot in traffic if Google found it primarily by https or by http. I wonder however if perhaps there is an issue with non-canonical duplicates of this page somewhere, which might affect it's page rank. If there are canonical issues, then that could also explain why google becomes confused and moves it to https as primary protocol. —TheDJ (talk • contribs) 14:02, 25 April 2013 (UTC)

I would be interested in knowing why we think (or more specificly how it happens) that google pointing people to https has a negative correlation with page views? Bawolff (talk) 16:31, 25 April 2013 (UTC)

Weird...

Was updating the centiJimbo userbox and stumbled on this in Jimbo's userpage history. The "older" edit was indeed to the userpage [10], but 2 years later. Any clue what's up with it? Just a weird ghost in the machine from all the software transitions back then? Screwed-up histmerge? — PinkAmpers&^{(Je vous invite à me parler)} 12:02, 25 April 2013 (UTC)

A known side effect of history merging. —TheDJ (talk • contribs) 13:50, 25 April 2013 (UTC)

• General MediaWiki database corruption from 2004: There are other pages which show corrupted revision links from 2004. In this case, with page "User:Jimbo_Wales" the original entries were from January 2002, but it seems 81 of those oldid numbers, in range 7476700-7476782, were reassigned to later transactions of edits made during September/November 2004, which should have been higher id numbers. Compare some of those revisions around id=7476700:

                dif670 dif680 dif690 dif700 dif710 dif720 dif730 dif740
                dif750 dif760 dif770 dif780 dif784 dif790 dif800 dif800 dif800

I guess someone could hand-update those database records, to have the correct next/previous oldid links, but there are over 110 bad links in those database id numbers already. -Wikid77 (talk) 14:55, 25 April 2013 (UTC)

User talk pages not loading with Firefox

I can't get user talk pages to load today using Firefox. Other pages are fine, but user talk pages won't load as diffs or when I try to edit them. It's only happening with Firefox. SlimVirgin ^(talk) 21:21, 25 April 2013 (UTC)

Amusingly this is happening to me with user pages and some diffs. It has improved a bit during the day but not that much. Now it takes me a few tries. Snowolf ^{How can I help?} 21:23, 25 April 2013 (UTC)

There are a few threads about this up above from yesterday; try disabling the WikiLove tab (in Special:Preferences, on the "Misc." tab) and see if that helps. Writ Keeper ⚇♔ 21:24, 25 April 2013 (UTC)

I started seeing this too today. In Firebug Net tab, it says these URLs are loading endlessly:

http://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-HotCat.js&action=raw&ctype=text/javascript

http://en.wikipedia.org/w/index.php?action=raw&ctype=text/css&title=MediaWiki:Gadget-navpop.css

http://en.wikipedia.org/w/index.php?action=raw&ctype=text/javascript&title=MediaWiki:Gadget-popups.js

If I interrupt loading quickly enough, it doesn't get stuck like that and I see the page normally. Really annoying, though. --Joy [shallot] (talk) 21:51, 25 April 2013 (UTC)

• I disabled WikiLove as Writ Keeper suggested, and the talk pages loaded again. I re-enabled it, and then they wouldn't load. So that seems to be the culprit. Thanks, WK. SlimVirgin ^(talk) 21:57, 25 April 2013 (UTC)

In the meantime I found bug 47457 (esp. comment #28). Ditto. --Joy [shallot] (talk) 22:15, 25 April 2013 (UTC)

Test the new login and account creation page designs

Hi all,

After many weeks of testing, We (the editor engagement experiments team) are is getting close to enabling redesigns of the account creation and login pages. (There's more background about how we got here and why ‎our blog post.)

Right now are trying to identify any final bugs before we enable new defaults. This is where we really need your help: for now, we don't want to disrupt these critical functions if there are outstanding bugs or mistranslated interface messages. So for about a week, the new designs are opt-in only for testing purposes, and it would be wonderful if you could give them a try. Here's how:

• Go to account creation and add &useNew=1 to the URL, or just use this link
• Go to login and add &useNew=1 to the URL, or just use this link

If you have questions about how to test this or why something might be the way it is, I'd definitely check out our step-by-step testing guide and the general documentation.

Many thanks, Steven Walling (WMF) • talk 22:39, 25 April 2013 (UTC)