Help talk:Citation Style 1/Archive 54

auto date formatting
Harking back to this conversation, an unrelated conversation elsewhere has pointed me to a possible solution which I have hacked into Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox. In the December 2012 test, using this same testcases page (1192 cs1|2 templates), the test bombed with timeout errors. This brand new 2019 test has at the bottom of the testcases page. It does not die.

Module:Citation/CS1/Configuration/sandbox sets a new variable  to the   form of the date format keyword used by df according to which of  or  (or their redirects) is found in the article's wikitext. In Module:Citation/CS1/sandbox, when df is not set (omitted, empty, or has an invalid keyword), it will be set to the value in. This permits editors to manually override the auto date formatting if they so choose.

Keep? Discard? Discuss?

—Trappist the monk (talk) 14:40, 11 March 2019 (UTC)
 * The stress test is Barack Obama. There are templates other than citation templates on most pages. I saw the change and thought "wouldn't it be nice", but I do not think it will perform acceptably. --Izno (talk) 14:54, 11 March 2019 (UTC)
 * Ok, User:Trappist the monk/Barack Obama is a copy of Barack Obama where all of the cs1|2 templates are the ~/new version (sandbox) and is commented out; no other changes.  Here is the parser reports taken from each:
 * {| class="wikitable"

!User:Trappist the monk/Barack Obama !! Barack Obama
 * +parser reports
 * }
 * —Trappist the monk (talk) 15:49, 11 March 2019 (UTC)
 * }
 * —Trappist the monk (talk) 15:49, 11 March 2019 (UTC)
 * —Trappist the monk (talk) 15:49, 11 March 2019 (UTC)


 * The conversation Trappist the monk referred to in the first post in turn refers to citoid. That page is an abomination. It refers to using ISO, but fails to say which version of which ISO spec. It gives the example yyyy/mm/dd (note the slashes rather than hyphens). It threatens to use this for all dates in the future, not just access dates. So will that apply to months (such that this month would be 2019-03), which are potentially indistinguishable form year ranges, and forbidden in WP:MOSNUM? When restricted to access dates, we don't have to worry about false metadata because all access dates will be after the founding of Wikipedia, and therefore will be in the Gregorian calendar. But we do risk emitting false metadata for other dates, since many publications from places such as Russia and Greece have specific, accurate-to-the-day publication dates, have been digitized, and did use the Julian calendar. Jc3s5h (talk) 16:12, 11 March 2019 (UTC)
 * This change has nothing to do with ISO 8601. This change has nothing to do with citoid.  This change has nothing to do with calendar conversion.  This change only converts date formats from any of mdy, dmy, or ymd format to the date format specified by either of  or, or their redirect templates, when they are present in the article's wikitext.  When these  templates are not present in the article's wiki text, this change does nothing.  Because of how df works, when there are date format errors in a cs1|2 template, none of the dates in that template are reformatted.
 * —Trappist the monk (talk) 16:57, 11 March 2019 (UTC)
 * If we are going to auto-format dates in this way, it seemed to me that we should auto-format all dates that can be formatted. The current module cannot reformat date ranges so I have tweaked the Module:Citation/CS1/Date validation/sandbox so that it does; these are the dates that the current module will reformat:
 * these are range dates that the current module will not reformat:
 * —Trappist the monk (talk) 13:12, 20 March 2019 (UTC)
 * One format I like to use (explicitly allowed by MOS) is to use either mdy or dmy dates for the publication dates of citations (as appropriate for the cultural background of the article) but YYYY-MM-DD dates for accessdate and archive-date parameters. Can your date auto-formatter handle this? —David Eppstein (talk) 15:37, 20 March 2019 (UTC)
 * I have been thinking about this issue. As it stands, the current code cannot determine if it should format access and archive dates one way and publication dates another.  This is because  and  (and their redirects) only indicate the date format to be used throughout the article and say nothing about the MOS-allowed access-/archive-date exception.  There are a couple of possibilities: add a parameter to, perhaps ymd (where   is the only allowed value), or create an alternate template  etc.  In either case, Module:Citation/CS1/Configuration would set a flag that would tell Module:Citation/CS1/Date validation to reformat access and archive dates ymd and the publication dates to be xxx as specified by the  template.  The parameter is probably best to avoid forking.
 * —Trappist the monk (talk) 16:06, 20 March 2019 (UTC)
 * And a working version that uses can be seen at User:Trappist the monk/Barack Obama.
 * —Trappist the monk (talk) 18:33, 20 March 2019 (UTC)
 * Other things that occur to me with regard to this enhancement:
 * add the keywords  and   to the list of acceptable keywords for df; these keywords are like the   keywords except that they will format publication dates to dmy or mdy but will format access-/archive-dates to ymd.
 * add a maintenance category when conflicts with existing df parameters.  If we implement auto-formatting, df becomes rather less useful, maybe even useless.  As it is right now df overrides the auto-formatting (there are eleven cases of this in User:Trappist the monk/Barack Obama).  Or we could just deprecate and remove df?
 * Not necessarily related to auto-formatting dates, but this same mechanism might be extended into a special template that does nothing but hold cs1|2 configuration data for the article. For example, there might be a template that is  that would tell every cs1|2 template that it is to be rendered as if it were, and that publication dates are to be dmy with access-/archive-dates to be ymd.  Perhaps there are other things that might be done with a shared configuration template.  We don't have to decide about this now.
 * Opinions?
 * —Trappist the monk (talk) 23:18, 20 March 2019 (UTC)
 * —Trappist the monk (talk) 13:12, 20 March 2019 (UTC)
 * One format I like to use (explicitly allowed by MOS) is to use either mdy or dmy dates for the publication dates of citations (as appropriate for the cultural background of the article) but YYYY-MM-DD dates for accessdate and archive-date parameters. Can your date auto-formatter handle this? —David Eppstein (talk) 15:37, 20 March 2019 (UTC)
 * I have been thinking about this issue. As it stands, the current code cannot determine if it should format access and archive dates one way and publication dates another.  This is because  and  (and their redirects) only indicate the date format to be used throughout the article and say nothing about the MOS-allowed access-/archive-date exception.  There are a couple of possibilities: add a parameter to, perhaps ymd (where   is the only allowed value), or create an alternate template  etc.  In either case, Module:Citation/CS1/Configuration would set a flag that would tell Module:Citation/CS1/Date validation to reformat access and archive dates ymd and the publication dates to be xxx as specified by the  template.  The parameter is probably best to avoid forking.
 * —Trappist the monk (talk) 16:06, 20 March 2019 (UTC)
 * And a working version that uses can be seen at User:Trappist the monk/Barack Obama.
 * —Trappist the monk (talk) 18:33, 20 March 2019 (UTC)
 * Other things that occur to me with regard to this enhancement:
 * add the keywords  and   to the list of acceptable keywords for df; these keywords are like the   keywords except that they will format publication dates to dmy or mdy but will format access-/archive-dates to ymd.
 * add a maintenance category when conflicts with existing df parameters.  If we implement auto-formatting, df becomes rather less useful, maybe even useless.  As it is right now df overrides the auto-formatting (there are eleven cases of this in User:Trappist the monk/Barack Obama).  Or we could just deprecate and remove df?
 * Not necessarily related to auto-formatting dates, but this same mechanism might be extended into a special template that does nothing but hold cs1|2 configuration data for the article. For example, there might be a template that is  that would tell every cs1|2 template that it is to be rendered as if it were, and that publication dates are to be dmy with access-/archive-dates to be ymd.  Perhaps there are other things that might be done with a shared configuration template.  We don't have to decide about this now.
 * Opinions?
 * —Trappist the monk (talk) 23:18, 20 March 2019 (UTC)

I find the above discussion rather confusing TBH, but if this means we can have something like  which would format all references accordingly, I'm for it. Headbomb {t · c · p · b} 23:42, 20 March 2019 (UTC)
 * Not because that would conflict with ; this is also a problem with the  template idea.  If both are present in an article, which wins?
 * What do you find confusing?
 * —Trappist the monk (talk) 00:11, 21 March 2019 (UTC)
 * What I mean by that is that there's one template on the page, and not 234 . I don't really care what template it is in the end, I just don't want a trillion df in references for no reason. Headbomb {t · c · p · b} 00:19, 21 March 2019 (UTC)
 * Templates and modules cannot remove anything from wikitext so if there are 234 cs1|2 templates and all 234 template have df with or without assigned values, there is nothing that Module:Citation/CS1 can do to remove them. As written right now, auto-formatting shall yield to those cs1|2 templates that have df with properly assigned values.
 * —Trappist the monk (talk) 00:46, 21 March 2019 (UTC)
 * I don't mean that use dmy dates removes df from templates, that's clearly impossible, but it does remove the need for df in that article. Headbomb {t · c · p · b} 00:51, 21 March 2019 (UTC)
 * This proposal does that. The maintenance category I proposed above will identify cs1|2 templates on a page with  where df exists in conflict with.
 * —Trappist the monk (talk) 01:02, 21 March 2019 (UTC)
 * —Trappist the monk (talk) 01:02, 21 March 2019 (UTC)

I am unkeen on dmy/mdy with access/archive dates in ymd. While it is MOS permissible, until it is the only permitted solution then cs1 should not be forcing or preferring that solution and allow the use of dmy/mdy for all dates in a citation. I don't have an issue with keywords  and   to allow editors who prefer that format to utilise it as long as there is no change from the current default. Nthep (talk) 00:17, 21 March 2019 (UTC)
 * Where did you get the notion that the auto-formatting compels access-/archive-dates to be rendered in ymd format? That is patently false.  If editors write  at the top of an article then all cs1|2 dates in that article shall be rendered in dmy format unless locally overridden by df in the individual cs1|2 templates; if editors write  then, and only then, cs1|2 publication dates shall be rendered in dmy format and access-/archive-dates shall be rendered in ymd format; local df caveat applies.  The same is true for  and .  If access is  blank or holds some value other than   it is ignored.
 * —Trappist the monk (talk) 00:46, 21 March 2019 (UTC)
 * thank you for the reply, my concern was that someone would take the suggestion one step further and make access=ymd the default behaviour because that is their preferred scheme. If that is not the case then I am content. Nthep (talk) 10:12, 21 March 2019 (UTC)
 * I would not at all be surprised that editors will squabble over the use of access. Another possible issue is bots or date-formatting-scripts choking on  or blindly removing ymd because they don't know about that parameter.  I doubt that the bot and script authors are watching this page.  If any reading this know who those authors are, will you ping them into this conversation?  Because this conversation involves a minor undocumented use of the  templates, I'll mention this discussion on their talk pages.
 * —Trappist the monk (talk) 10:37, 21 March 2019 (UTC)
 * How are you proposing to handle the short month situation with this? Keith D (talk) 12:59, 21 March 2019 (UTC)
 * I haven't given that much thought. At present, the new algorithm uses month names as they exist before reformatting in the final rendering:
 * Where month names don't exist (ymd → dmy or mdy), whole month names are used:
 * My experience suggests that, for the most part, abbreviated month names in all citations is rare. Do you have evidence to the contrary?
 * Because the intent is consistency throughout all of the cs1|2 citations in an article, perhaps the current mechanism is lacking in that citations can be a mix of whole month names even within the same citation.
 * —Trappist the monk (talk) 14:24, 21 March 2019 (UTC)
 * I have no evidence that they are used extensively, just seen them while fixing the "cite date errors". Often find just one or two in an article. Personally I would not mind if the MOS was changed to drop this option from referencing and just retain it for tables. This would simplify things, with 2 less options, and gain more consistency. Keith D (talk) 16:30, 21 March 2019 (UTC)
 * If it is necessary to support abbreviated month names we create another parameter for the templates.  Perhaps, for lack of a better name for now, short that takes the single value  .  access might also accept the value   or some such.  Both of these would be decoded:
 * {| class="wikitable"
 * My experience suggests that, for the most part, abbreviated month names in all citations is rare. Do you have evidence to the contrary?
 * Because the intent is consistency throughout all of the cs1|2 citations in an article, perhaps the current mechanism is lacking in that citations can be a mix of whole month names even within the same citation.
 * —Trappist the monk (talk) 14:24, 21 March 2019 (UTC)
 * I have no evidence that they are used extensively, just seen them while fixing the "cite date errors". Often find just one or two in an article. Personally I would not mind if the MOS was changed to drop this option from referencing and just retain it for tables. This would simplify things, with 2 less options, and gain more consistency. Keith D (talk) 16:30, 21 March 2019 (UTC)
 * If it is necessary to support abbreviated month names we create another parameter for the templates.  Perhaps, for lack of a better name for now, short that takes the single value  .  access might also accept the value   or some such.  Both of these would be decoded:
 * {| class="wikitable"
 * {| class="wikitable"

!short !! access !! publication dates !! access-/archive-dates
 * +auto date formatting
 * style="text-align:center" | – || style="text-align:center" | – || long || long
 * style="text-align:center" | – ||  || long || abbreviated
 * style="text-align:center" | – ||  || long || ymd
 * || style="text-align:center" | – || abbreviated|| abbreviated
 * ||  || abbreviated|| abbreviated
 * ||  || abbreviated|| ymd
 * }
 * Alternately we might dream up a single parameter that accepts a defined set of keywords; perhaps cs1-dates with keywords, perhaps:
 * – all dates long (default when cs1-dates omitted or empty)
 * – all dates long (same as default; here for completeness) – struck because redundant
 * – long publication dates, abbreviated access-/archive-dates
 * – long publication dates, ymd access-/archive-dates
 * – all dates abbreviated
 * – all dates abbreviated (same as ; here for completeness) – struck because redundant
 * – abbreviated publication dates, ymd access-/archive-dates
 * – all dates ymd; caveats: date ranges, month and year dates, single dates before 1582 not reformatted
 * Of these two solutions, I rather prefer cs1-dates and defined keywords because it explicitly indicates to editors that date formatting options specified in applies to cs1|2 templates only.  Opinions?
 * —Trappist the monk (talk) 17:33, 21 March 2019 (UTC) 18:48, 21 March 2019 (UTC) 14:15, 23 March 2019 (UTC)
 * I think that I have noodled out the cs1-dates option described above. User:Trappist the monk/testcases uses sy and User:Trappist the monk/Barack Obama uses ly.  This version will also long/short reformat my, m–my, and my–my date forms.  Season and named-day dates are left alone because we don't have support for short forms of those dates.  Legitimate keyword values for cs1-dates are listed in the table above.  This, I think, makes this functionality fully compliant with MOS:DATEUNIFY.
 * —Trappist the monk (talk) 19:02, 22 March 2019 (UTC)
 * An unrelated yet related thought occurs to me. We might create a  template that uses some or all of Module:Citation/CS1/Date validation and part of Module:Citation/CS1/Configuration to auto format dates in article text.  This template,, would wrap MOS-approved dates and render them according to the article's  template ...  I put this here as a reminder for me to look into that as a possibility.
 * —Trappist the monk (talk) 17:33, 21 March 2019 (UTC)
 * – all dates ymd; caveats: date ranges, month and year dates, single dates before 1582 not reformatted
 * Of these two solutions, I rather prefer cs1-dates and defined keywords because it explicitly indicates to editors that date formatting options specified in applies to cs1|2 templates only.  Opinions?
 * —Trappist the monk (talk) 17:33, 21 March 2019 (UTC) 18:48, 21 March 2019 (UTC) 14:15, 23 March 2019 (UTC)
 * I think that I have noodled out the cs1-dates option described above. User:Trappist the monk/testcases uses sy and User:Trappist the monk/Barack Obama uses ly.  This version will also long/short reformat my, m–my, and my–my date forms.  Season and named-day dates are left alone because we don't have support for short forms of those dates.  Legitimate keyword values for cs1-dates are listed in the table above.  This, I think, makes this functionality fully compliant with MOS:DATEUNIFY.
 * —Trappist the monk (talk) 19:02, 22 March 2019 (UTC)
 * An unrelated yet related thought occurs to me. We might create a  template that uses some or all of Module:Citation/CS1/Date validation and part of Module:Citation/CS1/Configuration to auto format dates in article text.  This template,, would wrap MOS-approved dates and render them according to the article's  template ...  I put this here as a reminder for me to look into that as a possibility.
 * —Trappist the monk (talk) 17:33, 21 March 2019 (UTC)

Overall, I think this is a brilliant idea. If editors write in an article then all cs1|2 dates in that article should be rendered in dmy format, including archive and access dates. Hawkeye7  (discuss)  19:30, 21 March 2019 (UTC)

The template Use dmy dates and kin was originally created by Ohconfucius and is often used in conjunction with that user's date maintenance script. If the CS1 templates were changed without an effort to get buy-in from the maintenance script author and users, the users will be perplexed when the script ignores the new parameters (or goes belly-up altogether).

Another risk is that users will use the new parameter to label an article that does not use citation templates, and expect something to happen to the dates in the citations. Jc3s5h (talk) 19:23, 22 March 2019 (UTC)
 * You know, that's why I wrote (modified here to reflect current state of the code):
 * I would not at all be surprised that editors will squabble over the use of cs1-dates. Another possible issue is bots or date-formatting-scripts choking on  or blindly removing cs1-dates because they don't know about that parameter.  I doubt that the bot and script authors are watching this page.  If any reading this know who those authors are, will you ping them into this conversation?  Because this conversation involves a minor undocumented use of the  templates, I'll mention this discussion on their talk pages.
 * Thanks for adding a ping.
 * I chose the parameter name cs1-dates to avoid expectations that auto formatting would reformat dates in citations not using cs1|2 templates. Do you have a better name?
 * —Trappist the monk (talk) 19:45, 22 March 2019 (UTC)
 * No, I don't have a better name. Jc3s5h (talk) 20:25, 22 March 2019 (UTC)
 * cs-dates or cite/citation-dateswould be clearer, IMO, since those would cover CS2 as well. Headbomb {t · c · p · b} 20:39, 22 March 2019 (UTC)
 * Not so sure. Many error messages and category names use the initialism cs1. Help:CS1 errors help text, the module suite, all maintenance messages, use the initialism cs1.   documentation mentions cs1.  We don't use 'cs' when referring to cs1|2.  We might change the parameter name detection code to recognize cs1-dates, cs2-dates, cs12-dates, but I don't see much benefit in that.  There are citation templates that have nothing to do with cs1|2 so cite/citation-dates could be just as confusing / unclear.  For this scheme to work, the citation template must be one of the native cs1|2 templates or be a wrapper of a native cs1|2 template.
 * —Trappist the monk (talk) 11:30, 23 March 2019 (UTC)
 * —Trappist the monk (talk) 11:30, 23 March 2019 (UTC)

I support the auto formatting of reference dates in principle but I have the following concerns:
 * 1) yyyy-mm-dd are allowed in references even when dmy or mdy text formats are used in the article text. However, yyyy-mm is not allowed by the rules (against my desire but I follow the consensus).
 * 2) The script by Ohconfucius changes the reference date format away from yyyy-mm-dd, even though allowed by MOS. I spend an awful lot of time restoring reference dates.
 * 3) MOS is a bit fuzzy about whether published dates and accessed dates should be the same or different. Personally I can't see a reason why publish date and access date should be different formats but some articles have them the same and some articles have them different - both forms are allowed under MOS.
 * 4) If references without a |df= setting automatically follow the 'use XXX' template at the top of the article, then on the day that this feature is turned on the many articles using yyyy-mm-dd references will suddenly but silently change into the 'use XXX" format. Preferably a bot would search for articles with 'use XXX' in combination with yyyy-mm-dd references and add whatever param is needed to the 'use XXX' template.  Stepho  talk 12:01, 23 March 2019 (UTC)
 * This is definitely not a BOT job as in many cases only a single date or a handful of dates are in the yyyy-mm-dd format so how would a BOT work out with a mixture of date formats which to use? It should be up to agreement on individual articles to use this format. May be it is time to get rid of this option of having different date formats in the references and just have a single consistent date formatting throughout the article. Keith D (talk) 13:31, 23 March 2019 (UTC)
 * Answers to your concerns (I changed your post to use ordered-list markup for clarity):
 * I have tweaked the sandbox so that it accepts y in the templates.  When so set, all single dates will be reformatted into ymd format with the caveats that:
 * date ranges are not reformatted because MOS:DATES does not allow for YYYY-MM-DD/YYYY-MM-DD or other forms of numeric-only dates
 * Month YYYY dates are not reformatted because MOS:DATES does not support YYYY-MM numeric date formats
 * dates earlier than 1582 (Julian calendar) because, even though en.wiki does not support ISO 8601, ymd dates look sufficiently like ISO 8601 dates that editors here insisted that cs1|2 obey the ISO 8601 Gregorian-calendar-only stricture (yeah, even though en.wiki does not support ISO 8601)
 * if you have issues with Editor Ohconfucius and that editor's script, you must take up those issues with Editor Ohconfucius; I cannot speak for Editor Ohconfucius
 * I don't see this as a fuzzy issue. In citations, publication dates and access-/archive-dates are not required to have the same format though access and archive dates are required to use the same format if different from publication dates.  Auto date format supports this.
 * Yeah, that will happen for those articles that have or  (or redirects).  This search times out but it isn't hard to find yyyy-mm-dd but access-date in some other format (when I ran the search there were several in the first page of 20 results).  That inconsistency would, I think, make it difficult for a bot task to determine conclusively just what the page editors intend for citation date formatting.  Better, I think, that the formatting switches to a know state and that editors then adjust the articles to meet their intent.  Are there any projects that prefer ymd citation dates?  If there are, please ping them into this conversation.
 * —Trappist the monk (talk) 14:15, 23 March 2019 (UTC)
 * Date autoformatting never had any consensus, and was formally abandonned. I don't understand why this is being resurrected in another guise. I don't want to sound arrogant but I'm afraid I don't have time to look at any of the issues raised from the new parameters, or to engage in any substantive discussions on any related issue or otherwise. But as to the script, AFAIR, upon each pass, the script will strip out all parameters from the or  templates and replace it with current month. There is the user option built into the script to convert only body dates, meaning that dates in the reference sections are left in yyyymmdd format. I'd say that nobody deliberately goes around flipping dates from yyyymmdd. Whilst observing MOSNUM as regards yyyymmdd dates is desirable, ensuring overall date uniformity is equally important. Anyway, I hope that users are aware of WP:MOSNUM when they run the script. However, I think it's counterproductive and a waste of effort changing dates back to yyyymmdd format because of personal preference. There are better things to do with one's time on the project, YMMV. Regards, --  Ohc  ¡digame! 16:13, 24 March 2019 (UTC)
 * This is not the same date autoformatting as in the RFC, which was deprecated for reasons unrelated to this discussion. (Namely, split the parser cache, presented inconsistent dates to anonymous readers, and provided undesired linking.) This solution in citation templates only would not present any of those issues. --Izno (talk) 16:57, 24 March 2019 (UTC)
 * If I understand Manual of Style/Dates and numbers/Date autoformatting, that form of auto date formatting was abandoned because it did not work for everyone, and ran afoul of WP:OVERLINK. (Is that an oversimplification?) It was not abandoned because editors decided that date consistency was a bad thing.  Were that true then Editor Ohconfucius's script would not be allowed which is, after all, auto date formatting in a different form.
 * Indeed, it appears that User:Ohconfucius/script/MOSNUM_dates.js completely rewrites the template (see  ).  For myself, I am not interested in mucking-about in that script – I have little experience with js and have no real desire to gain that experience.  If there are editors reading this who would be interested in tweaking User:Ohconfucius/script/MOSNUM_dates.js, please do.  Failing that, I don't want to abandon this so: plan 2.
 * Earlier in this discussion I suggested a separate template to hold cs1|2 configuration data. We could create  that would take, for now, a single parameter df and requires the presence of either of the  templates.  Module:Citation/CS1/Configuration would first search for a  template from which it would get the article's base date format.  If  is present, the module will use it to refine the rendering of dates within the cs1|2 templates.  When neither of the  templates are present, the module will ignore  even if it is present (and perhaps add the article to a maintenance category).
 * Before I venture into implementing plan 2, any js script writers willing to tweak User:Ohconfucius/script/MOSNUM_dates.js? The tweaks would be (more-or-less):
 * when not present in any form, write a new   – functionality already exists
 * when present without date, add &lt;current Month YYYY date>
 * when present with date, replace the value assigned to date with
 * —Trappist the monk (talk) 17:51, 24 March 2019 (UTC)
 * Not very surprisingly, no .js coders leaped to the challenge of tweaking User:Ohconfucius/script/MOSNUM_dates.js. Yeah, not surprising because the tweaks listed above is completely bogus.  So I've had a go at hacking it.  The modified version of the script is at User:Trappist_the_monk/script/MOSNUM_dates.js.  There is a test page at  User:Trappist the monk/MOSNUM dates.js test.  On the test page are descriptions of what changed, instructions for installation and testing of the script.  Brave editors sought (it won't kill you and you can always revert if something goes amiss).  Pinging the original author whose opinion is desired.
 * —Trappist the monk (talk) 19:13, 27 March 2019 (UTC)
 * when present without date, add &lt;current Month YYYY date>
 * when present with date, replace the value assigned to date with
 * —Trappist the monk (talk) 17:51, 24 March 2019 (UTC)
 * Not very surprisingly, no .js coders leaped to the challenge of tweaking User:Ohconfucius/script/MOSNUM_dates.js. Yeah, not surprising because the tweaks listed above is completely bogus.  So I've had a go at hacking it.  The modified version of the script is at User:Trappist_the_monk/script/MOSNUM_dates.js.  There is a test page at  User:Trappist the monk/MOSNUM dates.js test.  On the test page are descriptions of what changed, instructions for installation and testing of the script.  Brave editors sought (it won't kill you and you can always revert if something goes amiss).  Pinging the original author whose opinion is desired.
 * —Trappist the monk (talk) 19:13, 27 March 2019 (UTC)

Auto date formatting part 2
The thread was just too long to work with, so putting in arbitrary break.

I altered my common.js page, commenting out the line that loaded Ohconfucius's script and putting in a line to load Trappist's. In Firefox I did cntl-shift-R to reload the page, and I closed and reopened the browser for good measure. Then I added the following as the first line of my sandbox:

I saved and closed, then edited again with the source editor. I clicked on the line in the menu to the left "ALL dates to mdy". The first line changed to

So it doesn't seem to be working. Jc3s5h (talk) 19:48, 27 March 2019 (UTC)
 * Yeah, doesn't work because  doesn't exist.  Copy/pasta failure on my part.  Should be:
 * —Trappist the monk (talk) 21:12, 27 March 2019 (UTC)
 * Maybe a little off topic but if we auto format dates maybe we could also auto format CS1 vs CS2? That way we wouldn't have to worry when editors mix up the cite and citation templates. —David Eppstein (talk) 20:01, 27 March 2019 (UTC)
 * I suggested that we might create a template at .  The response was underwhelming.  But, now is the time to make these kinds of decisions before we wander so far down the path that it becomes difficult to backtrack and make our way along another. And yeah, typing error there too, though that one's been fixed.
 * —Trappist the monk (talk) 21:12, 27 March 2019 (UTC)
 * Still not working, even when I use a different broweser (Edge). Jc3s5h (talk) 21:34, 27 March 2019 (UTC)
 * Argh! Instructions above fixed, I think.  At  you apparently noodled out the correct file name (I copied that to my own common.js).  That version didn't work?  How did it not work?  When I edit your sandbox I see that you have  .  After I click 'All dates to dmy' I see   and coincidentally, all mdy dates changed to dmy dates, all as I would expect.
 * —Trappist the monk (talk) 22:27, 27 March 2019 (UTC)
 * It turns out I had another script that was loading Ohconfucius's script. Once I got rid of that it worked. Jc3s5h (talk) 23:13, 27 March 2019 (UTC)
 * It turns out I had another script that was loading Ohconfucius's script. Once I got rid of that it worked. Jc3s5h (talk) 23:13, 27 March 2019 (UTC)

Julian and Gregorian dates
We have a maintenance category Category:CS1: Julian–Gregorian uncertainty, which is fine and good, but no (documented) way of marking such items as resolved to one or the other.

Nor, while we are about it, have we addressed the more salient issue of the change of the year to run from January to December.

It would be fairly simple for editors, for example, to ensure [when] dates are either proleptic Greogorian or Gregorian, and for editors [to] tag them with.

Alternatively we could add  to supress the category, [whether this is displayed or emitted is another matter].

All the best: Rich Farmbrough, 17:17, 26 March 2019 (UTC).


 * From my experience here and on Wikidata, it is well beyond the ability of most editors to determine if a date is Julian, proleptic Julian, Gregorian, or proleptic Gregorian. In the case of various principalities and duchies in Europe, if you can get it right consistently, we should figure out a way to grant the editor a PhD in history. In any case, the date in the citation should be the date that appears in the publication, so that when the reader obtains the publication to verify the claim in the article, it will be obvious to the reader that the reader has the right publication.
 * Of course, since publication templates don't support Julian, all dates that are accurate to the day that are present in citation templates are either Gregorian or false. The way to tell that a date might be Julian is to notice that the citation doesn't use a template. Jc3s5h (talk) 17:34, 26 March 2019 (UTC)
 * They are not "false".  However I agree that the bibliographic date should be displayed.  To this end I have modified my suggestion above. All the best: Rich Farmbrough, 17:44, 26 March 2019 (UTC).


 * (edit conflict) They are false because metadata is emitted, no provision is made to convert Julian dates to (proleptic) Gregorian in the metadata, the metadata format requires the dates to be Gregorian, and the metadata format is specified by an outside organization, so we can't change the format specification. Jc3s5h (talk) 17:53, 26 March 2019 (UTC)
 * The cs1|2 templates do support Julian calendar dates in the sense that they don't fall over dead because the leap-year calculations for Julian and Gregorian are different. cs1|2 never has (and I hope never does) support date manipulation / conversion.  You are right, cs1|2 should report the date as written in the source regardless of Julian or Gregorian calendar.  The category in question is about what to do with those dates that fall into the morass that is the overlap period between Julian and Gregorian full adoption in the COinS metadata.
 * —Trappist the monk (talk) 17:51, 26 March 2019 (UTC)
 * was created in response to this rfc. See also this discussion.  We await input from those concerned editors for whom this category was created and, I presume, are reviewing the category so that they may make recommendations to us about what we should be doing with those dates that land between the first and last dates of Gregorian calendar implementation.  At this writing, those concerned editors have been thus far mute.
 * —Trappist the monk (talk) 17:51, 26 March 2019 (UTC)
 * If COINS expect dates to be in a certain calendar, then let's just not emit them before a certain period. Otherwise, no one cares if 7 January 1042 of a certain calender doesn't correspond to the 7 January of a backwards extrapolation of the modern calendar. Headbomb {t · c · p · b} 18:03, 26 March 2019 (UTC)
 * This:
 * generates this metadata:
 * In particular, note the  key/value pair.  cs1|2 has done this for a long, long time.  The issue is not Julian dates from before the first implementation of the Gregorian calendar but the dates between Gregorian calendar date-of-first-use and Julian calendar date-of-last-use and only those dates that are whole dates; roughly 1582–1923.
 * —Trappist the monk (talk) 19:30, 26 March 2019 (UTC)
 * I agree with Headbomb. The authors of COINS, by writing their standard the way they did, have declared to the world they don't care about historical dates; they only care about dates on current appointment calendars and that sort of thing. Since they don't care about our dates, we shouldn't give them our dates. For those who adopted COINS without knowing what it really was, they can go to a bar near a horse racing track and commiserate with all the others who bet on the wrong horse. Jc3s5h (talk) 20:35, 27 March 2019 (UTC)
 * In particular, note the  key/value pair.  cs1|2 has done this for a long, long time.  The issue is not Julian dates from before the first implementation of the Gregorian calendar but the dates between Gregorian calendar date-of-first-use and Julian calendar date-of-last-use and only those dates that are whole dates; roughly 1582–1923.
 * —Trappist the monk (talk) 19:30, 26 March 2019 (UTC)
 * I agree with Headbomb. The authors of COINS, by writing their standard the way they did, have declared to the world they don't care about historical dates; they only care about dates on current appointment calendars and that sort of thing. Since they don't care about our dates, we shouldn't give them our dates. For those who adopted COINS without knowing what it really was, they can go to a bar near a horse racing track and commiserate with all the others who bet on the wrong horse. Jc3s5h (talk) 20:35, 27 March 2019 (UTC)


 * I also agree. For ranges where the COinS date is invalid, ambiguous, or even just undefined, we should not emit a COinS date. Even further: if the resulting record thereby has no date, then skip the COinS record entirely. &diams; J. Johnson (JJ) (talk) 20:37, 29 March 2019 (UTC)

WP:SOURCEWATCH Launch
This is not directly related to work on the CS1 templates, but since a lot of people who watch this place presumably have an interest in accurate citations, this Signpost article that was published yesterday might be of interest to you. This has been the results of nearly 9 months of efforts. Feel free to share the article (and the WP:SOURCEWATCH link) to relevant people and communities you may know! Headbomb {t · c · p · b} 16:13, 1 April 2019 (UTC)

|others=
I am slowly running an awb script that works on stuff like this (all of these are from Chromate):


 * All of these were made in March of this year by that abomination that is ve. Besides the fact that all of these have a redundant worldcat url, here's what's wrong:
 * in last: a date range, presumably author's birth and death dates; in first: author's whole name, parenthetical expanded initial, and extraneous punctuation; in others: multiple names all separated by commas only, a date range, and extraneous punctuation, no indication of who these people are; in edition: extraneous 'ed.' text
 * in last: part of the publisher's name, extraneous punctuation; in first: the other part of the publisher's name
 * in last: author's middle initial; in first: surname and first initial
 * in others: surname, initials, parenthetical expanded initials, a (birth?) date, name, name, and extraneous punctuation
 * Yeah, I know, human names are hard. But if ve can't create correct parameter data, it should not just toss stuff into convenient parameters and call it good.  Were I running a bot that produced this kind of crap, I'd have been blocked and my birthday taken away.  Just say no to ve.

It's item 4, hence the section heading, that prompted this post. others implies, well, others: authors, editors, translators, interviewers. If others is used without any of these 'others' ought we remark on that either as an error message or at least a maintenance category? Nothing in others makes it into the metadata so for cases like #4. It would appear that Prasad and Shih are the editors of that work so clearly, for this case, an error message or maintenance category is appropriate.

—Trappist the monk (talk) 23:32, 31 March 2019 (UTC)


 * The cite book documentation says
 * others: To record other contributors to the work, including illustrators. For the parameter value, write Illustrated by John Smith.
 * So the documentation corresponds with common sense: the others parameter must both name the contributor and describe the contributor's role. This makes it a rather free-form parameter, which makes it difficult to use automation, whether to make corrections, to issue error messages, or to assign maintenece categories. Jc3s5h (talk) 23:56, 31 March 2019 (UTC)
 * I am not suggesting that we attempt to automate some sort of interpretation of the value assigned to others. I am suggesting that cs1|2 templates with &lt;any text> but without values assigned to any of the author, editor, contributor parameters should be noted and cause cs1|2 to emit an error or maintenance message.  Perhaps we should do the latter just to see what is out there.
 * In the quoted documentation, I read 'other' in the first clause to mean subsidiary or additional contributors which view is, I think, somewhat supported by the illustrators example and by the positioning of the others text in the rendered citation (after the title):
 * Perhaps we should consider just what we mean for others to be and revise the documentation and supporting code accordingly.
 * —Trappist the monk (talk) 11:01, 1 April 2019 (UTC)
 * There's a bug or two on Phabricator about some of the above. More-or-less, it's because the metadata that OCLC dumps for use is garbage (even though their "cite this" button on a work's page outputs everything just fine) and Citoid (not VE) tries its hardest to put things in the right places. It annoys me to no end also. I think phab:T160845 is the one?
 * As for the redundant URL, that's apparently a design decision driven by different wikis having different parameters--URL is basically guaranteed to be present on a non-English wiki, while oclc is not. --Izno (talk) 01:40, 1 April 2019 (UTC)
 * Yeah, that's probably the one. If the metadata are known to be crap then the metadata should not be used.  How hard is that to figure out?  Better for ve/citoid to do nothing than to produce crap that editors have to cleanup.
 * I haven't noticed, but is there similar ve/citoid url/identifier duplication for other identifiers? Should cs1|2 notice and flag instances of url/identifier duplication?  I know that citation bot does some fixing of this sort of thing.  Is that sufficient?
 * —Trappist the monk (talk) 11:01, 1 April 2019 (UTC)
 * Well, OCLC duplication inevitably ends up in one of the other maintenance categories. Yes, I think there's one or two others but I'm not sure which (PMID or PMC or both I think). I would support at least a maintenance message for OCLC here where the URL duplicates the OCLC value. Anchors/query parameters are a consideration for a general solution beyond OCLC? For example, Google Books is a duplicate of an ISBN given unless it has x or y parameters. Just some things to consider. --Izno (talk) 15:49, 1 April 2019 (UTC)
 * Well, OCLC duplication inevitably ends up in one of the other maintenance categories. Really?  Are you sure?  Shouldn't we see indications of that in the examples ahead of my rant at the top of this topic?
 * The tracking query components of the worldcat urls that I paid attention to are apparently ignored; these two go the same place:
 * http://www.worldcat.org/title/pre-columbian-mexican-miniatures-the-josef-and-anni-albers-collection/oclc/253845585&referer=brief_results
 * http://www.worldcat.org/title/pre-columbian-mexican-miniatures-the-josef-and-anni-albers-collection/oclc/253845585
 * and this one goes to an interception page:
 * http://worldcat.org/wcpa/oclc/51155119?page=frame&url=http%3A%2F%2Fhdl.loc.gov%2Floc.pnp%2Fcph.3c03824&title=&linktype=digitalObject&detail=
 * As I work my way along, I'll look for other examples.
 * —Trappist the monk (talk) 16:15, 1 April 2019 (UTC)
 * An unfortunate (bad?) joke; OCLC is one of the main contributors to Category:CS1 maint: Extra text (7th ed). --Izno (talk) 16:27, 1 April 2019 (UTC)
 * I have hacked the sandbox so that cs1|2 applies a maintenance category when &lt;any text> exists (has a value) and both of author and editor are missing or empty:
 * Because contributor requires author I have struck that; it is not used in the test for the maint category.
 * —Trappist the monk (talk) 14:07, 1 April 2019 (UTC)
 * —Trappist the monk (talk) 16:15, 1 April 2019 (UTC)
 * An unfortunate (bad?) joke; OCLC is one of the main contributors to Category:CS1 maint: Extra text (7th ed). --Izno (talk) 16:27, 1 April 2019 (UTC)
 * I have hacked the sandbox so that cs1|2 applies a maintenance category when &lt;any text> exists (has a value) and both of author and editor are missing or empty:
 * Because contributor requires author I have struck that; it is not used in the test for the maint category.
 * —Trappist the monk (talk) 14:07, 1 April 2019 (UTC)
 * Because contributor requires author I have struck that; it is not used in the test for the maint category.
 * —Trappist the monk (talk) 14:07, 1 April 2019 (UTC)

Questions/Comments about Template: Cite conference.
1. Presentation title displays italicized. The documentation says different:

3.4.2 Title 2. Book title is not described. I would expect this to be italicized. Seems like a good method to differentiate title from book-title.
 * title: Title of source. ... Displays in quotes.

I would like the template changed and the documentation updated. ---User-duck (talk) 23:07, 4 April 2019 (UTC)
 * Answers to your itemized list:
 * 1. Yeah, title is italicized when book-title is not present; cf:
 * Why? Because without book-title, cs1 assumes that title is the title of the proceedings that the editor is citing as a whole.  is similar to, , etc.  For those templates, title is the article in the journal or in the newspaper so for , when book-title has a value (the title of the proceedings) then cs1 assumes that title is the conference paper and renders both accordingly.
 * 2. WP:SOFIXIT. If you can see a way to improve the documentation, please do.  If you encounter difficulties, ask for assistance.
 * We have had conversations before about ; here are two, perhaps there are others:
 * {Template:Cite conference}: Why italic title for paper presented at a conference?
 * cite conference title= parameter is incorrectly formatted
 * No one here has ever claimed that the templates are perfect. If you have specific recommendations on how the templates can be improved, please provide those recommendations in detail so that we can assess them and a consensus can be formed.
 * —Trappist the monk (talk) 00:01, 5 April 2019 (UTC)
 * Thanks for the explanation!
 * I continued the similarity a little farther, title is the item (article/presentation/chapter/entry) in the conference or the book-title.
 * Isn't conference used for the "title of the proceedings"? I have wondered why it isn't italicized. I figured italics were reserved for book-title.
 * 3.4.4 Conference
 * conference: Name of the conference, …
 * Examples: or  or  or
 * I find this behavior confusing.
 * I have not seen the formatting of title change depending on other parameters for any of the other citation templates, except, of course, :
 * italicized for.
 * quoted for, independent of work / website.
 * quoted for, independent of work / newspaper.
 * quoted for, independent of journal.
 * quoted for, independent of magazine.
 * --User-duck (talk) 01:59, 5 April 2019 (UTC)
 * conference is the name of the conference which may be distinctly different from the name of the proceedings. It is a free-form parameter that may also hold the conference location and conference dates because these may be (likely are) different from the publication place (location) and publication date date
 * book-title is a pseudo-alias of title because in, when book-title is set, title is not required (as it is in most all other cs1 templates):
 * Yes, it is acknowledged that is different from most cs1 templates.  So is  which is similarly different:
 * —Trappist the monk (talk) 13:26, 5 April 2019 (UTC)
 * quoted for, independent of journal.
 * quoted for, independent of magazine.
 * --User-duck (talk) 01:59, 5 April 2019 (UTC)
 * conference is the name of the conference which may be distinctly different from the name of the proceedings. It is a free-form parameter that may also hold the conference location and conference dates because these may be (likely are) different from the publication place (location) and publication date date
 * book-title is a pseudo-alias of title because in, when book-title is set, title is not required (as it is in most all other cs1 templates):
 * Yes, it is acknowledged that is different from most cs1 templates.  So is  which is similarly different:
 * —Trappist the monk (talk) 13:26, 5 April 2019 (UTC)
 * Yes, it is acknowledged that is different from most cs1 templates.  So is  which is similarly different:
 * —Trappist the monk (talk) 13:26, 5 April 2019 (UTC)
 * Yes, it is acknowledged that is different from most cs1 templates.  So is  which is similarly different:
 * —Trappist the monk (talk) 13:26, 5 April 2019 (UTC)
 * —Trappist the monk (talk) 13:26, 5 April 2019 (UTC)
 * —Trappist the monk (talk) 13:26, 5 April 2019 (UTC)
 * —Trappist the monk (talk) 13:26, 5 April 2019 (UTC)
 * —Trappist the monk (talk) 13:26, 5 April 2019 (UTC)
 * —Trappist the monk (talk) 13:26, 5 April 2019 (UTC)
 * —Trappist the monk (talk) 13:26, 5 April 2019 (UTC)
 * —Trappist the monk (talk) 13:26, 5 April 2019 (UTC)

Suppression of periods at end of title, redux
I'm aware of previous discussion. See Joan Crockford Beattie (reference #1) for an example where the introduced exception still fails to catch a valid case. Argh!

To be entirely frank, I don't really understand why these periods have to be suppressed in the first place. I just think it's a bad idea. --Florian Blaschke (talk) 08:59, 6 April 2019 (UTC)
 * It is the duty and responsibility of the cs1|2 templates to handle element punctuation in a rendered citation. The templates do that well for the vast majority of citations.  But not every time.  Until you or someone else engineers the perfect algorithm to handle all cases of titles that are permitted to 'self-punctuate', we are left with what we have.
 * While we wait for that, there is the work-around described in that previous discussion:
 * —Trappist the monk (talk) 10:58, 6 April 2019 (UTC)
 * Thanks, I used the work-around to fix the snag. --Florian Blaschke (talk) 18:42, 6 April 2019 (UTC)
 * —Trappist the monk (talk) 10:58, 6 April 2019 (UTC)
 * Thanks, I used the work-around to fix the snag. --Florian Blaschke (talk) 18:42, 6 April 2019 (UTC)
 * Thanks, I used the work-around to fix the snag. --Florian Blaschke (talk) 18:42, 6 April 2019 (UTC)

Date indicated in journal versus actual publication / availability date
If a journal is notionally dated as being for the year 2011 but comes out in print only in 2012 - what parameters does one fill into the citation template so that it appears as _author_ (2011) [2012] xxxx. I ask this since it is important for the publication of taxonomical descriptions where the valid publishing date is the date on which the the publication became available. For the specific case I have at hand see Diplomesodon sonnerati - I tried putting in the cite journal template parameters as {{ cite journal|author=Cheke, A.[S.] |year=2012 |origyear=2011 - based on the template description and what I get is Cheke, A.[S.] (2012) [2011] - Am I misunderstanding the documentation given? I suppose the usual convention is to use square brackets for editorial comments such as in "[sic]" while the other is the verbatim date. Shyamal (talk) 15:33, 4 April 2019 (UTC)
 * This article?
 * If so then the source date is listed at the top of each page:
 * Journal of the Bombay Natural History Society, 108(2), May-Aug 2011
 * so:
 * {{para|date|May–Aug 2011}}
 * no need for {{para|orig-year}}
 * cs1|2 does not perform the function of a taxonomic description; cs1|2 identifies the WP:SAYWHEREYOUGOTIT for some statement in an en.wiki article. If there are templates specifically for taxonomic descriptions, I do not know what those templates are but, no doubt, there are editors who do.  Consider asking at the relevant projects.
 * —Trappist the monk (talk) 15:52, 4 April 2019 (UTC)
 * The finalized version is the version of record, and should normally be the one to be cited. Headbomb {t · c · p · b} 15:55, 4 April 2019 (UTC)
 * Thanks, ok, so this needs to be indicated outside. I was hoping that the flipped form could be achieved (2011) [2012] while also being semantically correct. I sometimes have a similar situation when journals use initials for the author and I add the full name as an editorial comment within the author field itself. That does not fortunately lead to any validation errors. Shyamal (talk) 16:13, 4 April 2019 (UTC)
 * When a journal uses an author's initials, that is what you should use in {{para|author}} or {{para|first}} unless you are using {{para|vauthors}} in which case author given names are to be reduced to one or two initials.
 * —Trappist the monk (talk) 16:22, 4 April 2019 (UTC)
 * To clarify that case - obituaries in journals are sometimes anonymous or with initials like "A.B." but sometimes you know who the author is even though the original publication does not indicate their identity - so for instance one could write author="Anon" [Real Name] or author="A.B." [Alpha Beta]. Similarly an article could be without a title or needs to be translated into a different language and one can give it a description - title=[Description of blah blah] - the square brackets indicating that it is an editorial comment and not actual title. Shyamal (talk) 16:35, 4 April 2019 (UTC)
 * If you are translating the title from another language, you should use {{para|title}} for the original title and {{para|trans-title}} for the translation. —David Eppstein (talk) 17:46, 4 April 2019 (UTC)
 * Dates in a citation are intended to help a reader find the source, verify for the reader that the copy the reader found is the correct material, and give the reader a general idea of when the material was published. Usually a difference in a few months between the nominal publication date and the actual availability to the reading public is not important and need not be mentioned. But it would be important if the publication dealt with events that were rapidly unfolding around the time the material was published. Jc3s5h (talk) 17:25, 4 April 2019 (UTC)
 * The actual date of publication is what’s used for things like Author citation (zoology) and it’s common to include both when discussing taxonomy. {{ping|Shyamal}} in my experience on Wikipedia the date in parentheses should be the date used to find the source but the date in brackets should be the date used for author citations. I really do think this should be made explicit in MOS:ORGANISM though. Umimmak (talk) 18:32, 4 April 2019 (UTC)
 * See also above. This should be supported. Headbomb {t · c · p · b} 18:57, 4 April 2019 (UTC)
 * They're not really quite the same thing though. Like something might be published in Volume 15, and the year associated with the {{em|volume}}'s publication was 1850 -- that would be the date you'd use to find the particular volume -- but maybe issue 1 of volume 15 came out in late 1849 and that would be the date of publication. Electronic preprints notably {{em|do not}} count for the publication date when it comes for author citation, so the two should not be conflated. Umimmak (talk) 19:10, 4 April 2019 (UTC)
 * See also above. This should be supported. Headbomb {t · c · p · b} 18:57, 4 April 2019 (UTC)
 * They're not really quite the same thing though. Like something might be published in Volume 15, and the year associated with the {{em|volume}}'s publication was 1850 -- that would be the date you'd use to find the particular volume -- but maybe issue 1 of volume 15 came out in late 1849 and that would be the date of publication. Electronic preprints notably {{em|do not}} count for the publication date when it comes for author citation, so the two should not be conflated. Umimmak (talk) 19:10, 4 April 2019 (UTC)

{{od|9}}I believe a certain degree of competence in using a library is the responsibility of the reader. If the reader observes that the issues of a journal have been bound together in a volume, and the spine of the volumes bear a year, the reader should be able to figure out that an article published in April 1908 might be in the volume labeled 1907, 1908, or 1909. The date in a Wikipedia citation should be the date of the article, not the volume (if indeed the volume even has a stated date). Jc3s5h (talk) 19:37, 4 April 2019 (UTC)
 * Author (date of publication) A new species Journal name [volume and issue with dates]
 * Surname, Jane. (1842) 'A new species of brown bird'. Transactions of the Little brown Bird society 1841: 476–478. *publication date noted by Macintosh, M., {1892) 'Publication dates of the transactions and proceedings of the Little Brown Bird society.' Transactions of the Little brown Bird society 1893: 1–742.

The key points in example is that the date of availability to formal publication is more important than the date on the title page, but that latter date may be the 'volume or issue's label. cygnis insignis 20:37, 4 April 2019 (UTC)
 * cs1|2 is not Author citation (zoology). Never has been.  The purpose of cs1|2 is to identify the source that an en.wiki editor consulted to support some statement in an en.wiki article so that an en.wiki reader may locate a copy to that source.  The date that is important to cs1|2 is the date that is printed in or on the source, not some date of 'availability' preceding that date.
 * —Trappist the monk (talk) 21:29, 4 April 2019 (UTC)
 * My statement was very poorly phrased, and doubtless someone has already put this in a clearer way. I certainly agree that the date on the title page would be crucial to the citation, barring some other overwhelming consideration. I also agree it is not an author citation per se, but this has a bearing on the selection of the publication date (which is crucial, because of rules of priority) and any other date that may be a series/volume/issue/number 'label'. The actual date of issue is the date used in the citation, and this is the subject of later research for the date used in the citation; this is an overriding consideration and assists in searches for the correct text. An oversimplification I'm sure. This is how I make use of the citation template and don't think it is subverting the intent to submit to my source's usage of dates, but correct me if I'm wrong. cygnis insignis 00:58, 5 April 2019 (UTC)
 * Rules of priority (whatever those might be) do not apply to cs1|2 citations because cs1|2 does not have any 'rules of priority'. I got lost here: {{tq|The actual date of issue is the date used in the citation, and this is the subject of later research for the date used in the citation;}}  What?  That seems almost circular.  Is the first {{tq|citation}} the same as or different from the second {{tq|citation}}?
 * The only date that cs1|2 cares about is the date that is printed in or on the source. Yeah, I know, I'm repeating myself, but it doesn't seem that that message is getting across.  If there is need for an Author citation (zoology) template then one should be created to serve that purpose.  Do not misapply cs1|2.
 * —Trappist the monk (talk) 12:58, 5 April 2019 (UTC)
 * —Trappist the monk (talk) 12:58, 5 April 2019 (UTC)

For Wikipedia articles that mention taxonomy I use the title page year in the template but include some text within the reference stating when the publication first appeared. There are many circumstances where the publication date for the purposes of taxonomic priority differs from that on the title page. A common example is where the proceedings of a learned society put the year of the society meeting on the title page but the publication is actually published in the following year. - Aa77zz (talk) 10:44, 7 April 2019 (UTC)
 * cs1|2 is not in the business of establishing taxonomic priority. Must I keep saying that?  You-all know that we do have {{para|publication-date}}, right?
 * {{cite journal |last=Last |first=First |title=Title |journal=Journal |volume=12 |issue=1 |publication-date=December 1954 |date=January 1955}}
 * —Trappist the monk (talk) 11:08, 7 April 2019 (UTC)
 * Many thanks for your reply - as you correctly guessed I hadn't realised that publication-date= wasn't a synonym for date= - I'll use publication-date= in future. - Aa77zz (talk) 11:36, 7 April 2019 (UTC)
 * Many thanks for your reply - as you correctly guessed I hadn't realised that publication-date= wasn't a synonym for date= - I'll use publication-date= in future. - Aa77zz (talk) 11:36, 7 April 2019 (UTC)

Published online parameter?
Increasingly journal articles are published online many months before they are published in the print version of the journal, which is often the following year. As a result many articles have references added with cite journal using date for the date of online publication. For example, this article was published online in October 2017 and appeared in print in 2018. The print edition gives published online as part of the citation. Using the year to state the actual date issue 1 of volume 12 was published ignore the date of original publication, while leaving date leaves a mismatch with the journal citation. A published-online would allow all the information to be provided. An alternative is to use published online 10 October 2017 but I'm not sure this is an appropriate use of this parameter.  Jts1882 &#124; talk 14:39, 16 March 2019 (UTC)
 * orig-year is meant to be used for this sort of thing, if the difference in time is meaningful. The parameter is free-form, allowing for such clarification. I would highly recommend restraining yourself to just one date in the general case if there is no difference between the online and paper publications. --Izno (talk) 16:22, 16 March 2019 (UTC)


 * Really, we should have orig-date Headbomb {t · c · p · b} 23:38, 20 March 2019 (UTC)
 * Yes, this would be a welcome addition. I too proposed an orig-date parameter several times already. Whenever I have to use orig-year to specify a date rather than only a year I feel as if I have to abuse a parameter to make the template do what it should do.
 * --Matthiaspaul (talk) 19:32, 25 March 2019 (UTC)
 * I saw this same matter come up a few months ago in (as I recall) Nature.$$ Part of the reason for having both dates (online and print) is that prior to the print publication an article might be referred to by its online date.  (And I have an instance of this, an article that was published online in 2018, but has not yet appeared in print. So if I cite it now: do I need to change the date when it comes out in print?) At any rate, it looks like some of the journals are starting to consider the problem, and I think we should monitor that.
 * As to using "orig-date/year": the print date has always been (and still is) considered the date-of-record, and calling the "pre-print" date "original" tends to confuse matters. I am thinking we should have a "online-date" parameter, which can be treated like orig-date, and indeed, could be a synonym [see below] . The point of having a different name is to avoid using (or telling people to use) "orig-date" for a date that is generally considered not original. &diams; J. Johnson (JJ) (talk) 20:37, 25 March 2019 (UTC)
 * $$ Keller and Prusiner, "Cite the online date of publication", Nature, 28 June 2018, p.519. &diams; J. Johnson (JJ) (talk)
 * Were we to proceed with this, it seems to me that a date-holding parameter for the online publication date must be a real date-holding parameter subject to all of the constraints of other date-holding parameters; not free-form so not an alias of orig-year. Can we presume that a journal article published online is the same as the printed article-of-record?  If online is subject to change (like preprints in the arXiv suppository) then WP:SAYWHEREYOUGOTIT applies so we should treat such citations in the same manner as our other preprint templates.  What to do with the online date when date has a value – is there any need to render both simultaneously?  Special annotation for this online date to identify it as an online rather than article-of-record date?  Applies only to  or  when journal is set?  No doubt there is other minutia to worry about.
 * —Trappist the monk (talk) 11:37, 26 March 2019 (UTC)
 * I can't speak for Jts and I am not against the introduction of a specific online-date parameter with full range checking, but I only asked for orig-date as a simple alias for orig-year, just so that people can finally use a sensibly named parameter when they specify a date rather than only a year. I really can't see a problem with this.
 * The orig-year parameter is used for many purposes beyond just online magazines, as would be a orig-date parameter. One of them is in conjunction with a prior publication in limited circulation or even restriced access form such as inside of organizations such as companies, governments, or the military, when the same publication will become accessible to the general public (typically much) later on - in this case, an internal publication in print may even preceed a later online publication. The parameter is also used in conjunction with reproductions/reprints of historic sources. I have also seen it applied to indicate the original publication date of the first edition of a work, when later editions where only slightly modified, or to indicate a filing date or the last edit date of sources, if it differs from a publication date. So, if that includes more than a simple year, putting this under online-date would be just as wrong as under orig-year. That's why I think orig-date (as a free-flow parameter) would be more flexible. --Matthiaspaul (talk) 17:08, 28 March 2019 (UTC)

I am going to strike my suggestion that 'online-date' could a synonym of 'orig-year'. Regardless of whether 'orig-year' was "meant to be used for this sort of thing" (as Izno says) or not, I now think that (at least for journals) that is not appropriate: the on-line version and print version should (at least initially) be identical, and therefore equally "original". (After publication the on-line version may be revised to correct any errors, which would involve a revision date, but the original publication date remains unchanged.)

So I think 'orig-year/date' isn't really applicable to journals. In that sense having 'orig-date', likely as a synonym (both being free-form?), seems good. But that is a different discussion than this one.

Re an on-line publication date: I think it should be a "real date". After checking it could be handled like orig-year: shown in square brackets. We should show both dates, because other sources might refer to it by the initial on-line publication date. (I had a case like that once: a source referred to "Smith 2000", which I simply could not find. Turned out that the print publication was like "Smith 2002".) I don't know that the 'online-date' needs to be labeled as such. (Do we label 'orig-year'?) If the print publication date is not yet known then the brackets show that the date provided is preliminary. As to post-publication on-line dates: of course. Revisions are sometimes made, and the on-line date can indicate that, but the date-of-record remains the same.

But none of this applies to a pre-print server. An item there might turn out to be identical with the "published" item, but that's not guaranteed. If such a source is used it should be identified as "draft" or "pre-press", or some such.

Matthiaspaul raises the matter of re-publication. There is a fine question here of just what constitutes "publication". Ordinarily this is when something first becomes available "publicly", and not to subsequent reprinting or copying, even copying on-line. (E.g.: copying an article to ResearchGate.net is not considered publication.) But note that non-public documents, secret memos, etc., are usually dated by when they were created or issued. To cite a memo from General Smith that was secret until published in The Pentagon Papers, a typical citation would be "Smith, 1966, In: The Pentagon Papers, 1972 ...". But these considerations could go well beyond the present topic. &diams; J. Johnson (JJ) (talk) 20:27, 29 March 2019 (UTC)

Are we going anywhere with this? The matter of on-line publication dating seems to be a developing issue which we might want to stay ahead of. &diams; J. Johnson (JJ) (talk) 21:08, 16 April 2019 (UTC)

Template-protected edit request on 17 April 2019
There's a typo at the page Template:Cite AV media. In the TemplateData table, in the row for "In-source location", there's a "source" that is misspelled as "soruce". Thank you. Shuipzv3 (talk) 11:57, 17 April 2019 (UTC)
 * ✅ - Actually the typo was on the subpage Template:Cite AV media/doc, which isn't protected. -- John of Reading (talk) 12:14, 17 April 2019 (UTC)

Languages that do not use a Latin-based alphabet
For those citations which languages that don't use a Latin-based alphabet, is the romanized transliteration required for the title? —Wei4Green &#124; 唯绿远大 (talk) 14:48, 22 April 2019 (UTC)
 * It is useful to have the original non-Latin title in script-title, the romanization in title and a translation in trans-title. Kanguole 15:00, 22 April 2019 (UTC)
 * So it would look like this? —Wei4Green &#124; 唯绿远大 (talk) 15:12, 22 April 2019 (UTC)


 * As you can see from your above, yep, that's how it looks. Is there something wrong with that rendering or are you simply using this page as a sandbox?
 * —Trappist the monk (talk) 15:27, 22 April 2019 (UTC)
 * I was wondering if it looks good like that with every citation needed to be romanized. Look at Beijing Daxing International Airport, would it look readable with all of the Chinese article titles transliterated? —Wei4Green &#124; 唯绿远大 (talk) 15:36, 22 April 2019 (UTC)
 * Deciding whether or not it looks good like that ... is a subjective, personal opinion, is it not? Were it me, because I cannot read either the original or the transliteration (I am not alone in that disability), neither really help me to decide if I believe that the source is interesting enough to pursue.  So, for me and for other readers like me, English-language sources are best.  English-language sources not being available, then the original source title in either script-title or title is a must.  There is no requirement for both but if both are provided, then readers should be able to locate the source by either original title or by the transliterated title.  If the transliteration is your own and not provided by the source as an 'official' transliteration, then it is little use to readers, right?  For example, if I paste this:
 * "Xí Jìnpíng jiù Sīlǐlánkǎ fāshēng xìliè bàozhà shìjiàn xiàng Sīlǐlánkǎ zǒngtǒng zhì wèiwèn diàn, Lǐ Kèqiáng xiàng Sīlǐlánkǎ zǒnglǐ zhì wèiwèn diàn" [search results]
 * into google search, it returns one link, our 2019 Sri Lanka Easter bombings article. Pasting the original title into google search finds about 7k hits; none of which I can read ... but still better, I suppose, than a circular link back to our article.
 * —Trappist the monk (talk) 16:03, 22 April 2019 (UTC)

Auto-date-format:
Please, either: change the script parameter to cs1-style or change the template documentation to cs1-dates. 65.88.88.91 (talk) 19:53, 23 April 2019 (UTC)
 * [edit] I suppose you could also alias the script parameter. 65.88.88.91 (talk) 19:56, 23 April 2019 (UTC)
 * done
 * —Trappist the monk (talk) 20:04, 23 April 2019 (UTC)

Lua makes migration hard
Perhaps this has been said before, but the incorporation of Lua code into this template makes it rather hard to migrate Wikipedia articles to other wikis because the standard MediaWiki release does not include Lua. -- Communpedia Tribal (talk) 15:04, 28 April 2019 (UTC)
 * You could make that complaint about any number of en.wiki templates, not just the cs1|2 templates. I know that Scribunto and Lua are available so it would seem that it is just a matter of the other wikis's sysops installing it (and also installing / updating whatever system support Scribunto requires).  If you think that Scributo and Lua should be in the MediaWiki standard release, then you should probably raise that issue with MediaWiki because we can do nothing to help you with that here.
 * —Trappist the monk (talk) 15:35, 28 April 2019 (UTC)
 * ... and that issue has already been raised on Phabricator. * Pppery * has returned 15:36, 28 April 2019 (UTC)
 * Yes, the same has been said about the automated taxobox system, but the advantages of Lua for complex coding far, far outweigh any issues over migration, and I agree that the answer is to make Lua into a MediaWiki standard. Peter coxhead (talk) 16:03, 28 April 2019 (UTC)

Contextual indication of source reliability
Reliable sources/Perennial sources and WP:SOURCEWATCH have some high-quality info and it's a shame to relegate it to pages deep within Wikipedia. I think of all the readers who could benefit when unwittingly clicking through to a "Forbes" article that is actually written by a Forbes contributor. What if we provided some visual indication or explanatory tooltip for specific sources so that readers can better prepare themselves to critically assess the citation's contents? At the very least, we could provide better context for how readers should approach the source's reliability (and why). And has there been prior discussion about such a CS1 feature before? czar 00:30, 1 April 2019 (UTC)
 * (off-topic but still relevant) @Trappist the monk Ack! I was quite shocked to see my name in a reversion saying "Do not delete others' text" etc. Then doubly shocked to check contribs and see that apparently I did delete it. I can only conclude/assume this was a butt-deletion by a cellphone in my pocket. The post above is extremely bland and non-controversial, and I have exactly zero problems with User:Czar. So please accept my apologies for the misdeeds of my posterior. ♦ Lingzhi2 (talk) 01:39, 1 April 2019 (UTC)

Yeah those are some neat resources. I'm afraid if we give them too much prominence editors will begin to treat them as immutable rules like a board game and Wikipedia would begin to be deleted by well-meaning but zealous editors who are "cleaning up". Maybe an optional plugin or something for those doing verification work to colorize sources? Remember the quality of sourcing varies from topic to topic - sourcing quality for an off-beat Internet meme is different from that for George Washington. Everything is contextual. -- Green  C  16:19, 1 April 2019 (UTC)
 * I don't think we need to do anything here at the CS1 level as far as warning readers is concerned. If you need to warn readers, or want them make up their mind about a source, either use a link Journal of Cosmology, or clarify things in prose "In an article published in the fringe-science Journal of Cosmology... ".
 * However, it will likely be useful for WP:SOURCEWATCH to have a sort of verification parameter akin to  for something cited per WP:ABOUTSELF (or similar) or   to indicate that this is the legit, not the hijacked journal. This would turn the SourceWatch into a proper worklist by letting us filter out non-problematic citations to Forbes (or other questionable/problematic sources). However, this needs a bit more stewing in my mind before anything should be implemented here. Headbomb {t · c · p · b} 16:30, 1 April 2019 (UTC)
 * , but readers do not know the standing of a source, especially when used within an article with no additional context, as if often the case. Wikipedia encourages basic information literacy in providing verifiable sources to check claims, but we assume that readers know to vet the source for trustworthiness. In my experience, readers trust that the source is reliable for the claim in the first place, when it could be, e.g., an interview/primary source. We're in a unique position to be able to offer contextual information about a source's use and reliability within the citation itself, or at least to develop the paradigm of visually indicating a source's trust status, even if only for the major cases with deliberate community-wide consensus. czar  13:25, 20 April 2019 (UTC)
 * That's what Wikilinks are for. We don't need to either clutter prose or referencing with POV/Weasily stuff like In the very reliable, but not perfect, Nature, authors said that ... but in the probably reliable Journal of Potato Research and Potato Farming researcher said that..., which is supported by claims published in the prestigious Science and also the averagely prestigious Journal of Farming.
 * The default is a reliable source. Readers shouldn't have to look up wether something is reliable or not because we're supposed to write things based on reliable sources. If it's not, remove the source and put a cn. &#32; Headbomb {t · c · p · b} 15:43, 20 April 2019 (UTC)
 * My focus was on the citation template (CS1), not in sentence-level prose context. The untrained reader does not know how to discern the difference between a self-published source, a fishy source, and a reputable source, and we have the tools/position to assist. My intent is less about requiring us to intervene with cn and more about giving context about how to use the best available source. (not watching, please )  czar  23:36, 28 April 2019 (UTC)

Capitalisation of subtitle with sentence case
I can't find anything definitive on whether to capitalise the first letter of a subtitle after a colon in a book title using sentence case. A subtitle can seem a continuation or separate from the title. A bibliography example that I did 1962 Tour de France. BaldBoris 14:35, 10 April 2019 (UTC)
 * It may seem silly, but I'd really appreciate some feedback on this if you get it. BaldBoris 00:18, 27 April 2019 (UTC)
 * I did not reply to this post because I don't really have an opinion. If you have a particular case, maybe I will have an opinion about that.  What does the original source do?  Follow the source's example?
 * —Trappist the monk (talk) 00:58, 27 April 2019 (UTC)
 * For as long as the capitalization is consistent in the source, try to reproduce the same capitalization as in the original source. If the capitalization of the source differs between the cover and the front matter, I would suggest to use that found in the front matter. This also applies to usage of "-", ":" or "," to separate subtitles. --Matthiaspaul (talk) 18:28, 30 April 2019 (UTC)