Wikipedia talk:Manual of Style

Wacky official US style showing up in titles and other places

The US gov has some gnarly styling that shows up in a few article titles such as San Jose–San Francisco–Oakland, CA Combined Statistical Area; the jamming together of city names with hyphens, as they usually do, was moved to en dashes in this one recently, but it still exhibits the use of the postal code, with mismatched comma, and the unnecessarily capped Combined Statistical Area (which they sometimes abbreviate to CSA). Most of our articles that once had titles of that sort have been moved to more rational titles, especially since they're not really about the statistical areas per se. Here is an Obama WH doc that lists all these things, showing off further stylings like hyphen-connected pairs or triples of state postal codes as in New York-Newark-Jersey City, NY-NJ-PA Metropolitan Statistical Area, double hyphens in things like Nashville-Davidson--Murfreesboro--Franklin, TN Metropolitan Statistical Area, etc. It's pretty hideous, but thankfully these don't show up in too many articles. Here's another title: Evansville, IN–KY Metropolitan Statistical Area. And Joplin–Miami, MO–OK metropolitan area is one where the hyphens changed to dashes OK, and the caps are reduced, but the unbalanced commas around the "MO–OK" postal code pair still looks weird and cryptic.

I'm not proposing anything in particular at this time, just seeking help if anyone wants to help figure out how to rationalize some of the place where these do show up. Dicklyon (talk) 00:33, 29 April 2018 (UTC)

I just noticed I participated in a discussion about this five years ago, at Talk:Lafayette-Opelousas-Morgan_City_CSA#Proposed_move. It didn't go anywhere useful. We should discuss again. Dicklyon (talk) 05:02, 29 April 2018 (UTC)

• Yeah, the names of these “statistical areas” are often clunky (and even contrary to the normal rules of English grammar). However, I think we need to present such names as they appear in the real world (ie sources), and not try to “correct” them to what we think they “should” be. When it comes to the presentation of names, we should only step in when sources are mixed in their presentation. Blueboar (talk) 11:35, 29 April 2018 (UTC)
  • The "external sources" meme might be ok when there's consistency out there. But as we all know, much naming is inconsistent in reliable sources. Tony (talk) 13:24, 29 April 2018 (UTC)
  • These names don't appear in a lot of sources. It's not clear that statistical areas are even "notable" – they're basically just line items from a long list of stats, and the "areas" they correspond to are usually known as something more sensible (and most already correspond to articles by other names). And even the gov docs don't refer to them consistently, sometimes adding a second comma, sometimes omitting or spelling the states, using dashes, etc. (e.g. here the US Department of Labor uses en dashes and matched comma; and this one from them uses em dash between state codes). Dicklyon (talk) 15:40, 29 April 2018 (UTC)

In the case of Joplin–Miami, MO–OK metropolitan area, I've moved it back to be about the metropolitan area as opposed to one or the other statistical area. As far as I can tell, there's no such thing as the claimed Joplin–Miama MSA, but there is a CSA. There are essentially zero sources for anything in this article. Dicklyon (talk) 16:32, 29 April 2018 (UTC)

Hmmm... I am beginning to think the real question here has more to do with WP:Notability, rather than WP:MOS. Are these "statistical areas" really notable enough for a stand-alone article... or should they be subsumed into other articles dealing with the geographic region? (If we subsume, then we won’t have to worry about using the clunky names as titles). Blueboar (talk) 17:31, 29 April 2018 (UTC)

A further annoyance with these areas is that they have a tendency to expand and change their names. A discussion at WT:WikiProject Cities#Former/deprecated CDPs touched upon this area. For me, when the only information unique to some bureaucratically defined area is a bunch of statistics, it is not really notable. Articles for such places are either deserts of stats, or they get fluffed up with info copied from other articles. Kill them, kill them all damn it! Batternut (talk) 19:15, 29 April 2018 (UTC)

Yes, I agree that what's notable about these areas is not their statistics, and as I said before, most such articles have already been renamed to be about the actual areas. The remaining couple dozen can't just be deleted, in many cases; they need to be looked at, moved, or merged. In any case, let's do try to get these funky things out of titles one way or another. Dicklyon (talk) 20:09, 29 April 2018 (UTC)

Use italics for foreign words: what about foreign units?

MOS:FOREIGNITALIC has advice on the use of italics for isolated foreign words. What if the foreign word is a unit used by {{convert}}? Please join the discussion at Wikipedia talk:Manual of Style/Dates and numbers#Unit names that are foreign words. Johnuniq (talk) 00:32, 3 May 2018 (UTC)

Idiosyncratic styling

At Manchester Small-Scale Experimental Machine and other articles, User:Eric Corbett has styling the reference sections in a novel way using Template:style-nt that he created recently, to give himself control over text point size, whether or not an edit button appears by the headings, whether they show up in the TOC or not, and what-all. The coding looks cryptic, and it's hard to discern any good reason for not going with the usual default style that one gets with normal section and subsection heading markup. He keeps putting it back, with little justification; see User talk:Eric Corbett#What does Template:style-nt do?. Does the MOS have anything to say about editors going their own way on such styling? Dicklyon (talk) 04:28, 7 May 2018 (UTC)

What does it do? What's the point of writing documentation if nobody reads it? Eric Corbett 04:55, 7 May 2018 (UTC)

This template should probably be submitted to WP:TFD. The headings are the way they are and users really shouldn't be trying to Make Their Pages Perfect With Respect To Their Preferences. There is also a bit of false documentation regarding whether bold headings are allowed by MOS--they aren't. --Izno (talk) 05:15, 7 May 2018 (UTC)

That's not what the MoS says at all. What it explicitly discourages is the use of the semicolon as in ";pseudo-heading" to produce bold headings, not bold headings per se. And it strongly encourages the use of heading markup as in "===Real heading===" for accessibility reasons, which this template supports. But I'm interested in which part of the MoS you're using to justify your assertion that "users really shouldn't be trying to Make Their Pages Perfect". Do you have a link? Eric Corbett 06:45, 7 May 2018 (UTC)

Focusing on the template issue is really to miss the point. I could, for instance, achieve a similar result to the template by prefixing a normal section header with something like <div id="section-header" style="font-size:14px;"> and suffixing it with </div>, or I could even override the default look of a level 3 header - or any other - by writing a new CSS definition. What would the MoS have to say about that, and why should it care? Eric Corbett 07:12, 7 May 2018 (UTC)

Yes, you could do that, and it would likely get reverted (I see you've made a pointy edit to that effect at already). The use of the template is more insidious, as the naive editor will see it and just think it's some widely used way of making some consistent styling, rather than your personal idiosyncratic way of styling, which is what it really is. Can't we all just use a consistent style? Aren't you a software engineer? Have you not bought in to the advantages of coding with a shared and understood style guide? Dicklyon (talk) 14:23, 7 May 2018 (UTC)

Why would it get reverted? In what way does it go against the guidance in the MoS? Of course we could all use a visually consistent style, this one for instance, which is more aesthetically pleasing than the default site-wide css for level 3 headers. Is it necessary to point out that the purpose of such css definitions is so that they can be overridden? And it's rather insulting to call my demonstration, clearly labelled as such, as pointy, but insulting behaviour appears to be your forte. One final thing: inconsistency in other areas of the MoS is actively encouraged, date formatting and spelling are two obvious examples. Is your next campaign going to be to force a single date format down everyone's throats? Eric Corbett 14:35, 7 May 2018 (UTC)

That sounds uncomfortable. Dicklyon (talk) 14:46, 7 May 2018 (UTC)

To address the broader question: MoS is a guideline primarily about the most common WP-writing "style" (spelling, grammar, tone, layout, etc.) questions and problems. It is not the One True Source of all common sense and consensus on Wikipedia, the general operating principle of which is that what has been working fine for a long time and is well-accepted by the community is the consensus, even if it was not established in a particular discussion. If someone changes something about that de facto consensus, and the change is met with little or no objection then widely adopted by others, it becomes part of the new consensus. Otherwise, we'd have to have millions more consensus discussions and a huge database to keep track of them, a project that might exceed the scope fo WP's actual public-facing content. "MoS doesn't have a rule stopping me" doesn't equate to "I can do anything I want". Otherwise MoS would have to be longer than The Chicago Manual of Style combined with New Hart's Rules, to account for every imaginable style idea. PS: I have no objection at all to adding an explicit MoS rule against using CSS tricks (manual or templated) to alter the default formatting of headings and other page elements, except inline CSS within a heading to make it conform to a particular MoS expectation. There may be some other already-accepted tweaks of this nature, such as ToC template options to suppress display of level-3 and lower headings in some cases when necessary to prevent excessively long tables of contents. If there's something wrong with how elements like the headings work on Wikipedia, and it can be addressed in CSS, then the idea should be proposed at Mediawiki talk:Common.css for inclusion in the site-wide stylesheet. If it's a sweeping change, it should probably be proposed at WP:VPTECH first.  — SMcCandlish ☏ ¢ 😼  00:45, 8 May 2018 (UTC)

One more question: what does the name style-nt mean? nt for "next thing" maybe? Dicklyon (talk) 14:24, 7 May 2018 (UTC)

What does it matter? I would have preferred to call it simply {{style}}, but a template with that name already exists. Eric Corbett 14:40, 7 May 2018 (UTC)

So why not style-ec? It matters because the Template namespace is intended to be understandable and usable by editors; it's not your personal playground. Dicklyon (talk) 14:46, 7 May 2018 (UTC)

I've really done with discussing anything with you, anywhere. You're quite impossible to deal with. Eric Corbett 14:51, 7 May 2018 (UTC)

In what way? His point is correct and sensible, though what this template is named is the least of the concerns about it.  — SMcCandlish ☏ ¢ 😼  00:45, 8 May 2018 (UTC)

Template:Style-nt A specimen, for delectation. I like gadgets, this is fun! Batternut (talk) 11:08, 7 May 2018 (UTC)

Apparently WP isn't meant to be fun. ;-) Eric Corbett 12:00, 7 May 2018 (UTC)

When misinterpreting WP as a CSS hacking playground and display case of Web-styling wizardry, that assessment is essentially correct. WP is meant to be an enjoyable environment in which to work on building an encyclopedia, but it's not even intended to be "fun" for readers, but simple and informative. It's not an entertainment website or a MMPORG, nor a place to flex one's Web coding skills in personally aesthetic ways. This is all covered at WP:NOT (#GAME, #WEBHOST, and some other sections).  — SMcCandlish ☏ ¢ 😼  00:45, 8 May 2018 (UTC)

• See Wikipedia:Templates for discussion/Log/2018 May 7#Template:Style-nt Jc3s5h (talk) 13:16, 7 May 2018 (UTC)

  I was about to suggest TfD.  — SMcCandlish ☏ ¢ 😼  00:45, 8 May 2018 (UTC)

• I don't think this really has anything to do with references, apart from the fact that the headings being formatted are in reference sections. The issue is using markup to change the way that section headings are formatted. The MOS does not cover this explicitly, but that's because it does not try to discuss every convention. In this case, there is a clear convention across the project not to try to change the font, size, weight, or other aspects of section titles. So editors should just leave that formatting as is, rather than trying to achieve some kind of special heading formatting in specific articles. I don't think this needs to be in the MOS, actually - 99.99% of editors seem to follow the convention without any trouble, so it's just a matter of fixing any uncommon articles that don't follow the convention. — Carl (CBM · talk) 15:18, 7 May 2018 (UTC)

  Agreed. This isn't about refs, but about consistency of standardized interface elements (or, rather, about unusual deviations from that consistency which don't seem to provide enough reader utility to cover the editorial cost of the divergence, or the cost to reader expectations in loss of consistency. There's a reason we don't do things like switch to a green background and a Celtic-y uncial font at articles about Ireland, and so on, despite the sense that "designer" types have that it would be fun and evocative to do so. WP is not a brochure, nor a Web-design experimentation platform.  — SMcCandlish ☏ ¢ 😼  00:45, 8 May 2018 (UTC)

New RFC on linking to Wikidata

Should we ban links to wikidata within the body of an article? --Rusf10 (talk) 00:50, 10 May 2018 (UTC)

Background

Over two months ago we had an RFC on linking to Wikidata, the result of which was "no consensus". I initiated the RFC after a user was continually adding links to wikidata to replace articles that were deleted through AfD for notability concerns, here is an example. Unfortunately, I did not create the question that we voted on and it was worded with the extreme position of "Never link to Wikidata" which got mixed support. I think most people generally agree that the links are the sidebar are useful (in particular the inter-language links) and should not be removed. However, within the body of the article there was less support for using wikidata. Some people also indicated that inline interlanguage links (see WP:ILL) may also be appropriate. However, almost everyone agreed wikidata links should not be a substitute for a red-link (or a deleted article). While I agree that linking different language versions of wikipedia is a great feature, otherwise I find wikidata to be unreliable and directly linking to it would be confusing for the average user.--Rusf10 (talk) 00:50, 10 May 2018 (UTC)

NOTE- Since there is another RFC on using wikidata in infoboxes, none of the options below will apply to the usage of wikidata in infoboxes since that is being determined separately.

I'm providing three options:

• Support- Wikidata should not be linked to within the body of the article (this includes hidden text links). This will have no impact on the sidebar links nor Wikipedia:Authority control
• Support, but with exception for inline inter-language links- Same as above, but allows for exception for use of Template:Interlanguage link
• Oppose-Link to Wikidata if an article does not exist

I am adding an additional option to clarify: --RAN (talk) 03:16, 10 May 2018 (UTC)

• Oppose- Allow hidden text links with Wikidata Q-numbers such as <!-Q1123456--> so that a duplicate Wikidata entry is not created in the future

And another, because the one above isn't an oppose rationale but another exception:

• Support, with two exceptions: for inline inter-language links and hidden-text Q numbers, as described above.

 — SMcCandlish ☏ ¢ 😼  09:54, 18 May 2018 (UTC)

Survey

• Support- full ban in body of article as proposer.--Rusf10 (talk) 00:50, 10 May 2018 (UTC)
•   NOTE: Some !voters below may have arrived via partisan audience CANVASS. This RFC was posted & linked on the Wikidata central Project Chat at 01:52, 10 May 2018.[1] Alsee (talk) 01:33, 13 May 2018 (UTC)
• Oppose - This appears to be about Rusf10 removing hidden links Q-numbers formatted as <!-Q123456--> to Wikidata from tables that list multiple people that do not currently have an entry in English Wikipedia. The Wikidata entry links to Wikipedia entries in other languages and links to Wiki Commons and Wiki Quote, even if they do not have an English Wikipedia entry. The hidden links will let an editor know that if an article is recreated or a new entry is created for this person, an entry at Wikidata already exists. This will hopefully reduce duplication of Wikidata entries. It also allows Wikipedia to disambiguate people that appear in articles and lists that currently do not have Wikipedia entries. This way a person can know that say "John Smith, Mayor of Yourtown<!-Q123456-->" in an article on Yourtown is the same person as "John Smith, President of BigCompany<!-Q123456-->" that appears in the article on BigCompany. It will allow someone who creates an article in the future to search for hidden text on the string "Q123456" and find both entries and create the properly disambiguated link to the article. Of course only someone actually editing an article will be able to see the hidden link Q-number. --RAN (talk) 02:06, 10 May 2018 (UTC)

This will do absolutely nothing to prevent duplicate entries in wikidata for topics that already have articles in wikipedia, so it seems to me to just be an excuse, not a real solution to a problem. If duplicate entries is really a widespread problem in wikidata then why doesn't wikidata come up with its own solution for this that doesn't involve wikipedia?--Rusf10 (talk) 03:38, 10 May 2018 (UTC)

Okay, to clarify what I think RAN is talking about: Suppose there is a redlink here. Somebody sees it, creates an article, and then creates a Wikidata entry for the new article. What I think RAN is suggesting is that any hint we can give here is useful, that a Wikidata item already exists, and so if/when a new article is created here, then it should be linked to the existing Wikidata item, rather than have a new one created for it.

Wikidata users make quite an effort to try to hunt down and merge duplicates, eg trying to spot potential duplicates that matching birth/death dates, or the same value for an external ID, or apparent duplicates that come up organically in search. But all these are playing catch-up, and are never 100%. It's altogether better if the new article gets linked properly from the outset.

Another reason (IMO) may also be worth considering why such references in comments might be useful, namely that if a wikidata item exists, it may have some useful information and references for basic facts like full names, dates, external identifiers, places of activity, birth, death, etc that all may be of use to somebody creating an article. Jheald (talk) 10:54, 10 May 2018 (UTC)

• Support a ban, or at least strongly discourage them, similar to the language in WP:EXTLINKS. Pburka (talk) 02:38, 10 May 2018 (UTC)
• Oppose Such links should be allowed to be used where they can provide extra information to readers and editors about the topic. They are not completely external links, they are links within the Wikimedia movement. Thanks. Mike Peel (talk) 12:07, 10 May 2018 (UTC)
• Support, but with exception for inline inter-language links. I oppose the concept of comments that point to Wikidata, because there is no unambiguous format to determine the exact meaning of such comments, or exactly how the comment would be associated with the text in the article. Such a situation is an invitation for people to write bots that screw things up. Jc3s5h (talk) 12:20, 10 May 2018 (UTC)
• We should not link to wikidata at all. Inline interlanguage links have always been discouraged in practice (notice how few of them exist). There is no reason to add an exception for Wikidata about them. — Carl (CBM · talk) 12:40, 10 May 2018 (UTC)
• Support with exception for interlanguage links per Jc3s5h. Ealdgyth - Talk 13:16, 10 May 2018 (UTC)
• Support with exception for interlanguage links per Jc3s5h and Ealdgyth. ILLs may be rare due to the fact that the English Wiki is currently standing at 5,646,567 articles, well ahead of most other languages (wp:List of Wikipedias). (Indeed if you ignore those articles written by Lsjbot, well over double the size of any other Wiki.) Therefore few articles will appear in another language and not in English, except for small geographic features and locally notable persons. ILLs are invaluable for setting up a link that can be subsequently translated either full or as guidance. When I was working on Peter Harlan I used an ILL to get the basis of the article and there are still ILLs for Cornelia Schröder-Auerbach, Hanning Schröder and Castle Sternberg within it. It means the reader has at least the possibility of finding the information until someone has the time to create an English version. Martin of Sheffield (talk) 13:40, 10 May 2018 (UTC)
• Oppose any restriction per my comment in the previous RfC. This an utter baby-with-the-bathwater case, which would disallow links to Wikidata in tables, for example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:35, 10 May 2018 (UTC)
• Mu I'm all for creating a policy to explain how and what sorts of links are useful. This sort of RFC, which is too restrictive and too ignorant of nuance, is not the way to do it. --Jayron32 14:51, 10 May 2018 (UTC)
• I cannot choose any one of the four options, although the closest thing would probably be "support with exception" + "allow hidden comments". The status quo appears to be to discourage inline interwiki links in general, except for Wiktionary and Wikisource links and those generated by {{Interlanguage link}}. Regardless of whatever concerns there are with Wikidata at this juncture, I think the current Manual of Style guidance should be sufficient, although I would update it to explicitly permit {{ill}} links to the Wikidata item. Banning hidden comments based on innocuous material, if the proposer is indeed in support of this, is patently ridiculous and unnecessarily heavy-handed, especially since these are not actually links and readers aren't supposed to see them. I don't think it's necessary to lump them together with real working links. Aside from the issue with hidden comments, I think the RfC should be clarified to indicate that the proposer is, at least according to their own words, in support of the status quo that currently exists. Jc86035's alternate account (talk) 15:06, 10 May 2018 (UTC)
• Support—there are far too many issues with WikiData's implementation and with WikiData-folk contemptuously imposing WikiData on articles beyond the control—or even awareness—of the custodians of Wikipedia articles. This shouldn't be re-opened for discussion until it can be clearly demonstrated that all the issues—both technical and behavioural—have been dealt with. Curly "JFC" Turkey 🍁 ¡gobble! 00:32, 11 May 2018 (UTC)
• Oppose A QID or URL in a comment is a good way to tip about the existence of the article in sister sites. At this stage practices are evolving and improving every day, but banning such info would just kill innovation. Syced (talk) 06:29, 11 May 2018 (UTC)
  • Note: This editor has acknowledged[2] arriving at this RFC via the partisan-audience advertisement at Wikidata. Alsee (talk) 01:33, 13 May 2018 (UTC)
• Oppose. The only reasonable usage of linking to wikidata (as opposed to pulling data from Wikidata, which the topic starter explicitly excluded from this RfC by saying it has no impact on {{Authority control}}), is to indicate next to a redlink that a Wikidata item for this redlink exists. I can not envision a single rational argument ("Wikidata is evil" is not a rational argument) against connecting a redlink on Wikipedia with Wikidata in the case the Wikidata item exists (there are plenty of items on Wikidata which do not have any sitelinks and which would be notable by our standards). Whether it should be a link similar to {{ill}} or just a number commented out is debatable, but I am not looking forward for this debate, as this RfC is very badly organized (similarly to the previous one) and is very untimely (similarly to the previous one).--Ymblanter (talk) 07:01, 11 May 2018 (UTC)
• Support- with the possible exception of interlanguage links. From what I've seen of WikiData, its content is confusing, often mostly empty, and frequently erroneous. As Curly points out, it feels lioke this junk is being inflicted on Wikipedia with minimal oversight. I'd put a moratorium on the use of WikiData until we can be satisfied that we're not just rubbishing our standards of accuracy. Reyk _YO! 07:08, 11 May 2018 (UTC)
• Support until such time as Wikidata develops a better reputation for fact-checking, referencing, and accuracy, especially for details such as citizenship of living people (often listed, rarely sourced). —David Eppstein (talk) 07:24, 11 May 2018 (UTC)
• Support - not a community based here.--Moxy (talk) 11:56, 11 May 2018 (UTC)
• Oppose Banning comments is excessive, and doesn't seem to have had any justification given. Limited use of {{ill}}-style links in tabular material and lists could also be useful. Jheald (talk) 18:39, 11 May 2018 (UTC)
• Support. Wikidata links are an inappropriate destination, except perhaps in the Wikidata article or other articles actually discussing Wikidata. In rare cases I could see a valid purpose for a hidden comment mentioning Wikidata. However hidden links are inappropriate without some unusual need in the specific case. Links to foreign language articles are generally a bad idea for a number of reasons, but sending a reader to Wikidata for interlanguage links is even worse. Alsee (talk) 02:56, 13 May 2018 (UTC)
• Support. Sending readers to Wikidata is very rarely helpful, and if an editor believes that more information about a redlink or an unlinked term / name is needed, it would be better if they added a reliable source as a reference to it. The same applies to the vast majority of regular interlanguage links in our articles. Fram (talk) 13:33, 17 May 2018 (UTC)
• Support. Rusf10, I'm not sure what "with exception for interlanguage links" has to do with the question "Should we ban links to wikidata within the body of an article?" SarahSV ^(talk) 14:13, 17 May 2018 (UTC)

  SarahSV I believe wikidata interlanguage links refers to replacing a redlink Jokery with Jokery, which sends the user to the bottom of a Wikidata page. In my opinion the typical reader will WTF when they see the link, and they'll be confused as hell if they click on it. Alsee (talk) 09:26, 18 May 2018 (UTC)

That's really confusing. I was thinking more along the lines of Olena Chaplynska. That could possibly have a use, but in my opinion, neither should be allowed. I just wanted to offer it as an option since some people had expressed support for these types of links in the past.--Rusf10 (talk) 14:24, 18 May 2018 (UTC)

• Support. Disruptive without sufficient utility for almost all readers. Who actually uses Wikidata? My guess is a special type of reader. I have no objection if Wikidata links are added where they're easy to find and unobtrusive—in the "See also" section at the bottom, or some such. Tony (talk) 14:23, 17 May 2018 (UTC)
• Support with the two exceptions. My reasoning is basically the same as that of David Eppstein who put it more succinctly than I would have. At some point, we can work-in an exception for WD material that is sourced to en.wp standards, when WD provides a means for us to be certain of this. WD-provided information would be useful for certain things, especially tabular data. But we're just not there yet. This project's core content policies are way more important that link-making convenience or data-provision centralization.  — SMcCandlish ☏ ¢ 😼  10:04, 18 May 2018 (UTC)

Overlaps with another RFC

• Please note - This RFC overlaps somewhat with another that is still ongoing (see Wikipedia:Wikidata/2018 Infobox RfC). I do not believe that there is any intentional forum shopping involved... but we do need people to know that similar questions are being discussed elsewhere. Blueboar (talk) 15:01, 10 May 2018 (UTC)

Thank for letting me know about this, I will add a statement above to clarify the proposal will not apply to infoboxes since that is being decided elsewhere.--Rusf10 (talk) 16:07, 10 May 2018 (UTC)

Fair enough. However, please note that the other RFC has grown beyond just discussing infoboxes. It may be better to put this discussion “on hold”... Until we see how the other closes. Blueboar (talk) 16:36, 10 May 2018 (UTC)

Disagree strongly. This RfC is straightforward and already looking like a WP:SNOWBALL. That other RfC is a sprawling mess of 1A, 3C, etc. options, from which obviously no consensus is going to emerge, other than possibly the one that points in the same direction this RfC is going. Virtually every single answer there conflicts with ever other answer, except that multiple respondents are arriving at the most-restrictive option (1A+2A+3A+4A). It's a textbook example of why to not structure RfCs that way. Ask one question, then do another RfC to ask another question. Also, as I commented over there, the excessively geeky structure and wording of that RfC basically makes it invalid: it's heavily skewed toward the input of IT professionals (few who are not in that camp will be able to parse it), and they have a strong bias in favor of data centralization and automation.  — SMcCandlish ☏ ¢ 😼  10:27, 18 May 2018 (UTC)

Semi-protected edit request on 10 May 2018

In Wikipedia:Manual_of_Style#Celestial_bodies, it says sun, earth, and moon are not capitalized except in astronomical use. MOS:CELESTIALBODIES says the same exact thing except with solar system added. I am questioning whether solar system should be added to Wikipedia:Manual_of_Style#Celestial_bodies because the article title of the solar system on Wikipedia is capitalized while on other sites it is not. I can't think of other ways solar system is used outside of astronomical use. 2601:183:101:58D0:34E8:552C:3EB8:46BF (talk) 20:07, 10 May 2018 (UTC)

@2601:183:101:58D0:34E8:552C:3EB8:46BF: Umm ... you seem to be requesting that this page not be changed but rather MOSCELESTIALBODIES (which you could edit directly) be changed and the article Solar System be moved accordingly. For this reason, your edit request is unanswerable on its face. If I am misinterpreting you and you actually think this page should proscribe the use of "Solar System" ... well, that's not going to happen because you made an edit request on this page, unless there is also consensus to move the article. It should, however, be noted that there is not currently a contradiction between that article's title and MOS:CELESTIALBODIES; the article is about astronomy, and specifically our solar system (i.e., it's using it like a name rather than a common noun). That this page doesn't go into quite as much detail as the capitalization subpage should be a given. Hijiri 88 (聖やや) 01:43, 17 May 2018 (UTC)

Use of "founded" to describe in-name-only change of status of a municipal government?

The lead of our Katano, Osaka doesn't quite sit well with me. According to ja.wiki, the town of Katano was formally declared a "city" in 1971, but using "founded" brings to my mind an image of settlers venturing into the wilderness and establishing a new settlement. Our Takizawa, Iwate article describes a similar process with the word "promoted". There's also the problem of "new" municipal governments being established from mergers or dissolutions, which I also wouldn't think "founded" would accurately describe.

But this might all just be me and my hang-ups, so rather than changing it unilaterally (and I could almost certainly "get away with it") I figured I'd ask here. Thoughts?

Hijiri 88 (聖やや) 01:33, 17 May 2018 (UTC)

• Reading the Japanese version, it sounds like that's when it went from being a -chō "town" to a -shi "city". The ja.wp version describes the -chō as being "市制前の名称" ("the name before municipal organization"?) I get the feeling that that's something like "incorporation". Curly "JFC" Turkey 🍁 ¡gobble! 01:45, 17 May 2018 (UTC)

No doubt - alternatives might be "achieved city status", "was declared a city" or something. Not founded if there was a pre-existing settlement. Johnbod (talk) 02:01, 17 May 2018 (UTC)

@Curly Turkey and Johnbod: What about cases like Ōshū, Iwate, which was apparently "created" in 2006 from two cities, two towns and a village that had existed before without any specific connection to each other? I'd still be averse to saying "founded" when describing municipalities that were created from mergers even when no city called "Ōshū" had existed before. (BTW, I'm pretty sure the name of the city is just as arbitrary as it sounds.) It may be hypothetical because that article currently uses "established", which I'm fine with, but I'm pretty sure there are a lot of places like this in Japan and maybe elsewhere (not Ireland, if I recall, and I don't know a lot about others). Hijiri 88 (聖やや) 07:07, 17 May 2018 (UTC)

"Merged" or "amalgamated" work—or "formed as a result of the amalgamation/merging of XXX and YYY". That was part of the whole 平成の大合併 about a decade-ish ago. Curly "JFC" Turkey 🍁 ¡gobble! 07:29, 17 May 2018 (UTC)

Yes - "founded" is really only appropriate for greenfield sites, or where there was just a little village. It's mainly appropriate for once-colonial places, or imperial whims. Johnbod (talk) 13:06, 17 May 2018 (UTC)