Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by TheDJ (talk | contribs) at 20:52, 15 May 2013 (→‎Audio Pronunciation Modification Suggestion: go ahead.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at Bugzilla (How to report a bug). Bugs with security implications should be reported to security@wikimedia.org or filed under the "Security" product in Bugzilla.

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

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


Relinking Google for SSL https

List of pages: wp:Google https links. -Wikid77 14:21, 8 May 2013 (UTC)[reply]
Note: #Confirmed stats.grok pageviews omit https. -Wikid77 10:38, 10 May 2013 (UTC)[reply]

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

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

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

What the... ? I've undone this move (which broke the hatnote, by the way): we do not randomly move pages around based on our own personal theories as to how Google works, and I can't even comprehend the problem statement. If you want to experiment, you've got a sandbox to do so. Chris Cunningham (user:thumperward) (talk) 12:20, 25 April 2013 (UTC)[reply]
Other editors have been discussing Google's https article-links for some weeks now, but it is a very complex problem which will be difficult for many people to comprehend without weeks of study. Fortunately, this is a wiki, and there are other people to help handle complex issues. -Wikid77 13:22, 25 April 2013 (UTC)[reply]
  • Double-renaming did not relink article as http protocol: After a period of 2 hours, the article was re-renamed from new http-protocol title "Parabola (mathematics)" back to "Parabola" but that did not immediately reset the Google https link as being http protocol, as would be expected if the old name were deleted, then the rename performed later. -Wikid77 13:22, 25 April 2013 (UTC)[reply]
    • File a bugreport in bugzilla with wmf site-requests. They have some contacts in Google. Will probably take long, but it can help. I doubt however that it really does matter a lot in traffic if Google found it primarily by https or by http. I wonder however if perhaps there is an issue with non-canonical duplicates of this page somewhere, which might affect it's page rank. If there are canonical issues, then that could also explain why google becomes confused and moves it to https as primary protocol. —TheDJ (talk • contribs) 14:02, 25 April 2013 (UTC)[reply]
I would be interested in knowing why we think (or more specificly how it happens) that google pointing people to https has a negative correlation with page views? Bawolff (talk) 16:31, 25 April 2013 (UTC)[reply]
  • Several major articles with Google https links have lower pageviews: There is very strong evidence of articles with Google https links having relatively low pageviews in April 2013:
Because the term "parabola" is 5x more common in Google hits, the pageviews should be higher, not 50% lower, than for the rare term "hyperbola". Similarly, the article "Gone with the Wind (film)" (as an American cultural icon from 1939) should have higher pageviews than "Lawrence of Arabia (film)" (1962), rather than 33% lower. In general, highly popular articles should have much higher pageviews, compared to similar but less-popular topics. The renaming of page "Parabola" as "Parabola (mathematics)" was intended to delink "Parabola" in Google, to allow deletion of the redirect, and then re-renaming back to "Parabola". However, the deletion might have required a multi-day period with no redirect named "parabola" (as wp:SALTed to prevent re-creation), and that would likely have caused more debates. All of this is compounded by re-indexing a page in Google without revealing the complex trade secrets of how Google's PageRank algorithm operates. Hence, the re-indexing of https-link pages in Google might be better if handled as a discrete wp:OFFICE action, without a lot of public discussion about Google's company-proprietary PageRank methods. -Wikid77 (talk) 03:50, 27 April 2013 (UTC)[reply]
the article "Gone with the Wind (film)" (as an American cultural icon from 1939) should have higher pageviews than "Lawrence of Arabia (film)" (1962), rather than 33% lower. Sorry man, but that's completely bogus. — Scott • talk 12:26, 27 April 2013 (UTC)[reply]
May be so many people talking about it is an indication few people need to check out the article on parabola, but many need to check out the term hyperbola to find out what it is. Nil Einne (talk) 09:38, 1 May 2013 (UTC)[reply]
When many people talk about a topic, the article pageviews usually run higher, not 4x lower. Compare the higher pageviews for "Parabola" in prior months: prior year stats-201204 (1,927/day), prior month stats-201303 (2,490/day), versus April 2013 stats-201304 (620/day). -Wikid77 13:04, 6 May 2013 (UTC)[reply]

Now Hyperbola https drops pageviews 66%

In March, article "Parabola" had an https-link in Google, to drop pageviews 75%, while "Hyperbola" remained with "http:" link and held unchanged pageview levels. However, on 27 April 2013, the pageviews of "Hyperbola" dropped an average 66% each day, and now it is linked in Google by https secure-server protocol (just like Parabola). That is clear evidence that the https-links in Google are deterring people from reading those article pages, probably due to browsers which ask multiple security certificate alerts before the page can be viewed. The pageview stats from April 2013 averaged a 75% drop in pageviews for "Parabola" while the stats from May 2013 show a 66% drop in "Hyperbola" pageviews, when comparing:

There were no edits to Hyperbola (edit | talk | history | protect | delete | links | watch | logs | views) between April 14-29, so the switch from "http:" prefix, to https link circa 27 April 2013, is not directly tied to an edit during the 12 prior days. -Wikid77 13:04, 6 May, 05:42, 7 May 2013 (UTC)[reply]

I'm just now following this discussion about the https pageview drop. How do we know we are deterring human views instead of perhaps eliminating a large number of automated views from unknown sources? In our work on the WP:TOP25 charts, we have learned that certain articles have high ongoing viewcounts that do not appear to be caused by human views, e.g., Cat anatomy - it is regularly among the most viewed weekly articles in the raw stats produced at WP:5000, but its far too popular to be caused by human views, so we have excluded it from the WP:TOP25 chart. I am interested to know if there is evidence (anecdotal or otherwise) that we are deterring human views.--Milowent • hasspoken 14:32, 6 May 2013 (UTC)[reply]
It's all my friends who keep looking at Cat anatomy. Quite a turn-on! Thincat (talk) 14:51, 6 May 2013 (UTC)[reply]
  • Lowered views of GWTW film poster and lower weekends indicate human viewers: Although it is an interesting possibility that 3,000 bots (or automated views) were reading "Gone with the Wind (film)" (GWTW) from Google every day, and have stopped due to the Google https-prefix link, the related 33%-reduced pageviews of the film poster strongly indicate the reduction is with human viewers. While pageviews of the GWTW film article have fallen over 62% per day, from average 4,900 in February/March to 1880/day in April/May, the pageviews of the GWTW film poster have also fallen, meanwhile, 33% from 112 to 75 pageviews per day (see: GWTW poster pageviews-201303, 201304). So, even if 3,000 bots per day were formerly reading the film article, I do not believe those bots were viewing the film-poster description page as 33% of prior pageviews. Instead, the reduced readers are humans, also inhibited to view the poster less (when not seeing the film article).
    Then, in comparing weekend pageviews, the article "Parabola" maintained its same 2-to-1, weekday-versus-weekend pageview ratio, when the pageviews dropped from range 3,150-1,650 on Sundays in March 2013, to 780-400 on Sundays in April 2013 (see: pageviews-201303, 201304). It is unlikely that automated pageviews would "take the weekend off" at the same rate as human viewers. Instead, a broad sample of human readers would be as likely to have reduced viewing on weekdays and lower weekends, at the same proportional rates, when all pageviews dropped over 60% lower. For those reasons, I strongly believe the reduced pageviews represent thousands of human readers who do not view pages, as often, with secure-server, https-prefix links. -Wikid77 (talk) 05:42, 7 May 2013 (UTC)[reply]
  • Now 300 major articles have Google https: I created "wp:Google https links" as an essay/list of Wikipedia pages with Google "https:" protocol links. The results show more than 300 major articles now requiring secure-server access if clicked from Google Search. Perhaps the https links are related to fixes on the mobile website, where pages, with domain "en.m.wikipedia.org" were set to link as "canonical" but with https prefix to enwiki. In many cases, the daily pageviews have dropped nearly 60%-75% during March/April 2013. The https links include many common terms and major articles in various fields of study:
As noted, over 300 of the articles cover major topics in each field of study. Although many users can still gain access to pages by "https:" protocol (or retype as typical "http:" prefix), the reduced pageviews, for each major article, have skewed the measurements of reader interest in each topic, giving the false impression that those major articles no longer have a strong base of viewers. Several major articles even give the illusion of leaving the Top 1,000 most-viewed ("Cancer" or "Oxygen" or "DNA" in March), or "Nikola Tesla" or "Mark Twain" or "Shakira" or "Lady Gaga" in late April 2013, as if their daily pageviews were actually below 6,200 per day, rather than 7,000-12,000 or higher. -Wikid77 (talk) 14:21, 8 May 2013 (UTC)[reply]

Page view stats declining from 22 April

See: "wp:Village_pump_(technical)/Archive_110#Sudden drop in pageviews" and
see: "wp:Village_pump_(technical)#Relinking Google for SSL https". -Wikid77 17:59, 7 May 2013 (UTC)[reply]

Hi. I asked at VPM but no one could shed any light. The Page view stats at Depression (mood) began declining precipitously on about 22 April in a weird way. Other, but not all, articles have been similarly affected. Any Ideas? --Anthonyhcole (talk · contribs · email) 03:49, 1 May 2013 (UTC)[reply]

Possibly this is related to the fact that the mobile website was causing duplicate content in Google. bugzilla:35233 —TheDJ (talk • contribs) 19:14, 1 May 2013 (UTC)[reply]
I didn't understand that. I'd like to know if the actual traffic to this and other pages has dropped by two-thirds overnight, or of this is an artifact of our data-collection. If the number of visitors to some of our more important health pages such as Schizophrenia, Cancer and Depression has actually dropped to a third overnight, we should get to the bottom of it, don't you think? Does anyone else think this needs to be clarified?
It matters to me because I'm trying to get professional medical societies to review some of our medical articles, and that task will be made easier if I can show them reliable statistics.
If no one here knows what's going on, can you tell me who would/might know? --Anthonyhcole (talk · contribs · email) 06:11, 5 May 2013 (UTC)[reply]
  • Google https links to Schizophrenia, Cancer and Depression (mood): As discussed about other pages since early April 2013, those articles (such as "Depression (mood)") have also changed in Google to have secure-server, https-prefix links, rather than typical "http:" prefix, as happened to several other articles in March 2013 ("Parabola" or "List of best-selling books" etc.). Although developers think the https-protocol requests have been properly logged, for pageview counts, some people think the pageview counts are still not correct (as perhaps undercounting the https transactions in those log files), while other people think that https security certificate alerts, in some browsers (such as MSIE not Firefox), have deterred people from viewing those articles, once their browsers ask about the secure-server access, and hence think the 66%-lower pageviews indicate actual reduction in readers viewing those pages. The reduced pageviews are shown by both stats.grok.se and the German Wiki-tech displays of pageview counts (such as for one-month "&Zeitraum=1M"). -Wikid77 (talk) 17:59, 7 May 2013 (UTC)[reply]
Heya, this is Diederik from the Analytics Team @ WMF. We are looking into this issue and I will report back once I have a satisfactory explanation. Drdee (talk) 20:29, 9 May 2013 (UTC)[reply]
Thanks, I have confirmed the https pages are omitted by stats.grok (see below). -Wikid77 10:38, 10 May 2013 (UTC)[reply]
Hi,
As promised, I would come back with an explatation regarding the pageview drop for https traffic. As mentioned before, we turned off the https/ip6 webrequest logging stream to webstatscollector back in March because we inaccurately concluded that we were double counting those pageviews. But in fact, by switching of that stream, we stopped counting of all https/ip6 traffic. Our apologies for this mistake.
We took the following steps to correct the situation:
1) As of May 14, 18:44 we re-enabled the https/ip6 stream to webstatscollector (see https://wikitech.wikimedia.org/wiki/Server_admin_log). Within the next hour or two, the pageview counts for articles that Google has indexed using the https protocol, should rebound to similar levels as they were before we switched off this stream.
2) One of the reasons we switched of this stream, was that the https/ip6 stream has a non-functional implementation of adding sequence numbers. Because these sequence numbers are off, our packetloss monitoring is incorrect. We fixed this situation by submitting patchset: https://gerrit.wikimedia.org/r/#/c/63220/
Please let me know if there are still lower than expected pageview counts in a couple of hours from now. Drdee (talk) 18:59, 14 May 2013 (UTC)[reply]
  • Thanks for fixing the https/ip6 stream to webstatscollector: That was a fast fix, as I had expected to wait another 2 weeks to fit some update schedule. I can appreciate trying to handle the other packetloss problems at the same time, and the https pageviews would not have mattered so much if there were not other software problems which caused the http/https protocols to store 3 separate copies of pages/images in the Google Search index. Meanwhile, we had admins being rude, even snarky, about attempts re-index Google around the https-related bugs. So, not only were you quick to fix the stream to webstatscollector, you were also very polite about it at the same time, as they say, "a gentleman and a scholar" both. Thanks again. -Wikid77 (talk) 05:21, 15 May 2013 (UTC)[reply]

Confirmed stats.grok pageviews omit https

As feared, due to some major articles showing 75% drop in pageviews with Google https-protocol, I have confirmed the stats.grok.se omits the https-protocol pageviews. In tests run during 12 hours on 9 May 2013, over 60 https-prefix pageviews of a Space Shuttle mission-patch image file were ignored, while "http:" views were counted:

Both mission-patch images ("http" for STS-98 and "https" for STS-99) were viewed within minutes of each other, repeatedly over 65 times, during the day-long testing of pageviews. The stats.grok.se website has counted only the "http" pageviews and omitted all https-protocol pageviews. Based on prior pageviews of major articles (see list: wp:Google https links), it is suspected that other pageview tools also omit the https-protocol page requests in the counts. -Wikid77 10:38, 10 May 2013 (UTC)[reply]

Huh

Why do people care about page views? I thought we were here to write an encyclopedia. — Scott • talk 17:37, 11 May 2013 (UTC)[reply]

  • Comparing pageview counts helps to prioritize which articles to revise first: Although it would be great if all articles could be updated instantly, the reality, after more than 11 years, is that many major topic areas of Wikipedia are still maintained, or expanded, by "skeleton crews" of a relatively few people who cannot update all articles fast enough. Hence, by comparing pageview counts, then the editors can see which articles are read almost to the minute, versus some articles read only a few times per week. By updating the frequently-read pages sooner, and waiting to update the less-read pages, then even a handful of people can provide current, or recent, data at almost "magical" levels of response. So, when a news event occurs, or a scientific expedition publishes a report, then editors can use pageview counts to see which articles to update sooner. For example, with the "Costa Concordia disaster" in Italy, the pageviews revealed how, on some days, over 2x more readers were viewing the ship article ("Costa Concordia") rather than the "~disaster" subarticle, and so the ship article became a priority in posting some summarized data, as read by more people than the subarticle. Similarly, the pageview counts can reveal when a crime suspect's article is read many times more often than the original crime-event article, and so effort can be prioritized to update the suspect's article sooner, for summarized updates, rather than divert hours to update the crime-event article, while also writing or updating other articles in a timely manner. As a rule, "If it aint read often, then update other pages first". Eventually, some editors can become quite adept at prioritizing which pages to update sooner, and add crucial information, and allow more free time outside Wikipedia. It can be quite a relief when realizing some "important" articles are just not read enough, or templates used enough, to update today, or even this week. Relax, do something else, and reconsider later. It can wait. -Wikid77 (talk) 23:31, 11 May 2013 (UTC)[reply]
Thanks for the detailed reply. I work for the long term, so this approach is foreign to me. — Scott • talk 12:32, 12 May 2013 (UTC)[reply]

Internet Explorer

Tracked in Phabricator
Task T42998

Can anyone verify that IE is actually prompting users when visiting the https version of Wikipedia, and if so, what the exact warnings are? I'm unable to reproduce this using a variety of different settings. — RockMFR 01:56, 13 May 2013 (UTC)[reply]

Verified that they do exist, uploading and posting screenie with how I got it now. Tazerdadog (talk) 03:27, 14 May 2013 (UTC)[reply]

Scary message is here:

I got this by literally typing in the address shown in the address bar of the screenshot. (https://www.wikipedia.com/Hyperbola) Note the .com, this was an accidental oversight, but wikipedia is a .org site. I can provide more details, but I don't know where to look... Tazerdadog (talk) 03:41, 14 May 2013 (UTC)[reply]

That was caused by typing in .com instead of .org. Wikipedia's security certificate is only valid for the .org domain, so an attempt to access the .com address through HTTPS will always return a security certificate warning. Firefox gives me a similar warning if I click your link. Solution: type in .org instead. jcgoble3 (talk) 03:45, 14 May 2013 (UTC)[reply]
Ok, it fixes it for me if that change is made, so that is almost certainly not the problem. Tazerdadog (talk) 03:52, 14 May 2013 (UTC)[reply]
This is a known issue with the wikipedia.com domain (which only does redirects btw). I linked the bug tracking issue. —TheDJ (talk • contribs) 06:15, 14 May 2013 (UTC)[reply]
Some people assume that all internet URLs end with ".com", possibly the same ones that assume that they all begin with "www." Just last week, I had two different people complaining that they couldn't get to the desired website - one was inserting "www." where none existed, and the other couldn't believe that ".gov.uk" was a valid TLD. --Redrose64 (talk) 12:31, 14 May 2013 (UTC)[reply]

Talk to Google

I believe his is altogether the wrong way of going around things. We should ask Google to have a facility to refer to the pages on the domain using http: always like they have the facility to always refer to them with www. or not according to the web owners preference. This would get rid of anything like this and probably help people elsewhere too. Sites can always use canonical for ones which don't follow the standard. I think our messing trying to flush the caches by renaming is a waste of our time.

Thinking about it more Google would really like such a facility I believe as it would improve their statistics. They would probably also like the option of sites saying they can support https even though they marked everything as normally http so logged in users could have an option to automatically use https as often as possible when using google. Dmcq (talk) 14:15, 14 May 2013 (UTC)[reply]

Did I read correctly above that the mobile views were accessing articles with canonical set to https urls? What on earth is the sense in that? Dmcq (talk) 14:50, 14 May 2013 (UTC)[reply]

Anyway I do support having rel=canonical on all our pages to get the domain and http right whatever about being able to tell Google about the general situation. Might even catch out some of the mirrors before they figure out they should change that when copying Wikipedia :) Dmcq (talk) 16:01, 14 May 2013 (UTC)[reply]

In fact we should probably use HTTP headers instead of sticking the link into the head of the html. This will ensure even the images get a canonical url. Pity this won't catch out the mirrors but that's life. Dmcq (talk) 16:18, 14 May 2013 (UTC) Dmcq (talk) 16:18, 14 May 2013 (UTC)[reply]

In case you are unaware, see meta:Change_to_section_edit_links. Section edit links will no longer appear floated on the right side of the page; instead they will be aligned left, after the section heading text.

This looks like a great change to improve the visibility of section edit links, and it has been proven to bring in more edits to page sections. Obviously it will raise the ire of some long-time editors, but we can always gadgetise the old CSS code if people want it that badly. — This, that and the other (talk) 11:38, 2 May 2013 (UTC)[reply]

There is a gadget "Move edit links next to the section headers" to move it as proposed, presumable that should be reversed when the change is implemented. Keith D (talk) 11:54, 2 May 2013 (UTC)[reply]
I had that option turned on. Wondered if there would be a conflict, and there doesn't appear to be, but for the sake of clean-up, it probably makes sense to remove it. --SPhilbrick(Talk) 13:20, 2 May 2013 (UTC)[reply]
This was "announced" at VPM (Wikipedia:VPM#.5Ben.5D Change to section edit links), but seriously, who reads VPM? Perhaps we need to change the page where we get our automated global messages. — This, that and the other (talk) 12:09, 2 May 2013 (UTC)[reply]
It says "Ideas to do this all the way to 2009 at least. It is often difficult to track which of several potential section edit links on the far right is associated with the correct section"; I remember how in 2009 we had a problem where a stack of box-type objects on the right (including images) could force the section edit links down the page, sometimes known as "bunching" (bugzilla:26449). I have seen as many as six section edit links bunched together; but that's not been a problem for almost two years now (mw:MediaWiki 1.17), so it seems as if we're been given a workaround for a problem which no longer exists. --Redrose64 (talk) 18:05, 2 May 2013 (UTC)[reply]
Those two issues are not really related. The bunching issue was a (comparatively) rare issue. This is basically about the ability of the human brain to travel and refocus from the left of your screen and find and later connect a widget all the way to the right of your window to this context at the left (guided by a horizontal line, but apparently that's only helping a bit). It's a rare vertical positioning problem vs a consistent and omnipresent horizontal positioning problem. —TheDJ (talk • contribs) 21:56, 2 May 2013 (UTC)[reply]

They've put the change live in the last half-hour or so. It can be fixed with this edit, but whether you do that or not, the edittop ("Add an [edit] link for the lead section of a page") feature is lost completely. --Redrose64 (talk) 18:33, 6 May 2013 (UTC)[reply]

Could you give instructions on how to do that, where to put it and so on in a slightly simpler form? I take it that that float right line gets added somewhere - but where? (I want my [edit]s where they're easy to hit quickly, not wandering around the page vaguely...) Peridon (talk) 18:46, 6 May 2013 (UTC)[reply]
Sure, just copy this line: span.mw-editsection { float:right; } and paste it into your common.css page. Writ Keeper ⚇♔ 18:49, 6 May 2013 (UTC)[reply]
Edittop works fine for me. However, the [edit] link is as large as the page title, which I don't like. Clarification: I'm using the Vector skin. Ian01 (talk) 00:06, 7 May 2013 (UTC)[reply]
I fixed it and I moved it to the right because I didn't like it being next to the title. Here's my code:
span.mw-editsection { font-size:small; } /* make edit links small */
the above is not necessary; see below
#firstHeading span.mw-editsection { float:right; } /* move edittop to the right */
Ian01 (talk) 00:49, 7 May 2013 (UTC)[reply]
Ian, the edittop link should be just as large as any other editsection link on the page. If it is in fact larger, then that's a bug and I'd like to see a screenshot. :) Matma Rex talk 13:52, 7 May 2013 (UTC)[reply]
Matma Rex, I disabled my CSS to take a screenshot, and it looks fine now. The brackets are still the same color as the title, though (title color being caused by the metadata gadget). Ian01 (talk) 21:42, 7 May 2013 (UTC)[reply]
(ec) Thanks. That's much easier than that diff. As I've commented further down the page, couldn't this have been done by a default tick in the box in Gadgets - Appearance so it would be easier to undo? I want those buttons where I can hit then quickly - I have no trouble going to the right hand side, but I do have trouble scanning across to find a wandering button. Looks neater over at the right, too. Peridon (talk) 18:57, 6 May 2013 (UTC)[reply]

The edittop feature is not lost; I have already personally submitted a {{editprotected}} request on its talk page, which has been as of right now completely ignored (MediaWiki talk:Gadget-edittop.js). There's no "they" here (in fact "they" have went as far as to fix your broken gadgets), it's your admins who are not helping. Matma Rex talk 19:00, 6 May 2013 (UTC)[reply]

Until it's fixed locally, you can add 
mw.loader.load( '//commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-edittop.js&action=raw&ctype=text/javascript' );
to your .js file. The Anonymouse (talk | contribs) 19:02, 6 May 2013 (UTC)[reply]
Okay, thanks you two. Sorry to be so touchy. Ignatzmice•talk 19:04, 6 May 2013 (UTC)[reply]
I've actioned MediaWiki talk:Gadget-edittop.js#Fixes for m:Change to section edit links now, and yes, I was ignoring it - partly because it's javascript, and partly because of all the sh*t that I get when I involve myself in many {{editprotected}} requests. --Redrose64 (talk) 19:22, 6 May 2013 (UTC)[reply]

Just a heads up, I found that the right-click to edit sections option in Preferences>Editing is a good alternative, and you can edit section 0 by right-clicking the article title. The double-click to edit option seems to go to full page editing no matter where you double-click, whether it be on a section title or even somewhere random on the page (Firefox 19.0). The problem for me with edit links right next to the title is it makes reading the article more difficult as large links are scattered throughout. When they were on the right I didn't notice them as much. The right-click to edit option is even nicer, I wish I had tried it sooner. Cheers, — Bility (talk) 20:09, 6 May 2013 (UTC)[reply]

  • Comment Obviously I'm too late, but having the edit link on the right side made it predictable and easy for people who click edit links often. Now instead of knowing that I need to move the cursor to the right, first I have to visually identify the end of the section header, then click edit. It's kind of annoying. Oh well. --IP98 (talk) 11:36, 7 May 2013 (UTC)[reply]

I've just noticed that local description pages for Commons images now have section-edit links (e.g. File:BtCPicture 008.jpg), which I don't remember ever seeing before. Is this new, or am I forgetting? Seems like a great idea to me. Nyttend (talk) 02:47, 5 May 2013 (UTC)[reply]

This is new, a side-effect of meta:Change to section edit links. Possibly an unintended side-effect, since the page doesn't mention it. -- John of Reading (talk) 07:15, 5 May 2013 (UTC)[reply]
This is indeed unintended, but it looks like a positive change to me (that said, I'm looking into why they are shown now and why they weren't in the first place). The links are currently displaying a little funnily, but this should fix itself when the change is deployed here tomorrow. Matma Rex talk 12:06, 5 May 2013 (UTC)[reply]
My diagnosis is that there is nothing that would have prevented those section edit links from being shown. I guess that the change simply resulted in their being more noticeable, which is precisely what it was intended to accomplish. :) Matma Rex talk 12:24, 5 May 2013 (UTC)[reply]
Reading the Meta page, I'm confused, because I've noticed this very thing in action at de:wp for a long time; for example, de:National Historic Landmark has Auszug aus dem Verzeichnis [Bearbeiten] , Alabama [Bearbeiten] , Alaska [Bearbeiten] , etc., and they have for quite a while. Has it been implemented there already (calling into question the up-to-dateness of the Meta page), or do they do it some other way? Nyttend (talk) 20:02, 5 May 2013 (UTC)[reply]
Out of the top ten linked on http://wikipedia.org/, this has been already been implemented on German, French, Italian, Polish, and Japanese Wikipedias (and likely more; one I remember off the top of my head is the Farsi one) with ugly JavaScript hacks, and slightly different ones on each wiki. This will simply replace those with a clean native solution. Matma Rex talk 21:03, 5 May 2013 (UTC)[reply]

[edit] moved

I think this has happened before, but I can't remember how to stop it. The little [edit] button on every section has moved from the far right to just right of the section heading. This is annoying, and I'd like to put it back where it belongs. I've not been messing with preferences, or anything else. I've looked in there to see if I can find a remedy, but can't. I'm in Firefox 20.0.1, on XP Classic view and Monobook. Peridon (talk) 18:38, 6 May 2013 (UTC)[reply]

See "Section edit links are migrating westwards" above. Steven Walling (WMF) • talk 18:39, 6 May 2013 (UTC)[reply]
Thanks. Good to see there's a way round it up there, if I could understand it. Why couldn't there just be a default tick in the box already in prefs (found it) so those of us that are less technical could just untick it again? Or is that too simple a solution? Peridon (talk) 18:49, 6 May 2013 (UTC)[reply]
Assuming that you mean Preferences → Gadgets "MediaWiki:Gadget-lefteditlinks", that installs several dozen lines of javascript. If the same effect can be achieved in one line of CSS - specifically by adding 
span.mw-editsection { float:right; }
to Special:Mypage/common.css - I very much prefer the CSS method. --Redrose64 (talk) 19:40, 6 May 2013 (UTC)[reply]
Which worked very nicely, thank you. --  Gadget850 talk 19:52, 6 May 2013 (UTC)[reply]
For people who know coding - yes, it's easy. For someone who can look through a list of tick boxes and alter one that is clearly labelled, no, it isn't easier to use CSS (whatever that is...). Peridon (talk) 21:23, 6 May 2013 (UTC)[reply]
You literally just have to copy and paste, and click on three things: Copy the above code. Click Special:Mypage/common.css. Click to start the page. Paste the code in. Type an edit summary and click save. That's it. Also, about not knowing what CSS is… Ian01 (talk) 00:28, 7 May 2013 (UTC)[reply]

This his has been mentioned at WP:VPM a week ago, which is where en.wp has apparently decided to receive important global notifications, with a link to more info at Meta: m:Change to section edit links. Matma Rex talk 18:58, 6 May 2013 (UTC)[reply]

Thanks. I've commented there. Peridon (talk) 19:17, 6 May 2013 (UTC)[reply]
If you want your edit buttons back on the right side, put
span.mw-editsection { float:right; }

in your Special:MyPage/common.css file. Peridon (talk) 21:10, 6 May 2013 (UTC)[reply]

Standard response: We tested something different but sort of like it a long time ago with a completely different and very small group of users for a different purpose, and now we've decided to apply it everywhere without having done recent testing on users who actually use those tabs. You know as well as I do that all of the data from those tests was flawed. More importantly, it's so outdated given all the changes in the interim, that it is meaningless. Put it back please. Risker (talk) 23:41, 6 May 2013 (UTC)[reply]
Sorry, but I can't just "put it back". It's not my call. I'm just helping advertise the change, and it was actually made by a conglomeration of volunteers and staff, with the primary committer being a volunteer. Steven Walling (WMF) • talk 23:43, 6 May 2013 (UTC)[reply]
Local projects can undo the change with an edit to their global .css fine. MBisanz talk 23:49, 6 May 2013 (UTC)[reply]
Why not first do those changes on one of the smaller wikis, to see a better feedback before putting it live on one of the top 10 worldwide websites? I just checked other languages Wikipedia's. Still the orange bar, no echo, no moved edit link. (mind you, of the three I do like echo) Garion96 (talk) 23:51, 6 May 2013 (UTC)[reply]
It was done on smaller wikis first. That's how every bi-weekly MediaWiki deployment goes. Steven Walling (WMF) • talk 00:01, 7 May 2013 (UTC)[reply]
Ok, I checked some smaller wiki's but saw they didn't had the changes. Guess it was done on the other ones. Garion96 (talk) 00:30, 7 May 2013 (UTC)[reply]
Actually, the current deployment cycle shows that it goes Meta/test/test2 then non-wikipedia wikis, then English Wikipedia, and only after that is it other Wikipedias. Risker (talk) 01:36, 7 May 2013 (UTC)[reply]
That's exactly what I meant. General MediaWiki releases don't go on to English Wikipedia first. They're on other wikis for a week before they hit here. Steven Walling (WMF) • talk 01:50, 7 May 2013 (UTC)[reply]
Hmm. Still doesn't explain why Enwp goes before all the other wikipedias; that's counterintuitive. And we know there's a very serious push for this to change in the near future, so there'd only be 3 days between.[1] Risker (talk) 03:34, 7 May 2013 (UTC)[reply]

Getting back to my point about the extremely limited research that has gone into this decision, it appears this was based on the 2009 Usability and Experience study[2], which involved a grand total of (wait for it) 15 people, using a different skin, with four years of intervening changes. Four-year-old research should not be the basis of any changes being made to MediaWiki or Wikimedia projects, and I'm flabbergasted that anyone would think a 15-person sample would be sufficient for recommending major changes in the first place. Risker (talk) 02:29, 7 May 2013 (UTC)[reply]

Well, looking even further at the Usability wiki, it looks like this was a recommendation that was never tested, actually. The study seems to point out that new editors had a hard time finding the (correct) edit button. Nothing I can find there suggests that they actually tested this solution to see if it changed the outcome. Risker (talk) 03:30, 7 May 2013 (UTC)[reply]
Good lord. Facepalm Facepalm. I understand that site design elements should not be held hostage to community consensus, but you guys at the foundation could at least make the effort to pretend the community matters when deciding what changes to make. The irony of this change being based on a usability study is that the most important link on the entire website was suddenly moved to a position that has a high likelihood of confusing longstanding editors. This change was counterproductive in many ways, and once again it was left to the community to build a fix for it. With that said, thanks to the editors above who posted the css code to put the button back where it belongs. Resolute 03:40, 7 May 2013 (UTC)[reply]
Three things:
  1. The Foundation didn't make this change, a volunteer developer and Wikipedian did, with code review from both staff engineers and other volunteers. Myself and others helped him announce it because it's a big deal, and he did the hard work to clean up the previously screwed-up way that MediaWiki was generating the HTML for section edit links. Not every technical change comes from the Foundation, as MediaWiki is a functioning open source project with lots patches and extensions by people who don't work for the WMF.
  2. There was not just a 15 person usability test. Trevor later ran a proper randomized A/B test with thousands of registered and unregistered editors. That's what's mentioned in the Meta page, though I think the A/B test is under-documented.
  3. Even if you don't like the way the change was announced, the technical work done by volunteers on this means that overall things are better for Wikipedia, in all its languages... Previously about half of the top ten Wikipedias were using local JavaScript to move the section edit links to the left. Now, because of this patch, you no longer need a script to move the links to left or right, you just need one line of CSS. This means literally millions of our readers and editors will have a little bit less hack-y JavaScript to load on their browsers, every time they view a page with section edit links.
Steven Walling (WMF) • talk 04:13, 7 May 2013 (UTC)[reply]
Steven, you're now telling us about research that isn't even mentioned at the MediaWiki page, to which you pointed us for an explanation. Where's Trevor's research? It absolutely is NOT mentioned on the Mediawiki page. Everything that is documented and available to the user basically says "we asked 15 people, and they had a hard time finding section edit links, and a couple of wikis like it over there, so we're going to move everyone's over here because we think it looks better." This keeps happening over and over: we're handed one explanation for something then another then another, and none of it adds up. That some wikis like it in one place and others like it elsewhere seems pretty obvious. So how about we allow this project to put it where it makes sense to us? Risker (talk) 04:43, 7 May 2013 (UTC)[reply]
"So how about we allow this project to put it where it makes sense to us?" There is not only nothing stopping the project from doing that if that's the consensus, it's actually easier because of this change to MediaWiki core, as I just said above.
As for the rest... This isn't a Foundation patch. We're supposed to document experimental work from years ago (that I didn't do), review someone else's code and design, test their code, deploy their code to more than 800 wikis, help announce the change, and manage the response of people across the wikis? You can see why maybe I think you're being a tad demanding. I'm sitting here at 9 o'clock at night to try and explain a volunteer's work to another volunteer when I have a metric ton of my own work to do, so can you maybe assume a little more good faith? I'm just the messenger, so don't shoot me. Steven Walling (WMF) • talk 05:14, 7 May 2013 (UTC)[reply]
Thanks for the clarification. Given that this isn't a WMF initiative (and the decision of where to display the "edit" link continues to rest with individual wikis), it seems sensible to restore the longstanding format locally until consensus to change it is established. (I believe that it would make more sense to retain the original default and allow projects to optionally shift the link to the left via the improved method, but that's a matter to be raised elsewhere.) —David Levy 05:35, 7 May 2013 (UTC)[reply]

Bug

The edit-0 button is now broken in the Modern skin - it previously used white text, allowing it to show up against the blue background of the header in that skin, but along with the move seems to have changed color, making it effectively invisible. I see brackets around where the button should be, but can't see the button itself. Nikkimaria (talk) 20:26, 6 May 2013 (UTC)[reply]

Should be fixed now. — Edokter (talk) — 00:05, 7 May 2013 (UTC)[reply]

What it says on the tin. Is this related in some way to all these other changes? If so, please cut it out, putting it on the far right works, and it's never ever ever been a subject of complaint before from anyone. Putting it at the end of the words in a header doesn't make any sense, because of widely varying header lengths; it's getting lost there. If this is NOT related, tell me who's responsible for it. Someone ought to be owning up. Risker (talk) 23:03, 6 May 2013 (UTC)[reply]

I'll see it, but I do not want another bit of javascript anywhere. We shouldn't have to keep adding all this javascript (much of which starts to internally conflict) just to have a decent user experience. Risker (talk) 23:18, 6 May 2013 (UTC)[reply]
The move is not done or undone via JavaScript. Steven Walling (WMF) • talk 23:22, 6 May 2013 (UTC)[reply]
I don't mind the move, but to a lay person like me, javascript and stylesheets both fall into the "incomprehensible code" category. MBisanz talk 23:27, 6 May 2013 (UTC)[reply]
Thanks Okeyes and everyone else. That the two are occurring simultaneously is frustrating, but not unrealistic. Steven, allow me to explain the problem here. In order to fix something that your team broke without a logical reason, I would have to add MORE CSS and/or JSS to my setup. Every time I log onto a page, my load is slowed noticeably, and that's with a decent computer and high speed internet. Just imagine what it would be like for the editors using older technology and dial-up. Those scripts don't all get along well, and they can mess things up. There's no good reason for that link to be anywhere other than the same consistent place on each section. If the only way I can have those section edit links where they belong is to add scripts or gadgets, then your team has messed up, because they all depend on CSS and JS. Risker (talk) 23:35, 6 May 2013 (UTC)[reply]

Haha, funny to see you here, Risker! Yeah, this is one thing everyone can agree on. I think it's easier to have the edit link on the far right--that way everybody always can predict where it is going to be, and not need to scour the page for it. I know, lame, but that is how it happened for me =/ Red Slash 23:54, 6 May 2013 (UTC)[reply]

Edit link next to the section head is better for newcomers, as more likely to be spotted and more inviting. For experienced users, it's generally better on the right (closer to the scroll bar), except when images cause edit links of small sections to overlap confusingly. Anyway, there it is; I'm just disappointed the CSS above hasn't worked for me. Rd232 talk 00:01, 7 May 2013 (UTC)[reply]
Calling a post in VP-TEch "an announcement" doesn't cut it. And requiring coding to undo WMF's fuck ups is UNSAT. PumpkinSky talk 01:39, 7 May 2013 (UTC)[reply]
Risker is absolutely right to complain about implementing possibly unwelcome changes without flagging them up in a highly visible manner. It looks to me like too many developers are taking lessons from Douglas Adams and deciding that that it's ok to inform folks by the wiki equivalent of "on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'." It's not ok. --RexxS (talk) 02:31, 7 May 2013 (UTC)[reply]
lesson?? Adams' line was satire! >:( Rd232 talk 12:38, 7 May 2013 (UTC) [reply]

Just thought I'd chime in and say that I think the section edit link should be put back on the far right. Another reason: We sometimes sort of forget that a large number of people come to Wikipedia to read, but not edit, the articles. Having the edit link immediately following the section headers is distracting, and therefore detracts from the reading experience. — Mudwater (Talk) 04:12, 7 May 2013 (UTC)[reply]

I have basically given up hope that either the Foundation or the developers listen to the core community on matters like this, but I have to agree 100% with Mudwater and Risker. NW (Talk) 05:44, 7 May 2013 (UTC)[reply]
Hey, I'm as mad as anyone about the Orange Bar issue (and this edit link issue shows how that mess has needlessly damaged WMF goodwill), but this change is basically a code improvement. If we want the edit link back where it was by default, we can do that with a line in MediaWiki:Common.css. WP:VPR is that way, if you want to propose it. Rd232 talk 12:36, 7 May 2013 (UTC)[reply]
The code improvement is fine, but we should not have to go to VPP to restore a change that is obviously quite opposed. The positioning of the link should be returned to its original place, and those who favour the change in placement should be the ones seeking consensus. Resolute 13:27, 7 May 2013 (UTC)[reply]
Pointless change. Worthless change. I understand that hacky code must be replaced, but keep the edit tab to the right. One should not have to look for it in various places, depending how long the section heading is. "Right" does not equal "hacky code", and left (sort of) does not equal "good code". When 99% of existing editors have added the .css code, will you still claim the change was good? HandsomeFella (talk) 18:00, 8 May 2013 (UTC)[reply]
Actually I find it would be harder to find the edit tab when it is on the right than at the section header. I often have to search around for the link when it gets moved around because of pictures or the like on the right. When its right next to the section header I know its going to always be right next to the section header. You don't have to look around more just because a header might be slightly longer. -DJSasso (talk) 18:24, 8 May 2013 (UTC)[reply]

Change it site wide

Per m:Change to section edit links#If you don't like this change, adding: 

.ltr .mw-editsection {
  float: right;
}
.rtl .mw-editsection {
  float: left;
}

to MediaWiki:Common.css will restore the old-fashioned link site wide. Just sayin' -- Avi (talk) 07:36, 7 May 2013 (UTC)[reply]

'Fixing' what isn't broke or a problem

Whose idea was it to move the 'Edit' link for the sections over next to the section title? Was this discussed first? Isn't this link better left to where it has been after all these years? As it is, it clutters and crowds the section title. -- Gwillhickers (talk) 16:54, 7 May 2013 (UTC)[reply]

It is mentioned above at #.5Bedit.5D_moved. There has been a popular preference option to move them to the left for years, so some editors surely prefer it there, but the main benefit is increased awareness of the "edit" option for non-registered users to encourage readers to become editors. ~ Amory (u • t • c) 17:04, 7 May 2013 (UTC)[reply]
I don't like it either. I was having a hard time finding it today.— Vchimpanzee · talk · contributions · 19:56, 7 May 2013 (UTC)[reply]
Edits from non registered users is an ongoing problem. Virtually all vandalism is committed by non registered users, while others too often do not discuss major edits and rarely leave edit summaries. It only takes a minute to register. IMO, we should of course allow all others to join Wikipedia, but editing should be a privilege that is earned, save talk page suggestions. This policy is used for Featured Articles. If such a policy was in place overall virtually all vandalism would disappear and registered and responsible editors wouldn't have to stand guard over articles near as much. Sticking the edit option in the face of potential nonregistered users only encourages them to, uh, 'edit', whenever they get the urge. If potential users feel their edit(s) are important and needed, they will take the minute to register. 'Free and open access to anyone' is one of the main reasons Wikipedia is not considered a reliable source in the academic world. i.e.'Anyone' can edit at 'any' time. In fact, WP is blocked on high school computers here in California, and no doubt elsewhere, because it can't be trusted. If we aren't building an encyclopedia that is respected and not subject to random changes from anonymous users then what are we doing besides entertaining ourselves? The new in your face edit link location only throws gasoline on this particular fire and encourages others to do the same. -- Gwillhickers (talk) 17:26, 8 May 2013 (UTC)[reply]
Every time it has been looked at systematically, the contributions of unregistered contributors were judged to be on balance positive. The result I recall from a few years ago was 75% good edits and 25% unacceptable good faith edits / vandalism. I suspect you'd disagree, but the community has generally been willing to tolerate the bad edits IPs create for the sake of the good edits they also make. In addition, there is a general fear that erecting new barriers to new user participation will cause the active user numbers fall even more quickly than they have been. Dragons flight (talk) 17:45, 8 May 2013 (UTC)[reply]
Dragons flight, what you say might be true, but it still doesn't counterdict what Gwillhickers said. Most IP's don't vandalize (per your claim), but that does not mean that most vandalism comes from registered users. That goes without saying. HandsomeFella (talk) 19:06, 8 May 2013 (UTC)[reply]
"...editing should be a privilege that is earned, save talk page suggestions. This policy is used for Featured Articles." - no, no it's not. FAs are conceptually as open to edits as any other pages are. (The daily FA is sometimes restricted for that day, but that's a specific case and mostly due to volume) Andrew Gray (talk) 18:54, 8 May 2013 (UTC)[reply]
conceptually yes, but in practice; not. A shrill cabal won't allow that; the policy described is - sadly - de facto, if not de jure. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:09, 14 May 2013 (UTC)[reply]

Would the real [edit] button to [edit] please stand up [edit] [edit]

My first reaction was to wonder what was the topic about "problem [edit]" and then I noticed that all the header lines were about "[edit]" but the word "[edit]" did not seem to fit the logic of every header title. Be careful what you wish for, when discovering the original situation was better. I guess if the edit button were spaced further with lead-spacing, beyond the header title, it could be less confusing. But then, the placement of the header edit-button was the only thing which still worked correctly in all older browsers, so its days were numbered: "If it aint broke, then fix it so it will be." Yet another wiki-trainwreck. Just too funny. -Wikid77 (talk) 14:54, 8 May 2013 (UTC) [reply]

With all these changes to make us look more like Google and facebook I am waiting to see what happens with the site name. Maybe something like Wikibook or Facepedia? Kumioko (talk) 14:57, 8 May 2013 (UTC)[reply]
Wikid and I have had our differences, but in this case, I agree with him to the fullest. HandsomeFella (talk) 15:22, 8 May 2013 (UTC)[reply]
From a graphic design standpoint, the new location looks cluttered and unbalanced. One of the things the developers got right early on with Wikipedia was the clean, functional section header appearance, and this messes it all up. Rivertorch (talk) 18:21, 8 May 2013 (UTC)[reply]

Individual section edit buttons

Is there a way to shift the buttons for editing each section, and the lead, back to the right of the screen, rather than being variably located depending on the length of the header? Thanks, CMD (talk) 11:41, 8 May 2013 (UTC)[reply]

There really should be a gadget to put the links on the right; since there used to be a gadget to put the links on the left, where they now are by default, and I don't think it needs a lot of discussion. Rd232 talk 13:05, 8 May 2013 (UTC)[reply]

  • Okay, then, if a passing admin wants to do it:
  1. Create MediaWIki:Gadget-righteditlinks.css with the content span.mw-editsection { float:right; }, as well as the header-text at WP:Gadget#Header
  2. Create MediaWiki:Gadget-righteditlinks with the content "Move section [edit] links to the right side of the screen" or similar
  3. Edit MediaWiki:Gadgets-definition to include the line * righteditlinks|righteditlinks.css (the lefteditlinks was placed under Appearance between MenuTabsToggle and PrettyLog)
  4. Update WP:Gadget#Currently installed gadgets.
Ignatzmice•talk 13:18, 8 May 2013 (UTC)[reply]
Added. — Edokter (talk) — 19:14, 8 May 2013 (UTC)[reply]
Thank you!! Rivertorch (talk) 06:12, 9 May 2013 (UTC)[reply]

Who moved my cheese: latest editsection change broke many scripts

So, i do not mind that the devs changed the page design and moved the "edit section" link to the left: i think it's a good change, and will make casual editors more aware of the "edit section" link.

However, while doing so, the devs also changed the CSS class name for the edit section link from "editsection" to "mw-editsection". this broke many scripts: basically, any script that did something to the edit section link and found it by its class name, needs to change. as far as i saw, there was no announcement to this change, and we had to find it by users reporting script breakages.

Not only was this change unannounced, but it's also pointless and unjustified. i can accept that mw-XXXX is a more appropriate name than XXXX for a CSS class, but this is true only up until the point this class is used for the first time: once it's there, you should have a Really Really Really Good Reason™ to change it and break backward compatibility. as far as i could see, the "really really really good reason" in this case was something like "someone likes this name better". a software package that's deployed in tens (if not hundreds) of thousands of installations, can't (or at least shouldn't) be so blasé about breaking backward compatibility.

So for all of you script owners out there: scan your scripts and make sure to change every "editsection" to "mw-editsection".

peace - קיפודנחש (aka kipod) (talk) 21:10, 9 May 2013 (UTC)[reply]

I and a few others have replied at meta:Talk:Change_to_section_edit_links#sneaky_parasitic_change_-_broke_many_scripts., as you posted that comment there as well. It would have been fair of you to copy those replies here or at least add a notification, instead of creating the false impression that no one cares about your comments. Matma Rex talk 15:23, 11 May 2013 (UTC)[reply]
clarification: i posted it _there_ to "protest" the perceived blasé attitude towards backward compatibility. several people answered, and at least _some_ of the answers actually strengthen my impression that not all developers hold backward compatibility at the high regard i think it deserves.
what i wrote _here_, was meant mainly for other script developers, that maybe did not notice that the change could have broken some of the scripts.
i did not try to create the impression that "no one cares", and if i did create such impression, i am sorry.
as a person who developed several scripts over the years, i noticed that i, personally, do not use the majority of the scripts i wrote. the main reason is that many of those scripts were written per specific requests from other users, but i am not really interested in using the functionality those scripts provide.
the WMF upgrade cycle is 2 weeks now, which i think is great. however, it is completely unreasonable to expect every script developer to run full regression tests for every single script they ever wrote and someone still uses every two weeks.
so i think that whenever an upgrade contains some breaking changes, more effort should be made to identify the affected community (e.g., when touching a hook, scan all the extension to find who uses this hook. when changing CSS class name, make a clear note before the upgrade to notify scripters).
and BTW, this last upgrade brought with it several other breaking changes: one is a jquery regression (to be fair, the developers probably couldn't really know about this regression), and another is some other html+CSS changes that were completely unannounced (class name "mw-watched" changed to "mw-changeslist-line-watched". like in editsection case, this change also relates to some html changes).
peace - קיפודנחש (aka kipod) (talk) 16:29, 12 May 2013 (UTC)[reply]

I wrote some CSS to restyle the section edit links as buttons to make them stand out more. (Which also increases the temptation to click them and do something!) If you'd like to as well, the code is here. — Scott • talk 13:03, 10 May 2013 (UTC)[reply]

Thanks. I like the button look a lot better. jcgoble3 (talk) 06:28, 12 May 2013 (UTC)[reply]

Headings "in the air" after I fixed the float of the [edit] tab to the right

After I created User:HandsomeFella/common.css to float the [edit] tabs to the right, there is a significant distcance between the section name and the line under it.

Did I do something wrong with the .css file?

HandsomeFella (talk) 14:02, 8 May 2013 (UTC)[reply]

Looks fine to me. Maybe it's something to do with site-wide funny business (see directly above)? Ignatzmice•talk 14:05, 8 May 2013 (UTC)[reply]
It's still a problem. However, when I edit a page (in preview mode, like now), the single section heading looks normal, with normal distance to the line – but then again, there's now edit tab present in preview mode. HandsomeFella (talk) 14:23, 8 May 2013 (UTC)[reply]
Instead of relying on your own CSS page, why not go to Special:Preferences? There's a gadget to put the link back where it was before this update. Nyttend (talk) 22:12, 9 May 2013 (UTC)[reply]
One reason could be that this change was applied to all WMF projects more or less simultaneously. Not all of them have gadgets to restore the old behavior yet. So it may be more convenient to just put the necessary CSS into one's own common.css instead of first searching the (possibly missing) gadget on every site one is active on.
Nevertheless the initial question is still valid: Is there a possibility to realign the [Edit] button's baseline with the section headings baseline? The way it looks now is quite ugly and not satisfactory: When changing such a fundamental design element at least a real possibility to correctly restore the old design should be provided. Not just a half-hearted cobble job like the current CSS that only somehow aligns the link on the right. --Patrick87 (talk) 23:22, 9 May 2013 (UTC)[reply]
The baselines are aligned; please check the facts before throwing accusations. Also, most of the projects were already using this look, en.wp was one of the outliers. Matma Rex talk 16:23, 11 May 2013 (UTC)[reply]
They are not (at least if where talking about the same thing). I accidentally assumed that this section was about edit-links "in the air", headings are actually fine for me. And where talking about edit-links moved to the end of the line by using .mw-editsection{ float: right; }.
So again for clarification: The edit-link's baseline is not aligned with the heading's baseline when restoring the old style with the proposed CSS. This should be fixed somehow. --Patrick87 (talk) 17:12, 11 May 2013 (UTC)[reply]
Ah, when using the float hack – you're right, apparently they aren't – but were they ever? This is caused by the line-height: 1em rule the CSS for new section edit links includes, necessary to avoid breaking the layout when the links use the same height as the headings they belong to. This works differently with floated links, though; as far as I can tell it's impossible to get them to align in the same way as non-hacked ones, but adding the line-height: inherit; rule should make them look better. But this should be done by local admins in the gadget anyway, and I can't do that. Matma Rex talk 18:05, 11 May 2013 (UTC)[reply]
I ammended the gadget, so the edit links should be more aligned. — Edokter (talk) — 19:30, 11 May 2013 (UTC)[reply]
Thanks for the change. This doesn't really fix the issue though. The bigger the heading the higher (relative to the baseline of the heading) the edit-link is displayed. Isn't there a a way to correctly align the links without manual tuning of position in CSS? --Patrick87 (talk) 21:35, 11 May 2013 (UTC)[reply]
Afraid not. I don't know what browser you have, but they do show fine for me in all four major browsers. They're se to inline-block which means they should align to the baseline. — Edokter (talk) — 23:53, 11 May 2013 (UTC)[reply]
I'm using Firefox 20.0.1. If you look really close or zoom the page you'll notice that the baselines are definitely not aligned to each other. --Patrick87 (talk) 05:37, 12 May 2013 (UTC)[reply]

IRC Office Hours Regarding Flow

On Thursday, May 09, 2013, there will be an office hours from 18:00 UTC until 19:00 UTC (11:00 am to noon pst) about the upcoming Flow project. Flow involves replacing user talk pages. We will be looking at an interactive prototype and discussing, well, everything. You really want to attend this. Please join us on Freenode, channel #wikimedia-office --Jorm (WMF) (talk) 00:28, 5 May 2013 (UTC)[reply]

Ugh, change.  — TORTOISEWRATH 00:44, 5 May 2013 (UTC)[reply]
Any chance for a repeat session for non-Americans? MER-C 09:42, 6 May 2013 (UTC)[reply]
Above session is not for Americans only. If you meant to refer to specific timezones though, it might be helpful to state which one(s) you have in mind. --AKlapper (WMF) (talk) 12:54, 6 May 2013 (UTC)[reply]
Right. I'm perfectly willing to do as many as need be, for as many time zones as need be. Just let me know when good times are?--Jorm (WMF) (talk) 19:53, 6 May 2013 (UTC)[reply]
Something suitable for Asian regions (say 12pm UTC) would be great. MER-C 03:16, 7 May 2013 (UTC)[reply]
Ugh, 12PM UTC is five a.m. for me. I'll find something, though.--Jorm (WMF) (talk) 20:03, 12 May 2013 (UTC)[reply]
Why does this have to be discussed on IRC? How many Wikipedia regulars whom this will impact actually use IRC? I certainly don't - and why should I have to?--ukexpat (talk) 18:27, 6 May 2013 (UTC)[reply]
IRC is the fastest way to get as many people involved in a conversation as possible, allowing for context and rapid response. There will be other types of conversations happening too - not just on IRC.--Jorm (WMF) (talk) 19:53, 6 May 2013 (UTC)[reply]
Meeting log available. Sumana Harihareswara, Wikimedia Foundation Engineering Community Manager (talk) 19:14, 9 May 2013 (UTC)[reply]

CAPTCHA and .js subpages

I logged in to User:IPLRecordsUpdateBot (the bot which I will operate) in order to create a subpage with some of its source code (which ends in .js, and such pages can only be edited by the user itself). On saving it I was prompted to enter a CAPTCHA for using an external link, but in .js subpages there are no external links. Why was I prompted to enter a CAPTCHA?

Possible reasons could be:

  • The text contains something like <a href="..., which may have been detected as an external link, but a tags are currently escaped by MediaWiki.
  • MediaWiki may have something to detect JavaScript which inserts external links into pages, and this one does insert links, but not anywhere on Wikipedia.
  • The square brackets used in regular expressions (e.g. /[a-zA-Z0-9]/) or for accessing/creating arrays (e.g. var a = [ 1, 2, 3]; a[1] = 'foo';) may have been taken as external links.

Similar reasons may apply for .css subpages as well. jfd34 (talk) 17:03, 6 May 2013 (UTC)[reply]

Although wikitext isn't rendered as such on js and css pages, the page is still parsed as if it were in order to pick up categories, wikilinks (for Special:WhatLinksHere), and so on. Which also means that ConfirmEdit picks up on any external links being added. ConfirmEdit can also look for certain other things, among which is the "<a href" that it probably saw in your script. Anomie⚔ 20:53, 6 May 2013 (UTC)[reply]
I don't think "<a href" has anything to do with it. If you save or preview the content of User:IPLRecordsUpdateBot/Source/IPLRecordsUpdateBot UI.js in a normal (not .js) pagename then this line produces an external link as seen here:
statusMsg.innerHTML = statusMsg.innerHTML.replace(/Committing edit\.\.\./, 'Edit successful (<a href="https://en.wikipedia.org/w/index.php?diff=' + revisionIDs[2] + '&oldid=' + revisionIDs[1] + '" target="_blank">diff</a>)');
By the way, I was surprised to see that diff going to the latest Main page edit. https://en.wikipedia.org/w/index.php?diff=0 goes to the same edit so a missing number is apparently taken as a 0. https://en.wikipedia.org/w/index.php?diff=1 has a more expected result 26 January 2002. PrimeHunter (talk) 23:09, 6 May 2013 (UTC)[reply]
"External" links to other WMF sites are whitelisted for ConfirmEdit's captchas. Check out the settings of $wgCaptchaWhitelist and $wgCaptchaRegexes in CommonSettings.php. Anomie⚔ 10:56, 10 May 2013 (UTC)[reply]

OpenDyslexic font

Wikipedia might make the OpenDyslexic font available to its readers.

—Wavelength (talk) 22:50, 7 May 2013 (UTC)[reply]

This can be accomplished by adding to Special:MyPage/common.css:
@font-face {font-family:OpenDyslexic;src:url('https://github.com/antijingoist/open-dyslexic/raw/master/otf/OpenDyslexic-Regular.otf');font-weight:normal;font-style:normal;}
@font-face {font-family:OpenDyslexic;src:url('https://github.com/antijingoist/open-dyslexic/raw/master/otf/OpenDyslexic-Bold.otf');font-weight:bold;font-style:normal;}
@font-face {font-family:OpenDyslexic;src:url('https://github.com/antijingoist/open-dyslexic/raw/master/otf/OpenDyslexic-Italic.otf');font-weight:normal;font-style:italic;}
@font-face {font-family:OpenDyslexic;src:url('https://github.com/antijingoist/open-dyslexic/raw/master/otf/OpenDyslexic-BoldItalic.otf');font-weight:bold;font-style:italic;}
*{font-family:OpenDyslexic;}
 — TORTOISEWRATH 23:36, 7 May 2013 (UTC)[reply]
Thank you. I previewed that subpage with the code added, and it works.
—Wavelength (talk) 00:35, 8 May 2013 (UTC)[reply]
I have started the page "Wikipedia:Dyslexic readers".
—Wavelength (talk) 00:49, 8 May 2013 (UTC)[reply]
I took the liberty of reformatting your CSS using <syntaxhighlight>. This isn't working for me, but I may have a conflict with one of my other scripts. Regardless, if useful, then this should be added as a Gadget. --  Gadget850 talk 10:09, 8 May 2013 (UTC)[reply]
This doesn't work for me on Firefox, only Chrome. I'm not sure why; Fx supports OTF embedding...  — TORTOISEWRATH 21:34, 10 May 2013 (UTC)[reply]
It might have to do with GitHub servers not sending the right CORS headers to allow such use. --SoledadKabocha (talk) 22:24, 14 May 2013 (UTC)[reply]
  • Scrambled word order might also be common for dyslexia: Or perhaps as a related problem, people should beware "putting the cart before horse the" where adjacent words get scrambled, or omitted. So, while an improved font could help, I still think, "There is no substitute for proofreading" as when people realize they tend to transpose or jumble words. A technique could be to move a thumb over the text and reveal each word, in order, to check the sequencing of words or commas, etc. -Wikid77 (talk) 09:23, 8 May 2013 (UTC)[reply]
Other fonts for dyslexics: I have now discovered that Dyslexia interventions#Classroom accommodations (version of 22:15, 5 May 2013) mentions other fonts designed for dyslexics.
  • Using appropriate font type and size. It is suggested[by whom?] that Sassoon and Comic Sans may be the easiest to read; Times New Roman may be one of the most difficult to read. The font should not be too small. There are several fonts and typefaces designed for dyslexia including Gill Dyslexic,[1] Read Regular,[2] Lexia Readable, Sylexiad,[3] OpenDyslexic,[4] and Dyslexie.[5] (Alphabet writing systems only)
Maybe similar code is available for the other fonts.
—Wavelength (talk) 16:34, 8 May 2013 (UTC)[reply]

Extension UniversalLanguageSelector allows to set OpenDyslexic as the default font for English text and other langauges. We spoke about making it available in Wikimedia wikis within a month or two in yesterday's Wikimedia Language Engineering team's Office hour. It also contains links to test environments. Siebrand (talk) 08:15, 9 May 2013 (UTC)[reply]

References

  1. ^ Gill Dyslexic
  2. ^ Read Regular typeface
  3. ^ Sylexiad
  4. ^ OpenDyslexic
  5. ^ Dyslexie font

Improved upload form on Special:Upload

Hi all,

I wanted to ask what you think about an improved Special:Upload upload form here on the English Wikipedia. Besides preloading the edit box with the {{Information}} template, a preview option before actually uploading proved very handy.

What I have in mind is something like either

  1. the basic version of the ImprovedUploadForm as it can be seen on Commons:Special:Upload?uploadformstyle=basic or
  2. the very similar upload form of the German Wikipedia, which only needs a few lines of JavaScript which can be found on de:MediaWiki:Onlyifuploading.js.

Tell me what you think about my proposal, your feedback is most welcome. --Patrick87 (talk) 23:47, 7 May 2013 (UTC)[reply]

I adopted the code from German Wikipedia and installed it as a user script. You can find the script on User:Patrick87/UploadForm.js, it's loaded from Common.js using the following code:
// Add preview button to upload form and preload with information template
if (mw.config.get( 'wgCanonicalSpecialPageName' ) === 'Upload') {
    importScript("User:Patrick87/UploadForm.js");
}
As stated above this script adds preview functionality to the basic upload form and preloads it wit the default file information template. --Patrick87 (talk) 20:38, 8 May 2013 (UTC)[reply]
Is no one using the basic upload form or are do those people actually using it never use preview functionality? --Patrick87 (talk) 21:58, 12 May 2013 (UTC)[reply]
FWIW: I can't recall when I uploaded to WP, as I usually upload to Commons. There I use the basic upload, and preview, as I find the upload "wizard" quite annoying. ~ J. Johnson (JJ) (talk) 22:09, 12 May 2013 (UTC)[reply]
I've used the basic upload form once or twice (not very often; I don't do much with images). I've had to go without preview since the form doesn't have the option. I use the basic upload form because the fancy upload wizard is dependent on JavaScript. Your script isn't much use to me for the same reason... It is a good idea, though. – PartTimeGnome (talk | contribs) 22:27, 12 May 2013 (UTC)[reply]

Does anyone know how to track and gather stats for usage of links to Wiktionary? Something similar to the stats.grok.se article traffic stats? Thanks! Dohn joe (talk) 21:47, 8 May 2013 (UTC)[reply]

(read the documentation), which says ".d" for Wiktionary, e.g.:
I'm wondering if the OP meant tracking links on enwiki pointing to enwikt. If so, there's some sort of links table database that a TS (or Wikimedia Labs™) person would have to run a query on. Killiondude (talk) 22:22, 13 May 2013 (UTC)[reply]
Yes, that's it exactly. How would I get in contact with a TS or Wikimedia Labs person? Dohn joe (talk) 22:30, 13 May 2013 (UTC)[reply]
Well, based on this edit, it seems you want to know how many visitors from the English Wikipedia click on a link to get to the English Wiktionary (or any?). Henrik wouldn't know since he just uses information given out at dumps.wikimedia.org (actual URL). You probably want to ask user:domas who maintains these things to some degree. I previously thought you wanted to know the number of links on Wikipedia that pointed toward Wiktionary. Killiondude (talk) 23:36, 13 May 2013 (UTC)[reply]
Yes, that is what I'm looking for, although the number of links would be interesting to know as well. I'll try asking User:Domas. Thanks for the help - it's much appreciated. Dohn joe (talk) 23:54, 13 May 2013 (UTC)[reply]
From the navigation panel at the left-hand side of a page, select "Special pages". From the section "Redirecting special pages", select "External links search". Enter http://en.wiktionary.org and see the results.
—Wavelength (talk) 00:02, 14 May 2013 (UTC)[reply]
Special:LinkSearch only finds urls like http://en.wiktionary.org/wiki/example and not interwiki links like wiktionary:example. PrimeHunter (talk) 00:18, 14 May 2013 (UTC)[reply]

editpage-specialchar: misuse warning

It is a bar in the edit form between the <textarea> (text editing window) and submit buttons and checkboxes, available even to IP editors. It is certainly a useful thing, and I do not see anything wrong with making symbols – — ° ≈ ≠ ≤ ≥ ± − × ÷ ← → · § so easily accessible. But easy accessibility of ″ ′ prompts dumb click-and-clickers and crackpots to use them as quotation marks (I know several cases), if not to promulgate the use of prime in “original” transcription systems (this instance had some consequences). IMHO primes should be moved, at least in English Wikipedia, from the default [Insert ▼] group to the [Symbols ▼] group, where they would be less prominent and prone to misuse by click-and-clickers. Incnis Mrsi (talk) 09:01, 9 May 2013 (UTC)[reply]

You are probably right, and I have wondered why so many editors use the curly quotation marks. So the insert-text box has listed them in the standard symbols, after the infinity sign:Template:J etc. I tend to agree, and it would probably reduce cleanup immensely, if the insert-text box showed, instead: 'x'   "x" as being examples for using single and double quotation marks. Talk about a really significant, but simple, change to improve the editing of articles. -Wikid77 (talk) 13:14, 9 May 2013 (UTC)[reply]
Please, do not divert the thread from the initial question so far. I raised the question only about the disturbing accessibility of primes. Curly quotes, although discouraged by MOS:QUOTEMARKS, do not constitute a blatant misuse if used as a quotes. We can eventually cope with curly quotes fully automatically by bots (or even more advanced means), but not with misused primes: the difference is that there are (few) completely legitimate uses of ″ ′ which are hard to distinguish formally from the crap. The only relevance of curly quotes to my question is an apparent reason behind primes and double primes produced by ignorant click-and-clickers: they mistakenly think that insert a curly quote while it is really an unrelated prime character. Incnis Mrsi (talk) 16:31, 9 May 2013 (UTC)[reply]
This is a vicious loop of changes that this symbol feature goes trough. Some people want to make symbols accessible for speciality areas (think IPA math etc) others (MoS people) then think that symbols that are not used in common english should not be accessible to users and that speciality users should copy paste from elsewhere. We remove stuff, we put stuff back and then 2 years later someone removes them again and a year later they are back. So good luck :D These particular ones are probably in there for DMS notation of angles and you can propose changes on MediaWiki_talk:Edittools. —TheDJ (talk • contribs) 17:18, 12 May 2013 (UTC)[reply]

British English / American English converter?

As many people have already seen, the difference of word/spelling variation between British and American English (mainly) has been an issue. I've seen rejected proposals of trying to establish a new "American English" wikipedia. Then I thought, why not learn from the Chinese Wikipedia? You can convert articles to Mainland Simplified Chinese, Hong Kong Traditional Chinese, Macau TC, Singaporean-Malaysian SC and Taiwan TC, whenever you like. They are only different versions of the same article, but not separated wikis. The method to do so is to define what words to change when you alter the version. For example, for an article of football/soccer, you can define which word to use in different versions. Here is an example of the code, imitating the Chinese Wikipedia:

{{noteTA
|T=en-am:soccer; en-gb:football;
|1=en-am:soccer; en-gb:football;
}}
"en-am" would be American English, while "en-gb" would be British English. T means the title and 1 means the first word to define its variety in the article.

What do you think? I'm not sure if anyone have suggested before but please express your views. -- Zamoeux (talk) 12:45, 9 May 2013 (UTC)[reply]

To be frank I think resources can be put to better use. Relatively speaking the differences between AmEng, BrEng (and let's not forget SAEng, AusEng and NZEng) are minimal compared to the differences between the various versions of Chinese, at least as I understand them from my colleagues in those Chinese-speaking countries.--ukexpat (talk) 16:16, 9 May 2013 (UTC)[reply]
Since Cantonese is my native language, I knew the variations of "Chinese" quite well. It's mostly with the Traditional and Simplified characters, some word variation and translations. Maybe you're right with the difference comparison. But I think the main issue would be the significant vocabulary and spelling difference, which can be confusing for non-native speakers. I know there is a Simple English Wikipedia but I don't think it's a waste to do so. It doesn't uses a lot of resources since a list of universal word conversion list which could be used by all articles. -- Zamoeux (talk) 16:50, 9 May 2013 (UTC)[reply]
So your 'universal word conversion list' would translate any occurrence of the word 'football' in a British-English article into 'soccer' in an American English version? That simply won't work. Think what would happen with "The boys were kicking a football around in the park...". To 'translate' one variety of English to another you have to understand it. Look at the mess machine translation usually makes, and ask yourself if that would be acceptable in Wikipedia articles. AndyTheGrump (talk) 17:03, 9 May 2013 (UTC)[reply]
Yep. Imagine a British royal visiting the U.S. and attending the Superbowl, and her article says it was a soccer game. There are so many potential exceptions that we'd be perpetually running around unconverting the conversions. Rivertorch (talk) 17:36, 9 May 2013 (UTC)[reply]
And it is easy to come up with many other scenarios where this would make things less clear. I can't speak to how well it works in Chinese, but machine translation of any kind is not a good way to generate coherent content in English. Beeblebrox (talk) 18:44, 9 May 2013 (UTC)[reply]
The thing is that Chinese simply uses different writing styles; it's possible to map simplified characters onto traditional characters. We could use this proposal to cause "centre" to appear as "center" to US English readers, and it would be a benefit. The reason we shouldn't adopt it is that it would take a ton of work for very few benefits. Nyttend (talk) 23:08, 9 May 2013 (UTC)[reply]
Yes, it could work for simple spelling difference such as color/colour and -ize/-ise. But it would not where the words are completely different, such as soccer/football, pants/trousers.--ukexpat (talk) 12:41, 10 May 2013 (UTC)[reply]
And it would work even less well when the same word has different meanings, eg table/table. --Carnildo (talk) 00:37, 11 May 2013 (UTC)[reply]
Yeah. My dog pants when I take him for a walk on a warm day. HiLo48 (talk) 01:29, 11 May 2013 (UTC)[reply]
And to add even more work to the template/functionality, you would have to consider Canadian English, which uses rules from both. We would standardize the colour of pennants flying from the walls of the shopping centre. Even in simple "translation", everything would have to be done in triplicate, at least. Resolute 00:42, 11 May 2013 (UTC)[reply]

Then there is Canoe English. I make up new words and spellings. USA and UK editors think they are correct on the other side of the pond and Canadian editors and me just giggle to themselves at the inside joke.--Canoe1967 (talk) 01:13, 11 May 2013 (UTC)[reply]

You are so vaverlocious! Just assume that it's a word here.  :-) North8000 (talk) 01:49, 11 May 2013 (UTC)[reply]
There was an interesting discussion on a cricket page recently where an American editor insisted that a description of cricket could be created for an American audience familiar with baseball, using the American concepts of attack/offence(/offense?) and defence. (Or should that be defense?) Anyone who knows both games will know that just ain't gunna work. In baseball the batters do the attacking. In cricket the bowlers make up the attack, and the batsmen both attack and defend. HiLo48 (talk) 01:29, 11 May 2013 (UTC)[reply]
I have little patience for people who willfully choose to be ignorant, so I am rather glad I didn't see that discussion.  ;) Resolute 02:00, 11 May 2013 (UTC)[reply]
Tomato/tomato --Redrose64 (talk) 13:36, 11 May 2013 (UTC)[reply]
Is there any dialect conversion tool other than those that do so for comedic effect? There are several language converters all of which have various issues. If someone has not developed a dialect converter, then I really do not expect to do so by use of templates. And this needs to be added to perennial, as it keeps coming up. --  Gadget850 talk 14:01, 11 May 2013 (UTC)[reply]
User:Ohconfucius/EngvarB. πr2 (t • c) 16:52, 11 May 2013 (UTC)[reply]

Hello! As the guy from Slovene Wikipedia few lines above said "this page seems to be the best place to get an answer" :) We at Latvian Wikipedia got our edit link appearance (similar to current one, but with small letters) written in the common.js page (after the row "//Kods rediģēšanas saišu novietošanai uzreiz aiz virsraksta"), but now after the global change of them we have the global version of them. And I think that almost everyone @lv wiki would be glad, if the old (Latvian Wikipedia style) would be used. Any suggestions, what to write in some js/css page? --Edgars2007 (talk/contribs) 16:01, 9 May 2013 (UTC)[reply]

If I were you, I would delete the old "Kods rediģēšanas ..." section of code from common.js, and go and add the following code to common.css:
.mw-editsection { font-size: x-small; }
If that is too small, try using font-size: small instead. — This, that and the other (talk) 06:23, 10 May 2013 (UTC)[reply]
For the record, the best place to ask this question would be the discussion of the meta page: meta:Talk:Change to section edit links. Matma Rex talk 15:25, 11 May 2013 (UTC)[reply]

Is the Job Queue out of whack again?

On :00.48 (UTC) on May 8, I linked 4 existing articles to a Template, and have been waiting for "What Links Here" on those 4 articles to populate with the other links on the template, as would be normal. However, as I write this, the only additions that show up on their "What Links Here" are the 4 added articles and the template itself, not the other links on the template. It's been 46 hours. I checked the Job Queue, and it doesn't seem backlogged. However, something else looks odd about it. Those exact same "jobs" figures have been there since two days ago. If I repeatedly refresh my browser, the numbers 5,434 and 8,752 show up as "jobs=", plus a couple of other numbers sometimes. But 5,434 and 8,752 have been showing up for two days. Is there something wrong with the Job Queue? — Maile (talk) 22:40, 9 May 2013 (UTC)[reply]

The graph at http://ganglia.wikimedia.org/latest/graph_all_periods.php?c=Miscellaneous%20pmtpa&h=www.wikimedia.org&r=hour&z=default&jr=&js=&st=1368034432&v=1516493&m=Global_JobQueue_length&z=large looks now fine to me, but there was an outage on Wednesday, 13:30 - 14:00 UTC, due to a memcached server going offline. Would be good to know if this is still a problem for recent changes. --AKlapper (WMF) (talk) 10:57, 10 May 2013 (UTC)[reply]
Yeah, I've still got the same issue, and I can't figure it out. But let me elaborate. See above Template I mentioned. If you click on any blue Wikipedia internal link that is listed prior to 2012, and go to "What Links Here", all the other links on that template - including the 2012 additions - have populated on the individual "What Links Here". However, the 2012 links were added May 8, 2013. If you click on any of those links, the template itself shows up under "What Links Here", as do the other 2012 links - but none of the pre-2012 links have populated under "What Links Here" for the individual 2012 articles. It's kind of strange. — Maile (talk) 11:22, 10 May 2013 (UTC)[reply]
  • WhatLinksHere can take 5 days to update after articles show new template: Even though the other 40 articles display the new revision of Template:Hawaiian Music Hall of Fame, the cross-wikilinks are not yet updated between all of them. In particular, the navbox-link article "Alfred Apaka" shows the new-revision template, but it is not yet indexed in WhatLinksHere for the new navbox-link articles. However, I ran a wp:NULLEDIT of two articles, "Benny Kalama" and "Ray Kinney" to force the wikilinks, and now they are listed in Special:WhatLinksHere/Hawaii_Ponoi (which should have 45 links when fully indexed). If not re-indexed by 14 May (5 days), then running 30 null-edits for the other 30 articles in the navbox would re-index the cross-wikilinks. -Wikid77 (talk) 15:33, 10 May 2013 (UTC)[reply]
Thanks for your help. — Maile (talk) 16:00, 10 May 2013 (UTC)[reply]

Delayed update on Special:WhatLinksHere

Special:WhatLinksHere/A Raisin in the Sun (film) and Special:WhatLinksHere/Titans (TV series) still list articles that have no links to specific targets after I changed links in templates and files. I wonder if there is delay on them. --George Ho (talk) 04:42, 10 May 2013 (UTC)[reply]

This might be related to #Is the Job Queue out of whack again? above. The Anonymouse (talk | contribs) 04:49, 10 May 2013 (UTC)[reply]

Talk page formatting anomaly

Could someone less clumsy with wikimarkup than I am please take a look at Talk:Kurdish people, where the formatting of the last two sections is all screwed up? I've tried various fixes, but none of them work, if Preview is to be believed. Rivertorch (talk) 22:47, 9 May 2013 (UTC)[reply]

That is strange. I can't fix it, either. It looks fine in "Preview", but when I "Save page", the text scrawls in tiny font, in a straight line off the right-hand side of the page. — Maile (talk) 22:55, 9 May 2013 (UTC)[reply]
It's just the same for me, except that I couldn't even fix it in Preview. I probably could find the issue if I had an hour or so to spend going through it line by line, but I don't. :( Maybe tomorrow, if no one else has any success in the meantime. Thanks for trying, anyway! Rivertorch (talk) 23:13, 9 May 2013 (UTC)[reply]
I got it! The problem was caused by the section above those two. The editor who posted there had some coding that I think was copied out of an Infobox, and there were no closing brackets, so the coding carried right on down the rest of the page. — Maile (talk) 23:24, 9 May 2013 (UTC)[reply]
Nice job! Thank you. Rivertorch (talk) 06:08, 10 May 2013 (UTC)[reply]
There was no need for closing braces, since the comment didn't include opening braces. The problem was actually unclosed <div> and <small> tags. Maile66's fix wrapped the whole thing in a table; this worked because tags opened in a table don't affect content outside the table. I've removed this fix and added the missing </div> and </small>. – PartTimeGnome (talk | contribs) 22:32, 10 May 2013 (UTC)[reply]
Interesting. I ran a search and counted various opening and closing tags, but I must have missed that one. All's well that ends well. Rivertorch (talk) 20:18, 11 May 2013 (UTC)[reply]

Watchlist past a month?

I need to see a few things on my watchlist that are a few days over a month old. Does anyone here know how I can do that or does anyone here have the power to see that?

Checking everything on my watchlist is out of the question because there are over 400 articles on my watchlist. --TheShadowCrow (talk) 23:09, 9 May 2013 (UTC)[reply]

You can't. Maybe break up your watchlist into something more manageable? Killiondude (talk) 04:46, 10 May 2013 (UTC)[reply]
The watchlist is limited by the recentchanges database table which only stores up to 1 month. Legoktm (talk) 04:48, 10 May 2013 (UTC)[reply]
You can view an alphabetical list of all pages on your watchlist that also includes their last modified dates via m.wikipedia.org (watchlist linked). Theopolisme (talk) 14:24, 11 May 2013 (UTC)[reply]

Other pageview tools

I want to test https-protocol pageview counts with other tools (see above: "#Confirmed stats.grok pageviews omit https"). Does anyone remember the other pageview tools besides stats.grok.se? -Wikid77 10:47, 10 May 2013 (UTC)[reply]

Don't know if this is the grok source, but there's http://dumps.wikimedia.org/other/pagecounts-raw/ — Maile (talk) 11:38, 10 May 2013 (UTC)[reply]

Wayback Machine snapshots

I draft an article in my userspace where I have some citations using citation templates. I filled in the archiveurl parameters with Wayback Machine urls as the parameters. The archive links on Wayback have the form http://web.archive.org/liveweb/http://www.finanznachrichten.de/. Does the liveweb in the url mean that those are not snapshots on Internet Archive servers but just redirects to the live resource on the web? Does WbM actually have snapshots of those urls or not? See here for my draft. -- Toshio Yamaguchi 13:13, 10 May 2013 (UTC)[reply]

Smallman12q (talk) 21:28, 10 May 2013 (UTC)[reply]

File replacement

How long does it take for a file to be updated? I uploaded a new version of File:ParisMontage1.jpg about an hour ago, but it still shows the old version in Paris. I have tried purging all the caches etc.--Gilderien Chat|List of good deeds 19:28, 10 May 2013 (UTC)[reply]

I can't easily see the difference between the current image and the one before. One of those two shows for me when I load the article. Secretlondon (talk) 19:32, 10 May 2013 (UTC)[reply]
The new one has a different, lighter top image, but it still doesn't load for me. It also shows the old one in the file page history table.--Gilderien Chat|List of good deeds 20:23, 10 May 2013 (UTC)[reply]
The previous version, timed 17:36 UTC is bit-for-bit identical to the current one, timed 17:38 UTC. --Redrose64 (talk) 20:31, 10 May 2013 (UTC)[reply]
You need to give a source for the top skyline image, by the way. Secretlondon (talk) 21:50, 10 May 2013 (UTC)[reply]
Yes, the file thumbnail didn't update, so I thought I had re-uploaded the old version. I think I have provided a source on commons, I just cropped the image shown at the bottom of the data.--Gilderien Chat|List of good deeds 22:01, 10 May 2013 (UTC)[reply]

Educational assignment template

Could somebody who's proficient at template syntax take a look at {{Educational assignment}}? The template has a problem with future/past tense depending on when the assignment ends. A discussion about this was started a year ago but it still doesn't work properly. The template somewhat unfortunately uses either "date" exclusive or "day", "month", "year" as parameters. It'd be good too if there's a test that gives an "incorrect usage" message if both are used. Jason Quinn (talk) 20:17, 10 May 2013 (UTC)[reply]

Show parent categories for articles

Right now, the tree structure of categories hides the fact that articles are also categorized under the parents of the categories they are in. This makes for confusion as shown by Category talk:American novelists. If we showed the parent categories for pages, this would prevent this confusion. Also this would fix the problem of people constantly adding parent categories to pages that are already under a child category. Transcendence (talk) 01:13, 11 May 2013 (UTC)[reply]

This would also cause issues for parent categories that are not content categories. It would also result in oddities such as AMBO pipeline being shown as being in Category:Seas of the Atlantic Ocean. Anomie⚔ 14:46, 11 May 2013 (UTC)[reply]
A solution would be to distinguish "this is an item in a cat" from "this is a subcat of a cat". Another solution is to scrap all the subsubsubcats and intersection-cats, and instead use lots of cats and then use a WP:CatScan-like tool to find the intersections one wants. DMacks (talk) 07:12, 12 May 2013 (UTC)[reply]

VisualEditor inserting pawns into articles

Tracked in Phabricator
Task T50346

You may want to hold off on using the VisualEditor for a few days. It seems to be inserting chess pieces into article text. This is a common problem with software that reaches a certain level of sophistication, so I'm sure the developers will have a fix for it soon :) Kaldari (talk) 06:19, 11 May 2013 (UTC)[reply]

This was already fixed when reported, but won't be deployed here until 20 May, I'm afraid. Jdforrester (WMF) (talk) 02:23, 14 May 2013 (UTC)[reply]
Of course, a pawn is not a chess piece, although it is a chess man. --Trovatore (talk) 02:29, 14 May 2013 (UTC) [reply]

Category suggestions when using HotCat are gone

Resolved

Up until recently, when I added a category to an article using the + sign at the bottom of an article with HotCat, when entering something into the text box I would receive category suggestions. Has this functionality been removed? I no longer get suggestions when entering something into the field. -- Toshio Yamaguchi 09:31, 11 May 2013 (UTC)[reply]

There have been no recent changes in HotCat, so the problem must be somewhere else. Lupo 10:11, 11 May 2013 (UTC)[reply]
It works again. Thanks for the response. -- Toshio Yamaguchi 10:49, 11 May 2013 (UTC)[reply]

userspace page found by Google

I received an email in the last few days from Google Alerts telling me about http://en.wikipedia.org/wiki/User:Nick_Levinson/Eva_Moskowitz_former_article (referring to the current revision, which is indirectly represented by http://en.wikipedia.org/w/index.php?title=User:Nick_Levinson/Eva_Moskowitz_former_article&oldid=554154449). That implies the page can be found in a Web search through Google by my name alone. In this case there was no harm but I don't think the visibility to an external search engine of a userspace page is your intention. Maybe something needs fixing or maybe it was just a fluke. Nick Levinson (talk) 16:50, 11 May 2013 (UTC)[reply]

Yep. That's what Google does. You can tell them not to do that by adding the magic word __NOINDEX__ to the page concerned; or, as seen top of User:Redrose64, you could add {{userpage|noindex=yes}} which does the same but wrapped in an explanatory box. --Redrose64 (talk) 19:27, 11 May 2013 (UTC)[reply]
(ec) User pages are not being excluded from indexing by default, but user talk pages are. — Edokter (talk) — 19:29, 11 May 2013 (UTC)[reply]
Tracked in Phabricator
Task T50389

Whenever I try to add an interwiki link by following the "Add link" link in the "Languages" section, the following error message pops up: "You need to be logged in. You need to be logged in on this wiki and in the central data repository to use this feature." However, if I visit Wikidata it seems I am already logged in there with my global login. This problem occurs not just with English Wikipedia but with other Wikipedias. Is this a known issue? Regardless, this error message is supremely unhelpful; it doesn't provide any indication as to what the "central data repository" is or how to log in there. —Psychonaut (talk) 17:43, 11 May 2013 (UTC)[reply]

I have reported this for you at bugzilla:48389. We will look into it. --Lydia Pintscher (WMDE) (talk) 20:23, 12 May 2013 (UTC)[reply]
Psychonaut, could you please let me know which browser you used while encountering the above issue? Without that information I can only guess what the issue might be. - Hoo man (talk) 20:29, 12 May 2013 (UTC)[reply]

Feature request: my todo list in Wikipedia:Notifications

Well, section title says it: can the new Wikipedia:Notifications feature give me the option to maintain a "todo"-list? I figure it could work like this: On a wiki page, I can add (click somehow) "todo", and add my note ("I should check thing x"). Whether my notifico-todo-listo is public or private is a discussion to be, of course, todo'ed. -DePiep (talk) 18:34, 11 May 2013 (UTC)[reply]

What's the connection to notifications? Sounds more like an annotated watchlist to me. Interesting idea though — HHHIPPO 18:57, 11 May 2013 (UTC)[reply]
I thought: WP:Notifications covers similar things. Indeed an annotated watchlist covers it too (can I filter it on "my todo-marked pages"?). If that can provide the function, fine with me. -DePiep (talk) 19:05, 11 May 2013 (UTC)[reply]
Well, WP:Notifications covers notifications. I'm not sure what kind of notifications you would expect from a todo-list, other than those provided by a watchlist. What functions an annotated watchlist would have is hard to answer, since it's a hypothetical feature anyway. Having a filtered watchlist (or equivalently, several watchlists) would also be nice indeed. If you don't mind all that being public you can make it manually though: just create a page in your user space, add links to all the pages you want to watch (and the talk pages), and add annotations as you like. Then use "Related changes" to use it as a watchlist. — HHHIPPO 19:48, 11 May 2013 (UTC)[reply]
Currently, I sometimes make elaborate notes on my Userpage: [3]. There, I cannot "click done". I requires full edits. But hey, If you think it an interesting idea though, why not elaborate on that?
Consider it Just My Association (Running Away with Me) -DePiep (talk) 20:14, 11 May 2013 (UTC)[reply]
Yeah, nice try ;-) I meant interesting to have, not "I'd be interested in coding it". — HHHIPPO 20:56, 11 May 2013 (UTC)[reply]
I meant to say: if you get it, support it. Technical problems we can do. -DePiep (talk) 21:03, 11 May 2013 (UTC)[reply]

I think I just got your original proposal: you'd like a way to manually add entries to your list of notifications, which will then stay there reminding you of things to be done until you mark them as done? That sounds like a nice feature. Maybe not for a long-term todo-list (for which I use a local file) but for things to remember within one editing session (where I keep all pages needing attention open in multiple browser tabs). So yes, support. But I'm afraid it's only one out of many items on the devs' todo-list. — HHHIPPO 22:01, 11 May 2013 (UTC)[reply]

Yeah, priority may be low. As with most of my thoughts ;-) -DePiep (talk) 10:29, 15 May 2013 (UTC)[reply]
I just imported from hewiki a short and sweet script that lets you define any number of "todo" lists, and add to the "hidden menu" (the one that houses the "move" button) one button per each todo list. pressing the button will add the current page to this list. see documentation. peace - קיפודנחש (aka kipod) (talk) 22:49, 11 May 2013 (UTC)[reply]
Thanks, sounds promising. Will take a further look. have put it on my -current- todo list. -DePiep (talk) 10:29, 15 May 2013 (UTC)[reply]

Finding typos

Hi, I'm trying to create an easy entry-point for an editor to make their first edit. The Getting Started tour is excellent for that, but I'm also looking into simple typo-fixing using commonly misspelled non-language-variant words, such as "recieved". I'm finding that if I search for these words using the search box, or the contains option of the search box that I cannot find persistent typos. Either they have already been fixed, or they are spelling redirects. Does anyone have an idea for how to find typos in Wikipedia articles that need fixing? This is a great exercise in breaking the 'fourth-wall' for editors and showing them an easy way to contribute with little difficulty. Thanks and cheers! Ocaasi t | c 21:32, 11 May 2013 (UTC)[reply]

Wikipedia:Lists of common misspellings
Wikipedia:WikiProject Fix common mistakes Bgwhite (talk) 21:54, 11 May 2013 (UTC)[reply]
Plus Wikipedia:Database reports/Linked misspellings -GoingBatty (talk) 21:59, 11 May 2013 (UTC)[reply]
Also see Wikipedia:Typo Team and Wikipedia:WikiProject TypoScan. – PartTimeGnome (talk | contribs) 16:39, 12 May 2013 (UTC)[reply]
Thanks for all of these tips! Ocaasi t | c 02:57, 13 May 2013 (UTC)[reply]

FYI: Toolserver web tools and bots down

Our friendly toolserver admins/roots are aware (see mailing list). In the meantime, migrate to Labs! Theopolisme (talk) 01:12, 12 May 2013 (UTC)[reply]

That depends on how much the WMF is willing to pay me. They have a spectacular record of pushing ahead with bad ideas and then ditching them. Not worth the opportunity cost of developing something else for the community. And there's some comfort knowing the WM-DE can run Wikipedia if another image filter debacle comes up. — Dispenser 03:01, 12 May 2013 (UTC)[reply]
To put the above in a wider context, Toolserver users (of which I am one) have invested hundreds (if not thousands) of voluntary hours building useful tools to aid in the writing and maintainance of Wikimedia projects like Wikipedia. Differences between the way Labs and the Toolserver work mean that it'll take quite a bit more voluntary effort to move things over. Many (most?) Toolserver users are struggling to justify putting in this work until there's an expectation that Labs will offer some advantage to our tools. - TB (talk) 11:22, 12 May 2013 (UTC)[reply]
This worries me greatly. Every system this important should have a backup. What, exactly, would it take to make a backup toolserver that would keep running if the main one went down for an extended period? If funds are required, we can raise our own, independently of Wikipedia. bd2412 T 12:59, 12 May 2013 (UTC)[reply]
Let's see ... bare minimum, three server boxes, rack space + pipe, 0.5 FTE admin and a data feed from Wikimedia ... $60k + $60k/year. Realistically, around double these figures to run a useful equivalent as a backup. - TB (talk) 17:06, 13 May 2013 (UTC)[reply]
You could run it for way less than that using cloud services like EC2, rackspace cloud, hp cloud, etc.. I recommend using rackspace/hp or one of the other OpenStack based clouds for compatibility with Labs. If you'd like to have independence from WMF, we don't discourage it. Everything we're doing is open source and in Gerrit. I've been building Labs with forkability specifically in mind. I believe our current database replication strategy should make it easier for us to define non-labs replication targets if the community finds it necessary.--Ryan Lane (WMF) (talk) 01:01, 15 May 2013 (UTC)[reply]
That's good to know thanks. Not sure how the plan is progressing - are things in a position yet to give and easy estimate of the bandwidth required to accept a feed of the binlogs from PreLabsDBDBS? - TB (talk) 18:34, 15 May 2013 (UTC)[reply]
Far as I know, independence is the underlying problem. German Wikimedia Chapter run Toolserver and don't have enough money. WMF don't want to give them the money and instead will replace Toolserver with something much better, in-house. Someday. Jim.henderson (talk) 13:08, 12 May 2013 (UTC)[reply]
Then how can we either support the German Wikimedians in their efforts, or begin our own. We absolutely must have tools that are independent of such "political" concerns. Important repairs can not be done, and are falling behind. bd2412 T 13:22, 12 May 2013 (UTC)[reply]
The 2013 WM-DE budget is 5 million € and includes Wikidata development. It is the uncertainty of running a service that is largely dependent on WMF not threatening to cut off the database feed. That feed makes the Toolserver different from other chapter run servers.
The WMF attitude of throwing away and redoing what works deters and detracts programmers ("Why should I make it if its going to be thrown out anyway?") and leads to when announcements are made that work in the area stops. They also internally price volunteer effort at zero dollar; which is why they have so many reader focused initiatives (and helps brings in donations to boot). — Dispenser 14:39, 12 May 2013 (UTC)[reply]
I wouldn't worry too much about Labs being ditched. It's an integrated part of WMF's development and testing process (the deployment-prep project) as well as a development and demo location for hackathons and such. It also greatly reduces the load on the operations team as it allows our staff and volunteer developers to make infrastructure changes (and the project is run by the operations team).--Ryan Lane (WMF) (talk) 01:10, 15 May 2013 (UTC)[reply]
  • Comment My understanding is that Wikimedia Labs is replacing the toolserver. The WMF planned to stop supporting the toolserver at the end of 2013 in favor of Labs. That caused WMDE to remove their funding, which is 90% plus of the operating costs. From what I've read, the tentative plan is to decommission the toolserver at the end of 2014 and give away the servers. Meaning there will be no toolserver 2 years from now. This is all tentative, but I have not seen any other plans to keep the toolserver running at this point. As far as I know, WMDE will decide what happens on May 25th, 2013 when they get together, but there is something of a Toolserver vs. Labs controversy (see here and here), so who knows what will happen. 64.40.54.26 (talk) 14:54, 12 May 2013 (UTC)[reply]
For more information there is https://meta.wikimedia.org/wiki/Future_of_Toolserver but I don't know how up-to-date that is. --AKlapper (WMF) (talk) 09:08, 13 May 2013 (UTC)[reply]
That document is rather outdated, as it represents the picture last September while many things were still rather uncertain. I don't think we currently have a clean overview document of the current status, although the current TODO list gives a good idea of the current completion. In practice, any tool that does not need direct access to the replicated database can be hosted in the Tool Labs already (and many already are. — MPelletier (WMF) (talk) 01:40, 15 May 2013 (UTC)[reply]
Hi all! WMDE has several reasons to discontinue the toolserver. This is not only about WMF's database dumps or about funding but the whole project is complicated to run the way we've been doing it: The toolserver has grown to become an infrastructure of ~25 servers, that has been taken care of by only two part-time/volunteer admins. (They will be three from now on to improve the situation.) It has become an essential part of community development for Wikimedia projects: Such an infrastructure requires more planning of capacities and a good documentation of the setup. We do not want a project that completely depends on very few individuals. (For example, it should be possible for an admin to leave without the whole project collapsing.) For us, there is a physical barrier, too: The toolserver is in a data center in the Netherlands to which WMDE doesn't have access (WMF has, but nobody is on-site or very close to it permanently). So the process to replace hardware there is always tedious. So the toolserver now has a size and importance that would greatly benefit from a more professional surrounding in organizational matters and we think that WMF can offer this with a bigger ops team (consisting of paid staff and volunteers) and the cloud-based concept that is integrated into a larger setup. As to the most recent status documentation, here are some links: Roadmap for the migration, Overview of features needed in Tool Labs, WMF database plan (for the db replication issue), List of tools running in Tool Labs: http://tools.wmflabs.org/, First draft of FAQ (tbc) That said, WMDE will continue to run the toolserver until Tool Labs is ready and volunteers have had a reasonable amount of time to migrate (one year as you can see on the roadmap). Silke WMDE (talk) 10:29, 15 May 2013 (UTC)[reply]

tools:~dispenser

Not sure if this is related to the above post .....but we have some links (as seen below) that are on hundreds of page (mostly project and help pages) that are not working. Will they be returning or should we get a bot to go around and remove the tools?Moxy (talk) 06:21, 12 May 2013 (UTC) tools:~dispenser....like[reply]

Yes, it's the same problem. Sounds like Dispenser is refusing to migrate to Labs, which might make things a bit difficult for these tools down the track. In the short term, though, I would expect that they will start working again before long. — This, that and the other (talk) 06:51, 12 May 2013 (UTC)[reply]

Also intermittent problems when clicking on geographical co-ordinates on any Wikipedia article, as this also uses toolserver. Getting "Bad Gateway", time-outs and so on. In the meantime I've taken to manually copying and pasting the co-ordinates from the articles directly in to Google maps. Also issues with other tools I use such as GLAMorous - indeed it appears like it is all to do with the same underlying issue. Rept0n1x (talk) 07:39, 12 May 2013 (UTC)[reply]

So, now it's a second day without these services. Will it be another two weeks before a decision is made? And perhaps months for something actually to go live? Ought relevant templates such as "coord" be hidden until then? Jim.henderson (talk) 11:44, 13 May 2013 (UTC)[reply]
So, an hour later, Geohack etc are working. I hope something steadier can be established soon. Jim.henderson (talk) 12:47, 13 May 2013 (UTC)[reply]

DYK tools

This also affects Did You Know, since all nominations there have to be checked for copyvio and close paraphrasing. The tools that I'm aware of affected by this are:

— Maile (talk) 11:58, 13 May 2013 (UTC)[reply]

The Duplication Detector now resides at https://tools.wmflabs.org/dupdet/ . MER-C 12:59, 13 May 2013 (UTC)[reply]
Thank you! — Maile (talk) 13:11, 13 May 2013 (UTC)[reply]

WP:AFC tools

{{AFC submission}} links two of the tools, Webreflinks http://toolserver.org/~dispenser/cgi-bin/webreflinks.py and CitationBot http://toolserver.org/~verisimilus/Bot/citation-bot/doibot.php - both passing the name of the proposed article as a parameter. This appears on the several hundred articles currently backlogged at Category:Pending AfC submissions as a means of cleaning up bare references on newly-submitted pages. These were down but seem to be back up at the moment; will there be more issues with these in the future? K7L (talk) 16:26, 13 May 2013 (UTC)[reply]

Year with comma

I know - I'm a pedant. I wouldn't do a lot of the WP task I do if I wasn't. But one thing rankles me every time I look at a contribs page, and there must surely be an easy fix to it. Go to your "user contribs" page, and in the box at the top you will find "From year (and earlier): 2,013". Is there some way the comma can be suppressed to make the year numbers right and stop the strange itching I get whenever I see it? It also strikes me as odd that you can check all contributions from, say, 1890 and earlier - but that's an even more minor problem... Grutness...wha? 01:54, 12 May 2013 (UTC)[reply]

I don't see a comma. It says 2013 for me. —Designate (talk) 02:07, 12 May 2013 (UTC)[reply]
Perhaps it's a problem with the MonoBook skin I'm using - here's a screenshot of how it appears for me. Grutness...wha? 11:22, 12 May 2013 (UTC)[reply]
Nope, monobook is fine for me. It could be your browser - are you using Safari on Mac? -- King of ♥ ♦ ♣ ♠ 11:33, 12 May 2013 (UTC)[reply]
(edit conflict)Let me guess... you're using a very modern browser? Chrome or Safari, maybe? Your browser is seeing that the year field is described as containing a "number", and so it is kindly providing you with thousand separators and a nice little up/down spinner. However, the separators shouldn't be seen for year values. I wonder if there a way around this in the HTML5 specification... — This, that and the other (talk) 11:40, 12 May 2013 (UTC)[reply]
Another possibility could be user scripts. One of those might be interfering. I've not looked at specifics, but I notice that User:Grutness/common.js is lacking a "); from the right-hand end of its single line. --Redrose64 (talk) 11:51, 12 May 2013 (UTC)[reply]
Using the Vector skin, I see the comma in Safari (iPad) but not in Firefox. JohnCD (talk) 12:07, 12 May 2013 (UTC)[reply]
That's Safari showing the year as a pretty number. The field has type "number", so there is no indication that it is even a year. Ideally, the type should be "month" to combine both fields, but IE and Firefox do not support this type. — Edokter (talk) — 12:35, 12 May 2013 (UTC)[reply]
It's curious that the <input>...</input> element allows type=month as an attribute - which is actually a year/month combination - but has no type for year alone. --Redrose64 (talk) 13:23, 12 May 2013 (UTC)[reply]
Is there a bug report for this already ? —TheDJ (talk • contribs) 17:04, 12 May 2013 (UTC)[reply]
Perhaps https://bugs.webkit.org/show_bug.cgi?id=62939? Although that indicates the bug has been fixed for some time now, and I see correct behavior (no comma, but spinner controls) in Chromium 26. But when Apple will update Safari, I have no idea. They don't seem to make their bug reports public. Anomie⚔ 18:27, 12 May 2013 (UTC)[reply]

Performance considerations regarding custom CSS an JavaScript (globally used)

Hi all,

I'm recently experimenting with global CSS and JS files which I'm storing centrally on my home Wiki and which I can easily load from all Wikimedia projects I'm active on. Right now I have a global.css and a global.js on German Wikipedia and I load them from common.css or common.js respectively using 

/* ########## load global.css from dewiki for cross wiki usage ########## */
@import "//de.wikipedia.org/w/index.php?title=User:Patrick87/global.css&action=raw&ctype=text/css";

and 

// ########## load global.js from dewiki for cross wiki usage ##########
mw.loader.load('//de.wikipedia.org/w/index.php?title=User:Patrick87/global.js&action=raw&ctype=text/javascript');


I'm now wondering how well this works performance-wise. That means how fast those files are loaded on a fresh page load and if they are correctly cached for subsequent page loads. Does anyone have an idea or even some numbers on how well my current approach performs?

For example I could omit the common.css at all and just put an additional mw.loader.load("//de.wikipedia.org/w/index.php?title=User:Patrick87/global.css", "text/css"); into my common.js.

Furthermore I'm wondering whether it matters were the global code files are stored? Is it OK to have them in the user space of my home Wiki or should I transfer them to another Wikimedia project? Is it useful to have them on a Wikimedia server at all or should I even try to put them on the fastest server I'm able to find?

I hope some of the geeks can shed some light on all this, since I'm neither familiar with such performance considerations in general nor with the MediaWiki related specialties.

Regards, --Patrick87 (talk) 14:23, 12 May 2013 (UTC)[reply]

Since all js scripts and css files are processed on the client side, the performance will mainly depend on the browser/OS/computer that you use. Ruslik_Zero 16:37, 12 May 2013 (UTC)[reply]
Actually, there might be server-side differences in performance because the global CSS/JS files are not being loaded through ResourceLoader. However, unless you have problems related to performance, don't worry about it. – PartTimeGnome (talk | contribs) 17:14, 12 May 2013 (UTC)[reply]
Well, I notice some small delays now and then. However it's hard to tell If they stem from the additional loading of global code files or from loading of scripts themselves. Probably both, but since it's a noticable delay I'd like to optimize loading times as much as possible without loosing the convenience of global code files. — Preceding unsigned comment added by Patrick87 (talk • contribs) 18:16, 12 May 2013 (UTC)[reply]
As this is very browser dependent, it would probably help if you reported which browser you are using. Additional DNS lookups might introduce a delay for instance, but then Chrome pre loads dns lookups right away, so it should only affect you very shortly on the first pageview session. Other browsers (or versions of other browsers) might not be so agile. —TheDJ (talk • contribs) 13:20, 13 May 2013 (UTC)[reply]
I'm using Firefox (currently version 20.0.1) on Windows 7. --Patrick87 (talk) 14:33, 13 May 2013 (UTC)[reply]

Audio Pronunciation Modification Suggestion

Hello!

I am currently a medical student and almost all my classmates and I (as well as health care professional students across the country) use Wikipedia to supplement some of the basic science information regarding the various topics we are studying. Currently we are in pharmacology and I've found myself constantly looking extra information about various pharmaceutical drugs up on Wikipedia only to have to look at secondary sites to look up pronunciation. I know that there is a way to make an audio pronunciation for words (e.g. - https://en.wikipedia.org/wiki/Onomatopoeia) and I've started tagging the tougher words so it shows up on https://en.wikipedia.org/wiki/Category:Requests_for_audio_pronunciation_%28English%29 and will hopefully get added, but when the audio clip is functioning properly it opens up a new window - which in my opinion is a big detractor. The other secondary sites that I am regularly using to look up pronunciations are forvo.com and howjsay.com - both of which are able to play the audio without having to load a new browser. That said, it is very frustrating to keep going back and forth between the two tabs and I feel like this feature could be a great improvement for Wikipedia.

I spoke via email with a Wikipedia representative (Luke Faraone) about this and he suggested that I post here because it would require a modification to the WikiMedia software. Would this be possible?

Thank you for your time and consideration. Let me know if you have any more questions.

Sincerely, Michael Tudeen — Preceding unsigned comment added by Mtudeen (talk • contribs) 16:13, 12 May 2013 (UTC)[reply]

Providing an explicit example, webbrowser information (name and version) plus steps to reproduce the problem are highly welcome. --AKlapper (WMF) (talk) 09:11, 13 May 2013 (UTC)[reply]
Since I do understand what Mtudeen is writing about I am going to start with explaining what (s)he is talking about and following that by mentioning the next steps. In a nutshell this is an template issue.
Mtudeen is talking about the template Audio - shown as pronunciation (US)ⓘ in the article Onomatopoeia. Mtudden dislikes that when (s)he clicks the link, then (s)he goes away from the page to a different page where the audio is played. This can easily be replicated by clicking the "pronunciation (US)" link above. Now, what Mtudden wants is that the audio should be played on the Onomatopeia page itself. That can be done with an template like Template:Listen - shown as
Onomatopoeia
Problems playing this file? See media help.

.

Now for the second part of my comment. While the template listen could in theory be used instead of template audio in the lead section of the page, I know that some users would dislike that for aesthetic reasons. So, I do think that this issue needs more discussion than it allready has and even some thought when it comes to design.--Snaevar (talk) 14:24, 13 May 2013 (UTC)[reply]

So is there be a way to implement the template listen function in a modified format that is more aesthetically pleasing? Instead of the current image, for example, just showing a small gif that looks like a speaker with sound waves coming out of it and clicking on it (or the word immediately following it) would allow you to hear the sound on the webpage you are currently on?--Mtudeen (talk) 20:20, 15 May 2013 (UTC)[reply]

Almost everything is possible, but it's open source software, so you need to find someone to actually create it and submit the patches. It's a question of time, effort and resources. —TheDJ (talk • contribs) 20:52, 15 May 2013 (UTC)[reply]

missing localized text in the Edit form

Resolved

Hello! When editing a page, there's a <cite-section-label> and a <cite-template-list> texts that should probably be changed to something more meaningful. However, I can't find where they are coming from (I couldn't find them in Special:AllMessages). Any idea? -- Luk talk 17:56, 12 May 2013 (UTC)[reply]

I don't know what you refer to with <cite-section-label> and <cite-template-list>. Does it literally say that? Where do you see it? Does it happen when you are logged out? If it only happens when you are logged in then what is your skin and language at Special:Preferences? What is your browser? PrimeHunter (talk) 21:00, 12 May 2013 (UTC)[reply]
Like PrimeHunter, I can't see this text either. MediaWiki uses angle brackets around message names to indicate that no translation can be found for that message, not even in MediaWiki defaults. Hence, for the examples given the messages are MediaWiki:cite-section-label and MediaWiki:cite-template-list. Since others can't see this, please check if these messages are from a user script or gadget. If so, contact the script author. If the messages come from MediaWiki itself, please file a bug; MediaWiki should not be outputting non-existent messages. – PartTimeGnome (talk | contribs) 21:41, 12 May 2013 (UTC)[reply]
It's the fourth text button in (modern) WikiEditor, which normally says "Cite" and allows to insert citation templates. I saw it sporadically, too, today. It might be a timing issue since it's not always displayed and often fixed after a page reload. --Patrick87 (talk) 21:53, 12 May 2013 (UTC)[reply]
It's apparently from MediaWiki:RefToolbar.js. I can get it to say <cite-section-label> by changing language, for example http://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=edit&uselang=fr. PrimeHunter (talk) 22:09, 12 May 2013 (UTC)[reply]
I got this once while editing the sandbox logged out in IE 10. However, I was unable to reproduce it in Firefox or Chrome, and upon logging in with IE, it worked correctly, and now I can't reproduce it in IE even after logging out and clearing the entire cache. Language set to the default of en the entire time. I also can't reproduce it with the fr link that PrimeHunter provided in any of these three browsers. Sounds like it happens completely at random, which is the worst kind of bug. jcgoble3 (talk) 04:56, 13 May 2013 (UTC)[reply]
I get it more or less consistently when using PrimeHunter's link (FF20.0, Ubuntu, MonoBook). Whenever I change the uselang= parameter, the message names appear. After reloading the page without changing uselang, the actual messages are displayed, but always in english. The only exception I found is uselang=de, where I get the German messages right away. Hope that helps. — HHHIPPO 06:49, 13 May 2013 (UTC)[reply]
I assume that this is the culprit. I can't reproduce the problem any more, but I'm also on a different PC. — HHHIPPO 07:27, 13 May 2013 (UTC)[reply]
Probably, it seems OK now. -- Luk talk 09:42, 13 May 2013 (UTC)[reply]

Is this a bug or a feature?

If I edit a protected page, it gives me a large multi line warning and all the edit window is in red. After editing, the page is still protected - all OK. However if I create a previously salted page, the warning is not so obvious, the edit window has a white background like an unprotected page, and after pressing "save", the article is unprotected and the protection log show no evidence of protection being removed - check my test at http://en.wikipedia.org/w/index.php?title=Special:Log&page=User%3ARonhjones%2FSandbox4 - the last entry is fully protected and the page is currently unprotected.  Ronhjones  (Talk) 18:08, 12 May 2013 (UTC)[reply]

You have two issues here:
  1. The mw-textarea-protected class is not applied to the textarea in the edit form for create-protected pages.
  2. Create protection is automatically and silently removed when the page is created.
The first is certainly a bug; please file a bug report for it.
I don't know about the second, since it mirrors the automatic and silent removing of edit protection when the page is deleted. The "automatic" part certainly makes sense, as the change in state means the old protection no longer applies. I'm not entirely sure about the "silent" part, but it should be changed in both cases if it's changed in either. You can file a bug for that one too if you want, or you could wait for more opinions on whether it's actually a bug or not. Anomie⚔ 19:20, 12 May 2013 (UTC)[reply]
I've lumped it all together at Bug 48411.  Ronhjones  (Talk) 19:05, 13 May 2013 (UTC)[reply]
Tracked in Phabricator
Task T50402
See related about renames: #Relinking Google for SSL https.

When editing via https, secure-server protocol, I do not see rel="canonical" inside the generated HTML markup. For example with "https:../Catenary" then I was expecting to look inside the HTML and see a line as:

So, anyway, when I edit those pages linked by Google with https-protocol, they do not re-index in Google (even after days), as compared to typical http-prefix pages in Google which re-index within minutes of an edit-save. Meanwhile, more articles are falling into Google's https-prefix abyss (such as recent page "Hyperbola" and now this week "Catenary" have Google https), where the https-protocol views are not counted by stats.grok.se, and any edits to those Google https-prefix pages no longer update the Google search-results blurbs. There are more than 600 Wikipedia pages/images linked in Google by https-protocol links (see essay: "wp:Google https links"). Anyway, since I cannot insert the canonical link-tag directly, as <link rel="canonical" href="http://en.wikipedia.org/wiki/Catenary">, does anyone know a template or parser function which can set a link as rel="canonical" so I can edit-save the page to connect the https and http versions within Google? -Wikid77 (talk) 19:51, 12 May 2013 (UTC)[reply]

Hmm, this is weird. I don't think we ever did it like this. Perhaps the google implementation changed ? They do list this as a requirement it seems. Canonicalness should be defined in MediaWiki core, so I filed a ticket, there is no and should be no user option for this. —TheDJ (talk • contribs) 13:16, 13 May 2013 (UTC)[reply]
  • Link-tags for "canonical" are inside en.m.wikipedia HTML pages: Thanks for checking this issue, as I had seen such link-tags (with rel="canonical") inside each mobile-site page's generated HTML markup (such as inside the HTML for https://en.m.wikipedia.org/wiki/Catenary). Hence, I expected any "https:" article's HTML markup to directly contain the link-tag, but if Google spiders can read the "canonical" setting from the MediaWiki core, then perhaps that should work. At this point, I have been able to rename pages to drop the https-protocol links in Google, but if the "canonical" setting can be directly applied, then Google should reset each "https:" to "http:" within a few days. -Wikid77 (talk) 05:36, 14 May 2013 (UTC)[reply]

Huggle Issues

Firstly, I know the disclaimer on Huggle, that is to say, every edit I make I am equally responsible for as if I had typed it into the edit window, etc. With that in mind, what the hell happened here? I instructed Huggle to make a normal revert-and-warn, and onlly found out this had happened when echo told me Lugia2453 had reverted me. Secondly, has this been reported in the past? I checked the HG feedback page, but it seems kind of inactive.--Gilderien Chat|List of good deeds 21:11, 12 May 2013 (UTC)[reply]

Editing Bar: Citation Templates not working

I keep clicking on any of the Cite templates in the editing bar ("cite web", "cite newspaper", etc.), but nothing at all happens. All of the other editing-bar buttons are working but the Cite Templates are not working at all.

Google Chrome 26 (also IE8); Win 7

Softlavender (talk) 03:40, 13 May 2013 (UTC)[reply]

Works fine here. Firefox 20.0.1, Windows 8. Are you getting any JavaScript errors (see WP:JSERROR)? jcgoble3 (talk) 04:01, 13 May 2013 (UTC)[reply]
No. Softlavender (talk) 04:34, 13 May 2013 (UTC)[reply]
Also works for me in Chrome 26.0.1410.64 m and IE 10. I don't know what the problem could be. jcgoble3 (talk) 04:42, 13 May 2013 (UTC)[reply]
I already replied to this person who requested help using the {{help}} template. They were given the option of also using the {{cite web}} and {{cite news}} templates manually but they didn't seem interested in that response or the idea that it was likely a problem on their localized computer. Mkdwtalk 04:52, 13 May 2013 (UTC)[reply]
Mkdw, my question was not how to use the {{cite web}} and {{cite news}} templates manually. I already know how to do that. My problem is that the templates don't appear when I click them on the Cite Templates drop-down menu of the editing bar. Softlavender (talk)
Yes I was fully aware of that. I never offered you advice about that. I informed you that while trying to use the tool bar in your browser that it was working for a number of people so asking for help on it was likely an issue with your computer and not Wikipedia. I suggested you reinstall your browser. Mkdwtalk 05:01, 13 May 2013 (UTC)[reply]
Jcgoble3, I looked at the page you linked and it doesn't make any sense to me. Plus I am not using any gadgets, I'm just using the Wikipedia editing bar; it doesn't give any error messages -- the templates just don't appear when I click the names for them. Softlavender (talk) 04:53, 13 May 2013 (UTC)[reply]

Despite your really rude response to me when I was trying to help you, I still want to if you're willing to politely discuss this further. I know it's frustrating but an unwillingness to talk it out with those helping is not going to help.

This is what happens for me when I click it btw. Mkdwtalk 04:56, 13 May 2013 (UTC)[reply]

File:Insert ref toolbar example.png
My editing bar is a completely different layout than your image -- different look, different buttons, nothing like that. Softlavender (talk) 05:14, 13 May 2013 (UTC)[reply]
It's just a different skin. The function works the same. Does yours look like the one below? Mkdwtalk 05:15, 13 May 2013 (UTC)[reply]
It's not just a different skin. The top image is the Advanced editing bar (which works fine for me). The bottom image is the standard editing bar. I could not get the standard editing bar's citation templates to work when I clicked on their names in the Cite Template drop-down menu. Nothing happened. Although now that I selected Advanced edit bar in my preferences, and then went back and unselected it, the standard toolbar's Citation Templates work again, but it has a completely different interface than it did before, and no longer has a drop-down menu for the citation templates (as in your bottom image), but rather radio buttons instead. In any case, unselecting and then re-selecting seems to have updated and fixed it. Softlavender (talk) 05:39, 13 May 2013 (UTC)[reply]

This is likely my fault. I made some changes recently that appear to have broken something. I have reverted them. I can't reproduce the problem on my end so I'm not sure why it occurs. By clearing your browser's cache and it should work again. Jason Quinn (talk) 06:53, 13 May 2013 (UTC)[reply]

The thing under question is called the WP:Reftoolbar. There are actually 3 different version depending on your preferences. My changes ought to only have affected Reftoolbar 2.0b (the one with dialogs). Jason Quinn (talk) 07:05, 13 May 2013 (UTC)[reply]
As I mentioned above, it's working OK from me now, at least on Google Chrome. The standard editing bar is still not working however on IE8 -- I click the Citation icon and nothing at all happens. Clearing cache doesn't change anything -- that's the first thing I tried. Also, why does the so-called "Advanced" editing bar have much fewer options on the citation templates than the standard edit bar does? The standard edit bar lets one preview a citation, add the title of a newspaper, and so forth. The standard edit bar is much more advanced than the "Advanced" edit bar. Softlavender (talk) 07:26, 13 May 2013 (UTC)[reply]
There was another person that reported an issue on my talk page, so you weren't the only one that experienced problems. I figure it's best to revert until I know exactly what's going on. It still may have just been a cache issue: clearing the cache is always a quirky thing and sometimes it just doesn't seem to do it until it finally does. Some browsers are better at it than others. The "advanced" toolbar is actually WikiEditor. The Reftoolbar is actually a misnomer: it should be called something like "CiteButton" because it just adds a button, not a toolbar. The Reftoolbar 1.0 (the "old" or legacy version) is still quite nice; it just looks "web 1.0". The 2.0 versions (the "enhanced" versions) are about equivalent in function. They just look a bit cooler. There are minor pros and cons to each version. I think of 2.0b (the dialog based one) as the most important because it's the default for new users. I've been curious how many people actually use each version. I agree with you that the whole thing is somewhat confusing. Jason Quinn (talk) 08:09, 13 May 2013 (UTC)[reply]

Message notification anomaly

Tracked in Phabricator
Task T49912

The new user talk page message notification is buggy. When a new message is placed on my talk page a red number '1' appears in a tiny box after my username at the top of the given page I am visiting or working on. After I go to my talk page to view the new message, the red '1' appears again when I go to a new page, and again and again, in some cases. This doesn't always happen, but it happens often. What was wrong with the old message notification using an orange colored banner? It couldn't be overlooked and it worked like a charm. Doesn't anyone do beta testing before they try to re-invent a new 'mouse trap' for WP? Would someone kindly bring this to the attention to the individual(s) responsible and maybe advise them to not re-invent (or "improve" on) things unless there is a real need to do so? -- Gwillhickers (talk) 03:52, 13 May 2013 (UTC)[reply]

If you click on the red box, it should show details about the notification (and a list of old notifications), and should then disappear. Inkbug (talk) 07:40, 13 May 2013 (UTC)[reply]
Known issue, I added the relevant bugreport on this for you. —TheDJ (talk • contribs) 12:37, 13 May 2013 (UTC)[reply]
  • Inkbug, I have also clicked on the red box and still experience the same problem. As with the original message notification, it should simply stop appearing by going to your user talk page. I am still experiencing this problem as I write. -- Gwillhickers (talk) 18:07, 13 May 2013 (UTC)[reply]
But you can only see it if Preferences → Pending changes → Enable tracking bugs on Bugzilla using the {{tracked}} template --  Gadget850 talk 01:40, 14 May 2013 (UTC)[reply]
@Gadget850: Everyone can see the floating box with the raw bug number. The gadget to which you refer only replaces the bug number with the title and status of the bug. jcgoble3 (talk) 01:48, 14 May 2013 (UTC)[reply]
What are the chances of bringing back the original message notification w/ the orange banner? Again, it was impossible to overlook, as I have done with this tiny red box. We don't need to see a list of messages (last msg, first) as they appear in that order at the bottom of our talk page -- and there is edit history. Seems like someone is going through a lot of trouble to reinvent the wheel. -- A fifth wheel no less. -- Gwillhickers (talk) 02:53, 14 May 2013 (UTC)[reply]

red box message indicator

I see they have added a small orange banner next to the tiny red box that appears when a new message is added to your talk page, and when you go there the orange banner no longer is displayed when you exit and go to other pages. However, that red box still appears until you click on it too. And clicking on it doesn't take you to your talk page. You now have to select a message from a list. Btw, I tried logging in at bugzilla to report this, but apparently your normal username/password won't work. -- Gwillhickers (talk) 23:07, 14 May 2013 (UTC)[reply]

Another little annoying quirk of Vector I've noticed since the demise of Classic skin: external links all seem to have a little icon after them (a small box with an arrow pointing NE). Is there a css tweak I can use to disable this? An optimist on the run!   07:56, 13 May 2013 (UTC)[reply]

It's not specific to Vector, but was already in Monobook at least a year before Vector was deployed. The icon is injected by site-wide Javascript, but the following in Special:Mypage/common.css or Special:Mypage/skin.css should suppress it:
a.external {
  background:none !important;
  padding: 0px !important;
}
Alternatively, it may be switched off for all users on a per-link basis by applying class=plainlinks as in <span class=plainlinks>[http://www.example.com/ Example]</span> → Example --Redrose64 (talk) 08:40, 13 May 2013 (UTC)[reply]
Thanks. An optimist on the run!   09:18, 13 May 2013 (UTC)[reply]
Appropriately documented at Help:External link icons. --  Gadget850 talk 01:28, 14 May 2013 (UTC)[reply]
The plainlinks class is indeed documented at Help:External link icons#Classes, but the advice at Help:External link icons#Custom link icons, if followed, only removes one specific type of icon - in the example given it's the padlock shown against anything beginning https:// - and when so doing it leaves a blank space where the icon would have been. My suggestion is not specific to one type of link; it eliminates that gap; and is shorter. It could be shorter still; per CSS 2.1 syntax, para 2 "After a zero length, the unit identifier is optional.", so on the third line I could have put 0 instead of 0px. --Redrose64 (talk) 08:43, 14 May 2013 (UTC)[reply]

Wikipedia:Articles for deletion

Is there any good reason why May 4 page is not currently shown on this page? Both May 3 and May 5 are shown, and May 4 has open nominations at the time I am writing this.--Ymblanter (talk) 08:02, 13 May 2013 (UTC)[reply]

Wikipedia:Articles for deletion/Log/2013 May 4 has open AFDs, but isn't appearing in Wikipedia:Articles for deletion/Old. This subpage is normally maintained by Mathbot (talk · contribs); unfortunately, that bot needs Toolserver to run correctly. --Redrose64 (talk) 08:16, 13 May 2013 (UTC)[reply]
I see, thanks. Can it be done manually? I would do it, but I am afraid to break smth.--Ymblanter (talk) 08:34, 13 May 2013 (UTC)[reply]
 Done I looked at how the 5 May entry was laid out, then did a manual construction of the missing entry. --Redrose64 (talk) 08:56, 13 May 2013 (UTC)[reply]
Thank you.--Ymblanter (talk) 09:14, 13 May 2013 (UTC)[reply]

VisualEditor fortnightly update - 2013-05-13 (MW 1.22wmf4)

Hey all,

Here is a copy of the regular (every fortnight) update for the VisualEditor project, so that you all know what is happening (and make sure you have as much opportunity to tell us when we're wrong, as well as help guide the priorities for development and improvement):

VisualEditor was updated as part of the wider MediaWiki 1.22wmf4 branch deployment on Monday 13 May. In the two weeks since 1.22wmf3, the team have worked on the new features for VisualEditor's beta launch as the default way users will edit our wikis: Categories, Templates, References and Images.

The VisualEditor now lets users edit the contents of <div> blocks (47907) as if they were normal mark-up - though not the blocks themselves, such as setting arbitrary CSS, which will come later. Work on enabling the editing of categories is almost finished with the addition of a way of setting {{DEFAULTSORT}} in the interface (46465), and support for moving, altering and inserting new images and references is also improving rapidly. Progress on template editing is at an earlier stage, with core back-end support mostly finished at this point.

We made quite a few changes to the MediaWiki integration layer. Most obviously, we now use SVGs rather than PNGs for the graphical elements of the interface, so it scales nicely for users who zoom in (48148). The "Edit source" tab now appropriate becomes active when it is being used (47452), appears on all pages, not just view (47776), and the "Edit" (VE) tab now points to the newly-updated page once you've made an edit (47420). The Vector drop-down menu's change behaviour no longer hides it behind the VisualEditor toolbar (48078)

We improved some issues with the Opera browser (47772) and now warn logged-out users appropriately about the consequences of their editing (47842). Pre-save diffs now give a more reasonable message when there are no changes to be made (43754), and now work when the diff is aborted and restarted (44446). Pages that are not wikitext content (such as user CSS or JS items) will now not trigger VisualEditor (47456). We added a new access key for accessing VisualEditor - Ctrl+Alt+v/Ctrl+⌥ Option+v - restoring the regular edit access key to the wikitext editor (48107).

We also made a number of fixes for RTL environments. First, the link inspector now works for RTL environments, but allows LTR content for Web links (47717). For multi-script variant wikis, content displayed with one variant whilst the user's interface is in a second now works correctly (33175). Un-editable blocks ("aliens") now appear in RTL environments correctly (47746). Finally, the "Edit" (VE) tab now appears down-tab rather than up-tab of the "Edit Source" tab (48017).

On the integration with Parsoid, we cleaned up a number of items of code including removing change markers (45061), and fixed some problems with trailing whitespace on paragraphs and table cells being dropped (47712). Content with different names for the same annotation now serialises to the same wikitext (48110), and serialisation of data with DOM elements is now fixed (47948).

Finally, we fixed a number of other bugs, including ugly issues with pawn characters being created in list and paragraph editing (48287, 48286, 47817, and 48346), with indenting and outdenting of multiple list items (48390), and with splitting list items (48386). Categories that appear in sub-sub-pages don't get corrupted when the page is being edited (48408), and in Firefox, we fixed editing a page causing the entire editor to go blank (47834) and non-character keys being interpreted as real ones (48022). Trying to set a link covering the first character of the document no longer causes VisualEditor to crash (47623), and links now don't wrongly appear to extend when you type after them (48171 and 48114).

A complete list of individual code commits is available in the 1.22/wmf4 changelog, and all Bugzilla bugs closed in this period on Bugzilla's list.

Per the MediaWiki deployment roadmap, this should be deployed here on Monday 20 May.

Hope this is helpful! As always, feedback gratefully received, either here or on the enwiki-specific feedback page.

Jdforrester (WMF) (talk) 02:40, 14 May 2013 (UTC)[reply]

Transwiki process

Hi there. Way back in October I nominated A leopard doesn't change its spots for deletion, and the result of the discussion was transwiki to Wiktionary. The problem is that the transwiki tag (This page will be copied to Wiktionary using the automated transwiki process) has been on the article ever since, and no transwiki has taken place. Is the automated transwiki still yet to happen, or has there been an error? I'm afraid I don't really know anything about transwiki. Thanks! — Richard BB 08:10, 14 May 2013 (UTC)[reply]

Transwikis are not automatic: the article can only be imported by Wiktionary admins. Also, there is already an article wikt:a leopard cannot change its spots. You should ask over there for further information. Darkdadaah (talk) 08:39, 14 May 2013 (UTC)[reply]
Oh right, thanks. The tag threw me as it said it was an automated process. Thanks for your help. — Richard BB 08:46, 14 May 2013 (UTC)[reply]
That is misleading, yes. The importation of the page and its history from one project to another is automated (thanks to the import feature), but the process has to be executed by someone on the target wiki. I deleted automated from the template. Darkdadaah (talk) 13:50, 14 May 2013 (UTC)[reply]

Is it possible to pass {{N/a}} from a template?

I'm trying to develop a template to automate the calculations on the page List of minimum wages by country. One of the calculations I do requires knowing the exchange rate between that country's currency and US Dollars, which is not always available. I'd like to display N/A in the table when this is the case, but I'm having difficulties. I boiled the problem down to this: it seems passing {{N/a}} through an intermediate template to the article's main table corrupts the formatting. See Debugging nested N/A for a simplified example. Is there any way to allow this kind of template passing, or will I have to get the "outer template" to recognize when it needs an N/A and send it directly? I'd like to avoid this second case if possible because it will clutter the high-level template with a bunch of ugly and confusing implementation details. --Greenbreen (talk) 14:40, 14 May 2013 (UTC)[reply]

This minimal example is really minimalistic (actually I'm not quite sure if I understand correctly what it should do) . However I did a small change to User:Greenbreen/TemplateInner (remove the line breaks) which at least fixes the table in User:Greenbreen/Sandbox. Tell me if this was the problem you were talking about and if my changes fixed it. --Patrick87 (talk) 15:32, 14 May 2013 (UTC)[reply]
That did it! Thanks very much for your help. --Greenbreen (talk) 16:01, 14 May 2013 (UTC)[reply]

Echo / Orange bar of doom status update

As of today, the Echo notification extension includes it's own talk page message alert. You should see this as an orange highlight around the Talk page link which changes to say "Talk: You have new messages" whenever a change has been made to your talk page. If you want to turn this alert off, go to your notification preferences and uncheck the box at the bottom. If you want to enable an alert similar to the old "Orange bar of doom", go to the gadget preferences and turn on the "Display a floating alert when I have new talk page messages" option there. There are also a few user scripts, such as User:Writ Keeper/Scripts/orangeBar.js, that do similar things. If you would like to discuss these features, or any other aspects of the notification system, please come to Wikipedia talk:Notifications. Kaldari (talk) 20:26, 14 May 2013 (UTC)[reply]

THANK YOU +1+1+1+1+1+1+infinity SarahStierch (talk) 21:33, 14 May 2013 (UTC)[reply]
This is still arse-about-face; the opportunity for experienced editors to configure their settings is welcome, but the old-style orange bar should not have been replaced (and should have been be restored) until there is something equally prominent to allow us to grab the attention of new editors. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:05, 14 May 2013 (UTC)[reply]
Thanks Kaldari! Nicely done. Ocaasi t | c 01:33, 15 May 2013 (UTC)[reply]

Complex categories

Is there a way to see, in a single view, the hierarchy organization of a specific category and its subcategories? There is a category that needs order, but going from main category to subcategories, to sub-subcategories and back, it's easy to get lost, and I may end up making things even more complicated than if I had the full picture at sight. Cambalachero (talk) 12:02, 15 May 2013 (UTC)[reply]

Try {{Category tree}}. -- John of Reading (talk) 12:13, 15 May 2013 (UTC)[reply]
Any category page which has subcats will list these at the top, and to the left of each one there should be a grey or blue triangle. These indicate whether the subcategory has subcats of its own: grey means no, blue means yes; and the blue ones are clickable. When you see a blue triangle pointing right, click it: the triangle turns to point down, and the subcat expands to show its members, which are also marked with grey or blue triangles. You can take this ad infinitum. --Redrose64 (talk) 13:41, 15 May 2013 (UTC)[reply]

Help:Job queue page up for deletion

Help:Job queue has been nominated for deletion by a new IP 151.230.23.170. — Maile (talk) 13:10, 15 May 2013 (UTC)[reply]

They didn't make a page or give a reason. I've just reverted as vandalism. Secretlondon (talk) 13:14, 15 May 2013 (UTC)[reply]
That IP has a history of vandalism and blocks. — Maile (talk) 13:25, 15 May 2013 (UTC)[reply]

extending template:unicode

Could someone please integrate the development at User:ChristTrekker/UnicodeSymbol into template:unicode? (This requires additions to mediawiki:common.css too.) The work's been done for several months, and it's been discussed about as much as I think it's going to be. Consensus seems to be that it's a good idea. It's just languishing now. ⇔ ChristTrekker 15:56, 15 May 2013 (UTC)[reply]

Embedding musical notation?

I am trying to replace the image at Time signature with the following <score>: . However, I cannot get it to embed properly in the Frame; is there markup for this, so that the text around it still appear in the same place, etc.? Thanks. It Is Me Here t / c 16:46, 15 May 2013 (UTC)[reply]

What do you mean by frame? --  Gadget850 talk 17:45, 15 May 2013 (UTC)[reply]
{ \key c \major \time 3/4 \relative c'' { a f c \bar "|" \hideNotes a \unHideNotes \bar "" } }
  • Avoid using score-tag for common examples: Try to retain typical images for common examples of musical notation, with the alt-text set for sight-impaired (or music-impaired) readers. Currently, the suggested score-tag (see image at right) gives alt=" { \key c \major \time 3/4 \relative c'' { a f c \bar "|" \hideNotes a \unHideNotes \bar "" } } " as the alt-text explanation for the example of printed music. Instead, the image should have "alt=Printed music staff with treble-clef symbol, 3/4 time signature, and 3 quarter notes: A, F, and middle C" or similar. Also, we recently had severe problems with caching of generated images for math-tag formulas, which ran a horrific 105x times slower than showing simple math symbols. Try to "Keep it simple" when writing articles and avoid using templates, math-tags or score-tags when there is a 10x-simpler alternative. Thanks for helping. -Wikid77 (talk) 17:23, 15 May 2013 (UTC)[reply]
{ \key c \major \time 3/4 \relative c'' { a f c \bar "|" \hideNotes a \unHideNotes \bar "" } }
Caption comes here.

can contain links, other templates,

newlines etc.
i do not think the advice given by Wikid77 is a good one. we should use tags "score" and "math" wherever it makes sense to use them, and the developers should (and will) solve performance-related issues. as to the OP: i think what you are looking for is template {{Image frame}}, like so:
{{Image frame
|align=right
|content=
<score> 
{ \key c \major \time 3/4 \relative c'' { a f c \bar "|" \hideNotes a \unHideNotes \bar "" } }
</score>
|caption=
   Caption comes here.<br />
   can contain links, <br />
   other templates, newlines etc.
}}

peace - קיפודנחש (aka kipod) (talk) 18:47, 15 May 2013 (UTC)[reply]

Search and replace regular expression option

I've been experimenting with the regular expression option in the advanced drop down of the edit window and I keep bumping into problems. When I try to do a lookaround I can match the thing I'm looking for but I can't seem to replace it.

For example, in here I can track the placings from 1st to 3rd with "\d (?=\w)", but replace does nothing (even though it tells me 123 replacements are done!). I get a quantifier error when trying to use lookbehind (?<!X) too.

I might just be completely noobing it (I've only just started playing with regex patterns), but I'm a bit lost. Why isn't this working? And, more importantly, why is there no documentation for this tool? SFB 17:45, 15 May 2013 (UTC)[reply]

Special:Nearby lets you see all the Wikipedia articles around you

Hi folks,

Wanted to let you know that there's a neat new feature out on Wikipedia – articles nearby! Anyone on a compatible device (mobile or laptop/desktop device that supports JavaScript and location data) can visit Special:Nearby and see a list of the Wikipedia articles that are near them. This feature relies on the GeoData extension and API, so if you know of an article around you that doesn't show up on the list, consider adding {{Coord}} to it :)

Nearby was originally built for the mobile site, since users on camera phones are able to take a picture of things near them that are missing lead images (designated by the little blue camera icon) and upload to Commons + add a thumbnail to the top of the article in one easy step via the Wikipedia mobile site. But we figured it would be useful for non-mobile users, too :) There's currently one known bug (clicking the search box after loading the page causes some mobile code to leak in and disrupt the experience a bit) but we've got a fix and should have that taken care of soon. Take a look and let us know what you think! Maryana (WMF) (talk) 19:17, 15 May 2013 (UTC)[reply]

It's great to finally see this truly integrated. Points to the mobile team for building our very own geo database. —TheDJ (talk • contribs) 19:34, 15 May 2013 (UTC)[reply]

Announcing the English Wikipedia Flow Portal

Hello!

As many of you know, the Wikimedia Foundation is now actively engaged in designing a next-generation discussion and workflow system called Flow, initially slated to replace user talk pages. Flow is an ambitious project (on par with the VisualEditor) and will touch nearly every aspect of the Wikimedia experience.

We need your help and input. We have started a portal for information and discussion. You can find it at WP:Flow on the English Wikipedia and at Flow Portal on mediawiki.org (we'll also be opening a discussion on meta as well). At the Flow portal, you can read about what we're doi ng and why, as well as play around with an interactive prototype.

We're desperately interested in your feedback and thoughts. There are things that we know, and things that we know that we don't know. But there are also things that we don't know that we don't know. And we want to reduce that lack of knowledge.

We will also be conducting additional office hours for a variety of timezones - as many as we need to - and will also be open to having conversations via Google hangouts and/or Skype as need be. I am always around on irc (freenode, username "jorm") and am willing to answer any questions you may have.--Jorm (WMF) (talk) 20:15, 15 May 2013 (UTC)[reply]

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