Wikipedia:Village pump (all)

From Wikipedia, the free encyclopedia

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)

Village pump sections

To discuss existing and proposed policies

To discuss technical issues. For wiki software bug reports, use Phabricator

Dialog-information on.svg
To discuss new proposals that are not policy-related. See also: perennial proposals.

Idea lab
To discuss ideas before proposing them to the community and attempt to find solutions to issues

To post messages that do not fit into any other category

View all village pump sections at once

Other help and discussion locations
I want... Where to go using Wikipedia Help desk find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review resolving a specific article edit dispute or making a user conduct dispute complaint  Requests for comment comment on a specific article Article's talk page view other Wikimedia projects Wikimedia Meta-Wiki learn about citing Wikipedia in a bibliography Citing Wikipedia report sites that copy Wikipedia content Mirrors and forks ask questions or make comments Questions


Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).


RfC: Wikimedia referrer policy

Moved to Wikipedia:Village pump (policy)/RfC: Wikimedia referrer policy: Hi everyone. Because this discussion has become so lengthy (a good 226,000+ bytes), I've moved it to a subpage of the village pump to make the village pump a little more accessible. I apologize if any confusion was caused by this. Respectfully, Mz7 (talk) 03:55, 27 June 2017 (UTC)

 Relisted I have relisted the discussion, i.e. gave the discussion additional 30 days. Therefore, more participants would be welcome to comment there during the extended time. --George Ho (talk) 01:41, 30 June 2017 (UTC); added icon, 01:45, 30 June 2017 (UTC)

RfC: Should Wikibooks pages be displayed in search results

No consensus. Opinions are almost evenly split between keeping Wikibooks and removing it from the results. Some people also suggested moving it to the bottom of the search results if we keep it. Kaldari (talk) 20:20, 26 July 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Example of sister project search results for "Brazil"

Apparently, the previous RfC was inconclusive on this point (or at least didn't have enough participants to establish a convincing consensus).[1] Instead of arguing about it, let's just see if there is consensus one way or the other and settle the matter. Should Wikibooks pages be included as part of the sister project results in Wikipedia search results? (See screenshot for an example.) Kaldari (talk) 21:57, 23 June 2017 (UTC)

  • Oppose As the previous RfC determined, the content in Wikibooks isn't worthy of being linked here. The sole voice to support inclusion only hoped that seeing the results in Wikibooks would draw drive-by editors away from dumping their useless content at en-wp. Chris Troutman (talk) 07:49, 24 June 2017 (UTC)
  • Just noting that if Wikibooks is included I think it should be placed last. Users are trained to expect content in order of relevance, and in the Brazil example on the right, when they get to "World Stamp Catalogue" in the list of cross-project results, they are going to tune out, in spite of the fact that the Wikivoyage result lower down is very relevant to their search. Of the wikis included in cross-wiki search, Wikibooks content is probably least likely to be relevant, so it should go last. — This, that and the other (talk) 04:04, 26 June 2017 (UTC)
Question, This, that and the other: do you want Wikibooks included in or excluded from the search results? --George Ho (talk) 14:44, 26 June 2017 (UTC)
I don't feel strongly either way. — This, that and the other (talk) 02:20, 27 June 2017 (UTC)
  • Don't feel strongly either way, but favour inclusion over exclusion. Positioning might be a good thing to adapt, per TTO. —TheDJ (talkcontribs) 15:36, 28 June 2017 (UTC)
  • Weak oppose - There are other ways to cross-communicate and cross-contribute. However, saying that Wikibooks is "least likely to be relevant" implies that readers would not want to go to Wikibooks while using their own search terms. I like the "positioning" idea, but that depends on what the community wants and how the community would organize the projects in search results. Does the community want the results in this order: Wiktionary, Wikivoyage, Wikisource, and Wikiquote? (Note that I excluded Wikibooks.) Or does the community want the results organized in relevance order, like this: Brazil, Brazil, Brazil, Brazil, and World Stamp Catalogue?

    Meanwhile, why including Wikibooks if there's either apathy or not much enthusiasm toward the project Wikibooks? I appreciate the developers' work on improving the Foundation's search engine. However, if no one cares for Wikibooks, and almost no one is willing to complete the incomplete books, then don't include Wikibooks. There's no sense on including Wikibooks if the community doesn't care for it. Also, no sense on including it in contrast to the previous RfC discussion. Unless I see compassion and interest toward Wikibooks, which would prompt me into favoring the inclusion, I won't change my vote. George Ho (talk) 19:49, 28 June 2017 (UTC); changed vote, so see my new comment below. --George Ho (talk) 01:19, 11 July 2017 (UTC)

    – The below "support" votes say limit the query or put Wikibooks to last. If that's the case, then maybe excluding the results from Wikibooks would be a safest bet until I see a newer, fresher enthusiasm toward Wikibooks. Including Wikibooks for the sake of including it, even when limited, is not a good adequate reason to support the inclusion, especially when (as said above) the enthusiasm toward Wikibooks is (nearly) absent. Wikivoyage was limited to just title matches, but the consensus allows the inclusion of Wikivoyage for various reasons, like free travel advertising and driving travel-guide editing out of Wikipedia. I don't see a case here, especially since the consensus seems rarely interested in the project. --George Ho (talk) 01:19, 11 July 2017 (UTC)
  • Weak oppose. Content is lacking; there are just 66 complete (featured) books, and incomplete books don't seem particularly useful to readers wanting to learn a topic. Wikibooks is also just not all that important, judging by the lack of interest in this RfC. Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me
    17:13, 3 July 2017 (UTC)
  • Support inclusion of Wikibooks in search results, but make it last, or organize results by relevance to search term. It could be incredibly helpful if Wikibooks has an entire textbook on a subject. I personally use the cookbook, and find that is very helpful when I remember to use it rather than a general internet search. Wikibooks becomes more useful when it is more visible, and I don't see the sense in hiding it from our readers and editors. The Simple English Wikipedia should be included, too. Jack N. Stock (talk) 17:40, 3 July 2017 (UTC)
  • Comment - maybe make it so that Wikibooks is displayed only if the search string is matched in the page title. Wikibooks results tend to be mostly almost wholly irrelevant tangential mentions of the search string somewhere deep in a book page. DaßWölf 19:16, 6 July 2017 (UTC)
How would that help? E-textbooks are titled slightly differently. Type either "ESL" or "English as a second or foreign language" or "English", and you'll see partial matches in Wikibooks. Also, the titling varies, depending on b:Wikibooks:Naming policy. If you type in b:English, it redirects to "Subject:English language". Pinging Chris, This, that and the other, TheDJ, Jc86035, and Jack about this suggestion. --George Ho (talk) 19:43, 6 July 2017 (UTC)
Pinging Daß Wölf for response. Also, how would title matching help improve "chalupa" search results and include b:Cookbook:Chalupa? --George Ho (talk) 02:15, 11 July 2017 (UTC)
Well, it was an idea. The Wikibooks search engine is certainly lagging behind our other projects -- when I search for "chalupa" even on Wikibooks, the only result is b:False Friends of the Slavist/Russian-Polish. DaßWölf 23:25, 11 July 2017 (UTC)
  • Support, but some tweaking might be necessary to avoid pointing to books that are only tangentially related to the search query. --Yair rand (talk) 21:24, 9 July 2017 (UTC)
  • Support goal of this project from the start..Jimmy Wales: The birth of Wikipedia . --Moxy (talk) 01:35, 11 July 2017 (UTC)
    Jimbo Wales mentioned Wikibooks at the very end of the video, Moxy. It's been 14 years since its creation. Some books are completed, most of them Featured Books. By the way, I typed "risotto", and it doesn't include b:Cookbook:Risotto. --George Ho (talk) 02:04, 11 July 2017 (UTC)
So your suggesting we improve the search engine.....they are doing just that. Best to try to improve what we have over pusing it under the rug. We need to put our efforts in to problem solving. Your examples are a great starting point.--Moxy (talk) 02:11, 11 July 2017 (UTC)
b:Cookbook:Risotto could be a very helpful search result. Jack N. Stock (talk) 02:14, 11 July 2017 (UTC)
@George Ho: this seemed rather strange to me. When looking into it, I realized you cannot even find that cookbook on en.wikibooks itself. I think I have found the cause of that in phab:T170473TheDJ (talkcontribs) 20:37, 12 July 2017 (UTC)
Umm, TheDJ... you can configure advanced search, select whichever namespace(s) you want to search through, and... voila. :D --George Ho (talk) 21:31, 12 July 2017 (UTC)
Yes, but that's not how it's supposed to work. The default setting should normally search all content, not just main space. —TheDJ (talkcontribs) 22:31, 12 July 2017 (UTC)
  • Comment regarding purpose of this project from the beginning: Wikipedia actually came from Larry Sanger, the man who did most of the heavy lifting. We should ask Larry Sanger, the man who actually created Wikipedia. QuackGuru (talk) 01:47, 11 July 2017 (UTC)
    Hmm... At first QuackGuru, I thought the source was misleading because it doesn't mention Wikibooks and because it's about including the project in the search results. But then... I used Ctrl+F, typed "search", and found what it said: "More users meant more articles, and more articles meant more search engine results, which brought in even more users. It was a snowball effect that would send Wikipedia traffic – and content volume – into the stratosphere." A nifty quote, admittedly. Still, I wonder how it helps to persuade me into supporting the inclusion of Wikibooks. We already have live cross-wiki search results and included Wikiquote, Wiktionary, Wikivoyage, and Wikisource. --George Ho (talk) 02:04, 11 July 2017 (UTC)
    What is the quality of Wikibooks? What does the WMF say about adding it to the search results? What did QuackGuru mean? Others can decide for us? QuackGuru (talk) 02:16, 11 July 2017 (UTC)
    Well... I was thinking the third question, QuackGuru. I could answer other questions if I can. Sorry about the previous response; I was either confused or unsure whether your comment was an attempted humor. My apologies if you feel offended. George Ho (talk) 02:25, 11 July 2017 (UTC)
  • Support I've found Wikibooks to be helpful when learning programming languages, and think it's a valuable thing to link to as a side matter. No doubt the search results need some refining, but that can happen over time. Legoktm (talk) 01:23, 12 July 2017 (UTC)
  • Oppose -- aren't Wikibooks collections of Wikipedia articles to begin with? If so, there's no need. K.e.coffman (talk) 04:10, 12 July 2017 (UTC)
    • @K.e.coffman: No, you're thinking of Wikipedia Books. Wikibooks hosts original free content textbooks. Kaldari (talk) 20:42, 12 July 2017 (UTC)
    • @K.e.coffman: Some or many pages were imported from Wikipedia or Wikiversity, like b:Cookbook:Zippuli from Zippuli. --George Ho (talk) 23:52, 12 July 2017 (UTC)
        • It should be noted that content has gone in both directions, where I have personally moved Wikibook content to Wikipedia to start new articles here.... usually from misguided folks who simply didn't know where to put the content. Also, Wikiversity started on Wikibooks and was hosted on en.wikibooks for nearly five years before moving onto its own server. en.wikibooks also used to be multi-lingual and hosted every language version of Wikibooks at one point. Content has been moved to Commons, Meta, and even onto Wikia servers at various points of time... for better or worse. That from time to time content is also started on Wikipedia and gets moved to Wikibooks is more of a style issue and depends on the content, but Wikipedia is usually not the seed from which books are created. --Robert Horning (talk) 02:00, 20 July 2017 (UTC)
  • Comment--@Fram, Dlohcierekim, Beetstra, and WhatamIdoing:--Pinging participants of the prev. discussion.Please share your views on the regard.Thanks!Winged Blades Godric 10:54, 14 July 2017 (UTC)
  • Comment - As a long time admin at Wikibooks and somebody who can be asserted as a champion of the project, I am utterly dismayed at the lack of understanding of what the project even is based on many of the above comments. I might add that among the various users of Wikipedia that are clueless about what Wikibooks is about includes Jimmy Wales himself, even though he supported its creation based upon a policy discussion here on the Village Pump. The featured books would indeed be valuable to link in terms of search results, and as for the incomplete books.... those can and ought to be treated as if they are stubs no different or as complete as stub articles here on Wikipedia. On the other hand, I'd say that the skills necessary to flesh out and finish a book on Wikibooks are far more difficult than it is to flesh out a Wikipedia article (having done both... I can say this with experience). Particularly for featured books, they should definitely be linked in appropriate Wikipedia articles (and usually are I might add). That the project could use some loving from its bigger sister on Wikipedia is no doubt, but I'd also invite those who might not know about Wikibooks to any great extent to simply go over the the project and check it out... and help out if possible. It would be nice for the project to have a search engine display some results potentially to encourage more readers, but frankly I'm personally neutral either way. --Robert Horning (talk) 01:53, 20 July 2017 (UTC)
    • Just as a personal word, know that there are many people supporting the sister projects (I witness this at each event I attend). Unfortunately there seems to be a large contingent of (vocal) Wikipedians, who are against anything that isn't directly benefitting Wikipedia itself. Do not let your enthusiasm be withered by the sour grapes of Wikipedia. You can counter with the fact that Wikipedia sucks because in 17 years they only managed to write 5000 featured article, if that makes you feel better :) P.S. I'm anti- one of the sister projects myself, but that doesn't mean i don't respect the energy people put into it. —TheDJ (talkcontribs) 15:28, 24 July 2017 (UTC)
  • Oppose--Per above.No particular benefits.A hodge-podge project.Winged Blades Godric 10:25, 24 July 2017 (UTC)
  • Support per Robert Horning. Wikibooks is not that large it won't pollute Wikipedia searches. It will help a sister project. It will help users find free open source content the purpose of Wiki. -- GreenC 15:45, 24 July 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Post-closure discussion

Somehow, the task to suppress Wikibooks from search results is declined. Then a task to sort search results from sister projects is made. I don't know why "no consensus" should be interpreted as leaving the results as is. George Ho (talk) 23:37, 26 July 2017 (UTC)

Pinging Kaldari and DTankersley in case that they rather discuss at here than at Phabricator. --George Ho (talk) 00:11, 27 July 2017 (UTC)

@George Ho: I'm not involved in that decision. I was just trying to get some clarity on what the community's opinion was on the matter. Kaldari (talk) 00:20, 27 July 2017 (UTC)
Thanks, Kaldari. Would "no consensus" mean defaulting to excluding the results per the other discussion? --George Ho (talk) 00:24, 27 July 2017 (UTC)
@George Ho and Kaldari:--In absence of a concensus, status-quo shall prevail which shall be the exclusion of search results(as consequent of the prev. discussion).Winged Blades Godric 12:31, 27 July 2017 (UTC)
Until I get a response from Deb soon (well, not too soon), I thought about taking this to the admins' noticeboard. Thoughts, Godric and Kaldari? --George Ho (talk) 13:59, 27 July 2017 (UTC)
Let's wait for two/three days.Anyway, AN doesn't seem to be the apt place!Winged Blades Godric 14:02, 27 July 2017 (UTC)
Alternatively, Godric, I thought about re-proposal to exclude it. However, I worry that I might rephrase the same question. --George Ho (talk) 14:06, 27 July 2017 (UTC)
The community has wanted sister projects to be included in the search results since at least 2009—and has implemented it successfully on various wikis without censoring the projects that are displayed. The idea of this feature is that showing additional search results across projects will not only increase visibility into those other sister projects, but it could also increase discovery into more articles of interest and maybe even encourage additional contributions.
I made the decision to keep Wikibooks in the sister projects snippets on enwiki because (based on the two RfC's that have dealt with this issue) there was no consensus for either removing or keeping the project in the search results, as Kaldari pointed out when the second RfC was closed. However, in that closing statement, there is a recommendation to have Wikibooks displayed at the bottom of the sister project snippets, which I agreed with and created (T171803) to start that work effort and declined (T168697). DTankersley (WMF) (talk) 16:46, 27 July 2017 (UTC)
Thanks for the explanation, Deb. When is the best time to propose to exclude Wikibooks? --George Ho (talk) 19:54, 27 July 2017 (UTC)
I still think declining the task to suppress the results is a disregard to the "no consensus" to include Wikibooks, and creating a task to adjust the Wikibooks results as a compromise between both sides is an attempt to change the community's mind without further discussion. Isn't this wrong? George Ho (talk) 21:52, 27 July 2017 (UTC)
Suggestion: Letting things fade away is often helpful. Wait a couple of months by which time people will have a much better feeling for what is going on and what should happen. There is no need for this much discussion at this stage. Johnuniq (talk) 22:14, 27 July 2017 (UTC)

Don't blank but archive talk pages.

I know that "blanking" on Wikipedia is essentially the same as archiving (but without the search 🔍 results being shown). But it just seems useless to have a bot blank IP talk pages when archives can be created, it would seem better if IP addresses got archives than were being blanked. Sure "newbies" who use new IP's will be amazed by it, but by creating archives we will keep relevant discussions searchable, blanking helps no-one. -- (talk) 08:14, 9 July 2017 (UTC)

Do we really have a bot doing this? I was editing as an IP address since 2005 before recently creating this account and my previous IP address' pages were never blanked. It's possible that for some ranges with a header like school blocks those are regularly restored. On the other hand, most of those messages are user warnings, I'm not sure how useful it would be to have those among search results. Also, archives would be likely to be pruned by IP address editors because they would often not be related to that person's activity. If they were protected, this would be non-standard practice. —PaleoNeonate - 14:04, 9 July 2017 (UTC)
Well, I think IP talk pages should be archived properly, because it's much better than rooting through revision history, as well as recording the history of the IP in question for reference. Jjjjjjdddddd (talk) 05:29, 15 July 2017 (UTC)

Wikipedia:Naming conventions (West Bank)

Recently, there has been some confusion on whether or not the 7 July 2017 UNESCO decision to list the Old Town of Hebron, specifically the Cave of the Patriarchs, as a World Heritage Site, can or cannot be listed in the main list of World Heritage Sites in Israel. I have proposed that it be listed there, while other co-editors have disagreed with me. Wikipedia policies outlined in WP:Naming conventions (West Bank) do not specifically deal with the historical/geographical aspects of sites in the West Bank and which places were, in antiquity, called by different names. For example, the geographical place known as the "Land of Israel" is also a country historically defined as such in the Midrash and Mishnah (compiled in 189 CE). Saying that a place (Hebron) is in the Land of Canaan, Judea, Palestine, the Land of Israel, the Holy Land, or whatever, is NOT necessarily a political statement, as it is a historical statement. It just so happens that the Government of Israel calls the country by its historical name. Had the Wikipedia article, "World Heritage Sites in Israel," been titled "World Heritage Sites in the State of Israel," the resentment in having Hebron or the Cave of the Patriarchs listed there may have held up, insofar as that is disputed. But, historically, there is no dispute whatsoever about its historical connections to these geographical names. If UNESCO wanted to politicize something, as in the recent case involving Hebron (see: UNESCO puts Hebron on endangered heritage list, outraging Israel), does that mean that we, on Wikipedia, must also politicize the same thing? Of course not! Please clarify Wikipedia's policy in WP:Naming conventions (West Bank) with respect to the use of geographical names used in antiquity, and which are NOT meant to offend any ethnic group, per se, but only mention its historical context.Davidbena (talk) 22:16, 9 July 2017 (UTC)

I'm not sure what claim is being made here. The page World Heritage Sites in Israel references the modern country Israel, not the historical Land of Israel, as is true of all of the Lists of World Heritage Sites by country. The list for Russia, for example, would be quite different if it were based on the historical Russian Empire. Newimpartial (talk) 22:34, 9 July 2017 (UTC)
Based on Davidbena's argument, we would also list sites in Ireland, the United States (east of the Mississippi River), Canada, India, Pakistan, Bangladesh, South Africa, Zimbabwe, Australia and so on as being in the British Empire. Jack N. Stock (talk) 22:46, 9 July 2017 (UTC)
The one difference being that the countries you've mentioned, their borders have changed, but in Israel's case, the borders are the same, and the ancient geographical names are still being used today for these places. Why deny the obvious?Davidbena (talk) 22:52, 9 July 2017 (UTC)
"The borders are the same"? Are you trolling? If you think that Israel extends to, and beyond, the Litani river, you had better inform the government of Lebanon.
Lists of UNESCO World Heritage sites are clearly intended to be classified according to current political boundaries, not irridentist fantasies. Newimpartial (talk) 23:02, 9 July 2017 (UTC)
For the most part, the borders are indeed the same. But what you have said about Lebanon (although it has no bearing on the point that we wish to make here about ancient topography), Josephus mentions the land of Judea and Galilee under Herod's Dynasty extending to places that were, prior to 1967, held by Syria (i.e the Golan Heights), but this is a regression. What we are mainly concerned with here is NOT to delineate the modern-day border of Israel based on the old, but rather to simply recognize that old appellations for the country (Canaan/Palestine/Judea/Israel) would include within them Hebron, a thing admitted to even by the Palestinian Arabs. Therefore, the old appellations are still relevant. There is no such thing as "fantasy" when historians (whether Jewish or non-Jewish, Greek, Roman or otherwise) have given multiple names to the same country, and which "naming conventions" of old are still being used in academic literature, and often have more of a historical/geographical bearing on the ancient sites today, than do any political considerations.Davidbena (talk) 01:13, 10 July 2017 (UTC)
The "argument" you offer has exactly the same bearing on the Russian Empire. I have seen no rejoinder to that. The list pages for UNESCO sites only refer to current boundaries. Newimpartial (talk) 03:25, 10 July 2017 (UTC)
My friend, in a historical context, one may also mention the old names given for the Russian Empire. Here, in this case, however, where the Land of Israel is concerned, it has NEVER lost its appellation. Let's say that you were a geographer, or a historian, and you had mentioned the site of Hebron in its historical context (Canaan, Palestine, the Land of Israel, Judea or the Holy Land), it would still be relevant. It has absolutely nothing to do with modern-day disputes over the site's location, or whether or not Israel has sovereignty over the country known as the "West Bank," a matter currently given-over to dispute. If you feel that Hebron cannot be listed under the name "Israel" because of its political status or its implied connotation, that can be remedied by adding an asterisk after the word "Israel" on the page, World Heritage Sites in Israel, making it clear that the term Israel as used here is only a geographical location, one and the same as Palestine, Judea and Canaan, when used in a historical context. Otherwise, we run the risk of infringing upon WP:IMPARTIAL. To steer clear from partiality, in this case, let us add an asterisk with an explanation.Davidbena (talk) 04:19, 10 July 2017 (UTC)
So... you want us to put a star * next to a load of Jews? I'll get my coat... Only in death does duty end (talk) 07:55, 10 July 2017 (UTC)

The tag Category:World Heritage Sites in Israel was recently added to Cave of the Patriarchs. I removed it, and there is now a discussion fork on this topic underway at Talk:Cave of the Patriarchs#Categorisation with respect to status as World Heritage Site. Snuge purveyor (talk) 00:55, 14 July 2017 (UTC)

(Re-paste of argument). The use of the category, "World Heritage Sites in Israel," ought to be considered valid with respect to the Cave of the Patriarchs and/or the Old Town of Hebron for the simple reason that its being designated as a World Heritage Site is irrelevant of the country, seeing that the identification of the place itself is undisputed, although the UNESCO board members have opted to take a political stand by not calling the country of its location "Israel," using instead the word "Palestine." The name of the country is disputed merely on political grounds, but should not have any legal bearing on making mention of the country based on its accepted use and understanding, broadly construed. By "broadly construed" I mean that "Israel" and "Palestine" are one and the same country, the one word used in place of the other by Jews and by Arabs. Moreover, seeing that the final borders of the "State of Israel" with respect to the Palestinians have yet to be finalized, and by saying that Hebron is not in Israel proper, you have taken sides in this argument. Secondly, it was Great Britain who first decided to partition the country known as "Palestine" by dividing it into two sovereign regions, which never came to fruition. Considering the history of violence between Jews and Arabs in Palestine prior to 1948, Britain decided in 1936 to divide Palestine between the Jews and Arabs, as we learn in The Survey of Palestine under the British Mandate: 1920 - 1948, published by the British Mandate government printing office in Jerusalem in 1946, p. 166: "The commission, under Lord Peel, was appointed on 7 August 1936 to investigate the cause for the outbreak of the Arab rebellion and the way the Articles of the Mandate were being implemented. Between November 1936 and January 1937 the commission studied the situation in the country, and in June 1937 published its recommendation to abolish the Mandate and to divide the country between Arabs and Jews." (End Quote). In this matter, nothing has been resolved. Still, prior to these recommendations, the area of Hebron was called by Jews and Arabs "Palestine," as was it called in classical Hebrew literature dating back to the 2nd-century CE "the Land of Israel." It is not our place to politicize the situation, simply because UNESCO wishes to do so. By that logic, Hebron is a "no-place" - neither in Israel, nor in Palestine. It would be outrageous to actually say such a thing.Davidbena (talk) 02:49, 14 July 2017 (UTC)
Why is this discussion open both here and at AN? Seraphim System (talk) 02:52, 14 July 2017 (UTC)
Here, it is open because of the desired or expected outcome, namely, of bringing about either a "modification" or "clarification" in Wikipedia's stated policy with respect to naming conventions used in articles related to the Arab-Israeli conflict, especially since what has happened with UNESCO's decision to list the "Cave of the Patriarchs" in Palestine. There, on WP:AN, its purpose is to achieve agreement as to the use of a category called "World Heritage Sites in Israel.".Davidbena (talk) 03:42, 14 July 2017 (UTC)
There seems to be an element of forum shopping in having three active discussions. Nonetheless, let me repeat my comments from Talk:Cave of the Patriarchs: There are no World Heritage Sites in Biblical Israel or Mandate Palestine for the simple reason that all WHS have been designated since 1972. Machu Picchu is not a "World Heritage Site in the Inca Empire," because these two terms never overlapped in time. When we say "by country" we mean the present, without feeding the extralegal ambitions of either side in international disputes.--Carwil (talk) 12:38, 14 July 2017 (UTC)
Not only does this appear to be a case of forum shopping; there also seems to be an element of disingenuity by the editor originating these discussions, who advances different (even tangential) arguments in each of the three fora. I would suggest that, right now, there is no evident desire to revise the naming conventions for West Bank articles (which would require an eventual RfC anyway, rather than being resolved in any of the fora in which Davidbena has raised the question); those interested in the specific case ought to address the most active discussion, which seems to be at Talk:Cave of the Patriarchs#Categorisation with respect to status as World Heritage Site. For my response to the editor's bizarre argument that because borders have not been finalized that therefore the effective borders of the state of Israel are coterminous with the historical Land of Israel, and that any other view is "politicizing the situation", see the discussion at the aforementioned talk page. Newimpartial (talk) 13:12, 14 July 2017 (UTC)
To be fair to User:Davidbena, I was the one who opened the third discussion at Talk:Cave of the Patriarchs. I was aware of the discussion here, but unaware of the one at AN. However in contesting the categorisation I felt the article's talk page would be the proper venue. I apologise for adding to the confusion, and for not notifying this discussion immediately upon opening the thread. Snuge purveyor (talk) 17:26, 14 July 2017 (UTC)
I'll take some responsibility here too, actually. I should have opened a discussion on the talk page when I saw one beginning here (and later on AN). The talk page discussion should always happen first, before any forums are consulted/shopped. Newimpartial (talk) 23:48, 14 July 2017 (UTC)
  • PROPOSAL: Since, as far as historical topography is concerned, no juridical legitimacy or anything "binding" can be ascribed to UNESCO's decision of 7 July 2017 to mention the Old Town of Hebron (the Cave of the Patriarchs) as a World Heritage Site in Palestine, anymore than its decision earlier (in 2001) to mention the fortress Masada as a World Heritage Site in Israel, as you can see here: UNESCO World Heritage Sites in Israel, although both places are located in the so-called "West Bank" captured by Israel in 1967 (or what some hope to be the future State of Palestine). UNESCO's use of nomenclature in this most recent matter is based purely upon political motives. However, in terms of Wikipedia's recognition of this unresolved border dispute, or its leaning towards any one side in the Arab-Israeli conflict, let it be resolved that we, as neutral observers, steer clear from taking any political stand, but maintain a neutral point of view, in accordance with WP:NPOV and WP:IMPARTIAL. In consideration of which, it is here proposed that the following disclaimer be appended to the Wikipedia pages broadly construed with the Arab-Israeli conflict, namely, that an asterisk (*) be placed after the word "Israel" in the category known as "World Heritage Sites in Israel," with a reference to the effect that the proper name "Israel" is used here apolitically, that is, as a geographical/historical toponym, often used in the same sense that "Palestine" is used, and whose recognized borders may actually be disputed; or vice-versa, the proper name "Palestine" is used here apolitically, etc. This may bring some succor to this complex and troubling issue.Davidbena (talk) 13:35, 14 July 2017 (UTC)
This is a ridiculous proposal; clearly Wikipedia should maintain the category "World Heritage Sites in Israel" according to the same principles used for all of the other categories for World Heritage Sites by country, using currently accepted national borders. The adoption of so-called apolitical toponyms as a cover for irridentism would be a violation of WP:NPOV and would be no more appropriate than categories classifying World Heritage Sites by the historical borders of the Russian Empire or of Poland. Newimpartial (talk) 13:43, 14 July 2017 (UTC)
Quite the contrary, historical/geographical names such as "Canaan," the "Land of Israel," "Palestine," "Judea," - are all used for one and the same country, as is well-known. As for what you claim to be an "ulterior motive" of mine (or being, as you said "irredentist"), meaning to say that I am seeking to advocate the restoration of territory to my country (or what was formerly thought of as such), that notion is incorrect, as Israelis do not need the world's approval or disapproval, as G-d is our witness. Still, in your allegations about me, you have not assumed WP:Good Faith with me and with these rather sane proposals. But let others, here on Wikipdia, be my judge. Be well.Davidbena (talk) 14:00, 14 July 2017 (UTC)
Wikipedia does not confuse historical regions with contemporary countries; the categories for UNESCO sites by country use contemporary names and accepted borders and should do no other.
Your argument that "Israelis do not need the world's approval or disapproval, as G-d is our witness" to restore territory to your country "or what was formerly thought of as such" is precisely an irridentist argument. I did assume good faith when you began this discussion, Davidbena, but you exhausted that assumption long ago; you also seem not to hear what others are saying, in spite of several editors raising similar objections to your arguments as I have raised. Newimpartial (talk) 14:22, 14 July 2017 (UTC)
My friend, my only objective here is to resolve disputes, rather than create new ones. So far, you are the only one who has responded here, after submitting my proposals. Let's wait and see how the administrators will handle this issue.Davidbena (talk) 18:58, 15 July 2017 (UTC)
Right after we move the old city to world heritage sites in Judah. This whole notion that Israel is eternal and undividedly belonging to the Jewish is hopeless fringe POV (in terms of available scholarship on the subject which shows that the historical reality of "Jerusalem as a capital of Israel" was much more complex) - but forget about that, it is a fiction - fortunately this is not that complex or confusing, it is not a world heritage site in Israel, which cant mean anything more then a UNESCO designation. Seraphim System (talk) 19:04, 15 July 2017 (UTC)

SIMPLIFIED REVISED PROPOSAL: As per Wikipedia's recognition of the unresolved border dispute between Israelis and Palestinians, or its leaning towards any one side in the Arab-Israeli conflict, let it be resolved that we, as neutral observers, steer clear from taking any political stand, but maintain a neutral point of view, in accordance with WP:NPOV and WP:IMPARTIAL. In consideration of which, it is here proposed that the following disclaimer be appended to the Wikipedia pages broadly construed with the Arab-Israeli conflict, namely, that an asterisk (*) be placed after the word "Israel" in the category known as "World Heritage Sites in Israel," with a reference to the effect that the proper name "Israel" is used here apolitically, that is, as a geographical/historical toponym, often used in the same sense that "Palestine" is used, and whose recognized borders may actually be disputed; or vice-versa, the proper name "Palestine" is used here apolitically, etc. This may bring some succor to this complex and troubling issue.Davidbena (talk) 19:46, 15 July 2017 (UTC)

We can't just ignore UNESCO's own designation, which is what this category is about, for no reason other then editorial POV. Attempts to present this as WP:NPOV are ill-conceived, to say the least. If you actually read WP:NPOV it has nothing to do with the kind of reasoning that is being presented here, which has nothing to do with WP:RS and basically amounts to "if I don't like it it's not neutral". Editors are really getting tired of this. While there has been criticism that can be briefly noted in the article, it can't be categorized as a "World Heritage Site in Israel" because it's not one. Seraphim System (talk) 20:00, 15 July 2017 (UTC)
Friend, my contention is that you cannot call half of the country "Palestine" and half of the country "Israel," when both toponyms were used for ONE and THE SAME country. Besides, it was the British who first proposed dividing the country in 1937, and which proposal eventually led to a war between Jews and Arabs, each trying to gain as much control of the country as possible. As far as borders are concerned, nothing has been resolved between the two parties in this dispute ---- a dispute, mind you, which I call one of the great "political intrigues" of the 21st century! Have a good day (here, it's evening).Davidbena (talk) 20:10, 15 July 2017 (UTC)
This is now clearly not an issue about the World Heritage Site, but rather a general issue of nomenclature for the entire West Bank and Gaza. Revisiting the current consensus would require a well-formulated RfC, at the very least. Newimpartial (talk) 20:46, 15 July 2017 (UTC)
That has been the entire foundation of this argument from the beginning. It's only WP:NPOV, if the whole country is Israel. Why not treat the whole country as Palestine instead and include all World Heritage Sites in both categories? That is the only way this proposal could be construed as neutral, otherwise we have no choice but to adhere to UNESCO's own classifications without imposing editorial POV on them. This "half of the country" language is fringe POV―Israel is a modern state that was created through modern quasilegal processes, it has no other existence and never has (except as a mythological concept and a reality that all kinds of scholarship and evidence has shown was far removed from that mythology). What everyone else is talking about is Israel as a nation-state, not Shangri-La, and the recognized borders define the entire country. Even the partition is disputed by some, but views that "the whole country is Israel" or "the whole country is Palestine" are generally regarded as equivalently outside the mainstream. The mainstream view, reflected in UNESCO's decision, is that settlement activity beyond the agreed upon borders of Israel is illegal, and that Hebron is not within those boundaries. What you are proposing is a pretty unworkable position in terms of WP:NPOV. Seraphim System (talk) 20:53, 15 July 2017 (UTC)

Friends, @Newimpartial: and @Seraphim System:, editors have been "politicizing" the situation since who-knows-when. But why do you insist on politicizing the situation when it negates Wikipedia's stated policy? As you can see here, the Israeli objection to calling regions of the country by two names - the one "Palestine" and the other "Israel" - based on political motives, or more precisely, on the now defunct 1949 Armistice Agreement between Israel and Jordan, is what we are dealing with here. (For the 1949 Armistice Agreement between Israel and Jordan, see discussion here [Green Line]). Israelis view the entire country as one, but to give two separate names for two regions of the country is inherently wrong and is based on perpetuating an errant political stand taken by the British in 1937 who sought to divide the country. Moreover, the 1949 Armistice Agreement is no longer binding. While some might refuse to recognize Israel's de facto claims and hold of this territory, hoping to return to the pre-1967 border, the reality is such that the entire country is called "Israel" by the Israelis who live here. What's more, in a broader sense, the country's historical and geographical names have never changed, whether Palestine or the Land of Israel. So, I object to your claim that this discussion isn't about the "World Heritage Sites in Israel," as it still is. As for Wikipedia's naming conventions, the issue has not been satisfactorily addressed. My proposal is to leave the "West Bank" just as it is (since it only describes a geographical region that once divided positions held by Israel and Jordan), but to add a disclaimer there, stating to the effect that Wikipedia's use of the words "Palestine" and/or "Israel" are meant to be understood apolitically, and as purely geographical-historical terms used in antiquity. In this manner, we steer clear from politicizing the situation. Whenever editors mention "Israel" and their intent is to describe a political case involving the State of Israel, or the Government of Israel, the words "State of Israel" or "Government of Israel" should preface their editorial entry. Be well. Davidbena (talk) 06:26, 16 July 2017 (UTC)

Hebron is not recognized as part of Israel by the United States, and even if it were that would not help Israel or the United States. Palestine is considered a state now, and the only place this is heading is straight to the ICC, or possibly other courts, where all the wonderful youtube videos of people saying "the whole country is Israel" will be available for prosecutors in the future. Fact finding is not as difficult when people openly admit to genocidal intent on youtube, but no, it is Palestine and to say otherwise may satisfy several of the demanding requirements for genocide under the law, so why don't you stop and certainly do not drag Wikipedia into it. What I am trying to tell you is recent developments in genicide law have shown that courts may not require a state policy and may bot require as dramatic an actus reus as you imagine, if the intent requirement is met so certainly anyone who is stating an intent to destroy Palestine as a nation, which is what this amounts to, may not understand how serious what they are saying is. It isn't cute, it isn't benign, and it isnt WP:NPOV, the majority of scholarship including legal scholarship is in agreement that the settlements in Palestine, and Hebron, are illegal - Wikipedia is not a mouthpiece to legitimize fringe and hateful right wing POV, we dont tolerate it for the KKK, we dont tolerate it for neo-nazis and I certainly hope we dont tolerate it from the Israeli right either. Seraphim System (talk) 07:13, 16 July 2017 (UTC)
For example you just suggested that we rewrite the policy to state that "Palestine is a historical-geographic term used in antiquity" - I have literally seen people indeffed for much less then this when the comments could be construed as "anti-semitic" - so, what you are suggesting is that we use "State of Israel" for Israel, and Israel for Palestine? Are you actually being serious right now? - I don't mean this in a sarcastic way, I actually can not tell if you are seriously proposing this. Whatever your intentions are, and I will assume you are acting in good faith, it's disgraceful and sad that this discussion is being allowed to continue like this is a reasonable proposal that should be entertained. Seraphim System (talk) 07:57, 16 July 2017 (UTC)
Again, you're politicizing the situation, and you've taken-up a non-neutral position, in defiance of WP:NPOV and WP:IMPARTIAL, besides having stated that "Palestine is considered a state now", when, in fact, it is NOT a sovereign State. We all know that International Courts are not unassailable, so whoa! Hold back your horses and try to proceed in this case on neutral ground. Why use such harsh derogatory words as "genocidal intent"??? That's a clear regression from the topic here. And, yes, I see nothing wrong with using "Palestine is a historical-geographic term used in antiquity." Have you never read English translations of Al-Muqaddasi's description of Palestine, or Al-Tamimi, the physician's use of the word Palestine? Have you never read where the Mishnah (Kelim 1:6), compiled in 189 CE, mentions the "Land of Israel"? All are used in a pure historical-geographical context.Davidbena (talk) 08:22, 16 July 2017 (UTC)
You are wasting our time with strawman arguments at this point. I'm not "politicizing" anything, there is nothing political about what I'm saying beyond the general effect of the massive press attention it would attract, I am telling you my understanding of the current situation based on many different sources, including recent scholarship and law cases, is that this is a very serious matter. The majority of sources, far from accepting the position that "There is no Palestine" seem to be discussing which of a variety of war crimes and crimes against humanity would be the best legal fit for the facts of the occupation in the territories. This isn't my POV, it's my understanding of the situation based on a lot of sources, including the recent activity of the UN. You can think the UN is just being flippant with this most recent designation, but the proposal that Wikipedia should declare that UNESCO is a politically motivated anti-semitic agency and that we should alter our policies to favor your POV on this basis should probably be worth at least a trouting.Seraphim System (talk) 09:04, 16 July 2017 (UTC)
The decisions passed at the UN are often biased, as we all know. I have never once suggested that "there is no Palestine." For me, Palestine, the Land of Israel and Judea are one and the same country. Our duty as editors is to remain NEUTRAL in political disputes. My proposal will help ensure this, and will help remedy a problem that currently exists. There is nothing wrong with mentioning aspects of the political morass inherent in the Arab-Israeli conflict, but this can be done with civility, and without taking sides in this issue.Davidbena (talk) 09:17, 16 July 2017 (UTC)
So, you think you are neutral, and everyone else is biased? That because Palestine and Israel "are one and same country" for you anyone who disagrees with you must be biased, including not only the UN, but the experts at the UN (whose reputations and subject areas expertise carry far more independent gravitas then anything association with the UN adds to them) Seraphim System (talk) 09:37, 16 July 2017 (UTC)
Also, I think if someone posted the equally foolish proposal that we should rewrite our policies to clarify that Israel is actually the "Zionist entity" in order to avoid politicizing the situation and to fulfill our obligation to remain NEUTRAL, that they would at the very least be strongly admonished, so once again I am dismayed that this conduct is being normalized and tolerated. Seraphim System (talk) 10:28, 16 July 2017 (UTC)
No, you misunderstood me. I'm not saying that the country names of "Israel" and "Palestine" are not disputed on political grounds. They are! All it takes is for you to look at the objection of the Israeli Prime-Minister Benjamin Netanyahu at the UNESCO declaration, here or Netanyahu Protests UNESCO Hebron Decision with Scripture. This dispute revolves around how the government of Israel exercises de facto rule over these parts, and considers them an integral part of the multi-national and Jewish State of Israel, while the other side wishes to be given a sovereign state of their own. For this reason Netanyahu voiced his displeasure at the UNESCO declaration, where it, in turn, referred politically to the region as "Palestine." You see, the matter of how the country should be called is disputed on political grounds by two peoples (Jews and Arabs), with Israelis calling it Israel, including Hebron. We ought to steer clear from this dispute, and use the words apolitically. Moreover, as good editors who adhere to policy, we are expected to uphold Wikipedia's policies of WP:NPOV and WP:IMPARTIAL. This does not prevent us, of course, from talking about these heated political issues. It does prevent us from taking sides in this conflict. What we might feel personally about this issue should not come across in our editing.Davidbena (talk) 12:22, 16 July 2017 (UTC)
Could I direct attention to this recent comment: "This dispute revolves around how the government of Israel exercises de facto rule over these parts, and considers them an integral part of the multi-national and Jewish State of Israel" - that, my friends, is irridentism. This is as if we were to adopt WP:NPOV by treating all sites in Slovakia, and Croatia, and Transylvania as though they could also be equally be described as "as integral parts of the multi-national and Magyar state of Hungary". The perspective Davidbena is advocating here is purest marginal POV; leave it to this new editor to formulate an RfC if they choose, but WP has a well-established, neutral, and quite carefully-balanced consensus on this nomenclature AFAICT. Newimpartial (talk) 13:16, 16 July 2017 (UTC)
You stand to be corrected, User:Newimpartial. Irredentist is defined by Oxford Dictionary as: "1. A person advocating the restoration to their country of any territory formerly belonging to it." This is not true of me because Wikipedia cannot change the borders that already exist. I was merely showing what the Israeli Prime-Minister thinks of this issue, without advocating anything. Look again at my words above. Besides, in Jewish orthodox law, even if the country were governed completely by non-Jews, it does NOT change the halachic requirements associated with the land and a Jew's obligation to uphold those laws vis-à-vis the country. Who the country is, therefore, governed by is totally irrelevant here. Even internationaly recognized borders has no bearing whatsoever on what Jews will do within those same borders, since Jewish law stipulates special laws to be performed in the territorial boundaries once held by Jews returning from the Babylonian captivity, and which State boundaries are not necessarily the same today - some still in Lebanon, for example. The Halacha, nevertheless, remains the same, no matter who is in control of these territories. I have been trying my best to deal with a problematic issue, the issue of rampant POV editing, as in the case of the UNESCO declaration concerning Hebron and our being prevented from listing the site in Israel, on political grounds, rather than historical grounds, but you have not assumed "Good Faith" with me.Davidbena (talk) 13:41, 16 July 2017 (UTC)
The article on Israel does not refer to a territory governed by Jewish orthodox law, but to a legally-recognized state, which happens not to include Hebron. Your argument that this article should deal with "the Halacha" is hopelessly POV, and is in fact the topic of another article. When there are two perspectives on an issue (e.g., the limits of a state's sovereignty), one belonging to political factions within one small country and the other belonging to virtually the entire rest of the world, WP:NPOV and WP:BALANCE do not mean that those two perspectives should be presented in parallel, as I believe I have shown with the examples I have taken from Russia and Hungary. But by all means, formulate an RfC that all nomenclature governing Israel and Palestine should be "historical". In the mean time, your argument that "what country it is" doesn't apply to the listing of UNESCO world heritage sites by country is - well, entertaining. I'll give you that. Newimpartial (talk) 13:53, 16 July 2017 (UTC)
Again, you misunderstood me. My reference to Jewish Halacha was only to show to you that what we do as Jews, here in this country, is NOT affected by what Wikipedia writes here. This was said in order to stress to you that my motives are pure, and that my only interest is in correcting a wrong, namely, blatant POV editing, and non-neutral editing. That's all. And, yes, I'm aware of world public opinion (majority view by virtue of their sheer numbers), but in this country the majority opinion is reversed. That means WP:DUEWEIGHT does indeed apply, with consideration of both views. Your analogy is almost like saying that if the majority of Chinese (being the most populous nation on earth) adopts a two-child policy, the same policy should be adopted by all other nations. Of course, you can see the absurdity of such a statement. Be well.Davidbena (talk) 15:54, 16 July 2017 (UTC)
No, my argument is the equivalent to saying that UNESCO world heritage sites in Taiwan would not be listed in a category for World Heritage Sites in the People's Republic of China, unless such a categorization was established by reputable sources on the world stage. The fact that the majority of Chinese might regard Taiwan as part of China does not affect the way wikipedia would list such a site, because it does not affect the standing of Taiwanese territory in the domain of world public opinion. Newimpartial (talk) 17:14, 16 July 2017 (UTC)
But if Taiwan was held by China, it would. Both history and reality would dictate that fact. Therefore, your analogy of China and Israel is inaccurate, especially given the history where Jews and Arabs in this country, prior to 1948, were both called Palestinians. Golda Meir had a Palestinian passport. But, let us leave aside for a moment this argument. I can see that we are nearly the only ones debating this issue. You seem to be a wise man. What steps or measures would you take, here on Wikipedia, if you wanted to impress upon our general volunteer staff of co-editors to maintain a more neutral posture in our editing? Any suggestions?Davidbena (talk) 17:38, 16 July 2017 (UTC)

As I have suggested before: if you would like to propose a change to the nomenclature for locations in the West Bank and Gaza, you should formulate a Request for Consensus (RfC). Newimpartial (talk) 17:51, 16 July 2017 (UTC)

I hear you. If this venue closes with no results, I will do exactly that. Be well.Davidbena (talk) 18:11, 16 July 2017 (UTC)

I have posted a response to this conversation here. Snuge purveyor (talk) 21:09, 16 July 2017 (UTC)

Leaving aside the dubious merits of the proposed change, the tendency of Arab-Israeli and Israeli-Palestinian disputes to bring a whole host of historical baggage, documentation, and arguments into quotidian matters like categorization, nomenclature, and syntax on Wikipedia is exhausting and unproductive. There's no need to change a well-established consensus on what "in Israel" means. Supposing there were, understanding the Balfour Declaration, the Mandate period, and 1948 would not contribute to it. I would urge all parties to avoid litigating the conflict itself when wikipedia categories are the issue at hand.--Carwil (talk) 01:09, 17 July 2017 (UTC)
Carwil, just for the record, you mention "a well-established consensus on what 'in Israel' means," which is fine. I can also agree to that. But is there a well-established consensus on what "in Palestine" means? You see, the current category designation for the Cave of the Patriarchs is "World Heritage Sites in Palestine." If the words "in Israel" refer to the country, and they do, are you saying that "Palestine" refers to a different country? Here, it seems to me, that we're meddling with politics. All said and done, have a good day, and may you be given the wisdom to help solve some of these problems.Davidbena (talk) 01:27, 18 July 2017 (UTC)
A colleague on the Cave of the Patriarchs Talk-Page has suggested a good solution (see here), and that is to rename the category to read: List of World Heritage Sites in Disputed Territories. This seems to be the most compromising thing that we can do under the current circumstances. Anyway, my own suggestions have not gained much ground here. Be well.Davidbena (talk) 12:46, 17 July 2017 (UTC)

RECOMMENDATION: I earnestly urge those who are in a position to mend the current Wikipedia:Naming conventions (West Bank) that they define and present a more clear guideline as to the categorization scheme used in "by country" categories on Wikipedia. This modification is important, as it will help solve the issue now underway in the Talk-Page of Cave of the Patriarchs, see Categorisation. Can the word "Palestine" be used for territories now referred specifically to as the "West Bank"?Davidbena (talk) 12:08, 19 July 2017 (UTC)


Hello everyone 🙋🏻, I’d like to request some amendments to WP:SEEALSO. I’ve created a plethora of articles and while creating them I tend to follow this policy to the letter, however I do notice that other editors simply ignore this and immediately start adding links already in the article.

Sent from my Microsoft Lumia 950 XL with Microsoft Windows 10 Mobile 📱.


The articles I’ve created and / or greatly expanded always link appropriately upon publishing/expansion, I tend to use templates like “Main” and inline “Seealso” to make sure that interested readers know where to find related articles. This however doesn’t stop other editors from still (re-)adding them into the “See also” section, I’ve seen this not only on “my” articles (as in the ones I’ve created, don’t worry I'm not asserting ownership, it’s just a manner of speaking), but on countless of other articles that I either read or just make minor edits to, for example I’m reading an article about let's say German history and Herr Bismarck is mentioned several times and even appears in a “Main” template above some users will still add him into the “See also” section, now I’m an inclusionist and I really hate to revert edits that aren’t maleficent in nature, but I know of several “dedicated” (read: Over-active) editors who go out of their way to find every break of WP:SEEALSO, and remove the links. Now my proposals below will not only save those people countless of hours in what can basically be summed up as “useless edits for the sake of following WikiPolicy”, but I believe will greatly benefit the readers (you know? The people we all do this for).

" but I know of several “dedicated” (read: Over-active) editors who go out of their way to find every break of WP:SEEALSO, and remove the links." What a lot of garbage. Did you make your account yesterday just to enlighten everyone as to how properly using a see also section is inferior to having every link from an article repeated? Primergrey (talk) 16:00, 14 July 2017 (UTC)

My proposals

I'll get straight to the point, abolish the guideline that states that a repetition of links is bad 🙅🏻, especially on larger articles though I personally don't plan on ever adding these links if this proposal would go through we have to think of how some readers read Wikipedia, I personally when I have the time prefer to read full articles 🤓, heck I even click on links or add some references through Bing News if I find “Citation Needed” 🔎📔, reckon that most of y’all do something similar, but I would guess that since the majority of the readers never edit that they would probably only look for the things and sections they’re interested in (at that moment), maybe someone only needs to read the end of the article and never bothers to go through the rest but they’re still interested in related subjects, what then? Well under WP:SEEALSO nothing, the assumption is that everyone reads full articles.

In my current editing style I tend to (re-)add links from earlier in the article if it’s for the first time in a large section again, imagine that an article on sulfuric acids has a link 🔗 to let's say base, but the article itself is 90 kb’s long, abs it gets mentioned again as an important comparison very late in the article, not linking would be a major disservice to readers, and from most people I know that only read and never edit Wikipedia, many don’t even know that there are navigation templates 🗒 at the bottom, let alone categories. In fact from the people I’ve asked (NOT A SCIENTIFIC SAMPLE, THIS IS WP:OR BUT I’LL CITE FOR REFERENCE AS NO ACTUAL STATISTICS CAN BE GATHERED AT PRESENCE) they tend to not read further than the “See also” section, sure we should still be able to differentiate when a navigation template suffices, and wen the “See also” section is needed (in fact I started my first “over-active” account purely to make a navigational template).

I propose therefore that links MAY be repeated (especially in larger articles, which for me as a mobile editor are hard to navigate through as is) if relevancy is either direct to the subject, or is extremely comparable / antonomic to the subject. I mostly read and edit Wikipedia on a mobile device (my Microsoft Lumia 950 XL) and in order to even be able to see a template at the bottom (LET ALONE EDIT ONE) I am forced to click on “Desktop”, I don’t think (read: Speculation) that most readers would do this to look for related subjects. So far WP:SEEALSO is a bane on the mobile reading experience, and as none of Wikipedia’s developers seem to have any interest in improving either the mobile reading or editing experience changing this one policy would probably be easier and best for the readers.

--Nayman30 (talk) 11:35, 14 July 2017 (UTC)

No. Things are bad enough as they are, with the prohibition that links that appear in the article should not appear as a see also. Removing the prohibition would create a list magnet which will soon grow out of hand, the see also is for links that are tangentially related to the article, any link that is important enough to be indispensible tothe article should be fully integrated into the article.--KTo288 (talk) 18:46, 24 July 2017 (UTC)
Please don't use characters like 🙋📱🙅🤓🔎📔🔗🗒 - they show as little rectangles. Also, don't use curly quotes “”‘’ they are against WP:QUOTEMARKS. --Redrose64 🌹 (talk) 23:27, 24 July 2017 (UTC)

G11 deletions

I propose that, in the case of abandoned drafts and AFC submissions that would otherwise be subject to criterion G11 of the speedy deletion criteria and show promise of possibly becoming a full-fledged article, be instead moved to draftspace. I am aware of the refund policy, but it's better to not delete the page in the first place, because other people would more easily see the content and contribute if the page was not deleted. Jjjjjjdddddd (talk) 07:38, 15 July 2017 (UTC)

I think this is wishful thinking. I'd be very surprised if more than 0.1% of such drafts would get someone willing to clean it up. Jo-Jo Eumerus (talk, contributions) 10:29, 15 July 2017 (UTC)
Never mind that a number of G11 articles are copyright violations which frequently aren't caught at the time of G11-tagging. Jo-Jo Eumerus (talk, contributions) 10:30, 15 July 2017 (UTC)
Isn't this the whole purpose of draftspace though? To hold pages that have potential to be articles, while getting rid of copyvios and other obvious garbage on the spot? Jjjjjjdddddd (talk) 10:37, 15 July 2017 (UTC)
Nah, the scope of draft is unfinished articles and these which need review. Spam and copyvios don't belong there. Jo-Jo Eumerus (talk, contributions) 11:15, 15 July 2017 (UTC)
Anything which won't eventually become an article good enough to survive our deletion process doesn't belong in the draftspace. עוד מישהו Od Mishehu 19:31, 15 July 2017 (UTC)
I mean, when spam and copyvios are made in draftspace, they get deleted before they can make it into mainspace. They are vetted in draftspace. Jjjjjjdddddd (talk) 02:48, 16 July 2017 (UTC)
They aren't "vetted", someone has to vet them. That's the point - someone has to do all the vetting work. That manpower does not appear out of nowhere and your proposal means an even greater need for manpower.
There are lots of proposals that this or that class of pages should be cleaned up instead of being deleted. Such proposals almost always ignore that someone has to do the clean up work, that the proposal means more clean up work than there already is and offer no suggestion as to where this manpower can come from. Which is a real issue because a lot of processes here are backlogged including copyvio cleanup. This seems like yet another proposal in this pattern. Jo-Jo Eumerus (talk, contributions) 09:20, 22 July 2017 (UTC)
About the only area where there is no shortage of manpower is in the creation of pages which require cleanup. Especially now that the school summer hols have started (in England anyway), they have more time on their hands to write about the garage band that their mates are starting. --Redrose64 🌹 (talk) 09:37, 22 July 2017 (UTC)
The proposal is based on the false premise that deleting admins are unthinking bots who are too unintelligent to recognize an article with potential. How about producing an example of a problem before proposing a solution? Johnuniq (talk) 04:28, 16 July 2017 (UTC)
The policy defaults to (soft) deletion. I'm aware that admins know better, but I'm trying to change policy itself. Jjjjjjdddddd (talk) 05:02, 16 July 2017 (UTC)
How about producing an example of a problem before proposing a solution? Johnuniq (talk) 05:25, 16 July 2017 (UTC)
I already did propose the problem; that drafts deleted by G13 cannot be seen and improved by the average editor, and finding examples is impossible because of the problem. Jjjjjjdddddd (talk) 06:43, 16 July 2017 (UTC)
That sounds like a hypothetical problem. Can you point to a discussion showing that someone saw a page before deletion and believed that the page should be kept as an article? Johnuniq (talk) 07:54, 16 July 2017 (UTC)
Well, this happened a few hours ago: . I know an admin probably wouldn't delete it, given its state, but it shouldn't be in the policy to speedy it at all. Jjjjjjdddddd (talk) 08:14, 16 July 2017 (UTC)
Whoa, slow down, it sounds like you're suggesting that admins are capable of higher thought, that can't be right. ♠PMC(talk) 04:46, 16 July 2017 (UTC)


The discussion on this topic has been occurring in a low trafficked page regarding the implementation of ACTRIAL. The WMF, apparently, has agreed to go along with it for a short trial to gain statistical insight. Their reasoning is a six year old consensus on the matter. When it was brought up whether or not a new RfC should be done to reconfirm that consensus it was shot down as unnecessary. Due to the immense change in Wikipedia policy that would result in this trial I felt it was necessary to post this notice to a much more seen board. The fact that this is being done in relative secret, away from the knowledge of most people, is astonishing and should bother any Wikipedian who values community input on such wide reaching actions. Therefore, the notice. Please see a retooled Wikipedia:Autoconfirmed article creation trial for further details. --Majora (talk) 19:26, 15 July 2017 (UTC)

Anyone interested in responses to the above may like to see User talk:Jimbo Wales#WP:ACTRIAL. Johnuniq (talk) 07:43, 16 July 2017 (UTC)
  • Editors are invited to join the conversations at WT:NPPAFC and WP:ACTRIAL. I think the discussion at Jimbo talk has made it clear that this discussion is about a trial, and not any permanent change, which is often a misconception. Jimbo talk is probably the best place to continue having this conversation so it will be in one place, but I did want to make it clear here as well. TonyBallioni (talk) 00:58, 17 July 2017 (UTC)
  • The claims made above by Majora are based on a misunderstanding broadcast in several places by Majora who is not familiar with what ACTRIAL involves. There have been no secret discussions. Any current relevant discussions invovle development by the Wikimedia Foundation and are being held very openly in various high traffic places such as WT:NPR, WT:NPPAFC, the two projects that handle these issues. Any RfC have been published properly and at Cent.
Depending on the results of the experiment, the WMF will collaborate with the communit to make or improve the tools that have been requested. A decision to run the trial was reached by a consensus of a series of RfC including one of the largest RfC ever held on Wikipedia. Kudpung กุดผึ้ง (talk) 03:45, 17 July 2017 (UTC)
  • Once again, your constant assumptions on my understanding, my profession, my life, and everything about me is nothing more than pure arrogance. Once again you assume and cast aspersions when you know nothing about me. Casting aspersions left and right for much of the past 24 hours, constantly attempting to put me in a negative light. You know nothing. All I wanted to do was ensure that people know what was going on. That is it. Now I'll ask you to stop but I know that you won't and that's ok. You've been doing it all day and I doubt any request from me is going to change that. --Majora (talk) 03:59, 17 July 2017 (UTC)
  • A different response would have occured if you had posted a neutral message without the nudge-nudge adjectives that suggest the effort to salvage new pages patrol is a secret plot to subvert Wikipedia. How about acknowledging that there really is a gigantic problem with new pages, and that hoping someone else will fix it is no longer adequate. A neutral message would simply have linked to the ACTRIAL page with a brief explanation of what ACTRIAL is. Johnuniq (talk) 05:49, 17 July 2017 (UTC)
  • No body is casting aspersions on you! WP is not the optimum place for discourses in Gandhian ideology and One can't expect to throw stones and in return be welcomed with a shower of flowers!. On a seperate note, you would probably do well to understand that a single statement can be delivered in numerous ways each highlighting a different part of the issue.Your statement precisely highlighted something of the sort of--How dare, we some underground editors try to implement some shady deals on the entire wiki?!And now that you have fairly got an idea on how the issue appeals to your intended community(Sigh!) of Jimbo-talk-page-visitants, stop bellowing out-- All I wanted to do was ensure that people know what was going on. and the usual accompanying garble---arrogant, negative light....Winged Blades Godric 11:15, 17 July 2017 (UTC)
  • The notice wasn't neutrally worded, but that is water under the bridge as far as I am concerned. Marjora was concerned and posted here to let people know, and while I would have preferred to work them on the wording of the post, its fine and more people know where to look if they want information now, which is good. The Jimbo talk conversation makes it clear that the community is still behind this and has brought more voices to the conversation. There's plenty of work to be done going forward, so lets do it. TonyBallioni (talk) 16:40, 17 July 2017 (UTC)
  • Jimbo Wales has made a statement on his talk page regarding ACTRIAL. As I pointed out following it, I will also emphasize here that ACTRIAL is a community driven initiative that the WMF is assisting in implementing. TonyBallioni (talk) 17:20, 18 July 2017 (UTC)

Clarification proposal on user subpages closed as "opposed"

Wikipedia:User pages/RfC for stale drafts policy restructuring/B4 clarification is closed as failed/opposed. The rationale is too detailed, but one of rationales is worth quoting: "Abiding by rules is an integral part for the development of any community. But rules exist primarily and solely for the development and the greater good of the encycloepadia in general. Rules are not meant to be created just for the sake of it." Read further more. --George Ho (talk) 01:12, 17 July 2017 (UTC)

RfC on labelling page mover closures of RMs

An RfC has been opened on the labelling of closures of requested moves by pager movers at Wikipedia talk:Page mover#RfC: Labeling page mover closures. All are invited to participate. TonyBallioni (talk) 00:38, 18 July 2017 (UTC)

The first two lines of the lede, and the importance thereof.

Google Search often takes the first two lines of the lede for a Wikipedia article and puts them in search results. As a result, promoters of some articles try hard to get what they want in those two lines. Or they try to keep out negative information. If they can just push the bad stuff down a bit by adding some verbiage, it disappears from Google. I've hit this issue twice in COI editing situations.Is there policy on this? Should there be? Discuss. John Nagle (talk) 20:13, 18 July 2017 (UTC)

There absolutely should be. I've found too many times editors want to make sure labels that may be predominate in public opinion/media coverage but denied by a person or organization are stuffed into the lede sentences, claiming WP:UNDUE requires them to be there. WP:IMPARTIAL and other points in WP:NPOV tells us to use caution, and the first few sentences absolutely set a tone for the article. There should be not one single controversial statement in the first two or three sentences of the lede and should be left as uncontested facts. A second paragraph or later, sure, attributed statements that are controversial should be be included if they are critical to the person or organization's notability, but they don't need to be present in the first few lede sentences. --MASEM (t) 20:22, 18 July 2017 (UTC)
Ah. That problem. That's shown up at English Democrats, over how right-wing they are. The UK has several right-wing parties, who argue over who's "far-right". That's a tough call. Ideas?
The problem I was thinking of is when a company or person did something really bad, and they want it out of the first two sentences. We've had that at Michael Milken, the "junk bond king" of the 1980s, who has a paid editor trying to de-emphasize his time in the Federal pen. (There are at least four wealthy ex-cons on Wikipedia with paid editors, and those are just the ones that came up at WP:COIN). We had a huge problem with this at Banc De Binary a few years back. BdB turned out to be a total scam and is now out of business, and they had some really aggressive paid editors. John Nagle (talk) 18:37, 19 July 2017 (UTC)
(Sorry about accidentally deleting this whole page. Firefox crashed during editing and recovered, but that somehow turned a section edit into a whole page edit.John Nagle (talk) 19:01, 19 July 2017 (UTC))
Of course the lead sets the tone, I don't see how we can set a one size fits all restriction for the first two lines of the lead. That needs to be worked out between editors following our policies and guidelines. The idea that nothing positive or negative should go in the first two lines just won't work. Doug Weller talk 19:07, 19 July 2017 (UTC)
If an entity has been found by courts of law to have done something illegal or criminal, and that contributes greatly to their notability, then hiding that is pretty much impossible (eg Lee Harvey Oswald) and it would be silly to actually hide that in the lede sentences. But that then diverges into two cases.
  • If we have a case of an entity that has been found to have done something illegal/criminal, but that is not greatly contributing to their notability then it shouldn't be pushed into the lede. For example, a lede for Exxon Mobil should not call out the Exxon Valdez oil spill, though clearly this should be somewhere in the article.
  • The other case, and the one that is usually more problematic, is where an entity has been accused of a crime but either not found guilty or still awaiting trail - or more often have fallen afoul in the court of public opinion, and that fact contributes greatly to their notability. This is where the first sentences should be as impartial as possible, but then break into the attributed issues that are part of their notability. Eg, there are several articles on entities called out as white nationalists as an clearly-attributed label from the mass media/public opinion, but they have not self-identified that way. The fact they are widely seen in this light is definitely needed to be included in the lede, but it shouldn't displace objective, uncontestable facts like their actual profession/service, etc, and definitely not included in the first two-or-so lede sentences. (Consider the counter-case of a highly received entity like a famous movie star or scientist; we don't start those articles off with intense praise in the opening sentences, but do get to how they are generally recognized as the best in their field with attribution.)
I agree there's no common formula to use here, as there's so many divergent cases, but I think it is fair to have editors avoid any facts that are of any type of subjective nature until after a few sentences. It's not hiding material but setting a neutral tone for the article at the start. --MASEM (t) 19:59, 19 July 2017 (UTC)

Discussion about establishing a new speedy deletion criteria

There is currently a discussion underway about establishing a new criteria for speedy deletion for undeclared paid editing. Please consider participating. TonyBallioni (talk) 01:04, 19 July 2017 (UTC)

"New York" is now New York (state)

Following an extensive and well-attended discussion, the article on the state of New York, formerly at "New York", has been moved to New York (state); the title, "New York", is now a disambiguation page for the state, the city, and the many other meanings of the name. Since links to either the city or the state can come up in a wide array of editing contexts, please note this in making links going forward. Cheers! bd2412 T 23:10, 19 July 2017 (UTC)

Policy for use of poster art in film articles throughout Wikipedia

There are several hundred film articles at Wikipedia and Interwiki which use unaltered poster art to introduce film articles which are being promoted by this poster art. There is never an issue of this being fair use, though every use of such promotional poster art created for the purpose of promoting films still requires fair use discussion which seems repetitive and redundant. For hundreds of films, the poster art ends up being used without any impediment or copyvio. Should there be a standard template created or policy established which would identify unaltered poster art as not being a copyvio and avoid the vast amount of redundant time being spent by hundreds of editors justifying the use of promotional poster art for films on a film-by-film basis? JohnWickTwo (talk) 17:45, 20 July 2017 (UTC)

Generally, this should fall under an allowed non-free use per WP:NFCI#1 (using a film poster for identification, as it carries implicit understanding of the film's marketing and branding). There is also {{Film poster rationale}} that standardizes the use of a poster for the infobox. --MASEM (t) 17:51, 20 July 2017 (UTC)
@Masem: One example is on the current Akira Kurosawa article where an editor has deleted poster art. Could you glance at this to see if it was correct? JohnWickTwo (talk) 17:57, 20 July 2017 (UTC)
Yes, deletion there is correct. On an article about a director/producer, the film's poster is not appropriate, unless there is some sourced commentary to make the inclusion of the poster image relevant. It's not the case on Kurosawa, but an example would be if the director created the poster art himself, and that was the subject of some commentary, then that could be possibly justified. But just to show a film poster an example of one of his works is not appropriate at all if the poster is non-free. --MASEM (t) 18:19, 20 July 2017 (UTC)
@Masem: Thanks for your comment. After some effort I managed to find a still from the film on Italian Wikipedia here [2] which, if I understand your concern here, might solve the image issue on the Akira Kurosawa article. When I tried to substitute it from the Italian version, it did not seem to be recognized. Is there an chance I could ask you to substitute the Italian image here on Kurosawa, if its possible, in order for me to learn how to do it in the future? If I understood your comment above, then any other versions of the poster cannot be used, only the still image. JohnWickTwo (talk) 18:45, 20 July 2017 (UTC)
It's not just the poster, it's any non-free image from the film, just to illustrate a section about the film. The poster or the film still would satisfy normal fair use law, but we are more restrictive since we are a free content project. As such, we don't allow extraneous use of non-free images. See WP:NFCC for more details. --MASEM (t) 19:03, 20 July 2017 (UTC)


I'm having a crack at getting WP:MICROCON moved from proposed (where it's languished for a while, to say the least), and it's apparently good practice to post an announcement here. The link to the Talkpage section is here. Thanks, Bromley86 (talk) 21:23, 20 July 2017 (UTC)

Which way is preferred for categorizing templates: in template or in doc?

Category declaration, [[Category:Some-topic templates]], can placed in template or in its doc. They are both widely used, and the guideline or help page have no opinion about which way is preferred, until this week User:Redrose64 says declaration in doc is preferred.

Pros for declaring in template:

  1. Conceptually more direct. The template is categorized because its source contains the category declaration. Not because it contains a doc page which contains the category declaration.
  2. Consistent with the way main articles are categorized.
  3. The only way for pages without a doc page.

Pros for declaring in doc:

  1. Does not trigger re-render for pages transcluding the template.
  2. Separation of content edit and category edit. Protected templates can be re-categorized freely.

Golopotw (talk) 05:35, 22 July 2017 (UTC)

Please do not put the whole of the blame on me. My edit was a direct reaction to this edit by Golopotw (talk · contribs), which was shortly followed by this edit by the same person, which I amended similarly. Please note that neither Help:Category nor Help:Template are policy pages.
Yes, declaring in template is consistent with the way main articles are categorized - but articles don't have doc pages, so for articles this is the only way available. One thing that you have not mentioned is that templates are often protected, their doc pages rarely are. The advice to place the cat on the doc page is consistent with several other pages, such as: Template:Documentation#Best practice; Template:Documentation/preload (you need to view the page source for this one); Wikipedia:Template documentation#Categories and interwiki links; and indeed with Help:Template#Documentation. --Redrose64 🌹 (talk) 09:06, 22 July 2017 (UTC)
As far as I've been aware, declaring in doc (when a doc page exists) has been recommended practice for a decade or so. The "pros for declaring in doc" you describe are significant and measurable, while the "pros for declaring in template" are minor and in no way outweigh them. Anomie 12:38, 22 July 2017 (UTC)
The advantages of "declaring in doc" does not apply to low traffic templates, that is, most of the templates. Golopotw (talk) 23:25, 22 July 2017 (UTC)
I don't think anyone is saying that a doc page must be created if all it is going to contain is a category. However, obviously if a template is useful it should have a doc page, even if minimal. In that case, categories belong there. Johnuniq (talk) 01:51, 23 July 2017 (UTC)
If a template has a doc subpage, place categoories there - thesde categories are more a part of the template's documentation than of the template itself. If the template doesn't have a doc subpage, don't create it just for the category. עוד מישהו Od Mishehu 05:18, 23 July 2017 (UTC)

RfC: Red links in infoboxes

Opinions are needed on the following matter: Wikipedia talk:Manual of Style/Infoboxes#RfC: Red links in infoboxes. A WP:Permalink for it is here. Flyer22 Reborn (talk) 09:43, 22 July 2017 (UTC)

Dispute resolution RfC

Hello. You are invited to comment on this RfC, which seeks to reform certain aspects of Wikipedia's dispute resolution processes. Biblio (talk) 15:47, 23 July 2017 (UTC)

RFC pointer: CSD G13 to include all draft-space drafts

Watchers of this page may be interested in WT:CSD#Expand G13 to cover ALL old drafts. --Izno (talk) 12:10, 25 July 2017 (UTC)

Resolving conflicts between (and within) PERFNAV, FILMNAV, and PERFCAT

FYI: Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Categories, lists, and navigation templates#Resolving conflicts between (and within) PERFNAV, FILMNAV, and PERFCAT, which proposes mutually conforming clarification to these guidelines, in a centralized discussion.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  00:40, 28 July 2017 (UTC)


Advanced search proposal at phab

Please see phab T101087, arising from geman WP, called to my attention by User:CKoerner (WMF) in this diff. Jytdog (talk) 21:17, 13 July 2017 (UTC)

Any chance that phab T159403 can piggyback onto this? That's actually a feature that used to be supported, long before the creation of the "Knowledge Engine" group.
See mw:Talk:Wikimedia Discovery#Search prefix: for background. – wbm1058 (talk) 00:46, 14 July 2017 (UTC)
Not very likely, one is MediaWiki frontend work on top of existing functionality, the other search engine backend work. Mixing that usually tends to create more complexity than desirable. —TheDJ (talkcontribs) 19:52, 17 July 2017 (UTC)
We hope to start updating query parsing (to possibly include phab T159403) in a couple quarters, starting in Jan 2018. We are currently working hard on machine 'learning to rank' and other high priority items in our annual plan (program 1) and we will also be helping with the Structured Data on Commons project. DTankersley (WMF) (talk) 23:47, 20 July 2017 (UTC)
Learning to rank seems difficult for laymen to understand. Except for "practical usage by search engines" which sounds like a "secret sauce" that makes PageRank work better. In other words, this is the core of the "Knowledge Engine" that was going to "compete with Google".
So what I hear you saying is that you can't take a minute to tie your left shoe lace, which I pointed out to you is untied, because you're too busy working on a new high-tech compound material for shoe soles, and that project will take several months, after which you will look into whether tying laces is possible. wbm1058 (talk) 08:24, 21 July 2017 (UTC)
No. That is not what Deb said. You asked if a not-insubstantial amount of work could "piggyback" on the work of the team. Both TheDJ and Deb, the product manager who defines and is responsive for the team's priorities, said no. Both explained some reasoning on why we can't just add more work to an already burdened team with established priorities. If you would like to discuss the methodologies that the foundation uses to prioritize and develop software that is welcome, but that is not the intent of this discussion. Also, mentioning a defunct proposal of staff long gone from the foundation as some sort of ongoing conspiracy does not encourage civil conversation. Many folks at the foundation who lived through that time are not keen on discussing it. It was a dark time for many. Empathy and understanding are appreciated. CKoerner (WMF) (talk) 15:27, 21 July 2017 (UTC)
OK. Empathize with the idea that I'm in the dark about why that time was so dark (and content to leave it at that). Your mission is to "build the anonymous path of discovery to a trusted and relevant source of knowledge". That seems about like what the mission has been all along; I don't understand what's defunct and what's not. "Program 1" is "Make knowledge more easily discoverable." Again, my understanding is that's been the program since the department was formed. Goal 1 of that program is to "Maintain our search systems and improve the relevance of search results." I believe my request is compatible with goal 1. Outcome 1 is "Through incremental Discovery improvements, readers are better able to discover and search for content." I believe my request is for an incremental improvement. Objective 1: is "Implement advanced methodologies such as “learning to rank” machine learning techniques and signals to improve search result relevance across language Wikipedias." Of course, this is subjective, but "advanced learning methodologies" strikes me as significantly more than an incremental improvement. Incremental improvements can usually be made in a matter of days, or weeks at most, while "groundbreaking advances" (sorry if I'm hinting at old hyperboles) take months or years of hard work. Part of my perception that you are working on a "groundbreaking advance" is the difficulty I have in understanding what you're doing. Is phab T101087 a component of this "objective 1" (aka “learning to rank” machine learning)? I honestly don't know. wbm1058 (talk) 23:06, 21 July 2017 (UTC)
I find it difficult to follow your train of thought. If you are in the dark about something, why mention it with such familiarity? Otherwise, don't. Questions are welcomed and I can help clarify. Perhaps there's a miscommunication between the task that was mentioned at the beginning of this conversation and the goals and objectives of the Discovery team? I am genuinely confused. I think the salient question I derive from your reply is if the Discovery department is working on improving the existing advanced search features (T101087). We are not, Wikimedia Deutschland is leading that development. We are aware and continue to support them where we can. CKoerner (WMF) (talk) 15:23, 24 July 2017 (UTC)

Rendering problems

I routinely clean out some error tracking categories and recently have seen strange problems that I have not encountered before. I think it must have been caused by some MediaWiki change a few weeks ago. This report is too vague for action, but I'm posting to see if others have noticed similar issues.

A problem can occur when a page is rendered (that is, when MediaWiki generates the HTML for display, from the wikitext). The problem goes away when the page is purged so it can be overlooked and issues are hard to pin down.

Two problems have been reported:

  • T168040 Table of contents (TOC) missing sporadically without apparent reason
  • T170039 Pages display Lua error in mw.wikibase.entity.lua

I saw a new problem at Fear, Love & War#External links 24 hours ago (it is still there, but will disappear when someone purges the page). An error can be seen just above the categories:

Lua error in mw.title.lua at line 59: attempt to index local 'ns' (a nil value).

List of Get Smart episodes#Season 5: 1969–70 currently shows the same message. I haven't investigated but my guess is that mw.title.lua would not be throwing that error unless something bad happened within Scribunto, similar to the mw.wikibase.entity.lua problem above.

Two hours ago I encountered another puzzle at Tornado outbreak of April 9–11, 2009#April 10 event. Just before "Brief tornado touchdown", a {{convert}} error is shown. The wikitext at that point is {{convert|1|mi|km}} but the error message is what would occur if the value (1) were omitted, or if {{convert}} (no parameters) were used. The article is in Category:Convert errors but it was not there 24 hours ago. The only edit since May was by InternetArchiveBot at 22:22, 16 July 2017—that edit did not affect the convert in question.

Ping JohnBlackburne because he has also noticed issues while clearing articles from Category:Pages with script errors. Normally (a month ago), articles with script errors would have been empty because problems that occur are fixed. However, the mw.wikibase.entity.lua problem above means that currently 97 articles are listed, and that is after fixing several wikitext problems. Johnuniq (talk) 10:49, 17 July 2017 (UTC)

I’ve just had a look at it. It seems unrelated to the Wikidata problem. In Fear, Love & War the problem seems to be here in Module:Navbar with the title 'Killarmy' (from {{Killarmy}}):
	local title =, 'Template');
	# ...
	local talkpage = title.talkPageTitle and title.talkPageTitle.fullText or '';
And the 'title' object is pretty unremarkable. I can only guess the 'title' got corrupted. when those scripts ran. It happening twice is odd, but I can’t see any reason why – a code change, a wikidata dependence, or other obvious trigger. It could be something happened on the server once that tripped up mw.title.lua for a short time.--JohnBlackburnewordsdeeds 13:24, 17 July 2017 (UTC)
That category always seems to need a null edit when I stop by to visit it. Changes to templates often add a bunch of pages that, when the template problem is reverted, need to be flushed from the error category. I wonder if we could ask a bot to null-edit all of the (non-sandbox, non-testpages) pages in that category once or twice a day. – Jonesey95 (talk) 14:17, 17 July 2017 (UTC)
My report about mw.title.lua has to be a bug in the underlying system. I haven't fully examined the situation, but it seems impossible to me that the red error could be generated by anything a template or module could do. It would be better to record any examples of weirdness that have been noticed, and later plan workarounds if the problem cannot be resolved. Purging the pages I mentioned just makes it hard for others to see the problem. Johnuniq (talk) 01:14, 18 July 2017 (UTC)

The heading of this thread is pretty ironic, considering that the designers of the Module:convert are deliberately abusing a parser function to cause "Rendering problems" and potentially triggering 3 different views (preview, cached rendering, preview with error) of the same page.

As far as scribunto libraries are concerned. mw.title and mw.html are some of the worst of the crop. They don't careful protect themselves from errors caused by calling modules by catching the invalid use and outputting better errors. The same applies to module:convert which should catch that error and prevent it from ever reaching a page, and output a much better error.Apart from the wikibase problem which is certainly a software issue, it is quite easy to replicate the "mw.title" error noted above :

local ns =[buu]

Module:convert uses a lot of related modules, so any one of them could at some point have facilitated the error above. Generally speaking, mediawiki needs a better error reporting tool that doesn't rely on crazy hacks like dumping errors to pages or using categories, perhaps Extension:Pickle or a related extension could one day facilitate this.

It won't however, fix bad programming practices. — Preceding unsigned comment added by (talk) 18:00, 21 July 2017 (UTC)

If you have positive suggestions for error reporting (rather than just complaining that existing methods are "crazy hacks"), feel free to suggest them in Phabricator. I suspect the title error described above (as opposed to your GIGO complaint) may be due to T166348, which is in the process of being fixed. The missing TOC error described above is also in the process of being fixed. Anomie 12:23, 22 July 2017 (UTC)
By the way, searching for "Lua error in mw.title.lua at line 59" in Special:Search or Google finds plenty of examples, and the Google cache shows them. Wang Maolin (last edited on 18 March 2017) is showing the error. Johnuniq (talk) 01:28, 23 July 2017 (UTC)
It seems that the error caused by the code above is intermittent and seems to show up whenever an unrelated uncaught script error occurs. It would probably happen with other unguarded related code even if that line didn't trigger it.
Improvement for the current error reporting seems to be already captured in phabricator. One approach might be to get rid of tracking categories, and red errors everywhere, and instead surface them using a centralized Linter like mechanism in mediawiki core.
In fact, it is already demonstrably superior to the tracking category, compare Special:LintErrors/self-closed-tag vs Category:Pages_using_invalid_self-closed_HTML_tags , and see T163430. At the time of this writing the former shows more errors, has a namespace selector, seems to be faster to update, can facilitate the collation of errors, identification of the template causing many errors, and unlike mediawiki core has a specific API for it.
There are also many related tasks that address a proper warning system phab:T141970, phab:T160102#3213366. Temporarily logging past errors is also way more useful than randomly popping them up in various pages. That is also partly discussed in mw:Help:Pickle/Test_log, and perhaps addressed by the pickle extension as a whole as far as lua is concerned. There are also plenty of phabricator tasks for pickle itself.
On wiki, wrapping the offending line in a xpcall would probably mitigate this problem until it is fixed server side. Such defensive programming is generally a good practice for data retrieved from a separate database. For specific scenarios like these intermittent errors, a targeted approach would be more useful than senselessly playing wack a mole, as some editors seem to be doing exactly because of the legacy error reporting system. (talk) 07:58, 23 July 2017 (UTC)
The error cannot be caught by a Lua module. Johnuniq (talk) 09:54, 23 July 2017 (UTC)
Scribunto !== Lua . You may also be confusing templates with a genuine programming language (LUA). It is fact that wrapping the entry point of the module (and/ or all functions within all modules) should still catch it, and if that doesn't work, then that truly merits a separate bug report. Looking at this error throughout various wikis, all of them seemed to make an unguarded call. In a worse case scenario the module could simply do string matching before outputting anything similar to the {{#iferror parser function. Someone mentioned a similar thing years ago (and was ignored) related to the tester (Module_talk:UnitTests#Add_a_value_to_nowiki_to_show_the_wikitext_only_if_the_actual_result_does_not_contain_a_script_error). If even that can't be done, then it is a pretty serious software issue.
Lua can even report the exact runtime variables at the point it errored, which would certainly help in tracking that and other errors without guessing. That's a fact, and something used in several other non-mediawiki platforms. However, scribunto developers deliberately neutered those powerful error reporting tools for security reasons, or due to lack of interest / resources to provide wrappers for it. (talk) 11:16, 23 July 2017 (UTC)

Apparently a new type of error started showing up (with a new deployment), "Lua error in mw.wikibase.entity.lua at line 37: data.schemaVersion must be a number, got nil instead.". It also seems to be intermittent, and probably as easily caught as the mw.title one, e.g. testwiki:module_talk:Errorcatch.15:59, 24 July 2017 (UTC)

That is visible in the infobox at Zürich. It appears the reason for the new error message is that per T170039, a release with more precise messages has been released to investigate what's going on. It also appears another release soon may fix the problem. By the way, I just purged the list of articles with script errors, so what is now shows will be new stuff. Johnuniq (talk) 23:53, 24 July 2017 (UTC)
I just purged the list again. It had 7 entries after my previous purge. That had grown to 31 entries a couple of minutes ago before this purge. It now has 6 entries. That's about four articles per hour being added. Johnuniq (talk) 05:59, 25 July 2017 (UTC)
88 entries total now; I'll start purging them soon. Just under 5 per hour. Johnuniq (talk) 23:12, 25 July 2017 (UTC)
Hopefully people don't take this the wrong way, but this is "insanity". As defined by Doctor Albert Einstein, insanity doing the same thing over and over again and expecting different results. No matter how many times these pages are purged, they'll keep returning until mediawiki developers fix the server software.
At the very least it makes more sense to use a bot and the search api to periodically purge all these pages rather than doing it manually if editors aren't interested in improving error checking in those modules.
Alternatively, the extensions could temporarily (or permanently) use the same solution adopted for which seems to basically be to reduce the need to waste time dealing with this until it is solved. — Preceding unsigned comment added by (talkcontribs) 20:55, 26 July 2017 (UTC)
The category is used to remove errors from articles but it is unusable when it contains mostly false positives. If you browse recent posts at T170039 you will see editors from at least two other Wikipedias asking for methods to clear the category so they can find articles that need to be fixed. Also, once the problem is fixed, it can take weeks or even months for a category like this to clean itself—the pages need to be purged sooner or later. I am using a home-grown Python script and am not "doing it manually". I don't know if you are reading anything here, but modules cannot catch these errors. Johnuniq (talk) 00:57, 27 July 2017 (UTC)

Save changes buttons - accessibility

At some point between 23:23 and 23:34, 18 July 2017 (UTC), the edit interface has changed. Is it Thursday already? I notice that the buttons at the bottom (Save changes, etc.) have changed, are bigger and less readable: there's a contrast problem. Accessibility is something to be careful of. --Redrose64 🌹 (talk) 23:57, 18 July 2017 (UTC)

+1 I am not entirely sure what was wrong with the old version either, and it is certainly not yet Thursday. ^_^ Double sharp (talk) 00:00, 19 July 2017 (UTC)
They've been dutifully warning us of the buttons' fuglification for weeks, including that there's no practical way to repair them with user css. I'd have complained earlier, but of course it would've done no good. —Cryptic 00:07, 19 July 2017 (UTC)
Redrose, accessibility for people with low vision is one of the main points. The contrast has been dutifully checked (several times by now, at least for Vector) and easily clears all of the standards.
Note that this is more than an aesthetic change, so a few old editing scripts may also break. See mw:Contributors/Projects/Accessible editing buttons for information on how to fix anything that's broken.
(P.S. It's a config change, which means it can descend on you on any day of the week. ;-) So far, it's only reached the Wikipedias and Meta. Other wikis will happen in a couple of weeks.) Whatamidoing (WMF) (talk) 01:20, 19 July 2017 (UTC)
They look perfectly fine to me. I don't see where any potential readability issues would come from even for those with eyesight issues. They're compliant. Amaury (talk | contribs) 01:27, 19 July 2017 (UTC)
Whatamidoing (WMF), could you please explain how making various interface elements exceedingly disproportional (like buttons being about 4 times bigger than hyperlinks) improves accessibility? If you care so much about these people (by the way, what is their fraction among the editors?), then maybe it would be better to make a special "accessible" style for them, with everything large and contrast? I can tell about my own experience with "accessibility": when I need to use a website with small fonts, I just press Ctrl++, and my browser magnifies everything proportionally. If I would do that with the current WP design, these ugly buttons will take half of the screen, actually decreasing the usability. And I also wonder very much: how artificially limiting the summary line to 80% of the width is supposed to help people with low vision? — Mikhail Ryazanov (talk) 09:46, 19 July 2017 (UTC)
The intention, at least as stated in prior posts here, was to improve accessibility for readers using the desktop version on mobile devices. Never mind that this affects editors, not readers, and significantly degrades the desktop version on the desktop. —Cryptic 16:50, 19 July 2017 (UTC)
Not just mobile devices. Touch devices. This includes things like Windows Surface laptops for instance. —TheDJ (talkcontribs) 18:49, 19 July 2017 (UTC)
I thought that all modern OSs have user preferences for sizes and colors, such that any interface built from standard elements will have a comfortable look and feel. Am I wrong? I do not have much experience with touch devices (believing that text editing on a keyboardless device is a bad idea), but how can it be that these users can tap hyperlinks, but cannot tap standard buttons (which are usually about twice bigger)? And again, how reducing the summary width to 80% helps them? Especially considering the problems (discussed below) with its wrong alignment and an overlapping counter. — Mikhail Ryazanov (talk) 22:57, 19 July 2017 (UTC)
Web pages cannot access OS user preferences (it would be a leak of privacy if they could), nor directly use the user interface elements provided by the OS (they use the user interface elements provided by the web browser, which may or may not resemble those natively provided by the OS). isaacl (talk) 23:54, 19 July 2017 (UTC)
Web pages do not need to access OS user preferences because the browser itself should. In any case, browsers have user preferences for default colors, fonts, and overall magnification. — Mikhail Ryazanov (talk) 04:42, 20 July 2017 (UTC)
Sure, the browser could retrieve and expose this data to web servers, but I don't believe there's currently a mechanism for web servers to retrieve this info from web browsers, and it would still be a potential privacy issue. There are defaults for colours and fonts, but not size information for user interface elements. Most users, though, appreciate greater variety in the web sites they visit, and would not want all of them to use only the default background and text colour. Even just considering the implications on a single site, visual elements such as side bars would blend into the main text flow without a distinguishing background colour. isaacl (talk) 18:31, 21 July 2017 (UTC)
Browser do not need to expose these preferences to web servers, they use them locally for rendering pages. If you have no idea how it works, please see [3], [4], [5], [6].
A variety in the web sites is fine, but kind of interferes with the accessibility, which was the declared reason for the changes we discuss here. And I still assert that neglecting user's setting actually does not "improve accessibility". — Mikhail Ryazanov (talk) 10:02, 24 July 2017 (UTC)
Thanks; I am familiar with how the default settings work. I was only responding to your original post regarding using the OS user preferences. Sure, it's possible to go back to the late 1990s look, with the web site using only defaults, and a single flow of content such as seen on many sites that are designed with mobile devices in mind as the primary viewing experience. But it's unlikely for any highly popular site such as Wikipedia to drop all styling, and in particular judicious use of background and foreground colours. For better or worse, most readers today expect both accessibility features to be respected and an engaging site design. Specifically regarding buttons: the key problem is that browsers don't offer good customization options to tailor their accessibility, and there is uneven support in adjusting their appearance via CSS. Accordingly sites will substitute their own button elements for the default ones. It's not a perfect solution, but it's what we have available. isaacl (talk) 16:29, 24 July 2017 (UTC)
Mikhail, the use of 80% width on the edit summary box has nothing to do with this change. It's been like that for years (possibly since the creation of the MonoBook skin). However, the team can change it, and if people don't like the result, then they can complain. Whatamidoing (WMF) (talk) 17:37, 24 July 2017 (UTC)
Yes, they have tried their best to impede user's CSS. I have added to my common.js some code to remove the offending classes:
// remove ugly styles from buttons:
// and checkboxes:
// remove inflated field margins:
This seems to help against the most evil stuff, at least so far... — Mikhail Ryazanov (talk) 09:31, 19 July 2017 (UTC)
What a relief! The awful new buttons couldn't be styled by CSS (by me at any rate), but this returns them to a usable legible state. And fixes my widgets too. Lithopsian (talk) 14:02, 19 July 2017 (UTC)
I regret that I have but one thanks button to click for this edit. A css solution would be better - removing the classes in javascript still shows the irritatingly immense buttons briefly until the page finishes loading - but this is still a huge improvement. —Cryptic 16:50, 19 July 2017 (UTC)
@Cryptic: Since they are classes, you can redefine them using user CSS. For example, I have changed the color. If you want to have boring grey buttons again, you can use
.oo-ui-buttonElement-button {
border: 1px solid black !important; 
background-image: linear-gradient(to bottom,#eee,#eee 100%) !important;
border-radius: 0 !important;
padding: 0.5rem !important;
transition: none !important;
for example. Regards SoWhy 12:29, 20 July 2017 (UTC)
Is there a CSS style that is just "look like a button, like all the other buttons - eg 'Go' and 'Search' in Monobook"? Mitch Ames (talk) 11:28, 24 July 2017 (UTC)
I just took a screenshot at File:Save_dialog_Wiki.jpg (FF 52.0.2, Windows desktop, Vector skin). Maybe that helps a bit to find remaining problems and script incompatibilites (obviously the buttons need fixing, and the "edit summary" field is cut by 1-2 pixels on the left side). GermanJoe (talk) 02:45, 19 July 2017 (UTC)
wikEd is making it's own style modifications. It will need an update. —TheDJ (talkcontribs) 07:17, 19 July 2017 (UTC)
I think they're awful – unattractive and huge, but I am more concerned with the fact that I no longer have any ability to leave an edit summary. Gone. The field is not even presented to me. I do/did have my interface tweaked to get rid of the gallons of material at the bottom of the page, and order it better. I'm assuming that is the issue. Can anyone advise if there's any way to tweak my customization or can identify the issue between my common.js and my my common.css?--Fuhghettaboutit (talk) 12:03, 19 July 2017 (UTC)
@Fuhghettaboutit: Eh, yeah you are doing some very uncommon manipulations there with both JS and CSS on your editOptions. If you want to hide something, you should always target as narrow as possible, not go high level and then selectively move things out of it with JS... —TheDJ (talkcontribs) 15:37, 19 July 2017 (UTC)
  • Any chance we have a preference like with VE ?, My main dislike is the huge blue button as well as the rather big tick (image) - Wouldn't be so bad if it was smaller, ofcourse I realise it's been designed for people with eyesight issues however without being disrespectful we're not all blind so surely there should've been common ground in terms of the design ?,
It pleases those with eyesight issues (which is absolutely great) but it pisses those off that don't have eyesight issues (FWIW I am short sighted and do wear glasses however the previous design was never an issue),
If we could have a preference option like with VE that'd be great - I know we can't please everyone I understand that but atleast to me the big blue button/tick is rather extreme... –Davey2010Talk 16:41, 19 July 2017 (UTC)
Davey, I know it seems like a pretty big visual change, but my bet is that if you wait a couple of weeks, you won't notice it as much any longer. Most people adapt to visual changes pretty quickly. Also, since most of us here are experienced editors, most of us don't really look at the buttons much anyway: It's just Tab ↹ to the edit summary box, type the edit summary, and Return to save the page. The buttons don't even need to be above the scroll.
We made this change at half a dozen big wikis two weeks ago. There were a few comments about the size and color there on the first couple of days, but I've seen nothing about it since then. Whatamidoing (WMF) (talk) 20:04, 19 July 2017 (UTC)
Ah see I don't do that - I usually hit any part of the scrollbar thus making it "ping" to any place - I then type whatever or use the arrow keys for autofil and then hit return,
Ofcourse I mean changes happen everywhere and not all are liked but we live with it but usually if something changes to my dislike I'll "dislike it but live with it" but here and I hate to be a little drama-queen but I actually hate it, The button is "too in your face" if that makes sense, I love the colour Blue always have so I love the colour choice here no problem but the button and tick are too big,
It would've been better to have it the same size as the previous and perhaps have implemented a tool where it could be made bigger in preferences or something, But I suppose it all goes back to "you can't please everyone",
Ah well it's changed and I guess there's nothing I can do except look in anger! Face-tongue.svg, –Davey2010Talk 20:37, 19 July 2017 (UTC)
Is this why the button is green?— Vchimpanzee • talk • contributions • 20:52, 20 July 2017 (UTC)

Show changes clicks Editing help on Android

On Google Android phone (Google Chrome) browser, the new oversize "Show changes" (button 3) clicks into "Editing help" (cheatsheet link) which is very bizarre because no "Cheat" buttons onscreen, and "Show changes" really should show changes on mobile phone edits (which are hard enough already). This glitch shows the horrors of user-hinterface experiments which can hinder simple processing, as the inverse consequence of wanting a modest improvement in user interfaces. "Kids don't do this: never move the brake pedal, gas petal or steering wheel while a car is being driven". We need an essay, "wp:Computer Screwups 101" to remind people to use alpha/beta testing steps on crucial user-interfaces, where experimental glitches can have horrific impacts (over 20,000 mobile phone edits per month). -Wikid77 (talk) 08:32, 20 July 2017 (UTC)

This report misses critical information. which page, which editor, which skin, which android device, which version of google chrome, did you test with disabling all your gadgets and userscripts ? How to report bugs effectivelyTheDJ (talkcontribs) 07:05, 21 July 2017 (UTC)
It happens on any page (wikitext editor) in Vector skin (Monobook skin ok) while suppressing License blurb, but when logged out then "Show changes" clicks Show preview, on Android phone LG Escape2, version 5.1.1. To avoid preview horrors, the Monobook skin can be used (which shows avocado " Save_changes " rather than Vector blue  Save changes ). -Wikid77 (talk) 06:08, 24 July 2017 (UTC)

New Edit summary window

The redesigned Edit summary window has the text left-anchored, with the result that most of the time you can't see what you're typing because it's off the right-hand end of the window (on an ordinary 13" laptop). Can that really be what the designers wanted to achieve? The remaining-character count is good, though. Justlettersandnumbers (talk) 08:27, 19 July 2017 (UTC)

@Justlettersandnumbers: It is supposed to right align. If it is not for you, then that might be a browser specific bug. Please report what browser and version of it you are using. —TheDJ (talkcontribs) 09:11, 19 July 2017 (UTC)
Safari Version 5.1.10, TheDJ. Justlettersandnumbers (talk) 09:14, 19 July 2017 (UTC)
Ah, that browser is not really supported anymore, so I guess it's not too surprising. I've been saying that we should disable JS support for Safari 5, but so far it seems it's still included. —TheDJ (talkcontribs) 09:51, 19 July 2017 (UTC)
Similar but not identical problem in Chrome Version 49.0.2623.112; Firefox 48.0.2 is OK, though. Justlettersandnumbers (talk) 09:20, 19 July 2017 (UTC)
I use Chrome 36 (after I abandoned Firefox because v. 51 got waaay too slow - five minutes to load a Wikipedia diff, and ten mins to click "back" from that? Ridiculous) and I find that it's right aligned, but the last two or three characters are hidden by the bytes-remaining counter. Pressing End reveals them though. Perhaps that counter could be put outside the box? --Redrose64 🌹 (talk) 10:06, 19 July 2017 (UTC)
Counter, what counter? Using the latest version of Chrome with Vector. Doug Weller talk 10:58, 19 July 2017 (UTC)
Are you using wikEd? That makes its own edit summary box with no counter. PrimeHunter (talk) 12:38, 19 July 2017 (UTC)
@Doug Weller: I suspect this might be interfering. And indeed so will wikEd. —TheDJ (talkcontribs) 12:57, 19 July 2017 (UTC)
@PrimeHunter and TheDJ: I got rid of the CSS but I want to keep WikiED, I'm ok without the counter, just nice to know why I can't see it. Doug Weller talk 15:40, 19 July 2017 (UTC)
@Doug Weller: I'm not going to fix wikEd though, you will need to contact it's maintainer. —TheDJ (talkcontribs) 15:50, 19 July 2017 (UTC)
@TheDJ: Of course not, why should you? As I said, I'm not bothered, I want to keep WikiED. Doug Weller talk 19:09, 19 July 2017 (UTC)
@Doug Weller: By "that counter", I mean the one described at Help:Edit summary#The 250-character limit (the bit about the figure 143). --Redrose64 🌹 (talk) 20:02, 19 July 2017 (UTC)
I have the same problem on Firefox 52.2.1. Deli nk (talk) 12:43, 19 July 2017 (UTC)
I have the same problem with latest version of Chrome for Windows. When I undo a change, I find myself removing most of the default stuff in the box so I can see what I'm doing. Annoying. Any way to go back until they fix it?--Bbb23 (talk) 14:04, 19 July 2017 (UTC)
  • Please roll back the change to the edit window. This makes it harder to write edit notes. It is cute to have the little twitter character counter but it actually gets in the way many, many characters from the end. This must go'. Jytdog (talk) 22:19, 19 July 2017 (UTC)

Edit summary field hidden

Not sure if this is related, but I came here wondering about why I was not able to see any edit summary field at all. I'm editing on a Kindle fire at the moment with the vector skin. olderwiser 08:57, 19 July 2017 (UTC)
You have #wpSummaryLabel hidden in your vector.css (as did I). Just remove the line.[7] -- zzuuzz (talk) 09:06, 19 July 2017 (UTC)
Hmm, that seems like an oversight in one of the IDs.. Please file a bugreport. —TheDJ (talkcontribs) 09:11, 19 July 2017 (UTC)
(edit conflict) The id wpSummaryLabel ended before the box in an old version I compared to. You can currently place the below in your CSS to hide the heading but not the box. PrimeHunter (talk) 09:32, 19 July 2017 (UTC)
#wpSummaryLabel .oo-ui-labelElement-label {display:none;}
@Bkonrad and Zzuuzz: You can increase the specificity of the selector, like this. --Redrose64 🌹 (talk) 09:31, 19 July 2017 (UTC)
Thanks @Redrose64 and PrimeHunter:. Both your suggestions work, though I noticed PrimeHunter's suggestion also hides the count of remaining characters (something I had not seen before and is nice touch). olderwiser 10:02, 19 July 2017 (UTC)

What is this number?

When I'm in the edit window in Firefox 54.0.1, logged in, there is an odd 3-digit number outside and to the right of the Edit Summary box. That same number appears no matter what article I open up. So, I opened Microsoft Edge without logging in. That same number appears no matter what article, except it's inside the Edit Summary. Are you tracking us? What is this number, and why is it the same number no matter what article, no matter if I'm logged in or not? — Maile (talk) 11:54, 19 July 2017 (UTC)

@Maile66: Type some letters into the edit summary box and you will see what it means! See also the first point at Help:Edit summary#Edit summary properties and features. — This, that and the other (talk) 11:57, 19 July 2017 (UTC)
Ahhhhh ... it counts the characters in our edit summary and tells us when we've reached the limit. Thanks. — Maile (talk) 12:00, 19 July 2017 (UTC)
@Maile66: Specifically, it counts bytes rather than characters; if you type in non-Latin characters like "카나다", "Канада", or "קאנאדע" you'll see it drop more quickly. My colleagues in the MediaWiki team are working on making it possible to write more than the current limit of 250 bytes, which was a highly-rated Community Tech wishlist item recently. Jdforrester (WMF) (talk) 15:56, 19 July 2017 (UTC)
Seems pretty pointless TBH. Another good reason why I ditched using edit summaries years ago. Lugnuts Fire Walk with Me 13:04, 19 July 2017 (UTC)
Actually, it counts the bytes, not the characters. This distinction is what makes it particularly useful for people who aren't typing in English. Whatamidoing (WMF) (talk) 15:34, 19 July 2017 (UTC)
@Maile66 and This, that and the other: A better link is Help:Edit summary#The 250-character limit, in particular the bit about the figure 143. @Jdforrester (WMF): 255 bytes, not 250. Same link. --Redrose64 🌹 (talk) 20:00, 19 July 2017 (UTC)
The counter is cool but should be outside the text field. The rest of the changes are just ugly. RivertorchFIREWATER 23:28, 19 July 2017 (UTC)

Last characters in summary are hidden

I came here to ask a related question, and saw this thread. How do I turn off the count box? I couldn't find anything in preferences. Is there a .css or setting that will kill it? On Google Chrome (with MonoBook skin), the box hides the last couple characters typed in the Edit Summary box - as a result, it just gets in the way. To verify I didn't leave off anything I need to back arrow then forward arrow to trick the UI to show me all the typed characters. If I type again at that point, they are again hiddent and I need to use the stupid back arrow/forward arrow thing again to view all my typed characters. --- Barek (talkcontribs) - 17:06, 19 July 2017 (UTC)
.oo-ui-textInputWidget > .oo-ui-labelElement-label { display:none !important; }
in your common.css. —Cryptic 17:13, 19 July 2017 (UTC)
Doesn't work—the countdown is still there. I'm sure this was implemented with the best of intentions but please, disable it until you can get it working properly—not being able to see what you're typing is remarkably irritating. We survived for 15 years without it, I'm sure we can survive another week while you work the bugs out. ‑ Iridescent 17:18, 19 July 2017 (UTC)
You're right - I was able to change the positioning and opacity with that selector, but display doesn't stick. I've added an "!important" to the above, which does work. (At least for me, in cologneblue, in preview.) Try that? —Cryptic 17:24, 19 July 2017 (UTC)
Even if CSS allowed to hide it, note that this will not prevent the extra scripts from loading and running (every typed character will still be processed by them). —PaleoNeonate - 17:21, 19 July 2017 (UTC)
Works here. It is an element and so it can be easily hidden. The selector is correct, make sure you copied it exactly and placed it in the correct file. Not to say it won't change tomorrow though. Also the count doesn't hide anything for me, so might be a browser-specific issue. Or just that skin? Either way, might work one day! Lithopsian (talk) 17:25, 19 July 2017 (UTC)
Sorry, my mistake, I was using a different selector:
#wpSummaryWidget > .oo-ui-labelElement-label
Lithopsian (talk) 17:28, 19 July 2017 (UTC)
Since "that browser" is Chrome and "that skin" is Vector, this is the most frequently occurring combination among Wikipedia editors by an order of magnitude—we're talking a major issue, not some obscure glitch that only affects a few users using archaic systems. ‑ Iridescent 17:30, 19 July 2017 (UTC)
I figured out why this is occurring. Let's hope someone can find a fix for it soon. —TheDJ (talkcontribs) 18:31, 19 July 2017 (UTC)
I also experience a strange bug where sometimes characters become hidden under the counter when typing using FF, after typing enough it resets and I can see the new characters again. I would really like if most of those new features systematically came with corresponding disable/enable preferences (large buttons, interwiki search, this counter are examples of recent features which lacked systematic toggling options. There's now a gadget to disable the search aspect (and it could be hidden by CSS), but that was still introduced afterward and does not prevent unnecessarily loading extra scripts (and all the interdomain pages, as can be seen in inspectors or security control addons); I also noticed that page loading time increased in the last months, scripts often lagging behind the actual page. I commonly click on the watchlist star before all scripts are loaded, causing the page to reload with the "add/remove" question like if JS was disabled. Another common occurence is for the page to load and jump at the proper anchor with scripts lagging, which when loaded cause sudden scrolling/jump, where I have to select the address bar and press enter again to scroll to the anchor. It's unfortunate for this bloat to become obvious for features I don't need, even on a fast system and fast connection... —PaleoNeonate - 22:50, 19 July 2017 (UTC)
  • Yes please turn this "counter" off. It is a bug, not a feature. Jytdog (talk) 22:23, 19 July 2017 (UTC)

Character counts on subject/edit summaries?

I'm seeing character counts on the Subject and Edit summary boxes now, which I wasn't before a few days ago. However, for long edits (such as after a revert) the cursor and last few characters are hidden.

Is this on for everyone, or is my Javascript (currently only OneClickArchiver) somehow causing this? Power~enwiki (talk) 21:37, 19 July 2017 (UTC)

see #What is this number? above, sounds like the same. Nthep (talk) 21:46, 19 July 2017 (UTC)
yup, same thing. Closing. Power~enwiki (talk) 23:44, 19 July 2017 (UTC)


What is the process through which this "Improvement" was implemented? Jytdog (talk) 22:24, 19 July 2017 (UTC)

God only knows. At the very least, there should have been a banner warning users of it. When I first saw it yesterday, I wondered for a moment if I'd somehow wound up on a spoofed site. RivertorchFIREWATER 23:26, 19 July 2017 (UTC)
Obviously someone at WMF who never uses this site thought it would be a great thing to implement. Hats off to them! Lugnuts Fire Walk with Me 12:11, 20 July 2017 (UTC)
It was pointed out to me here that this was done via phab:T36984. That in turn was related to phab:T165856. It ~appears~ to me that User:Jdforrester (WMF) was the person who implemented the request? I don't understand how the process of changing code works or how decisions are made to actually implement things. I suppose somebody thought this was a trivial tweak. I have no idea.
There is a Tech news thing where the devs communicate what they are doing, but I looked through the current issue and one previous issue and don't see this mentioned. Jytdog (talk) 12:31, 20 July 2017 (UTC)
Obviously someone at WMF who never uses this site is wrong per Jytdog's phabricator link (which I dug up). The original feature had implementations on other wikis in gadget form (especially the non-Latin alphabetic wikis) and has anyway existed in VisualEditor for 5 years (without seeming complaint anywhere on phabricator, besides a handful of breakages). --Izno (talk) 12:37, 20 July 2017 (UTC)
User:Izno - I have appreciated your providing information but the implementation in the WikiEditor was crappy and broke things. Period. Whether it worked somewhere else is entirely irrelevant. People get angry when their tools get broken - irrelevant argument pours oil on the fire. Jytdog (talk) 13:10, 20 July 2017 (UTC)
Indeed. So I guess we all need to start using VisualEditor so that we'll be forewarned about interface "improvements". It never ceases to amaze me: there are so many areas of the editing experience that could be improved, and WMF developers have repeatedly shown themselves capable of coming up with brilliant solutions, but they keep fixing things that aren't broken. And failing to give fair warning. RivertorchFIREWATER 13:57, 20 July 2017 (UTC)
It is rather amusing to see that almost everything now on my common.js and common.css pages exists solely to reverse various changes WMF developers made. And I certainly cannot thank enough everyone who has contributed here with wonderful solutions, with a special shout-out going to Mikhail Ryazanov and Cryptic! ^_^ Double sharp (talk) 14:36, 20 July 2017 (UTC)
@Rivertorch: Not having an indicator of how much information I could pack into an edit summary was more-or-less broken behavior and I'm personally surprised this change wasn't made earlier. "No-one got around to it because it would have been a pain before the train got rolling on the big blue Publish button" seems to be the indication from the phabricator task for the "why" of that. --Izno (talk) 15:11, 20 July 2017 (UTC)
@Izno: As I indicated elsewhere in this ever-growing section, the counter isn't a bad thing; the implementation of it is. The implementation is half-baked and was rolled out without proper notification. (It certainly wasn't urgently needed; one becomes rather adept over the years at estimating summary length and trimming as needed.) RivertorchFIREWATER 18:19, 20 July 2017 (UTC)
@Rivertorch: Agreed, generally. --Izno (talk) 18:31, 20 July 2017 (UTC)
@Jytdog: Having feelings about an (un)expected change is understandable. Communicating that in a non-collegial manner (that is, dripping sarcasm and obvious lack of research) is not. I am perturbed that you did not state an issue with his behavior but instead targeted my response, but sure, I'll move along. --Izno (talk) 15:11, 20 July 2017 (UTC)
User:Izno this was not feelings about an unexpected change - it is frustration with a change that broke something I rely on for every edit I make, that adds a "feature" that provides no value for me. Your initial responses were helpful and provided information. These last responses have not been helpful but are causing "feelings" that are decidedly not good. Jytdog (talk) 05:12, 22 July 2017 (UTC)

Make it stop

Please kill this counter. It is turning my edit notes into garble. This is so unbelievably stupid. TURN THE COUNTER OFF.Jytdog (talk) 03:00, 20 July 2017 (UTC)

This issue is being worked on. —TheDJ (talkcontribs) 09:32, 20 July 2017 (UTC)
The counter should be removed and made an option for people who want to see how much space they have left. I do not want this clutter. Removing it should be simple and fast, no? Whatever it takes to fix it can be worked out at leisure then, and It can be re-implemented as an option. Jytdog (talk) 13:13, 20 July 2017 (UTC)
The counter gets in the way of editing on a mobile / tablet and makes it impossible to leave a meaningful edit summary when reverting an edit using the web interface on an iPhone. For example: Undid revision 12345689 by Example (talk) consensus on the talk page is that this information violates the biographies of living persons policy and should not be used. Ritchie333 (talk) (cont) 09:43, 21 July 2017 (UTC)
  • It stopped!! Thank you devs, very much. Such a relief not to have to fight with the software to leave an edit note. We take simple things that work for granted, so I wanted to be sure to say thanks. I would prefer not to have the counter re-implemented but if it must be, please keep it out of the way. Jytdog (talk) 21:42, 21 July 2017 (UTC)

Cancel button no longer a button

Why is the Cancel button no longer a button, just a bolded red text link?

What on earth is that about? --BrownHairedGirl (talk) • (contribs) 09:20, 20 July 2017 (UTC)

The link has changed colour and size, but it wasn't a button before: 2014 screenshot -- John of Reading (talk) 09:29, 20 July 2017 (UTC)
The word "Citations", also without button, is floating just above the line between "Show changes" and "Cancel". (Monobook, desktop, current Firefox): Noyster (talk), 12:32, 20 July 2017 (UTC)
That sounds like you have a user script or gadget that needs updating. Anomie 12:45, 20 July 2017 (UTC)
The color change was not a good idea, because now it looks like a redlink, instead of just an editing page option. kennethaw88talk 00:00, 22 July 2017 (UTC)
Well... to experienced Wikipedians perhaps.. to the rest of the world, probably not as much. —TheDJ (talkcontribs) 10:05, 28 July 2017 (UTC)

Shortened edit summary

Nobody else seems to have mentioned it, so I will: Since the implementation of the accessible save buttons, the length of the edit summary seems to have been cut in half. I usually edit on a Windows 7 machine using 64-bit Firefox 54.0.1, using WikEd and these scripts; here is my CSS. Any suggestions? If I undo an edit, the automatically generated portion of the edit summary (the diff number and the links to the editor's contribs and talk page) take up more than half the length of the (shortened) edit summary. Thank you. — Malik Shabazz Talk/Stalk 02:47, 21 July 2017 (UTC)

I was wondering about that, but I think it's unchanged. There is a bug in that when scripting is disabled in the browser, there is no visible cursor in the edit summary box once the cursor hits the end of the box (129 characters in my browser window at the moment—that depends on how wide the window is). I can continue typing (with no visible cursor) until 200 bytes have been entered. I think that is the same as it used to be, although 255 bytes are available when scripting is enabled. Johnuniq (talk) 01:40, 23 July 2017 (UTC)
The 200-byte limit was lifted for everybody with the release of MediaWiki 1.17 back in February 2011; making this gadget somewhat redundant (it's no longer listed at Preferences → Gadgets). --Redrose64 🌹 (talk) 08:42, 23 July 2017 (UTC)
OK, but I tested before posting my comment above, and 200 bytes is all I can put in an edit summary box with scripting off, and 255 with it on. Johnuniq (talk) 09:57, 23 July 2017 (UTC)
I think it is just wikEd racing the oojs ui. If wikEd is first, it gets 200 limit (because that is the fallback if OOjs UI has not finished enhancing the view). —TheDJ (talkcontribs) 15:06, 24 July 2017 (UTC)
Thank you all for your comments and assistance. I tend to agree that it's probably a conflict with WikEd, because it doesn't happen on every edit. Just the ones for which I need a long edit summary. Face-smile.svg — Malik Shabazz Talk/Stalk 02:02, 26 July 2017 (UTC)

No preview of edit summary

I'd like to also express my disapproval of the new bigger "Save changes" etc buttons. More importantly though, I no longer get a the preview of edit summary that I used to get when I clicked "Show preview" or "Show changes". I use the MonoBook skin, but the same problem occurs when I switch to Vector. The preview of the edit summary itself is quite useful because I frequently include wiki-links in my edit summaries - most often to the relevant MOS guideline shortcut (eg MOS:BOLD) when editing pages to meet those guidelines. The summary preview showed me a clickable link (red if I've mistyped it) which I can ctrl-click (open in new tab/page) to check. Can we have the summary preview put back please. Mitch Ames (talk) 09:52, 24 July 2017 (UTC)

When I try it, in both Monobook and Vector, the preview shows up just under the edit summary input. I don't think it has even moved due to this change. Anomie 12:11, 24 July 2017 (UTC)
If I try in in a "private browsing" window, so I'm effectively not logged in, the preview appears, so perhaps there's something in the new style that conflicts with one or more of the settings in my preferences. I could reset them all to defaults and work through them all, but that will be tedious. Does anyone have any suggestions as to specific settings to try? Mitch Ames (talk) 13:34, 24 July 2017 (UTC)
Mitch Ames, if you are using the Live Preview option of your preferences, then there is currently a bug where the preview of the summary doesn't work. This is ticket phab:T171156. —TheDJ (talkcontribs) 14:59, 24 July 2017 (UTC)
Thanks - that's the cause in my case. I do have live preview enabled, and if I disable it the summary preview reappears. Mitch Ames (talk) 11:22, 25 July 2017 (UTC)

Show Preview and Show Changes on a single button

Since everyone's focused on this general topic, can I renew my plea for a single button that will give "Preview" and "Changes" at the same time? It's such a perfectly obviously useful thing, and there should be zero design issues. I'll just sit here and hold my breath until that's done. Thanks. EEng 13:43, 27 July 2017 (UTC)

@TheDJ:: What's the status of your experimental script for this? Whatamidoing (WMF) (talk) 16:13, 27 July 2017 (UTC)

New look in edit window on Delete Page

I'm fine with the big blue buttons in the regular edit windows. I am also an admin, and now when I delete a page, the big button that says "Delete Page" has a red background. For people with vision problems, the editors I think you want to accommodate, red is not a good choice. Especially in older people, or anyone dealing with macular problems. Red is one of the first colors that becomes harder to see. — Maile (talk) 00:14, 21 July 2017 (UTC)

Agree that color is horrible - this whole scheme wasn't thought through very well before release. — xaosflux Talk 00:33, 21 July 2017 (UTC)
Those colors are more for those who don't have those problems (it's a cognitive speed-up for most of us). But for the accessibility of those with visual impairments, there are basically two types of buttons: 'primary' (colored) and neutral/secondary (non-colored). For accessibility it matters if you can read the text (achieved by contrast between background vs text), and if can distinguish the primary choice from the other choices. The red color indicates the action is 'destructive', but the text is required to ALWAYS use wording that also implies 'destructiveness' (so that this is not solely communicated via color, which would be bad for screenreader users as well). —TheDJ (talkcontribs) 06:44, 21 July 2017 (UTC)
Yes, but ... the delete button is white text with red background. If a visually-challenged person doesn't see the red, then they just have a field of white with no distinct lettering. Or, depending on their individual case, maybe that red fades and blurs until they see some kind of background, but the text is not distinct. Maybe other colors too. But I'm just saying that visually-challenged people have difficulty with colors. And if the button is white letters with any color background, what a visually-challenged person sees is just a block of nothing. — Maile (talk) 11:09, 21 July 2017 (UTC)
@Maile66: I don't know much about all forms of visual impairments, but I do know that the color sheet is at least AA and strives to be AAA as much as possible. The style has been tested for most color deficiencies. But macular degeneration is a rather problematic issue and depending on how far it has progressed, it will indeed significantly affect your ability to read anything that doesn't have the highest contrast ratios (black vs white). We have had a long standing wish to integrate some aggressive accessibility settings (font size, contrast, aliasing/smoothing) to tackle the last of these problems, but as most users have these tools as part of their OS as well, it hasn't had top priority unfortunately (there have been some experiments at hackathons though).—TheDJ (talkcontribs) 12:30, 21 July 2017 (UTC)
Okey dokey. — Maile (talk) 12:38, 21 July 2017 (UTC)
Thanks for the link, The DJ. The bottom line is that red is, for almost all Western cultures, associated with high risk/emergency/problems....and that is not the association that should be made with where the colour red is being used here. I've also done a little poking at the WCAG guidelines and haven't been finding statistically valid testing to back many of the assertions and principles of the project, but that's neither here nor there. End of the day, red is a much harder colour for MOST people to see when it is in skinny font - almost regardless of background - and it's not being used effectively in these interfaces. I'd much rather they skipped the red completely or, if used at all, always have it presented properly as a button with bold, fat fonts. The editing population is aging a lot, and neither the WCAG standards nor the WMF colour palette take this factor into consideration. It has nothing to do with macular degeneration. It has more to do with changes over time in the way people perceive colours. Risker (talk) 00:08, 24 July 2017 (UTC)
I suspect they chose red for "destructive" actions such as deleting a page specifically because of that association. I'll leave debate over whether WCAG took "aging" vision into account for others. I see TheDJ already created T171458 to determine whether the Monobook styling actually follows WCAG's guidelines (it wouldn't terribly surprise me if it turns out they had only looked at Vector before). Anomie 12:15, 24 July 2017 (UTC)
I'll back out a little from my prior comment "the whole scheme" is a bit vague - I'm really only referring to the red "Cancel" and "Delete" buttons links - perhaps just adding some font weight to them would be enough. — xaosflux Talk 15:45, 21 July 2017 (UTC)
  • Noting in passing that today I found the delete button to be white with red lettering. Now, I've got pretty good eyesight, and I could barely make out what the letters were because they were too faint. They need to be bolded, bigger - and NOT RED. Red is almost never a good colour for an interface, unless the intention is for it to be considered the "Emergency" button. I also can barely read the "Cancel" link in the editing window below - also red, thin font. How about making the "CANCEL" an actual button rather than just a word?Can it at least be CAPITALIZED? It should be considered an equal partner to the other buttons. Current FF, Windows 10, Monobook. Risker (talk) 23:53, 23 July 2017 (UTC)
    • I share some concern with you about the accessibility of the Apex (as it is called) oojs-ui style that monobook users receive. I have created T171458 to start with an assessment and documentation of the color combinations. —TheDJ (talkcontribs) 10:07, 24 July 2017 (UTC)

Drop Down Box

Too much whitespace example
  • The other problem is that scroll-down list of reasons has too much white space and is harder to scan. Also, the font seems lighter and harder to read (for me) on the white background. SarahSV (talk) 22:14, 21 July 2017 (UTC)
    100% agree here, way to much line spacing here - how can we get these adjusted back? — xaosflux Talk 02:20, 22 July 2017 (UTC)
    • You write a style gadget that changes it. —TheDJ (talkcontribs) 12:48, 22 July 2017 (UTC)
TheDJ Don't exactly understand what you're saying, unless you're saying we should write a style gadget. But the issue with the drop down box spacing (at least on mine) is that every line is double spaced between the lines (LOTS of white space between the lines), larger type than before, and while the categories are in bold, the individual selections are grayish. I'm guessing ... but this seems to be what is about to happen to everything, including blocking, protecting pages, etc. etc. I know this was done in good faith, but it seems like it's being rolled out for a given editor demographic (whatever that is). — Maile (talk) 21:21, 22 July 2017 (UTC)
Maile66 Maybe we're not seeing the same things. Screenshots can be uploaded here. —TheDJ (talkcontribs) 00:01, 23 July 2017 (UTC)
This is more trouble than it's worth. I'm not doing a screenshot. Sorry. I know you mean well. Editing on Wikipedia shouldn't require all this. I find the changes happening counter-productive to what I do on Firefox. That's it. And it isn't just this edit window. If I send you a screen shot on this latest, tomorrow it will be something else. And another. And another. And another. Little things started going whack-a-doo for me about a month ago, when everybody else started complaining about things like the missing toolbar or other stupid stuff in the edit window. And every time another change comes, something else looks whacked, and not everything going on behind the scenes works for everybody. Bah. Humbug. What's happening now is total junk.— Maile (talk) 00:35, 23 July 2017 (UTC)
Also, I know you are very dedicated and are very diligent at trying to help editors. I don't mean to sound rude towards you, The DJ, but whatever they're doing is just too much. Sometimes I open an edit window, and everything looks normal. Sometimes it takes a refresh, or a preview, or any guess on a jiggle here or there to get things to load right in the edit window. And it's not consistent. And it's not a virus or malware. It's the re-programming that's happening. Unbelievable. — Maile (talk) 00:56, 23 July 2017 (UTC)
@TheDJ: see screen shot on the right, that double spacing is unwanted. — xaosflux Talk 23:23, 23 July 2017 (UTC)
Thank you Xaosflux. That does look a bit weird indeed. I have filed T171455 to double check if this is correct. —TheDJ (talkcontribs) 09:55, 24 July 2017 (UTC)

Maile66: Here's some medicine for you:

Big CSS snippet
/* Remove some whitespace */
.oo-ui-panelLayout-padded {
	padding: 0;

.oo-ui-fieldsetLayout.oo-ui-labelElement > .oo-ui-fieldsetLayout-header > .oo-ui-labelElement-label {
	margin-bottom: 0;

.oo-ui-panelLayout-padded.oo-ui-panelLayout-framed {
	margin: 0;

.oo-ui-fieldLayout.oo-ui-fieldLayout-align-inline {
	margin-top: 0;

.oo-ui-fieldLayout.oo-ui-labelElement > .oo-ui-fieldLayout-body > .oo-ui-fieldLayout-header {
	padding-bottom: 0;

.oo-ui-fieldLayout {
	margin-top: 0;

.oo-ui-dropdownInputWidget select:not( [no-ie] ) {
	height: 1.5em;

.oo-ui-textInputWidget input,
.oo-ui-textInputWidget textarea {
	padding: 0;

/* Make destructive buttons black */
.oo-ui-buttonElement-framed.oo-ui-widget-enabled.oo-ui-flaggedElement-primary.oo-ui-flaggedElement-destructive > .oo-ui-buttonElement-button {
	color: white;
	background-color: black;
	border-color: black;

.oo-ui-buttonElement-framed.oo-ui-widget-enabled.oo-ui-flaggedElement-primary.oo-ui-flaggedElement-destructive > .oo-ui-buttonElement-button:hover {
	background-color: black;
	border-color: black;

You can put that in Special:MyPage/common.css. You can pick and choose the snippets you want or copy it wholesale. If you think it's too squeezed up, you can just replace 0 with 3px or whatever values you want. Nirmos (talk) 12:02, 23 July 2017 (UTC)

Thank you. It has no effect on the white spacing. But one thing it does, is change that red button to black. And what a great improvement the black is. So, thank you for providing this to me. Just for the record, I have previously tried deleting all my scripts, and that didn't work. I've tried changing my skin to Vector, and that didn't work. I unchecked just about everything in Preferences/Gadgets, to no effect. The phenomenons I'm experiencing in English Wikipedia do not happen on Commons or Wikisource, both of which look remarkably like they always did. — Maile (talk) 12:12, 23 July 2017 (UTC)
Maile66: I've updated the code above to also remove the whitespace for the drop down menus and the text inputs. Nirmos (talk) 12:31, 23 July 2017 (UTC)
Nope, nothing. But I have a question. There is something in my .css that I put there in 2013. I can't remember why I put it there, or what it's for. Could it be part of the cause? — Maile (talk) 12:43, 23 July 2017 (UTC)
Maile66: You are indirectly loading MediaWiki:Gadget-navpop.css, but I don't think that's the problem. What skin are you using, exactly? Nirmos (talk) 12:56, 23 July 2017 (UTC)
Nirmos I have no idea what that Gadget-navpop does, so I must have been reading some noticeboard when I did that. I'm using Modern skin. I clear my cache. Tried Vector skin with the changes you gave me. I am on Windows 10 , Firefox 54.0.1. — Maile (talk) 13:12, 23 July 2017 (UTC)
Maile66: I can't see that you have tried my revision in Special:Diff/791941470. Nirmos (talk) 13:18, 23 July 2017 (UTC)
I misunderstood. Now I have tried the revision, both in Modern and Vector skins. What that does, is narrow the drop down box and the "Other additional reason" blank. But within the drop-down list itself, it's still double spaced between the drop-down reasons, and that's the original issue. Also, your changes not only narrowed the box on the Delete template, but as I'm typing this, I see it narrowed the Edit Summary box below this window. In case I was not clear, I can live with a wide Edit Summary box/drop down box. It's the lines between the drop-down reasons that are the issue for me. — Maile (talk) 13:37, 23 July 2017 (UTC)
Maile66: How much space there is between option elements varies by browser. Firefox simply has more space in between than, say, Chrome. Nirmos (talk) 14:49, 23 July 2017 (UTC)
Bingo! You just solved it. I don't normally use anything but Firefox. And the only other browser I have available to me it Edge, which does not show the extra spaces inbetween. It's Firefox. Sorry I wasted everybody's time on this. — Maile (talk) 15:49, 23 July 2017 (UTC)
@Maile66: I don't think you've wasted anyone's time. And if the "fix" that you got is the same as everyone else needs we may need to put it site wide. — xaosflux Talk 00:33, 24 July 2017 (UTC)
Xaosflux There's another piece to this puzzle regarding Firefox 54.0.1 (which I've just learned to live with) - that version of Firefox became available almost at the exact same time that Wikipedia started rolling out its changes. And there's more than just the double spacing issue. Opening an edit window in Firefox is funky, and I don't know if it's Firefox or the Wikipedia changes. And the issue with the Firefox edit window opening is that not everything loads (toolbar, and on opening things like AIV/RFPP listings, the "Show" link to drop down the templates) The solution to getting everything to drop down is to reload the page, or do a Preview, or whatever works at that time. And then again ... sometimes everything in the edit window opens up the first time. I haven't checked the Edge browser on anything but the double spacing, so I don't know if these issues are inherent in the current version of Firefox, or if all of these issues are a conflict with any Firefox version. — Maile (talk) 00:50, 24 July 2017 (UTC)
The "doublespace" problem does appear to be limited to Firefox (at least in FF v54.0.1) - verified with a separate account on testwiki - using chrome there is no doublespacing, with FF there is (with the new UI). — xaosflux Talk 01:32, 24 July 2017 (UTC)
@Maile66: If you mean the line
@import url('');
that, in essence, means "take the whole of the page User:Lupin/navpopdev.css and copy it here". So any CSS on that page will affect your experience as a user, and any changes there will be outside your control. --Redrose64 🌹 (talk) 18:52, 23 July 2017 (UTC)
Side note: The OOjs UI change (aka "Big Blue Button") has only been deployed to the Wikipedias so far. It will reach most sister projects on Tuesday, August 1st, and Commons sometime later. The reason I split this up is because it can affect some editing scripts, and there are only a handful of volunteers who really know how to fix some of them. I didn't want to overload them with all the wikis on the same week. The main downside is that you can't test a script this week at, say, Wikisource, to determine whether it's working under OOsj UI. Instructions for testing (including how to turn it off here for a single edit, by hand-editing the URL to include &ooui=0, so that you can see whether a problem you're encountering is actually related to this) are still at mw:Contributors/Projects/Accessible editing buttons. Whatamidoing (WMF) (talk) 18:09, 24 July 2017 (UTC)

#iferror does not work correctly with template:convert for me

I try to use {{#iferror:}} in a template which uses template:convert so that when the convert template gets invalid input, no "invalid number" error is returned. See User:Spike/Sandbox/Template:NFL predraft 2 for a simple example. But it does not work for me. When I use my new template User:Spike/Sandbox/Template:NFL predraft 2 on a page, see e.g. User:Spike/sandbox, I still see an "invalid number" error. The strange thing is that when I edit a page which transcludes this template, everything looks fine in the preview window: as I expected from the code, the error is simply replaced by the non-converted value. Try it out: Open User:Spike/sandbox for editing and click "Show preview" without changing anything. No error visible, #iferror replacement works perfectly. Only when I save the page does the error show up. Can someone tell me what I'm doing wrong? I have also tried another template which uses the same method, template:Ridership, and it seems that it has the same problem.

Until now I only have tried all of this in my own sandbox. Maybe it is a problem which only comes up in the sandbox and not in the proper Wiki. But I have not yet had the courage to do a change in the main namespace to try it out. Spike (talk) 14:47, 21 July 2017 (UTC)

{{#iferror:}} checks for class="error". {{Convert}} uses ispreview() in Module:Convert to only add that class in preview where a prominent red error message is displayed. On saving it adds the blue link seen in User:Spike/sandbox without class="error". {{convert|2{{frac|3|8}}|in}} produces:
[convert: invalid number]
Compare the above in save and preview. PrimeHunter (talk) 16:24, 21 July 2017 (UTC)
Seriously? This is why stuff like "ispreview()" is a bad idea and should be avoided. Anomie 16:38, 21 July 2017 (UTC)
As I understand it, "ispreview()" is not the issue here but the fact that {{Convert}} does not save "class=error". With such a saving, "#iferror" will work. (see also Template talk:Convert, looks good). Objections to "ispreview()", I'll encounter in other places then. -DePiep (talk) 20:19, 22 July 2017 (UTC)
My issue here is that the output of the template when previewed is wildly different from the output of the template when saved, which misbehavior "ispreview()" enables. Anomie 13:06, 23 July 2017 (UTC)
Convert works like that because people requested it. The idea is that if an editor uses a convert with a bad parameter, the editor should be given a chance to see the problem with an in-your-face error message, but readers should not stumble over the defacement if the page is saved with the error. At least one other widely used template does the same. Editors often adjust convert parameters in a big wiki-gnoming edit, and sometimes they mess it up but do not notice the problem in the middle of a big article. There is not much point in having an ugly message visible, and the tracking category means the problem is fixed with a couple of days. What is the actual problem with ispreview? Johnuniq (talk) 22:39, 23 July 2017 (UTC)
The actual problem here was that the output of the template differed so that {{#iferror:}} worked in preview but not when the page was saved. In general, I'd say the point of previewing is that it should as much as possible show what the page is going to look like when saved, not something gratuitously different no matter how much some people might want it to be gratuitously different for their specific use case. Anomie 12:28, 24 July 2017 (UTC)
@Spike and PrimeHunter: I proposed a change to Module:Convert/text at Template talk:Convert#Add <span_class="error"><span/> to cvt_format and cvt_format2 that would add an empty span with class "error" to the blue link error messages to allow them to be detected by {{#iferror:}}. --Ahecht (TALK
) 17:22, 21 July 2017 (UTC)

Dead end analysis there anything around which shows how far links through to articles go before going nowhere? Thanks, My name isnotdave (talk/contribs) 10:55, 23 July 2017 (UTC)

Removing arrow from link

Is there a way to remove the little arrows from these two links in this box? they shouldn't be there...◂ ‎épine talk 15:50, 23 July 2017 (UTC)

{{Plain link}} uses this solution. Look at the wikicode of this comment. (((The Quixotic Potato))) (talk) 16:03, 23 July 2017 (UTC)
@The Quixotic Potato: LMAO, 👀 🌊 what you did there. Thanks!◂ ‎épine talk 16:15, 23 July 2017 (UTC)

Watchlist not being updated properly

Recently, some of the buttons on my watchlist aren't coming up blue according to pages I've visited. Even in instances where mine was the last edit, the button sometimes remains green. Dhtwiki (talk) 22:49, 23 July 2017 (UTC)

By "buttons", I assume you mean "bullets" (round in Vector, square in MonoBook). Does it get fixed if you reload the page (F5 in Firefox & Opera)? --Redrose64 🌹 (talk) 22:59, 23 July 2017 (UTC)
Yes, bullets. Thank you. The watchlist just came up error-free, but it hasn't been working flawlessly. I'll follow up if there are further errors. Dhtwiki (talk) 23:53, 23 July 2017 (UTC)

Varieties of criticism

Can someone explain why no table of contents appears in varieties of criticism? This is generally sub-optimal behavior (per WP:Accessibility) and a Ctrl+F for "notoc" doesn't appear to identify the offending wikicode. --Izno (talk) 23:45, 23 July 2017 (UTC)

@Izno:  Works for me (see image right).
Works for me
. — xaosflux Talk 00:36, 24 July 2017 (UTC)
@Xaosflux: I'm not seeing it in Vector (works for me is probably not the best response for a non-default skin :D). --Izno (talk) 00:44, 24 July 2017 (UTC)
@Xaosflux: re-sign and ping. --Izno (talk) 00:45, 24 July 2017 (UTC)
The TOC was missing for me but appeared when I purged the page. PrimeHunter (talk) 00:56, 24 July 2017 (UTC)
@Izno: I don't recall ever actually "changing" my skin, so monobook is my default ;) — xaosflux Talk 01:26, 24 July 2017 (UTC)
Xaosflux was created in 2005, when MonoBook was the default. Vector did not become available until 2010; initially it was opt-in for all users, later it became the default for new users but existing users were left with their existing skin setting. --Redrose64 🌹 (talk) 08:53, 24 July 2017 (UTC)

See also #Rendering problems higher up on the page. This is ticket phab:T168040. —TheDJ (talkcontribs) 07:25, 24 July 2017 (UTC)

Exceedingly frustrating mobile view

I am stuck owing to internet access reasons accessing Wikipedia via the mobile site. This is a substandard and very frustrating experience. As some of the key features are missing, including on talk pages the "add topic" button, tables of contents on talk pages, I can't access my sandbox, nor full settings. I can't even seem to escape t his experience as I am automatically redirected here. Any ideas how to fix this?? Frustrated, Tom (LT) (talk) 12:34, 24 July 2017 (UTC)

@Tom (LT): If you scroll to the bottom of any Wikipedia page on the mobile site, there is a link that says "desktop". Click it, and your device should redirect to the desktop version of Wikipedia. --Ahecht (TALK
) 14:24, 24 July 2017 (UTC)



How long should it take for a change in a small template to update all articles. Special:WhatLinksHere/Tabarz does not reflect the change at Template:Cities and towns in Gotha (district) six days ago. Agathoclea (talk) 06:21, 24 July 2017 (UTC)

Not even an edit of an article makes a difference. Agathoclea (talk) 08:38, 24 July 2017 (UTC)
Try fixing {{Imagemap Germany district GTH}}, which also links there. עוד מישהו Od Mishehu 08:46, 24 July 2017 (UTC)
Thanks that was the hickup. Agathoclea (talk) 09:03, 24 July 2017 (UTC)

Tech News: 2017-30

15:57, 24 July 2017 (UTC)

How to link to a user talk page conversation?

I often want to link to a conversation on a user's talk page in a way that's future-proof. The problem is that people archive their talk pages, so the links go stale. I can use the Permanent Link tool, but that suffers from the problem that you get a link to a specific point in time, so the rest of the conversation, that happens after you create the link, isn't visible. Is there some better way to do this that gets me the best of both worlds? -- RoySmith (talk) 00:01, 25 July 2017 (UTC)

There is no way to achieve what you want. One of the old archive bots used to fix incoming links when it archived a talk page, although the overhead of that seems excessive. Quite a few people just delete stuff from their talk so only a permalink would work. Johnuniq (talk) 00:59, 25 July 2017 (UTC)
What you would needs is WP:FLOW, which was strongly rejected due to various reasons on English Wikipedia. Some of the other languages, and the mediawiki wiki use it. — xaosflux Talk 01:11, 25 July 2017 (UTC)
You can use the permalink tool when the conversation is over. That should work unless the revision is deleted (or some other obscure thing that I don't know about). – Jonesey95 (talk) 02:54, 25 July 2017 (UTC)
ClueBot III (talk · contribs) still fixes incoming links when it moves threads to archive (for example, this set of edits is all for the archiving of a single thread, see in particular the two in the middle), but it doesn't seem to run as often as it should. lowercase sigmabot III (talk · contribs) doesn't make such fixes, but that's probably because the various MiszaBots didn't either. --Redrose64 🌹 (talk) 09:05, 25 July 2017 (UTC)

Recovering page history of a previous deleted version of a page

I asked User:Orangemike (conversation here) to undelete the old deleted version of Banc de Binary, an article that was subsequently recreated, because Wikipedia's editing of it was in the news and was raised in policy debate at WP:NCORP. He did this, at Talk:Banc de Binary/Deleted version (the strange name was my idea). But ... he didn't get an article history, seemed unsure how to do it (despite being one of the most experienced admins around) and we really need that to have a forensic sense of how well Wikipedia responded to the situation. Can someone explain what the issues are with this and whether there is a good way to do it properly? Perhaps demonstrate using this undeleted version as an example? I am alarmed because the old version of a page like this should have attribution to be CC-BY licensed -- so the restored version may be a copyvio without the history, and if the current draft of any article has been recreated from the deleted version (rightly or wrongly) then it could have issues if this isn't doable, and developer work may be needed to make it possible. Wnt (talk) 00:36, 25 July 2017 (UTC)

Have you tried WP:REFUND, Wnt? Someone can help you out there. --George Ho (talk) 00:46, 25 July 2017 (UTC)
I can think of two ways. First is to just undelete the deleted entries. There are seven from before the May 2013 creation of the current article. Second, is delete the current article, undelete the seven entires and move them. Then undelete the current article. I'm not sure that the second one would work correctly. -CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq —Preceding undated comment added 00:52, 25 July 2017 (UTC)
I've done it. The page history got moved around a bit, so CBW's instructions wouldn't exactly apply. Nyttend (talk) 03:24, 25 July 2017 (UTC)
An ordinary deletion would not have been a problem; but in this case, there was userfication and other complications. --Orange Mike | Talk 03:26, 26 July 2017 (UTC)

Unasked for adding of non-breaking spaces

I went to correct two spelling errors (aircrafts to aircraft) at Bombing of Gorky in World War II. Why then did it add all the non-breaking spaces? That's not the sort of thing I want to see especially when my edit summary says "Spelling". CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 01:10, 25 July 2017 (UTC)

This is a regular question here. You are using WikEd, which, on edit, automatically converts existing invisible non-breaking spaces to their HTML entity names. You didn't add them: they were already there.
Is there a WP:WIKEDNBSP that can be linked to in the future, anyone else? --Izno (talk) 01:47, 25 July 2017 (UTC)
So I am. Strange I never saw it do that before. Thanks. CambridgeBayWeather, Uqaqtuq (talk), Sunasuttuq 09:25, 25 July 2017 (UTC)
@WhatamIdoing: Since I know you received a similar question, I created the above shortcut to the wikEd help page. --Izno (talk) 12:05, 25 July 2017 (UTC)
I suppose that explains why every once in a while I see a post on a page like this that also changes NBSP characters in others' signatures into entity references. Anomie 15:11, 25 July 2017 (UTC)

Hover over link doesn't suppress material that has been revision deleted

Hi. This morning I revision deleted a number of very abusive edit summaries from an editor who is now indefinitely blocked. Now if I view the normal history for the article, they appear greyed out and struck, although as an admin I can still choose the diff and then choose to view the edit summary if I wish, a matter of 3 or 4 more clicks. However, if I hover over the "hist" link on the relevant article on my watchlist, it shows the edit summaries immediately as they were before they were deleted - i.e. not greyed out and struck. Question: is this the same for all editors, or simply me as an admin? Because if the former, there's obviously a major problem... Thanks, Black Kite (talk) 14:32, 25 July 2017 (UTC)

Popups is apparently smart enough to know you have permission to see it. When I look at an edit where the edit summary was revdel'd, I can see the edit summary when I hover over it in popups, but when I log in using User:Floquensock instead, popups doesn't display it anymore. --Floquenbeam (talk) 14:40, 25 July 2017 (UTC)
Ah, all good then! Black Kite (talk) 17:52, 25 July 2017 (UTC)


Hi, all, is there a way to see what this setting is on live enwiki? My sourcediving skills are not the best in the context of Mediawiki; I see that in DefaultSettings.php it's set to 1 and CommonSettings.php doesn't touch it (as far as I can tell), but I can't seem to find a way to look at LocalSettings.php (whether because it'd be a security risk or just because the aforementioned sourcediving skills). I don't think 1 is actually correct, but I can't say for sure. Anyone know? Writ Keeper  20:26, 25 July 2017 (UTC)

Still 1:
[email protected]:~$ mwscript eval.php enwiki
> var_dump($wgAPIMaxUncachedDiffs);
Max Semenik (talk) 20:38, 25 July 2017 (UTC)
Ugh. Okay, thanks. Writ Keeper  20:59, 25 July 2017 (UTC)
Just as a minor note: LocalSettings is just a stub we generate automatically that includes CommonSettings and friends. There's nothing secret about it--it's just in a weird spot in the source tree and doesn't contain any actual configuration so it's not available via noc. It's weird, I know. You can see that stub file where it's generated by a scap plugin called prep. FACE WITH TEARS OF JOY [u+1F602] 23:20, 25 July 2017 (UTC)
Note too that everything that $wgAPIMaxUncachedDiffs affects is deprecated. action=compare should be used instead. Anomie 00:46, 26 July 2017 (UTC)

Template incorrectly categorizing articles as templates

Cross-post: Seeking feedback at: Wikipedia talk:WikiProject Templates#Organize template incorrectly categorizing mainspace articles as cleanup templates. Mathglot (talk) 06:46, 26 July 2017 (UTC)

Now fixed, thanks to John of Reading. Mathglot (talk) 07:26, 26 July 2017 (UTC)

TOC not shown

On some pages such as August 1973, the TOC is not shown even though the page has more than 4 sections and neither it nor any of its transcluded templates have "__NOTOC__" in their text. I have already fixed this one with a null edit. Are there any others that need to be fixed? GeoffreyT2000 (talk, contribs) 18:22, 26 July 2017 (UTC)

This is probably related to my issue at #Varieties of criticism. --Izno (talk) 18:43, 26 July 2017 (UTC)
That is T168040 mentioned at #Rendering problems above, and in an earlier archive. A fix will occur in due course. Meanwhile, either ignore it or purge the page. Johnuniq (talk) 04:13, 27 July 2017 (UTC)

TLS Handshake

I have recently noticed the performance of a TLS handshake when Wikipedia pages load, and subsequently, a noticeable increase in loading times and secure connection failures. Currently, Wikipedia is practically inaccessible to me. Is this handshake something new, and could it explain the performance issue I am experiencing?--John Cline (talk) 23:29, 26 July 2017 (UTC)

TLS handshakes are a standard part of TLS--it's what provides provides the Secure in HTTPS. We've been using them for years and you routinely use them on any site that provides a secure version. On any semi-not-ancient hardware, performance of this is typically not an issue--perhaps it's worth reporting in Phabricator so ops can have a look (and possibly ask you for some more debug info). FACE WITH TEARS OF JOY [u+1F602] 02:35, 27 July 2017 (UTC)
What browser? Is it a reasonably recent version (no more than six months old)? What do you see exactly? It is likely that a Google search would find discussions of the problem, and it is unlikely to be related to Wikipedia. Johnuniq (talk) 04:09, 27 July 2017 (UTC)
Thanks, both of you. The link was helpful as well. My hardware may well be outmoded, (it does not bluetooth after all), and I've heard of an exodus from Firefox for similar cause, (which I currently use). I am prepared to assume the problems I am experiencing originate on my end; I'll see about bringing myself up-to-date.
Regarding specifics, my Firefox browser was stalling on a command line that said, "performing TLS handshake with en-Wikipedia", then waiting on", and then a time-out screen would appear, saying: "Secure Connection Failed". This would happen 4 out of each 5 attempts with the 5th attempt loading, or partially loading the given page.
The situation has since improved to an inverted end; 4 of 5 pages load with every 5th timing out. The latter is a trade-off I can live with and it is likely a problem whose solution resides in my hand. Thanks again.--John Cline (talk) 05:13, 27 July 2017 (UTC)
Put the following into Google: firefox "performing TLS handshake"
For example July 24th, 2017. There will be some relatively simple solution. Johnuniq (talk) 06:17, 27 July 2017 (UTC)


A question has come up lately about the possibility of restricting users' use of the Cat-a-Lot script, which I don't believe has been considered before. The immediate problem: it's a js-script that's not hosted over here, but rather on Wikimedia Commons, and I'm not sure how much local control there is over it around here. I've noticed that when I use it, it sometimes does peculiar things - see here for an example of the sort of thing I'm talking about - and I don't know that there's a way for it to be customized locally to Wikipedia's needs. Given that, I'm not sure there's currently a way to introduce controls short of manual deletion of the script from users' pages. Or wholesale disabling of the script, which would be a pity; while it's frighteningly powerful, it does sometimes have its uses.

Is it possible to take over local control of the tool, or is that not feasible the way things stand? Don't want to propose anything without even being aware of what's possible. --Ser Amantio di NicolaoChe dicono a Signa?Lo dicono a Signa. 01:34, 27 July 2017 (UTC)

Commons doesn't have stubs, so commons scripts need not be aware of stub tags nor the need for special treatment of them. --Redrose64 🌹 (talk) 07:59, 27 July 2017 (UTC)
The background to this request comes from the incident at Wikipedia:Administrators' noticeboard/Archive290#Mass cat-a-lot reversion of User:Skr15081997 required, when an editor used cat-a-lot to mass copy a huge number of articles into the parent directory. A discussion was raised there and on my talk page about whether use of cat-a-lot should be approved (like AWB), or even if it were technically possible. Hence the question here - there's no point proposing an approval system if it's not technically possible to implement it. Optimist on the run (talk) 16:15, 27 July 2017 (UTC)
Caveat: I'm not technically competent to answer this question.
But I can't see any way to stop me from using whatever Javascript I wanted. For example: Let's say that we modify the script to use the AWB mechanism, which checks to make sure that your username is on an 'approved' list. Mine's not on the list, right? But I could bypass that by copying the (public) Javascript, deleting the "check to make sure your username is on an approved list" lines, and running my "jailbroken" copy in my userspace. WhatamIdoing (talk) 16:19, 27 July 2017 (UTC)
Also, I've been around for 12 years and I WORKED with stubs years ago. I would have made the same changes. An approval system is not gonna help with a conceptually arbitrary rule like this. I'm sure it will annoy many of our gnomes, but it's a wiki, not perfection. —TheDJ (talkcontribs) 18:41, 27 July 2017 (UTC)

Problem with https links to wsj

xaosflux Talk 03:44, 27 July 2017 (UTC)

Is my edit really awaiting pending revision?

I mean, I've got over 170,000 edits, that should be enough, surely? So I'm misunderstanding something about this. Doug Weller talk 15:06, 27 July 2017 (UTC)

@Doug Weller: Someone needs to accept, or reject, the edit made by Smooth alligator. Until such time as that edit has been deemed appropriate, your edit will stand as unreviewed. --Izno (talk) 15:19, 27 July 2017 (UTC)
Done, the previous unreviewed edit was an uncontroversial link improvement. GermanJoe (talk) 15:35, 27 July 2017 (UTC)
Thanks all. Doug Weller talk 16:09, 27 July 2017 (UTC)
  • Just to be clear, Doug Weller, your edit didn't require review, but as long as any review-required edit upstream from yours was still awaiting review, your edit had to remain hidden. Why doesn't someone give D.W. pending changes reviewer privileges? They gave it to me, and if they'll give it to me they'll give it to anyone, I guess. EEng 16:29, 27 July 2017 (UTC)
Wait a minute, D.W., you're an admin. Never mind. EEng 16:31, 27 July 2017 (UTC)
@EEng: Lol. That makes sense now that I think about it. I should have dealt with the other ones first. Doug Weller talk 17:50, 27 July 2017 (UTC)

File:Dunes and Ripples in Nili Patera.jpg

When I am logged out, the File:Dunes and Ripples in Nili Patera.jpg does not appear to be linked to the article Nili Patera dune field, although it is one of the article files. On the file page, I get the message: "File usage No pages on the English Wikipedia link to this file. (Pages on other projects are not listed.)" But when I am logged in, the file usage statement is correct: "File usage The following pages on the English Wikipedia link to this file Nili Patera dune field (pages on other projects are not listed)". I tried the other pictures in the article and they don't have this problem. Is there any explanation for this? Dr. K. 22:37, 27 July 2017 (UTC)

It is showing now that I added ?action=purge to the URL and purged the page. Johnuniq (talk) 22:46, 27 July 2017 (UTC)
Thank you very much John. It works now that I followed your instruction. Take care. Dr. K. 22:52, 27 July 2017 (UTC)

A technical category issue

While editing an article, I noticed a red linked category which I clicked on. The non-existent category was well populated, so I went ahead and created the category with a "Maintenance template" tag only. The category is Category:Wikipedia articles with SNAC-ID identifiers. Don't know anything about it or why the category didn't previously exist even though it was being populated by some template. Safiel (talk) 04:59, 28 July 2017 (UTC)

@Safiel: This was caused by additions to Module:Authority control just a few hours ago. -- John of Reading (talk) 06:14, 28 July 2017 (UTC)


Add archives to ALL URLs, dead or alive

So as many people are aware, InternetArchiveBot has been a major help to combating link rot in that it continuously and actively attempts to add archives to any URL that it sees as dead, or is tagged as dead. This really makes sure all of our sources continue to remain accessible and helps with verifiability. However there are those moments, when archives were not created in time and as such are unavailable when the original URL goes down. Having the bot add archives not only allows us users to make sure that it has an archive in case of possible link rot, but for those URLs missing an archive, allows us to take the opportunity to archive them elsewhere before possible link rot and add them, thus also letting IABot know that an archive exists, or vice versa.

So how would this work? Quite simple. Most sources use the CS1 and/or CS2 citation templates, which has the "deadurl" parameter. When set to "no", archive URLs are not made clickable on the rendered page, but when set to "yes" or when the parameter is omitted entirely, it will make the title link to the archive version instead. This allows users that detect dead urls to only have to flip the switch to enable the archived version. The bot will set deadurl=no to all cite templates it adds archives to that are still working, and of course it will set deadurl=yes to the dead ones as it does now. The side effect of this is, the non-cite template references that use external links will have {{Webarchive}} attached to them if it can't convert the link to a cite template.

Thoughts?—CYBERPOWER (Chat) 18:22, 3 July 2017 (UTC)

About cs1|2 and |dead-url=no: not quite true what you said. The archive is clickable, but you don't get to it through the source's title. To get to the archived source, click the word 'Archived':
{{cite web |title=Title |url= |archive-url= |archive-date=2017-01-01 |dead-url=no}}
"Title". Archived from the original on 2017-01-01. 
There are cases that are unclickable but for that to happen, the value assigned to |dead-url= must be one of unfit, usurped, or the bot-only value bot: unknown.
{{cite web |title=Title |url= |archive-url= |archive-date=2017-01-01 |dead-url=unfit}}
"Title". Archived from the original on 2017-01-01. 
The default state of |dead-url= (when omitted or not assigned a value) is yes so adding |dead-url=yes may not be required.
Trappist the monk (talk) 18:41, 3 July 2017 (UTC)
  • Oppose – Systematic archiving would create needless bloat in articles, and would drown editors and readers alike. Sources that actually need archiving would also become harder to identify at a glance. See the disastrous effect when a well-meaning editor applied IABot-assisted archiving of hundreds of sources at Barack Obama and Donald Trump. — JFG talk 12:32, 7 July 2017 (UTC)
  • Support: Systematic archiving of all cited webs is good and very desirable. Linkrot will eventually happen to most urls, and there is no advantage to postponing web-archiving and citing the copied url. Among other supporting arguments, I point to three:
    • Wikipedia rules plainly state that: Editors are encouraged to add an archive link as a part of each citation (Wikipedia:Link rot)
    • Citing sources and, and making those citations as complete as possible is central to Verifiability and having high quality and durable articles in wikipedia.
    • Bloating is not an issue with referencing as Wikipedia rules on optimal article sizes, say that "These rules of thumb [on article size limit] apply only to readable prose (found by counting the words (...)) and not to wiki markup size.".
      • Furthermore, expanding existing citations in any given article to include webarchive in them has a zero effect on the actual content and readability of the article. (talk) user:Al83tito 17:25 10 July 2017 (UTC)
There is no "rule" it's an wp:essay. It creates a tremendous problem with maintenance to deal with that many archive links as archive links also suffer from link rot and are considerably more resource intensive to fix from normal URLs. It also locks in an archive URL that might be working today but could stop working tomorrow. The archive is best retrieved when needed to avoid link rot. IABot is already able to fix links when they die so there is no great gain by doing it proactive but there are downsides. -- GreenC 20:04, 10 July 2017 (UTC)
  • Support, bloated or not Wikipedia should be durable and it's bad enough that plenty of articles can't be verified because of link rot today, tomorrow it'll be (even) worse. -- (talk) 05:40, 14 July 2017 (UTC)
  • Oppose I am dissatisfied with the communication policy around InternetArchiveBot. Comments on the bot go to phabricator instead of typical on-wiki discussion. This is an amazing, constructive highly valuable Wikipedia and Internet Archive project which I like a lot. At the same time I feel that the project has some management problems which need to be addressed because it discourages the Wikipedia standard of discourse (including having a talk page). I would like to see this project (1) establish a talk page (2) host some public conversations (3) get a demonstration of support. This is a project which many people like, including me, but I do object to the precedent it is establishing of operating without discussion. I only intend to ask for 2-3 hours of labor in community engagement. I do not wish to distract the project organizers with unnecessary community discussion. I do not anticipate that much community discussion is necessary. Blue Rasberry (talk) 18:43, 21 July 2017 (UTC)
  • Oppose I'm entirely fine with IABot creating such links pre-emptively and automatically, but pre-emptively and automatically adding them to duplicate stable links that aren't in danger of become rotted and spamming them on our articles is detrimental. I'm fine leaving this to the discretion of whoever activates the bot, but like all semi-automated things, the editor becomes responsible for the bot's edits, and there needs to be way to rescind access if the bot is abused.Headbomb {t · c · p · b} 21:55, 21 July 2017 (UTC)

Automatic column mode for references element

Recently it became possible for <references /> to automatically use responsive columns when there are more than 10 references in the generated list. Currently this behaviour is an opt-in mode (<references responsive="1"/>). The opt-in was intentional as throughout Wikimedia, we had many templates that already relied on pre-existing behaviour. Recently I prepared {{Reflist}}, to be able to deal with both situations. As such it would now be possible, to switch the default of <references />, without influencing {{Reflist}}. I think a default column mode is easier for most situations that do not require {{Reflist}} and I want to propose to switch the default of <references /> to automatic responsive columns. So to summarise:

  1. Currently <references /> never has columns
  2. When we switch the default, <references /> will have columns if there are more than 10 references (30em wide, same size as most Reflist usages).
  3. This switch of the default will not influence {{Reflist}}, which can be used for changing column width and a few more advanced features.
  4. It will be possible to disable these columns by using <references responsive="0" />.

If there is agreement, then we can file a phabricator bug report to make the change. —TheDJ (talkcontribs) 09:15, 13 July 2017 (UTC)

  • Yes please! --Izno (talk) 12:21, 13 July 2017 (UTC)
  • It would be great! --Jennica / talk 14:52, 13 July 2017 (UTC)
  • The change reduces the size of the text. This change was not mentioned in the description of this change. I prefer that the type size match the body of the article. Jc3s5h (talk) 15:39, 13 July 2017 (UTC)
    • @Jc3s5h: I'm not sure how you reached that conclusion, but I cannot confirm it. All references lists have a font-size of 90%. It has been like that since 2011 as far as I can tell. Can you please give examples, and information regarding the skin you use perhaps ?—TheDJ (talkcontribs) 15:55, 13 July 2017 (UTC)
      • When I tried to reproduce the problem, I realized the article I used as an example has several reference-related subheadings and I had been mixed up about which section I changed (in preview mode only, of course). Jc3s5h (talk) 16:12, 13 July 2017 (UTC)
  • I agree with this change. The columns seem to be just slightly too wide at the moment, but maybe this is deliberate. Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me
    05:58, 14 July 2017 (UTC)
  • I support this change. There will no doubt be some minor unintended consequences and some necessary cleanup to a few articles, but that is the price of progress. – Jonesey95 (talk) 16:19, 14 July 2017 (UTC)
  • Mild oppose. Personally, I prefer the single column style, and think that the change to 2 column that is often made is rarely an improvement. Making it the default will mean this is done with little thought far too widely. If this is to be done, the threshold of 10 is much too low, 30 is about right, at the lowest. DES (talk)DESiegel Contribs 14:44, 15 July 2017 (UTC)
  • This sounds like a nice improvement. I support making it the default. Kaldari (talk) 18:40, 15 July 2017 (UTC)
  • I kind of oppose this. As {{reflist}} already does this, changing <references /> too would make creating a single column ref list needlessly complicated. DaßWölf 21:53, 15 July 2017 (UTC)
  • Oppose. Multiple columns are fine for simple citations, but make it difficult to read long explanatory footnotes. In considering whether to use columns, and of what width, our first consideration should be what makes things easiest for the reader. That has to be done on a case-by-case basis rather than according to an arbitrary standard based on the number of citations. Ammodramus (talk) 16:55, 16 July 2017 (UTC)
    • @Ammodramus: You consider the case of NOT having columns for lists larger than 10 items to be more common than having columns ? I think we should cater to the largest group of users and to 'safe' defaults. I think that if we can have 90% of the cases right and only need to modify 10%, then that is better than the reverse for the casual editor right ? —TheDJ (talkcontribs) 10:17, 17 July 2017 (UTC)
  • Would support if the proposal is limited to two columns only. Even long citations / quotes are reasonably easy to read if in a two-column format. Is that what's intended by the proposal. K.e.coffman (talk) 21:20, 16 July 2017 (UTC)
    • The columns of the responsive column mode of the references tag, are the same as the most common setting for {{Reflist}}: 30em. The amount of columns depends on the width of your screen. —TheDJ (talkcontribs) 12:01, 17 July 2017 (UTC)
  • Oppose because we already have this with {{Reflist|}}. Why re-invent the wheel? What are the benefits of having two paths to get to the same place? Also, with today's screen proportions trending towards wider screens, three ref columns are being used more and more; so if this change were to take place, that capability should be available as well. I'd still oppose this, however, for the same reason as above. It's not a needed universal change, and we already have the way to do it. GenQuest "Talk to Me" 11:16, 17 July 2017 (UTC)
    • I see several errors in reasoning here. (1) The wheel is already reinvented, it just needs turning on. Our {{reflist}}'s multi-column support was liked so much it got added to the extension itself. (2) This change would use three columns on wide enough screens, it's more or less equivalent to {{reflist|30em}}, not {{reflist|2}}. (3) Two ways to do it already exist. The only thing this change changes is to make the default when "responsive" isn't specified in <references /> be <references responsive=1 /> rather than <references responsive=0 />. Anomie 12:14, 17 July 2017 (UTC)
      • Still not clear on there being a need for this. Users of reflist have pretty much moved away from using the column to the width parameters anyway. Doesn't this have the same effect as your #2 above? What, if any, are the differences? GenQuest "Talk to Me" 13:36, 17 July 2017 (UTC)
        • This form of arguing can also be inverted. Why would you want to keep a difference between two existing methods for the same purposes, now that we have the ability to not have this difference ? Is there a need for columns to begin with ? Well probably not, yet people still like using them. Is there a need to change the default ? Well no one will die if we don't, but if it's already the most common form, then why not align the default with that form and make the exception the more laborious process ? —TheDJ (talkcontribs) 13:52, 17 July 2017 (UTC)
          • Still doesn't answer the question. Why do we not just deprecate <references> and use the more powerful {{reflist}} ? GenQuest "Talk to Me" 16:05, 23 July 2017 (UTC)
            • Because {{reflist}} is, at heart, a wrapper for <references />. You can't deprecate the tag as it must be available for reflist to work. DES (talk)DESiegel Contribs 19:29, 23 July 2017 (UTC)
  • Support People generally like multiple columns, which is why {{reflist}} is so widely used. We may as well make it the default for a bare <references /> too, where it will use what is currently recommended as the multi-column setting in Template:Reflist/doc#Columns. Anomie 12:14, 17 July 2017 (UTC)
  • Support. There's no harm in doing so since automatically adding columns would actually reduce the amount of space that one has to scroll down. epicgenius (talk) 21:25, 17 July 2017 (UTC)
  • Support I ,like DESiege personally prefer single column, but I see from [[[[ that there is an easy way to turn this off. DGG ( talk ) 15:10, 18 July 2017 (UTC)
Hey, DGG. I see some typos and errors above in your post. Kind regards, --George Ho (talk) 11:31, 19 July 2017 (UTC)
(fixed, though that won;t fix the ping)--S Philbrick(Talk) 19:44, 27 July 2017 (UTC)

Edit filter to prevent Signature faking

I recently thought that it could be possible to fake signatures by copying the wikimarkup for an above signature and pasting it on to the end of their own text. Should there be an edit filter to protect from this? [Username Needed] 12:34, 14 July 2017 (UTC)

People often modify their signature in all sorts of ways, writing a filter to guard against that, won't be easy. —TheDJ (talkcontribs) 15:32, 14 July 2017 (UTC)
Maybe an edit-filter that guards against signatures which do not contain the editing user either as a link or as text? Regards SoWhy 15:48, 14 July 2017 (UTC)
Also common is to move threads around to a more appropriate location, in which case the editor copy/pastes multiple third-party messages and signatures together, either in the same page or to another page... —PaleoNeonate - 15:56, 14 July 2017 (UTC)
This isn't feasible without a high fail rate. I'm not an expert on abuse filters, but being a bot op, I can say this will be almost impossible to pull off. I would recommend a filter that trips if the user doesn't have a link to their user or user talk page in any edits on noticeboards, and talk pages. It's not a disallow, but asks the user to confirm the edit before continuing, asking them to sign with their username. The edit gets a tag if the confirmed edit is still missing a link. Then humans can patrol it.—CYBERPOWER (Chat) 16:00, 14 July 2017 (UTC)
Agreed, I can't think of any way to do this that wouldn't result in a useless number of false positives. Sam Walton (talk) 18:03, 22 July 2017 (UTC)
it could be possible to fake signatures - We don't expend resources on prevention of "possible" problems. Can you show evidence of a significant signature forging problem? ―Mandruss  16:11, 14 July 2017 (UTC)
The few instances that I remember seeing were usually mistakes (like one instance of an admin putting my signature on a message I didn't write after some revdel by another admin). Where this is not the case like in an AfD or other debate, it is usually discovered by other participants, because their watchlist and the history does not match what they see. What would be less likely to be detected promptly would be edits to old threads in unwatched archives or inactive discussions, however... —PaleoNeonate - 16:19, 14 July 2017 (UTC)
Ok, that's not what I would call a significant problem. The first case is extremely infrequent, is easily discovered and corrected with minor disruption, and provides useful information about the editor who committed the forgery. The second case is still hypothetical (again, real problems only, please) and would be largely inconsequential if it occurred. Perhaps you agree, I'm not sure. ―Mandruss  16:37, 14 July 2017 (UTC)
Yes, I agree. —PaleoNeonate - 23:03, 21 July 2017 (UTC)
  • This reminds me of another issue, despite WP:SIGPROB, possibly because it is only guideline, a number of editors have a signature showing another name. {{displaytitle}} detects when the displayed name does not match the signature and it would be easy to ensure that signatures match editor names as well. On the other hand, because of the existing practice, if this was suddenly enforced a number of users using strange names may need to rename their account... —PaleoNeonate - 16:25, 14 July 2017 (UTC)
  • We do have an ongoing issue with people leaving unsigned comments and others creating signatures for them, I'm not convinced we have an issue of people faking each others signatures - even the proposer seems to imply it as a possible problem rather than a real one. If it actually is happening we can block people for disruptive editing - no new policy is required. Before considering an edit filter we need to establish that this is common enough to merit an edit filter - I'm not yet seeing a single dif demonstrating that this actually happens, let alone the multiple recent diffs needed to show it merits an edit filter. Remember each edit filter slows everything down a teensy bit, so they are only appropriate for problems that are known to be sizeable. ϢereSpielChequers 14:08, 19 July 2017 (UTC)
  • I don't see this as an existing problem that needs a solution. Killiondude (talk) 22:40, 21 July 2017 (UTC)
  • Forging of signatures does happen occasionally (example) and it's sometimes difficult to detect, for instance if it occurs in the middle of a succession of edits. – Uanfala 17:41, 22 July 2017 (UTC)

Guild or WikiProject of paid editors

Thanks for the feedback. Jytdog (talk) 05:17, 22 July 2017 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

(also posted at Jimbo's talk page and at WT:COI)

I want to ask - at a high and initial level, does anybody here oppose the formation of something like a "guild or WikiProject of paid editors", by paid editors? I have proposed this initially in three places, but I want to also float this balloon here, and if it doesn't get terminally shot down here, I want to go to work doing what I can to help them plan and form it, and then at some point bringing it to a community-wide forum to get validation before it would actually launch.

The notion here is to formalize and build on what is already going at Wikipedia:Statement on Wikipedia from participating communications firms, and there is some support among two of the key signatories there, to do this.

If you read self regulation you will see that many industries have a level of self-regulation. The American Bar Association is cited in that article; the ABA operates within the bounds of the law of course, but it has additional rules and ethics, and if you break them, the ABA will throw you out and you can't practice law. Same deal with practicing medicine - you have to be certified by various boards, that are run by the medical profession itself.

If we had something like a guild of paid editors here (again, formalizing what it is going with the Statement), people who are part of it would pledge to follow PAID (disclose, not edit directly, and follow the other policies and guidelines) and the members of the guild would a) watch each other, and b) watch non-members, and c) train new members. They would throw out people who violated PAID or who socked, etc. They would also never: refuse entry to someone who said they would follow the "rules"; never lobby for changes in policies or guidelines; never implement each other's edits; never advertise their services in WP or chase people here.

Outside of that they would be like other editors, and the guild would give them no special privileges.

The community and WMF could say to the public, "There are paid editors who violate WP's rules and are not members of the WP community, and many of them have been banned and have to lie just to write in Wikipedia - they should be avoided. There are paid editors who are members of the community in good standing; people in the Guild of Paid Editors are examples of that, as far as we know."

There are lots of ways this could go wrong if it is set up wrong (there always are) and of course in its execution, but there are many potential benefits.

The thing I am most interested in, is starting to influence the market for paid editing. The public has no idea that there are "white hat" paid editors who are different from "black hat" paid editors, and pretty much the only message that WMF and the editing community put out there, is "paid editing is bad." This leaves the market wide open, and it is kind of like Prohibition in the United States where the gangsters are flourishing. Which is kind of foolish. I am not saying that anybody should endorse paid editing but we should make it clear there are "good guys" and "bad guys".

We could point to the "Statement" now, but that is kind of loose not formal, and if the paid editors themselves form the Guild/WikiProject and invest in it working, paid editors in it will have more of a stake in keeping it clean. And we would all have something more substantial to point to as examples than "signatories of the statement" which is kind of flimsy, and I don't know how rigorous the signatories are in throwing people out who violate their pledges.

If this is effective, it will decrease the amount of undisclosed paid editing that happens from the demand side - from people making better choices if they choose to use a paid editor.

Again, just looking for initial buy-in or "blockers" (to use the WMF dev term) at this very initial stage of thinking. Jytdog (talk) 00:43, 15 July 2017 (UTC)

I think the idea is worth looking into. • • • Peter (Southwood) (talk): 05:13, 15 July 2017 (UTC)
One thing to consider is whether members of such a guild should be required to disclose their real identities: a) to the guild, and b) on Wikipedia. • • • Peter (Southwood) (talk): 05:19, 15 July 2017 (UTC)
Anything that encourages compliance with the COI guideline, utilizing carrots as well as sticks, is constructive. Figureofnine (talkcontribs) 12:10, 15 July 2017 (UTC)
And now the proposal is dead. The requirement is disclosure, not self doxxing. When you make the rules harder for being honest, you encourage dishonesty. --v/r - TP 14:46, 15 July 2017 (UTC)
TParis, I miss your point. Could you clarify? • • • Peter (Southwood) (talk): 15:12, 15 July 2017 (UTC)
User:Pbsouthwood Tparis is kind of emotional about these things and tends to over-react. I think his concern is that we make this onerous paid editors will not use it. In my view the main thing is that paid editors use a stable WP identity and don't sock. Because paid editors who follow PAID need to disclose their employer, many of them do disclose their RW identity in WP. (see signatories to the Statement, linked in the OP) but I don't see a need to place an extra burden on paid editors outside of what is already required in PAID. Jytdog (talk) 19:56, 15 July 2017 (UTC)
Strong oppose no way should the Wikipedia Community look like it's endorsing paid edited by hosting a special place for these people. We should form a Wiki project that searches out these people and looks over their work.--Moxy (talk) 17:18, 15 July 2017 (UTC)
WP:WikiProject Integrity was set up years ago to examine the work of paid editors. isaacl (talk) 17:36, 15 July 2017 (UTC)
User:Moxy, this is not about endorsing, really. I understand that there is a risk that people will take it that way, but it is not that. The points here briefly are:
1) paid editing is never going away
2) There actually are "white hat" paid editors and "black hat" paid editors, but the public doesn't know this.
3) If we were to educate the public, this would do a lot to dry up the market for black hat paid editors
4) As part of that, we need something to point to, as "white hat" -- the "guild" would be people who say they follow PAID and the other guidelines and have not been indeffed. In other words as far as we know (always, "as far as we know"), the members are paid editors in good standing. This is essential for communicating to the public
5) there would be a bunch of other benefits to the self-regulation and having a centralized location for dealing with certain aspects of paid editing (e.g maybe listing all articles worked on by legit paid editors in one place). There are lots of things we could do with it if it were up and running.
I hope that all makes sense. But this is very much about dealing with the reality that paid editing is never going away, and thinking about strategies to manage the market for it. Jytdog (talk) 19:51, 15 July 2017 (UTC)
Just wondering, Jytdog. If the Guild won't work at Wikipedia, why not at Meta-wiki instead? They might form a User Group, seen at meta:Category:Wikimedia User Groups. --George Ho (talk) 18:48, 15 July 2017 (UTC)
I am not convinced that it won't work in WP. There will be turbulence getting there, but that is not unexpected. But meta could be an option, sure. Jytdog (talk) 19:51, 15 July 2017 (UTC)
I don't see why such a thing could not be done off-wiki, with a Facebook group or the like. I don't think such a thing belongs on the project. bd2412 T 22:42, 15 July 2017 (UTC)
  • Strong oppose - Sorry, Jytdog, but the fact that "paid editing is not going away" is not a reason to give it the imprimatur of our approval, any more than the fact that socking isn't going away is any reason to stop blocking socks and their masters. Beyond My Ken (talk) 20:34, 15 July 2017 (UTC)
User:Beyond My Ken This is not giving it "approval" and it is disappointing to hear this framed that way. Paid editors who follow PAID (and the other PaG of course) are members of the community in good standing. There is no argument against that, that you or anyone else can make. Let me come at this from a different direction -- you didn't !vote at the MfD on the Statement. How would you have !voted, if you had, why? Jytdog (talk) 21:08, 15 July 2017 (UTC)
I disagree, allowing such a guild to be formed would indeed give tacit approval to their efforts.
Personally, I am opposed to paid editing in any way, shape, or form. The WMF's most recent pronunciation on it tip-toed right up to the line of banning it altogether, and I have no idea why they didn't bite the bullet and do the deed. In any case, paid editing, whether they adhere to WP:PAID or not, is detrimental to our project, as we don't really have the resources to police their efforts properly -- hell, we can barely keep up with outright vandalism, and sock puppets will remain uncontrollable as long as (not the WMF, since other language wikis have more stringent rules) continues to stick its head in the sand and disallow "fishing expeditions" when experienced editors smell something rotten and report it, only to be told that an overriding concern for privacy (ha!) is more important. Well, that's bullshit, and so is this. Yes, I want paid editors to be pariahs, and I will oppose anything which will tend to integrate them into the community, whether they follow WP:PAID or not. If that's harsh, well, tough, they shouldn't be attempting to sully the integrity of our project with their PR. Beyond My Ken (talk) 21:26, 15 July 2017 (UTC)
User:Beyond My Ken taking a moral stance "against paid editing" is like taking a moral stance against drinking alcohol. People feel how they feel about it, but we as a society came to realize people are going to drink, and trying to stop it is pointless. So we regulate it. Likewise, we put PAID in place, but given the nature of this place it is easy for bad faith people to just ignore it. But there are people who follow PAID and we are shooting ourselves in the foot by not acknowledging that. We need to let the public know that good faith PAID editors exist, and we can dry up the market for bad faith paid editors by establishing something more solid for good faith PAID editors to inhabit and maintain - this guild or WikiProject. The moral absolutism is not helpful. We need to move past that by now. This is a strategy to influence the market that works on a bigger scale than the whack-a-mole of catching individuals. (I still do a lot of that work; it needs to keep going, of course). But please do hear me - I am not offering this lightly, and it comes with a lot of thought. So please, put away the emotion. Please. Jytdog (talk) 22:19, 15 July 2017 (UTC)
Your comparison to Prohibition is silly, frankly, as what paid editors are doing is a job, and their employment is damaging the encyclopedia I've spent a lot of time and effort on improving, and don't wish to see harmed. I fully understand that you have put a lot of thought into this, and I accept that you offer it in total good faith -- I would expect nothing less from an editor such as yourself -- but that doesn't make it any better of an idea. You say that it will "sway the market", and I say that it will throw the doors of the market wide open and make paid editing even less subject to control than it is now, as more and more people realize that they can get away with pure promotionalism and swamp our already meager ability to police it. I ask you to believe that this is a fully rational, well thought out stance which has little, if anything to do with "emotionalism". You asked for opinions on your idea, and this is my opinion: it is a bad idea. Beyond My Ken (talk) 22:33, 15 July 2017 (UTC)
The point of the Prohibition metaphor, is that doing what we have been doing - namely saying with straight backs and all moral fiber in place, "Paid editing is bad!"..... does absolutely nothing to affect whether people buy the service and what is worse, leaves those purchasers mostly at the mercy of the "gangsters" (the people who sold alcohol lucratively during prohibition)
tThis reported article in the Entrepreneur (and I mean "reported" - the author went out and talked to people including the WMF) gives no inkling that there are paid editors who are "white hats" and follow policy and there are "black hats". That really, really bothered me. The reporter tried to find out the score and walked away clueless. And communicated that to her audience, which is probably one of our biggest sources of shitty paid articles (startups, business people looking for exposure). I want the public to know there are legitimate people offering paid editing services, who follow policy and that there is a "black market". And just like buying anything on the black market, you do so with risks that you don't take with legit enterprises.... and that using this black market is actually kind of filthy, and actually harms the public good that is WP. The harm comes from undisclosed paid editors who sock and lie and directly dump garbage in WP. It doesn't come from the legit paid editors. Jytdog (talk) 02:54, 18 July 2017 (UTC)
  • Oppose. I disagree about the "good" vs. "bad guys" dualism mentioned in the proposal. There are many shades of paid editing, and the best ones still contribute to a systemic bias in favor of recent products and companies, which would usually have gotten fairly decent coverage anyway -- at best we're talking about a "bad guys" vs. "more-or-less neutral guys". There is nothing Wikipedia would gain from letting them organise into an interest group and (attempt to) gain public validation with this. DaßWölf 21:38, 15 July 2017 (UTC)
  • Strong Oppose per BMK. I'd also disagree with Jytdog's statement that declaring your paid status makes you a community member in good standing. Following the TOU does not necessarily mean that. It means that you are not excluded from using the website by the legal owner of the servers. Spamming is still against community policy even if the paid editor has declared their affiliation, and there are paid users who spam even when this is declared and think that somehow their following the terms of use makes this okay. I fear if this proposal was adapted it would further the misconception that paid editors who declare and create otherwise unacceptable articles should be allowed to do so (even though I know that was the intent of the proposal). TonyBallioni (talk) 21:43, 15 July 2017 (UTC)
You are killing me and worse you are not responding to what I have actually written here. When I say "following PAID" - what that means (if you actually read PAID) is, that they don't edit directly, they don't hammer people at talk pages, etc. Paid editing is not banned (and is impossible to ban given how WP is structured); we need to take that seriously. We don't love paid editors, but you cannot say that they are not members of the community when they are following what PAID actually says. Please go slower in responding to this. Leaving the market as it is, means just more of the same. This is a strategy to influence the market and having something substantial like what is being proprosed will help better regulate paid editing internally and will give us something to point the public to. I arrived at this proposal after a lot of thought. Jytdog (talk) 22:08, 15 July 2017 (UTC)
It references the COI guideline and NOTSPAM as well, but the core of it is the terms of use, which is what is normally meant when people say following PAID. I have read the page, and while your interpretation of it is the one that is most in line with our other community policies beyond TOU, PAID itself does not go into that much detail. I stand by my comments above: making it so that there is a semi-official grouping within Wikipedia lends legitimacy to the idea that paid editors complying with the terms of use allows them to violate other community policies on promotion. I am not actually anti-paid editor as a whole, there are some good ones (people who get grants to do this is just one example). The majority, however, are going to be spammers, and that is easier to deal with when there isn't an organized group sanctioning it. TonyBallioni (talk) 22:33, 15 July 2017 (UTC)
I would say that people who get grants to edit Wikipedia might be a form of paid editing I could accept, if their grant is on the order of "to improve Wikipedia's coverage of X subject" and not in the form of "reverse the bias in Wikipedia regarding X subject", since people who edit with the intent of undoing a bias generally end up editing with the entirely opposite bias, instead of endeavoring to edit neutrally. We had the recent example of the teacher who assigned their students the task of showing how Trump's policies were going to damage the environment. I believe the teacher ended up being indef blocked after an extremely long community discussion that went across numerous venues. That wasn't a grant situation, but it could certainly be one, depending on who is giving out the grants and what their purpose is. Non-profits aren't required to be neutral, nor are academics, but we are -- and PR people are never neutral concerning the subjects they're paid to promote. I see no reason whatsoever to open our arms to them, welcome them to Wikipedia, and give them their own clubhouse. Beyond My Ken (talk) 23:20, 15 July 2017 (UTC)
  • Leaning oppose but could be persuaded. Jytdog, I think I agree most with the opinion expressed by Daß Wölf here but leaning towards BMK. I have to ask, what do we hope to have happen if such a guild existed? How would it improve the current situation? I think the argument for self-regulation is not persuading me because the undeclared paid's already exist so far outside the bounds of what is considered acceptable (even legally per ToS and US commercial laws vis-a-vis FTC disclosures for advertising). ☆ Bri (talk) 02:49, 16 July 2017 (UTC)

A few comments based on what has been said above:

  • It's unclear to me that the signatories to the statement from the communications firms in question are truly interested in proceeding with forming a support group of sorts, given that they haven't in the past three years since the statement was released. But if they do proceed, I'd as soon it have some presence within Wikipedia to make it easier to monitor (and apply sanctions against, if necessary).
  • Wikipedia editors and readers are sufficiently savvy to understand that the views given in any number of essays in Wikipedia space are not tacitly approved by the community. I trust they will understand this regarding any project pages used by a paid editor support group.
  • Paid editors who wish to ignore Wikipedia policies and guidelines will do so anyway, no matter what pages exist in Wikipedia. A support group page or the absence of one won't influence them.

As I mentioned elsewhere, I am not optimistic that there will be any self-policing of membership in a support group run by paid editors, so I personally don't see this as making much difference in helping identify paid editors who follow the rules versus those who don't (I know others do; let's agree to disagree). (Editors interested in sorting this out are welcome to help keep Wikipedia:WikiProject Integrity/Editor Registry up to date.) In the collaborative spirit of a wiki, though, I think it is desirable for editors to support each other in following policies and guidelines, and I can't see any grounds to prevent non-banned editors from doing so. isaacl (talk) 03:44, 16 July 2017 (UTC)

It all comes down to what the community wants. If they don't want such a guild to exist, and an RfC shows that, then the guild will not exist. There doesn't have to be a specific policy giving the community the authority to stop it from forming or shut it down if it already has. We make policy, policy doesn't make us. Beyond My Ken (talk) 05:31, 16 July 2017 (UTC)
Sure, any group can be prevented from forming on-wiki (can't stop a group from forming off-wiki, as I mentioned). As much as possible, though, I'd prefer to base opposition on general principles, rather than on personal preferences, or else every conversation will just be an "I like it" discussion. isaacl (talk) 13:15, 16 July 2017 (UTC)
  • Oppose. I've been scanning over this discussion of dealing with paid editing for the past few days. an interesting way to deal with it. Very interesting. A lateral way to deal with such situation. But no. The key priority is keeping transparency with paid editing, and enforcing transparency with paid editing. This path...seems lucrative, but any fear, uncertainty and doubt is very justifiable, if this system operated. That's not saying that I would not trust the editors, but we have seen that past (and current) works of black-hat editing have used very sophisticated means to hide their editing. another thing to care about. And it could all go very wrong if it isn't cared for properly. I support Count Iblis's idea on Wales' talk page. My name isnotdave (talk/contribs) 12:57, 16 July 2017 (UTC)
With apologies, nothing you wrote makes sense. This doesn't make anything less visible and there is no new "system". I don't know what you are reacting to, but it is not this proposal. Count Ibis's idea on Jimbo's talk page means committing fraud, as I wrote there, and neither the WMF nor the community will engage in illegal behavior. If you want to go commit crimes, that is your deal, of course. Jytdog (talk) 21:45, 16 July 2017 (UTC)
  • I've put this on Template:Centralized discussion. [13]. My name isnotdave (talk/contribs) 13:10, 16 July 2017 (UTC)
  • I oppose paid editors, period. Wikipedia should be neutral, and paid editors aren't . --NaBUru38 (talk) 15:11, 16 July 2017 (UTC)
  • Jytdog, maybe you can give this one or a few more days. So far, I see unanimous/huge opposition toward the proposal. I'll let you decide when you can withdraw this proposal. Okay? --George Ho (talk) 21:30, 16 July 2017 (UTC); Never mind; after seeing a few "support" votes below, I'll give it some appropriate time. --George Ho (talk) 03:46, 17 July 2017 (UTC)
The conversation at Jimbo's talk page is going quite differently, and likewise the one at WT:COI - both places where people have been considering and discussing these issues for a long time. This thread has a very weird jag of emotional, kneejerk reactions that I was somewhat worried about when I posted this. But it doesn't matter that people don't "like" paid editing or that they imagine that this would change in any way the underlying policy basis under which paid editing should happen. And almost no one who has opposed seems to be aware of the activities around the Wikipedia:Statement on Wikipedia from participating communications firms that this would merely formalize. This isn't facebook and we don't decide things on "like"s or people shooting from the hip. Please don't close this prematurely. Jytdog (talk) 21:45, 16 July 2017 (UTC)
  • It seems to me that we should oppose undisclosed paid editing with a vengeance. But paid editors who are conscientious about following WP:PAID can make useful contributions, albeit only on a short leash. We must never give the appearance of giving approval to spammers. But if some good-faith editors are willing to voluntarily, and perhaps unofficially, patrol for violations and give advice about best practices, that could be a good thing. Maybe we just don't need to put an official name on it. --Tryptofish (talk) 22:34, 16 July 2017 (UTC)
  • Possible support While I oppose all paid editing, to the extent that I would long ago have actually proposed a ban if there were a feasible way to accomplish this, there is no fair method of detection--all that a ban would do is drive all paid editing underground. Given that it exists, we need to provide incentives for paid editors to declare themselves. This project could assist this, by providing clear standards to those in the trade in their own language, and enable us to keep a better watch on the declared paid editors to ensure that they were actually following the rules. It would assist the critical effort that ought to be made by the foundation to make it unambiguously clear by its own PR efforts that all advertisements of paid editors that do not specifically say they will guarantee the terms of use are opposed to our terms of use, and in many cases pure scams--and to clarify that there is a legitimate alternative. I'm aware that the declared paid editors have a commercial interest in discouraging the undeclared, but it coincides with our own priorities.
But this has to be named and run like any other wikiproject , with open membership and general participation. No wikiproject is "official". I've joined a few wikiprojects whose work I do not necessarily approve of, to keep tabs on what they are doing; many others do likewise. DGG ( talk )
Oppose. This would encourage EVEN MORE unconstructive paid editing. KMF (talk) 00:31, 17 July 2017 (UTC)
  • Comment. The following is something I suggested years ago, so I offer it here again. I would like to see an organization that acts as a neutral go-between, so that Wikipedians can be paid for their work, but not directly by article subjects or their agents.
    Ideally, the Wikimedia Foundation would set up a team with an email address and website, or OTRS-type multiuser system, to which people wanting to pay for articles could apply, and to which all approved paid editors would have access. The Foundation's team would set the fees; choose the editors from a list of Wikipedians who sign up for the scheme (who must have a minimum number of years spent only as volunteers, and a minimum number of edits); pay those editors as independent contractors; and take a percentage of the fee for having organized the transaction. The Foundation's brief to the paid editors would be to write a neutral, policy-compliant article. The payers would have no say over which editor was given the job. Editors producing non-compliant articles would have their paid privileges removed.
    This system would remove or at least reduce the COI; would give people requesting articles somewhere to go; and would provide fees for editors who understand the policies and have the project's interests at heart. It would be win-win. The Foundation is unlikely to do this, but I wonder whether it could be persuaded to help set it up and maintain s close tie with it. Peteforsyth and WWB would be ideally placed to lead it. SarahSV (talk) 01:17, 17 July 2017 (UTC)
      • This is something I definitely would not support, and I think is a direct contradiction to our basic principles. It essentially amounts to turning us officially into a partially paid encyclopedia. I consider it similar to book review journals which review some books for free, but will also renew anythign else if you pay for it--the most prominent example I know of this is now no longer accepted as a source for WP. It would give the WMF every incentive to maximize the proportion of paid articles, if they received part of the fee. Even volunteer editors often have a great attachment to the articles they work on, and OWNership is an ever-present if subliminal temptation--if the same people did it for money it would be much intensified. It would also put the WMF in the position of "approving" editors, which essentially means interfering with our content, and that would destroy the site entirely. Not only should the WMF not do it, but it should never let itself be connected to any entity doing it. It might even affect our safe-harbor status in terms of copyright and libel. There have been sometimes problems with organizations giving the foundation grants to support Editors in Residence, and Editor in Residence sometimes getting too much involved with articles closely connected with the organization that pays them, but these are at least supposed to be highly reputable non-profits. Having current legitimate paid editors organize it would be the worst way of all--they would essentially be establishing a monopoly. DGG ( talk ) 02:54, 17 July 2017 (UTC)
  • Support per DGG. I've worked pretty deeply on the problem for years, with hundreds of blocks at SPI, hundreds of AFDs and if I've learned anything, it is that it is impossible to prove paid editing most of the time, so managing the problem is better than trying to pretend we could really "outlaw" it. Better to have a system of self-policing with input from the entire community, to have self-declaring, some ethical standards, and then perhaps they would be helpful in getting rid of the bad players, because they have a stake in keeping in the community's good graces as well. It would be the lesser of two evils, which is still the better choice. Dennis Brown - 02:26, 17 July 2017 (UTC)
  • Support. Paid editing is here to stay, so it's overall beneficial for Wikipedia to turn some of these edits to be useful. Paid editors who want their work to survive would benefit from this project, while those who refuse to abide by Wikipedia policies will continue to ignore this project. feminist 16:48, 17 July 2017 (UTC)
  • Comment I'd like to push back agains the idea that it is better to have this out in the open with an endorsed organization rather than shunned and underground simply because we aren't able to stop it that DGG has brought up. I disagree completely. As it stands, we are actually pretty good about picking out the clear spam and getting rid of it through one of the deletion processes. People hide the fact of their employment status and then when it is put up for deletion and they gang up, it is very easy to spot and we deal with it quite well when the editors are undeclared. We can't prove the paid editing, but we can get rid of the non-notable spam articles.
    Working with new pages, I've been on the end of several declared paid editing AfDs where the declared paid status of the editor is used as a way to lend legitimacy to the article outside of policy concerns about notability and promotionalism. The editor is free to game the process circulating press release stories and sometimes canvassing sympathetic !votes to the process. This is without a guild of paid editors, but based solely on the idea that compliance with the TOU is enough if someone is paid. A guild would make this mentality worse and I think would be a step towards the effective end of AfD as a useful process for dealing with articles created by paid accounts on the merits. I respect the work of Jytdog quite a lot and know that they have put a lot of thought into the process, but this is not a kneejerk reaction: before articles get to COIN, they pass through NPP. I really believe this would make the already tough task of dealing with paid editors who will pester you about why their non-notable article should be kept even worse and make our task there much more difficult. As I mentioned above, I am not against all paid editing, but I don't see how this would do anything other than make Wikipedia's processes easier to game. TonyBallioni (talk) 17:03, 17 July 2017 (UTC)
User:TonyBallioni - Thanks for your kind words. The goal here is to promote best practices for paid editors - disclosing and proposing, and not being a jerk and being pushy. There are paid editors who behave this way, and one of the key goals of having a WikiProject of paid editors would be to promote and propagate these best practices. Besides the goal of having something to point the public to (so they have somewhere to go, to choose a "white hat" editor instead of a "black hat"), there benefits internal to WP. Like that propagation of best best practices. Another thing I would want to do is have a page within the project where all articles where paid editors are working, are listed. Another benefit would be, that the kind of pushy paid editors you raise, could go there and ask for advice, and the more experienced ones would tell them that they are barking up the wrong tree. This would all happen out in the open, and self-interest among white hats would drive propagation of best practices. This would be so valuable. Jytdog (talk) 17:17, 17 July 2017 (UTC)
I certainly get the concept in theory. I just don't think it will work in implementation. The paid editor has both ethical and practical obligations to their client: ethical in that they're being paid to promote the clients interests on Wikipedia, so the client should always come first, practical in that they are getting paid for a task and even if you come up with some sort of code of professional standards that includes things such as being paid per hour and not based on articles being kept, it is still going to be bad for business to have articles deleted. Both of these motivations are very compelling motivators to find ways to game the system with the TOU. The really good PR people will find ways to game the system whether they are "white hat" or "black hat", and as DGG has pointed out in the past, in exceptionally rare circumstances they actually help us by producing a good and neutral article about a notable client. My fear is that this will help mediocre and bad PR professionals game Wikipedia more easily. TonyBallioni (talk) 17:42, 17 July 2017 (UTC)
Virtually all editors at Wikipedia have no idea how flooded we are with paid accounts. A few years ago, I estimated it was many thousands of accounts, many per person. Again, I worked here as admin on this problem at SPI and elsewhere. Paid editors games the system in part because it is easier to avoid the rules than follow them here. And there are so few admin compared to paid editors, it is laughable to think we can keep up. Putting some sunshine on paid editing, setting standards, allow them to use one account instead of having to sock (our TOU is problematic as well, but that is another story), and generally allowing them to do so in the open under the same rules that everyone follows, meaning the ones that edit ethically and follow WP:RS, WP:V and WP:N are more likely to be successful here and with their clients. The ones that don't won't be. It reminds me of the illegal nature of cannabis in the US. Everyone practically laughs about it, enforcement can't keep up, the real damage is less than the damage of over-policing it. Paid editing is a problem, but I would rather manage it than be foolish enough to think that we can "stop" it. We can't. I tried, really hard, I failed, it can't be stopped. It can be managed better. Not all paid editors are evil, but we need a system to manage and allow them to self-manage and point out the problem editors, as they will want to protect their own self interest by doing it right. Or we can continue the way we are, and for every sock we block, two more pop up. Dennis Brown - 19:15, 17 July 2017 (UTC)
  • Strong oppose (ec) Tomy Ballioni above raises excellent points. Paid editing is a problem that consumes vast amounts of volunteer time and resources, taking away from more worthwhile pursuits. Why? Because there is demand from people and companies for articles that they can utilize in their marketing. The fact that it "is going to happen anyway" is no reason to create a Wikiproject about it, co-equal with Wikiproject Biographies and dozens of other legitimate subjects, giving it an implicit blessing by the project. And no, the fact that there are "white hat" paid editors is no reason to uncork the champagne. There are advantages of abiding by the rules (Tony Ballioni raised a couple above that I hadn't thought of), and one can accomplish most paid editing objectives by doing so. There is no reason to feel such gratitude for compliant paid editors, whose activities require constant policing by other editors,, to give them their own project as a kind of reward and acknowledgement of their service to the project. Lastly, a Wikiproject Paid Editors would be a significant public relations gaffe, albeit one that doesn't dismay me as the WMF deserves a p.r. thrashing for its ambivalent attitude toward this problem. Coretheapple (talk) 17:08, 17 July 2017 (UTC)
the purpose of the project ought to be to keep watch over it. It would be a good place to monitor if they kept their promises, or were just making pious gestures of good will. Companies put considerable effort into accurate disclosure forms. Unlike the government, we cannot penalize them civillly or criminally if they aren't correct, but we can certainly expose them to public embarrassment. DGG ( talk ) 20:06, 17 July 2017 (UTC)
Then perhaps there should be a paid editors registry, so organized and named that it would provide no marketing advantage to paid editors. "Guild" or "Project" implies Wikipedia approval, and gives paid editors something real nice to put in their advertising. Wikipedia should not be helping paid editors, even so called "white hat" ones, get business. Coretheapple (talk) 21:02, 17 July 2017 (UTC)
I think that registry is one of the purposes of the proposal. I do not particularly want to help whiteh at paid editors, but if the only way we can get rid of the black hats is to extend some coperation to them under our own terms, it's a good bargain. I would even say a necessary bargain. DGG ( talk ) 05:37, 18 July 2017 (UTC)`
I'd suggest there's an underlying fallacy, which is that we can get rid of, or substantially reduce, the so-called "black hats" without taking a variety of steps not acceptable to WMF or the community. However, I think that they can be discouraged - while still retaining Wikipedia's integrity and brand identity - by creating a "consumers guide" for subjects of articles, a variation on ideas that TParis and Smallbones have made. Essentially, potential subjects of articles should get a scary portrait of what happens and how it can and often is a net negative to hire someone to put an article on Wikipedia. If they do so, they should look for various stringent and rarely-met characteristics. Or perhaps better use can be made of article requests. There are a whole bunch of things like that that can be done to attack the problem from the consumer end. For instance, WMF, instead of just responding to requests for comment from journalists, can be more proactive in waging p.r. wars against paid editing. Creating a "white hat project" undermines the rationale behind such an effort, which is that Wikipedia is a volunteer project and that commercial exploitation is contrary to that and undermines public trust in the project. Coretheapple (talk) 13:20, 18 July 2017 (UTC)
Conflict of interest is everywhere in the world. What undermines public trust is unmanaged conflict of interest. This is a tool to help better manage the specific form of COI that is paid editing. Jytdog (talk) 15:05, 18 July 2017 (UTC)
No, what undermines public trust is conflict of interest. Period. What undermines puiblic trust even more is condoned COI. Coretheapple (talk) 17:10, 18 July 2017 (UTC)
Coretheapple, potential COI is everywhere, and every responsible organization has ways to manage it. Pretending it can be eliminated (especially here) is not the real world. You are invalidating your stance here by writing this kind of nonsense, and I will not be responding to you further. Jytdog (talk) 17:23, 18 July 2017 (UTC)
Good. You haven't or won't grasp my point, your WP:BLUDGEONing of the discussion is getting tiresome, and your inflammatory edit summaries gild the lily. Coretheapple (talk) 17:44, 18 July 2017 (UTC)
There is a paid editor registry: Wikipedia:WikiProject Integrity/Editor Registry. It can use updating; everyone is welcome to pitch in! isaacl (talk) 00:51, 19 July 2017 (UTC)
  • Strong oppose-All paid editing is, by its very nature, biased. And, as Coretheapple said, this would also put Wikipedia in the position of being seen (rightly or wrongly) as supporting those companies that pay these editors. --Khajidha (talk) 12:38, 18 July 2017 (UTC)
  • Comment I want to make a note here that even if everyone opposed the idea, someone could start the project, which could only be removed for cause, not just because we don't like it. As far as I know, Projects are not vetted beyond having a scope that is within the limits of the greater project, and this clearly is. When it gets started (and it could be a month, a year, a decade, but not "if"), it would best be started by someone that isn't a paid editor but is willing to provide some guidance and written material to keep paid editors out of trouble. In the end, that should be our goal: help any editor follow policy, generate worthwhile content, and avoid sanctions. That which isn't worthwhile, we have AFD for, no different than today. Dennis Brown - 13:27, 18 July 2017 (UTC)
Dennis, thanks for your note. My goal in posting here was to make sure that the community was aware of this from the beginning. I am aware that people have strong feelings about paid editing so wanted to communicate clearly and broadly, at an early stage, and get useful feedback so that as this move forward (if it does...) that could be built in. My plan has been to do further planning and then present again, with detail, before launching it. Jytdog (talk) 15:02, 18 July 2017 (UTC)
That WikiProject is not really driven by paid editors. With the lack of that sense of "ownership" in the positive sense, comes neglect. Part of the design of this WikiProject is that paid editors will "invest" in its authentic success in the community - that it would propagate best practices and help us identify paid editors who aren't following PAID much less best practices. Jytdog (talk) 15:02, 18 July 2017 (UTC)
I saw that yesterday and just didn't say anything yet. That WikiProject isn't driven by anything, it is basically a ghost town. Re-purposing defunct projects is allowed. Dennis Brown - 15:12, 18 July 2017 (UTC)
i allso wanted to say that this would be "organic" - the next step in the evolution of rhe Statement. Jytdog (talk) 15:16, 18 July 2017 (UTC)
IMO before we will get those involved with paid editing interested in doing it above board, we need to be much more vigorous in policing those involved with undisclosed paid editing. As lots of the articles made by throw away socks of undisclosed paid editors are kept they have no incentive to change. Doc James (talk · contribs · email) 15:21, 18 July 2017 (UTC)
User:Doc James, of course we need to keep working on that. But part of the design of this is to dry up the market for unpaid editing by making a place for "white hat" paid editors to be, and communicating to the public that there is a difference. A big goal here is to influence the marketplace and drive business away from the socking, undisclosed paid editors. If this works (and I don't know that it will) there would be fewer people choosing to buy paid editing services on the black market. But right now the marketplace is undifferentiated and that is really our fault, as we have done nothing to define it for people. Nobody else is going to do that, right? We need to do it. And to do that, we need something that defines the legit (as far as we know) service providers. We don't need to endorse or recommend them (indeed we shouldn't) but we need to have a place to point people to. You can think of this like needle-exchange services in Vancouver or the like, and all the issues around that. Jytdog (talk) 15:37, 18 July 2017 (UTC)
I have seen a handful of disclosed paid editors who consistently use the AfC process. There is nothing stopping us form listing them in a central location right now. Doc James (talk · contribs · email) 16:02, 18 July 2017 (UTC)
In a way, a project would have us picking the winners and losers. Paid editors that followed the rules wouldn't have any problems, so they would be more efficient (from their perspective). Paid editors that didn't, who still socked, who lied about their status, would be subject to having all their work deleted, wasting their time. This creates a financial incentive to play by the rules, and rewards those that do by letting them spend more time writing passable articles and getting new clients, and less time dodging AFD and Checkusers. This may sound simplistic, but people always act in their own self-interest. We just need to provide a better alternative to socking, one where we can easily monitor everything. Dennis Brown - 16:41, 18 July 2017 (UTC)
A "project" or a "guild" won't do anything to deal with the cause of so-called black-hat paid editing, which is the demand for articles about non-notable subjects. They'll continue to take money from people who want articles written about them, they'll create their throwaway socks for that purpose. If they don't slip by under the radar they will be blocked. So what? They don't care. They'll create other socks, using VPNs etc. Coretheapple (talk) 17:08, 18 July 2017 (UTC)
I have over 1500 SPI blocks, including a record setting 300 in a single paid editing case. VPNs aren't that hard to catch and rangeblock, and pushing as many as you can into the "good" side means fewer to deal with at SPI. Its a bit more complicated than you are making it out to be. I've had more than a few extended conversations with paid editors offwiki, I know the system quite well. Many would rather do so in a legit fashion but the current rules make it hard. Dennis Brown - 01:27, 19 July 2017 (UTC)
This would be a lot more organic if it had happened three years ago, and if there were more involvement from any of the signatories. Right now there are just a couple of statements on the statement's talk page, with only vague details on what kind of work and outreach the parties in question would do. Absent their participation in these discussions, it's hard to tell if they're interested in this initiative or in engaging the non-paid editor community in general. isaacl (talk) 05:55, 19 July 2017 (UTC)
That's true. There is not a single paid editor involved in this discussion one way or the other. They can come here and argue how such a project or guild would benefit them, and complain directly about how supposedly difficult it is to comply with the very few rules regulating paid editing (per Dennis's comment above). I've never heard such complaints, and I've never seen them in public, probably because they would be greeted with ridicule. Coretheapple (talk) 12:59, 19 July 2017 (UTC)
I see WikiProject Cooperation and in particular Wikipedia:WikiProject Cooperation/Paid editor help (the paid editor noticeboard) as a way for the non-paid editor community to provide support to paid editors. For any paid editor support group to be successful, I feel the community needs to reinvigorate a group of non-paid editors to provide assistance, whether it is at the current paid editor noticeboard or somewhere else. isaacl (talk) 00:59, 19 July 2017 (UTC)
  • Oppose: We don't want all paid editors to create an project, otherwise it can cause problems. KGirlTrucker81 huh? what I've been doing 19:17, 18 July 2017 (UTC)
  • Oppose As stated above, allowing for the formation of a WikiProject/Guild/What have you essentially grants tacit approval. We should be here for the benefit of the project, and not to try to turn a buck or push an agenda. caknuck ° needs to be running more often 20:44, 18 July 2017 (UTC)
  • Oppose this would further legitimise some paid editing, the more we de-legitimise it the more the paid editors have to hide by writing neutrally and including neutral sources. I doubt we can get to the stage where paid editors are telling their clients that they had to mention the scandal but they did keep it out of the lede, but that is the direction I'd prefer us to aim for. ϢereSpielChequers 14:17, 19 July 2017 (UTC)
User:WereSpielChequers the notion of "deligitimizing" is what we have always done, and there is no evidence that the problem of undisclosed paid editing is going away or that the public even understands what that means. The goal here again is to a) influence the market for it (which has grown up despite the message that "paid editing is bad"), which we have never tried to do before, and b) be provide a more well-defined space where paid editors can learn best practices (the real ones, not the worst ones). Jytdog (talk) 00:15, 20 July 2017 (UTC)
That the problem is pretty bad right now doesn't mean it won't get far worse if we stop managing it. I've seen a few nice people who backed out quietly when I pointed out that what they were doing was in conflict with our goals, but the egregious examples of gaming the system and trying to covertly promote their stuff more than make up for that, and if we give the latter a soapbox to stand on, we'll have an even harder time ridding the project of spam. DaßWölf 00:38, 20 July 2017 (UTC)
Well said Wolf. I'd add that we don't want paid editors learning from each other, we want paid editors learning from editors who write neutrally, use reliable sources and who avoid areas where they have a conflict of interest. ϢereSpielChequers 07:07, 20 July 2017 (UTC)
  • Just fyi, have been thinking about this further, and it might make sense to move that activities around the "Statement" that are already happening, to the WP:WikiProject Cooperation. Might be an easier way to go to accomplish the same thing. Jytdog (talk) 00:00, 20 July 2017 (UTC)
  • Support - A step in the right direction. There is a difference between white hat and black hat paid editors. Sorting the sheep from the goats is what it's all about... Carrite (talk) 04:29, 20 July 2017 (UTC)
  • Support, after thinking about it for a while. We're never going to stop paid editing altogether, so having some paid editors who are members of the community in good standing is an absolutely solid idea. Enterprisey (talk!) 06:43, 20 July 2017 (UTC)
  • Oppose - these guilds generally refer to self-regulatory bodies for desired groups; paid editors are, by our standard, an undesired group. עוד מישהו Od Mishehu 07:58, 20 July 2017 (UTC)
  • Support I'm opposed to paid editing, but I don't see the harm. Perhaps it's a dog whistle I'm not hearing. As pointed out above, anyone can create a Wikiproject. So what are we arguing about? Whatever happens here it will be done, or not, depending upon whatever the whims of individual Wikipedians. Figureofnine (talkcontribs) 00:15, 21 July 2017 (UTC)
  • Oppose, mostly per Coretheapple. Double sharp (talk) 08:40, 21 July 2017 (UTC)
  • Suggestion. Is there milage in encouraging corporate user pages? Let us say that Bodgeit & Scarper want to inform the world that they are "the largest (2017 sales: 35 million) and best manufacturers of spring loaded rodent elimination devices". They, or their agent, can put this on a user:Bodgeit_&_Scarper. An editor can then edit mouse trap to add the information that "In 2017 Bodgeit & Scarper claimed to be the largest manufacturer with 35 million sold.<ref>Bodgeit & Scarper, ''company page'' [[Bodgeit & Scarper]] accessdate=1 April 2017</ref>". Paid editing of the main encyclopedia can then be banned but "white hats" are able to input traceable information whilst eliminating POV. Just a half-formed thought! Martin of Sheffield (talk) 09:56, 21 July 2017 (UTC)
  • Oppose I appreciate Jytdog and others here commenting to advance the conversation. If Wikipedia were to develop infrastructure for supporting paid editors, then I think the start should be for paid editors who are not editing Wikipedia articles on people or organizations. Right now "paid editing" is almost synonymous with "editing for a brand or promotion". Because of that heated discussion, we do not create pathways for benevolent paid editing about general reference topics which do not benefit promotional interests. We have a highly committed model for expert paid editing in Wikipedians in Residence. We do not have a light payment model, like for example, an organization which wants to be less committed in funding a scholar to edit Wikipedia articles in a general field like "sanitation" or "public parks" without promoting a brand. For political debates there are some organizations which would fund neutral discourse and presenting all sides of issues, like for example, listing all major points of view in a discussion on any major policy issue. There are lots of organizations which invest large sums of money in sharing ideas in Facebook and Twitter, when actually, what they would really like is to have neutral information in Wikipedia. If there were a club for "no branding, no promotion paid editors" then I think that could be a workable, positive space for some editors. Once we established a clear path for paid editors who have nothing to do with branding, then perhaps we could address the more controversial talk about branding. So far as I know, 100% of paid editors doing editing for brands have caused problems and made volunteers upset. I see no reason to chase a path with a 15 year, 750,000+ attempt, 100% failure rate. Blue Rasberry (talk) 16:35, 21 July 2017 (UTC)
  • Limited support Some editors perform absolutely herculean tasks on WP, and it is a travesty that none of them should ever receive any recognition for their labors and the selfless giving of their time and expertise beyond just a few barnstars. This should certainly change, even if it is only a small stipend as a token of appreciation for their prolific efforts. Whether it be done through crowdfunding or some Wiki endowment, I do not know. And no doubt not all editors would even wish to be paid for their work, but those who do should have a means of submitting their editing history for review. A committee of admins could then analyze the value of their contribs and decide what, if any, compensation would be appropriate. Another option might be a PayPal link placed on certain user pages to recognize some of the top contributors, allowing others who wish to subsidize and encourage their efforts to do so. Incentivization of excellent work is certainly in the interest of this site. - JGabbard (talk) 17:37, 21 July 2017 (UTC)
  • Support with Guild member fees in Bronze, Silver and Gold accounts. Membership cards include exclusive benefits, such as immunity from 3RR and get out of AfD for free (see fine print for disclaimers and limitations). Members earn double and triple points for gratis edits made in a non-paid capacity. Other benefits include free Wikimania scholarships, the private email address of the WMF president and a Wikipedia tote. -- GreenC 18:52, 21 July 2017 (UTC)
  • Very strong Oppose. Every single paid edit whether it is written neutrally or not, is an attempt to promote a company, a product, a person, or a non-profit. That is not what Wikipedia is for, and it's not what thousands of maintenance workers and bona fide content creators offer their unpaid free time for. The slightest relaxation in our view on paid editing, especially the creation of help/support areas for paid editors will be taken by them as a legitimisation of their activity. We already have plenty who think that by putting a paid editing declaration on their user page means we condone paid editing and give them carte blanche to go ahead and write what is basically blatant spam.
Give these spammers the slightest crack in the plaster and they will soon be chipping away at our rules and guidelines until they've knocked the whole wall down. In collaboration of the community and the WMF a short trial of some new measures is soon going to take place and its analysis will show what kind of effect, if any, it has had on spam (as well as other unwanted content). That, together with the non-indexing of new articles, should go a long way towards negating the SEO advantages for the 'Get me a page on Wikipedia' customers, and reduce the incentive for the 'We'll get you a page on Wikipedia' merchants.
Paid editing is not particularly difficult to detect by experienced New Page Reviewers, and spam links slipped into articles should be recognised by recent changes patrollers and Pending Changes Reviewers, and a few software enhancement we are asking for (eg. ORES, and better automatic duplication detection) should do the rest. What is increasing now however, is the number of direct offers of money for work being sent by email to admins from professional rings of socks (so it's already going partly underground). We can only rely on the sysops' integrity to refuse. I understand that measures to combat paid editing will drive it underground, but I think we need to stick to our principles and if we don't yet have such strong principles, it's time we did. Kudpung กุดผึ้ง (talk) 21:42, 21 July 2017 (UTC)
  • Very strong Oppose. Kudpung has said it all above and I concur.Charles (talk) 21:53, 21 July 2017 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Inline/title coordinates in infoboxes

Template:Coord#Caveats warns that "Tools which read Wikipedia database dumps (such as Google Earth) often ignore inline coordinates. To ensure that coordinates are seen by these tools, one set should be displayed beside the title." - this also seems to be true for the Wikipedia API, which so far as I can see only provides coordinates for articles when they are displayed in the title, and ignores inline ones.

There are a number of articles that supply coordinates in their infobox, but only as |display=inline (eg. Foundling Museum), and as such are invisible to third-party tools which access the API using coordinates. In cases where an infobox is in the lead section of the article and is already displaying inline coordinates, I propose that these should always be expanded to |display=inline,title (to the point where this process could be performed by a simple bot). Are there any cases where this would be incorrect or unhelpful? --Gapfall (talk) 15:46, 20 July 2017 (UTC)

Regarding the API, there are two types of coordinates: "primary" and "secondary". The default is to return only the primary coordinates, but the coprimary parameter may be used to request secondary or "all". Foundling Museum currently only has secondary coordinates, but it does have them. Presumably it's the primary coordinates that are displayed by the title. Anomie 16:15, 20 July 2017 (UTC)
Good to know. So for the sake of API queries that are just asking for an article's primary coordinates, is it safe to make the assumption that if there are inline coordinates listed in a lead-section infobox, they must be the primary ones for the article (and update the {{coords}} template accordingly)? --Gapfall (talk) 07:55, 26 July 2017 (UTC)
I don't know enough about how those infoboxes are used to say whether it's safe to make that assumption or not. Anomie 11:34, 26 July 2017 (UTC)

Perennial proposals and the Village Pump

If something's been rejected often enough to become a perennial proposal, I gather it can still be acceptable to open a new proposal on it, but that the interested party should first raise it here at the Village Pump (to see if taking a new swing at it is actually merited). Do I understand that correctly? If so, what's the appropriate response if users (either deliberately or unwittingly) disregard PERENNIAL and open new proposals on a perennial topic anyway? ╠╣uw [talk] 18:47, 21 July 2017 (UTC)

Anyone can choose to discuss a perennial proposal in any venue, but unless they've examined past history and are able to address the previously raised issues, then the conversation is likely to end quickly. I would ask the editor in question if the proposal has taken into account previous feedback. isaacl (talk) 03:23, 22 July 2017 (UTC)
When it's clear that the editor has not (but the proposal remains open), what then is the appropriate action? Closing with direction to discuss at the pump? It seems like the value of the perennial proposals list is to help constrain repetitious or unproductive debate, but in my experience even repetitious perennial proposals that offer nothing new and don't consider previous feedback don't end quickly. The few who support it will do so vocally, and the majority who don't will feel compelled to participate so that their silence isn't taken as tacit support. ╠╣uw [talk] 11:56, 22 July 2017 (UTC)
Generally speaking such proposals affect a broader audience and so need the broader attention of a place like a Village Pump, or at least a notification at a Village Pump. I'm not personally a big fan of forcefully closing discussions, so my approach would be to warn the participants that unless the discussion is moved to a broader venue, it can't be acted upon. There are others who do take a more direct tack of closing the discussion; I just think most of the time it creates more fuss than is saved by letting the discussion wind down. isaacl (talk) 15:33, 22 July 2017 (UTC)
Actually, the need for a broad audience would be handled if the discussion in question is advetized in an appropriate venue with a large audience. And without knowing which discussion you're referring to, we can't really answer the question. עוד מישהו Od Mishehu 19:06, 22 July 2017 (UTC)
Yes, I mentioned that notification at appropriate locations can be sufficient. Exactly how I might word a message would likely be context-specific. (I assume your second sentence is addressed to the original poster.) isaacl (talk) 16:12, 23 July 2017 (UTC)
It's a proposed page move, and the proposal is contrary to a consistently applied guideline. It's failing at over 70% oppose. A local matter like that doesn't need a Village Pump consensus or Central Notice. It could reasonably be posted at the guideline's talk page, but the proposal is toast anyway. Just let it die naturally. The standard 7 day discussion period is half over.
In many cases a bad perennial proposal can get a quick WP:SNOW close after a few clear opposes. But a proposal with a 30% support and respectable arguments shouldn't get SNOW closed. This proposal is dead, but not SNOW appropriate. Alsee (talk) 06:29, 24 July 2017 (UTC)
Agreed that a page move in itself doesn't need a broader consensus (changing the relevant underlying policy or guideline would). If the conversation is ending, then as I alluded to originally (but I guess I didn't write explicitly), just let it end. isaacl (talk) 06:50, 24 July 2017 (UTC)

Dispute resolution RfC

Hello. You are invited to comment on this RfC, which seeks to reform certain aspects of Wikipedia's dispute resolution processes. Biblio (talk) 15:47, 23 July 2017 (UTC)

RFC pointer: CSD G13 to include all draft-space drafts

Watchers of this page may be interested in WT:CSD#Expand G13 to cover ALL old drafts. --Izno (talk) 12:11, 25 July 2017 (UTC)

Disputed dates of birth

If you go to the article on Robert Conrad, his date of birth is given as 1935, but the talk page on this article suggests this is disputed. Could we ask people to put "disputed" after dates of birth on some articles?Vorbee (talk) 08:43, 28 July 2017 (UTC)

One option in these cases is give a range or multiple dates with sourcing. Or use the {{circa}} with a footnote. -- GreenC 13:04, 28 July 2017 (UTC)

Idea lab

Add language links for user pages/main talk pages

Given the Unified log in, it would seem to be easy to have links under languages for the main user page and main user talk page for a user to any page which exists. So for example, since es:Usuario discusión:Naraht exists, it should have a link on the left to en:User talk:Naraht and vice versa. However since nn:Brukardiskusjon:Naraht does not exist, there would be no link to there from either page. Not sure it makes sense to do this all the time (gadget preference or tool would be fine, I guess)Naraht (talk) 16:46, 6 July 2017 (UTC)

Given welcome bots on some wikis, though, you can't really assume that an existing user talk page is particularly relevant. Anomie 17:43, 6 July 2017 (UTC)
Granted. But even so, it does mean that the user has edited that wiki. I'm not sure under what circumstances bots would create a user talk page with no edits on that wiki. And yes, I'm very likely to hit that, since I have edited many language wikis changing "John Hopkins University Press" to Johns Hopkins University Press". Naraht (talk) 20:57, 6 July 2017 (UTC)
On some wikis they do indeed create the user talk page as soon as a local account is created, which happens the first time you visit the link while logged in with SUL. Anomie 11:41, 7 July 2017 (UTC)
@Anomie: even just the same functionality as articles could eliminated lists of interwikis on each wiki - by moving a 'wmfuser' object in to wikidata - or possibly in where ever the wishlist "global preferences" could be stored? — xaosflux Talk 22:53, 6 July 2017 (UTC)
Wikidata rejects items dedicated to Users (see d:WD:N). However, see below. --Izno (talk) 02:41, 7 July 2017 (UTC)
I don't know it's done that way, but some wikis create a welcome message when you visit it and are logged in. For example, I had a welcome message on my talk page on Meta Wikipedia for years before I ever made an edit to it. isaacl (talk) 02:52, 7 July 2017 (UTC)
I like this idea. Jason Quinn (talk) 20:13, 6 July 2017 (UTC)
I was fairly sure there was a general request for this functionality on Phabricator, but all I can find is the recently-filed phab:T168792. --Izno (talk) 02:41, 7 July 2017 (UTC)

I like the idea, in these days i was even thinking in make this proposal in the lusophone Wikipedia. Jasão (msg) 08:59, 7 July 2017 (UTC)

Encouragement to proofread

As someone who has spent years correcting typos on Wikipedia, I have found many errors that could have been avoided by the original author proofreading his creation. Can we not do something more to encourage contributors to proofread? Or even automatically suggest corrections as WP:AWB or Grammarly do? Even a pop-up window upon submission of a new article or a notice to a talk page would likely be helpful. --LilHelpa (talk) 11:32, 12 July 2017 (UTC)

Hi LilHelpa I might be one of the people you are talking about and I agree somewhat. However for folks like me who are translating a page across wikis and sometimes simultaneously improving that article, the folks like you who do those little cleanups are an amazing help!. The cognitive load for some tasks like these requires frequent breaks. When I do return afresh to do some proofreading, some saint has already helped out. So that makes my job more efficient. As long as some kind of prompt to proofread didn't compete for my attention while I was doing step-wise translations (i.e. one sentence/one paragraph per edit at a time) then this would be great. Dr.khatmando (talk) 04:45, 13 July 2017 (UTC)
Thanks, Dr.khatmando as you make some valid points. I don't see much value to nagging every edit step. I do understand the difficult task of translating which you describe... and thank you for accomplishing that. Copy editing is also a task that needs to be efficient. To that end, many do not seek to cooperate in the slightest. --LilHelpa (talk) 12:12, 13 July 2017 (UTC)
LilHelpa Indeed. I know we value the same things have the same goals in mind. Dr.khatmando (talk) 12:32, 13 July 2017 (UTC)
Not everyone can proof read well, most of us have problems spotting our own mistakes, and I suspect many of our contributors are doing so in a second language and part of their motivation is getting people like LilHelpa and myself to fix their mistakes. The point about crowdsourcing is that people contribute content and others improve that, I don't see any benefit in making it harder for the content contributors, or rather if there was one change I'd make to contributors it would be to prompt for a sources where they appear to be adding unsourced content. ϢereSpielChequers 11:10, 13 July 2017 (UTC)
While sourcing is certainly more important (and more difficult) than proofreading, it is because of the ease of proofreading that encouraging proofreading may have a better return. Even conscientious article authors often do not carefully review their work. Nobody knows better than I that people make mistakes... and I agree that even a careful proofreading may miss some. However, it is those "contributions" that ignore capitalization and spacing (and IMHO could be considered vandalism) that are most trying. Somewhere in between are lazy editors who need a small push and encouraged to take more pride in their work. It doesn't have to be harder for the contributors (as with a pop-up), it just needs to be more portrayed as valuable. Cleanup needs to be efficient, too.--LilHelpa (talk) 12:12, 13 July 2017 (UTC)
It would be good to get a study done on this, but my experience is that many individuals do pay attention to what happens to their contributions and learn from the correction of their mistakes. Typos that I patrol will usually shift genres as people editing in one subject area take note of the corrections I have made and new people start. We could of course make preview a mandatory phase before saving, but I suspect the WMF would very sensibly veto that as an extreme measure that would undermine open editing and make people's first edit a bit more difficult and complex. ϢereSpielChequers 06:19, 14 July 2017 (UTC)
Typos are one of those things, like dab links, which appear very significant when you work through a massive database report that lists thousands of these errors, but which are really one of the last things we should worry about. Not that fixing them isn't important – I hugely appreciate (and have benefited from) the efforts of the editors who fix them. But when you're spent ages researching a topic and then drafting and redrafting your text, and when you've then gone over it alongside the sources to double-check you've represented them fairly, and when you've then edited your text for readability and made sure all the wikilinks go where they're supposed to and that all the ref anchors work, after all this two things are certain: 2) it's very ease to become incapable of noticing your own typos, and 2) the last thing you need at this stage is having another hurdle to stop you from publishing your work. And as for the editors who consistently make gross errors with spacing and capitalisation, well, I think these errors aren't going to be among the most problematic aspects of their contributions. Text that looks really bad should either be removed or left as it is, the character of its spelling and punctuation being a self-referential indicator of the quality and reliability of its content. – Uanfala 18:10, 22 July 2017 (UTC)

Make wikipedia readable again

Hello folks

I've been unsatisfied with Wikipedia user interface for years. When modern websites showing texts such as Medium, the main newspapers websites, Gitbook, etc display text on a narrow column with a high font size and space between lines, Wikipedia has still a very old fashioned way of displaying full width text with a very small font-size. This makes it very hard to read since your eye have to follow very long lines.

I'm not a web developper but I had just the idea to write a few lines of CSS to make wikipedia readable again. My idea was just to get inspired by Firefox reader's mode. So with a few lines of CSS, I was able to really improve my user interface.

I've edited my vector.css file.

  • The first point is to reduce the width of the main text :
    max-width: 800px;
  • The second point is to add right padding. I've chosen right padding as 40% :
           padding-right: 40%;
  • Then I've used the Helvetica font
    font: Helvetica;
  • Font size is 1em
    font-size: 1.0em;
    and line-height 1.6
    line-height: 1.6em;
  • Text color is grey
           color: #333;

Therefore adding this text to vector.css make Wikipedia really really nice :

#firstHeading {
       width: 100%;
       margin-left: auto;
       margin-right: auto;
       padding-right: 40%;
       max-width: 800px;

#bodyContent { 
       width: 100%;
       margin-left: auto;
       margin-right: auto;
       padding-right: 40%;
       background-color: #FFFFFF;
       color: #333;
       max-width: 800px;
       font: Helvetica;
       font-size: 1.0em;
       line-height: 1.6em;

I think that this can be useful for many people.

Any CSS specialist wanting to help me improve this CSS is welcome.

--PAC2 (talk) 19:26, 13 July 2017 (UTC)

"Modern" websites don't imprison their content in the center fifth of the window because that makes it more readable. They do it either so they can cram more ads into the sides, or because it's easier and cheaper than doing things right. —Cryptic 06:58, 14 July 2017 (UTC)
This is untrue. I just pulled off the top of Google this article. Some of them are in-fact designed this way for something more than advertisements or navigation or whatever else one might find in a another column on your screen. The Minerva skin (not yet a true skin, but soon-to-be separated from MobileFrontend) takes these factors into account in its design. --Izno (talk) 12:34, 14 July 2017 (UTC)
@Izno thanks for the tip. — Preceding unsigned comment added by PAC2 (talkcontribs) 13:00, 14 July 2017 (UTC)
Wikipedia has a lot of skins, see your Preferences for different looks. Also, you might be very interested in Help:Mobile access and/or Wikiwand, both of which are Wikipedia in a different and arguably more appealing interface. As for myself, I simply zoom in the font size (with my mouse wheel) and manually narrow my viewing window if I find the lines are too long to read comfortably. The problem comes when an article has many images, which crowd out text if the window is too small. Softlavender (talk) 09:50, 14 July 2017 (UTC)
Hello, I use a 750px width since 2013 (although I had it as fixed, not as max). With about 100 characters per line, text is much easier to read. I would also support such a (configurable) limit, although with a better layout (I get a huge blank area between the page text and the left column). --NaBUru38 (talk) 14:53, 14 July 2017 (UTC)
@TheDJ: I feel like I've seen you talk or work on stuff like this before, or at least know who has poked at it in WMF land. --Izno (talk) 15:45, 14 July 2017 (UTC)
Yes, PAC2 might be interested in my User:TheDJ/responsiveContent and responsive Vector experiments. —TheDJ (talkcontribs) 18:27, 14 July 2017 (UTC)
Strongly oppose any "max width" pixel value for content - Wikipedia is used many ways, including on projectors, huge screens, etc. — xaosflux Talk 16:13, 14 July 2017 (UTC)
You probably don't own a 27" retina screen.. Wikipedia's vector looks ridiculous in fullscreen mode on that :) I have it limited to 1200px content + 700px of sidebars and that makes it 'doable'. —TheDJ (talkcontribs) 18:27, 14 July 2017 (UTC)
A max pixel size would still be bad design, it should use ems or other responsive units so it doesn't break if people change their base font size. Personally, I just don't full-screen my browser to get a narrower line length for most browsing. Anomie 12:52, 15 July 2017 (UTC)

Citation count by source

Hi. This will not really useful to everybody. But IMO, it'll be handy to have an option (gadget) to display a citation count next to each source in the sources section of an article. For example,

  • Sarkar, Jadunath (1960). Military History of India. Orient Longmans. pp. 75–81. [cited 11 times]
  • Chandra, Satish (2005). Medieval India (Part Two): From Sultanat to the Mughals. Har-Anand Publications. ISBN 9788124110669. [cited 5 times]
  • de la Garza, Andrew (2016). The Mughal Empire at War: Babur, Akbar and the Indian Military Revolution, 1500-1605. Routledge. [cited 1 time]

This would count,

  • ^ abc Sarkar 1960, p. 77.

not as 1 citation of Sarkar but 3.

Such a feature would allow editors/readers to evaluate (across reflists, notelists, etc.) which sources the article largely relies on. It might also be useful to sort the sources list by citation count.--Cpt.a.haddock (talk) (please ping when replying) 09:25, 15 July 2017 (UTC)

Dispute resolution RfC

Hello. You are invited to comment on this RfC, which seeks to reform certain aspects of Wikipedia's dispute resolution processes. Biblio (talk) 15:47, 23 July 2017 (UTC)

Seeking feedback on addition to What Wikipedia is not: Wikipedia is not the final arbiter of truth

I'm looking for feedback on my initial draft of a proposal for a new section added to the policy What Wikipedia is not. It distills the long established practice of not taking sides in disputes, and giving due weight to significant dissent. I've noticed that sometimes IPs and SPAs are on a mission to change an article to take unresolved questions and resolve them. Marketers often want articles to say definitively that their company's product is the leader in its category. Quite a few want ownership of inventions assigned unequivocally to one nation, and no other. Many are partisans, many are just using Wikipedia for its most popular purpose: answering questions. When it's for a trivia quiz or to settle a bet, many readers won't accept anything but an either/or answer, when the sources are telling us is "it depends".

Wikipedia is not the final arbiter of truth

Wikipedia is not written to settle bar bets.

The policies requiring a neutral point of view and verifiability, and prohibiting publishing original thought, mean that Wikipedia editors, and the articles they write, cannot judge who is right in an entrenched disagreement. Articles focus mainly on facts that are most widely accepted and established, giving little space to on fringe ideas, but nonetheless, significant dissent from mainstream views is given proportionate attention. When views are divided, Wikipedia struggles to accurately portray that division, not oversimplify it.

Wikipedia cannot resolve questions that established experts have not themselves fully resolved. The ambiguities and contradictions of real life cannot be artificially made simple and tidy by Wikipedia. Articles can strive to give simple explanations for complicated concepts, but they cannot do away with complexity itself, nor make a roundabout series of events into a straightforward narrative. This does not mean Wikipedia should present facts as if they were opinions, only that Wikipedia does not add weight to the judgement of reliable sources.

An encyclopedia article is not the place to find the definitive answer to the question of whether the motorcycle is a German, French, or American invention. Wikipedia can verify that for a long time, most mainstream authorities agreed it was the Daimler Reitwagen, but the muddy and complicated picture made by reputable dissenters who bring up earlier steam motorcycles cannot be neatly cleaned up by Wikipedia editors. The International Astronomical Union's mission may include announcing, once and for all, that Pluto is not a planet, but Wikipedia's mission is only to describe the IAU's statements, and the significance and influence the IAU represents, but not to give or withhold a Wikipedia seal of approval. An encyclopedia of unlimited size can give a plot summary and production details of the Friends episode that featured the practice of going commando, but Wikipedia cannot change from opinion to fact the assertion that Friends is almost solely responsible for popularizing the slang term for not wearing underwear.

Changing an article, or requesting that it be changed, to give answers unambiguous enough to settle your bar bet is contrary to Wikipedia's core principles.

I threw in a few colorful illustrations from my own editing experience. I'm sure there are some issues of this type that I'm not familiar with. I'd like to draft a proposal that doesn't get bogged down in choosing the perfect wording, and can simply gauge consensus for or against the basic idea of this kind of addition to WP:NOT. Thanks in advance! --Dennis Bratland (talk) 06:27, 24 July 2017 (UTC)

Dennis, if you don't mind, what distinguishes this from Wikipedia:NOTTRUTH ? ☆ Bri (talk) 22:24, 24 July 2017 (UTC)
NOTTRUTH is an essay, this is a proposed amendment to a policy. Jo-Jo Eumerus (talk, contributions) 07:36, 25 July 2017 (UTC)
I think it's fair to say it's related to the essay Wikipedia:Verifiability, not truth. But I'm totally serious when I say this is about bar bets, or similar trivial hairsplitting. People like to win contests, or pick winners, over what is the first or best or which country invented the whatever. And they want Wikipedia to settle those questions. They want answers, not shrugs. And they want short answers, not long, complicated explanations that raise more questions than they answer.

Just like people turn to Snopes to debunk internet memes. Or PolitiFact or to adjudicate public statements. Perhaps I should adjust it to include "Wikipedia is not your Snopes, or PoliticFact or" It's not that we don't dabble in that, for example at List of common misconceptions. The central point is that we don't feel obligated to issue a ruling on every question. Many of these "lie checkers" have a bias toward giving some kind of answer, even if the data doesn't fully support a definitive conclusion. So the driving force behind my proposal is the No original research policy. Fudging, or erring, or ignoring contrary evidence, ignoring dissenting points of view, because we want articles to offer clear solutions or conclusions or judgements not fully supported by the sources.

Or because we want to define or categorize things. I guess you could call me one of the editors who thinks Wikipedia:Categorization is broken. It is mostly wonderful, but there is pressure to pigeonhole things into one category or another, but not both, not neither. "A place for everything". What if nature doesn't give us things that have a place? What if our taxonomy is flawed? Often, the taxonomist isn't a reliable source, it's a Wikipedia editor. Creating a taxonomy out of whole cloth violates WP:NOR. What if the sources don't tell us what category something belongs in? The intent of this WP:NOT addition is to offer support for editors who resist forcing an article into a category for the sake of sticking it somewhere rather than nowhere. I don't have a proposal that would fix the categorization policy, but I think this small addition to WP:NOT could help editors resolve some disputes, and help educate the general public about what we really do. --Dennis Bratland (talk) 01:23, 27 July 2017 (UTC)

Reading List

I often find myself stumbling upon Wikipedia articles that I would like to read, even though I don't have time to. To resolve this issue I would suggest the implementation of a basic "read list" feature. This would just be a simple (ordered by priority or date added) list that is tied to ones account. It would be added to and then removed from once the user has finished with each respective page. When the user then views a page again, they can see whether they've marked it as read. This kind of idea could then also be extended in a variety of ways. I also fail to see any technical constraints that may be involved. --Sherbet-head (talk) 14:54, 24 July 2017 (UTC)

This can be requested at Phabricator, see Wikipedia:Bug reports and feature requests for how to request it. עוד מישהו Od Mishehu 07:00, 25 July 2017 (UTC)

Another one of Anna's jugheaded ideas

Is anyhow familiar with the Kim Jong-un non-free image thing?

The community has now wasted hundreds of hours on reads and keystrokes over this matter.

Do you remember Wikipedia:Donated artwork?

Bottom line:

It listed BLP articles with huge hits needing any image. Artists make a one-hour drawing to get credit and half a million views a year. No money offered. No takers. Artists are poor. Asked at WMF and it was all hoops to jump through to loosen the purse strings.

What if Wikipedia:Donated artwork tendered? An off-wiki crowd-funding/donation thing? Would-be WMF donators sick of the pile of unused loot instead put their cash into something direct. Thoughts? Anna Frodesiak (talk) 00:28, 26 July 2017 (UTC)

Alright. No interest. I get it. I had to try. Please hat. Thanks for the read. Anna Frodesiak (talk) 00:15, 27 July 2017 (UTC)
Well give it a couple more days. It's a little off the wall for rapid responses :) --Elmidae (talk · contribs) 00:56, 27 July 2017 (UTC)
I don't really see how this is a solution to the Kim Jong-un problem. I've never follow the situation but a quick loook suggest to me that AFAICT, there are already multiple free content sketches of him. These have been used on and off in the article since early 2015 or earlier. The primary object to them is not due to questions over whether they are free content, nor to do with the quality, but that some people feel there should be a photo. The only person I've seen objecting to the quality is you. Possibly 1 or 2 other people although I'm not sure about these since their comments were ambigious, I think they just don't want the sketches because they don't think any sketches will do. In others perhaps this will resolve your objection, but it's just going to be a waste of the artist's time since there's a fair chance the problem will still exist and I'm not even sure that this sketch will be more popular than any of the other current ones. Nil Einne (talk) 08:00, 27 July 2017 (UTC)
I've now looked more carefully at the discussion. I found one other person who seemed to be objecting specifically to the sketch nearly 3 years ago since they said it was cartoonish although this was when there were fewer options and I'm not convinced they would have been happy with artwork. As said, there are other people who made less specific comments like "ugly" but I'm even less convinced these people will be happy with any artwork. One comment which caught my eye was "A talented portrait artist working in a hyper-realistic style could create an original image, or painting, of Kim Jong-un based on study of many photos rather than copying one photo. If that artist donated the image under an acceptable Creative Commons license, then this problem would be solved." I think this comment may have partly inspired this proposal but I'm not convinced it's true. Personally I share Jack Upland's view in that same discussion, and this is IMO supported by previous discussions for this very issue (as well as previous ones I remember seeing). Even hyperrealistic professional art is likely to have problems since people simply object to the idea of art instead of a photo since they either don't understand or don't share our free content goals. (Although it's true very high quality photorealistic art can be very difficult to distinguish from an actual photo so many casual observers won't know. But then again I get the feeling this is going to increase the objections of those who feel there's something wrong with using art instead of a photo.) In any case, even if something like that would be acceptable unlike the other sketches so far, while I'm not an artist I'm pretty sure it's not something that is going to take only an hour but many hours. Nil Einne (talk) 09:12, 27 July 2017 (UTC)
To put things a different way, most of the discussions have actually been about why there's no photo and whether or not we should allow an NFCC photo and whether our policy on that is a good thing etc or not. While it's often hard to tell due to the lack of clear commentary, when there has been discussion of the sketch it's often been about which one is preferable. When people have objected to all the sketches and suggested no photo is better rather than simply saying we should use a photo, I've seen almost no one saying the current options are too poor but a better sketch would be okay. As said, their reasons aren't always clear but with a few of them I get the feeling they either don't think any sketch will ever be acceptable to the community and so prefer to keep it out to reduce controversy, or they personally feel that all sketches are too poor a subtitute for photos. It's possible some or many of them haven't considered truly photorealistic art, but as said earlier it's also easily possible the objections will remain with that, or even increase. It's true some articles on living people have survived for years with sketches of various kinds, but these have tended to be less high profile and their sketches weren't necessarily any better than what we already have for Kim Jong-un. Note that none of this means that the idea won't be helpful elsewhere, simply that the cited example doesn't seem to help the case. There's a fair good chance even if someone did pay for art 3 years ago, we would have spent the same or more time on discussion at Kim Jong-un. And actually, it does highlight one of the risks of paying for art, there's no guarantee consensus is going to be in favour of including it no matter how good it is. Nil Einne (talk) 09:12, 27 July 2017 (UTC)


Teahouse host

I've been answering questions at the Teahouse for a long time and finally got around to formally signing up as a host on the nineteenth. I can't see my profile on the host page, though. Even weirder, the page history doesn't show me having edited it, even though my edit history does. Can you just not see your own profile? Or is some kind of bug at play? White Arabian Filly Neigh 19:10, 22 July 2017 (UTC)

I see you as #177 at Wikipedia:Teahouse/Hosts, but the linked image/file does not seem to exist. —PaleoNeonate - 19:18, 22 July 2017 (UTC)
Oh, also the actual page is Wikipedia:Teahouse/Host_landing which is transcluded in that above one, I see your edit in its history there... I hope this helps, —PaleoNeonate - 19:20, 22 July 2017 (UTC)
@White Arabian Filly: I fixed the image issue, it only had an extra File: prefix (which was already implicit). Also, thank you for joining the hosts, I'm actually one of the editors you once helped there. —PaleoNeonate - 03:41, 23 July 2017 (UTC)
PaleoNeonate, thank you for your help. I remember talking to you at the Teahouse, too. White Arabian Filly Neigh 20:49, 23 July 2017 (UTC)


I fixed an error in an article and someone reverted me, knowing that my father is a Black African, could this be racism? How should I handle it? Φράγκος Στάθης (talk) 05:25, 26 July 2017 (UTC)

Reading through the comments next to all the edits, I'd say the more likely scenario is that the person who reverted that edit of yours probably didn't know about your ethnicity, even if they cared. An astonishingly large number of reverts happen before the reverter has even looked over the other person's user page. Rhialto (talk) 10:09, 26 July 2017 (UTC)
Yeah, you can not assume that another editor looked at your user page to discover your ethnic heritage. Most editors won't. Indeed (given your user name) it is more likely that other editors will assume you are of Greek heritage rather than of African heritage.
As for how you should handle being reverted... first, never take being reverted personally (being reverted is something that happens all the time - even very experienced editors get reverted from time to time). The way to deal with it is to go to the article's talk page and ask the other editor why he/she reverted your edit... and then discuss it politely. Blueboar (talk) 10:26, 26 July 2017 (UTC)
@Φράγκος Στάθης: If you see an obvious problem like "/_help" for no reason in an article then please check the page history before just removing the bad text like in [14]. The previous edit [15] had bigger problems and should have been reverted completely. The page was better right after than right before your edit but you inadvertently helped hide the bigger problem. It has now been reverted completely. The editor who reverted you was apparently unaware of this so I'm not saying that revert was justified. PrimeHunter (talk) 12:34, 26 July 2017 (UTC)

I can speak with absolute certainty that the editor in question did not know your racial background nor did they care. You have been here for 24 minutes and am already accusing people of racism against you; you dearly need to read WP:AGF. --Golbez (talk) 16:34, 26 July 2017 (UTC)

Why do you assume it wasn't because you have a Welsh mother? GangofOne (talk) 20:24, 26 July 2017 (UTC)

Disestablishment date

"American Viscose operated from 1910 to 1976, when it was renamed Avtex. Avtex closed in 1990." What disestablishment date should be used in the category, 1976 or 1990? --Richard Arthur Norton (1958- ) (talk) 19:34, 26 July 2017 (UTC)

Net neutrality banner

Hi all,

Copied from Wikipedia:Help desk:

Hi all,

Could we please put a net neutrality banner for all readers to see, similar to the fundraising banner?

FCC is considering a law to allow US Internet providers to censor bandwidth price and slow down certain websites you visit.
Please stop this by writing a letter to your representative today! (If you're outside of US, share with a friend.)

I am a foreigner; if you're able to word this more concisely, please do.

--Gryllida (talk) 00:15, 27 July 2017 (UTC)

Hello Gryllida, hope you're well. As the Help Desk is for resolving issues related to editing, I should recommend that you may consider the Wikipedia:Village pump (miscellaneous) forum for posting your suggestion. Thanks. Lourdes 03:01, 27 July 2017 (UTC)

--Gryllida (talk) 05:15, 27 July 2017 (UTC)

Please read this, which will help explain why it's unlikely we will have a banner as there appears to be no clear consensus of opinion regarding support or opposition.--S Philbrick(Talk) 19:38, 27 July 2017 (UTC)
WMF's Wikipedia Zero initiative is firmly anti-Net Neutrality. — Dispenser 13:41, 28 July 2017 (UTC)


How to article „Former Yugoslavia“ leads on article „Socialist Federal Republic of Yugoslavia“ to the part „12 Legacy“ not „2.8 Legacy“? --SrpskiAnonimac (talk) 14:13, 27 July 2017 (UTC)

You'll need to either rename the sections so that they are unique within the article or use {{anchor}} to create a named anchor to use in the redirect. olderwiser 14:41, 27 July 2017 (UTC)
I have removed the first one-sentence section.[16] PrimeHunter (talk) 14:54, 27 July 2017 (UTC)

RFC open concerning use of Cultural warning and advisory templates.

There is currently an RFC open at Template_talk:Recent_death_Aboriginal_Aus concerning the use of templates and notices to comply with cultural sensitivities. Please feel free to drop by if interested. Thanks! Dane|Geld 21:07, 27 July 2017 (UTC)

Strategy discussion, cycle 3. Challenge 5

Hand 3.svg

There are only three days left (plus today) to take part in Cycle 3 of the Wikimedia strategy discussion. Insights to the last challenge our movement is facing has just been published. The challenge is: How does Wikimedia meet our current and future readers’ needs as the world undergoes significant population shifts in the next 15 years?

The previous challenges are:

  1. How do our communities and content stay relevant in a changing world?
  2. How could we capture the sum of all knowledge when much of it cannot be verified in traditional ways?
  3. As Wikimedia looks toward 2030, how can we counteract the increasing levels of misinformation?
  4. How does Wikimedia continue to be as useful as possible to the world as the creation, presentation, and distribution of knowledge change?

On this page, you may read more, and suggest solutions to the challenges. Also, if you're interested in related discussions that are taking place on other wikis, please have a look at the weekly summaries: #1 (July 1 to 9), #2 (July 10 to 16), #3 (July 17 to 23).

In August, a broad consultation will take place, but it'll differ from what we've been conducting since March. This is your last chance to take part in such a discussion! SGrabarczuk (WMF) (talk) 13:33, 28 July 2017 (UTC)

The first edit?

  • I tried looking at address , to try to find when was the first Wikipedia edit of them all. This Edit 1 proved to have been made to page Wikipedia:Wikipedians by Luis Oliveira at 14:25, 26 January 2002; but page Wikipedia:Wikipedians had about 60 edits before that. That page's edits after that Edit 1 have small numbers increasing with time, as expected; but that page's edits before that Edit 1 have high numbers, and that page's oldest edit has number 332199963. Anthony Appleyard (talk) 13:36, 28 July 2017 (UTC)
Retrieved from ""
This content was retrieved from Wikipedia :
This page is based on the copyrighted Wikipedia article "Wikipedia:Village pump (all)"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA