Wikipedia talk:Manual of Style/Dates and numbers

Astronomical units

(The discussion wrapped up and resulted in a change to the MOS.)

Another thread recently concluded that units approved for use with the SI do not need to be converted to SI units. Astronomical units (AU) are approved for use with the SI, but there was some sentiment expressed that they should be converted to SI units.

The RFC on very large distances has concluded that light-years should be primary, with conversion to parsecs and not kilometers or foometers. One big objection to kilometers at that scale was that exponential notation would be required to express those quantities, and many readers would find that difficult to understand. Interplanetary distances are small enough that they can be written in familiar words. Pluto currently does that even in its infobox, and it seems to work OK.

Previous discussion resulted in a decision not to use metric prefixes larger than "tera", because they would not be widely understood; planetary systems extend into the petameters, e.g. the heliopause, though most AU distances probably don't. Articles like Makemake currently use Tm.

Which solution are people in favor of?

1. Astronomical units are accepted for use with the SI, and don't need to be converted.
2. Astronomical units should be converted to kilometers using "million", "billion", or "trillion" in both prose and compact environments like infoboxes and tables. Examples:
   • 49.3 au (7.38 billion km)
   • 121,000 au (18.1 trillion km)
3. Astronomical units should be converted to meters using metric prefixes. Examples:
   • 49.3 au (7.38 Tm)
   • 121,000 au (18.1 Pm)
4. Something else.

Presumably we'd flip to using light-years and parsecs before getting over 9,999 trillion km, possibly even before 999 trillion km. A million AU is about 150 trillion km, and going over 1 million AU could be awkward anyway. -- Beland (talk) 19:06, 6 September 2024 (UTC)

I've nothing against light years or AU, but articles should include a converted value to metres with the appropriate prefix that avoids decimal places 49.3 AU (7,380 Gm). A kilometre is after all 1000 metres. Wikipedia educates, the reader can always link to Giga or another prefix to see what it is. We already use Giga or Gibi for computer storage. Avi8tor (talk) 19:29, 6 September 2024 (UTC)

Hmm, Wikipedia:WikiProject Astronomy/Manual of Style#Units recommends km/s for large velocities, like interplanetary spacecraft. It's a bit harder to compare tens of thousands of km/s to Tm instead of billions of km (though obviously a lot easier than miles). -- Beland (talk) 20:22, 6 September 2024 (UTC)

Your option 2 seems like a good balance: trillion is the largest we'd ever really hit (once around 100,000 au we should switch to ly; might be worth putting that in the guidelines!), and I don't see a large benefit in using metric prefixes for million and billion here. I think the point of a converted value is for people to have a value they can try to compare with ordinary life, and "million km" seems easier to do that with than "billion m". Scientific notation probably isn't worth using in prose but might be in info boxes? - Parejkoj (talk) 20:31, 6 September 2024 (UTC)

NOT #3. The point of the conversion is to move out of specialist-speak. Giving two specialist versions is pointless. Johnjbarton (talk) 23:04, 6 September 2024 (UTC)

Option 2 is clear and useful, and we don't really need to worry about expressing anything in trillions of kilometres. Neptune's only about 30 au (4.5 billion km) from the sun and even the heliopause is about 120 au (18 billion km) out. 121,000 au (1.91 ly) is really an interstellar distance, nearly halfway to the nearest star out here in the boondocks, and I wouldn't expect our sources to be using au then. Not #3, it makes reading too much like hard work. NebY (talk) 23:38, 6 September 2024 (UTC)

I must have been reading something other than the heliopause that's 120,000 AU out and got my numbers mixed up. Oort cloud and a couple dozen other articles do use 200,000 AU, 100,000 AU, and 50,000 AU. Comet, for example, actually converts 50,000 AU to light-years.

We could actually advise, say, anything over 10,000 AU should have AU converted to light-years and not kilometers (that's about 0.16 ly). That starts to become a significant fraction of the distance to the nearest star. It would ease the transition from km to light-years; otherwise short distances have AU+km and long distances have ly+pc and there's no way to directly compare them. -- Beland (talk) 00:58, 7 September 2024 (UTC)

My preference would have been to use AU for small (astronomical) distances and pc (or ly) for large ones, with continuity ensured by always converting to SI. I understand Beland's proposal to be: convert AU to km for short distances, AU to ly for middle distances and ly to pc for long interstellar distances. It's a pig's ear but it's probably the best we can do given the (IMO misguided) decision to avoid converting interstellar distances to SI. Dondervogel 2 (talk) 06:42, 7 September 2024 (UTC)

Ah yes, I was forgetting how great comet orbits can be and the hypothesised extent of the Oort cloud. I'm hesitant about giving advice on a transition point (a little like saying when to use inches or feet) or introducing a third conversion pair. My rule-of-thumb might be that in a planetary or in-system context use au/km, in an interstellar one use ly/pc, and if if it should be put in both contexts then consider using not only one context's pair but also the lead dimension from the other (au/km + ly, or ly/pc + au), but sparingly - and there has to be a better way of putting that. NebY (talk) 12:34, 7 September 2024 (UTC)

I concur that we shouldn't have a transition distance, but rather recommend AU for in-system contexts and ly for interstellar contexts. When both contexts are relevant I think it's better to not try to make a rule; Solar system mixes AU, ly, and km in various places, and I think they do a good job. Tercer (talk) 13:03, 7 September 2024 (UTC)

Should we just say something like "where interplanetary and interstellar scales overlap, it is OK to convert between AU and light-years to make distances comparable"? BTW, for clearly interplanetary distances, were you in favor of AU+km or just AU? -- Beland (talk) 16:55, 7 September 2024 (UTC)

I think that's a good solution. As for AU+km or AU, I don't have a strong opinion. 150 million km is on the edge of what can be intuitively grasped, so it can be useful for some readers. I don't think it's worth the clutter, so I'd rather write only AU. But if some editor wants to add the km conversion I won't bother them about it. Tercer (talk) 19:28, 7 September 2024 (UTC)

Personally I'd favour option 2 as most reader-friendly. However, option 1 follows logically from our general rule that "units approved for use with the SI do not need to be converted to SI units", so it would be a reasonable solution too. Gawaon (talk) 06:42, 8 September 2024 (UTC)

Option #4. None of Options #1-3 are compatible with the use of pc/ly for interstellar distances. To avoid inconsistencies, we need overlap between

• large interplanetary distances (in au) and small interstellar distances (in ly/pc), and
• large planetary distances (in km) and small interplanetary distances (in au).

The only way I see to achieve both is to convert au to SI for small interplanetary distances and au to ly/pc for large ones. Dondervogel 2 (talk) 09:02, 8 September 2024 (UTC)

Comment To give some examples for how the latter is currently handled: at a predicted minimum distance of 0.051 parsecs—0.1663 light-years (10,520 astronomical units) (about 1.60 trillion km) (from the lede of Gliese 710); about 52,000 astronomical units (0.25 parsecs; 0.82 light-years) from the Sun (from Scholz's Star); and Semi-major axis 506 AU (76 billion km) or 0.007 ly (from the infobox of Sedna). Renerpho (talk) 22:55, 8 September 2024 (UTC)

The second one looks to me like the MOS-preferred style (other than the choice of units) for a triple conversion and something that naturally comes out of {{convert}}, whereas the other two need some tidying up. The quadruple conversion seems like a bit much. -- Beland (talk) 17:20, 9 September 2024 (UTC)

In the case of the solar system article, it became a bit silly to keep converting distance scales from AU to km. The consensus was to use AU throughout, because the AU is intended for interplanetary scales (whereas km is intended for planetary scales). There is a comment in the early part of the article explaining the term, and that is all that is needed. The comparable conversion used on the asteroid articles is AU and Gm. Praemonitus (talk) 21:57, 9 September 2024 (UTC)

• From the listed options I would go with Option 1 (just use AU), though I could see giving a conversion to either km or m using scientific notation. I have a pretty strong negative reaction to Gm, Tm, etc; I think that's just SI fetishism. I'm fairly sure those units are used at most sparingly in the wild. --Trovatore (talk) 00:17, 10 September 2024 (UTC)

I'd go with Option 1, but most importantly we should use the modern abbreviation au wherever it appears. Wikipedia's usage has been left inconsistent for too long (including in this thread). Skeptic2 (talk) 11:29, 12 September 2024 (UTC)

Fully agree about consistency of symbol (au, not AU). Let's make sure any new guidance reflects that consensus. Dondervogel 2 (talk) 11:55, 12 September 2024 (UTC)

Is that a proposal to delete "Articles that already use AU may switch to au or continue with AU; seek consensus on the talk page." from MOS:UNITSYMBOLS? I use "AU" in conversation because that's what I learned in as an undergrad, but I have no particular preference. -- Beland (talk) 18:00, 12 September 2024 (UTC)

That was not my intention. I just meant that any new statement about astronomical units should follow existing mosnum consensus, which is to use au for the unit symbol. I can't speak for Skeptic2. Dondervogel 2 (talk) 18:06, 12 September 2024 (UTC)

I have no strong preference between au and AU, but I'm less than convinced that this needs to be uniformized across Wikipedia as a whole. The main thing is that it be consistent within any single article, in the spirit of WP:ARTCON. --Trovatore (talk) 18:09, 12 September 2024 (UTC)

Hmm, well, the existing consensus isn't exactly for "au", it's for "au" except where "AU" is consistently established. I intentionally used "au" in the examples because that seems to be the long-term direction we're going, but for consistency with the other recommendation the examples might need to have a note saying "AU" is OK if used consistently throughout an article. On the other hand, if we're adding or removing conversions across the entire project, that would be a good time to standardize on "au". Dropping the "AU" exception would also result in simpler rules. Either way, I'm going to run a script to find non-compliant instances like I did to enforce the new rule that liter uses a capital "L" symbol.

BTW, I was wondering where consensus for the existing guidance was established, and it appears to be Wikipedia talk:Manual of Style/Dates and numbers/Archive 157#Abbreviation for astronomical unit once again. -- Beland (talk) 18:16, 12 September 2024 (UTC)

I prefer option 1, no conversions or optional conversions. 21 Andromedae (talk) 15:27, 14 September 2024 (UTC)

The use of au in place of AU was recommended by the IAU in 2012 and is now adopted by leading professional journals such as MNRAS, ApJ, AJ, etc. Hence au is the internationally recognized abbreviation and should have been adopted by Wikipedia a decade ago.Skeptic2 (talk) 19:00, 12 September 2024 (UTC)

Summing up au

OK, trying to score the opinions above in a reductionist fashion (correct me if I've gotten anything wrong):

• Avi8tor: #3
• Parejkoj: #2
• Johnjbarton: NOT #3
• NebY: #2, NOT #3, for overlap: au+km+ly (and in reverse ly+pc+au)
• Dondervogel2: #2 more or less, for overlap au+km, au+ly+pc
• Tercer: #1 but #2 OK, for overlap: "where interplanetary and interstellar scales overlap, it is OK to convert between AU and light-years to make distances comparable" rather than a specific rule
• Gawaon: #2 but #1 OK
• Praemonitus: #1 for solar system
• Trovatore: #1 but #2 OK, m with scientific notation OK, NOT #3
• Skeptic2: #1

And tallying those up:

• #1: 3 first choice, 1 second choice, 1 for solar system context
• #2: 4 first choice, 2 second choice
• #3: 1 for, 3 explicitly against
• #4: 3 in favor of conversion from au to at least ly to provide overlap

It's pretty clear there is consensus against #3, and it looks like there's a weak preference for #2 over #1. Given the reasons people noted for and against converting au to km, it might make sense to adopt #2 but emphasize the existing "excessive" exception, which will result in #1 in places where I expect people feel strongest that au-only is better.

It seems we favor "au" over "AU", so I'll use that in examples. I'm doing some database scans and will ask about removing "AU" as an allowed unit as a separate question once I have some numbers.

It also seems like there's support for having overlapping but not rigidly specified ranges between km, au, and ly, so readers can make appropriate comparisons. Exactly how to do that was a bit unclear, but for the sake of operationalizing this, I'll make a specific proposal. (If people have strong feelings, feel free to discuss.) The previous RFC decided to convert ly to pc, and there might be some objections if ly are used and pc are not (though astronomers also use au). It also decided not to convert between km and ly, partly because of comprehensibility problems with overly-large quantities of km, so maybe we should avoid doing that. Which would also mean the same units would be used no matter whether au or ly were primary, which is kind of nice. So the overlapping units on the high end would be au, ly, and pc, with either ly or au primary.

So, how about adding this as another "Generally...except" bullet point after the "light-years" exception:

• Astronomical units (au) should be converted to kilometers (km) using "million", "billion", or "trillion" in both prose and compact environments like infoboxes and tables. When large interplanetary-scale distances overlap with small interstellar-scale distances, convert au to ly and pc, or ly to pc and au (depending on context). Examples:
  • 49.3 au (7.38 billion km)
  • 121,000 astronomical units (1.91 light-years; 0.59 parsecs)
  • .9 ly (0.28 pc; 57,000 au)

and add "articles like Solar system where many interplanetary distances are given" to the list of examples on the "excessive" exception. -- Beland (talk) 03:26, 13 September 2024 (UTC)

Thank you for taking the time to do this. You have captured my position well in your summary. Dondervogel 2 (talk) 05:52, 13 September 2024 (UTC)

I think the last example should read "0.9 ly" since we don't do 0-dropping. Otherwise I like it! Gawaon (talk) 06:11, 13 September 2024 (UTC)

Oh man, well spotted. I have a script to fix that very thing, and am sad to have not noticed that. So make that:

0.9 ly (0.28 pc; 57,000 au)

— Preceding unsigned comment added by Beland (talk • contribs) 17:57, 13 September 2024 (UTC)

Added to the MOS page; further tweaks welcome if anyone notices anything else amiss. -- Beland (talk) 23:00, 13 September 2024 (UTC)

Guidance at APPROXDATE for completely unknown ranges

At risk of instruction creep... currently MOS:APPROXDATE has guidance for various partially unknown date ranges. It doesn't say anything about when everything is unknown, presumably because most editors simply omit it when there's nothing to say. However, it seems there are lists which have say a birth / death range as a standard inclusion per row, and some editors might be tempted to throw in an empty range to mark that the range is not included. There doesn't appear to be MOS guidance for this case, currently.

My suggestion to add:

If both extremes of a range are unknown but a c. or fl. marker is inappropriate, omit the range entirely. Do not use ?–? or ????–????. This is true even if part of a section that normally includes such a range, e.g. a list of people with their birth and death dates. In the rare scenarios where such a range is important to include anyway, use (unknown) or (disputed) if there are referenced scholarly sources saying it is flat unknown or a debate, but do not use these if the dates merely haven't been found in sources consulted so far, such as for obscure people or organizations.

This would basically make "omit it" the default. Thoughts / alternative ideas? Would this be a useful inclusion? (Or alternatively does anyone want to argue we should suggest something different for this case, e.g. using "(unknown)" even when it might be known, just not to the Wikipedia editors at the moment?) SnowFire (talk) 22:04, 10 September 2024 (UTC)

• Two points:
  • The issue isn't specific to dates or date ranges. It could be any data in a table, so I'm not sure it's a dates-and-numbers issue specifically.
  • The advice to say unknown or disputed is good, but my intuition is this isn't something that MOS should opine on (not yet, anyway) -- see WP:MOSBLOAT. Has there been controvery about this on multiple articles currently?

EEng 23:27, 10 September 2024 (UTC)

I'm honestly not sure if it comes up particularly often. It came up recently at a FLC discussion and I realized there didn't appear to be a "standard" to settle the matter. I'm sensitive to CREEP concerns and if we want to just file this one away as a "wait for a 2nd person to complain", that's fine by me - just figured the first person to raise the matter might still be a useful signal. SnowFire (talk) 09:14, 11 September 2024 (UTC)

Strong oppose the proposal. This comes up all the time if you are writing about medieval and earlier people and events. Obviously you still have include something. It's completely ridiculous to say dating should be suppressed just because we don't know if, for example, someone was born in 1105 or 1109, or some date in between! But there's no point in another finely-tooled set of instructions which most will ignore. MOS:APPROXDATE is already rather too long and over-prescriptive. Johnbod (talk) 15:34, 21 September 2024 (UTC)

Estimated or approximate non-dates?

We generally don't use c.  (etc.) for figures other than dates, even in places we would happily use the English word around. Would it be appropriate to explicitly mention options for non-dates such as est. , approx. , and associated templates somewhere? Both the attempted use of circa for non-dates, as well as general confusion on the matter seem at least semi-frequent. Remsense ‥ 论 05:36, 21 September 2024 (UTC)

Circa or c. is mostly used for dates, but there is nothing in its meaning to make it only for dates. Making a new rule (on top of our already too many) seems unnecessary for me. SchreiberBike | ⌨  00:49, 22 September 2024 (UTC)

I agree there shouldn't be any new provisions, but use of c. or circa for anything but dates, years, etc. will strike readers as very awkward. I'd challenge you to find any non-time usage in high-quality sources. EEng 01:24, 22 September 2024 (UTC)

That would seem an etymological fallacy to me: the very existence of the narrower convention where it is used only for dates means that other uses trying to treat it as a perfect synonym of around are actively awkward to read; it is a wrong usage. With that made clear, I would object that this is likely MOS creep: approximated and estimated figures are important and common, and editors routinely express a general lack of understanding for how best to present them. Remsense ‥ 论 00:58, 22 September 2024 (UTC)

Wait... you're objecting to your own proposal as WP:MOSCREEP? EEng 01:24, 22 September 2024 (UTC)

No, sorry: I was objecting to Schreiber's concern of MOSCREEP. Remsense ‥ 论 01:27, 22 September 2024 (UTC)

So you meant to say something more like "I object to the characterization of this as MOSCREEP"? Under that assumption, I disagree (with you), until (per MOSCREEP, which -- ahem -- I wrote) there's evidence that this issue has been a problem on multiple pages. Is there? EEng 01:44, 22 September 2024 (UTC)

You are correct. There's definitely classes of articles where this is a problem; I'll see what I can do. Remsense ‥ 论 01:46, 22 September 2024 (UTC)

Like the cat who ate some cheese then stood outside a mouse hole, I wait with baited breath. EEng 02:47, 22 September 2024 (UTC)

Recent edits

A string of edits by Jc3s5h and JMF. introducing and removing changes to Wikipedia:Manual of Style/Dates and numbers § Common mathematical symbols, raise issues that I believe should be discussed.

1. The most recent change, permalink/1247903136, has the comment This page does not cover matrix operations., however, I do not see anything in the article to support a restriction to numerical operations.
2. The most recent change reinstates the link to dot product, despite the comment.
3. There seems to be disagreement on the division sign.

The questions that I wish to raise are

1. Should that section mention {{tmath}} or <math>...</math>?
2. Are vector operations within the scope of the article? Regardless of the answer, the dot and cross products should be treated consistently.
3. Should there be two new rows for dot and cross product?
4. Should there be a row for tensor product?
5. Is obelus unhelpful since it has three forms?
6. Should the Division sign (U+00F7 ÷ DIVISION SIGN) be deprecated in favor of Slash (U+002F / SOLIDUS)?
7. Should U+2215 ∕ DIVISION SLASH be explicitly deprecated in favor of Slash?
8. Should the use of "x" and "*" as multiplication signs be explicitly deprecated in favor of U+00D7 × MULTIPLICATION SIGN?
9. Should that section show the LaTeX markup for characters in addition to the HTML character entity references?

-- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:52, 27 September 2024 (UTC)

1. I think the page should be devoted to general articles, and <math> should be reserved for advanced math and science articles.
2. Vector operations are not currently in the scope of the project page, and I'm not thrilled about adding them.
3. Dot product and cross product should certainly not be addressed in the same row as any scalar operation. The multiplication dot should certainly not be linked to the "Dot product" article nor should the multiplication cross be linked to the "Cross product" article.
4. Tensor products should not be covered in this project page because they're too advanced.
7. I'm not willing to spend 5 or minutes figuring out what this line means.
8. The asterisk as a multiplication sign should be limited to articles about computer languages that use it as such.
9. LATEX should not be mentioned, since we don't use it in Wikipedia. This isn't a style manual for writing outside of Wikipedia.

Jc3s5h (talk) 19:45, 27 September 2024 (UTC)

Tbh, I wondered what this extensive list is doing in the MOS in the first place. Glossary of mathematical symbols does it better. It really needs to be reduced to cover only those symbols that have a styling issue: scalar division and multiplication.

• The grade-school division sign should be formally deprecated, for reasons explained at division sign.
• The 'ordinary' slash (002F) should be preferred over 2215, same logic as straight quotes and curly quotes.
• I prefer U+00D7 × MULTIPLICATION SIGN over x, for biology as well as math but maybe that needs debate.

𝕁𝕄𝔽 (talk) 20:04, 27 September 2024 (UTC)

Comments:

• I see no good reason to prohibit using a division sign to express division. That seems absolutely fine. The division sign article seems to say it might be confusing in Italian, Russian, Polish, Danish, Norwegian, or Swedish, but this is the English Wikipedia. We use points as decimal separators also, and we use commas as a thousands separator too, although that might be confusing in other languages.
• I also see no good reason to prohibit using an asterisk for multiplication; it seems well-understood, easy to type, unambiguous, and common in practice. I agree with not using "x" for multiplication, although I think it's OK to express "by" relationships for 2x4 lumber, 4x8 sheets of plywood, and 4x4 trucks.
• <math>x</math> (i.e., $x$) looks different from ''x'' (i.e., x), and those look different from {{math|''x''}} (i.e., x), at least on my screen, and seeing mixtures of those in the same article can be a bit annoying (especially if they are near each other).

—⁠ ⁠BarrelProof (talk) 21:46, 7 October 2024 (UTC)

Asterisk means convolution (which is somewhat related to the idea of "multiplication" but should not be confused with the usual multiplication). Its use as a substitution for "×" or "⋅" is a bad habit from the old days of poor technology (but it was never used as such in professional typesetting) and has no excuse nowadays. — Mikhail Ryazanov (talk) 22:12, 7 October 2024 (UTC)

Convolution would only be a matter to consider in very mathematically sophisticated specialized contexts. It's not something most people have ever encountered. Even for those who use it, it would often be expressed using summation or integration instead. —⁠ ⁠BarrelProof (talk) 22:21, 7 October 2024 (UTC)

I don't think that this is a good reason to make exceptions to tolerate/promote sloppy typography (moreover, in some computer fonts the ASCII asterisk looks more like a superscript than a binary operator consistent with +, −, = and so on).

I don't think we should feel responsible for how Wikipedia is rendered in all possible fonts. We should remember that everyone is supposed to be able to edit Wikipedia articles. In an article that isn't about mathematics, or at least isn't using it beyond the 10th grade level, f = 1.8 * c + 32 seems basically OK to describe conversion from degrees C to degrees F. It's tricky enough that we tell people to pay attention to the difference between "-", "–", "—", and "−", and to not use italics for the numbers in that formula, although I support those instructions. —⁠ ⁠BarrelProof (talk) 03:37, 8 October 2024 (UTC)

Nobody should complain about otherwise good edits that include "lazy" typography. Those edits are 100% OK and a net improvement to Wikipedia. Other editors who care about typography and MoS can clean up the markup and character choices later. Wikipedia is a collaborative project. Indefatigable (talk) 15:46, 8 October 2024 (UTC)

Using an asterisk to represent multiplication is programming language syntax; I don't think this is common or even well-known among non-programmers. isaacl (talk) 01:47, 20 October 2024 (UTC)

I agree we should discourage use of "*" as a multiplication symbol. I agree it's easy to type, so if one editor writes "y = m*x + c" in an otherwise correct edit, the response should not be to revert that edit, but to replace it with "y = mx + c" or other approved alternative. Dondervogel 2 (talk) 10:40, 20 October 2024 (UTC)

Using an asterisk for multiplication is absolutely known to non-programmers because that's what is used on the number pad on most keyboards in the US. --User:Khajidha (talk) (contributions) 14:28, 12 November 2024 (UTC)

Ah, but which came first - the * key, or its use in mathematical expressions? Forty-some years ago, I was taught that in computer code, the * character was chosen to avoid confusion with the letter x, since the × did not exist in either of the character sets that were in use at the time - ASCII and EBCDIC. It's the same with / vs. ÷ and indeed - vs. −. --Redrose64 🌹 (talk) 18:15, 12 November 2024 (UTC)

* appeared on many (but not all) early typewriters. When not present it was often replaced by a fraction key (1/2, 1/4, etc) Practically every computer terminal from the 1970s onward has a * key - but that's probably due to it being used by Fortran (1957). Early teletype keyboards typically used Baudot code encoding and did not have * - but these were more for telecommunications rather than programming. Fortran was invented at IBM and used punch cards/tape using IBM's BCDIC. The early variations of BCDIC had *, - and / but not +. + was added soon after. My take is that BCDIC tried to encode whatever was commonly used on typewriters - subject to the limitation of using only 64 characters. Fortran then assigned functionality to whatever was in that set. * looked the most like x without being a letter, so it got the job.  Stepho  talk  23:56, 12 November 2024 (UTC)

It would really behoove participants here, instead of just speculating from the armchair, to take the radical step of doing some research to actually find out the answer. * has been used, in math, to mean multiplication for three hundred years. See the bottom of p. 66 of [1]. EEng 07:15, 13 November 2024 (UTC)

I didn't mention that paper, because I'm not in the habit of searching through 100-year-old academic journals. Now, 100-year-old magazines is a different matter, witness my stacks of boxes of The Railway Magazine back to 1902 (gaps between 1902 and 1939, complete from 1940 onward). --Redrose64 🌹 (talk) 12:02, 13 November 2024 (UTC)

FORTRAN was a decade earlier than ASCII and EBCDIC. What the first FORTRAN compiler used was the scientific BCD character set of the IBM 704, which replaced the older Percent (%) and Lozenge (U+2311 ⌑ SQUARE LOZENGE) with parentheses. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:35, 13 November 2024 (UTC)

Misleading shortcut

Wikipedia:Manual of Style/Dates and numbers#Common mathematical symbols indicates that its shortcut is "MOS:COMMONMATH", but in fact MOS:COMMONMATH links to Wikipedia:Manual of Style#Common mathematical symbols (a different section on a different page, although partially covering the same topic), which also indicates "MOS:COMMONMATH" as its shortcut. Perhaps one of them must be renamed. — Mikhail Ryazanov (talk) 00:47, 7 October 2024 (UTC)

@Mikhail Ryazanov: I have traced it to this edit nearly two years ago by SMcCandlish (talk · contribs), which I have reverted. The two redirects MOS:COMMONMATH and WP:COMMONMATH were created on the same day in January 2014 (although about twenty hours apart), the first by BarrelProof (talk · contribs) and the second by Wavelength (talk · contribs) following this discussion. It seems that they were intentionally different - and have remained so ever since. If one of them should be repurposed to match the other after ten years, we would need a WP:RFD. --Redrose64 🌹 (talk) 09:00, 7 October 2024 (UTC)

There must've been something that happened to instigate creation of those on the same day, but I have no recollection of it. —⁠ ⁠BarrelProof (talk) 09:17, 7 October 2024 (UTC)

You'd observed that there are two MOS sections on the symbols and suggested merging them, Wavelength responded that both locations are appropriate and we could have two shortcuts instead, and no-one else said anything. NebY (talk) 11:26, 7 October 2024 (UTC)

Thanks for the refresher. I think the two sections ought to at least mention each other in hatnotes, if not be merged. I just added the mentions. It is confusing that both of them are part of the MOS and both of them are sections of the MOS with the same heading: "Common mathematical symbols". Maybe they should become MOS:COMMONMATH1 and MOS:COMMONMATH2?? Is there some way to express the difference between the purposes of those two? I notice that one of those is part of Wikipedia:Manual of Style/Dates and numbers but says nothing at all about dates and numbers, so I suggest that it be merged into the other one. Mathematics is not synonymous with numbers. That section is about expressing operations and relationships and formatting variable names, not numbers. —⁠ ⁠BarrelProof (talk) 17:50, 7 October 2024 (UTC)

Better with hatnotes, yes. Though mathematics != numbers, MOSNUM seems the natural place where readers might look for guidance on the symbols; after all, the less mathematically sophisticated we are, the more likely we are to think of the operators as things we use with numbers. I'd expected that MOSNUM would be more detailed but there's extra content in MOS too, so that's not a useful distinction. The chatty one and the formal one? NebY (talk) 20:10, 7 October 2024 (UTC)

Usually having "MOS:FOO" and "WP:FOO" go to two different places is fine; the very reason we have the "MOS:FOO" pseudo-namespace for MoS shortcuts is that MoS pages were sucking up too many of the mnemonically meanful shortcut strings in which "WP:FOO" would for more editors bring to mind some non-MoS "WP:"-namespace material. Yes, use a disambiguation hatnote as needed; we have those for a reason. However, in this case, both targets are MoS sections, so both shortcuts should go to the same place, presumably the more detailed material. If the stuff at Wikipedia:Manual of Style#Common mathematical symbols is simply a nutshell summary of Wikipedia:Manual of Style/Dates and numbers#Common mathematical symbols (which is probably the case and should be the case) then the former needs no shortcut at all.  — SMcCandlish ☏ ¢ 😼  06:04, 8 October 2024 (UTC)

Discourage postfix plus?

(motivated by the previous section) If there's any work to be done with combining/rearranging MOS:COMMONMATH and WP:COMMONMATH, can we please also add that "over N" and "at least N" should use the standard notation >N and ≥N respectively (as, for example, the CMOS tells in 3.83 and 12.16) instead of a postfix plus (N+, which is ambiguous, inconsistent with other cases like <N and ~N, and doesn't seem to conform to any reputable style guide)? — Mikhail Ryazanov (talk) Mikhail Ryazanov (talk) 21:29, 7 October 2024 (UTC)

Has this issue come up a lot? EEng 22:12, 7 October 2024 (UTC)

A while ago I've got a revert with a suggestive edit summary (that particular article has changed a lot since then, but I still stumble upon similar examples from time to time – if needed, I can put some effort to find specific examples). Also, a simple search for insource:/[0-9]\+ / prefix:: yields thousands of results (before timing out), only a small fraction of which are legitimate uses (or poorly formatted binary operations). — Mikhail Ryazanov (talk) 22:54, 7 October 2024 (UTC)

Then the next question is: has time been wasted debating this question on multiple articles, or can they just be fixed on sight without fuss? If the latter, then no new MOS provision is needed, and therefore it is needful that there not be one. EEng 23:10, 7 October 2024 (UTC)

Numerals in a sequence

'Phase 1' or Phase one'? This appears to be a case that's not explicitly covered.

The AP Stylebook recommends using figures for sequences in its section on "Numbers": "Also use figures in all tabular matter, and in statistical and sequential forms", from which I infer that for sequences, such as 'phase 1', figures should be used for clarity and consistency.

Similarly, chapter 9 of The Chicago Manual of Style advises using figures when referring to a sequence.

I propose adding similar explicit advice to this section of the MOS.

-- Jmc (talk) 20:10, 19 October 2024 (UTC)

• As usual, what's needed before something's added to MOS is examples of this being an issue on multiple articles -- see WP:MOSBLOAT. Are editors not able to work this out for themselves on individual articles? Anyway, why does the word "Phase" need this in particular? Why not "Section" and "Part" and any other words like that?
  The advice from APA and CMS are great if you're making up a new sequence for your thesis, but that's not us. It's hard to imagine an article using a phrase like "Phase 1" or "Phase One" on its own -- that is, other than in imitation of the phrasing of sources. So follow the sources; for example, Economic Stabilization Act of 1970 refers to Phase I and Phase II and Phase III., because that's the form the Act uses. We're not going to override that in the name of consistency with other, unrelated articles. EEng 22:00, 19 October 2024 (UTC)

  To clarify: I'm using 'Phase' purely as an example. The issue of using figures for sequences applies to any sequence. including 'Section' and 'Part' - and other examples: "Game 3", of a sequence of nine; 'Chapter 9' of a sequence of 24; 'Week 4' of a limitless sequence.

  I raise this issue in the context of differing editorial practices in the British Post Office scandal article, where both figures and words have been used to reference the same phases and weeks of the inquiry. I sought guidance from the MOS and found none.

  I'd be content to follow the sources, without adding bloat to the MOS, if I could be confident that that's an accepted stylistic convention in this instance. -- Jmc (talk) 22:27, 19 October 2024 (UTC)

  Such names are very often established by authoritative sources and constitute proper names; we should follow the sources rather than renaming them. Per EEng, we only need a MOS guideline if our sources don't provide clear names and either there is dissent among editors or consistency across articles would be of significant benefit. In the Post Office case, I see the phases have been titled Phase 1, Phase 2 etc by the inquiry[2] so unless the inquiry's inconsistent, we can follow that source. Still, I see that this is a live issue at that British Post Office scandal article, so it would be wrong to establish a new guideline or issue some sort of MOS talk-page ruling without the knowledge of the other editor; pinging MapReader. NebY (talk) 14:56, 20 October 2024 (UTC)

  Between May 1966 and December 1989, multi-episode Doctor Who stories could have titles in any of the four combinations of (i) "Episode ..." or "Part ..."; (ii) numbers as figures or as words. The decision as to which format to use was probably in the hands of the series producer, but in our articles about each story, we give the actual title shown on screen - except that where the on-screen title is all-capitals, we reduce it to title case. Certain Doctor Who reference books do the same, so we're following the sources. --Redrose64 🌹 (talk) 18:18, 20 October 2024 (UTC)

  The question raised was "differing editorial practices in the British Post Office scandal article". Sounds like a matter of internal consistency, which is different. For all manner of things -- this being one IMO -- we might not need consistency among articles, but it does look bad within articles. Surely we already have a rule addressing that general issue tho? Herostratus (talk) 13:24, 21 October 2024 (UTC)

  I think we don't. In articles on TV series it's common to have expressions like "season 3" and "episode 7", which seem to go against our current wording (use words for numbers below 10). Gawaon (talk) 16:37, 21 October 2024 (UTC)

  It is indeed a matter of internal consistency and it does look bad, as Herostratus says. Within the one article (British Post Office scandal), we have (e.g.) both "Phase 3 hearings" and "Phases five and six". Is there in fact a rule addressing this general issue? -- Jmc (talk) 18:47, 21 October 2024 (UTC)

  From Wikipedia:Manual of Style/Dates and numbers#Numbers as figures or words: "Comparable values nearby one another should be all spelled out or all in figures, even if one of the numbers would normally be written differently." Unless you are dealing only with series with fewer than 10 seasons each with fewer than 10 episodes, it is more in line with MOS to give all season and episode numbers in digits rather than words. --User:Khajidha (talk) (contributions) 13:15, 22 October 2024 (UTC)

  True, but series with less than ten seasons aren't all that rare, and there are also miniseries with less than ten episodes. Gawaon (talk) 16:39, 22 October 2024 (UTC)

  Whether or not it's in line with MOSNUM, we frequently – I suspect in the vast majority of cases – give series/season and episode numbers in digits. I've been dipping into Wikipedia:Good articles/Media and drama#Television. Articles on individual episodes do routinely begin e.g. " the ninth and final episode of the first season" but with digits in the infobox. Articles on a season/series list episodes using digits, and articles on a show list series/seasons and episodes with digits, regardless of whether there are more or less than ten, in keeping with the examples in Wikipedia:Manual of Style/Television#Episode listing. Articles are often titled <show> season <n> where n is a digit, never a word, in accordance with Wikipedia:Naming conventions (television)#Season articles. Sampling our WP:Featured articles#Media, I see the same treatment in titles, infoboxes, and listings.

  I very much doubt that editors would accept changes to those FAs and GAs to bring them into line with MOS:NUMERAL, that FA and GA assessors will start to apply MOS:NUMERAL in such cases, that any move requests would succeed, or that MOS:TV and WP:TVSEASON will be brought into line with the current MOS:NUMERAL. Changing MOS:NUMERAL might be easier. NebY (talk) 08:20, 23 October 2024 (UTC)

  I agree, a small addition to MOS:NUMERAL might be a good thing. Gawaon (talk) 17:00, 23 October 2024 (UTC)

  Your final sentence doesn't follow from your statement. It would be more in keeping with the MOS to give all in words. MapReader (talk) 11:16, 23 October 2024 (UTC)

μs vs us

Which style I should use for micro seconds? Does μs relative to "Do not use precomposed unit symbol characters"? DungeonLords (talk) 04:44, 30 October 2024 (UTC)

The 2 characters "μ" and "s" are just fine. The precomposed symbols advice is to guard against particular fonts that combine them into a single character because many software readers for the sight impaired do not know all of these symbols.  Stepho  talk  04:53, 30 October 2024 (UTC)

Day, date month format

Greetings and felicitations. I assume that such constructions as "Wednesday, 24 February" are discouraged, but I can't find it in the text or the this page's archives. (The comma seems unnecessary to me.) May I please get confirmation or refutation? —DocWatson42 (talk) 04:28, 4 November 2024 (UTC)

• MOS:DATEFORMAT and MOS:BADDATE cover the allowed and disallowed formats. Unless the day of the week is vitally important then we leave it out.  Stepho  talk  06:16, 4 November 2024 (UTC)

  This specifically regards the "Hadaka Matsuri" article, and its Konomiya Hadaka Matsuri infobox, which includes the days of the week. —DocWatson42 (talk) 07:40, 4 November 2024 (UTC)

  Ah, the mysterious East. EEng 08:06, 4 November 2024 (UTC)

• Salutations and hugs and kisses to you too.
  • If your question is whether day-of-week should be gratuitously included with dates for no particular reason, the answer is No. That is, if the day-of-week is somehow relevant to the narrative, sure, include it, but otherwise no.
  • Assuming we're in some situation where (per the preceding) inclusion of day-of-week is indeed justified, maybe your question is how to append the D.O.W.
    • If the date is February 24 or February 24, 2024, then without doubt the right format is Wednesday, February 24 or Wednesday, February 24, 2024.
    • According to "Elite editing" [3] (whoever they may be -- search the text "inverted style" on that page), the corresponding answers for 24 February and 24 February 2024 are Wednesday, 24 February and Wednesday, 24 February 2024. To me that does seem right -- Wednesday 24 February 2024 (all run together, no commas at all) seems intolerable.

The question naturally arises as to whether MOS should offer advice on all the above. My answer, as usual, is provisionally No, per WP:MOSBLOAT. EEng 08:02, 4 November 2024 (UTC)

Looking at the article, the date is the 12th day of the Chinese year and the day of the week has no significance. I would remove the day of the week from all those dates in the infobox. For what it's worth, I spent most of the 1990s in Hong Kong/China. Major holidays based on the Chinese calendar treat the day of the week in the same way that we treat the day that Christmas falls on.  Stepho  talk  09:18, 4 November 2024 (UTC)

Okay—will do. Thank you both. ^_^ —DocWatson42 (talk) 09:21, 4 November 2024 (UTC)

The new 18th edition of The Chicago Manual of Style gives advice about commas in dates in ¶ 6.14. When giving examples they mostly give examples with words after the end of the date so the punctuation at the end of the date is illustrated. Some examples:

• The hearing was scheduled for 2:30 p.m. on Friday, August 9, 2024.
• Monday, May 5, was a holiday; Tuesday the 6th was not.

Jc3s5h (talk) 16:56, 4 November 2024 (UTC)

Spacing with percentage points

A question regarding spacing of percentage point (pp) usage. I have always assumed there is no space between the number and pp (e.g. 5.5pp not 5.5 pp), on the basis that you wouldn't put a space between a number and a percentage sign (5% not 5 %). There is no reference to this in the MOS, but the percentage point article uses it unspaced. It might be good to have it clarified in the MOS as I see regular changes adding spacing, which I am not sure is correct. Cheers, Number 57 23:49, 5 November 2024 (UTC)

• MOS:PERCENT says "omit space".  Stepho  talk  23:54, 5 November 2024 (UTC)

  Perhaps I am missing something, but as far as I can see, it says to omit space when using the percentage symbol (%) but nothing about when using pp? Number 57 00:21, 6 November 2024 (UTC)

  Apologies, I missed the "point" word in your question.  Stepho  talk  01:49, 6 November 2024 (UTC)

• % is essentially a constant factor (.01), but pp is more like a unit so my intuition says it should be spaced. I note that the basis point article uses a space before bp (mostly, anyway). I'll be interested to hear what others think. EEng 18:23, 6 November 2024 (UTC)

  You've got this back to front. Percent (%) is a standard unit symbol and should be spaced, whereas pp is a made up abbreviation, meaning you can put it anywhere you want, space or unspaced. I know MOSNUM says otherwise, which is WP's prerogative. In other words, if we need a rule, let's make one up and apply it, but there's no logic involved. Dondervogel 2 (talk) 21:06, 6 November 2024 (UTC)

• Dondervogel, "Percent (%) is a standard unit symbol and should be spaced". Huh? It's not an ISO unit symbol, is it. No spacing in English, unlike French. On pp, I agree with EEng: space it. Tony (talk) 11:10, 8 November 2024 (UTC)

  Absolutely. When it comes to peepee, always space it [4]. EEng 21:36, 8 November 2024 (UTC)

  Yes, "%" is an ISO standard unit symbol. Dondervogel 2 (talk) 12:45, 8 November 2024 (UTC)

  What is it the unit of? Gawaon (talk) 13:14, 8 November 2024 (UTC)

  Nothing. It's a dimensionless quantity. To the original q: I don't see "pp" used often, in fact rarely. It's probably better written out in full on first use, and if there are subsequent uses, follow the guidance at MOS:ACRO1STUSE. --Redrose64 🌹 (talk) 19:58, 8 November 2024 (UTC)

  It's used widely in election infoboxes where there isn't space to write it out. Number 57 22:25, 8 November 2024 (UTC)

  I will answer Gawaon's valid question in two parts. The first part is a quotation from ISO 80000-1:2009 (emphasis added)

  • In some cases, per cent, symbol %, where 1 % := 0,01, is used as a submultiple of the coherent unit one.
  • EXAMPLE 4
  • reflection factor, r = 83 % = 0,83
  • Also, per mil (or per mille), symbol ‰, where 1 ‰ := 0,001, is used as a submultiple of the coherent unit one.Since the units “per cent” and “per mil” are numbers, it is meaningless to speak about, for example, percentage by mass or percentage by volume. Additional information, such as % (m/m) or % (V/V) shall therefore not be attached to the unit symbol %. See also 7.2. The preferred way of expressing, for example, a mass fraction is “the mass fraction of B is w B = 0,78” or “the mass fraction of B is wB = 78 %”. Furthermore, the term “percentage” shall not be used in a quantity name, because it is misleading. If a mass fraction is 0,78 = 78 %, is the percentage then 78 or 78 % = 0,78? Instead, the unambiguous term “fraction” shall be used. Mass and volume fractions can also be expressed in units such as µg/g = 10-6 or ml/m3 = 10-9.

  Notice the deliberate space between numerical value (e.g., 83) and unit symbol (%). Dondervogel 2 (talk) 22:10, 8 November 2024 (UTC)

  The second part is a partial retraction, quoting from ISO 80000-1:2022, which supersedes the 2009 document:

  • If the quantity to be expressed is a sum or a difference of quantities, then either parentheses shall be used to combine the numerical values, placing the common unit symbol after the complete numerical value, or the expression shall be written as the sum or difference of expressions for the quantities.
  • EXAMPLE 1
  • l = 12 m - 7 m = (12 - 7) m = 5 m, not 12 - 7 m
  • U = 230 ⋅ (1 + 5 %) V = 230 ⋅ 1,05 V ≈ 242 V, not U = 230 V + 5 %

  The space is still there between numerical value (5) and percentage symbol (%), but I could not find an explicit reference to "%" as a unit symbol. I'm unsure how to interpret that change, but I'll report back here if I find further clarification. Dondervogel 2 (talk) 22:16, 8 November 2024 (UTC)

  I found this in NIST Special Publication 811

  • In keeping with Ref. [4: ISO 31-0], this Guide takes the position that it is acceptable to use the internationally recognized symbol % (percent) for the number 0.01 with the SI and thus to express the values of quantities of dimension one (see Sec. 7.14) with its aid. When it is used, a space is left between the symbol % and the number by which it is multiplied [4: ISO 31-0]. Further, in keeping with Sec. 7.6, the symbol % should be used, not the name "percent."
  • Example: xB = 0.0025 = 0.25 % but not: xB = 0.0025 = 0.25% or xB = 0.25 percent
  • Note: xB is the quantity symbol for amount-of-substance fraction of B (see Sec. 8.6.2).
  • Because the symbol % represents simply a number, it is not meaningful to attach information to it (see Sec. 7.4). One must therefore avoid using phrases such as "percentage by weight," "percentage by mass," "percentage by volume," or "percentage by amount of substance." Similarly, one must avoid writing, for example, "% (m/m)," "% (by weight)," "% (V/V)," "% (by volume)," or "% (mol/mol)." The preferred forms are "the mass fraction is 0.10," or "the mass fraction is 10 %," or "wB = 0.10," or "wB =10 %" (wB is the quantity symbol for mass fraction of B—see Sec. 8.6.10); "the volume fraction is 0.35," or "the volume fraction is 35 %," or " φB = 0.35," or "φB = 35 %" (φB is the quantity symbol for volume fraction of B—see Sec. 8.6.6); and "the amount-of-substance fraction is 0.15," or "the amount-of-substance fraction is 15 %," or "xB = 0.15," or "xB = 15 %." Mass fraction, volume fraction, and amount-of-substance fraction of B may also be expressed as in the following examples: wB = 3 g/kg; φB = 6.7 mL/L; xB = 185 mmol/mol. Such forms are highly recommended (see also Sec. 7.10.3).
  • In the same vein, because the symbol % represents simply the number 0.01, it is incorrect to write, for example, "where the resistances R1 and R2 differ by 0.05 %," or "where the resistance R1 exceeds the resistance R2 by 0.05 %." Instead, one should write, for example, "where R1 = R2 (1 + 0.05 %)," or define a quantity Δ via the relation Δ = (R1 - R2) / R2 and write "where Δ = 0.05 %." Alternatively, in certain cases,the word "fractional" or "relative" can be used. For example, it would be acceptable to write "the fractional increase in the resistance of the 10 kΩ reference standard in 2006 was 0.002 %."

  As with ISO 80000-1:2022, there is always a space between numerical value (e.g., 35) and the percentage symbol (%), but no mention of % as a unit symbol. Dondervogel 2 (talk) 22:38, 8 November 2024 (UTC)

  there is always a space between numerical value (e.g., 35) and the percentage symbol (%) – Maybe in NIST-world, but not here on Wikipedia (see MOS:PERCENT), so I don't see how any of that helps us with the issue at hand. EEng 23:29, 8 November 2024 (UTC)

  I was correcting a misconception that % is not a unit symbol when it is. At least it was until 2022. I find it best not to leave incorrect statements unchallenged or they take on a life of their own. Dondervogel 2 (talk) 00:24, 9 November 2024 (UTC)

  Um, OK, but you do realize that WP does not follow NIST's advice about spacing it, yes? EEng 00:44, 9 November 2024 (UTC)

  Yep, and I wasn't trying to change that. My contributions have been to

  • correct a factual error (yours)
  • respond to questions from Tony and Gawaon

  I have not weighed in on the main thread regarding percentage points because I don't expect my opinion (based not on NIST's utterings but on the ISO standards on which they are based) to be taken seriously, so why would I waste my e-breath? Dondervogel 2 (talk) 09:41, 9 November 2024 (UTC)

UNITSYMBOLS (1 × 3 × 6 m): “each number should be followed by a unit name or symbol”

MOS:UNITSYMBOLS currently requires a unit symbol after each value when listing dimensions separated by × (“1 m × 3 m × 6 m, not 1 × 3 × 6 m”). Could we have a carveout from this rule, and allow editors to use only a final unit when writing for infoboxes, and perhaps other places where space is limited?

Context: {{Infobox mobile phone}} currently has a preference for listing the dimensions of the product each on a separate line. This, and other parameters, can make the infobox very long. This is especially problematic for pages that cover multiple products or versions of a product; see dimensions in Samsung Galaxy S21 infobox. In order to cut down these infoboxes, we could be using a single line for all three dimensions, but the unit after each value feels unnecessary, and can cause line overflow.

Prior discussion: Wikipedia talk:Manual of Style/Dates and numbers/Archive 145#Repeating units in ranges and dimensions, where the potential for confusion with actually multiplying values was pointed out. I think this is a minor concern in general, but worth considering in prose, or in contexts where the values could be ambiguous. — HTGS (talk) 04:17, 11 November 2024 (UTC)

Where space is limited, it makes sense to present a single compound unit, equal to the product of the separate units. For the example given, the compound unit symbol would be m³. Dondervogel 2 (talk) 12:13, 11 November 2024 (UTC)

Who ever heard of a phone advertised as 5 cc ? People are more interested in it being wide and tall but very thin. This necessitates stating each individual dimension.  Stepho  talk  22:40, 11 November 2024 (UTC)

No, what Dvogel means is you'd write that a certain phone measures 146 x 71.5 x 7.65 mm³. Having clarified that, I'm bound to say that that would, of course, confuse 99% of our readers. EEng 22:47, 11 November 2024 (UTC)

Gotcha. As well as confusing most readers, it would also be different to 1 by 3 by 6 m, which is allowed.  Stepho  talk  23:30, 11 November 2024 (UTC)

To be clear for those playing along at home, while the canonical formuations are 1 m by 3 m by 6 m and 1 m x 3 m x 6 m, MOS currently makes an exception allowing 1 by 3 by 6 m (specifically in the case where all the quantities are in the same unit -- in this case metres), but no corresponding exception allowing 1 x 3 x 6 m. While it may offend purists, I really don't see why the exception shouldn't be extended to that last case as well. Thoughts? EEng 23:39, 11 November 2024 (UTC)

Thank you for clarifying my intent. And for making me chuckle. LoL

For a 3 dimensional object, one can write either 146 mm x 71.5 mm x 7.65 mm or 146 x 71.5 x 7.65 mm³. I agree the former is clearer, but the latter uses less space, which can be a consideration. There is no difference in meaning.

I guess one could also write 146 x 71.5 x 7.65 mm, but then we have a length, not a volume. It would be clearer to write that length as 79.86 m. Dondervogel 2 (talk) 23:42, 11 November 2024 (UTC)

one could also write 146 x 71.5 x 7.65 mm, but then we have a length, not a volume – Formally perhaps, but you could say the pretty much the same about 146 by 71.5 by 7.65 mm, and yet we allow it. No one will think that 146 x 71.5 x 7.65 mm means the length 79.86 m (i.e. 79860 mm). In context readers will understand it for what it is. I'd like to hear what others think about my proposal. EEng 23:56, 11 November 2024 (UTC)

Seconded EEng's proposal - simple and clear.  Mr.choppers | ✎  04:36, 14 November 2024 (UTC)

EEng is, of course, correct. At {{convert}} we sometimes are asked how the duplicate mm units can be removed to save space (the trick is to use xx in convert) and we tell them that omitting repeated units is ok if space is limited. May as well make it official. Johnuniq (talk) 05:51, 14 November 2024 (UTC)

EEng is, of course, correct. – Of course -- even Dondervogel says so. EEng 06:37, 14 November 2024 (UTC)

I also support the proposal.  Stepho  talk  05:53, 14 November 2024 (UTC)

• It's tiresome to have to write (and read) units multiple times when multiplication signs are used. Tony (talk) 09:47, 14 November 2024 (UTC)

Do we have to convert inches for wheels?

I see people adding conversions to mentions of screen sizes and wheel dimensions - is this really necessary? Even in Germany or New Zealand, automobile and bike wheels are universally referred to by inches; rim diameters are expressly defined in inches in the EU regulations. To me, adding conversions for these types of dimensions adds unnecessary clutter, harming readability for no return whatsoever. I haven't read the entire MOS today, apologies if I missed a mention of these situations.  Mr.choppers | ✎  17:24, 13 November 2024 (UTC)

It looks like sizing bike wheels in inches is not universal. I see many charts in the I-net such as this that use both metric and imperial/American units for bike wheels and tires. Whether the convert template handles them correctly is another issue. Donald Albury 17:43, 13 November 2024 (UTC)

On the matter of wheel sizes, not all are inches. See this post and my reply. Even for a conventional non-Denovo wheel, the dimensions are a bastard mixture: "195/65 R 15" means a tyre that is 195 mm wide on a 15-inch rim. --Redrose64 🌹 (talk) 19:10, 13 November 2024 (UTC)

Yes, there is the Michelin TRX and the Denovo. Just as we wouldn't convert the "195" when we write 195/60 R15, I don't think we ought to convert the diameter either. I would treat all of these tire dimensions as one would nominal measurements, rather than inserting unnecessary templates. Bicycle tires, meanwhile, proved more varied than I was aware of.  Mr.choppers | ✎  04:33, 14 November 2024 (UTC)