Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Smallman12q (talk | contribs) at 21:28, 10 May 2013 (→‎Wayback Machine snapshots: re). 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, 215


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]

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]

Echo

Modern skin and Echo

I made some local CSS changes to the Modern skin, so that these users get a bit better Echo experience. If ppl report issues with Modern skin not relating to Echo in the coming hours, this might be a candidate for reverting. —TheDJ (talk • contribs) 22:35, 1 May 2013 (UTC)[reply]

Orange message bar

Where did the orange message bar go? All I get now is this little blue number in the upper right corner. Prettier, certainly, but far less effective. The orange bar was ugly as sin, but there's no way a new editor could claim he didn't know he had a message.—Kww(talk) 06:08, 2 May 2013 (UTC)[reply]

Just found Wikipedia talk:Notifications. I really don't understand how things like this just show up one day. How could anyone think making it difficult for a new editor to realize he's about to be blocked was a good idea?—Kww(talk) 06:20, 2 May 2013 (UTC)[reply]
It's gone. Choyoołʼįįhí:Seb az86556 > haneʼ 06:21, 2 May 2013 (UTC)[reply]
  • 👍 LikeI actually quite like the powerful new functionality. Now a message on our talk page will give rise to a notification, ditto if someone reverts a change we make somewhere, and if you are mentioned on the talk page of another. There may be others which I have not yet discivered, but what's there is good. The little red blob with a number on it is discrete yet instantly noticeable, and will be more so once we get used to it. -- Ohconfucius ping / poke 06:31, 2 May 2013 (UTC)[reply]
I'll chime in with general support. Unfortunately, one of my first notifications was a revert, by an IP, of a recent edit. Embarrassingly, a good revert, but while it was on my watch list, my watch list is out of control, and I might not have seen it otherwise. Not opposed to restoring the orange bar, though.--SPhilbrick(Talk) 13:14, 2 May 2013 (UTC)[reply]
This appears to be a case of registered editors' preferences being put first, when there were very good reasons for not doing so. I'm certain that a comfortable majority of established editors would like to use the new implementation, indeed I would myself. But communication between all types of editor is essential, and the orange bar is without question easiest way of making sure that someone receives a message in good time (assuming they're logged in, of course). This is particularly true of newly registered and IP editors, but doesn't exclusively apply to them. In my experience established editors like to get rid of the orange bar as quickly as possible, and I doubt the same will apply to the relatively discrete number in the top corner. —WFC— FL wishlist 05:47, 3 May 2013 (UTC)[reply]

There is a new gadget (basically a copy-paste of Writ Keeper's script, except for a bit saying to get familiar with Notifications and a link to the doc page that has instructions to turn it off) has been created. Being a gadget, it is fully opt-out-able. The script can be reviewed at MediaWiki:Gadget-OBoD.js. It was ON by default, so new users would see it, but Edokter raised concerns about that. Should it be default-on? Comment at WT:Notifications#Pseudo OBOD Gadget is live. Ignatzmice•talk 19:50, 4 May 2013 (UTC)[reply]

There are far too many discussions going on in far too many places at this point. Can we just create a separate page to talk about the Orange Bar and related RFCs? Surely we can copy/paste all the current text to that and point links in all these pages / threads to that page. Now we have two gadgets for this, as well? (This is my understanding.) Killiondude (talk) 20:29, 4 May 2013 (UTC)[reply]
  • Comment The 'official' discussion is at Wikipedia talk:Notifications (and THEY do seem to be listening to us), but the briefly turned on replacement has been slated for review here. Someone decided that a 107 to 19 consensus wasn't enough, or that the gadget was untested and needed reviewing over here. Peridon (talk) 20:55, 4 May 2013 (UTC)[reply]
    • I am not disputing the outcome of the RFC; just the way the code is deployed. Gadgets are subject to review, especially if they are going to be turned on be default. I could find no technical review, do I disabled the [default]. — Edokter (talk) — 21:06, 4 May 2013 (UTC)[reply]
    • It is urgent to restore a means of communicating with newbies. The WMF refuse to restore the "proper" orange bar, and are talking of the week after next for their solution. Please let us not start another discussion here: comment at WT:Notifications#On by default? JohnCD (talk) 21:17, 4 May 2013 (UTC)[reply]
I just got a message about vandalism on a library computer before signing in. So all is well, apparently.— Vchimpanzee · talk · contributions · 20:09, 8 May 2013 (UTC)[reply]

Notifications gadget's z-index

Tracked in Phabricator
Task T50078

Notifications gadget doesn't appear properly because z-index is same like the editor toolbar - 100. --Rezonansowy (talk) 12:01, 6 May 2013 (UTC)[reply]

I suspect you use the Visual Editor toolbar. I have already file a bug. — Edokter (talk) — 12:16, 6 May 2013 (UTC)[reply]

Gadget review please

I'd like some technical review for Mediawiki:Gadget-Notification.js and Mediawiki:Gadget-Notification.css for the potential event that it may be enabled by default. It's basically two lines of JavaScript, so I don't expect any problems. This may put a stop to a very large discussion at Wikipedia talk:Notifications. The gadget is intended to be active until the WMF team has decided on a solution for a new message indicator discussed at Wikipedia:Notifications/New message indicator‎. — Edokter (talk) — 15:11, 6 May 2013 (UTC)[reply]

Note: Screenshot here, if anyone cares to know. Ignatzmice•talk 15:15, 6 May 2013 (UTC)[reply]

Temporary notification system

I am going to enable a default gadget that will pop up when you receive a notification. I do this because there is a valid concern new editors may not notice the standard red blip on top of the screen. While there is consensus that some form of notification alert is needed, the current discussion at Wikipedia talk:Notifications/New message indicator is going downhill fast.

For more information, see Wikipedia:Notifications/Popup documentation. — Edokter (talk) — 00:30, 7 May 2013 (UTC)[reply]

Hi @Edokter: now that this gadget is being served to all new editors, and they're seeing it almost immediately after signup due to the welcome notification, I wanted to run a quick remote usability test to see if there are any glaring successes or problems we should investigate further. (The WMF has a usertesting.com account which we use for this sort of thing regularly.) I ran just two initial tests to make sure our test instructions made sense, and here are the relevant clips regarding the popup...
  • Clip A
  • Clip B
As you can tell, the good news is that the popup helped them see that they had notifications, and after that they successfully clicked the number indicator and opened their notifications. The bad news is that they both were confused by the red in the popup, and thought it indicated there was an error or problem, rather than a neutral notification. I think this supports the suggestion I made earlier, which was removing the red background. Of course Fabrice's team or someone still needs to run a larger experiment to get an objective look at clickthrough rates for various options on the table, but this is why we also do usability tests: more clicks are not always better, if new editors end up confused or irritated.
If you'd be interested in running another pair of usability tests to see if users react differently, let me know. Last but not least: the testers pick us, we don't pick them individually, but the person in Clip A said he had several thousand edits prior to the test, which is slightly unusual for usertesting as a site. Steven Walling (WMF) • talk 05:38, 7 May 2013 (UTC)[reply]
That is good feedback. I may test another design, it will have some red, as it matches the badge. User A expected orange, which only experienced editor would. I may also file a bug report on how to improve mw.notify, as it is quite inflexible; there is an option to make it persistent, but I can't set a custom timeout. — Edokter (talk) — 09:51, 7 May 2013 (UTC)[reply]
Toned it down for now. I have to go out for a few hours, will complete it tonight. — Edokter (talk) — 10:18, 7 May 2013 (UTC)[reply]
The relevant bug on mw.notify is 40307. Agreed about orange, that's why I pointed out he was an experienced editor. Steven Walling (WMF) • talk 19:20, 7 May 2013 (UTC)[reply]

You have new messages

I didn't see the orange bar that says I have new messages. I did happen to see a 1 that I had never seen before to the right of my name at the top of the page. I clicked and was told I have new messages. I like the old way better.— Vchimpanzee · talk · contributions · 19:56, 7 May 2013 (UTC)[reply]

Well, if you really want the OBoD in all its glory back, I made a script when this was first released to restore it: you can install the script by going to your common.js page and pasting in the following line: 
importScript("User:Writ Keeper/Scripts/orangeBar.js");
. Thanks to a change Kaldari made yesterday (and forgot to tell me about, coincidentally; I had to stumble across it myself earlier today), it should be nearly identical to the way it was before; it just takes slightly longer to appear than it used to. Writ Keeper ⚇♔ 20:32, 7 May 2013 (UTC)[reply]
Thank you. I got worried when I couldn't find my question but see others have been concerned about the same thing.— Vchimpanzee · talk · contributions · 20:47, 7 May 2013 (UTC)[reply]
And I just found what I needed in the Help Desk archives. If I had been a little more patient ...— Vchimpanzee · talk · contributions · 21:18, 7 May 2013 (UTC)[reply]

Notifications popups

Hi, where was the consensus for this, and most especially for enabling it by default? -— Isarra ༆ 18:08, 8 May 2013 (UTC)[reply]

It was done at the Foundation level, not through any community based process. Beeblebrox (talk) 18:48, 8 May 2013 (UTC)[reply]
No, I don't think it was; I think that was User:Edokter doin' his thing. Not sure where he claimed consensus, though it may (or may not) have been an IAR-type thing to bridge the gap before the WMF response. Writ Keeper ⚇♔ 18:51, 8 May 2013 (UTC)[reply]
That was Edokter (and me, and a couple other people maybe) just trying to get something together in light of all the concerns raised about newbies not noticing the small little box. I don't think IAR was ever specifically cited, but that was the general mindset. It's meant to be temporary, until the WMF comes out with something better. Ignatzmice•talk 18:54, 8 May 2013 (UTC)[reply]
(ec) If anything, I claimed a complete lack of consensus between the community and the WMF. Recognizing the immediate concern raised by the community, I stepped in and made the popup as a temporary measure. Haven't had complaints so far. — Edokter (talk) — 18:56, 8 May 2013 (UTC)[reply]
Consider this a complaint, then. Such things require consensus, and your change attempts to resolve poor design in one regard - a lack of noticeability or indication what the number actually is - with even worse in another - a very annoying popup that does not stay gone when dismissed, that still does not do anything to say what the notification is (or even what a 'notification' is in general), and that has little affordance to connect it to what it is even referring to due to its visual and spacial separation from the p-personal toolbar. This is not a good change, and indeed a good example of why we operate on a consensus- and review-based model, so please revert this at once if it is still live. -— Isarra ༆ 22:14, 8 May 2013 (UTC)[reply]
Why should it stay gone when dismissed? The whole point is to let editors (new editors especially) know that something important has happened. If people don't want it, there's a link there do the documentation page explaining how to turn it off. Ignatzmice•talk 22:28, 8 May 2013 (UTC)[reply]
Actually, there was an overwhelming consensus to reinstate the orange bar, but that proved problematic in that the proposed solution was untested. So I created one that was based on an existing framework thus not prone to bugs. I also reiterate that it is a temporary solution. I just came from IRC on a collaborative meeting where we agreed on a new notification system that will hopefully meet the approval of the community. Until then, the red popup only takes one click in your prefereces to disable. — Edokter (talk) — 22:30, 8 May 2013 (UTC)[reply]

Hey Edokter. I appreciate the work you've been doing trying to design something to meet community requests, but considering that there are now gadgets being tested to meet this need, can we consider turning off the red popup as default? (I don't mean removing it entirely.) The new gadgets by Kaldari still need design work I'm sure, but they already do more advanced behavior like only appear on Talk messages, so they work as orange bar replacements for editors that want them. I am also asking because in about an hour, my team is launching a controlled test of a new version of Wikipedia:GettingStarted, and the red popup is likely to have a negative effect on our test results. This is because it fires immediately after you sign up, due to the welcome notification. Steven Walling (WMF) • talk 19:02, 9 May 2013 (UTC)[reply]

Hi Steven. That does create the situation that prompted the red popup in the first place, namely that new editors don't immediately see that they have messages. Would it be OK to have the F2 gadget replace it as a default gadget? — Edokter (talk) — 19:08, 9 May 2013 (UTC)[reply]
Can't wait for a reply now. I'll check back in 45 minutes. — Edokter (talk) — 19:28, 9 May 2013 (UTC)[reply]
As a side question: is there a list of vars like mw.echo.overlay.notificationCount that allow my to filter talk page messages? — Edokter (talk) — 19:17, 9 May 2013 (UTC)[reply]
@Edokter: I think the F2 gadget as default would be fine, as an interim solution. Steven Walling (WMF) • talk 19:37, 9 May 2013 (UTC)[reply]
I don't know about ones that tie into Echo or mention a notification count, but if you're just looking for whether there's a new talk page message or not, Kaldari put in a new variable called "wgUserNewMsgRevisionId" that has the revid of the earliest unread edit on one's talk page, or null if there aren't any, which is cleared once a user goes to their talk page. I've already switched my OBoD script over to using it (which, as a consequence, no longer uses any API calls and is now quite simple and compatible with any browser/skin, I believe). Writ Keeper ⚇♔ 19:42, 9 May 2013 (UTC)[reply]
Okay, until we figure this out and pending some other small todos my team has, we're just going to hold off on launching our A/B test of the new GettingStarted. That will give us a week to let everyone figure out what's the state of notifications. Steven Walling (WMF) • talk 20:14, 9 May 2013 (UTC)[reply]
@Steven (WMF): I'm OK with switching to F2. That will give us a chance to measure the community reaction. — Edokter (talk) — 20:24, 9 May 2013 (UTC)[reply]
If folks want to un-default the Notifications gadgets and make F2 on by default, I'm fine with that. I went ahead and disabled the animation for now, since it's a bit janky and still needs some work. The gadget definition is 'toolbaralert2|toolbaralert2.js|toolbaralert2.css'. MediaWiki:Gadget-toolbaralert2 will need to be updated. Kaldari (talk) 20:52, 9 May 2013 (UTC)[reply]
Also, I should mention that it currently doesn't localize, i.e. it only displays the alert in English. Kaldari (talk) 20:55, 9 May 2013 (UTC)[reply]
It has been done. I don't know if the gadget should be moved to the Appearance section. Feel free to do so. — Edokter (talk) — 21:35, 9 May 2013 (UTC)[reply]

Notifications flag

How do I get rid of that Notifications tag at the top of my screen? I've disabled everything I know to within my preferences, but it's still showing up. My talk page is on my watch list, so I don't need that thing. Thank you! ←Baseball Bugs What's up, Doc? carrots→ 21:07, 8 May 2013 (UTC)[reply]

You can't. --Onorem♠Dil 21:08, 8 May 2013 (UTC)[reply]
Wikipedia talk:Notifications is the place to discuss it I guess, but it's not going away. --Onorem♠Dil 21:09, 8 May 2013 (UTC)[reply]
Was this done in place of that orange message bar that was there for years? ←Baseball Bugs What's up, Doc? carrots→ 21:16, 8 May 2013 (UTC)[reply]
This should get rid of the little number (e.g. "(0)") at the top of the page (not fully tested):
li#pt-notifications { display: none; }
However, do not use the above unless you have some other talk notification gadget or user script enabled! You need an immediate notification of talk page messages of some sort; it looks really bad if you continue editing after someone sends you a message asking you to stop and discuss. (I doubt you look at your watchlist between every edit.) – PartTimeGnome (talk | contribs) 20:04, 9 May 2013 (UTC)[reply]

Edit-window bar blocks notification popup

Tracked in Phabricator
Task T50078

Sorry to contribute to the fun but when I click the notifications tag in edit mode, the top bar of the edit window (with "Advanced", "Special characters", "Help" and "Cite") blocks part of the notifications popup (which, FWIW, I like now :-)). My skin is Vector. Thanks and all the best, Miniapolis 21:05, 9 May 2013 (UTC)[reply]

Are you using the Visual Editor? If so, this is bug 48078. – PartTimeGnome (talk | contribs) 21:15, 9 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.[2] 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[3], 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]

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 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]

Add 'move-subpages' permission to the filemover group

I already suggested this under Proposals, but got no response -- perhaps this is the right place instead. It's a pretty trivial request, and I can't imagine there would be opposition. Perhaps the reason no one responded there was that it is too trivial, and really, implementing it is just a technical issue. The following is a slightly modified version of what I wrote there.

Filemovers have been vetted to ensure that they can be trusted to move images, for example. I would think they should also be trusted to move subpages. Use case: Right now I am trying to help clean up categories and pages in the GLAM area, and we are renaming several project pages to use the full name of the institutions. This is extremely tedious because some of them have many subpages, and they have to be moved one-by-one.

I was just granted 'filemover' rights, but that doesn't allow me the ability to move subpages.

Klortho (talk) 14:06, 2 May 2013 (UTC)[reply]

  • Support I see no reason not to. -- King of ♥ ♦ ♣ ♠ 07:49, 3 May 2013 (UTC)[reply]
  • Comment This initially seems like a fine idea, even though the two rights aren't terribly connected. I'm just a tiny bit worried that this would lead to filemover being assigned solely for the move-subpages right, though. Perhaps add this to rollback instead? I think the use of this right should be (generally) easy to undo, as with rolled back edits, so that would seem like a better fit to me. – Philosopher Let us reason together. 19:41, 3 May 2013 (UTC)[reply]
Either one would be fine. Please tell me -- where does this go from here? I've never suggested a change here before, and I'd like to know what is the procedure for actually getting it done. Do we need a quorum of "support" votes? Klortho (talk) 03:01, 4 May 2013 (UTC)[reply]
To be clear, I would support either version, but greatly prefer the rollback one. As for next steps, it'll wait a few days. If nothing happens, you can bump a (preferably) uninvolved experienced user or admin who posts on this board to judge the existing consensus and try to get it moved to the next step. I think the next step is filing a bug on Bugzilla, but I'm not quite sure. Hope this helps. – Philosopher Let us reason together. 02:14, 6 May 2013 (UTC)[reply]
  • Oppose "filemover" has a clear purpose: moving files. Why screw that up by making it "file and subpage mover"?

    But the proposal in the comments to add it to "rollback" is even worse, as that has absolutely nothing to do with file moving, and I strongly oppose that. If you want to create a "slightly more trusted than the average user, but not enough to go through RfA" group, propose that (after reading WP:PEREN#Hierarchical structures) instead of trying to add rights piecemeal to rollback. Anomie⚔ 20:28, 6 May 2013 (UTC)[reply]

    • Really, we should just have a rights group with some of the obscurer admin rights that occasionally come in handy. Suppressredirect, move-subpages, markbotedits, unwatchedpages, maybe tboverride. Basically that category of rights that have too high an abuse risk to be bundled with anything else, but require nowhere near as much trust as the core admin tools. — PinkAmpers&(Je vous invite à me parler) 23:11, 6 May 2013 (UTC)[reply]
  • Oppose Moving subpages is a different thing. Create a "subpagemover" user group instead if this is needed. --Stefan2 (talk) 21:22, 6 May 2013 (UTC)[reply]
    • Creating a usergroup for something that trivial seems quite silly to me - there's no need to keep expanding the number of usergroups we have for each function that is made more widely available. When proposing that it be included with rolback, I wasn't considering function but level of generic trust, which should be the relevant criterion, I think. But perhaps ... what did you think of PinkAmpersand's idea? – Philosopher Let us reason together. 04:31, 8 May 2013 (UTC)[reply]
  • Sigh It really shouldn't be this difficult for me to get this right. I have no interest in applying for adminship, but this particular right would let me work more effectively, which would benefit WP. Move-subpages, IMO, should be the default behavior: how often do you want to move a page, but leave all the subpages in place? So, I don't think there's a huge potential for abuse. Most people who get filemover probably wouldn't even notice that they had this new right. So, what is the problem, other than the aesthetic issue that it doesn't "fit" with filemover? Philosopher wrote: "I'm just a tiny bit worried that this would lead to filemover being assigned solely for the move-subpages right, though." -- Yes, that's what happened with me: in hopes of this proposal being accepted, I requested filemover, and got it. So what? I'm technically competent and trustworthy, and I'm not going to abuse filemover, and it might come in handy in the future. On the other hand, I agree with Philosopher that creating a "subpagemover" group for this is silly -- the whole point of having groups is to bundle rights, to keep things from getting too complicated.
Okay, I'll propose PinkAmpersand's idea of "trusted user". Klortho (talk) 12:49, 8 May 2013 (UTC)[reply]
  • I think just adding this to rollback makes much more sense. This is not a common enough issue to warrant an entire new userright and it doesn't make a great deal of sense to merge it with filemover. Beeblebrox (talk) 18:44, 8 May 2013 (UTC)[reply]
  • Support Beeblebrox' idea. This userright is meant for mainspace, as is rollbacker, and unlike filemover, and we don't need a new usergroup. Nyttend (talk) 23:17, 9 May 2013 (UTC)[reply]

Thumbnail generation issue

I just uploaded this file for use here; the thumbnail in the page where it is used is displayed fine, but the server is refusing to generate previews of the image for use on the image page or non-full-resolution links therefrom. What is causing this; is it related to the database lockdown an hour or so ago?  — TORTOISEWRATH 01:37, 4 May 2013 (UTC)[reply]

Seems to work for me (thumbnail is displayed). If a specific thumbnail size does not display for you, please provide the size(s). --AKlapper (WMF) (talk) 12:51, 6 May 2013 (UTC)[reply]

climate table at Homer, Alaska

I've just removed a rather nice table at this article because it was causing a serious formatting error that generated massive whitespace in the article. This is the second time this has been added, the second time it has broken the article, and the second time I have spoken to the person who added it about it but they seemed uninterested in doing anything to rectify the situation. It's a nice table and I'd like to have it in the article, but not if it is going to ruin the formatting. Anyone know how to fix it? Beeblebrox (talk) 19:34, 4 May 2013 (UTC)[reply]

It's fairly easy to fix - the problem is that the weather table has to be a particular width, and it "collides" with the infobox and the images on the right, causing it to be shoved down until after the images - hence the whitespace.
I've moved the images below the box for now (it may still have some whitespace on wider screens due to the infobox); the other solution would be to move the weather table much further down the page. Andrew Gray (talk) 20:34, 4 May 2013 (UTC)[reply]
That works for me, thank you. Beeblebrox (talk) 22:34, 5 May 2013 (UTC)[reply]

Generating a JS library for cleanup scripts

While I was fixing some bugs at our WP:AFC helper script (WP:AFCH) I was realizing that there are many scripts trying to archive many kind of cleanup the same way and reinventing the wheel. I want that these developers work together (more?) and generate a library for cleanup uncontroversial stuff like converting HTML markup to wiki markup, fixing common spelling errors, removing unnecessary HTML comments (the AFC project is generating many of them) and doing similar stuff.

Potianial script for such a library (I know of) would be:

and additional this also could be added to Twinkle as a general cleanup while tagging pages.

Would anybody experienced with JavaScript and/or Regex would help me adding as many as possible uncontroversial cleanup lines to this library and improving Wikipedia by crowed developing? :-)

mabdul 22:13, 4 May 2013 (UTC)[reply]

My experience with both is limited, but I would be happy to contribute where I can. Technical 13 (talk) 22:55, 4 May 2013 (UTC)[reply]
Is it a case of 'reinventing the wheel, or is it simply 'many hands make light work'? I run several scripts. Each script has a unique scope with some minimal overlap. Of those, my formatting script does things similar to AWB general fixes, and it is possibly the one you would target as being of the most general in cleaning up function. The scripts all employ regexes, so copying them over per your thoughts should be relatively simple. Maybe some others can chip in about the collaboration model: for security reasons, scripts are currently protected and tied to the user. -- Ohconfucius ping / poke 01:11, 5 May 2013 (UTC)[reply]
One possible solution for using the central depository might be to call up script functions from another. This can be done so long as it's imported into the driver script, in the same manner as importing into vector or monobook. Tony1 achieves a 'one-touch' facility by installing my control script – a composite I wrote for that purpose. -- Ohconfucius ping / poke 02:09, 5 May 2013 (UTC)[reply]
You probably should start with AutoEd. It is a javascript program that calls other javascript modules. There is a module to convert HTML markup to wiki code, some others to correct formatting.
Typos project is used by AWB, WikEd and WPCleaner for spelling mistakes. Bgwhite (talk) 08:36, 5 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]
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]

Adding new content (with reference)

While moving pictures and copyediting in the Home Front (World War II) article, I forgot to add: 'New material to the "Britain" ' section, on 4 May 2013. Trying three or four times, both yesterday and today, for some reason, it will not accept my input when I press 'Save' (it's only on this page). But the new content is there; I've looked. RASAM (talk) 12:20, 5 May 2013 (UTC)[reply]

Are you trying to change the edit summary without changing content? --  Gadget850 talk 12:29, 6 May 2013 (UTC)[reply]
Looks likely that that's it. A way round it is to delete your new material, and then save, followed by re-adding it with the edit summary. Or easiest, just don't worry about it. If you're not planning to stand for an admin job in the near future, just leave it. No-one's going to block you or shout at you for missing one summary. I don't think summaries without content will go into the record. Peridon (talk) 15:09, 6 May 2013 (UTC)[reply]
Hang on - you did it at Home front during World War II not Home Front. You moved pics and left an edit summary there all right on that day. Perhaps that's the trouble... Peridon (talk) 15:15, 6 May 2013 (UTC)[reply]
Sorted. Peridon (talk) 08:58, 7 May 2013 (UTC)[reply]

Toolserver problems

Referring back to Toolserver funkiness from April 21, it's still crap. Don't know how much I've tried since then. But the message that keeps coming up today when I tried to access "Contributors" from an article's history page is,

Bad Gateway
An error occurred while communicating with another application or an upstream server.
There may be more information about this error in the server's error logs.

It only has to do with the Contributors, all other options under history have always worked fine. If I go into the Firefox "Page Info" or "Page Source", it had exactly that same message, nothing else. — Maile (talk) 14:59, 5 May 2013 (UTC)[reply]

I've been having random problems for the past couple days whenever I try to use anything on Toolserver. I'm getting "Bad Gateway," "Gateway Time-out," "Page not found," "en.wikipedia.org is not a valid wiki," whatever it feels like giving me. What's gone wrong this time?  — TORTOISEWRATH 01:43, 6 May 2013 (UTC)[reply]
I got it to give me X!'s Edit Counter this time, but the replication lag is terrible right now. Is this related to the database lock a couple days ago, perchance?  — TORTOISEWRATH 01:48, 6 May 2013 (UTC)[reply]
I began noticing this weeks before I first posted about it on April 21. It comes. It goes. And just when you need it, it malfunctions. Since I posted above today, I went over to toolserver and tried tools I knew about. More than half the time, I got that "Bad Gateway" message. Right now, it's working. But later, it won't. Very unreliable. — Maile (talk) 02:01, 6 May 2013 (UTC)[reply]
I've gotten nothing but "Page not found" errors at least since yesterday. Anybody here in contact with anyone over there? Rivertorch (talk) 05:08, 8 May 2013 (UTC)[reply]

Preferences date/time-setting

I changed the format and TZ of date/time in Preferences, but the software still shows the UTC time. Should be CEST since I'm in Italy. Please give me a valid reason for this behavior. All 4 other great Wikipediae do it right, only the English is different. The number format (.=>,) as well, but I can accept this as a geek :-), Kind regards from Tuscany,  Klaas|Z4␟V:  15:35, 5 May 2013 (UTC)[reply]

It works for me. What exactly does "Server time", "Local time" and "Time zone" say at Special:Preferences#mw-prefsection-datetime? Do you see the UTC time in page histories and user contributions like Special:Contributions/ZeaForUs? Signatures and other content based on wiki source is not affected by the setting (but a gadget can affect it). PrimeHunter (talk) 18:17, 5 May 2013 (UTC)[reply]
Browser info (name and version) also welcome. --AKlapper (WMF) (talk) 12:55, 6 May 2013 (UTC)[reply]

Patrolling new pages

I used to be able to patrol new pages (allthough I never did). Some time ago, however, I lost the ability. I can't mark a page as patrolled anywhere (as I can see), and the red and green circles to the right which used to be there when I looked at new pages don't show anymore. Suggestions? Regards, Iselilja (talk) 19:32, 5 May 2013 (UTC)[reply]

That has happened to me as well, and I did used to patrol them.--Gilderien Chat|List of good deeds 22:51, 5 May 2013 (UTC)[reply]
    • Have either of you disabled JavaScript? I believe that the badge that pops up when I mark a page as patrolled (there's a tiny link at the bottom of the page) is a JavaScript thingie, so possibly the entire thin is. But wait a minute... 1) did you know there's a link at the bottom of the page? and 2) are you using Page Curation? In which case what I just said may have no bearing. Hope this helps. Ignatzmice•talk 22:55, 5 May 2013 (UTC)[reply]
@Gilderien, Iselilja: When you visit Special:NewPagesFeed and review a specific page, is there a "Curate this page" link in the toolbox section on the lefthand side? If so, clicking that link should make the toolbar that you can use to review pages re-appear.--Eloquence* 01:08, 6 May 2013 (UTC)[reply]
  • Thanks for input. No, I cannot see a "Curate this page" link. And I don't get this "Mark this page as patrolled" link at unreviewed pages anymore. (Maybe I should mention that my skin is Cologne Blue, but this has been so all the time). I believe I have the JavaScript installed as I am able to use my internet bank. Regards, Iselilja (talk) 05:15, 6 May 2013 (UTC)*[reply]
  • Eloquence, Ignatz, Gilderien. NOW, I found it: A "curate this page" link, and after I clicked it the right side bar is showing up again. Thank you, very much, Iselilja (talk) 22:22, 6 May 2013 (UTC)[reply]

Hidden categories text size

I'm trying to find a way to make the hidden categories have a smaller font size than the main categories. Surely there's some CSS hack I'm not aware of. I've found <div id="mw-hidden-catlinks" class="mw-hidden-catlinks mw-hidden-cats-user-shown"> in the HTML code, if that helps. FallingGravity (talk) 05:58, 6 May 2013 (UTC)[reply]

Judging by this edit, try 
div#mw-hidden-catlinks { font-size: 88%; }
which works for me. I put it in Special:Mypage/skin.css but I don't see why it couldn't go in Special:Mypage/common.css --Redrose64 (talk) 09:33, 6 May 2013 (UTC)[reply]
That worked, thanks! FallingGravity (talk) 18:53, 6 May 2013 (UTC)[reply]

Email notification

Hi, is the email notification system working? I don't seem to be receiving items although my email appears to be working, so I don't think it's a problem on my own emails. SagaciousPhil - Chat 09:51, 6 May 2013 (UTC)[reply]

Have you checked your notification preferences? Also, has your email adress been confirmed? — Edokter (talk) — 10:33, 6 May 2013 (UTC)[reply]
Yes, I've re-checked preferences and notifications and everything is set correctly. It was working fine yesterday evening but just stopped and there is still nothing coming through - for instance, I didn't receive notification of your response, just picked it up by checking my watch list. SagaciousPhil - Chat 10:53, 6 May 2013 (UTC)[reply]
All of a sudden in the last few minutes, email notifications have started to arrive. SagaciousPhil - Chat 16:45, 6 May 2013 (UTC)[reply]
Resolved

Skip to TOC - Skip to Bottom

Skip to TOC - Skip to Bottom appears at the top of any of my user space pages (i.e. sandboxes etc.). The problem is, it lays itself right across the Edit link for the lead, making it impossible for me to click on that. This has only started happening recently, but I'd like to know how to get rid of it. Only on user space pages. I've changed skins to see if it will at least appear at a different place on different skins. Nope, that thing totally covers up my Edit link for the lead section. Zooming in or out with my browser does not change the position. I have absolutely no need for this "Skip to..." message, and it just hinders my editing ability on my own pages. Please tell me how to turn it off. — Maile (talk) 11:54, 6 May 2013 (UTC)[reply]

And...it's not on all my user space pages. It's just hit and miss as to which one it appears on. No pattern I can see what makes it appear on one user space page and not another. Has nothing to do with whether or not there is a lead section. And it has nothing to do with whether or not there even is a TOC on the page. This is strange. — Maile (talk) 12:17, 6 May 2013 (UTC)[reply]
Added nostb for you. — Bility (talk) 18:14, 6 May 2013 (UTC)[reply]
Thank you very much. That worked. — Maile (talk) 18:20, 6 May 2013 (UTC)[reply]
Well, it worked on my main user page. It did not work on This One. So, I'm wondering what I did in setting up this particular page that triggered it. — Maile (talk) 18:27, 6 May 2013 (UTC)[reply]
OK. Well, I see that something in the navboxes was triggering it. So, I removed the navboxes. End of problem. — Maile (talk) 18:29, 6 May 2013 (UTC)[reply]
There was already an instance of {{Noticeboard links}} on the page, so adding another one with |nostb=yes didn't do anything. Just needed to add the parameter to the template that was already on there. Cheers, — Bility (talk) 18:31, 6 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]

Invalid Search redirect to C2.org

Typing Wiki:SOFIXIT (okay I forgot what the proper link for shortcut, it should be WP:SOFIXIT) into the search bar on FF or the search bar on wikipedia itself links to C2.org instead of a page saying no link exists. ηoian ‡orever ηew ‡rontiers 19:53, 6 May 2013 (UTC)[reply]

It's a feature. Typing wiki:anything you like will always go to http://c2.com/cgi/wiki - it's one of the prefixes listed at m:Interwiki map. Same goes for wikilinks like wiki:anything. --Redrose64 (talk) 20:13, 6 May 2013 (UTC)[reply]
Indeed. But here's a slightly confusing detail: if you type <known interwiki prefix>:<any text> and press search rather than go, our search results page tells you "There is a page named "xx:yyy" on Wikipedia". This is wrong in two ways: (1) the page might or might not exist, it's only the prefix that exists for sure; (2) the page will not necessarily be on a site called Wikipedia.
It's obvious where this comes from, since the prefix is known the whole thing is a valid link from Wikipedia's point of view, so the search engine claims we have that page. But the phrasing is not quite right in the case of interwiki links. — HHHIPPO 20:28, 6 May 2013 (UTC)[reply]
The default Vector skin doesn't have search and go buttons. The search button in other skins corresponds to "containing..." in the drop-down box. ηoian is far from the first to be confused by wiki: going to c2.com. There is a suggestion to remove this prefix at meta:Talk:Interwiki map#Wiki. The discussion could actually use some technical expertise. Anyone have a method to determine the number of uses in Wikimedia wikis? If the prefix is removed then presumably a bot should change the uses at all wikis to one of the three other prefixes for c2.com. Can the uses be identified? PrimeHunter (talk) 22:45, 6 May 2013 (UTC)[reply]

https://

Resolved
 – Back up since circa 14:00, 7 May 2013 (UTC)

The https:// version of the site is inaccessible. Is this happening to anyone else?--Gilderien Chat|List of good deeds 19:54, 6 May 2013 (UTC)[reply]

tracert
 5    35 ms    42 ms    29 ms  r1fra1.core.init7.net [80.81.192.67]
 6    30 ms    48 ms    38 ms  r1fra3.core.init7.net [77.109.128.222]
 7    42 ms    43 ms    43 ms  r1fra2.core.init7.net [77.109.128.245]
 8    56 ms    48 ms    46 ms  r1ams2.core.init7.net [77.109.128.201]
 9    48 ms    45 ms    47 ms  gw-wikimedia.init7.net [77.109.134.114]
10    45 ms    42 ms    42 ms  wikipedia-lb.esams.wikimedia.org [91.198.174.225]

Computer problems

1. The 'radio' buttons on all 'Revision history' pages always revert to the top two, after looking at any version - which makes a systematic trawl from the older edits to the most recent article page rather difficult. I've got a new computer with Windows 8 and Internet Explorer 10; the old one with Windows XP and IE 7 did not have this problem.

2. "Internet Explorer is not working correctly" is constantly being displayed. Sometimes it means that I lose eveything I have done. Again, I did not have this situation with the old computer. Anyone got any idea why and what I might do about it?


RASAM (talk) 21:30, 6 May 2013 (UTC)[reply]

As a start, do you experience the same problems with a different browser? --AKlapper (WMF) (talk) 08:49, 7 May 2013 (UTC)[reply]
They do mention this didn't happen using IE 7 on Windows XP, so I'd guess not.
Regarding the first point, you might find the "← Previous edit" and "Next edit →" links at the top of diff pages useful for tracing through history one edit at a time. Also, on a history page you can click the "prev" link next to an edit to quickly compare it with the previous edit without touching the radio buttons. (I appreciate that these tips aren't so useful if you want to compare edits in groups rather than one at a time.) – PartTimeGnome (talk | contribs) 20:23, 9 May 2013 (UTC)[reply]

reverting single edit (not last one)

When someone does something obnoxious like this 8 Feb edit, which removed all ref tags, and some other code, I know one can restore to the version prior to the edit, but that will wipe out the couple dozen subsequent edits. Is there a solution which undoes that one edit without disturbing the subsequent edits? I'm fairly sure the answer is no, but want to ask, just in case.--SPhilbrick(Talk) 22:20, 6 May 2013 (UTC)[reply]

You can sometimes undo the edit, as long as there is no conflict with any of the following edits. However, it doesn't look like that will work in this case. --Bongwarrior (talk) 23:55, 6 May 2013 (UTC)[reply]
Yeah, I tried that, but it failed. Oh well.--SPhilbrick(Talk) 00:44, 7 May 2013 (UTC)[reply]
Resolved
by doing it manually.--SPhilbrick(Talk) 12:45, 8 May 2013 (UTC)[reply]

Template:Commons category multi

Could someone take a look at Template:Commons category multi? When there are 2 categories listed, the box is not "clearing right". It's aligned right, but it floats to the left of other right-aligned boxes. See Category:Horticulture and gardening, it should be under the "infobox catalog", not to the left of it. Thanks, --Funandtrvl (talk) 00:06, 7 May 2013 (UTC)[reply]

I think I took care of it. --Izno (talk) 00:24, 7 May 2013 (UTC)[reply]
Yes, I think that worked. Thanks! --Funandtrvl (talk) 00:28, 7 May 2013 (UTC)[reply]

Custom CSS - color change

Using: Firefox, latest version

What I want is to make the background display the color I choose. My CSS code so far (within "body { }brackets): 

   font-family: DejaVu, serif;
   font-size: 125%;
   color: #FFD6AD;
   background-color: #FFD6AD;
   content: #FFD6AD;

This turns everything my chosen color except the background of the article itself -- that's still white. What am I missing? --Bluejay Young (talk) 02:27, 7 May 2013 (UTC)[reply]

Try this outside body brackets:
#content { background : #FFD6AD !important; }
PrimeHunter (talk) 03:19, 7 May 2013 (UTC)[reply]
You should also remove the 
content: #FFD6AD;
from its present position. The content: property can't control colour, and so it isn't expecting a colour value. Another point: if you have settings like
    color: #FFD6AD;
    background-color: #FFD6AD;
what you're asking for is text of this colour on a background of this colour which looks like this and that has serious WP:CONTRAST issues, even if you have 20/20 vision. --Redrose64 (talk) 09:49, 7 May 2013 (UTC)[reply]

Template: Conjugate

Could someone of HTML/CSS experts review my template {{conjugate}}? You can see the actual use in composition algebra. When you helped me with possible shortcomings, I would back-port the style to {{sqrt}} and {{radic}} which suffer from (e√þ same) √disease as {{overline}}. Incnis Mrsi (talk) 07:24, 7 May 2013 (UTC)[reply]

I would advice against the packport. Both implementations may show better results on one, and worse result on other poeple's computers. It all depends on what fonts are used on the user's display. They actually look very similair to me. — Edokter (talk) — 23:46, 7 May 2013 (UTC)[reply]
Thanks, but does any reliable mean to control the gap between the top of glyphs and the overline exist? Or any calculation for upper border departs from some fixed line such as cap height and hence, a uniform solution for uppercase and lowercase letters is not possible? Edokter, please, watch your spelling. Making three typos in a short reply is awful. Incnis Mrsi (talk) 09:32, 8 May 2013 (UTC)[reply]
There is no 100% failproof way to position the overline. You can play with line-height, but that also varies with the used font. — Edokter (talk) — 10:15, 8 May 2013 (UTC)[reply]
Line-height has no effect either. Padding is already zero. If your goal is to make the line lower, then there is no way. — Edokter (talk) — 10:20, 8 May 2013 (UTC)[reply]
On my screen, {{overline}} looks actually slightly better in composition algebra then {{conjugate}}; the overline is slightly closer and scales better with font-size. — Edokter (talk) — 10:37, 8 May 2013 (UTC)[reply]

Universal account

Where can I discuss my situation regarding my accounts on other Wikimedia projects? Simply south...... eating shoes for just 7 years 10:02, 7 May 2013 (UTC)[reply]

There was some related discussion at Wikipedia:Village pump (technical)/Archive 111#Unwanted global account(s), which may contain helpful links. --Redrose64 (talk) 10:42, 7 May 2013 (UTC)[reply]
Thanks although mine is a different situation. I have now expanded a little and left a note at WT:Unified login/Finalisation if you want to reply there. Simply south...... eating shoes for just 7 years 10:53, 7 May 2013 (UTC)[reply]

Mass removal of old indefinite rangblocks under controlled conditions

Hello,
There is currently an ongoing proposal at Village Pump (proposals) to review and remove most old indefinite rangeblocks on IPs, and to have their edits monitored for an interim period of time. The proposal has received nearly unanimous support from about a dozen editors, but there has not been any discussion so far on how it could be possibly implemented. Anyone with any technical know-how is welcome to comment on the proposal as well as to discuss on how to implement it, should it pass.
Thank you,
TheOriginalSoni (talk) 10:02, 7 May 2013 (UTC)[reply]
[Please comment on that discussion only]

File move strangeness

Can anyone figure out what's going on with File:Detail from Alfons Maria Mucha's "The Slavs in Their Original Homeland".jpg? I moved it to that title from File:Deatail from Alfons Maria Mucha's "The Slavs in Their Original Homeland".jpg, but now the image information page also displays as a redirect. I just can't figure it out. Thanks.--ukexpat (talk) 15:36, 7 May 2013 (UTC)[reply]

The redirect from the original location to the new location, was also on the new pointing to itself. - X201 (talk) 16:08, 7 May 2013 (UTC)[reply]
File:Detail from Alfons Maria Mucha's "The Slavs in Their Original Homeland".jpg (edit | talk | history | links | watch | logs)
Somehow you managed to do the move twice: first, moving the file page from the bad name to the good name, and then moving the redirect page on top of the file page. This needs an admin, I think, to recover the lost file page with its permission templates and such like. -- John of Reading (talk) 17:03, 7 May 2013 (UTC)[reply]
Jeez, so I did. I have no idea how or why I did that. Would a friendly admin in the neighbourhood please stop by and try to fix? Thanks.--ukexpat (talk) 17:42, 7 May 2013 (UTC)[reply]
I'm not entirely clear what the problem is. Is it that a redirect is listed at File:Detail from Alfons Maria Mucha's "The Slavs in Their Original Homeland".jpg#File usage? I don't think that's necessarily wrong: I recently moved File:Lewisham train crash 1857.jpg to File:St Johns train crash 1898.jpg and the old name is listed as a redirect at File:St Johns train crash 1898.jpg#File usage. --Redrose64 (talk) 18:34, 7 May 2013 (UTC)[reply]
It's more subtle than that. After the first move, at 13:04:34, there was a redirect at the wrong name and a proper file page at the right name. Eleven seconds later, the second move copied the redirect over the file page. The file was originally uploaded in November 2012, but the file page created then has been lost. Is it possible for an admin to recover it? -- John of Reading (talk) 19:13, 7 May 2013 (UTC)[reply]
There's very little in the logs for the old name, and nothing in the logs for the new name. There's nothing at the deletion archive, for either file. I rather think that it's beyond the powers of a WP:ADMIN, you need a specialist with direct SQL access. --Redrose64 (talk) 20:36, 7 May 2013 (UTC)[reply]
Can anyone recover the lost page from a database dump? This needs someone with a database dump and some Perl skills; I have the dump but not the skills. -- John of Reading (talk) 07:47, 8 May 2013 (UTC)[reply]
But that sounds like a bunch of work; wouldn't it be easier to put together a new page? We still have the image with its watermark, so we know its origin; this page says that it was published in 1912, so it's PD-US, and its Czech copyright status will depend on his 1939 death date. Meanwhile, a little confirmation on the unavailability of this data for admins: Special:Contributions/Chocolatemedia (the uploader) shows nothing around the time of upload except this, to add the new image to Mucha's article. Special:DeletedContributions/Chocolatemedia shows six edits, all of which are to Aslyoga, "an organiation that provides free yoga classes for the Deaf and Hard of Hearing communities". Nyttend (talk) 22:02, 9 May 2013 (UTC)[reply]

Twinkle D-batch

See User talk:MZMcBride#Advice. I can't seem to get the D-batch function to work on Category:Candidates for speedy deletion or any other page for that matter. There's a bunch of G8 speedies for broken redirects that I wanted to batch delete. How to get D-batch to work, or other methods of batch-deleting? INeverCry 19:30, 7 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]
  • 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]

Namespace numbers

Wikipedia data structure
Namespaces
Subject namespaces Talk namespaces
0 (Main/Article) Talk 1
2 User User talk 3
4 Wikipedia Wikipedia talk 5
6 File File talk 7
8 MediaWiki MediaWiki talk 9
10 Template Template talk 11
12 Help Help talk 13
14 Category Category talk 15
100 Portal Portal talk 101
118 Draft Draft talk 119
126 MOS MOS talk 127
710 TimedText TimedText talk 711
828 Module Module talk 829
Former namespaces
108 Book Book talk 109
442 Course Course talk 443
444 Institution Institution talk 445
446 Education Program Education Program talk 447
2300 Gadget Gadget talk 2301
2302 Gadget definition Gadget definition talk 2303
2600 Topic 2601
Virtual namespaces
-1 Special
-2 Media
Current list

Who came up with these numbers? I guess the first few were created in chronological order, and the virtual namespaces in negative chronological order, but who decided that modules should be 828? -- Ypnypn (talk) 00:21, 8 May 2013 (UTC)[reply]

Its partially because it includes all Wiki's and their namespaces including some that have been deleted and some that were created and never launched. For example Wiktionary and Wikispecies both have some that Wikipedia doesn't have. I hope that helps. Kumioko (talk) 00:34, 8 May 2013 (UTC)[reply]
So there are a total of at least 414 namespaces, across all wikis across all time? -- Ypnypn (talk) 01:23, 8 May 2013 (UTC)[reply]
mw:Namespace_registration refers, but its list is far from comprehensive. LeadSongDog come howl! 04:34, 8 May 2013 (UTC)[reply]
150 is clearly what we as a community are lacking. ~ Amory (u • t • c) 06:09, 8 May 2013 (UTC)[reply]
Extensions are able to pick any namespace ID they'd like that's not already in use. I believe 828/829 wasn't chosen for any particular reason other than it's unlikely to conflict with any other numbers chosen. In practice, these numbers should matter very little to most users. ^demon[omg plz] 12:55, 8 May 2013 (UTC)[reply]
I'm guessing that they're numbered in the first place to transcend language difficulties — if they program the system to treat namespace 3 in one way, namespace 75 in another way, etc., they don't need to worry about the names of the namespaces, while they'd need to worry about it if they told the system to treat namespace Benutzer Diskussion: in one way and namespace Anexo: in another. Nyttend (talk) 13:29, 9 May 2013 (UTC)[reply]
Well yes, that's how namespaces work internally. ^demon[omg plz] 15:36, 9 May 2013 (UTC)[reply]

Create a new "trusted user" permission group.

See this discussion. The proposal is to create a new group which bundles a few miscellaneous rights that don't fit in any of the existing groups. User:PinkAmpersand suggests "Suppressredirect, move-subpages, markbotedits, unwatchedpages, maybe tboverride." The reason I'm requesting this is that I'd like to be granted "move-subpages" permissions, but it isn't currently granted for any groups but admins. In the discussion linked to, I proposed adding it to Filemover, but that didn't fly. Klortho (talk) 12:55, 8 May 2013 (UTC)[reply]

Errors...

It seems MediaWiki is choking this morning - been getting a few of the "Error" pages, and CSS styles(?) are pretty much borked on pages right now - all the text is displaying with absolutely zero formatting... - The Bushranger One ping only 13:41, 8 May 2013 (UTC)[reply]

At least, in Monobook - Vector seems to be OK, and oddly, most of the edit window seems to be OK, but the actual pages are wholly unformatted. - The Bushranger One ping only 13:45, 8 May 2013 (UTC)[reply]
  • (edit conflict) Yeah, I've been getting that too. Sometimes the page doesn't load; sometimes the page loads w/o CSS. JavaScript (e.g. Twinkle, suggestions in the searchbar, right-click to edit sections) also seems to be gone (and I haven't messed around with my common.js that recently...) P.S. I'm in Monobook too. Ignatzmice•talk 13:48, 8 May 2013 (UTC)[reply]
I am seeing it too -- the hamsters need a rest or replacement.--ukexpat (talk) 13:51, 8 May 2013 (UTC)[reply]
Ditto. Using Vector, some pages take upwards of 30 seconds to load (although eventually of all them do). All Wikimedia sites are causing the same problem (at least WP, Meta, and MW). Sometimes the CSS doesn't load. I remember a similar thing happening a few months ago. -- Ypnypn (talk) 13:54, 8 May 2013 (UTC)[reply]
Seems to be fixed now... Ignatzmice•talk 14:05, 8 May 2013 (UTC)[reply]
This sounds a lot like the outage on Wednesday, 13:30 - 14:00 UTC, due to a memcached server going offline. "As usual this caused all kinds of cascading failures on other clusters such as Squid/Varnish. When not overloaded, these clusters would only serve cached pages at that point." Should be fixed now. Sorry for the problems. --AKlapper (WMF) (talk) 01:32, 10 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]

Require IP/anon edits to enter an edit summary

Just wondering if the Wiki software was capable of enforcing the entry of edit summaries when users are not logged in (i.e. IP/anonymous users)? Registered users would be unaffected; they could continue to leave blank edit summaries based on their judgement (and lack of criticism from other editors). One notorious problem is that IPs will change information on articles (vital stats or facts) without explanation - often it is introduction of errors; sometimes it is choosing data from conflicting and/or unreliable sources; occasionally a valid point is being made, but the editor is not indicating that. The countervandalism and edit review process would be expedited if IPs had to enter an edit summary, ideally with a prompt which explains the need for reliable sourcing and the value of edit summaries. Or we could keep the status quo and continue to waste a lot of collective time attempting to read minds when dealing with most IP edits. Dl2000 (talk) 21:21, 8 May 2013 (UTC)[reply]

You can't force a useful summary...so why force a summary? --Onorem♠Dil 21:25, 8 May 2013 (UTC)[reply]
agree with Onorem. we currently get a lot of the "often it is introduction of errors; sometimes it is choosing data from conflicting and/or unreliable sources; " that ARE accompanied by edit summaries. And those summaries are rarely "I am adding bad information". -- TRPoD aka The Red Pen of Doom 21:29, 8 May 2013 (UTC)[reply]
Example. This is in fact useful, because there is a lot of unsourced WP:CRYSTAL being added to articles about British heritage railways - and although the IP address changes at least once a day, the edit summary is normally "Update!!" --Redrose64 (talk) 21:35, 8 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]

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]

Gadgets in the Slovene Wikipedia

Tracked in Phabricator
Task T50278

Hi, my apologies for bringing this up at the English Wikipedia, however this page seems to be the best place to get an answer. In the last days I've spotted that all the gadgets have disappeared in the Slovene Wikipedia (sl:) (HotCat doesn't work, PopUps don't work etc., the 'Gadgets' tab in the Preferences has disappeared). Any idea what's the reason for this and what to do? --Eleassar my talk 10:38, 9 May 2013 (UTC)[reply]

This is weird. sl:Special:Gadgets is supposed to show a list of all gadgets available on the wiki, but it is blank. sl:MediaWiki:Gadgets-definition has not been modified since March. Based on this, it looks as if there is some internal problem with the Gadgets extension on slwiki. I suggest you either file a bug in bugzilla:, get on IRC #wikimedia-tech connect, or contact Duesentrieb (email). — This, that and the other (talk) 11:10, 9 May 2013 (UTC)[reply]
Ok, thank you. --Eleassar my talk 11:55, 9 May 2013 (UTC)[reply]
A null edit to MediaWiki:Gadgets-definition on slwiki will fix the problem. See also bugzilla:37228. Issue has been known about for a while, and was caused due to the partial outage that occured yesterday. Reedy (talk) 12:27, 9 May 2013 (UTC)[reply]
It has worked. Thank you. --Eleassar my talk 12:47, 9 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]

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]

Preferred format for pronunciations

I'm doing Commons:Commons:Bots/Requests/Smallbot_9 where ~6.5k pronunciations will be uploaded to the commons. What is the preferred format for pronunciations: .ogg or .webm?Smallman12q (talk) 17:46, 9 May 2013 (UTC)[reply]

.ogg --Edgars2007 (talk/contribs) 17:49, 9 May 2013 (UTC)[reply]

User questioning if they've been hacked

Please advise if I should report this to anyone. On May 6, 2013, I made This revert, and posted a standard Warning template on the IP address talk page. Today, I received Spurious posting? inquiry on my talk page. I think the IP is used by many users, but thought I should mention this if there's anything that needs to be addressed. — Maile (talk) 18:17, 9 May 2013 (UTC)[reply]

It looks as if the user just didn’t notice that she is logged out.—Emil J. 18:28, 9 May 2013 (UTC)[reply]
That would be my guess. Besides which, the user doesn't seem to know exactly what their user account name is. — Maile (talk) 18:30, 9 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]

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]

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]

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]

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