This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
I see no favicon in Firefox 39.0 tabs for redirects to sections, for example Wiki spam and others tested in Category:Redirects to sections and the five other languages listed there. I see the favicon in Wiki spam in IE, Chrome, Safari and Opera. In Firefox I see the favicon for Spamdexing (direct link to the page) and Spamdex (redirect to the page but not to a section). Do others have the Firefox issue? PrimeHunter (talk) 02:26, 3 July 2015 (UTC)
I couldn't see it for the Wiki spam page in 38.0.5. But then when I went to verify the version number, the browser auto-updated to 39.0 and now that page does show a favicon. Regards, Orange Suede Sofa (talk) 02:45, 3 July 2015 (UTC)
Are you still on the page saying "(Redirected from Wiki spam)" when you see the favicon in 39.0? We use url redirection now so if the page is reloaded then you get the redirect target Spamdexing#Wiki spam where I do see the favicon and no "Redirected from". PrimeHunter (talk) 02:51, 3 July 2015 (UTC)
Yes, I see the favicon on the "Redirected from..." page. When I reload the page, the "Redirected from..." disappears as expected and the favicon remains. Orange Suede Sofa (talk) 03:04, 3 July 2015 (UTC)
So today I finally started my css page. I've never done that before because I find css very confusing.
Here's what I'm trying to do: hide certain templates. I pulled some css from Template:Humor/doc, though I don't want to hide those templates in particular. I added one I did want to hide, which didn't work, and upon looking at the template codes I further edited it to this. It still didn't work, so I removed all code (because it might compromise my account, booga-booga.) So, anyone know why this is happening? Eman235/talk13:43, 3 July 2015 (UTC)
@Eman235: I think your problem is that you need a comma after all but the last class selector (You're missing one after .ombox-humorantipolicy). That CSS code is essentially looking for a not-a-forum box inside a humorantipolicy box, which won't exist. Adding the missing comma should solve your problem. /~huesatlum/ 14:27, 3 July 2015 (UTC)
Since a few hours ago, there's a significant vertical gap left between the line containing "Clear the watchlist" and the "You have n pages on your watchlist..." line. All that with dismissed announcements and "Mark all pages as visited" button hidden with some custom JavaScript. Any clues? It used to be all neat and tidy. — Dsimic (talk | contribs) 04:54, 2 July 2015 (UTC)
While we're on the subject, could someone update the watchlist Legend so we mortals will know what the circles and arrow and bullets and colors mean? And BTW, I've been meaning to ask for some time (though I haven't seen this in a week or two): changed-since-my-last-visit articles usually show up in a deep bold blue, but someones one or two up them are in a sort of grayish blue. Anyone want to explain (or, again, update the legend)? EEng (talk) 14:18, 2 July 2015 (UTC)
@EEng: Hm, I'm a bit confused as I see no such things (circles, arrows and different shades of blue) on my watchlist. Out of curiosity, which watchlist-related options are enabled in your preferences? Oh, and I have some custom CSS forcing bold page names for modified watchlist entries. — Dsimic (talk | contribs) 20:35, 2 July 2015 (UTC)
At Preferences > Gadgets I've got these two checked:
Display green collapsible arrows and green bullets for changed pages in your Watchlist, History and Recent changes
Display pages on your watchlist that have changed since your last visit in bold.
Sometimes they're green and sometimes they're blue, and now there are little green bullets sometimes. It's all very entertaining. EEng (talk) 21:11, 2 July 2015 (UTC)
What's even more confusing, I also have those two options checked, and really haven't seen any fancy watchlist inconsistency. Which skin do you use? I'm using the default Vector skin, while viewing everything in Firefox. — Dsimic (talk | contribs) 21:20, 2 July 2015 (UTC)
Green indicates pages you haven't visited yet since they were updated (which is also explained at the top of your watchlist). An arrow indicates a collapsed item, which you can expand. -- [[User:Edokter]] {{talk}}20:41, 3 July 2015 (UTC)
List of contributors
I recently made a post to the help desk asking "is there an easy way to get a list of all the users (and IPs) that have contributed to article X, and maybe even list them in order of number of edits to the page?" and I was directed here. I think there's an xTools page ([1]) that's supposed to accomplish this but it doesn't work for me. I need the list fairly soon because the page (QI (A series)) is up for deletion and the page history is a bit long to go through manually. — Bilorv(talk)(c)(e)22:01, 3 July 2015 (UTC)
this has been down for a very long time,(its important for articles like Dyslexia, Ebola/west Africa,..)is there any idea when it will be working? thank you--Ozzie10aaaa (talk) 22:12, 4 July 2015 (UTC)
The whole xtools suite appears to be in a state of flux. The basic problem is that the people who made it are no longer active. Per the recent watchlist notice, some are trying to assemble a new team to rewrite it from scratch. But it is not clear whether they will succeed or how long that would take. Out of curiosity, what statistics specifically are you looking for?--Anders Feder (talk) 05:16, 5 July 2015 (UTC)
Database error
From Wikipedia, the free encyclopedia
• Javascript-enhanced contributions lookup 0.2 enabled. You may enter a CIDR range or append an asterisk to do a prefix search.
A database query error has occurred. This may indicate a bug in the software.
Function: IndexPager::buildQueryInfo (contributions page filtered for namespace or RevisionDeleted edits)
Error: 2013 Lost connection to MySQL server during query (10.64.32.25)
Search my contribs with namespace "Module" or "Mediawiki" if this fails to provoke an error (due to caching) try another rarely (or never?) edited namespace, or another user with many edits such as User:Koavf.
It's slow but works for me, for example for you on TimedText which gave "No changes were found matching these criteria.", on a correctly looking page without error messages. PrimeHunter (talk) 16:06, 29 June 2015 (UTC)
I'm not surprised, the second time I did it with "Module" it worked, though whether this is a result of smart caching or variance in database load I cannot tell. Nonetheless I would think that the software could deal with these queries, either by chunking or increasing the timeout. All the best: RichFarmbrough, 22:42, 29 June 2015 (UTC).
{{PAGESINCATEGORY|Featured articles|R}} should give the number without commas. Strangely this is not working - 6627. Anyone know why? All the best: RichFarmbrough, 15:51, 29 June 2015 (UTC).
mw:Help:Magic words#Statistics shows several possible values of a second parameter, and if others than R are used then R can be a third parameter. If you want the template to be similar to the magic word then you could just pass everything on with |{{{2|}}}|{{{3|}}}. It appears the magic word just ignores the extra parameters if they are empty. PrimeHunter (talk) 23:09, 29 June 2015 (UTC)
I noticed some strange percent encoding, every time an IP made a mobile edit, ref names were getting another layer of % encoding - [2]. Is this a known bug, or a one off glitch we can ignore? All the best: RichFarmbrough, 18:51, 5 July 2015 (UTC).
Most of those user's edits are not tagged mobile. And the one that is, doesn't show this problem. I'm guessing that the user's browser has an extension that is buggered up by installed extensions or something. —TheDJ (talk • contribs) 19:58, 5 July 2015 (UTC)
Looks more like vandalism to me. The IP labelled that edit as "fixed the page". The IP has been blocked by the way. Tvx1 20:08, 5 July 2015 (UTC)
The substantive edits seem ok. The IP was blocked as an open proxy, thanks for pointing the block out. All the best: RichFarmbrough, 20:17, 5 July 2015 (UTC).
I assumed they had overridden the tag - I guess that can't be done? Perhaps they were trying not to make that problem. Anyway its something to watch out for. All the best: RichFarmbrough, 20:17, 5 July 2015 (UTC).
Conversion to PDF
A reader reported problems converting two articles to PDF. I just tried each of them and can confirm the same problem. In each case I received the following error:
Status: Bundling process died with non zero code: 1
I had hoped to respond that the problem has been resolved but I tried both of these and both failed. I placed the error message after the article name.--S Philbrick(Talk)14:23, 4 July 2015 (UTC)
Good catch, I glossed over the single word difference in the error message. This means that the prior problem, which is reported solved, is solved and this is a different issue. You identified the bug report for the first error. The second one does generate a different error. It has already read been reported as T88890. That report talks about a problem working with collections. I added this specific instance to show that it can be generated with a single article.--S Philbrick(Talk)13:27, 6 July 2015 (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
On the mobile site, you now see more information when you search for a page. It now shows the description from Wikidata. [3]
Problems
The code of long pages is not colored any more. You may see this problem on the pages of long gadgets. [4]
Changes this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from July 7. It will be on non-Wikipedia wikis from July 8. It will be on all Wikipedias from July 9 (calendar).
The "Page information" tool shows how many users watch the page. You can now see how many are active. [5][6]
You can now translate articles into English with the new translation tool. [7]
Meetings
You can join the next meeting with the Editing team. During the meeting, you can tell developers which bugs are the most important. The meeting will be on July 7 at 19:00 (UTC). See how to join.
Over the last few years, the Wikimedia Foundation has been working towards enabling HTTPS by default for all users, including anonymous ones, for better privacy and security for both readers and editors. This has taken a long time, as there have been different aspects to take into account. Our servers haven’t been ready to handle it. The Wikimedia Foundation has had to balance sometimes conflicting goals, having to both give access to as many as possible while caring for the security of everyone who reads Wikipedia. This has finally been implemented on English Wikipedia, and you can read more about it [link-to-blog-post here]here.
Most of you shouldn’t be affected at all. If you edit as registered user, you’ve already had to log in through HTTPS. We’ll keep an eye on this to make sure everything is working as it should. Do get in touch with us if you have any problems logging in or editing Wikipedia after this change or contact me if you have any other questions. /Johan (WMF) (talk) 12:43, 12 June 2015 (UTC)
To editor Johan (WMF): – You have to know what a real drag this is. Not only do I want a CHOICE in the matter, and would continue to choose HTTP as long as the edit summary field's autofil function does not work when I'm on the HTTPS server, you should also consider what Redrose64 said above, that some users are unable to use HTTPS connections. The part in the blog post about "all logged in users have been accessing via HTTPS by default since 2013" is just not true, either. We've been given a choice up until now, and I for one do not want to give that up. I want to be able to CHOOSE whether or not I'm on the HTTP server or the HTTPS server. – Paine14:21, 12 June 2015 (UTC)
Yes, we do know. The answer I was given when I asked about this is that any form of opt-out would also leave potential security risks in our implementation which make it difficult to safeguard those who do not opt-out. Because of this, we’ve made implementation decisions that preclude any option to disable HTTPS, whether logged in or not. This renders the current opt-out option ineffective, and the option will be removed at a later date after we’ve completed the transition process. /Johan (WMF) (talk) 14:27, 12 June 2015 (UTC)
It's evidently a weighty issue. And I do realize that I don't edit WP in a vacuum, that I must eventually accept this situation for the good of all. And frankly, I don't have a problem with having to stay on HTTPS as pertains to the "big picture". My problem is very basic and concerns the fact that I no longer have a drop-down list from which to pick my edit summaries, because that function is thwarted by my IE-10 when I am on any HTTPS server. If that little quirk could be fixed, I'd be a happy camper whether I'm on a secure server or not. – Paine15:47, 12 June 2015 (UTC)
@Johan (WMF): IE10 won't enable autocomplete on HTTPS pages when the "Cache-Control: no-cache" HTTP header is set (which Wikipedia does). Changing it from "no-cache" to "must-revalidate, private" would allow autocomplete, but may have other unintended consequences. --Ahecht (TALK PAGE) 16:34, 12 June 2015 (UTC)
@Paine Ellsworth: It seems like IE 11 does not have this problem, and all users would eventually be required to update to it by the end of the year (by Microsoft). Did you try IE 11? Tony Tan·talk02:09, 14 June 2015 (UTC)
Yes, Tony Tan, I upgraded to Win8.1 and IE-11 yesterday and was pleased to pass it on that it has given me back what I had lost with the older browser and Windows software. Thank you very much for your kind thoughts and Best of Everything to You and Yours! – Paine02:26, 14 June 2015 (UTC)
I also see I am struck with using HTTPS, which is nuisance and a bother as I longer have a drop-down list from which to pick my edit summaries. How can a drop-down list be re-implemented? It was the only degree of automated help we had in what is otherwise an unfriendly article editing environment. Hmains (talk) 17:44, 12 June 2015 (UTC)
So how do I use the website in http then? I do not want extra security to protect me. I don't need protecting. This is a nonsense. Why am I being forced to use https even though I don't want to use it? There was an opt out. The opt out has been removed despite the fact that those using the opt out very clearly want to opt out. — Preceding unsigned comment added by 86.18.92.129 (talk) 19:46, 12 June 2015 (UTC)
Hi, the reason explanation I've been given is that any form of opt-out would also leave potential security risks in our implementation which make it difficult to safeguard those who do not opt-out. /Johan (WMF) (talk) 19:53, 12 June 2015 (UTC)
Johan (WMF), Re: "the reason explanation I've been given is that any form of opt-out would also leave potential security risks in our implementation which make it difficult to safeguard those who do not opt-out", would you be so kind as to ask for a one-paragraph explanation as to why they believe this to be true and post it here? Not a dumbed-down or simplified explanation, but a brief, fully technical explanation for those of us who are engineers? Thanks! --Guy Macon (talk) 20:49, 12 June 2015 (UTC)
Sure. Just so you know, they're getting a lot of questions at the moment, as well as handling the switch for the hundreds of Wikimedia wikis that aren't on HTTPS yet, but I'm passing on all questions I get that I can't answer myself. /Johan (WMF) (talk) 21:18, 12 June 2015 (UTC)
The engineering-level explanation is that in order to help prevent protocol downgrade attacks, in addition to the basic HTTPS redirect, we're also turning on HSTS headers (gradually). The tradeoff for HSTS's increased protections is that there's no good way to only partially-enforce it for a given domainname. Any browser that has ever seen it from us would enforce it for the covered domains regardless of anonymous, logged-in, logged-out, which user, etc. Once you've gone HSTS, opt-out just isn't a viable option. /BBlack (WMF) (talk) 21:56, 12 June 2015 (UTC)
To editor Johan (WMF): I don't see what the problem is: create a cookie named something like IAcknowledgeThatHttpIsInsecure which can be set from a dedicated page: if this cookie is set, do not send the Strict-Transport-Security (HSTS) header and do not force redirect to HTTPS. Yes, people who have received the Strict-Transport-Security header will get a browser error, but I assume all browsers that implement HSTS allow some way for the user to manually override or ignore it (something like "I know what I'm doing", then set a security exception); and the users can be warned in advance on the dedicated page that sets the cookie. If you're afraid an attacker will set the cookie on an unsuspecting user (through a fake Wikipedia page) and thus bypass HSTS, please note that (1) this attack always exists anyway, because an attacker who can do this can setup a fake HTTP wikipedia.org proxy domain anyway (in both cases, it will impact those users who did not receive the HSTS header), and (2) you can mitigate the attack by letting the cookie's content contain a MAC of the client's IP address (or some other identification string), with a MAC key that Wikimedia keeps (and the cookie is honored only if the MAC matches). You might also display a warning in the HTML content if the cookie is set, reminding of its existence and impact, and giving a link to remove it should the user change their mind. The performance cost of all of what I just described should be completely negligible in comparison with the performance cost of doing HTTPS in the first place. And this should all be very simple to implement. On a personal note: I promise to donate 150€ to the Wikimedia foundation (adding to the 100€ I donate about once a year) if and when a way to access it through HTTP using the former URLs is brought back; conversely, until this happens, I will be too busy to consider how I can work around this inconvenience to contribute either financially or by editing articles. (I could also go on to emphasize how, as a cryptographer, I think the idea of forcing users to go through HTTPS to read publicly accessible and publicly editable information is absolute idiocy, but the cryptophile zealots have made up their mind already.) --Gro-Tsen (talk) 19:43, 13 June 2015 (UTC)
Keyed MAC of client IP address is not going to work due to dynamic IPs that change (And I'm not sure that there exists any other unique identifier that would be appropriate. Keep in mind, for your scheme to work, the browser cannot receive an HSTS header even once). Note that deleting an HSTS setting from your browser is actually much more hidden then you'd normally think, and are generally not meant to be user overridable. While you're correct that HSTS cannot prevent a malicious proxy if the user has never visted wikipedia before (unless we do HSTS preloading, which we do not yet), your scheme weakens the protection of HSTS, since a malicious proxy only has to set a cookie for wikipedia, not necessarily catch the user at the first visit. Furthermore, in order for the redirect not to take place, the cookie must be non-secure. Hence the malicious proxy might as well just pretend to be some fake subdomain, e.g. http://fake.wikipedia.org (Which since its fake, does not have HSTS, unless we set the includeSubDomains flag for HSTS, which we don't currently, and would prevent us from ever hosting a non-secure service on any subdomain), use some method to load traffic from that address (easy), and then set your IAcknowledgeThatHttpIsInsecure cookie with the domain field set to .wikipedia.org. Last of all, your scheme is also incompatible with HSTS preloading, which presumably the WMF is eventually going to pursue. Bawolff (talk) 00:53, 14 June 2015 (UTC)
OK, I'll give up on trying to solve other people's problems with HTTPS and focus on mine: to this effect, do you (or anyone else) knows if there at least exist some reliable transparent Wikipedia mirror on HTTP (perhaps something like "wikipedia-insecure.org") that allows both reading and editing and that I could use (by spoofing my DNS to point there) without the trouble of setting up my own? (I hope we can agree that a mirror served under a different domain cannot weaken security since anyone can set up such a thing.) I'll find a way to disable HSTS on my browser somehow. --Gro-Tsen (talk) 23:02, 14 June 2015 (UTC)
It's worth giving some background here to understand the need for security. One of last year's revelations was that Wikipedia editors were being targeted by the NSA. So if you weren't using HTTPS (and probably even if you were), you were likely helping to build a database profile on your reading habits. But worse, your e-mail and other communications were probably also targeted for follow-up simply because you edit Wikipedia. What difference does it make? Nobody in the general public knows! The collected information is used in secret fashion in secret ways by undisclosed people. But there are real dangers to you. Supposedly, the information is being used only for national security related to terrorism. That's not true, however, because it is known from the same leaks that it is being used for more than that, for instance, in the war on drugs. And, it is also known that collected information is sometimes abused by those who have access to it for personal reasons. The use could also include (and probably is) helping to decide whether you get security clearance for future dream job. it could potentially even be used to sabotage a hopeful's political career or in general help silence people with oppositional points of view. In other words, this information has the potential to be used by people now or in the future to negatively affect your life and destiny without you even knowing. The WMF has decided (and rightfully so) that there's a need to protect users from dangers that they might not even be aware of. When it comes to this, many people say things like "I'm not doing anything wrong" or "I've got nothing to hide" but the problem is that you can't say you're doing nothing wrong because it's third parties who determine that, not you. And you do have stuff to hide even if you are completely a law-abiding citizen. This issue that affects you even if you think it doesn't. People are talking above about certain countries that do not allow HTTPS and how IP users there should be not be forced to use HTTPS because Wikipedia would be blocked for them. Well, those are great examples where governments being able to see what you are reading could get you arrested, imprisoned, or worse. The use of HTTPS is only a minor step in combating the abuse of government-level surveillance but it's a step in the right direction. @Johan (WMF), it'd be interesting to know why the implementation cannot safely handle an opt-out because naively I don't see why the one should affect the other. Maybe this exposes a flaw in the implementation. Jason Quinn (talk) 21:17, 12 June 2015 (UTC)
On January 12, 2016, Windows 7 users will be required to install Internet Explorer 11 and Windows 8 users will be required to update to Windows 8.1 anyway, so you don't need to worry about the autocomplete problem in IE10. That problem doesn't occur in IE11. GeoffreyT2000 (talk) 21:26, 12 June 2015 (UTC)
Wikipedians were NEVER targeted by the NSA, why would they be? I don't know where you people are getting your information from and if some wikipedian came along and said that s/he was being targeted, then s/he was either being paranoid (like 90% of americans) or s/he is doing soemthing "illiegal" so its the best interest of wikipedia to report that person to NSA, not ENFORCE this stupid idea....Again Wikipedia is an INTERNATIONAL website, its NOT only for AMERICA....why should the rest of the world have to pay for the fears of a few paranoid psychopaths that are better off in jail..oh and BTW, HTTPS has and will NEVER be secure, the "s" in https never stood for secure...@Jimbo Wales:, Why would you allow this?--Stemoc21:43, 12 June 2015 (UTC)
At the right is the main slide itself so you and others can decide for themselves what it means. The slide explicitly uses Wikipedia as an example of the websites that they are "interested in" and confirms that they are interested in "typical users" of such websites. Given the context of the slide (exploiting HTTP for data collection), it is unreasonable to assume readers and editors were not being targeted. We all were targeted and all our traffic to and from Wikipedia would have been caught up in the named NSA collection programs. It would be naive to think otherwise. If there is one thing that's been learned in the last year, it's that "if it can be done, it is" kind of summarizes what's been going on and "mitigated" does not described their collection techniques. As for other countries being denied access by the global removal of HTTP support, that is a point that should be debated. But I already mentioned that there are countries were the use of HTTP might literally allow Wikipedia readers to be executed for readings the "wrong" stuff. The meaning of a "free" encyclopedia would have to be discussed and the dangers of access in these countries would have to be considered and weighed in such a debate. And, regardless of how you perceive the US, it's possible the US could become as bad. Jason Quinn (talk) 22:30, 12 June 2015 (UTC)
The real win here (imo) is making Firesheep style attacks totally impossible and thwarting non-state sponsored, and lower budget state sponsored adversaries. One assumes that the NSA will probably just slurp up the unencrypted inter-data center links (For those of you not close enough to use eqiad directly. Imagine a world where the sum of human knowledge fully deployed IPSec). Given the funding level of the NSA, I expect that they probably have traffic analysis capabilities to be able to tell who is visiting a page of interest (especially for a site like wikipedia, which imo seems like the perfect target for a traffic analysis type of attack against a TLS secured connection). However https does make it much harder to simply collect it all, and any measure that increases the cost of ubiquitous surveillance should be applauded. Bawolff (talk) 22:50, 12 June 2015 (UTC)
All I see Jason is a bunch of American websites.....Mate, if NSA want to spy on you, it WILL SPY on you, you don't have to eff up wikipedia for them to stop and basically, by forcinghttps onto the wikipedia, would you not think that it will make NSA more interested? because only a person with something to hide would do this ..So Jimmy loses his battle with NSA in terms of NSA and this is what he comes up with? moving to https which honestly is just as secure as http...After this was defeated last year, i honestly felt like we lived in a democracy where the voice of the people was heard and adhered........back to communist wikipedia we go..yeah Jason, executed for reading the wrong stuff on wikipedia like How to build a Bomb or How to join ISIS......oh right, we don't have those pages cause wikipedia is NOT a terrorist organization...--Stemoc22:59, 12 June 2015 (UTC)
(a) Non-Americans arguably have got more to fear from NSA surveillance; the legal framework allows for the collection of great swathes of foreign data. (b) The decision was made by Wikimedia, which is in no way a democracy. (c) Do actually read up on the issues you're arguing. Alakzi (talk) 23:29, 12 June 2015 (UTC)
Yeah, you really shouldn't let your anger and/or frustration allow such bullshit from your fingers and keyboard, Stemoc. "Communist Wikipedia"? no more than an airline practices communism when they check for bombs and weapons as we board – no more than when we have to pass through a building security point that helps to protect us while we're on the premises - is it communism to own a .357 and be ready to shoot a criminal who tries to steal from you? or to hurt your loved ones? Privacy, security, if you don't try to work with structures that protect them, then you're no better than the criminal, terrorist or agency that tries to circumvent them. Best of Everything to You and Yours! – Paine00:03, 13 June 2015 (UTC)
Calm down lady, this is just an Encyclopedia, not your ebay, paypal, bank account or your social networking sites where privacy is a MUST NEED for safety reasons.. the MAIN reason this site was created was to allow users to browse and edit anonymously so no one really knows your true identity or location, if you are using your real name and stuff, I'd advice you to invoke the 'Vanish' policy and start anew or get your account renamed, I think people keep forgetting that this is NOT like every other site they visit, infact wikipedia is based on facts and if you are scared to write down fact on articles because you fear the NSA then i really really pity you... only crooks fear the government....let that be known...and p.s, I'm brown and I don't give a shit about the NSA...as usual, the wiki revolves around America...pathetic.--Stemoc02:47, 13 June 2015 (UTC)
@Stemoc: Out of curiosity, what do you think about the following hypothetical situation: Someone (Lets say Alice) thinks she might have <insert weird disease here>. Alice wants to look it up on Wikipedia, but is worried that her ISP is tracking which websites she visits, and will sell the information to her insurance company (or whomever else is the highest bidder), who in turn will jack up the price of her insurance beyond what she can afford, on mere suspicion of having the disease, even if she doesn't have that. Is that a legitimate reason to want/need privacy when browsing Wikipedia? You may trust the government (For some reason), but do you really trust your ISP? What about the guy sitting across the room at the starbucks on the same wifi network? Bawolff (talk) 06:12, 13 June 2015 (UTC)
Bawolff, again, another "american" problem....I have an IDEA, why not make a us version for https?, brilliant now, e.g, anyone that wants to be logged in on https, log in at https://us.wiki.riteme.site and everyone else at the old link at http://wiki.riteme.site, this will solve the problem once and for all, why "force" everyone onto https, its the same as pushing everyone over the cliff and telling them to swim instead of building a bridge to get across, those who can't swim or having health (ISP) problem will surely drown..I fought this the last time it happened and I will fight it yet again..--Stemoc11:43, 13 June 2015 (UTC)
+1. Live in a country with universal health care...Or has privacy laws...I am an IT professional with a Computer Science Degree and 30+ years of experience. I know the implications of not using HTTPS, an I also know the NSA can bypass that easily if they care to. This (not allowing an opt-out) is total garbage and a false sense of security...˥ Ǝ Ʉ H Ɔ I Ɯ (talk) 11:56, 13 June 2015 (UTC)
Now cut that out, buddy, or I'll hit you with my purse! Hey, waitasec – how did you know I'm a "lady"? You been hackin' into my HTTP??? – Paine12:46, 13 June 2015 (UTC)
@Bawolff: We're not done with all of our plans for securing traffic and user privacy. This will be covered in deeper detail in a future, engineering-focused blog post after the initial transition is complete. But just to hit some highlights in your post: we do have an active ipsec project, which is currently testing on a fraction of live inter-DC traffic. We're also looking into what we can do for some forms of traffic analysis, e.g. mitigating response length issues. We plan to move forward as soon as possible on heavier HTTPS protection mechanisms like HSTS Preloading, HPKP, etc as well. We're committed to doing this right, we're just not done implementing it all yet :) -- BBlack (WMF) (talk) 01:53, 13 June 2015 (UTC)
@BBlack (WMF): I appreciate there's more to come, and I'm happy to see that its (finally) happening. However I think its important to give our users the full picture, the good, and the bad. HTTPS is great for confidentiality and integrity. Its somewhat ok for providing privacy, particularly against a weak adversary, and it makes bulk matching of packets against fixed strings in the body of the request impossible (Which is quite important given the selective censorship threat wikipedia faces). But its questionable how well it would hold up against a powerful nation state actor trying to simply de-anonoymize you. It certainly wouldn't hold up against a targeted attack, and its questionable if it would prevent a more broad attack (albeit it would certainly make a broad attack quite a bit more expensive to pull off). I'm also quite doubtful you can really foil traffic analysis with padding TLS sessions, unless you use extreme amounts of padding, far past what is acceptable performance wise. p.s. The ipsec project link is limited to those in the WMF-NDA group, so I can't see it (I'm in the security nda group only). However I can certainly see in puppet that IPSec is enabled on a small number of servers, and I noticed it was mentioned when I was reading the WMF quarterly report. Bawolff (talk) 03:03, 13 June 2015 (UTC)
@BBlack (WMF): It is great to see that the WMF is finally switching to HTTPS by default. I look forward to seeing Wikipedia send HSTS (includeSubDomains, long max-age, preload) and HPKP headers! However, phab:T81543 seems to have restricted access. Thanks, Tony Tan·talk02:39, 14 June 2015 (UTC)
One of the nice things I just noticed that is really nice is that ru.wikipedia.org has an A+ on the SSL labs test [8]. Here's to looking forward to that for all Wikimedia domains, once HSTS is turned up :D Bawolff (talk) 05:20, 14 June 2015 (UTC)
Not such a difficult fix
Just want to make sure that everyone catches what contributors TTO (at phab:T55636) and GeoffreyT2000 (above) have been kind enough to share with us. Several of the above users may be happy to hear that I can confirm what TTO and GeoffreyT2000 say about Win8.1 and IE-11. I just upgraded, and the new software thus far seems to work a lot better under HTTPS than my old Win8.0 and IE-10 did. Forms do indeed autofil, which means that my old drop-down boxes with my edit-summary choices do show up again. I still sympathize with all the users above who feel they've lost something with this change, however, like I said, we don't edit in a vacuum any more than we become passengers on aircraft all by ourselves. As an analogy, airport security can be a real hassle and a serious time cruncher on occasion, but compare that to what has happened, and still could happen, and there should be none of us who would not want that security to keep our flying times safe. Same for the conversion to HTTPS – it is quite the hassle for some, but the very real need to protect our privacy and security is an overwhelming priority, in my humble opinion. So, /Johan (WMF), you don't have to find an IE fix for me, and I greatly appreciate the fact that you said you would! I also deeply thank the rest of you for your enlightening responses here. Best of Everything to You and Yours! – Paine23:32, 12 June 2015 (UTC)
Thank you. I'll still at least ask around to see if there's anything I can do. We want editing Wikipedia to be as simple as possible, no matter which browser people use. If one is OK with upgrading to IE 11, that's probably the best solution, though. /Johan (WMF) (talk) 01:25, 13 June 2015 (UTC)
So, here's what I got on this issue so far. Yes, there appears to have been an open Phabricator ticket since 2013 reporting this issue, and no, given the number of tickets, the team that dealt with the transition wasn't aware of it. We'd obviously have preferred to be. Sorry, and I really mean it. Causing trouble for people who edit Wikipedia is the opposite of what we want to achieve. We're still in the process of transitioning (English Wikipedia was one of the first to switch over, and there are more than 800 Wikimedia wikis) and I haven't found an easy fix so far (except for upgrading to Internet Explorer 11), as this isn't so much a bug as how Internet Explorer 10 intentionally behaves. The team will be able to focus more on this as soon as the HTTPS transition is complete. We're not ignoring the issue. /Johan (WMF) (talk) 12:10, 16 June 2015 (UTC)
This broke my bot :( I'm using RestClient library to make API requests, and it apparently is unable to verify the certificate. Getting the error SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (RestClient::SSLCertificateNotVerified) Surely that's an issue on my end? I can force it to not verify the certificate but then what's the point of using HTTPS? — MusikAnimaltalk18:32, 13 June 2015 (UTC)
I took a quick look, and it seems that this library has a way to pass to the SSL library the CA certificates to be used for verification. It probably just doesn't have a default set of CA certificates. The solution would be to give it a copy of the correct root certificates to use. --cesarb (talk) 21:26, 13 June 2015 (UTC)
Who loses
@Johan (WMF): Hi, while you are here I would like to have something specific clarified. As always with these sorts of major changes, most people win and some people lose. I personal am iffy about the distribution of relative ideological and technical interest and need for this particular project, but I accept that that merely puts me in the middle of the Wikipedian spectrum, between people like TomStar81 who wants nothing to do with the ACLU and people like Jason Quinn who thinks it keeps us from being roasted on an open flame.
However in these sorts of changes I care less about who wins, because that's obvious. I can read the spam-ish blog post to find that out. I am more interested in the question: who loses?
Who does HTTPS hurt? Can we come to an understanding of this? Surely every change, no matter the size, hurts some stakeholders. ResMar03:58, 13 June 2015 (UTC)
Can someone clarify what is going on with the IE 10 issues? Was the WMF aware of this problem? Is it really that significant?
Can someone clarify what the effect will be in mainland China? Can you quantify the impact there?
Hi, good question that deserves a good answer, not just what I can come up with on the top of my head. I'll ask around about a few things to make sure I (or maybe someone else, I'll spend much of this weekend travelling) can reply properly. /Johan (WMF) (talk) 04:19, 13 June 2015 (UTC)
Great! Thank you. I think this discussion so far has been high on posturing, low on content (speaking about the community response here), and I'd love to see a frank cost-benefit analysis from the WMF on this matter, and an associated community critique. After all, this is the communication that the volunteers so crave. Not, frankly, blog announcements. ResMar04:44, 13 June 2015 (UTC)
I'd also like to see my transparency on WMF's the analysis. Everything seems to be shrouded in unnecessary secrecy. On the subject of China. I'm not that familiar with the situation, but according to https://en.greatfire.org/search/wikipedia-pages - HTTPS is currently not blocked There seems to be conflicting info on if HTTPS is blocked. The greatfire website says https is not blocked, but there actual test data seems to suggest that both normal http and https on zh is blocked starting may 19 [9] (The switchover for zh to https happened on June 9, so change in blocking status seems unrelated) but en is fine (both https and non-https). There are about 324 pages that are censored on the HTTP version, mostly on zh, however on en we had Students for a Free Tibet, Tiananmen_Papers, Tiananmen_square_massacre, Tibetan_independence_movement blocked. Switching to HTTPS forces china to decide either to block all of wikipedia or none of wikipedia (Possibly they can distinguish between languages and block say all zh, but not en. I'm not that familar with SNI, but my impression is the domain is sent in the clear). FWIW, greatfire strongly advocates switching to https on zh wikipedia [10], although they are obviously a special interest group that believes Chinese censorship needs to be fought tooth and nail. I imagine the situation is similar for Russia, which rumor had (Although I've not seen direct sources for this) was trying to censor pages related to Ukraine on ru, but can't anymore due to https. The other impact, is that it makes harder (but certainly not impossible depending on their traffic analysis capabilities) for China to generate lists of people who try to visit certain politically sensitive topics (Its unclear if they actually do that. I haven't heard of any evidence that they do, but it wouldn't surprise me). Other potential things to keep in mind, in the past China has DDOS'd websites (GitHub) that host material China finds objectionable, but cannot be censored selectively due to HTTPS and are too popular to block outright (However, I consider it very unlikely they would do something like that to Wikipedia. Wikipedia has a low enough popularity in China, that they would probably just block it totally if they decided to do something about Wikipedia). Bawolff (talk) 05:18, 13 June 2015 (UTC)
Regarding secrecy, or at least part of it: yeah, we didn’t really enjoy springing this on the community, though the WMF has publicly been talking about the intent to switch to HTTPS for the past years. The reason we didn’t say anything about the specific deadlines or make public the transition until it was in progress was because public statements opened us to possibility of man-in-the-middle attacks. Letting everyone know meant letting bad actors, so to speak, know our plans and timeline. We couldn’t have this debate in public without telling the world what we intended to do, which could have compromised the security and privacy of readers and editors in certain areas. We’d have preferred not having to worry about that, obviously. /Johan (WMF) (talk) 19:33, 16 June 2015 (UTC)
@Johan (WMF): But this discussion and these plans were open and public, where any "bad actors" could surely have followed them. Surely that workboard was missing an item relating to fixing bots that didn't operate on wmflabs.org. I can only do so much to stay tuned to such things, and a proactive heads up, perhaps by email, would have been appreciated. I asked about this last December on the Village Pump, and never got a response. How am I supposed to know about venues such as m:HTTPS, where I might have gotten help last December? Wbm1058 (talk) 16:50, 20 June 2015 (UTC)
An example I've been given is that not knowing our time plan made it much more difficult to e.g. hack DNS and traffic at a border, proxy traffic as HTTPS back to us but make it seem to everyone they're connected to us, as HSTS support in modern browsers will prevent the downgrade and warn about it. I'd have loved to be able to give everyone this would cause trouble for a heads up, and we do understand it has caused more work for people we don't wish to cause any unnecessary work for. We'd definitely have preferred to not found ourselves having to choose between either, as we saw it, putting user security in certain areas at risk or not having proper, open communication.
@Resident Mario: Other people that HTTPS could potentially hurt which we know about (Personally I think this is an acceptable hurt): People who use IE6 on windows XP will not be able to view any page on wikipedia. (IE6 on XP is incompatible with modern best practices for HTTPS). People on very old browsers which don't support SNI (e.g. Android 2.3.7, IE 8 / XP, Java 6u45), will get a certificate error when visiting a sister project (But wikipedia will be fine). Bawolff (talk) 20:02, 13 June 2015 (UTC)
@LFaraone: IE6 doesn't work because it only supports SSLv3, and we require at least TLS1.0 (To prevent downgrade attacks/POODLE). We use both subject alt name, and SNI and wildcard certs. If no SNI is sent you get a certificate for *.wikipedia.org with an alt name of wikipedia.org. Which is great if you're browsing wikipedia. Not so great if your browsing wiktionary.org.Bawolff (talk) 05:45, 14 June 2015 (UTC)
@Bawolff: Browsing wiktionary.org works fine even if the browser doesn't send SNI. If the SNI is absent, the server sends a diffenert certificate whose subject alternative names include domain names of all sister projects. 191.237.1.8 (talk) 06:42, 14 June 2015 (UTC)
Oh, you're absolutely right, users get a uni cert when they don't have SNI. I saw the SNI behaviour of switching certificates and just assumed it would be broken without SNI. My bad. Bawolff (talk) 11:09, 14 June 2015 (UTC)
Yes, but its disabled by default. The type of people who use internet explorer are probably not messing with the TLS settings. When I was running IE6 under wine, enabling TLS1.0 didn't seem to help anything, but that was probably just wine not working great. Bawolff (talk) 04:19, 17 June 2015 (UTC)
To editor Resident Mario: The switch to HTTPS will badly hurt those who chose to change their browser's default list of certification authorities and who, specifically, do not trust GlobalSign (the root authority from which Wikipedia's certificate emanates). At the very least, they will be forced to add security exceptions for all Wikipedia domains, and quite possibly will be locked out of Wikipedia altogether because browsers do not always allow security exceptions on HSTS sites. In effect, the switch means that users are forced to either trust everything that GlobalSign signs if they wish to use Wikipedia, whereas so long as HTTP transport was permitted, one could at least read Wikipedia on HTTP if one does not care about the security of public information on Wikipedia but doesn't want to trust GlobalSign. (I can't explain the problem with GlobalSign because I don't want to risk being sued for libel, but let's say that one might not necessarily wish to trust all, or any, certificate authorities.) So the irony is that this change, which is supposed to protect the "security" of users, actually forces security-conscious users to downgrade theirs, in effect a Trojan horse kind of attack. (In all fairness, Web browsers and HTTPS in general should be blamed for having an absurdly rigid approach to security: one can't restrict a certificate authority to certain domains, or things like that, so I can't say "I trust GlobalSign only for signing certificates in the wikipedia/wikimedia/wiktionary/etc.org domains".) --Gro-Tsen (talk) 21:15, 13 June 2015 (UTC)
For real? Any person who intentionally messes with their root certificate store, should be technically competent enough to make their own trust decisions of Wikimedia certs, by say verifying them in some other way. If you're not, you have no business removing CAs from your trust store. Bawolff (talk) 21:45, 13 June 2015 (UTC)
About 10% of HTTPS websites use GlobalSign, so it is not a Wikipedia-specific issue. One could say the same for any other CA that the WMF may decide to use. Moreover, Bawolff makes a great point that someone technically competent enough to mess with trusted roots would be able to work around this as well. They must know how to do so already, since there are numerous other sites using GlobalSign! If someone really lost faith in the CA system, they should try using Convergence, Perspectives, or Certificate Patrol. Tony Tan·talk03:07, 14 June 2015 (UTC)
To editor Resident Mario: In short: HTTPS everywhere hurts everyone. HTTP was built with network proxy and caching servers to decrease page load times. These are intermediate servers run by your ISP to reduce backbone data requests. Australians will bemost affected since 87 ms away from our Virginia data centers, so they'll have a 200 ms ping. Due the design of HTML, these requests can stack meaning that 200ms could bloat to 2 seconds. Now <100 ms is considered ideal, 1 sec users become frustrated, and at 10 seconds they'll look for something else. (Proponents will weasel around this by saying your browser caches content, which helps if you don't back to the Google search results)
Additionally, anyone who say this'll stop the $53 billion a year NSA is delusional. Methods for the NSA to get the WMF private keys: Court order (ala Lava Soft who shutdown over this), intercepting and backdooring hardware (Cisco routers, Hard drives), to recruiting/bribery of employees. This basically leaves ISP spying on users (Verizon Wireless adds a advertizing tracking ID to all HTTP requests), but considering how willing WMF is to toss aside net neutrality... — Dispenser15:08, 17 June 2015 (UTC)
On that first part: well yes and no. Most browsers now support SPDY and/or HTTP2/0, for which https is a requirement and which will give you a 20-700% speed boost. Especially this last part is probably going to significantly increase the speed for the majority of the users in those areas. Second, that area is served from the San Francisco caching center, so it's slightly closer then Virginia at least, though still so far away, that there is a good point. I do know that WMF is watching the performance impact of this change around the world, and I think they were already considering adding another caching center for Asia/Oceania regardless, so if it really does drop measurably, then that consideration might get higher priority. —TheDJ (talk • contribs) 01:09, 18 June 2015 (UTC)
We send anti-caching headers (Because people edit and then things become outdated). ISP level caching servers that conform to the http spec should not be caching wikipedia pages whatsoever. So HTTPS won't really affect caching efficiency. Well lots of people go on and on about NSA, I really think the threat that this move is more designed to address is someone like China or Russia, altering pages in a Mitm fashion to make articles less NPOV. Bawolff (talk) 02:23, 18 June 2015 (UTC)
This isn't an anti-NSA measure, it's due to security and privacy concerns on a number of different levels, not all of them related to governments. /Johan (WMF) (talk) 13:37, 22 June 2015 (UTC)
And another problem: No browser history!
@Johan (WMF): - In addition to losing the drop-down edit summaries (as mentioned above), I've also lost the browser history for all newly-visited Wikipedia pages. Why the exclamation point?? Because this is absolutely crucial -- in fact, integral -- to my ability to work on Wikipedia. I totally depend on having those page links, which give me quick & easy access to all recently-visited pages.
Johan, you said above, "We want editing Wikipedia to be as simple as possible, no matter which browser people use." (I am using IE 8.) Please tell me there is going to be a technical fix for this problem ASAP. Because if there isn't, there is a very real possibility that I will have to give up editing. I am a long-time (since 2006), very conscientious editor, with nearly 60,000 edits. So I truly hope that does not become necessary. Cgingold (talk) 09:11, 13 June 2015 (UTC)
P.S. - I raised the very same issues a couple of years ago during the last discussion on this subject, which was resolved to my satisfaction when I learned that it was possible to opt out. So this is really a sore point for me. It sure would have been nice if you guys at least had the consideration to place a banner at the top of all pages for a week or two giving all of us a heads up about the impending change. Matter of fact, I believe I made the same point last time! :-( Cgingold (talk) 09:20, 13 June 2015 (UTC)
Yup, this is a problem for me too that is admittedly a considerable annoyance. I always opted out previously for this reason. Connormah (talk) 11:21, 13 June 2015 (UTC)
@Cgingold: If you mean that you lost your browser history for all of the http domains, I would say: deal with it yourself. It's a petty issue. You will regenerate the URLs soon enough as you visit the new pages again; it's no different than if you were to clear your browser history. If you have lost the ability to generate new URLs in your URL history, then that is a problem. I hope it can be fixed, but if it cannot...wouldn't it be easier for you to move up to an Internet browser that's less than six years old? ResMar13:48, 13 June 2015 (UTC)
Even if it was "merely" the loss of older browser history that I was referring to -- which it wasn't -- that would hardly be "petty", my friend. You might want to check your attitude at the door before you trivialize another editor's problem. But of course, I was talking about the fact that my browser no longer generates new URL links in the browser history. And it is indeed a very serious problem. Cgingold (talk) 21:29, 13 June 2015 (UTC)
Petty? The switch to HTTPS is petty. It is stark raving mad to switch to https to avoid NSA surveillance. I cannot believe the reasoning there, some people need to take their tin foil hats off. I bet if anyone were to read this at the NSA then would have a right good laugh at us all. Even if they were inclined to mine data off this site then the switch to https would be of little impediment to a body of that resources. Why do we not only operate on tor and demand VPN usage if we are trying to protect the hypothetical drug smugglers, money launderers and terrorists that apparently have abandoned the onion sites in favour of WP talk pages? There is no benefit for this change in policy and the reasoning behind is deranged.--EchetusXe17:46, 13 June 2015 (UTC)
@Connormah: As a sysop, you should probably use HTTPS. Otherwise, your account is at risk of being hijacked in a Firesheep-style attack, especially when you use a public network. A sysop account would be really useful for someone intending harm. :( If there are big issues, upgrading your browser to a newer version of IE, Chrome, Firefox, etc. should help. Tony Tan·talk03:15, 14 June 2015 (UTC)
Cgingold, I just wanted to say that, yes, we really do care about your problems, we appreciate all the work you're doing, and I will ping you personally as soon as I have good answer or solution. /Johan (WMF) (talk) 12:15, 16 June 2015 (UTC)
It would more likely be http://en.insecurewikipedia.org, but I don't think there would be many fans to maintain such a system.. We will have to see about what kind of case can be made for that, but I think it is unlikely that it will happen. —TheDJ (talk • contribs) 10:25, 13 June 2015 (UTC)
Anyone could setup a proxy to do this (e.g. http://crossorigin.me/https://wiki.riteme.site [maybe that's a bad example, as it doesn't fix the links]. Anyways, point is that it is trivial to set up an independent proxy to an HTTPS site. Allowing edits might be trickier, but not impossible ). Bawolff (talk) 18:28, 13 June 2015 (UTC)
We have had a discussion
Just a note that we have had a discussion at the village pump about this earlier this year (WP:VPR/HTTPS). The discussion was closed as WP:CONEXCEPT due to the highly technical nature of the issue.
From my point of view, this move to HTTPS-by-default is the correct one. Mozilla (Firefox), Chromium (Chrome), the IETF, and W3C TAG are all behind moving websites on the Internet in general to HTTPS and deprecating insecure HTTP.
HTTPS guarantees the authenticity of content sent from Wikipedia servers as it travels through the Internet, prevents tampering (whether it is censorship in another country or your internet service provider injecting ads or adding invasive tracking headers), and curbs mass surveillance (by a gov't or an internet provider) by making it difficult and expensive to monitor articles being read or written by individuals.
Regarding the potential negative effects of switching to HTTPS for older clients/browsers, we should be able to find a workable solution for them fairly quickly. A lot of the issues mentioned are software bugs that can be fixed without going back to HTTP. Google uses HTTPS by default, and there does not seem to be an issue with anyone using Google. Tony Tan·talk20:43, 13 June 2015 (UTC)
Thank you so much, Tony, for pointing out that Google doesn't cause these kinds of problems! Somehow, I hadn't even noticed that -- I guess precisely because it doesn't cause any problems... SHEESH!! If these issues are, in fact, entirely unnecessary, then WHY WERE THEY IGNORED by WMF's tech people when they had been explicitly pointed out on this very page a couple of years ago??? Inexcusable. I am sitting here literally shaking my head in disbelief... Cgingold (talk) 21:48, 13 June 2015 (UTC)
Well, google (the search engine anyways, not counting other sites google runs) does its own auto-complete with javascript based on what it thinks you want to search for. It does not use the built in remember what I typed previously browser feature. You used the word "issues" in the plural. As far as I'm reading, the old version of IE disables auto-complete on HTTPS is the only actual issue reported in this thread that could possibly not affect Google (Or for that matter, is a reasonable complaint imo). Am I mistaken? Edit: I guess you're also complaining about browser history, so that makes 2 issues. All things considered, both are essentially minor inconveniences, both are experienced only by a relatively small number of users, and the autocomplete one has an easy way of mitigating (update your browser). Not exactly what I'd call the end of the world. Bawolff (talk) 04:45, 14 June 2015 (UTC)
Please enable HTTP mode
Hi. I'm from Iran. After WP enabled https as default (and no access to http), we have a lot of problem to access WP due to Internet censorship. Because Iranian government abuses https protocol. It's very slow and pages do not load properly. Time-out error happens frequently. Editing is not easy anymore. Please enable HTTP option for restricted countries again. Wikipedia is a great contribution to humanity. Thanks. --188.158.107.24 (talk) 10:41, 14 June 2015 (UTC)
All people everywhere possess the inalienable right to have access to information of any and every kind. And they should be able to express that right without intervention by any company, organization or government, to include suppression, censorship and secret monitoring. The sole exception would be information that is kept secret for reasons of national security. What I don't understand is why any government would suppress and censor this right by committing abuse of HTTPS and not also commit abuse of HTTP? Is HTTP really that much harder to abuse? to suppress and to censor? Since many of the problems that have erupted since Wikipedia converted to HTTPS-only are shown to be due to users using older versions of software, and perhaps older hardware as well, maybe if you upgraded to recent versions you would find that rather than governments being the problem, usage of non-recent versions of hardware and software is the problem? – Paine16:06, 14 June 2015 (UTC)
They try to block HTTPS and other encrypted traffic because they can't see what you're doing. Cleartext traffic like HTTP can be examined. They want to give people some access to the Internet, because they know it's generally a lost cause to try to block Internet access completely, and trying to do so might spark a revolt, but they want to retain the ability to block some content, and keep tabs on what you're doing. For instance, China's "Great Firewall" selectively blocks access to information on things like the Tienanmen massacre through multiple techniques, including a blacklist of certain sites, and traffic analysis. --108.38.204.15 (talk) 22:33, 14 June 2015 (UTC)
I think I understand what it feels like to be faced with Internet censorship; I spend half my time in China, where the Great Firewall disrupts access to websites that are commonly used in countries like the U.S. It is very, very frustrating. What I do want to point out, however, is that by enabling forced HTTPS encryption, governments like that of Iran will be forced to make the decision to either block all of Wikipedia or none of it, instead of being able to selectively filter by the topic of individual articles. While in the short term users may find access to be unstable or even impossible, the government may eventually be forced to stop interfering with Wikipedia traffic if it decides that access to the "good" information is more important than filtering the "bad" information. So in the long run, it may be better to keep Wikipedia HTTPS only if users eventually end up having access to all of Wikipedia, without censorhip. There is no guarantee, but I think we should at least wait and see. Tony Tan·talk01:50, 15 June 2015 (UTC)
@108.38.204.15: Out of curiosity, do you have a source for information about the great firewall using traffic analysis? Most of the things I read seem to suggest they mostly use deep packet inspection and DNS posioning. And I'd be really interested in reading any publicly available info about how their system works. Bawolff (talk) 02:10, 15 June 2015 (UTC)
I'm suspicious that HTTPS will do nothing to stop spying by the NSA or GCHQ, but has been introduced to make it much harder for whistleblowers to sit in the middle and see who they are spying on. It seems we're stuck with it though, and if you're using ancient browsers such as IE8, you'll just have to upgrade. Akld guy (talk) 06:24, 15 June 2015 (UTC)
That doesn't really make sense to me. What realistic opportunities would a whistleblower ever have to be in the middle of an NSA/GCHQ communication? And even if they were in such a position, the transport security of Wikimedia would be rather irrelevant. To the best of my knowledge, no whistleblower has ever intercepted communications in transit over the internet in order to release for the public interest. Whistleblowers are usually in a trusted position, and legitimately have access to the data which they decide to divulge. Bawolff (talk) 07:47, 15 June 2015 (UTC)
I want to clarify one thing that's turned up a couple of times in the general discussion (and I'm not replying to any specific user here). There have been a number of comments regarding the NSA. We know that the NSA has targeted Wikipedia traffic, and the Wikimedia Foundation doesn't believe Wikipedia readers and editors ought to be targeted, but while this may have been tangentially related to concerns over the NSA, it wasn’t the driving force. There are other governments and private actors to take into account, and, for example, the Firesheep style attacks that Bawolff has mentioned. Rather, it was driven by concern for the privacy and security of editors and readers all over the world, which means there are many different problems to consider. /Johan (WMF) (talk) 08:00, 15 June 2015 (UTC)
I am with Tony Tan on this one. Our concern is not the NSA or GCHQ spying on users (that can be done even inspite of HTTPS), but its governments like Iran, China, and others that (with HTTP) could filter out certain content from Wikipedia without the majority of people noticing. HTTPS forces them to either block *.wikipedia.org entirely, or just let go. They will probably chose the latter, since the former will cause protest sooner or later. Compare, by the way, to what Russia has been doing with the Internet Archive because of their recent HTTPS-by-default policy: they had to block the entire domain. Of course they would love to only filter out LGBT-related topics etc. but it is a good thing they cannot. And this is why we have to make HTTPS the only option. --bender235 (talk) 09:38, 2 July 2015 (UTC)
Just to add my 5c, I do remember using a university Internet network a year ago that completely banned HTTPS (so I could use Wikipedia only in HTTP). I do not know the origin of this block (this should be definitely a setting by university network administrator), and I do not know if that block is still there (I haven't used it since then), but I would like to inform that such networks do exist, and I don't think there is a way to track them — NickK (talk) 09:16, 15 June 2015 (UTC)
Such networks probably exist, but I think it would be up to the network administrators to whitelist Wikipedia's servers if they believe access to Wikipedia is important. They would probably do it after realizing that it is no longer possible to access Wikipedia on plain HTTP. Tony Tan·talk05:26, 16 June 2015 (UTC)
If Iran blocks HTTPS, there's no way Wikipedia/WMF will be changing their minds by blocking access to Wikipedia for Iranians through HTTP, which is probably a desirable outcome for the regime anyways. WMF should set up additional HTTP servers for static access to Wikipedia (no-edit access) then with a disclaimer stating that the content may be modified by third party man-in-the-middle vandalism in big banner statements at the top and bottom of every page. -- 70.51.203.69 (talk) 04:44, 17 June 2015 (UTC)
Yes, it would, however, it would reenable access to populations who are completely blocked form using HTTPS. If the governments in question actively block HTTPS, then we are just falling into their hands by removing access to Wikipedia from their populations, to limit their populations access to information by voluntarily falling into the schemes of their governments to censor the internet by removing access to Wikipedia completely, as they filter out HTTPS. -- 70.51.203.69 (talk) 11:31, 18 June 2015 (UTC)
Never really saw the logic behind moving to https...so it either stops the governments from snooping the accounts of say 10,000 wikipedians (people who browse and randomly edit the wiki) or by moving to https, it blocks 1.2bn-2bn users from COMPLETELY accessing the website..If i was the guy incharge of making the decision, I'll choose the latter. I'd rather have a billion users being able to access this site than help 10,000 users from "hiding" behind closed doors and randomly attacking their government and making this site look bad....sadly, I don't work for the site and I sympathize with those that can no longer access the site..if WMF had actually done their research before doing this, they would realise it was those users who contributed a lot to the website than those 10,000 who use the site for their own personal agendas...alas...the weak shall inherit the wiki..and for the 1000th time, enwikipedians demands supersedes the demands of other language wikis--Stemoc11:53, 18 June 2015 (UTC)
Billion? Do you have a citation for that? Before anyone says China, China is not currently treating https access to Wikipedia any differently then http access. I'm keenly interested in who this actually blocks, so if anyone has actual information about people who are blocked... please say so. Bawolff (talk) 21:39, 18 June 2015 (UTC)
If the governments that currently block HTTPS really intended to completely remove their citizens' access to all of Wikipedia, they would have already done so over HTTP. Precisely because they still see value in some of Wikipedia's content, they chose to filter instead of block. HTTPS removes the filter option, so they will have to either allow or block all traffic to Wikipedia. When they made the decision, Wikipedia was still available over HTTP, so they chose to block HTTPS and filter HTTP, achieving their purpose of allowing access to some information while blocking others.
Now that Wikipedia can only be accessed on HTTPS, they are forced to re-evaluate their decision. They are now forced to decide between blocking all of Wikipedia, or allowing all of it. While all of Wikipedia is blocked as of now (due to their earlier decision based on a situation that has since changed), they may eventually be forced to allow it if they think public access to certain resources is important. This was the case for GitHub. When GitHub switched to HTTPS-only, China eventually decided to allow all GitHub traffic because of its importance to software development, even though there were other information on there that the gov't wanted to censor. It may be a while before HTTPS becomes unblocked; perhaps the governments are waiting for Wikipedia to enable HTTP access again, which would make it unnecessary for them to allow HTTPS and give up filtering. Tony Tan·talk07:34, 21 June 2015 (UTC)
You do not need a website to have a "TOR address" to use Tor to access the website. You can use Tor to access any website that does not block Tor exit node IPs. .onion addresses are used for concealing the location of the web server. Tony Tan·talk20:43, 23 June 2015 (UTC)
Note
Google has been mentioned. While Google defaults to https it can be (easily) persuaded to use http. All the best: RichFarmbrough, 16:54, 7 July 2015 (UTC).
So... I have page ID (i simply have it). Is there some simple way to find out, to which page this ID belongs? Not using API query, SQL quarry... Can't I go to search and do some search like "id:XXXXX", or maybe LUA people can do some work? As I understand, Module:Page can't do that. --Edgars2007 (talk/contribs) 13:40, 3 July 2015 (UTC)
This is easy from Lua: mw.title.new(26096242).prefixedText. It would be easy to set up a module to do this if necessary. Jackmcbarn (talk) 15:21, 3 July 2015 (UTC)
Fwiw... there's already a Special: page search utility that can take a PAGID and give you the associated page (albeit a bit clunky as well as poorly labelled) -- just go to the Redirecting Special Pages section and select Redirect by file, user, page or revision ID. Don't forget to switch the input selector menu value from User ID to Page ID before you send your request.
You can also build a template based on that special page's syntax and the previous id given above like: Special:Redirect/page/26096242 .
Unfortunately, as it stands today, the output is not listed as an optional wikilink for you to follow if need be but automatically takes you to the target article, revision or user in question instead. I'm sure amending the app to display the target as a clickable wikilink rather than automatically opening the target page is the better solution here. Maybe providing a checkbox indicating not to take you to the target as an alternative maybe? -- George Orwell III (talk) 00:15, 4 July 2015 (UTC)
I read WIkipedia on an iPad, and the screen is large enouugh that don't need the awful mobile version. Yet I can't stop my Chrome browser from constantly serving up the mobile version, constantly forcing me to tap the "Request desktop version" button. Is there a way to force Wikipedia to give me the desktop version by default? --Calton | Talk21:21, 5 July 2015 (UTC)
Bookmarking "wiki.riteme.site" (without the .m.) and always starting from there serves as a workround, since once you've requested desktop site once it should remember it as long as you don't give it the chance to go to the mobile site. I completely agree about the shittiness of the mobile site, and whoever thought it should be default should be summarily fired—even on phones, let alone tablets, it's far less friendly than the desktop site. – iridescent21:29, 5 July 2015 (UTC)
@Iridescent: If you have some constructive feedback on what you don't like about the mobile view for reading, then the Reading Department would welcome it. You can give that feedback on the mobile mailing list, mobile-llists.wikimedia.org. That said, I would note that if you phrase your feedback to the list in the extremely combative manner that you did here, people will likely avoid engaging with you. Please keep things as constructive as possible, both on- and off-wiki. --Dan Garry, Wikimedia Foundation (talk) 20:07, 7 July 2015 (UTC)
I've found that bookmarking "wiki.riteme.site" is not sufficient (on Android Chrome) as the server will detect your platform and redirect to the mobile site anyway. However, once the mobile page loads, if you scroll to the bottom and click the "Desktop" link, then the server remembers your choice. I'm not sure if it only lasts until you close the tab or if it lasts as long as your login session, but it expires eventually. Also, there is no equivalent way to switch back to mobile, you have to add the ".m" into the URL to get back. Ivanvector🍁 (talk) 20:12, 7 July 2015 (UTC)
OK... I just thought to look for the thanks in question. There's only one logged as sent to DumbBOT, and it's timed at 07:48, 29 October 2013 (at first, I had assumed that the incident was recent). Might it be that it was possible to thank bots at the time, but the software has since been amended? --Redrose64 (talk) 17:48, 7 July 2015 (UTC)
API calls just starting throwing SSL/HTTPS (?) errors
For context, I run WP:STiki, which scores every en.wp edit in near real-time. In the last couple of hours, this process has hit the fan. In the last several days, I have implemented changes to handle the HTTPS switchover and the new continuation procedure for queries returning long result sets. As of ~15 hours ago, everything was running perfectly smoothly. Now my (Java) API code is throwing errors like this at every API call (but does succeed in browser):
Error: HTTP error at URL: https://wiki.riteme.site/w/api.php?action=query&prop=revisions&revids=670300219&rvtoken=rollback&rvprop=ids|timestamp|user|comment|tags&format=xml
javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
at sun.reflect.GeneratedConstructorAccessor15.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:532)
at sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1458)
at java.security.AccessController.doPrivileged(Native Method)
at sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1452)
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1106)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:254)
[snip some lines]
Caused by: javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate DH keypair
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1697)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1660)
at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1643)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1224)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1201)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:440)
[snip some more]
Clearly something is going on at the SSL handshake between my server and the WMF one. Given my things were working on my end and I have not intervened, this heavily suggests something was changed on the WMF side. Any pointers? I'll note that CBNG also went down parallel to my service, I believe. Thanks, West.andrew.g (talk) 03:57, 7 July 2015 (UTC)
Most frequently used words with 6 or more characters on the English Wikipedia
How can I find someone who knows how to do a statistical analysis on a Wikipedia dump? I would like to have a list of the most frequently used words on Wikipedia that contain 6 or more characters. For more info about why I want such a list please click here. Thanks! The Quixotic Potato (talk) 11:55, 7 July 2015 (UTC)
Oh… and the reason this is theoretically not a sufficient tool for working on typos, is that the statistical nature of each dump is post-correction for certain typos. For example I fixed all (5 or 6) occurrences of "chruches" a few days ago. A current dump would indicate that this is never misspelled thus. All the best: RichFarmbrough, 14:57, 7 July 2015 (UTC).
Content Translation, the new article creation tool is now available as a beta-feature
Tool iconHow to use Content Translation - a short video)
Hello, Content Translation has now been enabled as an opt-in beta feature on the English Wikipedia for logged-in users. To start translating please enable the Beta feature in your preferences. Visit Special:ContentTranslation or go to your contributions page to open the tool. You can follow the instructions in the User Guide on how to get started. You can also find more information in our earlier announcement in The Signpost.
Since this is the first time we have installed the tool on this wiki there are chances that there may be some problems or service disruptions which we are not yet aware of. We will be monitoring the usage to check for any failures or issues, but please do let us know on the Content Translation talk page or through Phabricator if you spot any problems. Thank you. On behalf of the Wikimedia Foundation's Language Engineering Team:--Runa Bhattacharjee (WMF) (talk) 17:06, 7 July 2015 (UTC)
@Runab WMF: Why do we need this? This is the English Wikipedia; pages are written in English. If we want to translate a page to, say, German, we edit the German Wikipedia. --Redrose64 (talk) 17:36, 7 July 2015 (UTC)
@Redrose64:Research shows that even between big Wikipedias such as English and German the overlap is about 51%. That means that half of the German Wikipedia could be translated into English. That does not mean that all those articles are relevant to English Wikipedia, but there are some valid opportunities for translation into English. In this ticket we collected the requests from the community to enable the tool in English Wikipedia.Pginer-WMF (talk) 18:20, 7 July 2015 (UTC)
Images not showing up
If you add an image to a page and then upload the image, the page will fail to display the image (and put the page into Category:Articles with missing files) until the job queue catches up, or until you edit the page. In the last 24 hours, I've had a variant of this problem. I added an image to Rawson, Ohio before it had finished uploading to Commons, so I made a null edit, because that fixes ordinary purging problems. The result? No change. I had to make a dummy edit (while using the wrong terminology) to get things to work, and then self-revert. Meanwhile, I'd added an image to Benton Ridge, Ohio (not hitting Save until the image was visible on Commons), and the same thing occurred: it looked like a nonexistent image, despite a null edit, until I'd made a dummy edit. Ditto at Cass Township, Hancock County, Ohio. Lately I've noticed that articles occasionally don't display changes after an edit (e.g. I'll add a paragraph, save, and the paragraph's not there), but this problem is normally resolved by refreshing and always by a null edit, and anyway this problem shows no changes whatsoever, not all-changes-except-image. Can anyone explain what's going on, why I have to edit a page twice to get the image to appear? I've been adding photos to other articles as well, and none of the others had problems, even though with most images (e.g. the one at Portage Township, Hancock County, Ohio) I saved the edit as soon as the photo was done uploading. Nyttend (talk) 17:59, 7 July 2015 (UTC)
This is different from "Post not showing up immediately". It goes from showing nothing in the infobox image space to showing a nonexistent image, and after the first edit to each page, all of them were in Category:Articles with missing files — besides the category appearing at the bottom of the page, the article names appeared when I went to the category and looked through its contents. Nyttend (talk) 21:15, 7 July 2015 (UTC)
file_get_contents on wmflabs?
Hi, trying to retrieve this page from labs returns false:
Please see User:Howcheng/sandbox and User:Howcheng/sandbox2. We are trying to add captions to the main page images to solve the longstanding complaint of when the images don't go with the top item in ITN and OTD. I've checked this in Vector and Monobook skins on Win 7 and 8 with latest versions of Chrome, Firefox, and IE. I need some people to verify it using a Mac, using iPad (not worried about iPhone/iPod as smaller resolutions will get the mobile version, which does not include ITN and OTD), and from Android tablets with stock browser and Chrome. Additionally, if anyone has suggestions for other image types to test with, feel free to edit as needed. Thanks! —howcheng {chat}20:20, 7 July 2015 (UTC)
Works just fine on Safari for Mac, and on iPads and iPhones (w00t new responsive design mode of Safari 9 for testing exactly this !). Android will be a lot more work to test. There's a lot of rendering differences between all the minor versions of Android. Android 4.4 == Chrome 30.0.0, that I know. —TheDJ (talk • contribs) 20:57, 7 July 2015 (UTC)
That's a whole lot of nesting divs with contradictory classes (floatright vs. floatnone for example) which basically do nothing. There is a lot of fat to trim. But I like the basic approach, though I would like to advocate using a separate class for main page images instead of using the inline-styled thumb classes (which look weird with the 'new image thumb' gadget enabled). -- [[User:Edokter]] {{talk}}21:27, 7 July 2015 (UTC)
Is it possible to change the strings of certain things on the wiki? Like, if I wanted to change, for example, the text of "Talk" to say "Discussion" for me, for some reason. I read somewhere you could change it via the skin .css somehow, but I don't know if that's possible or how you'd do it. If it is, how do I find the, like, string id of a thing I wanna change? Thanks. --Srđan📣09:38, 8 July 2015 (UTC)
@Srdjan m: You can only change text values in CSS by using ugly hacks like these. However, it's quite easy to change text values with JavaScript. Just add the code $('#ca-talk a').text('Discussion'); to your common.js page. The "#ca-talk a" part is the CSS selector for the "Talk" link at the top of every page. The drawback of using JavaScript for this is that it doesn't load straight away, so there will be a split-second when you load the page when it still says "Talk" instead of "Discussion". — Mr. Stradivarius♪ talk ♪10:12, 8 July 2015 (UTC)
Thanks. Btw, would using that hack on css (even though I really didn't get what to do on that page though) actually get rid of the split second delay or would it still be a thing? It's not a huge deal, but it's just a minor drawback that I wanna see if I can eliminate. :P --Srđan📣10:26, 8 July 2015 (UTC)
Revision scoring IEG goes for a second round
Hey folks,
About 6 months ago, we posted here to notify you of an IEG-funded project we've been working on: Revision scoring as a service. Today, I'm posting to ask for your feedback on our plan for a second round of IEG funding. In the first 6 months of our project, we've met our goals. We stood up a production level service for retrieving revision scores. (Test it out right now at this link: http://ores.wmflabs.org/scores/enwiki/?models=reverted|wp10&revids=638307884|642215410) We have 5 languages running (English, French, Portuguese, Turkish and Persian) and two models ('reverted' == probability that the edit will need to be reverted & 'wp10' == WP 1.0 Assessment). We've had a set of tools and bots pick up the service. See ScoredRevisions and Reports bot 3.
In the next 6 months we plan to do some more interesting stuff.
I've been using the 1.0 assessment model for WikiProject Medicine, and I'm pretty satisfied. In particular, it's nice to have something make a list of things tagged as stubs that probably aren't (and vice versa). WhatamIdoing (talk) 16:04, 8 July 2015 (UTC)
when I wanted to see the editing history of Gülnar - I found that the history has lost!
which is completely WRONG! and should not be happened! as if someone made a full article "blah-blah", and someone else made a stub "blah_blah", and then if somebody rename "blah_blah" to "blah-blah" all history of "blah-blah" will be lost! (Idot (talk) 15:35, 7 July 2015 (UTC))
There are three deleted edits at Gülnar. Only one seems relevant, and that's the one where you added additional links to the page. Is that the history you are looking for? I've dropped the text of that page onto your talk page. There is no other history that I can find, but these deleted edits seem consistent with the moves that show up in the history. UltraExactZZSaid~ Did16:21, 7 July 2015 (UTC)
The top of page histories has a link saying "View logs for this page". The link for Gülnar is [12] which includes: "23:30, 6 July 2015 Bkonrad (talk | contribs) deleted page Gülnar(G6: Deleted to make way for move)". Deletions can only be made by administrators like Bkonrad. When a page has been deleted, the page history is only visible to administrators. The software did as requested so there is no technical issue. It's common to delete a page with no necessary content to make way for a move. Bkonrad made a judgment call that the content in the page history was not necessary. It's possible but tricky to keep the old content somewhere when a page is moved to an already used name. As mentioned above, Ultraexactzz has copied the deleted content to your talk page. PrimeHunter (talk) 16:54, 7 July 2015 (UTC)
Yes, but an administrator has to jump through some hoops to avoid deleting the page history when a new page is moved to a used title without the old page being moved elsewhere. And if the two page histories are merged into a single page history then the result can be quite confusing. WP:HISTMERGE may give an idea of the complications involved in history merging. We usually try to avoid it. PrimeHunter (talk) 17:30, 7 July 2015 (UTC)
Within the past four weeks, there appears to have been a software change that has solved many of the problems with nested footnotes - you can now have the main note and subnote in the same list. However, a new problem has appeared in that subnotes using {{refn}} and {{efn}} now fail within an outer note that uses <ref></ref> tags. To see examples, please look at WP:Nesting footnotes#What does not work: cases 2 and 3 displayed correctly a month ago. Can anyone investigate and report as necessary?: Noyster (talk),19:53, 8 July 2015 (UTC)
As far as I remember, cases 2 & 3 never worked - the outer <ref>...</ref> always blocked expansion of certain constructs inside, which included {{#tag:ref|...}} which is what is inside {{efn}}. --Redrose64 (talk) 20:21, 8 July 2015 (UTC)
Looks like a simple typo. As the note on the footnote says, the date is in the URL, and the date was 2005, not 2015. I suspect the date in prose is also a typo, they probably meant 2012 instead of 2015, but that is also an easy error to make since 5 is above 2 on a numeric keypad. Resolute00:21, 9 July 2015 (UTC)
The article has a template, {{RemainingAtGuantanamo}}, that has a 2015 citation. Old copies of articles use current versions of templates that they transclude.
Recently, I've noticed that when someone (myself included, otherwise I may not have noticed this) nominates a page to Articles for Deletion, the system sometimes decides the result of the discussion is keep when either Twinkle or Page curation puts the relevant code on the page, nullifying the link to the discussion (the discussion is still there, it's just not being linked to properly) on the template and the user warning. I keep having to remove the |result=keep to get the links working. Here is an example (note that I didn't nominate this page, so it's not my computer) Have these articles been nominated before? (if so, then the nominations aren't being handled properly) Has anyone else encountered this? Adam9007 (talk) 00:50, 9 July 2015 (UTC)
It doesn't "decide" keep and it doesn't "nullify" any link. The code is in comments <!-- ... --> so it has no effect while it's there. If the decision turns out to be delete then the talk page is also deleted so there will be no delete decision to record there. The code is only needed for non-deletions and keep is the most common result in those cases. In some cases it should be manually changed to something else like "No consensus" when it's copied to the talk page. The link to the AfD page is sometimes red initially when tools are used for the nomination. This is because the tools can edit so quickly that when the nomination template is placed on the article, the MediaWiki software hasn't yet registered that the AfD page has been created. This is fixed by purging the article, or making any edit like you did but that is not necessary. PrimeHunter (talk) 01:33, 9 July 2015 (UTC)
It does seem to have an effect, the same thing just happened to me again here I just put the |result=keep in again and it had no effect, it seems you're right in that I sometimes have to make an edit. It's still annoying though. Adam9007 (talk) 02:22, 9 July 2015 (UTC)
Thank you. As a corollary - if one clicks "give thanks for this edit", then clicks "no" when it asks to give public thanks, does it give private thanks? DuncanHill (talk) 13:27, 9 July 2015 (UTC)
I noticed this was proposed a while back, but I think Wikipedia would greatly benefit from a back to top button. This button could be a round one which could be situated beyond the margin of the text, or if that can't be avoided, within the text if if can fade slightly so that the underlying text is shown. I find this very frustrating when I'm scrolling down long articles and that I have to manually scroll all the way back up to the top if I want to go there. I use an Apple Macbook and an iPhone 5 and this would greatly benefit Wikipedia. Sam.gov (talk) 16:31, 9 July 2015 (UTC)
If you have an article on your watchlist which is under pending changes, say Malala Yousafzai, and you consider that a particular series of revisions (for example these eight) are not acceptable, and decide to revert the whole group of eight by using the Unaccept revision feature, something rather odd happens.
You get a screen which lists the eight revisions, in reverse chronological order with dates and times, which is OK; the list is preceded by a note that uses MediaWiki:Revreview-reject-text-list as a framework. This MediaWiki: message is constructed such that $2 is supposed to be for the name of the page. What is actually fed in through $2 is the revision ID of the second edit in the group being reverted, but with commas to separate the number into groups of three digits. So in the above example, the second edit is that of 05:58, 9 July 2015, whose revision ID is 670635145, and so it shows "... from the following revisions of 670,635,145:" when it should be showing "... from the following revisions of Malala Yousafzai:".
Hmm, I cannot reproduce that problem. If you get an explicit error message, it's welcome (though please remove any personal information such as your IP address). --AKlapper (WMF) (talk) 09:46, 10 July 2015 (UTC)
@AKlapper (WMF): That problem was just gone after I posted that message. The 503 errors were occurring for a minute, then as soon as they stopped, I posted it. You don't have any logs? Gparyani (talk) 18:14, 10 July 2015 (UTC)
It's weird though, there already is a CSS fallback defined, and that should take precedence I think. Might be a FF bug. —TheDJ (talk • contribs) 14:51, 7 July 2015 (UTC)
Rigth, where border attributes do, because the attribute also affects the value of the rules attribute, which does provide borders between the cells. As in HTML4 tables spec. But inline CSS doesn't, so you should just use wikitable. —TheDJ (talk • contribs) 15:17, 7 July 2015 (UTC)
Frankly, please stop using custom CSS for the tables. I see no reason not to use the wikitable class. --Izno (talk) 14:56, 7 July 2015 (UTC)
I think it has to do with them wantint to waste less horizontal whitespace, then wikitable allows them. But yes, as proven right here, such an approach is not maintainable.. —TheDJ (talk • contribs) 15:17, 7 July 2015 (UTC)
They were coded that way because tables that use the "wikitable" class have barely visible outlines on the mobile site. Like in this example:
A a group of wikitables in a rally article on the desktop site
The same tables on the mobile site
@Zwerg Nase: can you please tell me the exact version of FF and operating system that you are using please ? i'd like to keep an eye on this but i've not yet found a version of FF for my Mac with this same problem. —TheDJ (talk • contribs) 15:54, 7 July 2015 (UTC)
"barely visible outlines on the mobile site" -> Then you need to submit a ticket to get the mobile site fixed, not introduce arbitrary styling. Fix the root cause, not the symptom. --Izno (talk) 16:31, 7 July 2015 (UTC)
Izno, I could really use some advice here. I already attempted to have this root cause fixed but was met with fierce opposition. I agree wholeheartedly with your advice to fix the root cause, not the symptoms. However when I tried to I got the exact opposite advice, namely to fix the symptom, not the root cause. Two of the users who replied to my proposal back then have replied to this section as well (Redrose64 and TheDJ). If want to go through this hassle again I want to make sure that I make the extent of the problem clear. As TheDJ knows, I'm on Phabricator as well so would be prepared to go there if that's the best approach. Tvx1 15:24, 9 July 2015 (UTC)
And what are the HTML5 replacements for these obsolete parameters? I know align= should be replaced by style="text-align:" (and I have replaced quite a few of them, although it's an unmanageable task to replace them across the whole 'pedia), but I don't know the others. Tvx1 16:13, 9 July 2015 (UTC)
There aren't any, not in HTML5, anyway. Like most other attributes (and elements) that are concerned purely with visual appearance without any semantic meaning, they're no longer part of HTML, since in virtually all cases CSS can do the same thing, in a uniform way (see this doc, where it lists cellpadding and cellspacing with a whole bunch of others, at the bottom of which it says "Use CSS instead."). You can put CSS inside a HTML style="..." attribute, but that's tedious, error-prone and bloaty. Far better to do it through a class, with the styling set up somewhere like MediaWiki:Common.css. So, what is basically wrong with the existing wikitable class? --Redrose64 (talk) 16:55, 9 July 2015 (UTC)
It's specifically the mobilewikitable class. The table outlines described in that are barely visible, as you can see in the picture above (specifically the one on the right). And for instance if you just compare tables at about just about any article using them. Like for instance this desktop version and its Mobile equivalent. Tvx1 17:50, 9 July 2015 (UTC)
The opposition you met was with the specific solution you proposed, which was to make the tables render precisely the same. There are some problems you noted as what I would personally evaluate as accessibility-related and so should be changed (borders at least, potentially background). My advice is thus that you submit a phab ticket for what might be considered real problems with the mobile skin. --Izno (talk) 16:59, 9 July 2015 (UTC)
In that case I was misunderstood. My main concern was and still is the readability issues of the mobile "wikitables". I just used at the desktop table as the norm because it thought it was preferable to limit the differences between skins, without them being precisely the same. Tvx1 18:12, 9 July 2015 (UTC)
(edit conflict) Izn, which way do you think the accessibility problem works? The dark lines on desktop make it hard for some people (e.g., with dyslexia) to separate letters from borders (and therefore to read the contents), or the faint lines on mobile make it difficult for some other people to keep track of which line they're reading across a wide page? (Maybe we should go back to green bar style.) WhatamIdoing (talk) 18:17, 9 July 2015 (UTC)
I know this question is not direct at me, but the observations I have seen while working in my area of editing all point at the second problem. I don't think the lines on desktop are dark enough to cause problems. They are clearly lighter than the text. Tvx1 19:02, 9 July 2015 (UTC)
@WhatamIdoing: *g* I'm simply pointing out that there's probably a legitimate concern about accessibility of table borders hiding somewhere in there. My inclination as a normal-sighted user (never mind the probably larger audience of visually disabled [not dyslexic] and normal-sighted people), I would expect the larger problem to be faint lines, not dark lines simply by number of people. (To: WaId (WMF):) Has anyone done an analysis on the usability team of either the mobile or desktop viewing, specifically regarding tables? --Izno (talk) 19:16, 9 July 2015 (UTC)
They've done usability testing in general; I don't know if they've specifically done testing regarding tables. I'll ask the Design Research team, and let you know if I find out anything interesting. While we're on the subject, you should all consider signing up for mw:Wikimedia Research/Design Research's studies. Problems identified in their research are systematically reported to the team responsible for the problem. Whatamidoing (WMF) (talk) 20:28, 9 July 2015 (UTC)
I am using Chrome 43.0.2357.61 with iOS 8.3. When I try to edit a page in mobile mode, the "Save" button disappears after I make my edit. Help!!! Grover cleveland (talk) 06:56, 11 July 2015 (UTC)
WGT Baseball:MLB deleted
Hi! I noticed that the article I originated, WGT Baseball:MLB, was deleted without as far as I know, even a VFD or Speedy Deletion tag. I saw on the deleted link it was taken off by a bot. I was wondering what happened and maybe someone can re-post it? I mean if this is a case of just a bot randomly deleting an article then that could be a problem in the future for other articles....Antonio Wonder Why Martin (dime aca) 04:09, July 10, 2015 (UTC)
5 June 2015: Anarchyte nominated "WGT Baseball: MLB" for deletion via WP:PROD, with the reason "The only references that aren't primary are press releases. May not be notable".
12 June 2015: User:Ged UK deleted "WGT Baseball: MLB", repeating Anarchyte's PROD rationale. This broke the redirect at "WGT Baseball:MLB", as it was then pointing to a non-existent page.
13 June 2015: User:AnomieBOT III automatically deleted the broken redirect.
The bot is functioning as it is supposed to: it looks like you are just being confused by the page move. If you would like the page restored or moved to your userspace, the best thing to do is ask Ged UK for advice, as they deleted the article. Best — Mr. Stradivarius♪ talk ♪05:28, 10 July 2015 (UTC)
When replying to people on talk pages (which can sometimes take more than just a couple of minutes), I'm increasingly often getting an apology for not processing my save because of a 'loss of session data'. Trying to save again (with my edit clearly there in the edit window) does no good. I have to copy my edit, go back to the previous version, open up and paste. This isn't due to anyone else editing the page and causing a conflict. It's starting to get irritating. Is something going on (or going wrong)? Peridon (talk) 20:25, 11 July 2015 (UTC)
How long does it take for you to type out your posts? When I do spend some time collecting sources and text before saving, it does make that same error for me. Jo-Jo Eumerus (talk, contributions) 20:32, 11 July 2015 (UTC)
I tend to make fairly detailed posts, but I always have. I've even left the edit window open while I've dealt with phone calls and so on before. Now, it's coming up every day, or so it seems. Before, once a year or so. Peridon (talk) 20:42, 11 July 2015 (UTC)
Happened to me yesterday, once. Edit time <20 mins, Win7, IE11. I simply resubmitted by clicking "Save page" again and was successful. Akld guy (talk) 05:22, 12 July 2015 (UTC)
I'm on XP Pro, FF20 and Monobook. That doesn't work for me - I've tried Save six times or more on one edit. Peridon (talk) 11:40, 12 July 2015 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I have tried to upload an album cover twice, and both times I received an error stating "invalid token". Anyone know what that means? Erpertblah, blah, blah...03:51, 12 July 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
New contribution?
ContentTranslation popout menu. This appears when you hover over the "Contributions" link in the top right.ContentTranslation "new contribution" menu. This appears at the top of Special:Contributions.
Per the announcement above, appending ?action=info to the URL for this page now includes the second line:
Number of page watchers 2,837
Number of page watchers visiting recent edits 647
What does the second line mean? Why not "with recent edits"? The gerrit description is general and I'm wondering what values apply here. The description mentions a right to view the info, but when I tried from an IP (not logged in), the same info was displayed—does everyone have the right? Johnuniq (talk) 02:32, 10 July 2015 (UTC)
The code is a bit more specific: if I've read it correctly, it refers to the number of watchers that visited the page since about 26 weeks before the latest edit. — Mr. Stradivarius♪ talk ♪02:48, 10 July 2015 (UTC)
Thanks all, but does that mean there is a table showing who visited a page (in the last 26 weeks)? How else could it count the number of unique editors who view a page? The last proposal I recall to monitor which pages an editor visits was rejected on the basis of privacy concerns. Johnuniq (talk) 05:02, 10 July 2015 (UTC)
Well, it's not just "visited" a page, it's (a) has it on their watchlist AND (b) visited the page. I'm finding this uncomfortable - if for no other reason than that I thought this level of user-specific information was not kept in the database for longer than 3 months. Risker (talk) 05:34, 10 July 2015 (UTC)
To be exact, it is (a) has it on their watchlist, (b) visited the page and (c) the page has not changed since then. What can be derived, then, is whether or not the latest revision has been visited by the user. That is not to say it does not have privacy implications.--Anders Feder (talk) 06:14, 10 July 2015 (UTC)
I'm not sure about (c), or the number of active users would bounce around wildly after every edit to a page, from 0 immediately afterward to (potentially) hundreds or thousands of watchers who look at the page before it gets changed again. On articles that are (a) heavily watched and (b) being edited at a high rate of multiple edits per hour, the effect would be to keep resetting the active user number to 0 every time someone edited, whether or not there are dozens of editors who have the article on their watchlist and are viewing the page at that precise moment. Jimbo's talk page, the ANI and AN noticeboards, current events like election days, World Cup, major tragedies....would all have low "active watchers" because they're constantly edited. Meanwhile, it seems the data retention guidelines specifically mentions retention of page-browsing data, and says it would be a maximum of 90 days. This is where the disconnect is. Risker (talk) 16:09, 10 July 2015 (UTC)
just one small comment/correction: the "26 weeks" referred above is actually a configuration settings (i.e., a value in LocalSettings.php), so it might be 26 weeks, or it might be something else for each individual wiki. the way i understand it, it means "any watcher who visited the page since last page edit, or no more than X time ago" (for active pages, only the 2nd part is meaningful, for stale ones, the 1st part may trump it). as to the "privacy" concerns: this is the same datum that allows the system to track whether you read a watched page since its last edit. i do not think the "privacy" is a legitimate concern: after all, the list of page you are watching is much more revealing than the timestamp of the last time you visited any specific one of them, so by "agreeing" to maintain a watchlist, you practically give up this piece of privacy.
i do not know it for a fact, but it's my understanding that those parts of the database (watchlists etc.) are censored out of the publicly accessible copies. peace - קיפודנחש (aka kipod) (talk) 22:07, 10 July 2015 (UTC)
I think perhaps you've missed my point. When the data retention guidelines say that this information would be kept for no more than 90 days, one would expect it was kept no more than 90 days. It's quite possible that the right hand didn't recognize that the left hand had written this rule, although that guideline was created with the active participation of WMF developers who ought to know what is and is not available. Risker (talk) 22:29, 10 July 2015 (UTC)
i am not sure what "this information" you refer to is. my understanding is that your watchlist falls into the "Account settings" bracket, so the retention rule is "Until user deletes/changes the account setting." as far as i know, your actual browsing history is not kept at all - here we are talking about your watchlist. the fact that this "watchlist" contains a timestamp does not change that (as far as i understand, this timestamp does not represent your last visit to the page - it represent the timestamp of the oldest edit of the page you _did not_ read once you read the page, the timestamp disappears - it will be added again when someone edits the page, and will be cleared when you'll read it again, and so on. i may be wrong here). this may look like hair-splitting to some, but in my view it's simply a part of the watchlist, and nobody expects their watchlist to begin evaporating after 90 days. peace - קיפודנחש (aka kipod) (talk) 23:06, 10 July 2015 (UTC)
After a quick scan of the code linked above and mw:Manual:Watchlist table, I think the situation is as kipod describes—there is no privacy problem. A feature of watchists is that a user preference allows an email to be sent to the user if a page on their watchlist changes. That is governed (apparently—I know very little about MediaWiki) by the wl_notificationtimestamp field in the watchlist table. If an editor views a page on their watchlist, that timestamp is cleared. If someone else changes the page later, the timestamp is set to the time/date of that edit, and setting the timestamp will also send a notification email if enabled in preferences. The new "Number of page watchers visiting recent edits" is calculated by counting the number of people watching that page with a timestamp for the page less than 26 weeks old, or with a cleared timestamp. That counts all people who watch the page and who have viewed it either after the last edit, or less than 26 weeks before the last edit. The timestamp retains a tiny piece of information about the editor, but the database has to remember that the editor is watching the page, and the timestamp provides very little extra information. Johnuniq (talk) 03:42, 11 July 2015 (UTC)
This is a brand new parameter added specifically for this extension/function; given it's less than a month old, it's no surprise that it hasn't changed. Risker (talk) 21:25, 11 July 2015 (UTC)
As one of the people who has been requesting something like this for a long time, I'm happy. If you want to know why this matters, then please take a look at the inactive vs active watchers on this very old WikiProject. It has almost two thousand watchers! But 99% of them haven't edited in a long time, and only eight (8) of them have actually looked at the page during the last 180 days.
Risker, there is no universal 90-day timer. If there were, then the watchlist feature wouldn't work for any page that you haven't visited within 90 days. On day 89, it would be saying that you haven't looked at Boring since it was last edited, and on day 91, it would be saying that you had, just because it was more than 90 days ago and it "forgot". WhatamIdoing (talk) 03:28, 13 July 2015 (UTC)
You used code of form {{subst:afd2 | pg=PageName | cat=Category | text=Why the page should be deleted}} ~~~~ with a second subst in the text parameter, but only the outer subst:afd2 is performed on the first save. It's a bit complicated but see Help:Substitution if you are curious. PrimeHunter (talk) 11:35, 12 July 2015 (UTC)
@PrimeHunter: I wasn't aware that I was substituting into another substitution, as I used Twinkle to create the page. I was expecting it to substitute as I could only see one subst: (Twinkle was hiding the outer one). Perhaps I can get this "bug" fixed by asking the Twinkle developers to have the AfD module expand template substitutions before calling the API to save the edit. Gparyani (talk) 16:45, 12 July 2015 (UTC)
You want something that can intersect but already have something to intersect with? I'm confused. I know that Wikipedia:CatScan does intersection also. I think autolist can also do it but I haven't played at all with it. --Izno (talk) 19:53, 12 July 2015 (UTC)
Every time I open a template edit page, first the page loads and then, after a short time delay, the following pops in at the top of the page:
Manage TemplateData Information about TemplateData
Both are links and when they pop in, they push the rest of the page down several lines. I wonder if this drives anybody else nuts, too? There I am doing redirects in a sort of "fast edit mode", and each time I load an edit page I must adjust my "readiness" several lines downward. I wonder if there is a bug in phab that is set to fix this and make the above TemplateData links load the same time the rest of the page loads? Why is there a time delay? – Paine16:40, 12 July 2015 (UTC) PS I've looked in Prefs and there doesn't appear to be any box to check or uncheck to manage this. PS added by – Paine16:43, 12 July 2015 (UTC)
There's a delay because TemplateData is JavaScript, basically. The quick and dirty fix would be to reserve some space for TemplateData in your stylesheet, e.g. by adding a top margin to .mw-editnotice-10 and position: absolute to .tdg-editscreen-main. Alakzi (talk) 16:48, 12 July 2015 (UTC)
I have a page set up, User:Resident Mario/godate, whose content is taken in via a script. The substance of the page is merely:
BOF
{{#time:Y-m-d|Sunday - 14 days}}
EOF
I am retrieving this information via pywikibot, but I get back a 21 June 2015, even though the current archive is on 28 June 2015. I think it's a caching issue: hard-purging the page in my web browser causes it to now correctly give me the June 28 2015 date (specifically, 2015-06-28). Is there a quick workaround? ResMar19:17, 12 July 2015 (UTC)
You don't need to use pagegenerator or any of the factory classes since we're only working with the one page. Alakzi (talk) 20:51, 12 July 2015 (UTC)
That is correct. When you have your page instance you can just call purge(). No need to call the touch script. Actually if you look in that script it'll show you how it purges pages. — xZise [disc] 21:15, 12 July 2015 (UTC)
XZise, Alakzi: Thanks. I'm thinking I'll have to rewrite the method to use pywikibot request infrastructure and implementing this instead of using requests directly: see this bug that I left on stackoverflow. Any idea what's going on there? ResMar14:45, 13 July 2015 (UTC)
Not sure - probably something to do with how Varnish is configured. You can retrieve the generated text with expand_text in pywikibot. Alakzi (talk) 15:04, 13 July 2015 (UTC)
Redirects and includeonly
What happens if a template page containing an instance of <includeonly>#REDIRECT [[Target]]</includeonly> is transcluded or substituted? GeoffreyT2000 (talk) 02:19, 13 July 2015 (UTC)
Transclusion inserts the text "REDIRECT [[Target]]", but only when the page is rendered. Substitution inserts the text "#REDIRECT [[Target]]", which creates a redirect if it's the first thing in the article. --Unready (talk) 09:10, 13 July 2015 (UTC)
Apparent glitch in mobile browser
While recently viewing the 2015 Formula One season article, I noticed two uses of the {{refn|group=N}} template. This seems to have caused a glitch where clicking on one of the footnotes doesn't do anything. It's a lot like having two subsections with the same name on one article. The problem doesn't exist when using any other format. Prisonermonkeys (talk) 09:25, 13 July 2015 (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.
There was a problem with editing on Thursday. Some tools like bots and VisualEditor were broken on all wikis for 10 minutes. [14]
There was a problem with images on Thursday. They were broken on all wikis for 15 minutes. [15]
Changes this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from July 14. It will be on non-Wikipedia wikis from July 15. It will be on all Wikipedias from July 16 (calendar).
Meetings
You can join a technical meeting at Wikimania in Mexico City this week. [16]
OK, so we've had some discussions about Administrative Actions. This comes up now and again, sometimes in the context of Arbitration Enforcement, sometimes in the context of administrator inactivity (Do edits count, or just actual, official administrator actions like deleting pages or blocking?), and other times in the context of closing discussions and requests (like declining unblock requests, for example). The trick is that the system, at present, only logs administrator actions that require the tools - protecting and unprotecting pages, blocking or unblocking editors, deleting or undeleting edits or pages, etc. So, sometimes it is confusing to tell whether an editor who has the administrator tools is actually acting in their official capacity as an admin, or just chiming in as an editor. Different answers to that question can carry different weight - taking an admin action does not make an editor involved in the discussion, but commenting as an editor might. And whether the editor is involved or not can be relevant, especially in a hot dispute.
So I had an idea. We can flag our edits as "minor" if we wish, simply by ticking a box in the edit dialogue. Would it be possible to add a similar flag for Administrative Actions? Obviously, we would need rules to govern its use, just as we have policies in place that require proper use of the "minor edit" flag (and can result in blocks for repeated misuse). But if used properly, an "Admin" flag might give administrators a way to clarify when they are "on duty" and acting in their official capacity.
Two questions, then - 1) Is this a technically workable idea? It would seem so, but I don't know how simple it would be to implement. 2) Is this something the community would have an interest in, either as a short-term trial or a long-term experiment? Thoughts? UltraExactZZSaid~ Did13:35, 8 July 2015 (UTC)
My concern here is that admins are not moderators de jure, merely de facto; nor do admins have editorial precedence over other users. Implying that edits can be "admin actions" seems contradictory to those principles. {{Nihiltres|talk|edits}}16:24, 8 July 2015 (UTC)
This sounds like a good idea on paper, but the thing is that it's not really up to the choice of the admin to decide whether something is an "admin action" or not. The very nature of the edit is what determines that. So I can't really see that something like this would be worth it; if we take the label at face value, it's extremely prone to abuse, and if we don't, then I don't really see it providing any real benefit. Writ Keeper⚇♔16:38, 8 July 2015 (UTC)
This edit was an admin action; this edit 99 minutes later was not, although it was to the same page. Why do I describe them so, when only the second involved the {{pp-vandalism}} template? Because when I made the first edit, the article was under full protection; by the time that I made the second one, the prot had been reduced to semi, so any confirmed user could have done the same. These two edits are recorded similarly in my contribs and the page history; to know that the first one was when the page was full-prot, and therefore an admin action, you need to look at the prot log for the page as well. --Redrose64 (talk) 16:57, 8 July 2015 (UTC)
Sure, I understand that, and I see how there could be value there; like I say, it sounds good on paper. But I'm worried about the implications. A hypothetical admin in an edit war could label all their reversions as admin actions in an attempt to immunize themselves from 3RR, and even from INVOLVED when they finally block the other hypothetical participant--after all, they've only been involved with that user in an administrative capacity, just look at those edits all labeled "admin"! That'd be a misuse of the function, of course, but it provides that much more "justification" to abuse of admin tools, and it'd be indelible. As you point out, Redrose, it's difficult to tell whether an edit is an admin action or not without context, but that swings both ways; it also makes it hard to *verify* an applied "admin action" label, and the consequences of an edit falsely labeled as an admin action are likely more severe than the consequences of an unlabeled admin action. I suppose my initial reply was a false dichotomy, but I still think that this would ultimately be more trouble than it's worth. YMMV Writ Keeper⚇♔17:19, 8 July 2015 (UTC)
True - and nothing whatsoever stops me from making an edit with the summary "Minor edit - grammar and punctuation". The software just lets me identify it as such with an additional piece of data attached to that edit. This would be similar. UltraExactZZSaid~ Did20:31, 8 July 2015 (UTC)
Are interwiki transclusions possible? I appreciate that they would be generally frowned upon, but had the idea of having the same user page across my wikimedia accounts with the syntax {{w:User:Name/UserSubPage}}. U+003F?22:36, 11 July 2015 (UTC)
There are three more that work: your userpage, global.js, and global.css pages at Meta. If you want the same userpage across Wikimedia accounts, then create that page at m:User:U+003F, and it will happen automagically. Whatamidoing (WMF) (talk) 03:32, 13 July 2015 (UTC)
No, interwiki transclusions are not possible. The 3 examples above (global.css, global.js and Files from Commons) aren't even transclusion :p ^demon[omg plz]01:35, 14 July 2015 (UTC)
The minor edit checkbox has been disabled on creations of new pages. Since when did this happen? However, Keegan has some edits with edit summary {{checkuserblock}} that are marked as both creations and minor. GeoffreyT2000 (talk) 02:49, 13 July 2015 (UTC)
I have no idea. The CheckUser block form does not offer the selection of marking an edit as minor or not. Keegan (talk) 04:50, 13 July 2015 (UTC)
I've just tried to use the API to force a couple of page creations to be marked as minor edits, but they weren't marked as minor in either case. So that rules out the hypothesis that all page creations from API calls using action=edit and minor= result in the edit being marked as minor. @GeoffreyT2000: It would help if we could see the actual edits in question - could you link to them? — Mr. Stradivarius♪ talk ♪05:29, 13 July 2015 (UTC)
So it's in how the CheckUser form processes the option to mark user/usertalk pages. Extension:CheckUser likely needs to be updated. Keegan (talk) 05:37, 13 July 2015 (UTC)
Hi there. I added this talk page comment to the Chevrolet Suburban article. My comment will invite editors to this draft article. My concern is that the draft article is almost identical to the real article, and I'm afraid some search engine may mistakenly pick up the draft article. I don't want someone to Google "Chevrolet Suburban" and end up at the draft article. Is there some meta-tag that could be added to the draft article to prevent this from happening? Thanks! Magnolia677 (talk) 11:00, 14 July 2015 (UTC)
To me in Firefox it appears top-down, rotated 90 degrees clockwise from normal left-to-right writing. This is intentional. Do you mean it rotates 180 degress for you? In which browser? PrimeHunter (talk) 02:56, 12 July 2015 (UTC)
Verified - same flipping of the text when PC toolbar is minimized under IE 11. Never mind using a paragraph tag <p> to hold the text Curation is a bad idea to begin with since it has top & bottom margin lengths defined by default (which in essence become margin left & right when rotated btw), p#mwe-pt-toolbar-vertical has a [ms-]transform setting to rotate 90 degrees (so + 90 degrees) in addition to an inline style for writing-mode set to tb-rl ( + another 90 degrees = 180 degrees hence the complete flip as in the screenshot). Apparently, that additional inline setting was meant specifically for IE 8 and lower when detected but they're not using the corresponding ms- prefixed attribute for writing-mode at the same time for IE8 (or IE9) so I don't know what is going on there exactly.
Personally, I'd stop using the inline styling of writing-mode set to tb-rl altogether, let [ms-]transform rotate the text-block per its 90 degrees setting and switch the current use of a paragraph element to a block level span or div instead to accomplish this. Of course, YMMV. Obviously, something is crossed with the IE version detection and/or the appropriate attribute to use in each instance. -- George Orwell III (talk) 09:18, 12 July 2015 (UTC)George Orwell III (talk) 14:16, 12 July 2015 (UTC)
@Izno: Enabling the preference does nothing on wide screens, but keeps the box wide on smaller screens (i.e. the size adjustment doesn't kick in when the preference is enabled). Gparyani (talk) 17:19, 14 July 2015 (UTC)
So turn the preference off. :D (I noted the presence of the preference at the MT:Vector.css.) --Izno (talk) 17:28, 14 July 2015 (UTC)
"So turn the preference off" – what do you mean? For us, it was never activated (and still isn't). The gadget needs to be removed now that the box is already bigger, and I would like to know how to return it to its previous size. Jared Preston (talk) 18:11, 14 July 2015 (UTC)
Yes, i have suggested a change that by default gives more space for the search field if you have a wide screen, and automatically takes up significantly less width on very narrow screens. I think it is an interesting experiment and I'm wondering how people will receive it. I suspect it might make it easier to find the search for most anonymous users, and i know for sure that it will improve the experience for people with narrow screens. My suggestion it that we evaluate after a month or so ? —TheDJ (talk • contribs) 19:22, 14 July 2015 (UTC)
The gadget you mean ? Let's see after the month. If you remove or disable gadgets, it's really disruptive and it makes rolling back difficult. —TheDJ (talk • contribs) 20:01, 14 July 2015 (UTC)
I agree that !important isn't required. User css loads after global/site css, and last one to load wins. It would be required to override inline HTML styles, which this isn't. FWIW, I think the old size was 12.6em, but that's just a nit. --Unready (talk) 23:06, 14 July 2015 (UTC)
How to properly hide/show rows in table for a template?
I'm currently creating a template to replace the results tables being used at esports competition pages such as Evolution Championship Series and Apex (tournament series). The intention of the table is that it can show anywhere from 4 to 16 rows of data, but I can't get it to show anything past the first rows, with any data beyond the 5th row being shown as raw data above the intended table.
Yeah, it's usually easier to develop templated tables with full HTML template markup, and then try to convert it to wikicode, in a sandbox, step-by-step (or not bother with the conversion). Wikicode's operator-overloading of the "|" character, its only-partial insensitivity to whitespace, and its nitpicky requirements for certain things (including template coding bits like |+, !, etc.) to be at the beginnings of lines, can make this a slow and frustrating process. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:54, 15 July 2015 (UTC)
Template rename server effect
In order to make a template name more concise and consistent with its sister template, {{R from diacritics}}, I have proposed that template {{R from title without diacritics}} be renamed to {{R to diacritics}}. An administrator, Diannaa, has raised the issue that template R from title without diacritics has more than 388,000 transclusions and that such a page move might have an adverse effect on our server load. Diannaa suggested that I raise this issue here to discuss this and find out more about the effects on the servers. So the question would be, will it be okay to move template R from title without diacritics to (presently one of its aliases) template R to diacritics? – Paine22:15, 12 July 2015 (UTC)
It will not have an adverse effect. It might take a long time before all the uses are updated. Most important with such templates is that you shouldn't edit them too often, because each time you are dumping 388000 articles into a queue, which isn't something to do willy nilly. But overall the redirect or the change shouldn't matter too much. —TheDJ (talk • contribs) 11:25, 13 July 2015 (UTC)
That's good, and thank you, TheDJ! The main page to be moved was last edited on 19 June, and the redirect, which has been transcluded only about 440 times, was last edited about 18.5 hours ago. Should we wait a bit longer? Please forgive my ignorance of the timing range within which it is best to wait. Is there a guide on MW somewhere? Seems something this important should have a policy, don't you think? – Paine15:16, 13 July 2015 (UTC)
@Paine Ellsworth:, that's just fine. Doing it 2 times in a single day would be suboptimal, doing it 10 times in a week also not really helpful, and edit warring would be really bad, other than that you are good. There is not really a guide, but as soon as you pass like 100000 transclusions you should simply prepare properly and make sure that you get it right in one edit, if at all possible. The site won't explode if you make multiple edits, not even with a 1.2 million transclusions, but it will introduce a large delay for all the other background updates, which editors sometimes find annoying. —TheDJ (talk • contribs)
Yes, thank you – I could find no policy nor guideline on MW except that they have two places in the Terms that allude to not being disruptive toward the servers, but no details. Quite possibly they would rather not put bad ideas in people's minds, for while the vast majority wouldn't dream of being disruptive, MW does seem to have its fair share of disgruntled ex-editors from the past who would just love to be able to edit a high-risk template or two. Anyway, thanks again and Best of Everything to You and Yours! – Paine15:49, 13 July 2015 (UTC)
Thanks for that explanation, TheDJ. I think this accounts for odd delays I've sometimes experienced, with changes not showing up until after waiting a while and doing a purge. It happens much less today than it did only a few years ago, I supposed due to a combination of people being more careful and (probably more so) a more robust back-end, what with all of WMF's funding. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:50, 15 July 2015 (UTC)
Phabricator bug: Registering a Phabricator account with an incorrect email address
If you have an account that has never used the Phabricator, and you go to phabricator.wikimedia.org, click the "Login or Register MediaWiki"-button and use an incorrect email address (I used idonothaveanemailadress@idonothaveanemailadress.sorry) then you are:
-unable to change your email address to a correct email address (you cannot access the email settings)
-unable to log in
I know that this is the wrong place to report this problem, but I cannot file a bugreport on the Phabricator... :-D
Can someone fix this bug and delete my email address so that I can chose another one?
I don't really see a bug here but I can imagine that it's surprising behavior, indeed. Not sure if any clarification is needed in the Phabricator Help? In general, feel free to bring such topics and this specific case up on mw:Talk:Phabricator/Help - for example, I have no idea yet about the Phabricator username to reset. :) Thanks! --AKlapper (WMF) (talk) 11:29, 9 July 2015 (UTC)
@AKlapper (WMF): It is my username: "The Quixotic Potato". We do not need clarification in the Help, we need to change the acount registering procedure so that you can change your email address if you've entered a wrong email address. The Quixotic Potato (talk) 11:45, 9 July 2015 (UTC)
@AKlapper (WMF): You must be aware that that is not a solution to this problem. There are more than a hundred open bugs there, and some of the bugs that are open have been open for a very very long time (2014). You assigned the bug to no one, and you set the priority to low. Running that command is not enough, the acount registering procedure should be changed so that you can change your email address if you've entered a wrong email address. Is SCFC using the email address tim<at>tim-landscheidt.de? mw:User:MModell_(WMF) says he uses mmodell<at>wikimedia.org. Are you going to email them or should I do it? The Quixotic Potato (talk) 10:39, 14 July 2015 (UTC)
I know it’s frustrating to not be able to login. Filing the bug is only the first step in the process. The status is meant to indicate actual reality: at the moment, there really is nobody working on it (or about to start working on it very soon). Therefore, no one is "assigned to" work on it (right now), even if the team already knows who is most likely to fix the bug in the end. That will change when someone is preparing to start work on it. (They do this so that other volunteers will know that this one isn't being actively worked on yet, and that therefore they can jump in and do it themselves without fear of wasting their time.)
The traditional priority labels are a bit misleading for some teams. For this team, "high", "medium", and "low" mean something closer to "current work", "next up", and "later". "Later" could be as soon as a couple of weeks from now. What this setting means is only a statement of reality: at the moment, and compared to the other problems in the list, this is – purely from a practical, realistic standpoint – probably not going to be one of the next bugs to get fixed by the team (although anyone outside the team is welcome to do so at any time). Whatamidoing (WMF) (talk) 16:20, 14 July 2015 (UTC)
Thank you, I have spent over 7 years of my life working with various bug tracking systems (e.g. Trac) so I know how they work, which is why I wrote what I wrote. If I didn't understand how bug tracking systems work then I would probably be happy with AKlapper's reply. The Quixotic Potato (talk) 18:58, 14 July 2015 (UTC) p.s. phab:T105352 is not something someone "outside the team" can work on. Its not even something that requires any work. Someone needs to run a single command (phabricator/ $ ./bin/remove destroy @The_Quixotic_Potato). Only a very small group of people have the ability to run that command. If AKlapper would've wanted to help me he would've contacted one of them (e.g. via talkpage/email/IRC) instead of creating phab:T105352. I am not the only one with this problem, see phab:T99455.
I'm sorry this takes longer. I personally cannot fix this because I don't have sufficient permissions, and as can be seen in phab:T105352 Mukunda is subscribed to that task (and is one person who could fix this), hence he received a notification. So I did contact one of them. --AKlapper (WMF) (talk) 19:55, 15 July 2015 (UTC)
One issue is that a University journal included a reprint of a 1929 magazine article, thus I have a citation within a citation and I cannot figure out how to make it work. Technically, I think the proper rendition should be something like Lee, Muna. "The Inter-American Commission of Women", Pan-American Magazine (1929) contained in Cohen, Jonathan (ed). "A Pan-American Life: Selected Poetry and Prose of Muna Lee" Madison: Wisconsin, University of Wisconsin Press (2004). Can someone tell me how to put this properly in the citation template?
2nd issue is that for another reference my PDF file has a [] in it, which Wiki is seeing as code, rather than as part of the url. The PDF file name is http://www.oas.org/en/CIM/docs/PIA[EN].pdf which results in a "file not found" error if you attempt to access the link. Any suggestions?
The usual solution I see to the first problem is just using two citations and manually connecting them, i.e. <ref>{{cite magazine |…}} [Verb]ed in {{cite book |…}}</ref>. {{Nihiltres|talk|edits}}17:43, 13 July 2015 (UTC)
@Nihiltres: Thanks. I am pretty "technically" illiterate. If I cite two sources as you indicate in the text portion, why would not that be rendered as two separate citations in the "reflink" References section? I must be missing something, but since there is not anything physically "in" the References section, there is no way to type anything there. I'll try it and see what happens, as I see that your <ref> beginning and ending brackets are around the whole. SusunW (talk) 17:55, 13 July 2015 (UTC)
This would be only one entry in the references list but would render as "two citations". See below for what is probably the better solution. --Izno (talk) 18:06, 13 July 2015 (UTC)
That the article is a reprint in the new journal is more-or-less irrelevant to the citation since the only article that you looked at was in the context of the (more-)recent journal. I would use {{cite journal}}:
{{cite journal |last=Lee |first=Muna |orig-year=Reprinted from 1929 |date=2004 |title=The Inter-American Commission of Women |editor-last=Cohen |editor-first=Jonathan |journal=A Pan-American Life: Selected Poetry and Prose of Muna Lee |publisher=University of Wisconsin Press |location=[[Madison, Wisconsin]]}}
Lee, Muna (2004) [Reprinted from 1929]. Cohen, Jonathan (ed.). "The Inter-American Commission of Women". A Pan-American Life: Selected Poetry and Prose of Muna Lee. Madison, Wisconsin: University of Wisconsin Press.
@Izno: Its the other way around. The only part of the article I used was Muna Lee's 1929 text. I have no idea what else is in the 2004 volume and it is irrelevant to my article.SusunW (talk) 18:10, 13 July 2015 (UTC)
That doesn't make sense. Are you suggesting you have the 1929 text or the 2004 text? Only cite whichever you have access to. --Izno (talk) 18:12, 13 July 2015 (UTC)
@Izno: Actually it makes perfect sense. Someone put only the section of Cohens' piece that contained the Muna Lee article into a pdf format. It is quite clear that it was written in 1928 and published in 1929 from her description of events. However, since I do not have access to the actual Lee article, and have no idea how I would obtain it, the proper citation is indeed to give Cohen credit for the piece and a double citation is necessary, because the pdf shows that it is copyrighted in 2004 as part of Cohen's work. SusunW (talk) 18:29, 13 July 2015 (UTC)
If you have the book or magazine in your hand then that is what you should cite. If you are citing the pdf, then that is what you should cite. The pdf is clearly a transcription so it is not the magazine article nor is it the book. WP:SAYWHEREYOUGOTIT. Use {{cite web}}:
{{cite web |last1=Lee |first1=Muna |title=The Inter-American Commission of Women: A New International Venture |url=http://www.uhmc.sunysb.edu/surgery/IACW.pdf |website=Stoneybrook School of Medicine |accessdate=13 July 2015}}
@Trappist the monk: Thank you. Are you saying that if I am reading a book on-line I am to cite it as a web citation and not a book? That makes no sense to me, no place to put an ISBN code, etc. I can use that cite on on Lee piece, though if you access the document, it shows the double citation. SusunW (talk) 19:00, 13 July 2015 (UTC)
@Trappist the monk and SusunW: This is why I recommended the multiple-citation approach. The ideal here (and I believe WP:SAYWHEREYOUGOTIT supports me) is to cite the source read, and then indicate the chain back to the original publication. Here we'd ideally cite the PDF ({{cite web}}), list the PDF as citing/quoting the book ({{cite book}}), and list the book as citing/quoting the magazine article ({{cite magazine}}). A little convoluted, to be sure, but it makes the origin of the cited facts clear and gives readers multiple options for verification. {{Nihiltres|talk|edits}}19:11, 13 July 2015 (UTC)
If you are reading a book at Google books or Internet Archive, then cite the book as a book when those images that you see on your screen are facsimiles (scans) of the book. If you can read A Pan-American Life: Selected Poetry and Prose of Muna Lee online then you can cite that as a book. At Google books, the best we can get is snippet-view but that is sufficient to show that the pdf is not a facsimile but rather a transcription. So, if you have access only to the pdf, then that is the thing that you should cite and as such cite it using {{cite web}}. If all we have is the pdf, we do not know what editorial license was taken when the magazine article was made ready for publication in A Pan-American Life.
The snippet-view problem is only true of copyrighted works Google doesn't have license to distribute freely in full text; Google Books does in fact provide full-text PDF facsimiles of a large number of public-domain books; I use it to get them frequently. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 22:18, 15 July 2015 (UTC)
It is not the function of a citation to state the publication history of a work. When citing Dickens' Oliver Twist, for example, we cite the particular book by publication date; we don't backtrack to the original Bentley's Miscellany publication of the serial parts. The purpose of a citation is to identify the source material that an editor is using to support a particular claim in an article. WP:SAYWHEREYOUGOTIT does not require editors to provide publication histories in citations.
Also, the copyright status of the work you read has nothing to do with the information a bibliographic citation should include. Parties get acknowledged in a citation for their intellectual contributions, not for their legal rights. WhatamIdoing (talk) 00:02, 14 July 2015 (UTC)
@Nihiltres:@SiBr4: Brilliant! It worked. Except that [verb]ed rendered just like that showing the brackets, so I just typed contained in and it looks perfect. Two authors, two titles, two dates! Exactly what I needed. Thank you both, you are amazing and a valuable asset to us mere mortals without technical skill. SusunW (talk) 18:10, 13 July 2015 (UTC)
@SusunW: Right. I just used "[Verb]ed in" for the example because the relationship could vary: "quoted in", "contained in", "cited in" et cetera. Anyway, glad to help. :) {{Nihiltres|talk|edits}}19:03, 13 July 2015 (UTC)
Concur with Nihiltres. SAYWHEREYOUGOTIT wants you to cite the actual excerpt you found it in, which is a particular work. WP:RS wants to know why this is actually a reliable source, so you need to indicate the "chain" of citation back to the original, without misleading anyone into thinking you have on-hand either the original publication or the journal that republished it that lead eventually to the third-party excerpt you have. This has nothing to do with online vs. dead-trees copies of books. It has to do with editorial sources. Someone edited out the excerpt from a journal which republished. That's a chain of three, not two, editorial processes. The last in that chain could have introduced independent errors, which is why you have to cite where you actually got the material. By contrast, if my publisher used the final TeX draft of my book to produce a paper copy and an e-book for simultaneous release, as is typical today, that is a single editorial process, and you can use {{cite book}} to cite the online copy of the book (otherwise that template would have no |url= parameter, of course). If Project Gutenberg, Google Books, or Archive.org provide a PDF copy of a book scanned from the hardcopy in a library, you can cite it with {{cite book}}, too; it's a photographic facsimile (even if it also includes embedded OCR text that helped you find it and which makes it content-searchable by the user, at least it if it was done right); the URL says where you got it. Some would argue that you need to use the scanning date as the publication date and use |origyear= for the original book, and some might even make arguments about what goes in the |publisher= field, but I think that's splitting hairs for no reason. By stark contrast, if a text approximation of the book in .mobi or .epub form, produced purely through OCR (which is also common at all three of those sites), this is a separate editorial process (one that introduces usually quite numerous errors), and you should cite it specifically as a PG/Archive.org/Google Books e-book edition (including Google Books when it provides snippet view only), with its modern release date, and indicate the date of the original only with |origyear=; you cannot cite it as the original publication. That error rate alone is a very good reason to always prefer the PDF scan when you have a choice, which is usually the case [except for non-free stuff you get snippet view for]. An e-book textual approximation is arguably not really a reliable source due to this problem. At the very least, the article using such a source would be at the mercy of the trust level that GA/FA assessors have in the proofreading at PG/Archive.org/Google Books, and most of them surely know that the QA in this regard is very low where it even happens at all. Some of the OCR'd e-books you can download from these places are almost unreadable. I've totally given up on them, and work strictly from PDFs at these sites. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:44, 15 July 2015 (UTC)
My first mapping effort
I would like to duplicate the map found here in a format useful for the Wiki. I was wondering if any map experts might help me, or point me to the right starting place? Maury Markowitz (talk) 12:03, 15 July 2015 (UTC)
@Maury Markowitz: Please clarify: Are you looking for a map expert to make the map, or a map expert to help you get started making your own maps? Both are probably available. ―Mandruss☎12:12, 15 July 2015 (UTC)
Thanks. I don't have the problem in Firefox but see it in IE 9.0. It's the same for the section below, no problem in Firefox but misplaced bullets in IE 9.0. PrimeHunter (talk) 23:20, 15 July 2015 (UTC)
Green marker in watchlist for pages that have been changed
Not sure if this is the place to make this comment so feel free to move this comment to a more appropriate place if necessary.
The use of a green marker in the watchlist is a real concern for me and for the significant percentage of the population with some form of colour vision deficiency.
Wikipedia:Manual of Style/Accessibility#Color recommends that colour alone should not be used to mark important information. This should equally apply to non-article pages as well. The use of green in particular is a real accessibility no-no.
@Mattinbgn: In Preferences > Gadgets under the Watchlist heading there's a "Display pages on your watchlist that have changed since your last visit in bold." option which should hopefully help :) Sam Walton (talk) 23:02, 12 July 2015 (UTC)
This should probably be made the default. I'm not colourblind, but I've got real trouble parsing the watchlist with just the bullets. Alakzi (talk) 23:13, 12 July 2015 (UTC)
Silly me -- I thought it was the default. BTW once in a while I see a kind of grayish bold instead of the usual deep blue bold. I've never been able to figure out what that means. Anyone know? Also, can someone please update the collapsible "Legend" inside the "Watchlist options" box, so it will include all the new bells and whistles and colors and stuff? EEng (talk) 23:47, 12 July 2015 (UTC)
I'm not sure I've seen a gray bold, but I'd be happy to update the legend - what bells and whistles are you referring to? The green marker is a bit of a long explanation so probably best left as a sentence above unless you can think of a succinct way to write it. Sam Walton (talk) 00:03, 13 July 2015 (UTC)
Not gray, but a kind of medium-light blue/grayish blue. It's only about once every few days. As to the bells and whistles, I guess didn't really see the bit about "with a green symbol", which I think is new (?), so I get it now. But why not put the four symbols -- green bullet, green collapse arrow, blue bullet, blue collapse arrow -- in the legend, along with the explanation of bold? When one sees a legend, one naturally gravitates to it, thinking it's the key to everything. I guess I just assumed that if the legend didn't explain the green/blue thing, nothing on the page did, and stopped looking around. EEng (talk) 00:41, 13 July 2015 (UTC)
I leave this to your judgment, but thanks for the info. Listen, I have a question... In an earlier thread I suggested adding to the popups menu a "Mark this page as visited" option. I was given a not-very-convincing reason that this wouldn't be possible except by silently fetching the article and throwing it away. I had completely forgotten about the "Mark all pages visited" button -- given its existence, it seems it shouldn't be too hard to do that on a page-by-page basis. What think you? EEng (talk) 15:33, 13 July 2015 (UTC)
A general comment - Wikipedia is not particularly good with accessibility for readers/editors with colour vision deficiency. This is at least partly to do with the volunteer nature of the project - it relies on editors taking into account an issue they are likely to be unfamiliar with and there is no co-ordinated editing approach to highlight issues where they arise. Nearly every chart/map that uses color to convey information creates an issue for color vision deficient readers. Some (most?) are just completely indecipherable for me - and my deficiency is quite mild. Map makers especially love to use red and green to convey "yes" and "no" - I just throw my hands up in the air! Not sure how the issue can be addressed but it is a real issue. -- Mattinbgn (talk) 01:38, 13 July 2015 (UTC)
The default configuration of MediaWiki uses bold. Back in the day, it was turned off at en.wp (only) because of server load problems. We had a widely publicized CENT-listed RFC at the Village Pump with unanimous support from dozens of editors to change it back to the default... and the day the devs did exactly what the community asked for, solely because we asked for it, there were dozens of people saying that they hated it and starting another RFC to demand that the config change to be reversed immediately. The green dot was conceived of as a way to provide that signal to more people, without having the bold that some people hate.
Someone like UserEdokter will know for sure, but I believe the gadget to provide the default configuration is turned on for new accounts, but not for existing accounts. So if your account is more than about five or six years old, then it would be off by default. WhatamIdoing (talk) 03:42, 13 July 2015 (UTC)
Yes that seems like a fair representation of the status quo. I think everyone is ope to change this, we just need good ideas that will keep the watch list usable for everyone. P.S. Mattinbgn, if you ever need something addressed in accessibility of the website, am happy to assist you. I made several changes to improve the overall accessibility of the website over the years, I'm willing to assist in further developments. But as you stated accurately, the problem is mostly that in order for the content to be fully accessible, we basically need to turn every editor into an accessibility expert, which is unlikely to happen :) —TheDJ (talk • contribs) 11:22, 13 July 2015 (UTC)
The green arrows have always been default-on for everyone since its conception (except for the enhanced watchlist). You'de have to turn off the gadget explicitly to revert to the software default (bold). However, it the default were to be turned off, then only those who changed the setting would retain it. The rest would follow the default setting of the gadget. -- [[User:Edokter]] {{talk}}17:35, 13 July 2015 (UTC)
Grayish bold
Right now Jacob Bigelow is showing up in my watchlist in this different color. Maybe if "you" (i.e. anyone interested) add it to your watchlist right now you'll see it too. EEng (talk) 04:52, 13 July 2015 (UTC)
Side question
Has anyone worked out a way to make it easier to spot single-character changes? Sometimes someone only removes a space, or changes as "," to a ";". While normally no one cares, this can make a big difference in a page full of source code, and tracking down such changes is maddeningly tedious. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:46, 15 July 2015 (UTC)
Wouldn't it make more sense to just use one of the existing freeware Web discussion board (forum) packages that most of us are already familiar with? This would require doing one of the following:
Replacing its native bbcode parser with calls to the wikicode parser
Creating a plugin for it that calls the wikicode parser
With the latter approach, we could leave the bbcode features alone (other than disabling the feature to inline images from offsite), and just add to it a [wiki] ... [/wiki] feature, with anything inside that being parsed as wikicode.
Obviously this would take a non-trivial amount of work, but from a how-to-approach-it standpoint, it makes more sense to me than the current wheel-reinvention approach. I would almost be surprised if this hasn't been done somewhere already (probably without the wikicode parsing) at some other MediaWiki installation, using apache (or whatever) URL rewriting to redirect requests for talk pages to forum threads. That part of the process seems comparatively trivial to implement.
A variant of this idea would be to have a preferences setting for using wiki talk pages or a "traditional" Web forum interface, so people can post either way, and scripts would translate between them on the fly during the save process. The principal problem with that would probably be that wiki talk page editors could still insert comments into threads arbitrarily, but webboard users would only be able to append them as new material (either new topics, or new replies). All convenience comes at a cost, I guess. Another bot might even be able to fix that, though, by examining indent levels, and "translating" interpolated talk page posts into message board replies at the right level.
A number of discussions on Wikipedia don't have exactly an one linear thread per forum format. I also wonder about security (the website I work on, TV Tropes) once had such a forum that turned out to be too unsafe against hacking attempts, thus we now use a homebrew code that is of similar appearance as Flow. That was years back, though) and integration with MediaWiki. Jo-Jo Eumerus (talk, contributions) 13:03, 15 July 2015 (UTC)
Speaking from the technology side, I think you are underestimating the work required. I count:
Replacing the parser (HUGE)
Replacing the login system
Replacing the account management
Replacing the skin
Implement transclusions
Integrating a new notification system
Deal with integrating back and frontend caching between the two systems.
etc etc etc.
You would have butchered up the original so much (and you would have to maintain that butchered variant and keep it in sync with the original) that there is little difference between that and starting from scratch. —TheDJ (talk • contribs) 09:33, 16 July 2015 (UTC)
A lot of the good web boards are published under licenses incompatible with MediaWiki's license, and the ones that are compatible with its license are not that great. I agree with WMF's decision to implement a new discussion forum system, which looks very good at the moment yet is published under a compatible license. Gparyani (talk) 19:10, 16 July 2015 (UTC)
Too much dependence on volunteers
Sockpuppet
The following discussion has been closed. Please do not modify it.
Volunteers like Cyberpower TParis Hedonil music animal nakon, x! and others have a lfe of their own. Everyday some tools malfunction. Can't the wikimedia employ atleast five people to make these tools work 24/7. I agree with Kudpung that these important tools shouldn't be maintained by volunteers. And if any Wikimedia people reading this just think about it. Free encyclopedia should not become bugged encyclopedia.--Captain Doverman (talk) 05:30, 16 July 2015 (UTC)
The last thing we need is fingerpointing. I would like to thank them: X!, Hedonil, TParis, Cyberpower678, MusikAnimal, et. al., for building, maintaining, and for picking up the pieces. xTools is currently at the mercy of its environment. Repeatability is an issue. Right now, we need a DevOps project to isolate the factors which are killing xTools. --Ancheta Wis (talk | contribs)06:09, 16 July 2015 (UTC)
Thanks for twisting my words. I was supporting them. I understand their pressure. I was accusing Wikimedia for putting too much burden on them. We don't know their real names and their pictures. Technical 13 is banned. They will contribute and retire, we will know them with their username not the human behind that name. Yes i was finger pointing against Wikimedia foundation. So what?--Captain Doverman (talk) 07:02, 16 July 2015 (UTC)
By definition, being a volunteer is voluntary. WMF is not a nation state, and can not impose duties on volunteers they have not themselves taken upon them. If you have concrete suggestions for how to retain valued volunteers, that is a different discussion.--Anders Feder (talk) 07:47, 16 July 2015 (UTC)
I think their argument was that many of the tools are so useful or important that the WMF should be providing some support towards their maintenance. Sam Walton (talk) 08:06, 16 July 2015 (UTC)
Yes i know about voluntary. These are very important tools and WMF shouldn't just sit and relax putting the entire burden on volunteers. Article creation is different, tool maintenance is different. Even a 12 year old girl can understand this, which some experienced wikipedians failed to understand. What next--- Wikipedia security related issues will also be thrust upon volunteers? There must be some mechanism in selecting them. As check user identity is verified. The tool creators must submit their professional and educational qualifications to the WMF. There must interview to check their capability. I don't have to explain that only software engineers and IT professionals or computer science students maintain tools. History students, arts students can create articles, but they don't do these things. Captain Doverman (talk) 08:44, 16 July 2015 (UTC)
I understand what you are trying to say. But... you have to consider that 'more stuff', means more knowledge and worse, when it comes to volunteer 'experiments', knowledge that cannot easily be institutionalized. The trick to efficiently scaling up is that you create a 'common' base of knowledge, that you can reuse across multiple projects. With the volunteer projects, this is hardly possible, because they are often 'improvised hacks' that 'do their own thing'. This is actually what makes them powerful, because people can divert from the set out conventions and find wonderful new approaches.
Now WMF is already spending a lot of time building infrastructure to sustain this internally and through API and labs externally, but I do think that WMF should for instance, give more workshops to volunteers to build up knowledge about how to scale their own work. They need to encourage people to do more things like the shared static resources offering between tools. To help them with source code management and building development teams around tools. To help them improve bug reporting and documentation etc. Because that is what will make things scale the next five years and create fewer problems long term for everyone. The problem is just that we have a few critical tools that are 10 years old that will have to find a way to catch up with that. But just tossing five expensive resources (that would have to be hired from where exactly... ??? ) will not fix the problem with these tools any time soon either and worse if they did work on this, we would have the exact same problems five years into the future.. —TheDJ (talk • contribs) 09:08, 16 July 2015 (UTC)
@ Anders Feder, which part of my sentence"I am not accusing the volunteers"you don't understand. I am accusing WMF for putting some volunteers to develop these important tools, which they are supposed to develop. Don't they have any responsibility?. Is it so difficult to hire only five software engineers and computer/IT professionals. Wikipedia is a free encyclopedia. Cyberpower, music animal, they have their own professional/student life. Whenever tools don't work, they come under pressure from all quarters. As volunteers, we are putting too much pressure on them. What do they get in return from WMF ?Captain Doverman (talk) 09:33, 16 July 2015 (UTC)
WMF haven't "put some volunteers" to anything. The volunteers have chosen to make the tools on their own initiative in order to solve a problem they have themselves defined.--Anders Feder (talk) 10:22, 16 July 2015 (UTC)
@Captain Doverman:, I think with a few more tools, it should be possible to debug where the problem sits in the code, which is visible on github. Hedonil and Cyberpower678 put the X! code up on github for anyone to see. But Cyberpower678 has observed that his test cases are not getting executed. I propose we use xdebug extension for PHP to isolate where the thread is getting stepped on. But I believe this is a DevOps situation, which is bigger that the xTools code itself. So we need cooperation from others, such as the Redis specialists (in WmF?). --Ancheta Wis (talk | contribs)13:09, 16 July 2015 (UTC)
With all due respect, I think I'd prefer the present set-up to an organised WMF team... If the OP is still watching this thread (but he's currently unable to contribute to it, so he might not be), nobody here gets 'assigned' to tasks. I came to Wikipedia to remove some rubbish, and I'm still doing that. Others have technical knowledge and skills that I don't - they create tools and keep the basic framework of the place working. There are paid WMF people for positions that volunteers couldn't really be expected to handle - maintaining servers, dealing with legal matters and so on. Peridon (talk) 15:40, 16 July 2015 (UTC)
In chemistry, there is an identifier named InChI that is an encoding for the full (3D) molecule structure. For example acetate has InChI=1S/C2H4O2/c1-2(3)4/h1H3,(H,3,4)/p-1. My question is: how should we best add this code to the article? It is illegible, but it is an ID for sure.
Notes:
Publishing the InChI code in an article will help outside searches.
Per chemical substance, there exists just one normalised code. However, multiple non-normal codes can exist in parallel. For these, the same question exists: add to article because of external search?
InChI code can be long, like 500 characters. (It is also hashed into a shorter Key, which is not unique. Let's forget for now).
Today, the illegible code is folded in a collapsed "hide" box. However, as we know in mobile view it is not hidden.
I don't expect a conclusive answer here, because it is multi-faceted (readers view & ID & search). But can people give me hints on where to read & learn & detail this? Any earlier wisdom? -DePiep (talk) 20:40, 16 July 2015 (UTC)
I don't think that it is useful to file a ticket on the Phabricator because I believe that this problem is related to Internet Explorer, and that it is not fixable on Wikipedia. AFAIK the only (good) solution is to change how Internet Explorer works. AFAIK there is no fix for this problem that could be implemented on Wikipedia. The Quixotic Potato (talk) 03:27, 16 July 2015 (UTC)
The issue may be the CSS associated with those divs being interpreted differently by different browser versions. (easy enough to check: turn off CSS) but I suspect the issue is because Wikipedia uses the old style <br clear="all" /> instead of the more modern <br style="clear:both;" /> or the external CSS equivalent. --Guy Macon (talk) 03:30, 16 July 2015 (UTC)
Float:left on the <li> seems to work, but that still isn't perfect. A better solution is to set the display style of the UL element to table. Please don't ask me why, but that seems to work. Or <ul style="list-style-position:inside;">. I hate Internet Explorer. The Quixotic Potato (talk) 03:43, 16 July 2015 (UTC)
This is a bug in IE9. However, to some degree this is a problem with all lists next to floating content. It's just aggravated by the bug. We have {{Flowlist}} to deal with specially this combination of content, a list next to a left floating element. I suspect it will also fix the IE9 issue. Please do try it out. —TheDJ (talk • contribs) 09:17, 16 July 2015 (UTC)
Fwiw... to rectify this behavior (under at least IE 11), the UL or OL needs to be set to display: inline-block; rather than the default, display:block;.
An image
A bullet
Another bullet
A third bullet
Some more bullets...
One final bullet
Since wiki markup is being used I'm guessing wrapping the list in a DIV set to the same display:inline-block; should work as well. -- George Orwell III (talk) 20:56, 16 July 2015 (UTC)
@Gparyani:. The amount of distance between the image's right edge and the bullet marker items is due to the [re]use of the default UL margin: css settings because the assumption has always been list-items would be the left-most content in any given block of text being applied. There is not much that can be done about that except for dropping the use of wiki-markup for such lists and then overriding the defaults by adding your own modified inline css styling(s) for the opening UL tag.
As for filing a request to "correct this" across all the wiki-projects; that's not likely to be accepted -- at least not without thorough vetting against all browser versions and multiple usage scenarios that is. Since the behavior seems to be specific to IE 9 and higher, I'm betting the response to asking for such a change would be to apply templates such as {{Flowlist}} or similar workarounds (like my DIV wrapper one) on a case-by-case basis. I'm afraid I'd have to agree with such a position; there are just too many variables and possible instances of usage-type in play to craft a universal solution given the fact float: and DIVs are used for [thumbnail] image alignment to begin with. -- George Orwell III (talk) 23:22, 16 July 2015 (UTC)
I can confirm that this would likely be the result. Flowlist itself is the result of such a bug report. This is just one of those situations, where HTML has trouble delivering what we want it to do. —TheDJ (talk • contribs) 14:37, 17 July 2015 (UTC)
The title creation blacklist had a minor glitch in functionality...
Just wanted to point out that the software that enforces the title creation blacklist had a malfunction about five minutes ago. I cannot replicate the issue at the present time, given that the blacklist enforcement software is functioning again. (I know that there was a bug filed for this and resolved in the past, but I cannot find it right now.) Steel1943 (talk) 21:02, 16 July 2015 (UTC)
Only lately, I've noticed a few pages not loading for me in Opera12, though they load in new Opera and Firefox. At first it was the 2015 FIFA Women's World Cup, but 2011 & 2019 worked. Now I notice they don't, and I've also found John O'Brien (priest) doesn't work either. I suspect now it has something to do with the apostrophe, but replacing it with %27 doesn't work either.
New Opera uses that and works, FF uses apostrophe and works.
I've noticed this is called a bug, but I didn't see how to make it work with my browser. Overall, I guess it's not essential, but if you know any fixes I'd like to know. Thanks...Smarkflea (talk) 22:25, 16 July 2015 (UTC)
I tried all those thing, incl. logging out, and I get the same thing (Win8.1). Only the address bar loads; nothing at all on the screen but white.Smarkflea (talk) 01:59, 17 July 2015 (UTC)
Because moving w/o redirect is technically copying an article to a different title and deleting the original? Is there anything undesirable about the notice?--Anders Feder (talk) 02:21, 18 July 2015 (UTC)
Thanks, that explains it. I should have spotted that. It was in the user's signature, but they seem to have gone back to a standard signature now. Cheers, JohnCD (talk) 17:47, 17 July 2015 (UTC)
Protecting an entire article against automatic spell-miscorrection
(Dthomsen8 has asked me to address this problem because I'm a linguist.)
Is there a straightforward way to protect an entire article from automiscorrection?
AWB tries to "correct" some words in Catalan verbs to English words that they resemble. How can this be prevented without {{sic}}cing every Catalan word in the article, of which there are a great many? Please {{Ping}} me to discuss. --Thnidu (talk) 23:48, 14 July 2015 (UTC)
@Thnidu: If you use the {{sic}} template on a page then AWB will display the following warning in a messagebox: "This page contains a 'sic' tag or template, please take extra care when correcting typos". Many AWB users will simply skip the article after receiving that warning. If you do not want to show it, you can use "{{sic|hide=y}}". I don't know if AWB knows that it should ignore anything inside the template {{lang}} if the language is different than the language of the typo-regexps. The Quixotic Potato (talk) 00:05, 15 July 2015 (UTC)
What if you replaced a character in the word with a Unicode equivalent that AWB won't recognize? bd2412T00:28, 15 July 2015 (UTC)
It might be interesting to have AWB be changed so that it also pops a warning when {{lang}} is used. Might submit a phab for that regardless and then the AWB devs can tell us whether it works like that already. --Izno (talk) 00:52, 15 July 2015 (UTC)
People who blindly correct spelling with AWB - changing dozens of instances of "movie" to "movi.e.", for example - shouldn't have access to it at all. There's been a very strong consensus to reject unsupervised spelling bots since forever precisely because of this sort of problem. —Cryptic00:52, 15 July 2015 (UTC)
@PrimeHunter: My point is that it is massively impractical to {{sic}}-tag every non-English word in a sizeable article about another language, and it is clearly unreasonable to expect an editor to do so. The Quixotic Potato and Izno have made useful suggestions, and Cryptic has made a very good point and mentioned a consensus or policy that I was not aware of. --Thnidu (talk) 01:26, 15 July 2015 (UTC)
In general, AWB does not change anything within a template such as {{lang}}. It never does so for its several thousand typo rules. An AWB user can force the program to change text within a template for rules that they have themselves provided, but they should not do so unless they really know what they're doing. The problem is not within the program. No editor should save any change if they do not understand why that change is being suggested. If any user (with or without AWB) makes repeated erroneous edits, you should tap them on the shoulder and inform them of the disruptions, and then undo the damage. If they persist, have them banned from editing. If anyone knows the details of 'dozens of instances of "movie" to "movi.e."', please provide those details here or on AWB's talk page so we can deal with that situation; my guess is that an unreliable editor has made up a rotten rule. But please don't post vague complaints here in an effort to place restrictions on the use of AWB. Christhe spelleryack02:30, 15 July 2015 (UTC)
@Izno:@Thnidu: I did some experimenting, and AWB does ignore stuff that is inside a {{lang}} template, even when I claim that the language is English. It also ignores stuff inside the templates {{sic}}, {{typo}}, {{notatypo}}, {{As written}} & {{Proper name}}. But for some reason I couldn't get AWB to show me a messagebox with the warning I mentioned earlier... I do not understand why. I am certain this used to work with older versions of AWB, here is the code (from main.cs):
// check for {{sic}} tags etc. when doing typo fixes and not in pre-parse mode
if (chkRegExTypo.Checked && !preParseModeToolStripMenuItem.Checked && TheArticle.HasSicTag)
MessageBox.Show(@"This page contains a 'sic' tag or template, please take extra care when correcting typos.", "'sic' tag in page", MessageBoxButtons.OK, MessageBoxIcon.Warning);
It is easy to find the message in older versions of the source code (if you search for "take extra" you can find it here for example. But for some reason I am unable to find "take extra" inside the most recent version of the same file.
I do not understand why, but I think that this messagebox-warning has been removed for some reason.
Speculating, you can silently ignore text inside T:Lang without worry and any langs in general because text is always inside lang (and presumably that's the text that shouldn't be changed), but you can't do the same since sic doesn't always contain text within, which is why you need the FYI to the user. --Izno (talk) 02:51, 15 July 2015 (UTC)
EEng is correct, I just tested it, {{bots|deny=AWB}} works. I think adding {{sic|hide=y}} isn't a bad idea, because it does show a warning in AWB, but the attention-grabbing messagebox is gone. The Quixotic Potato (talk) 03:00, 15 July 2015 (UTC)
"How can this be prevented without [sic]cing every Catalan word in the article, of which there are a great many?" Simple: put a {{lang}} template around only the words or phrases that draw AWB's attention. I have done this, and it only took a few minutes. The next time you have a question about AWB, try the talk page for AWB. The editors there are very knowledgeable, helpful and friendly. You'll get help a resolution faster, and it won't look like you're trying to sneak up and gang up on the AWB users. Is it too soon to put a {{Resolved}} template on this section? Christhe spelleryack02:58, 15 July 2015 (UTC)
The section starts out with an attempt to stop AWB from ever touching the article, not asking how to prevent AWB from damaging the article. Yes, I may have misconstrued Cryptic's purpose for mentioning "movi.e.". But I stand by my statement that the AWB talk page would be a better forum. Christhe spelleryack03:23, 15 July 2015 (UTC)
@Thnidu: Regarding the Catalan verbs article, I've fixed several English misspellings and added/fixed some italics to protect some Catalan text. Chris the speller added a few {{lang}} templates to protect the rest of the Catalan text. The net effect of the changes can be seen here. Could you please add the missing end parenthesis in the last paragraph of the Catalan verbs#2nd conjugation (-re, -er) verbs section?
I wasn't taking a position on what the best approach is, just pointing out a technical fact. But since you bring it up, I personally have been vexed many times over many years by mindless "fixes" wrought by script-kiddies in a hurry to make themselves feel they're helping WP by changing careful writing and markup to lower-functioning vanilla that looks like what they've seen in other articles, and which they therefore have concluded must be the only acceptable way to do things. EEng (talk) 03:12, 15 July 2015 (UTC)
@Thnidu and Chris the speller: To clarify my post above, please note that AWB also doesn't fix the spelling of any text inside of quotation marks or italics. (I've just clarified this on Wikipedia:AutoWikiBrowser/Typos#AutoWikiBrowser (AWB).) By adding italics for the book titles in the Catalan verbs#Bibliography section, the {{lang}} templates were not necessary there. Not only did fixing another set of italics earlier in the page made another {{lang}} template redundant, but it then allowed AWB to identify some real English typos, which I then corrected. Hope this helps! GoingBatty (talk) 03:23, 15 July 2015 (UTC)
@CambridgeBayWeather: Sorry my edit summary wasn't clear. The editor who accidentally changed "movie" to "movi.e.," four times made a mistake. Your action to change "movi.e.," to "movie.," was also an accidental mistake. In my edit summary, I meant to indicate that I was fixing all of these accidental (but good faith) changes. GoingBatty (talk) 03:54, 15 July 2015 (UTC)
@Thnidu:: Proper use of {{lang}} is how to fix this. Yes, it's some amount of work to do it, but it should be done anyway, even aside from AWB issues, and is the semantically correct way to do it; putting {{Sic}} around all the Catalan content is the same amount of work, but a worse-than-pointless approach. In the interim, as someone else pointed out, even including a single {{sic}} will send up an AWB red-flag. You could thus use it at the bottom of the page thusly: {{sic|hide=y|reason=Do not remove this. It is a signal to AWB users that this page contains a lot of non-English text that can produce false positives in AWB's automated spell-checking routines.|<!--Intentionally blank content.-->}}, or better yet, put that all in a template, e.g. {{Do not auto-correct spelling with AWB}}. PS: Using {{bots|deny=AWB}} is also a wrong-headed approach, because AWB does many things besides spellchecking. Abuse of that tag is a minor form of WP:OWN and interferes with others' editorial rights, albeit not in a huge way. More importantly, it interferes with the ability to include Catalan-related articles in legitimate cleanup efforts. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:08, 15 July 2015 (UTC) Struck out my brain-fart. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 07:04, 15 July 2015 (UTC)
D'oh! I need coffee. Oh well, then just putting an empty, hidden {{sic}} at page bottom should do it. My main concern was people abusing {{sic}} to "protect" non-English words instead properly using the same amount of work to identify non-English text with {{lang}}. — SMcCandlish ☺☏¢ ≽ʌⱷ҅ᴥⱷʌ≼ 07:03, 15 July 2015 (UTC)
The {{sic}} template is very very rare, and the amount of typos approaches infinity. The sic template is used in ~12.500 locations (including outside the article namespace) and there are 4,917,656 articles in total. The Quixotic Potato (talk) 09:57, 15 July 2015 (UTC)
I tried to point out that if there are people abusing {{sic}} to "protect" non-English words instead of identifying non-English text with {{lang}} then that must be very rare, because the sic template is not frequently used. The Quixotic Potato (talk) 23:58, 15 July 2015 (UTC)
Essentially when doing a spelling correcting run with AWB one has two options available when encountering a false positive:
Skip the spelling/article (both easy)
Tag the correctly-spelled-in-this-context word with a Lang, Sic, Typos, Not a typo, or Proper noun templates.
Anyone who does the first will run into the same false positives on the next run, so it is I imagine pretty normal to do the second (I certainly did).
Proposed software change: Show the reference list when section editing
I often find little errors in references, and usually hit the edit section button to correct these. The problem is, I have no way to preview them when I do this. I suggest that the reflist be automatically added below the edit summary window if the edited area doesn't already have one. This would allow me to preview my reference corrections, instead of having to do another edit to correct it again. Oiyarbepsy (talk) 04:54, 17 July 2015 (UTC)
Support - For the reason given, I usually avoid section edit for this purpose. The problems with that: Sometimes a little harder to find the spot I want to edit (although browser Find usually gets me there with a good choice of search text), increased chance of edit conflict, and edit summary doesn't show the section name. An alternative solution would be to make the ref tooltips work in section edit preview (or do the two go hand-in-hand?). Shouldn't this be at WP:VPR? ―Mandruss☎06:55, 17 July 2015 (UTC)
I had this on my idea list as well. I'm not sure if it's entirely possible. The biggest problem however is that you are guaranteed to have big red errors as soon as you have named and reused references. It's a bit jarring to novices.. —TheDJ (talk • contribs) 13:36, 17 July 2015 (UTC)
This has been tried in a hackish way via Template:Reflistp. A not-unworkable design would be something like this: as a "last step" in a section preview, do the equivalent of {reflist|group=foo} for all nonempty groups. These would not necessarily show the refs the same as they'd be seen in a full-article preview (# columns, etc.) but would be enough e.g. to proofread citation templates. "Referenced but not defined" errors could simply be surpressed -- or if that's hard just leave them. If all this comes at the very end of the page those who don't find it useful could ignore it all. EEng (talk) 22:50, 18 July 2015 (UTC)
I've been doing some work on List of people from Pennsylvania, which is quite lengthy and is subdivided by, I guess, reason for notability: Actors, Artists, Athletes... Recently IP user 173.52.75.38 broke up the four or five longest sections into alphabetical chunks (diff), which I thought was an excellent idea (their talk page). To reduce the need for scrolling still further, I added subTOCs— see for example § Athletes there— but I used anchors instead of subTOC wikicode because there's more than one "A–B" sub§, etc. I think this could be very useful for many long lists.
My understanding from that HD thread is that this was made necessary by a change to MediaWiki:Common.css.
We sometimes see CSS used in wikitext to enhance layout, but this is the first time I've seen it required to prevent layout from breaking. Basically we're saying that average editors will have to know this workaround solution just to make basic layout work; to the extent they do not, there will be ongoing related issues at Help Desk, Teahouse, etc. Is this the best we can do?
The offending declaration block should simply be removed. I don't see why anybody would need to change the background of block quotations, and, even if they had to, they'd be wise to do so systematically, using a template. Alakzi (talk) 11:57, 17 July 2015 (UTC)
If you need to reset the overflow property, use inherit instead, as initial is ignored by IE. But it has been pointed out that we sometimes expect behaviour from HTML that is not always possible. In such cases, consider alternative layout; don't force the layout you want using CSS hacks. That tends to backfire. -- [[User:Edokter]] {{talk}}07:34, 18 July 2015 (UTC)
The reason it was placed in Common.css: "Avoid collision of background with floating elements". Note that this mainly applies to templated uses of <blockquote>. -- [[User:Edokter]] {{talk}}09:18, 18 July 2015 (UTC)
So there's nothing wrong with it. If it mainly applies to templates, then it should be placed in templates. Alakzi (talk) 09:23, 18 July 2015 (UTC)
What's wrong is that it's there. I agree the blanket declaration for <blockquote> is misplaced; it should be a template class. But let's not hide that by applying these hackish work-arounds. -- [[User:Edokter]] {{talk}}09:42, 18 July 2015 (UTC)
Well, it is a temporary measureAlakzi, if this is temporary, where is the permanent? Is this something to be filed away in the back of one or two people's minds, for possible later attention as time permits? I again ask people to look at this from the average editor's perspective, and I'm still interested in an answer to my preceding question, which was not rhetorical. ―Mandruss☎02:52, 20 July 2015 (UTC)
You're preaching to the choir. I can't answer your question; I wasn't the one who made that decision. It will be fixed permanently if and when it pleases His Majesty Edokter, Protector of All Stylesheets. Alakzi (talk) 09:17, 20 July 2015 (UTC)
Various tools are down
It's known here that Article History tool hasn't been working for quite a while now (around a month). But now, things are getting worse: the Sigma tools (such as this and [18]) are now displaying a 500 error when you try to use them. Now what? Narutolovehinata5tccsdnew02:21, 18 July 2015 (UTC)
(edit conflict) My tools were briefly down for maintenance. As for WikiHistory, a replacement from the German Wikipedia is in the works, as far as I know. →Σσς. (Sigma)02:27, 18 July 2015 (UTC)
It appears that MediaWiki:Histlegend should update //tools.wmflabs.org/usersearch/index.html?page={{FULLPAGENAMEE}} to someting like //tools.wmflabs.org/sigma/usersearch.py?page={{FULLPAGENAMEE}}&server=enwiki. PrimeHunter (talk) 03:10, 18 July 2015 (UTC)
Apologies for article info not working. Our team of developers cannot figure out what the problem is. As an alternative, per what Sigma said, I am working on making the German version articleinfo, called wikihistory, available for the english wikipedia. I should have it up soon.—cyberpowerChat:Online14:22, 18 July 2015 (UTC)
It's not clear from the comments if this alternative is meant to be a temporary solution until the issues with revision history statistics are solved. Don't see an issue with a temporary alternative, something is better than nothing, but if it is meant as a permanent replacement this surely requires a RfC to get community opinion and consensus.--Wolbo (talk) 12:56, 20 July 2015 (UTC)
Whether you want to use any tool temporarily or permanently is your own call, and as such does not require any consensus.--Anders Feder (talk) 13:53, 20 July 2015 (UTC)
Mobile editing
Has something changed recently with the mobile editor to make inadvertent deletions of the lead like this more likely? I'm seeing more of them, all mobile edits. --NeilNtalk to me14:45, 18 July 2015 (UTC)
I don't know statistics or an answer but will just mention that section blanking has always been common in the desktop version. However, desktop doesn't have an edit link for the lead (unless you have an account and enable a gadget), so in desktop it isn't the lead which is blanked. Mobile does have an edit link for the lead, and mobile editing is probably increasing in general. PrimeHunter (talk) 00:41, 19 July 2015 (UTC)
Indeed, tack "?useskin=minerva" at the end of any Wikipedia url, for example this page. The only edit link I see in my browser is the one to edit the lead, but I haven't played around with any Minerva preferences. --Unready (talk) 16:23, 19 July 2015 (UTC)
That's because this page is messy. Proper articles have a section edit button when you uncollapse the button. It depends on the ability to automatically detect sections, which is fragile (because wiktext has no proper sections, just headers). —TheDJ (talk • contribs) 11:10, 20 July 2015 (UTC)
It's not stretching it, it's splitting it into shorter lengths in an attempt to display it in columns. Multi-column reflists are not normally useful when the number of references is small (10 or less) and the refs themselves are longer than about half the page width. --Redrose64 (talk) 16:50, 20 July 2015 (UTC)
lists 34 rows. I'm guessing these are being created through an API that does not interpret namespace prefixes properly. Possibly related, there also appears to be an instance of User_talk:War_wizard90 in namespace 0 also - see this query. - TB (talk) 19:45, 19 July 2015 (UTC)
Cheers. We've a total of 69 misplaced articles as a result of this bug from 27th January this year - they can be seen at User:Topbanana/Temp. All have corresponding articles in the correct namespace and are almost entirely inaccessible through MediaWiki. I'll see what can be done about tidying them up. - TB (talk) 08:49, 20 July 2015 (UTC)
@Topbanana: These can be deleted through the API, using just the page ID, not the title. It should be quite easy to create a script that deletes all of them automatically if we use the list of known bad page IDs. — Mr. Stradivarius♪ talk ♪14:20, 20 July 2015 (UTC)
All deleted now; the simplest solution was to correct the deletion confirmation form being produced by the MediaWiki software to retain the curid parameter when passed one rather than always using title to identify the subject of the operation. - TB (talk) 08:12, 21 July 2015 (UTC)
transwiki
Hi,
I'd like to transwiki (most of) my user pages and sub-pages to m:User:Jc37. I'm an admin here, but not currently an admin there. Is there a way to do this besides copy/paste?
Am I better off asking a steward (or someone else) to either do it for me or to ask a steward grant me Importer per m:Help:Import for this?
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Changes this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from July 21. It will be on non-Wikipedia wikis from July 22. It will be on all Wikipedias from July 23 (calendar).
You now see more warnings in the image viewer. They tell you to be careful when using the image, for example if it shows a person. [19]
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs are the most important. The meeting will be on July 21 at 19:00 (UTC). See how to join.
Future changes
Soon you won't be able to use MathJax to display math. [20]
Ever since the official discontinuation of the Compact Personal Bar, I've force-enabled it by adding special code to my vector.js file. However, the bar seems to no longer load. I tried about an hour ago, and it worked fine. Has it been permanently removed even for those who force-enabled it? Gparyani (talk) 18:58, 19 July 2015 (UTC)
Yes, it looks like Ori has removed it from the servers. The WMF devs seem to be spending some time figuring out what they can support and removing things that are at risk for bitrot due to lack of resources for maintenance. I was personally never very fond of that one, but I know that it had a couple of staunch fans. While it might be possible to mimic a few of its features in CSS, it looks like the tool itself is gone for good. Whatamidoing (WMF) (talk) 18:58, 20 July 2015 (UTC)
@Whatamidoing (WMF): Could you get someone to fix the "critical" bugs holding this feature back? I was long aware of them, but I continued to use it because I had never ran into these bugs during the time it was official, and I was willing to accept the risk of running into them later on (I never ran into any one of them afterwards). Gparyani (talk) 19:29, 20 July 2015 (UTC)
I'm not getting into that argument, the fact is that the current resource allocation doesn't allow to support this. Also, it was a beta, primarily to explore an idea, not to deliver it. —TheDJ (talk • contribs) 18:15, 21 July 2015 (UTC)
Compact another way
I don't want to argue the fiscal aspects here either but do take issue with the idea this couldn't be done per a lack of resources or whatever. It seems to me that the approach -- basically a drop-down menu bulleted with "icons" for each label a la OOUI -- was the only avenue ever experimented with. And, once that approach failed due to some extraneous gadget interaction issues, it seems the entire premise (a suitable compact replacement of Personal toolbar's default text) was deemed not worth pursuing at all.
One would have thought alternatives would still continue to be sought out in spite of that one and only approach's failure -- especially if the availability of the 'work-in-progress' is being permanently removed at the end of the day -- instead of being dropped entirely in spite of the apparent demand for something compact. -- George Orwell III (talk) 20:29, 21 July 2015 (UTC)
What is the "apparent demand" we are talking about here? What number of users who regret this trial being discontinued are we looking at?--Anders Feder (talk) 21:00, 21 July 2015 (UTC)
I can't say overall but on en.wikisource, the premise of some sort of "compact" personal tool bar (along with side-bar elimination and/or relocation) was in the majority as far as frequent/regular contributors were concerned. In short, CPB was "popular" until it was no longer a matter of just opting in like most typical Beta offerings. The resulting drive for alternatives vary; the thumbnail depiction is but one avenue taken.
Besides that, I'm under the impression a redesign of the personal (and again, side-bar) toolbar(s) is more of a design necessity than an actual response to demand or polling per the stated infobox blurb for CPB and it's pointer to the proof-of-concept example page. Either way, folks who jump between mobile, tablet and desktop platforms seem to appreciate the 'less is more' (i.e. compact) design direction "we" seem to be on imho. -- George Orwell III (talk) 21:32, 21 July 2015 (UTC)
It's the same as with most changes, overall readers love it, but getting something like this production deployed is massively expensive. Think community communication, multiple variant testing, aftercare due to teething problems, rewriting extensions that use such a thing, rewriting the testcases, making it accessible for the visual impaired, fixing all the user scripts on hundreds of wikis. You would have to invest at least some 25-30 times more than the original hours of the experiment. —TheDJ (talk • contribs) 22:04, 21 July 2015 (UTC)
Points well taken here and can't argue with the rationale behind them but not every "redesign" needs to be in the form of an OOUI, .menupokey driven drop-down background-image bulleted menu. My only point was if the given "Winter" prototype design is any basis for what the future really holds for us, simply switching from text to clickable icons (or background images / mw-buttons if you like) as depicted would have helped meet the new "space" requirements for the current personal toolbar while solving the occasional gadget integration issue(s) without de-railing the entire notion & development of a "flat" or "fixed" article/skin header redesign (Vector-beta) in the process. Now, without CPB as a component, the entire endeavor seems stalled along with losing any chance of somebody fresh "stumbling in" with even better alternatives or refinements to the personal tools redesign question; be that compact or otherwise & all while moving forward. That seems short-sighted imo. -- George Orwell III (talk) 22:32, 21 July 2015 (UTC)
Music
In this table there's a column that says "What links to this file". There are many other tables with identical columns. Instead of discovering and then typing the names of individual Wikipedia articles in that column, is it possible to type some identical code together with the file name? Then the code would automatically display whatever Wikipedia articles link to the file. I think that would make things much easier for me, user:Raul654, User:Ravedave, User:Antandrus, User:Graham87, User:La_Pianista, user:Violarulez, and User:Ftiercel. Thanks for any reply.Anythingyouwant (talk) 05:52, 20 July 2015 (UTC)
As a first approximation, {{Special:Whatlinkshere/File:Oh holy night.ogg|namespace=0}} produces:
With AWB's list comparer I made these lists, which show there are 473 files in subcategories of the Commons category that are not linked on the project page.
As for the second query, I thought using {{#if}} on a transcluded WhatLinksHere page could determine whether or not the list of usages is empty (i.e. {{#if:{{Special:WhatLinksHere/Foo}}|1|0}}), but it seems the special page is only expanded after the parser function is evaluated, as the #if always returns 1 even though the result of transclusion for an unlinked page is an empty string (also, interestingly, {{#ifeq:{{Special:WhatLinksHere/Foo}}|{{Special:WhatLinksHere/Foo}}|1|0}} returns 0). SiBr4 (talk)08:59, 21 July 2015 (UTC)
Thanks, the lists made using AWB will be helpful, and I'll see if I can make similar lists for other letters of the alphabet. It will be quite tedious to add so many items from the Ba category to the Ba table, and it sure would be nice if it could be done automatically. Can it? Cheers.Anythingyouwant (talk) 17:06, 21 July 2015 (UTC)
I figured out how to make a merged document from your list of 473 songs, and then pasted the merged list into the "Ba" table. It's kind of a crummy and incomplete set of info that I pasted, but it is way better than nothing, I think.Anythingyouwant (talk) 03:55, 22 July 2015 (UTC)
Article rename
Could someone help rename an article? The article 9-Man should be called "9-Man (documentary)". The title should be italicized, and it should be noted that it is a documentary, or it will easily be confused with 9-man. Every time I change an article name I mess it up. Thanks! Magnolia677 (talk) 10:29, 22 July 2015 (UTC)
@Magnolia677: I have moved the article to 9-Man (film) since I agree that relying on the capitalization difference to distinguish it from the game 9-man is confusing. For your reference, italics are not truly part of article titles but are instead applied with the template {{Italic title}} in the body of the article (usually at the top). This template automatically leaves the parenthetical disambiguation in roman (ie. not italicized). Cheers —jameslucas (" " / +) 13:04, 22 July 2015 (UTC)
Another watchlist proposal: Symbol to replace (0) when net effect is no change at all
In the case where a sequence of edits has resulted in no net change to the source text at all (not just no net change to the length of the source text) how about replacing the (0) length-delta with something else, perhaps (∅)? It's useful to be able to recognize this special case at a glance. EEng (talk) 14:02, 2 July 2015 (UTC)
Collapse interesting conversation which basically came up with the idea of using () instead of null-set symbol
It's a good idea to distinguish between ε and 0, but the numeric field probably isn't the place to do it. Perhaps an "=" sign (or ==, or ===, depending on your preference...) after the numeric thus "(0)=" . I think it would break a smaller number of applications. All the best: RichFarmbrough, 18:43, 2 July 2015 (UTC).
Good point. Maybe it could be worked into whatever it is you folks are cooking up with the green and blue arrows and dots and whatnot. EEng (talk) 19:40, 2 July 2015 (UTC)
Since the <span> containing the "(0)" has its own CSS class, called "mw-plusminus-null", changing the text to something else can be done with some relatively simple user-specific JavaScript (I've tested it):
This uses the "∅" empty set symbol (U+2205) surrounded by parentheses, as above; this can be replaced with any wanted string. SiBr4 (talk)19:22, 2 July 2015 (UTC)
Yeah, I was wondering just where in that code the test for "no net change" was, but I thought, "Well, these Village Pump gnomes must know something I don't" and went to try it. Guess what? You did misread the question. But it does a beautiful job of turning zeros into "empty-sets". Thanks for the effort, though. EEng (talk) 19:40, 2 July 2015 (UTC)
There's not much we can do here, other than using JavaScript to retrieve the two versions and making a comparison, but that would be rather slow - assume that your watchlist shows 50 edits, that means that 100 pages (50 pairs) need to be retrieved, and for one of the pages in each pair, every byte compared against the corresponding byte in the other page of the pair. Functions exist to compare strings of bytes, not sure if they'd handle strings that were several hundred K in length without breaking into substrings. If nobody is willing to try it in JavaScript, you could file a feature request at phab:. --Redrose64 (talk) 12:34, 7 July 2015 (UTC)
(You're not sure there are functions to compare long byte strings? Are you kidding???) Retrieving and comparing the actual text is obviously out of the question, but with all due respect I question the accuracy of your analysis. When I hover over e.g. 4 changes (or whatever), where someone made a bunch of changes and someone else reverted them, it easily pops up with an empty diff, and that isn't happening by two full versions being retrieved and compared on the fly -- something somewhere knows, without too much trouble, that these two versions of have a null diff. EEng (talk) 12:51, 7 July 2015 (UTC)
@EEng: A page diff is run on the Wikimedia servers and has access to all sorts of functions. Any javascript that customises display for a particular user is run client-side, and so any functions and data that are used must be available to the client. --Redrose64 (talk) 15:19, 7 July 2015 (UTC)
That doesn't explain why, if the javascript can request the two pages themselves (to do its own diff), it can't just as easily request the diff directly. But anyway, since the hashes appear to be available, this is moot (unless we want to improve the performance of the hover-diffs, which would be a good idea -- no wonder they're so slow!). EEng (talk) 15:26, 7 July 2015 (UTC)
The null diff might perhaps use a symbol for unit type, sometimes denoted '()'. It's not the same symbol as ø 'nothing at all'; it symbolizes 'action which leaves what you care about unchanged', such as adding zero to your number, or multiplying it by one. --Ancheta Wis (talk | contribs)13:08, 7 July 2015 (UTC)
If I'm understanding you you're suggesting omitting the zero, so that (0) becomes (). That's a great idea, and might (at least partially) address RF's concern about breaking existing applications, since (one hopes) empty string will be interpreted as zero, for those applications that just want the length. EEng (talk) 13:30, 7 July 2015 (UTC)
@EEng: If you are using Popups to generate diffs when you hover over a diff link, it actually does retrieve two full versions and compare them on the fly. Popups contains its own diff generator, separate from the MediaWiki one, which is why it sometimes says "diff truncated for performance reasons" but the native MediaWiki one doesn't. You can see the code for it by searching for "Javascript Diff Algorithm" in MediaWiki:Gadget-popups.js. Also, if you open the part of your browser console that monitors network requests, you can see the requests for each of the two pages being sent each time you hover over a different diff link. — Mr. Stradivarius♪ talk ♪14:54, 7 July 2015 (UTC)
My apologies. I clearly underestimated the potential depths of implementation insanity. Why in the world don't they get Mediawiki to generate a diff and just use that? Luckily, as seen below, this can all be shortcut via hashes, as seen below. Any thoughts about the interface chanage to ()? EEng (talk) 15:03, 7 July 2015 (UTC)
It is indeed exposed by mw:API:Revisions with prop=revisions&rvprop=sha1. So, it is simply a matter of retrieving the hashes of the first and last revision in a series and doing a string comparison. [21][22]Alakzi (talk) 13:54, 7 July 2015 (UTC)
Yippee! That's even better than a very efficient diff, because it's obviously available for free. So before we recruit some knowledgeable gnome to implement this, what do we need to do to make sure everyone who might care is OK with the suggested output format change i.e. ()? Paging Rich Farmbrough. EEng (talk) 14:49, 7 July 2015 (UTC)
It doesn't need to be backward-compatible with anything if we're writing a user script. If you want this to be changed in core, just open a ticket on Phabricator; it seems fairly straightforward, so it might even be implemented before the turn of the century. Alakzi (talk) 15:24, 7 July 2015 (UTC)
It's an interesting dilemma: a user script would get it sooner for me, but this seems like something that would benefit most users, but they won't get that benefit if they have to know about a script to install, so seen that way it's better to request it in core -- but that will probably delay my getting it. So should I go for my own selfish insterests, or the greater good? EEng (talk) 15:30, 7 July 2015 (UTC)
Yeah, I thought of that too, but how much you want to bet, if there's a user script available,, that implementing it in core gets deferred because "there's already a user script for people who want this". Honestly I'm amazed this feature wasn't in there from the very beginning -- it's such an obviously important special case. In fact, it really ought to be integrated into the overall grammar of bullets, arrows, bolding, coloring, and so on of the watchlist, since the idea is to help people filter out the unimportant (including the null) and focus on actual changes they care about. EEng (talk) 16:39, 7 July 2015 (UTC)
Part of the reason I brought it up is I have the impression that stuff's being changed right now (or maybe I just haven't been looking closely for a while). How do we get the right person's attention? EEng (talk) 16:51, 7 July 2015 (UTC)
I'm thinking about how to implement something so that we could visually identify net-null pairs in revision lists. The SHA-1 hashes from the API make the comparisons trivial, but I'm not sure how best to represent the results of the comparisons in the revisions list. In particular, two problems:
I'm not sure how to model cases like back-and-forth reverts. For instance, if we had a case where the unique hashes were [A,B,C,B,C,D], in order with "D" the most recent hash, how should I show the relationships between both the two "B" revisions and the two "C" revisions? My first thought was a "layered stripes" system with lines linking the first, last, and any middle instances of matches, but that could easily end up with as many as n⁄2 layers for n revisions (or more? Haven't thought it through…) with obvious nonideal ordering like [A,B,C,D,C,B,A] or [A,B,A,C,B,D,C,D], so it's probably not a good design.
I'm not sure how to represent pairings visually. I want to do it in a way that a) avoids modifying the revision list much, for compatibility and such and b) doesn't rely on colour if possible (using it is OK, but ideally it wouldn't be necessary for comprehension).
I'll think about it some more, but input would be helpful to solve or sidestep those problems. There's got to be something more elegant, but I'm tired and it's escaping me. {{Nihiltres|talk|edits}}06:12, 11 July 2015 (UTC)
Thanks for taking this on! I think the more complex output you're envisioning would be great if we could find an elegant format, but it still might be best left to the future. As a first cut I think the most bang for the buck comes from just comparing the start and end hashes for "today" (corresponding to the two versions from which the size difference is computed) and if they're the same, changing (0) to () as someone suggested above (assuming no one sees a compatibility problem with that). BTW, if retrieving the hashes is a separate step from retrieving the sizes, then we can skip getting the hashes in the very common case that change-in-length is not 0.
I thought about "unbolding" when hashes match (and certain other conditions hold) but it starts to get not so clear what should happen when there have been changes over more than one day, when the user has visited sometime in the middle of today's sequence of changes, etc. I'll give some thought to an "ABC"-type interface you're proposing but for now I wanted to get the above posted. EEng (talk) 00:58, 12 July 2015 (UTC)
The problem I see for the watchlist version of the idea is that I don't see a good plan for selecting the old version would be for comparison. The ideal would be to get revision IDs based on the last visit, probably based on whatever the "updated since your last visit" system uses, but I don't see a way to do that. Another way is to select some relatively arbitrary date in the past and then pull revision hashes from then, which would likely give inconsistently useful results. Alternatively, I could rig up some system to store "most recent revisions on last visit" locally, but that seems really flaky for a whole bunch of reasons. Another idea would be to simply check the previous 10 or so revisions of each page for identical hashes and add some note or other about the timestamp of the matching hash, but that'd be really inefficient, especially for large watchlists.
My idea was more to augment the history pages, because seeing net-null pairs would be really useful and be a useful model for improving history pages (and thus probably also the watchlist) in MediaWiki proper—I don't think the watchlist idea is useful right now. The catch is, as I mentioned above… the problem of how to lay out the results sanely. Does my line of thinking make more sense now? {{Nihiltres|talk|edits}}17:48, 12 July 2015 (UTC)
I missed where you said revision lists -- sorry. That's an interesting idea, but if you'll excuse my selfishness I'd like to stick with the watchlist idea for a minute, because it's really quite simple. The hash comparison is meant to check for a special case of the (0) length-change indication i.e. the special case where, not only did the length not change (net), but nothing at all changed in the byte image of the article source (net). The the versions to be hash-compared are precisely the same as the two versions whose lengths were subtracted to produce the length-change i.e. the version at the end of "yesterday" (how ever that's defined -- UTC and so on) vs. the current version.
The intent is simply to ameliorate a frequent nuisance: a little-edited article pops up on your watchlist. It has two changes, and the net length-change is (0). Now, that almost always turns out to a vandal's edit followed by someone's reversion, and so it's tempting to just assume it is indeed that. But to really tell, you have to hover over the 2 changes and wait for the diff popup, which is annoyingly slow, not to mention inefficient for everyone. As a result, I usually just assume the net change is null, and don't check.
It's not a big deal, but it bugs me. This feature would make it immediately obvious when the net change is null, because the summary line for the article will show () instead of (0). With these clarifications wouldn't htis be pretty easy to do?
If this ever gets implemented, it would be nice to have an option to have no-net-effect changes just not show up at all in the watchlist. More room for the actual changes. Regards, Orange Suede Sofa (talk) 19:41, 12 July 2015 (UTC)
I thought about this (a similar idea is to "unbold" the article) but you run into a lot of problems about what to do when e.g. the last visit was somewhere inside today's sequence of edits. EEng (talk) 22:44, 12 July 2015 (UTC)
@EEng: If I simplify it down to "last 2 changes are net-null" it'd be workable, but probably >90% of the time it'd be redundant to a revert's edit summary. I'll toy around with some code for now and keep you updated. {{Nihiltres|talk|edits}}01:56, 13 July 2015 (UTC)
No, not the last two changes! (That was just an illustration I gave.) What we want are the two changes on which the net size difference is based i.e. the first and last change today. Do you understand what I'm saying? Otherwise, it doesn't make sense to change (0) to (). EEng (talk) 04:47, 13 July 2015 (UTC)
Uh, aren't all the size differences displayed just from the most recent (single) edit? Either way, I don't see an efficient way to do that through the API. {{Nihiltres|talk|edits}}16:02, 15 July 2015 (UTC)
We're obviously talking at cross-purposes here. Could we discuss this via IRC? I have no idea how to do that, but this would be a good time to learn. EEng (talk) 18:56, 15 July 2015 (UTC)
I have scheduled File:Chen Rong - Nine Dragons.jpg for POTD on August 3. The work is supposed to be viewed from right to left, and in the article proper the template is coded to do so:
{{Panorama
|image = File:Chen Rong - Nine Dragons.jpg
|height = 230
|alt =
|caption =
|dir = rtl
}}
I've been using AWB to add missing commas to month-day-year-formated dates that appear in the middle of sentences. At present, I'm focusing on the 20th century, so my search parameter is insource:/[yhletr] *[1-3]?[0-9], *19[0-9][0-9] [a-z]/. If I search for this parameter using the site's native search engine, I get some number of results, typically between 800 and 1100. If I run the same search through AWB, I get 1049 results added to my list, and when I've edited them all I can get 1049 more, which implies that the number of relevant hits may be very large. Is there a reason that the built-in search would return only an inconsistently sized subset of search results? Is there any efficient way to find the true total number of matches so that I can get a sense of the scope of my undertaking? Cheers, —jameslucas (" " / +) 12:56, 22 July 2015 (UTC)
Probably because regexp's on all the content we have are a VERY expensive operation. So expensive, that some users (possibly AWB users doing things similar to you) actually brought the entire search cluster down, and seatbelts had to be installed to protect everyone. You might have run into one of the seatbelts. If you want to do efficient searches, you should use something on toollabs that talks to local copies of the database and is built specifically to do this. Quarry does this for SQL queries for instance. I'm not sure if there is a tool that does it for source text matching. Regardless, it will probably be slow :) —TheDJ (talk • contribs) 16:40, 22 July 2015 (UTC)
AWB can use regexps to search within a downloaded database dump. A query such as yours would take about an hour to run on my laptop. I'd offer to run it for you, but my latest download is about two months old so the results would be out of date. -- John of Reading (talk) 16:53, 22 July 2015 (UTC)
I think we're on the right track. I revised my search to ", 19" insource:/[yhletr] *[1-3]?[0-9], *19[0-9][0-9] [a-z]/, since (if I understand correctly) the first search term is easier to search and therefore removes many, many hits before they are subjected to the regex term. I got ~1600 hits, which I suspect means I managed to get more searches in before I triggered a "seatbelt". John of Reading, would you be willing to run the query on the out-of-date dump? I'm looking for an order of magnitude more than anything. The machine I have available has only a small solid-state drive and I can't handle the dump myself. Most appreciatively —jameslucas (" " / +) 17:17, 22 July 2015 (UTC)
@JamesLucas: Your first "insource" here includes the comma, so it matches articles containing, say, "May 6, 1921". These are the ones that don't need correcting, is that right? I aborted the scan after it found the first 1,000 articles; it was going to find about 30,000 in all. I've begun a scan for [yhletr] *[1-3]?[0-9] +19[0-9][0-9] *[a-z] which is heading for about 1,000 articles; I will post them in a sandbox somewhere when it is done. -- John of Reading (talk) 17:59, 22 July 2015 (UTC)
On July 14, 2015,a Wikipedian operating out Brooklyn, New York,began a tiny crusade against missing commas.
I wrote the example to the right when discussing the work with The Quixotic Potato the other day. The commas between the month and the year and the city and the state are usually present, and when they're not, they're picked up by a number of other methods—rules in AWB, bots, mindful editors. The commas after the year and the state are often missed, and they're the ones I'm going after. Thanks so much for the anaylsis! 30,000 is in line with my expectations. —jameslucas (" " / +) 18:26, 22 July 2015 (UTC)
No doubt, simplifying the criteria can prolong the search before the safeguards clamp down. I'll certainly be tempted to spend time improving the parameters, but I'll try to remember that the edits are the true and (comparatively) meaningful objective! —jameslucas (" " / +) 02:37, 23 July 2015 (UTC)
The numbers are changing for some reason you have to discover. I'm not primarily addressing that, (although I believe most regexp searches can always be improved). I'm encouraging you to discover some reasons. But it can't be the regex engine's safeguards throttling down the user's observed "number of matches" (shown to the far right of the search box query). The entire search domain must be searched every time and the full quantity always reported, or else how could one set a search domain (using a namespace or a prefix) from one query to another? — CpiralCpiral03:15, 23 July 2015 (UTC)
To see the error, go to the page and click on the team column to sort alphabetically. The error will pop to the top. I looked at the entry for Julie and didn't see anything wrong with it. I thought it might be a problem in the template above the Southland template, and I thought I found a problem in it and fixed it but that did not solve the problem.
I tried re-creating the entry for Julie by copying another entry and bring in the information for Julie. Oddly that corrected row now appears as a second row but I don't know where the first row is coming from.--S Philbrick(Talk)16:01, 22 July 2015 (UTC)
thanks for the quick response. I thought I looked there, but sometimes with this sequence of templates the problem is in the preceding template and I found a problem there which I fixed so assume that was it. I now see a problem with the Mountain West but I think I can fix it--S Philbrick(Talk)16:16, 22 July 2015 (UTC)
Change the "Edits by user" external tool link
Clicking on the current link goes to a page that says that the tool is defunct and that this tool [25] should be used instead. Can the link on Wikipedia history pages be changed to this one? Gparyani (talk) 21:02, 22 July 2015 (UTC)
Oh, and it doesn't prefill the "page" field with the page I came from when clicking on the link to go to the new one. Can that be fixed? Gparyani (talk) 21:06, 22 July 2015 (UTC)
Private incident reporting and tracking system for admins
First of all ANI/Incidents is currently the most frequently edited page. Second of all, it seems that it's possible to report things privately to arbcom, but not to the administrators as a whole. There's a number of pros and cons to having a private means to report incidents to administrators. There's two potential approaches, one is all admins having access to this tool, a second is only admins IDed to WMF have access.
Pros:
Good for shy editors who aren't comfortable drawing attention to themselves.
Good for issues that editors might be uncomfortable bringing up in public, such as sexual harassment.
Would make ANI/Incidents less of a huge mess.
Would reduce burden on arbcom potentially, as minor issues regarding some privacy wouldn't have to go through them.
Less drama, canvassing opportunities, etc.
Might be good for other language wikis, that may have different cultures regarding reporting incidents.
Most other websites have a means to privately report issues to administrators, so it's what many people are used to.
Might make the lives of admins easier, as a wiki is not an ideal issue tracking system.
Cons:
Potential legal issues if admins not identified to WMF have access. Editors might assume issues reported privately to administrators is private information, even though such information is not legally.
Potential off site drama with wp admins with ill intent leaking private incident reports.
Potential for misuse (like any new tool).
Might make ANI/Incidents (which this would certainly not replace) get less admin attention.
Personally I'd support such a tool, as it would be tremendously helpful to editors who might have difficulty "raising their voice" so to speak. --ScWizard (talk) 17:43, 22 July 2015 (UTC)
Having some concern about such a tool attracting a lot of reports that don't need to be private or don't need to be targeted at administrators. That's my expectation based on reports I handle on other websites, for the record. Jo-Jo Eumerus (talk, contributions) 17:49, 22 July 2015 (UTC)
A report that doesn't need to be private, but also doesn't need to be public, would be more quickly resolved through a proper incident tracking system than through a wiki, I think. As for reports that don't need to be targeted at admins, you're right that there are likely to be reports in the fashion of "this article is wrong!!!" by individuals who are completely unfamiliar with wikipedia. However such a report might give the wiki an opportunity to engage people who wouldn't think of editing the wiki otherwise. --ScWizard (talk) 17:56, 22 July 2015 (UTC)
There are experienced editors who are active on ANI but who are not administrators. Any change that hides the sort of cases we see on ANI from those editors denies Wikipedia a useful tool for dealing with abuse. --Guy Macon (talk) 20:49, 23 July 2015 (UTC)
French Wikipedia has Global contributions Special page
I just noticed that French Wikipedia has the Special:CentralAuth tool which allows you to query user contributions and rights across all Wikimedia Projects. See for example: https://fr.wikipedia.org/wiki/Sp%C3%A9cial:CentralAuth/Sadads . Is there a reason we don't have this implemented? Can we implement it? It would be insanely useful for things like whether to ping someone else on another wiki, checking whether to give editors rights or when blocking editors, for WP:The Wikipedia Library screening if editors have sufficient contributions to qualify for partnerships access, etc. I can't think of a reason not to have it enabled. Sadads (talk) 20:30, 22 July 2015 (UTC)
Nevermind on not having it, I must have had a typo in trying to find it. However, we don't link it anywhere obvious (for example at the top of Special:Contributions/Sadads). It seems silly to be sending users to meta, without a significant difference (its probably really disorienting for English only contributors). Moreover, I seem to remember a ton of different templates linking to this tool, which is always clunky and slow, but not to CentralAuth. Could we add it to the top of Special:Contributions? And I didn't even know that box was at the bottom of Special:Contributions. Is there a way we could move that up the page, make it discover-able --- it seems like a lot of valuable information that shouldn't be hidden at the bottom of the page (maybe a side bar on the right?). French Wikipedia has it in a bunch of different default user templates. I will try to find some of the templates (like Template:User8 where we could make Special:CentralAuth more visible, instead of sending users to an outside tool), Sadads (talk) 23:14, 22 July 2015 (UTC)
Based on uselang=qqx an alternative placement on user contributions would be the currently blank MediaWiki:Contributions-summary which is displayed above the "Search for contributions" box at Special:Contributions/Sadads. That is probably too prominent. MediaWiki:Sp-contributions-explain is displayed inside the "Search for contributions" box but that place should probably only be used for a help link like now, or information about the fields in the box. The names "Contributions-summary" and "Sp-contributions-explain" also hint that the messages aren't intended for something like this. The French Wikipedia [27] uses MediaWiki:Sp-contributions-footer at the bottom like us. I think that is the best. PrimeHunter (talk) 23:42, 22 July 2015 (UTC)
@Sadads: The reason for linking to Meta's version of Special:CentralAuth instead of ours is that only Meta's version shows log entries for global account actions (like locking). Jackmcbarn (talk) 19:59, 23 July 2015 (UTC)
Sadads, for your purposes, I think that you will benefit from adding some popular user scripts to your account. Here's my list of recommendations, complete with the code you need to add them to your .js file:
// Gives some useful links on user, user talk, and user contribution pages
// by [[m:user:Hoo man]] <http://meta.wikimedia.org/wiki/User:Hoo_man/Scripts/Useful_links>
mw.loader.load('//meta.wikimedia.org/w/index.php?title=User:Hoo_man/useful_links.js&action=raw&ctype=text/javascript');
if(typeof(usefulLinksConfig) == 'undefined') usefulLinksConfig = {};
usefulLinksConfig.toolLinkMethod = 'p-cactions';
// Useful script to tell if a user is currently blocked, by striking out the username
mw.loader.load('//ru.wikipedia.org/w/index.php?title=MediaWiki:Gadget-markblocked.js&action=raw&ctype=text/javascript');
// [[File:userinfo.js]]
mw.loader.load('//wiki.riteme.site/w/index.php?title=User:PleaseStand/userinfo.js&action=raw&ctype=text/javascript');
Just paste that into m:User:Sadads/global.js and reload the page to run it. You will then have quick access to links on all user pages via the "More" dropdown menu that normally houses only "Move" (CentralAuth will be listed as "CA"), a visible indicator if any person is blocked (on any page, every time the user page is linked), and a list of user rights, account age, number of edits, and how recently the editor has edited on all user pages, immediately underneath the page title. Also, if you add it to your global.js page at Meta, it should work on all the Wikipedias. That should save you a bit of time. WhatamIdoing (talk) 19:08, 23 July 2015 (UTC)
Wikipedia:Dispute resolution noticeboard/request not working
Java and JavaScript are unrelated (yes, the similar names are confusing, not our fault). JavaScript comes with the browser but may be disabled. Do you have a [show]/[hide] to the right of "Contents" at #toc? That also requires JavaScript. PrimeHunter (talk) 21:03, 22 July 2015 (UTC)
@Debresser: Can you check if the "Form for filing disputes at the dispute resolution noticeboard" option is enabled in your preferences under gadgets? - NQ(talk)22:18, 22 July 2015 (UTC)
I would just like to draw Wikipedians attention to the way the page view statistics are presented. In each and every Wikipedia page one would click 'View history', then 'Page view statistics' and he will get the statistics page. Now, the headline reads - '(Wikipedia page) has been viewed xxxxxx times in the last 30 days. (and, for 10,000 Wikipedia pages, also - ) This article ranked xxx in traffic on wiki.riteme.site.'. One may get the wrong impression
that the ranking is an all time one. As I understand it, the ranking is merely the page's rating for the month of March 2014 (see the figures here). This can be a bit misleading.
Yes, the rank is only for March 2014, for example for http://stats.grok.se/en/latest/Malaysia_Airlines_Flight_370 which disappeared that month and peaked in page views there. http://stats.grok.se is made and controlled by a single volunteer editor who can be contacted at User talk:Henrik but hasn't edited since August 2014. The editors of the English Wikipedia have decided to link the tool in page histories but it's not an "official" tool run by the Wikimedia Foundation which runs Wikipedia. PrimeHunter (talk) 16:43, 23 July 2015 (UTC)
Proposal to create PNG thumbnails of static GIF images
The thumbnail of this gif is of really bad quality.How a PNG thumb of this GIF would look like
There is a proposal at the Commons Village Pump requesting feedback about the thumbnails of static GIF images: It states that static GIF files should have their thumbnails created in PNG. The advantages of PNG over GIF would be visible especially with GIF images using an alpha channel. (compare the thumbnails on the side)
The associated feature was not popular at Wikipedia:Village pump (technical)/Archive 136#Edit Tags. The English Wikipedia has no tags which can be manually added or removed, but I think admins could create such tags. The tag log would show when users added or removed the tags. Special:Log/tag is empty but fr:Special:Log/tag is not. French history pages like [28] have buttons saying "Edit tags of selected revisions". Apparently the only such tag they currently have is called "Test balise" which means Test tag. I don't know whether they use it for anything other than just testing the feature. PrimeHunter (talk) 01:55, 23 July 2015 (UTC)
Check out Realm of Impossibility, look especially at the references. Although it seems I am using the same format for the cite tags throughout, some of them render the pages as if they are the "issues", with a colon. Any ideas? Maury Markowitz (talk) 16:51, 24 July 2015 (UTC)
the template is {{cite journal}}, which for as long as I can remember (six years) has never displayed "p." or similar before page numbers. Note that issue numbers differ from page numbers in that they get parentheses -
So is the ":12" the expected outcome? It seems odd compared to what we want from an sfn. Is there any reason for this difference? Maury Markowitz (talk) 21:49, 24 July 2015 (UTC)
I read the "In-source locations", and it seems to suggest p. 12 is the expected outcome? What am I missing here? Maury Markowitz (talk) 21:54, 24 July 2015 (UTC)
The things that are missing are |volume= and |issue=. {{cite journal}} is 'optimized' for academic journals which usually include both of those parameters:
{{cite journal |author=Author |title=Article title |journal=Prestigious Journal |volume=1 |issue=2 |page=25}}
Author. "Article title". Prestigious Journal. 1 (2): 25. {{cite journal}}: |author= has generic name (help)
In the example, the numbering flows largest element to smallest and is consistent with how academic journals identify pages in a journal issue.
For the case of ROM Magazine, the value in |url= shows that these citations are to articles in issue 4 (no volume that I can tell) so adding that bit of information to the template:
{{cite journal |url=http://www.atarimagazines.com/rom/issue4/interview.php |title=Interview: Mike Edwards |journal=ROM Magazine |date=February/March 1984 |page=12 |first=Peter |last=Ellison}}</syntaxhighlight> which displays as
::{{cite journal |url=http://www.atarimagazines.com/rom/issue4/interview.php |title=Interview: Mike Edwards |journal=ROM Magazine |date=February–March 1984 |issue=4 |page=12 |first=Peter |last=Ellison}}
There has been some discussion at Help talk:Citation Style 1 about tweaking the way {{cite journal}} renders page numbers so that when |volume= and |issue= are not provided, Module:Citation/CS1 uses the p. and pp. prefixes.
I think it's been a month since I have been seeing this kind of problem with mobile wikipedia version. I have seen seen this kind of problem in the beginning of this year but all went normal after some time but now the problem is as it is for about a month.
Now the problem is that the edit button (that looks like a pencil) is not coming on any mobile Wikipedia page (though the same thing is not happening in desktop mode). I am logged in with Wikipedia and I tried clearing cache but all was useless. Then I checked the same thing on other browsers n the same thing happened again on ucmini and ucbrowser and chrome also.
After this I faced the same problem with another phone.
I think it's a bug in Wikipedia s mobile site. (Anyone else is facing the same problem??)
Also, what kind of browser are you using when accessing the mobile website... Perhaps it doesn't support SVG or something, causing the images not to show ? —TheDJ (talk • contribs) 11:05, 20 July 2015 (UTC)
Surely SVG images are always converted to PNG server-side, because not all browsers support them? For example, this image appears in the <img /> tag as src="//upload.wikimedia.org/wikipedia/commons/thumb/8/84/Example.svg/20px-Example.svg.png" --Redrose64 (talk) 16:47, 20 July 2015 (UTC)
The pencil icon that forms the "edit" links in the mobile skin is actually directly shown as an SVG for me (Chrome). It is added by the following CSS rule, which seems to be added to the page using JavaScript (it is not visible using "View source", only with the "Inspect element" tool):
I'm guessing the background-image property is set to four different values to let it fall back to the last working one if any variation is not supported by the used browser. An SVG file with code directly embedded on the page (replaced with a comment here) is used in two cases, and a PNG version from a different page in the other two. SiBr4 (talk)17:51, 20 July 2015 (UTC)
Please let me know your device, operating system and browser (including version) that you are using and I will look into this. Jdlrobson (talk) 00:18, 26 July 2015 (UTC)
So what does that mean? We no longer can add photos? Someone is working on the problem? I should not upload the other 4 I wanted to because they won't work either? SusunW (talk) 22:37, 24 July 2015 (UTC)
At the moment it appears that there is some sort of thumbnail generation problem on wiki.riteme.site for recently uploaded files (you saw yourself that displaying full size images is fine). German Wiki etc and Commons do not appear to have the same issue. You can continue to add photos. You can continue to upload them. We don't know if anyone is working on the problem. Also, you may find it useful to follow the {{infobox person}} template instructions and change the syntax of your image additions in the infobox (and add the image_size parameter) so that they will display properly when the problem is resolved or passes. E.g. change
| image = [[File:Ana_Rosa_Tornero.jpg|thumb|right|Ana Rosa Tornero in ''[[Wara Wara]]'' (1930)]]
| alt =
| caption =
to
| image = Ana_Rosa_Tornero.jpg
| image_size = 200px
| alt =
| caption = Ana Rosa Tornero in ''[[Wara Wara]]'' (1930)
(image size is a guess at what may be suitable) Hopefully tech are looking at the underlying issue already. Nanonic (talk) 23:03, 24 July 2015 (UTC)
with or without the thumb notices they don't work. If you leave off "file" all together, the photo took up almost the entire page. And I see that RedRose was trying to get it to work and now it shows no image even without "file". No point in spending a lot of time with "what if" parameters. They may not need any adjustments if they fix the problem. If I upload fair use images, and they don't fix the problem quickly I'll have to do it again because they'll be deleted for not being tied to a file within 7 days. I'll just save the links and see if it works later. Thanks! SusunW (talk) 23:23, 24 July 2015 (UTC)
As an additional data point, seen here, some |upright values work while others break the thumb. My default thumb size is 220px; changing it to 300px causes different upright values to break the thumb. This image was uploaded in 2007. ―Mandruss☎04:11, 25 July 2015 (UTC)
Added tests of fixed px values. For me, 300, 270, 250, 240, 220, 200, 180, 150, and 120 work; 290, 280, 260, 230, 210, 190, 170, 160, 140, and 130 do not. But File:Sands Hotel 1950s.jpg fails at 250, so apparently all of that is image-dependent. ―Mandruss☎09:13, 25 July 2015 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I have tried twice to upload an album cover to the article Chicago '85... The Movie. While the image and its fair use information does show up properly when it is clicked on, the thumbnail itself appears broken in the article. Anyone know what could be wrong? Erpertblah, blah, blah...04:17, 25 July 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Very possibly related to one or more of the three image-related threads immediately preceding this one. ―Mandruss☎08:17, 25 July 2015 (UTC)
I thought originally it was a glitch with one of the photos I uploaded so I tried another one and it did the same thing! It won't even show when not in the infobox either. Strange. Hope it's fixed soon!♦ Dr. Blofeld08:38, 25 July 2015 (UTC)
Hello, I could use some help with table formatting in List_of_mayors_of_Bremen please. It's a bit hard to describe, but I'll try: Look at the last 2 rows about Jens Böhrnsen and the new mayor Carsten Sieling. The 2nd Mayor Karoline Linnert will probably stay in office (per the German senate site). So I would like to display Karoline Linnert's data in 2-row columns stretching over both 1st Mayors (as she was 2nd Mayor with both 1st Mayors). If A are all columns for a 1st Mayor (the first 4 columns) and B are all columns for a 2nd Mayor (the last 4 columns), I want something like:
A1 B1
A1 B2
A2 B2, where A1 and B2 should only be 4 single boxes stretching over 2 rows. I have tried fiddling with rowspan (in preview mode) but failed. Are such alternating, "overlapping" 2-row columns possible in Wiki-tables? GermanJoe (talk) 15:17, 25 July 2015 (UTC)
@TheDJ:I think, the problem occurred when I tried to remove the last split as well (sorry for missing that detail). I simply removed the last empty cell descriptions, and then the formatting broke somehow. Would you mind removing the last split too please (the last 4 small empty cells)? Aside from that, it is exactly what I looked for. GermanJoe (talk) 15:41, 25 July 2015 (UTC)
(tested again). Deleting the last 4 cell elements is indeed my problem. It breaks the display of Karoline Linnert's cells - they no longer extend across 2 rows afterwards. GermanJoe (talk) 16:17, 25 July 2015 (UTC)
Yeah, that worked (I added the pseudo column at the beginning just to be sure). Many thanks to both of you for your help. GermanJoe (talk) 17:57, 25 July 2015 (UTC)
... and the Navboxes only showed in desktop mode. I know navboxes are not suppose to "appear" when printed out (class="noprint") but I doubt that has anything to do with them not rendering in 'Mobile Mode' (if they ever did that is as Redrose64 pointed out). -- George Orwell III (talk) 23:28, 25 July 2015 (UTC)
It's by purpose. The majority of navboxes do not render well at by 320px and unfortunately our current tech stack (templates) doesn't make it possible to style them differently on mobile and desktop. Given that on desktop the HTML markup associated with navboxes are huge it would be a great idea for us to all rethink them (possibly using JavaScript make them more interactive). Jdlrobson (talk) 00:22, 26 July 2015 (UTC)
Display oddity
In Firefox 39 (current production version) in Win 7, the following, which uses <code><pre><nowiki>, nested in that order,:
<pre> is block, <code> is inline. I keep explaining you cannot nest block inside inline elements (despite what HTML5 allows); MediaWiki (Read: HTML Tidy) does not allow that. Also, <pre> invokes <nowiki> by default, so no need to specify that, unless you want to actually show the tag. -- [[User:Edokter]] {{talk}}15:52, 26 July 2015 (UTC)
Problem on WikiProject Physics page
Screenshot of the problem
Hi. There is an odd problem on Wikipedia:WikiProject Physics. Some flag colored yellow, red and green floats over the content in the "Current status of physics articles" section. I am using Google Chrome 44 under Windows 8 with Vector skin. --Meno25 (talk) 15:24, 26 July 2015 (UTC)
The log is [31]. The page history of the target [32] also shows it twice, with consecutive page revisions 669814688 and 669814689. I guess it's just a glitch. PrimeHunter (talk) 02:05, 23 July 2015 (UTC)
"Just a glitch" is usually what comes back in a few months or years as "OMG, I wish we'd fixed that problem when we first noticed a symptom. All the best: RichFarmbrough, 00:27, 27 July 2015 (UTC).
DIFF highlighting glitches ?
Not sure if this is a glitch or not. My personal opinion is that this is a logic flaw in the diff engine.
GLITCH DESCRIPTION:
Adding an inline citation immediately after an existing inline citation results in a flawed diff highlight as follows:
ORIGINAL:
article text blah blah.<ref>{{cite ...|ref=ALPHA}}</ref>
EDITED:
article text blah blah.<ref>{{cite ...|ref=ALPHA}}</ref><ref>{{cite ...|ref=OMEGA}}</ref>
INTUITIVELY WHAT SHOULD BE HIGHLIGHTED:
article text blah blah.<ref>{{cite ...|ref=ALPHA}}</ref><ref>{{cite ...|ref=OMEGA}}</ref>
REALITY OF WHAT IS HIGHLIGHTED:
article text blah blah.<ref>{{cite ...|ref=ALPHA}}</ref><ref>{{cite ...|ref=OMEGA}}</ref>
ALTERNATELY -- This is also true if you insert a new citation in the middle of multiple existing citations:
article text blah blah.<ref>{{cite ...|ref=ALPHA}}</ref><ref>{{cite ...|ref=OMEGA}}</ref><ref>{{cite ...|ref=DELTA}}</ref>
HOWEVER -- The diff highlighting is correct if you insert the new citation BEFORE any existing citation(s).
article text blah blah.<ref>{{cite ...|ref=OMEGA}}</ref><ref>{{cite ...|ref=ALPHA}}</ref>
Diff isn't an exact science, and in my experience Wikipedia's implementation frequently highlights unintuitively. I wouldn't hold much hope that this can be resolved, except by grafting on some ugly hack, which probably would not be well-received by the developers.--Anders Feder (talk) 15:39, 23 July 2015 (UTC)
I believe that the diff feature starts at the right-hand end of the line and works towards the left. So when adding a <ref>...</ref> after one that is already there, the diff feature notices that each line ends with a </ref> which is considered to match. Then as it works its way to the left, it will come across another </ref> on the later version which is considered not to match, so it gets the highlight. --Redrose64 (talk) 08:37, 24 July 2015 (UTC)
I actually can't see what you mean in the above example. A smarter diff would certainly recognise where delimiters package entities and match for example "<<bar>> " instead of "bar>> <<" in the following, assuming that "<<bar >>" had been inserted.
Hi there, is anyone aware of any tool (or possibly willing to make one) that would dim/remove references from view upon command while looking at a diff?
In these edits I'm interested in seeing what the net change to the prose was in the big blue block, but with all the long references, it's difficult to read the prose and see what changed. I'm thinking of something like WikEdDiff that, with a press of a button, would turn anything between <ref></ref> tags light gray or something. Naturally this would have no effect on the article. It would only affect what a user sees on their screen. Thanks. Cyphoidbomb (talk) 16:34, 24 July 2015 (UTC)
Was thinking about related script (feel free to move this to new section). When somebody moves a text lower for some rows and makes some other changes in that text, in diff window you can't see what really has been done in that text, because it only shows you that whole paragraph or so has been moved somewhere else (specifically, some rows up or down). I think I'm not the only one, who would like to know, what else has been done in that edit. I could really live with the fact, that I can't see in diff window, that text has been moved, just show me the real changes in the text. Mission impossible (such script)? --Edgars2007 (talk/contribs) 10:19, 25 July 2015 (UTC)
Hi all,
I mostly translate articles from other wikis into English and templates are the bane of my life. I was wondering if anyone could explain how I should perform a particular translation. The German version of the coord template can be made to produce a map (see an example here: de:Felsrelief von Fıraktın ). Could anyone suggest how I might get the same effect on English wikipedia?
Cheers,
Furius (talk) 13:40, 25 July 2015 (UTC)
The German code is {{Coordinate |article=/|map=left|maptype=relief|name=Fıraktın|NS=38/16/18/N|EW=35/37/54/E|type=landmark |region=TR-38}}. A similar map can be made by {{Location map}} with some work. Here I used:
I went through 's-Hertogenbosch on my way to Liège many years ago, but the name has nothing in common with Arabic names. I will take your advice on that name.--DThomsen8 (talk) 22:32, 26 July 2015 (UTC)
User:Green Giant doesn't exist: I get the little "View or restore 4 deleted edits?" link at the top, just as I do with a previously deleted page that doesn't currently exist, and the tabs at top say "Create this page" and "undelete 4 edits" instead of "edit this page" and "history". All very nice, except for the obvious fact that the page exists! All the links go directly to Commons, and it's identical to Commons:User:Green Giant. Has some software weirdness happened, or am I just unaware of a new feature/bug that transcludes your Commons userpage if your en:wp userpage doesn't exist? Nyttend (talk) 15:35, 26 July 2015 (UTC)
Hehe, aye it is the global user page; if you don't have a user page on any particular wiki, it will show whatever is on your Meta user page, but your user talk pages are not affected. When it became operational, I requested deletion of several of my user pages on other wikis because I want to migrate from being a Wikipedian to being a Wikimedian. The ENWP and Commons user pages were more complex so I didn't get round to getting them deleted until yesterday. I believe there will also be global notifications and watch-lists in the future. Green Giant (talk)19:47, 26 July 2015 (UTC)
Wikipedia File Upload Wizard (Fair use files)
I would like to ask two questions about the Wizard, specifically the non-free files form, and more specifically: Step 3 > “This is a copyrighted, non-free work, but I believe it is Fair Use.” > “This is an historic portrait of a person no longer alive.”
A) Why am I able to confirm that “the image will be shown as a primary means of visual identification at the top of the article dedicated to the person in question” by simply ticking a box, but I have to write a text “explaining” that “a free alternative to this image cannot be found”, “our use of the file will not harm any commercial opportunities of its owner” and “the use of this file will be minimal”? The third one, especially, could be very easily replaced by a box-to-tick.
Β) Why is the Wizard sequence Free alternative-Commercial opportunities-Minimal use while the Non-free rationale template sequence is Free alternative-Minimal use-Commercial opportunities?
I suppose you can always write "✔" in the text box. But I think our fair use policy could do with a slightly more liberal overhaul. All the best: RichFarmbrough, 12:46, 27 July 2015 (UTC).
I always add the same text. It looks, however, like an attempt to train editors to write creatively, which would be laughable
Recently the Wiki search page has been spoilt, by adding a migraine headache in the search box and a promiscuous drop down menu. I've tried to stop it by altering the settings in Preferences to no avail, can anyone help please.Keith-264 (talk) 11:58, 27 July 2015 (UTC)
Which skin are you using? (It seems relatively unchanged to me, though I see from comments above it has some regex ability.) All the best: RichFarmbrough, 12:43, 27 July 2015 (UTC).
Oh you mean the search box? Yes that dropdown that hides the search key is sometimes irritating, but also sometimes useful. The Migraine - maybe someone can offer some css to turn that off? All the best: RichFarmbrough, 13:29, 27 July 2015 (UTC).
The post is about the big search box at Special:Search and not the smaller box on all pages. In Firefox, each time I type a character in the big box I briefly see annoying flickering tilted grey lines in the whole box. The drop-down with search suggestions is bigger and more attention seeking than for the small box, and it covers "Multimedia Everything Advanced" so I have to click somewhere else on the page before I can use those options. "Disable the suggestions dropdown-lists of the search fields" at Special:Preferences#mw-prefsection-gadgets works on the small box but not the big. PrimeHunter (talk) 13:34, 27 July 2015 (UTC)
It's not the little one at the side of the article page (that's annoying enough) but the big one on the page that the search goes to if there isn't an obvious wikipage. The drop down is never useful and the pattern in the box comes from the imagination of a !"£$%^&*(). Don't the people who do these things ever ask first?Keith-264 (talk) 13:38, 27 July 2015 (UTC)
Is there any way to disable this feature altogether? For eg. if I intend to search in Special:Search for Lorem, it fills in Lorem Ipsum by default when I press the Enter key to search. I'd have to press the Tab key and then the Enter key every time to get the desired search query which is really cumbersome. NQ-Alt (talk) 14:20, 27 July 2015 (UTC)
I don't suppose Wiki will force anyone who changes it to add a "change it back" button to every change? That would be useful.Keith-264 (talk) 14:25, 27 July 2015 (UTC)
Is there a tool that can quickly convert multiple instances of [https://wiki.riteme.site/wiki/Article_title Article title] to proper wikilinks? (Asking again here as I got no joy at the HD.) Roger (Dodger67) (talk) 13:33, 27 July 2015 (UTC)
It sounds like user:js/urldecoder does what you want. You could also use the find and replace tool on the right side of the Advanced menu of the edit toolbar: paste \[((?:https?:)?\/\/en\.wikipedia\.org\/wiki\/.+?) (.+?)\] into the search box and {{subst:u2w|1=$1|2=$2}} into the replace box, and check "Treat search string as a regular expression", and click "Replace all". This replaces all external Wikipedia links with {{subst:urltowiki}}, which converts them on page save. /~huesatlum/ 14:22, 27 July 2015 (UTC)
At one time it was possible to use Special:LinkSearch and enter wiki.riteme.site - that facility was removed last year. LinkSearch has recently been altered again, so that it assumes http:// unless you explicitly specify https:// which means that when hunting down spam links, you now need to do twice as many searches as you used to. --Redrose64 (talk) 18:54, 27 July 2015 (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
You can now use redirects to link to JavaScript pages. [34]
There was a problem with some Lua modules on July 22 and 23. Some pages using them did not list them in "what links here". You can fix those pages with a null edit: edit and save the page without making any change.
There was a problem with the abuse filter page on big wikis on July 23. It was due to a code error. [39]
Changes this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from July 28. It will be on non-Wikipedia wikis from July 29. It will be on all Wikipedias from July 30 (calendar).
JavaScript authors: You cannot use wgNoticeUserData to get edit counts anymore. [40]
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs are the most important. The meeting will be on July 28 at 19:00 (UTC). See how to join.
That would be an odd browser feature. Which url did you visit, what is the browser, exactly what does it say in the browser history, and what does it say for a page with more characters like Example? PrimeHunter (talk) 17:13, 27 July 2015 (UTC)
Yes, there is, but it only works on the German Wikipedia for the time being. I'm working on making it work for the english wikipedia, and should have it up and running soon. I will post a link once I have it running.—cyberpowerChat:Online14:17, 18 July 2015 (UTC)
C678, WikiHistory is a poor and rudimentary replacement for the history revision statistics page. As a stopgap it is fine, better to have something than nothing, but work should continue to get the original tool up-and-running again. The process and communication regarding the status of this tool is subpar.--Wolbo (talk) 11:26, 22 July 2015 (UTC)
@Wolbo: You are free to continue work on getting the original tool up-and-running again - you can find the source code here. Other editors have been collaborating to that end at Wikipedia talk:XTools. In the meantime, C678 may dispense his time the way he find most beneficial. If you need anything beyond that you should instead direct your comments to the m:Community Tech team.--Anders Feder (talk) 12:25, 22 July 2015 (UTC)
I'm sorry Wolbo, but there is only so much I can do. For now this will have to do until we can get the code rewritten.—cyberpowerChat:Online14:23, 23 July 2015 (UTC)
This is a different tool that we borrowed for now. We are still working on bringing the original code back up.—cyberpowerChat:Online14:23, 23 July 2015 (UTC)
Good to read that work is proceeding to bring the 'history revision statistics' back to live (that wasn't entirely clear from the communications I read on the subject). Opinions may differ but in my view both the information it contained as well as the way the information was displayed was excellent so hopefully the attempts to get it going again will be successfull.--Wolbo (talk) 22:32, 28 July 2015 (UTC)
Private drafts?
Where are we at with private drafts? Tonight I found myself in need of such a thing (long unfinished reply to a contentious conversation, didn't want to save it in userspace, ended up saving it in an offline text editor). I found this discussion from a few years ago, which pointed to this bug, which looks like it got mired in a bunch of what-if navel gazing. Did this ever get enabled, and if so, how do I use it? Regards, Orange Suede Sofa (talk) 04:23, 21 July 2015 (UTC)
I actually agree that such a thing would be useful, and really a standard part of any modern web-based authoring interface. But, at the same time, the concerns raised in the bug are legitimate. The lack of eyeballs on anything "private" means it is easy for malicious users to abuse.--Anders Feder (talk) 09:53, 21 July 2015 (UTC)
If I have a page that absolutely nobody else can see (and therefore there are no "eyeballs" on it), then how exactly would I go about using it for abuse? I'm trying to understand what "abuse" means when absolutely nobody except me can see the contents of the page. WhatamIdoing (talk) 16:11, 22 July 2015 (UTC)
Sharing the password to my whole account? I don't think that's a realistic scenario. For that matter, there are already opportunities for doing that, at least for short messages. If I wanted to leave you a secret message in my account, I could type it into the sig field in prefs, and then give you the password. But I really can't imagine anyone wanting to go to that much trouble, when free private web boards are so easy to get. Or I could get a free e-mail account from any one of thousands of providers, and do the same thing by saving a draft of an e-mail message. This does not sound like a significant problem. WhatamIdoing (talk) 18:38, 22 July 2015 (UTC)
It depends on the exact implementation, but just consider resource consumption: some sad pubescent kid could probably find great pleasure in making a program that automatically created 700 yottabyte worth of drafts featuring ASCII artlolcats, just for the sake of crashing Wikimedia servers.--Anders Feder (talk) 16:18, 22 July 2015 (UTC)
Really? Do you also have a constant to limit the number of drafts created by each user accounts? And once you have, do you also have a constant to limit the number of user accounts created by each physical person? If so, how do you plan on enforcing it?--Anders Feder (talk) 18:49, 22 July 2015 (UTC)
This particular possible issue aside, wouldn't this just make loads of work for the WMF, who would be the only ones able to patrol these pages for issues related to problematic content on their servers? Sam Walton (talk) 19:02, 22 July 2015 (UTC)
The proposal is for a single draft (per account), not for an infinite number. There is already a system in place that limits the size of a page. There is already a system in place that limits the number of accounts you can create (per computer/IP address during a given time period). Your scenario is definitely implausible.
If nobody can see it except the one logged-in user, then why would the page need to be patrolled in the first place? This feels like "we have to make a note about what color the invisible unicorn is, because we check the color of every animal that can be seen in public!" Well, yes: we do try to check the content of every page that is visible to the public. But this one would not be visible to the public, so why should the visible-to-the-public rules need to be applied to an invisible-to-the-public page? WhatamIdoing (talk) 18:51, 23 July 2015 (UTC)
"The proposal is for a single draft (per account)". Lies. There is no such proposal. And if all concerns raised about the suggestion are "definitely implausible" anway, what are you waiting for? Why don't you go ahead and prod the engineering team to implement it instead of arguing with people here who have no power over the installation anyway?--Anders Feder (talk) 19:38, 23 July 2015 (UTC)
Let me present a more focused scenario. Let's say that I'm drafting some sensitive non-article text; like a response to an RfA or Arbcom thing with lots of diffs. I'm in the middle of doing so and I need to step away for a few hours. I'm not done with my text but I want to save it because I'm putting a lot of effort into collecting and formatting all of those diffs and the power might go off or my browser might crash or whatever. And I don't want to save it in my sandbox because it's not cool to just post stuff concerning other users unless I'm sure it's ready for others to see. Today I have to copy that text to an offline text editor and copy it back later. What I'd like is just a button that says "save draft" and when I come back to the article, I can "resume draft". That's it. No namespaces, no unlimited storage of pictures of my board game collection.
Given that this has been a feature of practically all web-based content systems since forever (webmail, blog software, etc.) the objections presented so far are surprising. For example, I'm pretty sure a script kiddie wouldn't need the draft extension turned on if they wanted to DoS the system. In fact, this scenario happens rarely enough for me that I would be satisfied with being limited to a single draft with a fixed size limit if that addresses some of the concerns. Or a client-side solution, as was proposed. Regards, Orange Suede Sofa (talk) 17:25, 22 July 2015 (UTC)
There isn't anything "surprising". Wikipedia isn't "all web-based content systems". It's a specific system working under its own constraints, and there is no two ways about having to address those constraints if you want to deploy this or any other new feature.--Anders Feder (talk) 17:59, 22 July 2015 (UTC)
What constraints do you have in mind? So far I've heard "nobody has created that yet" and "people might violate the terms of use by posting their account passwords on the web". Neither of these seem especially relevant to the question of whether it might be useful enough, for legitimate purposes, to be worth requesting. WhatamIdoing (talk) 18:38, 22 July 2015 (UTC)
Who have questioned whether it "might be useful enough"? Do you also see the exact words "I actually agree that such a thing would be useful" above or are they something I am imagining?--Anders Feder (talk) 18:44, 22 July 2015 (UTC)
@Orange Suede Sofa: You mention "drafting some sensitive non-article text; like a response to an ... Arbcom thing with lots of diffs" - there was a recent arbcom case where the accused was doing precisely that. It didn't go down at all well. You may notice that they haven't posted to this page for over a month now. --Redrose64 (talk) 19:30, 22 July 2015 (UTC)
Redrose, this is confusing. The editor can't have been accused of "doing precisely that", because "precisely that" is technologically impossible at this point in time. Was the editor accused of drafting a reply in public, i.e., precisely the thing Orange Suede Sofa wants to avoid? Or of drafting the reply offline (which nobody has any business caring about)? WhatamIdoing (talk) 18:51, 23 July 2015 (UTC)
By "doing precisely that" I mean that they were drafting their replies in userspace; that user subpage was quite lengthy, and contained a number of allegations against another Wikipedian which were sufficiently libellous for them to be removed and revdelled very quickly, and not long after were oversighted. --Redrose64 (talk) 08:06, 24 July 2015 (UTC)
This sounds like an argument in favor of having a private space for such efforts. Private notes, unseen by anyone else are never libel. (Libel requires publication.) With luck, the editor would have kept editing until the contents were legal; if not, then it would be no worse than what happened. WhatamIdoing (talk) 00:10, 29 July 2015 (UTC)
I would oppose having pages that only one editor could see. At the very least, there should be no spaces in the project that can not be seen by admins (who can see, for example, deleted page content and redacted revisions). Any editor who wants to draft things in a private space can already do it offwiki. bd2412T19:44, 22 July 2015 (UTC)
There is a type of draft that is semi-private. It is a draft in user space. Anyone can see it, but is unlikely to see it unless they either search for it or are directed to it. For composing something off-line that is completely private, why not just use a word processor or text editor? Robert McClenon (talk) 20:01, 22 July 2015 (UTC)
"Anybody in the entire world can read this" is what we call "not at all private". Security through obscurity is no security at all.
First, I consider it a WP:NOT problem. The policy says that Wikipedia is not a web hosting service, which is what an option like this could easily become. Unsavory characters could even use such a capacity as a space to communicate criminal plans. bd2412T19:03, 23 July 2015 (UTC)
Definition from the article: "A web hosting service is a type of Internet hosting service that allows individuals and organizations to make their website accessible via the World Wide Web." That pretty much rules out a page that nobody else can see. Also, I'm not sure how one "communicates" anything, criminal or otherwise, when nobody else can see it. I asked why it's a problem to have a page that only the logged-in editor can see. You have replied with a concern that it could be bad if other people could see it. I agree, but that's not an answer to my question. What is the inherent problem in having a small page of text that only one person can look at? WhatamIdoing (talk) 19:17, 23 July 2015 (UTC)
First, it's not within Wikipedia's mission, so not worth the time doing the programming needed to create it. Second, people wanting to use this for illicit communication would only need to share the password with each other. Third, "a small page of text"? How small? How do we know how small it is, if it can't be looked at? Will the page history be publicly viewable? bd2412T22:21, 23 July 2015 (UTC)
Because there's already a limit on page sizes. It's immediately enforced by software, so no human needs to look at any page to know that it's being done. WhatamIdoing (talk) 00:10, 29 July 2015 (UTC)
Copying and pasting only takes a few extra seconds if your favorite text editor is decent. If you really can't afford waiting those seconds, then why not use a pastebin? Esquivaliencet00:09, 23 July 2015 (UTC)
Among other problems: You might not be at your usual computer, or you might be planning to finish it elsewhere (e.g., you start at work and you finish at home). Saving on your computer doesn't so well work if your access is via an internet cafe or a borrowed computer. Pastebins aren't necessarily private.[41] Copying and pasting on mobile and tablet devices is often difficult. Text editors have a tendency to create curly quotes, which mean that when you wanted italics, you end up with ‘’a mess‘’ instead. And that's just off the top of my head; other people could presumably add to this list. WhatamIdoing (talk) 18:51, 23 July 2015 (UTC)
Isn't the wiki markup source code open source? As far as I know, anyone can download it and create their own wiki public or private. If you really want a draft space with wiki markup, that's an option. bd2412T22:24, 23 July 2015 (UTC)
To be honest, they didn't answer your question. They raised some valid concerns. Given, for example, that we had one draft page, limited to, say 64k or 128k, and viewable by admins most of those concerns would vanish. All the best: RichFarmbrough, 00:18, 27 July 2015 (UTC).
Infobox image/text justification problem
I don't know when it exactly happened, I can't find the code where it happened. So did some css or module get updated, because over the past month or so I've constantly ran in to text and image justification problems. What used to be center justified is now left justified. Here's four examples I could find. I know I had to add some code to one template to fix it on that particular one. Did someone break something? TrueCRaysball | #RaysUp06:06, 25 July 2015 (UTC)
@TrueCRaysball: It's private for me too. It also takes ages to "leave" that page to come back here, I suspect a high level of javascript and advertising. If what you've posted there are screenshots, it's better to WP:WPSHOT than use an external service. --Redrose64 (talk) 14:58, 25 July 2015 (UTC)
@Edgars2007 and @Redrose64: I tried redoing the privacy settings again. I used an external service because my screenshot has non-free logos in them to illustrate the point and I can't upload that to Commons. Should be fixed now. If it comes to it, I'll link each individually. @PrimeHunter: So IE9 wasn't interpreting code correctly so lets break the tables for everyone who updates their browser. Makes perfect sense. TrueCRaysball | #RaysUp19:40, 25 July 2015 (UTC)
By the way, I just finished update the template code for those infoboxes to fix their alignment. There are others, I'm sure, still affected by this. Wouldn't it have been easier to to just add text-align:inherit; to MediaWiki:Common.css rather than moving that code like what happened? TrueCRaysball | #RaysUp20:30, 25 July 2015 (UTC)
I did finally get through to that photobucket page - which took over a minute to load because the advertising included a video (of a potter's wheel, for some reason) which soaked up all the CPU cycles and caused the mouse and keyboard to stop responding - and then it took a further three mins to get out again and get to this edit screen, most of which was Windows cleaning up its cache, swapfile etc. to make space for Wikipedia's javascript to load again. If the logos are not relevant to the problem (they probably aren't, as it's about text alignment) crop them off or paint them out. --Redrose64 (talk) 21:06, 25 July 2015 (UTC)
For me (XP and latest Firefox) AdBlock isn't working. But OK, I understand that it's offtopic, so here it's just a note, that AdBlock doesn't work for everybody. If you have some suggestions (except upgrading the system :) ), then you're welcome to my talkpage. --Edgars2007 (talk/contribs) 09:18, 28 July 2015 (UTC)
Issues over the past few days
Session data seems to be lost almost every edit.
Saving often displays the pre-edited version of the page. This was almost unheard of previously.
When I go to my user contributions and I select Edit Count I see that that my edits are broken down according to type of namespace. (Talk, User space, ect.) The top category, which should be mainspace, or Articles, or something like that, displays these foreign (perhaps Korean) symbols: 일반 문서. What's wrong? -- Naytz (talk) 20:20, 28 July 2015 (UTC)
Apologies if this has been covered before, but I couldn't find anything in the archives. Currently when you move a page (as an admin) if the target location has a non-negligible history (i.e. anything more than a single edit redirecting to the page you're moving) you get a really helpful screen that tells you the target has history, gives a link to that history and then gives you a tick box to delete that page so you can proceed with the move if you want. The problem is that often the talk page will also have a non-negligible history, but you don't get a prompt or any real warning for this. Once the move is completed there is a line at the bottom of the page that tells you whether moving the talk page (and any archives) was successful or not, but it's very easy to miss. So my question is, would it be feasible to somehow have the move feature detect when, if the "move accompanying talk page" box is ticked, the talk page that is being moved to has a non-negligible history and give you a tick box option to delete it all in the same process? If that is too difficult or complicated, would it at least be possible to make the notice somehow more prominent (bigger and in red, say?) when moving the talk page is unsuccessful? Thanks, Jenks24 (talk) 08:17, 22 July 2015 (UTC)
Yes but I think it's a developer job to do it properly. Possibly you could use javascript to suppress the "real" move tab and create a "fake" one, and Lua to do the extra checks, but it would be better to make it a feature IMHO. All the best: RichFarmbrough, 00:20, 27 July 2015 (UTC).
Hey Rich, many thanks for responding. I agree that a developer making this a site-wide feature, rather than just a personal hack for me, would be the optimal outcome. The following might be a silly question, but how do I actually contact the developer team with a suggestion like this? Jenks24 (talk) 05:46, 27 July 2015 (UTC)
Thank you both. This has prompted me to finally sign up for Phabricator (can't remember if I had an account for the old one, whatever that was called). Turns out this has been a bug since 2007 [43]. I added a comment to it, but no idea if that will do anything. Jenks24 (talk) 13:55, 29 July 2015 (UTC)
Default edit summary
Is it possible with js or css code in my personal js/css subpage to add some default edit summary for edits? &summary= isn't answer this time, because i'm using regular wikilinks, not URLs. Sometimes I'm too lazy to add edit summary if I'm making some mass edits to many pages where I'm doing the same thing, like adding template, DEFAULTSORT etc. --Edgars2007 (talk/contribs) 11:14, 28 July 2015 (UTC)
I assume you tested that. Not bad, especially if your browser supports buttons on a bookmark toolbar (do they all?). You would still have to remember to click the button, but it would be slightly better than a copy-and-paste from an open Notepad window. Little use for less tech-savvy editors, unless there was a page with well-written usage instructions for each of the major browsers. Ideal solution: A check box at the bottom of the edit window, "Save edit summary", but I won't hold my breath on that one. ―Mandruss☎11:42, 28 July 2015 (UTC)
OK, bookmarklet does the job well. Thanks! But if that code can be modified to put it here, then I would love it more, as Mandruss said - still have to remember to click the button. Like the idea about check box :) --Edgars2007 (talk/contribs) 12:12, 28 July 2015 (UTC)
I use a free programme called AutoHotKey to create macros, so I can type any regularly-used string with just three keystrokes. I wrote a blog post explaining how. I reserve the combination AA for temporary strings. I also take advantage of my browser (Firefox)'s autocomplete function. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits12:44, 28 July 2015 (UTC)
T:Literatur is not a CS1 template directly though it does use Citation/core which relies on the same Module:Citation as CS1. It is a copy last I checked for the German template of the same name. In general, where it is found in an article it should be replaced with the appropriate CS1 template (IMO) since its only use is in copying/transwiking an article from German to English. --Izno (talk) 16:36, 29 July 2015 (UTC)
Some references call a "citedoi" template, and do not seem to have a way of authorlinking. Is there any way in which the authors of a work cited in this way can be linked? An example would be the ref name=" LisieckiRaymo" in the article Pastonian Stage. Thanks, DuncanHill (talk) 13:21, 29 July 2015 (UTC)
I had never noticed the list of templates at the bottom, probably because it was collapsed! Thanks, hopefully will be able to manage from here on. DuncanHill (talk) 13:41, 29 July 2015 (UTC)
DuncanHill, please keep asking questions. We'd rather have you productive than stuck on something, especially when we can answer your questions quickly. You can also post at WP:Help desk if you have less-technical questions about editing. WhatamIdoing (talk) 16:41, 29 July 2015 (UTC)
Reading Non-acsii characters via mwclient
I am currently experiencing an issue when I try to read from pages with non-ascii characters that I lose that character. For instance, if I have prime symbol it is changed to a '?'. Has anyone experienced similar issues? I am utf-8 encoding everything once I have the text, but I have already lost the non-ascii characters prior. Any suggestions or support resources would be greatly appreciated.Julialturner (talk) 06:40, 28 July 2015 (UTC)
Some minimal testcase might be welcome - how do you invoke mwclient? How did you set utf-8 encoding? Which underlying operating system is this about? --Malyacko (talk) 08:52, 28 July 2015 (UTC)
Sure. I invoke mwclient like so:
def connection(self):
useragent = 'Protein Box Bot, Run by The Scripps Research Institute: nanis@scripps.edu'
connection = mwclient.Site(('https', settings.BASE_SITE),clients_useragent=useragent)
connection.login(self.username, self.password)
return connection
"Adding in a feature to sort by date or alphabetically by title will, for the reasons explained above, result in degraded performance for the vast majority of users. It's for this reason that search engines like Google don't allow you to sort by date or alphabetically by title; it degrades the quality of the service. I'm WONTFIXing this bug accordingly, as I cannot justify adding features to CirrusSearch that degrade the experience for the vast majority of its users." Gotta love the arrogance of some of the development team, telling users "no, no, we think you won't understand what a 'sort by date' button really does." --NeilNtalk to me16:06, 27 July 2015 (UTC)
@NeilN: If you wish to constructively discuss this request, then please reach out to me privately, or discuss the request here, and I'd be more than happy to talk to you about it. If, on the other hand, you wish to continue in this unconstructive manner, attacking others rather than discussing the matter at hand, then I will not engage with you further. Thank you. --Dan Garry, Wikimedia Foundation (talk) 03:30, 28 July 2015 (UTC)
@Deskana: I see the discussion that took place in the phabricator report. Will repeating the points do any good? You've already made your decrees based on very misleading statements ("degrade the experience for the vast majority of its users"). --NeilNtalk to me03:41, 28 July 2015 (UTC)
@Deskana: What the heck. I'll give it a shot. Please justify your comparison that Wikipedia pages are the "web" and Wikipedia search is "Google". This is a little grandiose and ignores the fact that Wikipedia pages have structure and Wikipedia does not contain a billion pages of garbage. Given the less than stellar parts of the current UI, please justify your assumption that a clearly marked "Sort by date" button would "result in degraded performance for the vast majority of users". Please justify your statement that "I've already outlined that sorting by date will, for the vast majority of users, generate meaningless results." You've repeated your assumption, you haven't justified it. --NeilNtalk to me04:10, 28 July 2015 (UTC)
@NeilN: That isn't exactly a positive start to the conversation. There's very little to be gained by debating the past, especially given your combative way of asking these questions. What would be productive is for us to work together to identify what it is you're trying to do, so that I can see if I can help support it. Why don't we start by you walking me through what task you're trying to accomplish? Then I can see if we can support it. Does that sound like something you'd be interested in doing? (P.S. Please don't ping my volunteer account with messages relating to my work, as I'm unlikely to see them; please ping User:Deskana (WMF) instead) --Dan Garry, Wikimedia Foundation (talk) 04:34, 28 July 2015 (UTC)
User:Deskana (WMF), but you've already dismissed my use case (looking at articles containing a term which have recently changed) using the assumptions I've listed above. Now I'm asking you to justify them. --NeilNtalk to me04:41, 28 July 2015 (UTC)
@NeilN: I have already done so. You are within your rights to disagree that I have. However, that does mean that this is no longer a productive conversation, so I must discontinue it so I can get back to my work. Best wishes. --Dan Garry, Wikimedia Foundation (talk) 04:59, 28 July 2015 (UTC)
Not pinging Deskana as it's clear he no longer wishes to participate but can someone else look at the phab reports and point out where he's actually justified his assumptions? --NeilNtalk to me05:05, 28 July 2015 (UTC)
I am writing to report that English Wikipedia is extremely slow right now (I can not access WP:VPT), and sometimes gives an error:
"This page can't be displayed
•Make sure the web address https://wiki.riteme.site is correct.
•Look for the page with your search engine.
•Refresh the page in a few minutes.
•Make sure TLS and SSL protocols are enabled. Go to Tools > Internet Options > Advanced > Settings > Security"
This sounds like it could be a load-balancing problem in one of the WMF datacenters - see this thread for a previous example. Another reason may be slow JavaScript. Try logging out (or browsing in private mode, which essentially logs you out) and see if you still experience slowness. If things are still slow when you are logged out, it is a good indicator that it is a load-balancing problem rather than a JavaScript problem. If this is the case, please let us know roughly where you are in the world, as load-balancing problems are often limited to a specific geographical area. — Mr. Stradivarius♪ talk ♪10:08, 28 July 2015 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Yes, it was the file upload wizard. And I tried to upload a jpeg via Google Chrome. But everything is working fine now, so I'll close this. Erpertblah, blah, blah...23:55, 30 July 2015 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Citation now spam
I found a citation to a website that is now squatted to a generic spam search. Luckily I was able to find an archive to link to. However I didn't want to leave the spam link, nor did I want to remove the url - I think I took the protocol identifier off, and left it at that. Is there a consensus way tot deal with these links? All the best: RichFarmbrough, 19:55, 29 July 2015 (UTC).
Check whether the link was recently replaced - some spammers replace links in citations, especially broken ones. Otherwise, standard editing will have to serve, along with link blacklisting if it happens repeatedly. Jo-Jo Eumerus (talk, contributions) 20:03, 29 July 2015 (UTC)
Well given that the archive version was good, it obviously wasn't the type of "dead link spam" SEO'ers have been doing recently. And link blacklisting is no help against what happened several years ago, far better to generate a list of all external links to that domain and add archive urls where possible (a nice little job for automation, which, of course I cannot do!).
I have MonoBook skin, not some beta-testing Mobile thing. The box at the top of the Watchlist, with various options, has just gone all Facebooky, grey and unreadable with lots of blank space. How can I switch it back to how it was? --Redrose64 (talk) 18:37, 30 July 2015 (UTC)
"Invert selection" and "Associated namespace" only apply if a namespace has been selected so they are grey before that. Do you see other grey parts, or are they still grey after a namespace selection? PrimeHunter (talk) 18:43, 30 July 2015 (UTC)
(edit conflict) I too have MonoBook. Multiple buttons are very large all of a sudden, and the Invert selection/Associated namespace checkboxes have a bit of excessive whitespace around them. Dustin(talk)18:45, 30 July 2015 (UTC)
Why is "Mark all pages as visited" so big? I never use that button so I don't know why it needs to take up so much vertical space. Sam Walton (talk) 18:46, 30 July 2015 (UTC)
Yup. A waste of space - poor ergonomics. 18:57, 30 July 2015 (UTC) — Preceding unsigned comment added by AndyTheGrump (talk • contribs)
@PrimeHunter: The obviously-visible items are: the word "Namespace"; the word "all" below that; two grey squares (which may be checkboxes - without the familiar inset border it's hard to tell); a "Go" button, which is much bigger than it used to be - and with a background of light blue instead of silver. There is also some barely-readable grey text; dragging my mouse over it, I see that it's "Invert selection" and "Associated namespace". I also find that the namespace selector has a border that is so pale that it's even less noticeable than that grey text. Going away and coming back I find that the text starts off black but quickly turns grey, like there's some javaScript going on. --Redrose64 (talk) 19:07, 30 July 2015 (UTC)
Yes, with black text, very little superfluous space, the namespace selector and checkboxes white within inset border, and a silver button. --Redrose64 (talk) 19:15, 30 July 2015 (UTC)
Hi, the change of watchlist interface was indeed deployed prematurely (and now reverted), and we missed some of the display issues with it (mostly there wasn't meant to be that much whitespace, and it behaved strangely on small screens). I didn't author or accept it myself, but I reviewed it and didn't flag them. We're going to be trying again, with feeling this time, probably next-next week (week of 10 August). Please watch phab:T99256 for updates (you can "Subscribe" if you have a Phabricator account to receive updates by e-mail), I'll make sure there's a testing wiki with the patch set up and linked from that patch at least a few days earlier, for everyone to play with and comment. Matma Rextalk20:11, 30 July 2015 (UTC)
The type of changes mentioned, I understand, would greatly increase the internet search-ability of talk pages as this would facilitate the use of search terms such as: site:www.wiki.riteme.site/wiki/Talk/ search term/s.
I oppose the suggested change but will just note about the above Google search that Google doesn't actually index "Talk:". They do index some talk pages they picked up as "Talk%3A" where "%3A" is a percent-encoded ":" and our servers produce the same content. I don't know why Google drops "Talk:". I don't see anything relevant in https://wiki.riteme.site/robots.txt, and there is no noindex in the html of the pages (if there were then it should also be in the %3A versions). I don't want Google to index talk pages, I just wonder what stops them. Did Google decide on their own that talk pages are too uninformative to deserve the high placement they would get? PrimeHunter (talk) 12:36, 30 July 2015 (UTC)
Google has special cleverness for Wikipedia. As far as I know they have not shared what it is. I am pretty sure they do not honour __NOINDEX__ though. All the best: RichFarmbrough, 19:35, 31 July 2015 (UTC).
This wouldn't work because it would clash with Main namespace pages containing slashes in the title. An article named "Talk/Foo" would have the same URI as the Talk page for the page named "Foo". Slashes in URIs are already an issue in MediaWiki, since MediaWiki uses them as part of the page title for subpages, which raises the same issue of potential URI clashes. So, MediaWiki has a setting that allows you to disable subpages on a per-namespace basis, with them off by default in the Main namespace (which is the setting Wikipedia uses). You also touched on initial capitals in page titles, which are another pain point. By default the first character in a page title is case-insensitive, so [[Foo]] and [[foo]] will go to the same page, which is what people tend to expect. Wiktionary has this setting toggled so it can have different articles on, e.g., Rock and rock, but this means you always have to pay attention to the initial capital in wikilinks, and I think it messes with searching too. Basically there's never a perfect solution for anything in (software) engineering. It's all about what tradeoffs you choose. --108.38.204.15 (talk) 22:36, 31 July 2015 (UTC)
Main page on mobile
Breaking with centuries of tradition I today views the mainpage from a mobile phone. A lot of the content, for example DYK was not visible. All the best: RichFarmbrough, 19:38, 31 July 2015 (UTC).
I don't know how many people have set their preferences to be able to view image annotations from Commons, but the feature can cause problems in small resolutions, where it is far more annoying than useful. It's not so much the plethora of tiny yellow boxes that can obscure an image without highlighting anything visible, as it is the text that appears below it—"This file has annotations. Move the mouse pointer over the image to see them."—which can take up more space than the image itself. I noticed this phenomenon in the display templates for good topics (where I initially tried to solicit opinions, before giving it a try here), but I imagine it can affect small images everywhere, such as in navigation templates.
The situation hasn't changed much in two-and-a-half years (except perhaps the increased likelihood of coming across an image with annotations), and my question is this: is there a way to suppress the feature when displaying an image? And if not, could one be devised? Waltham, The Duke of14:32, 31 July 2015 (UTC)
In Firefox 39 I see it in both MonoBook and Vector. The text is made with JavaScript and is added shortly after page load. The yellow boxes are only visible when hovering over the image. I don't know whether the 89px limit depends on anything. I have added a 400px version where I also see the text and yellow boxes. PrimeHunter (talk) 20:57, 31 July 2015 (UTC)
Aha. I needed to also disable "Redirect image links to Commons for files hosted there". Seems that they can't coexist. --Redrose64 (talk) 21:45, 31 July 2015 (UTC)
Thank you for the detailed investigation. It makes sense that there would be a size limit, but it really is arbitrary because it depends on the specific image and its level of detail. And as I've said, the text takes up a lot of space.
Although my programming skills are extremely limited, I think I've managed to copy the template's relevant command here and suppress annotations in the medium-sized image on the right. (I have no idea if there is any difference between span and div, though; they're both in the template.) If someone knows how to make this—the command rather than the entire ImageNoteControl template—part of {{Featured topic box}}, that would solve the immediate problem. For other small images, more publicity for {{ImageNoteControl}} might be desirable. Waltham, The Duke of06:09, 1 August 2015 (UTC)
I think that it's "cleaner" to have three classes instead of just one: class="wpImageAnnotatorControl wpImageAnnotatorOff wpImageAnnotatorCaptionOff" As for <div>...</div> versus <span>...</span> it depends upon the context. For images used as block elements (as with all examples so far) div is correct; for images used inline, like this then span is correct. --Redrose64 (talk) 11:01, 1 August 2015 (UTC)
Capital! This is exactly the desired effect. Thank you very much for your trouble—and for the impromptu HTML lesson along the way. It would feel wrong for me to implement your edit, especially considering the possibility that you might still want to tinker with it, so I'll leave it for you to proceed with that step whenever you are ready. Other than that... I'll see if I can find some image-related help page in the English Wikipedia where inserting a mention of {{ImageNoteControl}} would be productive. Waltham, The Duke of11:59, 1 August 2015 (UTC)
Precisely. This is, frankly, an ambiguous provision that cannot easily be decided and makes no real sense. We'd be much better off enforcing the Commons policy, which prohibits the inclusion of parent categories with a single easy-to-identify exception. Nyttend (talk) 01:34, 2 August 2015 (UTC)
Search links not appearing
I just discovered that all my search links that are limited to searching the article text (eg. {{search link|text="buggy"}}) stopped rendering sometime in the past 48 hours past week (apparently my earlier conversation on this very board and with John of Reading on his userpage didn't use the text parameter). I've checked instances logged-in and logged-out, on Chrome and on Firefox, and I get the glitch in all cases. This does not seem to affect instances of {{Search link}} that do not have that limitation. I have not had a chance to test various alternates. Test matrix:
plaintext using <nowiki> tag – regular wikitext
{{search link|text="buggy"}} – "buggy"[restored as of 22:34 (UTC)]
User:Cpiral changed the parameter names in [44] without allowing the old names as aliases. That's problematic for an old template with many uses. I see Cpiral updated some uses of the old names. Was that all of them or are there still many? In either case I suggest allowing the old names. PrimeHunter (talk) 21:35, 28 July 2015 (UTC)
Was problematic. With {{Template usage}} now anyone can now find all template usage and directly removing obsolete parameter usage from the wikitext, avoiding the need for backward compatible code. — CpiralCpiral23:03, 28 July 2015 (UTC)
@Alakzi: They have been rewriting whole sections, much of their new text is barely comprehensible. In this edit, for example, terms like "parameter" and "argument" are used almost interchangeably; and although they state early on that there are two kinds of parameter: named and unnamed. Soon after, we find that there is a third kind, the positional parameter, which is apparently not the same as an unnamed parameter. Have a look at each edit individually - they really are difficult to follow. The most recent large edit produced the paragraph
To improve readability many programming languages ignore much of the whitespace, so programmers can add newlines and indent almost at will. Because of the nature of transcluding text in place, seemlessly, MediaWiki software is very sensitive to whitespace, only allowing it around some places, but in most places newlines for code-readability are treated by the software as content, so the template code uses <!-- comments --> as a work around, adding <!-- before each newline character and --> after it.
Awh, let's go ahead and sully the talk page at Help:Template. I've started a conversation there about the changes. You can refer to me in first person now. Thanks. — CpiralCpiral00:16, 29 July 2015 (UTC)
There's another big issue with updating parameter names: Many other projects rely on the template infrastructure of the English Wikipedia. Breaking stuff makes it much harder to adopt updates. All the best: RichFarmbrough, 19:58, 29 July 2015 (UTC).
I think I understand your concerns, but can you specify? I am not convinced that template infrastructure need develop differently than the way I am developing it. I can achieve new-feature parity for any template and avoid the need for carrying any backward compatible code, by directly changing every instance of obsolete parameter usage on the wiki, then changing the template. The documentation was updated. Was I supposed to change these few on the wiki in User space? — CpiralCpiral02:36, 3 August 2015 (UTC)
What does a Healthy Community look like to you?
Hi,
The Community Engagement department at the Wikimedia Foundation has launched a new learning campaign. The WMF wants to record community impressions about what makes a healthy online community.
Share your views and/or create a drawing and take a chance to win a Wikimania 2016 scholarship!
Join the WMF as we begin a conversation about Community Health. Contribute a drawing or answer the questions on the campaign's page.
Why get involved?
The world is changing. The way we relate to knowledge is transforming. As the next billion people come online, the Wikimedia movement is working to bring more users on the wiki projects. The way we interact and collaborate online are key to building sustainable projects. How accessible are Wikimedia projects to newcomers today? Are we helping each other learn?
Share your views on this matter that affects us all!
We invite everyone to take part in this learning campaign. Wikimedia Foundation will distribute one Wikimania Scholarship 2016 among those participants who are eligible.
More information
All participants must have a registered user of at least one month antiquity on any Wikimedia project before the starting date of the campaign.
All eligible contributions must be done until August 23, 2015 at 23:59 UTC
Module:Citation/CS1 incorrectly adding pages using edition=revised to tracking category
Module:Citation/CS1 automatically adds "ed." after the value of the edition parameter. Citations that explicitly use something like "2nd ed." are added to the hidden maintenance category Category:CS1 maint: Extra text to allow fixing these values more easily. However, the module probably just checks whether the value ends with "edition", "ed" or similar. This leads to issues on pages like Pi, where a reference (No. 79, The Penguin Dictionary of Curious and Interesting Numbers) gets incorrectly marked as erroneous because it uses "edition=revised", which ends with "ed". Is this a bug? —Maths314 (talk) 20:04, 2 August 2015 (UTC)
Yes, a bug that has been fixed in the sandbox. Questions and concerns about this module are best addressed at Help talk:Citation Style 1.
In November 2014 a lesbian couple filed for an amparo and were granted an injunction to marry. The state appealed the decision. 10 July, 2015, the Appellate Court upheld the ruling in favor of the couple. Their wedding, which was the first same-sex marriage in the state of Puebla<ref name="1st marriage">{{cite news|last1=Hernández Alcántara|first1=Martín|title=Mañana se celebrará el primer matrimonio gay en la historia de Puebla|url=http://www.lajornadadeoriente.com.mx/2015/07/31/manana-se-celebrara-el-primer-matrimonio-gay-en-la-historia-de-puebla/|accessdate=31 July 2015|publisher=La Jornada de Oriente|date=31 July 2015|location=Puebla, Mexico|language=Spanish}}</ref> took place on 1 August 2015.<ref name="1st marriage">{{cite news|last1=Fernández|first1=Tuss|title=Se celebra en Puebla la primera boda de personas del mismo sexo|url=http://ladobe.com.mx/2015/08/se-celebra-en-puebla-la-primera-boda-de-personas-del-mismo-sexo/|accessdate=3 August 2015|publisher=La Dobe|date=2 August 2015|location=Puebla, Mexico|language=Spanish}}</ref> As you can plainly see the text is different, but the numbers are the same: 254 is the citation number for both. Edit was made at 19:03 and it is still the same at 19:18? SusunW (talk) 00:18, 3 August 2015 (UTC)
@SusunW: This has happened because you've given both the references the same name, "1st marriage", so MediaWiki thinks your second reference is actually a reuse of the first one rather than a totally new reference. If you change the name of one of the references, it'll be fixed. Hope that helps. --(ʞɿɐʇ) ɐuɐʞsǝp00:24, 3 August 2015 (UTC)
You commented below someone else's support, which the tool probably picked up as "support". It should not do that, someone commenting on someone else's !vote is usually not a vote, or a contestation. Not sure why it ignored the nomination, though. Jo-Jo Eumerus (talk, contributions) 10:03, 30 July 2015 (UTC)
I was bold and have tweaked the page. What's probably going on is that you used the incorrect list type to start your comment (please read WP:Accessibility#Lists). Check in a day or two to see if that fixed it. --Izno (talk) 11:58, 30 July 2015 (UTC)
@Izno: Thank you very much. I think I found what's wrong. User:4minute lover signed his "keep" vote with a signature that contains a link to my talk page ([46]). That's very weird. He probably didn't know how to sign, but copied my signature. I changed it, and the AfD Statistic is now OK. I took a look into 4minute lover's edits, and I found that here he signed his post with a signature of User:Gene93k. Very strange behavior. Vanjagenije(talk)11:30, 3 August 2015 (UTC)
That one with Gene looks like he was moving the deletion sorting notice, not signing the page with a new comment. Which it's weird, but separately weird. --Izno (talk) 13:56, 3 August 2015 (UTC)
This is what is so ugly about talk pages. They are messy and unstructured. WP:Flow would be much easier for tools like this to work with. But a lot of reactionary people wants it to fail.--Anders Feder (talk) 11:08, 30 July 2015 (UTC)
Wikimedia email
Is Wikimedia email currently working? I sent an email to another user about an hour ago, ticked the box to receive a confirmation copy to my registered email address, got the on-screen confirmation that the email had been sent, but never received the confirmation email. Can this be independently checked? Dirtlawyer1 (talk) 02:37, 3 August 2015 (UTC)
Good idea, OM. I should have thought of that. I have three alternative accounts that I use to maintain separate large watch lists. I will try emailing one of those accounts. Cheers. Dirtlawyer1 (talk) 02:57, 3 August 2015 (UTC)
@Od Mishehu: About 45 minutes ago, I tried to send an email from my alternate account, Dirtlawyer2: Olympics, to my primary user account, Dirtlawyer1. I have not received either the email sent to the recipient account, or the confirmation email that the email system is supposed to generate for the sender account. About 10 minutes ago, I also sent a test email to you through the Wikipedia email system. Please let me know if you do or don't receive it. Thanks. Dirtlawyer1 (talk) 03:39, 3 August 2015 (UTC)
As I've suggested a few times since this problem presented itself, we could resolve this issue by correctly and accurately identifying the sender (albeit by proxy) of the email as Wikimedia and provide the email address of the Wikipedia user who requested Wikimedia send the email in the reply-to field.
Alternatively, each user with email enable could be assigned virtual email address that Wikimedia would route to their actual email. xeno@users.wikimedia.org, for example. –xenotalk13:00, 3 August 2015 (UTC)
Upload file from WikiEditor...to Commons
Hi there, Wikipedians!
First, this is not a very polished script, so forgive the omissions and thrown-together UI.
At Wikimania, I wrote a gadget that uploaded from enwiki beta to Commons beta. And it worked. And it was brilliant.
Now, the code required for that gadget is on enwiki proper. So I ported the script over to enwiki.
All you need is the following line in your common.js to enable it:
After that, a second "insert file" icon will appear in WikiEditor after a second or two, and its title text will be "upload file" or something.
Note, this is going to Commons, under a CC-BY-SA 4.0 license, so by reading this and installing my script you're agreeing to those terms when you upload...see, I told you it was unpolished. In the Future, it will have a license disclaimer.
This is going to be the very rough basis for our upcoming tools, which will live both in WikiEditor and in VisualEditor. They will definitely have proper license disclaimers.
In this grand tradition, you can create subclasses of my mw.Upload object(s), and my mw.UploadDialog object(s), and write specialized upload tools for various purposes. Want to add a special category to images in a class of articles that you edit often? Easy! Subclass mw.CommonsUploadForEditDialog to return a subclass of mw.CommonsUploadForEdit which adds the category in automatically on creation. This is only one example of the cool, specialized stuff you can do.
You can also do this using |dab=athlete as opposed to my solution for each of the template uses. I think my solution is marginally easier to understand. YMMV. --Izno (talk) 15:33, 3 August 2015 (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
The ContentTranslation extension has been updated:
You can now type in list paragraphs on wikis with right-to-left scripts. [47]
Some user interface updates changed how details in the ContentTranslation extension look. [48][49][50][51]
The error page you see when the sites are not working is now simpler and easier to read. It also shows the Wikimedia logo. [52]
MediaWiki now supports redirects for CSS pages. [53]
Bots can't guess captchas unlimited times anymore. [54]
Problems
There was a problem with thumbnails on wikis with local images on July 24 and 25. It was due to a code error. [55]
The new version of MediaWiki will be on test wikis and MediaWiki.org from August 4. It will be on non-Wikipedia wikis from August 5. It will be on all Wikipedias from August 6 (calendar).
Meetings
You can join the next meeting with the VisualEditor team. During the meeting, you can tell developers which bugs are the most important. The meeting will be on August 4 at 19:00 (UTC). See how to join.
favicon in Firefox 39.0 tabs for redirects to sections, for example Wiki spam and others tested in Category:Redirects to sections and the five other languages listed there. I see the favicon in Wiki spam in IE, Chrome, Safari and Opera. In Firefox I see the favicon for Spamdexing (direct link to the page) and Spamdex (redirect to the page but not to a section). Do others have the Firefox issue? PrimeHunter (talk) 02:26, 3 July 2015 (UTC)
– Paine 12:46, 13 June 2015 (UTC)
..--Stemoc 17:01, 13 June 2015 (UTC)
lists.wikimedia.org, to keep discussion centralised and give everyone a chance to participate. Thanks again! --Dan Garry, Wikimedia Foundation (talk) 20:09, 7 July 2015 (UTC)
Alakzi: What method can I call within a script to do so? ResMar 19:43, 12 July 2015 (UTC)
Done Thanks. The Quixotic Potato (talk) 00:31, 16 July 2015 (UTC)
.
-3-phenyl-cyclohexanone.gif)
-3-phenyl-cyclohexanone.png)
appears in the 
Fixed T106273 - NQ-Alt (talk) 01:35, 28 July 2015 (UTC)
Like the idea about check box :) --Edgars2007 (talk/contribs) 12:12, 28 July 2015 (UTC)
then span is correct. --Redrose64 (talk) 11:01, 1 August 2015 (UTC)
Resolved