→Resolution: No personal attacks |
→A polite version of "Fooled you again suckers, haha" from Jdforrester (WMF) to enwiki.: (uninvolved) chg hdg per Qgil-WMF's comment, which is quite correct |
||
Line 435: | Line 435: | ||
:[[meta:Meta:Requests for help from a sysop or bureaucrat#Iberocoop Translating Ibero America]] - [[User:NQ|'''NQ''']] [[User talk:NQ|<small>(talk)</small>]] 02:18, 11 May 2016 (UTC) |
:[[meta:Meta:Requests for help from a sysop or bureaucrat#Iberocoop Translating Ibero America]] - [[User:NQ|'''NQ''']] [[User talk:NQ|<small>(talk)</small>]] 02:18, 11 May 2016 (UTC) |
||
== A polite version of "Fooled you again suckers, haha" from |
== A polite version of "Fooled you again suckers, haha" from WMF to enwiki. == |
||
{{tracked|T132806}} |
{{tracked|T132806}} |
||
Some of you may remember [[Wikipedia:Village pump (technical)/Archive 145#VE was imposed as primary editor]] and the subsequent [[Wikipedia:Village pump (technical)/Archive 146#Earth to JDForrester]]. Basically, before the new release of the choice of editing environment (wikitext or VE) in April, [[User:Alsee]] asked [[User:Jdforrester (WMF)]] explicitly that wikitext would be the default for new editors at enwiki, and was promised quite clearly that this would be the case. |
Some of you may remember [[Wikipedia:Village pump (technical)/Archive 145#VE was imposed as primary editor]] and the subsequent [[Wikipedia:Village pump (technical)/Archive 146#Earth to JDForrester]]. Basically, before the new release of the choice of editing environment (wikitext or VE) in April, [[User:Alsee]] asked [[User:Jdforrester (WMF)]] explicitly that wikitext would be the default for new editors at enwiki, and was promised quite clearly that this would be the case. |
Revision as of 09:27, 13 May 2016
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
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.
Tech News: 2016-17
21:02, 25 April 2016 (UTC)
Change of "Save page" button to "Publish"
The use of Publish instead of Save Page would look more confusing IMO as many experienced users are already used to saving pages. Publishing would mean it's final, and Wikipedia itself is not final. Was there community consensus or Meta discussion on that change? And will this go live together with the new MediaWiki version? 49.148.95.70 (talk) 04:05, 27 April 2016 (UTC)
- Some documentation would need to be changed … --Pipetricker (talk) 09:03, 27 April 2016 (UTC)
- "as many experienced users".. Please note that these people are far fewer than that globally there are (potential, incidental or inexperienced) users of the MediaWiki software. Just saying. —TheDJ (talk • contribs) 10:54, 27 April 2016 (UTC)
- And every save is final, because every action is public and logged eternally. It's a matter of perspective. —TheDJ (talk • contribs) 10:58, 27 April 2016 (UTC)
- Comment on the phab tickets - I can't see any good reason this shouldn't be able to be controlled via a local variable such as Mediawiki:Save-button-label. — xaosflux Talk 11:10, 27 April 2016 (UTC)
- Is it like a localization to Wikipedia? 49.148.95.70 (talk) 11:17, 27 April 2016 (UTC)
- It's currently controlled via MediaWiki:Savearticle but will apparently change to MediaWiki:Publishpage.[6] The wording is also being changed in the VisualEditor interface, in other wikis, and presumably in many foreign languages when they catch up. The transition may cause some confusion but there will probably be more long-term confusion if the English Wikipedia decides to override a coming "Publish page" default. PrimeHunter (talk) 11:33, 27 April 2016 (UTC)
- (edit conflict) The current save button uses MediaWiki:Savearticle. Use to find it out once its deployed. Also, blah
en-gb
blah blah always broken. — Dispenser 11:46, 27 April 2016 (UTC)
- Is it like a localization to Wikipedia? 49.148.95.70 (talk) 11:17, 27 April 2016 (UTC)
- I missed on that one. Was there a discussion in this Wikipedia about the change? The discussion in the link is to Phabricator, not necessarily about Wikipedia, and many users may haven't been aware until the bot message was posted here. 49.148.95.70 (talk) 11:17, 27 April 2016 (UTC)
- Comment on the phab tickets - I can't see any good reason this shouldn't be able to be controlled via a local variable such as Mediawiki:Save-button-label. — xaosflux Talk 11:10, 27 April 2016 (UTC)
- And every save is final, because every action is public and logged eternally. It's a matter of perspective. —TheDJ (talk • contribs) 10:58, 27 April 2016 (UTC)
- "as many experienced users".. Please note that these people are far fewer than that globally there are (potential, incidental or inexperienced) users of the MediaWiki software. Just saying. —TheDJ (talk • contribs) 10:54, 27 April 2016 (UTC)
- I think this is very unwise. "Publish" is not a good word and is confusing (especially for non-native English speakers who come here). "Save" (or "Post") is simple, direct, common, and easily understood. "Publish" is entirely inaccurate. How did the word "publish" get so corrupted that someone wants to use it for single impermanent iteration of a Wikipedia page that could get reverted by someone else within seconds? Softlavender (talk) 13:35, 27 April 2016 (UTC)
- Actually, they've been talking about this for years, and multiple studies with users say that this change needs to be made. Inexperienced people consistently believe that "Save" means "Save inside my personal account, but don't show it on the web". And because of a lifetime of being told to "save early, save often", they often save before trying to do something that feels risky to them – like "Show preview". I'm looking forward to this change, because it looks like there will be less confusion for new editors and consequently less mess for the rest of us to clean up. Whatamidoing (WMF) (talk) 17:19, 28 April 2016 (UTC)
- @Whatamidoing (WMF): I can believe your argument about "save" versus "publish". But how the hell does "show preview" feel risky? Can you point me to these studies you're talking about? Thanks. BethNaught (talk) 07:07, 3 May 2016 (UTC)
- Our implementation of Show preview is different from any common UI paradigm in or out of a browser. In my experience it is unique to Wikipedia. The entire edit interface is like that, where clicking Back after a save inexplicably and counterintuitively drops you back into the editor. The whole damn thing seems clunky and 1980s-ish, which no doubt contributes to the difficulty of retaining editors from non-tech backgrounds. But that's off topic.
As for "save" vs "publish", I can only say that "publish" would have been less intuitive to me as a new editor, since I didn't come here to publish anything. That said, the uncertainty will be very short-lived for the new user. Absent any other button that looks like it will commit their edit, they will probably click Publish and discover what it does. I don't think the problem will turn off many editors who are motivated enough to last in this environment longer than a few days anyway. After a few edits, it won't matter if the button says save, publish, or XYZ; they will know where it is and what it does. ―Mandruss ☎ 07:49, 3 May 2016 (UTC) - Beth, there really isn't anything to read. Most of these are face-to-face studies, with a researcher and a user sitting down together and seeing whether the user can figure out how to edit a page, and ask them to talk about what they're doing and thinking. The researchers then summarize their notes, which – if we're lucky – eventually get posted to Commons, but (of course) not all the researchers are in the WMF, so not all of them think to do this. And even when the reports are published, the content is unfortunately as minimal as what I've just told you. For example, from a recent one study about the visual editor (still unpublished, AFAICT), the sole content about Save/Publish out of 17 slides is just seven words: "Confusion about whether 'save' also meant 'publish'". If you then go talk to the researcher, you can get more information, but there really isn't anything to read. It'd make a horrible source for supporting a claim in an article. As a result, what I know about "users feel that 'Show preview' is risky" is: users feel that 'Show preview' is risky. Maybe they worry that their computers crash easily? Maybe they had "save early, save often" drilled into them from any early age? Maybe it's just the order of the buttons (Save page, then Show preview, then Show changes)? I don't know. But that's the fact: many newbies feel like 'Show preview' is a risky button, so they want to do something 'safe', like saving their work, before they try it.
I also agree with Mandruss' comment: Experienced editors really don't look at the button anyway. This change is about getting people past their first couple of edits (well, and doing whatever makes Legal happy, of course). Whatamidoing (WMF) (talk) 17:18, 3 May 2016 (UTC)- One of the Asian Wikipedias - I think it's zh: - doesn't allow "Save page" until you've used "Show preview". --Redrose64 (talk) 18:02, 3 May 2016 (UTC)
- Yes, it's the Chinese Wikipedia. I suspect that experienced editors here would find that very annoying, but since Chinese is a dual-script wiki (the articles can be written in a mix of simplified and traditional characters, but displayed entirely in whichever one the reader prefers), that has probably saved them a lot of grief. It might make sense for all of the "language variant" wikis (Gan, Inuktitut, Kazakh, Kurdish, Serbian, Tajik, Uzbek) to try that. Whatamidoing (WMF) (talk) 18:11, 3 May 2016 (UTC)
- This is a very strange basis on which to make even fairly trivial UI changes. I don't see how, on the basis of the data you apparently have, you can say this is a "fact". It's a second-hand report of a handful of observations, with no information about how these test users were selected, whether this alleged confusion was a significant barrier to otherwise productive editing, or whether the use of "publish" as the button label actually reduced their confusion. Do an A/B test and show that it makes a difference in the aggregate for a reasonable sample of the actual user population and then roll out the change. Opabinia regalis (talk) 18:41, 3 May 2016 (UTC)
- I'd like to A/B test the world, but what do you measure here? An increase in the total number of edits, a decrease in the number of edits that have to be suppressed to remove non-public personal information, a quarter-second shaved off the average edit time for first edits because a fraction of users spent less time wondering what the button did (How do you even figure out if it's a first edit, rather than someone who has been editing as an IP or under a different account, since you can't ask them directly?), a decline in the number of test edits saved, a decrease in the number of people who are in legal jeopardy because they "Published" libel on the web when they meant to privately "Save" it on a computer? I think that the UX people are right: sometimes it makes more sense to interview people, figure out which ones are truly new users, directly watch what they do, see when they hesistate or get strange looks on their faces, and then directly ask them what their problems are. An A/B test is never going to produce a result that says something like, "I'm not really sure if clicking this button will save my work privately on my computer or will publish it on the web." Face-to-face user tests, however, have produced that result – repeatedly, in multiple studies, with many new users. Whatamidoing (WMF) (talk) 18:16, 4 May 2016 (UTC)
- Well, you said there would be "less mess" to clean up if this change is made, so you must have some idea of what the effects are. What was the observed effect of this "confusion" in the user tests? Did people who professed confusion try to save very short pages, or pages with placeholder text? Did they make more obvious test edits? Post their phone numbers? Were these people able to make productive edits after the confusion was cleared up, even if it took a human directly telling them how the interface worked? Were any users tested with the button labeled "publish" and if so, what if anything did they do differently? I realize this isn't science and isn't a research project and doesn't have unlimited resources, but surely at least the proposed revision was tested to see if it addressed the problem, or created any new ones. The logical metric for a larger-scale sample is whatever observations were made in the pilots. I just don't see how you (or anyone) can be confident that this is a problem, and be confident that this change will solve the problem, and yet have no idea of how to measure whether the problem was solved. Opabinia regalis (talk) 02:12, 5 May 2016 (UTC)
- I'd like to A/B test the world, but what do you measure here? An increase in the total number of edits, a decrease in the number of edits that have to be suppressed to remove non-public personal information, a quarter-second shaved off the average edit time for first edits because a fraction of users spent less time wondering what the button did (How do you even figure out if it's a first edit, rather than someone who has been editing as an IP or under a different account, since you can't ask them directly?), a decline in the number of test edits saved, a decrease in the number of people who are in legal jeopardy because they "Published" libel on the web when they meant to privately "Save" it on a computer? I think that the UX people are right: sometimes it makes more sense to interview people, figure out which ones are truly new users, directly watch what they do, see when they hesistate or get strange looks on their faces, and then directly ask them what their problems are. An A/B test is never going to produce a result that says something like, "I'm not really sure if clicking this button will save my work privately on my computer or will publish it on the web." Face-to-face user tests, however, have produced that result – repeatedly, in multiple studies, with many new users. Whatamidoing (WMF) (talk) 18:16, 4 May 2016 (UTC)
- One of the Asian Wikipedias - I think it's zh: - doesn't allow "Save page" until you've used "Show preview". --Redrose64 (talk) 18:02, 3 May 2016 (UTC)
- Our implementation of Show preview is different from any common UI paradigm in or out of a browser. In my experience it is unique to Wikipedia. The entire edit interface is like that, where clicking Back after a save inexplicably and counterintuitively drops you back into the editor. The whole damn thing seems clunky and 1980s-ish, which no doubt contributes to the difficulty of retaining editors from non-tech backgrounds. But that's off topic.
- @Whatamidoing (WMF): I can believe your argument about "save" versus "publish". But how the hell does "show preview" feel risky? Can you point me to these studies you're talking about? Thanks. BethNaught (talk) 07:07, 3 May 2016 (UTC)
- Actually, they've been talking about this for years, and multiple studies with users say that this change needs to be made. Inexperienced people consistently believe that "Save" means "Save inside my personal account, but don't show it on the web". And because of a lifetime of being told to "save early, save often", they often save before trying to do something that feels risky to them – like "Show preview". I'm looking forward to this change, because it looks like there will be less confusion for new editors and consequently less mess for the rest of us to clean up. Whatamidoing (WMF) (talk) 17:19, 28 April 2016 (UTC)
- Comment: apparently, this is just changing the default, which is overridable with the local MediaWiki: message. So there's no need to harangue the engineers if you don't want this to happen here. BethNaught (talk) 07:07, 3 May 2016 (UTC)
- Comment: the word "Publish" has commercial implications, so I'm not sure that's the best choice. My suggestion would be "Update". Praemonitus (talk) 21:24, 9 May 2016 (UTC)
- Many words have many connotations, but that's not necessarily the same as implications. I'm not aware of a commercial implication due to the word publish, however there is a important effect on copyright. That already applies to us, wether we say Save or Publish, and publish would again be more accurate. —TheDJ (talk • contribs) 18:02, 10 May 2016 (UTC)
- Comment: WordPress uses "Publish" for new posts, but "Update" for changes; Twitter uses "Tweet" (which seems more similar to "Publish" than "Save"), and doesn't permit editing; Nextdoor.com uses "Post" or "Post event" for new posts but "Done" when editing a post ("Save changes" when editing an event). Those are the only platforms I'm familiar with, other than Facebook, which waits for the first [Enter]/[Return] press to save/publish a post (if you subsequently edit that post, you click "Save" to end your editing). I welcome others to add (common) examples (Instagram?); I'll only note that the button label in question doesn't distinguish between creating a page and editing an existing page; that's actually quite unusual for common web platforms. -- John Broughton (♫♫) 19:45, 10 May 2016 (UTC)
- Comment Yes this may save some clean-up. But the resistance to pressing "publish" is a bad thing, we have too few people willing to make edits as it is. Gender gap research indicates that lack of confidence is one of the key inhibitors for women and girls, this change might exacerbate that issue.
- All the best: Rich Farmbrough, 19:18, 12 May 2016 (UTC).
Watchlist getting stuck
For quite a while now, ever since the last big update, when I try to bring up my Watchlist it takes ages - much MUCH longer than bringing up Contributions or getting to the Main Page. But this afternoon I have been unable to even get to my Watchlist. Sorry if I missed the memo (lol) but does anyone know what is going on? Thanks, Shearonink (talk) 21:11, 28 April 2016 (UTC)
- I'm having this problem too, Safari 6.1.6 (yes, I know, haven't updated). I managed to log on using Chrome, deleted my watchlist, then tried logging in with Safari and had no problem. I started reloading the watchlist a bit at a time, and after adding all the As, which was okay, then the Bs and then I got a message telling me there are too many pages to load (the entire watchlist - all of it – is barely over 2000, so As and Bs is a small number). Have we stopped supporting old versions of Safari? Victoria (tk) 01:21, 29 April 2016 (UTC)
- Adding: I tried to go to my contribs to comment out the scripts I have on my .js and other pages and hung when I clicked "contribs" so I think it's more than the watchlist. Victoria (tk) 01:28, 29 April 2016 (UTC)
- Nice to know I'm not the only one. Haven't tried Chrome, am running on Safari atm, but haven't been able to access my Watchlist at all today. Is anyone else having this issue? Shearonink (talk) 03:09, 29 April 2016 (UTC)
- "Have we stopped supporting old versions of Safari?". Officially not yet, but that is probably because no one thought about taking that action yet. It is really hard to support older versions of Safari, because it is a tiny group of the userbase, and because it is very difficult for developers to run older versions of
Mac OSSafari (basically you need a 2nd mac that you don't upgrade). I would say that Safari 8 and up is what is effectively supported. —TheDJ (talk • contribs) 09:08, 29 April 2016 (UTC)- Thanks for the answer. But upgrading sounds like a hassle, especially since I don't have any trouble on any other website; I think I'll just stop editing. Richard75 (talk) 09:12, 29 April 2016 (UTC)
- You can consider using a different browser. Also, reports like this, will probably cause older Safari versions to be degraded from our list of 'Modern' to 'Basic' support, where all Javascript enhancements (the most likely cause of any problems) are no longer enabled for you. —TheDJ (talk • contribs) 09:17, 29 April 2016 (UTC)
Ok, thanks. The problem might not be with the browser, though, and I'm not sure how to respond to the "the reports like this … " part of this. I managed to load 500 pages back to the my watchlist and it worked, then it hung again when I loaded the next 100. So basically, just reporting that when I try to log in, when I try to view my watchlist, (and last night trying to view diffs, page history, and contribs) it hung. So there's an issue somewhere. Victoria (tk) 12:16, 29 April 2016 (UTC)Struck old - these conditions no longer apply. Victoria (tk) 21:37, 29 April 2016 (UTC)
- You can consider using a different browser. Also, reports like this, will probably cause older Safari versions to be degraded from our list of 'Modern' to 'Basic' support, where all Javascript enhancements (the most likely cause of any problems) are no longer enabled for you. —TheDJ (talk • contribs) 09:17, 29 April 2016 (UTC)
- Thanks for the answer. But upgrading sounds like a hassle, especially since I don't have any trouble on any other website; I think I'll just stop editing. Richard75 (talk) 09:12, 29 April 2016 (UTC)
- Since yesterday I've gone from being unable to view the watchlist, contribs, page histories, spent many hours trying to troubleshoot, and now get a complete freeze trying to log in. I think that it would nice if the three people posting to this thread who are experiencing similar difficulties could have a little more troubleshooting help other than being told that the browser isn't supported, please update. I get update messages from other websites and usually I have months to do the updating. Here it has to be done after the fact. And in the meantime you're locked out. Victoria (tk) 21:37, 29 April 2016 (UTC)
- Here's what I found out: My guess is you are using Lion or Mountain Lion as your operating system, and this means you are unable to upgrade to a more recent version of Safari. Safari 6.1.6 came out in August 13, 2014. It's not realistic for us to have to maintain compatibility with outdated browsers indefinitely. It looks like you have two options at this point: Switch to Chrome, or upgrade your browser to El Capitan so that you can upgrade to the most recent version of Safari. I use Chrome almost exclusively, as I find it is the best browser for the type of work I do here on Wikipedia (operating system is Mavericks). I suggest you give it a try, as this is a simple fix. — Diannaa (talk) 14:09, 30 April 2016 (UTC)
- Hi Diannaa, thanks for replying. You're right, I need to update to El Capitan, but don't have the time to do it immediately (and it wasn't on my list of things to do during the winter), and I think that's my frustration that this came out of nowhere. The issues are to do with loading any page and it doesn't matter if I'm logged out or not, i.e. if I'm reading an article while logged out and click a wikilink it freezes (and it's a really terrible freeze). Surely I'm not the only person who is lazy about updating. I understand that we can't support all browsers or older browsers; I do get that. But it seems a disservice, is the point I'm trying to make, and I don't have trouble reading or accessing any other websites. When that begins to happen, I know that it's time to update, but I'm surprised that it's Wikipedia that's forcing it, is all. In the meantime, I dumped my entire watchlist, which allowed me to log in and I was able got here using the search function. Victoria (tk) 16:38, 30 April 2016 (UTC)
- The problem is very simple. We need to find someone with enough technical skill who can 'figure' out why this is occurring. Now those people generally tend not to run Safari 6 on Lion, can't easily downgrade to that, and can't easily install it from scratch. Simple problem, hard solution. It's not a disservice, it's a practicality. In the mean time, I've filed a bugreport (which anyone could have done), but Victoria, could you please check if you have the same problems on other language versions of Wikipedia or sister sites ? Just to make sure that it is not a problem specific to this site ? —TheDJ (talk • contribs) 17:37, 30 April 2016 (UTC)
- Hi TheDJ, that's a good point. While logged out I went the main page and clicked today's featured article, clicked through the first link, tried to click that page's history and froze. Also, while logged out, I went from the TFA to the German version, was able to click through a few links, and was able to open the page history without freezing. I can log into Commons and load my watchlist there. I was also able to click history on a file without freezing. So it seems to be an issue with en.wp. Basically if I click anything that's blue here, whether or not I'm logged in, it freezes and I have a very hard time getting out of the freeze. My concern is not so much whether I can edit, because I haven't been much recently, but whether it's feasible to add some sort of notification to anyone using Lion/Safari 6.xx that Wikipedia doesn't support the browser, instead of causing an ugly freeze. P.s trying to preview causes in edit conflict, so apologies for mistakes. Also, thanks for filing the bug report. Victoria (tk) 18:20, 30 April 2016 (UTC)
- Hm, that is strange. Do you have any Gadgets enabled in your preferences per chance ? —TheDJ (talk • contribs) 19:53, 30 April 2016 (UTC)
- TheDJ, yes, I have gadgets and I can turn them all off and then work through to test each one, but until I'm able to put back my watchlist I won't be working under normal conditions. Before posting here, while still logged out, I tried to get click the history tab of the TFA on the main page and froze again, so it seems the issue is more to do with the OS/browser rather than whether logged in user or not. My sense is that during the server updates something got changed with the way pages are called and it's now not compatible with Lion/Safari 6.xx Victoria (tk) 21:15, 30 April 2016 (UTC)
- Victoriaearle Right, after the earlier reply, I realized i myself had an old mac in storage somewhere, so I spent some 4,5 hours to revive it and I can confirm that I see the same problem. It has nothing to do with Javascript, since it still crashes if I disable Javascript. It very much looks like the Safari rendering engine just dies on something that we feed it (probably a CSS statement of some sort). I see the same problem on the german Wikipedia, but not on the Dutch wikipedia, which is .... most peculiar to say the least. The cause is most definitely a bug in Safari, but which one it is and what the exact trigger is will take a bit more time to figure out. —TheDJ (talk • contribs) 23:04, 30 April 2016 (UTC)
- TheDJ, yeah I've hacked at it a bit too since Friday and it does show very odd and inconsistent results, but I've been doing a lot of cache-clearing and restarting, which might have something to do with it. The thing is, my machine isn't ancient - 2012 model Macbook pro – and I chose to skip the Mavericks update because it had problems when released. If we're finding these issues on the other wikipedias then I have to wonder how many people in the world run four-year-old machines who haven't updated in two years and are experiencing these freezes/crashes and if that's what we want? I don't have any issue with other major websites at all yet – only here. If I want to edit here I'll use Chrome as Diannaa suggests above until I get around to doing the necessary backing up (I have tons of files ). Thanks for spending time with this. Victoria (tk) 01:15, 1 May 2016 (UTC)
- Victoriaearle Right, after the earlier reply, I realized i myself had an old mac in storage somewhere, so I spent some 4,5 hours to revive it and I can confirm that I see the same problem. It has nothing to do with Javascript, since it still crashes if I disable Javascript. It very much looks like the Safari rendering engine just dies on something that we feed it (probably a CSS statement of some sort). I see the same problem on the german Wikipedia, but not on the Dutch wikipedia, which is .... most peculiar to say the least. The cause is most definitely a bug in Safari, but which one it is and what the exact trigger is will take a bit more time to figure out. —TheDJ (talk • contribs) 23:04, 30 April 2016 (UTC)
- TheDJ, yes, I have gadgets and I can turn them all off and then work through to test each one, but until I'm able to put back my watchlist I won't be working under normal conditions. Before posting here, while still logged out, I tried to get click the history tab of the TFA on the main page and froze again, so it seems the issue is more to do with the OS/browser rather than whether logged in user or not. My sense is that during the server updates something got changed with the way pages are called and it's now not compatible with Lion/Safari 6.xx Victoria (tk) 21:15, 30 April 2016 (UTC)
- The problem is very simple. We need to find someone with enough technical skill who can 'figure' out why this is occurring. Now those people generally tend not to run Safari 6 on Lion, can't easily downgrade to that, and can't easily install it from scratch. Simple problem, hard solution. It's not a disservice, it's a practicality. In the mean time, I've filed a bugreport (which anyone could have done), but Victoria, could you please check if you have the same problems on other language versions of Wikipedia or sister sites ? Just to make sure that it is not a problem specific to this site ? —TheDJ (talk • contribs) 17:37, 30 April 2016 (UTC)
- Hi Diannaa, thanks for replying. You're right, I need to update to El Capitan, but don't have the time to do it immediately (and it wasn't on my list of things to do during the winter), and I think that's my frustration that this came out of nowhere. The issues are to do with loading any page and it doesn't matter if I'm logged out or not, i.e. if I'm reading an article while logged out and click a wikilink it freezes (and it's a really terrible freeze). Surely I'm not the only person who is lazy about updating. I understand that we can't support all browsers or older browsers; I do get that. But it seems a disservice, is the point I'm trying to make, and I don't have trouble reading or accessing any other websites. When that begins to happen, I know that it's time to update, but I'm surprised that it's Wikipedia that's forcing it, is all. In the meantime, I dumped my entire watchlist, which allowed me to log in and I was able got here using the search function. Victoria (tk) 16:38, 30 April 2016 (UTC)
- Here's what I found out: My guess is you are using Lion or Mountain Lion as your operating system, and this means you are unable to upgrade to a more recent version of Safari. Safari 6.1.6 came out in August 13, 2014. It's not realistic for us to have to maintain compatibility with outdated browsers indefinitely. It looks like you have two options at this point: Switch to Chrome, or upgrade your browser to El Capitan so that you can upgrade to the most recent version of Safari. I use Chrome almost exclusively, as I find it is the best browser for the type of work I do here on Wikipedia (operating system is Mavericks). I suggest you give it a try, as this is a simple fix. — Diannaa (talk) 14:09, 30 April 2016 (UTC)
- Root cause found. I knew this started to sound somewhat familiar. Together with valhallasw, I reported this issue to both Safari and Chrome before (but neither ticket was ever closed it seems). It's apparently fixed in newer versions of Safari and Chrome, but not in old versions of course. We saw something similar happened in august 2015. —TheDJ (talk • contribs) 09:24, 1 May 2016 (UTC)
- I have the same problem. I'm using Safari 6. Everything is working good in my Wikipedia account (Talk, Sandbox, Preferences, Beta, Read Edit, View History) except when I go to my "Contributions" and Watchlist", my wiki page hangs/freezes and unable to proceed.--Richie Campbell (talk) 02:48, 2 May 2016 (UTC)
- I was having this problem yesterday on iOS7. Updating the iPad to 9.31 cleared it up, though this option won't be available to everyone.LeadSongDog come howl! 13:28, 2 May 2016 (UTC)
- Update: TheDJ - I'm now on Mavericks and using Safari 7.0.6. Bad news is that it still freezes - i.e. if I try to load the history of a page it freezes (with the swirling colored circle). Good news is that it's a softer freeze - I can back out of it, I can close Safari, all things I couldn't do with Safari 6. To digress slightly, the update to Mavericks was done after a lot of backing up, researching El Capitan and a trip to the Apple store where I was advised that these machines designed for Lion don't do great when updating all the way to Yosemite or El Capitan, so we compromised. Mavericks will allow me to go all the way to Safari 9 (a big jump), which I'll do in a few days, but I'd like to hack around with this first and see what else I find. I've not yet tried to replace my watchlist. Victoria (tk) 15:33, 2 May 2016 (UTC)
- We have decided to rollout a patch that will bypass the problem, since so many people are affected (also quite a few iOS devices) and because it's a page freeze that is not related to Javascript but to CSS. This change will mean that Safari users will not get the improvement for text with bidirectional content that the developer originally intended to make, instead only chrome and firefox users will get the improvement. —TheDJ (talk • contribs) 17:39, 2 May 2016 (UTC)
- TheDJ thanks for putting in the patch. I'm not sure what's happened, but I had all of two pages on my watchlist, was able to log in this morning, and now can't get past the log in screen without the hard freeze again. I deleted the two pages from my watchlist (using Chrome) and was able to get back in, but I don't think it's quite there yet for Safari users. Victoria (tk) 20:26, 2 May 2016 (UTC)
- We have decided to rollout a patch that will bypass the problem, since so many people are affected (also quite a few iOS devices) and because it's a page freeze that is not related to Javascript but to CSS. This change will mean that Safari users will not get the improvement for text with bidirectional content that the developer originally intended to make, instead only chrome and firefox users will get the improvement. —TheDJ (talk • contribs) 17:39, 2 May 2016 (UTC)
- PS - Even though I have switched to Chrome for this issue, I have noticed over the past several days that my Watchlist seems to be slowing down on Chrome. Not hanging up or getting stuck but slower... Shearonink (talk) 00:36, 6 May 2016 (UTC)
- JFTR I haven’t experienced any of the described problems with Safari v5 on OS X v10.6 “Snow Leopard”. There are quite a few sites that don’t work properly any more (I use Firefox for those) but so far this isn’t one of them. (Although I had to switch my math preference to use PNG, because formulæ were getting rendered much too small to read.)—Odysseus1479 21:53, 8 May 2016 (UTC)
- It's still happening for me. I'm using Mac OS X 10.9.4, Safari 7.0.5. More info: it appears to be related to the amount of data to display. It hangs on my "Contributions", or the "History" of most pages. But it doesn't hang for my Watchlist (which is very short), or (it seems) when the article History is very short. Adpete (talk) 03:52, 9 May 2016 (UTC)
Watchlist & contribs corruption
I imagine this is relevant to a discussion above: Watchlist getting stuck. I've got Mac OS X Lion 10.7.5 [with Safari 6.1.6 (7537.78.2)] and keep getting a "some webpages are not responding" message whenever (and only when) I try to check my WP watchlist and contributions. Any other activity on Wikipedia, e.g. accessing mainspace or pages such as this, or online generally is fine. The same error message was identified on apple.com back in January 2014; for me it's only been an issue in the last two days. Has something changed on Wikipedia in that time? I also use an ancient iPad, btw, but I can access Watchlist, etc. no problem on that. Frustrating – but my question is, why is this suddenly an issue? Cheers, JG66 (talk) 14:13, 30 April 2016 (UTC)
- Because the code of website has a couple hundred changes per week, and because old browser are not as capable as new browsers. Oh and because browsers have hundreds and hundreds of bugs in them. And apparently those conditions came together to create a problem :) —TheDJ (talk • contribs) 18:01, 30 April 2016 (UTC)
- Btw, I have Mac OS X Lion 10.x.x & have been running a higher version of Safari than yours. At this point I've given up using Safari to access my Watchlist - Chrome works but it's annoying to have to switch between the two. Would be nice to know why the Watchlist has been misbehaving - but apparently only for Safari users. Shearonink (talk) 03:28, 1 May 2016 (UTC)
how is RefToolbarLegacy.js getting added to Category:Pages with empty citations?
Category:Pages with empty citations lists MediaWiki:RefToolbarLegacy.js. This has perplexed me for a long time. If I look at the html source for RefToolbarLegacy.js I cannot find any reference to Category:Pages with empty citations. How is this category being added to RefToolbarLegacy.js?
In edit mode, the list of "Pages transcluded onto the current version of this page" includes Template:Citation and Template:Cite book, either of which, when empty, will cause the trancluding page to be added to Category:Pages with empty citations.
Is it this? (at lines 351, 352):
<input type="radio" tabindex=1 name="template" id="cite_book" value="cite_book" checked="1"><label for="cite_book">{{cite book}}</label> <sup><a href="//en.wikipedia.org/wiki/Template:Cite_book" target="_blank">[doc]</a></sup> \
<input type="radio" tabindex=1 name="template" id="citation" value="citation"><label for="citation">{{citation}}</label> <sup><a href="//en.wikipedia.org/wiki/Template:Citation" target="_blank">[doc]</a></sup> \
If so, how? Should javascript be transcluding templates? Why can't I find Category:Pages with empty citations in the RefToolbarLegacy.js html source?
I'm pretty sure that I can make Module:Citation/CS1 ignore this page but, before I do that, I'd like to understand how it is that RefToolbarLegacy.js is getting added to the category.
—Trappist the monk (talk) 14:25, 4 May 2016 (UTC)
- It's caused by
{{cite book}}
. It only adds the tracking category in some namespaces. Maybe you tested it in userspace where it's not added. css and js pages are evaluated as wikitext when link tables are built but the result is not used to render the pages. This can be confusing. PrimeHunter (talk) 16:53, 4 May 2016 (UTC)- I'm afraid I find your answer somewhat confusing. Module:Citation/CS1 excludes certain namespaces from its error categorization. These excluded namespaces are identified at the top of Module:Citation/CS1/Configuration in the table
uncategorized_namespaces
. MediaWiki is not one of those namespaces.{{cite book}}
and{{citation}}
both use Module:Citation/CS1 so either (more likely both, if the code snippet above is the culprit) could be the the cause. I'm not sure what to make of this sentence:Maybe you tested it in userspace where it's not added.
What test? There was no need to test anything to see that MediaWiki:RefToolbarLegacy.js is a member of Category:Pages with empty citations.
- I'm afraid I find your answer somewhat confusing. Module:Citation/CS1 excludes certain namespaces from its error categorization. These excluded namespaces are identified at the top of Module:Citation/CS1/Configuration in the table
-
- What does make sense, mostly, is that
css and js pages are evaluated as wikitext ...
Perhaps this indicates that there is a small bug in the code that does this processing – clearly it knows that the page is css or js. If these pages shouldn't transclude other pages (is there ever a case where they should?) then there should be no reason to keep the results and and similarly, no reason to keep the side effects (in this case the error category) of transclusions. - —Trappist the monk (talk) 18:36, 4 May 2016 (UTC)
- Sorry, I misread "either" as "neither" in your first post and incorrectly thought you had tested the empty templates somewhere and found them to not add the category there. The side effects are used deliberately in some situations like adding user css and js pages to speedy deletion categories on user request, and to track imports of js pages via WhatLinksHere. For example, User:Bart133/monobook.js says:
importScript('User:Dr pda/prosesize.js'); //[[User:Dr pda/prosesize.js]]
- The part after
//
is a JavaScript comment so it has no effect on the js page, but it's not a wikitext comment so it's evaluated during wikitext processing and causes the page to be listed at Special:WhatLinksHere/User:Dr pda/prosesize.js (importScript does not cause a WhatLinksHere). I don't know whether these side effects were made by design in MediaWiki but once something exists, it can quickly become a feature. See https://xkcd.com/1172/. PrimeHunter (talk) 20:23, 4 May 2016 (UTC)- This should sort it. --Redrose64 (talk) 20:27, 4 May 2016 (UTC)
- I don't know it that script still works (I assume that it does), but Category:Pages with empty citations is now empty for the first time. Well done.
- —Trappist the monk (talk) 20:37, 4 May 2016 (UTC)
- This should sort it. --Redrose64 (talk) 20:27, 4 May 2016 (UTC)
- What does make sense, mostly, is that
- See phab:T34858, phab:T35355#1862685, phab:T18683 and phab:T12410. Helder 21:35, 7 May 2016 (UTC)
Scrollbar for map
Hi. Can someone help with creating a vertical scrollbar for the map in List of power stations in Sri Lanka? I need that map reduced 50% in height, so as to reduce whitespacing in a number of screen resolutions. I know of {{Tall image}}, but that cannot be used in this case (right?). Thanks in advance! Rehman 14:48, 4 May 2016 (UTC)
- @Rehman: How's this? -- AxG / ✉ / 10 years of editing 21:15, 5 May 2016 (UTC)
- Hi AxG. Thank you. Would you know if the map can be made to look like this scrollable image? (notice the borders and caption). Rehman 15:53, 6 May 2016 (UTC)
- @Rehman: Some tinkering later... -- AxG / ✉ / 10 years of editing 18:05, 6 May 2016 (UTC)
- Hi AxG. Thank you. Would you know if the map can be made to look like this scrollable image? (notice the borders and caption). Rehman 15:53, 6 May 2016 (UTC)
Toolbar cite journal template not working
Lately, whenever I try to edit a page and add a journal citation by copying and pasting the doi/pmid into the cite journal template in the toolbar (which you access by clicking "cite" and then "templates"), the template is not filling in like it's supposed to when I click the magnifying glass next to the doi or pmid field (depending on which one I copied into the template). Other times, as now, when I edit a page and click on the "templates" window in the toolbar, nothing even happens, so I can't even try to fill out the template as described above at all. Usually, I have to then open another WP page and edit that in order to fill out a cite journal template in the toolbar. Does anyone know how I can fix this problem? Everymorning (talk) 02:53, 5 May 2016 (UTC)
- Could you open your web browser's "developer tools" and reload the page on which you see the problem and perform the steps leading to the problem? If there is a problem or an error with JavaScript it should be printed in the 'console' of the developer tools. For more information please see:
- --AKlapper (WMF) (talk) 09:38, 5 May 2016 (UTC)
- Related discussion /Archive 145#Citation autofill on toolbar not working for journals.
Fred Gandt (talk|contribs)
23:07, 5 May 2016 (UTC)- It looks like the error is "Use of "wgTitle" is deprecated. Use mw.config instead." However, I've gotten two other errors in the console tab besides "wgTitle": "wgArticlePath" and "wgUserName". Hope this helps identify the root of the problem and a solution to it. Everymorning (talk) 01:57, 6 May 2016 (UTC)
- Although directly using those global values is deprecated Everymorning, they're still usable for now, and
won'tshouldn't cause any issues. They should however be updated, as eventually they may not exist. In your console, you will often see warnings which are usually informational and yellow. Red messages are usually more likely to be errors which will affect functionality. However, both these types of console output are set by the writer of the code, and can be used erroneously or even whimsically. You can experiment in your browser's JavaScript console if you like; where you see the warnings, place your caret underneath, and typewgTitle
(or others) and press ↵ Enter. You'll see the value of the variable and should get another warning about using it. If you then typemw.config.get( "wgTitle" );
and press ↵ Enter, you'll get the same value but no warning. I realise this info doesn't help trace the problem with the ref toolbar, but I hope it helps you understand more about JavaScript code and your browser.Fred Gandt (talk|contribs)
06:10, 6 May 2016 (UTC) - @Everymorning: Can you revert this change and try again? Also, if you have the proveIt gadget enabled in your preferences, please remove ProveIt.js and associated code from your vector.js - NQ (talk) 02:30, 6 May 2016 (UTC)
- @NQ: I undid the change you requested and removed ProveIt.js stuff from my vector.js, but I still can't fill out cite journal templates on the toolbar as described above. Do you have any idea why this might be happening? BTW, I am using Google Chrome Version 50.0.2661.94 (64-bit). Everymorning (talk) 00:10, 10 May 2016 (UTC)
- @Everymorning: It might be due to a conflict with another script or gadget you have enabled. Could you create an alternate account and see if you have the same issue? The reftoolbar and all that should come pre-enabled so you don't have to do anything, just check if you're able to use the autofill feature. - NQ (talk) 00:58, 10 May 2016 (UTC)
- @NQ: I undid the change you requested and removed ProveIt.js stuff from my vector.js, but I still can't fill out cite journal templates on the toolbar as described above. Do you have any idea why this might be happening? BTW, I am using Google Chrome Version 50.0.2661.94 (64-bit). Everymorning (talk) 00:10, 10 May 2016 (UTC)
- Although directly using those global values is deprecated Everymorning, they're still usable for now, and
- It looks like the error is "Use of "wgTitle" is deprecated. Use mw.config instead." However, I've gotten two other errors in the console tab besides "wgTitle": "wgArticlePath" and "wgUserName". Hope this helps identify the root of the problem and a solution to it. Everymorning (talk) 01:57, 6 May 2016 (UTC)
I was able to fill out the cite journal template using a doi when I edited logged out of my account, though I still can't do it using this account. Everymorning (talk) 20:17, 10 May 2016 (UTC)
- Update: this problem seems to be fixed (at least in article space; I still can't fill out journal templates on this page for some reason, but since I really only need to do this in article space, that doesn't really matter). Everymorning (talk) 20:21, 10 May 2016 (UTC)
Wrong category title
Discussion moved to Category talk:Maritime incidents by year. --Pipetricker (talk) 07:33, 7 May 2016 (UTC)
frac template
In {{frac}}, e.g. N⁄D, I see a slash if my skin is Cologne Blue, but not in Monobook (my favorite), Vector or Modern. The HTML is
<span class="frac nowrap"><sup>N</sup>⁄<sub>D</sub></span>.
Taking away the <span> has no effect, I still see no slash in N⁄D; but I do see it here: N⁄D, N ⁄ D. Is the problem on my end? (Firefox, MacOS; it's been so through multiple versions of each. My default font is Lucida Grande.) I do see a bar in N/D. —Tamfang (talk) 09:00, 7 May 2016 (UTC)
- Sounds like a glitch at your end; the slash is certainly displaying fine to me in both Firefox and Chrome. As an aside, when it comes to display issues the only skin you need to pay any attention to is Vector, since that's what the readers always see. ‑ Iridescent 09:41, 7 May 2016 (UTC)
since that's what the readers always see
- Really? A registered reader can't change their skin in their prefs? I wasn't aware of that. So, what, you have to make one edit before that preference is enabled? ―Mandruss ☎ 09:45, 7 May 2016 (UTC)- Of course registered readers can set their skin, but we have a multitude of unregisterd readers which cannot set their skin.
-- [[User:Edokter]] {{talk}}
10:37, 7 May 2016 (UTC)
- Of course registered readers can set their skin, but we have a multitude of unregisterd readers which cannot set their skin.
- That was my understanding, but it is not what the commenter stated. ―Mandruss ☎ 10:43, 7 May 2016 (UTC)
- When we talk about 'readers', we usually mean unregistered users.
-- [[User:Edokter]] {{talk}}
11:36, 7 May 2016 (UTC)- If you say so, but doing so is a terrible idea because it increases the likelihood that we will fail to consider registered, non-editing readers in our discussions and decisions. What we say affects how we think; if we speak imprecisely, we will think imprecisely. For evidence of this, simply refer to Iridescent's statement, that we needn't consider any skin except Vector, implying that no one is affected by the other skins except editors. ―Mandruss ☎ 11:52, 7 May 2016 (UTC)
- Mandruss, as I imagine you're perfectly well aware, the proportion of pageviews which come from registered accounts is well below 0.1%. Given that 70% of registered accounts have Vector set as their preference (and most of the 20% set to Monobook will be long-abandoned accounts registered back in early days when it was the default), the number of readers reading Wikipedia using anything other than Vector is so low as to be lost in statistical noise. Treat Cologne Blue (used by 0.7% of registered accounts, which at a rather generous estimate equates to one reader in a million) as you would Lynx users, as a group for which Wikipedia has a traditional obligation to cater, but which provides such an insignificant fraction of the readership that it doesn't justify any special effort to cater for and which is likely to be deprecated in due course. ‑ Iridescent 12:56, 7 May 2016 (UTC)
- If you say so, but doing so is a terrible idea because it increases the likelihood that we will fail to consider registered, non-editing readers in our discussions and decisions. What we say affects how we think; if we speak imprecisely, we will think imprecisely. For evidence of this, simply refer to Iridescent's statement, that we needn't consider any skin except Vector, implying that no one is affected by the other skins except editors. ―Mandruss ☎ 11:52, 7 May 2016 (UTC)
- When we talk about 'readers', we usually mean unregistered users.
- That was my understanding, but it is not what the commenter stated. ―Mandruss ☎ 10:43, 7 May 2016 (UTC)
- I see, thank you for the considered response. So the number, while nonzero, is not sufficiently large to say "unregistered readers" instead of "readers". It is a fairly long word, requiring several seconds to type, prone to misspelling and typos. Perhaps your calculus is correct, and I retract my comments. I'll continue to say "unregistered readers" and I hope that doesn't cause any confusion. ―Mandruss ☎ 14:30, 7 May 2016 (UTC)
- FTR, I see the slash in Windows 10, Firefox 46.0.1 and MS Edge 25.10586.0.0, all skins. That intersects the OP's failures, so I'm stumped unless they wish to try a magnifying glass or a different computer. If this thread archives without anyone else reporting a problem, I'll be left to "glitch on your end"; i.e., SOL. ―Mandruss ☎ 10:43, 7 May 2016 (UTC)
Table convert tool
Is there an easy-to-use tool for converting tables from Microsoft Word into Wiki mark-up? I find construction and amendment of tables to be among the trickiest things at Wikipedia. Many thanks. Martinevans123 (talk) 09:47, 7 May 2016 (UTC)
- Have you tried using the table editor of the VisualEditor ? It's a lot easier to build tables with that. The VE surface also allows you to copy paste tables to some degree. Not sure if that works with Word tables however. —TheDJ (talk • contribs) 10:21, 7 May 2016 (UTC)
- I made a script for someone only recently for copy/paste of Word tables to wikitext, which I could possibly extend to be more general purpose. As long as there's no hurry, I'll add it to my todo list if you like.
Fred Gandt (talk|contribs)
10:58, 7 May 2016 (UTC)
- Thank you both for the helpful replies. There's no hurry, thanks. Martinevans123 (talk) 11:15, 7 May 2016 (UTC)
- A number of tools are listed at WP:Tools#Importing (converting) content to Wikipedia (MediaWiki) format, WP:Tools/Editing tools#Wikisyntax conversion utilities, de:Wikipedia:Technik/Text/Basic/EXCEL-2003 Tabellenumwandlung VBA. -- Michael Bednarek (talk) 01:59, 8 May 2016 (UTC)
- Many thanks, Michael. That seems to cover everything. Martinevans123 (talk) 12:08, 8 May 2016 (UTC)
- The visual editor does well with many tables. .csv files are simply drag and drop. But I believe that there's an open bug with Microsoft Word tables. If you did an interim transformation (e.g., maybe save it as HTML from Word, or export it as a CSV?), then you might have better success there. Whatamidoing (WMF) (talk) 18:44, 10 May 2016 (UTC)
- Many thanks, Michael. That seems to cover everything. Martinevans123 (talk) 12:08, 8 May 2016 (UTC)
- A number of tools are listed at WP:Tools#Importing (converting) content to Wikipedia (MediaWiki) format, WP:Tools/Editing tools#Wikisyntax conversion utilities, de:Wikipedia:Technik/Text/Basic/EXCEL-2003 Tabellenumwandlung VBA. -- Michael Bednarek (talk) 01:59, 8 May 2016 (UTC)
- Thank you both for the helpful replies. There's no hurry, thanks. Martinevans123 (talk) 11:15, 7 May 2016 (UTC)
No link in diff-view to previous revision
See [7]. It's normal for Revision as of [time], [date] to be linked, so that you can see what the page was like when previously edited, but for some reason it's not linked in this specific diff (I've closed and reopened the link several times; it's not just a one-time bad page load) that appeared on my watchlist. I've often noticed this happening when I see a bunch of edits in my watchlist; it's been going on for some months now. It's not something significantly problematic, but I doubt that it's supposed to work this way; the only context in which a link shouldn't be clickable is when the old revision's been oversighted. Nyttend (talk) 14:55, 7 May 2016 (UTC)
- Odd, the link is clickable and works fine for me. Sam Walton (talk) 14:57, 7 May 2016 (UTC)
- Well, I'm to blame for this Nyttend. The hack I gave in Wikipedia:Village pump (technical)/Archive 140#Custom script to obscure a link? is messing it up on certain diff pages. If you remove that piece of code from your monbook.js, everything should be back to normal. - NQ (talk) 15:36, 7 May 2016 (UTC)
- Odd; it affects diffs on occasional pages with {{Infobox NRHP}}, but only a very few. The code you supplied there is still quite useful, and the missing link atop this diff isn't at all useful, so I have no desire to get rid of the code. Thanks! Nyttend (talk) 16:15, 7 May 2016 (UTC)
- Well, I'm to blame for this Nyttend. The hack I gave in Wikipedia:Village pump (technical)/Archive 140#Custom script to obscure a link? is messing it up on certain diff pages. If you remove that piece of code from your monbook.js, everything should be back to normal. - NQ (talk) 15:36, 7 May 2016 (UTC)
Category:Articles to harmonize
For Category:Articles to harmonize, what is to be done? Are there instructions somewhere?--DThomsen8 (talk) 16:04, 7 May 2016 (UTC)
- Template:Sync puts articles in that category, but no help in saying what is to be done.--DThomsen8 (talk) 16:21, 7 May 2016 (UTC)
- See Wikipedia:Templates for discussion/Log/2016 May 7#Template:Sync. Nyttend (talk) 16:33, 7 May 2016 (UTC)
URL processing to work around Chrome, etc., flaw
It turns out that the Chrome browser (and variants like Chromium, Opera, etc.) do not do certain kinds of auto-escaping. Thus, if you use one of these browsers and do something like a Google search on the quoted phrase "Manx cat", the URL it gives you for the search results will be something like https://www.google.com/search?q="Manx%20cat"
(with various extra parameters about language, time zone, browser). This URL will not work properly in Wikipedia:
- As a bare URL: "Manx%20cat"
- That should have looked like: [8]
- In the {{URL}} template: "Manx%20cat" search results
- Which should have looked like: search results
- etc.
The problem is that the double-quote character has to be escaped as %22
, and most editors don't know this, so will not know how to fix it. So, MediaWiki should probably do this for us (and look for other characters it needs to escape in URLs, too). — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 20:37, 7 May 2016 (UTC)
- Can you not just use {{google|"Manx cat"}}? ‑ Iridescent 21:11, 7 May 2016 (UTC)
- In Chrome and Firefox (as tested on OS X), a URL copied in full is always percent-encoded:
- If you do a Google search for "Manx cat", the result page will have a URL looking like this, with quotation marks:
https://www.google.com/search?q="Manx+cat"&rlz=1C5CHFA_enSE530SE534&oq="Manx+cat"&aqs=chrome..69i57&sourceid=chrome&ie=UTF-8
.
- If you copy this URL in full from the address bar, either by menu or keyboard action or by dragging the favicon, you will get the URL with the quotemarks percent-encoded as
%22
. But if you copy only a part of the URL in the address bar, you will get the text copied as it looks in the address bar, with unencoded quotation marks.
- (It occurs to me that I've been using this without thinking about it, copying both the percent-encoded URL, and separately unencoded characters from the URL, as I described here.)
- With Safari, copying a URL from the address bar using keyboard or menu will give you the text as it looks in the address bar, which usually is with any quotation marks percent-encoded (but a newly entered address can have unencoded quotemarks). Dragging the favicon will always give you the percent-encoded URL. --Pipetricker (talk) 08:40, 8 May 2016 (UTC)
- The difference is URI vs. IRI I believe. For the sake of readability at some point the browser vendors introduced the IRI. The problem is that only browsers really support them and even they have had quite a few security problems with them. Implementation of IRI is not a simple feat. unfortunately. And then you still have to keep them apart when a user presses paste, which isn't simple either. —TheDJ (talk • contribs) 09:15, 8 May 2016 (UTC)
Presentation of parent categories
Concerning the discussion here [The Link], I'd like to find out if the technically experienced users consider this idea to be possible, given that it is approved by the majority of all users. CN1 (talk) 23:58, 7 May 2016 (UTC)
- Technically, very possible; it is a HTML list, which allows for flexible styling. I have trouble seeing the 'majority of users' though, so this needs more input.
-- [[User:Edokter]] {{talk}}
07:13, 8 May 2016 (UTC)
- Per WP:MULTI, please discuss on the existing thread. --Redrose64 (talk) 12:24, 8 May 2016 (UTC)
Annoying "Secure connection failed"
As much as this has happened to me over the last few months, I'm sure this must have been mentioned before. It happens perhaps less than half a dozen times a day, but that's enough. The phenomenon happens when I click "Preview", no other time. And it's rather sporadic. The message is at the tab heading "Problem loading" And the error message in the body is "Secure Connection Failed. The connection to the server was reset while the page was loading. The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem." It gives me the option to "Try again", which pretty much loses whatever edit I was doing at the time. Really irritating. Firefox 46.0.1, but it's been doing this when I had older versions of Firefox. Arrrrgh. — Maile (talk) 19:13, 8 May 2016 (UTC)
- Not addressing the problem, but here's a hint to avoid losing your edit due to any reason including edit conflict. Before pressing Show preview or Save page, highlight the text and copy it. If you lose the edit, you can reload the page and paste the text back in. Akld guy (talk) 19:46, 8 May 2016 (UTC). Edited to show buttons. Akld guy (talk) 10:10, 9 May 2016 (UTC)
- Thanks for the tip. — Maile (talk) 21:38, 8 May 2016 (UTC)
- I got that message once, a few days ago, when using Show changes. I didn't use Try again - I clicked the "back" button then Show preview. This one didn't complain, so I clicked the "back" button then Show changes, which worked, so I carried on as normal. Firefox 46.0.1. --Redrose64 (talk) 09:17, 9 May 2016 (UTC)
I've also seen these warning messages recently: their appearance seems to be sporadic. Browser: Firefox on Linux. -- The Anome (talk) 11:14, 9 May 2016 (UTC)
- And it just happened when I was deleting a CSD nomination. At least we know it's not just "Preview" that causes that. — Maile (talk) 23:06, 9 May 2016 (UTC)
- I got it again yesterday, this time on a Save page. As before, I didn't use Try again but clicked the "back" button then Show preview, then "back" and Save page again. My changes were saved; nothing was lost. --Redrose64 (talk) 07:30, 10 May 2016 (UTC)
- Happened several times to me this morning. Seems to be getting more frequent. I never touch Try again because it doesn't really work; it's like a tease. I just do the back button, then Save page. I see below there is a ticket out on this. The thing is this morning, I was doing detail clean-up that was hundreds of little edits on one article. Glad this didn't wipe those out when it happened, because it would have been time-consuming to re-do. — Maile (talk) 15:34, 10 May 2016 (UTC)
- I started getting this very frequently starting either yesterday or the day before - hadn't had it before. The connection I'm using actually isn't 100% reliable (I have to replace a plug) but it seems pretty consistent now. The weird thing is it happens once per edit - if I preview, I get it on the preview, but then not on the post. (but it didn't happen just now, four times in a row...) Wnt (talk) 12:13, 10 May 2016 (UTC)
- Same here, six or seven times the last two days, when previewing. Whether it happens when posting, I can't say (I preview a lot more than I actually post). Using firefox 46.0, Ubuntu. Prevalence 15:11, 10 May 2016 (UTC)
- Been happening periodically to me, mainly when previewing pages - I've reported in T134869 -- samtar talk or stalk 12:23, 10 May 2016 (UTC)
Odd references format
Could anyone explain the format of the sources at Livesey which I've marked as deadlinks? Were they really added in this form? I'm assuming this question would be an easy one for technical geeks like User:Fred Gandt. Thanks. Martinevans123 (talk) 19:47, 8 May 2016 (UTC)
- Looks as though they were added like this - they look like search queries to get to the intended page, rather than navigating to the page. At least some of them are archived at the Wayback machine, but the first one (Ref 4) - had a dead link for the actual photo and didn't seem to support the preceding text - replaced this with a similar link from the same site. Fixed Ref 5 with an archive url. The site says its under reconstruction... Good luck with the other dead links! Robevans123 (talk) 20:46, 8 May 2016 (UTC)
- Ooh, blimey. A real techno-geek. Thanks. Martinevans123 (talk) 21:02, 8 May 2016 (UTC) p.s. great user name
- The site reorganized the content without making the old url's work. Very annoying but websites do it all the time. The references state the title so you could also try searching the site for the titles. It has a search box where "Coal Mining in Cherry Tree" leads to [9]. I haven't tried the others. For another time, note that Template:Dead link#Usage says: "this tag should be placed just before the
</ref>
that contains the dead link". PrimeHunter (talk) 21:29, 8 May 2016 (UTC)
- Yes, thanks very much, Prime, fully noted. Good job they're now alive again. Martinevans123 (talk) 21:58, 8 May 2016 (UTC)
Revising a subst template to be more user-friendly after substing
I would appreciate if a technical whiz would look at Template talk:Rfd2#Template produces hopeless technobabble and see if there are ways for the subst template to produce wikitext that is more user-friendly to non-technical editors. Thanks, Oiyarbepsy (talk) 03:16, 9 May 2016 (UTC)
- @Oiyarbepsy: Can you try out {{Rfd2/sandbox}} and see if it does what you'd like?
Fred Gandt (talk|contribs)
06:02, 9 May 2016 (UTC)
How to automate display of pages at one per day?
Resolved
There are 1299 mottos in the Motto of the day department. Is there a way to set those up so that they would automatically display one per day, over and over again?
Please respond at the following link:
Wikipedia talk:Motto of the day#Proposal: automate Motto of the day
Thank you. The Transhumanist 15:33, 9 May 2016 (UTC)
- Marking as resolved as you've got all the bits now. — Dispenser 17:07, 9 May 2016 (UTC)
Help improve search relevance with Discernatron 🤖
The Discovery department's work to improve search continues with a new tool! We are asking volunteers to help choose, or discern, which search results are the most relevant.
One way of improving search results relevance is to provide search results from multiple search engines side-by-side for comparison. Participants pick the best, most relevant results, which are then used to tune our own search results. It's one way to help improve search with human assistance, by showing articles that are most relevant to search queries. This system is used by many R&D departments and gives great results.
Discernatron is a tool developed by the Discovery department for just this sort of work. Visitors are asked to pick the most relevant results across four different search result sets. The data is then used to help improve our relevancy model for search.
If you are interested in helping, you can access Discernatron at https://discernatron.wmflabs.org/ and authenticate with your unified user account.
To learn more about the tool visit Mediawiki.org.
CKoerner (WMF) (talk) 21:49, 9 May 2016 (UTC)
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Recent changes
- Wikiversities now have better access to Wikidata. They can use data from any page on Wikidata on any page on Wikiversity. This happened on May 3. [10]
- You can use Wikipedia GapFinder to find missing articles between languages. [11]
- Users are invited to try Cross-wiki Notifications on all wikis. This is the last test session before the release by default, scheduled for May 12th at 23:00 UTC. [12][13]
- You can use keyboard shortcuts to open the visual editor (meta+V) or the wikitext editor (meta+E) (on certain wikis, even if you have chosen a favorite editor). [14]
- Uploading files bigger than 100 megabytes on Wikimedia Commons required to opt-in in your preferences. This is not necessary anymore. [15]
- The UploadsLink extension is now available on Wikimedia Commons. [16]
- Deleting a translation unit page didn't remove the corresponding content from the translation page. This is now solved. [17]
- Translation suggestions based on Apertium are now available on Mediawiki.org. [18]
Problems
- MediaWiki 1.27.0-wmf.23 has been rolled back from Wikimedia wikis, due to a performance issue. [19]
Changes this week
- The new version of MediaWiki will be on test wikis and MediaWiki.org from May 10. It will be on non-Wikipedia wikis and some Wikipedias from May 11. It will be on all wikis from May 12 (calendar).
Meetings
- You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs you think are the most important. The meeting will be on May 10 at 19:00 (UTC). See how to join.
- You can join the next meeting with the Architecture committee. The topics this week are Overhaul Interwiki map, unify with Sites and WikiMap. The meeting will be on May 11 at 21:00 (UTC). See how to join.
- 2017 European hackathon will happen on May 19 - 21, in Vienna (Austria).
Future changes
- Today, in categories, a page titled "11" comes before "2". We plan to reorder that: "2" will come before "11". Please tell the developers if the change will cause problems. [20]
Tech news prepared by tech ambassadors and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.
23:22, 9 May 2016 (UTC)
11 to come before 2
Definitely a welcome change to ordering. But how exactly will the software determine if there is really a need to do so? Counting the number of successive digits? If 11 will come after 2, will 1001 come after 999? Will 1 001 come after 999? Will 1,001 come after 999? Might be a problem because of how we space out digits. 49.148.66.44 (talk) 09:35, 10 May 2016 (UTC)
- Please add your comment on meta:Talk:Community Tech/Numerical sorting in categories so it will be seen and can be discussed in one single place. Thanks. --AKlapper (WMF) (talk) 10:58, 10 May 2016 (UTC)
ClueBot III
The bot is the talk of the town for a while now, after sleeping for a few weeks then resuming editing for a week, then sleeping again. Pages are not getting archived regularly unless they moved to lowercase sigmabot archiving. Sadly, Cobi is not actively editing Wikipedia (is he active on IRC?) I'm looking forward to progress in the situation. Is there any as of now? 49.148.66.44 (talk) 09:38, 10 May 2016 (UTC)
Email unsubscribed every time I use "Email this user"
Whenever I use the "Email this user" feature, I promptly get a notification that my registered email address "has been unsubscribed due to multiple message delivery failures. You can verify your email address again." So I do, and next time it happens again, four times now. The email address is on Yahoo: other messages get through to it OK. Any ideas what the problem might be? JohnCD (talk) 09:48, 10 May 2016 (UTC)
- Wikipedia mail works poorly or not at all with Yahoo (see phab:T58414 and phab:T66795). See Comparison of webmail providers for some free alternatives. PrimeHunter (talk) 10:10, 10 May 2016 (UTC)
- Also T123068 and mw:Notifications/Messages unsubscribe-bouncehandler are related.
Fred Gandt (talk|contribs)
10:12, 10 May 2016 (UTC)
More problems: I set up an AOL account and sent a test message using "Email this user" to my alternate WP account. It arrived, but was put in the spam folder with "Why is this message in Spam? It has a from address in aol.com but has failed aol.com's required tests for authentication." Also (which may be connected) although I checked the "Email me a copy of my message" box, no copy arrived.
Any suggestions for email providers that are known to work trouble-free with Wikipedia mail? JohnCD (talk) 11:53, 10 May 2016 (UTC)
- I have never had an issue with Gmail. --Izno (talk) 11:56, 10 May 2016 (UTC)
- Gmail for me too - generally excellent.
Fred Gandt (talk|contribs)
12:43, 10 May 2016 (UTC)
- Gmail it is, and that works. Thank you all. JohnCD (talk) 13:44, 10 May 2016 (UTC)
- The problem with spam filters is that if you send an email with a sender in one domain, but the mail reaches your domain from a different one, then there is a risk that it's spam sent by a third party, using a name (s)he thinks you will trust. Domains may not know that Wikipedia email has safeguards preventing such problems. עוד מישהו Od Mishehu 17:27, 10 May 2016 (UTC)
Page views of non-mainspace pages
I am curious to find the pages with the most views in namespaces other than main. Are there any tools that do this (and if there are do they count transclusions as views)? I've had a look at WP:Statistics#Page views and nothing that would work jumped out at me. Cheers — crh 23 (Talk) 15:21, 10 May 2016 (UTC)
- TopViews jumped to from PageViews would seem to include pages which are not in mainspace. --Izno (talk) 16:19, 10 May 2016 (UTC)
- @MusikAnimal: Is there an easy way to add filters for namespaces? --Izno (talk) 16:20, 10 May 2016 (UTC)
- Unfortunately, no. The Wikimedia API that's used doesn't offer this functionality, so we'd have to cross-reference the pages with the main API to get the namespaces, and filter accordingly. Especially for the non-mainspace, this could be hugely expensive, and may not even give you what you want, as the API only gives us the top 1000 pages. So for instance, if you wanted the top viewed pages in the portal talk namespace, there will be few if any pages that happened to make the top 1000 overall. I do hope to add a mainspace filter since that's what people are most interested in, and it's feasible to do given the bulk of the top viewed pages are in the mainspace. Best — MusikAnimal talk 16:52, 10 May 2016 (UTC)
- Thanks all, I appreciate the help. I assume TopViews uses the most view articles bit of Analytics/PageviewAPI. If I were desperate to get the data I assume I could use Analytics/Data/Pagecounts-all-sites or probably the merged stuff at [21] (which I can't find any documentation for on Wikitech): does anyone know of any programs that have been made to process that data? — crh 23 (Talk) 19:15, 10 May 2016 (UTC)
- If you just want to download the data, I can make a "download as CSV" feature for Topviews, as we have for Pageviews. However mind you Topviews data is approximate due to API limitations. The dumps at [22] might be more accurate — MusikAnimal talk 14:55, 11 May 2016 (UTC)
Printable/book versions
Two issues:
1. The "printable version" of an article will only give the title of a URL (the same thing that a reader sees on the actual page), but not the URL itself. Could this be changed so that the URL is given in parentheses after the title? An example from today's FA:
- What the printable version will currently display:
- Hubbard, Amy (2012-10-15). "Celebrating Little Nemo by Winsor McCay; his 'demons' made him do it". Los Angeles Times. Archived from the original on 2013-02-13. Retrieved 2012-12-15.
- My suggested change would display this:
- Hubbard, Amy (2012-10-15). "Celebrating Little Nemo by Winsor McCay; his 'demons' made him do it" (http://web.archive.org/web/20130213141842/http://articles.latimes.com/2012/oct/15/nation/la-na-nn-little-nemo-google-doodle-20121015). Los Angeles Times. Archived from the original (http://articles.latimes.com/2012/oct/15/nation/la-na-nn-little-nemo-google-doodle-20121015) on 2013-02-13. Retrieved 2012-12-15.
2. The "download as PDF"/book creator functions are apparently very obsolete/nonfunctional. For example, it appears to completely ignore any content embedded in tables or templates. Should these links simply be removed from the toolbar?
- 1 This is hidden by our local print stylesheet. I don't think it used to be like that. did we change something about references ?
- 2 Well yes, they have many bugs. Removing the links is the most sure way to guarantee that no one will ever fix them however. —TheDJ (talk • contribs) 17:44, 10 May 2016 (UTC)
- The mw:Offline_content_generator certainly supports templates. It does suppress most tables and infoboxes by default, as they've proven very resistant to proper layout; over-wide tables often break the rest of the page. It is supported and maintained, but only by one person (me). Greater support and patches are very welcome! The task for table support is phab:T73808, for instance. One thing I would like to implement is the ability to add hints for the PDF generation, so that we can fine-tune the output on featured articles (for instance). For instance, math-related articles show up better in single-column mode. Some tables or infoboxes might be "whitelisted" using this mechanism. C. Scott Ananian (talk) 17:53, 10 May 2016 (UTC)
- It's nothing to do with templates (if it were, then such things as this link - Postdlf - wouldn't print). This issue has come up here before, several times, and is related to such threads as Wikipedia:Village pump (technical)/Archive 144#Mobile version not displaying some content - some box-type structures belong to certain classes (like
infobox
or metadata
), and those classes are given the CSS declaration display:none;
for some media types, including mobile and print. There are two routes to fixing it: either remove that declaration from the rules that match those classes, or remove those classes from the boxes in question. --Redrose64 (talk) 19:32, 10 May 2016 (UTC)
- I see, so it's more of a CSS issue? I think most templates these days use CSS. postdlf (talk) 21:51, 10 May 2016 (UTC)
- Most of the Internet uses CSS, it's not confined to Wikipedia templates. The problem is that the style sheets include some rules whose selectors match certain structures on the web page and whose declaration blocks set the
display:
property to the value none
. That does not have to be done by means of a template; try printing this page, do you see in it? I thought not. But that's not a template, it's pure inline HTML. But you should see these three words, which are inside a template, one which uses no CSS whatsoever. --Redrose64 (talk) 22:52, 10 May 2016 (UTC)
@C. Scott Ananian: omitting the infoboxes from various highway articles is quite problematic. That's where the map of the highway is shown, for example! Also, by dropping tables, the entire junction list on something like U.S. Route 16 in Michigan is lost, and that's considered one of the "Big Three" sections for any highway article along with the Route description and the History. In short, we lose a lot of content on a whole class of articles. It's even worse on an article like Pure Michigan Byway: the main list, the infobox with map and the gallery of photos are gone. (The captions for the gallery are still there, oddly enough.) Hopefully these elements can be restored. Imzadi 1979 → 09:03, 11 May 2016 (UTC)
Statistics for page counts and breakdown of the source of the page counts
Page count statistics are stored and available for all Wikipedia articles for the cumulative number of page hits per day on one of the tabs readily accessible on the edit history page. Does anyone know if these page count statistics are broken down anywhere as to the source of where the page request is coming from? What part of the the cumulative page count at Wikipedia comes from searching and linking from the Yahoo engine, as opposed to the Google engine, as opposed to the Wikipedia search box engine, how many are from desktop, how many are from mobile, etc? Which percentage of page counts for individual Wikipedia articles come from which sources whether from inside Wikipedia or from outside Wikipedia? Can these statistics be readily retrieved? Fountains-of-Paris (talk) 19:07, 10 May 2016 (UTC)
- @Fountains-of-Paris: PageViews has a "Platform" and an "Agent" box. The former for all/PC/mobile/app and the latter for all/user/spider/bot. The other information you're looking for is not provided by the API of interest, but I believe you can report the desire for that information at Phabricator; the generic bug for PageViews things is phab:T120497--you can submit another task if you think this is desirable by a wide set of persons. @MusikAnimal: FYI. --Izno (talk) 11:49, 11 May 2016 (UTC)
- And phab:project/view/1772/ is the relevant project on Phabricator. --Izno (talk) 11:55, 11 May 2016 (UTC)
- @Izno: That sounds like the correct tool, though I cannot locate the tabs for Platform or for Agent which you are referring to. Are they above the graph or below the graph which is posted to illustrate the page counts? Do I need to navigate through other tabs first to find them? Knowing the difference between the sources of how readers are getting to Wikipedia articles is a very important design paramater. How do I get to Platform or to Agent? Fountains-of-Paris (talk) 14:25, 11 May 2016 (UTC)
- They should be dropdowns located above the graph, placed to the right of the Dates and Project forms. What browser are you using? The Github repo docs have this line: "IE10 and Safari 8 and below are not supported." Are you using one of the unsupported variants? --Izno (talk) 14:28, 11 May 2016 (UTC)
- It wouldn't work at all in IE10 and Safari 8 and below, so I'm guessing you're just missing that dropdown: it's at the top-right next to the date range and platform input. Anyway, what you are after is the HTTP referer, and the API does not offer this information. The old squid reports, has some referer information, but that hasn't been updated since August 2015. If you want to file a feature request on phab, I guess add the "RESTBase-API" tag at that seems to be the place where this information would be made available [23] — MusikAnimal talk 14:50, 11 May 2016 (UTC)
- @Izno: Just found a connection that gives me those tabs now. It looks like the mobile referrers are at about one percent of the total daily page counts for the handful of pages I sampled, which is very small. The related question which is also of interest is to track the number of times a page is requested from another Wikipedia page either (a) by blue-keyword-link clicking in other articles, or, (b) by Wikipedia search box engine searches while on another page, or, (c) by selected drop-box fill-in options automatically suggested in the Wikipedia search box engine. Somewhere I read that the inter-article referrals are counted at Wikipedia and available. Does anyone know where they are kept? And what about the Wikipedia search box referrals broken down by (i) direct referrals exactly as typed into the standard Wikipedia search box or broken down by (ii) selected drop-box auto fill-in suggestions automatically offered while the standard Wikipedia search box engine is being used by an editor. Do the breakdown statistics for the details of the practical day-to-day use of the Wikipedia search box engine exist in an accessible format? Fountains-of-Paris (talk) 16:30, 11 May 2016 (UTC)
Where is this??
Where is the current site notice for "Translate Ibero-America" located? Can't find it using "Message names" nor with "what links here" at the linked project page. Is it not actually on en.wiki? If that's the case I think I have a concern with this, but first things first: there are two glaring, embarrassing typos. --Floquenbeam (talk) 02:13, 11 May 2016 (UTC)
- This was added at Meta. Nakon 02:16, 11 May 2016 (UTC)
- meta:Meta:Requests for help from a sysop or bureaucrat#Iberocoop Translating Ibero America - NQ (talk) 02:18, 11 May 2016 (UTC)
A polite version of "Fooled you again suckers, haha" from WMF to enwiki.
Some of you may remember Wikipedia:Village pump (technical)/Archive 145#VE was imposed as primary editor and the subsequent Wikipedia:Village pump (technical)/Archive 146#Earth to JDForrester. Basically, before the new release of the choice of editing environment (wikitext or VE) in April, User:Alsee asked User:Jdforrester (WMF) explicitly that wikitext would be the default for new editors at enwiki, and was promised quite clearly that this would be the case.
Surprise, surprise, after the release it turns out that this is not true and VE is the primary editor. This issue is raised here, at Phabricator, and at Jdforrester's talk page, but no reaction follows. Despite this being the only post to his talk page in that period, he claimed that his very late response was because he hadn't seen the message and had too many notifications.[24] That's why we have the "you have new messages" orange notice here, of course, but perhaps that's too difficult.
Now, the Phabricator task has suddenly been declined by Jdforrester with the following text
Yup, sorry about this.
I didn't configure the wiki exactly as I had intended, which indeed had the effect that new users who've never edited before will get the visual editor on first edit (unless their machine is incompatible). The plan was to make that part of change subsequently to the main change, which was to provide only one edit tab (with the editor chosen by the user) instead of having two.
Now that both these changes are deployed, I think going back and then forward would cause confusion and disruption with no benefits for our editors. The benefit for users following the plan would have been a lack of unexpected changes. However, this is not something I can create from the spilt milk we now have, sadly.
Consequently, I won't be undoing this change, as I don't think there is overall value in so doing. In future I'll take more care in writing these kinds of changes, sorry.
(end of quote) This, of course, is not only going back on earlier promises without any further discussion, but also seems to be a, what is the acceptable way of saying this, right, an "incorrect statement". Please, Jdforrester, explain how it would be confusing to present new editors on enwiki from now on with wikitext as the primary editor instead of VE, as planned and promised? The editors who have registered meanwhile (between early April and now) don't need to be set back, that damage is done, but the discussion is only about first edits by new editors. How will it be confusing if from now on, they get wikitext as the primary editor? And why then wasn't this a problem when you made your promise earlier? Please provide us with a much better explanation of why you closed this as "decline", as the current one is utterly unconvincing.
Please reopen the phab ticket and do what has been asked of you and promised by you, instead of inventing excuses why it just happens that the WMF-wanted situation is the one we end up with, again, for the umpteenth time, with the minority editor imposed as the default.
User:Elitre (WMF), since you are a community liaison who actually functions in that job, could you please liaise in this situation and convince Jdforrester that simply sending us a polite "sorry, I never planned to do this but told you otherwise, now fuck off" is not really acceptable? It sens the same old unacceptable message of the disconnect between WMF and enwiki, and the disregard some of the people there have for concerns expressed here. Fram (talk) 09:45, 11 May 2016 (UTC)
- @Fram: Hey there. As always, I'm totally happy to be convinced to change my mind. I'm not sure escalating from people working in partnership to a 'confrontation against WMF' is the right move here. :-(
- The series of changes (secondary access to the visual editor for users; secondary access for IPs; SET; prompted choice of editor for users; prompted choice of editor for IPs) has been underway for almost a year now. I really didn't mean to do steps three and four together, and I'm sorry that it happened like this. That said, I don't think undoing step four and then almost immediately re-doing that it in a week's time is valuable for anyone. Am I missing something?
- (Also, it's worth noting that the impact of this change has been to slightly reduce the number of users using the visual editor, because people stick to the last editor they used. I'm not pushing it so much as pulling it back to users who regularly use it. I think continuing to give new accounts a choice of editor – as voted for by community RfC in August – is important to preserve.)
- Jdforrester (WMF) (talk) 19:40, 11 May 2016 (UTC)
- @Jdforrester (WMF): Don't wave your RfC about. Neither the September RfC nor the July RfC (I couldn't find an August one, could be wrong) supports making enwiki VE-primary; both operated on the assumption of having two edit tabs. The "choice of editor" is also more or less meaningless now that single edit tab has been implemented: whereas before there were two clear options, now there is a pop up with a "switch to source editor" which is visually de-emphasise. Therefore you can't claim that making VE primary is insignificant, since, there being only one edit tab, VE is now thanks to human nature and some de-emphasising design the effective default for new accounts.
- Did you plan to ask before the next stage, had you not made this mistake? If you want to be "working in partnership" like you wrote, you should have done so. BethNaught (talk) 22:10, 11 May 2016 (UTC)
- "As always, I'm totally happy to be convinced to change my mind. I'm not sure escalating from people working in partnership to a 'confrontation against WMF' is the right move here. :-(" Then why did you change your mind without any indication of what convinced you or any attempt to discuss this with e.g. Alsee or the enwiki community before closing this, and why did you stop "working in partnership" and instead choose to go for the confrontation against enwiki yet again? You are good with hiding your intentions after smooth words (hence the "polite" in my header here), but you are much better with showing your true intentions with your actions. Can you explain why it is so hard for your team of developers to change the default editor for newly registered editors from Ve to Wikitext? It was possible to deliver this, you never claimed it wasn't, but apparently now you can't do this any longer without rolling back a previous rollouot. Which looks from here like you (the team you are product manager of) are totally incompetent, or you (personally) are lying. The two, sadly, aren't mutually exclusive. User:Jdforrester (WMF), feel free to provide a better explanation, just make sure it is convincing this time. Fram (talk) 07:03, 12 May 2016 (UTC)
- .. while this of course, easily, could be on-wiki configurable settings .. but that would be result in '.. a website which allows collaborative modification ..', which we of course are not. --Dirk Beetstra T C 11:18, 11 May 2016 (UTC)
However, this is not something I can create from the spilt milk we now have, sadly.
- It is scarcely believable that Forrester could be so openly dismissive of anyone disagreeing with his action. Which, by the way, is a textbook example of a fait accompli, made not by volume of actions, but by a single action from power. — Scott • talk 17:04, 11 May 2016 (UTC)
- So. Hypothetically speaking, what would y'all think of a script that would automatically disable the VisualEditor for new users on our end? Say a coder that we'll call "M. Hypothesis" had developed a script to detect new users (perhaps via checking
mw.user.options.get("visualeditor-hidebetawelcome") == 0
). One might imagine this script would then change the user's preference to default to "always use source editor", and one might further imagine that this script would then set the aforementioned hidebetawelcome to 1, to avoid overwriting any further settings. Maybe, to be even more safe, M. Hypothesis might also add a check that could look something like mw.config.get("wgUserEditCount") == 0
, because I'm imagining that M. Hypothesis is a nice person who doesn't want to change a preference that someone is already using. Now, this is all wild speculation, of course, but if M. Hypothesis added this script to Mediawiki:Common.js (or maybe just vector.js; M. Hypothesis might imagine that someone who can change their skin can intelligently choose for themselves what editor to use), such a script would have the effect of making new users default to the source editor, which is what seems to be wanted here. I wonder what would happen in such a hypothetical scenario? Writ Keeper ⚇♔ 18:35, 11 May 2016 (UTC)
- Hypothetically, this basically happened with the ImageViewer and is what caused the whole superprotect debacle. Sounds like a Great Plan™. --Izno (talk) 18:48, 11 May 2016 (UTC)
- Technically, dewiki did that. But the difference here is that this (nominally) isn't a change that the WMF is forcing on us; this is a bug that the WMF has refused to fix (again, nominally). I'd think that a user like M. Hypothesis simply can't abide bugs, and so they want to simply fix it. How could the WMF complain about some hyothetical coder who just wants to fix bugs? Writ Keeper ⚇♔ 19:07, 11 May 2016 (UTC)
- They say that they are sorry for superprotect, but we haven't put up any resistance to their ongoing "we know what's best for you better than you do" attitude lately. I strongly suspect that they will do to M. Hypothesis what they did before -- use superprotect or something like it to get their way. --Guy Macon (talk) 19:14, 11 May 2016 (UTC)
- i do not like the actions taken by Forrester more than the next person likes them (that is, not at all), and i had one or two more encounters with this person which left me very disappointed with his attitude.
- that said, i think the idea of simply "disabling" VE for new editors is atrocious, and in effect, is just as arrogant and bad (or worse) as Forrester's behavior. you are absolutely entitled not to like VE and not want to ever see it in action, but this can't justify depriving other users of the choice. if i misunderstood User:Writ Keeper's question "what would y'all think of a script that would automatically disable the VisualEditor for new users on our end", and by "disable" he actually meant "making sure it's not the default", then i think he should clarify. if by "disable" he meant disable, then this is awful idea, as bad or worse than Mr. Forrster's arrogant and dismissive behavior. קיפודנחש (aka kipod) (talk) 19:44, 11 May 2016 (UTC)
- Yes, "making sure it's not the default" would be the behavior. Any user would be free to switch to VisualEditor if they like; this wouldn't interfere with their choice. Writ Keeper ⚇♔ 19:46, 11 May 2016 (UTC)
- What are the reasons for doing this, aside from "they turned it on without asking"? Reverting for the sake of it is stupid and unproductive. Could you please point me to where this change is causing disruption to the encyclopedia that would actually warrant such an action? It sounds to me like you're wanting to pick a fight over a power grab, plain and simple. Keegan (talk) 19:54, 11 May 2016 (UTC)
- Not only did they turn it on without asking, they did so after recently promosing they would not do so, and after promising to fix it when they did. Translated out of mollification language, you last sentence means "just let the WMF break its promises, and meekly comply as they steamroller over you." 3 years after the original fight, the WMF still hasn't learned. In my opinon, yes, the WMF needs to be taught that it can't lie and mislead and mamipulate. Of course, as a staffer, you would be comfortable with that when you like VE. BethNaught (talk) 20:04, 11 May 2016 (UTC)
- BethNaught, I've been a Wikipedian and an admin of this site for a decade now, and I'm writing as such. I have the right to comment here, and I will not refrain from doing so. There is no need to bring a staff label onto me to discredit me. Please explain to me how an eye-for-an-eye is appropriate? While you're at it, please explain how your personal jab at me is appropriate as well? Keegan (talk) 20:08, 11 May 2016 (UTC)
- The fact is that you just completely ignored BethNaught saying "Not only did they turn it on without asking, they did so after recently promising they would not do so, and after promising to fix it when they did" tells me that "as a staffer, you would be comfortable with that" is likely to be an accurate prediction of future behavior. What you should have done, assuming that you are not comfortable discussing the behavior of a fellow WMF staffer (I know I wouldn't be) is to simply state that you will bring this to the attention of the appropriate level of WMF management so that they can get ahead of this before it becomes one more WMF debacle which gets posted to Slashdot, Wikipediocracy, Reddit, etc. You should do this even if you personally think there is nothing to it. Clearly multiple Wikipedia editors are pissed off. After the broken promises associated with Pending Changes (I have a document with full details I can post if anyone is too new to know about that one) the WMF needs to work to regain our trust. --Guy Macon (talk) 07:36, 12 May 2016 (UTC)
- What's it like, telling people what to do on the internet? I'm writing here as a volunteer, I "should"n't do anything that you suggest, nor did I ask for your instruction. Take your unpleasantness to someone else, because your words are hollow when they are full of spite. Keegan (talk) 16:43, 12 May 2016 (UTC)
- (edit conflict)Well, on some level, yes, I *do* want to pick a fight over a power grab; the thing about power grabs is that they keep happening if you don't challenge them. also for the lulz. But this isn't a thing I'm just going to go do on my own; even apart from WMF reprisals (and how is that even a thing), pushing unvetted, unfinished code into production is a bad idea.
Which, y'know, is the more important reason why we should do this. The VisualEditor is still in beta; it is not complete code. We should not be pushing new users toward it, and certainly not without a disclaimer that it's still in beta. Yet right now, that's exactly what we're doing. That's what I'd like to fix.
- Because keep in mind that this has been presented to us as a bug. While the whole "M. Hypothesis" was obviously me being facetious about the fact that WMF reprisals are in fact a thing, I wasn't totally kidding--from what we've been told by the WMF, and also according to what we wanted, this is a bug, not a feature, and I want to fix the bug, since the WMF won't. The only way that this is "sticking it to the Man" is if the WMF really was lying the whole time, and never intended to make the normal source editor the default. So, if we AGF and all that that the WMF *wasn't* lying, then this shouldn't be controversial to them at all; we're just fixing a bug and making the software behave in the way that both the WMF and we wanted. If. Writ Keeper ⚇♔ 20:18, 11 May 2016 (UTC)
- "We" wanted it that way? From what I can tell, it was done that way so that the people who are upset right now wouldn't be upset, not some kind of community consensus. So when y'all talk about "we", stop pretending to speak for the community. Show me evidence that this is harmful and needs reverted, not that you want to make a power grab to prove a point. That behavior is unbecoming of an administrator. If you can show that this move has harmed the encyclopedia and thus you are fulfilling your duty as an admin, then I might support you. Y'all are playing petty politics, admins are to be more civilized than that. Keegan (talk) 20:27, 11 May 2016 (UTC)
- I never claimed to be speaking for the community. In fact, when I was typing all this out, I had originally used the word "community", and I deleted and replaced it with the pronoun "we" specifically so that I wasn't speaking for the community. This is a bug that I'm trying to fix. It's only a power grab if the WMF wants it to be, if the WMF had duplicitously grabbed first. We don't need widespread community consensus to fix bugs, nor do we need to do A/B testing to see if the bug is harmful. It is harmful by definition: code that is not production-worthy has been pushed closer to production than it should have been or was intended to be. We can fix that; assuming the fix works, why wouldn't we? This shouldn't be controversial; "petty politics" is the only reason it is. Writ Keeper ⚇♔ 20:36, 11 May 2016 (UTC)
- It's not harmful by definition, but by your definition. Visual editor is stuck labeled "beta" because of pushback here three years ago. It's about as beta as MediaWiki is, so we can just shut this whole thing down and go homejoking!. In all seriousness, you're saying bug=harmful. That is not true. Our own software bug starts with "A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways." It does not say harmful. I am asking you to show the harm that you intend to fix. It shouldn't be hard for you to do if it's as bad as you say. Keegan (talk) 20:47, 11 May 2016 (UTC)
- en.wiki is a source-editor-default wiki. The settings for new users are not honoring that. Whether you consider that harmful or not is irrelevant; it is incorrect behavior, and fixing incorrect behavior does not require widespread consensus (at least, not when it doesn't hurt anything else, and this doesn't). If you want "harm", then imagine a user who's been editing as an IP for a while. As an IP, they've been using the source editor, which is correctly the default for IP users. One day, they finally decide to make the jump and register. When they do so, instead of the source editor they're used to, they get this weird VisualEditor thing, but it so happens that they are doing so while trying to edit something that VisualEditor doesn't handle well. It flubs their edit, messes up the table, they don't know how to fix it, get frustrated, and give up. That is harm. Pointing new users to beta software without indicating that it's beta is harmful. If, by the way, you're really insisting that VisualEditor isn't in beta, then I guess it's my turn to ask for evidence to back up your statement; it's clearly indicated as beta in both the preferences and the internal variables. Hell, the dialog box we're talking about is even labeled "betawelcome" internally--not that it mentions that in the box itself. But even if not, the mere fact that it's providing an unnecessary and undesired behavior--particularly when that behavior is at odds with other site behavior, e.g. IP editing--is enough to fix it. Again, the only thing this change costs is the time we spend discussing the petty politics; there's no other reason *not* to do this. Writ Keeper ⚇♔ 21:04, 11 May 2016 (UTC)
- I don't want your imagination. I want evidence of harm. I don't want labels as proof, because all anyone here is trying to do is use labels to defend things. That's not responsible administration of this website. Look, you asked, essentially, if anyone would have a problem with you reverting the change. You've got two yes's already. Nip this idea in the bud before this gets ugly, the choice is yours to make here. If you want to go down this road under the argument of "I'm right, they're wrong," then you are making a poor decision, in my opinion, and other community members will be upset with you, as I am now. Keegan (talk) 21:13, 11 May 2016 (UTC)
Right, you're asking for something that you know I physically can't give you, because the only actual evidence that would be worthwhile would be an A/B test of new users, which is laughably beyond any one user's capability--I'm not even sure the WMF itself is currently equipped to do that. I know they're gearing up to test it, but I don't think they've actually done it yet. But absence of evidence is not evidence of absence, and given that we *know* that this is currently not working to specifications, and that we *know* we can fix it without any other negative impacts, why would we not fix it? How does it make sense to demand that this behavior, which everyone has admitted is wrong behavior, must do some other unspecified "harm" beyond its wrongness to implement a painless, essnetially free fix for it?
Remember that both this bug and this fix only affect new users--nobody that's currently part of the community would even be affected by either. So what exactly are you looking for? Because if I'm being quite honest here, it looks like you're just moving the goalposts. also, the only "no" I'm counting is yours, unless I guess you're counting Izno. That's not how consensus works; we don't stop RfAs as soon as they get their first "oppose" Writ Keeper ⚇♔ 21:25, 11 May 2016 (UTC)
- You have my "no". We also have data suggesting engagement is higher with VisualEditor, through this somewhat difficult to read tool at [25]. Not saying we shouldn't move forward with an RfC, but let's definitely not write this script without consensus first. The problem is of course the people whom this RfC will concern are very unlikely to participate in it — MusikAnimal talk 21:34, 11 May 2016 (UTC)
- Well, like I say, I definitely wasn't planning on going rogue and deploying it sitewide myself--I've had other people do that with my scripts before (the OBoD thing), and I'm definitely not a fan. Besides, what's the point of asking for people's opinions if I'm not going to care about their answers? If people want an RfC, that's fine; I don't think it should really be necessary, but whatevs at this point. Writ Keeper ⚇♔ 21:58, 11 May 2016 (UTC)
- I'll also add my no. —TheDJ (talk • contribs) 22:31, 11 May 2016 (UTC)
Suggestion
- Get someone who knows how to write such a script, if Writ Keeper hasn't already.
- Propose an RfC about whether the script should be implemented.
- Deploy the script if the RfC is successful.
This procedure would have several benefits:
- Opportunity for code review
- Find out whether VE has support in the community
- Make any WMF reprisals illegitimate
BethNaught (talk) 21:27, 11 May 2016 (UTC)
- My draft of the script is at User:Writ_Keeper/Scripts/hypothesis.js. Works as near as I can tell (I've been adding it to teh common.js of test accounts before I create them). Writ Keeper ⚇♔ 21:30, 11 May 2016 (UTC)
- I would much rather see this fixed server-side than client-side. It's not best coding practice to fix obvious bugs in such a roundabout manner. Perhaps just push for a phabricator request to be allowed, and then a community coder can get this simple change reviewed & deployed during SWAT. Mamyles (talk) 21:40, 11 May 2016 (UTC)
- Agree in principle, but after Forrester's remarks, what hope of that is there? If anything, we may hope this RfC itself would make the WMF relent. BethNaught (talk) 21:42, 11 May 2016 (UTC)
- Yes, fixing it serverside is always the ideal. In lieu of that, though, I don't think this is so bad. Writ Keeper ⚇♔ 22:00, 11 May 2016 (UTC)
- I'd like to reiterate that, aside from it being not what we were promised, the main issue for me is that this bug creates an inconsistency in the user experience between IP editors and newly-registered users: IP editors get the wikitext editor, but newly-registered users get the VisualEditor by default. I think that's a signficant issue (not site-breaking of course, but not trivial either), and one I'd hoped my script could fix. Writ Keeper ⚇♔ 22:17, 11 May 2016 (UTC)
- It is not site breaking, but it is an inconsistency that will make new editors who first edited as an IP wonder what happened to 'their' editor (I wouldn't be surprised if some stepped back go back to IP editing). I therefore support activating this script now (as per discussions, and repeated broken promises of WMF), and do what the WMF should have done in the first place: start an RfC to gauge what the community thinks should be the standard situation. --Dirk Beetstra T C 03:45, 12 May 2016 (UTC)
- I support activating such a script as well. Fram (talk) 07:04, 12 May 2016 (UTC)
- Do we really need another RfC? I could have sworn I participated in at least one last year where there was a clear consensus against making VE the default for new/inexperienced editors. And I don't recall any new discussion in the meantime. I support flicking the switch back now, provided Writ Keeper's code is good (and I see no evidence that it isn't). Jenks24 (talk) 07:31, 12 May 2016 (UTC)
- @Jenks24: No, I don't think we need another RfC - unless the WMF wants to convince us that the situation since the last RfC has changed drastically and that maybe the situation is different and they strongly perceive that the community has changed their mind. What could use another RfC is to just blanket override VE completely and completely disable it, whatever WMF is implementing (the few editors and the WMF people who really want it can then in their common.js override the override) - at least until they first ask the community (and preferably until the community agrees). --Dirk Beetstra T C 08:03, 12 May 2016 (UTC)
inconsistency in the user experience between IP editors and newly-registered users
- please don't go there. The WMF will just "solve" that by foisting VE on our IP editors too. —Cryptic 11:24, 12 May 2016 (UTC)
- @Cryptic: And you think that that is not the whole plan yet? --Dirk Beetstra T C 11:32, 12 May 2016 (UTC)
- @Beetstra: Oh, I'm sure it is. I just don't want to accelerate it. —Cryptic 11:34, 12 May 2016 (UTC)
- @Writ Keeper, Beetstra, and Cryptic: Yes, you're right, enabling VE as the primary editor for all IP uses is the eventual plan, as discussed at length last year. That's what the A/B test was going to be for – to provide data for the community RfC to help decide whether we were ready yet. Jdforrester (WMF) (talk) 18:53, 12 May 2016 (UTC)
I support deploying the javascript now to fix this bug community-side, per the fact that is an acknowledged bug, per the existing consensus regarding VE for new users, per the burden of having to clean up after so many VE edits, and per the fact that that we have hard data that VE is worse ( May 2015 study found much slower editing and lower rate of new users being able to successfully complete an edit, as well as a complete failure of the purported help more users make a first edit and complete failure to increase editor retention - which were the entire rationale for VE in the first place). If we're not prepared to deploy a javascript fix base on the old consensus then I support an RFC to establish a fresh consensus to do so.
Jdforrester (WMF), this sort of crap is why so many people don't trust anything the WMF says, why so many don't trust the WMF to engage in reasonable collaborative engagement. For half a year you and other staff have been promising you would not try to sneak in a goddamn VE default as part of the single edit tab deployment. Please fix this on your end - that is much preferable to a community side javascript fix. Alsee (talk) 19:43, 12 May 2016 (UTC)
- @Alsee: See below. It looks like you haven't seen it. Jdforrester (WMF) (talk) 19:56, 12 May 2016 (UTC)
Resolution
OK, there's way too much shouting right now, and no proper discussion. :-( With the fix that we've done, going out next week, we'll now show the welcome dialog to all users, regardless of editor; this will be in this week's Tech/News newsletter (as it will affect all users everywhere). This will improve the flow for new users (giving them the choice of editor), and then I'll undo the accidental part of the config change for this wiki. No point getting into a war, I'm here to work as a partner. Jdforrester (WMF) (talk) 18:49, 12 May 2016 (UTC)
- Of course we want collegial working. For that reason I've changed the section title from "Resolution" to "Proposed resolution". All the best: Rich Farmbrough, 19:58, 12 May 2016 (UTC).
- Since we the community have no control over software deployment, the 'proposed' part seems completely redundant, so I'll remove it. Folks, I do think the "community" should let go of the idea that it controls the Foundation and their decisions reagrding the development of MediaWiki. They own Wikipedia, and we are merely granted the privilege to edit it. We do not get to dictate the foundation on how they choose to operate Wikipedia, develop their software or run their servers. Sure, we have the right to yell when things go seriously wrong, but these days, every minor change is perceived as a disaster. This can only develop into a "boy who cried wolf" situation, where the foundation is growing numb to all the shouting, and may ignore it when there is a real problem. So you know what? Just swallow your pride and accept the changes already.
-- [[User:Edokter]] {{talk}}
20:27, 12 May 2016 (UTC)
- Disagree. They are granted the privilege to host it. The Foundation was created by the community, not the other way around. All the best: Rich Farmbrough, 20:39, 12 May 2016 (UTC).
- Uh, it was incorporated by Wales and Sanger to fund wikipedia. So yes, the foundation owns Wikipedia. Editors have no legal position within the foundation whatsoever.
-- [[User:Edokter]] {{talk}}
21:01, 12 May 2016 (UTC)
- Side note: ideas and discussion about communities' participation in software development are welcomed in mw:Technical Collaboration Guideline and subpages / Phabricator tasks. And one request related to this specific topic: please don't single out WMF individuals when criticizing WMF decisions. It is not fair for the person fulfilling a role in a team, and it doesn't help understanding and resolving the issue at stake. For instance, Fram singles out "Jdforrester (WMF)" in the title of this topic and other places. That is not necessary, and it is not too late to amend it (please). In Wikipedia terms, all I am saying is no personal attacks, please.--Qgil-WMF (talk) 08:54, 13 May 2016 (UTC)
NOT RESOLVED. Jdforrester (WMF), to quote you on your talk page the fix is the first editor that loads will still be the wikitext editor. If that is not fixed then the community javascript should still be deployed to prevent VE from loading by default.
If there is a dialog then "Continue Editing" simply clears the the dialog revealing the first-loaded wikitext editor. The "Switch" option on that dialog will need to be rewritten to say it's switching to Visual Editor. Alsee (talk) 21:21, 12 May 2016 (UTC)
- @Alsee: Yes. Jdforrester (WMF) (talk) 21:25, 12 May 2016 (UTC)
- Jdforrester (WMF) thank you. Alsee (talk) 21:48, 12 May 2016 (UTC)
wmflabs 'edit summary' search not working?
Today I wanted to search an editor's edits for a specific phrase in their edit summaries. I know they used this phrase in their edit summaries, I can see it in the first page of their contributions and yet...AND YET... when I use the edit summary search I get zero results. This is not possible. I sat down and hand-counted the edits over some period of months and knew there are at least 30 with this phrase. I tried one part of the phrase, I tried the entire edit summary from Twinkle but both times came up with no results. Is the edit summary search function not working these days? Thanks, Shearonink (talk) 14:24, 11 May 2016 (UTC)
- @Shearonink: Works for me Which user, what phrase? --Redrose64 (talk) 20:13, 11 May 2016 (UTC)
- Hmm... well, oddly enough, I just ran it again and it worked. Took a couple minutes to come up with the results though. Shearonink (talk) 20:41, 11 May 2016 (UTC)
How much is VisualEditor used?
Currently, what percentage of Wikipedia editors use VisualEditor? Related question: what percentage of Wikipedia edits use VisualEditor? --Guy Macon (talk) 09:31, 12 May 2016 (UTC)
- Enwiki, article namespace only, bots excluded: 95% of the edits are made using wikitext, 5% are made using VE.[26].
- VE has every day about 2,500 unique editors (less in the weekends, somewhat more during the week), while wikitext has about 21,000 unique daily editors. Excluding IPs, we have every day about 2K editors using VE and 8K editors using wikitext.
- More statistics can be found here. (Note that according to the WMF, these WMF-provided statistics are now useless to make the distinction between newly registered editors and other ones, as "newly" starts a few years back). Fram (talk) 09:51, 12 May 2016 (UTC)
- @Guy Macon: To answer your question, for the English Wikipedia, last week (roughly) 23% of logged-in editors and 6% of logged-in editors' edits (about 5% of all edits). Note that (e.g.) AWB edits push down this percentage as they technically count as wikitext edits (even though it's mostly a bot).
- However, I think the more interesting numbers are how successful edits are in using VE vs. WT for their first few edits (which is one of the main reasons why we're building VE, after all); see [27]. For this wiki last week, VE was 126% more successful than the wikitext editor at getting newbies to make their first edit (30.3% vs. 13.4%), and 26% better at making their 2nd through 5th edits (42.2% vs. 33.6%). For IP editors on the German Wikipedia (where VE is enabled by default for IPs, unlike here), it's even more pronounced – VE is slightly more than 600% better (9.2% vs. 1.3%) at getting people to actually make and save an edit.
- Jdforrester (WMF) (talk) 23:30, 12 May 2016 (UTC)
Cross wiki notifications will be released by default on May 12 at 23:00 UTC.
Hello
Cross wiki notifications will be released by default on all wikis on May 12 at 23:00 UTC
During the beta phase, the cross-wiki notifications feature was enabled by over 18,000 accounts across more than 360 wikis. We receive great feedback from a lot of very happy users. After that 3-months long beta period during which we made adjustments and that feature is now ready for a release by default.
Users who don't want to receive cross-wiki notifications will be able to turn them off on their preferences on each wiki. If you haven't activated Cross-wiki Notifications during the Beta phase, you may receive old unread notifications from other wikis.
More information is available on the documentation. The talk page is still open for any questions or feedback, in any language.
All the best, Trizek (WMF) (talk) 16:43, 12 May 2016 (UTC)
- User:Trizek (WMF) Hm... I like the feature. I suspect that a lot of people will get, as I did when I enabled it, a slew of years old notifications, which I didn't like. May I suggest you limit this to notifications to those left after the change to the default? All the best: Rich Farmbrough, 19:21, 12 May 2016 (UTC).
- I might also suggest that 6 hours and 17 minutes is not very much notice. All the best: Rich Farmbrough, 19:23, 12 May 2016 (UTC).
- We had discussed about that with the team and some users, and we have decided not to add a limit because that amount of old notifications was not that important on average and sometimes people had great surprises. did you received a lot of old notifications at the same time? Trizek (WMF) (talk) 19:30, 12 May 2016 (UTC)
- They appeared to arrive in two batches. All the best: Rich Farmbrough, 19:44, 12 May 2016 (UTC).
- These old notifications did in fact arrive in batches during the first few weeks of the beta feature release, because we made the beta feature available while we were still populating all the tracking information. This process took three weeks and went through all wikis in alphabetical order. It finished on March 22nd, so anyone who enabled the beta feature after that date should not have had the batched arrival experience, nor should anyone who first gets it when we enable it by default today. Any old notifications should be visible immediately, so while people will have to dismiss some old notifications, they'll only have to do that once. Besides, some people have reported finding useful things in there that they had missed before :) --Roan Kattouw (WMF) (talk) 20:03, 12 May 2016 (UTC)
- I only activated it a few days ago. So I am expecting that you will see some unexpected behaviour! All the best: Rich Farmbrough, 22:06, 12 May 2016 (UTC).
Translate tool
The translate tool seems to be having problems with English:
- The language doesn't appear in the "to" list
- If forced by manipulating the URL it says the translation to English is not supported.
What's going on?
All the best: Rich Farmbrough, 19:50, 12 May 2016 (UTC).
- @Rich Farmbrough: It works fine for me. Here's an example link, and screenshots of the selection interface and translation interface (one and two, tested in both chromium and firefox). I suggest filing a phabricator task, if you can't get it working, with details on the specific links you are using, and your browser/OS. Quiddity (WMF) (talk) 21:01, 12 May 2016 (UTC)
- I can get the screen you show by manipulating the URL. But even then the automatic translation is not available.
- All the best: Rich Farmbrough, 21:55, 12 May 2016 (UTC).
- @Rich Farmbrough: Oh, the "machine translation" is the specific part that you were referring to! That is because the language pair fr->en is not currently supported by Apertium or Yandex, according to mw:Content translation/Machine Translation. If you can and want to help, details are at mw:Content translation/Machine Translation#How can I improve machine translation support for my language?. HTH. Quiddity (WMF) (talk) 22:47, 12 May 2016 (UTC)
- But.. but.. I have used it in the past! All the best: Rich Farmbrough, 23:54, 12 May 2016 (UTC).
CAT:AFD/U
I noticed that CAT:AFD/U is quite populated this morning. Do we have a script for adding cats to uncategorized AfD pages? Sam Sailor Talk! 07:19, 13 May 2016 (UTC)
- Don't think so - but it's not difficult. Pick a letter, and slot it in. --Redrose64 (talk) 07:53, 13 May 2016 (UTC)
- Quite what I'm doing now, Redrose64. Sam Sailor Talk! 08:07, 13 May 2016 (UTC)
Cross-wiki notifications - how to clear?
Following the introduction of cross-wiki notifications, I now have a few messages from other projects. Clicking on "view messages" shows the list, but doesn't display the message text or any links - clicking on the hamburger icon and selecting "Mark as read" doesn't seem to do anything (the message count doesn't change and the message list is still populated). Do I have to visit each project individually to clear the messages, or is this a bug? I'm using Monobook on IE11, and en-wiki messages seem to be working correctly. Tevildo (talk) 07:38, 13 May 2016 (UTC)