Help talk:Citation Style 1/Archive 65

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

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

@Francis Schonken: The full list of all parameters (some of which may duplicate others in some way) is at Module:Citation/CS1/Whitelist and some of their correlation is at Module:Citation/CS1/Configuration in the line starting with local aliases. Most of them are applicable to all templates. --Izno (talk) 16:49, 1 April 2020 (UTC)

Module:Citation/CS1/Whitelist contains all aliases (which seem to be defined at Module:Citation/CS1/Configuration): a "full parameter list" should rather indicate each definable parameter value with one single name, without redundantly repeating an alias parameter name for the same parameter content. Is it possible to find (or extract) a list of unique identifiers of parameter values, preferably named after current standard (or preferable) names for these parameters? Tx.

A question: Template:Cite book/doc#Title has:

• "title: ... Can be wikilinked to an existing Wikipedia article ..."
• "title-link: Title of existing Wikipedia article about the source named in title ..."

I see no preference for either using a wikilink in the "title" field or defining the "title-link". The second seems less economical

WP:ARTICLESIZE-wise (even when using a piped link). Am I right that I can prefer the wikilink in the "title" field? --Francis Schonken (talk

) 13:32, 4 April 2020 (UTC)

Yep,

csdoc

}}.

I presume that you mean: Is it possible to produce a list of canonical parameter names? Technically? Yes. Practically? Perhaps, but it might be a painful migration. To do so would require that the determination of the canonical parameter name be established in the aliases{} table with the canonical parameter name listed first. Some snippet of module code somewhere would be necessary to read aliases{} and extract the canonical and alias names for each particular metaparameter and provide these names to {{csdoc}} and its subordinate templates.

At the moment, I cannot think of a reason why one of |title=[[Title]] or |title=Title |title-link=Title should be preferred except perhaps clutter, and as you say, wikitext size but the few bytes difference is really rather negligible.

—Trappist the monk (talk) 14:17, 4 April 2020 (UTC)

1. {{
   csdoc}} appears unsuccessful in defining a full parameter set at Template:Citation Style documentation#Full horizontal style, nor is there a usable basis at Template:Citation Style documentation#Full vertical style. Maybe those sections of that documentation page is where a full parameter set (from which derived templates can choose) should start? --Francis Schonken (talk
   ) 15:15, 4 April 2020 (UTC)
2. Either way, a bot changing from one internal link definition style to another should have that task approved before proceeding, I suppose. To me, it seems like getting such approval would be near-impossible in view of
   split threshold – and was thus reverted by me. The COSMETICBOT guidance warns that undoing a cosmeticbot edit may be objectionable under the same guidance: not if the bot was for no good reason increasing size of a large article. --Francis Schonken (talk
   ) 15:15, 4 April 2020 (UTC)

Replies:

1. If {{
   csdoc
   }} is unsuccessful, make it successful. That template is only semi-protected so you have the necessary rights to edit it.
2. cs1|2 is not a bot, does not operate bots, and has no authority over bots. If you have an issue with a bot's edits, the place to address those issues is at the appropriate bot or operator talk page. If I understand
   WP:RPS). A tool linked there indicates that List of compositions by Johann Sebastian Bach printed during his lifetime
   has 7,707 bytes of prose.

—Trappist the monk (talk) 16:44, 4 April 2020 (UTC)

Continuation of bot topic

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

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

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

Replying to two points of Ttm:

• Re. "If you have an issue with a bot's edits, the place to address those issues is at the appropriate bot or operator talk page" – I know. Just wanted to make sure I had read the guidance correctly.
• Re. "
  WP:CHOKING
  's somewhat confusingly formulated guidance.

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

Continuation of "full parameter set" topic

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

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

returns this list:

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

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

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

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

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

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

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

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

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

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

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

Thanks! Seems very helpful.

Re. "If {{

csdoc}} where best to start to address this issue, or (as I originally intended) just individual citation templates' documentation pages' "full parameter set" lists? --Francis Schonken (talk

) 21:43, 4 April 2020 (UTC)

If you have a clear and concise plan for improving the cs1|2 documentation I would think that the best place to start might be right here. Lay out your plan, see what other editors think; see what technical help we can provide, then get to it. The cs1|2 documentation is not a stellar example of our best work so anything that improves it is welcome.

—Trappist the monk (talk) 23:35, 4 April 2020 (UTC)

The background for the plan is, I suppose, something like: {{cite book}}, {{cite web}} and a few other cite templates are among the most often used templates, and are templates that support core content policies such as WP:V. Their documentation should be top notch, so that human editors can use these templates as comfortably as possible. Also for bot operators the documentation should probably better be somewhat clearer, so that always welcome error correction and mostly desirable cleanup are better differentiated from style choices that are often better decided by human editors than by bots.

Question: the list generated above does not contain the "hdl" parameter which I encountered yesterday for the first time, so the list is probably not complete (or is it possible that this parameter is only defined for the "cite book" template?)

Plan, step 1: replace, at Template:Citation Style documentation#Full horizontal style, the "Full parameter set in horizontal format" (currently: {{cite book |last1= |first1= |author1-link= |last2= |first2= |author2-link= |editor1-first= |editor1-last= |editor1-link= |others= |title= |trans-title= |url= |archive-url= |archive-date= |format= |access-date= |type= |edition= |series= |volume= |date= |year= |orig-year= |publisher= |location= |language= |isbn= |oclc= |doi= |id= |page= |pages= |at= |trans-chapter= |chapter= |chapter-url= |quote= |ref= |bibcode= |lay-url= |lay-source= |lay-date= |author-mask= |display-authors= |postscript= |last-author-amp=}}) by one that lists all parameters accepted by (the communal part of?) Citation Style 1 templates, that is, without doubling aliases.

Step 2 would be to do the same for "Full parameter set in vertical format" at Template:Citation Style documentation#Full vertical style

Step 3 would be to do step 1 at Template:Cite book/doc#Usage, that is for all parameters accepted by the {{cite book}} template.

Step 4, would be a similar repeat of step 2 for the {{cite book}} documentation

Step 5 and 6, repeats of both steps (i.e. full horizontal/full vertical) for {{cite web}}'s documentation

Step 7 and 8, similar for {{cite journal}}'s documentation

Etc. for other popular cite templates.

--Francis Schonken (talk) 07:19, 5 April 2020 (UTC)

Identifier parameters are listed in ~/Configuration id_handlers{} and were not included in the original code hack. They now are and the canonical-name and alias-names fetching works for them as well:

{{#invoke:cs1 documentation support|canonical_name_get|ISBN}} → isbn

{{#invoke:cs1 documentation support|alias_names_get|ISBN}} → ISBN

Because of this tweak, I have noticed that the id_handlers{} flip-flop between lowercase-identifier-name-first and uppercase-identifier-name-first. I have standardized on lowercase-identifier-name-first in the sandbox.

I don't see an easy way to automate the full-horizontal and full-vertical lists from the data available in the module suite. The order in which the parameters are presented in the documentation is more a matter of human preference; the modules don't care a whit about order. I can see how we might create an alpha-sorted list of parameters for the various templates by creating exclusion lists. We would exclude |issue=, |sheet(s)= from a listing at {{cite book}} and exclude |chapter= from a listing at {{cite journal}} for example.

—Trappist the monk (talk) 14:18, 5 April 2020 (UTC)

Proposing further intermediary steps for the first step:

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

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

Add to your list a determination of which in a group of alias names is the canonical name. This isn't always easy. The cs1|2 metaparameter Periodical currently has:

canonical: journal

aliases: magazine, newspaper, periodical, website, work (there is a long-standing TODO in the code about the last four of these which really should be listed elsewhere)

Which of those parameter names should be the canonical parameter name really depends on context (which template).

One other thing to consider. A complete rewrite and reorganization instead of creating patches to shoehorn into the existing documentation.

—Trappist the monk (talk) 14:18, 5 April 2020 (UTC)

Re. "canonical" – was my intent for 1.3 ("most appropriate" name; don't care whether it is really canonised, but the one that is the best choice, i.e., would be most widely accepted as the name to be used preferentially – yes, that would/should be the canonical one normally, and if not we'd have to consider what to do best)

Re. "complete rewrite" – yes, considered that too, but even if that were plan "zero" (I mean, preceding the steps proposed above), then still execution of that plan zero might *start* with trying to figure out a best way to present full parameter sets. So, I don't have the feeling my energy is lost, even if somewhere in the middle of the execution of the plan sketched above we decide to fundamentally update/rewrite/rework the prose and/or structure of the parameter descriptions and/or layout of the documentation page(s). --Francis Schonken (talk) 15:37, 5 April 2020 (UTC)

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

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

{{#invoke:cs1 documentation support|canonical_name_get|Periodical|magazine}} → magazine

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

for {{cite web}}

{{#invoke:cs1 documentation support|canonical_name_get|Periodical|website}} → website

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

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

Step 1.0: Alphabetical list of parameters

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

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

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

For |encyclopedia=, there is a long-standing TODO in the code to fix that (mentioned earlier in these discussions).

For |contribution= that parameter name is required in {{cite book}} (and {{citation}} when none of the |work= aliases have a value) when |contributor= has a value.

{{cite book |chapter=Chapter |title=Title |last=Author}} → Author. "Chapter". Title. {{cite book}}: |last= has generic name (help)

{{cite book |title=Title |contribution=Contribution |last=Author}} → Author. "Contribution". Title. {{cite book}}: |last= has generic name (help)

{{cite book |title=Title |contribution=Contribution |last=Author |contributor=Contributor}} → Contributor. "Contribution". Title. By Author. {{cite book}}: |last= has generic name (help)

Having |contribution= as a separate parameter in the aliases{} table was a simple expedient. I've added TODOs to fix this (easier than fixing the |encyclopedia= issue).

Decode the numbers in the Coll. column?

—Trappist the monk (talk) 14:49, 6 April 2020 (UTC)

Thanks for the clarifications. Here are some more of the quirky ones:

• "mailinglist": parameter in its own right, and alias for "journal".
• "message-id" is the canonical for both "MessageID" and "USENETID".

Re. "Decode the numbers in the Coll. column?" – Coll. is abbreviation for "collation", i.e. the collation as currently proposed in the next section (Step 1.1): the first two numbers refer to the block in the list, and the next two to the place the parameter has in that block. A zero is added to allow to insert and/or resort without needing to rewrite all numbers. The ones not assigned in the list below are marked by "—"

Example: 12010 → |map= (first item under number 12); 12020 → |map-url= (2nd item under number 12); |map-format= is currently not listed below: if we'd like to include it between the previous 2, we could give it, e.g., "Coll." number 12015. --Francis Schonken (talk) 15:06, 6 April 2020 (UTC)

|mailinglist= is part of the |encyclopedia= issue but more easily fixed; TODOs added to the sandbox. I had already deactivated |message-id= in the sandbox aliases{} table.

—Trappist the monk (talk) 15:45, 6 April 2020 (UTC)

Step 1.1: collation order

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

1. author-related: {{cite book |others= ...

   not included: "authors" (not adopted in COinS metatdata)

2. editor-related: ... |veditors= ...

   not included: "editors" (not adopted in COinS metatdata)

3. title-, web-, chapter-, type- and journal-related: ... |type= ...

   not included: "title-link" (redundant)

   chose "work" instead of its alias "website"

4. edition-, series-, event-, agency- and volume-related: ... |volume= ...
5. date-related: ... |df= ...
6. publisher- and language-related: ... |language= ...

   not included: "publisher-link" (redundant)

   chose "location" instead of its alias "place"

7. pages- and time-related: ... |time-caption= ...
8. id-related: ... |zbl= ...
9. url-, chapterurl-, lay-, quote- and ref-related: ... |ref= ...
10. display-related: ... |postscript= ...
11. access-related: ... |sections= ...
12. interview-related: ... |display-interviewers= ...
13. season- and network-related: ... |station= ...
14. transcript- and conference-related: ... }}

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

[1] Perhaps #1 and #2 should be subsections of a single names group? subgroups for author names, editor names, and other names?

[2] In #1 (and #5): |aliases=? what do these mean?

[3] In #3 you use an underscore as a separator; there are no currently supported parameter names that use the underscore; where did you find those? And, |title_title=? |type_default=? You say |title-link= not included (redundant); redundant to what? |contribution-url= should move to #9? |department= is intended more for {{cite news}}; departments of a newspaper (sports, local, ...); like |agency= should probably be ignored by {{cite book}}

[4] If these parameters that you've listed are for {{cite book}}, in #4 |series-link=, |episode=, and |event= are ignored; |agency= probably should be ignored.

[5] In #5, |began= and |ended= are not currently supported parameters; where did you find these?

[6] In #6, doesn't |publication-date= belong in #5? (I'm of a mind that this particular parameter should go away or, at the least, become an equal alias of |date= in the same way that I think that |publication-place= should go away or become an equal alias of |place= – which should be an alias of |location=)

[7] Better name for groups #7 is in-source locator parameters?

[8] Perhaps a new group #10 for miscellaneous parameters? |quote= (#9), |language= (#6); I would also include the lay- parameters here (#9)

—Trappist the monk (talk) 21:59, 5 April 2020 (UTC)

I numbered your suggestions [1] to [8] for ease of responding to them, if that's OK:

• [1] In the full parameter set of the book template's doc the author-related block (Template:Cite book/doc#Authors) is separated from the editor-related block (Template:Cite book/doc#Editors) 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#author 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#title; "type_default" from Template:Citation Style documentation#type. 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#journal "Options ...". Seems you misunderstand the exercise: this one is for Template:Citation Style documentation#Full horizontal style (as you recommended to do first) – not for any of the individual cite templates. 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#Full horizontal style), see [3].
• [5] Template:Citation Style documentation#date, "Options ..."
• [6] Not according to the current versions of Template:Citation Style documentation#date and Template:Citation Style documentation#publisher
• [7] I used the subsection names as currently available at Template:Citation Style documentation#Parameters section – 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 {{

csdoc

}} to control how that template renders the documentation for that those sections in a cs1|2 template's doc page.

[3][4] Seems you misunderstand the exercise: this one is for Template:Citation Style documentation#Full horizontal style (as you recommended to do first) – not for any of the individual cite templates. Misunderstand? No doubt. But, if this exercise is template agnostic, why does the list in your #1 begin {{cite book? I do not recall any recommendation to start with horizontal style. I think that my first recommendation was (still is) start by choosing which of a list of parameter alias names shall be the canonical parameter name.

[5] I have removed the doc option control parameters for |date= aliases (there are none) and for |began= and |ended= (doc support for those removed January 2016) and added the doc option control parameter |limited_param_list= to hide cs1|2 parameter |orig-year= when the csdoc template is used in documentation for limited-parameter-set cs1 templates.

[6] yes |publication-date= is listed with |publisher= and |place= and |via= but it should't be. It is a date so should be listed with the other publication-date parameters (and converted to a simple alias of |date=)

—Trappist the monk (talk) 14:20, 6 April 2020 (UTC)

"publication-date" removed from the full set proposal, for the same reasons as "air-date" (see below). --Francis Schonken (talk) 05:27, 9 April 2020 (UTC)

Updates to 1.1 and/or parameters needing further attention

Additions to the listing below and/or comments welcome:

• – 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 {{cite episode}} and {{cite serial}}; 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. {{cite episode}} and {{cite serial}} docs updated.

  —Trappist the monk (talk) 22:29, 7 April 2020 (UTC)

• archive-format 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 {{

  csdoc

  }}

  —Trappist the monk (talk) 00:07, 10 April 2020 (UTC)

• book-title – 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 {{cite conference}}; 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)

• class – 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#id2 section if it has anything to do with arxiv). --Francis Schonken (talk) 10:36, 7 April 2020 (UTC)

  Exclusively used by {{

  cite arxiv

  }} and documented there.

  —Trappist the monk (talk) 14:12, 7 April 2020 (UTC)

• conference-format – added to proposal (#15); currently undocumented in documentation template: should probably best be documented at Template:Citation Style documentation#conference. --Francis Schonken (talk) 10:43, 7 April 2020 (UTC)
• contributor-first# and contributor-link# – 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 contributor-last# 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 {{

  Template:csdoc § display

  —Trappist the monk (talk) 13:48, 10 April 2020 (UTC)

• contributor-mask#, display-translators and display-contributors – added to proposal (#10); needs to be mentioned in documentation. --Francis Schonken (talk) 12:11, 7 April 2020 (UTC)
• degree – 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)

  {{cite thesis}} as an alias of |type=.

  —Trappist the monk (talk) 14:12, 7 April 2020 (UTC)

• interviewer-mask# and display-interviewers – 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)
• docket – 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 {{cite thesis}} where it is locally tacked on to the csdoc id1 rendering

  —Trappist the monk (talk) 14:12, 7 April 2020 (UTC)

• pmc-embargo-date – 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)

• map-format and map-url-access – added to #12, needs to be documented. --Francis Schonken (talk) 14:20, 7 April 2020 (UTC)

  Also sheet and sheets need documentation. {{cite map}} only.

  —Trappist the monk (talk) 14:28, 7 April 2020 (UTC)

  Likewise, script-map and trans-map: 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; sections on the other hand added & sorted, but needs to be better documented. --Francis Schonken (talk) 14:50, 7 April 2020 (UTC)

  |section= in {{cite map}} 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=); {{cite map}} does not accept any of the |chapter= aliases except |section= in this special use. TODOs added to tweak the code to remove the separate Section key from the aliases{} 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)

• transcript-format – 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 → bibcode-access
  • DOIaccess → doi-access
  • HDLaccess → hdl-access
  • JSTORaccess → jstor-access
  • OLaccess → ol-access
  • OSTIaccess → osti-access
  • S2CIDaccess → – new in the sandboxen so not yet available

  There are no aliases for these parameters so:

  {{#invoke:cs1 documentation support|alias_names_get|JSTORaccess}} →none← (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)

{{csdoc|usage vertical}}
<pre style="margin:0px;">
{{cite book
| last                  =
| first                 =
| author-link           =
}}
</pre>
{{csdoc|usage vertical mid}}
<pre style="margin:0px;">
&nbsp;
&nbsp;
last
&nbsp;
&nbsp;
</pre>
{{csdoc|usage vertical mid}}
<pre style="margin:0px;">
&nbsp;
same as last1
same as first1
&nbsp;
&nbsp;
</pre>
{{csdoc|usage vertical end}}

{{cite book
| last                  =
| first                 =
| author-link           =
}}

 
 
last
 
 

 
same as last1
same as first1
 
 

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

{{cite book
|last1=
|first1=
|author-link1=
}}

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

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

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

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

Click show preview.

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

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

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)

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

Because |air-date= and |airdate= are only used in the two templates, I hit upon the idea of creating a template_specific_arguments table in

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

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

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

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

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

And one more, {{cite newsgroup}}:

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

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

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

I am in general agreement with the specific args table. I suppose that semantically |air-date= and |publication-date= would be considered equivalent. 98.0.246.242 (talk) 01:58, 9 April 2020 (UTC)

@Trappist the monk: I see that |air-date= has now been merged into |date= (technically: has become an alias of the latter, instead of a parameter in its own right). Why hasn't |publication-date= shared its fate? That seemed similar enough to be treated likewise? Or am I missing something? --Francis Schonken (talk) 03:45, 23 April 2020 (UTC)

Because |publication-date= is only an equal alias of |date= when it is used alone. When used with |date=, |publication-date= is also rendered:

{{cite book |title=Title |date=1999}}

Title. 1999.

{{cite book |title=Title |publication-date=2020}}

Title. 2020.

{{cite book |title=Title |date=1999 |publication-date=2020}}

Title (published 2020). 1999.

Just as I would like to see |publication-place= go away, so too, I would like to see |publication-date= go away

—Trappist the monk (talk) 11:08, 23 April 2020 (UTC)

So |publication-date= does now what I described as my preferential MO for air-date (see below, with explanation & example why it should be available for works that are aired). So no, keep it. And, if this is possible for publication-date, there should be no major issue to implement the same for "air-date", so please bring |air-date= back, with that specific MO. Well, make it just an alias of publication-date, after which the parameter can be made available to most (if not all) cite templates. Thanks. --Francis Schonken (talk) 11:36, 23 April 2020 (UTC)

With air-date, the emitted cite should read "Title (aired 2020). 1999." – so struck the last part of my last suggestion: just bring air-date back, with a functionality comparable to current publication-date (but then for works that can be aired). I think that e.g. {{cite interview}} should have both: an interview will often have a publication date (e.g. when printed) or airing date (for e.g. televised interviews) different from the date when the interview was taken (both *when* the interviewed person said something, and *when* it was made public can have significance). --Francis Schonken (talk) 12:07, 23 April 2020 (UTC)

Test:

{{cite book |title=Title |date=2000 |publication-date=2000}}

Title. 2000.

{{cite book |title=Title |date=2000-01-14 |publication-date=2000-01-14}}

Title. 2000-01-14.

{{cite book |title=Title |date=2000-01-14 |publication-date=14 January 2000}}

Title (published 14 January 2000). 2000-01-14.

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

• Re. "air-date", here's what I think it should do: if it only works for {{cite episode}} and {{cite serial}}, then for those two cite templates is should allow to record two different dates for the work: the production date in |date= and the date of airing in |air-date=. Example: Father Brown, 7th series, shows the date of "2018" in the credits, thus |date=2018 – all episodes of that series were however first aired in January 2019; thus |air-date=2019. That's however not how it works: only a single date can be mentioned in the cite template, only either |date= or |air-date= can be used: they are aliases when used in any of the templates in which they currently can be used. Imho the software should only consider them aliases when only one of the two is defined (in other words: "air-date" should define the "date", and the other way around, if no value is given for the other parameter – only when a different value is given to "date" and "air-date" should both values be accepted, and allowed to be different, which is not the case currently).

I think "publication-date" should work similarly for books and other printed works, or works published otherwise than by airing. In that case, "publication-date" and "air-date" could be aliases of the same parameter, working in the same way across all cite templates (which is not the case currently), e.g. for a Netflix serial it should be possible to use |publication-date= in the {{cite serial}} template as an equivalent of an "air-date" for a traditional broadcaster. Also books can be published in a different year than their nominal date: e.g., the Bach Yearbook of 1953 was published in 1954 ([1]).

If that's not possible, and all cite templates use only a single date, whether it's called "date", or "air-date" (for some templates), or "publication-date" (for some other templates), then we should be simplifying things and make all these date-related parameters aliases of the "date" parameter, instead of having different flavours of dates which are de facto all the same, but don't work the same across the cite templates.

Anyway, the current arrangement is a useless complexity. The cs1 template currently has 158 different unique parameters: getting rid of a few useless ones (which can be defined as simple aliases of the "date" parameter) should not be taking too much work to get sorted I suppose. --Francis Schonken (talk) 08:11, 9 April 2020 (UTC)

Citations concern published material (with very rare exceptions). They should provide the date a work became public, not the date it was produced/printed/recorded etc. Unless the publication date is unknown, in which case any available date can help in source discovery. Most source databases use the same criteria to index their content. 65.88.88.69 (talk) 20:08, 9 April 2020 (UTC)

The Bach Yearbook of 1953 is, in all reliable sources, referred to with the 1953 date (please find me one which doesn't!). Wikipedia does otherwise, because of the current limitations of the cite template. --Francis Schonken (talk) 22:27, 9 April 2020 (UTC)

From a citation perspective: |title=Bach Yearbook 1953, |date=1954, |series=[annual] is correct. Also, |title=Bach Yearbook, |date=1954,|series=[annual], |vol="1953" is correct. But anything that includes |date=1953 is not correct. Since the publication date is known, that is what should go there. should it not? 98.0.246.242 (talk) 01:41, 10 April 2020 (UTC)

As said, this is correct according to current limitations of Wikipedia's cite templates, but not how it is done in reliable sources. In the context of solid professional literature, Wikipedia's way of citing this high-profile scholarly edition is extremely weird. As said, find me one, one single source apart from Wikipedia, which refers to the Bach Yearbook of 1953 with the 1954 date. Afaik there is none. I could give you a few that use the 1953 date exclusively for referring to this publication.

My point is: there are 158 unique parameters for cite templates. None of these support referring to the Bach Yearbook of 1953 the way it is done in professional literature. If that's the way we want it for the Bach Yearbook, and for other cases such as the Father Brown series, I see no reason to keep and publication-date as separate parameters: they are exotic aliases of the date parameter (exotic while they can only be used in selected templates), and should rather be defined as simple straightforward aliases of that parameter, thus reducing the total number of unique parameters with two (result: 156 unique parameters, which is still more than enough for how the templates currently work). --Francis Schonken (talk) 06:39, 10 April 2020 (UTC)

The Wikipedia citation system is unique and should not be compared with any others except in very narrow, strictly technical aspects. It is the first general-purpose citation system of its kind, whose main target are non-expert, non-professional readers. Unlike other citation systems whose aim is to support expert synthesis or professional original research, the purpose here is much more basic. It is a tool to apply Wikipedia's verification policy. To help prove that whatever is claimed in wikitext actually exists, somewhere. Because the project is inherently unreliable, since it depends on anonymous contributors. No offense meant, but "Francis Schonken" means nothing to me, or most people (I imagine). You could have signed "Stephen Hawking" and none would be the wiser.

Because of the type of the intended consumers of Wikipedia citations, the guidelines of any systematic approach should be ease of understanding, ease of use, and accessibility. This is an open slate that should not depend on inscrutable custom. Or on the narrow requirements of a specific field whose practitioners use citations daily, are familiar with technical jargon, and implicitly understand the underlying concepts. Most of all it has to make sense. So when we want use a field that refers to the date the work became available to the public (because that is what is pertinent) we should put that particular date there. Only when the work cannot be discovered with such date, should a different date field come into play, perhaps with an explanation. Luckily, one of the great advantages of Wikipedia is the fact that there is no "house" system that one has to follow. You can format a citation any which way as long as it is understandable and relatively easy to verify. One of the best examples would be a footnote with the following: "I found This information is in the Bach Yearbook 1953, which was published in 1954 by so-and-so, in this location. Look in pages xxx-xxxx. This source can also be found by a commercial book identifier, which is so-and-so."

Other than that, I definitely agree that CS1 is way too complex as presently presented (without going into the technical and design issues lingering from the previous incarnation). It could be documented in a much more understandable fashion. 98.0.246.242 (talk) 15:30, 10 April 2020 (UTC)

Of course it should be compared with how reliable sources display references. Let's get back to basics: references, including cite templates "support core content policies such as

WP:V

" (as I wrote above on this page) – it is in the best interest of readers and editors that references are as recognisable as possible, resulting in an unhampered application of core content policies. "Recognisable" means that references should look, as much as possible, like the ones one encounters elsewhere, in reliable sources.

I'm not sure what you're actually proposing as an improvement to Citation Style 1 templates and their documentation. Just complaining that it is too complex is neither here nor there. I proposed a simplification: either it gets accepted (if enough editors support it and someone is prepared to implement it) or it doesn't. If it doesn't get accepted, and the complexity is retained, I proposed to put it to better use – same for that option: either it is supported by other editors, and gets implemented, or it isn't.

I'm well aware how references can be written without cite templates, and what the principle behind

WP:SAYWHEREYOUGOTIT is. The latter is however part of another guidance page (which, FYI, I helped writing around 15 years ago when the <ref> system was first introduced in the software), with its own talk page if you want to suggest improvements, but not part of what is discussed on this talk page, i.e. improvements to Citation Style 1 templates and their documentation. --Francis Schonken (talk

) 09:27, 11 April 2020 (UTC)

I doubt that the average Wikipedia reader will be able to recognize any of the existing citation systems. Recognize in the sense of understanding how they are formatted, what they do, and what they and are there for. At most, they may get a vague idea that the strange paragraph is somehow related to the stuff that came before it. Here, the target audience is that type of relatively un-knowing reader. The minority who has an understanding of MLA, APA and all the other discipline-based systems is not the concern. They will know enough to pick their way through a Wikipedia citation no matter how it is formatted. But this citation system cannot be based on the disctinct minorities and their respective favorites, created to fit their particular disciplines. It is not comparable in philosophy or purpose, and the implementation should reflect that. As expected, and unfortunately, a lot of the people involved in this application of citations have prior knowledge of the specialist citation systems, and this apparently hampers their ability to develop a simple general-purpose system. It doesn't have to, but it does.

This has nothing to do with

WP:SAYWHEREYOUGOTIT

, I was using an example as illustration. It is also irrelevant whether "Francis Schonken" contributed to that discussion, and is now contributing to this one, even if it is the same (real) person in both cases. This is simply about presenting citations in a way that makes sense to people who are ignorant on the subject. The common-sense expectation would be for a publication date, and only a publication date, to be in the publication date field.

I have commented on CS1, templates, and citations in general for many, many years, so forgive me for not wanting to revisit specifics. Previously (pre-Lua) the confusion, beside the technical issues, was mostly the result of diversity: many templates were part of the collection only in name and technical base ({{citation/core}}). The presentation was all over the place. In this incarnation we have uniformity and good attempts at consistency, but there are glaring omissions, in both design, logic, and user interface. The underlying code naturally will evolve to be more complex or more abstract or both, that is fine. It is the presentation that should be going in the opposite direction. Having "experts" decide on the formatting is not helping. Unless the experts can approach this as non-experts, and apply their expertise on that approach. 98.0.246.242 (talk) 16:09, 11 April 2020 (UTC)

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

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

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

Well, it is simple. Your original complaint about not being able to enter two different dates (production date and air date) on the same citation template is not in my opinion actionable. The subsequent discussion followed from there. 98.0.246.242 (talk) 02:18, 12 April 2020 (UTC)

There was no "complaint". There were two completely different suggestions, which are either... or... The first is as "actionable" as the second. Just say which one you like most, and take it from there. --Francis Schonken (talk) 05:51, 12 April 2020 (UTC)

Why is

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.

b

} 12:31, 23 April 2020 (UTC)

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

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

This would allow for scripts to be designed to identify which citations are in CS1/CS2 styles at a glance. This could also be used for people who only want to be warned of

Already exists in a slightly different form. All cs1 templates include their name or a hyphenated variant of their name (without the cite prefix) as part of the class= attribute. {{citation}} does not.

{{citation}}:

'"`UNIQ--templatestyles-000000C7-QINU`"'<cite class="citation cs2">''Title''</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>

{{cite av media notes}}:

'"`UNIQ--templatestyles-000000C9-QINU`"'<cite class="citation AV-media-notes cs1">''Title'' (Media notes).</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=unknown&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>

—Trappist the monk (talk) 15:09, 21 April 2020 (UTC)

@Trappist the monk: probably something that should be refined then since CS1 sub-classes proliferate at a rather rapid pace, and that CS2 aren't explicitly marked as such.

• <cite class="citation cs1 AV-media-notes">...
• <cite class="citation cs2">...

The above would greatly facilitate script development.

b

} 15:26, 21 April 2020 (UTC)

@

b

} 16:09, 21 April 2020 (UTC)

Is there a script in development? I don't know what you mean by CS1 sub-classes proliferate at a rather rapid pace. That CS2 [isn't] explicitly marked is in itself explicit marking because there is only one cs2 template: {{citation}}. Yes, |mode= is not announced in the class= attribute.

—Trappist the monk (talk) 16:15, 21 April 2020 (UTC)

There's none in development now but I would make one if this was there.

b

} 17:43, 21 April 2020 (UTC)

@

In the sandbox:

{{citation/new |title=Title}}

'"`UNIQ--templatestyles-000000D3-QINU`"'<cite class="citation cs2">''Title''</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>

{{citation/new |title=Title |mode=cs1}}

'"`UNIQ--templatestyles-000000D6-QINU`"'<cite class="citation cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>

{{citation/new |title=Title |mode=cs2}}

'"`UNIQ--templatestyles-000000D9-QINU`"'<cite class="citation cs2">''Title''</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>

{{cite book/new |title=Title}}

'"`UNIQ--templatestyles-000000DC-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>

{{cite book/new |title=Title |mode=cs1}}

'"`UNIQ--templatestyles-000000DF-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>

{{cite book/new |title=Title |mode=cs2}}

'"`UNIQ--templatestyles-000000E2-QINU`"'<cite class="citation book cs2">''Title''</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+65" class="Z3988"></span>

I may undo this change in a little while because this single change makes every test in Module talk:Citation/CS1/testcases fail.

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

Undone with notes to restore at next module suite update.

—Trappist the monk (talk) 15:04, 23 April 2020 (UTC)

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

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

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

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

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)

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

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

ignores other Periodical 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)

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

Title.

PMC 7500000

.

Title.

PMC 7500001

.

Title.

PMID 33000000

.

Title.

PMID 33000001

.

Title.

SSRN 4000000

.

Title.

SSRN 4000001

.

Title.

S2CID 23000000

.

Title.

S2CID 230000001

.

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

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

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

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

Where's an example where you are running into expansion limits?

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)

@

2019–20 coronavirus pandemic data/sandbox}}, which uses {{#invoke:Sandbox/Ahecht/Cite|web}} and {{#invoke:Sandbox/Ahecht/Cite|news}}, which has a post-expand include size that is over 200kB smaller. --Ahecht (TALK
PAGE

) 03:01, 25 April 2020 (UTC)

Confirmed. To take all of the other stuff out of the picture, I did an experiment with Module:Lang which is configured to be called from other modules. I created a blank mainspace page with a nonsense name and previewed it:

• blank → Post‐expand include size: 0/2097152 bytes

Then I added a single {{lang-es}} template, previewed (repeated for 100× and 1000×) {{lang-es|mi casa su casa}}:

• 1× → Post‐expand include size: 232/2097152 bytes
• 100× → Post‐expand include size: 23200/2097152 bytes
• 1000× → Post‐expand include size: 232000/2097152 bytes

I did the same tests using direct invoke {{#invoke:lang|lang_xx_italic|code=es|mi casa su casa}}:

• 1× → Post‐expand include size: 116/2097152 bytes
• 100× → Post‐expand include size: 11600/2097152 bytes
• 1000× → Post‐expand include size: 116000/2097152 bytes

As a follow-up, I compared the 100× versions of both. Both have the same html for the template output; each has 100 of:

• <a href="/wiki/Spanish_language" title="Spanish language">Spanish</a>: <i lang="es">mi casa su casa</i>

All of this suggests to me that there is a flaw in how MediaWiki counts bytes when calculating post-expand include size.

Your next stop, I think, is phabricator.

—Trappist the monk (talk) 11:23, 25 April 2020 (UTC)

This is a known issue since a decade and more ago. It didn't need confirmation... --Izno (talk) 15:08, 25 April 2020 (UTC)

@Trappist the monk: The double counting isn't a flaw, it's by design. See phab:T15260 (tstarling is Tim Starling, the Lead Platform Architect for MediaWiki). The intention was to force more native usage of Lua, which is more efficient from a server standpoint than multi-level nested templates. --Ahecht (TALK
PAGE) 19:15, 25 April 2020 (UTC)

It seems odd that a limit that was justified ten years ago as a way to limit processing time has not been increased to account for increases in processor speed. I am probably misunderstanding. – Jonesey95 (talk) 20:35, 25 April 2020 (UTC)

I'm sure that I'm misunderstanding something. Apparently that was pre-lua days, it was pre-parsoid days. But, tstarling appears to be saying that once we have lua and parsoid then reducing parsing limits should be considered. I don't really know what that means. But, we have lua and we have parsoid so was reducing parsing limits considered? What was the result of that consideration?

But, regardless, if double counting a template wrapper around an invoke is how the system is designed, then we should not be gaming that system to eke a little more time by patching this and patching that before an oversize article finally collapses under its own weight and must be split or severely pruned. I am also concerned that the {{#invoke:cite|web|<params...>}} construct will just confuse editors who already complain that cs1|2 is too complex to be understood. Is that construct editable by editors who use ve?

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

@Trappist the monk: It's not gaming the system. Avoiding nested templates is exactly what the system was designed to encourage. Also, the syntax is a bit simpler than in your example (unless I'm misunderstanding your notation). For example, {{Cite web|url=https://en.wikipedia.org|title=Wikipedia|accessdate=24 April 2020|publisher=Wikipedia Foundation}} would become {{#invoke:Cite|web|url=https://en.wikipedia.org|title=Wikipedia|accessdate=24 April 2020|publisher=Wikipedia Foundation}}. It is editable by visual editor (see this edit in my sandbox, or try editing my sandbox yourself with VE). And just to clarify, this usage would not be widespread, only a tiny handful of pages would ever need to use it. --Ahecht (TALK
PAGE) 23:43, 25 April 2020 (UTC)

I don't think this is a good idea if applied in a piecemeal fashion or in some specific cases. It could create variance in the application of CS1 among, or even within pages. One more thing to be (perhaps poorly) explained. It would make more sense for it to be universally applied, or not at all. Let's keep in mind that there are very few (mainly one) persons maintaining an increasingly complex system. As Trappist suggested, a far simpler solution would be to split the article. As for the phab discussion linked above, tstarling seems to be saying that since the introduction of lua and the new parser would supposedly reduce the parsing resources required, it would make sense to decrease the parsing limits in the new (current) system. Note the linked phab discussion, that proposes an opposite direction. And here we are several years later. 98.0.246.242 (talk) 00:35, 26 April 2020 (UTC)

Misplaced </nowiki>.

The goal of this exercise appears to be an attempt to hold off the inevitable. The articles are growing. They will continue to grow until someday after editors have run out of tweaks and patches, the articles will just be too large. Making tweaks and patches to hold off the inevitable is what I meant by gaming the system. I know, this is hard, editors don't like to split split articles.

—Trappist the monk (talk) 11:48, 26 April 2020 (UTC)

This edit request has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

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

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Can't find it. :\ Aasim 09:55, 25 April 2020 (UTC)

"Not done" stroken for procedural reasons.

Aasim, this is a talk page for citation templates and the right place to make suggestions how to improve them or their documentation. This is open for anyone. You can voice your opinion like anyone, but you are not to decide if or if not something gets done. Therefore the usage of "Not done" is inappropriate and comes over as presumptuous and rude, in particular as the OP's request was genuinely friendly and constructive (and also quite sensible). So, there was not the slightest reason to reply as if the user would have done a mistake. Please

WP:DONTBITE

our newcomers.

Further, no reliable sources (

WP:RS

) are needed for someone to propose an improment. Finally, the OP even suggested an improved wording, so, putting the tone issues aside, your reply was inappropriate even on purely technical grounds.

--Matthiaspaul (talk) 12:25, 25 April 2020 (UTC)

Dear IP, thanks for your suggestion, you have a good point here. The phrase "Date of source being referenced" is somewhat misleading and could probably be improved. As the |date= parameter typically holds the publication date of the specific version/edition cited (and not the |access-date=, which is used for the date when the source was read), your replacement suggestion "Date of publishing of the source" is more to the point in most cases. However, there are a number of corner cases, where the parameter is used in a wider sense: For example, in some cases, there might be a difference between a limited-audience publication and one which is open for the general public. Similar, there might be a significant difference between an original publication date and an (identical) reissue much later. Some sources provide a "last edit", "filing" or "print" date rather than a publication date. Sometimes, multiple such dates are given - in this case the |orig-year= parameter can be used to specify them.

This inherent ambiguity is the reason why the wording in the help was left somewhat vague in regard to the type of date to use for the |date= parameter, and your suggestion "Date of publishing of the source", although correct for most cases, might already be a bit too specific for the general case.

To just better distinguish |date= from |access-date= perhaps "Date of referenced source" would already do the job?

Alternatively, to solve the underlying issue, we could either explain all this in detail in the help, or introduce more specific date parameters (like f.e. |reissue-date=, |publication-date=, |print-date=, |filing-date=, |edit-date=, ...) for the different types of date (of which only one would be used most of the time). The newest given date would then have to be treated as an alias for |date=, whereas the other date(s) would have to be aliases for (or be combined with) |orig-year=. So, this would not change much in the template's visible output, but help plausibility checks when later editors would run into what looks like the same source being referenced with a different date somewhere else (this would increase the level of trust we could put into a citation, and might also be useful to improve future, more specific types of metadata).

--Matthiaspaul (talk) 12:25, 25 April 2020 (UTC)

Hi Matthiaspaul! I see the challenge. Your suggestion Date of referenced source sounds good to me. And perhaps a link to somewhere which describes the intricacies of the situation and the other parameters. Many "normal people" apparently find the use of templates hard. Thus it's very important I think that the documentation is as crystal clear as possible without losing the real world complexity. As Albert Einstein supposedly said "Everything should be made as simple as possible, but no simpler". Stay safe amigo! 2001:14BA:9C0B:A700:0:0:0:8EA (talk) 12:15, 26 April 2020 (UTC)

Another TODO added just before the last module suite update.

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

Normal sort of operation:

and with redundant parameters:

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

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

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