Wikipedia talk:Manual of Style/Dates and numbers

Numbers

Under the Numbers section, it states:

"Generally, in article text:

Integers from zero to nine are spelled out in words."

I wonder why is "from zero to nine" instead of "from zero to ten"? We humans have ten fingers, we learn how to count from one to ten since we were little kids. If we learn a foreign language, the first thing we learn is words like hello, thank you, good bye, and count from one to ten. It doesn't make sense that only integers from zero to nine shoulde be spelled out in words. It should be integers from one to ten. 120.16.218.233 (talk) 17:18, 13 April 2024 (UTC)

Yes, but cats have nine lives, so it makes perfect sense actually. GiantSnowman 17:19, 13 April 2024 (UTC)

LOL. You must be joking. 120.16.218.233 (talk) 17:21, 13 April 2024 (UTC)

...weren't you? GiantSnowman 17:23, 13 April 2024 (UTC)

Nope. I really think that in article text, integers from zero to ten should be spelled out in words (i.e. ten years ago not 10 years ago). 120.16.218.233 (talk) 17:28, 13 April 2024 (UTC)

We don't say that "only integers from zero to nine shoulde be spelled out in words". We do say that Integers greater than nine expressible in one or two words may be expressed either in numerals or in words and proceed to qualify that in several ways, allowing for either "10" or "ten" to be used as appropriate. NebY (talk) 17:39, 13 April 2024 (UTC)

I’ve thought this for a long time, so agree with you. Numbers expressed as words are easier to read and don’t visually interrupt a sentence in the same way as does sticking figures in the middle of it. IMHO figures should only be used when multiple words are needed to express the quantity. MapReader (talk) 18:59, 13 April 2024 (UTC)

"Numbers expressed as words are easier to read". My experience is the opposite. I find it much easier to express numbers as numerals always. I only express them in words when English convention says Thou Must Use Words For Small Numbers but I never liked it. Mind you, I spend most days writing software and doing engineering stuff, so I may not represent the typical reader.  Stepho  talk  11:07, 14 April 2024 (UTC)

Agreed. We should be looking to REDUCE the instances of "numbers as words", not increase them. --User:Khajidha (talk) (contributions) 17:19, 17 April 2024 (UTC)

While I have no strong preference one way or the other, adding ten to the numbers for which words are preferred would be fine with me. Ten is indeed just one more character than 10, so it's the number easiest to spell out. Gawaon (talk) 19:25, 13 April 2024 (UTC)

Some other style guides:

• The BBC News Style Guide has "For the most part, we use words for single-figure numbers, digits for anything above nine (ie eight, nine, 10, 11)" followed by various exceptions.[1]
• The Guardian and Observer style guide has "Spell out from one to nine; numerals from 10 to 999,999 ...."[2]
• According to this 2005 discussion here in WT:MOSNUM, Wikipedia talk:Manual of Style/Dates and numbers/Archive 25#Numbers written as words, the Chicago Manual of Style has (or had) "According to Press style, the following are spelled out in ordinary text: Whole numbers from one through ninety-nine; Any of these followed by hundred, thousand, million, etc."
• According to the same discussion, the Oxford Style Manual (2003) had "In non-technical contexts, OUP style is to use words for numbers below 100."
• Fowler's Modern English Usage (4th edn) has "Figures should be used when the matter consists of a sequence of stated quantities [e.g.] The past 12 months show an increase of 5 tons" and "In descriptive matter, numbers under 100 should be in words, but write 90 to 100, not ninety to 100."

I haven't tried a proper search in MOSNUM's history – I doubt a straightforward Wikiblame search would help – but it looks as if the core one-to-nine rule's been stable since Wikipedia talk:Manual of Style/Dates and numbers/Archive 73#Proposed revision of "Numbers in words" in 2007. NebY (talk) 20:26, 13 April 2024 (UTC)

Proposal The IP user brought up an interesting point. Why "from zero to nine"? Why not "from zero to seven, eight, ten, or eleven"? I propose that we change the rule to "Integers from zero to twenty are spelled out in words". If we can express a number in a single, simple English word, then use the English word. If more than one word or a hyphen is involved (e.g. twenty-one, one hundred and one), use the numerals. N. Mortimer (talk) 00:32, 14 April 2024 (UTC)

Against - Existing form (words for single digits, numerals for more) works fine. Examples for each:

1. There 14 reasons to object.
2. There are fourteen reasons to object.

The numeral form is so much more compact, quicker to type, quicker to read, requires less effort to understand and the quirks of spelling for 11-19 are avoided for our English as a second language audience (why is 11,12 different to 13-19; why is 13-19 different to 23-29, etc?). Keep it simple.  Stepho  talk  01:53, 14 April 2024 (UTC)

So you also support my proposal of adding "ten" to the mix? Thank you. Ten is a very simple word, I think all people with a basic understanding of English know this word.

By the way, even if we use "14" instead of "fourteen" in your sentence example, we can't really omit the "are", but I agree with you that numbers greater than ten should be written in the numeral form. 120.16.218.233 (talk) 09:57, 14 April 2024 (UTC)

Oops, I forgot to type in "are" for the first example. My mistake.

Oh dear, it looks like only 1 of us knows how to count up to 2. "10" is not a single digit, so "words for single digits, numerals for more" means I support "10", not "ten".  Stepho  talk  10:22, 14 April 2024 (UTC)

Why don't you support "ten"? "Ten" is shorter than "three", "seven" or "eight". People like to group things in even numbers, not odd numbers (because they are odd 😂). 120.16.218.233 (talk) 23:59, 14 April 2024 (UTC)

Because "10" is not a single digit. Am I saying this wrong? Should I type slower? Should I use words with one syllable or less?  Stepho  talk  00:31, 15 April 2024 (UTC)

No. Spelling out such simply words is already allowed, it shouldn't be required. It's very hard to see why 17 should be treated differently than 27, and if this rule were adapted, it would logically have to apply to thirty, forty etc. as well. Gawaon (talk) 04:43, 14 April 2024 (UTC)

Yes, it should logically apply to thirty, forty etc. And the reason is obvious; single spelled words are easier to read than interrupting a sentence with digits, but that advantage weakens when multiple words are required to spell out a number. MapReader (talk) 06:40, 14 April 2024 (UTC)

Actually, I find "The applicants' ages ranged from seventeen to seventy" harder and less convenient to read than "The applicants' ages ranged from 17 to 70". Especially, in latter sentence the numbers stand out, making them very easy to detect when one skims a text quickly, which is not the case in the former sentence. Gawaon (talk) 07:02, 14 April 2024 (UTC)

That's why we should make "ten" the cut-off point:

Zero

One

Two

Three

Four

Five

Six

Seven

Eight

Nine

Ten

11

12

13.... 120.16.218.233 (talk) 10:03, 14 April 2024 (UTC)

No. As spelt out in the very next sentence after Integers from zero to nine are spelled out in words, we already allow that Integers greater than nine expressible in one or two words may be expressed either in numerals or in words, both subject to and extended by the following notes and exceptions. This is appropriately flexible; the mere fact that single words exist for some numbers does not meant they are always the best way for readers to take in quantitative information, even when reading the text closely rather than skimming it for key points – as many encyclopedia readers do. Our manual is in keeping here with at least some other major style guides, and has served as stable guidance and a sound reference point for Wikipedia editors for many years. NebY (talk) 18:02, 17 April 2024 (UTC)

• I don't care whether the boundary is at non, ten, or eleven. Tony (talk) 04:48, 25 May 2024 (UTC)

I have a question regarding numbers. What if a number below 10 is part of a larger number that is partially spelled out? For example, 3 million, 4 thousand, 6 hundred, etc? Also note that numbers below 10 are not spelled out in {{Convert}} which is inconsistent with this MOS. Volcanoguy 17:48, 17 June 2024 (UTC)

Just happened to see this pop up; I'll record that, while I don't think it's a big deal, it would make sense to me to include "ten" as the last use-words number. I think that's what I learned in typing class. Also the English names up through ten all have five letters or fewer, whereas from eleven on they generally have six or more (the exceptions I can think of being "forty", "fifty", "sixty" — I think that's it? unless you count mega, which few people would). One thing we should emphasize in any case is to avoid mixing; don't say the winner got 13 points and the loser got seven. But I assume without checking that this is already mentioned. --Trovatore (talk) 18:14, 17 June 2024 (UTC)

And I know without checking that it is. EEng 18:19, 17 June 2024 (UTC)

Discussion on other talk page and project

See Wikipedia:Village pump (policy)‎#MOS on date format by country and Talk:Lisa del Giocondo‎#Edit warring about whether the date format customary in a non-English speaking country has any bearing on what date format should be used in an English Wikipedia article. Jc3s5h (talk) 22:31, 16 June 2024 (UTC)

The answer is yes, we should use the local date format regardless of the language spoken. GiantSnowman 17:58, 18 June 2024 (UTC)

DATETIES vs. DATEVAR/DATERET

I agree with Eeng's edit to make it even clearer that DATEVAR/DATERET is referring to DATETIES when it says "strong national ties". This was already clear to me, but it seems like the change will help avoid an interpretation that would put the two in parts of the guideline in conflict with each other. It has been evident since this guidance was first added that the two parts are meant to be harmonious. Firefangledfeathers (talk / contribs) 18:00, 18 June 2024 (UTC)

I personally think it's pretty silly to have MDY set on articles whose topic doesn't touch North America. It's just awkward to work with when most quotes and literature will be in the other format. Remsense诉 18:00, 18 June 2024 (UTC)

"most quotes" is an interesting one. I could see that being a strong basis for change based on talk page consensus. Firefangledfeathers (talk / contribs) 18:10, 18 June 2024 (UTC)

There's also cultural reasons when terminology used in the article is usually tied to a certain order. I do feel this is a distinct issue from ENGVAR. Remsense诉 18:15, 18 June 2024 (UTC)

Could you give an example of what you mean here? Firefangledfeathers (talk / contribs) 18:26, 18 June 2024 (UTC)

This all started with Lisa del Giocondo using MDY, even though Italy used DMY and all related significant articles to that one use DMY... GiantSnowman 18:53, 18 June 2024 (UTC)

Thanks, but I meant examples of "terminology used in the article" that is "tied to a certain order". Firefangledfeathers (talk / contribs) 18:59, 18 June 2024 (UTC)

I'll retract this for now, as I can't actually think of a good example. I'll update this if one pops into my head. Remsense诉 19:33, 18 June 2024 (UTC)

I don't actually really care if you want to tweak the wording here. However, my strong position remains that we should use the local date format regardless of the language spoken. Remove "English-speaking countries" to reflect this. GiantSnowman 18:01, 18 June 2024 (UTC)

I'm not at all opposed to changing the guidelines collectively so that they match your preference here. It's just that I do conceive of that as being a substantive change, and I'd like to see it run through the proper process. In the meantime, I think it's important that we have language in our guideline that is internally consistent. Firefangledfeathers (talk / contribs) 18:19, 18 June 2024 (UTC)

I too think that EEng's change (which was reverted by GiantSnowman) is constructive – it's very clearly just expressing what the current guidelines are meant to express, just didn't quite as clearly because (I suppose) nobody thought that the brief backreference to the more detailed language in DATETIES would be misinterpreted. Gawaon (talk) 18:24, 18 June 2024 (UTC)

I also agree that EEng's change was a good one that added clarity to established style. Doremo (talk) 18:34, 18 June 2024 (UTC)

I would agree with this, which reflects my impression of how most articles already are, except where someone has decided to make date format an issue. MapReader (talk) 19:32, 18 June 2024 (UTC)

"English-speaking countries" is appropriate in the guidelines. There is no reason why English-language material on Wikipedia should be subordinated to a pattern in a non-English language—whether this is date format, punctuation, alphabetization, calendrical system, numbering system, first/last name order, or any other language feature. Doremo (talk) 18:23, 18 June 2024 (UTC)

Actually, there are pretty clear distinctions there: some concern how a specific language is written, and others are invariant of the language being written. Also wait, name order? Are you suggesting we put every biography by default in given-family order, assuming there's not an existing English-language COMMONNAME? That's loony.Remsense诉 18:25, 18 June 2024 (UTC)

That's right. Looking at a non-English language to decide how to write English is loony, as you put it. Doremo (talk) 18:31, 18 June 2024 (UTC)

No, you are painting with the world's broadest brush and conflating a lot of different things into "English vs. non-English", and it sounds ridiculous. It's not how any other publication on Earth would do things. Remsense诉 18:31, 18 June 2024 (UTC)

To be clear, this would result in new biographies of Chinese people being written in an order that is used by no one except us, and then we would always have to change it to the right way around when we notice that other English-language sources are doing the natural, obvious thing. Inane. Remsense诉 18:40, 18 June 2024 (UTC)

GiantSnowman, since you seem most committed to getting this changed, could you suggest a rewording to MOS:DATETIES that you would prefer? To discuss this, I think it would help to know what specifically the alternative would be – and when I look at DATETIES, it doesn't seem all that trivial to find one. Gawaon (talk) 18:59, 18 June 2024 (UTC)

I have no issues with EEng's proposed wording, minus "a particular English-speaking country", which instead should just be "a particular country" or "particular date format" or similar. GiantSnowman 19:31, 18 June 2024 (UTC)

I agree with the overwhelming majority here, that EEng's edit should be restored. It clearly reflects both the original intent of the guideline and the consensus here. JoelleJay (talk) 04:29, 4 July 2024 (UTC)

I do not want to see us make a change that would cause us to use 2024 June 18 (nor 2024-06-18) as the main date format for articles about Japan-related topics. For this sort of reason, I prefer to continue to restrict this guideline to only apply to English-speaking countries, and I would prefer to reinstate EEng's edit to clarify this continued restriction. —David Eppstein (talk) 19:04, 18 June 2024 (UTC)

That's not what anyone wants. DMY is preferable to MDY since we naturally don't use YMD. Remsense诉 19:07, 18 June 2024 (UTC)

Yeah, the date formats used are DMY or MDY. In my experience Japanese topics tend to use MDY. GiantSnowman 19:31, 18 June 2024 (UTC)

Right, that's currently the case (since your suggested rule modification is not yet in force), but can anyone of us say with any certainly which date formats are usual in arbitrary non-English-speaking countries? If it's YMD or YDM or something like that, that would be quite awkward to try to mimic in English. Hence I think just striking "English-speaking" is not going to fly. Gawaon (talk) 20:12, 18 June 2024 (UTC)

The usual Japanese format appears to be Y-M-D, written out in numerals, with kanji after each number specifying what it is [3]. If we were required to follow national ties for non-English-speaking countries, some kind of Y-M-D format would be the one. Probably YYYY-MM-DD since that's the only one in that order that matches our MOS. GiantSnowman, if you want the guideline to be "follow national ties only for countries that have M-D-Y or D-M-Y format and otherwise do something else" then you need to be more specific rather than focusing the current discussion on following national ties more generally for all non-English-speaking countries. It sounds to me like your intended proposal is really "allow Americans to use M-D-Y and force all other topics to use D-M-Y", regardless of whether that is relevant for the nation in question. Your experience of what we have historically tended to use for our articles on topics from those countries is not particularly relevant. National ties means ties to a format used by people in that nation, not accidents of past Wikipedia editing. —David Eppstein (talk) 20:47, 18 June 2024 (UTC)

Since, for good reasons, the "Manual of Style/Dates and numbers" only allows the YYYY-MM-DD format for dates from the year AD 1583 and onward, and only for Gregorian dates, some articles with strong ties to some countries in eastern Asia would not be able to use the YYYY-MM-DD format. And what about other than dates containing the year, month, and day. How would a date like June 18 be formatted? Where would an English-speaking editor find that information? Jc3s5h (talk) 20:57, 18 June 2024 (UTC)

Nobody is suggesting we use YMD, given that that is not an established format on English Wikipedia. GiantSnowman 17:58, 19 June 2024 (UTC)

List of date formats by country? Hawkeye7 (discuss) 20:54, 18 June 2024 (UTC)

Since "List of date formats by country" was written and is maintained by the same editing community that inhabits this talk page, except editors seem to pay less attention to it, I pay no attention to it. Jc3s5h (talk) 20:59, 18 June 2024 (UTC)

To the list, or to this MOS page? Hawkeye7 (discuss) 21:27, 18 June 2024 (UTC)

I pay no attention to the article, because I have no confidence in its factual correctness. I pay attention to the style manual because style manuals are arbitrary decisions by a publication. Jc3s5h (talk) 21:53, 18 June 2024 (UTC)

Jc3s5h, unsure if you're trolling or having AI write your responses for you? GiantSnowman 17:58, 19 June 2024 (UTC)

I understand GiantSnowman's concern about using the local date format regardless of the language spoken. However, I also recognize the concerns of other editors, such as David Eppstein, that using local date formats could introduce non-dmy or non-mdy date formats, such as Japan's yyyy-mm-dd.

To address both viewpoints, we could add a new sentence to the manual of style, such as For articles about non-English-speaking country, the date format used should generally match the one most commonly found in English-language sources from that country. For example, in the case of Japan, the mdy format is used because English-language sources from Japan such as NHK, Japan Times, Mainichi, Asahi Shimbunand Kyodo News all use it.. What do you think about this suggestion? Ckfasdf (talk) 03:09, 19 June 2024 (UTC)

No, no, no. First of all, a provision addressing articles "about a non-English-speaking country" is useless, because it would only apply to the articles Japan and Russia and Rwanda and so on. Second, changing "ties to an English-speaking country" to just plain "ties to a country" is an absolutely terrible idea, as I will describe below. EEng 08:32, 19 June 2024 (UTC)

Not sure why we are duplicating the discussion that is at Wikipedia:Village pump (policy)#MOS on date format by country. Anyway...

Beware that Japan does not have a default English language format. They use whichever format they have business partners with or whichever format the individual person learnt from his/her teachers. If they deal more with Brits/Aussies then they use DMY. If they deal more with yanks then they use MDY. The sources you listed are all closely tied to finances and the US leads the world's economy (rightly or wrongly), so therefore they follow MDY. Plenty of other sources from other industries in Japan use DMY too.

I'm in favour of adding an extra rule something like For topics closely tied to a country that uses DMY or MDY (the 2 formats used in English) then that format should be used.

And we continue to avoid local formats that are not DMY or MDY from prose, using the existing first-come rule for anything else.  Stepho  talk  06:06, 19 June 2024 (UTC)

Yeah, that would be fine with me too. Broaden the "close ties" rule, but only for cases where DMY or MDY are locally dominant. Gawaon (talk) 06:22, 19 June 2024 (UTC)

As for duplicating discussions: I think this is the best place to have this discussion, since it's the talk page of the page where the rule is formulated. Gawaon (talk) 06:23, 19 June 2024 (UTC)

I think this would be fine. Remsense诉 06:33, 19 June 2024 (UTC)

Do you mean the proposed "should generally match the one most commonly found in English-language sources from that country" wording? Gawaon (talk) 07:27, 19 June 2024 (UTC)

Yes. Remsense诉 07:28, 19 June 2024 (UTC)

Hmm, the more I think about it the more I think that that particular wording would be highly impractical to actually use. We know that DMY is dominant in Italian-language publications, but it would shift the burden to English-language publications coming out of Italy. Which are those, and how do we find them? Do we have to make statistics on English-language publications from (say) Ethiopia before we can write about topics related to that country? Gawaon (talk) 07:36, 19 June 2024 (UTC)

I don't see it as that problematic? Something like If there is a clear preference in English-language publications from the country, use that. If not, defer to the choice of the first main contributor. Maybe you see clear as a qualifier that will just be argued over, but I think it works as a safety valve here? Remsense诉 07:48, 19 June 2024 (UTC)

Oh no, I've just realized that both English People's Daily and Xinhua use MDY. What have I done! SCMP uses DMY though. Remsense诉 07:53, 19 June 2024 (UTC)

Right, so there we have one publication that uses one style and two that use the other one. Is that a "clear preference"? Almost certainly not – just find another publication and the score might be balanced. Also, do you know which date style English-language publications from Italy prefer? Even if you know (certainly only after doing your research, since you can't know without) where would the results of this WP:OR be documented so that others can know too? And why should we suddenly be expected to do OR here, which in Wikipedia is otherwise forbidden? Gawaon (talk) 08:32, 19 June 2024 (UTC)

Aye, I think I've now come around to EEng's formulation. Remsense诉 08:33, 19 June 2024 (UTC)

• This suggestion ("a country that uses DMY or MDY") is flawed for several reasons. First, it would make the English dependent on the patterns of a non-English language (i.e., follow the patterns of Korean, Finnish, etc. when writing about Korea, Finland, etc. in English). Second, many countries are not monolingual, and so the editor would need to choose which foreign language to imitate in English (note that it is languages that use DMY, MDY, YMD, etc., not countries per se). Third, it raises additional issues involving subordination of English to foreign languages (for example, Slovenian does not use the serial/Oxford comma, and so by analogy the English serial/Oxford comma would be forbidden in articles about Slovenia or Slovenian topics). Fourth, this places an onus on editors to conduct original research on languages: who really wants to study date format in Tucano or Khoekhoe before editing English-language articles about them? If the suggestion refers to "English-language sources from that country", this raises the additional burden of more original research (determining which English-language sources from county X are representative or dominant) and the problem that English-language sources produced in countries where English is not a native language are not reliable sources of standard English usage. The status quo at MOS:DATETIES and MOS:DATERET has worked well for years and should be retained. Doremo (talk) 07:35, 19 June 2024 (UTC)

  The status quo at MOS:DATETIES and MOS:DATERET has worked well for years and should be retained – Amen. There are two issues here:

  • Question 1: Was my edit [4] a substantive change, or merely a clarification of what was undoubtedly both the intent of the guideline and the (almost) universal understanding of it?
    Answer: Gawaon (commenting above) has it right: my change was (if I do say so myself) very clearly just expressing what the current guidelines are meant to express, just didn't quite as clearly because (I suppose) nobody thought that the brief backreference to the more detailed language in DATETIES would be misinterpreted.
  • Question 2: Instead of changing DATEVAR/DATERET's "country" to read "English-speaking country" -- thereby making its wording consistent with DATETIES -- should we instead change DATEVAR's "English-speaking country" to just "country", so that everything now just says "country"?
    Answer: This would be a disaster. The reason DATEVAR/DATERET and DATETIES are what they are (i.e. the test is English-speaking country, not just country -- even if DATERET is elliptic on that point) is this:
    • American editors (for example) find it dissonant to read that Roosevelt died "12 April 1945", while British readers feel the same about Churchill dying "January 24, 1965". The strong-ties provision says what to do in those cases, and edit-warring is avoided.
    • But what about Philip II of Macedon? Should he die "21 October 336 BC" or on "October 21, 336 BC". Should we use strong ties to figure that out? If so, are his ties to Macedonia, which doesn't exist anymore? Greece, maybe? OK, let's say we eventually settle on Greece -- then we have to research, and maybe argue about, which date format is used in Greece. And for what? Greek readers are reading the Phillip article on the Greek Wikipedia, not ours. We're not going to get a lot of editwarring over Phillip's date format.
    • This is why the guideline recognizes only ties to English-speaking countries: it's a restricted set of articles where "strong ties" are relatively easy to determine, where the associated country's date format is well known, and where editwarring to "correct" any Roosevelt-Churchill dissonance previously described is relatively likely. None of that applies to Phillip, and that's why the "first major contributor" test is the path of least resistance for that article (and other articles with no strong English-speaking country ties). (This isn't the best explanation I've ever given in my life, but it's the best I have time for.)

  The purpose of the guideline is avoid style churn and editwarring, not to have the "just right" format for articles about Ethiopia. The idea that we're going to debate the clear preference in English-language publications from the country is either a joke or part of a plot to destroy Wikipedia from the inside. I modestly propose that we adopt my extremely excellent edit (linked earlier) -- which doesn't actually change anything, but rather clarifies what already exists -- and drop this mad idea of changing "English-speaking country" --> "country", which would open a Pandora's box to no benefit at all. All in favor? EEng 08:45, 19 June 2024 (UTC)

  In favor. Restore the clarification [5] by EEng and maintain the status quo. Doremo (talk) 09:13, 19 June 2024 (UTC)

  Support the status quo ante (DATETIES applies only to English-speaking countries and DATERET applies in all other cases). Also support date formatting choices for readers (like we had 20 years ago). —Kusma (talk) 10:11, 19 June 2024 (UTC)

  In favour, let's keep the status quo, but including EEng's clarification which (while not changing it at all) makes misreadings less likely. I wasn't opposed to changing the rules to encourage DMY for countries where that's locally the default (many European countries at least), but making a clear-cut rule of out that seems more trouble than it's worth. Gawaon (talk) 10:43, 19 June 2024 (UTC)

  I say just so to EEng's edit at 8:45 in the morning on the 19th day of June in the year of our Lord 2024, Greenwich Mean Time. Jc3s5h (talk) 11:47, 19 June 2024 (UTC)

  Shirley you mean UTC. GMT went out with the horse and buggy. Jeesh. EEng 17:50, 19 June 2024 (UTC)

  While I realise you are joking, Mr Feynman, just pointing out that Greenwich Mean Time is still a thing. Dondervogel 2 (talk) 18:38, 22 June 2024 (UTC)

• As stated by others, the purpose of a style guide is to make arbitrary style decisions once, so they don't have to be debated repeatedly. The guidance on strong national ties and retaining the initial variant in one sense acts against this principle, but it tries to avoid needless churn by allowing editors interested in a given topic to use what would be a natural format for them. Having to evaluate the preferred date format on a country-by-country basis for English-written texts in that country just opens up the door further for more debate, with little benefit since all these formats are understood by all readers, even if it's not what they're most used to. isaacl (talk) 14:03, 19 June 2024 (UTC)

  Why couldn't you have posted your short, incisive explanation last night, thus preempting me from inflicting my long, rambling post on everyone? EEng 16:06, 19 June 2024 (UTC)

  It's all part of the process—you ramble, I ramble, I realize I'm wrong, we all grow a little bit. Remsense诉 16:45, 19 June 2024 (UTC)

  It takes a Wikivillage to raise an editor. EEng 22:16, 19 June 2024 (UTC)

Going once... EEng 09:00, 21 June 2024 (UTC)

Going twice... EEng 06:08, 22 June 2024 (UTC)

I repeat - we should change "English-speaking country" --> "country", given that certain non-English language countries do have specific date formats which are appropriate for the English-language Wikipedia (see e.g. Date and time notation in Italy). GiantSnowman 06:20, 22 June 2024 (UTC)

How about actually engaging with the objections made to this idea by various editors above? Gawaon (talk) 06:51, 22 June 2024 (UTC)

Nobody has explained why topics related to non-English language countries (of which we probably have at least dozens!) should not have sensible and appropriate date formatting. GiantSnowman 10:13, 22 June 2024 (UTC)

Well of course nobody has explained why topics related to non-English language countries should not have sensible and appropriate date formatting, because nobody is advocating that topics related to non-English language countries should not have sensible and appropriate date formatting. What we are doing instead is discussing what constitutes "sensible and appropriate date formatting" -- except you, who just say over and over what you want.

So I'll repeat Gawaon: How about actually engaging with the objections made to this idea by various editors above? EEng 14:42, 22 June 2024 (UTC)

It's quite difficult to engage with people who accuse their opponents of being "part of a plot to destroy Wikipedia from the inside". GiantSnowman 14:45, 22 June 2024 (UTC)

And if that accusation had actually been made, that would be understandable. For my part, I find it difficult to engage with someone who uses feigned (or -- worse -- actual) inability to grasp hyperbole as an excuse not to engage the detailed, careful reasoning of his or her fellow editors. EEng 21:44, 22 June 2024 (UTC)

I don't normally participate in debates about date formatting, but something attracted me to this one because I can't help but agree with GiantSnowman's view, that MOSNUM can do better than say "choose whatever date format you want". It has been pointed out that the whole point of a style guide is to provide a norm, even when (or perhaps especially when) there is no precedent for that norm. "Why?!?" I here you all ask (all except GiantSnowman, that is). Well, because that is what the style guide is for. Its whole raison d'etre is to facilitate a harmonised encyclopaedia by specifying such norms. Why would that not apply to articles that have no clear attachment to an English speaking country? None. None at all. Dondervogel 2 (talk) 18:49, 22 June 2024 (UTC)

Let's see...

• Why would that not apply to articles that have no clear attachment to an English speaking country? – Because it would require determination of the strong ties between 1,000,000 articles topics (literally -- and that's a conservative minimum) and countries, and 200 debates on what the right date formats are for the various countries, and a way to memorialize the result of those debates, and editors to consult that archive every goddam time they write an article related to some obscure country -- all to no benefit. See Gawaon's post just above, and my long post before that. EEng 21:44, 22 June 2024 (UTC)

I am not arguing for determining local customs in non-English speaking countries when writing in English. I accept that is unworkable. Just pick either DMY or MDY and apply it to all articles without a strong connection to one or other. Dondervogel 2 (talk) 22:55, 22 June 2024 (UTC)

My position on this has shifted since reading List of date formats by country, which suggests an overwhelming preference for DMY outside North America. A reasonable rule might be "pick DMY unless there is a good reason to prefer MDY". Permissible "good reasons" could then be listed, including subjects closely associated with USA. Dondervogel 2 (talk) 16:31, 23 June 2024 (UTC)

Yes, for example Philippines uses MDY in my experience, due to historical links to US. But in Europe, I pretty much only ever see DMY. GiantSnowman 16:41, 23 June 2024 (UTC)

• It has been pointed out that the whole point of a style guide is to provide a norm, even when (or perhaps especially when) there is no precedent for that norm. – False. As expressed by the brilliant author of WP:MOSBLOAT:

Something belongs in MOS only if (as a necessary but not sufficient test) either:

• There is a manifest a priori need for project-wide consistency (e.g. "professional look" issues such as consistent typography, layout, etc. – things which, if inconsistent, would be significantly distracting, annoying, or confusing to many readers); or
• Editor time has been, and continues to be, spent litigating the same issue over and over on numerous articles ...

The purpose of MOS is absolutely not to go out of its way to prescribe stylistic choices just to fill a vacuum.

EEng 21:44, 22 June 2024 (UTC)

I'm not arguing for inventing a rule where one is not needed. I had the impression that editor time is being wasted by edit warring between DMY and MDY. Was my impression incorrect? Dondervogel 2 (talk) 23:04, 22 June 2024 (UTC)

Yes there has been editwarring -- by GiantSnowman [6] [7] [8] [9] [10] [11], based on his logically impossible interpretation that where DATEVAR/DATERET says "strong national ties", it means ties to any country whatsoever, rather than being an elliptical backreference to DATETIES's (immediately preceding) "strong ties to a particular English-speaking country". (BTW I'll just point out MOS:TIES, on the main MOS page, which also restricts its applicability to English-speaking countries only.) At this article talk page you'll see him asserting that "DMY is used for Italian topics" -- a statement for which there's no basis whatsoever, because for pages not tied to a particular English-speaking country, MOS doesn't ask editors to go research and argue about what format Italy or Botswana or Romania use -- it specifies first come, first serve. Giant Snowman apparently didn't understand that, and now that he does he wants to change it. He can propose that, but in the meantime I'm just trying to make the sure current guideline can't be misinterpreted as GS misinterpreted it. EEng 00:20, 23 June 2024 (UTC)

Unsure if you are continuing to ignore Date and time notation in Italy deliberately??? GiantSnowman 10:29, 23 June 2024 (UTC)

But do we have similar pages for all the 200 countries of today's world? And what about historical countries that no longer exist, and their conventions? Gawaon (talk) 10:44, 23 June 2024 (UTC)

See Category:Date and time representation by country. If a country has no established format, then nothing changes, does it? GiantSnowman 10:53, 23 June 2024 (UTC)

Thank you! And to make it perfectly clear, I am NOT proposing implementing just any date format - just the ones already established at en.wikipedia, being DMY or MDY. GiantSnowman 18:58, 22 June 2024 (UTC)

And neither is anyone else proposing anything other than DMY or MDY. EEng 21:44, 22 June 2024 (UTC)

Wrong. Someone has suggested YMD might be used. GiantSnowman 10:28, 23 June 2024 (UTC)

Right, and inevitably, because it logically follows from your proposal to simply remove "English-speaking" from DATETIES. Apparently you didn't mean it, but that that time you hadn't clearly explained what you meant, and so far you haven't proposed a wording that would actually achieve what you're apparently trying to achieve, namely allowing TIES to apply to any country that uses DMY or MDY (but not to any other). Gawaon (talk) 10:48, 23 June 2024 (UTC)

What's the issue with changing DATETIES from "Articles on topics with strong ties to a particular English-speaking country should generally use the date format most commonly used in that nation" to "Articles on topics with strong ties to a particular country should generally use the date format most commonly used in that nation where that date format accords with the formats in common usage on English-language Wikipedia"? GiantSnowman 10:57, 23 June 2024 (UTC)

Would be okay with me. Not sure if I would vote for it (since it would force a lot of changes with little obvious benefit), bit it's essentially the rule of thumb I use myself and I certainly wouldn't vote against it. But I guess a change of such magnitude would require an RFC or similar, and then we'll see how it goes. Gawaon (talk) 12:14, 23 June 2024 (UTC)

I don't think there would be such huge changes as feared. The majority of articles use the 'correct' format already. It's only when you have things like Americans writing articles on Italian topics (which is what started all this), meaning the original date format is out of kilter with all related articles... GiantSnowman 12:24, 23 June 2024 (UTC)

Example - Michel Fribourg being DMY for 7 years (including from article creation) even though topic is American... GiantSnowman 13:10, 23 June 2024 (UTC)

Let's go back to just Question 1

Let me see if I can untangle this. Earlier I foolishly bundled resolution of both my Question 1 and my Question 2 (both above) into a single package, which is now hung up on GiantSnowman's preoccupation with Question 2. I'd now like to re-propose resolving, first, only Question 1 by making my edit [12], which as Gawaon said was just very clearly just expressing what the current guidelines are meant to express, just didn't quite as clearly because (I suppose) nobody thought that the brief backreference to the more detailed language in DATETIES would be misinterpreted

After that's resolved then GS can argue for changing the guideline. Pinging back everyone who's participated so far: Firefangledfeathers, Remsense, Gawaon, Doremo, David Eppstein, MapReader, Kusma, Jc3s5h, Isaacl, Stepho-wrs, Dondervogel, 2 GiantSnowman, Hawkeye7. EEng 21:44, 22 June 2024 (UTC)

• Support for your edit regarding question 1: TIES should be considered only for English-speaking countries. (Americans writing about Cambodia should not be bound by whatever convention Cambodians use when writing dates). Ping @Dondervogel 2, @GiantSnowman as @EEng seems to have messed that up. —Kusma (talk) 21:56, 22 June 2024 (UTC)
• Support from me too, as might be expected. Gawaon (talk) 22:01, 22 June 2024 (UTC)
• Support from me for myself too, as also might be expected. EEng 01:48, 23 June 2024 (UTC)
• Yes on question 1: EEng's edit to DATERET to clarify that it only concerns English-speaking countries was not a substantive change, but an accurate clarification of long-standing consensus. Question 1 is only about the status quo ante, not about whether and how the consensus might change. —David Eppstein (talk) 22:07, 22 June 2024 (UTC)
• I don't have a view on question 1. Happy to abstain. Dondervogel 2 (talk) 22:50, 22 June 2024 (UTC)
• Support for your edit/clarification regarding question 1: TIES are considered only for English-speaking countries. Doremo (talk) 02:43, 23 June 2024 (UTC)
• Support that the edit clarified the current meaning of WP:DATETIES and WP:DATERET. I think the current meaning should be changed but that's question 2.  Stepho  talk  03:45, 23 June 2024 (UTC)
• I support EEng's edit, as stated above. I would be interested to see how future discussion on Question 2 goes, but the edit on the table now just clarifies the long-standing meaning of the guideline. Firefangledfeathers (talk / contribs) 03:56, 23 June 2024 (UTC)
• Oppose any change unless it is removal of 'English-speaking'. Ignoring national date formatting conventions (as shown by e.g. Date and time notation in Italy etc.) which aligns with the established formats in use on en.wikipedia (i.e. DMY and MDY) is a nonsense. GiantSnowman 10:31, 23 June 2024 (UTC)

  It's not a (substantive) change, though, just a clarification. Just saying. Gawaon (talk) 10:52, 23 June 2024 (UTC)

  Turning from 'country' to 'English-language country' is not just a clarification. GiantSnowman 10:54, 23 June 2024 (UTC)

  It is, though, because it's clearly just a backreference to DATETIES (just above) which always had "English-speaking country". But I bet you know this as well as anybody here, you just don't like to admit it. Gawaon (talk) 11:06, 23 June 2024 (UTC)

  Why is DATERET being "clarified" to match DATETIES, and not the other way around? GiantSnowman 11:08, 23 June 2024 (UTC)

  Because DATETIES is the actual rule, and the other one just points back to it to make it clear that there is no conflict between what these two sections say. DATERET is about retaining the date style, not about changing it. Gawaon (talk) 12:11, 23 June 2024 (UTC)

  Then, as I have said, remove 'English-speaking' from DATETIES. GiantSnowman 12:25, 23 June 2024 (UTC)

  See WP:IDHT. Why don't you hold your breath until you turn blue? That might convince people. EEng 18:28, 23 June 2024 (UTC)

• As Doremo wrote, "Support for your edit/clarification regarding question 1: TIES are considered only for English-speaking countries." Jc3s5h (talk) 00:52, 24 June 2024 (UTC)
• Support - this was simply a clarifying edit. --User:Khajidha (talk) (contributions) 11:36, 24 June 2024 (UTC)

Hey, GiantSnowman, do you agree that the consensus at this point is to reinstall my original edit? EEng 14:19, 24 June 2024 (UTC)

Yes. GiantSnowman 17:47, 24 June 2024 (UTC)

And after only 140 posts totaling 45K! So it's not like huge amounts of editor time got wasted arriving at the obvious. EEng 22:35, 24 June 2024 (UTC)

That's not fair. What was obvious to you was not obvious to others, including me. No one is disputing the consensus, but the editor discussion was needed IMO to achieve that consensus. Dondervogel 2 (talk) 23:40, 24 June 2024 (UTC)

Sure it's fair. You're to be excused because, as you mentioned, you haven't been involved in date format–related issues much before. GS has, and should certainly have known (and, for all I can tell, did know) the meaning of the guideline. If he hadn't insisted on repeatedly reverting multiple other editors in order to block the clarifying change which all other watchers understood to be nonsubstantive, none of this would have been necessary. He should have known better. Then, after it was explained over and over why "Question 1" was separate (and precedent to) "Question 2", he insisted on using his butthurt on Question 2 to attempt to block what, by then, was perfectly obviously the inevitable outcome on Question 1. Bad job. EEng 00:02, 25 June 2024 (UTC)

insisted on repeatedly reverting multiple other editors in order to block the clarifying change which all other watchers understood to be nonsubstantive, Hopefully no one will insist this discussion must be Formally Closed before the edit can be restored... JoelleJay (talk) 04:42, 4 July 2024 (UTC)

And of course this [13] (though wisely withdrawn [14]) didn't add to the festive atmosphere either. EEng 15:13, 25 June 2024 (UTC)

Why raise it then, other than to add to the sourness? GiantSnowman 16:23, 25 June 2024 (UTC)

Because it shows that, in addition to wasting a huge amount of editor time in pursuit of your personal hobbyhorse, your perspective is so distorted that it actually occurred to you that I might have used some dumb trick to gain the upper hand in a discussion where, quite obviously, my hand was already so upper that the Hubble telescope would be needed to see it. "Ha! I'll just accidentally fail to ping these guys so maybe they'll forget that a discussion they posted to two hours ago is still going on." Right. I'm crafty that way. EEng 16:47, 25 June 2024 (UTC)

Stow the 'tude please. GiantSnowman 17:31, 25 June 2024 (UTC)

'tude? You wanna see 'tude?

For years you've been told (and not just by me) that your stupid, broken date-fiddling script changes stuff in violation of MOS, but have you learned your lesson? Fixed the script? Found something useful to do? Nooooo. That's your hammer and for you article space is a collection of nails.

In 2020, you used your broken script to screw up a bunch of stuff in a particular article. In reverting you [15], I said (with amazing courtesy -- for me, anyway) ...

Please be more careful in the use of automated tools. None of these changes is appropriate: you've changed the established format of access dates in violation of WP:DATERET, removed a hidden note intended for future article improvement, and even changed verbatim quotations and titles of sources!

Let me repeat that: you changed verbatim text in quoted material and titles of cited articles, and even "fixed" the date inscribed on a physical object. Obviously you weren't paying attention. Then, unbelievably, last year you came back to the same article and did the same things. This time I was more forthright [16]:

User:GiantSnowman, this is the third or fourth time in the last year that I've caught you using some broken script to fuck up dates in literal quotations, tamper with articles' established date formats, and so on. What the hell do you think you're doing? You're an admin and should know better. And admin or not, I'm seriously considering proposing you be banned from making script-assisted changes.

It's like you have ONE job on this lousy project, it's stupid, but you're going to do it whether it improves anything or not. (And to sweeten the pot, you edit-warred with me and another admin -- one who takes the time to read and understand guidelines and documentation -- about the article subject's middle initial [17][18][19][20].)

And now here you've wasted a dozen people's time with your mixed-up reading of MOS. No wonder I'm pissed off at you.

There are many kinds of 'tude, dude. One of them is continuing to use your hobbyhorse script when you've had it rubbed in your face over and over that it breaks stuff. And you obviously aren't reviewing the script's changes before saving, in violation of the most basic rule for automated editing. So you stow the fucking 'tude, bro. Stop using your broken script until you can find someone to fix it for you; I'm sure there are plenty of soccer statistics you can occupy yourself updating. Peace out. EEng 23:02, 27 June 2024 (UTC)

Firstly, it's not my script, and I repeatedly raise improvement suggestions for it/flag bugs. That doesn't fit your agenda though, does it?

Secondly, the above rant (and that's all it is) reflects so, so poorly on you. I'm actually slightly embarrassed for you. There are far better ways of expressing yourself and raising concerns about a script than acting like this. GiantSnowman 11:16, 29 June 2024 (UTC)

As usual, you've used feigned shock at colorful expression to distract from the substantive issue, which is that your script (which is what it is when it's in your hands) makes changes against guidelines and policy, you've been told this for years, and yet you keep on using it. If you've asked for those problems to be fixed, and they haven't, please link to where that conversation is happening so I can participate.

Save your embarrassment for yourself. You need a full supply. EEng 18:31, 29 June 2024 (UTC)

I hereby solemnly declare this discussion closed. Thanks everyone for your participation! Gawaon (talk) 11:39, 29 June 2024 (UTC)

Templatizing date format

With regard to the discussion above on date format, I have a technical proposal. Under Preferences > Appearance there's a "Date format" option, allowing editors to select DMY, MDY, or YMD for their personal display. For example, this works with the templates {{Birth date}} and {{Death date}}; if the parameter df= or mf= is not specified, it will display based on the user's set preference. However, it does not seem to work with the template {{Date}}. If the "Date format" preference were enabled for the template {{Date}} (and the parameters df= or mf= deprecated, or overridden by the "Date format" preference), a bot could presumably templatize all dates, and users that prefer DMY or MDY would always see dates displayed in their preferred format—and this would presumably overcome the objections of anyone committed to a particular date format. There would be some details to work out, such as dates without years, ranges of dates, and so on, as well as protecting date formats in quotes. I am not technically able to work on this (and there may be pitfalls I haven't anticipated), but it seems like it could be considered as a solution. Doremo (talk) 08:02, 24 June 2024 (UTC)

See User:Dabomb87/Summary of the Date Linking RFCs. An earlier method to let users see dates in their preferred format was to link the date to the articles about the day of the year and the year, and the system would then attempt to display in the format set in the user's preferences. This was ripped out as an utter failure. One of the chief reasons was that readers with no account couldn't set a preference. Editors usually did have accounts. So the dates in an article would be a mish-mash of different formats, which would (presumably) annoy most readers but wouldn't be noticed by the editors who could fix it. Jc3s5h (talk) 13:24, 24 June 2024 (UTC)

In addition, I challenge Doremo's claims "For example, this works with the templates Birth date and Death date; if the parameter df= or mf= is not specified, it will display based on the user's set preference."

But the Template:Birth date documentation for the Birth date template states "The default output of this template is to display the month before the day." Please prove that your claim is correct. Jc3s5h (talk) 13:30, 24 June 2024 (UTC)

If a previous attempt was poorly executed, it doesn't mean that someone with better skills couldn't execute it better. I presume that readers with no account would view a consistent default template output if all dates were templatized. If I look at an infobox with {{death date|1807|6|26}} (e.g., here: John Smith (antiquary)) and my "Date format" preference is set to MDY, it displays as "June 26, 1807". At the same time, the template {{date|1807-6-26}} in the lede displays as "26 June 1807". I don't know if that's true for everyone that looks at that page. Doremo (talk) 13:42, 24 June 2024 (UTC)

Jc3s5h is correct (I see now that I misread the part about the default output). I agree that the "Date format" preference does not affect the display of the {{Birth date}} and {{Death date}} templates. I do not know if "Date format" preference can be made to affect displayed output on a template; it's a technical matter beyond my skills. Doremo (talk) 14:14, 24 June 2024 (UTC)

IIRC certain templates (certain citation templates for sure) understand and obey Template:Use MDY dates and Template:Use DMY dates. Not sure what other templates do. Those features are a far cry from automagically formatting dates in running article text. Yes, it would be possible to wrap all dates, everywhere, in some special template, but see my comments lower down in this thread. EEng 21:28, 24 June 2024 (UTC)

People who were heavily involved in Wikipedia development were involved in the date linking fiasco and ultimately decided recognizing date preferences for readers who were not logged in would create an unacceptable performance degradation. Jc3s5h (talk) 14:39, 24 June 2024 (UTC)

• Trust me on this one. Nothing like this is ever going to happen. And if it did, it would represent a massive waste of development resources. There are many, many truly important things we've been waiting years and even decades for, and this isn't one of them. EEng 21:21, 24 June 2024 (UTC)
• It would complicate caching, for little benefit: readers are not confused by seeing either format, even if it's not the one to which they're most accustomed. isaacl (talk) 01:15, 25 June 2024 (UTC)
• Thanks for the various feedback above; I accept that it's not a viable option. Doremo (talk) 03:35, 25 June 2024 (UTC)

Age ranges

An experienced editor has changed "2,251 children are in the age group of 0–6 years", to "2,251 children are in the age group of zero–six years" with an edit summary of MOS:NUMERAL. This seems extremely awkward, are children referred to as "Zero" years old?, but "nought-six" is also unnatural. However, it does seem to comply with the wording of MOS:NUMERAL, whereas 0-6 does not.
This may seem a minor point, but 0-6 is the range used in the census of India, and many other countries, so would affect tens of thousands of articles. Any comments/clarification of the guideline appreciated. - Arjayay (talk) 09:49, 27 June 2024 (UTC)

I would suggest something like "age group of up to six years" or "... six years or less". Gawaon (talk) 10:35, 27 June 2024 (UTC)

Irrespective of context, to write "zero–six" of anything looks mighty weird. It should always be "zero to six". Dondervogel 2 (talk) 10:49, 27 June 2024 (UTC)

If the article is also considering other age ranges (eg children aged 7–14, students aged 18–25) then I'd say we should use numbers throughout, per Comparable values nearby one another should be all spelled out or all in figures and for clarity in presenting statistics. If we're going to use words then it should be phrased appropriately per Gawaon or Dondervogel2 or "aged up to six" and suchlike, not with a mere replacement that's neither one thing nor the other. NebY (talk) 10:56, 27 June 2024 (UTC)

Inconsistency

What do I do at Masaya Kimura (singer)? The subject is Japanese so MOS:ENGVAR is irrelevant. The article was published with "Use British English" and "Use mdy dates" which doesn't make sense because dmy is the norm in the UK. [21] And then later on, someone came by and replaced "Use British English" with "Use American English" AND "Use Canadian English" without leaving an edit summary explaining why. [22] So I guess the question is do I change it back to Use British English per MOS:RETAIN and does that mean I retain "Use mdy" or can I change that to "Use dmy"?  Bait30  ^{Talk 2 me pls?} 07:57, 30 June 2024 (UTC)

Per MOS:RETAIN and MOS:DATERET, "Use British English" and "Use mdy dates" should both be retained. However, if you think that DMY dates are preferable, you can ask on the talk page if anybody would object to such a change, and if nobody does (within a week or so), go ahead and change it. Gawaon (talk) 08:29, 30 June 2024 (UTC)

MDY is standard for Japanese articles in my experience. GiantSnowman 09:30, 30 June 2024 (UTC)

There wasn't any problem of inconsistency. On Wikipedia, using British English doesn't require using DMY dates; as MOS:DATETIES says, For any given article, the choice of date format and the choice of national variety of English (see Wikipedia:Manual of Style#Strong national ties to a topic) are independent issues. So as Gawaon says, "Use British English" and "Use mdy dates" should both be retained (barring consensus to the contrary) and as GiantSnowman says, MDY is normal for articles about Japanese subjects. NebY (talk) 15:15, 30 June 2024 (UTC)

Everything you say is correct, except for the idea that there's any date format "standard", or engvar "standard", for Japanese subjects (or any other subject not strong-tied to an English-speaking subject). EEng 18:19, 30 June 2024 (UTC)

Hence my use of "normal" rather than "standard". NebY (talk) 18:48, 30 June 2024 (UTC)

I didn't mean any criticism of you. It's just I'm a bit, um, hot under the collar because of time wasted along these lines elsewhere on this page recently. EEng 19:52, 30 June 2024 (UTC)

Right, there's no requirement that American English be coupled with MDY or that British English be coupled with DMY. Gawaon (talk) 15:42, 30 June 2024 (UTC)

As far as I can tell, there is nothing in the "Manual of Style" or any of the related pages saying that MDY is normal for articles about Japanese subjects. Perhaps the basis of this statement is that one or more of the editors of this thread have read a bunch of English Wikipedia articles about Japanese subjects and noticed the predominant date format is MDY. Or maybe the editors asserting this have some other basis for the statement. Personally, I haven't read many articles about Japanese subjects so have not formed an impression about what date format is most common. Jc3s5h (talk) 15:55, 30 June 2024 (UTC)

Yes, it's from experience, something you acknowledge you don't have in this area. GiantSnowman 16:29, 30 June 2024 (UTC)

Luckily, your experience and Jc3s5h's lack of experience are irrelevant: there's no "standard" for articles not strong-tied to an English-speaking country. A dozen editors just spent a week, on this very page, getting you to understand that, and yet here you are playing the "experience" card as a cover to keep spouting misinformation. Meanwhile, of course, you haven't supplied the link requested here [23], though you've made some edits since I made that request (which included a ping to you). Any chance you can get around to that sometime soon? EEng 18:19, 30 June 2024 (UTC)

I also have years of experience of dates in Asian countries and it tells me that MDY is not the norm in Japan. Most Asian countries use YMD in their native language. In English, businesses tend to use either the date format of their biggest customer. When this is not the most important thing then they tend to use the format used by their teacher. If they (or their teacher) studied in England then they use DMY. If they studied in the US then they use MDY. It's very much an arbitrary thing. It's irrelevant in this case anyway but I bring this up because I have seen you say this before and I want you to know that it is not a valid argument.  Stepho  talk  21:31, 30 June 2024 (UTC)

It won't sink in, I assure you. EEng 00:23, 1 July 2024 (UTC)

Quite possibly true. But I don't want him to say "I mentioned this multiple times before and nobody objected."  Stepho  talk  03:00, 1 July 2024 (UTC)

I realize now that you didn't have the pleasure of following last week's discussion. See #Discussion on other talk page and project. Delicious. EEng 03:06, 1 July 2024 (UTC)

Ahh I missed that sentence under MOS:DATETIES, thanks.  Bait30  ^{Talk 2 me pls?} 18:26, 30 June 2024 (UTC)

Wikipedia date formats

• I agree with Gawaon that MOS:RETAIN and MOS:DATERET apply to Masaya Kimura (singer) and that "strong national ties" does not apply because he appears to have no strong tie to an English-speaking country. As it was created with UK English but mdy dates, consensus on the article talk would be needed to change either of those. That choice of styles is idiosyncratic but not actually inconsistent as there is no logical tie between dialect and date style. Inconsistency in style from other members of similar groups could be a valid argument for a style change, but a matter for the article talk rather than here; I don't think we want to legislate that sort of thing as a global rule, because it's too nitpicky to make a good rule. —David Eppstein (talk) 19:13, 30 June 2024 (UTC)

  Yes, and just to use this as a teachable moment, because of the time wasted on stuff like this recently: the budding debate, a bit above, about who has more experience in judging what is normal or standard in a give topic area is exactly the reason MOS:DATETIES and MOS:DATERET specify that, in general, there is no normal or standard to debate about: it's first come, first served, nothing to debate, doesn't matter what various editors think their experience is. EEng 19:59, 30 June 2024 (UTC)

  Agreed. Tony (talk) 05:15, 1 July 2024 (UTC)

Adjectival ordinals for centuries and millennia BC

This is subtle and requires several simultaneous conditions, but I run into it enough that I think it might be worth a sentence of explication. I was also sure before, but I'm less so now, having reread the relevant guidelines.

With ordinals e.g. 2nd century BCE and 1st millennium BC, are we meant to use a hyphen or an en dash in the adjectival form? It's multiple words, but they're not quite independent wholes as described in MOS:ENBETWEEN; the era designator also isn't quite an affix as per MOS:AFFIXDASH. Remsense诉 22:21, 30 June 2024 (UTC)

• I'll activate our team of rabbis. EEng 00:18, 1 July 2024 (UTC)
• I can't say I've ever been confident on when to use one or the other in a lot of cases, but I've used hyphens (the doohickey next to the zero on my keyboard) many times in phrases like "a 2nd-century coin" and no one's complained yet. SchreiberBike | ⌨  01:38, 1 July 2024 (UTC)

That's clearly correct. But it begins to look weird when it gets to pre-2nd-century-BCE coins or post-World-War-II morality or Empire-State-Building-sized project. I think that's what the query is about. I used to know how to handle stuff like that but I'm too tired to think now -- and IIRC it sometimes involves en edashes (or, you might say, it's an en-dash–related issue) and I'm not up for an en-dash argument right now. EEng 01:50, 1 July 2024 (UTC)

Sorry for writing up another puzzle for folks! 2nd-century (adj.) is very much correct. I'm curious about how to write 2nd-century BC (adj.) Options seem to be:

1. 2nd-century BC – It's likely that no one would ever get mad at this; it seems the cleanest.
2. 2nd–century BC – Seems wrong, especially when used alongside AD/CE centuries that use a hyphen.
3. 2nd-century-BC et al. are clearly unacceptable; I think this is probably a rule of thumb for adjectival phrases longer than two words.

Well, I guess I've answered my own question by writing it down properly. Dangit. Remsense诉 02:01, 1 July 2024 (UTC)

Oh, I guess this isn't totally worthless—might it be worthwhile to include an example with BC next to the ones without it? Remsense诉 05:21, 1 July 2024 (UTC)

So your proposal is "2nd-century BC" (1)? Looks fine for me too. Gawaon (talk) 06:25, 1 July 2024 (UTC)

That's right and in agreement with Fowler's Modern English Usage, in particular that

• we use hyphens to avoid misinterpretation (a second-century coin, not a second century coin).

• Avoid creating words with multiple hyphens. Burchfield suggested that phrases such as early-nineteenth-century poets can always be written as poets of the early nineteenth century instead, which, though longer, is probably easier for readers to process. Similarly ... instead of a nuclear-weapon-free world ... a world free of nuclear weapons. Hyphenating should not become burdensome.
  — hyphen, 4th edition

NebY (talk) 11:17, 1 July 2024 (UTC)

Deprecating "Since"

The advice in MOS:SINCE is contradictory in its treatment of the word "since". The goal of the section is to avoid phrases that are likely to go out of date, but it includes "since" in its recommended examples despite its time-dependency. Saying "She has been the director since 2010" indicates she is still the director, and so will go out of date. I propose the following edits. This leaves "since" as recommended only in the sentence specifically about current and future events, where the use should be flagged for time-dependency.

Except on pages that are inherently time-sensitive and updated regularly (e.g. the "Current events" portal), terms such as now, today, currently, present, to date, so far, soon, upcoming, ongoing, since and recently should usually be avoided in favor of phrases such as during the 2010s, since 2010, and in August 2020. Wording can usually be modified to remove the "now" perspective: not she is the current director but she became director on 1 January 2024; not 2010–present or since 2010 but beginning in 2010 or since 2010. Terms likely to go out of date include best known for, holds the record for, etc. For current and future events, use phrases such as as of November 2024 or since the beginning of 2024 to signal the time-dependence of the information; use the template {{as of}} (or {{updated}}) in conjunction.

(See the back and forth recent edits to MOS:RELTIME for background.)--Trystan (talk) 15:20, 13 July 2024 (UTC)

I don't think this is necessary or advisable. Since by itself doesn't imply anything about the current state. She has been the director of X since 2010 implies that she still holds that position, but because of the tense, not because of the since. Since 2010 she was the director of X, but she resigned in 2022 after a controversial tweet is perfectly possible too. Since by itself is no more likely to go out of date than in, during, or until. Gawaon (talk) 15:54, 13 July 2024 (UTC)

That sentence reads strangely to me. I might say Roosevelt was president from 1933 until his death or Roosevelt had been president since 1933 if speaking about a particular point in time during his presidency, but never Roosevelt was president since 1933 until his death. Is this something that varies between dialects?--Trystan (talk) 17:28, 13 July 2024 (UTC)

Possibly. The Cambridge Dictionary defines since as: "from a particular time in the past until a later time, or until now". I wouldn't use since ... until either, but the example I gave feels natural enough to me. Let's see what others think. Gawaon (talk) 18:14, 13 July 2024 (UTC)

There are far too many unproblematic usages of this phrasing to deprecate.

• "France had colonial possessions, since the beginning of the 17th century"
• "Since the passage of [the Parliament Acts of 1911 and 1949], the House of Commons of the United Kingdom has become the dominant branch of Parliament"
• Austria "inhabited since at least the Paleolithic period"
• "'to the City', the appellation Greek speakers used since the 11th century to colloquially refer to" Istanbul
• Association football "continued to be played by women since the time of the first recorded women's games in the late 19th century"
• Mathematics "until the 16th and 17th centuries, when algebra and infinitesimal calculus were introduced as new fields. Since then..."
• Boats "have been used since prehistoric times"

Beside that, in my experience, discouragement of time-dependent phrasing often merely causes the recentism of an article to remain present but buried in circumlocutions, making it harder to find and keep up to date. It is the recentism, not the specific wordings used to express time relations, that we should prefer to avoid. —David Eppstein (talk) 18:48, 13 July 2024 (UTC)

I do agree with Trystan that "since .. until" reads strangely, and I wouldn't use it. Gawaon, Cambridge's "until a later time" surprises me (but Cambridge sometimes does); it's not supported by examples or shared by Merriam-Webster or Chambers online, or the old print OED, or Collins in print or online, and for your example I'd automatically avoid since and prefer e.g. "Beginning in 2010" or "From 2010 she was .. but resigned". David, those are all good examples but of matters that will remain so indefinitely, rather than something we can reasonably expect to end soon if it hasn't already e.g. "since 1980, the finance manager has been ...". Still, I take your point about recentism and that deprecating "since" wouldn't achieve much. On the other hand, might it not be better to stop recommending it as MOS:SINCE does now? NebY (talk) 19:46, 13 July 2024 (UTC)

Yeah, I admit there's a fairly strong "until now" tendency in since I hadn't sufficiently appreciated above. As for no longer recommending it, I'm sceptical since I'd say that it still has the very clear advantage of precision compared to words like currently and recently which that section is chiefly (and reasonably) advises against. And ultimately, articles that make some kind of statements about the present are more useful than those that don't, even if the risk of going out of date is the price they pay. Since 2019 she has been the director [and we believe she still is] may become outdated, but it's more helpful than In 2019 she became the director, which leaves the reader in the dark about what might or might not have happened since. Plus the first wording can easily be updated to something like From 2019 to 2023 she was the director if somebody realizes it's no longer true, while the other wording is somewhat less easy to update. Anyway, I think both wordings are fine in general and it's not the place of the MOS to discourage one in favour of the other. Gawaon (talk) 20:18, 13 July 2024 (UTC)

A vast number of articles about people, places and organisations, start Name is.... Eventually, all of these will be outdated. I don't know how this is squared with MOS:NOW, but I don't think that changing these would make articles better. I certainly agree that it is more useful to say she is the director than she became the director leaving readers to wonder then what? So while since does imply a statement that will become outdated, I don't think that avoiding it would make articles better. Mgp28 (talk) 10:01, 15 July 2024 (UTC)

...might it not be better to stop recommending it... I would agree with just taking out the two recommended examples above, without adding in the cautions against using it. Some form of updating to recognize that it does have a strong "until now" implication that places it in the class of phrases that may need to be checked for currency (unless very long timeframes are involved).

I wonder if the "until a later time" captures uses like "He had been president since 1981", where both points of time are in the past.--Trystan (talk) 22:15, 13 July 2024 (UTC)

One specific unproblematic class of usage is when writing about longer periods: in the lead of Chinese characters I've written that Following the Han, [i.e. late antiquity] regular script emerged as the result of cursive influence on clerical script, and has been the primary style used for characters since. I don't feel like I can omit the hypothetical future datedness of this statement without explicating a slightly bizarre-feeling 21st century somewhere. Remsense诉 19:52, 13 July 2024 (UTC)

There is specific guidance endorsing relative expressions for long time periods. I'm not necessarily opposed to their use for shorter periods where it is warranted, just think the guideline shouldn't suggest that "since 2010" is immune to going out of date.--Trystan (talk) 22:25, 13 July 2024 (UTC)

Notes

Using circa template only at first occurence

Is there a reason why the c. template should only be used at the first occurence in an article? To me, this rule seems weird, and it also just looks quite inconsistent. I can remember reading the guideline a long time ago, when it wasn't like that (I checked the version history and saw this has indeed not always been the case). I'm asking out of curiosity, because I can't think of any reason for it. Thanks in advance. Maxeto0910 (talk) 21:51, 14 July 2024 (UTC)

Because it brings up a tooltip to explain what it means. It's annoying to see that at every occurrence. (Honestly I think it's a little annoying to have it at all, but the one occurrence I can live with.) --Trovatore (talk) 21:54, 14 July 2024 (UTC)

The dotted underline? I understand that by comparison as I said below, but this may truly boil down to a matter of taste. Different strokes and all. Remsense诉 21:57, 14 July 2024 (UTC)

To be honest I don't really like the tooltip interface for Wikipedia at all. The little floating question mark does not seem to be that much used these days (it reminds me of — Encarta, I think? Something of that vintage anyway). I don't think Wikipedia should be proliferating UI elements, particularly ones that show up only occasionally.

And I don't really think "c." needs explanation. Give readers some credit.

That said, I can live with the one occurrence. --Trovatore (talk) 22:11, 14 July 2024 (UTC)

It's not a Wikipedia thing, it's an HTML thing. And I imagine it's distinctly less pleasant reading for those using screen readers to hear "see dot" each time. (One can disable the tooltip, but I still don't think it should be the guideline across the encyclopedia to do so.) Remsense诉 22:13, 14 July 2024 (UTC)

Ah, do they hear "circa" when the tooltip is used? Is that true for other tooltips as well? I wasn't aware of that. --Trovatore (talk) 22:17, 14 July 2024 (UTC)

Quite! See also the MDN doc for the <abbr>...</abbr> tag. Remsense诉 22:20, 14 July 2024 (UTC)

Also, not to say it's a replacement for this discussion, but since you dislike it, you could add

abbr { text-decoration: none; } to your common.css to hide them all forever. Remsense诉 22:53, 14 July 2024 (UTC)

It seems a reasonable rule, consistent with the MOS on overlinking and saving both readers and editors from a repeatedly cluttered experience. NebY (talk) 22:18, 14 July 2024 (UTC)

I also think this shouldn't be the guideline. I imagine the reason is that it's visually obtrusive à la one of the reasons against overlinking—but I simply don't think they're comparable, especially given accessibility reasons. Remsense诉 21:56, 14 July 2024 (UTC)

I agree, and I fact I wasn't aware that we are supposed to use it just once per article (or per section, maybe?). In my experience, it's most often used in captions, where it's quite reasonable to treat each caption as fairly independent of the rest of the article. I'd suggest writing something like "the use of the {{circa}} template is preferred over just c., at least for the first occurrence in a section or caption. At later occurrences, writing c. (followed by a non-breaking space) or using the {{circa}} template is preferred over ..." Gawaon (talk) 07:03, 15 July 2024 (UTC)

Or actually, because of the accessibility issue discussed above, the best course of action (and also a very simply one) is surely to recommend always using the template. Gawaon (talk) 07:08, 15 July 2024 (UTC)

I agree, if it makes the text more accessible for people using screen readers, that seems a good thing. Also, while many or most readers may not need an explanation of what c. means, the benefit of helping those who do need an explanation seems to outweigh any harm from using the template, especially as the text decoration can be hidden if particularly disliked. Mgp28 (talk) 09:37, 15 July 2024 (UTC)

I agree it's exceptionally annoying and should be deprecated in all circumstances. -- Necrothesp (talk) 13:48, 16 July 2024 (UTC)

"[Binary prefixes] are generally not to be used"... What? Why?

The section on units for bits and bytes states:

• The IEC prefixes kibi- (symbol Ki), mebi- (Mi), gibi- (Gi), etc., are generally not to be used except:
  • when the majority of cited sources on the article topic use IEC prefixes;
  • in a direct quote using the IEC prefixes;
  • when explicitly discussing the IEC prefixes; or
  • in articles in which both types of prefix are used with neither clearly primary, or in which converting all quantities to one or the other type would be misleading or lose necessary precision, or declaring the actual meaning of a unit on each use would be impractical.

And the rationale behind this is:

...consensus on Wikipedia in computing-related contexts favours the retention of the more familiar but ambiguous units KB, MB, GB, TB, PB, EB, etc. over use of unambiguous IEC binary prefixes. For detailed discussion, see WT:Manual of Style (dates and numbers)/Archive/Complete rewrite of Units of Measurements (June 2008).

I find this ridiculous. Binary units never had any justification for decimal prefixes. Why are we using outdated terminology? Continued usage of the outdated "decimal prefixes with binary meaning" means that the already bad ambiguity is continuously perpetuated, and simply adds to the confusion. While many people will say "it's unambiguous but let's not use it because people aren't familiar with it", it's exactly these people who are preventing others from becoming familiar with them.

A rule I firmly live by and tell others is analogous to Hanlon's razor, and that is: "Never assume unnecessary complexity when lack of familiarity will suffice."

Thank you. DASL51984 ^{(Speak to me!)} 14:04, 15 July 2024 (UTC) DASL51984 ^{(Speak to me!)} 14:04, 15 July 2024 (UTC)

Unhide "Binary prefixes" the little "Archives" box at the top of this very page, and you'll see that this topic has its own little series of 17 (count 'em -- seventeen!) pages of archived discussion on this. If, after reviewing those, you feel you have new arguments to offer that might change the consensus, by all means let us know. EEng 14:39, 15 July 2024 (UTC)

Yes, I've read through them. It was painful beyond recognition from the get-go, and by the end, I felt like I had lost all my brain cells.

Not only that, those discussions were all made back between 2005 and 2010, and the binary prefixes weren't well-known back then. Now, however, they are much more widely known, especially with MacOS and Linux having changed over a decade ago so that they display base-10 units but with base-10 meaning. (When will Windows catch up with reality??) DASL51984 ^{(Speak to me!)} 15:03, 15 July 2024 (UTC)

I fear that archive collection only includes discussions up to 2010. Some more recent ones can be found by searching for "binary prefix".[24] NebY (talk) 15:07, 15 July 2024 (UTC)

Totally agree with you. However I think you'll have difficulty shifting the consensus whilst the big desktop players such as Microsoft continue to use decimal prefixes. It always amuses me that some of the editors who are most determined to implement SI proceed to baulk at following the advice given by BIPM: "The International Bureau of Weights and Measures (BIPM), which maintains the International System of Units (SI), expressly prohibits the use of SI prefixes to denote binary multiples, and recommends the use of the IEC prefixes as an alternative since units of information are not included in the SI". Martin of Sheffield (talk) 14:55, 15 July 2024 (UTC)

You might want to read this case against deprecation of IEC prefixes. Dondervogel 2 (talk) 15:12, 15 July 2024 (UTC)

That was an excellent read. Thanks so much for bringing it up! DASL51984 ^{(Speak to me!)} 16:51, 15 July 2024 (UTC)

My own opinion, for what it is worth, is that the present wording of COMPUNITS reads like a Luddite's handbook, and is used by editor's to justify introducing ambiguity into articles where clarity and precision is needed. Dondervogel 2 (talk) 18:10, 15 July 2024 (UTC)

Your impressions on Locke Cole's point of view? DASL51984 ^{(Speak to me!)} 11:00, 16 July 2024 (UTC)

And the contra essay for your consideration: IEC units are bad. —Locke Cole • t • c 04:53, 16 July 2024 (UTC)

Much of your "essay" is spent regurgitating the exact same rotten excuses that myself and so many other people are absolutely sick and tired of hearing. Over the years, I've heard both perspectives countless times and tried my best to understand both perspectives equally, but none of the arguments I've seen from those against IEC units make any sense at all. DASL51984 ^{(Speak to me!)} 10:49, 16 July 2024 (UTC)

The arguments given in favor of these prefixes seem to fall into two categories: First, "they're better"; second, "they're accepted by standards bodies". Both of these arguments are irrelevant. What matters is whether they're used in the wild. Wikipedia follows; it doesn't lead. --Trovatore (talk) 23:41, 15 July 2024 (UTC)

Why do you think those are the only 2 arguments? Sources choosing to disambiguate use IEC prefixes. Those preferring ambiguity do not. Wikipedia has parked itself firmly in the camp preferring ambiguity. Is that really what you want? Dondervogel 2 (talk) 00:12, 16 July 2024 (UTC)

That's a "they're better" argument, and is irrelevant. --Trovatore (talk) 00:56, 16 July 2024 (UTC)

Nonsense. I made no claims about why the source disambiguate in this way, only pointed out the fact that they do. That is clearly about usage. Dondervogel 2 (talk) 10:45, 16 July 2024 (UTC)

Non sequitur. It's the usage you think is better, which makes it a "they're better" argument -- and irrelevant. --Trovatore (talk) 18:59, 16 July 2024 (UTC)

FYI: Repeating an incorrect statement does not make it any less invalid. DASL51984 ^{(Speak to me!)} 19:45, 16 July 2024 (UTC)

That is certainly true, but I made no incorrect statement, nor did Dondervogel identify one. --Trovatore (talk) 21:07, 16 July 2024 (UTC)

You certainly did make a completely nonsensical statement, and at this point all you have is "it's irrelevant" with no substantiation. And, when you were confronted about it, you merely repeated it as if it helped your case at all (spoiler: it actually weakened it severely). DASL51984 ^{(Speak to me!)} 21:23, 16 July 2024 (UTC)

Your statement that I was making a "they're better" argument is objectively incorrect. I was making a statement about usage and you know it. Dondervogel 2 (talk) 22:57, 16 July 2024 (UTC)

Not following. Yes, it's about usage, specifically the usage you think is better, because it's less ambiguous. I don't know what's subtle about this. That's a "they're better" argument, and I can't make any sense out of your denial of that obvious fact. --Trovatore (talk) 01:13, 17 July 2024 (UTC)

Wikipedia has parked itself firmly in the camp preferring ambiguity. No, Wikipedia has "parked itself firmly" in the camp that follows what the reliable sources used on our project use more often than not. When the day comes that that changes, Wikipedia will change along with it. But we're a long ways away from that day. —Locke Cole • t • c 00:22, 16 July 2024 (UTC)

If certain particular ways of doing things are erroneous and can be proven to be objectively incorrect, they remain incorrect, even if everyone does things in an incorrect way. Therefore, by "park[ing] itself firmly inthe camp that follows what the[...] sources used on our project use more often than not", as a side effect Wikipedia will inadvertently park itself in the camp that causes unnecessary confusion if those "reliable sources" follow outdated or incorrect conventions.

Basically, the entire argument propagated by gatekeepers like you can be boiled down to "we know this way of doing things is confusing, but let's do things that way anyways even though we know it's wrong." Do you seriously not realise how nonsensical this is? DASL51984 ^{(Speak to me!)} 02:44, 16 July 2024 (UTC)

Wikipedia takes the world as it is, not as we'd like it to be. SI wants to change computing units. 90+% of the world has decided to ignore that "standard" in favor of what has existed for decades. WP:DUE, WP:VNT and WP:BUTITSTRUE may help you understand this better.

In the end, your issue isn't with Wikipedia. Your issue is with Microsoft, Apple, The New York Times, CNN, and practically every other major software/hardware vendor and media outlet in existence. If you want to change the world, go make a nicely formatted letter and mail it to each of them. I wish you the best of luck, genuinely. —Locke Cole • t • c 04:46, 16 July 2024 (UTC)

• 90+% of the world has decided to ignore that "standard" in favor of what has existed for decades.

The way I see it, the real reasons are: (1) There are still a lot of old heads who won't admit that they were wrong and want to justify their laziness, (2) people think they sound funny (I think they sound weird too, but I accept that this helps reduce confusion), and (3) the IEC's patch for this bug was only rolled out fairly recently.

I think that, rather than being ignored, a lot of websites simply don't know about the binary prefixes, so they don't realise that the units are wrong. But trying to gatekeep information with this "it's better, but no one is familiar with it, so let's not do it" only adds to the problem. So my issue is actually with both sides. DASL51984 ^{(Speak to me!)} 10:34, 16 July 2024 (UTC)

No, your issue is with the entities I listed for you. Wikipedia reacts to our sources, we don't guide our sources to what is "correct". And to continue my WP:NPA recommendation below, calling people "old heads" who are "lazy" is a form of personal attack. Calling editors who disagree with you "gatekeepers" is likewise an attack. I've held my tongue with this so far, but if you're here to change minds, calling people names is a sure fire way not to accomplish that. —Locke Cole • t • c 04:00, 17 July 2024 (UTC)

(paraphrasing) "If things are incorrect, they're incorrect even if everyone does them that way." I actually agree with that. But the issue here is that's not Wikipedia's call. Wikipedia doesn't decide what's correct. That would be too much power; Wikipedia doesn't want it. You have to go convince the wider world. Then Wikipedia will change. --Trovatore (talk) 07:13, 16 July 2024 (UTC)

@Trovatore: Applying your reasoning, Wikipedia would use kbps (or Kbps? who knows), but MOSNUM prescribes kbit/s. The reason MOSNUM prefers kbit/s, Mbit/s, etc is to remove the ambiguity associated with kbps, Kbps, Mbps, mbps, MBps and countless other permutations used by the computer industry. Dondervogel 2 (talk) 07:29, 16 July 2024 (UTC)

Haven't looked into that one. Maybe that decision was wrong. --Trovatore (talk) 19:00, 16 July 2024 (UTC)

If that decision was wrong it should be re-opened. And while we're at it we should clearly revert to "kt" for knot and "nm" for nautical mile. Dondervogel 2 (talk) 19:15, 16 July 2024 (UTC)

Very possibly. Not under discussion at the moment. --Trovatore (talk) 21:09, 16 July 2024 (UTC)

Do you really think that using "Mbps" (which is more common than Mbit/s for the same reason that MB is more common than MiB) would make Wikipedia a better encyclopaedia? Dondervogel 2 (talk) 23:03, 16 July 2024 (UTC)

The best encyclopedia uses the terminology most familiar to our readers. That typically means the terminology widely used in our sources. Using neologisms does nothing but confuse our readers and is a disservice to the experience we want to present. —Locke Cole • t • c 23:06, 16 July 2024 (UTC)

Yup. This is very much still in the realm of "what do our reliable sources use"? And the answer, as ever, is predominantly the classic units. When major news articles use these units with regularity and they're used in more sources overall will be when Wikipedia can finally transition, not before. —Locke Cole • t • c 00:20, 16 July 2024 (UTC)

Yes, "MiB" is more accurate than "MB" when the latter means 1,024² bytes, but the question is what the majority of reliable sources use. As Trovatore says, Wikipedia doesn't decide what's correct in such matters, annoying though the inaccurate use is to many of us. Peter coxhead (talk) 13:29, 16 July 2024 (UTC)

My day job is as an embedded programmer. As such, I spend a lot of time reading datasheets for individual chips. Overwhelmingly, these datasheets use 32 KB to represent 32×1024 bytes and 1 MB to represent 1024×1024 bytes while still using 20 MHz to represent 20×1000×1000 Hertz. And this is not just like 60:40% majority, it's like 95:5% majority. For chip datasheets (as used by the industry itself) the IEC prefixes are almost completely unused.

It was mentioned that the IEC prefixes were relatively new. In this fast paced industry, 1999 is practically ancient times. In 25 years the industry responded to them with "meh".

The IEC prefixes have exact 2.4% error in them. In most cases this is negligible. Do you really care if you have 34,359,738,368 bytes of flash storage or 32,000,000,000 ? Be aware that you probably don't know how much overhead the file system uses , so you might only have approx 28,000,000,000 bytes available to you, the user. Or maybe less. Or maybe more. 2.4% is neither here nor there for most people.

Then compare it to Mbits/s vs Mbps. One is 8 times the other (1 byte = 8 bits). That is a significant difference to almost everybody. Practically anybody can tell if something is 8 times faster/slower. And it is so, so easy to mix up the 2.

There are very few rules in WP that are absolute. Instead, we give a certain amount of weight to each, stack the opposing arguments against each other and then see which side dominates. Sometimes it will be which has the least confusion and sometimes it will be which has the most use in sources. For Mbits/s and Mbps, both are well attested in use but Mbps has a very high probability for confusion - so we go for clarity. For MiB vs MB, there is a low rate of usage in the sources for MiB but meagre consequences of confusion, so we favour MB.

For what it's worth, I'm OCD and vastly prefer unambiguous statements (which is an asset in my job). But even I recognise that the industry simply did not embrace IEC prefixes.  Stepho  talk  23:55, 16 July 2024 (UTC)

While 1 KiB is only 2.4% larger than 1 KB, this discrepancy is not insignificant, and quickly grows (you most likely already know this by now, but still). 1 MiB is 4.9% bigger than 1 MB, 1 GiB is 7.4% larger than 1 GB, and 1 TiB is 10% larger than 1 TB.

For so long, storage was expensive and had limited capacities, so back in the day the 2.4% really wasn't that big of a difference. But today, there are many old heads that still do things wrong and many legacy systems that are still in use which display incorrect units, so the adoption has been slow. However, the sooner people start fixing the problem instead of grasping at straws and coming up with excuses, like you are doing here, the better. DASL51984 ^{(Speak to me!)} 00:41, 17 July 2024 (UTC)

Oops, my mistake. That should have been 2.4% per K. So G would be 2.4 cubed, which is about 14%. Not quite insignificant but in today's era of cheap memory, not a big problem either (you mentioned yourself that back in the day storage was expensive, implying that today's is cheap).

"grasping at straws" ??? "excuses" ??? I gave reasoned points, showed how we weighed up the pros and cons and did not get involved in name calling. In response, you insult anybody with a different view, put your hands over your ears and went "la-la-la-la-la...".  Stepho  talk  01:23, 17 July 2024 (UTC)

I'm totally on your side, but you need a math refresher. 1G (or Gi, depending on your political tastes) is (1.024)^3 ~= 1.074. It's got nothing to do with cubing 2.4, or whatever you were trying to say. EEng 04:54, 17 July 2024 (UTC)

Egad - I'm on a roll but its downhill :( As pointed out, it should have been 1.024 cubed, not 2.4 cubed, to make approx 1.074 -> 7.4%. So much for my maths degree ...  Stepho  talk  05:08, 17 July 2024 (UTC)

Every argument I've seen defending the erroneous "KB = 1024" is always an appeal to tradition, some other logical fallacy, or has more invalid points than "valid" ones.

I called out what you said as excuses because that's pretty much exactly what they were and your attempt at presenting arguments in favour of not using binary prefixes was anything but "reasoned". For example, your first paragraph about "no one uses them" is an appeal to popularity, since the use of decimal prefixes with binary meaning is objectively incorrect and inconsistent even if everyone does things that way.

And finally, calling out an improper use of units and calling out people who refuse to acknowledge that a wrong use of units is indeed wrong is not "insulting anyone with a different view". I don't know where you got that from. DASL51984 ^{(Speak to me!)} 01:36, 17 July 2024 (UTC)

Try reading WP:NPA and seriously consider your next words carefully. —Locke Cole • t • c 02:03, 17 July 2024 (UTC)

How does this fall under NPA? DASL51984 ^{(Speak to me!)} 02:27, 17 July 2024 (UTC)

DASL51984: Your argument is mostly based around WP:RIGHTGREATWRONGS. As already pointed out, WP is not the place to right great wrongs but follows what the majority of sources say. The majority of sources said "meh" about IEC prefixes.

You said that we are just following tradition. Nope, we are following what the real world uses. If the world changes then we will follow. The world hasn't changed yet. Ask again in 5 years.

Re NPA: "the entire argument propagated by gatekeepers like you" and "the sooner people start fixing the problem instead of grasping at straws and coming up with excuses, like you are doing here, the better". Calling those of the opposite view as gatekeepers and grasping at straws could be considered as a (mild) personal attack. Or at least an ad hominem attack. We prefer that you address the issues rather than (mild) name calling.

We have presented our view as using the same units used in the real world and that the argument of righting great wrongs does not hold water here. These 2 principles are deeply ingrained in WP. Your arguments fly in the face of these 2 principles. You must either find new arguments or be prepared to overturn these 2 principles.  Stepho  talk  02:34, 17 July 2024 (UTC)

Thank you for (finally) not being unreasonable.

I didn't mean to insult anyone, but I code and work with computer software and hardware on a regular basis, and things like this matter a lot to me. The whole 1000 vs. 1024 war was silly to me when I first got interested in coding and computing back in grade school, and it's still silly to this day. DASL51984 ^{(Speak to me!)} 02:53, 17 July 2024 (UTC)

Mbps is an abbreviation for "megabit per second", the unit symbol for which is Mbit/s. There is no factor of 8. Are you confusing it with MBps? Dondervogel 2 (talk) 13:32, 18 July 2024 (UTC)

Sorry, I didn't say it properly. I meant that Mbits/s is very clear but Mbps could easily be confused with MBps, which is what I meant by an 8 times confusion.  Stepho  talk  20:40, 18 July 2024 (UTC)

Stepho, when you said earlier that you're on a roll, was it this kind of roll ?EEng 21:35, 18 July 2024 (UTC)

Certainly feels like it sometimes.  Stepho  talk  23:06, 18 July 2024 (UTC)

Ah yes, that makes sense. You seem to be acknowledging that Wikipedia's use of Mbit/s is justified because it is a less confusing symbol than the abbreviation used by the popular press and much of the computer industry (Mbps). Correct? Dondervogel 2 (talk) 05:12, 19 July 2024 (UTC)

Not quite. Mbits/s and Mbps are both well attested in the real world (I spend a lot of time programming communication protocols) but WP uses Mbits/s because MBps and Mbps are easily confused and the consequences are huge.

Whereas MiB is not used much in the real world and the consequences of confusing MiB with MB is small.  Stepho  talk  00:22, 20 July 2024 (UTC)

Yes, I understand the nuance, but I did not phrase my question carefully enough, so let me explain better. Others on this page are arguing that the inherent value of a unit symbol is irrelevant, and that the ONLY thing that matters is how often that unit symbol is used. Your position differs from that by acknowledging that the value of the unit symbol (in this case its value in disambiguating the factor 8) is also a consideration, in addition to usage. I sense no dogmatic principle in your reasoning that ONLY the frequency of usage matters, and I find that helpful. That was my point. Dondervogel 2 (talk) 06:17, 20 July 2024 (UTC)

Yes, I try to take a balanced viewed instead of looking only at a single point to the exclusion of all else - a distinctly unpopular view ;)  Stepho  talk  09:15, 20 July 2024 (UTC)

Without wishing to put words in your mouth (please correct me if I take this too far), I imagine you apply a similar reasoning to the choice of nmi for nautical mile (avoiding confusion with the nanometre) and kt for knot (avoiding confusion with the kilotonne). Just as well no one ever uses the dB or MB ;-) Dondervogel 2 (talk) 09:27, 20 July 2024 (UTC)

No, that would be taking my point too far. KiloTon and knot are unlikely to be mistaken due to context - weight vs speed. Nautical mile and nanometre are both distances but the difference is so big that wrong usage would also be obvious.  Stepho  talk  23:56, 21 July 2024 (UTC)

Notes

Use of metric prefixes

As someone with high functioning autism I find it all nice, consistent and straightforward to use the whole range of metric prefixes (see article on those) at every opportunity (even instead of non-SI units even specialists tend to use), this to me (forgive me for any slight inaccuracies here these are to rounded figures and are off the top of my head ), the mass of an electron is 9.109 qg, the mass of a proton is 1.69 yg the electronic charge is 160 zC, the the dialect of a proton is about 1 fm, the depth of the world’s planned deepest swimming pool would be 5 dam, the height of the Eiffel Tower is 3.24 hm, Everest is 8.863 km high, the earth has a circumference of 40 Mm and a surface area of 510 Mm2, the volume of water in the Pacific Ocean is about 1 Mm3, the distance to the Moon is 384 Mm, the distance to the Sun is 150 Gm, the distance from the Sun to Saturn is 1.4 Tm, the distance to Alpha Centauri is 40 Pm, the distance to Betelgeuse is roughly 3 Em, the diameter of the Milky Way is 1 Zm with Andromeda 21 Zm away, the diameter of the Observable Universe is a Comoving 880 Ym, the mass of the Earth is 5.98 Rg and the mass of Jupiter is about 2 Qg. To me, it would be much more consistent and straightforward if all Wikipedia articles used the full range of metric prefixes to get people using them more and thus making more sense to me. Perhaps that change could be made, with people being directed to the metric prefixes page as needed to help them understand the wider range of prefixes. From the age of 12 I started to use the full range of prefixes them known to me in my schoolwork, and at virtual astronomy society I tend to butt in with the distance or mass expressed that way instead of earth masses or light years, for example. Avenues2009 (talk) 09:13, 21 July 2024 (UTC)

While I'm in favour of primarily using SI units whenever reasonable, we chiefly use the units that are most common in any given area, so general custom needs to change first before we follow suite. Hence we'll continue to use units like solar mass and astronomical unit in astronomy, nautical miles and knots in marine navigation (which fit the Earth's coordinate system better than SI units), and even feet for aviation. Also I'm pretty sure that years and centuries will remain more popular for expressing longer periods of time than mega- and gigaseconds, charming as the latter might theoretically be. Gawaon (talk) 09:44, 21 July 2024 (UTC)

Could both then be provided (including use of exotic prefixes in case of one) so not only is everybody else satisfied, so am I. Perhaps this could be done by always providing the SI with the exotic prefix in brackets (you can tell I am British here). Even if SI is already used but with a common prefix, perhaps the more exotic prefix could be provided in brackets. That would again satisfy all round. Avenues2009 (talk) 10:03, 21 July 2024 (UTC)

Template:Convert exists and can be used for such purposes. However, in less obvious cases or if you are reverted, it might be best to open a discussion on the talk page of the article in question. Gawaon (talk) 10:28, 21 July 2024 (UTC)

How does one use that to do two different conversions at the same time - eg thousands of kilometres to both miles and megametres, or astronomical units to both millions of kilometres and gigametres? Avenues2009 (talk) 11:24, 21 July 2024 (UTC)

One conversion should be enough, and units like mega- or gigametres that don't see any real world usage shouldn't be used at all. Gawaon (talk) 11:29, 21 July 2024 (UTC)

But that’s the whole point of me having started this discussion. With my high functioning autism, to me they should be used everywhere because that means everything is all straightforward and consistent. That’s why I wanted to be able to do two conversions at the same time, to bring them into use as well as what others prefer. Avenues2009 (talk) 11:57, 21 July 2024 (UTC)

Your high functioning autism doesn't mean the world will magically take the shape you would like it to take. Wikipedia is consensus-driving, and there is no consensus for the use of exotic SI combinations such as gigametres or megaseconds, even though they are theoretically valid. Gawaon (talk) 12:06, 21 July 2024 (UTC)

And it is much easier to say a measurement when using all the prefixes not just the common ones. Avenues2009 (talk) 11:58, 21 July 2024 (UTC)

I echo the other concerns mentioned in other replies. I'll add that from the time the metric system was created about 7 Gs ago until the introduction of the International System of Units (SI) about 2 Gs ago a variety of ad hoc units were added, such as mmHg. Also, some of the original prefixes were found to be inconvenient. So SI recommends that hecto-, deka-, deci-, and centi- not be used, and only coherent units be used. However, the prefixes for multiplication or division by 10 and 100 are still used in entrenched cases, such as centimeter or decibel. Jc3s5h (talk) 13:22, 21 July 2024 (UTC)

Don’t you mean 7 Gs and 2 Gs? Avenues2009 (talk) 13:32, 21 July 2024 (UTC)

You're right, I fixed it.

It is not Wikipedia's job to try to promote metric prefixes in contexts where they are not used in the wider world, even if some individuals do use them in those circumstances. Most scientists in many fields - including, since you raise it, astronomy - don't use them - particularly the more extreme ones - because they are obscure and serve to confuse rather than enlighten.

I'd also note that even the largest metric prefixes aren't large enough for some astronomical data. I note that you fail to mention the mass of the sun, which is around 2 (non-existent-prefix)-grams. And there's plenty of of masses you might want to express that are many orders of magnitude larger than the mass of the sun. Kahastok talk 15:20, 21 July 2024 (UTC)

Perhaps a parallel example might be useful. I recently learnt a major reason why Americans keep rejecting the metric system. A major benefit of metric is the use of prefixes makes it trivial to convert from mm, to m, to km, and so-on. Except Americans are so used to the imperial (customary) system making it so hard to convert between inches, feet, yards and miles that they simple learn to not convert between units. So one of metric's major advantages is simply a non-issue to them.

The parallel here is that people use solar masses, AU, light-year, etc and just never convert them to other units. Only people writing software for things like interplanetary probes would ever do such conversions to kg, m, etc and they don't need Wikipedia for this info. So converting them to metric is not useful and the clutter it causes makes articles harder to read.  Stepho  talk  03:18, 22 July 2024 (UTC)

For me, articles would not be too crowded with such conversions thrown in. To me, they would be quite useful, as well as educational for all those who live between 5 and 12 Mm away from me in the US. Avenues2009 (talk) 06:47, 22 July 2024 (UTC)

The larger figure being included to encompass Hawaii by the way. Avenues2009 (talk) 06:50, 22 July 2024 (UTC)

Do you see what I mean there? I live in the UK, hence the distance I gave. Avenues2009 (talk) 22:30, 22 July 2024 (UTC)

I don't. Gawaon (talk) 05:54, 23 July 2024 (UTC)

Therefore such unit conversions would be quite useful and not make articles too crowded, because then you might. It would help Americans understand how much more useful the metric system would be for them. Avenues2009 (talk) 06:55, 23 July 2024 (UTC)

Nobody argues against the usefulness of commonly used metric units. However, Mm (as opposed to mm) is not one of them. Gawaon (talk) 07:05, 23 July 2024 (UTC)

Er, I'm American, and the ease of converting metric units is refreshing compared to trying to remember how many ounces are in a pound or a gallon, and I think makes metric quite attractive. We have to convert between customary units (we don't use imperial units since that system came after US independence) frequently, and to do that I either ask a smart speaker or look it up online if I can't remember the conversion factor. Generally, I think Americans find the metric system difficult to learn simply because they (outside of STEM fields and certain industries) don't use it every day and have no intuitive sense of what various quantities (like 100 km or 10 degrees C) mean. I think trying to add more prefixes into common use like gigameters or whatnot, would just mean more to memorize about the metric system, and thus make it slightly harder to learn, not easier. -- Beland (talk) 07:05, 23 July 2024 (UTC)

It doesn’t take much to memorise 24 prefixes. Avenues2009 (talk) 07:38, 23 July 2024 (UTC)

That's why I say "slightly harder" and not "a lot harder". I'm an American who does have a feel for what a kilometer is, and if you start speaking in megameters, you'll just make me do extra mental work to convert back to thousands of kilometers. If you start speaking in megaseconds, I and my European friends are probably just going to stop listening, because it's too much work to figure out what that means in years, which is the conventional and intuitive unit for long time. I'm an enthusiastic promoter of the metric system and use it whenever feasible, but anything above "tera" or below "milli" I'd have to look up.

I think a much better way to get Americans to learn the metric system (and one which already has broad consensus) is to make sure that every time a US unit is given on Wikipedia, there's a metric conversion right there. Since Wikipedia is consulted so frequently, I expect this would increase American exposure to the metric system significantly, since it rarely comes up in the news or in everyday life (unless you work in STEM or a few other narrow areas). Eventually I hope people would generate an intuition for metric units by sheer exposure.

This is currently required by MOS:CONVERSIONS, but there are hundreds of thousands of instances violating the guideline. I am actually working on adding conversions in my spare time, using moss to scan database dumps and JWB to quickly add in {{convert}}. I have tens of thousands of articles in a queue to be fixed for feet and inches alone, if you'd be interested in helping out. -- Beland (talk) 08:07, 23 July 2024 (UTC)

If you read the article on metric prefixes, there is a hint that at some stage in the future, double prefixes may return, with the restriction that the last one be quecto or quetta, but that has not happened her. That problem would be solved if they did return. Avenues2009 (talk) 06:23, 22 July 2024 (UTC)

So they can’t be used before that time if it ever happens. Avenues2009 (talk) 06:24, 22 July 2024 (UTC)

How is it more convenient to keep swapping prefixes instead of just using a single unit with scientific notation if needed? I'd much rather compare 0.04 km with 2000 km than compare 40 m with 2 Mm. Double sharp (talk) 09:17, 23 July 2024 (UTC)

Well I find it more convenient, it’s easier to say the measurement for a start if the prefixes are used. And instead of saying 40 m, you’d say 4 dam. Avenues2009 (talk) 10:03, 23 July 2024 (UTC)

Car power is expressed in 3 different units in Wikipedia articles, kW, hp and PS, so having 3 different units for astronomical distance could work. Some people do use these prefixes, look at the computer world, Gigabyte and PB are very common. When people see this it might open their mind to look into this unit and learn something, which after all is the reason for Wikipedia. Avi8tor (talk) 15:36, 23 July 2024 (UTC)

What a good idea. It would be great if that was implemented not only in astronomy but other fields as well. Avenues2009 (talk) 16:41, 23 July 2024 (UTC)

Different countries have different definitions of horsepower, including the German PS. I think the general trend is that kW is replacing horsepower in international commerce (and using kW as primary is now mandatory in the EU). It doesn't seem useful to encourage anyone to learn about horsepower or start using it when they otherwise wouldn't.

If you meant to reply to the question about light-years, this is the wrong section. -- Beland (talk) 17:02, 23 July 2024 (UTC)

Oh, when you say "3 different units for astronomical distance", you mean e.g. AU, km, and Gm or something? Having two meter-based conversions would seem to me to be adding clutter because a.) those conversions are easy for readers to do just by moving the decimal place, and b.) Gm is virtually unused, and thus not useful for conveying information about the subject of the article. The only reason to have it there would be to teach readers about obscure units in the metric system, which is not the point of Wikipedia articles except for Metric system and Metric prefix and friends. -- Beland (talk) 17:09, 23 July 2024 (UTC)

Then let’s have two metre-based conversions then, for that very purpose of teaching readers those obscure units. And let’s do it for distances beyond the solar system as well. Avenues2009 (talk) 17:13, 23 July 2024 (UTC)

Wikipedia is not a textbook. Teaching is not our primary task, and we don't have a right to decide who should be taught what. Gawaon (talk) 17:18, 23 July 2024 (UTC)

Yes, and we convert to alternative units to communicate quantities to people accustomed to this or that set of units, not to train people in the use of an unfamiliar one. NebY (talk) 17:36, 23 July 2024 (UTC)

But the more the unfamiliar ones were taught, the more they might catch on and become familiar. Avenues2009 (talk) 18:24, 23 July 2024 (UTC)

As WP:RIGHTGREATWRONGS says, Wikipedia is intentionally "behind the curve"; I think it would happily adopt such a change if it had already substantially caught on, but does not itself want to lead that type of movement. Sorry that's unsatisfying, given that I'm sure using the obscure units makes you and the original designers of the system happier than watching people use the metric system as they actually do. 8) -- Beland (talk) 19:01, 23 July 2024 (UTC)

I was thinking more AU or light years, miles and Gm or Pm for the 3 units. I've found that in general citizens of different countries use what they are fed, miles in the UK and USA and km elsewhere. The same with every other unit. The British empire used stones for weight, now only the UK used stones. It appears most younger people outside the UK have never heard of stones even though their mother tongue is English. Avi8tor (talk) 19:36, 23 July 2024 (UTC)

Currently, it's not required to convert into miles for STEM articles. In many cases we don't, and in some cases we're actively removing them. -- Beland (talk) 19:57, 23 July 2024 (UTC)

Well for astronomy you could instead convert into Mm,Gm, Tm, Pm, Em, Zm or Ym as the case may be, or for the Comoving circumference of the observable universe at least, Rm. That would make a lot more sense than miles. Avenues2009 (talk) 20:25, 23 July 2024 (UTC)

And the same with mass. It would make sense to have both kilograms, and the relevant prefix that would apply to a given value. Avenues2009 (talk) 21:34, 23 July 2024 (UTC)

And for large objects like stars, galaxies etc the second figure would be the number of Qg until such time as double prefixes are allowed again. Avenues2009 (talk) 21:40, 23 July 2024 (UTC)

Of the distance units mentioned, the units people actually use are AU/light years and kilometers. Ym might make more sense to you, but they don't make sense to hardly anyone else, and Wikipedia's goal is to communicate to as broad an audience as possible. -- Beland (talk) 22:58, 23 July 2024 (UTC)

Hence the suggestion of converting to both km and a more appropriate prefix so things make sense to me as well as to others. Avenues2009 (talk) 06:09, 24 July 2024 (UTC)

When I say people use kilometers, I mean people use kilometers, not Ym. How many people do you think actually use Ym or would understand them on sight? -- Beland (talk) 15:41, 24 July 2024 (UTC)

I’ve met one or two actually. Avenues2009 (talk) 19:20, 24 July 2024 (UTC)

And they even understand what it stands for - yottametres. Avenues2009 (talk) 19:21, 24 July 2024 (UTC)

That's not really enough information to get a handle on the overall ratio of English speakers. How many people have you met who would not understand Ym? What is your sampling bias compared to English Wikipedia readership? -- Beland (talk) 22:06, 24 July 2024 (UTC)

The sampling size is the groups I belong to, including astronomy society, and all my friends. But it really does make sense to use the prefix just below a value. It makes measurements much easier to write or to say. Avenues2009 (talk) 22:14, 24 July 2024 (UTC)

My astronomy society do not seem to understand Mm to Rm (megametres to ronnametres) so if these changes were implemented on Wikipedia that I am here asking for, we’d teach them. They’re technical and brainy enough, there are several of my fellow PhD holders among them, as well as a few teachers, so it would be very easy for them to learn and adopt any missing prefixes out of the 24 available. Avenues2009 (talk) 22:17, 24 July 2024 (UTC)

If even a specialty audience needs to be taught how to read the units, the vast majority of readers will certainly not know them on sight. We've already established it's a non-starter if readers don't already understand the units Wikipedia would be using across tens of thousands of articles. -- Beland (talk) 23:15, 24 July 2024 (UTC)

The goal is to communicate clearly with as wide a readership as possible. Do you believe that there are people who understand what a Ym is but don't understand what a km is? What then is the advantage of adding measurements in Ym (and the other obscure units you've proposed), other than satisfying your own personal sense of consistency? CodeTalker (talk) 22:12, 24 July 2024 (UTC)

It would satisfy my desire for consistency. Having the obscure unit included besides km (or kg) in a double conversion, would do that as well as be educational and informative that there are many other prefixes people can use as well. Avenues2009 (talk) 22:20, 24 July 2024 (UTC)

Although people can read the article on prefixes if they want to, they would be more likely to learn about them if they saw them in use, which such double conversions would enable. Avenues2009 (talk) 22:26, 24 July 2024 (UTC)

You're just repeating the same arguments you've already made and which have already been objected to. I could make the same objections again, but we're just going in circles, so it seems there's no point continuing this thread. -- Beland (talk) 23:18, 24 July 2024 (UTC)

The Manual of Style does ask for things to be in SI where possible and for unfamiliar units to be explained. So that is why I would like to see the full range of prefixes brought in using double conversions. Avenues2009 (talk) 07:55, 26 July 2024 (UTC)

I thought double conversions would help explain them. Anyway, that is my view. Avenues2009 (talk) 09:43, 26 July 2024 (UTC)

The MOS says that because unfamiliar units that must be used to explain the subject need to be explained. It's not asking to use unfamiliar units on purpose. Double conversions would add clutter which would make it slightly more difficult for readers to learn about the subject of articles. -- Beland (talk) 14:41, 26 July 2024 (UTC)

Ok. Avenues2009 (talk) 18:40, 26 July 2024 (UTC)

Ok, I run with that, although I still feel that if a metric prefix has been devised, one might as well use it because that is what it was devised for. Avenues2009 (talk) 08:49, 28 July 2024 (UTC)

No, some were devised merely for completeness, at a time when there was no foreseeable use for them. For example, it appears that while ronna (10^27) and quetta (10˄30) were added in anticipation of the need to express ever-larger quantities of data, ronto (10˄-27) and quecto (10˄-30) were added simply for symmetry with the other two [25] -- no one envisions anything (yet) they might actually be used for. EEng 13:55, 1 August 2024 (UTC)

Two questions

1. Why fractions and mixed units are generally not used with metric units? I have seen some uses of fractions with metric units in articles such as Shoe size, but never seen any usage of mixed units.
2. Do articles that have strong ties to both US and Canada use metric or imperial units first? I think that it would be stupid to use imperial units first in articles with strong ties to Canada. --40bus (talk) 15:22, 22 July 2024 (UTC)

   For your second question, I typically use {{Convert}}, and place the unit used in the majority of sources first, i.e., if a source says six miles, I add {{Convert|6|mi}}, yeilding "6 miles (9.7 km)". If a source says ten km, I add {{Convert|10|km|mi}}, yielding "10 kilometres (6.2 mi)". The order in which the output is displayed can be manipulated by the "order=flip" parameter, i.e., {{Convert|6|mi|order=flip}} yields "9.7 kilometres (6 mi)". I don't really care whether "imperial" or "metric" displays first, as long as the unit used in the source is placed in the first parameter in the template to avoid rounding errors. Donald Albury 18:36, 22 July 2024 (UTC)

   You might not care but the Wikipedia Manual of style does. People can pick cherry pick sources, it's what the authorities in that country want that counts. The EU requires that power in all car owner manuals be in kW since about 1980, this includes the UK. The MOS states in Units of measure: SI primary outside the USA and UK. Plenty of people in the US use metric, Space X, Tesla, the auto industry, John Deere, etc. etc. yet congress in the USA does not mandate SI, it's optional. There are lots of other examples. See what the law states [[26]] Avi8tor (talk) 19:51, 23 July 2024 (UTC)

People frequently do calculations with measurements, and usually perform the calculations with calculators and computers. These devices are much easier to use with decimal fractions rather than mixed numerals. Jc3s5h (talk) 16:35, 22 July 2024 (UTC)

Conversion of light years and parsecs

Hi, all. We're trying to harmonize the units used in astronomy articles by building consensus for Wikipedia:WikiProject Astronomy/Manual of Style. It currently seems to be general practice to convert interplanetary distances and smaller to km, but not convert interstellar distances measured in light-years (and to show conversion to parsecs). Given that these units are not used outside astronomy and astrophysics, this contradicts the part of MOS:CONVERSIONS which advises converting "units of measure that are ... obscure outside of a particular specialty or geography". Would it be OK to add an official exception noting interstellar and larger distances should be given in light-years and parsecs and not converted to SI units? -- Beland (talk) 07:11, 23 July 2024 (UTC)

Can you give an example (point to a page) where that conversion to km doesn't happen? Gawaon (talk) 07:15, 23 July 2024 (UTC)

I see that in all the infoboxes of the first extrasolar objects I could think of, namely Alpha Centauri, Betelgeuse, Wolf 359, and Andromeda Galaxy. -- Beland (talk) 07:28, 23 July 2024 (UTC)

Thanks. As someone who's not a editor or expert in the field, but an occasional reader, I'm not in favour. I find 0.024 AU (3,600,000 km) much more helpful than a naked distance in AU, and I find 7.86 light-years (7.44×10¹³ km) more relatable than 7.86 light-years (2.41 parsecs). Light-year and parsec essentially just mean "unimaginably long" to me, but I know what a kilometre is and 10¹³ allows me get a better understanding of the dimensions involved. Gawaon (talk) 09:12, 23 July 2024 (UTC)

Well you're lucky then, because there's no way I'd relate to 10¹³ km in any remotely sensible manner. I can at least think of a light year as about a quarter of the distance to the nearest star to the Sun. Praemonitus (talk) 18:21, 23 July 2024 (UTC)

You quite have a perspective there, because "10¹³ km" is essentially meaningless to me. It is very hard to think about that number in terms of human scale alone. You will not encounter that number on a daily basis except perhaps when discussing countries' GDP or debts.

7.86 light-years (2.41 parsecs) is much more sensible on my perspective. That means light reaches that star in just under 8 years time, and that it makes a parallax angle of 1/2.41ths of an arcsecond every six months in the sky. It is more than just being "unimaginably long." SkyFlubbler (talk) 11:41, 28 July 2024 (UTC)

Would it be better to say that distances given in light-years should only be converted to parsecs and vice versa? Looking at Proxima Centauri and Antares reminds me that distances between binary stars may be appropriately given in smaller units such as AU and billions or trillions of kilometres, which would technically be contrary to an unqualified "interstellar". NebY (talk) 08:47, 23 July 2024 (UTC)

Good point; I mean distances between stellar systems, rather than between stars in the same system. We could say "between stellar systems" or "distances typically measured in light years by reliable sources" to clarify. -- Beland (talk) 16:29, 23 July 2024 (UTC)

No, that would not be OK. That would be like saying it's OK not to convert knots to m/s because nautical people are familiar with knots. What unites all of us is the SI system, so a conversion to SI is needed. Always. Dondervogel 2 (talk) 12:16, 23 July 2024 (UTC)

Would you be in favor of converting from light-years to km only, and dropping parsecs, as in Gawaon's examples above? Parsec says light-year is more common in popular science and general media, which aligns with my experience. I have always found parsecs redundant to light-years and confusingly different. -- Beland (talk) 16:34, 23 July 2024 (UTC)

I would support making a choice between light-years and parsecs (I don't care which, but both would be overkill). Once that choice is made, convert to SI and we're done - in the sense that everyone can then comprehend the distance. Dondervogel 2 (talk) 17:21, 23 July 2024 (UTC)

I agree, that sound reasonable. Among the two, light-year seems to be better known, as Beland noted. Gawaon (talk) 17:26, 23 July 2024 (UTC)

I agree with Dondervogel 2 as well. Avi8tor (talk) 19:56, 23 July 2024 (UTC)

I see little reason not to. Most of the units that aforementioned policy in MOS:CONVERSIONS refer to are still "human-scale", or at least close to it. When one furlong is thrown out, for example, its conversion to 220 yards/0.125 mi/~201 m is easy to visualize, as such lengths are encountered frequently in life. People generally have first-hand experience with distances that long.

One light-year is nearly 1e13 km. I can't speak for everyone, but personally that figure is almost completely meaningless to me; 1e13 km simply is not a comprehensible figure. Even 1 AU (~1.5e11 m) is difficult to comprehend. This is why internet demonstrations of the "true scale" of the Solar System and interstellar space often go viral: people just do not intuitively grasp these distances and scales very well, and no conversion will change that. As Praemonitus mentioned in Wikipedia talk:WikiProject Astronomy/Manual of Style#Conversion of light years and parsecs into km, this issue only gets worse for intergalactic distances on the order of megaparsecs. Ultimately, I fail to see how useful such conversions really would be. ArkHyena (talk) 17:24, 23 July 2024 (UTC)

Thanks for writing this comment, that's precisely my opinion and you saved me the work. Tercer (talk) 17:29, 23 July 2024 (UTC)

I was not aware of this attempt to write a specific MOS for astronomy; I imagine you'd get more informed input at WT:AST than here. Astronomical distances are measured in au within a star/planetary system (including the Solar System), and in parsecs for everything larger (extending to kiloparsecs for galaxies, megaparsecs for galaxy groups etc.). Converting either of those to km would not be useful to readers - the numbers are incomprehensibly vast, which is one of the reasons why astronomers don't use km in the first place. Light years are used only in popular science accounts and press releases, where they do have some utility, but are essentially never the original astronomical measurement. I think it's fine to provide a conversion of pc to ly, but pc should be the primary unit. Converting to km is generally pointless, unless there's some unusual situation. Linking the au or pc unit on first appearance would be more useful to readers. Modest Genius ^talk 17:48, 23 July 2024 (UTC)

PS. There's some relevant discussion in the archives at Wikipedia_talk:WikiProject_Astronomy/Archive_12#Should_we_decide_on_a_default_unit_to_use_across_WP? and Wikipedia_talk:WikiProject_Astronomy/Archive_11#Units_to_be_used_for_distances_and_sizes_in_infoboxes Modest Genius ^talk 17:54, 23 July 2024 (UTC)

The previous discussions linked above seemed to concern whether light-years or parsecs should be used for large distances, and the general consensus seemed to be that astronomers use parsecs, readers are much more likely to understand light-years, and we should just use {{convert}} to display both. That has since at least mostly happened, but no one suggested converting to kilometers, and at that time the language about "obscure outside of a particular specialty" was not in MOS:CONVERSIONS. Hence the current question about resolving the conflict.

Per WP:JARGON, Wikipedia articles are written for the broadest possible audience, and we are advised to "write one level down" if necessary to make technical articles understandable to non-specialists. So if we need to pick two units and one of them is km, then parsecs may have to get the boot because it's mostly only specialists who use them. Fortunately, astronomers should be able to convert from light-years to parsecs easily, unlike the general public, so we don't need to sacrifice level of technical detail.

In other unit-related discussions, we've decided to use {{convert}} to display Wikipedia house style to readers and in some cases hide the units used by sources. Using a parameter like disp=out can do that while preserving the original units for verification against the cited source, and to avoid losing precision if someone comes by later and adds a second conversion. -- Beland (talk) 18:52, 23 July 2024 (UTC)

I disagree, as noted above. 10¹³ km means something to me, even if (admittedly) the dimensions involved are hard to grasp, while throwing "parsecs" or "light-years" around is essentially meaningless. (I agree one of them should be used too, but not exclusively.) Gawaon (talk) 18:16, 23 July 2024 (UTC)

I wonder then how many lay readers are familiar with distances expressed in exponential notation? Because that isn't everyday usage. If you saw 1×10¹³ in a lay readers article, it would be more likely to be written as "10 million million kilometers". I look at the public facing NASA article The Galaxy Next Door and it gives distances and dimensions in light years, so NASA is expecting the public to be familiar with that distance scale. The distance to the Andromeda Galaxy is something like "25 million million million kilometers", surely a cumbersome statement. Praemonitus (talk) 22:01, 23 July 2024 (UTC)

I must agree with this, I—anecdotally—would not expect most laypeople to understand what 1e13 km really means. To my knowledge, most educational platforms do not convert lyr or pc to km/mi (some examples: [27] [28] [29] [30]). It is clear that science communication as a whole deems conversions of lyr into km/mi as unhelpful and unneeded for most purposes. ArkHyena (talk) 22:20, 23 July 2024 (UTC)

I checked my state's curriculum standards, and exponential notation is required to be learned in eighth grade. So I would guess this has been taught to anyone who has completed their primary school education in a country with a decent education system. That doesn't include all our readers, and some people will have failed math or completely forgotten this concept. On radio broadcasts for popular consumption, I have definitely heard constructions like "billion billion" or "6 with 20 zeroes after it" in lieu of exponential notation, and also light-years.

Based on editors' personal reports here, it seems there are some people who think in light years and some who think in large numbers of kilometers. Why not have both to maximize accessibility and intuitive understanding? Anyone who knows what a parsec is almost certainly has a firm grasp on what a light-year is. -- Beland (talk) 22:38, 23 July 2024 (UTC)

The issue is that there are situations where this may introduce clutter with arguably marginal benefit, especially in infoboxes. I suppose introduction of conversion in main article text is fine, so long as km values are given in exponential notation to limit clutter. A potential compromise would be to add a note upon first mention of a lyr/pc in an article that provides km values for one lyr/pc; this is broadly similar (though not perfectly analogous) to how hurricane articles handle major hurricane status (e.g. at Hurricane Beryl). ArkHyena (talk) 23:27, 23 July 2024 (UTC)

That's an interesting idea...you're thinking light years converted to parsec in infoboxes, light-years converted to kilometers in article prose (and maybe only at first mention)? -- Beland (talk) 04:47, 24 July 2024 (UTC)

I'm opposed to the latter. If we're expecting students to know what a kilometre is and to grok out exponential notation, then it's reasonable to expect that they will also understand a light year. I see no need to provide a conversion to km in most cases. A link should suffice. Praemonitus (talk) 14:47, 24 July 2024 (UTC)

What do you mean with "understand" here? I know what a light-year is, in the abstract sense: It's the distance light travels in a year. And I, and guess most people, also know that light travels "very fast". But how much is "very fast" times one year? I don't have the foggiest idea, to be honest. Never having travelled at the speed of light, it is very hard to fathom for me, and as such essentially meaningless. Exponential notation, on the other hand, is not very hard to get, if you know how to do basic addition and multiplication. If I read 10¹³ km, I know I have to take one kilometre, multiply it with 1000, and again, and again, and again, and then finally with 10. Still abstract, admittedly, but now I have a much better sense of the dimension involved compared to "unimaginably fast times one year". Which is why I'm in favour of using exponential notation in addition to light-years or parsecs (I don't care which of them is chosen). Gawaon (talk) 15:09, 24 July 2024 (UTC)

I would perhaps prefer 10 Pm to 10¹³ km, but other than this detail I strongly agree with Gawaon. I can accept 10¹³ km if that is the consensus. I cannot accept omitting the conversion to SI - to do so would suggest that astronomy is beyond metrology, when it clearly is not. Notice the link to petametre takes the reader directly to an equation stating that a petametre is about 0.1 light-year. Dondervogel 2 (talk) 15:20, 24 July 2024 (UTC)

Oh come on. It suggests nothing of the sort (about astronomy being beyond metrology). Metrology is a whole discipline; SI is just a system of units, roughly as arbitrary as any other.

That said, I don't have a hardened objection to including an SI conversion, at least in infoboxes, though I wouldn't be thrilled to see them repeated over and over again in the running text. --Trovatore (talk) 16:18, 24 July 2024 (UTC)

OK, so I was exaggerating, for effect. A more measured remark would have been that even the IAU defines its units in terms of the SI, so why mark it unnecessarily hard on the reader by omitting that conversion on Wikipedia? I accept the SI is arbitrary, but it is THE single arbitrary system that we all (including Americans) learn at school, is used in day to day scientific work and is defined by international standards (BIPM).

Providing a conversion to SI in info boxes seems a good compromise. Dondervogel 2 (talk) 18:47, 24 July 2024 (UTC)

I would argue for the inverse, actually. Providing SI conversions in maintext whilst omitting them in infoboxes seems to be the best practice besides not having any. Infoboxes, especially those of astronomy, are already crowded with numbers; it would not help readability to shove yet more in them. ArkHyena (talk) 18:55, 24 July 2024 (UTC)

Right now light-years and parsecs are typically presented side-by-side in infoboxes. If one of them is replaced with a different unit, that wouldn't result in any additional clutter. Gawaon (talk) 19:04, 24 July 2024 (UTC)

Per SevenSpheres: The astronomical literature almost exclusively uses parsecs, because distance in parsecs can be derived directly from parallax, which is used to measure stellar distances. So it makes sense to use both units. I don't think I've seen interstellar distances expressed in kilometers much if at all before today ... On the topic of deriving distance from parallax, {{Starbox astrometry}} can do this automatically and is used this way in most star articles. So even if parsecs aren't used in the text, it doesn't make sense to remove them from the infobox

If we are to implement SI conversions, they are better-suited for the maintext (either as first mention or throughout), since that is presumably where most readers read. Astronomy infoboxes typically hold information about more obscure/technical (even if still very much relevant) properties for their respective objects. ArkHyena (talk) 19:32, 24 July 2024 (UTC)

"So I would guess this has been taught to anyone who has completed their primary school education in a country with a decent education system." - And most people don't work in science-related fields, and so never use scientific notation and thus have forgotten it. "10^13 km" and "1 light year" both translate to "very, very large", but the latter can at least allow comparison of distances--"it's only a few light years to the nearest star, but a million light years to the nearest galaxy."--whereas 10^13 km and 10^19 km are both equally meaningless as "very large", because they don't think in subtracting exponents. The prefixes are even worse, as anything beyond giga or tera are completely unfamiliar to most (and even those just mean "big" to many). - Parejkoj (talk) 06:50, 25 July 2024 (UTC)

No one is suggesting we stop using light-years (or parsecs if you prefer those - take your pick). We just prefer to include a conversion to SI, because we are all taught SI units. It's called the International System of Units for a good reason. Dondervogel 2 (talk) 07:08, 25 July 2024 (UTC)

I disagree. In this field of astronomy the governing body would be the International Astronomical Union, and the SI would only be focused on standardizing units relevant to common everyday measurements (and perhaps those in technology). And parsec is specifically defined in the notes of Resolution B2 in 2015. SkyFlubbler (talk) 12:02, 28 July 2024 (UTC)

Not everybody is an astronomer though, and our articles shouldn't be accessible to specialists only. Gawaon (talk) 12:58, 28 July 2024 (UTC)

But this is still a topic of astronomy, so of course we have to use units used by astronomers. By your logic we should not use radians as an angle measurement despite countless mathematical areas using it because "not everybody is a mathematician."

If they are seeking astronomy topics here in Wikipedia, the article for parsec is as simple as a mouse click. SkyFlubbler (talk) 23:31, 30 July 2024 (UTC)

In general, we don't use radians for angles, such as when discussing bicycle frames or sports or flowers). We use the much better-known degrees, unless there is a specific reason that radians make calculations or geometric expressions easier (which is why they exist). Radians are also much better-known than parsecs. I checked the Massachusetts curriculum standards; radians are part of the secondary school math requirements. Parsecs are not a requirement, and I would expect them to be first taught in undergrad astronomy classes (which obviously hardly anyone takes, though I did) or picked up as an extracurricular interest.

Certainly linking unfamiliar units like parsecs helps a lot of readers make more sense of them, but not everyone using Wikipedia has a mouse. Sometimes articles are printed out. Sometimes they are read out loud by a text-to-speech system - quite common for blind and visually impaired people, and also among people like me who use TTS to read articles while doing something else like yard work or doing the dishes. All of us screenreader users potentially have to listen to conversions for every single field in an infobox, which can get a bit tedious and make things harder to follow, especially if we don't know the definition of one of the units. -- Beland (talk) 02:55, 31 July 2024 (UTC)

What do you mean by "your logic"? I'm in favour of using parsecs, but against using only parsecs (or only non-SI units). Gawaon (talk) 05:58, 31 July 2024 (UTC)

This astronomy MOS was announced at WT:AST and considerable discussion has already happened there, and I already posted there a link to this discussion. I started this discussion because I wasn't comfortable creating an exception to MOS:CONVERSIONS without consulting the wider editor community beyond the WikiProject Astronomy. -- Beland (talk) 18:31, 23 July 2024 (UTC)

• Light-years are not an obscure or specialized unit; along with parsecs, they are the standard units used to measure interstellar and larger distances. While it's true that they're only used in one field, astronomy is the only field that deals with such large distances! This is different from, say, furlongs, which are on the same scale as kilometers.
• My thought is that interstellar distances expressed in kilometers are meaninglessly large numbers, while such distances expressed in light-years are more accessible to the general reader. Surprisingly though, there are comments saying the opposite! I find it hard to believe this is representative of the average reader though; surely most people who understand scientific notation also understand what a light-year is? That if a star is 100 light-years away, its light takes 100 years to reach us and so we see it as it was 100 years ago?
• In terms of common usage, sources aimed at the general public (like the NASA pages linked above) almost exclusively use light-years, presumably because, again, this is the most accessible unit to the general public. The astronomical literature almost exclusively uses parsecs, because distance in parsecs can be derived directly from parallax, which is used to measure stellar distances. So it makes sense to use both units. I don't think I've seen interstellar distances expressed in kilometers much if at all before today.
  • (On the topic of deriving distance from parallax, {{Starbox astrometry}} can do this automatically and is used this way in most star articles. So even if parsecs aren't used in the text, it doesn't make sense to remove them from the infobox.)
• A proposed change of this kind that would affect so many articles should be more widely advertised; I suspect everyone who's commented here watches either this page and/or WikiProject Astronomy where this was mentioned.

SevenSpheres (talk) 00:21, 24 July 2024 (UTC)

If we decide to suppress parsecs from reader view, {{Starbox astrometry}} can simply be changed to convert to light-years or whatnot. It's actually a lot easier to do that than change 1,000 articles that are not using a template feature like that, which I am sadly already doing for a lot of problems. -- Beland (talk) 04:51, 24 July 2024 (UTC)

There's no way a light-year is a standard unit. It is not defined by international standards bodies, and according to the IAU, light-years are "mostly confined to popular publications and similar media". And I suspect there are more readers who think the light-year is a unit of time than ones who would be confused by use of the metre (or kilometre) as a unit of distance. If there is a standard unit in astronomy, it is the parsec, not the light-year. Dondervogel 2 (talk) 11:21, 24 July 2024 (UTC)

I don't there exists anyone who thinks light-year is a unit of time but understands what a parsec is. Ironically enough, the creators of Star Wars thought parsec was a unit of time. Tercer (talk) 12:32, 24 July 2024 (UTC)

@SevenSpheres: FYI 1 furlong is 201.168 m, so not quite the "same scale". Martin of Sheffield (talk) 14:14, 24 July 2024 (UTC)

Corrected. SevenSpheres (talk) 15:10, 24 July 2024 (UTC)

Where would you like to see this discussion "more widely advertised"? -- Beland (talk) 15:57, 24 July 2024 (UTC)

WP:RFC? SevenSpheres (talk) 16:16, 24 July 2024 (UTC)

If we're doing that, we should summarize the discussion into some clear options. How about this for a question with neutral background material:

----

How should distances between stellar systems and longer be presented in infoboxes? (These are often calculated automatically from different units presented in astronomy sources, such as parallax.)

Examples from Local Interstellar Cloud, Andromeda Galaxy, Proxima Centauri, and Betelgeuse.

A.) Light-years and kilometers only in infoboxes:

• 30 ly (2.8×10¹⁴ km)
• 2.50 Mly; 2.36×10¹⁹ km
• 4.2465 ± 0.0003 ly
  4.0175×10¹³ ± 2.8382×10⁹ km
• 408–548+90
  −49 ly (3.86×10¹⁵–5.18+0.85
  −0.46×10¹⁵ km)

B.) Light-years and parsecs only in infoboxes

• 30 ly (9.2 pc)
• 2.50 Mly; 765 kpc
• 4.2465 ± 0.0003 ly
  1.3020 ± 9.1980×10⁻⁵ pc
• 408–548+90
  −49 ly (125-168.1+27.5
  −14.9 pc)

C.) Light-years and meters with larger prefixes in infoboxes

• 30 ly (280 Pm)
• 2.50 Mly; 23.6 Zm
• 4.2465 ± 0.0003 ly
  40.1750 ± 0.0028 Pm
• 408–548+90
  −49 ly
  3.86–5.18+0.85
  −0.46 Em

D.) Light-years and parsecs only in infoboxes (like B), with conversion to kilometers on first mention in prose

E.) Something else

If conversion to kilometers in infoboxes is not required, this would be added as an explicit exception to MOS:CONVERSIONS.

Previous discussions identified that parsecs are used by professional astronomers and light-years are used in popular news and educational media. Editors disagreed on whether light-years or kilometers with exponential notation were easier to read and understand intuitively for most readers.

----

-- Beland (talk) 18:10, 24 July 2024 (UTC)

(Edited to link units.) -- Beland (talk) 18:16, 24 July 2024 (UTC)

How about "Parsecs and kilometers only in infoboxes" as further option, since that combination has been mentioned as well? Also, if you suggest 5 or 6 different options, it's quite likely that none of them will gain an absolute majority, resulting in an unclear outcome.

An alternative question might be something along the lines of "Since it's cumbersome to present more than two alternative units, which two should preferably to used for interstellar distances?", with the options being:

A. Light-year

B. Parsec

C. Kilometre with exponential factor

D. Metre with SI prefix

And every editor asked to pick their two favourites. Gawaon (talk) 18:54, 24 July 2024 (UTC)

OK, maybe we should ask the "pick two" separately for prose and infoboxes, since there seems to be a stronger leaning toward different practices, and it would be nice to get a clear result for both if we're bothering everyone to consider the question. -- Beland (talk) 22:02, 24 July 2024 (UTC)

Okay, why not, though personally I see no good reason to treat them differently. Gawaon (talk) 06:11, 25 July 2024 (UTC)

Some editors have expressed different preferences for prose vs. infobox...at this point I've thought about all this too much and don't know how I feel about anything. Revised draft RFC posted in subsection below; everyone feel free to tweak or critique. -- Beland (talk) 07:32, 25 July 2024 (UTC)

If you're referring to my comment, I haven't expressed different preferences for prose vs. infobox, only a stronger preference to retain the status quo in infoboxes. SevenSpheres (talk) 14:55, 25 July 2024 (UTC)

I was thinking of ArkHyena's proposal to convert to km on first mention in prose but not infoboxes. -- Beland (talk) 19:48, 25 July 2024 (UTC)

IAU definitions are about as standard as you're going to get in astronomy. Per the IAU style manual, the "unit known as the light-year is appropriate to popular expositions on astronomy and is sometimes used in scientific papers as an indicator of distance".[31] "The light-year is roughly equivalent to 0.3 parsecs, and is equal to the distance traveled by light in one Julian year in a vacuum, according to the IAU."[32] The parsec does have a standard IAU definition, although it is a much less well known unit in the public space. Praemonitus (talk) 14:54, 24 July 2024 (UTC)

Looking again at MOS:CONVERSIONS, I think In some topic areas [...] it can be excessive to provide a conversion for every quantity applies here, though unlike light-years the examples given are at a scale where metric units are typically used. As I've said, I don't think For units of measure that are [...] obscure outside of a particular specialty or geography applies; not part of the SI or US customary systems may apply but that's not the part that was mentioned. SevenSpheres (talk) 18:22, 24 July 2024 (UTC)

Are you arguing for leaving some quantities in infoboxes unconverted from the preferred unit, or are you thinking of omitting conversions only in prose? -- Beland (talk) 18:39, 24 July 2024 (UTC)

The opposite, as per e.g. [33] I would more strongly prefer to retain the status quo in infoboxes than in prose. SevenSpheres (talk) 19:03, 24 July 2024 (UTC)

OK, that looks like a vote for light-years and parsecs in infoboxes with kilometers in prose but not to excess. I consider the status quo to be "SI conversions are required in infoboxes" because of MOS:CONVERSIONS, but in practice for the ones I've seen, the status quo is light-years and parsecs. -- Beland (talk) 22:01, 24 July 2024 (UTC)

All I will say is that this discussion seems to connect with the one I began about prefixes. Looking at this thread it seems I might not be alone here. Avenues2009 (talk) 23:18, 29 July 2024 (UTC)

Sure; feel free to share your preferences in the RFC thread. -- Beland (talk) 01:19, 30 July 2024 (UTC)

Draft RFC question

Version 1

How should distances between stellar systems and longer be presented in astronomy articles? (These are often calculated automatically from different units presented in astronomy sources, such as parallax.) Previous discussions identified that parsecs are used by professional astronomers and light-years are used in popular news and educational media; those two units are currently the most commonly used and converted to each other. Editors disagreed on whether light-years or kilometers with scientific notation were easier to read and understand intuitively for most readers. If conversion to SI units (like kilometers) is not required in certain contexts, this would be added as an explicit exception to MOS:CONVERSIONS.

More than two units per quantity is cumbersome, so we're asking folks to pick their TOP TWO from:

• Light-year (ly)
• Parsec (pc)
• Kilometer in scientific notation (km)
• Meter with metric prefix (?m)

Infobox examples using quantities from Local Interstellar Cloud, Andromeda Galaxy, Proxima Centauri, and Betelgeuse:

• ly and km:
  • 30 ly (2.8×10¹⁴ km)
  • 2.50 Mly; 2.36×10¹⁹ km
  • 4.2465 ± 0.0003 ly
    4.0175×10¹³ ± 2.8382×10⁹ km
  • 408–548+90
    −49 ly (3.86×10¹⁵–5.18+0.85
    −0.46×10¹⁵ km)
• ly and pc:
  • 30 ly (9.2 pc)
  • 2.50 Mly; 765 kpc
  • 4.2465 ± 0.0003 ly
    1.3020 ± 9.1980×10⁻⁵ pc
  • 408–548+90
    −49 ly (125-168.1+27.5
    −14.9 pc)
• ly and ?m:
  • 30 ly (280 Pm)
  • 2.50 Mly; 23.6 Zm
  • 4.2465 ± 0.0003 ly
    40.1750 ± 0.0028 Pm
  • 408–548+90
    −49 ly
    3.86–5.18+0.85
    −0.46 Em

Please let us know if you prefer the SAME or DIFFERENT for INFOBOXES vs. PROSE (or if you prefer some other solution). We assume that for prose the "unless this would be excessive given the context" rule from MOS:CONVERSIONS will still apply.

Version 2

How should distances between star systems and galaxies be presented? These are measured in light years (ly) in popular news and educational media; professional astronomers use parsecs (pc). Articles currently use a variety of units (some only ly and ly converted to km) but most commonly use ly converted to pc in infoboxes (often automatically from technical data). If conversion to SI units (like kilometers) is not required in certain contexts, this would be added as an explicit exception to MOS:CONVERSIONS. The maximum distance in the observable universe is under 100 billion light-years, and interplanetary distances (inside a star system) are a fraction of a light-year and are measured in astronomical units (AU or au).

Two formats are needed: an expanded format for use in article prose (especially on first mention), and a compact format for infoboxes, tables, and prose where the expanded format would be excessively long. The "unless this would be excessive given the context" rule from MOS:CONVERSIONS will still apply when the units are used several times in prose.

The units nominated in previous discussion are:

• Light-year (ly)
• Parsec (pc)
• Kilometer (km)
• Meter (m)

Units can be written in words or symbols, but if symbols are used, MOS:NUMNOTES says the number part must be written in numbers (e.g. 12 million km, not twelve million km). First use of light-year/ly and parsec/pc must be linked to their articles, per MOS:UNITS.

The notations that can express very large quantities are:

• Words (million, billion, trillion, and so on in names of large numbers)
• Metric prefixes, namely: Gly, Mly, kly, Gpc, Mpc, kpc, Ym, Zm, Em, Pm, Tm
• Scientific notation, often used with km (which already have a metric prefix), e.g. 8.8×10²⁰ km
• Long numerals, e.g.: 93,000,000 ly (88,000,000,000,000,000,000 km)

Formatting details are delegated to {{convert}} and {{val}}, which may be helpful in expressing your preferences below.

The chosen formats need to accommodate simple cases and complex expressions of precision like:

• 30 ly (2.8×10¹⁴ km)
• 2.50 Mly (765 kpc)
• 4.2465 ± 0.0003 ly
  4.0175×10¹³ ± 2.8382×10⁹ km
• 408–548+90
  −49 ly (125-168.1+27.5
  −14.9 pc)

Please specify which order the units should appear in, if you have a preference.

(sample votes shown)

Compact format (specify preferred units, notation, and order)

• ly only, with metric prefixes. "34.5 Mly ± .3Mly". Infoboxes get overwhelmingly numbery if they have conversions. - User 1
• ly converted to pc, both in exponential notation. "34.5×10⁹ ly (1.06×10¹⁰ pc)". Astronomers need parsecs for convenience. - User 2

Expanded format (specify preferred units, notation, and order)

• "Light year" converted to km, in exponential notation. "34.5 million light years (3.26×10²³ km) " - User 1
• "Light years" converted to "kilometers" then "parsecs", in words, but no higher than trillion. "34.5 million light years (326 billion trillion kilometers; 10.6 billion parsecs) plus or minus .3 million light years." - User 2

Version 3

What units should be used for distances between star systems and galaxies? These are measured in light years (ly) in popular news and educational media; professional astronomers use parsecs (pc). Articles currently use a variety of units (some only ly and some ly converted to km) but most commonly use ly converted to pc in infoboxes (often automatically from technical data). If conversion to SI units (like kilometers) is not required in certain contexts, this would be added as an explicit exception to MOS:CONVERSIONS. The maximum distance in the observable universe is under 100 billion light-years, and interplanetary distances (inside a star system) are a fraction of a light-year and are measured in astronomical units (AU or au).

Two formats are needed: an expanded format for use in article prose (especially on first mention), and a compact format for infoboxes, tables, and prose where the expanded format would be excessively long. The "unless this would be excessive given the context" rule from MOS:CONVERSIONS will still apply when the units are used several times in prose. First use of light-year/ly, parsec/pc, and rare meter prefixes (e.g. zettameter) must be linked to their articles, per MOS:UNITS. The chosen formats need to accommodate simple cases and complex expressions of precision (examples below).

The choices nominated for inclusion are:

• Light-year (ly) with SI prefixes (kly, Mly, Gly) and large number words (million, billion) in prose
  • 34.6 ± 0.3 million light-years (ly) [first mention in prose]
  • 34.6 ± 0.3 Mly [compact]
  • 408–548+90
    −49 ly [compact]
• Parsec (pc) with SI prefixes (kpc, Mpc, Gpc)
  • 765 ± 2 kiloparsecs (kpc) [first mention in prose]
  • 765 ± 2 kpc [compact]
  • 125-168.1+27.5
    −14.9 pc [compact]
• Kilometer (km) with scientific notation
  • 3.27×10¹⁴ km [compact, secondary in prose]
  • 3.273×10¹⁴ ± 2.8×10¹² km [compact, secondary prose]
  • 68.1+7.5
    −4.1×10¹⁴ km [compact, secondary in prose]
  • 3.27×10¹⁴ kilometres [primary expanded]
• Meter with SI prefixes (Ym, Zm, Em, Pm, Tm)
  • 68.1 zettameters (Zm) [first mention in prose]
  • 68.1 Zm [compact]
  • 68.1+7.5
    −4.1 Zm [compact]

You can of course advocate for as many or few options as you find appropriate, or assert multiple options are equally good, but previous discussion has assumed at most two units would be used because many editors find three to be excessive. Please specify your preferred order; "primary" units come first and other units are converted to (typically in parentheses in prose, sometimes on a new line or after semicolon in infoboxes).

(sample votes shown)

Your preferred units

Please note your preferred units for both compact-in-infobox and expanded-in-prose if they are different.

• Light-years only. Conversions make science overwhelmingly numbery. - User 1
• Light years converted to parsecs in infoboxes for astronomers, kilometers in prose for general audience. - User 2

Discussion

• For clarity I would suggest using the same format for all examples (always put the second unit in brackets or maybe always use a semicolon between them, instead of semicolons, brackets, and line breaks mixed). Otherwise it looks fine to me. Gawaon (talk) 08:07, 25 July 2024 (UTC)
• I'm afraid it's hard to decipher your illustrative possibilities; I think it's better to say explicitly that you are displaying the same data using the three combinations (ly, km), (ly, pc), and (ly, ?m). Also, it might be worth noting that (ly, pc) is already a de facto standard. Tercer (talk) 08:35, 25 July 2024 (UTC)

  Tweaked to add headers for clarity. -- Beland (talk) 09:27, 25 July 2024 (UTC)

  And added note about the status quo in articles, per your suggestion. -- Beland (talk) 09:28, 25 July 2024 (UTC)

In articles, I see semicolons, parentheses, and new lines in infoboxes. -- Beland (talk) 09:24, 25 July 2024 (UTC)

Okay. Gawaon (talk) 10:28, 25 July 2024 (UTC)

I have two comments

• I object to using megalight-years in the examples. While light-years are commonly used, megalight-years are not (and the unit in any case should be light-megayear, not megalight-year). Saying "2.5 million light-years" is fine. Saying "2.5 megalight-years" is not.
• I'm not sure the question is well posed. Surely we are all assuming the primary unit is either light-year or parsec, and the question should then be "what are converting it to?"

Dondervogel 2 (talk) 09:59, 25 July 2024 (UTC)

That's not true. Mly is commonly used. "light-megayear" is non-existent. Tercer (talk) 10:31, 25 July 2024 (UTC)

I meant that in a relative sense. In other words, use of the megalight-year is less common than that of the light-year. I accept that light-megayear is rarely used, but if one uses light-second, light-minute, light-day and light-year, the obvious next steps are light-century, light-kiloyear and light-megayear. That was my point.

That said, my main objection to use of megalight-year, gigalight-year is the absence of an authoritative/standard definition of these units. The IAU does not define them, so who does? Perhaps the same question applies to the megaparsec, but that seems somehow less controversial. I'm not sure why. Dondervogel 2 (talk) 16:44, 25 July 2024 (UTC)

I'd say if Mly is used in existing pages, it's okay to use it in an example too. Gawaon (talk) 17:36, 25 July 2024 (UTC)

I mean, why would the IAU have to define them when mega- and giga- prefixes are already well-defined? This doesn't seem to be a very good justification to not use them; AFAIK, no organization "officially defines" what a kiloton or megaton is, but articles about nuclear tests and volcanic eruptions use them all the time in TNT-equivalent units simply because kt and Mt are useful and widely used. ArkHyena (talk) 17:40, 25 July 2024 (UTC)

I'll pay you 10€ if you can find a single example of light-megayear used in a peer-reviewed paper. I see your point about the logical progression of the units, but the fact of the matter is that this is not how astronomers use it. Tercer (talk) 17:54, 25 July 2024 (UTC)

Hmmm ... that's an interesting challenge. I can't guarantee to find light-megayear, but I would be surprised if a search for light-kiloyear, light-megayear and light-gigayear doesn't come up with something. Watch this space ... Dondervogel 2 (talk) 19:20, 25 July 2024 (UTC)

... I found this mention of a light-gigayear. See also [34] Project Astronomy Archive 17, where it appears the same question arose 9 years ago, and with the same outcome. Dondervogel 2 (talk) 19:37, 25 July 2024 (UTC)

Light-gigayear is fair enough, but I did specify a peer-reviewed paper. Tercer (talk) 20:08, 25 July 2024 (UTC)

You did indeed, so I am not claiming my 10 EUR just yet. I'll keep watching out for an example :P Dondervogel 2 (talk) 20:13, 25 July 2024 (UTC)

It just dawned on me that the reason I can't find light-megayear in peer-reviewed papers is that peer-reviewed papers use the parsec (and megaparsec), not the light-year. The light-year is used in popular literature only, where it does not need a rigorous definition. Perhaps that explains why Mpc seems less controversial (to me) than Mly. Dondervogel 2 (talk) 20:23, 25 July 2024 (UTC)

While parsecs are clearly the unit of choice, plenty of peer-reviewed astronomy papers do use light-years: [35] [36] [37]. Tercer (talk) 20:44, 25 July 2024 (UTC)

Sometimes I really do wish astronomers and science communicators would use just one unit instead of two... ArkHyena (talk) 20:50, 25 July 2024 (UTC)

Yes, I see those articles use the light-year (though in one case only in the title). Do you know one that uses the megalight-year? Dondervogel 2 (talk) 20:56, 25 July 2024 (UTC)

It looks like Morrison and Sartori 1965 might use the light-kiloyear. I can't be sure because it's behind a paywall. Does anyone have access to Phys Rev Lett? Dondervogel 2 (talk) 21:19, 25 July 2024 (UTC)

I found it and yes, they talk about "R ~ 10 light kiloyears". Gawaon (talk) 22:07, 25 July 2024 (UTC)

I have checked, and indeed, that's a light kiloyear. Not a light-megayear, but I think it's good enough. Please email me your IBAN through Special:EmailUser/Tercer so that I can pay you what I owe. Tercer (talk) 08:33, 26 July 2024 (UTC)

Light-year#Definitions has citations to textbooks for kly, Mly, and Gly, kilolight-year, megalight-year, and gigalight-year. English isn't always a logical or consistent language, but we use it as it is. There doesn't seem to be any disagreement about what these units mean; they adopt the SI prefixes straightforwardly. Mly, Gly, kpc, and Mly are currently used in a lot of articles, but I also see constructions like "70,000,000 ly" in infoboxes and "70 million light years" in prose. These units are a lot more compact and a lot cleaner when there are ±, and they have commonly-used prefixes people are familiar with from computer hardware. Beland (talk) 17:56, 25 July 2024 (UTC)

We can ask this question two ways: 1. pre-discuss possibilities and offer up the most popular (among astro-enthusiast editors) and logically coherent choices in an effort to make the question easy to answer and consensus easy to discern, or 2. open voting to arbitrary combinations and have faith that The People will Do the Right Thing. I started with approach 1, but Gawaon requested approach 2. If we're sticking with approach 2, I'm inclined to let the wisdom of the crowd decide which unit they want as primary. If 70% of people vote to make kilometers primary, then that's surprising but useful information to make the encyclopedia more readable to the general public, and no one can complain the question was biased and we need to do another RFC. We've been talking about two units of measure as the optimal number, but the more articles I look at, the more I wonder if 1 or 3 wouldn't be better, depending on whether we want to make things clear and easy to understand (which some articles already do) or give everyone immediate handy access to a number in the units they are thinking or calculating in.

I was originally thinking of this only as a question for infoboxes, but the more articles I look at, the more I realize that quantities are presented very differently in prose. For example, "72 million light-years" is much more reader-friendly than either "7.2 × 10⁶ ly" or "7.2 Mly", and the friendly version is often used in prose. Perhaps we should frame the question as asking people to define "compact" and "expanded" formats. In prose, we often use an expanded format on first mention of an unfamiliar-to-everyday-life unit (like light-years), and then compact formatting for later uses to avoid excessive length. We also use compact formats for tables, not just infoboxes. MOS:NUMNOTES has some things to say about this already, but doesn't make all the choices we have questions about.

When we write $2M in prose, we write two million dollars, not two megadollars, and I agree 2Mly should be written as two million light years, megatons notwithstanding. I'll add some prose examples showing the default interpretation of choosing certain units. Beland (talk) 18:23, 25 July 2024 (UTC)

I didn't mean to ask about "primary" and "secondary", only about the preferred combinations of two units (considering that regularly using more would be impractical). I think the only truly "odd" result from the astronomers' viewpoint would be if kilometres and prefixed metres were chosen, with both light-years and parsecs discarded. But I think that's a very unlikely outcome, hence I believe we can trust the "wisdom of the crowd" to find a reasonable combination. Gawaon (talk) 19:08, 25 July 2024 (UTC)

(Also I didn't mean to "request" anything, it was just a suggestion to make the multiple logical possibilities easier to handle.) Gawaon (talk) 19:12, 25 July 2024 (UTC)

Sure, it was a good suggestion! BTW, I've drafted a second version of the RFC question making the variables more explicit and connecting to some existing rules so hopefully we don't have to re-debate those. Too much? -- Beland (talk) 19:37, 25 July 2024 (UTC)

@Beland: I question the assertion that there is no dispute about the meaning of megalight-year. According to this unit converter, a megalight-year is equal to 999315.53730322 light-years. Is that the conversion you would expect? Dondervogel 2 (talk) 19:25, 25 July 2024 (UTC)

Seems like a floating point error. SevenSpheres (talk) 19:35, 25 July 2024 (UTC)

I doubt it's a floating point error. More likely a consequence of the ambiguity between a megaannum (precisely 365.25 million days, following the IAU convention, using Julian years) and one million years (approximately 365.2422 million days). I don't think the arithmetic works out to explain that weird conversion, but my fundamental point is that such units are undefined, and therefore ambiguous. Dondervogel 2 (talk) 19:52, 25 July 2024 (UTC)

This website is clearly suffering from rounding errors. It converts 9999999999999 mm to 9999.999999999001 Mm. It's pretty clearly a not-so-carefully semi-automatically created SEO honeypot. -- Beland (talk) 19:56, 25 July 2024 (UTC)

Somebody used "365.5" when entering one unit into the database, and "365.25" for the other: 999315.53730322 / 365.25 = 365.5×10⁻⁶. Indefatigable (talk) 19:58, 25 July 2024 (UTC)

Nice catch! Tercer (talk) 20:11, 25 July 2024 (UTC)

...hmm, it does actually say that in the text though... but it also says One megalight-year [...] is one million light-years. That website is probably not the most reliable source in any case. SevenSpheres (talk) 19:37, 25 July 2024 (UTC)

Shitty websites making mistakes prove nothing. If you want to demonstrate that there is a dispute about the definition of megalight-year you need to find reliable sources saying so. Tercer (talk) 19:50, 25 July 2024 (UTC)

Uh-uh. The unit remains ambiguous until it is defined. And there is never a justification for using this particular ambiguous unit when we can easily write "one million light-years", with no ambiguity. Dondervogel 2 (talk) 19:54, 25 July 2024 (UTC)

I fail to see how "megalight-year" would remotely be ambiguous, unless the metric prefix "mega-" itself is ambiguous. ArkHyena (talk) 20:01, 25 July 2024 (UTC)

But the prefix mega- (as in megabyte) IS ambiguous. I suspect you realised that before adding the "metric" qualifier. For the definition we rely on a handful of sources from the light-year article. Is that really enough? And I repeat we can always write "one million light years" (or "one billion light years" for giga), so why confuse our readers with the prefix? Dondervogel 2 (talk) 20:10, 25 July 2024 (UTC)

That particular case is does seem to be exceptional due to its usage within compsci, but honestly I doubt people who are aware of that oddity would apply it to other units. "Mega-", regarding units, seems to be universally understood to mean 10⁶ unless specified otherwise, regardless if the unit it is applied to is SI or not. A megatonne of TNT equivalent is one million tonnes of TNT equivalent. A megaelectronvolt is one million electronvolts. And so on.

The one possible point of confusion is that "mega-" in colloquial usage does not strictly refer to the metric prefix, e.g. "megadonor", but TMK people generally recognize that, when affixed to a unit of measurement, "mega-" indeed means 10⁶. ArkHyena (talk) 20:22, 25 July 2024 (UTC)

Can we agree to write "6.7 million light years" instead of "6.7 mega-light-years" and "9.8 megaparsecs" (which seems standard) and 6.7 Mly and 9.7 Mpc for short? I don't think anyone is going to be confused into thinking that the "M" uses the 1000x scale instead of 1024x for light years but not parsecs. Certainly not people who know enough to need the numbers for precise calculations, who seem to be using Mly in technical papers with zero confusion. 1000x is what everyone in America is taught in school when we learn the metric system. Almost anyone who knows about the 1024x scale should know it's only used for computers. Our main audience is the general public to whom we're giving these numbers just to get a general sense of things (at which point 1000x vs. 1024x doesn't matter). -- Beland (talk) 22:19, 25 July 2024 (UTC)

Reliable sources do define Mly as exactly one million light-years, as cited at light-year. Definitions of units don't need to be blessed by a government or professional body to have a clear meaning, any more than "straight up" needs an English equivalent of the French Academy to legally define which vector I mean by that. This web site is unambiguously making an error. -- Beland (talk) 20:01, 25 July 2024 (UTC)

• Since some votes will differ in options for infobox vs. prose (or some contributors may want to add notes specific to one or the other), it may be best to set up two separate surveys (e.g. survey for infoboxes/survey for prose) once the RfC is pushed out for organizational reasons. ArkHyena (talk) 10:56, 25 July 2024 (UTC)

  Excellent suggestion; implemented in Version 2 of the draft above. -- Beland (talk) 19:38, 25 July 2024 (UTC)

  My preference (and I don't think I am alone here) would be

  • primary unit: parsec or light-year
  • converted unit: any SI unit

  I don't see this preference represented in the choices offered. Dondervogel 2 (talk) 19:59, 25 July 2024 (UTC)

  That seems like a perfectly valid not-vote. We didn't say you couldn't pick multiple items off the menu as equally good in whatever slot. I assume "any SI unit" means you don't care if we use m or km, and don't care if we use exponential notation or metric prefixes or long numerals or words. -- Beland (talk) 20:06, 25 July 2024 (UTC)

  Yes, that is a correct interpretation. Dondervogel 2 (talk) 20:17, 25 July 2024 (UTC)

  While I see the ideas behind Version 2, I think it's too complicated. We can't expect everyone to express separate preferences for compact and expanded format, and nobody should have to think about which prefixes for light-years they prefer. I'd keep it simpler, more in line with version 1: You have four possible units (ly, pc, km/scientific, m with prefix) – pick the two you prefer. Maybe Preferably ask for first and second unit too. My choices, similar to Dondervogel 2: ly or pc as first, km/scientific as second. Gawaon (talk) 20:08, 25 July 2024 (UTC)

  I'd also argue for this. More complex options would probably prolong discussion and make things messier than they need to be. This discussion here is already quite protracted. ArkHyena (talk) 20:13, 25 July 2024 (UTC)

  OK, so to clarify:

  • We're limiting this RFC to the compact format intended for infoboxes and tables, and after we get a clear answer on that discuss what to do about prose?
  • Are we pre-selecting a notation for extremely long distances for ly and pc? According to parsec, Gpc, Mpc, and kpc are standard. Despite the one-editor objection above, Gly, Mly, and kly seem to be used and understood, and seem a lot more compact than 93,000,000 ly (especially if there's an error margin) and more comprehensible and less cluttery than exponential notation.

  -- Beland (talk) 22:10, 25 July 2024 (UTC)

  We can probably survey for infoboxes and prose simultaneously, especially since I'd figure someone would bring up prose conventions at some point if it is not included in the first place—we'd just have to partition the survey as aforementioned to hopefully keep things smooth. And yes, Gpc, Mpc, kpc; and Gly, Mly, and kly seem to be well-established standards in relevant articles. ArkHyena (talk) 22:35, 25 July 2024 (UTC)

  Should we then assume the expanded form (prose first or infrequent mention) would use unit names instead of symbols?

  Should we also assume we're not using scientific notation for the expanded form and we'll use the words for multipliers greater than "thousand"? For example, "34.5 million light years (326 billion trillion kilometers)" if those units win the not-vote? ("Sextillion" isn't even in all dictionaries listed by Names of large numbers; when English Wikipedia uses it, it tends to be accompanied by exponential notation or other -illion words to explain what it means.) -- Beland (talk) 02:49, 26 July 2024 (UTC)

  No, of course not, with distances like this, scientific notation will have to be used for kilometres in any case. Stuff like "billion trillion" is impractical to write and confusing to read. (And probably also confusing to write – indeed I think it should have been "billion billion" or "million trillion" (10¹⁸).) Gawaon (talk) 05:35, 26 July 2024 (UTC)

  Also, it's common to abbreviate converted units in brackets also in prose, and I would assume that for our survey too. So the above example could be written as 34.5 megalight-years (3.26×10²⁰ km) – that's how {{convert}} does it. Though actually "million light-years" is probably better than "megalight-years" in prose. While I agree with that, I don't think such details should be part of this RfC, that would just be a needless overcomplication. Gawaon (talk) 05:58, 26 July 2024 (UTC)

  OK, I've integrated all your suggestions into Version 3, above, which does feel a lot less overwhelming and easier to answer. I've tried to leave no ambiguity in the examples and use only formats with the strongest support, in case they are later taken as prescriptive (which they kind of will be if no one complains about them), and so no one can complain "if I'd known that's how we'd be writing this, I'd have voted differently". -- Beland (talk) 16:13, 26 July 2024 (UTC)

  Yeah, that version looks fine to me. Gawaon (talk) 16:18, 26 July 2024 (UTC)

  Yes, I agree it's reasonable to survey for infoboxes and prose together. People who have different preferences of units for one vs. the other should simply express that as part of their vote – I for one don't. But keep it one survey, with the option to express separate preferences for both in case they differ – nobody should be forced to vote twice, and certainly not in different sections. Stuff like Gpc and Mly sounds reasonable too, so we can used it in examples, but it's not what the RfC is about. Gawaon (talk) 05:34, 26 July 2024 (UTC)

• Version 3 reads good to me! Gawaon (talk) 16:12, 26 July 2024 (UTC)

  Agree here, version 3 looks good to go. ArkHyena (talk) 21:36, 26 July 2024 (UTC)

• I just noticed that astronomical unit is absent. Is this a deliberate omission? Dondervogel 2 (talk) 16:23, 26 July 2024 (UTC)

  Yes. Based on comments by Modest Genius and general practice I see observed in articles and the popular media, AU are used for distances inside star systems, but not the much larger distances between star systems. One light-year is about 63,240 AU, so even for relatively short interstellar distances, the numerical quantities are getting into the range where we'd normally start considering applying metric prefixes or exponential notation. 1 AU is the size of the Earth's orbit, so it makes sense to use these units for easy, intuitive comparisons of planetary orbits, and not for measurements on vastly different scales. I think it's unlikely that even if offered the choice, the wisdom of the crowd will favor AU, but that said, if anyone has strong feelings and wants to nominate AU to be included, I'm happy to add them. -- Beland (talk) 17:02, 26 July 2024 (UTC)

  That's very reasonable. No need to add them on my behalf. I just wanted to check it was not an oversight. I also approve of the Version 3 wording. Thanks to those who have invested their time in the multiple iterations. Dondervogel 2 (talk) 20:27, 26 July 2024 (UTC)

  Woo! If no one has any further suggestions or objections, I'll start the RFC with the version 3 text in the next 24-48 hours. -- Beland (talk) 20:33, 26 July 2024 (UTC)

RFC for units of the longest distances

What units should be used for distances between star systems and galaxies? These are measured in light years (ly) in popular news and educational media; professional astronomers use parsecs (pc). Articles currently use a variety of units (some only ly and some ly converted to km) but most commonly use ly converted to pc in infoboxes (often automatically from technical data). If conversion to SI units (like kilometers) is not required in certain contexts, this would be added as an explicit exception to MOS:CONVERSIONS. The maximum distance in the observable universe is under 100 billion light-years, and interplanetary distances (inside a star system) are a fraction of a light-year and are measured in astronomical units (AU or au). 01:40, 28 July 2024 (UTC)

Two formats are needed: an expanded format for use in article prose (especially on first mention), and a compact format for infoboxes, tables, and prose where the expanded format would be excessively long. The "unless this would be excessive given the context" rule from MOS:CONVERSIONS will still apply when the units are used several times in prose. First use of light-year/ly, parsec/pc, and rare meter prefixes (e.g. zettameter) must be linked to their articles, per MOS:UNITS. The chosen formats need to accommodate simple cases and complex expressions of precision (examples below).

The choices nominated for inclusion are:

• Light-year (ly) with SI prefixes (kly, Mly, Gly) and large number words (million, billion) in prose
  • 34.6 ± 0.3 million light-years (ly) [first mention in prose]
  • 34.6 ± 0.3 Mly [compact]
  • 408–548+90
    −49 ly [compact]
• Parsec (pc) with SI prefixes (kpc, Mpc, Gpc)
  • 765 ± 2 kiloparsecs (kpc) [first mention in prose]
  • 765 ± 2 kpc [compact]
  • 125-168.1+27.5
    −14.9 pc [compact]
• Kilometer (km) with scientific notation
  • 3.27×10¹⁴ km [compact, secondary in prose]
  • 3.273×10¹⁴ ± 2.8×10¹² km [compact, secondary prose]
  • 68.1+7.5
    −4.1×10¹⁴ km [compact, secondary in prose]
  • 3.27×10¹⁴ kilometres [primary expanded]
• Meter with SI prefixes (Ym, Zm, Em, Pm, Tm)
  • 68.1 zettameters (Zm) [first mention in prose]
  • 68.1 Zm [compact]
  • 68.1+7.5
    −4.1 Zm [compact]

You can of course advocate for as many or few options as you find appropriate, or assert multiple options are equally good, but previous discussion has assumed at most two units would be used because many editors find three to be excessive. Please specify your preferred order; "primary" units come first and other units are converted to (typically in parentheses in prose, sometimes on a new line or after semicolon in infoboxes).

01:40, 28 July 2024 (UTC)

Your preferred units

Please note your preferred units for both compact-in-infobox and expanded-in-prose if they are different.

• Light-years only. If there's a second unit, strong preference for kilometers. Astronomy infoboxes are already number-heavy; adding conversions makes them even more overwheming and unapproachable to the general public, which is a chronic problem in popularizing science. Light-years give nice, easy-to-understand small numbers for which we don't need exponential notation, avoiding overloading brains and having people mentally label everything from planets to galaxies as "incomprehensibly far" and more or less equally distant. It's easy to remember Alpha Centauri is about 4 ly away and the Milky Way is ~100,000 ly across and calibrate intuition from there. The speed of interstellar spacecraft (of which there are none) are sensibly measured in fractions of c, not km/s, and not parsecs per year (!?). If there is going to be a secondary unit, I strongly prefer kilometers, for consistency with all other articles and smaller measurements in infoboxes. Parsecs are too close to light-years and are only useful to specialists, who can easily do the conversion if they need to. I'm less opposed to conversion to km in prose because it feels less overwhelming, especially if it's only done sparingly, and it gives a sense of just how big a light-year is compared to everyday life. That said, it's not wrong to expect people to develop an intuition of how big a light-year is on their own or by reading light-year if they are new to the concept. -- Beland (talk) 01:44, 28 July 2024 (UTC)
• Parsecs or light years as primary, kilometres as secondary (converted) unit. I have no strong opinion regarding the use of pc or ly as primary unit, but figure that pc are to be more useful since they are preferred by specialists. I strongly favour the use of SI units with scientific notation as secondary unit, since it'll give normal (lay) readers a better sense of the dimensions involved – most people know what a kilometre is, and even those more accustomed to miles will know that they are of roughly the same scale. Using other SI prefixes such as zettametres would in theory comply even better with the SI, but few people know prefixes of such dimensions, so in practice it would be much less helpful than km with scientific notation. Gawaon (talk) 05:44, 28 July 2024 (UTC)
• Light-years first, parsecs second. We need to use light-years because that's what our readers understand, and parsecs because that's what our sources use. km is useless, both for intuitive understanding (a gigantic exponent gives no intuition other than gigantic distance), and for calculations (as relevant speeds are given in fractions of c). Em, Zm, Ym are even worse, these SI prefixes are way too obscure. Tercer (talk) 08:17, 28 July 2024 (UTC)
• Light-years only. Agree (mostly) with Beland. Lightyears give an understandable number for the general public such that distances to different stars can be compared (eg 4 light-years to Alpha Centauri vs 100,000 light-years for the width of the galaxy). km's at that scale are all are read as an equal "damn that's big!" and are totally unrelatable - the average reader simply does not think in terms of numbers that big. km clutters up the article with no payback. Parsecs are not known to the general public (professionals know how to convert and probably get their information from better sources than WP anyway).  Stepho  talk  08:47, 28 July 2024 (UTC)
• Light-years first, whatever unit is the primary unit used in the source second. We should be making it easy for our readers to understand, and not trying to shoehorn the content into some "official" style that will be more or less meaningless to many readers. I do support converting the primary unit used in the source to light-years, flipping the output as needed. - Donald Albury 17:45, 28 July 2024 (UTC)
• Light-years, because that's the unit used by Patrick Moore, one of the most prolific authors of popular astronomy books. If the source uses another unit, state that as well, using {{convert}} with |order=flip. For example, if the source says 123 parsecs, we would enter {{convert|123|pc|order=flip}} which emits 400 light-years (123 pc). --Redrose64 🌹 (talk) 18:08, 28 July 2024 (UTC)
• Parsecs, or if necessary pc+ly (pc first) using {{convert}}, for consistency with the professional literature. We need Wikipedia to be usable as a professional resource, not merely a dumbed-down only-for-the-public childrens' encyclopedia. —David Eppstein (talk) 18:34, 28 July 2024 (UTC)

  The guideline Wikipedia:Make technical articles understandable makes a useful distinction between what I would consider "dumbing down" - WP:OVERSIMPLIFY which says not to oversimplify or tell lies-to-children - and "writing one level down", which WP:ONEDOWN says is a good rule of thumb for technical subjects.

  In finding a middle ground between the overly technical and the oversimplified, §Avoid overly technical language specifically advises: "If no precision is lost, use common terms instead of technical terms. Substitute technical terms with common terms where they are completely equivalent." Whether that advice should apply in this situation is a matter of opinion, but I think it's important to remember that "making accessible" and "dumbing down" are not always the same thing. -- Beland (talk) 15:54, 29 July 2024 (UTC)

  Making accessible should also mean, making accessible for professionals to read and to edit. "The widest possible general audience" should include professionals, not just non-professionals. Gratuitously avoiding the preferred unit of professionals makes our articles less usable to and less editable by them, for no good reason. It sends the message that their participation is not welcome here, the opposite of what we want. —David Eppstein (talk) 01:49, 30 July 2024 (UTC)

  The discussion in the previous thread has several examples of peer-reviewed astronomy papers that use light-years, even though it's not the majority, and the unit is well-known in the popular press, which professional astronomers are also exposed to. Light-years should be perfectly accessible to professional astronomers and those familiar with the peer-reviewed literature, and no doubt already occasionally use the conversion factor to compare figures from different sources.

  I was also pondering whether or not it would be good to also have parsecs to attract more professionals to use Wikipedia articles for quick reference, and possibly fix things while they are here. This past week I went through and fixed the densities and surface gravities of a lot of exoplanets; a few seemed completely wrong because someone had confused g/cm³ with kg/m³ or missed undoing a logarithm or just pulled data from a contradictory source without leaving a citation. Those sorts of things I would expect a professional to occasionally spot.

  I think it would be good to get actual data about whether or not this makes a certain community feel unwelcome, rather than go on the guesses of non-astronomers about other people's emotional reactions. Does not using US units in science articles make Americans feel unwelcome? This American certainly does not, so I'm a bit skeptical of this idea. I might feel differently if someone did it intentionally to spite Americans rather than for good reasons, like reducing clutter for a global audience and the fact that STEM fields tend to use metric and Americans are an inconvenient minority on the planet in this aspect. I took some astronomy and planetary science classes while I was an undergrad at MIT, but I'm definitely not a career astronomer. Is anyone else here a professional astronomer or know someone who is and is uninvolved in this discussion so far? -- Beland (talk) 03:29, 30 July 2024 (UTC)

  (See Parejkoj's reply, below, for one answer.) -- Beland (talk) 18:34, 1 August 2024 (UTC)

• Light-years as primary unit, as the most familiar and understandable way of expressing interstellar distances. Parsecs as secondary unit, as the unit most often used by professional astronomers. Sources always use one or both of light-years and parsecs. While I prefer the status quo of using both I would also be okay with only light-years; compact tables like the list of nearest stars should use only light-years. Using large numbers of kilometers is not supported by common usage, and it seems clear that this being more understandable than light-years is a minority position. SevenSpheres (talk) 18:38, 28 July 2024 (UTC)
• Light-years as primary unit (and perhaps the only unit) as the mostly widely understood unit. I don't like the idea of using parsecs. The point of providing multiple units is to allow the reader to understand the number if they are unfamiliar with the primary unit. I can't imagine that there's anyone who knows what a parsec is but doesn't know what a light-year is. Parsecs are used only by professional astronomers, who certainly know what a light-year is and can easily convert between light-years and parsecs. Furthermore, it seems unlikely to me that a professional astronomer would be doing research using Wikipedia rather than more professional resources. Well-respected popular science magazines like Astronomy and Scientific American use light-years. Weak preference for km as a secondary unit if a secondary unit is necessary, although the huge numbers involved in the conversion to km will probably be hard to understand for a significant number of our readers. CodeTalker (talk) 19:05, 28 July 2024 (UTC)

  Well, if edited with that attitude, it is unlikely that our astronomy articles will be usable by professional astronomers. But in other areas of science, Wikipedia is usable, useful, and used by professional researchers, not so much as a source for data but as a good starting point for literature reviews and starting material for understanding topics with which they may not already be familiar. —David Eppstein (talk) 20:02, 28 July 2024 (UTC)

  I certainly know chemists who use Wikipedia to look up reference data on certain molecules sometimes, but when doing so occasionally spot errors. We generally don't convert those data to secondary units in chem infoboxes (though I do see some Fahrenheit). It seems the benefits of using a single set of units - which we're lucky enough to also be those used in industrial and academic chemistry - outweigh the convenience for Americans who might be thinking or calculating in US units. It seems a bit much to claim that using light-years and not parsecs would make Wikipedia articles unusable for astronomers; how hard is it to divide by 3.26? -- Beland (talk) 05:24, 29 July 2024 (UTC)

  @CodeTalker: The "huge numbers involved in the conversion to km" are one reason why such a conversion is helpful. An astronomer does not need reminding of that vastness, and uses parsecs for convenience, but the mindboggling vastness of space is lost when we use correspondingly vast units. The mindbogglingly large numbers resulting from a conversion to km (or mi) is one way of conveying the vastness to a lay reader. Dondervogel 2 (talk) 19:12, 1 August 2024 (UTC)

  My opinion is that "conveying vastness" should not be a goal. The goal should be writing in a way that helps the reader to understand, not to awe them with wonder. I think few readers who are not already mathematically inclined will take anything away from numbers like 10²⁰ km or 10²⁵ km, except that they're both "very big", without any understanding of what they really mean or the difference between them. CodeTalker (talk) 19:36, 1 August 2024 (UTC)

  If it is not Wikipedia's goal to convey how far away the stars are, then I too see little point in converting to km (or Zm). There we can agree.

  But in my view a good encylopaedia should strive to convey precisely that. It seems this is where we differ. Dondervogel 2 (talk) 20:10, 1 August 2024 (UTC)

  Of course our goal is to convey how far away the stars are. I don't see how you can read my response to mean that we should not. But it should be done in a way that is understandable to readers, not to deliberately use inappropriate units so that we can impress the reader with big numbers. CodeTalker (talk) 20:16, 1 August 2024 (UTC)

  Space is big. Really big. You just won't believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it's a long way down the street to the chemist, but that's just peanuts to space. Listen... – Douglas Adams, "Fit the Second", The Hitchhiker's Guide to the Galaxy.

  The point is that we cannot conceive very large numbers, so there's no point in choosing one unit over another unless you are comparing one distance with another, in which case you can judge that this object is ten times as far away as that object, when measured using the same units. --Redrose64 🌹 (talk) 21:01, 1 August 2024 (UTC)

  Your precise words were "conveying vastness" should not be a goal. I interpreted that as meaning Wikipedia should not try to convey the vastness of space. I see no other reasonable interpretation. If not that, what did you mean instead? Dondervogel 2 (talk) 22:35, 1 August 2024 (UTC)

  Not to put words in anyone's mouth, but I think the idea is that light years give small numbers that can be readily compared to easily comprehend relative distance. Distances in light years convey the mathematical information about how far away the stars are, but do not convey a realistic sense of sheer vastness unless one already has an intuition for how vast a light-year is. As compared to kilometers, which can (for those who understand scientific notation and who stop to think for a moment) convey an intuitive sense of how far away stars are in absolute terms, for example by making it easy to see how long it would take to drive there at 100 km/h or how long it would take Voyager 2 to get there at 15 km/s. -- Beland (talk) 03:43, 2 August 2024 (UTC)

  Yep. The distances need to be presented in light-years (or parsecs), to provide relative distances and in kilometres (or metres) to convey the vastness. Very well put. Dondervogel 2 (talk) 06:37, 2 August 2024 (UTC)

  The main sticking point here seems to be over if it is within our purpose to do so (re: km conversion).

  Personally, I would say it is not. ... for example by making it easy to see how long it would take to drive there at 100 km/h or how long it would take Voyager 2 to get there at 15 km/s. Including conversions solely for this purpose feels uncomfortably close to WP:INDISCRIMINATE to me. Unit conversions are included for reasons of practicality, not for conveying "vastness" or other arbitrary properties.

  There are, of course, other arguments for include km conversions that others have laid out, but I feel that this specific line of reasoning is a weak one. ArkHyena (talk) 08:05, 2 August 2024 (UTC)

  Conveying vastness essentially means providing a comparison with a familiar unit. Thus providing distances in, say, kilometres enables readers to compare the distance to a measure they use frequently, and providing them in a large unit such as light years enables readers to more easily compare the relative distance for different stars. isaacl (talk) 13:35, 2 August 2024 (UTC)

  My stance that such a reason alone is not sufficient still stands. I fail to see how SI conversions would enable a reader to more easily compare the relative distance for different stars, because that is, in part, why we use lyr/pc in the first place. A star 50 lyr away being twice as distant as a star 25 lyr away is perfectly understandable to the reader. On the topic of vastness, we don't provide the masses of planets in kg just to convey to the reader how massive they are with impressively large numbers, we include them because

  • Kg are occasionally, if not frequently used by astronomers when dealing with the masses of celestial objects, including planetary ones
  • There are relevant attributes that rely on their masses being given in kg, such as planetary densities, planetary compositions, or the masses of a planet's internal layers

  If we are to include SI conversions for lyr/pc, we ought to do so for similarly practical reasons. ArkHyena (talk) 19:50, 2 August 2024 (UTC)

• My previous position was parsec or light-year as primary unit, converted to SI, but I now favour parsec as primary unit, converted to SI. I will explain the rationale behind the shift in a follow-up post, but my thoughts remain in a state of flux and the popularity of the light-year makes me consider the need for a 3-way conversion in some situations. I will be back. Dondervogel 2 (talk) 21:14, 28 July 2024 (UTC)

  … and my considered preference is Parsec as primary unit, converted to an SI unit. In prose, convert also to light-years, thousands of light-years, millions of light-years, billions of light-years (avoiding the abbreviations 'ly', 'kly', 'Mly', 'Gly'), as appropriate.

  My preferred SI unit would be Pm, Em, Zm or Ym, linked on first use to petametre, exametre, zettametre, yottametre. I can see the benefit of relating to the kilometre (km), so I would not object to that option, although I find the exponential notation cumbersome.

  As mentioned in my previous post, I no longer favour the use of light-year as a primary unit. I was already uneasy about “megalight-year” and similar but was unsure why. When I dug a little deeper I discovered the IAU style manual, which lists SI units and non-SI units recognised for use in astronomy. The units recognised by the IAU are the metre (symbol m), the astronomical unit (symbol au = 0.149 60 Tm) and the parsec (symbol pc = 30.857 Pm). In other words, the IAU does not recognise the light-year for use in astronomy. And if the IAU does not recognise the unit, we should not use it, right? No, not quite. Many Wikipedia readers will know a light-year is the distance light travels in a year, and this familiarity makes it relevant, hence the proposed additional conversion (in prose) to light-years, but avoiding the abbreviations ly, Mly, etc., which I find unhelpful.

  The conversion to SI provides a scale (whether the metre or kilometre) that all readers are familiar with and conveys the vastness of space in a way that parsec (or light-year) on their own do not achieve (Readers who understand the meaning of ‘light-year’ as the distance travelled by light in a year do not necessarily have a grasp of how fast light travels; only yesterday I was asked “what travels faster, light or sound?”)

  Examples

  • Sirius B is 2.670 pc (82.4 Pm; 8.71 light-years) from the Sun.
  • The Whirlpool Galaxy is 7.220 Mpc (223 Zm; 23.5 million light-years) from the Sun and 23.58 kpc (0.728 Zm; 76,900 light-years) in diameter.

  The use of 0.728 Zm in preference to 728 Em avoids an unnecessary conversion between Zm and Em in the 2nd example. The SI values could be replaced with exponential notation if that is preferred. I find it cumbersome but that is a personal preference. Dondervogel 2 (talk) 13:57, 29 July 2024 (UTC)

  Finally someone who would agree with me in the discussion on prefixes I started. Avenues2009 (talk) 21:37, 30 July 2024 (UTC)

  I can see the benefit of SI prefixes in astronomy and nuclear physics, because the prefixes obviate the need for cumbersome exponential notation. Where we differ is your statement it would be much more consistent and straightforward if all Wikipedia articles used the full range of metric prefixes, which differs from my position. In 99.9 % of our articles it is preferable to use a scale between "millionths of a millimetre" and "millions of kilometres", as appropriate. Dondervogel 2 (talk) 09:11, 31 July 2024 (UTC)

• Light-years as primary unit, parsecs as secondary unit, as lyr are indisputably the primary unit used to convey interstellar distances or larger. I don't see why distances measured by lyr/pc should be converted as such distances are well into the region where scales conveyed by kilometers are, at best, impractical and unintuitive to most. This is evidenced by numerous science communication outlets—including NASA itself—excluding SI (or US customary) conversions for interstellar distances (some examples: [38] [39] [40] [41]). It is clear that the overwhelming majority of science communication, nevermind technical introductory sources such as astronomy textbooks, deems such conversions as largely unnecessary, and I fail to see why we should be any different. ArkHyena (talk) 02:52, 31 July 2024 (UTC)

  None of the web pages you linked use parsecs, either. -- Beland (talk) 03:17, 31 July 2024 (UTC)

  Yes, but this is balanced by the fact that academic sources overwhelmingly use pc over lyr. Popular sources use lyr, academia uses pc; per this, we should use both, with the less technical lyr being our primary unit. ArkHyena (talk) 03:19, 31 July 2024 (UTC)

  Interestingly, our dab page lyr doesn't mention light-years. --Redrose64 🌹 (talk) 19:59, 31 July 2024 (UTC)

  Should be fixed now, thanks for the heads up :) ArkHyena (talk) 20:04, 31 July 2024 (UTC)

  Our article light-year also doesn't mention "lyr", a contraction which I had never come across until your post of 02:52, 31 July 2024 (UTC) - everybody else in this section, when abbreviating, has used "ly". I hope that "lyr" is not something that you made up. --Redrose64 🌹 (talk) 07:13, 1 August 2024 (UTC)

  I suppose it's a mistake. Gawaon (talk) 07:33, 1 August 2024 (UTC)

  Both "ly" and "lyr" are legitimate abbreviations of "light-year". I have seen "lyr" in reliable sources (e.g., Mutel et al 1981; Chen & Chen 2016). It should be mentioned in Light-year as a legitimate alternative to "ly". Dondervogel 2 (talk) 08:05, 1 August 2024 (UTC)

  I have added "lyr", "klyr" and "Glyr" to Light-year, citing RS. Dondervogel 2 (talk) 08:17, 1 August 2024 (UTC)

• Light years as primary, small preference for conversion to parsecs in extended prose. Professional astronomer here (there's about a half dozen that I know of that semi-regularly edit Wikipedia): parsec is really useful because the relationship between arcsec, au, and pc (and the conversion factor of 206,265) allows really easy conversion between measured angular sizes, proper motions, distances, etc. in one's head. But that's not something that most people will ever have to care about, so there's not a strong reason to use pc on Wikipedia, except that that is the value that most primary sources report. I like the suggestion above to use `order=flip` in the converter, since that helps make it clear where the value came from: we have a terrible problem of un- and poorly-sourced numbers in astronomy articles.
  Metric prefixes for meter are right out: most astronomical scales are well beyond what any typical reader would be familiar with; I work computing, and still have to remind myself what the exponent for peta is. Prefixes above giga would be completely unfamiliar to most readers.
  To the question of whether astronomers are, or should be, using Wikipedia as a data source: I mostly hope that they do not. We have our own curated sources for data values (e.g. NED, SIMBAD, or the SDSS value added catalogs), and it's almost always not as simple as just grabbing the "top" value from a catalog. This often happens on Wikipedia, and results in long arguments by non-experts about e.g. which star is biggest. I've tried at various points to get colleagues to edit wiki pages when they notice something incorrect without much success; you don't get tenure or grant funding editing wiki! We're not going to turn Wikipedia into a preferred source of numerical values without essentially re-creating the work that went into something like SIMBAD, and that took *significant* funding and buy-in from institutions. Trying to re-create that work without experts onboard is not worth our time. - Parejkoj (talk) 03:58, 31 July 2024 (UTC)
• Light years as primary. I would include a conversion to parsecs (using order=flip if it helps). Light-years are widely recognised by the lay reader, which will be most of our audiences. Parsecs are more likely to be found in sources (so including them helps with verification) and will be needed if we aspire to have an audience of professionals. I would not strongly object to a third conversion to kilometres where space allows, but I would strongly object to the use of obscure metric prefixes that would not be readily understood even by professional astronomers or other professional scientists. Shoot, even names of large numbers are more understandable to more people (even if we restrict ourselves to professionals) than most of the larger metric prefixes. At least you can work out how big a quintillion is from its name. You can't do that with exa-, zetta- or yotta-. Kahastok talk 21:40, 2 August 2024 (UTC)

Conversion of non-SI metric units

One part of MOS:CONVERSIONS says "conversions to and from metric units and US or imperial units should be provided". Another part says for units "not part of the SI or US customary systems (e.g. zolotnik), supply a parenthetical conversion into at least SI units". Should the latter part say "metric" or "modern metric" instead of "SI"? I may have been the one to put that in and merely chose the wrong words. I ask now because I came across jansky, which is a non-SI metric unit. It seems a bit silly to convert janskys to 10⁻²⁶ W⋅m⁻²⋅Hz⁻¹, which is apparently more strictly SI.

By "metric units" I assume it's clear we mean anything that's a named combination of SI units or can be related to them with factors of 10, which also includes the liter, hectare, and metric ton. Those three I assume we clearly don't want to convert, but to the degree that they are no longer used, it does seem like we'd want to avoid CGS and MTS units where there are drop-in SI equivalents, like erg or dyne or sthène? -- Beland (talk) 01:18, 30 July 2024 (UTC)

It's a bit tricky since "metric" would be very broad, while "modern metric" and SI seem to be largely treated as synonymous. (Metric system say "The International System of Units is the modern metric system"; similarly, International System of Units calls it "the modern form of the metric system".) Units officially accepted for use with the SI should be fine in general (though I'd still like to see the astronomical unit converted to km, but maybe others will disagree). For others, such as the jansky, it could be decided on a case-by-case basis – that one seems reasonable enough. I think rather than changing the text of that section, adding a note on other acceptable units might be a better solution – to be extended, if the need arises, after a short discussion on this page, or through WP:EDITCON. Gawaon (talk) 06:37, 30 July 2024 (UTC)

I don't think that a "metric unit" is necessarily related to an SI unit by an integer power of 10. The article List of metric units includes multiple examples that do not satisfy this criterion. Examples include the CGS-ESU electromagnetic units statcoulomb and statmho. Are these not metric units? Dondervogel 2 (talk) 07:36, 30 July 2024 (UTC)

CGS is obsolete. I assume it is the reason Beland mentioned "modern metric". Tercer (talk) 08:00, 30 July 2024 (UTC)

Yes that's why I was leaning toward "modern metric", though it's interesting to find out about non-base-10 metric units, so, well spotted!

It does seem like a specific list of exceptions to "convert to SI" is needed for clarity, especially since upon further research there are some units that meet my description that are so obscure I'd probably want to convert anyway. Maybe "metric" in the first sentence should actually be replaced by "SI"?

AU and eV have come up at Wikipedia:WikiProject Astronomy/Manual of Style. I was expecting to have a separate discussion about AU after we finalize a decision for light-years. For electronvolt and dalton, it seems like they are actually too small and fiddly, and are actually well-suited to the domains in which they are used, without conversions that would require scientific notation. If no one objects, I think it would make sense to say units officially accepted for use with the SI (except possibly for AU) don't need to be converted.

List of metric units was very helpful to look through for possible exceptions to the "otherwise convert to SI" rule. I tried to find the ones that would be awkward to convert into SI, either because the combo unit is very complicated, or the non-SI name is very common.

• Solar flux unit is complicated but doesn't look like it's used outside of articles about units.
• Rad (radiation unit) looks like it could be replaced in our articles with Gray (unit)
• Rutherford (unit) could perhaps be replaced with MBq
• M for molar concentration seems like a good candidate for leaving unconverted, due to common use.
• Rayleigh (unit) is complicated, but only used in a handful of articles; should probably be discussed.
• Currently, English Wikipedia articles on some planets have atmospheric pressure given in bar, atm, and Pa. Since 1 bar is exactly 100 kPa, that seems like overkill, and a good topic for the astronomy MOS. Measuring in standard atmospheres is nice because it's an intuitive comparison to Earth, though I guess given that the other scales are calibrated with 1 or 100 at Earth standard, maybe only one of these scales is actually necessary? I don't have a good sense of how well people in metric-using countries know bar and Pa, and if one would be better to use over the other or if they are both fine and could be used based on the field or article history or whatnot. Here in the US, the weather is in inHg, my bike tires are in psi, and I have no intuitive sense of how they relate to each other and vague memories of bar and torr from high school chemistry class. (Hlep!) -- Beland (talk) 08:42, 30 July 2024 (UTC)

The electronvolt and dalton are among the units officially accepted for use with the SI, so I think they should be fine to use without conversion. Molar as mol/L seems fine to me, since the mol is an official and the litre an accepted unit. As for rayleigh, I don't know – there doesn't seem to be any other common unit of photon flux, so it probably needs to be kept? Pressure should preferably be given in or converted to Pa, since that's the standard. Gawaon (talk) 09:18, 30 July 2024 (UTC)

Having lived in several countries that use SI, the kilopascal is the common and only unit for pressure in tires in Southern Africa, Australia and New Zealand. The hectopascal is used worldwide for atmospheric pressure (Canada uses kPa), the USA uses inches of mercury for surface pressure and millibars for upper air pressure. The bar and millibar are deprecated and not SI. What they are trying to do in the MOS is have SI primary for every country except the USA, Britain is a mix. Avi8tor (talk) 10:48, 30 July 2024 (UTC)

Here in Spain bar (and milibar) is used for pressure. In informal speech it is used interchangeably with atm. Pascal only exists in textbooks. Tercer (talk) 13:13, 30 July 2024 (UTC)

I was surprised to see erg (as sole unit) and erg/s (with a conversion to W) in Proxima Centauri, one of the examples in the discussion above. Is that common among astronomers?

Some use hectopascals (hPa) rather than mbar for terrestrial weather, as the values are identical, but in science ant technology generally it's Pa, kPa and Mpa with no glimpse of hPa. For inHg/psi, you probably see barometers go up to about 30 inHg and know standard atmospheric pressure's about 14.7 psi, so 2:1 is good enough for an intuitive relationship? NebY (talk) 17:54, 30 July 2024 (UTC)

Weather for pilots is in hPa worldwide because older altimeters are calibrated to millibars and nothing needs changing. Most airplanes now have a switch to change the display from inHg to hPa depending on where you are on the planet. Avi8tor (talk) 08:59, 31 July 2024 (UTC)

My point is not to develop an intuition about US pressure units, but to point out that for the vast majority of Americans that doesn't exist. -- Beland (talk) 19:20, 31 July 2024 (UTC)

Part of the problem here is that previous discussions have broadly used "SI" as a shorthand for the conventional systems of units used in most of the world outside the US and UK. It was never intended that we strictly use SI for the sake of strictly using SI, regardless of sanity. The people writing this probably weren't thinking of units used by scientists at all. They were thinking of things like Scandinavian miles, pennyweights and chains.

My rule of thumb for scientific articles would be to ask whether the reader (judged e.g. according to WP:ONEDOWN) is likely to be familiar with the unit. If so, no conversion is needed, just link it. If not, then you should convert to a unit that they will be familiar with. Kahastok talk 15:14, 3 August 2024 (UTC)

Primary units and flipping

May I suggest that the units shown first should always be those quoted in the source document. The reason is that this is less likely to be distorted by rounding errors, and is likely to be more accurate than any alternative, converted figure. If "flipping" is allowed, then the user is left in doubt as to which of the two (or more) figures is more accurate, and in many cases also as to the precision of each figure. This means that some information is lost. Ehrenkater (talk) 15:17, 30 July 2024 (UTC)

Your rounding-errors argument makes no sense, since Convert will be working from the source's unit whether the display is flipped or not. The "user left in doubt" argument has at least some merit, but I believe it's completely outweighed by the fact that we'd be presenting values from different s sources with different unit orders, which will appear random to the reader. Johnuniq may have useful insight on this. EEng 16:50, 30 July 2024 (UTC)

I prefer using the unit used in the source as the first in the Convert template, but usually flip to put the metric output first. Care must be taken to minimize rounding errors whether the outputs are flipped or not. Donald Albury 17:01, 30 July 2024 (UTC)

{{Convert}} is quite good with keeping the approximate precision of the source, and I agree that it's better to use flip as needed to get a consistent output. Consistency requirements within the same article suggest that the same unit should always come first (if possible), otherwise readers could get confused. Gawaon (talk) 17:06, 30 July 2024 (UTC)

Yes, and editors might use one source rather than another so that their preferred system of units comes first (see this talk-page's archives, too often). NebY (talk) 17:35, 30 July 2024 (UTC)

This is addressed in the Wikipedia:Manual of Style/Dates and numbers/Units of measurement/Unit choice and order. Shortcut MOS:UNIT. Basically this states that with the exception of the USA and the UK, the primary unit will be SI. Note that metric and SI are not the same thing. Sources can be cherry picked, the official government or company reference is a better choice. Magazines or newspapers generally round articles to their preferred unit. Avi8tor (talk) 19:44, 30 July 2024 (UTC)

Oh, I know MOS:UNIT says that and that sources can be cherry-picked - that's exactly my point and I've got the t-shirt. However, an official government or company release will not always be a better source, per WP:PRIMARY. NebY (talk) 19:53, 30 July 2024 (UTC)

Is there an example where distortion from rounding errors has occurred? Johnuniq (talk) 23:57, 30 July 2024 (UTC)

I commonly see in Wikipedia a distance of about 100 yards (91 m) when it's an estimation not a measurement, far to accurate in metres for "about or approximately." I have a copy somewhere of an article on a roman building excavation from 3 different newspaper sources all with different dimensions in feet only. Finding it on my computer may take a while, it's been a few years. Another example is engine power in motor vehicles, which since ~1980 in the EU has required it be stated in kilowatts. This hasn't stopped people from using PS, CV or HP because it's from their source. The best source is the owners manual, most available online. Avi8tor (talk) 04:59, 31 July 2024 (UTC)

Thanks but I meant an example of an article where someone had used {{convert|...|order=flip}} and where the result was distorted. It sounded as if the OP might have encountered the issue. Johnuniq (talk) 05:27, 31 July 2024 (UTC)

Flip was not involved. What I was thinking of was this, where {{Convert}} had a round number (700 km2) as input, and sigfig set to 1, which caused the output to round to 300 sqmi. This caused the sqmi output to be larger than the output from a conversion of 703 km2 to 271 sqmi. This was a list ranked by size, and it would have ended up with an entry showing as smaller than another entry when nmeasured in km2, and larger than that entry when measured in sqmi, if I had not changed the sigfig. Pay attention to the sigfig setting. Donald Albury 16:48, 31 July 2024 (UTC)

Interesting case, but I'd tend to leave out that parameter and let {{Convert}} do the right thing. Most of the time it seems to do a good job (700 km² (270 sq mi) looks reasonable too). Gawaon (talk) 17:03, 31 July 2024 (UTC)

'sigfig' has its uses. As with everything else in editing Wikipedia, one should inspect the output of any use of the convert template. Donald Albury 18:56, 31 July 2024 (UTC)

I suspect that you have something like this: a reference of 6 miles and an article that uses SI first. And that you "flip" by hand to get 10 km to make the SI appear first like {{convert|10|km/h|mph|0}} to display as 10 kilometres per hour (6 mph).
The answer (assuming I have constructed the right strawman) is to not flip by hand but to tell {{convert}} to swap the display order. Hence, you do {{convert|6|miles|km|0|order=flip}} to display as 10 kilometres (6 miles). This always uses the reference value in the wiki mark-up, displays SI first and does not do a double conversion.  Stepho  talk  07:56, 31 July 2024 (UTC)

If the reader sees 10 kilometres (6 mi) he or she will most likely assume that the accurate distance is somewhere between 9.5 km and 10.5 km (or possibly the 10 km could be only one sig. fig., there is no way of telling). However in reality the length is probably somewhere between 5.5 miles and 6.5 miles (or about 8.9 km to 10.5 km) so some information has been lost in the flipping. Ehrenkater (talk) 07:25, 2 August 2024 (UTC)

Few readers will care whether the exact length is 9.2 or 9.6 km and those that do will do better by either looking it up in the provided reference (where they'll find the original unit) or looking it up in some kind of primary reference collection that presents all distances in a uniform way and according to a uniform standard of reliability. Face it, a tertiary source like Wikipedia that gathers information out of all kinds of (hopefully reliable) sources is not the place to go if you're interesting in absolute precision. Gawaon (talk) 08:37, 2 August 2024 (UTC)