Help talk:Citation Style 1/Archive 65

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)
 * 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 . 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 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   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.
 * 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   table with the canonical parameter name listed first.  Some snippet of module code somewhere would be necessary to read   and extract the canonical and alias names for each particular metaparameter and provide these names to  and its subordinate templates.
 * At the moment, I cannot think of a reason why one of Title or  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)
 * appears unsuccessful in defining a full parameter set at Template:Citation Style documentation, nor is there a usable basis at Template:Citation Style documentation. 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)
 * 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:
 * If is unsuccessful, make it successful.  That template is only semi-protected so you have the necessary rights to edit it.
 * 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)
 * 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: --Francis Schonken (talk) 21:43, 4 April 2020 (UTC)
 * 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.

Continuation of "full parameter set" topic
For the sake of curiosity, I've hacked some code. This:

returns this list:

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

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

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

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

But this, because there are no aliases for Agency, returns:
 * → (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  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 is unsuccessful, make it successful" – my question was rather, is  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, the "Full parameter set in horizontal format" (currently: ) 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
 * Step 3 would be to do step 1 at Template:Cite book/doc, 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  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:
 * Because of this tweak, I have noticed that the  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  and exclude chapter from a listing at  for example.
 * —Trappist the monk (talk) 14:18, 5 April 2020 (UTC)
 * 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  and exclude chapter from a listing at  for example.
 * —Trappist the monk (talk) 14:18, 5 April 2020 (UTC)
 * —Trappist the monk (talk) 14:18, 5 April 2020 (UTC)

Proposing further intermediary steps for the first step: --Francis Schonken (talk) 12:48, 5 April 2020 (UTC)
 * 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
 * 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   currently has:
 * canonical:
 * aliases: (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)
 * 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 which is fine for  but not so fine for  or  so for those we want something else. So, I've added an override parameter. For the doc page we would write:

for

—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:

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.
 * For contribution that parameter name is required in (and  when none of the work aliases have a value) when contributor has a value.
 * Having contribution as a separate parameter in the  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   table.
 * —Trappist the monk (talk) 15:45, 6 April 2020 (UTC)
 * "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   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): --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) author-related:  ...
 * not included: "authors" (not adopted in COinS metatdata)
 * 1) editor-related: ... ...
 * not included: "editors" (not adopted in COinS metatdata)
 * 1) title-, web-, chapter-, type- and journal-related: ... ...
 * not included: "title-link" (redundant)
 * chose "work" instead of its alias "website"
 * 1) edition-, series-, event-, agency- and volume-related: ... ...
 * 2) date-related: ... ...
 * 3) publisher- and language-related: ... ...
 * not included: "publisher-link" (redundant)
 * chose "location" instead of its alias "place"
 * 1) pages- and time-related: ... ...
 * 2) id-related: ... ...
 * 3) url-, chapterurl-, lay-, quote- and ref-related: ... ...
 * 4) display-related: ... ...
 * 5) access-related: ... ...
 * 6) interview-related: ... ...
 * 7) season- and network-related: ... ...
 * 8) transcript- and conference-related: ...
 * [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 ; departments of a newspaper (sports, local, ...); like agency should probably be ignored by
 * [4] If these parameters that you've listed are for, 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:
 * [1] In the full parameter set of the book template's doc the author-related block (Template:Cite book/doc) is separated from the editor-related block (Template:Cite book/doc) by date- and chapter-related parameters. Not sure whether we'd want to keep it like that for that implementation of the Citation Style documentation, but not merging both blocks keeps options open.
 * [2] See Template:Citation Style documentation which explains the parameter under "Options for this field"; In #5 it was an unintended double, so I removed it there.
 * [3] "title_title" from Template:Citation Style documentation; "type_default" from Template:Citation Style documentation. In both cases listed under "Options for this field". "title-link" is redundant to wikilinking the title in the "title" parameter (which is not literally the same as an alias parameter, but a more efficient method to do the same, without using a parameter). "contribution-url" is apparently an alias of "chapter-url", so I removed it from #3. "department" from Template:Citation Style documentation "Options ...". Seems you misunderstand the exercise: this one is for Template:Citation Style documentation (as you recommended to do first) – not for any of the individual cite templates. See "Plan" above, this is the first sub-step of the first step. Doing this for cite book would be step 3.1, still around a dozen of substeps before we're there. cite news isn't even listed yet, so would be step 9.1 at the earliest. Keeping options open for these further steps is recommended, making this a mishmash of all current and future steps is not.
 * [4] They're not (they are for Template:Citation Style documentation), see [3].
 * [5] Template:Citation Style documentation, "Options ..."
 * [6] Not according to the current versions of Template:Citation Style documentation and Template:Citation Style documentation
 * [7] I used the subsection names as currently available at Template:Citation Style documentation – see intro of the current talk page subsection above. None of these names will of course be retained in the "Full parameter set in horizontal format", these are just temporary devices so that anyone can follow where I got it.
 * [8] The proposal is not complete yet, but for the naming I'll continue the scheme as explained in previous point.
 * --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 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 (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  ?  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)
 * [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 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 (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  ?  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)
 * "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:
 * – added to #14 (addition to #5 might have been possible too); needs to be documented at Citation Style documentation --Francis Schonken (talk) 08:33, 7 April 2020 (UTC)
 * A semi-alias of date and used only by and ; when both are present in a template, air-date yields silently to date.  This parameter isn't much used; could probably be deprecated and deleted.   and  docs updated.
 * —Trappist the monk (talk) 22:29, 7 April 2020 (UTC)
 * and added to #9, and all parameters of that section re-sorted; these two additional parameters still need to be documented at Citation Style documentation --Francis Schonken (talk) 09:08, 7 April 2020 (UTC)
 * archive-format and lay-format added to
 * —Trappist the monk (talk) 00:07, 10 April 2020 (UTC)
 * – not retained in current full parameter set proposal: not sure what this parameter does, whether it is implemented for any cite template (e.g. apparantly unused in, and at least undocumented for, cite book). Should be documented at Citation Style documentation, if anyone knows what it can be used for. --Francis Schonken (talk) 09:23, 7 April 2020 (UTC)
 * Used with ; is the title of the proceedings which leaves title available for the title of the conference paper/presentation. This template has needed rewriting since forever.
 * —Trappist the monk (talk) 14:12, 7 April 2020 (UTC)
 * – similarly, not retained in current full parameter set proposal: anyone knowing what it is or what it does? Module:Citation/CS1/Configuration suggest it has something to do with arxiv, but it is not documented anywhere at Citation Style documentation (where it should normally be in the Template:Citation Style documentation section if it has anything to do with arxiv). --Francis Schonken (talk) 10:36, 7 April 2020 (UTC)
 * Exclusively used by and documented there.
 * —Trappist the monk (talk) 14:12, 7 April 2020 (UTC)
 * – added to proposal (#15); currently undocumented in documentation template: should probably best be documented at Template:Citation Style documentation. --Francis Schonken (talk) 10:43, 7 April 2020 (UTC)
 * and – added to proposal (#1; also: name of "contributor" parameter changed to "contributor-last1"); should be documented in the documentation template, and possibly the canonised form of  changed to "contributor-last#". --Francis Schonken (talk) 12:11, 7 April 2020 (UTC)
 * If the canonized form for this one changes then the same change should be made for the editor, interviewer, and translator parameter names.
 * —Trappist the monk (talk) 14:12, 7 April 2020 (UTC)
 * contributorn (and variants and related) and contributor-linkn (and variants) are documented. Does not display at  because these parameters are used for book cites only ( and ).  contributor-maskn added to
 * —Trappist the monk (talk) 13:48, 10 April 2020 (UTC)
 * , and  – added to proposal (#10); needs to be mentioned in documentation. --Francis Schonken (talk) 12:11, 7 April 2020 (UTC)
 * – couldn't find any documentation, not retained in full parameter set proposal: does anyone know what this is for? --Francis Schonken (talk) 12:36, 7 April 2020 (UTC)
 * as an alias of type.
 * —Trappist the monk (talk) 14:12, 7 April 2020 (UTC)
 * and – added to #13 (or should that better be added in #10?); should best be mentioned in documentation. --Francis Schonken (talk) 12:36, 7 April 2020 (UTC)
 * – what is it? what is it for? No documentation found, not retained in full parameter set proposal. Can someone add a description for this parameter to the documentation template? --Francis Schonken (talk) 12:41, 7 April 2020 (UTC)
 * Also in where it is locally tacked on to the csdoc id1 rendering
 * —Trappist the monk (talk) 14:12, 7 April 2020 (UTC)
 * – as previous, unexplained in doc, not retained, someone please explain/update doc . --Francis Schonken (talk) 12:45, 7 April 2020 (UTC)
 * Associated with pmc and documented at Id2.
 * —Trappist the monk (talk) 14:12, 7 April 2020 (UTC)
 * Oops, should have double-checked: added, and documentation was indeed OK all the time. --Francis Schonken (talk) 14:32, 7 April 2020 (UTC)
 * and – added to #12, needs to be documented. --Francis Schonken (talk) 14:20, 7 April 2020 (UTC)
 * Also and  need documentation.   only.
 * —Trappist the monk (talk) 14:28, 7 April 2020 (UTC)
 * Likewise, and : these two already added to full set proposal. --Francis Schonken (talk) 14:40, 7 April 2020 (UTC)
 * "section", as a map-related parameter (?), doubles with one of the aliases of the "chapter" parameter, so omitted from the full set proposal for the time being; on the other hand added & sorted, but needs to be better documented. --Francis Schonken (talk) 14:50, 7 April 2020 (UTC)
 * section in is identifies a location on the cited map; section in a non-periodical template identifies a section of a larger work akin to the chapter of a book (chapter);  does not accept any of the chapter aliases except section in this special use.  TODOs added to tweak the code to remove the separate   key from the   table.
 * —Trappist the monk (talk) 17:10, 7 April 2020 (UTC)
 * – added to #14 (or should it rather have been added to #4?); documentation required. --Francis Schonken (talk) 15:00, 7 April 2020 (UTC)
 * Removed "number" from #14, for its doubling as an alias of "issue". --Francis Schonken (talk) 16:39, 7 April 2020 (UTC)
 * – added to #15; needs doc. --Francis Schonken (talk) 15:29, 7 April 2020 (UTC)
 * Removed three aliases of "chapter-url-access" from #11; also, from the same, "bibcode-access", "doi-access", "jstor-access", "ol-acces" and "osti-access" (not really parameters? – defined as "custom_access" in the id_handlers list of Module:Citation/CS1/Configuration, but not listed in the "canonical_param_lister" above). --Francis Schonken (talk) 19:03, 7 April 2020 (UTC)
 * id-access parameters added to the list of canonical parameters. There are no metaparameters for these so they are accessed through the doc support module with uppercase id concatenated with 'access':
 * BIBCODEaccess →
 * DOIaccess →
 * HDLaccess →
 * JSTORaccess →
 * OLaccess →
 * OSTIaccess →
 * S2CIDaccess → – new in the sandboxen so not yet available
 * There are no aliases for these parameters so:
 * →← (empty string)
 * —Trappist the monk (talk) 21:30, 7 April 2020 (UTC)
 * OK, (re-)added "bibcode-access", "doi-access", "hdl-access", "jstor-access", "ol-access" and "osti-access" to the full set proposal, and to the 1.0 table. That table now has a total of 158 known unique parameters. Would that be "complete", as in totally and utterly complete all parameters (& their aliases) currently (i.e. not counting sandbox ones) accepted by any (i.e. at least one) of the Citation Style 1 cite templates? --Francis Schonken (talk) 03:06, 8 April 2020 (UTC)
 * I suspect that the list is now complete. Every parameter, canonical and alias, used by cs1|2 must be listed in Module:Citation/CS1/Whitelist.  Checking your list against the whitelist will answer the question.
 * —Trappist the monk (talk) 11:33, 8 April 2020 (UTC)
 * Regrouped #10. --Francis Schonken (talk) 05:32, 8 April 2020 (UTC)
 * Regrouped #10. --Francis Schonken (talk) 05:32, 8 April 2020 (UTC)

1.2 – 1.3 aliases and canonical
This is what the horizontal proposal looks like at the end of substep 1.1:



Started to add background colours in the table of 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. is a canonical name, for clarity reasons the proposal above uses the first of these two aliases:. 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 &lt;param name>-first parameters that do not have a matching &lt;param name>-last?  If so, which?
 * —Trappist the monk (talk) 13:33, 14 April 2020 (UTC)
 * —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)
 * 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 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.", 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:
 * 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   and   we should use them in  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 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   and   in the  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:
 * non-canonical alias:
 * 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 :
 * I have noticed that the flip-flop between lowercase-identifier-name-first and uppercase-identifier-name-first.  I have standardized on lowercase-identifier-name-first in the sandbox.
 * —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.
 * 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, 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 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.   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 section until after ? 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)
 * 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.   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 section until after ? 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)
 * —Trappist the monk (talk) 18:39, 14 April 2020 (UTC)

Parameter descriptions for documentation

 * Alias(es):
 * Usage (e.g., air-date):
 * Use only in and, where the parameter is an alias of date.
 * Use only in and, where the parameter is an alias of 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. --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): &lt;list>
 * has restricted value set: &lt;list>
 * supports  Accept-this-as-written markup: yes|no
 * has parameter-specific error detection: &lt;list>
 * has parameter-specific maintenance category: &lt;list>
 * has parameter-specific property category: &lt;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)
 * 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, 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 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:



 &amp;nbsp; &amp;nbsp; last &amp;nbsp; &amp;nbsp;

 &amp;nbsp; same as last1 same as first1 &amp;nbsp; &amp;nbsp;



 last

 same as last1 same as first1

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:

{

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: --Francis Schonken (talk) 14:36, 16 April 2020 (UTC)
 * which format would be wisest to use for presentation of the full vertical list at Template:Citation Style documentation, 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?

Further questions and suggestions:
 * Added some hover title gizmos to the first parameters in the table above below : good idea? --Francis Schonken (talk) 04:36, 17 April 2020 (UTC)
 * lay-summary? --Francis Schonken (talk) 03:41, 19 April 2020 (UTC)
 * registration? subscription? --Francis Schonken (talk) 06:03, 19 April 2020 (UTC)
 * 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)
 * these three parameters are listed in Template:Cite book/doc, 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.
 * —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)

--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. ). --Francis Schonken (talk) 14:44, 19 April 2020 (UTC)

The full vertical list has now been moved to the documentation. Remaining issues: --Francis Schonken (talk) 05:48, 22 April 2020 (UTC)
 * Both the 3-column model as the 4-column model are currently in the documentation (see Template:Citation Style documentation/doc). 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).

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 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, 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 or. Similarly, only the author-name documentation is rendered when the template is transcluded in the pre-print templates,, , , and.

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, author-mask is documented in which is rather a long way away from. 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, 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:

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:

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 and  and are sort-of aliases of date. When date is present and has a value in and  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 ( 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  table of supported parameters and have a separate entry in the ~/Configuration   table. In the sandboxen, I have moved air-date and airdate into sub-tables of the new ~/Whitelist/sandbox  table and added them to the   entry in ~/Configuration/sandbox   table.

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

I have done the same with the rest of the and  parameters. This uses some of them:

and changing to to demonstrate exclusivity:

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

And one more, :

and changing to to demonstrate exclusivity:

All for now, I think. Other candidates for this treatment are:, , , 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)
 * 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:
 * 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)
 * 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)
 * 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:

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 and, 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 date2018 – all episodes of that series were however first aired in January 2019; thus air-date2019. 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 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.
 * 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: Bach Yearbook 1953, 1954, series is correct. Also, Bach Yearbook, 1954,series, "1953" is correct. But anything that includes 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  as separate parameters: they are exotic aliases of the  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 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 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 . 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 Teahouse/Questions/Archive 587 in that category? That page wasn't edited in years, and had never been in there before. &#32; 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. &#32; 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

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. &#32; 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   prefix) as part of the   attribute.   does not.
 * —Trappist the monk (talk) 15:09, 21 April 2020 (UTC)
 * 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.
 * The above would greatly facilitate script development. &#32; Headbomb {t · c · p · b} 15:26, 21 April 2020 (UTC)
 * also, CS1/CS2 isn't marked if you have something like  or  . &#32; 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: .  Yes, mode is not announced in the   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. &#32; Headbomb {t · c · p · b} 17:43, 21 April 2020 (UTC)
 * The above would greatly facilitate script development. &#32; Headbomb {t · c · p · b} 15:26, 21 April 2020 (UTC)
 * also, CS1/CS2 isn't marked if you have something like  or  . &#32; 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: .  Yes, mode is not announced in the   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. &#32; Headbomb {t · c · p · b} 17:43, 21 April 2020 (UTC)
 * There's none in development now but I would make one if this was there. &#32; Headbomb {t · c · p · b} 17:43, 21 April 2020 (UTC)

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 or, those couldn't be recognized as CS2 or CS1 styles from their classes. Hence the need for the explicit CS1/CS2 class. &#32; Headbomb {t · c · p · b} 16:01, 22 April 2020 (UTC)
 * In the sandbox:
 * 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)
 * 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)
 * 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)
 * 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, (merely a redirect to ), and :

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

but simultaneous use is not:

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

—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. I have done this in the sandboxen

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

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

Does the right thing when combined with contributor:

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

—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  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:

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

works as it did before:

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

—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  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

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

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 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,  or , which wouldn't double-count the bytes in the reference, instead of   or  , to reduce post-expand include size. --Ahecht (TALK PAGE ) 00:11, 25 April 2020 (UTC) PAGE ]]) 03:01, 25 April 2020 (UTC) PAGE ]]) 19:15, 25 April 2020 (UTC) PAGE ]]) 23:43, 25 April 2020 (UTC)
 * Where's an example where you are running into expansion limits? &#32; 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)
 * 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 and, which has a post-expand include size that is over 200kB smaller. --Ahecht ([[User talk:Ahecht|TALK
 * 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 template, previewed (repeated for 100× and 1000×) :
 * 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 :
 * 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:
 * Spanish: mi casa su casa
 * 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)
 * The double counting isn't a flaw, it's by design. See T15260 (tstarling is, 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 ([[User talk:Ahecht|TALK
 * The double counting isn't a flaw, it's by design. See T15260 (tstarling is, 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 ([[User talk:Ahecht|TALK
 * 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   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)
 * 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,  would become . 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 ([[User talk:Ahecht|TALK
 * —Trappist the monk (talk) 22:04, 25 April 2020 (UTC)
 * 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,  would become . 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 ([[User talk:Ahecht|TALK
 * 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.
 * 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)
 * 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)


 * Red question icon with gradient background.svg 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 as an in-source location parameter. When 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  table. This change removes the separate  metaparameter.

Normal sort of operation:

and with redundant parameters:

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

template-specific arguments table for cite map
Like those created for, , and , in ~/Whitelist/sandbox I have created a table for arguments that are exclusively used by.

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