Shirt a Phobia

Sample Page

Precomposed fractions should be allowed on pages about the fraction in question

In this edit, an editor feels that MOS:FRAC is a sufficient excuse to make the 1/3 page less useful.

In particular, the 1/3 disambig page, like the 1/2 disambig page, should have the relevant Unicode character, ⅓, on it.

While “Some precomposed fractions may not work with screen readers, and not all fractions are available precomposed”, there are times when one wants to have the Unicode fraction to quickly cut and paste, especially in the article about the fraction in question.

Samboy (talk) 14:09, 18 February 2026 (UTC)[reply]

That one’s a disambiguation page, though. In fact we have no article about the fraction 1/3. Gawaon (talk) 15:41, 18 February 2026 (UTC)[reply]
Fair enough. I put ⅓ in the bullet list item about the fraction 1/3 on the 1/3 disambig page. Samboy (talk) 17:26, 18 February 2026 (UTC)[reply]
Yeah, that makes more sense! Gawaon (talk) 17:49, 18 February 2026 (UTC)[reply]
You’ve also added 1.33333… to that line.[1] I’ve corrected it but it’s still veering into breaching WP:D2D and WP:DABLONGDESC. Broadly speaking, each bullet of a disambiguation page should be a brief link to an article, with sufficient detail to distinguish that target from the others listed; it shouldn’t be a substitute for an article. NebY (talk) 18:16, 18 February 2026 (UTC)[reply]

Abbreviated “century”: “C. or “c.”?

In abbreviating something like “18th century”, is it “18th C.” or “18th c.”? Generating example: see subsections under Tel Lachish#Select inscriptions.

Unless I missed it, this doesn’t seem to be mentioned in this MOS page. Could it be added? If it is elsewhere, could a wikilink to that place be added?

Feline Hymnic (talk) 19:45, 22 February 2026 (UTC)[reply]

I suggest ‘C.’, as ‘c.’ represents ‘circa’ to me… GiantSnowman 19:48, 22 February 2026 (UTC)[reply]
I was just about to say the same. —David Eppstein (talk) 21:10, 22 February 2026 (UTC)[reply]
The only abbreviation given in the print Collins English Dictionary is “C”, prefixed, e.g. C14 = 14th century, and that’s the only one I use in making personal notes. I would not use it or any other abbreviation for century on Wikipedia and see no benefit to the readers in the example you’ve given, only a risk of obscurity and bafflement. NebY (talk) 21:19, 22 February 2026 (UTC)[reply]
Why not use the full form? Unusual abbreviations should only be used in emergencies, and that article doesn’t seem to be one. Gawaon (talk) 21:47, 22 February 2026 (UTC)[reply]
I would spell out “18th century”, per Gawaon. Dondervogel 2 (talk) 23:13, 22 February 2026 (UTC)[reply]
See MOS:ABBR. We don’t have space restrictions like a paper publication. Use the full word unless it’s necessary like in a table. If needed, “18th C” could work, but it’s hardly ever needed. SchreiberBike | ⌨  00:41, 23 February 2026 (UTC)[reply]
The primary aspect of my question is about whether the MOS gives guidance on abbreviating “century”: an act that has been reasonably common in printed literature. After all the MOS is there to give guidance on a wide range of stylistic and grammatical conventions: WP’s considered consensus. My particular “century” instance is simply one such instance within the range.
If MOS already covers the century case, then my question is very quick and simple: where is it, please? Have I missed it?
But if we don’t already have the century case, then my question becomes a two-part (a) primary: shouldn’t we have one? (b) secondary: what, after considered discussion, should it say?
Feline Hymnic (talk) 10:02, 27 February 2026 (UTC)[reply]
We tend to use less abbreviations than print publications, since space considerations are much less significant online. Plus we write for a general audience, while the publications you have in mind are supposedly for a more specialized, academic audience. So “but they do it” is not a particularly relevant or convincing argument here. Gawaon (talk) 11:08, 27 February 2026 (UTC)[reply]
If you’re looking for advice on abbreviations in general, SchreiberBike already linked it: MOS:ABBR. “Century” is not mentioned there, which suggests it should not be abbreviated. Gawaon (talk) 11:12, 27 February 2026 (UTC)[reply]
Also, don’t expect us to explicitly list all words that should not be abbreviated. Such a list is impossible for obvious reasons. Gawaon (talk) 11:14, 27 February 2026 (UTC)[reply]
(a) No, as several editors have already responded above. There’s therefore no point in addressing (b), but the extreme difficulty (to put it mildly) that we would have in finding an instantly recognisable, unambiguous and clearly conventional abbreviation is one of the reasons why we shouldn’t abbreviate “century”. NebY (talk) 13:22, 27 February 2026 (UTC)[reply]
Yes, I’m inclined to agree that ‘century’ does not need to be abbreviated. GiantSnowman 21:42, 27 February 2026 (UTC)[reply]

Fathoms and mils

Hi all. I was editing Stygiomedusa; I was uncertain whether to use fathoms (in addition to feet) for depth and mils for small units (e.g. 2 mm) or not. I decided not to use them. What do you think about?– Carnby (talk) 19:41, 6 March 2026 (UTC)[reply]

Clarify wording of MOS:CENTURY

I found the following from MOS:CENTURY to be a bit redundant, verbose, and confusing:

  • The 18th century refers to the period (1701–1800), while strictly the 1700s refers either to (1700–1799) or (1700–1709). When using forms such as the 1900s, ensure there is no ambiguity as to whether the century or the decade is meant.

So I changed it to:

  • The form the 1700s can refer to either (1700–1799) or (1700–1709). If there is ambiguity, consider more precise forms such as the 18th century or the first decade of the 1700s.

The statement “The 18th century refers to the period (1701–1800),” was repeating an earlier bullet point. The word “strictly” seemed confusing and unneeded. Feel free to revert if you think it is a step backwards. Noleander (talk) 14:14, 13 March 2026 (UTC)[reply]

Date format in references

@1Veertje: is edit warring with me at Bas van Wegen (including editing from an TA) regarding date formats in references. Their view is that a reference must use YYYY-MM-DD format – I say WP:DATERETAIN applies and therefore writing the date in full in the reference is absolutely fine. Further views/guidance welcome. GiantSnowman 11:13, 21 March 2026 (UTC)[reply]

DATERETAIN surely applies, plus YYYY-MM-DD is one of our non-preferred date formats. Gawaon (talk) 11:25, 21 March 2026 (UTC)[reply]
Calling YYYY-MM-DD “non-preferred” is inaccurate. It is allowed as a standardized format in references, either for all references (although I don’t personally care for this style) or only for the editor-facing access-date and archive-date parameters with spelled-out publication dates (a style I frequently use). All that said, DATERETAIN surely applies, and as GiantSnowman wrote, “writing the date in full in the reference is absolutely fine”. The article was created in 2008 (by GS) with spelled-out dmy dates, so that is the default standard and would need discussion and a consensus to change. —David Eppstein (talk) 21:09, 21 March 2026 (UTC)[reply]
If you use yyyy-mm-dd in a citation template (which is also what the editing interface and citation tools produce by default) and add {{Use dmy dates}} or {{Use mdy dates}}, the displayed date format is localized consistently across the article. In that setup, the stored value (|date=) and the displayed format are effectively separate concerns: the template handles presentation, while ISO format keeps the underlying data consistent and easier to maintain. Given that, I don’t see a policy-based reason to convert citation template dates away from ISO format. 1Veertje (talk) 11:36, 21 March 2026 (UTC)[reply]
This is not an issue. The vast majority of articles use full date, not YYYY-MM-DD. GiantSnowman 11:47, 21 March 2026 (UTC)[reply]
The vast majority of articles were written before date formatting could be handled consistently via {{Use dmy dates}} / {{Use mdy dates}}. I didn’t mean to edit from TA, I was accidentally logged out. I think it’s pretty obvious I made the edit. 1Veertje (talk) 11:59, 21 March 2026 (UTC)[reply]
There are 4 allowed formats for displaying dates:
  1. dmy in text, dmy in references.
  2. dmy in text, ymd in references.
  3. mdy in text, mdy in references.
  4. mdy in text, ymd in references.
For the date format used within the wiki markup for references there is no policy or guideline at all – none. And it makes no difference anyway because {{Use dmy dates}} and {{Use mdy dates}} override whatever format is used in the wiki markup for references. Which means all this is a storm in a tea-cup.  Stepho  talk  12:15, 21 March 2026 (UTC)[reply]
Given that there’s no policy governing the stored format of dates in citation templates, and that {{Use dmy dates}} / {{Use mdy dates}} control the displayed format, changing yyyy-mm-dd dates in references to written-out formats does not improve the article. ISO format also has practical advantages for consistency and tool compatibility, but that is secondary to the point that there is no requirement to convert it. – 1Veertje (talk) 12:22, 21 March 2026 (UTC)[reply]
No, there is no requirement to convert it either way – which means your insistence that it must be YYYY-MM-DD is simply wrong. GiantSnowman 12:46, 21 March 2026 (UTC)[reply]
I insist you don’t change the references I formatted correctly to a date format that is not an ISO standard. 1Veertje (talk) 13:22, 21 March 2026 (UTC)[reply]
Insist all you want – you are in the wrong here. GiantSnowman 13:25, 21 March 2026 (UTC)[reply]
no, you should not have changed my properly formatted references 1Veertje (talk) 14:16, 21 March 2026 (UTC)[reply]
What you have done at the article is 1) introduce some YYYY-MM-DD date formats to references when the established format was already DD-MM-YYY, and then when I pointed you to WP:DATERETAIN, converted all date formats in references to your preferred YYYY-MM-DD, which you have restored despite this discussion and despite saying here that you would not make any further edits. If I was not INVOLVED you would be blocked for disruption. GiantSnowman 14:30, 21 March 2026 (UTC)[reply]

Can somebody revert this please? @Gawaon, Stepho-wrs, and Jc3s5h:? GiantSnowman 14:31, 21 March 2026 (UTC)[reply]

Done. @1Veertje: Apparently the article was already tagged as using DMY dates since years ago, so you should respect that. On the talk page you can suggest changing it to MDY but that’ll need good reasons and will only happen if you get consensus for the change. There’s no way in which the article date style could be changed to year-first, since that’s not one of our preferred date styles. Gawaon (talk) 16:22, 21 March 2026 (UTC)[reply]
The article is still displaying dates in dmy format due to {{Use dmy dates}}; that has not changed. My edits only affected the stored format in citation template parameters, not the rendered output. As Stepho explained, this is consistent with WP:DATERETAIN. I prefer using ISO standard 8601 for storing dates in citation parameters for consistency and tool compatibility. Citation parameters function as structured data, where this standard is commonly used, while MOS:DATES primarily governs what readers see. These are not in conflict when the dmy/mdy templates are used. There is therefore no policy-based reason to revert the change.1Veertje (talk) 18:49, 21 March 2026 (UTC)[reply]
You saying “I prefer” is the crux of the matter – it is your personal preference only, not rooted in any policy or guideline, and indeed (as detailed above by myself and others), in breach of WP:DATERETAIN. Why can’t you see this? Do you lack the competence to edit? GiantSnowman 19:03, 21 March 2026 (UTC)[reply]
I would ask that you re-read my previous message and respond to its content rather than making personal remarks. 1Veertje (talk) 19:22, 21 March 2026 (UTC)[reply]
There is nothing to respond to, that is the point. As I have said, repeatedly, nothing you say is rooted in any policy for guideline, it’s purely personal preference. GiantSnowman 19:25, 21 March 2026 (UTC)[reply]
This is ultimately a matter of formatting preference, as the rendered output of the article does not change. There is no policy requiring citation template dates to be rewritten from the default ymd format, so I don’t think they should be changed. 1Veertje (talk) 19:38, 21 March 2026 (UTC)[reply]
You are going in circles – WP:DATERETAIN says to use the existing date format, and the existing date format on the article in question was ’21 March 2026′. GiantSnowman 19:40, 21 March 2026 (UTC)[reply]
As this is about source formatting, it is a personal preference that only affects the editors of the article. I also prefer to use YYYY-MM-DD dates in the reference sections of my articles, while displaying them in mdy or dmy depending on what is appropriate for the article. I use YYYY-MM-DD because it is what my citation tools produce, so I try to keep this consistent. This works perfectly well until GiantSnowman comes along and changes my date formatting, changing the source with usually no change to the display and making it harder for me to keep my source formatting consistent. I would like to see a general prohibition against edits that change the date formatting in the wikitext like this one. —Kusma (talk) 19:39, 21 March 2026 (UTC)[reply]
Kusma, please deal with the issue at hand, rather than your hatred of me. Should 1Veertje have changed the existing date format on the article in question from ’21 March 2026′ to ‘2026-03-21’, yes or no? If ‘yes’, please explain why. GiantSnowman 19:42, 21 March 2026 (UTC)[reply]
I’m not changing the existing date format on the article. And I agree with Kusma that the edit they cited was not WP:SUBSTANTIVE 1Veertje (talk) 19:52, 21 March 2026 (UTC)[reply]
You are changing the date format used in the references. GiantSnowman 20:06, 21 March 2026 (UTC)[reply]
I added a consistent format for how dates are stored in citation parameters, including unifying existing entries. This affects how dates are stored in the wikitext, not how they are displayed; the article continued to show dmy dates. I don’t think MOS:NUM applies here, as that guidance concerns displayed content. As Stepho noted, the stored format used is acceptable. 1Veertje (talk) 20:45, 21 March 2026 (UTC)[reply]
In the case at hand, you are correct that there was an established format for the wikitext in the references, and you are the main author, so 1Veertje should have respected your choice of date formatting and not change it (and definitely not edit war about it). You of course should also respect other people’s choice of formatting and not use scripts to enforce your preferred format. I do not know whether you still do that, but edits of yours like the one I mentioned above have annoyed me greatly in the past, and have diminished my enjoyment of having my articles featured at DYK (you used to run your “date audit” script on stuff linked from the Main Page).
One general problem here seems to be that different semiautomatic tools have different standards: your reFill apparently outputs dmy, while ProveIt defaults to YYYY-MM-DD. It would be good to be able to set a standard for the date formatting in the references and have semiautomatic tools and scripts then respect that standard so editors using different tools can collaborate better without causing inconsistencies. —Kusma (talk) 21:00, 21 March 2026 (UTC)[reply]
there’s a pending change to reFill that would make it output dates in ISO 8601 by default. There was too little participation to call it a consensus but the technical contributors who showed up to discuss changing the default on the WebRef bookmarklet agreed of the preferability of using this standard. 1Veertje (talk) 21:06, 21 March 2026 (UTC)[reply]
back in 2023 there was already a technical contributor proposing reFill should really output ISO compliant dates. 1Veertje (talk) 21:14, 21 March 2026 (UTC)[reply]
The script should not be changed without discussion at Wikipedia on how the output should be. I have repeatedly said that the Script I use – and which others do (I have so many diffs saved of others making the exact same edits as me btw) – can and should be amended so that if an article is tagged somehow so that YYYY-MM-DD is the preferred date format for references, it does not change that. Otherwise, there is no way of telling! GiantSnowman 21:27, 21 March 2026 (UTC)[reply]
reFill will continue to offer its user the possibility of changing their default, but will become in line with the citation tooling already integrated in the interface and become ISO compliant. 1Veertje (talk) 21:32, 21 March 2026 (UTC)[reply]
I have started to use to ensure there is at least some sort of record what convention is being used in an article. I fully agree that having standardised tags that are recognised and respected by any semiautomatic tools would be extremely helpful. What would be needed to make that happen? —Kusma (talk) 23:01, 21 March 2026 (UTC)[reply]
I think the {{use DMY dates}} / {{use MDY dates}} needs to have a better tag than the cs=ly1 or whatever it says, AND the script needs to be changed to recognise that. GiantSnowman 08:18, 22 March 2026 (UTC)[reply]
@1Veertje: Keep in mind that you don’t OWN the article or any of the references in it. Other editors can neither know your personal preferences nor do they have any specific reason to care about them. They have every right to improve any article and you have no right to revert their edits because they contradict your personal preferences. Gawaon (talk) 20:14, 21 March 2026 (UTC)[reply]
I’m not asserting ownership of the article. My edits were to fix dead links and add citation data in a consistent stored format. I’m fine with this not being enforced as policy, but ISO 8601 isn’t “just a preference”; it is an international standard for representing dates in data, which is why it is commonly used by citation tools and for maintaining consistency in template parameters. The rendered article continued to display dates in dmy format, so the article’s date style never changed. I don’t think changing the stored citation format in this case improved the article, and I agree with Kusma’s point about this type of edit. 1Veertje (talk) 21:31, 21 March 2026 (UTC)[reply]
You are in the wrong and repeating yourself will not change that. Admit you messed up, say you won’t do it again (even though you have previously said you would not make such edits, but then 2-and-a-half hours later did anyway), and move on. GiantSnowman 21:36, 21 March 2026 (UTC)[reply]
I reverted once Stepho indicated that this formatting is acceptable. My edit did not change the article’s displayed date style; it only affected how dates are stored in citation parameters while fixing dead links. I used ISO 8601, which is commonly used by citation tools for consistency. 1Veertje (talk) 21:51, 21 March 2026 (UTC)[reply]
Yeah, but you shouldn’t have reverted. You can use what you want, but you shouldn’t prevent others from improving the article. No big deal, but just: Please don’t do it again. Gawaon (talk) 21:59, 21 March 2026 (UTC)[reply]
You seem to want to prevent people from honouring the {{Use dmy dates}} and {{Use mdy dates}} tags in many articles, by reverting people who update these tags, which means making sure that all dates are indeed in agreement with the tagged date style. That’s not a good thing. (Yes, I’ve read that in theory dates in references can use a different date format, but there’s no way to tag that and it seems just a needless overcomplication, as far as I can see.) Gawaon (talk) 21:49, 21 March 2026 (UTC)[reply]
For reference, here is the version with my edits. The rendered article still displays dates in dmy format due to {{Use dmy dates}}, so the article’s date style remained unchanged. At no point did I disrespect this template. 1Veertje (talk) 21:55, 21 March 2026 (UTC)[reply]
WP:DATERETAIN concerns the appearance of dates in the source coding, not only in the rendered appearance. —David Eppstein (talk) 21:57, 21 March 2026 (UTC)[reply]
In this thread so far, Kusma, Stepho and I interpret this differently. My understanding is that {{Use dmy dates}} / {{Use mdy dates}} handle the displayed date format, while citation template parameters function as structured data. Using ISO 8601 for stored dates is compatible with that, as it does not affect the rendered article style. 1Veertje (talk) 22:09, 21 March 2026 (UTC)[reply]
Your understanding is, once again, incorrect. What Kusma is saying is that YYYY-MM-DD is an acceptable date format for references (the ultimate display output is irrelevant btw) – what Kusma and everybody else is saying is that when the established reference date format is ’21 March 2026′, your should NOT change that to ‘2026-03-21’. Do you understand that? GiantSnowman 22:13, 21 March 2026 (UTC)[reply]
By the same reasoning, dates already stored as yyyy-mm-dd should also be left as they are, with the {{Use dmy dates}} / {{Use mdy dates}} templates handling the displayed format. 1Veertje (talk) 22:23, 21 March 2026 (UTC)[reply]
I don’t agree that the rendered output is irrelevant. MOS:DATES is primarily about what readers see, and in this case the displayed format remains dmy due to {{Use dmy dates}}. This appears to be a difference in preferred formatting of citation parameters rather than a policy requirement. 1Veertje (talk) 22:51, 21 March 2026 (UTC)[reply]
There are also practical reasons to let templates handle presentation while storing dates in a consistent format, as this improves compatibility with citation tools and maintenance. Consistent formats such as ISO 8601 are widely used in tooling because they are easier to process reliably. 1Veertje (talk) 23:04, 21 March 2026 (UTC)[reply]
You are once again missing the point. Do you understand that, as David says, “WP:DATERETAIN concerns the appearance of dates in the source coding, not only in the rendered appearance”, and as multiple others have said, the dates should not be changed to YYYY-MM-DD? GiantSnowman 08:21, 22 March 2026 (UTC)[reply]

I think this discussion would be better moved to Wikipedia talk:User scripts, where it can be treated as a technical issue. As noted above, storing dates in ymd format in citation parameters does not change the displayed article style when {{Use dmy dates}} / {{Use mdy dates}} are present. This therefore seems less a style issue and more a question of how data in citation templates is stored. If citation parameters are treated as structured data, consistently storing dates in a single format (such as ISO 8601) improves predictability and compatibility with tools such as VisualEditor and translation tools. There are also practical advantages: if the preferred display format changes, it can be handled centrally by templates rather than requiring changes across many individual references, and consistency is easier to maintain. Please consider that applying WP:DATERETAIN to stored citation parameters may reflect an earlier situation where storage and presentation were coupled. Now that templates make it possible to separate these concerns, it may be worth reconsidering whether applying DATERETAIN at that level leads to unnecessary duplication of effort. 1Veertje (talk) 07:06, 22 March 2026 (UTC)[reply]

It’s not just or chiefly a technical issue. Mere readers might not see the raw reference formatting, but for editors it’s confusing if dates in the source code and rendered text use different formats, plus something like 2026-07-05 is for many people arguably more confusing and less intuitive at first sight than 5 July 2026. Also getting your tools to output properly formatted DMY or MDY dates is no rocket science. The best solution would be to fix your tools to do just that. The second best is to continue to add YMD dates and then let others properly format them for you, if they choose to do so. Either way, if you think you can overthrow DATERETAIN, please start a discussion/RfC about it, but until then, please respect it. And I’m out of here now. Gawaon (talk) 08:23, 22 March 2026 (UTC)[reply]
I think any editor who is able to handle something as confusing as a citation template is going to be able to deal with ISO date formatting, which is the only option we have where we do not have to spell out the name of the month. —Kusma (talk) 12:56, 22 March 2026 (UTC)[reply]
I see this primarily as a technical issue. Wikitext functions as the source code of the article, and in citation templates the date parameter is effectively data. From that perspective, storing dates in a consistent format (such as ISO 8601) avoids pre-formatting and makes maintenance and tooling more predictable. It also avoids ambiguity in day/month ordering and removes reliance on spelled-out month names (which is more vulnerable to typos). I understand that some editors value consistency in the wikitext itself for readability, but there is also a benefit to making citation data consistent and machine-readable. The {{Use dmy dates}} / {{Use mdy dates}} templates allow these concerns to be separated by handling presentation independently of storage. Given that, this seems less a question of article style and more about how citation data should be stored and handled by tools, which is why I suggested moving the discussion to Wikipedia talk:User scripts. 1Veertje (talk) 13:46, 22 March 2026 (UTC)[reply]
I would also not conclude that there is a clear consensus in one direction here; the views expressed so far appear split.
I’ve tried to outline a coherent argument that this is better treated as a question about how citation data is stored and handled, in a way that is equally legible to both humans and tools, and therefore may be more appropriate for discussion among technical contributors at Wikipedia talk:User scripts.
As Stepho noted, different date notations can coexist in citation parameters without affecting the displayed article style, as the {{Use dmy dates}} / {{Use mdy dates}} templates handle presentation.
Given the disagreement, it may be best to avoid further changes of this kind until there is clearer guidance or consensus (for example via an RfC). 1Veertje (talk) 19:36, 22 March 2026 (UTC)[reply]
Re “the views expressed so far appear split”: yes. Your views are split from everyone else’s. Beyond that I don’t see a lot of division. A one-person WP:FILIBUSTER is not a lack of consensus. You might also find WP:BLUDGEON relevant. —David Eppstein (talk) 20:05, 22 March 2026 (UTC)[reply]
I don’t agree with that characterization. I’ve tried to explain my reasoning clearly, and I think it raises a legitimate question about how citation data should be handled. As noted, this seems to be an area where there are differing interpretations, which is why I suggested moving the discussion to a more appropriate venue or considering an RfC. 1Veertje (talk) 20:31, 22 March 2026 (UTC)[reply]
No, of course you wouldn’t agree. I’m going to be blunter than David: nobody supports your position, and the fact that you cannot recognise that and that you are continuing to pursue it is concerning.
Now, putting aside the origin of this dispute, I will give you some good faith advice: please stop. If you don’t, you will end up making more disruptive edits and then pissing off the wrong admin in trying to explain/defend it, and ultimately getting blocked. Nobody wants that. Go edit in a different area. GiantSnowman 21:13, 22 March 2026 (UTC)[reply]
1Veertje, as a non-involved admin who has been observing this discussion, I think Giant Snowman is giving you good advice. Please find something else to work on. Donald Albury 21:51, 22 March 2026 (UTC)[reply]
no, MOS should stay in its lane and concern itself with style, not with the way data is stored in wikitext. I respected the “use dmy/mdy date” more than he is doing by letting it do its job of formatting the date as it is stored in the reference. It was not an improvement to move away from a date notation that is the International standard when storing data. I know longtime users are used to seeing wikitext as just another visual aspect of Wikipedia, but its primary purpose is to store both the factual information and the formatting information. Repeating what formatting the rendered side of Wikipedia is using in every reference has many downsides as I’ve been trying to explain. I get that it is hard to respect that considerations should be made for non-human readers. Try to understand what happens when you don’t: the visualEditor has a harder time parcing a date, making the chance of new editors ever slightly less likely. Every bot that checks references has to be prepared for a multitude of date formats, including typos, which are more likely when the month is written out in full. There are python libraries that catch these issues without requiring the individual programmer to think of every possible variation you are being tolerant towards, but in recent times the tool most easily reached for is an LLM. GiantSnowman is not participating in this discussion in good faith. He has so far accused me of being blind, disrespecting a template when I very clearly have my reasons and of not having anyone on my side when both Kusma and Stepho have let it known that they see it as either perfectly fine to format a date in ymd or even annoyed that they keep making edits they see as not making a difference. They themselves should check MOS:NUM, which they keep citing. It does not mandate the format in which a date should be stored because that is not its function. It is not I who is enforcing a personal preference over a standard, as I keep explaining. 1Veertje (talk) 23:24, 22 March 2026 (UTC)[reply]
WP:WALLOFTEXT.
Btw, Kusma said you should not have made the edits you did. GiantSnowman 18:20, 23 March 2026 (UTC)[reply]
Yup. I personally prefer YYYY-MM-DD, but more importantly I respect the choices of other people to use other conventions in their wikitext, and I want my choices to be respected as well. GiantSnowman used a reasonable and consistent style; as a non-major contributor to the article in question, 1Veertje had no business changing this to their preferred style. To selectively quote from a statement about a somewhat related topic, “people hold passionate beliefs. We have chosen one of several popular styles. Pick a style that suits you, then use it consistently.” —Kusma (talk) 18:47, 23 March 2026 (UTC)[reply]
And for the avoidance of any doubt, I do not have any issues with ‘YYYY-MM-DD’ is that is the preferred format (see my comment above about tagging and scripts being adapted to reflect that). What I do have issue with is the lack of consistency. I see so many articles that have date formats (in and out of references) showing as ’23 March 2026′, ‘March 23, 2026’, and ‘2026-03-23’…! GiantSnowman 19:02, 23 March 2026 (UTC)[reply]

To summarise the four allowed date-style combinations mentioned by Stepho:

Date style Compatible with MOS:NUM Compatible with ISO 8601
dmy in text, dmy in references ✓ ✗
dmy in text, ymd in references ✓ ✓
mdy in text, mdy in references ✓ ✗
mdy in text, ymd in references ✓ ✓

I value consistency just as much — which is precisely why I favour the combinations with ymd in references. Those are compatible both with MOS:NUM and with ISO 8601 — an international standard, not an arbitrary format preference. Consistent ymd storage in citation parameters makes tooling easier, because scripts and bots can work from one unambiguous format rather than many possible written-out variants.

This is the practical background to my concern here. I use the WebRef bookmarklet because DPG Media, the largest newspaper publisher in the Netherlands, has a hard cookie wall that the Citoid API cannot get past, so an API-based tool is not always an option for those sources. I want WebRef to default to ymd so that its output is immediately reusable on the Dutch Wikipedia and in articles using {{Use dmy dates}} or {{Use mdy dates}}. While I could fork it, as I explain at its talk page, the bookmarklet likely still has a substantial user base, so the default there matters.

The same issue arises with reFill, where a Croatian editor requested ISO 8601 as the default because localized month abbreviations produced by the tool do not match local citation practice. That is exactly the kind of tooling problem a consistent machine-readable date format helps avoid. 1Veertje (talk) 20:32, 26 March 2026 (UTC)[reply]

Does Bas van Wegen (Diff ~1344334278) by @GiantSnowman fall under WP:COSMETIC? I suppose it changes the category. — Qwerfjkltalk 13:24, 27 March 2026 (UTC)[reply]
I do not think it was merely cosmetic. It changed citation parameters away from ISO 8601, an international standard that many Wikipedias can localize correctly in display through template logic and local configuration. See Croatian example. So while the rendered result on enwiki may have remained similar, the edit moved the stored data away from a more reusable format. To make the formatting uniform, I then made this follow-up edit (while accidentally logged out). 1Veertje (talk) 14:21, 27 March 2026 (UTC)[reply]
1Veertje, if it does not affect the rendered page, it is cosmetic. Please have another look at the link I gave. — Qwerfjkltalk 17:54, 27 March 2026 (UTC)[reply]
@Qwerfjkl I understand your point about WP:COSMETIC, and I agree that under that definition this may be considered cosmetic in terms of the rendered output. However, I see this primarily as a technical issue concerning how citation data is stored, rather than a stylistic one about what readers see. Citation parameters function as structured data, and from that perspective there are advantages to using a consistent, machine-readable format compliant with ISO 8601.
If tools or scripts are used to harmonize date formats in references, I would therefore expect that discussion to consider not only visual consistency but also data consistency and interoperability across tools and language versions. From that perspective, a move towards ISO-standard formatting would seem more future-proof than away from it. That said, I agree this likely needs a clearer consensus or discussion in a more technical venue. 1Veertje (talk) 18:02, 27 March 2026 (UTC)[reply]
Yes, it was indeed a cosmetic edit, since it didn’t change the rendered page. Gawaon (talk) 19:30, 27 March 2026 (UTC)[reply]
No, my edit was not COSMETIC per WP:COSMETICBOT. The edits of 1Veertje were. GiantSnowman 13:07, 28 March 2026 (UTC)[reply]
How did your edit change the rendered page? Gawaon (talk) 14:23, 28 March 2026 (UTC)[reply]
the “administration of the encyclopedia”, such as the maintenance of hidden categories used to track maintenance backlogs (e.g. changing {{citation needed}} to {{citation needed|date=September 2016}} GiantSnowman 14:54, 28 March 2026 (UTC)[reply]
The edits from both Snowman and 1Veertje are cosmetic because they do not affect the rendered output or anything off the page (eg categories). However, cosmetic changes can still be useful.
Personally, I love the ymd format and would love to use it everywhere. Reality is that other people don’t agree and think that it is confusing – mostly because they are not familiar with it. There is also the problem that the date field sometimes represents an actual date and sometimes represents a label on a magazine cover. This label is often in the form of “Spring 1987”, “August 2002”, “Oct-Nov 2013” and does not map to ymd at all. Sometimes we get dates like “circa 684-687” for historical quotes, which maps even worse to ymd. So the goal of using ymd everywhere is a great goal but won’t work. The templates will just have to handle the common formats and skip anything they don’t understand. Trappist’s comments in the section below carry great weight here because he implemented a lot of the reference date handling templates.
Changing the date format from ymd to dmy is also cosmetic. However, I can see the appeal of having a single date format in the wiki text instead of both dmy (displayed) and ymd (wiki markup).
Personally, I enter all dates for reference fields as ymd. I recognise that this is a personal choice based on my own preferences (I’m mildly autistic and I love its uniformity and the fact that filenames using this format will sort alphabetically correctly). I do get annoyed that occasionally somebody uses a script and changes them all to dmy or mdy. But I also just leave it be because it doesn’t really affect the output and the usefulness of ymd is not agreed by all people (yet).
Changing the reference field date format is as useful as those wonderful people who “correct” British spelling into America spelling or “correct” American spelling into “British spelling. But it is even less useful because even fewer people can see it. Then we get edit wars, grumpy discussions at MOS and accusations of WP:OWN.
To sum up, type in whichever format floats your boat, let the reference templates render it and then leave the bloody thing alone. Don’t change the format to your own preference. But don’t worry if somebody else does.  Stepho  talk  01:22, 29 March 2026 (UTC)[reply]
Again, please actually read COSMETICBOT. But your comment Don’t change the format to your own preference is one that 1Veertje has been repeatedly told by numerous editors and which she has repeatedly ignored. GiantSnowman 08:48, 29 March 2026 (UTC)[reply]
I agree with your point that changing formats in existing references is not helpful and tends to lead to unnecessary conflict. The broader question I’d like us to focus on, is slightly different: for new or updated references, especially in cs1|2 parameters with single full dates, would it make sense to treat ymd as a preferred storage format? This is already the default output of the citation tool in VisualEditor, IABot, and — with a pending change — reFill. It would make it easier to reuse references across articles with different display styles and across language versions, while letting templates handle the presentation. Exceptions (ranges, seasons, BCE dates, etc.) would of course still need to be handled as free-form values. 1Veertje (talk) 11:12, 29 March 2026 (UTC)[reply]
Tools/scripts do not determine Wikipedia policy/guidelines – it is the other way around. GiantSnowman 11:34, 29 March 2026 (UTC)[reply]
That default in the VisualEditor didn’t happen arbitrarily. It’s also the only notation that makes references reusable across articles with different date formats, and across language versions, without modification. 1Veertje (talk) 19:38, 29 March 2026 (UTC)[reply]
Among other reasons (like Julian calendars) why this is not a universally-good choice, numeric dates make it impossible to distinguish the two different dates March 2026 and 1 March 2026, and impossible even to represent dates like Spring 2026.
And VisualEditor is hardly a convincing argument for good engineering. VisualEditor is a large part of the reason why reference date formatting is so often inconsistent. —David Eppstein (talk) 19:50, 29 March 2026 (UTC)[reply]
This is definitely something that’s sbhoold be classified as COSMETIC. It has no impact on how the page is displayed. — LCU ActivelyDisinterested «@» °∆t° 16:21, 29 March 2026 (UTC)[reply]
My preference is for the policy to state that if an article has either {{use mdy dates}} or {{use dmy dates}} the it is permissible to change date formats in cs1|2 templates to ISO 8601, otherwise stick with what the article uses. — Shmuel (Seymour J.) Metz Username:Chatul (talk)

Single full dates versus (a) ranges and (b) dates with no day

I don’t have an opinion on the above proposals, except to point out that a single full date with a year, month, and day is not the only kind of allowable date per MOS, and thus not the only kind of date that appears in citation date parameter values. We have acceptable dates that include month ranges (March–April 2017), year ranges (2017–2018), year-only (2017), month and year only (March 2017; note that YYYY-MM e.g. 2017-03 is not permitted), seasons (Spring 2017), day ranges (5–12 March 2017 or March 5–12, 2017), and dates with an era label (2017 BCE). If you’re going to craft new guidance about using YYYY-MM-DD, please ensure that it applies to single-day full dates only. – Jonesey95 (talk) 20:10, 27 March 2026 (UTC)[reply]

If this discussion is about template dates, and assuming by that we mean cs1|2 templates, era label (2017 BCE) dates are not supported except in |orig-date= which is a free-form text-holding parameter. And, era dates before the Gregorian calendar (October 1582) are not supported by ISO 8601. For Julian calendar publication dates, YYYY is likely all that is needed. Because COinS metadata requires ISO 8601 date formats, we truncate Julian calendar publication dates prior to October 1582 to the year portion of the supplied date regardless of its precision.
Back in 2017, there was a long discussion at T132308 where we considered implementing the Extended Date/Time Format (EDTF) Specification; that specification was considered for inclusion in ISO 8601 as Part 2: Extensions. I don’t know if that ever came to be. Editors interested in this discussion should probably read the T132308 discussion.
And since I’m here: the {{use xxx dates}} templates do nothing; to say that they do is to misspeak. cs1|2, by way of Module:Citation/CS1/Configuration, reads the article wikitext to extract the first {{use xxx dates}} template (if present) and adjusts date presentation formats accordingly. No {{use xxx dates}} (or recognized redirect), no date reformatting.
—Trappist the monk (talk) 22:17, 27 March 2026 (UTC)[reply]
ISO 8601 was revised in 2019 and split into two parts. Part 1 is nearly the same as the 2004 version. Part 2 incorporates many of the ideas from Extended Date/Time Format but differs in details. Neither part supports anything other than the Gregorian calendar. Jc3s5h (talk) 04:20, 29 March 2026 (UTC)[reply]
YYYY-MM-DD dates also have issue with disambiguation and short form references. As the normal disambiguation by year no longer works, anyone changing these dates must ensure the are not generating no target errors. — LCU ActivelyDisinterested «@» °∆t° 16:25, 29 March 2026 (UTC)[reply]
And not no double negatives, neither. EEng 05:12, 30 March 2026 (UTC)[reply]
Noun not adjective. Maybe I should have written No Target so it was clearer. — LCU ActivelyDisinterested «@» °∆t° 09:20, 30 March 2026 (UTC)[reply]

Updating Cite web documentation to reflect ymd as slightly preferred format for single full dates

Several editors in this discussion have noted that they personally use or prefer ymd for citation parameters, while also agreeing that changing existing formats is not helpful. A concrete next step would be to update the documentation for {{Cite web}}. This could reflect this without mandating changes to existing articles.

This would clarify that ymd is not a formatting error to be corrected, and would better reflect how references are increasingly added in practice — through VisualEditor, IABot, and similar tools that already output ymd by default. {{Cite web}} is specifically for sources published on the internet, where Julian calendar dates are not a practical concern. Exceptions such as month-only dates, ranges, and seasons would naturally remain in free-form notation, as they cannot be expressed in ymd. There is no ambiguity between 2026-04-01 and April 2026.

Keeping the documentation aligned with how major citation tools actually output dates would reduce unnecessary inconsistency, and would make it easier for tools targeting multiple language versions to use a single output format.1Veertje (talk) 12:45, 5 April 2026 (UTC)[reply]

I finally read the whole thread. Whether the “major citation tools” prefer ISO dates seems irrelevant for human editors. ISO dates are easier to code, especially if the tools need to be written for multiple language Wikipedias. This proposal seems like it’s based on a misunderstanding. Rjjiii (talk) 23:32, 5 April 2026 (UTC)[reply]
1Veertje’s entire approach to this issue is based on a misunderstanding… GiantSnowman 11:57, 6 April 2026 (UTC)[reply]
One aspect that seems underweighted in this discussion is the co-existence of human editors and automated tools. Several editors have noted that tools shouldn’t drive formatting decisions — but tools have different constraints than humans, and dismissing tool compatibility entirely puts unnecessary burden on the people maintaining those tools. It’s also worth noting that many editors’ preference for spelled-out dates formed at a time when ISO storage offered no practical advantage. That context has changed. 1Veertje (talk) 18:07, 7 April 2026 (UTC)[reply]
Tools aren’t as stupid as you make them to be. To correctly format or parse a date in DMY style instead of ISO, the only additional info it needs are the English names of the 12 months. That’s not a hurdle that should make any decent tool stumble. If your tool can’t handle it, then frankly: find a better one. Gawaon (talk) 20:15, 7 April 2026 (UTC)[reply]
I mean there is absolutely nothing wrong with the current way of operating? 1Veertje seems stubbornly determined to fix a problem that isn’t there… GiantSnowman 20:44, 7 April 2026 (UTC)[reply]
To add a practical dimension: ymd is the only stored format that can be copied directly into an article regardless of whether it uses {{Use dmy dates}} or {{Use mdy dates}}, and reused without modification on other language Wikipedias. A reference with |date=2026-04-08 works everywhere. A reference with |date=8 April 2026 needs to be changed when copied to an mdy article, and definitely does not match local citation practice on non-English Wikipedias. The reFill fix shows what happens when tools try to output localized spelled-out dates: the previous implementation using babel.dates produced abbreviated month names in Czech and Dutch that matched neither local practice nor what any human editor would write. ISO 8601 as the universal standard was the only thing that actually worked. That is not a tooling limitation to be dismissed — it reflects that enwiki does not exist in isolation. 1Veertje (talk) 22:12, 7 April 2026 (UTC)[reply]
That argument to practicality would only be valid if you somehow hadn’t paid any attention to all of the many cases stated above where numeric dates cannot be used at all. —David Eppstein (talk) 23:16, 7 April 2026 (UTC)[reply]
I have addressed this above — exceptions such as month-only dates, ranges, and seasons cannot be expressed in ymd and would naturally remain as free-form values. The portability argument applies to single full dates only. 1Veertje (talk) 03:51, 8 April 2026 (UTC)[reply]
If it ain’t broke… GiantSnowman 17:31, 8 April 2026 (UTC)[reply]
@1Veertje, take a look at the history for St. Amant High School. I just addressed a bunch of inline tags using auto-formatted citations while noting which tools I use in each edit summary. I even started with a custom script that just outputs the url, title element, and current day in ISO format. The scripts give variously formatted output, but all of the dates are displayed in MDY formatting. It would cause no issue at all if a person or bot were to convert those dates in the source code over to MDY or to YDM. I don’t see how your proposal addresses a problem. Rjjiii (talk) 00:19, 9 April 2026 (UTC)[reply]
One practical issue that keeps coming up in tooling is that the absence of a clear preference for Y-M-D makes it harder to produce output that is portable across language Wikipedias.
This has come up before in tools like WebRef and reFill, where developers assumed that formatted dates were required, even though citation templates can already localize Y-M-D output at display time.
I’m not suggesting changing existing references or enforcing a site-wide format, but noting that from a tooling perspective, Y-M-D is the only format that can be reused without modification across different contexts. Converting such dates in the source code is therefore often an unnecessary additional step rather than a requirement. 1Veertje (talk) 10:26, 9 April 2026 (UTC)[reply]
Well, since we’ll never get to a situation where all dates in references would be YMD, it’s a necessary step anyway. Gawaon (talk) 14:33, 9 April 2026 (UTC)[reply]
1Veertje, you are once again failing to explain why there is a problem that needs fixing, and/or why your solution is the right way to do it. I suggest this is because ‘there isn’t’ and ‘it isn’t’, respectively. GiantSnowman 17:49, 9 April 2026 (UTC)[reply]
I agree. Personally, I find the YMD format confusing, and harder to read than formats with the date spelled out. As a matter of neatness and consistency, my preferred state is to have citation dating match the same format as the body of the article, DMY or MDY as appropriate per TIES and RETAIN, and I don’t understand why a few editors occasionally push for having citations differently formatted from their articles. Far from having a minor preference for YMD, as the OP proposes, I would have a strong preference for not using it. MapReader (talk) 06:54, 10 April 2026 (UTC)[reply]
p.s. and, incidentally, there seems to have been an increase recently of editors inserting YMD citations into articles tagged as DMY or MDY. Do we have a cite template that is defaulting to YMD regardless of the preferred formatting for the article? MapReader (talk) 06:56, 10 April 2026 (UTC)[reply]
Can you provide an example of an article with {{use mdy}} or {{use dmy}} where {{cite web|date=ISO date}} is rendered as yyyy-mm-ddd instead of respecting the default style? — Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:08, 10 April 2026 (UTC)[reply]
If you want to the data to be portable, then take all the data out of en:wp (to wikidata?), format it how you like then it can be imported where ever after that, but it’s an unreasonable expectation to require the globalisation to be undertaken on en:wp when en:wp happily accepts other date formats. Nthep (talk) 15:28, 10 April 2026 (UTC)[reply]

Specifically, the documentation could note that when {{Use dmy dates}} or {{Use mdy dates}} is present in an article, ymd stored dates are automatically reformatted for display, making the per-citation df parameter unnecessary in that context. 1Veertje (talk) 12:54, 5 April 2026 (UTC)[reply]

The last point you mention is already in the docs, search for “Automatic date formatting”. Personally I’m not convinced that further changes are needed. Gawaon (talk) 15:26, 5 April 2026 (UTC)[reply]
The documentation for the CS1 and CS2 templates is intertwined, and structured so that information that applies to more than one of these templates is in one location so that when a change is needed, it need only be changed in one place. This creates a mindset that all these templates are nearly the same, and anything read about one of the templates probably applies to all of them. So having divergent recommendations about how to write a date is likely to create confusion. I will post a notice of this discussion at Help talk:Citation Style 1 and Help talk:Citation Style 2. Jc3s5h (talk) 15:58, 5 April 2026 (UTC)[reply]
If they dates are automatically formated by one of the “Use xxx dates” templates the it’s pointless, and if one of the templates isn’t in use then it’s going to potentially introduces dates that don’t match an article’s preexisting style. As I mentioned above the format doesn’t work well with short form references that use disambiguation. It’s not a major issue but is complicated by the error messages for short form refs being off by default. I know some editors prefer it, but personally I don’t see an upside for this and potential for negatives. — LCU ActivelyDisinterested «@» °∆t° 17:13, 5 April 2026 (UTC)[reply]
Sorry, in what way is ymd the ‘slightly preferred format for single full dates’?! In my experience, the vast majority of editors use MDY or DMY. GiantSnowman 17:50, 5 April 2026 (UTC)[reply]
+1. —David Eppstein (talk) 18:51, 5 April 2026 (UTC)[reply]
+2. I for one would also object to any attempt to forbid the normalization of all dates in an article to the locally preferred format (DMY or MDY, never anything else). Gawaon (talk) 19:42, 5 April 2026 (UTC)[reply]
Just for clarity are these meant as replies to 1Veertje or to me? — LCU ActivelyDisinterested «@» °∆t° 21:40, 5 April 2026 (UTC)[reply]
My comment (and David Eppstein’s too, I guess) is a reply to GiantSnowman, as per the usual indentation rules. Gawaon (talk) 07:23, 6 April 2026 (UTC)[reply]
I guess I caused the same confusion, as my comment should have been a reply to GiantSnowman. If their comment is a reply to me I can understand it in context to my comment. — LCU ActivelyDisinterested «@» °∆t° 12:15, 6 April 2026 (UTC)[reply]
No, my original comment was a reply to the general thread/topic! GiantSnowman 12:16, 6 April 2026 (UTC)[reply]

I have removed the tl template from the title of this section because it inhibits linking to this discussion. Jc3s5h (talk) 16:07, 5 April 2026 (UTC)[reply]

ah, thank you 1Veertje (talk) 16:49, 5 April 2026 (UTC)[reply]

Several technical notes:

  • Non-CS1/CS2 dates still exist in many citations.
  • {{Webarchive}} does not auto-format dates. It is used for over 1.4 million citations across 680,000 articles. It would need to call Module:Auto date formatter as {{cite patent}} and {{cite comic}} do.[2][3] The change is pretty simple, but the module probably needs the tracking code discussed on the talk page, and there may be unintended issues down the line.
  • {{CS1 config}} will also affect date formatting. I don’t know if something that technical should be in the MOS, but it probably is relevant to these conversations.
  • The shortened footnote citation templates created by Module:Footnotes will sometimes require an extra parameter with YMD dates. For example, |date=31 December 1999b would have to replaced with |date=1999-12-31 and |year=1999b. Because of the way anchors are generated by the the module, this should (I think) technically be done in any article but is typically only done when paired with {{sfn}} and so on.

Feel free to ask questions if any of that is unclear, Rjjiii (talk) 18:08, 5 April 2026 (UTC)[reply]

There have been at least a couple of requests at Template talk:Webarchive to apply date formatting per the {{use xxx dates}} templates. The requests have been rejected; see:
{{CS1 config}} does not cause cs1|2 templates to reformat dates. Because we already use the {{use xxx dates}} templates for that, using {{cs1 config}} would be pointlessly redundant or confusingly contradictory.
—Trappist the monk (talk) 18:39, 5 April 2026 (UTC)[reply]
You’re right. I’m distracted with boiling crawfish, I suppose. I struck that note above. Just going from memory, I misremembered the formatting keywords as being in the wrong template. Rjjiii (talk) 18:45, 5 April 2026 (UTC)[reply]

Commas after years in Australian English

I’ve made a search of the archives without finding a definitive answer:

In Australian English, which sentence construction is correct?

“In April 2017, Frank married Sheila.”
“In April 2017 Frank married Sheila.”

What are the rules of grammar regarding use of a comma after a year in Australian English?

In American English, the date format places commas before and after the year, except in some edge cases, but in Australian English for DMY dates, using the comma after the year is deprecated in the Australian Government Style Manual.

I may be getting old, but I’ve always regarded a comma as indicating a pause, unless we’re dealing with long numbers or CSV or such. If the date precedes or is part of a parenthetical clause, use commas on both sides (eg. “When Frank married Sheila, on 7 December 1941, the weather that day was clear and calm.”) but otherwise, why use a dramatic pause?

Asking Perplexity Pro and Claude gives answers quoting the AGSM:

In Australian English, the correct construction is “In April 2017 Frank married Sheila.” No comma is needed after the year.

Australian style follows the day-month-year sequence (e.g., 14 April 2017) without punctuation between elements in body text. When only month and year appear at the sentence start, like “In April 2017,” omit the comma after the year, as it’s unnecessary for clarity in this format—unlike American English, which often adds commas.

The Australian Government Style Manual explicitly states: “Don’t include a comma or any other punctuation” for such dates.

When I look at an article I’ll occasionally tidy away such commas unless they are part of a parenthetical clause, where a pause is required. Apparently this tweaked a nerve in a biographical article on a subject where Australian opinion is apparently sharply divided on the matter of war crimes, and well, I thought I’d best bring this here. Is there any definitive, hard and fast rule on commas in dates? —Pete (talk) 21:02, 12 April 2026 (UTC)[reply]

Also, a Government Style Manual supposedly governs the government, or some parts of it, but others may or may not follow it, just as with other style guides. Gawaon (talk) 21:41, 12 April 2026 (UTC)[reply]
For context please see Talk:Ben Roberts-Smith#What’s your story?. TarnishedPathtalk 00:37, 13 April 2026 (UTC)[reply]