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, 214, 215, 216

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

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

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

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

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

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

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

@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)[reply]

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

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

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

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

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. Giant Snowman 10:29, 31 May 2013 (UTC)[reply]

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

Yes, it should definitely not be a one-click option. Giant Snowman 10:45, 31 May 2013 (UTC)[reply]

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

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

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

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

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

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

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

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

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

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

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. Giant Snowman 12:37, 2 June 2013 (UTC)[reply]

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

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

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

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

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

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

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

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

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

Better late than never! Giant Snowman 10:49, 11 June 2013 (UTC)[reply]

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

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

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

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

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

Concerns with Flow

Okay, so I've been following the discussion on Flow. There are many things that I am concerned about as it will completely change the way that talks and discussions and what not will have to be handled... The most recent thread of concern is mw:Thread:Talk:Flow/Avatars/reply (25) where it seems that not only will customizable signatures be a thing of the past, but using templates in discussion (even the simple useful ones like {{Done}} and {{Not Done}}) will not be allowed anymore either. Just plain text and a system default signature. It makes me feel like we are all truly being assimilated. Technical 13 (talk) 22:42, 1 June 2013 (UTC)[reply]

Dislike times three or four dozen. Change for change's sake. Do they care about us oldies at all? (What will happen to all those templates already on talk pages when Flow is rolled out?) Ignatzmice•talk 22:53, 1 June 2013 (UTC)[reply]

The biggest concern here might actually be the loss of {{Help me}} and {{Admin help}} making it even harder for new users to get help... Where are those two templates suppose to go? On user talk pages... Where is Flow going to be rolled out to start? On user talk pages... *sigh* Technical 13 (talk) 22:57, 1 June 2013 (UTC)[reply]

How will we discuss the appearance of templates? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:58, 1 June 2013 (UTC)[reply]

We won't be able to use any of the {{Tl|...}} family anymore... That being said, curly brackets should just display as curly brackets from my understanding so we can just type them out (and use square brackets to link the template if we want)... At least that is my guess... Technical 13 (talk) 23:05, 1 June 2013 (UTC)[reply]

Can't even do that, apparently... Ignatzmice•talk 23:09, 1 June 2013 (UTC)[reply]

I also felt that this part of the discussion was very enlightening. It basically says, that the WMF development team made some decisions regarding Flow already knowing it will upset the community, but doesn't care because it thinks those changes are "better for the future of Wikipedia". Everything should simplify the experience for new users, regardless of usability or accustomed ways of doing things, that were accomplished long ago and work perfectly well. --Patrick87 (talk) 23:35, 1 June 2013 (UTC)[reply]

I think "Flow" (see m:Euphemisms) has the potential to be good. However, as I've stated before, the Foundation appears to be doing a lot of work to reshape Wikipedia into something... different. Killiondude (talk) 23:55, 1 June 2013 (UTC)[reply]

(edit conflict) Apparently, Flow will make it impossible to use templates to warn users. This is getting ridiculous.--Gilderien Chat|List of good deeds 23:58, 1 June 2013 (UTC)[reply]

Not to mention WikiProject Banners, the Edit protected template, Article history and a wide variety of others. Like I said in the discussion on Mediawiki. If Flow can't use templates, they may as well stop developing it and move the resources somewhere else. Too much of our system relies on the use of templates, so if they have eliminated the use of templates on talk pages, they just broke Wikipedia. Kumioko (talk) 23:59, 1 June 2013 (UTC)[reply]

The noindex template is important - at least to me. If it can't be used, I hope they consider keeping talk pages from being indexed by default. Victoria (talk) 00:34, 2 June 2013 (UTC)[reply]

I agree wholeheartedly--Kumioko, you've hit the nail on the head here. Theopolisme (talk) 00:10, 2 June 2013 (UTC)[reply]

Wait. So tools like Twinkle and Huggle would stop working? Seriously? --NeilN ^{talk to me} 00:15, 2 June 2013 (UTC)[reply]

Yep, deader than a doornail. In fact a lot of work would need to be done to AWB and a lot of bots as well. Kumioko (talk) 00:17, 2 June 2013 (UTC)[reply]

Well, eventually, I think they will be "replaced" with something called workflow. But in the meantime, usertalk pages will be devoid of custom signatures, templates, and other complicated syntax. Instead of just, I don't know, hiding the syntax, they're prohibiting it.--Gilderien Chat|List of good deeds 00:19, 2 June 2013 (UTC)[reply]

From Wikipedia:Flow/FAQ#How_will_Flow_handle_spam_and_vandalism.3F: "[FIXME]" *headdesk* Theopolisme (talk) 00:27, 2 June 2013 (UTC)[reply]

Cool. So we get a lot of newbies, using the "easier" system to proclaim "I waz here!", while editors who already volunteer their time throw up their hands in frustration and wonder why the Foundation is obsessed with rolling out "Facebook UI" widgets at all costs. --NeilN ^{talk to me} 00:28, 2 June 2013 (UTC)[reply]

As usual, when people who are not active wikimedians design features, they have no clue what is actually required. If this design decision stays in, it obviously cannot be deployed anywhere on Wikimedia, so it would be nice if the WMF would employ their resources to do something actually useful. Snowolf ^{How can I help?} 00:12, 2 June 2013 (UTC)[reply]

Well, it will be deployed on every user talk page. That's already a fixed plan by WMF at this point in time... --Patrick87 (talk) 00:17, 2 June 2013 (UTC)[reply]

If they deploy something (Flow or anything else) that affects the flow of talk pages, they need to do it to all talk pages. Not just users. Otherwise we would now need to learn 2 separate systems for discussions. One for one group of pages and 1 or more for others. That would be about the dumbest way to "Make discussions easier" that I have ever heard. Kumioko (talk) 00:21, 2 June 2013 (UTC)[reply]

Talk about "editor retention"...seems like now everything's just about getting the new ones. It's all or nothing for the WMF... :/ Theopolisme (talk) 00:20, 2 June 2013 (UTC)[reply]

The WMF has made it clear time and time again that editor retention is not a concern of them. Their only concern is to attract new editors, especially ones who seem to be more interested in facebook and shiny graphics than building an encyclopedia. I don't know why you're surprised, it's hardly news. Replying to Patrick, yes, I know it will be deployed regardless of whether it is or isn't fit for purpose. No news there either.Snowolf ^{How can I help?} 00:23, 2 June 2013 (UTC)[reply]

Surprised? No. But I feel like if I say it enough times, maybe someone will listen. Then again, what's he going to do... Theopolisme (talk) 00:25, 2 June 2013 (UTC)[reply]

Well, if the community revolted, with Jimbo, 3 community seats and 2 chapter seat, we would have a majority on the WMF board ... --Gilderien Chat|List of good deeds 00:30, 2 June 2013 (UTC)[reply]

(edit conflict) I wonder how MediaWiki changes are implemented on enwiki, and if there's a way to pause/stop/revert them...

Ignatzmice•talk 00:26, 2 June 2013 (UTC)[reply]

We'd have to fork it or something. Which now doesn't seem like too crappy an idea...well, okay, it's a terrible idea, and we'd lose most of our editors, but it could keep running on MediaWiki 1.20.6 ad inifinitum. ;) Theopolisme (talk) 00:30, 2 June 2013 (UTC)[reply]

Well a lot of people have been trying to get rid of me. Implementing Flow just might do it. Kumioko (talk) 00:28, 2 June 2013 (UTC)[reply]

Admins can change the interface pretty freely; when Wikia implemented their new skin a load of administrators managed to remove it .... of course, they were all desysopped when they tried to fork.--Gilderien Chat|List of good deeds 00:34, 2 June 2013 (UTC)[reply]

That's just a skin, though. Not the underpinnings of MediaWiki itself. Ignatzmice•talk 00:35, 2 June 2013 (UTC)[reply]

Flow is a mediawiki extension, which means it is installed on the server-side. So we'd need a rogue WMF employee or something. Theopolisme (talk) 00:37, 2 June 2013 (UTC)[reply]

There would be a way round it. But (and I would probably do this) this would increase the divide between new and established editors even further.--Gilderien Chat|List of good deeds 00:39, 2 June 2013 (UTC)[reply]

If it came to that, I honestly would advocate a fork. Theopolisme (talk) 00:43, 2 June 2013 (UTC)[reply]

I can't remember where I read it, but I thought something said that Wikipedia was successful in its early days for being simple and not trying to use advanced and complicated technology. Things like Flow and Visual Editor seem to be complicated ways to reinvent the wheel, but only a partial implementation of what we currently have (like all wheels are now semicircles). As an example, this FAQ about Flow says that "A singular package will not and cannot cover these cases. So we have to build our own." But there is a singular package: the thing we currently have.
Also, it is important to gain new users, but alienating the existing editor base is suicide. Retention is as important as attracting newbies. Also, if someone can't overcome the minor barriers that may or may not exist in the current interface, are they someone capable of crafting this encyclopedia? Also, from what I see, these new "features" make some things easier but erect artificial barriers preventing many others.Chris857 (talk) 00:47, 2 June 2013 (UTC)[reply]

I'm glad I Like to because I seem to have opened up a can of worms... I would love to see some WMF response here... Perhaps we are all "just missing something", but I fear we are not... I'm starting to Dislike Flow more and more, and it hasn't even been written yet... Technical 13 (talk) 00:49, 2 June 2013 (UTC)[reply]

Maybe you should try out the interactive prototype? :) --Gilderien Chat|List of good deeds 00:53, 2 June 2013 (UTC)[reply]

I was already going to avoid Flow at all costs. That some users, including myself, "will not be able to edit or add comments" is what ruined it for me. From the above, it seems many others will also be avoiding it, and for good reason.

The WMF is determined to push through changes unfit for purpose regardless of what we say, so we must consider how to workaround such changes when they arrive. Once Flow is required for talk pages, I thought to move my talk page to User:PartTimeGnome/Talk to take it out of talkspace. The scratchspace idea mentioned above is also good. Unfortunately, both ideas would mean losing talk page notifications, though I could ask users to mention me each time they post.

I hope it goes without saying that resisting the organisation controlling the servers is a bad position to be in. Since we can't work with the changes the WMF is forcing through, the WMF needs to change. There is an opportunity for this very soon: the Wikimedia Foundation elections start on 8 June (next week). Use your vote wisely! – PartTimeGnome (talk | contribs) 02:15, 2 June 2013 (UTC)[reply]

Amen. Here is what I think: If Flow is going to cause this much trouble, it is not worth whatever improvements it may bring. AutomaticStrikeout ? 02:52, 2 June 2013 (UTC)[reply]

Before this discussion goes any further, I just want to point out that a lot of what is being said about Flow is nothing but rumour or misinterpretation. It seems that the WMF is asking for community feedback before they develop the tool (as opposed to what happened with, say, AFT), which is something we as a community should welcome. But just grumbling about the supposed "features" of the tool here isn't a very productive use of time. If you are concerned that Flow will not allow the use of templates in discussions, then go and have a friendly chat to the developers, see what their side of the story is, and then explain how you disagree with them. Simple as that. — This, that and the other (talk) 03:48, 2 June 2013 (UTC)[reply]

I may be reading this wrong, but from the discussions linked above it seems Technical already had that conversation, and Jorm said "Nuh-uh." But if they do decide to change that, wonderful. And I might be wrong. Ignatzmice•talk 04:00, 2 June 2013 (UTC)[reply]

Let's be clear here; we're at the discussion stage. The team actively working on Flow consists of Brandon, who is actively talking through things. Now: yes, we may lose templates. The intention is not to lose anything by losing templates. What I mean by that is that, largely, templates aren't the end-goal, they're the method; the goal is being able to signify that a user needs help, or is blocked, or...etc, etc. These are things that can be implemented in other ways. Nobody at the WMF end wants to lose the underlying functionality that makes templates useful. Okeyes (WMF) (talk) 04:05, 2 June 2013 (UTC)[reply]

I'm in the process of writing a response. Today is a non-work day for Foundation folk; I was down in Santa Cruz.--Jorm (WMF) (talk) 04:06, 2 June 2013 (UTC)[reply]

- @Okeyes So are you saying Flow will not be implemented before acceptable alternatives for Twinkle, Huggle, Cluebot, etc are rolled out? --NeilN ^{talk to me} 04:09, 2 June 2013 (UTC)[reply]

Don't panic. Right now, Brandon (Jorm) is actively floating ideas on how Flow could work, including potential alternatives to existing workflows. Nothing has been implemented or set in stone yet, and now is a good time for ideas to be tested, kicked around, prototyped and, in some cases, shot down. The whole point of having this discussion early (with only an interactive prototype in existence) is so that issues can be surfaced early in the development. That's a good thing. Give Brandon a chance to respond in a bit more detail, and then we can see if we can come up with an approach that addresses key concerns.--Eloquence * 04:46, 2 June 2013 (UTC)[reply]

Response from Jorm

Well, hasn't this been fun! I'm just going to comment on everything here, in a subsection, because REASONS.

Here's your bullet points:

Yes, you can still warn users.
Yes, we've made implementation decisions already, based on back-end constraints.
Yes, bots, twinkle, huggle, awb will continue to work. Anyone who says otherwise has been Caught Not Reading.
Yes, you'll still be able to add templates to page boards (though we're not going into Article talk pages yet). There will be a "non-structured" area on every page. Existing templates will likely migrate but again: that's not where we're at right now.
Yes, we're thinking seriously about restricting the ability of allowing anyone to edit other people's comments willy-nilly. This is a complicated topic and we're thinking through several options.

Okay. To the meat.

I wish this discussion would actually have taken place in the multiple places provided for it, and I wish that it had been started on a work day, and I wish that it hadn't had several hours to cook and cycle upon itself without a response from me because it's a Saturday and I was at a cook out with my in-laws. I also wish that there were more assumptions of good faith and trust.

In fact, I think I'm gonna talk about that for a second. Friday was the third year anniversary of my employment at the Foundation. That's a really long time in Silicon Valley years and it's more than enough time, I think, that we should drop the whole schtick about "Foundation designers don't know the community" and "they're trying to turn it into Facebook" and "you don't listen to us" and all the other jazz. I think you'd be disturbed at how well we understand the processes used by the various wikis and I think you might be saddened if you understood how hamstrung we are in making your life better because the complexity of the process is hypnotic. Ask people whether or not Special:NewPagesFeed isn't an improvement and then ask me how many hours were spent studying how page patrollers work and interviewing patrollers and basically absorbing everything about it. Was the final product exactly what any one patroller wanted? Probably not, but it was closer to what they needed.

If you think - even for a moment - that there are not people who are thinking about and discussing every one of the problems or issues that have been brought up above, you're wrong. And if you think that we're working in Bad Faith, there's nothing I or any of us can do for you.

The only thing I can ask you for is your input. I think we've been pretty damned good about trying to communicate and ask for input.

Okay.

Let's start with templates, which I think is what everyone is really freaking out about when it's boiled down.

First, no one has said, ever, "well, we're doing this, and screw you and your processes, you're just out of luck." In fact, we've been pretty solid about saying "we're going to help you in any way you can". In fact, "buried" in the global navigation on every Flow portal is a page describing a "Workflow Description Language". We're planning to give you something to replace your templated workflows and make them better and easier.

Second, no one has said, "well, bots and Twinkle and Huggle and AWB people are screwed." No, they aren't, and I'm frankly finding it hard to jump to that conclusion. How will Twinkle work? Simple: we grab the hook off "create section," take the template that it wants to drop, parse it into html, make sure the Parsoid understands it, and create a new Flow Topic with the html as the post text. That's it! And even better: the conversation is now managed.

Ah, but what if - what if - what if we could make warning a user a real, true workflow? What if, instead of a spray-and-pray template, we can initiate a workflow that actually tracks how many warnings a user has, makes sure the user has seen and acknowledged them, and then also provides them with interactive tools to learn about what they did wrong? Wouldn't that be neat?

Let's now tackle the "devs are making decisions without us" line of thought.

Spoiler: Of course we are. Absolutely we are. You, as a community, cannot individually be expected to understand how our software back end works. Nor can you be expected to understand how to program. Or have studied human interface design, or even know anything about computers at all. I'm not saying that some of you don't: I know many members of the community do.

I am saying that it is our job to know about all of those things. What this means is that we sit and look at our design constraints and look at what our goals are and how the system (e.g., community processes) works, and how the system will be impacted, and so forth. We read tea leaves and we think about The Future - not just as it relates to enwiki, but to all wikis.

Here's the future and I don't think it's a surprise to anyone: The VisualEditor.

That adds a massive constraint to whatever design we come up with. Whatever content gets entered into Flow must be readable, parsable, and editable within the VisualEditor. It is simply a non-starter otherwise.

Currently, the VisualEditor (and Parsoid, which is our real constraint) does not handle templates very well - at least not well enough that we can (at this time) state for a fact that all templates can be parsed by it. The fine developers working the VE are hustling to get these things working but the timeline isn't "next week". Ergo, we can't depend on it, so we have to treat it as a design constraint.

That brings me to the next constraint: scalability and the Parsoid. I walked through the issues with this before and it's a lot of text so I won't repeat it here. The gist is "running every post through the parser on load is not scalable". It's just not possible to do.

We're also not going to be storing the data for Flow posts in the local wikis. The database structure doesn't allow for it (they're built for horizontal scale, not vertical, and Flow requires vertical scaling). That means all Flow posts get saved to a different database system (another constraint).

(There's an interesting side-effect to that, but I'll leave it as an exercise to the reader to figure it out. For now.)

Let's walk back from the ledge, people. This is all good stuff. I'm not going to lie to you: it's going to be change, and it's going to hurt for a bit, but we'll all get through it.

It might be a fun exercise to sit and think about how many things we can fix with Flow, rather than how many things are going to change.

This was long. It's Saturday night. I'm going to spend what remains of it with my wife. I'll try to be available to answer questions tomorrow (Sunday). I'd prefer it if these questions were left at mw:Flow Portal, so they're centralized, but I'll talk here as well.--Jorm (WMF) (talk) 04:52, 2 June 2013 (UTC)[reply]

Thanks for the detailed explanation Jorm. I understand this discussion may have seemed somewhat premature and bad faith but given the recent changes that have been coming out that were, arguably, not helpful, I hope you can understand our concern and reluctance at the potential that this would eliminate the ability of using templates.

Enjoy the rest of your weekend. I have been married a couple times, you have to do the same thing to keep them as you did to get them, it took me a while to figure that out. :-)Kumioko (talk) 05:02, 2 June 2013 (UTC)[reply]

Jorm, my thanks as well. Enjoy your night-- Theopolisme (talk) 05:10, 2 June 2013 (UTC)[reply]

Thank you for your response. May I suggest putting some of it in here? --NeilN ^{talk to me} 05:56, 2 June 2013 (UTC)[reply]

About the exercise to the reader: should we take it as a hint that 'local wikis' is plural while 'different database system' is singular? — HHHIPPO 10:19, 2 June 2013 (UTC)[reply]

Thank you for your response, just one thing though - "Anyone who says otherwise has been Caught Not Reading." ... I have read as much as I can find and I haven't found this said anywhere; Huggle especially relies entirely on templates so presumably it would have to be re-written.--Gilderien Chat|List of good deeds 11:05, 2 June 2013 (UTC)[reply]

WP:FLOW was created too early since the pages describing Flow have insufficient explanation of how common talk page actions would occur. Of course there can be no detail at this stage, but there should be a 20,000 foot overview of fundamental issues like whether Flow will handle standard warnings, and how abusive posts (or spam or trolling) can be removed (hint: asking an admin is not acceptable). The other issues mentioned at WT:Flow should also be addressed. Johnuniq (talk) 11:26, 2 June 2013 (UTC)[reply]

Jorm (WMF), thank you for you taking the time to respond here. Being the one that has opened this discussion here (and a discussion elsewhere questioning the Borgification of signatures (which I'm not saying is entirely bad)), I want you guys to know that I really am assuming good faith on your (the Foundation's) part (I've even gone out of my way to try and stick up for you in some of these threads like here). I'm far from opposed to change. As you know, I've been following this discussion on the MediaWiki liquid threads and I've been following as much of it as I can find on Bugzilla (I'm on the mailing lists as well), and trying to ask important questions and understand it in both places and addressing concerns. I just wanted to make sure that everyone was aware of some of these things and had a chance to offer some more input to the process. No, I'm not saying they don't have the same ability as myself or anyone else to go to MediaWiki and follow all of it like I have, simply that some may not have the kind of time required to read all of the messages if follow it at all or are simply unaware that it exists there. The template thing is a huge concern of mine (and apparently others) because there are so many tools that rely on them from Twinkle, Huggle, Snuggle, AWB (less so because it isn't as often used on talk pages) and critical processes such as warnings, help/edit requests, teahouse invitations, wikiproject banners, afc/dyk/fa/deletion/block notifications, etc... I would love to help in anyway I can to create alternatives or make these functional within Flow before Flow is rolled out... So, do you think that WMF and the community can work together on this instead of the foundation just saying "hey, we researched everything and we know how your systems work better than you do and this is what we devised based on that..."? Technical 13 (talk) 12:12, 2 June 2013 (UTC)[reply]

@Jorm I think there are a lot of flaws with your statements above and with your assumptions in the article about the Athena project linked below. I do think your intentions are pure so I don't want anyone saying I am not assuming good faith but here are a few of my concern which I had last night but saved posting them to let you enjoy your night:

First, not posting on a weekend because you don't work on weekends shows a huge lack of understanding about the dynamic and global nature of how the community works. Or a lock of caring. Either way its not a great thing. The community edits 24 hours a day 7 days a week. We should not need to save our comments and concerns for a WMF work day because the primary developer doesn't edit here off work hours.
Next the comments about posting at the MW site is pretty much silly and again shows a fundamental lack of understanding about how the community works. The vast majority of the community never edits there and wouldn't even know the discussion was there until it was too late. Even on this page there is a limited number of people who comment and most of those are admins and technical folks. If you want to ensure that few comments are made and make the point later that no one commented so everything must be fine, then hiding the discussions in MediaWiki is a good way to do just that.
The technical aspect of the site is much more of a minor problem than the uncivil and toxic nature of how newby's are treated. I agree its a little dated and it could stand some updating but we aren't Facebook and the people who edit here are doing so for different reasons than Facebook or social media so using the mentality that Facebook spent a lot of time and money developing it so it must be good for us as well is fundamentally flawed.
The vast majority don't leave because they have trouble learning how to edit. They leave because the community treats them like crap if they aren't born with the knowledge of our rules and some block happy admin blocks them the first time they don't sign their posts or some other stupid thing. If you want to keep editors, work on culture toxicity, not on implementing a secondary talk page discussion system so they have to learn 2 and eliminate make it so we cannot use templates.
Another big reason we are losing editors is that they aren't leaving, we are diluting our pool of editors with new projects as the come online. With every new project we add (Wikidata, Wikivoyage, Wiktionary, etc.) we lose some editors to this new project. I don't want to sound like these projects are a bad thing because they aren't and that's not what I mean to imply. But it does spread us thinner so our resources don't go as far as far as human capital goes.
You state that no one has said "well, we're doing this, and screw you and your processes, you're just out of luck." Really, isn't that almost exactly what they have said in multiple occasions in the past, including the elimination of the Orange Bar of Doom? Because I distinctly remember at least 2 comments from WMF folks implying exactly that.
You also stated "well, bots and Twinkle and Huggle and AWB people are screwed.". Of course there will be a way to work around the problem but these things will need to have some modifications made to them if this goes through. That modification might need to include just not updating whatever page Flow is displayed on. So although you are correct that no one said they/we are screwed, no one made it clear in any instructions before now that these would not be affected. Additionally, although several of these applications were designed by or supported by people who work at the WMF, none of these applications are actively "supported" by the WMF. So I could easily see the attitude of well we don't support it so its not our problem if it breaks. And it wouldn't be the first time the WMF had this attitude by the way.
There are a lot of improvements that Visual editor will bring I agree but it still has a ways to go. Even when it is released, its likely that we will still need an advanced editor in the form of what we have as the current edit capability.

In summary I'm glad you took the time to post and I very much appreciate that as well as other community members do. But the general tone of your post is that of a general lack of empathy and frankly indicates exactly the problem with the "well, we're doing this, and screw you and your processes, you're just out of luck." comment you made above. Kumioko (talk) 13:58, 2 June 2013 (UTC)[reply]

Wow. That's...certainly something. Let me go through, but by bit.

I don't think it demonstrates a lack of understanding about the community; do you think after three years of heavily engaging with the community, Brandon was ignorant of the fact that we're a global, volunteer-based movement, and that editors can post at any time, from any place? As someone who has worked with him very closely for 2 of those 3 years, Brandon gets it to a degree most staffers don't - to a degree that some community-sourced staffers don't. He wasn't saying he was ignorant of this community trope; he was saying that, weirdly, staffers sometimes need to take time off. As someone who has done the whole work-90-hours-a-week-every-week-for-a-year schtick, I've started trying to take weekends for myself, too (as this demonstrates, I'm not very good at it). I don't think people get the long hours that staffers work, here. It's not Brandon not understanding the community, it's Brandon understanding that working 120 hour weeks would drive him insane. I have absolutely no desire to wander into the office and find him, mind broken, wandering pantsless around the 6th floor chainsmoking Marlboro Lights and singing 'I Will Survive' over and over again. I doubt anyone else wants that mental image either. If you truly think staffers should be active whenever editors are active then you're asking for the WMF to be run by ELIZA, because that's the only way we can keep up.
Nobody has told you to post on MW.org. Please point me to the bit of Brandon's post where he mentioned MW.org as a venue. We are not ignorant of the difficulties around it; if you look at the engagement strategy I wrote for Page Curation, a project Brandon worked heavily on, you'll see it specifically called out as a problem. What Brandon meant is that there are several other perfectly good venues for this kind of discussion, one of which is right here on enwiki.
Citation needed for your third statement? I'll agree that a big chunk of people who register in the data as 'editors who leave' leave because of community toxicity. This is nothing to do with the relative difficulty of overcoming toxicity versus overcoming technology, it's to do with poor science; by definition, everyone who edits and then leaves can handle editing. When we look at surveys of ex-contributors or that sort of data, or just anecdotes, of course we're going to be biased towards people who grok markup and leave for other reasons. People who don't grok markup can't participate in the observations.
No comment on diluting the pool, really, except to say that we're talking about Wikimedia-wide data on editor decline, not enwiki-specific data. We're not losing them, as you note.
We're not talking about the orange bar of death, or any of the other occasions. We're talking about Flow, let's be clear. You may as well tar the development process with the IEP brush, if the approach that you're taking is one where prior actions are complete predictors of future actions taken by a different set of people.
Sure, they'll need some modifications. We know this; I spent about 40 hours writing up use cases for everything we'd need to support in the existing talkpages - not just twinkle or huggle, but the underlying mechanisms, like having a good external API for Flow and making sure that we reach out to the volunteer developer community and provide clear instructions and help with such things.

In summary, I don't see Brandon's post as indicating a lack of empathy; honestly, if he didn't appreciate the feelings the community had do you think we'd be having this conversation, let alone making plans to ensure things like Twinkle support work? If he didn't care - if we didn't care - here's what would happen. We'd keep all the documentation on MediaWiki.org, we'd have built the software already around our utopian community workflows, we would've silently deployed it, and, absent bugzilla reports, not given a brass farthing what anyone said. That's quite clearly not what we've done. I'm sat here at 6pm on a Sunday evening writing out a ludicrously long counter-counter-argument to follow your counter-argument to another staffer's argument because We want to keep people informed about and involved in the process. And that counter-argument I'm responding to is, depressingly, one that alternately argues our culture is toxic and states basically that "well you should be contributing whenever an editor contributes, then. Any alternative just means you don't care about us". I'm disappointed by the cognitive dissonance I'm seeing here.

As I've offered before, Kumioko (and I hope you'll take the offer up, this time); if you want to discuss the factors at play here, or Flow generally, I'm certainly willing to free up an hour for a skype call or a google hangout. The same goes for any other editor who wants to talk through...well, whatever they want, really. Okeyes (WMF) (talk) 16:53, 2 June 2013 (UTC)[reply]

KumiokoCleanStart, I think that while most of your statements are how you personally feel towards the WMF team and may be written based upon good intent, they are mostly unfounded and most of them are completely unfair in my opinion. There really is a big gap in the communications between them and us, and I agree that needs to be addressed. I view a large part of your comment as flaming and bashing of the WMF team and I commend them for their efforts to bite their tongues as well as they have been. Finally, I would really appreciate it if you would do something about your username, I find it disruptive and counter productive... I am barely aware of whatever you had to go through before, but that being said, having the username of "KumiokoCleanStart" and not actually changing your ways implies to me that you really do not wish to have a clean start. Anyways... That is between you and the admins, I just wish you would stop being so disruptive and every comment being to complain or mock or flame someone else. I implore you to look in the mirror and ask yourself how you can improve yourself. Now, since I expect something of a "With all due respect Technical 13" response from you for this comment, I would like to make sure that you know ahead of time, it would be a waste of time... Technical 13 (talk) 17:45, 2 June 2013 (UTC)[reply]

Actually I have met Brandon (although I'm certain he couldn't pick me out in a crowd) and quite a few of the other folks at the WMF and harbor no hard feelings or ill will towards any of them. I found most of them to be very collegial and personable. I also think that some of my statements above are being taken out of context which doesn't really surprise me much either. Clearly I must be the only one who has issue with the comments from Brandon above. I have no doubt that he and the WMF folks mean well but frankly, given the changes that have occurred lately, I wanted to make sure my comments were out there. If they choose to listen and consider my comments or ignore them or if you and others think I am a nut, that's fine. Just remember this discussion a few months from now when Flow comes out because I have enough experience in the IT field as a project manager to see the writing on the wall. So since the comments seem to indicate my input is not wanted or needed I am going to move on and go back to editing. Let them release Flow, break all the templates and cause problems for the admins. Not my problem anymore. I have voiced my concerns and said my piece. There is nothing more I can do since its clear that nothing I say is going to be taken seriously anyway, I'm just wasting my time. Which is IMO not a unique issue with me and a byproduct of the culture here in the project. I'm not an admin nor a member of the WMF so as just an editor, and not a particularly popular one at that, my opinions are of little interest or impact. The reason I keep bringing up the bit about the culture is, strangely, I don't see anything being done about it. Lots of talk about Facebook like pages and making it easier to edit, but the only comments about the culture are directed at me and how your tired of me bringing it up. If your tired of hearing it, then do something about it rather than kick the can down the road. I analyze things, that's what I do and I often offer suggestions to fix it. But I can't make the changes. Hell I can't do a lot of things around here to help out that I would if I could. Because we are more worried about keeping the power in the hands of a few, than enabling editors to edit and buildup the site. That is the problem with our culture. We are driving the editors off with our actions. Not because they can't figure out editing. If you want to retain editors. Look at fixing those issues first. Otherwise your just putting makeup on a pig! No matter how pretty and easy you make the site, if people are still being shitty to one another, they ain't gonna stay because it looks like Facebook.
As for my username this is hardly the place but since you brought it up I'll explain it again. I tried to create a new one and was blocked for socking from an overzealous admin. Then I edited as an IP and once again I had editors crying that I was socking. So I recreated this username and yes I am poking some fun at a lousy policy (clean start) because it doesn't work. Our other policies and culture prevent if from working. If you have to link your old account name to your new one its not a clean start. Frankly if I knew what I now know that I wouldn't be allowed to edit as an IP or create a new name I would have kept the old one with the vast majority of my edits and edit history. But its too late to change it back so now were all stuck with this one. Happy editing and there's no bother replaying to my comments. I'm not going to get involved in the discussion anymore. You all can talk about how wonderful Flow is going to be without my interventions. Kumioko (talk) 22:33, 2 June 2013 (UTC)[reply]

Kumioko, nobody said we didn't want to hear your issues. We said we didn't want to hear complaints about how Brandon doesn't care because he doesn't work 24 hours a day, 7 days a week. There are some very good reasons why the WMF does not get involved in cultural change, and again, for the third time, I am happy to talk to you in more detail about this issue and/or any other. I hope that this time you might either take me up on my offer or at least offer a response. Okeyes (WMF) (talk) 23:20, 2 June 2013 (UTC)[reply]

Okeyes, No one expects Brandon or anyone else to work 24/7/365 and that is not what I meant. What I was referring to was Brandons comment at the start of his post'I wish this discussion would actually have taken place in the multiple places provided for it, and I wish that it had been started on a work day, and I wish that it hadn't had several hours to cook and cycle upon itself without a response from me because it's a Saturday and I was at a cook out with my in-laws. I also wish that there were more assumptions of good faith and trust.'

As I said above, few of us watch the other places so there should be little surprise that no one is commenting there. There is no reason for this to Start or happen on a WMF work day, disussions often cook here and fester and boil. If the WMF is not keeping the members of the community in the loop, things will get blown out of proportion because the WMF isn't relaying that information. If you write a 3 sentance description about Flow and in it say things like Signatures and templates won't work with no explanation of why or how that will be worked around, don't get mad at me or others because we call you out on it. This is an opportunity for growth and development for all of us. We can take everything offensively or take the comments in these discussions as an opportunity for improvement. Lastly certainly I think everyone understands that Brandon and anyone else should get to spend time with their family. No one and certainly not me would have though the less of him if he would have left a comment saying I will comment in detail on Monday I am spending time with the family. I'm glad he left the detailed comment and I am sure he was frustrated at the situation as are we all. But many of his comments raised more conerns and I commnted on them. I got to where I am in my real life because I don't suger coat things and I don't generally hide behind politics. If I see something wrong I work to address fixing it. I am not shy, timid or calculating. I am blunt and often times in text only environments it comes off as abbrasive. Its not meant to be. It doesn't change the problem though. Flow, as advertised, is not an improvement for us here. It could be if the issues are addressed. But not in its current state. Kumioko (talk) 15:17, 3 June 2013 (UTC)[reply]

Per Kumiko's comment a long way above, the VisualEditor can never completely replace the source editor. The VisualEditor is good for convenience and for the less technical among us. However, there are various tasks that would be impossible with a WYSIWYG editor (editing parser functions, CSS, JS, Lua scripts, ...), and other tasks might be harder using WYSIWYG. Furthermore, the VisualEditor cannot work without JavaScript; the source editor provides a fallback for editors unable or unwilling to run scripts. Please do not consider the VisualEditor as the future; the future should be VisualEditor and the source editor. – PartTimeGnome (talk | contribs) 23:24, 2 June 2013 (UTC)[reply]

The VisualEditor always has had a source editor component planned; we're not going to be removing that for just those reasons. Okeyes (WMF) (talk) 23:31, 2 June 2013 (UTC)[reply]

That's basically the opposite of what Brandon told me before. According to him (at least regarding Flow) Wikitext will be abandoned completely and everything will be designed to work properly with VisualEditor. A source editor will only be made available for people without JavaScript enabled and will only offer a very limited set of function (even more limited than the VisualEditor. Can you explain this discrepancy in your statements? --Patrick87 (talk) 00:08, 3 June 2013 (UTC)[reply]

That's not the opposite of what I said. "Source Editor for articles" is not the same as "source editor for discussions". You don't need to edit CSS or Lua scripts to respond to someone in a thread. Ergo, it's not going to be there.--Jorm (WMF) (talk) 00:29, 3 June 2013 (UTC)[reply]

It is impossible to implement the VisualEditor without JavaScript. Therefore the source editor is needed as a fallback for non-JS users. Participating in discussions is core functionality, so it must function without JavaScript. There's nothing wrong with non-JS users having a degraded experience (i.e. no WYSIWYG editing), but they must be able to post in discussions somehow. (Also, because you don't understand the need for something is not an argument to remove it, unless it causes some other problem. Things should be easier for both developers and users if the editor behaviour is broadly similar regardless of where it is used. It should mean fewer code paths to test, and less user confusion due to differences in the available functions.) – PartTimeGnome (talk | contribs) 01:02, 3 June 2013 (UTC)[reply]

OK, I see. So basically the idea is to have all (?) functionality of the current WikiEditor in a future VisualEditor source editing component, but deactivate these functionalities selectively at places where they are not needed? So in the "unstructured" board section everything (?) that is currently possible will be possible in Flow, too, but in comments on the threads only basic text formatting will be offered? --Patrick87 (talk) 01:05, 3 June 2013 (UTC)[reply]

P.S. I've used CSS in talk page comments a few times. I often participate in technical discussions about CSS, and it is useful to be able to show how a given piece of styling will appear. Your assumption that CSS is not used in discussions is incorrect. – PartTimeGnome (talk | contribs) 01:41, 3 June 2013 (UTC)[reply]

I am satisfied with your response, Jorm. It was thoughtful and now that you have given it these concerns I have are fully addressed. Unrelated to the stated problem, it seems that both WMF developers and the WM community are dissatisfied with the communication channels between each other. The existing communication resources - for whatever reason - are not meeting my needs, and other people may feel the same way that I do. This problem may or may not be able to be solved, but if it is not solved then I would expect it to continue. Blue Rasberry (talk) 14:29, 2 June 2013 (UTC)[reply]

I've been thinking about this recently, so this is addressed to the problem you raise (not to you directly) ...

There are 2 aspects to the communication channels problems: Quantity, and Location. (This goes for any example, from ARB/ANI decisions, or MoS changes, to site-code changes.)

Quantity of items: Some people want to know about all the hundreds of plans/changes/decisions. Most people only want to know "What's going to effect me?"
Quantity per item: Some people want ALL the details, and will be upset if core aspects aren't mentioned. Some people just want a brief synopsis in clear non-technical English. Some people want terse bullet-point summaries.
Location: There are a large number of locations that people expect/want/wish their news to be browsable. Some people want it all in one spot and only one spot. Some people want each communication placed in a topic-appropriate location and then mentioned in numerous other places (often leading to fragmented conversations at each external "pointer" eg this one which started as a pointer to Mediawiki). Some people want mass-duplication of anything relevant, pasted to everywhere potentially relevant (eg the 3 Flow portals at mediawiki/meta/here).

Add to which: Some people are reluctant to leave their "home" wiki, for a variety of reasons.

On En.Wp alone, we have all of these: WP:Dashboard and Template:Noticeboard links (compendiums), WP:Wikipedia Signpost, WP:CBB, Site notices, watchlist notices, WP:Update, etc

Then the meta/foundation/mediawiki wikis, and their various structured locations for centralized or separated discussion. Plus all the other languages, and all the sister projects in each language.

Plus all the official blogs, unofficial/personal blogs, IRC, and the voluminous mailing lists.

E.g. If we added all the discussions from http://lists.wikimedia.org/pipermail/wikitech-l/ into this WP:VPT, it would be overwhelming. But that's essentially what some people want (I.e. A say in every matter, and every matter brought to their home-wiki, and every matter discussed in the place they feel is most appropriate).

Back to Flow: Based on mw:Flow Portal/Use cases, and a few other pages I've glanced through: the 1 person working on this, and the people assisting/advising/discussing it with him (i.e. Us, and all other wikimedians), might be aiming to partially improve this flawed situation, with Flow itself (as well as dozens of other primary goals). The only way we'll know if it's an improvement, is if something gets built, and tested. So we have 3 options: (1) Provide feedback/bugreports/code/suggestions to improve whatever Flow turns into, or (2) Invent our own superior solution (and build and test it), or (3) [insert negativity] as some did at the start of this thread.

Helping to build stuff is why we're here, so options 1 and 2 are the only ways forward. –Quiddity (talk) 03:14, 3 June 2013 (UTC)[reply]

General comment Concerning 'good faith' - I assume good faith on the part of the Jehovah's Witnesses or Mormons at my door (never at the same time, unfortunately - could be fun, that...). That doesn't mean that I agree with them in the slightest, or have any desire at all to convert to their faith. (I don't assume good faith on the part of the person trying to sell me a new driveway, or telling me that my roof needs urgent repairs.) Part of the trouble down here on the factory floor is that we rarely seem to see the names of the people perpetrating the changes down here in places like NPP, AfD, AfC and so on. They may have been here long ago, or we might have missed seeing them. I would repeat a comment I made somewhere in the OBOD altercations - progress is change, but change isn't always progress. I don't expect the designer of a new machine that makes veeblefetzers to spend months on the factory floor. I would hope that they know what a veeble is, how one fetzes with it, and to have some acquaintance with the working procedures and safety/comfort of the poor bugger that's going to operate the machine. All of which have more importance than do the scrolled handles, the Ionic supporting columns and the chromed dome over the hopper. Peridon (talk) 18:12, 2 June 2013 (UTC)[reply]
- This reminds me a tad of a great story a colleague recently told me. He was hired by this company to redesign their product language model. When he arrived he was witness to a ton of old technology and already smelled trouble. He then designed a new replacement language, that handled everything the old language did, and added a ton of new functionality in the language. It also included an editor, with autocompletion, syntax highlighting and validation, preview rendering etc. His first draft was reviewed. They loved it, but then came responses like: but how are we going to find the line number of this piece of block ? He answered line number? what would you need that for ? Well, we still need it to run on our 80x40 (column x lines) based storage system (small detail, why would you ever spec that... :D ). Turns out their entire storage reference system was based on their old display and interface formats (old Vax systems). He then gave them the only logical answer; if you want to keep using your 80x40 storage system, you better keep using what you have right now, there is nothing modern that will ever map on it. The real question is, why do you want to keep such a storage format, and not invest into replacing it, so that you can use this great new language that could make your products so much more flexible and your people so much more efficient ? The engineers protested loudly about all the systems that they would need to replace and all instability it would bring. My colleague concluded: there is nothing I can do for you, not a single language I design will help you any further.
  We shouldn't have the problem you describe, but we definitely don't want the problem I just described either. The balance has to be somewhere in between. The company in question is almost bankrupt now btw. In their industry, they were like Nokia and suddenly there was the iPhone. —TheDJ (talk • contribs) 19:00, 2 June 2013 (UTC)[reply]

Hi Jorm. I'd like to clarify a few things: you mention we will be able to use templates on Flow boards, and there will be a non-structured area on each page. Am I correct in my understanding that templates will only be allowed in the non-structured area, and not in regular posts?

You also mention that Flow will still be able to use templates from things like Twinkle (albeit internally expanded into HTML). Why can't the same approach be used for comments from editors? Will the ability to use templates in a discussion only be available using the API?

The expansion of templates into HTML effectively means every template would be subst'd. If this were allowed for editor comments, the automatic substitution might confuse editors who re-edit their comments and find they don't look the same, especially if a template has expanded into something lengthy and complex. This could be solved by storing the original wikitext alongside the expanded HTML; the edit page would show the original wikitext and generate new HTML upon saving.

In many of your comments you appear to say that Flow can replace the functionality of all existing templates. Though this might be true for templates that form part of various workflows (RFCs, warnings, edit requests, etc), what about other templates? Various convenience and formatting templates are frequently used in general discussion, such as {{code}}, {{diff}}, {{small}}, {{smiley}} and {{tracked}}. There's also {{tl}}, which I heavily used in the previous sentence. Another common use of templates is demonstration, either to demonstrate the use of a template, or to give an example of a proposed edit to an article (I'm assuming templates will still be allowed in articles). How will we do these things with Flow? – PartTimeGnome (talk | contribs) 23:03, 2 June 2013 (UTC)[reply]

Templates will be allowed in the non-structured area, yes. Or, at least, that's the current thinking. And no, not in the regular posts.

I'm simplifying what will happen significantly but yes, the principle aligns with "substing" everything that goes in. The reason this works for API edits and not "website" edits is that API edits do not (currently) run through anything that the VisualEditor deals with. If the only way for website edits to happen is through the VE, then only VE-pure code happens.

Now, I'm going to be honest: it's highly likely that many templates left by Twinkle and other applications will break. But, as we've done before with other projects, we will be working with the maintainers of those tools to make sure that things are seamless and will require little or no effort from the editor community to account for the changes.

This is not our first time at this rodeo. As it were.

And yes: technically, we will probably store a "wikitext" version of the page. But that version of the page should be considered "cold storage" and not accessible in the moment to moment use of the software (for the performance issues outlined above).

And regarding the templates you described above: roughly half of those templates either are (or should be) natively supported by the VisualEditor, though in other formats (like linking to diffs, or creating font size changes, or source code). Others (smiley) could be trivially implemented with an emoji generator, and the "tracked" template is an ideal candidate for conversion to a Flow workflow.

In other news, I'd still like it if these questions were moved to WP:FLOW.--Jorm (WMF) (talk) 00:38, 3 June 2013 (UTC)[reply]

Okay, the templates I mentioned are supported by VisualEditor. Can the same be said for the hundreds of other formatting/convenience templates used on talk pages? Templates allow regular editors to define new ways to format text that other editors can easily reuse. With VisualEditor, any new formatting options would need to be added by a developer.

Also, you didn't mention how templates or proposed article edits can be demonstrated in Flow. If I wanted to say "template foo will look like bar when used with parameters baz and qux", I would typically invoke the template in place of bar. How would I say this in Flow?

I think the main problem here is this fixation on the VisualEditor. The VisualEditor is a great idea and I support it, but it can never hope to do all the things we do in wikitext, not even on talk pages. As I read it, the main reason you are saying "no templates" is because the VisualEditor does not support it. Furthermore, its dependence on JavaScript means some editors cannot use it. Relying solely on the VisualEditor introduces too many constraints. We really do need the source editor as an option. – PartTimeGnome (talk | contribs) 01:34, 3 June 2013 (UTC)[reply]

As far as people are concerned about Twinkle, please don't be. Twinkle is actively maintained and can be updated to fit any software changes. It is foolish to try to design new software features around local gadgets, of all things. And, who knows, perhaps some aspects of Twinkle will end up being built into Flow itself? — This, that and the other (talk) 01:06, 3 June 2013 (UTC)[reply]

F.L.O.W. - Frustrating Lots Of Workers

Any radical change is likely to be trouble, but complete upheaval, of day-to-day operations, is guaranteed to be terrifying and demoralizing. Of course, if wp:Flow become unbearable, then people could always resort to using WP essay pages as talk-pages (essay "Talk of RMS Titanic"). Even the mere suggestion that templates used in wp:FLOW pages would be subst'ed to HTML is horrific. Perhaps the first horror would be a long template that generates extensive markup such as {{bg|#ccc|This}} which shows "This" but would insert "<span style="background-color: #ccc">This</span>" for every {bg} in a Flow page. Then there is also the pesky trouble of including a calculation adding 20 numbers and reducing the talk-text to only the final result, not easy to modify for adjusted numbers. However, the elephant in the room, for subst'ing templates in Flow pages would be the inability to upgrade system-wide style templates to, retroactively, back-apply the new style into older Flow pages. Templates are not just simple typesetting styles, but rather they are the way to quickly update the population counts of 2,700 towns/cities in Austria, by editing just 10 templates. And they are, also, the way to style wp:WikiProject banners, so all pages could show a similar style, even when enhanced to a new system-wide style in the future. In general, people must understand the concept of a macro scripting language and why the word "macro" is so critically important to easily reading and maintaining data in a word-processing system, and remember that talk-pages are in this same word-processing system. Talk-pages are NOT your grandfather's handheld keypad device to be read by millions of people. No instead, talk-pages are word-processing documents styled and formatted to convey a vast array of information, including data tables and graphical charts calculated by templates and Lua script modules. -Wikid77 (talk) 13:52, 4 June 2013 (UTC)[reply]

Can you stop fear mongering please ? I mean the world can seize to exist tomorrow, but we don't post 300 word essays about that on this page every day either. Still it would significantly impact our capabilities of working on the encyclopedia. —TheDJ (talk • contribs) 15:44, 4 June 2013 (UTC)[reply]

(edit conflict) (false conflict - no other edits)

I am not fear-mongering, and it's not like I said, "FLOW is the secret organization Freakazoid Lunatics Overtake Wikipedia" but I can sense your levels of frustration. I think it would be much more productive to fix the numerous problems with auto-merging of edit-conflicts, both for talk-page replies and for multiple insertions near the same lines in article texts. Some of that work could be called "FLOW" while using the current talk-pages, but with FLOW extensions. Even if the edit-conflicts are not fixed with a formal proof of correctness, yet some heuristic methods could be used to auto-correct most edit-conflicts. I have already noted the need for test-and-set logic, by read-locking the page each time a "new section" is appended, to avoid adding 2 conflicting endings to the same prior revision. Otherwise, wp:FLOW can sound like a scary delusion mistaken about how talk-pages are actually used. The reality is that many talk-pages contain portions of article text, with templates and footnotes, and some cases keep re-revising that text for later use in live articles. Also, people often say, "Edit this talk-page section to see markup" as in

E=mc^{2}

. If you haven't noticed the current fear levels about wp:FLOW, then try rereading those threads. -Wikid77 (talk) 04:38, 5 June 2013 (UTC)[reply]

To correct some of the above:

The expanded HTML won't be visible to users since Flow won't allow you to view or edit the source. Jorm is planning to only allow editing using a cut-down VisualEditor.
Regular users won't be able to use templates at all, so you won't be able to use {{bg}}. HTML expansion of templates only applies to posts by bots and scripts that use the MediaWiki API.
WikiProject banners won't be affected since they will be in the non-Flow "unstructured content" at the top of the page. This behaves like regular wiki pages.

We might end up with essay pages being used for talk (or similar). However, since we can't get rid of Flow, this means we'd have fragmented discussions. Some editors would comment using Flow whilst others would comment on essay pages, causing parallel discussions on the same topic. – PartTimeGnome (talk | contribs) 23:06, 4 June 2013 (UTC)[reply]

Well, it might be more correct to explain how wp:FLOW will not be able to function, realistically, if it worked according to plans suggested in May 2013. So instead, many WP discussions would likely bypass the FLOW-controlled portions of pages, to post talk-pages messages as before in other areas. -Wikid77 04:38, 5 June 2013 (UTC)[reply]

I asked Jorm on IRC and he said that he's not dead-set on disallowing templates – it's just that Flow is going to support whatever VE supports, and it currently doesn't support inserting or modifying templates. But – and this is my own judgment now – it seems to me that the template support will reach useful levels before Flow is anywhere near being fully implemented, so I wouldn't worry about this part too much. Matma Rex talk 19:13, 5 June 2013 (UTC)[reply]

And Brandon achieved what he intended: No one worries anymore up to the day FLOW is due and editors recognize I didn't work as expected. Sorry, Matma Rex, but Brandon mentioned often enough that templates and the like will be most likely gone. I don't believe such excuses that easy. --Patrick87 (talk) 19:53, 5 June 2013 (UTC)[reply]

But is he still planning to disable the source editor for discussion pages? Given that I can't use VisualEditor, that's a bit of a big one for me... – PartTimeGnome (talk | contribs) 20:39, 5 June 2013 (UTC)[reply]

Presumably, there has been a gap analysis to compare what talk pages are used for now with what the new platform can provide. Can we see that please?

In particular, there's talk about whether templates will be allowed or not. Is it just templates or all Wiki markup? One of the primary purposes of talk pages is to talk about their linked pages. In order to discuss edits to the main page, you need to be able to reproduce those edits as closely as possible in the talk page. This includes basic things like text style, size, color, etc. and well as linking to other wiki pages (in various namespaces), interwiki links, and links to web pages. If these are not supported with the same syntax as now, can't they be made to be? If they're not supported at all, of course, it seems like a non-starter.

There are lots of templates that are used to make discussions more clear ({{tl*}}, {{bg}} et. al., {{in5}}, {{done}}, off the top of my head; some not-so-important ones). Are there replacements for each of them?

I'm all for making it easier for newbies to use talk pages, and solving the threading/indenting issues that are now so confusing to them (and us), but, at the core of it, these pages are still about editing wiki pages and, to implement them without wiki markup seems like it will always provide less than what is needed. —[AlanM1(talk)]— 22:32, 9 June 2013 (UTC)[reply]

Re: gap analysis: See mw:Flow Portal/Use cases and the other pages linked in the sidebar there.

Re: templates, I'm not sure, but given that it's still being designed at the moment, I'm sure we'll be able to influence the direction it grows in, and the features that it includes. Mediawiki is the preferred place for those discussions (ie where Jorm is most likely to see them). –Quiddity (talk) 23:28, 9 June 2013 (UTC)[reply]

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

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

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

X!'s Edit Counter

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following list:

Wikipedia technical issues and templates

When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

Several users have expressed that they want the detailed edit stats to be visible without having to optin. I see this as a Privacy concern and I feel the community should answer this question before taking any intiative on this. Should the detailed edit counter remain as an opt-in or should it be an opt-out or not opt-able at all? — Preceding unsigned comment added by Cyberpower678 (talk • contribs) 12:58, 4 June 2013 (UTC)[reply]

Keep opt-in

Opt-out privacy is a joke, and is not privacy at all. While it's certainly not the biggest privacy violation on the Internet, I don't think people have an automatic right to view this kind of data. Oh, and as mentioned below, as long as this is hosted on the toolserver, it can't be changed. There's some German privacy law regarding "profiling of individual user's activity", which requires this kinda thing to be opt-in. --Chris 14:44, 4 June 2013 (UTC)[reply]
Urgh. It's on labs now, and the toolserver version will be shutoff soon.—cyberpower ^Chat_Online 14:51, 4 June 2013 (UTC)[reply]
This is a clear privacy issue, I fail to see how anybody can see otherwise. Giant Snowman 15:02, 4 June 2013 (UTC)[reply]
Believe me, a lot of people on IRC tried. I said I'm not doing it without an RfC.—cyberpower ^Chat_Online 15:24, 4 June 2013 (UTC)[reply]
+1 to Chris's statement: "Opt-out privacy is a joke..." Keep this opt-in. If someone wants to use it for themselves, then it's a few clicks away. If they want to use it to peer into someone else's history, it's for that person to open that door to them. --RA (talk) 15:25, 4 June 2013 (UTC)[reply]
i'm surprised that this is even brought up as an option. an active editor's edit pattern can reveal way too much about them, and the idea that this data should be thrown into the public domain without them actively expressing consent is inconceivable. peace - קיפודנחש (aka kipod) (talk) 17:45, 4 June 2013 (UTC)[reply]
Our contributions are already public record, but for detailed analysis of our edits, which can be used to hound an editor by those who do not assume good faith of the editors intentions, should IMHO be something that should be primarily available to 'Crats or if an editor chooses to make it publicly available. Hopefully, everyone will want increased transparency of our activities, but IMHO it should be a personal choice, rather than something that one has to opt out from.--RightCowLeftCoast (talk) 17:56, 4 June 2013 (UTC)[reply]
The really crazy/creepy folk, the ones that would engage in off-wiki hounding or outing or real life confrontations, don't need X!s tool. Those people are dedicated enough to sift through a lot more than just some graphs. Sven Manguard Wha? 17:02, 8 June 2013 (UTC)[reply]
The fact that some data is public but scattered, is one thing, collecting and organizing the data is something quite different, that is (good part of) the work of Intelligence agencies («intelligence gathering, [...] does not necessarily involve espionage, but often collates open-source information.», from Espionage). WP is not a espionage / intelligence agency, I'd say. - Nabla (talk) 23:07, 5 June 2013 (UTC)[reply]
Per Chris G. It Is Me Here ^{t / c} 17:01, 6 June 2013 (UTC)[reply]
Yes. This is one of the rare questions I have a gut answer to :-). The data is public, and there is nothing stopping people "rolling their own" analysis, but there is a big difference between that and Wikimedia-supported profiling and publication. Andrew Gray (talk) 19:33, 6 June 2013 (UTC)[reply]
Yes. The opt-in steps are easy (even I figured it out), and the privacy concerns are compelling. New editors are probably unaware of the feature, and for some this could discourage participation when they become aware. 78.26 (I'm no IP, talk to me!) 15:46, 10 June 2013 (UTC)[reply]
Very strong support that it should be "opt-in". There are strong privacy concerns. We can expect new users to be unaware that these counters even exist for a substantial period of time before they discover them; that is, if many of them would even discover them at all. I do not think they should be surprised about it when and if they do. This should even be being polled. It's a matter of principle. — Preceding unsigned comment added by Jason Quinn (talk • contribs) 17:39, 11 June 2013 (UTC)[reply]

Remove opt-in and replace with opt-out

As per Tom Morris, this information is not actually private. X!'s edit counter is a quick and efficient way to gauge an editor's contribution history. I think that switching to an opt-out system would help to improve transparency. Some people would feel uncomfortable with their editing patterns being so exposed, so they should still be permitted to opt-out at their discretion. Kurtis ^(talk) 17:46, 4 June 2013 (UTC)[reply]

Remove opt-in completely

This information isn't "private". It's just a compilation of public data. Anyone who has access to the Toolserver or to the API can work this out with very little work. Treating public data as if it were private data leads people to believe that by not opting-in or by opting-out, the compilation of these statistics won't be done. It just means it won't be done by this tool. I mean, let's consider the silliness of this: shall we allow users to "opt-out" from Stalker, Max McBride's tool to compare contributions between users in order to help people detect socking? No. The issue isn't actually privacy in any meaningful sense of the term. The reason it is opt-in is to give people a feeling that they are in control of "private" information, even though it isn't private information and they aren't in control. I'd rather not give people the illusion that this information is private when it isn't. —Tom Morris (talk) 15:45, 4 June 2013 (UTC)[reply]
Who's Max? --MZMcBride (talk) 22:18, 4 June 2013 (UTC)[reply]
Yeah this. The data is publicly available, that tools shouldn't exist which compile it in a usable form seems silly. --Jayron32 17:49, 4 June 2013 (UTC)[reply]
The tool doesn't give you any information that isn't already on the user contribs page, seems silly to have an opt-in, or an opt-out. Though I'd support opt-out over opt-in if we must. Prodego ^talk 18:02, 4 June 2013 (UTC)[reply]
Note that if the tool is hosted on a wikimedia de server, then the opt-in must stay. Prodego ^talk 18:03, 4 June 2013 (UTC)[reply]
It's a helpful tool that uses publicly available information. When unavailable, it just makes finding the information so much harder. I see no real privacy concerns as long as every editors contributions may be browsed. --SmokeyJoe (talk) 21:46, 4 June 2013 (UTC)[reply]
Going a step further to say that user contributions should be scrutinized carefully and this tool helps enable this. Data on editors' contributions should be widely available to combat POV pushing and similar problematic behaviour. There is no privacy issue as contributions are public record. This falls squarely in line with the foundations's privacy policy which reads: User contributions are also aggregated and publicly available. User contributions are aggregated according to their registration and login status. Data on user contributions, such as the times at which users edited and the number of edits they have made, are publicly available via user contributions lists, and in aggregated forms published by other users. [1] Them From Space 23:08, 4 June 2013 (UTC)[reply]
It's simply a tool that takes public data and aggregates it using standard methods. Without the tool, all the information could still be found, but it would just take more work. I see no privacy violation here. -- King of ♥ ♦ ♣ ♠ 23:52, 4 June 2013 (UTC)[reply]
Per Tom Morris. Ironholds (talk) 00:24, 5 June 2013 (UTC)[reply]
Per Jayron32 -- John of Reading (talk) 04:49, 5 June 2013 (UTC)[reply]
Per everyone above. Graham87 04:54, 5 June 2013 (UTC)[reply]
I have never understood why this is opt in. It saves a lot of time on various issues, and therefore should be available freely - especially as there are no privacy issues. Mdann52 (talk) 10:05, 5 June 2013 (UTC)[reply]
@Mdann52: It was opt-in because German law required it. Toolserver is located in Germany.—cyberpower ^Chat_Online 15:07, 5 June 2013 (UTC)[reply]
Per above, if it's moved from a server where it's a legal requirement (damn Germans!). It's not actually private information - just number of edits/month and number of edits to individual articles, both of which IIRC can be found on other tools, associated or not. Ansh666 14:39, 5 June 2013 (UTC)[reply]
@Ansh666: You realized you just damned me, right? The guy who is moving the tools to labs. :p—cyberpower ^Chat_Online 15:07, 5 June 2013 (UTC)[reply]
Heh, oops. Ansh666 20:20, 7 June 2013 (UTC)[reply]
Per all above. ·addshore· ^{talk to me!} 23:11, 5 June 2013 (UTC)[reply]
You cannot make private what has already been publicized. When each datum has been published, nothing new is revealed by summaries and aggregations that users could always perform on their own computers, if they wished. Opt-in or opt-out attempts to weave garments of mixed fibers. DavidLeighEllis (talk) 02:00, 6 June 2013 (UTC)[reply]
Because this information is very easy to gather from the API, which is publicly accessible, and with only very minimal coding skills. Any added privacy from an opt-in is illusory. — Carl (CBM · talk) 02:16, 6 June 2013 (UTC)[reply]
Per supra. Theopolisme (talk) 03:07, 6 June 2013 (UTC)[reply]
I don't understand how there can be a privacy violation. The pages a person has contributed to is something they should be proud of. -- ^(T)Numbermaniac_(C) 07:24, 6 June 2013 (UTC)[reply]
A false sense of privacy. Marcus Qwertyus (talk) 19:08, 6 June 2013 (UTC)[reply]
Per User:Numbermaniac, Not entirely sure how it can be considered a "privacy violation", If you don't want the edit counter being public then don't edit on WP, It's not rocket science!. ........ →Davey2010→→Talk to me!→ 00:15, 7 June 2013 (UTC)[reply]
This is not a privacy issue. We are all responsible for maintaining the integrity of Wikipedia. Transparency is good. Carrite (talk) 06:43, 7 June 2013 (UTC)[reply]
The information is already public! The only thing one needs to work a lot to find those! --Tito Dutta (talk • contributions • email) 00:22, 8 June 2013 (UTC)[reply]
There isn't a real privacy concern here, and I'm someone that takes digital privacy more serious than they should. I see no reason not to remove opt-in. Sven Manguard Wha? 16:56, 8 June 2013 (UTC)[reply]
Suggesting an illusion of privacy with an opt-in is worse than being up front with what this data is. older ≠ wiser 17:08, 8 June 2013 (UTC)[reply]
Useful information, and consistent with the desire for transparency.--SPhilbrick (Talk) 13:08, 10 June 2013 (UTC)[reply]
Activities performed in a public place aren't private.—Kww(talk) 19:29, 11 June 2013 (UTC)[reply]
The information stats isn't a privacy issue as its already available and accessible to all. All this does is compile the information that anyone can already view in an easy format.Blethering Scot 19:33, 11 June 2013 (UTC)[reply]
I fail to see how anybody's editing history is private. On some users I've always wanted to see the detailed stats for some people but they haven't opted in yet. JayJay^{What did I do?} 00:27, 12 June 2013 (UTC)[reply]

Discussion

You need to make your opening statement clearer, explain the situation in greater detail. You say editors "want the detailed edit stats to be visible" - visible to themselves, or visible to the public? Giant Snowman 13:23, 4 June 2013 (UTC)[reply]
I don't see how it can be much clearer. There are users who don't want the opt-in and there are users who want to keep it. So I'm asking the community the simple question. Should the edit counter have the optin?—cyberpower ^Chat_Online 14:10, 4 June 2013 (UTC)[reply]
No, it's still clear as mud. Opt-in to what? Giant Snowman 14:22, 4 June 2013 (UTC)[reply]
Top Namespaces Edits and monthly statistics.—cyberpower ^Chat_Online 14:23, 4 June 2013 (UTC)[reply]
Slightly clearer - but I'll repeat, "visible to themselves, or visible to the public?" Giant Snowman 14:26, 4 June 2013 (UTC)[reply]
Removing optin means visible to the public.—cyberpower ^Chat_Online 14:28, 4 June 2013 (UTC)[reply]
I agree that you should explain it better and also add that those with x number of edits will always be opt-out. I thought anyone could opt-out by simply deleting the page created during opt-in? Also, the options above are not clear to me. What if I wanted all editors to be automatically opt-in? Mohamed CJ (talk) 14:30, 4 June 2013 (UTC)[reply]
@Mohamed CJ: "What if I wanted all editors to be automatically opt-in?" Then you would support the section "Remove opt-in and replace with Opt-out". That section is for making everyone automatically opted-in and they have the option to opt-out.—cyberpower ^Chat_Online 15:00, 4 June 2013 (UTC)[reply]

I'm still not 100% clear, can somebody else please have a go seeing as cyberpower is unable/unwilling? Giant Snowman 14:40, 4 June 2013 (UTC)[reply]
Let me try this again. Currently, all editor are required to opt themselves in to allow everyone to see additional statistics in X!'s edit counter. These are top namespace edits and monthly edit statistics. This opt-in was setup because because of a law in Germany, which toolserver is located in. Since we are migrating to labs, there are users who wish to see other users monthly stats and top namespace without that said user being looked up to have to opt-in. Therefore all data will be readily available without said users consent. The question is should we allow this or should the user still have control over what can be seen in the edit counter, that is should opt-in be removed, or should it be kept, respectively. I'm sorry if this isn't clear either. I'm trying my best to make it clear.—cyberpower ^Chat_Online 14:57, 4 June 2013 (UTC)[reply]
No, that's perfect, exactly what I was looking for! Some of us aren't as technically minded as others... ;) Giant Snowman 15:01, 4 June 2013 (UTC)[reply]
How is it a privacy concern? Anyone who has access to the database (any Toolserver user, say) can work out the most-edited-pages of a user by running the query by hand (or going through Special:Contributions). The reason for requiring opt-in is as much to preserve server resources as is it to give users the illusion that the public information is somehow not public. —Tom Morris (talk) 13:53, 4 June 2013 (UTC)[reply]
Some users wish the compilation of public data to be readily accessible. I am well aware that this is public data.—cyberpower ^Chat_Online 14:10, 4 June 2013 (UTC)[reply]

While certainly true, it doesn't mean we should just give up any attempt at privacy. There's a big difference between anyone with access to the Toolserver (or anyone who can code) being able to work something out, and anyone who can use a web browser. --Chris 14:53, 4 June 2013 (UTC)[reply]
Actually, it's not just anyone with access to the Toolserver. It's anyone with access to the API... which is everybody. —Tom Morris (talk) 15:39, 4 June 2013 (UTC)[reply]
Ok then go ahead. Someone who is not a coder, please work out the namespace totals/month counts/etc for my account. --Chris 02:45, 5 June 2013 (UTC)[reply]
It is rather time consuming, but they could do that by going through Special:Contributions and compiling the statistics by hand. Toolserver (or now Tool Labs) or API scripts are just doing what any editor with the time and inclination could do. There's nothing stopping anyone from creating an off-wiki edit counter that uses the API and shows far more detailed information than X's counter - WikiCounter for instance. I might do so on Tool Labs precisely because I'd like to play around with new fancy charting libraries. —Tom Morris (talk) 04:29, 5 June 2013 (UTC)[reply]
That link is broken.—cyberpower ^Chat_Offline 04:33, 5 June 2013 (UTC)[reply]

Thank you for proving my point. Yes the data is public, but who in the right mind would go through 20,000 edits and count them manually? Yes it would be possible for a dedicated person to work out this kind of information, that does not mean we should make their job any easier. --Chris 05:01, 5 June 2013 (UTC)[reply]
Anyone could download a mirror of the database and run a query to get the same results. It's not limit to TS tool devs.--v/r - T P 13:26, 5 June 2013 (UTC)[reply]
Yes, I completely understand that. What I am saying is that there is a big difference between someone being able to use the API, or a database dump and write a script to generate that information, and someone being able to navigate to a web page and access it at the click of a button. No, it's not perfect privacy, but it is better than nothing. --Chris 13:33, 5 June 2013 (UTC)[reply]
It was an issue on the toolserver due to German privacy laws which are bizarrely strict. Werieth (talk) 14:05, 4 June 2013 (UTC)[reply]
Correct. And I'm very strong on Privacy concerns. Maybe because I'm German too.—cyberpower ^Chat_Online 14:10, 4 June 2013 (UTC)[reply]
I am not sure what this is doing here. I don't see a comment from the user whose account X's tool is on and who would obviously have to agree to these proposed changes, and I don't see a statement from toolserver admins stating that this would be compatible with their ToS, as it was my understanding that it was for ToS purposes that this was impossible. Snowolf ^{How can I help?} 15:40, 4 June 2013 (UTC)[reply]
I also am not sure as to why, if this was a serious proposal, the English Wikipedia would get to decide what happens to a global tool. Snowolf ^{How can I help?} 15:41, 4 June 2013 (UTC)[reply]

It's not toolserver anymore. It's labs. Completely different now.—cyberpower ^Chat_Online 15:51, 4 June 2013 (UTC)[reply]
I don't think it matters if it is on the Toolserver or Labs. It's still a global tool. Snowolf's point stands. Killiondude (talk) 16:22, 4 June 2013 (UTC)[reply]
It is now completely up to the owner of the tool, as Snowolf says. This vote doesn't really matter. Prodego ^talk 18:09, 4 June 2013 (UTC)[reply]
I maintain it too. Right now I have taken up the project if moving it to labs. So it does matter. And I probably will be launching a proposal on meta or redirect a thread to here for more input globally.—cyberpower ^Chat_Offline 18:16, 4 June 2013 (UTC)[reply]
Your time would be much better spent improving and maintaining tools rather than starting discussions like this. :-) If you have coding skills, I'd strongly recommend focusing on coding. We already have enough process wonkery and meta-process wonkery. --MZMcBride (talk) 22:41, 4 June 2013 (UTC)[reply]
To address the issue of the tool's 'owner', I maintain that I inherited the and do not own them and I've taken part in the process, led by Cyberpower, to migrate these tools to labs. I've joined a team, of sorts, that Cyber has termed xlabs and so as these tools move to labs, I am abdicating any sort of psuedo ownership I gained while hosting open source tools that I didn't even design and barely maintained. I'm definitely okay with any changes to the tools as long as it's a team decision and I've address that with Cyber already.--v/r - T P 02:23, 5 June 2013 (UTC)[reply]
toolserver.org/~tparis/topedits/ lists 100 top edited pages of each namespace publicly. wikichecker.com even shows edit counts by hour of day and day of week. So the data is already public.···Vanischenu^「m/_Talk」 22:06, 4 June 2013 (UTC)[reply]
I'd have to agree with Snowolf, this should be a global discussion and not held on enwiki. Enwiki is not in charge of the other wikis. --Rs chen 7754 04:53, 5 June 2013 (UTC)[reply]
If this RfC continues to take this course, we will most likely launch a second RfC on meta before any change is applied, after a discussion with the team.

Any chance we could make it opt-out only for en.wp users? I only ask because meta moves slower than a snail with a brain injury when it comes to policy discussions. Beeblebrox (talk) 03:17, 6 June 2013 (UTC)[reply]

Based on what I'm looking at right now, it doesn't look there's going to be an opt at all. Besides, the change won't go into effect until at least the tools are migrated, debugged, and fully set up.—cyberpower ^Chat_Offline 03:49, 6 June 2013 (UTC)[reply]

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

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

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? - Ka renjc 20:25, 6 June 2013 (UTC)[reply]

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

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

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

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

A question about notifications

I have a question about the new notification system. When I receive a notifcation saying that a certain article has been linked, who actually gets that notification? Everyone who ever edited the article? A certain number of editors with the largest number of edits to the article? Editors who expanded the article a certain amount? A certain number of recent editors? What's the criteria? Beyond My Ken (talk) 18:25, 7 June 2013 (UTC)[reply]

Hello Beyond My Ken. If you go to Preferences → Notifications and mouse-over the little question-mark icon it will tell you "Notify me when someone links to a page I created from an article page." Technical 13 (talk) 18:31, 7 June 2013 (UTC)[reply]

Ah, thank you. I somehow didn't recognize some of the articles as ones that I had created. Beyond My Ken (talk) 20:33, 7 June 2013 (UTC)[reply]

Redirects you create that someone else expands into articles also count as articles you created. – PartTimeGnome (talk | contribs) 21:37, 7 June 2013 (UTC)[reply]

Ah! That helps too!

And speaking of redirects, is there anyway to redirect notifications from my old IDs to my current one? Beyond My Ken (talk) 21:55, 7 June 2013 (UTC)[reply]

Hmm. Not that I know of, but it would be an interesting form of wikistalking if I were able to, say, see anytime User:Beyond My Ken is linked. Perhaps that's why following other usernames beside the one you're logged in to is not supported Killiondude (talk) 21:02, 8 June 2013 (UTC)[reply]

Good point. I've solved the problem by setting notifications on the old account to got to e-mail, so I'll see them that way (if there are any). Beyond My Ken (talk) 22:49, 8 June 2013 (UTC)[reply]

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

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

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

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

(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)[reply]

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

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

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

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

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

Image?

Why is the image in this DYK nom showing up as a picture of Charlieissocoollike?--Gilderien Chat|List of good deeds 22:08, 7 June 2013 (UTC)[reply]

I see File:ZhangZiyi Amfar.jpg with a woman in a black dress. Are you saying you see an image of the man Charlieissocoollike instead? PrimeHunter (talk) 00:43, 8 June 2013 (UTC)[reply]

Yes. However, it is squashed in from the sides and also not in the article.--Gilderien Chat|List of good deeds 16:54, 8 June 2013 (UTC)[reply]

I suspect that your browser is stubbornly ignoring the true file content and is displaying a locally-cached copy which has the same filename. Try a WP:BYPASS. --Redrose64 (talk) 19:19, 8 June 2013 (UTC)[reply]

Thank you, it is now showing the correct image.--Gilderien Chat|List of good deeds 22:55, 8 June 2013 (UTC)[reply]

Elections banner is buggy

We're bound to get complaints about the latest WMF banner "Votes are now being accepted for the Board of Trustees and Funds Dissemination Committee election. Click here to read about the candidates and vote. [ Help with translations! ]" (it's elections, not fundraising, but people will still complain) so I'll kick it off. It's buggy: the cross-in-circle icon closes it as expected; but then it then immediately takes you to meta:Wikimedia Foundation elections 2013. It's not a problem specific to en.wp, since it happens at commons: and fr: too. I'm willing to bet it's not a something to bother bugzilla with, so does anybody know where the relevant file-a-bug page is? --Redrose64 (talk) 09:17, 8 June 2013 (UTC)[reply]

Not sure about the bug-filing page, but the notice is using m:Special:CentralNotice, so some place on Meta would be a good start. Maybe m:Meta:Requests for help from a sysop or bureaucrat? — Mr. Stradivarius ^{♪ talk ♪} 09:47, 8 June 2013 (UTC)[reply]

OK, thanks; from that first link I found Elections_voting_open in which was m:Special:CentralNoticeBanners/edit/Election2013 voting starts and looking at the logs I saw who last modified it, so I posted to their talk page. --Redrose64 (talk) 10:27, 8 June 2013 (UTC)[reply]

Thanks Redrose, I'm looking into this. It may be that the 'box' around that circle isn't big enough and so it thinks you're clicking both the circle and the link at the same time. Jalexander--WMF 22:03, 8 June 2013 (UTC)[reply]

That should be better now, I expanded the invisible 'box' that is the close link and tested on a couple browsers. If anyone has other issues let me know. Jalexander--WMF 22:29, 8 June 2013 (UTC)[reply]

Hidden audio file links

Can someone take a look at Template talk:Infobox IPA#Hiding the linkage. I'm worried that templates are once again managing to hide links to info about audio files.

The importance of additional linkage for audio file templates has been discussed several times before.

"Clean" audio templates with nothing but a play button and no other links shouldn't even be contemplated since they violate our own conditions concerning licensing and information about the creators.

Peter ^Isotalo 15:59, 8 June 2013 (UTC)[reply]

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

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

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

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 [5] 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)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@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)[reply]

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

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

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

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

User e-mail sending speed limit

Tracked in Phabricator
Task T51444

Is there a technical limit on how many e-mails you can send in one peridod (e. g., 1 hour)? --Синкретик (talk) 06:19, 11 June 2013 (UTC)[reply]

Yes, 20 per day. MER-C 07:44, 11 June 2013 (UTC)[reply]

Please give a prooflink. I Assume good faith, but err is human. --Синкретик (talk) 08:16, 11 June 2013 (UTC)[reply]

http://en.wikipedia.org/enwiki/w/api.php?action=query&meta=userinfo&uiprop=ratelimits MER-C 08:26, 11 June 2013 (UTC)[reply]

Thanks. Doesn that mean 20 letters regardless of the receiver? I'm asking because we at Russian Wikipedia had a case of massive e-mail WP:Canvassing at user Pessimist2006's RFA & he failed. --Синкретик (talk) 08:33, 11 June 2013 (UTC)[reply]

That link is for the English Wikipedia. As far as I can tell, the throttle limit is set on a per-site basis; http://ru.wikipedia.org/enwiki/w/api.php?action=query&meta=userinfo&uiprop=ratelimits shows entirely different limits for the Russian Wikipedia. Perhaps this means that global accounts can be spammed by visiting the various Wikimedia projects in turn, sending as many e-mails as possible before reaching the limit, before moving on to the next one. —Psychonaut (talk) 08:41, 11 June 2013 (UTC)[reply]

That should be changed email limit globally! --Tito Dutta (talk • contributions • email) 09:01, 11 June 2013 (UTC)[reply]
- That's probably not easily doable until we actually finish the whole global account migration (SUL). But we should make a bugzilla for it. —TheDJ (talk • contribs) 09:16, 11 June 2013 (UTC)[reply]
  - Support making a bugzilla if that's easy enough to do now. --Синкретик (talk) 11:25, 11 June 2013 (UTC)[reply]
    - There's no need to start an entire Bugzilla just for this one issue. A single report to the existing Bugzilla will suffice. And there's no need to vote for that; just head on over to https://bugzilla.wikimedia.org/ and file the report. —Psychonaut (talk) 13:14, 11 June 2013 (UTC)[reply]
      - Yes, but they may not fulfill it due to absence of consensus. --Синкретик (talk) 13:28, 11 June 2013 (UTC)[reply]
        I've never known the developers to check for consensus here before implementing a very reasonable feature request. If they want to gauge the demand for a feature they'll sooner look at the Bugzilla votes. —Psychonaut (talk) 15:10, 11 June 2013 (UTC)[reply]

- - - - Yes, that is a problem, isn't it. Users should not have to out themselves to report or vote for a bug. LeadSongDog come howl! 16:08, 11 June 2013 (UTC)[reply]

Wow you guys... Tangent much... Let's try to get this back on topic... Has anyone submitted a ticket to bugzilla yet to get a global email limit set once SUL project is done? Jorm (WMF), sorry to bother you, but I'm curious who is lead on the SUL project if you happen to know or can find out. Thanks. Technical 13 (talk) 16:37, 11 June 2013 (UTC)[reply]

I have. --Синкретик (talk) 17:00, 11 June 2013 (UTC)[reply]
- Voted Technical 13 (talk) 17:08, 11 June 2013 (UTC)[reply]
For the record, developers do not look at votes on bugzilla, like ever (Seriously. The vote feature is used like a watchlist for bugzilla for folks who don't like adding themselves as cc on a bug). It is preferred to gather consensus on a wiki page (and usually consensus is required for config changes. Reasonable requests get denied all the time due to lack of consensus [Usually that happens for non-english wikis though]). In regards to Синкретик's question, according to mw:Auth_systems, that would be Chris. Bawolff (talk)
- Noted: Bawolff, In2thats12, RobLa-WMF can one of you ping/echo Chris to this discussion, I can't seem to see a link to his profile on mw: or here on w: Thanks Technical 13 (talk) 19:32, 11 June 2013 (UTC) 19:25, 11 June 2013 (UTC)[reply]
  - btw, I should clarify one thing about my previous comment. Consensus is needed for config changes generally, it is not needed for bug fixes usually (if the bug could reasonably considered to be obviously unwanted behaviour). This request may fall more in the bug fix category than the config change category. Chris's user page is mw:User:CSteipp. Bawolff (talk) 19:47, 11 June 2013 (UTC)[reply]
- I left Chris a message on mw:User talk:CSteipp and now we just wait for a reply. Technical 13 (talk) 11:06, 12 June 2013 (UTC)[reply]
  - He's left a comment on the bug page. He doesn't oppose it. --Синкретик (talk) 13:40, 12 June 2013 (UTC)[reply]
  - [14:00] <Technical_13> Would you mind if I quote your Bugzilla reply on VPT csteipp ?
    [14:01] <csteipp> Technical_13: not at all
    For some background, the limit is currently 20 emails/user for all wikis (that
    was changed from 100 a few months back). That counter is per wiki, so a user
    could send out emails from multiple wikis to the same user, and the target
    would receive more than 20/day.
    
    To move this to a global throttle isn't trivial, but we could do it. It would
    fall into the general Admin Tools work.
    
    Technical 13 (talk) 18:25, 12 June 2013 (UTC)[reply]
    - The email system only lets me send about 1 every other day. I gave up trying to use the Email system. Kumioko (talk) 17:16, 12 June 2013 (UTC)[reply]
      - It's a bug than can be fixed if you report it in details with a new thread here. My restriction request is hardly connected to your problem. --Синкретик (talk) 06:48, 13 June 2013 (UTC)[reply]

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

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

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

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

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

:-( Helder 12:16, 12 June 2013 (UTC)[reply]

Article feedback on the main page

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

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

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

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?--Laun chba ller 17:10, 11 June 2013 (UTC)[reply]

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

No Technical 13, it isn't; it's MenoBot II.--Laun chba ller 17:24, 11 June 2013 (UTC)[reply]

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

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).--Laun chba ller 17:56, 11 June 2013 (UTC)[reply]

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

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

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.--Laun chba ller 20:00, 11 June 2013 (UTC)[reply]

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. [6]
An alpha version of the VisualEditor was enabled on all Wikipedias on June 6. Please test it and report problems. [7]
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. [8]
The logo of 16 Wikipedias was changed to version 2.0 in a fourth group of updates. [9]
A test instance of Wikidata is now available at test.wikidata.org. [10]
Users can now patrol the first version of a newly created page if they visit it from Special:NewPages or Special:RecentChanges. [11]
Translation pages will no longer include edit section links (bug #40713). [12]

Future software changes

A report on mobile upload errors was published, and software changes to reduce their number will come soon. [13]
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)[reply]

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

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

"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/enwiki/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)[reply]

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

Problems with a special character

I would like to know more about this character: "�". If I search for it, Wikipedia will return the following message:

 An error has occurred while searching: The search backend returned an error:

If I try [[�]] or http://en.wikipedia.org/wiki/%EF%BF%BD - it will say "Bad Title".

How can a Wikipedia reader find information about such a character on a Wikipedia article? Thanks. — Ark25 (talk) 06:17, 12 June 2013 (UTC)[reply]

That is the Unicode 'REPLACEMENT CHARACTER' (U+FFFD). See Specials_(Unicode_block)#Replacement_character. --Splarka (rant) 07:29, 12 June 2013 (UTC)[reply]

Thank you! I added the character to the list at Wikipedia:Page name#Invalid page names - the reader will be pointed to the list after getting a "Bad Title" error. — Ark25 (talk) 08:19, 12 June 2013 (UTC)[reply]

I fixed the description as only � is invalid in page titles. The other specials are valid, and in fact the respective one-character-titled articles all exist (as redirects): FFF9, FFFA, FFFB, FFFC. However, something is wrong with search: for example, [14] gives the error message you mention above, while [15] works. In fact, searching for � also works if there is more text in the search box [16]. This sounds very much like a bug to me.—Emil J. 18:29, 12 June 2013 (UTC)[reply]

I get the same message searching for a pipe character: thus. LeadSongDog come howl! 19:02, 12 June 2013 (UTC)[reply]

Apparently the bug is already tracked at bugzilla:47761.—Emil J. 11:00, 13 June 2013 (UTC)[reply]

In this case, I think the search engine should a similar message to the one at [http://en.wikipedia.org/� Bad title] when you get a search error. The red error message should be shown alone only when there is an unknown error. — Ark25 (talk) 00:26, 13 June 2013 (UTC)[reply]

There likely is an unknown error. Why would the search engine ever complain about a bad title? It is supposed to search through articles that exist, not those that don’t.—Emil J. 10:36, 13 June 2013 (UTC)[reply]

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

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

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

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

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

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

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

I installed pop-ups and they seem to work fine at <https://en.wikipedia.org/enwiki/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)[reply]

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

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/enwiki/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)[reply]

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

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

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

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: [17], 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)[reply]

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

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

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

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

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

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

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

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

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

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

See the bottom of http://en.wikipedia.org/enwiki/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)[reply]

VisualEditor breaks BLP warnings

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

{{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)[reply]

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

Template:AFC statistics

Thanks to whoever got the Template:AFC statistics page working again. It's so much nicer reviewing pages from there with the additional information provided. —Anne Delong (talk) 23:16, 12 June 2013 (UTC)[reply]

I think The Earwig and their bot updates the page, so they deserve the praise. Bgwhite (talk) 07:25, 13 June 2013 (UTC)[reply]

It was an AFC group effort. Earwig updated the bot, I lightened the template some, and someone (I don't remember who) replaced part of the template with a Lua component to make it lighter and cleaner. Technical 13 (talk) 11:41, 13 June 2013 (UTC)[reply]

The last one is Martijn Hoekstra. — Earwig ^talk 14:55, 13 June 2013 (UTC)[reply]

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

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

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

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

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

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

We also have no say over websites such as Deletionpedia. Giant Snowman 15:56, 13 June 2013 (UTC)[reply]

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

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

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

You should provide one. Giant Snowman 16:19, 13 June 2013 (UTC)[reply]

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

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

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

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

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

As BWilkins says above, I'm not sure this counts. Giant Snowman 16:44, 13 June 2013 (UTC)[reply]

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

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

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

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

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

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

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

Well, yeah, it's the same as any other page. Just do https://en.wikipedia.org/enwiki/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)[reply]

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

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

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

Bolding on watchlist despite preference set for no bolding

I noticed that pages I haven't visited since they were last updated just started appearing in bold on my watchlist. I have the preference set under gadgets to not have the bolding, but the bolding is showing up despite the preference. I tried turning the bolding on in the preferences and then back off, but that did not fix the problem. Is there some sort of bug with the bolding/no bolding option? Just before the bolding started showing up, I visited Special:Newpages . . . could that have somehow affected my watchlist? Calathan (talk) 18:18, 13 June 2013 (UTC)[reply]

this setting works for me as advertised. try to do a deep-refresh (assuming ff, chrome or ie on windows, press Ctrl+⇧ Shift+Delete, and select whatever your browser use for "drop/forget/delete cache/temporary files". if you use a different browser or os, look in the browser's menu how to completely purge the cache), and see if this solves the problem.

also, if you use a skin other than vector, try it with vector. if you find that the problem is skin or browser related, please report your findings. peace - קיפודנחש (aka kipod) (talk) 18:27, 13 June 2013 (UTC)[reply]

Oh, what a headache. Literally...the bold is horrendous. 1. I have checked my preferences under gadgets and indeed have bolding for watchlist unselected. 2. I just performed the "detete temporary internet files" routine (thanks for the neat keypress info...) 3. I temporarily changed my skin from Modern to Vector. None of this mattered one iota. I still have pages bolded. The only way I can keep from getting a migraine is to click "mark all pages visited" each time I check my watchlist; which only works for a moment because I have nearly a thousand pages I watch, some of which are quite active (like this one). This is new, unexpected and unliked. Fylbecatulous talk 18:45, 13 June 2013 (UTC)[reply]

I have purged the cache, I'm not on compatibility mode, and the option isn't selected in my preferences. Giant Snowman 18:51, 13 June 2013 (UTC)[reply]

I've also tried the suggestions קיפודנחש gave, and they did not fix the problem. I'm using MonoBook, but the bolding was still present when I switched to Vector. I also deleted the cache/temporary Internet files, but that didn't solve the problem. The bolding is still present. Calathan (talk) 18:54, 13 June 2013 (UTC)[reply]

It's not working for me either. Roger (Dodger67) (talk) 18:58, 13 June 2013 (UTC)[reply]

the problem seems to be real, but it only materialize with IE - for ff and chrome this preference seem to work as advertised. this is the probable cause - i venture a guess that the person who created this gadget use some browser other than IE. i left him a message asking him to take a look at this topic. peace - קיפודנחש (aka kipod) (talk) 19:27, 13 June 2013 (UTC)[reply]

It worked perfectly on IE for about a year, why would it suddently change? Roger (Dodger67) (talk) 19:38, 13 June 2013 (UTC)[reply]

If it is an IE issue, try toggling "compatibility" mode... Technical 13 (talk) 19:44, 13 June 2013 (UTC)[reply]

As I've already said, that doesn't work. Giant Snowman 19:48, 13 June 2013 (UTC)[reply]

I have IE10. I see nothing that applies to me on the "Compatability mode" choices...so I too am not on combatability mode and don't intent to tinker, actually. I agree: what has happened? I've been upgraded to IE 10 as long as it has been available. Fylbecatulous talk 20:00, 13 June 2013 (UTC)[reply]

This is probably an issue now when it wasn't for the last year because of the recent introduction of green bullets on the watchlist. I believe these use some of the same classes as watchlist bolding; the bolding gadget was probably changed to accommodate this. – PartTimeGnome (talk | contribs) 22:08, 13 June 2013 (UTC)[reply]

I think I fixed it. As usual, IE is retarded enough to miss the the finer points of CSS; it does not seem to understand what 'inherit' means. — Edokter (talk) — 20:04, 13 June 2013 (UTC)[reply]

I've logged out, re-purged and opened a new browser - still big'n'bold. Giant Snowman 20:08, 13 June 2013 (UTC)[reply]

Seems like another, unfortunately increasingly typical, change to the system that has not been properly tested. Why does Wikipedia allow any editor to install any changes without a full test on all browsers? I have complained several times before about such changes and received very arrogant responses along the lines of "it's your fault for using IE" or as described above "IE is retarded"

NO - like it, or hate it, IE is the most used browser in the world, if any change has not been fully tested in all standard browsers it should not be allowed to be implemented. I've made this point before, and it was described as "unrealistic", although no reason or justification was made for this claim. As it is, my editing has been severely hampered for months by the toolbars dropping into the edit pane, due to another so-called "improvement" that caused more damage than good.

Wikipedia has been wondering why experienced editors leave - whilst ignoring repeated requests not to "fix" things that are not bust. We need a simple, basic interface which editors can add to by selecting options in My Preferences, not an increasingly complex interface that requires editors to install complex lines of code to disable them, if they can find this code hidden on some obscure page. Arjayay (talk) 20:31, 13 June 2013 (UTC)[reply]

Wikitech-l: Features vs. Internet Explorers. Helder 21:11, 13 June 2013 (UTC)[reply]

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

{{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)[reply]

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

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

Bolding on watchlist has gone away, please give it back

Please give me the bolding marks on the watchlist back, since the update today they have gone away. It have been told in the meantime that they now only can be seen, when someone has a functionating (newer version of) JavaScript in the browser. But that again is not what unobtrusive JavaScript is about. First no notifications here anymore and no possibility to change interwikis anymore because of Wikidata, now these changes back again, what comes next? WD:Flow#‎Flow without javascript, the VisualEditor, what else should be feared to get live some day?

Shall it not be possible anymore to edit Wikipedia without scripts? Why? Why shall WP editors be forced to new systems, new browsers, new scripts? Does the Foundation want to drive editors away who are not compatible with that what the Foundation wants? If this kind of driving away the editors will continue in the future, then the editors will be away someday, yes. But why do you want this to happen? I thought that there would be a reaching-out for new editors. But it seems to be that theses new editors must meet some technical conditions which are set by the Foundation. That’s really a pity. Everyone should be able to edit WP. Also in the future. Can you please take a look upon Wikipedia:Petition to the WMF on handling of interface changes before changing such things? --Geit ost 22:14, 13 June 2013 (UTC)[reply]