User talk:Bender235/2015 archive

811:

browser would be more helpful. Nobody supports an unsupported browser. This is a common practice because of security and manpower. It would be irresponsible to support an unsecure platform. It also costs more to keep unsupported version going and nobody is going to waste manpower for that. Currently a Mac OS version is only supported for ~4 years. 10.6 was last to have support dropped. Sorry, but it is not remotely reasonable for anyone to support 10.6 now. You choose a Mac, you knew you will pay more for a Mac and have shorter support times. At the end of the year, Microsoft is dropping support for all browsers except for IE 11 and above. At that point, sites will start yanking out code supporting anything earlier than 2013 browsers. This is just the way of computer life.

762:, Thank you for taking time to explain this. The Safari 8 was released in October 2014; Knowledge really cannot rely on users having computers less than 6 months old. I have had Macs now for about 25 years, so I´m pretty much at home with Safari. As I said above, though: outside the high-tech environments people often have ancient computers, because they see no need to upgrade when their present computer do everything they wants it do: a bit of surfing, (typically news) and some email. I think it would be a loss for Knowledge, if these people were not also given a chance to edit Knowledge. 4257:

about the connection being untrusted (I don't have that kind of certificate) and, according to the browser, possibly a target of site impersonation. My site is minor but later the same day I tried a *.gov site that worked with HTTP but failed with HTTPS (www.cdc.gov). So, unless you're testing every non-Wikimedia link or at least every non-Wikimedia subdomain, I wouldn't convert their protocols to HTTPS. I assume protocol relativity works only for Wikimedia URLs (and perhaps some others but that's only a speculation), so I'll continue to link to the URLs that I actually used.

5639: 7604:. I had to do that manually since a bot had added another edit. I didn't see the need for a "Needs a copy-edit" tag when I had just completed a thorough copy-edit of the article. Also, the editor had re-worded the first sentence so that it no longer made sense. Since I had forgotten to put the GOCE template on the article's talk page, I did that. However, I noticed that the size of an image in the article had also been changed. I didn't know whether to change that or not. I thought I'd ask you to check it. 31: 5651: 6174:

for every link he/she wants to follow? If those users who might, some day, have no choice but access WP through http decide to go through the difficult task of first convincing WP to allow for an opt-out feature, and then opt-out to be able to visit WP with http, then they will be very upset everytime they see an absolute https link where a PR link would have been fine for everyone. These users will get bored of converting https to http and will wonder why PR links were not used.

7372: 6101:

https links won't change anything for https users and won't block anyone in some countries where people might be affraid of complaining when WP gets blocked through https. Besides, the more we force Big Brother to increase its decryption power, the faster BB will get money for spying even more. BTW, the RfC could not be seen by readers living in countries that block https, so the concensus was reached among https-only readers. Sorry if I missed something.

7951: 63: 5142: 1035: 941: 3931:. It is not a good idea to change from a specific nationality to com in Google books. Sometimes the pages are only visible for certain nationalities. If for example you change google.co.uk to google.com, google usually defaults that to the nationality of the IP address making the request and that may make the pages inaccessible to some uses when it would be visible if the choose to look at it with google.co.uk (as an example). 7000: 6605: 7527: 6751: 5256: 4952: 3409: 1760: 1540: 6191:

https opt-out can drive some users in some countries to protest against blocks, but there will always be some users who won't be able to fight against blocks nor find workarounds. I just wish that these users be able to get an opt-out feature from WP if they can't fight against blocks by their govs. I agree that these users should fight against blocks, but I also think they know

1149:, which should not take more than a minute of your time. I would dearly appreciate you taking this minute; not only as a Knowledge researcher but as a fellow content creator and concerned member of the community (I believe your answers may help us eventually improve our policies and thus, the project's governance). PS. If you chose to reply here (on your userpage), please 741:. One of the advantages of SPDY is instead of multiple round trips to establish an https connection, it can be done in one, like non-https browsing. A web site has to support SPDY. Archive.org and Knowledge currently don't support it. Knowledge is currently testing it. Google, Facebook, Twitter, Yahoo all use it. 4223:, not a Wikimedia property, and, because of restrictions in some nations, Wikimedia does not always require HTTPS, so external links to Wikimedia should begin with the double slash that comes after the opening protocol and colon, as in //example.com. In the archive.org Dowrkin case, both protocols work. 8127:

my father was a great man he was the innovative of the world wide internet as we know it today i cannot share our real names because his own identity must not be discoverd he was the fifth element which is the open source project for all of the internet without his suffering pain and work they would

3954:

If you look at my edit history you will see it is very large and I do not have an example to hand. But I can assure you that it is true in some cases. I often test a page that is not available within the UK (uk) against Canada (ca) and New Zealand (nz) and while it is not always true that the book is

2473:

Well, at least do me one favour if you must persist with this bizarre style. Before applying it to an article, first check whether I have contributed and if I have then don't bother. Fix the barelinks, by all means; strip the http etc, sure; but don't add that template - perhaps you don't realise how

810:

Knowledge supports Safari 7. I was just giving an example where a new version would be more helpful. YouTube just made a change to HTML5 video by default. This is only supported in Safari 8. HTML5 is a smaller download, thus videos would load faster. Again, an example where a newer version of a

732:

You are correct Bender, it is caused by outdated version of the browser and possibility the hardware too. Safari 4.x series came out in 2009. Huldra would be running OS X 10.4, which had its support end in 2010. One cannot expect anything that old to work on today's web. Huldra's "new" system

525:

I have looked for ages, and not found any method! And there are lots and lots of people with ancient computers out there, they are just not contributing to Knowledge as they are put off by lots of nerdy geeks who have the very newest computers and expect everyone else to have it, too. And people

329:

FYI... Knowledge only supports IE version 8+ and the current releases of Chrome and Firefox. At the end of 2015, Knowledge will only support IE 11+. At the moment, the code for IE 8 and below is depreciate, but will be removed by the end of the year. Currently only 10% of requests come from IE and

6173:

On the other side, imagine that for some reason some user is forced to read WP through http. Should WP force this user to copy the https absolute link he/she wishes to follow, paste it in the address bar of a new tab, remove the s and, only then, clic "Go" or press return, and repeat all these steps

4009:

As a secondary issue I am not at all sure that just because one accesses Knowledge via https it is necessary to access links external to Knowledge as https rather than http. What is your thinking about that and do you check if the external site is running an https server before you make a change? --

1144:

take part in that vote. Which is where you come in :) You are a highly active Wikipedian (47th to be exact), and you were active back during the January 2012 discussion/voting for the SOPA, yet you did not chose to participate in said vote. I'd appreciate it if you could tell me why was that so? For

597:

A slow computer really doesn't affect performance of https via plain web browsing. If on an older browser (pre 2010), not all browsers would cache https content. This would result in a huge slowdown. Network connection speed does cause problems for the initial connection to a site as it takes more

6190:

for everyone already using https. Using absolute https will only disapoint users, should an opt-out feature be adopted some day. I'm not suggesting to revert the decision of making https the default for WP. I'm suggesting that we keep articles as protocol-neutral as possible. I admit that having no

5761:

Also - I would love to see a page about someone - is this a conflict of interest: my mother Zakia Sarwar, a teacher, teacher trainer pioneer and pioneer in large classes teaching in Pakistan whose work is acknowledged worldwide. She started the Society of Pakistan English Language Teachers (SPELT -

4467:

FYI... The VPP you mention is moot. It was closed as something the Mediawiki people should decide. They decided and Knowledge is now https only. The only reason not to move to https is where countries (ie China & Russia) are blocking websites. https makes it harder to go around the blocks.

4368:

Since there's no grand agreement on things I can't say what “we” do, but I certainly found it useful. A lot of websites that Knowledge articles rely on as sources offer HTTPS without any downsides, so it seemed only plausible to me to do this. A lot of users thanked me so far and apparently agreed.

3807:

Hi Bender, I am so sorry if I am not doing this right. I was just wondering if you could add my bronze Sacagawea statue in Cascade Locks, Oregon to the list of statues on the Sacagawea Knowledge page? My name is Heather Soderberg and my website is www.heathersoderberg.com Thank you so much! Heather

2141:

It might be technical but it is not minor. Stop fiddling around, please - you are making things more complex even for those of us who supposedly know what we are doing and we poor content contributors do have to worry about it: you're stuffed without us. If you must change all instances relating to

6199:

its users, even to those who don't want to fight. Some people might think that this is a bad idea and that WP should do politics. I would answer that WP can still do politics by refusing opt-outs or by accepting opt-outs only for carefully selected countries and for a limited time, until diplomacy

6177:

If my suggestion of using protocol-relative URLs insteat of absolute https would have meant disabling https for anyone already using https, then I would not be writing all this. But this is not the case. Hardcoding https will only result in more trouble the day WP finds out that some countries are

6100:

takes less space, as it was already spotted. Moreover, it could be usefull, some day, to let user-agents opt-out of the https redirection (e.g. with a cookie or an http header). I know that this sounds crazy. Everyone, including myself, prefers https. But, as we all know, using PR links instead of

4256:

Thanks for telling me that, I learned something, but that doesn't apply to non-Wikimedia sites (and I'm not clear if all non-English Wikimedia sites are in that exclusive mode yet). On Saturday, I tested a site of my own that I set up for HTTP by trying the HTTPS protocol and got a browser message

3316:

is only one way to read it. We use licenses that encourage others to republish our work. Other sites do not use HTTPS (and may have good reason not to) -- there is no need to force all users toward HTTPS rather than HTTP. There is no downside I'm aware of to using the "[//..." format. (It also has

830:

Bender235: You apparently were the user who edited my wikipedia biography (Timothy J. Bartik) to say that my birth date was October 1, 1952. This is incorrect. My birthdate is March 26, 1954. This has since been partly corrected (a part of my wikipedia bio says March 26, 1954, the other part says

656:

35. So please tell me, what kind of system are we talking about in your case. Maybe there's an easy fix for you. And it doesn't have to be Firefox; Chrome, Opera, or any other modern browser will suffice. Please don't think of this as "geeky stuff", because keeping your machine updated is actually

6020:

My thinking was that HTTPS and PRURL have exactly the same effect for archive.org, so why spend six characters unnecessarily? Upon further reflection, it does require some editor effort to remove those six characters from new URLs that have been copied from the browser's address bar. And it makes

4800:

I don't see how a template changed from the diff you gave. Everything stayed the same except for the https change. The two "minor edits" you gave were indeed minor (depending on one's view of the https change). How many bytes were changed isn't the definition of minor. Combining refs into one

1938:

The whole thing seems like a load of bollocks. We really do have to stop fussing because I guarantee you it is driving a lot of established contributors away. And since we're not doing well filling their ranks that is pretty disastrous. I do wish the tech folks would keep everyone properly in the

671:

I am writing this on my old Mac, (ibook G4, Safari 4.1.3). It was brand new when I first stared editing Knowledge 10 years ago, I only has it as a reserve these days. But I had to use it for nearly a month last summer, as the screen on my 3 year old Mac flunked out, and it took some time for the

7982:

Or there is another way of looking at this. My watchlist is turning massive in the "active" sense because of the number of India-related articles that are being processed. Specifically, that causes problems for one of Knowledge's well-known hotbeds, ie: caste stuff. Seriouusly damaging edits are

5428:

For tirelessly getting links rewritten to their stronger HTTPS forms. I've read a number of comment threads reacting to your changes, and people seem to keep interpreting it as blind activism that will break links, rather than thoughtful selection of institutions which have made public and clear

3935:

I never heard of that and I highly doubt this is true. Do you have a source confirming this sort of regional discrimination of Google Books? What is true is that Google Books usually re-directs a visitor of books.google.com to say books.google.fr if she's located in France. Also, it switches the

2838:

Andrew George MP. Wonder why you edited out the section MP's Expenses? This information is verifiable and was in the National Press. As a Public figure and elected member of the British Parliament it is essential that people are aware of such matters concerning elected members? Removing the said

1299:

that I thought was mostly positive, but then there were many opposes. Now I will just have to see how the discussion goes. I don't really understand why some users are so against this; many issues that they mentioned (performance, server load, actual security, censorship, etc.) were addressed by

3606:

I didn't until that debate and I had used the ";" for years. So I guess it has been pressed more in the last year or so. From what I have seen on other sites if you place a colon after the bold then the HTML that results is ok. But I have not discussed that and quite frankly it is not worth the

3363:

If there is consensus for this, wouldn't it be best done by a bot? And the way you're going about it would make it more difficult to return to protocol-relative links in case WP ever re-allows http or creates an insecurewikipedia.org as some have commented about. Perhaps you should seek a fresh

3077:. You may want to reconsider using a tool to make those edits, and maybe discuss with other tool users/developers as appropriate. I'm not rolling back your changes, but if you think some of them should be rolled back in light of the policy, feel free to do so. Thanks for your contributions! -- 619:

article again, and now it works, i.e., I stay on http, also for archive.org. I use archive.org a lot, typically several links for every article I edit. I am not based in the Middle-East, but I know the area, and in my estimate, if people have computers, then most would have pre-2010-models. And

468:

I am running on a brand new Mac, bought last August, Safari 7.1.2. It is only my back-up which is ancient. (But when my Mac broke down last summer, it took one month before I could get it replaced, that whole time I was on my old 2005 computer, and really had problems with the Https). Yes, I´m

1273:

I saw your message here and then looked at the discussion on the pump.... egads. Well, that turned worse than I thought and my thoughts were very, very low to begin with. I don't think there is a chance until Knowledge moves to HTTP/2. At that point, one can say https is faster than http.

6182:

users. Do you think these targeted users would be able to protest if they represent only a tiny percentage of the population in their countries? No, they will be ignored. Targeted blocks are probably already being used in some countries. Should WP disappoint those targetted users by adding an

7201:

Do you call that a good practice: you opened the RfC...then you closed it ...with the conclusion you wanted? Should you not have had the decency to let someone else close the RfC? I see some strong objections there, which you have ignored. Oh well, I guess a RfC about your conduct is next?

1882:

recently and I don't understand it most of the time. What on earth is the point of using it when the info is already "parameterised" in a cite books template, for example? It looks like yet more daft template changes just for the sake of it. Has there been some sort of discussion about this

4283:

links to https does not affect external links to www.cdc.gov or any other site. In fact, I only changed those links for websites that definitely support HTTPS and encourage its use, such as YouTube, Google Books (basically any Google service), and finally the Internet Archive. That's it.

5429:

declarations of HTTPS support and enforcement. I appreciate your detailed responses to each one, and I hope you continue working on rewriting them. Keep a cool head and stay polite, no matter how many people don't seem to read your full rationale, and you'll make a stronger Knowledge.

4533:... but you are going about it in the wrong way. Making mass changes to lots of articles in a short period of time is almost seen as disruptive (it is seen as crusading, and people react negatively to any form of crusading). You need to go slower... remember that most editors don't 3211:

Have you found anyone who agrees with you on that? The fact that Knowledge content is now served by default as HTTPS doesn't say anything about how we should code external links within our articles. If this is so obvious, you should be able to link to a consensus discussion.

4730:

into your traffic if it is unencrypted. I don't want to expand this to a 101 lecture on internet security, but I hope I could clear some misconceptions. To summarize, the reason to read Google Books or Internet Archive via HTTPS is no different from the one for Knowledge:

5479:

which way is left. So far, none. In the end, this is a masterpiece of Wikibureaucracy. People who understand the issue agree that it is important to protect readers' privacy, but no one can come up with a way to do it that doesn't violate some petty rule from years ago.

2474:

many problems we already have without adding another layer of broken brackets, malformed arguments and different cite styles into the mix. Just leave it well alone if I've been there before you. Please. Gnoming is easy; really keeping tabs on stuff takes more effort. -

4839:

Once again sorry to correct your misunderstandings. FREAK is an attack on a particular low-security export-graded level of encryption that is deprecated for decades. The disclosure of the attack led to many fixes in SSL/TLS software. As for the "problematic edits":

7566: 6257:

for the archived discussions) then, in case archive.org and/or books.google.com also become available through a .onion address, a small number of changes (in the way PRs are handled) would probably be enough to have these links rendered as onion addresses.

2380:

But you were not just removing bare urls in the example I gave, nor in others that I have seen. And what you should have done was stick with whatever template seemed most appropriate of those that were already in use, not introduce yet another variant. -

4991: 1784: 347:: I assume that by IE you mean internet explorer? I have used Macs now for nearly 25 years, and always Safari (sometimes Opera). And my reserve computer is from when I started editing Knowledge, back in 2005. But even on my brand new Mac, looking up 7578: 5082:

quite a while ago. They now show "or" instead of a slash, and they also put the page in a tracking category for cleanup. The following shows a tiny asterisk after each convert, and holding the mouse over that shows a warning. Pretty obscure, I agree.

5003: 1811: 1591: 1579: 6776: 5282: 3434: 6378:

become available. The implementation of the PRURL renderer would first use a hash table to find whether or not the address in a given protocol-relative external link points to a website that is known by WP to be available through an associated

2783:

you changed the citation format. I much prefer the previous version: it makes the list of References a source of useful information, and does not have duplicates. Hence, I reverted your changes. The format that I like best is the one used in

1799: 4848:

removes a reference duplicate by adding a name tag. Both are perfectly inline with Knowledge guidelines and policies. I'm unsure where this discussion is going. I get the sense that your opposition is unreasonable, hence a "knee-jerk" move.

2022:

would do the same trick. However, it is less flexible if, in the near future, Google abandons unsecure HTTP entirely. If they do, then for us it's just a minor change in a widely deployed template, rather than having to fix a million links.

6552:

I see. Sometimes when I put them in with the best first, so that even if they are not in numeric order my order is deliberate. It's really not a big deal, but I'm wondering if there is a policy on this or if it is just a style choice.

227:

Bender, I saw that you're adding hidden versions of the infobox template to college player bios in preparation for the 2015 NFL Draft. I note that you are still using deprecated versions of several filed/parameter names, specifically:

4541:

react negatively to mass changes (especially to changes to citations). This reaction may be a "knee-jerk" reaction, but it is a natural, instinctive reaction never the less. You need to anticipate this reaction, and take the time to

4632:

on this talk page and have yet to give an answer that boils down to anything other than "because I want to." The fact that WMF is https does not force external sites to do so. I went back to VPP, and if a site does not use https,

1274:

Enabling SPDY was on the Wikimedia technical team's agenda for last quarter, but never got looked at. Most of last quarter's agenda wasn't looked at or finished. SPDY and/or HTTP/2 is not currently on any agenda that I know of.

4559:

a day or two... then return and (if there are no objections) update the links to https. If there are objections, take the time to respond to them. At a minimum, this will let others know that you are acting in good faith.

3883:

we both know my edits are not a violation of AWB rules. But I understand your concern with the technicalities. What would be a compromise you could live with? Me creating a bot-account and running those routines over there?

7224:

I did not close it. I merely added the archive templates on the top and bottom. And added a summary. Of course this is irrelevant, because what matters is others' opinions during the RfC. You can read it. So stop the ad

5531:

Ah, looks I'm too late (I don't get notifications of Knowledge pings, as a not-super-active community member). The discussion was archived or removed. Feel free to email me at eric@konklone.com if I can ever be helpful.

5873: 4637:

Therefore, there appears to be no pressing reasons to change external citations, especially when you have no idea if those sites are running https services. So do you want to "protect users' privacy" or only make them

1331:

Yeah, well, Knowledge seemingly can always only move as fast as the weakest link in the chain. Since there are apparently still people with IE6, or dial-up connections, we can't switch to modern and secure techniques.

3163:

suggest that you feel free to ignore the previous consensus because some ignorance was involved. Using AWB to make edits that go against consensus might be questioned, since AWB is granted to trusted users. Thanks,

1617:, sometimes changes like this may be warranted but IMO they shouldn't be done automatically. Changing the protocol of a URL is one thing, changing an "http://" that occurs within a URL path is a different matter. -- 3120:, which is not true — the VP discussion recommends protocol-relative URLs for websites supporting both. Please change the edit summary for these edits. This was already pointed out to you by me and another user at 7690:. It has the authority to enact binding solutions for disputes between editors, primarily related to serious behavioural issues that the community has been unable to resolve. This includes the ability to impose 6942:

Hi, why did you lock the aristotle page?? I discovered some interesting things that i would like to add. I understand you not wanting it to be vandalised but i would please like it if you cpuld un lock it. Thnx

3977:

I'm sorry, but I'm really not convinced of this story, because I find it implausible. Even if Google restricts access to some books because of some stupid copyright law (which definitely could be the case), the

837:

I am very curious as to why on earth you would think my birthday is October 1, 1952? And how on earth are such errors to be corrected, when I am not supposed to edit my own Knowledge page, for obvious reasons.

4867:

gets installed on web sites. It might be better to wait until this happens. Say when Google finally goes https for unlogged in users, then change the links and use a bot to do it. Would save time and grief.

3955:

accessible through those domains it is not uncommon either. This is not access for the whole book (which is quite frequently available in the states but not in the other domains) but for sections of a book. --

7733:

article, going back to mid-October. Your https edits were mixed in the middle; please feel free to re-run your https script on this article again, and I will not revert. Thanks, and sorry about the bother.

4578:

I see your point, but do you honestly believe this is practical given almost five million articles on Knowledge? Am I supposed to post on five million talk pages about this issue? It doesn't seem practical to

4696:. Google Books, Google News, and of course Archive.org are among the most linked-to references on Knowledge. Both encourage HTTPS use. And if I change those links from HTTP to HTTPS, no reference will break. 1608: 280:

to a https-adress. Please don´t do that. I added that link once (as I have added most of the links to archive.org on Palestinian places), and I am occasionally on my old computer which simply cannot read the

376: 1920:. I'm sorry for not following the existing style, though. Sometimes it is hard to tell whether an article has an "established style" if there are all kinds of different references, including bare links. -- 507:

It is possible to switch this in your user preferences. But anyhow, is it that difficult to just update your machine? I don't find it reasonable to mold Knowledge articles because fringe cases like yours.

6435:

I'm not sure how that would work. If WP was available through an .onion address, all PRURL would link to .onion, too. Unless we add domain-specific filters to the Wiki software, which I don't see yet. --

2542:

You are not sorry at all. However, you are correct. Which is why I will most likely revert you on every occasion. I'm not being bullied by you or anyone else. For starters, you may have forgotten about

1368:

for chrome. It gives a little symbol if either one is installed. According to the plugin, Knowledge is running SPDY v 3.1. I hadn't seen anything that SPDY was enabled on Knowledge. There is also a

7562: 4987: 8003:{{subst:User:BracketBot/inform|diff=695283912|page=Aram Khachaturian|by= by modifying 1 ""s|debug=(0, 1, 0, 0)|list=yes|remaining=*{{quotation|We will consider that if these comrades <nowiki: --> 4773:, where you've changed not only HTTP to HTTPS, but also changed a template. So you're doing more than just conversion, and not disclosing that - fact to cn is totally different. You also tagged a 4582:

In my opinion, this subtle URL switch from HTTP to HTTPS for (some!) websites is no different from other low-level copy-editing types of changes that I have made for years. For instance, I replaced

4417: 5566: 3720:

https to bots? You're spamming my watchlist at a rate of 10+ edits per minute, which is too fast for AWB use anyway. If you were a bot, I could filter you out, otherwise I miss vandalism. See also

6183:

avoidable hassle (removing the s in some external links)? I don't think so. Creating potential problems for users that are targeted by their governments will not help these users fight their govs.

5506: 4927: 1575: 5278: 3159:

recommended protocol-relative links for sites supporting both http and https. If you think that the 2014 consensus has been superseded by a later discussion, I'd appreciate being pointed to it.

146:

It must've been an accident. AWB usually fills in this data from the infobox template, but it didn't seem to have been there, either. I don't know what went wrong. You are right to remove it. --

4222:

was acceptable but not for the reason in your edit summary, unless something has changed again. Wikimedia generally prefers HTTPS over HTTP, but the link you edited was for <archive.org: -->

2930:

Yes that would be better. We need to convince the WMF to create a list of templates that are supported across all languages. Maybe with Lila's new tech initiative we can get tech support time.

4555:

What I would suggest is that you craft a short paragraph, outlining the situation with http and https... something you can cut and paste onto the talk pages of articles. Post this paragraph,

6693:

is the encrypted version of HTTP. It basically prevents anyone between you and the webserver you accessed to read or interfere with the data you requested. There's also a nice website by the

598:

round trips to make the initial connection. Any connections after, the secure connection should be cached, so no more extra round trips. But, the cache is only there for around 10 minutes.

3117: 2687:

info in citations and references. I don't think it's a good idea relying on templates like this, this isn't a solution. If you want to draw up refs quicker as I say, use the tool I linked.♦

1913: 1795: 6772: 5187: 2866:

I oppose the addition of this template to medical articles. IMO the last thing we need is more complicated templates that work in no other language of Knowledge. Will start a discussion at

3940:

from English to French (in this case). Rather than having this switch "predetermined", it is better to offer our "general audience" readers the "general link" which is books.google.com. --

5476: 3070: 623:

Thank you for your explanation about https, I still prefer http, though I can see that at times https would be useful (say, dealing with sensitive material, in certain countries) Cheers,

7036:

Was he "Irish" or "British" or do we need to define his nationality in some other way? A debate on the subject, to reconsider a long-standing consensus that he was Irish, has started at

2852: 239:

Having consolidated these redundant parameters, we would not like to perpetuate the deprecated paraameter/filed names by incorporating them into the the new 2015 players bios. Thanks.

6021:

sense to do them all the same way, thus simplifying the environment a bit. So maybe I'll start using HTTPS instead of PRURL, and changing both HTTP and PRURL to HTTPS when I see them. ―

1123: 898:

ich bin Journalist und würde mich mit Ihnen gerne über Ihre Arbeit als "Contributor" unterhalten. Vielleicht kontaktieren Sie mich einfach unter der Mail "ad.lobe@googlemail.com".

4546:

other editors as to why you are making the changes you wish to make. I realize that you left edit summaries explaining what you were doing, but a simple edit summary is often not

6246: 6089: 5149: 4642:

their privacy is secure? The sites that are being visited still use cookies, https or no. So I don't see a pressing need or an appropriate rationale for mass editing like this.

7228:

But anyhow, if you think I somehow manufactured consensus in that RfC, feel free to open another one. Of course, no one will agree that we should use protocol-relative links for

1626: 7184: 6465:

would be prefered because in such situations no traffic needs to go through an exit node. Coming back to PRURLs, I would imagine that any attempt to make WP available through a

1229: 6118:

I don't buy that logic. There is basically no downside to traffic encryption, and even if this gives reason to ‘Big Brother’ to find ways to decrypt, the race will continue.

4774: 3430: 3385:. Not sure if our bots can do that. Anyhow, I don't think this issue requires a lenghty "consensus-seeking" discussion. Wikimedia's HSTS move is not going to be reversed. -- 3296:). Thus, all protocol-relative URLs will be HTTPS links from now on. That's why I wrote “protocol-relative links do not make sense anymore.” I hope that was clear enough. -- 615:: thank you very much for your tip on how to turn https off, I have done so now. (As you perhaps understand: I'm not that technically advanced!) Anyway, I have checked the 3689: 7246:

I see "In conclusion, there is near-unanimous support for converting the mentioned links to a secure HTTPS connection." signed by you...if you did not close it, who did?

7276: 5806: 5136: 4450:

That VPP discussion closed no consensus due to technical issues (as clearly stated), and WMF does not decide what services external servers should run. That's why not.

1165: 6250: 1223: 5794:

Hey..I'm completely new here on Wiki and just made this account to ask you a question but I'd like to ask you this question in private..so how can I do that? Thanks

8133: 7111: 6958: 1441:. Looking at the phabricator reports, they are still in the process of optimizing SPDY via other changes. Nginx hasn't released a version that supports HTTP2 yet. 6254: 5966:

Right, thank you. I'll continue to use PRURL for archive.org, then. In fact, one might go so far as to say that we should be changing HTTP to PRURL, not to HTTPS. ―

3858:

I know what you mean, but this of course is a possibility which each of our edits, semi-automatic or not. I'll do my best to catch nonsense where ever I find it. --

1250: 1132:), you may know me as an active content creator (see my userpage), but I am also a professional researcher of Knowledge. Recently I published a paper (downloadable 7832: 7475: 5362: 4923: 7040:. Just in case you're interested. Current comments are at "Nationality", at the foot of the page - although an earlier thread at "Irish"? may also be relevant. -- 5444:

I appreciate the pep talk. But this has come to a point where there is not much left I can do. Changing literally millions of links by hand is too tedious. Using

4369:

In general, using HTTPS is not sufficient, but certainly a necessary step to ensure readers' privacy. HTTPS prevents entities to scan traffic at internet hubs. --

7311:

Open an ANI and have an admin of your choice reword it, if it makes you feel better. Serious, this is ridiculous. The consensus in this RfC was crystal clear. --

6651:

Hello, Bender235. Please note that articles must be at least 1500 characters long to qualify for DYK. Please be encouraged to type more into the wikiarticle on

5780: 4692:

readers to use their HTTPS service for sake of their own privacy. Same goes for Google who, being a tech-savvy corporation, have been early to the game and both

4472:

protocol technically handles both http and https, but the browser companies are only going to support https. Note, I have no position on what Bender is doing.

4183: 3685: 1670:

Since it produced this garbage {{Interlanguage link multi|Joseph-König-Gymnasium|de|3=Joseph-König-Gymnasium Haltern am See}}, I call it incompetent. It seems

909: 177: 6195:

whether such fights are worth or not. WP should not treat them badly just because they decide not to fight. WP should be, imho, as user-friendly as possible to

4095: 1491: 1393: 7719: 7640: 6057:

I liked the idea of protocol-relative URL when Wikimedia still gave the option between HTTP or HTTPS access. But now it seems more like an obsolete feature. --

5802: 5692: 5228: 856: 700:

Nope, that is the newest I can have with that hard-ware. I´m writing this on my new Mac, though, (Safari 7.1.2). As I said above though, when I learned how to

672:

shop to get the model of Mac Air that I wanted. When it tries to access https-pages, it just freeze. Anyway, with the info from Bgwhite: it works out fine.

454:? Only then protocol-relative URLs should return an HTTPS link (hence the name). I really wonder what kind of ancient machine you're having, please tell me. -- 8035:

I would appreciate if you can revert the title of the "Sargan-Hansen test" to the original title "Sargan test". This will be more fair and accurate. Thanks.

7872: 7515: 5402: 3508:. This is just FYI, no action needed. I'm letting you know because using a deprecated option puts the article in an error tracking category which I clean up. 5453: 3116:

and other related edits: I don't have a problem with converting http:// links into https, but the edit summary you're using implies that this is condoned by

217: 5732: 3928: 8129: 7107: 7049: 6954: 6558: 6516: 4303: 1828: 4343: 3867: 3748: 1868: 7964:

https conversions for archives.org, Google Books and Newspapers.com. Our researching readers deserve optimal security when clicking on our references :)

6387:

address. As you see, there is no need for any synchronisation. All we need is some changes in the renderer (to make it aware that it is working for WP's

6166:

for archive.org, books.google.com and any other site accepting both http and https (even if http gets instantly redirected to https by those sites) will

4387:

Should've read your talk page. This seems to be related to an earlier discussion, and seems to be your personal judgment. This needs wider discussion.

3708: 3101: 6664: 5831: 1731: 285:-links, And it is not only me; you are making it impossible for any person with an older computer to follow these links; that is not very fair, is it? 248: 7935: 7919: 7465: 7443: 7422: 5948:

No, so far I don't. Since Knowledge is HTTPS-only, all protocol-relative links will be HTTPS anyways, so what would be the point of changing, right? --

5776: 2853:

http://www.telegraph.co.uk/news/newstopics/mps-expenses/5315055/MPs-expenses-Liberal-Democrat-claims-for-308000-flat-used-by-daughter-as-bolt-hole.html

8152: 7130: 6987: 5910: 5885: 4598:

on thousands of articles without anyone complaining. The HTTPS switch is of the same kind, only that it is less esthetic and more practical. It harms

4293: 4266: 4251: 1747: 8043: 3832: 2667: 2628: 2612: 2344: 2296: 2116: 2084: 852: 7992: 7758: 4207: 3792: 3766: 3340: 3326: 3243: 2768: 1345: 1265: 929: 263: 8080: 7661: 5658: 4781:, both of which appear in contribs in the dark red "major change" category. Lastly, why are we at Knowledge beholden to an external site's policy? 3221: 3206: 3173: 2830: 2812: 1682: 889: 7590: 7031: 6734: 6720: 6706: 6645: 5686: 5518: 5053: 5029:, please do not use "widowed" when the spouse has died. It should only be used when the article topic has died and their spouse survived. Thanks. 4157: 4135: 4107: 3914: 3893: 3132: 3058: 2951: 2925: 2594: 2210: 2163: 2058: 1314: 6588: 6562: 6554: 6543: 6512: 6066: 6036: 6003: 5981: 5957: 5927:, I wasn't aware of that RfC while it was open. Are you (and others) also changing existing protocol-relative links to archive.org? If so, why? ― 5578: 5541: 5489: 5128: 4719: 4615: 3532: 2992: 1707: 552: 169: 155: 7887: 5417: 5015: 4939: 4891: 4877: 4858: 4790: 4744: 4651: 4459: 4433: 4396: 4378: 3262: 1641: 1506: 1283: 1215: 1198: 1118: 750: 339: 7348: 7334: 7320: 7306: 7288: 7255: 7241: 7211: 7196: 7026: 6931: 6482: 6444: 6430: 6301: 6216: 6131: 5784: 5623: 4981: 4918: 4869: 4802: 4569: 4505: 4473: 3673: 3305: 3107: 2556: 2537: 2483: 2436: 2390: 2258: 2032: 1970: 1956: 1929: 1603: 1527: 1483: 1478:. They have also been making improvements to speed up things for https. I know they getting rid of bits.wikimedia.org because of https, see 1450: 1442: 1432: 1401: 1385: 1290: 1275: 1024: 812: 757: 742: 727: 713: 695: 681: 666: 612: 599: 540: 535: 517: 482: 463: 344: 331: 317: 222: 5243: 4810: 3147: 1823: 8137: 7826: 7013: 6610: 6474: 6422: 6259: 6208: 6102: 3394: 1300:

replies from me and others. Anyways, I would like the opinions of as many people as possible so you are also welcome to comment there. Best,

877: 771: 644:, please tell me, what "ancient machine" (your words) are you running? I'm really curious why it can't be updated at all. I have a 13-yr old 632: 607: 410: 392: 7096: 6267: 4042: 3999: 3964: 3616: 3601: 1961:

Additionally, you didn't even need to use that template to create hte prurl if it is that important to you. Just do the // thing, surely? -

379:

and ], then I think you will see that I have added most of them. I still have a few to add. But having to deal with them being turned into

3586: 1647: 1189:

Recalling events, I was in favor of the blackout right from the beginning, because I recognized the threat SOPA would pose to Knowledge. --

1029: 131:

back in July 2014, gave the actress a date of death in the Persondata template. I have removed it and only waving it at you for your info.

7613: 7294: 5942: 3559: 5465: 5026: 4232: 3780: 3372: 2075:

Nobody is supposed to be “driven away.” This is just minor technical stuff that (content) contributors don't even have to worry about. --

1381: 1296: 7973: 6110: 5438: 620:

connections are generally slow. Please don´t make Knowledge a place for only those with the newest computer-models or fast connections.

7893: 6575:

I'm not sure, either. Like I said, AWB does it automatically, and they usually don't implement stuff that is not backed by atleast our

6526:

The shuffling is done automatically by AWB, and it is to make sure that references appear in descending numeric order. In other words,

5814: 4976: 3990:

IP (hence your location), not the domain you're trying to access. So unless you can provide at least one example, I'm not buying it. --

3551: 913: 3152: 2977: 1365: 864: 686:

Alright. I suspect the trouble you're having is caused by an outdated version of your browser. Is it possible for you to update it? --

7852: 7495: 5712: 5382: 4323: 3547: 3538: 2890: 1848: 197: 6619: 4722:. Instead I am talking about any entity that could manipulate plain HTTP traffic between you and a Google or IA server. People that 4058: 1879: 1471: 1411: 7743: 4511: 3817: 935: 6903:

Hi, could anything be done with the four deadlinks at the Oba Chandler article detected today? :) If so any help is appreciated.--

5924: 5666: 5102:

Anyway, I will replace disp=s with disp=or in that article in due course, but you might like to bear this in mind for the future.

1713:

Please can you check all refs at these pages 1) Lupton family 2) Potternewton 3) Martineau family 4) Headingley 5) Oswald Birley

304:

old computer then, but okay (seriously, what kind of machine are we talking about here?). Luckily, Knowledge has something called

140: 7520: 7407: 5038: 4219: 3121: 3092:

I don't think any of my edits added spaces in front of Ref-tags. Have a look at that diff you linked. There is no such change. --

2695: 1947:

thinks of this. We're increasing our number of (usually crap) articles exponentially and we're fighting silly fires like this. -

4112:

I have not done it, I'm not admin, I was just informing you. admin Materialscientist removed you, you can give your explanation

3693: 2797: 8199: 7730: 7669: 7376: 7115: 5357: 5208: 5111: 3852: 3086: 3020: 1146: 1098: 1004: 232:"currentpositionplain" and "currentposition" should no longer be used, and should be replaced with "position" in all instances; 117: 8117: 7848: 7845:. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. 7491: 7488:. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. 6993: 6966: 6891: 5810: 5737: 5708: 5705:. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. 5378: 5375:. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. 4945: 4319: 4316:. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. 4195: 3733: 3517: 1844: 1841:. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. 193: 190:. Such links are almost always unintended, since a disambiguation page is merely a list of "Did you mean..." article titles. 8055: 7644: 6096:(where applicable). Dropping six characters after a copy-paste from an address bar is not such a hard task, isn't it? Using 5862: 4187: 3949: 3113: 1892: 880:. If it was incorrect, I'm sorry. Google will pick up the correct DOB shortly, don't worry. Good thing that you fixed it. -- 7911: 7715: 7595: 7054: 5456:

that they consider a switch to a secure URL protocol as insignificant and secondary as fixing wrongly piped Wikilinks like

1533: 6684: 4727: 4026: 3472: 3043: 2701:

I totally agree with you. Heck, I spent most of my time on Knowledge fulling out incomplete references. I never meant for

88: 7780: 7078: 7069: 6962: 6912: 6520: 5918: 5906: 5858: 4693: 4362: 4054: 1753: 1723: 7388: 7177: 2424: 1653: 7702:

describes the Committee's roles and responsibilities in greater detail. If you wish to participate, you are welcome to

6507:

A bunch of your edits appeared in my watchlist. Most make sense, but I'm wondering why you reordered some references,

4198:

I converted some external links from HTTP to HTTPS. It's a mere technicality that increases privacy for our readers. --

7154: 4468:

Reasons not to switch, such as https is slower, are no longer the case. https is now faster. Another FYI... the new

4019: 820: 8122: 6598: 5423: 4628:

Bender, if the VPP was moot, you should not have cited it as support for your position. You have been questioned by

4179: 905: 383:

seriously puts me off Knowledge -editing, Please stop. At least stay out of the localities in the areas I mentioned.

294: 8093: 3034:

has apparantly been deprecated. See the link for more info. I also did not know until someone pointed it out to me.

2011:

it does not disrupt any citation style. It's just a little technical tweak that makes sure you leave Knowledge on a

129: 8051: 7636: 6508: 4080: 3030:

Hi Bender235, I noticed you added Persondata to one of the articles which I created. I wanted to let you know that

860: 7804: 5608: 4685: 3721: 3138:

You're right. I'll fix that. Anyhow, protocol-relative URLs no longer make sense since Knowledge is HTTPS-only. --

3007:

says either is fine, and it makes no difference at all to how the article is rendered and presented to the user.

7764: 7711: 5822:

There's an "email this user" button on the left side of your screen that will, obviously, send an email to me. --

5212: 3270: 3265: 2959: 2943: 2882: 1233: 1102: 1008: 429: 356: 305: 7601: 1203:

Thank you - you are right, I somehow missed your vote there. Once again, thank you for taking time to answer! --

8176: 8068: 7551: 4723: 3269:

I really didn't expect this to be so hard to understand. Let me re-phrase it in simple English. The feature of

1789: 1564: 1380:

is installed. It doesn't show up in the icon, but does if you click for more info. More on QUIC can be found

588:

Goto Preferences at the top-right. Uncheck the box that says, "Always use a secure connection when logged in".

6449:

Yep, I also think that there would have to be some sort of filter. But if I'm not mistaken, nothing forbids a

6207:

edit rule to make it convert http to PR links (instead of absolute https) would be so great! Don't you agree?

4030: 526:

wonder why Knowledge is loosing editors! FYI: in my area (partly listed above) I`m hardly a "fringe case";

7837:

Hi. Thank you for your recent edits. Knowledge appreciates your help. We noticed though that when you edited

7480:

Hi. Thank you for your recent edits. Knowledge appreciates your help. We noticed though that when you edited

7011:

has been reviewed, and some issues with it may need to be clarified. Please review the comment(s) underneath

6633: 5770: 5698: 5697:

Hi. Thank you for your recent edits. Knowledge appreciates your help. We noticed though that when you edited

5367:

Hi. Thank you for your recent edits. Knowledge appreciates your help. We noticed though that when you edited

4668:

Thanks for the elaborate answer, and giving me the chance to clear some obvious misunderstandings. The point

4308:

Hi. Thank you for your recent edits. Knowledge appreciates your help. We noticed though that when you edited

4213: 2861: 1833:

Hi. Thank you for your recent edits. Knowledge appreciates your help. We noticed though that when you edited

834:

However, google now seems to have picked up Knowledge, and Google now lists my birthday as October 1, 1952.

825: 182:

Hi. Thank you for your recent edits. Knowledge appreciates your help. We noticed though that when you edited

8086: 6775:

again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on

6398:

We also don't even need to update the hash table immediatly after a new website becomes available through a

6092:

after it was closed. I think that since WP has switched to https by default, it would be much better to use

5281:

again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on

3433:

again to fix it. If I misunderstood what happened, or if you have any questions, you can leave a message on

3382: 841:

I do note that there is at least one online source that gives my correct birthdate, in a bio of my mother.

6641: 4172:

Hello bender, I'd love to know what you changed on Alan Sharps (my grandfather) Knowledge page, thank you

3015: 2785: 1410:, and that I had actually "subscribed" to the tracking bug a bit before, but forgot about it. According to 842: 7941: 7707: 5200: 5153: 4676:

convert each and every link, but only those who offer and encourage the use of HTTPS. One example is the

4309: 3848: 3729: 2947: 2886: 1090: 1046: 996: 952: 160:

Ah yes, AWB is picking up the death date of her son which was added with the Death date template. Thanks

123: 7556: 2640:

Personally, I'd prefer this template would turn into one of those bot-enhanced citation templates, like

1569: 7164:

I thought we agreed that we should use //archive.org/stream/etc, when referring to archive-links? See

5629: 5204: 3082: 2998: 2912:, any time. So that the Google books link would be automatically created from that information and the 2199:

Providing properly formatted citations is difficult enough as it is, without introducing this monster.

1094: 1000: 38: 6918:

I counted four. I fixed them now. But for future reference, doing this is pretty easy: have a look at

3627:"That sort of defective html causes annoyance for screen readers who are led to expect a definition, " 3569:

to remove text-reader problem. So please revert you changes to the bold lines which were changed form

652:

on my computer, and it processes HTTPS links just fine, because it can be (and has been) updated with

7724: 7045: 5789: 5745:

A correction - this links to the wrong footnote: "published by Hard News, in India." - it goes to "

5020: 4841: 4770: 2285:

Does your template support the cs2 citation style for instance Bender? It doesn't seem that it does.

1183: 372: 7983:

likely to be missed because of the sheer number of gnome-ish edits going on. Win some, lose some. -

473:

it, but I have found no way in my preferences to change it. Is it possible to be logged in as Http?

8064: 7969: 7915: 7439: 7403: 7379:

regarding an issue with which you may have been involved. Thank you. ..I think we need more eyes,

7037: 6842:: statisticheskoe issledovanie / pod obshchei redaktsiei. Moscow: OLMA-Press See Tables 52 & 56 5767: 5059: 4845: 4778: 3802: 3454:

1|title=Ballot|publisher=Merriam-Webster Learner’s Dictionary |accessdate=2012-11-07}}</ref: -->

330:

6% of requests from IE 11. Knowledge will not support any browsers that are no longer maintained.

6851:

find-war-dead.aspx/|title=Commonwealth War Graves Commission, Find War Dead accessdate=2014-11-24]

6822:

Military Effort of the British Empire During the Great War 1914–1920'', The War Office, P.674–676

6833:

the Military Effort of the British Empire During the Great War 1914–1920'', The War Office, P.339

6809:

In all, nearly 2,000 men from the Chinese Labour Corps died during the First World War, some as a

6637: 6418: 5902: 5854: 5842:

You've just made a large number of edits, each with a red-linked "this RfC" in the edit summary.

5320:

Nail a Dictator": New Film Tracks Struggle for Justice After Guatemalan Genocide - Democracy Now!

4262: 4228: 2965: 2774: 1873: 1727: 1692: 1657: 1370: 1309: 1245: 56: 6861:(Appendices). Being The Story Of The Part Played In The Great War By The Royal Air Force p. 160 6803:

skycitygallery.com/japan/wwi_chinese_1.pdf|title= THE CHINESE LABOUR CORPS AT THE WESTERN FRONT

5309:

pov/granito/film_description.php] Film Description | Granito: How to Nail a Dictator | POV | PBS

4769:. Also, I'm not going to dig everything out, but there are problematic edits. I will point out 3073:, some of them (adding spaces before ref tags) seem opposite to edits others are making, citing 543:: By "requests" above, what do you mean, people editing Knowledge, or people reading wikipedia? 235:"currentnumber" should no longer be used, and should be replaced with "number" in all instances. 7586: 7064: 6764: 6473:

addresses. It would, later, also examine https and http. But I need to learn more about Tor...

5449: 5269: 5249: 5065: 5011: 3900: 3878: 3844: 3813: 3725: 3669: 3483: 3477: 2623: 2589: 2291: 2205: 2111: 2053: 1819: 1614: 1599: 873: 6144:

I do agree that there is no downside to traffic encryption. But this is not the point. Since:

5169:

While all constructive contributions to Knowledge are appreciated, content or articles may be

4863:

In the end, majority of links will go the https route. Things will really start rolling when

4732: 4421: 4239: 4091: 3287: 3191: 1475: 1236:

in matters related to this subject. Your input in the discussion would be welcome. Thank you,

1059:

While all constructive contributions to Knowledge are appreciated, content or articles may be

965:

While all constructive contributions to Knowledge are appreciated, content or articles may be

8196: 8181: 8148: 8076: 7931: 7883: 7822: 7788: 7754: 7739: 7657: 7461: 7418: 7344: 7316: 7284: 7237: 7192: 7126: 7022: 6983: 6927: 6730: 6702: 6584: 6539: 6440: 6297: 6234: 6163: 6127: 6097: 6062: 5999: 5953: 5881: 5827: 5682: 5619: 5574: 5514: 5485: 5413: 5239: 5124: 5049: 4935: 4887: 4854: 4740: 4611: 4429: 4374: 4289: 4247: 4203: 4153: 4103: 4038: 3995: 3945: 3910: 3889: 3863: 3828: 3788: 3762: 3744: 3704: 3597: 3528: 3390: 3336: 3322: 3301: 3273:

is that the protocol for the link is chosen based on how you entered Knowledge. For example,

3202: 3143: 3097: 3078: 3054: 2988: 2921: 2808: 2764: 2753: 2743: 2705: 2663: 2608: 2533: 2432: 2340: 2254: 2080: 2028: 1987: 1925: 1902: 1743: 1703: 1637: 1502: 1341: 1261: 1194: 925: 885: 723: 691: 662: 513: 459: 313: 259: 244: 151: 113: 7081:, where you can join the project and see a list of open tasks and related articles. Thanks! 6879: 6819:{{cite web|url=https://familysearch.org/search/catalog/292837?availability=Family%20History% 6292:

Google (Books/News/etc.) to become available as .onion at the same time. Highly unlikely. --

5345: 3460: 3286:. This made sense as long as there were two different protocols supported by Knowledge. But 8047: 8039: 7907: 7698:, editing restrictions, and other measures needed to maintain our editing environment. The 7629:

In the preliminary text, just before "Early Life..." the beatification date cited is 1857.

7538:

that an edit performed by you may have introduced errors in referencing. It is as follows:

7393: 7041: 6950: 6896: 6887: 6744: 5798: 5638: 5353: 4963:

that an edit performed by you may have introduced errors in referencing. It is as follows:

4242:. Knowledge in HTTP is no longer available. Thus, protocol-relative links are pointless. -- 4175: 3922: 3468: 3217: 3169: 3031: 2826: 2793: 1771:

that an edit performed by you may have introduced errors in referencing. It is as follows:

1719: 1551:

that an edit performed by you may have introduced errors in referencing. It is as follows:

1522: 1427: 1077: 901: 848: 7795:) to comply with the latest RfC on the matter? If so i would love to comment and help-- 7434:

Citation Bot does the exact opposite of what you are doing, so I asked them to stop it.

7398:

I put in a bug report so that the citation bot will stop converting google books to http.

4882:

Yes, HTTP/2 will be a game changer, but I don't see it widely deployed until the 2020s. --

4602:. Honestly I have no clue why anyone would oppose this other than pure “nobody's touching 8: 8028: 7965: 7703: 7618: 7435: 7399: 7159: 7101: 7092: 6716: 6680: 5753: 5216: 5034: 4348: 4127: 4072: 3156: 3039: 2939: 2878: 2733: 2715: 2246: 1917: 1673:

Lastly, you seem to not to have the faintest idea how to interact with fellow editors. --

1106: 1012: 47: 17: 5599:. Any help is appreciated and I will of course add you to the DYK nom for the article.-- 3592:

Oh, I'm sorry, I didn't know that the semicolon formating is deprecated. Is that new? --

3160: 269: 7543: 6858:

The CWGC figures include military dead outside of combat theaters and civilian workers

6670: 6502: 6031: 5994:

Why would you say so? It's not like Wikimedia is going to switch back to HTTP. Ever. --

5976: 5937: 5893: 5845: 5645: 5537: 5434: 5107: 4565: 4258: 4224: 4167: 3664:). If a screen reader has a problem with such valid HTML, the screen reader is broken. 3540: 3513: 3074: 3025: 2973: 2905: 2867: 2375: 2194: 2001: 1678: 1479: 1295:

Yeah, the discussion at the pump is not looking very good. My hopes were up when Jimbo

1020: 165: 136: 6119: 3638: 3487: 7868: 7859: