Wikipedia:Village pump (proposals)/Archive 160

Since disambiguation pages are not considered encyclopedic, why are they in the main space? Has it been previously discussed to have a Disambiguation namespace so that the article count (currently standing at 5,887,631) would be more representative of actual encyclopedic articles? Banana Republic (talk) 02:14, 15 July 2019 (UTC)

• @Banana Republic: This topic has appeared in the context of other conversations a few times, but there is only one conversation I can find (quickly) which is dedicated to it—Wikipedia:Village_pump_(technical)/Archive_33#Disambiguation:_namespace. This conversation is negative on the idea and presents some arguments. Personally, I think that disambiguation could, in the long term, be folded into Wikidata functionality, with the concomittent elimination of DAB pages and replacing with a search facet which draws on dab-data, but that's not something close to being discussed at present as far as I know. --User:Ceyockey (talk to me) 02:30, 15 July 2019 (UTC)

That was a rather short discussion, and it appears that it contained a basic fallacy. One user wrote "Disambiguation pages are still articles". Perhaps they were considered articles in 2008 when the discussion took place, but they are not considered articles today by Wikipedia:Disambiguation which states that "Disambiguation pages are not articles and so should not be tagged as orphans". It therefore seems that if they are not considered articles, they should not be in the article namespace. Banana Republic (talk) 02:43, 15 July 2019 (UTC)

There are lots of things in the mainspace that are not articles. Like redirects, (some) lists, etc. Killiondude (talk) 02:48, 15 July 2019 (UTC)

Per this link, redirects are not counted in the article count.

Per Wikipedia:Manual of Style/Lists, lists are considered as list articles.

This means that if disambiguation pages were to be put into their own namespace, the article count would reflect the number of articles plus 1 (the main page, which is not considered an article). Banana Republic (talk) 02:59, 15 July 2019 (UTC)

I was making the point that some lists are akin to disambiguation pages in that they are nothing but links. Killiondude (talk) 03:02, 15 July 2019 (UTC)

Lists are different from disambiguation pages, and serve a different purpose. Banana Republic (talk) 03:04, 15 July 2019 (UTC)

According to Template:Disambiguation, there are approximately 190,000 disambiguation pages on Wikipedia (that incorporate the template). This is approximately 3% of the 5.89 million pages that are counted as articles. I think it would be good idea to have those 190,000 articles removed from the article count, and have a more meaningful article count. Banana Republic (talk) 03:16, 15 July 2019 (UTC)

Where would the links point, then? What would be at those titles? If an editor makes a link to Seal or Pop or Frank Smith, or a reader searches for that term, would the link point to a redirect to this new space? There isn't an article that could remotely be considered the primary topic for any of those terms. bd2412 T 03:54, 15 July 2019 (UTC)

Per

WP:INTDABLINK, "Links to disambiguation pages from mainspace are typically errors". Therefore, with perhaps a few exceptions that I cannot think of, there should not be any links to disambiguation pages from within the mainspace articles. Banana Republic (talk

) 04:07, 15 July 2019 (UTC)

I am fairly certain that pages which include <code>__DISAMBIG__</code> are not included in article totals. --Izno (talk) 04:26, 15 July 2019 (UTC)

Nope, I'm wrong. Interesting. Maybe that should be a request in for the devs. --Izno (talk) 04:27, 15 July 2019 (UTC)

I would think that developers would want to see a consensus before considering implementing such a change. Banana Republic (talk) 05:38, 15 July 2019 (UTC)

As pages change whether they are disambiguation pages or not (when we decide what is or what is not the primary topic), the sharp distinction of an extra namespace does not look like a good idea to me. Having Mercury redirect to Disambiguation:Mercury also does not look like an improvement. The main advantage of the proposed change seems to be that it might make it easier for our article count to be more accurate, but that is hopeless anyway, with sub-articles and with lists split into several articles because they are too long otherwise. Whether we overestimate the "correct number" by 3%, 5% or 10% (or underestimate it because of merges that really are covering separate topics) isn't relevant unless we pretend the "article count" actually means anything at all other than "Wikipedia is really big, and still growing". And we shouldn't pretend it means any more than that. —Kusma (t·c) 09:01, 15 July 2019 (UTC)

Such a move would be a case of the article count tail wagging the encyclopedia dog. We are here primarily to build an encyclopedia, not to worry about things like article count, so any decision should be made on the basis of what makes for a better encyclopedia. People are free to count articles in any way they want without the encyclopedia being disrupted for the sake of counting them.

Phil Bridger (talk

) 09:21, 15 July 2019 (UTC)

Article count is only one issue. The bigger issue is to drive home the point made in WP:Disambiguation that Disambiguation pages are not articles. Nothing makes the point more clear than to put them in their own namespace. Banana Republic (talk) 12:43, 15 July 2019 (UTC)

So you propose spending hundreds of hours of editor and developer time on driving hime a point made by a throwaway remark about whether certain pages should be tagged as orphans, without presenting any evidence that confusion over this point has caused the slightest of problems? I won't be commenting any further here, because I have better things to do with my time than discussing pointless proposals.

Phil Bridger (talk

) 14:03, 15 July 2019 (UTC)

Yes, the transition would indeed require some effort, but I think it is an effort worth exerting. I think it is worthwhile to keep things clean and keep non-articles out of the article namespace. Banana Republic (talk) 14:29, 15 July 2019 (UTC)

Disambiguation are IMHO a reading aid to help readers find the article they really want to read. A service to readers. To hide them, is not helpful at all. The Banner talk 13:09, 15 July 2019 (UTC)

The proposal would not make disambiguation pages hidden. It would only make hat notes that currently point to disambiguation pages such as George Washington (disambiguation) point to Disambigution:George Washington instead. Banana Republic (talk)

And it would make lots of pages become redirects to the disambiguation namespace. Someone who wants a working copy of the encyclopaedia would need to copy not just the article, but also the disambiguation namespace. Your fallacy is to assume that only "articles" can be in the article namespace. Many lists and outlines are not proper "articles" either, nor is the Main Page. (Moving the Main page to a different namespace, say, portal or Wikipedia, is a proposal I would support, though). —Kusma (t·c) 13:29, 15 July 2019 (UTC)

Your fallacy is to assume that only "articles" can be in the article namespace. Huh???? That's a fallacy?

Many lists and outlines are not proper "articles" either. I don't know what you mean by "outlines" (perhaps you meant "stubs"?), but as already pointed up earlier, per Wikipedia:Manual of Style/Lists, lists are considered as list articles. Banana Republic (talk) 13:48, 15 July 2019 (UTC)

Outlines, like Outline of biology. Or one of the 500+ articles that transclude Template:Outline footer. Often also called a "rough sketch". The Banner talk 15:10, 15 July 2019 (UTC)

Per the nutshell in Wikipedia:Outlines, An outline is a list article, and hence would not be impacted by this proposal. Banana Republic (talk) 16:10, 15 July 2019 (UTC)

The nutshell states An outline is a list article, arranged hierarchically, that helps a reader learn about a subject quickly, by showing what topics it includes, and how the topics relate to each other. So even when you want to push this down to just a list, it is still a special type of list. The Banner talk 17:09, 15 July 2019 (UTC)

I'm still unclear about what benefit this will provide. From the readership POV, it seems like the best case scenario is for it to be exactly as good as it is now. From an editor POV, it seems like this only complicates things. Off the top of my head, it seems like we'd need a redirect page in place of the DAB page, so that errant links to seal, for example can properly get forwarded to Disambigution:seal. I generally dislike the phrase, "a solution in search of a problem" because it's often used dismissively, but this proposal sure seems like it qualifies. Could you specify what will be fixed? Matt Deres (talk) 16:03, 15 July 2019 (UTC)

I think it's a cleaner way to do things. If disambiguation pages are not considered articles, they should not be in the article namespace, and should be included in their own namespace (since they would not fit in any other existing namespace). Implementing this proposal would leave the main page as the only non-article in the article namespace (since redirects do not count anyway). Banana Republic (talk) 16:13, 15 July 2019 (UTC)

I get that aspect of it, but to what end? What problem are people having that this will address? Matt Deres (talk) 17:53, 15 July 2019 (UTC)

In reply to the post of 02:14, 15 July 2019 (UTC): yes - the notice at Wikipedia talk:Namespace#Disambiguation namespace and this refers to Wikipedia talk:Disambiguation/Archive 33#Dab page location which in turn refers to Wikipedia:Village pump (policy)/Archive 50#ALL disambiguation pages to end "(disambiguation)", Wikipedia talk:Disambiguation/Archive 31#Hatnote redirects to disambiguation pages. and Wikipedia:Village pump (policy)/Archive 84#Uniform Disambiguation page naming. Some of these discussions link to other previous discussions. --Redrose64 🌹 (talk) 19:49, 15 July 2019 (UTC)

• On the idea of somehow tying DAB to wikidata... OH HELL NO! Blueboar (talk) 20:00, 15 July 2019 (UTC)
• I'd oppose this. Seems like it would require a massive amount of work to implement a solution in search of a problem.--CNMall41 (talk) 22:14, 15 July 2019 (UTC)
• Also oppose. Not broken, WONTFIX/DONTFIX. Samsara 11:47, 16 July 2019 (UTC)

• Just throwing the option here, as I do see several problems with that as well: Our search functionality gives a pretty good 'disambiguation' for 'Mercury'. We could basically delete all disambiguation pages ánd redirects that point to disambiguation pages, upon which a search for 'mercury' will automagically bring you to a list of possible articles. Only problem is that http://en.wikipedia.org/wiki/Mercury does not bring you directly to a search result but to a 'create this page' result (but also that could be changed. (Now arguably a search result may be less informative than a properly sectioned disambig page). --Dirk Beetstra ^{T C} 12:00, 16 July 2019 (UTC)
  • This only works for individual words. For multi-word phrases, including human names, the search function is borderline unusable for disambiguation purposes. If you are searching for a "John Smith" it will give you every article containing the words "John" and "Smith", and will often bury clearly relevant results behind several pages of jumbled irrelevant results. Also, as you might note, for pages that have a primary topic, like Andrew Jackson or Los Angeles, searching for the title will take you to that primary topic, meaning that a disambiguation page is required (Andrew Jackson (disambiguation), Los Angeles (disambiguation)) to easily see other results. There are tens of thousands of disambiguation pages like that, with primary topics placing the page at disambiguated titles. bd2412 T 23:50, 16 July 2019 (UTC)
    • @BD2412: I already expected that there was something obviously stupid about my idea :-). --Dirk Beetstra ^{T C} 13:42, 17 July 2019 (UTC)
      • The deficiencies of the search function are actually not obvious at all, until someone does a lot of work using that search to set up disambiguation pages. There are some instances, where there is a single-word title with a small number of meanings which are all title matches, where this would work. On the other hand, if you look at a page like Seal, and then do a search for the word "seal", look how far down the search results you have to go to find the single most common meaning of seal, Pinniped. bd2412 T 15:55, 17 July 2019 (UTC)
• Oppose per the Banner. Disambiguation pages are in the mainspace because they are part of the encyclopaedia, like articles and redirects they are used by our readers. Other namespaces are for things that ultimately help build the Encycopaedia but are not part of it. If for statistical purposes we want to breakdown how many pages in mainspace are articles, how many are redirects and how many are disambiguations then I suspect that can be done by programmers. ϢereSpielChequers 09:04, 20 July 2019 (UTC)

As I have written elsewhere, it's not just about article count. It's also about keeping what is considered non-encyclopedic articles out of the article namespace. Banana Republic (talk) 00:01, 22 July 2019 (UTC)

This would involve moving literally hundreds of thousands of pages, and making thousands of other adjustments and fixes to existing templates policy pages, and reports. bd2412 T 00:22, 22 July 2019 (UTC)

That's correct, but it would be a one time thing, and in my opinion, worth the effort. I assume the bulk of the work could be automated. Banana Republic (talk) 01:13, 22 July 2019 (UTC)

• This is a solution in search of a problem. There is a moderate amount of movement between regular articles and disambiguations as new articles are created about people and things with the same name, and placing disambiguation in a separate namespace just complicates the process and obscures the history for no obviously useful purpose. The whole "they aren't articles" argument is an exercise in hair-splitting. Redirects aren't articles either, yet they reside in article space, and they are subject to a certain amount of movement between regular article status and redirects too. Somehow the encyclopedia manages to get along just fine that way. And on the Wikidata idea ... no. The whole WP/WD interface is a black box to most editors. Acroterion (talk) 03:54, 22 July 2019 (UTC)
• What counts as a disambiguation page vs article vs navigation aid is difficult to discern in some instances. It can be something of a grey zone, a matter of perspective. eg.
  ARD Digital -- GreenC
  04:42, 22 July 2019 (UTC)
• In my opinion, this is a good case for rejecting based on
  WP:IAR alone. So disambiguation pages do not belong in article space? What harm does it cause? As Acroterion notes above, this is an exercise in hair-splitting that provides little or no benefit to the encyclopedia. -- llywrch (talk
  ) 19:47, 25 July 2019 (UTC)

• Could you clarify what changes would be made to ensure "accessibility" is met? The word covers a potentially huge area, and I'd like to know what would be required. Adding a request for "accessibility" isn't as crystal clear as you may think! - SchroCat (talk) 09:20, 4 July 2019 (UTC)
• That sounds like something that's easier to say but harder to define: how would you define a more accessible FA in one word? ——SerialNumber54129 09:22, 4 July 2019 (UTC)
• Phil Bridger (talk
  ) 09:33, 4 July 2019 (UTC)

I was indeed not referring to that kind of accessibility, I'm referring to making articles as easy to read as possible while still including complex topics.

As to the wording, I now see that it would have to be defined more clearly than I stated it originally. The sixth requirement

WP:FA?

we could add: "b. Accessible: The article can be understood by a broad audience and explains technical terms in the article itself."

I'm not sure if the wording should differ between FA and GA, but I tried writing it such a way that the FA requirement for accessibility is "stricter" than the one for GA, although I recognize I might not have done a great job at that. The specific wording is tentative and open for input.--Megaman en m (talk) 09:48, 4 July 2019 (UTC)

Rather than try to add further rules onto an already rule-laden process without an indication of the problems, could you find some examples of FAs and GAs you see as problematic? Thanks - SchroCat (talk) 10:02, 4 July 2019 (UTC)

My proposal isn't intended to expose problematic GA or FA articles, rather it is aiming to rectify internal inconsistency between requirements and offer clarity to reviewers and nominators. I could find various instances of terms in GA or FA articles not being adequately described to a lay audience, such as "accusative morphosyntactic alignment" in

WP:B?, but that would not be the right way to go in my opinion.--Megaman en m (talk

) 10:41, 4 July 2019 (UTC)

One example I can think of is

WP:AUDIENCE, which says, among other things, Make your article accessible and understandable for as many readers as possible., which I think is exactly what Megaman en m is talking about. I'm not trying to shame this specific article or say it shouldn't have been promoted to FA, but I do think that providing context to the (non-expert) reader is still an area where this article could improve, and I like the idea of it being an explicit part of the FA/GA criteria (even if it's only briefly mentioned). Colin M (talk

) 16:47, 5 July 2019 (UTC)

I think your first step - if you want to pursue this further - is finding another term. For Wikipedia, accessibility is defined as linked above. You want something different, so for clarity that then needs another name. --Gerda Arendt (talk) 12:03, 4 July 2019 (UTC)

Accessibility would be the usual term for what I'm talking about, but if a paraphrase is needed, maybe just say that the article has to be "understandable"? That's the term used in the

essay on the perfect article describing the same concept.--Megaman en m (talk

) 12:44, 4 July 2019 (UTC)

If it's "understandability", then FAs should already be compliant - having at least five reviewers per article (normally from non-specialists, unconnected wth the subject matter) means that should be the case already. - SchroCat (talk) 12:51, 4 July 2019 (UTC)

Understandable is what is used by the relevant guideline, Wikipedia:Make technical articles understandable, and yeah, people are going to be confused if you use the word "accessibility" so I would recommend "understandability". Galobtter (pingó mió) 13:11, 4 July 2019 (UTC)

That's an interesting way of looking at it, I haven't considered that. But this still leaves GA "vulnerable" to the understandability issue, as the single reviewer is usually familiar with the general subject and might not consider the viewpoint of a layperson. For example, the reviewer of a video game article nominated for GA might not stop to think that a layperson might not know what experience points actually do.--Megaman en m (talk) 13:00, 4 July 2019 (UTC)

I don't believe that "The article can be understood by a broad audience" is always possible, so your proposal would exclude (from FA at least) some topics from being covered at all. For instance, an article I've worked on that is currently rated as B-class, Dehn invariant, has a lead that I hope can be read by mathematically-inclined high school students, but some later content (particularly "Realizability") that might well be difficult for undergraduate mathematics majors. That is not because of any intention to make the article difficult, but rather because after making it as easy to access as I could it was still difficult; it is a technical subject and some technicality is unavoidable. Should such articles be automatically barred from being at a higher class? Should there be no incentive to work towards making such articles better, because it cannot be rewarded with a higher class? —David Eppstein (talk) 18:47, 4 July 2019 (UTC)

I agree with

Phil Bridger (talk

) 19:14, 4 July 2019 (UTC)

It is of course the case that any article should be able to attain FA status, in principle. Some topics reasonably require some preexisting knowledge for the more basic concepts; if we had to explain every single piece of jargon in an advanced article about genetics, the article would become unmanageably long-winded. My proposal is that a serious attempt is made to avoid these technicalities or explain them when possible (e.g. when it can be adequately explained in a sentence or two). If the concept needs to be mentioned, is complex, and can't be explained shortly, then a simple wikilink is all we can do.

For example, a language article should not explain what a noun or tense is. But, when it comes to terms like "accusative morphosyntactic alignment" mentioned above, even someone with a introductory knowledge in linguistics might be left scratching their head. I recognize that it might be difficult sometimes to determine what a "basic" concept is versus a more advanced one, but that alone shouldn't be a reason to can the proposed understandability requirement. As a side-note, more complex concepts should preferably be mentioned near the end of the article; the introduction should

ease people into the topic at hand, not scare them away.--Megaman en m (talk

) 19:18, 4 July 2019 (UTC)

Yes, "can be understood by a broad audience" might be too strong a requirement. But

WP:B? uses the wording The article presents its content in an appropriately understandable way. It expands on that by saying It is written with as broad an audience in mind as possible. Although Wikipedia is more than just a general encyclopedia, the article should not assume unnecessary technical background and technical terms should be explained or avoided where possible.. I think wording along these lines would address your concern, and not automatically exclude any articles about technical subjects out of the gate. For a highly technical subject "as broad an audience as possible" might actually be pretty narrow, and should be considered in light of the set of readers who are likely to actually reach the page. Someone with only a very basic math education is unlikely to reach Dehn invariant, so their ability to comprehend the article's content shouldn't be a strong consideration. Colin M (talk

) 17:17, 5 July 2019 (UTC)

I might call it "readability". But I think at least most regular FAC nominators at least hope that reviewers will help out on this. I know as a lawyer I have a tendency to use jargon in my field. That has sometimes led to reviewers going "huh?" I'd like to say "we're already doing this" but I'm waiting really for actual examples in recent FAs.--Wehwalt (talk) 23:47, 4 July 2019 (UTC)

Readability is the closest thing I could think of, where there is a score generated on a readability scale. Alanscottwalker (talk) 00:00, 5 July 2019 (UTC)

Readability is a related – and useful – concept, but it's not what I'm talking about exactly. Readability would readily fall under the current "well-written" requirements.

Responding to Wehwalt: Someone pointed out that the fact that FA requires multiple reviewers who are usually not knowledgeable; this sort of fixes the understandability problem nicely. However the problem still remains for GA articles, due to the fact that it only require single reviewer who usually is knowledgeable about the subject. I would also like the requirements for all the classes to be internally consistent. By that I mean that a lower class shouldn't have a requirement lacking in higher classes (I'm talking about the 6th requirement in

WP:B?

.

Long story short: I now think that the understandability requirement is not practically necessary for FA class. However, for reasons of consistency and the reviewing process, GA would still benefit from this requirement for the reasons mentioned above.--Megaman en m (talk) 07:47, 5 July 2019 (UTC)

The B-class criteria "presents its content in an appropriately understandable way" and that "it is written with as broad an audience in mind as possible." are reasonably practicable and reasonably clear in intent. How they would be interpreted in any specific case will depend on the topic. Is there any reason to assume that B-class criteria no longer apply when an article is proposed for GA and FA? Feedback on what is appropriate and possible should come from someone who has the background necessary for the target audience. This is usually a person who is not already an expert, but in many cases must have some existing understanding of the broader level of the topic. When there is uncertainty or disagreement among reviewers, it could be useful to first come to some agreement on who is the target. The proposer should have a reasonably good idea of this, and should be able to explain why. · · · Peter Southwood ^(talk): 08:23, 5 July 2019 (UTC)

Because B-class doesn't require peer review, there is a good chance some B-class articles don't fully comply with the B-class requirements. GA is where, for the first time, the adherence to the requirements get scrutinized by an impartial reviewer. Therefore, it should at least contain all the requirements from lower classes, including understandability. The average (knowledgeable) GA reviewer will focus on more on the listed requirements, especially prose, grammar and sourcing. Understandability might fall through the cracks and be "re-discovered" during a potential FA nomination.--Megaman en m (talk) 08:39, 5 July 2019 (UTC)

• Whole-heartedly support this. This is already a factor I consider when doing GA reviews (and I imagine many others do too, even if subconsciously). You could argue that this already exists in the
  WP:AUDIENCE, which expands on why and how to make an article "accessible and understandable for as many readers as possible". Colin M (talk
  ) 16:57, 5 July 2019 (UTC)

So do most people agree that the sixth requirement of

GA requirements? It doesn't have to have its own section.--Megaman en m (talk

) 06:34, 6 July 2019 (UTC)

• I certainly agree that an article that could practically be written in such a way that a broad audience could understand it, but is not, should not be FA and perhaps not GA. My concern is, who exactly is judging the extent to which it can be written non-technically?
  Aside: This is a perennial problem with the {{technical}} template. Very frequently it is added to articles with no indication of how understandability could be improved, or even where the article fails to be as understandable as possible. The simplest explanation seems to be that the tagging editors don't understand the material themselves, and for that reason suppose that there is something wrong with the exposition, which may or may not be true but which they are not equipped to judge.
  So either you give non-technical reviewers veto power over promotion of technical articles, or you ask them to simply trust the judgment of experts that the material is presented as clearly as possible. I can't say that either of those options is especially attractive. --Trovatore (talk) 08:06, 6 July 2019 (UTC)
• I'm leaning oppose on this proposal given
  FACR
  could be interpreted to already imply an accessibility requirement:

its prose is engaging... (from 1a)

it neglects no major facts or details and places the subject in context (from 1b)

(Emphasis mine on both)

If the prose is engaging, it engages a general audience, which would imply that a general audience could understand it. If the subject is placed in context, then a person sufficiently aware of the context from the article could then understand the details.

Having said all of that, I would not vociferously oppose the proposal if the consensus evolved to overwhelmingly favor it. – John M Wolfson (talk • contribs) 05:31, 7 July 2019 (UTC)

@

unnecessary detail" can run into similar problems. In short: I believe that any potential downsides are outweighed by the upsides of having both the reviewer and nominator keep the broadest audience possible in mind.--Megaman en m (talk

) 07:46, 7 July 2019 (UTC)

@Megaman en m: Well, I guess that answers part of my concern, but the deeper issue here is, how is a reviewer, not having the background needed to understand the topic of the article, expected to judge whether it is written appropriately for the intended audience? Can we specify that such a reviewer is expected to ask for expert help on such matters? --Trovatore (talk) 22:21, 10 July 2019 (UTC)

@

WP:B?. I find technical papers on linguistics engaging, but I wouldn't have a non-expert read them. They also place the subject in the right context, although they usually do so by introducing even more jargon. An understandability requirement is not currently covered by other FA/GA requirement and would help people in the reviewing process focus on the important task of keeping the intended audience in mind.--Megaman en m (talk

) 07:46, 7 July 2019 (UTC)

@Megaman en m:, that does somewhat assuage my fears of writeability for niche topics. As for placement in the right context with linguistics (basic grammar, etc.), I guess that's what internal links are for. – John M Wolfson (talk • contribs) 07:52, 7 July 2019 (UTC)

@John M Wolfson: Internal links are useful, but they should primarily be for people wanting to read more about that topic rather than "required reading material". They should only be relied upon as a last resort.--Megaman en m (talk) 08:08, 7 July 2019 (UTC)

It all depends. There are what I call "101 articles" (from the classic designation for basic university courses in the US) that should not assume much knowledge. Then there are "202" articles that have "prerequisites" when it comes to knowledge and may have to rely on links for basic concepts, and possibly higher numbers as we get more specialized. Some articles are hybrid, an article on a ship may be "101" when it comes to its history but "202" or more when it comes to the ship's specifications and equipment. While we don't have as much information on reader reaction as I would like (I supported the old feedback tool), FA nominators and reviewers have seen a lot of talk page comments, reactions on TFA day and other people's reviews, and do a good job in gearing things properly. I'm just not certain what we are supposed to do differently.--Wehwalt (talk) 11:01, 7 July 2019 (UTC)

I think most editors instinctively understand that a GA should of course also satisfy the general

The last point, which Megaman en m has discovered, is because GA1b doesn't require full MOS-compliance but only certain sections, not including

Another thing one might add to the GA criteria, and which might actually be enough on its own: Normally a GA should should satisfy the B-class criteria of the appropriate WikiProject(s). But this should be clearly marked as something GA reviewers don't have to check. It would be significant extra effort and could have unwanted effects where WikiProjects have strange ideas about B-class criteria (e.g.: may only use

To move this discussion forward, I started a voting process.--Megaman en m (talk) 10:30, 8 July 2019 (UTC)

Can the lack of opposition be taken that most people are okay with this proposal?--Megaman en m (talk) 19:19, 14 July 2019 (UTC)

No. (See also

WP:POLSILENCE

.)

As for me, I'm not necessarily opposed, but I don't feel my concerns have been adequately addressed. --Trovatore (talk) 19:41, 14 July 2019 (UTC)

I don't think you've made your case about FA, and from the comments, I didn't see much of an attempt to have a change to WP:WIAFA. I don't have an opinion on GA.- (Wehwalt) -19:44, 14 July 2019 (UTC)

@

WP:AUDIENCE. As for your other concern, first the nominator should make the case that the article can't reasonably be written for a broader audience. In this case, where the reviewer doesn't have the necessary knowledge, it should be expected of them to either ask for expert help, or do some basic research on their own. I have changed the proposal to reflect this.--Megaman en m (talk

) 13:47, 16 July 2019 (UTC)

@Wehwalt: The case for FA rests on being consistent with lower classes. It is indeed weaker than the case for GA due to FA having multiple reviewers, which is why the proposal has come to focus on GA.--Megaman en m (talk) 13:47, 16 July 2019 (UTC)

How do I proceed now? Is this enough to move on to how the wording for understandability in GA should be implemented?--Megaman en m (talk) 07:08, 20 July 2019 (UTC)

@

WT:GAN. Just a thought. Colin M (talk

) 16:57, 22 July 2019 (UTC)

Started a topic to discuss implementation for GA.--Megaman en m (talk

) 09:13, 24 July 2019 (UTC)

Why?: "Understandability" is very important, yet it is not specifically required for FA or GA status. This new requirement will help people in the reviewing process keep the average reader. This will also improve consistency between the classes.--Megaman en m (talk) 10:30, 8 July 2019 (UTC)

Vote

• Support (as proposer) With GA usually being the first time that an article undergoes peer review, the reviewer should pay just as much focus on understandability as grammar and sourcing. The FA review technically fixes this problem by having multiple reviewers act as they lay audience reading it for the first time, therefore "correcting" it for understandability. The single reviewer for GA is usually knowledgeable about the subject, which could cause them to overestimate the background knowledge of the average reader. I still believe that understandability deserves a mention in FA, even if just for the sake of internal consistency between classes.--Megaman en m (talk) 10:30, 8 July 2019 (UTC)
• Support for the reasons I wrote above. I think the most unobtrusive way to do this would be to add a few words to
  WP:AUDIENCE. A whole new subcriterion of 1 (i.e. 1c) would also be fine, though that would require some template changes. Colin M (talk
  ) 22:09, 8 July 2019 (UTC)
• Pending. I could support this if it were clarified that understandability is relative to the inherent difficulty of the material, and that reviewers without the background needed to understand the material should ask for expert help in evaluating this criterion. ---Trovatore (talk) 20:00, 14 July 2019 (UTC) Support as amended. --Trovatore (talk) 16:47, 16 July 2019 (UTC)
• So the above started about accessibility which makes some sense to me as a possible GA criteria. However this specific language is about how things are written which I had always assumed was covered in GACR 1A. So I'm in the abstract in favor of some language around accessibility but think this specific language is already covered. Best, Barkeep49 (talk) 16:06, 16 July 2019 (UTC)

• To be clear, this proposal was never about "accessibility" in the sense of
  state the obvious, don't use unnecessary jargon (and when it is necessary, explain its meaning). Colin M (talk
  ) 16:20, 16 July 2019 (UTC)

• With the proviso that sometimes the explanation of the jargon will necessarily use other jargon, and we can't always trace it all the way back to the beginnings of the subject without making the article useless to those it's potentially useful for. --Trovatore (talk) 16:49, 16 July 2019 (UTC)

• Support Bit late to the show, but I think this is a very important criterion in general for articles and I welcome any extra focus on it, especially in GAs and FAs.
  talk
  ) 15:32, 31 July 2019 (UTC)

This would enhance civility and prevent users shying away. Although it is manually possible to make your own custom award, a template would encourage more and promote a crucial attribute currently lacking in this community. THE NEW ImmortalWizard(chat) 19:13, 22 July 2019 (UTC)

I wouldn't consider a templated apology to be a real apology. Much better to simply apologise in your own words, relevant to what is being apologised for. Anyone who is qualified to edit an English-language encyclopedia should be capable of writing a couple of sentences in English without a template.

Phil Bridger (talk

) 19:22, 22 July 2019 (UTC)

I'm inclined to agree. If you've made a sufficient error to warrant apologising, I wouldn't be impressed if I just received a template one. Nosebagbear (talk) 20:58, 22 July 2019 (UTC)

@

Phil Bridger: I don't think ImmortalWizard is referring to templates here. This seems more akin to Barnstars which require a personalized message. @ImmortalWizard: you could theoretically already enact your proposal by giving a user a kitten, goat, or the custom option. I know plenty of users send kittens already as a way of saying sorry. However, we could add something like "Apology cake" to the food and drink section. It'd involve getting a good picture of a cake that says sorry, but that'd probably be more doable. It'd also overtake Baklava as listed first among the foods... though I have mixed feelings about that. –MJL ‐Talk‐^☖

18:05, 31 July 2019 (UTC)

Apologies IMHO don't need pretty flowers and fancy colours etc - A simple black and white apology should be enough. –Davey2010^Talk 18:30, 31 July 2019 (UTC)

Moved to

WP:AN § What should we do to 2607:fb90::/32 (moved from VPPR)

 – Enterprisey (talk!

) 08:54, 3 August 2019 (UTC)

Whoa, this range is affecting billions of T-Mobile users. The block is too long, what should we do? Should we shorten it or extend it? 2600:1702:38D0:E70:B4CD:9550:507:3ED1 (talk) 18:12, 2 August 2019 (UTC)

Background...
Working with the newly constituted WP:WikiProject Climate change I ran into a long term maintainence headache at

• Index of climate change articles versus
• Glossary of climate change versus
• Category/Climate change

A very superficial looking around suggests other subject areas have similar un-synched overlap.

This suggests the following problems...
A. There is too much overlap but not enough synchronicity between

• Categorization of a subject's articles
• Indexes of a subject's articles
• Glossaries of a subject's terms

B. The three bullets above require three different manual edits (There is a fourth edit which isn't presently involved in the problem but is a part of the solutiuon, and that is adding a short description to each article.)

C. Glossaries I have looked at all fail

Proposed unified solution
1. Provide a window of time for editors to verify entries on an index are properly categorized, and after the time period auto-replace all manual indexes with bot-generated indices based on categorization (assuming an index isn't just redundant in the first place)

2. Same as 1 but for glossaries. In addition to verifying categorization, verify each article's short description is suitable as a brief glossary explanation

3. When the bot auto-generates the glossary, it looks up and copies the articles short description from Template:short description

Advantages....

• Instead of four steps to make a glossary + index + category + short description there are just two, tagging the articles for categories and adding the short description
• There will be automatically be a 1:1:1 relationship between index, glossary, and category entries
• Glossaries still won't have references, but odds are that glossaries are built with little peer review, whereas articles have a lot more watchers. Presumably the short descriptions will be more accurate due to the increased peer review from other eds.
• Article short descriptions and glossary text will automatically remain in sync.
• Urges editors to verify that all articles in a given subject area have good short descriptions (a goal included in the template's documentation)
• After implementation, simply adding short descriptions and category tags takes care of all of this, while the bots maintain synchronicity between all four tools (indexes, glossaries, cats, and short descriptions). Super simple.

Comments, questions, discussion?

• Support as proposer
  NewsAndEventsGuy (talk
  ) 02:48, 1 August 2019 (UTC)
• I don't think this will work for many areas. We have relatively few glossary and index articles in fact - still fewer areas with both -and where we do the articles will often be spread over several categories, and many if not most of the index articles shouldn't be in the glossary. So "There will be automatically be a 1:1:1 relationship between index, glossary, and category entries" doesn't necessarily strike me as a good thing. Both index and glossary articles are typically rather neglected in areas I work in, and not much viewed. It may be different elsewhere (actually looking at some, I see decent views for some glossaries). Johnbod (talk) 03:17, 1 August 2019 (UTC)

Thanks for commenting, those are easily overcome, I think.

For your first point, without examples, we're guessing. The climate change subject can be parsed and diced into different subcats, but there is still the mother category "climate change". I have a hard time believing a subject that is sufficiently one thing to have either an index or a glossary lacks a similar mother-of-all super category that catches everything. It must exist, so future bot generated index or glossaries could be based on that super category. Can you find an unfixable example that disproves this assumption?

Re your second point (maybe an index entry should not be a glossary entry) that's a good point. For subjects with both an index and a glossary right now we have editors thinking and pushing the right buttons so the index and glossary has intentional mismatch. The next editor might not maintain that mismatch because there is no record of the thinking by the first editor. Voila! Just add a parameter for the super-category template to suppress inclusion when the bot runs the glossary or the index. Then editors can still think and push the right buttons to get that outcome, and we can still enjoy the advantages I described, and future editors will see a record of the first editor's work to suppress glossary inclusion.

NewsAndEventsGuy (talk

) 03:30, 1 August 2019 (UTC)

• I haven't had time to consider this proposal fully, and probably won't for a few days, but in general I agree that the overlap between Index, Categories, and Glossaries (I would even throw in Outlines and Portals to the set) is something that needs more consideration. These pages duplicate the features and purposes of many others, and this is not ideal because it means things very quickly get out of sync and are hard to maintain as a set. At first glance, I like 1 and am unsure of 2 and 3 (mostly because I'm not sure short descriptions are reliable for that), but I'll think about it more. Wug·a·po·des​ 03:47, 1 August 2019 (UTC)

Yes, not only are short descriptions mostly currently written by dedicated non-specialists driving-by, they are almost always too short, vague and non-descriptive to be usable in a glossary. Restricting the idea to auto-compiling indexes from categories ought to be simpler & might be a good idea in some cases, though I suspect it might make many too long to be very useful. Johnbod (talk) 11:02, 1 August 2019 (UTC)

PROPOSER says.... Current practice is not an obstacle to reforming current practice, so that's something of a circular argument. Both short descriptions and glossaries are insufficiently vetted - not enough eyeballs, not enough source-checking. Sure, this proposal would change the word choice for some short descriptions, maybe. It would also increase care and attention put on both glossaries and short descriptions, which would be a good thing for both.

NewsAndEventsGuy (talk

) 11:47, 1 August 2019 (UTC)

Yes, so basically you are proposing a huge amount of work, needing to be done by relatively specialized editors, on articles that fairly few look at. Looking at some more index articles, I think quite a high proportion should be moved to draft space or user space until they can be brought to a useful level of completion (by automation or otherwise). Look at the completely useless Index of Renaissance articles, last edited in Feb 17, & about 1% complete. But I'll shut up now & see what others think. Johnbod (talk) 21:19, 1 August 2019 (UTC)

Not only are our index articles useless as they stand (

outlines at least have a hierarchy, so it helps with navigation; I can't think of any reason I would ever be looking for an article in a particular topic alphabetically. Caeciliusinhorto (talk

) 22:01, 2 August 2019 (UTC)

• Some thoughts:
  1. On the one hand, both editors & users need something like an index or portal to find related topics that our current best tools -- namely hyperlinks, navboxes, & the category system fail at. There have been many times that even after a diligent search I've failed to discover existing articles related to the one I'm working on.
  2. On the other hand, indices/portals/outlines/lists fail because they are hand-made, not automated. It's a lot of tedious & error-prone work compiling one of those pages. Then they must be maintained & kept up to date; people have been known to stop contributing to Wikipedia, often with no notice.
  3. But until we have some kind of automated tool to create a guide to subjects -- say a means to apply the information at Wikidata, while retaining some kind of oversight, or an easy ability to modify the facts there -- we're stuck with what we have. (Yeah, we could insist that WMF fund such an application, but I've been waiting for them to provide a comprehensive guide to Wikipedia templates, & it's been at least 10 years since I first suggested that.) -- llywrch (talk) 19:47, 2 August 2019 (UTC)
• Should not use short descriptions this way. Short descriptions are to be kept short, less than 40 characters, as they are targeted for mobile devices, etc. That requirement limits their use in any other area, as in this proposal; to be that short, they can (and often do) violate normal encyclopedic uses, such as skimping on proper grammar, overgeneralizing, etc. Worse, having multiple conflicting missions for short descriptions encourages changing them so as to be less useful for their intended primary purpose. Now, if we want to start a new "short description-ish" system for more general purposes as in this proposal, that would be okay; we could even allow one system default to using the description provided by the other if that's all that's available. (Maybe the current short description should be renamed mobile description to emphasize its more narrow specific purpose?) (And yes, I know many current short descriptions are not short; it's a very new system with teething problems, but we should assume these will be worked out. See Wikipedia_talk:Short_description#Should_a_short_description_define_or_distinguish?) --A D Monroe III^(talk) 16:27, 3 August 2019 (UTC)
• If only we had a linked-, open- data repository, and a tool to build Wikipedia pages from it. Oh, wait, we do: Wikipedia:Listeria. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:46, 3 August 2019 (UTC)

I periodically see {{Multiple issues}} transcluded on an article with only one top-of-article issues template, e.g. see this revision of the Hot or Not article. Would it be worthwhile to have a bot go around and remove this template in such situations, both a one-time run now and periodic runs in the future? The point of a cleanup template is to draw attention to the problem in question, but {{Multiple issues}} doesn't do that — of course that's all right if there are lots of issues, but with only one issue the template doesn't particularly help, and also it looks rather silly to the reader to say "This has multiple issues" and then give just one. "What else is wrong with the article?" one might think. From a technical perspective, this should be really easy: get a list of all pages transcluding this template, check each one, remove template if it's encasing one or zero cleanup templates, and don't touch template if it's encasing two or more templates. Nyttend (talk) 22:44, 22 July 2019 (UTC)

Maybe {{

Phil Bridger (talk

) 17:54, 23 July 2019 (UTC)

I suspect the most frequent cause of this is that a page with a originally appropriate multiple issues template, has had some of the issues removed. I've done this hundreds of times, but I've only thought once or twice to remove the multiple template also. Now that I see it's posing a problem, I'll do this, but it would be more practical do do this by a program. DGG ( talk ) 17:02, 26 July 2019 (UTC)

A smart {{

b

} 21:09, 26 July 2019 (UTC)

I created a prototype Lua module here: Module:Sandbox/MarioGom/Multiple issues. This will take two parameters. If the first parameter contains a single or no template, it will return the first parameter. Otherwise, it will return the second, which would be the wrapped version. I'll try to get this prototype to a full template version. Should I create it on Template:Multiple issues/sandbox or somewhere else? Best, --MarioGom (talk) 23:42, 26 July 2019 (UTC)

Phil Bridger, DGG, and Headbomb, what do you think of the module that MarioGom has created? Sorry for the days of delay; I just thought of this after removing another non-multiple occurrence of the template. Nyttend (talk

) 12:02, 3 August 2019 (UTC)

Unfortunately, the approach MarioGom has taken here doesn't actually work, because Lua modules get their input post-template-expansion and thus don't see any curly braces to check. * Pppery * _{it has begun...} 14:19, 3 August 2019 (UTC)

:-( In that case, is it time for a bot request? Nyttend (talk) 19:06, 3 August 2019 (UTC)

It should be

@Monniasza:  Done. Next time, please use {{rename media}} to request that a file be moved. --AntiCompositeNumber (talk) 11:40, 11 August 2019 (UTC)

My hovercraft is full of eels. --Redrose64 🌹 (talk) 16:42, 11 August 2019 (UTC)

Some articles end up with multiple

Some of them have specific sanctions, eg Template:ArbCom Arab-Israeli enforcement. I'm not sure what's confusing about having several on a page. --Doug Weller talk 18:10, 11 August 2019 (UTC) reping @Sakkura: --Doug Weller talk 18:12, 11 August 2019 (UTC)

A container box like we have when multiple wikiprojects would not be bad, it can lead off "This article is subject to multiple discretionary sanctions:" and include each notice. --Masem (t) 18:14, 11 August 2019 (UTC)

The DS talk page banners are technically useless anyway. Per

NewsAndEventsGuy (talk

) 18:17, 11 August 2019 (UTC)

I think there should be a warning at the top of a preview of an edit if there is a broken reference name. I have been spending a lot of time going through the huge backlog of pages with broken reference names, and have found that many of them occur when someone copy/pastes text from one article to another and forgets to grab the parent reference. Also, there are some cases where someone mistakenly puts the name of a book or publication in the <ref name> parameter. I think most people don't scroll down to the bottom of the page to double-check the reference section if they preview their edit, and this could solve the problem. It would only take another minute or two for the editor to find the parent reference in this case, whereas when someone else has to hunt down the reference a year later, it can take a long time. I wasn't sure if this was something I should post about here or on Phabricator, so let me know if there's a better way to proceed. Secundus Zephyrus (talk) 19:29, 24 July 2019 (UTC)

A warning would be a very good idea. This has been a problem for years and there has been some progress. AnomieBOT's OrphanReferenceFixer manages to fix many of these errors or we would be inundated. See the log here. For a while there was another bot, ReferenceBot, which would leave messages on editors' talk pages about errors AnomieBOT couldn't fix. However it has not been running since Feb 2017. StarryGrandma (talk) 04:15, 25 July 2019 (UTC)

+1

b

} 04:32, 25 July 2019 (UTC)

This would be a great improvement. Auto-detection of failure to include the pesky "/" at the end of <ref name> where needed would also help. RobDuch (talk·contribs) 07:01, 25 July 2019 (UTC)

Agreed. This is especially important when editing a section (not the whole page where all refs are visible) and forgetting to check for other sections where refs may become orphaned. ComplexRational (talk) 19:42, 29 July 2019 (UTC)

ComplexRational, I hadn't even thought of that possibility, that's a great point. --Secundus Zephyrus (talk) 20:29, 29 July 2019 (UTC)

All great ideas above. Does someone with technical background know how these warnings above the preview window are generated in Lua? --Hecato (talk) 10:23, 25 July 2019 (UTC)

• Hmm, >3,000 articles in this situation. Looks like I should bend some time toward the mop-and-bucket part of my activities. --User:Ceyockey (talk to me) 21:57, 30 July 2019 (UTC)
• Yes, please. I admit even I'm guilty of this. I've tried to pay it forward, but it's just too much. That category is huge. –MJL ‐Talk‐^☖ 18:07, 31 July 2019 (UTC)

  I'd really also want to see action on folks trying to fix the common errors with

  WP:LDR. –MJL ‐Talk‐^☖

  18:13, 31 July 2019 (UTC)

• Strongly support. Far too many editors guilty of adding undefined refs. DuncanHill (talk) 18:16, 31 July 2019 (UTC)
• Support - I always check refs once I'm done but I assume I'm the 1% minority :P, –Davey2010^Talk 18:27, 31 July 2019 (UTC)
• Oppose as proposed. The idea is good, but if a page already has a broken reference, this will confuse newbies and a good share of experienced editors. If there's a way to show the warning only if the error's new (i.e. before the edit there were no warnings, but the previewed content would have one), I would readily support doing that. Nyttend (talk) 19:10, 3 August 2019 (UTC)

Nyttend, that's a good point. I wonder if it can be worded in a less-scary way that might strike a balance between the newbies and the experienced editors? The reason I ask is because I've come across pages with broken references going back years, and I think if an experienced editor got a notification of an old error, they might be more likely to try to fix it if they have the time. --Secundus Zephyrus (talk) 18:55, 11 August 2019 (UTC)

There's an open proposal on Meta to run a CentralNotice banner on Wikipedia and certain other Wikimedia projects from September 1 to September 30 in order to publicize the Wiki Loves Monuments photo contest, as has been done in previous years. Please comment on the proposal at m:CentralNotice/Request/Wiki Loves Monuments 2019. --Yair rand (talk) 06:10, 14 August 2019 (UTC)

I started a discussion at

I have created User:Crouch, Swale/Bot tasks/Civil parishes (current)/Simple which is the current model, there is also User:Crouch, Swale/Bot tasks/Civil parishes (current)/Coded and User:Crouch, Swale/Bot tasks/Civil parishes (current) which provide more instructions and some arguments for an against for bot created articles at User:Crouch, Swale/Bot tasks/Civil parishes (current)#Process.

There are 2 questions here, who has the understanding to program such a bot and are there any other things that need to be improves/changed to ensure that this works correctly or to otherwise improve the articles.

It would be good if eventually we could do the same thing for places in other countries to but we'll start with England for now. Crouch, Swale (talk) 12:02, 5 August 2019 (UTC)

I call

WP:OTHERPARENT on this: although Crouch, Swale has linked Wikipedia:Bot requests#Civil parish bot, they fail to link the other places where they've requested this, such as Wikipedia talk:WikiProject England/Archive 4#Bot created articles. --Redrose64 🌹 (talk

) 20:53, 5 August 2019 (UTC)

Not quite

b

} 03:19, 6 August 2019 (UTC)

• Comment I'm not sure that this is the most necessary bot in the world (I don't believe that the US counties were created by a bot, for example), but nor do I adamantly oppose it on principle if all of the kinks get worked out. – John M Wolfson (talk • contribs) 00:34, 7 August 2019 (UTC)

• Weren't the US counties created in the same way as the settlements, it looks like Ram-Man didn't have a separate account for the bot until later [4][5]. Anyway indeed the bot shouldn't be approved until we're sure its OK. Crouch, Swale (talk) 17:15, 8 August 2019 (UTC)

• Based on my instructions does anyone have the ability to construct a code for the bot? If that can be done then we'd be going in the right direction to see if there's consensus. Crouch, Swale (talk) 08:00, 10 August 2019 (UTC)

  I've notified BON. Crouch, Swale (talk) 11:07, 13 August 2019 (UTC)

  @Crouch, Swale: I might be able to code such a bot, but I need some more info. Your /simple, /coded, and (current) are confusing. Can you please create: 1 full fledged example article (what the bot should be able to produce) and 1 "shell" with the content that would be common to all of the articles? (Like every single one will have == References == and {{Reflist}} DannyS712 (talk) 11:13, 13 August 2019 (UTC)

  @DannyS712: I have created User:Crouch, Swale/CP example which is an example "full fledged article" (although the categories obviously wouldn't be disabled). In the User:Crouch, Swale/Bot tasks/Civil parishes (current)/Coded example the words that aren't in "" are the content that would be common to all articles. In other words all articles will have the text "The parish touches" but the names of the parishes will be variable. The example given (Rattlesden) is one that already exists but illustrates how it would be created if it didn't exist. Note that I have removed the notes from the coded one but they'll stil be useful to the bot operator. Crouch, Swale (talk) 11:35, 13 August 2019 (UTC)

  @Crouch, Swale: Okay. So I see it as a shell that needs the following parameters:

  1. Name (without disambiguation)
  2. Region
  3. Centre point from City Population
  4. District name
  5. County name
  6. Population
  7. Area
  8. District name (with disambiguation)
  9. Touching parishes
  10. Number of listed buildings

  and, for each article, the title at which it should be located. It seems fairly straightforward, as long as all of that information can be retrieved in a usable format. Do you have a good way to get that data? If so, I'd be willing to fulfill the bot request, provided that there is indeed consensus for it. DannyS712 (talk) 11:58, 13 August 2019 (UTC)

  @DannyS712: these are explained at User:Crouch, Swale/Bot tasks/Civil parishes (current)/Simple but I'll add a bit here.

• Name (without disambiguation)

  If the title isn't disambiguated then this will be the same as the title (as with the Rattlesden example) if the title is disambiguated (such as Boxford, Suffolk) then that will need to be removed from the "official_name" "civil_parish" and the bold face at the beginning. In other words for the Boxford, Suffolk example all 3 would just be "Boxford" not "Boxford, Suffolk" that is to say the name used on City Population.

• Region

  The name of the region given in City Population which is not linked in the infobox for example "East of England" or "North East".

• Centre point from City Population

  This is the middle (centre) point of the area given for the parish at City Population, if its not possible for the bot to get that then the coordinates from the Ordnance Survey linked data can be used. This is also used to measure the distance from the county town.

• District name

  The title of the district (which might be disambiguated) for example linked as Babergh (and Category:Babergh) if not disambiguated but Arun (and Category:Arun District) or Stafford (and Category:Borough of Stafford) if it is. Remembering also if its a unitary authority.

• County name

  Milton Keynes

  .

• Population

  The 2011 figure given by City Population, which is omitted if City Population doesn't give any data (mainly for parishes of less than 100) also noting that the sentence "In 2011 the parish had a population of X" is removed.

• Area

  When you click on an entry at City Population it gives the area (which is 13.2 for Rattlesden). This is only added to the infobox.

• District name (with disambiguation)

  As with the district name above this means that the district article (and/or category) might be disambiguated as explained above, if the article is then it needs to be piped in text as explained.

• Touching parishes

  The names of the other parishes the parish touches (which may be disambiguated) the bot works out the correct article by checking the coordinates of the target article or if it can't just linking to the unqualified name which I can fix.

• Number of listed buildings

  From the listed buildings site (although the English Heritage site might be a better option but can be discussed later) namely by finding the parish from here by region then county/unitary authority then parish (and the coordinates for the buildings can be compared to those from the OS to ensure the correct parish has been found). Crouch, Swale (talk) 18:56, 13 August 2019 (UTC)

  @Crouch, Swale: I understand what they stand for. My question is if you have a spreadsheet or other place where all of the applicable data is. I'd prefer not to manually input the 2011 figures, etc. DannyS712 (talk) 03:14, 14 August 2019 (UTC)

  @DannyS712: all of the 2011 figures are at City Population by region, at South East, London, North West, East of England, West Midlands, South West, Yorkshire and the Humber, East Midlands and North East on the "Population Census 2011-03-27" row eg for Workington its 25,207. Those (such as Wythop) don't have population data but do still have the area (if you click on the area). Crouch, Swale (talk) 07:22, 14 August 2019 (UTC)

  @Crouch, Swale: for South East, I made User:DannyS712 test/parish.json, which has the data from the link you posted above. But, making that took a lot longer than I thought. If you want me to help with this, I need all of the data in one place (not population from one source, coordinates from another, etc) in a bot-readable format (ideally json). --DannyS712 (talk) 08:59, 14 August 2019 (UTC)

Hi everyone, I just wanted to propose for a debate section in the talk pages of ongoing issues like the Hong Kong crisis article. This would enhance views from different people across the world and this would encourage boldness from people who previously feared editing hence bringing the vision of Wikipedia's 'Be bold'policy to a realization. Thank you -

Wikipedia is not a forum. I would think a debate section would be near the literal definition of a forum. --Izno (talk

) 03:16, 15 August 2019 (UTC)

Yes, a talk page is not the space for a debate or any general discussion of the article's subject. However, if such a section is devoted to analyzing the viewpoints of sources with different biases and their worthiness of inclusion in articles, it may be a good idea (as long as it does not stray to personal opinions, in accordance with

talk page guidelines). Those types of discussions are in the nature of a talk page. ComplexRational (talk

) 09:24, 15 August 2019 (UTC)

Compulsive masturbation has diagnosis criteria, so it is encyclopedic. Please make article about compulsive masturbation which will replace redirect. — Preceding unsigned comment added by Monniasza (talk • contribs) 17:28, 14 August 2019 (UTC)

You can do it yourself! See Help:Your first article for advice and details. Anomie⚔ 11:14, 15 August 2019 (UTC)

Some topic categories do not have a main article. For example, the article

which casts light on most documenteries - perhaps not what was intended. In any case, I simply added the {{where}} cleanup tag. That tag was accepted, but did not add the category into any cleanup categories. I suggest it should (for most cleanups), though I do understand this might require a different title, due to the way cleanups are counted.

An alternative, is to require every topic category to have an associated (possibly shared) article where all statements can be properly sourced.

Dpleibovitz (talk) 21:37, 20 August 2019 (UTC)

I am confused about the premise here... wouldn’t the article Documentary film be considered the main article for category:documentaries? Blueboar (talk) 22:00, 20 August 2019 (UTC)

No, that would be the main article for Category:Documentary film. However, Category:Documentaries reads like a set index article or disambiguation page - there are many kinds of documentaries, with film being just one of them. There really should be a separate (stub) article, where issues such as biasing (for all kinds of documenteries) be discussed in a balanced manner - a category is simply not the forum to do so. Nevertheless, I am loathe to simply delete the offending line as it does indicate what should go into such an article. Dpleibovitz (talk) 22:12, 20 August 2019 (UTC)

• I suspect that if any article cleanup tags are used in category space, that should indicate that a main article is required. Perhaps have a new {{main article needed for category}} template to place at the top of such categories. This would be another in Wikipedia:Categorization § Category cleanup templates (though that list is actually for articles not category pages). Wikipedia:Categorization doesn't address the problem of overly complex (article like) categories. Dpleibovitz (talk) 22:49, 20 August 2019 (UTC)

Would it be worth this year or subsequent years putting up a banner linking to the videos of presentations at wikimania? It might be a way of making it more broadly known the sorts of things that are going on 'behind the scenes' for readers who otherwise don't know how extensive the wikimedia community activities are. Might even inspire people to think about getting involved. T.Shafee(Evo&Evo)^talk 02:29, 21 August 2019 (UTC)

I don't think listening to Wikimania speeches is a good way to get an accurate understanding of what's going on behind the scenes, and I don't think using a site notice is a good way to publicize such things either. --Yair rand (talk) 05:19, 21 August 2019 (UTC)

Evolution and evolvability, sure why not. Especially some of the Research sessions were really accessible versions of the paper, that should be very insightful to people that don't feel like reading the entire research papers. —TheDJ (talk • contribs) 07:30, 21 August 2019 (UTC)

Are they adequately subtitled? I am becoming increasingly frustrated by the increasing use of videos that are inaccessible to the deaf, whether as sources or for information. - Sitush (talk) 07:35, 21 August 2019 (UTC)

@Sitush: Sadly, I think the current subtitling is pretty basic (just youtube's machine-transcribed ones). Long-term the quality of the video and sound recordings will go a long way to making them valuable after the event, as well as making wmania:2019:Video easier to navigate (also relevant: meta:WikiProject_remote_event_participation @Daniel Mietchen, Hogü-456, Jane023, and Fuzheado:). This will be especially important if the WMF is serious about wanting to make remote participation feasible for those who can't afford to or choose not to fly to the conference. T.Shafee(Evo&Evo)^talk 07:59, 21 August 2019 (UTC)

Well, thanks at least for letting me know. The YT machine translations are next to useless. - Sitush (talk) 08:02, 21 August 2019 (UTC)

Thanks for the ping. No I don't think a site notice is useful unless it is trimmed back to logged-in users, because I see the main value of Wikimania content as progress status reports and how-tos for various important internal projects that mean nothing to the wider community of readers and therefore only the keynotes would be more widely appreciated and you're better off putting just those (or associated WMF blogposts) in the site notice. I see a site notice as being for temporary consumption, whereas these important status updates are crucial markers in the "History of Wikipedia" that should be tracked. I think a separate Wikibase is necessary to track the Wikimania stuff (Commons/submissions/etherpad/Youtube) and maybe we need a "Wiki Loves Wikimania" for this. Jane (talk) 08:26, 21 August 2019 (UTC)