Help talk:Citation Style 1/Archive 54

Archive 50 Archive 52 Archive 53 Archive 54 Archive 55 Archive 56 Archive 60

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 {{use mdy dates}} at the bottom of the testcases page. It does not die.

Module:Citation/CS1/Configuration/sandbox sets a new variable global_df to the -all form of the date format keyword used by |df= according to which of {{use mdy dates}} or {{use dmy dates}} (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 global_df. 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 {{Featured article}} is commented out; no other changes. Here is the parser reports taken from each:
parser reports
User:Trappist the monk/Barack Obama Barack Obama
<!-- 
NewPP limit report
Parsed by mw1266
Cached time: 20190311153500
Cache expiry: 86400
Dynamic content: true
CPU time usage: 6.484 seconds
Real time usage: 7.192 seconds
Preprocessor visited node count: 42934/1000000
Preprocessor generated node count: 0/1500000
Post‐expand include size: 1780906/2097152 bytes
Template argument size: 249696/2097152 bytes
Highest expansion depth: 21/40
Expensive parser function count: 33/500
Unstrip recursion depth: 1/20
Unstrip post‐expand size: 1863599/5000000 bytes
Number of Wikibase entities loaded: 5/400
Lua time usage: 3.459/10.000 seconds
Lua memory usage: 15.08 MB/50 MB
-->
<!--
Transclusion expansion time report (%,ms,calls,template)
100.00% 5700.216      1 -total
 67.82% 3866.024      1 Template:Reflist
 38.85% 2214.261    427 Template:Cite_news/new
 11.64%  663.364    140 Template:Cite_web/new
  6.59%  375.468      8 Template:Infobox
  6.27%  357.479      1 Template:Infobox_president
  4.85%  276.218      2 Template:Navboxes
  3.19%  181.778     17 Template:Navbox
  2.80%  159.504     21 Template:Cite_book/new
  2.14%  122.003     17 Template:Infobox_officeholder/office
-->
<!-- 
NewPP limit report
Parsed by mw1325
Cached time: 20190311094329
Cache expiry: 86400
Dynamic content: true
CPU time usage: 6.232 seconds
Real time usage: 6.867 seconds
Preprocessor visited node count: 43065/1000000
Preprocessor generated node count: 0/1500000
Post‐expand include size: 1743517/2097152 bytes
Template argument size: 251255/2097152 bytes
Highest expansion depth: 21/40
Expensive parser function count: 57/500
Unstrip recursion depth: 1/20
Unstrip post‐expand size: 1847068/5000000 bytes
Number of Wikibase entities loaded: 6/400
Lua time usage: 3.264/10.000 seconds
Lua memory usage: 15.55 MB/50 MB
-->
<!--
Transclusion expansion time report (%,ms,calls,template)
100.00% 5297.816      1 -total
 63.80% 3379.907      1 Template:Reflist
 37.60% 1992.136    427 Template:Cite_news
 11.54%  611.612    142 Template:Cite_web
  5.90%  312.565      1 Template:Infobox_president
  5.47%  289.789      8 Template:Infobox
  5.24%  277.460      2 Template:Navboxes
  3.41%  180.533     17 Template:Navbox
  2.37%  125.729     21 Template:Cite_book
  2.15%  113.701      4 Template:Official_website
-->
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 mw: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 mw: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 {{use dmy dates}} or {{use mdy dates}}, or their redirect templates, when they are present in the article's wikitext. When these {{use xxx dates}} 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:
  • {{cite book/new |title=Title |date=2019-03-17 |df=dmy}}Title. 17 March 2019.
  • {{cite book/new |title=Title |date=2019-03-17 |df=mdy}}Title. March 17, 2019.
  • {{cite book/new |title=Title |date=March 17, 2019 |df=dmy}}Title. 17 March 2019.
  • {{cite book/new |title=Title |date=March 17, 2019 |df=ymd}}Title. 2019-03-17.
  • {{cite book/new |title=Title |date=17 March 2019 |df=mdy}}Title. March 17, 2019.
  • {{cite book/new |title=Title |date=17 March 2019 |df=ymd}}Title. 2019-03-17.
these are range dates that the current module will not reformat:
  • {{cite book/new |title=Title |date=March 13–17, 2019 |df=dmy}}Title. 13–17 March 2019.
  • {{cite book/new |title=Title |date=13–17 March 2019 |df=mdy}}Title. March 13–17, 2019.
  • {{cite book/new |title=Title |date=27 February – 2 March 2019 |df=mdy}}Title. February 27 – March 2, 2019.
  • {{cite book/new |title=Title |date=February 27 – March 2, 2019 |df=dmy}}Title. 27 February – 2 March 2019.
  • {{cite book/new |title=Title |date=27 December 2018 – 2 January 2019 |df=mdy}}Title. December 27, 2018 – January 2, 2019.
  • {{cite book/new |title=Title |date=December 27, 2018 – January 2, 2019 |df=dmy}}Title. 27 December 2018 – 2 January 2019.
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 {{use dmy dates}} and {{use mdy dates}} (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 {{use xxx dates}}, perhaps |access=ymd (where ymd is the only allowed value), or create an alternate template {{use dmya dates}} 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 {{use xxx dates}} 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 {{use mdy dates}} 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 dmy-mos and mdy-mos to the list of acceptable keywords for |df=; these keywords are like the -all 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 {{use xxx dates}} 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 {{cs1 config|mode=cs2|df=dmy-mos}} that would tell every cs1|2 template that it is to be rendered as if it were {{citation}}, 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 {{Reflist|df=dmy}} which would format all references accordingly, I'm for it. Headbomb {t · c · p · b} 23:42, 20 March 2019 (UTC)

Not {{reflist|df=dmy}} because that would conflict with {{use xxx dates}}; this is also a problem with the {{cs1 config}} 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 {{cite xxx|df=}}. 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 {{use dmy dates}} where |df= exists in conflict with {{use dmy dates}}.
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 dmy-mos and mdy-mos 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 {{use dmy dates}} 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 {{use dmy dates|access=ymd}} 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 {{use mdy dates}} and {{use mdy dates|access=ymd}}. If |access= is blank or holds some value other than ymd 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 {{use xxx dates|access=ymd}} or blindly removing |access=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 {{use xxx dates}} 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:
  • {{cite book/new |title=Title |date=Mar 17, 2019 |df=dmy}}Title. 17 March 2019.
  • {{cite book/new |title=Title |date=Mar 13–17, 2019 |df=dmy}}Title. 13–17 March 2019.
  • {{cite book/new |title=Title |date=17 Mar 2019 |df=mdy}}Title. March 17, 2019.
  • {{cite book/new |title=Title |date=13–17 Mar 2019 |df=mdy}}Title. March 13–17, 2019.
Where month names don't exist (ymd → dmy or mdy), whole month names are used:
  • {{cite book/new |title=Title |date=2019-03-17 |df=dmy}}Title. 17 March 2019.
  • {{cite book/new |title=Title |date=2019-03-17 |df=mdy}}Title. March 17, 2019.
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 {{use xxx dates}} templates. Perhaps, for lack of a better name for now, |short= that takes the single value yes. |access= might also accept the value abr or some such. Both of these would be decoded:
auto date formatting
|short= |access= publication dates access-/archive-dates
long long
abr long abbreviated
ymd long ymd
yes abbreviated abbreviated
yes abr abbreviated abbreviated
yes ymd abbreviated ymd
Alternately we might dream up a single parameter that accepts a defined set of keywords; perhaps |cs1-dates= with keywords, perhaps:
l – all dates long (default when |cs1-dates= omitted or empty)
ll – all dates long (same as default; here for completeness) – struck because redundant
ls – long publication dates, abbreviated access-/archive-dates
ly – long publication dates, ymd access-/archive-dates
s – all dates abbreviated
ss – all dates abbreviated (same as s; here for completeness) – struck because redundant
sy – abbreviated publication dates, ymd access-/archive-dates
y – 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 {{use xxx dates}} 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 |cs1-dates=sy and User:Trappist the monk/Barack Obama uses |cs1-dates=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 {{df}} 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, {{df}}, would wrap MOS-approved dates and render them according to the article's {{use xxx dates}} 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 {{use dmy dates}} 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 this (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 {{use xxx dates|cs1-dates=<keywords>}} 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 {{use xxx dates}} 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-dates=would 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. {{citation}} 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)

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):
  1. I have tweaked the sandbox so that it accepts |cs1-dates=y in the {{use xxx dates}} 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)
  2. 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
  3. 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.
  4. Yeah, that will happen for those articles that have {{use dmy dates}} or {{use mdy dates}} (or redirects). This search times out but it isn't hard to find |date=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 {{use dmy dates}} or {{use mdy dates}} 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)

@Ohconfucius: 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)
(edit conflict)
If I understand Wikipedia: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 {{use xxx dates}} template (see ohc_use_dates_template()). 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 {{cs1 config}} that would take, for now, a single parameter |df= and requires the presence of either of the {{use xxx dates}} templates. Module:Citation/CS1/Configuration would first search for a {{use xxx dates}} template from which it would get the article's base date format. If {{cs1-config|df=[l|s|y][s|y]?}} is present, the module will use it to refine the rendering of dates within the cs1|2 templates. When neither of the {{use xxx dates}} templates are present, the module will ignore {{cs1-config}} 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):
  1. when {{use xxx dates}} not present in any form, write a new {{use xxx dates|date=<current Month YYYY date>}} – functionality already exists
  2. when {{use xxx dates}} present without |date=, add |date=<current Month YYYY date>
  3. when {{use xxx dates}} present with |date=, replace the value assigned to |date= with <current Month YYYY date>
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:

{{Use mdy dates|date=March 2019|cs1-dates=y}}

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

{{Use mdy dates|date=March 2019}}

So it doesn't seem to be working. Jc3s5h (talk) 19:48, 27 March 2019 (UTC)

Yeah, doesn't work because User:Trappist the monk/script/MOSNUM dates.js test.js doesn't exist. Copy/pasta failure on my part. Should be:
importScript('User:Trappist_the_monk/script/MOSNUM dates.js');
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 {{cs1-config}} template at this edit. 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 this version 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 {{Use mdy dates|date=March 2019|cs1-dates=y}}. After I click 'All dates to dmy' I see {{Use dmy dates|date=March 2019|cs1-dates=y}} 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)

Julian and Gregorian dates

We have a maintenance category, 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 calendar=Gregorian.

Alternatively we could add Gregorian=12 February 1599 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)
(edit conflict)
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)
Category:CS1: Julian–Gregorian uncertainty 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:
{{cite book |title=Title |date=7 January 1042}}Title. 7 January 1042.
generates this metadata:
'"`UNIQ--templatestyles-0000003B-QINU`"'<cite class="citation book cs1">''Title''. 7 January 1042.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=1042&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+54" class="Z3988"></span>
In particular, note the &rft.date 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. ♦ 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):

  1. {{Cite book|url=https://www.worldcat.org/oclc/36969745|title=Dana's minerals and how to study them.|last=1906-2005.|first=Hurlbut, Cornelius S. (Cornelius Searle),|date=1998|publisher=Wiley|others=Sharp, W. Edwin., Dana, Edward Salisbury, 1849-1935.|isbn=0471156779|edition=4th ed.|location=New York|oclc=36969745}}
    1906-2005., Hurlbut, Cornelius S. (Cornelius Searle), (1998). Dana's minerals and how to study them. Sharp, W. Edwin., Dana, Edward Salisbury, 1849-1935. (4th ed. ed.). New York: Wiley. ISBN 0471156779. OCLC 36969745. {{cite book}}: |edition= has extra text (help); |last= has numeric name (help)CS1 maint: extra punctuation (link) CS1 maint: multiple names: authors list (link) (diff)
  2. {{Cite book|url=http://worldcat.org/oclc/1059182319|title=Potential Toxic Effects of Chromium, Chromite Mining and Ferrochrome Production : A Literature Review|last=Canada.|first=MiningWatch|date=2012|publisher=MiningWatch Canada|year=|isbn=|location=|pages=|oclc=1059182319}}
    Canada., MiningWatch (2012). Potential Toxic Effects of Chromium, Chromite Mining and Ferrochrome Production : A Literature Review. MiningWatch Canada. OCLC 1059182319. (diff)
  3. {{Cite book|url=http://worldcat.org/oclc/191989186|title=Ore deposit models 7 : magmatic segregation deposits of chromite|last=M.|first=Duke, J.|oclc=191989186}}
    M., Duke, J. Ore deposit models 7 : magmatic segregation deposits of chromite. OCLC 191989186.{{cite book}}: CS1 maint: multiple names: authors list (link) (diff)
  4. {{Cite book|url=https://www.worldcat.org/oclc/947118220|title=Environmental materials and waste : resource recovery and pollution prevention|others=Prasad, M. N. V. (Majeti Narasimha Vara), 1953-, Shih, Kaimin,|isbn=9780128039069|location=London|oclc=947118220}}
    Environmental materials and waste : resource recovery and pollution prevention. Prasad, M. N. V. (Majeti Narasimha Vara), 1953-, Shih, Kaimin,. London. ISBN 9780128039069. OCLC 947118220.{{cite book}}: CS1 maint: extra punctuation (link) CS1 maint: others (link) (diff)

<rant>

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:
  1. 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
  2. in |last=: part of the publisher's name, extraneous punctuation; in |first=: the other part of the publisher's name
  3. in |last=: author's middle initial; in |first=: surname and first initial
  4. 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.

</rant>

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 |others=<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):
{{cite book |title=Title |date=2019 |location=Location |publisher=Publisher |others=Illustrated by John Smith}}
Title. Illustrated by John Smith. Location: Publisher. 2019.{{cite book}}: CS1 maint: others (link)
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 (|edition=7th ed). --Izno (talk) 16:27, 1 April 2019 (UTC)
I have hacked the sandbox so that cs1|2 applies a maintenance category when |others=<any text> exists (has a value) and both of |author= and |editor= are missing or empty:
{{cite book/new |title=Title |date=2019 |location=Location |publisher=Publisher |others=Illustrated by John Smith}}
Title. Illustrated by John Smith. Location: Publisher. 2019.{{cite book}}: CS1 maint: others (link)
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. |title=Presentation title displays italicized. The documentation says different:

3.4.2 Title

  • title: Title of source. ... Displays in quotes.

2. |book-title=Book title is not described. I would expect this to be italicized. Seems like a good method to differentiate |title= from |book-title=.

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:
{{cite conference |title=Title}}
Title.
{{cite conference |title=Title |book-title=Book Title}}
"Title". Book Title.
Why? Because without |book-title=, cs1 assumes that |title= is the title of the proceedings that the editor is citing as a whole. {{cite conference}} is similar to {{cite journal}}, {{cite news}}, etc. For those templates, |title= is the article in the |journal= or in the |newspaper= so for {{cite conference}}, 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 {{cite conference}}; here are two, perhaps there are others:
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: Book Title. Name of Conference. or Title. Name of Conference. or "Title". Book Title. Name of Conference. or Title of the proceedings. Name of Conference.
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, {{Citation}}:
  1. italicized for {{cite book}}.
  2. quoted for {{cite web}}, independent of |work= / |website=.
  3. quoted for {{cite news}}, independent of |work= / |newspaper=.
  4. quoted for {{cite journal}}, independent of |journal=.
  5. quoted for {{cite magazine}}, 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=
{{cite conference |last=Last |first=First |editor=Editor |title=Paper |book-title=Proceedings |conference=Conference at Nelson's Dockyard, Antigua 1–5 December 2018 |location=Kansas City, KA |publisher=Publisher |date=2019}}
Last, First (2019). "Paper". In Editor (ed.). Proceedings. Conference at Nelson's Dockyard, Antigua 1–5 December 2018. Kansas City, KA: Publisher. {{cite conference}}: |editor= has generic name (help)
|book-title= is a pseudo-alias of |title= because in {{cite conference}}, when |book-title= is set, |title= is not required (as it is in most all other cs1 templates):
{{cite conference |book-title=Proceedings |conference=Conference at Nelson's Dockyard, Antigua 1–5 December 2018 |location=Kansas City, KA |publisher=Publisher |date=2019}}
Proceedings. Conference at Nelson's Dockyard, Antigua 1–5 December 2018. Kansas City, KA: Publisher. 2019.
Yes, it is acknowledged that {{cite conference}} is different from most cs1 templates. So is {{cite encyclopedia}} which is similarly different:
Encyclopedia. {{cite encyclopedia}}: Missing or empty |title= (help)
Title.
"Title". Encyclopedia.
"Article". {{cite encyclopedia}}: Missing or empty |title= (help)
"Article". Encyclopedia.
"Article". Title.
"Article". Title. Encyclopedia.
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:
{{Cite journal|last=Turner|first=Susan |last2=Beattie |first2=Joan |date=2008 |title=((Joan Crockford-Beattie D.Sc.)) |url=http://www.bryozoa.net/annals/annals2/annals_of_bryozoology_2_17_2008_turner.pdf |journal=Annals of Bryozoology 2: aspects of the history of research on bryozoans |volume=2 |pages=viii, 442}}
Turner, Susan; Beattie, Joan (2008). "Joan Crockford-Beattie D.Sc." (PDF). Annals of Bryozoology 2: aspects of the history of research on bryozoans. 2: viii, 442.
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)

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:
|date=May–Aug 2011
no need for |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 |author= or |first= unless you are using |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 |title= for the original title and |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. @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 #Published online parameter? 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 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 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)

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: 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 citation the same as or different from the second 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)

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 |publication-date=, right?
{{cite journal |last=Last |first=First |title=Title |journal=Journal |volume=12 |issue=1 |publication-date=December 1954 |date=January 1955}}
Last, First (January 1955). "Title". Journal (published December 1954). 12 (1).
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)

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[1] 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 |orig-year=published online 10 October 2017 but I'm not sure this is an appropriate use of this parameter.   Jts1882 | 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)

References

  1. ^ Strassert, Jürgen F H; Karnkowska, Anna; Hehenberger, Elisabeth; Campo, Javier del; Kolisko, Martin; Okamoto, Noriko; Burki, Fabien; Janouškovec, Jan; Poirier, Camille (2017-10-10). "Single cell genomics of uncultured marine alveolates shows paraphyly of basal dinoflagellates". The ISME Journal. 12 (1): 304–308. doi:10.1038/ismej.2017.167. ISSN 1751-7370. PMC 5739020. PMID 28994824.
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. ♦ 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. ♦ 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 {{cite journal}} or {{citation}} 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. ♦ 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. ♦ 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)

  Done - 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 | 唯绿远大 (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?

Chinese president Xi Jinping and Premier Li Keqiang expressed their condolences to Sri Lanka leaders on 22 April 2019 after the bombings.[1]

Wei4Green | 唯绿远大 (talk) 15:12, 22 April 2019 (UTC)

References

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#References, would it look readable with all of the Chinese article titles transliterated? —Wei4Green | 唯绿远大 (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: {{use dmy dates}}

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

Wikipedia: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. -- GreenC 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=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 {{cite journal ... |sourcewatch=appropriate}} for something cited per WP:ABOUTSELF (or similar) or {{cite journal ... |sourcewatch=!hijacked}} 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)
@Headbomb, 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}}. 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 {{ping}}) 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#Bibliography. BaldBoris 14:35, 10 April 2019 (UTC)

@Trappist the monk: 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)