Wikipedia:Village pump (technical)/Archive 122

Add links
From Wikipedia, the free encyclopedia
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 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

New article creator counter

The new article creator counter tool thing no longer seems to work for me... GiantSnowman 15:05, 26 December 2013 (UTC)

Confirming. Wondering if it's an issue of the tool (somebody needs to contact the author) or with Labs in general (#wikimedia-labs on IRC or the mailing list). --AKlapper (WMF) (talk) 01:24, 27 December 2013 (UTC)
@TParis:@Cyberpower678: - any insight please? GiantSnowman 17:30, 29 December 2013 (UTC)
Tool works for me, just takes very long. That's something that needs fixing soon.—cyberpower ChatOnline 18:11, 29 December 2013 (UTC)
Every time I try to use it I get a 502 error message. GiantSnowman 18:17, 29 December 2013 (UTC)

How to find articles that cite a specific work?

Hi!

Is there a tool or similar to allow finding wikipedia articles in which a specific work is ref'ed?

Thanks Saintrain (talk) 19:05, 26 December 2013 (UTC)

I don't think there's one specific way to do this. One way would be to run a search for a specific string by enclosing the search term in quotation marks (i.e. "The Chicago Tribune"). Killiondude (talk) 19:10, 26 December 2013 (UTC)
Thanks. Oh well. Saintrain (talk) 17:58, 30 December 2013 (UTC)

Unable to delete image

Tracked in Phabricator
Task T61098

I'm trying to delete File:Paovardasfclogo.jpg but I'm getting an error that reads "Error deleting file: The file "mwstore://local-multiwrite/local-public/e/e1/Paovardasfclogo.jpg" is in an inconsistent state within the internal storage backends". Mark Arsten (talk) 03:58, 29 December 2013 (UTC)

Looks like a problem in the infrastructure of the media backends. Reported on bugzilla —TheDJ (talk • contribs) 10:58, 29 December 2013 (UTC)
Thanks! Mark Arsten (talk) 04:28, 30 December 2013 (UTC)

Too many templates

RESOLVED: Fix in {{Featured topic box/sandbox}}; split page long-term. -Wikid77 19:20, 31 December 2013 (UTC)

Wikipedia:Good topics is currently broken, with so many templates that a few won't even show up - and that includes the categorization ones! Wonder if a solution can be found. igordebraga ≠ 04:37, 29 December 2013 (UTC)

Sorry about that... Fell asleep last night working on it. To answer your question, moving stuff to separate pages actually makes it worse because there is more content that needs to be transcluded. What I was going to do is subst: a bunch of the static stuff in the header that should never change to reduce the transclusions... Other than that, I'm going to have to dig a lot deeper and probably dig out the bot to fix it. That being said, template size can be fairly easily reduced through substitution, and you have a larger issue lurking in the near future of being extremely close to exceeding the expensive parser function limit of 500. I'll see what we can do about that as well. Technical 13 (talk) 14:51, 29 December 2013 (UTC)
This could be alleviated somewhat by converting Template:Featured topic box to Lua. However, we might need to rethink the use of the PAGESINCATEGORY magic word, as its use risks bringing Wikipedia:Good topics over the expensive parser function limit, as Technical 13 says. — Mr. Stradivarius ♪ talk ♪ 16:44, 29 December 2013 (UTC)
Mr. Stradivarius, I'm thinking that if you could grant the edit request on Template talk:Icon then all of the icons could be subst: taking care of the immediate issue... This will give a little time to figure out how to deal with the expensive issue. Thanks. Technical 13 (talk) 17:22, 29 December 2013 (UTC)
WP:Good topics is quite a large page. Perhaps split it into sub-pages by topic, with the main page just containing the header and footer boxes and an index of the topics covered by each sub-page? – PartTimeGnome (talk | contribs) 18:17, 29 December 2013 (UTC)
Igordebraga and PartTimeGnome are thinking along the right lines here. As an example of a page where the template limits have been overcome by the use of multiple subpages, WP:AFD hasn't transcluded the discussions all the way through to the main page for a long time now; instead they're transcluded to daily pages, and those daily pages are linked from the main page. I would be very wary of converting anything to Lua - this is not the magic panacea that it's often made out to be, and restricts the maintenance of the template to the Lua-savvy, since it is totally unlike Wiki markup. --Redrose64 (talk) 00:15, 30 December 2013 (UTC)
Looking at this in more detail, I see that it is going to be hard to do away with PAGESINCATEGORY. It is an integral part of Template:FeaturedTopicSum, which calculates whether a topic is Good or Featured. No amount of conversion to Lua can reduce the expensive parser function limit, so I am inclined to agree that the best way to deal with this is to split the pages up into subtopics. This will be necessary at some point in the future anyway, as the number of Good Topics is only going to increase, and even with the most optimised and streamlined template setup the page will become too long to navigate comfortably anyway. — Mr. Stradivarius ♪ talk ♪ 16:05, 30 December 2013 (UTC)
  • Main culprit is {classicon} with blanks and #iferror: Some people put a lot of blank spaces in span-tags inside protected mega-template {{Class/icon}}, with "Pages transcluded on 5,252,562" and those blanks in image-links count repeatedly into "post-expand include size" along with #iferror adding another 100 bytes to each GA/FA icon. Also passing all the page titles into {{Featured topic box}} just doubles the impact of icons+titles, compared to listing a 3-column wikitable. Perhaps step 1 is to switch to a short {{GAsym}} template for most of the page titles, then also split each group of titles into a separate wikitable, under each {Featured_topic_box} to reduce double-counting the icons+titles as post-expand data. For example, wp:Featured_topics/James_Bond_films could be 3x smaller using an image-link icon (omit {classicon} data) or 6x smaller by listing Bond films as 3-column wikitable under the {Featured_topic_box}, or 7x smaller with group image as 4th column; see sample: wp:Featured_topics/James_Bond_films/sandbox. -Wikid77 (talk) 18:30/20:52, 29 December 2013 (UTC)
  • I've made some edits to the /sandbox and /testcases page for that template too (same idea as {{Icon}}) and will put in an edit request because although it is TE protected, it also seems to be cascade protected... :( Technical 13 (talk) 20:03, 29 December 2013 (UTC)

Thanks Wikid and Technical 13 for pointing out that it is {{classicon}} and {{icon}} that are the main resource-hoggers here. After Technical 13's edit request at Template talk:Icon, I made an experimental Lua module to see if Lua sped things up appreciably for these kinds of templates. It does make things faster - down from 25.595 seconds to 17.185 seconds on my sandbox page of ~2400 {{icon}} transclusions. (See Template talk:Icon for the numbers.) However, more surprising is that in the Lua version, only 1.940 seconds is spent inside Lua - most of the rest of the time is spent processing the images themselves. I suppose I shouldn't really be surprised, as when I think about it, resizing 2400 images is not a trivial task. So the next question is, how can we reduce the time that MediaWiki spends generating these images? Does MediaWiki usually cache images in the event that they are used multiple times on a page? — Mr. Stradivarius ♪ talk ♪ 15:27, 30 December 2013 (UTC)

Excellent analysis, and wrapping a template inside another "parameter-less" template does, indeed, cache all processing, reducing a 2,500-icon formatting to 6 seconds, as 2x times faster than Lua {icon/sandbox|ga} when run outside of the wrapper template. Note that the internal templates are also cached, to repeatedly run {icon/sandbox|ga} 2,500 times, as fast as directly #invoke'ing the Lua module with "|main|1=ga". Hence, a parameter-less template, repeated in the hundreds, would run equally as fast, with either Lua or markup internals, but outrun a Lua-based template with parameters by 2x faster, as proven by logical deduction. The main concern is not speed, but rather, the post-expand size. -Wikid77 (talk) 18:30, 30 December 2013 (UTC)
mediawiki caches images ("thumbs") when they are used. if you use a thumb with a new size (i.e., size which are not used on any wikimedia site), the image server will generate a new version of this image, with the appropriate size. this image will be shared among all wikimedia sites who want to display this image at this size. in case of multiple use of the same image on the same page, the browser will only pull the image once from the server, and will use the same image everywhere on the page (not so if you use different sizes - these are different files on the server).
some time ago i dug into a similar issue when trying to see why {{Chess diagram}} was so expensive: this template used to be made of 64 separate images, most of them were the same (an empty "white" square, and an empty "black" square comprise half the board on initial position, and more than half as the game progresses and there are less pieces left). what i found was that just sending the HTML for an image is expensive, and it became significantly more expensive some time ago, when User:Brion VIBBER added a "high-res" feature in order to support some super-displays on hand-held devices. you can see it if you look at the HTML for any image on enwiki: in addition to the old "src=<SOME URL>", there is now "srcset=<URL FOR x1.5 RESULUTION>, <URL FOR x2 RESOLUTION". this almost tripples the HTML code for each image, and inflates the page size considerably. i suggested at the time to add a new attribute to the wikicode for [[File:Some image name]] to eliminate this extra html in cases it's unneeded (empty chess squares do not gain much from the hi-res version). maybe it's time to float this request again... peace - קיפודנחש (aka kipod) (talk) 18:04, 30 December 2013 (UTC)
@קיפודנחש: gzip compression which Wikipedia uses to serve you pages all but eliminates the transfer overhead of this. Matma Rex talk 21:13, 30 December 2013 (UTC)
  • The key thing here to think about is template expansion size and expensive function calls. As far as your speed question goes, we could make a new set of icon images that are already 16px so they won't have to get resized and make the resolution as low as necessary to reduce image size and use the shortest logic filenames (cut back on transcluded characters). I think this new set of icons would be a big improvement, however graphic design and manipulation is not a strong suite of mine and it would take me a great deal of time to get done. Any volunteer? Technical 13 (talk) 01:01, 31 December 2013 (UTC)
For now, I have the temporary fix as a 330-byte reduction in {{Featured topic box/sandbox}}, to install after New Year's so wp:Good_topics will fit within 1,950,000 post-expand bytes, and I have created {{GAsym}} (), as 49-byte versus 196-byte icon example. Plus, I have edited some featured-topic boxes to list 3-column page titles as 2nd wikitable to reduce each by 30% lower (1000-7500b lower) post-expand size. -Wikid77 19:20, 31 December 2013 (UTC)

Image failed to show up after uploading a copy to Commons

Resolved

It appears that after I did some WP:CSD#F8, some images (see File:Chrysosporium keratinophilum.jpg on Chrysosporium keratinophilum and File:Aphanoascus fulvescens ascospores.jpg on Aphanoascus fulvescens as examples) failed to render. Yet other pages like Onychocola_canadensis done during the same time frame had no issues. In Firefox, the image was shown briefly (less than half a second) then disappear. In IE, the image area was replaced by some placeholder. Does anyone know what's happening? OhanaUnitedTalk page 05:29, 29 December 2013 (UTC)

Shows fine on my end. Try purging the image on Commons. — Edokter (talk) — 10:11, 29 December 2013 (UTC)
Looks like purging solved it. Mark as resolved. OhanaUnitedTalk page 03:30, 30 December 2013 (UTC)

A bug in archiving

There is a bug in the archiving system which is polluting WP:WLH data. It might be the code of user:ClueBot III, or a change in some template somewhere. See examples User talk:Jguard18 and Template talk:PD-CAGov. I raised this at User_talk:Cobi#A_bug_in_archiving a few days, but it looks like user:Cobi is away during the festive period. John Vandenberg (chat) 06:39, 29 December 2013 (UTC)

It has been going on for years. At User talk:ClueBot Commons/Archives/2012/April#Strange archive index by ClueBot III I got no reply about User:ClueBot III/Indices/User talk:Pluma which is still edited weekly with the same problem, except in a few of the revisions. PrimeHunter (talk) 11:48, 29 December 2013 (UTC)
Thanks for the pointer PrimeHunter. I've done a bit of analysis of the two cases I see now, and I suspect there are a few corner cases which trigger this bug. In any case, the code should have a very simple test before writing: does the first entry in the list of archives start with '!' and/or does the first entry not match the 'archiveprefix' parameter. Either of those should trigger an exception: the bot doesnt understand the structure and should not write junk to the wiki - instead it should write the problematic page to an exception list on wiki for someone to investigate the cause.
Regarding User_talk:Jguard18, the history shows the first revision (2013-10-29) looks fine, but the second edit results in a dump of the first of allpages. The user was renamed at 2013-10-24, so maybe the bot becomes confused around user renames. Also Jguard has switched formats a few times; see Special:PrefixIndex/User_talk:Jguard18.
Template_talk:PD-CAGov is different, as the history of User:ClueBot_III/Indices/Template_talk:PD-CAGov shows it was busted at the beginning(2012-04-14) after the archiving was requested. But the bot archived to Template talk:PD-CAGov 1, so user:Gogo Dodo moved the archive page to Template talk:PD-CAGov/Archive 1, and 'fixed' the archiving template. But then the bot archived to Template talk:PD-CAGov/ 1, so I have moved that page to Template talk:PD-CAGov/Archive 2, and 'fiddled' with the settings. I'd be surprised if my fiddling fixes the problem, but we'll see how that goes when the bot comes around next time.
Is the code public? John Vandenberg (chat) 05:50, 30 December 2013 (UTC)
The bottom of User:ClueBot III says Bot source. PrimeHunter (talk) 11:10, 30 December 2013 (UTC)
I turned off indexing at User_talk:Jguard18 more than a day ago, but today (HNY!) the bot has regenerated the problematic index. John Vandenberg (chat) 00:24, 1 January 2014 (UTC)
If anyone wants to see clean case which triggered the bug, consider Module talk:Convert. That page was created on 19 February 2013; at 04:15, 5 October 2013 a "User:ClueBot III/ArchiveThis" template was added (diff); the next edit to the page was on 08:40, 6 October 2013 and was ClueBot doing the first archive (diff)—that had the bug (the but was reported but that was archived without comment). Johnuniq (talk) 21:40, 30 December 2013 (UTC)

Template not updating on main space pages

I updated athe template Template:Analgesics as it was linking to cannabis and not the correct cannabis (drug) article. The template has updated but it isnt updating the pages which have the template. So if we go to Thiocolchicoside and show the analgesic template at the bottom of the article we see the template has not updated and is still linking to the wrong cannabis article. This is so with all the articles which have the analgesic template, as can be seen here (this is a large page). I thought it might be something to do with caching last night but the problem is still there. Please help. ♫ SqueakBox talk contribs 15:02, 29 December 2013 (UTC)

The discussion Wikipedia:Village_pump_(technical)#Purging pages when updating template above may provide an explanation. => Spudgfsh (Text Me!) 15:09, 29 December 2013 (UTC)
Thanks, there is no question you are correct. Unfortunately I have a great deal more than 21 pages to purge but it is a working solution. ♫ SqueakBox talk contribs 15:22, 29 December 2013 (UTC)

Pages that link here not updating

Thanks to Spudgfsh and following the advice here #Purging pages when updating template I have for instance successfully updated the analgesic template on Aspirin/paracetamol/caffeine. What has failed to update is the special what links here page for cannabis which still contains the link to Aspirin/paracetamol/caffeine and other articles which I have purged, as these pages now have no link to cannabis. How can I purge the "pages that link here" page?♫ SqueakBox talk contribs 15:39, 29 December 2013 (UTC)

The best answer is to wait for the job queue to process it, instead of increasing the load further by forcing it. Anomie⚔ 16:11, 29 December 2013 (UTC)
That would be the best answer if I didnt want to regularly use the page. Unfortunately, due to the unique titling of the Cannabis (drug) article there are literally thousands of articles that wrongly point to the botanical plant article when the context means they should point to the drug article and these need fixing as a matter of some priority. They cannot be done by a bot as each case needs a human judgement. Of course it is much easier to fix this issue without hundreds of drug articles that have the analgesic or other templates, as well as making it much easier to see which analgesic etc articles have been purged and which havent and this is my reason for wanting this page to be updating quickly and not several months down the line. If it wasnt for this work I am engaged in I would agree, Anomie♫ SqueakBox talk contribs 16:29, 29 December 2013 (UTC)
Well the analgesic template has now updated which is excellent news, hopefully the cannabis page will be a matter of hours too, rather than months♫ SqueakBox talk contribs 16:57, 29 December 2013 (UTC)
As you've found, a purge does not update the "What links here" output; one would instead use a null edit to each page instead. If you've been using the API I mentioned in the previous discussion, you can force the API to update the link tables by adding &forcelinkupdate=1 to the URL for the API request. Also note that there's a limit to the number of pages that can be purged at once using the API (I think it's 50 pages; it might be more). – PartTimeGnome (talk | contribs) 19:24, 29 December 2013 (UTC)

Javascript enabled, but can't be used on English Wikipedia

I am using Chrome 30.0.1599.101. I have Javascript enabled, and I can use VisualEditor on Simple English Wikipedia and French Wikipedia, but on the English Wikipedia I can use none of the Javascript functions. I have checked and my Javascript is enabled. Is this a problem on my end, or what? — Preceding unsigned comment added by Thesixthstaff (talk • contribs) 18:04, 29 December 2013

Have you enabled VisualEditor at Special:Preferences#mw-prefsection-betafeatures? PrimeHunter (talk) 18:44, 29 December 2013 (UTC)

RFC on Template protection

Hello,

There is an RFC at Wikipedia:Village_pump_(policy)#Template_Vandalism to protect templates inorder to deal with template vandalism. Please participate in the discussion.

Thanks, TheOriginalSoni (talk) 19:47, 29 December 2013 (UTC)

Icon post-expand size

We need to create tiny templates for heavy-use icons, such as {{GAsym}} to directly show Good-Article symbol, {{classicon|GA}}: , as 34 bytes, rather than "367" or 11x times smaller. For years, we have been struggling with lists of icons and pagenames which exceed the post-expand include size (2,000 KBMB). A tiny icon template should also use a short image-file name to reduce each byte of post-expand space used. For the Good-Article symbol, it could be:
     · Template:GAsym contents: [[File:GAsym.svg|{{{size|16px}}}|alt={{{alt|}}}|link={{{link|}}}]]
Using image name File:GAsym.svg, the post-expand size would be only 34 bytes, compared to longer "File:Symbol_support_vote.svg" with 48 bytes as post-expand size. Impact: Currently, to avoid massive icon templates, people have been hard-coding (or wp:subst'ing) the long, tedious icon-file names with options, "|16px|alt=|link=" while a tiny icon "{{GAsym}}" would add only 34 bytes of post-expand size in long lists of pagenames (11x smaller than {{classicon|GA}} with 367 bytes, or 496 bytes when passed by a nested template). Previously, there had been a push to kill all tiny icon templates in favor of pushing 100-parameter mega-templates into millions of pages, which cause all those millions of pages to reformat when a new icon parameter is added into the mega-template. By contrast, a change to each tiny icon template would reformat only a small subset of pages, where it was used for efficiency, while allowing the mega-template icons to remain where convenient. Also, as a parameter-less template, a dedicated icon template will be cached by the MediaWiki parser and process 2x faster when repeated on a page. -Wikid77 (talk) 21:38, 29 December, 12:21, 31 December 2013 (UTC)

I suspect you mean 2 MB, not 2,000! (The exact post-include size limit is 2,048,000 bytes.) – PartTimeGnome (talk | contribs) 00:07, 31 December 2013 (UTC)
Well, "2,000 KB" because 2 MB is 2×1024×1024=2,097,152 bytes. -Wikid77 12:21, 31 December 2013 (UTC)

Display slow to update

For several days what is displayed seems very slow to update, e.g. after ten minutes deleted pages still show as bluelinks, items closed at MfD do not show as closed. This does not seem to be a local cache problem - I have cleared Firefox's cache, and indeed still see bluelink and open MfD when using another device. JohnCD (talk) 22:03, 29 December 2013 (UTC)

I have been experiencing this same issue. Transclusions seem to be painfully slow to update as well... E.g. I will have a subpage I transcluded on my user page, and an update to the subpage won't reflect for 15 minutes or more. — MusikAnimal talk 23:57, 29 December 2013 (UTC)
Same goes for {{ping}} — MusikAnimal talk 01:13, 30 December 2013 (UTC)
The job queue has been high for a long time. A set of complex templates to implement {{convert}} was replaced by a call to Module:Convert at 02:15, 11 December 2013. After 29 days, most pages have been refreshed, but lot's haven't. For example, clicking edit at Skipton House shows several Template:Convert/xxx links in the list of transcluded pages at the bottom, and no Module:Convert. Previewing the unchanged contents of the article shows the current transclusions which omits the convert/xxx subtemplates and includes module:convert. In the last 50 hours, the articles linking to Template:Convert/track/disp/ has reduced from 500 to 495.
I don't think the change to use module:convert is responsible for the big job queue because looking at the graphs linked from WP:JQ did not show any surge around the switchover time, and in fact the global job queue steadily declined from 2013-12-10 22:48 to 2013-12-12 19:36. Johnuniq (talk) 03:38, 30 December 2013 (UTC)
I recently added the draft namespace to Module:Pagetype (5,000,000 transclusions), which will have had a far bigger effect on the job queue than the switch to Module:Convert. And I noticed a big spike on Dec 19 when we switched over to the new version of MediaWiki, although I'm not sure if that was the direct cause. — Mr. Stradivarius on tour ♪ talk ♪ 08:19, 30 December 2013 (UTC)
  • Mega-template {class/icon} updated 27 December 2013 for 5 million pages: To add an icon for draft-status pages, the Template:Class/icon was edited at 18:39, 27 December 2013 (3 days ago) with "Pages transcluded on 5,252,562" and so the update hit the wp:Job_queue(s) with 5.25 million pages to re-reformat (). Also remember, people have been creating millions of "empty" talk-pages to show wp:WikiProject banners+icons, and even if no one cares to discuss any issues on those millions of pages, the 5 million still must be reformatted when a new icon is needed for a hundred pages. If tiny talk-pages reformat @10-per-second, then 1 day can clear 864,000 pages (24×60x60x10) from the queues, or 2,592,000 in 3 days. However, eventually the talk-pages of major articles will surface in queues to tinker with {classicon}, and many talk-pages are much larger than the related article pages, where 554,000 of them took 17 days to quickly reformat for Lua {convert} with Lua {cite_web}, Lua {infobox}/{navbox}, but the talk-pages are not using Lua for the massive Template:WPBannerMeta subtemplates which run 1-2 seconds per talk-page. -Wikid77 (talk) 08:33, 30 December 2013 (UTC)
  • The problem seems to be connected with Wikipedia's caches. After closing another MfD discussion I noticed that (a) the MfD page showed the deleted page as a bluelink; purging it turned the link red, but on WP:MFD this discussion still did not show as closed, (b) purging WP:MFD fixed that. Is there a reason why caches are not being updated automatically, or updated less frequently than before? JohnCD (talk) 23:09, 31 December 2013 (UTC)

The SELIBR id is not valid

Can anyone tell me why at European Association for Animal Production the {{Authority control}} template is throwing up the error message "The SELIBR id is not valid", and therefore adding it to the non-existent Category:Wikipedia articles with faulty authority control identifiers (SELIBR)? There's no SELIBR id in the template; deleting the SELIBR field entirely appears to make no difference. I've not been able to reproduce the error elsewhere. Justlettersandnumbers (talk) 00:51, 30 December 2013 (UTC)

Michael Gielen seems to be the only other example, but it is specifying a SELIBR. Chris857 (talk) 01:05, 30 December 2013 (UTC)
PS I found that Gielen had an errant right-to-left mark messing it up. Still looking at EAAP. Chris857 (talk) 01:19, 30 December 2013 (UTC)
When {{Authority control}} is used on European Association for Animal Production it pulls data from the Wikidata page you reach by clicking "Data item" in the Tools menu: wikidata:Q15428859. That page recently added [1] a SELIBR field which contains <!--xxxxxx--> and no number. I don't know how it works but I guess that's the problem. PrimeHunter (talk) 01:43, 30 December 2013 (UTC)
I fixed the problematic item by removing the very odd entry on Wikidata. The issue should fix itself so long as there is an ID specified in the article or another ID is specified at Wikidata. --Izno (talk) 03:17, 30 December 2013 (UTC)
This odd entry was erroneously imported from en:WP to Wikidata: I had corrected the GND No. here and subsequently performed a reimport with the Authority Control gadget to get Wikidata in sync. Somehow the commented-out placeholders from the template here escaped my attention and "looping" them through wikidata turned the comment markup <!-- ... --> into visible text. -- Gymel (talk) 11:42, 30 December 2013 (UTC)
Thanks for the explanation. I don't know the gadget but if it happens automatically unless the user specifically does something to prevent it then maybe it should be reported at wikidata:MediaWiki talk:Gadget-AuthorityControl.js. PrimeHunter (talk) 11:53, 30 December 2013 (UTC)
I raised the issue there. My impression is that HTML comments in templates are always legal thus the gadget should understand them (i.e. eliminate them on import). -- Gymel (talk) 12:20, 30 December 2013 (UTC)
Thanks to all who have helped with this, including Gymel who fixed it in the article and reported the problem. It is, superficially at least, entirely my fault - I made in my Regex editor a version of {{Authority control}} with the various "xxxxx" placeholders of the template page commented-out so as not to have to delete them manually on each use. However, at a deeper level there is probably something wrong - the system should be proof against such user errors. Thanks again, Justlettersandnumbers (talk) 12:34, 30 December 2013 (UTC)

I regularly remove invisible characters from pages to avoid similar situations. -- Magioladitis (talk) 22:55, 30 December 2013 (UTC)

Tech News: 2014-01

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

Recent software changes

  • You can now see the text of DjVu and PDF files in search results on wikis testing the new search tool (CirrusSearch). [2] [3]
  • With the new version of the Wikibase DataModel extension, you can install it outside Wikimedia wikis. [4]

VisualEditor news

  • Images are now shown inside VisualEditor as HTML5 <figure /> elements. Comments are welcome. [5]
  • You can now test a basic version of VisualEditor on mobile devices; see this article as an example.

Problems

Future software changes

  • CirrusSearch will be added as the second search method for Spanish (es), French (fr), Portuguese (pt) and Russian (ru) wikis on December 30. Wikimedia Commons, Wikispecies and Wikinews users will also be able to enable it in their Beta Features options.
  • AbuseFilter log entries will be visible in CheckUser tool reports. [7] [8]
  • It will soon be possible to search for log entries done by users without an account. [9] [10]
  • It will no longer be possible to globally hide users with more than 1,000 edits. [11] [12]

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

08:45, 30 December 2013 (UTC)

DBpedia now parsing infobox subtemplates

Colleagues may be interested to know that DBpedia recently added support for a number of infobox subtemplates, including:

see DBpedia live:

http://live.dbpedia.org/page/Albert_Einstein

and note the "dbpedia-owl:citizenship" properties, for example, pulled from |citizenship= in Albert Einstein, which uses {{Plainlist}}. (Values in the dbpprop namespace are not split correctly, but this will be fixed in a forthcoming update). DBpedia static will be updated on the next release. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:27, 30 December 2013 (UTC)

Tool for checking amount of watchers on a certain page

Where can I find the tool that tells you exactly how many users have a certain English Wikipedia page in their watchlist? Heymid (contribs) 13:55, 30 December 2013 (UTC)

If you click on the history tab of the article, there will another tab offered "number of watchers" which will tell you how many people have it watchlisted. Unfortunately that will only give you exact numbers for pages which have 30 people or more watching the page. Less than that and it will simply say "less than 30 watchers." Valenciano (talk) 14:01, 30 December 2013 (UTC)
"Page information" in the Tools menu also leads to that page, although not directly to the watchers field. PrimeHunter (talk) 14:06, 30 December 2013 (UTC)
Thanks so much! That worked for me. :) However, I was looking for an off-wiki tool that only displays the amount of users watching a certain English Wikipedia page. I think it was a toolserver tool, but the "Page information" page is enough for me. Heymid (contribs) 16:24, 30 December 2013 (UTC)
The history page once linked to a now defunct tool at http://toolserver.org/~mzmcbride/watcher/, but it seems unneccessary now. "Page information" is efficient. It was MZMcBride who requested the change.[13] PrimeHunter (talk) 16:52, 30 December 2013 (UTC)
You might also want to try Dispenser's tool, since that tells you how many of the accounts that are allegedly "watching" the page are active. On some old pages, the difference can literally be 2,000 inactive accounts versus 50 current ones. WhatamIdoing (talk) 20:12, 30 December 2013 (UTC)

Clickable link to diff for use in edit summaries?

Suppose, in an edit summary, I want to mention an earlier edit. So far the best I've come up with is

Fix spelling error introduced by enwp.org?diff=588220707

which has the merit of brevity but, unfortunately, requires that the user paste the "link" into a browser window to actually view the diff.

I'm trying to find a syntax that, in the page revision history, will be clickable -- maybe something analogous to [[Special:Permalink/588220707]] (which is clickable, but which gives only that version of the article with no diff -- I've tried variations like [[Special:Diff/588220707]] with no luck). Unfortunately templates (such as {{diff}}) don't work in edit summaries.

I've looked everywhere for this. Any thoughts? EEng (talk) 19:14, 30 December 2013 (UTC)

Collapse "oops" discussion
see Template:Diff and Template:Diff2.
if you include the following snippet in Special:MyPage/common.js, it will prepare the template for you when you watch a "diff" page, and place it just under the page title when viewing a diff. you'll then be able to "mark" it with the mouse and copy it to the clipboard.
peace - קיפודנחש (aka kipod) (talk) 19:25, 30 December 2013 (UTC)
	if ($('h1#firstHeading:contains(Difference between revisions)').length) {
		$('#contentSub').append( [ '{{diff', 
			mw.config.get( 'wgPageName' ), 
			mw.util.getParamValue( 'diff' ), 
			mw.util.getParamValue( 'oldid' ), 
			'This diff}}' ].join( '|' ) );
	}
ooopsie - i missed the fact you were talking about summaries. i think for a summary you have to include the link (copied from the address line of the browser... it still won't be clickable, but it will be useful. peace - קיפודנחש (aka kipod) (talk) 19:27, 30 December 2013 (UTC)
@EEng: There is currently a patch pending that would add a Special:Diff page (or DiffLink, we're not quite sure about the best name) which would work exactly as you'd want it to: https://gerrit.wikimedia.org/r/#/c/63395/ – I would expect it to be merged and deployed within a few weeks, tops. Matma Rex talk 21:16, 30 December 2013 (UTC)
BTW since the use case is edit summaries (where bytes are at a premium) I would counsel Special:Diff over Special:Difflink. EEng (talk) 02:30, 31 December 2013 (UTC)
Wow -- it's like they looked into the future and read my mind. Thanks! EEng (talk) 21:36, 30 December 2013 (UTC) P.S. I've never been able to figure out how to navigate the bugzilla machinery -- can you throw in the notion that such a feature should allow any two revids to be diffed? Also, I like the feature of {{diff}} that allows suppression of the rendered page -- just gives the source diff. I recognize it's likely too late to add such things to this round. EEng (talk) 21:42, 30 December 2013 (UTC)
Yeah, diffing any revids sounds like a good idea. Suppression of the page contents can be controlled in user's preferences ("Do not show page content below diffs" under "Appearance", I have it enabled myself), so I don't think it should be controllable via the link (and besides, it'd make the linking syntax silly). (I commented on the patch, too.) Matma Rex talk 22:53, 30 December 2013 (UTC)
Of course a more powerful feature would be a syntax to allow any query string in any wikilink, but I don't know the implications and [[Special:Diff/xxx]] is probably the most missed. PrimeHunter (talk) 00:52, 31 December 2013 (UTC)
While they're at it you should be able to append an encoding of your financial information for the year, and it will file your income taxes. (A related feature would be checkoff box for $10 to be contributed to Wikimedia Foundation.) Would that delay deployment? EEng (talk) 02:30, 31 December 2013 (UTC)

Adding columns to existing wiki-tables

Can anyone suggest a tool, please, that will add a column to an existing table, between its current columns, like those on List of Lord Mayors of Birmingham? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:58, 30 December 2013 (UTC)

How easy it would be depends on which column, but find-and-replace in a text editor could add a column before the Terms column by searching for "|| 18" and replacing it with "|| || 18". I think. I didn't try it. Other columns might require some regex expertise. – Jonesey95 (talk) 20:15, 30 December 2013 (UTC)
  • Copy the table from the wiki page in read mode
  • Paste it into a spreadsheet such as Excel
  • Manipulate the table as desired
  • Copy the cells
  • Paste into http://excel2wiki.net/index.php and Submit query
  • Copy output- I usually don't copy the header, as the original is usually better formatted
  • Edit wiki page
  • Paste
  • Cleanup as needed

--  Gadget850 talk 22:05, 30 December 2013 (UTC)

Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:33, 31 December 2013 (UTC)

Parser function bug

Just thought I'd drop a note here in case anyone else comes across it. The March calendar was recently being displayed on February. After some work I tracked it down to a parser function bug where {{#time:F|February}} was returning "March". I filed 59137 and applied a workaround to that page, but anything else that relies on that parser function to return February will likely also have problems. I suspect this has to do with the end of the year. --Shirik (Questions or Comments?) 20:37, 30 December 2013 (UTC)

It appears to be fundamentally rooted in this: <? echo gmdate("Y-m-d\TH:i:s\Z", strtotime("February")); ?> results in a time in March (due to "30 February" not existing, it gets rolled forward). This implies that {{calendar}} needs to be adjusted to expect this behavior. I think I can fix that with relative ease. --Shirik (Questions or Comments?) 20:50, 30 December 2013 (UTC)

Red link works

I had a problem which was solved by clearing the cache and I hope I haven't messed up my computer by doing it. I'm afraid to try this again even though it was just for the one site. I added a Wlink to King George which stays red no matter what I do. Yes, I know I should have created the redirect before doing anything else, but I didn't. Please make sure I'm not leaving a red link there because I have to rejoin the real world now.— Vchimpanzee · talk · contributions · 22:27, 30 December 2013 (UTC)

Simple purge fixed it. — Edokter (talk) — 22:34, 30 December 2013 (UTC)
See Wikipedia:Purge for the procedure. PrimeHunter (talk) 00:30, 31 December 2013 (UTC)

American English auto(in)correct.

When editing, my spellings are automatically changed to American English. Right-clicking over the word shows that the language preference is indeed set to English (United Kingdom) and the problem only occurs when editing Wikipedia. The issue is a relatively new one and does not occur when using MS Word on the same computer. Any ideas?--Ykraps (talk) 11:40, 31 December 2013 (UTC)

it could be a issue with your browser. If I remember correctly Google Chrome has a separate spell check setting. => Spudgfsh (Text Me!) 11:47, 31 December 2013 (UTC)
I'm using Internet Explorer, although I also have Firefox. Using Firefox gave the same problems but there was an option to download a British English dictionary which fixed it. There doesn't seem to be a similar option for Internet Explorer (looking in tools, internet options). I have started adding English spellings to the dictionary but the American spell checker is obviously useful when editing articles written in American English.--Ykraps (talk) 14:15, 31 December 2013 (UTC)
try this => Spudgfsh (Text Me!) 14:22, 31 December 2013 (UTC)
Ah yes, I can see where the spellchecker options are now (tools, manage add-ons, spelling correction). It confirms that English (UK) is the default setting so I guess it isn't working properly. I have disabled the function which isn't ideal but better than the alternative. Thanks--Ykraps (talk) 14:59, 31 December 2013 (UTC)

Timestamp problem

For some reason over at Wikipedia:WikiProject Anime and manga/Deletion Archive/2013 I can not list *{{afdl|1+2=Paradise||9 December 2013|31 December 2013|Keep}} the entry is for a complete AfD entry that gets archived manually once the AfDs are concluded. Looking at the other entries I do not have or not have ever had this problem. - Knowledgekid87 (talk) 22:09, 31 December 2013 (UTC)

For the record what appears is this: [[]] at Wikipedia:Articles for deletion/9 December 2013 (31 December 2013 – Error: Invalid time.) Rather than this (An example):

- Knowledgekid87 (talk) 22:11, 31 December 2013 (UTC)

 Fixed When including a link that includes the equals, the equals must be escaped, otherwise the text before the equals is parsed as a parameter. Here, you are trying to include 1+2=Paradise, so you need to encode it as 1+2{{=}}Paradise. --  Gadget850 talk 22:28, 31 December 2013 (UTC)

Thanks! Happy new year! =) - Knowledgekid87 (talk) 23:24, 31 December 2013 (UTC)

Special:ExpandTemplates gives different page preview

Take a look at User:EEng/sandbox. Here's what you'll see -- displayed here using the {{:User:EEng/sandbox}}:

[Template invocation removed since sandbox has changed, invalidating example -- 18:27, 14 April 2014 (UTC)]

[End of display of User:EEng/sandbox]

Now go to Special:ExpandTemplates -- in the Input text: box enter {{:User:EEng/sandbox}} -- hit OK.

Look at the Preview -- it's not the same as you see here above -- there's only one instance of

1. ^ Ref text

instead of two. (At least that's what I get -- something about my preferences or something?)

How can this be? What's going on??? Please don't give me a lecture about how I shouldn't be doing whatever I'm doing. Just explain how the preview in the template expander can possibly be different from the live page.
EEng (talk) 00:41, 21 December 2013 (UTC)
P.S. I'm guessing this is related to this [14]

This is (poorly) documented at Template:Reflist#Multiple uses. What's happening is that MediaWiki caches the expansion of templates with no parameters, so instead of re-processing the second invocation of {{reflist}} it simply repeats the output from the first invocation. Adding any parameter, even a dummy parameter that has no effect on the template's output, will bypass this caching and so give the correct output.
Special:ExpandTemplates also gives the correct output here because it half-parses the wikitext to get new wikitext and then parses that half-parsed wikitext again to give the preview. To see something else fun, try passing {{#tag:ref|Ref A<ref>Ref B</ref>}} to it.
Bugs 46815 and 31834 are related. Gerrit changes 99792 and 99793 would fix this issue for {{reflist}}, but they're being held up because Parsoid (the thing that transforms between wikitext and HTML for VisualEditor) would probably need changes to keep up. Anomie⚔ 03:10, 21 December 2013 (UTC)
It all makes sense once you point out the caching. This leads to a new concern though. I knew about {{reflist}}'s "repeat" behavior and was experimenting with it as part of a crude hack I won't go into. But it's clear now it's not a feature, but an accident. I had interpreted Template:Reflist#Multiple uses this way: if you use reflist twice, the second invocation gives all the same refs as the first plus any new ones added by < ref> in the meantime; in other words I interpreted the difference between reflist with, or without, any parameter as being that reflist with a parm outputs the accumulated refs, then clears the list, while reflist without any parm just outputs, but doesn't clear. Though the presence/absence of a parm was a puzzling way to control this behavior, I imagined this was a feature provided for some case (though I couldn't think of what that case could be) in which we need to output a set of refs, then later output the same set augmented by new ones accumulated since.

But that's not how it works, and how it does work seems completely useless, so why is it even documented? Depending on how the caching is implemented, or implemented in the future, this "repeat" behavior could stop working, or only work sometimes/unpredictably -- in fact our discussion above is an example. So why make this a documented "feature" the implementers are stuck with? Shouldn't the documentation read something like

If {{reflist}} is used multiple times on the same page, each invocation must have at least one parameter e.g. {{reflist}} or {{reflist|group=}}; otherwise, unpredictable behavior, which may change with future implementations of Mediwiki, will result.
(That's not exactly what you'd say -- the technical details are slightly off -- but you get the idea.)

Of course, I'm assuming no one actually uses this "repeat" behavior for any valid reason -- does anyone know of an example? Even if so, the documentation could at least deprecate such use. I glanced at the bugs you linked and somewhere it's suggested forcing the engine to recognize that reflist can't be cached at all, and of course that assumes there's no legit use of this "feature" either. EEng (talk) 21:11, 21 December 2013 (UTC)

It's supposed to be documented as a known bug, with a workaround noted. Why it is misleading the way it is (or was), I have no idea. If anyone is actually using this as a feature... this would be apropos. Anomie⚔ 22:30, 21 December 2013 (UTC)
If it helps, this edit by Gadget850 seems to have introduced the misleading wording and the strange idea of "closing" the references. Anomie⚔ 22:51, 21 December 2013 (UTC)
Ref tags are part of en extension. There is an incomplete description of the behaviour at mw:Extension:Cite/Cite.php#.3Creferences_.2F.3E. Since 2009 [15] it has said: "In the case of multiple references-tags on a page, each gives the references defined in the ref-tags from the previous references-tag. In the case that these references-tags are produced by templates, each gives the references defined in the ref-tags before the first references-tag, and there is an error message that there is a ref-tag but not a references-tag." It doesn't mention that you only get an error message if there are refs after the first references-tag, and it doesn't mention that the whole issue goes away if the templates have parameters. {{reflist|}} is enough. PrimeHunter (talk) 02:02, 22 December 2013 (UTC)
There used to be a long and very confusing explanation. I tried to summarize it and include the existing practice of closing references. Yes, you can use a pipe alone, but it is liable to get deleted by follow on editors. Multiple reflists are mainly used where there are separate explanatory notes, and we have templates such as {{notelist}}. You can also see them on talk pages. As for a legitimate use of caching and repeating references, I can't think of any. --  Gadget850 talk 18:37, 22 December 2013 (UTC)

Modifying reflist documentation

My point is that what we have now is a short and confusing explanation. Any reason I shouldn't propose the following suggested text at Template talk:Reflist#Multiple uses?

If {{reflist}} is used multiple times on the same page, each invocation must explicitly specify group= e.g. {{reflist|group=""}} (which is otherwise equivalent to {{reflist}}) or {{reflist|group="Notes"}}; otherwise unpredictable behavior, which may change in the future, will result.

This slightly overspecifies the workaround (actually any parameter would do, and up to one invocation with no parameters can be tolerated) but complete accuracy would serve no purpose. I also thought about mentioning the earlier close=1 advice, but that also seemed more confusing than helpful. EEng (talk) 19:54, 22 December 2013 (UTC)

'close=1' is already in use, and removal from the documentation will cause confusion for follow on editors who will investigate it, find no documentation and remove it. I had been considering adding 'close' to the template, so the '=1' would not be needed. --  Gadget850 talk 20:06, 22 December 2013 (UTC)
You don't need to complicate it by mentioning specific parameters, let alone unnecessary parameters that will only confuse. Try one of these:
  • If {{reflist}} is used more than once on the same page, there should be no more than one that has no parameters.
  • If {{reflist}} is used more than once on the same page, only one of them may be used without parameters.
  • If {{reflist}} is used more than once on the same page, only one of them may lack parameters.
Keep It Short and Sweet. --Redrose64 (talk) 20:49, 22 December 2013 (UTC)
We disagree about what constitutes simplicity. Your text turns the directions into a logical puzzle ("at most one should have none") just to add flexibility that's of no value ("Oh good! We can leave out the parameters on one of them!" -- big deal!).
You confuse simpler with shorter (KISS stands for Keep It Simple, Stupid, not Keep It Short and Sweet, as I've always heard it): a definite thing to do (you can always specify "group=") is better than giving the user a choice of which parameter to use -- few editors know even what "group=" is, much less the more obscure parameters.
Your text also doesn't explain why the rule must be followed. Without that, people may decide by experiment that some other approach seems to work, setting the stage for trouble under a later implementation.
And finally, your text doesn't address Gadget's point about people removing "close=" if they don't see it documented. I do think now that "close=" should be mentioned.
So try this:
If {{reflist}} is used multiple times on the same page, each invocation must specify group=; i.e. use {{reflist|group=""}} instead of {{reflist}}. Otherwise unpredictable behavior, which may change in the future, will result. (An earlier technique involving a close=1 parameter is now deprecated.)
— Preceding unsigned comment added by EEng (talk • contribs) 22:40, 22 December 2013 (UTC)
Again, my concern is that follow on editors will remove a blank 'group' parameter since it is not obvious what it does. Why do we need to change an established practice? --  Gadget850 talk 09:45, 23 December 2013 (UTC)
Hmmm. I see your point. Christ, what a mess. More thought is needed. EEng (talk) 11:02, 23 December 2013 (UTC)

Gadget's right. Using group to suppress caching risks its being unknowingly removed when it's group="". So how about this:

If {{reflist}} is used multiple times on the same page, each invocation must specify |close=1 e.g.
*{{reflist|close=1}}
*{{reflist|close=1|group=Note}}
*{{reflist|close=1|35em}}
Otherwise unpredictable behavior, which may change in the future, will result.

EEng (talk) 19:02, 23 December 2013 (UTC)

You don't need 'close' for the second and third examples. To reset the reflist cache, you just need any parameter. --  Gadget850 talk 13:51, 25 December 2013 (UTC)
To avoid further confusion on this topic, I offer this correction: it's not "reset the reflist cache", it's "avoid the template cache". Anomie⚔ 16:08, 25 December 2013 (UTC)

Gadget, obviously I understand that -- I said way back, "This slightly overspecifies the workaround (actually any parameter would do, and up to one invocation with no parameters can be tolerated) but complete accuracy would serve no purpose." What do you want to say? This?...

A reflist must have at least one parameter if there is more than one reflist on the page. Exception: There can be ONE reflist with no parameter, in which case all the other reflists must have at least one parameter. The parameter can be one of the normal parameters e.g. group=Note, columns=2, etc. but if none of the normal parameters is desired you can use, group="", which doesn't do anything but is still a parameter and so satisfies the need for a parameter to be present, but if you don't like that or think that maybe someone will remove the group="" because (as we just said) it doesn't do anything, except it really does do something in the sense that it's a parameter whose presence solves the problem with multiple reflists one one page -- in that case you might wnat to use close=1, which is not really a parameter but will fool the...

It's silly. By telling the user that, on any page with multiple reflists, he should always use close=1 (even when we know it's not necessary) you're giving a simple, easy-to-remember rule and no harm is done. Further, if we encourage editors to rely on regular parameters to force no caching, it's easy to see how things will mysteriously go wrong when someone unknowingly removes the only parameter e.g. col=2 -- in fact, that was your point a few posts back.

Of course, if we really want a super-simple rule, we could just say that reflist should always have close=1, period, all the time, on all pages. But next thing you know some gnome will set up a bot to add close=1 to the 3.000,000 pages with exactly one reflist, and then angry villagers will be at the gates brandishing their implements of husbandry threatening to set fire to the castle.

Per Anomie's comment, I suppose we could say to use nocache=1 or cache=0 or something, but then we'd have to explain why we're not using close=1 anymore.

So, further thoughts please on the current proposal (in bold above). EEng (talk) 21:59, 25 December 2013 (UTC)

[Proposed text by Gadget]:
If {{Reflist}} is used multiple times without a parameter, each subsequent use will repeat the output of the first instance due to template caching. This may also result in a misleading error message:
MediaWiki:Cite error refs without references
Where a page include multiple uses of {{Reflist}}, each subsequent use should include at least one parameter, such as refs or group. If these parameters are not appropriate, then the practice is to use {{Reflist|close=1}}. Do not use close without the =1, as it will be parsed into the column-width.
--  Gadget850 talk 14:14, 26 December 2013 (UTC)
Again, here's my proposed wording from a few posts back, slightly modified:
If {{reflist}} is used multiple times on the same page, each invocation must specify |close=1 e.g.
*{{reflist|close=1}}
*{{reflist|close=1|group=Note}}
*{{reflist|close=1|35em}}
Otherwise unpredictable behavior, which may change in the future, will result. (Symptom of not doing this are sometimes the message MediaWiki:Cite error refs without references, or the same list of references output twice.)
Gadget, what in the world is the point of all that complex explanation? Why tell the user about caching, and document the repetition of the reflist contents as if it's a feature to be supported in future??? If we're gonna warn them "do not use close without the =1", then why not warn them "do not use the German Schließen instead of close", or "do not misspell Reflist"? I'm serious. What's all that stuff get us? Please explain. (I suppose we could put a footnote -- no kidding -- giving a technical explanation for those interested.) EEng (talk) 20:35, 26 December 2013 (UTC)
I have no better wording. And I don't know why the Mediawiki page isn't rendering for you, but the way you modified it certainly breaks it. --  Gadget850 talk 02:02, 27 December 2013 (UTC)
You have no better wording than what??? Which wording are you talking about -- yours or mine? Are you saying mine is OK, or you prefer yours? And if the latter, why? Can you please give a straight answer so we can be done with this? EEng (talk) 14:26, 27 December 2013 (UTC) P.S. Not that it's a big deal, but the errmsg as you had coded it didn't show up at all on both IE and Chrome (whether I was logged in or not).
<bump> EEng (talk) 15:38, 29 December 2013 (UTC)

Discussion continued at Template_talk:Reflist#Proposed_change_to_.22Multiple_uses.22_doc. EEng (talk) 16:35, 3 January 2014 (UTC)

Odd floating text at the top of a number of pages

On a number of pages (Redneck, Lil Wayne discography, Indian Removal Act, West Side Story are a few examples) the following text is floating against the top edge of the browser window (in both Firefox and Safari): [[Image:Svetlana font example.png|List of mass shootings in the United States]]. The only common denominator between all these pages is an error that shows up in red in the References section: "Wikilink embedded in URL title (help)". The error also apparently adds the hidden category Category:Pages with citations having wikilinks embedded in URL titles, yet none of the pages are to be found in that category. WP search doesn't return any instance of the floating text anywhere, but I did find a number of the pages using Google. I'm sure correcting the reference error would solve the problem on a page-by-page basis, but there is apparently a deeper problem that may need to be looked at. --| Uncle Milty | talk | 16:34, 30 December 2013 (UTC)

The "Related changes" for Redneck highlights recent vandalism to Template:Single+space. Although the template has been repaired, the job queue hasn't got round to processing all the affected articles. The text at Redneck disappeared when I purged the page. I guess the vandalised "single+space" was being added somewhere in the article where the parser won't process an image request. -- John of Reading (talk) 16:56, 30 December 2013 (UTC)
Ok, the RecentChangesLinked search is a nice tool. I'll try that in the future. Thanks. And thank you for your help. --| Uncle Milty | talk | 17:09, 30 December 2013 (UTC)

Radiohead

When viewing the Radiohead article, the text "Image:Svetlana font example.png|link=List of mass shootings in the United States" appears at the top of the page and then scrolls down as I view the page obscuring the article text. Same in various browsers. danno_uk 02:57, 1 January 2014 (UTC)

A template was vandalized on the 29th. Purging the article got rid of it for me; do you still see it? Chris857 (talk) 03:16, 1 January 2014 (UTC)
Nope, clear for me too. Thanks. How could I have seen that/fixed it myself? danno_uk 03:25, 1 January 2014 (UTC)
I guess there are maybe three relevant points. 1) This is related to a series of edits adding fake "ads" to articles, so knowing about that helped. 2) If the content isn't directly in the article, it is probably in a transcluded template. Special:RecentChangesLinked is helpful, since you can enter an article, restrict to templates, and see what's changed recently (such as [16]). 3) If nothing is obvious, purging is often a good idea/sanity check. Chris857 (talk) 03:37, 1 January 2014 (UTC)
Many thanks, I'll bear those tips in mind. And a happy incoming new year to you. danno_uk 03:58, 1 January 2014 (UTC)

Problem in page

Hi, someone could correct the error in the page Doctor Who (series 1)? there is : <div style="position:fixed; center:0; top:0;">[[Image:Svetlana font example.png|link=List of mass shootings in the United States]]</div> in the source page. I don't know where it commes. Thanks in advance. Hunsu (talk) 18:34, 1 January 2014 (UTC)

Template vandalism that has been fixed. Purge the page and it'll go away. NtheP (talk) 18:43, 1 January 2014 (UTC)
Thanks. which template was vandalised? Hunsu (talk) 18:47, 1 January 2014 (UTC)
{{Single+space}} NtheP (talk) 19:07, 1 January 2014 (UTC)

Post request

Is there a relatively simple way to do a post request in Java? (this is for a Wikipedia bot) --Jakob (talk) 20:34, 30 December 2013 (UTC)

[17], [18]. Some Java MW bot frameworks: [19], [20]. Also try the docs. πr2 (t • c) 22:13, 1 January 2014 (UTC)

Problem with image formatting

I have run into a problem with the layout of certain entries that involved images. It was suggested that I should post this question here, so here it goes. One thing first, please, please, please, even though this is the "technical" discussion board, I absolutely loathe all of the jargon that gets bandied about on Wiki pages. I would love to have an answer to this, but not if it requires a bunch of crazy links and references to bot and projects and blah-blah-blah. I truly don't mean to be unappreciative of those with lots of knowledge, but in my humble opinion, the jargon one encounters on Wikimedia is its #1 shortcoming. With that disclaimer, here is my best summary of the problem I've run into:

So, I've been playing around with this, and the true nature of the problem has struck me. It seems that WP "protects" photos from being overlaid by text, but that doesn't seem to apply to the corresponding footnote numbers - just the unique text. When there is a photo on the left of a short entry, and if the list of references starts before the text has wrapped up a point under the bottom of the photo, the numbers of the footnotes overlap the photo even though the text of the footnotes remains to the right of the photo. Using the CLEAR option works pretty well, but even using clear|left or clear|right still results in a white space and pushes the first footnote down to the first line of text that clears the bottom of the photo. It might just be me, but the appearance of that is not great.

The same problem happens when you have a list of bullet points (say, within a subsection of an article) and the same section containing the list of bullet points also includes a left-justified photo. The text of the bullet point automatically bumps to the right, just clear of the photo. But, the bullet point itself stays stuck on the left margin. Especially when the bullet list section of the article is in the middle, it can look really bad to force a big white space section using the CLEAR option. The bottom line just seems to be that WP automatically prevents overlaps of images by forcing user-entered text to the right to clear the image, BUT auto-created materials like footnote numbers and bullet points remain stuck on the left margin even if that space is already occupied by a photo. Isn't there any way to automatically position the WP-generate characters (e.g., footnote numbers and bullet points) to the right of photos along with the accompanying text?ProfReader (talk) 22:10, 30 December 2013 (UTC)

I just typed up a little blurb in my personal page (User:ProfReader/sandbox) to show what I'm talking about. I know that there are workaround solutions for this, but just assume that the photo MUST remain on the left and that I simply want BOTH the text of the footnote AND the footnote number itself to appear to the left of the photo, is there a way to do that? ProfReader (talk) 22:19, 30 December 2013 (UTC)

What browser are you using? In your sandbox, I can see the "1." in FireFox 26.0, but not in Internet Explorer 11. GoingBatty (talk) 22:37, 30 December 2013 (UTC)
This is a known issue, which is the result of a design choice in the wiki software that involves how lists are rendered. That choice was to place the bullets (or numbers) outside the space occupied by the list item itself. Normally a browser accounts for this, but when a list is placed to the right of any left-floating (left-aligned) block element such as an image or table, browsers no longer takes the space for these bullets into account. This is a flaw in CSS, the system responsible for how pages are laid out, and there is no 'fix'. but there is a workaround by using the {{flowlist}} template; it will contain the list, and its bullets, in it's own space. — Edokter (talk) — 22:49, 30 December 2013 (UTC)
The reference list is already inside a <div>. I'll have to look and see how that interacts. --  Gadget850 talk 23:01, 30 December 2013 (UTC)
The <div> will need something like style="overflow-x: hidden" to get behaviour similar to the {{flowlist}} template. – PartTimeGnome (talk | contribs) 00:04, 31 December 2013 (UTC)
Thanks for the feedback. I've been using Internet Explorer. I just tried a different browser, and the issue was resolved! Lesson learned: Stop using Internet Explorer. Until a universal fix for all browsers is achieved, I'll just use something else when I use WP. — Preceding unsigned comment added by ProfReader (talk • contribs) 00:19, 31 December 2013 (UTC)
FWIW, I also see the same issue in Opera 12.16. – PartTimeGnome (talk | contribs) 20:52, 31 December 2013 (UTC)
I added the flowlist class to {{reflist/sandbox}} and applied it to User:ProfReader/sandbox. The reference number now appears in IE11. Further discussion at Template talk:Reflist#Flowlist. --  Gadget850 talk 12:29, 1 January 2014 (UTC)
And Edokter pointed out the problem with that. Looking at User:ProfReader/sandbox again, it wasn't quite correct in Firefox- the reference list was still too far to the left as compared to the References heading. Wrapping {{reflist}} in {{flowlist}} resolved that. --  Gadget850 talk 13:56, 1 January 2014 (UTC)
The fix turned out to be simple. Documented at Template:Reflist#Image flow issues. --  Gadget850 talk 16:12, 1 January 2014 (UTC)

Action-createpage

Tracked in Phabricator
Task T61200

Does anyone know what system messages MediaWiki:Action-createpage is used in, besides MediaWiki:Permissionserrorstext-withaction? I ask because if a registered non-admin tries to create a create-protected page (e.g. [21]), then permissionserrortext-withaction gives them the message "You do not have permission to create pages, for the following reasons:". This isn't true, as they do have permission to create pages, they just don't have permission to create create-protected pages. I'm thinking that we could change action-createpage to "create this page" instead of just "create pages", but that isn't going to work if other system messages use it in a different way. — Mr. Stradivarius ♪ talk ♪ 09:47, 31 December 2013 (UTC)

I've filed a bug about this: bugzilla:59200. — Mr. Stradivarius ♪ talk ♪ 09:54, 2 January 2014 (UTC)

Failing to type

Sometimes when I'm writing in the Teahouse, the edit page sometimes doesn't register me pressing the letter keys. Blackbombchu (talk) 01:33, 1 January 2014 (UTC)

Does the problem occur on other Wikipedia pages? On other websites or programs? What browser/OS are you using? ~HueSatLum 01:36, 1 January 2014 (UTC)
No, the problem is only in the teahouse. I'm using Internet Explorer 9. Blackbombchu (talk) 04:23, 1 January 2014 (UTC)
Try refreshing the page. Clear the cookies and cache if needeed using your browser's settings. ///EuroCarGT 04:43, 1 January 2014 (UTC)
  • Is it the edit-notice with WP_teahouse_logo.png? I think it's all the dotted lines at wp:Teahouse; just kidding. When editing a section in wp:Teahouse/Questions, there is a large, in-your-face edit-notice which displays a tedious tree-house logo image (File:WP_teahouse_logo.png) in cumbersome PNG format, rather than rapid JPEG format, and I wonder if other processing is involved, to delay the browser when first trying to enter text into the window. It might be good to click the section to edit, then wait 15 seconds for the browser to process the edit-notice (or related JavaScript?), and then begin typing text into the window. Otherwise, when clicking a section, and immediately typing text, the browser might have delayed the echoing of characters. Thanks for noting the problem, as there are often techniques to make Wikipedia run 3x to 500x times faster, once the bottleneck is pinpointed. -Wikid77 16:44, 1 January 2014 (UTC)

Moving a file from one wikipedia to another without moving to commons

Hi, please could someone help me - i would like to move [22] this file to english wikipedia (from hebrew wikipedia). It has fair use rationale on the El-Kerak Inscription page, but would not qualify for commons. Is there an easy way to do this? Oncenawhile (talk) 16:29, 1 January 2014 (UTC)

Normally, one would use the import function, but I don't know if that is possible in this case. — Edokter (talk) — 16:33, 1 January 2014 (UTC)
Try adding a Copy to Wikimedia Commons template in the Hebrew Wikipedia and once it has been copied, it is ready to be linked here. ///EuroCarGT 17:03, 1 January 2014 (UTC)
He said the image does not qualify for Commons, as it is a fair use image. — Edokter (talk) — 17:09, 1 January 2014 (UTC)
True, ill find another option to find. ///EuroCarGT 17:23, 1 January 2014 (UTC)

Why not just download it from hewiki and upload it here? πr2 (t • c) 22:10, 1 January 2014 (UTC)

How do I upload a logo for a sports event?

Hello.

How do I upload a logo for a sports event, and under which conditions is it allowed (for copyright reasons)? I'd like to upload the logo for the 2014 European Allround Speed Skating Championships, just like the one present in the 2012 article.

The 2014 logo is available here.

(Unfortunately that website, belonging to the International Skating Union has recently gone through a makeover, and the result is ... mediocre in my view. For instance, I'm getting "Done, but with errors on the page.")

Maybe someone could help out with the upload?

Thanks in advance.

HandsomeFella (talk) 17:08, 2 January 2014 (UTC)

Go to this page (direct link to their logo), download it, and then upload it under whatever filename you want. For the description page, you should basically start with the rationale from the 2012 logo and just replace "2012" with "2014" where applicable, along with giving the correct source URL instead of "The logo may be obtained from the official website of the event (http://www.essc2012.hu/)." This should be sufficient; logos are almost always fair use when used to identify the owner of the logo, since that's the whole point of a logo. Two other things: (1) Copyright questions can be sent to WP:MCQ, which is dedicated to image copyright. (2) To get the URL of the logo, visit the page, rightclick the image, get the image properties and copy the URL into your browser, and cut everything off the end of the URL after the height=360 bit. Sorry if you already knew this, but your comments made me think you were confused. Nyttend (talk) 19:48, 2 January 2014 (UTC)
Thanks for the help. I have uploaded the logo now, and added it to the article. I moved the pic of the venue (Vikingskipet) further down, but now the caption for that pic does not show. Why is that?
HandsomeFella (talk) 13:46, 3 January 2014 (UTC)
The caption only shows if you include |thumb in the image link. The venue picture in the article has already been fixed by Ukexpat. – PartTimeGnome (talk | contribs) 21:22, 3 January 2014 (UTC)

Commons down

Tracked in Phabricator
Task T61221

MediaWiki internal error.
Exception caught inside exception handler.
Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information.

Eh? — Edokter (talk) — 18:40, 2 January 2014 (UTC)

I get the same at commons:. If click the Commons icon at a file page like File:Raupe des Buchsbaumzünsler, Cydalima perspectalis 24.JPG then I get [23] which currently says "[45465c86] 2014-01-02 18:41:28: Fatal exception of type MWException". PrimeHunter (talk) 18:45, 2 January 2014 (UTC)
I got the same. Came here to see if it was just me but obvious not. Is there a page on Meta where this should (hopefully) have been reported? AgneCheese/Wine 18:48, 2 January 2014 (UTC)
I had the same issue. Weird. --Coemgenus (talk) 18:55, 2 January 2014 (UTC)
Bugzilla is the place to report it. I found bug bugzilla:59221, which appears to be about the same problem happening at Wikivoyage (same error message, bug logged at 18:53). I've noted that it's affecting Commons too on that bug. – PartTimeGnome (talk | contribs) 18:59, 2 January 2014 (UTC)
Same here, I can't get anything to load, not even the main page. What's going on?--eh bien mon prince (talk) 19:04, 2 January 2014 (UTC)
Further, this issue is only affecting web access to Commons; the API works fine. Looking at recent changes via the API, I see a few non-bot users successfully making edits, including IP address users. I can't read the pages they are editing with the usual web interface, even logged out. Since some people are making edits, it would appear not everyone is affected by this. – PartTimeGnome (talk | contribs) 19:25, 2 January 2014 (UTC)

Back up right now for the first time in an hour. Marcus Qwertyus (talk) 19:29, 2 January 2014 (UTC)

I'm getting a comparable problem, running IE11 in Windows 8.1, and I use Monobook both here and there. I've been getting HTTP 500 errors all day. Nyttend (talk) 19:40, 2 January 2014 (UTC)

Here in Brazil, the access to Wikimedia Commons was normalized after the site has been unavailable for a few minutes. (Tested in Google Chrome 31.0.1650.63, Mozilla Firefox 26.0 and Windows Internet Explorer 11.0.9600.16476.) Fúlvio (talk) 19:47, 2 January 2014 (UTC)

This is handled in bugzilla:59221, as written before. Issue should be fixed now, thanks to Reedy. Sorry for the inconvenience & thanks for reporting it here. --AKlapper (WMF) (talk) 21:09, 2 January 2014 (UTC)

Talk page reorganization tool

Long ago I made a silly decision to organize my user talk archives by month. Is there a tool to refactor them into a yearly format? NE Ent 21:19, 2 January 2014 (UTC)

  • Edit each year and wp:Subst 12 months: The merge will be quick enough by using top-level wp:subst'ing in each year's archive:
{{subst:NE Ent/Archive/2009/January}} - for each 12 per year
Once all 12 months are listed, then copy before saving and just change the year number in the next year's page. However, since the old archive pages will still exist, consider naming with a year-prefix "yr" as in "/Archive/yr2009" or such. -Wikid77 12:16, 3 January 2014 (UTC)

not getting email confirmation

I have changed my email in settings and have requested an email confirmation be sent. WP says it has been sent, but it's over 30 min and I am getting nothing. I confirmed the email address was correct. I am getting email to the new address from other locations. Can anyone either fix, explain, or offer alternative way to confirm? Thanks. μηδείς (talk) 22:37, 2 January 2014 (UTC)

Emails in general can be delayed, blocked or disappear for different reasons. It's hard to know wether you are getting all the mails you should. See Wikipedia:Email confirmation#Known issues. PrimeHunter (talk) 23:27, 2 January 2014 (UTC)

Restore vs Restart -- Technical Question

Here is a common scenario as I understand things:

  1. an article stub is created by an editor.
  2. other editors may or may not work on the stub.
  3. at some point the article/stub and related talk and history pages are deleted for insufficiency (WP:N, CSD:A7, whatever).
  4. later an editor finds the needed sources and decides to resurrect the article.

At this point there are four options:

  • (A) restore the deleted article pages into the mainspace and add in the new material.
  • (B) restore and WP:INCUBATE the article pages.
  • (C) restore and WP:USERFY the article pages.
  • (D) restart the deleted article as a new (same name) article written from scratch.

QUESTION: What happens to the related pages (especially the edit history) of the deleted first version of the page if the page is restarted (option D above)? Are they overwritten or can they be accessed somehow (by an admin or higher I assume) if needed? F6697 FORMERLY 66.97.209.215 TALK 10:06, 3 January 2014 (UTC)

Everything is still there and can be recovered and even reintegrated into the the new article. This is called a history merge and detailed by Wikipedia:How_to_fix_cut-and-paste_moves. —TheDJ (talk • contribs) 11:17, 3 January 2014 (UTC)
You can ask for restoration of the history in such a case at Wikipedia:Requests for undeletion or by contacting any admin in Category:Wikipedia administrators willing to provide copies of deleted articles. I'm in that category and would be happy to consider any requests like the scenario described above. Graham87 04:28, 4 January 2014 (UTC)

Image disappearing

For some reason, File:Paulette Carlson.jpg is redlinked on Paulette Carlson. I know there was a valid image in the article just yesterday. And neither the local nor Commons shows the image as being deleted. Where did it go? Ten Pound Hammer • (What did I screw up now?) 08:13, 4 January 2014 (UTC)

I see it in the commons deletion log. -- John of Reading (talk) 08:24, 4 January 2014 (UTC)

New classic edit toolbar buttons no longer appear to work in new version on mediawiki?

New classic edit toolbar buttons, which I created myself, no longer appear in the new version on mediawiki 1.22 monobook skin.

I created this page: User:Igottheconch/common.js with several edit toolbar buttons, and nothing appears, even after I refreshed the page. I have tried this on three other wikis, mediawiki.org and two personal wikis, and these new edit toolbar buttons do not appear.

Any suggestions?

Thank you!

Igottheconch (talk) 18:54, 28 December 2013 (UTC)

@Igottheconch: mwCustomEditButtons is no longer supported, you can achieve the exact same functionality using mw.toolbar.addButton(): basically, replace structures like mwCustomEditButtons[mwCustomEditButtons.length] = { ... } with mw.toolbar.addButton({ ... }). This change has been discussed at T49872 and was announced via Tech News a few months ago. Matma Rex talk 20:55, 28 December 2013 (UTC)

Sigh, i still can't get it to work.

How would I change the below to something that would work? Thank you. 

 if (mwCustomEditButtons) {
 
   mwCustomEditButtons[mwCustomEditButtons.length] = {
     "imageFile": "http://images.wikia.com/central/images/7/74/Button_comment.png",
     "speedTip": "Comment visible only for editors",
     "tagOpen": "<!-- ",
     "tagClose": " -->",
     "sampleText": "Insert comment here"}
  }

Igottheconch (talk) 22:07, 29 December 2013 (UTC)

  • Can anyone please help? Thank you. Igottheconch (talk) 09:36, 6 January 2014 (UTC)

@Igottheconch: You have one '}' too many, that should never have worked :). The following is okay. Matma Rex talk 11:17, 6 January 2014 (UTC) 

  mw.toolbar.addButton({
     "imageFile": "http://images.wikia.com/central/images/7/74/Button_comment.png",
     "speedTip": "Comment visible only for editors",
     "tagOpen": "<!-- ",
     "tagClose": " -->",
     "sampleText": "Insert comment here"
  });

A template purge bot or manual purge assistant might be handy

(originally posted at WP:Help desk)

There have been a rash of template vandalisms lately. Even after a vandalized template is fixed, pages may continue to show the vandalism until they have been purged. This is a rather tedious process to perform manually, especially since the vandals target highly used templates. The community is having a discussion about what if anything could/should be done: Wikipedia:VPP#Template_Vandalism.

Is there a project page where 'bot and/or tools authors get together to exchange ideas? I was thinking that a nice 'bot and/or manual tool to have would be one that can seek out all pages that transclude a recently modified template and apply a purge to those pages.

A manual tool would probably put less load on the servers, since I can easily imagine templates being edited in stages.

I was originally considering submitting a feature request to Bugzilla, but this doesn't exactly count as a bug or even a MediaWiki enhancement. Stigmatella aurantiaca (talk) 16:24, 31 December 2013 (UTC)

To refresh pages after template changed, add "?action=purge". -Wikid77 08:29, 6 January 2014 (UTC)
  • Wait 2 days or edit from transclusion-info page: The null-editing of pages has been updating the "page was last modified" date at bottom, so for templates with fewer than 1,000 related pages, the automatic reformat should complete within 2 days. However, when major articles are affected, then they can be directly null-edited from the related transclusion-info page, such as:
There is an edit-tab for each page listed, and high-visibility pages can be selected sooner (if known) from the list. Edit perhaps 40 pages, and then refresh the transclusion-info list (the page-count lags behind for days). Meanwhile, people have been discussing reduced editing of the mega-templates which flood the wp:job_queue(s) with millions of pages to reformat. Otherwise, "Do not Panic" as there are numerous problems in thousands of pages, and the major readership has come to expect occasional vandalism to slip past, along with out-dated facts, or partial data. Also, some vandalism can be a good thing, if it spurs idle users to fix the page, then copy-edit for clarity, and perhaps update other pages. We are too accustomed to seeing vandalism as an isolated, negative event, rather than an incentive for many users to actively help update thousands of other pages. -Wikid77 (talk) 18:51/20:43, 31 December 2013 (UTC)
Example: A template changed at 21:28, 3 January 2013, triggered reformatting of 217 small pages (to hide a space in mixed numbers), which completed by early 5 January (within 40 hours), while the wp:Job_queue(s) held over 500,000 jobs in processing. -Wikid77 08:29, 6 January 2014 (UTC)
In answer to the question about where to ask about bot ideas, I think you want WP:Bot requests. A manual tool would probably be better, since most template edits don't need the pages using the template to be updated immediately. It's only urgent cases such as vandalism where it's necessary.
Regarding a Bugzilla request, MediaWiki already has a feature to update all pages that transclude a template: just edit the template. For templates with less than 500 transclusions, the updates happen almost immediately. If a template has more than 500 transclusions, the page updates are added to the job queue. Unfortunately, MediaWiki is often slow to process the job queue, normally taking days. Since updates are processed in a queue, edits to well-used templates will slow down updates for other less well-used templates. Ideas to improve this should be submitted to Bugzilla, as I'm sure the developers would love to hear about them. – PartTimeGnome (talk | contribs) 21:11, 31 December 2013 (UTC)
The statement that "For templates with less than 500 transclusions, the updates happen almost immediately" is inconsistent with experience. Over 24 hours ago (specifically at 20:48 UTC, 1 January 2014) I edited Template:Brian Grazer to remove a link to The Inside and replace it with a link to The Inside (TV series). That template has 88 transclusions, far fewer than 500. However, approximately 25 hours after making this edit, Special:WhatLinksHere/The Inside still shows about 80 incoming links, of which the vast majority are due solely to template transclusions. (The discrepancy in numbers is probably because a few of the 88 articles transcluding the template happen to have been edited within the intervening time for other reasons.) Incidentally, last month I did a similar template edit and watched the "what links here" count for the link I fixed for over 14 days, and there was no indication that the job queue had done anything at all in that time. --R'n'B (call me Russ) 21:52, 2 January 2014 (UTC)
Sorry, when I said "updates", I was simplifying slightly. By "update", I meant that the parser cache for those pages is invalidated, to be regenerated next time the page is viewed. (The parser cache stores the HTML sent to browsers when a page is viewed.) The updates to the link tables used by Special:WhatLinksHere happen separately. These updates always go through the job queue AFAIK, so might lag behind the pages themselves being re-rendered. Up to now this thread was only about what readers saw in articles, so I didn't mention the link table updates in my earlier post (it's confusing enough as it is!). – PartTimeGnome (talk | contribs) 22:56, 2 January 2014 (UTC)
Well, the parser-cache version of pages can still lag behind for at least 2 days, after changing a template with only 217 transclusions. -Wikid77 08:29, 6 January 2014 (UTC)

Searching in contributions

How to search quickly in my contributions - only actions where i renamed pages? Is possible to obtain this result via query, or tag filter or something else? Thanks. XXN (talk) 11:57, 2 January 2014 (UTC)

Special:Log/move/XXN should do it. Legoktm (talk) 12:07, 2 January 2014 (UTC)
You can also get to the same page by looking at the top of your Contributions page. You will see a link to "Logs" and then pick "Move log" from the first drop down box. GB fan 12:10, 2 January 2014 (UTC)
Thank you guys.

Other challenge: someone, sometimes uses AWB; and his edits has summary edit description ”using AWB”. It's possible somehow to show only those contributions throught many other - to view not all contributions, but only those done with AWB? :) XXN (talk) 13:35, 2 January 2014 (UTC)

Here is a link that does that for your edits, http://tools.wmflabs.org/sigma/summary.py?name=XXN&search=AWB&server=enwiki&max=500&ns= GB fan 14:00, 2 January 2014 (UTC)
For rowiki not working http://tools.wmflabs.org/sigma/summary.py?name=XXN&search=AWB&max=500&server=rowiki&ns= :)) XXN (talk) 21:04, 4 January 2014 (UTC)

"Disclaimers" not showing in mobile view

The tiny little link to our disclaimers that appears among a cluster of tiny little links at the bottom of articles in "desktop view" doesn't appear in "mobile view" - at least when I use Dolphin browser on my Samsung Note (Android/Ice Cream Sandwich). Not sure who to tell. --Anthonyhcole (talk · contribs · email) 13:13, 2 January 2014 (UTC)

Didn't appear on my Blackberry's default browser either, although IIRC it never appeared on the bottom section of articles on mobile view either. hmssolent\You rang? ship's log 15:43, 2 January 2014 (UTC)
You could file a bug under the mobile extension, or maybe someone from the WMF (ping Ironholds) can comment. πr2 (t • c) 15:58, 2 January 2014 (UTC)
I'll go see if any of the mobile devs are in the office and file a bug either way. Ironholds (talk) 18:09, 2 January 2014 (UTC)
Answer is "it's in the sidebar menu" (accessed by hitting the button in the top left that looks like a set of horizontal lines). Does that work? Ironholds (talk) 18:14, 2 January 2014 (UTC)
Thanks. Can you possibly arrange to have the disclaimer link appear on the same page as the articles? --Anthonyhcole (talk · contribs · email) 15:34, 4 January 2014 (UTC)
Same page? Both tabs can be visible simultaneously (at least on my device). Ironholds (talk) 19:59, 4 January 2014 (UTC)
Sorry, I didn't understand your response. I'm wondering if you can arrange things so that when a reader opens an article in mobile view the disclaimer link appears on the same page as the article text. --Anthonyhcole (talk · contribs · email) 11:27, 6 January 2014 (UTC)
User:Anthonyhcole: Well, I can't, but it seems like a reasonable request; wanna throw in a Bugzilla entry about it? Ironholds (talk) 21:57, 6 January 2014 (UTC)
I don't know how to do that. I went to the page linked above, and I'm still no wiser. Could you pass it on for me please, Ironholds? --Anthonyhcole (talk · contribs · email) 22:22, 6 January 2014 (UTC)

done. Ironholds (talk) 23:42, 6 January 2014 (UTC)

Merci beaucoup. --Anthonyhcole (talk · contribs · email) 04:36, 7 January 2014 (UTC)
Actually, the problem with the current arrangement is readers don't see the link to "disclaimer" when reading the article, because (at least on my device and I think some others above) its hidden behind a link consisting of 3 horizontal bars in the top left of the screen. Most readers will never click that link, so most won't even see the "disclaimers" link. It needs to be added to the little cluster of links at the bottom of the article, among

Wikipedia ® Mobile | Desktop
Content is available under CC BY-SA 3.0 unless otherwise noted.
Terms of use | Privacy

I'd add that as a comment to your request but I haven't received my account confirmation email yet. Would you mind making that clarification please, Ironholds? --Anthonyhcole (talk · contribs · email) 05:57, 7 January 2014 (UTC)

Common.css

Hello! I've added a code #p-lang div.pBody ul li { font-family: sans-serif; } to my common.css (I dislike previous appearance of font of interwiki) and I've been reported that «Code that you insert on this page could contain malicious content capable of compromising your account. If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump. The code will be executed when previewing this page.» What does it mean? I think, this code is absolutely normal. In Russian Wikipedia it works without problems. Thanks. --VAP+VYK (talk) 17:05, 2 January 2014 (UTC)

It's a standard message that is shown at the top of all User .css and .js pages, regardless of what's actually on the page. It even shows for empty pages. Your CSS contains absolutely nothing that might be compromising your account. --Redrose64 (talk) 17:14, 2 January 2014 (UTC)
Thank you very much for answer, you've set my mind at rest. :) --VAP+VYK (talk) 17:32, 2 January 2014 (UTC)
You could also try Preferences → Beta features → Typography refresh. I quite like the new look. --  Gadget850 talk 17:44, 2 January 2014 (UTC)

Pronouns

At Special:Preferences, under "Internationalisation" we're given the option of being identified as "he", "she", or neither. Many people however, including genderqueer and intersex people, prefer to be referred to using the singular they. Can this be fixed? – Arms & Hearts (talk) 06:22, 3 January 2014 (UTC)

We could, but it wouldn't make much difference right now, as the translations system only knows about male, female and generic. You'd have to fix all the translation systems for it to take any effect. But such a request would go into bugzilla with the translate/language team as a feature request. —TheDJ (talk • contribs) 09:41, 3 January 2014 (UTC)
For the records, some related discussion has taken place in bugzilla:53834. --AKlapper (WMF) (talk) 10:34, 3 January 2014 (UTC)
As far as I know, MediaWiki doesn't use it to say he or she anywhere, but in some foreign languages it's used for a gender-specific variant of the word "user". Wikipedia editors can choose to say "they" if the gender is not specified. {{They}} does exactly that. Are there English words which vary between not knowing anything about a person and knowing the person doesn't want to be described as either male or female? PrimeHunter (talk) 12:58, 3 January 2014 (UTC)
@PrimeHunter: It's used for more than that; for example, in Polish, in a sentence like "PrimeHunter said something", "said" would be a different word depending on your grammatical gender ("powiedział" for male, "powiedziała" for female). It's pretty much not used in English localization of MediaWiki, but it could be (in, say, Echo's notifications like "PrimeHunter mentioned you on his/her talk page" – this is currently not done). Matma Rex talk 13:30, 3 January 2014 (UTC)
  • I'm still wondering why the system changed from asking if a user was male, female, or unspecified. This asking if they want to be referred to as he or she implies that the system has some kind of AI that will automatically change any reference to any user to what they preferred to be called, and this is simply not the case. Technical 13 (talk) 13:38, 3 January 2014 (UTC)
    There was some long boring discussion somewhere about some people with complicated sexuality apparently being offended or something. And changing this *does* consistently change the entire interface in languages where this distinction matters more than in English, even the "User" namespace name is changes (like PrimeHunter mentioned), so this also makes it easy for other people to refer to one with correct grammatical gender. Matma Rex talk 13:42, 3 January 2014 (UTC)

In case one wishes to manually addr4ess another user as that user prefers, is there a way on en.wikipedia to see that user's prefernce choice on this item? DES (talk) 16:12, 6 January 2014 (UTC)

I use User:PleaseStand/userinfo. This script adds userrights and the date of the last edit, which is very helpful if you're trying to find someone who's actually active.
There are more direct methods (that presumably work on all wikis, not just en.wp), but I don't know how to use them. Perhaps someone else could post them? WhatamIdoing (talk) 18:51, 6 January 2014 (UTC)
There are templates too:
and just in case you're wondering, {{he or she|Redrose64}} → he or she; {{his or her|Redrose64}} → his or her (I'm not saying). --Redrose64 (talk) 20:03, 6 January 2014 (UTC)
The magic word GENDER works on all wikis. It is described at mw:Help:Magic words#Localisation and translatewiki:Gender. All the gender-dependent templates use GENDER. If you just want to see the gender then you can also use the API like this (there may be a shorter way): https://en.wikipedia.org/w/api.php?action=query&list=users&usprop=gender&ususers=WhatamIdoing. PrimeHunter (talk) 21:02, 6 January 2014 (UTC)

This all seems a bit ridiculous and political to me. The logic in the claim that "He edits wiki pages" is the top choice which implies the default gender can also be applied to the new format that "They edit their wiki sandbox (They/Their)" then "they" becomes the implied default gender. I don't really understand all this, but how often have you addressed someone else using a gendered pronoun rather than using the standard wikicoded {{reply to}} template or the [[User:...]] syntax? Why don't we just take the easiest route and have everyone declare their gender on their userpage instead? TeleComNasSprVen (talk • contribs) 20:18, 6 January 2014 (UTC)

In fact, now that we have the {{#babel...}} extension syntax and categories in place, we can just ask people to put {{#gender:...}} onto their userpage, put them into the relevant categories like the babel templates do, and ask people to address them this way. We could have all kinds of ways of addressing then, based on their inclusion in [[:Category:User male]], [[:Category:User female]], [[:Category:User intersex]], [[:Category:User bisexual]] etc, etc TeleComNasSprVen (talk • contribs) 20:29, 6 January 2014 (UTC)
I rarely address people by genderd terms, but i frequently would refer to them by such terms. "I agree with User:Example when he says that we ought to..." or "I think User:Sample is making a big mistake when she asserts that..." If I don't know the gender I will usually use "s/he" on talk pages (not in articles) -- I strongly dislike singular they. DES (talk) 21:58, 6 January 2014 (UTC)
Your proposal makes the data less structured, making it harder for software to choose the correct language. Though MediaWiki doesn't make much use of the preference in English, it is very important for other languages where terms such as "user" have masculine and feminine forms. Your proposal could work in addition to the preference to supply extra information for humans, though.
The example categories you gave aren't much use for making language decisions, though – if someone is in Category:User bisexual, I am none the wiser as to whether I should use "he", "she", "it", "they", etc. Better examples would be Category:User refer to as masculine (he/him/his), Category:User refer to as feminine (she/her/hers), Category:User refer to as neutral singular (it/its) and Category:User refer to as plural (they/them/their).
Personally I would find it too much effort to check a user page just to pick a pronoun. It's so much easier just to use {{subst:gender:UserName|his|her|their}} or similar. – PartTimeGnome (talk | contribs) 00:43, 7 January 2014 (UTC)
@DESiegel: Well, if you dislike singular they, you can still refer to everyone else who doesn't fit into the gender binary (genderqueer/intersex/neutral/unspecified) as "s/he", I suppose, so that doesn't add much as to why we need to include this feature at all. The alternative to that is using "it", and so far, I've never met anyone who wanted to be addressed/referred to as "it".
@PartTimeGnome: You have a good point, but I don't understand why using a magic word like {{#gender...}} would make data less structured, you'll have to explain that a little more in depth with me. Your second point, that in other languages the MediaWiki software uses this to create different inflections for the word "user", leads me to ask, what pronouns if any can other languages use to address/refer to people outside of the gender binary? And if so, what would be the inflection for the word "user"? In English this seems a pretty trivial matter to agonize over if someone or some software got your gender wrong when referring to you.
I think the root of the problem is more to do with the fact that the English language (and most other languages) have no pronouns at all to refer to genderqueer/intersex or genderless people (singular they is simply a pronoun to be used broadly, I use this when referring to anybody, gendered or not, and I don't really like having to use a template to refer to someone). TeleComNasSprVen (talk • contribs) 01:32, 7 January 2014 (UTC)
Yes, you've got that exactly right. Some of the agonising over this preference is because people see it as a statement of their identity, and dislike being constrained to the "standard choices" imposed by our language.
It isn't the use of a magic word that makes the data less structured, but the notion that users would not be restrained in the what they could set using the magic word. The software needs some way to translate whatever the user placed in the page to language for referring to that user. If the idea is to allow users a way to express their wishes in more detail just for humans (i.e. still keep a separate preference for the software to use), we already have a large range of userboxes. I'm not sure there's any point categorising – I don't think there's a good use for a list of Wikipedians that prefer to be referred to in a certain way.
You ask a good question about what options other languages have. Some cultures have the concept of a third gender (or more), though this does not seem so common in languages. Sanskrit does have a third gender. I don't know how MediaWiki handles such languages (does it?).
If your concern about using a template is how others might perceive this, use subst:. By substituting the template, just the word "he", "she", etc. is saved in the wiki source, so no one will see that you used a template to discover the word to use. If your concern is usability, I agree it isn't great – it would be good if the software disclosed this preference in a less technical manner. (I could say the same about the {{#gender...}} idea. A preference setting is a lot less technical than adding a parser function to a user page.) – PartTimeGnome (talk | contribs) 02:37, 7 January 2014 (UTC)

Wikiproject cleanup and popularity statistics

Some wikiprojects have this available:

  • Cleanup listing, documenting by type all tagged pages under a projects' purview (eg [24])
  • Popularity listing, listing the top 500 pages by viewcount (eg Wikipedia:MED1500 from [25]).

I'd like to enable this for WP:ANATOMY, as it would prove invaluable in determining which articles receive attention. However I haven't been able to contact the developers of either of the tools, or have tried and not had a response, and am beginning to worry that "Available in November" is not referring to November, 2013. I am wondering: (1) if there are alternate tools that we could use, or (2) if there are any users with privileges that could add our project to the listings above. This would prove invaluable to the project, and we'd be very grateful if it could be enabled. --LT910001 (talk) 00:11, 4 January 2014 (UTC)

Hi, I'm the author of the popularity stats tool. I was hoping to have it ready by November, but problems with the move from the Toolserver to WMF Labs combined with a total rewrite of the program itself have slowed things down a bit. Assuming nothing goes horribly wrong in the next couple of weeks, it should be ready for new projects by the end of this month. Feel free to leave me a message on my talk page sometime in the last week of January. Mr.Z-man 04:13, 4 January 2014 (UTC)

：：Great! Thanks a lot for creating the tool, Mr.Z-man I'll contact you later this month. Do you know how we might get the cleanup listings? I'm particularly interested in finding a list of all proposed merges under our scope. --LT910001 (talk) 00:15, 5 January 2014 (UTC)

See User:Svick/WikiProject cleanup listing. WhatamIdoing (talk) 18:54, 6 January 2014 (UTC)

How do I get OpenDyslexic working?

I just read User talk:Jimbo Wales/Archive 153#More WMF Bright Line violations. I'm not very technical. Am I right in thinking I can get that font working on the Wikipedia pages I read? --Anthonyhcole (talk · contribs · email) 15:32, 4 January 2014 (UTC)

You can, although it's not in a very obvious place. Click the cogwheel next to "Languages" in the sidebar, choose "Fonts" and then select OpenDyslexic from the list. the wub "?!" 15:37, 4 January 2014 (UTC)
Cool. Thanks the wub. Wow. It's like someone turned the light on. Thanks Lawrence. --Anthonyhcole (talk · contribs · email) 17:19, 4 January 2014 (UTC)
You know, if that information isn't already there, then maybe we should add it to WP:ACCESS and WP:WikiProject Dyslexia's pages. WhatamIdoing (talk) 18:56, 6 January 2014 (UTC)
Maybe Andy Mabbett, who seems knowledgeable and committed regarding accessibility issues, has some thoughts on how best to present this option to readers with reading difficulties. --Anthonyhcole (talk · contribs · email) 22:28, 6 January 2014 (UTC)

PrettyLog.js issue

MediaWiki:Gadget-PrettyLog.js doesn't work on Special:Log for me. Can someone fix it? --Rezonansowy (talk • contribs) 19:26, 4 January 2014 (UTC)

What do you mean with "doesn't work" ? You mean you don't get the same styling that you see as you don on Commons ? That seems logical, because search results on en.wp don't have the same styling either. Did this gadget ever work ? —TheDJ (talk • contribs) 13:25, 5 January 2014 (UTC)
OK, could add these styles to this script? --Rezonansowy (talk • contribs) 11:30, 6 January 2014 (UTC)
 Done —TheDJ (talk • contribs) 16:41, 6 January 2014 (UTC)
Thank you --Rezonansowy (talk • contribs) 23:14, 6 January 2014 (UTC)

Failed section redirect

I added the link Factors influencing size to Talk:Sea cave and when ever I open that link in a new tab, it takes me to the section Sea cave#Factors influencing size but when ever I click the link directly, it instead takes me to the beginning of the whole article. Blackbombchu (talk) 01:09, 5 January 2014 (UTC)

That problem is not happening anymore. It only happened immediately after I created that section on the talk page. That problem isn't happening in this section of Village pump either. Blackbombchu (talk) 01:12, 5 January 2014 (UTC)

Infobox problems

Hi all, thanks in advance, I am trying to post multiple images (including one map) to the infobox on this article Pittsburgh metropolitan area. Yet only one image is showing. Can someone provide me the correct code for this I've already compared it to code in such articles as Atlanta metro area and all seems correct to my untrained eye. Market St.⧏ ⧐ Diamond Way 11:28, 5 January 2014 (UTC)

In the case of the skyline, you included "File:" where it was not needed, and in the case of image_map1, you added a line for it without removing the one that was already there, which defined it as null. Someguy1221 (talk) 11:35, 5 January 2014 (UTC)
Many thanks, and thank you even more for going ahead and fixing the code! Market St.⧏ ⧐ Diamond Way 12:08, 5 January 2014 (UTC)

Links to Commons

If I try to look at the Commons page for an image used on English WP, I am sent to a non-existent page called "File:File:(whatever).JPG". I think this link needs to be sorted out. LynwoodF (talk) 12:49, 5 January 2014 (UTC)

Incidentally, I am solving the problem in the short term by copying and pasting the file name with just one "File:". LynwoodF (talk) 12:56, 5 January 2014 (UTC)
That is a bug in the MultimediaViewer beta. There is a notice about it on the feedback page of the MultimediaViewer beta. —TheDJ (talk • contribs) 13:40, 5 January 2014 (UTC)
Thanks. I see someone is working on it. LynwoodF (talk) 14:31, 5 January 2014 (UTC)

Minor problem with Template:Infobox international hockey competition

If the "winners" parameter is not defined, it causes a line break between "Second place" and the silver medal image (if the "second" parameter is defined), as well as a line break between "Third place" and the bronze medal image (if the "third" parameter is defined). If the "fourth" parameter is defined, there will be a line break between "Fourth" and "place". An example can be seen in this article revision (see the infobox to the right). I've been able to reproduce this problem in the latest versions of Safari and Chrome on the latest version of Mac OS X, but the latest version of Firefox does not have this problem. What causes this? Heymid (contribs) 16:59, 5 January 2014 (UTC)

Page moves in own userspace for users with non-Latin user names

Apparently the MediaWiki:Titleblacklist prevents pages from being moved to mixed-script names. Is there any way to override this for page moves in one's own userspace? This is a constant nuisance for me. (If I create a subpage with an English name (say, a draft) in my own userspace, and I don't like the name I first chose, I can't move it because of this restriction, as my Hebrew username and the Latin target subpage name form a mixed-script title; instead, I have to copy-paste and request a {{db-userreq}} for the original page.)

Thanks, הסרפד (call me Hasirpad) 19:21, 5 January 2014 (UTC)

@הסרפד: One workaround could be to create the draft in the new Draft namespace, where your username would not be part of the title. GoingBatty (talk) 19:45, 5 January 2014 (UTC)
@GoingBatty: True, but this only applies to the example I gave (there may be other reasons for wanting to move a page in one's userspace) and, in any case, I prefer to have my drafts in my userspace. הסרפד (call me Hasirpad) 19:58, 5 January 2014 (UTC)
I don't think you're hitting the mixed script rules; instead, it appears you are hitting a rule that is intended to block letter-lookalikes in article titles (apparently "פ" is considered a lookalike). I've added a whitelist entry for your userspace. Anomie⚔ 20:34, 5 January 2014 (UTC)
@Anomie: Thanks! I just tested it and it works. (Why was I not hitting the mixed-script rules though? Does the software (forgive my terminological ignorance) recognize subpages as non-mixed? הסרפד (call me Hasirpad) 21:35, 5 January 2014 (UTC)
The mixed-script rules exclude the User and User talk namespaces (and various others). Anomie⚔ 21:42, 5 January 2014 (UTC)

Problems with WikiProject Physics Portal

There is a problem with the WikiProject Physics Portal. In general, I think the instructions that tell each segment of the portal where to hold an article or picture for the que to the Physics Portal are no longer correct. More specifically, when I post an article to the Monthly Selected Articles it is there but hidden (Please see February. 2014 here and here); the monthly selected pictures should probably also be checked, and finally, the monthly anniversaries should probably also be checked.

Although the January 2014 monthly anniversary reflects my most recent editing , it was not functioning correctly by hiding the edited content, although it is there now.

Addtionally, it would be much appreciated if a person could look at the Selected Articles and Selected pictures for 2009, 2010, 2011, 2012, and 2013. Perhaps reviewing these pages could show how these are intended to be set up as well as errors that have occurred between 2009-2013. Below, in the next section, I have provided the last edit diffs for each page which I am requesting a review so this post can at least appear to be brief. Thanks in advance. --- Steve Quinn (talk) 23:10, 5 January 2014 (UTC)

Requested review pages

Hopefully, a section like this doesn't cause confusion. If it does just go ahead and remove the section head and this content to the original post above. Here are the last edit diffs for each of the requested pages:

Selected article:

Selected pictures

- Steve Quinn (talk) 23:19, 5 January 2014 (UTC)

I've fixed an error in the "Edit" links at Portal:Physics/2014 Selected articles and repaired the February page. The 2009-2013 pages look OK to me. -- John of Reading (talk) 08:18, 6 January 2014 (UTC)

WP DB

How can i browse wikipedia database? XXN (talk) 01:27, 6 January 2014 (UTC)

You can download a database dump and browse it on your own computer. Wikimedia Labs and the Toolserver also hold live replicas of the databases; anyone with an account on either system could query the database for you. Also see Wikipedia:Database queries. – PartTimeGnome (talk | contribs) 00:57, 7 January 2014 (UTC)

Can't display a page in a frame

Wondering what de:Denkmal was talking about, I went to Google Translate and told it to translate http://de.wikipedia.org/wiki/Denkmal, but I got a message (apparently from my browser, IE11) saying "This content cannot be displayed in a frame" and a little explanatory note for non-techie types like me. A link to open the content in a new window was provided, but something went wrong, because clicking the link caused new windows to proliferate like Hydra heads. The same happens when I try to translate an English article into German. This is seemingly rather new, because it's not been that long of a time since last I got an entire page in another language (German?) translated into English this way. Three questions: (1) Is this no-frame thing just a problem with some of the Wikipedias, or is it something that affects all WMF sites? (2) Is there anything we can do about it? (3) Could it be a browser thing? I was using IE8 until my previous computer died several weeks ago, and I don't remember encountering this kind of problem with it. Nyttend (talk) 02:27, 6 January 2014 (UTC)

I tried going to http://translate.google.com using IE11 and Firefox 26. When I typed "http://de.wikipedia.org/wiki/Denkmal" in the box, it then provided a link I could click to see the translated page. (It also provided a "Drag and drop link here to translate the page" box that did not work.) However, I couldn't reproduce your issue with frames. GoingBatty (talk) 03:20, 6 January 2014 (UTC)
Did you click the link to see the translated page? Problems arise only when I click the link. Nyttend (talk) 03:54, 6 January 2014 (UTC)
Sorry for not saying so before: When I clicked on the link to see the translated page, everything looked fine. GoingBatty (talk) 03:58, 6 January 2014 (UTC)
@Nyttend: Do you get the same issue in other scenarios? (e.g. logged in or logged out, other de.wikipedia pages, other foreign wikipedia pages, other foreign non-WP pages) GoingBatty (talk) 04:09, 6 January 2014 (UTC)
Hadn't thought to try other languages (I assumed all was the same, since en: and de: were throwing a fit), but that helps: fr:Paris translates (although gibberish, since I accidentally told it to translate English into German on this French page...:-), and I'm getting an English translation of de:Paris as well. Didn't try to log out; since I've not yet set up an email client on this computer, I've been leaving myself logged into Google so that emails will immediately be visible. de:Denkmal is now working fine; I don't know what the difference is, since I've not changed anything. Nyttend (talk) 04:16, 6 January 2014 (UTC)
I got a similar message looking at a Google map embedded on another website a little while back (using Opera 12). I went back later and it worked fine. I think Google have been fiddling with something related to frames. – PartTimeGnome (talk | contribs) 01:21, 7 January 2014 (UTC)

Tech News: 2014-02

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

Recent software changes

  • The latest version of MediaWiki (1.23wmf9) was added to test wikis and MediaWiki.org on January 2. It will be enabled on non-Wikipedia wikis on January 7 and on all Wikipedia wikis on January 9 (calendar).
  • The old note-taking site (Etherpad) was removed on December 30, 2013. You can see most of the documents on the new site. [26]

Problems

  • On January 2, Wikimedia Commons, Wikidata and all Wikivoyage projects were broken for 2 hours due to language cache update issues.
  • On the same day, it was not possible to edit most wikis for about 30 minutes, due to a database replication problem.

Future software changes

  • The new search tool (CirrusSearch) will be added as the default search method for Italian Wikipedia, French Wikisource, Wikidata and all Wikivoyage sites, and as a second search method for the German Wikipedia and all Wikibooks sites on January 6. [27]
  • Spanish, French, Portuguese and Russian Wikipedia users will also be able to enable CirrusSearch in their Beta Features options. [28]
  • Plural form rules for some languages will be changed. Many translations of the user interface for Belarusian, Russian, Serbian, Ukrainian and other languages will need to be changed. [29] [30] [31]
  • You will see a warning when you try to delete a page linked to from other pages. [32] [33]
  • You will be able to hide redirect pages on the list of protected pages. [34] [35]
  • You will be able to use keyboard shortcuts in the Translate tool, by pressing Alt+1 and similar key groups. [36] [37]
  • E-mails sent by MediaWiki will include the name of the site in their From: line. You will be able to change this name on your wiki by editing the MediaWiki:Emailsender page. [38] [39]
  • Images viewed in the Beta Features media viewer will load faster. [40] [41]

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

08:35, 6 January 2014 (UTC)

wiki:

Is there a reason, why wiki: redirects to http://c2.com/cgi/wiki? Armbrust The Homunculus 11:10, 6 January 2014 (UTC)

@Armbrust: Yes, because that is the original wiki: WikiWikiWeb. Matma Rex talk 11:12, 6 January 2014 (UTC)
There has been discussion for some time about removing this misleading interwiki prefix. In fact, it is slated to be removed with the next interwiki map synchronisation. See m:Talk:Interwiki map#Wiki. — This, that and the other (talk) 11:23, 6 January 2014 (UTC)
Also, WP:DAW. --Redrose64 (talk) 17:53, 6 January 2014 (UTC)

"New messages" from 2011

I just happened to view a page while logged out, and when I did this, I saw the trusty old Orange Bar of Doom telling me I had new messages. However, as you can see, the last edit to my IP's talk page was in June 2011. I find it difficult to believe that no-one who has been assigned that IP since then had bothered to click the "new messages" link... but there you go.

More to the point, I was under the impression that the Orange Bar of Doom "expired" after a given period of time (say, a couple of weeks), since talk page messages for IPs generally become irrelevant after a while. Clearly this is not the case. I wonder if we should get such an expiry implemented...? — This, that and the other (talk) 10:23, 5 January 2014 (UTC)

Sounds like a sensible idea to me. I'm not sure whether the OBOD had an expiry set in the past, but if it did, then I suppose it's possible that the behaviour may have been changed when notifications were introduced. In either case, this should probably go in Bugzilla so that the right people are notified and can work out what actually happens in the code. — Mr. Stradivarius ♪ talk ♪ 08:34, 6 January 2014 (UTC)
As one who has taken some fairly long wiki-breaks in the past, I can tell you that the old orange bar still signaled for new messages for logged-in users when the newest msg was more than a year old. I don't think it included any expiry. I don't see why it should have included one only for IP users, but I've never really tested that. Many msgs are time-sensitive and make now sense months later, but some do. I'm not sure an expiration is actually a good idea. DES (talk) 14:28, 7 January 2014 (UTC)
However, the wording might be changed away from "You have new messages" if they are actually quite old. Many IP's have complained at the help desk that they got a warning about edits they didn't make. Some are worried that their computer or Internet connection was hacked, but mostly they just blame Wikipedia. After seeing the prominent OBOD they apparently don't notice the usually old date of the signed message, or MediaWiki:Anontalkpagetext which is displayed at the bottom of IP talk pages. Would it be possible to pass the age or time of the latest message so a wiki can adapt the text in MediaWiki:Youhavenewmessages and other system messages? PrimeHunter (talk) 15:26, 7 January 2014 (UTC)
Not just the help desk: sometimes they send complaints to the person who left the original message. I'm sure that I've seen these complaints over a long period, certainly from before the introduction of Notifications, and investigating, I find that they concern messages left more than two years earlier. this edit pre-dates Notifications, and if I log in as Redrose64a (talk · contribs), I used to get the full OBOD but now I get the orange-background "you have new messages" talk page link. User:Redrose64a has never visited User talk:Redrose64a, so that I can see how long the orange bar persists; it's over 14 months so far. --Redrose64 (talk) 15:52, 7 January 2014 (UTC)

Problem when using Chrome

When using Firefox, I see the tabs at the head of the article in two groups: the Article and Talk tabs on the left and Read, Edit, New section and View history on the right. The tabs I see using Chrome are different (Read, Edit, View history, star, down-arrow, and TW+down-arrow), but used to be positioned similarly. For the past week or so, the second groups of tabs is positioned below the first group and overlapping the article title, with the Read tab partially underneath the Talk tab. Besides the weird appearance, this interferes with click-drag selection of the article title. I'm using Chrome version 31.0.1650.63 m. Does anyone know if this is an resolvable by changing some Chrome setting, or perhaps a CSS issue, or what? 203.177.166.122 (talk) 10:48, 5 January 2014 (UTC)

The problem is only superficially your browser. The problem is that you are logged out when using firefox, but logged into an account when using chrome. That is the only way the last three tabs would even show up. So something is probably wonky with your .js or .css or gadgets on your account. If you edit from your account again so we can see those pages, we may be able to tell you more. Someguy1221 (talk) 10:58, 5 January 2014 (UTC)
If the row of buttons is overlapping the title, then that means that your browser window is not wide enough to fit them on the other line. —TheDJ (talk • contribs) 12:46, 5 January 2014 (UTC)
Thanks. I just realized about the logged in vs. not situation myself, checked that, and saw that logging in with firefox resolved the tab differences. The placement differences remain, though. I'm making this edit while logged in, and I'd appreciate anything you can tell me to help. I'm not a css or js jock and haven't looked at my userpage css or js files in quite a while. If it's a problem there, though, I can probably figure it out myself by the process of elimination -- I'll give that a try tomorrow if I don't see anything further here. Thanks again & Cheers, Wtmitchell (talk) (earlier Boracay Bill) 12:52, 5 January 2014 (UTC)
I have blanked my vector.js and vector.css pages, logged out, shut down and restarted chrome, and logged back in. I'm still seeing weirdness, as follows:
  • Right now I am viewing this page in tab 1 of a chrome window, editing this section in tab 2, and viewing (not editing) User:Wtmitchell/vector.css (which is currently empty) in tab 3.
  • Chrome tab 1 displays WPtabs in expected positions, but sometimes will misposition them briefly (sometimes multiple times) during a page reload.
  • Chrome tab 2 has the WPtabs mispositioned. Reloading the page does not fix this.
  • Chrome tab 3 has the WPtabs mispositioned. Reloading the page does not fix this.
  • Clearing the chrome's cache using chrome's settings->tools->clear browsing data->empty the cache and then reloading pages with mispositioned WPtabs doesn't get the WPtabs back to their expected positions.
I'm not sure where to go from here in troubleshooting this. Wtmitchell (talk) (earlier Boracay Bill) 19:47, 5 January 2014 (UTC)
Please provide a screenshot; it's easier to see what's wrong. ALso, do you by any chance have the Allow toggling between menus and tabs gadget enabled? — Edokter (talk) — 11:36, 6 January 2014 (UTC)
See image here. Apologies if my description above was unclear.

I don't think I have Allow toggling between menus and tabs enabled, but I don't see that on my Preferences page. Where would I check that? Wtmitchell (talk) (earlier Boracay Bill) 01:26, 7 January 2014 (UTC)
The option is called "Enable toggling between tabs and dropdown menus in the Vector skin". You can find it under Preferences → Gadgets → Appearance. – PartTimeGnome (talk | contribs) 02:46, 7 January 2014 (UTC)
I checked that, and it is not enabled. Making this edit, I see that the tabs are still mispositioned when I'm editing this article but not when I'm viewing. I see that they are mispositioned when I'm editing some other articles but not all of them. They seem to be not mispositioned when I edit articles I haven't previously edited, or perhaps not edited in a very long time. I'm wondering whether this might be somehow related to caching somewhere between me (on Boracay island in the Philippines) and WP (in Florida, as I remember). I haven't tried editing using Chrome and logged in from a different machine here -- I'll try it give that a whirl tomorrow and will report my results here after doing that. Wtmitchell (talk) (earlier Boracay Bill) 12:20, 7 January 2014 (UTC)
There is too little space in the screenshot. WHat is noticable, is the large search box. Check your preferences again to see if Widen the search box in the Vector skin under Gadgets is enabled. — Edokter (talk) — 12:46, 7 January 2014 (UTC)
I checked, and found "Enable simplified search bar (Vector skin only)" was enabled. I disabled that, and found on trying to edit this section that the tabs were not mispositioned. I re-enabled it and found on trying to edit this section that the tabs were still not not mispositioned. I had neglected to check before fiddling with that, so I don't know whether tabs were still mispositioned when editing this section before I fiddled with that vector preferences option. I restored the vector.css and .js files I had blanked and the tabs were still not mispositioned. It seems to be OK now. Thanks for your help. Wtmitchell (talk) (earlier Boracay Bill) 15:43, 7 January 2014 (UTC).

Red link that isn't

The wikilink to a recently created article, Den Chai Railway Station on the page State Railway of Thailand#Network is being displayed in red as a dead link, despite the article being there. I've had a quick look in various browsers, cleared my cache and tried from a different computers and the link remained red. I created a link from my own sandbox and it didn't have a problem, so it seems to only be a problem with the State Railway article. There are lots of route diagram templates on the page so it could be that one of them has a bit of incomplete syntax or wikimarkup that's affected the material on the page - though I can't see anything obvious and it seems unlikely to just affect one link. Could it be that something just isn't updating properly and it'll fix itself soon? Altogether I'm a bit clueless as to what could be causing it so I'd appreciate it someone could take a look. Here's a link to the user who created the station article's talkpage (he spotted the problem). Thanks in advance for any help! Jr8825 • Talk 12:15, 6 January 2014 (UTC)

It was red for me, too, and I turned it blue (for me) by purging Wikipedia's cache. I don't know whether that purges it for all readers or only those fed by a particular server. If it is still a redlink for you, click "edit source" for the page, and in the address bar replace "action=edit" with "action=purge". Something seems to be wrong which make purging necessary much more often than usual - see discussion under "Display slow to update" above. It's a pain, and I wish it could be fixed. JohnCD (talk) 12:35, 6 January 2014 (UTC)
This has been happening for all red-links I've turned blue over the last week or so. Doing a false edit, or refreshing the page clears it, but it's something that needs to be fixed. Lugnuts Dick Laurent is dead 19:14, 6 January 2014 (UTC)
A purge should work for all readers. – PartTimeGnome (talk | contribs) 01:28, 7 January 2014 (UTC)
  • Wikilink squirrels are tired of running to update redlinks: We need to get a head-count of the current group of treadmill squirrels who have been running to reformat page-cache files and relink categories. They seem to be very tired in recent months, and people are beginning to see through the illusion of so-called "computer-based typesetting" to reveal the Animal Farm underneath. That's why Wikipedia is written in so many other languages: very few of the squirrels can read English. Anyway, perhaps we can get some human volunteers to run beside the squirrels, if they swear an oath not to reveal there are "no computers" in the WMF – it's been all ornery treadmill squirrels for some years now.... ;‑) Wikid77 (talk) 21:29, 6 January 2014 (UTC)
    Maybe we should switch to using pigeons instead. It seems to work for Google. – PartTimeGnome (talk | contribs) 01:28, 7 January 2014 (UTC)
    IP over Avian Carriers --  Gadget850 talk 19:50, 7 January 2014 (UTC)
The simpler way to purge is to enable either Preferences → Pending changes → Add a clock in the personal toolbar that displays the current time in UTC (which also provides a link to purge the current page) or Preferences → Pending changes → Add a "Purge" tab to the top of the page, which purges the page's cache when followed. --  Gadget850 talk 19:50, 7 January 2014 (UTC)

Year in other calendars!!

https://en.wikipedia.org/wiki/Template:M1_year_in_topic

Please look at the link above. It's an internal link but I've formatted it as an external link. Within it I see hyphens used where minus signs belong. I cannot edit those. Wikipedia is supposed to be editable. How can I edit this? And who is so rude? Michael Hardy (talk) 05:51, 7 January 2014 (UTC)

@Michael Hardy: It's not rudeness - it's just templates embedded in templates. Try Template:M1YearInTopic (no calendar) and Module:Year in other calendars, and try posting on the associated talk pages if you need assistance. Happy editing! GoingBatty (talk) 05:59, 7 January 2014 (UTC)
I find this:
-1344 – -1343
There you see two hyphens where minus signs belong. Journalists are stupid and one expects nothing better of them, but one certainly does expect better than that from people who edit Wikipedia articles. Nothing in the links you cite gives me any way to edit these. Michael Hardy (talk) 06:25, 7 January 2014 (UTC)
Template:Year in other calendars uses mathematical functions in Module:Year in other calendars to compute the years. It wouldn't be practical to manually edit the numbers for thousands of years. Module talk:Year in other calendars redirects to Template talk:Year in other calendars, so that's where to post a request that hyphens in negative numbers are automatically converted to minus signs. PrimeHunter (talk) 07:27, 7 January 2014 (UTC)
Hi Michael - I'm the rude one who wrote Module:Year in other calendars. :) You can indeed edit that, but it might get a bit technical as all the years are calculated automatically. I probably should have coded in proper minus sign support when I first wrote it - that was an oversight. Still, it's an improvement on the old wikitext template which displayed negative year ranges as e.g. "-100–-99". In any case, there should be a fix coming along fairly soon to add proper minus signs, as you can see from the conversation below. Best — Mr. Stradivarius ♪ talk ♪ 16:52, 7 January 2014 (UTC)
  • Fix ready for minus-sign years in sandbox: For Template:M1_year_in_topic, I have tested a fix, in Module:Year in other calendars/sandbox, to show "&minus;" ("−") for negative years numbers or year ranges (as "−1344 – −1343") in the Lua-generated calendar box. However, we should consider adding any other changes before release into the 2,816 related pages. -Wikid77 (talk) 16:25, 7 January 2014 (UTC)
    I should probably update it to use Module:Arguments before we go live. Also, your fix isn't working for the Chinese calendar - see Template:Year in other calendars/testcases#3001 BC. This will also be the case for any new calendars which do the year formatting themselves, rather than leaving it to the calendar object. Why don't we simply replace all the hyphens with minus signs using string.gsub? That would be the simplest way of doing things. For more complex wikitext that might actually need to use hyphens in wikilinks etc. we could disable automatic hyphen replacement using a parameter or a new calendar method. — Mr. Stradivarius ♪ talk ♪ 16:47, 7 January 2014 (UTC)
It would be safer to only replace hyphens before a digit. There could also be a common function to format a potentially negative number, similar to {{Exprsign}}. If a calendar forgets to use the function then an occasional hyphen may be better than risking unwanted minus signs. PrimeHunter (talk) 17:11, 7 January 2014 (UTC)
  • I would prefer each calendar to format the negative numbers, and add spaces around dashes, rather than gsub the entire text to filter the hyphens. Start with the most-likely negative calendars, and others could wait until a later update. Retro-formatting of text almost always turns the "creeping featurism" into "featured creepyism". -Wikid77 17:23, 7 January 2014 (UTC)
  • Fair enough, and now done. Only numerical year input and year ranges are automatically formatted; years input as strings must now do the formatting themselves. The formatting is done by a new function "formatNegative" which only changes hyphens to minus signs if they appear immediately before a number. Michael Hardy, is that looking better? (If you don't see an update you might need to purge the page cache.) — Mr. Stradivarius ♪ talk ♪ 05:21, 8 January 2014 (UTC)
  • Looks good; thank you for your attention to this. Michael Hardy (talk) 23:24, 8 January 2014 (UTC)

Unable to click Discuss and go to the discussion

In the article Halite, I proposed that that article be merged into Sodium chloride and indicated where the discussion should take place by writing 'Discuss=Talk:Sodium chloride#Merge Halite into this article' and clicking Discuss still brings me to the beginning of the entire talk page instead of the section that the edit page indicated. I'm wondoering if it's anything to do with the fact that I changed halite to Halite in the section title before I proposed the merger. The Discuss link in the article Sodium chloride only takes me to about a section and a half before where it's supposed to take me. Blackbombchu (talk) 19:25, 7 January 2014 (UTC)

I've fixed Halite - the parameter should be named "discuss" not "Discuss". The link at Sodium chloride is working for me. -- John of Reading (talk) 19:51, 7 January 2014 (UTC)
Now they both redirect to a few lines above the title of the discussion section. Blackbombchu (talk) 21:53, 7 January 2014 (UTC)
The heading at Talk:Sodium chloride#Merge Halite into this article is near the end of the page. I guess your browser window simply doesn't have room to scroll further down. PrimeHunter (talk) 22:05, 7 January 2014 (UTC)

New template not really taking effect

I recently changed the navbox Template:Jasper Fforde, replacing one of the horizontal lines with a navbox subgroup template, following closely the Template:Navbox subgroup#Example of Protected Areas in Colorado. The new Template looks fine on its Template page, it looks fine when transcluded on the Jasper Fforde page, but on all the other pages where the Template is invoked, it shows up as the old Template, as if the old Template had been substituted back in the day. Of course, it hasn't been substituted. I changed the one on The Eyre Affair to explicit state=autocollapse, and that works, showing the new Template. I toyed around with the state line in the Template itself, even changing the state to match the actual Template:Protected Areas of Colorado, to no effect. I'm stumped. Choor monster (talk) 20:06, 7 January 2014 (UTC)

When a template is changed, the software makes a note that other pages need to change, but doesn't do it immediately - the "job queue". You can force a page to display the latest template by purging it. -- John of Reading (talk) 20:14, 7 January 2014 (UTC)

Link to a nonexistent article

The last section of my talk page says the page Wikipedia:Articles for deletion/Google Feedback doesn't exist but it does exist. Blackbombchu (talk) 21:55, 7 January 2014 (UTC)

You mean the link was red. I have purged your talk page so it updates and registers the page exists now. The poster used Twinkle which makes edits so quickly that MediaWiki doesn't always register the page was created a moment before. PrimeHunter (talk) 21:59, 7 January 2014 (UTC)
A similar glitch is happening with the Reportum link in Wikipedia:Articles for deletion/Reportum after I added a redirect from Reportum to Adverse Event Reporting System. There's no need for you to go an fix it if it's going to fix on it's own later. My real purpose in mentioning this technical issue is so that Wikipedia will change it's system to avoid that glitch on future links to Wikipedia pages. Blackbombchu (talk) 01:44, 8 January 2014 (UTC)
Whenever you see a redlink that should be blue (or a bluelink that should be red), the first thing to try is a WP:PURGE. If that doesn't fix it, try a WP:NULLEDIT, and if that doesn't work, WP:BYPASS. There's no need to being them to VPT. --Redrose64 (talk) 13:36, 8 January 2014 (UTC)

Typography refresh beta feature

Hi everyone,

This an update regarding the "typography refresh" beta feature, which is live on all wikis that have Beta Features available. The following changes I describe will be live on Thursday, January 9th.

The first version of the typography update certainly wasn't perfect, but the UX design team wanted to get it out there and see what people thought about some of the ideas included. Well, we've recevied a ton of feedback on the Talk page.

Changes made based on your feedback

Almost all of the feedback was constructive, and some showed a really keen understanding of the issues with typography on Wikipedia. Thank you to everyone who stopped by and left a message. Based on the feedback we got, we made the following changes:

  1. Reverted the size of the personal toolbar menu and lefthand sidebar back its previous size (.8em)
  2. Reverted the black/grey links in the sidebar and personal toolbar back to blue
  3. Reverted the width of the left-hand back to its previous width, to avoid line breaks in those links
  4. Increased the body content size to 1.1em. While we did not originally increase the body content size, we saw that many people brought up this idea, and we think it's a good strategy for improving readability. This also allows us to emphasize the main content more without decreasing the size of toolbar or sidebar links, etc.
  5. Increased the size of page titles and their line height
  6. Tweaked the whitespace between section/subsection headings and around blockquotes. We hope this version provides better balance.
  7. Reprioritized the font family CSS for headings, placing the free and open source variant "DejaVu Serif" first

Additional ideas we're trying out in this release

  1. Placing a maximum width on page contents of 715px. It is widely accepted that text columns with a line length which spans the entire width of a (desktop or laptop) screen are not ideal for reading/scanning.[42], [43], [44],[45] The max width will not apply to Special pages (like Prefences) or to actions on an article, like viewing history.
  2. Removing the border around thumbs, increasing the whitespace around them, and changing the text styling on thumbcaptions. Vector and Monobook styles are both overly reliant on border styles to demarcate page elements. Numerous borders, especially with right angles, increases cognitive load when scanning a page.
  3. Changing disambiguation and row links to have the same type as thumb captions.

Other things we have retained in the beta. For example, serif headings were a source of complaints, but were retained since one of the goals is consistency with the mobile skin for Wikimedia projects.

On behalf of the design team, Steven Walling (WMF) • talk 23:16, 7 January 2014 (UTC)

P.S. Best place to leave feedback is this discussion page, linked to from within the Beta preferences.

Can File:Lido EP.jpg be moved to English Wikipedia

I have tried everything that I can think of, but the "Upload" button for pictures on English Wikipedia file upload remains greyed out after I fill out every row of information. --Jax 0677 (talk) 16:36, 8 January 2014 (UTC)

this has often annoyed me too. When the commons image exists with the name it will not let you load over the top of it. I believe you have to use the old upload form special:upload. Graeme Bartlett (talk) 22:25, 8 January 2014 (UTC)
Or you could ask for it to be deleted off commons, as the image there is almost certainly out of policy as it would be used under fair use only. Graeme Bartlett (talk) 22:29, 8 January 2014 (UTC)
Reply - I tried to upload the file when there wasn't such a file on Wikipedia, but the Upload button remained greyed out. I therefore used the old English Wikipedia photo upload form. --Jax 0677 (talk) 22:39, 8 January 2014 (UTC)
@Jax 0677 and @Graeme Bartlett: Uploading a file to enwiki with the same name as a Commons file requires the reupload-shared permission, which is only given to administrators. jcgoble3 (talk) 01:12, 9 January 2014 (UTC)
Resolved - The issue has now been resolved. --Jax 0677 (talk) 01:14, 9 January 2014 (UTC)

"Image" display anomaly

I'm having a "file" problem that must be unique to me. I can't view:

log cabin

[[Image:Cjd P7160326.JPG|left|thumb|300px|log cabin]]

But I can view:

log cabin

(Dropped one parameter, 300 px). Both images are viewable by another editor. (We each thought the other was crazy and tried to get the other blocked for insanity!  :) I'm using Mozilla Firefox. Don't know what the other editor is using.

Any ideas? Thanks. Student7 (talk) 18:48, 7 January 2014 (UTC)

Sounds like a purge did not arrive at one of the caching centers. This happens at times and can be troublesome to recover from. A normal purge usually does not suffice. I have now, purged, regenerated the 300px image and purged the page again, which should bust the cache of the server in the caching center. If you bypass your browser cache is is visible for you now ? If it still isn't visible, please let us know, there might be a problem with all purges failing to reach one of the caching centers in that case. —TheDJ (talk • contribs) 19:12, 7 January 2014 (UTC)
Using IE8 I can see both log cabins. GoingBatty (talk) 20:01, 7 January 2014 (UTC)
Thanks TheDJ. "Windows F5" worked perfectly. So I don't contend with another valid edit, what should I do permanently?
(And thanks GoingBatty. I have reservations about IE). Student7 (talk) 00:55, 10 January 2014 (UTC)

Give Users Support

How could it be, that an user does not use preview, give no edit summary and does not sign for more than six years contributing to wikipedia. Compare Newest contributions 2014 >><< Oldest contributions 2007 Is it possible to create a tool to detect / filtersuch editors and give them a some help? > {{subst:uw-preview}} {{subst:uw-editsummary}}--Frze > talk 07:06, 8 January 2014 (UTC)

Huh? There's no requirement to use edit summaries or preview. The editor has signed their edits on a few occasions just at a quick glance (first two I clicked on): [46], [47]. Legoktm (talk) 07:10, 8 January 2014 (UTC)
Hah? Use template {{subst:uw-editsummary}} --Frze > talk 13:56, 8 January 2014 (UTC)

Edit summary needed

Information icon Thank you for your contributions to Wikipedia. Please make sure to include an edit summary with every edit. Please provide one before saving your changes to an article, as the summaries are quite helpful to people browsing an article's history.

The edit summary appears in:

Please use the edit summary to explain your reasoning for the edit, or a summary of what the edit changes. Thanks! Frze > talk 13:51, 8 January 2014 (UTC)

We have templates for all kinds of things. Edit summaries are encouraged but not required. Leaving them out has the side effect of making RecentChanges patrollers assume that you're up to no good. If you don't mind people being even more suspicious of your work, then you, too, may omit them. I don't recommend it, but you are permitted to make that choice. WhatamIdoing (talk) 16:59, 8 January 2014 (UTC)
Every now and then, there's a suggestion to make edit summaries mandatory. Here's the latest. Personally, I've opted-in by setting "Prompt me when entering a blank edit summary (or the default undo summary)" at Preferences → Editing. --Redrose64 (talk) 18:20, 8 January 2014 (UTC)
Wikipedia:Perennial proposals#Automatically prompt for missing edit summary. --  Gadget850 talk 18:24, 8 January 2014 (UTC)
I used to be this way, until it became apparent to me that no one cares about the 90% or so edits that I do, when the section link is all that's really necessary, and sufficient to get the point across, more so than a short "reply". TeleComNasSprVen (talk • contribs) 16:20, 9 January 2014 (UTC)

Login problem

OTRS received a request VRTS ticket # 2014010510006699 Is there someone comfortable with login problems who could help?. The person has asked for password reset, but it hasn't worked. She is now asking for a password reset to a new email address. This isn't my area of knowledge, but I thought such a thing would not work doesn't the password reset have to go to the address used to setup the name?--S Philbrick(Talk) 14:33, 9 January 2014 (UTC)

If she doesn't remember the email address associated with her account, or can no longer receive email at that address, I think that she is out of luck. There is no way for us to change the email address on her account, and for security reasons, that wouldn't be prudent, anyway. ​—DoRD (talk)​ 15:09, 9 January 2014 (UTC)
OK, thanks, I feared that was the case. I am writing to the user with other options.--S Philbrick(Talk) 16:19, 9 January 2014 (UTC)
wmf:Privacy policy says: "Users whose accounts do not have a valid email address will not be able to reset their password if it is lost. In such a situation, however, users may be able to contact one of the Wikimedia server administrators to enter a new e-mail address." I don't know anything about if and when this is done in practice. Presumably it would at least require good evidence of the user's identity. If "valid email address" is interpreted as one which originally worked then I don't know whether users who lost access to the address can get help. At the English Wikipedia we usually just tell users they have to create a new account if they cannot remember the password or retrieve mail at a stored address. PrimeHunter (talk) 16:59, 9 January 2014 (UTC)
In practice this is rarely done anymore, because proving your identity is thoroughly difficult and doing it for many people is a very resource intensive task. So basically for this procedure, you need to have a lot of edits to make it worth everyone's time and then either a {{User committed identity}} or subject yourself to a voluntary checkuser investigation and have some good proof of email identities and an acceptable story on why you lost your password that will pass sysadmin's criteria (those criteria are likely extremely high). Translated this means for 99.5% of users, no email means not recoverable by sysadmins. —TheDJ (talk • contribs) 17:20, 9 January 2014 (UTC)
Thanks for the information. I will continue to tell users to create a new account and not mention server administrators unless there are special circumstances like thousands of edits or a user right admins cannot grant (but then they probably have thousands of edits). PrimeHunter (talk) 18:05, 9 January 2014 (UTC)

A Multimedia Vision for 2016

Happy new year!

Many thanks to all of you who contributed to our multimedia programs last year! Now that we have a new multimedia team at WMF, we look forward to making some good progress together this year.

To kick off the new year, here is a proposed multimedia vision for 2016, which was prepared by our multimedia and design teams, with guidance from community members.

This possible scenario is intended for discussion purposes, to help us visualize how we could improve our user experience over the next three years. We hope that it will spark useful community feedback on some of the goals we are considering.

The best way to view this vision is to watch this video:


File:Multimedia vision 2016.webm
Multimedia Vision 2016, presented by Fabrice Florin at a Wikimedia Meetup in San Francisco on Dec. 9, 2013.


You can also view this five-minute video in other file formats on YouTube and Vimeo -- or browse through these annotated slides, at your leisure.

Multimedia Vision Slides

This vision explores ways to integrate Wikimedia Commons more closely with Wikipedia and other MediaWiki projects, to help you contribute more easily to our free media repository -- wherever you are.

After you’ve viewed the video, we would be grateful if you could share your feedback in this discussion. We would like to hear from all Wikipedians who benefit from Commons, even if your work takes place on other sites.

In coming weeks, we will start more focused discussions on some key features outlined in this presentation. If you would like to join those conversations and keep up with our work, we invite you to subscribe to our multimedia mailing list.

We look forward to hearing from you -- and to more great collaborations in the new year! Fabrice Florin (WMF) (talk) 01:01, 10 January 2014 (UTC)

Script for interactive chess board

Hello,

At Wikipedia_talk:WikiProject_Chess#Interactive_chess_board, I had suggested that we try and develop an interactive chessboard for usage on EnWiki, similar to how the Hebrew wiki articles have.

קיפודנחש (kipod), who had worked on the board on the Hebrew wiki, replied and has suggested a possible way to do this. But we would like more thoughts on how other editors think this should behave and whether it will be a good idea to have it as the default in mainspace in the future. (I think that is a very strong yes given how so many chess articles are dependant on the positions displayed in static diagrams instead of a board like this which would have take our articles' quality up a huge notch)

So what do other editors think of this and are there any changes we can do to make it better?

Regards, TheOriginalSoni (talk) 02:11, 3 January 2014 (UTC)

Sounds good. Will make chess-related articles more interactive and will be more hands-on informative. ///EuroCarGT 05:22, 3 January 2014 (UTC)
I'm saying the same thing as last time. Fine, but please just make it degrade nicely for people WITHOUT Javascript. And preferably in a way that doesn't make it look like a datadump. You could have a template include a reference to a page with pgn data and using Lua output a human readable 'simple' description of the game. Then the pgn viewer could detect this template with the hidden reference to the data page and load the pgn data for playback, partially or fully replacing the description. BTW. when it comes to these full games being included.. I find them as useless as episode listings without commentary. There should be a paragraph of text explaining the key moment of a game, the significance etc. Because Wikipedia is not a sport results site. So what i'm saying is, if I turn off Javascript on he:אליפות_העולם_בשחמט_2013 and it looks somewhat remotely like World_Chess_Championship_2013 instead of User:קיפודנחש/pgnviewer_demo, then it's a good solution. —TheDJ (talk • contribs) 10:10, 3 January 2014 (UTC)
this way of thinking is understood, but it shows some misunderstanding of the way chess games are regularly communicated: you say "human readable", but the whole point of pgn is that is *is* human readable. for example, please look at Pirc Defence#Sample games. (this is by no means unique - many chess articles contain similar sections). the idea here is that for people with no JS, the section(s) will continue to look more or less like this, and people with JS will see something like what you can see in User:קיפודנחש/pgnviewer demo when you activate the script User:קיפודנחש/pgnviewer.js. peace - קיפודנחש (aka kipod) (talk) 15:17, 3 January 2014 (UTC)
  • קיפודנחש (kipod), I think what TheDJ meant was that even for those without Javascript, there should be a particular chess position displayed rather than the full game. That way, the board still makes sense for those without JS. That was definitely one of the things I preferred TheOriginalSoni (talk) 20:27, 3 January 2014 (UTC)
TheDJ, TheOriginalSoni: i do not think the right way to do it is to try and train some Artifical Intelligence to decide which position is the best one to show from each game. I think that this should be left to the editor. it is possible to create a template that will consume the PGN of the games, and some more stuff, and will display the "more stuff" to users without JS. this can be done by utilizing a mediawiki feature which is currently not used on enwiki: Mediawiki:Noscript.css. what one needs to do here is to create several new CSS classes: one which will have "display:none" in common.css and then "display:inherit" (and maybe another which will have "display:block" and a third which will have "display:inline") in noscript.css, and then another class that will have "display:none" in noscript.css. this way, template authors will be able to define parts of the tempalte which are visible to people without JS
this may come in handy in other places: for instance, we use collapsible elements (i.e., elements with "show/hide" buttons) all over the place. these elements rely on JS to do their thing, and for user with no JS they are always in a "show" state. i can imagine some special cases, in which it would be better to completely hide an element in case the collapsing mechanism does not work.
i can not do all this things in the script or in a template - it requires edit rights in the mediawiki namespace, IOW, "editinterface" permissions. in enwiki, only sysops/admins have this permission (some other wikis created a usergroup that have the "editinterface" permission without being sysop/administrator). someone with these permissions needs to create the classes, and then we can look at creating a template that will support JS-less viewers more gracefully.
peace - קיפודנחש (aka kipod) (talk) 15:38, 4 January 2014 (UTC)
TheOriginalSoni: yes, though i can't guarantee to do this expeditiously - my wiki-budget is somewhat limited. also, if testwiki supports more restricted rights than "admin/sysop", which still contain "editinterface", this would suffice (some projects *do* have "editinterface" user group. i don't think enwiki is one of them. such a group makes a lot of sense for testwiki to have). peace - קיפודנחש (aka kipod) (talk) 14:50, 9 January 2014 (UTC)
  • קיפודנחש (kipod), Contact [48] on his talk page, who agreed to give you admin rights on test-wiki until you can finish testing this script out. Peace 15:56, 9 January 2014 (UTC)
User:TheOriginalSoni: did that. see the demo page on testwiki. קיפודנחש (aka kipod) (talk) 01:44, 11 January 2014 (UTC)

Are we not talking about a playable board? I think that having a fully playable game integrated into the article would be an enormous bonus. bd2412 T 20:48, 3 January 2014 (UTC)

  • bd2412, What we currently have is similar to what is already present in the Hebrew wiki articles. Is this what you wanted, or did you have something else in mind when you said playable? TheOriginalSoni (talk) 13:38, 4 January 2014 (UTC)
BD2412: you can see for yourself exactly what we are talking about: you need to add to Special:Mypage/common.js the following line:
importScript('User:קיפודנחש/pgnviewer.js');
and then, look at User:קיפודנחש/pgnviewer demo. peace - קיפודנחש (aka kipod) (talk) 15:38, 4 January 2014 (UTC)
I have seen the simulation on Hebrew Wikipedia. I'm talking about the ability to play an actual game of chess. bd2412 T 20:41, 4 January 2014 (UTC)
if you are talking about the reader playing a game of chess against the website/computer, i doubt this can be achieved through wikipedia infrastructure. even if it _was_ possible, i don't believe this is "encyclopedic content", so i do not think it's something appropriate for wikipedia - see WP:NOTGAMEHOST. peace - קיפודנחש (aka kipod) (talk) 21:15, 4 January 2014 (UTC)
(edit conflict) In which case, it's simple: we do not host games, chess or otherwise. --Redrose64 (talk) 21:16, 4 January 2014 (UTC)

Demo ready

so User:Technical 13 granted me admin rights on test wiki, and i created pgnviewer demo on testwiki. for the demo, i created "Teplate:Chess pgn viewer", which has a "no script" parameter, that lets the editor to define what the people who have JS disable will see. in the demo, i only included 3 positions from 3 of the games, but, of course, the editor can place anything she choose under the "no script" parameter. whatever it is, it's completely hidden from viewers with JS. view this page with JS enabled and then with it disabled to see the difference.

please test it, and play with it (i.e., copy the page and edit the copy to see what can be done). peace - קיפודנחש (aka kipod) (talk) 01:40, 11 January 2014 (UTC)

  • קיפודנחש (kipod), It looks pretty great. Could you hide the pgn for users without JS? Seeing all the PGN for all 9 games will probably not be preferable for non-JS users. TheOriginalSoni (talk) 15:19, 11 January 2014 (UTC)
TheOriginalSoni: the pgn _is_ hidden for users without JS, unless the editor chose to show it (i.e., the editor included some PGN in the "no script" parameter). sometimes, when enabling and disabling JS in the browser, it's possible that some stuff does not work as intended immediately. this is not a real problem: we want to solve the problem(s) for users with or without JS, and not necessarily for users who enable and disable JS rapidly. after either enabling or disabling JS, just execute "deep refresh" once to see how a reader with or without JS will see the page. i'll make a note about it on the demo page also. peace - קיפודנחש (aka kipod) (talk) 17:08, 11 January 2014 (UTC)

hilite template is partly broken

Last night I discovered a bug in a template. I don't know much about how templates work at their back end, so I didn't even try to fix it . The Talk page hasn't been touched in a year, so I figured anything I wrote there would not be noticed, and came here.

But the Village Pump page says this Technical section is "To discuss technical issues. For wiki software bug reports, use Bugzilla", so I went to Bugzilla and filed a detailed report (below).

This morning I got an answer there (also below), telling me to BE BOLD or go to the Talk page. Enough already. I'm done with it. --Thnidu (talk) 16:42, 9 January 2014 (UTC)


Bug 59855 - some examples in Template:Hilite/doc are broken

The hilite template doc page on Wikipedia, https://en.wikipedia.org/wiki/Template:Hilite/doc , has examples of five ways to parameterize the template (including null). The third and fourth, which should have pink and yellow highlighting respectively, have none. I am using a 13-inch, Mid 2011 MacBook Air with Mac OS X Lion 10.7.5 (11G63b). I discovered the bug in Firefox 26.0 and have replicated it in Chrome 31.0.1650.63 and Safari 6.1.1 (7537.73.11).

Examples

code output notes
{{hilite | text }} text
{{hilite | text | lightblue }} text
{{hilite | text | pink | 2011-01-01 }} text
{{hilite | text || January 1, 2114 }} text Note the color parameter, left blank, is still represented
with a pipe (followed by the expiration parameter pipe)
{{hilite | text | #00FF00 | 1 January 2015 }} text 
Comment 1 Andre Klapper 2014-01-09 15:01:07 UTC

Thanks for taking the time to report this!
Has this been brought up on
https://en.wikipedia.org/wiki/Template_talk:Hilite/doc ? 
Sounds like the more appropriate page to reach its developers (or [[WP:BE
BOLD]] by fixing the docs if you have time and expertise), as Bugzilla's
"Template" component refers generally to loading templates and not to specific
ones on specific websites (so I'm closing this as INVALID but only because
Bugzilla isn't a good place for this, not because the issue you report does not
exist). This should be fixed on-wiki instead.
@Thnidu: Please note how the documentation mentions an expiry functionality. Now guess how the date in your broken examples effect the color of the text :D I've reset the 4th example to a more distant date to show the effect. —TheDJ (talk • contribs) 17:01, 9 January 2014 (UTC)
I have tweaked the examples and notes further.[49] If you have problems using a template and have limited template knowledge then Wikipedia:Help desk is often a good place. Bugzilla is common for all Wikimedia projects and should rarely be used for problems with a template, since templates are edited locally at each wiki. PrimeHunter (talk) 17:51, 9 January 2014 (UTC)
Thanks TheDJ and PrimeHunter! --AKlapper (WMF) (talk) 22:06, 9 January 2014 (UTC)
YES, thanks! To TheDJ for the explanation, and to PrimeHunter for making it clear on the page. --Thnidu (talk) 22:32, 9 January 2014 (UTC)
Bugzilla is for drawing issues to the attention of the people who maintain the servers and write the wiki software (MediaWiki) that runs on them. Templates are written by Wikipedia editors, so problems with them should be dealt with by Wikipedia editors. If you don't know how to fix a template problem yourself, bring it here or to the help desk. – PartTimeGnome (talk | contribs) 20:48, 11 January 2014 (UTC)
You can also raise a thread at WP:WPT. --Redrose64 (talk) 21:40, 11 January 2014 (UTC)

Looks like Javascript is working sporadically

I just viewed one page, then went to another and found no javascript menus, no usual wikipedia menus on top. I've cleared my cache (Using Chrome ) and came here, it also showed no menus on top, however, when I went in to edit the menu's (all of them ) re-appeared again.

Anyone else experiencing this ?  KoshVorlon. We are all Kosh   19:16, 9 January 2014 (UTC)

The interface off looks like crap. There's no skin or JS. I've trying purging and clearing my cache but no luck.—cyberpower ChatOffline 19:19, 9 January 2014 (UTC)

(Merged two sections about the same issue) Yep. bits.wikimedia.org is being slow and sometimes failing. My watchlist loaded with absolutely no JavaScript or CSS. Somebody should ping the devs on Bugzilla. jcgoble3 (talk) 19:21, 9 January 2014 (UTC)
(seems to be) back to normal now. Jared Preston (talk) 19:25, 9 January 2014 (UTC)
(edit conflict) sometimes happens after version upgrade (we are on wfm9 now). try deep purging of browser's cache (what works best for me is hitting Ctrl+⇧ Shift+Delete (works on big-3 windoze browsers + big 2 on linux) and selecting "delete temporary files" or "clear cache" or whatever else your browser chooses to call deep cache-purging. for opera try "settings => delete private data") dunno how to do same on mac. after this, and a couple more ⇧ Shift+F5, everything should go back to normal. peace - קיפודנחש (aka kipod) (talk) 19:33, 9 January 2014 (UTC)

Interface (Typography refresh problem)

Tracked in Phabricator
Task T61815
Invalid

It's squashing content into the left 2/3rds of the screen for me, but not on Special: pages.--Gilderien Chat|List of good deeds 19:29, 9 January 2014 (UTC)

@Gilderien: The "2/3rds of the screen" is part of the latest revision of the "Typography refresh". I've just disabled this beta feature in my preferences. -- John of Reading (talk) 19:35, 9 January 2014 (UTC)
Same for me. Here's a screenshot. Marcus Qwertyus (talk) 19:46, 9 January 2014 (UTC)
i do not believe disabling "Typography refresh" is required. from what i see, if you perform aggressive refresh/purge cache, everything should go back to normal, even if you have "Typography refresh" enabled. peace - קיפודנחש (aka kipod) (talk) 19:49, 9 January 2014 (UTC)
Note that the content squashing is actually intentional, see mw:Talk:Typography_refresh#Additional_ideas_we.27re_trying_out_in_this_release. Legoktm (talk) 19:54, 9 January 2014 (UTC)
Yes, I posted this above at #Typography refresh beta feature. It is not be related to any lack of skin CSS or JS though. Steven Walling (WMF) • talk 21:41, 9 January 2014 (UTC)

Site Resolution for Wikipedia Articles

Is anyone having issues with the resolution on articles? (See image below) I first noticed this issue this morning (about 12 hours ago). Any ideas on how to fix this?

[Image deleted at uploader's request.]

Thanks, -- ТимофейЛееСуда. 00:15, 10 January 2014 (UTC)

See the section #Typography refresh beta feature above. They are testing out narrower articles (715px), as there is evidence this improve readability. I'm not so sure, personally. — Huntster (t @ c) 00:21, 10 January 2014 (UTC)
Oh dang. This is terrible. I don't know if I can still edit with the articles like this. Is there a way I can disable this? -- ТимофейЛееСуда. 00:23, 10 January 2014 (UTC)
Nevermind. I figured it out. Thats just yucky. Sorry for opening a new discussion. -- ТимофейЛееСуда. 00:26, 10 January 2014 (UTC)
It's good for mobile browser (using desktop view) but definitely bad for non-mobile device which has larger screen/resolution. -- Sameboat - 同舟 (talk) 01:36, 10 January 2014 (UTC)
See #Article alignment below. --  Gadget850 talk 16:03, 10 January 2014 (UTC)

Article alignment

Hello, logging onto Wikipedia today it seems that the layout/skin has changed so that all the text is squashed to the left (see this screenshot). It doesn't happen when I log out, or when I change skin. I'm currently using the Vector skin with Google Chrome. Any help would be appreciated. —JennKR | ☎ 15:37, 10 January 2014 (UTC)

You have Preferences → Beta features → Typography refresh enabled. I like it, except for the screen width, which is supposed to make it match the mobile display. You can disable the max width by adding this to your CSS:
.action-view #bodyContent {
  max-width: none !important;
}
--  Gadget850 talk 15:43, 10 January 2014 (UTC)
That's done the trick! Thank you very much! —JennKR | ☎ 15:46, 10 January 2014 (UTC)
See #Additional ideas we're trying out in this release for the reason for the 715px max width. --  Gadget850 talk 16:04, 10 January 2014 (UTC)

Collapsible navboxes broken

It looks like a recent change broke all of Wikipedia's collapsible navboxes. I'm seeing a lot of space to the right-hand-side of the boxes, but the outer border extends all the way to the end of the page. This happens whether the box is collapsed or not. Here are some screenshots: collapsed, uncollapsed. This doesn't seem to be connected to the typography update discussed above, as it happens even after I turn that feature off in my preferences. Does anyone know what changed to cause this? — Mr. Stradivarius ♪ talk ♪ 09:18, 10 January 2014 (UTC)

Update: This doesn't happen when I'm logged out or logged in to my alternate account, so it must be something in my settings. I'll have a go at tracking it down. — Mr. Stradivarius ♪ talk ♪ 09:31, 10 January 2014 (UTC)
It's the Nearby beta. It pulls in tablet.styles module, which has a rule to set navboxes to receive 'display:inherit'. This causes the effect you are witnessing. —TheDJ (talk • contribs) 09:33, 10 January 2014 (UTC)
Yep, I just found it. I can confirm that the issue goes away when I turn the "Near this page" feature off. — Mr. Stradivarius ♪ talk ♪ 09:37, 10 January 2014 (UTC)
It's also affecting {{collapse top}}, which uses the navbox class for some reason. — Mr. Stradivarius ♪ talk ♪ 09:52, 10 January 2014 (UTC)

I reported this to the team btw. here. —TheDJ (talk • contribs) 20:25, 10 January 2014 (UTC)

Visual impairment

I've heard that visually impaired editors commonly find blue on yellow easier to read than conventional display. Do we/could we have options that enabled this in people's monobook and vector css or better still preferences? ϢereSpielChequers 11:13, 10 January 2014 (UTC)

if you want to create a CSS definition that will work well, it's very easy to make a gadget, selectable from preferences, that will load it. peace - קיפודנחש (aka kipod) (talk) 23:34, 11 January 2014 (UTC)
Eg. we do already have MediaWiki:Gadget-Blackskin in Special:Preferences#mw-prefsection-gadgets, which uses MediaWiki:Gadget-Blackskin.css if you have Monobook active. –Quiddity (talk) 23:58, 11 January 2014 (UTC)
I think we could do a lot more to help visually impaired, and colour-blind editors (and readers). I left some collated links/notes on the latter, at mw:Talk:Accessibility#Colour-blindness links and notes. See also the thread/link directly above that. Beyond that - ie. what to do next, and what to prioritize, and how many options are wanted/needed - I'm not sure. –Quiddity (talk) 23:58, 11 January 2014 (UTC)

This link opens my printer. Help?

This link It's a nice page, but its opening my printer as if I pushed Ctrl-P. Annoying! Can other people check it with other browsers to see how common this is please? I'm using Iceweasel on Linux. Ideally, I'd like to reformat it so it stops doing that...  The Steve  14:09, 11 January 2014 (UTC)

"drucken" means "print", so it's not surprising. When I googled for the first line, I found this link which works better. -- John of Reading (talk) 14:27, 11 January 2014 (UTC)
Cool, thanks. Guess I should have thought of that... The Steve  15:02, 11 January 2014 (UTC)

Source code glitch

I saved a page with the exact same source code more than once and it didn't give the same result every time. See the file description for more details. Blackbombchu (talk) 19:51, 11 January 2014 (UTC)

(file)
That 'weird' text was caused by a space before the sentence, which you removed when you retyped the paragraph. — Edokter (talk) — 19:57, 11 January 2014 (UTC)
You can see how your two edits differ by looking at the diff. You can get to this using the history tab, then clicking "prev" next to your 2nd edit. See Help:Diff for more information on using diffs. – PartTimeGnome (talk | contribs) 20:38, 11 January 2014 (UTC)
I can't do that because that article doesn't exist anymore because it was merged into 2013 Central and Eastern Canada ice storm, unless I search Toronto blackout (2013) which redirects me to 2013 Central and Eastern Canada ice storm then click the article I was redirected from then view its history. Blackbombchu (talk) 20:49, 11 January 2014 (UTC)
When you are redirected, you should see "(Redirected from Toronto blackout (2013))" under the page title. Click this to view the redirect itself, then click the history tab. Your edits are still there – they were not deleted when the article was replaced by a redirect. – PartTimeGnome (talk | contribs) 21:00, 11 January 2014 (UTC)
I think that acording to the proper answer format, you're supposed to use 1 colon if you're answering me and 2 colons if you're answering Edokter. Blackbombchu (talk) 20:51, 11 January 2014 (UTC)
I've fixed the indentation. – PartTimeGnome (talk | contribs) 21:00, 11 January 2014 (UTC)

How long does the average reader spend looking at a Wikipedia article?

Is there a tool that tells me this for individual articles or for en.Wikipedia articles in general? --Anthonyhcole (talk · contribs · email) 22:13, 6 January 2014 (UTC)

No. Wikipedia does not record when a user leaves a page or the site, so we can't know how long they were reading. – PartTimeGnome (talk | contribs) 02:40, 7 January 2014 (UTC)
Yeah; it wouldn't really be possible to track anyway. There's no 'reading a page' period - you make a GET request, you retrieve the page, it lives in your browser until you close the window and (short of active connections maintained between the site and the client, or further requests from the client) there's no further interaction. Ironholds (talk) 04:05, 7 January 2014 (UTC)
OK. Thanks. It would have been nice to know what proportion of readers stays on a page long enough to read more than the infobox and lede. --Anthonyhcole (talk · contribs · email) 04:27, 7 January 2014 (UTC)
You could probably do something with the "onunload" hook, but 1. it would only work for people with JS enabled, 2. people could submit false data, 3. it would be a huge invasion of privacy. πr2 (t • c) 18:47, 7 January 2014 (UTC)
  • Average pageview measured in seconds before next page: This topic has been discussed before, and the average duration was so short it seemed time unlikely to read more than one paragraph before then viewing another webpage. I have asked Jimbo, for longer discussion there (see: "User_talk:Jimbo_Wales#How long average reader views a page"). -Wikid77 17:23, 7 January 2014 (UTC)
    Any idea how this data was gathered? I can only assume it was an opt-in study over a small sample of people; I'm pretty sure the WMF would not allow such tracking of readers without their permission. – PartTimeGnome (talk | contribs) 23:03, 7 January 2014 (UTC)
    Maybe something like this or mw:EventLogging. πr2 (t • c) 03:05, 8 January 2014 (UTC)
Perhaps average pageview duration was a simple calculation of total pageviews per month divided by number of unique usernames/IPs per month, to split the month into seconds per pageview per user. -Wikid77 21:09, 8 January 2014 (UTC)
I don't think I understood that properly. Page views per month divided by unique users per month gives page views per user. It doesn't give any hint how much time was taken per page view. – PartTimeGnome (talk | contribs) 18:38, 11 January 2014 (UTC)
Thanks, πr2, some interesting reading there. I'm convinced now that the WMF wouldn't have any problems using a similar system to track time spent reading articles without consent. The first link you gave also answered my question: the WMF have previously measured this using comScore, which is an opt-in system. I'm not sure of the exact method of counting they use, though (e.g. do they look at how long the page is kept open? how long it is the active tab? exclude when the screensaver is on?). That page doesn't actually mention what the average reading time is, though it does say the average plus 3 standard deviations is 24 minutes. – PartTimeGnome (talk | contribs) 18:38, 11 January 2014 (UTC)
I'm not familiar with that particular research, but you could try looking in the page's history and asking one of the authors. πr2 (t • c) 05:01, 12 January 2014 (UTC)
I quite frequently come upon an article I think I could improve, and might have time "later that day" or tomorrow. I will just leave that page open in one browser tab, and continue my current work in other browser tabs. That means the article is open, but I'm not reading it. We're asking for technical data to give us information on human behaviour. There may not be a great correlation. HiLo48 (talk) 03:22, 8 January 2014 (UTC)
Agreed. That's partly why I asked how the data was collected, since I wondered if anything had been done to account for factors like that. I often open multiple tabs, and often go elsewhere for hours at a time with browser tabs left open. – PartTimeGnome (talk | contribs) 18:38, 11 January 2014 (UTC)

Raging thanking dragon

Tracked in Phabricator
Task T61807

Sending "thanks" now redirects to a separate page that requires yet another confirmation. What is this?? Why do I need to 'confirm' that I want to thank an editor?? Is this system of positive feedback being 'abused' by some hideous thanker of excess?If we want users to use this system, it has to be easy to use; redirecting to a separate page with yet another button and system is ridiculous, and in terms of usability deprecates one of the only features that promotes positive feedback between editors. Am increasingly dissatisfied with the way Wikipedia changes around me with no easily-accessible consultation or notice. LT910001 (talk) 23:44, 7 January 2014 (UTC)

I think it's because it's so close to the "undo" link that if you're not careful when going for "undo" you might hit "thank" by mistake, and so give the opposite impression to what you intended (hey! I'm so glad that you inserted "poop" into this page!) --Redrose64 (talk) 23:56, 7 January 2014 (UTC)
I've opened a bug report to request that a preference be added. Jackmcbarn (talk) 23:56, 7 January 2014 (UTC)
The confirmation was added because people kept 'thanking' people for edits when they meant to undo them. I believe that the day after the confirmation step was added, completed thanks dropped by a quarter and complaints about people mis-thanking dropped to zero. I'm certainly very happy about this, since I made that mistake several times.
But I've not heard of it redirecting people to another page. It normally has a small pop-up. You click twice: 'Thank' and 'OK'. The confirmation step adds about an extra three seconds. It doesn't strike me as unreasonable. WhatamIdoing (talk) 05:28, 8 January 2014 (UTC)
Depends if you have JavaScript enabled. --MZMcBride (talk) 22:32, 8 January 2014 (UTC)
Also, if you click the "thank" link before the page has fully-loaded (as I managed to do a few days ago) it will take you to Special:Thanks (with the revision number filled in properly) instead of triggering the pop-up confirmation box. –Quiddity (talk) 21:15, 9 January 2014 (UTC)
The behaviour described (redirecting to another page) is what happens with JavaScript disabled (or if JavaScript has failed, not yet loaded, etc). This is fairly new (deployed 2 January, I think). Before this, clicking thanks without JavaScript did nothing at all. I'd say this change is a definite improvement. See also bug 49161 and Tech News 2013-51. – PartTimeGnome (talk | contribs) 19:18, 11 January 2014 (UTC)
Ah, thank you PartTimeGnome. I was quite confused as to why I was getting a separate page. --LT910001 (talk) 02:10, 12 January 2014 (UTC)

Navboxes on ro.wiki

The below was originally posted under Collapsible navboxes broken. I've split it out as it is unrelated to the original problem raised there. – PartTimeGnome (talk | contribs) 22:47, 11 January 2014 (UTC)

I have a similar problem on ro.wiki. I created template Navbox-test (copy of Navbox). It uses ro:Module:Navbox (+ ro:Module:HtmlBuilder and ro:Module:Navbar). Everything in them are copied from enwiki, but result is not the same - navbox is broken. See here an example ro:User:XXN/teste2. How you can see the 3 buttons: view, talk and edit template - are not at their place, and when i collapse template it retracts in upper-left corner. What is the problem? XXN (talk) 23:15, 10 January 2014 (UTC)

That is becouse ro.wikipedia does not have the same CSS rules - in ro:MediaWiki:Common.css - as the english wikipedia does. For that specific problem, the code below is missing in ro.wiki's Common.css. Ideally, though, you should copy the navbox, navbar, hlist and plainlist CSS rules from enwiki's common.css and either add them to Common.css on ro.wiki yourself - if you are an administrator on ro.wiki - or ask an administrator on ro.wiki to do it for you.
.navbox-inner,
.navbox-subgroup {
    width: 100%;
}

--Snaevar (talk) 00:29, 11 January 2014 (UTC)

Thank you Snaevar. Unfortunately i am not admin.
Is here any global sysop to help solve this promlem? Our local sysops are not receptive to my proposals.XXN (talk) 14:19, 12 January 2014 (UTC)
Global sysops are called Stewards. They won't help, though – they don't use their admin rights on wikis with active admins except in an emergency. You're only option is to convince your local admins. Possibly look into the decision-making and dispute resolution processes available on ro.wiki; I don't know much about them. – PartTimeGnome (talk | contribs) 21:58, 12 January 2014 (UTC)
But we have another group of people exactly for this purpose Global edit interface editors. Editors who specifically deal with JS/CSS and MediaWiki/Template/Module namespaces on wiki's where local sysops might not have the required knowledge to get things like this done. —TheDJ (talk • contribs) 22:22, 12 January 2014 (UTC)
Thank you, TheDJ. I′ll try ask them for help. XXN (talk) 12:10, 13 January 2014 (UTC)

Infobox horseracing personality broken

The below was originally posted under Collapsible navboxes broken. I've split it out as it is unrelated to the original problem raised there. – PartTimeGnome (talk | contribs) 22:47, 11 January 2014 (UTC)

  • All the inboxes for {{Infobox horseracing personality}} have had a major parameter collapsed when it's not the default, and there is no "show" option to uncollapse them. See, e.g. Rosie Napravnik. It's not in the history of that template, so must be some parent set of templates, but it's not happening everywhere. Earlier, someone broke everything at Infobox person, but that was fixed. Who is screwing around with these parameters and where? Montanabw(talk) 23:50, 10 January 2014 (UTC) Never mind, this has been fixed. Montanabw(talk) 04:23, 11 January 2014 (UTC)
Somebody managed to break all the infoboxes by making a rather strange test edit to {{infobox}}. --Redrose64 (talk) 15:26, 11 January 2014 (UTC)
yeah, there were a couple other issues, but they got fixed, so all is well! Montanabw(talk) 01:34, 13 January 2014 (UTC)

Wikilink of persons preferred name

Actor J.P. Manoux spells his name without a space between the initials. While J. P. Manoux redirects to J.P. Manoux, there are many articles with the non-preferred spelling. Is there a bot or tool that can be used to fix these? NE Ent 23:21, 11 January 2014 (UTC)

 Done I'm working it for you right now with WP:AWB. VanIsaacWS Vexcontribs 23:49, 11 January 2014 (UTC)
I've also tagged the redirect with {{R from misspelling}}, which will encourage editors who work on Wikipedia:Database reports/Linked misspellings to fix links in the future. GoingBatty (talk) 04:22, 12 January 2014 (UTC)

Ping2

I have written {{Ping2}}. Distinction of this template and {{Ping}} is, other than it being in Lua, that if your '/noping' subpage exists, your pings are not displayed: instead, they are hidden using CSS. You still get notifications in the notification centre. The rationale is backward compatibility with old times when discussions did not contain linked usernames that much.

Feedback? Thoughts? Thanks. Gryllida (talk) 05:42, 12 January 2014 (UTC)

Script error: No such module "Ping2".
It seems to misformat the content after the ping2 template...
More testing required! ;p
Also, is the "/noping" functionality documented anywhere? Or is this also something new that you created for this template's usage? Thanks. –Quiddity (talk) 20:01, 12 January 2014 (UTC)
@Quiddity: Fixed. The /noping is something new, I only documented it at the template /doc subpage. Gryllida (talk) 20:11, 12 January 2014 (UTC)
Since it's written in Lua, why doesn't it support more than 5 usernames? But the noping thing is going to cause trouble if this gets any sort of use, considering that mw.title.new is expensive (and therefore can only be used 500 times per page, or fewer if other things on the page are also using expensive functions). Anomie⚔ 20:07, 12 January 2014 (UTC)
@Anomie: Subst it. Gryllida (talk) 20:11, 12 January 2014 (UTC)
Script error: No such module "Ping2". [50] — I edited it to complain about substing.. Gryllida (talk) 20:38, 12 January 2014 (UTC)
Just type them manually in the {{{N|}}} format in the template source code, and Lua will process as many as you like. Gryllida (talk) 20:38, 12 January 2014 (UTC)
Lua can read the parameters passed to the template directly (using frame:getParent). This technique allows any number of parameters to be read, which I think was Anomie's point. Passing them in {{{N|}}} format from the template puts a fixed limit of N on the number of parameters.
The template does not subst properly – it's outputting {{#invoke:Ping2|...}} followed by a line break. This still calls your Lua script, so is almost as resource-intensive as if subst had not been used. I suggest adding a {{{|safesubst:}}} to the #invoke call. Furthermore, the line break after the #invoke call is probably what's causing the formatting issue seen by Quiddity; remove it. – PartTimeGnome (talk | contribs) 21:45, 12 January 2014 (UTC)
I have already fixed that by removing line breaks in the template itself. The template is substituted, so his message shows up with a problem. Thanks for the note about number of arguments, I will try to implement it. Gryllida (talk) 01:40, 13 January 2014 (UTC)
OK, the indent is broken again. Gryllida (talk) 01:53, 13 January 2014 (UTC)
I have fixed it, including unlimited number of arguments, except requiring subst ({{require subst}}); this bit is unreadable to me. Gryllida (talk) 02:14, 13 January 2014 (UTC)

"Display a floating alert when I have new talk page messages" gadget might need updating

Talkpage message indicator

Hi, this is a friendly notice that Echo's orange new talkpage message indicator will in the future be visible for users with JavaScript disabled, and therefore the gadget that replaces it with a bigger orange bar might require changes to continue working properly. (This has actually been requested here in the past.) See T58974. I think the change will happen on Thursday, 30 January 2014, per the roadmap. You will probably also want to change the part that takes about JavaScript on Wikipedia:Notifications/FAQ about then. Matma Rex talk 15:25, 12 January 2014 (UTC)

Thank you very much to Legoktm for implementing this! I look forward to seeing orange talk page indicators once more. – PartTimeGnome (talk | contribs) 21:10, 12 January 2014 (UTC)

Tech News: 2014-03

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

You can read a recent blog post about how Tech News is put together, translated and sent to you across wikis each week.

Recent software changes

  • The latest version of MediaWiki (1.23wmf10) was added to test wikis and MediaWiki.org on January 9. It will be added to non-Wikipedia wikis on January 14, and all Wikipedia wikis on January 16 (calendar).
  • Searching in the File: namespace on Wikimedia Commons may be slow due to a search engine issue. [51]

VisualEditor news

  • VisualEditor will be added for all users on several Wikipedias on January 13. [52]
  • You can now add and remove __NOTOC__, __FORCETOC__ and __NOEDITSECTION__ in the page metadata menu. [53] [54] [55]

Problems

  • For a few hours on January 6, it was not possible to edit pages using the Translate tool on Wikimedia Commons and the Wikimania 2013 wiki, due to a settings error. [56] [57]
  • For about 20 minutes on January 9, there were problems with CSS and JavaScript due to high server load.

Future software changes

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

09:33, 13 January 2014 (UTC)

stats.grok.se

December 31 pageviews

The pageview tool seems to have either gotten interrupted or was subject to partial data. I need help figuring out which it was. From what I can tell there must be some process that runs through WP pages alphabetically. Somewhere between Tim Hardaway, Jr. and Tory Burch, the process did not run for December 31. Either the underlying data was not available for the end of the alphabet or they were not compiled. Can someone tell me whether the underlying data exist for the underlying data.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 04:31, 2 January 2014 (UTC)

It's the Y2K+14 bug I've been trying to raise the alarm about! Now don't you wish you'd listened to me??? EEng (talk) 05:14, 2 January 2014 (UTC)
  • Estimate the missing 31-December data: Since the stats are complete for pages "A"-"TNZ", then until the database is fixed (during the next few days), perhaps treat the partial day's stats in "To"-"Zzz" as an estimate for 31 December as either the pageviews from 30 December, or 17 December (2 weeks prior), or the average: (30Dec + 17Dec)/2. After "To" there is some partial data, such as "Toy" from 472 to 3, or "Tow" 72 to 5, or "TS" 114 to 76. -Wikid77 13:03, 2 January 2014 (UTC)
It looks like it's just a problem with the stats.grok.se site:
alexz@tools-login:~$ zgrep -F "en ZZ_Top " pagecounts-20131231-080000.gz
en ZZ_Top 52 1578087
-- Mr.Z-man 15:29, 2 January 2014 (UTC)
Either you are showing me something that suggests ZZ Top got 1.578 million pageviews or 52 pageviews in the 8:00 hour on December 31 according to the underlying data. I will assume it got 52 pageviews that hour. So something is not compiling correctly starting at some point in the alphabet between Tim Hardaway, Jr. and Tory Burch. Starting at "TO" there is minimal data according to User:Wikid77. I'll be watching here for confirmation that the database has been corrected.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 19:18, 2 January 2014 (UTC)
Yes, it's 52. The second number is the total number of bytes sent (I'm not sure why that's included in the data). Mr.Z-man 02:48, 3 January 2014 (UTC)
Having not run since the 1 January, it seems it tried to run for yesterday and most are complete but I've found a few that are missing. Blethering Scot 19:11, 6 January 2014 (UTC)
I am fairly certain that January 5 results are only about 25% of the daily totals.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 19:17, 6 January 2014 (UTC)
It looks like the underlying data does not exist after 5 AM and extending well into the 6th. All dates are now caught up except for December 31 (TO-ZZZ).--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 16:24, 10 January 2014 (UTC)

stats.grok.se support

The help page for stats.grok.se (which we link to from all sorts of places, for example DYK notificiations) directs people to User talk:Henrik, but that's littered with people pointing out that User:Henrik doesn't answer queries there. Should we be providing the equivalent service from a WMF server?

[FYI, The issue I wanted to raise is that, on, for example [63], it says "Magistrate of Brussels has been viewed 57 times in 201401.". But that doesn't include today's visits (the article was under DYK on the main page today). Better wording would be something like "As of 4 December 9013, Magistrate of Brussels has been viewed 57 times in 201401."] Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:06, 5 January 2014 (UTC)

I think a couple of years back there was talk about Wikimedia finding another service for stats. What happened to that idea, I wonder? Henrik will often fix things if you email him. But posting on that talk page goes nowhere fast. And there seems to be many breakdowns of the stats. — Maile (talk) 01:32, 6 January 2014 (UTC)
I think we need to consider rebuilding the tool with more capabilities.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 18:23, 6 January 2014 (UTC)
There is definitely a problem with it. For example this only records the stats of 5 January and not the days before or after it (including one when it was on the main page as a DYK). The C of E God Save the Queen! (talk) 20:33, 7 January 2014 (UTC)
How do we start the process of getting a replacement to the current tool?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 05:57, 9 January 2014 (UTC)
Find a volunteer to write the replacement, or write it yourself. WMF Tool Labs can host it. For finding someone else to write it, I don't know if there's somewhere specific to find tool developers, though this page is a good place to find technically-minded users. – PartTimeGnome (talk | contribs) 20:25, 11 January 2014 (UTC)

Page traffic counter is sick

The counter has been down for a quite a few days now. There's no information as to whether 2 Jan figures are going to melt into the ether, lost forever. And no indication of whether the system is up and running properly now.

Would it not be better for the WMF to take over this facility formally? It's a very important facility. Tony (talk) 02:54, 10 January 2014 (UTC)

There is no data for the 6 Jan as it skips from 5 to 7. Then again there is nothing for 8 either.Lihaas (talk) 04:25, 10 January 2014 (UTC)

All of a sudden, January 1–3 & 7 ran. December 31 (TO–ZZZ) and January 6, 8 & 9 remain a mystery and January 5 only seems to be about 25% of the data.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 04:38, 10 January 2014 (UTC)
There is definitely something wrong with it, I do agree that WMF probably should take over it so we can potentially minimize the disruption. for example, in this article, the 6th of Jan doesn't exist! The C of E God Save the Queen! (talk) 10:37, 10 January 2014 (UTC)

The raw data used to compute these things is generated by the WMF. This is what Henrik uses, what I use for WP:5000, and virtually all other statistical page view functionalities of which I am aware. I will note that something broke spanning Jan. 5 and Jan. 6 2014 (UTC). Otherwise, it has been quite stable for some time. West.andrew.g (talk) 16:03, 10 January 2014 (UTC)

West.andrew.g, thanks for the explanation about Jan 5/6. Can you tell me why December 31 was left incomplete for the TO–ZZZ portion of the alphabet. Also, what do you know about the dates listed at User:Killiondude/stats#Are_there_known_dates_for_which_complete_sets_have_not_been_compiled_although_the_data_seems_to_be_available?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 16:22, 10 January 2014 (UTC)--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 16:22, 10 January 2014 (UTC)
All went through as planned with my processing script on Dec. 31, so there does not seem to be a fundamental problem. I cannot comment on what might have happened with Henrik's script . Henrik's tool is known the be imperfect in some ways. I can't account for all those dates listed (my storage began sometime in 2010), but it did used to be a far more buggy process than it is now. West.andrew.g (talk) 18:28, 10 January 2014 (UTC)
I guess my question is whether the numbers posted on Henriks page are final or whether they can ever be compiled to include December 31st for the end of the alphabet?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 20:56, 10 January 2014 (UTC)
West.andrew.g, I am asking you.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 14:37, 12 January 2014 (UTC)
I can't answer that question. It would be simple to reprocess if the bug is found (I assume a single line had some weird encoding; or maybe it was just that the machine lost power) and Henrik or a tool admin re-fires the code. The raw statistical data is stored for perpetuity. It's my understanding that getting a hold of Henrik might be the hard part, though. West.andrew.g (talk) 23:07, 12 January 2014 (UTC)

Page-views

Hi there. I don't know if I am posting this in the right place, but I am sure that someone here you'll be able to send it to the right place. Is anyone here aware of these problems? The page-views Stats Grok is out order since early 2014. This is an important data information and I still don't get why WMF simply don't put it running in order and, so, we are still depending on unstable server and scripts. Regards, 177.148.179.211 (talk) 23:42, 9 January 2014 (UTC)

As I understand it, that's a private website run by a private individual. WhatamIdoing (talk) 01:16, 10 January 2014 (UTC)
So, thats another question. Its a important and very desirable information. Why we still depend on "private website run by a private individual" to get it? Come on, WMF guys, bring us the Page-views data back! 177.148.179.211 (talk) 03:55, 10 January 2014 (UTC)
Hi. See #stats.grok.se. Many things are provided by volunteers (bug fixes, tool/scripts used for editors, etc.). I actually prefer things that are run by (active) volunteers vs. the WMF getting involved. It's lamentable that Henrik's tool is erratic lately, however. Killiondude (talk) 22:35, 10 January 2014 (UTC)

Potential replacement

de:User:Hedonil has developed a tool on Labs that may be able to serve as a replacement. It doesn't currently have much historical data (only going back to September 2013), but it should hopefully be more reliable as it's run by a more active user. http://tools.wmflabs.org/wikiviewstats/?page=Example&lang=en&project=wikipedia Mr.Z-man 16:27, 10 January 2014 (UTC)

Thanks @Mr.Z-man:. Looks like a nice tool, however a comparison of a few pages stats show the newer tool comes out with a higher figure. Not sure whether thats because Henrik's tool discounts something or there is something else causing that, only checked out on two pages but with a variety of dates.Blethering Scot 16:47, 10 January 2014 (UTC)
Im wondering if it's redirects or something like that causing higher number of stats. Also what was interesting was if you run American Psycho (musical) on that tool it displays every days stats but adds a note that stats.grok.se was missing at least one day and page stats are lower by 1075. Thats useful buts different to the normally higher figures as doesn't display on all pages when data isn't missing on the other site. States uses dumps-wikimedia.org to get data but appears to check stats.grok.se to see if its missing data, can only assume tool was created for the basis of problems were having.Blethering Scot 17:26, 10 January 2014 (UTC)
The new tool is more powerful. You can click on a day and see the hourly totals. You can also see the current day partial totals. Can this tool be set to run over the historical datafiles to backfill its data?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 17:56, 10 January 2014 (UTC)
Its far better i agree, but whats accounting for the higher day to day figures. Also i cant link to a specific page's stats i.e. Kinky Boots (musical) it gives you a ? in domain name not the title of the search.Blethering Scot 18:51, 10 January 2014 (UTC)
Yes an explanation for the higher totals would be appreciated.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 20:57, 10 January 2014 (UTC)
He has explained in detail to another user on his talk page. Seems stats.grok.se is on average 10% lower.Blethering Scot 23:13, 10 January 2014 (UTC)
Victoria's Secret Fashion Show is one where stats.grok.se is 50% higher.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 23:28, 10 January 2014 (UTC)
Seems against the norm but all you can do is ask him. Seems pretty responsive.Blethering Scot 23:33, 10 January 2014 (UTC)
The translation tool that I used did not make it clear to me what the difference was. Does anyone understand it. How can some pages be slightly higher and others be significantly lower?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 09:26, 11 January 2014 (UTC)
Blethering Scot, u say "He has explained in detail". I don't see that. Am I translating the wrong thread. Which thread were you talking about?--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 14:41, 12 January 2014 (UTC)
To be fair, stats.grok.se is treated as an "authoritative" source only because it's been around longest. As there aren't really any official stats to compare to, there's no real way of knowing which one is more accurate. As long as they're generally consistent, it's probably as good as we're going to get. If one tool shows views for an article increasing over time and another shows them decreasing, that would be more of a cause for concern. Even the raw data is not always accurate. Unfortunately, despite high community interest in this, it's not something the WMF seems to be highly prioritizing. Mr.Z-man 00:27, 13 January 2014 (UTC)
I like this as a replacement. I have inquired about whether it can be backfilled from the datafiles going back to 2007.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 00:35, 14 January 2014 (UTC)
  • The guy seems to speak English, but he is ignoring my query. Does anyone speak German. I posted a question on the guy's talk page that has gone unanswered.--TonyTheTiger (T / C / WP:FOUR / WP:CHICAGO / WP:WAWARD) 00:23, 16 January 2014 (UTC)

Proposal : creating an automatic alert for invalid usernames upon new account creation?

Hello Wikipedia Team...great job !

Just an idea : basing on my personal experience, it can be sometimes harsh to make one's first steps as a new contributor (despite the fundamental principles :"Assume good faith" and "don't bite newcomers"...). So here is a small suggestion for Wikipedia's great platform to still improve in conviviality-and especially indulgence towards newbies.. !

(I hope I am addressing the right recepient!)

I would like to suggest that action is taken preventively, so that new users don't infrige the policies and get blocked right after their very first contribution (for instance on ground of invalid username).

Couldn't it be done simply by the same automatic programm responsible for the block? Let it notify the user beforehand that the account he is creating contains words that are likely to result in a block, such as Society, Foundation, Group, etc...

This would prevent the blunt barring a posteriori of good willing contributors, who just wished to contribute to the common knowledge. This type of proactive action is applicable to other domains of course.

For further reading, here is my short story: I assembled material, with the help of a few friends, to create and expand some articles that we thought interesting and missing on Wikipedia. It took us a few days to carefully complete the work (although we are well aware it is still highly perfectible). Putting the first part of the work online, as a token of consideration for my collaborators, I created an account with the name of this (unformal) group. No promotional purposes in that ! (This association is totally non-profit, its goal is mainly to raise public awareness about the environment on a tiny island in the Aegean).

BAM : blocked !

I realize I did unwittingly infrige Wikipedia policy, that is clearly specified. I apologize and wish to correct this. But please consider that Wikipedia's guidelines, policies and regulations span over dozens of pages, making it difficult for newcomers to absorb them all at once.

I suppose most contributers are like us, regular users of Wikipedia who simply wish to contribute to the common knowledge in their turn, in good faith...Assuming that sticking to the Five Pillars is fair enough. Be bold, they say ! So the blunt barring of a user- for an easily remediable problem - seems somewhat brutal. How could it be a motivating pedagogy ?


Still, congratulations for the remarkable achievement of Wikipedia and thank you for this worldwide epistemic adventure.

Lonaïs

Velanidia Foundation (talk • contribs) 14:37, 6 January 2014 (UTC)

@Velandia Foundation: FYI, the process for checking usernames is not automated, it is an editor based process. But yes you are right that it the terminology is somewhat 'scary'. In this case I would personally suggest we use the term 'locked account' instead of 'blocked account'. The technical result is the same, but it's less offensive to people I think . Also User:Steven (WMF) has promised in the past that there would be further improvements to the Create Account page that would give users more feedback/instructions about the usernames and passwords while you type them. This functionality had been held back for deployment a couple of months ago, but is still planned I think. Thank you for your feedback and please be free to point out any similar problems that you encounter. —TheDJ (talk • contribs) 15:22, 6 January 2014 (UTC)
We already use the term "locked account" for accounts that can't even be logged in to. How would we differentiate between these situations? Jackmcbarn (talk) 16:37, 6 January 2014 (UTC)
TheDJ misspelled @Velanidia Foundation: above. See meta:Global locks for the normal meaning of locked account. I think it would cause confusion to have two terms for blocked accounts, also if the terms aren't used for other things. I don't think the poster complains about the word blocked, but about being blocked so quickly. PrimeHunter (talk) 16:57, 6 January 2014 (UTC)
BTW, one of the reasons we block group usernames is because a user account should only be controlled by one person, and a group name gives the impression it is not. It's not just concerns about promotion. – PartTimeGnome (talk | contribs) 01:49, 7 January 2014 (UTC)
  • I actually have no objections to adding "confusing" or "ISU" objective words in the Titleblacklist (assuming they are not already there). Things like bot, sysop, reviewer, society, group, etc... They few edge cases of these being allowed would still be able to be created by request through account creation interface/process. Technical 13 (talk) 18:06, 6 January 2014 (UTC)
    "Sysop" is already a globally blacklisted username. There's a good case for blocking some of the others locally. – PartTimeGnome (talk | contribs) 01:49, 7 January 2014 (UTC)

"I don't think the poster complains about the word blocked, but about being blocked so quickly." Indeed! Thank you PrimeHunter for clarifying. Locked or blocked, neither of those are likely to feel good for a newbie, who just would like to add his little contribution to the grand puzzle. The point is to prevent those hiccups from happening. At least why not give prior notice? Thanks! 18:22, 6 January 2014 (UTC)Velanidia Foundation — Preceding unsigned comment added by Velanidia Foundation (talk • contribs)

I don't see any reason why we couldn't give WP:NOSHARE accounts a few days' warning before blocking them. With WP:Flow, it might even be possible to get automatic follow-up reminders to reduce hassle for the admins. The main complaint in the past is that admins can't track these warned accounts efficiently, so "one week's fair warning, during which you need to get your name changed" turns into "indefinite freedom, because I can't remember who I warned". But if a Flow process automagically told you when the time was up, then you wouldn't have to remember anything. (Hey User:Quiddity (WMF): I want another pony for Christmas, okay?) WhatamIdoing (talk) 19:27, 6 January 2014 (UTC)
I agree that the problem identified should be addressed. I tried a more comprehensive approach:User naming convention proposal. I still think it has merit, and this proposal is further evidence that there is a problem.--S Philbrick(Talk) 19:52, 6 January 2014 (UTC)
I have given such accounts warnings before using {{uw-username}}. I was rather disappointed to find that admins block accounts that have been given such warnings rather quickly (after about a day), even if they haven't used the account since the warning. I don't think there's any worry about admins having difficulty tracking warned users. (The template categorises the users into Category:Wikipedia usernames with possible policy issues, making them easy for admins to find.) – PartTimeGnome (talk | contribs) 01:49, 7 January 2014 (UTC)
@PartTimeGnome and WhatamIdoing: Timer-based workflows (or "reminder Notifications" as my note on the scratchlist calls them) are definitely something Flow aims to improve. Anything from individual-editor-reminders ("A week has passed since I commented on X that I'd be back in a week"), to systemwide-workflows ("category of editors who've been warned for 5 days about username issues, and need followup action"). It's not being rushed, so will take a while to reach that level of complexity, but with our guidance and patience over the coming months, it will fix hundreds of small problems like this. (No more ponies for you, WhatamIdoing, they've all been hired by as extras for some tv show...) Quiddity (WMF) (talk) 00:50, 9 January 2014 (UTC)

Respects to all of you for considering the issue and various ways to address it. PartTimeGnome, you mention a template that "categorises the users into Category:Wikipedia usernames with possible policy issues, making them easy for admins to find". -Couldn't the same programm simply deliver a warning to the new user (automatically)? Thank you. Lonaïs Velanidia 21:07, 13 January 2014 (UTC) — Preceding unsigned comment added by Lonaïs Velanidia (talk • contribs)

The template is called Template:uw-username, and it does give a warning as well as the category. Click my link to the template to see what the warning looks like. It is only invoked by humans, though, not automatically. To use this automatically, we'd need to define criteria a computer could use to determine which accounts should get the warning. That's the tricky bit, and it could never be perfect – there would be many cases that require human judgement. – PartTimeGnome (talk | contribs) 21:53, 13 January 2014 (UTC)
I seem to recall that there's a bot (can't remember which one) that files reports at WP:UAA using a filter test - it seems as though it wouldn't be difficult to apply that same filter at account creation. If tripped, it would produce a message along the lines of: "The username you have chosen may not meet Wikipedia's username policy. You may create an account with this username, but please be aware that username violations routinely result in accounts being blocked. Do you want to proceed with this username?" Potentially the wording could differ depending on the filter tripped (e.g. "...because it appears to indicate that you are editing on behalf of a company or organisation" for usernames which include strings like "corp", "official" or "sales"). I'm sure that can't be terribly hard to implement. Yunshui 雲‍水 10:48, 14 January 2014 (UTC)
That's User:DeltaQuadBot. It's not possible for it to catch usernames before they're registered, though, since there's no data for it to look at until after an account has been registered. This isn't the kind of thing that could be done by a bot. Writ Keeper ⚇♔ 17:21, 14 January 2014 (UTC)
But bots are the answer to everything... Seriously, though, ignoring the idea of using a bot, how complex is it to introduce a filter at account creation? Is it something that could only be done in the underlying MediaWiki software? Yunshui 雲‍水 09:44, 15 January 2014 (UTC)

WhatLinksHere overwhelmed by links in navigation templates

I wish there were an easy way to have Special:WhatLinksHere optionally (or even by default) not include links that only link through navigational templates. It there are way? Could there be?

My problem is that when I look at Special:WhatLinksHere for an article to find other articles with an interest in this article, the results can be overwhelmed by links that only exist in a navigation template. Now while navigation templates are good, the incoming links they generate are not so useful. --SmokeyJoe (talk) 00:12, 10 January 2014 (UTC)

AFAICT, this can't be done right now. I'd like it, too.
Does anyone know if this could be handled by a user script, or if we'd need the devs to support it? WhatamIdoing (talk) 01:14, 10 January 2014 (UTC)
It's a frequently requested feature but the developers will not implement it. See for example bugzilla:1392 and bugzilla:3241. PrimeHunter (talk) 01:17, 10 January 2014 (UTC)
It's bugzilla:1392. I believe that priority setting translates to is "if you write it, then we'll (maybe) merge it, but we won't spend any time on this ourselves".
Could something be built at Labs to produce the same effect? It doesn't have to be onwiki. WhatamIdoing (talk) 01:22, 10 January 2014 (UTC)
It would require a re-design of the database in order to achieve it. Right now all links (from templates, Lua, and article text) are combined, duplicates are removed, and the resulting list is in the database. Werieth (talk) 01:24, 10 January 2014 (UTC)
Would the redesign be so bad. Exclude all links from transcluded templates, but keep the links from the template itself? --SmokeyJoe (talk) 03:43, 10 January 2014 (UTC)
The link tables in the database only store that a link is from a given page, but not whether the link is from a template. A new field could be added to store this, of course. Adding a new database field is not to be done lightly, but isn't that bad. The bad bit is figuring out what to put in it. The MediaWiki parser expands all templates in a page before it parses the expanded wikitext for links. Even if MediaWiki tracked which bits of text came from the original page and which came from templates, there are many cases where it is ambiguous whether the link is from a template or the page:
  • Where a link is passed in a template parameter, does it "belong" to the template? Common sense says the link belongs to the page passing the parameter, but tracking parameters as they pass through a template to ensure the appropriate links in the template's output are considered to belong to the page would be very tricky.
  • The most common one is a template that constructs a link based on parameters passed to it. The link is not in the page nor in the template, but is only present when the two are combined.
  • Consider a template {{X}} that contains "Page]]". A page uses this template as "[[Main {{X}}". Believe it or not, this is valid wikicode that produces the link Main Page. Since the link is split between the containing page and the template, does it "belong" to the template or the page?
A simplistic solution is to ignore all links from a page that are also links from templates on that page. This still has problems: If a page directly links to something that is also linked by a template on the page, the direct link would be ignored. Furthermore, links in a template inside <includeonly> or that are only output under certain conditions do not count as links from the template. With this simplistic approach, they'd count as belonging to the pages that contain the template which is probably not what most would expect. – PartTimeGnome (talk | contribs) 22:03, 11 January 2014 (UTC)
What if the MediaWiki parser didn't expand templates in a page before it parses the expanded wikitext for links? --SmokeyJoe (talk) 22:39, 11 January 2014 (UTC)
Then "what links here" would be useless for the exercise that I described at 21:52, 10 January 2014 (below). The goal was to locate pages with a link to Chapel-en-le-Frith railway station; but some of the links to that were (and still are) constructed using {{stnlnk|Chapel-en-le-Frith}}. This template is commonly used across pages dealing with railway stations whose article names are of the form "Foo railway station", but when linking to that, you just want the "Foo" part to be displayed. So, {{stnlnk|Chapel-en-le-Frith}} displays as Chapel-en-le-Frith and so is exactly equivalent to [[Chapel-en-le-Frith railway station|Chapel-en-le-Frith]] but occupies significantly less wikicode. --Redrose64 (talk) 23:39, 11 January 2014 (UTC)
(edit conflict) That would be a major rewrite of the parser. It would effectively need to parse each template separately from the page transcluding it, rather than expanding everything and parsing once. With each template parsed separately, any given markup in a template would need to be self-contained within that template (no splitting markup across templates). This would break existing pages that rely on templates being used in combination. I really hope no real uses of my split link example exist, but we do have things like {{collapse top}} and {{collapse bottom}} that are designed to be parsed together. We also have templates that combine to make tables, with each table row being a separate template. There are also subtler effects such as the way line breaks inside and outside templates can combine. (There might be ways around such issues, at the expense of further complexity.)
These changes would affect normal transclusion, but substitution would continue to work as it does now because it expands templates when an edit is saved, before the page is parsed. The increased differences between the two might confuse editors further.
Note that this still doesn't correctly resolve some of the ambiguities I mentioned. E.g. links constructed by a template based on parameters would be treated as links from the template, even though their destination is specified by the containing page.
I understand the developers want to rewrite the parser, but this is a long way off, and some of the changes will require a conversion process for existing pages. – PartTimeGnome (talk | contribs) 23:50, 11 January 2014 (UTC)
We can expand on the idea of skipping pages that link to a page and also use a template. Have two lists: One of pages that don't use the template and one of pages that do. With the second list, it should be simple enough to write a little program that reads the list and looks at each pages' ?action=raw to find bracketed links to the desired page(s). Overly convoluted, I know, but it should get the desired result. moluɐɯ 15:00, 13 January 2014 (UTC)
Not quite the desired result, though, since it still wouldn't handle non-bracketed links, such as Redrose64's {{stnlnk|Chapel-en-le-Frith}}. – PartTimeGnome (talk | contribs) 22:13, 13 January 2014 (UTC)
Hmmm. How many templates are there like that? and how similar are they to each other? If the majority of them create a link in a way that's as simple as what you linked, it might be worthwhile to take the page source reader idea a step further to include simple link creating templates like that. moluɐɯ 17:14, 14 January 2014 (UTC)
See Category:Internal link templates. There appear to be many such templates. There are also some linking templates not in that category. Citation templates can take an authorlink= parameter; some info-boxes take a page name in a parameter to produce a link. – PartTimeGnome (talk | contribs) 23:41, 14 January 2014 (UTC)

Workaround

What I used to do (and this still works but takes much, much longer than it did before) was to edit the navbox so that the link that I was interested in was modified in some way, but not actually broken - such as going through a redirect, like this. Over the coming minutes, whilst the job queue was updating the link tables, I would monitor "what links here" for the page that I was interested in. Once it stopped growing shorter, I would wait ten or fifteen minutes more to make sure, and then I would make any edits consequent on the remaining incoming links. Having completed that task, I would then revert my edit to the navbox, like this. However, in about May or June 2013, something happened to the job queue so that the wait is now measured in days or even weeks instead of minutes. It's just not practicable any more. --Redrose64 (talk) 21:52, 10 January 2014 (UTC)

@Redrose64: I think this was T52785; see Wikipedia:Village pump (technical)/Archive 114#Null edits. --  Gadget850 talk 12:11, 11 January 2014 (UTC)
Well there's an idea. Require that all templates link only to template-redirects. Then you sort out the link-heres that link directly vs. those that link through template-redirects. And you would know that everything linking through a template-redirect was transcluding a template. So for example I have a template {{tools}} and one of the links in it is [[hammer-redirect|hammer]] hammer-redirect is just a redirect to hammer. When I look at what-links-to-hammer then I can ignore the pages coming through hammer-redirect. Yes, I know this would be a lot of extra work and is an idea that likely won't fly. The problem is editors who think that templates are a replacement for the category system and that every article in a broad topic area needs to be loaded up with template directories to everything remotely related to the topic. I'm frustrated with the amount of null-edits I need to make to thoroughly clean up after making certain changes. Wbm1058 (talk) 01:48, 11 January 2014 (UTC)
@Redrose64 and Wbm1058: ...except that redirect links in navboxes break functionality, because they do not show up in bold and unlinked when viewing that article, which hinders navigation through the articles in the navbox. Because of this, WP:NOTBROKEN specifically advises fixing redirect links in navboxes to point directly to the article in question. jcgoble3 (talk) 06:33, 11 January 2014 (UTC)
Oh, yea, right, I forgot about that. No, I actually bypass redirects in templates, in order to make the link appear in boldface. Wbm1058 (talk) 14:37, 11 January 2014 (UTC)
I didn't intend my post as advice to leave the redirect in permanently - I did know about the boldface feature, which is why I put "Having completed that task, I would then revert my edit to the navbox, like this". That edit eliminated the redirect (which was only intended to be temporary) so that the boldface showed again. --Redrose64 (talk) 15:49, 11 January 2014 (UTC)
  • ick.. no wonder the job queue is overloaded half the time... I've been working on some core enhancements to Special:Userlogin today, but tomorrow I would be happy to look into writing a userscript to filter out the unwanted links... Can someone give me a clear cut example of what is expected to be done? Like: "get rid of all links generated by Template:Bar on WLH for Foo" is what I currently think you want, and that should be easy via js. Technical 13 (talk) 02:19, 11 January 2014 (UTC)
    • Maybe we should just set limits on the allowed scope of navigational templates, seek out the worst offenders, and prune them down to size. Wbm1058 (talk) 14:37, 11 January 2014 (UTC)
  • Navigational templates are very helpful, much better a navigation aid than the category system. They shouldn't be restricted due to this WhatLinksHere glitch. — Preceding unsigned comment added by SmokeyJoe (talk • contribs) 22:46, 11 January 2014 (UTC)
    • I really have no idea whether my null edits have any impact on the job queue or not. Just a vague idea of how the job queue works. I've made changes where I needed to find every article that truly linked to a particular article and make real edits to those articles. But I have to sift through a forest of "fake" links via navigation templates. To clear that forest, I make null edits. Can't recall the situations exactly, but I think certain page moves, i.e. article title changes, comes to mind. Wbm1058 (talk) 14:37, 11 January 2014 (UTC)

Search index not being updated

It appears that the index has not been updated for 4 or 5 days. Can we get it running again? Chris the speller yack 05:40, 11 January 2014 (UTC)

I'm not sure, but it might be because they are building the index for the new search engine that is going to launch soon. —TheDJ (talk • contribs) 11:28, 11 January 2014 (UTC)
Thanks. That's either very reassuring or very scary; I'm not sure which. Chris the speller yack 17:59, 11 January 2014 (UTC)
Until we know when "soon" actually is, rather than when it is meant to be, I'm assuming very scary. Arjayay (talk) 18:25, 11 January 2014 (UTC)
There was a blogpost with a link to timeline. So as you can see it is beta only and then there will be a bigger announcement when it leaves beta. I'll ask a sysadmin about the status of updates to the current index. —TheDJ (talk • contribs) 13:08, 12 January 2014 (UTC)
Bugzilla 59979 [64] has been created for this problem. Chris the speller yack 03:52, 13 January 2014 (UTC)

Job Queue, redlinks and Search

I'm sure this is not a new issue, just as I'm sure the job queue is tied in to why the Search is not working on new articles. As I go down the list of DYK nominations, I've noticed that articles created within the last few days don't show up on a search, as if the articles do not exist at all. I created a new article 16 hours ago, which naturally does not come up in Search. But also, I noticed where I had placed a link to the new article in other articles, the link in the other article showed as a redlink, while running my mouse over the redlink gave me a popup of the new article's lead paragraph. To get rid of the redlink, I had to do a null edit on the article containing the redlink. — Maile (talk) 13:37, 11 January 2014 (UTC)

I think old pages are being lost from the search index somehow. If I start typing "Semper fi", the suggestions include "Semper fidelis" so long as I have just entered "Semp" or "Sempe"; but if I get as far as "Semper", then nothing is offered. It's as if I'd mistyped, when in fact I'm certain that the spelling "Semper" is correct. --Redrose64 (talk) 18:57, 11 January 2014 (UTC)
i do not see the same phenomenon, and i predict you won't see it either if you repeat the same experiment. as each letter typed causes a new AJAX call, it's possible that one of those calls went berserk for whatever reason (maybe for a short while all of them did), and the suggestion mechanism had a brain-fart. i do not think this is related in any way to "old pages". peace - קיפודנחש (aka kipod) (talk) 20:58, 11 January 2014 (UTC)
Thanks, I look forward to their answer. It is now a whole week since it was updated, and us poor little WP:WikiGnomes will be swamped with spelling corrections etc. as it is, without any further delays. Arjayay (talk) 19:25, 12 January 2014 (UTC)

Current search & new search

We haven't started building the new search index just yet (we are going to start in about 12 hours from now). And once we do, that won't have anything to do with the old search index not updating (we're running both in parallel for redundancy). Also, the job queue is not used for updating the old search index, it's done by a daily cron at about 1am UTC. The new search index will be done via the job queue via their own prioritized queue so it should be much faster :) I'll be posting here tomorrow about the new search some more when we start the indexing process. I'm having a look at the lsearchd indexer right now, will follow-up if I find anything interesting. ^demon[omg plz] 05:18, 13 January 2014 (UTC)

We haven't found an answer to the broken old search yet. Nik and I both have been taking a look at it. ^demon[omg plz] 17:09, 13 January 2014 (UTC)
Ok, so the search indexer was restarted about a week ago, but the jobs to index don't seem to have restarted. We're pretty sure we've fixed this and they'll begin indexing overnight like before. I hate the once-per-day updates :( ^demon[omg plz] 00:29, 14 January 2014 (UTC)
The index updater has caught up to reality. Thanks to all who helped get this fixed. Chris the speller yack 21:44, 15 January 2014 (UTC)

Rethinking the entire CSS framework

Main page: Wikipedia:New CSS framework
The Senate side of the United States Capitol in Washington, D.C.

I have been toying with this idea in my head recently, for redesigning most of the current CSS in Common.css. Instead of singlular blocks of CSS geared towards each template separately, it would be much more efficient breaking them up in smaller entities that can be reused by all templates. So instaed of one large block dedicated only to {{navbox}}, there would be several smaller blocks describing borders, headers and the like, which are in turn used by multiple templates. This involves some work, but I want to poll the idea and see if this is feasable. One major benefit is eliminating the many occurences of duplication. It would also make design easier and more consistent, while still allowing flexibility.

This sprang to mind when I thouhgt about redesigning individual templates; doing each one separately is way to much work and very inefficient. Why not use a modular and reusable CSS framework that can be employed by all templates? As a side note, this gives a great oppurtunity to refresh the aging look of many templates. As an example, all floating element would look like the thumb image (the only element that would need a change in core) on the right. A consistent look also comes across much more professionally. Thoughts? — Edokter (talk) — 15:17, 11 January 2014 (UTC)

I'd support this idea. Jackmcbarn (talk) 16:07, 11 January 2014 (UTC)
  • support. You are certainly an expert in CSS and I would follow your lead here. --  Gadget850 talk 16:12, 11 January 2014 (UTC)
  • Support I do give this proposal. Modular code is the way to go. I'm somewhat of an intermediate css person myself, let me know if I can be of any assistance in developing the prototype. Technical 13 (talk) 18:26, 11 January 2014 (UTC)
    • I started a page for brainstoring and testing (see top of post). Anyone is welcome to contribute. — Edokter (talk) — 20:31, 11 January 2014 (UTC)
  • Comment @Edokter: I'd strongly recommend posting to the Design list about this. There are a number of volunteer and staff mediawiki devs and designers, who watch that list, that might be interested, including the folks who are implementing LESS in mediawiki core (See mw:CC/LESS for details). HTH. –Quiddity (talk) 00:13, 12 January 2014 (UTC)
    • @Quiddity: This mainly concerns local templates and CSS in Common.css. Is LESS going to be supported from Common.css as well? In that case, I may ping the list. (But as I understand it, LESS is only supported in core CSS.) — Edokter (talk) — 00:32, 12 January 2014 (UTC)
      • @Edokter: There's nothing stopping LESS from being supported via, say, MediaWiki:Common.less and similar pages – it was just not done yet because everyone was eager to get support for it in core out, and allowing user-supplied LESS to be parsed would require considering various security issues, which obviously takes time :) (For example, you can use @import to load other LESS files – it would have to be disabled in the parser for usages from wiki pages, or some core files could be whitelisted, or it could embed other wiki pages – and AFAIK none of these are possible to do by just toggling a setting right now.) Matma Rex talk 01:01, 12 January 2014 (UTC)
        • That's not helping much here. In either case, that doesn't stop us from creating a new framework here. — Edokter (talk) — 01:55, 12 January 2014 (UTC)
        • See bugzilla:54864 for one step towards that. I think there are more discussions (on either a mailing list, or one of the numerous wikis or bug tickets) but I can't find them. That's another reason to ping the design list! HTH. –Quiddity (talk) 01:58, 12 January 2014 (UTC)
        • If I may suggest something, then for the love of all that is holy, do not ping the design list. You will not gain anything through the experience, but you will get to admire truly impressive amounts of stillborn ideas and overblown egos. When you do need design input, ask someone directly. The list can sometimes be useful when you already have concrete ideas with proof-of-concept implementations and several people readied to put out any fires of stupidity that will inevitably start spreading. Matma Rex talk 02:43, 12 January 2014 (UTC)
  • Conditional support; while this sounds like a great idea, I'd want design changes to be separate from the code structure changes insofar as that's possible. Without that, I fear that the improvements that the code structure changes represent would be mired in frustrations with the specifics of the design changes. {{Nihiltres|talk|edits}} 03:12, 12 January 2014 (UTC)
  • Support. I fully trust Edokter with our CSS, I know he knows what he is doing, and I think this will set us up to be able to improve our tired-looking styling. — This, that and the other (talk) 09:51, 12 January 2014 (UTC)
  • Note that it is very likely that at some point in the next 2 years we will see CSS that is bound to templates. This is to cleanup the pervasive use of inline styling in templates while at the same time not serving every page with a ton of unused styling statements. Additionally, we have of course a lot of classes that double as semantic classes so we would have to be careful there as well. —TheDJ (talk • contribs) 13:00, 12 January 2014 (UTC)
    • That is fine of course. My main concern is the (re)use of common CSS code for generic styling to avoid duplication. I think there is a lot to gain there. — Edokter (talk) — 14:08, 12 January 2014 (UTC)
  • Support but raise parser limits: While condensing the massive CSS classes and style text will reduce size, there is also the need to support longer page names, as more people split mega-articles into long-named subarticles, and the wp:post-expand include size needs to be larger (3 MB?) to support longer page names as well as all the massive CSS style tags which have swamped the parser with long-winded style text. -Wikid77 19:56, 12 January 2014 (UTC)
    Parser limits have nothing to do with this proposal. – PartTimeGnome (talk | contribs) 22:24, 13 January 2014 (UTC)
  • I'm all for modularity and reusable code, so this makes a lot of sense to me. Anything that can reduce our dependency on inline styling counts as a big step forward in my opinion. I'm thinking that we should have a transition period where both the old-style and new-style classes are available, so that our major templates can be moved over to the new system, but I suppose whether this makes sense or not will depend on the details of the implementation. — Mr. Stradivarius ♪ talk ♪ 07:54, 14 January 2014 (UTC)

Template:Infobox animanga/Video and Wikipedia:Categories for discussion/Log/2014 January 3#Films by country and year

Wikipedia:Categories for discussion/Log/2014 January 3#Films by country and year was closed as double upmerge and delete. Unfortunately, some of the categories are being populated by {{Infobox animanga/Video}}. Can some user please help with removing/fixing the code which populates these categories in this template? עוד מישהו Od Mishehu 16:53, 13 January 2014 (UTC)

I think this edit has fixed that. Thanks. Lugnuts Dick Laurent is dead 19:56, 13 January 2014 (UTC)
Yes, it works. Thanks - I can't handle complex tempaltes like this one. עוד מישהו Od Mishehu 17:35, 15 January 2014 (UTC)

Template sort appears to not give the correct sort key

I'm probably getting blind, can someone else see why my sort doesn't work. Please see article 2014 European Allround Speed Skating Championships. In it, I have prepared the sort key like this {{sort|24|NQ24}} where I want to indicate both placing and that the skater didn't qualify for participation in subsequent events. In three of of four tables, it work as it should, but in the fourth – the second "Ranking after three events" section, the one for women – it doesn't.

Check the sort order by clicking first on "Skater", then back to "Rank". As mentioned, it works for the first three similar tables, but not the fourth. Why? Why? (to quote Nancy Kerrigan) ;-)

I would be greatful if someone could point out what I'm obviously missing. Will have get my eyes checked?

Thanks

HandsomeFella (talk) 20:32, 13 January 2014 (UTC)

The type auto detection only looks at the first few rows, for reasons of efficiency. Forcing it will give more reliable results (and ideally should be done for most more complicate cases where you are using table sorting —TheDJ (talk • contribs) 20:54, 13 January 2014 (UTC)
(edit conflict) The thing to remember is that whatever data you put into it, {{sort}} emits a text string. In the first three tables, you haven't used {{sort}} until the eighth row or later, and the sorting software has been able to work out from the first few entries that the column contains primarily numeric data, and so should be sorted numerically. But in the fourth one, the first use of {{sort}} is in the third row, and {{sort|3|WD3}} expands to <span style="display:none;" class="sortkey">3 !</span><span class="sorttext">WD3</span> - that exclamation mark causes the sorting software to believe that the cell isn't purely numeric, and so the column should be sorted as text: 1, 10, 11...19, 2, 20, 21...29, 3 etc. --Redrose64 (talk) 20:57, 13 January 2014 (UTC)

Brilliant! Mille grazie. I'll try to remember that. HandsomeFella (talk) 21:20, 13 January 2014 (UTC)

Just one question: why does the template produce an exclamation mark there? HandsomeFella (talk) 23:25, 13 January 2014 (UTC)
It was added with this edit, replacing a &#xfeff; BOM. The final version of the relevant discussion is here. --Redrose64 (talk) 23:53, 13 January 2014 (UTC)

Jakebot help - was directed here from the Teahouse

Hi,

I've been trying to run a bot and have been trying to work out editing using the API, but it doesn't appear to work. The code is: 

       Socket s = new Socket("en.wikipedia.org", 80);
       PrintWriter out = new PrintWriter(s.getOutputStream());
       out.print("POST "+ "/w/api.php" + "?action=edit&format=json&title="
               + "User%3AJakebot%2FTest%20report&text=foo&"
               + "token=1a783fff5b06fd636a301606d67b629d+\\&"
               + "summary=Test");
        Scanner in = new Scanner(s.getInputStream());

And yes, I make sure to get the correct token from [65] before running it. Any ideas? --Jakob (talk) 22:42, 13 January 2014 (UTC)

The code you have there isn't speaking proper HTTP to the server. Why don't you use a library/framework that will handle all the details of the HTTP protocol for you, including processing cookies correctly and such? Anomie⚔ 13:38, 14 January 2014 (UTC)

Item appearing in watchlist-changes list, but is not being watched

I notice this morning that Wikipedia:Village pump (proposals) (and its talk page) is appearing on my watchlist-changes list, but I'm not watching it - it does not appear in "edit watchlist" or "edit raw watchlist", and when I visit the page the tab reads "watch", not "unwatch". I did make an edit on that page on 9 December last, which is now archived, but the page would not have stayed on my watchlist for more than a few days. That is the only page affected. Does anybody know what the problem is likely to be? Thanks Rwxrwxrwx (talk) 10:12, 14 January 2014 (UTC)

Bug: MathJax processes "script error" messages

Tracked in Phabricator
Task T57675

View this post with MathJax enabled: Script error and Script error will look like . This leaves me unable to read the error message after MathJax mangles it. Keφr 16:38, 14 January 2014 (UTC)

  • The math-format rendering of wp:Script_error is a common problem, but then the words "Script error" are fairly unreadable to many people, and we must View-source for the HTML markup of the page and search for "Script error" to see the specific details of the associated error message stored for a Lua script problem. If a search of the HTML page fails to find "Script error" then there is none. I wish Lua were more sophisticated and could exit MathJax to report, "Misspelled variable 'countEr' switched to 'counter' at line 2,560 in function xyz" but Lua does not check spelling or uninitialized variables. So, yes, the "2010s are the new 1950s" of computing technology, but now you know why fast auto-correcting compilers were developed in the 1960s. -Wikid77 17:52, 14 January 2014 (UTC)
    • Uhh... Script error. Keφr 18:46, 14 January 2014 (UTC)
      • Uh indeed. Could you please stop dragging unrelated stuff into every discussion you comment on wikid ? —TheDJ (talk • contribs) 23:04, 14 January 2014 (UTC)
  • Hmm this is a bug that was introduced in september. Filing a bug report.—TheDJ (talk • contribs) 22:10, 14 January 2014 (UTC)

"Cite Journal" template shortcut on Edit Toolbar not working properly

Hi folks,

This is frustrating -- the "Cite Journal" template in the editing toolbar (at least the one I see) is not working properly all of a sudden (I don't know how long this has been going on, since I don't think I've used in a month or so). If one clicks "Cite Journal", the "Cite Book" template pops up instead! It is missing all of the critical ingredients of the "Cite Journal" template, like PubMed number, DOI number, and so forth. I tried to make some manual adjustments after I filled in the fields in the "Cite Book" template that in now the only one available, but it's still not working correctly. Even odder is the fact that though the edit toolbar clearly titles the template "Cite Book" (instead of the "Cite Journal" requested), when one clicks "add citation", the resulting citation text reads <ref>{{cite journal}}</ref>, even though it's clearly not and doesn't have the normal journal fields.

Anyway, this is really really frustrating for those of us citing medically related articles, and so forth. BTW, I've checked this on Chrome and on IE, and it's the same glitch on both.

Can someone please restore the "Cite Journal" template to its former correct state, complete with the proper name, and the PubMed number field, DOI number field, and so forth? Thank you. Softlavender (talk) 23:41, 14 January 2014 (UTC)

It works for me. You can ask at Wikipedia:RefToolbar, but there hasn't been a lot of activity. --  Gadget850 talk 09:07, 15 January 2014 (UTC)
Just to confirm, I'm getting the standard journal form to fill in as well (Chromium 31). What happens if you try selecting cite web/news/book? Andrew Gray (talk) 17:15, 15 January 2014 (UTC)
After a little digging, MediaWiki:RefToolbarLocal.js is the local version of the configuration code - it's not been altered since October. I suspect this is a local glitch on your computer, though I have no idea what's causing it! Andrew Gray (talk) 17:17, 15 January 2014 (UTC)
None of the "Cite" tools work for me, but they never have in IE11 (no sarcastic comments please). That includes all the "Templates", the "Named references" and the "Error check"; furthermore the "Link", "Embed file" and "Reference" icons on the initial toolbar do not work either. Of course, "Search and replace" hasn't worked on IE for several years. The templates sometimes work in "Compatability view" but that uses the old, simplified, drop down menus and creates other problems. Arjayay (talk) 17:31, 15 January 2014 (UTC)

Templates on List of PlayStation 3 games not showing up

Screenshot showing the problem

Hello. I experienced some problems on List of PlayStation 3 games where templates after the “Viking: Battle for Asgard" entry are not showing up, and I suspect this is a server problem. The full explanation of the problem can be found on Talk:List of PlayStation 3 games#Templates not showing. Thanks a lot! Zhaofeng Li [talk... contribs...] 09:41, 15 January 2014 (UTC)

It is in the hidden Category:Pages where template include size is exceeded. See Wikipedia:Template limits. --  Gadget850 talk 10:12, 15 January 2014 (UTC)
Oh, I see. However, it needs to be fixed since it affects both editors (saving a tiny edit takes over a minute) and readers (confusing links leading to confusing template pages). I think splitting the long list into short ones by their initials is a good workaround. Is there any bot that can do this automatically, or we have to do this manually? Zhaofeng Li [talk... contribs...] 10:45, 15 January 2014 (UTC)

Notifications have not been working for weeks

What does work for me: notifications of a new message on my talk page and of "thanks". What notifications don't trigger: Everything else that is supposed to. I first noticed this on January 4 - a ping had been left for me on a talk page not my own, and it never showed up in Notifications. Here and there, I've noticed others. Another notification should have triggered for me from WP:DYK about half an hour ago - but didn't. Is this issue already known?— Maile (talk) 15:34, 15 January 2014 (UTC)

For mentions to work, you have to sign your new comment. So this will never generate a mention notification (not signed) and neither will this (not a new 'comment' block). This is because in our talk format it is difficult to distinguish editing from 'new posts'. Flow will fix that. —TheDJ (talk • contribs) 17:08, 15 January 2014 (UTC)
Also ensure that at Preferences → Notifications, you have "Mention" enabled. --Redrose64 (talk) 18:54, 15 January 2014 (UTC)
Thanks for that - my Preferences are set correctly. I get what TheDJ is saying. Where I first noticed a ping wasn't notifying me was Here, which was a new post that seems to be signed by the posting editor. — Maile (talk) 20:18, 15 January 2014 (UTC)
That particular post screwed up the template syntax, so it didn't generate a link to User:Maile66. And, of course, the fix in the next edit didn't count because it wasn't a new post with a signature. Anomie⚔ 20:43, 15 January 2014 (UTC)
Got it. So what it amounts to when the Notifications don't work is "...user error..." — Maile (talk) 20:52, 15 January 2014 (UTC)
@Maile66: not sure i'd put it the way you did, but sure, user error can cause notification to fail. genuine bugs in the software can also cause it to fail, but in this case, it was the former. check to see if you get notification for this one... peace - קיפודנחש (aka kipod) (talk) 00:06, 16 January 2014 (UTC)
I got the notification on this one. Thanks. — Maile (talk) 00:08, 16 January 2014 (UTC)

Current article link wish

I've two enhancement ideas:

  1. Expanding navbox to highlight (bold) link. Example: Jetpack (Firefox project) and its link in navbox
  2. Marking redirect link too. Example: XKeyscore and its link in navbox sidebar (Programs section)

This can be done probably with JavaScript (especially the first idea) and IMO will make navbox navigation really better.

Please comment! --Rezonansowy (talk • contribs) 15:40, 15 January 2014 (UTC)

The first should already be showing as bold by use of CSS. The second can be done by using User:Anomie/linkclassifier. For example, I see self-redirects with a green background. --  Gadget850 talk 15:49, 15 January 2014 (UTC)
In first I meant expanding navbox to show its content with bolded link. In second, I know about this gadget, but that's not only an enhancement, IMO thats a bug and should be corrected in core of MediaWiki. Please tell me if you agree. --Rezonansowy (talk • contribs) 16:12, 15 January 2014 (UTC)
You want to automatically expand a collapsed box that contains a link to the page it is transcluded on? --  Gadget850 talk 16:52, 15 January 2014 (UTC)
Yes, but only on current page where it is transcluded on, then the bolded link will be visible. --Rezonansowy (talk • contribs) 17:31, 15 January 2014 (UTC)
That practically means that every navbox would be expanded as they normally all contain a link to the current page. That goes against the current practice of automatically collapsing navboxes when there are more then two navboxes on the page. — Edokter (talk) — 17:40, 15 January 2014 (UTC)
And changing link colors to nonstandard is going to confuse readers. I enabled the linkclassifier so I understand why I get all those colors. It should never be a default. --  Gadget850 talk 22:28, 15 January 2014 (UTC)

RfC: Should we support MP4 Video on Wikipedia?

The Wikimedia Foundation's multimedia team seeks community guidance on a proposal to support the MP4 video format. This digital video standard is used widely around the world to record, edit and watch videos on mobile phones, desktop computers and home video devices. It is also known as H.264/MPEG-4 or AVC.

Supporting the MP4 format would make it much easier for our users to view and contribute video on Wikipedia and Wikimedia projects -- and video files could be offered in dual formats on our sites, so we could continue to support current open formats (WebM and Ogg Theora).

However, MP4 is a patent-encumbered format, and using a proprietary format would be a departure from our current practice of only supporting open formats on our sites -- even though the licenses appear to have acceptable legal terms, with only a small fee required.

We would appreciate your guidance on whether or not to support MP4. Our Request for Comments presents views both in favor and against MP4 support, based on opinions we’ve heard in our discussions with community and team members.

Please join this RfC -- and share your advice.

All users are welcome to participate, whether you are active on Commons, Wikipedia, other Wikimedia project -- or any site that uses content from our free media repository.

You are also welcome to join tomorrow's Office hours chat on IRC, this Thursday, January 16, at 19:00 UTC, if you would like to discuss this project with our team and other community members.

We look forward to a constructive discussion with you, so we can make a more informed decision together on this important topic.

All the best, Fabrice Florin (WMF) (talk) 01:42, 16 January 2014 (UTC)

Categorizing non-mainspace redirects

Per discussion on my talk page, is there a better or more obvious way to categorize general redirects located outside of mainspace? There were two suggestions brought up, that we should "consider removing the namespace restrictions on the r from/to plural templates" or that we should "create new 'r from/to plural in non-main namespace' templates". See also here for a more complete discussion. I understand that primarily the {{R from plural}} template is meant to produce the Category:Unprintworthy redirects insofar as to prevent the redirect showing up should a user wish to download files from the Wikipedia website (or Jimmy to construct his book) but there should be an easier way to categorize non-mainspace redirects. TeleComNasSprVen (talk • contribs) 18:35, 6 January 2014 (UTC)

There would be no need for a separate "R from plural in non-mainspace" template. {{R from plural}} could use a template like {{main other}} to detect where it is used, and output the appropriate categories for that namespace. In fact, I see it already does so – Category:Unprintworthy redirects is omitted when the template is used outside of mainspace.
As for Category:Redirects from plurals, this is a tracking/administration category, not an article category, so IMO there's nothing wrong with it containing redirects from mixed namespaces. The main question to answer is if there is any benefit in splitting main and non-main redirects, or would it just make things more awkward? – PartTimeGnome (talk | contribs) 01:17, 7 January 2014 (UTC)
The problem is that I don't see it categorizing non-mainspace redirects into Category:Redirects from plurals even if it says it does, which it honestly should. I'm fine with excluding it from Category:Unprintworthy redirects as things outside of mainspace should not be printed in the first place. TeleComNasSprVen (talk • contribs) 23:37, 7 January 2014 (UTC)
The sub-cats of Category:Cross-namespace redirects – Wbm1058 (talk) 01:25, 11 January 2014 (UTC)
{{R from plural}} uses |main category=Redirects from plurals, so only mainspace pages are placed in that category. To apply to all pages, each use of main category should be changed to all category (these parameters are passed to to {{Redirect template}}). – PartTimeGnome (talk | contribs) 18:06, 11 January 2014 (UTC)
I am the user who started the discussion in question. I never really thought that creating a separate template/category was the best idea; i.e., I am slightly in favor of just removing the namespace restriction, but it might be good to know who added that restriction in the first place and whether there was any previous discussion. I have no strong objections to anything here. --SoledadKabocha (talk) 16:37, 16 January 2014 (UTC)
The technical restriction was added by Paine Ellsworth in June 2011, with the edit summary "standardize with Template:R to plural". This was part of a larger rewrite of the template. Template:R to plural has the same restriction, which was added as part of a similar rewrite by Mclay1 in February 2011. The mainspace-only restriction was added to the documentation of both templates more recently (August 2013), again by Paine Ellsworth. – PartTimeGnome (talk | contribs) 21:37, 18 January 2014 (UTC)

A lua module should be able to automatically detect the categories that are needed. John Vandenberg (chat) 18:30, 16 January 2014 (UTC)

WikiProject Military History Lag.

WikiProject Military History is experiencing lagging. "We" (the WikiProject) is experiencing lagging inseveral areas. I am using Internet Explorer, and I clean my internet browser several times a day, yet I still see articles there. Please see the following:

Adamdaley (talk) 06:45, 14 January 2014 (UTC)

  • Directly check categories in page, not sub-pages: The system has become very slow to update nested sub-pages, and so try to simplify massive status pages to directly list the categories and related counts. For example:
It is better to avoid nesting the layer upon layer upon layer of obtuse nested pages, where most people do not even know where the nested crap is coming from. Many wp:WikiProjects have created these uber-complex status pages which lag behind the actual counts. If you are not allowed to simplify the status pages, then create one in your own user-space to directly check {{PAGESINCATEGORY:}} for each category count. Then edit that status page, and rerun "Show-preview" when wanting to see the current counts. Otherwise, to update the whole massive status page, you will need to run a wp:null_edit to force all the sub-pages to update and re-render the whole page with current details. -Wikid77 (talk) 09:12, 14 January 2014 (UTC)
There is anything I can do to stop this? There has to be a way? If so please explain it in a way that I can understand it. Adamdaley (talk) 07:06, 15 January 2014 (UTC)
hello? How can I stop this? Adamdaley (talk) 23:10, 16 January 2014 (UTC)

Fixing issues with medical articles

A question I've seen a lot is "What about the people who use Wikipedia for medical advice? How do we protect them from vandals?" Well, how about a button to point out the recent changes that may not have had a chance to be reverted if they're vandalism, maybe by highlighting the edits in the past week? Ideas? Supernerd11 (talk) 22:30, 15 January 2014 (UTC)

Template:WPMED related changes was recently developed for this purpose. Maralia (talk) 22:49, 15 January 2014 (UTC)
Alright, thanks. Supernerd11 (talk) 13:20, 16 January 2014 (UTC)
enwiki has the ability to define some pages as "require review" - the whole shebang is explained in WP:RVW.
it seems that this is the right tool to solve the problem you raise, by marking all pages that readers might turn to for medical advice as "require review".
peace - קיפודנחש (aka kipod) (talk) 19:19, 16 January 2014 (UTC)

Confusing media redirection

In Category:Wikipedia soft redirects there is one file. It is called "Normalspace.gif". If you click on it, you appear on page "File:Normal space.png". The reason is commons:File:Normalspace.gif is a redirect to commons:File:Normal space.png. However we have a local page called File:Normalspace.gif. See https://en.wikipedia.org/wiki/File:Normalspace.gif?action=history It is probably easy enough to fix this case by deleting the local gif , however there is a bug somewhere in there, and many more files may be affected. John Vandenberg (chat) 02:24, 16 January 2014 (UTC)

The problem is that the file still appears to be present in the category. Even though the deleted file is no longer in the local category, it seems the system does not realize that this is the case. It might be that it just takes long to update due to the job queue, or perhaps it simply doesn't realize that the local page no longer exists. I suggest we wait a bit and see if the job queue cleans it up. If it is still there after a few days, we call in the system administrators :D —TheDJ (talk • contribs) 09:26, 16 January 2014 (UTC)
@TheDJ: the local page does exist, with a {{soft redirect}} which is doing the categorisation. You can see it here https://en.wikipedia.org/w/index.php?title=File:Normalspace.gif&action=edit John Vandenberg (chat) 13:28, 16 January 2014 (UTC)
Deleted the local file page; soft redirect was overridden by the Common hard redirect anyway. — Edokter (talk) — 13:36, 16 January 2014 (UTC)
I was leaving in undeleted so that we could identify the bug. John Vandenberg (chat) 18:28, 16 January 2014 (UTC)
I was unaware of that. Though I don't really see a bug here. Had the page contained an image, you would have landed on the local page. Otherwise, the Commons redirect takes precedence. — Edokter (talk) — 18:48, 17 January 2014 (UTC)

Message at page bottom

When on a wikibreak, I put a message at the bottom of my talk page informing visitors of the fact and asking them to write above that message and below everything else. In practice, people often add their message below my advisory notice, which therefore gets lost. Is it possible to pin my message to the bottom of my talk page so that it stays there despite other editors?

I've left it very late to post this, since I'm flying this evening, so if it can be done, please feel free to fix my talk page according. Thanks, Jimfbleak - talk to me? 07:56, 16 January 2014 (UTC)

Yeah, the add section button always puts the new section at the very end of the talk page, so oftentimes, people won't even see your notice. You might try out a WP:Editnotice as an alternative, since I don't know how to add a section that stays at the bottom. VanIsaacWS Vexcontribs 08:56, 16 January 2014 (UTC)
You might be able to concoct something with absolute positioning in CSS, a little like the "Jimbo peeking" picture, but I'd recommend against it. It would probably look annoying, and there are some tools (like popups) that allow you to go straight to adding a new section, so people might not even see it then. I'd go for an edit notice plus a notice at the top of the page if you want maximum visibility. — Mr. Stradivarius ♪ talk ♪ 10:55, 16 January 2014 (UTC)
Thanks, I've added an edit notice, and put the message at top and bottom of talk page, so we will just have to see if it works! Jimfbleak - talk to me? 12:05, 16 January 2014 (UTC)
  • MediaWiki software should have page-footer notices: This issue is one of the quite important features to have, which should have been added years ago, as another example of a typesetting environment without typesetting capabilities, because footers have been provided in computerized typesetting for over 40 years. Perhaps enough people can keep reminding the developers to implement page-header and page-footer directives always positioned to the top/bottom of a page, especially as instructional messages without editing a page. Perhaps there is already a wp:MediaWiki extension which provides headers/footers, as with the extension to store data-settings between templates (which could make some markup-based templates run 10x faster). -Wikid77 12:52, 18 January 2014 (UTC)
    There are multiple extensions providing page footers: Extension:PageNotice, Extension:Header Footer and Extension:HeadersFooters are some that I know. I don't think any are up to the code quality required for deploying on Wikimedia, but I don't think it would take much work to bring one up to scratch. I agree that such a feature would be useful.
    The other extension you mention (I guess you mean Extension:Variables) isn't relevant here, but is unlikely to be deployed. Templates are not intended as a fully-featured programming language, and the developers won't support attempts to turn them into such, especially when we already have Lua. – PartTimeGnome (talk | contribs) 20:59, 18 January 2014 (UTC)

Database error in filtered new users' contributions search

Tracked in Phabricator
Task T60157

Does anyone else find that, when trying to perform a namespace-specific search in new users' contributions, they receive the following error message? 

A database query error has occurred. This may indicate a bug in the software.
   Function: IndexPager::buildQueryInfo (contributions page filtered for namespace or RevisionDeleted edits)
   Error: 0

I periodically run through and check new user uploads in the file namespace and have been experiencing this problem for the last three or four weeks. Sometimes, after much loading, I am able to view the most recent changes up to the end of the first results page; attempts to view changes older than the top 100 or 200, however, produce the database error. As a consequence, the oldest recent changes in the namespace (dating back a month) become inaccessible. SuperMarioMan 04:03, 17 January 2014 (UTC)

Confirming that something similar happened to me too when I tried it, via this link. I didn't get the database error you mentioned though, but a "data not received" error from Chrome. (The actual error message may be different, as I translated it from Japanese.) I remember something similar was also reported for user log pages recently - I'll see if I can find the archive link. — Mr. Stradivarius ♪ talk ♪ 04:21, 17 January 2014 (UTC)
Here it is: Wikipedia:Village pump (technical)/Archive 118#timeouts. Also see bugzilla:54876. That bug report was resolved as fixed, so this may be a separate issue. — Mr. Stradivarius ♪ talk ♪ 04:43, 17 January 2014 (UTC)
bugzilla:58157 is still open though. --Redrose64 (talk) 10:39, 17 January 2014 (UTC)
Yes, the error is pretty much exactly as described in the second Bugzilla report. I didn't know that named user contributions lists were affected as well – yet, true enough, when I try the links provided in the first two posts there, the page is just as slow to load, and the eventual result is the same message as before. Curiously, if I remove the "&namespace=X" suffix, load the full contributions list, and then click back to the previous page, the namespace-specific list displays as normal.

For reference, this is the bookmarked URL that I normally use: http://en.wikipedia.org/w/index.php?limit=150&tagfilter=&title=Special%3AContributions&contribs=newbie&target=&namespace=6&tagfilter=&year=&month=-1. Until a few weeks ago, the link functioned perfectly, and I was able to cycle back through past edits in batches of 150 up to the cut-off point (30 days?); now, it works only if lower limits of 20 or 30 are applied, and batches no longer show past the 100 or 200 mark – in upload terms, no further back than the last few days. For what it's worth, I'm using Firefox and Internet Explorer, although this is clearly not a browser issue. SuperMarioMan 14:42, 17 January 2014 (UTC)

IRC feeds down?

I'm not sure the logistics behind how recent changes work... but Huggle says it's connected to the IRC feed but nothing is showing up. Likely related, ClueBot NG has made no reverts since 12:15 EST. Anyone know what's going on? Thanks! — MusikAnimal talk 18:04, 17 January 2014 (UTC)

There is a network failure at the moment (apparently the fiber feeds into one of our datacenters have no less than three breaks) that reduces or prevents some services from running properly. Impact on Labs is variable, depending on the exact tool, but no access to the database replicas will work until the network has been repaired (outside our control, atm). — MPelletier (WMF) (talk) 18:22, 17 January 2014 (UTC)
Gotcha, thanks for the update. For anyone else reading this that uses Huggle, change your options to force the software to use the API queries rather than the IRC feed. System > Options > uncheck "Use IRC feed for recent changes if possible". Cheers! — MusikAnimal talk 18:38, 17 January 2014 (UTC)
The RC-IRC feed is back up since about a minute. --Sitic (talk) 19:29, 17 January 2014 (UTC)
Seems like it came back up, but isn't really stable and is having intermittent issues. Just need to be patient with it until the fibers are patched... Technical 13 (talk) 19:47, 17 January 2014 (UTC)
Hm, so that's why I couldn't access the IRC feeds when I opened up Huggle during my lunch (Yes, I do that a lot). I thought it was my Internet, but apparently not. MusikAnimal left me a note on my talk page saying that he/she couldn't access IRC either. It might also explain why ClueBot NG isn't working, though most RC patrolling bots, such as SineBot, are still okay as they use the API queries. I think that might be an idea - in case IRC goes down again, ClueBot NG should automatically switch to API, like Huggle does. It's slower, but it's better if vandalism was reverted one hour after it was made than never being reverted at all. K6ka (talk | contrib) 20:37, 17 January 2014 (UTC)
Or... not. While Huggle can access the IRC feeds just fine, ClueBot NG is still down. It may be an issue on ClueNet's end again. K6ka (talk | contrib) 21:46, 17 January 2014 (UTC)

Capitalization problem

I added a hatnote to Large-screen television technology because I didn't capitalize a T and TV technology sent me there. But there was no such redirect and my hatnote got changed because of a flag that the redirect didn't exist. Obviously, it does now, because I fixed it, but the redirect was from Tv technology.

This has surely been discussed but I have lots to do and will have to come back tomorrow.— Vchimpanzee · talk · contributions · 22:38, 17 January 2014 (UTC)

I'm not sure what your complaint is. You added the hatnote {{redirect|TV technology|the trade journal|TV Technology}} at a time where there was no redirect at TV technology, so {{redirect}} correctly added the article to Category:Missing redirects. User:Wbm1058 saw that and removed your hatnote. Maybe Wbm1058 should have changed the hatnote or created the redirect instead, but that isn't a technical issue. Are you saying that your hatnote should have automatically detected there existed a redirect at another capitalization Tv technology? I don't think that is possible without testing each potential capitalization one at a time, and that would be too expensive. Maybe Category:Missing redirects should include suggestions to check incoming redirects by clicking "What links here" and "Hide links". PrimeHunter (talk) 00:10, 18 January 2014 (UTC)
Just to be clear I did not completely remove the {{redirect}}, I changed it to a {{for}} (diff). If the editor truly believes that readers searching for "TV technology" will find themselves surprised to land on an article about television technology, then fine, I won't further contest a decision to explain it to the confused readers with a {{redirect}} hatnote. Wbm1058 (talk) 00:33, 18 January 2014 (UTC)
Per PrimeHunter's "testing each potential capitalization"; we do this over at Wikiproject Red Link Recovery and fix cases like this one as part of our normal process. We also catch missing diacritic marks, confusions of n and m dashes and many other cases where red links are very-nearly-but-not-precisely-like the title of an article, template or redirect. - TB (talk) 10:41, 18 January 2014 (UTC)
If you enter a title in the search box then you automatically find a redirect with any other capitalization. An editor going through Category:Missing redirects can certainly do that but since this was posted to the tech pump, the question may be whether a template like {{redirect}} can do it and produce different output depending on the result. mw:Help:Extension:ParserFunctions#.23ifexist only works for one capitalization. I don't know whether there is a way to do it in Lua. PrimeHunter (talk) 14:37, 18 January 2014 (UTC)
When I first ran across Category:Missing redirects it was a crowded and neglected maintenance category begging for attention. I enhanced several templates in the {{redirect}} family to populate the category, as it was only being populated by a minority of these templates. As far as I know, I am the only one who actively patrols this category, and as a result I create redirects all the time. You would be surprised at how many editors put {{redirect}} on top of an article, mistakenly thinking that is the way to actually create a #REDIRECT. So I create the xyzzy redirect and remove the template, as disambiguation to xyzzy (disambiguation) is unnecessary. So, please forgive me for simply simplifying the hatnote, and prioritizing my time by not bothering to create that particular redirect. And thank you, Vchimpanzee, for taking the time to create the redirect. I think the template functions fine as-is and shouldn't be modified to "work around" red links. Redirects are cheap, and fixing content forks is expensive. – Wbm1058 (talk) 15:10, 18 January 2014 (UTC)
  • I'm not entirely sure why Vchimpanzee posted this here either, I would have thought the Help Desk, the talk page of TV technology, or the talk page for the wikiprojects involving that would have been more appropriate. If there was some kind of template that could determine all of the existing capitalization possibilities as discussed here, what exactly would it be expected to do with that knowledge? Add the page to a category, perhaps? Place a hat note on the page, perhaps? Not sure this would be appropriate in most cases, and may cause confusion... Lua can't really do any more than a standard template in this case, and the big issue with using either one of them will be the fact that {{(pf)ifexist:}} has a limit of 500 call before it quits working and both Templates and Lua run into this issue. Now, I suppose, what would be great here is if there was a bot... @Anomie, Hasteur, Legoktm, Theopolisme, and GorillaWarfare: or any other "bot guy/gal" that might be interested, can one of you volunteer to help write a bot for this task of creating redirects to likely redirects for various characters or casing, assuming such a bot doesn't already exist... Technical 13 (talk) 17:45, 18 January 2014 (UTC)
I'm not sure what result I was expecting. I didn't realize I had caused a problem until later, and of course I was confused when I landed on this article that at the time looked completely different. I think my problem is that in some cases it has appeared the redirect existed when it didn't because I didn't capitalize something, but then later I discovered a red link or something. Or I might never have discovered the red link and it would have been a problem for someone else.— Vchimpanzee · talk · contributions · 18:23, 18 January 2014 (UTC)
Wait, I know. The only reasonable expectation is that because TV is sort of an acronym, the fact that I didn't capitalize the V should have somehow led to a solution. The other letters in "technology" besides the T wouldn't have been a problem.— Vchimpanzee · talk · contributions · 18:26, 18 January 2014 (UTC)
Looking at what has been said above, maybe the problem has been dealt with sufficiently.— Vchimpanzee · talk · contributions · 18:34, 18 January 2014 (UTC)

Incorrect notice following pagemove

Even when redirect creation is successfully suppressed during a page move, the special page confirming the move displays a notice at the bottom stating "A redirect has been created." This is a minor issue, but it is an unnecessary source of confusion. Is this an issue that can be fixed on-wiki or does it need to be reported at Bugzilla? Thank you, -- Black Falcon (talk) 06:52, 18 January 2014 (UTC)

bugzilla:45348: moving a page with suppressredirect produces misleading message "A redirect has been created". PrimeHunter (talk) 08:33, 18 January 2014 (UTC)

FlaggedRevs

Hi. Please help me to make a patch. Sincerely -- Дагиров Умар (talk) 13:51, 18 January 2014 (UTC)

File usage bug

OK who is ready for a brain bender? I was cleaning up WP:NFCC#9 issues and came across File:Corvus.jpg which Mediawiki lists as being used on 4 pages. So no big deal right? I went to remove the file and cant find it in the wikitext or any template being used. Odd, might be a cache issue, so I purged the pages where the file is used .... No go, still showing up. At this point Im scratching my head, as I cannot figure out why the file is being listed on a page where the file isnt displayed. I had one other thought perhaps it was a [[Media: link causing the false hit, After digging around, no luck. I finally decide to look at the HTML source of the article, and I discover that File:Corvus-illustration.jpg is the source. The file is on commons and is a file redirect to their version of commons:File:Corvus.jpg. Can someone please dig me out of this rabbit hole? Werieth (talk) 20:57, 18 January 2014 (UTC)

Wikipedia handles Commons redirects in a strange way. User:Haus clearly wants to use the Commons file in his userspace and this situation is very confusing, so I have moved away our local file. --Stefan2 (talk) 21:06, 18 January 2014 (UTC)
No Commons redirect, simple name clash. Local page deleted. — Edokter (talk) — 23:50, 18 January 2014 (UTC)

CirrusSearch now enabled

Hi all. The exciting day of new search is upon us. We've just enabled the new search backend for enwiki and we're starting to build the index now. What does this mean for your searches? Nothing yet. Right now you can only engage the new search engine via url parameters (&srbackend=CirrusSearch for API & Special:Search). Once we get the index built, we'll look at turning it on as a Beta Feature so more people can try it out. I'll keep this thread updated with indexing progress (honestly, we don't know how long enwiki will take just yet). As the index fills out you'll start to see more and more reasonable results. If you see any problems relating to the new search (Cirrus, elasticsearch, any term like that), please please let me know so we can fix it. Things should be mostly invisible to everyone right now while we're building things out, other than you'll see the job queue rise some (we'll be keeping an eye on it and try not to flood it). Thanks everyone! ^demon[omg plz] 17:14, 13 January 2014 (UTC)

Confirmed CirrusSearch matches pages changed within prior minute: Although the overall search-index is still being populated, we can already run instant near-real-time searches (including pages updated within recent minutes) by using the new CirrusSearch backend on typical Special:Search for text. For example, to search template-talk pages about recent "custom-text parameters" being discussed, use:

• https://en.wikipedia.org/wiki/Special:Search/?search=Template_talk%3A%20%22custom-text%20parameters%22&srbackend=CirrusSearch

Note the template-talk prefix is "Template_talk%3A" where colon ":" is encoded as "%3A" and spaces are "%20" in the URL encoding. Alternatively, just run a typical wp:wikisearch (MWsearch), and then rerun the URL with "&srbackend=CirrusSearch" appended, to also search pages recently edited within the prior minute. -Wikid77 08:40, 14 January 2014 (UTC)

You can also float pages with more recent edits to the top using some somewhat cryptic syntax. I don't know if that is useful for you.
• https://en.wikipedia.org/w/index.php?title=Special%3ASearch&profile=default&search=Template_talk%3Aprefer-recent%3A1,10+text&fulltext=Search&srbackend=CirrusSearch
The "1" means scale the whole document score and the "10" means that the half life of the score should be 10 days. You can leave off either or both of the numbers to get the defaults that are used on wikinews: 60% of the score is scaled at a half life of 160 days. NEverett (WMF) (talk) 20:26, 14 January 2014 (UTC)


Update on indexing status: we're churning away. Just passed the 9 million document mark, which is good. Trying to find ways to speed it up all the time. ^demon[omg plz] 20:11, 14 January 2014 (UTC)
Maybe there's a learning curve for using the new search. I tried it because the old search index is not being updated (yes, again). I expected about 150 results from searching "where played", but the new CirrusSearch gave me many thousands of hits, such as "where he played". That doesn't help me. I looked for detailed instructions on CirrusSearch, but haven't found any. Chris the speller yack 15:52, 19 January 2014 (UTC)
@Chris the speller: Try adding "~0" to the search - see mw:Help:CirrusSearch#Phrase search and proximity. -- John of Reading (talk) 16:08, 19 January 2014 (UTC)
Thanks, John, that worked. Even more thanks for the link to the help page. Chris the speller yack 16:29, 19 January 2014 (UTC)

Site-wide template auto-collapse issue

Tracked in Phabricator
Task T61912

As seen in the image, does anyone know what's going on? Templates on Firefox 26 is acting funny, while IE10 (which I never use), displays fine... Rehman 13:01, 18 January 2014 (UTC)

I see no issues here, using Firefox 26. Try purging the template. — Edokter (talk) — 13:11, 18 January 2014 (UTC)
It's on all templates, and on all pages using templates. On all 3 W7/FF PCs I use. Rehman 00:50, 19 January 2014 (UTC)
I seem to remember a beta feature (Near here) could be responsible for this. — Edokter (talk) — 13:13, 18 January 2014 (UTC)
You're right! The "Near this page" beta feature is what's responsible for this! Thanks. Rehman 00:52, 19 January 2014 (UTC)
I can confirm this for the latest version of Chrome for Windows (32.0.1700.76 m). — Scott • talk 22:00, 18 January 2014 (UTC)

Opt-in for pending changes

Is it technically possible to make it so an editor can opt-in to pending changes for a specific edit?

For example, if I am making a relatively small edit on an article where I have a COI. There is no need to discuss it on Talk, but because I have a COI, I think it would be polite and proper to have another editor approve it sort of speak. CorporateM (Talk) 14:53, 18 January 2014 (UTC)

If it's on a pending-changes article, you can make the edit and then unaccept it, since you're a reviewer. For people who aren't reviewers, or for non-pending-changes articles, it's not currently possible. The best we have is {{request edit}}. Jackmcbarn (talk) 17:57, 18 January 2014 (UTC)
Yah, I use Request Edit a lot, but I don't think anyone would be a happy camper with me submitting 20 Request Edits for various copyedits as part of a GA review or anything like that. OTOH, a quick click on the "approve" button as a formality to comply with WP:COI and Bright Line. It might also be great for new editors uncertain about their edit.
Do you think it's something I could reasonably beg and plead a technical person to make possible or would it be a huge thing? CorporateM (Talk) 19:00, 18 January 2014 (UTC)
Flagging one edit as "please review this" is an interesting idea. However, what would happen to subsequent revisions by non-reviewers before the edit is reviewed? Such revisions would incorporate the edit flagged for review, but I'm not sure we'd want further edits to be subject to review as well. The alternatives – auto-accepting, auto-rejecting or forcing the next editor to make a choice – don't seem great either.
Regardless of how that is answered, I imagine some effort would be involved in implementing this. – PartTimeGnome (talk | contribs) 20:19, 18 January 2014 (UTC)
@CorporateM: Another option is that you could also copy the article to the draft namespace, make your changes on the draft, and then put one {{request edit}} on the article's talk page to copy the draft to the article. GoingBatty (talk) 02:54, 19 January 2014 (UTC)
Meh, people generally don't want to do that, because they need to know what edits they are making by proxy. Otherwise they risk being hood-winked by a COI that did not accurately describe the changes between the two drafts. This happens a lot where a PR rep says it is "copyedits" but it is actually promotion. CorporateM (Talk) 14:40, 19 January 2014 (UTC)

Search results number

There used to be a setting in preferences to say how many results would be shown on each screen as the result of a search. I think the default was 20; I had mine set at 500, but now it is showing 100. Has something changed or am I missing something? SchreiberBike talk 00:35, 19 January 2014 (UTC)

Maybe it got removed on en? The preferences help at en does not mention that, but [66] does. RudolfRed (talk) 00:44, 19 January 2014 (UTC)
Hmm... there have been changes to search recently, though the loss of this option wasn't mentioned. Perhaps it was removed because the new search engine doesn't support it? (I'm just guessing.) – PartTimeGnome (talk | contribs) 17:49, 19 January 2014 (UTC)
It got removed. ^demon's reasoning was: "In this case, we've got a preference that's set to insane values on WMF wikis when it's mostly not functional. lsearchd is hardcoded to return only 50 maximum results, so any number above that's basically been useless since ~2009 or so." Legoktm (talk) 18:22, 19 January 2014 (UTC)
  • Max wikisearch shows 501 results & next 500: Using the "&limit=999" then the wp:wikisearch results-increment is set to 500, but the first screen will list 501 results, possibly a fence-post error. Appending "&limit=" is an alternative to setting Special:Preferences anyway. -Wikid77 05:40, 20 January 2014 (UTC)
I'm sure I was getting 500 per page last month, and the "View (previous 100 | next 100) (20 | 50 | 100 | 250 | 500)" is still available at the bottom of the list of results. And I see that I can work around it by modifying the search's url with a "limit=" statement. Could that be integrated into Template:Search link perhaps? Thanks for the info anyway. SchreiberBike talk 18:39, 20 January 2014 (UTC)

Integrate AfC into Article Alerts

It would greatly benefit the AfC reviewers and the backlog there if AfC articles could be marked with a Wikiproject and then added to the article alerts system. As with any other articles, the articles could then be detagged from the project, and if deleted the article is already automatically removed from statistics. Is there any way this might get done? --LT910001 (talk) 02:52, 20 January 2014 (UTC)

Please fix wp:CS1 cite month to show date

I am hoping several people can fix the protected wp:CS1 cite templates (Module:Citation/CS1) to again re-show the date from the "month=" parameter, and keep it fixed to always work. I suspect thousands of cites have been dropping the dates since last year. Compare {cite_web} to {cite_web/old}:

  • {{cite web |title=Test |url=http://loc.gov | month=September}} → "Test". {{cite web}}: Unknown parameter |month= ignored (help)
{{cite web/old|title=Test|url=http://loc.gov |month=September}} → "Test". September. http://loc.gov. 
{{cite web/old |title=Test |url=http://loc.gov | month=June 2013}} → "Test". June 2013. http://loc.gov. 

For several weeks, the "month=" parameter has been dropping dates, to show no date at all in many citations. Please re-fix the CS1 cite templates and then leave them alone. -Wikid77 (talk) 06:21, 20 January 2014 (UTC)

I think this discussion would be better off held at Module talk:Citation/CS1. Discussion seems relatively active over there, so you shouldn't have a problem with a lack of response. Although, bear in mind that the module's authors might have changed the behaviour of the month parameter on purpose. In my opinion, you will stand the best chance of not annoying the authors if you ask "why does this behave in this way?", rather than demand "please fix this and leave it alone". Remember that it doesn't pay to annoy the developers. ;) Hope this helps. — Mr. Stradivarius ♪ talk ♪ 09:07, 20 January 2014 (UTC)
The omitted-month dates has been mentioned there before, but there are so many other problems added/found with the Lua module, and it seems out of control. With 180 cite parameters, there are numerous ways to foul-up the prior citation templates, as the possibilites are endless. Fortunately, {cite_report} still handles "month=". I am thinking essay "wp:Template-glitch density" to describe templates which ruin article pages. -Wikid77 16:42, 20 January 2014 (UTC)
@Wikid77: Articles with CS1 citations that still use the deprecated |month= parameter are included in Category:Pages containing cite templates with deprecated parameters. I've updated the category page with an explanation of the issue. The Cite uses deprecated parameters error does not yet appear for your {{cite web}} examples for all users. Before that's enabled, Trappist the monk is running Monkbot over this category to fix these references. I think it would be good for Trappist to expand his bot to change |month=June 2013 to |date=June 2013. It might also be helpful if you could please provide an example of an article that only uses |month= without |date=, |day=, or |year=. Hope this helps! GoingBatty (talk) 13:28, 20 January 2014 (UTC)
|month= will be displayed if |year= is present. To display the month, you can either populate the year parameter or change |month= to |date=. Either one will eventually display an error, the former because of the deprecated month parameter (a bot will fix this for you) and the latter since |date=September is not a valid date per MOS. If you want to dig further, Module talk:Citation/CS1 is the place to do it, with examples of citations from actual articles. Thanks. – Jonesey95 (talk) 14:36, 20 January 2014 (UTC)
Thanks, as I had suspected the date handling was just getting worse each month, inventing more busy work where common-sense reasoning could tell what the month "September" was all about. Looks like wp:Template creep is well into ruining the formatting of citations. Other problems occur for typical 2-form ISBN numbers: {cite web|...|isbn=ISBN-10: 1234567890. ISBN-13: 1234567890123} gives error: "Title". ISBN ISBN-10: 1234567890. ISBN-13: 1234567890123. {{cite web}}: Check |isbn= value: invalid character (help). -Wikid77 16:42, 20 January 2014 (UTC)
The original query has been answered in multiple ways, and now the discussion is forking into specifics of the module's code. Let's continue these two discussion items at Module talk:Citation/CS1. See you there. – Jonesey95 (talk) 16:53, 20 January 2014 (UTC)

Tech News: 2014-04

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

Recent software changes

VisualEditor news

  • In the toolbar, the menu to edit the styles (like bold, italic, etc.) now has a down arrow (). The order of the Insert menu has also changed a little.
  • You can now edit <gallery /> tags with a very basic tool. [72]
  • You can now see a help page about keyboard shortcuts in the page menu. [73]
  • When you change categories, you will now see them when you save the page. [74]
  • When you edit templates, you will now see the parameters in the right order. The ones that you must add have a star (*). [75] [76]
  • The page will now be saved faster, thanks to a new way of coding the text that sends 40% less text to the servers. [77]
  • Your wiki can ask to test a new tool to edit TemplateData. [78]

Problems

  • There was a problem with search on the English and German Wikipedias between January 6 and January 14. You could not see new pages and changes in search results. [79]
  • There were "pool timeouts" errors on several wikis on January 13; it was caused by a code change that was made to fix another problem. [80]
  • On January 17, Bugzilla and Wikimedia Labs were broken for about 20 minutes due to network problems. IRC channels with recent changes (irc.wikimedia.org) were broken for about two hours. [81]

Future software changes

Orange bar with new messages
  • If you have removed JavaScript in your web browser, you will soon be able to see the orange bar saying that you have new messages. If you have changed how the bar looks with a gadget, you may need to change the gadget again. [82] [83]
  • You will soon be able to add a given Flickr user to a blacklist so that their files can't be uploaded using UploadWizard on Wikimedia Commons and other wikis. [84]
  • You will see a warning when you try to delete a page included in at least one other page. [85]
  • You will so longer see disambiguation pages in Special:LonelyPages. [86] [87]

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

10:22, 20 January 2014 (UTC)

Archive bots

Thanks all for your very responsive feedback to my previous queries. I'd like to know what the currently accepted archive bots are? I know there are quite a few around, but that only a few are still working. Is there one that is supported by WMF and/or semi-official? I want to add a bot to talk pages on some articles, but am unsure how. Would value some advice or pointers as to how to do this, what bot to use, and where to look for advice --LT910001 (talk) 11:02, 20 January 2014 (UTC)

@LT910001: You may want to look at User:MiszaBot/Archive HowTo for instructions on one of the popular archiving options. GoingBatty (talk) 13:30, 20 January 2014 (UTC)
None of the archiving bots are supported by WMF; and I don't think that any are official (semi or otherwise). The MiszaBot family no longer operate on English Wikipedia, but a page set up for archiving by those bots will actually be archived by Lowercase sigmabot III (talk · contribs). Another popular archiving bot - used on this page - is ClueBot III (talk · contribs). --Redrose64 (talk) 13:49, 20 January 2014 (UTC)
Thanks, as I think ClueBot III seems to work well. -Wikid77 17:14, 20 January 2014 (UTC)
Thank you all! --LT910001 (talk) 08:40, 21 January 2014 (UTC)

Spamming Template:C. and Circa

Another growing area of wp:template creep can be found with Template:C., which calls Template:Circa, where {circa|1856} gives "c. 1856" as originally to allow sorting with circa-dates. Perhaps step 1 would be to find who is actively spamming Template:C. into 1,000 pages or {circa} into 5,000 pages, and ask them to stop. If those cannot be stopped, then let's AfD delete those templates and recommend some form of sort-key template, and add examples of how to sort with "c. 1984" as a date/year. Obviously, people will create a template for every phrase in the language, and quick put it into a 1,000-5,000 pages, unless deterred. -Wikid77 17:14, 20 January 2014 (UTC)

That's a funny way to say you don't like something. If you want to TfD it, TfD it. — Scott • talk 17:23, 20 January 2014 (UTC)
  • Further options: We can have central discussion at Template_talk:Circa, with {c.} mentioned there, because there are other issues since created in November 2007, to reduce usage, but also improve "sortable=on" for wp:ACCESS perhaps by using "postition:absolute;left:-10000px" to handle more browsers, but add middle space for screenreaders, so option sortable=yes will give data: "1850 c. 1850". -Wikid77 00:35, 21 January 2014 (UTC)

Separating direct and indirect transclusions of templates

I'll take an existing template as an example to illustrate my question. Consider {{Lorem ipsum}}, which generates a nonsense text also called lorem ipsum. It takes one unnamed parameter {{{1}}} which specifies the number of paragraphs of text it gives. (It actually takes more, but this is just an example.)
Now suppose an editor creates a template {{Lorem ipsum 2}}, with soure code {{Lorem ipsum|2}}, to output exactly two paragraphs of lorem ipsum. (Note that a template {{Lorem Ipsum 2}} once existed and is now a redirect, but again, this is just an example.)

Now for my actual question. Pages which tranclude a template that itself transludes another template are counted as transcluding the other template in the WhatLinksHere pages. In the case of the example, "Special:WhatLinksHere/Template:Lorem ipsum" would also show pages that transclude {{Lorem ipsum 2}}, since the latter itself transcludes {{Lorem ipsum}}.
Is there a way to apply coding (such as a tracking category) only to pages that directly transclude a template, or in another way generate a list of direct transclusions only? I've tried using tricks like <include<noinclude/>only>, though that seems to work only if all templates are substituted (see these three sandboxes). SiBr4 (talk) 18:40, 20 January 2014 (UTC)

There isn't. But oh, if only... --Redrose64 (talk) 18:44, 20 January 2014 (UTC)
Well, thanks for the very quick response! SiBr4 (talk) 18:59, 20 January 2014 (UTC)

If it's not possible to automatically generate such a list, can I request a bot/script to generate a list of direct transclusions of a specific template, sorted by the parameters used? Or should I use another page for such requests? SiBr4 (talk) 11:52, 21 January 2014 (UTC)

Wikimedia Foundation Error

I keep getting "Wikimedia Foundation Error".

About an hour ago, I got it a couple of times; then a few mins ago, I got it every time I tried to save;

"Our servers are currently experiencing a technical problem. This is probably temporary and should be fixed soon. Please try again in a few minutes. If you report this error to the Wikimedia System Administrators, please include the details below. Request: POST http://en.wikipedia.org/w/index.php?title=User_talk:Jimbo_Wales&action=submit, from 88.104.24.157 via amssq49 frontend ([91.198.174.192]:80), Varnish XID 2393050699 Forwarded for: 88.104.24.157 Error: 503, Service Unavailable at Mon, 20 Jan 2014 20:30:52 GMT"

What's the problem? — Preceding unsigned comment added by 88.104.24.157 (talk) 20:35, 20 January 2014 (UTC)

You mean like the screenshot that I've just pasted into this section? It means that the page you were editing was so large that the servers took too long to process it, and gave up. Apparently this page was User talk:Jimbo Wales, which does get huge every few days. First, check your contributions, and if the edit is there, all well and good; if it's not, try and save it again. --Redrose64 (talk) 20:56, 20 January 2014 (UTC)
I got the same error on this page. And other pages, which are not large. Repeatedly.
I don't think it's just a 'huge page' problem. — Preceding unsigned comment added by 88.104.24.157 (talk) 21:12, 20 January 2014 (UTC)
Agreed, as the Jimbo talk-page was archived 30% smaller at 15:00, to reformat in 2 seconds, and should not cause a WFEM timeout error. -Wikid77 23:17, 20 January 2014 (UTC)

Also, I just tried to look at a page history, and got;

XML Parsing Error: unexpected parser state Location: jar:file:///C:/Program%20Files%20(x86)/Mozilla%20Firefox/omni.ja!/chrome/toolkit/content/global/netError.xhtml Line Number 308, Column 50:

&netReset.longDesc;

-------------------------------------------------^ — Preceding unsigned comment added by 88.104.24.157 (talk) 21:14, 20 January 2014 (UTC)

That error message, with "Program Files (x86)/Mozilla Firefox..." seems like a local Firefox browser error. -Wikid77 (talk) 23:17, 20 January 2014 (UTC)
See WP:WFEM. ~ J. Johnson (JJ) (talk) 22:11, 20 January 2014 (UTC)

Deletion warning in new version of MediaWiki

With the latest update, we get a warning when attempting to delete most pages: "Warning: Other pages link to the page you are about to delete". Most of the time, a page's creator will be warned about its deletion, many deletion-taggers log their tagging on a dedicated page (example), and many pages in CAT:CSD will end up being linked by userspace or WPspace pages (example) that are set up to track CSD-tagged pages. Is there any benefit to using it here, or any benefit to paying attention to it? Nyttend (talk) 06:36, 10 January 2014 (UTC)

I haven't tried it myself yet, but it sounds like it would be very useful if it could be configured to display a warning if the page had incoming redirects or transclusions, rather than just links. And maybe links from mainspace would be useful too? — Mr. Stradivarius on tour ♪ talk ♪ 07:45, 10 January 2014 (UTC)
This was the result of feature request 35485 —TheDJ (talk • contribs) 07:51, 10 January 2014 (UTC)
I would add that this feature is probably more useful for small wikis. Pages up for deletion here will almost always have incoming links. I suppose we could just blank the message if we don't want it. — This, that and the other (talk) 10:10, 10 January 2014 (UTC)
Restrict it to mainspace links, redirects, and transclusions, and I'd welcome it, and I can see how this would be much more of a thing for smaller wikis. Wouldn't complain about blanking either. Nyttend (talk) 23:02, 10 January 2014 (UTC)
I agree with Nyttend. The message as it is is meaningless, and I would welcome a facility to turn it off, because it will be a very rare page which doesn't have any incoming links. JohnCD (talk) 23:08, 10 January 2014 (UTC)
  • I agree with Nyttend. It must be restricted to mainspace links (surely redirects are mainspace links?) and transclusions. — RHaworth (talk · contribs) 14:13, 11 January 2014 (UTC)
some more spaces where the warning is desired come to mind: template, portal, book, help, and possibly others. it probably should be fine to mask links from talk spaces (including all the "XXX talk"), WP and user space. peace - קיפודנחש (aka kipod) (talk) 18:14, 11 January 2014 (UTC)
I agree with everything said above. I've seen two situations where this feature would have been useful:
  1. Someone mistakenly G6-tagged a couple of templates that were in use. An admin deleted them without checking properly (the templates were subsequently restored). A warning that the template still had transclusions would have prompted the deleting admin to check more carefully.
  2. I've found a couple of broken redirects left behind after deletions. A warning to the deleting admin would prompt them to delete or re-target these redirects.
For this feature to be useful, it needs to only warn about those cases that matter. Counting links in notifications left on talk pages and in deletion discussions means the warning will appear for almost every deletion, so will be ignored. There are many possible enhancements we could suggest on Bugzilla to make this more useful. – PartTimeGnome (talk | contribs) 22:17, 11 January 2014 (UTC)
The feature, as is, would probably end up being ignored due to banner blindness; unless we end up having some means of showing the warning only when it's likely to matter, we're better off removing it completely. (And some times speedy-deletable pages will have incoming mainspace links - either created by the author of the speedy-deletable page, or a user created a speedy-deletable page with a linked-to title.) עוד מישהו Od Mishehu 08:55, 12 January 2014 (UTC)
  • I agree with Nyttend, PartTimeGnome, and others here. Substantially every page that is up for deletion ought to be linked to from some other page -- often a user talk page, warning the article creator that the article they started is up for deletion. But links like that are not worth warning the deleting admin about. --Metropolitan90 (talk) 19:04, 12 January 2014 (UTC)
  • @Nyttend:,@Metropolitan90:,@RHaworth:,@Mr. Stradivarius:, et al.: If y'all are curious, I stumbled across this page and wrote User:Writ Keeper/Scripts/backlinkWarner.js; if you install it, it'll add separate warnings to that box for mainspace links (as opposed to any ol' link) and also warnings for redirects (my brain is too fried to figure out the API call for transclusions so far)done. Writ Keeper ⚇♔ 00:51, 14 January 2014 (UTC)
  • Thank you. Is there any way that we could make it default for everyone, e.g. putting it into the site JS? Or would this be overkill, since it would load for all non-admin users as well, and on every page? Nyttend (talk) 01:00, 14 January 2014 (UTC)
  • Script content can be loaded on a per-group context, which in this case would be MediaWiki:Group-sysop.js. §FreeRangeFrogcroak 01:07, 14 January 2014 (UTC)
    It could also be placed in a gadget with default|rights=delete in its gadget definition. The gadget would only be available to administrators and would default to on for them. – PartTimeGnome (talk | contribs) 23:46, 14 January 2014 (UTC)
Sounds good WK. All we need is mainspace links and transclusions, not everyone's CSD list and talk page mention. So far, I think I've seen one or two pages where this thing didn't appear. Peridon (talk) 11:29, 14 January 2014 (UTC)
Err, how does one install it? I probably should know, but I do very little technical twiddling these days... Peridon (talk) 11:31, 14 January 2014 (UTC)
@Peridon: Sure, just add importScript("User:Writ Keeper/Scripts/backlinkWarner.js"); to your common.js page. Writ Keeper ⚇♔ 17:55, 14 January 2014 (UTC)
That won;t have had any effect. A link to a user page (which is all that a ping is) only trigers a notification if it is signed as part of the same edit. If you want to ping Peridon, you need to create a new signed edit, as I jsut did. DES (talk) 18:02, 14 January 2014 (UTC)
Yeah, I know that. I actually deleted my old sig on that post and replaced it with new tildes, since I know it's dependent on the post being signed, but apparently that's not enough. Writ Keeper ⚇♔ 18:05, 14 January 2014 (UTC)
Oh I failed to notice you had replaced the sig. Maybe that was enough then, I'm not sure. Well, no harm done if s/he gets 2 pings. DES (talk) 18:16, 14 January 2014 (UTC)
Actually, I don't think it was; after I did it, I got to wondering whether it worked; tested it from my test account, and it didn't seem to, so... Writ Keeper ⚇♔ 18:30, 14 January 2014 (UTC)
Thanks. Only one ping - from DES. I'm a 'he', by the way. Peridon (talk) 18:37, 14 January 2014 (UTC)
For an edit to trigger a user mention notification, Echo looks for signature-like text being added to the page: a full timestamp and a link to the editor's user, talk or contributions page. Writ Keeper's ping overwrote a previous signature; much of the new signature text was the same as the old, so did not count as being added to the page. – PartTimeGnome (talk | contribs) 23:56, 14 January 2014 (UTC)
@Writ Keeper: You shouldn't use "wgTitle" because it will leave the namespace part out. For example, if I am deleting Template:Navbox, there will be no message "There are pages that transclude this page" because wgTitle = "Navbox", not "Template:Navbox". --Nullzero (talk) 06:21, 15 January 2014 (UTC)
I'm getting confused. I installed that thing per instructions, and @Writ Keeper: redid it with another version. I'm still getting talk page links, and some times a red warning about redirects (useful) and a red warning about pages that transclude the page I'm about to delete. I don't tend to delete templates, but what transcludea an AfC page, or a main space article - and what am I supposed to do with it if I even manage to identify it? Peridon (talk) 16:10, 19 January 2014 (UTC)
@Peridon: Well, to identify it, you can just click on the "What links here" link for that page; it'll list all the pages that link to it, and say whether it's a transclusion or not. As for the warning, well, I'm not sure, but for some things, Wikipedia (that is, WhatLinksHere, the API, everything, not just my script) is saying that the page transcludes itself. If it's not something that's normally transcluded (e.g. an article or draft), you're probably fine to just ignore the transclusion warning. Writ Keeper ⚇♔ 19:08, 21 January 2014 (UTC)
Still confused... I've come across templates being transcluded, and managed to do it to my RfA (don't ask me how...), but I didn't know that articles were transcluded. I've also not seen any comments in WLH about transclusion. Just links and redirect page. I've dealt with redirect pages (as usual) and ignored the transclusion warning. Nothing seems to have blown up or collapsed yet. Peridon (talk) 19:22, 21 January 2014 (UTC)
is flow here yet? Well, technically speaking, any page can be transcluded; there's nothing special about templates that allows them to be trancluded. Basically, any time you put any page's name in the double curly braces (as in {{User:Writ Keeper}}), that page's contents will be inserted into the page when the page is rendered, which is what transclusion is. It's just usually not helpful to insert one page's content into another's, unless it's something like a template or an RfA (where you insert the content of your RfA into the general WP:RFA page). Anyway, I've added a check to catch this weird self-transclusion thing (it's weird because you'd never need to insert a page's content into itself, since the content is already there, plus there are infinite recursion issues), so you shouldn't see any more transclusion warnings when you don't expect it. Writ Keeper ⚇♔ 19:32, 21 January 2014 (UTC)

Does the mw:Extension:Disambiguator have a MagicWord to count the amount of the page which have the DISAMBIG?

I want to calculate the amount of the page which is the disambiguation page.Now I use the {{PAGESINCATEGORY:<the category's name of the disambiguation page>}} to calculate it,but I hope my formula can work in any plan beacause of the difference of the category's name in different plan.Thank you for help.--Cwek (talk) 04:00, 16 January 2014 (UTC)

No magic word, but
MariaDB [enwiki_p]> select count(*) from page_props where pp_propname="disambiguation";
+----------+
| count(*) |
+----------+
|   242120 |
+----------+
1 row in set (0.38 sec)
Legoktm (talk) 09:22, 17 January 2014 (UTC)

Streamlining page moves over redirects?

Moving a page over a redirect is becoming less likely to succeed because so many minor adjustments are being made to redirect pages. Many of us are allowed to move over a redirect if it has just one line in its edit history, but have to request a page move in other cases. Would it be difficult to relax these restrictions so that multiple edits of rather minor sorts would not hold up a page move? A case where Avicbot had fixed a double redirect is discussed at Talk:Gomphocarpus fruticosus, and there is some more discussion on my talk page. Some of these edits are manual, and some made by bots. Category additions are one type, and template additions such as the "redirect to …" and the "R from …" templates. Sminthopsis84 (talk) 19:57, 18 January 2014 (UTC)

Nothing we can do at this end; it would need a amendment to the MediaWiki software. Please file a feature request at bugzilla. --Redrose64 (talk) 20:17, 18 January 2014 (UTC)
Before you do, please define "of minor sorts" in a manner that can be determined quickly and unambiguously by a computer program. Anomie⚔ 22:02, 18 January 2014 (UTC)
Thank you both, this is clearly beyond my knowledge realm, so I'll drop the matter. Sminthopsis84 (talk) 22:04, 18 January 2014 (UTC)
Here's one way to define it: allow a redirect to be overwritten if all of its revisions are redirects to the page being moved over it, and the redirect does not have any form of protection. So that MediaWiki doesn't have to look over potentially hundreds of revisions, also include a restriction that there must be fewer than 20 revisions. Any change to a redirect that does not change its target or turn it into an article is minor enough to allow it to be overwritten, to my mind. Under this system, should there be a special case that must not be overwritten, an admin could semi-protect it. – PartTimeGnome (talk | contribs) 22:14, 18 January 2014 (UTC)
That won't handle the relatively common case of double redirect fixes though, because they will have pointed to a different target at some point. Anomie⚔ 23:07, 18 January 2014 (UTC)
@Anomie: What if, as long as the page has never been anything but a redirect, regardless of target, allow moving over it? If that would lend itself to abuse, then require that the initial revision must have pointed to the page being moved over it. Jackmcbarn (talk) 23:13, 18 January 2014 (UTC)
The former would allow the vandal to retarget a redirect and then move over it, which seems open to abuse. The latter would still not handle double redirect fixes. Anomie⚔ 01:18, 19 January 2014 (UTC)
Regarding the former, how big of a problem would it be if vandals could move pages over unrelated redirects? The code could be changed to put the deleted revisions in deletedhistory instead of sending them down the memory hole to make cleanup of that easier. (And only autoconfirmed users can do that anyway, so it's not like it would be an everyday occurrence.) Regarding the latter, you could handle that if, for example, A was moved to B and then C, by just moving C to B before moving it back to A (which I've successfully done before in cases where nobody "fixed" the double redirect before I got to it). Jackmcbarn (talk) 01:24, 19 January 2014 (UTC)

The former is even worse: A candal could move a page, then move some other page over that redirect. This would make a bigger mess. Iwould propose the following: The target has never been anything but a redirect either directly to the source page, or something else that has only ever been a redirect and is currently a redirect to the page in question. That would fix my issue; and would allow reverting multiple page moves. I think that Jackmcbarn's problem with the former is less serious - and if the revisions are somehow retained, we don't need to worry about it much. To the average reader, it's no diferent than converting an article into a redirect; to the vandalism fighters, just revert the move and fix the redirect. עוד מישהו Od Mishehu 20:40, 19 January 2014 (UTC)

Vandal wants to move page A to B, but a page exists at B. So he moves B to C then to D, then changes the redirects at B and C to point to A before a double-redirect fixer gets to it, then moves A to B. This is allowed because B has always been a redirect (to C then A), and C has also always been a redirect and currently points to A. Now you could fix that by requiring that C has always pointed to A or a another redirect under the same terms, but then you're getting into a growing number of pages that need checking. Anomie⚔ 21:06, 19 January 2014 (UTC)
If my second proposal (all revisions must have been redirects, and the earliest must point to the page to be moved over it) were done, though, wouldn't that just mean that if 2 moves are made, 2 moves must be done to undo it, without adding potential for more vandalism, and without causing a web of pages to need to be checked every move? Jackmcbarn (talk) 21:10, 19 January 2014 (UTC)
A partial solution: How about having bots that make such edits tag them as "okay to page move over." If ALL of the edits of a page except the first one are 1) made by bots (we can change this later if needed) AND 2) have the "okay to page move over" flag, THEN any mere mortal can move-over-redirect. This should cover at least half of the "simple cases" of page moves blocked by multiple minor edits. Yes, this would require editing the Wikimedia software but at least it's well-defined and there's no room for guesswork or abuse-by-vandal. davidwr/(talk)/(contribs) 03:09, 23 January 2014 (UTC)
  • Also needing to be taken into consideration is just because a page is a redirect, does not mean there isn't other content on the page. See Category:Redirect templates and I remember there being a Bugzilla ticket requesting that redirects get processed to allow those templates to display (not just add categories) and to allow parserFunctions to dictate where the redirect goes, but I can't seem to find it right now. Technical 13 (talk) 16:01, 23 January 2014 (UTC)
Question: as the suggester I was out of my depth and stated above that I would drop the matter, but in light of the inspiring discussion above, I wonder if the request of me to file a feature request at bugzilla is still open. Has that effectively been handled already, or should I do that? Sminthopsis84 (talk) 16:41, 23 January 2014 (UTC)
You may most certainly still do that. At very worst it will be closed as WONTFIX and will note that it has been requested before. Just make sure to link to this discussion in your request so the developer that reviews it has the full context. Technical 13 (talk) 19:56, 23 January 2014 (UTC)
It's bug 60383. Sminthopsis84 (talk) 23:14, 23 January 2014 (UTC)
@Technical 13:The same issues you raise apply (at least in theory) to redirects which only have one edit. davidwr/(talk)/(contribs) 19:40, 23 January 2014 (UTC)
Yes, but the likely-hood of there being an issue caused by this increases with every edit. Where should the threshold be? Technical 13 (talk) 19:56, 23 January 2014 (UTC)
The difference is that normal editors can move-over-redirect if there is only 1 edit. If the presence of "other content" should prevent move-over-redirect, then we should disable move-over-redirect for most editors or at least have a way of "fully undoing" the move and restoring the full previous content. If the presence of this content in a redirect is not an issue for a redirect with only 1 edit, then I'm not seeing how it would be an issue if there was more than one edit (assuming of course that this is the ONLY issue with the various edits). davidwr/(talk)/(contribs) 20:10, 23 January 2014 (UTC)

Convenience break in MoR discussion

  • Perhaps a Bugzilla: issue should be created that disallows normal editors from moving any redirect that has "other content"? I would support that if there is consensus. Technical 13 (talk) 20:16, 23 January 2014 (UTC)
  • Certain common, safe-to-lose-the-content cases would need to be exempt, such as "move over my own edit that happens to be the only edit in a redirect" (this would be a special case of db-user) and "move over other content that is typically created as part of the move process" such as {{R from move}} or which are typically created for manually-created redirects but which would never need to be preserved, such as the "R from" and "R to" templates listed in Template:R template index, as well as other templates that do not need preserving, like {{This is a redirect}}. davidwr/(talk)/(contribs) 20:36, 23 January 2014 (UTC)

Echo

Tracked in Phabricator
Task T58828
See also: mw:Thread:Talk:Echo (Notifications)/Why can't we thank IPs?
The feature in question.

The Echo feature appears to be limited to logged in users only. Do we want to disable it until it does, per Wikipedia:IPs are human too? --Gryllida 14:47, 20 January 2014 (UTC)

Sorry, what has Echo got to do with archive bots? AFAIK if a bot archives a user talk page, you don't get a notification. Is your problem that you do want a notification when your talk page gets archived? --Redrose64 (talk) 14:54, 20 January 2014 (UTC)
I didn't type a heading name. I did, now. Gryllida 21:13, 20 January 2014 (UTC)
Some things, like Echo, Watchlists and Preferences, are inherently associated with registered accounts. I don't see anyone advocating we turn off the other two, I don't see why would we turn off this one :) Matma Rex talk 11:16, 21 January 2014 (UTC)

WikiData gone awry?

What has happened to the WikiData links to equivalent articles in other languages. They seem to have disappeared and it's impossible to add them. Voceditenore (talk) 19:19, 20 January 2014 (UTC)

They're there, but are in a rather silly font which takes time to download. You can force the font to be the same as the rest of the page - and thus speed things up - by putting 
#p-lang li.interlanguage-link, .autonym { font-family: inherit; }
into Special:MyPage/common.css --Redrose64 (talk) 19:50, 20 January 2014 (UTC)
Thanks! I managed to get them to appear without adding the code, by waiting a bit after I clicked Languages. Best, Voceditenore (talk) 19:04, 23 January 2014 (UTC)

Pool queue is full

FYI FWIW Trying to perform a search on en.wiki I was just greeted with "An error has occurred while searching: Pool queue is full". Subsequent searches did work... Palosirkka (talk) 10:34, 21 January 2014 (UTC)

Yeah, this happens sometimes. WMF's top people (^demon and manybubbles) are working on a replacement. Matma Rex talk 11:15, 21 January 2014 (UTC)
I'm glad someone thinks I'm a top person. NEverett (WMF) (talk) 15:43, 21 January 2014 (UTC)
Hehe, thanks for the info and for working on Wikimedia! Palosirkka (talk) 15:37, 23 January 2014 (UTC)

Universal language selector

Tracked in Phabricator
Task T48306

Hi everyone,

Universal Language Selector was disabled on all Wikimedia Foundation wikis a little while ago due to a performance problem. It is an opt-in feature for logged-in users. This may not be a big issue for most users here at the English Wikipedia, but this means:

  • several wikis with less than optimal system level font support
  • OpenDyslexic font is not available
  • web-based input method editors are not available (affects all users)
  • the translate extension is broken for wikis that use it for page translation (fixed)
  • Wikidata affected by the non-availability of ULS's js APIs (ULS enabled by default on Wikidata)

I don't know how quickly this will be resolved, but the hope is "soon". If you know people or projects that will be affected by this, please share the news. Whatamidoing (WMF) (talk) 18:03, 21 January 2014 (UTC)

You can re-enable ULS by selecting it in the language section of your Special:Preferences. Legoktm (talk) 18:04, 21 January 2014 (UTC)

Feedback request: VisualEditor special character inserter

The developers are working towards offering Wikipedia:VisualEditor to all users at about 50 Wikipedias that have complex language requirements. Many editors at these Wikipedias depend on being able to insert special characters to be able to write articles.

A special character inserter tool is available in VisualEditor now. They would like to know what you think about this tool, especially if you speak languages other than English. To try the ⧼visualeditor-specialcharacterinspector-title⧽ tool:

Screenshot of TranslateWiki interface
The “insert” pulldown on the task bar of VisualEditor will lead you to the ‘⧼visualeditor-specialcharacterinspector-title⧽’ tool.
Screenshot of Special Characters tool
This is the ⧼visualeditor-specialcharacterinspector-title⧽ inserter. Your feedback on this tool is particularly important.

To let the developers know what you think, please leave them a message with your comments and the language(s) that you tested at the feedback thread on Mediawiki.org or here at the English Wikipedia at Wikipedia:VisualEditor/Feedback. It is really important that the developers hear from as many editors as possible. Thank you, Whatamidoing (WMF) (talk) 20:18, 22 January 2014 (UTC)

Playing our audio and video on iOS and Android devices

Following discussion on Commons:Village pump, about the difficulty of playing Wikimedia audio and video on mobile devices, we've added red links to Commons:Media help, for iOS and Android. I'm sure some of the readers of this page have the requisite knowledge, to populate those pages; so please do!

The issue arose during |a project I've been running with the BBC, in which they've released clips of broadcast material under open licence, for the first time.

Assisting mobile users, on any of our projects, to play our media more easily will lend weight to future requests to other archive holders, to release audio-visual resources under open licences. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:38, 22 January 2014 (UTC)

Error creating data template

I've created Template:Data Philippines. I started off with content copied from Template:Data United States, with parameter values adjusted for the Philippines. However, in the Derived data data section, I get an error saying Expression error: Unrecognized punctuation character "[". I've apparently done something dumb, but I don't see what it might be. I'd appreciate some help. Thanks. Wtmitchell (talk) (earlier Boracay Bill) 02:17, 23 January 2014 (UTC)

The error message disappeared when I purged the page. PrimeHunter (talk) 02:27, 23 January 2014 (UTC)
Great. I guess I didn't do something dumb after all -- just didn't do enough things correctly. I'll spiff up a few things on the template and move forward. Thanks for the help. Wtmitchell (talk) (earlier Boracay Bill) 11:53, 23 January 2014 (UTC)

Speedy template

Ican;t figure this out , but CAT:CSD is including many articles that have never been nominated for deletion. This isn;t a question of whether they should be listed, but that they simply have not been, as shown in the article history. eg. Collinsville Power Station , Climate change policy of the United States , Ralph Keeling , Citroën C3 Aircross Many of them seem on environmental subjects, so I wonder if someone is tinkering with them in some fashion. I do not see any relevant hidden categories. DGG ( talk ) 04:44, 23 January 2014 (UTC)

It originates from a {{db-move}} transcluded from Template:CO2. The version with db-move has since been deleted but it can take a long time before affected categories and pages are updated. PrimeHunter (talk) 05:00, 23 January 2014 (UTC)

AFD page

I'm running into a technical issue with a WP:AFD discussion, which I thought I should bring to somebody's attention.

I first created Wikipedia:Articles for deletion/Rock for Dimes on January 15, and correctly transcluded it to the correct day's AFD log; however, a couple of days later a bot incorrectly detected it as not transcluded anywhere, and thus added it to the AFD log for January 18. I've since removed it from the later day, as there's no need to have the same discussion transcluded into two separate active AFD daylogs at the same time. However, I can see a possible reason for the bot error nonetheless, as even with the page correctly transcluded on January 15, that daylog seems to be dropping from the discussion page's "what links here" list at random and unpredictable intervals — which, I suppose, might cause an automated tool to incorrectly assess the page as not being transcluded anywhere even though it actually is.

Can somebody check into whether there's a database issue that's causing that page's transclusion status to fluctuate? Thanks. Bearcat (talk) 22:12, 20 January 2014 (UTC)

Interesting. I created an AfD last night (my time) and transcluded it to the log that came up when I clicked the proper link on the WP:AFD page instructions. Turns out that the log that came up when I clicked that link was for the previous UTC calendar day, so a bot detected it had not properly been transcluded. Risker (talk) 22:28, 20 January 2014 (UTC)
Bearcat: You created Wikipedia:Articles for deletion/Rock for Dimes on January 16 UTC time, but added it to the AfD log for January 15. Risker: I guess you used the link "Today's AfD log" at Wikipedia:Articles for deletion. That link may point to an earlier day if the page needs to be purged. The page has a purge link on "Click here to refresh this page". I don't know whether Cyberbot I is so picky that it treats the previous day as no valid transclusion (User:cyberpower678 could probably say). Or maybe it thought there was no transclucion at all. If a template or transcluded page somewhere got messed up then it might actually have prevented the transclusion from working on the AfD log when Cyberbot I checked it. PrimeHunter (talk) 23:28, 20 January 2014 (UTC)
I think the bot should have enough tolerence to allow discussions from the first hour of any given day to be transcluded on the previous day log. עוד מישהו Od Mishehu 08:44, 21 January 2014 (UTC)
Just for the record, I transcluded the debate into the daylog that I was taken to by clicking on the "list" link in step 3 of the template — so essentially what happened, thus, is exactly the same as what happened to Risker. And if it took me to the wrong date, that's still a technical error on the server end rather than my error. Either way, the bot has now retranscluded my page a second time, this time into the daylog for January 22 — which is still something that shouldn't be happening at all, as the page still has no need of being transcluded into two active daylogs at the same time. Bearcat (talk) 03:16, 22 January 2014 (UTC)
Anyway, this is a combination of known server cache issues, and a bot which is the responsibility of cyberpower678 - so there is no need to continue the discussion here. עוד מישהו Od Mishehu 06:43, 22 January 2014 (UTC)
  • I can't find any error with the bot. My best guess for this one is a caching issue and Cyberbot is not seeing the transclusion.—cyberpower ChatAbsent 19:27, 24 January 2014 (UTC)

Login Problems on Chrome

Hello. I can't login to Wikipedia on Chrome (version 32.0.1700.76 m). I type my username and password, click Login, and get redirected back to the login page. Any help is greatly appreciated. --Mayfare (talk) 01:39, 21 January 2014 (UTC)

Double check that your browser is keeping the cookies. This is a likely source of this problem for any browser - especially if you're having login problem on other web sites. עוד מישהו Od Mishehu 08:38, 21 January 2014 (UTC)
So there is not even a message displayed? It just silently shows the same login page again? --AKlapper (WMF) (talk) 13:01, 21 January 2014 (UTC)
As of my reboot last weekend, I've had the same problem. Yes, AKlapper, it just returns me to the logon screen, with my user name preloaded. When I try to edit a page, I'm dumped back into the editor with none of my edits visible, in fact I'm now editing the entire page instead of just the one section where I started. (This started happening whilst I was still logged in, but it does the same when I'm not, IP visible.) WesT (talk) 02:19, 26 January 2014 (UTC)

BBCode → Wiki markup

Hello. Are there free converters in working condition? Thanks.--Парис "Анима" надаль (talk) 13:40, 24 January 2014 (UTC)

Have you looked at / tried http://pear.php.net/package/Text_Wiki/ and https://www.mediawiki.org/wiki/Extension:BBCode ? No idea if they work but they look like the closest you can find. --AKlapper (WMF) (talk) 13:50, 24 January 2014 (UTC)
Yes, I saw these references, but I am afraid that very small my technical knowledge are in an order to understand and understand, that to do farther with the begun to swing files of formats .tgz and tar.gz . :-(
Am sorry I, and are there in good condition online-converters? All those converters, that I found in the Internet, did not execute the work. Only: http://www.rpgdl.com/wiki/BBwiki.php, but this converter assumes very much inaccuracies in the process of converting. Thank you.--Парис "Анима" надаль (talk) 14:41, 24 January 2014 (UTC)
The extension will only work if it is installed here, which it is not. --  Gadget850 talk 14:46, 24 January 2014 (UTC)
In Russian Wikipedia, where I conduct the most of the time, also costs no extensions. Also I have a test wiki. I made a request to connect any of the extensions and got the following reply.
By testing the online converters , I found the only option with the correct conversion web links. BBCode → HTML, HTML → Wikitext, — defects are present, but from present variants in my opinion the best, that is present. I will leave references here, because maybe other users will have the same problem. Thanks.--Парис "Анима" надаль (talk) 19:05, 24 January 2014 (UTC)
I've considered creating a userscript or gadget or special page that will allow a user to convert from various types of coding to wikitext, I just haven't gotten around to it. I envision a textbox of some type that will allow formatted text to be pasted in, a dropdown list being offered for the user to select what formating their source has and a button to convert to wikitext. The page would then reload (or open a new tab or a new section on the page) with a chunk of code the user can copy and paste into a wiki page with proper formatting. I'll move this project up a few notches on my todo list, but it still might take me a while to iron out all of the details of how it should function. In the mean time, my answer to the OP is this, You can always start a new section on your talk page, start it with {{Help me}}, then paste your BBCode in a <syntaxhighlight>Put your [b]BBCode[/b] here</syntaxhighlight> and ask if someone can convert it to wikitext for you. Technical 13 (talk) 15:07, 24 January 2014 (UTC)
Many thanks, I will do so, if I will appear in a difficult situation.--Парис "Анима" надаль (talk) 18:43, 24 January 2014 (UTC)

API query for redirects to a page

Is there a way to get a JSONp result from an API for all the pages that redirect to an article? I'm at a hackathon, so a speedy answer would be awesome! Ocaasi t | c 19:24, 24 January 2014 (UTC)

https://en.wikipedia.org/w/api.php?action=query&list=allpages&format=jsonp&apfrom=Criteria_for_speedy_deletion&apcontinue=Criteria_for_speedy_deletion&apnamespace=4&apfilterredir=redirects&aplimit=10 for example perhaps? Technical 13 (talk) 19:38, 24 January 2014 (UTC)
If that doesn't work exactly how you want, you could probably do something like https://en.wikipedia.org/w/api.php?action=query&list=allpages&format=json&callback=result&apfrom=Criteria_for_speedy_deletion&apcontinue=Criteria_for_speedy_deletion&apnamespace=4&apfilterredir=redirects&aplimit=10 Technical 13 (talk) 19:41, 24 January 2014 (UTC)

CSS

It′s possible to create a template what use my own CSS rule undeclared in MediaWiki.css? (template [with this CSS style] should be visible for all the same, not only for me) --XXN (talk) 21:40, 24 January 2014 (UTC)

Yes, we have MediaWiki:Common.css. Legoktm (talk) 22:12, 24 January 2014 (UTC)
  • We also have MediaWiki:Vector.css, MediaWiki:Monobook.css, MediaWiki:Cologneblue.css, and MediaWiki:Modern.css as skin specific all user stylesheets. I believe it is also possible to create special usergroup or namespace or projectspace css to be automatically applied to the proper groups or pages. However, all of these pages and options are restricted to be created and/or edited by an administrator. You will need and exact use case of what you want accomplished, sample code that can be tested in a sandbox and appropriate testcases, and a community consensus to implement said code in order to get any of these enacted. 22:29, 24 January 2014 (UTC) — Preceding unsigned comment added by Technical 13 (talk • contribs)

I think the question is about attaching a CSS file to a template, such that the CSS has effect in all pages that transclude the template. This cannot be done, though it is possible to use style= to include in-line CSS in a template. E.g. &lt;span style="color: red"&gt;Example&lt;/span&gt; → Example. – PartTimeGnome (talk | contribs) 00:05, 25 January 2014 (UTC)

If that were possible, it would help at Help talk:Table#Help with Wikitables. --Redrose64 (talk) 00:15, 25 January 2014 (UTC)
Thank you. I have to define some classes. And how i see is not possibly, so i leave this idea. XXN (talk) 03:07, 25 January 2014 (UTC)
This is something that will be worked on in the not so far future, since the developers want to get rid of the usage of inline styles for templates, which have a big set of problems that is preventing us from enabling truly responsive (adapt to many screen sizes) lay outing of the content. It's one of the bigger new developments that will happen over the next year. It is good to see that users have identified similar missing functionality. —TheDJ (talk • contribs) 10:29, 26 January 2014 (UTC)
FYI:
Helder 12:45, 26 January 2014 (UTC)

Watchlist history

I had about 8000 pages in my watchlist. On day i decided to delete them all from Special:EditWatchlist/raw. )) Is there any way to recover my watchlist? XXN (talk) 22:09, 24 January 2014 (UTC)

No, I'm pretty sure there isn't - unless you can convince the people in charge of keeping database backups that they need to go to the backup tapes. I suspect that they would only do this if it was a legal matter. --Redrose64 (talk) 22:14, 24 January 2014 (UTC)
  • You mean you don't remember what pages were on your watchlist so you can just re-add them all manually (I jest). Let me make this easy for you. No, it can not be done automatically for you. Technical 13 (talk) 22:31, 24 January 2014 (UTC)

Mobile interface contains bad English

Tracked in Phabricator
Task T62426

Wikipedia's mobile interface urges users to "login". But "login" is a noun and so it makes no sense to use it as a verb. The interface should instead urge users to "log in", using the phrasal verb. As far as I know, Wikipedia uses the correct wording everywhere else. Here are some examples from the mobile interface. In each case "login" should be "log in".

  • "Please login to add an image to this page."
  • "Wikipedia is made by people like you. Login to contribute."
  • "Help improve this page! Login. Sign up."

Geoff Moreton (talk) 22:40, 24 January 2014 (UTC)

I've found MediaWiki:mobile-frontend-donate-image-login-action (⧼mobile-frontend-donate-image-login-action⧽); MediaWiki:mobile-frontend-edit-login-action (Help improve Wikipedia.
Log in to edit.); MediaWiki:mobile-frontend-generic-login-action (⧼mobile-frontend-generic-login-action⧽); MediaWiki:mobile-frontend-photo-upload-anon (⧼mobile-frontend-photo-upload-anon⧽); MediaWiki:mobile-frontend-user-cta (⧼mobile-frontend-user-cta⧽); MediaWiki:mobile-frontend-watchlist-cta-button-login (Log in); MediaWiki:mobile-frontend-watchlist-login-action (⧼mobile-frontend-watchlist-login-action⧽). There may be others. --Redrose64 (talk) 23:20, 24 January 2014 (UTC)
I've also found MediaWiki:mobile-frontend-main-menu-login (Log in). --Redrose64 (talk) 23:44, 24 January 2014 (UTC)
  • wikt:login is defined as The process of logging in on Wiktionary. Query "define login" on Google returns a box that says: log·in (ˈlôgˌin,ˈläg-/) noun: 1. an act of logging in to a computer, database, or system. (condensed into a single line format for simplicity). dictionary.com defines it as log·in [n. lawg-in, log-; v. lawg-in, log-] (noun Also, log-in, logon.) 1. the act of logging in to a database, mobile device, or computer, especially a multiuser computer or a remote or networked computer system. thefreedictionary.com defines it as log·in (lôg′ĭn′, lŏg′-) also log·on (-ŏn′, -ôn′) n. The process of identifying oneself to a computer, usually by entering one's username and password.. I could go on as there are many more sources (reliability of some may be questionable, but the sheer number of them, some by major publishing companies) seems to indicate that the single word login is the act of logging in to the system which is the correct usage in all of these cases. Technical 13 (talk) 23:28, 24 January 2014 (UTC)
    • Three out of your four list it as a noun. Not a verb. Killiondude (talk) 23:31, 24 January 2014 (UTC)
      • Yes, they do, and I believe that is what these system messages call for. The are saying that you need to preform the act of logging in to (share your media|edit|contribute|add and image to this page|see your notifications|see)... They are not using it as a verb. Technical 13 (talk) 23:38, 24 January 2014 (UTC)
      Let me clarify, in order for these messages to be using the word as a verb, they would need to be preceded by a noun. They would need to be in the form you "You need to log in to contribute.", however, they are worded as "Login to contribute." Technical 13 (talk) 23:40, 24 January 2014 (UTC)
      Even so, that seems like it should be a verb. Jackmcbarn (talk) 23:42, 24 January 2014 (UTC)
      I mentioned this on the edit request as well. What about "you have to hurry to catch your flight"? Jackmcbarn (talk) 23:48, 24 January 2014 (UTC)
      (ec) Technical13, I'm not sure where you got the idea that a verb requires a noun to precede it, but that is incorrect. When it says, "Login to [whatever]", there is an understood "you" before the verb usage of "login". LadyofShalott 23:51, 24 January 2014 (UTC)
      This is called the imperative mood and in English it frequently drops the subject pronoun "you". Killiondude (talk) 23:55, 24 January 2014 (UTC)
    English has noun forms for many verbs, and the words are often similar to each other. E.g. the verb register has a corresponding noun, registration. Imperative statements should start with a verb phrase (a verb optionally preceded by adverbs); they don't make sense if one uses a noun instead. For example, we can use the imperative "please register an account" (using a verb), but "please registration an account" is nonsense (no verb). Likewise, "login to contribute" is nonsense because login is a noun. It should be "log in to contribute", where log in acts as a verb. – PartTimeGnome (talk | contribs) 00:17, 25 January 2014 (UTC)
  • (edit conflict) A quick Google search of "noun verb sentence structure" returns About 1,700,000 results (0.20 seconds). Selecting the first one in the list, http://www.eslgold.com/grammar/basic_sentence.html, says There are five basic patterns around which most English sentences are built. They are as follows: and goes on to list, Subject-Verb, Subject-Verb-Object , Subject-Verb-Adjective, Subject-Verb-Adverb, and Subject-Verb-Noun. This is a widely accepted norm for English which says that all sentences start with Subject-Verb (and of course a subject is a noun). The issue that we face with many of these messages, is that many of them are not actual full sentences, but instead are used as part of sentences and injected into other messages. Also, everyone should also consider that the devs have already seen the counter discussion to change it to login in Bugzilla:6138 and changed it to "login" as a result of that ticket. Technical 13 (talk) 00:20, 25 January 2014 (UTC)
Yes, "log in" is a verb phrase, which is what is called for. It is comparable to "check in", "log off / log out". The subject-verb structure is fine, because imperative sentences have an implied "you" as the subject. Otherwise "Jump!" would not be a complete sentence.
The reference to bugzilla confuses me. It appears that the request was to fix "login" by changing it to "log in", and that was done. That is what is requested here. Also note the bottom of the bugzilla page if you are not logged in: "You need to log in before you can comment on or make changes to this bug." (emphasis added) – Jonesey95 (talk) 00:28, 25 January 2014 (UTC)
  • The ticket says please change < 'loginreqlink' => 'log in', to > 'loginreqlink' => 'login',. So, it is asking for the code to be changed to "login" from "log in". Technical 13 (talk) 00:38, 25 January 2014 (UTC)
    I feel like I'm taking crazy pills. The title of the Bugzilla request is 'Should be "log in" for the verb, not "login"'. Maybe I am misreading Technical 13 and we are both saying the same thing?
    Who can make the requested changes to the locations listed above? It's a simple grammar fix. If you can, please do. To be clear, the request is to change "login" to "log in" in all of the above Mediawiki:mobile* locations listed above.
    As an added bonus, if you can fix it in all of the rest of the places on the web where it is wrong, along with similar variations like "Checkin here" and "Click logout", I'll send you a giant barnstar IRL. – Jonesey95 (talk) 03:08, 25 January 2014 (UTC)
    T13, the bug reporter used a reversed diff. I can tell this because he quotes the diff command he used: diff wiki/languages/Messages.php wiki/languages/Messages.php.orig. For a normal diff, the original file should be the first parameter. – PartTimeGnome (talk | contribs) 16:24, 25 January 2014 (UTC)
  • There are a lot of words here, and some sentences as well. The imperative version of "to log in" is "log in". No hyphen, not spelled as one word. Such prepositional verbs are typically spelled as their two separate constituent verbs, and that's just all there is to it. Drmies (talk) 02:09, 25 January 2014 (UTC)
  • Since we can't know what other system messages transclude the phrase, we can't know if it is always used as a verb or a noun. This is something that the developers should fix in core and possibly the Bugzilla ticket should be reopened. AKlapper (WMF), since your the big Bugzilla ticket sorter guy, what do you think? Technical 13 (talk) 03:13, 25 January 2014 (UTC)
    We can know, because the code is public. It even contains documentation for every message (the documentation also uses login where it should say log in). Most of the messages are complete sentences with a terminating full stop. One is used as the text on a button (normally a verb), and one is the text on a menu. Using messages in multiple different ways is strongly discouraged as it makes them hard to translate to other languages (i.e. such uses would be bugs).
    I agree the developers need to fix this, though. The incorrect messages originate from the MobileFrontend extension (not core), so that is where the fix should be made. – PartTimeGnome (talk | contribs) 16:24, 25 January 2014 (UTC)
  • So we're settled? Is there anything else I need to do? I don't need to file a bug or anything, do I? Geoff Moreton (talk) 12:46, 25 January 2014 (UTC)
No bug needs to be filed, since we can do all the necessary customisation for English Mobile Wikipedia by creating or editing MediaWiki: pages, such as the ones that I linked earlier. --Redrose64 (talk) 13:42, 25 January 2014 (UTC)
  • The existing ticket should be re-opened, a new one does not need to be made. These changes should be done in core because apparently there were some changes before and they were wiped out by a restore or an upgrade, so locally customizing is a great stopgap, but may not be permanent. Technical 13 (talk) 14:00, 25 January 2014 (UTC)
    What existing ticket? Bug 6138 that you mentioned earlier is about a different message that is still correct (MediaWiki:loginreqlink → log in). Furthermore, that bug is about MediaWiki core, whereas the problematic messages are in Extension:MobileFrontend. Unless someone knows of some other bug, a new bug should be opened. – PartTimeGnome (talk | contribs) 16:24, 25 January 2014 (UTC)
Entered as Bug 60426. Thanks for the discussion, everyone. – Jonesey95 (talk) 16:54, 25 January 2014 (UTC)

Template error

I keep on getting weird errors at {{Service award progress}}. Does anyone know why exactly the expr magic word keeps failing, or if the error is related to something completely different? Thanks! APerson (talk!) 02:05, 25 January 2014 (UTC)

Your switch syntax is wrong. It should be #switch:. See mw:Help:Extension:ParserFunctions#.23switch. PrimeHunter (talk) 02:27, 25 January 2014 (UTC)
Thank you! APerson (talk!) 14:22, 25 January 2014 (UTC)

Wikipedia:Wikipediholism test automated version account expired

I went to update my Wikipediholic score on https://toolserver.org/~merphant/cgi-bin/wikiholic.cgi and was dismayed to get a 403 error as the account has expired. Can any of our wmflabs people possibly get this script running again on labs? Thanks! Technical 13 (talk) 00:30, 26 January 2014 (UTC)

To those of you who can parse JS and jQuery...

...this script is looking for more contributors and pairs of eyes. Thanks, --Gryllida (talk) 11:53, 26 January 2014 (UTC)

Unable to resize File:Extreme XM logo.png

I am unable to resize File:Extreme XM logo.png, an image file from the Commons. If I attempt to post the file without any size specified, it appears just as it should (see below); if I try to adjust the size, the image will not display. I first encountered this problem while attempting to place this file in the {{Multiple image}} template. Levdr1lp / talk 01:46, 27 January 2014 (UTC)

Never mind. The previous version had errors -- I have uploaded an error-free version which seems to be working just fine. Levdr1lp / talk 02:01, 27 January 2014 (UTC)

Can we please get rid of those shouty comments in template documentation?

You know the ones I mean... "PLEASE ADD CATEGORIES AND INTERWIKIS AT THE BOTTOM OF THIS PAGE" and "CATEGORIES AND INTERWIKIS HERE, THANKS". I don't know where or when they originated, presumably in the first ever template documentation template. But we've now been successfully using the system for years, and everybody knows how it works. For the times that someone doesn't, another person will fix the transclusion of a category momentarily; and it causes no actual harm until they do. Perpetuating this copy-and-paste mess also creates its own maintenance overhead, as I've now seen someone who's decided that they need to grind through them adding a mention of Wikidata. That's a colossal waste of time.

So can we please, please agree that it's time to get rid of these patronizing and shouty comments? And when we have, get a bot to remove them? I, for one, am sick to death of seeing them, and will continue my practice of nuking them on sight if they occur in a documentation template that I'm working on. — Scott • talk 12:26, 17 January 2014 (UTC)

Technical: The comments are added by Template:Documentation/preload. --  Gadget850 talk 14:37, 17 January 2014 (UTC)
Thank you. I was almost right, then; they originated in the first version of Wikipedia:Template documentation in 2006. See also my reply below. — Scott • talk 16:02, 17 January 2014 (UTC)
I'm assuming they are still there for all of the editors that are new to templates and documentation that might not know. The reason for them to be all caps like that is that they are HTML comments, and as such, need to stand out to be noticed in a seas of text or walls of code. I suppose there could be a note added to the editnotice for all template pages, but that might be more work than it is worth and easier to just have the SHOUTY comments in the source (where they are more likely to be seen than editnotices anyways). Technical 13 (talk) 14:55, 17 January 2014 (UTC)
Following the link provided above by Gadget850, it seems that the shouty comments only occur in templates older than February 2011, when the preload template was deshoutified by DePiep. I'm less concerned now that I know the shouty ones aren't being added any more. @Gadget850: I'm going to ask people at Template talk:Documentation if they think the comments are really still relevant. — Scott • talk 16:02, 17 January 2014 (UTC)
Yes. Later on, the interwiki link message has changed too, for wikidata. Maybe a botter would like to clean these. -DePiep (talk) 17:14, 17 January 2014 (UTC)
Removing the comments would have the disadvantage that all of the templates' transclusions would have to be updated. If it's done by bot, then that would become a very large number of pages, probably in the millions. — Mr. Stradivarius ♪ talk ♪ 04:44, 18 January 2014 (UTC)
Most of them are /doc subtemplates, with few transclusions each (not millions). -Wikid77 00:36, 19 January 2014 (UTC)
I've usually seen them as a set, with "CATEGORIES AND INTERWIKIS GO ON THE /doc SUBPAGE" placed on the template page, and "CATEGORIES AND INTERWIKIS GO HERE" placed on the /doc subpage. I've no problem with fixing ones on /doc subpages, by bot or by hand. The ones on template pages should probably wait until there is a separate reason to edit the template, so that there is an actual content edit as well as the beautification fix. — Mr. Stradivarius ♪ talk ♪ 10:41, 19 January 2014 (UTC)
"everybody knows how it works:

...except for the hundred-thousand-plus editors who are active now but have never touched a template, and the tens of thousands who have occasionally edited templates, but not often enough to remember how it works. The "everybody" who already knows how this works is actually a quite small percentage of users. WhatamIdoing (talk) 00:16, 18 January 2014 (UTC)

Yes, and they're the ones who'll fix it when the inexperienced ones get it wrong. Them, or bots. We have innumerable bots crawling around the site making similar grades of fix on a vastly larger scale; this should be one of the things that they look out for. — Scott • talk 21:57, 18 January 2014 (UTC)
Why waste the time of more experienced editors? Why make it easier to make mistakes? The comments do no harm. They help inexperienced editors learn what to do, and hopefully reduce the time the rest of us spend fixing mistakes. – PartTimeGnome (talk | contribs) 22:04, 18 January 2014 (UTC)
Like I said, bots could catch these errors in real time. Editor involvement would be minimal. To answer your question, the comments are already doing some harm in the form of accumulating technical debt - notice the effort that will be required to update them. Better to do away with them entirely, have real documentation in a single location, and have systems in place to catch whatever minor errors occur subsequently. This is poor factoring that will only get more messy over time. — Scott • talk 13:46, 21 January 2014 (UTC)
In fact, this could and should be one of the tasks performed by Wikipedia:WikiProject Check Wikipedia's army of bots. — Scott • talk 13:24, 23 January 2014 (UTC)
Updated SHOUTy text with new /preload text: The new format should be copied to replace any old, ALL-CAPS comments in /doc pages, as from the current Template:Documentation/preload, especially to control /sandbox use:
<includeonly>{{#ifeq:{{SUBPAGENAME}}|sandbox||
<!-- Categories go here, and interwikis go in Wikidata -->

}}</includeonly>

It's not just HTML cmts but also the #ifeq for sandbox use. The plan is for any new /sandbox to omit the category links of the doc subpage. -Wikid77 00:36, 19 January 2014 (UTC)
I've been guilty of adding those many times. I mainly just copy and paste from Help:Template documentation (just changed it), which did have the shouty comment. I suspect a lot of other people did, too. APerson (talk!) 18:56, 28 January 2014 (UTC)

Curious inclusion

I recently selected "Printable version" from the "Print/export" drop-down menu for Stop the World (Aranda album). The following text appeared at the bottom of the copied, (ctrl/a), text:

<onlyinclude>{{#ifeq:{{{name}}}|Stop the World (Aranda album)|~~~~}}</onlyinclude>The following suggestions were generated by a semi-automatic [[User:AndyZ/peerreviewer|javascript program]], and might not be applicable for the article in question.

I am curious about the desirability of this text, as well as its origin? AndyZ may have insight as well.—John Cline (talk) 22:04, 21 January 2014 (UTC)

The origin is likely User:AndyZ/peerreviewer.js, which is mentioned in your vector.js. – PartTimeGnome (talk | contribs) 22:11, 21 January 2014 (UTC)
Thank you; this is helpful insight.—John Cline (talk) 00:33, 22 January 2014 (UTC)

Wdsearch.js edit request

Hi everyone. Could someone who knows JavaScript take a look at the protected edit request at MediaWiki talk:Wdsearch.js#vi? It's been open since 9 January and could do with being reviewed by someone who understands the code. — Mr. Stradivarius ♪ talk ♪ 23:38, 21 January 2014 (UTC)

Now done by Salix alba. — Mr. Stradivarius on tour ♪ talk ♪ 09:40, 27 January 2014 (UTC)

Protecting a table within an unprotected article

At Wikiproject medicine we're discussing the risk of vandals moving a decimal point on dose information. Is it possible to protect or semi-protect a table or section within an otherwise unprotected article? Could that be done by transcluding a protected template into the article? --Anthonyhcole (talk · contribs · email) 23:16, 23 January 2014 (UTC)

At the moment, protecting just part of an article is not technically doable, but I'd imagine the transcluding option would work. ~HueSatLum 23:27, 23 January 2014 (UTC)
(ec) "No" and "yes" in that order, but my understanding is that the general rule is that templates shouldn't be used to transclude article content. See WP:Template namespace: "Templates should not do the work of article content in the main article namespace; instead, place the text directly into the article." BencherliteTalk 23:28, 23 January 2014 (UTC)
However, see e.g. hydrogen and {{Infobox hydrogen}} - most (all?) of the chemical elements have the infobox separately, see Category:Periodic table infobox templates. --Redrose64 (talk) 00:03, 24 January 2014 (UTC)
  • Bencherlite, I wouldn't consider an edit protected table (semi-protected would be fine according to the requestor) being transcluded as a template as "doing the work of article content in the main article namespace" Since there is no way to protect part of a page (without extensions that we don't have, nor I expect will ever have on this wiki). However, that being said, perhaps PC1 protection to the whole page would be more appropriate in this case, no? Technical 13 (talk) 00:09, 24 January 2014 (UTC)
  • Well, if the content is being transcluded from a template, then that template is doing the work of article content since to edit the content, one has to go to the template namespace. I hadn't seen {{Infobox hydrogen}} before and I'm not sure that's a great example to follow too widely, although I see that the deletion discussion for the element infoboxes templates was a resounding "keep" a couple of years ago. Protection (semi or PC1) would depend on the level/type of edits rather than being a first step. BencherliteTalk 00:19, 24 January 2014 (UTC)
  • Ahh, but if the template is protected, then it is the protection that makes it so that it is doing something the article can't. Technical 13 (talk) 01:47, 24 January 2014 (UTC)
Transcluding article content is generally a bad idea per the above comments, but WP:IAR is policy. I think I would only go that route if the page were protected to prevent such vandalism AND there was a followup discussion to replace the page protection with using transclusion. There is one other issue: If the page itself is not protected, any editor can just subst: in the transcluded page then edit it to his hearts content. If move-protection on the trancluded page isn't in place, he can move the transcluded page away and unless both the moved-to page and the leftover redirect are protected (they might be, I don't know how moving an edit-protected page that isn't move-protected works), he can do mischief at either the now-moved transcluded page or replace the leftover redirect with whatever he wants, likely avoiding page-watchers in the process. davidwr/(talk)/(contribs) 00:14, 24 January 2014 (UTC)
You can't move an edit-protected page unless you can also edit it, and when such a move is made, both the old and new titles have the original protection level. Jackmcbarn (talk) 02:33, 24 January 2014 (UTC)
  • This is true, and part of why I think it is a waste of time and better to just PC1 or semi-protect the whole page. Why would on;y part of the page need protecting? Technical 13 (talk) 01:47, 24 January 2014 (UTC)
{{EICAR test file}} and {{OpenDNS IP addresses}} were created to make protected article content, but I'm not sure it's a good idea for a whole table or section with dose information. We would probably want other parts of it to be editable, and we have a medical disclaimer. PrimeHunter (talk) 02:26, 24 January 2014 (UTC)

We'll address the advisability and policy aspects in another discussion once the technical feasibility is established. I've read all of the above and it seems to answer my question. (I'm a digital foreigner.) I'll re-read it once I've had some sleep. Thank you all! --Anthonyhcole (talk · contribs · email) 01:26, 24 January 2014 (UTC)

also, note that not only "templates" (IOW, pages in the "template namespace) can be transcluded: it's possible to transclude articles (and, indeed, pages from any namespace except "special"). also, for about a year now, it's possible to transclude arbitrary parts from another page using the little advertised extension mw:Extension:Labeled Section Transclusion. see Help:Labeled section transclusion. whether there's any policy in enwiki governing this kind of use i do not know. peace - קיפודנחש (aka kipod) (talk) 21:58, 24 January 2014 (UTC)
For context, Anthony is worried about the table in Equianalgesic. He has previously blanked it. WhatamIdoing (talk) 20:30, 27 January 2014 (UTC)

What's the essential difference between PC1 and PC2

I can't see any meaningful difference between the two forms of pending changes protection in this 2012 RFC description. Can someone tell me how they differ and (sorry the next is a bit off-topic for this thread, so brief would be good) why people would support 1 but not 2? --Anthonyhcole (talk · contribs · email) 06:39, 24 January 2014 (UTC)

With PC level 1, edits by unregistered and new users must be approved by a reviewer, while confirmed users can edit freely. PC2 means that edits by both unregistered and confirmed users (except reviewers and admins) are subject to review. It was agreed that PC2 shouldn't be used on the English WP by several past RfCs, though I don't know what the main objections against it were. SiBr4 (talk) 10:22, 24 January 2014 (UTC)
Thank you, SiBr4. --Anthonyhcole (talk · contribs · email) 16:20, 24 January 2014 (UTC)
The last RFC (over a year ago, not the current one) concluded that PC2 shouldn't be used for the first six months, until we figured out whether PC1 was going to be used so widely that the reviewers would be overwhelmed. (It wasn't, so they weren't.) PC2 has been used on a few articles during the time when it was allegedly "prohibited" with some success and no obvious problems, but it's not likely to be appropriate for large numbers of articles. WhatamIdoing (talk) 20:33, 27 January 2014 (UTC)

Minor change to HTML diff representation

Something of a PSA here. In the past couple of days a minor change was made to the way diffs are represented in the browser interface with HTML (if anyone screen scrapes and processes that). Also, this is the same HTML that is returned by the Mediawiki API if you ask for a diff. The change caused the processing engine of my WP:STiki tool to go crazy, as I parse that HTML. Any ways, lines that used to look like: 

<td class="diff-deletedline"><div>* Ivan Shawbly, a <span class="diffchange diffchange-inline">fiction</span> 
character from the television series ''[[Mona the Vampire]]''</div></td>

have become... 

<td class="diff-deletedline"><div>* Ivan Shawbly, a <del class="diffchange diffchange-inline">fiction</del> 
character from the television series ''[[Mona the Vampire]]''</div></td>

The "del" tag can also be an "add". This is happening on relatively few pages (maybe 1 in 100, or 1 in 1000). One example is [88]. This shouldn't affect many, but hopefully my post can save a tool developer some time if they run into similar issues. West.andrew.g (talk) 22:04, 24 January 2014 (UTC)

I think Max recently made some changes in the diff area... Legoktm (talk) 22:07, 24 January 2014 (UTC)
That wasn't me but the precending commit, gerrit:78156. Because only I have pressed for wikidiff2 to be updated after changing the code, that change went live with my gerrit:99541 which doesn't alter side-by-side diffs even though it looks scary:) Max Semenik (talk) 00:12, 28 January 2014 (UTC)

Navigation Popups and Mixed Content Blocking in Firefox

Ever since Firefox upgraded to version 23, I have been unable to use WP:POPUPS unless I click on the Firefox Shield Icon in the address bar and select "Disable Protection on This Page". Of course, this only works on the page selected, and only until that page is refreshed or otherwise displayed again. Has anyone come up with a way to have the Firefox Mixed Content Blocking "Feature" not function either with all Wikipedia pages or specifically in conjunction with Popups? I've already searched the Archives and if his was already discussed and solved, I seem to be unable to find it. --After Midnight 0001 13:52, 26 January 2014 (UTC)

@After Midnight: see [89], I've fixed it for you. The old code you were loading had "http://" which forced a load over HTTP rather than HTTPS. Legoktm (talk) 21:04, 26 January 2014 (UTC)
Thank you so very much for fixing this for me. It never occurred to me that this was an issue with my monobook. --After Midnight 0001 13:59, 27 January 2014 (UTC)

MediaWiki:Common.js/IEFixes.js

There's an issue being reported with IEFixes.js and IE11. IE Debugger is reporting an error at line 40 

document.attachEvent( 'onreadystatechange', fixIEScroll );

that Object doesn't support property or method 'attachEvent'. Nthep (talk) 14:50, 26 January 2014 (UTC)

I wonder if this fix is still needed in IE8/9/10/11. — Edokter (talk) — 14:57, 26 January 2014 (UTC)
Apparently not. That fix was used for old IE versions in Monobook. Removed. — Edokter (talk) — 15:16, 26 January 2014 (UTC)
Consider notifying the mainteiners of forks of MediaWiki:Common.js/IEFixes.js. Helder 19:03, 28 January 2014 (UTC)

Sidebar shop link for all (but faster)

Due to end-user performance concerns, bugzilla:57939 has just been fixed, meaning that the sidebar will always link to the WMF shop. The current system delays page load by inserting the link after the fact if the IP of the user appears to be in the appropriate location. This change affects only the English Wikipedia, the only project currently slowed down by featuring the WikimediaShopLink extension, and will start taking effect on 6 February 2014 tomorrow. --Nemo 20:58, 26 January 2014 (UTC)

Tech News: 2014-05

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

Recent software changes

  • Pages from Wikimedia sites now load faster in your browser thanks to "module storage", a way for your browser to save data like JavaScript and CSS on your computer to avoid downloading them again. See video. [90]
  • The code used to show videos has changed. You should be able to play the video on the page, with the play button on top of the video. If you see the play button on the right of the video, or if clicking on the video leads you to the original file, please file a bug or tell User:Bawolff. [91]
  • The Special:ActiveUsers page will be removed because it's too slow. [92]
  • The latest version of MediaWiki (1.23wmf11) was added to test wikis and MediaWiki.org on January 16. It will be added to non-Wikipedia wikis on January 28, and all Wikipedia wikis on January 30 (calendar).

Problems

Future software changes

  • You can give comments about the new version of "Winter", a proposal to have a fixed toolbar at the top of wiki pages. [94]

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

09:47, 27 January 2014 (UTC)

VPT not showing up at VPA again

Once again, some code I can't find (not that I know anything) on this Village Pump is preventing it from showing up at Wikipedia:Village pump (all). Ntsimp (talk) 16:06, 27 January 2014 (UTC)

Fixed in [95]. PrimeHunter (talk) 17:02, 27 January 2014 (UTC)
(edit conflict) Fixed, that <onlyinclude>...</onlyinclude> was being processed despite being tucked inside <blockquote><nowiki>...</nowiki></blockquote>. --Redrose64 (talk) 17:04, 27 January 2014 (UTC)

Kindle "loc" vs. printed page numbers

Footnotes that provide Kindle digital page numbers (loc) are showing up in the articles. Is there a way to convert these into the page numbers included in the hard copy book, i.e., if you provide the ISBN? 36hourblock (talk) 19:29, 27 January 2014 (UTC)

Many Kindle books will give you the page number, provided you have the right device (some Kindles don't show page numbers at all). If the user is around to ask, you could ask them to check. I don't think it is possible to convert using a service or formula, though. Formerip (talk) 20:20, 27 January 2014 (UTC)
There is no way to match loc and the page number in a hard copy version. And you should not try to do so, as those versions may differ in other ways. --  Gadget850 talk 20:27, 27 January 2014 (UTC)

Categories for multiple merge targets

At Wikipedia:Categories for discussion/Working/Manual there are a set of categories that have two merge targets. I am about to close another discussion with a similar outcome. Whilst the bots can do a simple Cat X -> Cat Y then delete Cat X type thing, they can't do a two targets thing, i.e Cat X -> Cat Y and also Cat Z. There doesn't seem to be any multi-step way obviously available either, i.e. I can't do a merge and delete to Y and then use Y to duplicate into Z, because Y will get deleted after it is 'merged'. Does anyone know of any automated way I could cause this to happen? Many thanks, Splash - tk 21:56, 27 January 2014 (UTC)

AutoWikiBrowser is a good semi-automated tool to do this sort of task - take a look at Wikipedia:AutoWikiBrowser/Regular expression to see how to do a whole group of categories atr the same time. עוד מישהו Od Mishehu 06:31, 28 January 2014 (UTC)
Splash: the cat-a-lot script can help here. it's a script from commons, which, for a long time, handled files only, but for more than a year now it can do non-file pages also. with "cat-a-lot", you open the category, click the cat-a-lot linkette, click "select all", set the target category, and click "copy". repeat for next one and next one and next one. except that in the last target, choose "move" instead of "copy". i haven't test it on enwiki for a long time, so you probably want to test it on a smaller scale to make sure it still works properly, and also get familiar with it. for anyone who deals with categories a lot, "cat-a-lot" is indispensable tool. see cat-a-lot in WP:US.
(limitation): note that cat-a-lot works through the category page itself, which is limited to 200 entries. if one needs to manipulate categories with thousands of members, this may not be a good choice. peace - קיפודנחש (aka kipod) (talk) 15:51, 28 January 2014 (UTC)
This sounds like it could have potential. I'll take a look once I've knocked back some more of the CfD backlog, thanks. AWB I know of but seem to have had trouble with in the past, but maybe that can be useful too. Splash - tk 19:57, 28 January 2014 (UTC)

Who or what is Widr?

Resolved

Why is {{REVISIONUSER:last}} always Valenzuela400? Is it just me, or is that a MW bug? Technical 13 (talk) 05:01, 28 January 2014 (UTC)

  • Ahh-ha! Widr (talk · contribs) is the last editor to edit Last. I see. How would one go about getting the "previous" editor (not the current revision, but the one before) for the current page? Technical 13 (talk) 05:05, 28 January 2014 (UTC)
  • Hmm... I guess this officially means that I am around too much. :-) Widr (talk) 06:01, 28 January 2014 (UTC)
  • I don't think you can, apart from through the API. — Mr. Stradivarius ♪ talk ♪ 06:46, 28 January 2014 (UTC)
Not a bug, working as documented; see mw:Help:Magic words#Technical metadata of another page, last row of table. This is also implied at WP:VAR, but the impression given there is that only the first bulleted list takes a pagename as a parameter, whereas in fact many (but not all) of the second list do as well. --Redrose64 (talk) 12:52, 28 January 2014 (UTC)
  • WP:VAR is outdated and needs to be redone to reflect the changes in the command. mw:Help:Magic words#Technical metadata of another page does seem to be up-to-date. I see that parts of the discussed changes on Bugzilla (particularly comment 12 suggesting that the revision id should be allowed to be used in place of pagename) were never implemented, and that is my bad. I wonder if anyone else will expect to be able to use "curr", "prev", "last" as revision ids to use with this function and will be disappointed. Anyways. I'm glad my understand has been clarified. Technical 13 (talk) 19:37, 28 January 2014 (UTC)

Parser functions failing

In {{Service award progress}}, I have two #expr statements that consistently do not return the arithmetical sum of their inputs. Does anyone know what's going wrong? Thanks! APerson (talk!) 19:09, 28 January 2014 (UTC)

It would be useful if you could tell us what you are passing in to the template, and what you are expecting to get back out. Also, let's discuss it on the template's talk page where it should have been asked first.  :) I look forward to seeing your response there. :) Technical 13 (talk) 19:40, 28 January 2014 (UTC)
I was referred here from the IRC help channel. APerson (talk!) 20:29, 28 January 2014 (UTC)
It looks like there is mismatch between how {{Service award progress/helper}} is called and what it does. If we say it's called correctly now (with a second unnamed parameter indicating a level) then I think it will do what you want by replacing {{Service award progress/level|edits|date={{{year|1970}}}-{{{month|1}}}-{{{day|1}}}|edits={{{edits|1}}}}} with {{{2}}}. PrimeHunter (talk) 23:59, 28 January 2014 (UTC)
@Technical 13: VPT is appropriate for this kind of request, as there may not be anyone watching the template talk page. — This, that and the other (talk) 02:33, 29 January 2014 (UTC)
  • Normally I would agree with you, which is why I said nothing the first time a few days ago when help was asked for on this template. A couple editors responded including my edit on the template. I might also agree if the question was posted on the talk page and got no answer before coming here, I guess the fact that help has been asked for here multiple times and the talk page is still a red link struck me as off and out of process. Perhaps I was having a bad day. I dunno. Technical 13 (talk) 03:35, 29 January 2014 (UTC)

Strange marks in infobox in edit mode

Could someone take a look at Journal of Near Eastern Studies in edit mode? In its infobox I see things like:

title =

What are those signs (they appear like the bottom-right corner of a square to me, if you can't see them)? Are they supposed to be there? Thanks. It Is Me Here t / c 19:43, 28 January 2014 (UTC)

Those look like your browser is rendering tabs with little squares. Since they don't impact the performance of the infobox and are only used as separators, they are not causing any problems. I went and replaced them with spaces, since the tabs ended up mis-aligning many of the parameters. APerson (talk!) 20:32, 28 January 2014 (UTC)

Random selection, is it possible?

Do we have any parser functions or other magic, that would expand on page saving time to a random page name selected from a category that is given as parameter? jni (delete)...just not interested 20:18, 28 January 2014 (UTC)

Sort of. You can use Special:RandomInCategory/Living people, which will take you to a random page in Category:Living people, but it won't give you the actual page name. You can also get a random item from a list by using Module:Random with the syntax {{#invoke:random|item|list item 1|list item 2|...}}, but there isn't a way to get a list of pages in a category to use with it. — Mr. Stradivarius ♪ talk ♪ 21:54, 28 January 2014 (UTC)
Thanks! I'll see if I can cook something interesting out of those tools. jni (delete)...just not interested 22:19, 28 January 2014 (UTC)

Template problem

I wanted to display the verses of the Bible from which the lyrics of "Turn! Turn! Turn!" were taken. The link makes it appear they come from only one verse, but I was hoping this could display all the verses. However, what I did causes the link not to go to the correct verse.— Vchimpanzee · talk · contributions · 20:25, 28 January 2014 (UTC)

Fixed - template parameter names are case-sensitive. -- John of Reading (talk) 20:41, 28 January 2014 (UTC)
Thanks.— Vchimpanzee · talk · contributions · 20:49, 28 January 2014 (UTC)

Unable to copy at the Teahouse

When I went to the Teahouse, then clicked 'Ask a question', text from the question box coludn't be copied, but text from elsewhere could be pasted into the question box. Blackbombchu (talk) 01:39, 29 January 2014 (UTC)

Is this the problem exemplified in the screencast I uploaded on bugzilla:60441#c8 or something else? Helder 09:52, 29 January 2014 (UTC)
No, the problem is in the pop-up window that appears when I click 'Ask a question'. When ever I highlight text that I typed into that pop-up box then press Cntl + C, it acts like I did nothing then when I press Cntl + V, the last piece of text I copied from somewhere other than that question box pastes instead. Blackbombchu (talk) 17:28, 29 January 2014 (UTC)

Template issue

Would anyone know why this template is producing the weird images on this page, as well as the extra "}}"s? I suspect it may have to do with the fact I'm modifying a template designed for different parameters than the image thing, but if anyone could help fix it, that would be great! Kevin Rutherford (talk) 02:47, 29 January 2014 (UTC)

There appears to be an extra }} before <!-- 09 -->, but there may also be other issues. PrimeHunter (talk) 03:36, 29 January 2014 (UTC)
Many of the parameters in your testcases do not seem to match the parameters in the sandbox template, as far as I can tell. Maybe I'm missing something. — Preceding unsigned comment added by Jonesey95 (talk • contribs) 04:39, 29 January 2014 (UTC)
I'm not keeping that page up as much, as I am trying to work out this image thing. We have worked out all of the other kinks, but that one is what is holding it back. I could revert to an earlier version and deal with it later, but I would rather get it right now. Kevin Rutherford (talk) 04:54, 29 January 2014 (UTC)
This edit should fix it. --Redrose64 (talk) 10:47, 29 January 2014 (UTC)

How to view rev-deleted edits :O

I found a loophole recently.

1. Turn on WikiEd from Gadgets.

2. Find a revdeleted edit, if you can manage to reach the edit's diff page. It should say that you cannot view the contents because it has been revdeleted.

3. Click the WikiEd button to show the differences in each edit (the green triangle). You can now more or less see the revdeletion, kind of. Everything is in red though.

This might have to be patched. Thekillerpenguin (talk) 04:01, 29 January 2014 (UTC)

That's the revision that wasn't deleted... Legoktm (talk) 04:19, 29 January 2014 (UTC)
(edit conflict) As far as I can tell, wikEdDiff is simply treating the revdel'ed version as blank, and showing a diff betwen the visible previous version and a blank page. This causes the whole previous version to be red but doesn't reveal anything you couldn't see by just editing that version in the page history. If you really have a way to see revdel'ed content then see "Bugs with security implications" at top of this page and don't post it in public, or we may have to revdel your post (oh, the irony). PrimeHunter (talk) 04:21, 29 January 2014 (UTC)
Indeed, there's no vulnerability here. Jackmcbarn (talk) 00:48, 30 January 2014 (UTC)

Module:Documentation

Just a note that I have finished working on Module:Documentation and it's ready to replace {{documentation}} on all of our template and module pages. I'd like people to comment on it before I put it up live, so if you're interested, please join the discussion at the template talk page. Bug reports, feature requests and general questions are all welcome. :) — Mr. Stradivarius ♪ talk ♪ 07:55, 29 January 2014 (UTC)

Database error

Tracked in Phabricator
Task T62600

For documentation only; this may be an isolated incident rather than indication of a serious problem.

Database error


From Wikipedia, the free encyclopedia


Jump to: navigation, search


A database query error has occurred. This may indicate a bug in the software. Function: AbuseFilter::checkEmergencyDisable Error: 1205 Lock wait timeout exceeded; try restarting transaction (10.64.32.26)

— Vchimpanzee · talk · contributions · 16:49, 29 January 2014 (UTC)

I have the same problem when trying to save pages. If saving does work, it is terribly slow. Ruigeroeland (talk) 16:52, 29 January 2014 (UTC)
I'm getting that as well - you can preview but whenever you try to save it (eventually) gives the message above. SagaciousPhil - Chat 16:59, 29 January 2014 (UTC)
Happened to me again. Same message.— Vchimpanzee · talk · contributions · 17:08, 29 January 2014 (UTC)
I keep getting this too, especially while using HotCat. De728631 (talk) 17:10, 29 January 2014 (UTC)
I am facing same problem.--Wikiuser13 (talk | contribs) 17:11, 29 January 2014 (UTC)
Three times. And I'm about to do some major editing.— Vchimpanzee · talk · contributions · 17:14, 29 January 2014 (UTC)
@Vchimpanzee: Try coping the content before saving and if it appears again, edit again, paste and save.--Wikiuser13 (talk | contribs) 17:20, 29 January 2014 (UTC)
This seems to be a problem of the article namespace. I guess 10.64.32.26 is one of the servers there. I've been playing with my user sandbox though and have also done some edits in category namespace and these all went just as smooth as ever. De728631 (talk) 17:24, 29 January 2014 (UTC)
I'm pleased to see that it's not just me; I've been having this same problem and I noticed that I've been triggering filter 554 with almost every edit I've made to the mainspace in the past couple of hours; as De728631 has said, non-article edits seem to be okay. Acalamari 17:27, 29 January 2014 (UTC)
Well, if it's a filter problem can someone at least temporarily disable said filter? This is obviously an untenable situation, I've been having the same issue. The Blade of the Northern Lights (話して下さい) 17:29, 29 January 2014 (UTC)
It also seems that on the occasions it eventually says the edit is saved, it hasn't actually done so? SagaciousPhil - Chat 17:32, 29 January 2014 (UTC)
Well, after 6 tries I finally just forced it through, not sure if we're in the clear yet. The Blade of the Northern Lights (話して下さい) 17:35, 29 January 2014 (UTC)

@Wikiuser13:Didn't have to, but thanks. That's what I did just in case.— Vchimpanzee · talk · contributions · 17:35, 29 January 2014 (UTC)

@Kww: I disabled it. DMacks (talk) 17:39, 29 January 2014 (UTC)
  • I've been having the same issue today. And it's really slow. Yesterday, I kept running into "Bad Gateway". — Maile (talk) 17:44, 29 January 2014 (UTC)
    • Seems to be okay for me now... – Connormah (talk) 17:50, 29 January 2014 (UTC)
  • My most abject apologies ... obviously completely my fault. My only saving grace is that at least I had it running with no action while I was testing, but obviously that wasn't enough.—Kww(talk) 18:12, 29 January 2014 (UTC)
What looked weird to me is that the filter was already autodisabled due to exceeding a system limit. The timeouts I got gave error messages specifically mentioning checkEmergencyDisable, not generic database access. Seems like what should have been short-circuiting the too-expensive filter is also too expensive? DMacks (talk) 18:43, 29 January 2014 (UTC)
Meh... the extension doesn't even known how to count... Helder 18:49, 29 January 2014 (UTC)
Agreed. The emergency feature that is supposed to stop a filter blocking all edits seems to have had the opposite effect... I've logged bug 60600 for this. – PartTimeGnome (talk | contribs) 22:44, 29 January 2014 (UTC)

Database query error

I've no idea if this matters at all, but, in any case, I just got the following error while trying to make this edit. Thought I should report it. J Milburn (talk) 17:41, 29 January 2014 (UTC) 

A database query error has occurred. This may indicate a bug in the software.

   Function: AbuseFilter::checkEmergencyDisable
   Error: 1205 Lock wait timeout exceeded; try restarting transaction (10.64.32.26)

The same is discussed above.--Wikiuser13 (talk | contribs) 17:43, 29 January 2014 (UTC)

The problem with filter 554

This problem started with an edit to filter 554. The filter condition was changed to the following text: 

article_namespace == 0 
& (
((lcase(added_lines) rlike ("top100\w*\.blog"|"charly1300")|"mickeycharts")| "atrl.net/forums")
)

I've highlighted the matching parenthesis to make this a little easier to follow.

There are two things that jump out at me about this: First, I'm not sure it makes sense to apply the | (OR) operator to quoted strings. I suspect something like "(top100\w*\.blog|charly1300|mickeycharts|atrl.net/forums)" was intended instead, with the | inside the string where it would function as the regular expression choice operator.

Secondly, note that the right-hand side operand for the rlike operator is terminated by the parenthesis after "mickeycharts". The boolean result from rlike is OR'd against the string "atrl.net/forums". I suspect the edit filter coerced the string into a boolean value because it was OR'd against a boolean value. I further guess the resulting coerced value was true. Anything OR'd against true is also true, making the condition have the same effect as article_namespace == 0 & true – i.e. it matched all edits in the main namespace.

(Note: I'm not much of an expert on edit filter syntax. I've guessed most of the above based on my knowledge of similar operators in other languages.) – PartTimeGnome (talk | contribs) 23:40, 29 January 2014 (UTC)

Yes, I certainly blew it big time.—Kww(talk) 00:35, 30 January 2014 (UTC)

Technical question about redirects

An editor just asked a technical question at Wikipedia talk:Redirect. Could one of you pop over there and answer their question, please? Ego White Tray (talk) 15:28, 29 January 2014 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_122&oldid=1145039419"