Wikipedia talk:Manual of Style/Dates and numbers

Petition to have dates start with the month, followed by the day

This discussion has been closed. Please do not modify it.
This is not happening and there's no point in wasting more of our time discussing why it won't happen. —David Eppstein (talk) 23:39, 2 March 2023 (UTC)
It has come to my attention that some don’t agree with having a month before the day (I.e. March 1, 2023) and would rather have it like this (1 March, 2023). Personally I think that is ridiculous, and we normally would have it the other way around. Is there any way to start a petition here on the wiki to allow these kinds of changes. Marino13 (talk) 18:56, 2 March 2023 (UTC) You keernaart be serious. Dondervogel 2 (talk) 19:38, 2 March 2023 (UTC) I’ll let more knowledgeable editors give a fuller answer, but this has been one of the longest-lived (and most contentious) wrangles on Wikipedia, since the American dating system (what you suggest) differs from that of other countries (e.g. Britain), and for that matter, the system used by the U.S. military. The convention that was reached that was articles that principally involve the United States or her people (e.g. New York City, George Washington) should follow the American convention (Month, Day, Year, or MDY), while articles principally about the UK and some other countries using her conventions (e.g., Queen Victoria, Trafalgar Square) should follow the British convention of day-month--year (or DMY). When there is no particularly or unique connection to either country (e.g. War of 1812), editors should follow the convention used by the first substantial contributor. Much more (and probably more clearly) at [1] —— Shakescene (talk) 19:46, 2 March 2023 (UTC) Wikipedia goes by consensus, not by American exceptionalism. See MOS:ENGVAR and MOS:DATEFORMAT. Muzilon (talk) 20:02, 2 March 2023 (UTC) What I'm hearing is that an American is insisting we do it the American way and screw the majority of the English speaking world that does it differently. As an Australian, I find the American date format ridiculous. It starts with the month, then goes into the more detailed day, then jumps back up to the less detailed year. Up-down-up-down-up-down - make up your mind. The D-M-Y system of consistently going from fine detail to the broad makes far more sense. The Chinese system of Y-M-D makes even more sense because their system flows into hours-minutes-seconds as well. And the M-D-Y system requires commas that the other systems don't need. So what you find natural is kind of unnatural to the rest of us and vice versa. In the past we had Americans "correct" the date format . Then a non-American would "correct" it back. And back and forth many times with much aggrevation. So eventually we made the WP:DATEVAR policy that says articles with strong ties to a predominantly English speaking country should use that country's date format. For all other articles (including those with only weak ties or ties to multiple countries) we keep the first date format that the article used when it was created. Ie, Wikipedia is an international effort and we respect that our fellow editors come from other countries that use different date formats. Or put it another way - how would you, as an American, like it if we said that all articles must use British dates, British spelling, British grammar.  Stepho  talk  21:07, 2 March 2023 (UTC) Wanders in innocently whistling But isn't it the English Wikipedia, so shouln't we use English spelling and grammar? Exits rapidly avoiding brickbats, dead dogs and insults from just about the whole globe ;-) Martin of Sheffield (talk) 22:34, 2 March 2023 (UTC) WP:SNOWCLOSE --𝕁𝕄𝔽 (talk) 23:26, 2 March 2023 (UTC)

Well, that answers that 🤦‍♂️.— Preceding unsigned comment added by Marino13 (talk • contribs) 08:33, 3 March 2023 (UTC)

Dates, months, and years / Formats

Why is the YYYY-MM-DD date format not allowed? What's wrong about saying The event occurred on 2004 October 30? :3 F4U (they/it) 22:44, 26 March 2023 (UTC)

There are no professionally edited English publications that use that format ("2004 October 30"), so the format will confuse readers. Our goal is to provide an encyclopedia to our readers without quirkiness that hinders understanding. Indefatigable (talk) 23:17, 26 March 2023 (UTC)

(edit conflict) @Freedom4U: There's nothing wrong with it; it's as valid as any other choice, but Wikipedia has made style choices to be as readable as possible and accessible around the world. That's meant that we've compromised and use both mdy and dmy (MOS:DATEVAR). If I were emperor, we'd all use YYYY-MM-DD (2004-10-30) and we'd all get used to it and go on and be a little more logical, but thankfully I am not. There are many compromises in an international encyclopedia and sticking with just two date styles (with a few exceptions) is one of them. SchreiberBike | ⌨  23:28, 26 March 2023 (UTC)

I wasn't asking because yyyy-mm-dd is "more logical" or anything like that, but because it just feels awkward reading DMY or MDY formatted dates when the article has clear national ties to Korea or China or Japan. With MDY, there's at least the month and day lining up, but the year still throws me off. :3 F4U (they/it) 23:44, 26 March 2023 (UTC)

I understand where you're coming from. I lived in China for a few years and I edit a lot of articles about Japanese cars. I love YMD. I'm also one of the most vocal supporters of yyyy-mm-dd being used in references. But even I stop at using it in English prose. It's simply not an English language format and it would be a distraction for the majority of international readers. There will also be many edit wars when Brits or Yanks "correct" it back to DMY or MDY.  Stepho  talk  02:30, 27 March 2023 (UTC)

ENGVAR controls big L or little L for litres/liters?

The one-l lama, He's a priest; The two-l llama, He's a beast. -- Ogden Nash

Right now our units table's got:

Group	Unit name	Unit symbol	Comment
Volume, flow	litre liter (US)	L (not l or ℓ)	The symbol l (lowercase "el") in isolation (i.e. outside forms as ml) is easily mistaken for the digit 1 or the capital letter I ("eye") and should not be used.
	millilitre milliliter (US)	ml or mL	Derivative units of the litre may use l (lowercase "el") as guided by WP:ENGVAR.

The "don't use lowercase ell in isolation" and as guided by ENGVAR bits both originate with this edit [2], which came on the heels of WT:Manual of Style/Dates and numbers/Archive 160#Litre abbreviation RFC. However, I don't see where the closer (who hasn't edited in a year) got the ENGVAR part -- nor do I know what it means.

I believe we should just drop the text as guided by ENGVAR. Thoughts? EEng 05:44, 27 March 2023 (UTC)

• Agreed - drop.  Stepho  talk  05:53, 27 March 2023 (UTC)
• Long ago in the mists of time the US National Institute of Standards and Technology had officially recommended that people in the US should use L rather than l as the symbol for liter. According to the most recent version of Special Publication 811, page 8, Table 6, footnote b, the General Conference on Weights and Measures (CGPM) has adopted L as an alternative symbol for the liter to avoid confusion with the digit 1. So I would say it used to be an ENGVAR issue, because the guidance to use L came from the US, but now that the main international organization, CGPM, endorses L, it is no longer an ENGVAR issue.

  I could go further and suggest that the English Wikipedia adopt L as the preferred symbol. Jc3s5h (talk) 16:04, 27 March 2023 (UTC)

  That's already what the first row of the table (above) says -- for the symbol standing alone i.e. without (for example) an m for milli. The question is the second row: what forms should be used for milliliter: ml or mL or it-depends-on-ENGVAR? AFAICS the outcome of the RfC I linked didn't support an ENGVAR angle -- I don't see where the closer got that -- so we should drop the text as guided by ENGVAR. If you want L to be used in all cases -- L and mL -- you'll need a new RfC, but please in the name of Jesus do not do that, at least not now. For now I'd really like to just get this odd bit of text dropped. EEng 17:17, 27 March 2023 (UTC)

• I also see no relevance of WP:ENGVAR. The closing 4 words (if engvar counts as a word) add nothing. Dondervogel 2 (talk) 17:50, 27 March 2023 (UTC)
• Go straight to "L". Drop the ENGVAR bit. — JohnFromPinckney (talk / edits) 18:42, 27 March 2023 (UTC)
• The Australian style manual says that either is acceptable but the capital L is preferred to avoid confusion. So I support dropping the ENGVAR bit. Hawkeye7 (discuss) 19:33, 27 March 2023 (UTC)

Now that I've had my coffee, I realize that (I think) we have (A) a solution that then leads to (B) a new problem. The solution (A) is to change

Derivative units of the litre may use l (lowercase "el") as guided by WP:ENGVAR.

to

Derivative units of the litre may use l or L (lowercase or uppercase "el"), with in-article consistency.

Are we all together on this?

But then here's the other problem: (B) Is "milliliters per liter" ml/L? or ml/l? -- or are both acceptable? (And now that I think about it, mL/L is a possibility too. But mL/l makes no sense at all, obviously.) I'm just previewing this (B) thing. Can we all agree on (A) above before we start debating (B)? EEng 02:09, 28 March 2023 (UTC)

• Let's just go for L everywhere (including derived units). Removes the complications altogether.  Stepho  talk  02:40, 28 March 2023 (UTC)

  Please, please, please, pretty please, let's just start by agreeing on (A). You can raise the idea of "L everywhere" later. EEng 03:38, 28 March 2023 (UTC)

  Yep - already agreed to (A) dropping mention of ENGVAR.  Stepho  talk  03:44, 28 March 2023 (UTC)

  Agreed. Support A. And "in-article consistency" rules out ml/L. Somebody please keep EEng away from the coffee before we get to "Y for Gaw'd sake" Hawkeye7 (discuss) 03:10, 28 March 2023 (UTC)

• No, the WP:ENGVAR text should not be removed, because there is a real-world WP:ENGVAR component to this. In Europe, including the UK and Ireland, the lower case l is the standard symbol for the litre. Having a capital L on UK- and Ireland-focussed articles would be almost as jarring as insisting on spelling it "liter". Kahastok talk 07:14, 28 March 2023 (UTC)

  'as jarring as insisting on spelling it "liter"' -- no, the opposite. "litre/liter" remains guided by ENGVAR. Undisputed here. The point & proposal is, that l/L has no ENGVAR base. Your "standard" claim is missing a link. DePiep (talk) 09:06, 17 April 2023 (UTC)

• Support (A) dropping the ENGVAR wording for the millilitre. Support (B), use consistently within article. Support eventual (C), explicitly standardise on only using the upper-case symbol L as the symbol for litres and all derived units (mL, cL, dL, ML, GL, and so on). The fact that the upper-case symbol was explicitly approved by the CGPM for the reason of avoiding ambiguity is sufficiently compelling for me to overlook the ENGVAR issue, especially given that this has already been done in the MOS for the litre itself. XAM2175 ^(T) 11:03, 28 March 2023 (UTC)
• No; I would agree with Kahastok that since there is an Engvar angle to the variations in usage, then the reference should stay. Having in-article consistency sounds fine (and is of course also achieved by Engvar) until we end up with a big argument over an article that has American or British usage but the opposite usage for the measurements within the article. That doesn’t sound particularly sensible, and simply sows seeds for unnecessary in-article misunderstanding and debate in the future. If the reason for supporting a change from ml to mL is simply because editors from the US are more familiar with the latter, then it’s clearly an Engvar issue and the sort of thing that WP:ENGVAR is intended to avoid or resolve. MapReader (talk) 12:02, 28 March 2023 (UTC)

  At the moment, however, we don't have consistency – the MOS mandates "L" regardless of ENGVAR, meaning that articles using both litres and millilitres can end up using "L" alongside "ml". As to "[if] the reason for supporting a change from ml to mL is simply because editors from the US are more familiar with the latter"; that rationale appears to be entirely absent from the discussion so far. XAM2175 ^(T) 12:11, 28 March 2023 (UTC)

  Not entirely absent, I’d suggest. However, more pertinently, on my visits to the US I haven’t seen any evidence that the litre/liter or measurements derived from it such as centilitres or millilitres are in common usage, or even understood, with food packaging and recipes referring to ounces and cups. As the WP article on the metric system says, “the United States is the only industrialised country where commercial and standards activities do not predominantly use the metric system”. Whereas ordinary people in other English-speaking countries are used to seeing metric measurements written on the things we buy from the supermarket and in recipes and countless other commonplace settings. Why would US editors want to impose onto the wider English-speaking world their own format for abbreviations of measurements that most of them never use? MapReader (talk) 12:35, 28 March 2023 (UTC)

  You're swinging a very broad brush with US editors, very broad indeed. Of the editors who have !voted in support and given their location in their user pages, one is in the US, one is in Scotland, and two are in Australia. Hawkeye7 has already noted that the Australian Government Style Manual explicitly prefers upper-case L for millilitres. I further note that the Canadian Government does as well. Even the UK Metric Association do, though I recognise that they're a campaign group rather than an official body. XAM2175 ^(T) 13:05, 28 March 2023 (UTC)

  • ml/L is completely unacceptable; ml/l is acceptable in principle but violates the principle of the close.
  • I support EEng's proposed edit.

  Dondervogel 2 (talk) 18:32, 28 March 2023 (UTC)

  The close definitely does not support the claim that "ml/L is completely unacceptable", and I sharply disagree with that claim. --Trovatore (talk) 22:29, 28 March 2023 (UTC)

  I was not referring to the close. It is unacceptable because it is against the spirit of the MOS, the aim of which is to "promote clarity, cohesion, and consistency". Use of ml/L achieves the opposite of that. Dondervogel 2 (talk) 06:30, 29 March 2023 (UTC)

  "Use of ml/L" is explicitly not part of the topic here. Will not be concluded upon. DePiep (talk) 09:09, 17 April 2023 (UTC)

• Since the idea of English Wikipedia preferring "L" in all cases, including with prefixes, is getting more attention than I expected, I will quote The International System of Units (V2.01, December 2022, Bureau International des Poids et Mesures, pdf with English text), page 145, Table 8, footnote d

The litre 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).

Jc3s5h (talk) 12:54, 28 March 2023 (UTC)

• No, it is an ENGVAR issue. For example, UK consumer packaging continues to use "ml" and "cl", in accordance with UK regulations (which remain aligned with European regulations).
  This proposal springs from a request at Template talk:Convert#Liter that {{Convert}} default to "L" rather than "l", which raised concerns that {{Convert}} would be in conflict with MOSNUM. NebY (talk) 13:35, 28 March 2023 (UTC)

  NebY and Kahastok, the UK law is that both ml and ML are allowed. Same for the other derivatives of litre. See https://www.legislation.gov.uk/uksi/1987/1538/made . Bizarrely, that official document says that "1 or L" are allowed for the litre - they use the number one instead of the letter lowercase letter el. However, I do recognise that all their examples and general usage in Britain use "ml", so this is a bit like Commonwealth English strongly preferring "realise" but allowing "realize".  Stepho  talk  15:33, 28 March 2023 (UTC)

  Just so. "mL" would be in accord with UK regulations - see also The Weights and Measures (Packaged Goods) Regulations 2006 - but "ml" is too and is the norm. NebY (talk) 16:58, 28 March 2023 (UTC)

  Exactly. And my point is that seeing these abbreviations in lower case is commonplace in Europe, including the UK, whereas for Americans it is mostly of academic (both literally and figuratively) interest how they are abbreviated, since outside the narrow scientific community no-one there uses them. MapReader (talk) 17:56, 28 March 2023 (UTC)

  In America most groceries are labelled in metric by law. You may well find some items labelled only in metric. Hawkeye7 (discuss) 19:54, 28 March 2023 (UTC)

  Soft drinks/sodas (1 and 2 liter bottles are very common) and alcoholic beverages (using both 'ml' and 'ML'), off the top of my head. Donald Albury 20:12, 28 March 2023 (UTC)

  I have a British education, have lived all my life in Europe, and was taught to spell "litre" (never "liter") and "metre" (except for the measuring instrument, a "meter"), and that "L" and "l" (and by implication "mL" and "ml") are equally valid alternative symbols. Engvar is a red herring. Dondervogel 2 (talk) 18:29, 28 March 2023 (UTC)

  This is the case in Australia and New Zealand too. "L (lower case l is permitted but is better to avoid)" [3] Hawkeye7 (discuss) 19:54, 28 March 2023 (UTC)

• Comment IRL masters matters preclude substantive participation on this matter, though I delight in having managed to spark a lively debate. What I suggest y'all do is start by reviewing the RfC I l linked above, to decide (1) whether the close was faithful to the discussion, and (2) whether the edit made to the guideline was faithful to the close. After making any corrections there, THEN start debating new ideas like "let's all go to L". Just my thoughts. EEng 14:41, 28 March 2023 (UTC)

  You're studying for a(nother) master's? But seriously, this is not a good way to challenge or overturn the close of an RFC. A recent close can be challenged by discussion with the closer or at WP:AN per Wikipedia:Closing discussions. Two years later? Launch a new RFC. NebY (talk) 16:55, 28 March 2023 (UTC)

  Before getting all formal, let's see if we can agree on what happened. To some extent the question is whether the close was flawed, but as much or more is the question of whether the edit reflected the close. I don't see at all where the ENGVAR text comes from. (But I've been run ragged recently so maybe I'm just not seeing it.) Fixing that wouldn't be challenging the close, just implementing it properly. EEng 17:12, 28 March 2023 (UTC)

  It's a good implementation that follows the reasoning of the close (which was good too) by applying the second of the three arguments against B analysed and assessed by the closer, the first having been rejected outright and the third being inapplicable given that there's no consensus re "ml". NebY (talk) 18:05, 28 March 2023 (UTC)

  Here's the actual text that you seem to be talking about in the close:

  As Option A is the status quo, this leaves Option B as the potential change to assess. The numerical vote is roughly 12-8 in favor of B (with two votes for option D and one vote for option C). The argument for B is primarily that it will avoid confusion with uppercase "I" and number "1". The arguments against B are threefold. The first is an argument against MoS guidances at all. The second is an ENGVAR argument. The third is that while "l" for litre should be discouraged, other abbreviations such as ml should be used. Regarding ENGVAR, capital L is not just an "Americanism", but is permissible everywhere and widely used outside of Europe; furthermore editors can still spell out litre in running text. As the third argument notes that lowercase "l" is confusing (as well as the voters for C and D), I find there is consensus to stop using a standalone "l" for litres.

  As I read this, the first two rationales are rejected, and only the third is partially affirmed. I don't see any support in the close for mentioning ENGVAR in the guidance. --Trovatore (talk) 23:28, 28 March 2023 (UTC)

  Right. That's my reading as well. Somewhere between making the close and doing the edit, the closer seems to have swept ENGVAR into the mix accidentally. I'm hoping we can all recognize that and get rid of the EMGVAR big, after which the floor is open for further refinement, and hopefully a final settlement of this accursed matter. (That further refinement might even include someone proposing that there should be an ENGVAR angle after all, but to repeat, that doesn't seem to have been any part of the outcome of the original RfC, so it's only fair to return to that base before opening the floor to new change proposals.) EEng 05:49, 29 March 2023 (UTC)

  Followup: My conjecture is that the closer was working on that row of the table, his eye fell on the left cell reading millitre / milliliter (US), and the idea popped into head that there's an ENGVAR issue (which there's not, because that row is about unit symbols, not unit names). EEng 16:58, 29 March 2023 (UTC)

• Yes, if all we are doing here is debating A, then I still support it. I am not convinced by the ENGVAR arguments of Kahastok and MapReader. In an extremely non-rigorous (or non-rigourous), non-scientific study, I painstakingly entered "irish liquid containers" und scanned through the images listed as a result. Of those large containers on which I could actually read the label, the very first was this one, which uses "2.5Ltr". I must confess I was confused momentarily by the "tr"; I was looking for "L", found it, and guessed "tr" meant something Irish. Guess I need coffee, too. I found no other large containers with this search. Small containers invariably use small "el", as in "70cl" or "450ml". But on I forged, with "british liquid containers": This sales image also uses 25L, although that's not exactly an RS. This wasn't scientific or extensive, but I'm not cherry-picking; I actually found few readable large-container labels. My findings are nevertheless that British and Irish usage probably tends toward writing out litres, or using "Ltr", but I'm not convinced the use of "L" would be "jarring", so I support A without mention of ENGVAR. The B part might be trickier. — JohnFromPinckney (talk / edits) 09:13, 29 March 2023 (UTC)

  As an aside, your gesture (or non-rigourous) is appreciated, but not actually necessary – Commonwealth and US spellings have come to align where the "-ous" suffix is concerned; thus it's acceptable that rigour becomes rigorous, valour becomes valorous, etc etc. Separated by a common language indeed! XAM2175 ^(T) 10:39, 29 March 2023 (UTC)

  As I mentioned above, there is no consistency in the US. Looking at an assortment of wine, liquor, and liqueur bottles, those of less than a liter use either "ml" or "ML", while those of one liter or more use "LITER(S)", either on the label or molded on the bottle. Both domestic and imported brands use either "ml" or "ML", but the labels, and often the bottles, of imported brands are produced in the US. Of the two bottles I have that were purchased in Europe (both with labels printed in English), the one from Greece uses "ml", while the one from Denmark uses "ML". There certainly is no consistent form in commercial use in the US. Donald Albury 15:56, 29 March 2023 (UTC)

  For the avoidance of doubt here Donald, ML, as opposed to mL, is the symbol for the megalitre; 1 ML = 1,000,000 L (264,172 US gal). A rather significant difference!

  (The discussion here would suggest that a British megalitre would have the symbol Ml, which I confess to my eyes looks exceptionally odd.) XAM2175 ^(T) 16:21, 29 March 2023 (UTC)

  Wow, one slip of the shift key and suddenly ... [4]. EEng 16:55, 29 March 2023 (UTC)<>/del>

  Yes, it is a shame that merchants and customers don't pay attention to official definitions. Should I sue the distributor because the bottle of wine says 750 ML on the label, but only holds 750 ml? I wonder if I could find a court that would allow me to pursue that case. Donald Albury 18:11, 29 March 2023 (UTC)

  I once saw a pharmacist in the US label a prescription in "Mg" rather than "mg"... XAM2175 ^(T) 18:16, 29 March 2023 (UTC)

  @Donald Albury: Be sure to check the settlement is paid in MUSD, not mUSD. Dondervogel 2 (talk) 19:26, 3 April 2023 (UTC)

  Note that the text in discussion is specifically about derivative units of the litre, particularly the millilitre. As such, the only piece of evidence you cite that is actually relevant to this discussion is Small containers invariably use small "el", as in "70cl" or "450ml". i.e. confirming the preference for lower-case ml and cl in Britain and Ireland, a preference that is not shared elsewhere. Hence, an WP:ENGVAR issue. Kahastok talk 18:21, 29 March 2023 (UTC)

  From my (American) perspective, mL comes off as a bit pedantic, though it does seem to be used in a majority of the bottles I checked around the house. I also found ml and ML. On the other hand L is pretty much obligatory, not for any nationalistic reasons, but because of the original sin of Wikipedia, namely choosing a sans-serif typeface as the default. --Trovatore (talk) 20:42, 29 March 2023 (UTC)

  Update on the last point: I tried editing my CSS to default to a serif font, and it turns out that lowercase ell still strikes me as looking too much like a numeral one to be usable for "liters". --Trovatore (talk) 20:48, 30 March 2023 (UTC)

  "l" and "L" for litre are not language or cultural at all (i.e., what ENGVAR is about). They are symbols, not words not even 'abbreviations', both defined per SI (without SI stating a preference). As editors we (wiki) are free to choose one. "Habits" do not tie us. Especially not when (1) oficially none is prescribed (UK, eg) and (2) when the issue is legibility not cultural.

  Sidetest: given the UK gov link here, "the" ENGVAR-UK form is not even defined. DePiep (talk) 09:26, 17 April 2023 (UTC)

• Coming a bit late to this, but FWIW my !vote is to support the proposal to drop the ENGVAR reference (I am not sure whether mathematical symbols can even be considered part of English, or any natural human language) as it seems pedantic and unnecessary. There's no reason we can't be consistent in recommending the use of "L", which (as pointed out above) is what most standards orgs do in any case. I don't recall seeing any authoritative body prescribing the use of "l" over "L", come to think of it. Moreover, it is not unreasonable to expect an editor coming to MOSNUM for advice on such usage to find it a bit confusing that they are instead referred to ENGVAR, which does not discuss anything related to units of measurement (nor should it). Archon 2488 (talk) 14:31, 3 April 2023 (UTC)

  For the record, I also support deprecation of the lower case "l". That would promote increased coherence within and between articles. I am not advocating a mass change from "ml" to "mL" in existing articles, but suggesting that a change in the other direction would be discouraged. Evolution, not revolution. Dondervogel 2 (talk) 21:57, 3 April 2023 (UTC)

• Given that IEC allows both, I would go with upper case, since it is easier to distinguish "L" from "1". --Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:49, 3 April 2023 (UTC)

  We're not talking about L vs l now. EEng 01:30, 4 April 2023 (UTC)

---

OK, just to count heads: Unless I'm missing something, only NebY objects to the proposal on the table -- which (to repeat) is to replace

Derivative units of the litre may use l (lowercase "el") as guided by WP:ENGVAR.

to

Derivative units of the litre may use l or L (lowercase or uppercase "el"), with in-article consistency.

NebY: before I unleash the mob to pummel you into submission, is there any possibility that Trovatore's response to you above (see #anchor) has convinced you to go along? And anyone who does object, but I missed, please speak up now (after considering, as mentioned, the above). EEng 01:30, 4 April 2023 (UTC)

Needless violent language here, EEng. DePiep (talk) 08:27, 21 April 2023 (UTC)

Needless comment born of your misreading of social cues three weeks after the fact, DePiep. EEng 12:37, 21 April 2023 (UTC)

You wrote it. It's agressive. If you mean something else, write something else. -DePiep (talk) 15:20, 21 April 2023 (UTC)

DePiep, you've been asked over and over to stop trying to referee the interactions of other editors, because you lack sufficient awareness of social cues to understand what's going on. I meant what I wrote, and I'm not going to use kindergarten baby-talk just because that's what you need in order to understand what everyone else readily gets. Really, just butt the fuck out of others' conversations -- see (among many examples) WP:Administrators'_noticeboard/IncidentArchive1018#EEng_agression. EEng 22:38, 25 April 2023 (UTC)

I see Kahastok and MapReader both arguing that it's an ENGVAR matter, and arguments that Ireland or Australia use "L" don't detract from that; ENGVAR has never been about a binary choice between AmEng and all the rest, and it should surprise no-one that sometimes BrEng differs from AusEng or IrEng. EEng, when you opened this discussion it was in terms that you weren't trying to overthrow the close of an RFC that's only two years old, merely its implementation, as if the two were separate and the implementation was by someone who misunderstood the close. I at least failed at first to appreciate that the closing statement and the implementation were by the same respected and experienced editor at the same time. Far from one editor misunderstanding another, what we have is User:力 being thorough and performing a close in two parts, a statement and an implementation. Together they make the totality of the close. You don't like the close of an RFC and it's too late to question the closer or take it to WP:AN for review? Ask a question directly in another RFC. NebY (talk) 17:59, 4 April 2023 (UTC)

I agree with this, both on the substantive point and the procedural point. Kahastok talk 19:04, 4 April 2023 (UTC)

The Australian manual of style given above says that L is preferable but that both L and l are acceptable, so that takes Australian out of the ENGVAR argument.

I didn't see an explicit Ireland reference above but I gave a UK (including Northern Ireland) reference that uses lots of lowercase examples but says both L and l are acceptable (technically it used the number 1 instead of lowercase el but that was probably a typo and not repeated in ml, etc). So the UK is also out of the ENGVAR argument.  Stepho  talk  22:22, 4 April 2023 (UTC)

I reiterate my strong opposition to classifying unit symbols, or any other mathematical symbols, in any context, for any reason whatever, as part of any variety of English or any other natural language. To anyone who objects, please explain to me what variety of English, or any other natural language, the statement "e^πi + 1 = 0" is written in.

And for emphasis: I oppose any attempt to push any MOS-level advice on the appropriate use of unit symbols to any part of the MOS other than MOSNUM. I would also note that no RS deprecating the usage of the symbol "L" in UK/IE (or any other, AFAICS) contexts have been cited, and at present we have nothing but the POV of a couple of editors against its usage. Archon 2488 (talk) 21:55, 4 April 2023 (UTC)

• I apologize for overlooking Kahastok and MapReader. I'm really distracted IRL and not hitting on all cylinders:
• As already stated, it's not that I "don't like the close", just I think the closer may have had a brain fart between the close per se and the edit meant to implement it. Tell me again where in the close per se there's anything about recognizing an ENGVAR issue?

EEng 04:05, 5 April 2023 (UTC)

I boldly implemented EEng's suggestion. My reason? The argument that ENGVAR is remotely connected with the choice of symbol is patently absurd, per Archon 2488. The whole point of international standard unit symbols is that they are international standard symbols. It does not matter whether one is writing in Spanish, French, Italian or any other language using a Latin alphabet. Beyond the alphabet, language is irrelevant. Dondervogel 2 (talk) 13:40, 5 April 2023 (UTC)

Not even confined to the Latin alphabet, actually! Archon 2488 (talk) 13:58, 5 April 2023 (UTC)

• Support. That's drop the text "as guided by ENGVAR" per OP. Also per proposal, this change should not decide on some preferred usage of "l" vs. "L". Just remove the text. ("consistent l or L in article" is trivial here, and should not be metioned). -DePiep (talk) 08:37, 17 April 2023 (UTC)

Crore

MOS:CRORE currently provides this advice (emphasis added):

• Provide a conversion to Western numbers for the first instance of each quantity (the templates {{lakh}} and {{crore}} may be used for this purpose), and provide conversions for subsequent instances if they do not overwhelm the content of the article. For example, write three crore (thirty million). When converting a currency amount, use the exchange rate that applied at the time being written about; the {{INRConvert}} template can be used for this purpose.

But WP:ICTF#Films says that there is consensus that {{INRConvert}} should not be used in list-type articles or in infoboxes (at least for Indian film-related articles).

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.

I had started using {{INRConvert}} in Indian film articles based on MOS:CRORE. It wasn't until later that I saw WP:ICTF#Films and realized what I was doing was counterproductive.

So, I wonder we should add something to the current writeup at MOS:CRORE to acknowledge or note this "consensus" about avoiding {{INRConvert}} in list-type articles and infoboxes?  — Archer1234 (t·c) 16:01, 30 March 2023 (UTC)

Strictly speaking, the provisions at MOS:CRORE override the WikiProject consensus, per WP:CONLEVEL. It might be possible to alleviate the infobox clutter concern (number 3) by footnoting the conversion, and the problems with inflation concern (number 2) is already addressed by MOS:CRORE where it says use the exchange rate that applied at the time being written about.

That just leaves concern number 1, which MOS:CURRENCY leaves open to lower-level consensus: in non-country-specific articles, such as Wealth, use US dollars (US$123 on first use, generally $123 thereafter), euros (€123), or pounds sterling (£123). XAM2175 ^(T) 01:41, 31 March 2023 (UTC)

One of the main concerns I have about using INRConvert in the infobox is the clutter, but not just in the infobox. The conversion would be in the infobox and in the article lead, toward the bottom, which generally is quite close to where the conversion in the infobox will be. That feels like content overload for the reader. Keeping a fairly clean infobox presents relevant information to the reader, with easy access to the conversion in the lead mitigates that without giving an undue burden. Ravensfire (talk) 03:06, 7 April 2023 (UTC)

Don't use crore in those circumstances; MOS:CRORE and MOS:COMMONALITY both discourage it, and it makes the article less accessible. BilledMammal (talk) 05:10, 7 April 2023 (UTC)

MOS:DATEUNIFY and MOS:DATEVAR should be more explicit about template parameters

There are various editors running around changing all of the «YYYY-MM-DD» date formats in citation template parameters to e.g. «D Month YYYY» format (e.g. using the script User:Ohconfucius/script/MOSNUM dates). At best, this is in my opinion a pointless waste of attention, because these templates already have logic to render dates into whatever desired human-readable format, so these edits do not affect the output seen by article readers in any way, but only change the source markup.

But in my opinion these changes are actively harmful, because the whole point of these templates is to be a structured format which is accessible to both human readers and to automated tools. The clear, concise, lexicographically sortable, unambiguous, standardized «YYYY-MM-DD» format is an international standard (ISO 8601) for machine-readable metadata for good reasons. Many existing bots emit this format in these template parameters, the same or similar formats is widely adopted outside Wikipedia (for example, the Internet Archive's Wayback Machine has dates in «YYYYMMDD» format as part of archive URLs, making it trivial to copy-paste into the "archive-date" parameter and just add hyphens) and anyone trying to do anything with the template markup, either manually or using a computer program, benefits from having a numeric «YYYY-MM-DD» format, which is much easier to work with than alternatives when dealing with many dates at a time as metadata per se.

At the very least, the MOS should directly state that «YYYY-MM-DD» dates in template parameters should not be changed by script to the same format as plain-text dates in article body copy / plain wiki-markup dates in citations. In my opinion it would even better to explicitly nudge editors to change other date formats to «YYYY-MM-DD» format in the context of template parameters; but I don’t care strongly enough about this to try to make any kind of site-wide policy about it. –jacobolus (t) 18:01, 3 April 2023 (UTC)

Seconding this. While other formats can be allowed if they are in line with the article's format, YYYY-MM-DD should be listed as the preferred format, and scripts should not change this.

These edits (eg, changing date=2023-04-03 to date=3 April 2023) actively harm translation efforts by making it more difficult to translate citations. Wracking ^💬 18:20, 3 April 2023 (UTC)

Dates in the YYYY-MM-DD format may be false for dates earlier than 1923; the further back, the greater the likelihood of a falsehood. Jc3s5h (talk) 18:53, 3 April 2023 (UTC)

(edit conflict)This should be a non-discussion, MOS already specifically permits YYYY-MM-DD:

* Access and archive dates in an article's citations should all use the same format, which may be:

• • the format used for publication dates in the article (see above);
  • the format expected in the citation style adopted in the article; or
  • yyyy-mm-dd

— and it is really annoying when a fly-by bot changes date formats and triggers a watchlist entry just for an unnecessary date change. Martin of Sheffield (talk) 20:28, 3 April 2023 (UTC)

Why wouldn't this equally apply to any other date format? –jacobolus (t) 21:22, 3 April 2023 (UTC)

I'm fine with articles that consistently use either MDY or DMY in prose and consistently use YYYYMMDD in the references. I don't think I've ever come across such an article, and the fact that RefToolbar, the default source editing citation tool, defaults to DMY means that many articles are inconsistent. When faced with an inconsistent article, I think using the available script to unite the style across the prose and references is an improvement. Editors are already discouraged from doing so in a bot-like manner if the changes are only cosmetic (i.e. only to the references). Firefangledfeathers (talk / contribs) 20:39, 3 April 2023 (UTC)

I am extremely annoyed by editors who use the date unification script to change numeric dates to spelled-out dates in articles that use the |cs1-dates= parameter of the date format template to specify that the dates should be numeric. The script to unify these dates is broken, because it cannot handle this standard numeric format even when the article explicitly specifies it as the format. But despite years of complaining about the script being broken, editors persist in using it and riding roughshod over WP:DATEVAR. I don't care whether you think it is an improvement. Unless this long-broken script can be properly fixed, it needs to stop. —David Eppstein (talk) 21:11, 3 April 2023 (UTC)

You and I are not talking about the same cases. I also would oppose the changes you're talking about. Firefangledfeathers (talk / contribs) 21:20, 3 April 2023 (UTC)

What cases are you talking about? I'm a bit confused. Wracking ^💬 21:42, 3 April 2023 (UTC)

I provided an example below in reply to jacobolus. Firefangledfeathers (talk / contribs) 22:45, 3 April 2023 (UTC)

Examples of four different users incorrectly changing consistently-formatted numeric access dates into spelled-out dates using a script: Special:Diff/947500508 (2020), Special:Diff/1032832144 (2021), Special:Diff/1117477199 (2022), Special:Diff/1145374634 (2023). I'm not sure these are all using the same broken script but at least some of them are Wikipedia:MOSNUMscript, exactly the same broken script that you (Firefangledfeathers) have linked to in your own recent script-date-change edit summaries. The script talk page indicates that the developer has refused to fix the script when this issue is raised and instead thinks of it as a user error. —David Eppstein (talk) 21:46, 3 April 2023 (UTC)

I looked at your first diff. First, it was not tagged with the cs1-dates parameter, so it doesn't seem aligned with your use case. Second, since no "use XXX dates" template was present, the page was displaying different formats for the date= and accessdate= parameters. I don't see that as a good thing, and it wouldn't have occurred to me that the date style was consistent. If there's a reason to stick with that sort of consistent inconsistency, I'd be glad to know about it and will change my practice moving forward. Firefangledfeathers (talk / contribs) 22:45, 3 April 2023 (UTC)

The "first diff" in question here could have limited itself to only adding {{Use mdy dates}} at the top of the page and the effect for readers would have been identical; changing numerical dates to spelled out «Month D, YYYY» format was unnecessary. –jacobolus (t) 23:04, 3 April 2023 (UTC)

Perhaps the MOS should directly recommend that all pages include a "use XXX dates" template with cs1 parameter set on it, to be added any time someone wants to make a significant modification to date formatting. I doubt anyone would have a problem with an edit setting |cs1-dates=XX on a page where the templates are currently rendering dates inconsistently. –jacobolus (t) 22:58, 3 April 2023 (UTC)

When I created the auto-date formatting for cs1|2, it was my intention that there would not be a need for a script to fiddle with date formats in cs1|2 templates because those templates would follow the format specified in the {{use xxx dates|cs1-dates=<format>}} templates. If I recall correctly, for a time, the script did not fiddle with cs1|2 dates; it reformatted dates in the prose and left the cs1|2 date formatting to cs1|2. Editors did not like that so now we have the situation where the script ignores |cs1-dates=.

—Trappist the monk (talk) 23:25, 3 April 2023 (UTC)

The second and fourth examples are definitely bad edits. In both cases the {{use xxx dates}} templates had valid |cs1-dates=ly parameters indicating that the correct formats for cs1|2 templates in those articles is long-form format for publication dates and YYYY-MM-DD format for access and archive dates as allowed by MOS:DATEUNIFY. The script should not be ignoring |cs1-dates= when it has a value so I concur: for these edits the script is broken. The other two examples are correct edits in that a {{use xxx dates}} was not present before the script edited the articles so the script could not know to preserve YYYY-MM-DD access and archive dates unless the script operator instructed it to do so; I don't know if the script has the ability to accept that sort of instruction from the operator; if it doesn't, it should.

—Trappist the monk (talk) 23:25, 3 April 2023 (UTC)

All four are bad edits, and the script should be fixed to not make edits of this type. –jacobolus (t) 07:04, 4 April 2023 (UTC)

@Firefangledfeathers: Re "the page was displaying different formats for the date= and accessdate= parameters": YES. DELIBERATELY. THAT IS A CONSISTENT DATE FORMAT. It is a date format explicitly allowed in MOS:DATE. It is exactly the date format described by cs1-dates=ly. It should not have been changed.

Re: "not tagged with the cs1-dates parameter": this makes no difference to the script's behavior. And it should not be necessary to tag an article that is in a consistent date format, in order for it to be recognized as consistent and left unchanged. In fact this diff was one of several things that convinced me that was necessary to tag every article I created. There are two reasons, only one of which is the misbehavior of editors like you who run this broken script and then, just like you above, insist that it was merely making things consistent, ignoring the fact that they were already consistent before. The other reason is that that these editors, and maybe some others, will then tag the article with a use-dates template that omits the cs1-dates= parameter, and this omission causes all the citation templates to convert the numeric dates to spelled-out dates in the same way. By starting all new articles with a use-dates template with a cs1-dates parameter, I can preempt the editors who think that this template should somehow be mandatory but fail to match it to the consistent date format already in place. But the template should not be mandatory, it should not be needed to stop the broken script from converting one consistent format to another, and in fact it is not sufficient to stop the broken script from converting one consistent format to another. —David Eppstein (talk) 06:05, 5 April 2023 (UTC)

👍 Firefangledfeathers (talk / contribs) 11:15, 5 April 2023 (UTC)

What advantage specifically do you see in having the template markup for a citation say e.g. … |archive-date=2 September 2022 |… instead of … |archive-date=2022-09-02 |…, assuming that the reader is going to see "2 September 2022" either way? Why is this an improvement? –jacobolus (t) 21:30, 3 April 2023 (UTC)

I don't see any advantage to that change. One where I do: assume the article is tagged with Template:Use mdy dates. The first ref has ...title=ref1 |archive-date=2 September 2022 ... . The second ref has ... |title=ref2 |archive-date=September 10, 2022 .... I would favor a change to unify the date styles, just for the very minor benefit of code readability. Since it's a cosmetic change, I wouldn't make the edit unless bundled with an edit that actually changes the displayed page for readers. Firefangledfeathers (talk / contribs) 22:45, 3 April 2023 (UTC)

If the article has {{use mdy dates}} at the top, then this change will not affect readers, because the template will already standardize the output. But to make the markup most legible/useful I would personally recommend switching these to … |archive-date=2022-09-02 |… and … |archive-date=2022-09-10 |… , respectively. –jacobolus (t) 23:09, 3 April 2023 (UTC)

• When the book or website being cited has a date on it, should this not be the format used for |date=? OK, I'll accept a conversion from Roman numerals to Arabic, but otherwise it should be copied as is. Access and archive dates on the other hand are subject to the Access and archive dates section of MOS, quoted above. Martin of Sheffield (talk) 07:37, 4 April 2023 (UTC)

  I'm sorry, but that's silly. A date is information, not a form of expression (as text is), and while we are unavoidably forced to choose a date format for any particular article, the whole reason for doing so is so that the information in the article's various dates will be presented in a way that's as unobtrusive as possible, and that means not varying the format willy-nilly. EEng 13:37, 4 April 2023 (UTC)

MOS:DATED proposal "a recent study"

I think MOS:DATED (and perhaps also MOS:RELTIME) should include a note about adjectives such as recent in phrases such as a recent study, which I see all the time. Case in point: I changed A recent synthesis gives to A synthesis by Harper (2017) gave. MOS:DATED is focused on adverbs such as recently and currently, but also has present, upcoming and ongoing that could be used both adverbially and adjectively, and already features the adjective example she is the current director. I think we should add a sentence about replacing a phrase like a recent study with example solutions such as a 2017 study or a study by Foo (2017).

I think we should also add an extra alternative to the example of she is the current director, namely one with the formulation has been (or plural have been), which is already commonly applied, e.g. she has been director since 1 January 2023. This is to cover ongoing situations that have a known starting date, but an unknown ending date, which may or may not have already passed. Terms and tenures of certain offices or positions such as director are typical examples of that. They may not have set end-dates (e.g. directors of companies or organisations which they (co-)founded themselves can often remain director indefinitely until they pass the position to someone else at some point at their pleasure), and even positions with fixed terms may be extended (due to re-election or reappointment for another term) or cut short (due to resignation, removal from office, death, or otherwise).
Situations in which a sportsperson or tallest building or whatever is the current (world) record holder are similar: it is uncertain how long they will remain the current record holder. Apart from formulations such as She set a world record in fooing in 2023 or Foo is the tallest building in Fooland as of 2023, a has/have been formulation can be useful, especially in articles that are not frequently updated. So the formulation has/have been is a good solution to indicating when a tenure began without necessarily saying it is still ongoing (or has already ended) whenever that is unknown, or whenever it can in fact be known from reliable sources, but hasn't been updated yet. (Once it is known, it can always been changed to had been, if that makes narrative and grammatical sense). Cheers, Nederlandse Leeuw (talk) 10:08, 4 April 2023 (UTC)

You're quite right about "recent" and I would even avoid she has been director since 1 January 2023, preferring she became director on 1 January 2023 (was appointed, was promoted to, ...). Some editors may be happy using {{As of}} eg {{as of|2023|01|01|lc=on}} as of 1 January 2023 or even {{as of|2023|01|01|lc=on|since=y}} since 1 January 2023, but even that's less durable. NebY (talk) 18:19, 4 April 2023 (UTC)

I agree. Nederlandse Leeuw (talk) 11:51, 5 April 2023 (UTC)

Like the above, I prefer simple past to any perfect tenses, as things like the present perfect still imply conditions which may or may not be true any longer. "She became such and such" is much better than "She has been such and such since" because that still implies we have knowledge of the present condition, which the article may not. --Jayron32 13:25, 5 April 2023 (UTC)

I very much agree with NebY and Jayron32. Whenever I see "since" or "has been", I think to myself "as of when?" or "until what date?", and sometimes even check the refs (if any, hah) when I'm in pure reader mode, to see (guesstimate) how out of date the statement might be. — JohnFromPinckney (talk / edits) 14:25, 6 April 2023 (UTC)

There are other, equally damnable, words and phrases. Not very long ago, I had to correct an article that said (my emphasis) "the couple currently live in Anytown with their teenage children". The statement was add in (and cited to cited to a source dated) 2014.

Also, every January, it pays to do a search for "this year", "last year" and "next year". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:12, 10 April 2023 (UTC)

Line wrapping and units

Is there a sound reason why we require that "...a normal space is used between a number and a unit name" and not a non-breaking space? To me, it looks wrong (doubly so where the figure is a single digit), and I strongly suspect it hinders readability. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:03, 10 April 2023 (UTC)

It seems a bit odd, yes. It's also inconsistent with how the MOS treats constructions like "21 million", where MOS:NUMERAL holds that a non-breaking space should be used. XAM2175 ^(T) 12:38, 10 April 2023 (UTC)

MOS:DECADE vs MOS:CENTURY

Over at List of fatal crowd crushes, the format of the article is confusing regarding the year 2000. Events from 2000 are included in the sub-heading "The 2000s", which is under the heading "The 21st century". This pretty clearly goes against MOS:CENTURY, which proscribes that the year 2000 belongs to the 20th century.

We could try using only one system in the article, but neither result seems satisfactory. If we removed "2000s/2010s/etc", we end up with awkward 10-year groupings like "2001-2010" and "2011-2020", which are completely unnatural. We could remove "17th/18th/etc century", and instead write "1600-1699" and the like, but that seems esoteric, and also a bit unnatural... Is there an elegant solution here I'm not seeing? Are all or most list articles like this? PhotogenicScientist (talk) 22:00, 18 April 2023 (UTC)

PhotogenicScientist, this is a good question. what if, under the table for "20th century", an entry was placed at the bottom that stated "for the year 2000, see § 2000s"? better yet, the entries for the year 2000 could be moved to the table for "20th century" instead, and an entry at the top of the table for "2000s" could state "for the year 2000, see § 20th century", because the year 2000 is in the 20th century and not the 21st century. to avoid sorting issues, code like the following could be used.

colspan="6" align="center" data-sort-value="" | ''for the year 2000, see {{section link||20th century}}''

different lists seem to have tackled the issue differently. the list of floods mentions a flood in the year 2000 under the 19th (!) century heading, does not have a 20th century heading, and completely ignores the 2000 flood under the 2000s heading. (it also mentions a 1900 flood under the 19th century heading, and an 1800 flood under the 18th century heading.) the list of building or structure fires mentions all the relevant fires of 2000 under the 2000s heading and completely ignores them under the 20th century heading, but it also mentions all the relevant fires of 1900 under the 20th century heading.

by the way, i think you mean "prescribes" rather than "proscribes". they are pretty much antonyms, but people often confuse the two, so the mistake is understandable. dying (talk) 23:30, 18 April 2023 (UTC)

Wow, that floods article is ridiculous lol. I made what quick corrections I could there.

Thanks for bringing up those two examples - they give me some ideas. Personally, I think it makes sense to include years ending in '00 in the century with the years after it. That's how we celebrate, after all - January 1 2000 marked the start of the 21st century, and the new millennium, to pretty much the whole world. And that just makes sense - the number in the hundreds place changes, so it feels like a new century. But apparently, this is some grand academic debate, spawning because there was no year 0 AD, and so the "first century" or first group of 100 years was necessarily 1-100 AD...

Anyways, I suppose that means I'd be in favor of amending MOS:CENTURY, as above. (also, thank you - I'll stop using proscribes wrongly :))PhotogenicScientist (talk) 13:39, 19 April 2023 (UTC)

No it didn't. The year 2000 was the last year of the 20C, the 21C started on 1 January 2001. It's not really "some grand academic debate"; count your fingers: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. You don't say you have two-and-a-fifth hands now, do you? For years, the first decade was 1-10, the first century 1-100 (otherwise it wouldn't be a century) and take it from there. Martin of Sheffield (talk) 13:52, 19 April 2023 (UTC)

That's how we celebrate, after all - January 1 2000 marked the start of the 21st century, and the new millennium, to pretty much the whole world. And that just makes sense - the hundreds number changes, so it feels like a new century. So, did you just miss this part? Or did you purposefully ignore it? Because I feel I demonstrated that I can count in 10s and 100s by acknowledging the source of the issue.

I don't know if you were alive at the time, but pretty much everyone everywhere on Jan 1 2000 was celebrating the turn of the millennium (and the century). PhotogenicScientist (talk) 14:04, 19 April 2023 (UTC)

Not only alive at the time, but I'd been warning about and mitigating against, Y2K at work since the 1980. New Year is a nice excuse for a booze-up whatever the numbers, and I joined in the Y2K celebrations, but never referred to it as the start of the new millennium. That's simply mathematically and logically wrong. there really isn't any need for discussion, you can use whatever personal definitions of a millenium you want, but it is correctly a period of 1,000 years, not 999. Martin of Sheffield (talk) 14:17, 19 April 2023 (UTC)

That's simply mathematically and logically wrong. Correct. But is it Wikipedia's calling to be "exactly, logically correct" or "approachably, familiarly correct," in cases like these where there is conflict, perhaps outright contradiction, between the two?

You can say that you yourself never referred to 2000 as the start of the new millennium, but I imagine you're in scant company there. I imagine there are others, like you and me, who have different opinions on how the year 2000 should be treated. Which is why I disagree that there really isn't any need for discussion. PhotogenicScientist (talk) 14:26, 19 April 2023 (UTC)

I suggest changing the heading 19th century to 1800-1899, 21st century to 2000–present, etc. That being disposed of, I have a question, PhotogenicScientist: are you by chance scientist/supermodel Symmetra [5]? EEng 15:10, 19 April 2023 (UTC)

I appreciate the input. That being said, no, that person is not me - but I did have a sensible chuckle at that mailing. PhotogenicScientist (talk) 15:49, 19 April 2023 (UTC)

(edit conflict) I doubt that we're ever going to agree, but in response to your (possibly rhetorical) question: 'is it Wikipedia's calling to be "exactly, logically correct" or "approachable, familiarly correct,"' then I would say the former. There are plenty of cuddly social sites where accuracy is secondary, but Wikipedia strives to be an encyclopaedia where precision and truth are fundamental. All IMHO of course. EEng who has just edit conflicted with me, has the correct answer. Martin of Sheffield (talk) 15:14, 19 April 2023 (UTC)

That's quite alright - my intention isn't to convince people to agree with me. Only to start a discussion and see where the opinions of others lie.

A minor quibble, though, with Wikipedia strives to be an encyclopaedia where precision and truth are fundamental: Wikipedia is a compendium of that which is verifiable in reliable sources, and not necessarily of that which is true. If there's a preponderance of reliable sources asserting something to be true, then Wikipedia follows. This may at times be at odds with what could be considered the "absolute truth" of a matter.

As that pertains here, "the public at large" might not be considered a reliable source to base our content on. But what about basing our practices/formatting? The public at large is our primary customer - the reason WP exists is to share knowledge with them. If our formatting could change to improve the transfer of knowledge to readers, that would be a benefit worth considering. PhotogenicScientist (talk) 15:59, 19 April 2023 (UTC)

The problem that no one wants to address is that "the 1900s" way of naming a century and "the 20th century" way of naming a century do not have the same years. If we call our centuries "the 1800s" or "the 1900s" we're delineating our centuries based on the left-most two digits of the number. If we're calling it "The 20th century", we're delineating it based on counting from "year 1", where "years 1-100" were "the first century". You'll note that this means that "the 1900s" is close to, but not identical to "the 20th century". Notably, this means that the year "2000" is in "the 2000s century" AND in the "21st century". If you categorization scheme doesn't take this into account, you're going to need to make adjustments. In this case, it may be best to just remove all mentions of the "Ordinal" century and use "1900s" and "2000s" and don't use the terms "20th century" or "19th century", because it's actually impossible to mix the systems and be accurate. --Jayron32 15:31, 19 April 2023 (UTC)

I went source-hunting, and have collected those that seemed the most reputable and reliable. In short, it seems the mathematicians and pedants have an iron grip on the press - reliable sources, by and large, strictly adhere to notion that year 2000 belongs to "the 20th century."

• Library of Congress
  • Contains my favorite quote, which very succinctly sums up my thoughts: "When does the century end? This simple question has such a simple answer that the very existence of a dispute is puzzling... Yet many find the truth of the matter so unacceptable that the resulting controversy has generated a considerable literature."
• USN Astronomy department
• Scientific American
• LA Times article from 1988
• timeanddate.com

I find myself leaning toward using "Xth century" nomenclature less, due to its inherent incompatibility with decade nomenclature...

Should we amend WP:CENTURY to recommend that preference in writing? PhotogenicScientist (talk) 20:59, 19 April 2023 (UTC)

How many years are there in a century? When, in your opinion, did the first century CE begin and end? Are the answers compatible? -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:52, 20 April 2023 (UTC)

What's "CE"? EEng 14:35, 20 April 2023 (UTC)

@Chatul: 100. The CE/AD system has no Year Zero, so the first century ran from 1 CE to 100 CE. The first decade ran from 1 to 10, the second from 11 to 20 and the 20s ran from 20 to 29. Of course the answers aren't compatible. --𝕁𝕄𝔽 (talk) 15:22, 20 April 2023 (UTC)

The CE nomenclature is intended to match the year numbers of the AD nomenclature while reducing the religious friction with the term "Anno Domini". The AD system was invented by Christians before the Orthodox Christians and the Protestants split away from the Roman Catholic Christians, so it belongs to all Christians, with the possible exception of denominations that split away before 525 CE, when the AD system was invented. Since these Christians do not have a mechanism to resolve differences today, there is no answer. Jc3s5h (talk) 16:00, 20 April 2023 (UTC)

Getting back to the original point and ignoring (for now) the PC issue. It's important to remember that year, decade, century and millennium numbers are ordinal numbers, not cardinal. We use cardinal numbers for complete years. Consider a child born at 00:00 on 1 January 2000. For the whole of 2000 he is in his first year, but aged 0. During 2001 he is in his second year, aged 1. During 2009 he is now in his tenth year, but is a 9 year old. As I write he is well into his 24th year, as befits a 23 year old. When his parents talk about 1999 it would be the first year before he was born.

A very old-fashioned way of talking about years (common prior to maybe 1800) would be to describe the year 2000 as "in this the 2000th year of Our Lord", and not as "Jesus is 2000 years old" (ignoring totally that the date of Jesus' birth was not 1 January 1 AD). There is no need for a "year 0". We went from the first year before Jesus' birth to the first year after Jesus' birth. To assign a year 0 would imply it was neither before nor after the birth, and if that had have lasted a full year I think it would have been mentioned! Martin of Sheffield (talk) 21:35, 20 April 2023 (UTC)

Actually, ordinal numbers start with 0. Anyone who gets that wrong is probably a Fortran programmer. See picket-fence problem and off-by-one error. --Trovatore (talk) 23:23, 20 April 2023 (UTC)

ordinal number is real in Fortran. Hawkeye7 (discuss) 00:22, 21 April 2023 (UTC)

Let me see: PL/1, BASIC, FORTRAN, COBOL, Z80 assembly, VAX Macro, Macro-64, C, C++, PHP, Perl, Python ... Hmm, I must fit your description! Martin of Sheffield (talk) 07:17, 21 April 2023 (UTC)

PL/I? PL/I is perfectly capable of doing 0-based indexing. DECLARE FOO(0:BAR) FIXED BIN; -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:20, 21 April 2023 (UTC)

I think Martin is saying that he's used a lot of languages, including Fortran. Fair enough, but you'd think that much experience would have convinced him that 0-based is superior. --Trovatore (talk) 16:48, 21 April 2023 (UTC)

Exactly. But language capabilities are not really relevant which is why the discussion is in small type. Martin of Sheffield (talk) 20:21, 21 April 2023 (UTC)

But what is relevant, to the point you yourself brought up, is that ordinals start with 0. --Trovatore (talk) 20:22, 21 April 2023 (UTC)

See Ordinal numeral Martin of Sheffield (talk) 20:25, 21 April 2023 (UTC)

... and zeroth. You're emphasizing the difference between ordinals and cardinals, but using a linguistic convention for ordinals that evolved before the idea of zero was well understood. That's not terribly convincing. Or rather, it's fine, if your point is that it all comes down to language -- but you could have just said that; it's not clear what the ordinal/cardinal distinction adds to the point. --Trovatore (talk) 20:29, 21 April 2023 (UTC)

Right let's simplify this.

1. A cardinal number is a simple number which reports the number of items. It has a zero. Consider: "how many eggs do you have?", "six". If you give six away you have zero eggs.
2. An ordinal number represents an order. It does not have a zero. Consider: "where did you finish in the race?" "first". No-one came in before the first runner.
3. When recording an age or similar you use cardinal numbers to record the number of complete years: "He was 21 last birthday".
4. When recording dates (days, months or years) you use ordinal numbers to record the position of the date: the 1st of January, the fourth month, the 100th year.

Clearer? Martin of Sheffield (talk) 20:59, 21 April 2023 (UTC)

Your point 2 is incorrect. Or more precisely, it's specific to the way language has developed, and has nothing to do with numbers. If the notion of zero had been developed in time, we would say that the winner finishes zeroth. --Trovatore (talk) 21:05, 21 April 2023 (UTC)

Right - even the section they linked for ordinal number lists "zeroth" first among "common ordinals".

This is not a problem caused by math - it's a problem caused by language. PhotogenicScientist (talk) 21:19, 21 April 2023 (UTC)

"It's specific to the way language has developed" – well of course, it is after all linguistics which describes the language! It's not a problem, it is simple English usage, as taught at secondary school. As regards the link, "Zeroth only has a meaning when counting starts with zero, which happens in a mathematical or computer science context. Ordinal numbers predate the invention of zero and positional notation." BTW Who else linked this?Martin of Sheffield (talk) 21:28, 21 April 2023 (UTC)

If you're saying it's about language, you could just have said that directly. By focusing on ordinals vs cardinals, it seemed like you were trying to make it about numbers. Numbers are a priori; language is contingent. --Trovatore (talk) 23:05, 21 April 2023 (UTC)

I disagree that ordinal numbers always exclude 0. Ordinal numbers are numbers that can be meaningfully ordered. The year 1 undoubtedly comes after the year 0, so there is a definite order. Cardinal numbers, on the other had, are used to count indistinguishable things such as the number of eggs in a carton. (But there is no year 0 in the AD/BC or CE/BCE system.) Jc3s5h (talk) 05:55, 21 April 2023 (UTC)

In fact, from the perspective of set theory, all cardinals are ordinals, and that include 0 (null set). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:20, 21 April 2023 (UTC)

ITYM empty set. --Trovatore (talk) 20:26, 21 April 2023 (UTC)

Had I written a null set, you would be correct. Despite some comments on wiki, the use of the null set in set theory was not created by the K-12 set; see, e.g., Dugundji, James (1966). "1 Sets". Topology. Allyn and Bacon, Inc. p. 2. ISBN 0-205-00271-4. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 00:36, 23 April 2023 (UTC)

That usage is essentially nonexistent in research mathematics. If you want to be understood you must say "empty set". --Trovatore (talk) 18:20, 23 April 2023 (UTC)

It is important to remember that a century hass 100 years, including the first century. Unless you want to decree that the first century CE only has 99 years, you're pretty much forced to accept that xx00 is the last year of a calendar century, not the first. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 10:20, 21 April 2023 (UTC)

That was Steven Jay Gould's reasoning for saying the 21st century began with the year 2000, but as much as I admired him, he was wrong on that. Donald Albury 12:13, 21 April 2023 (UTC)

Not so much "decree" but rather "acclaim world wide by having massive parties and celebrations beginning December 31, 1999." Jc3s5h (talk) 13:34, 21 April 2023 (UTC)

MOS:£

I have some proposals to clean up some ambiguous/poorly worded language relating to MOS:£.

• For Britain's currency, sterling, use the £ symbol (U+00A3 £ POUND SIGN). Do not use U+20A4 ₤ LIRA SIGN, which is a legacy code point for a series of HP printers (Whether a pound sign has one or two bars is purely a typeface (font) choice: the code point is always U+00A3, irrespective of appearance.)

Because of the "LIRA SIGN" code point some have taken it to mean that "£" and "₤" are entirely different characters, I feel it needs to be made more clear that the only reason for "₤" having a separate code point at all is because of the Roman-8 character set.

At present it also entirely breaks with discussion of the pound sign mid-way through to go on a tangent about the abbreviation "stg" then reverts for some reason, when it would have been more appropriate to mention it in the section below; my draft of which is here:

• An unqualified £ sign always means sterling on Wikipedia. Abbreviations such as £stg or £ stg are best avoided. Do not use GB£.

"Best avoided" is far too ambiguous a phrase for "GB£", because this construction is not found in any WP:RELIABLE SOURCES. "£stg" and "£ stg" do exist in reliable sources, but are not enormously common post about 1980. Thus I propose advising against "£stg" and explicitly prohibiting "GB£".

• Non-sterling currency units named pound or lira should use the fully disambiguating abbreviation specific to that currency. (e.g. £SA for the South African pound).[6]

On this final point the original sentence was badly worded and did not even give any examples for editors. 92.12.140.56 (talk) 15:23, 25 April 2023 (UTC)

The existing text was arrived at after extensive discussion just a few months ago: I see no reason other than wp:IDONTLIKEIT to reopen the question. The one-bar v two-bar allographs issue is fully explained at pound sign#Double bar style: there is no need to have a wp:CFORK of it in the MOS. --𝕁𝕄𝔽 (talk) 18:38, 25 April 2023 (UTC)

Could you link to that recent discussion? JMF you make a mistake, no (bad) FORK at hand.

An article must describe what is used, for example by the Bank of England. However, the MOS must describe what we at enwiki use. Out of MOS interest, it is important we prescribe a non-ambiguous and non-variant writing throughout this wiki. What sign a source uses for GBP is irrelevant for our article tekst. (Apply single MOS option ie £).

I still don't get why MOS-forbidding £stg &tc. ever is an issue. A variation that never helps or is needed. Also, simply rule out U+20A4 lira sign — solved. (Incidentally, if and when a font has a double-barred sign for U+00A3: so be it).

Of course, MOS-rules are overboard when the sign is the topic itself (in Pound sign etc). — Preceding unsigned comment added by DePiep (talk • contribs) 18:59, 25 April 2023 (UTC)

DePiep is quite right, I'm not talking about articles per se, just how the manual should advise editors.

I am not taking issue with the spirit of the guidelines, but the exact wording, which is currently very oddly written and poorly explained; for example it gives no examples of other currency units for contrast. I think it ought to be msde completely clear in the manual that £ alone indicates sterling only with no need for any other abbreviations or resorting to ISO codes, and that editors should clearly denote any other pound/lira unit with a different fully disambiguating abbreviation (e.g. LL for the Lebanese pound, £NZ for the New Zealand pound and so on), leaving a simple £ without qualification to mark sterling, much as € marks amounts in euros. 89.240.244.177 (talk) 22:05, 25 April 2023 (UTC)

@DePiep: see Talk:Pound sterling#Second request for comment (currency symbol) (which was a reprise of Template talk:GBP#Semi-protected edit request on 12 June 2022). To quote User:Redrose64 there, Ah crap, not this again. Enough already. Exactly. --𝕁𝕄𝔽 (talk) 22:49, 25 April 2023 (UTC)

I am not trying to contradict anything there, merely reword and tighten up the style guide. The guidelines offered at present are a bit all over the place and not particularly well written. Not far below it already states Exceptions may occur in tables and infoboxes where space is limited e.g. Currencies accepted: US$, SFr, £, €. It may be appropriate to wikilink such uses, or add an explanatory note. using £ on its own to represent sterling. I do not see my proposal as a change per se, merely a cleanup of poor structuring and grammar. 89.240.244.177 (talk) 23:21, 25 April 2023 (UTC)

I have now added my suggested edits. I hope they are an effective cleanup. 89.240.244.177 (talk) 00:12, 26 April 2023 (UTC)

Which edits? You edited the MOS text? -DePiep (talk) 04:36, 26 April 2023 (UTC)