Archive 220 Archive 223 Archive 224 Archive 225 Archive 226 Archive 227 Archive 228

MOS:DECOR and navboxes

Fairy tales often start in the same manner, like "Once upon a time", and so does this topic, as compared to my previous one: For a couple of years (and perhaps even more) I've been cleaning the articles from that, – well, now we'll talk about the navbox templates rather than the articles – however, recently I've met a significant population of users (by the number of – guess what? – two) who oppose to my edits so strongly that I have to draw your attention now.

The question is whether the navboxes related to a geographical region, such as Template:Nizhny Novgorod Oblast, should include the region's flag and coat of arms.

Two misconceptions presented by the opponents are: (a) "it is recommended to have these images there", which just doesn't turn out to be the case, and (b) "many navboxes have these, so there must be something to it", which is nothing but WP:OTHERCONTENT, a well-known invalid argument.

Now look: the navboxes in question always have a wikilink to the corresponding region's article (e.g. Nizhny Novgorod Oblast), and the first thing you'll see there is that same flag and that same coat of arms in its infobox. So what we have in a navbox is a duplicate. Furthermore, the images in an article's infobox have much larger size, enough to be clearly seen and comprehended, while those in a navbox don't. (And if we enlarge the images within the navbox, they'll increase the overall size of the latter, and eat up the precious space that should be dedicated to the navigation. This is especially significant to the narrower screens, e.g. the vertical.)

Generally, I think it all is already covered up by MOS:DECOR: "An icon is purely decorative if it does not improve comprehension of the article subject and serves no navigational function." However, my two opponents – both of them! – don't think so, and demand that I start the discussion here. They even have spawned an ANI case against me. So please help sort it out.

Should we include some special mention of it within MOS:ICON page? — Mike Novikoff 19:15, 4 January 2022 (UTC)

And I do not have any strong feeling either way about navboxes, but if they are not appropriate in ((Nizhny Novgorod Oblast)) why are they appropriate in ((Arizona))?--Ymblanter (talk) 12:28, 5 January 2022 (UTC)
MOS:DECOR provides unambiguous guidance. Those icons in the 2 navboxes mentioned above serve no purpose, add clutter and take up space in quite busy navboxes. They ought to be removed. -- Michael Bednarek (talk) 13:00, 5 January 2022 (UTC)
I agree here, especially the left icon. – The Grid (talk) 14:14, 5 January 2022 (UTC)
I agree that images are rarely appropriate in navboxes, and that most extant examples are violations of MOS:DECOR. I would support codifying some advice about this in P&G, though I think WP:NAVBOX (or the supplement WP:NAV) would be a more salient location than MOS:ICON. Colin M (talk) 17:42, 5 January 2022 (UTC)
I agree with the suggestion to codify this in WP:NAVBOX/WP:NAV. -- Michael Bednarek (talk) 04:14, 6 January 2022 (UTC)
I'm fine with any location, as long as it will cut off any future disputes.
At the first glance, the best place would be WP:NAV#Navigation templates are not arbitrarily decorative, where we already have such shortcuts as WP:NAVCOLOR and WP:NAVCSS (that I oftentimes use in my edit summaries). On the other hand, "This page is not one of Wikipedia's policies or guidelines, as it has not been thoroughly vetted by the community." On the third hand :-), we can use it nevertheless, and cut off any future disputes with a link to this discussion. Any better locations?
What exactly shall we put there? Maybe something like this (feel free to correct):
"Per MOS:DECOR, images are rarely appropriate in navboxes. Just like colors and styles, they should have a justification to appear. Specifically, there should be no national or regional flags or coats of arms. A rare example of an appropriate image is this: a map shows (in green) the location of a region within the state of Kazakhstan, and this is consistently implemented for all state's regions." (xref) — Mike Novikoff 21:30, 10 January 2022 (UTC)

Infoboxes

Would the thoughts here also apply to flags on lines of Infoboxes or is MOS:INFOBOXFLAG already solid? — GhostInTheMachine talk to me 12:58, 9 January 2022 (UTC)

See my reply there. In short: MOS:INFOBOXFLAG is solid enough. — Mike Novikoff 18:30, 10 January 2022 (UTC)

Closure?

It looks like we have an unanimous consensus here. To summarize: (a) most images, and in particular flags and coats of arms, should go away from the navboxes; (b) the proposed statement will be added under WP:NAV#Navigation templates are not arbitrarily decorative.

Shall we move on to implement it already, or do we need any extra steps such as a formal closure? I'll assume the former if there'll be no objections within the next few days. — Mike Novikoff 20:55, 17 January 2022 (UTC)

I've updated WP:NAV page. — Mike Novikoff 09:30, 30 January 2022 (UTC)
Given this has had only a half dozen users for what is likely to be several thousand navboxes (approximately 28,000), I would think a wider RFC would be called for. I have no personal strong opinion, but the trivial way to implement this would be to remove the parameter entirely, and I doubt any of the smarter template editors would take an edit request for this few responses. --Izno (talk) 22:47, 21 March 2022 (UTC)
Surely it would be easiest to just eliminate both |image= and |imageleft= at once, but note that there are some exceptions discussed above. I'm not sure what level of support they have, so maybe we really should start an RFC where the options would be "remove the parameters entirely" and "deprecate them but keep for some few exceptions".
As the more experienced user, will you start this RFC now? — Mike Novikoff 00:05, 22 March 2022 (UTC)

YMB

For the record, one of the two users who forced me to start this topic, an IP who is currently blocked for three months, turned out to be an LTA evading the indefinite block. And the second user, who said your edits get reverted on a regular basis... well, God bless him. My second cheek, my third cheek, my fourth one. Anyway, "what doesn't kill us makes us stronger". — Mike Novikoff 19:39, 1 February 2022 (UTC)

For the record, this will go to my collection of diffs to document harassment.--Ymblanter (talk) 20:16, 1 February 2022 (UTC)
You mean you will apologize for your harassment someday? Why not right now? — Mike Novikoff 20:32, 1 February 2022 (UTC)
No problem, I have enough patience.--Ymblanter (talk) 20:52, 1 February 2022 (UTC)
OMG. My collection of diffs is especially brilliant. — Mike Novikoff 21:02, 1 February 2022 (UTC)
Man, I'm lost for words. You've just lost the case, you've been supporting an LTA, yet you dare frighten me? If I were you, another ANI case would already have been filed. But I'm not you, so the revenge and collection of diffs are not among my goals here at WP. Will you just let me live? — Mike Novikoff 21:45, 1 February 2022 (UTC)

Interesting discussion...

...at armor-piercing ammunition. The article was originally written in BrEng but the title was originally in AmEng. Primergrey (talk) 03:19, 24 March 2022 (UTC)

I don't think it's an MOS-related issue, but I supported there. Dicklyon (talk) 03:52, 24 March 2022 (UTC)
It would not be unreasonable to have a line somewhere in the MoS that states an article title (if applicable) should reflect the same ENGVAR as established in the article body. TITLEVAR is sadly somewhat wishy-washy on this matter. (JMHO) - wolf 04:00, 24 March 2022 (UTC)
Pragmatically, in unusual situations like this, the path of least resistance is to change the title to match the body. It requires changing one thing over potentially changing a whole mess of things, and since neither is more correct than the other, we should do the thing that makes it consistent. --Jayron32 15:12, 24 March 2022 (UTC)

Hyphenation of ethnic groups used as adjectives

I couldn't find anything about this question in the archives. In "African-American Vernacular English" or "Asian-American culture", should there be hyphens? External style guides seem to have various opinions. MOS:HYPHEN gives the example of "Middle Eastern cuisine—using the adjectival form of a proper noun—as not needing a hyphen, but "African American" is not a proper noun. So I'd assume hyphens are warranted. In any case, I suggest adding something along the lines of "But never insert a hyphen into a proper name (Middle Eastern cuisine, not Middle-Eastern cuisine; Asian-American culture, not Asian American culture, because "Asian American" is not a proper name)." Perhaps split up over two sentences. Ovinus (talk) 14:47, 28 March 2022 (UTC)

I am certain that there was an RfC about this a few months ago. --Redrose64 🌹 (talk) 22:15, 28 March 2022 (UTC)
I think it was more like a year, but wouldn't swear to it; and,, IIRC, it was not specifically about adjectival use, but whether or not hyphens were acceptable in any context (i.e., "Curtis Loew was an African-American who picked cotton and played blues music"). Ovinus, I think you are for the most part correct, but I think there's another way of explaining the difference that doesn't require considering whether or not there's a proper noun: "African American" is an adjective (African) with a noun (American). Even though it often seems as though the two words together form one noun, that truly is not the case: an African American is an American of African descent, as likewise a European American is one of European descent. African describes 'American'. But "Middle East" has become the name for a paricular region; it is not describing the middle part of a larger area that is named "the East". (It did at one time, but now it is just a name for that region). Therefore, the two words ttogether make a single noun, and in its adjectival form it is one adjective derived from one noun that happens to be two words, while African-American in adjectival form is two adjectives being used together. That answer was longer than I meant for it to be, for which I apologise..I hope it made some sense :) 2600:1702:4960:1DE0:8D46:3093:F6BA:A219 (talk) 01:17, 29 March 2022 (UTC)

Spacing RfC

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
In this discussion, Th78blue proposes a change to the way we format text in the editing interface. The proposed change would have no effect on the rendered page but would improve readability of the wikimarkup for some editors, such as the nominator who is visually impaired.
The community reflects on this suggestion and notes that the proposal would also decrease readability of the wikimarkup for those who use small screens such as phones. With my closer hat on, I give considerable weight to this concern because editors from some communities would be disproportionately affected. Wikipedians who aren't from wealthy Western democracies very often edit from their phones because they don't have access to a desktop or laptop; so the proposed rule has downsides and needs to be considered in the light of systemic bias.
In the discussion below, despite some articulate and well-argued dissent, the community reaches a weak consensus that what's called for here is guidance rather than regulation. Editors are invited to discuss how to phrase an appropriate edit to MOS:ACCESS that would explain the benefits of leaving a white line after headings for visually impaired people, and also the drawbacks for small-screen users. When the phrasing is agreed, the appropriate edit may be made.—S Marshall T/C 11:51, 30 March 2022 (UTC)

Should the MOS say that a space is required (or suggested) between each section and the content below it and sub-section and the content below it? Firefangledfeathers 03:42, 18 February 2022 (UTC)

Adding the above so that this RfC has a brief neutral statement. Please read Th78blue's full proposal below. Firefangledfeathers 03:42, 18 February 2022 (UTC)

Hello all,

I have noticed that on user talk pages (see mine for instance) there is automatically a single line of white space in the source editor "back end" when you are editing, and that this line is helpful visually for people with me that have bad eyes because it presents the text more clearly as separate so that nothing mushes together. I have noticed on other main space articles that you can add a space on the back end of any article between a section or sub-section header, and it will not change the way it looks at all on the front end to the casual Wikipedia-reading public. I'd like to propose a minor change to the MOS, that a space be required (or at minimum suggested) between each section and the content below it and sub-section and the content below it. From an accessibility standpoint, this helps me greatly in reading the source editor (and I really do NOT like the "visual editor", call me "old school" that way). I do not think there is much of any reason to NOT allow for a space, because it does not affect the appearance in any way to the front end.

Example sub-section WITH a space below text as I am advocating for (notice ONLY appears different on backend/source editor)

Example sub-section WITHOUT a space below text, appears to "mushed" to me (notice ONLY appears different on backend/source editor)

I hope I have made my point clear, and if so, I'd add a brief one line to the MOS in the "Spacing" section that outlines adding a space between headers and content as suggested or as mandatory. I have spent some time adding such spaces to thousands of articles, and no one has yet raised any concern, until just recently someone asked me why I added a space. I just want to make sure everything that is ever done has the community and MOS support. Thank you very much. Th78blue (talk) 13:19, 17 February 2022 (UTC)

Survey (Spacing RfC)

@Masterhatch:, Thank you for your comment. Th78blue (talk) 17:16, 19 February 2022 (UTC)
Thank you for your comment FactSuperNerd. Th78blue (talk) 14:12, 19 February 2022 (UTC)

Final conclusion

Hello all,

After waiting some time now, it appears as if the 'consensus' is for a suggestion rather than any hard mandate. I will proceed with a slight wording change then to the MOS to reflect this unless there is any further comment or objection? Thank you all for participating, and please let me know how to "close" the RfC then. Do we remove this commentary from the MOS talk page? I am not familiar with all the steps. Th78blue (talk) 12:57, 12 March 2022 (UTC)

Consensus? Where? -- Michael Bednarek (talk) 13:58, 12 March 2022 (UTC)
@Th78blue: If you don't know how to close an RfC, you shouldn't be attempting to do so: the posts below demonstrate your lack of experience with RfCs. Since you initiated the whole thread and have posted numerous times since, you are not uninvolved and certainly shouldn't determine the outcome of what is clearly a contentious issue. --Redrose64 🌹 (talk) 17:09, 12 March 2022 (UTC)
My sincere apologies. Whom determines the closure then, just so I can follow along? Th78blue (talk) 17:20, 12 March 2022 (UTC)
For something this complex, any uninvolved admin - or a similarly-uninvolved experienced non-admin in good standing. You may file a request at Wikipedia:Closure requests. But it may be best to wait a few days, until Legobot removes the ((rfc)) tag, which should occur at 04:01, 20 March 2022 (UTC). More at WP:RFCEND. --Redrose64 🌹 (talk) 19:13, 12 March 2022 (UTC)
Thanks for the help with this from a procedural standpoint Redrose64. I will wait until after that date and time has passed and then I will follow up with your suggestion via a closure request. I know "consensus building" can be excruciating, but I also do enjoy it. Th78blue (talk) 17:09, 17 March 2022 (UTC)

Discussion (Spacing RfC)

I already got growled at weeks ago, for deleting whitespace from the intro of articles. BTW: Why isn't there an RFC tag for this RFC? GoodDay (talk) 17:51, 17 February 2022 (UTC)

Exactly the sort of issue that I am looking to fix by finally just having consensus around one way or another. Personally some whitespace (just one single line, and only underneath each header, helps me a lot due to my vision). I think your suggestion of an RFC tag is fine, I have not done many of these RfC's so I am not familiar with the format of that tag or where to put it, would you mind helping me out in this case then and I will then know for the future. Thanks in advance. Th78blue (talk) 17:58, 17 February 2022 (UTC)
Done. GoodDay (talk) 18:09, 17 February 2022 (UTC)
It's not being listed correctly because the statement is both too long and too complex - it contains subheadings. I don't know how many times I've pointed this out, but WP:RFCBRIEF is not optional. --Redrose64 🌹 (talk) 23:16, 17 February 2022 (UTC)
Thank you for pointing this out. I apologize, as this is one of my first RfC's for any change/update to the MOS (even if small). I can sometimes be verbose in my explanations, but I really try to get it right, and ensure that I am being articulating my points properly. Also, my eyesight is rather poor, even with my prescription glasses and enlarged screen. I am asking that people consider support of this proposal, if not as a new mandate (which I can understand opposition to), then perhaps as a suggested acceptable edit at least (to add a single space immediately beneath headers). Thank you very much for reading my comment (also, on a somewhat related or unrelated note, I liked the picture on your user page that says, "We need people like these. The one at far left is being punished for trying to explain what accessibility means, and why it is a bad idea to deliberately ignore it." That really rings true to me right now. Th78blue (talk) 03:33, 18 February 2022 (UTC)
I added a brief neutral statement above your proposal to comply with WP:RFC. Firefangledfeathers 03:42, 18 February 2022 (UTC)
Wonderful Firefangledfeathers. That is much more concise than mine, perfect! Th78blue (talk) 04:42, 18 February 2022 (UTC)
Feel free to voice a comment in the RfC itself if you'd like. I am trying to form consensus around this one way or another... which is never easy I find. Th78blue (talk) 04:48, 18 February 2022 (UTC)
Yes, that worked. Thank you --Redrose64 🌹 (talk) 23:08, 18 February 2022 (UTC)

Until I got a verbal spanking for it. You & I (@Th78blue:) were working in opposite directions. I had been removing white-spacing from the intro of articles, even when the spacing wasn't showing. GoodDay (talk) 23:33, 18 February 2022 (UTC)

I don't think anyone should verbally spank anyone on this great encyclopedia. It is too bad we can't all follow WP:DBI. I am sorry you had to experience that. If my proposal loses out, so be it. It is the will of the community. Though I'm holding out hope that we can perhaps find some middle ground with a suggestion instead of a requirement worst case. Th78blue (talk) 23:40, 18 February 2022 (UTC)
@GoodDay, what was your thinking on the value of removing invisible spacing? valereee (talk) 11:16, 19 February 2022 (UTC)
Gave me a gnome task, that would've lasted several months. GoodDay (talk) 18:07, 19 February 2022 (UTC)
Wow GoodDay, I can really relate to this! It is almost therapeutic to have a nice "gnome task" to work on. Th78blue (talk) 01:31, 21 February 2022 (UTC)
For gnome tasks that actually make a difference to readers, I like Wikipedia:Typo Team. I've got several I run checks for every once in a while. valereee (talk) 14:34, 20 February 2022 (UTC)

Th78blue, I wonder if this might be developed as something that could be opted-into via preferences? As an accessibility issue, if it weren't a daunting task, it might be of interest to developers. I like having spaces between lines of code when I'm working in source, too. It just makes things easier to find. valereee (talk) 11:14, 19 February 2022 (UTC)

I have never seen the "u" ping before? Interesting! Well let me try it. Valereee, your suggestion is a highly interesting one, over my head to be sure as it relates to backend development, but I'd be happy to see a fix here implemented any way that we could. Th78blue (talk) 14:10, 19 February 2022 (UTC)
@Th78blue, sometimes a good place to start is Wikipedia:User scripts/Requests. If it's simple enough (and I have zero clue on that), there may be someone who can write a script that you can simply install. Make your request as brief and concise as you can, and head the section something like 'Accessibility for visually-impaired editors'. Lots of people are interested in helping make editing more accessible. valereee (talk) 14:37, 19 February 2022 (UTC)
That sounds like a great suggestion. Let us see where this particular proposal ends up, and then I will look into that. Thank you very much for caring! Th78blue (talk) 14:38, 19 February 2022 (UTC)
@Valereee: @Th78blue: I didn't know scripts like this existed - I actually popped in to say that I've talked to editors unfamiliar with accessibility templates like ((lang)) and ((transl)) before who have commented that they seem a lot of work, but it's really little gnome-like things that make a big difference. Are user scripts purely visual styles, like user-defined css?--Ineffablebookkeeper (talk) (((ping)) me!) 22:31, 21 February 2022 (UTC)
@Ineffablebookkeeper, there's a list at WP:User scripts/List. One of them even automatically installs other scripts for you so that after you've installed that one, you don't need to screw with your scary (jcs?) page. valereee (talk) 22:38, 21 February 2022 (UTC)
@Th78blue: anything that makes a link to a user page has the potential to trigger a notification. ((u)) is merely one of many templates that create a userpage link, as is ((replyto)) that I used here. See WP:MENTION. --Redrose64 🌹 (talk) 16:21, 19 February 2022 (UTC)
Interesting. I traditionally always used the "ping" one, such as @Redrose64:. Is any one more "appropriate" for use than another or anything? I even saw someone use "yo" once, but when I tried it, it did not format correctly for me to them I believe. Th78blue (talk) 16:24, 19 February 2022 (UTC)
((replyto)), ((yo)) and ((ping)) are merely redirects to the same template (I don't like "ping" as a term, see this post for why). Which method that you use (a simple link such as Th78blue works just as well as any template) depends primarily upon the appearance that you desire. --Redrose64 🌹 (talk) 17:09, 19 February 2022 (UTC)
Thank you very much this information. I will forever more try and not use ping, just because. Why not!? I will thus @Redrose64: you here, and if it is not a reply, but a first reach out, then I might just use Redrose64 instead. Every single day I learn more on this great encyclopedia. Th78blue (talk) 17:14, 19 February 2022 (UTC)
Is there any difference in terms of the "notification" that you receive on your end depending on whether it has the "@"-sign or not? Does that do or mean anything else? Th78blue (talk) 17:15, 19 February 2022 (UTC)
No. The text and formatting are exactly the same. --Redrose64 🌹 (talk) 18:00, 19 February 2022 (UTC)
How about first creating a template for an options blank line, and stating that
  1. Editors should include that template in the lead of new articles
  2. Editors should not insert an initial blank line in existing articles.
  3. Editors should not remove an initial blank line from existing articles.
I see no reasons for any of the above to be MUST or MUST NOT. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:05, 20 February 2022 (UTC)
@Chatul: This isn't about blank lines at the start of articles, but below section headings. --Redrose64 🌹 (talk) 22:31, 20 February 2022 (UTC)
Redrose64, I am open to any and all "compromises." It is never "my way or the highway" on the encyclopedia after all. I like your templated "options" @Redrose64: Th78blue (talk) 01:34, 21 February 2022 (UTC)

Whether it is merely allowed or is actively recommended, this is not the sort of edit that needs doing by itself. Nobody should be going around making edits that simply add this spacing without anything else. And ESPECIALLY shouldn't be going around doing multiple such edits to a single page by editing each section separately. --User:Khajidha (talk) (contributions) 16:44, 23 February 2022 (UTC)

Comment - @Th78blue: I hope you don't mind me clarifying a few things about this RfC and your reason for proposing it. I looked through your edit history in an effort to better understand this RfC, and what I noticed was that you were moving alphabetically through the Florida city articles. Your edits at first were useful cosmetic edits, but then you focused almost exclusively on adding extra lines under each section in the article, sometimes five or more edits per minute, each time adding an extra line under a section heading, saving the edit, then moving to the next section. Then you moved alphabetically to the next city. You made hundreds of bot-like edits until your reached "M"--Miami--when I left a message on your talk page asking why you were doing this. You then immediately responded by creating this RfC, explaining that you were adding all these extra lines because of a vision problem. But when I looked though those hundreds of edits, not once did you ever leave an edit summary explaining that your were doing this because of a vision problem. Did you explain this somewhere and I missed it? Thanks! Magnolia677 (talk) 21:21, 23 February 2022 (UTC)

Hi Magnolia677, thank you for asking about this again. I appreciate your kind words as always. I edit as I do normally top down, alphabetically, and then (if you review my edit history it will confirm this) I often return to articles where I might have missed something after a first pass. I try to get things in one go, but hey, we all have different styles right? If you'd like, I can try and upload my eye prescription via wikimedia somewhere. Just let me know how to do so, and I will obviously black out any personally identifiable information before doing so. Would that help? Th78blue (talk) 21:33, 23 February 2022 (UTC)
@Th78blue: Yes, you mentioned that you were going from article to article adding extra spaces, so that when you returned to do more editing, it would be easy to see. Yet, prior to my commenting about what appeared to be bot-like additions of extra lines, you returned to few of the Florida articles you had edited. And when you did, your vision problem didn't seem a priority. For example, at Avon Park, Florida, you made this edit to the "notable people" section, during which--along with other edits--you added an extra line after the section heading. But when they returned to that article three weeks later, you edited a table in the "geography" section, and didn't add an extra line under the geography heading. I'm just pointing this out because we are considering a change to the MOS that could effect thousands of editors. Magnolia677 (talk) 23:17, 23 February 2022 (UTC)
Okay Magnolia677, I will see how I can upload a picture of my prescription for you. In the meantime, I think we were looking into this as a suggestion instead of a hard mandate. Which should make it essentially a non-issue for any and all editors (was my hope and thinking at least) as it relates to how they edit now, and how they would edit in the future. I have added extra lines under many new entries since, but only when accompanied with another edit (that is all that has changed from before this MOS RfC to now). Prior to us having this discussion it was not clear as to whether or not an editor could add spaces underneath headers, and so I proceeded to do so without issue previously. Now, I am only adding spaces when it is accompanied by other edits. Such as I did recently at: Yankeetown, Florida, Worthington Springs, Florida, Windermere, Florida and dozens upon dozens others in FL (I am now done with my first pass through FL by the way... so it will be some time before I "touch" those again, but I never leave anything forever). My aim is not to make anyone's life more difficult or to make their editing style harder, but only to ensure that I can edit in a non-disruptive fashion without fear of being unexpectedly reverted myself. Not just by you mind you, but by anyone. I do my best to follow the MOS to a "T", but if there is an aspect of it that we can change (ever so slightly) for WP:ACCESS purposes, then I do not see any issue with that either. I have never uploaded an image for the purpose of just proving my bad vision before, where should I upload that to? If you could help, I'd be happy to do so. Th78blue (talk) 23:33, 23 February 2022 (UTC)
The current MOS text says the blank line after the heading is optional. Nothing needs to be changed in that wording to permit you to add blank lines after headings while editing articles for other purposes. Schazjmd (talk) 23:40, 23 February 2022 (UTC)
@Th78blue and Schazjmd: The RfC question is "Should the MOS say that a space is required (or suggested) between each section". This is a major change, as thousands of new editors will start adding an extra line after each section heading. It is also quite wonderful that so many editors have sympathized with Th78blue's claim that they went from article to article adding lines in a bot-like way, because adding an extra line would somehow make it easier to edit at some point in the future when Th78blue returned to the article, even though when they actually returned to the article they edited a section that had no extra line (and didn't add one). I also noticed that last month another editor asked Th78blue "why do you make so many edits instead of just one?", and "I did mention those bulk edits because it seems like a potential case of editcountitis", and their response about why they edit that way didn't mention vision. Magnolia677 (talk) 23:55, 23 February 2022 (UTC)
Magnolia677 You've made your incredulity of my poor sight clear. Moving on to the next point, I refuted that already above for anyone who wishes to verify (with dozens of articles where I have continued over the past week [plus] to add lines beneath headers, but now only with an accompanying other valid edit). Also, I am not kidding about adding my prescription. I just need to figure out where/how best to do so (as I asked above, I am open to your feedback, hostile or not). Lastly, the RfC has hardly been a resounding string of support, there have been a number of editors that have said that they do not wish any change, and in that event, so be it. However, I was happy if we could even just move forward with the suggested wording. I myself am convinced that a "mandate" or "requirement" is a bit much at this stage to be frank. Th78blue (talk) 00:08, 24 February 2022 (UTC)
Friend, I'm not trying to embarrass you or hurt your feelings. I just care a lot about the project, and to be honest, the reason you gave (twice) last month for why you edit this way makes way more sense. Magnolia677 (talk) 00:18, 24 February 2022 (UTC)
Magnolia677 Understood, and I can see that you do care a lot about the project, as do I, which is good. As promised,
here is what I could upload just now.
My apologies for the delay, I wanted to properly cover up personal info for obvious privacy reasons, and digitally "redacting" and then uploading a form like this is new to me. Th78blue (talk) 03:16, 24 February 2022 (UTC)

Suggested followup RfC

I'd like to see an RfC about not opening community-wide RfC's out of the blue on random subjects about which there's been zero prior discussion to clear the ground or frame or focus the question. EEng 02:41, 24 February 2022 (UTC)

, sorry its been a bother. I am not super well versed in the proper goings on regarding a proper RfC yet... My apologies. Th78blue (talk) 02:57, 24 February 2022 (UTC)
It's not just you. This happens all the time. EEng 04:01, 24 February 2022 (UTC)
This is why we have WP:RFCBEFORE. --Redrose64 🌹 (talk) 19:31, 24 February 2022 (UTC)
But unfortunately what we don't have is WP:RFCBEFOREENFORCEMENT. EEng 22:48, 24 February 2022 (UTC)
@EEng: and @Redrose64:, you both appear much more "senior" than I. How can we tell when my original RfC is "done" and "consensus" is "reached" ? Th78blue (talk) 03:02, 4 March 2022 (UTC)
I initiated a request for closure here just now, just so all involved are aware. Wikipedia:Closure requests, thank you! Th78blue (talk) 21:09, 21 March 2022 (UTC)
Another example of an RFC with effectively no discussion on the issue is here. The creator of the RFC effectively based it on a comment by an IP made about 7 months ago, where there was no discussion or response. The question was also vague, but that is a different issue. 2601:647:5800:1A1F:889E:96A8:F1A2:A8E7 (talk) 23:06, 23 March 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Question (loosely) relating to ENGVAR

As you all are likely aware, it is the situation with the spelling of certain words which for one variety of English, only one spelling is used, but for another variety, two variant spellings are acceptable (usually with one being preferred, or at least more common than the other). For words in which the more common spelling in one variety is the same as the only acceptable spelling in the other variety, the obvious practice is that that is the preferred spelling encyclopaedia-wide: e.g., jail, connection, glamour rather than gaol, connexion, glamor. But, if the only acceptable spelling in one ENGVAR is in MINORITY (but, let's say, SIGNIFICANT minority) usage in the other variety, is that spelling permissible in an article that uses that English variant? Unfortunately, I only know if American English examples (other than Oxford spellings, which is already covered by MOS): grey, theatre, draught, are all less common in America than gray, theater, and draft; however, all of them are still used, not infrequently, and none of them are are considered incorrect. So, if an article's English style is "American English", are the majority spellings required, even when the minority spellings are not uncommon, and are still deemed acceptable variant spellings? And if so, would that not basically be enforcing an artificial version of "American English that is not reflective of actual usage? (That is, if, say, 40% of American English sources use theatre, but we enforce theater in 100% of the articles written in American English - would that not distort reality?) 2600:1702:4960:1DE0:4D69:F0F8:A0CA:5BC (talk) 02:45, 2 April 2022 (UTC)

The short answer is "yes". None of them are considered incorrect. The English Wikipedia prefers no national variety of English over any other. Unlike some other languages, there is no standard form of English. There aren't even any national standards. What we have is style guides. While we might speak loosely about "American English" (for example) there is no official standard. Indeed English isn't even the official language in the United States. What there are is significant regional and organisational style differences, in many cases documented in style guides. Even if you live your whole life in a small town somewhere you will still be exposed to different styles through books, broadcasts and (of course) the internet, so what style something is written is unimportant because everyone can understand anyway, and if they actually encounter an unfamiliar word or term or phrase then that is desirable from our point of view, because it is in line with our educational mission. What we are concerned about on Wikipedia is preventing a series of edit wars over style. Our own MOS is restricted to matters where confusion might arise. Hawkeye7 (discuss) 21:04, 2 April 2022 (UTC)

"She" for ships

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
In this RfC, there were slightly more editors supporting the MOS change than those in favour of keeping the status quo, and there were a few neutral as well. Arguments in favour of changing MOS guidance on ship pronouns from "she" to "it" included that it would align with most style guidelines and that the use of "she" is an antiquated/informal/specialized appellation. Arguments against changing the MOS guidance included past precedent, MOS:RETAIN, and the continued usage of "she" by some navies and specialized sources.

I believe, based on the arguments presented, that there is consensus to change the MOS guidance—not delete "she", but change when it should be used. Per WP:TECHNICAL, "The content in articles in Wikipedia should be written as far as possible for the widest possible general audience." I believe there is a consensus that the usage of "she" (or gender in general) in referring to non-living entities such as ships is unconventional to unspecialized readers and unexpected (WP:PLA) in an English-language encyclopedia. The argument regarding style guidelines dissuading "she" is also pertinent. Editors/navies/academics remain free to use "she" outside of the project; a change to the Wikipedia MOS is not infringing on that. There was no consensus in regard to the RfC question specifically.

However, there was an additional argument about following what sources write depending on the ship, and there were also concerns about how such an MOS change would be implemented if there was consensus to do so. The fact that the MOS (such as GNL) is guidance is also a factor. Therefore, I believe there is also a consensus that ships currently using "she" should not be changed to "it" until there is a consensus on the ship article's talk page that a majority of relevant sources use "it" in referring to that particular ship. If it is determined that "she" is more prominent, a note of some sort indicating to readers why "she" is used would align with WP:AUDIENCE. I believe this caveat aligns with WP:V's "content is determined by previously published information rather than the beliefs or experiences of editors" and will result in the smoothest outcome for editors and articles alike. (non-admin closure) Heartfox (talk) 02:48, 11 April 2022 (UTC)

Should the MOS guidance about pronouns for ships be changed to prefer "it" over "she"? 16:47, 7 March 2022 (UTC)

Note: This discussion started on 3 March with the post below. Participants in the last RFC were pinged on 4 March. It was added to WP:CENT on 5 March. Due to the high volume of responses and !votes, I have added the ((rfc)) tag to it on 16:47, 7 March 2022 (UTC) with what I hope is a neutrally-worded, short question that summarizes the question up for discussion. If anyone thinks the RFC question is not neutral or should be improved, please feel free to change it directly. Levivich 16:47, 7 March 2022 (UTC)
The issue is that by treating it as an RFC we are combining responses to the now-neutral notice, and to the previous non-neutral notice that predisposes the reader towards a particular conclusion. Because of this previous notice the normal consensus decision-making process has been compromised and it will be difficult, if not impossible, for a closer to determine the consensus here. BilledMammal (talk) 01:29, 17 March 2022 (UTC)

I understand that this issue has been previously discussed here. More supported than opposed by my count, but the vote was close to evenly split and the status quo remained in place. That was over two years ago, and is worth reconsidering as the modern English language continues to evolve; "she" for ships is in decline (Case-insensitive English Google Ngram). In popular parlance, the tradition of naming ships 'she' has now become less common. It's worth noting that the shipping industry newspaper, Lloyd's Register of Shipping, now calls ships ‘it’.[1] Using "she" instead of "it" to refer to a country, ship, or vehicle is now considered "old-fashioned".[2] Wikipedia itself no longer does this for countries or vehicles except in quotations, making ships the last remaining bastion of this tradition on the site.

It is more than just some grammar oddity, but has significance to tone, as it is a form of personification and isn't gender neutral. Consider this example, "Look at my new car - isn't she beautiful?" It personifies the object, regarding it as feminine.[3] According to O’Conner and Kellerman, "the personification of nonliving nouns (e.g., ships or nations) as 'she' has fallen out of common usage. It’s now generally considered quaint or poetic."[4]

This can tradition can be distracting, and even seem sexist to readers. This is because the tradition of gendering boats as "she" can be associated with portrayals of women as controlled by or as relying on men. That may sound like an extreme claim, but the military is a male-dominated sphere. Consider the following example from a U.S. Navy official website, "In the course of a ship's life, she may have had more than one husband but this had little bearing upon her true affections. Tradition has it, her love was saved solely for her sailors." As another example. an article in favor of calling ships "she" by Rear Admiral Francis D. Foley, U.S. Navy (Retired) argues that "Ships are referred to as "she" because men love them." This is not to say that there's anything violent or hateful about love and affection between men and personified objects, but rather that it's less appropriate for an encyclopedia, and ends up reinforcing traditional notions of femininity and heterosexuality, at least if we take the U.S. navy at its word.

This personification of objects is usually done for poetic effect or to show strong emotional attachment.[5] Once again, I have no problem with that but Wikipedia is an encyclopedia, and should express a neutral point of view using an encyclopedic tone. One of our articles, She (pronoun), even states that "She can also be used for ships and other inanimate objects of significance to the owner." But Wikipedia shouldn't show affection for ships or treat them as if they carry any special significance to editors nor does it own any.

Other serious publications, such as the Associated Press, New York Times, BBC, Guardian, Reuters, National Public Radio, and the US Coast Guard use “it” or “its” to refer to ships and countries. And as previously mentioned, Lloyd's List, the 273-year-old London-based shipping newspaper, officially dropped the gender personification and now refers to ships with the pronouns "its" and "it" instead of "her" and "she."

Per Wikipedia policy to use modern language and gender-neutral language, I suggest we we do away with "she" for ships, as a fellow Wikipedian argued in The Signpost all the way back in 2014.

All this is relevant because of our current policy not really providing guidance on the issue (see: WP:SHE4SHIPS and WP:SHIPPRONOUNS). I've noticed that despite official policy stating that both both "she" and "it" are appropriate, only "she" is almost always used used, as enforced by warring editors (see: USS John S. McCain (DDG-56), USS John S. McCain (DL-3), HMS King George V (41), Soviet submarine K-278 Komsomolets, and Soviet submarine K-222). Talib1101 (talk) 18:04, 2 March 2022 (UTC)

WP:ENGVAR would seem to rule here; especially the notion that one should not change between equivalent forms arbitrarily. If the first stable version of those articles used "she", then that pronoun should be maintained, and not changed to "it". The converse would also be true for ship articles that were started with the pronoun "it". Whether or not the guidance should be changed to recommend only "it" is another conversation to have, but only on your last statement regarding enforcement of "she"; if those articles started with the pronoun "she", then they should keep "she". If those articles started with "it", then they should continue to use "it" today. That's fairly simple. --Jayron32 18:54, 2 March 2022 (UTC)
I'm flabbergasted to learn that Wikipedia is still doing this. "She" for ships was already pretty archaic in British English when I was growing up in the 1960s. Is it really still acceptable in any other variety of English? Phil Bridger (talk) 19:02, 2 March 2022 (UTC)
I'm all for having that discussion. Someone who is concerned should maybe start a new, neutrally worded, RFC. People should be prepared to comment on that discussion with up-to-date style guides and other evidence. --Jayron32 19:16, 2 March 2022 (UTC)
Before someone starts this entire thing up all over again, there should probably be some evidence things have substantially changed in the past 2 years, enough that this should be discussed again. Two years is not a lot of time (how many editors showing up won't have already been here since the last time), and this has been exhaustively argued. Exhaustively arguing it again because Wikipedia isn't moving to their political timetable is not going to be a great foundation for an RfC. Der Wohltemperierte Fuchs talk 19:55, 2 March 2022 (UTC)
I don't see any connection to WP:ENGVAR. There is no national variety of English involved.
And I am against any "first come first served" style rule so would not want to apply WP:ENGVAR even in principle. Bryan Henderson (giraffedata) (talk) 01:27, 5 March 2022 (UTC)
The current situation is "first come first served" by virtue of MOS:RETAIN. Primergrey (talk) 12:52, 5 March 2022 (UTC)
MOS:RETAIN has nothing to do with pronouns, it has to do with article style (i.e. citations and date formats) and national varieties of english. Floydian τ ¢ 15:14, 24 March 2022 (UTC)
Before this discussion inevitably descends into personal attacks, accusations of sexism or worse like all the previous discussions on this subject here - may I remind everybody that MOS is subject to discretionary sanctions.Nigel Ish (talk) 19:58, 2 March 2022 (UTC) Bolding this to ensure that it is prominantly displayed. Cinderella157 (talk) 02:17, 3 March 2022 (UTC)
My feeling is we should avoid it simply because it is not precise language and I'm not sure it would be considered grammatically correct as English doesn't traditionally apply gender to non-gendered nouns. I personally see it as a term of endearment/respect and would be happy to use it in casual discussion but I prefer we use more precise language as a rule. I think we should avoid it for the same reason we should avoid many value laden labels, often they aren't precise, if you will, clinical terms. Certainly we should not avoid it in quotes or similar. Springee (talk) 21:21, 2 March 2022 (UTC)

I tend to agree with David, ie "what has changed"? Many navies continue to officially refer to ships as "her" - see Australia, UK, US and Canada. Peacemaker67 (click to talk to me) 02:01, 3 March 2022 (UTC)

Can someone close this? No evidence has been presented that usage has changed to justify another RfC on the matter from 3 years ago. It appears to be a waste of editor time to rehash it again.  Spy-cicle💥  Talk? 02:07, 3 March 2022 (UTC)

Agree with PM67 and Spy-circle. What has changed to justify another WP:BIKESHED. Cinderella157 (talk) 02:21, 3 March 2022 (UTC)

Comment: The last discussion was in favor of using both "it" and "she", yet it seems that almost every article uses she, even some that originally used "it" when they were first drafted, which is not in accordance with MOS:RETAIN. What's up with that? It seems that despite the "it" variant being stronger, as per my reference to Google Ngram, "she" dominates Wikipedia due to a group of devoted fans. I've also noticed many articles using a mixture of "it" and "she", which is inconsistent and undesirable. And, regardless of what the U.S. Navy calls it, other encyclopedias such as Britannica refer to ships as "it" and "its", not "she", "her", and "hers". Talib1101 (talk) 05:09, 3 March 2022 (UTC)

Yes, reopen the discussion. Much has changed in five years. BeenAroundAWhile (talk) 05:24, 3 March 2022 (UTC)

We dropped almost 80,000 words on the topic ending "2 years, 2 months, 7 days" ago at Wikipedia talk:Manual of Style/Archive 217#"She" vs. "it" for ships. The closer wrote that there was a "neck-and-neck discussion, with neither side gaining a decisive advantage". We can do it again, and I'd like to get rid of what I see as an old fashioned personification of objects, but I think the odds of reaching a consensus for any change is unlikely just two years after we tried before. Give it say, three years from now, and try again. SchreiberBike | ⌨  05:54, 3 March 2022 (UTC)

My comment above was against having the discussion (and the incivility and bad faith arguments below support that thought), but now that we're having it anyway, I'll add that I support "it". Rather than making further arguments, I'll say that @Snow Rise: is making excellent points below. SchreiberBike | ⌨  16:36, 7 March 2022 (UTC)
I prefer we use more precise language as a rule What is precise for one reader is imprecise for another. My experience it so find "it" for a ship to be imprecise, because, in sources I use, a ship is usually "she". Rewording some bits of Wikipedia with "it" would be a massive job, because there are many sentences here where "it" and "she" differentiate between a ship and some other inanimate object – simple substitution in those cases would leave massive ambiguity. This is just a battle against a useful grammatical diversity in the English language. ThoughtIdRetired (talk) 09:13, 3 March 2022 (UTC)
Using pronouns in this way does not produce clear prose. When there are two inanimate objects, it's much clearer to use e.g. "the ship" and "the dock" rather than relying on readers unfamiliar with maritime jargon to figure out that "she" illogically refers to one inanimate object and not the other. -- Beland (talk) 05:44, 5 March 2022 (UTC)

I think 2 years is too soon. Besides that, I think MOS:VAR is a great answer here. Articles that started with "she" keep "she" and articles that started with "it" keep "it". We don't need more rules forcing people to abandoned certain styles. Masterhatch (talk) 11:41, 3 March 2022 (UTC)

Collapsed. Enterprisey (talk!) 03:18, 16 March 2022 (UTC)
  • @RandomCanadian:: you are not permitted to unliterally collpase the good-faith, on-topic contributions of other editors in an open discussion, just because you are not happy with your arguments being refuted: that is not how discussion on this project proceeds. Talk page guidelines make clear that collapsing in discussion spaces is only to take place in specific circumstances, none of which apply here, whatever your feelings about your rhetorical opposition's reasoning and no matter how loudly you make strawman arguments about another editor's supposed lack of objectivty compared to your own, as based one interaction. That's a weak rhetorical ploy utilized by those whose primary arguments on the actual issue under discussion are not suceeding, and I would recommend you avoid it altogether; I am only involved in this discussion because I was originally brought to it by an WP:FRS notice for community input: it is not a topic I am looking to engage with due to some deep underlying attachment, nor a "hill I am looking to die on" no matter how much throwing out such a random supposition may appeal to you as a quick and lazy way to undermine the position of another editor you disagree with, rather than engaging with the substance of their argument itself--or in this case, the refutation of arguments you made where the conclusions did not flow from your antecedents. Further, your edit (and edit war to restore it) also moved my comment, such that it appeared to respond to a different comment than it originally followed, which is also not permited under policy. If you edit war again to try to suppress my or another editor's comments (or to reframe them inaccurately by moving them or otherwise changing their content) again in this discussion, I will be seeking admintrative review of your conduct here. You do not get to pick and choose which responses to your comments will be displayed on screen. That is not the manner in which wikipedia's collaborative discussions operate. SnowRise let's rap 22:25, 15 March 2022 (UTC)
    WP:BLUDGEON is a perfectly valid reason to collapse posts, particularly when it is so obvious like here (in three comments, you have over 13 kb of text, which is obviously excessive - and even more staggeringly, you haven't addressed the key argument which is that A) this is just a matter of personal preference and B) it's a huge waste of time [as your walls of text are proving on their own]). And since you bloody insist, you were specifically asking for examples of Wikipedia following subject specific sources (like we do in plenty of topics). That you don't like it and keep dismissing it as being the fault of some vague "hobbyist editors" is not a convincing argument, and is further proof that this is just a matter of personal opinion - and if you feel the need the make ad hominems by implying that other editors are too biased to be able to make a correct decision, then that just reflects badly on you. RandomCanadian (talk / contribs) 23:22, 15 March 2022 (UTC)
    As to A), are you familiar with the logical fallacy of begging the question? The very issue the community is discussing right now is whether or not this ought to be left entirely as a matter of individual editorial discretion, or whether we ought to deprecate a usage in conformity with our own internal style guidance on other such colloquial uses of pronouns, the substantial entirety of the world of style guidance, and rational clarity for the reader's benefit. It's not compelling argument for the position you support if your line of reasoning amounts to you saying your prefered solution should prevail...because it should. Regarding B) Nobody is forcing you to engage here, my friend, and you're the one who engaged with my thoughts first--so why the sudden shock that someone might choose to refute your observations in that context? This is an open discussion and has had the volume of response from the community that it has because, even if its not something the project's direction is going to turn on, neither is it a completely trivial question: this will impact a class of articles that can be defined as "any Wikipedia article which mentions a ship". That's not a small number of articles. I personally completely understand why it as attracted the attention it has, and I think just loudly and repeatedly declaring that it's not important contributes nothing to reaching a consensus on the actual topic itself.
    Clearly it's important enough, and guess what: what's good for the goose is good for the gander--you can't stake out a firm position in a discussion and then start leaning on to how it's all just a waste of time anyway. What kind of reasoning is that? Nor can you extend that logic to hide behind relative volume of the comments: it sometimes takes a much longer amount of time to respond to poor arguments or incorrect information than it does to just throw the flawed suggestion out there in the first place. That's just the nature of things in a collaborative space. I responded to Eek's post (and your response to that comment) because I believed they contained some bad arguments and material mistakes about policy concerns, and (contrary to your own hot take on the question) that the issue was large enough that such errors deemed being addressed. For the record though, I also don't think this issue can be boiled down to just a 'hobbyist' vs generalist editor divide: I believe it is more complicated than that.
    But now this discussion truly -has- gotten meta and tangential to the actual discussion, which is why I self-collapsed my last post. Note that this is a very different matter from collapsing someone else's post, but I'm not going to edit war over it. If you should change your mind, please feel free to collapse the last three or four posts in our exhange: that will have no objection from me. But if you opt to do so, please leave my response to Eek and my post following your response visible, as I believe our discussion up until that juncture was on-point and germane and never should have been collapsed. Everyhting we have had to say to eachother since probably never needed to be said, so feel free to collapse it or even (as far as I am concerned) even delete or hide the text of the last few comments if you wish, and feel the thread will benefit from it--just be careful of breaking the formatting of the discussion. I have no more wish to bloat the discussion than you. SnowRise let's rap 01:04, 16 March 2022 (UTC)
    Sidenote: As to the suggestion that I levelled an ad hominem at you, I reviewed the entirety of my exchange with you, and I don't see anywhere that I can be said to have done that. And I'd be surprised to have found something of that nature, as I try to make it a policy to frame any debate on this project in terms of the arguments themselves and avoid direct and generalized statements about other parties. If you feel there is somewhere where I have failed to adhere to this standard, please bring the matter to my talk page and clarify the specific statements and I promise I will address the issue there, including with an apology if I genuinely did employ an ad hominem or anything close. SnowRise let's rap 01:04, 16 March 2022 (UTC)
    I can very well stake out a position against something and point out how absurdly long the conversation over it is. The bike-shed effect is not just fiction, it's a very real thing, and we should seek to avoid it as much as possible - something to which your comments of excessive length are not helping. If you can't make your point concisely, it's unlikely you're going to convince anybody. RandomCanadian (talk / contribs) 01:14, 16 March 2022 (UTC)
    The scale of importance necesary to determine whether an issue is a "bike-shed" (in the meaning of that idiom) depends on what you think the actual structure of importance here is--and it's unclear to me what you think that larger issue is. If the larger interest is merely "Wikipedia as a whole", that's a poor argument, given Wikipedia is substantially a collection of many such small issues, each appearing trivial when examined on its own, but most of which need to be addressed in order for the smooth operation of the project's functions. Without having an interest more narrow than "all of wikipedia" but broader than "this question" it's impossible for me to know what you are trying to say when you invoke the bike-shed effect in this context. I will only repeat that, given the number of articles that could be potentially impacted by any result in this discussion (surely several hundred thousand at least), and given the numbers of editors whose interests the issue cuts accross, the scale of the discussion is not surprising to me. But anyway, I believe it would be in the best interest of readability of this thread, and permitting the discussion to move on from our difference of opinion here, if I were to collapse our discussion, starting from the post where I pinged you. Do I have your permission to do that? SnowRise let's rap 01:45, 16 March 2022 (UTC)
EDIT for additional rationale: some editors do note that they find such usage as jarring, or even "disorienting". I can assure you that the feeling is similar on the other side of the fence... when I see a boat referred to as an "it", I find it equally as jarring and actually disrespectful. My experience is actually very common in the maritime communtity. In my opinion, in articles pertaining to maritime topics, all other things being equal, preference should be given to terminology generally used by mariners. Le Marteau (talk) 14:06, 23 March 2022 (UTC)
@Le Marteau: your primary reasoning is WP:ILIKEIT. You have to put yourself outside of the maritime bias and look at the average reader. the fact you consider it "Disrespectful" means this is a very "personal" preference. It adds a tone to Wikipedia because its the only inanimate object that is allowed to be given a gender pronoun in all of Wikipedia. and that preferential treatment shouldn't be acceptable.Blue Pumpkin Pie (talk) 18:27, 29 March 2022 (UTC)
@Blue Pumpkin Pie:It adds a tone to Wikipedia.... This is your subjective opinion. Mine is, that it is disrespectful, and considered as much by most mariners and many land lubbers, and I consider both yours and mine, valid rationales.Le Marteau (talk) 18:58, 29 March 2022 (UTC)
The fact you consider it "disrespectful" only proves my point further that it indeed adds a personal tone to it and removing it would cause some disrespect. Otherwise, removing pronouns would seem "an odd adjustment" at its worst. WP:PRONOUNS says to avoid them when unnecessary. And in this case, objectively, they're not. WP:TONE also pushes for a more formal and neutral tone. There are no female pronouns on tanks or airplanes anymore, despite some military biased individuals continuing to use them. So in your own words, as a Wikipedia editor first and maritime last, why should Wikipedia make naval ships the exception? The openly subjective perspective of this shouldn't be accepted in wikipediaBlue Pumpkin Pie (talk) 20:41, 29 March 2022 (UTC)
WP:ILIKEIT. There you go, with my compliments. Not you, but I sense there's a lot of that on this RFC masquerading as objective judgement, but I'll go ahead and say it, and if you or the closer chooses to disregard anything I've said on this, or strike it, or remove it, I've stated my case and I'll rest satisfied with that. G'day to ye, matey. Le Marteau (talk) 21:03, 29 March 2022 (UTC)
EDIT for additional rationale: When some of you read 'she' for 'ship', a lot of you hear an old salt, or others a bigot, or a mysogynist, or a poseur of some sort, and say it comes across as unnatural. For those of you, I encourage you to listen to ten seconds of this fine craftswoman say 'she' or 'her' three times, then tell me it does not sound completely natural, unaffected, and anything but mysogynistic or archaic. Tell me her words would sound better if she succumbed to the pressure of the 'she' haters and said 'it' insead. Because this is the kind of speech I hear in my head when I read such words. Cued up to the 10 seconds I'm referring to. https://www.youtube.com/watch?v=ou4HyS68Nfk&t=178s Le Marteau (talk) 23:54, 1 April 2022 (UTC)
Sounds overly romanticized and personalized for referring to an inanimate object to me. And it sounds even worse when used in an encyclopedic context. User:Khajidha (talk) (contributions) 16:35, 6 April 2022 (UTC)
@Spy-cicle: oh, don't forget you're apparently a "misogynist" as well. (Just another in the lonnng line insults being posted against opposers here). - wolf 03:22, 5 April 2022 (UTC)

Some ngrams of another (more accurate?) colour...

As Blueboar pointed out, running ngrams for phrases such as "her/its sails were" or "it/she steamed east" yields results that consistently and strongly favour she/her. For your convenience: her/its sails steamed east hull starboard

The "steamed east" one doesnt appear to have enough usages at all to be useful. "Her sails/hull/starboard" all more common than their "it" counterparts. Another point of interest, usage of "she/her" appears to have hit a low point in the 1980s and 90s, but has been n steadily increasing since (as has it; the gap is certainly more narrow than it was 100 years ago, but all y'all's claims of minority usage appear to be..mistaken. Credit goes to Blueboar for noticing this. 2600:1702:4960:1DE0:6451:588A:E890:CE87 (talk) 01:21, 8 March 2022 (UTC)

Of course ngrams that mention archaic modes of propulsion (steam, sails) are going to favor archaic pronouns. its/her gross tonnage shows "she" has been on a steady decline since 1900. --Ahecht (TALK
PAGE
) 20:03, 8 March 2022 (UTC)
It also shows that "she" is still in common use - in 2019, it was used twice as much as "it". BilledMammal (talk) 04:58, 10 March 2022 (UTC)
The ngram I posted shows that in in 2019 "its" was about 1% more common. --Ahecht (TALK
PAGE
) 14:01, 10 March 2022 (UTC)
One possible explanation for this phenomenon is that "its" is harder to say than "her" and has an irregular spelling, and (at least for me as a native English speaker who grew up in Ireland in the 1980s and received a state education) it "feels weird" because normally people own things and inanimate objects don't, so ngrams that focus on the possessive article/pronoun/adjective are going to give results that are artificially tilted in favour of "her" over "its" because some writers may be inclined to use "her" in the possessive but "it" in other places. But I think we're all in agreement that "its hull" is not grammatically wrong/unacceptable, aren't we? This is a little more telling: "she left port" used to be overwhelmingly more common in the latter half of the 19th century, but "it left port" overtook it for the first time as early as 1947 and has seemingly been the consistent preferred choice since the early 1980s. Assuming most Wikipedia editors were college-age or younger when Wikipedia started, most Wikipedia editors were born after the early 1980s. Hijiri 88 (やや) 01:19, 11 March 2022 (UTC)
Without evidence I would seriously doubt that assumption. Without numbers "most" is unjustifiable and you'll find there are plenty of editors born before 1960. Martin of Sheffield (talk) 08:23, 11 March 2022 (UTC)
With smoothing off, "her" was used twice as "it" in 2019. In 2018, the opposite was true - all it tells us is that both forms are still in active use. BilledMammal (talk) 23:54, 14 March 2022 (UTC)
...normally people own things and inanimate objects don't... all boats registered with the US Coast Guard, and most which are not, are named and as that name (along with hailing port) are unique, I consider that "ownership". Also, that boats are named, usually with affection, I think goes a long way towards sailors considering them gendered. Le Marteau (talk) 20:45, 30 March 2022 (UTC)

There are lies, damned lies, and ngrams. Phil Bridger (talk) 08:58, 12 March 2022 (UTC)

You might be misinterpreting the "hull" example. If you click the link for "her hull" below the graph for the period 1970 – 2019 in the top row of links and examine the top ten Books results, four of them are false positives. Here are snippets:
  • ...Gilman worked through topics in her Hull-House lectures...
  • ...frustrated with attempts to balance her Hull House duties with teaching
  • ...ideals that had grown in her mind during her Hull-House days...
  • ...Addams drew on her Hull House...
Examining top ten "its hull" results for a similar period shows no false positives in the top ten. The graph shows "her hull" ahead of "its hull" for the period 1970 – 2019, but not by double, and if you remove 40% of the total from the "her hull" curve that would put it behind "its hull" by about 15%, probably too close to be significant, but no clear result in any case. Mathglot (talk) 07:55, 13 March 2022 (UTC)

@Wugapodes: there's a lot of misunderstanding about the differences between the google books query interface, and the google ngrams query interface which searches the google books database. Congrats on being aware of summation and division, which works in ngrams, but unfortunately logical operators do not. Your "ship and its" clause, for example, searches literally for the exact three word expression ship and its, with and as the second word of the trigram. (You can confirm this by consulting the ngrams doc, or more directly by clicking "1984 – 2000" in the top row below the graph, and checking the bolded terms in the result snippets.) Bottom line: your ngrams query, I'm afraid, is invalid and the resulting graph meaningless. I don't want to belabor this discussion on how to find the results you want, but we can take it up on your Talk page if you wish, or perhaps better, at some Wikipedia project page that discusses search best practices, if there is one. As a quick-start, use Books search, not ngrams, and the NEAR operator, not AND. Ping me from somewhere if you want to take this up further. Mathglot (talk) 04:49, 13 March 2022 (UTC) moved here from Survey section; by Mathglot (talk) 08:01, 13 March 2022 (UTC)

@Mathglot Yes, I've read the documentation before. The trigram was intentional. The problem with investigating pronouns in corpora is that their antecedents are not necessarily local or linearly ordered (see Binding (linguistics)). There's no guarantee that a pronoun near the word "ship" actually refers to the ship unless our query incorporates a syntactic relationship between the ship and the pronoun. The choice of "ship and <pronoun>" minimizes confounds introduced by non-local binding by using a syntactic construction (noun phrase conjunction) which ensures that the pronoun actually refers to the ship and not some other object or person in the context. Wug·a·po·des 20:31, 13 March 2022 (UTC)
User:Wugapodes, I'd wondered if that was perhaps your intention, but assumed not, because of the false positives, and because of the possible bias inherent in the query choice. But if you want to keep the 'and' construction, then you could consider a top-10 pronouns query to see if that shows anything useful. But this is getting far afield; last word is yours if you want it, then we should carry on elsewhere. Cheers, Mathglot (talk) 04:44, 14 March 2022 (UTC)

Looking into "its hull" and "her hull", it appears that "her" continues to be the preferred form. This doesn't appear to be due to false postives; by using wildcards, we can see what contributed to this result; the most common continuations for both are "and" and "was", and looking at how "its/her hull was/and" are used, we see that all the results appear to reflect naval use - "and" and "was". BilledMammal (talk) 00:13, 15 March 2022 (UTC)

In my opinion, this issue wont be resolved until we determine whether using "She" for ships is considered standard English, or just a long on-going tradition. If its an ongoing tradition, then it doesn't matter how many old sources use "She", its not based on standard English and is based on bias to uphold tradition. This problem really only happens with English ships. Most asian ships aren't labeled as "She". It can be proven that the ship using female pronouns can be very confusing when it is not upheld in other speaking languages. Especially because by changing the pronoun to it, it doesn't lose any accuracy and makes the article easier to read. it also has a less bias tone. We aren't mariners or military based website. the writing should fit with everyday people. This isn't about rihting wrongs. This is just about giving the most neutral tone we can give in wikipedia imho.Blue Pumpkin Pie (talk) 16:33, 15 March 2022 (UTC)

There is no consensus on what standard English is. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:47, 15 March 2022 (UTC)
But she's a beautiful language, ain't she. Martinevans123 (talk) 23:38, 16 March 2022 (UTC)

Style guides

Perhaps a table of what various style guides say would be of use to put it in perspective. For the current federal Canadian style guide, it's very clear to avoid using gender for ships (hurricanes, etc.). I've got the 1980s version, and the current G&M somewhere if that's of interest. Perhaps, like spelling, the gender use should be country-specific? Nfitz (talk) 20:33, 8 March 2022 (UTC)

I doubt if it's country-specific, at least as far as the major fault line of American vs. British is concerned. The use of "she" is certainly archaic/jargon/marked/poetic in British English, and others have confirmed that it is in American English. Phil Bridger (talk) 20:47, 8 March 2022 (UTC)
The Times style guide very emphatically sticks to "she" and "her" for ships and boats. ThoughtIdRetired (talk) 23:09, 9 March 2022 (UTC)
And yet Times journalists don't seem to have any problem using "it" (It sank about 18km off the Old Head of Kinsale and 1,201 people died.[9] It was the first British warship sunk by German forces[10])? (For the record, I don't think the fact that other Times articles say things like If she had not encountered the German U-boat U-20, this would have been her 202nd transatlantic crossing.[11] -- or used to say them until around five years ago? -- supports the claim that The Times itself "very emphatically sticks to 'she' and 'her' for ships and boats", and the fact that the style guide hasn't been updated to reflect the paper's actual current practice seems pretty irrelevant for our purposes.) Hijiri 88 (やや) 01:30, 11 March 2022 (UTC)
For global news agencies whose work is widely republished by other news sources:
For governments:
I started going through English items in the Newspaper of record list, but got to "Hong Kong" before I gave up. --Ahecht (TALK
PAGE
) 16:01, 10 March 2022 (UTC)

One can only hope that "it" will be the final change, to the ship descriptions. GoodDay (talk) 23:23, 10 March 2022 (UTC)

Return to Style Guides

(after hi-jack by ngram enthusiasts)

By happenchance a few inches down is an interesting link: Why Writers Fight Style Guides. It shows a clear spectrum, with Chicago and academics at the "it-max" end, nowhere near ordinary English usage, and newpapers more in tune with their readers/journalists. This is not directly transferable to ships of course, but illuminating none the less. Davidships (talk) 12:56, 13 March 2022 (UTC)

When it came to official directives, things were a little less clear-cut. Plenty of style gurus, from the Chicago Manual to the American Psychological Society, forbid the use of humanoid pronouns to refer to animals.....Most newspapers afford animals personal pronouns as long as they’ve already got another human accoutrement, like a name or a gender designation.

Requesting closure

Someone (who isn't me) should close this discussion. Though I think it's pretty evident that there's no consensus again. -- RockstoneSend me a message! 07:18, 20 March 2022 (UTC)

@Rockstone35: It's still 16 days (and some hours) before Legobot removes the ((rfc)) tag at 17:01, 6 April 2022 (UTC) and delists the RfC. But if you really think it should be closed early, it would probably be best to formally request closure at WP:ANRFC. See also WP:RFCEND. --Redrose64 🌹 (talk) 21:32, 20 March 2022 (UTC)
Just let it run its course. Who knows what may happen? Early closure will just result in more gnashing of teeth and tearing out of hair. EEng 22:29, 20 March 2022 (UTC)

Opening a can of worms is always a bad idea. The status quo is almost - I emphasise almost - invariably better. T A Francis (talk) 07:27, 23 March 2022 (UTC)

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

Compound with parenthesis

I came across the following sentence in the JPEG 2000 article: “JPEG 2000 is a discrete wavelet transform (DWT) based compression standard.” How can it be improved?

  1. JPEG 2000 is a DWT-based compression standard.
  2. JPEG 2000 is a discrete wavelet transform (DWT)-based compression standard.
  3. JPEG 2000 is a discrete wavelet transform  (DWT)–based compression standard.
  4. JPEG 2000 is a discrete wavelet transform–based compression standard.
  5. Leave as is.
  6. Rewrite.

Fezzy1347Let's chat 20:29, 16 April 2022 (UTC)

Definitely not #1; piping the DCT article to DWT is an WP:EASTEREGG, and doesn't seem to be correct, as the article says that the intent was to supersede the DCT. I'd probably rewrite. Maybe something like
JPEG 2000 is a compression standard based on a discrete wavelet transform (DWT).
How's that? --Trovatore (talk) 20:43, 16 April 2022 (UTC)
I mixed up DWT and DCT when I was typing, since there are two such sentences in the article . Oh yeah, that 's fine. I'm going to use your rewrite. Thank you.
Fezzy1347Let's chat 21:27, 16 April 2022 (UTC)
That's the construction I would have advised as well.  — SMcCandlish ¢ 😼  00:47, 4 May 2022 (UTC)
When in doubt, rewrite. Both the "(DWT)-based" and "(DWT)–based" texts look awful to me, but either of the others could work if the abbreviation could be explained elsewhere. SchreiberBike | ⌨  22:17, 16 April 2022 (UTC)
Per SchreiberBike, none of the above work as well as "JPEG 2000 is based on the discrete wavelet transform (DWT) compression standard." However, this is entirely irrelevant in this case, because the article in question never again uses DWT as an abbreviation. There's no need to introduce an abbreviation you have no use for using later in the article. I would simply say "JPEG 2000 is based on the discrete wavelet transform compression standard." --Jayron32 18:07, 18 April 2022 (UTC)
Dammit, you found a way to resolve the question definitively and without violence. Can't we just pretend that DWT is used later in the article, so we can keep arguing? EEng 12:40, 19 April 2022 (UTC)
It's fine to remove DWT if it's not used again, but just to appease EEng's need for conflict, I'll point out that the discrete wavelet transform is not in itself a compression standard, so Jayron's text doesn't quite work. You could use my first suggestion but remove the (DWT) part. --Trovatore (talk) 18:07, 19 April 2022 (UTC)
That's the spirit! EEng 19:43, 19 April 2022 (UTC)
Sorry, I don't follow... If something is "blah-based" then certainly there is no semantic difference between that and "based on blah". If not, then it wasn't correct before either. --Jayron32 15:31, 20 April 2022 (UTC)
JPEG 2000 is a compression standard. That compression standard is based on a particular discrete wavelet transform. Do you see anything wrong with my suggestion from 20:43, 16 April 2022 (UTC), excepting the unnecessary (DWT), which I agreed could be removed? --Trovatore (talk) 18:06, 20 April 2022 (UTC)
No, not really. I was just playing along with EEng's desire to be an agent of chaos. Perhaps my sarcasm was a bit too subtle. Carry on, please. --Jayron32 18:08, 20 April 2022 (UTC)
What a sense of power it gives me to know that I command this vast army ready to do my bidding. EEng 00:08, 28 April 2022 (UTC)

The Kashmir Files lede

There is a RFC concerning the lede for a recently released film on Kashmir wherein there is a dispute about conformance to MOS. Comments are welcome. TrangaBellam (talk) 07:55, 20 May 2022 (UTC)

Feedback request

Editors are invited to comment on the article "Sacred Cod"'s use of style at Wikipedia:Good article reassessment/Sacred Cod/1. ɱ (talk) 00:19, 28 April 2022 (UTC)

Greek transliteration

Sorry if this has been discussed before, but I wonder if we need a policy on ancient Greek transliteration? There are three schools of thought on the matter; latinization, romanization and straight transcription. For example Ἀχιλλεύς could be treated as Achilles, Achilleus or Akhilleus. No less an authority than the JACT course (essentially Mother's knee) has this to say: "More recently it has been fashionable to keep to a spelling that is closer to the original Greek, but the difficulty with this practice is that some words and names, in particular, have become so much part of our English heritage that they look strange and unfamiliar in their ‘Greek’ form. E.g. we all recognise ‘Achilles’, but ‘Akhilleus’ comes as a shock. Editors therefore have to make a decision whether to be consistently ‘Latin’ or consistently ‘Greek’, or whether to keep the familiar words in their ‘Latin’ form while treating the less familiar words in a ‘Greek’ way. The latter course has been followed in this book." My own prior would be latinizations are "colonialist" and direct transcription is to be preferred. In Wikipedia's case there is no confusion when you can link to the relevant article. The only special cases might be familiar names, i.e. Plato rather than Platon. Thoughts?Twospoonfuls (εἰπέ) 10:37, 22 April 2022 (UTC)

If people are not edit warring, I would say use whichever variant would be most recognizable (and least jarring) to our readers. Blueboar (talk) 11:09, 22 April 2022 (UTC)
Agree with Blueboar. Remember WP:RF "If you find yourself defending something as it is the "academic standard" or because it is what you as an editor want, you know you're going wrong! Write for our readers, not for academics and not for yourself". Later in the same article: "Another group which might make a good theoretical audience are high school and college students". So where there is an English language name (Achilles, Plato) use that in preference to a Greek transcription. However ensure that the Greek transcription is mentioned, after all we seek to inform. Martin of Sheffield (talk) 11:44, 22 April 2022 (UTC)
Is anyone edit warring over this? Not that I know of. I can start one if you like though! But seriously, the problem with latinization, which must be the most familiar treatment of Greek words since it's the 19th century standard, is twofold. 1) the familiarity fallacy: jarring is good if it distances us from comforting, and sometimes false, assumptions. And the past is a foreign, uncomfortable place. 2) It is assuming Latin is the standard and Greek is subordinate, the very definition of a colonialist assumption. Weren't we meant to be doing something about that? And P.S. aren't featured articles supposed to be of interest to the specialist, they can't be that and written to a high school standard. Twospoonfuls (εἰπέ) 12:05, 22 April 2022 (UTC)
Wikipedia adheres to the 19th century standard. Looking at the exemplary list of words given by Antony Andrewes in his preface to The Greek Tyrants, I see that even words he considered ripe for a closer-to-Greek spelling are given the older latinizations first at their respective articles (e.g. hyperakrioi and Rhaikelos, the latter not even having a "non-latinized" redirect). Further, I don't believe that discombobulation is a virtue; and the number of Latin terms derived from ancient Greek demonstrates the importance and sophistication of the latter language, not the reverse. Dhtwiki (talk) 01:53, 23 April 2022 (UTC)
"Don't make me think" is definitely not a virtue. And isn't "the number of Latin terms derived from ancient Greek demonstrates the importance and sophistication of the latter language, not the reverse" what we call cultural appropriation now? It is possible to both profess admiration and be condescending and belittling. Twospoonfuls (εἰπέ) 09:40, 23 April 2022 (UTC)
Wanting to adhere to conventional forms of expression to facilitate communication isn't a matter of "Don't make me think". Otherwise, why do we have a manual of style? And, not all borrowings are *inappropriate* cultural appropriation. It's hard to think of the Romans as egregiously awful colonizers, when one of their most notable panegyrists was Greek. Dhtwiki (talk) 06:12, 24 April 2022 (UTC)
We should not be aiming for Latin or Greek names, but English ones where they exist. I'm pretty sure that nearly all English-language sources use Achilles and Plato, rather than other forms, so that is what we should use, just as we refer to Athens, Rome etc. by their English names. Less well-known people and places from antiquity are more often referred to in academic sources than in general-interest ones, so we should follow current academic standards. Phil Bridger (talk) 12:44, 22 April 2022 (UTC)
JACT has it right: "keep the familiar words in their 'Latin' form while treating the less familiar words in a 'Greek' way. [This] course has been followed in this book." And should be followed here, consistent with WP:COMMONNAME. Similarly, we have an article at Munich and a redirect at München. For names that are not habitually spelled a certain way ("Achilles", etc.) in English, then default to a closer transliteration of Greek, and bypass the Latinization.  — SMcCandlish ¢ 😼  00:42, 4 May 2022 (UTC)

Lists of books about a subject in the article

Is it normally acceptable for an article about a topic to have a list of external references about the topic? If so what guidelines apply to inclusion, exclusion, length etc? I'm asking in context of the topics Conservatism and Liberalism. Both articles contain extensive "further reading" lists [17], [18]. What policies apply here? Is there a way to decide if a book/article is acceptable or not? My feeling is such lists should be discouraged/used sparingly. If the source isn't used as a citation then it seems it may not be relevant enough to include. Also, such lists seem like they may be abused as a place to promote inappropriate works. By that I mean works that are of poor quality, not widely accepted, biased in their views etc. Thanks. Springee (talk) 14:22, 19 April 2022 (UTC)

See MOS:FURTHER. I agree that such sections do have the annoying tendency to be abused to promote marginal works of scholarship or POVs. IMO, in an ideal world, this content would actually be based on secondary bibliographic coverage of the topic. Colin M (talk) 14:35, 19 April 2022 (UTC)
Yes, they also tend to be out of date, or all in a foreign language, especially German. The German wp tends to have a long "bibliography" section, and this often gets translated over. Johnbod (talk) 14:58, 19 April 2022 (UTC)
That seems reasonable but it would perhaps be helpful to know what is a reasonable number (5, 10, 20, more?). Also, is there any criteria for what is a good "further read"? Imagine if an editor added a book that promoted racism to a list of further reading about racism. Many editors may totally miss the nature of the book being added. Springee (talk) 17:12, 19 April 2022 (UTC)
WP:ELYES. --Redrose64 🌹 (talk) 15:36, 19 April 2022 (UTC)
Looking at that one I don't see that a generalized list of "further reading" sources would be allowed but I'm also not certain it applies here. That link says things like an organization's home page can be linked, a link to a site with a legally accessible copy of a work in question is OK and links to sources that have usable but copyrighted material is OK. I'm not sure any apply to a further reading list since such a list isn't required to have any external links. Springee (talk) 17:12, 19 April 2022 (UTC)
Indeed. On big topics such as those you mention, I think up to 10 could be ok, but many editors trim to c. 5 or 6. I'd think 20 is the absolute maximum. Johnbod (talk) 17:20, 19 April 2022 (UTC)
Extensive bibliographies on a per-article basis is something the old Britannica had, and may still have; but those were classified, annotated, and didn't include scholarly monographs. There are printed books that themselves contain extensive bibliographies (e.g. each volume in the Oxford History of the United States, as far as I know). Those should be considered as suitable for inclusion before others. There shouldn't be extensive additions by people who are otherwise uninvolved with the article. Various wikiprojects might take on maintaining extensive bibliographies that would be inappropriate for individual articles. There might be websites, to be pointed to under "External links", where well curated specialist bibliographies are maintained, with convenient access via links, which might be preferable to extensive listings here. Dhtwiki (talk) 22:49, 21 April 2022 (UTC)
This is really a matter for discussion and consensus building on an article-by-article basis. Regardless, it's not really an MoS matter or question. What MoS has to say is more about layout the sections. If we need a content guideline better addressing "Further reading" lists, then that should be taken up at WT:External links.  — SMcCandlish ¢ 😼  00:44, 4 May 2022 (UTC)

MOS:ERA on multiple related articles

Background:

MOS:ERA is written from the perspective of a single article. But this question is about how its principles might apply to a set of closely related articles.

The discussion at Talk:Book of Daniel would, I think, equally apply to all the books of the HB/OT, of which there are around 40. (The exact count varies, depending on the way they are counted, and, if the HB/OT-era Apocrypha is taken into account, what is included.) In response to a suggestion that we view the principle as applying to all books in the HB/OT collection, one of the comments there is "but that is not how WP:ERA works". Technically, and viewed literally, that single-article comment is probably correct. But it also seems that this collection would illustrate the usefulness of a MoS clause that acknowledged such a collection of articles as a single set of articles, and that applying MOS:ERA to the overall set can be a valid consideration.

Courtesy ping: @StAnselm:; @Achar Sva:

Feline Hymnic (talk) 14:54, 2 May 2022 (UTC)

It would be way more than 40. Logically, it would also include Hebrew Bible people and things. Hundreds. StAnselm (talk) 15:02, 2 May 2022 (UTC)
WP:ERA says that we ARE allowed to change styles, we just need discussion and consensus before we do so. This would apply to groups of articles as well as individual articles. Blueboar (talk) 15:12, 2 May 2022 (UTC)
The points raised at Talk:Book of Daniel are variations on Christian articles must use BC/AD and non-Christian articles must not use BC/AD. This is the wrong basis to choose from. The basis should be what the reader understands. For the majority of English speaking countries this would be BC/AD. BCE/CE is most used by academics - including Christian academics.  Stepho  talk  15:22, 2 May 2022 (UTC)
This discussion here at MOS:ERA isn't about particular outcomes of a particular single-article case. It is, rather, about the principles of grouping, so that multiple, closely-related articles can have consistent criteria, treatment and outcomes, as if it were, in this ERA context, one super-article. Feline Hymnic (talk) 16:04, 2 May 2022 (UTC)
And the answer to that question is that they CAN have consistent era styles, but they are NOT REQUIRED to have consistent styles. Whether a specific group of articles should have a consistent era style isn’t something we should mandate here at the MOS. You need to hold a centralized discussion (or an RFC) to determine what the consensus of the community is. Blueboar (talk) 19:15, 2 May 2022 (UTC)
Yeah, there is a part of me that wants all related articles to be rigorously and strictly in the same format in all ways. But pragmatically I know that this has little actual benefit, will be hard to enforce and will be the source of much argument finding the "one true way". We certainly don't need yet another reason for a religious war to break out. Best to just let each article do its own thing for ERA.  Stepho  talk  23:08, 2 May 2022 (UTC)
There's also the fact that a particular article may be part of multiple groups that may have conflicting relations to era notation. --User:Khajidha (talk) (contributions) 11:46, 3 May 2022 (UTC)
If A is a related article to B and B is a related article to C, would that mean that A must then also have the same style as C? If so then by defining "related" loosely enough one could then in a backdoor way require most or al of the encyclopedia to use a single era even if each article is only related to a small number of others. So to prevent conglomeration of multiple related groups into superclusters of far too many articles, I this idea would only be workable if the notation of "related" could be defined in such a way as to limit each article to being in only a single related group, of a constrained size, with these limits baked into any proposal. That seems totally unrealistic to me, to the point where I don't think it is possible to do this at all. —David Eppstein (talk) 16:02, 3 May 2022 (UTC)
The very article that started this is proof that it isn't realistic. As already stated, there are people classifying it as a Christian related article which must use BC and other people classifying it as a non-Christian (specifically, Jewish) article that must use BCE. --User:Khajidha (talk) (contributions) 17:00, 3 May 2022 (UTC)
Which goes back to what I said before about religion should not be the basis of choosing BC/AD or BCE/CE. Being able to group them is merely widening the scope, so that a victory (for either side) in one article can then be used to bludgeon the edit war into a wider group. And as said above, if articles form overlapping groups then this will be used as an excuse to endlessly flip-flop across multiple articles (eg book of Daniel is group with Jewish articles, so it must not be BC, but it is also grouped with the Christian bible, so it must be BC). Therefore: 1. let each article stand alone, 2. do not use religion for choosing the era style and 3. use WP:RETAIN, WP:DATERETAIN, etc to avoid changing the existing style.  Stepho  talk  22:00, 3 May 2022 (UTC)
Religion is ultimately the only reason this debate exists, period. There is no way around that fact.  — SMcCandlish ¢ 😼  00:32, 4 May 2022 (UTC)
Well unless you want to adopt 2022 = 2775 AUC, then every system that there is is based one way or another on religion. Assuming that we don't want to adopt this year as 5783 AM or 1443 AH, then you are left with two alternatives both based on a miscalculated assumed date of Jesus' birth. Call it "Before Christian Era" or "Before Christ", they both mean the same. Likewise "AD" which most people can't really translate or "Christian Era" are really the same. It's just a pious(!) attempt to grab a moral high ground and appear superior to the masses in a few scientific journals. I'd suggest "BP", but what is special about AD 1950 CE? and how do we date times after that? Martin of Sheffield (talk) 13:52, 4 May 2022 (UTC)
Except that "CE" is "Common Era", not "Christian Era". --User:Khajidha (talk) (contributions) 13:57, 4 May 2022 (UTC)
Agree with Khajidha-- as far as I am aware, "CE" is usually now said to stand for "Common Era," so as to obscure the religious connection, even if doing little to actually separate it. Still obviously based on religion, as you say, but I support "CE" as at least a tiny step in the right direction. Cheers. Dumuzid (talk) 13:59, 4 May 2022 (UTC)
Eh? Since when? So now we have three ways of expressing the same thing! Whilst we are at it, what defines this "common"? Martin of Sheffield (talk)
See Common era. I'm rather partial to Era Vulgaris; too bad that one didn't catch on...
—Trappist the monk (talk) 14:25, 4 May 2022 (UTC)
Since about 1708. --Ahecht (TALK
PAGE
) 14:37, 4 May 2022 (UTC)
You are the only person I've ever encountered who actually used "CE" = "Christian Era". I've come across it as an alternative listed as an aside (like ""CE", for "Common Era" (or "Christian Era")"), but even that has been rare. It has always been presented to me as "CE = Common Era" since I first learned of it back in the 1990s. So, no, we don't have three ways of expressing the same thing. And the "common" means "using the year numbers commonly used in international contexts". --User:Khajidha (talk) (contributions) 15:57, 4 May 2022 (UTC)
To me what it means is that we're still using a dating scheme based on the Christian religion but we're pretending that Christians are the only people important enough to be considered common and everyone else doesn't count. It's not really more or less offensive than AD, which spells out its Christian origin more directly and honestly. So I'm not convinced that Dumazid's "tiny step in the right direction" is actually in the right direction. But all that doesn't really matter; the date system is what we have and it makes no sense to try to go back to AUC or Unix dates or whatever. As long as the general consensus is that CE is the secular alternative to AD, we should generally prefer it in articles that are not specifically Christian in content (and I don't see why we can't use it in those either). —David Eppstein (talk) 16:07, 4 May 2022 (UTC)
This is a perfectly fair take. I do feel the need to say that "common" to me has always meant that by dint of historical accident, the Christian dating system spread well beyond its original confines and was 'common' in that it was used by various communities. Also, I prefer this since "A.D." is specifically predicated upon the birth of Jesus, which most would now agree did not happen in 1 A.D.--and "CE" to me is an implicit admission that "we all just agree to this point in time." As ever, reasonable minds can differ, especially upon picayune matters! Cheers all. Dumuzid (talk) 16:14, 4 May 2022 (UTC)
To David Eppstein: the reason we should not be using BCE/CE is that this era style is largely unknown to the general public i.e. our readers. Sweet6970 (talk)
[Citation needed]. —David Eppstein (talk) 16:41, 4 May 2022 (UTC)

See Common Era – in particular, the mentions of the National Trust, the BBC and the Guardian. Sweet6970 (talk) 17:02, 4 May 2022 (UTC)

And, from that article: "In 2013, the Canadian Museum of Civilization (now the Canadian Museum of History) in Gatineau (opposite Ottawa), which had previously switched to BCE/CE, decided to change back to BC/AD in material intended for the public while retaining BCE/CE in academic content.[1] If you have a watchlist with a lot of history, archaeology or art articles, you do see puzzled people asking what BCE is - this is especially the case on Indian-related pages, as only very expensively-educated Indians encounter BCE/CE, or often anyway. WP:ERA very clearly does NOT "generally prefer it [CE] in articles that are not specifically Christian in content", and if you think it should you should propose that there, & see how that goes! Johnbod (talk) 17:32, 4 May 2022 (UTC)
  1. ^ "Museum of Civilization putting the 'Christ' back in history as BC and AD return", by Sean Kilpatrick/The Canadian Press, National Post, 27 February 2013

Split out the "Gender Identity" subsubsection from the "Identity" subsection

Pretty much the title. Right now MOS:ID is a level 2 heading, with the "gender identity" subsection being underneath it as a level 3 heading. I believe "gender identity" should be level 2 on equal footing with "identity". The status quo would seem logical as they're both types of identity, but they differ in a few key aspects.

I was wondering what people thought of this proposed change and if we can gain consensus to make it. Chess (talk) (please use ((reply to|Chess)) on reply) 22:41, 24 March 2022 (UTC)

The section structure is there to make the maze of twisty passages that is our MOS more navigable. It's not a measure of how important this or that is, and I strongly object to adding such a concept to the already-large pile of unimportant stuff we already have available to fuel endless, pointless argument. EEng 04:46, 25 March 2022 (UTC)
I oppose for much the same reason. This is an instruction manual, and should be organized by topic, not importance. Magnolia677 (talk) 10:59, 25 March 2022 (UTC)
I agree with EEng and Magnolia, for some similar reasons, and would also add that if people believe that we should treat people with courtesy and decency because of other identity-related issues like race, ethnicity, sexuality, language, place of birth, etc; then that's not exactly a bad thing. The standards we use for gender identity are not exactly bad if we also apply them to other identity issues. --Jayron32 11:54, 25 March 2022 (UTC)
Well...I do suppose any kind of self-identification for which absolute acceptance is mandated is susceptible to abuse by players acting in bad faith (including gender), and one could possibly argue that the more types of identity are treated in that fashion, the greater potential for abuse is created. (e.g., say, a white person claiming black racial identity in attempt to take advantage of programs intended to support disadvantaged peoples, when that person actually has no such disadvantage). That is not my position, by the way..I agree with what you said entirely. I also think that if we were to start enshrining in PAGs which social categories are more important than others, that that sets a potentially very dangerous precedent..because then we are basically deciding which groups of people are more important than which other groups of people. (And "gender identity" is already increasingly starting to be seen by many gays and lesbians as an existential threat to their own civil and human rights; whether there's base to those concerns is irrelevant, the project has no business making rulings at a project level over which groups' concerns and interests are more legitimate or important than others). 2600:1702:4960:1DE0:1BB:1B9C:92AB:34C7 (talk) 23:14, 25 March 2022 (UTC)
@Jayron32: I recently participated in an ANI thread about someone who said we should extend the standards for gender identity to royal pretenders and got blocked for it. If we are to say that this identity standard should be extended, we should consider delineating the boundaries because the community likely won't allow anyone to self-identify as a monarch, will probably have a murkier time with ethnicity, and would likely allow people to self identify their sexuality/etc. Chess (talk) (please use ((reply to|Chess)) on reply) 22:43, 28 March 2022 (UTC)
Oh, I never said we should extend the definition to include people who use the identity issue to mock those who are legitimately under societal assault for their identity issues; people that mock others by saying stupid shit like "I identify as a monarch" are not extended the grace that is given to those that are actually discriminated against because they are of a different race, sexuality, gender identity, ethnicity, language group, etc. You know that's bullshit, and so did the person who made that argument. What I am saying is that people from discriminated against groups should be extended a baseline level of respect and dignity, and that perhaps raising the bar of dignity is not something we should argue against. --Jayron32 11:01, 29 March 2022 (UTC)
But what if they say they identify as a queen? Then what?[FBDB] EEng 21:39, 29 March 2022 (UTC)
I think I literally just answered that. We extend grace and courtesy to people who are parts of groups or have traits that are currently being discriminated against by society. If a person is transgender, we extend to them due courtesy by recognizing their status in the appropriate manner. A person who mocks transgender people by saying "I identify as a <insert ridiculous thing here>" are no so afforded that courtesy. They're just being assholes, and saying that a person who does that is equivalent to someone who is genuinely transgender is intellectually dishonest, and just plain rude. --Jayron32 18:43, 30 March 2022 (UTC)
Think, Jayron, think. It's me. EEng 20:08, 30 March 2022 (UTC)
There is a difference between "is foo" and "identifies as foo". We should be respectful of people's beliefs about their identities, even when they aren't persecuted, but we should also be respectful of those who don't share those beliefs. That's not just gender, it's also, e.g., geography, religion. Issues like male athletes who have hormone treatment and join female teams need to be addressed in a courteous, neutral and respectful manner. My inclination would be to use the term identifies as foo for anything likely to be controversial. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:37, 30 March 2022 (UTC)
We also want to be careful about the derogatory or pejorative use of "identifies as" rather than just "is". The former is often used in a way that casts doubt on the earnestness of the person in question, as though it is some kind of arbitrary choice, rather than being a core element of their selves. Terminology that highlights (falsely) the identity as a choice is wrong, also is terminology that treats people's identity as non-normative; that there is an expectation that a person is a cis-hetero-white-male-protestant or whatever, and that all else is variant from that normative state. We should avoid language that treats people that are not that as somehow lesser, deviant, or outside of the norm. --Jayron32 13:33, 31 March 2022 (UTC)
Exactly. The opinions of those who refuse to accept facts because they don't fit their prejudicial programming don't matter. A trans identity is not a matter of opinion, it's a fact that must be stated plainly. And, absolutely right that white cis hetero male is not some sort of default setting for humanity. We need to avoid any such implication. oknazevad (talk) 21:05, 31 March 2022 (UTC)
You are correct to a certain extent, but wrt gender identity I don't think it's always possible to avoid "identifies as" type language, as...well, that's what an identity is, how a person identifies. Some want to redefine the gender categories to make them completely based on a person's identity and completely independent of biological sex. Many women (and gays) have strong objection to that, because females, regardless of their gender identity, are also an oppressed class of people; furthermore, (biological) women face certain adversities that are entirely due to biological reality, not culture or society, and those will not change until we evolve into another species. Those adversity no male, including no trans woman, will ever be subject to. E.g., no trans woman will ever have to experience having an unwanted pregnancy imposed on her forcefully via rape, possibly being made to carry it to term against her will, possibly dying in the process. Many women feel that shared experiences such as those and others are what distinguishes their sex from the male sex. This is not to say that individuals should not be respected, but that redefining 'woman' to mean something other than the type of human that is subjected to those realities erases their existence as a group. Likewise, to many female homosexuals, when they are told that "lesbian" also applies to heterosexual males that identify as lesbians, and that if they don't submit to penile-vaginal intercoarse with those individuals that they are 'TERFs', that feels a lot like compulsory heterosexuality to them. (See the article lesbian erasure for more on this subject). So, point being, all things within reason. We should write respectfully about all peoples, but it would (in my opinion) be wrong for us to declare that, e.g., gender identity is of higher priority than discrimination due to biological sex, or that a gay person's exclusive oppositesame-sex attraction does not have to be respected when heterosexual members of the opposite sex who are trans. (Yes, the trans person's identity should be respected, but their identity doesn't entitle them to compel a homosexual person to engage in sexual activity that is contra to their orientation, and we should not be writing article text that suggests it does). 2600:1702:4960:1DE0:4D69:F0F8:A0CA:5BC (talk) 07:46, 2 April 2022 (UTC)

Nobody writes article text doing what that last bolded line states - that is a complete red herring. And even apart from that obvious point, people being told that if they don't submit to penile-vaginal intercoarse with those individuals that they are 'TERFs' is one of the major urban legends of the internet age - or perhaps moral panic is the better term. Certainly not a social phenomenon.

Also, I don't know any AFAB people of any gender who interpret pregnancy as a defining element of rape/sexual assault in the way that the IP editor attributes to many women, here. The IP appears to hold FRINGE, "gender critical" views and to be presenting them as mainstream. While this is interesting for future anthropology and all, it isn't really relevant for this Talk page and guidance for writing about gender identity on WP. Newimpartial (talk) 12:32, 2 April 2022 (UTC)

@Jayron32: What about transracial people? We have Rachel Dolezal. Chess (talk) (please use ((reply to|Chess)) on reply) 03:13, 1 April 2022 (UTC)
We're not going to play the "whatabout" game. We're going to treat people with due dignity. That is all. --Jayron32 11:18, 1 April 2022 (UTC)
Singling out one type of identity as more important than others will engender endless debates over relative importance. Like most people, I have multiple identities:
  • Age
  • Avocations
  • Cultural
  • Educational
  • Family
  • Gender
  • Gender orientation
  • Genetic
  • Geographic
    • I was born in Detroit
    • I live in Northern Virginia
  • Linguistic
  • Marital status
  • Religion
  • Vocations
You could make a case for any of these, or some that I didn't list, as being more important than any of the others, and I wouldn't see such debates as being productive. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:57, 27 March 2022 (UTC)
But we already do single out gender identity. It is the only one to have its own subsection (for reasons that are more or less outlined above; it is generally more sensitive and more likely to fall under disputes, which led to more policies existing to govern how we approach it.) I don't think Chess is saying that it is more important in an overarching cosmic sense, but it is more important in terms of how many policies there are to consider when writing articles here that touch on it. --Aquillion (talk) 09:52, 1 April 2022 (UTC)
As far as I can tell, the manual of style is not organized in terms of importance. I do agree that the importance of the gender identity section extends beyond mere stylistic concerns. In my opinion, a better way to communicate that would be to promote it into an actual policy page like WP:BLP instead of merely a guideline page like WP:MOS. PBZE (talk) 23:41, 31 March 2022 (UTC)
Actually, I agree that the destination for most of the GENDERID/DEADNAME guidance ought to be WP:BLP, since it has already a high-level of site-wide consensus (through well-publicized, highly participated processes) and because some of the "enforcement processes" related to the guideline - like removing non-notable deadnames and misgendering in article space - are clearly BLP/WP:3RRBLP actions. But the required RfC looks to me like a lot of work. :) Newimpartial (talk) 12:22, 2 April 2022 (UTC)
Leave it as is. One identity doesn't take precedence over other identities. GoodDay (talk) 14:16, 2 April 2022 (UTC)
Concur with GoodDay. This proposal makes no sense to anyone familiar with sensible document organization, which any serious Wikipedian should be.  — SMcCandlish ¢ 😼  18:26, 4 May 2022 (UTC)

Feedback request on SpaceX Starship

Editors are invited to comment on the article "SpaceX Starship"'s use of date format at Talk:SpaceX_Starship#Request_for_comment_on_date_format. CactiStaccingCrane (talk) 04:27, 18 June 2022 (UTC)

Anything in the MOS about carriage returns?

Cfls recently edited several articles to add carriage returns in the middle of infobox titles. That - formatting text so it works on one editor's particular display - seems like a bad idea. Is there anything in the MOS that specifically addresses this? ElKevbo (talk) 00:54, 5 June 2022 (UTC)

The relevant guideline is MOS:NBSP, which generally recommends preventing line breaks as opposed to forcing them. What work well on one's screen might not be optimal for another's. Readers can be reading from anything from a small phone to a widescreen monitor.—Bagumba (talk) 01:41, 5 June 2022 (UTC)
Dear Wikipedia community members,
I will now issue a specific fact sheet on ElKevbo's allegations.
The United States has one of the best higher education systems in the world. Many states have established their own institutions of higher education, using geographical names as the distinction between branch campuses. For example, the University of Illinois Urbana-Champaign, with the world's top computer science school. The name of this university is very long.
Wikipedia has a very good screen size adjustment mechanism, which can adapt to various computer and mobile phone sizes for easy reading. Meanwhile, in the case of an entry such as University of Illinois Urbana-Champaign, no personal computer's browser in the world can display the name of the school in its entirety on one line at the top of the Wikipedia entry information box. The most common display currently is to display "University of Illinois Urbana-" on the first line and "Champaign" on the second line. Obviously, this is not the way people usually use sentence segmentation.
In daily life, the way people use sentence segmentation is "University of Illinois" and "Urbana-Champaign." This is people's language-using habit. In the second paragraph of the main text of the Wikipedia Manual of Style we can see, "Editors should ... structure articles with consistent, reader-friendly layouts and formatting." Following this principle, I optimized the display of school names above the entry information box for the University of Illinois Urbana-Champaign to match popular perception. Therefore, in this entry, "University of Illinois" is displayed on the first line, and "Urbana-Champaign" is displayed on the second line. This is in line with people's common perception.
The same applies to some of the University of California campuses with longer names, such as University of California, Los Angeles, Santa Barbara, and San Diego. Such typographic optimization is to allow our readers to read our articles better and get information more easily.
ElKevbo states his own personal opinion. This community member argues that the typesetting editing behavior that makes it easier for readers to read the Wikipedia entries for universities with unusually long names should give way to "let the browser do its job." We strongly affirm and acknowledge that Wikipedia's automatic typesetting system is excellent. At the same time, we need to pay attention to the fact that we should give correct line breaks to improve readability when faced with a university name that cannot be read in two words such as Cornell University. We know that in any case, the school names such as University of Illinois Urbana-Champaign cannot be displayed in one line, so we should take the initiative to solve this situation. What I'm stating is by no means a distrust of Wikipedia's automatic typesetting. Instead, I'm trying to make Wikipedia entries better by editing them.
The views expressed by ElKevbo is not acceptable. We should take into account the specific circumstances of each entry, and appropriately present what is described in the circumstances. We respect the Wikipedia Manual of Style as a community guide for all editing.
Thank you, all active members of the Wikipedia community who have contributed greatly to the spread of human knowledge.
This concludes my presentation. Cfls (talk) 05:57, 5 June 2022 (UTC)
Re For example, the University of Illinois Urbana-Champaign, with the world's top computer science school. The name of this university is very long.: The name of this university is not as long as some, like the Vallurupalli Nageswara Rao Vignana Jyothi Institute of Engineering and Technology, Mahachulalongkornrajavidyalaya University, or Ivan Chernyakhovsky National Defense University of Ukraine. But despite its relative brevity, the name we use here for UIUC confuses me. First off, our usual convention for combinations of names of separate entities that are not subordinate to each other, like in this case Urbana and Champaign, is to use an en-dash. Hyphens are for double-barreled names for single places, but there is no single place Urbana-Champaign. So why is it University of Illinois Urbana-Champaign and not University of Illinois Urbana–Champaign? And second, why does its category hierarchy use the alternative form Category:University of Illinois at Urbana–Champaign with the en-dash and with an extra word "at" included? —David Eppstein (talk) 07:11, 5 June 2022 (UTC)
Specific name of this university aside, the original question is more about how to optimally encode names that might not fit on one line for a given reader's screen (the actually page name can be dealt with on that specific page, WP:RM, etc.)—Bagumba (talk) 08:20, 5 June 2022 (UTC)
A general solution per MOS:NBSP would be using ((nowrap)), e.g. ((nowrap|University of California)), Los Angeles, which incidentally shows up fine as one line on my laptop, not to mention a widescreen external monitor. Encode it to give clues on optimal places to place a break, but leave the ultimate decision to the browser on whether a break actually is needed, depending on the screen being used.—Bagumba (talk) 08:13, 5 June 2022 (UTC)
See H:LINEBREAK for ideas about how to do this better. That page recommends against using <br /> in an infobox. Phil Bridger (talk) 08:31, 5 June 2022 (UTC)
Beware that the intent is not to enforce a line break at a particular place but to discourage a line break in another particular place. Perhaps ((Non breaking hyphen)) could work here.  Stepho  talk  08:45, 5 June 2022 (UTC)
@ElKevbo: To your original q., i.e. Is there anything in the MOS that specifically addresses this?, see Wikipedia:Manual of Style/Accessibility#Text, which says Do not insert line breaks within a sentence, since this makes it harder to edit with a screen reader. --Redrose64 🌹 (talk) 20:35, 5 June 2022 (UTC)

Thanks for all of the replies and pointers to helpful guidelines and tools.

@Cfls: What exactly are you trying to do here? It seems clear that simply adding a manual line break/carriage return is not a good idea or in line with our practices and policies. Would one of the ideas suggested here meet your goal(s)? ElKevbo (talk) 20:53, 5 June 2022 (UTC)

I've updated the relevant University of California schools to use ((nowrap)) and not explicitly force a line break, leaving the browser to decide on its own if it is needed.—Bagumba (talk) 07:11, 9 June 2022 (UTC)

That's contradictory. If you used nowrap, then browsers will not decide if it's needed, they will simply not wrap.  — SMcCandlish ¢ 😼  14:11, 9 June 2022 (UTC)
Still left opportunity for break: ((nowrap|University of California,)) ((nowrap|Los Angeles))Bagumba (talk) 19:51, 9 June 2022 (UTC)
This is exactly the right way to approach this. EEng 04:12, 11 June 2022 (UTC)

Whitespace wrapping section headings in the source

Is there a general consciousness on whether section headings should have whitespace after the first == and before the last ==? I realize it's rendered the same either way, with whitespace stripped, but I assume it's better to be consistent throughout the site. Help:Sections shows it with the spaces whenever an example heading is on its own line, but doesn't contain the spaces later in the article when the examples are inside of the paragraphs.

Tl;dr: == Heading 2 == or ==Heading 2==?

ShortTimeNoSeeMessage ⸻ 02:17, 20 June 2022 (UTC)

Back in the day we never had spaces there, but FWIW, since I've seen others doing it, I've become a convert. The spaces make the wikitext noticeably more readable. Usually when I come across non-spaced headings they are in an old article that hasn't been heavily worked on for many years. -- Visviva (talk) 02:20, 20 June 2022 (UTC)
Some people have strong feelings that it should be one way or another. I can't imagine caring that much, so I just leave it as it is. It's like should it be * Text or *Text? I'm happy to let other people have their small victories. SchreiberBike | ⌨  02:44, 20 June 2022 (UTC)

The guidelines are clear (last I looked; can't recall where): Always blank line before heading; optional after, and don't fight over it. I often add a blank line before a paragraph if it's crammed up against stuff like heading+images that make it hard to see the start of a paragraph, but if it's just up against a heading that's not so bad; I prefer a blank line there, but wouldn't add it unless most of the rest of the headings in an article are that way. Dicklyon (talk) 15:55, 20 June 2022 (UTC)

Oh, sorry, I answered the wrong question. Those spaces in headings are generally considered optional and not worth thrashing over. Dicklyon (talk) 15:56, 20 June 2022 (UTC)

On talk pages, the "new section" tab places spaces between the equals signs and the heading. There are WP:SUBSTed templates that create headings without the spaces. But it really doesn't matter whether they're present or not. What must not occur is people editing pages just to add (or remove) those spaces. --Redrose64 🌹 (talk) 19:51, 20 June 2022 (UTC)

Starting sentences with conjunctions

I don’t think it sounds right, or in keeping with Wikipedia’s style, to start sentences with conjunctions, such as “But”, “And” or “So”. In my view, it’s more encyclopaedic to start a sentence with “However” or “Despite this…”. I generally replace the former with the latter whenever I see it on Wikipedia articles. I can’t see anything in the MOS about it - has this subject been discussed before? Any views?—TrottieTrue (talk) 00:23, 30 May 2022 (UTC)

Oh yes. see Wikipedia:Lies Miss Snodgrass told you. Hawkeye7 (discuss) 00:57, 30 May 2022 (UTC)
It still doesn’t sound right to me on Wikipedia - and it doesn’t seem to be the norm, either.—TrottieTrue (talk) 13:37, 30 May 2022 (UTC)
Starting a sentence with a conjunction is "not the norm" in the sense that appropriate uses are rare. But they do exist. Stuff like this calls for application of stylistic judgment, not reflexive removal. EEng 15:58, 30 May 2022 (UTC)
My stylistic judgment is generally that it isn’t in keeping with the tone of Wikipedia’s house style. I seldom come across good quality articles which do this.—TrottieTrue (talk) 08:06, 31 May 2022 (UTC)
Sorry, but asserting a blanket, one-size-fits-all stylistic judgment betrays a lack of stylistic judgment. Like I said, appropriate use cases are rare, but they exist. EEng 21:07, 31 May 2022 (UTC)
Yes, exactly. They are rare, but they exist. In the Featured Articles from the last week, there are several examples of articles using "however" to start a sentence. None of them use "But" to start sentences. In most cases, "however" is preferable to "but" - especially in an encyclopaedia. TrottieTrue (talk) 13:13, 1 June 2022 (UTC)
MOS:EDITORIAL already covers this: "Words to watch: but, despite, however, though, although, furthermore, while ...
More subtly, editorializing can produce implications that are not supported by the sources. When used to link two statements, words such as but, despite, however, and although may imply a relationship where none exists, possibly unduly calling the validity of the first statement into question while giving undue weight to the credibility of the second. Doug Weller talk 12:15, 31 May 2022 (UTC)
But that's irrelevant to the point at hand, which is specifically re starting a sentence with a conjunction. EEng 21:07, 31 May 2022 (UTC)
And whether a conjunction creates an inadequately-sourced implication is independent of whether it is placed at the start or middle of a sentence. —David Eppstein (talk) 22:10, 31 May 2022 (UTC)
And I think that's what I was trying to say. But apparently not very well. However. EEng 03:51, 1 June 2022 (UTC)
I worded my reply badly, but I think the point about the examples was important. Doug Weller talk 06:40, 1 June 2022 (UTC)

Maybe I can help bring this to an end by pointing out that MOS doesn't try to teach universal principles that apply to all formal writing; except in rare cases in which some point has been a chronic source of trouble specifically here at WP, MOS restricts itself to points of WP's house style, that is, points on which formal publications vary. (See WP:MOSBLOAT.) So even if you were to be successful in convincing your fellow editors that it's a general rule of formal writing to never (or seldom) start a sentence with a conjunction, that's not going to be solemnized in MOS anyway.

Nor is any central noticeboard the place to discuss it. Just make changes as part of normal copyediting. But -- warning -- any kind of systematic search-and-destroy mission is likely to lead to tears sooner or later. Bad idea. EEng 01:38, 2 June 2022 (UTC)

I think you’ve misunderstood me. It’s not about rules for all formal writing - it’s about the house style of Wikipedia. I’m certainly not intending a “systematic search-and-destroy mission”. It’s simply something I tend to change as and when I find it, and another user has been edit warring over it on a few occasions when I’ve done so. TrottieTrue (talk) 17:53, 2 June 2022 (UTC)
The trouble is, that if something ends up in MOS, then someone will carry out "systematic search-and-destroy missions", probably involving AWB or bots. This is why MOS should have as few rules as we can get away with.Nigel Ish (talk) 09:24, 3 June 2022 (UTC)
I simply think that in most cases, starting sentences with “and” or “but” isn’t in keeping with the encyclopaedic tone of Wikipedia. I raised it here because another editor keeps warring over the usage of such conjunctions, refusing to let “but” be replaced with “however” at the start of sentences. I’m just going by what I’ve seen on Wikipedia - the general style seems to favour the latter. This editor insists it is acceptable grammar, which isn’t really the point. TrottieTrue (talk) 12:56, 3 June 2022 (UTC)
Indeed the point isn't that it's acceptable. The point is that it isn't inferior or deficient in any way, and your sense that it "isn't in keeping" with Wikipedia's tone is baseless. AlsoWukai (talk) 04:54, 4 June 2022 (UTC)
Baseless apart from finding “however” on numerous articles, while “but” is seldom used, in my experience. In my view, “but” or “and” sounds inferior as a way of starting a sentence on an encyclopaedia. TrottieTrue (talk) 12:22, 4 June 2022 (UTC)
See Katzenberger Trial, where User:AlsoWukai has been edit warring over their insistence upon the article retaining the sentences beginning with “but” which they inserted recently. It sounds quite awkward in that article, and unlike the tone I’m used to on Wikipedia. The article is protected for another day. This editor has also taken issue with me replacing “but” with “however” on a couple of previous occasions. It seems an odd thing to edit war over, quite apart from my stylistic preference for the latter (which I find far more often on WP).—TrottieTrue (talk) 01:33, 5 June 2022 (UTC)

WP:CURLY

It seems to me that the reasons for prohibiting curly quotes are obsolete

Can we form a consensus to eliminate the prohibition of curly quotes? --Banana Republic (talk) 02:32, 8 May 2022 (UTC)
I should mention that I personally find the curly quotes (“quote”) more visually pleasing than the straight quotes ("quote"). --Banana Republic (talk) 02:34, 8 May 2022 (UTC)

While I find the curly ones to be rather silly looking, much like the Comic Sans font.--User:Khajidha (talk) (contributions) 18:40, 8 May 2022 (UTC)

Response:

Hawkeye7 (discuss) 19:40, 8 May 2022 (UTC)

And inevitably an article will end up with a disconcerting mixture of the two, which is particularly annoying when editing in wikimarkup mode as here. Doug butler (talk) 21:44, 8 May 2022 (UTC)
Personally I prefer straight quotes and apostrophes (KISS), but reasonable people disagree. What about making the wikitext agnostic as to curly or straight, but to always display curly. Word processors can figure out which direction the quote marks or apostrophes should curl; could Wikipedia's display text do the same? I suspect that would be a big problem to solve, but it would finally solve the problem. SchreiberBike | ⌨  23:15, 8 May 2022 (UTC)
"Smart quotes" tend to break things when they get inserted in places where they are invalid. I vehemently oppose any automatic replacement of, e.g., apostrophes, parentheses, quotes, with alternate code points, even though I agree that ‘foo’ and “foo” are more attractive than 'foo' and "foo". --Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:26, 9 May 2022 (UTC)

Use of commas with glosses

I was editing the page Honourable to standardise a number of different styles for glossing/translating (I don't pretend to fully understand the difference) between different equivalents of honorifics in various languages. I tried to apply the MOS re glosses (MOS:SINGLE), but that left some slightly odd results in my view. Principally, the MOS prohibition on commas between term and definition.

It's fine for one- or two-word simple glosses (e.g. Mevrouw 'madam' is ...).

It seems clunky for longer ones (e.g. Legal academics are addressed as De weledelgestrenge heer/vrouwe Mr 'the well-born lord/lady master' when ...).

It also seems clunky when some qualification of the translation is needed (e.g. Ad libitum literally 'towards pleasure' is used ... or Anima roughly 'soul' can be ...) especially in the middle of a sentence (e.g. ... it was called a res publica traditionally translated 'commonwealth' despite having ...).

Would it be very controversial to edit the MOS to add words to the effect of...

With or without the example (someone can likely think of a better one), or put the addition in a footnote otherwise?

Charlie A. (talk) 13:41, 9 May 2022 (UTC)

It's not the length of the gloss that matters, but the syntactic structure (including qualification, but also relative clause structure, apposition, etc.); for example:

     – Amicus usque ad aras 'a friend up until the altars' refers to ...
     – Amicus usque ad aras, literally 'a friend up until the altars', refers to ...
     – Amicus usque ad aras, which means 'a friend up until the altars', refers to ...
     – Amicus usque ad aras, a Latin expression for 'a friend up until the altars', refers to ...
     The first of these is a simple gloss with no comma before the definition, and the rest are non-simple. Doremo (talk) 15:16, 9 May 2022 (UTC)

OK, that's very helpful – thanks. But if single-quotes rule applies to the non-simple glosses, as your answer implies, the MOS wording needs to be changed to say so. (I also think that the example in Dutch I gave above would be much improved with commas, but I'm happy enough to accept it if I've applied the rule as intended). Charlie A. (talk) 17:08, 9 May 2022 (UTC)
I was thinking of simple (syntax) = no comma vs. non-simple (syntax) = comma. Otherwise a gloss is a gloss and is set in single quotes, even long stuff with grammatical codes. Doremo (talk) 17:48, 9 May 2022 (UTC)
Crikey that's an intimidating chapter. I would welcome a clarification to the MOS to make clear the two rules you've outlined: (a) simple glosses don't need a comma, non-simple do; (b) all English glosses go in single quotes, whether simple or non-simple. I read the current guidance as clear for simple glosses, and saying nothing about non-simple ones. Charlie A. (talk) 18:05, 9 May 2022 (UTC)
Come to think of it, it's not really the gloss that's the issue at all: (a) all English glosses go in single quotes with no comma before the definition, (b) relative clauses, appositives, and other structures containing a gloss may be preceded by a comma or other punctuation after the lexeme. Doremo (talk) 02:53, 10 May 2022 (UTC)
Agreed, that's a good summary. The current wording only covers scenario (a), though it actually applies to glosses in general. How about something like:
  • Simple gGlosses that translate or define unfamiliar terms take single quotes, with; simple glosses require no comma before the definition (Cossack comes from Turkic qazaq 'freebooter' is the root of Cossack; republic comes from the Latin res publica, loosely meaning 'public affair').
(With or without the second example) Charlie A. (talk) 08:11, 10 May 2022 (UTC)
This looks good to me. I think the second item is helpful. (I'd prefer no the before language names, but some people do that.) Doremo (talk) 12:36, 10 May 2022 (UTC)
That was me on autopilot – reordered the example to show the gloss in the middle of the sentence, put a the in naturally. Wasn't an intentional/meaningful change, I've removed it. Should I just go ahead an edit or do we need some broader input/RfC? Charlie A. (talk) 13:34, 10 May 2022 (UTC)
I agree with it. I think it's uncontroversial and has been fully discussed here. Please go ahead and make the edit (suggestion: "the Latin" → "Latin"). Doremo (talk) 14:01, 10 May 2022 (UTC)
Done ✅ (with "the Latin" → "Latin"). Thanks for your help! Charlie A. (talk) 15:58, 10 May 2022 (UTC)

I never heard of using single quotes except inside double quotes. Is this some Commonwealth custom? BeenAroundAWhile (talk) 04:59, 10 May 2022 (UTC)

It's a standard convention in linguistics, just like setting binomials in italics is standard in taxonomy. Articles that make use of linguistic, taxonomic, etc. material generally follow the field-specific conventions. Doremo (talk) 05:50, 10 May 2022 (UTC)
Wikipedia is also the first place I'd encountered the convention. I do like it though, it's helpful to have a different markup from the glossed term (in italics) that's subtle and distinct from a direct quote. Charlie A. (talk) 07:55, 10 May 2022 (UTC)

Circa

For the usage of "Circa", the current MOS simply states, To indicate approximately, the abbreviation c. (followed by a space and not italicized) is preferred over circa, ca., or approx. c. may be used.. This is pretty straightforward, but I'd like to suggest that we state that ((circa)) is actually the preferred usage. I have come across many editors and readers that have commented that just "c." alone is confusing to them and does not help them, while "circa" is better in their view, but I point out that it is not preferred by the MOS and that "c." is. That said, I think ((circa)) solves this problem, and I have never had any pushback over ((circa)), because it allows the reader to hover over the c. and the text will display "circa", while I acknowledge that this might not be ideal then for mobile devices, it seems to be the best of all worlds. While not a formal RfC (yet). I'd like to ask the community if a minor reword to look like following could be made the he "Circa" section of this MOS:

To indicate approximately, the abbreviation c. is preferred over circa, ca., or approx. For example, c. 1955 and not circa 1955, ca. 1955, nor approx. 1955 Th78blue (talk) 17:20, 25 April 2022 (UTC)

Or even simpler, just indicating priority of ((circa)), how about, "To indicate approximately, the use of ((circa)) is preferred over circa, c., ca., or approx." This ensures that the benefit of the Tooltip is available to all, while in no way changing the aesthetic of the currently preferred "c." or c. Th78blue (talk) 01:07, 26 April 2022 (UTC)
Can anybody explain why not to use the plain English words around and about instead of their Latin translation, which most English speakers can't even pronounce properly? — Mikhail Ryazanov (talk) 23:11, 26 April 2022 (UTC)
In infoboxes and tables, at least, c. 1890c. 1950 is much more concise than around 1890 – about 1950. pburka (talk) 23:26, 26 April 2022 (UTC)
For years in confined spaces – OK. But for everything else?.. In normal text, "around"/"about" are much more natural, and for brevity, there is a common notation "~" (consistent with ">", "<", "≳", "≲"). — Mikhail Ryazanov (talk) 23:47, 26 April 2022 (UTC)
When a term which was originally Latin has become so much part of the language that it is used in speech, then it would be obvious to accept it as having become English. There are many Latin words in everyday use, not just the more obvious ones such as "etcetera" or "consensus" but also modified words like "pork" or "beef". Using two words with a solidus between them is informal and deprecated unless there is no alternative. Martin of Sheffield (talk) 06:23, 27 April 2022 (UTC)
Hear hear! Moreover, I will not pronounce the statesman's name "Kickero" unless and until time travel is a practical possibility. Cheers, all. Dumuzid (talk) 13:46, 27 April 2022 (UTC)
What did you mean by "two words with a solidus between them"? If if was related to "around"/"about", then I was using it just on this talk page, indeed in an informal context and with the sense of exclusive or. And why do you call it deprecated? CMOS doesn't think so (see 6.106). Regarding English "circa", all dictionaries define it as "approximately, about, around", not the other way around. So my initial question was what is the purpose of using a loanword in English Wikipedia if English language already has appropriate words with the same meaning. It still remains unanswered. — Mikhail Ryazanov (talk) 19:06, 27 April 2022 (UTC)
There are few or no words in English that did not originally come from another language. There is no requirement on Wikipedia that we only write with Germanic-origin words, avoiding the Romance-origin or other-origin words. Indeed, you have used several other Romance-origin English words besides "circa" in your reply: approximately, initial, deprecated, dictionary, language, etc. Do you think those words, also, should be avoided? What makes "circa" in any way different from them? —David Eppstein (talk) 19:10, 27 April 2022 (UTC)
English is a crazy mixed-up language. Sometimes we don't care where words originated, and meld them anyhow - so "television" is a bastard of Greek and Latin. We've spent over a thousand years hearing invaders and other tourists using different words and for one reason or another, adopted them for ourselves. Sometimes it was the other way about: our colonists went to India and brought back bungalow, pyjamas, shampoo and verandah. --Redrose64 🌹 (talk) 22:28, 27 April 2022 (UTC)
I don't think that "approximately", "initial", "deprecated", "dictionary", "language" should be avoided. What makes "circa" different from them is that "circa" has more common and convenient analogs, whereas these words don't. I had no intention to go down to Proto-Indo-European history and am quite surprised that other people stated all this rambling instead of answering a simple question. — Mikhail Ryazanov (talk) 19:39, 28 April 2022 (UTC)
You are digging your hole deeper. Of course those words have Germanic parallels, as do most Romance words in English. "approximately"="about", "initial"="first", "deprecated"="unwanted", "dictionary"="wordbook", "language"="speech". In this respect they are not different from "circa". —David Eppstein (talk) 00:40, 29 April 2022 (UTC)
Circa itself is common and convenient, as well as being more concise than "in approximately", "in or around", etc. It's not a "loanword" by any reasonable standard, having been used in its current meaning in English since the 19th century (the OED gives an example from 1861; Google Books finds an example apparently from 1848). XOR'easter (talk) 01:38, 29 April 2022 (UTC)
Why do you assume that the way most English speakers pronounce it isn't "proper"? Seems like you are confusing the pronunciation of the Latin word "circa" with the pronunciation of the English word "circa". In which case saying that English speakers are mispronouncing it makes about as much sense as saying that you mispronounce your own first name because you don't say it the original Hebrew way. --User:Khajidha (talk) (contributions) 15:53, 27 April 2022 (UTC)
You are replying at a wrong level. :–) And not answering the question asked ("why not to use the plain English words?"). — Mikhail Ryazanov (talk) 19:06, 27 April 2022 (UTC)
1) Nope. I was replying to your comment about "proper" pronunciation. Hence, I indented one more level than you. 2) As to why use "circa" instead of "about" or "around", simply because circa is more commonly used in certain constructions in English. I would expect to see "around" or "about" in usages like "about a hundred years ago" or "around the time the tornado hit". I would expect to see "circa" in usages like "the city was founded circa 800 BC". English has many examples where there are "plain English" and "foreign" words that have dictionary definitions (denotations) that seem similar or identical, but which show different patterns of usage with different conotations. --User:Khajidha (talk) (contributions) 19:32, 27 April 2022 (UTC)
And sometimes different connotations, too. EEng 05:51, 28 April 2022 (UTC)
1) My comment about pronunciation had one level of indentation (:), your reply had four (::::), which is definitely not "one more level than the comment it replies to". 2) I've already said about years (see 23:47, 26 April 2022). Please take a look at what WP:MOS#Circa says (To indicate approximately, the use of ((circa)) is preferred over circa, c., ca., or approx.) and explain: where this "To indicate approximately" is limited to years? The whole section "Abbreviations" is about abbreviations in general, and the note in "Circa" says "See also" instead of "For details, see", making an impression that this prescription is also general, not just about years. From what I see in all the literature that I read, it would make more sense to prefer "about" or "around" over "approx." and "circa" in normal text, and specifically for years prefer ((circa)) over circa, c., ca., or approx. (due to whatever tradition). — Mikhail Ryazanov (talk) 19:39, 28 April 2022 (UTC)
1) I interpreted that comment as a continuation of the previous one, not as a separate point. I concede that your interpretation of the levels is also valid. 2) What part of "See also: Wikipedia:Manual of Style/Dates and numbers § Uncertain, incomplete, or approximate dates for examples." makes you think that circa is not limited to years? I can't recall ever seeing circa used for anything but years, and the fact that the note directs you to a section on "uncertain, incomplete, or approximate dates" and specifically says that it is "for examples" of the usage of circa is consistent with my recollection and seems to leave no room for confusion. --User:Khajidha (talk) (contributions) 21:22, 28 April 2022 (UTC)
WILL YOU TWO PLEASE STOP TALKING ABOUT THE INDENTATION LEVELS? SOME OF US ARE TRYING TO SLEEP. THANK YOU. 04:17, 29 April 2022 (UTC)
The very next section, WP:MOS#Do not use unwarranted abbreviations, starts with a very similar "See also: Wikipedia:Manual of Style/Dates and numbers § Units of measurement", although isn't itself limited to units (moreover, doesn't even mention them). There are several other examples, less striking but still demonstrating that "See also" doesn't limit the scope. Regarding MOS:APPROXDATE, there is no occurrence of the word "year" before "flourishing". Thus it can be easily interpreted such that "List of films set around May Day" must be renamed to "List of films set c. May Day" :–) (there are no such examples, but the lack of examples souldn't supersede the explicitly stated rule). However, if we assume that it is indeed limited to years, I still find it counterproductive. For example, Chronology of Jesus reads very naturally with all its "about"s and "around"s, and replacing them all with "c." would be too pretentious (there are only two occurrences of "c.", both to save space, which is fine). — Mikhail Ryazanov (talk) 22:49, 28 April 2022 (UTC)
This is obviously subjective, but I find the tooltip sort of annoying. I suppose I don't mind it much at first use in a given article, but I definitely wouldn't want it to be mandated at every occurrence, decorating a whole article with those dotted underlines. --Trovatore (talk) 23:04, 28 April 2022 (UTC)
You know what, I've thought about it some more, and my views have hardened. I don't think we should use ((circa)) at all. The tooltip interface is not one of the basic ones we use in Wikipedia, so it violates the least surprise principle to see this funny hooked question mark popping up out of nowhere. Also it's minimally useful, because people who don't know what "c." means are likely not going to be helped by glossing it as "circa". --Trovatore (talk) 16:36, 29 April 2022 (UTC)
Agree with this. Johnbod (talk) 16:45, 29 April 2022 (UTC)
The purpose of the ((circa)) template is to provide an accessible means of expanding the abbreviation "c." - it does this by means of the <abbr>...</abbr> element and its title= attribute, which is the primary semantic use for that HTML element. The fact that for some users this appears in the form of a tooltip is neither a matter for this page nor a reason not to use the template and thereby compromise accessibility. --Redrose64 🌹 (talk) 12:57, 30 April 2022 (UTC)
Never mind accessibility, what about utility? As Trovatore says: "people who don't know what "c." means are likely not going to be helped by glossing it as "circa"". In fact I'm sure more people understand "c." than circa. If it included a simple English explanation, such as "meaning "about"", there might be some point to it. Johnbod (talk) 16:59, 30 April 2022 (UTC)
So, how about we (or somebody with the right Power) change the title text from just "circa", to something like "circa – meaning about or approximately" — GhostInTheMachine talk to me 17:57, 30 April 2022 (UTC)
That is not permitted by the spec that I linked in my last post - The abbr element represents an abbreviation or acronym, optionally with its expansion. The title attribute may be used to provide an expansion of the abbreviation. The attribute, if specified, must contain an expansion of the abbreviation, and nothing else. Notice the last three words. --Redrose64 🌹 (talk) 19:36, 30 April 2022 (UTC)
(edit conflict) I agree that "circa – meaning about or approximately" would be a better tooltip. I don't have any specific knowledge, but I suspect a lot of people don't know what circa means, so having "circa" as the tooltip may be unhelpful. That being said, I still think circa or c. is often the best word/abbreviation even if not everyone is familiar with it. I'd also say that like a wikilink, the tooltip shouldn't generally be used more than once per article. In addition, while the vast majority of uses are with dates, it's fine with other numbers. SchreiberBike | ⌨  19:50, 30 April 2022 (UTC)
The template ((circa)) need only be used at first occurrence, but should be used at that occurrence. This is what is consistent with MOS:ABBR, which has us ensure that first introduction of an abbreviation is explained. I would support updating the circa advice to say this.  — SMcCandlish ¢ 😼  00:35, 4 May 2022 (UTC)
Personally I think the c. template should appear at all instances appropriate on any given article, given that we never know where a reader might come in and begin to read any given article or section of an article. If it is valid once, it should be valid always. It also takes up no additional space, and I find the tooltip to be quite useful personally for other editors that have been confused in the past about "c." alone. Th78blue (talk) 15:06, 4 May 2022 (UTC)
Agreed. Wikipedia is WP:NOTPAPER and we should recognize that our readers often jump into the middle of articles. If we really want to show the tooltip only on the first use that should be done through technical means, and it should handle cases such as readers redirected to a section, sortable tables, etc. pburka (talk) 15:37, 4 May 2022 (UTC)
That isn't the point. The point is twofold: First, we don't use this "abbr element", as far as I'm aware, for anything else. Or it's possible I've seen it once or twice, not sure. But in any case it's not part of Wikipedia's standard UX.
That's the general point about the abbr element. The specific point about this template is that this template is pretty damn close to absolutely useless. If you don't know what "c." means you probably don't know what "circa" means either. Now granted, you can Google it, which is why I qualified the statement with "pretty damn close". But all things considered the "accessibility" argument here is remarkably weak. --Trovatore (talk) 18:07, 6 May 2022 (UTC)

I think we need to consider that circa is used primarily in English ti indicate "approximately", but only really for dates. For other things, such as a number of people killed in a battle, you would not use circa. In that instance, I think a tilde with a tooltip would be the briefest and still work nicely. Any way we can create a standard for that? Whereby a tilde (~) would generate a tooltip that says "approximately" when you hover over it? Th78blue (talk) 14:03, 5 May 2022 (UTC)

By the way, which style guides recommend "circa" or "c." at all? APA only says to use "ca." (not "c."!) for uncertain publication years; MLA says to use "circa" (not "c."!) for the same purpose; CMOS says, literally, "ca. or c. circa, about, approximately (ca. preferred for greater clarity)", and has very few examples, all with years and only one with a date: "ca. 21 September" – which I don't remember seeing in real life. None of them uses or recommends "circa" or its abbreviations for anything except dates. And even if we suppose that WP:MOS#Circa is indeed limited to approximate dates (which is currently not obvious), as I mentioned above, I don't think that, for example, Chronology of Jesus would benefit from replacing "about" and "around" with "circa" or "c.", neither that in phrases like "It was scheduled to arrive around November 6", "..., with an opening expected around April 1, 1958" or "Full containment was expected around November 30", as MOS:APPROXDATE says, "the use of the ((circa)) template is preferred over circa, c, c., ca, ca., around, approximately, or approx.". So I would like to see any major style guides supporting this recommendation. Otherwise WP:MOS#Circa and MOS:APPROXDATE should be changed to be more clear and less strict (use only with years, not to be preferred over "around"). — Mikhail Ryazanov (talk) 17:36, 10 May 2022 (UTC)
A more world-wide addition. "Oxford Guide to Style" says: "The Latin circa, meaning 'about', is used in English mainly with dates and quantities. ... In discursive prose it is usually preferable to use about or some when describing quantities other than dates (about eleven pints, some 14 acres)." For what it's worth, "Australian Government Style Manual" makes a general statement: "Use English rather than Latin shortened forms, except in some cases. People will prefer the English equivalent unless the context requires special use." — Mikhail Ryazanov (talk) 18:12, 10 May 2022 (UTC)

Readability / reading level / accessibility

Is anyone aware of past discussions or good recommendations on how to decide an appropriate reading level for a Wikipedia article?

Here is the wiki article on the concept. Readability Here is a related concept; I am not suggesting plain English in all cases, but it could be appropriate in some of them. Plain English

Some questions:

I am especially interested in any links to past discussions that anyone can identify. I am not asking about any particular article. Thanks. Bluerasberry (talk) 18:56, 10 May 2022 (UTC)

WP:TECHNICAL might be of interest. Visviva (talk) 11:42, 15 May 2022 (UTC)

Styling for self-referencing list item

I have a question about list formatting. If an article contains a list, and one of the elements in that list is the subject/name of the article, can/should that element be bolded? I'm sure I've seen this somewhere, most often done automatically in navigation templates, but I'm not sure it's proper in the article body. Any thoughts on this? – Reidgreg (talk) 00:53, 12 May 2022 (UTC)

We boldface the article title in the lead, so people are clearer that they're at the right page, but there's no cause to re-boldface a recurrence of it in a list. If you mean a list that mentions the titles of other articles, no don't boldface them.  — SMcCandlish ¢ 😼  04:53, 16 May 2022 (UTC)