Wikipedia talk:Manual of Style/Dates and numbers

Grouping of digits with commas is not allowed for numbers in the SI

The Wikipedia:Manual_of_Style#Numbers currently states that commas should be used for grouping of digits. It also links to MOS:DIGITS where the use of narrow gaps is given as an alternative. On both pages there are examples of numbers in SI units, but using the comma as the grouping digit.

It happens that the use of commas for the grouping of digits of numbers is not allowed in the SI since 1948, when the CGPM decided in its Resolution 7, and reaffirmed by resolution 10 of the 22nd CGPM, 2003: "Numbers may be divided in groups of three in order to facilitate reading; neither dots nor commas are ever inserted in the spaces between groups."

As many countries (including English speaking such as South Africa, and many non-English speaking) and international organizations use the comma as the decimal separator symbol, there is a real risk for English Wikipedia readers to misinterpret the numbers stated on an article if the comma is used as a grouping digit.

While it is necessary to stop using commas as grouping digits in quantities expressed in SI units, it is simpler and more consistent to apply that narrow spaces style to all other numbers as well, which would avoid interpretation mistakes by the readers for all quantities.

Therefore I propose to use narrow spaces instead of commas as grouping of digits in Wikipedia:Manual_of_Style and remove the allowance for them in MOS:DIGITS.

This would follow the recommendations from the BIPM,, ISO, NIST, IUPAC, the American Medical Association's widely followed AMA Manual of Style, among others.

Nativeblue (talk) 15:47, 27 August 2023 (UTC)

• Not going to happen. They can put me in BIPM-ISO-NIST jail if they want. EEng 16:39, 27 August 2023 (UTC)

  Yeah, WP is not written to SI's style guide (or ISO's or BIPM's, etc.). We're happy to accept their advice when it doesn't conflict with normal English usage, when there's a "clearly improves the encyclopedia" reason to do so, and especially when the particular point has made its way into major general style guides (e.g. much of WP:MOSNUM is derived from Scientific Style and Format, which is essentially a collation of the most useful and consistent style points promulgated by such organizations and by academic journal publishers). A side point: The South African government officially uses "1 234 567,890" style, but WP is not written in bureaucratese/officialese, and I can't find any evidence that South African readers have any trouble interpreting "1,234,567.890" format, which is otherwise used nearly universally in the English-speaking world, and is also built into many programming languages, user interfaces, etc. (regardless of language). I have a strong suspicion that even non-native users of English today have no difficulty with this format at all because of its modern ubiquity. However, there is probably some kind of Javascript "gadget" approach that could be built to convert between these formats on-the-fly, on the user side. I know that the citation templates are doing complex date-format translation, so this is clearly technically possible.  — SMcCandlish ☏ ¢ 😼  17:41, 27 August 2023 (UTC)

  I oppose a Wikimedia Foundation approved method for users to reformat numbers according to their preference. The next thing you know, the users of the system would demand we go in and apply special markup to numbers that are, for some reason, incompatible with the system. Jc3s5h (talk) 19:31, 27 August 2023 (UTC)

  You may remember when Wikipedia tried across-the board date autoformating, or maybe you've happily blanked it, in which case there's an overview here. That's a nicely circumscribed problem compared to rendering all numbers. Rendering all numbers held within {{val}}-like templates would be a bit easier, but then we'd have to persuade all editors to template numbers and to put up with the source text being even harder for human readers to parse, plus many of the other problems in that overview. NebY (talk) 18:20, 28 August 2023 (UTC)

• I would support a change along the lines of the one proposed by Nativeblue (talk · contribs). Using thin spaces instead of commas makes lists of numbers easier to read and eliminates the risk of the comma being misinterpreted as a decimal separator. Dondervogel 2 (talk) 17:52, 27 August 2023 (UTC)

  Clarification: I don't think anyone wants a blanket ban on use of the comma as thousands separator, and I would not support that either. It has been mentioned that some subject areas (e.g., finance) would not benefit from thin spaces, and that's reasonable. I just think that Wikipedia as a whole would benefit from wider use of thin space separators where there is no good reason to insist on a comma. Dondervogel 2 (talk) 20:26, 29 August 2023 (UTC)

• I'm a techie; I happily read numbers separated by thin spaces and sometimes use them within and outside Wikipedia. Most of our readers aren't, and most websites, newspapers, books and magazines don't use thin spaces. Most of our editors don't either, and many will complain about or revert them. Switching to thin spaces across Wikipedia, for mentions of monetary values, distances, demographics, and all the other quantities in the encyclopedia, would require broad support and clear consensus among active editors. It would not be possible to impose it by consensus among the few regulars at WT:MOSNUM; that would only result in MOSNUM guidance being revereted. Instead it would require techies and non-techies alike to agree it in a massive centralised discussion, and that would be dominated by the question of what actually happens in the world we describe - a world which has largely metricated (or metrificated), mainly implementing SI, with this one glaring exception. NebY (talk) 18:25, 27 August 2023 (UTC)
• Just no this is not how the majority of English-speaking countries render numbers in educational or business prose. Given that this is the English Wikipedia, we go with the common English-language style. TonyBallioni (talk) 18:50, 27 August 2023 (UTC)
• This is already dead in the water, but I'll add my opposition. – John M Wolfson (talk • contribs) 19:16, 27 August 2023 (UTC)
• Sorry this sounds like a terrible idea. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 19:40, 27 August 2023 (UTC)
• I'm not against it - although not wildly for it either. But how would it be implemented? Editors are not going to type in the Unicode for thin space - we have enough trouble getting them to use various dashes (note my incorrect but common use of "-"). Also, cutting and pasting those numbers to other programs or web pages may have those Unicode characters in them that may confuse that other program. They would have to wrap every number over 999 (or 9999) in something like {{val}}, which uses clever CSS tricks to copy only the digits. But wrapping them is a huge inconvenience to the editors and makes the wiki mark-up clumsy and hard to read and the majority of editors simply won't even realise that it should be done at all.  Stepho  talk  22:46, 27 August 2023 (UTC)
• Clearly a non-starter, for the numerous pragmatic reasons already discussed above, and more besides. This is an encyclopedia, not a technical resource. As such, its content is formatted and stylized in a fashion calculated to make it as easily digestible to the average reader of English, and consistent with broadest conventions employed within the most commonly used written idiolects. The principle of least astonishment should definitely be employed here, not for prescriptive reasons, but simply to make the content as accessible as possible to the average user likely to be reading our content. The proposal would replace that calculus for an effort to reach towards a more regularized and universal standard. But putting aside that my experience suggests to that the standard itself is not nearly as universally adopted in technical spheres and in global populations as the OP seems to think, it's just clearly not practical for encyclopedic form in the relevant language here. SnowRise ^{let's rap} 22:59, 27 August 2023 (UTC)

  "principle of least astonishment" Lol. Thank you for that addition to my mental furniture. Elinruby (talk) 03:14, 28 August 2023 (UTC)

  @Elinruby: See also WP:ASTONISH, and Principle of least astonishment.  — SMcCandlish ☏ ¢ 😼  05:13, 28 August 2023 (UTC)

  thanks. surprised I had not previously encountered that Elinruby (talk) 05:53, 28 August 2023 (UTC)

  And don't forget WP:Principle of Some Astonishment. EEng 06:03, 28 August 2023 (UTC)

• I like narrow spaces for grouping digits. I use them whenever I'm writing something where I have free choice over that element of style. But the Wikipedia editor is not the easiest for adding symbols that aren't on the keyboard, and editing on mobile phones is even harder. Also, readers use different browsers and different screen sizes, and sometimes numbers with spaces end up breaking across multiple lines (this might only be if the wrong sort of space was used, but I'm afraid that seems inevitable). So while I might like this to be the Wikipedia style, I don't think it's practical for a collaborative project with so many people using different systems to read and edit. Mgp28 (talk) 23:45, 27 August 2023 (UTC)
• Opposed - perhaps it’s because I am getting old… but I have difficulty deciphering large numbers without commas. Substituting spaces for the commas in large numbers would actually make reading Wikipedia harder for me.Blueboar (talk) 01:32, 28 August 2023 (UTC)
• Opposed - What Blueboar said. I have no particular objection to internationalizing a number of conventions, but not this one. - Donald Albury 01:46, 28 August 2023 (UTC)
• Oppose; There is, I think, (and as I assume several of the other editors know) a reason for the ISO style [converted into a Standard] — there are other languages (notably French) where the traditional convention is the exact opposite of English convention, e.g. the number 1,234,567.89 in Anglo-American style was often rendered as 1.234.567,89 ; i.e. separating thousands with periods/full stops (points) and whole numbers from fractions with commas (virgules). But what might be necessary for trans-national scientific exchange is problematic for the common, familiar Anglo-American conventions with which far more than 90% of our readers are used to seeing. And thin spaces, as others have argued more eloquently above, present their own problems such as absence from the QWERTY keyboard, unfamiliarity, and being less effective than commas in showing divisions between thousands. I don't know how the ISO separates wholes from fractions: commas, periods (full stops) or something else. And I can imagine that this might complicate what Anglo-Americans already don't grasp at first sight: the Indian system of lakhs and crores. —— Shakescene (talk) 02:25, 28 August 2023 (UTC)
• Oppose: translator here. I routinely convert number formats but on the whole I don't see what problem we are trying to fix that would justify such a massive find-and-replace. I would have no issue with 2 300 versus 2,300 but thin space is...not something I am going to learn how to do. Meanwhile, maybe I am just not seeing the problem but imho 3,4 is easily understood as 3.4, is it not? There might conceivably be an issue with a number that has many significant digits after the decimal, i.e 346.782 vs 346,782. But surely there's a conversion template for such edge cases? Elinruby (talk) 04:36, 28 August 2023 (UTC)

  @Elinruby: Which of these two lists do you find easier to read:

  • 10, 100, 1,000, 10,000, and 100,000

  or

  • 10, 100, 1000, 10000, and 100000?

  Dondervogel 2 (talk) 12:46, 28 August 2023 (UTC)

  @Dondervogel2: How often do I see this type of list is a better question. And can there not be another delimiter? As it happens, we just finished Black market in wartime France, an economics article that involved many numbers, and I think there was a single instance of readability demanding a comma after a number in the thousands, and I reworded in the copyedit phase. I think there are better uses for bot time.Elinruby (talk) 20:51, 28 August 2023 (UTC)

  I'd separate them by semicolons, especially after a colon: 10; 100; 1,000; 10,000 and 100,000. (Oxford semicolon optional.) Certes (talk) 22:16, 28 August 2023 (UTC)

  I'd be fine with that. What sort of article does this crop up in? It looks like some thing that wants to be a table but isn't. Looked into this a bit, and am wondering if the formatnum template would solve the perceived problem? I am getting a glimpse of the issue as it seems thar one of the editors really wants commas vs spaces. Maybe I was being too glib when I didn't take the question seriously Elinruby (talk) 20:12, 29 August 2023 (UTC)

  It seems rare. Examples include Asymptote#Introduction, Austro-Hungarian krone infobox and Arizona Outlaws#1984 Oklahoma Outlaws (huge section; search for "decent"). Certes (talk) 21:42, 29 August 2023 (UTC)

• Oppose, I know this has a snowball's chance in hell of being implemented, but it would generally be a complete non-starter for screen reader users like me, as the guideline already notes (also see an earlier discussion on this topic). Graham87 10:34, 28 August 2023 (UTC)
• Support: easier to read, avoids confusion. But what is "narrow spaces style". Is this not it: 10 526 241? Edward-Woodrow :) _[talk] 12:18, 28 August 2023 (UTC)

  I think this is: 10526241 ({{val|10526241}}) - I think those should be non-breaking spaces and should still be interpretted as a single number by a screen-reader (rather than as ten, five hundred and twenty six, etc.). Mgp28 (talk) 12:36, 28 August 2023 (UTC)

• Support: but provide {{SI number}} template to separate groups of digits with nonbreaking spaces. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:32, 28 August 2023 (UTC)

  Do you mean like this?

  • 10526241

  Dondervogel 2 (talk) 12:35, 28 August 2023 (UTC)

   Done but called {{val}}. Of course it only works if we enclose all numbers in {{val}}. NebY (talk) 17:46, 28 August 2023 (UTC)

  Exactly, as long as the gaps are nonbreaking. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:35, 30 August 2023 (UTC)

• Oppose. We are not a solely scientific publication. The proposal would also massively increase accessibility problems, and this thread shows that even people who care about (and have presumably just read) the MOS are likely to misunderstand the guidance for the narrow spaces style. Firefangledfeathers (talk / contribs) 12:41, 28 August 2023 (UTC)
• Oppose. ISO needs a format which works for scientists and engineers across languages. MOS needs a format which works for readers of English prose. Those two problems have different solutions. We can't expect new editors to type 123<thin space>456 consistently, let alone {{some template|123,456}}. However, some sort of gadget to identify numbers and convert them into the user's preferred format, whether that's ISO, French or Indian, might be useful. (Beware of dates, ISBNs and other fake integers.) Certes (talk) 14:59, 28 August 2023 (UTC)

  Would (e.g.) the year A.D. 1776 [C.E.] be rendered by some 'bot or template as 1 776 or 1,776 ? —— Shakescene (talk) 18:50, 28 August 2023 (UTC)

  Deliberately? I'm not aware of any culture that prefers 1 776 or 1,776 to 1776, but it's possible. Accidentally? Almost certainly. It's hard for sofware reading that Football F.C. fielded "their 2023 players" to know that this refers to the year rather than extreme cheating. Certes (talk) 19:38, 28 August 2023 (UTC)

  I would narrow the application of thin spaces. Thin space are sometimes used by, or on behalf of, scientists and engineers when they are writing journal articles and similar formal publications. They are seldom if ever used in personal notes and calculations that lead up to the final publications, because it's just too much of a burden. Do we really want to force Wikipedia editors to use a style that even scientists and engineers won't use except to publish papers so they can look good to their employers and put food on the table? Jc3s5h (talk) 20:24, 28 August 2023 (UTC)

  In short "hell no".  — SMcCandlish ☏ ¢ 😼  21:57, 28 August 2023 (UTC)

• Oppose, solution in search of a problem. Stifle (talk) 12:34, 29 August 2023 (UTC)
• Never going to happen. Instead, Use magic word formatnum – that will output it in the correct format for whatever wiki the page is in. It might be possible to override that just for your own pleasure with appropriate adjustments to your common.css, but I'm not certain about that. Mathglot (talk) 05:06, 2 September 2023 (UTC)

  The idea is nice but now we have to convince editors to write "in 2021 they sold {{formatnum:12345}} copies" instead of the far simpler "in 2021 they sold 12,345 copies". Considering how hard it has been trying to convince editors to use ndash "–" or mdash "—" instead of the "-" character, this is unlikely to succeed.  Stepho  talk  08:14, 2 September 2023 (UTC)

  This is not a valid objection. What happens in practice is that the vast majority of editors (including myself) use "-" for everything because they don't know better. Then a more informed editor (or a bot?) comes along and tidies up the initial text, and everyone is happy. In the same way, the vast majority of editors will type "12,345". There's nothing wrong with that, and nothing to stop a more informed editor to replace it with {{formatnum:12345}} or {{val|12345}}, or whatever template is preferred. Dondervogel 2 (talk) 09:27, 2 September 2023 (UTC)

  Sure, the wikignomes are underworked, they'll be so glad for more burden - whip us harder, we love it!. We're not talking a few instances per article, we're talking many, many instances for every single article. And each new edit potentially adds another one, which we have to fix without confusing them with 4 digit years or anything that goes into a template - eg {{convert}}.  Stepho  talk  09:47, 2 September 2023 (UTC)

  That's a good point, and a reason for careful consideration. LOL. Dondervogel 2 (talk) 10:33, 2 September 2023 (UTC)

• No, this won't do. The subject is way more complicated and needs a lot more thinking about. I understand the Manual of Style to be saying that we format Pi as 3.141,592,654... Is that really intended? And do we really intend to use American high school rules in articles within the scope of WikiProject Mathematics? Because if I use one of Wikipedia's several competing versions of proper math formatting, I get $3.141592654...$ or 3.141592654.... I should get $3.141,592,654$ or 3.141,592,654, should I? Because that looks way off to my eye. And the non-breaking spaces don't always work at all. I mean, I can render 3.141 592 654 using {{math}} but <math> won't render a non-breaking space. I think whatever we decide here is going to need fixes to the way math syntax works. I also don't think it's right to to insist on American high school number style for articles covered by WikiProject Mathematics, WikiProject Astronomy, and other hard science for grown ups, and I feel we need a sort of WP:ENGVAR-style "don't alter the original author's formatting" rule.—S Marshall T/C 13:37, 2 September 2023 (UTC)

  I don't think anyone is considering grouping with commas after the decimal point. I haven't read the whole discussion so I can't be sure, but I'd be fairly shocked. I would remove such commas on sight, and I think most people would, without needing anything said about them in the MoS. Commas before the decimal point are what I think we're discussing. --Trovatore (talk) 16:19, 2 September 2023 (UTC)

  Yeah, I don't know what S Marshall's going on about. Nothing in either the main MOS or MOSNUM suggests these weird things. EEng 17:24, 2 September 2023 (UTC)

  It startled me too. But it's possible to take In general, digits should be grouped and separated either by commas or by narrow gaps to mean that commas may be used as separators after the decimal point, with an exception for numbers greater than 999, When commas are used left of the decimal point, digits right of the decimal point are not grouped (i.e. should be given as an unbroken string). NebY (talk) 17:43, 2 September 2023 (UTC)

  If anyone seriously suggests doing that we'll just have them killed. I know people who will do it for nothing as a public service. EEng 18:38, 2 September 2023 (UTC)

  We should probably mention that. NebY (talk) 18:42, 2 September 2023 (UTC)

  What, and spoil the fun? Dondervogel 2 (talk) 19:05, 2 September 2023 (UTC)

• If it means don't group numbers after the decimal then it should say so. And my other point remains: we still need to make exceptions to the commas rule for people using {{math}} and <math> so the articles about serious maths can use serious maths formatting.—S Marshall T/C 21:48, 2 September 2023 (UTC)

  Please say the exact change to the guideline text you want. I can't tell what the problem is. EEng 23:52, 2 September 2023 (UTC)

  The rule is "always use commas for large numbers". I want exceptions to that rule, firstly for articles within the scope of WikiProject Mathematics, and secondly, for all editors using {{math}} or <math> rather than typed out numbers.—S Marshall T/C 01:04, 3 September 2023 (UTC)

  By "the exact change" I mean something of the form: "Add blah blah blah as a new bullet point to the Foo list" or "Change the text lorem ipsum to mickey mouse". EEng 07:31, 3 September 2023 (UTC)

  Playing Devil's advocate, if I was editing an article about how many of a particular car were sold in 2020 and I didn't want to use commas, then according to your proposal I could wrap the sales figures in {{math}} or <math>.  Stepho  talk  01:11, 3 September 2023 (UTC)

  The rule given at WP:MOS#Numbers is "In general, use a comma in numbers with five or more digits to the left of the decimal point." I think that's generally good guidance. It links to MOS:DIGITS for the specifics, and DIGITS gives us "[grouping with narrow gaps] is especially recommended for articles related to science, technology, engineering or mathematics". I think the status quo is not far off from what you're looking for, but I may be misunderstanding your view. Firefangledfeathers (talk / contribs) 01:16, 3 September 2023 (UTC)

  For example, binaries. The decimal number 100 should be rendered in binary as 1100100 and not 1,100,100. Our article on binary number, if you check it, actually uses commas to separate numbers in a list of numbers rather than to group digits. It's a pretty decent article and trying to make it comply with this MOS rule would break it.—S Marshall T/C 01:22, 3 September 2023 (UTC)

  No one in their right mind would understand the guideline to mean you should do that. EEng 07:31, 3 September 2023 (UTC)

  My experience with editors who're MOS focused is very different from yours, then.

  Humour me, Eeng. Utterly needless though these clarifications are, let me put them in.—S Marshall T/C 08:46, 3 September 2023 (UTC)

  For, like, the third or fourth time, say exactly what change you want, or just put it in the guideline directly so we can all see it, or do something else tangible. You keep saying you want something added but never say quite what. EEng 19:59, 3 September 2023 (UTC)

For Christ's sake, Eeng, seriously?—S Marshall T/C 23:42, 3 September 2023 (UTC)

S Marshall's proposed revisions to Wikipedia:Manual_of_Style#Numbers. Additions in red, deletions in strikethrough

Integers from zero to nine are spelled out in words. Integers greater than nine expressible in one or two words may be expressed either in numerals or in words. Other numbers are given in numerals or in forms such as 21 million. See MOS:NUM § Numbers as figures or words. In general, use a comma commas in numbers with five or more digits to the left of the decimal point. Numbers with four digits are at the editor's discretion: 12,345, but either 1,000 or 1000. See MOS:NUM § Grouping of digits. Don't use commas after the decimal point, and don't use commas in numbers that aren't in base 10. Don't apply Wikipedia:Manual_of_Style#Numbers to articles within the scope of WikiProject Mathematics, or to text formatted with {{math}} or <math>. In these cases apply MOS:DIGITS instead. In general, use decimals rather than fractions for measurements, but fractions are sometimes used with imperial and U.S. customary units. Keep articles internally consistent. Scientific notation (e.g., 5.8×107 kg) is preferred in scientific contexts. Markup: {{val|5.8|e=7|u=kg}}. Write out "million" and "billion" on the first use. After that, unspaced "M" can be used for millions and "bn" for billions: 70M and 25bn. See MOS:NUM § Numbers as figures or words for similar words. Write 3%, three percent, or three per cent, but not 3 % (with a space) or three %. "Percent" is American usage, and "per cent" is British usage (see § National varieties of English). In ranges of percentages written with an en dash, write only a single percent sign: 3–14%. Indicate uncertainties as e.g., (1.534±0.35)×1023 m. Markup: {{val|1.534|0.35|e=23|u=m}}. See MOS:NUM § Uncertainty and rounding for other formats.

• Grouping of digits (whether by commas or spaces) is never done after the point, only before it. Our {{formatnum:}} magic word knows that too: {{formatnum:1234567.9876543}} → 1,234,567.9876543 - I'm pretty sure that there's an ISO doc on the matter, but I don't have the appropriate subscription. --Redrose64 🌹 (talk) 17:56, 3 September 2023 (UTC)

  The magic word formatnum, according to the documentation, changes its behaviour depending on the language setting of the page. That makes it more complicated than I want to think about.

  In contexts where thin spaces are being used to group digits, the grouping should be done on both sides of the decimal point. So says the National Institute of Standards and Technology (¶ 10.5.3). Jc3s5h (talk) 18:33, 3 September 2023 (UTC)

  The print Kaye and Laby separated groups of three digits with thin spaces when there were more than four digits after the point. The archive of NPL's online version also has three-digit grouping (with rather wide spaces)[1] except that mathematical constants have five-digit grouping there[2] (unlike the print edition). The SI Brochure has spaced three-digit grouping after the point, as do various ISO standards; as you say, there probably is one on the subject, or at least on the format for ISO standards. NebY (talk) 18:49, 3 September 2023 (UTC)

• NebY (talk · contribs) is correct. From p150 of the SI Brochure, 9th edition,

  Following the 9th CGPM (1948, Resolution 7) and the 22nd CGPM (2003, Resolution 10), for numbers with many digits the digits may be divided into groups of three by a space, in order to facilitate reading. Neither dots nor commas are inserted in the spaces between groups of three. However, when there are only four digits before or after the decimal marker, it is customary not to use a space to isolate a single digit. The practice of grouping digits in this way is a matter of choice; it is not always followed in certain specialized applications such as engineering drawings, financial statements and scripts to be read by a computer.

Examples given are "43279.16829 but not 43,279.168,29" and "either 3279.1683 or 3 279.168 3". Dondervogel 2 (talk) 19:49, 3 September 2023 (UTC)

The scope of my proposal was understood way beyond what I intended. My focus is on measures in SI units.

Take the example which is currently on the MOS:DIGIT as a "good" example: 255,200 km. A reader which understandably uses the SI rule to interpret it will believe the number means the same as 255.200 km, which is one thousandth of the value intended. This problem does not happen with the already allowed alternative 255200 km.

How current MOS digit grouping alternatives get interpreted

Ungrouped	MOS Groupings	Meaning on SI	Meaning on countries with decimal comma
123456	123,456	123.456	123.456
123456	123456	123456	123456
12345	12,345	12.345	12.345
12345	12345	12345	12345
1234	1,234	1.234	1.234
1234	1234	1234	1234
123456.7	123,456.7	invalid	123.4567
123456.7	123456.7	123456.7	123456.7
12345.6	12,345.6	invalid	12.3456
12345.6	12345.6	12345.6	12345.6
1234.5	1,234.5	invalid	1.2345
1234.5	1234.5	1234.5	1234.5
1.2345	1.234,5	invalid	1234.5
1.2345	1.2345	1.234	1234

Luckily not all cases are ambiguous, but any ambiguous examples of SI units in the MOS need to either be fixed by using {{val}} or be marked "bad". Nativeblue (talk) 21:32, 3 September 2023 (UTC)

Eh? Whats wrong with 1.234,5? I suppose that could be borderline (4 digits only), but consider 0.123,456,789 - the alternative 0.123456789 is a nightmare. Martin of Sheffield (talk) 21:53, 3 September 2023 (UTC)

The problem with 1.234,5 is the ambiguity (it can mean a number a little of over 1.2, or a number a little of over 1234). And the alternative to the abomination 0.123,456,789 is 0.123456789. Dondervogel 2 (talk) 22:05, 3 September 2023 (UTC)

The 1.234,5 format isn't widely used or understood. I'd probably assume it was a European version of the number I'd write as 1,234.5. 0.123456789 is indeed a nightmare; the best alternative is 0.123 456 789. I don't think anyone is seriously proposing using commas after the decimal point. If the proposed wording could be misinterpreted as implying that, it should be clarified. Certes (talk) 22:10, 3 September 2023 (UTC)

Why assume a European interpretation in an English WP? If writing on the French or German WP I'd use their formats. As for "isn't widely used or understood" you suprise me. It's how we were taught in the 1960s and how I've always written long fractions right through school exams, uni and life for the last half century. Is this some new millenial thing? Martin of Sheffield (talk) 09:47, 4 September 2023 (UTC)

• I was at school in the 1960s and 1970s (O levels in 1976; A levels in 1978). I would be perfectly comfortably with "1.2345" to mean a number a little over 1.2. No ambiguity there.
• If I encountered "1.234,5" in an English text, I would be mystified. Using British English conventions I find it impossible to parse, so, like Certes I would most likely interpret as 1234.5 (though relatively rare, it's not hard to find examples of this use [3][4][5] on English Wikipedia), but I would feel I was missing something. It's not a format we should be using or advocating on MOSNUM.

Dondervogel 2 (talk) 11:44, 4 September 2023 (UTC)

Those three examples are clearly European style. For example, $3.000,00 is obviously three thousand dollars and no cents rather than three dollars shown to the nearest thousandth of a cent. Certes (talk) 12:45, 4 September 2023 (UTC)

If you were educated in the United States, you would be repeating 5th grade for the 60th time. Jc3s5h (talk) 11:48, 4 September 2023 (UTC)

I don't think it's millennial (I'm certainly not), but commas after the point are not a format I encounter often enough to recognise it instantly. The websites I just checked describe it as unusual, though they do look like personal blogs rather than reliable sources. Certes (talk) 11:48, 4 September 2023 (UTC)

Your proposal was understood the first time and WP:SNOW-opposed. We're not going to try to forbid the current use of commas as thousands-separators. (Suggesting that we have different rules for numbers with SI units and other numbers is not realistic either.) The discussion's moved on. We're now talking about whether or not to go into detail about some other matters, such as the use of <math> formatting, binary numbers, and the use of commas as separators after the decimal point. NebY (talk) 22:21, 3 September 2023 (UTC)

• The proposal was mis-interpreted as a blanket ban on the comma as thousands separator. That blanket ban, though never intended, was indeed, snow-opposed.
• I believe the intended proposal was an adjustment to one of two different rules that already exist, one for mathematical and scientific articles (thin space separators) and one for most other articles (comma separators). It might help if the proposer would suggest a specific text change (for scientific articles). The misunderstanding might then be resolved.

Dondervogel 2 (talk) 22:42, 3 September 2023 (UTC)

Hopefully the following modification clarifies it (additions in red, deletions in strikethrough):

• In general, digits should be grouped and separated either by commas or by narrow gaps (never a period/full point).
  • Grouping with commas
    • Left of the decimal point, five or more digits are grouped into threes separated by commas (e.g. 12,200; 255,200 km; 8,274,527th; 1⁄86,400).
    • Numbers with exactly four digits left of the decimal point may optionally be grouped (either 1,250 or 1250), consistently within any given article.
    • Don't use commas to the right of the decimal point, or with numbers not in base 10.
    • Avoid having a comma in whole numbers with SI units because this is ambiguous. Instead, use a larger prefix, scientific or engineering notation or format with {{val}}. (e.g. 13.8 kV; 13.8×10³ V; 1.38×10⁴ V; 13800 V; but not 13,800 V)
    • Markup: {{formatnum:}} produces this formatting.
  • Grouping with narrow gaps
    • Digits are grouped both sides of the decimal point (e.g. 6543210.123456; 255200 km; 520.01234 °C; ⁠101325/760⁠).

(...) Nativeblue (talk) 20:33, 10 September 2023 (UTC)

The proposal at 20:33, 10 September 2023 (UTC) claims that 13,000 V is ambiguous. But making such a claim contradicts the requirement elsewhere in the guideline "use a period/full point (.) as the decimal separator, never a comma: 6.57, not 6,57." If using a comma as a decimal is forbidden, then "13,000 V" can never mean 13 V ± 0.001 V. I dispute the whole notion that the allowance in the SI Brochure of either "." or "," means that either must be allowed in any context. In the context of Wikipedia the only allowable decimal point is ".". — Preceding unsigned comment added by Jc3s5h (talk • contribs) 21:17, 10 September 2023 (UTC)

Yes; en.WP isn't written for non-English-speaking Europeans who use commas as decimal indicators.  — SMcCandlish ☏ ¢ 😼  21:22, 10 September 2023 (UTC)

English Wikipedia is read by people from all over the world, being English an official language in their countries or not. This includes people from places which use the decimal comma.

It is very unlikely that they would know that only the dot is allowed as the decimal separator, specially if they don't edit en.WP themselves, which most people don't.

Take for example an analogy with the date formats. Both mm/dd/yyyy and dd/mm/yyyy are disallowed in en.WP, but this fact does not make either of those formats unambiguous. That is why the subset of accepted formats needs to be more restrictive. Nativeblue (talk) 22:03, 10 September 2023 (UTC)

This argument is not specific to quantities expressed in SI units so does not support a requirement that only applies to such quantities. Jc3s5h (talk) 22:44, 10 September 2023 (UTC)

I would be okay with explicitly stating that commas are not used in binary and other numbering systems ("The decimal number 100 should be rendered in binary as 1100100 and not 1,100,100", etc.). But we have no need to say anything about math markup in here than we already do, because MOS:DIGITS already makes the desired exception. As Stepho-wrs points out, drawing more prominent attention to an exception for that markup may have the WP:BEANS consequence of encouraging comma haters to unnecessarily convert to such markup in inappropriate contexts just to avoid comma usage. And we don't need to say the same thing twice anyway, even for WP:SUMMARY purposes, because MOS:DIGITS is already part of the same guideline page.  — SMcCandlish ☏ ¢ 😼  01:34, 5 September 2023 (UTC)

References

full, unambiguous signifier for CNY

What would be a "full, unambiguous signifier" for CNY? My guess would be CN¥? I've seen all kinds of things including CNY, RMB, RMB¥, and I would like to tidy those up. And do we/could we have a document anywhere where we list all of them? Danielt998 (talk) 21:43, 7 September 2023 (UTC)

Seems reasonable to me, like "US$" and "UK£" (or GB£ if you prefer). The problem with the ISO codes like CNY (and USD and GBP), and "traditional" financial industry abbreviations like RMB which sometimes completely differ from the ISO ones) is that they are ambiguous with a lot of other acronyms. I know there are fans here and there of "just do everything ISO does and make it some kind of mandatory policy to follow ISO in everything" (we even have a few people who want to impose ISO dates in running text, LOL). But I think there are other, more reader-facing concerns to keep in mind. WP isn't a banking and currency-trading institutional publication, and is not in any way bound to follow the house-style ideas of publishers in that niche.  — SMcCandlish ☏ ¢ 😼  03:43, 26 September 2023 (UTC)

What is "the body of an article"?

I recently encountered Wikipedia talk:Manual of Style/Dates and numbers/Archive 162#Proposal: Allow use of % for percentages in non-technical articles, which changed the ambiguous "technical" terminology, but retained the "body of an article" terminology. Around the same time as that conversation, I was in a dispute about the use of % in an article where I was reverted when restoring to a long-standing use of %, because my interlocutor interpreted "body" as meaning "the part of the article that is not the lead". I left it standing at the time because MOS arguments are not a hobby of mine and I have really mixed feelings on that article these days anyway, but given that all terminology in MOS:% now uses "body" as opposed to "tables/infoboxen", I'm not sure if this is...the intended reading. What's the intended reading? Vaticidalprophet 02:37, 26 September 2023 (UTC)

The body is the main text of the article. It doesn't include references, see also, illustrations and their captions, the table of contents, the title, the short description, etc. Bubba73 ^{You talkin' to me?} 02:49, 26 September 2023 (UTC)

Yes, but does it include the lead? That's the specific contention in this case. Vaticidalprophet 03:05, 26 September 2023 (UTC)

I'm not sure. Bubba73 ^{You talkin' to me?} 03:14, 26 September 2023 (UTC)

Yes, it includes the lead in a context like this: we do not write lead prose differently from after-lead prose, or readers would get quickly confused, since it would seem like the content was written by two different organizations. (There may be a handful of references in MoS somewhere to "body" meaning "after the lead", but those will be clearly in their context contrasting the lead specifically from the rest of the article. Leads do have different "information architecture" requirements from the rest of the article, but are not written in a different style of writing, including "%" versus "per[ ]cent"). Anyway, it was clear from reading the MOS:% text what the issue was and a couple of edits should resolve the problem (combined diff: [6] – someone may want to tweak it further). Anyway, the point is that person you refer to who thinks "body" in this case means "only after the lead" is completely mistaken (probably just honestly confused, no wiki-lawyering inappropriately). The new footnote should fix the confusion, and has probably been needed for a long time because MoS pages should not use "wiki-terms" in ambiguous ways without being very clear what the meaning really is in that particular instance.  — SMcCandlish ☏ ¢ 😼  03:38, 26 September 2023 (UTC)

• I confess that I sometimes use "article body" to mean the part after the lead. At other times I say "the article proper". Neither is self-explanatory. Just lazy I guess. EEng 04:38, 26 September 2023 (UTC)

  There are some times when the lead is different from the rest. You are not supposed to put references in the lead. Bubba73 ^{You talkin' to me?} 05:01, 26 September 2023 (UTC)

  Not always true; we put references in the lead for claims readers are apt to find controversial, and references go in the lead on short stubs because they only consist of a lead. And that's not a style matter anyway, but a content matter, which is why WP:CITE is not "MOS:CITE".  — SMcCandlish ☏ ¢ 😼  05:30, 26 September 2023 (UTC)

  "I confess that I sometimes use 'article body' to mean the part after the lead." Sure, it can make sense when the context is clear enough, which is why MOS:LEAD uses it that way. We just had a problem here where we meant something completely different, as Bubba73 laid out above, and hopefully my footnoting and other text tweaks will resolve the confusion without any issue.  — SMcCandlish ☏ ¢ 😼  05:33, 26 September 2023 (UTC)

Commas in numbers?

Does the MOS have any suggestions on adding commas in numbers? For example, 1000 vs 1,000. I tend to add commas to differentiate between years, for example 2,023 vs 2023, but I haven't been able to find a recommendation on commas in general. Does this exist? —Panamitsu (talk) 23:21, 7 October 2023 (UTC)

Try MOS:DIGITS. ―Mandruss ☎ 23:27, 7 October 2023 (UTC)

RfC on season and episode numbering

FYI

 – Pointer to relevant discussion elsewhere.

Please see: Wikipedia talk:Manual of Style/Television#Number format within TV articles - request for views. This is an RfC on "season 3, episode 7" versus "season three, episode seven" styles (and probably also "seventh season" vs. "7th season", etc.).  — SMcCandlish ☏ ¢ 😼  19:14, 11 October 2023 (UTC)

Overlining a problem

MOS:DECIMAL currently has Indicate repeating digits with an overbar e.g. 14.31{{overline|28}} gives 14.3128. (Consider explaining this notation on first use.) An IP editor at Inch is persistently changing eg 0.333 for ⁠1/3⁠ to 0.3, claiming correctness. Not only may many readers fail to fully grasp that, but also Graham87 reports that screen readers "don't read out the attributes generated by the overline template". This particular IP editor doesn't claim to be relying on MOS:DECIMAL but others may and produce similar problems. Can we improve it? NebY (talk) 20:41, 11 October 2023 (UTC)

0.333 does indeed seem somewhat strange. If the overline is used it seems reasonable to start it as early as possible. The alternative would be to use rounding and say 0.333, without overline. Gawaon (talk) 20:58, 11 October 2023 (UTC)

That's a good point about rounding, and might well resolve that particular case of conversion values from Inch to palms, feet and yards. NebY (talk) 10:14, 12 October 2023 (UTC)

Yeah I've just tested it in both Chrome and Firefox on the two most common Windows screen readers, JAWS and NVDA, neither of which indicate the overline while reading text. If you focus on the character with the overline on it in Chrome and press JAWS key+F to get its font information, JAWS sometimes (but not always) says it has no font and has a 0-point font size, which distinguishes it from the surrounding text in a really bizarre way (screen readers are weird, m'kay?). Otherwise neither screen reader shows any indication at all. Graham87 (talk) 05:27, 12 October 2023 (UTC)

Which would seem to suggest that something that reads as 0.333 (overline being indecipherable) is going to be more useful and suggestive to unsighted readers than a simple 0.3. Of course the decimal notation of 1⁄3 is well known so this is a trivial example; more complex cases present "challenges". If we were to change the guidance, we would have to advise inclusion of at least two instances of the repeated digits (thus, for example, 14.312828). Is that realistic? --𝕁𝕄𝔽 (talk) 09:55, 12 October 2023 (UTC)

Good question, and while you're here, as another UK editor, can you say anything about the UK use of overdots? It seems[7] they may still be part of the maths curriculum, rather than the overline. NebY (talk) 10:23, 12 October 2023 (UTC)

As a UK reader I've seen both. IIRC we were taught dots at school, but that was nearly half a century ago (and I know that in WP terms that is archaic and not worth bothering with). At degree level and at work I think the overbar came to prominence, but that may simply be an artefact of international publishing. Martin of Sheffield (talk) 10:33, 12 October 2023 (UTC)

The suggested change to require at least two instances of the repeated digits sounds good to me. Graham87 (talk) 12:28, 12 October 2023 (UTC)

I wouldn't change the MoS at this time. Currently it's silent about how exactly the overline is to be used, and that's probably the best course of action. In math contexts, repeating the digits twice would probably be confusing, and outside of math contexts, the overline is likely very rarely used anyway. The Inch use case seems a bit special and I don't think we should try to derive a general rule from it. The screen reader issue is surely annoying, but the best course of action may be to complain to the vendors about it. The overline is standard mathematical notation; if they don't support it, that's their fault, not ours. Gawaon (talk) 12:58, 12 October 2023 (UTC)

A resolution by screen reader vendors/makers would be years or even decades away. The overline is implemented as a CSS style and most of those are rightly ignored by screen readers unless the user tells them otherwise. Also see the "Screen readers do not update overnight" section (and others) from this blog post which is about memes but has some relevant points here. Graham87 (talk) 17:15, 12 October 2023 (UTC)

As the nutshell of Wikipedia:Manual of Style/Accessibility says, Wikipedia pages should be easy to navigate and read for people with disabilities. Managing accessibility isn't a matter of who we can blame, and it's not WP policy to leave the users of screen readers stranded between the shortcomings of the technology and a lack of understanding by editors.

There are other uses of {{overline}} such as for crystal classes in mineralogy, and some of the 2036 transclusions are in maths articles, but some are in more general articles such as other units of measurement, or coins. One Half farthing is stated in the infobox to be worth £0.00052083 (ie with a final overlined 3); I do wonder how many general readers recognise that at once not to mention whether WP:ENGVAR requires the use of a dot instead. I don't imagine we could give an all-encompassing rule, but we might in MOS:DECIMAL

• inform editors that users of screen readers won't hear any indication of an overline
• suggest truncating at reasonable resolution instead, outside of maths contexts, and/or
• suggest showing initial repeats, outside of maths contexts.

NebY (talk) 18:51, 12 October 2023 (UTC)

Sounds reasonable, I'm not opposed. Gawaon (talk) 07:33, 13 October 2023 (UTC)

I strongly support requiring rounding to sensible precision. In the example, the precision given is a schoolboy error when describing a real-world item. £1⁄1920 is "about £00052". 𝕁𝕄𝔽 (talk) 08:36, 13 October 2023 (UTC)

Thanks, all. I've edited MOS:DECIMAL accordingly, using the above examples. I've put it mildly (overbars may be used but consider rounding etc) but we could be stronger (eg saying rounding is preferred or making it imperative), and I expect the phrasing can be improved in other ways. NebY (talk) 16:36, 14 October 2023 (UTC)

Style: specifying units after defining variables?

I have a difference of opinion with someone who has contributed heavily to the article on Magnetic sail technology. The article frequently defines variables for use in equations, like ion mass and density, followed by a specification of units like "(kg)" or "(kg/m3)" etc. I find this misleading and inappropriate, as it suggests (to me) that the measured values must be measured in these units and no others. The other author says he is just announcing which units will be used in later examples using the variables, but that is not what "(kg)" necessarily means by itself; it seems very ambiguous and misleading when set next to the definition of a term. Indeed, this even is done in contexts quite distant from any examples, as in a listing of parameters, i.e., relevant factors, for defining a plasma, which include "the number of ions...per unit volume (m-3), the average mass of each ion type accounting for isotopes (kg)..." This seems odd to me, as the mere statement that the number of particles/ions per volume is relevant doesn't require the use of any particular units. The density is relevant whether the unit volume is m-3 or cm-3 or something else, as long as it's a volume denominator. Again, particular uses of this variable must use particular units, but the units used are irrelevant to a general discussion of what factors characterize a plasma.

It feels to me like talking about Newton's laws, and saying "F = ma where m is mass (kg) and a is acceleration (m/s2)". Now of course, if you're going to use an example, you must give specific units, and be consistent with their use. If you're saying the earth's force of gravity produces an acceleration of 9.8, you must follow this with m/s2; if you're talking about a specific apple's or asteroid's weight, you must specify this as X grams or Y trillion kg or whatever, and if this is used in a formula the other terms must be expressed in the same units, or one must be converted into the other.

But it does not seem appropriate to constantly say "(kg)" after, e.g., each mention of a new variable (for ion mass, for electron mass, for mass per unit volume, payload mass, etc.) This seems to both take up extra room and potentially mislead the reader.

I do not immediately see this issue addressed in the present article, but perhaps I am missing something. What do others think about this issue? Any particular instance of this may be relatively minor, but it seems like a strange style choice, one not made by most other articles using physics terms and formulas, and I would like to seek greater consistency on this.23:37, 13 October 2023 (UTC) ScottForschler (talk) 23:37, 13 October 2023 (UTC)

If the variable is defined apart from any example or equation, I don't think it is necessary to give units. You already agree for the need to give units if there is an example. I believe it is also necessary when an equation is given. Using F=ma as an example, this would be false if F were pounds force, m was pounds mass, and a was miles per hour. Instead of giving units, one could state a coherent system of units must be used. But that introduces a level of abstraction that I don't think is ideal for a generalist publication like Wikipedia. Jc3s5h (talk) 00:00, 14 October 2023 (UTC)

"Instead of giving units, one could state a coherent system of units must be used. But that introduces a level of abstraction that I don't think is ideal for a generalist publication like Wikipedia."

I agree. I have found dozens of errors in equations in books and papers that do not give units along with the equation. Having the units stated (somewhere) enables dimensional analysis of the terms on both sides of an equation and helps identify and prevent such errors.

This also places an additional burden on the reader to determine what is a "coherent system of units." It is more straightforward to simply just state the units - without parentheses. Dmcdysan (talk) 04:35, 16 October 2023 (UTC)

I disagree; determining and sticking with a "coherent system of units" is not a burden to anyone with the most minimal competence in physics. If a reader doesn't know what a coherent system of units is, no short statement of units will be used is going to enlighten them, and an exhaustive explanation on every article mentioning a physics equation is "an undue level of abstraction" placing great burdens on both authors, and competent readers who have to wade through this ad nauseum. But I also don't see what's wrong with using parentheses around units to indicate that these are the ones to be used in general in a certain context, I only object to the idea that this indication is needed when no such general use follows immediately.ScottForschler (talk) 19:01, 16 October 2023 (UTC)

Sorry, I'm not following you. How would you explain to a person without a most minimal competence in physics a "coherent system of units?" Please use the F = m a equation as an example.

"I only object to the idea that this indication is needed when no such general use follows" I think we may be approaching agreement on this - I think that the current article has excessive and unnecessary replications of units. I recall proposing on our private Talk on this subject that units need only be mentioned once per article, section, (group) of equations, figure or table. Would this address your above comment?

Usage of parentheses raised a number of objections on this thread. I think the same thing can be done without parentheses.

An equation in general physics, and other mathematically based disciplines is inherently unitless. I don't see this as an inconsistency, just a different usage of mathematics. I will try to explain later with an example from the IEEE guidelines. Dmcdysan (talk) 00:45, 17 October 2023 (UTC)

I looked up Coherence (units of measurement)#List of coherent units) and all units there are listed in parentheses.

I had proposed that somewhere early in the magnetic sail that a statement indicating that coherent or derived SI units are used where defined and conversion from cgs units may be necessary for certain cited references.

I also proposed that units need only be mentioned once per article, section, (group) of equations, figure or table. This would drastically reduce the number of instances that units need be stated.

At some point, having the text mention the name(s) used in the article, section, equation (group) unit name; for example in the magnetic sail context:

Drag is a force Newtons (N).

Plasma mass density ρ (kg/m³)

A number of units in magnetic sail appear to not be defined in SI units. or have several options, and the following are widely used in magnetic sail cited references

Proton mass m_p Kilograms(kg)

ion mass m_i Kilograms(kg) for an ion with Atomic number Z_i

ion number density n_i (ions/m³)

Spitzer resistivity η_p Weber metre (W m)

The MOS style guide clearly states that units are to be used without parentheses when following numbers; however, it also states that "Units unfamiliar to general readers should be presented as a name–symbol pair on first use, linking the unit name (Energies rose from 2.3 megaelectronvolts (MeV) to 6 MeV)." puts general(units) in parentheses, using a similar style to that of the SI units given above. Is that acceptable to the experts on this thread?

I want to have a clear consensus before going through the article and making changes, and I believe that the usage of parentheses is allowed when the units do not follow numbers. How does a consensus process work here? What is the range of time needed? This is not an urgent issue, but I will not start any major editing until I get feedback. I also plan to study the MOS and make other necessary changes as I progress through each section.

I also have two other formatting issues suggested by another editor that appear appropriate to discuss here that I will place in a separate topic. I would like to have consensus on all of these subjects before doing an editing pass through the entire article, where I also plan to also add some clarifying text to make the article more accessible to readers without having to understand the equations.

Questions, comments?

Thank you in advance for your support in making Wikipedia a consistently formatted encyclopedia! Dmcdysan (talk) 20:43, 18 October 2023 (UTC)

Don't forget coherent. EEng 22:27, 18 October 2023 (UTC)

Not sure I understand your comment - does the following proposed wording address it? If not, please clarify.

"proposed somewhere early in the magnetic sail (article) that a statement indicating that coherent or derived SI units are used where defined and conversion from cgs units may be necessary for certain cited references." Dmcdysan (talk) 23:25, 18 October 2023 (UTC)

"If the variable is defined apart from any example or equation, I don't think it is necessary to give units." I agree with this as well. I still have a question of whether units should be used when referring to a figure or table.

For example, If the axes in a Figure are F and an and m is a parameter for multiple curves in the Figure (for which no dimension is given to not clutter up the graph.) Which would be the preferred style:

"Figure foo plots force F N versus acceleration a m/s^2 with mass m kg as a parameter for the multiple curves."

OR

"Figure foo plots force F versus acceleration a with mass m kg as a parameter for the multiple curves." Since units for F and a are given on the Figure axes. Dmcdysan (talk) 04:39, 16 October 2023 (UTC)

Of course units should be given for tables with specific numbers therein, or graphs for that matter, that was never any part of my objection. I'm not sure I quite grasp your two options as listed--the grammar of your explanation and offered options seems confusing to me. But I don't see why it matters much where the units are mentioned, as long as they are either on or near the figure.ScottForschler (talk) 19:09, 16 October 2023 (UTC)

This is a minor formatting question. If the units are on the figure/table should they be repeated in the associated text, or left out of the text. I prefer repeating them in the text in the first example

"Figure foo plots force F N versus acceleration a m/s^2 with mass m kg as a parameter for the multiple curves."

The second example removed the bold faced units. Dmcdysan (talk) 00:51, 17 October 2023 (UTC)

I just took a look at the article. The use of units in brackets adds unnecessary clutter and distracts the reader's attention away from what matters (the concept or the equation). There might be some rare exceptions, but in general the unit belongs with numerical examples only. Dondervogel 2 (talk) 06:52, 14 October 2023 (UTC)

It's not merely superfluous to provide units for the variables when all the values employed are not merely in coherent units but specifically in SI units, their provision in brackets makes formulae and expressions ambiguous puzzles ("$M_{c}(min)$") - are these variables in the formula or units extraneous to it? It is also emphatically wrong to provide values with units in parentheses ("has a mass density of 3,500 (kg/m3)", "$J_{e}$=10¹¹ (A/m²), $r_{sc}$= 5 mm, $\rho _{sc}$=6,500 (kg/m³)"), whether done consistently or in this case, wildly inconsistently; see MOS:UNITS, the SI brochure , or any textbooks, standards, or publications of NIST, IEEE, etc. NebY (talk) 09:57, 14 October 2023 (UTC)

In the formula M_c(min) the "min" indicates the minimum valued is not a unit. I agree with removing parentheses around units when used with numerical values, this is not done consistently in the article. Dmcdysan (talk) 23:30, 15 October 2023 (UTC)

I was not aware of the MOS:units link and I will modify the Magnetic sail article to match this style (i.e., remove all parentheses and fix other style conventions in one pass. Thank you!

A few more related questions:

For an equation for M_c(min) that you said was ambiguous, where the subscript c already has other meaning so that min can't be used as a subscript and without defining another variable. Would the notation _minM_c be preferable? I could not find this in Wikipedia:Manual of Style/Mathematics

When a variable B_u and units T (Tesla, not in the MOS:Units guide) on as axis title in a Figure, should this be done with or without parentheses, For example "B_a T" versus "B_a (T)." I did not find this in MOS:Units or Wikipedia:Manual of Style/Mathematics.

Similar questions for units in Table column headers: "The values for the equation R_a B_a = R_u B_u are shown in the Table foo." The Table column headers without parentheses would be "|R_a m | B_a T | R_u m | B_u T|" which looks odd to me. "|R_a (m) | B_a (T) | R_u (m) | B_u (T)|"

Many technical papers put the units for Figures axis titles and Table column headers in parentheses. If there is a style guide for this, I could not find it and if one exists if you could help me find it that would be much appreciated. If there is not a style guide covering this, then I suggest there should be. Dmcdysan (talk) 02:33, 16 October 2023 (UTC)

"It's not merely superfluous to provide units for the variables when all the values employed are not merely in coherent units"

How are the "coherent units" communicated to the reader?

Many publications have a Table with the variable names, a brief description and units as columns, which in my opinion is acceptable, but I prefer the units spelled out upon first use in an equation if they are used consistently in an entire article, sections, or subsequent equations, a plot in a Figure, or Table. Dmcdysan (talk) 04:53, 16 October 2023 (UTC)

From https://mentor.ieee.org/myproject/Public/mytools/draft/styleman.pdf

15.1 Letter symbols and units

Letter symbols defined in applicable IEEE standards (see Clause 2) should be used in preparing mathematical expressions. (See 14.4 for a discussion of letter symbols.)

All terms shall be defined, including both quantities and units, in a tabulation following the equation [see Equation (1)]. The list should be preceded by the word where, followed by the list of variables and corresponding definitions. See 4.5 in Annex B for an example.

The Dipole#Field of a static magnetic dipole equation format is an example of following this standard.

Instead of inventing a new style for Wikipedia, I suggest that an existing technical document standard, such as IEEE be used.

I didn't see answers to my questions regarding Figure and Tables in this document. Dmcdysan (talk) 06:01, 16 October 2023 (UTC)

I see that you deleted all units in parentheses, that saves me from having to do it, but loses some information. At least the plasma specific variables need units on first use using the NRL formulary. I interpret your comment that further copy editing is needed to add formatting from MOS as mentioned on this thread; specifically only mention units with the spelled out SI (or NRL) unit name (as described in MOS) and the abbreviation in the minimum number of places, preferable only once. Here is an example where I did this requiring changing the unit name to align with SI units (it was ambiguous), giving the spelled unit name (and abbreviation) only once for the entire article. A similar change would help clarify the H magnetic field strength and others terms there.

https://en.wikipedia.org/w/index.php?title=Biot%E2%80%93Savart_law&diff=1181066530&oldid=1180834647

I think a similar style can be used for much of the magnetic sail article only mention the unit name as a wikilink and (abbreviation) only once. Will see if there is any feedback there before proceeding on magnetic sail.

BTW, I like the way your formatted units to a separate column in the table and that addresses one of my questions.

In the Biot-Savart article is also a style suggested by constant314 for referencing a specific chapter, section, equation for a citation in a more compact way than done in magnetic sail, and I plan to use that in my editing pass that also should reduce clutter. Dmcdysan (talk) 17:12, 20 October 2023 (UTC)

I see you've reinserted many of the improperly placed units that I'd removed, then tagged the article as under construction so as to make yourself the only one editing the article, and have edited the article and the talk page using two accounts, Dmcdysan and Sumlif2. You do not have consensus for the placing of those units, you're ignoring what multiple editors are telling you here, and you're giving the impression that you have support for your stances. Have you read WP:IDHT, WP:OWN and WP:SOCK? NebY (talk) 18:35, 22 October 2023 (UTC)

Another style commonly used is an example such as the following:

Dipole#Field of a static magnetic dipole

The far-field strength, B, of a dipole magnetic field is given by

$B(m,r,\lambda )={\frac {\mu _{0}}{4\pi }}{\frac {m}{r^{3}}}{\sqrt {1+3\sin ^{2}(\lambda )}}\,,$

where

B is the strength of the field, measured in teslas

r is the distance from the center, measured in metres

λ is the magnetic latitude (equal to 90° − θ) where θ is the magnetic colatitude, measured in radians or degrees from the dipole axis

m is the dipole moment, measured in ampere-square metres or joules per tesla

μ₀ is the permeability of free space, measured in henries per metre.

In my opinion, this more readable than a table. It avoids ambiguity. If the article just gave the equation and names of the variables and sited that coherent SI units are to be used, then how does the reader determine the appropriate units? Dmcdysan (talk) 05:10, 16 October 2023 (UTC)

Here is another way that units are used specific to magnetic sail:

https://en.wikipedia.org/wiki/Plasma_parameters

and the NRL plasma formulary https://library.psfc.mit.edu/catalog/online_pubs/NRL_FORMULARY_19.pdf

which gives units for individual variables, conversions between unit systems (e.g., could be used to convert the Wikipedia article from cgs to SI).

It also has theoretical plasma physics equations, which like other theoretical physics equations, are unitless because the functions are just mathematical abstractions that do not have a direct physical interpretation. To assign numbers to theoretical (plasma) physics equations requires specification of units and then assignment of values according to the units to give the equation physical meaning.

A principal goal of the magnetic sail article is to assign numbers to theoretical equations and hence specification of units is necessary. I believe this is true in general. Dmcdysan (talk) 08:28, 16 October 2023 (UTC)

Jc3s5h (talk) 00:00, 14 October 2023 (UTC) wrote "You already agree for the need to give units if there is an example. I believe it is also necessary when an equation is given."

I agree.

I would state the example relevant to the specific point made by ScottForschler (talk) 23:37, 13 October 2023 (UTC) as follows: "When Force F is expressed in Newtons (N), as done in most references cited in this article, then in the formula F = m a, a consistent set of (units) are m is mass (kg) and a is acceleration (m/s^2).

This need only be stated at the beginning of an article (as in the above example), section, (group) of equations, a figure or table.

This would avoid repetition of units in *many) other places as in the current Magnetic sail article. In the above style I believe the phrasing (units) pairs with the parenthesized (unit expression), or the parentheses could be removed. I have seen both styles used in technical papers, I prefer the parentheses but will conform to whatever consensus is reached regarding the Manual of Style. Dmcdysan (talk) 23:49, 15 October 2023 (UTC)

This increases my suspicion that you were in fact modeling the units style after that used in technical papers. But these have very different, and much narrower, purposes than a general encyclopedia article does. I am glad we are coming closer to agreement on this.ScottForschler (talk) 19:14, 16 October 2023 (UTC)

Yes, I interpret Using Sources below to include the use of units for variables or equations as used in the source or required by the reliable source publisher. I believe this has precedence over a formatting style as discussed here. However, I plan to go through the article and use the style guide and our discussion to remove excessive usage of (units), as well as parentheses and only introduce units as little as needed, as I understand your comments. I believe keeping a small subset of the equations helps verifiability, but I plan to pay close attention to those that you found confusing and either add or clarify additional text, and possibly remove some equations. However, renumbering and changing the cross references is a manually intensive process with the current state of Wikipedia technology and that disincentivizes me from doing this. The cited references have many equations and the summarization reflects the same style.

"Wikipedia is fundamentally built on research that has been collected and organized from reliable sources, as described in content policies such as this one. If no reliable independent sources can be found on a topic, Wikipedia should not have an article about it. If you discover something new, Wikipedia is not the place to announce such a discovery.

The best practice is to research the most reliable sources on the topic and summarize what they say in your own words, with each statement in the article being verifiable in a source that makes that statement explicitly. Source material should be carefully summarized or rephrased without changing its meaning or implication. Take care not to go beyond what the sources express or to use them in ways inconsistent with the intention of the source, such as using material out of context. In short, stick to the sources." Dmcdysan (talk) 01:32, 17 October 2023 (UTC)

References

Does this article assume that "the year 2023" contains a four-digit number?

"Numbers with exactly four digits left of the decimal point may optionally be grouped (either 1,250 or 1250), consistently within any given article."

The above quote from the article might be intended to imply that if an article contains "2023" for any reason, including because it means "the year 2023", all other four-digit numbers should be written without a comma. Full disclosure: I would like that because I think four-digit numbers should never be written with a comma.

Whether or not that is the case, I think the article should be clearer on this point. Does, according to this article, "the year 2023" contain a four-digit number? Polar Apposite (talk) 19:25, 21 October 2023 (UTC)

From MOS:DIGITS (last bullet point): "Four-digit page numbers and four-digit calendar years should never be grouped ...". So you can have 2,023 articles in a bag, but this year is always 2023. Martin of Sheffield (talk) 19:39, 21 October 2023 (UTC)