Misplaced Pages

Revision as of 23:30, 24 June 2015

• Table of contents
• First discussion
• End of page
• New post

• WP:VPR
• WP:VP/PR
• WP:VPPRO
• WP:PROPS

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• Consider developing your proposal on Misplaced Pages:Village pump (idea lab).
• Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
• Proposed policy changes belong at Misplaced Pages:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Misplaced Pages:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Misplaced Pages:Requested articles.

Centralized discussion Village pumps policy tech proposals idea lab WMF misc Refining the administrator elections process AI-generated images depicting living people Blocks for promotional activity outside of mainspace Voluntary RfAs after resignation Proposed rewrite of WP:BITE LLM/chatbot comments in discussions For a listing of ongoing discussions, see the dashboard. view edit history watch archive talk purge

It's time to abolish the "Ignore the Diacritics" rule everywhere

Reasons:

1. Botching diacritics can be seen as very disrespectful by native speakers;
2. Botching diacritics can be a strong indication that the editor has little or no knowledge/acknoledgement of their functions and/or linguistic/cultural significance;
3. With new generations of computers and tablets becoming more and more available, the "I don't know how to type it" excuse is becoming no longer valid.

Based on the above reasons, I strongly propose that it's time for Misplaced Pages to completely abolish the "ignore the diacritics" rule (or convention or whatever). Cedric tsan cantonais 19:29, 5 May 2015 (UTC)

What rule is that? Where have you seen it being applied? --Redrose64 (talk) 19:46, 5 May 2015 (UTC)

Presumably the guideline at WP:DIACRITICS. Whic does not call to "ignore the Diacritics". -- Gadget850 20:29, 5 May 2015 (UTC)

It might as well. Though the use of diacritics is "neither encouraged nor discouraged", the fact remains that we're instructed to make that decision off the back of English sources, which have - by and large and for the most part - omitted diacritics, for a variety of reasons. Alakzi (talk) 20:38, 5 May 2015 (UTC)

"we're instructed to make that decision" Where? -- Gadget850 21:02, 5 May 2015 (UTC)

It's the first sentence of WP:DIACRITICS. See also MOS:PN#Diacritics, which contradicts it. Alakzi (talk) 21:13, 5 May 2015 (UTC)

WP:DIACRITICS (which, by the way, only applies to article titles), says "when deciding between versions of a word which differ in the use or non-use of modified letters, follow the general usage in reliable sources that are written in the English language." That is pretty easily derived from WP:V (and, by extension, WP:NONENG). If the common usage in English includes diacritics, that is what's used in the English Misplaced Pages. If the native language uses diacritics but English doesn't, then neither does the English Misplaced Pages.

However, the original poster seems to be referring to this diff, in which User:Canuckian89 said that "Misplaced Pages convention is that diacritics aren't used on NHL-related pages". That is referring to Misplaced Pages:Naming conventions (ice hockey), which states "All North American hockey pages should have player names without diacritics, except where their use is likewise customary (specifically, in the Quebec Major Junior Hockey League and the Ligue Nord-Américaine de Hockey)." That wording was put in by User:Djsasso in 2003 — previously the guideline stated that they should use "most common spelling in English as described by reputable reference books and media outlets. In most cases this means the omission of diacritics and other characters not commonly found in English.", which is in line with WP:V and WP:NONENG. --Ahecht (TALK
PAGE) 21:18, 5 May 2015 (UTC)

@Ahecht Thank you. This is the very first convention that I seek to repeal. As for references, I would argue that if we are willing to look at sources in other languages (which, according to my experiences, are equally valid in English Misplaced Pages), there're plenty of sources indicating the correct use of diacritics. For example, in this news release by the Czech Ice Hockey Association, more than one NHL players, including Petr Průcha, David Krejčí and Zdeno Chára, are mentioned and the diacritics in theirs names. Also, the Czech were nice enough to keep all diacritics in players' names, regardless of the languages they're in. All these are making Misplaced Pages:Naming conventions (ice hockey), which tries to justify botching diacritics, invalid. Also, if TSN and ESPN are seen as valid sources, the Czech Ice Hockey Association just can't be any less valid. Cedric tsan cantonais 22:01, 5 May 2015 (UTC)

If the problem is specific to Misplaced Pages:Naming conventions (ice hockey), why discuss it here, not at Misplaced Pages talk:Naming conventions (ice hockey) (plus an advisory note to WT:WikiProject Ice Hockey). --Redrose64 (talk) 22:54, 5 May 2015 (UTC)

I wouldn't say that non-english sources are "equally valid in English Misplaced Pages". WP:NONENG says "However, because this is the English-language Misplaced Pages, English-language sources are preferred over non-English ones whenever English sources of equal quality and relevance are available." --Ahecht (TALK
PAGE) 23:23, 5 May 2015 (UTC)

The key words here are whenever English sources of equal quality and relevance are available". In terms of diacritics, I would argue that there are little or no English sources "of equal quality and relevance" available, due to my observation that many English sources, other than English Misplaced Pages, would already botch the diacritics before making their way into English Misplaced Pages and, therefore, cannot match the quality and relevance of certain non-English sources. Henceforth, my argument that certain non-English sources, like the news release I posted above, should be deemed equally valid in the case of diacritics.

Also, since my main focus is on Cantonese Misplaced Pages, I don't edit English Misplaced Pages as much and that's why I wasn't aware of the existence of Misplaced Pages:Naming conventions (ice hockey). But now that I know there's this convention, I'll start working on getting the "ignore the diacritics" part amended or abolished.Cedric tsan cantonais 00:08, 6 May 2015 (UTC)

You say "my observation that many English sources... botch the diacritics". You're saying English Sources are "botching" how things are written in English. Even if you're right, Misplaced Pages is not the place to try to fix it. We follow the sources, we don't lead. Alsee (talk) 05:44, 6 May 2015 (UTC)

I'm not "leading". I'm just cherry-picking the best sources to follow. In the case of diacritics, many non-English sources had proven themselves more trust-worthy than their English counterparts. — Cedric tsan cantonais 17:36, 6 May 2015 (UTC)

• As one of the parties of the compromise over on the hockey WikiProject, I've got two cents to throw in. The compromise was the truce in a long and contentious edit war involving many editors (myself included) and many articles. No one was really happy with it, and there've been a couple attempts over the years since to overturn it, but it's kept the edit warring down to a dull roar.

  My strong preference was then, and remains, to recognize that this is the English Misplaced Pages; not the Czech, not the French, not the Swedish or Finnish or Viet or any other national Misplaced Pages that commonly uses diacritics. The English language does not, for the most part, use diacritical marks. I would be thrilled to see WP:DIACRITICS extended project-wide, the hockey articles included. That being said, it's obvious from the guideline itself that private compromises have been enacted -- this MOS section dealing with Ireland-related articles, for one -- and I don't see any horde of editors coming in to force a change to go over any better than it would have on what I see from archives was a long and bitter dispute on those articles. Ravenswing 01:59, 6 May 2015 (UTC)

• I have the same but opposite opinion as Ravenswing. I think they should be used everywhere because they are proper names and as such don't change between languages so if they have diacritics on one they have diacritics in the other. That being said, what Ravenswing says about it being a compromise is true. Diacritics have been an all out war at times on the wiki and the battle over them has left many people on both sides of the issue blocked and/or banned. As such the hockey project for hockey articles in the absence of a true wiki-wide consensus came to a consensus to damper down the edit warring that was constantly on going. It is a topic I generally recommend editors staying away from and usually counsel people to leave it like you found it in the same vein as ENGVAR. I would note the edit of mine being referenced above goes back farther than 2013, it was just added to that particular page at that point, however, it had been listed elsewhere for years before that. -DJSasso (talk) 13:52, 6 May 2015 (UTC)

• I would be shocked to see WP:DIACRITICS extended project-wide since that would be a major sign of collective ignorance. I'm considering adding reference(s) whenever I'm writing diacritics. This is kind of a last-resort measure but now that I know there's such strong opposition towards diacritics, I've got little choice. — Cedric tsan cantonais 17:36, 6 May 2015 (UTC)

• I think many people would view something like that as being disruptive to make a point. Resolute 20:17, 8 May 2015 (UTC)

• I see no reason to change anything here. I'd say 99.3% of the time diacritics aren't appropriate on the English Misplaced Pages because they are not in the English alphabet. I'll counter your claim that they are proper names and as such don't change between languages so if they have diacritics on one they have diacritics in the other with Hillary Clinton - Hilarė Klėntuon - Hillary Clintonová or maybe even Гілары Клінтан from the collapsed section in support #53 of Talk:Hillary Rodham Clinton/April 2015 move request#Support. We're not using Hilarė Klėntuon because this is English, in the same light, diacritics don't belong on other names in English. Now, as for the claim that "the "I don't know how to type it" excuse is becoming no longer valid, I'm not buying that either, my English qwerty keyboard still doesn't support those characters without knowing the unicode values for each, and to expect anyone to have a huge chart on the wall or know which character means what is unreasonable. — {{U|Technical 13}} 04:13, 7 May 2015 (UTC)
  • And that is a strawman, Hilarė Klėntuon or Hillary Clintonová are not her name. If they were, and if they were what she used for her name, then yes they would be completely appropriate. You don't need a huge chart on the wall to know what the characters mean, if you don't know what they mean you ignore them just like you are seeking to do in print. As for typing it, its great that the edit box actually has them included so you don't have to know the unicode values, you just click a link. They aren't in the English Alphabet but they are in the English Orthography. -DJSasso (talk) 13:29, 7 May 2015 (UTC)
  • Have you ever visited any Vietnamese article? You might be nonplussed. Alakzi (talk) 13:45, 7 May 2015 (UTC)
  • With all due respect, saying that they (diacritics) are not in the English alphabet only shows that you have nearly zero knowledge of English history. Back in the old days, "one, two, three, four" used to be written as "ān, twā, þrēo, fēowor" — and, still, I don't think anyone can argue that "these are not English words". As for typing, I use a QWERTY keyboard, too, but typing alphabets like áàêęçţčạẇėīōåøœæłțůžĉĝñẽã#€ëýȳÿ are almost as easy as one-two-three (and I don't even need to bring up the special character panel below the edit box). Of course, this took me quite a bit of practise, ḃůţ ħéÿ, ṗřæċťïşẽ ṁąḱęś ṕèřƒēçť! —Cedric tsan cantonais 16:24, 7 May 2015 (UTC)
    • Using that argument suggests that you have a poor knowledge of English history. You do understand, don't you, that however much the English alphabet was different half a thousand years ago, we're editing here on the English Misplaced Pages, not the Middle English Misplaced Pages? Your argument is the moral equivalent of claiming that Americans are still subjects of the British Crown, just because they happened to be a few centuries ago. Yogh, thorn, eth, and wynn haven't been in the English language in several centuries, and neither are diacritical marks. Ravenswing 11:43, 8 May 2015 (UTC)
      • You know what? I'm pretty sure that English had already adopted Latin alphabets by the time Beowulf became codified. And yes, I'm totally aware that ð, þ, ƿ, etc., used to be alphabets of Old English, and I would totally advocate re-adopting at least ð and þ. And no, that does not equal me arguing that US citizens are still British subjects because the US had already declared their independence while you never specified which period of English we're talking about. OTOH, arguing that diacritical marks haven't been in the English language is simply ignorant. As far as I know, New York Times, for example, is sticking to café rather than cafe, and I don't think you can argue that "café" is not an English word now, can you? Cedric tsan cantonais 16:50, 8 May 2015 (UTC)
• Do I get this right, Motörhead, Hüsker Dü, Blue Öyster Cult are wrongly named lemma because there is no diacritical sign in the poor english language? European top footballers like Petr Čech, Tomáš Rosický, Tomáš Ujfaluši, Thomas Müller, Jérôme Boateng, André Schürrle, İlkay Gündoğan and so forth (I just looked up Čech and German) should be dumbed down as well? That would be a great loss. The article should be proper named, the dumbed-down diacritic-less version should be a redirect imho. Grüße vom Sänger ♫ 14:01, 8 May 2015 (UTC)
  • Well, I would say the heavy metal umlat is less a problem of language, and more one of trademark. Resolute 20:17, 8 May 2015 (UTC)

• This debate is ultimately a rehash of one that has long plagued the project. And, as with Ravenswing and DJSasso above, I am one of the editors that helped draft the compromise that brought about a truce in WP:HOCKEY's diacritics war. (The short version of the compromise is that NHL and NA team/league articles hide them, while European articles and all player articles show them.) At the time, I was one of the people with the "English Alphabet" mentality, but have subsequently 'switched sides' and favour their use. But from either perspective, and recognizing the overall lack of consensus, I think our compromise does a good job of maintaining order at this point in time. Though it should be noted that times are changing, as diacritical marks are slowly making appearances on NA team hockey jerseys, publications, etc. But that is in its infancy, and I don't see a need to revisit this now. Resolute 20:17, 8 May 2015 (UTC)
  • I beg to differ, sir/madam. As the means of inputting diacritics became more and more easily accessible, I would argue that now is the time for the pro-diacritic side to at least make a push to popularise diacritics (provided that they're used correctly, of course). And by "making a push", I mean that the pro-diacritic side should initiate conversations in order to make diacritics more and more widely accepted. Also, I think now is the time to amend the rules so when pro-diacritic users open up new articles with diacritics, anti-diacritic users won't be able to mess things around in these new articles and push them back into the Old Régime. Cedric tsan cantonais 18:05, 10 May 2015 (UTC)
    • It is not Misplaced Pages's place to right great wrongs. Nor is it our place to popularize diacritics. I sympathize with your viewpoint, but it will be some time yet before the movement of technology reaches the point where a consensus will form in your favour on Misplaced Pages. Resolute 18:08, 10 May 2015 (UTC)
      • In that case, I'll just keep telling others to "stop f*cking around on the pages that I opened", even though it wouldn't be likely for me to open up that many articles on English Misplaced Pages since Cantonese Wiki Projects remain my priority. — Cedric tsan cantonais 21:34, 10 May 2015 (UTC)
• The issue boils down to WP:COMMONNAME and the US/UK news media's inability to deal with diacritics in a sensible fashion. Most 'foreigners' new topics are introduced via the news media so their known-as names are those used by the media. The media refuses to deal with diacritics. Therefore WP:COMMONNAME is typically the topics true name minus the diacritics. Personally I prefer to use VIAF for preferred ASCII renderings of non-ASCII names where possible. Stuartyeates (talk) 22:05, 10 May 2015 (UTC)

  With all due respect, sir/madam, I prefer Unicode. :P — CÉDRIC TSÄN CANTONAIS SAYS NO TO I.P. EDITS! 17:31, 13 May 2015 (UTC)

• It feels weird to have this discussion without User:PBS involved. Also, why isn't this discussion about a general rule over at the talk page for the actual rule? WhatamIdoing (talk) 05:45, 17 May 2015 (UTC)

Thanks for the heads up WhatamIdoing. The title of this section says It's time to abolish the "Ignore the Diacritics" rule everywhere. There is not such rule what rules there are say follow usage in reliable English language sources.

The arguments based on WP:COMMONNAME—for which I think the link WP:UCRN (Use commonly recognizable names) is preferable—which is an important part of the Article titles policy is limited in scope to article titles. As is the guidance given in the policy section called "Foreign names and anglicization" (link WP:UE) and the explanatory guidelines called Misplaced Pages:Naming conventions (use English) as section of which called "Modified letters" (link WP:DIACRITICS)

The sections of the MOS that covers usage within articles (other than the subject of an article) is MOS:FOREIGN and also Misplaced Pages:Manual of Style/Proper names § Diacritics.

The fundamental problem here is exactly the same as spelling in general. If one reads a paragraph that contains an unusual spelling such as color/colour and it is not in ones own dialect it tends to look odd, and editors will wish to change it. This was the driving force behind the creation of the rule about MOS:ENGVAR—and it is something that some third party style guides also describe (see here). The use of accent marks on names tends to spark the same annoyance as "incorrect" spellings. This tends to split the community by native monoglot English speakers/reader and those familiar with the presentation of the word in another language. For example I would imagine that most French people reading English Misplaced Pages see nothing odd in the use of Ivory Coast but if the name used is "Cote d'Ivoire" then it will bother them because they will be used to seeing it as "Côte d'Ivoire and like the color/colour spelling may wish to "correct" it.

On the alphabet. When one is at school in the English speaking world the alphabet is the 26 letter of the alphabet song, it does not include "&" or any other character. Accent marks are not introduced to children until they learn a "Foreign" language (this includes words such as cafe/café which if the child notices will be explained ways as a foreign word not yet fully Anglicised), so consequently accent marks are seen by most English speakers as a foreign things (blame it on teachers). Now I know that some English speakers are passionate about using the "correct" accent marks on words but they (both the users and the letters) are often seen as eccentric or pretentious by monglot English speakers, (an example of this comes across on pronunciation as well for words like Porsche#Pronunciation of "Porsche" those who pronounce it the German way are assumed either to own one or want to own one).

Faced with the instability this problem of "it does not look right", the Misplaced Pages community has several options.

• No guidance at all and a local consensus for each article. This was ruled out for the same reason that MOS:ENGVAR exists. Article content becomes unstable as people care passionately about this issue and some will edit war over it, so the community needed to issues guidance that reflects a wider community view.
• Guidance that accent marks will never be used.
• Guidance that accent marks will always be used.
• Guidance based on a rule similar to the Economist guideline that those languages which a generally educated person in an English language country ought to know, eg French for the British, Spanish for Americans, (the Economist also includes German and Portuguese).
• Guidance based on English usage. The first advantage of this one is simple to implement and it is less arbitrary than the Economist rule eg why German and not Italian? The second advantage is it produces spellings with "least surprise" for the majority of readers and therefore probably causes the least annoyance. Third it is simple to understand and ties in with the concepts behind "Use commonly recognizable names" (WP:UCRN) which in turn is based on the policy WP:V.

So while following usage in reliable English language sources does not always produce the "best" results, it has proved a reasonable and sustainable method for settling disputes over the "best" spelling to use for many years, because using sources to prove a point is widely used when trying to reach a consensus in many areas of disagreement in on Wikiepdia talk pages. For example the initiator of this section uses a source to make a point:

"As far as I know, New York Times, for example, is sticking to café rather than cafe, and I don't think you can argue that "café" is not an English word now, can you? Cedric tsan cantonais"

This is how the policy is meant to work and it come naturally into play among experienced Wikipedians because it is so frequently used in debates about titles and content. And user:Cedric tsan cantonais when you wished to show that "café" is an English spelling you turned to an authoritative English language source; you did not use a French source such as here (the first page of who's survey seems to contradict your findings). But your point still stands, as does mine that when we as editors discuss the "correct" usage of "Cafe" and "Café" we turn to reliable English language sources to decide on English language usage, and that is what the policies and guidelines reflect. We may or may not disagree on which spelling we think looks better (is more correct), or whatever, but providing we are editing in good faith, even if we do not agree on those issues, we may well be able to agree on what is most frequently used in English reliable sources (even if we we are surprised by the finding and do not like the result). The guidance only breaks down when someone ignores usage (or plays the system by arguing that only sources that reflect their bias are reliable), because as editors editing in good faith, we can always go back to whatever the original usage was if reliable sources do not give a definitive answer. -- PBS (talk) 11:32, 17 May 2015 (UTC)

My two cents: Most of you are looking at this issue too narrowly. You're thinking of words or names in languages you're familiar with (like French in many of the examples), and think the only problem is diacritics on one or two letters. It isn't! Many other languages have have alphabets that have diverged more from the English (i.e, Latin) one than French did. These other languages have not only diacritics, but also additional or bizarrely modified letters, and worse, letters that look like English but are pronounced differently from their English cousin. The end of this spectrum are languages with completely different character shapes from English (e.g., Hebrew, Greek, Russian) or no alphabet at all (e.g., Chinese). At which point do we stop copying the topic's original native name, and start transliterating it into English? This is why we have an article called "Beijing", not "北京市", and "Pasha" not "paşa", because English speakers cannot read, and do not use, these foreign characters, so those are not useful as article names (but can appear in parantheses in the opening paragraph, of course). And if we do transliterate, it should be into some sort of commonly used English - not some phonetic alphabet. Check out http://en.wikipedia.org/Talk:Nazareth_Illit, where while everyone agreed that Hebrew names (in Hebrew letters) cannot be the name of English wikipedia articles, there was an argument whether the names of the articles should be some sort of theoretic transliteration nobody is familiar with, or the more commonly accepted simple transliteration into English.

87.69.227.74 (talk) 11:06, 18 May 2015 (UTC)

For those who claim that English uses its own "English alphabet", I have a simple message. There is no such thing as the ”English alphabet". English, like many other European languages, uses the Latin alphabet. It just doesn't use every possible letter available in that alphabet. Because of this convenience I myself, whose native language is Dutch, can read English without having to learn a different alphabet beforehand. And this example counts for any combination of languages which use the Latin alphabet. Russian, just like English, doesn't have its exclusive alphabet either. It uses the Cyrillic alphabet. Using or not using diacritics is not just a question of aesthetics, but actually one of spelling and, more importantly, pronunciation. Writing Petr Cech instead of Petr Čech provokes an entirely different and wrong pronunciation. Therefore we simply cannot ignore these characters. Transliterating should only between languages that use different alphabets or syllabaries (e.g. Kanji to Latin, Cyrillic to Latin,...). This is not the England (or even United States) wikipedia. This is an international encyclopedia, and this one is uses by many users, just like me, don't have English as a native language as well. Just claiming that all English speakers cannot read these "foreign" characters is blatantly ridiculous. We should really accept that millions of none native English speakers read this wikipedia as well. Therefore I support Cedric tsan cantonais's proposal to ditch this censoring of these characters which are even part of our alphabet. Tvx1 17:08, 18 May 2015 (UTC)

I agree with Tvx1's point. But I cannot let the claim 'There is no such thing as the ”English alphabet"' stand. Here is the English alphabet: ABCDEFGHIJKLMNOPQRSTUVWXYZ. Here is the Polish alphabet: AĄBCĆDEĘFGHIJKLŁMNŃOÓPRSŚTUWYZŹŻ. Both are derived from the classical Latin alphabet ABCDEFGHIKLMNOPQRSTVXYZ. Maproom (talk) 06:14, 22 May 2015 (UTC)

FWIW, no "support" or "oppose" !vote will have much weight here unless a proper WP:RFC is created. And I wish anyone who attempts it good fortune as I can tell you right now it will end as no consensus. Resolute 17:18, 18 May 2015 (UTC)

@User:Tvx1 you write "There is no such thing as the ”English alphabet”". As I said above disputes are often resolved by looking at sources. What is your reliable source for that statement? Because a search of Google Books of "English-alphabet" states "about 89,600 results" and it returns 960 books, the same search but limited to the 21st century states "about 13,900 results" and about 670 books. which refutes your statement. There is a Classical Latin Alphabet (which was derived from an earlier alphabet) from which the English Alphabet is derived, but contains its own extensions such as "W", other languages have their own alphabets derived from the Classical Latin Alphabet their own additions or subtractions. Those that are derived from the Classical Latin Alphabet can be amalgamated into what is today called the "Extended Latin Alphabet" (or "Latin Alphabet" for brevity), but whether that concept existed and was commonly used before 1960 and the need for a term in computer science I know not, however a search of Google books for "Extended Latin Alphabet" (About 1,740 results) tellingly returns "Extended Latin Alphabet Character Set for Bibliographic Use" ISO (1975) as the second oldest use of the term with one mention the year before.. -- PBS (talk) 10:16, 19 May 2015 (UTC)

Boy do I differ with Tvx1 on this one. This is an English based Misplaced Pages. That's why we have so many different language encyclopedias to choose from. We use English sourcing whenever possible and we use the English alphabet when English sources lead us in that direction. We don't complain when the Serbian Misplaced Pages does strange things to US spellings nor should they when we do the same. We simply follow the English sources and use what the sources show us. Fyunck(click) (talk) 09:56, 21 May 2015 (UTC)

(Totally OT, why not Fyunch(click)?) --Thnidu (talk) 03:37, 30 May 2015 (UTC)

Oppose further use of diacritics - Fyunck hits the nail squarely on the head. Let's review some basic realities and first principles:

1. This is the English language Misplaced Pages;
2. The English language Misplaced Pages is written in English to serve readers who read English;
3. English is the native tongue of the overwhelming majority of English language readers of Misplaced Pages;
4. The overwhelming majority of native English speakers are completely unfamiliar with the diacritics added to the Latin alphabet in the Croatian, Czech, Danish, Estonian, German, Hungarian, Latvian, Lithuanian, Norwegian, Polish, Serbian, Slovak, Slovene, Turkish, Vietnamese.
5. Only a small percentage of English-speaking specialists learn these languages in American, British or Commonwealth secondary schools and universities. To the extent Americans learn a foreign language in high school or university, the overwhelming majority study Spanish or French. In short, the overwhelming majority of native English speakers cannot read or write a foreign language that makes widespread use of diacritical marks.
6. The standard QWERTY keyboard in use throughout the English-speaking world does not include diacritics, and cannot produce diacritical marks without resort to the alternative ASCII alternative character sets -- which requires not only some understanding of spelling in the particular foreign language, but also knowledge of the ASCII character maps and ASCII character codes.
7. To the extent the spelling and/or use of diacritical marks differ for an article title or subject, including proper names, we can and we should identify those differences in the first sentence of the lead of the article.
8. To the extent the spelling and/or use of diacritical marks differ for an article title or subject, including proper names, we can and we should create redirects from spellings with diacritical marks to standard English article titles without diacritics.
9. None of this intended as a slight to our international readers whose first language is not English; we love y'all and we appreciate your readership and editorial contributions, but demanding that native English speakers adopt foreign orthography for the English language Misplaced Pages is a bit over-the-top. One can only imagine the reaction of editors of the German, Hungarian or Serbian Wikipedias if native English writers demanded that those Wikis adopt English spelling and a diacritics-free orthography for articles about American, Australian, British, Canadian, Irish, and New Zealand subjects.
10. Bottom line: Misplaced Pages should follow the standard majority practices of mainstream publications in the English language when comes to the use of foreign diacritics and orthography. That means omitting the diacritics in the vast majority of cases.

Dirtlawyer1 (talk) 11:39, 21 May 2015 (UTC)

I'm not convinced that diacritics posit any major problem to English speakers. Firstly, technical issues are pretty much non-existent: search engines have got no trouble finding these pages, and we've set up redirects from diacritic-less titles, etc. Secondly, if a speaker of English cannot parse the diacritics, would they not read the text as they normally would? What good does stripping Latin-alphabet names of their diacritics do? Alakzi (talk) 12:00, 21 May 2015 (UTC)

Correction, the standard QUERTY keyboard can produce diacritics simply if the correct operating system is used. It has been simple to include many diacritics on the Macintosh since its inceptions and mobile keyboards make it even easier. Not to detract from the argument though, Windows and Linux do not, allow the easy addition of diacritics.

With that said, the remainder of the arguments are sound and one is missing but alluded to in the conclusion: how do the majority of English-language sources present the name? 208.81.212.222 (talk) 18:19, 21 May 2015 (UTC)

Unfortunately, 208.81.212.222/Anonymous, getting "the correct operating system" is not a very convenient operation for a user who needs it. If you ain't got it, you ain't gonna get it with a "command-control-shift-alt-OS"! --Thnidu (talk) 03:53, 30 May 2015 (UTC)

It's not a question of creating problems, although I give up on many tennis player names once too many diacritics start pouring in. It's a question on what is used in English sources and what the title should be. I'm not saying we shouldn't also mention the foreign spelling, of course we should. But for normal everyday usage we should use standard English as sourced from English sources. If that tells us to use résumé instead of resume then that's what we use. If it tells us to use Zurich instead of Zürich then ditto. We let everyone know alternate spellings exist and move on. It even causes problems when trying to copy and paste a tennis player name from wikipedia into huge databases like the International Tennis Federation. Unless you use standard English it comes back as "not found." So I use a "follow the English sources" viewpoint. If there really aren't any English sources then we move out and use other sources at our disposal. But today we are forced, yes forced, to use diacritics in tennis player names, even if 99% of sources do not. Often even if a player has dropped the use of them herself. And we are not allowed to even mention that a standard English version exists in 99% of sources, lest the diacritic police come down on us like thunder. English versions of player names are banished forever per tennis RfC. I don't fight it anymore unless I can prove that a player uses the non-diacritic version on their own websites, facebook and twitter accounts. It just isn't worth it. I don't know what is taught in Canadian or Australian schools, but US schools don't teach them. They only let us know they exist because a few words still use them on occasion. Fyunck(click) (talk) 19:17, 21 May 2015 (UTC)

I just happened upon this because I was on the page for a different query. I do agree with the OP for the reasons given, and because that's what redirects are for. The article title (and text), whether for a person or a place name, etc., should always be spelled with whatever diacritics are used by the person or place, with however many redirects as may be useful to help people find the article. I honestly don't understand why this should be controversial. Milkunderwood (talk) 04:14, 23 May 2015 (UTC)

Should we also put our Sevastopol article at Севасто́поль? Should we put our Tokyo article at 東京? That's what your logic proposes, using the original language spelling. The other argument is that we follow the sources. If Reliable Sources say the moon is made out of cheese, then we say the moon is made out of cheese. If the sources are wrong, Misplaced Pages is not a place to WP:RIGHTGREATWRONGS. If Reliable Sources say the English spelling for "Севасто́поль" is "Sevastopol", then we put the article at the English-language title "Sevastopol". If the sources are wrong, Misplaced Pages is not a place to WP:RIGHTGREATWRONGS. If Reliable Sources say the English spelling for "Tomáš Berdych" is "Tomas Berdych", the article should be at "Tomas Berdych". If the sources are wrong, Misplaced Pages is not a place to WP:RIGHTGREATWRONGS. Alsee (talk) 18:42, 23 May 2015 (UTC)

Expanding my comment, Google Search finds zero hits at the New York Times for "Tomáš Berdych", but 1330 hits for "Tomas Berdych". An argument that the New York Times misspelled something 1330 times isn't an argument that belongs on Misplaced Pages. A global Google Search for "Tomáš Berdych" -"Tomas Berdych" gives 1.1 million hits, and eight of the top ten hits are English Misplaced Pages, Croatian Misplaced Pages, four Czech language hits, and a pair of twitter hits. A global Google Search for "Tomas Berdych" -"Tomáš Berdych" gives 3.2 million hits, and the only one that isn't an English Reliable Source is an instagram hit. Why the heck do we have this article at Tomáš Berdych?? New York Times, Google, and almost all English Language Reliable Sources say that Севасто́поль is spelled Sevastopol in English, and Tomáš Berdych is spelled Tomas Berdych in English. Alsee (talk) 19:43, 23 May 2015 (UTC)

Re: "Should we also put our Sevastopol article at Севасто́поль? Should we put our Tokyo article at 東京?" That's an obvious red herring fallacy. Different writing systems (scripts) are not comparable to adding diacritics to Latin script. If I paint some stripes on my cat that doesn't make it comparable to a tiger. As for Tomáš Berdych/Tomas Berdych, the fact that you can find an isolated example of an article that may not be reliably sourced for the diacritics it uses is meaningless to the questions at issue here. I can probably find a rock star article that doesn't cite a source for its discography, but that doesn't mean rock star articles should categorically have their discographies deleted. You're certainly correct that WP:GREATWRONGS applies here, but it would be particularly directed at the kind of sustained campaign that's been going on for years by a handful of editors to rid Misplaced Pages and the rest of the English speaking world of the sinister menace of diacritics.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  13:27, 24 May 2015 (UTC)

• Comment (on original post and some responses to it): We're already mostly using diacritics where appropriate, and moving more toward doing so, despite years of tendentious WP:ADVOCACY against them by a handful of editors. So I don't see the point of the vague proposal. If there's an actual conflict between WP:DIACRITICS and MOS:PN#Diacritics, then normalize to what the MOS page says. MOS governs style, and the naming conventions (even WP:AT policy itself) defers to MOS on style matters, naturally. Conflicts between MOS and NC guidelines are uncommon, but as far as I can recall are always resolved in favor of what MOS says. E.g. the whole species common name capitalization mess we had for several years, with WP:NCFAUNA, WP:NCFLORA, MOS:LIFE, and I think some other page, too, all saying conflicting things, has long been normalized to what MOS:LIFE says. What was probably the single most WP:ACTIVIST RfC campaign in Misplaced Pages history, WP:BIRDCON, failed to gain consensus to change MOS:LIFE to follow what proponents of the now-rejected changes at NCFAUNA were advocating. That's a really strong precedent for cases like this.

  As for diacritics in particular, the problem with "most tennis sources don't use the diacritics" as some kind of WP style and titles rationale is that the reason they don't is expediency/laziness/disregard, not accuracy. Such sources are not reliable for what the proper form of a name is. Where we have reliable sources that demonstrate that someone's/something's name has a diacritic, then that fact about the styling of the name is reliably established. No amount of sources that just can't be bothered with it (including piles of random websites pulled up in Google searches, or publications of sports governing bodies who jingoistically refuse to respect diacritics) can undo this fact of verifiability. Journalistic (especially tabloid, news daily, television, and sportswriting) sources are utterly unreliable on this, because they are under intense deadline pressure, have editorial control almost entirely focused on getting reported main-story facts like dates and places and statistics and quotations fact-checked, are written for the lowest-common-denominator audience, and are mostly written by people who historically probably didn't know how to generate diacritics without looking it up in a manual. Yet even these kinds of sources are increasingly respecting diacritics, as it gets easier to do so and more expected in anglophone countries. People who live in less ethnically diverse places like Idaho or whatever are probably somewhat less aware of this than those who live in more culturally mixed places like Montreal, California, and Ireland, where names of everyday people, from local politicians to the very newscasters they're watching, often have diacritics. It's an obvious WP:SYSTEMICBIAS matter. Furthermore, it's downright absurd to suppose that we'd disrespect the proper styling of the names of thousands of subjects, many of them BLPs, simply because they're tennis players (or whatever) instead of physicists or painters. It's just not a rational result.

  We've all been over, again and again and again, at WT:AT, WT:MOS, WT:NCP, WP:RM, and many other places, how a WP:COMMONNAME analysis tells us what the common (or only real) name is (Sinéad O'Connor vs. Shinaid O. Conner), but does not govern how we style the name (Sinéad O'Connor vs Sinead O'Connor), which is a WP:MOS matter, determined in each case by the same kind of normal WP:RS analysis used to establish any other article fact. Re-re-re-raising a pretense of confusion or doubt about this at VP doesn't magically actually establish any confusion or doubt. It's just another stop in a long tour of WP:FORUMSHOPPING. This is a perennial waste of editorial time and energy.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  13:27, 24 May 2015 (UTC)

I agree with your points about a campaign by a handful of editors, about WP:FORUMSHOPPING, about a perennial waste of editorial time and energy. However you accuse the the New York Times of being "lazy" and "utterly unreliable". You accuse essentially the entire English Speaking World of WP:SYSTEMICBIAS. Even if New York Times is "lazy" and "utterly unreliable", even if English Speaking World has WP:SYSTEMICBIAS, Misplaced Pages is not a place to try to fix the outside world. Common usage by the English speaking world defines what is or is not English. The fact is that most English Sources consider the "English Language" to consist exclusively of A-Z and a-z. Exceptions to that practice are rare and extremely notable-as-exceptions. Most English sources translate the name "Пу́тин" into the English language as "Putin". Most English sources translate the name "Tomáš" into the English language as "Tomas". Translation is not "laziness". Our articles should have Пу́тин and Tomáš in the lead sentence, just as our Tokyo article has 東京 in the lead sentence. But our English article titles and English article prose normally shouldn't use the characters и š or 東 when the New York Times and other common English usage don't consider them a normal part of English prose.

Your argument is that the New York Times should stop translating Tomáš. Arguments about what the outside world should do, do not belong here. Alsee (talk) 01:58, 27 May 2015 (UTC)

@Alsee: I'll reply to this just so you know where the holes in your arguments are, but I'm collapsing it because they're obvious enough, no one else needs to wade through it.

 — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  01:56, 28 May 2015 (UTC)

Tomas is not a "translation" of Tomáš, that would be Tomash, but a lazy simplification and disregard for proper pronunciation. Simply ditching important pronunciation marks is just lazy. The 2 dots above my nick change the pronounciation of the "a" from to . These are definitely not the same letters. Grüße vom Sänger ♫ 17:38, 28 May 2015 (UTC)

Actually in US English those two dots mean absolutely nothing (same with the ü and ß. We pronounce things the way teachers or others pronounce things. It's not like we are taught about diacritics.... unless perhaps we take an advanced linguistics course at a university, or maybe we see them when taking a foreign language course. The few English words with them are taught as anomalies or perhaps a fancy way of doing things like when we occasionally see café on signs instead of the normal cafe. We are taught they eventually fade away as they become a hindrance to writing and reading. I don't know what is taught in Canadian, UK or Australian schools so perhaps it's different there? Fyunck(click) (talk) 18:23, 28 May 2015 (UTC)

My sig in proper diacritic-free version should be "Gruesse vom Saenger", as ä=ae, ö=oe and ß=ss (or sometimes sz, but not with the czech pronunciation ;).

There is only one way to proper pronounce a persons names, and that is in the native language of the named person, only with geographic objects there are sometimes real translations that deviate from the "real" one, like München/Munich or Moskow/Moskwa. So you either have to use diacritics, or transscribe it to plain letters with the same english pronunciation, that's or Tomash, not Tomas, or what other solutions do you know to get the proper pronunciation across? --Grüße vom Sänger ♫ 05:44, 29 May 2015 (UTC)

That's your own viewpoint and not backed up by 99% of sourcing. Your name spelling in English is usually what English sources tell us it is, not what you tell us it is. My family name in Polish is Kołodziej, in English it's Kolodziej. We don't spell it with a "w" here. And when older relatives travel back to Poland they may or may not switch back to Kołodziej. English is very versatile in that its letters take on all kinds of sounds without needing diacritics. If someone wants to make a Z sound like a K in English we simply tell people that's how we pronounce it. We don't re-spell it phonetically. However to avoid confusion we would drop the B looking letter and make it ss as with "Johann Strauss." Now of course, Misplaced Pages can do what it likes by consensus. If enough editors agree it can certainly follow non-English sources rather than English sources. It does that often. But that won't change the English language or how it's taught outside of Misplaced Pages. Fyunck(click) (talk) 06:13, 29 May 2015 (UTC)

If you move to a foreign country and want to use your name there in the native writing in that land you have to decide for yourself how to do this: Rewrite your name that the pronunciation of the new spelling fits to the right pronunciation or ditch the right pronunciation and keep the spelling. Or even translate if possible to something completely different sounding with the same meaning. I know of an example where two brothers did so in different ways in my home village: The dutch "u" ist pronounced like the german "ü", and their name derived from Holland and includen an "u". One decided to be pronounced with an "u", the other changed his name to an "ü". (I would have a problem with the same letter if I moved to Holland, I had to choose whether tu change the letter to "oe" to keep the proper pronunciation or keep the letter and thus change it.

But that has only tangential relation with this topic here, as here it's about peoples names that still live in that country and thus have only one proper pronunciation and no need to decide anything. It's up to enWP to decide whether to respect their names and proper pronunciations or not. Grüße vom Sänger ♫ 09:22, 29 May 2015 (UTC)

"There is only one way to proper pronounce a persons names, and that is in the native language of the named person" Which is going to be awfully inconvenient for English speakers who are addressing someone whose native language is tonal or click. Contrary to the assertion above, people's names do get translated: consider Wenceslaus I, Duke of Bohemia, known as Václav in Czech. The old Christmas carol isn't wrong for using the English instead of the Czech. People also change the pronunciation of their names. I know two people who have permanently changed the pronunciation of their names (one for the sole purpose of helping people figure out how to spell it), several that use translations of their names (e.g., Diego if you speak Spanish, but James if you speak English), and two that choose a different pronunciation depending upon the language. It's impossible to say that "there is only one proper way to pronounce a person's name" when the person is using three different pronunciations himself. WhatamIdoing (talk) 09:40, 29 May 2015 (UTC)

So what if some people translate their names in foreign languages? Many many more don't. And for those who don't we can only use the native spelling, unless their native writing system is different to our Latin writing (e.g. Cyrillic, Katakana, ...). In such a case we cannot avoid using a transliteration. And for people who did translate their names, we could use such a translation if it is backed by a reliable source. Tvx1 18:30, 30 May 2015 (UTC)

• Oppose further use of diacritics as per Dirtlawyer1 and Fyunck(click). I've responded to people above, but this is my base-level response to the original question. The original question and other commenters asserting that the majority of English Language Reliable Sources are "botching" the English Language is not a valid argument to make on Misplaced Pages. We should follow general English language practice of English language Reliable Sources. Diacritics (usually) do not belong in English language article titles and prose. Alsee (talk) 05:38, 29 May 2015 (UTC)

• REDIRECTs !! I have a strong preference for keeping diacritics per the original language in proper names, but I recognize that not everyone shares it. I propose that for pages whose titles include names in the Latin alphabet
  1. Ideally, the title of an article should use the proper diacritization of the name, per the original language.
  2. But if it doesn't— and there may be good reasons, e.g., Ho Chi Minh, properly diacritized as "Hồ Chí Minh"— there should always be a redirect from the proper diacritization (as there is from Hồ Chí Minh).
  3. Partial diacritizations should also work, though not necessarily via a full redirect. This seems to be already covered, at least in part: typing Antonin Dvořák (with a plain "i") in the search box brings up three possibilities: Antonín Dvořák , Antonín Dvořák Theatre, and Antonín Dvořák Museum, all properly diacritized with "í".

--Thnidu (talk) 03:37, 30 May 2015 (UTC)

• Comment. What would be the next step ? A re-ignition of "The Dakota" war since Dakȟóta would be so more diacritic ? Pldx1 (talk) 10:04, 30 May 2015 (UTC)
• Comment. We should follow the kind of references a professional copy editor might consult. The Chicago Manual of Style recommends Merriam-Webster, Britannica, and American Heritage. British style guides recommend Oxford. WP:DIACRITICS is an incoherent mess. To see how this issue should be handled, take a look at the guideline for geographic place names. This guideline looks like it was modeled on the recommendations given in the CMOS. Too hip to be cool (talk) 23:48, 30 May 2015 (UTC) Misplaced Pages:Sockpuppet investigations/Kauffner
• Comment. Excuse me for butting in on a subject I know nothing about (and care even less) but this page is now on my watchlist and I have a question. User:Cedric tsan cantonais claimed that diacritics were used in English in "the old days", presumably meaning Old English judging by the examples he gives. So how is it that I can see the diacritics in Wikisource's text of Beowulf, but they are entirely absent from the original manuscript? Perhaps the diacritics are just a modern affectation to aid pronunciation and were never really part of the language. SpinningSpark 19:52, 30 May 2015 (UTC)

  See Old_English#Orthography. Accoring to that, some 'runic' letters and a few diacritics were used in OE manuscripts, but modern transcriptions have added diacritics to preserve distinctions in sound that would have been clear to a reader of the day, but not to a modern reader. DES 20:40, 30 May 2015 (UTC)

  So the short answer is no, "one, two, three, four" were not written as "ān, twā, þrēo, fēowor" in the old days, at least not usually. SpinningSpark 00:27, 31 May 2015 (UTC)

  This is a fair query. From what I understand, Latin didn't really have them, or old Germanic. The better question would be why did many other languages decide to add them while English didn't? Specifically the romance languages. I don't think anyone knows why English or Anglo-Saxon didn't jump on the bandwagon when other languages started added them. Fyunck(click) (talk) 05:52, 31 May 2015 (UTC)

• Comment - the editors inputting on the WP:DIACRITICS guideline historically have been tilted to the anti-diacritics or "English names for foreigners" lobby. As such the WP:DIACRITICS wording reflects an anachronism in conflict with consensus across 100,000s of articles which consistently use diacritics - except for one blonde tennis player who was moved in a RM including a previous incarnation of community-banned sockmaster Misplaced Pages:Sockpuppet investigations/Kauffner‎ above - and it is that consistent MOS across 100,000s of articles, confirmed in RFC after RFC, which represents the editor reality of the encyclopedia not a guideline with (still amazingly) local consensus defenders some of whom just don't like the way modern hardback English full font books, and/or en.wp article corpus are. In ictu oculi (talk) 22:33, 2 June 2015 (UTC)
• Comment, bordering on Support: I know this isn't the place to debate this, but since the same goofy things keep being said, I can't help making a few points:
  • To the people who keep saying "English has 26 letters and no diacritics": you're wrong. I'm a native speaker of English, and the language I use includes diacritics. I write "Susie Hawkins, née Butler". I write "à la peanut butter sandwiches". I'm not saying you're wrong for not using the diacritics, but by the same token, you can't say I'm wrong for using them.
  • The New York Times writes "naïve". The New Yorker writes "coöperate". You may find these to be affected usages typical of liberal northeast media that you may not care to read, but they're mainstream American media, so you really can't argue with them, either.
  • McDonald's, which is about as mainstream American as you can get, writes McCafé. (And you can get a Frappé there, whatever that is.)
  • Noël Coward.
  • Support for diacriticful typography is incredibly widespread. Unicode is everywhere. 7-bit ASCII is long gone.
  • People who don't know how to type diacritics when editing Misplaced Pages articles don't have to. Someone else will come along and fix them later.
  • People who don't like diacritics don't have to enter them, either. Someone else will come along and fix them later.
  • When reading, people who don't like diacritics can just ignore them. (If we can survive color/colour -- and we have to -- we should be able to survive this.)
  • The hockey article compromise (or the tennis article compromise, or whatever you want to call it) is a terrible crock.
  • The WP:MOS language on the matter is fine. The only problem is some number of strangely parochial (or downright xenophobic) editors who see red when they see diacritics and go around looking for excuses to remove them. (But the existence of the hockey/tennis compromise shows that, whether I like it or not, the number and/or vociferousness of those editors is evidently not small.) —Steve Summit (talk) 23:25, 10 June 2015 (UTC), updated 18:19, 11 June 2015 (UTC)

    The hockey compromise is really just a victim of the changing times on the wiki. It was very progressive when it was created. All over the wiki diacritics were being removed right left and centre. And notedly were also added in some. But it was the only place where there was anything in place to push for using them. It was then used by many other topics to argue for using them elsewhere on the wiki. So it seems antiquated now because it calls for not using them in one area, but really it was created with a progressive mindset in 2007 when there was a real war going on between the two sides on whether or not to use them on the wiki. The hockey compromise would be removed in a heartbeat if we had a new RfC that indicated that the wiki consensus had shifted to support using them since the last wiki-wide RfC finished 50-50 almost to the person a couple years ago on using them or banning them. -DJSasso (talk) 18:03, 11 June 2015 (UTC)

    Thanks for that perspective. —Steve Summit (talk) 18:19, 11 June 2015 (UTC)

    Someone please launch that RfC. I've done too many lately.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  23:33, 17 June 2015 (UTC)

• WP:Wikiproject New Zealand has persistent issues with macrons (which are common the the indigenous Maori language and making their way via loan words into New Zealand English). We systematically defer to WP:COMMONNAME. When evaluating usage for WP:COMMONNAME, we discount media sites which are technically unable to deal with macrons (several of the mainstream newspapers) but not those that don't use macrons as a policy choice. Stuartyeates (talk) 21:17, 11 June 2015 (UTC)

Can we get a bot to check the Internet Archive for dead link solutions?

Rather than merely tag dead links as being dead, can we have a bot see if the dead link was archived at the Internet Archive around the time when the link was added to the Misplaced Pages article, and either change the dead link to point to that Internet Archive link (which would presumably be a working representation of the page before it was a dead link), or at least make a report on the talk page proposing the fix? bd2412 T 04:05, 2 June 2015 (UTC)

On a related point: If the archive is added to the citation, I think it should be added as |archive-url= with |deadurl=yes. This makes the citation title link to the archive while preserving the original link as "original" in the citation. Thus the original link can be easily checked for possible resurrection, which does happen sometimes. ―Mandruss ☎ 05:03, 2 June 2015 (UTC)

• Support this is an excellent idea. "repairing" dead links have become a common spamming technique. If we had a bot add archive links from internet archives that would solve a lot of problems. Do we have someone interested in building such a bot? We could also added an internet archive for the links that are not dead just incase they become so. We would use for the live ones |deadurl=no Doc James (talk · contribs · email) 07:59, 2 June 2015 (UTC)
• Problem: sometimes the archived page at Internet Archive is not valid—they really do have to be checked by human eyes. Curly Turkey ¡gobble! 11:05, 2 June 2015 (UTC)
  • True, IA has significant reliability problems. Many times an archive version is unusable but another version of the same page, archived a few hours or days earlier or later, works fine. And a bot likely wouldn't be able to tell the difference. But is a bad archive version any worse than a dead link? Either way, a human needs to try to find an archive version that works. ―Mandruss ☎ 11:55, 2 June 2015 (UTC)
    • I completely agree that human eyes are needed for confirmation, but it would be helpful to have a bot find and suggest the link. If a page has a lot of dead links, a bot report of some kind will also save the trouble of searching the Internet Archive for the ones that don't exist there at all. bd2412 T 12:12, 2 June 2015 (UTC)

Another issue is the (rather uncommon) case that the cited webpage changes over time and the archived version chosen by the bot may not be the correct version to support the content it references. A good way to address technical problems would be for the bot to leave a message on the article's talk page, much like bots do on user talk pages. The message would say something like "On , repaired of references by inserting a link to archived versions of these dead links. The archived webpages should be verified to determine if the archived webpage displays properly and supports the content it references." That's just an idea for what the text should say, it needs to be worded better. The message would include a link to edit diff and could even display the links to the added archived webpages to make verification easier. The message template could also include a parameter for the verifying editor to adjust to indicate verification, similar to how Template:Request edit includes a parameter indicating that the requested edit has been made. A parameter "archivebot=" could be added to citation templates to indicate that the archive link was added by a bot. I believe the benefit of repairing dead links (should check both IA and other web archiving sites) with a bot outweigh the drawback that a small percentage of archived webpages won't display properly or may not link to the right version of a webpage. AHeneen (talk) 13:10, 2 June 2015 (UTC)

I came across an archived webpage at IA yesterday that first displays a message that cookies are disabled and need to be enabled to use the website (the page is in French) and in Firefox the tab has a spinning green circle indicating the page is loading. The first screen has a box to check "OK" and if you click "OK" it goes to the archived version of the webpage and the green spinning circle disappears (again, using Firefox). This is something that a bot might reject as a bad archived webpage. This supports using a bot that lets editors review the archived webpages, rather than automatically rejecting them. AHeneen (talk) 18:49, 5 June 2015 (UTC)

• Support I think this is much better than just tagging the dead link. See comments in the threaded discussion above. AHeneen (talk) 13:10, 2 June 2015 (UTC)
• Conditional Support ... the condition being that it is not a fully automated process. Thanks for the idea S a g a C i t y (talk) 15:03, 2 June 2015 (UTC)
• Script it The internet archive sometimes archives 404 not found pages (many websites make fake 404 pages that look like real webpages to bots), so this won't do. A script that shows a human the proposed link and gives them a yes or no choice and changes the link if the human clicks yes is just the ticket. Oiyarbepsy (talk) 20:07, 2 June 2015 (UTC)
  • That would be ideal, yes. bd2412 T 20:18, 2 June 2015 (UTC)
• Support as a semi-automatic script with user-check. GermanJoe (talk) 21:14, 2 June 2015 (UTC)
• Comment (for Firefox users) In the meantime, this little add-on on the Firefox Addon page adds a "Check for Internet archives" function to contextmenus of links and to the toolbar (not my invention, just mentioning it). Not a huge improvement, but still quite helpful. GermanJoe (talk) 20:29, 2 June 2015 (UTC)
• Support I think this is an essential service we need. We all know we have dead links scattered throughout wikipedia. WP does not control the status of external sites, but we rely on that information for our sources. Essentially when a dead link is detected, it becomes the sequence for removing content, sometimes selectively for POV purposes. Used in such malicious circumstances, the offending editor must first fail to search for the archive link and then deliberately remove content. An automated process will eliminate the question and the opportunity. Once a link to a website is posted within wikipedia, frequently it will cause the archive spider to find an otherwise unknown link and start the archiving process, so all WP needs is a means to link back to that archive if the originating site goes down and the proper information is retained in perpetuity. The knowledge is not lost. "Knowledge is good." Trackinfo (talk) 20:55, 2 June 2015 (UTC)
• Support Excellent idea and an efficient way to manage dead links. Winner 42 Talk to me! 20:57, 2 June 2015 (UTC)
• Support The issue of the bot retrieving non-pertinent archive urls could be well dealt with by chucking in a template field that says the archive url has not yet been verified. Even if we say that the bot has only 50% accuracy in getting a good archive url, this would be a vast improvement from the current arrangement, at the cost of a slight amount of disappointment over there being two bad urls rather than one. I also support the idea of a scripted tool which would show users a non-verified link and allow them confirm, replace or remove the bot-provided url. SFB 21:02, 2 June 2015 (UTC)
• Support: This would also help reduce the incidence of a form of "article rot", in which dead links are used as excuses to pepper articles with inline or block citation dispute tags, or simply delete material as "unsourced" when it takes about as much time to take these unhelpful actions as it does to just go to archive.org and find a URL for the source that still works. Might as well just have a bot do it, if it can be done that way.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  19:55, 4 June 2015 (UTC)
• Support: Having worked on repairing dead links, having a way of harvesting the archived versions of an URL seems useful. Maybe have such a bot add a marker (like {{Archived URL available}} with the URL) that can be reviewed instead of outright replacing links, too - in case the archived URL is not suitable. Jo-Jo Eumerus (talk) 11:11, 5 June 2015 (UTC)
  • I would say that an "unsuitable" link is no worse than a "dead" link. I would prefer outright replacing the link and putting a "needs review" tag on it. bd2412 T 14:41, 5 June 2015 (UTC)
    • That also works, I'd say. Jo-Jo Eumerus (talk) 20:23, 5 June 2015 (UTC)
      • The "needs review" is a good stipulation to add to the automated process I supported above. Trackinfo (talk) 00:04, 9 June 2015 (UTC)

Adding url to archive.org for deadlinks

We are wanting to create a bot that adds links to the archive.org url for urls marked with deadlink automatically when possible. We think it can be technically done at least some of the time. The eventual goal may be to have an archive url added even before the url goes dead to indicate the exact version that was used as a ref. Often websites changes their content even when the link does not go dead. Is their support for this idea? Doc James (talk · contribs · email) 23:29, 8 June 2015 (UTC)

Do you mean support specifically for the idea of adding the Internet Archive link even before the referenced link goes dead? I would support that. If the Internet Archive doesn't already have the page archived, we can instruct it to archive it. bd2412 T 23:54, 8 June 2015 (UTC)

Yes Doc James (talk · contribs · email) 00:53, 9 June 2015 (UTC)

• Support in a way. Certain references are time related. When the original source changes, suddenly that could turn into a dead link or could get noticed by a human as not containing the content the article claims the source to support. If a logging system could track the date an archive.org's most timely capture of the site, that would be extremely useful. On the other hand, particularly with the long url's on archive.org, such a process would add a lot of bytes to sourcing and could make editing out of a mass of non-word based text more difficult. Ultimately across millions of articles, we are talking about a lot of extra data to store. The date stamped history could be an excellent source of that information, a log notation made each time a <ref> is created. That doesn't need to go any further until a human reports a dead link or that the source does not contain the material. Then rather than removing the content, the bot should activate the archive link and then make that source subject to human review. I'm sure the bot people will come up with better logic, the point being time stamped archive content being ready to replace changed or deleted content when there is a problem. Trackinfo (talk) 10:28, 9 June 2015 (UTC)

• (edit conflict)I think this would be a good attempt to do, but it would need some heuristics to distinguish between the several types of archived pages which are not representative of the target page. This is a problem with archive.org, that it will index pages like "you have visited a page which is no longer on this site - please try searching for it", and http errors of several types (mostly 302s and 404s I think), and it will sometimes index pages which are redirects from the target page. Maybe if the bot were to be run for a time and the results reviewed to see how to improve the results incrementally.... Another option would be to build into the deadlink template something like the "certain" parameter for {{self-published inline}} where the default would be "deadlink?" which could signal a bot or a human to test if there is an archived page; if a parameter like "reallydead=y" were added, this would signal that, indeed, the link had been tried to be recovered and it had failed. This wouldn't mean it "couldn't" be recovered, because sometimes its just a matter of the web url structure has been drastically altered and the original page is still present but hidden from casual view.

As for the matter of "exact version", I don't think this is something you can designate in archive.org for pages which have been previously indexed; in other words, I don't think there is a way to inject a specific version (i.e. today's version) into a saved set where the page is in the indexing queue. If it is the FIRST time a page has been indexed, yes, you can designate the exact version, though --User:Ceyockey (talk to me) 23:58, 8 June 2015 (UTC)

• There's another approach to consider as well. I've quoted a bit from the Wayback Machine FAQ below. Wondering if WikiMedia Foundation could approach Archive.org and have Misplaced Pages itself used as a directory to drive site indexing. This would not mean crawling Misplaced Pages to include in Archive.org, but crawling for URL-like strings appearing between <ref></ref> tags. Just a thought. --User:Ceyockey (talk to me) 00:06, 9 June 2015 (UTC)

How can I get my site included in the Wayback Machine?

Much of our archived web data comes from our own crawls or from Alexa Internet's crawls. Neither organization has a "crawl my site now!" submission process. Internet Archive's crawls tend to find sites that are well linked from other sites. The best way to ensure that we find your web site is to make sure it is included in online directories and that similar/related sites link to you.

Alexa Internet uses its own methods to discover sites to crawl. It may be helpful to install the free Alexa toolbar and visit the site you want crawled to make sure they know about it.

Regardless of who is crawling the site, you should ensure that your site's 'robots.txt' rules and in-page META robots directives do not tell crawlers to avoid your site.

Often there are a lot of dates for which a specific page is available thus one could use the one that is closest per the "access date". I will try to meet with someone from archive.org to discuss Doc James (talk · contribs · email) 00:32, 9 June 2015 (UTC)

• comment why has another discussion been started on this topic, which is being discussed just a few discussions above this one ("Can we get a bot to check the Internet Archive for dead link solutions?")?? Usually it's helpful to keep related discussions together. Issues raised in the first comment by Ceyockey have already been raised...that does not mean Ceyockey's comment is not valuable or adds to the discussion, just that it's helpful to see what others have said. I think this discussion should be merged with the other (maybe as a subheader). AHeneen (talk) 05:09, 9 June 2015 (UTC)

Sorry User:AHeneen yes merged. I have rounded up a bot programmer who states he can have something ready by the end of June for a trail run. Looks like their is sufficient support for WP:BAG Doc James (talk · contribs · email) 05:25, 9 June 2015 (UTC)

• Support, to thwart linkrot, though I share some of the above concerns about implementation.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  23:27, 17 June 2015 (UTC)
• Comment: Worth noting that Misplaced Pages:Bots/Requests_for_approval/Cyberbot II 5 already contains functionality to submit live links lacking an archive for archiving. Jo-Jo Eumerus (talk) 09:29, 18 June 2015 (UTC)
• Support, also suggested it here: Suggestion: a bot that automatically retrieves a Wayback Machine's archived page for dead link: one would simply fetch the archived version that is closest to the accessdate (and if possible before the accessdate). However one also has to consider the 404 sites. So even if it's closest to the accessdate it's not necessarily a "good" version of the site. So I'd suggest adding some additional parameter to citation-templates which the bot would fill (saying: adding the new parameter and filling it).

If it's filled it could show some other note next to the link instead of like . Then there could be some functionality for users to confirm that the site is in fact working. There could be exceptions to this however - for example if the archived version is of the same date as the accessdate etc.

However these are just some suggestions on how to deal with this problem...maybe there's a better way. --Fixuture (talk) 18:45, 22 June 2015 (UTC)

Meta comment (archive bot task force)

It seems to me that some issues are very complex, requiring a lot of discussion, possibly for a few months, and probably could be decided by a small group of experts in the area. Is the Village Pump a good place for such things? Would there be any benefit to the concept of a task force, a sort of short-term WikiProject? Something like that could be tried informally for this issue on a page in the OP's user space, as a test of the concept. If things like this issue need community consensus, and I've seen more significant things happen without it, the group's solution could be brought back here as a well-developed proposal. If this process turned out to be no better, at least it wouldn't be any worse, and we would have learned something from the experience. ―Mandruss ☎ 10:57, 11 June 2015 (UTC)

This is a pretty good idea. An alternative would be to take this into Meta as that would set the stage for both sourcing solutions from other Wikipedias and disseminating solutions to multiple Wikipedias. --User:Ceyockey (talk to me) 23:33, 11 June 2015 (UTC)

If anyone, individual or group, manages to do anything that improves the situation, please do make sure you let me know. I'll shower them with barnstars, praise, love and puppies for eternity. It's a bane of the life of developers of quality content that it degrades with time, and this will be a massive dose of helpfulness in that regard. — Preceding unsigned comment added by Dweller (talk • contribs) 19:01, 15 June 2015 (UTC)

"What links here" for article sections

So currently there's the "What links here"-feature that shows all Misplaced Pages-pages that link to the current article. However the entries don't signify whether or not those links are linking to just the page or to a specific subsection of it.
I'm proposing a change that either:

• Also shows the subsections that pages link to on these "What links here"-pages.
• Or (and I'd prefer that; it could also be done by an external AddOn/Gadget though): displays some kind of button next to the section-header at mouseover which at a click shows all articles that link to that section (for editors only; eventually also only for those who enabled this feature in the preferences).
  I think the first thing to do in this case however would be to get anchor links on section-headers -> I'm going to create a section in here on that in a minute as it's a separate issue.

So why would this be useful? -> it's useful when renaming section-headers to make sure the wikilinks that link to them don't break (amongst other things).

Please post what you think of this suggestion; not sure if it was already asked in here or if it's a thing to put on phabricator. --Fixut͉͇̞͖͉̼̭͉͓͑̈̉́͑ȗ̹̲ͨͮ̂̂̄ṙ̫̥͚͚̜͙͍̰́̈́ė̺̩̞̗̓̉ͧͩ̿ͤ̎̆ (talk) 18:56, 7 June 2015 (UTC)

• I think this would be useful, but maybe not as a baseline addition to the system. I think that at first one would want to create a routine to analyze incoming links to see if the originations have # cues and then do a validation to determine whether the #-value exists in the target article. There might be a couple of ways of doing this; if memory serves, there is an ordinal value assigned to sections sequentially which is independent of the title of the section; thus, there might be a way of "healing" broken section references if the order of sections has not changed. This would require some significant bot-heuristics looking at, for instance, the content of the first sentence and the number of paragraphs in the section as measures of identity between old-name section and new-name section ... maybe more trouble than its worth, but I'm not bot designer, so it might be reasonable. --User:Ceyockey (talk to me) 03:26, 11 June 2015 (UTC)
• Support When I edit long controversial articles, it would be very useful to know what links to an individual section that is getting lots of attention over a period of time. NewsAndEventsGuy (talk) 08:51, 14 June 2015 (UTC)
• Support: I have long desired this, specifically for the redir cleanup.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  23:25, 17 June 2015 (UTC)

Really glad you three like it! I just opened a task at phabricator here. --Fixuture (talk) 22:47, 21 June 2015 (UTC)

A proposal to reform the power structure of Misplaced Pages

I have been a Wikipedian for 11½ years, and an administrator for almost as long. However, I took an extended break from 2007 until recently, apart from a few sporadic edits. When I returned this year, I was shocked to find that the number of active administrators/sysops is about the same as what it was back in 2007! I would have expected to find at least 10,000 — but no.

I propose a thorough shake-up of the whole power structure. I am aware that certain folks who hold entrenched positions and/or who love titles will not like this proposal. But I think it would streamline the Misplaced Pages bureaucracy and make the project much more manageable. Here goes:

Positions to be abolished :

• Sysop/administrator - most rights of sysops to be transferred to all users who have been registered for six months and have completed 2000 edits to at least 200 unique articles.
• Bureaucrat — position obsolete. Bots to take over.
• Checkuser
• Steward — these last two positions to be replaced by Guardians (see below).

Proposed positions :

• Editor — new editors, by default, will be just like normal users at present. Electronically upgraded after six months and 2000 edits to 200 unique articles; given all powers currently entrusted to sysops except the power to block other users. No need for a "bureaucrat" to give users these rights — a bot would electronically "clock" a user's edits and would electronically upgrade his or her status automatically on passing the threshold.
• Restricted editor — an editor whose rights have been restricted by the Arbcom. In the case of an editor who has caused problems, a member of the Arbcom (or a Guardian — see below, acting on instructions from the Arbcom) could put a restriction on their account. This would either prevent, revoke, or suspend the post-threshold upgrade.
• Guardian — To be given the powers currently entrusted to Stewards and Checkusers, as well as the blocking power of sysops. Grandfather all existing sysops, bureaucrats, checkusers, and stewards into Guardians (the Arbcom could veto certain users on a case-by-case basis). Replace the current RFA with RFG (Requests for Guardianship). Eligibility — one year's tenure and 10,000 edits to 1000 unique articles. Change the voting rules: Only existing Guardians should be allowed to vote; to be elected, a candidate should score 60% or more, and be "ratified" by 90% of the Arbcom. The Arbcom may revoke or suspend a Guardian at any time and for any reason, by a 90% vote.

One other point: rights should be global, not restricted to a specific wiki. It's silly allowing somebody to do something on the English Misplaced Pages but not on the Italian Wikibooks, for example.

Well, that's a rough proposal. It's not set in concrete — feel free to amend it. But something has to be done to streamline the ossified, Byzantine power structure of Misplaced Pages, and make it more of a bottom-up than a top-down system. David Cannon (talk) 12:51, 8 June 2015 (UTC)

• I suspect this will be a no-go in its entirety, but as a specific complaint, there is no way that every current admin could be given checkuser powers. It could be done technically, of course, but giving everyone that permission would almost certainly be a violation of WMF's privacy policies. Never minding the fact that checkusers (and Stewards, I believe) are required to identify themselves to the foundation. A natural consequence of this proposal would be a dramatic reduction in the number of admins/"Guardians" - and that appears to run counter what you intend. Likewise, disenfranchising non-guardians is a non-starter. RFA may be a mess, but taking away the right of the overwhelming majority of the project's members to participate is not a good thing. Resolute 13:27, 8 June 2015 (UTC)
  • We can tweak this a bit. Sure, if applicants are required to reveal their full identity, the proposal could easily mean that fewer Wikipedians would be willing to apply for Guardianship than are presently willing to apply for Adminship. But if almost all active users were to get most of the powers that sysops have at present, that wouldn't matter so much. As for the voting rules, non-Guardians could still have the right to make their voice heard in submissions to the Arbcom — anybody with objections could file them. David Cannon (talk) 14:04, 8 June 2015 (UTC)
• another problem is that WMF legal has said that non-administrators should not have the ability to see deleted material. -- GB fan 13:53, 8 June 2015 (UTC)
  • We could retain that rule "in spirit". As I said, users would only get the powers that sysops presently have after six months and an editing threshold. But that is one power that could be transferred to Guardians, if too many people are concerned about it. David Cannon (talk) 14:04, 8 June 2015 (UTC)
• The main problem with this that I can see is it opens the door to disruptive editors to gain rights/abilities with which they could do real damage. 2000 edits/200 articles is easy to achieve if you put your mind to it. It would be even more of an issue if it were done globally, as then it would be easy for an editor to make their edits on another Wiki that has fewer people watching it before before becoming disruptive e.g. here.--JohnBlackburne_deeds 14:12, 8 June 2015 (UTC)
• I would strongly oppose "electronically upgrading" editors to quasi-admins after a certain number of edits. Do you have any idea how easy it would be to make 2000 edits to 200 articles if you're doing stupid stuff like dummy edits or making simple changes with AWB? If you're going down this path (and I'm not sure how I feel about it yet), getting these extra permissions should at the minimum require the same sort of human review that we currently require for rollbacker and pending changes reviewer. --Ahecht (TALK
  PAGE) 14:37, 8 June 2015 (UTC)
• I would also add that it's unclear what problem this is meant to address. Sure the number of admins has hardly increased, and there are probably fewer active than three or four years ago. But the number of active editors has decreased too. At the same time there has been near continuous improvement and development of tools and systems to automate the process of dealing with problems and problem editors: filters to stop problem edits happening at all, tags to alert editors of edit patterns that may be problematic, tools like Twinkle and AWB, greater centralisation of blocks and filters to stop WP hopping. If anything the encyclopaedia works better than ever at tackling and preventing problem edits and editors, as far as I can tell. And that may be why there has been little pressure to do anything about the admin numbers, there is no major shortage of them.--JohnBlackburne_deeds 14:50, 8 June 2015 (UTC)
• (edit conflict) This is an absolutely terrible idea, especially the part where only "Guardians" can have an impact on the selection of new admins. Why not limit the ability to select admins to editors who have created multiple featured articles instead? We are concerned about the quality of the encyclopedia, right? GregJackP Boomer! 14:56, 8 June 2015 (UTC)
• Let's see: automatic granting of admin rights, non-elected granting of viewdelete, automatic privileges but manual removal of privileges, mixing of high-level rights with admin-level rights … if this proposal went to a poll, it'd be SNOWed under in an hour. {{Nihiltres|talk|edits}} 16:04, 8 June 2015 (UTC)
• Trout. Firstly, the names are more WP:MMORPG than WP:PEDIA. Automatically giving protection, (revision) deletion, and other contentious permissions automatically at such a low bar? And then giving editors the ability to give or take rights globally at the usual bar for adminship (stewardship requires extensive cross-wiki contributions and 500+-voter scrutiny)? No. Esquivalience 22:22, 8 June 2015 (UTC)
• "rights should be global, not restricted to a specific wiki"? If this is a serious proposal, it is clearly being made in entirely the wrong place - the English-language Misplaced Pages cannot grant rights elsewhere, end of story. This proposal appears not to have been thought through... AndyTheGrump (talk) 22:30, 8 June 2015 (UTC)
  • Yes it is a serious proposal. I thought I'd float the idea here first, and then more widely (e.g. on the Meta) if it should gain general approval. Obviously nobody seems to agree with it. I'm also hoping, though, that in the event of its being rejected (which now seems certain), it will at least provoke some discussion about what CAN be done to improve the system. David Cannon (talk) 01:24, 9 June 2015 (UTC)
    • It is still unclear what problems you see that need addressing. As I noted above though there may be fewer active admins than a few years ago that is not a problem in itself: there are fewer active editors and many technological and process improvements that further make things easier or work better. Two more of these that I didn't think of above but which are good examples. Pending chages are another tool that can be used to limit the impact of problem edits and editors with no administrator effort once in place. And the Template editor permission partly does the job of your upgraded editors, by giving a few editors the right to edit highly visible and so protected templates, without giving them full admin rights.--JohnBlackburne_deeds 02:19, 9 June 2015 (UTC)
      • The fact that there are fewer active admins today than previously may not be a problem in itself, but I can see it becoming one. If the number is dwindling, it is highly likely that those who remain are "ageing" and if those who drop out are not being replaced by a steady supply of new blood, I can only see trouble down the track. Better, IMO, to prevent a problem than solve one. Ditto for the declining number of active users - I can see entire sections of Misplaced Pages becoming outdated if there are not enough new active users (this is already happening in certain historical articles - most of those related to Fiji, for example, have hardly been touched since 2007. I was the one who did most of the work on them; nobody did much about most of them in the eight years I was away. That should not happen. It looks as if I shall have to go through several hundred articles and update them all myself. I shouldn't have to - there should have been dozens of users taking care of these articles all these years. Misplaced Pages should be continuously attracting new users and few, if any, articles would be left unattended. (And don't blame Fiji's geographical isolation - most Fijians are very internet savvy). May I put it to you that fewer new editors are being attracted because they see Misplaced Pages as overly bureaucratic? Automating the lifting of editing restrictions (which is what sysop-access basically is) would create a much more inclusive atmosphere and new users would know that constructively contributing a reasonable amount of work would be rewarded, without their having to jump through a lot of hoops.

Another problem that I think such automation would solve is the way the whole RFA electoral process is skewed. Does every editor show up to vote? Nope. Just a few regulars and a few other sporadic visitors. What that means in practice is that those who get elected are not necessarily the ones who do the most work, or the best work, but rather then ones who have good "connections" - either with the regular voters on the RFA or with a pool of people who are usually non-voters, but will show up just to vote for "their" candidate. Other GOOD users, who just beaver away quietly in obscure corners of the project, paying little attention to developing such relationships, are less likely to be chosen. That's not the way democracy is meant to function. Automating the process would make the lifting of restrictions not tied to an "office" to be elected to, but rather a recognition that the user has been contributing both quantity and quality to the project and is not a fly-by-night. Every new user would know that if he or she sticks around, and does not cause trouble, these rights will be granted automatically. The six-month period is ample time for the new user to learn the ropes and for other users to notice any signs of trouble and report that to the Arbcom, who would then "flag" that user's account as restricted.

Of course, some unsuitable users will slip through the system that way. That's inevitable. But grandfathering present sysops and other "office holders", for want of a better term, into Guardians would mean that there would be a considerable number of people around with the power to do something about that. And if you re-read my propsal, the blocking power currently entrusted to sysops would be held only by Guardians.

As for why I want to restrict the "electorate" to those who are already Guardians: see my comments above on who currently votes at RFA. A mixture of hobbyists and single-candidate supporters (and opponents). A stable "electoral college" is preferable to an electronic town meeting where only those who support / oppose a particluar candidate show up. Moreover, given the sweeping powers that Guardians would possess, it is only fair that new Guardians should have the trust of their peers, as well as the nearly unanimous approval of the Arbcom. Preventing non-Guardians from voting would in no way prevent them from making submissions; they could make their objections known and I'm sure that the Arbcom would take them into account, if the Guardians voting had failed to do so. David Cannon (talk) 07:31, 9 June 2015 (UTC)

This just seems to be another way for admins to gain more power at the expense of content creators. Admins already have too much power, giving them more is insane. We should limit them, not expand their power. Maybe a two-year term as an admin, followed by a loss of the mop for at least a year (i.e. term limits) would be the way to go. Under no circumstances is this proposal viable. GregJackP Boomer! 15:56, 9 June 2015 (UTC)

While I agree that this does impact concentration of power, I do not believe your false dichotomy is helpful. "Content creator" and "admin" are not mutually exclusive. Nor is it a fact that the latter targets the former, no matter how much certain agitators wish to pretend otherwise. Resolute 17:12, 9 June 2015 (UTC)

It's not a false dichotomy. Nor did I claim that admins could not be content creators or vice versa. On the contrary, there are plenty who are both. Cirt comes to mind, as do you, Worm That Turned, Rschen7754, Wehwalt, etc. We need more admins who are like those (and you), who have created content. Second, there are plenty of examples of administrators who go after content creators, one need only look at the block log of Eric Corbett. The difference is that the administrators have the power and can silence those who oppose them. Allowing the in-power group to consolidate their power even further is not good for the project. Excluding mere editors from determining who should be admins hurts the project. Limiting adminship to those trusted by people who have repeatedly contributed FA articles can only help the project. GregJackP Boomer! 18:24, 9 June 2015 (UTC)

We should not credit any argument that says admins go after content creators because of one case (if it's only one case, than it shows that admins are definitely not going after content creators). Alanscottwalker (talk) 18:40, 9 June 2015 (UTC)

If you want, I can get a whole list, but that's a side issue. Listing one case is known as an analogy, but we can go through a bunch of them, one by one. It doesn't really serve the purpose of this discussion however, and provides a simple way for admins (and others) to deflect the conversation. The main point is that the current proposal is not acceptable. GregJackP Boomer! 19:06, 9 June 2015 (UTC)

Well, good then there was no point in bringing up the meme that admins want to go after content creators - they just don't. -- Alanscottwalker (talk) 19:18, 9 June 2015 (UTC)

Yeah, they do, albeit unintentionally because most admins do not know how to create content and the "rules" are more important than the content. Anytime you have bureaucrats driving the train instead of engineers, it becomes no way to run a railroad. GregJackP Boomer! 19:35, 9 June 2015 (UTC)

Well, as long as we don't have to put up with more cliches - all the better. Alanscottwalker (talk) 19:48, 9 June 2015 (UTC)

• WP:SNOW, there's no way sucha frankly ridiculous, poorly conceived proposal could possiblty be approved. Also, we do not have the authority to get rid of stewards, they are elected by the global community. . Beeblebrox (talk) 18:42, 9 June 2015 (UTC)
• I am not going to dignify this proposal with a response. --Rschen7754 01:08, 10 June 2015 (UTC)
  • You could try being nice once in a while. Alakzi (talk) 01:58, 10 June 2015 (UTC)
• Has anyone perhaps considered that the proposer is a returning user who was relatively inactive for many years, and may not be informed about the community's new standards concerning adminship? After all, he was most active in the early days, when adminship could be obtained with a mere 3,000 edits and a few months' experience. Currently, the expectations are generally over one year of experience and more than 10,000 edits (or even 20-30,000), with very little tolerance for mistakes. I'm not saying that I support all aspects of the proposal, because I don't, but we need not be so hostile and condescending. This is not a good way to respond to a good-faith proposal by one of our recently-returned early contributors. (I know how it is to have a proposal ridiculed, so...) --Biblioworm 01:45, 10 June 2015 (UTC)
• Comment Our overall editor numbers are lower than they were in 2007. So it is not just the number of admins that has stagnated. The most important work of the encyclopedia still takes place at the level of article editing. Those who edit thus have the greatest power and I consider this to still be a bottom-up organization. Adminship is really just part of the dispute resolution mechanisms and the carrying out of community determined consensus. We have many successful and thus "powerful" editors who are not admins. Doc James (talk · contribs · email) 18:58, 10 June 2015 (UTC)
• I have no comment on the proposal itself but I agree with Biblioworm that we should respond more nicely to this good-faith proposal by a returning early-contributor. Tony Tan · talk 03:43, 14 June 2015 (UTC)
• Exact opposite of what we need. A second-class editor category? An all-powerful admin class? We'd lose thousands of editors the first day that rolled out, and the project would probably collapse under the weight of its its own corrupt bureaucracy pretty fast. We actually need additional classes of trusted users, like template-editor, that are below admin (i.e, can't block), so more work can get done.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  23:23, 17 June 2015 (UTC)
• Jimbo Wales has advocated an "easy come, easy go" system of adminship. I think his idea is a bit better than automatically upgrading everyone to have admin rights. I'm sympathetic to this idea, but the risk of subtle vandals and trolls who make 2000 trivial edits is too great. I think we could easily move a few admin rights into rollbacker and pending changes reviewer, but this current proposal is probably too big of a change to make all at once. It requires better planning and less ambitious changes. NinjaRobotPirate (talk) 23:31, 23 June 2015 (UTC)

Enhancing the enhanced watchlist

Our default watchlist uses green bullets to indicate changes to pages since last visited. When you use the enanced (and grouped) watchlist, no such indicators are used. I plan to change that. I have prepared a test gadget for evaluation, and plan to enable it by default in the near future. This also enables me to move the code already in Common.css (and skin CSS) to centralize it, providing users the option to disable it completely (which reverts the display to the software default). The gadget can be found in your preferences (all the way to the botom). -- ] {{talk}} 14:28, 12 June 2015 (UTC)

Where is the option to enable the enhanced watchlist? Alakzi (talk) 14:43, 12 June 2015 (UTC)

Prefs, Recent changes: "Group changes by page in recent changes and watchlist". --Izno (talk) 15:19, 12 June 2015 (UTC)

And "Expand watchlist to show all changes, not just the most recent" under Watchlist tab. -- ] {{talk}} 16:03, 12 June 2015 (UTC)

I personally use a black, bold, lowercase "c" to indicate a changed page, just prior to the page name. Using a new "bullet" might be interesting. --Izno (talk) 15:19, 12 June 2015 (UTC)

First thought is that it will take some getting used to. I actually don't find it enough of an indicator of change (I much prefer the previous bold-the-entire-line we had going which is the default config option--did someone turn that off again?), but maybe time will change that. --Izno (talk) 15:23, 12 June 2015 (UTC)

I just override the entire thing with my CSS. I use stars and bold.—_Chat:Online 15:45, 12 June 2015 (UTC)

In the near future, turning off the gagdet should automatically give you bold (unless you check the future "do not use bold" gadget). -- ] {{talk}} 16:01, 12 June 2015 (UTC)

I like it, except for shrinking the font used on the time & minor-edit/bot indicator. Set that back to what it was? Alsee (talk) 14:07, 13 June 2015 (UTC)

Actually, I enlarged it quite a bit (in Chrome that is). The original font declaration suffered from the monospace bug, which resulted in a great difference between browsers. It should now match the base font size in all browsers. -- ] {{talk}} 18:07, 13 June 2015 (UTC)

Edokter, then it's still bugged. Either you explicitly set font-size:88%, or the monospace bug was merely moved from Chrome to Firefox. Either way Firefox is shrinking as much or slightly more than Chrome increased. When I manually edit the element in Firefox from font-size:88% to font-size:100% it restores the gadget-watchlist to match the no-gadget watchlist size. Alsee (talk) 06:39, 18 June 2015 (UTC)

Yes, it was huge in Firefox and tiny in Chrome; they are now the same size matching the base size. -- ] {{talk}} 20:07, 18 June 2015 (UTC)

New button: View source

I propose that for each article, in every section, alongside the "Edit" button, we have another button, "View source". This would allow editors to see the code which generates the section text without opening the section for editing. Editors can then get a quick look at how specific formatting is accomplished without extensive hunting through the tutorials for explicit instructions, but without the slight danger of accidentally modifying the section.

For example, matrices have fairly complicated code. Suppose that someone wanted to insert matrices into a section of an article which does not already have matrices in it. The editor could simultaneously view the source code in another article which has matrices neatly formatted, while creating the matrices in the first article. — Anita5192 (talk) 17:48, 13 June 2015 (UTC)

I don't really see how this would be different from clicking edit on the page; that shows you the source markup. I've not heard accidentally saving changes being an issue, but if you do you can just undo the edit. Something similar that could be useful is a source page that has clickable links which take you to the relevant markup help pages or contains links to the templates being used in the article, this would help new users find exactly how things are being done in another article without having to hunt around. Sam Walton (talk) 17:56, 13 June 2015 (UTC)

@Anita5192—an excellent idea! Viewing source code and manipulating working markup is the best way to learn. Using a live edit view is an invitation to learn Murphy's Law; Misplaced Pages is the encyclopedia anyone can edit—but no one wants to do so accidentally. I began here copying source to my sandbox, and I worry still about unintentionally making a live edit. And @SW—undoing is only a fix if you realize you made an accidental edit (think multiple pages open, it's late, and your coffee's worn off).— Neonorange (talk) 22:15, 13 June 2015 (UTC)

@ Neonorange: My thoughts, exactly! — Anita5192 (talk) 18:11, 14 June 2015 (UTC)

I also think it's a great idea. ~ ONUnicornproblem solving 16:16, 16 June 2015 (UTC)

Nothing wrong with it as a gadget option.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  23:18, 17 June 2015 (UTC)

Poll on expanding block log to include sanctions/bans of all kinds

Question: Would it benefit the project if sanctions other than blocks were noted in such a way that they would appear in an expanded sanctions log, rather like the current block log, but more comprehensive? NewsAndEventsGuy (talk) 21:33, 13 June 2015 (UTC)

Discussion

• Yes When I am deciding how to handle what I see as problematic behavior I like to check a user's past history with sanctions of all sorts. The block log is handy, but far from comprehensive, and while one can spelunk at ANI/AE/ARB for individual decisions, there's no list that I know of. It would be helpful if there were a simple way to track problem behaviors, because this would help us recognize long standing patterns when we encounter them for the first time with some editor we have just met. That in turn may be useful information to the community/admins/arbs when new complaints are filed. Your thoughts? NewsAndEventsGuy (talk) 21:33, 13 June 2015 (UTC)
• Yes but with a different approach To be frank, I don't think something like this will get implemented into the core software. Block logs are for blocks, so if anything there'd be a "ban log" or "sanction log". All we need is an easy way to see if a user is under sanctions, and I've thought about this before. My idea was to have the wikidata item for Misplaced Pages:Arbitration Committee/Discretionary sanctions include structured data on users and their sanctions. Then I could implement a check of this page into WP:MOREMENU (or something similar) that will link to the corresponding arbcom page when you're viewing a page related to that user. One issue is wikidata is for all projects, where this would only apply to enwiki. So we could have the data here on enwiki we'd just need to be disciplined about the way it is structured in order for a script or bot to be able to parse it. — MusikAnimal 21:54, 13 June 2015 (UTC)

I'm glad someone else is thinking about this, but I'm not enough of a wikinerd term of affection to have the slightest idea what you just said. I'll add one thing though.... ideally this would show current sanctions, but any sanctions, regardless of time. My purpose is pattern recognition, so old expired sanctions would still be relevant, maybe. NewsAndEventsGuy (talk) 22:04, 13 June 2015 (UTC)

Basically I mean it's probably best we implement this logging system ourselves rather than relying on WMF to add it to Special:Log, particularly since the system of sanctions/bans may be unique to enwiki. — MusikAnimal 00:33, 14 June 2015 (UTC)

• A way (any centralized location) to track sanctions would be very beneficial if done well, the problem is if it is used inconsistently or vaguely. If it is added, there needs to be a very clear way to determine what is added to the log to prevent certain users from appearing to have no problems due to entries not being added to their sanction log and others from appearing to be very problematic due to entries being added for minor things. It would also be beneficial to expand cases where thing are added to any "official" part of something that could lead to a sanction as long as it is very specific, for example, if someone names me in an ANI case but it is nothing happens, an entry could be added saying AN/I discussion (link) started by ExampleUser and another saying AN/I discussion (link) closed/archived with no support for action instead of just the first message, which could cause some users to believe there was a genuine problem. If there are any more proposals related to this, I ask that someone let me know, I am very interested in this idea. PHANTOMTECH (talk) 23:24, 13 June 2015 (UTC)

One simple way of ensuring consistency is to adopt a simple rule that no sanction can be enforced if it has not been added to (whatever log is created). NewsAndEventsGuy (talk) 23:47, 13 June 2015 (UTC)

That would effectively solve the problem of logging sanctions but to prevent people evading the log by agreeing to things like "voluntary" interaction bans when they think an "official" action is coming I think that things like being brought to ANI should be logged. The problem is people will continue to try to evade the system by trying to end the discussion before it gets to a logged event if the events are very specific or will cause over or under logging if the events are too vague, with some logging any discussion on a user's talk page where they provide some resistance and others not logging unless action is taken at ANI. I do think that an effective way of doing this can be found, perhaps quite easily, but want to stress its importance. PHANTOMTECH (talk) 00:04, 14 June 2015 (UTC)

I don't think we should log being brought to ANI, only link to the thread if it resulted in a sanction/ban. It would be up to the closing administrator or arbcom clerk to update the sanction log. — MusikAnimal 00:28, 14 June 2015 (UTC)

I agree with MusikAnimal; lots of ANIs are spurious, and the named eds are victims, not problems. NewsAndEventsGuy (talk) 00:39, 14 June 2015 (UTC)

If we don't log being brought to ANI, it allows genuine problems that simply don't have much support for action at the time to be hidden away. Bad faith ANI reports are a problem, and simply logging something like brought to AN/I for something as complicated as ANI would cause problems which is why logs should be specific, linking to the thread to allow reviewing users to see what actually happened and saying what action, if any, was taken to keep those who don't check from jumping to conclusions. A centralized location for logging only sanctions would be beneficial, but I have a feeling people will rely on it too much which could cause people to underestimate certain problems. PHANTOMTECH (talk) 00:51, 14 June 2015 (UTC)

• Before we even consider logging more things, we need a better way to address bad/erroneous blocks in the log. Current policy is that pretty much no matter how bad the block is, it can never be removed (despite having the technical ability to delete it). Before we start adding more undeleteable content to the logs, we need to find a good way of cleaning bad blocks (and overturned sanctions from this proposal) from the logs of innocent. Ideally this would be done with full transparency, while also removing the blemish from the log on casual glance. I would propose that we allow redaction of block/sanction log entries, either with the consent of both the admin who originally enacted the sanction, and the target of the sanction, or with a clear consensus at a notice board in favor of redaction; we would then create separate, manual log of entries redacted under this process. In the case of the consensus route, the standard should be that the block must have been bad, as a matter of policy, at the time made , and not where it was just decided to unblock later. The log would provide transparency to the process, while removing the bad sanction from immediate view when looking at the editor's log. Monty₈₄₅ 02:16, 14 June 2015 (UTC)

Removed logs could just be hidden from default view with a note attached about why it was removed. This would require a software change for block logs but would solve the issues caused by accidental or bad blocks staying in the block log, would be very transparent and would allow easy restoration in case of accidents. I agree with your idea for conditions where blocks should be removed. PHANTOMTECH (talk) 03:26, 14 June 2015 (UTC)

• Comment: The block log is generated by administrators using a specific tool. It is not a manually created log. Before going any further down this rabbit hole, perhaps someone should find out exactly what would be required in order to log certain decisions. Keep in mind there is a difference between actions (which can be logged), and decisions (which are not logged now, anywhere, for anything, except in manually created data). Thus, it seems to me, there may need to be an additional "button" for "other sanction" or something like that. Who's writing the software? Risker (talk) 03:40, 14 June 2015 (UTC)

There would have to be another button or special page which would have to be used manually each time we wanted something logged since many things we want logged don't have a specific associated action. If it's integrated properly into Misplaced Pages it will have to be done my a MediaWiki dev, if we decide to throw something together ourselves it can be done using scripts/gadgets or default gadgets with the minimum necessary being a script that allows adding logs and nothing needed for reading them. PHANTOMTECH (talk) 03:48, 14 June 2015 (UTC)

Maybe something involving a manual post to the editor's talk page that produces a filter, sort of like the current DS Alert system? NewsAndEventsGuy (talk) 08:45, 14 June 2015 (UTC)

• Oppose: We don't need a new way to shame and judge other editors. The present tools' ease of use is already unforgiving. If someone's being programmatically disruptive there are already enough ways to dig up the past. If admins think it's be useful for admin purposes only, I guess I wouldn't object to that. My main concern is that WP is already full of way, way too many grudges.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  23:15, 17 June 2015 (UTC)

Scrollable reflist option

I have noticed that the pt:Misplaced Pages can display references in a box with a scroll, as can be seen here, different from ours here. I don't know if this is the right place for a proposal of change, but if not, maybe one of you guys could take it to the proper place or people. That would be quite an interesting move ! Krenakarore 21:43, 13 June 2015 (UTC)

@Krenakarore: I'm not seeing the scroll box you described at that page, do you have a user preference checked or something which is enabling it? Sam Walton (talk) 22:09, 13 June 2015 (UTC)

What box? what scroll?—_Chat:Offline 22:14, 13 June 2015 (UTC)

Bingo ! Compactar referências: Permite "barra de rolagem" (Scroll) em referências. So, that would be possible ! Krenakarore 22:18, 13 June 2015 (UTC)

Found that in Preferências->Gadgets, checked it. It reduced the number of references displayed from 233 to 36, but no way to scroll that I can see. I don't see the point anyway, since it sounds like it would simply replace one scroll action with a different one. ―Mandruss ☎ 22:41, 13 June 2015 (UTC)

However Mandruss, allocated in "Preferences", this gadget would allow users to make use of it or not. Besides, a long list of References would be displayed in a more concentrated form, enhancing the layout quality of this encyclopedia. As for the "but no way to scroll that I can see", I believe this only works when a number of references is reached. Best, Krenakarore 05:46, 14 June 2015 (UTC)

Sorry, I still fail to see how anything would be enhanced. Without the feature, I can fill my screen with references, assuming the article has enough of them; with it, I would be limited to viewing a fraction of that at a time — in your example Windsor Castle article, apparently only 36 out of 243 — even if it worked, which, as I said, it doesn't for me. I'd call that an anti-feature. Perhaps I'm just blind; please explain how it benefits a reader to have a scrollable part of the references and part of the notes on-screen at the same time, or a scrollable part of the references and part of the bibliography. ―Mandruss ☎ 10:18, 14 June 2015 (UTC)

@Krenakarore: I have changed your heading to something more descriptive than "Suggestion"; I hope you don't mind. ―Mandruss ☎ 10:40, 14 June 2015 (UTC)

Absolutely not Mandruss. Actually, you have just improved the title of the heading, which is the purpose here (better what I do and I'll return the favor). What I meant is that it might save space when we have long "lists" of references in this section, enhancing the appearance of the page (that's my work here, to better the quality of what I see and read). The example on the right shows a box and a scroll. The Notes section is above and Bibliography below, so I think it only works for this section. Nonetheless, if both sections (notes and references) occupy the same sub-section, they might well appear together.

You see, there are many interesting ideas put to the test or in current use in other Wikipedias. Maybe creating gadgets like "justify paragraphs" (which I make use of once I have never seen a book without alignment on the right, and I believe that does improve the quality of Misplaced Pages), might invite other users like me to edit articles. I really don't know if "Move section links to the right side of the screen", "Add a clock in the personal toolbar that displays the current time in UTC", or even our VisualEditor might benefit a reader, but in my humble opinion it's an improvement to the project. There will come a day when we users and reader alike will be able to watch holographic images come out of the screen, dance before our eyes in dynamic motion and stimulate our perception and understanding of what is worth seeing, believing, making, creating, thus changing our way to see the world. Krenakarore 19:57, 14 June 2015 (UTC)

Scrollable references have been discussed in the past (I'm afraid I don't have a quick link to the past discussions); they are discouraged because they can have a number of undesirable effects. Potential issues include:

• Incorrect, mangled, or broken display in some browsers;
• Incompatibilities or difficulties navigating with some accessibility tools (like screen readers for the blind);
• Incorrect or incomplete display of references when printing articles;
• Difficulties in rendering on small, low-resolution, or unusually-sized screens or windows;
• Probably a bunch of subtle but annoying things for editors reading, reviewing, or updating references.

As to justifying paragraphs on Misplaced Pages, there are good reasons not to do that on the web. Here are the first couple of links that Google throws up: , . Essentially, rendering text on the fly, to be displayed on screens of arbitrary size (especially arbitrary width), without careful supervision and tweaking (hyphenation and so forth) tends to make text less readable. It's particularly hard on the dyslexic and the vision impaired. TenOfAllTrades(talk) 02:22, 15 June 2015 (UTC)

Different hearts beat on different strings. When I first came here was to mention the existence of this feature, not to convince others that it is a good idea. Misplaced Pages has many advantages over other websites, being the main one the possibility to choose between using or not this or that gadget. The title of the link you gave me (much appropriate by the way) is: "Never Justify Type on the Web". So, if justifying paragraphs were mandatory I would be inclined to agree with you, but once it isn't... I guess the same applies to the scrollable references, regardless the browser I were using - I am getting in touch with programmers at their Village Pump to know if there are complaints about the use of this gadget. Many users here are against infoboxes, but it's the very first thing that appear on my mobile ! All in all, if we'd drop every opportunity to experiment, we'd better bury this project after all. Krenakarore 16:05, 15 June 2015 (UTC)

To be clear, I don't have anything against individual users installing whatever gadgets they want, or opting in to whichever formatting changes they like. But the default display format for Misplaced Pages articles should be as friendly as possible to as wide a range of readers as possible—and should especially avoid doing things that are apt to make things difficult for readers already facing accessibility challenges. TenOfAllTrades(talk) 22:36, 15 June 2015 (UTC)

I would add that if some group finds a way to display reference lists in a non-default way, fine. But no one is making any commitments to such a group to support their preference. If some citation styles don't work with their special tools, tough luck; the outcome of this discussion shouldn't be viewed as requiring editors to alter any citation style to work with non-standard display tools. Jc3s5h (talk) 22:47, 15 June 2015 (UTC)

Definitely, I agree with you. I got in touch with the people at their Village Pump and they informed me that only a few editors justify paragraphs, me being the last to copy the code from mw:Snippets/Paragraph justification to my common.css today ! They also said that the scroll bar is important once there are articles with more than 100 or 200 references, and such distribution is impractical and extremely anti-aesthetic. Besides, the page about the criteria to create gadgets did not exist shortly before the proposal that resulted in the gadget creation. So, they believe that it's unlikely that a gadget to compress references in the English Misplaced Pages be created, since the problems it would introduce are enough so it does not pass the criteria for gadgets creation.

You said: "I don't have anything against individual users installing whatever gadgets they want". Could I create this gadget here (compacting references with a scroll bar) the way I did there today by copying that code to my commons.css, and which code would that be ? Krenakarore 23:21, 15 June 2015 (UTC)

 Done, thank you  !

This (and justification, etc.) are fine as optional gadgets, but shouldn't be pushed as defaults. This is far less trivial (for someone who wants this ref-squishing) than many current gadgets.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  23:12, 17 June 2015 (UTC)

Revisiting trivia, and pop-culture / cultural references / cultural impact material

1. Proposal to develop a content guideline on encyclopedic relevance: There is no question that the Misplaced Pages community has a general consensus on the handling (mostly rejection) of trivia, on the fact that not all popular culture material is trivial, and that material on cultural influence/impact is a necessary part of encyclopedic coverage. We have no content guideline covering this, but a number of essays that include some very well-accepted advice and rationales. It should not be too difficult to develop a draft guideline for WP:Proposal from the best-regarded of these points, tied to WP:Core content policies. The last time this was attempted was many years ago, when inclusion of trivia was advocated by many editors. Much has changed since then. I advocate a descriptive as much as prescriptive/restrictive approach: Codify existing best practices, rather than introduce new rules.
   Please comment at WT:Handling trivia#Proposal to develop a content guideline on encyclopedic relevance.
2. Proposal to restart WikiProject Popular Culture with a new focus: It still has years-old material about "saving" trivia, and has of course become inactive. It should be repurposed improve actually encyclopedic cultural references material, and perhaps to speed the removal of unsourced, unencyclopedic trivia.
   Please comment at WT:WikiProject Popular Culture#It's time we realign this project's priorities and reboot it.
3. Proposal to deprecate the "In popular culture" heading: Other headings can more accurately describe the (proper) content of such sections, and be much less likely to attract the addition of trivial cruft. "Cultural references" seems to be the most popular alternative, but only address one of at least 3 rather different classes of / approaches to such sections.
   Please comment at WT:Manual of Style/Trivia sections#Deprecating the "In popular culture" heading.

Relatedly:

• New guideline material: I added a section to MOS:TRIVIA, at WP:Manual of Style/Trivia sections#"In popular culture" and "Cultural references" material, on how to approach pop-culture content from a MoS perspective (avoid list format, etc.). For content policy matters, I just cross-referenced to the relevant policies. I also (this will probably be the only potentially controversial part of the addition) linked to the WP:"In popular culture" content essay in this section, but noted that it is an essay, and did not recommend anything in it, just observed that's there.
  Please comment at WT:Manual of Style/Trivia sections#Covering cultural references / popular culture material.

I think that together, such efforts may lead to better handling of encyclopedically relevant cultural-references and cultural-influence material, and a faster general reduction in unencyclopedic pop-culture trivia.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  11:58, 14 June 2015 (UTC)

• Trivia is not the same thing as "In popular culture". The academic study of the humanities, as well as much general reader interest, involves in considerable part the study of the influences of one topic or work or author upon others: this is the basis of which intellectual history is made. Similarly, even what we call trivial uses are significant as part of social history--what people put in the background of their works can be very meaningful. (I have for example seen academic discussions of the significance of the product brands chosen to characterize individuals in F Scott Fitzgerald's novels.) What needs reforming is our rules that restrict this coverage. At present we have an uneasy equilibrium, and accept a good deal of this material from major topics, but even this is continually challenged. I'd like to have more, but I am concerned about the possible effects of upsetting the balance. I think the rational position for those on either side of this issue is to let the compromise stand.Only a zealot really wants to gamble on all-or-nothing. DGG ( talk ) 00:05, 17 June 2015 (UTC)
  • I agree on all of that up to "the rational position for those on either side of this issue is to let the compromise stand". There's no all-or-nothing gamble. It's a pre-proposal to see if there's enough interest to write a proper relevance (not trivia or pop-culture only) guideline that absolutely takes all of that into account. If it didn't and would "risk all", then fail it. I would like us to be able to go through a collective-brain rearranging process like we did with notability (formerly a lot of stuff like "importance", "fame", "notoriety", etc.) and come up with something useful and not detrimental. As someone else said on the other VP, "relevance" is a broader matter. If we can separate relevance from the format (short factoids, allegedly "trivia", but often relevant and just needing integration) and from the focus (media mentions/appearances/homages/parodies/etc, allegedly "trivia", but also often relevant), we'll be getting somewhere. Especially if we also can provide guidance on how to ID material that is well-developed and seems encyclopedic but actually is irrelevant.  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  23:07, 17 June 2015 (UTC)
    • Hello, I've long claimed that Misplaced Pages had policies on article relevancy, but not on content relevancy. That is, there's a rule on whether a topic deserves a standalone article or not, but we don't have specific rules on whether a fact deserves to be mentioned on a given article or not. This goes much further than pop culture trivia. --NaBUru38 (talk) 19:41, 24 June 2015 (UTC)
      • Perhaps you would like to read WP:DUE, which is our policy on whether a fact deserves to be mentioned in a given article or not. WhatamIdoing (talk) 19:44, 24 June 2015 (UTC)

Good questions

Hi, folks! I think this is a great idea to explore Misplaced Pages.

Rat her than fill in the blanks, I think that the best way to quizzify is through well-made questions.

Not easy questions ("who was the 27th U.S. president?"), but deep questions. Not just "find a fact" questions, but "think about the subject" questions. --NaBUru38 (talk) 19:46, 24 June 2015 (UTC)

Quiz mode

I have started a proposal at Misplaced Pages:Quiz mode. Please discuss it at Misplaced Pages talk:Quiz mode.
—Wavelength (talk) 03:24, 17 June 2015 (UTC) and 03:25, 17 June 2015 (UTC)

GEO CONTEXT

Hi

Please revise guidelines with the view of getting contributors, particularly those from the US to provide suitable GEO context when the information they provide is US-centric ( or other country centric ).

I object to reading wording like "the supreme court" without geo qualification, unless geo qualification is offered elsewhere then it should read "the US Supreme Court" in deference to non-US citizens. The US supreme court has no juristriction in my country so I prefer to read about it as a foreign entity by means of qualification.

Writers from the US often write in a style in which figures or organisations of authority are referred to without any geo context, this can lead to a vague impression in the reader that the writer in some manner proposes these as global authorties rather than ones that apply only to US citizens. This is in effect a global example of the well known habit of New Yorkers to say that they come from "the city" which can be taken as arrogant by non-New Yorkers.

Careless lack of geo context gives an impression of arrogance and an impression of a world in which there is the US and then there are all the 'other' countries. I single out the US as in my subjective view media from the US is worse in this respect than media from other countries but the observation is meant to be universal with a specific focus.

The reader may very well guess the GEO context because certain figures or institutions are well known but that very same reader may still resent the fact that this is assumed. There are sensible limits for instance many city names are so well known and also unique that qualification seems redundant, on the other hand there are many presidents around the world so reference to "the president" will generally benefit from geo context.

I would like to see the US army, president, senate, supreme court and similar qualified by "US" when they are first introduced in any article, otherwise we may forget that France has a president, Ireland has a senate and most countries have armies, airforces and so on.

Kind regards

Jon

Can you give me an example of an article where the geo context is unclear? For example, if I were writing an article about China, and I was mentioning the Supreme Court, I think it would be obvious that I was talking about the Supreme Court of China and not the Supreme Court of the United States. Likewise, if I were writing an article about Haiti and discussing a disputed presidential election, I think it would be obvious that I'm talking about the President of Haiti and not the President of the United States. Please give an example where there is a problem. ~ ONUnicornproblem solving 16:46, 17 June 2015 (UTC) (P.S. I realize China may not be the best example, and I really shouldn't have shortened it to "Supreme Court" when it's really the "Supreme People's Court" and by shortening it to "Supreme Court of China" one risks confusing it with the Supreme Court of the Republic of China - so that was a bad example.)

Dear Jon, we are aware that several articles on general subjects seem to give for taken that they are talking about the United States, or Western Europe, or the Western world.

We aim to make our articles describe the world in general. Unfortunately, sometimes we aren't careful and make these kind of mistakes.

Also, sometimes an article is written by very few people, whodon't know about the subject outside their region. We need more writes from around the world to imrpve the balance.

The only way to fix it is to be aware of the issue, to find articles with the issue and find the people who can solve it. You may be interested in the WikiProject Countering systemic bias.

Thanks! -- NaBUru38 (talk) 19:53, 24 June 2015 (UTC)

Permit WP:Red links in WP:Navboxes?

Opinions are needed on the following matter: Misplaced Pages talk:Red link#Proposal to permit redlinks in navigation templates; subsection is at Misplaced Pages talk:Red link#Revision proposal. A WP:Permalink for the matter is here. Flyer22 (talk) 20:14, 17 June 2015 (UTC)

Gradually enabling VisualEditor for new accounts

TL;DR: The recent test results show that there's no negative impact from offering VisualEditor to newly registered accounts. Here's a plan for how we might offer it more widely in a gradual manner.

Hi everyone,

Research results

Yesterday, Aaron shared the results and his analysis of the recent VisualEditor A/B test. We designed the test to determine how giving users of new accounts the choice between the visual and wikitext editors would affect their activities on the English Misplaced Pages, and the effects that would have on the English Misplaced Pages's means of curating new revisions. In particular, we wanted to find out whether it would enable more damage (e.g. vandalism and sub-par good-faith edits) to take place, and whether it would add any further burdens to the work of the community of change patrollers.

The A/B test indicates that giving users the option to use VisualEditor does not result in extra vandalism, nor does it lead to lots of poor-quality edits. More specifically, we found that:

• New editors who use VisualEditor create no additional burden on existing community members. They are no more likely to be reverted or blocked than editors who are offered only the wikitext editor. In fact, there's a slight reduction in the burden on admins when VisualEditor is enabled; and
• New editors who have VisualEditor available to them make as many good edits as those with just the wikitext editor, and stay around for just as long.

You can read more detail of the data collected and the means of analysis on Aaron's research page on meta.

Improvements

I think these results are related to improvements made to VisualEditor over the past few years. Since 2013, we've learnt a great deal about making VisualEditor a good experience for our new and existing editors alike, not least through working with the various wiki communities where VisualEditor is already enabled for all users.

We have processed thousands of bugs, tasks and feature requests surfaced by community. Since June 2013, we have made over 100 production releases, each with improvements for usability, stability and/or performance. We ran several surveys, including a targeted exercise to improve VisualEditor's function and design and make sure improvements reflected community concerns. We held monthly "office hours" for editors to share their concerns, and later switched to holding open weekly triage meetings to make that sure we prioritise fixes and improvements around the most important aspects for you.

Lately, we've been focussed on making simple edits as easy as possible for users who don't yet know wikitext, so that they can focus on making valuable contributions to Misplaced Pages. Some of the features and improvements that support this include:

• the auto-filled citation generator, which automatically creates a templated citation from online sources based on a URL or some academic reference IDs like DOIs;
  

  

  View as animated GIF
  
• a better link editor, which suggests links from the wiki with redirect and disambiguation pages flagged, and an image and the Wikidata descriptions for each article to make it clear where you're linking;
  

  

• we introduced a context panel, which shows some details about things you click on as you edit. For example, clicking a link will show you where the link goes; clicking a reference will show you the citation as it will show up in the references list; and clicking on a template will tell you which template is being used, with an 'edit' button to fix things that you want to change;
  
• 
• 

• you can now add columns or rows to tables (and do more complicated things, like merge cells) at the click of a button, which even very experienced users have said is a good deal easier to understand than staring at the wikitext. We've also expanded browser support to cover well over 90% of all our readers and editors, and worked with major browser makers to help iron out bugs in their browsers which VisualEditor has to work around; and
  

  

• load and save performance, which I know was a particular concern for many of you, has hugely improved.

I'd like to thank all the editors who have helped us improve VisualEditor over the past two years. The millions of times people have used VisualEditor has given us vital data points to analyse and improve. The time people have taken to find, report, and highlight bugs as they arose on-wiki has been superb. The community participation on-wiki, on Phabricator and elsewhere, and the help we've had from some volunteer developers and community gadget authors, has been great, and has really driven forward integration with existing tools and workflows.

Proposal

Given these results and the recent improvements, I think it is now time to undertake a slow, steady process in which we will gradually make VisualEditor available to more editors on the English Misplaced Pages. My current focus is strictly on new accounts, who I think have the most to gain from having VisualEditor available. To be clear, this would not involve changing the interface for existing editors. As always, existing editors here can opt-in to having VisualEditor available at any time via Special:Preferences.

So, what specifically would a graduated release for new accounts look like?

I always keep the impact on our current editors, patrollers, and curators at top of mind as I consider changes. Because no amount of testing and triage will ever catch every possible issue, I do not want to make changes quickly, and we have several processes in place to respond rapidly if anything does arise. To minimize any impact if problems do occur, we would gradually enable VisualEditor for new accounts, starting at 5%, which is about a dozen new active editors a day. This portion of new accounts would be able to choose which edit tab they wanted to use each time they edited: VisualEditor or the wikitext editor. The remaining 95% would get the existing experience, of just having the wikitext editor.

If that initial roll-out goes well, we would slowly and incrementally raise the threshold, making VisualEditor available to more new accounts. Throughout the process, we'd be carefully monitoring the on-going impact on both the new users and the wider community of experienced editors. Our regular public triage meetings will continue to take place, and I would be happy to continue the conversations there too, or on Phabricator. The pace of the roll-out would be determined by how well each step worked for all concerned, and the process would probably take a month or two before the choice reached all new users.

Again, this process would only affect newly created user accounts. Only once we're confident that the community's existing edit triage processes are faring well with the change for new accounts do I think we should look at enabling VisualEditor for logged-out users, as there are a huge number of edits made every day by IPs, and I don't want to swamp the community if anything does arise during subsequent testing.

As always, I would appreciate your thoughts on this proposal.

Yours,

Jdforrester (WMF) (talk) 21:15, 17 June 2015 (UTC)

Discussion - Gradually enabling VisualEditor for new accounts

• Absolutely yes. I have wanted this for a long time, specifically for new users. As a volunteer I participate in a lot of local Misplaced Pages trainings. We get some really smart people in the room—people who by all means should be Wikipedians. While we have been teaching our participants about wikitext formatting, it's an annoying obstacle. I want people who volunteer the time to write Misplaced Pages articles to be able to spend their time doing that—writing articles, and not finagling over whether it's two apostrophes or three apostrophes and so on. This makes the job of a Misplaced Pages trainer that much easier, and it makes editing Misplaced Pages a much more engaging the experience. I was at the National Institutes of Health, and someone needed help with a citation. I told him about our little secret VisualEditor, and boom! He had access to a full-on citation editor. This is the kind of experience that should be accessible by more people. I see a lot of promise in VisualEditor, especially since it is a lot better than it used to be, and I support this gradual launch approach. Harej (talk) 21:32, 17 June 2015 (UTC)
• Oppose If your study shows that new editors using VisualEditor "make as many good edits as those with just the wikitext editor, and stay around for just as long", what's the reason for the switch? What problem are you trying to fix? I'd want to see evidence that VisualEditor has a significant positive impact on editor retention and constructive contributions before it's rolled out. There are still significant issues with VisualEditor, and we shouldn't have to start cleaning up <nowiki/> tags everywhere for no good reason. --Ahecht (TALK
  PAGE) 21:39, 17 June 2015 (UTC)

  It would be nearly impossible to study VE's impact on "editor retention" without VE being rolled out to a large number of existing users for a long period of time. If VE's rollout is contingent on that evidence being available beforehand, then it will never be rolled out. And as for the "problem" VE seeks to resolve, it seems self-evident to me: most potential contributors in the world don't know how to edit wikicode, and VE removes that barrier of entry, allowing for more content creation and a better encyclopedia. That seems particularly important now, given that Misplaced Pages's editor base has been continuously shrinking over the past several years. –Prototime (talk · contribs) 06:02, 18 June 2015 (UTC)

  But it was studied recently. The May 2015 study looked at a population of 20,000 editors, half of whom had VisualEditor enabled as default. Of these two groups, nearly identical numbers (3386 vs 3363) made an edit, nearly identical numbers (2502 vs 2551) edited more than one article, nearly identical numbers made productive unreverted edits (1778 vs 1772), and an identical number were still editing 3-7 days after registration (287). If anything, this shows that Wikicode doesn't scare off new editors any more than VE does. --Ahecht (TALK
  PAGE) 19:47, 18 June 2015 (UTC)

• Support enabling I haven't used VE much recently, so I'll have more comprehensive thoughts on it in the future (I'm going to re-enable it now!), but from everything I've seen this is something the Misplaced Pages community, especially new editors, would really benefit from. Sam Walton (talk) 21:41, 17 June 2015 (UTC)
• This sounds like a reasonable strategy for deployment. I hope future major changes are rolled out in this way as well. Seraphimblade 21:46, 17 June 2015 (UTC)
• Strong support - I've been using VE lately for almost everything that I can and it's wonderful. I've been teaching newbies how to use it and they love everything about it, and are able to make productive edits much faster and able to do more complicated tasks much more efficiently. It is so much better than it used to be - really, it's now what it should have been when launched - and I think new editors can greatly benefit from a gradual launch. Keilana| 21:48, 17 June 2015 (UTC)
• Support: While I find the regular edit mode easier to use, it does not appear to me that it would not really hurt users who would opt not to use it in any way to have it enabled by default, but it would help with people who would use it but don't opt in for whatever reason. Jo-Jo Eumerus (talk) 21:50, 17 June 2015 (UTC)
• Tentatively support per the pro arguments above (I can't see any I disagree with, and I really want to see if it increases new recruits), but tentative per the second concern of Ahrect: the bugs. Do we have any info on when these will be fixed? Ahrect's first concern I don't share: We'll only know if it has measurable positive effects if we try it on a larger scale for a while at least. We can always turn it off again later (though should only do so for new new editors, not recent ones already using VE. PS: I personally loathe the VE, but I can understand why some people love it. Either you are a WYSIWYG person or you're a coder .  — SMcCandlish ☺ ☏ ¢ ≽ⱷ҅_ᴥⱷ≼  22:57, 17 June 2015 (UTC)
• Support. VE has greatly improved, and I think it's been ready for use on enwiki for some time now. Opposers would do well to remember that VE is vastly easier than the wikitext editor for new users to learn. — Mr. Stradivarius 00:37, 18 June 2015 (UTC)
• Strong oppose – New editors need to learn how to edit the encylopaedia properly. They needn't be misled with training wheels, such as these. The only way for a new editor to understand the workings of Misplaced Pages, the technical details, the intricacies of editing, is through familiarity with Wiki markup. That familiarity comes from experience. I'd say that the Visual Editor should only be allowed for editors who have acquired a prerequisite experience in markup, so as to ensure that all editors have a good foundational understanding of the way Misplaced Pages articles are constructed. RGloucester — ☎ 00:50, 18 June 2015 (UTC)

  Strange though it may sound to some, but VE is the proper way to edit, instead of trying to put all the 6433 lines of Parser.php into your head ;) Max Semenik (talk) 01:08, 18 June 2015 (UTC)

  Honestly this is reading to me as "I had to do things this way so now everyone else has to". People should not be expected to learn what is, with parser functions, a turing-complete programming language to be able to edit and it's ludicrous to say that new users should be expected to immediately "understand the workings of Misplaced Pages, the technical details, the intricacies of editing". Forcing someone to learn, in complete idiosyncratic detail, how systems work and then allow them to use something simpler and more intuitive to inexperienced people is precisely the opposite of how any process should work. To extend your analogy, if VE is training wheels, your proposal is giving a five year old a monster truck (because they can't drive if they don't know how a combustion engine works!) and then hoping they aren't terrified. Ironholds (talk) 14:35, 18 June 2015 (UTC)

  This. Veteran editors seem to forget that wiki markup was supposed to be an easy to use, simple mechanism for non-technical people to create well-formed content. That it has devolved through feature creep into a monstrous entity, requiring several megabytes of help pages and style rules to use correctly, is something to be ashamed of, rather than proud; even if every one of those features has proven essential to build an encyclopedia. VE may not be perfect yet, and I consider it phylosophically inferior to markup, but it recovers the spirit of "anyone can edit through dead-simple tools" that we should have never lost. Diego (talk) 15:30, 18 June 2015 (UTC)

  "Anyone can edit" isn't now, nor should it ever have been, the most important criteria of an actual reference work. As we've grown, "if every one of those features has proven essential to build an encyclopedia" has grown in importance. That shouldn't surprise or disturb anyone.—Kww(talk) 17:41, 18 June 2015 (UTC)

  So, you don't think that having a diverse and large user base is critical for achieving a neutral and comprehensive reference work, overcoming the systemic WP:BIAS? Well, I do. Diego (talk) 23:08, 18 June 2015 (UTC)

  Would you also require everyone who has a blog to understand and use PHP before using a text editor to make posts? What useful purpose could that serve? There is zero benefit in requiring contributors to jump through unnecessary learning curves to provide content to readers. Readers only care about the end product; it makes no difference to them whether contributors created the end product through intricate mastery of a programming language or simply using a text editor. Let's not make things more difficult for contributors for the sake of tradition and being "proper". –Prototime (talk · contribs) 17:48, 18 June 2015 (UTC)

• Support definitely. I think it is definitely possible to understand the "workings of Misplaced Pages" from VisualEditor. For the deeper technical details, sure, you need to delve into the wikitext of templates etc.; but most editors are simply not interested in doing that - their goal is to improve article content. VisualEditor has come a long way in the last two years; I use it regularly for the majority of article editing, and although there are a number of known issues, they will not affect the majority of our new users who perform more straightforward edits. Source editing is always available from the "edit source" tab alongside VisualEditor's "edit" tab in all cases, for those who prefer to use it. — This, that and the other (talk) 02:50, 18 June 2015 (UTC)
• Support; editing tables in VE is much easier than in wikitext. As long as the Wikitext editor remains an option, at this point I believe that VE is a net positive to enable at the start. I do think that VE should show what the equivalent markup would be in wikitext, however, as editors should still learn wikitext due to its greater versatility. StringTheory11 (t • c) 04:42, 18 June 2015 (UTC)
• Oppose Basic foundational bugs to the way VE handles template/table interaction still prevent using it from editing awards lists (see https://en.wikipedia.org/search/?title=Alice_in_Chains&veaction=edit&vesection=17), pop music articles (try to edit the tables in https://en.wikipedia.org/search/?title=Bette_Davis_Eyes&veaction=edit&vesection=7), and pretty much any of our myriad of articles that use templates to enforce consistent formatting across groups of similar articles. These bugs have been known for years and never addressed. Its whole approach to template editing makes it difficult for editors to see how our standard articles are constructed, and that leads to an inevitable and inexorable erosion in our ability to maintain consistent styling across projects.
  Further, we still have issues with stray "nowiki" tags being scattered across articles. Until those are addressed, the notion that VE doesn't cause extra work for experienced editors is simply a sign that the metrics used to analyze effort were wrong. Jdforrester, can you explain how a study that was intended to measure whether VE caused extra work failed to note that even with the current limited use, it corrupts articles at this kind of volume? Why would we want to encourage such a thing?—Kww(talk) 05:33, 18 June 2015 (UTC)
  • The nowiki edit filter is not specific to VisualEditor (phab:T53421). In the last 24 hours, it appears that there were about 16 edits using VisualEditor there.
    The A/B test was looking at overall edit quality, perhaps what you could call "all-cause mortality" for edits. Errors that are typical of each editing environment are treated equally by the test. A reversion due to someone mis-typing the number of or '''apostrophes'' in the wikitext editor (which happens many dozens, if not hundreds, of times a day) is equal to someone reverting because Parsoid added an unwanted nowiki tag as far as the test is concerned.
    Also, I'm unable to reproduce your bug report about editing the tables. I copied them to my sandbox, and, as you can see, I can edit them in VisualEditor. I was able to change both content and structure for these template-based tables. Can you be more specific about the problem you were encountering, and tell me what web browser you're using? (You can post the details at Misplaced Pages:VisualEditor/Feedback if you prefer.) Whatamidoing (WMF) (talk) 18:42, 18 June 2015 (UTC)
    • These are old bugs, Whatamidoing (WMF). Look at the display of the "result" column in https://en.wikipedia.org/search/?title=Alice_in_Chains&veaction=edit&vesection=17 and note the corrupt display of raw HMTL formatting. Try to change {{nom}} to {{won}}. If you can figure it out, then see if you can tell me in good faith that it was easier or more obvious than changing "nom" to "won". As for https://en.wikipedia.org/search/?title=Bette_Davis_Eyes&veaction=edit&vesection=7, I see that you did, indeed, add a Dutch100 entry. How on earth does an editor add the row to the table to add that? For music articles, that's probably the stereotypical newbie first edit, and I can't figure out how to do it for the life of me.—Kww(talk) 21:58, 18 June 2015 (UTC)
      • In the previous diff, I was removing the Dutch100 item. Here I change the nominated and won templates, and inserted a new Dutch100.
        The complex transclusion editor is, well, complex. The first change is pretty easy: insert a new template, slide it down to the correct position, and delete the old. The second took me a couple of minutes (it took two tries to because I didn't realize that it was validating the contents and therefore wouldn't accept "Kww" as a chart name ;-) I don't think the complex transclusion editor is mentioned in the basic user guide, but I can leave instructions on your talk page, if you really want to do it (there are two methods, depending on whether you know the wikitext for the template). However, what I'd rather see is both the wikitext there being simplified, and VisualEditor’s support for complex tables being extended, so that doing this is all quite easy for everyone, no matter what editing environment they want to use. Whatamidoing (WMF) (talk) 22:41, 18 June 2015 (UTC)
        • Whatamidoing (WMF), I notice that you haven't mentioned the corrupted display of the "results" column. I still don't see the point of an editor that makes relatively simple things difficult in the quest to make trivially simple things even more trivially simple.—Kww(talk) 21:58, 22 June 2015 (UTC)
• Support - The process laid out here is a reasonable, slow roll out of a product that is much more polished than its somewhat-bungled initial release a few years ago. I have no doubt that VE is not perfect, but perfection shouldn't be the standard, especially not for a slow rollout as proposed. Rather, the standard should be whether the benefits of rolling out VE outweigh the costs. Yes, there are still bugs to work out, but given the functionality of the product at this point, including the many tools listed in this proposal that were not available during its initial release, it seems more than ready to start being used across Misplaced Pages. –Prototime (talk · contribs) 06:02, 18 June 2015 (UTC)by
• Support especially with the proposed deployment plan. —TheDJ (talk • contribs) 08:52, 18 June 2015 (UTC)
• Comment this seems like a reasonable proposal (not going to oppose), although the estimated schedule of 1-2 months (in total?) is a bit short and should be longer. Such a slow partial rollout may be helpful to get additional feedback from other user groups. However, Visual Editor is not a finished product - the main focus should be on fixing the long list of remaining issues and improving the interface, not on getting it over with as soon as possible. And a note for clarity: if a significant number of additional errors occurs during this rollout period, further rollout should be stopped or delayed. GermanJoe (talk) 11:12, 18 June 2015 (UTC)
• Oppose: Isn't VE still in the beta? I don't feel like it's such a good idea to put a beta product to a new user. In the long term, yes, of course, VE should be the future. But I think it's more prudent to enable the software once it's complete (wikitext after all is complete and works perfectly). -- Taku (talk) 12:20, 18 June 2015 (UTC)

  @TakuyaMurata: VE is in "beta features" because it's not rolled out yet; that's where things tend to live until they're fully deployed. I wouldn't say Wikitext works perfectly; it is the baseline everything else is compared against, and when the baseline is "doing everything Wikitext can do"..well, yes, Wikitext can do that, but perfection it ain't. Ironholds (talk) 14:37, 18 June 2015 (UTC)

• Strong support. Ironholds (talk) 14:37, 18 June 2015 (UTC)

Hi, Ironholds. Please remember WP:NOTVOTE, especially because you might have special insight from your WMF role. I did see your comment above that makes it clear you think VE is easier but this seems counter to the May 2015 study that concludes there is "No significant difference" in "Newcomer productivity and survival" and there are "lower completion rates and more time to save". Also I have to wonder what, if any, conflicts of interests you may have as a WMF researcher on reader data. Have you worked on VE? Studied its user data? etc. Jason Quinn (talk) 20:10, 19 June 2015 (UTC)

You could always structure those queries as actual questions rather than leading ones; you're likely to get a better response. Try it.

My position above has, as you said, made clear what my opinion of VE is, and the study does not conclude there is "no significant difference" in "newcomer productivity and survival"; what it concludes is that in the first week or couple of weeks, VE is as-good as wikitext. Survival is based around much more than the first couple of weeks, of course - it also involves interactions further down the line when someone does not yet identify as "A Wikipedian" but is still contributing, and those further contributions are likely to be where wikitext really bites because it's where you run into issues around, for example, new article creations or precise formatting, a lot of the time. I've never worked on VE in a research capacity and my only work studying its user data was grabbing lists of users for the community liaisons to poke around beta testing; I'm pretty confused as to what logical chain you followed to decide that someone who studies how readers interact with our search systems would gain some benefit from people editing, or not editing, external to their benefit as a Wikipedian from having more Wikipedians around. Could you explain that?

What being a researcher has taught me, however, is that there are several potential confounds here which would make the VisualEditor potentially appear worse than it is: in other words, we can probably treat "not worse" as a baseline. For example, users previously editing as IPs, or under other accounts, who sign up and are confronted with the VE, have some adjustment time; the short length of the study and the fact that it is only a study of a percentage of logged-in users makes it difficult to test for previous activity or measure adaption time for that class of user. Hopefully this adds additional clarity. Ironholds (talk) 21:34, 19 June 2015 (UTC)

I had only one query (about any potential COI). The rest of my message was a reminder that just saying "support" is not an argument which I was hoping would function as a nudge for you to add one since your two prior replies cannot really be said to contain a cohesive argument. As for the study, it does conclude there's "no significant difference" in "newcomer productivity and survival". I copied and pasted directly from the Results section of the study. (Look at the TL;DR summaries.) Regarding the rest of your comment, I think it supports my idea that VE needs longer and more expansion trials but not necessarily enabling. Also when you say "I've never worked on VE in a research capacity", does that exclude as a developer? Jason Quinn (talk) 22:10, 19 June 2015 (UTC)

Outside of our analytics stack I've never worked as a developer for the Wikimedia Foundation full stop. Ironholds (talk) 22:31, 19 June 2015 (UTC)

• Support - The case seems to be fairly strong for this proposal, and some of the new features may even have me giving it a try again. Obviously, if VE is shown to have significant issues or if it creates more work work for experienced editors, then this gradual roll out can be halted while the issues are addressed.- MrX 14:54, 18 June 2015 (UTC)
• Strong support as someone who does outreach in GLAM and Education, appreciates the significant table editing improvements in VE and who has heard direct feedback on the positive impact of the VE on other language communities for training new users and for making people less scared of editing: I fully endorse the need for this, Sadads (talk) 15:26, 18 June 2015 (UTC)
• Neutral, leaning towards support with caveats. I'm torn on this one. On the one hand I'm all for providing newcomers with tools adapted to them ASAP. On the other hand, there is the matter (explained above by other editors) of hard-to-spot and randomly-appearing bugs that could erode the quality of articles througout the whole project. Given the precedents of WMF pushing problematic code without a back-off strategy, I'd rather have the deployment strategy made of several steps controlled by the community -who should greenlight every new batch of users exposed to the tool- rather than a WMF-controlled roadmap, even if it's flexible. Diego (talk) 15:46, 18 June 2015 (UTC)
• Neutral leaning oppose. On one hand, VE is quite handy when editing templates or inserting references. On the other, it is buggy. I can recall two times; once it left "nowiki" tags and once it revertde to a past version of the article. You don't want to drive away newbies who get confused about what happened during their edit. --Fauzan_{✉ mail} 17:49, 18 June 2015 (UTC)
  • Hi Fauzan, thanks for this note. Do you happen to have a diff from the edit that ended up with the wrong version? It would be really helpful to me. Whatamidoing (WMF) (talk) 19:00, 18 June 2015 (UTC)
• Support. Several months ago, for the first time, Wiki Education Foundation asked a handful of classes to get started with VE instead of wikitext. It went well enough — and enough of the problems that came up have been fixed since then — that I think VE is ready to become the default for new editors. Hopefully, as VE continues to improve, we'll see it overtake wikitext in terms of new editor retention and productivity. --ragesoss (talk) 19:49, 18 June 2015 (UTC)
• Oppose It's just not quite ready yet. I like the idea of the VE and I really want to support, but the known are currently a problem. It wouldn't be so bad if a bot could easily clean them up, but it's not feasible to build one to effectively remove them. I also gave a test of the VE, the interface really lagged, and somehow I managed to completely mess up the article. I'm not sure what I did to do that, but suddenly half the article was missing.—_Chat:Online 23:38, 18 June 2015 (UTC)
• Neutral I can understand how visual editor is easier for someone just starting out at Misplaced Pages. Making simple copy edits using it is much easier. The problem comes when you try to do anything more complex. It's not at all clear how to create wikilinks, cite sources, insert pictures, or edit tables. If one is editing the source code it may be confusing at first, but you can copy what was done on other articles to get the same result in the article you're working on. So it has pros and cons. Make the UI more clear so it's easier to figure out how to do things other than change "adn" to "and" and I'll support.~ ONUnicornproblem solving 23:46, 18 June 2015 (UTC)
• Question Has there been any analysis of the effect of VE on newbies' participation in talk page discussions? The biggest thing I'd be concerned about with wider deployment is that talk pages still use wikitext. It's a standard expectation, and common advice to newbies, to engage on talk pages when there are problems or concerns about an edit. Introducing VE to newbies in effect asks them to learn two systems at once, and they won't develop any experience with the wikitext used on talk pages from editing articles and seeing the relationship between existing markup and the visual result. (On the other hand, maybe the edits they produce with VE are less likely to be misformatted or missing references, and therefore are less likely to be reverted or require discussion?)

In any event, I support a broader rollout; I just suspect the behavioral dynamics of newbie interactions might be different in ways that aren't captured by "productivity" metrics. Opabinia regalis (talk) 23:51, 18 June 2015 (UTC)

• Support a gradual rollout to new users, with a plan to roll it back in the pocket if needed. I would like to note that I'm expressing support as a long-time Wikimedia volunteer, as a WMF community liaison I have not worked with VisualEditor in well over a year. Keegan (talk) 06:25, 19 June 2015 (UTC)
• I support a gradual rollout too. I am using VE more and more these days and it's definitely better than it was. There are still some instances where only wikitext will do, but these don't generally relate to things that new editors will want to do. — Martin (MSGJ · talk) 08:24, 19 June 2015 (UTC)
• Oppose and Object. This proposal is too biased and too soon. The proposal begins by mentioning "no negative impact" from VisualEditor while ignoring that the same study also found that there's no positive impact either. Ahecht thankfully mentioned this in an early comment. This is important because a few of the support comments are worded such that it suggests their authors did not read the study's results and therefore their support comments were biased by the proposal itself. I hope the closer of this proposal takes this into account and weighs those comments accordingly. This discussion was initiated the day after the results of the A/B testing were announced. That gave inadequate time for public review, discussion, and digestion of the results and methods of the study. I also believe the subsequent wording and structure of this proposal is too non-objective to initialize a fair discussion. Maybe the VE is ready to enter more advanced trail phases to gather more data on its use. This proposal, however, guarantees the eventual deployment of VE by default for all new users because there's no way of "unrolling it" if VE is less efficient on average than text editing. The proposal only implies the rate of increase would slow temporarily if "problems" were detected. (What counts as problems also needs detailing.) By "enabling" VE via this proposal, it's akin to planting an seed that there's no intention of uprooting if it turns out to be a weed. A neutral proposal would have to give conditions under which the threshold would be incrementally decreased, something the proposal never addresses. Jason Quinn (talk) 19:41, 19 June 2015 (UTC)
• Strong Support Eventually we are going to need to move towards VisualEditor enabled by default, and I'm in favor of adding it now. With the ability to generate citations from doi and pubmed-id I'd probably switch to it for most non-template work myself. There are some quirks, but there are quirks in mark-up as well, and as long as development continues I support it. -- CFCF 🍌 (email) 21:10, 19 June 2015 (UTC)
• Oppose current proposal: Needs a little more work - I think that Visual Editor is an excellent idea, but would suggest that we need to have some prep work done first: 1. All users it rolls out to should have a video or the like explaining both Wikitext and VE (and not just "VE makes this easier" - it should explain the Wikitext alternative as well, with particular focus on templates.) We're probably going to be in a state where we need both for a while still, so let's make sure VE users can find the Wikitext help they need when it becomes needed. Adam Cuerden 23:14, 19 June 2015 (UTC)
• Support I have been trying VE for some edits and I have found it reliable for tasks newbies tend to perform (copy-edits, straightforward content writing, linking...). Wikimarkup is a really intuitive markup language, but most people don't use markup languages at all. Enabling VE for new editors by default will allow them to get started without as many frustrations. They will still need to learn wikimarkup eventually, but they won't need it from the get-go. BTW, even with VE enabled, you still have an edit source tab, and a link on every section so the text editor is not innaccessible. My only two suggestions would be to allow new users to choose VE or not in the account creation process (with good information, including that this choice is reversible), and to tag accounts that opt in so that editors trying to help them know what is going on. Happy Squirrel (talk) 01:25, 20 June 2015 (UTC)
  • Hi Happy Squirrel, thanks for the suggestions. The old team in charge of WP:GettingStarted was pretty firm that every extra option in the sign-up process led to a measurable decrease in the number of people who created accounts. Consequently, their thinking seems to be more about providing information after the sign-up process is complete (e.g., a note pointing at the Beta Features link or a GuidedTour once you open it) rather than in the middle of it. Most of the new editors in the study seemed to be able to figure it out for themselves, though. One of the main differences between the two groups was that a lot of the editors with access to both opened both, poked around for a while, and then picked the editing environment they wanted to use for their edits.
    You shouldn't have much trouble telling which editors are using VisualEditor, since every single edit made in it is tagged. These tags should be visible in your watchlist, page histories, and RecentChanges. Whatamidoing (WMF) (talk) 06:33, 20 June 2015 (UTC)
• Weak oppose - While it seems to have made a lot of strides, there are still some issues. The auto-filled citation generator is somewhat problematic. If you give it a URL for a site it doesn't "recognize", it returns an incomplete citation with nothing but the title, URL, and access date. But then rather than prompting you to fill in the rest, you have to insert it and then click a whole bunch of things to be able to manually fill in the extra data. Its handling of DOIs is also spotty. In particular, it doesn't work with journals published by one of the largest scientific publishers. This appears to be because, as far as I can tell, it extracts the data from the publisher's website and needs special code for every single publisher, even though CrossRef has an API for extracting metadata from DOIs (that, not to brag, reftoolbar handles with around 50 lines of code that works for virtually every journal). And for the journals it does work for, it frequently produces incorrect output. Of 4 journal articles from 4 publishers I tested, it didn't work 100% correctly on any. 1 was an Elsevier journal that didn't work at all, 2 produced dates in a format not accepted by the template, and 1 filled the ISSN field with "null." Mr.Z-man 02:44, 20 June 2015 (UTC)
• Maybe New editors should be given the choice. VE may be better for some while other may like the old text editor. Having this choice may improve editor retention. We all do not need to do things in the same way. There are still improvements I would like to see such as if the DOI or PMID is given a url is not typically needed. I do like that if one gives it a PMID it automatically also finds and fills in the DOI. One concerns is that this will make it harder for new editors in that they will being using one system for the article and another for the talk pages. Doc James (talk · contribs · email) 06:54, 20 June 2015 (UTC)
• Support much easier for new users, although not ideal for experienced editors. --Tom (LT) (talk) 08:55, 20 June 2015 (UTC)
• Oppose Rolling out to new users until two eminently fixable issues are addressed. (1) It doesn't display the BLP EditIntro, which is an important policy notification that new users should be made aware of. The edit intro for disambiguation pages is also helpful. (2) The options, advanced settings and languages tabs should be removed altogether since they are useless to new users, and to everyone actually since they provide functionalities either unused in mainspace or incorrectly handled (e.g. redirecting keeps the old page content), and on the other hand the possibility to edit categories should be more visible. Although the second point can be 'fixed' by playing around with css and js, the first point requires software changes: phab:T56029. Cenarium (talk) 14:11, 20 June 2015 (UTC)
• Support This is a slow rollout only affecting new users. There is research done that shows that this won't cause major problems to existing editors, and there really has been a lot of progress made to Visual Editor it looks like. Its definitely worth noting that the new users this affects would not be forced to use VE, as they will just be shown two buttons, one for VE and one for Wikitext. This proposal would give new users a choice. I would support this proposal. I see no good reason at the moment to oppose. Zell Faze (talk) 20:42, 20 June 2015 (UTC)
• Oppose To support something on the basis of a study that has shown no real benefits because it has shown only minor disadvantages seems paradoxical. Until it actually improves the experience for new and old editors, there is no reason to enable it. A VE certainly has potential advantages , and I look forward to see a version that actually realizes it. DGG ( talk ) 23:51, 20 June 2015 (UTC)
  • Hi DGG, the research study found that there is one small but real benefit (slightly fewer of their edits needed to be reverted), and that everything else is equal. It found no disadvantages. The types of errors or complications differ between the two editing systems, but the net effect is slightly positive for editors who have both editors available. Whatamidoing (WMF) (talk) 00:32, 21 June 2015 (UTC)
    • You mean the result that the study described as: Rigor tells us we can't believe this result. Either there is a real, but very small effect or non at all. --Ahecht (TALK
      PAGE) 04:48, 22 June 2015 (UTC)
      • I mean the result that the study described as "editors in the experimental condition produced slightly fewer revisions that would need to be reverted (W = 5869081, p-value = 0.007)." The sentence you've quoted from his work log referred to an erroneous calculation (read the next sentence, which begins with the word "Oops"). Whatamidoing (WMF) (talk) 17:26, 22 June 2015 (UTC)

  DGG, there's one way in which VE improves the editing experience, but I don't think it's going to be easy to measure. I've switched almost entirely to editing articles in VE, and I am much more productive as a result. I would like to see the option made more visible to new users because some of them may have the same experience I did. I'm basing my support not so much on the experimental evidence above as on my own experience with VE. Mike Christie (talk - contribs - library) 12:16, 21 June 2015 (UTC)

• Strong oppose - find a way so that next to the regular 'edit' button there is a 'visual edit' button, where EVERY editor has simply the plain choice to choose whichever editor they want to use. An absolute strong oppose to enforcing user to use one of the editors, an absolute strong oppose to abandoning the old editor (I am hoping that you will never even start considering to abandon the old style editor anyway, so there is no reason why these cannot run next to each other and giving the person who wants to make an edit a choice). --Dirk Beetstra 06:33, 21 June 2015 (UTC)

  Dirk, unless I'm missing something your comments aren't addressing what's been proposed. The wikitext editor will be visible to all users, in the enabled group or not. There's no suggestion of eliminating the wikitext editor, and I can't imagine anyone suggesting something so foolish. The proposal is what you suggest it should be -- give editors both buttons so that they have a choice. Can you clarify what you're opposing? Mike Christie (talk - contribs - library) 12:11, 21 June 2015 (UTC)

  Mike, I oppose having it standard enabled for any user, I want every user to, on every single edit they wish to make, to have a direct choice, not 'edit goes to VE' (and if I need source-editing I have to click somewhere else), or 'edit goes to source-editing' (as it is now), I want just two buttons - one for VE and one for source - so I can chose on every single edit which one to use, and that choice has to be clear: one button with 'edit with VE', one button with 'edit source'. No settings needed to be changed, no standards needed to be changed. Hence I oppose. --Dirk Beetstra 13:27, 21 June 2015 (UTC)

  Basically, what I want to see is what currently is the case when you enable VE: two tabs, one saying 'edit source' and one saying 'edit' - but I want the latter to specify that it says 'edit (VE)' (or something similar making clear that that 'edit' is using the VE-engine). Then there is no need for settings to be enabled, and it is clear what you get (like VE: what you click is what you get). --Dirk Beetstra 13:33, 21 June 2015 (UTC)

  I think I follow. Just to check: are you saying that if the label on the "Edit" tab were changed to "Edit VE" or "Visual edit" or something similar, you would support this proposal? Mike Christie (talk - contribs - library) 15:31, 21 June 2015 (UTC)

  It would make it better, but I still don't think that new editors should be subject to this - it should be the experienced editors who take out all glitches first, a new editor, when the vE is behaving weird, is unlikely to figure out how to do the 'emergency repair'. The whole thing is again smelling of 'we think it is good to have it, we spend money and time to develop it, we want people to use this, we'll push it through somehow'. --Dirk Beetstra 03:32, 22 June 2015 (UTC)

• Support. No doubt more bugs will be found each time the threshold is raised; I hope the process for raising the threshold will include further review here, and some discussion of any serious bugs that cause damage to articles. Mike Christie (talk - contribs - library) 12:11, 21 June 2015 (UTC)
• Support. I don't plan to use VisualEditor—wikitext manipulation is much more powerful—but pushing it to newbies is a good idea. It's one less barrier to entry at a time when we could use more participation and when the average newbie probably hasn't had much experience with markup languages. I do share the concern that we should try to avoid "scaring people off" from wikitext—for example, I think we ought to pair VE with a syntax-highlighting wikitext editor—but this is the next step in removing a barrier to entry for those unwilling to learn wikitext markup. {{Nihiltres|talk|edits}} 14:47, 21 June 2015 (UTC)
• Support The benefit to acclimating new users (less reversion) is good, and in some opposes, I hear the echo of that paper encyclopedia meeting circa 1999 (new tech? new systems? no, no, no - and then they were history), in other opposes, I hear, 'this thing should run before it walks (or perfect is the enemy)' -- well, this is what walking is - so that running may come some day. Alanscottwalker (talk) 15:09, 21 June 2015 (UTC)
• Support We need to be forward looking. I agree VE is not perfect. Will it ever be for everybody in every possible situation? Sure no. Is it good enough to attract and retain a new generation of editors? Yes. Then VE is worth a shot. --Afernand74 (talk) 20:55, 21 June 2015 (UTC)
• Support We don't need habitual reactionaries; we need to attract more qualified editors.--Anders Feder (talk) 21:40, 22 June 2015 (UTC)
• Oppose but kudos for improving V/E to the point where it is no worse on average for newbies as the classic editor, that must have taken a huge amount of work. I still believe that a good WYSIWYG editor would be way better than the classic editor. But it would be premature to deploy it now. Remember one of the won't fix bugs was that it was written to take advantage of the latest chips and in consequence runs glacially slowly on old kit. So the people we'd gain from V/E are the ones who don't like the wall of text and profusion of curly brackets and the like, they will still be ready for us when and if V/E is ever clearly better than the classic editor. But if there is no net advantage to V/E then we can assume that the people we gain will be matched in number by the people we lose because V/E runs ridiculously slowly on their PCs. As a global inclusive organisation we shouldn't discriminate in such a way. ϢereSpielChequers 21:48, 22 June 2015 (UTC)
  • Hi WSC, I’m not sure which old bug you’re talking about. The team have dealt with over 4,000 requests by now. Do you have a link to it?
    They spent the last few months dramatically improving performance. In fact, in parts of Central Asia or Africa, it is usually faster to open a page in VisualEditor than in the wikitext editor. (In North America and other rich countries, the wikitext editor usually edges out VisualEditor; it depends upon the Internet setup in each place.) The main idea is to give people a choice and let them decide what works better for them. Why don’t you try it out? Just click http://en.wikipedia.org/Special:Random?veaction=edit a few times, and see what you think. Whatamidoing (WMF) (talk) 23:49, 22 June 2015 (UTC)
    • One of the problems of running the bugs on bugzilla and or whatever system they used for V/E is that they don't get included in your watchlist and those of us who raise bugs don't get told if they are fixed or not. I reported a lot of bugs in early 2013, most were archived without comment because even before it was first rolled out there were too many bugs coming in for the devs to keep up with. But one of the bits of feedback I did get was that my experience of extreme slowness with V/E wasn't the IO issue I'd assumed but was down to my then using an old machine, and that this was a "won't fix". I have since replaced that machine, so hopefully the bug would no longer affect me, but no-one has told me that the "won't fixes" have been fixed, I've no doubt that many of the things they were trying to fix have been fixed and that the software is not as bad as it was two years ago, but the evidence of retention rates is that if the hypothesis that we need a WYSIWYG editor to recruit most non programmers, then V/E still has a long way to go. As for your invitation, thanks, but after my previous experience with V/E testing I'm very reluctant to spend my time testing new WMF software again. ϢereSpielChequers 09:46, 23 June 2015 (UTC)
      • I tend to agree with you about the "off wiki" problem for bug reports. I've looked through the archives and found several discussions you participated in (beginning here), but I was not able to find anyone saying that performance improvements were a wontfix issue. In fact, improving performance has been a major goal, with a dedicated sub-project. I've had several editors tell me that they use VisualEditor successfully with older computers, including one who says that VisualEditor is faster than the wikitext editor on his nine-year-old computer. I've heard no significant complaints about speed for months.
        However, the actual speed is a bit of a red herring: the point of this proposal is only to give new editors easy access to the choice, not to make them use VisualEditor. They can decide for themselves which works best for them or their computers. I believe that the choice between wikitext and VisualEditor should be in the hands of the individual editor, so that each editor can freely choose whichever one is better for that editor's own situation. Whatamidoing (WMF) (talk) 05:39, 24 June 2015 (UTC)
        • VE is about 2-4 times faster now compare to 1,5 years ago in my experience. But it will never be as fast as wikitext editing. Then again. MS Word, Google docs, and Pages aren't by a long shot as fast as notepad either and all have their fanboys. —TheDJ (talk • contribs) 18:24, 24 June 2015 (UTC)
• Support Making new users think about what they are doing and looking more modern is better than the current system. VE could be better, but I support adding thing that help new users. New users are always good. --Frmorrison (talk) 15:21, 23 June 2015 (UTC)
• Strong upport. Giving new users the choice of which editor to use (VE is best for some things, Wikitext is best for others), and rolling that choice out gradually is a Good Thing for Misplaced Pages. As long as bug reports continued to be monitored (and I have no doubt at all they will be) then I cannot see any disadvantages to this. Thryduulf (talk) 09:57, 24 June 2015 (UTC)
• Support. It is thoroughly ridiculous that we make new users manually enable an editing system that is demonstrably easier to understand and requires far less of a learning-curve for new users to operate effectively, and yet we are perfectly happy showing them a highly complex code system by default. At this stage of VE's ongoing development, the only reason that we would not want to allow people to have the option of either system by default is because we want to retain the higher barrier to entry for newbies. Wittylama 10:31, 24 June 2015 (UTC)
• Support. I have it enabled and it has worked well for me the times I've used it. I often edit from diffs and the like so, often end up using wikitext directly mostly out of habit. I've also used visual editor or other wikis and believe it would be useful as a default for new editors. My biggest problems is occasionally running into places where it isn't able to edit, or on really long pages minor performance issues, though in most of those cases that really is a sign that the page should be split. PaleAqua (talk) 20:07, 24 June 2015 (UTC)
• Oppose, for a while. (My Wikitext browser crashed, so this may be a shortened version.) IMO, the reversal rate is not a good measure of the error rate. In my experience, most wikitext editor errors can be seen, even just when reading; while VE errors, except for "snowmen", often require careful investigation of the wikitext to discover. Furthermore, I could be wrong, but I don't think all the "show-stopper" bugs have been fixed. — Arthur Rubin (talk) 23:14, 24 June 2015 (UTC)
• Oppose, I did try to use it, but it is useless for me. If VE had been the default choice when I started editing Misplaced Pages, well, then I would never have become a Misplaced Pages editor. Huldra (talk) 23:29, 24 June 2015 (UTC)

Non-voting discussion

Should we be doing this when talk pages aren't covered by VisualEditor? I'm a bit worried about pushing two different editing styles on new users. Adam Cuerden 21:15, 20 June 2015 (UTC)

Here are two points I think you should consider: First, most new editors don't use talk pages at all (only about 4% of all accounts that registered during the recent research used a talk page). Second, this part of the study analyzed edits by namespace, and there was no statistically significant difference in the use of talk pages. If learning wikitext at the same time as learning the much more familiar, word-processing-style environment was too difficult, then we should have seen a difference there. Whatamidoing (WMF) (talk) 00:39, 21 June 2015 (UTC)

Some questions on the study:

• How many editors in the experimental group disabled VE? There appears to be data on editors in the control group that enabled it, but not vice versa. (And if there's a difference, is there any asymmetry, like editors in the control having a link encouraging them to try VE but not vice versa?)
• What are the absolute numbers for numbers of reverted edits (the metric for which VE performed better)? I can't see any information here, only the information for number of editors blocked. Also, why was this comparison only analyzed with Wilcoxon given that most of the others used both Wilcoxon and chi-squared?
• The Wilcoxon signed-rank test is a test for paired data - how and when was the pairing done, and shouldn't the control and experimental groups have the same number of editors if the data were paired? (I haven't used this test much, so apologies if I'm missing anything basic.)
• What correction was used for multiple hypothesis testing?
• Where can we find the raw data, e.g. in CSV format?

Thanks, Sunrise (talk) 02:01, 21 June 2015 (UTC)

I don't think that anyone knows how many editors changed their preferences. What's known is how many people in each group actually used VisualEditor.

You may find the other information in the work logs. In the infobox at the top of this page, you will find a link to the dataset. I'm sure that EpochFail will be happy to discuss his research with you next week. Whatamidoing (WMF) (talk) 05:17, 21 June 2015 (UTC)

Thanks! I hadn't been aware of the links to the work logs or dataset. One thing that concerns me is that according to the work logs for revert rate here, Halfak seems quite doubtful that an effect exists, but on the summary page and in the above discussion, it seems to be presented as a solid result. (The conclusion that the effect probably isn't real is a sentiment I felt as well after reading the summary, and was partly the motivation for my questions.) There also seems to have been a translation from "no difference found," which is what this type of analysis tells us, to "definitely no difference" which is a very different statement that a p-value analysis can't tell us about.

I do think the majority of my previous comment is still relevant, but I'm happy to wait until the wilderness vacation is complete. :-) Sunrise (talk) 06:58, 21 June 2015 (UTC)

Hey folks! I just got back. It seems like these questions are best posed on the study's talk page since this conversation will be fragmented otherwise. See m:Research talk:VisualEditor's effect on newly registered editors#Sunrise's questions. --Halfak (WMF) (talk) 14:26, 24 June 2015 (UTC)

For the record, we do log preference changes in EventLogging, so someone with the appropriate access could look it up if they wanted to. Legoktm (talk) 06:08, 23 June 2015 (UTC)

What about a choice

Can someone from WMF please explain why this editor has to be, excuse my wording, shoved down the throat of people. It is my hope that the old-style editor is not going to be abandoned completely anyway (it should always be available to edit out quirks that the VE did not manage to handle for whatever reason), so why not run them next to each other - always? Just have for every person both the 'edit' and the 'visual editor' choice and they can ALWAYS use whatever they want. Why the insistence (including spending development money on studies showing that the new editor is just as good or even better than the old one) to have everyone use the new editor - give the choice, and when your site-stats show that 99%+ of the editors is using the new editor by choice, then you can consider to make it a default choice (but still keeping the old option available). --Dirk Beetstra 06:40, 21 June 2015 (UTC)

Yes the old editor must never be disabled. I hope there are no suggestions that it will be.

I agree people should be given a choice. Maybe both should be shown by default with a "visual edit" button and an "edit" button. People should than be able to keep both, turn of one, or turn off the other. I would support this rolling out. Doc James (talk · contribs · email) 07:57, 21 June 2015 (UTC)

There is NO need to have 'edit' standard go to VE, just give everybody a second edit button next to the first one, and make sure that one clearly goes to VE ('edit (VE') and one to source ('edit source'). As editing the wikisource may be confusing to editors, that will also be the case for using the VE (and the ratio we can guess or determine later). Not having 'edit' standard go to VE, but make sure that on button goes to a visual editor, and the other to wikisource editing. Not a standard set choice, but a choice every time. --Dirk Beetstra 08:05, 21 June 2015 (UTC)

Yes that is what I mean. The edit button goes to the normal editing mode. The "edit visual" goes to VE. The normal editor is on the left the VE button on the right. People can remove either if they wish. Doc James (talk · contribs · email) 08:13, 21 June 2015 (UTC)

I don't understand this objection, because it's requesting what's been proposed. The proposal is to give new editors a choice between editing environments. If you want two buttons for new editors, so that they can easily make their own choices every time, then you should be supporting this proposal. If you want only one button, so that new editors cannot choose VisualEditor, then you should be opposing this proposal. Whatamidoing (WMF) (talk) 17:01, 21 June 2015 (UTC)

Yes I sort of support the proposal. I would prefer the old edit button called "edit" and the new edit button called "visual edit"

I would also like to keep the ability to turn of one or the other button to clean up the user interface. Doc James (talk · contribs · email) 04:03, 22 June 2015 (UTC)

They'll have the same button for enabling and disabling VisualEditor via Beta Features that you have now. Whatamidoing (WMF) (talk) 06:05, 24 June 2015 (UTC)

It seems to me that this discussion is about the normative position - whether the word "edit" should apply to the old style or the new style, and by extension, what should the "other" form of editing be called. For example: "edit / edit (beta)" and "edit (source) / edit" actually mean the same thing. BUT, this is a side issue to the question of allowing new users to have BOTH options turned on by default. Wittylama 10:23, 24 June 2015 (UTC)

Yes agree it is a side issue and a super easy one to address. I guess we could have a separate RfC to discuss it. Doc James (talk · contribs · email) 10:57, 24 June 2015 (UTC)

I agree that this is a side issue, one that should be discussed in a separate RFC (and probably after this current RFC is concluded, since the button labels will be a moot point if the community rejects the roll out). –Prototime (talk · contribs) 21:51, 24 June 2015 (UTC)

Without presuming to speak for the product teams, this old essay may be helpful in understanding the costs that choices/preferences impose on developers, QA, and users (especially new ones). Another variation on the same theme was written by the team at 37 Signals as part of their influential book "Getting Real".—Luis (talk) 21:33, 24 June 2015 (UTC)

Alternate proposal - choice of VE or source-editing at any given time an editor decides to edit

Every editor gets next to the original 'edit' tab a new tab with the title 'edit (visual editor)', and the old edit tab is renamed 'edit (source)' (appropriate naming making unambiguously clear to which editor an editor goes to be determined). The 'edit (visual editor)'-tab leads to the VE-editor, the 'edit (source)'-tab leads to the current edit interface. In the preferences, we get an option choosing either both, or one of the two are visible, and we have a follow-up RfC whether the two tabs are standard visible to every editor who did not make a choice either way.

• Support as proposer. --Dirk Beetstra 09:55, 21 June 2015 (UTC)
• Comment When VE is enabled, this is exactly what you see, except that the VE edit tab is just marked edit. The option to have both tabs or one is in preferences under beta. This RfC is precisely asking whether both tabs should be visible by default to new editors. Happy Squirrel (talk) 16:36, 21 June 2015 (UTC)
• This is, indeed, exactly the proposal at hand, except for the question of what names ought to be on the buttons. If anyone has ideas about how to make this clearer (maybe we should move the screenshots to the top, and label them "If you want two buttons, then support" and "If you want one button for wikitext only, then oppose"? I just don't know how we ended up with this level of confusion today. Whatamidoing (WMF) (talk) 17:04, 21 June 2015 (UTC)
• Support Some of use want the button more clearly named. I like the proposed naming here. Doc James (talk · contribs · email) 04:06, 22 June 2015 (UTC)
• Seems like a community issue to me. MediaWiki namespace and you can call it "Editor for newbs" and "Editor for nerds". I'd preach about consistency, but I've given up on that with en.wp, Commons and de.wp. —TheDJ (talk • contribs) 18:35, 24 June 2015 (UTC)

Turning a blue link to a red link without deleting the page

This might haven been proposed before, but wouldn't it be nice if there is a way to make a link to a page in the main name space a red link (meaning there is no artcie on the topic) without actually deleting the page. The reasons why some editors (especially I) want this feature is that the content on the page should be deleted; because it is wrong or in a wrong place, but the edit history contains some non-trivial information (e.g., edit summaries). Having a "blue link" gives a wrong signal that the article on the topic exists.

Implementing this feature probably requires a change in software, but what I have in my mind is putting a template like {{red link}} makes the link to the page a red link even when the page exists technically. Am I making sense? -- Taku (talk) 12:11, 18 June 2015 (UTC)

I'm not sure I understand why this would be useful. Do you mean that you want a feature where a page's contents can be deleted but the history remains? Sam Walton (talk) 12:13, 18 June 2015 (UTC)

Yes, basically. I just want to see an "option" to be able to do this. Right now, the only way to make a link a red link to delete the page. Sometimes you just want to make a link a red link so not to mislead the readers following a blue link to lead them to further information. Deleting the page really deletes everything (I suppose one can move the page and then request the deletion of the newly created redirect, but that's convoluted.). -- Taku (talk) 12:44, 18 June 2015 (UTC)

Surely this would only be a short term solution until the page is deleted? Couldn't you just remove the wikilink entirely if the page is that bad (i.e. being speedily deleted)? Sam Walton (talk) 12:45, 18 June 2015 (UTC)

No, sometimes the content or the edit history itself is not problematic, but it's under the wrong page title, for instance and resolving the issue can be nontrivial. You don't want to delete it, but you don't want to make an impression the content under the page title exists . In other words, I want a way to signal the readers that they shouldn't follow the link without actually deleting the page. -- Taku (talk)

So you are saying the page that is linked should be moved to the correct name and the redirect deleted or that one of the articles needs to be disambiguated. Do you have an example that shows what you are talking about? -- GB fan 12:59, 18 June 2015 (UTC)

Sometimes that simple option is not available since the the target page exists. Merging the contents could be nontrivial and take several months in some cases and meantime the link remains blue. -- Taku (talk) 13:26, 18 June 2015 (UTC)

Articles can always be moved, sometimes it takes an admin to move it, but any article can be moved. -- GB fan 13:33, 18 June 2015 (UTC)

Is this actually meant to provide a mechanism for giving non-admins access to a sub-class of deleted pages (especially their histories)? --Boson (talk) 13:03, 18 June 2015 (UTC)

Yes, very similar. Yes, there is some workaround like moving a page around, but then you need to make sure some other editors are able to find the new page but right now there isn't a way to do this without turning a link blue.

I suppose it's similar to the concept of zero. Right now, we cannot say there is no content since saying "there is no content" (e.g., blanking the page) makes the link to the page blue (suggesting there is content.)

To give an example, the feature I'm proposing can be used as an outcome of "article for deletion" process; instead of deletion, there is an option to turn the page to "no content"; making the link red without actually deleting the edit history since for instance some other editors may find the edit summaries useful. -- Taku (talk) 13:26, 18 June 2015 (UTC)

If someone clicked on this artificial red link, where would it take them? -- GB fan 13:30, 18 June 2015 (UTC)

Also, do you have an example that you could point to where you think this feature should be used? -- GB fan 13:35, 18 June 2015 (UTC)

That needs to be worked out. I think you will just see a normal Misplaced Pages page. I'm thinking of some magic template one can put so that the link appears red but there is still text in particular an edit history that can be accessed. This is useful since for the content in the some previous version needs to be merged into some other article but you don't want to be saying the readers there is content on a given article title. (I concede this feature can be confusing due to unfamiliarity.)

I don't have any particular concrete example; but I think one way to use the proposed feature is to give a new option in AfD; instead of deletion, you can make it a "red link"; this allows the editors to work out what to do with the page (in particular providing them access to the edit history), meantimes the link appears red so the readers don't think about following it. -- Taku (talk) 13:43, 18 June 2015 (UTC)

So we are not fixing any current problems, just making something available for some future possible occurrence? -- GB fan 14:22, 18 June 2015 (UTC)

Sounds a bit like Misplaced Pages:Pure wiki deletion system (which actually has quite a lot of benefits) — Martin (MSGJ · talk) 21:10, 19 June 2015 (UTC)

• I agree that a solution between delete and blank might be useful. In many cases losing the edit history is a Bad Thing, because, apart from anything else, attribution is broken. Also a not insignificant number of deletions should probably have been "stubify" or "redirect" - this would make those outcomes more retro-fittable. Thirdly the open preservation of history is more in keeping with the Wiki-way, especially now we have tools for deleting revisions that present legal problems. Fourthly knowing what has been deleted helps creators of new versions avoid the same mistakes. All the best: Rich Farmbrough, 22:48, 19 June 2015 (UTC).
  

DYK RFCs

There are two RFCs at Misplaced Pages talk:Did you know; one about changing the newness requirement and another about adding a guideline for reviewers to copy edit articles. Interested parties should participate. People who are active in New page patrol are also encouraged to participate. ~ ONUnicornproblem solving 00:05, 19 June 2015 (UTC)

Proposal for slight expansion of existing suppression criterion

There are regular occurrences where new editors to Misplaced Pages perform their first edit without realizing that their IP address will be shown in place of a username, and oversighters are periodically asked to suppress the IP information. There is a perception that the purpose of the current Oversight policy is only to protect registered users from accidental logged-out edits, and some oversighters will regularly decline such requests. This seems significantly problematic in that it is extremely easy to miss the "You are not logged in" flag at the top of the edit window (it is on a pale yellow background with black writing, and no differently coloured warning symbols). We know it's easy to miss because even experienced editors sometimes miss it. Attempts in the past to make this "notice" more obvious have been opposed by editors who deliberately choose to edit using their IP addresses, as well as others.

Therefore, I propose a slight expansion of the existing suppression criterion: request from new editor who can articulate that s/he did not realize that the IP address would be published in place of a username. We want to keep these new editors, not drive them away using rules that we do not apply to registered users; in fact, we want them to become registered users and keep editing. The fact that they have actually managed to find the way to request suppression indicates that they've quickly developed some useful Wikipedian skills. This is not a brand new oversight criterion, but an extension of an existing one to include not-yet-registered users/first time editors.

I've posted this here so that there can be discussion from the broader community, not just the small number of people who watch the Misplaced Pages:Oversight page. Risker (talk) 00:57, 19 June 2015 (UTC)

Discussion - Slight expansion of suppression criterion

• Support - No reason to withhold this from those who would be most likely to need it. ~ ONUnicornproblem solving 01:14, 19 June 2015 (UTC)
• Support - I think that it should only be used in obvious cases. Supdiop 01:39, 19 June 2015 (UTC)
• Support. Seems eminently reasonable considering the number of requests we get from alarmed people who didn't realize editing = sharing their IP with everyone forever. Humans are a species known for not RTFMing (well, them and giraffes. Giraffes are the worst at it), and when it comes to internet safety it's better for us to err on the side of protecting them despite this. A fluffernutter is a sandwich! (talk) 01:44, 19 June 2015 (UTC)
• Support per nom. -sche (talk) 02:18, 19 June 2015 (UTC)
• Dupport - this criterion is clearly part of crietrion 1 (Non-public personal information about a real individual); if it's drequently declined because oversighters don't think it counts, we should change the policy to make it clear it does count. עוד מישהו Od Mishehu 03:54, 19 June 2015 (UTC)
• I'll just comment on the basis that there are a significant number of logged out IPs which use IPs without disclosing the connection between themselves and a registered account. Maybe that ought be taken into account. The intent is generally good, however. NativeForeigner 05:10, 19 June 2015 (UTC)
• Oppose, and strong oppose unless add'tl procedures are implemented to verify requestors. As it is, I'm already concerned about the potential abuses of user/editor-hiding under criteria one; it enables possible cover-ups of attempts to evade scrutiny. To be honest, I think it is hard to claim that IP addresses of unregistered users meets the criteria even when read in the broadest context. LFaraone 05:17, 19 June 2015 (UTC)

  You sound like you've seen this happen in specific case(s), but I'm having trouble picturing what the misuse you're thinking of would be. Can you explain a little more how you see this being gameable in a way specific to people without (or claiming not to have) accounts, that wouldn't be already happening in cases where the user already has an account (we currently handle those cases as a matter of course, clearly covered under current OS policy). If it's all too beans-y to lay out in public, this kind of gaming is probably something Oversight-l should be aware of anyway, so maybe explain it there? A fluffernutter is a sandwich! (talk) 05:32, 19 June 2015 (UTC)

  I'd like to second Fluffernutter's request for some examples, either here or on the Oversight-L mailing list if it is eyes-only; I've been doing oversight since 2009, and the only time I've encountered someone "gaming the system" to get their IP suppressed was a longtime editor with a registered account; I've never seen a new/first-time editor do it. Risker (talk) 14:54, 19 June 2015 (UTC)

• Support I think the community is collectively pretty silly when it comes to how big a deal we make about IP Address privacy. There are some edge cases where there are legit reasons why someone really needs to keep it a secret, but for 99% of us it really doesn't matter. But since that doesn't seem to be changing, if we are going to make a big deal about it, being consistent is a good thing, and there is no reason to deny IP editors who request this after creating an account when we already do it for editors who accidentally edit while logged out. I would however clarify that this is something the new account holder should need to affirmatively request, and not something we should take it on ourselves to request on the behalf of others, as sometimes occurs to hide IPs accidentally logged out editors. Monty₈₄₅ 05:26, 19 June 2015 (UTC)
• Support, but only under limited circumstances. If an IP editor gets an account shortly after making one or a small number of IP edits, I would support suppressing their IP address. Or if an IP editor from a repressive country makes a "politically incorrect" edit and then realizes their IP address could be traced back to them, I would support a suppression (but also strongly urge the person to get an account). But if someone does a lot of IP editing and is unwilling to get an account, I'm not very sympathetic. — Richwales (no relation to Jimbo) 05:32, 19 June 2015 (UTC)
• Support As someone with access to privileged / personal information in the form of IP addresses with regards to the account creation team, I can understand all too well how both new users and seasoned users can feel concerned for their IP being listed for a number of reasons - dynamic IP associated with vandalism, simple privacy concerns, etc. - and just because they're new, I feel that that is an unfair reason to deny that method of recourse to an IP user. Assume good faith and help them out, provided they can articulate it in a way that makes sense from a reasonable perspective. RegistryKey 05:35, 19 June 2015 (UTC)
• Support per the proposer's own rationale. Thryduulf (talk) 10:01, 19 June 2015 (UTC)
• Comment I am interested to know what process would be in place to verify that a user requesting to suppress an IP address are in fact the same person. I think this is a great idea since accidental logged out contributions happen all the time but an even better (but albeit infinitely more complex) solution would be to merge an edit of an IP to a editor's account -- therefore correctly attributing the contribution. Mkdw 11:16, 19 June 2015 (UTC)

While I don't disagree with you, Mkdw, this is pretty far outside of the scope of oversighters. I'm not sure if the ability to merge contributions is operative yet, or whether or not it is possible to merge *individual* edits by an IP to an account (bearing in mind that most IP addresses are dynamic and often have been used by multiple editors over the course of years), but the merge-edits ability is not part of the Oversighter toolkit, nor is it likely to be added. Risker (talk) 12:37, 19 June 2015 (UTC)

@Risker: I agree it's outside the scope of oversight, but we're essentially asking oversight to fix a problem about attribution of contributions. It's one fix, but I feel like the real fix would be to resolve the merging of contributions, and then let oversight do what they do best in terms of confidentiality and protection. Mkdw 19:06, 20 June 2015 (UTC)

• Comment - would it not be more prudent to make the "you are not logged in" notice more noticeable? I would also argue that this should only be actioned if the IP can actually be traced to a username, rather than opening ourselves into suppressing any IP for any reason. — foxj 15:14, 19 June 2015 (UTC)

I tried to make the "not logged in" notice more visible in May 2014 and was soundly defeated in my efforts; in fact, I received almost no support, at least in part because some WMF staff were doing some kind of "experiment" and kept declining any proposals. Even if it is more "noticeable", we still have plenty of evidence that even experienced editors who should be much more aware of the meaning of editnotices fairly regularly miss them; logged-out editing by experienced users is probably the #2 reason for suppression (after personal info of minors) and has been since the day suppression was made available.

The requirement that someone have an account is kind of defeating the purpose of this proposal; I would suggest that our standardized response to these cases (the OTRS 'canned text') strongly urge the creation of an account with appropriate links. Step One should be addressing what the user believes is an unexpected breach of their privacy. This isn't trying to protect people who are gaming the system, it is aimed at the top unexpected personal information exposures that new, unregistered users are exposed to. Oversighters already have the tools required to say "no" to a request that appears to be gaming the system. Risker (talk) 15:32, 19 June 2015 (UTC)

• Support I have from time to time seen the need for this in running training sessions, where people have already edited as an ip and now want to get a user name. I'm sure there are other good cases. DGG ( talk ) 23:38, 22 June 2015 (UTC)
• Support as proposed. OSers can still use their judgement when someone is requesting for the wrong reasons or to evade scrutiny, etc., this just gives them a little more flexibility. Dennis Brown - 2¢ 10:57, 24 June 2015 (UTC)

4-day delay period for G13 deletions

It has been proposed that a delay period of 4 days be put in place for deletions under CSD G13. The discussion (RfC) is taking place at WT:CSD#4-day delay period for G13 deletions. 103.6.159.179 (talk) 06:54, 20 June 2015 (UTC)

Add RFA to TW dropdown list

There should be another option under TW named RFA on a user talk page. When you click on it, you can then type in a description for the user and Twinkle should automatically create an RFA subpage and put {{subst:RfA-nom|YOUR USERNAME}} on the user talk page. GeoffreyT2000 (talk) 18:17, 21 June 2015 (UTC)

You might want to suggest that on Misplaced Pages talk:Twinkle, the discussion forum for Twinkle. RfA nominations are sort of rare though, but I can see the benefit in light of the complaints about the RfA nomination process being difficult in terms of transclusions (which was discussed on Misplaced Pages talk:Requests for adminship just a few days ago). Jo-Jo Eumerus (talk) 19:17, 21 June 2015 (UTC)

I don't see how this would solve the transclusion issue, since creating an RfA page and transcluding it when finished are different processes/stages. Sam Walton (talk) 20:17, 21 June 2015 (UTC)

Yeah, my thoughts exactly. Why would we add such a rare utility? Not to mention it could potentially cause mayhem. Best, FoCuSandLeArN (talk) 20:31, 21 June 2015 (UTC)

• I can only see it being abused to such an extent that admins would have to clear up the mess - right GeoffreyT2000? Kudpung กุดผึ้ง (talk) 11:11, 22 June 2015 (UTC)

• Not used enough to justify the mess it would cause. The RFA template does need cleaning up, but this can be done on a separate page, where it isn't likely to cause more cleanup for admin. Dennis Brown - 2¢ 10:59, 24 June 2015 (UTC)

• Agree with Dennis Brown: doesn't really serve much point given the shockingly low number of RfAs. —Tom Morris (talk) 13:59, 24 June 2015 (UTC)

• We do need someone to overhaul the RfA submission process to make it simpler, it has become a barrier for some users and we might see an uptick if it weren't so daunting a process. –xeno 14:11, 24 June 2015 (UTC)

This, however, is not the solution; adding RFA to Twinkle will simply result in a glut of inappropriate nominations. Since such nominations often result in the retirement of the nominee when they are inevitably closed as failures, this is, however, a great way to help drive moderately proficient editors away from the project. Yunshui _水 14:14, 24 June 2015 (UTC)

Exactly. We need a separate page in the RFA space that the candidate can fill out, and allow noms to fill out, then press a single link and i will autotransclude once completed, but there is no reason for TW to be involved. As a matter of fact, most noms require 2 or 3 people to fill out something, so TW would be terrible for this. Dennis Brown - 2¢ 20:03, 24 June 2015 (UTC)

A new rule for users to make talk page entries when removing large chunks of text

So I'm proposing a WP rule of conduct that requires users to make an entry on talk pages when they remove large chunks of text of an article including a diff-link that shows all the removals.

Users being bold and removing large chunks of text might be what drives Misplaced Pages as it (often at least) helps with reference-, quality-, style-, and on-topic issues...however there's also a bad side to it:

• The current approach doesn't encourage users to improve parts of an article but instead plainly and with less effort simply remove parts of it. (I'd hope for a spirit of "improve, don't remove" in here...)
• When users enwatchlist an article they usually don't check through its whole history and instead (if anything) just inspect new edits/removals. But if there's a talk page entry with a handy link to the diff that shows all removed parts of a substantial cleanup it's more likely that they check it through. So for example users might rewrite contents of what was already part of the article earlier but was removed because for example there weren't sufficient references attached to it...even though those refs exist in plentitude with the former editor just being new or thinking its "common sense"/doesn't need to be referenced or alike.
• It allows for/encourages better communication/discussion on such changes. (For the person removing the content better explaining it; avoiding edit-warring; finding consensus; collaboratively identifying which parts should stay and in which form; accumulating material/sources on the removed parts later on; ...)

(The norm wouldn't "forbid" users to continue just plainly removing stuff but would encourage these kind of talk page entries for substantial removals)

--Fixuture (talk) 21:33, 21 June 2015 (UTC)

So you're proposing a new guideline? Eman235/talk 21:53, 21 June 2015 (UTC)

Exactly, yes. Sorry for not using the right term right away. --Fixuture (talk) 22:15, 21 June 2015 (UTC)

There are plenty of large removals that are very uncontroversial, and as such, this would end up adding a bunch of unproductive paperwork to slow down fixing problems. Particularly where the material removed as actively harmful, drawing more attention to the removed material from the talk page is counter productive. While getting the talk going instead of edit warring is good, just drawing the line at any substantial removal of content is way over inclusive. To an extent, WP:BRD already covers this well if people actually follow it. Monty₈₄₅ 15:09, 22 June 2015 (UTC)

the removals are already readily accessible in the article history, which shows the size of the change as well as the edit history. If you want to check for major unjustified removals of material (or unjustified major additions) all that you need do is scan down the list. When asked to look at an article I always do that, often before looking at the talk p. & sometimes even before looking at the article itself. The ability to easily analyze edit histories is the most important technical innovation of wiki software. DGG ( talk ) 23:24, 22 June 2015 (UTC)

Some editos might make 50 different tweaks and provide a rationale in each edit summary. I like that. Others might do exactly the same thing with a single edit, and an edit summary that says "some revisions" or similarly useless bit of drivel. It would be nice to reduce the latter type. Maybe a draft proposal could be written focussing on making revisions to no more than text below a single section or subsection heading? But anyone trying to write one has to deal with copy editing and reorganizing which would be quite a challenge and while I have an open mind I'm dubious it could be done without producing just more WP:CREEP NewsAndEventsGuy (talk) 16:36, 22 June 2015 (UTC)

I don't see this working so well for articles on religion, politics, aliens, magic, pseudoscience, or anything else that attracts conspiracy theorists. There's plenty of short-term users who add stuff that doesn't need any more justification to remove than an edit summary that contains at least two of the following explanations:

• "WP:NOR"
• "WP:UNDUE"
• "unsourced"
• "WP:GEVAL"
• "made up" / "hoax" / "WP:BOLLOCKS"
• "conspiracy theory"
• "edit made by sock of banned editor (name)"

The addition is technically made in good faith, and so wouldn't fall under a typical vandalism exception. Besides, WP:BRD already covers this -- if another editor disagrees with the edit, they revert it and ask for an explanation to justify the massive change. Ian.thomson (talk) 16:53, 22 June 2015 (UTC)

I think there's some misunderstanding of the intentions of this. It's not about explaining the removals but about making large removals accessible - mainly to users that join the page afterwards or don't check their watchlist well enough. In addition to that it also subtly encourages users to improve instead of just removing stuff. And it establishes a place for discussion.

Also @Monty845: I don't think huge removals are (or should be) done that often that this would effectively slow things down. As said, it's not really about explaining the removals which can be done in the edit-summaries but the other 3 points I listed there. So for example there could be a gadget / button that semi-automatically creates a talk page entry with a link to the diff or something. Concerning the paperwork that might ensue if people aren't ok with the change (and wouldn't have noticed the removal without the talk page entry anyway) I think more paperwork isn't necessarily bad as it might be appropiate/needed. It's also a just couterbalance to the efforts put forward by whoever wrote the removed parts.

But maybe BRD already covers all of this well enough...then (when putting aside the "new users to an article"-thing) I think it comes down to making the watchlist more useful (but that's yet another proposal). --Fixuture (talk) 18:26, 22 June 2015 (UTC)

But if your interested in removals, they are really easy to spot in the article history. Further, you still don't deal with the problem that sometimes we don't want to attract additional attention to the removal, such as with the removal of a BLP violation. So we shouldn't automate it, and without automating it, you are adding paperwork in the form of whatever your asking us to add to the talk page. Monty₈₄₅ 18:45, 22 June 2015 (UTC)

But close to noone actually looks up the article history while many do look up the talk page. Also most articles have really long histories which makes this rather unpractical.

If you don't want to attract additional attention to an edit you don't have to make the talk page entry. I wrote semi-automatically so you wouldn't have to use the button/whatever. It would just be "encouraged" to use it. There could even be exceptions explicitly listed on the guideline-page for which making such talk-page entries aren't recommended.

--Fixuture (talk) 18:58, 22 June 2015 (UTC)

But not when they're adding text? What a strange suggestion, considering that the general sense of policies is that the burden of proof on whether text should be added (or re-added) rests on the party that wants to add the text, not the party that wants to delete it. This proposal will just add one more layer of protection for Misplaced Pages cruft and original research-- problems which cannot be fixed by amount of re-writing--than there already is by the mere fact that use of the backspace key tends to generate hostile encounters with whoever added the ill-advised content in the first place. Please don't encourage editors to coddle shit--they'll do that anyway. Geogene (talk) 21:12, 22 June 2015 (UTC)

Well I guess it's clear now that it's not a guideline that would get much support here so further debating this seems rather pointless. However it's not superseding the burden of proof-ethos in here: things can be removed as before...having large removals at hand might just help editors to improve an article -> if the editor who removed it decides to semi-automatically add it to the talk page (which probably wouldn't be the case if it's some UFO-crap or alike; a good example of where it would be useful are list-entries). Also unsufficient references are not the only reason why people remove stuff in large chunks. For example many remove sections that they think of as too long. Now the article might however lack important parts of it. So maybe after a year another editor comes around and notes a lack of fundamental info in the article. In this case he might check the talk page and see a section about the removal. Now he knows why that essential info was removed and knows what to do better and most importantly: he now has something to start upon and make use of the old content by condensing and rewriting it. However that's just a one in a hundred examples.

Often times editors making such removals leave an entry on the talk page. But more often not. My suggestion is simply about encouraging it for reasonable cases.

--Fixuture (talk) 22:48, 22 June 2015 (UTC)

This seem like pointless additional rulemaking for something that's already very well covered by existing rules. You are removing obvious vandalism/copyvio/spam? Say so in an edit summary and move on. You are removing something less obvious, such as a dubious section tagged with {{cn}} which hasn’t been sourced for a long time? Remove it but with a carefully worded edit summary saying why. If challenged or reverted then take it to the talk page. Any bold edit can be challenged or reverted, I don't see why we need a special rule for removals which are among the easiest sorts of edits to check and assess.--JohnBlackburne_deeds 21:47, 22 June 2015 (UTC)

I think that anything amounting to common courtesy should not be a rule. If you see somebody assassinating text and don't understand why, ask, and mention that they could avoid such pestering if they explained themselves at the time of making any edit that could appear dodgy to an unacquainted observer. Jehochman 23:36, 22 June 2015 (UTC)

We don't need a guideline, it's already policy ("As long as any facts or ideas would belong in an encyclopedia, they should be retained in Misplaced Pages."). If the content removed is encyclopedic, it should be kept at the talk page for later reuse if it doesn't fits the current article, or directly moved to another article. I concur with Fixuture that talk pages are unwieldy for a decades-old project with the amount of users in this encyclopedia; the signal-to-noise ration is abysmal. Talk pages on the other hand are archived and structured under sections, so they're much better for keeping content that should potentially be reviewed at a later date. Diego (talk) 13:13, 23 June 2015 (UTC)

Topic Talk namespace

Pages in the Topic namespace should also have talk pages. The number for the Topic Talk namespace should be 2601, following the rule that the number for a talk namespace is always one higher than the number for the subject namespace and that subject namespaces always get even numbers and talk namespaces always get odd numbers. GeoffreyT2000 (talk) 03:00, 23 June 2015 (UTC)

Having a pair of namespaces is not a technical requirement, and there are a few pseudo-namespaces that do not have associated pairings, such as Special: - The full list at mw:Extension default namespaces contains a few more (though none of those other extension examples are installed on this wiki). Additionally, the Thread_talk: namespace was never really used in LQT, so we have a good reason to not create its equivalent with Topic_talk:. There is however at least one inconsistency that needs to be fixed with the namespace, and I previously filed that as phab:T72595, and discussed it again with Danny a few days ago, so it should be cleared up fairly soon. Hope that helps. Quiddity (WMF) (talk) 04:58, 23 June 2015 (UTC)

Group disambiguation

I've just spent a while trying to disambiguate an article (2015 NCAA Division I Outdoor Track and Field Championships), which uses the common names for United States Universities. Its a repetitive process in related articles. In that sphere, state names and city names are common shortened names for the universities that bear the common name of the larger agency. So whenever one is working on an NCAA article, or an article on American Universities in general, those common shortenings would be used. Can't we build a set of those disambiguations that can be placed in a hidden header to an article that refers all links in the article to the set of defined names for that group? American postal codes have defined lists of 2 letter codes, which would currently all turn into disambiguation pages. For a long set of names (probably copied from list documents in sources) with the specified two letter code built in, it would certainly save editors a lot of labor to have an automatic feature that, if invoked, checks against the specified 2 letter codes and resolves the proper state name and wikilink out of it. Trackinfo (talk) 00:51, 24 June 2015 (UTC)

I use WP:POPUPS along with the User:Anomie/linkclassifier script. The script highlights links to disambiguation pages so they can be easily identified, and popups lets you disambiguate the links with a couple of button clicks. It's not exactly what you're suggesting but it will probably make things faster for you. Ivanvector (talk) 01:06, 24 June 2015 (UTC)

Hi, Trackinfo! How about this?

• NCAAi-UAB (institution) -> University of Alabama at Birmingham
• NCAAt-VT (team) -> Virginia Tech Hokies
• NCAAf-ND (football) -> Notre Dame Fighting Irish football
• NCAAb-CLE (baseball) -> Clemson Tigers baseball
• NCAAs-FLG (softball) -> Florida Gators softball
• NCAAmb-DUK (men's basketball) -> Duke Blue Devils men's basketball
• NCAAwb-FS (women's basketball) -> Florida State Seminoles women's basketball

Those links could be replaced by bots. --NaBUru38 (talk) 20:05, 24 June 2015 (UTC)

• Misplaced Pages village pump
• Misplaced Pages proposals
• Pages automatically checked for accidental language links