Wikipedia talk:Manual of Style/Dates and numbers

$x USD/£x GBP

A few articles employ a notation where a currency sign and a corresponding ISO 3-letter code both appear in the same figure. Should it be explicitly disallowed? DeeDeeEn (talk) 05:30, 11 June 2023 (UTC)

Can you show us some examples? Dondervogel 2 (talk) 05:39, 11 June 2023 (UTC)

This diff has me specifically editing an instance of the notation. This section involves two currencies in such format. DeeDeeEn (talk) 05:54, 11 June 2023 (UTC)

The D in USD stands for dollar and the P in GBP stands for pound. Which makes $50 USD stand for 50 dollars United States dollars and £50 GBP stand for 50 pounds Great Britain pounds. In both examples this is duplicitous and should be avoided. We can use the symbol or the 3 letter code but not both.

A good way to avoid the problem is to use one of the {{USD}}, {{GBP}} or {{currency}} templates.  Stepho  talk  06:05, 11 June 2023 (UTC)

I have no objections. However, I am proposing that this problem be explicitly addressed in the Manual of Style. DeeDeeEn (talk) 06:51, 11 June 2023 (UTC)

FYO stylemanual.gov.au, Imperial College London, regards, Govvy (talk) 08:30, 11 June 2023 (UTC)

The latter site doesn't seem to mention the topic at hand at all. Good to know that there is one style manual explicitly mentioning this though. DeeDeeEn (talk) 08:38, 11 June 2023 (UTC)

These codes do not infact stand for anything, they aren't abbreviations. "USD" only resembles an abbreviation, whereas "GBP" isn't an abbreviation of any term at all ("Great Britain pound" is a backronym). Personally I think that "$" and "£" on their own with no additions are widely enough understood to refer to US dollars and sterling that the ISO codes are unnecessary in the vast majority of circumstances. 92.12.143.145 (talk) 22:58, 11 June 2023 (UTC) Ban-evasion by WP:Sockpuppet investigations/TheCurrencyGuy 74.73.224.126 (talk) 00:45, 14 June 2023 (UTC)

That can be said for the pound sterling. However, the MoS has already stated how "$" does not just stand for the US dollar.

Additionally, this topic isn't about which of the two to use; it's whether the use of both should be mentioned in the MoS. DeeDeeEn (talk) 01:02, 12 June 2023 (UTC)

@DeeDeeEn: that's an LTA who, as the master accounts username suggests, is obsessed with currency and also The Troubles for some reason. ISP is usually TalkTalk and he's previously left disruptive messages here from that same /21 range here (see archived discussion). Some other TalkTalk ranges involved include 92.21.248.0/21 and 92.9.0.0/21. Given the broadness of the mobile ranges available more is likely forthcoming. Just revert, collapse, or strike posts as appropriate, but otherwise ignore and don't engage. 74.73.224.126 (talk) 00:45, 14 June 2023 (UTC)

I did not have prior information about the long-term abuser. I therefore treated the IP user without taking any of the above into account. Thank you for taking the time to mention me, however. DeeDeeEn (talk) 01:17, 14 June 2023 (UTC)

No worries, I was just letting you know for the next time it happens. 74.73.224.126 (talk) 01:18, 14 June 2023 (UTC)

MOS:CURRENCY gives explicitly our style guidance for these currencies. As with the rest of the MOS, we don't tend to list all of the ways that people can get it wrong. So no need to add yet another rule, just remove the error as you would any kind of spelling or grammatical error. --𝕁𝕄𝔽 (talk) 11:15, 11 June 2023 (UTC)

I mean, $x USD is, though established to be incorrect, widely commonplace. I couldn't see a point where I would be forbidden to repeat the currency name; however, thank you for your reminder. DeeDeeEn (talk) 12:15, 11 June 2023 (UTC)

I have never seen it but I assume you have done, enough to make for you to feel justified in raising here. If your edits to correct it are being reverted on the basis that the MOS doesn't deprecate it, then yes, we need to say so. Has anybody else seen it? (Google won't use it as a search argument.) 𝕁𝕄𝔽 (talk) 13:34, 11 June 2023 (UTC)

I, fortunately, have never been reverted due to a style problem regarding this notation. However, it is used frequent enough that I believe proposing this is a fair idea.

I still await others' comments. DeeDeeEn (talk) 14:00, 11 June 2023 (UTC)

You have unanimous agreement here (including mine) that writing the dollar sign followed by USD (or the pound sign followed by GBP) is incorrect. I suggest you edit with that unanimous agreement in mind. If you find others revert you (after you have referred them to this discussion) I would support a change to the MoS. Dondervogel 2 (talk) 14:22, 11 June 2023 (UTC)

Thank you for clarifying. This would render syntaxes like $x USD, USD $x or USD$x unacceptable.

I shall follow this up with an update the next time someone contests my edits. DeeDeeEn (talk) 14:30, 11 June 2023 (UTC)

That sounds reasonable. Thank you for checking in. Dondervogel 2 (talk) 14:57, 11 June 2023 (UTC)

Semi-automated changes to YYYY-MM-DD in templates

Edits like this made with the MOSNUM dates script provide no benefit to the reader, as dates already render as intended. They do, however, make translating citations more difficult as I explain here. YYYY-MM-DD is allowed in citation templates per MOS:DATEUNIFY—there is no MOS reason to change this formatting, but because these changes are not explicitly prohibited, the script continues to be used in this way.

Relevant discussions I am aware of:

• In June 2019 an editor notified the script creator that date formatting in citation templates was no longer necessary, and advised that edits which solely make this change should not be completed.
• In March 2023, discussion was raised at the script's talk page. Editors deferred the conversation to this page.
• In April 2023, discussion was taken here (WT:DATE), but it fizzled out and ultimately no action was taken.
• In May 2023, I raised the issue again. There were well-intentioned, but convoluted, suggestions on how I could personally fix the issue.

I find this specific use case of the script incredibly frustrating and demotivating. With the script, this change takes a few seconds to perform and doesn't seem to provide any benefit, but causes extra work for others. I can individually reach out to the editors making these semi-automated edits (and I have), but I'm just one person. Maybe an RfC is the correct next step here? Thanks. Wracking ^talk! 19:45, 12 July 2023 (UTC)

• We need an end to this bullshit, which has been going on for years and years and years, to no purpose but causing much wasted editor time. The script is broken and should not be used. Either the script itself should be banned (WP:BAG?) or Giant Snowman, who seems unable to learn how to use it without causing regular disruption, should be banned from using it. Paging David Eppstein. EEng 22:16, 12 July 2023 (UTC)

  To add to "the script is broken": it does not know how to handle cs1-dates=ly format (that is, spelled-out publication dates and numerical access dates for references), which is one of the standard MOS-approved styles, and will break that format when applied to articles using that style. I have complained about this for years, with the typical response from the script writer being WONTFIX and the typical response from the script users being "that's just how the script works, I can't change it and I'm not going to stop using it". I'm too lazy to look for diffs for all that right now.

  Giant Snowman is only one of multiple editors doing this. For a long time I even thought Giant Snowman and The Rambling Man might be socks for the same editor because they were behaving the same way with respect to this script, but I encountered others later and now think that it's just the existence of the script that caused them to behave similarly.

  It's also mostly cosmetic, in the sense that it does not affect the readers at all: in any article using citation templates and properly tagged for its date style, the dates are reformatted by the templates and rearranging them beforehand is pointless. —David Eppstein (talk) 22:33, 12 July 2023 (UTC)

  As a minor procedural note, since this is users individually choosing to run a script on a page it does not fall within the purview of WP:BAG any more than use of twinkle does. 74.73.224.126 (talk) 01:07, 13 July 2023 (UTC)

  Whether it's BAG, ANI, or firing squad, I don't care. EEng 02:28, 13 July 2023 (UTC)

  I think the issue is about the script's task of changing YYYY-MM-DD to MDY or DMY in reference templates. The issue isn't that certain people are using the script in this way, but that the script is able to be used in this way (and it's the default!). Based on WP:BOTAPPEAL, I think WP:BOTN may be the place to go, with a clear and concise explanation of the issue and why it is fundamental to the script, not an issue of individual operator action. Wracking ^talk! 21:34, 14 July 2023 (UTC)

  If a script is broken, then either fix the script or delete it. The only thing remotely BOT-related here is if there's WP:MEATBOT behaviour, and WP:MEATBOT gives admins all the leeway they need to act here. BAG has no special purview over scripts. Headbomb {t · c · p · b} 21:49, 14 July 2023 (UTC)

  I think the issue is that, while some editors think the script is broken and have asked for this functionality to be removed or restricted, others (such as some script users and the original developer) disagree, saying the script is not broken and is working as intended. This (YYYY-MM-DD to DMY or MDY in ref templates) is a default functionality of the script, to my understanding. (Meaning I would not define it as an issue of individual script-users.) Wracking ^talk! 03:18, 15 July 2023 (UTC)

  I have to agree with Wracking that the function of the script is not indisputably broken. As the CS1 templates work today, the presentation to the users can easily be made to comply with whichever format the editors of the article form a consensus for. We have no unequivocal principle of style or citation that says the wikitext must obey any particular style (with a few exceptions for especially confusing usages). We are not like a software shop where if your code doesn't follow the company style, you'll be in trouble with the boss.

  The strongest ground to attack the script, in my opinion, is that it my experiments suggest it doesn't behave the way the documentation says it behaves; I would have thought if you put a particular value in the cs1-style parameter, the script would obey it. But so far as I can determine, that parameter is ignored. Jc3s5h (talk) 10:20, 15 July 2023 (UTC)

Wracking, was my suggestion too convoluted? Copying again: "is it possible to copy-and-paste the English versions into your sandbox, run this tool to change to either YYYY-MM-DD or DD-MM-YYYY, and then translate?" Separate from whether that works for you or not, I'm in agreement that the issue DE brings up needs to be addressed. Either the script needs to recognize and respect cs1-dates parameters, or users need to be warned when they're using it erroneously. Even if the tag isn't present, moving away from an acceptable date style without discussion is misuse of the tool. I've likely made this mistake in the past, and I wouldn't have known about it without the last discussion. Firefangledfeathers (talk / contribs) 04:01, 13 July 2023 (UTC)

@Firefangledfeathers, maybe "convoluted" isn't the right word—I truly did appreciate your suggestion, and may try it in my next translation. (I have taken a bit of a break from translating but am hoping to start a new project soon!)

I find that learning new plug-ins/scripts for Wikipedia takes me a while, and always longer than I hope. I've never used the MOSNUM dates script, so maybe it would be easy to enact your suggestion. My issue, though, is that it's hard to disseminate that tip to translators (besides me). (And, we have an issue of well-cited content being translated... but refs being left out. So I highly encourage anything we can do to make the translation process easier.)

For English→Spanish translations, I prefer using Content Translation as it's an easy interface—I could look into using a sandbox as the source text. I can only speak from one perspective, that of an English/Spanish speaker. I don't know if there are other Wikipedias that use other date formats or have less support, in which this poses an even greater problem.

(also, as a correction to my previous comments, I think I was thinking of some of the other painfully tedious translation I've done, haha. I actually did not translate the refdates in my initial translation of es:Ice Spice, but a bot did it for me about 2 weeks later. I don't know if a bot like that exists on English Wikipedia, or other Wikipedias that translate from English Wikipedia.) Wracking ^talk! 21:22, 14 July 2023 (UTC)

@Wracking: I've only started using the script yesterday (and will stop until this is resolved), but it seems to me to be a problem with the Content Translation tool rather than this script. It's entirely reasonable, per MOS:DATEUNIFY, that all the dates be mdyfied or dmyfied uniformly, ref or no. The ISO date is, for a lack of a better word, ugly. It's a buncha numbers that you have to decipher in your mind. That's why the month is written out in full, for readability's sake. dmy and mdy are perfectly machine-readable, or the script wouldn't be able to operate on them in the first place. I don't think it's reasonable to condemn the script for doing its actual job, which is standardizing date formats across the article. What you need is a better translation tool (or a new feature therein), certainly not imposing an inconsistent style on all articles just for the sake of a hypothetical, one-time future translation effort. 〜 Festucalex • talk 11:04, 20 July 2023 (UTC)

@Wracking: In addition, you have another problem. The script isn't the only thing causing dmy and mdy formatting inside refs. Normal users are, too. Let me tell you, I have never, and I mean never, written the date and archive-date in YYYY-MM-DD before, ever. I usually write in mdy manually. So, even without the script, you still have your translation troubles. That's why I think it's not the script's fault, but the fault of your translation method. 〜 Festucalex • talk 11:12, 20 July 2023 (UTC)

I will support that. I have never used YYYY-MM-DD in creating or modifying a citation, but use mdy or dmy, as seems appropriate for the article. Donald Albury 17:39, 20 July 2023 (UTC)

@Festucalex, I understand MOS:DATEUNIFY. I (and others) think that editors should not be doing fly-by semi-automated edits that remove "ugly" (but MOS-accepted) formatting, when those edits serve no benefit to the reader.

It's fine that you don't use YYYY-MM-DD. I explicitly said that I'm not asking editors to change their behavior, besides that related to the script. I have no intentions related to imposing an inconsistent style on all articles. Wracking ^talk! 18:36, 20 July 2023 (UTC)

@Wracking: Would you, then, be fine with editors manually changing YYYY-MM-DD to mdy in reference templates? 〜 Festucalex • talk 18:41, 20 July 2023 (UTC)

@Festucalex, I’m talking about the script. Wracking ^talk! 03:14, 21 July 2023 (UTC)

• The mdy format is, for want of a better word, ugly, impractical and illogical. Beauty is in the eye of the beholder, but the reason mdy is accepted is not one of beauty or elegance, but of convention. It is a convention followed by a minority of readers of English Wikipedia, and respected for that reason.
• By contrast, yyyy-mm-dd is practical and logical, but such considerations carry no weight when it comes to date format. However, yyyy-mm-dd, just like mdy, is followed by a minority of readers of English Wikipedia, and should be respected for the same reason. As pointed out by Wracking (talk · contribs), it's unwise to remove stuff just because you find it ugly.

Dondervogel 2 (talk) 18:54, 20 July 2023 (UTC)

@Dondervogel 2: Rather than debate subjective aesthetics, I'll point out that YYYY-MM-DD never occurs in the body of an article, and thus could never fulfill MOS:DATEUNIFY. There's no reason to defend it so vehemently against a very useful script ("BAG, ANI, or firing squad"!), since its practicality is a matter of question. 〜 Festucalex • talk 19:01, 20 July 2023 (UTC)

You need to carefully read Wikipedia:Manual_of_Style/Dates_and_numbers#Consistency, especially the bullet on Access and archive dates. If an article's established citation format uses YYYY-MM-DD for access and archive dates, you must not change that unilaterally, even if this stupid script invites you to do so. The fact that this script has over and over tempted editors to do what they must not do, apparently without warning them about it, is the reason it needs to be either fixed (immediately) or trashed (immediately). EEng 19:42, 20 July 2023 (UTC)

An editor could avoid breaking the consistency rule by using the script, and also inspecting the cs1-dates parameter in the use xxx dates template and insuring the value is correct; in the scenario mentioned by EEng a parameter value of ly would be suitable. Jc3s5h (talk) 20:04, 20 July 2023 (UTC)

Incorrect. They could avoid breaking the consistency rule by NOT using the script on articles that are formatted in this way. The script is incapable of behaving correctly on articles with this formatting. It will always spell out the dates even when the article is tagged as using numeric access dates. And it is not always the case that articles in this format are tagged with the parameter stating that they are in this format. —David Eppstein (talk) 20:32, 20 July 2023 (UTC)

MOSNUM only applies to the rendered result, not the wikitext. Prove otherwise. Jc3s5h (talk) 23:30, 20 July 2023 (UTC)

Scripts that make only unseen changes to articles are generally forbidden, by WP:COSMETICBOT. —David Eppstein (talk) 23:57, 20 July 2023 (UTC)

WP:COSMETICBOT only applies to bots. The script is not a bot. Jc3s5h (talk) 13:55, 21 July 2023 (UTC)

COSMETICBOT also applies to bot-like editing from users, meaning (as I understand it) wide-ranging or rapid-fire changes done manually or with semi-automated tools. This would apply to users who use the script repeatedly and rapidly, but not, I think, to users who just run it on pages they're working on anyway. Even though I don't tend to use the script rapidly, I do still try and avoid making cosmetic-only edits while using it. I make a few copyedits rather than publish an edit that doesn't affect the rendered page. Firefangledfeathers (talk / contribs) 14:39, 21 July 2023 (UTC)

These are not unseen changes, though. GiantSnowman 07:19, 22 July 2023 (UTC)

To an extent, they are, and that was part of the earlier discussions. For example, here's one of your script-assisted edits that was purely cosmetic. FYI, I had to go back sixteen edits on this list to find it. Firefangledfeathers (talk / contribs) 01:00, 25 July 2023 (UTC)

I've stopped using the script because it disturbs a few users. That's unfortunate because although our guidelines specifically allow YYYY-MM-DD dates in citations, I think they cause more trouble than they solve. Also, though this script is annoying for some, it does a lot of good quickly (making an article use a consistent date format takes a lot of time). If I were king, I'd say all dates should be in YYYY-MM-DD format; there would be some distress but everyone would quickly figure it out (I'd go metric/SI too). Luckily I'm not king and we use a less logical, less beautiful, but perfectly adequate system of sometimes MDY and sometimes DMY, always with the month spelled out. Many people see 2023-07-20 as equaling 1996. They just can't figure out that the string of numbers in an unfamiliar format is a date. That applies to editors as well as readers. Seeing what some people see as computer code in the wikitext turns off potential editors. If there's to be an RfC, I'd vote to stop allowing YYYY-MM-DD.  SchreiberBike | ⌨  19:41, 20 July 2023 (UTC)

@SchreiberBike: I'd vote for that as well. Article-wide consistency, readability, and a convenient method for standardization are more important than an arbitrary carveout for that specific date format. 〜 Festucalex • talk 20:03, 20 July 2023 (UTC)

It is wrong to say that YYYY-MM-DD dates may be universally used for publication dates. Julian calendar publication dates must not be used in Citation Style 1 because doing so emits false metadata. When such a publication date is encountered, the entire citation should be written by hand, with no use of Citation Style 1. Whether all the citations in the article should be rewritten in an non-CS1 format, or if it is acceptable to hand-write a citation that imitates the output of CS1 is unclear. Jc3s5h (talk) 20:09, 20 July 2023 (UTC)

I agree with Scheiber. My worry is that many readers find YYYY-MM-DD confusing—especially whether the middle or final position is a month. Our readers can't be assumed to be experts. Tony (talk) 03:07, 21 July 2023 (UTC)

Readers do not see the YYYY-MM-DD text. For refs, it is translated into MDY or DMY format depending on the article. Wracking ^talk! 03:12, 21 July 2023 (UTC)

User:Wracking, technical question: why do I so often see US-related articles with the correct mdy in the article text, but dmy in the refs. It's plain weird. Tony (talk) 12:35, 21 July 2023 (UTC)

I have seen various formats but what questions me is if there's a history of this with MOSNUM, no one has made a fork that would fix it? I mean I still have issues with the built in citoid with grabbing titles (and the MOSNUM date choice not doing anything) and there's at least a documented page by BrownHairedGirl about it. – The Grid (talk) 14:29, 21 July 2023 (UTC)

Tony1, possibly because some users will remember to be consistent when writing the text, but then use the cite facility in the editing toolbar to automatically do the ref which has their personalised choice of date format, or because both were done incorrectly and someone corrected the text but didn’t notice the date. - SchroCat (talk) 09:46, 22 July 2023 (UTC)

SchroCat—Got any suggestions for fixing it? I'm not very technical. Tony (talk) 10:16, 22 July 2023 (UTC)

Tony1 Me neither! Ideally they should pick up on an existing “Use mdy dates” template present on the page, which would be preferable to the current set up, but I have no idea idea if that technically possible. - SchroCat (talk) 11:24, 22 July 2023 (UTC)

Wracking, readers do see YYYY-MM-DD text when the cs1-dates parameter is set for that format. Tony, I think the main culprit for dmy in US English articles is the RefToolbar, which automatically scrapes website for dates and defaults to DMY. If Template:Use MDY dates is present, these wikitext DMY dates display as MDY for readers. Firefangledfeathers (talk / contribs) 14:42, 21 July 2023 (UTC)

It's hardly satisfactory, the default. Tony (talk) 02:29, 22 July 2023 (UTC)

It is only 'translated' if the article as a DMY or MDY tag - which is what the script adds... GiantSnowman 07:20, 22 July 2023 (UTC)

Julian calendar publication dates must not be used in Citation Style 1 because doing so emits false metadata. Not true. The metadata for a Julian calendar date is truncated to year-only when |date= is written using either of the dmy or mdy formats. Writing a Julian calendar date in YYYY-MM-DD format is not supported in cs1|2 because MOS:DATEFORMAT; attempting to do so causes a Check date values error.

—Trappist the monk (talk) 13:23, 21 July 2023 (UTC)

At what point was somebody going to notify me about this discussion, given you (@EEng and David Eppstein:) are, respectfully, slagging me off and trying to impose some kind of ban on me? GiantSnowman 07:13, 22 July 2023 (UTC)

• We're not saying anything about you that you haven't heard us say 100 times: using this script you regularly mess up dates in articles, and won't stop. EEng 08:09, 22 July 2023 (UTC)

  and always respectfully Dondervogel 2 (talk) 08:36, 22 July 2023 (UTC)

  That is nonsense and you know it. GiantSnowman 08:58, 22 July 2023 (UTC)

  Humor impairment strikes again. EEng 09:05, 22 July 2023 (UTC)

  Actually, wait... what are you saying is nonsense? The always respectfully bit? The We're not saying anything about you that you haven't heard us say 100 times bit? Or the you regularly mess up dates in article bit? EEng 09:07, 22 July 2023 (UTC)

  All of it. GiantSnowman 09:10, 22 July 2023 (UTC)

  Then we're back to humor impairment strikes again. EEng 09:19, 22 July 2023 (UTC)

  Are the personal insults necessary or appropriate here? -- Pemilligan (talk) 11:38, 22 July 2023 (UTC)

Talking of notification, Ohconfucius has finally been alerted to the discussion (in another context). David Brooks (talk) 14:40, 22 July 2023 (UTC)

There may be some misunderstanding about how my script works in conjunction with MOSNUM so I'll try and discuss what my operating considerations are:

firstable, the script was and is intended to convert or unify formats throughout any given article. It still does the job pretty well, with very few false negatives or false positives. There is no reason not to use the script. The controversy seems more to be related to the political choice of editors.

According to strict interpretation of guidelines, once autoformatting began, there is no reason for any ref dates to be changed; users are to rely on parameters within the {{use xxx dates}} templates. By that same token, editors should use the parameters if they want ref dates to display in yyyy-mm-dd form.; the script ought to stop acting on dates within references. So although we have been ordered not to care any more about the underlying dates and focus on the rendered output, I have not modified the script to stop their conversion because I found to not do so sometimes gives rise to unsatisfactory results: especially where the references pre-exist without citation templates, in which case the automatic rendering ordered by the "use" templates fail. There is no solution to this in any event.

Secondly, most existing articles started life with either dmy or mdy dates; yyyy-mm-dd dates are a relative latecomer and few were inserted by human editors. To decide which format should prevail, we defer to WP:RETAIN in disputes. But precious few editors check what original format the "first major contributor" used.

We see some editors preferring yyyy-mm-dd ref dates increasingly up in arms, but there is no reason to be, for the reasons already stated above – we only care about the rendered output. Bearing the above in mind, I certainly don't see the need to rewrite the script so that it allows conversion of ref dates to yyyy-mm-dd form. All editors need to do is to confirm that the very first date is indeed in yyyy-mm-dd form, and then apply the parameter as in {{use xxx dates|ls}}. There should also be no more discussing "ugliness" of one date format over another, nor for chastising fellow editors for the inconsequential removal of yyyy-mm-dd dates lest forget the goal of having consistent date formats in any given article. -- Ohc ^{revolution of our times} 22:46, 24 July 2023 (UTC)

Ohconfucius, don't you think an edit like this one is troublesome? Prior to the script-assisted edit, the article had no Use XXX dates tag, but was fully consistent in its use of a MOS-accepted style. The script changed from one acceptable style to another, which we urge editors not to do without discussion. Firefangledfeathers (talk / contribs) 01:00, 25 July 2023 (UTC)

I think I've already said what needed to be said. It's a political editorial choice and my script is but a tool to that end. The only issue I have with the edit is that the editor neglected to add the |cs1-dates= parameter, and appeared to edit war over the format. The insertion of {{use mdy dates}} is useful and necessary, and correct application of the parameter at the outset may well have avoided the conflict. Although the script doesn't add the parameter, it doesn't overwrite it.  Ohc ^{revolution of our times} 18:29, 25 July 2023 (UTC)

Why do you keep saying things are "political"? What in the world are you talking about? EEng 19:09, 25 July 2023 (UTC)

I mean it's editorial choice based on interpretation of policies.  Ohc ^{revolution of our times} 19:20, 25 July 2023 (UTC)

Clarification (and/or change) requested re "Uncertain, incomplete, or approximate dates"

I'm unclear on how to handle this situation: we have a person who we definitely know was alive (and an adult or teen) in 1651, and was still alive in 1658 (a seven-year range), and that is all we know. I'm not sure how this should be handled in the parenthesized vital-dates at the beginning of the article:

1. Nanker Phelge (fl. 1651 – 1658) was...
2. Nanker Phelge (before 1651 – after 1658) was...
3. Nanker Phelge c. 1651 – c. 1658 was... [using {{circa}}]
4. Nanker Phelge (fl. 17th century) was...

Or something else? (FWIW this came up at Pasqua Rosée and the discussion started at Talk:Pasqua Rosée#Use of "fl." at opening is wrong I think?). And FWIW it looks like MOS:APPROXDATE recommends both #1 and #2 (and possibly #3, not sure) but not (I think) not #4), so I think we should consider clarifying this if possible? (For my part, whatever best serves the reader is what counts, everything else is mostly noise.) Herostratus (talk) 17:29, 16 July 2023 (UTC)

Herostratus, "fl." is used to denote when a person was considered active. exact dates can be used with "fl.", even when the subject's years of birth and death are not known with certainty, because floruit does not assert that the dates mentioned are actually the subject's years of birth and death.

"fl. x–y" effectively states that a subject was born on or before x, died on or after y, and was active between x and y inclusive, so option 1 actually says a bit more than option 2. also, option 2 asserts that phelge (or rosée) was alive in 1659, which may be an inappropriate assertion given that there are no known surviving records for rosée after 1658. (i don't know anything about phelge, though.) i think using option 3 would be misleading because it suggests that we know with some degree of certainty that the subject was born around 1651 and died around 1658. the use of specific years in option 3 also suggests that the actual years of birth and death are likely within a few years of the stated estimates, while we are (or, at least, i am) fairly certain that rosée was not a toddler when he began serving edwards his daily coffee. option 4 seems valid, but it asserts far less than option 1, so i am not sure why that option would be preferred.

by the way, "fl." does not normally take a spaced en dash if it is used with a simple year–year range, so technically, option 1 is formatted incorrectly. i can easily understand why the error was made, though, as the mos had actually contradicted itself on this point until 2021. i see nothing wrong with how the range is currently presented in the article on rosée. dying (talk) 18:46, 16 July 2023 (UTC)

In the interests of making consensus visible, I'd second everything said here. UndercoverClassicist (talk) 19:09, 16 July 2023 (UTC)

Alright, but assuming that we want to use WP:APPROXDATE with as few changes a possible, I mean at bullet point 3 it says

Where birth/death limits have been inferred from known dates of activity: [eg] Offa of Mercia (before 734 – 26 July 796)..."

but then right below it at bullet point 4 it says

When birth and death dates are unknown, but the person is known to have been active ("flourishing") during certain years, fl., fl., or fl. may be used, [eg] Jacobus Flori (fl. 1571–1588)

Seems confusing... first it says use "before (and/or after)" then it says to use "fl". The only difference between the two, that I can see, based on the examples, is that the first (before and/or after) is used when the span of years is considerable -- enough to possibly cover the lifespan of an accomplished person (the example shown covers 66 years, and the other examples are similar), while the second (fl.) covers 17 years, which would usually not be the full lifespan of an accomplished person (and the other examples are similar). But it could be, and might well be if the person is notable for being a royal heir, say (and the article in question, Pasqua Rosée has "(fl. 1651–1658)" which is just 8 years).

So, is that the difference? "Before and/or after" is used for long spans, and "fl." is used for short spans? If not, what are the circumstances that leads one to chose one over the other? Should we not explicitly give them, or if there are not any, say "use either, depending on your inclination, but stay consistent within articles"? Or else just erase one of the proscriptions, either "Before and/or after" or "fl."?

User:Dying (and User:UndercoverClassicist, you say

"'fl." is used to denote when a person was considered active. exact dates can be used with "fl.", even when the subject's years of birth and death are not known with certainty, because floruit does not assert that the dates mentioned are actually the subject's years of birth and death...."fl. x–y" effectively states that a subject was born on or before x, died on or after y, and was active between x and y inclusive

Well but that's didactic and how is the editor to know this?. Maybe you've been to school and learned it there, but I haven't, and hella other editors haven't either. Herostratus (talk) 19:03, 24 July 2023 (UTC)

It's not a matter of the length of the span; it's about what's known and what impression we want to give the reader about it (or avoid giving). For Offa, we have a date of death and we know something about when he was born. For Florii and Rosée, we know some dates in their lives but those dates don't indicate when they were born or died. It would be technically true to say they were born before the first known dates and died after the last, but also banal and even potentially misleading, as many readers who saw "before YYYY" might think we wished to imply that was a good indicator of when they were born. That's when we use fl. with the years we do know.

TL:DR: first apply test #3: are meaningful limits for birth or death dates inferrable? If not, proceed to #4: do we know when they were active? For Nanker Phelge, #3 = definitely not and #4 = yes, so fl. 1963–1965. NebY (talk) 19:22, 25 July 2023 (UTC)

Alright. But how is a person supposed to know this -- editor person or reader person? I would think that some simulacrum of what you wrote above should go into the instructions? But for one thing it the differences seem subtle, and, remember, every time we burden an editor with extra text, God kills a kitten. And then, what about the poor reader, how is she going to know what is meant?

Maybe some other people have some worthwhile points and ideas, and/or you have more cogent commentary. So its worthwhile to keep this section up maybe, but simultaneously I'm going to open a subthread (below) about a different approach to the problem. — Preceding unsigned comment added by Herostratus (talk • contribs)

The larger picture

Executive summary: The best answer is "Nanker Phelge (lived 17th century) was..". None of the above!

---

Ok, so a main purpose of rules and suggestions is to serve the reader. It's not the only purpose, but it's important. So, to refresh, the question is how best to serve the reader in this case.

So, for me, I don't care much about what what professors of history write out of ancient habit going back to the Romans I guess. I do care about puzzling or annoying the reader. Things outré, like if we decided to call all thespians "actrons" would do that. But getting rid of "fl." would not, except maybe some snobs.

I"fl."... what does that even mean? I'm a high school dropout farmworker in Winterset. I'm an ESL dockworker in Wroclaw. A policeman in Ikot Ekpene, a 7th grade student in Schooner Gulch, a restaurant owner in Molenbeek, a division manager at Exxon-Mobile (After all, a whole honken lot educated folks don't read anything much but novels or news or technical materials in their specialty.)

Sure, a whole lot of our readers have been graduated from private universities, or are widely read, or are just quick to pick up things, and so on. And yes, we can't much accommodate ESL or illiterate or unread folks at the cost of accommodating our main readership.

So, hella people don't know what "fl." means. Does using "flourished" instead disaccommodate people who do? I'm not seeing it. ("Floruit" is straight out, we don't require our readers to know Latin.)

(And then, the primary meaning of "flourished" is "thrived". But some of our subjects didn't thrive. Domna Anisimova (td. 19th century) was blind, illiterate, and lived in an obscure village in the backwaters of Imperial Russia. Maybe she didn't flourish. "Flourished" is an OK word but a little fancy in this context, and a little off. What's wrong with "lived"? "Nanker Phelge (lived 17th century)"... it doesn't grate, it's really easy to understand. Is it so horrible. Is it not the best way to serve the reader.

OK. So, on the dates thing. Vital statistics are traditional to give, and important to people, and we give them. "Notary Sojac (April 17, 1933 - November 12, 1989)". Lot of times we just give the year, and put the actual day in the body text, and birth and death. I usually do, cos it places the person in temporal context, which the actual dates are noise to most people. I think there's a rule somewhere about that, don't know or care.

But for Phelge, 1651 and 1658 aren't part of his vital statistics. They're not the date (or even year) and place of birth and death place. The United Nations defines vital statistics as "vital events (live births, deaths, fetal deaths, marriages, and divorces)". Nothing about "first time mentioned in somebody's diary or whatever, that we know of."

1651 and 1658 are just dates when he signed an invoice and when he got a writeup in the local paper, or whatever. The belong at the very top of the article, yes. Not right after the name.

"Lived 17th century" puts the person in context, it a good start for understanding the subject. Rando dates when he wrote a letter to his brother or whatever don't do much for that. The reader has to figure out what the numbers mean and convert that to the subjects era. Why make the reader do extra work. Herostratus (talk) 22:53, 26 July 2023 (UTC)

Herostratus, have you read our article on "floruit" yet? dying (talk) 00:34, 27 July 2023 (UTC)

As Floruit says, "active" is an alternative, that is easier to understand. Putting "Lived 17th century" is a sure way to attract tags etc, and not helpful to the reader. What does "Lived 20th century" tell you? Kurt Cobain, or someone killed in WWI. You asked the question, & were given the answer. Don't whine, or at least not at such length. Johnbod (talk) 01:08, 27 July 2023 (UTC)

See current discussion on clarifying or abolishing centuries at Wikipedia:Village pump (policy)#Without looking it up, what year and day were the ends of the 6th century BC?. But remember every time we burden an editor our fellow editors with extra text long diatribes and unrealistic proposals, God kills a kitten all the kittens. NebY (talk) 10:11, 27 July 2023 (UTC)

MOS:CENTURY-related discussion at VPP

Please see Wikipedia:Village pump (policy)#Without looking it up, what year and day were the ends of the 6th century BC? Firefangledfeathers (talk / contribs) 20:10, 24 July 2023 (UTC)

b2k dates

Over at Megalonyx there has been a dispute between me and another user regarding the use of Before Present or b2k dates. The other user is asserting that since b2k is preferred by the International Commission on Stratigraphy, it should be preferred by Wikipedia too. However, as far as I can tell, BP remains a much more common dating system in scientific literature. I tried searching and cannot find any other examples of b2k dates being used on Wikipedia. Hemiauchenia (talk) 14:14, 29 July 2023 (UTC)

b2k seems more transparent than BP, especially for lay readers, but we should at least have a linkable article on it if we're going to use it. Yes, we would want to be confident that it's won formal acceptance and become broadly at least as common as BP in new scientific literature; is there any prospect of the IUGS, the parent body of the ICS, approving it soon? Perhaps more trivially, I'm confused by "11,235 BP, which corresponds to 11,255 B2K" in this edit comment; is there not a 50-year difference between BP (1950) and b2k (2000)? NebY (talk) 14:57, 29 July 2023 (UTC)

I'll guess that the confusion arises from the assumption (which I've been making) that BP dates meant before today's date, not knowing that standard practice is to use 1 January 1950 (as stated at Before Present). How many casual readers actually know that? -- Pemilligan (talk) 15:23, 29 July 2023 (UTC)

To be honest, for the dates that BP is appropriate to user over BC (generally 10,000 years ago or greater in my opinion), 50 years is a relatively insignificant amount of time to the point that it doesn't really matter, and the confidence interval for such dates are often in the hundreds of years anyway. Hemiauchenia (talk) 15:45, 29 July 2023 (UTC)

Many more casual readers will know that than have any idea what a "b2k" date is! Many are still thrown by BCE, especially outside North America. The world isn't ready for this, no matter what the International Commission on Stratigraphy say. He should come back in 20 years. Johnbod (talk) 17:49, 29 July 2023 (UTC)

Or at least when search results for "b2k dating" are less about Lil Fizz and Omarion. NebY (talk) 18:14, 29 July 2023 (UTC)

Well, in the interim, someone who cares and who has good journal access should write up a WP article b2k dates.  — SMcCandlish ☏ ¢ 😼  18:36, 29 July 2023 (UTC)

Unit conversion missing some stuff

Our section on unit conversion says to do it when there's a dialectal split, but mentions nothing about converting units that are likely to be unfamiliar to the average reader (cubits, ells, etc.), which we routinely do. When conversion is done, we would want it to be done consistently, following the general MoS principle to be consistent within the same article, but the section does not actually say that and it probably should. I.e., we don't want someone to do a conversion at the first mention of a unit then never do another conversion in the article.  — SMcCandlish ☏ ¢ 😼  19:01, 29 July 2023 (UTC)

Sometimes it may be sufficient to give a conversion only the first time a unit is mentioned, so the reader will have a general idea of the magnitude of the unit. It really depends on the subject matter. Jc3s5h (talk) 19:27, 29 July 2023 (UTC)

MoS does not require such absolute consistency - see MOS:OLINK or our guidance on dates, with examples such as She fell ill on 25 June 2005 and died on 28 June. Repeated conversions can make an article less readable, so we do say In some topic areas (for example maritime subjects where nautical miles are the primary units, or American football where yards are primary) it can be excessive to provide a conversion for every quantity. In such cases consider noting that the article will use a particular unit – possibly giving the conversion factor to other, familiar units in a parenthetical note or a footnote – and link the first occurrence of each unit but not give a conversion every time it occurs. Applying this principle may require editorial discretion; for example, in scientific articles the expected level of reader sophistication should be taken into account. NebY (talk) 19:46, 29 July 2023 (UTC)