Wikipedia:Village pump (technical)

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

wikimedia.org 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.

view · edit

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

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

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

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

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

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

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

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

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

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

Relinking Google for SSL https

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

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

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

Page https "Parabola" (stats-201304, 600/day formerly 2,500/day) lower than rare "Hyperbola" (stats-201304 1,300/day)
Page https "Gone with the Wind (film)" (stats-201304, 1,860/day formerly 4,900/day) lower than "Lawrence of Arabia (film)" (stats-201304 2,800/day)

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:

April Parabola stats-201304, 620/day, versus March, Parabola stats-201303, as formerly 2,490/day.
May Hyperbola stats-201305, 405/day, versus March, Hyperbola stats-201303, as formerly 1,192/day.

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]

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]

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]

When I click on the notifications button, the left hand one-third of the window that opens is off the left-hand side of my screen [1]. this is the first time I've done this, so I don't know if it worked before your change. Black Kite (talk) 10:53, 2 May 2013 (UTC)[reply]
- Try bypassing your browser cache. If that doesn't help then it's because my changes don't work on IE and unfortunately I don't own Windows, so it will be difficult for me personally to help you along. Which version of IE are you using specifically ?—TheDJ (talk • contribs) 11:05, 2 May 2013 (UTC)[reply]
  - Bypassing the cache didn't work - it's IE9 (at work). Here at home, I'm on Firefox and it's fine. Black Kite (talk) 18:16, 2 May 2013 (UTC)[reply]
    - As I'm also a modern user, I will test it at work tomorrow. (only having access to a Mac right now) mabdul 19:54, 2 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]

Question Is there a way I can get back the orange bar? "I am used to it" might not be the best justification, but I don't know whether I will recognize the small number. -- Toshio Yamaguchi 07:46, 3 May 2013 (UTC)[reply]
The orange bar should be there for users that are not yet autoconfirmed, to ensure that they get their notifications. Remember that not all users even know they have a talk page. As for the rest of us, I'm sure a script will show up sooner or later to give it back to us if we want it. – Philosopher ^{Let us reason together.} 19:46, 3 May 2013 (UTC)[reply]
- I wrote a script the other day that replicates the orange bar functionality; it's at User:Writ Keeper/Scripts/orangeBar.js. You can install it by adding the line importScript("User:Writ Keeper/Scripts/orangeBar.js"); to your common.js page. Writ Keeper ⚇♔ 19:49, 3 May 2013 (UTC)[reply]
  - Brilliant, thanks! Just to reiterate, though, I do think it should be turned on by default for users who are not yet autocinformed. – Philosopher ^{Let us reason together.} 20:01, 3 May 2013 (UTC)[reply]
  - Agreed, very cool. Thank you. -- Toshio Yamaguchi 20:03, 3 May 2013 (UTC)[reply]
    - Brilliant! Thank you! The new tiny little number (which is very very easy to overlook) is perhaps the single most stupid change in Wikipedia for a very long time (despite stiff competition). Good to have the orange banner back! Grutness...wha? 05:53, 4 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]

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]

Section edit links are migrating westwards

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]

They have, apparently. — Crisco 1492 (talk) 11:40, 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]

GAAAAAHH! I liked the edittop too! Why do they keep doing this to us? Ignatzmice•talk 18:54, 6 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]
- In case you haven't seen yet, there's a simple fix: Add span.mw-editsection { float:right; } to your common.css style sheet. Ignatzmice•talk 11:40, 7 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]
  - That could be useful - a "trusted user" group, perhaps. However, that seems like a prime target for wiki-drama when asking which rights to bundle into it and who to give it to, so maybe it's not a great idea? – Philosopher ^{Let us reason together.} 04:28, 8 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]

Issue with Main Page on mobile, viz. it hasn't changed since Tuesday

Tracked in Phabricator
Task T50062

Pull up the mobile site en.m.wikipedia.org/wiki/Main_Page. You'll find that Adrian Boult is still the Featured Article, the Icelandic election is the top news story, and the ITN picture is still the unfortunate minaret (rather than the new King of the Netherlands). Why, and how can this be fixed? Lockesdonkey (talk) 00:16, 3 May 2013 (UTC)[reply]

How about now? I logged in on the mobile site and purged the page. Looks fine to me now. jcgoble3 (talk) 01:08, 3 May 2013 (UTC)[reply]

I purged my whole cache. No dice. Also, this is happening on two devices in two browsers: one on a MacBook Pro running Chrome (OS: OS X Lion) and on an iPhone 4 running Safari (iOS 6.1.3). Lockesdonkey (talk) 02:13, 3 May 2013 (UTC)[reply]

I can confirm that this problem exists for me viewing [2] in Firefox 23 on Windows 7, something I've never done. Definitely a server-side problem. — TORTOISE WRATH 02:22, 3 May 2013 (UTC)[reply]

Firefox 20.0.1 on Windows 8 here, and after going back to the page now, it's back to the old version again. But if I log in, it shows me the current version. Sounds like bugzilla:44391 has now manifested itself on the mobile site (also see the discussion from the original version of this bug). jcgoble3 (talk) 03:17, 3 May 2013 (UTC)[reply]

Indeed. — TORTOISE WRATH 03:47, 3 May 2013 (UTC)[reply]

Thanks for reporting this! The problem sounds like an issue in the MediaWiki server configuration. It would be nice if somebody who has this issue could send the software bug to the 'Bugzilla' bug tracker by following the instructions How to report a bug. This is to make developers of the software aware of the issue. If you have done so, please paste the number of the bug report (or the link) here, so others can also inform themselves about the bug's status. Thanks in advance! --AKlapper (WMF) (talk) 12:17, 3 May 2013 (UTC)[reply]

Reported as bugzilla:48062. — TORTOISE WRATH 01:26, 4 May 2013 (UTC)[reply]

Where is the audit trail for all actions on an article under pending changes?

Resolved

– It is called the review log. Orange Suede Sofa (talk) 19:36, 3 May 2013 (UTC)[reply]

On List of countries by GDP (PPP), I noticed that another reviewer had accepted a change that shouldn't have been accepted. I unaccepted the change and then rejected it myself. I want to notify the other reviewer of what I did and why, but the other reviewer's acceptance disappeared from the normal page history (after I unaccepted & rejected the change) and I can't find a record of the fact that the other reviewer touched the page at all. It doesn't show up in the other reviewer's contribs. Where can I find that record? Regards, Orange Suede Sofa (talk) 19:05, 3 May 2013 (UTC)[reply]

Um. The Pending changes log is at (curiously) Special:Log/stable; input the article name in the "Target (title or User:username for user):" window, like this. However, I don't think that's what you're after. --Redrose64 (talk) 19:22, 3 May 2013 (UTC)[reply]

My bad. I've updated the section title accordingly. What I'm after is an audit trail of the pending changes and their acceptances/rejections, so that I can find a complete record of the situation I described above. Regards, Orange Suede Sofa (talk) 19:29, 3 May 2013 (UTC)[reply]

(edit conflict) Worked it out. You want the "Review log", Special:Log/review. Near upper right of the article you should see a little box showing "Accepted (latest)" with a down arrow after it. Hover over that arrow and a further box appears; click the word "accepted". --Redrose64 (talk) 19:32, 3 May 2013 (UTC)[reply]

That's exactly it. Thank you! Orange Suede Sofa (talk) 19:36, 3 May 2013 (UTC)[reply]

Hiding the BLP editnotice

Can someone help me figure out how to hide the BLP editnotice? As I edit pages using a magnified page view, it really takes up a disproportionate percentage of my screen. It should be possible to hide it using either CSS or JS (I think), but I can't quite figure out how to do either. Thanks! – Philosopher ^{Let us reason together.} 19:51, 3 May 2013 (UTC)[reply]

For reference, the editnotice template is at Template:BLP editintro and is placed on the edit screen by MediaWiki:Common.js. – Philosopher ^{Let us reason together.} 19:54, 3 May 2013 (UTC)[reply]

Yep, putting .editnotice_BLP_editintro{display:none;} into your CSS page should do the trick. Writ Keeper ⚇♔ 19:58, 3 May 2013 (UTC)[reply]

Your name seems to keep showing up on my userscript pages. Thanks again! – Philosopher ^{Let us reason together.} 20:09, 3 May 2013 (UTC)[reply]

Generally speaking, if you know where the message comes from - and you've already worked out that it's Template:BLP editintro - look inside that for a class=value that encompasses the whole message; in this case we have <div class="editnotice_BLP_editintro">. The CSS to use is the name of the class, minus any quotes, preceded by a period and followed by {display:none;} which gives

.editnotice_BLP_editintro { display:none; }

Some messages have an id=value instead of a class=value and for these, the technique is almost the same, except that you begin with a hash # instead of a period . --Redrose64 (talk) 20:32, 3 May 2013 (UTC)[reply]

I look at the html source of the rendered page to find such things. That can also work when you don't know where it comes from. Indeed, the html source says <div class="editnotice_BLP_editintro">. PrimeHunter (talk) 20:41, 3 May 2013 (UTC)[reply]

Yeah, that's what I do (and did above). Right-click on it and select "inspect element" (if you're in Chrome; I use Firefox, so I get a similar thing through the Firebug extension). Writ Keeper ⚇♔ 20:43, 3 May 2013 (UTC)[reply]

I often use a magnified page view too. My User:Bgwhite/vector.css has options to remove alot of the "distractions" to give me more room. There are comments to say what each option does. I also use User:PleaseStand/hide-vector-sidebar.js in my vector.js file to remove the left sidebar. A tab option is placed at the top so you can access the sidebar when needed. Bgwhite (talk) 21:36, 3 May 2013 (UTC)[reply]

Thanks, everyone! I did find the class element, but wasn't sure what to do with it. Now I've got a (semi-permanent) reminder on my page in this script. Awesome!

@BGwhite: I'll take a look at those, thanks for pointing them out! – Philosopher ^{Let us reason together.} 22:23, 3 May 2013 (UTC)[reply]

...and now my User:Philosopher/common.css and User:Philosopher/common.js are both longer and the 'pedia is more easily editable.

– Philosopher ^{Let us reason together.} 22:58, 3 May 2013 (UTC)[reply]

Firefox has an inbuilt element inspector, which is IMO the best out there. Right-click and "Inspect element" or Alt+Q. — TORTOISE WRATH —Preceding undated comment added 01:39, 4 May 2013 (UTC)[reply]

Yeah, but in the change from v19 to v20 certain aspects of it were altered and sometimes it's more difficult to find what you want. The worst is that the pane on the lower left (where the "source" is displayed) sometimes doesn't show the line being inspected, but the very top of the page - the <html> tag, <head>...</head> element and <body> tag, followed by some <div>...</div>s. Other negative changes include the pane which shows how the styles were determined: it used to be full-height, now it's crammed into the corner and a lot of scrolling is needed. The only positive I've found so far is the "box model" tab.

I didn't mention the "inspect element" feature before, because not all browsers have it, and for those that do, it varies widely. I perhaps should have mentioned "View source", since all major browsers have it; but it can be daunting for somebody unused to HTML. --Redrose64 (talk) 07:54, 4 May 2013 (UTC)[reply]

I completely agree; I noticed these negative changes, too, but I forgot about them since v20 (I'm on the nightly channel, so it's been a few months for me since the change). I still think it's the best one available, just not as good as it used to be. It's a shame that nobody seems to have made an extension to get the v19 one back. — TORTOISE WRATH 00:38, 5 May 2013 (UTC)[reply]

Wikidata items on article

Hello. In greek wikipedia we can enable (at preferences) to show items from Wikidata, under the title of a page. How can Ι enable this in english WP? I can't find it. Thx. Xaris333 (talk) 01:30, 4 May 2013 (UTC)[reply]

You can enable that by adding the following code to your common.js, or request to add the tool as an gadget. As far as I know, it is not enabled as an gadget on enwiki.

// [[d:User:Yair rand/WikidataInfo.js]]
importScriptURI("//www.wikidata.org/w/index.php?title=User:Yair rand/WikidataInfo.js&action=raw&ctype=text/javascript");

--Snaevar (talk) 01:41, 4 May 2013 (UTC)[reply]

Couldn't do it. Can you help? My commons.js in my page. Xaris333 (talk) 13:07, 4 May 2013 (UTC)[reply]

Yes, I can help. The code needs to be at the bottom of your common.js file, below the bracket and semicolon - };, not above it like you did. So, the bottom of your common.js should look like so:

    'listOfUnavailablePagesOn': 'List of not available pages on'
};

// [[d:User:Yair rand/WikidataInfo.js]]
importScriptURI("//www.wikidata.org/w/index.php?title=User:Yair rand/WikidataInfo.js&action=raw&ctype=text/javascript");

--Snaevar (talk) 18:26, 4 May 2013 (UTC)[reply]

Thx! Xaris333 (talk) 18:57, 4 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? — TORTOISE WRATH 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]

Searching for string literals containing non-alphanumeric characters

Are there any tools that can be used to perform a full-text search for a string containing non-alphanumeric characters. Say, hypothetically, I wanted a list of all pages in mainspace containing the string !!. Doing this doesn't work, for understandable reasons; grep only searches page titles. This would be equivalent to the pseudo-SQL SELECT * FROM `pages` WHERE `namespace`="(Article)" AND (`body` LIKE "%!!%" OR `title` LIKE "%!!%"), but performing direct SQL queries on the Wikimedia servers is something I predict only Jimbo is allowed to do. — TORTOISE WRATH 03:43, 4 May 2013 (UTC)[reply]

The only method I know of is to download your own copy of Wikipedia's text and then to scan it with the AWB Database scanner. Alternatively, drop a note on my talk page and I could run a search for you in my copy (a snapshot from 4th April). -- John of Reading (talk) 05:50, 4 May 2013 (UTC)[reply]

Watch tab star

Hi - since switching to Vector recently, I've noticed there seems to be no rhyme or reason to the watch/unwatch tab at the top of the page. Sometimes it's written in text, sometimes as a filled or hollow star. It doesn't seem to be namespace specific, nor (as I first suspected) is it browser dependent (a lot of my browsing is done on a clapped out IE7 PC which I can't upgrade). Does everyone get this? Is there any reason for the inconsistency, and is there any css/js tweak I can do to make it appear the same way? An optimist on the run! 06:58, 4 May 2013 (UTC)[reply]

In your vector.js you have a script $('#ca-watch').removeClass('icon'); to remove the icon. However, it can only do this after the page has fully loaded, which can take a while. That explains the inconsistent result you are observing. —TheDJ (talk • contribs) 07:06, 4 May 2013 (UTC)[reply]

I should have thought of that - thanks. An optimist on the run! 07:58, 4 May 2013 (UTC)[reply]

I only get the star, never text. I'm using Firefox 23 on Windows 7. — TORTOISE WRATH 17:03, 4 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]

Move page

I made an error when i moved a page from User:Edinburgh Wanderer/2013–14 Partick Thistle F.C. season and ended up at Edinburgh Wanderer/2013–14 Partick Thistle F.C. season. I then tried to move it to the correct page 2013–14 Partick Thistle F.C. season and got a database error. The database error created 2013–14 Partick Thistle F.C. season but as a redirect to Edinburgh Wanderer/2013–14 Partick Thistle F.C. season i.e not moving the page. Need an admin to fix it and not sure what caused the database error.Blethering Scot 22:34, 4 May 2013 (UTC)[reply]

Fixed. PrimeHunter (talk) 22:43, 4 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. — TORTOISE WRATH 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]

Edit links on Commons files

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]

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? — TORTOISE WRATH 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? — TORTOISE WRATH 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]
  - I was using the new NewPagesFeed and I got quite I large bar menu on the right. I have JavaScript on.--Gilderien Chat|List of good deeds 23:08, 5 May 2013 (UTC)[reply]
    - Mm, yeah, that's Page Curation (or some variant thereof) I believe. I don't use that. See if there's a link that says [Mark this page as patrolled] when you click on an unpatrolled page from Special:NewPages. Ignatzmice•talk 23:14, 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]

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

Can someone please create a gadget to fix this? Werieth (talk) 19:57, 6 May 2013 (UTC)[reply]
- To fix what exactly? — Edokter (talk) — 19:58, 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]

Put it back please. There's no reason at all given for this change, and it makes no sense at all. The edit link is lost where it is now, is much more difficult to find, and is creating a net negative user experience. Nobody complained about it being in a nice consistent place on each line before. Change for the sake of change is offensive. Risker (talk) 23:21, 6 May 2013 (UTC)[reply]
- "Why this is changing" section on the Meta documentation linked to above is probably what you're seeking. Steven Walling (WMF) • talk 23:25, 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.[3] 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[4], 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. 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. Reso lute 03:40, 7 May 2013 (UTC)[reply]

Three things:

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

[From Wikipedia talk:Notifications:] Oh hold on now....why is the section edit link not over at the far right anymore?

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]

See Wikipedia:Village pump (technical)#edit moved. Easy fix: insert span.mw-editsection { float:right; } in your common.css page. Ignatzmice•talk 23:08, 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]

This is, as Steven says, completely unrelated to Notifications. Okeyes (WMF) (talk) 23:26, 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. Reso lute 13:27, 7 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]

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]

Not me, sorry. Ignatzmice•talk 19:56, 6 May 2013 (UTC)[reply]
Nope. ~ Amory (u • t • c) 20:04, 6 May 2013 (UTC)[reply]
Inaccessible to me too. --Roberto Segnali all'Indiano 21:11, 6 May 2013 (UTC)[reply]
I'm having the same problem. The regular version works fine, but the HTTPS version times out (which is kind of a pain when you have http=>https rewrite rules in effect in your browser). Kolbasz (talk) 21:47, 6 May 2013 (UTC)[reply]
- http://status.wikimedia.org/ says it's working. Steven Walling (WMF) • talk 23:14, 6 May 2013 (UTC)[reply]
  - It just came back up. Let's hope it stays that way. Kolbasz (talk) 14:06, 7 May 2013 (UTC)[reply]
Works fine for me. I'm on it right now — TORTOISE WRATH 23:47, 6 May 2013 (UTC)[reply]
Not working here in the UK. Gilerian and Roberto both appear to be in Europe (not working) whereas Tortoise (working) seems to be in the US. Also seems to be slower than it used to be. Martin451 (talk) 00:01, 7 May 2013 (UTC)[reply]
- https:// works for me too. Routing information etc. and trying with a different internet provider first is very welcome. --AKlapper (WMF) (talk) 08:48, 7 May 2013 (UTC)[reply]
Down for me, too -- https://91.198.174.225 timeouts.
Judging by Special:Contributions/Amalthea (bot) since 18:10 UTC yesterday. :/
Amalthea2 (talk) 13:09, 7 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]

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 \sqrt þ same)$ $\sqrt d isease$ 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]

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]

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

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.

BBC News - OpenDyslexic font gains ground with help of Instapaper

—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;}

— TORTOISE WRATH 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]

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

the basic version of the ImprovedUploadForm as it can be seen on Commons:Special:Upload?uploadformstyle=basic or
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]

Namespace numbers

Wikipedia data structure
v
t
e
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
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 (API call)

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]

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]

Add span.mw-editsection { float:right; } to you common CSS file. Ignatzmice•talk 11:48, 8 May 2013 (UTC)[reply]
- This could really do with being made a preference rather than requiring editing of css files. Thryduulf (talk) 12:27, 8 May 2013 (UTC)[reply]
  - Okay, then! Is it possible to have a CSS-only gadget, or do you need the JavaScript as well? If you really felt like doing it, you could head over to wp:Gadget to see how—all you'd need is that one line of code. Though technically there ought to be discussion there, and it's true that the Gadget section of the preferences is getting rather full... Ignatzmice•talk 12:37, 8 May 2013 (UTC)[reply]
    - Well the CSS edit works now, thanks Ignatz. Is there a page with a list of CSS edits that this could be added to if the gadget section is too full? CMD (talk) 12:45, 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]

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]