This is an archive of past discussions about Wikipedia:Manual of Style. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Missing point in "Numbers as figures or words" section
Something "obvious" that I'm pretty sure we used to have is missing from WP:Manual of Style/Dates and numbers#Numbers as figures or words: use figures before a unit. I.e., we do not want to see "seven kg" but "7 kg" (except "Seven ..." at the beginning of a sentence, if moving "7 kg" to elsewhere in the sentence doesn't work well for some reason). It seems very strange to me that this bit of very basic and central advice, which experienced editors all seem to be following, has somehow gone missing. The chart at WP:Manual of Style/Dates and numbers#General guidelines on unit names and symbols illustrates the figure style pretty consistently, while permitting some examples of spelled-out number words (presumably for sentence-initial cases).
At least one thread on this page (namely, part of the discussion at #Number ranges more generally) indicates some confusion about this, an inference that MoS is somehow expecting/demanding "five to seven kg", due to lack of an exception for measurements, so this probably should be resolved. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 22:53, 20 November 2017 (UTC)
Well, the table says Do not spell out numbers before unit symbols ... but words or figures may be used with unit names. There's a kind of division of labor under which Numbers as figures or words deals mostly with unitless stuff + non-scientific stuff like money and minutes/hours, and Unit names and symbols deals with hardcore units. I'm always torn about whether to duplicate advice like numbers-as-figures-or-words in two places. EEng02:28, 21 November 2017 (UTC)
I've learned the hard way that it's best to do so, concisely and with a pointer to the more detailed section. People do not read MoS as a document from start to finish, but by shortcuts to sections to answer a specific question. If they don't find it where they think they should find it, they tend to just make an assumption (often incorrect) and stop looking. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 04:15, 21 November 2017 (UTC)
Meant to bring this up a long time ago, but forgot. The logic and resultant rule we're applying to date ranges – to give them in the form 2002–2011 not 2002–11 – applies to all numeric ranges (outside of directly quoted material) and we need to state that explicitly. I keep running into sporadic WP:WIKILAWYERing along lines which can be parodied as "I can use 'p. 2002–11' if I wanna because MOS:NUM#Ranges only technically applies to dates, and no matter how much WP:COMMONSENSE dictates that that the reasoning applies across the board, the rules don't quite say it, so ha ha ha." Let's just fix it. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 06:18, 3 October 2017 (UTC)
It seems to me that the preference for a single piece of guidance in Wikipedia:Village pump (policy)/Archive 129 #WP:DATERANGE ambiguity and stylistic concerns RfC debate would apply equally to the choice between full number ranges and abbreviated ones, in particular phrases like "pages 153–158" vs "pages 153–58" or "pages 153–8". It would be a step forward, I think, to encourage one style and deprecate the others. Reading the RfC, I believe that there is likely consensus for a new sub-section in Wikipedia:Manual of Style/Dates and numbers #Numbers titled "Number ranges" with guidance along the lines of "Number ranges, including page ranges, when given as ordinals, should state the full number both for the beginning and end of the range." I expect that the usual exceptions like "In tables and infoboxes where space is limited ..." and when quoting a source directly would need to be mentioned, along with a few examples.
You will either need to start a new RfC, or try a bold edit to this page and see if it sticks. Or perhaps there will be lots more debate here, whence we can determine consensus. Cheers --RexxS (talk) 18:56, 9 October 2017 (UTC)
Took the bold approach [1], since all the reasoning in the RfC applies to other date ranges. We can of course RfC it again if necessary. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 23:35, 10 October 2017 (UTC)
The problem I see is that for every case of "43241–8" (which is honestly hard to be certain is intended to be a range rather than some kind of obscure serial number or something, so yes I do think "43241–43248" is preferable) there's going to be about 1000 cases of "125–9" or "1901–05". The last kind of case is seriously problematic since it looks like a Y-M date; many fonts do not distinguish clearly between - and –, and many readers are not clear on the distinction even if they can see it. Maybe a caveat can be added that if the range begins with a number higher than 2100 the short form can be used. That should avoid any potential confusion with dates up to the near future. PS: We can't do something like "If it could be confused for a date, use the long form" because some of this data is auto-generated by templates and bots and such. We can't depend on every number range to be human edited. That'll be even more true the more WikiData stuff is implemented here. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 03:38, 11 October 2017 (UTC)
CMoS has a complicated four-tiered system for compressing ranges, geared to avoiding ambiguities (they say, though I don't see that it deals with date-confusion), and based on how large the starting number is. I strongly suspect their system is too fiddly for WP to accept (plus it's a manual thing, and can't reliably be done in an automated way). The CMoS system, and any others for compression, are concerned with paper publications where space-saving is a concern. CMoS also recognizes the don't-compress rule we implemented for dates, and the compress-maximally ("2934–8") approach some want to use here. Maybe more importantly, it expects citations in a consistent format with a particular order of authors, dates, pages, etc., and a more limited number of such parameters, where we have utter chaos. The potential for confusing dates and other things is much higher on WP, especially since people are empowered by WP:CITEVAR to invent their own citation "styles" (according to CITEVAR's regulars, anyway), and our templated citations have parameters for just about every kind of source ID there is, many of which are numeric. PS: Anyone should feel free to revert the WP:BOLD addition of the "Number ranges" section, of course. If it needs more discussion and perhaps more exemptions or whatever, we can work that out. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 17:01, 11 October 2017 (UTC)
On a related issue, Mac. Why is it that a range of general numbers e.g. 10–15 is OK to be written this way, but 1–9 should be spelled out as "one to nine"? At appears to be inconsistent to me. William Harris •(talk) •09:45, 20 November 2017 (UTC)
Surely it all depends on context? Citing "pages 1–9" seems perfectly reasonable to me, as does "the boat could carry one to nine additional guns". Who would write those differently? I think the problem is in expecting us to be able to write prescriptive rules to cover every possible circumstance. The English language simply isn't that amenable to regulation. --RexxS (talk) 14:13, 20 November 2017 (UTC)
Right. In running prose, we'd normally write "one to nine" because we normally write "one" and "nine". But we wouldn't do that to things conventionally given in numerals, like page numbers, addresses, sports scores, vote tallies, measurements, etc. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 19:34, 20 November 2017 (UTC)
Many thanks for both of your replies. It was measurements that I had in mind as I contribute largely to biology-related subjects. I certainly would write 5-7 kg, or 2–7 km, but that is not what the guide advises. It would look strange stating that "the smaller subspecies weighs from five to seven kilograms and the larger subspecies 10-14kg." Following from your earlier lead, Mac, I have been WP:BOLD on the article page. William Harris •(talk) •20:02, 20 November 2017 (UTC)
@William Harris: Where do you think the wording needs clarification? I'm not sure where your "not what the guide advises" is coming from. MOS:NUM#Number ranges doesn't suggest anything like "five to seven kg" [or "... kilograms" or "... kilogrammes"], and only illustrates ranges with figures. If anything, we might need to clarify that one should write "five to seven survey respondents out of ten", when the numbers are not something we normally always put in figures (scores, votes, measurements before units, etc.), since the section doesn't actually illustrate this usage. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 22:45, 20 November 2017 (UTC)
I'm planning to change convert to use sdot (instead of middot) and mu (instead of micro). Using sdot contradicts the first WP:MOSNUM link above. Thoughts? Johnuniq (talk) 00:50, 18 November 2017 (UTC)
The mid-dot in unit combinations, is clearly a multiplication symbol and should use the same symbol as any other mathematical multiplication (I don't care which of the two dots is adopted, but it shold be the same dot for both).
The μ in μm is a Greek lower case mu - no other character should be used for this purpose IMO.
Wrt the dot, the two MOSes are contradicting and one should be changed (it follows, WP:MOSNUM should be changed). I note that per SI, the unit is an algebraic formula (allowing calculations), so in m·s (for metre-second) it is the multiplication symbol.
Wrt the micro/mu: as an SI-prefix it is a letter, not a math operator symbol, so the Greek letter is the obvious one. The confusion arose when Unicode created two characters for this one letter. (But maybe outside of SI-prefix, the "micro" does have a meaning?) -DePiep (talk) 12:36, 18 November 2017 (UTC)
Support updating WP:MOSNUM to suggest to sdot, and to use mu and sdot in templates for units. I imagine that WP:MOSNUM may have been written without considering the alternative to middot. —Quondum23:54, 19 November 2017 (UTC)
Support updating WP:MOSNUM to use sdot for compound units, and to use mu and sdot in templates for units. I am used to the sdot (dot operator) indicating a product, but of course that might be old-fashioned! It wouldn't hurt to settle on Johnuniq's suggested scheme, and would only require bringing MOSNUM into line – I'm fairly certain readers won't be confused by seeing compound units like m⋅s and kW⋅h, as opposed to m·s and kW·h. Slightly tangentially, quantities like torque are vector products, rather than scalar products like work, but nobody is going to complain about us using N⋅m (I hope). --RexxS (talk) 20:35, 20 November 2017 (UTC)
The others are just approximations, and the names of these two unmistakably indicate they are the correct characters for these purposes. The other dot is a typesetting character, not a maths operator, and the mu is a Greek letter not a technical symbol (though the latter is obviously derived from the former). It's irritating that Unicode actually does this stuff with characters that are visually identical, but it does, and we're stuck with it. PS: I don't agree that "as an SI-prefix it is a letter, not a math operator symbol". "Micro sign" != "math operator". It's simply a symbol, and the correct one to use here, because μm is not Greek (i.e., we would not put it or the full version, micrometer/micrometre, inside {{lang|el|...}}). This is science and other fields repurposing what originated as a Greek letter, for symbolic purposes unrelated to rendering Greek text. Saying we should use the Greek letter μ is tantamount to saying we should not use the ™ symbol, but instead use <sup style="font-variant: small-caps;">TM</sup>. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 21:43, 20 November 2017 (UTC)
Now that you mention it I do recall the special micro sign, distinct from mu. So yes we should use that. EEng22:13, 20 November 2017 (UTC)
Skimming that, I don't find it compelling. I too was involved in Unicode mailing lists back when, and many decisions where typical, arbitrary (in the negative sense) "design by committee" gaffes, while many were not and were pointedly about separating symbols from natural-language characters that look like them. One person's anecdote about what they remember about what they thought might have been the intent back when, well, it just isn't very meaningful. What other people are using in their house style isn't very informative here, either, especially when the characters are essentially identical. (This is a bit like the dash-versus-hyphen-versus-minus and x-versus-×-in-math disputations; it really doesn't matter one whit that the average publisher just uses "-" and "x"; we use "−" and "×" in a maths context because they're the functionally correct characters to use, even if the average person neither notices nor cares.) There's a Unicode character specifically for micro- reduced to a symbol, it has not been deprecated, we have no indication it will ever be deprecated (any more than will IPA symbols that also coincide visually with natural-language ones in various writing systems), and it has no connection to rendering of Greek-language text, so we should obviously use the dedicated micro- symbol, as intended, when we mean micro- not mu in Greek-script quoted material. The fact that various off-WP writers have preferred the Greek letter is almost certainly because character-picker tools like Windows Character Map and PopChar (Mac OS) make it easier to find the Greek letter, in a code block for Greek right after the Latin alphabet, than to find the micro- symbol, mingled in confusingly with various other symbols. You have to know where (in your preferred tool) to look for it. That's a good reason to spell out what character it is and how to insert it as a decimal or hex HTML character entity, and to have templates auto-emit it. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 23:15, 20 November 2017 (UTC)
See my comment at the other thread. Micro is a compatibility decomposable character. It "would not have been encoded in the Unicode Standard except for compatibility and round-trip convertibility with other standards" (section 2.3) Kendall-K1 (talk) 00:29, 21 November 2017 (UTC)
But it has been, and it's there, so we should use it instead of misapplying a glyph from the Greek-language character subset for non-Greek purposes. I would love it if Unicode eliminated all duplicate and near-duplicate glyphs (especially since various characters that should be in 8-bit Unicode (UTF-8) are not due to lack of namespace room) but it's never going to happen. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 04:19, 21 November 2017 (UTC)
The Greek letter mu has been designated per SI to be the symbol for SI-prefix micro-. Once and where declared a symbol, it is not the "Greek language" any more (Greek script it is, but language =/= script). It is not up to Unicode to overrule that SI definition. Anecdotal background is not an argument, nor is Skimming that [micro/mu discussion], I don't find it compelling a strong argument. I point to the Kendall-K1 quote above @00:29: that the micro sign is a compatibility decomposable character, per a major Unicode policy. That is: added to provide compatability with legacy code systems (think old ASCII with limited number of code points so only selected non-Latin characters were imported into Latin set). Also, nowhere does Unicode claim or even suggest the micro sign should replace the letter mu anywhere. Also no need to go to the "confusion" area of the web, of Unicode, or of anyone's understanding. Both Unicode and SI are perfectly clear in this, and the web can handle this clarity.
And no, the micro/mu issue is not the same as the sdot/middot issue (as stated below), because the dot is a math operator, and the mu-prefix symbol is not. Math operators have different semantics from other dots, the prefix symbol has not: it is still the Greek letter. -DePiep (talk) 09:11, 21 November 2017 (UTC)
This is turning completely circular, and I decline to reiterate my position just because you're reiterating yours. We've both made our case. I don't want this to turn into one of those "SI mebi- and gibi- prefixes" types of near-interminable disputes. There are arguments in both directions, and consensus will settle on one or the other, probably not on the basis of technical assertions about which is more "correct" according to SI, or, well, the SI prefixes debate would not have dragged out for so long and would not have concluded the way it did. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 09:39, 21 November 2017 (UTC)
"Meh" isn't a denigration of anyone or anything; it's an expression of (usually growing) indifference and a feeling of tedium [3][4]. The arguments you added don't appear to be new, but recycling of those made in the earlier discussions already linked to. I don't think I have anything new to say about them, and I doubt anything new is forth coming in support of them, so I don't see the point. We have both made our case, and others can give their input. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 19:09, 21 November 2017 (UTC)
re SMcCandlish Both your "glancing" and your "meh" remarks are dismissive wrt the discussion proces and their contributors (see WP:IDIDNOTHEARTHAT). I note that I made several replies in my response to your posts. List of Newies, short: "not Greek language", "language =/= script", "different semantics", "Unicode policy", "Unicode does not claim ...", "compatability", .... None a repetition, also because this was my first reply to you. -DePiep (talk) 15:14, 22 November 2017 (UTC)
I'm not declining to hear anything, just to continue arguing about it. I've already indicated I WP:DGAF about the outcome of this. I've presented an argument for using the Unicode symbol that's intended specifically as a symbol for the kind of purpose at issue here, and you've presented a case to use the Greek letter, based primarily on some regret within the Unicode Consortium for having done things this way in the first place. I'll be okay with whatever consensus emerges on the matter. Neither view is crazy; one just favors using the tool as-is, the other favors using the tool as its creators have reimagined it (without them actually changing the Unicode spec itself; if they actually marked U+00B5 deprecated, I would take your side in this). — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 19:12, 22 November 2017 (UTC)
mu. The use of mu as a metric symbol predates SI, let alone Unicode - for example, the 1911 Kaye and Laby uses it. SI is independent of Unicode and does not define symbols in terms of Unicode; it defines the micro- symbol as mu, not as any particular Unicode character. 92.19.24.9 (talk) 23:21, 20 November 2017 (UTC)
We know. WP works in Unicode like the rest of the Web. Where Unicode provides two glyphs for the same thing (the character specified by SI), one a technical symbol, and one specifically for Greek text, we use the the former for the former purpose, we don't misuse the latter for it, or misuse the former for Greek material. Again, this is exactly the same issue as hyphen, dash, and minus characters, or x versus ×. It does not matter that some other publishers chose to use - for minus and x for multiplication because they don't care about Unicode distinctions; WP is not among those publishers. Another example is duplicate-looking glyphs in Greek and Latin, and in Greek, Cyrillic, etc. We don't use the Greek ones in Cyrillic or the Latin ones in Greek just because we feel like it or they're easier to type, or any other reason. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 00:26, 21 November 2017 (UTC)
SMcCandlish – I see nothing in your argument other than that the micro should be used because it exists as a separate character with no other semantics (whereas mu also has this meaning). That they look the same is no accident: the one was supported by an early ad hoc extension to the ASCII character set without Greek characters predating Unicode; it is arguably the same character with an archaic encoding, and is evidently what led to your lament: that it looks the same. It is also clear that it is a legacy encoding that is effectively deprecated by Unicode (see quote by Kendall-K1). I have checked several SI standards PDF documents and web pages such as at NIST, they uniformly use mu, not micro. Unlike the argument for retaining the archaic inch in the US, adopting the Greek mu in this MoS would have no expected transition impact. —Quondum13:47, 21 November 2017 (UTC)
"should be used because it exists as a separate character with no other semantics" is exactly the reason we use the proper character for minus, for multiplication, and for many other things. I don't see a solid rationale for diverging from that pattern. The fact that some people (including some at Unicode) want[ed] to deprecate the one character in favor of the other is immaterial; it has not been deprecated. By way of analogy, many at W3C and WHATWG wanted to deprecate (for what they thought were good reasons) the non-semantic font-styling HTML elements like <b>, <i>, <u>, and <s> in HTML5 (in favor of using styled spans for these things when they do not have a semantic value conveyed, respectively, by <strong>, <em>, <ins>, and <del>) but this did not end up happening, so these elements are in fact still in use and legitimate to use. (They did deprecate <tt>, in favor of <code> and the related semantic tags, so <tt> should not be used here or elsewhere, even if browsers are generally not going to choke on it). "I wish this were deprecated" isn't good enough for me, especially when it runs into "use of micro- and the symbol for it in English has F'-all to do with rendering Greek-language material". I can't think of anything else to add that won't simply be rehash of what I already said. Bazillions of things are among those that some people want to deprecate and which do not actually get deprecated; life goes on. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 19:09, 21 November 2017 (UTC)
SMcC, saying "we don't misuse" at best begs the question of whether it is misuse. Use of Greek letters is not only appropriate, it's prescribed. It's worth remembering that the U+00B5 coding is a bodge that predates Unicode; you'll find it in the 256-character set of the original IBM PC (later known as Code page 437) as one of the 14 upper- and lower-case Greek characters that were squeezed in to support various mathematical, scientific and technical uses. Unicode supported that bodge, of course, but it also supports the full Greek alphabet so there is no longer any need to use U+00B5. As Unicode Technical Report #25 puts it, "Implementations therefore need to be able to recognize the micro sign, even though U+03BC μ is the preferred character in a Unicode context."[1]92.19.24.9 (talk) 21:34, 21 November 2017 (UTC)
Just in case my own position was not clear (shifting my position from neutral to use of sdot on the mid-dot question; unchanged on μ):
I support use of the multiplication symbol for all multiplication operations, including multiplication of units (seems self-evident)
I support use of the Greek letter mu for the μ in μm because μm is an SI symbol, and the SI symbol for μm uses a Greek letter mu (again, this seems self-evident to me, but I see that others are arguing the opposite - hence the need to reiterate the logic).
This comment is a very incomplete substitute for a methodical summary of points raised which I don't have time for. The dot issue has been resolved and convert will use sdot. The micro/mu issue is a problem with many supporting mu based on reasons that seem convincing. The pushback supporting micro is strong but seems to be based on a belief that micro's existence is proof of its correctness. Countering that is the claim that micro exists only for certain technical reasons (see "compatibility and round-trip convertibility" above). What evidence is there to support micro? I was once a strong supporter of micro as can be seen at User talk:128.178.189.30 but my faith started wavering due to DVdm's comments there. I still support one thing I said, namely Unicode is a black hole from which useful information rarely escapes. Johnuniq (talk) 22:19, 21 November 2017 (UTC)
The quote I gave in the other thread seems pretty conclusive to me: "The purpose for the inclusion of compatibility characters like these is not to implement or emulate alternative text models, nor to encourage the use of plain text distinctions in characters which would otherwise be better represented by higher-level protocols or other mechanisms. Rather, the main function of compatibility characters is to simplify interoperability of Unicode-based systems with other data sources, and to ensure convertibiliity of data." In other words, it's not considered a separate character. It's more like the difference between the character "é" and the character "e" combined with a separate COMBINING ACUTE ACCENT. Kendall-K1 (talk) 23:02, 21 November 2017 (UTC)
My guess about the idea of "compatibility characters" is that some once commonly used 8-bit character sets define hex B5 as μ (mu). For example, see ISO/IEC 8859-1 (Latin alphabet No. 1). That presumably makes it more likely that Unicode U+00B5 (micro) would be displayed with a micro sign for the B5 on a system that did not use Unicode. Thanks Kendall-K1, that makes a convincing case that micro was for compatibility but mu is the preferred symbol. Convert moves slowly but it will be switched to use sdot and mu in due course. Thanks all! Johnuniq (talk) 23:51, 22 November 2017 (UTC)
Is it possible to add Jewish dates in templates (for example {{cite news|date="7 Tishrei, 5775 // October 1, 2014"}})? --Jonund (talk) 19:19, 6 November 2017 (UTC)
Not in {{cite news}} and other Citation Style 1 templates. Dates are checked for validity. Only Gregorian calendar months are supported, and years are limited to the current year + 1 (e.g. in 2017, years up to 2018 are supported). – Jonesey95 (talk) 14:43, 29 November 2017 (UTC)
MOS:NUMERAL
I was wondering why this says "Integers from zero to nine are spelled out in words", when "ten" is clearly more readable than "10". I would have thought changing "nine" for "ten" in the MOS would make sense? MapReader (talk) 10:05, 3 December 2017 (UTC)
Far from arbitrary - there are no more single digit numbers available to use higher than "9". At higher bases we're forced to invoke letters, so "0-9" is a pretty bright (and immovable) line. ~Tom.Reding (talk ⋅dgaf)14:32, 3 December 2017 (UTC)
Well, since this is a MOS discussion, we need to keep courteously correcting one another until one of us drops dead from exhaustion. It really is arbitrary. For example, apparently AP says up to 9/nine should be in words, but Chicago says up to one hundred/100 – not ninety-nine/99 – unless (Chicago says) you feel like using the 9/nine rule. This is may be the purest example of point A2(b) at User:EEng#mossy. EEng14:50, 3 December 2017 (UTC)
Personally I think that any number that can be expressed with a single word (rather than a two-word combination) is more readable as a word than in figures, except in special circumstances like lists and tables. So this would put the dividing line at "twenty" - which is actually a pretty good place for it. Or, if you argue that words like fourteen are effectively four-teen, you could put the upper limit at "twelve". Either of these would be more logical and sensible than "nine", since the additional figure when you increment to "10" decreases readability, and the reduction of one letter from "nine" to "ten" increases it - so "ten" very clearly has a greater readability premium over "10" than "nine" does over "9". MapReader (talk) 19:34, 3 December 2017 (UTC) MapReader (talk) 19:34, 3 December 2017 (UTC)
MOS Seasons
I note that no protocol is listed for the use of the terms fall and autumn - perhaps it's worth pointing out which countries use each term? (AFAIK, fall is used in all Western Hemisphere English-speaking countries, and autumn elsewhere, but I'd prefer some confirmation from Canadian, Jamaican, etc. editors) Grutness...wha?08:24, 26 November 2017 (UTC)
You might have heard of that little island off the coast of Europe where the language first developed. Fall is considered dated, archaic or dialectal here, though it was in common use from 1550 to the end of the seventeenth century, when autumn took over as the usual term for this season. (Perhaps, by Western Hemisphere, you meant that big lump of newly-discovered land to the west of the Atlantic? ) Dbfirs08:45, 26 November 2017 (UTC)
Pretty much most of the Commonwealth (ie which includes most English speaking countries outside of the US) says autumn, including my home country of Australia. That's far short of all Western Hemisphere English-speaking countries. But this is already covered by WP:ENGVAR. Just as long as we don't use either as a date because those of us south of the equator have to do mental gymnastics every time somebody says fall 2017 or autumn 2017 and mentally convert that into our spring 2017. Stepho talk09:55, 26 November 2017 (UTC)
"You might have heard of that little island off the coast of Europe where the language first developed". Yes I have, @Dbfirs: I was born there and have lived in Commonwealth English speaking countries my whole life. It just seemed surprising to me that - after a lengthy discussion on the page about the order of numbered dates (e.g., "1/4/71") and the fact that the numbers are used differently in different parts of the world - no mention was made of this difference in usage, especially since it could cause confusion when the manual claims that "the same names are used for both northern hemisphere and southern hemisphere seasons", which implies that each season has only one name which is used worldwide at the appropriate time of the year. @Stepho-wrs: usage in Australia (and where I live in New Zealand) is irrelevant to its usage in the Western Hemisphere, as neither country is there. A lot ofCanadianwebsites seem to use the term fall in place of autumn, as do some Jamaican and Bahamian sites. Grutness...wha?00:49, 27 November 2017 (UTC)
I've made a tweak to MOS:SEASON as a result of this question--in case it wasn't obvious before, you should avoid the use of seasons entirely for dating. --Izno (talk) 14:54, 26 November 2017 (UTC)
Interesting ordinal date contradiction with WP:DATERET
On Erhard Maertens, the first (indeed, only) major contributor, scope creep, chose a date-number format that contravenes the Unacceptable date formats table, namely, Do not use ordinals (1st, 2nd, 3rd, etc.). What is the proper resolution here, and can WP:DATERET's wording be made clearer/stronger as to how these conflicts should be resolved in the future? ~Tom.Reding (talk ⋅dgaf)13:22, 3 December 2017 (UTC)
I reverted to your version i.e. without the ordinals. Nothing needs changing in DATERET, because when it says, "If an article has evolved using predominantly one date format", that obviously means one acceptable format. EEng14:09, 3 December 2017 (UTC)
The absence of "acceptable" was enough to dissuade scope creep to use unacceptable date formats, and enough ambiguity for me to bring it here. I'd say that's worth a 1-word 'bloat' addition. But I'll defer to consensus, of course. ~Tom.Reding (talk ⋅dgaf)14:50, 3 December 2017 (UTC)
You've proposed [5] adding acceptable to the guideline i.e.
If an article has evolved using predominantly one acceptable date format, this format should be used throughout the article...
But when the negation of a proviso would make the guideline absurd, then the proviso is unnecessary. The negation of acceptable date format is date format (whether acceptable or unacceptable) i.e.
If an article has evolved using predominantly one date format (whether acceptable or unacceptable), this format should be used throughout the article...
which is absurd. While I realize you were momentarily flummoxed by the situation, I really think that was an anomaly. Under your logic we'd have to add acceptable in a bunch of places, and if we miss one then next thing you know someone will be saying that in that one case the omission of acceptable means the unacceptable is, in fact, acceptable, leading to angry talk page discussions, personal attacks, and indefinite blocks. EEng15:48, 3 December 2017 (UTC)
MOS:DATERET appears to be a catch-all section, so I don't think it's absurd for someone to infer (whether acceptable or unacceptable), and indeed someone did. Also, when you said that obviously means one acceptable format, it's more accurate to replace "means" with "implies". For a catch-all section, explicitness is better than implicitness, so "acceptable" wouldn't have to be placed everywhere, I think. I would not want the scenario as you describe it to play out either, though.
I should caveat all this by saying I don't frequent MOS:Talk at all, and only now added it to my watchlist, so I'm unsure of how frequent a problem this is. While it might appear to me to be a non-trivial problem, it may, in practice, be an infrequent occurrence. If it's indeed rare, then it's probably not worth further discussion, so I'd like to know more about its frequency before conceding. ~Tom.Reding (talk ⋅dgaf)16:35, 3 December 2017 (UTC)
Take it from us – unwatch while there's still time! – EEng
To my recollection it's never come up that someone's suggested that DATERET implies that an "unacceptable" date format should be retained. EEng17:20, 3 December 2017 (UTC)
I thought about that, but I'm not really sure this is a dispute about date formats. It's more a dispute about a dispute about date formats. EEng17:43, 3 December 2017 (UTC)
There's a another circumstance where we have language like this: MOS:STYLERET. The "acceptable" wording came from ArbCom (in three cases, cited in WP:MOS's footnotes). Since DATERET is just STYLERET narrowed to dates, the "acceptable" proviso applies to it. It's true that "acceptable" seems redundant in the context of an entire MoS page, but virtually no one reads these pages top-to-bottom, just a section at a time, arrived at by shortcut. So, it's probably better to err on the side of clarity than brevity in this case. If someone just reads that a date [or other] style established in an article should not be changed without good reason, and they do not continue on to what styles are even acceptable at all, they'll naturally conclude that "July the first in the year of our Lord nineteen hundred and thirty-six" is a style they can revert to defend in an article of which they're the primary post-stub author. Not a desirable outcome. Even if they would not carry the day in such an argument, the time wasted on the argument is undesirable, as are poorly-watched articles with divergent style in them in the interim. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 01:27, 4 December 2017 (UTC)
Well, my prediction is that if acceptable is in there, then this hypothetical person will just say to himself, "Well, 'July the first in the year of our Lord nineteen hundred and thirty-six' is acceptable to me" and we're back where we started. So I guess we'll have to say, "acceptable under WP:DATEFORMAT together with all the provisos here and there about which and wherefore the various formats are designated to be used, and in what combinations". EEng02:46, 4 December 2017 (UTC)
I've only seen this happen one time, and the WP:GAMING attempt did not WP:WIN. It was, however, why STYLERET was reworded: 'On some questions of style, the MoS provides more than one acceptable answer; on other questions it gives no guidance. The Arbitration Committee has expressed the principle that "When either of two styles are acceptable ...' – pre-loading this with what "acceptable" means in the context. We can do something similar but much more concise here, e.g. If an article has evolved using predominantly one [[#Dates and years|acceptable date format]] .... All it takes is a word and a wikilink in this case. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 12:30, 4 December 2017 (UTC)
Hi Tom.Reding, Hi EEng, I think there needs to be an awareness that the date formats used in most European countries and to a certain extent, those countries that European countries, conquered, e.g. Britain conquering India, means that India uses the date format 10th May 2019, and other countries. I propose an extension is made to the format to enable this format. For most British, reading a date like 10th May 2019 is natural. Not 10 may 2019. That is read here as ten May 2019, which doesn't sound right. It should be 10th as in tenth of May 2019. As regards the WP:DATERET I have been using it fend folk off who have changed to American Date formats. I don't know what your thinking it, but the American format dates subverts British English articles, and reduces them. It is not fair really. I propose an extension or whatever the procedure to extend the MOS in this specific instance. Thanks.scope_creep (talk) 17:45, 3 December 2017 (UTC)
Undercover Wikipedian spot checking date formats in various Commonwealth newspapers
This is perennial rehash. We go over this several times per year and consensus never changes because the facts never change. The style "10th May 2019" isn't the one used in Commonwealth English, it's one of many styles ("10 May 2019", "10th of May 2019", "2019-05-10", even "May 10[th], 2019" in some publications). And "10th May 2019" style isn't limited to ComEng; it's also sometimes used by (mostly older) North Americans. The dominant style in ComEng publishing (we don't care how people write letters) is "10 May 2019". This is easy but tedious to verify by going down lists of notable, extant British, New Zealand, Hong Kong, Irish, Australian, etc., news publishers and seeing how they do dates. I just spot-checked about 30 of them, and all use "10 May 2019" format consistently, except: one used the weird "10 May, 2019" [almost certainly a software problem]; one used a mixture of those two; four used a mixture of "10 May 2019" under headlines and "10th May 2019" in running text; four used "May 10, 2019" (three were from the same publishing company); and two used "10 May 2019" in articles but "2019-05-10" style under headlines. So, a) "10 May 2019" clearly dominates, and b) it is conclusively proved that "10th May 2019" is not normative in Commonwealth English, just attested. WP doesn't need to use it because the th is redundant, like adding "of"; "10 May 2019" is perfectly understood by all English-language readers, including Americans (many of whom prefer it, especially in technical and academic writing). — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 01:27, 4 December 2017 (UTC)
Why don't you explain the rationale behind proscribing ordinals for dates in the section of the MoS that proscribes them? FactotEm (talk) 20:24, 4 December 2017 (UTC)
'Coz there ain't no rationale. It's just a choice, as good or as bad as any other consistently applied choice. (The alternative - not to make a choice - would be chaos). Leastways that's how I see it. Dondervogel 2 (talk) 20:59, 4 December 2017 (UTC)
But there is a rationale, based on established style guides in the world of publishing and common usage, or have I misunderstood something? FactotEm (talk) 15:45, 5 December 2017 (UTC)
There's no one "established style guides in the world of publishing and common usage". There actually are publications using ordinal dates e.g. check out this Edinburgh bus schedule [6]. But each publication needs a house style or everything looks like a mess, and no-ordinals is ours. It's actually amazing we're able to operate effectively with the choice of MDY and DMY – the last thing we need is to turn that difficult marriage into a love triangle. EEng15:54, 5 December 2017 (UTC)
To be clear, other than finding it a little odd at first, I do not have, nor have I ever had a problem with this standard. Apparently a lot of people do, though. The MoS is effectively banning by diktat a convention that many people routinely use in spoken English. The replies to my original post indicate the decision to adopt this standard was purely arbitrary. However, SMcCandlish's post above, and points made in previous discussions, seem to indicate that the preponderance of the cardinal format in modern usage, reflected in many reputable style guides, influenced this decision. This seems a reasonable justification to me. I just don't understand why it isn't stated somewhere more prominent than the talk pages. FactotEm (talk) 11:28, 6 December 2017 (UTC)
When I was at school I was taught to write "10 May 1969" and read this out loud as "the tenth of May, nineteen sixty-nine". Sure, written and spoken forms are different, but Wikipedia is (for the most part) a written encyclopaedia, not a spoken one. (Question: Is there an equivalent of MOSNUM for "spoken" articles? The point being raised would be more relevant there, especially as there at least two different ways of reading (the year) 2019) Dondervogel 2 (talk) 16:03, 6 December 2017 (UTC)
We would need new technological support for a "voice MoS" to be feasible or even meaningful, e.g. a way to force a pronunciation like "the tenth of May" when "10 May" is followed by a year and read aloud. Assuming such a thing were a good idea; there are people who do not read that construction that way at all, but say "ten May", exactly as written. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 08:09, 7 December 2017 (UTC)
The source rationale for the rule isn't stated in MoS because (see a zillion prior "source the MoS" discussions) MoS is not an article, but a guideline and we do not cite sources in guidelines, we provided the advice that consensus has concluded to provide, which is based on internal consensus discussion, often informed by sources, but not entirely derived from them; consensus is also derived from collective editorial common sense and experience of what works well here and what does not. Further, if we sourced this then people would want to source everything, and then MoS would be enormously longer. MoS is not part of the encyclopedia content, is not a statement of facts about the world, and is not providing advice to anyone otehr that WP editors for how to write WP content. In the very small number of places where MoS has an external source, it's for when we're deferring to an off-site standards document like HTML5 or something from IETF, WCAG, ISO, etc. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 08:09, 7 December 2017 (UTC)
Thanks for taking the time to answer my question. I tried searching the archives for more info on sourcing the MoS, but haven't found anything pertinent yet. I'm still not sure I understand why we can't have some explanation to help us understand why things are the way they are for the more contentious issues, but I'm not going to waste anyone's time pursuing it any further here. I'll keep digging and maybe raise it again in the future if I feel there is anything new to be said. FactotEm (talk) 15:14, 8 December 2017 (UTC)
Dear Wikipedians!!, You WP:MOS folk, I think, I suspect that like most folk, you are resistant to change. But we live in a changing world. SMcCandlish most newspapers, designed in the UK, and other English speaking nations, are designed to be read by transatlantic audiencies, and as such use the simplest of date format as possible, the American date format. SMcCandlish I see you have never written a very large, complex article, perhaps involving 100's, or 1000's of hours of research, then to write it, in British English, and realize you can't use British date formats, because at some point, somebody is going run a bot against the article and remove the ordinal dates. It is disheartining and not really fair. Your rationale is therefore incorrect. I will round up some evidence. Out of the 2.2million books published in the UK every year, some of them must use it. I will find the research. What is the formal method to raise a change in the WP:MOS. scope_creep (talk) 00:54, 5 December 2017 (UTC)
Let me save you, and everyone else, some time. This has been chewed over many, many times, and something seismic will have to happen – like Jesus, Mohammed, and Yahweh appearing on TV as a Three Tenors tribute group and ordaining it in song – before it's going to change. If you still want to waste your time on this, start by reviewing the innumerable prior discussions listed here [7], and if you have something new to say, then get back to us. Finding examples of ordinals in the wild has zero value, because we already know that. Every publication has its house style, and that doesn't mean allowing everything that someone somewhere has exemplified.
While we're here, let me give you another tip. The surest and fastest way to make a fool of youself on Wikipedia, and particularly here at MOS, is to present yourself as oh-so-more experienced than your fellow editors. The proportion of people here who do serious literary, governmental, commercial, or academic research and writing is very high, and to be quite blunt your post above is barely literate. You're not fooling anyone.
User:EEng That is a bit harsh. Your purpose here seems to be push back, without supplying a cogent argument. What are you talking about? You seem to have the attitude that the MOS is inviolate, cast in stone, like the commandments, unable to change. I was making a point, that you have choosen to ignore. I will look through your list, find the research, analyze it, and if the research bears it up, the MOS will be changed. scope_creep (talk) 08:55, 5 December 2017 (UTC)
Given that you wrote I see you have never written a very large, complex article, perhaps involving 100's, or 1000's of hours of research, you should consider yourself to have got off easy. And there's a reason there's a box near the top of this page: It has been X days since the outbreak of the latest dispute over date formats.EEng09:21, 5 December 2017 (UTC)
Personal ages are typically stated in figures (8-year-old child).
It simply isn't correct, and is patent WP:CREEP. It's entirely normal English, including in an encyclopedic register (perhaps especially in one) to write "eight-year-old child". Many of us do this, and the alleged exception is inconsistent with the general "Numbers as figures or words" rule, for no good reason. We gain nothing – for readers or for editors – in having this line-item. This is simply someone's personal preference, and I don't believe it represents consensus at all. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 22:59, 20 November 2017 (UTC)
Yeah, and that's a style we wouldn't use here. We don't even do that in infoboxes; we use "Died: June 22, 2008 (aged 71)" style. — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 04:46, 21 November 2017 (UTC)
Yes, please. There's another figure–word rule I hate: you can't start a sentence with a figure? But I can't imagine the moaning and wailing that would greet a proposal to remove that. Tony(talk) 02:48, 23 November 2017 (UTC)
I agree also. Except for the bit about numbers in figures not starting a sentence, which generally helps readability (except possibly when it's a list). MapReader (talk) 10:23, 3 December 2017 (UTC)
The lead sentence is another obvious exception. A page starting with "3M is an American corporation ..." isn't likely to confuse anyone or even raise an objection from people who hate sentences starting with numerals; they're not apt to vent about list items, headings, table headers, or captions starting with numerals (or the lowercase i in iPod, or whatever), either. Anyway, we could RfC the matter, but I think we may be hitting MoS- and AT-related RfC saturation point right now, especially as the holidays draw near.
There's a long-term productively risk too: If we had no line-item in MoS saying to rewrite (when practical) to avoid beginning running-prose sentences with numerals, lower-case letters, and misc. symbols, then people would do it way more than probably anyone would be comfortable with. The effective status quo is that we generally write to avoid it, but don't stress about it and go ahead and use a "3M" or an "iPod" at the start of a sentence if rewriting would be awkward. All is well. What we could end up with is people who hate rules who just don't give a damn going around writing sentences like "21 episodes were aired in season 3.", just because they can get away with it and like to write like this is their personal blog. The amount of work it would take to clean up genuinely poor usage could greatly exceed the amount of work we presently engage in to avoid that poor usage because of the "rule" (recommendation). — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 18:41, 13 December 2017 (UTC)
Am I missing something where changes to MOS like this are communicated? Or is it a matter of embarrassment & crazy-making that all editors must go thru when quoting MOS in editsums, to learn they were mistaken, or check each time for a changed MOS before quoting it, respectively? (I'd suggest a summary of changes published quarterly, in the WP online "magazine". It'd be a reasonable place & time for an editor to review what's changed. Else embarrassment & crazy-making. Am I missing if/where such a summary is published periodically? Obviously, the changes to MOS s/b synch'd with the periodic publication, not done piece-meal at random/unpredictable times.) Thx. --IHTS (talk) 13:03, 13 December 2017 (UTC)
Yeah, I'm not sure who'd want to volunteer for that kind of "policy journalism"; sounds like a lot of work, and it's very "meta". — SMcCandlish☏¢ >ʌⱷ҅ᴥⱷʌ< 18:41, 13 December 2017 (UTC)
There are many hundreds of pages that have "was jailed for two-and-a-half years" or similarly (unnecessarily) hyphenated mixed numbers. The hyphens need to be removed. The manual says "Mixed numbers are usually given in figures", so my inclination is to change it to "was jailed for 2+1⁄2 years". Would such a change bring howls of protest from editors who prefer something else, like "was jailed for two and a half years" or "was jailed for two and one-half years"? The manual does not cover the topic of hyphens or lack of hyphens in mixed numbers that are spelled out. If the number is adjectival, I think that "a two-and-a-half-year sentence" would be improved if changed to "a 2+1⁄2-year sentence". Does anyone feel differently, or am I on the right track? Christhe spelleryack17:26, 17 December 2017 (UTC)
I'm not sure what ENGVAR issue you're talking about. Writing 2,5 is common in some countries, but as far as I know not in any English-speaking countries, which are the only ones that "count" for ENGVAR purposes.
Adventures in localization: I once was the main programmer for a numerical Windows application. As what I thought was a friendly gesture, I made it respect the locale that you had your computer set to. We got a complaint from a German user who was used to seeing decimal points, rather than commas, in "English software". I'd never thought of it as English software; it was numerical software. Oh well. We added an option so that the user could specify whether the program would respect the locale, or use the default "C" locale (the "C" locale uses decimal points). --Trovatore (talk) 21:56, 22 January 2018 (UTC)
That doesn't make any sense to me. Americans understand 2.5 as well as anyone else. To me the distinction between 2+1⁄2 and 2.5 is that 2+1⁄2, in principle, is an exact number, whereas 2.5 is likely to be rounded to the nearest tenth. --Trovatore (talk) 00:44, 23 January 2018 (UTC)
Well, but Americans don't generally write "favour". They do write 2.5. I really don't know where you're coming up with this ENGVAR thing. I think you have some belief that is just false. --Trovatore (talk) 03:13, 23 January 2018 (UTC)
If I were to go to a well-trafficked article written in British English and add some relevant information about such-and-such a thing being "2+1⁄2 metres high", it would be changed to "2.5 metres", with ENGVAR as the justification, faster than you can say "false belief". Primergrey (talk) 03:57, 23 January 2018 (UTC)
Well, it could be that the Brits (incorrectly) think that it's an ENGVAR issue. But it isn't. No one would change it the other direction in an AmE article. --Trovatore (talk) 04:09, 23 January 2018 (UTC) Though of course they might change metres to meters. --Trovatore (talk) 04:10, 23 January 2018 (UTC)
I'm looking at [8], which consistently changed CE to AD, in violation of MOS:ERA: "Do not change the established era style in an article unless there are reasons specific to its content. Seek consensus on the talk page...". But, at first blush, reverting that change seems to be hypocritical. Should I interpret "established" as "the style used over the several most recent edits, or for a significant amount of time"? Am I worrying too much? Probably. David Brooks (talk) 14:09, 29 January 2018 (UTC)
Kendall-K1 pointed out that the article had consistently used AD until July 2017; sorry I didn't check earlier. So, on the principle of reverting a change that does not respect policy, it was correct to change CE back to AD. In general, I guess my "hypocrisy" concern over reverting an unexplained change didn't fully appreciate the intent of "established" (over time, not necessarily the version that happens to be current). So I'll go quietly now. David Brooks (talk) 05:36, 30 January 2018 (UTC)
Rule on M and bn
I have to question whether this should be retained, at least in anything like the current form:
* M (unspaced) or bn (unspaced) respectively may be used for "million" or "billion" after a number, when the word has been spelled out at the first occurrence (She received £70million and her son £10M).<!-- This needs to be coordinated with text in units tables re nonuse of M (for 1000) MM, etc. -->
Reasons:
It's inconsistent to use bn (lower-case) but M (capitalized).
The bn abbreviation isn't all that frequently used in general-audience publications (mostly in financial news, which verges on specialist material).
It's also not consistently given as bn but sometimes Bn or B; why are we advocating bn in particular? (Similarly, m is often used in real-world sources, especially ones not using metric units.)
The fact that this use of M can be confused with M for 1000 is a problem.
In both cases, mil. and bil. appear to be much more common in general-audience English; I would advocate that we switch to recommending these.
"At the first occurrence" here is ambiguous. We mean "at the first occurrence in the same passage" or something to this effect, but it's going to be misinterpreted to mean that as long as million appeared in the lead, for example, that any other occurrence can be replaced with M, even if it's separated from million by 50K of article text.
When we actually do want to use an abbreviation, there's no reason that the normal rules in MOS:ABBR shouldn't apply – i.e., do something like £10mil. (or £10M) at first occurrence, with {{abbr}}, regardless how recently we used million somewhere in the same page.
re 4. I can't conceive of a normal case where the Roman numeral "M" (=1000) could be confused with "M" = million = mega = 1,000,000. In the case quoted how could £10M be anything other than ten million quid? Martin of Sheffield (talk) 21:59, 19 January 2018 (UTC)
Do we care? If seven rationales for a change are provided and one is weak, and there are no counter-rationales, then the change should probably proceed. — SMcCandlish☏¢ 😼 22:06, 19 January 2018 (UTC)
Well if you want all reasons addressed:
bn is an abbreviation of "billion", but M is widly understood as the SI unit "Mega" with international abbreviation "M". With all due deference to the bullet below, use of "M" and "k" in finance is a long-lost battle. It would be difficult to find someone who didn't understand £45k as a salary or $367k for a house.
Umm, newspaper headlines are pretty general-audience.
I've no problem with bn or Bn, though the former is to be preferred on stylistic grounds ("Bn" is neither a proper noun nor an initialism). B is widely understood to be "bytes". Probably not confused that often, but clearly sub-optimal. m may be incorrectly used in the real-world, but is clearly wrong (milli or possibly metres).
As above.
mil. as an abbreviation is seriously overloaded. Milli- and million may be discernible by context but do we need to require readers to pause to think? Likewise "military" is pretty standard.
Agreed.
Agreed.
Originally though you were asking whether a specific bullet point should be retained. The implication is retain or delete. However your point 5 implies you wish to change it. Perhaps you could clarify:
I'm not convinced this needs to be specified in the MOS, and in general I think Stanton loves inter-article consistency far too much. Inter-article consistency is really not that important, as long as all articles are understandable. The way to shorten the MoS, as apparently all would like, is to allow articles more local control. That said, I do have a preference here, which is that if we use M, we should also use B, as these are both The Economist-style. I don't think there is much danger of confusion between "billion" and "bytes". --Trovatore (talk) 20:58, 21 January 2018 (UTC)
Using "million" and "M" in the same sentence is inconsistent. I see no reason why the rules should demand inconsistency. Surely there's nothing wrong with using either "million" or "M" twice in the same sentence? DrKay (talk) 10:18, 7 February 2018 (UTC)
For what it's worth I do favour inter-article consistency. The precise abbreviation used is less important than the consistency, though I quite like mn, bn, tn. Dondervogel 2 (talk) 14:22, 7 February 2018 (UTC)
Ranges using the words "century", "decade", etc.
I've just reformatted a date range from fl. 1st/2nd century AD to fl. 1st to 2nd century AD. Keeping century AD seems necessary here, and in that case using an en dash doesn't seem appropriate, but this kind of range isn't addressed here or at Wikipedia:Manual of Style#En dashes. Does this format seem right? If so, could it be made explicit here? Languorrises (talk) 17:43, 11 February 2018 (UTC)
I read fl. 1st/2nd century AD as "in the first and/or the second" and fl. 1st to 2nd century AD as "in the first and the second". The impicit uncertainty of the first form will often be appropriate and clearly is in this case (we shouldn't say that someone who is only known to have begun practicing medicine at some point in Trajan's 98–117 AD reign definitely flourished in the first century). 79.73.243.152 (talk) 12:21, 16 February 2018 (UTC)
Please help. MOS says a format is acceptable (MOS says it "may" be used). An editor keeps on traipsing around the Project, changing it. As though MOS says the opposite -- that it "may not" be used. From the already-used acceptable format.
MOS:DATERET and MOS:RETAIN apply in this situation. If multiple formats are allow by the guidelines then the existing format in the article gets priority unless there is consensus on the talk page to change it. Arbitrary changes from one format to the other are not allowed without consensus. Stepho talk12:31, 23 February 2018 (UTC)
While there was some support to phase out the use of crore/lakh in articles, it seems that the consensus is to retain such terms in India-related articles, provided that either crore or lakh is to be linked at the first mention in the article, and that a conversion to either US$ or regular Rupee numbers is provided. As for how to present such conversions, consensus appears to be that US$ conversions must include whatever the conversion was at the relevant time (the {{INRConvert}} template can be used for this purpose). (non-admin closure) Narutolovehinata5tccsdnew 13:40, 15 March 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Sometimes, the variety of English used in an article may necessitate the use of a numbering system other than the Western thousands-based system. For example, the South Asian numbering system is conventionally used in South Asian English. In those situations, link the first spelled-out instance of each quantity (e.g. crore, which yields: crore).
This is followed by three more bullet points of WP:CREEP about crore. The lead sentence of this is just patently false; nothing necessitates the use of alternative numbering systems. Proof that Indian English doesn't do so abounds (including with regard to Indian currency) [9], [10], [11], [12] etc., etc.
I propose that this be deleted and replaced with a) short advice against use of crore in Wikipedia articles, unless conversion is provided to Western numbers, and b) retaining the advice against using "1,00,00,000" for "10,000,000".
Rationale: I do not believe the present wording has actual consensus, and crore are rarely used in our articles even on Indian subjects. Some small number of Indian editors have somehow gotten MoS to be permissive about crore, despite it being non-English and meaning nothing to most anyone outside that part of the world, and despite English-speakers of India having no problem with "ten million" (or "10,000,000", "10mil", "10M", etc.) — SMcCandlish☏¢ 😼 05:08, 24 January 2018 (UTC)
Comments on crore
I would be in favour of deletion, assuming most Indian readers do understand million. I have the impression they do, having lived in India for a while, although the people I associated with may not have been representative. I do find your evidence convincing. Kendall-K1 (talk) 13:03, 24 January 2018 (UTC)
I normally oppose decisions in favour of consistency for the sake of consistency, but in this case I would support advising against the use of crore without a converstion to million/Western numbers in order to make numbers equally understandable across the project. I would, however, like to see input from Wikiproject India editors before anything vaguely resembling 'consensus' is assessed, especially with regard to its inclusion in Indian English articles. -- Cheers, Alfie. (Say Hi!) 22:52, 27 January 2018 (UTC)
Any chance of a couple of links to articles where this would make a difference? An article on numbering systems may need to show examples of crore and lakh and the highlighted text seems compatible with that. There may be articles where prices are given in a way that would not be meaningful for most enwiki readers and either commonsense or this guideline should spell out standard procedure. Johnuniq (talk) 00:08, 30 January 2018 (UTC)
I coincidentally came across an article yesterday that I thought handled it well: Padmaavat: "With a production budget of ₹215 crore (US$34 million)..." Others may disagree but I think it works fine to use crore for rupees and million for dollars. It would look a bit cluttered to say "₹215 crore (₹2.15 billion) (US$34 million (US$3.4 crore))". Kendall-K1 (talk) 02:35, 30 January 2018 (UTC)
I agree that "₹215 crore (US$34 million)" is good, particularly if the source gives the crore value. There's no problem in exposing readers to how the world works in other places. Johnuniq (talk) 02:42, 30 January 2018 (UTC)
Seeing what links to crore will mostly give you movies and bios of rich people, but you'll also get some hits searching for, say, "lakh votes", "lakh people", "lakh tons", "lakh villages", and "crore people." One curious example is K-IV water project, which mixes both styles: The estimated cost of approximately Rs.25.5 billion, this water project intended to provide 65 crore gallons of water to the Karachiites in three phases (260mgd + 260mgd + 130 MGD). -165.234.252.11 (talk) 19:03, 30 January 2018 (UTC)
Lakh women, lakh police officers, lakh homeless people, lakh Soil Health Cards, lakh 2-wheelers, lakh square feet, lakh polling stations, lakh households, lakh subscribers, lakh insurance policies sold, lakh surgeries, lakh infants, lakh litres of milk, lakh Youtube views, lakh trees, lakh shirts, lakh lakes, and sho on and sho on. -165.234.252.11 (talk) 19:15, 30 January 2018 (UTC)
Personally, I'm in favor of SMcCandlish's proposal per the spirit of MOS:COMMONALITY: Prefer vocabulary common to all varieties of English. [...] Universally used terms are often preferable to less widely distributed terms, especially in article titles. For example, glasses is preferred to the national varieties spectacles (British English) and eyeglasses (American English); ten million is preferable to one crore (Indian English). (So I guess I'm in favor per the letter of COMMONALITY, too.) Different ways of counting are in a whole different league from color vs. colour and pounds vs. kilos. -165.234.252.11 (talk) 18:58, 30 January 2018 (UTC)
I'm in favor of linking and converting the terms lakh and crore, and am not in favor of using the peculiar numerical digit separation scheme that goes with the terms. However, I wouldn't want to discourage the use of the words themselves in articles, as I encounter them all the time in sources. They are defined by my smaller English dictionaries and are used in my print Britannica without any indication that they constitute choice, i.e. unusual, diction. Dhtwiki (talk) 22:49, 3 February 2018 (UTC)
For somebody immersed in the Indian culture, lakh and crore are perfectly natural terms. For somebody not immersed in the culture, they are unintelligible terms that break the flow of thought. Sometimes in a car article I see an editor add the Indian price of a car expressed in lahk. Apart from WP not being a price guide, this has the double whammy of throwing lahk onto unsuspecting readers who were looking for information on a car and weren't particularly interested in learning a new numbering system. Better to keep to the simple numbers that are common to all forms of English, for both native English speakers and those who learnt it as a second language. Stepho talk00:13, 4 February 2018 (UTC)
Lacs and Crores are very much native to the Indian Culture and English usage as Customary units are for the American population. I am not in favor of removing the usage as a policy. We could have a template that can handle the conversion whenever these units are used and including the template can be made as a policy. --Hagennos (talk) 07:27, 4 February 2018 (UTC)
I support both requests; I think neither is unjustified or onerous to implement. I actually enjoy seeing crore used as a unit (makes the place look a little less parochial), but conversion of possibly unknown units is a standard usability convention and should be observed here. The alternate punctuation approach is just plain confusing and should be avoided. --Elmidae (talk · contribs) 10:46, 13 February 2018 (UTC)
Fruitless uphill battle - Though my personal preference would be to discourage the usage of crore on the basis that we write for a global readership, and western numerical formatting seems to be more widely embraced, this is a fruitless uphill battle. In Indian film articles (of which there are tens of thousands,) lakh and crore are the dominant terms, and these are the terms used extensively by the Indian film trades and other reliable news sources. Trying to wrangle in all of the crores is a fool's errand, since the majority of casual Indian editors will (in my vast experience) convert ten millions back to crore. And just from a practical perspective, when I have to check whether or not Film A grossed 1223.3 million, it's way easier to match to a reference, as the reference is almost certainly in crore. I don't want to have to do mental math conversions when spot-checking against potential vandalism. And other suggestions of using templates to provide conversions seems like it has the potential to make a mess in articles, especially when we're also performing conversions for financial figures. Cyphoidbomb (talk) 23:33, 17 February 2018 (UTC)
That something will be tedious and take a long time to incrementally deal with has never been rationale for why to not do what's best for the readership. And we have bots for a reason; they excel at auto-converting predictable numeric patterns. — SMcCandlish☏¢ 😼 16:30, 22 February 2018 (UTC)
I've edited on WP:India for quite a while and i still can never remember exactly how much a Lakh or Crore is relative to dollars. As suggested above, having an automatic conversion into dollars next to the Crore value etc sounds like a good idea. It would be a good policy compromise (MOS:TIES vs COMMONALITY). It's important to display Indian currencies still, they have a comparative and cultural value within India and are often used in reliable sources. Cesdeva (talk) 04:50, 18 February 2018 (UTC)
Lakh and Crore are very common in Indian-English and articles, removing these may not be a good idea. Moreover, we cannot term these as non-English. These words are present in British and American dictionaries from long time back.
Don't try to push water uphill. Do advise in favour of using/including conversion when using lakh/core when it is desired to use the terms. Do support anyone who edits to include conversion where it has been omitted. Don't waste time, effort, and goodwill by trying to police it where there is no compelling reason (such reason as for instance someone mischievously converting standard western notation in western articles to crores without conversion). Stop wasting time on this discussion. JonRichfield (talk) 06:16, 18 February 2018 (UTC)
Monetary conversion templates such as INRConvert should not generally be used in list type articles or infoboxes per this consensus and this discussion. The prevailing attitude was: 1) Converting to US dollars is arbitrary. 2) Default conversion templates create problems with inflation, Ex: where the gross from a 2008 film is converted to the present year's US$ rate. 3) The inflation adjustment option in the template results in infobox clutter.
This only applies to Lists and infoboxes, and precludes inflation as well as dollar conversions, but the "budget" and "gross" infobox figures for Indian films are one of the major uses of crore. - Arjayay (talk) 11:20, 18 February 2018 (UTC)
I was thinking the same. Infoxbox of movies should still be using crore or otherwise it will be confusing for readers that are mostly used to with crores. MapSGV (talk) 02:55, 20 February 2018 (UTC)
The purpose of Wikipedia is primarily to serve its readers. Taking a look at the current problem from this point of view gives us the full picture.
Most articles using India English are meant for a audience which primarily hails from the subcontinent ( Baring certain notable exceptions such as India, Indian, West Bengal, Bengali, Punjab, Punjabi, and all such articles ). Using a number system other than the crore and lakh system of representation ( which is widely prevalent among Indians ) will mean putting a sizeable chunk of the articles readership at a unfair disadvantage for the sake of consistency.
Thus according to my veiws on the matter, the crore and lakh system should be used in articles depending on the expected veiwership ratios (Indian:Non-Indian) of the article. Conversion templates should be used for ease of the Western readers but not in infoboxes, ledes, list articles and disambiguation pages. Finally it should also be made mandatory to link to crore and lakh on the first instance to avoid creating confusing some one who has absolutely no idea about the Indian system of numbering — FR™10:33, 20 February 2018 (UTC)
Don't remove — Most articles pertaining to WikiProject India draw majority of their pageviews from India, so removing crore from these articles would be detrimental, and would go against the very basic aim of this encyclopaedia building exercise, that is, to make articles as accessible to the viewers.
What I'd suggest to make the articles more globally accessible is to make conversion of crore/lakh into its western equivalents mandatory. {{INRConvert}} already does this, and for the rest of things editors should be advised to do the same. Regards, SshibumXZ (Talk) (Contributions). 18:52, 20 February 2018 (UTC)
Yes, that does seem the way to proceed, though we would ideally have crore/lakh second. Doing it the other way around has the same "These are just written for Indian people" ghettoizing effect as not providing the conversions, only to a lesser extent. — SMcCandlish☏¢ 😼 16:33, 22 February 2018 (UTC)
(edit conflict) Except it wouldn't be detrimental because Indians also understand the "Western" (pretty much world-wide) numbering system. The opening statement already covered this, as well as that we can provide crore in cases where we want it as a converted, secondary value. — SMcCandlish☏¢ 😼 16:33, 22 February 2018 (UTC)
@SMcCandish: I would've to disagree with you there, I think it would be detrimental, or at least inconvenient. As far as having core/lakh second, I don't have any strong views about either way, but, I think where a monetary value is involved, crore/lakh should take precedence, but as {{INRConvert}} already does this, no further change would be needed. Regards, SshibumXZ (Talk) (Contributions). 18:17, 22 February 2018 (UTC)
@Arjayay: oh, ok. To remedy that, I think we can make an exception for films as per the consensus reached by the Indian cinema task force, monetary values for films can be manually converted taking the average value of INR against USD for that year into account. I don't think this is a dealbreaker in any shape or form. Regards, SshibumXZ (Talk) (Contributions). 19:55, 23 February 2018 (UTC)
Don't remove per SshibumXZ, and don't mandate any particular order for the Indian/converted format. Having a conversion is a good idea though, and to be honest I think that applies even in film articles. Wikipedia should take a WP:WORLDWIDE view and not suppress formats that are valid in different varieties of English. — Amakuru (talk) 10:43, 27 February 2018 (UTC)
Continue to allow but mandate a conversion. Presumably many Indian readers, who are often likely to be the only readers of film articles etc (plus some dispora element) still think in lakh and crore, and we should accomodate them. At the same time, non-Indians should be able to readily understand the text. On the whole I don't favour the "₹215 crore (US$34 million)" style for money (it's fine for other figures), as it brings in a currency conversion. Better to give two rupee figures in both units, and a dated coversion in millions to the $. Johnbod (talk) 15:33, 27 February 2018 (UTC)
Exchange rates vary over time. If we convert to a foreign currency then we must also specify the time of conversion. Eg "₹215 crore (US$34 million at February 2018 exchange rates)". Stepho talk22:33, 27 February 2018 (UTC)
Apologies, I missed the word 'dated'. 00:14, 3 March 2018 (UTC)
For film articles, the date should be implied; the time the film earned the money, whether in theaters or in other forms of distribution. How about making the template; "₹215 crore (then US$34 million}"? SeptentrionalisPMAnderson20:10, 2 March 2018 (UTC)
Unfortunately the date cannot be implied. Assume a film comes out in June 2018. It gets an article in August 2018 that gives the cost as ₹215 crore. In December 2018, a helpful editor specifies the cost in US dollars by looking up the current (ie December 2018) conversion rates - alas, practically no-one looks up up the historical conversions rates. In November 2025 after a huge stock market adjustment where India's economy doubled that of US, an editor sees the 2 amounts, wonders why it was double the price it should be and helpfully puts the 'correct' figure according to November 2025 conversion rates. Without a dated conversion a reader has no idea which is the correct amount. A dated conversion solves this ambiguity. Stepho talk00:14, 3 March 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
What is needed is a ruling from the MOS deities: should rai and pyeong be italicized by {{convert}}? I think that is a style issue that is not really in convert's domain. Johnuniq (talk) 01:04, 2 May 2018 (UTC)
This sounds to me like a more general style issue, outside the scope of MOSNUM. Does MOS require foreign words to be italicized? Dondervogel 2 (talk) 08:11, 2 May 2018 (UTC)
Require? no; prefer? yes. See MOS:FOREIGNITALIC. So that browsers know how to properly render and screen readers properly speak non-English text, such terms should, I think, be marked up:
The context of use makes it clear that the word refers to a unit, which is sufficient for the purpose of alerting the reader that special interpretation is needed. I also find that the emphasis given by the italics gives a sense of having to look for something unexpected: that I should be looking for a meaning other than more than the obvious use as a unit or measure. I think that italicization of foreign units should be debated as a class, not only the two units considered here, and not simply as part of the blanket class of foreign phrases. I'm mildly opposed to the proposal to italicize such units. —Quondum12:10, 2 May 2018 (UTC)
I am also mildly opposed to italicizing them, but I strongly support Trappist's suggestion of adding the span tags to identify the language, and it might be helpful to link to the article about the unit. Another option, for the second, might be specifying that it's "3995 Korean pyeong". WhatamIdoing (talk) 07:17, 7 May 2018 (UTC)
It seems there's a rather clear no consensus in support of italicising such units, at least when they follow numbers. I think this can safely be dropped; thanks for the input. --Paul_012 (talk) 04:12, 10 May 2018 (UTC)
Should definitely be italicized, since they're not English, in any sense (assimilated loanwords, etc.). We've assimilated taco and soufflé and sushi, but we still italicize non-assimilated foreign food names like feijoada, vánočka, and nhúng dấm. This is no different. How and why could it possibly be? MoS already covers this at MOS:FOREIGN, which makes no "magically special" exceptions for something relating to numbers or measuring. It is not required, or even sane, for MoS to try to list every possible category of "things" that might be covered by it, or that section of MoS alone would be a list so long it would crash your browser. Paul 012's "assessment" above is backasswards. There is over a decade of unwavering consensus to italicize non-assimilated foreign words that appear in English language passages (and which are not proper names – we do not write "Charlie Sheen was born Carlos Estévez"). What there is "rather clear no consensus" for is making up a fake exception out of nothing whatsoever, just to suit random personal whim. — SMcCandlish☏¢ 😼 01:48, 19 May 2018 (UTC)
Decide on “l” vs “L” for litre (liter)
This page (in the table “Guidelines on specific units”) gives the option of using either of the SI symbols for litre: “l” or “L”, just as SI itself does. In the United States the National Institute of Standards and Technology explicitly says to use “L”, not “l” (nor “ℓ”). (See note (b) to table 6 in SP 811.) I do not know if other English-speaking nations have similar conventions that officially favor “l” over “L”. Given the U.S. preference for “L”, and the logic expressed in the annotation, I think it makes sense for Wikipedia to simply stick with “L”.
Lowercase seems to be more common in the UK, for example a beer can is 500 ml. I note that NIST says "the symbol to be used in the United States is L", perhaps outside the US "l" should be preferred. So the question then becomes how US centric should WP be? ~~
My impression is that L is used more often in isolation, but ml is much more common for milliliters, including in the US, at least in non-scientific use. However you might well see mL in scientific papers.
I doubt there's much the MoS can do to clean this up. I would suggest staying out of it.
That said, I do think l in isolation is probably a bad idea, if for no other reason because Wikipedia is rendered by default in sans, and the lowercase ell is almost indistinguishable from the uppercase eye. --Trovatore (talk) 22:58, 27 April 2018 (UTC)
We are not bound by the US government. However, lowercase 'l' can be mistaken for the number one - especially if the editor missed the space before the unit or the reader is used to spaces after the decimal. Eg, 1.123 l vs 1.123 L. Stepho talk00:02, 28 April 2018 (UTC)
I would be OK with a recommendation to avoid l for liters, provided it explicitly says that ml is OK for milliliters, at least in non-science articles. --Trovatore (talk) 00:13, 28 April 2018 (UTC)
I can buy that as well. Another potential solution is recommending a serif-templated version of it, like we do for certain letters in variables, but people ignore that one all the time, so they would ignore this one too. That said, it's also means they're going to ignore the "use L" instruction if they're used to "l". In the end, only gnomes are going to care or do anything about it, so it may not really matter what the rule says, as long as there is one, and it's specific, not a "do whatcha like" wish-washy thing. We already have a general rule to not use abbreviated units on first occurrence; the symbols are generally used inside parenthetical conversions, in tables, etc., so I'm skeptical that there's a real problem to solve there, or we would have had a shitstorm about it long before now. — SMcCandlish☏¢ 😼 02:05, 19 May 2018 (UTC)
Proposal to recommend L for non-scientific articles
How about the following? The first sentence is what's in the guideline already.
The symbol l (lowercase "el") in isolation (i.e. not in such forms as ml) is easily mistaken for the digit 1 or the capital letter I ("eye"). Outside scientific articles it may be preferable to use L.
Somehow I figured "it may be preferable" would be all things to all people and avoid a long debate. EEng03:02, 28 April 2018 (UTC)
The symbol l (lowercase "el") in isolation (i.e. not in such forms as ml) is easily mistaken for the digit 1 or the capital letter I ("eye"). Therefore L may be preferable. Reminder: The first sentence is in the guideline already.
That would be an improvement on what's there now, but I would like it more without the "may be". Under what circumstances is it not preferable to avoid the potential for misreading the character l?. Dondervogel 2 (talk) 17:00, 28 April 2018 (UTC)
If we leave the wording as may be preferable, I predict there will be little objection and we'll end up adopting it. If we change it to say anything from is preferable to must, I predict a big fight. EEng17:11, 28 April 2018 (UTC)
EEng's is better. It may be preferable, but I can certainly imagine cases where it isn't. For example, if mixing millilitres and litres in the same article, the disambiguation benefit of using "L" may well be outweighed by the confusion of using a different symbol for "litre" depending on whether it has a prefix or not. Kahastoktalk16:56, 29 April 2018 (UTC)
Consistent usage within an article (except in direct quotes) should triumph over which symbol is less ambiguous. Using "L" in the same article as "ml" invites the reader to think the "l" and the "L" have different meanings, and the reader is left scratching her head, wondering what the one that isn't a liter might be. If we do go for "L", every occurrence in this guideline, WP:MOS, and any subsidiary guideline of WP:MOS should be changed to "L". Jc3s5h (talk) 17:16, 29 April 2018 (UTC)
I don't see anyone arguing for a mix of L and ml. If L is preferred over l it follows that mL is preferred over ml. I don't see a need to make it explicit because of the overarching requirement for consistent, but I would not object to making it explicit (still with EEng's "may be preferable") if others don't mind the verbosity:
The symbol l (lowercase "el") in isolation (i.e. not in such forms as ml) is easily mistaken for the digit 1 or the capital letter I ("eye"). Therefore L may be preferable. Once a symbol for litre is chosen for an article, the same symbol is used throughout that article (e.g., "1 L is 1000 mL", and not "1 L is 1000 ml").
No, I disagree. The argument against lowercase ell applies when it's used by itself. It doesn't apply for ml. I explicitly said I was OK with recommending L, provided it is explicitly stated that ml is OK. --Trovatore (talk) 21:02, 29 April 2018 (UTC)
Oh, maybe I misunderstood. In a single article? Maybe that's true, in a single article. But I think it's probably fairly rare to see both liters and milliliters in one article. --Trovatore (talk) 21:04, 29 April 2018 (UTC)
Perhaps it was who misunderstood the intent. I would not support any change that permitted "1 L is 1000 ml". That would be bizarre. Dondervogel 2 (talk) 21:20, 29 April 2018 (UTC)
Well, you'd probably find that construction only in an article on units or volumes or some such, not as a "natural" occurrence. I don't think the MoS needs to get so specific about something that's only going to happen in a couple articles. --Trovatore (talk) 21:23, 29 April 2018 (UTC)
I found an interesting example in Oxygenation: "Dissolved oxygen (DO) is measured in standard solution units such as millilitres O2 per liter (ml/L)". It even mixes UK and US English, but let's focus on the unit symbol, for which my preference is mL/L, with ml/l second and the present form (ml/L) a big no no. What do others think? Dondervogel 2 (talk) 21:30, 29 April 2018 (UTC)
(ec) I prefer "ml/l", personally. Maybe, EEng's wording but add but do not mix units using "L" and units using "l" in the same article? Kahastoktalk21:36, 29 April 2018 (UTC)
I don't think we should necessarily be forcing "mL" to be consistent with "L" in circumstances where "ml" is more common - and it appears to me that that is what this change will do. Better to leave it with EEng's wording. Kahastoktalk21:28, 29 April 2018 (UTC)
I think that suggesting a preference between or rationale for 'l' and 'L' would be MoS overreach. I'd use only the last sentence in EEng's suggestion. —Quondum14:06, 30 April 2018 (UTC)
The purpose of MOS is to ensure consistency within and between articles. I don't see any scope creep in expressing a preference. Where's the overreach? Dondervogel 2 (talk) 14:28, 30 April 2018 (UTC)
If we prefer 'L' versus 'l', given the regional association, we would have to revisit WP:ENGVAR. Do you have the stomach for that? Besides, 'L' looks alien and smacks of illiteracy in countries where the upper-case version is essentially absent. Do we wand WP to be international, or American with a tip of the hat to the rest of the world? I do not see any problem that needs solving that badly. —Quondum17:02, 30 April 2018 (UTC)
As I have stated elsewhere in this page, ENGVAR is (IMAO) irrelevant because the reason for preferring "L" over "l" is not a regional one, but a simple, practical, and encyclopaedic one. The MOS states a preference for all kinds of other unit symbols (kbit/s, cu ft, nmi, kn to name but a few), all of which are likely to be encountered more in one region than another but it matters that we do not CHOOSE them for that reason. Dondervogel 2 (talk) 18:10, 30 April 2018 (UTC)
In response to EEng's recent reminder: I kinda like it as it stands, without change: informative, possibly even suggestive, but clearly leaving discretion to the editor. When it comes to "preferable", there are so many factors involved that IMO it cannot sensibly be distilled into a clear recommendation. —Quondum21:14, 1 May 2018 (UTC)
Yes, all that writing it out in full will do is to generate edit wars over "litre" vs. "liter". I regularly squash these by changing to the abbreviation. Peter coxhead (talk) 06:28, 28 April 2018 (UTC)
Not quite a non-starter. WP:ENGVAR and WP:RETAIN say the article should consistently use only a single variation of English. If the article already uses 'colour' and 'metre' then it should use 'litre' and not 'liter'. And of course the converse is true for American English. If it hasn't decided which variation to use and has no close ties to any variation then first comes, wins. After that, change is restricted by WP:RETAIN. Personally, I prefer the full word over the abbreviation (even with the American ending) but the choice should be there. Stepho talk06:42, 28 April 2018 (UTC)
Yes, but in a scientific article, editors argue that the SI form should be used regardless of the spelling of non-technical words (just as I would write "hard disk" not "hard disc" in a computing context in an article otherwise in British English). So WP:ENGVAR and WP:RETAIN don't work to suppress serious edit warriors (the argument is more usually over "metre" / "meter", but the principle applies). WP:COMMONALITY supports the abbreviations. Peter coxhead (talk) 06:51, 28 April 2018 (UTC)
Engvar is irrelevant here. The point is that "L" is a symbol universally understood to mean litre, liter, litro, lítri or any other spelling you can imagine. I see no convincing arguments for not using it in all articles, given the risks of misinterpreting "l". Dondervogel 2 (talk) 07:19, 28 April 2018 (UTC)
Woah Nelly! You've taken my words and bolted off into the sunset. There's a guide somewhere that says scientific articles should use SI - which I agree with. Non-scientific articles currently still get the choice of 'l', 'L', 'litre' or 'liter'. I'm only suggesting that an outright ban on 'litre' and 'liter' isn't necessary. I've certainly had my share of US vs UK spelling issues but perseverance usually pays off against the 'everybody should use my spelling' edit warriors if you are following the rules. Nevertheless, the 'L' fall back is handy if the edit warrior is just as stubborn. Stepho talk07:44, 28 April 2018 (UTC)
This thread started as an argument to spell out the word in full rather than use the abbreviation. I'm strongly in favour of using the abbreviation, although I prefer "l". The argument that it looks too much like a "1" is less valid when properly spaced: "15l" is problematic; "15 l" less so. Peter coxhead (talk) 07:36, 28 April 2018 (UTC)
I think the lowercase sans-serif ell is problematic even when spaced. Even if you work out that it's not a numeral one, it could still be an uppercase eye. (I think there's a discussion somewhere on talk:Iago where someone thought we were rendering the villain's name as "lago", as in Italian for "lake".) This is one of the reasons I frankly wish we would change to use serif everywhere, but of course I understand that's a hopeless dream. --Trovatore (talk) 20:30, 28 April 2018 (UTC)
Typographical alternative
Perhaps "L" is preferable to "l" when standing alone, but to me "mL" looks weird, and "ML" is Local magnitude scale. As the core issue is "easily mistaken for the digit 1" (ever since typewriters didn't come one with a "1" key), perhaps a better approach would be to deal with the underlying typographical issue by forcing "l" into a more distinct typeface, such as this: "l". This could be done with a template, which, when given a value, would also add a non-breaking space. ♦ J. Johnson (JJ) (talk) 21:35, 29 April 2018 (UTC)
1953-1957 model You have to go back a long way to find a usable Smith Corona without a usable one-exclamation key! Has anyone heard of ASR 33s?--ClemRutter (talk) 20:29, 30 April 2018 (UTC)
Oh yes, I have heard of ASR 33s. Though what I was using might have been a 35.
That typewriter is "coral". The ones I have in mind were mostly black, and about twice as high. And plenty of them kicking around through the 70s. ♦ J. Johnson (JJ) (talk) 23:34, 30 April 2018 (UTC)
This Underwood has no "1" key
I think the bigger issue is that it's hard to distinguish lowercase ell from uppercase eye. At least in the sans-serif typefaces we seem to be stuck with. --Trovatore (talk) 21:16, 30 April 2018 (UTC)
Can you provide an example in a WP (real or hypothetical) article where such ambiguity would not be almost transparently resolved by context? —Quondum21:30, 30 April 2018 (UTC)
Let's suppose that you're analyzing a circuit meant to control the flow of water. Then 2 l is two liters of water, but 2 I is twice the current.
I'm not saying the reader can't work it out, of course. But ideally we prefer not to give readers puzzles when we don't have to. --Trovatore (talk) 21:37, 30 April 2018 (UTC)
I don't find this convincing enough: the quantity being measured is usually clear: putting "2 l" next to a wire in a circuit begs to be misinterpreted. We annotate by saying "volume: 2 l" or similar. The MoS routinely advises revising for region-neutral and unambiguous grammar and expressions generally. We avoid letting readers puzzle it out, yes, by choosing ways to express things that are unambiguous. The editor is free to use "2 L" here; no need to recommend "L" in all cases just because there might be a risk that no editors notice and fix the ambiguity. To introduce a WP-wide recommendation that is meant to address examples that have yet to be observed looks too much like a solution looking for a problem to solve. —Quondum22:27, 30 April 2018 (UTC)
I think "l" (using <kbd>) works, and is considered sans-serif. (Quasi-serif?) Which shows that the problem is not the lack of serifs, but simply poor shape of the character. Perhaps we could agitate for replacing the "l" characters in the sans-serif typefaces? ♦ J. Johnson (JJ) (talk) 23:44, 30 April 2018 (UTC)
I understand that the kbd tags normally result in a monospace font on the English Wikipedia. On my computer, it shows as Courier, which is a slab serif monospace font. However, the font is chosen by the web browser, so some users will see a different font; perhaps some of them will see sans serif monospace fonts, such as Monaco or Lucida Sans Typewriter. WhatamIdoing (talk) 07:29, 7 May 2018 (UTC)
To the extent the problem of confusing glyphs is endemic across many Latin typefaces: perhaps Wikipedia is a force sufficient to initiate a forward reaching change? Hmmm, that might almost get somewhere. Maybe. ♦ J. Johnson (JJ) (talk) 21:28, 7 May 2018 (UTC)
FWIW, I recently wrote a paper where a referee had trouble confusing lower case el with the numeral 1 and totally misunderstood the significance of an equation. I solved the problem by using lower case cursive el (ℓ), Unicode Hex 2113. Finding that character, however, is probably too difficult to be a general solution. --SteveMcCluskey (talk) 21:45, 14 May 2018 (UTC)
Amusing aside
I spot checked a bottle of bourbon on my shelf, and it said it was "750 ML", which should be enough for everyone on the planet to have a good stiff double. --Trovatore (talk) 00:31, 28 April 2018 (UTC)
I don't find any of this the slightest bit amusing. Having been around during the metrication and decimaisation debates in the 1970, and then having implemented the decisions in schools, and enforcement agencies on local councils there is one correct form - the lower case 'l' which is written with a loop in cursive handwriting. Go into any Walmart (Asda) and Aldi, Tescos,and, by law the products must be marked up with a lower case 'l'. In the EU and any country that trades with the EU. It is done this way to give exporters a compatible system across the 28. A little joke about a couterfeit whisky does not mean that Wikipedia should veer away from international norms and standards. We follow referenced standards not invent our own ClemRutter (talk) 19:53, 30 April 2018 (UTC)
OK, first of all, I have to object to both Martin's and Clem's aspersions on American bourbon whiskey. I appreciate the variety of single-malt Scotch whiskies myself, but they are a different thing. If you aren't familiar with bourbon, and you insist on evaluating it as though it were Scotch, of course you aren't going to think it's a very good Scotch, but that's a completely meaningless test.
Clem, EU regulations on trade are not dispositive at Wikipedia. In science, for example, my impression is that the curly ell is almost unknown, and the uppercase L is most common even when talking about milliliters. But Wikipedia is many things to many people. Sometimes we're talking about trade, sometimes about science, sometimes about other things. That's why my first reaction was that MoS should just stay out of it, though I'm forced to recognize that the lowercase sans-serif ell, standing alone, is problematic. --Trovatore (talk) 21:08, 30 April 2018 (UTC)
"the uppercase L is most common" – only in the US. As a worldwide generalization, I'd suggest that this might not be accurate. —Quondum22:31, 30 April 2018 (UTC)
If that is an offer- I am more than happy to evaluate as much rye whiskey and you would care to send me. I will pick the crates up at Wikimedia UK London Office if that helps- I am sure that one or two bottles may get to me unopened, and there is always a warm welcome to hop over the ditch and visit. Now onto the difficuly we are having with typesetting. I assure you that an upper case 'ĺ' is never-ever used as a unit of volume. That was settled with Metrication in the United Kingdom in the sixties, the metric system and with it, its abbreviations became enshrined in the EU accession treaty in 1973, and in the school syllabus in with the National curriculum which is obligatory. https://www.gov.uk/guidance/packaged-goods-weights-and-measures-regulations#units-of-measurement. I know never is a strong word, but in the UK a student would miss their university place if they started making up an abbreviation for litre. Given time any secondary teacher will be able to quote the reference.
In Europe and the EU 28 this is centrally defined. Looking at SI unit: And the paper:National Institute of Standards and Technology Special Publication 330, 2008 Edition Natl. Inst. Stand. Technol. Spec. Pub. 330, 2008 Ed., 96 pages (March 2008) CODEN: NSPUE2 Appendix 1, p55 defines derived units .(the litre is a cubic decimetre) . Note that this is a Commerce department document- not a science paper
::::[Principles
::::Roman (upright) type, in general lower-case, is used for symbols of units; if, however, the symbols are derived from proper names, capital roman type is used. These ::::symbols are not followed by a full stop.
::::In numbers, the comma (French practice) or the dot (British practice) is used only to separate the integral part of numbers from the decimal part. 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.
::::l-liter
Page 39 gives the footnote that explains that the symbol for litre has been is the lower case l- since 1879 but an alternative symbol was allowed in 1979:
(f) The liter, and the symbol lower-case l, were adopted by the CIPM in 1879 (PV, 1879, 41). The alternative symbol, capital L, was adopted by the 16th CGPM (1979, Resolution 6; CR, 101 and Metrologia, 1980, 16, 56-57) in order to avoid the risk of confusion between the letter l (el) and the numeral 1 (one). Editors’ note: Since the preferred unit symbol for the liter in the United States is L, only L is given in the table; see the Federal Register notice of July 28, 1998, “Metric System of Measurement: Interpretation of the International System of Units for the United States” (FR 40334-4030).
I am not aware that the relaxation made it int EU law, education or common use.
I don't see anyone arguing for governments (or standards) to prevail. A central point: that the onus is on showing that a MoS guideline is needed on preferring anything. Demonstration of such a need has been singularly lacking on this page. Consider the principle that unneeded rules are to be avoided. —Quondum12:43, 1 May 2018 (UTC)
I concur. Storm in a tea cup- just a nagging doubt that decision are being proposed on personal experience rather than verifiable factClemRutter (talk) 18:50, 1 May 2018 (UTC)
It was in fact my first instinct that MoS didn't need to say anything, and I won't mind too much if that's the outcome. Just the same, the discussion has made it clear to me that l is problematic in the existing typefaces. I won't go looking for it, but I may well correct it if I come across it. --Trovatore (talk) 19:01, 1 May 2018 (UTC)
I can live with ml/l and mL/L (preferring the latter) but consider ml/L to be completely unacceptable. Arguing for change here is pointless, so I'll fix the offending article instead. Dondervogel 2 (talk) 08:17, 2 May 2018 (UTC)
Those are the SI's own principles for writing SI unit symbols, as documented in Appendix 1 of NIST's 'Special Publication 330' (linked above - see p55). Dondervogel 2 (talk) 12:19, 7 May 2018 (UTC)
The original French is a bit less clumsy, e.g. "en caractères romains, en général minuscules" rather than "Roman (upright) type, in general lower-case".
"Les symboles des unités sont exprimés en caractères romains, en général minuscules ; toutefois, si les symboles sont dérivés de noms propres, les caractères romains majuscules sont utilisés. Ces symboles ne sont pas suivis d'un point.
"Dans les nombres, la virgule (usage français) ou le point (usage britannique) sont utilisés seulement pour séparer la partie entière des nombres de leur partie décimale. Pour faciliter la lecture, les nombres peuvent être partagés en tranches de trois chiffres : ces tranches ne sont jamais séparées par des points, ni par des virgules." (Résolution 7 de la 9e CGPM (1948)[13]
Rather than reverting a second time, EEng, I might as well just mention that—beyond the rationale stated in my edit summary about conforming the longform usage of {{floruit}} with the longform usage of {{circa}} immediately above it—there are actually 1,418 transclusions of the {{floruit}} template on the English Wikipedia at this time, which is nearly 2.5 (~2.48) times more common than the current 499 transclusions of {{fl.}}. (Meanwhile, therearezero for the other three redirects.) So, contrary to your edit summary, the longform usage is actually used very frequently.
I don't particularly care which is mentioned, though. This is both too pedantic and too insignificant an issue to dispute. I was just trying to ensure the more common one (which also conformed with other template usage in the section) was stated, especially since it eliminates a needless redirect for anyone clicking on the link. I do want to note this information, however, in the event that it is mistaken that {{fl.}} is at all the more common transclusion. With that stated, I will leave it up to you and anyone else reading this to decide which template usage to mention. I'll go back to my usual editing.
Your stats don't take account of uses of fl. vs. (that's short for versus) floruit which aren't via transclusion i.e. (that's short for id est) instances simply in plain text. I'd be very surprised if a complete count didn't tip heavily toward the abbreviated form. I certainly don't mind listing both forms, but offering just the long-form template makes little sense. EEng15:47, 22 March 2018 (UTC)
Both, the aim of the encyclopaedia is to inform readers (WP:RF). Many readers will not know that fl. -> floruit, a fair number will assume that fl. -> flourished (which the MOS explanation mentions). If you use the conventional abbreviation then that suits everyone whereas forcing them to check up on the full Latin word can be a pain. Consistency is nice, but not at the expense of clarity. Martin of Sheffield (talk) 15:58, 22 March 2018 (UTC)
I can't tell what you're recommending. I'm the last person to urge consistency for its own sake. EEng17:05, 22 March 2018 (UTC)
Yes. We shouldn't encourage people to pepper the encyclopedia with Latin when they can use an abbreviation which works fine in both English and Latin. Clarity and simplicity in articles trumps a trivial increase in consistency in the MOS. The MOS's sole purpose is to improve the encyclopedia. 92.19.30.54 (talk) 18:59, 28 March 2018 (UTC)
It's normal in English to use the abbreviation, not the full word. It's also normal on WP to have templates at "transparent" names not abbreviated ones, though this sort of thing could easily be an exception. We don't need two templates for this, but a redirect. I agree with the sentiment that the advice should be consistent. If we recommend a template or redir named "circa", recommend one name "floruit"; if we recommend one named "fl.", recommend one named "c." Though I will ride one of my "high hobby horses" again (if I may mix metaphors), and remind people that "ca." is very common in real English, and is a better option for MoS to recommend, because "c." is an abbreviation for other things and has been since at least the 19th c. (not c. the 19th c.). — SMcCandlish☏¢ 😼 02:10, 19 May 2018 (UTC)
The regnal calendar ("nth year of the reign of King X", etc.) is used in many official British government and legal documents of historical interest, notably parliamentary statutes and also historically parliamentary sessions. It may be that the sources used by a Wikipedia editor will use the regnal calendar. I suggest that a subsection is added to the section "Dates, months and years" of this guideline, stating that if regnal years are used the year or year range in the appropriate Julian (prior to 1752) or Gregorian calendar is appended in parenthesis.
The reason for doing this is because most people have no idea which year for example is Elisabeth I, 10 (November 1568–November 1569); and mentioning the article "Regnal years of English monarchs" here will inform editors where they can go to get the information do the conversion.
Unless Regnal years of English monarchs is taken essentially fact-for-fact from a systematic source making essentially the same presentation, I fear it may contain a great deal of WP:OR.
Even getting past that, for sure taking a source's reference to a regnal year and translating it for modern readers is OR. Anyway, I don't see the use case for this under our other policies. What reliable secondary source, of the kind we use for fact content in articles, dates something via regnal year only, so that we have to translate it ourselves? We don't source articles to Roger of Wendover.
See the cited chapter in Sweet & Maxwell [[15]] for an introduction and table which supports the Wiki page.
For a usage example see Weights and Measures Acts (UK), indeed every article citing an English/British/UK Act of Parliament ought to have a reference like this.
Is converting a source's format for modern reads OR? By analogy a statement such as: "The Low Main lies 94 fathoms (564 ft; 172 m) below the surface and is 3 feet (0.91 m) thick." might be held to be OR, and yet the {{convert}} template is built to do just that. Where I do agree with EEng is that I don't see a need to add this to the MOS. Unless there is a dispute over the best way to convert regnal years to historic years we should let knowledgeable wiki editors get on with the job unhindered by instruction creep. Martin of Sheffield (talk) 12:45, 30 May 2018 (UTC)
"case for this under our other policies". This is not discussion about changing policy, but guidance in a guideline. The reason for mentioning both the start of year with Julian dates (MOS:OSNS) and seasons (MOS:SEASON), is for exactly the same sort of reasons (the latter came up because of confusion with seasons during the Falklands War). In both cases "knowledgeable wiki editors" do not need the advise, it is aimed at those who either do not know (as in the start of year) or did not think it through (as in season). This process is exempt from OR as is doing simple maths, calculating someone's age, or converting one measurement into another (WP:CALC). -- PBS (talk) 18:22, 30 May 2018 (UTC)
The problem with guidance and guidelines (sentence 2 of MOS starts "This is the primary page for the style guidelines:" [my emphasis]) is that some people will use them as if they were mandatory and start interminable arguments about them. Better to leave it out unless there is a perceived problem that can't easily be resolved on the talk pages of the article concerned. Martin of Sheffield (talk) 19:55, 30 May 2018 (UTC)
Yes, we don't need to add more line-items without a real need for them. But what you said before that has correlation/causation inclarity. It's not something being called "guideline" or "guidance" that causes disputes. It's editors who do not want to follow a particular piece of guidance who do that. Even if they bother to read WP:P&G's "Editors should attempt to follow guidelines, though they are best treated with common sense, and occasional exceptions may apply" all take away is "I get an exception!" (because they have also not absorbed WP:WIARM: "must justify how their [WP:IARs] improve the encyclopedia" and "Most of the rules are derived from a lot of thoughtful experience and exist for pretty good reasons; they should therefore only be broken for good reasons." Feeling incorrectly that policy is on their side, their "MoS is only a guideline and there's no policy against what I want to do" crap starts, and there's your interminable dispute. Actually, most of them are short-lived (and settled in the favor of the guidelines); that's not the issue. It's the frequent recurrence of the same style-quirk demand over and over again, either from a tendentious party, or from random people who can't yet understand why they shouldn't write here like they learned to in 10th grade in 1989, or like their boss tells them to at work.
The source of actually interminable style conflicts is MoS making a pseudo-rule like "do A or B, per editorial discretion at the article" (or us knowing there's a perennial dispute but neglecting to account for it in MoS at all). This is guaranteed to lead to repeated disputes at many pages for no good reason, until the un-rule (or lack of one) is replaced with a single instruction. — SMcCandlish☏¢ 😼 10:17, 6 June 2018 (UTC)
There is no nothing like what WP:CALC contemplates: Routine calculations do not count as original research, provided there is consensus among editors that the result of the calculation is obvious, correct, and a meaningful reflection of the sources. Basic arithmetic, such as adding numbers, converting units, or calculating a person's age are some examples of routine calculations. Using the regnal-years table, which has 14 footnotes along the lines of:
Henry VI was deposed by Edward IV on 4 March 1461, officially bringing his reign and last regnal year to a close. However, Henry VI briefly recovered the throne in 1470–1471, so he has an extra regnal year, dated from 9 October 1470 to c. April 1471, and referred to as the 49th year ("Anno ab inchoatione regni nostri") or 1st year of restoration ("Readeptionis nostrae regiae potestatis"). Henry VI's "restoration" year does not mar the continuity of Edward IV's regnal years – Edward IV's 10th Year is counted unbroken as beginning from 4 March 1470 and ending 3 March 1471, his 11th year beginning 4 March 1471, etc.
And that's before we fold in the issue of civil vs. historical years. A process that even sometimes involves considerations like that cannot be called a "calculation" which is "obvious". But I'm back to the question of use case. Are we building article content from sources so old that they give dates in regnal form? Do we really consider those reliable sources? An article on the history of weights-and-measures legislation should draw on modern sources discussing that history, not cobble together way-old sources from all over the map. EEng18:58, 30 May 2018 (UTC)
But that's exactly why the page cites Sweet & Maxwell for authority. And what is easier that looking up one line in a table? BTW, old != unreliable any more than new == better! That way leads to journalism rather than encyclopaedic work. Martin of Sheffield (talk) 20:02, 30 May 2018 (UTC)
It seems to me EEng that you are playing devils advocate and that you do not hold a strong opinion on this: "And that's before we fold in the issue of civil vs. historical years." That is precisely what is covered in this guideline by MOS:OSNS. WP:CALC (part of the OR policy) includes the phrase "or calculating a person's age are some examples of routine calculations." Using the "Regnal years of English monarchs" it is no more complicated to calculate the year using a modern format than it is calculating the age of a person. Martin of Sheffield if someone has written an article where the secondary source mentions in passing that such and such an act influenced the outcome (but does not date the act), if that act is found in a list of acts listed by regnal years, then I do think that if the regnal date is added then at least a conversion to the familiar format ought to be added as well, and guidance here on how to do that is I think desirable, just as it is for Old Style/New Style OSNS dates. If someone then runs AWB to add familiar dates to such entries then all to the good. -- PBS (talk) 14:41, 2 June 2018 (UTC)
looking up one line in a table??? 49 Henry VI was when, exactly? – be sure to read the footnotes! Look, make a table with Regnal years, or ranges of them, on the left, and the corresponding calendar year range X–X+1, on the right (something like [16]) and then I'll call it looking up one line in a table. But you can collapse the "inside" years of most reigns via formulas showing how to compute X=Y+REGNALYEAR. There will still need to be some notes about OS/NS, of course, but you can never avoid that. The current table takes skill to apply. EEng19:38, 2 June 2018 (UTC)
Well to be pedantic, two lines I suppose. The footnote only explains the de facto limits; 9/10/70 - ?/4/71 is a subset of the theoretical 1/9/70 - 31/8/71. Calling either the full year or the subset as 49 Henry VI satisfies your equation where Y=1421: 1470 = 1421 + 49. I also fail to see how introducing the Roman calendar aids any understanding in this matter. Martin of Sheffield (talk) 20:09, 2 June 2018 (UTC)
There is already a Template:British regnal year that uses a Lula module to convert Julian/Gregorian years to regnal ones:
I have used that year to demonstrate how the template handles anomalies. I have asked on the template talk page if it is possible to add an inversion so that if a Julian/Gregorian regnal year is put in it will display the regnal Julian/Gregorian years. -- PBS (talk) 22:26, 5 June 2018 (UTC)
Yep. When I started reading the thread I was going to suggest this could be automated, and here we are. If there are any cases where the reverse-calculated results could have OR in them (e.g. because of historical "who's actually in charge of this country, again?" matters used as illustrations above, perhaps have the template output nothing, or a just a red notice that it doesn't have reliable output for this case. That said, output like "1649 24 Cha. 1 – 1 Cha. 2" needs punctuation of some kind, since it's not easily parseable without it by anyone not already familiar with the system. Maybe "1649, 24 Cha. 1 – 1 Cha. 2" or "1649 (24 Cha. 1 – 1 Cha. 2)". Not sure I care. — SMcCandlish☏¢ 😼 09:36, 6 June 2018 (UTC)
OK then we seem to have a consensus. Once a template where a regnal year is entered and a Julian/Gregorian years are displayed is written, and the display format agreed, then we will add something to this guideline. Until then lets adjourn. -- PBS (talk) 20:42, 7 June 2018 (UTC)
Abbreviation for astronomical unit once again
Au (mixed case, initial cap) is the symbol for gold
I am raising, once again, the issue that au (not AU) should be used as the abbreviation for astronomical unit. It has been discussed both here and on the talk page for Astronomical unit. About five years ago I recommended allowing both abbreviations to be used in the article on the Astronomical unit until the issue was sorted out by appropriate defining authorities. At that time the situation stood as follows:
The 2012 IAU RESOLUTION B2 on the re-definition of the astronomical unit of length, recommends "that the unique symbol “au” be used for the astronomical unit." It looks like we've got a difference between the IAU (2012) recommendation and the BIPM (2006) report. I suspect the BIPM and the IAU will sort this out, but for the moment we probably should let both stand with the more recent IAU recommendation getting some priority. --SteveMcCluskey (talk) 17:43, 11 May 2013 (UTC)
Since that time, the situation has changed. The 2014 Supplement to the eighth edition of the BIPM brochure on The International System of Units and the draft ninth edition (forthcoming 2019) recommended the symbol au in both English and French texts, citing IAU resolution B2, 2012 which recommends "that the unique symbol 'au' be used for the astronomical unit." National organizations such as the American Astronomical Society and the Royal Astronomical Society also recommend the use of au in their publications, the AJ, ApJ, and MNRAS. Given this agreement among the authoritative international organization on weights and measures and the primary national and international organizations on astronomy, Wikipedia should follow suit by changing its Manual of Style to reflect accepted practice. --SteveMcCluskey (talk) 20:00, 9 May 2018 (UTC)
The symbol preferred by ISO 80000 is ua, possibly to avoid a clash with the symbol au to mean attodalton. Whatever the reason there seems to be no strong consensus amongst standards bodies, so I think we should make a choice and stand by that choice. Has that much changed since we chose AU in 2015? Dondervogel 2 (talk) 23:06, 9 May 2018 (UTC)
Dondervogel, you are terribly wrong! I cite the Wikipedia page itself:
In 2006, the International Bureau of Weights and Measures (BIPM) recommended ua as the symbol for the unit. In the non-normative Annex C to ISO 80000-3 (2006), the symbol of the astronomical unit is "ua".
You cannot use a decision of 2006 to overthrow a decision of 2012-2014! Especially since is a non-normative annex! You have to follow the last decision! And as a member of the Astronomical Community, I would like that Wikipedia considers more important the decision of IAU than the opinion of an user! Or does it need a letter from IAU? (I know several person there, but also the president because he was the President of my MSc thesis Committee) SkZ (talk) 21:25, 13 May 2018 (UTC)
@Dondervogel 2: suggested above that the use of "ua" in ISO 80000 was "possibly to avoid a clash with the symbol au to mean attodalton." Lacking any citation to support this hypothesis, it is much more reasonable -- and relevant to our discussion -- that the ISO was following the then current standard set by the BIPM, which in the eighth edition of its The International System of Units (SI) (2006) favored "ua" as the symbol for unité astronomique. This also suggests that since the ISO was following BIPM practice in its 2006 revision, it will follow current BIPM / IAU practice in it forthcoming revision. --SteveMcCluskey (talk) 02:22, 14 May 2018 (UTC)
All we know for sure is that the current (2006) ISO standard favours ua and the current (2014) BIPM standard favours au. ISO TC12 is presently developing a final draft (FDIS) of ISO 80000-3, which means that it is highly likely to be updated shortly. There are five things that can happen, in (my perception of) order of decreasing likelihood:
the FDIS is approved, and makes no statement about the astronomical unit;
the FDIS is approved, and switches to au, following BIPM;
the FDIS is approved, and continues to use ua;
the FDIS is not approved and ISO 80000-3:2006 remains current;
the FDIS is approved, and switches to some other symbol for this unit.
When the choice of AU was made, it was the worst out of the 3 available (either ua or au would have been better), but I supported AU because it achieved uniformity across Wikipedia. In my opinion we should wait for TC 12 to take its course. In the two most likely scenarios, the de facto international standard becomes au. If it comes out in favour of au we should definitely adopt that symbol, but what if it doesn't? Right now I do not support any change based on speculation. Instead we should wait until TC 12 either publishes or withdraws the draft standard presently under development. Dondervogel 2 (talk) 06:49, 14 May 2018 (UTC)
We also know
the draft has reached stage 40.99; it has been published as a DIS and approved for registration as an FDIS. It is available for purchase now but is expensive.[18]
the committee has a virtual meeting next week, 23 May 2018, and provisionally will meet in Helsinki in October.[19]
But does that matter, given that ISO tends to follow BIPM and Wikipedia is bound by neither? Can we move instead to considering what's actually in use, per Wikipedia's general principles and the specific 2015 close that the "issue can always be revisited at a later date if the IAU preferred "au" version becomes the more widely adopted unit symbol in the literature"? 92.19.29.193 (talk) 12:23, 14 May 2018 (UTC)
Proposed draft
#1 Proposal to allow au or AU
Rather than discussing an abstraction, I'll propose a specific change for the table, drawing on the discussion to date:
au is recomended by the BIPM[1] and the IAU,[2] and is called for in the publications of the AAS (AJ and ApJ)[3] and the RAS (MNRAS)[4]. AU is a commonly used symbol for this unit, both in popular and professional articles.
References
^Cite error: The named reference SI Brochure was invoked but never defined (see the help page).
Oppose: MoS is not an article and does not cite sources, for any reason other than clarification or reference to additional reading (e.g., MOS:ACCESS has references to various accessibility specs, because their detailed technical stuff that people who want to work on it here should be familiar with and which an MoS page should not regurgitate). And WP is not an advocacy platform of any kind, especially over a tiny bits of style trivia, most especially never in the furtherance of some internecine bickering between a field's institutions for which one has longer authoritativeness junk to wave. Furthermore, more times we say "do A or do B" we are making a mistake, and failing as a style guide, and setting up future pointless disputes. We should never, ever do this, unless there's a site-wide completely failure, repeatedly, to come to consensus on something after wide editorial input. This little matter generally has no input from much of anyone but people in astronomy or a closely related field, who favor this organization's specs versus that one's. — SMcCandlish☏¢ 😼 02:23, 19 May 2018 (UTC)
#2 Proposal discussing options au and AU
Here is a revision which indicates the preferred option, responding to the discussions below:
The preferred option au is recomended by the BIPM[1] and the IAU,[2] and is called for in the publications of the AAS (AJ and ApJ)[3] and the RAS (MNRAS)[4]. AU remains an acceptable option as it is a commonly used symbol in both popular and professional articles.
References
^Cite error: The named reference SI Brochure was invoked but never defined (see the help page).
The preferred option is au. An alternative is AU. Articles that already use AU may choose to switch to au or continue to use AU.
I prefer this wording because it makes it clear au is preferred, permitting AU during the transition (to au) but not promoting it. Also, we do not normally include the reason for our choices in mosnum. I think this is to keep it short. Dondervogel 2 (talk) 18:31, 16 May 2018 (UTC)
The ISQ is a system of quantities, not units. It does not prefer ua. A non-normative appendix in a standard that describes part of the ISQ uses ua. That's all. 92.19.29.193 (talk) 21:38, 14 May 2018 (UTC)
I was using the term "ISQ" as a shorthand for ISO/IEC 80000 Quantities and Units, which is about units as well as quantities. I have now spelt it out in full. How can we be sure the same informative annex will not find it's way into the 2018 (or 2019) revision? Dondervogel 2 (talk) 21:54, 14 May 2018 (UTC)
In view of the questions about what is actual use, I did a very quick search of recent articles in the Astrophysics Data System: Four of the first five articles I could download from Arxiv (to be published this year in AJ Letters, ApJ, and MNRAS) used AU, one (forthcoming in Astronomy and Astrophysics) used au. Since these are preprints, I can't confirm what they will look like after going through the formal editing, but it does indicate that authors submitting papers to AJ Letters, ApJ, and MNRAS still use AU, despite the style guides calling for au. It seems our draft using both AU and au reflects current usage. --SteveMcCluskey (talk) 15:06, 15 May 2018 (UTC)
I have checked articles from MNRAS, A&A, Icarus (all European journals), and there the published articles that I have read use au. In Nature AU, in ApJ and AJ (US journal) I have found AU or au (but more au in the more recent ones) SkZ (talk) 02:42, 6 June 2018 (UTC)
The ayes 'n the nays
Ayes
Support: As drafter, I support this proposal. In view of the growing support of the form au, I had considered making it au only, but in view of the comments in the discussion of the traditional long-term use of AU, I am willing to concede some value to that form. On the other hand, the old usage of ua, which has been deprecated on this page since this edit by Dondervogel 2, has now been abandoned by the BIPM and is only supported by the ISO, does not seem relevant to this proposal. --SteveMcCluskey (talk) 21:11, 14 May 2018 (UTC)
Version 3 looks good to me but to avoid confusion shouldn't we keep AU as an acceptable option in the "symbol" column. as it is the "comment" column contradicts the "symbol" column. --SteveMcCluskey (talk) 20:35, 16 May 2018 (UTC)
In light of the discussion to date, I'd say we should go with one of the versions supporting au. In order of preference, I find Version 3 or Version 4 acceptable. I believe all the participants in this discussion have had their views heard and it's time to close. --SteveMcCluskey (talk) 13:55, 22 May 2018 (UTC)
As a active member of the Astronomical Community, and official member of the Chilean Astronomical Community (I still didn't sent the recuest for the IAU membership in time for the IAU General Assembly in August) and as an university professor I support this proposal in the more strict version of using just au in Wikipedia. I don't care what Wikipedia users and no astronomers think, we decided a standard and you have to respect that standard. You have no right to decide astronomical standard. SkZ (talk) 20:41, 18 May 2018 (UTC)
Nays
Oppose: I'm open to persuasion if someone has a good answer to my question. In the meantime my preference is to wait until ISO 80000-3 is updated or the FDIS is withdrawn. I don't see the point of making this or any other change before then. Dondervogel 2 (talk) 18:31, 14 May 2018 (UTC)
Reply: I would not have opened a discussion of a change, were it not for the fact that the current version deprecates the use of the form au, which has been approved by the two leading scientific standards organizations in the appropriate disciplines, the BIPM and the IAU. That discrepancy clearly calls for making a change now. ISO's present support for the symbol ua, which you yourself added to the list of deprecated symbols, is irrelevant to this proposal. --SteveMcCluskey (talk) 21:25, 14 May 2018 (UTC)
Look, let’s face it – AU was a mediocre choice in 2015 and it remains a mediocre choice now. I supported it only to ensure WP-wide uniformity. I can see myself supporting a change that leads to uniform adoption of au, but not one leading to a mix of au and AU. Dondervogel 2 (talk) 22:14, 14 May 2018 (UTC)
I see your point; you want to establish a single standard usage for Wikipedia. In most cases, I would agree but for astronomical unit we are in a period of flux where standards bodies increasingly favor the usage au but practice (being conservative by nature) still favors AU. In such a time of flux (which may last for several decades) it seems reasonable to adocate the new standard but to allow the older form as an option. Would you, as someone who has worked on this page for some time, see a way to expand on the discussion of options in the lead to provide a preferred (au) and acceptable (AU) symbol for astronomical unit.--SteveMcCluskey (talk) 02:44, 16 May 2018 (UTC)
I see this choice as similar to the one made between Mbps and Mbit/s for the megabit per second. At the time that choice was made it was very common, and as far as I know remains common, to use Mbps, while standards bodies recommend Mbit/s. If we want the symbol to instantly recognizable but ambiguous, we would have adopted Mbps. Instead there was a preference for a symbol that was less recognizable (because it was not in widespread use) but unambiguous, namely Mbit/s. Here are faced with the familiar but ambiguous AU against the less familiar but unambiguous au. The answer to your question is that I would support a form of words that made clear au is preferred, while not deprecating. That would create a climate in which a transition from AU to au could start. Dondervogel 2 (talk)
It confuses discussion when you change text already commented on. Please just strike out your old proposal above and give your new proposal here. EEng14:17, 16 May 2018 (UTC)
I don't buy that argument at all. "Mbit/s" is not "less recognizable", but more. Recognizability has as much to do with lack of ambiguity and with parsing speed and accuracy as it does with prior familiarity with the string. Anyone with a linguistics background knows this (as does anyone with a machine-learning one, or a cognitive science one). "Mbit/s" may be a less common exact text string by some margin than "Mbps", but it's closer to plain English and much less ambiguous. If you lined up 100 people and asked them what one string means, and another 100 got that question for the other string, far more of them would correctly supply "megabits per second" as the answer when fed "Mbit/s". What we have here it the exact opposite case, where we're being asked to support the extremely unintuitive (in English) "ua", which nearly no one outside astronomy circles will have seen before (or will remember later– it's anti-mnemonic in this language). — SMcCandlish☏¢ 😼 02:42, 19 May 2018 (UTC)
Not a rational option (I mean #3; I'm not sure if this comments section is for that or for all of them; I opposed the other two for different reasons, above). "Articles that already use AU may choose ..."? When did our articles achieve sentience? I take a tiny wikibreak and miss the entire AI revolution? Damn. More seriously, we do not go with "three editors at this article and two at that one can make up their own 'rules', and fight with everyone else about it for the next 12 years" pseudo-guidelines, unless consensus abjectly fails to arrive at some kind of standard people can live with. We have very few cases like this, mostly with *VAR in their shortcut names, and generally resolving to either a) English dialect ("variety") matters, or the unholy grail: "the citation style used in my journal can beat up the citation style used in yours". [WP should long ago have set a single citation style and just put an end to that, but we're now stuck seemingly forever with an expanding citation-mess nightmare. Don't create another one.] PS: We only tolerate this kind of wishy-washy recipe for breaking out the "member"-size rulers when WP has no intrinsic reason to prefer one option over the other. In this case, we do: "au" is better supported by standards bodies than any other option, and better supported by the more relevant ones, in non-provisional specs, while the weird one, "ua", isn't recognizable to anyone but specialists, even aside from the "au" vs. "AU" squabbling. — SMcCandlish☏¢ 😼 02:32, 19 May 2018 (UTC)
New discussion section on 4 separate proposals
The ayes 'n nays were to discuss a single proposal (the first one) and things are getting difficult to follow. Let's discuss the merits of the 4 proposals here. Dondervogel 2 (talk) 09:54, 19 May 2018 (UTC)
Well, I and others have already commented in-place on various things. I agree more extended discussion should probably be in a new section for it. — SMcCandlish☏¢ 😼 13:17, 20 May 2018 (UTC)
My proposal, just to put a damned end to this perennial rehash, is to recommend the au version, and deprecate "AU" and "ua" if we mention them at all, because all the actually authoritative/definitive sources that set standards for this stuff codify that version of it, except ISO likes the "ua" version, while we have no support for "AU" other than vestigial use that doesn't have much of anything current to cite to back it up. We should not recommend "ua", because it's sorely outnumbered, and because it's French and not recognizable to (i.e., will be confusing to) English-speakers. Even someone like me who has never taken a single astronomy-related class knows what an au or AU is, but has never seen "ua" in this context outside of an MoS squabble. The average person who reads or watches any sci-fi on a casual basis knows what au/AU means. Probably less that 0.1% of even that faintly-geeky crowd knows what "ua" stands for, and hearing it aloud would mistake it for a reference to United Artists.
I would have agreed that AU is merely vestigial and should also be deprecated until I did a quick check (see above) of current usage in the astronomical literature. Since AU is still frequently used by professional astronomers, despite the recommendations of the standards authorities and journal editors for au, I think we should allow those two options to stand. --SteveMcCluskey (talk) 12:47, 20 May 2018 (UTC)
No, we shouldn't. Any time room is made for an exception which doesn't actually matter (the way it can matter in, say, Commonwealth versus American English distinctions, e.g. metre vs. meter to give an on-topic example), this is a recipe for endless, pointless fighting over trivia no one else GaF about, at article after article after article. It's would in effect be an intentional call for a non-stop, unproductive, territorialism-based disruption, and strongly against the spirit of WP:OWN. Professional writers do all kinds of things differently – by field, by house style, even by age bracket, but MoS recommends one specific approach regardless, on almost every question. That's how a house style works, and all reputable publishers have one. Doing it this way is especially important in technical material, which is much of what MOS:NUM is aimed at. There are a grand total of zero professional astronomers who are unaware of differing au/AU style and unable or unwilling to use the style called for by the stylesheet of the publication they are writing for, or they would not survive in their career. All of these people have to write for journals, and write in ways that comply with the house style of the journal in question. It's no different from writing for WP. Within units and measures in particular, we are imposing uniform standards on the material written here, despite the fact that, say, engineers and other pro nerds of various sorts are apt to do all kinds of things if left to their own devices, like using run-together measures and units, using alternative unit names, not providing conversions, using "-" (hyphen) when "–" (minus) or "–" (en dash) is called for, using informalisms like 3'7'', using "x" instead of "×", using completely different symbols for multiply/multiplication/times (*, ·), and so on. We don't permit that kind of chaos, because it makes both writing and understanding the encyclopedia more difficult. We have no reason to make a magically special exception to our normalization practices here just to please a handful of greybeard astronomers fighting a badly-losing style battle within their field. Taking up their side in that trivial fight isn't WP's job. — SMcCandlish☏¢ 😼 13:17, 20 May 2018 (UTC)
I see your point, I just don't agree that 80% of an admittedly small sample of professionals writing about astronomical unit in the major journals is either "vestigial" or "a handful of greybeard astroomers." On that empirical fact, you're wrong; on your editorial principle, you may be right. --SteveMcCluskey (talk) 13:42, 20 May 2018 (UTC)
Our job is to make a choice and stick with that choice. We made a choice (for AU) in 2015. If the consensus has changed since then I do not object to changing that choice to au, but I do object to a mixture, for the reasons so eloquently explained by User:SMcCandlish. I can support #3, #4 or the status quo. Dondervogel 2 (talk) 18:45, 20 May 2018 (UTC)
I could also get behind "AU" over "au", if some frequency analysis shows it to be dominant in current works, for the same reason I support our decision to go against "gibibytes" and related units despite there being a published standard for them – they're not well enough known or used. This case may be different, because "au" isn't coming from just a single spec. As you're both intuiting, I care more about avoiding a mixed-bag approach and the conflict it leads to, than about any particular choice we settle on (other than against "ua", which isn't sensible in English writing). — SMcCandlish☏¢ 😼 16:18, 22 May 2018 (UTC)
I think that your job is to follow the standard decided internationally in the proper places (like IAU General Assembly, where hundreds of astronomers meet every three years to make decisions). SkZ (talk) 03:02, 6 June 2018 (UTC)
@SkZ There are two flaws in your reasoning. For the first flaw I rely on my recollection of what happened 3 years ago, which is that mosnum did follow the IAU recommendation, which at that time was to use AU, in preference to ISO (ua) or BIPM (au); as I say I'm not completely sure of which body recommended which symbol but I am sure there was confusion then, and that confusion has not yet gone away. The other is that mosnum really does trump the IAU or any other single international standards body; the whole point of mosnum, and of the MOS generally, is that it is our house style, the purpose of which is to bring clarity through harmonization. A choice was made to adopt AU (consistent with IAU advice at the time) and I see no urgent need to adopt a different symbol now. As a general rule the guidance of BIPM is more likely to result in Wikipedia-wide harmonization than the guidance of IAU, but given those too bodies are now aligned in their advice, perhaps the time has come for mosnum to follow suit. I do not object to this change. Dondervogel 2 (talk) 05:26, 6 June 2018 (UTC)
[For the "GB" problem, we should link on first occurrence to the intended unit page, at least unless and until we arrive at consensus for a different solution.] More importantly, MoS's main point is to ensure sensible, properly written, consistent output for readers; it's purpose to harmonize away editorial dispute is secondary (though more often the effect immediately in play in any given discussion about it). So, ua is a poor choice (in English) if AU or au is available, plus we have a strong rationale to not flip back and forth on these things after picking one, since it affects the output of numerous of articles and thus could confuse readers who've already gotten used to one of them. Another issue is that it's emphatically not WP's job to declare this body or that one more authoritative.
Our job is to look neutrally at all the RS (which means publications, not legal entities) and consider them in the context of each other. It doesn't matter to WP what IAU says versus what BIPM says versus what another relevant organization says [as long as none of them are disreputable – we're looking for RS, here], except inasmuch as it helps us be sure the option we do pick isn't stupid and, if we're lucky, does have multi-authority support. But all this focus on organizations is a red herring. What we really care most about is what the majority of non-obsolete RS – in total, not just specialist publications – prefer. That's our first choice. And we might reject it anyway, if there's some kind of problem with it (technical, ambiguity, even social). The end goal is recognizability to the readership, not the approval of a particular group. The readership is everyone from kids to ESL learnings, line cooks to Nobel Prize winners.
Furthermore, we've had rare but serious problems in the past with people associated with off-site organizations trying to use WP as a vehicle to promote adoption of their would-be "standard" or "convention" when it really had little real-world acceptance among relevant organizations and institutions, but a significant "fan base" among individuals in the field. In one case, it led to over a decade of intermittent disruption, and reader-confusing output in thousands of articles. Some WP:COI was demonstrably happening – someone from the on-site editorial clique pushing this supposed convention was regularly updating a blog-style page at the off-site organization's website with news of the "progress" of imposing their spec on our content. [I'll pass on giving more detailed about it here; there's no active dispute now, this isn't a WP:DR forum anyway, and one shouldn't pick at scabs.]
The point is that while we usually think of things like this in terms of commercial, political, religious, and fringe groups, even highly-regarded institutions can be the source or inspiration of programmatic PoV pushing on this site, so we're rightly skeptical of any "our organization has The Truth" stance-taking. While, obviously, no one in this debate has some weird CoI agenda, our averseness to taking sides in off-site disputes between professional bodies and the like serves multiple purposes, and serves us well. For the case I'm alluding to, no one would have thought – at first – that something untoward was happening without really looking into it. I've had my own doubts about a few issues that have recurred on this particular page, including several years of vehemence about gibibytes and the like. — SMcCandlish☏¢ 😼 09:05, 6 June 2018 (UTC)
I'd oppose au because the first question anyone will have is what the hell is an au? People know what the AU is, it is the vastly dominant usage, and it should remain the AU until au becomes the dominant form and actually used in more than a handful of publications. Headbomb {t · c · p · b}12:30, 8 June 2018 (UTC)
Approximate birth dates based on age as of date
Waiting for changes to default behavior of a template
MOS:APPROXDATE says if you have two possible birth years based on an as-of date, you should say for example "born 1912 or 1913". But we have a template for this, Template:Birth based on age as of date, that instead uses a slash: "1912/1913". You can add a param to make the template comply with MOS, but shouldn't that just be the default? Kendall-K1 (talk) 16:07, 29 March 2018 (UTC)
Um, late to this discussion but |mos=1 added to the template with this edit quite some time ago ... See the template's documentation.
Kendall-K1, Jc3s5h, can either of you add usage examples to MOS:APPROXDATE? I'd also encourage you to suggest that the template be modified as you suggest above -- that will change the appearance of some current usages (i.e. changes / to - by default) but I can't see that mattering enough to worry about. (Obviously in changing the template a new parm would be introduced which would allow getting the old punctuation.) EEng21:10, 24 April 2018 (UTC)
Slashes are a bad idea. If someone was born on "10 January 1701/1702" it is stating that the person was born on 10 January 1702 (New Style). So using slashes can be confusing for years before 1752 and before March 25 of those years for dates given within Britain and the colonies. -- PBS (talk) 17:41, 28 May 2018 (UTC)
The proposal is to move away from slashes as the default, so not sure what your point is. EEng00:11, 29 May 2018 (UTC)
@SMcCandlish I'm afraid I did not explain myself well. The problem with the quoted extract (from Boxee) is not particularly that GB is ambiguous, but that it is used with two different meanings in the same sentence. When describing RAM it means 10243 bytes. When describing flash memory it means 10003 bytes. The problem would go away if we could only think of one symbol that means 10003 bytes and another that means 10243 bytes <sigh>. Dondervogel 2 (talk) 11:06, 6 June 2018 (UTC)
And what I meant was to do "1 GB of RAM, and 1 GB of NAND flash memory." There already are separate symbols, GiB and GB, but years of flamewarring has us deadlocked on whether to use GiB except in specialist contexts. I don't think it can last forever, but it's not resolved yet. Frankly, in a construction like this I would use GiB anyway, and cite WP:IAR if anyone challenged me on it, since it genuinely improves the encyclopedia to disambiguate in such a back-to-back case. The fact that "GB" has long been used by RAM manufacturers to refer to 10243, which is more properly named [by modern standards] a gibibyte than a gigabyte, doesn't force WP's hand to use the ambiguous and now sub-standard "GB" for this, or to refer to 10233 obsoletely as a "gigabyte" just because some chip plants have their heads stuffed way up their butts. >;-) It's not something I would argue about as a stand alone thing – "1 GB of RAM" it's all that bad, and is more recognizable to the average reader. But "1 GB of RAM, and 1 GB of NAND flash memory" is only barely an improvement over the unlinked version; it's innately confusing. The usual counter-argument is "we deal with ambiguous constructions in our language all the time without the sky falling; the type of device makes the intended meaning clear in the context", but this really isn't true any longer, as storage moves onto chips. The average person who even knows of the 10243 versus 10003 distinction probably has no idea which is used by flash memory or an SSD. I think we'll have to revisit the "Gibibyte ban" at MOS:NUM within the year. — SMcCandlish☏¢ 😼 11:45, 6 June 2018 (UTC)
It is much easier to understand all digital memory sizes (and the movement of information between digital memory) if one does the maths is hexadecimal as the conversion to binary (as used by binary electronic computers) is much simpler. It is a shame that the articles like "Kilobyte" and "Gigabyte" represent numbers in decimal and not hexadecimal. 1000 and 1024 in decimal presents these number as if 1000 is clear than 1024, but if they are written in hex it is the other way around 0x3E8 looks far less clear than 0x400. Therefore writing the lead using decimal numbers presents the information with a specific bias in those articles. They also fail to convey why computer scientists prefer to work with 0x400 rather than 0x3E8 and that it is done for piratical reasons and not on a whim or as a professional affectation. -- PBS (talk) 13:47, 6 June 2018 (UTC)
Yes, that would definitely make everything crystal clear to the nonspecialist laymen who are our target audience. EEng14:54, 6 June 2018 (UTC)
It might help laypeople understand why computer scientists prefer to calculate memory sizes using 0x400 (1024 dec) rather than 0x3E8 (1000), and perhaps lead them onto the subject of maths in other bases. Besides it is assumed by the authors of the article that readers are familiar with handling bits in packets of 8 (ie 1000 bytes is actually 8000 bits, after all if bytes are used then base 8 is used -- 2 bytes is 16 bit, 3,24 4,32 etc and that is no more complicated than pounds and ounces). -- PBS (talk) 20:35, 7 June 2018 (UTC)
Seems kind of long-winded. Don't we presume that readers' brains won't melt when they encounter "10003"? And the hex numbers are meaningless to non-specialists as numbers, though PBS's point isn't invalid about x0400's clarity in that format being [part of?] why it was favored over 0x3E8. I'm thinking now that a complex template would be a good idea, like what {{Nihongo}} does with Japanese. These number conversions are something software can do automatically. — SMcCandlish☏¢ 😼 00:50, 7 June 2018 (UTC)
If one writes the numbers hex 1GB = 0x40000000 bytes and 1GB 0x3B9ACA00 bytes then it inverts the supposed clarity. (As SMcC indidates, bracketed numbers in hex would help explain this issue). Going off-piste: But why stop at bytes and use bits or some other measure instead. In these days when some microwave ovens probably have processors with a word size of 64 bits (if not they are probably not Y2038 safe and will cook something for 137 years starting on a day in 2038), using an arbitrary 8 bits rather than arbitrary 64 bits is quaint, but salesmenpeople know that big is better and 1000 x (8 bits) sounds so much larger than 125 x (64 bits). -- PBS (talk) 20:35, 7 June 2018 (UTC)
Except that capacity is measured in bytes whereas word size is a measure of system width. I've worked with people who insisted on sizing jobs in terms of words (usually kilowords) and most confusing it could be. At that time we had the SGI Origins (64 bit), Crays (64- or 56-bit) and support machines (32-bit). Even on 64-bit machines a byte is usually the smallest addressable unit of memory (as well as being one ASCII or EBCDIC character). 8 bits is not arbitary and reverting to word sizing would make my brain explode! Martin of Sheffield (talk) 22:30, 7 June 2018 (UTC)
It's an interesting problem. If we said "one glass of wine and one of beer" would we need to say that a wine glass is 5 oz and beer is 12, 16 or 20? Probably not, depending on the context. Even for someone familiar with the problem, I have to stop and think whether NAND flash is measured in GB or GiB. Whatever you do, please fix the citekill, and insert nbsp between the number and the unit. Kendall-K1 (talk) 22:46, 6 June 2018 (UTC)
With respect Kendall-k1 it's worse than the glass analogy. Virtually everyone knows that glasses come in different sizes. A closer analogy is the long/short/metric ton discussion that's been going on elsewhere. We wouldn't accept a phrase such as "a ton of UK steel is better value that a ton of US steel" and hope that the reader inserts "long" and "short" appropriately. I'd agree with SMcC that a change to the ruling is long overdue. Martin of Sheffield (talk) 09:42, 7 June 2018 (UTC)
Well I know that a barrel of UK beer lasts much longer than a barrel of US beer. I agree that the current MOS recommendation against using GiB should be revisited but I dread the ensuing discussion. Kendall-K1 (talk) 11:32, 7 June 2018 (UTC)
Barrel emptying times is not something so easily quantified as quantity against time :-) -- PBS (talk)
It really depends on what's happening. I'm sure a UK barrel will go much faster during the World Cup than a US one, and vice versa during the Super Bowl. >;-) — SMcCandlish☏¢ 😼 23:12, 12 June 2018 (UTC)
Likely, but it's going to take a well-thought-out proposal that addresses the issues raised in the previous rounds of debate about this; it verges in WP:PERENNIAL. — SMcCandlish☏¢ 😼 06:59, 20 June 2018 (UTC)
It is my recollection that the problems in previous discussions were caused not by the issues but by the lack of goodwill on the part of a very small number of editors and their puppets. The troublesome editors have moved on so I expect the discussion to be constructive, and a constructive discussion will succeed in addressing the issues. The bottom line is that it should not be necessary to rely on WP:IAR to follow an international standard in situations for which it is the obvious solution. Dondervogel 2 (talk) 07:27, 20 June 2018 (UTC)
Date ranges vs. full birth–death dates in biographical leads
And yyyy-mm-dd format isn't allowed universally anyway, just in particular contexts where the format is especially useful; see above for some disputation about how that list may shrink, e.g. because wikitables can now sort the other date formats chronologically. — SMcCandlish☏¢ 😼 15:02, 5 July 2018 (UTC)
This may entail changing all the dates in the article with the YYYY-MM-DD format to a different format, such as Month d, yyyy. Too bad the editor who introduced YYYY-MM-DD into the article in the first place didn't plan ahead. Jc3s5h (talk) 17:15, 5 July 2018 (UTC)
The ISO specification allows for dates along the form of YYYY-DD-00 to indicate that the day is unknown--the spec does not allow for someone to trim digits off. I would personally advocate against it generally and agree that conversion of format is preferable. --Izno (talk) 18:07, 5 July 2018 (UTC)
I have read a draft of the next version of ISO 8601. It has two parts; the first part is supposed to be the same as the 2004 version, and the second part is extensions. You can find it at the Library of Congress if you choose appropriate search terms. (I don't have an official copy of the 2004 official version). Nowhere does it allow for zeros to be substituted for unknown digits. Jc3s5h (talk) 18:48, 5 July 2018 (UTC)
Ah, I misremembered what our article says on the point (ISO 8601). It does allow us to specify dates without day precision (YYYY-MM) as well as dates without year precision (or, 2000 did: --MM-DD). --Izno (talk) 19:57, 5 July 2018 (UTC)
The forbidding of yyyy-mm dates bothers me. In an article such as Tesla,_Inc. there are 477 reference. 476 of them have full dates with year, month and day. Only a single reference lacks the day (May 2009). The current guidelines suggest the following ways to handle it:
Display that single date as 'May 2009', violating WP:DATEUNIFY
Change all the dates to '31 December 2018' or 'December 31, 2018' style, violating WP:DATERETAIN.
Provide a fake day (eg '01'), which is lying
Provide a '00', which is new to me and potentially confusing to the majority of readers
Personally I've always thought that readers who see a dozens to hundreds of references with dates in yyyy-mm-dd format will not suddenly think that those exact publication dates have suddenly swapped to inexact date ranges covering years. Especially since 2001-2005 is now the preferred format over 2001-05. Stepho talk21:30, 5 July 2018 (UTC)
I would the urge conversion route, because we have no encyclopedic interest in using reader-hateful ISO dates, except in particular contexts with good reasons. I even say that as a professional geek who works with ISO dates all the time, and is a huge fan of their value in technical contexts, like filenames that sort by date, or the ability to operate easily on dates with a script. We've been permissive of ISO dates mainly because of the wikitable sorting problem, and it has been fixed. If people at that article pitched a fit about it, go with "May 2009" as a minor IAR inconsistency, and let them have their playground; it's not worth the drama. — SMcCandlish☏¢ 😼 23:15, 5 July 2018 (UTC)
I've seen how people who don't like ISO dates use emotion charged words like 'hateful' and 'pitched a fit'. Far from wanting to convert away from ISO dates, I would prefer to find a way to consistently use ISO in all references on articles that choose to do so. Converting 476 dates just because of a single reference is an unbalanced way to do things. Stepho talk09:49, 6 July 2018 (UTC)
I'm with Stepho on this. It's really hard to misinterpret a date like yyyy-mm when all other dates are yyyy-mm-dd. Should be permitted. Dondervogel 2 (talk) 17:26, 6 July 2018 (UTC)
(edit conflict) Please read rather than react. You missed both points. You can just IAR, with "May 2009" and move on, without changing any ISO dates. I'm not among "people who don't like ISO dates"; repeat: I'm huge fan of their value in technical contexts. This isn't one, not even in citations. — SMcCandlish☏¢ 😼 06:26, 7 July 2018 (UTC)
React? You used emotion charged words to urge me to follow a certain action and I calmly expressed that I didn't prefer that reaction. That's called a conversation. Unless you're simple trying to shut it down by ridiculing anyone who doesn't agree with your opinion.
Yes, I read both of your points, even though I was only responding to one of them. As I stated, I prefer not to convert away from ISO dates. Your second option of IAR is what I have been using since the yyyy-mm ban came into place. Older articles that used yyyy-mm I have turned a blind eye to. For new references I have used 'July 2018' type dates. There is no action that is 100% correct under the current rules. I prefer to stay within the rules when possible, so I am asking for clarification (in case I missed something) or possible rule changes. Stepho talk23:59, 7 July 2018 (UTC)
(edit conflict)That particular citation is, I think, fixable. As written right now, it has the form:
[http://www.justice.gov/atr/public/eag/246374.htm Economic Effects of State Bans on Direct Manufacturer Sales to Car Buyers]" ''Economic Analysis Group Competition Advocacy'', May 2009.
It alone, of all the references in that section, is not templated. It probably should be; perhaps like this:
{{cite report |last=Bodisch |first=Gerald R. |url=http://www.justice.gov/atr/public/eag/246374.htm |title=Economic Effects of State Bans on Direct Manufacturer Sales to Car Buyers |orig-year=2009 |date=15 October 2015 |work=Economic Analysis Group |publisher=United States Department of Justice}}
I recently worked on an article where the source that ultimately was used was a parish register of vital events. It spanned several decades. Later it was microfilmed, and then the microfilm was put online. WP:CITE#Dates and reprints of older publications says to cite both the original date and the date of the re-publication where you saw it. The original date might be something like 1706-11, or some might write it 1706-1711. If the second year in the range were written with 2 digits, there could be genuine confusion whether it means 1706 to 1711, or November 1706. Indeed, an editor trying to "correct" it should examine the source to discover which is the case.
Such a date (1706-1711) could be valid, in the sense that during the period when the book was only partially full, members of the public could look at it, so in a sense it was "published" throughout that period. Jc3s5h (talk) 00:23, 8 July 2018 (UTC)
A valid point, although thankfully a rare case on articles I work on (mostly automobile articles where the problem cases involve magazines issued as 'XXX Magazine, July 2018'). Perhaps we could say (simialr to your suggestion) that references with date ranges always use 4-digit years on both sides (current rules prefer this but also allow 2001-05). Stepho talk05:40, 8 July 2018 (UTC)
A perennial debate because neither side can really must a good argument. The ISO lovers don't say much more than WP:ILIKEIT and the rules allow it (catering to the techno-nerds like me). The ISO haters don't say much more than WP:IDONTLIKEIT and users are dumb. Speaking anecdotally from my own experience, ISO dates are common in Northern Europe and Asia and English speaking countries near them are getting used to seeing ISO dates. Whereas the US has no such neighbours using ISO dates and are often the most vocal (but not only) voices against them. Not being judgemental, just noting a possible cause. Stepho talk05:40, 8 July 2018 (UTC)
That's an utter distortion of these discussions, though. The usability arguments against ISO dates have been well and consistently articulated, by numerous editors. The primary rationale in favor of using them, date sorting in tables, no longer exists. — SMcCandlish☏¢ 😼 07:33, 8 July 2018 (UTC)
Really? I follow most of the ISO date discussions and I rarely see any good arguments on either side. Could you point me to some of theses previous discussions that show well articulated points. By the way, I not worried by the sorting issue - the current software seems to handle all allowed forms equally well. Stepho talk09:04, 8 July 2018 (UTC)
Start at the top of this one, and read it through. Cf. WP:SHOWME. There's no point is repeating (or copy-pasting, or diffing) the exact same arguments that have very recently been stated (and were already repeats from previous threads). If you have read it all and are just asserting that you don't find the arguments convincing but did see and understand them, that's an empty thing to say, since you've done nothing to refute them. It's "I don't like it". — SMcCandlish☏¢ 😼 09:43, 8 July 2018 (UTC)
It doesn't solve the problem, but I'll just note that a properly formatted date range is always distinguishable from an ISO-ish date because it uses a dash rather than a hyphen. Kendall-K1 (talk) 01:55, 10 July 2018 (UTC)
Clarification on using quote marks ( " ) as the unit symbol for inches in infoboxes
Big Ten Inch Record
versus
3"
MOS:UNITSYMBOLS includes "Where space is limited, such as in tables, infoboxes, parenthetical notes, and mathematical formulas, unit symbols are preferred." The "Guidelines on specific units" table lists "in" as the unit symbol for "inch", with the comment Do not use ... ″(″) ... or quote(").
When I tried to use "inch"[20] or "in"[21] for this infobox single, I was reverted. In their first edit comment, SnapSnap wrote: "Per MOS:UNITSYMBOLS, unit symbols are preferred in infoboxes."[22] In their second, they added "Quotation marks are widely used for inches in music article infoboxes, plus the guideline doesn't mention anything about using "in" instead of quotes in infoboxes."[23]
However, Template:Infobox song#format (which replaced Infobox single) includes: "Do not use " or ″ (double quote) for inches, instead use 7-inch rather than 7" (if it is necessary to abbreviate, use 7 in; see WP:Units)."
It's clear that quote marks ( " ) should not be used for inches in prose, but clarification on what to use in infoboxes, tables, section headings, etc., would be appreciated.
—Ojorojo (talk) 18:35, 10 July 2018 (UTC)
There's a lot of problems with that section (for instance the whole of §4.4.1). I'd take note that the table is headed "Guidelines on specific units" not "Rules ..." and act with common sense. Martin of Sheffield (talk) 20:46, 10 July 2018 (UTC)
Articles that use {{Infobox artwork}} (dimensions) and {{Infobox motorcycle}} (wheelbase, height, etc.) use "in" for inches. A guideline is "is a generally accepted standard that editors should attempt to follow, though it is best treated with common sense, and occasional exceptions may apply." {{Infobox song}} should follow the same "generally accepted standard", unless there is a good reason not to do so. —Ojorojo (talk) 21:37, 10 July 2018 (UTC)
I see no justification for ever using " as a symbol for inch on Wikipedia. The only question is whether to spell out the full name (inch) or use the symbol (in). Dondervogel 2 (talk) 22:49, 10 July 2018 (UTC)
The sentence about using "inch"/"in" rather than quotation marks wasn't added to {{Infobox song}} until last year. Using " in single infoboxes when referring to vinyl releases has been the standard for as long as I can remember. snapsnap(talk)23:46, 10 July 2018 (UTC)
Please cite the standard. Who published it? The ISO? What you really mean is that it's a common style in writing about music releases. It is not the only style, and it's not one that WP wants because " or ″ a) doesn't mean anything to all readers, and b) even when it does it means something else to many of them (seconds). WP is not written in news style as a matter of policy, and that includes the music journalism subset of news style. — SMcCandlish☏¢ 😼 19:59, 11 July 2018 (UTC)
There is little space savings using "7 in record" over "7-inch record". It makes more sense to be consistent when including a conversion "7 in (18 cm) record" rather than "7-inch (18 cm) record", but I don't recall seeing conversions in songs articles. The use 7-inch instead of 7" phrase was added to the Infobox single documentation on June 19, 2016. (Before the two infoboxes were merged in May 2017, Infobox song included it by reference: "Unless otherwise stated here, refer to Template:Infobox single for guidelines on how to use parameters that it shares with Template:Infobox song.") —Ojorojo (talk) 01:55, 11 July 2018 (UTC)
The English Wikipedia is also for non-native speakers of English. Non-native speakers are much more likely to understand 'in' than '"'. Dondervogel 2 (talk) 09:29, 11 July 2018 (UTC)
"Twelve-inch single" ("12 inch single") is a term of art; it is not something that needs to be converted on the fly to "(18 cm)"; it's like 100 metre dash and 2 × 4. Just link the first occurrence of "twelve-inch single" or "12 inch single" to the article on the format, for anyone new to the concept. We should probably use the former; there is no reason to abbreviate it to "12". There is no reason to use the " symbol, which should properly actually be primes (″) not apostrophes, but we have a rule against both. And even if we did provide a conversion, one of the longest-running MOSNUM rules is to spell out the first unit and abbreviate the parenthesized one(s). There's been a later change to say "Consider using inches (but not in.) in place of in where the latter might be misread as a preposition—but not where the value is followed by a parenthesized conversion e.g. bolts 5 in (12.7 cm) long, or is part of such a conversion (bolts 12.7 cm (5 in) long)." This is inconsistent with the rest of our treatment and with actual practice, and should be reset back to something like: "Consider using inches (but not in.) in place of in where the latter might be misread as a preposition—but not where the value is part of a parenthesized conversion: bolts 12.7 cm (5 in) long." This will prevent this kind of "12 in (18 cm) single" dispute from arising again. See also WP:Common sense; no one in the world, including thoroughly metricized Europeans, writes gibberish like that in reference to music releases. — SMcCandlish☏¢ 😼 19:41, 11 July 2018 (UTC)
No one is suggesting that a conversion be added (if this may be misinterpreted, I've struck it). As Dondervogel 2 noted "the only question is whether to spell out the full name (inch) or use the symbol (in)". This discussion focuses on use in an Infobox: the guideline notes the preference for unit symbols in infoboxes, which is "in". But for editors who use 7" or 12" alone (without single, record, etc.), 7-inch or 12-inch may be better understood than 7 in or 12 in. —Ojorojo (talk) 21:01, 11 July 2018 (UTC)
No one is suggesting that in the present discussion, but it's being done anyway. See all the cleanup I did at Twelve-inch single just today, for example [24]. Summary of principles:
"Twelve-inch single", "ten-inch EP", "seven-inch single", etc., in reference to formats and release types, are terms of art in the music industry, not measurements (many of them are not quite 12 inches or whatever; exact size varies by pressing plant). They're standardized/conventionalized types of vinyl pressings the names of which happen to be derived from measurements (cf. Three Mile Island and other names so derived). Spell them out even if less cautious publishers don't always do so. Using this format also avoids the ugly and often reader-irritating practice of starting a sentence with a numeral. These take a hyphen. Example of good usage: "Twelve-inch singles typically have much shorter playing time than full-length LPs, and thus require fewer grooves per inch."
"12-inch", "10-inch", "7-inch", used as sizes, are measurements (and in this context are approximate ones). Use the numerals. Use the word "inch" unless it's the metric unit which is given first (which shouldn't happen in this context). These take a hyphen with "inch"; if the unit symbol "in" in used, these take a non-breaking space not a hyphen, even when used adjectivally, same as with any other measurement+symbo pair. Example: "As no 7-inch (18 cm) acetates could be found, a 10-inch (25 cm) blank was used." [If the changed (current) MOSNUM wording is retained, "7 in (18 cm)" would be used, but this is wrongheaded, and the change to the guideline should be reverted, as discussed above.]
Then "12-inch single" would probably be appropriate. Or "12 {{abbr|in|inch}} single" if desperate, I suppose. We just don't hyphenate between digits and unit symbols (apparently we are now hyphenating between digits and unit names; I corrected the bullets above to reflect this. I dislike how inconsistent this is, but [shrug] c'est la vie. — SMcCandlish☏¢ 😼 02:25, 13 July 2018 (UTC)
Don't forget that writing "12 in" implies the product of the number 12 and the unit inch (twelve times one inch), and this meaning would be corrupted by the presence of a hyphen. It is therefore natural for the punctuation to be different for a mathematical operation, and perhaps for this reason it would be wise to avoid expressions like "12 in single". Your suggestion to write "12-inch single" seems like the best we can do here. Dondervogel 2 (talk) 11:02, 13 July 2018 (UTC)
I guess that would depend on the context. Probably needs to be decided by common sense. The most important think is to avoid " as a symbol for inch. We have a symbol already (in) and we don't need another. As EEng points out, " can also mean seconds of time (or seconds of arc for that matter), and is best avoided. Dondervogel 2 (talk) 17:07, 13 July 2018 (UTC)
Shouldn't this be discussed at MOS:MUSIC as well? I'm not against using "inch" instead of " (which, like I said, has been used for ages when referring to vinyl releases), but if you're going to replace " with "inch" in one music article, you might as well replace it in other articles, too. snapsnap(talk)23:07, 13 July 2018 (UTC)
No, per WP:TALKFORK. WT:MOSMUSIC has been notified of this discussion. But we apply measure and unit style consistently, not on a topic-by-topic basis, or we'd have utter chaos. Yes, the same approach (or approaches, if we need a compressed syntax in infoboxes) should be used across all the articles on music stuff); that's a given. I don't think anyone's goint to interpret this as some kind of one-article local consensus discussion, or it wouldn't've been posted here. :-) — SMcCandlish☏¢ 😼 03:37, 14 July 2018 (UTC)
Indic date mess
Could someone who understands the dating system(s?) of India/Hinduism please clean up Ram Charan (guru) and Ram Kishor to conform to MOS:DATE and WP:USEENGLISH? It's pretty impenetrable to anyone who isn't a Hindi speaker, and the material is veering back and forth between calendars in a very confusing way. — SMcCandlish☏¢ 😼 11:28, 17 July 2018 (UTC)
Well my understanding is that they really don't have much of a dating system but instead use arranged marriages a lot of the time. EEng14:54, 17 July 2018 (UTC)
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
The result of the discussion was to go with Option 3 (au, while not prohibiting AU). Options 1, 2, and the status quo were firmly rejected, leaving only a discussion about whether to make this a "hard" or "soft" deprecation; in other words, allowing existing AU usage or actively discouraging its further use. There was strong support for both options, but more advocated for the position that there was no rush to immediately convert all instances of AU to au. From an administrative perspective, I note that the sentence An alternative is AU contradicts the overall idea and sentiment of deprecation, and it will be struck from the updated table. If there comes a point where au is officially recognized by all astronomical societies and its use has been deprecated on the English Wikipedia, there is no prejudice against starting a new discussion to remove the "Comment" regarding AU, though a formal RFC might not be necessary. Primefac (talk) 22:03, 30 June 2018 (UTC)
This RfC relates to the options discussed in the immediately preceding section, which has become inactive in the last week. To bring this discussion to a close, I am initiating a formal RfC, which may attract additional participants and has a formal closing mechanism. Below are sections for expressing support of the four draft revisions proposed above. SteveMcCluskey (talk) 02:02, 30 May 2018 (UTC)
AU is the most commonly used symbol for this unit, both in popular and professional articles, and is hence also used on Wikipedia (though some organizations, including the BIPM[1] and IAU,[2] recommend au).
au is recomended by the BIPM[1] and the IAU,[3] and is called for in the publications of the AAS (AJ and ApJ)[4] and the RAS (MNRAS)[5]. AU is a commonly used symbol for this unit, both in popular and professional articles.
The preferred option au is recomended by the BIPM[1] and the IAU,[6] and is called for in the publications of the AAS (AJ and ApJ)[7] and the RAS (MNRAS)[8]. AU remains an acceptable option as it is a commonly used symbol in both popular and professional articles.
AU is the best option of all, and we don't need the massive disruption changing to, or allowing, au. Headbomb {t · c · p · b}12:34, 8 June 2018 (UTC)
I'm agnostic to both AU/au, but we should only have one. Allowing multiple acceptable variants does more harm than good (the light-year discussion comes to mind, but forget I mentioned that...). ~Tom.Reding (talk ⋅dgaf)12:59, 8 June 2018 (UTC)
'AU' is the traditional version; 'au' is the IAU preference. To me the 'AU' seems much clearer as 'au' looks too much like a misspelled word. The standard convention in English for an abbreviation is to capitalize the letters, which leans more toward 'AU'. But I can live with either, as long as the usage is consistent within an article. Praemonitus (talk) 14:26, 8 June 2018 (UTC)
Strongly oppose the status quo. AU may be acceptable, but the status quo's deprecation of au, which is the internationally approved symbol for astronomical unit, is not. --SteveMcCluskey (talk) 01:35, 12 June 2018 (UTC)
Support. "AU" is far more commonly used, and is far more recognisable amongst readership, who are after all the folks we're trying to service. — Huntster (t@c)07:11, 12 June 2018 (UTC)
Second choice, though we need not mention "this other organization prefers ...." stuff, other than maybe in a footnote with {{efn}}. — SMcCandlish☏¢ 😼 23:19, 12 June 2018 (UTC)
I actively oppose this ("au or AU, your choice") because it absolutely guarantees endless article-by-article editwarring and "my organization is better than yours" PoV pushing. Nothing constructive can come of this. The job of a style guide is to set a standard (even if an arbitrary one) to put a stop to both fights and "what do I do?" confusion, and [more importantly] to produce consistent output for readers – not to just throw up it's hands and say "whatever". If we were going to do that, the solution would be to remove any mention of the unit and its symbols at all. We also do not cite sources in MoS or other WP:P&G pages as if they're articles (unless is to point to resources like usability specs that an editor might need which is out-of-scope – not for justification, which is WP's own editorial consensus, arrived at by source comparison, consideration of project goals and reader needs, and many other factors. — SMcCandlish☏¢ 😼 09:12, 6 June 2018 (UTC)
I actively oppose this (another "au or AU, your choice" option), for the same reason as stated for Option One. — SMcCandlish☏¢ 😼 09:13, 6 June 2018 (UTC)
Support this as my preferred option, but they're all better than the status quo. The correct form, used by all the relevant professional bodies and in particular the IAU, is au not AU. Modest Geniustalk14:33, 8 June 2018 (UTC)
Support, not because AU is widely used in the big bad world out there but because until now it has been required by MOSNUM. This option permits a smooth transition to au. I can also live comfortably with Option #4 or the status quo. Dondervogel 2 (talk) 11:09, 30 May 2018 (UTC)
Support. pace SMcClandlish, Option 4 could also lead to fresh conflict if a rush to change AU to au in existing articles triggers a return to the question here. If - or more likely, when - organisations such as NASA and more of the popular press move from AU to au over coming years, we can switch to Option 4. Order of preference: 3,4,2,1 while strongly opposing the status quo's choice of an obsolescent symbol. 92.19.25.65 (talk) 08:37, 12 June 2018 (UTC)
Weak oppose, because it leans a bit in the direction of the two options immediately above, in being wishywashy and thus likely to perpetuate pointless disputes over style trivia on an article-by-article basis. This would be my distant third choice, if it came down to it, and only if we moved some of the organizational claptrap into an {{efn}} footnote. — SMcCandlish☏¢ 😼 23:15, 12 June 2018 (UTC)
Weak support. As I mentioned above, I favor leaving use of both symbols as acceptable, since the larger community is only slowly moving from the old form AU to the new au. Emerson said "a foolish consistency is the hobgoblin of little minds." For Wikipdedia to ban either of the accepted symbols in the name of consistency seems a perfect example of Emerson's "foolish consistency." Of options allowing both symbols Option 3 is more concise than option 2. I could be brought to a strong support if this option were internally consistent and provided both symbols in the Symbol column, as it already does in the Comment column. --SteveMcCluskey (talk) 11:42, 18 June 2018 (UTC)
You're severely misunderstanding Emerson, like almost everyone who quotes him out of context. See WP:EMERSON. He meant inflexibility of mindset in the face of changing facts – not typographic or stylistic consistency, something he was entirely used to as a professional writer. — SMcCandlish☏¢ 😼 16:55, 18 June 2018 (UTC)
Support Option Four
Support, as it favors the formally accepted abbreviation au, and deprecating the not more so used AU. I have checked the published version of articles in MNRAS, A&A, AJ, ApJ, Icarus (I am an astronomer) and all the ones published in the last 1-2 years use au. Up to 2015 ApJ and AJ used AU, but it seems they stopped. Also I support it because I am an astronomer and I would like you to respect our decision and not to decide by yourself what is the astronomical standard! Why should Wikipedia users be above International Astronomical Union? SkZ (talk) 02:51, 6 June 2018 (UTC)
Support as first choice (without prejudice toward settling on AU instead, if there's a reason WP should prefer it). KISS principle: Set a single WP recommendation, as MoS does on virtually everything (unless there's a WP:ENGVAR conflict). Otherwise people will fight it out article-by-article until the end of time. We could have a note in it about whose standard it is, in plain English, without a pile of inappropriate "back up my claims" citations, which don't belong in WP:P&G material, or it will inspire "sourcing wars". We already went through that at the main MoS page several years ago, resulting in the WP:MFD of two pages of cherry-picked citation material that people were using to editwar incessantly at MoS. Never again. The discussion above already demonstrates quite a lot of polarization (if that word can really apply to a mostly three-organization conflict), so this should be nipped in the bud right now. — SMcCandlish☏¢ 😼 09:28, 6 June 2018 (UTC)
Unicode is coded for an AU symbol. If we change, we should use the Unicode coded version. Otherwise, we should remain at the status quo, per older discussions. -- 65.94.40.190 (talk) 06:46, 14 June 2018 (UTC)
Note - I've taken the liberty of adding the options above the "poll" itself so that they are a little easier to find/remember. Primefac (talk) 12:02, 8 June 2018 (UTC)
I have the impression that Options 1 and 2 have the least support, with support for one of them coming only from Modest Genius. May I be so bold as to ask Modest Genius which his or her second preference might be, in the event that 1 and 2 were both withdrawn (think of it a single transferable !vote)? Dondervogel 2 (talk) 20:24, 9 June 2018 (UTC)
"AU remains an acceptable option as it is a commonly used symbol in both popular and professional articles." This isn't just a colloquialism: it follows the convention in English to capitalize the letters of a multi-word abbreviation (that is not yet common vocabulary). E.g. FYI, YTD, RSVP, &c. Praemonitus (talk) 17:32, 10 June 2018 (UTC)
I think it matters whether we are discussing a symbol or an abbreviation. Your argument holds for the latter but not for the former. The reason I prefer au as a symbol is that this symbol has been adopted by international standards bodies, including the IAU. Dondervogel 2 (talk) 19:15, 10 June 2018 (UTC)
Regardless of whether you consider it a symbol, AU is an abbreviation for Astronomical Unit. Yes 'au' was adopted by the IAU for the purposes of standard communication within the astronomy community. That doesn't mean Wikipedia needs to stick with it. Praemonitus (talk) 14:20, 14 June 2018 (UTC)
That's not a universal rule for units of measurement. Look at mph/MPH in news reports[25], for example, or psi/PSI, while less common units outside SI tend even more strongly to be abbreviated to or symbolised by lower-case rather than upper-case characters (eg in.w.g. or inH2O rather than INWG, but possibly excepting the British thermal unit, Btu in standards but often BTU in sales literature.) 92.19.25.65 (talk) 09:01, 12 June 2018 (UTC)
That is specifically why I said "not yet common vocabulary". 'AU' is hardly as commonplace as 'mph' — most non-astronomy-buffs wouldn't have a clue that AU is an abbreviation if it were in lower case. See the abbreviation article. Praemonitus (talk) 14:24, 14 June 2018 (UTC)
My position has shifted a little. I think it is time to follow the international standards (BIPM, IAU) by switching from AU to au, and now find options 3 and 4 equally acceptable - I don't think it really matters how quickly the change occurs. The status quo comes a poor third, while options 2 and 3 represent an unacceptable cop-out. I will update my !vote when I find the time. Dondervogel 2 (talk) 04:28, 14 June 2018 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Followup: Does this divide along discipline lines?
It strikes me as worth asking, so that a specific variant can be recommended for specific contexts (or so we can recommend to use the variant appropriate to the context, rather than listing them out here). E.g., subspecies is abbreviated ssp. in zoology, but subsp. in botany, which uses it as a symbol in scientific names while zoology does not. Wondering if something similar might be going on in, say cosmology and archaeoastronomy versus astrophysics and exoplanetology, or whatever. — SMcCandlish☏¢ 😼 04:11, 5 July 2018 (UTC)
If composed fraction characters are to be avoided in prose, should 6½ Avenue and similar titles be changed? Obviously {{frac}} can't be used in article titles, so maybe there should be guidance for this. (Note that 6+1⁄2 Avenue is actually between Sixth Avenue and Seventh Avenue, so I'm not sure how it's supposed to be pronounced.) Jc86035 (talk) 11:06, 20 July 2018 (UTC)
Unless a proponent of the current title can cite a reliable source showing that the City of New York has knowingly officially designated it as the Unicode character U+0036 followed by the unicode character U+00BD, and that the use of these characters is not merely the choice of some secretary or typesetter, then we are free to render it as best suits our technology: 6 1/2. Jc3s5h (talk) 14:24, 20 July 2018 (UTC)
Concur with Jc3s5h (whom I assume is no relation to Jc86035, though they may come from the same illustrious Jcrandomstuff lineage, the Dukes of URL). We should be using 6 1/2 style. Probably worth mass-WP:RMing the ones using the Unicode fractions. — SMcCandlish☏¢ 😼 07:11, 23 July 2018 (UTC)
Monetary values guideline unclear
MOS:CURRENCY states, "Conversions should be in parentheses after the original currency, rounding to avoid false precision (two significant digits is usually sufficient, as most exchange rates fluctuate significantly), with at least the year given as a rough point of conversion rate reference; e.g. Since 2001 the grant has been 10,000,000 Swedish kronor ($1.4M, €1.0M, or £800k as of August 2009[update]), not ($1,390,570, €971,673 or £848,646)". I find this guideline unclear. Why is 1,390,570 rounded just around 10k to 1.4M but 848,646 to 800k -a difference of almost 50k? Wouldn't it be better to round it up to 850k? After all, the guideline itself says that two significant digits is usually sufficient, so it is unclear why it was rounded to 800k. In addition, why use two different formats for millions in the same sentence, 10,000,000 and 1.4M? Thinker78 (talk) 07:21, 22 July 2018 (UTC)
Mixing styles in mosnum is common. Its purpose is to usually to illustrate that multiple styles are permitted, and I'm guessing that is also the purpose here. In any one article consistency is encouraged. Dondervogel 2 (talk) 07:31, 22 July 2018 (UTC)
I actually think that our guideline is relatively clear regarding this specific point - it is just the example that is wrong, as you've rightly pointed out Thinker78.
Consequently I intend to change the example to: "Since 2001 the grant has been 10,000,000 Swedish kronor ($1.4M, €970k, or £850k as of August 2009[update]), not ($1,390,570, €971,673 or £848,646)"
(Personally I don't believe it is appropriate to encourage multiple styles within the same conversion but, if we did need an example of that aberration, it might be: "Since 2001 the grant has been 10,000,000 Swedish kronor ($1.4M, €970k, or £850,000 as of August 2009[update]), not ($1,390,570, €971,673 or £848,646)" if this specific part of the guideline were followed) --BushelCandle (talk) 10:41, 28 July 2018 (UTC)
Who can resist EEng's challenge to find formal use of kUSD, kEUR and similar?
Well, obviously not me, and here's a few examples to get us started:
^Budzianowski, W. M. (2018). Enhancing low-carbon economic growth by renewable energy uptake in countries with per capita gross domestic product between 10 and 20 kUSD. International Journal of Energy Technology and Policy, 14(2-3), 292-318.
^Burns, T., & Wilkoszewski, H. (2013, June). Governing complex education systems. In Presentation at 3rd GCES-Conference ‘Effective Multilevel Governance in Education’, Paris (pp. 17-18).
I hope you don't mind my numbering your items.
From the title, 3 is a presentation
5 is just a technical list, not a usage example
As to the rest, I'm not sure that's the kind of formal nontechnical (I should have said that) writing I meant. It's one thing to condense $56,000,000 to $56M but changing $56,000 to $56k seems unnatural and fussy for little benefit.
(ec) I'm happy to withdraw #3 for the reason you say. I think the ISO standard is valid though because it's an indication of international consensus, and is intended for formal use. My main point is that it cost very little effort to find these - I'm sure there are plenty more to be found. Whether there's a benefit in introducing the abbreviation is a different question. Dondervogel 2 (talk) 17:26, 28 July 2018 (UTC)
I don't know why I didn't think this through before, but the important point is that MOS:CURRENCY doesn't call out this use (though it does give M for million and bn for billion). EEng19:13, 28 July 2018 (UTC)
Following the shortcut MOS:DATERANGE currently leads to a long section covering more than 25 style guidelines for date ranges. It is cumbersome for the reader to find specific guidelines within. Proposal: The text be organised into subsections:
Simple ranges: year–year, day–day, month–month
Ranges where items are spaced
Date range to the present
Biographical dates
To produce the subheadings and layout as sandboxed here. Rationale: to aid reading navigation and break the guideline into more manageable segments when editing. Comments sought and welcomed. -- Ham105 (talk) 16:23, 30 July 2018 (UTC)
covering more than 25 style guidelines – No, that's a huge exaggeration. Maybe 10, depending how you count. But that's not the point. Good structure isn't arrived at by some formula, but by thinking about how to best help the reader understand each portion of the guideline.
A real problem with level 5's, and a reason to avoid them, is that they're typographically indistinguishable from 4s. They're used in only one place on the page, where several large groups of related points absolutely have to be set off from one another and there's no other way to do it i.e. where Chronological items > Dates, months and years > Formats has subsections Consistency + Strong national ties to a topic + Retaining existing format.
In the section under discussion, the existing indented bullet structure, and bolding, already draw the eye to each point in turn. The level 5's you propose mostly repeat what's said, in bold, in the bullet point immediately following.
There's a progression of related formats which are meant to be read as a group. Breaking up into sub-sub-sub sections obscures that.
"breaking the guideline into more manageable segments when editing" is absolutely of zero consequence. There are a very few of us scribblers editing, but an average of 1000 editors visiting daily for guidance. The best presentation is the only thing that matters.
I concur entirely with EEng on this. Sectioning should be introduced when it works well, not just because it's possible to do it. — SMcCandlish☏¢ 😼 02:38, 1 August 2018 (UTC)
As a personal preferences, the new version is much easier for me to read and find a sub-section that is relevant to me. The current one is harder for me to read as it's just a giant bold wall-of-text. --Gonnym (talk) 23:01, 3 August 2018 (UTC)
While already here, does MOS:DATERANGE (specifically the 4 digits change) also apply for article titles or just for dates inside an article? Only somewhat relevant mention was the lead that said this is especially important within an article. Would appreciate the clarification. --Gonnym (talk) 15:28, 4 August 2018 (UTC)
Paging SMcCandlish. I suspect the answer is yes, it applies the same in titles as in text, but I also suspect that with the exception for adjacent years, most titles will be unaffected. EEng16:25, 4 August 2018 (UTC)
Section on dispute over section headings in discussion page discussion discussing section headings
@EEng: Please stop subverting this discussion point by editing it into a subsection. Show some good faith. While citing WP:TPO in your edit summary ... It can also sometimes be appropriate to merge entire sections under one heading ...", you somehow omitted the text "To avoid disputes, it is best to discuss a heading change with the editor who started the thread, if possible, when a change is likely to be controversial." -- Ham105 (talk) 12:39, 4 August 2018 (UTC)
You're talking about [28] and [29]. I apologize for not realizing that there were sane people who would consider such a thing "controversial".
I realize it's frustrating that the original discussion isn't going your way. But I'm happy to leave your level 2 section heading untouched now as a kind of consolation prize.
Given your preoccupation with section headings I wonder if you wouldn't be happier editing Sectionpedia, which consists entirely and only of section headings that you can add and adjust to your heart's content.
I've broken this off this side discussion into a separate section to help our esteemed fellow editors maintain their bearings in this increasingly bizarre maze of discussion of headings for discussions of headings.
Ha ha! Consolation prize and apology accepted, my good man. ;-) But I'm happy to let the original discussion take its fair course. That part of the MoS reads like a dog's breakfast. It is a long mishmash of boldface masquerading as headings and, well,
The MoS says date ranges should use an unspaced ndash or a spaced mdash (bot of which I agree with). However, it doesn't say whether we should use the unicode character (as given in the helpful toolbox just below the edit summary), the html entity – or the template {{tlx{ndash}}. Or is there no preference? Should we retain the existing variation, similar to WP:RETAIN and WP:DATERET? I find the unicode character easy to enter using the toolbox or via copy and paste from nearby text. I also find the other 2 choices quite cluttered that makes editing harder to read. Thoughts? — Preceding unsigned comment added by Stepho-wrs (talk • contribs)
Hmm, something must have changed since my last in-depth look here (plus I accidentally reversed en and em when I typed the above). Nevermind, thanks for the clarification. Stepho talk00:43, 5 August 2018 (UTC)
Fixed [2]. — SMcCandlish ☏ ¢ >ʌⱷ҅ᴥⱷʌ< 00:30, 22 November 2017 (UTC)
Grutness...wha? 00:45, 28 November 2017 (UTC)
You are invited to join the discussion at WT:JAPAN#Date formats. -- Marchjuly (talk) 05:23, 1 March 2018 (UTC)
.jpg)
Barrel emptying times is not something so easily quantified as quantity against time :-) -- PBS (talk)
Doing.... Primefac (talk) 21:17, 30 June 2018 (UTC)
