Jump to content

Help talk:Citation Style 1/Archive 65

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 60←Archive 63Archive 64Archive 65Archive 66Archive 67→Archive 70

Cite book/doc: "full" parameter lists

I just added two parameters to the "full" parameter lists of the template. I have no clue what other parameters may be missing from these full parameter lists in the documentation. Could someone check and, if needed, update the lists accordingly? Don't know whether a comparable check & possible update for other cite templates wouldn't be welcome too. Tx. --Francis Schonken (talk) 11:26, 1 April 2020 (UTC)

@Francis Schonken: The full list of all parameters (some of which may duplicate others in some way) is at Module:Citation/CS1/Whitelist and some of their correlation is at Module:Citation/CS1/Configuration in the line starting with local aliases. Most of them are applicable to all templates. --Izno (talk) 16:49, 1 April 2020 (UTC)
Module:Citation/CS1/Whitelist contains all aliases (which seem to be defined at Module:Citation/CS1/Configuration): a "full parameter list" should rather indicate each definable parameter value with one single name, without redundantly repeating an alias parameter name for the same parameter content. Is it possible to find (or extract) a list of unique identifiers of parameter values, preferably named after current standard (or preferable) names for these parameters? Tx.
A question: Template:Cite book/doc#Title has:
  • "title: ... Can be wikilinked to an existing Wikipedia article ..."
  • "title-link: Title of existing Wikipedia article about the source named in title ..."
I see no preference for either using a wikilink in the "title" field or defining the "title-link". The second seems less economical WP:ARTICLESIZE-wise (even when using a piped link). Am I right that I can prefer the wikilink in the "title" field? --Francis Schonken (talk) 13:32, 4 April 2020 (UTC)
Yep, Module:Citation/CS1/Whitelist defines all parameter names allowed in cs1|2 templates. Aliasing of those parameter names is determined in the aliases{} table in Module:Citation/CS1/Configuration. Which one of a group of aliases is the canonical parameter name is not defined in the module suite; that determination is rather more political than technical so is documented in the template documentation, typically in {{csdoc}}.
I presume that you mean: Is it possible to produce a list of canonical parameter names? Technically? Yes. Practically? Perhaps, but it might be a painful migration. To do so would require that the determination of the canonical parameter name be established in the aliases{} table with the canonical parameter name listed first. Some snippet of module code somewhere would be necessary to read aliases{} and extract the canonical and alias names for each particular metaparameter and provide these names to {{csdoc}} and its subordinate templates.
At the moment, I cannot think of a reason why one of |title=[[Title]] or |title=Title |title-link=Title should be preferred except perhaps clutter, and as you say, wikitext size but the few bytes difference is really rather negligible.
—Trappist the monk (talk) 14:17, 4 April 2020 (UTC)
  1. {{csdoc}} appears unsuccessful in defining a full parameter set at Template:Citation Style documentation#Full horizontal style, nor is there a usable basis at Template:Citation Style documentation#Full vertical style. Maybe those sections of that documentation page is where a full parameter set (from which derived templates can choose) should start? --Francis Schonken (talk) 15:15, 4 April 2020 (UTC)
  2. Either way, a bot changing from one internal link definition style to another should have that task approved before proceeding, I suppose. To me, it seems like getting such approval would be near-impossible in view of MOS:STYLEVAR, and similar guidance such as WP:CITEVAR, and the bot policy: I imagine such edits would be too close to WP:COSMETICBOT for comfort. Anyhow, the article size argument may be relevant for well-referenced articles (or long lists) flirting with the upper limit of the recommendations at WP:ARTICLESIZE. That is not a theoretical example: this edit pushed the article's size unnecessarily close to the split threshold – and was thus reverted by me. The COSMETICBOT guidance warns that undoing a cosmeticbot edit may be objectionable under the same guidance: not if the bot was for no good reason increasing size of a large article. --Francis Schonken (talk) 15:15, 4 April 2020 (UTC)
Replies:
  1. If {{csdoc}} is unsuccessful, make it successful. That template is only semi-protected so you have the necessary rights to edit it.
  2. cs1|2 is not a bot, does not operate bots, and has no authority over bots. If you have an issue with a bot's edits, the place to address those issues is at the appropriate bot or operator talk page. If I understand WP:ARTICLESIZE, it explicitly excludes wikimarkup contributions including citations (WP:RPS). A tool linked there indicates that List of compositions by Johann Sebastian Bach printed during his lifetime has 7,707 bytes of prose.
—Trappist the monk (talk) 16:44, 4 April 2020 (UTC)

Continuation of bot topic

Be cognizant of this relevant RFC. --Izno (talk) 17:43, 4 April 2020 (UTC)

Thanks for the RfC link, but its outcome does not speak about the diff I gave above ("this edit"), which imported various styles not yet used in the article (not "harmonising a style" within an article, first case considered by the closer of the RfC), nor was any article content work involved (second and last case considered by the closer of the RfC)

In sum, my question was about citation template changing bot tasks without any form of preliminary consensus, i.e. neither an approved task of the bot, nor, as I realised today, something mandated by relevant guidance, nor, as you made me realise, part of the consensus outcome of a relevant RfC.

Replying to two points of Ttm:

  • Re. "If you have an issue with a bot's edits, the place to address those issues is at the appropriate bot or operator talk page" – I know. Just wanted to make sure I had read the guidance correctly.
  • Re. "WP:ARTICLESIZE ... explicitly excludes wikimarkup contributions including citations" – correct, it also makes exceptions for lists, etc. None of that seems, however, relevant in a discussion with someone hacking away in an article they consider too big (case in point). Part of the reasoning, which I can't say I completely disagree with, seems to be that large portions of wikitext in edit mode can cause problems on less advanced machines and/or machines with a slow internet connection. That point is (sort of) made in WP:CHOKING's somewhat confusingly formulated guidance.

--Francis Schonken (talk) 21:43, 4 April 2020 (UTC)

Continuation of "full parameter set" topic

For the sake of curiosity, I've hacked some code. This:

{{#invoke:cs1 documentation support|canonical_param_lister}}

returns this list:

  • access-date
  • agency
  • archive-date
  • archive-format
  • archive-url
  • article-number
  • arxiv
  • asin
  • asin-tld
  • at
  • author-link#
  • author-mask#
  • bibcode
  • bibcode-access
  • biorxiv
  • book-title
  • cartography
  • chapter
  • chapter-format
  • chapter-url
  • chapter-url-access
  • citeseerx
  • class
  • collaboration
  • conference
  • conference-format
  • conference-url
  • contributor-first#
  • contributor-last#
  • contributor-link#
  • contributor-mask#
  • date
  • degree
  • df
  • display-authors
  • display-contributors
  • display-editors
  • display-interviewers
  • display-translators
  • docket
  • doi
  • doi-access
  • doi-broken-date
  • edition
  • editor-first#
  • editor-last#
  • editor-link#
  • editor-mask#
  • eissn
  • encyclopedia
  • episode
  • first#
  • format
  • hdl
  • hdl-access
  • id
  • inset
  • interviewer-first#
  • interviewer-last#
  • interviewer-link#
  • interviewer-mask#
  • isbn
  • ismn
  • issn
  • issue
  • jfm
  • journal
  • jstor
  • jstor-access
  • language
  • last#
  • lccn
  • mailing-list
  • map
  • map-format
  • map-url
  • map-url-access
  • medrxiv
  • message-id
  • minutes
  • mode
  • mr
  • name-list-style
  • network
  • newsgroup
  • no-pp
  • no-tracking
  • number
  • oclc
  • ol
  • ol-access
  • orig-date
  • osti
  • osti-access
  • others
  • page
  • pages
  • people
  • place
  • pmc
  • pmc-embargo-date
  • pmid
  • postscript
  • publication-date
  • publication-place
  • publisher
  • quote
  • quote-page
  • quote-pages
  • ref
  • rfc
  • s2cid
  • s2cid-access
  • sbn
  • scale
  • script-chapter
  • script-encyclopedia
  • script-journal
  • script-map
  • script-quote
  • script-title
  • season
  • sections
  • series
  • series-link
  • series-number
  • sheet
  • sheets
  • ssrn
  • ssrn-access
  • station
  • time
  • time-caption
  • title
  • title-link
  • title-note
  • trans-article
  • trans-encyclopedia
  • trans-journal
  • trans-map
  • trans-quote
  • trans-title
  • transcript
  • transcript-format
  • transcript-url
  • translator-first#
  • translator-last#
  • translator-link#
  • translator-mask#
  • type
  • url
  • url-access
  • url-status
  • vauthors
  • veditors
  • via
  • volume
  • year
  • zbl

The list above is the first (leftmost) alias assigned to a metaparameter in the Module:Citation/CS1/Configuration aliases{} table alpha sorted.

To fetch the canonical name associated with a cs1|2 metaparameter, this, for the Chapter metaparameter, returns:

{{#invoke:cs1 documentation support|canonical_name_get|Chapter}} → chapter

To fetch the alias names (but not the canonical name) associated with a cs1|2 metaparameter, this, for the Chapter metaparameter, returns:

{{#invoke:cs1 documentation support|alias_names_get|Chapter}} → contribution, entry, article, section

Some parameters have only the canonical name. This, for the Agency metaparameter, returns:

{{#invoke:cs1 documentation support|canonical_name_get|Agency}} → agency

But this, because there are no aliases for Agency, returns:

{{#invoke:cs1 documentation support|alias_names_get|Agency}} → none (an empty string)

This was the easy part. If this scheme is to be used, the first task is to sort through the list of aliases in Module:Citation/CS1/Configuration and determine which alias is to be the canonical alias and move it to the front (left end) of the alias list for that metaparameter. Then, in the template documentation templates, insert the appropriate {{#invoke}} in the appropriate place to get the documentation to read correctly.

There may be other issues that I'm overlooking. —Trappist the monk (talk) 20:04, 4 April 2020 (UTC)

Thanks! Seems very helpful.
Re. "If {{csdoc}} is unsuccessful, make it successful" – my question was rather, is {{csdoc}} where best to start to address this issue, or (as I originally intended) just individual citation templates' documentation pages' "full parameter set" lists? --Francis Schonken (talk) 21:43, 4 April 2020 (UTC)
If you have a clear and concise plan for improving the cs1|2 documentation I would think that the best place to start might be right here. Lay out your plan, see what other editors think; see what technical help we can provide, then get to it. The cs1|2 documentation is not a stellar example of our best work so anything that improves it is welcome.
—Trappist the monk (talk) 23:35, 4 April 2020 (UTC)
The background for the plan is, I suppose, something like: {{cite book}}, {{cite web}} and a few other cite templates are among the most often used templates, and are templates that support core content policies such as WP:V. Their documentation should be top notch, so that human editors can use these templates as comfortably as possible. Also for bot operators the documentation should probably better be somewhat clearer, so that always welcome error correction and mostly desirable cleanup are better differentiated from style choices that are often better decided by human editors than by bots.
Question: the list generated above does not contain the "hdl" parameter which I encountered yesterday for the first time, so the list is probably not complete (or is it possible that this parameter is only defined for the "cite book" template?)
Plan, step 1: replace, at Template:Citation Style documentation#Full horizontal style, the "Full parameter set in horizontal format" (currently: {{cite book |last1= |first1= |author1-link= |last2= |first2= |author2-link= |editor1-first= |editor1-last= |editor1-link= |others= |title= |trans-title= |url= |archive-url= |archive-date= |format= |access-date= |type= |edition= |series= |volume= |date= |year= |orig-year= |publisher= |location= |language= |isbn= |oclc= |doi= |id= |page= |pages= |at= |trans-chapter= |chapter= |chapter-url= |quote= |ref= |bibcode= |lay-url= |lay-source= |lay-date= |author-mask= |display-authors= |postscript= |last-author-amp=}}) by one that lists all parameters accepted by (the communal part of?) Citation Style 1 templates, that is, without doubling aliases.
Step 2 would be to do the same for "Full parameter set in vertical format" at Template:Citation Style documentation#Full vertical style
Step 3 would be to do step 1 at Template:Cite book/doc#Usage, that is for all parameters accepted by the {{cite book}} template.
Step 4, would be a similar repeat of step 2 for the {{cite book}} documentation
Step 5 and 6, repeats of both steps (i.e. full horizontal/full vertical) for {{cite web}}'s documentation
Step 7 and 8, similar for {{cite journal}}'s documentation
Etc. for other popular cite templates.
--Francis Schonken (talk) 07:19, 5 April 2020 (UTC)
Identifier parameters are listed in ~/Configuration id_handlers{} and were not included in the original code hack. They now are and the canonical-name and alias-names fetching works for them as well:
{{#invoke:cs1 documentation support|canonical_name_get|ISBN}} → isbn
{{#invoke:cs1 documentation support|alias_names_get|ISBN}} → ISBN
Because of this tweak, I have noticed that the id_handlers{} flip-flop between lowercase-identifier-name-first and uppercase-identifier-name-first. I have standardized on lowercase-identifier-name-first in the sandbox.
I don't see an easy way to automate the full-horizontal and full-vertical lists from the data available in the module suite. The order in which the parameters are presented in the documentation is more a matter of human preference; the modules don't care a whit about order. I can see how we might create an alpha-sorted list of parameters for the various templates by creating exclusion lists. We would exclude |issue=, |sheet(s)= from a listing at {{cite book}} and exclude |chapter= from a listing at {{cite journal}} for example.
—Trappist the monk (talk) 14:18, 5 April 2020 (UTC)

Proposing further intermediary steps for the first step:

  • 1.0 generate alphabetical list of all available parameters
  • 1.1 determine collation order, that is the order in which the parameters are presented in the full set
  • 1.2 getting rid of aliases
  • 1.3 check whether for all parameters with aliases the most appropriate name is used
  • 1.4 check for other reasons to trim or expand the full list
  • 1.5 check for technical issues, if any
  • 1.6 seek community approval
  • 1.7 implement

--Francis Schonken (talk) 12:48, 5 April 2020 (UTC)

Add to your list a determination of which in a group of alias names is the canonical name. This isn't always easy. The cs1|2 metaparameter Periodical currently has:
canonical: journal
aliases: magazine, newspaper, periodical, website, work (there is a long-standing TODO in the code about the last four of these which really should be listed elsewhere)
Which of those parameter names should be the canonical parameter name really depends on context (which template).
One other thing to consider. A complete rewrite and reorganization instead of creating patches to shoehorn into the existing documentation.
—Trappist the monk (talk) 14:18, 5 April 2020 (UTC)
Re. "canonical" – was my intent for 1.3 ("most appropriate" name; don't care whether it is really canonised, but the one that is the best choice, i.e., would be most widely accepted as the name to be used preferentially – yes, that would/should be the canonical one normally, and if not we'd have to consider what to do best)
Re. "complete rewrite" – yes, considered that too, but even if that were plan "zero" (I mean, preceding the steps proposed above), then still execution of that plan zero might *start* with trying to figure out a best way to present full parameter sets. So, I don't have the feeling my energy is lost, even if somewhere in the middle of the execution of the plan sketched above we decide to fundamentally update/rewrite/rework the prose and/or structure of the parameter descriptions and/or layout of the documentation page(s). --Francis Schonken (talk) 15:37, 5 April 2020 (UTC)

Per suggestion above I added a step 1.0: alphabetical list of all available parameters. --Francis Schonken (talk) 10:59, 6 April 2020 (UTC)

Continuing the thought about what to do when the canonical parameter isn't appropriate for a particular template. The canonical Periodical parameter is journal which is fine for {{cite journal}} but not so fine for {{cite magazine}} or {{cite web}} so for those we want something else. So, I've added an override parameter. For the {{cite magazine}} doc page we would write:

{{#invoke:cs1 documentation support|canonical_name_get|Periodical|magazine}} → magazine
{{#invoke:cs1 documentation support|alias_names_get|Periodical|magazine}} → journal, newspaper, periodical, website, work

for {{cite web}}

{{#invoke:cs1 documentation support|canonical_name_get|Periodical|website}} → website
{{#invoke:cs1 documentation support|alias_names_get|Periodical|website}} → journal, magazine, newspaper, periodical, work

—Trappist the monk (talk) 00:58, 15 April 2020 (UTC)

Step 1.0: Alphabetical list of parameters

Retrieved from "aliases" and "id_handlers" at Module:Citation/CS1/Configuration:

handlers, and parameters with which to call them
Handler Canonical Aliases Coll.
AccessDate access-date accessdate 09130
Agency agency none 04060
AirDate —
ArchiveDate archive-date archivedate 09060
ArchiveFormat archive-format none 09050
ArchiveURL archive-url archiveurl 09040
ARXIV arxiv eprint 08020
ASIN asin ASIN 08030
ASINTLD asin-tld none 08035
At at none 07040
AuthorList-First first# author-first#, author#-first, author-given#, author#-given, subject-first#, subject#-first, subject-given#, subject#-given, given# 01020; 01050 01080 01110 01140
AuthorList-Last last# author-last#, author#-last, author-surname#, author#-surname, subject-last#, subject#-last, subject-surname#, subject#-surname, author#, host#, subject#, surname# 01010; 01040 01070 01100 01130
AuthorList-Link author-link# author#-link, subject-link#, subject#-link, authorlink#, author#link 01030; 01060 01090 01120 01150
AuthorList-Mask author-mask# author#-mask, subject-mask#, subject#-mask 10020; 10030
Authors people credits —
BIBCODE bibcode none 08040
BIBCODEaccess bibcode-access none 11040
BIORXIV biorxiv none 08050
BookTitle book-title booktitle —
Cartography cartography none 12040
Chapter chapter contribution, entry, article, section 03090
ChapterFormat chapter-format contribution-format, entry-format, article-format, section-format 09080
ChapterURL chapter-url contribution-url, entry-url, article-url, section-url 09070
ChapterUrlAccess chapter-url-access contribution-url-access, entry-url-access, article-url-access, section-url-access 11030
CITESEERX citeseerx none 08060
Class class none —
Collaboration collaboration none 01240
Conference conference event 15030
ConferenceFormat conference-format none 15050
ConferenceURL conference-url none 15040
Contribution 03120
ContributorList-First contributor-first# contributor#-first, contributor-given#, contributor#-given 01260; 01290
ContributorList-Last contributor-last# contributor#-last, contributor-surname#, contributor#-surname, contributor# 01250; 01280
ContributorList-Link contributor-link# contributor#-link 01270; 01300
ContributorList-Mask contributor-mask# contributor#-mask 10090; 10100
Date date air-date, airdate 05010
Degree degree none —
DF df none 05040
DisplayAuthors display-authors display-subjects 10040
DisplayContributors display-contributors none 10110
DisplayEditors display-editors none 10140
DisplayInterviewers display-interviewers none 13090
DisplayTranslators display-translators none 10080
Docket docket none —
DOI doi DOI 08070
DOIaccess doi-access none 11050
DoiBroken doi-broken-date none 08080
Edition edition none 04010
EditorList-First editor-first# editor#-first, editor-given#, editor#-given 02020; 02050 02080 02110 02140
EditorList-Last editor-last# editor#-last, editor-surname#, editor#-surname, editor# 02010; 02040 02070 02100 02130
EditorList-Link editor-link# editor#-link 02030; 02060 02090 02120 02150
EditorList-Mask editor-mask# editor#-mask 10120; 10130
Editors —
EISSN eissn EISSN 08090
Embargo pmc-embargo-date none 08225
Encyclopedia encyclopedia encyclopaedia, dictionary —
Episode episode none 04040
Format format none 09020
HDL hdl HDL 08100
HDLaccess hdl-access none 11060
ID id ID 08010
IgnoreISBN 08120
Inset inset none 12050
InterviewerList-First interviewer-first# interviewer#-first, interviewer-given#, interviewer#-given 13020; 13050
InterviewerList-Last interviewer-last# interviewer#-last, interviewer-surname#, interviewer#-surname, interviewer# 13010; 13040
InterviewerList-Link interviewer-link# interviewer#-link 13030; 13060
InterviewerList-Mask interviewer-mask# interviewer#-mask 13070; 13080
ISBN isbn ISBN 08110
ISMN ismn ISMN 08140
ISSN issn ISSN 08130
Issue issue number 03070
JFM jfm JFM 08150
JSTOR jstor JSTOR 08160
JSTORaccess jstor-access none 11070
Language language lang 06070
LastAuthorAmp 10050
LayDate 09120
LayFormat 09100
LaySource 09110
LayURL 09090
LCCN lccn LCCN 08170
MailingList mailing-list mailinglist —
Map map none 12010
MapFormat map-format none 12024
MapURL map-url mapurl 12020
MapUrlAccess map-url-access none 12026
MessageID —
Minutes minutes none 07050
Mode mode none 10010
MR mr MR 08180
NameListFormat 01160
Network network none 14040
NoPP no-pp nopp 07030
NoTracking no-tracking template-doc-demo 09140
Number number none —
OCLC oclc OCLC 08190
OL ol OL 08200
OLaccess ol-access none 11080
OrigYear 05030
OSTI osti OSTI 08210
OSTIaccess osti-access none 11090
Others others none 01310
Page page p 07010
Pages pages pp 07020
Periodical journal magazine, newspaper, periodical, website, work 03040
Place place location 06020
PMC pmc PMC 08220
PMID pmid PMID 08230
PostScript postscript none 10150
PublicationDate publication-date publicationdate —
PublicationPlace publication-place publicationplace 06030
PublisherName publisher institution 06010
Quote quote quotation 09150
Ref ref none 09160
RFC rfc RFC 08240
Scale scale none 12030
ScriptChapter script-chapter script-contribution, script-entry, script-article, script-section 03100
ScriptMap script-map none 12014
ScriptPeriodical script-journal script-magazine, script-newspaper, script-periodical, script-website, script-work 03050
ScriptTitle script-title none 03020
Section —
Season season none 14010
Sections sections none 12060
Series series version 04020
SeriesSeparator 14035
SeriesLink series-link serieslink 04030
SeriesNumber series-number series-no 14020
Sheet sheet none —
Sheets sheets none —
SSRN ssrn SSRN 08250
Station station none 14050
Time time none 07060
TimeCaption time-caption none 07070
Title title none 03010
TitleLink title-link episode-link, episodelink —
TitleNote title-note department 03080
TitleType type medium 03130
TransChapter trans-article trans-chapter, trans-contribution, trans-entry, trans-section 03110
Transcript transcript none 15010
TranscriptFormat transcript-format none 15025
TranscriptURL transcript-url none 15020
TranslatorList-First translator-first# translator#-first, translator-given#, translator#-given 01190; 01220
TranslatorList-Last translator-last# translator#-last, translator-surname#, translator#-surname, translator# 01180; 01210
TranslatorList-Link translator-link# translator#-link 01200; 01230
TranslatorList-Mask translator-mask# translator#-mask 10060; 10070
TransMap trans-map none 12016
TransPeriodical trans-journal trans-magazine, trans-newspaper, trans-periodical, trans-website, trans-work 03060
TransTitle trans-title none 03030
URL url URL 09010
UrlAccess url-access none 11010
UrlStatus url-status none 09030
USENETID message-id none —
Vauthors vauthors none 01170
Veditors veditors none 02160
Via via none 06050
Volume volume none 04070
Year year none 05020
ZBL zbl ZBL 08260

Feel free to make the list more complete! --Francis Schonken (talk) 10:59, 6 April 2020 (UTC) Think I have most (just one less than than what is in the "canonical_param_lister" listing above?) all – can someone check whether this is a full list of all parameters accepted by Citation Style 1 template implementations? Tx. --Francis Schonken (talk) 07:19, 7 April 2020 (UTC) Found the missing one. --Francis Schonken (talk) 18:34, 7 April 2020 (UTC)

Something odd is going on with "contribution": it is a parameter in its own right, but also defined as an alias of "chapter". Similarly: "encyclopedia" (alias: "encyclopaedia"), parameter in its own right, and both spellings also aliases of "journal". Is that OK? --Francis Schonken (talk) 13:20, 6 April 2020 (UTC)

For |encyclopedia=, there is a long-standing TODO in the code to fix that (mentioned earlier in these discussions).
For |contribution= that parameter name is required in {{cite book}} (and {{citation}} when none of the |work= aliases have a value) when |contributor= has a value.
{{cite book |chapter=Chapter |title=Title |last=Author}} → Author. "Chapter". Title. {{cite book}}: |last= has generic name (help)
{{cite book |title=Title |contribution=Contribution |last=Author}} → Author. "Contribution". Title. {{cite book}}: |last= has generic name (help)
{{cite book |title=Title |contribution=Contribution |last=Author |contributor=Contributor}} → Contributor. "Contribution". Title. By Author. {{cite book}}: |last= has generic name (help)
Having |contribution= as a separate parameter in the aliases{} table was a simple expedient. I've added TODOs to fix this (easier than fixing the |encyclopedia= issue).
Decode the numbers in the Coll. column?
—Trappist the monk (talk) 14:49, 6 April 2020 (UTC)
Thanks for the clarifications. Here are some more of the quirky ones:
  • "mailinglist": parameter in its own right, and alias for "journal".
  • "message-id" is the canonical for both "MessageID" and "USENETID".
Re. "Decode the numbers in the Coll. column?" – Coll. is abbreviation for "collation", i.e. the collation as currently proposed in the next section (Step 1.1): the first two numbers refer to the block in the list, and the next two to the place the parameter has in that block. A zero is added to allow to insert and/or resort without needing to rewrite all numbers. The ones not assigned in the list below are marked by "—"
Example: 12010 → |map= (first item under number 12); 12020 → |map-url= (2nd item under number 12); |map-format= is currently not listed below: if we'd like to include it between the previous 2, we could give it, e.g., "Coll." number 12015. --Francis Schonken (talk) 15:06, 6 April 2020 (UTC)
|mailinglist= is part of the |encyclopedia= issue but more easily fixed; TODOs added to the sandbox. I had already deactivated |message-id= in the sandbox aliases{} table.
—Trappist the monk (talk) 15:45, 6 April 2020 (UTC)

Step 1.1: collation order

The most logical approach seems to follow the order in which the parameters are explained in the documentation text, i.e., start with "author"-related parameters, then "editor"-related ones, etc. (as they appear in Template:Citation Style documentation#Parameters section):

  1. author-related: {{cite book |others= ...
    not included: "authors" (not adopted in COinS metatdata)
  2. editor-related: ... |veditors= ...
    not included: "editors" (not adopted in COinS metatdata)
  3. title-, web-, chapter-, type- and journal-related: ... |type= ...
    not included: "title-link" (redundant)
    chose "work" instead of its alias "website"
  4. edition-, series-, event-, agency- and volume-related: ... |volume= ...
  5. date-related: ... |df= ...
  6. publisher- and language-related: ... |language= ...
    not included: "publisher-link" (redundant)
    chose "location" instead of its alias "place"
  7. pages- and time-related: ... |time-caption= ...
  8. id-related: ... |zbl= ...
  9. url-, chapterurl-, lay-, quote- and ref-related: ... |ref= ...
  10. display-related: ... |postscript= ...
  11. access-related: ... |sections= ...
  12. interview-related: ... |display-interviewers= ...
  13. season- and network-related: ... |station= ...
  14. transcript- and conference-related: ... }}

--Francis Schonken (talk) 12:48, 5 April 2020 (UTC)
Added a few more. --Francis Schonken (talk) 20:03, 5 April 2020 (UTC)
& one more. --Francis Schonken (talk) 20:24, 5 April 2020 (UTC)
Complete; checking whether I missed parameters accepted by cite-templates would be welcome now. --Francis Schonken (talk) 10:07, 6 April 2020 (UTC)

[1] Perhaps #1 and #2 should be subsections of a single names group? subgroups for author names, editor names, and other names?
[2] In #1 (and #5): |aliases=? what do these mean?
[3] In #3 you use an underscore as a separator; there are no currently supported parameter names that use the underscore; where did you find those? And, |title_title=? |type_default=? You say |title-link= not included (redundant); redundant to what? |contribution-url= should move to #9? |department= is intended more for {{cite news}}; departments of a newspaper (sports, local, ...); like |agency= should probably be ignored by {{cite book}}
[4] If these parameters that you've listed are for {{cite book}}, in #4 |series-link=, |episode=, and |event= are ignored; |agency= probably should be ignored.
[5] In #5, |began= and |ended= are not currently supported parameters; where did you find these?
[6] In #6, doesn't |publication-date= belong in #5? (I'm of a mind that this particular parameter should go away or, at the least, become an equal alias of |date= in the same way that I think that |publication-place= should go away or become an equal alias of |place= – which should be an alias of |location=)
[7] Better name for groups #7 is in-source locator parameters?
[8] Perhaps a new group #10 for miscellaneous parameters? |quote= (#9), |language= (#6); I would also include the lay- parameters here (#9)
—Trappist the monk (talk) 21:59, 5 April 2020 (UTC)
I numbered your suggestions [1] to [8] for ease of responding to them, if that's OK:
--Francis Schonken (talk) 06:49, 6 April 2020 (UTC)
On second thought it would probably be best to keep the parameters for the {{Citation Style documentation}} template itself (which I suppose is what is meant by "Options for..."?) out of the sampled "Full parameter set in horizontal format" example. I removed |aliases=, |title_format=, |title_title=, |type_default=, |map=, |began= and |ended=. --Francis Schonken (talk) 08:01, 6 April 2020 (UTC) The "map" parameter exists in the context of {{cite map}}, so I re-added it to the listing above (the parameter is, however, undocumented in {{Citation Style documentation}}) --Francis Schonken (talk) 10:07, 6 April 2020 (UTC)
By the numbers:
[1] Ok, they don't have to be subgoups of a names group but there should be an 'other names' group for the |translatorn= (never in an author / editor position in the rendered citation), |collaboration= (can't be stand-alone; requires an author), |contributor= (can't be stand-alone; requires an author and |contribution=), |others= (never in an author / editor position in the rendered citation; can be used without author/editor but shouldn't because 'others' implies others).
[2] I was asking about the parameter |aliases= that you listed (and have since removed)
[3] 'title_title' and 'type_default' are not a cs1|2 parameters but are doc option control parameters used by {{csdoc}} to control how that template renders the documentation for that those sections in a cs1|2 template's doc page.
[3][4] Seems you misunderstand the exercise: this one is for Template:Citation Style documentation#Full horizontal style (as you recommended to do first) – not for any of the individual cite templates. Misunderstand? No doubt. But, if this exercise is template agnostic, why does the list in your #1 begin {{cite book? I do not recall any recommendation to start with horizontal style. I think that my first recommendation was (still is) start by choosing which of a list of parameter alias names shall be the canonical parameter name.
[5] I have removed the doc option control parameters for |date= aliases (there are none) and for |began= and |ended= (doc support for those removed January 2016) and added the doc option control parameter |limited_param_list= to hide cs1|2 parameter |orig-year= when the csdoc template is used in documentation for limited-parameter-set cs1 templates.
[6] yes |publication-date= is listed with |publisher= and |place= and |via= but it should't be. It is a date so should be listed with the other publication-date parameters (and converted to a simple alias of |date=)
—Trappist the monk (talk) 14:20, 6 April 2020 (UTC)
"publication-date" removed from the full set proposal, for the same reasons as "air-date" (see below). --Francis Schonken (talk) 05:27, 9 April 2020 (UTC)

Updates to 1.1 and/or parameters needing further attention

Additions to the listing below and/or comments welcome:

1.2 – 1.3 aliases and canonical

This is what the horizontal proposal looks like at the end of substep 1.1:

{{cite book }}

Started to add background colours in the table of #Step 1.0: Alphabetical list of parameters above, indicating whether currently the proposed full set uses a "canonical" or "alias". --Francis Schonken (talk) 16:39, 7 April 2020 (UTC)

Background colours complete: I see around thirty that don't use the canonical name in the above proposal, and am not really bothered by it. e.g. doi-broken-date is a canonical name, for clarity reasons the proposal above uses the first of these two aliases: none. Maybe it would be best that in the software canonical and alias were switched in this case, but for the documentation I see no reason why that should be necessary: an explanation can be done as easily using the alias name as when using the canonical name.

The point here is whether in the proposed list above the best names are chosen, that is: as a list to be used in the documentation. --Francis Schonken (talk) 06:13, 8 April 2020 (UTC)

For clarity, 158 existing parameters, 17 of which not retained in the above full set proposal for being too exotic or too unclear, leaves a whopping 141 parameters listed in the current full set proposal. --Francis Schonken (talk) 05:47, 9 April 2020 (UTC)
Going through the list of canonical and alias names, I think there are a few cases, where canonical and alias names should be swapped for consistency:
Canonical - Aliases ...
  • |author-link#= - |authorlink#= ...
  • |mailing-list= - |mailinglist= ...
  • |lccn= - |LCCN= ...
  • |mr= - |MR= ...
  • |map-url= - |mapurl= ...
  • |oclc= - |OCLC= ...
  • |osti= - |OSTI= ...
  • |pmc= - |PMC= ...
  • |pmid= - |PMID= ...
  • |publication-date= - |publicationdate= ...
  • |rfc= - |RFC= ...
  • |ssrn= - |SSRN= ...
  • |zbl= - |ZBL= ...
  • |author-first#= - |first#= ...
  • |author-last#= - |last#= ...
  • |contributor-last#= - |contributor#= ...
  • |editor-last#= - |editor#= ...
  • |translator-last#= - |translator#= ...
so that the parameter names with hyphens take "precedence" over names without hyphens (for easier readability and improved flow in narrow edit boxes), lower-case names take precedence over all-uppercase names, "-first"-style canonical parameters have corresponding "-last"-style counterparts among canonical names, and the author parameters use the same format as those for editors, contributors, translators (instead of the amibigous shorthands |first= and |last=).
--Matthiaspaul (talk) 19:48, 13 April 2020 (UTC)
The identifier parameter names have already been adjusted in the sandbox. I concur with all of the rest except |last= and |first=. Search results:
|lastn=: 219,805 results (timed out)
|author-lastn=: 435 results (timed out)
|firstn=: 259,291 results (timed out)
|author-firstn=: 453 results (timed out)
the rest of the |last= aliases for completeness:
|surnamen=: 747 results (timed out)
|authorn-last=: 394 results (timed out)
|subjectn=: 725 results (timed out)
|hostn=: 251 results (timed out)
These searches were run in the order listed. If these results are to be believed, there is a clear preference for |lastn= and |firstn=. That may be because the writers of the various individual standalone cs1|2 templates over time converged on |lastn= and |firstn= as the preferred parameter names (listed first in the template code and used in the documentation) or because various tools (reftoolbar etc) prefer those parameter names. I don't know. What is clear is that |lastn= and |firstn= are used far more than any of the other aliases so I think that they should remain in the first position and the documentation of these parameters should be under those names and not under |author-lastn= and |author-firstn=.
Not quite sure what you mean by this: "-first"-style canonical parameters have corresponding "-last"-style counterparts among canonical names. Do you believe that there are |<param name>-first= parameters that do not have a matching |<param name>-last=? If so, which?
—Trappist the monk (talk) 13:33, 14 April 2020 (UTC)
By this I meant that Francis' list above inconsistently has entries like |contributor-first#= and |contributor#= as canonical names, but not |contributor-last#= – this is listed as an alias to |contributor#=, whereas, I think, |contributor#= should better be listed as an alias to |contributor-last#= instead (or as a third canonical parameter, even if handled as alias internally), so that |contributor-first#= has a counterpart |contributor-last#= among the canonical names for symmetry/consistency reasons. Same for |editor-last#= and |editor#=, as well as for |translator-last#= and |translator#=.
Regarding |first#= and |last#= versus |author-first#= and |author-last#=, I think, the main reason why |first#= and |last#= are more prevalent is down to the fact that these parameters exist for much longer, and many tools were never updated. IIRC (but I haven't looked up) |author-first#= and |author-last#= were added much later (at around the time when |editor-first#= and |editor-last#= were added) for reasons of symmetry/consistency. Sure, the old parameters are shorter, but since WP:NOTPAPER I prefer the longer forms because they explicitly declare given names as authors rather than editors. For |first#= and |last#= users will have to look up the documentation to learn about this, otherwise they can be easily confused for a "don't-know-if-this-is-an-author-or-an-editor" parameter. They are almost misnomers.
The only reason why I am proposing this is consistency, because consistency makes it easier for (new) editors to memorize the parameters and reduces the risk of misuse (|first#= and |last#= for editors rather than authors).
--Matthiaspaul (talk) 16:47, 14 April 2020 (UTC)
All of the other adjustments (except |firstn= and |lastn= have been made in the sandbox.
—Trappist the monk (talk) 12:06, 15 April 2020 (UTC)

Taking a step back, I would like to know what it means for a parameter to be chosen as "canonical". If it means only that it is preferred in the documentation, or that it will be the one presented to Visual Editor users, then I don't think this matters so much. If we are going to start having bots converting parameters to their canonical forms, then this is much more problematic to me. I would be quite unhappy to have all my citation templates converted from my preferred choice of parameters (first/last/etc) to somebody else's idea of what should be preferred (author-first/author-last/etc or whatever else is chosen). I would also be unhappy at having my Watchlist gunked up by cosmetic changes like that, and even more unhappy if this decision should be taken a step farther to deprecating or even eliminating non-canonical parameters. (That would break software that I'm no longer certain I can recompile.) It's also perhaps important to note that some of these apparently-synonymous parameters have different semantics associated with them, and sometimes also different formatting output. For instance, in periodical citations, the journal, newspaper, and magazine parameters serve similar functions, but should be used for different classes of periodicals, and produce different output. Putting it more bluntly: what is the point of this exercise? —David Eppstein (talk) 00:25, 14 April 2020 (UTC)

@Trappist the monk: could you take a look at the suggestions and questions by Matthiaspaul and David Eppstein above? As it happens, that's about what I was thinking too, without having ready answers. Tx. --Francis Schonken (talk) 06:35, 14 April 2020 (UTC)
Since you started this series of conversations, oughtn't you to be the one to answer the what is the point of this exercise question?
—Trappist the monk (talk) 13:33, 14 April 2020 (UTC)
The point of the exercise I initiated is clearly explained in #Continuation of "full parameter set" topic above, just before I start to propose the practical steps of the plan. It reads: "{{cite book}}, {{cite web}} and a few other cite templates are among the most often used templates, and are templates that support core content policies such as WP:V. Their documentation should be top notch, so that human editors can use these templates as comfortably as possible. Also for bot operators the documentation should probably better be somewhat clearer, so that always welcome error correction and mostly desirable cleanup are better differentiated from style choices that are often better decided by human editors than by bots." Trappist the monk, as you can see, my pre-emptive explanation of the exercise has no mention at all of aliases vs canonical parameters, which I only included into the plan because it seemed so important to you, and because you asked for it explicitly here ("Add to your list a determination of which in a group of alias names is the canonical name"): so it's not up to me to explain "why" the aliases vs canonical parameters part of the exercise is important (which I don't know either, and which I was more and more wondering about too, so that at a certain point I started to ignore it, see above "I see around thirty that don't use the canonical name in the above proposal, and am not really bothered by it" – emphasis added). --Francis Schonken (talk) 14:01, 14 April 2020 (UTC)
Important to me because early-on you asked: Is it possible to find (or extract) a list of unique identifiers of parameter values, preferably named after current standard (or preferable) names for these parameters? To which my answer was the creation of:
{{#invoke:cs1 documentation support|canonical_param_lister}}
{{#invoke:cs1 documentation support|canonical_name_get|<meta-parameter>}}
{{#invoke:cs1 documentation support|alias_names_get|<meta-parameter>}}
Important to me because the code that is those three functions needs some way of knowing which parameter in a list of parameters is to be the parameter that we identify as the one parameter that goes into your vertical and horizontal lists. If we do nothing else with canonical_name_get() and alias_names_get() we should use them in {{csdoc}} and its sub-templates to provide the parameter names we are defining. The primary reason for this is to ease the doc maintenance burden; defined parameters and associated aliases will always be in sync with the module suite.
The determination of which parameter name in a list of parameter names is to be the one that gets defined and explained still needs doing.
The color coding in the table at Help talk:Citation Style 1 § Step 1.0: Alphabetical list of parameters should all be in the canonical column; your horizontal and vertical lists should only draw from that column.
—Trappist the monk (talk) 16:30, 14 April 2020 (UTC)
Well "why" that should be so is still not clear to me. You prefer it, that's clear. For writing the user's manual it makes no real difference, a parameter can be explained with whatever name that works, and all working alternatives for that name should be mentioned in the documentation anyhow. --Francis Schonken (talk) 16:51, 14 April 2020 (UTC)
It doesn't make sense to me to write user manual documentation for a lessor-used parameter from a list of parameter aliases; it still works but that way is certainly less than optimal. All of the aliases should be mentioned (for the most part they are mentioned in the current documentation). The proper parameter name associated with the documentation and mention of all aliases would be assured if we implement canonical_name_get() and alias_names_get() in the {{csdoc}} and sub-templates and take the trouble to select which one parameter from each list of parameter aliases is the one that we define and explain.
—Trappist the monk (talk) 18:39, 14 April 2020 (UTC)
This is what we currently have for the OCLC handler:
  • canonical name: oclc
  • non-canonical alias: OCLC
Documentation currently suggests to use lower case for parameter names, so whichever is the canonical (upper case or lower case) all documentation descriptions & examples currently use lower case, which makes it quite irrelevant which one is the canonical – both for current and future documentation. --Francis Schonken (talk) 18:57, 14 April 2020 (UTC)
Umm, this was noted, resolved in the sandbox, and reported at Help talk:Citation Style 1 § Continuation of "full parameter set" topic:
I have noticed that the id_handlers{} flip-flop between lowercase-identifier-name-first and uppercase-identifier-name-first. I have standardized on lowercase-identifier-name-first in the sandbox. (diff)
—Trappist the monk (talk) 19:47, 14 April 2020 (UTC)
Indeed, illustrates that the distinction between canonical and alias is of no consequence for the documentation. If the code follows what is deemed best according to the documentation in canonical vs alias issues, that's OK for me, but not something that needs to be resolved in the documentation, that is a code adaptation, not a documentation adaptation – and certainly not documentation adapting to the code on these matters.
The documentation update on the full parameter sets etc. can proceed without needing to wait for further software updates, and without needing to re-adjust colour codes in tables etc. --Francis Schonken (talk) 20:51, 14 April 2020 (UTC)
Clearly, we are not communicating. I wrote in that same discussion:
The order in which the parameters are presented in the documentation is more a matter of human preference; the modules don't care a whit about order.(diff)
To draw anything useful from the module suite for the documentation, the order in which the parameters are listed in ~/Configuration needs tweaking so that the data are appropriate to the documentation.
—Trappist the monk (talk) 12:06, 15 April 2020 (UTC)
Since this whole topic is about cs1|2 documentation, the canonical parameter is that single parameter that, out of a group of aliases, is the parameter that is defined and explained. We define and explain |lastn= but do not define and explain |author-lastn=.
As far as I can see, none here have advocated for bots converting parameters to their canonical forms. Misbehaving bot operators have always had the ability to write bots to do that. These discussion will not change that.
In {{citation}}, |journal= and |newspaper= do cause the citation to render differently from the same citation using |magazine=. In cs1 periodical templates, the template name determines how that template renders so the periodical parameters are equivalent there.
The point of this exercise, as I understand it, is to improve the cs1|2 documentation.
—Trappist the monk (talk) 13:33, 14 April 2020 (UTC)
Re. "the canonical parameter is that single parameter that, out of a group of aliases, is the parameter that is defined and explained": not in the current documentation, and even less so in the #Parameter descriptions for documentation proposal below. --Francis Schonken (talk) 14:01, 14 April 2020 (UTC)
Because you had already established that your suggested parameter descriptions for documentation should include:
canonical parameter name
an aliases list
usage example
description and explanation text
and because I do not disagree with those inclusions, I saw no reason to repeat those things in my list.
not in the current documentation Not sure that I agree. {{csdoc}} and its sub templates define and explain a subset of parameters and list the associated aliases. The choice of which canonical parameter is that single parameter ... that is defined and explained is determined in each of the individual sub-templates and does not necessarily reflect the parameter-name ordering used the module suite. It is true that there are parameters that are not defined and explained and I have done some fixing in that regard.
—Trappist the monk (talk) 16:30, 14 April 2020 (UTC)
Do you suggest to wait with publishing the proposed full horizontal set in the Template:Citation Style documentation#Full horizontal style section until after #module suite update 18–19 April 2020? I think the proposed set is better than the current (very limited) full horizontal set, and there's no impediment to further fine-tunings after the 18–19 April software update. --Francis Schonken (talk) 16:51, 14 April 2020 (UTC)
Because your list is a manually curated list and because it can be tweaked whenever it needs tweaking, you are free to publish it whenever you would like. If, as I think should be done, the list is to be automated, then the decisions regarding which single parameters from the alias lists belong in the horizontal and vertical lists need to be taken so that the source data can be arranged accordingly.
—Trappist the monk (talk) 18:39, 14 April 2020 (UTC)

Parameter descriptions for documentation

Alias(es):
Usage (e.g., |air-date=):

Would that work? Thinking about building a template to format standard parameter descriptions in this way. --Francis Schonken (talk) 09:34, 8 April 2020 (UTC); Updated the description, had misunderstood how this parameter operates, see below #air-date. --Francis Schonken (talk) 04:39, 9 April 2020 (UTC)

Every parameter has a set of properties. The properties that come immediately to mind, and in no particular order, are:
  • is a limited-use parameter: yes|no
  • can be enumerated: yes|no
  • contributes to COinS metadata: yes|no
  • requires other parameter(s): <list>
  • has restricted value set: <list>
  • supports ((...)) Accept-this-as-written markup: yes|no
  • has parameter-specific error detection: <list>
  • has parameter-specific maintenance category: <list>
  • has parameter-specific property category: <list>
A per-parameter doc template should, I think, include all of this. Should also have an anchor so that it can be linked from somewhere else.
Usage examples should be simple with just enough other parameters to produce a valid rendering. Too many of the examples in the cs1|2 doc pages are overly complex.
—Trappist the monk (talk) 12:00, 8 April 2020 (UTC)
I think it would be best to have technical documentation (for those involved with the setting up and maintenance of cite templates and the underlying code), and a user's manual for those using the templates when adding content to the encyclopedia (and have no, nor need to have, inklings regarding what, e.g., a "property category" means). The latter should be written (as much as possible) in plain English, and be concise (not because of using technical language, but because of omitting what a content contributor would not likely be looking for). --Francis Schonken (talk) 12:23, 8 April 2020 (UTC)
Two things to manage and maintain instead of one? That makes no sense to me. All of a parameter's information should be collected in one place. How that information is displayed can be as simple as a default-collapsed portion of the rendering for select information.
—Trappist the monk (talk) 12:53, 8 April 2020 (UTC)
Or, the more technical summary as something that shows up when a subtemplate like {{Citation Style documentation/author}} is posted at {{Citation Style documentation}}, but not when the same subtemplate is used anywhere else, such as when transcluded in {{Cite book/doc}}. The technical solutions to keep the documentation in a single place, and still diversify according to target audience are multiple. --Francis Schonken (talk) 16:11, 8 April 2020 (UTC)

Anyway, removed "air-date" and "publication-date" from the proposed full parameter set above: their uses appear too limited, and the way they operate too questionable, for listing them in the proposal. --Francis Schonken (talk) 05:27, 9 April 2020 (UTC)

Steps 1.4 to 1.7 — Completing step 1 and moving on to step 2

The horizontal full set proposal resulting from earlier steps, and listed above in #1.2 – 1.3 aliases and canonical, currently contains 141 parameters (selected from a total of 158 currently existing parameters). I assume discussions about which name of the possible canonical and alias ones are to be used in the example set are concluded (are they?), so that we can proceed with a last check of whether more parameters should be added to, or removed from, the full set example for adoption in the Template:Citation Style documentation#Full horizontal style section. --Francis Schonken (talk) 07:09, 9 April 2020 (UTC)

Technical check: I see no further technical issues to continue with the next step. The parameters most in need of some technical adjustment are no longer retained in the full set; inasmuch as these adjustments are still outstanding, they are also not relevant for the current full set proposal. Also, updates to the full set after these issues are resolved are easy enough to perform, imho. Other thoughts? --Francis Schonken (talk) 05:21, 13 April 2020 (UTC)

Afaics from discussions in subsections above there's enough support for introduction of the full horizontal parameter set in the documentation (step 1.6), so I'll proceed with that (step 1.7), after which we can start work on the full vertical set for the documentation template (step 2). --Francis Schonken (talk) 06:11, 15 April 2020 (UTC)

Step 1.7 done --Francis Schonken (talk) 06:35, 15 April 2020 (UTC)

Step 2: vertical list format? – and other questions

{{Citation Style documentation}} currently recommends this 3-column format for the vertical list: 

{{csdoc|usage vertical}}
<pre style="margin:0px;">
{{cite book
| last                  =
| first                 =
| author-link           =
}}
</pre>
{{csdoc|usage vertical mid}}
<pre style="margin:0px;">
&nbsp;
&nbsp;
last
&nbsp;
&nbsp;
</pre>
{{csdoc|usage vertical mid}}
<pre style="margin:0px;">
&nbsp;
same as last1
same as first1
&nbsp;
&nbsp;
</pre>
{{csdoc|usage vertical end}}
Full parameter set in vertical format
Vertical list Prerequisites Brief instructions / notes 
{{cite book
| last                  =
| first                 =
| author-link           =
}}

 
 
last
 
 

 
same as last1
same as first1
 
 
  • If a field name is listed in the Prerequisites column, it is a prerequisite for the field to the left.

This format may work for templates with a handful of parameters, however it seems unworkable for a template with a large number of parameters (like the ones we're dealing with here). Instead, e.g. {{Cite book/doc}} uses this 4-column format: 

{| class="wikitable"
|+Full parameter set in vertical format
! Parameters !! Prerequisites !! Brief instructions / notes !! Vertical list
|-
|| last1 ||  || may also use "last"; for additional authors, "last2", "last3", etc. || rowspan="3" style="vertical-align:top;" | <pre style="margin:0px; border:none;">
{{cite book
|last1=
|first1=
|author-link1=
}}
</pre>
|-
| first1 || last or last1 || may also use "first"; for additional authors, "first2", "first3", etc.
|-
|| author-link1 || last or last1 || may also use "author-link"
|-
| colspan="4" style="text-align: center " | If a field name is listed in the '''Prerequisites''' column it is a prerequisite for the field to the left.
|}
Full parameter set in vertical format
Parameters Prerequisites Brief instructions / notes Vertical list
last1 may also use "last"; for additional authors, "last2", "last3", etc. 
{{cite book
|last1=
|first1=
|author-link1=
}}
first1 last or last1 may also use "first"; for additional authors, "first2", "first3", etc.
author-link1 last or last1 may also use "author-link"
If a field name is listed in the Prerequisites column it is a prerequisite for the field to the left.

I'm not going to try to build the full vertical list in the 3-column format (141 parameters and counting) but am not sure whether {{Cite book}}'s 4-column format is anything near a standard (is it?).

So, a few questions:

  • which format would be wisest to use for presentation of the full vertical list at Template:Citation Style documentation#Full vertical style, or can I just go with {{Cite book}}'s 4-column format?
  • Do we want to keep the 3-column format guidance at {{Citation Style documentation}} (then with an indication it is only useful for cite templates which allow no more than a limited set of parameters), or should I rather aim at a replacement of that 3-column format with whatever format is indicated in the discussion here as more optimal (I don't think any of the cite templates has under a dozen parameters)?
  • Is there any (meta-)guidance on how to build vertical lists of parameters for (whatever) templates?

--Francis Schonken (talk) 14:36, 16 April 2020 (UTC)

Further questions and suggestions:

|lay-summary=, |registration=, |subscription= no longer supported. Did you find any of these in some documentation someplace? Where?
—Trappist the monk (talk) 14:49, 19 April 2020 (UTC)
@Trappist the monk: these three parameters are listed in Template:Cite book/doc#Usage, both in the "full horizontal" and "full vertical" lists of that documentation. Additionally, |lay-summary= is currently indicated as a prerequisite for both |lay-source= and |lay-date= in the "full vertical" list of that documentation. I don't see very well how a no longer supported parameter can be a prerequisite for two supported parameters? Do these supported parameters no longer have prerequisites? Or do they have (currently unmentioned) other prerequisites? --Francis Schonken (talk) 04:54, 20 April 2020 (UTC)
Fixed at {{cite book}}.
—Trappist the monk (talk) 12:18, 20 April 2020 (UTC)

Step 2: vertical list table proposal

Starting, based on {{Cite book}}'s 4-column format:

(list moved to Template:Citation Style documentation/doc#Four columns format)

--Francis Schonken (talk) 03:15, 17 April 2020 (UTC)

Obsolete parameters removed from table. --Francis Schonken (talk) 06:06, 21 April 2020 (UTC)

The above table proposal is now complete in mentioning all parameters, but the middle columns still need to be updated/filled; and some remaining questions answered (six of them, see previous subsection, i.e. #Step 2: vertical list format? – and other questions). --Francis Schonken (talk) 14:44, 19 April 2020 (UTC)

The full vertical list has now been moved to the documentation. Remaining issues:

  • Both the 3-column model as the 4-column model are currently in the documentation (see Template:Citation Style documentation/doc#Full vertical style). Still not sure whether the rather impractical 3-column format needs to be retained there.
  • Examples of the {{hover title}} template, used for listing aliases, are retained in the 4-column format, but whether that is a good idea, I don't know.
  • The two middle columns of the 4-column format still need to be further updated, but that can be done in the documentation directly as far as I'm concerned (and for that reason I did not keep a copy of that list here).

--Francis Schonken (talk) 05:48, 22 April 2020 (UTC)

Step 3–4: cite book doc

For steps 3 and 4, the full horizontal and full vertical sets of the {{cite book}} documentation, I'd work parameter by parameter in both sets concurrently, updating Template:Cite book/doc#Usage directly, and only returning here if there are any issues while updating. --Francis Schonken (talk) 12:31, 22 April 2020 (UTC)

prospective documentation &c.

Sort of as an offshoot of Help talk:Citation Style 1 § Cite book/doc: "full" parameter lists, I've been wondering about using some of the code that I wrote for that discussion. I chose the name-holding parameters as a test bed and created Template:Citation Style documentation/names.

That template is almost wholly automated. cs1|2-parameter canonical- and alias-names are drawn directly from Module:Citation/CS1/Configuration. The contributor-name documentation is only rendered when the template is transcluded in {{cite book}} or {{citation}}. Similarly, only the author-name documentation is rendered when the template is transcluded in the pre-print templates, {{cite arxiv}}, {{cite biorxiv}}, {{cite citeseerx}}, and {{cite ssrn}}.

I chose to group all of the name-related parameters into this single template so that they would all be in the same place. For example, at {{cite book}}, |author-mask= is documented in § Display options which is rather a long way away from § Authors. Still, the template does require one parameter, |header-level= which sets the number of equal signs (=) on each side of a header's text.

Have a look. What is there is mostly copied from the existing documentation so no doubt, no doubt, can be improved. The template includes a notes section that may or may not be retained; includes and explanation of parameter enumeration and the rules thereof. Opinions? Keep? Discard? Enhance?

You can see how the template renders in various cs1|2 template documentation by editing the ~/doc page. Choose a location and add this:

{{csdoc|names|header-level=5}}

Click show preview.

Another thing that I have done is to modify Template:Citation Style documentation itself. In the past, when modifying a csdoc sub-template so that portions of the sub-template are rendered according to the state of some parameter, those parameters had to be added to Template:Citation Style documentation as pass-through parameters. That is just a headache so I have replaced the content of Template:Citation Style documentation with a call to Module:Template wrapper so that all parameters in the call to Template:Citation Style documentation are passed through to the underlying sub-template.

—Trappist the monk (talk) 18:50, 22 April 2020 (UTC)

Vancouver style error message fix

This mess fails because of the parentheses in |last= but the current error message isn't working correctly:

Cite book comparison
Wikitext {{cite book|chapterurl=http://books.nap.edu/openbook.php?record_id=12480&page=530|doi=10.17226/12480|first1=Youth|first2=M. E.|first3=T.|first4=K. E.|isbn=978-0-309-12674-8|last1=National Research Council (Us) Institute Of Medicine (Us) Committee On The Prevention Of Mental Disorders Substance Abuse Among Children|last2=O'Connell|last3=Boat|last4=Warner|pages=530|pmid=20662125|publisher=National Academies Press|quote=Table E-4 Risk Factors for Anxiety|title=Prevention of Mental Disorders, Substance Abuse, and Problem Behaviors: A Developmental Perspective|url=https://semanticscholar.org/paper/a83d9124d2e53dafd330910fdfa9dfe854440f17|veditors=O'Connell ME, Boat T, Warner KE|year=2009}}
Live National Research Council (Us) Institute Of Medicine (Us) Committee On The Prevention Of Mental Disorders Substance Abuse Among Children Youth, O'Connell ME, Boat T, Warner KE (2009). O'Connell ME, Boat T, Warner KE (eds.). Prevention of Mental Disorders, Substance Abuse, and Problem Behaviors: A Developmental Perspective. National Academies Press. p. 530. doi:10.17226/12480. ISBN 978-0-309-12674-8. PMID 20662125. Table E-4 Risk Factors for Anxiety {{cite book}}: External link in |chapterurl= (help); Unknown parameter |chapterurl= ignored (|chapter-url= suggested) (help); Vancouver style error: non-Latin character in name 1 (help)
Sandbox National Research Council (Us) Institute Of Medicine (Us) Committee On The Prevention Of Mental Disorders Substance Abuse Among Children Youth, O'Connell ME, Boat T, Warner KE (2009). O'Connell ME, Boat T, Warner KE (eds.). Prevention of Mental Disorders, Substance Abuse, and Problem Behaviors: A Developmental Perspective. National Academies Press. p. 530. doi:10.17226/12480. ISBN 978-0-309-12674-8. PMID 20662125. Table E-4 Risk Factors for Anxiety {{cite book}}: External link in |chapterurl= (help); Unknown parameter |chapterurl= ignored (|chapter-url= suggested) (help); Vancouver style error: non-Latin character in name 1 (help)

Fixed in the sandbox.

—Trappist the monk (talk) 19:54, 22 April 2020 (UTC)

air-date

As a result of the discussion above, I've been looking at how |air-date= and its alias |airdate= are handled. In the current live module suite, these parameters are only used by {{cite episode}} and {{cite serial}} and are sort-of aliases of |date=. When |date= is present and has a value in {{cite episode}} and {{cite serial}} templates, and when one of |air-date= or |airdate= is present and set, the template quietly ignores them. This is inconsistent with how we treat other redundant aliases in cs1|2 templates.

Because |air-date= and |airdate= are only used in the two templates, I hit upon the idea of creating a template_specific_arguments table in Module:Citation/CS1/Whitelist/sandbox. This mechanism is similar to how we handle the preprint cs1 templates ({{cite arxiv}} and the like). This new table holds parameters that are only used by specified templates. During the parameter validation process (nearly the first thing we do with a cs1|2 template) the module consults the variety of tables in ~/Whitelist. It knows which template is being rendered so can look in the appropriate sub-table for the parameter being validated.

In the live module, |air-date= and |airdate= are listed in the ~/Whitelist basic_arguments{} table of supported parameters and have a separate entry in the ~/Configuration aliases{} table. In the sandboxen, I have moved |air-date= and |airdate= into sub-tables of the new ~/Whitelist/sandbox template_specific_arguments{} table and added them to the Date entry in ~/Configuration/sandbox aliases{} table.

Cite serial comparison
Wikitext {{cite serial|date=April 2020|title=Title}}
Live Title. April 2020.
Sandbox Title. April 2020.
Cite serial comparison
Wikitext {{cite serial|air-date=2020-04-08|title=Title}}
Live Title. 2020-04-08.
Sandbox Title. 2020-04-08.
Cite serial comparison
Wikitext {{cite serial|air-date=2020-04-08|date=April 2020|title=Title}}
Live Title. April 2020. {{cite serial}}: More than one of |air-date= and |date= specified (help)
Sandbox Title. April 2020. {{cite serial}}: More than one of |air-date= and |date= specified (help)
Cite episode comparison
Wikitext {{cite episode|date=April 2020|series=Series}}
Live Series. April 2020.
Sandbox Series. April 2020.
Cite episode comparison
Wikitext {{cite episode|air-date=2020-04-08|series=Series}}
Live Series. 2020-04-08.
Sandbox Series. 2020-04-08.
Cite episode comparison
Wikitext {{cite episode|air-date=2020-04-08|date=April 2020|series=Series}}
Live Series. April 2020. {{cite episode}}: More than one of |air-date= and |date= specified (help)
Sandbox Series. April 2020. {{cite episode}}: More than one of |air-date= and |date= specified (help)
Cite journal comparison
Wikitext {{cite journal|airdate=2020-04-08|journal=Journal|title=Title}}
Live "Title". Journal. {{cite journal}}: Unknown parameter |airdate= ignored (help)
Sandbox "Title". Journal. {{cite journal}}: Unknown parameter |airdate= ignored (help)
Cite journal comparison
Wikitext {{cite journal|air-date=2020-04-08|journal=Journal|title=Title}}
Live "Title". Journal. {{cite journal}}: Unknown parameter |air-date= ignored (help)
Sandbox "Title". Journal. {{cite journal}}: Unknown parameter |air-date= ignored (help)
Cite journal comparison
Wikitext {{cite journal|air-date=2020-04-08|date=April 2020|journal=Journal|title=Title}}
Live "Title". Journal. April 2020. {{cite journal}}: Unknown parameter |air-date= ignored (help)
Sandbox "Title". Journal. April 2020. {{cite journal}}: Unknown parameter |air-date= ignored (help)

—Trappist the monk (talk) 15:39, 8 April 2020 (UTC)

I have done the same with the rest of the {{cite episode}} and {{cite serial}} parameters. This uses some of them:

Cite episode comparison
Wikitext {{cite episode|airdate=9 October 1965|credits=Writer [[Terry Nation]], Director [[Derek Martinus]], Producer [[Verity Lambert]]|episodelink=Mission to the Unknown|location=London|network=BBC|series=Doctor Who|station=BBC One|title=Mission to the Unknown}}
Live Writer Terry Nation, Director Derek Martinus, Producer Verity Lambert (9 October 1965). "Mission to the Unknown". Doctor Who. London. BBC. BBC One. {{cite episode}}: Unknown parameter |episodelink= ignored (|episode-link= suggested) (help)
Sandbox Writer Terry Nation, Director Derek Martinus, Producer Verity Lambert (9 October 1965). "Mission to the Unknown". Doctor Who. London. BBC. BBC One. {{cite episode}}: Unknown parameter |episodelink= ignored (|episode-link= suggested) (help)

and changing to {{cite book}} to demonstrate exclusivity:

Cite book comparison
Wikitext {{cite book|airdate=9 October 1965|credits=Writer [[Terry Nation]], Director [[Derek Martinus]], Producer [[Verity Lambert]]|episodelink=Mission to the Unknown|location=London|network=BBC|series=Doctor Who|station=BBC One|title=Mission to the Unknown}}
Live Mission to the Unknown. Doctor Who. London. {{cite book}}: Unknown parameter |airdate= ignored (help); Unknown parameter |credits= ignored (help); Unknown parameter |episodelink= ignored (help); Unknown parameter |network= ignored (help); Unknown parameter |station= ignored (help)
Sandbox Mission to the Unknown. Doctor Who. London. {{cite book}}: Unknown parameter |airdate= ignored (help); Unknown parameter |credits= ignored (help); Unknown parameter |episodelink= ignored (help); Unknown parameter |network= ignored (help); Unknown parameter |station= ignored (help)

—Trappist the monk (talk) 18:33, 8 April 2020 (UTC)

And one more, {{cite newsgroup}}:

Cite newsgroup comparison
Wikitext {{cite newsgroup|author=Tanenbaum, A. S.|date=January 29, 1992|message-id=12595@star.cs.vu.nl|newsgroup=comp.os.minix|quote=I am not unhappy with LINUX|title=LINUX is obsolete}}
Live Tanenbaum, A. S. (January 29, 1992). "LINUX is obsolete". Newsgroup: comp.os.minix. Usenet: 12595@star.cs.vu.nl. I am not unhappy with LINUX
Sandbox Tanenbaum, A. S. (January 29, 1992). "LINUX is obsolete". Newsgroup: comp.os.minix. Usenet: 12595@star.cs.vu.nl. I am not unhappy with LINUX

and changing to {{cite book}} to demonstrate exclusivity:

Cite book comparison
Wikitext {{cite book|author=Tanenbaum, A. S.|date=January 29, 1992|message-id=12595@star.cs.vu.nl|newsgroup=comp.os.minix|quote=I am not unhappy with LINUX|title=LINUX is obsolete}}
Live Tanenbaum, A. S. (January 29, 1992). LINUX is obsolete. I am not unhappy with LINUX {{cite book}}: Unknown parameter |message-id= ignored (help); Unknown parameter |newsgroup= ignored (help)
Sandbox Tanenbaum, A. S. (January 29, 1992). LINUX is obsolete. I am not unhappy with LINUX {{cite book}}: Unknown parameter |message-id= ignored (help); Unknown parameter |newsgroup= ignored (help)

All for now, I think. Other candidates for this treatment are: {{cite conference}}, {{cite mailing list}}, {{cite map}}, {{cite speech}} and perhaps others.

—Trappist the monk (talk) 19:48, 8 April 2020 (UTC)

I am in general agreement with the specific args table. I suppose that semantically |air-date= and |publication-date= would be considered equivalent. 98.0.246.242 (talk) 01:58, 9 April 2020 (UTC)
@Trappist the monk: I see that |air-date= has now been merged into |date= (technically: has become an alias of the latter, instead of a parameter in its own right). Why hasn't |publication-date= shared its fate? That seemed similar enough to be treated likewise? Or am I missing something? --Francis Schonken (talk) 03:45, 23 April 2020 (UTC)
Because |publication-date= is only an equal alias of |date= when it is used alone. When used with |date=, |publication-date= is also rendered:
{{cite book |title=Title |date=1999}}
Title. 1999.
{{cite book |title=Title |publication-date=2020}}
Title. 2020.
{{cite book |title=Title |date=1999 |publication-date=2020}}
Title (published 2020). 1999.
Just as I would like to see |publication-place= go away, so too, I would like to see |publication-date= go away
—Trappist the monk (talk) 11:08, 23 April 2020 (UTC)
So |publication-date= does now what I described as my preferential MO for air-date (see below, with explanation & example why it should be available for works that are aired). So no, keep it. And, if this is possible for publication-date, there should be no major issue to implement the same for "air-date", so please bring |air-date= back, with that specific MO. Well, make it just an alias of publication-date, after which the parameter can be made available to most (if not all) cite templates. Thanks. --Francis Schonken (talk) 11:36, 23 April 2020 (UTC)
With air-date, the emitted cite should read "Title (aired 2020). 1999." – so struck the last part of my last suggestion: just bring air-date back, with a functionality comparable to current publication-date (but then for works that can be aired). I think that e.g. {{cite interview}} should have both: an interview will often have a publication date (e.g. when printed) or airing date (for e.g. televised interviews) different from the date when the interview was taken (both *when* the interviewed person said something, and *when* it was made public can have significance). --Francis Schonken (talk) 12:07, 23 April 2020 (UTC)

Test:

{{cite book |title=Title |date=2000 |publication-date=2000}}
Title. 2000.
{{cite book |title=Title |date=2000-01-14 |publication-date=2000-01-14}}
Title. 2000-01-14.
{{cite book |title=Title |date=2000-01-14 |publication-date=14 January 2000}}
Title (published 14 January 2000). 2000-01-14.

The functionality is almost perfect: when the date is the same (and written down in the same date format), only one date is displayed, just what I described below as the desirable MO. Perfect would have been if it was date-format independent. I'd really like to see that implemented for air-date too (even if only the almost-perfect MO can be implemented in the short run). --Francis Schonken (talk) 12:18, 23 April 2020 (UTC)

  • Re. "air-date", here's what I think it should do: if it only works for {{cite episode}} and {{cite serial}}, then for those two cite templates is should allow to record two different dates for the work: the production date in |date= and the date of airing in |air-date=. Example: Father Brown, 7th series, shows the date of "2018" in the credits, thus |date=2018 – all episodes of that series were however first aired in January 2019; thus |air-date=2019. That's however not how it works: only a single date can be mentioned in the cite template, only either |date= or |air-date= can be used: they are aliases when used in any of the templates in which they currently can be used. Imho the software should only consider them aliases when only one of the two is defined (in other words: "air-date" should define the "date", and the other way around, if no value is given for the other parameter – only when a different value is given to "date" and "air-date" should both values be accepted, and allowed to be different, which is not the case currently).
I think "publication-date" should work similarly for books and other printed works, or works published otherwise than by airing. In that case, "publication-date" and "air-date" could be aliases of the same parameter, working in the same way across all cite templates (which is not the case currently), e.g. for a Netflix serial it should be possible to use |publication-date= in the {{cite serial}} template as an equivalent of an "air-date" for a traditional broadcaster. Also books can be published in a different year than their nominal date: e.g., the Bach Yearbook of 1953 was published in 1954 ([1]).
If that's not possible, and all cite templates use only a single date, whether it's called "date", or "air-date" (for some templates), or "publication-date" (for some other templates), then we should be simplifying things and make all these date-related parameters aliases of the "date" parameter, instead of having different flavours of dates which are de facto all the same, but don't work the same across the cite templates.
Anyway, the current arrangement is a useless complexity. The cs1 template currently has 158 different unique parameters: getting rid of a few useless ones (which can be defined as simple aliases of the "date" parameter) should not be taking too much work to get sorted I suppose. --Francis Schonken (talk) 08:11, 9 April 2020 (UTC)
Citations concern published material (with very rare exceptions). They should provide the date a work became public, not the date it was produced/printed/recorded etc. Unless the publication date is unknown, in which case any available date can help in source discovery. Most source databases use the same criteria to index their content. 65.88.88.69 (talk) 20:08, 9 April 2020 (UTC)
The Bach Yearbook of 1953 is, in all reliable sources, referred to with the 1953 date (please find me one which doesn't!). Wikipedia does otherwise, because of the current limitations of the cite template. --Francis Schonken (talk) 22:27, 9 April 2020 (UTC)
From a citation perspective: |title=Bach Yearbook 1953, |date=1954, |series=[annual] is correct. Also, |title=Bach Yearbook, |date=1954,|series=[annual], |vol="1953" is correct. But anything that includes |date=1953 is not correct. Since the publication date is known, that is what should go there. should it not? 98.0.246.242 (talk) 01:41, 10 April 2020 (UTC)
As said, this is correct according to current limitations of Wikipedia's cite templates, but not how it is done in reliable sources. In the context of solid professional literature, Wikipedia's way of citing this high-profile scholarly edition is extremely weird. As said, find me one, one single source apart from Wikipedia, which refers to the Bach Yearbook of 1953 with the 1954 date. Afaik there is none. I could give you a few that use the 1953 date exclusively for referring to this publication.
My point is: there are 158 unique parameters for cite templates. None of these support referring to the Bach Yearbook of 1953 the way it is done in professional literature. If that's the way we want it for the Bach Yearbook, and for other cases such as the Father Brown series, I see no reason to keep and publication-date as separate parameters: they are exotic aliases of the date parameter (exotic while they can only be used in selected templates), and should rather be defined as simple straightforward aliases of that parameter, thus reducing the total number of unique parameters with two (result: 156 unique parameters, which is still more than enough for how the templates currently work). --Francis Schonken (talk) 06:39, 10 April 2020 (UTC)
The Wikipedia citation system is unique and should not be compared with any others except in very narrow, strictly technical aspects. It is the first general-purpose citation system of its kind, whose main target are non-expert, non-professional readers. Unlike other citation systems whose aim is to support expert synthesis or professional original research, the purpose here is much more basic. It is a tool to apply Wikipedia's verification policy. To help prove that whatever is claimed in wikitext actually exists, somewhere. Because the project is inherently unreliable, since it depends on anonymous contributors. No offense meant, but "Francis Schonken" means nothing to me, or most people (I imagine). You could have signed "Stephen Hawking" and none would be the wiser.
Because of the type of the intended consumers of Wikipedia citations, the guidelines of any systematic approach should be ease of understanding, ease of use, and accessibility. This is an open slate that should not depend on inscrutable custom. Or on the narrow requirements of a specific field whose practitioners use citations daily, are familiar with technical jargon, and implicitly understand the underlying concepts. Most of all it has to make sense. So when we want use a field that refers to the date the work became available to the public (because that is what is pertinent) we should put that particular date there. Only when the work cannot be discovered with such date, should a different date field come into play, perhaps with an explanation. Luckily, one of the great advantages of Wikipedia is the fact that there is no "house" system that one has to follow. You can format a citation any which way as long as it is understandable and relatively easy to verify. One of the best examples would be a footnote with the following: "I found This information is in the Bach Yearbook 1953, which was published in 1954 by so-and-so, in this location. Look in pages xxx-xxxx. This source can also be found by a commercial book identifier, which is so-and-so."
Other than that, I definitely agree that CS1 is way too complex as presently presented (without going into the technical and design issues lingering from the previous incarnation). It could be documented in a much more understandable fashion. 98.0.246.242 (talk) 15:30, 10 April 2020 (UTC)
Of course it should be compared with how reliable sources display references. Let's get back to basics: references, including cite templates "support core content policies such as WP:V" (as I wrote above on this page) – it is in the best interest of readers and editors that references are as recognisable as possible, resulting in an unhampered application of core content policies. "Recognisable" means that references should look, as much as possible, like the ones one encounters elsewhere, in reliable sources.
I'm not sure what you're actually proposing as an improvement to Citation Style 1 templates and their documentation. Just complaining that it is too complex is neither here nor there. I proposed a simplification: either it gets accepted (if enough editors support it and someone is prepared to implement it) or it doesn't. If it doesn't get accepted, and the complexity is retained, I proposed to put it to better use – same for that option: either it is supported by other editors, and gets implemented, or it isn't.
I'm well aware how references can be written without cite templates, and what the principle behind WP:SAYWHEREYOUGOTIT is. The latter is however part of another guidance page (which, FYI, I helped writing around 15 years ago when the <ref> system was first introduced in the software), with its own talk page if you want to suggest improvements, but not part of what is discussed on this talk page, i.e. improvements to Citation Style 1 templates and their documentation. --Francis Schonken (talk) 09:27, 11 April 2020 (UTC)
I doubt that the average Wikipedia reader will be able to recognize any of the existing citation systems. Recognize in the sense of understanding how they are formatted, what they do, and what they and are there for. At most, they may get a vague idea that the strange paragraph is somehow related to the stuff that came before it. Here, the target audience is that type of relatively un-knowing reader. The minority who has an understanding of MLA, APA and all the other discipline-based systems is not the concern. They will know enough to pick their way through a Wikipedia citation no matter how it is formatted. But this citation system cannot be based on the disctinct minorities and their respective favorites, created to fit their particular disciplines. It is not comparable in philosophy or purpose, and the implementation should reflect that. As expected, and unfortunately, a lot of the people involved in this application of citations have prior knowledge of the specialist citation systems, and this apparently hampers their ability to develop a simple general-purpose system. It doesn't have to, but it does.
This has nothing to do with WP:SAYWHEREYOUGOTIT, I was using an example as illustration. It is also irrelevant whether "Francis Schonken" contributed to that discussion, and is now contributing to this one, even if it is the same (real) person in both cases. This is simply about presenting citations in a way that makes sense to people who are ignorant on the subject. The common-sense expectation would be for a publication date, and only a publication date, to be in the publication date field.
I have commented on CS1, templates, and citations in general for many, many years, so forgive me for not wanting to revisit specifics. Previously (pre-Lua) the confusion, beside the technical issues, was mostly the result of diversity: many templates were part of the collection only in name and technical base ({{citation/core}}). The presentation was all over the place. In this incarnation we have uniformity and good attempts at consistency, but there are glaring omissions, in both design, logic, and user interface. The underlying code naturally will evolve to be more complex or more abstract or both, that is fine. It is the presentation that should be going in the opposite direction. Having "experts" decide on the formatting is not helping. Unless the experts can approach this as non-experts, and apply their expertise on that approach. 98.0.246.242 (talk) 16:09, 11 April 2020 (UTC)

Still not sure what you're trying to accomplish. Seems to be going nowhere. Someone blogging about their philosophies.

I proposed some practical steps. I can't even figure out whether you support them or not, as you rather seem to steer for inactivity w.r.t. practical problems, and w.r.t. practical solutions.

Whether average Wikipedia readers (which don't even exist) can understand citations is not the question. What is clear, on the other hand, is that citation systems close to those found elsewhere would usually be more comprehensible than those less close to what is found elsewhere (duh!). So comparison is useful and, of course, practical. --Francis Schonken (talk) 20:47, 11 April 2020 (UTC)

Well, it is simple. Your original complaint about not being able to enter two different dates (production date and air date) on the same citation template is not in my opinion actionable. The subsequent discussion followed from there. 98.0.246.242 (talk) 02:18, 12 April 2020 (UTC)
There was no "complaint". There were two completely different suggestions, which are either... or... The first is as "actionable" as the second. Just say which one you like most, and take it from there. --Francis Schonken (talk) 05:51, 12 April 2020 (UTC)

Category:CS1 errors: DOI

Why is Wikipedia:Teahouse/Questions/Archive 587 in that category? That page wasn't edited in years, and had never been in there before. Headbomb {t · c · p · b} 21:33, 22 April 2020 (UTC)

Registrant portion less than 4 digits without subcode. Likely cause for it's sudden appearance is that MediaWiki finally got round to refreshing that page.
—Trappist the monk (talk) 22:00, 22 April 2020 (UTC)
How pages are purged when templates are updated, and the job queue, work in mysterious ways, is the short answer. Of course, it should be obvious the triggering citation (for which |template-doc-demo= looks appropriate). --Izno (talk) 22:02, 22 April 2020 (UTC)
I bypassed the error by updating the doi to 10.1234/1234. Headbomb {t · c · p · b} 12:31, 23 April 2020 (UTC)

Mode marker?

Thinking out loud, would there be a way for templates to emit a "mode" marker of some type? E.g. something like

  • <cite class="citation cs1">...
  • <cite class="citation cs2">...

This would allow for scripts to be designed to identify which citations are in CS1/CS2 styles at a glance. This could also be used for people who only want to be warned of User:Ucucha/HarvErrors.js-type of warnings in CS2 templates for whatever reason. Headbomb {t · c · p · b} 14:39, 21 April 2020 (UTC)

Already exists in a slightly different form. All cs1 templates include their name or a hyphenated variant of their name (without the cite prefix) as part of the class= attribute. {{citation}} does not.
{{citation}}:
'"`UNIQ--templatestyles-000000CA-QINU`"'<cite class="citation cs2">''Title''</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>
{{cite av media notes}}:
'"`UNIQ--templatestyles-000000CC-QINU`"'<cite class="citation AV-media-notes cs1">''Title'' (Media notes).</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Title&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>
—Trappist the monk (talk) 15:09, 21 April 2020 (UTC)
@Trappist the monk: probably something that should be refined then since CS1 sub-classes proliferate at a rather rapid pace, and that CS2 aren't explicitly marked as such.
  • <cite class="citation cs1 AV-media-notes">...
  • <cite class="citation cs2">...
The above would greatly facilitate script development. Headbomb {t · c · p · b} 15:26, 21 April 2020 (UTC)
@Trappist the monk: also, CS1/CS2 isn't marked if you have something like {{cite av media notes|title=Title|mode=cs2}} or {{citation|title=Title|mode=cs1}}. Headbomb {t · c · p · b} 16:09, 21 April 2020 (UTC)
Is there a script in development? I don't know what you mean by CS1 sub-classes proliferate at a rather rapid pace. That CS2 [isn't] explicitly marked is in itself explicit marking because there is only one cs2 template: {{citation}}. Yes, |mode= is not announced in the class= attribute.
—Trappist the monk (talk) 16:15, 21 April 2020 (UTC)
There's none in development now but I would make one if this was there. Headbomb {t · c · p · b} 17:43, 21 April 2020 (UTC)

@Trappist the monk: What I meant by CS1 sub-classes proliferate at a rather rapid pace is that CS1 templates are created relatively often, so a script that relied on detecting the "AV-media-notes" "journal", etc... classes would need to be maintained to have its list of classes up to date, instead of relying on something more dependable like an explicit CS1 class. And yes, there is only one template that is CS2 style natively, but if you have something like {{cite journal|mode=cs2}} or {{citation|mode=cs1}}, those couldn't be recognized as CS2 or CS1 styles from their classes. Hence the need for the explicit CS1/CS2 class. Headbomb {t · c · p · b} 16:01, 22 April 2020 (UTC)

In the sandbox:
{{citation/new |title=Title}}
'"`UNIQ--templatestyles-000000D6-QINU`"'<cite class="citation cs2">''Title''</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>
{{citation/new |title=Title |mode=cs1}}
'"`UNIQ--templatestyles-000000D9-QINU`"'<cite class="citation cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>
{{citation/new |title=Title |mode=cs2}}
'"`UNIQ--templatestyles-000000DC-QINU`"'<cite class="citation cs2">''Title''</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>
{{cite book/new |title=Title}}
'"`UNIQ--templatestyles-000000DF-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>
{{cite book/new |title=Title |mode=cs1}}
'"`UNIQ--templatestyles-000000E2-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>
{{cite book/new |title=Title |mode=cs2}}
'"`UNIQ--templatestyles-000000E5-QINU`"'<cite class="citation book cs2">''Title''</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fwiki.riteme.site%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>
I may undo this change in a little while because this single change makes every test in Module talk:Citation/CS1/testcases fail.
—Trappist the monk (talk) 22:24, 22 April 2020 (UTC)
Undone with notes to restore at next module suite update.
—Trappist the monk (talk) 15:04, 23 April 2020 (UTC)

long-standing cite encyclopedia TODO

For a long time, there has been a TODO in Module:Citation/CS1/Configuration with respect to |encyclopedia=, |encyclopaedia=, and |dictionary=. These parameters have, for that long time, been masquerading as periodical parameters. This was an expedient used to properly format the value assigned to one of these three parameters in the rendering (because periodical parameters are italicized and the encyclopedia alias parameter values want to be italicized). But, these parameters aren't periodical parameters and don't belong in the periodical alias list. So I have done something about that in the sandbox.

In the sandbox, |encyclopedia=, |encyclopaedia=, and |dictionary= are now aliases of each other. Use of these parameters is restricted to {{cite encyclopedia}}, {{cite dictionary}} (merely a redirect to {{cite encyclopedia}}), and {{citation}}:

Cite book comparison
Wikitext {{cite book|encyclopedia=Encyclopedia|title=Title}}
Live Title. {{cite book}}: Unknown parameter |encyclopedia= ignored (help)
Sandbox Title. {{cite book}}: Unknown parameter |encyclopedia= ignored (help)
Cite book comparison
Wikitext {{cite book|encyclopedia=Encyclopedia|periodical=Periodical|title=Title}}
Live Title. {{cite book}}: |periodical= ignored (help); Unknown parameter |encyclopedia= ignored (help)
Sandbox Title. {{cite book}}: |periodical= ignored (help); Unknown parameter |encyclopedia= ignored (help)

Use of a periodical parameter without simultaneous use of a |encyclopedia= alias is allowed:

Cite encyclopedia comparison
Wikitext {{cite encyclopedia|title=Title|work=Work}}
Live Title. {{cite encyclopedia}}: |work= ignored (help)
Sandbox Title. {{cite encyclopedia}}: |work= ignored (help)

but simultaneous use is not:

Cite encyclopedia comparison
Wikitext {{cite encyclopedia|encyclopedia=Encyclopedia|title=Title|work=Work}}
Live "Title". Encyclopedia. {{cite encyclopedia}}: |work= ignored (help)
Sandbox "Title". Encyclopedia. {{cite encyclopedia}}: |work= ignored (help)

The template is still peculiar with respect to the other cs1|2 templates as it always has been:

Cite encyclopedia comparison
Wikitext {{cite encyclopedia|encyclopedia=Encyclopedia|title=Title}}
Live "Title". Encyclopedia.
Sandbox "Title". Encyclopedia.
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|encyclopedia=Encyclopedia|entry=Entry}}
Live "Entry". Encyclopedia.
Sandbox "Entry". Encyclopedia.
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|entry=Entry|title=Title}}
Live "Entry". Title.
Sandbox "Entry". Title.
Cite encyclopedia comparison
Wikitext {{cite encyclopedia|encyclopedia=Encyclopedia|entry=Entry|title=Title}}
Live "Entry". Title. Encyclopedia.
Sandbox "Entry". Title. Encyclopedia.

—Trappist the monk (talk) 19:12, 24 April 2020 (UTC)

contribution TODO

A TODO added to the module suite just before the last update is to remove redundant alias listing for |contribution=. In the live module, |contribution= is an equal alias of |chapter=. |contribution= also feeds a separate metaparameter Contribution. I have done this in the sandboxen

|contribution= when used without |contributor= is an equal alias of chapter:

Cite book comparison
Wikitext {{cite book|contribution=Contribution|title=Title}}
Live "Contribution". Title.
Sandbox "Contribution". Title.
Cite book comparison
Wikitext {{cite book|chapter=Chapter|title=Title}}
Live "Chapter". Title.
Sandbox "Chapter". Title.

As an equal alias, only one of |contribution= and another |chapter= alias is permitted in a cs1|2 template:

Cite book comparison
Wikitext {{cite book|chapter=Chapter|contribution=Contribution|title=Title}}
Live "Chapter". Title. {{cite book}}: More than one of |contribution= and |chapter= specified (help)
Sandbox "Chapter". Title. {{cite book}}: More than one of |contribution= and |chapter= specified (help)

Does the right thing when combined with |contributor=:

Cite book comparison
Wikitext {{cite book|author=Author|contribution=Contribution|contributor=Contributor|title=Title}}
Live Contributor. "Contribution". Title. By Author. {{cite book}}: |author= has generic name (help)
Sandbox Contributor. "Contribution". Title. By Author. {{cite book}}: |author= has generic name (help)

This change fixes an issue with simultaneous use of |contributor=, |contribution=, and another |chapter= alias:

Cite book comparison
Wikitext {{cite book|author=Author|chapter=Chapter|contribution=Contribution|contributor=Contributor|title=Title}}
Live Author. "Chapter". Title. {{cite book}}: |author= has generic name (help); |contributor= requires |contribution= (help); More than one of |contribution= and |chapter= specified (help)
Sandbox Author. "Chapter". Title. {{cite book}}: |author= has generic name (help); |contributor= requires |contribution= (help); More than one of |contribution= and |chapter= specified (help)

—Trappist the monk (talk) 14:07, 25 April 2020 (UTC)

mailinglist TODO

A TODO added to the module suite just before the last update is to disentangle |mailinglist= from the Periodical alias list. In the live module, |mailinglist= (but not its alias) is an equal alias of |work=, |newspaper=, etc. This was a programmer's expedient to ensure that the value assigned to |mailinglist= is properly italicized or, more likely, a programmer's oversight. I have done this in the sandboxen.

|mailing-list= is not required but I wonder if it should be:

Cite mailing list comparison
Wikitext {{cite mailing list|title=Title|url=//example.com}}
Live "Title" (Mailing list).
Sandbox "Title" (Mailing list).

ignores other Periodical parameters; perhaps it should emit an ignored param message:

Cite mailing list comparison
Wikitext {{cite mailing list|title=Title|url=//example.com|work=Work}}
Live "Title" (Mailing list).
Sandbox "Title" (Mailing list).

works as it did before:

Cite mailing list comparison
Wikitext {{cite mailing list|mailinglist=Mailinglist|title=Title|url=//example.com}}
Live "Title". Mailinglist (Mailing list). {{cite mailing list}}: Unknown parameter |mailinglist= ignored (|mailing-list= suggested) (help)
Sandbox "Title". Mailinglist (Mailing list). {{cite mailing list}}: Unknown parameter |mailinglist= ignored (|mailing-list= suggested) (help)

now emits a redundant param message when extra work param present; perhaps it should emit the ignored param message instead:

Cite mailing list comparison
Wikitext {{cite mailing list|mailing-list=Mailinglist|title=Title|url=//example.com|work=Work}}
Live "Title". Mailinglist (Mailing list). {{cite mailing list}}: More than one of |work= and |mailinglist= specified (help)
Sandbox "Title". Mailinglist (Mailing list). {{cite mailing list}}: More than one of |work= and |mailinglist= specified (help)

—Trappist the monk (talk) 16:04, 25 April 2020 (UTC)

identifier limits

At the last module suite update limits for those identifiers for which we have established limits, were moved from the identifier validation functions in ~/Identifiers into a table id_limits{} in ~/Configuration. I don't know what I was thinking when I did that. Each identifier has its own handler table and that is where the identifier limits belong. I have moved them

Title. PMC 7500000.
Title. PMC 7500001.
Title. PMID 33000000.
Title. PMID 33000001.
Title. SSRN 4000000.
Title. SSRN 4000001.
Title. S2CID 23000000.
Title. S2CID 230000001.

When I did this, I discovered a minor flaw in the s2cid error checking. |s2cid=1 is a valid corpus ID. But ...

Cite book comparison
Wikitext {{cite book|s2cid=1|title=Title}}
Live Title. S2CID 1.
Sandbox Title. S2CID 1.

Fixed in the sandbox.

—Trappist the monk (talk) 18:22, 25 April 2020 (UTC)

Help with news article subtitle?

I'm trying to quote this article. It has a title ("U.S. Navy Rescue Pleases Moscow") and a sub-title ("Finding of 4 Russians Adrift in Pacific Brings Wave of Goodwill to Americans"). How do I go about that? I don't see a separate "sub-title" parameter. Do I put everything in the title using colon? Do I just drop a subtitle? -- Wesha (talk) 18:46, 25 April 2020 (UTC)

See also #Subtitles above. Re. "Do I put everything in the title using colon?" – yes, that is: if you think it best to include the subtitle for the purposes of where the cite template will be used. --Francis Schonken (talk) 18:52, 25 April 2020 (UTC)

Allow direct invocation of Module:Citation/CS1

On many of the COVID-19 articles, we're facing an issue where the references alone are getting to the point where they are causing the pages to exceed the post-expand include size. This has also been an issue on other pages with lots of citations (I know Cristiano Ronaldo faced this in the past). One common solution is to hardcode the references instead of using a template, but that is less than optimal. Another solution I'm proposing would be to allow the citation module to be called directly, because calling a template like {{cite web}} that then invokes the module causes the sizes of all the citations to be counted twice. I mocked this up by uncommenting line 3821 here. A module could be created at Module:Cite (based on Module:Sandbox/Ahecht/Cite) to call Module:Citation/CS1. Citation heavy articles could then use, for example, {{#invoke:Cite|web| or {{#invoke:Cite|news|, which wouldn't double-count the bytes in the reference, instead of {{Cite web| or {{Cite news|, to reduce post-expand include size. --Ahecht (TALK
PAGE) 00:11, 25 April 2020 (UTC)

Where's an example where you are running into expansion limits? Headbomb {t · c · p · b} 00:14, 25 April 2020 (UTC)
Last time I checked it about a week ago one of the affected articles was 2019–20 coronavirus pandemic. --Matthiaspaul (talk) 00:51, 25 April 2020 (UTC)
@Headbomb and Matthiaspaul: That was the most recent example. A large part of that is due to the citations in {{2019–20 coronavirus pandemic data}}, which total approximately 450kB by themselves. Compare that to {{2019–20 coronavirus pandemic data/sandbox}}, which uses {{#invoke:Sandbox/Ahecht/Cite|web}} and {{#invoke:Sandbox/Ahecht/Cite|news}}, which has a post-expand include size that is over 200kB smaller. --Ahecht (TALK
PAGE) 03:01, 25 April 2020 (UTC)
Confirmed. To take all of the other stuff out of the picture, I did an experiment with Module:Lang which is configured to be called from other modules. I created a blank mainspace page with a nonsense name and previewed it:
  • blank → Post‐expand include size: 0/2097152 bytes
Then I added a single {{lang-es}} template, previewed (repeated for 100× and 1000×) {{lang-es|mi casa su casa}}:
  • 1× → Post‐expand include size: 232/2097152 bytes
  • 100× → Post‐expand include size: 23200/2097152 bytes
  • 1000× → Post‐expand include size: 232000/2097152 bytes
I did the same tests using direct invoke {{#invoke:lang|lang_xx_italic|code=es|mi casa su casa}}:
  • 1× → Post‐expand include size: 116/2097152 bytes
  • 100× → Post‐expand include size: 11600/2097152 bytes
  • 1000× → Post‐expand include size: 116000/2097152 bytes
As a follow-up, I compared the 100× versions of both. Both have the same html for the template output; each has 100 of:
  • <a href="/wiki/Spanish_language" title="Spanish language">Spanish</a>: <i lang="es">mi casa su casa</i>
All of this suggests to me that there is a flaw in how MediaWiki counts bytes when calculating post-expand include size.
Your next stop, I think, is phabricator.
—Trappist the monk (talk) 11:23, 25 April 2020 (UTC)
This is a known issue since a decade and more ago. It didn't need confirmation... --Izno (talk) 15:08, 25 April 2020 (UTC)
@Trappist the monk: The double counting isn't a flaw, it's by design. See phab:T15260 (tstarling is Tim Starling, the Lead Platform Architect for MediaWiki). The intention was to force more native usage of Lua, which is more efficient from a server standpoint than multi-level nested templates. --Ahecht (TALK
PAGE) 19:15, 25 April 2020 (UTC)
It seems odd that a limit that was justified ten years ago as a way to limit processing time has not been increased to account for increases in processor speed. I am probably misunderstanding. – Jonesey95 (talk) 20:35, 25 April 2020 (UTC)
I'm sure that I'm misunderstanding something. Apparently that was pre-lua days, it was pre-parsoid days. But, tstarling appears to be saying that once we have lua and parsoid then reducing parsing limits should be considered. I don't really know what that means. But, we have lua and we have parsoid so was reducing parsing limits considered? What was the result of that consideration?
But, regardless, if double counting a template wrapper around an invoke is how the system is designed, then we should not be gaming that system to eke a little more time by patching this and patching that before an oversize article finally collapses under its own weight and must be split or severely pruned. I am also concerned that the {{#invoke:cite|web|<params...>}} construct will just confuse editors who already complain that cs1|2 is too complex to be understood. Is that construct editable by editors who use ve?
—Trappist the monk (talk) 22:04, 25 April 2020 (UTC)
@Trappist the monk: It's not gaming the system. Avoiding nested templates is exactly what the system was designed to encourage. Also, the syntax is a bit simpler than in your example (unless I'm misunderstanding your notation). For example, {{Cite web|url=https://wiki.riteme.site|title=Wikipedia|accessdate=24 April 2020|publisher=Wikipedia Foundation}} would become {{#invoke:Cite|web|url=https://wiki.riteme.site|title=Wikipedia|accessdate=24 April 2020|publisher=Wikipedia Foundation}}. It is editable by visual editor (see this edit in my sandbox, or try editing my sandbox yourself with VE). And just to clarify, this usage would not be widespread, only a tiny handful of pages would ever need to use it. --Ahecht (TALK
PAGE) 23:43, 25 April 2020 (UTC)
I don't think this is a good idea if applied in a piecemeal fashion or in some specific cases. It could create variance in the application of CS1 among, or even within pages. One more thing to be (perhaps poorly) explained. It would make more sense for it to be universally applied, or not at all. Let's keep in mind that there are very few (mainly one) persons maintaining an increasingly complex system. As Trappist suggested, a far simpler solution would be to split the article. As for the phab discussion linked above, tstarling seems to be saying that since the introduction of lua and the new parser would supposedly reduce the parsing resources required, it would make sense to decrease the parsing limits in the new (current) system. Note the linked phab discussion, that proposes an opposite direction. And here we are several years later. 98.0.246.242 (talk) 00:35, 26 April 2020 (UTC)
Misplaced </nowiki>.
The goal of this exercise appears to be an attempt to hold off the inevitable. The articles are growing. They will continue to grow until someday after editors have run out of tweaks and patches, the articles will just be too large. Making tweaks and patches to hold off the inevitable is what I meant by gaming the system. I know, this is hard, editors don't like to split split articles.
—Trappist the monk (talk) 11:48, 26 April 2020 (UTC)

dab

Hi! Currently it says for date: Date of source being referenced. I think this is a bit ambiguous and could be interpreted as the date when you reference the source. I think better wording would be Date of publishing of the source or something to that effect. 2001:14BA:9C0B:A700:0:0:0:8EA (talk) 09:30, 25 April 2020 (UTC)

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Can't find it. :\ Aasim 09:55, 25 April 2020 (UTC)
"Not done" stroken for procedural reasons.
Aasim, this is a talk page for citation templates and the right place to make suggestions how to improve them or their documentation. This is open for anyone. You can voice your opinion like anyone, but you are not to decide if or if not something gets done. Therefore the usage of "Not done" is inappropriate and comes over as presumptuous and rude, in particular as the OP's request was genuinely friendly and constructive (and also quite sensible). So, there was not the slightest reason to reply as if the user would have done a mistake. Please WP:DONTBITE our newcomers.
Further, no reliable sources (WP:RS) are needed for someone to propose an improment. Finally, the OP even suggested an improved wording, so, putting the tone issues aside, your reply was inappropriate even on purely technical grounds.
--Matthiaspaul (talk) 12:25, 25 April 2020 (UTC)
Dear IP, thanks for your suggestion, you have a good point here. The phrase "Date of source being referenced" is somewhat misleading and could probably be improved. As the |date= parameter typically holds the publication date of the specific version/edition cited (and not the |access-date=, which is used for the date when the source was read), your replacement suggestion "Date of publishing of the source" is more to the point in most cases. However, there are a number of corner cases, where the parameter is used in a wider sense: For example, in some cases, there might be a difference between a limited-audience publication and one which is open for the general public. Similar, there might be a significant difference between an original publication date and an (identical) reissue much later. Some sources provide a "last edit", "filing" or "print" date rather than a publication date. Sometimes, multiple such dates are given - in this case the |orig-year= parameter can be used to specify them.
This inherent ambiguity is the reason why the wording in the help was left somewhat vague in regard to the type of date to use for the |date= parameter, and your suggestion "Date of publishing of the source", although correct for most cases, might already be a bit too specific for the general case.
To just better distinguish |date= from |access-date= perhaps "Date of referenced source" would already do the job?
Alternatively, to solve the underlying issue, we could either explain all this in detail in the help, or introduce more specific date parameters (like f.e. |reissue-date=, |publication-date=, |print-date=, |filing-date=, |edit-date=, ...) for the different types of date (of which only one would be used most of the time). The newest given date would then have to be treated as an alias for |date=, whereas the other date(s) would have to be aliases for (or be combined with) |orig-year=. So, this would not change much in the template's visible output, but help plausibility checks when later editors would run into what looks like the same source being referenced with a different date somewhere else (this would increase the level of trust we could put into a citation, and might also be useful to improve future, more specific types of metadata).
--Matthiaspaul (talk) 12:25, 25 April 2020 (UTC)
Hi Matthiaspaul! I see the challenge. Your suggestion Date of referenced source sounds good to me. And perhaps a link to somewhere which describes the intricacies of the situation and the other parameters. Many "normal people" apparently find the use of templates hard. Thus it's very important I think that the documentation is as crystal clear as possible without losing the real world complexity. As Albert Einstein supposedly said "Everything should be made as simple as possible, but no simpler". Stay safe amigo! 2001:14BA:9C0B:A700:0:0:0:8EA (talk) 12:15, 26 April 2020 (UTC)

section TODO

Another TODO added just before the last module suite update.

|section= is an alias of |chapter=. It is also used by {{cite map}} as an in-source location parameter. When {{cite map}} is used to cite a map in a book, |chapter= (and aliases – except |section=) is ignored and |map= is used in its place. In the live version of the module suite, there are two references to |section= in the ~/Configuration aliases table. This change removes the separate Section metaparameter.

Normal sort of operation:

Cite map comparison
Wikitext {{cite map|map=MAP|section=B3|title=Title}}
Live "MAP" (Map). Title. § B3.
Sandbox "MAP" (Map). Title. § B3.

and with redundant parameters:

Cite map comparison
Wikitext {{cite map|chapter=Chapter|map=MAP|section=B3|title=Title}}
Live "MAP" (Map). Title. {{cite map}}: More than one of |map= and |chapter= specified (help); More than one of |section= and |chapter= specified (help)
Sandbox "MAP" (Map). Title. {{cite map}}: More than one of |map= and |chapter= specified (help); More than one of |section= and |chapter= specified (help)

—Trappist the monk (talk) 19:05, 26 April 2020 (UTC)

template-specific arguments table for cite map

Like those created for {{cite episode}}, {{cite newsgroup}}, and {{cite serial}}, in ~/Whitelist/sandbox I have created a table for arguments that are exclusively used by {{cite map}}.

—Trappist the monk (talk) 21:54, 26 April 2020 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Help_talk:Citation_Style_1/Archive_65&oldid=984451097"