Wikipedia:Village pump (technical)/Archive 113

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (technical) archive  

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

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

adding thumbnails (namely thumbnails of flags) to a section

Hi, I am trying to add a thumbnail flag to a section for which the text is already written.

I have browsed the help section "adding images", but could not find anything relevant to my problem.

Does someone knows where I can find it?

Thanks for your help.

Regards. — Preceding unsigned comment added by Kimuzukashiineko (talk • contribs) 07:28, 3 June 2013 (UTC)

You can write {{flag|India}} to get India. If you want the flag only, you can use {{flagicon|India}} → .—Emil J. 15:27, 4 June 2013 (UTC)

Be careful. Use of flags is becoming less popular because of the political issues they raise. See MOS:FLAG. —[AlanM1(talk)]— 01:23, 10 June 2013 (UTC)

kml option has stopped working

The {kml} option, which normally shows a number of pins representing geographical features overlaid on google maps, appears to have stopped working. I have tried the ones on River Welland, Huddersfield Broad Canal and River Don Navigation and all now report "No geocoded items found", and show a google map of the whole world. Is this the right place to report this. I cannot find anywhere else to do so. Regards. Bob1960evens (talk) 14:46, 6 June 2013 (UTC)

It now appears to be working again. Bob1960evens (talk) 22:01, 9 June 2013 (UTC)

A proposal to solve the problem with unequal height of rows

I propose to change the flagicon size from default 22x20 pixels to 24x15 pixels in the fully protected Template:Flagicon/core.

Default flagicon size 22x20 pix maximum

Italy	22x15
Spain	22x15
Switzerland	20x20
France	22x15
Belgium	22x15
Nepal	20x20
China	22x15
Vatican City	20x20
United Kingdom	22x11
Australia	22x11
Canada	22x11
Cuba	22x11

Flagicons with proposed size 24x15 pix maximum

Italy	23x15
Spain	23x15
Switzerland	15x15
France	23x15
Belgium	23x15
Nepal	15x15
China	23x15
Vatican City	15x15
United Kingdom	24x12
Australia	24x12
Canada	24x12
Cuba	24x12

So, as you can see on this example, the first table looks ugly because of oversized flags of Switzerland, Nepal and Vatican. Please post your remarks on the talk page Wikipedia talk:WikiProject Flag Template. Thanks. Maiō T. (talk) 13:50, 9 June 2013 (UTC)

Are thousands of people a day not finding the articles they want?

Over at WP:Topred, which lists the most popular weekly redlinks, there are a lot of entries with complicated and repeated codes. For example, the current #13 is Michael Bubl\xC3\xA9, with 19,135 hits. Is this a likely result of 19,000+ attempted but failed human views of the article Michael Bublé? If so, is anyone aware of a technical solution, so that all articles with complicated characters, such as "é", can have redirects created for them? Thanks. Biosthmors (talk) 10:22, 9 June 2013 (UTC)

Those seem to be badly encoded URLs, probably originating from malformed links on some website(s). Not much we can do about that. — Edokter (talk) — 10:27, 9 June 2013 (UTC)

I do not think that creating thousands of redirects for cases like this and that is a right way, because they would become expensive to watch and complicated to maintain (especially in the case of a merge–unmerge cycle). If some definite pattern can be detected, such as these URLs with non-standard hexadecimal escapes, and there are substantiated expectation that it will persist, then developers should consider some URL rewrite built into the engine. If it is a glitch caused, say, by some version of a browser or some version of a CMS, which are expected to be fixed soon, then the right way is just ignore. It is not our problem. Incnis Mrsi (talk) 10:38, 9 June 2013 (UTC)

WP:Topred is currently dominated by entries containing \x. In the cases I examined, it was a percent encoding of a real title with each % incorrectly replaced by \x. For example, "Michael Bubl\xC3\xA9" in a url would be the incorrect http://en.wikipedia.org/wiki/Michael_Bubl\xC3\xA9 while the correct percent encoding is http://en.wikipedia.org/wiki/Michael_Bubl%C3%A9. The 12 May list [1] had no entries containing \x so it seems like a recent problem (some of the older lists had a limited number of \x entries). I agree it's too soon to think about creating redirects from the invalid encodings. PrimeHunter (talk) 11:21, 9 June 2013 (UTC)

As Incis hinted, this looks like a bug in code/script to in-line Wikipedia content (and perhaps the high numbers are caused by automatic re-attempts upon failure). What would be really interesting is to see if these redlink cases are being driven by a single or small set of IP addresses. While that would be fun, we shouldn't expect the analytics team to help us with this due to the privacy issues involved. Thanks, West.andrew.g (talk) 13:06, 9 June 2013 (UTC)

I've seen issues like this with Toolserver tools, but I can't reproduce it so far with Firefox 21 or MSIE 10. Maybe someone using an older version of MSIE could try the links with accented letters on http://toolserver.org/~dpl/ch/dab_challenge.php ? GoingBatty (talk) 17:30, 9 June 2013 (UTC)

Perhaps the referrers and user agents could be logged for a period, aggregated and anonymized (as well as culled of uniques)? That should give some hints as to the origin of the problem. Also, a temporary workaround could be employed using Javascript, similar to the case-sensitive fixer for some Wiktionary projects. If a browser ends up on a red title, and if the name includes some known bad encoding that can be repaired, and if a page with the correct encoding exists (via quick API call check), then (after a short delay) the location could be changed to the correct one. Eg: wikt:Dummy --Splarka (rant) 07:30, 10 June 2013 (UTC)

Passing a location to Special:Nearby?

Tracked in Phabricator
Task T51413

At the end of this discussion, an editor suggested the ability to pass an arbitrary location to Special:Nearby. I'd like this as well, because if I'm going to a particular area, I'd like to see if any nearby articles need pictures. I read about some of the workarounds in the previous discussion but they are either cumbersome off-wiki approaches (Marble) or not sufficiently helpful (querying the server directly and getting raw XML back). Regards, Orange Suede Sofa (talk) 00:22, 10 June 2013 (UTC)

If you have Firefox then you could try https://addons.mozilla.org/en-us/firefox/addon/geolocater/ to set a location in the browser. I haven't tried it. PrimeHunter (talk) 00:57, 10 June 2013 (UTC)

i like the idea of allowing passing location to nearby (e.g. "Special:NearBy/44.12,-71.13"), which does not depend on browser at all. we could use such links in portals, on wikivoyage, and more. however, i think it makes more sense to post such a suggestion in mw:Mobile design rather than on enwiki's en:WP:VPT ... peace - קיפודנחש (aka kipod) (talk) 14:54, 10 June 2013 (UTC)

The suggestion was the first response at https://blog.wikimedia.org/2013/05/29/wikipedia-nearby-beta/. The Mobile Software Engineer Jon Robson replied: "Currently there is no option to manually insert a location but it would be trivial to add this functionality. The main complication around doing this is the design Ideally we hope to integrate a map feature in future which would make it easy to drop a pin and see nearby articles. It doesn’t really make sense to allow users to enter a longitude and latitude coordinate as these are not very human friendly :)".

IMHO, that is a poor reason to reject something that would be trivial to add. Allowing users to enter longitude and latitude would be a vast improvement over nothing, especially assuming it can be done with e.g. "Special:NearBy/44.12,-71.13" so various tools can generate a clickable link. PrimeHunter (talk) 15:47, 10 June 2013 (UTC)

I agree with PrimeHunter, especially as Jon said "it would be trivial." Is there a bugzilla? Theopolisme (talk) 15:52, 10 June 2013 (UTC)

esp. since it's not just about users adding the coords manually - this should be done in a way that will allow creating internal links to "nearby"'s, e.g. by using a link in the form "Special:Nearby/coords", which should work even when the device/browser can't/won't allow sending its coordinates. peace - קיפודנחש (aka kipod) (talk) 16:29, 10 June 2013 (UTC)

Raise a bug to make sure this doesn't get lost. I should have been clear. The bit that is trivial is allowing user input. The bit that isn't is how you present that information. It requires a lot of discussion around how it can be queried and what the expected behaviour is when it is queried. For instance if I pass in a geo coordinate what does refresh do? If I pass in a geo coordinate how do I know I'm looking at things near that geo coordinate rather than things nearby? All these design considerations need attention - otherwise we risk the danger of someone thinking they are looking at articles nearby which are actually articles near somewhere completely different and people thinking they are looking at something broken. Jdlrobson (talk) 21:06, 10 June 2013 (UTC)

I've logged a bug at bugzilla:49413. – PartTimeGnome (talk | contribs) 21:41, 10 June 2013 (UTC)

Yes! It would be great if tools like GeoHack could have links to Special:Nearby.

Regarding concerns that entering a longitude and latitude isn't user friendly, how about allowing entry of any article name where the article has geodata? Users could then enter the name of a town (or nearest notable location) rather than having to look up the coordinates themselves. – PartTimeGnome (talk | contribs) 21:17, 10 June 2013 (UTC)

For articles that have coords registered, another option could be to add a link from the standard left-hand "Toolbox" links-- "What's nearby" or similar. Regards, Orange Suede Sofa (talk) 21:26, 10 June 2013 (UTC)

That's another great idea! – PartTimeGnome (talk | contribs) 21:41, 10 June 2013 (UTC)

Watchlist Notifications

Hello, I have left a proposal for a short message to placed on everyone's watchlist next week here which needs approval.--Dom497 (talk) 00:08, 11 June 2013 (UTC)

Tests show "section=new" has edit-conflict

(edit conflict) I have begun discussions about fixing simple edit-conflicts in the several related Bugzilla reports from 2006-2010-2013. Meanwhile, in running tests, I have confirmed that using "section=new" does not reduce edit-conflicts, so if a user intended to reply in a bottom section and also append a new section, then just do both as a bottom-section edit (plus "==Next=="), rather than a separate "section=new". In fact the "section=new" operation also caused an edit-conflict for a later reply in the "penultimate" section, because when adding a "section=new" then the next-to-bottom section also hit edit-conflict, even when separated by a 3-line section between them. From reading the implementation discussions, the software has a function to "append at end of page" (with no comparison of changes), but that still causes the 2nd editor to hit edit-conflict, after a pure append of new text at page bottom. I'll work with Bugzilla to see if the "section=new" operation can be fixed to not edit-conflict against changes to the bottom 2 sections, but in the meantime, beware changing either of the bottom 2 sections of a page could hit edit-conflict after a recent "section=new" addition. If a Show-changes reveals a new "==Header==" at bottom, then beware a conflict. -Wikid77 (talk) 09:14, 11 June 2013 (UTC)

For reference, section editing doesn't really do anything special. We just put it all through GNU diff3, at let that program sort it out. Bawolff (talk) 19:29, 11 June 2013 (UTC)

Thanks for confirming that, as it explains why the edit-conflicts are much the same after all these years, using diff3 as a black box tool and not improving the merge algorithm inside it. I assume it still re-syncs the differences after insert/delete only when the successive entire lines match, rather than resync on lines with the same prefix or suffix text. One possible path forward would be to write a variation of diff3 for talk-page edit-merges, rewritten to allow close-merging of adjacent lines perhaps called "diff3near" which would stack new additions, together, when seeking to resync at the common lines after the merged lines. Currently, diff3 is like a sledge hammer to ensure handling all nail sizes, when a diff3near could be like a tap hammer to easily handle the "small nails" in talk-pages without getting "nail-conflict" to separate small nails near each other. Talk-pages (and many articles) need a more-refined, 3-version merge tool which treats adjacent lines (or phrases) as typical edit-collaborations, not edit-conflicts. Editing is currently just fine, as long as people do not imagine working together, during the same minutes, on revising the same paragraph! -Wikid77 00:04, 12 June 2013 (UTC)

Article feedback on the main page

Is that intentional? If it is, what is the point? -- Toshio Yamaguchi 11:02, 11 June 2013 (UTC)

Feedback on the Main Page?

I just noticed a "reader comments" feedback link on the Main Page; it goes here, and there's just one small comment. Since when is feedback enabled on the Main Page, and why? Nyttend (talk) 21:45, 11 June 2013 (UTC)

I suspect that this edit may be related; but it occurred in between the above two comments. --Redrose64 (talk) 21:59, 11 June 2013 (UTC)

When a bot edits one of my pages,

I don't receive an eMail notification despite having set in my preferences to receive notifications by eMail. I have previously alerted Meno25 to this as it's his bot that placing maintenance templates across my pages and he has brung me here. Any idea what's going on?--Launchballer 17:10, 11 June 2013 (UTC)

Hello Launchballer, is the bot in question listed on MediaWiki:Echo-blacklist? Technical 13 (talk) 17:20, 11 June 2013 (UTC)

No Technical 13, it isn't; it's MenoBot II.--Launchballer 17:24, 11 June 2013 (UTC)

Okay, Launchballer, then next question is if you get any emails at all from anyone. The way that the system currently works is that you only get one email per page no matter how many subsequent edits are done to that page until you go to the history of that page and view the changes. If you read down through the email messages that you get from editors, you should find something like:

There will be no other notifications in case of further activity unless
you visit this page. You could also reset the notification flags for all
your watched pages on your watchlist.

            Your friendly MediaWiki notification system

Unless I am mistaken, it uses the same logic as bolding on your watchlist. If you log in and look at your watchlist you should see a bunch of bold items or items with funky green bullets as opposed to the normal pastel blue ones. You will not receive an email for any of those pages as long as they are noted as being not visited. I'm assuming that this is the trouble you are having. There is no way that I am aware of to get an email for every edit regardless of whether or not you have viewed the differences. It may be worth submitting a bugzilla ticket to have that option. Technical 13 (talk) 17:38, 11 June 2013 (UTC)

That makes some sense, but I have set it to get an eMail for each edit. We are dealing with edits that have occurred by bots immediately after I created the article (see All I See (A+ song) for an example that I did not receive an eMail for).--Launchballer 17:56, 11 June 2013 (UTC)

The new Notifications isn't involved in this.

1) Under Preferenes->User Profile, at the very bottom, there is the option "Email me when a page or file on my watchlist is changed". This has to be checked. You will only get an email when your watchlist has changed.

2) The edit to All I See (A+ song), was done by a bot and was labeled as a minor edit. Under Preferences->Watchlist, you must NOT HAVE "Hide bot edits from the watchlist" and "Hide my edits from the watchlist" checked. If you have one of these checked, your watchlist will not be updated, thus you will not receive an email. Bgwhite (talk) 18:18, 11 June 2013 (UTC)

I think Bgwhite meant "Hide minor edits from the watchlist" must not be checked, rather than "my edits". – PartTimeGnome (talk | contribs) 19:24, 11 June 2013 (UTC)

I kind of guessed that was intended. Neither of them are checked. The top six are unchecked, while the bottom four (below the watchlist token) are checked.--Launchballer 20:00, 11 June 2013 (UTC)

Pywikipedia

I've been trying to download PyWikipediaBot at here, but I'm getting the "Connection has timed out" box. All other sites are working fine. Ypnypn (talk) 20:09, 11 June 2013 (UTC)

Download it here instead. Cheers, Theopolisme (talk) 20:33, 11 June 2013 (UTC)

"Request Feedback" link in toolbox

I just noticed that the toolbox has a "Request feedback" link, but when I click it I'm sent to the protection screen. For example, clicking the link at Sandusky High School sends me to http://en.wikipedia.org/w/index.php?title=Sandusky_High_School&action=protect. (1) If you're a non-admin and click this line in the toolbox, do you get a "permission denied" type of message as if you click my Sandusky link? (2) What's the point of an additional link to the protection screen? (3) Why is this link called "request feedback" when it's not related? I mean, if I start using this link at lots of prominent pages, I'll start getting feedback all right, but not the type that would be expected from a "request feedback" link. Nyttend (talk) 23:46, 11 June 2013 (UTC)

My tests with alternative accounts show it's only a protect link in admin accounts. The admin options in the protection screen include to enable or disable feedback. In autoconfirmed non-admin accounts "Request feedback" leads to a feedback feature. For IP's and non-autoconfirmed accounts there is no "Request feedback". PrimeHunter (talk) 00:26, 12 June 2013 (UTC)

New feature: a quick way to say "thanks" for an edit

A Thanks notification.

Hi folks, we wanted to let you know that we just released a new feature today: the Thanks notification offers a new way to give positive feedback on Wikipedia.

This experimental feature lets editors send a private 'Thank you' notification to users who make useful edits -- by clicking a small 'thank' link on their history or diff page, as described on this overview page. The purpose of this Thanks notification is to give quick positive feedback to recognize productive contributions.

We hope that it will make it easier to show appreciation for each other's work -- and it should be particularly helpful for encouraging new users during their first critical steps on Wikipedia. We have intentionally kept this notification as simple as possible, so we can evaluate it and improve it together.

Once you have had a chance to try it out, we welcome your feedback about this feature, and look forward to a healthy discussion on this talk page. (And if you do not want to thank others or be thanked, you can easily disable this notification in your preferences, as described here.)

Many thanks to all the community members who helped us test this feature in recent weeks. We hope the rest of you will find it helpful as well. Enjoy! Fabrice Florin (WMF) (talk) 01:09, 31 May 2013 (UTC)

I misclicked twice there today, as the last link of that portion has been "undo" so far. I wanted to undo and most probably they have got "thanks"! It seems Wikimedia is working on "implement first and inform later" basis! --Tito Dutta (contact) 01:19, 31 May 2013 (UTC)

I'm confused; we sent out notifications several days ago about it, one of them here. Okeyes (WMF) (talk) 11:13, 31 May 2013 (UTC)

Well, If that was the case, at least I overlooked the notification. I was surprised by the new "Thank" functionality. --Patrick87 (talk) 11:35, 31 May 2013 (UTC)

Yes, I also think the button is placed badly. I left a comment on the talk page. --Patrick87 (talk) 02:19, 31 May 2013 (UTC)

Not sure if I missed something but I cannot access this feature no do I see any instructions on how to turn it on. Kumioko (talk) 01:57, 31 May 2013 (UTC)

@Kumioko: Is "Exclude me from feature experiments" checked for you at Special:Preferences#mw-prefsection-rendering? If so, you need to uncheck it to see the "thanks" link. Theopolisme (talk) 03:02, 31 May 2013 (UTC)

No its not, I thought that too. I also tried IE and Firefox, I tried checking the exclude option and then unchecking it again. Maybe its hiding in the same place as my Green bullet? :-) I don't have that either. Kumioko (talk) 03:06, 31 May 2013 (UTC)

Are you looking at contribs? It seems it only works when viewing page histories or diffs, not on watchlists or contribs pages. Beeblebrox (talk) 04:17, 31 May 2013 (UTC)

Alas, I have accidentally thanked someone I wished to 'undo' this morning. Fortunately it was only an experimental edit, but I surely did not mean to thank them. I did my revert afterwards, but there seems to be no way to undo my thanks. They are registered, so perhaps they will be a better editor because of my goof. This seems badly placed (exactly where 'undo used to be). Either that or I can't edit until after I am more caffeinated. Sheesh! (Again I was behind the door when this was passed out...) Fylbecatulous talk 10:10, 31 May 2013 (UTC)

I too have left a gentle message on their talk page (sigh) Fylbecatulous talk 10:19, 31 May 2013 (UTC)

I've just done the same, as it was removing a CSD tag it probably looks sarcastic! There should be an 'undo thanks' option that appears to replace the 'thanks' option. GiantSnowman 10:29, 31 May 2013 (UTC)

A feature like this should require a confirmation step, just like the "undo" button it is unfortunately next to. Hullaballoo Wolfowitz (talk) 10:38, 31 May 2013 (UTC)

Yes, it should definitely not be a one-click option. GiantSnowman 10:45, 31 May 2013 (UTC)

Good feature, expect I will use it a lot, but do need some way to handle misclicks though. Personally I'd prefer not to have to confirm each Thanks, since it would be two clicks for one minor job. The ability to undo the Thanks for some seconds afterwards might be enough. Rjwilmsi 11:03, 31 May 2013 (UTC)

Probably a pain to code, however, but I'll run it past people :). Okeyes (WMF) (talk) 11:13, 31 May 2013 (UTC)

You sound pretty silly suggesting that two clicks would be a burden. :-) --MZMcBride (talk) 13:49, 31 May 2013 (UTC)

I don't think it sounds that silly if a person is ambitious about using the feature and is very active in the community... I could see someone thanking a couple dozen people for certain contributions a day so it is not as much two clicks as it is 50 clicks vs 25 clicks... They add up... I think the users was asking for a feature similar to Google calendar that has a little javascript popup (just like the one you use for "your edit has been saved") that would allow them to quickly retract their "thank" if it was a misclick. Technical 13 (talk) 13:55, 31 May 2013 (UTC)

Good feature- but the icon, a little heart in Barbie Doll pink, I can imagine what the reaction of many of the editors I would like to thank would think of that. Thanks, you are a diamond, thanks for the spadework, thanks for clubbing that ip-editor on the head. Would it take much code to allow me to set an icon in my preferences that matches my malevolent personality? -- Clem Rutter (talk) 11:59, 31 May 2013 (UTC)

For anyone interested, there's an open bug here regarding the Thanks workflow: bugzilla:47658. --MZMcBride (talk) 13:51, 31 May 2013 (UTC)

Any way to view a list of the thanks you've gotten? - Amaury (talk) 23:30, 31 May 2013 (UTC)

@Amaury: Yep, just go here. Theopolisme (talk) 23:31, 31 May 2013 (UTC)

MOVE the button

Twice(!) today, I accidentally clicked "Thank" instead of "Undo" on a diff page. The button is on the wrong place; it should not be listed after the page action links, but next to the user action link on the next line. — Edokter (talk) — 12:14, 2 June 2013 (UTC)

I don't see how people never had issues clicking (undo) when they were trying to (edit) or visa-versa... The (thank) is for that edit, but if you want it on the next line and aren't opposed to some js bloat, I could add it into my User:Technical 13/Scripts/NoThanks.js script... It won't be today, but I can probably finish up that script and get it in there by Tuesday. Technical 13 (talk) 12:28, 2 June 2013 (UTC)

It's because we are used to pressing 'undo' as the button furthest to the right, a place now occupied by the 'thank' button. This entire thing has been very poorly thought out. GiantSnowman 12:37, 2 June 2013 (UTC)

If that is it, the logical thing would be to put (thank) in the middle so that it isn't the furthest to the right or left... Anyways... If moving it down a line is a wanted feature, I'll add it, otherwise I'm not wasting time on it. Technical 13 (talk) 12:50, 2 June 2013 (UTC)

This has been an issue for twinkle/friendly users for ages. It's nothing new, we just expanded the group that encounters it a bit further. The central problem here is that our history, contributions, RC, diff etc pages are really poorly thought out in terms of UI. I'd love to see someone do some design work on that. —TheDJ (talk • contribs) 16:57, 2 June 2013 (UTC)

I've actually written some code for removal of the block and rollback interfaces as well, and I would be happy to take some time when I have it (this week is really busy with school, summer semester is always the toughest) to re-work my code and make a script that will re-locate "stuffs" in a more user friendly fashion and upon completion of that I would be happy to make note of it (screenshot or whatever of the output) on Bugzilla and get the layout put directly into the core. To do this, I need community input as to what it "should" look like. Technical 13 (talk) 17:30, 2 June 2013 (UTC)

I don't think we need to move the button - we need to make it so that it's 2 clicks. GiantSnowman 17:34, 2 June 2013 (UTC)

Tracked in Phabricator
Task T49658

I think that two clicks for something so simple that some users may actually intend to use to thank for 25-40 edits a day is too much... That being said, I'm not opposed (as mentioned on the related bugzilla) to having it so that when you click (thank) instead of it changing to (thanked) that it instead changes to (un-thank) or (de-thank) allowing you to undo it if it wasn't intentional. Technical 13 (talk) 17:57, 2 June 2013 (UTC)

The reason why clicking "edit" when you mean "undo" (or vice versa) is not an issue is because both require you to click another button before anything is saved. If you clicked the wrong one you can click your browser's "Back" button then click the one you meant. – PartTimeGnome (talk | contribs) 00:36, 3 June 2013 (UTC)

• Hi everyone, thank you so much for all your helpful feedback about the Thanks feature! We have reviewed all the comments from a variety of channels and have started to discuss and prioritize feature requests, based on your suggestions. Over a dozen people have reported issues with the thanks link, which has caused some to accidentally click "thank" instead of "undo" on history and diff pages. We are now working on this issue as our top priority, as it appears that the current placement next to undo is problematic, as well as the lack of a confirmation or 'unthank' function. To help us solve this issue quickly, we would be grateful if you could answer a few questions, so we can pinpoint the problem more accurately -- and develop an appropriate solution in coming days. To keep our discussion focused in one place, we have posted these questions and a feature update on this Thanks talk page, and encourage you to post your answers on that thread. Thanks again for all your good insights! Fabrice Florin (WMF) (talk) 20:44, 5 June 2013 (UTC)
  • Hi Fabrice. As an intermediate solution, can we at least swap the positions of the "Undo" and "Thank" links? That should dramatically decrease the likelyhood of clicking Thanks by accident, as we all expect the Undo link at the right most position. — Edokter (talk) — 16:05, 8 June 2013 (UTC)
    • OK, your idea is nice, your workaround put (without any previous discussion) into common.css is just unacceptable. Now the link is green! Not only that links are supposed to be blue with default settings, now it also looks like the "updated since my last visit" messages and messes up my experience with history pages completely! --Patrick87 (talk) 17:18, 8 June 2013 (UTC)

Time limit for thanks

Just wondering if there should be a time limit on thanks. I just got thanked for an edit I did in 2009. -- WOSlinker (talk) 18:12, 8 June 2013 (UTC)

I don't see a problem with that. Helder 18:48, 8 June 2013 (UTC)

Better late than never! GiantSnowman 10:49, 11 June 2013 (UTC)

Suggestion about the icon

I'm ambivalent about the heart icon associated with the thanks notice. To me, it connotes "love" (as in a valentine) more than "thanks". Perhaps something like this: would be better. --Tryptofish (talk) 22:00, 12 June 2013 (UTC)

This is already discussed on Wikipedia talk:Notifications/Thanks#Change the i-love-you heart to something more neutral. A smiley was suggested and received positively. However there were some considerations on copyright. --Patrick87 (talk) 23:35, 12 June 2013 (UTC)

See http://www.unicode.org/charts/PDF/U1F600.pdf.

—Wavelength (talk) 23:59, 12 June 2013 (UTC)

Thanks. I'll comment there. --Tryptofish (talk) 00:25, 13 June 2013 (UTC)

Captcha

There's been an outbreak of trolling at the Reference desk lately, and this post on the Help desk made me suspect it's spreading. A quick archive search revealed at least one previous similar complaint here back in 2008; however, the problem then was caused by an unfortunate conjunction of two innocuous words. If two proper dictionary words are still required, I can't see how the current reported captcha could possibly have been produced, but I don't know for sure. Before I stop assuming good faith with our questioner, can anyone here look at the alleged captcha wording and tell me categorically whether or not the system could have generated it? - Karenjc 20:25, 6 June 2013 (UTC)

Don't bother - the latest contributions by Sawwooddoow (talk · contribs) show that this is another troll. -- John of Reading (talk) 20:32, 6 June 2013 (UTC)

Thanks. It looked like a duck, and sounded like a duck, but it was good to hear the quack. - Karenjc 16:57, 7 June 2013 (UTC)

I agree that looks like trolling, but for future reference, it is indeed two completely random English words. I've seen some that could be strange or offensive, and apparently so have other people... [2], [3], [4] Steven Walling (WMF) • talk 17:23, 7 June 2013 (UTC)

Well, gerrit:53124 has kinda been sitting there for a while now... Legoktm (talk) 01:14, 13 June 2013 (UTC)

How does "You have new messages" work?

How exactly does the You have new messages functionality work? Is there some kind of flag like visited since last change=false? I am asking this because I would like to know whether it would be possible to set that flag manually. An example: Say I get a message from another user. I log into my account and get the new messages notification. I then visit my talkpage and find that the issue is too complex to be dealt with at the moment. I would set the flag back to true, which would trigger the You have new messages message again. Is that possible? -- Toshio Yamaguchi 10:44, 11 June 2013 (UTC)

Not currently. It uses timestamps. There is a last viewed timestamp for when you read the page, and one for the last edit. If last edit newer than last viewed you have new messages. Werieth (talk) 12:37, 11 June 2013 (UTC)

:-( Helder 12:16, 12 June 2013 (UTC)

Tech news: 2013-24

Latest tech news from the Wikimedia technical community. Please inform other users about these changes.

Recent software changes

(Not all changes will affect you.)

• The latest version of MediaWiki (1.22/wmf6) was added to test wikis and MediaWiki.org on June 6, and to non-Wikipedia wikis on June 10. It will be enabled on all Wikipedias on June 13. [5]
• An alpha version of the VisualEditor was enabled on all Wikipedias on June 6. Please test it and report problems. [6]
• Several VisualEditor bugs have been fixed; users can now add, edit and remove categories using the editor's "Page settings" menu.
• Wikimedia error messages will no longer link to the #wikipedia IRC channel on Freenode. [7]
• The logo of 16 Wikipedias was changed to version 2.0 in a fourth group of updates. [8]
• A test instance of Wikidata is now available at test.wikidata.org. [9]
• Users can now patrol the first version of a newly created page if they visit it from Special:NewPages or Special:RecentChanges. [10]
• Translation pages will no longer include edit section links (bug #40713). [11]

Future software changes

• A report on mobile upload errors was published, and software changes to reduce their number will come soon. [12]
• A request for comments on updating MediaWiki to use RDFa version 1.1 was started on MediaWiki.org (Gerrit change #67608).

Tech news prepared by tech ambassadors and posted by Global message delivery • Contribute • Translate • Get help • Give feedback • Unsubscribe.

20:05, 11 June 2013 (UTC)

And Notifications and Thanks has been updated: Wikipedia_talk:Notifications#This_week.27s_update. —TheDJ (talk • contribs) 16:10, 12 June 2013 (UTC)

Afc proposal help?

Has anyone had a chance to test out the code listed above at #Proposed change to the Afc submission process? —Anne Delong (talk) 14:09, 12 June 2013 (UTC)

Is daily option working for notification emails?

It took me almost exactly a week to get an email about this revert, even though my notification preferences are set for "A daily summary of notifications" and I saw and clicked on the web-based notification within a couple hours of said revert. I did not change any notification preferences during that time.

Is this something I/we need to worry about? If this is a known issue, is it already documented anywhere? --SoledadKabocha (talk) 17:37, 12 June 2013 (UTC)

WT:Notifications might be a good place to bring this up. Theopolisme (talk) 20:18, 12 June 2013 (UTC)

template cite pmid

Hi, I have a problem with {{cite pmid}}, since yesterday, I saw that it doesn't display correct when it is a redirect to a Template:cite doi/some-id, as it can be seen in Leukoencephalopathy#References.

File:Cite pmid display error.png

screenshot

Any idea about what is happening? --Götz (talk) 21:00, 12 June 2013 (UTC)

A purge fixed Leukoencephalopathy#References. PrimeHunter (talk) 21:08, 12 June 2013 (UTC)

Interesting, now I understand, thanks! Götz (talk) 02:47, 13 June 2013 (UTC)

Wiki signup translation

Sorry for writing here. I'm from another wiki. We have a problem about translation on Special:UserLogin&type=signup. want to translate this line (Wikipedia is made by people like you., 4,255,469 articles, 126,229 recent contributors). but can't find those line in translatewiki.net. How Can i do ? Can anyone help me?--Aftab1995 (talk) 21:46, 12 June 2013 (UTC)

See the bottom of http://en.wikipedia.org/w/index.php?title=Special:UserLogin&type=signup&uselang=qqx for the names of the used MediaWiki namespace pages. The first is MediaWiki:createacct-benefit-heading. PrimeHunter (talk) 22:07, 12 June 2013 (UTC)

Request for import user right

I have asked to be granted the import user right so I can import some long-lost revisions into the Wikipedia database. Please see the discussion on the proposals village pump and add any comments there. Graham87 03:19, 13 June 2013 (UTC)

Status update no longer in contributions?

I used to see User:Vchimpanzee/Status in my contributions, and still do for earlier "edits", but today it's not there. That scared me but I checked my profile page and it's properly updated. Some days I forget to do it. Some days I turn off my computer and I'm still "online" for days. While I'm here, Is there a possible way to change that to "offline" just by the mere fact I'm no longer "signed in" once my computer is off? Or vice versa?— Vchimpanzee · talk · contributions · 20:32, 7 June 2013 (UTC)

I see your last update in both your contributions and the page history as 5 June at 18:09 (UTC). At present your user page says "Online", which matches what I see in the Status subpage.

It isn't possible for you to update the page when your computer is off. A bot running on another computer could do it if there was some mechanism to remotely check your computer is on (e.g. a program on your computer that stays in contact with the bot). However, this is a somewhat over-engineered solution. – PartTimeGnome (talk | contribs) 21:35, 7 June 2013 (UTC)

Why is my status update not in my contributions, then? And I am offline now after I submit as I have things to do.— Vchimpanzee · talk · contributions · 21:39, 7 June 2013 (UTC)

Wait, I don't show myself updating my status Wednesday. That's it.— Vchimpanzee · talk · contributions · 21:42, 7 June 2013 (UTC)

(edit conflict) When you log in to Wikipedia, a cookie is set on your computer. That cookie is sent back to Wikipedia whenever you request any page, or you send an edit. The only way that Wikipedia knows that you're logged in is if it receives that cookie along with the page request; so technically speaking, you're logged out all the time except for the few milliseconds that it takes to retrieve a page. --Redrose64 (talk) 21:47, 7 June 2013 (UTC)

It does sound like more trouble than it's worth, but I distinctly remember clicking on "offline" before I signed off the computer Monday and it's not in my contributions. Neither is my clicking on "online" today. It wasn't the last thing I did so it's not like I didn't wait long enough before turning off the computer.— Vchimpanzee · talk · contributions · 19:46, 12 June 2013 (UTC)

Whatever I did just now worked ... — Vchimpanzee · talk · contributions · 20:10, 12 June 2013 (UTC)

Those status changes aren't in the page history either. When you tried to go offline on Monday, the edit didn't save at all. When you tried to go online today your status was already online, so it was a null edit. Null edits are not saved in the database, so don't show in the page history or your contributions. I don't know why your "offline" status update didn't save.

Are you aware of losing any other edits, or is it just the status updates? If it's just the status updates, I'd suggest asking the author of the "user online" script you are using if they have any ideas. – PartTimeGnome (talk | contribs) 20:15, 12 June 2013 (UTC)

If you log out before you click on "Status: Online", I'm pretty sure that the status change won't be actioned, because it requires you to be logged in as yourself. It's possible to become logged out even if you didn't use the Log out link upper right, for example by telling your browser to clear cookies. --Redrose64 (talk) 21:19, 12 June 2013 (UTC)

You will need to be logged in for the script to update your status as the javascript dynamically edit the /status subpage based on your username. I've had a look at the script and it seems fine for me so I'd advise purging your cache and if it still doesn't work, try editing the subpage without the script ie. change the subpage to online or offline yourself and see if that works. CJ ^{Drop me a line! • Contribs} 09:16, 13 June 2013 (UTC)

Popups not working in page histories

Hi. I use Vector skin on IE8. Recently (I don't know when, but certainly today and yesterday), navigation popups stopped working for me when used in page histories. They still work fine elsewhere, including articles, talk pages and watchlist. Any ideas please? --Stfg (talk) 16:51, 12 June 2013 (UTC)

• Beware weekly updates to Wikipedia: As you probably know, the current plan is to update the MediaWiki software every Monday/Tuesday, and so beware the next weekly surprise. With a weekly update schedule, it is almost impossible to effectively announce the proposed changes, in a manner where part-time volunteers have time to process the scheduled impacts. It is perhaps not worth taking time to wonder about the latest problems, because next week, they will either break again or be eclipsed by other, more horrifying changes. I have already explained that "moving the brake pedal or steering wheel" on a weekly, daily, or hourly basis is very disruptive to operations. Each person needs to assess how much time to burn, each week, worrying about the rampant questionable changes. However, if you ever wondered how it feels to be a "lab mouse in a maze" where the paths might change every time.... -Wikid77 (talk) 20:16, 12 June 2013 (UTC)

I came here to ask a specific and civil question that may indicate a bug that could be fixed. I think I deserve not to be talked down to about software design management, which I actually do know something about. Now, anyone any ideas about the specific problem, please? --Stfg (talk) 21:14, 12 June 2013 (UTC)

Sorry, I was just checking to see if you wanted to spend much time analyzing this specific problem. -Wikid77 12:38, 13 June 2013 (UTC)

Oh I see. Sorry. Yes, I can spend time on it. Popups are very useful, and other editors may benefit if we can resolve it. --Stfg (talk) 12:58, 13 June 2013 (UTC)

I don't think Wikid77 intended to talk down to anyone. I think he just has a habit of writing tangentially related mini-essays around here. :-)

Does anything show up in your browser's error console when visiting a history page with pop-ups enabled? Can you provide a specific URL that isn't working (for debugging purposes)? It sounds like a selector may have gone missing or something, but it's difficult to say for sure right now. --MZMcBride (talk) 01:10, 13 June 2013 (UTC)

I installed pop-ups and they seem to work fine at <https://en.wikipedia.org/w/index.php?title=User_talk:MZMcBride&action=history&useskin=vector> for me. I'd missed that you're using IE8, though. Can you try another browser? That would help pinpoint this issue. IE8... well, you know. --MZMcBride (talk) 01:16, 13 June 2013 (UTC)

Hi MZMcBride. Thanks for your help. When I load your talk page history from the link above, the IE8 status bar says "Done" until I hover over a "prev" link. After doing that, the status bar says "Error on page" and the details file gives message that's I've copied into User:Stfg/Sandbox1. Does this help? I don't have any other browsers installed, but will do so if you need further info. Cheers, --Stfg (talk) 09:01, 13 June 2013 (UTC)

• Analyzing messages in User:Stfg/Sandbox1: Some other browsers have no trouble with processing https-protocol for "action=raw", so what happens in IE8 if you open another tab and try running request:

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

Does that request display the JavaScript "main.js" text immediately, or do you get a secure-server warning about the "https:" prefix in the line? -Wikid77 12:38, 13 June 2013 (UTC)

Thanks for looking at this. It asks me if I want to save it or find a program online to open it. --Stfg (talk) 12:55, 13 June 2013 (UTC)

Some other browsers, such as Firefox, simply display the contents of the requested JavaScript text, with no questions about access, and even though IE8 has been the world's most-popular browser for years, some aspects of the MediaWiki software are periodically changed and break the processing with IE8, which differs from IE9 and those other browsers. -Wikid77 (talk) 13:46, 13 June 2013 (UTC)

Popups is using the RL module 'mediawiki.user', without declaring it as a dependency. That might be related... —TheDJ (talk • contribs) 13:52, 13 June 2013 (UTC)

it's absolutely related. in the meantime, until the popup maintainer(s) will add the dependency directly to the script (i don't think this can be done through MediaWiki:Gadgets-definition - currently popup gadget does not use RL, so it can't declare dependencies), you can patch this specific problem for yourself, by adding to Special:MyPage/common.js the following line:

mw.loader.load('mediawiki.user')

there is another bug in mediawiki code that currently only affects IE users: it's in the new "thanks" extension, in this file: [13], line 53: the problem is that this module defines an object with a member named class, which IE considers a reserved word, so it bulks. the fix is very simple - just change class: 'ui-button-green', to 'class': 'ui-button-green',. this probably required opening a bugzilla report, but unfortunately i can't do that ATM. peace - קיפודנחש (aka kipod) (talk) 14:34, 13 June 2013 (UTC)

Thanks. That patch didn't solve it, I'm afraid, but if it's going to be fixed soon, let's not worry too much about the temporary issue. Thanks everyone. --Stfg (talk) 15:56, 13 June 2013 (UTC)

You can use RL modules in non-RL gadgets using code like mw.loader.using('mediawiki.user', function(){ ... }) – the callback function will be executed after the module is loaded. One could just wrap the entire Popups' code in this and it should start working. @kipod – I submitted a patch to the Thanks extension at https://gerrit.wikimedia.org/r/68418, I'll poke someone to get it deployed soon, thanks. Matma Rex talk 16:14, 13 June 2013 (UTC)

As a former popups maintainer :D I added the dependency —TheDJ (talk • contribs) 21:20, 13 June 2013 (UTC)

And bingo! it's working again even in page histories and even with IE8. Many thanks everyone who spent time on this. --Stfg (talk) 22:12, 13 June 2013 (UTC)

VisualEditor breaks BLP warnings

Tracked in Phabricator
Task T51552

Hi. When BLP articles (e.g., Barack Obama) are edited with the normal source editor, a warning about BLP policy appears at the top of the page; this is omitted when the article is edited with the new VisualEditor. I raised this on the VE feedback page and was told that it's not a VE bug per se but a result of the way the warning is generated by the article being in a particular category. Since VE is aimed especially at helping new editors, who probably aren't going to be familiar with our policies about BLPs, it seems important that the warning should be displayed through VE. Is there any way this can be done? Dricherby (talk) 22:39, 12 June 2013 (UTC)

{{BLP editintro}} is added by the editintro code for the English Wikipedia in MediaWiki:Common.js. I don't know whether it can added by the VisualEditor but if you don't get an answer here then you could try asking at MediaWiki talk:Common.js. PrimeHunter (talk) 23:04, 12 June 2013 (UTC)

Thanks for the extra explanation, PrimeHunter. I'll try the page you linked if we don't get it sorted here. Dricherby (talk) 08:55, 13 June 2013 (UTC)

For future reference. the block to add to has class "ve-init-mw-viewPageTarget-toolbar-editNotices". It needs to be wrapped in something with class "ve-init-mw-viewPageTarget-toolbar-editNotices-notice". Now to find a hook to know that the VE is done with setup. —TheDJ (talk • contribs) 22:23, 13 June 2013 (UTC)

Hmm, too easily do this might require adding some events to the VE. I've created a ticket to track this problem. —TheDJ (talk • contribs) 22:35, 13 June 2013 (UTC)

Module:IncrementParams

For any infobox template editors out there, I have just written Module:IncrementParams. This module increments numbered parameters of infoboxes and other similar templates, so that you don't have to renumber all the parameters by hand. Enjoy! — Mr. Stradivarius ^{♪ talk ♪} 08:40, 13 June 2013 (UTC)

Removal of a deleted page from view

Hi, can a deleted page (ie title, deletion notice and reasons) be completely deleted so that others cannot see it and it does not appear when google searched? Thanks for your help JulieSmith123 (talk) 15:07, 13 June 2013 (UTC)

How is it currently not "completely deleted"? Note that we don't have influence on search results that 3rd parties (e.g. Google) cached (made a copy of) at some point. --AKlapper (WMF) (talk) 15:48, 13 June 2013 (UTC)

And Google will presumably stop indexing it next time they crawl Wikipedia and find the article has gone. (I assume that robots.txt or some other mechanism stops search engines crawling the article creation page you get after clicking on a redlink to an article, which mentions that the article formerly there was deleted.) Dricherby (talk) 15:52, 13 June 2013 (UTC)

Deleted pages return a 404 HTTP status code, aka "Not Found". This tells Google that the page doesn't exist, so Google removes it from its index (eventually). Content such as the deletion log is returned with the status code for display in web browsers, but the 404 causes Google to ignore it. – PartTimeGnome (talk | contribs) 22:01, 13 June 2013 (UTC)

We also have no say over websites such as Deletionpedia. GiantSnowman 15:56, 13 June 2013 (UTC)

AKlapper, Sorry I should have been clearer by "not completely deleted" I mean the title, deletion notice and reasons for its deletion remain (content is gone). Although it is not, I was wondering if there was a deleted article with a libelous or defamatory title would it also remain on wikipedia? I know that you have no influence over 3rd parties, but if a deleted page's title remains, consequentially it still appears on google search pages.Thank you Dricherby - JulieSmith123 (talk) 16:05, 13 June 2013 (UTC)

That information can be wiped, given a valid reason for doing so. Werieth (talk) 16:12, 13 June 2013 (UTC)

Are those valid reasons available anywhere? JulieSmith123 (talk) 16:17, 13 June 2013 (UTC)

You should provide one. GiantSnowman 16:19, 13 June 2013 (UTC)

Who would I send it to and who would deem it valid? JulieSmith123 (talk) 16:27, 13 June 2013 (UTC)

Special:EmailUser/Oversight Contact them and they will review your request. Werieth (talk) 16:31, 13 June 2013 (UTC)

Thank you!!-JulieSmith123 (talk) 16:35, 13 June 2013 (UTC)

Although, if this is related to Clonakylti, I see nothing under RevDel or Oversight policies that would justify its purging (✉→BWilkins←✎) 16:41, 13 June 2013 (UTC)

For the record, there is in fact a list of valid reasons for suppression at Wikipedia:Oversight#Policy. Beeblebrox (talk) 16:40, 13 June 2013 (UTC)

As BWilkins says above, I'm not sure this counts. GiantSnowman 16:44, 13 June 2013 (UTC)

The deletion notice serves as a warning to others not to re-create the page without good reason. In general, the existence of that notice isn't something to worry about: it doesn't reflect badly on you or anyone else, for example (it doesn't even mention anyone by name, apart from the person who deleted the page). Dricherby (talk) 16:52, 13 June 2013 (UTC)

Thanks, no this query doesn't necessarily regard Clonakylti. For the record, I do find deleted for "Unambiguous advertising or promotion" does slightly undermine your credibility- there could be a possible argument for defamation as it could lower your reputation in the eyes of the reasonable-thinking members of society and it mentions the company by name, a person in the eyes of the law- but I do not intend to!! JulieSmith123 (talk) 16:58, 13 June 2013 (UTC)

That's ridiculous, the article was deleted as being promotional, it has no bearing on the company itself, and I must warn you are dancing right up to the line of making a legal threat, which is grounds for immediate blocking. I would suggest you just quietly make whatever request you were going to make to oversight and maybe review the core policies of Wikipedia so that you better understand what is and is not appropriate content. Beeblebrox (talk) 17:09, 13 June 2013 (UTC)

Emphasis: there could be a possible argument and repeated use of the word could but I do not intend to. You will find I did not make any argument. I do not intend to make any request. — Preceding unsigned comment added by JulieSmith123 (talk • contribs) 17:20, 13 June 2013 (UTC)

• Blanked page with speedy tagbox had cleared Google cache: As typical, when an article for deletion has been blanked and tagged for speedy-delete, then Google resets the indexed cache copy to clear any prior contents. Any use of Google Search, which matches the topic, will link to the deleted page, with no contents to display, and any views of the Google cache will just show the speedy-delete tagbox and none of the prior contents of the deleted page. After a few days, the page-rank typically falls quickly, and within a week, then a direct Google request for the page title might yield zero results, because the prior cache page would be completely hidden from view (as shown when the temporary rename of "Gone with the Wind (film)" caused it to vanish from Google after a few days). Note that an improperly deleted page would remain a few days in Google, to allow time to be discussed and restored without affecting the Google search-results, but a spam page can be blanked/tagged for instant re-caching, and the remaining days of access would just indicate the blanked page was deleted. -Wikid77 (talk) 18:44, 13 June 2013 (UTC)

Thank you Wikid77. - JulieSmith123 (talk) 19:01, 13 June 2013 (UTC)

Special:MyPage plus action=edit ?

Special:MyPage is a magic word that goes to the user's userpage. Is there a way to add/pass an action=edit parameter in the url so that it goes to the editing page of a user's userpage? Cheers! Ocaasi ^{t | c} 15:13, 13 June 2013 (UTC)

Well, yeah, it's the same as any other page. Just do https://en.wikipedia.org/w/index.php?title=Special:MyPage&action=edit. (It's not a magic word per se, it's a special page that forwards to one's own userspace, IIRC.) Writ Keeper ⚇♔ 15:17, 13 June 2013 (UTC)

You cannot make a querystring in a wikilink like Special:MyPage?action=edit but as Writ Keeper shows, there is no problem in a url. You can also do it with http://en.wikipedia.org/wiki/Special:MyPage?action=edit. The prettiest and most portable way to do it may be with {{Querylink}} as in {{Querylink|Special:MyPage|qs=action=edit|edit your user page}} to produce edit your user page. PrimeHunter (talk) 18:54, 13 June 2013 (UTC)

You can also use {{edit}}. E.g. {{edit|Special:MyPage|edit your user page}} gives "". – PartTimeGnome (talk | contribs) 22:04, 13 June 2013 (UTC)

Thanks all, any of those will work, and the url version is best suited to what I'm working on. Cheers! Ocaasi ^{t | c} 03:29, 14 June 2013 (UTC)

Some Google https links now http

This is just FYI. A few of the prior pages with wp:Google https links have resumed the original http-prefix, including: "Gone with the Wind (film)", "Alan Turing" and "American Football". Ironically, the GWTW novel page has shifted to Google https-protocol ("Gone with the Wind") but that allows comparing the recent http/https pageview counts, and many other older pages (such as "Parabola" and "Hyperbola"), still have Google https links as of 13 June 2013. -Wikid77 19:12, 13 June 2013 (UTC)

{{DEFAULTSORT}} behavior on subpages (archived talk pages)

Observe that Category:Closed move reviews has three archived pages listed under A – I assume that they're sorting by A for "Archive". Why don't they sort under B, T, and I? I put a {{DEFAULTSORT:Burma}} tag at the bottom of Talk:Burma/Archive 10 and still it sorts under A rather than B, even though the Page Information shows that the "Default sort key" is Burma. What's up? Thanks, Wbm1058 (talk) 19:41, 13 June 2013 (UTC)

A {{DEFAULTSORT}} is always overridden if a category has an explicit sort key. It's the {{MRVdiscuss}}, which essentially contains a [[Category:Closed move reviews|{{SUBPAGENAME}}]]. --Redrose64 (talk) 20:43, 13 June 2013 (UTC)

Changing the sort key to BASEPAGENAME fixed it. Thanks! Wbm1058 (talk) 21:40, 13 June 2013 (UTC)

Proposed change to the Afc submission process

Dear Technical people:

Writ Keeper has been helping me to implement a proposed addition to the Afc submission process. The proposal is here User:Anne Delong/AfcBox. It has already been through Rfc and been accepted. We would both like a technical assessment to make sure that the javascript is operating properly and not causing interaction problems. If you would like to help check this out, you can find the code at User:Writ Keeper/Scripts/afcDialog.js, and a sample page at User:Writ Keeper/sandbox.

After fixing any technical problems, I will be posting at the Afc talk page for comment on the exact wording of the options, so please hold your comments about that for now so that they'll end up in the right discussion later. Then we'll be working out how to try it with real editors and get feedback from them.

Please let either me or Writ Keeper know if you try this out, whether it works as expected, and whether you forsee any technical problems. (We'll deal with editor interaction problems later at the Afc). Thank you. —Anne Delong (talk) 16:55, 10 June 2013 (UTC)

An implementation note: if we want to give this a trial run (and certainly if it ever goes into production), it needs to be made a default-on gadget, so the code should probably be reviewed with that in mind. I don't think there's anything that's not cross-compatible in it. Writ Keeper ⚇♔ 16:58, 10 June 2013 (UTC)

@Writ Keeper:, no chance to test it, but I'd change at least the url building a bit. like this. —TheDJ (talk • contribs) 18:01, 10 June 2013 (UTC)

Okay, I'll look into that. You changed the typeof thing, but I don't think your version works: it still gives the "not defined" error when I test it in my console, at least, so I'm going to stick with typeof for now. Writ Keeper ⚇♔ 20:11, 10 June 2013 (UTC)

Other than the typeof thing, your suggested changes have been implemented and seem to work. Writ Keeper ⚇♔ 20:23, 10 June 2013 (UTC)

• No promises, but I'll try to set some time aside this week to import the script into my common and test it on all five major browsers (latest version of all except IE which I run v7). I'll let you know what I find. Technical 13 (talk) 18:06, 10 June 2013 (UTC)

Hi Technical 13, have you had time to deal with this yet? Roger (Dodger67) (talk) 20:38, 14 June 2013 (UTC)

I'm sorry, I haven't yet. The only thing higher on my todo list right now is a fix I have in my head for AFCH typeof o = null error. Soon. Technical 13 (talk) 21:38, 14 June 2013 (UTC)

VisualEditor weekly update - 2013-06-13 (MW 1.22wmf7)

Hey all,

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

VisualEditor was updated as part of the wider MediaWiki 1.22wmf7 branch deployment on Thursday 13 June. In the week since 1.22wmf6, the team worked on finishing the new features ahead of VisualEditor's launch as the default way users will edit our wikis in beta.

The most noticeable change for users is that you can now insert images and other media items from the local wiki and Commons - they default to right-floated thumbnailed images with no caption set. Images will also now appear "correctly", positioned in the normal places when editing. We will make it possible to set the caption, as well as convert images from thumbnails to inline or floating on the other side, in the coming week. We also changed the "Save page" workflow to no longer require users to view a wikitext diff before saving (bug 49258), and removed the 'alpha' notice, replacing it with a more subtle beta label (bug 48428). Work continued on ​inserting and editing Templates and References​, ​the other two critical areas ahead of the release ​, which we hope to​ ​​make available in the next week or so.

We fixed some bugs relating to support for multi-byte Unicode characters used by some languages (bug 49246 and 48630) and some tweaks to the category setting interface released last week (bug 48555, bug 48555 and bug 48565). HTML comments and elements that have no contents like some <span>s will now not be silently dropped when editing (bug 48605). You can now use the forwards and back buttons on your browser with VisualEditor as you would expect (bug 43844).

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

Ahead of the regular MediaWiki deployment roadmap, this should be deployed here late today, Thursday 13 June.

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

Jdforrester (WMF) (talk) 17:58, 13 June 2013 (UTC)

Note that section edit links will now take users to the VE, if they have the VE beta enabled. There is a preference switch to have section edit tabs take you to the source, rather than visual, editor - "Use the wikitext editor for editing sections while VisualEditor is in beta " under "Editing". Okeyes (WMF) (talk) 10:42, 14 June 2013 (UTC)

Will there be a preference to do the same when VisualEditor is no longer in beta? In fact, can it be the same preference? Anomie⚔ 11:32, 14 June 2013 (UTC)

Thanks for providing this option. I am basically waiting for template & reference editing to be available before properly looking at visual editor. Rjwilmsi 11:33, 14 June 2013 (UTC)

Database lag

Due to high database server lag, changes newer than 913 seconds may not appear in this list.

What does this message mean? and how this issue will resolve? I mean, i can't see the newest changes--Jockzain (talk) 19:13, 20 June 2013 (UTC)