Policy | Technical | Proposals | Idea lab | Miscellaneous |
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).
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. |
|||||||||||||||||||||
|
|||||||||||||||||||||
« Older discussions, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146 | |||||||||||||||||||||
Centralized discussion | |||
---|---|---|---|
Proposals: policy | other | Discussions | Ideas |
For a listing of ongoing discussions, see the dashboard.
Note: entries for inactive discussions, closed or not, should be moved to the archive. |
|||
Contents
- 1 Tech News: 2016-17
- 2 Watchlist getting stuck
- 3 how is RefToolbarLegacy.js getting added to Category:Pages with empty citations?
- 4 Scrollbar for map
- 5 Toolbar cite journal template not working
- 6 moving with a link? (Special:MovePage parameters?)
- 7 Error with categories for discussion through twinkle
- 8 Wrong category title
- 9 Dezoomify.py
- 10 frac template
- 11 Table convert tool
- 12 No link in diff-view to previous revision
- 13 Category:Articles to harmonize
- 14 URL processing to work around Chrome, etc., flaw
- 15 Presentation of parent categories
- 16 Annoying "Secure connection failed"
- 17 Odd references format
- 18 Revising a subst template to be more user-friendly after substing
- 19 How to automate display of pages at one per day?
- 20 Help improve search relevance with Discernatron 🤖
- 21 Tech News: 2016-19
- 22 ClueBot III
- 23 Email unsubscribed every time I use "Email this user"
- 24 Page views of non-mainspace pages
- 25 Printable/book versions
- 26 Statistics for page counts and breakdown of the source of the page counts
- 27 Where is this??
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)
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)
- 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)
moving with a link? (Special:MovePage parameters?)
Does Special:MovePage take any parameters in the URL such that you could create a link that moves a page? Ideally it would actually try to make the move, but I suspect that would pose too many potential problems, so perhaps it could just open the move page with the namespace, target, etc. already selected? — Rhododendrites talk \\ 20:37, 5 May 2016 (UTC)
- You can open the move form with source, target and reason filled out:
https://en.wikipedia.org/w/index.php?title=Special:MovePage&wpOldTitle=...&wpNewTitle=...&wpReason=...
. {{Db-move}} uses all three. PrimeHunter (talk) 20:56, 5 May 2016 (UTC)- Should really be described at mw:Manual:Parameters to Special:MovePage, but it doesn't exist (compare mw:Manual:Parameters to Special:Export). Only mention of a MovePage parameter that I can find is
wpReason=
at mw:Manual:Parameters to index.php#Special pages. --Redrose64 (talk) 11:38, 6 May 2016 (UTC) - There's also wpMovetalk (whether to move the talk page), whether to watch the 2 pages, whether to move subpages, and whether to leave a redirect behind. Do you know the URL parameters for the latter 3 options? GeoffreyT2000 (talk) 13:56, 6 May 2016 (UTC)
- There is wpMovesubpages and wpLeaveRedirect. Set =0 to not do it and =1 to do it. There is apparently something called wpWatch and wpDeleteAndMove (admin only) but I cannot get them to work. PrimeHunter (talk) 20:09, 6 May 2016 (UTC)
- Should really be described at mw:Manual:Parameters to Special:MovePage, but it doesn't exist (compare mw:Manual:Parameters to Special:Export). Only mention of a MovePage parameter that I can find is
Error with categories for discussion through twinkle
Hello - I am not sure what the problem is. I posted manually to Wikipedia:Categories for discussion/Log/2016 May 6 because I got an error message when using WP:Twinkle to nominate a category for discussion. When I got to that page, I saw that Eric similarly commented that they also saw an error message. I am not sure where the problem is. It seems that the process which posts "categories for discussion" to the daily log has been disrupted. Blue Rasberry (talk) 15:39, 6 May 2016 (UTC)
- Hello all- When I followed the "Click THIS LINK..." under Wikipedia:Categories for discussion#Procedure, I was brought to an edit window containing only the most recent nomination section, with no commented instructions. Eric talk 15:54, 6 May 2016 (UTC)
- I have restored the header and limited instructions which were removed by an IP.[7] PrimeHunter (talk) 22:38, 6 May 2016 (UTC)
Wrong category title
Discussion moved to Category talk:Maritime incidents by year. --Pipetricker (talk) 07:33, 7 May 2016 (UTC)
Dezoomify.py
I'm trying to download full-sized scrolls from the Digital Scrolling Paintings Project. Since this online tool seemingly doesn't work, I started to use Dezoomify.py. However, when trying, for instance, python dezoomify.py https://scrolls.uchicago.edu/scroll/erlang-and-his-soldiers-driving-out-animal-spirits c:\output.jpg I receive this in the command line:
ERROR: Zoomify base directory not found.
When I try base URL python dezoomify.py https://scrolls.uchicago.edu/scroll/erlang-and-his-soldiers-driving-out-animal-spirits -b c:\output.jpg I get this:
ERROR: Could not open ImageProperties.xml <HTTP Error 404: Not Found>.
Troubleshooting implies that ImageProperties.xml must be in URL, while URLs at the the Digital Scrolling Paintings Project seemingly lack them. Is there a way to fix this? If Dezoomify is incompatible with the Digital Scrolling Paintings Project, maybe there's another script or free program? Thanks. Brandmeistertalk 19:04, 6 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.
- 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)
-
-
-
- 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 [8]. 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: [9]
- 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)
- Thanks for the tip. — Maile (talk) 21:38, 8 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)
- I have seen some SPDY errors in Chrome recently, wonder if that might possibly be related. —TheDJ (talk • contribs) 13:54, 9 May 2016 (UTC)
- And it just happened to me again, first time today. I guess the only temporary solution, is to copy every edit before clicking "Show preview", which is where it happens. It's a bit of a glitch, that I guess will keep happening for a while. — Maile (talk) 22:29, 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 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)
- 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 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 [10]. 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)
- 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 [10]. I haven't tried the others. For another time, note that Template:Dead link#Usage says: "this tag should be placed just before the
- Ooh, blimey. A real techno-geek. Thanks. Martinevans123 (talk) 21:02, 8 May 2016 (UTC) p.s. great user name
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?
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)
Tech News: 2016-19
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)
- Gmail it is, and that works. Thank you all. JohnCD (talk) 13:44, 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 [22] (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)
- 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)
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?
Thanks, postdlf (talk) 16:32, 10 May 2016 (UTC)
- 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
ormetadata
), and those classes are given the CSS declarationdisplay: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 valuenone
. 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)
- 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
- 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)
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)
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)