The feedback request service is asking for participation in this request for comment on Talk:Meghan Markle. Legobot (talk) 04:23, 25 December 2017 (UTC)[reply]

The examples in the documentation for Template:Anchor still have the anchors placed inside the section heading. I think this needs to be sorted out once and for all. A New Year task? Peter coxhead (talk) 09:47, 26 December 2017 (UTC)[reply]

@Peter coxhead:Seems worth doing. There was disagreement about this stuff only last week at WT:MOS. In my draft User:SMcCandlish/Manual of Style/Internal supplement essay, I've laid out the nature of the dispute, in the "Links and anchors" section.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  02:18, 27 December 2017 (UTC)[reply]

Yes, I've seen the "Links and anchors" section which is excellent. The right solution, it seems to me, is for this to be fixed in the MediaWiki software, so there's a standard way of doing linking to the heading that produces sensible HTML and generates 'plain' edit summaries. Whether this would be worth pursuing is another issue. Perhaps it would give some leverage if it could be shown that some of the methods you've laid out, which are actually used by editors, confuse screen readers. However, the key step for me at present is to get text like yours (slightly amended here) into the MoS: The overwhelmingly most common practice in mainspace is to include anchors below headings, not inside them, to avoid confusing new editors with mangled edit summaries. Prefer below the heading by default, as least likely to be problematic, but do not editwar over different placements. Peter coxhead (talk) 07:35, 27 December 2017 (UTC)[reply]

@Peter coxhead: Could compress it even more for real MoS usage: In mainspace, include anchors below headings, not inside them, to avoid confusing new editors with mangled edit summaries.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  22:56, 27 December 2017 (UTC)[reply]

New year greetings. Putting my stupidity hat on- giving clear examples of false code seems weird. Looking at the third example in placement in tables, there is no visual distinction between this and the correct code in the other examples. I am not an expert on the MOS conventions for displaying false code, but use of colour (displaying the illicit code in red) or putting the whole lot in the second column of a two column table- and 'Don't go here' icon in the first, would signal the difference. --ClemRutter (talk) 13:41, 26 December 2017 (UTC)[reply]

@ClemRutter: Yes, we have templates for that, e.g. {{!mxt}} and {{dcr}}. Which one works better depends on the surrounding markup. If the page is already using {{xt}}-family templates to mark up examples, I use {{!mxt}}, but an isolated case might better with {{dcr}}, especially if the code in question is outright invalid or malfunctional (that template uses re-styled <del>...</del> markup).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  02:18, 27 December 2017 (UTC)[reply]

Thanks for that- it will be copied over to my user/sandwardrobe. In the Tenplate:anchor/doc under discussion- the offending code appears to be:

the following forms of cell are not valid:<source enclose=div lang=text>!{{anchor|Foo1}} |A header cell !style="background:white;" {{anchor|Foo2}} |A header cell with styling |{{anchor|Foo3}} |A data cell |rowspan=2 {{anchor|Foo4}} |A data cell spanning two rows</source>

So is there a magic way in Template:/doc space of turning the text color=red, in a way that is not overwritten? It has beaten me today. I can see multiple uses if we had a simple negative template for false code blocks. ClemRutter (talk) 14:30, 27 December 2017 (UTC)[reply]

@ClemRutter: I don't use <source> or <syntaxhighlight> much, specifically because they interfere with tweaking the displayed output – they're a rather blunt instrument. I guess I need to be sure what your intent is. My usual approach to this sort of thing is to use <code style="padding-left:0;">...</code>. This gets rid of the annoying rightward indentation at the start of the code material, and then one can just use <br /> to create line breaks within the code block (turning off nowiki as needed to make that happen, and to make templates like {{!mxt}} or {{dcr}} work within the code example). Regardless what approach you use, the main thing to remember is CSS cascading order; if you do something like {{!mxt|<code>Bad example</code>}}, the result will look the same as <code>Bad example</code> because the stylesheet stuff for the code element comes after that for the {{!mxt}} template. Same goes for links; if you want to something like {{xt|Example text [[War of 1812]]}} you end up with link coloration marring the green example: Example text War of 1812. This actually has to be done as {{xt|Example text}} [[War of 1812|{{xt|War of 1812}}]]: Example text War of 1812. Various MoS pages have errors of this sort in them; I've been fixing them as I run across them.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  22:56, 27 December 2017 (UTC)[reply]

Specifically, regarding the "Ds/alerts" problems you highlighted. Would it lessen the "threat" aspect if the alerts were issued by a bot? What I was thinking is that if an article is tagged (say by edit notice) as under discretionary sanctions, that if an editor makes a substantive edit (let's say a non-minor one) to it the bot informs them of the presence of sanctions if they are otherwise eligible for such notification. Jo-Jo Eumerus (talk, contributions) 22:47, 27 December 2017 (UTC)[reply]

@Jo-Jo Eumerus: That would help a lot, though someone from WP:Teahouse or whatever needs to also re-design the template to look less like a "go F yourself" message. >;-) I have actually been proposing a solution like this since ca. 2015, so if others take up the bot idea, maybe it will finally grow legs. It would also prevent system-gaming of the kind of outlined many times (disrupt in one area until "notified", go to another one and do it there, etc., then come back a year later, after notice expiry, and start over again at the original topic).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  22:56, 27 December 2017 (UTC)[reply]

Now we would need to get it proposed somewhere where AE active admins and arbitrators see it... Jo-Jo Eumerus (talk, contributions) 23:01, 27 December 2017 (UTC)[reply]

Could try WT:ARBCOM, but this might actually require a formal WP:ARCA.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  23:39, 27 December 2017 (UTC)[reply]

I'll see if @Callanecc: knows where to ask. Jo-Jo Eumerus (talk, contributions) 12:44, 28 December 2017 (UTC)[reply]

I'd suggest probably taking two steps, the first by proposing it at WT:AE for AE regulars to review and then at WP:ARCA for the committee to review. I suggest WT:AE first as I think it's reasonably likely that the committee will want to hear from them before making a decision. Callanecc (talk • contribs • logs) 06:16, 29 December 2017 (UTC)[reply]

Sounds reasonable. I'll let Jo-Jo continue to take the lead on this. I've had F-all luck getting any traction of any kind on DS reform for something like 4 years now. I know when to take a back seat.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  06:31, 29 December 2017 (UTC)[reply]

SMcCandlish, the collapsible (and collapsed) instructions on the Template:Did you know/Queue page between the queues and the preps is suddenly no longer collapsing, nor even offering the option to collapse/show. When I took a look to see what might be causing it, the only thing that caught my eye was this edit by you. Can you please check to see whether your change has broken the "collapse top" template, and if so, please fix things? Many thanks. BlueMoonset (talk) 22:58, 27 December 2017 (UTC)[reply]

Repaired. I'd forgotten the closing }}} when adding a parameter alias. Derp.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  23:34, 27 December 2017 (UTC)[reply]

The feedback request service is asking for participation in this request for comment on Talk:Bosnian pyramid claims. Legobot (talk) 04:23, 28 December 2017 (UTC)[reply]

On the MOS talk page you recently wrote: "(our articles are palimpsests stirred together by a global assortment of geniuses, crackpots, and everyone in between, sometimes citing great stuff, sometimes poor stuff, and sometimes nothing)". This, my friend, is a gem. If there's a Hall of Fame for WP user quotes, this should be on it. Whatever you had for dinner the night you wrote that, have it more often.  White Whirlwind  咨  10:14, 28 December 2017 (UTC)[reply]

Guess I'd better stock up on chicken covered in extra-spicy barbecue sauce then. Heh.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  13:24, 28 December 2017 (UTC)[reply]

Note to self: Vera Lynn is badass. Over 100 now, and still gets albums in the charts.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  07:34, 30 December 2017 (UTC)[reply]

The feedback request service is asking for participation in this request for comment on Talk:Trace Adkins. Legobot (talk) 04:23, 1 January 2018 (UTC)[reply]

– Send New Year cheer by adding {{subst:Happy New Year}} to user talk pages.

Thanks, you too.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  14:35, 1 January 2018 (UTC)[reply]

   Send New Year cheer by adding {{subst:Happy New Year fireworks}} to user talk pages.

Hope you had a wonderful new year. :)

Hi, I'd like to pick your brains on an issue concerning category titles. I'm working on the flora distribution categories that follow the World Geographical Scheme for Recording Plant Distributions. Some more categories need to be created. The titling practice that seems to have been followed, mostly but not entirely consistently, is that in "Category:Flora of X", other than an extra "the", "X" is chosen so that it is the title of the article that best matches the WGSRPD unit. This means that if "X" needs to be disambiguated, then a disambiguating term is used in "Category:Flora of X", even though it wouldn't be needed for the category alone. Thus Category:Flora of New York (state) even though there isn't a flora distribution category for the city; Category:Flora of Chihuahua (state) to match Chihuahua (state); etc. There will need to be a category for the Brazilian state of Amazonas, whose article is at Amazonas (Brazilian state). To me "Category:Flora of Amazonas (Brazilian state)" seems clumsy (the WGSRPD just calls it "Amazonas"). On the other hand, I can see the logic of this approach. You think about titles more than I do, so I'd value your opinion on how it fits with usual title and disambiguation practices. Peter coxhead (talk) 16:12, 3 January 2018 (UTC)[reply]

@Peter coxhead: I would make it match the article name even if it's clumsy, because failure to match the article name is grounds for speedy category renaming (WP:CFD#C2D). With the short name, the ambiguity would still be there for the reader (who might think Category:Flora of New York meant the city). Disambiguation generally "adheres" to the topic; it's not done differently in different namespaces. Clumsiness of cat. names is way less of an issue than with article titles, since readers are generally not typing category names or picking them from a disambiguation page, but just noticing them at bottoms of articles and then clicking around in them as a navigation system.

PS: An exception to article-title-matching is that if the category could not imaginably pertain to anything but one topic, then it need not be disambiguated. Amazonas is a bunch of places, so organisms being in them could obviously apply. If there were only one place called Amazonas, but the big company were Amazonas.com instead of Amazon.com, and we had Amazonas (Brazilian state) and Amazonas (company) (only), then Category:Flora of Amazonas would be likely fine, because the concept "Flora of" couldn't logically pertain to the company. I can't think of any actual place names, right off hand, where this would come up. Even the ones I'm straining to think of (e.g. Clovis, California versus King Clovis, are already disambiguated for other reasons, or the place is actually the primary topic anyway and not disambiguated. It's more likely to come up in a case like "Category:Songs by Foo", where the article is at "Foo (singer)" and none of the other Foos have anything to do with music. And this exception isn't even consistently applied; lots of categories have disambiguation even when one might not think it strictly necessary, probably because it's easier to just copy the article name than to analyze whether the disambiguation is really needed on a cat.-by-cat. basis.
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  02:02, 4 January 2018 (UTC)[reply]

Thanks, that's useful advice; the reference to WP:CFD#C2D is particularly helpful if anyone queries using a disambiguated name.

More problematic to me is when this approach is "over applied", as I see it. Thus we have Category:Flora of North America and Category:Flora of South America when the WGSRPD defines these (as Northern America and Southern America) differently to what would be expected given the category titles used (it puts Central America and the Caribbean in Southern America). Peter coxhead (talk) 07:40, 4 January 2018 (UTC)[reply]

One of the other things I've noticed, which I know you've been involved in discussions about before, is the inconsistent use of diacritics in article titles. Why Réunion for example, but not Québec? Peter coxhead (talk) 08:21, 4 January 2018 (UTC)[reply]

I started with Category:Mammals of North America, Category:Felids of South America, and Category:Felids of Central America, and worked up to Category:Mammals of South America, Category:Mammals of Central America, Category:Mammals of North America, but did not complete the inclusion hatnotes, and didn't finish the cross-categorized Category:Mammals of the Caribbean (it should include any Caribbean place sometimes classified as S. or C. Am., but I don't think it has them all yet). I got side-tracked by other stuff and never did finish all that, and I did not drill upward to non-mammals much less to plants, nor sideways into canids or simians or whatever – huge job, better done with AWB or something). The goal was to match our life-forms in the Americas categories to how we're categorizing actual countries (and adjust even that as necessary to be inclusive of conflicting definitions).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  16:20, 5 January 2018 (UTC)[reply]

Yes, animal distributions are categorized differently. As per Category:Fauna by continent, the traditional North and South America are used, and Oceania is employed, I suppose for Australasia and the Pacific, but since there's no single external source for the system used, it gets applied inconsistently. By contrast, for plants we have a single well-used source, and a set of clear maps at Wikipedia:WikiProject Plants/World Geographical Scheme for Recording Plant Distributions. So the problems for animals and plants are a bit different. For both we have a small set of the usual suspects (no names here) who love to create extra categories, mostly unnecessary and almost always never worked through to completion or consistency. However, at least for plants we have a standard that can be returned to, if and when anyone has the time and energy to do it.

I will try again to see if there could now be agreement on "Flora of northern America" and "Flora of southern America". WT:PLANTS seems the place to open a discussion. Peter coxhead (talk) 17:30, 5 January 2018 (UTC)[reply]

What I'm suggesting is to have a separate set of categories, such that we have "normal people" categories for SAm, CAm, NAm, Caribbean (and there'll be some overlap, with various Caribbean ones as illustrated on the felids and mammals categories, plus Mexico being classified in both NAm and CAm, due to varying definitions). Then also have WGSRPD categories – northern and southern – for people that need to look at this stuff through that lens.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  17:37, 5 January 2018 (UTC)[reply]

I've looked for the past discussion(s) in the archives, but haven't found them yet. My recollection is that it was agreed that having two categories like "Flora of northern America" (WGSRPD) and "Flora of North America" (usual sense) wouldn't work. Suppose we treated the new "Category:Flora of North America" as a container category for the relevant Level 2 and Level 3 components of the WGSRPD, i.e.

• ALU Category:Flora of the Aleutian Islands (WGSRPD: Aleutian Is.)
• ASK Category:Flora of Alaska
• NUN Category:Flora of Nunavut
• NWT Category:Flora of the Northwest Territories
• YUK Category:Flora of Yukon
• 71 Category:Flora of Western Canada
• 72 Category:Flora of Eastern Canada
• 73 Category:Flora of the Northwestern United States (WGSRPD: Northwestern U.S.A.)
• 74 Category:Flora of the North-Central United States (WGSRPD: North-Central U.S.A.)
• 75 Category:Flora of the Northeastern United States (WGSRPD: Northeastern U.S.A.)
• 76 Category:Flora of the Southwestern United States (WGSRPD: Southwestern U.S.A.)
• 77 Category:Flora of the South-Central United States (WGSRPD: South-Central U.S.A.)
• 78 Category:Flora of the Southeastern United States (WGSRPD: Southeastern U.S.A.)
• 79 Category:Flora of Mexico
• 80 Category:Flora of Central America
• 81 Category:Flora of the Caribbean

Where would we then put the hundreds of articles about plants presently directly in the current Category:Flora of North America? They would have to have both [[Category:Flora of northern America]] and [[Category:Flora of North America]] added to each article, which would confuse the hell out of readers and most editors. The same would apply to southern/South America. Peter coxhead (talk) 21:00, 5 January 2018 (UTC)[reply]

Maybe disambiguate as "Category:Flora of northern America (WGSRPD)" or "Category:WGSRPD northern America flora"? The problem with any WGSRPD category is all these more specific categories like "Flora of the Caribbean" and "Flora of Western Canada" lend themselves to categorization in our usual geographical categories, so it'll eventually happen whether they're also in WGSRPD categories for "northern America" and "southern America" or not, if for no other reason than to prevent confusing gaps in the category tree. What we have here is a conflict between how WP geographically categorizes and how some other entity does so; if we want to include categories for their unusual designations they'll surely have to be add-ons. Not because anyone will make a rule about it but because they'll be edited around in the normal course of doing things. It's at least happy that many of their more specific categories coincide with ones we'd use anyway (aside from some abbreviations). Not so much the broad US and Canadian regional subdivisions; we don't organize any US or Canadian categories by "Western" or "Southeastern", so some of these will need to be non-diffusing.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  23:48, 5 January 2018 (UTC)[reply]

We have to use the WGSRPD categories as the primary ones in many if not most instances, because these are what reliable secondary sources use, including the IUCN, GRIN, and the World Checklist of Selected Plant Families (WCSP), plus more specialized sources that rely on these. So it's the non-WGSRPD categories that generally have to be "add-ons" for plants. So, no, it won't "eventually happen". If the source has code "7" or "northern America" it's only possible to categorize accurately if there's a category for this.

The other problem with non-WGSRPD categories is the lack of clear definitions. Thus above I used a definition of "North America" that excludes Greenland, placing it in a separate "Arctic" category, as I found in some sources. If you include Greenland in "North America" then it's more-or-less equivalent to the WGSRPD's Northern America + Central America. "Central America" without a clear map like the WGSRPD's is a problem, because the northern boundary varies by source. "Oceania" is a real problem. Editors classifying animal distributions have fudged the issue badly. The map at Category:Fauna by continent treats it as a separate 'continent' to Asia. In the article Oceania, it includes the island of New Guinea. However although Category:Fauna of New Guinea is placed in the Fauna of Oceania, it is also ultimately placed (via Indonesia) in the Fauna of Asia, yet these are supposed to be different continents.

The treatment of New Guinea is probably an illustration of a wider problem. Whatever scheme is being used, editors come across an area A that comprises part of area B and part of area C. Since categorization is hierarchical, the only valid approach is to put A into the category for the area that completely includes B and C. But this isn't what usually happens. Either A is put into B and C (wrong because A is not a sub-area of either) or B and C are both placed in A (wrong because neither B nor C are sub-areas of A). Category:Flora of the Rocky Mountains is a good example, where I've just recently removed Category:Flora of Western Canada and Category:Flora of the Western United States.

(An alternative is to accept that categorization in the English Wikipedia is not hierarchical, and that placing category X in category Y means something vaguer. The problem then is that there's usually no good reason to put X into Y rather than vice versa, e.g. as the Rocky Mountains run across Western Canada and the Western United States, the latter categories could reasonably be put into the former.) Peter coxhead (talk) 11:01, 6 January 2018 (UTC)[reply]

I think we're talking past each other a little bit. I have no issue at all with the idea that categorization along WGSRPD lines is what botanists will do, and do it quite strictly by WGSRPD-related RS definitions (aside from us expanding some abbreviations for clarity). But it's pretty much inevitable that they'll also be categorized in a more loosey-goosey way (if not plant articles themselves, then the small-region fauna categories they're in) along the usual "commonly understood meaning of [insert geographical area here]" lines, just through everyday editorial activities by people who don't care at all about botany but who care a whole lot about the Caribbean or where ever – the way everything else on WP gets categorized. E.g., you'll find various countries categorized as being both Eastern and Central European, and so on. Our category tree isn't really a tree but more like neutral network, with a lot of cross-linking and what some would call redundancy. It's okay that way. The solution is to make sure that the WGSRPD categories are clearly IDed as such, if not in their names then in inclusion criteria at the top of the category.

Mostly I don't think there'll be a problem. As an example, a plant might get put into Category:Flora of Trinidad at Tobago when that exists at some point. I assume this would be WGSRPDed as a subcat of Category:Flora of southern America. But "southern America" isn't a thing to anyone but WGSRPD. Other Category:Foo of Trinidad and Tobago categories are in Category:Foo of the Caribbean and Category:Foo of South America (because how to geographically define T&T varies by context). So, it's pretty much inevitable that Category:Flora of Trinidad and Tobago will be a child cat. of all three of Category:Flora of southern America, Category:Flora of South America, and Category:Flora of the Caribbean, and these categories will serve different purposes for different reader communities; the latter two will just be based on how T&T is categories from (respectively) a geophysical landmass perspective versus a socio-politico-cultural one, and it won't have a thing to do with the plants. Meanwhile, the WGSRPD cat. will be entirely based on botanical sources, and we wouldn't even have "southern America" categories for any other reason (similarly, we have "Latin America" categories for certain internationally cross-cultural things, but we don't use them outside that sphere (there'll never be a Category:Flora of Latin America, nor a Category:Volcanoes of Latin America, because it just doesn't compute; flowers and lava aren't Latino).

So, it's not an either-or choice. People who want to know what plants live in Mexico as a geographical-range matter may be thinking either "Central America" or "North America" (we won't know), those from an environmental regulation perspective probably from a "Central American" perspective (.mx law has more in common with that of the rest of "northern Latin America", as it were, than of the US and Canada), while botanists will be thinking strictly in terms of WGSRPD's "northern America" (now – I note that .mx used to be cut in half in the WGSRPD scheme).Everyone will get to be happy, at least in theory. Or from a different angle: Look at how Turkey is categorized. Someone could consider it confusing, but the purpose of the categories isn't a hierarchical and exclusive labeling system, but a navigation tool to related articles, and Turkey is Balkan, SE European, E Mediterranean, Middle Eastern, Near Eastern, etc., all at once depending on perspective.

Hope that helps. I'm sure you and the rest of the botanists will get the WGSRPD stuff done right (even if it takes some policing – you might find someone insisting that Flora of Delaware has to be in Flora of the Northeastern United States because so-and-so sources (economic, geological, etc.) catalogue DE as part of the US Northeast, not understanding that it's a WGSRPD label, not a general geographical one. A potential solution to that if it ever became a real problem would be using category names like "WGSRPD flora of the Northeastern United States" or something, if having category inclusion criteria doesn't cut it. But it should be enough.
 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  17:42, 6 January 2018 (UTC)[reply]

Yes, we agree that some more "user friendly" categories are also needed. Some of these can be made compatible with the WGSRPD ones, by being super- or sub-sets, but others can't, and just exist in parallel. I have no problem with that. The problem arises when, as has happened in the past, discussions have resulted in category names that correspond to the "user friendly" categories but are supposed to be used for the WGSRPD ones. That's the case, as we seem to agree, for Category:Flora of North America for example, which, when I've finished my current tidying, I'll try again to get changed, with this name used for the usual sense, and Category:Flora of northern America used for the WGSRPD sense.

The general principle I'd like to see established is that the WGSRPD category is only called by the "common name" when the "common name" has the same meaning or a meaning so close that it doesn't matter.

We also agree that it's important to make clear what is a WGSRPD category and what isn't; I've working on this by adding {{WGSRPD code}} to every such category – the template also creates a tracking category by level, e.g. Category:Flora categories with a level 3 WGSRPD code, which will help in maintenance.

Jingoism applies here, too, since many editors want "their" country/state/district/stomping ground/whatever to have its own distribution category, regardless of whether this makes sense.

By the way, categories aren't supposed to form a general net, as per your comment above, but rather a set of cross-connected trees, as per Wikipedia:Categorization#Category tree organization. In the current context, the WGSRPD categories will form a strict tree, with cross-connections to what should be other trees based on more common usage. Peter coxhead (talk) 18:54, 6 January 2018 (UTC)[reply]

I'd be in support of that. Let me know if it comes up in CfD again. (to be explicit: I'm declaring an interest in working on that being consistent, not asking to be canvassed). Also don't disagree with your net/tree assessment; I was over-generalizing. We do have a lot of strict trees for particular purposes, and more loose arrangements; some are diffusing some are not. Together they form kind of an interlacing mangrove, which is less of a bramble than it looks at first glance when you examine it in detail. I think I first encountered this (and debates about it, which mostly seem to have settled out) when working on the Category:Cue sports stuff. There was strong, even strident, desire to categorize snooker as a sport unto itself, yet it also obviously needed to be classified as a cue sport like pool and carom billiards. Consequently, lots of sports categories have separate entries for cue sports and for snooker, but not for pool or carom (which don't have their own international sport fandom and marketing machines of any note, while snooker is on par with cricket in that regard in many parts of the world). We similarly have categories like Category:Ball games under Category:Sports by type (and Category:Games by type) that include cricket and cue sports and yadda yadda, but it's not a strict tree into which all the sports-that-have-a-ball-in-them get forced (e.g. Category:Sports in the United States has no Category:Sports in the United Staes by type and thus not Category:Ball games in the United States; it's been flattened to Category:Sports in the United States by sport.

I think this sort of thing is good precedent for what's under discussion here. As long as there's some category thicket for "Flora of [geographical name]" that suits the general-interest approach to that, there is no rationale to blockade or merge parallel specialized trees, like one for WGSRPD, that do something similar along different lines, even if there's conceptual overlap or a name similarity. It would even be possible to skip the "call the WGSRPD category by the 'common name' when the 'common name' has the same meaning or a meaning so close that it doesn't matter" part in theory, though it might be necessary to have WGSRPD in the names. Something like this is alrady used for conservation status; I see that Category:Biota by conservation status system exists, but it doesn't seem very fleshed out yet for anything but IUCN. But we do have Category:IUCN Red List critically endangered species (and, I note with relief it's not "Critically Endangered", LOL). If this sort of thing is defensible for IUCN, then it's defensible for WGSRPD.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  07:37, 7 January 2018 (UTC)[reply]

Diacritics

Diacritics: Basically, it's because there are a lot of jingoistic asshats, and they sometimes form a big enough WP:FACTION to wear down everyone in a war of attrition until they get the censorship they want. They actually keep getting shut down, e.g. in an ArbCom case, and getting their "wikiproject" (read: canvassing farm) deleted, and so on, but they never really go away. They used to be hard-core centralized in a few other projects like WikiProject Tennis and WikiProject Ice Hockey, but RM has largely undone their attempts to WP:OWN those categories as no-diacritics zones. I expect that Québec will gets its proper spelling eventually, especially given MOS:ENGVAR (whether 'Mercans (or Brits or Strines for that matter) like to include the diacritic is irrelevant, it's frequently retained in Canadian English, so no defensible argument can be made that it's "not English"). PS: I fixed the missing King Clovis redirect. How was that a redlink? Sheesh.

Sadly jingoism isn't confined to diacritics, either here or in the real world! We appear to live in an increasingly nationalistic age, to my discomfort as an aging liberal internationalist. Peter coxhead (talk) 17:30, 5 January 2018 (UTC)[reply]

Bet yer a Zionist commie, too! >;-) ^[FBDB] — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  17:37, 5 January 2018 (UTC)[reply]

That ^[FBDB] comes in handy, don't it? EEng 05:49, 18 January 2018 (UTC)[reply]

Yep, though it shouldn't be necessary. It's symptomatic of the administration problem we have. I used the template at WP:ARCA recently.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  14:24, 18 January 2018 (UTC)[reply]

An editor has asked for a discussion to address the redirect William, Prince of Wales. Since you had some involvement with the William, Prince of Wales redirect, you might want to participate in the redirect discussion if you have not already done so. --Nevé–selbert 18:36, 3 January 2018 (UTC)[reply]

What's your opinion on the close at Wikipedia talk:Naming conventions (television)#RfC: Telenovela disambiguation? A pretty poor close in my book. I'm already having problems with it - see Talk:Victoria (TV series)#Requested move 5 January 2018 (withdrawn), [14], and [15]. Have tried taking it up with the closing editor here: User talk:Winged Blades of Godric#Half finished RFC close. Would be interested in your take on all this. --woodensuperman 15:47, 5 January 2018 (UTC)[reply]

@Woodensuperman: Dropped off a note at Godric's page. While I don't dispute the underlying fact of the close (that the discussion failed to come to a clear consensus), it's clearly a mis-worded close that implies that a discussion that didn't even come to consensus can, through some form of black magic, literally override long-standing guidelines, and this is leading to RM disruption. In the interim, I would suggest re-opening a new RfC at WP:VPPOL, with the explicit reason that the discussion at RM, despite being fairly thorough discussed among a number of topically interested editors, failed to come to consensus, and the closer specifically directed that a broader discussion would be needed to resolve the matter. (That's how you avoid bogus complaints of tendentious rehash of a recently closed discussion). I personally don't care much whether we use "(telenovella)" as a disambiguator, though I lean against it per WP:USEENGLISH and WP:OVERDAB. However, I care a tremendous amount about undermining of WP:P&G by wrong-headed misapplication of WP:LOCALCONSENSUS to try to do something that it cannot.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  15:59, 5 January 2018 (UTC)[reply]

Thanks for that! Let's see what Godric does now. Exactly, how can a failed RFC result in the outcome that the RFC failed to establish? --woodensuperman 16:03, 5 January 2018 (UTC)[reply]

Okay, so Godric got a second opinion and is refusing to change the close. Is it worth pursuing further do you think? --woodensuperman 12:55, 8 January 2018 (UTC)[reply]

@Woodensuperman: Yes. What I suggested at "In the interim, ..." is probably the way to go. WBoG's poorly worded close is going to be taken as blanket license to use "telenovela" everywhere, despite actual failure of consensus to reach that conclusion.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  22:28, 8 January 2018 (UTC)[reply]

Okay, thanks. See Wikipedia:Village pump (policy)#RfC: Is "telenovela" a suitable disambiguator?. I hope you don't mind but I recycled some of your wording above. --woodensuperman 09:17, 9 January 2018 (UTC)[reply]

@Woodensuperman: That sounds like reasonable wording, though maybe also see what the book and other guidelines say. I would link to WP:PRECISE in it (the policy from which we derive the "do not over-disambiguate" principle). As for RfCs, I like to let them run the full course. Most requests to close RfCs early at WP:AN/RFC are actually ignored, and patience is a virtue, and there is no deadline, and don't give anyone a wedge to drive ("the RfC was closed too soon, so it's not really valid", blah blah).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  14:28, 18 January 2018 (UTC)[reply]

Okay, thanks. Maybe I'll wait a bit then, although the conversation seems to have fizzled out, and the consensus there seems unanimous. But in light of the recent reverts after the previous RfC, I can think of at least one editor who may resist if we don't wait for the 30 days... --woodensuperman 14:38, 18 January 2018 (UTC)[reply]

Looking at WP:NCFILM and WP:NCBOOKS neither sanction genre at all. I guess as it should really only be used when all other options are exhausted, a situation which would be very rare. Is it worth mentioning it at WP:NCTV, or would this just cause more confusion? --woodensuperman 14:43, 18 January 2018 (UTC)[reply]

I would mention it to prevent a recurrence. I'm surprised it's not mentioned at the the other pages, though we tolerate a wee bit of this stuff in books, e.g. "(novel)" and "(book)" when "(book)" would almost always suffice.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  15:16, 18 January 2018 (UTC)[reply]

Sorry, I meant whether it was worth including the clause that begins "unless...". I wouldn't really draw a parallel between this situation and the book situation. I'd view "book" as the format, just a vessel for the type of work. --woodensuperman 15:24, 18 January 2018 (UTC)[reply]

I think the "unless" clause is useful; there will be times when the condition happens and we shouldn't leave people not know how to further disambiguate when and only when it does.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ< 

The feedback request service is asking for participation in this request for comment on Talk:Miranda Lambert. Legobot (talk) 04:23, 6 January 2018 (UTC)[reply]

I'm converting a glossary to templates and was wondering if you knew a way to suppress the anchor links made by {{term}}? The glossary has 370 terms but about 50 of them are alternate names. I'd like those alternate names to have anchor links at the main term where the definition is, so the reader won't have to jump up and down in the glossary. Do you know if this is possible or if there's a workaround to achieve this? Would appreciate any advice. Thanks. – Reidgreg (talk) 18:08, 9 January 2018 (UTC)[reply]

@Reidgreg: If I understand this correctly, you want to have something like (if I may template the crap out of this, for cross-references and hatnotes):

{{term|foo|noid=yes}}
{{defn|1={{crossref|selfref=no|See {{gli|phu}}.}}}}
...
{{term|phu|content={{anchor|foo}}phu}}
{{defn|1={{ghat|Also ''foo''.}} Definition here.}}

Where noid is a presently non-existent parameter for anchor ID suppression? I.e., such that the anchor for foo goes to the phu entry?  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:34, 9 January 2018 (UTC)[reply]

 — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:35, 9 January 2018 (UTC)[reply]

So, looks like the middle option works, using <dt>...</dt> instead of {{Term}}, for the foo entry. I could also hack the {{Term}} template to have an option for suppressing the ID. However, I don't really see the point of this. Why not just link directly to the phu entry? I don't know what {{Glossary link}} custom template you are or will be using (i.e., your equivalent of {{Cuegloss}}). Supposing it were {{Quuxgloss}}, you could just do: {{quuxgloss|phu|foo}}.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:52, 9 January 2018 (UTC)[reply]

PS: Not doing it the {{quuxgloss|phu|foo}} way will also produce incorrect hover text; when you mouse over it, the tooltip will say "See entry at Glossary of quux terms § foo" but will actually take you to the phu entry which may be confusing to readers even with {{ghat|Also ''foo''.}} as a hatnote in the phu entry.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  19:06, 9 January 2018 (UTC)[reply]

Wow, you went above and beyond the call with all the templated examples! (I'm saving a copy on my talk page for future reference.) I see what you mean, that it's really not a problem with piped incoming links. I think I just wanted to keep the page as functionally equivalent to the non-templated version as possible so as not to upset anyone with the changes. Much thanks! – Reidgreg (talk) 14:25, 10 January 2018 (UTC)[reply]

No prob. I know this particular code better than anyone, so it's pretty "brain dump" on my part.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  14:42, 10 January 2018 (UTC)[reply]

You and I (you more than I) have put a lot of effort in to several discussions at T:MOS which have stalled. I'd hate to see that all go to waste. I suggest we try to resolve them one at a time. May I suggest we start with refs inside vs. outside parens? That one seems easiest least hard. EEng 20:14, 9 January 2018 (UTC)[reply]

A bunch of stuff has gotten archived, too, but had traction. I'll be happy to start with which ever you like.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  20:58, 9 January 2018 (UTC)[reply]

Thanks. I do what I can to push for some WP:AE and WP:AC/DS reform, but it's very, very slow-going.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  13:40, 10 January 2018 (UTC)[reply]

The feedback request service is asking for participation in this request for comment on Talk:2017–18 Iranian protests. Legobot (talk) 04:24, 11 January 2018 (UTC)[reply]

Hello Stanton- Saw your contributions to Wikipedia:Wikimedia_sister_projects and thought you might be able to help me with what I thought would be a simple thing: At the top of Nave, I went to change the target of the Distinguish template from a wikilink on Rogue (vagrant) to a Wiktionary link on knave, with nothing but knave displayed. (The wiki article Knave is a disambig page). Nothing I do will work. {{Distinguish|[[wikt:knave]]}}}}, {{Distinguish|[[:wikt:knave]]}}, {{Distinguish|{{Wiktionary|knave}}}} all generate various messes. Can you tell me what I'm missing, besides perhaps a functioning intellect? Thanks in advance. Eric ^talk 14:12, 11 January 2018 (UTC)[reply]

@Eric: The proper hatnote is {{distinguish|knave}} →

Not to be confused with knave.

We should use that because we do have a disambiguation page; this is why the default output of so many hatnotes is to link to disambiguation pages with the same base pagename. In another context: I don't think what you want to do can be done with that template; its code is too "tied down". If we had no DAB page, and the term on WP redirected to an article with a radically different title, you could do something like {{distinguish2|knave; see [[Rogue (vagrant)]]}} → Template:Distinguish2 If we had no appropriate WP article at all, the thing to do would probably be {{Distinguish2|knave}} → Template:Distinguish2  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  16:27, 11 January 2018 (UTC)[reply]

Ok, thanks very much for the prompt reply! So it's Distinguish2 that would achieve what I wanted, but policy would not have us do that. Thanks for your edit there as well. Eric ^talk 17:43, 11 January 2018 (UTC)[reply]

@Eric: {{distinguish|wikt:knave}} ->

Not to be confused with wikt:knave.

will provide you a link also (and might be preferable), though I generally support SMC's "link to our article/disambiguation first". --Izno (talk) 16:41, 18 January 2018 (UTC)[reply]

I wouldn't do {{distinguish|wikt:knave}}, because "wikt:knave" doesn't mean anything to our readers, only to editors.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  16:56, 18 January 2018 (UTC)[reply]

I don't particularly disagree (hence the "might be preferable"). There's also {{See Wiktionary}} which I just remembered. --Izno (talk) 18:16, 18 January 2018 (UTC)[reply]

Hello, sorry to pester you again. I've just spotted that the user that closed the discussion at Talk:Vikings (TV series)#Requested move 19 December 2017 actually !voted in the discussion. That isn't right, is it? Not sure where to take this, although not sure there's a lot of point, as sadly I don't think the consensus is in favour of the move (even though the current title goes against WP:INCDAB). --woodensuperman 15:16, 12 January 2018 (UTC)[reply]

@Woodensuperman:. It's generally a bad idea, unless the consensus is very clear (i.e. a WP:SNOWBALL in one direction, or a hopeless "no consensus"). If someone does an obviously bad close of a discussion they're involved in, one can take it to WP:ANI, though I've also seen WP:AN used, and a request for re-closure at WP:AN/RFC, though the latter isn't likely to be acted upon. One can also just revert a bad closure, post a request for proper closure at AN/RFC, and re-revert it with a note that a non-involved closure has been requested at AN/RFC if someone un-reverts. The "nuclear" option to open a new RfC at WP:VPPOL, on the basis that the original discussion was improperly closed by an involved party and the question needs broader input. In this case, I wouldn't do any of these things, because the close actually seems reasonable. We do permit exception to guidelines when there's a consensus to do so. And it was a SNOWBALL. And a new RM is already open anyway.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  17:36, 15 January 2018 (UTC)[reply]

Hi, I notice you do a lot of work in this area and you have always been kind enough to offer thoughtful analysis at the snooker project so I was wondering what your views were on the interpretation of WP:EGG in the context of aliases at Template_talk:Infobox_film#Query between myself and Erik. I was pretty sure I was right, but after reading the guideline again I am doubting my own interpretation. The guideline itself invokes the "principle of least astonishment" (which implies we should avoid linking through aliases), but if somebody has an obscure alias or a film has an obscure alternative title where should it link to, if anywhere? I am not particularly bothered about the "crediting" issue which triggered the discussion, but rather the deployment of aliases as redirects. Betty Logan (talk) 17:24, 15 January 2018 (UTC)[reply]

I commented over there. When it comes to works with alternative titles, it might be an EGG issue, but probably only if the alt. title has no reason to be used in the context. There could be one. E.g. one might write "George Lucas first showed his draft The Star Wars treatment to United Artists in 1973."  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:17, 15 January 2018 (UTC)[reply]

The feedback request service is asking for participation in this request for comment on Talk:James D. Zirin. Legobot (talk) 04:24, 16 January 2018 (UTC)[reply]

Please could you have a look at Wikipedia talk:WikiProject Tree of Life#Guideline change proposal. The discussion seems to me to be so muddled that I can't tell what is being proposed. Your understanding of these issues will be helpful. Peter coxhead (talk) 19:15, 16 January 2018 (UTC)[reply]

I think I got the gist of it and ended up having to oppose, as conflicting with at least two of the WP:CRITERIA. (If I'm somehow wrong, then it really is too muddled and should be re-proposed with a clearer rationale that pre-figures concision and precision objections – it's one of those WP:Policy writing is hard matters).  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  19:27, 16 January 2018 (UTC)[reply]

Regarding these changes, please also note the existence of the nearly identical m:Help:User style. - dcljr (talk) 03:00, 17 January 2018 (UTC)[reply]

Hmm. Well, not everything that we might put in our version will apply to all wikis or to Meta in particular, and Meta isn't subject to our style guide (technically, non-articles here aren't either, but we tend to apply it to project pages for consistency and to be exemplary – we can't expect new editors to follow rules we won't follow ourselves). That said, I may look them over and see about making the pages more consistent with each other. I don't edit at Meta very much, and am not sure how touchy people are about old pages like that.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  03:06, 17 January 2018 (UTC)[reply]

This isn't about MOS-type stuff, guidelines, or "rules" (i.e., editing style); it's about UI things (CSS) that individual user's can customize for themselves (alone). Code placed in a user's "global.css" (at Meta) will affect their experience at all Wikimedia wikis (to the extent possible). - dcljr (talk) 07:48, 17 January 2018 (UTC)[reply]

True enough.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  23:38, 17 January 2018 (UTC)[reply]

I noticed that you posted messages at User talk:Pzoxicuvybtnrm and User talk:Nimbus227 asking these users to update their signatures to avoid obsolete HTML tags. Great! Please be aware, however, that User:Nihlus prepared 3 lists of users with signature issues (with <tt> tags, images, and <font> tags) and I am systematically working through User:Nihlus/linter_sigs, tracking compliance and reminding users who continue to edit and ignore my messages. I am more than 80% done and hope to finish soon. Thank you for your support for ending the propagation of lint in Wikipedia! —Anomalocaris (talk) 03:10, 18 January 2018 (UTC)[reply]

@Anomalocaris: Is this to say that I don't need to continue with this? I was working up a template for this in a sandbox, but will leave off if you and Nihlus already have this covered.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  03:39, 18 January 2018 (UTC)[reply]

I'm doing them in order of most-to-fewest pages edited, and as I go down the list, I update a spreadsheet on my computer, go to the user's talk page, copy my template, go to an editing page of Nihlus's list, copy their old signature, paste it into my message, create an HTML5-compliant signature, make sure it matches, test it in Preferences if there's any suspicion it might be over 255 characters or be defective in some way, and save the page. I don't bother to check if the user spontaneously fixed their signature or if anyone else has already suggested that they do so. This is correct 99+% of the time. But if we collaborate, then it takes longer because I have to verify that nobody else has already notified the user. Even if we divide the list in some way, I still want to track compliance, and that's easiest if I'm the only one doing the notifying. So, thanks for your support, but if you want to support the effort, what would be the most helpful would be if I provide you the IDs of non-cooperative users. Perhaps if they hear from another Wikipedian such as you, sharing in your own words the message of de-linting signatures, they'll listen. Interested? —Anomalocaris (talk) 04:20, 18 January 2018 (UTC)[reply]

Might be more effective, then, for me to later hit up those who did not make the change, after X number of months. Would just need a list or to be pointed at one.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  04:40, 18 January 2018 (UTC)[reply]

https://en.wikipedia.org/w/index.php?title=Wikipedia:Requested_moves/Technical_requests&diff=821149614&oldid=821148429 - looks like the same titles. --SarekOfVulcan (talk) 18:26, 18 January 2018 (UTC)[reply]

@SarekOfVulcan: Yeah, it was just a typo; someone intuited what was intended given the rest of the RMs in the series.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:50, 18 January 2018 (UTC)[reply]

Yup, I saw. I just couldn't figure it out quickly enough myself for some reason. --SarekOfVulcan (talk) 18:59, 18 January 2018 (UTC)[reply]

Well, the earlier ones got acted on so quickly, the context was lost. I expected it to take longer myself and for all of them to still be there when the last one was saved; ended up edit-conflicting.  — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  19:06, 18 January 2018 (UTC)[reply]

I have given up on my years of resistance against emoji, and am hereby replacing my Unicode-art cat face in my sig; using the graphical one is a space saver.
 — SMcCandlish ☏ ¢ 😼  19:19, 18 January 2018 (UTC)[reply]

Per your change, here's a fish for your cat to eat: . North America¹⁰⁰⁰ 09:41, 20 January 2018 (UTC)[reply]

Nom nom nom.  — SMcCandlish ☏ ¢ 😼  19:36, 20 January 2018 (UTC)[reply]

Hello, Stanton! I've read that you struggle to find barnstars. My suggestion is to check here in Commons, where there's lots of specific subcategories. Have fun! --NaBUru38 (talk) 20:49, 18 January 2018 (UTC)[reply]

Good idea, though the point is that we should be able to find them on WP itself, without some self-appointed pack of gatekeepers making this difficult. They've refused to acknowledge the issues they're causing and said I should just RfC it, so that's what'll happen when I get around to it. One of those "be careful what you wish for" things. [sigh]  — SMcCandlish ☏ ¢ 😼  20:52, 18 January 2018 (UTC)[reply]

The feedback request service is asking for participation in this request for comment on Talk:Israel. Legobot (talk) 04:24, 21 January 2018 (UTC)[reply]

It will never happen. @Timrollpickering: KMF (talk) 05:47, 23 January 2018 (UTC)[reply]

You seem to be experiencing a time warp. Already did happen, and your MR has no merit. "I don't like it" isn't a rationale; the close itself has to be faulty.  — SMcCandlish ☏ ¢ 😼  06:15, 23 January 2018 (UTC)[reply]

Confused about a seeming advice notice you posted at Wikipedia_talk:WikiProject Languages#Bot for WP:WPENGLISH talking about a bot request you made somewhere. You seem to be pointing to a very long section name at WT:Bot requests that I suspected was actually two links (the with not being part of either one) and I was just going to add some brackets to fix it up for you, but then looking at WT:Bot requests, I couldn't find anything by you; in fact, the most recent change to that page is from November, so I just left everything as is. You might want to untangle it all. Best, Mathglot (talk) 11:10, 23 January 2018 (UTC)[reply]

Not sure what you mean. I just clicked the link to WT:WPLANG, and clicked the link in it there to WP:BOTREQ and it goes directly to the quite short "#Tag talk pages of articles about English with Template:WikiProject English language" section as intended. It's at WP:BOTREQ, not WT:BOTREQ (the talk page about how to operate the BOTREQ page). There's no tangle.  — SMcCandlish ☏ ¢ 😼  20:49, 23 January 2018 (UTC)[reply]

Being involved in an edit war can result in your being blocked from editing—especially if you violate the three-revert rule, which states that an editor must not perform more than three reverts on a single page within a 24-hour period. Undoing another editor's work—whether in whole or in part, whether involving the same or different material each time—counts as a revert. Also keep in mind that while violating the three-revert rule often leads to a block, you can still be blocked for edit warring—even if you don't violate the three-revert rule—should your behavior indicate that you intend to continue reverting repeatedly. Cassianto^Talk 21:14, 23 January 2018 (UTC)[reply]

Let's not be silly. I didn't perform any reverts at all; I tried numerous ways to integrate the very point at the core of your objection: that the case in which the serial comma introduces ambiguity is simply poor writing.  — SMcCandlish ☏ ¢ 😼  22:57, 23 January 2018 (UTC)[reply]

No, lets not, but then that's a bit of a hypocritical, isn't it, seeing as you did exactly the same on SchroCat's talk page. The fact you didn't use the revert feature is irrelevant; you indirectly reverted to another version that wasn't SchroCat's, which amounts to the same thing. And I'm not surprised he reverted you when you use questionable prose like this. Cassianto^Talk 23:08, 23 January 2018 (UTC)[reply]

Sorry, I meant SchroCat; you two tagteam so much you're indistinguishable. Regardless, the silly tit-for-tat template you've left for me is not applicable; I performed zero reverts, only edits attempting to merge SchroCat's concerns and mine.  — SMcCandlish ☏ ¢ 😼  23:46, 23 January 2018 (UTC)[reply]

Of course it wouldn't be "applicable" , would it, because you received it. You're hardly going to think it's justified, and if you did, you certainly wouldn't tell me, would you? Let's not forget, it takes two to edit war, and from an outsider looking in, you were the most definitely the second, although you went round the houses to do it. This'll be my last post. Good evening. Cassianto^Talk 23:57, 23 January 2018 (UTC)[reply]

I suggest you familiarize yourself with WP:REVERT, especially WP:3RR, and WP:ANEW. You're simply wrong on this. If party A makes an edit, party B reverts it, party A tries a different edit to merge A and B's concerns, B reverts, A tries another approach to getting what both A and B want, and B reverts, only B is editwarring, and only B has hit 3RR, A having 0 reverts. A is attempting to reach compromise, B simply to stonewall.  — SMcCandlish ☏ ¢ 😼  00:00, 24 January 2018 (UTC)[reply]

Hello! An old dispute that you were involved in has been brought up again. Your opinion is greatly valued. Thank you! KevinNinja (talk) 00:22, 24 January 2018 (UTC)[reply]

Re just-started Wikipedia_talk:Manual_of_Style#RfC_Should_the_usage_of_the_terms_"Arab"_and_"Arabic"_be_guided_by_the_Manual_of_Style? - the discussion might well benefit from any background info you may be aware of regarding the cultural sensitivity argument for Arab/Arabic MoS guidance. Batternut (talk) 10:21, 24 January 2018 (UTC)[reply]

It's more of a mainstream English matter. Even mentioning "cutural sensitivity" just resulted in drama, and WT:MOS is really not the place for it anyway; maybe List of English words with disputed usage is the place to source something like that.  — SMcCandlish ☏ ¢ 😼  23:34, 24 January 2018 (UTC)[reply]

Hi, SMcCandlish. I'm an arbitration clerk, which means I help manage and administer the arbitration process (on behalf of the committee). Thank you for making a statement in an arbitration request at Wikipedia:Arbitration/Requests/Case. However, we ask all participants and commentators to limit the size of their initial statements to 500 words. Your statement significantly exceeds this limit. Please reduce the length of your statement when you are next online. If the case is accepted, you will have the opportunity to present more evidence; and concise, factual statements are much more likely to be understood and to influence the decisions of the arbitrators.

Requests for extensions of the word limit may be made either in your statement or by email to the Committee through this link or arbcom-llists.wikimedia.org if email is not available through your account.

For the Arbitration Committee, Kevin (aka L235 · t · c) 14:30, 24 January 2018 (UTC)[reply]

Clearly Cassianto needs to be topic-banned from infoboxes, and ArbCom should consider whether further sanctions are needed. But a SchroCat is a metaphysical problem, because they might or might not be in the (info)box depending on the phase of the moon. Robert McClenon (talk) 02:43, 25 January 2018 (UTC)[reply]