Help talk:Citation Style 1/Archive 72

Archive 65

←

Archive 70

Archive 71

Archive 72

Archive 73

Archive 74

Archive 75

Is Module:Citation/CS1/autofix used by anything?

It appears to be a failed test by a since-banned user. If it is used, could someone add documentation? * Pppery * _{it has begun...} 21:58, 7 October 2020 (UTC)

No, it is unused by CS1. It appears to have been that user's sandbox. --Izno (talk) 22:29, 7 October 2020 (UTC)

I have documented it. We could move it to the user's space, but I don't know if modules can be invoked from User space. – Jonesey95 (talk) 23:57, 7 October 2020 (UTC)

It could move to Module:Sandbox/Wikid77/Citation/CS1/autofix where is can be invoked. Delete or userfy.

—Trappist the monk (talk) 00:15, 8 October 2020 (UTC)

There's no point in userfying content by indefinitely blocked users. * Pppery * _{it has begun...} 01:42, 8 October 2020 (UTC)

This is a flawed approach. Content should be judged on its own merit, even if the motivation of the author is suspect. In this case, the premise (auto-fixing) is useful though the execution is lacking. I remember this blocked user from this page, as someone somewhat obsessed with performance. 64.18.9.207 (talk) 12:38, 8 October 2020 (UTC)

Nomination for deletion of Module:Citation/CS1/autofix

Module:Citation/CS1/autofix has been nominated for deletion. You are invited to comment on the discussion at the module's entry on the Templates for discussion page. * Pppery * _{it has begun...} 01:42, 8 October 2020 (UTC)

Will this TemplateData change result in access-date without URL errors?

Coffeeandcrumbs: Will this change to cite news/doc result in "access-date without URL" errors when editors use VE to insert a cite news template for an off-line source? I don't use VE, so I don't have a way to test it. – Jonesey95 (talk) 15:03, 7 October 2020 (UTC)

Yes, the change would cause those kinds of errors. I also do not believe the change will work, since substing doesn't work inside <ref> tags. --Izno (talk) 15:10, 7 October 2020 (UTC)

Do templates even work in TemplateData? They didn't before, nor did wiki markup, that's why the usual cs1|2 template documentation {{csdoc}} wasn't used to create documentation for ve and why TemplateData doesn't link to more extensive documentation.

—Trappist the monk (talk) 15:16, 7 October 2020 (UTC)

Sorry about that, I did not know these issues. Is there a way to put something similar to {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} as an "example" in TemplateData? Right now, when using {{Cite news}} manually in VE, the user has to figure out the date in UTC and enter it. It would be convenient to have it in the example to copy from similar to how we have endash ("5–11") in the example for |pages= for the user to copy from. --- C&C (Coffeeandcrumbs) 15:41, 7 October 2020 (UTC)

BTW, I meant to put it in "auto value" but it would not have worked there either. --- C&C (Coffeeandcrumbs) 15:56, 7 October 2020 (UTC)

No "auto value" date keyword, eh? What is an "auto value" good for if you can't tell it what to give you automatically? Of course, were there such a thing, you'd need a date-format control...

—Trappist the monk (talk) 16:07, 7 October 2020 (UTC)

I don't know. I think that TemplateData is a failed experiment that attempts to do two things simultaneously, documentation and control. Maybe it does ok with the control part, I don't know because I don't use ve, but it fails miserably at the documentation part because it does not support templates and normal wiki-markup on a wiki – who thought that was a good idea?

—Trappist the monk (talk) 16:07, 7 October 2020 (UTC)

I am comfortable using both editors and I assure you, it has done wonders for non-technical editors. I am sure there is room for improvement but let's not throw the baby out with the bath water. However, the fact that it does not accept wiki markup is a huge fail. --- C&C (Coffeeandcrumbs) 04:49, 9 October 2020 (UTC)

Izno, I tried to learn why substing does not work inside <ref> but could not find it documented any where. Can anyone point it out? Why not allow substing inside a ref? --- C&C (Coffeeandcrumbs) 04:49, 9 October 2020 (UTC)

@Coffeeandcrumbs: phab:T4700. --Izno (talk) 04:50, 9 October 2020 (UTC)

WOW! Just wow! Some phab tickets are just so hilarious. --- C&C (Coffeeandcrumbs) 05:00, 9 October 2020 (UTC)

Template: Cite journal

Why does {{Cite journal}} display |page=7 as "7" and not "p.7"? This means that interpretation of the reference is not immediately obvious. Please can it be changed so that it displays correctly, as it does when {{cite book}} is used. Mjroots (talk) 11:05, 9 September 2020 (UTC)

This is about Llangennech derailment? Rail, according to our article is a magazine so use {{cite magazine}}. {{cite journal}} is for academic and scholarly journals an uses the style appropriate to them.

—Trappist the monk (talk) 11:14, 9 September 2020 (UTC)

Trappist the monk it's not specifically about that article, no. It's about the inconsistent dispay output of the various templates. It is not asking too much to expect consistency across templates that all do a similar job. Mjroots (talk) 20:59, 9 September 2020 (UTC)

The point, however, is that these templates are displaying things differently not by accident but deliberately - that's the very reason for why different versions of these template exist in the first place. Per design, {{cite journal}} displays citations following the conventions used for scientific journals, whereas {{cite magazine}}, which takes the same set of parameters, renders them as is common for magazines. That is, by switching between these templates you can change the output style.

To be honest, sometimes I like that and sometimes I hate it. I think, we should have a small number of rendering styles available to adjust to a certain style in an article, but I would prefer to have them available as a parameter (similar to |(cite-)mode= or |df=), so that {{cite journal}}/{{cite magazine}} could officially be merged into one.

The way page numbers are displayed would be controllable by this setting, but it would be combined with the style for volumes, issues and numbers, because not all combinations make sense. The most common styles would be similar to:

• |periodical-mode=scientific → v (i[ #]n): p[–p]. Example: 15 (11 #179): 14–23.
• |periodical-mode=abbreviated → Vol. v no. i[ #]n. ... p[p]. p[–p]. Example: Vol. 15 no. 11 #179. ... pp. 14–23
• |periodical-mode=full → Volume v, Number n, Issue i, Page[s] p[–p]. Example: Volume 15, Number 179, Issue 11, Pages 14–23.

In most cases, only one out of issue and number would be given at the same time; in this case, the current practise is to treat them the same and not add a prefix like #. But there are cases, where both values exist, therefore this discussion should not forget about this special case, that's why I added it to the examples above (Help_talk:Citation_Style_1/Archive_62#Problem_with_journals,_magazines_(and_books)_using_all_three_parameters:_volume,_issue_and_number).

In addition to the choices illustrated above, there also might be choices for a symbolic notation with non-boldface volume as well as for uppercase abbreviated and lowercase non-abbreviated text versions.

(Actually, there is at least one more common symbolic notation used in Europe, but I haven't seen it being used in the English Wikipedia.)

--Matthiaspaul (talk) 19:24, 10 September 2020 (UTC)

The last interesting discussion on the topic is probably Help talk:Citation Style 1/Archive 51#Journal / Magazine / News(paper) uniformity (and books too). Generally, this comes up once every year or so in some fashion; it's just hard to get over the inertia and start an RFC to change... Something. --Izno (talk) 13:28, 9 September 2020 (UTC)

Ah, I think I found the actual last time. See Help talk:Citation Style 1/Archive 62#Bolding of the volume number. Even came up with the question and still couldn't manage to herd the cats. :) --Izno (talk) 02:35, 10 September 2020 (UTC)

Proposal: All templates using Citation Style 1/2 produce a consistent display when |page= or |pages= are used, in the format of "p. n" or "pp. xx-yy", as is currently the case when (e.g.) {{cite book}} or {{cite magazine}} is used. Mjroots (talk) 11:37, 10 September 2020 (UTC)

Does this proposal also change how cs1|2 shall render the p. and pp. prefixed pagination? In the proposal, the p. and pp. prefixed pagination to be produced by cs1|2 for |page= and |pages= is written this way:

p.<space>''n''

pp.<space>''xx<hypen>yy''

Presumably the italic markup in the proposal is intended to convey the semantic meaning of 'variable'. However, because the proposal does not use <var>...</var> or {{var}} it is not possible to know if 'variable' is the intent of the italic markup or if italic markup is a new requirement. In its present form, cs1|2 renders |page= and |pages= this way:

p.&nbsp;<page-number>

pp.&nbsp;<page-number><endash><page-number>

The proposal specifies a format but then also says to use the current {{cite book}} or {{cite magazine}} formatting. I don't think that it is possible to do both.

—Trappist the monk (talk) 13:26, 10 September 2020 (UTC)

Trappist the monk Not sure exactly what you mean, cite book and cite magazine both insert a space after p./pp., do they not? If there are cases where "p.n and "pp.xx-yy" are produced, then yes, the proposal is to change them to introduce a space. In instances where p./pp. are not present (e.g. {{cite journal}}), then the proposal changes the display to include p./pp. followed by a space Mjroots (talk) 13:52, 10 September 2020 (UTC)

cs1|2 separates the p. and pp. prefixes from the page number or page numbers with a no-break-space character ( ) but your proposed format (in the format of "p. n" or "pp. xx-yy") uses a plain space character. cs1|2 separates the starting page number from the ending page number in a range with an endash character (–) but your proposed format uses a hyphen character (-).

Is it your intent that cs1|2 discontinue use of the no-break-space character and instead use a plain space character? Is it your intent that cs1|2 discontinue use of the endash character and instead use the hyphen character? Is it your intent that cs1|2 italicize page numbers when they follow the p. and pp. prefixes?

—Trappist the monk (talk) 14:11, 10 September 2020 (UTC)

No, it is not my intent to change the use of non-breaking spaces, endashes or to put page numbers in italics. The latter was shown for clarity as to what the proposal was, apologies if it misled. Mjroots (talk) 15:01, 10 September 2020 (UTC)

• Support as proposer. Mjroots (talk) 11:37, 10 September 2020 (UTC)
• Support. The main opposition to this is its inconsistency with the way academic journals are cited elsewhere, a strange argument. First it trades internal Wikipedia style consistency for some unrelated system's consistency. Secondly, it assumes the average Wikipedia reader (anyone of the millions of unique IPs that visit Wikipedia everyday) would be familiar with academic citations. Finally, it is a case of "that' how's being done/that's what I know. Why change?" This last one ignores the valid recurring questions about it. 172.254.241.58 (talk) 12:36, 10 September 2020 (UTC)
• Oppose – As Trappist the monk observed, the proposal introduces several dis-improvements (not-adherence to MOS:NUMRANGE and MOS:ITALICS). Further, when journal sources are consulted, they show the existing format emitted by {{cite journal}}, so this is in line with established practice for journals. If the cited source is not a journal, other templates are available. -- Michael Bednarek (talk) 14:44, 10 September 2020 (UTC)

@Michael Bednarek: - see my clarification above. Mjroots (talk) 15:01, 10 September 2020 (UTC)

• This RFC is premature and ignores the previous discussions that we've had regarding the set of volume/issue/pages as linked above to you. Please consider withdrawing and/or submitting a new RFC that takes those discussions into account. --Izno (talk) 16:44, 10 September 2020 (UTC)

Izno, you said in this very thread "Generally, this comes up once every year or so in some fashion; it's just hard to get over the inertia and start an RFC to change... Something". Therefore I've started the ball rolling. SMcCandlish made an excellent comment in the first discussion linked to. The second discussion, which you linked to is not about page numbers. I've put a firm proposal forward to standardise the display of page numbers whichever template is used, without changing the use of non-breaking spaces, endashes or the display of said page numbers. This proposal does not impact on the display of any other parameter even where those parameters may produce a different display for different templates. Mjroots (talk) 18:28, 10 September 2020 (UTC)

@Mjroots: Please review the second discussion then because it clearly is about page numbers and about the holistic approach we should take with the deviant cite journal. --Izno (talk) 18:49, 10 September 2020 (UTC)

Indeed it makes sense to consider |volume=, |number=/|issue= and |pages= together. That discussion identified three coherent alternatives to the status quo, and that would be a sensible basis for an RFC. Kanguole 10:53, 11 September 2020 (UTC)

That might be too big a jump for some editors though. One step at a time might be the better approach here. If we can get agreement to harmonise one parameter, then that can provide weight to the argument to harmonise other parameters. Mjroots (talk) 11:26, 11 September 2020 (UTC)

Still, I think, the parameters need to be seen in a larger context. Therefore, I, too, think that an RfC just focussing on "pp." is premature. Our citation templates are also used in other-language entities of Wikipedia, so, even if we would support only one style any more here, the other entities may still need to support the other styles as well. This clashes with the current modus operandi to remove support for unused features in the citation templates. So, in order to address the requirements of all involved parties, IMO it makes more sense to introduce means to control the style independent of if {{cite journal}}, {{cite magazine}}, etc. have been used and perhaps change the defaults we use in the English Wikipedia.

There is more than one way how to achieve your goal of getting the "pp." in the end, and your approach of just changing the output to "pp." in {{cite journal}} in general might cause problems elsewhere if the larger context isn't taken into account in a solution. Therefore, I suggest a more general solution which would allow you to get what you want, but would address other requirements as well. And that can be had without an RfC.

--Matthiaspaul (talk) 10:11, 13 September 2020 (UTC)

• Support. Telegraphic citation styles established by journals in days when paper was expensive do a disservice to readers who cannot be expected to know the conventions on which of these unspecified numbers is the volume number, which is the issue number, which is the series number, and which are the page numbers. Consistency with other types of citations is an improvement. However any change of this nature should be done simultaneously to both Citation Style 1 and Citation Style 2; we should not pull those two styles farther out of synch with each other. —David Eppstein (talk) 20:08, 10 September 2020 (UTC)

Excellent suggestion, David Eppstein. Have added "/2" to the RFC. Mjroots (talk) 07:34, 11 September 2020 (UTC)

• Support, exactly per David Eppstein. I would add that the boldfacing of volume numbers needs to stop, and should never have applied to anything but this telegraphic style. (I keep running into it in citations that are not to journals.) The only rationale for the bolding, which is only a feature of certain off-site citation styles, is distinguishing the volume number from the issue number more clearly, and that is only needed in this dumb hyper-compressed style. PS: Yes, it should be pp.&nbsp;<page-number><endash><page-number> (MOS:DASH, etc.).  — SMcCandlish ☏ ¢ 😼  11:30, 11 September 2020 (UTC)
• Comment. I support the goal to have a consistent style within an article, but I can also see a desire to style different types of articles differently, at least optionally. Therefore, rather than to make the rendering style dependable on the citation template used or to only allow one style in general, I would like to see a setting (hypothetical named |periodical-mode= or |periodics-mode= as a discussion handle), which would allow to switch the display of volumes, numbers, issues and pages between a number of predefined combinations (about 3 to 7, see further above). If we would want to keep supporting different citation templates for {{cite journal}}, {{cite magazine}}, {{cite newspaper}} etc., they could have different |periodical-mode= defaults, but in all templates it should be possible to override the default to achieve an article-wide consistent look. --Matthiaspaul (talk) 12:20, 11 September 2020 (UTC)
• How difficult would it be to have a template to create a profile for an article and for the cs1/cs2 cite templates to use the article profile for the default formatting options? Shmuel (Seymour J.) Metz Username:Chatul (talk) 13:11, 11 September 2020 (UTC)

You mean something like auto-date formatting? If we would have the code to switch between multiple predefined styles selectable by a template-parameter like |periodical-mode=, extending this model to evaluate a "global" parameter similar to |cs1-dates= would not be difficult (also for |(cite-)mode=). (This, however, is because most of the infrastructure for this exists due to the great work Trappist has done to make auto-date formatting a reality.) --Matthiaspaul (talk) 13:31, 11 September 2020 (UTC)

• Support, the inclusion of "p." or "pp." for page number in journal citations. The current system is ambiguous and certainly not clear what is meant by the string of numbers in these citations. It should be obvious without any prior knowledge what it means. Will achieve consistent output when there are a mixture of journal, magazine, news etc. n a single article.

Also good to do it in small steps and not get tied up with trying to change everything at one go which will end up getting nowhere. Keith D (talk) 17:38, 11 September 2020 (UTC)

A possible smooth path to go would be to provide a new parameter like the suggested |periodical-mode=, including a setting for the new combination of scientific periodical notation with "pp." for pages instead of the traditional ":", perhaps even make this the default for {{cite journal}}. The settings could be as follows:

• |periodical-mode=symbolic → v (i[ #]n), pp. p[–p]. Example: 15 (11 #179), pp. 14–23.
• |periodical-mode=scientific → v (i[ #]n): p[–p]. Example: 15 (11 #179): 14–23.
• |periodical-mode=abbreviated → Vol. v no. i[ #]n. ... p[p]. p[–p]. Example: Vol. 15 no. 11 #179. ... pp. 14–23
• |periodical-mode=full → Volume v, Number n, Issue i, Page[s] p[–p]. Example: Volume 15, Number 179, Issue 11, Pages 14–23.

At a later stage, a global parameter for article-wide settings (similar to how auto-date formatting works at present) could be provided as well.

This would achieve the goal of having easy means to bring articles into a consistent style while at the same time keep options to select from a set of other styles on the basis of individual articles or citations to support specific needs. We would thereby not risk throwing the baby out with the bathwater.

--Matthiaspaul (talk) 10:11, 13 September 2020 (UTC)

• Oppose treatment of |pages= in isolation from the other parameters subject to journal-style formatting, namely |volume= and |number=/|issue=. These were all designed to fit together, and a coherent format needs to deal with all of them. Kanguole 10:34, 13 September 2020 (UTC)

This is a valid point, but it does not invalidate the present discussion, it enhances it: The same parameters should render the same way anywhere in the citation system. Also, |volume= has a further, internal inconsistency. Not only the display varies depending on the template, it also varies depending on length. Funny! I think. 2A01:B747:79:314:39AE:1263:C82B:88E8 (talk) 01:38, 14 September 2020 (UTC)

No, the same parameters should absolutely not render the same way anywhere in the citation system. Consider |title=, which we want to be different for major (Books) and minor works ("Article"s). – Finnusertop (talk ⋅ contribs) 16:26, 5 October 2020 (UTC)

Value for script-title

I presume my remarks apply to the other script parameters as well, but I haven't checked.

The documentation of |script-title= says that the value may start with a language prefix. As the big change to Module:Citation/CS1 in September 2019 now red-inks the citation if the prefix is missing, should it be changed to must? I noticed this issue in the incubator, where we don't have a bot changing the parameters of {{cite-book}} etc. --RichardW57 (talk) 07:24, 9 October 2020 (UTC)

Fixed.

—Trappist the monk (talk) 10:41, 9 October 2020 (UTC)

While commendable, that's not what I'm talking about. The problem was that a Thai script |script-title= started spewing red ink because it wasn't prefixed by a script language code. Prefixing by a language identifier is documented as optional, not mandatory. --RichardW57 (talk) 18:18, 9 October 2020 (UTC)

You asked: should it be changed to must? (emphasis in original). The answer to that question is: yes. So I fixed the documentation. Now you are complaining that I made the change. What am I to make of that? The purpose of the various |script<param>= parameters is to provide proper markup so that browsers render, and screen readers speak, the non-English text using more appropriate fonts and pronunciation (and various other stuff like isolating right-to-left languages from left-to-right).

—Trappist the monk (talk) 19:33, 9 October 2020 (UTC)

You missed out Help:Citation_Style_1, so I'd assumed you hadn't made the change I expected. I now see you've done it in {{cite-book}}, so it's down to the tedious job of proof-reading and fixing where overlooked. I'm not doing it tonight. --RichardW57 (talk) 00:36, 10 October 2020 (UTC)

There was only one missed case - and that was for a parameter that wasn't supported anyway! --RichardW57 (talk) 15:33, 10 October 2020 (UTC)

It's curious to see that the Thai port hasn't added 'en' as a script language code - surely they're not tagging English titles as Kurdish! Possibly they're not getting transliterated for references. --RichardW57 (talk) 18:18, 9 October 2020 (UTC)

This is en.wiki. If you have issues with how th.wiki uses the module suite, you must take it up with editors there. We have no control over how they use the modules.

—Trappist the monk (talk) 19:33, 9 October 2020 (UTC)

Given the effort made to support localisation, I did wonder why the major Latin script languages weren't catered for. I am still not sure why only a few language codes rather than all 2- and 3-letter codes are catered for. I started looking for more sophisticated support. --RichardW57 (talk) 00:36, 10 October 2020 (UTC)

The reason is because special treatment (like BDI) is not needed for English text, therefore the normal |title= parameter could be used (however, |trans-title= may require adaptation to support language prefix codes in some locales).

For other reasons I also propose to improve the |script-= parameters to accept all language codes (while internally still only treating those scripts special which actually need it), see:

• Help talk:Citation Style 1/Archive 67#Possible improved treatment of title parameters and language attributes
• Help talk:Citation Style 1/Archive 73#Guidance about indexing by first name?

--Matthiaspaul (talk) 08:41, 13 October 2020 (UTC)

'publication-date' error

{{cite web|author=Author|date=c. 1980|url=http://www.example.com|title=Title|website=Website|publication-date=c. 2010}}

-displays with error:

Author (c. 1980). "Title". Website (published c. 2010). {{cite web}}: |author= has generic name (help)

??? 98.0.246.242 (talk) 02:20, 13 October 2020 (UTC)

|publication-date= does not take all date formats accepted by the |date= parameter. At present there are two possible workarounds:

{{cite web |title=Title |author=Author |date=c. 1980 |publication-date=2010 |website=Website |url=http://www.example.com}}

Author (c. 1980). "Title". Website (published 2010). {{cite web}}: |author= has generic name (help)

{{cite web |title=Title |author=Author |date=c. 2010 |orig-date=c. 1980 |website=Website |url=http://www.example.com}}

Author (c. 2010) [c. 1980]. "Title". Website. {{cite web}}: |author= has generic name (help)

However, to actually solve this issue, |publication-date= should accept a few more formats (but still only a sub-set of those supported by |date= as not all make sense for a publication date), see also: Help talk:Citation Style 1/Archive 69#Publication date.

--Matthiaspaul (talk) 09:07, 13 October 2020 (UTC)

Ok. May I suggest allowing all date formats in |publication date= on Wednesdays. That would make it even more quirky.

I don't want to touch the doc issue again, but there is no indication of the behavior of publication date there. It also mentions that "published" displays only when the work is missing. This is not so. 172.254.241.58 (talk) 11:39, 13 October 2020 (UTC)

redundant_parameters

• Nephilim (edit | talk | history | protect | delete | links | watch | logs | views)
• People linked to Anwar al-Awlaki (edit | talk | history | protect | delete | links | watch | logs | views)

See "Lua error in Module:Citation/CS1/Utilities at line 129: Called with an undefined error condition: redundant_parameters." in these two articles. They are due to edits by Citation bot: diff + diff. The first problem is in the following wikitext from ref 12. While that could be fixed, the undefined issue might need attention in the module.

{{cite conference
|last=Salvesen
|first=Alison
|title=Symmachus Readings in the Pentateuch
|booktitle=Origen's Hexapla and Fragments: Papers Presented at the Rich Seminar on the Hexapla, Oxford Centre for Hebrew and Jewish Studies, [July] 25 – 3 August 1994
|page=190
|publisher=Mohr Siebeck
|year=1998
|isbn=9783161465758
|url=https://books.google.com/books?id=9xQDu27_HEIC&pg=PA190
|ISBN=9783161465758
|quote=The rendering "he fell upon, attacked" [in Symmachus, Genesis 6:6] is something of a puzzle ... If it has been faithfully recorded, it may be related to the rendering of Aquila for the Nephilim in 6:4, {{lang|grc|οι επιπιπτοντες}}.
}}

Johnuniq (talk) 04:21, 13 October 2020 (UTC)

Fixed. Thanks.

—Trappist the monk (talk) 11:18, 13 October 2020 (UTC)

support for |editors= withdrawn (in the sandbox)

{{cite book/new |title=Title |editors=A list of editors}} → Title. {{cite book}}: Unknown parameter |editors= ignored (|editor= suggested) (help)

—Trappist the monk (talk) 13:17, 13 October 2020 (UTC)

No objection to this as a whole, but simply suggesting the singular |editor= might lead to less experienced users replacing this now-deprecated parameter with something like |editor=Joe Bloggs, Jane Doe, and John Doe. Glades12 (talk) 18:41, 13 October 2020 (UTC)

That will generate a maintenance message: {{cite book/new |title=Title |editor=Joe Bloggs, Jane Doe, and John Doe}} → Joe Bloggs, Jane Doe, and John Doe (ed.). Title.{{cite book}}: CS1 maint: multiple names: editors list (link) – Jonesey95 (talk) 19:21, 13 October 2020 (UTC)

Discussion at Wikipedia talk:Citing sources § "Work" versus "agency" versus "publisher"

 You are invited to join the discussion at Wikipedia talk:Citing sources § "Work" versus "agency" versus "publisher". {{u|Sdkb}} ^talk 19:16, 13 October 2020 (UTC)

Smart substitution token to reduce redundancy among input parameters

I would propose a somewhat different implementation of this introducing a generic placeholder * into the syntax of the |archive-url= parameter. This would result in:

{{cite web |url=https://example.com/page |title=Example page |website=Example.com |date=2020-08-04 |archive-url=https://web.archive.org/web/20200721125421/* |archive-date=*}}

The substitution would happen only if the |archive-url= contains exactly one * (not necessarily at the end of the link).

* is not normally used in urls (even less in archive links), but it can. In the case of archive.org, it is used as a wildcard for the timestamp, however, this isn't used in valid archive links (only internally by the template to help users select a specific snapshot). To not cause misinterpretation, this archive.org special syntax would have to be special-cased, so that if the * would be located inside the timestamp no substitution by |url= should happen.

My proposal is not as short as Nixinova's proposal, but it is more flexible and could work also for a number of other archivers - and without having to add a new parameter or even a bunch of special |...-timestamp= ones.

The main reason, however, why I used * is another more generic feature proposal I planned to make for quite some while, where * would be a "smart" context-sensitive placeholder also supported in various other parameters:

It would substitute whatever is a sensible replacement string in the context of a particular parameter:

• For example, |access-date=* would be substituted with the value of |publication-date= or |date= (if given, otherwise an error would be thrown instead of silently ignoring the parameter as what would happen for an empty parameter).
• |archive-date=* would be substituted with the value of |access-date= (likewise).
• |website=* would extract the domain name from |url=.
• |title-link=... * ... would implant the value of |title= at the position of the * (e.g. |title-link=* (song). Our |title-link=((...)) "take it as it is" ((syntax)) would allow for |title-link= to actually contain a * - in this case, the parameter substitution would be disabled. (TBD. What would be the best substitution if |trans-title= and/or |script-title= were used as well?)

Example: ... {title=Flying Circus |title-link=Monty Python's * (album) |date=...

• |author-linkn=... * .../|editor-linkn=... * ... etc. In the simple case, the substitute for * would be the value from |authorn=/|editorn=, the ((syntax)) would be supported as well. If the name is composed from multiple parameters such as |author-firstn=/|author-lastn=, the substitute would be the resulting string. This would allow for things like:

... |author-first=William |author-last=Shakespeare |author-link=* (author) |date=...

or

... |author-first=Otto |author-last=Sander |author-link=:de:* (actor) |date=...

A single * would result in the composition of "<first> <last>" (because this is the most likely substring used in article titles), a doubled ** would result in "<last>, <first>" (comma, semicolon etc. depending on other template settings), a triple *** in only the "<last>" name. If someone would use ** or *** in |author-linkn= in conjunction with |authorn= rather than |author-firstn=/|author-lastn=, this would result in the contents taken from |authorn= as well (like a single *).

(TBD. At some point in the future we will probably support the full set of |trans-authorn=/|script-authorn= parameters. If they exist, the source values for the substitution should be derived from these parameters. The exact patterns are still TBD to maximize the utility value.)

• |author-maskn=... * ... etc. would support substitution as well. In this case, * would result in the composition of <first> and <last> according to the default order used by the template (or the setting of the |af= parameter once proposed by Headbomb to override the default order); at present (and without |af=), this would be "<last>, <first>" (because the format used in the |-mask= parameters is most likely needed to be in the same order as in the normal display of author names without |author-mask=). A doubled ** would result in the opposite order of the one selected by *; at present, this would be "<first> <last>". Triple *** would result in only the <last> name. Again, if someone uses *, ** or *** in |author-maskn= in conjunction with |authorn= rather than |author-firstn=/|author-lastn=, the value of |authorn= is taken as a replacement.

So much for the overview. There are a number of special cases not discussed yet, but I think you already get the idea: One easy to remember global placeholder * as a generic smart and context-specific placeholder, possibly doubled ** or tripled *** to switch the output format depending on context (similar to different signatures being issued with ~ ~~ ~~~ ~~~~ or different link types being used depending on if using single or doubled brackets etc.) Since, in the context of each parameter, it is quite obvious what would be a reasonable source for the substitution (AFAI see it, there is always only one source which really makes sense), this scheme is easy to remember and use. It would be backward compatible and optional to use, it would reduce the amount of required manual input, reduce the risk for many typos, may make many citation templates easier to read on source code level (YMMV) without having to reduce the amount of provided info, and it would even save some storage space.

--Matthiaspaul (talk) 14:48, 8 August 2020 (UTC)

Taking a citation from the #Editors thread, here are two examples, how they could be simplified using the * placeholder, avoiding the hardcoded name in the |-mask= parameter:

Example 1:

{{cite book |title=The Rolling Stone Illustrated History of Rock & Roll |chapter=The Beatles |author-last=Marcus |author-first=Greil |author-link=Greil Marcus |editor1=DeCurtis, Anthony |editor2=Henke, James |editor3=George-Warren, Holly |editor-mask3=with George-Warren, Holly; |editor4=Miller, Jim}}

This could be reduced to:

{{cite book |title=The Rolling Stone Illustrated History of Rock & Roll |chapter=The Beatles |author-last=Marcus |author-first=Greil |author-link=* |editor1=DeCurtis, Anthony |editor2=Henke, James |editor3=George-Warren, Holly |editor-mask3=with *; |editor4=Miller, Jim}}

(Note that the substitution in |author-link= would be "Marcus Greil" (contents of |author-last= and |author-first= combined in form "<first> <last>" per one *) and in |editor-mask3= it would be "George-Warren, Holly" (contents of |editor3=).)

Example 2:

{{cite book |title=The Rolling Stone Illustrated History of Rock & Roll |chapter=The Beatles |author-last=Marcus |author-first=Greil |author-link=Greil Marcus |editor-last1=DeCurtis |editor-first1=Anthony |editor-last2=Henke |editor-first2=James |editor-last3=George-Warren |editor-first3=Holly |editor-mask3=with George-Warren, Holly;<!-- need to hardwire this here --> |editor-last4=Miller |editor-first4=Jim}}

This could be reduced to:

{{cite book |title=The Rolling Stone Illustrated History of Rock & Roll |chapter=The Beatles |author-last=Marcus |author-first=Greil |author-link=* |editor-last1=DeCurtis |editor-first1=Anthony |editor-last2=Henke |editor-first2=James |editor-last3=George-Warren |editor-first3=Holly |editor-mask3=with *; |editor-last4=Miller |editor-first4=Jim}}

(Note that the substitution in |author-link= would be "Marcus Greil" (contents of |author-last= and |author-first= combined in form "<first> <last>" per one *) and in |editor-mask3= it would be "George-Warren, Holly" (contents of |editor-last3= and |editor-first3= combined in the (default) form "<last>, <first>" per one *).)

--Matthiaspaul (talk) 12:32, 10 August 2020 (UTC)

See also: Help_talk:Citation_Style_1/Archive_70#Small_glitches_masking_and_linking_author_names

--Matthiaspaul (talk) 09:28, 16 August 2020 (UTC)

What's the benefit given by the having the entire prefix over just a timestamp? Having the start of the URL is unnecessary.  Nixinova   T   C   07:48, 27 August 2020 (UTC)

Yes, an advantage of your proposal is that it is shorter, but as is it would only work for archive.org. So, if we would want to support other archiving sites in a similar fashion, we would have to introduce similar parameters for them as well. As we try to remain agnostic of specific third-party implementations (where possible), adding a special case only suitable for archive.org would not be ideal. That's the downside.

My proposal, while not as short as yours, has the advantage that it potentially works with a number of other archiving sites as well depending on what kind of link scheme they use (admitted, it, too, would not work with all of them).

Also, it would not require the introduction of a new parameter. You know, individual parameter names need to be remembered by users (while your |wayback-timestamp= parameter name is not a bad name, it does not fit into the scheme of |url=- nor |date=-related names). If the names follow a broader scheme, it becomes easier to remember them without remembering each specific one.

The reason why I brought up my "counter-proposal" now is not that I don't like your proposal (I like it), but to discuss it in the context of a more general citation template-wide "redundancy removal" scheme (I like even more). It would be possible to implement both as independent features, but if it is part of a broader placeholder concept, it might gain more traction (if the placeholder concept would be implemented someday, that is).

The placeholder * would be documented as a generic syntax element supported in various parameters, whereever we see fit. This would be similar to the ((take-this-as-it-is)) syntax we also support in various places (and, perhaps, the proposed parameter review scheme to improve the quality of citation contents) as a general concept.

The placeholder idea, if it works, is that the user, whenever s/he runs into the situation where s/he is about to enter a parameter value which is repeating a value already entered, will recall that citation templates support a general feature of a smart placeholder * that can be utilized to avoid this repetition.

For this to work, it would have to be highly intuitive (that is, almost obvious or at least very easy to remember) which other parameter value would be used by the template as a source for the substitution. Ideally, there would be only one possible source which "makes sense", so that the user can derive it with intuition instead of having to consult the documentation.

In the case of redundancy in the |archive-url= and |website= parameters, there is only one possible source for substitution, the |url= parameter value. Likewise, in the case of the |-link= and |-mask= parameters, it is obvious that the corresponding author/editor etc. or title parameters must be the source. In the case of |access-date= and |archive-date= there are several potential sources, but only one actually makes sense for each of them. Does it make sense to derive the |access-date= from the |archive-date=? No, because |access-date= belongs to |url=, not |archive-url=, so the user can rule this out without looking up the documentation, thereby being sure that the source would be |publication-date=/|date=.

In my opinion, the only parameter, for which there is some ambiguity in regard to the potential source of substitution is the |archive-date= parameter. In cases, where the |archive-url= contains a timestamp, this could be a source (if we would implement code to detect timestamps in links from certain TLDs). The next likely source would be |access-date= followed by |publication-date=/|date=. Deriving |archive-date= from |access-date= makes sense if the archived snapshot was initiated by the editor himself. Deriving |archive-date= from |publication-date=/|date= might only makes sense in the absense of |access-date= (assuming that the archived snapshot was initiated by the publisher of the work). However, this might be something the user would actually have to remember (rather than be able to guess) and not use the placeholder if both potential source dates are given (and not equal) and the desired source would not be the |access-date=. (If this would be found too complicated the rule could be simplified by only allowing |access-date= as potential source.) But otherwise, the scheme appears to be highly intuitive to me.

--Matthiaspaul (talk) 13:49, 5 September 2020 (UTC)

Above I wrote: "the |archive-date= parameter. In cases, where the |archive-url= contains a timestamp, this could be a source (if we would implement code to detect timestamps in links from certain TLDs)." Of course, if we would allow to make the |archive-date= parameter optional, we could simply omit it if the |archive-url= value is from a recognized archiver containing the timestamp already. The example above would then reduce to:

{{cite web |url=https://example.com/page |title=Example page |website=Example.com |date=2020-08-04 |archive-url=https://web.archive.org/web/20200721125421/*}}

which is almost as short as Nixinova's alternative proposal (after all, the full archive link to be truncated down must be available in both cases), but more flexible, and without having to add a new parameter for this.

--Matthiaspaul (talk) 10:46, 15 October 2020 (UTC)

The proposed smart placeholder token for the |-mask= parameter should not only take display styles (name order "last, first" vs. "first last") into account but also national naming conventions (as controlled by another proposed parameter like |name-mode= or, even better, the language prefixes of |script-name-*= parameters), see Help_talk:Citation_Style_1#Guidance_about_indexing_by_first_name?

--Matthiaspaul (talk) 11:50, 22 September 2020 (UTC)

ISBN wikilinks on Template:Cite book (edit request)

When the "cite book" template is used to create a reference, the link for "ISBN" points to ISBN (identifier), which redirects to the page International Standard Book Number. However, the link ISBN also points to the same target, which defeats the purpose of using ISBN (identifier) instead. Could this link in the template be changed to either the correct target article or simply ISBN? Thanks. — Paper Luigi ^{T • C} 21:06, 19 October 2020 (UTC)

Did you read the rationale at ISBN (identifier)? Are you seeing someplace where the ISBN (identifier) redirect fails to link to International Standard Book Number?

—Trappist the monk (talk) 21:37, 19 October 2020 (UTC)

I didn't read that rationale because I didn't think to check the actual redirect page first. I hadn't seen a page with that disclaimer before (granted, there are only 55 redirect pages in that category). No, I didn't see the redirect link fail anywhere before posting. I guess it makes more sense now that I've taken that into account. Thanks. — Paper Luigi ^{T • C} 21:48, 19 October 2020 (UTC)

To search or not to search

Hi all.

I recently upgraded our talk page archiving bot from SigmaBot to ClueBot III because the latter claims to fix up links while archiving (see: Keeping linked and Talk page linking with automatic link recovery after page archiving). It also creates an index. While the fix-up of links from other pages seems to work, there is still a problem with links from this talk page itself (hopefully this will be fixed soon, see: Cluebot III did not fix up a link while archiving a talk page thread).

Also, the appearance of talk archives was changed to provide a navigation bar ({{Automatic archive navigator}}) and a search box ({{Search box}}), so that it becomes much easier to browse through past discussions to find old feature requests and other snippets of information relevant for ongoing discussions and the further improvement of our citation templates.

However, Izno removed the search box from our local bot profile on this talk page again ([1]), so that future archives will not have it unless my change gets restored. Without the search box, one first has to load the talk page to use the archive search box from there. (Like all pages, the talk archives also provide the standard search box in the upper right corner, but this is for "global" search, not refined to archived discussions already.)

I find the search box tremendously helpful when researching old citation-related topics and can't see a good reason why we would not want to have it for convenience and to save time. Therefore, I'm asking for opinions on this per WP:BRD.

--Matthiaspaul (talk) 11:38, 25 September 2020 (UTC) (updated 15:43, 25 September 2020 (UTC))

May I ask what was Izno's rationale for removing the search feature. 64.18.9.200 (talk) 12:03, 25 September 2020 (UTC)

Honestly? I'm greedy and want to be able to read archives on mobile in Timeless without having to fight with my browser, yet the search bar is an absolute width in px (for which I've submitted a phab task about making it responsive...).

Secondly, it's rare if not unheard-of to have a search bar on each archive page, which is what your change added. I would gather the current search pattern on most talk pages is "search from main page, ctrl+F where necessary on specific pages if the search results aren't perfect". (This page of course does not need a search bar as it already has one; the one on this talk page annoys enough already :). --Izno (talk) 13:38, 25 September 2020 (UTC)

If this is really something that is difficult to use in Timeless, I support changing the format of the search box from an absolute width to the (much smaller) default width, and hopefully to something responsive, eventually. Izno, can you provide a link to the phab task you mentioned?

In general, I still find it unnecessarily inconvenient having to return to this talk page to initiate new searches instead of being able to enter them on a page provoking the search.

Search boxes on archive page are rare, but I assume this is down to the fact that most archives are "dead storage" of no longer needed stuff which noone is interested in anymore. In our case, however, the archives are a repository actively used to search for a large backlog of still unresolved issues, and proposals and discussions how to fix issues, as well as many snippets of valuable citation-related information which are helpful addressing new problems. For the while being, the archives also fill gaps in the citation documentation. Some stuff is definitely outdated, but quite a lot of it is still valid and useful today. Therefore, I think, it is desirable to make browsing and searching the archives as easy as possible, and, at least in my judgement, the lack of a search box is hindering more in this endeavour than its existence.

More opinions?

--Matthiaspaul (talk) 12:16, 20 October 2020 (UTC)

phab:T255499. --Izno (talk) 13:50, 20 October 2020 (UTC)

Thanks. --Matthiaspaul (talk) 15:21, 20 October 2020 (UTC)

support for various deprecated parameters withdrawn

support for deprecated parameters |authormask=, |displayauthors=, |editorlink=, |ignore-isbn-error=, |subjectlink=, |authormask#=, |author#mask=, |editorlink#=, |editor#link=, |subjectlink=, |subject#link= has been withdrawn.

—Trappist the monk (talk) 13:52, 13 October 2020 (UTC)

support for |lastauthoramp, |last-author-amp withdrawn

—Trappist the monk (talk) 14:07, 13 October 2020 (UTC)

Ouch! That's reached 18,000 red-inked references, and growing. I unreliably recall that it was only at 12,000 articles with deprecated parameters a few days ago. It's definitely risen by over a 100 this evening as pages get regenerated. --RichardW57 (talk) 00:10, 16 October 2020 (UTC)

Yep, the count is increasing. There is a pending bot task to deal with the |last-author-amp= parameters and there are several gnomish editors using awb to clear articles from the category.

—Trappist the monk (talk) 00:24, 16 October 2020 (UTC)

How does one remove Wikipedia:Reliable sources/Noticeboard/Archive 200 from the maintenance category? Or does it live in the category for ever? --RichardW57 (talk) 00:24, 21 October 2020 (UTC)

You can still edit archives, just not section edit. That said, it's important to preserve the sense of the original if possible, so some archives should be converted while others might use whatever the no-tracking parameter is now. --Izno (talk) 00:39, 21 October 2020 (UTC)

Which I did...

—Trappist the monk (talk) 00:41, 21 October 2020 (UTC)

Episode number

Is there a way to use an alternative episode number? Like when shows merge and release two episodes as one. Or renumbering due to missing or banned episodes. 119.93.40.241 (talk) 14:47, 16 October 2020 (UTC)

I don't have a really clear understanding of your question but cs1|2 does not automate episode numbers so whatever you give it will be what it renders. If you believe otherwise, please provide an explicit example of such a template here.

—Trappist the monk (talk) 14:59, 16 October 2020 (UTC)

For example:

{{cite-episode
   | title = 
   | episode number =
   | alt episode number =  <-- something like this, for new numbering, let's say a show re-run with some episodes renumbered to reflect, e.g.,  a previously unreleased episode or a previously two-part episode merged and renumbered as one 
  }}— Preceding unsigned comment added by 119.93.40.241 (talk) 15:21, 16 October 2020 (UTC)

That looks like you are trying to cite multiple sources with a single template. cs1|2 is not designed to do that. Cite the episode number of the episode that you consulted to support the en.wiki article text. If you are simply making a list of episodes using {{cite episode}}, one template per episode.

—Trappist the monk (talk) 15:30, 16 October 2020 (UTC)

I understand the IP's question as how to cite a single source which has become known under different numbers over time.

In general, the rule is to cite the work in front of you, but I can understand the desire to mention alternative numbers as well within the same citation, if not to avoid confusion. Since {{cite episode}} does not seem to support |id= (why?), I would add such information as a nota bene comment immediately following the citation (but still inside the <ref></ref> framing).

--Matthiaspaul (talk) 16:14, 16 October 2020 (UTC)

As far a I know, |id= has never been a parameter supported by {{cite episode}}. The {{citation/core}} version of {{cite episode}} usurped |id= to support |network= and |station=. The Lua version continued that.

—Trappist the monk (talk) 16:58, 16 October 2020 (UTC)

unfit url: maint or property?

The tracking category for pages using |url-status=unfit or |url-status=usurped, Category:CS1 maint: unfit url, seems like it would make more sense as a property category, much like Category:CS1: long volume value, given that there are legitimate uses for those values. -BRAINULATOR9 (TALK) 20:52, 27 October 2020 (UTC)

We've had one or two (not recent?) discussions about whether it should be maintained. For example, someone might feasibly misuse the parameter to remove a URL that doesn't need removing, where maybe it should be the case that someone should check that each instance of unfit is a good use. We don't have any sort of obvious queue for doing so though. Maybe we should, whether that's another parameter (like doi-broken-date maybe) or a bot-maintained page where we can check uses off or something. --Izno (talk) 21:48, 27 October 2020 (UTC)

Proposed documentation and parameter alias changes for Template:Cite_episode

Template:Cite episode could use some updating and flexibility. This is a 5-part proposal (some of the parts are inter-dependent).

1) The template has a parameter documented thus:

• station: Call letters of the local station (if any).

I propose giving this some aliases (at least |channel=). Then revise the documentation to be more flexible/useful/global, and less tied to the old-school (especially American) airwave broadcasting model which is decreasingly relevant:

• station: In US broadcasting and that of several other countries, usually used for the call letters or other local station identifier (e.g., |station=[[WGBN]]). It can also be used for channels and network divisions for systems arranged differently (e.g., |channel=[[BBC Four]]|network=[[BBC]]), and for Internet "TV" channels (e.g., |channel=[[Gamers Nexus]]|carrier=[[YouTube]] While some cable networks have "Channel" in their names, they belong in the network parameter. Aliases: channel (not used for local broadcast/cable channel numbers).

2) Next, |network= should probably also have an alias of something like |carrier= and perhaps |platform= for situations that don't pertain to old-school broadcasting/cable. The current doc reads:

• network: The network the episode was aired on. (e.g. ABC, NBC, CBS, Fox, Disney, USA Network, BBC)

This could be updated to something like:

• network: In broadcasting and cable, the network that the episode was aired on (e.g., ABC, NBC, CBS, PBS, Fox, Disney, USA Network, BBC, CBC, etc.). In Internet "TV" and "radio", the originating carrier/platform (e.g. YouTube, Netflix, Amazon Prime Video, Audible, Buzzsprout, etc.). Note: When a website like YouTube is not acting as an original carrier but is doing post-airing redistribution of archival material, use the via parameter to indicate where to find it (e.g. |via=YouTube). While many traditional broadcasters now also officially provide some of their material via such sites, remember that under Wikipedia:Copyright policy, it is not permitted to link to probably-infringing copies posted by random individuals. Aliases: carrier, platform.

(Included PBS, and a Canadian network, and also provided an audio-only example for the online side. Also, distinguished this from |via=, and added a long-overdue copyright note.)

3) One problem, however, is the parameter order (which doesn't even make sense without the above two changes). |channel= should come before |network=. In the expanded usage above, the |channel= alias for |station= is usually going to be more closely tied to the content (|series=, etc.), while |network= AKA |carrier=, has a much more tenous connection to the content (just as for books and periodicals |publisher= is less connected to the content than the author and editor name parameters and the title of the work and/or any chapters/articles; the publisher is included primarily to help identify the source, and can change between editions without the content changing in any way, just as episodic online content could move to another site but still be the exact same MP4). Even with current traditional-TV usage of this template, stations participating in a network are subsets of the network, so it makes little sense to put them at the end. (Cf. specific publisher info; we usually do things like |publisher=First Amendment Project, University of Florida, not |publisher=University of Florida, First Amendment Project, which is confusing. (Yeah, that's "sub-publisher" and publisher in a single parameter, but the order is the point here.)

4a) We should probably also document the fact that |publisher= works with this template and is not an alias for |network= or vice-version; but give it custom documentation for this template, since it would usually be redundant:

• publisher: In {{cite episode}}, this parameter should only be used for the company or other organization that generated the content (E.g. National Geographic or Smithsonian Institution regardless what network is airing the show), when this is salient information and is not redundant with the network/carrier or station/channel. It should also not be used to identify commercial sponsors.

If we keep them as separate parameters, the order of their display should be switched, so that publisher is grouped with episode and series titles before the

4b) An alternative would be to actually alias |publisher= and |network= together. [I don't actually support this option.]

5) It might help to provide a complete example (for the ==Examples== section) for an Internet episode, e.g.:

• {{cite episode |number=105 |title=Ryzen 3000 in X370? PSU Wattage Calculation? |series=Ask GN |channel=[[Gamers Nexus]] |date=February 5, 2019 |carrier=[[YouTube]] |first=Steve |last=Burke |url= https://www.youtube.com/watch?v=TL0r1ZThUsY |minutes=25:58 |access-date=November 11, 2024}}

Renders as:

• Burke, Steve (February 5, 2019). "Ryzen 3000 in X370? PSU Wattage Calculation?". Ask GN. Episode 105. 25:58 minutes in. YouTube. Gamers Nexus. Retrieved November 11, 2024.

(Except, per point 3 above, it would read "Gamers Nexus. You Tube." instead of the other way around. Side note: I did not include |publisher=GamersNexus, LLC because it's near-identical to the channel name and would be redundant; same reason we don't do |publisher=The New York Times Company.)

This is an instructive example, since Gamers Nexus (one of the top three most respected enthusiast computing-focused "new media" content producers) has several episodic series (including a Hardware News program that is proper journalism and one of the most reliable sources in its specialty), and the episodes are available on different "carriers", e.g. YouTube for most of them, but some are subscriber-only via Patreon. While their own website (GamersNexus.net) lists this content, it's just linking to the YT pages; the content is "native" to YT as the publishing carrier (or Patreon, for the subscriber-only episodes – much as a writer might have two publishers for different works, or a musician may release material on multiple labels).

It's also a good example in that this is not a |via=YouTube, which is appropriate when YT is serving a post-publication redistribution role, like Google Books or Internet Archive. Here, it is the carrier – the e-quivalent of the TV network, of a book's publisher. GN has a formal monetized-content-producer relationship with YT and a full-time staff producing this content. (I.e., it's distinguishable from a random schmoe vlogging on YouTube, which we would not normally cite, but if we did (e.g. as Twitter-style primary source proof of a statement that generated RS-reported controversy) would be more like |publisher=Self-published|via=YouTube.)

One might also be able to construct a similar example for an entertainment series on "YouTube Originals", "YouTube Premium", "Audible Originals", "Amazon Originals", "Netflix Originals", various podcasting platforms, or whatever. But I don't know if they are arranged into channels (and won't pay to find out), and we're better off illustrating a non-fiction use here, anyway (with a notable example; it's weird that Gamers Nexus has no article here yet; I might consider writing one).

An editor might be tempted to use Template:Cite AV media, but it doesn't have the proper parameters. E.g., one would end up either dropping information, or wrongly cramming it all into the |title= parameter; it would be rather like misusing {{Cite book}} for a journal or newspaper.

Anyway, this proposal would be some steps forward in making this template more relevant in 2020, making it less specific to US "local channel callsign" stuff, and less confused with {{Cite AV media}}, which is better used for one-off audio-visual works, not series with episodes.
 — SMcCandlish ☏ ¢ 😼  01:25, 23 October 2020 (UTC)

Two points:

1. "Carriers" or "platforms" are also networks (likely of data centers or compute distribution nodes). But having them as aliases is fine afaic.

2. "Networks" however are not publishers. Networks in this context are legally defined distribution entities carried by physical distribution entities such as a communication utility infrastructure. For citation purposes network is the source, or work. It is published by another entity, usually the owner. Much like websites have publishers (the domain owners) or encyclopedias.

The publisher is important in discovery. Among other things, assuming the (network) publisher is still around in some form, they can be a last resort in finding a source - contact them.

Such concerns bring up the producer. Much like the publisher, production entities can be a last resort in finding sources discussed here. Perhaps a separate parameter would be apt. 64.18.9.208 (talk) 12:47, 23 October 2020 (UTC)

Re: "'carriers' or 'platforms' are also networks" – Yes, that's why I wrote: "|network= should probably also have an alias of something like |carrier= and perhaps |platform=". I didn't want to get into production entities (other than maybe to say "that's not this parameter") since adding that would be a different proposal. I do think I would support it, though, for the reason you state. I've long thought it was weird that it was missing from the A/V-related citation templates, since it can often be more important than network or a specific "author" (writer? director? why are we not distinguishing?). Anyway, I suggested 4b (aliasing |publisher= to |network= in this particular template) as an afterthought possibility, but it is not one that I really support (I listed 4a first for a reason), even if I don't have an immediate use for |publisher= in an episode citation today. I thought of good examples, and integrated them. However, I don't know what you mean by "For citation purposes network is the source, or work." |work= is the same as |title= in most one-off-publication templates, and is the same as |journal=, |website=, |magazine=, |newspaper=, etc., in templates where |title= is that of a subwork (i.e., is equivalent to |chapter=). Regardless, it's always a published work, not any kind of entity like a publisher, production company, |via= distributor, author, etc. And I wasn't sure what you meant be "source" in that; |network= in this template is not the same as |via=; e.g., the network might be PBS or BBC, but the |via= might be YouTube, redistributing an old PBS or BBC show (the via is the WP:SAYWHEREYOUGOTIT feature for redistribution cases). And finally, I don't get why you are referring to "data centers or compute distribution nodes", "legally defined distribution entities", or "physical distribution entities such as a communication utility infrastructure". These things have nothing to do with anything in a citation. I think you're commingling several different categorization systems (citation-related, infrastructural, and regulatory) that simply use some of the same words, in different but sometimes overlapping ways.  — SMcCandlish ☏ ¢ 😼  21:43, 26 October 2020 (UTC)

Confusing error message

I'm (twice) getting a big red error message reading 'Cite error: A list-defined reference with group name "" is not used in the content (see the help page).', at Sally Hemings. But this page does not use LDR.  — SMcCandlish ☏ ¢ 😼  18:05, 28 October 2020 (UTC)

Not one of ours. Help talk:Cite errors might be better. --Izno (talk) 18:15, 28 October 2020 (UTC)

 Fixed -- John of Reading (talk) 20:40, 28 October 2020 (UTC)

Engadine_Line

The article is throwing a ISSN error but according to Talk:Engadine Line/GA1 it appears to be correct. Jo-Jo Eumerus (talk) 19:35, 28 October 2020 (UTC)

The 'hyphen' is not a hyphen but is an ndash.

—Trappist the monk (talk) 19:57, 28 October 2020 (UTC)

Apostrophes are stripped from titles

(moved from VPT:) Apostrophes are stripped from titles in {{Cite wikisource}}:

{{Cite wikisource|Uncle Tom's Cabin}} → Uncle Tom's Cabin  – via Wikisource.

{{Cite wikisource/make link|link=Uncle Tom's Cabin|label=Uncle Tom's Cabin}} → Uncle Tom's Cabin

{{citation|title={{Cite wikisource/make link|link=Uncle Tom's Cabin|label=Uncle Tom's Cabin}}}} → Uncle Tom's Cabin 

{{cite book|title={{Cite wikisource/make link|link=Uncle Tom's Cabin|label=Uncle Tom's Cabin}}}} → Uncle Tom's Cabin .

Pinging Trappist the monk, who probably knows where this is happening. It appears to be happening in the CS1 module code, which is why I posted it here. I don't know if this needs an adjustment in Cite wikisource or in CS1, or somewhere else. And if Cite wikisource is doing it, other wrappers might be doing it as well. – Jonesey95 (talk) 21:43, 28 October 2020 (UTC)

Yes, it is. When you are done with {{cite wikisource/sandbox}}, I will continue to troubleshoot – I need that to be a copy of the live template so that I can use it to troubleshoot in the cs1|2 sandboxen.

—Trappist the monk (talk) 21:49, 28 October 2020 (UTC)

Go for it. – Jonesey95 (talk) 22:37, 28 October 2020 (UTC)

Fixed, perhaps...

{{cite wikisource/sandbox|Uncle Tom's Cabin}}

Uncle Tom's Cabin  – via Wikisource.

Found another lurking bug, c.f.:

{{cite wikisource|chapter=Laurent,_Cornelius_Baldran |wslink=Appletons'_Cyclopædia_of_American_Biography|plaintitle=Appletons' Cyclopædia of American Biography}}

"Laurent, Cornelius Baldran" . Appletons' Cyclopædia of American Biography – via Wikisource.

{{cite wikisource/sandbox|chapter=Laurent,_Cornelius_Baldran |wslink=Appletons'_Cyclopædia_of_American_Biography|plaintitle=Appletons' Cyclopædia of American Biography}}

"Laurent, Cornelius Baldran" . Appletons' Cyclopædia of American Biography – via Wikisource.

—Trappist the monk (talk) 00:16, 29 October 2020 (UTC)

Just out of curiosity, where did the little globe icon disappear to in the Cite wikisource sandbox (in the Uncle Tom's Cabin example)? I am not attached to it, but it's in the live template. – Jonesey95 (talk) 02:29, 29 October 2020 (UTC)

I think that's supposed to be an iceberg.

—Trappist the monk (talk) 10:59, 29 October 2020 (UTC)

Deprecated archive switch parameter [dead-url] on cite magazine

I believe the {dead-url} switch has been replaced by {url-status}. I intend to change references to {dead-url} on the above page to the new parameter. Are there objections. Cambial foliage❧ 14:39, 29 October 2020 (UTC)

Support for |dead-url= and its companion |deadurl= was removed quite some time ago. Alas, there are regularly used tools that continue to insert one of these forms into new cs1|2 templates so cleaning up after them is more-or-less a continuing task. Changing to |url-status= in any cs1|2 template, not just {{cite magazine}}, is the correct resolution, so please do.

—Trappist the monk (talk) 14:54, 29 October 2020 (UTC)

Thanks Trappist the monk. I would be happy to but it turns out I cannot. I believe you can? Cambial foliage❧ 15:07, 29 October 2020 (UTC)

scrap that I found the right edit button for the doc. Cambial foliage❧ 15:09, 29 October 2020 (UTC)

url-status defaulting to 'dead' is problematic

If 'archive-url' has a value and 'url-status' is omitted or has no value, then 'url-status' is silently treated as having the value of 'dead'.

I am finding this problematic, as I see numerous instances where the original URL is still live but an editor has set 'archive-url' (that's fine) and omitted 'url-status=live' (presumably these editors have simply been unaware that it defaults to 'dead').

Before requesting reconsideration of the default behaviour, I am wondering whether it was a deliberate decision and, if so, what the rationale was. I have searched this talk page's voluminous archives but have not yet found any such discussion. Can anyone advise (or link to) what consideration was given to making this the default behaviour? Thanks. Nurg (talk) 23:31, 30 October 2020 (UTC)

Perhaps this: Wikipedia:Requests for comment/Dead url parameter for citations.

|deadurl=no is the no-longer-supported for of |url-status=live.

—Trappist the monk (talk) 00:03, 31 October 2020 (UTC)

Lowhanging fruit for no-dash versions

I have edited the whitelist and configuration sandboxes to deprecate some more no-dash versions of parameters that are low-hanging fruit (i.e. <1k uses): |conferenceurl=, |contributionurl=, |laydate=, |laysource=, |layurl=, |seriesno=, |timecaption=, and |titlelink=. Of course, dash versions such as |conference-url= remain.

I noticed a few parameters that have 0 uses in the wild and I don't believe we need the synonym in those cases: |seriesnumber=, |event-format=, |event-url=, and |eventurl= in {{cite conference}}, which has |series-number=, |conference-format=, and |conference-url=. These were removed.

I also saw a curiosity. |event= is currently a synonym for |conference= in /Configuration. However, it is apparently used in {{cite speech}} (see particularly Albert Einstein as an example from the search). Any opinions on whether that is an issue? --Izno (talk) 16:48, 22 October 2020 (UTC)

Apparently |event= is intended to name the location, venue, whatever where the speech was given. For the purposes of citing a speech, I don't think that where the speech was given has any value because someone attending the speech can't cite it and expect that readers can verify what the speaker said. Editors will likely be citing a written copy of the speech from a book, a magazine, a journal; or citing an audio, video, film recording of the speech. We have sufficient templates for those kinds of citations so I guess I have to wonder if there is any real purpose to keeping {{cite speech}}.

—Trappist the monk (talk) 19:21, 22 October 2020 (UTC)

Agreed. "Speech" can be a |type= in the templates you mention. 64.18.9.203 (talk) 12:06, 23 October 2020 (UTC)

I generally agree. Dealing with a template however is a question for WP:TFD. --Izno (talk) 22:36, 23 October 2020 (UTC)

polluted categories

Since we're talking about categories... According to this search result there are 311 CS1-prefixed categories that use {{polluted category}}. That template is a do-nothing template that is supposed to identify categories that hold items that exist in main-space and items that exist in user-space so that these categories are excluded from Wikipedia:Database reports/Polluted categories which is apparently moribund. Regardless, {{polluted category}} brings no benefit to the cs1-prefixed categories because Module:Citation/CS1 is the only way that anything should be listed in these categories and because Module:Citation/CS1 excludes, among others, the user and user talk namespaces when it creates category wikilinks.

So, without objection, I shall remove {{polluted category}} from all of the CS1-prefixed categories.

—Trappist the monk (talk) 19:50, 26 October 2020 (UTC)

There having been no objection, done.

—Trappist the monk (talk) 15:27, 28 October 2020 (UTC)

Footnotes

Hello. I would like to know how you match the footnote labels between the footnote marker and the reference list. I would like to do it on the Wikipedia of another language. Let me know. Hypuxylun (talk)

Hard to know just exactly what you mean. In general, in article text, citations (either plain text or template) are wrapped in <ref>...</ref> tags. In the reference section, the basic form is a single <reflist /> tag. MediaWiki's cite.php creates the list of citations where the <reflist /> tag is placed. Did I answer your question?

—Trappist the monk (talk) 23:36, 30 October 2020 (UTC)

For example, for the lower alpha footnotes, the footnote marker is ^[a], ^[b], ^[c]... and the reference list is also a, b, c... However, on the Wikipedia of another language, the footnote marker is ^[a], ^[b], ^[c]... but the reference list is still 1, 2, 3... I would like to know how you change the reference list from 1, 2, 3... into a, b, c... You can find the example on the template Sablon:Efn from the Hungarian Wiki. --- Hypuxylun (talk)

I think that the letters are provided by the "list-style-type" attribute in Template:reflist. If you use that code in the hu.WP version of reflist, it might do what you want. – Jonesey95 (talk) 01:00, 31 October 2020 (UTC)

OK, it was not included on the one in Hungarian template Sablon:Reflist. I can find a way to fix it and hope that it works. Hypuxylun (talk) 01:20, 2 November 2020

Several co-authors that share the same last name

Example situation: article Nova 9: The Return of Gir Draxon contains a reference in which the authors Hartley, Patricia, Kirk all share the same last name, Lesser. Assuming all three are related in some way (no hidden text was provided to say otherwise), isn't there a way to condense the list of authors to display all three first names but only one last name for the group? I'd like to suggest a clearer mention on the template page, though the use of such a parameter would be limited.

Semi-related, I removed the name-list-style=amp parameter from the citation mentioned above, because displaying both a semicolon and an ampersand to separate the three authors just looks weird. — Christopher, Sheridan, OR (talk) 05:58, 2 November 2020 (UTC)

You can do so by setting |author-maskn= for each. I personally deplore the style you are using because it is hell to figure out bad citations when it is employed. (If you provide all of the first/last pairs as expected, it is slightly better but still leaves me at least somewhat salty. :) --Izno (talk) 06:07, 2 November 2020 (UTC)

Thank you for the suggestion. However, the Template:Cite journal is not clear about how it should be used, and doesn't give appropriate examples for demonstration. I would therefore have to play around with the author-mask_n= parameter to figure out how to use it. That's part of the problem I'd like to report—lack of examples on the template page on how to use it. — Christopher, Sheridan, OR (talk) 06:19, 2 November 2020 (UTC)

The documentation is quite dense already, so I think examples would be hard to fit. That said, this might be to your liking: Smith, A., B, & C. Title.. I think that is not really that great a style, but perhaps you have something in mind that will make it obvious. --Izno (talk) 06:24, 2 November 2020 (UTC)

Yes, that is what I'd like to see. Thank you for the assistance; I shall implement it on the article immediately.
— Christopher, Sheridan, OR (talk) 06:32, 2 November 2020 (UTC)

|nocat=

I have cleared Category:CS1 maint: nocat. I have also removed support for |nocat= and Category:CS1 maint: nocat from the sandbox module suite. After the next update, |nocat= will cause cs1|2 templates to emit the unknown parameter error message:

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

Title. {{cite book}}: Unknown parameter |nocat= ignored (|no-tracking= suggested) (help)

—Trappist the monk (talk) 13:36, 29 October 2020 (UTC)

Thanks, Trappist. I haven't gone through all citations using |no-tracking= yet, but in the past weeks I cleaned up some of the |nocat= parameters as well and among them did not run into any citations for which we would actually need this feature in mainspace any more (for broken DOIs we now have a much better option). Did you?

If all uses in mainspace would have been removed, and categorisation would be disabled outside mainspace, the parameter could be removed completely or reduced to a pure debug option (possibly with reversed logic to optionally enable categorisation outside mainspace).

Questions from Help_talk:Citation_Style_1/Archive_71#no-cat_parameter_cleanup:

• Do we actually need this in mainspace? Should we disallow the feature in mainspace?
• What should be the default behaviour in other namespaces? Should the behaviour be changed to populate categories only when a special option is given?
• If it would be always disabled in mainspace and enabled elsewhere, do we need a parameter to control it at all?
• Should we change the temporary nocat category into a permanent maint category for the feature as a whole?
• Find a better parameter name based on the resulting functionality and use case of the feature. If we don't keep a maint category the parameter name needs to be unique to also serve as a good search pattern.

Opinions?

--Matthiaspaul (talk) 23:05, 4 November 2020 (UTC)

Bump PMC to 8000000

PMC 7528258 is valid, but gets reported as an error. Headbomb {t · c · p · b} 18:42, 2 October 2020 (UTC)

bumped.

{{cite book/new |title=Title |pmc=7528258}} → Title. PMC 7528258.

—Trappist the monk (talk) 19:46, 2 October 2020 (UTC)

Is the rate by which this increases predictable with reasonable certainty so that we could automatically increase the upper limit depending on the current date somehow? If so, the maintenance rate for these limits could be reduced significantly. Not that this would be much of a problem right now, but it requires monitoring. Let's think a couple of years into the future when we might no longer be around here any more - it's always better if things are set up in a way that does not need any or only very few updates.

--Matthiaspaul (talk) 21:51, 2 October 2020 (UTC)

See also:

• Help_talk:Citation_Style_1/Archive_63#pmc_can_be_larger_than_6000000
• Help_talk:Citation_Style_1/Archive_63#PMC_parameter
• Help_talk:Citation_Style_1/Archive_64#SSRN_limit_now_exceeded
• Help_talk:Citation_Style_1/Archive_64#Where_can_I_find_the_range_of_value_|pmc
• Help_talk:Citation_Style_1/Archive_65#identifier_limits
• Help_talk:Citation_Style_1#PMID_limit

--Matthiaspaul (talk) 21:30, 12 October 2020 (UTC) (updated 11:36, 5 November 2020 (UTC))

Error category names standardization

Could the error categories in the next version sync be standardized? Out of the 55 categories in Category:CS1 errors, 44 start with "CS1 errors". These are the ones that use a different style:

• Category:Pages using citations with accessdate and no URL
• Category:Pages with archiveurl citation errors
• Category:Pages with empty citations
• Category:Pages using citations with format and no URL
• Category:Pages with citations having redundant parameters
• Category:Pages with citations lacking titles
• Category:Pages using web citations with no URL
• Category:Pages with citations having bare URLs
• Category:Pages with citations using unnamed parameters
• Category:Pages with citations using unsupported parameters
• Category:Pages with URL errors

--Gonnym (talk) 15:11, 22 October 2020 (UTC)

See Help talk:Citation Style 1/Archive 71 § error category names standardization and the top of Module:Citation/CS1/Configuration/sandbox

—Trappist the monk (talk) 15:17, 22 October 2020 (UTC)

In case that response is unclear, the sandbox version of the module has been updated to standardize the above category names (follow the Archive 71 link to see the new names). They will be updated the next time the sandboxes are copied to the live module (typically every couple of months). – Jonesey95 (talk) 15:59, 22 October 2020 (UTC)

Thanks both for the link (and Jonesey for saving me time reading that). --Gonnym (talk) 16:22, 22 October 2020 (UTC)

Since it's already archived, I'll comment here. I didn't see these 3 mentioned at the discussion. All sub-categories of Category:CS1 properties which use a colon: Category:CS1: long volume value, Category:CS1: Julian–Gregorian uncertainty and  Category:CS1: abbreviated year range. --Gonnym (talk) 18:06, 23 October 2020 (UTC)

I think that it should be the other way 'round: all Category:CS1 properties cats should have a colon after the 'CS1' prefix just as all error and maintenance categories with the 'CS1 errors' and 'CS1 maint' prefixes have a colon. I don't know if it is really necessary but, we could go further and use 'CS1 prop' prefixes.

—Trappist the monk (talk) 18:51, 23 October 2020 (UTC)

And Category:CS1 has been listed for renaming to Category:Citation Style 1; see Wikipedia:Categories for discussion/Speedy § Current requests.

—Trappist the monk (talk) 19:27, 23 October 2020 (UTC)

Not particularly important, but if we are going to rename / streamline the CS1 category names anyway, perhaps we should also change

"maint" -> "maintenance"

in the category names. The rationale would be to avoid unnecessary abbreviations. Space is not an issue here. "Maint" is non-standard developer jargon, therefore pretty obvious for us. But I'm not sure if uninvolved readers (our target audience) will guess its meaning equally easy. --Matthiaspaul (talk) 14:22, 26 October 2020 (UTC)

It is most definitely an issue for people who use Timeless where the categories end up in the sidebar through no fault of their own ;). Uninvolved readers can't see the category on each page anyway since it is hidden (like CS1 errors for that matter), much less the maintenance message itself, so the only other place they might stumble upon the category name is the category page itself (which provides sufficient context) or the context of discussions about the categories, like this one (which also provides sufficient context). --Izno (talk) 15:25, 26 October 2020 (UTC)

I don't understand this argument. So what if categories are in a side bar? Here is an article using timeless skin that has three hidden categories. All are visible to me (I presume because I have enabled hidden category display in my preferences). All of those category names are readable. The maintenance messaging must be turned on by interested editors but our choice of category names has no bearing that. So what is it that you are really complaining about?

—Trappist the monk (talk) 13:42, 28 October 2020 (UTC)

I did not assert that I could not see them in Timeless. I did not assert clearly anything by what I did say, in fact... To make it clear now, I do not want longer category names because they will not wrap cleanly and/or will make an already often-long sidebar on the right much longer for no obvious gain. I honestly don't want longer message names either (as CS1 maintenance: is longer than CS1 maint:), which has a similar, though of lesser nature, concern associated with how long the word is.

I did argue that how long or what is in the category name is immaterial to the casual reader who cannot see the categories in any location whatsoever (c.f. But I'm not sure if uninvolved readers (our target audience) will guess its meaning equally easy. by Matthias). Someone who can't see the category listing on a specific page won't care how long or what the names are, which means that only the following groups are of interest: a) casual people who have somehow navigated to the category page are there by happenstance and are provided an explanation in the rest of the page; b) casual people who see a discussion on a page like this one, in which they are provided sufficient context; and c) people who are not casual and have turned on hidden categories will need to learn what is going on, but that also is made obvious by the content of each named category. And then, those who see the structure once can probably figure out what is going on from thereon. (Do I presume too much?) In all cases regardless, someone can click and see what is on the category page and will see "maintenance" in some form or another on each.

I assert that the reason our error messages don't have CS1 in them is that abbreviation is just as much technobabble as the asserted shortening of "maintenance" is....

As for 'properties', I do think those should at the least be consistently at CS1:. I honestly haven't decided whether I like "props" or "properties" more, though you might tell which I lean toward. --Izno (talk) 21:15, 28 October 2020 (UTC)

Please, no, "props" is really cancer to the eyes.

In general, as Wikipedia is for readers, I wonder if we should support grammatical nonsense such as "maint" at all. If Timeless can't cope with "maintenance" in category names well, it will have problems with longer-than-average words and titles in general, that is, it is an issue that occurs all over the place. If so, it is a problem of the skin, not the contents, and consequently should be addressed at skin level, not by adjusting the contents. Looks very unprofessional to me.

--Matthiaspaul (talk) 10:24, 29 October 2020 (UTC)

You apparently continue to ignore what I said. Readers. Can't. See. These. Categories.

I happen to agree that the skin is doing something dumb here, but saying we must do X because of Y reasons and then ignoring the other Z reasons that we really don't need to do X isn't cool. "Looks very unprofessional to me." --Izno (talk) 00:50, 1 November 2020 (UTC)

I wonder how you come to that conclusion. I read your reasoning and value it as any constructive input into the discussion, but it didn't convince me much, in particular because addressing this in our narrow context by using abbreviated category names won't solve the problem anywhere else, so it's clear that the fix for this must be elsewhere. Also, while I originally wrote "uninvolved readers", editors and developers are readers as well. Since you more or less suggested to change the category names to "props" I provided my opinion on this.

Y and Z must be weighted. I think that, in general, skin issues should be solved on skin level. I would support special-casing something to improve the appearance in Timeless (although I don't know what that could be in this particular case). The extent of this support would stop where it would weaken the general appearance in other skins (including the default Vector skin).

Perhaps the solution would be to change the thresholds when categories move from the bottom of a rendered page into the sidebar and/or to blend in the categories only after pressing a special button, I don't know. (I don't use Timeless and given the many issues you reported with this skin in the past it does not appear to be very desirable to use.)

--Matthiaspaul (talk) 23:50, 1 November 2020 (UTC)

I'll leave the Timeless redesign discussion aside save to say that no, the (quantity of) issues I have reported do not reflect my happiness with the skin.

I'm not sure how much more productive this line of discussion between you and me will be, so I will leave that there also. Perhaps another editor or two will appear to discuss/give input. I will suggest something a little more off-the-wall down the way to see if that fits anyone's tastes. --Izno (talk) 04:15, 2 November 2020 (UTC)

From there, I think it's just a question whether we shall catch headgoblins. --Izno (talk) 21:19, 28 October 2020 (UTC)

This discussion has meanwhile been moved to Category_talk:CS1#Opposed speedy move request.

--Matthiaspaul (talk) 21:26, 3 November 2020 (UTC)

'CS1 maint:' → 'CS1 maintenance:' and properties: 'CS1' (with and without colon) → 'CS1 properties:'. See Module:Citation/CS1/doc/Category list. —Trappist the monk (talk) 15:30, 26 October 2020 (UTC)

And ... I've been reverted by some mechanism that doesn't notify editors that a revert has taken place and which also reverted an unrelated edit to Module:Citation/CS1/Configuration/sandbox.

—Trappist the monk (talk) 13:16, 28 October 2020 (UTC) 13:20, 28 October 2020 (UTC)

Because of that unrelated edit, MediaWiki indicated there was an intervening edit that could not be reverted with 'undo', I needed to perform a manual revert i.e. opened the previous good version, copy-pasted the uncontested change in from the current version, and saved. (In retrospect, I suppose I could have undone all of the edits rather than the two I would have preferred to revert with 'undo', then reinserted the uncontested change in the one edit pane.) --Izno (talk) 21:15, 28 October 2020 (UTC)

Or not revert at all. --Matthiaspaul (talk) 10:24, 29 October 2020 (UTC)

Or not revert at all. This is a wiki. Get off that dumb horse there. Moreover, it isn't cool to deliberately misinterpret what I said to mean "I had to revert". You know that was not the intention. These modules are used on a couple million pages. Consensus is required for change. A revert makes it obvious you don't have consensus. --Izno (talk) 00:50, 1 November 2020 (UTC)

Izno, I did neither question the technical necessary steps of your reversion nor did I question your good intentions in general. Likewise, I can rule out any deliberate misinterpretation on my side. My remark was meant as a friendly reminder that reversion of perfectly good-faith contributions should remain restricted to cases where no other options for improvement exist. An occasional revert hardly harms, but frequent reversions do. Trappist edited the sandbox, not the live template. The sandboxed modules are not used on millions of pages. The sandbox is, by its very definition, open for experimentation by anyone, and while it makes sense not to wait until the next update to clean up edits for which there is no consensus also in the sandbox (at least for as long as we don't have a separate release stage area), there also is no reason to revert changes almost immediately in the middle of the discussion just because you don't agree with them.

--Matthiaspaul (talk) 23:50, 1 November 2020 (UTC)

By the same token, on Wikipedia, quick reverts save everyone time untangling good edits from bad. This is no less true in a community sandbox (that I personally treat as requiring consensus) than the module which is the live representation of that sandbox. You particularly, in the last module release, conflated many reasonable edits with many edits that I would have personally preferred not to have seen added to the module, but I could not easily revert them and gave you the benefit of the doubt that you would announce those changes proactively (like Trappist and I have done when we make changes to the sandbox).... T'was not to be. (I still don't understand a few of the changes that were made, and that disturbs me both from the user-perspective and the rationale perspective.) Instead, I will revert now, skip being worried that unnecessary complexity has been added, and ensure that what is in the sandbox is something that could be deployed tomorrow with the appropriate consensus (if we were interested in doing so).

If you (or anyone else) would like to "experiment" (rather than announce and propose actual changes), then, like the main page sandbox suggests for that area (see edit notice), your own personal copy of the modules might be preferable for experimentation or redesign. (Were it the case we could fork more easily... maybe there is a Javascript writer who could do that for us. :^) --Izno (talk) 04:15, 2 November 2020 (UTC)

Different suggestion: We should consider removing all CS1 'subtypes' from the category names, meaning that "CS1 errors:", "CS1 maint:", and "CS1(:)" would all become "CS1:", and then only the parent category name would need to match the category of message/property. This would have the side-benefit that maintenance messages promoted to errors, or properties to maintenance/errors, would not need to have their category name changed when promoted. --Izno (talk) 04:15, 2 November 2020 (UTC)

Meh. Now that the sandbox has been altered to normalize the category names, certainly the prefixes can be removed from the category names in Module:Citation/CS1/Configuration/sandbox error_conditions{}. We can then apply the prefixes in Module:Citation/CS1/sandbox where we actually create the category wikilink. Same side benefit and we retain the prefixes which I think we should do. I suspect that it isn't possible to apply some sort of css trick to category wikilinks so that individual editors could hide the prefixes in the hidden categories list...

We should not forget the non-English wikis of various types that also use these modules and the associated categories; for them, the prefixes may (or maybe not) be important.

—Trappist the monk (talk) 14:10, 2 November 2020 (UTC)

Indeed, but they are also free to customize as they see fit; they are not beholden to precisely the same naming.

As for prefix removal to elsewhere if such occurs, my understanding is that it is both harder for i18n and more expensive for Lua to process two strings like that in separate places. Where necessary we should perform string manipulation, but I do not think this would be a place were we to go down that path. --Izno (talk) 15:00, 2 November 2020 (UTC)

Agreed, other wiki's are not obliged to follow our lead. For those that do, fully spelled-out names may be important.

Of course. Any work that the module has to do costs time and processor resources. We are already concatenate Category: with <category name> which we then hand off to utilities.make_wikilink() where we concatenate [[, the prefixed category name, and ]] to make the final result. Changing utilities.make_wikilink ('Category:' .. v) to utilities.make_wikilink ('Category:' .. cfg.presentation['<category prefix>'] .. v) isn't much extra work.

Maybe better would be to write something like:

utilities.substitute (cfg.messages['cat wikilink'], {cfg.messages['cat err prefix'], v})

where the messages{} table has:

['cat wikilink'] = '[[Category:$1$2]]'

['cat err prefix'] = 'CS1 errors: ',

['cat maint prefix'] = 'CS1 maintenance: ',

['cat prop prefix'] = 'CS1 properties: ',

For i18n, should probably do something like that anyway so that other language wiki's don't have to edit Module:Citation/CS1 as well as Module:Citation/CS1/Configuration.

—Trappist the monk (talk) 16:32, 2 November 2020 (UTC)

I have have added ['cat wikilink'] = '[[Category:$1]]' and a matching [':cat wikilink'] = '[[:Category:$1|link]]' to ~/Configuration/sandbox. To use those I have replaced the calls to utilities.make_wikilink() with utilities.substitute (cfg.messages['cat wikilink'], {v}) where we make category names and the similar call where we make the link in maint error messages.

—Trappist the monk (talk) 18:00, 2 November 2020 (UTC)

Apparently, even experienced editors don't understand that properties categories are not error categories. I just stumbled on this discussion: Help talk:Citation Style 1/Archive 68 § Bogus long volume which suggests to me that were Category:CS1: long volume value renamed to Category:CS1 properties: long volume value then that discussion might not have been necessary or would have been about something else.

—Trappist the monk (talk) 15:21, 6 November 2020 (UTC)

Italics

I want to italicize the newspapers in Dietrich Adam but it comes up with an error. Please allow the option to do it manually, I hate it when things are controlled by a template.† Encyclopædius 13:12, 5 November 2020 (UTC)

Use {{cite news}} and |newspaper=

{{cite news |url=https://www.spiegel.de/kultur/tv/dietrich-adam-ist-tot-friederich-stahl-in-sturm-der-liebe-a-548adb45-64fe-49ce-8e71-58a7cce9c3a9 |title=Schauspieler Dietrich Adam ist tot |newspaper=Der Spiegel |date=4 November 2020|access-date=5 November 2020 |language=de}}

"Schauspieler Dietrich Adam ist tot". Der Spiegel (in German). 4 November 2020. Retrieved 5 November 2020.

Did the error message help text not answer this question?

—Trappist the monk (talk) 13:19, 5 November 2020 (UTC)

Wikipedia doesn't actually force anyone to use citation templates. The only requirement is that the style you use looks identical to the one in the rest of the article. Glades12 (talk) 13:48, 6 November 2020 (UTC)

Request for the "nbk" (NCBI bookshelf) attribute for "cite book"

Please add the "nbk" attribute for the "cite book" template to specify the NCBI NBK number. You already have the "pmc" and "pmid" attributes, but the "nbk" is different. It refers to the NCBI bookshelf site that has different URL forman than PubMed Central. The URL to the bookshelf looks like https://www.ncbi.nlm.nih.gov/books/NBK557634/ (where 557634 is the NCBI NBK number). My idea is when you specify the "nbk" to the "cite book", the direct URL to the book at the NBI site will be generated. Currently, NCBI bookshelf books cannot be accessed directly from Wikipedia or other Wikimedia cites that allow the "cite book" template. Maxim Masiutin (talk) 19:42, 6 November 2020 (UTC)

Weird category text

What's going on with Category:CS1 errors: dates? A bunch of sectioned text just appeared today, that don't have to do with dates. Does it have to do with the {{#lst}} stuff? I don't understand how those work. kennethaw88 • talk 22:14, 6 November 2020 (UTC)

Thanks for reporting this. A couple of hours ago I swapped some sections at Help:CS1 errors to reestablish the alphabetical order of entries, however, I must have overlooked something. As Izno reverted me, the effect should already have been gone by now. To be sorted out.

--Matthiaspaul (talk) 23:03, 6 November 2020 (UTC)

Fixed. --Matthiaspaul (talk) 11:04, 7 November 2020 (UTC)

Triple curly

From Women in the Byzantine Empire:

{{cite book| author = | chapter = | chapter-url = | format = | url = | title = [[The Oxford Dictionary of Byzantium]] | orig-year = | agency = ed. by Dr. [[Alexander Kazhdan]] | edition = |location= N. Y. |date = 1991 |publisher= |volume= {{{том|}}} | pages = {{{страницы|}}}| series = | isbn = 0-19-504652-8| ref = {{harvid|Kazhdan|1991}}}}

Produces:

• The Oxford Dictionary of Byzantium. N. Y. 1991. ISBN 0-19-504652-8. {{cite book}}: Unknown parameter |agency= ignored (help)CS1 maint: location missing publisher (link)

Are triple curly-brackets {{{том|}}} and {{{страницы|}}} error or feature? -- GreenC 16:09, 7 November 2020 (UTC)

The template variables are in the first version of that article. cs1|2 does not see them because they are empty strings by the time the template is passed to Module:Citation/CS1.

—Trappist the monk (talk) 16:30, 7 November 2020 (UTC)

(edit conflict) It's an error caused by copying and pasting the template from the Russian Wikipedia when the article was created. I found only one other instance of this problem in article space, so it looks like it is not a big problem. – Jonesey95 (talk) 16:35, 7 November 2020 (UTC)

This is good news as finding the template's terminus }} when there are triple curly brackets embedded raised some edge case complications, now they can just be logged and removed. -- GreenC 00:40, 8 November 2020 (UTC)

Add wayback-timestamp parameter

When an archive is added to a reference, the vast majority of the time it is just a Wayback Machine archive of the exact same URL. This bloats the source code of pages massively. It would be much simpler if a wayback-timestamp parameter was added, which would be set to the timestamp of the archive found in the page's URL. This was mentioned seven years ago here but the discussion had no conclusion. Example: |wayback-timestamp=20200721125421 in \{{cite web|url=https://example.com/page|title=Example page|website=Example.com|date=2020-08-04|wayback-timestamp=20200721125421|archive-date=2020-07-21}} as opposed to the bloated {{cite web|url=https://example.com/page|title=Example page|website=Example.com|date=2020-08-04|archive-url=https://web.archive.org/web/20200721125421/https://example.com/page|archive-date=2020-07-21}}. Implementation: if waybackTimestamp then archiveUrl = 'https://web.archive.org/web/' + waybackTimestamp + '/' + url end.  Nixinova   T   C   05:15, 4 August 2020 (UTC)

You're not wrong, but the thing is, server space keeps getting cheaper and cheaper, and programmer (paid, or volunteer time) keeps getting more expensive and scarcer. If you had to prioritize this against stuff that's either broken and needs fixing, or enhancements that would provide desired new functionality, well, you see the problem... Mathglot (talk) 04:00, 6 August 2020 (UTC)

I'm not saying to replace all archive-url's with this, just add it as an additional option.  Nixinova   T   C   07:47, 27 August 2020 (UTC)

Bumping, I still think this is a good idea. Wayback is what most people use for archives, and this would save many kilobytes per page. Other archiving services could be used with archive-url without touching this syntax, but this would be very useful at minimising the size of references in a page's source.  Nixinova   T   C   03:23, 2 October 2020 (UTC)

@Nixinova: Have you tried |wayb? For example, {{cite web |url=https://example.com/page |wayb=20200721125421}}? Note that when using |wayb you don't need to use |archive-date because it extracts the date from |wayb. I think that is an undocumented feature, I discovered it reading some page source to understand the inner workings. Joaopaulo1511 (talk) 08:05, 15 October 2020 (UTC)

@Nixinova: Sorry, |wayb works on Portuguese Wikipedia, but not on English Wikipedia. Check pt:ReactOS (page source) to see what I am talking about. The |wayb argument is documented here pt:Predefinição:Citar_web#URL and on other Portuguese citation templates. @Mathglot: The wayb I see it, one day of a coder's work can help editors save many months by not having to repeat wiki code over and over, and also help read (and edit) faster by uncluttering the sources' pages. And the code is already there, on the Portuguese Wikipedia, just waybting to be copied. 😅 Joaopaulo1511 (talk) 08:55, 15 October 2020 (UTC)

I like the idea in general, but not the proposed user-interface. I am not too fond of the idea of adding a specialized parameter |wayback-timestamp= or |wayb= just for archive.org. Also, these parameter names would not fit well into our parameter naming scheme. An alternative proposal, which works without introducing a new parameter, is discussed here: Help_talk:Citation_Style_1/Archive_72#Smart_substitution_token_to_reduce_redundancy_among_input_parameters

It is slightly longer (which shouldn't matter, as in both cases the full archive link must be available for truncation before adding it to a citation - basically noone types in archive links or timestamps without utilizing copy & paste), but it is more flexible (also possible for some other archivers) and it would be embedded into a more general concept potentially reducing the necessary amount of typing also for a number of other citation template parameters. Of course, both could be implemented in parallel, but for reasons of consistency across citation templates (similar to our ((accept-this-as-it-is)) syntax) I would prefer the broader concept of a smart substitution token.

--Matthiaspaul (talk) 11:09, 15 October 2020 (UTC)

(edit conflict)

Previous discussions:

• Help talk:Citation Style 1/Archive 39 § Archive-date parameter
• Help talk:Citation Style 1/Archive 58 § Fill in archive-date automatically

Those seem to focus on all archive sources, whereas |wayb= is specific to Internet Archive. Because we have InternetArchiveBot I would guess that the vast majority of |archive-url= parameters hold wayback urls. If that is the case then perhaps there is some sense in supporting |wayb= or similar. But, for me, it is easier to copy/paste an entire archive url than it is to highlight 14 digits in the middle of the archive url and then copy/paste that. So that suggests, if the goal is to make life easier for editors, when |archive-url= holds a properly formed Internet Archive url, cs1|2 can extract the date from the 14-digit timestamp and return a YYYY-MM-DD archive date to be formatted according to |df= or {{use xxx dates}}.

I'm not all that comfortable with automatically assembling an archive url from |url= and an editor-supplied timestamp. Any change that 'fixes' the url will likely break the assembled archive-url.

—Trappist the monk (talk) 11:14, 15 October 2020 (UTC)

Moreover, this would make the bot's work more complex. Solid "we should not do this". --Izno (talk) 13:07, 15 October 2020 (UTC)

Assembling archived links from a prefix, a timestamp and an URL is hardly "complex", it's trivial to code. However, there is, as Trappist correctly wrote, a risk to break the archived link when the URL gets modified later on. So, this whole idea depends on such timestamps been adjusted or removed whenever |url= is touched, or for them to be replaced by the expanded link in |archive-url= again. However, failing to update |archive-url= when modifying |url= is almost always an error, even without this proposal. What we'd lose is the "known good state" of an already existing |archive-url= when the |url= undergoes only minor tweaking (like removing unnecessary URL parameters). As bots not updated to take |wayback-timestamp= (or similar) into account would likely just add |archive-url=, the failure mode is on the safe side if the template gives |archive-url= priority over |wayback-timestamp=. In the case of the placeholder idea, an |archive-url= containing a * would not match and would likely be overwritten by the bot when it changes |url=. It's not 100% bullet-proof over the transitional phase, but little actual damage can be made, so this aspect alone should not invalidate the idea, IMO.

In general, we should not have "mercy" with bots. They are to make life easier for humans, not the other way around. Programs exist to code once, solve often. For as long as the work required to code a program is smaller than the accumulated amount of work that would be required to repeatedly solve a problem manually, the difficulties to code and maintain a bot are worth it.

--Matthiaspaul (talk) 09:58, 16 October 2020 (UTC)

I think, the goal of these proposals, as far as archive links are concerned, is to reduce clutter in citation source code (URLs tend to be long and ugly), less so to save storage space (because it doesn't matter much) or reduce the amount of typing (as the parameter value would be crafted from a pasted archive link rather than typed in manually).

In the case of |archive-date=, the goal is actually to reduce typing and maintenance time. Although this is only addressing a minor aspect of both proposals, making |archive-date= optional for |archive-url= links from archivers known to include timestamps would be something I would support as well. Wikipedia:List of web archives on Wikipedia lists a number of archivers producing links with embedded timestamps.

--Matthiaspaul (talk) 09:58, 16 October 2020 (UTC)

last-author-amp=

This documentation edit reminds me that |last-author-amp= should be deprecated in favor of a new parameter with a better name. We do not have |last-contributor-amp=, |last-editor-amp=, |last-interviewer-amp=, or |last-translator-amp= parameters. When |last-author-amp=yes, any of the other name lists that have two or more names will use the ampersand separator between the last two names in the list.

What is the new parameter name? |last-name-amp= is problematic for obvious reasons. |last-sep-amp=? Or, something different, perhaps: |namelist-last-sep=<keyword> where <keyword> is & or amp or and; possibly other keywords? Still needs the new parameter name and keyword definitions.

—Trappist the monk (talk) 19:53, 19 August 2020 (UTC)

How about |author-ampersand=, |editor-ampersand=, etc.? Spelling out "ampersand" is a bit awkward, but its meaning is clearer than "amp". The |xxx-ampersand= model is easily extensible to other parameters, such as those listed above. The documentation could make it clear that the parameter, when set to "yes" or "y", renders an ampersand between the final two author/editor/translator names. – Jonesey95 (talk) 21:16, 19 August 2020 (UTC)

|last-author-amp= applies to all name lists even when there are no names in the author name list:

{{cite book |title=Title |translator=Translator |translator2=Translator2 |last-author-amp=yes}}

Title. Translated by Translator; Translator2. {{cite book}}: |translator= has generic name (help); Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)CS1 maint: numeric names: translators list (link)

This mechanism makes sense to me because the name lists in a citation should all render with the same style. A single parameter name not closely tied to a particular name list seems to me better than renaming |last-author-amp= and creating four aliases of that – I can imagine editors adding an (unnecessary) alias parameter for each name list in the citation...

—Trappist the monk (talk) 21:37, 19 August 2020 (UTC)

I've been wondering if late whether this parameter is strongly needed at all. But that aside, I'd go for |namelist-last-sep=<keyword> or similar. --Izno (talk) 21:45, 19 August 2020 (UTC)

I confess to wondering the same, but it exists and were we to take it away, no doubt, no doubt, torches, pitchforks, ...

—Trappist the monk (talk) 21:50, 19 August 2020 (UTC)

My mistake. I would support something like |name-list-ampersand= then. And I would not be excited about an open-ended var option for the separator. The last thing we need around here is more citation variation, let alone within CS1 templates. – Jonesey95 (talk) 21:56, 19 August 2020 (UTC)

There was this discussion: Help talk:Citation Style 1/Archive 44 § Is there any interest... I thought I remembered more than that one but it appears that my memory is faulty.

—Trappist the monk (talk) 22:18, 19 August 2020 (UTC)

(edit-conflict) If we switch to use a different parameter, I think, it should be one not only allowing the feature to be enabled or disabled, but to actually specify the separator as well. That would be your proposed |namelist-last-sep=, although, I think, that name is too complicated (and contains an abbreviation not all people will understand). The {{catalog lookup link}} template uses |list-leadout= for this. Given that it would apply to all name lists, |leadout-separator= or just |leadout=/|lead-out= could work as well (but could be easily confused with the |postscript= parameter).

Is there a chance that we'd need to specify alternative leadouts also for other lists in the future? Then, the parameter name should be chosen in a way already taking such extensions into account, namewise. However, the only other lists at present are identifier lists and pages — I don't see any possible need to divert from the default separation schemes there, hence, no issue.

However, there are other options as well:

If, for example, we would want to get rid of a parameter, the functionality could be merged into one of the existing parameters

• |name-list-format= (either through a new token such as "amp", or by just taking all string values except for "vanc" as the actual leadout string — however, in the latter case, the parameter name should be changed to become more meaningful again)

or

• |display-<names>= (either using negative values -1, -2, etc. to use & instead of the default leadout, or any string values other than "etal" to define the leadout string — in the latter case, the feature could not be used in combination with actually display-truncated lists, and in both cases, the parameter name may need to be changed as well).

If the feature is only rarely used, it could even be emulated manually using |<name>-maskn=, but this would give more options than necessary including some undermining the feature, so it would only be an option for occasional use.

--Matthiaspaul (talk) 23:01, 19 August 2020 (UTC)

I don't think that I like |list-leadout= because leadout seems rather more jargon-ish than most cs1|2 parameters. I don't particularly care for |namelist-last-sep= for the same reason.

The language list uses <space>and<space> (two languages) and ,<space>and<space> (three+ languages). I see no reason to change that.

I do rather like |name-list-format=amp and |name-list-format=and because that parameter applies to all name lists. amp and and will not conflict with vanc because Vancouver style only supports comma separators between names.

I don't think that name-list separators have anything to do with the purpose |display-<name-list>= serves (and negative numbers are just too cryptic). As it works now, |display-<name-list>= causes cs1|2 to ignore |last-name-amp=. I think that this is probably the correct action to take when both parameters are present.

—Trappist the monk (talk) 00:12, 20 August 2020 (UTC)

I forgot about the language list, but, like you, I don't see any need for a change there.

I mentioned |display-<names>= only for completeness and because it also deals in some way with the last name in a list, but I completely agree with you, that semantically it has a very different purpose. (Talking about it, this reminds me that these parameters should better be named |authors-display=/|editors-display= than |display-authors=/|editors-display= to follow the naming scheme of most of the other modern parameters to further differentiate on the left rather than the right side.)

I, too, find |name-list-format=amp[ersand]/and/vanc a good name for the purpose (and much better than |last-author-amp=yes), and also like the idea of limiting the choices to a few hardwired tokens instead of allowing this parameter to accept free text.

--Matthiaspaul (talk) 10:44, 20 August 2020 (UTC)

We really should rename |name-list-format= to something shorter, like |nf= (which is short for name format) in parrallel to |df= (which is short for date format). Headbomb {t · c · p · b} 19:58, 23 August 2020 (UTC)

In the sandbox I have extended |name-list-format= to allow the additional keywords amp and and:

• {{cite book/new |title=Title |author=Black |author2=Brown |name-list-format=amp}} → Black; Brown. Title. {{cite book}}: Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (help)
• {{cite book/new |title=Title |author=Black |author2=Brown |name-list-format=and}} → Black; Brown. Title. {{cite book}}: Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (help)
• {{cite book/new |title=Title |author=Black |author2=Brown |author3=Red |name-list-format=amp}} → Black; Brown; Red. Title. {{cite book}}: Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (help)
• {{cite book/new |title=Title |author=Black |author2=Brown |author3=Red |name-list-format=and}} → Black; Brown; Red. Title. {{cite book}}: Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (help)

|last-author-amp= still works:

• {{cite book/new |title=Title |author=Black |author2=Brown |last-author-amp=yes}} → Black; Brown. Title. {{cite book}}: Unknown parameter |last-author-amp= ignored (|name-list-style= suggested) (help)

I wonder about the punctuation for and. It looks odd to me without the name separator in the three-name list:

• Black; Brown and Red

or

• Black; Brown; and Red

Which is better? more correct?

—Trappist the monk (talk) 10:59, 4 September 2020 (UTC)

MOS has a preference for the Oxford/serial comma, which I think reasonably extends to our use of the semicolon. --Izno (talk) 14:35, 4 September 2020 (UTC)

The following links indicate that a serial semicolon analogon to the serial comma exists, although it can't be exactly common (I cannot remember to have ever seen this in the wild and it looks quite odd to me):

• https://english.stackexchange.com/questions/402252/is-there-an-oxford-semicolon
• https://english.stackexchange.com/questions/121809/do-i-use-a-semicolon-before-and-in-a-complex-list
• https://myooka.wordpress.com/2011/05/12/the-serial-semicolons/

Given that our specific use case here is a list of names and the fact that corporate names may include the conjunction "and" as well, I nevertheless tend to prefer the second form to avoid ambiguities. This would also be consistent with the way the language lists works at present.

Or go yet a bit further by generalizing the parameter |name-list-format= into |list-format= (also shorter per Headbomb), adding another token like "serial", and (despite what we both wrote above) apply the setting to both, name and language lists with "serial" being the default (also in the "vanc" case)?

--Matthiaspaul (talk) 15:54, 4 September 2020 (UTC)

Tweaked to use ; and for name-lists of three or more but your point about corporate names would also suggest the same tweak for two-name lists and also for name-lists that use the ampersand.

As part of this change, in ~/Configuration for i18n I created sep_nl_and and sep_nl_end in presentation {} and have renamed:

parameter-separator → sep_list

parameter-final-separator → sep_list_end

parameter-pair-separator → sep_list_pair

These were in messages{} but I have moved them to presentation {} where they more properly belong. This change applies to the |language= list and error-message lists. I had hoped that I could use a common function to handle the writing of name lists and language lists but |<name-list>-mask=<text> heaves a spanner into the works because the rendered value from text-masked names uses a space character as a separator. I may still write that function so that at least the language-name and error-message lists can share common code.

Also as part of this change, and unrelated to it, I added require('Module:No globals') which I'm pretty sure used to exist in one of the modules though I can't now find where that was ... This addition brought to light a handful of items that oughtn't to have had global scope so I have marked those items local.

This parameter is for name lists so its name should reflect that; vanc has no meaning for language or error-message lists.

—Trappist the monk (talk) 22:14, 5 September 2020 (UTC)

In Module:Citation/CS1/Utilities/sandbox I have created list_make() as the common function that makes a comma-separated list (other separators possible) with selected coordinating conjunction. This function is now used to render certain error messages and to render the languages list:

{{cite book/new |title=Title |chapter=Chapter |section=Section}}

"Chapter". Title. {{cite book}}: More than one of |section= and |chapter= specified (help)

{{cite book/new |title=Title |page=1 |pages=23–24 |at=¶6}}

Title. p. 1. {{cite book}}: More than one of |pages=, |at=, and |page= specified (help)

and the language list:

{{cite book/new |title=Title |language=ale}} → Title (in Aleut).

{{cite book/new |title=Title |language=cop, la}} → Title (in Coptic and Latin).

{{cite book/new |title=Title |language=nv, chy, zun}} → Title (in Navajo, Cheyenne, and Zuni).

This one illustrated here because the error message may be assembled in two modules:

{{cite book/new |title=Title |year=2002 |date=2001 Dec 2}} – assembled in Module:Citation/CS1/Date validation/sandbox and Module:Citation/CS1/sandbox

Title. 2001 Dec 2. {{cite book}}: Check date values in: |date= and |year= / |date= mismatch (help)

{{cite book/new |title=Title |date=2001 Dec 2 |url=//example.com |access-date=2001}} – assembled in ~/Date validation/sandbox

Title. 2001 Dec 2. Retrieved 2001. {{cite book}}: Check date values in: |access-date= and |date= (help)

Excepting the coordinating conjunction, date error messaging renders differently from the live messaging for the same errors (separator font):

Title. 2001 Dec 2. Retrieved 2001. {{cite book}}: Check date values in: |year=, |access-date=, |date=, and |year= / |date= mismatch (help)CS1 maint: year (link)

Title. 2001 Dec 2. Retrieved 2001. {{cite book}}: Check date values in: |year=, |access-date=, |date=, and |year= / |date= mismatch (help)CS1 maint: year (link)

—Trappist the monk (talk) 17:33, 11 September 2020 (UTC)

Just for reference sake, deprecation will cause a change to about 36k pages. --Izno (talk) 17:04, 4 September 2020 (UTC)

Yep, know about that. I have a bot task pretty much ready to go. In testing that task I learned that it is almost never the case that all cs1|2 templates in an article that could make use of |last-author-amp= (those cs1|2 templates that have two or more names in a name-list) actually have |last-author-amp=. These came from the top of my article list from my testing a week or more ago:

Belarus – 1 use in 18 eligible templates

India – 2 uses in 88

Barack Obama – 1 use in 82

Australia – 1 use in 27

Ronald Reagan – 6 uses in 33

It will, I think be the rare case that every eligible template in an article uses |last-author-amp=.

Alas, BRFAs require test runs so until the deprecation goes live (which includes the new keywords for |name-list-format=), there isn't much progress to be made.

—Trappist the monk (talk) 17:50, 4 September 2020 (UTC)

Given that so many pages need to be touched (but can be fixed up by a bot), I actually think we should change the parameter name |name-list-format= into |list-format= (regardless of if we add the "serial" token or not), so that we don't have to change them all again at a later stage.

Meanwhile I actually think we should add the "serial" token as well to allow citations to blend in perfectly with a pre-existing list style in articles.

--Matthiaspaul (talk) 15:24, 5 September 2020 (UTC)

Going through the parameter list, the term "format" is currently used for three different things:

* To specify the document format of URL links with |format= and variants like |archive-format=, |chapter-format=, |section-format=, |entry-format=, |article-format=, |conference-format=, |contribution-format=, |event-format=, |lay-format=, |transscript-format=

* In the |name-list-format= parameter above

* (Indirectly in the |df= ("dat a e format") parameter)

Therefore, in our attempt to improve the consistency of parameter names, I think, we should change the |name-list-format= to something not containing the term "format" any more. Existing usage of |name-list-format=vanc amounts to some 6.5k citations, but if we have to run a bot on 36k entries anyway, before we hammer it into stone forever, another 6.5k edits doesn't really matter, if we thereby reach a higher level of consistency.

Probably the easiest choice would be |name-list=, but this might be misleading. We have |mailing-list= and |series-separator= already. |name-list-separator=? |list-separator=? |separator-style=? |name-list-style=? |list-style=? Opinions?

--Matthiaspaul (talk) 10:28, 9 September 2020 (UTC)

|series-separator= was apparently invented for an early lua version of {{cite episode}}. I can't find where it was actually used in the wikitext version of that template. When I migrated {{cite episode}} to the module suite, |series-separator= was not included. And then came the great separator purge with the invention of |mode=. I'm astonished that |series-separator= survived the purge (an indication of too damn many parameters?). I will remove it and its meta-parameter.

When we invented |mode=, my preferred name for that parameter was |style=. That was rejected, in part, because it would be the same as the html style= attribute.

And |df= is date format, not data.

—Trappist the monk (talk) 11:37, 9 September 2020 (UTC)

I was wondering what that is - this explains why I didn't find anything regarding |series-separator=... ;-)

type is in use as well already.

|separator-mode=? |name-list-mode=? |list-mode=?

--Matthiaspaul (talk) 12:28, 9 September 2020 (UTC)

But if it can't be |name-list-type= because |type= then it can't be |name-list-mode= because |mode=, right?

—Trappist the monk (talk) 12:35, 9 September 2020 (UTC)

Almost. ;-) It would have to be |cite-mode= then (another 6.9k hits)... (the old problem of too unspecific parameter names biting again) ;->

In the case of mode the two settings are at least both switching between different ways how citations are rendered, whereas in the case of type, the pre-existing usage of the parameter is to specify the media type ("Video") or formal document type ("Essay", "Report"), something not even remotely related to a list style in the citation itself.

I still like style; while it is true that we should try to maintain consistent parameter names across Wikipedia, I think it is even more important to at least reach a logical and consistent parameter naming scheme among the citation templates. So, if we don't find something linguistically and semantically more pleasing, I would still opt for something ending on -style - and if a temporarily confused editor would accidently throw HTML at it this wouldn't cause harm but just return an error message.

BTW. The old thread was Help_talk:Citation_Style_1/Archive_7#Display_parameters:_do_we_need_them?

Any other suggestions?

--Matthiaspaul (talk) 20:40, 9 September 2020 (UTC)

Two-and-a-half weeks have passed without an answer. As we need to find a good new name for the parameter before the pending update of the template (because otherwise, the bot task would hammer the -format name into stone forever), I have continued to seek for alternatives. Some remarks:

• |name-list-format= is inadequate for our purpose, because semantically, -format implicitly deals with input data. Also, as detailed above, we have an otherwise consistent established use for this already, so we really should use something different here.
• |name-list-mode= could be a good choice, but then we should move the existing |-mode= to |cite-mode= or similar (and leave |mode= as an alias for it). Semantically, -mode affects some internal configuration of the template and possibly the output, so while it would fit into a future parameter class |-mode= for all kinds of mode settings, it is not a perfect match.
• |name-list-style= is linguistically very pleasing and semantically a well-suited name, as -style implies that this parameter somehow deals with output data. The HTML argument against |style= does not really apply, as our parameter would be named |name-list-style= rather than just |style=.
• |name-list-appearance= is, like |name-list-style=, linguistically and semantically well-suited, but quite long.
• |name-list-display= might be a good choice as well, in particular if we also switch the semantically misleading |display-names= parameters to the |name-display= form, which are semantically better suited and in compliance with our parameter naming conventions to list the input "type" last and disambiguate on the left side. Switching these names (and keeping the older ones as aliases for now) would considerably improve the consistency in documentation and make it easier to remember the parameter names. |name-list-display=vanc/and/amp would fit in the group of |author-display=0/n/etal/|editor-display=0/n/etal, etc. parameters if we define the -display as a parameter class to change the appearance of a citation and not change the template's internal configuration.

Other synonymns I came up with were linguistically or semantically worse.

My order of preference is (in descending order): |name-list-display=, |name-list-style=, |name-list-mode=

Which one should we choose?

--Matthiaspaul (talk) 21:27, 27 September 2020 (UTC)

I'm perplexed. Here you complain that the bot task would hammer the -format name into stone forever) yet, elsewhere on this page you appear to anticipate that |title=none will redefined in future. If the [hammered] ... into stone argument applies to the one it must also apply to the other.

semantically, -format implicitly deals with input data. Really? Where do you get that notion?

If we must choose another name (I'm not yet convinced that we must), I would choose |name-list-style= because this |<noun>-<verb>= parameter in combination with its assigned value, instructs cs1|2 how to style the name lists.

—Trappist the monk (talk) 14:54, 29 September 2020 (UTC)

Trappist, thanks for taking the time to think about it and your answer. Having thought about the various parameter classes and their possible future extensions for another two days, I have also come to the conclusion that |name-list-style= is the best name, and that the argument regarding a possible clash with the HTML style= attribute can be ignored here.

Regarding format being associated with input data, I had hoped that my "implicitly" would make it clear that this was meant in the context of our usage in citation templates; all the other parameters using format describe input data, |name-list-format= is the sole exception. In general, format can be associated with output data as well, of course, but at least not with internal states such as mode. While the name is "bearable" and we are used to just use what is given, if, in our attempt to improve the user interface for normal users, we seek for the most-suitable parameter name fitting into our naming scheme, such nuances or subtleties are important to become aware of. Does this make things clearer? It is also possible that not all people have the same associations... ;-)

There is no reason to be perplexed: If we keep the |name-list-format= name, your bot task will hammer it into 36k articles since we merge |last-author-amp= into this parameter. The number would be much too high to carry out this change manually (and also non-neglectible for a bot), but fortunately we have your bot task. Now, if we use |name-list-style= instead, your script will have to edit another 6.5k articles (not much of an addition for the bot, therefore acceptable), but in the end we'd have a parameter name which does not clash with other semantically considerably different uses of parameters of the -format class (as discussed above), and if we would have other settings only affecting the output we could use the -style class for them as well. If we skip this chance to rename the parameter, and would decide that |name-list-format= needs to be changed later, we would have to run a bot just for this task on 42.5k articles (which might be too much to be acceptable). So, doing it now, we can "save" 36k edits. That's why I think we should not skip the chance. (Even, if we want to freeze the code now for the update and could not come to a decision before it, I think, we should include it in the update, because if we would decide against it, we could still silently remove it again in the next update, whereas if we don't include it and then decide to use it, we would have to delay the deprecation of the |last-author-amp= parameter for another quarter.)

(Regarding redefining |title=none, that's a completely different case (best discussed in the other thread), but IIRC it only affects some 1k cites, so it is even possible to achieve manually.)

--Matthiaspaul (talk) 18:04, 29 September 2020 (UTC)

One comment regarding any change: remember that {{harv}} et al. use an ampersand. In articles that repeat references to the same book, I put the full citation on first reference and then use {{harvp}} for subsequent references, akin to how The Chicago Manual of Style shortens subsequent footnotes to a previously used source. If |last-author-amp= weren't available, I'd run into an inconsistency where full citations and shortened citations in the same reference list won't do similar things. (See footnotes 40 [full] and 51 [shortened] or footnotes 50 [full] and 55–57 [shortened] in Michigan State Trunkline Highway System for an example in just one article. Every eligible footnote should be using |last-author-amp= as well.) Imzadi 1979 → 00:46, 6 September 2020 (UTC)

I don't understand the point you are attempting to make here. It appears that you think that the |last-author-amp= functionality is going to go away because that parameter will be deprecated. Not true. |last-author-amp=yes shall be replaced with |name-list-format=amp. Writing your example citations using the sandbox:

{{cite web/new |url = http://www.michiganhighways.org/history.html |title = The History of Roads in Michigan |last1 = Pohl |first1 = Dorothy G. |last2 = Brown |first2 = Norman E. |name-list-format = amp |publisher = Association of Southern Michigan Road Commissions |date = December 2, 1997 |access-date = September 11, 2008 |page = 1 }}

Pohl, Dorothy G.; Brown, Norman E. (December 2, 1997). "The History of Roads in Michigan". Association of Southern Michigan Road Commissions. p. 1. Retrieved September 11, 2008. {{cite web}}: Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (help)

{{harvp|Pohl|Brown|1997|p=3 }}

Pohl & Brown (1997), p. 3

How does that not give you what you want? Or are you silently complaining about the possible inclusion of a name separator with the ampersand: ; & so the {{cite web}} would render like this:

Pohl, Dorothy G.; & Brown, Norman E. (December 2, 1997). "The History of Roads in Michigan". Association of Southern Michigan Road Commissions. p. 1. Retrieved September 11, 2008.

My prospective bot task reports that all eligible cs1|2 templates in Michigan State Trunkline Highway System are using |last-author-amp=yes. Seems peculiar to me that the long-form cite is for page 1 but the short-form cite is for page 3.

—Trappist the monk (talk) 01:27, 6 September 2020 (UTC)

Monkbot task 17; BRFA

—Trappist the monk (talk) 16:07, 4 October 2020 (UTC)

Yes. I, too, and wondering about circumstance in which a previous editor, for a citation containing three authors, invoked the name-list-style=amp parameter, producing thus: Last1, First1; Last2, First2 & Last3, First3. It just looks weird to me. — Christopher, Sheridan, OR (talk) 06:28, 2 November 2020 (UTC)

Nbsp in |author, |last, and equivalents for other contributors

Prior to the last release, the code that looks for looked for a count of characters that was more than 1 of either commas or semicolons. For example, |author=Last, First, Jr. or something like |last=Last; Last2; Last3 (unfortunately not contrived :( ) would have triggered the maintenance message, both of which still today emit a maintenance message. (I am not sure if a mix of semicolon and comma would have done the same but think one semicolon and one comma would have.)

However, the behavior changed in the last release so that now commas and semicolons are counted separately, and if there are more than 0 semicolons, the module emits the maintenance message.

Due to an error on my part (perhaps the original code also contained the error, I haven't tested), it is now the case that any HTML entity encoding will be identified as needing maintenance. This is most common with the non-breaking space (i.e.  ), as in the last two cases of test_Mult_names on Module talk:Citation/CS1/testcases/errors. (Perhaps this is why the check was originally at least 1 semicolon, I do not know.) I noticed this because I had been working on the category for authors, which had been hanging around 13k, which is now some 30k pages (and I do not think there were that many semicolons... maybe there were and I have found a hidey hole of cleaning. :)

For a discrete example, a construction like |author=Tolkien, J. R. R. aka |author=Tolkien, J. R. R. (those are non-breaking spaces) emits the message currently.

• Tolkien, J. R. R. Title. (JRR would probably have triggered this message before the last release since it has two non-breaking spaces.)

Is it worthwhile supporting HTML entities in |author=/|last=? It will come up in the |author= case most-often as we rarely abbreviate last names (and moreover almost-never have multiple last names to abbreviate), for which a 95% solution can be a conversion to |last= |first= as this check does not occur for |first= (we prefer the use of |last= |first= anyway for best metadata generation). Cases other than can be worked on if they occur, since nbsp is not the only kind of entity that could end up encoded this way in |author= (I am skeptical it would occur in most uses of |last=). By worked on I mean that we can create templates similar to {{ndash}}, or convert to the Unicode representation.

Aside: I don't know if it would be reasonable for the software to be checking |first=; I suspect so given some constructions in the wild I've seen.

Thoughts? --Izno (talk) 20:42, 24 October 2020 (UTC)

I would think non-breaking spaces (using any mechanism) may be important in situations where author names separated by a hyphen? One could argue that some readers could be confused or misunderstand a citation that splits a compound last or first name into a newline. I haven't looked at the code to see how it handles such cases. 98.0.246.242 (talk) 01:31, 25 October 2020 (UTC)

Not non-breaking spaces, but dashes/hyphens/straight lines in the middle of names, for which we do already have other workarounds. --Izno (talk) 01:38, 25 October 2020 (UTC)

Right. I mixed up non-breaking with non-wrapping in my previous comment. So now I cannot think of any other use-case for such markup, but who knows. 98.0.246.242 (talk) 02:06, 25 October 2020 (UTC)

Multiple authors' names should never be separated by any type of hyphen or dash or slash or whatever, if that's what the IP is asking. They should be separated by entering them as separate parameters (or by a comma, but only when using "Vancouver style" in which both periods and spaces are omitted from authors' initials anyway, and therefore moot).

Adding non-breaking spaces to the output for any first-name input which matches (in whole or part) a pattern of multiple consecutive initials (spaced or unspaced) seems like an easy task for regular expressions inside the module. This would be more robust than encouraging or requiring users to include html entities in the input, or even think about doing so.

There are of course certain abbreviations which look like a person's initials but should remain unspaced according to the MOS. It's conceivable that some user might enter something other than a person's name, such as |author=U.S. Treasury but in reality that should be spelled out and moved to |publisher=United States Treasury.

Of course, an even lazier approach might be to just enclose the output for every firstname and every lastname in a span with some class CSS-styled as white-space: nowrap. This would (rather aggressively!) prevent wrapping when name parts contain (a) initials (e.g. |first=J. R. R. or |first=F. Scott), and/or (b) real or implied hyphens (e.g. |first=Mary-Kate or |last=Lloyd Webber), which would otherwise risk being wrapped in the middle of. ―cobaltcigs 18:54, 25 October 2020 (UTC)

Please do not do that last, "aggressive" proposal. There are too many cases like |author=U.S. Select Foobarian Subcommittee of the International Committee of Bazquuxians for Global Widgetization-Dingusification Standards (where |publisher= has another long-winded thing that is the parent organization name[s]).  — SMcCandlish ☏ ¢ 😼  22:15, 26 October 2020 (UTC)

Only names divided into a |first= and |last= part would be affected. Between two nowrap spans would be a comma and a regular space, where wrapping would be permitted. Barring bad input, that should only be individual human authors. And not even all of them. ―cobaltcigs 01:29, 1 November 2020 (UTC)

|author=, used regularly for organizational authors, is a synonym for |last=. Nowrapping the output for that parameter is accordingly a no-go due to regular column size constraints. (I have said a few times now that we should have a |org-author=, but alas, it has not happened.) --Izno (talk) 01:36, 1 November 2020 (UTC)

In the long run, it might be necessary to decouple |author= from |last= to improve support for foreign names, anyway. But I agree that right now it would not be worth the trouble to change this just to improve some wrapping behaviour. Given that wrapping in the middle of initials looks particularly odd, adding automatic "anti-wrapping" to |first= could already improve the display of names somewhat.

--Matthiaspaul (talk) 02:02, 6 November 2020 (UTC)

As for the template behavior, it would be nice if it permitted &nbsp; and other entities, and excluded any &...; pattern from its counts of semicolons while trying to detect improper input. Now that I'm migrating back to Windows I'm remember what a hassle it is to get various special characters inserted, though I think I will buy PopChar for Windows and hope that it works as well as the Mac one (esp. compared to Windows Character Map). Even if we wish people would always use the composed Unicode character, we know that they will not. And &nbsp; is actually desirable, since no one can visually tell the difference between a regular space and a non-breaking one otherwise.  — SMcCandlish ☏ ¢ 😼  22:15, 26 October 2020 (UTC)

Right, we don't want to use the invisible character. We have a separate test for the invisible control characters that will emit an error. Invisible very badddd.

However, as I said earlier, we can encourage the use of {{nbsp}} to meet this user desire. Or encourage the use of normal spaces. (Now that I look, there is the caveat at WP:NBSP regarding the use of the template with links. Maybe that is sufficient reason to support it until there is some consensus about whether non-breaking behavior is actually desirable in the citation templates.)

I do not think there is a general way to allow all HTML entities. We would need to add and check against some published list (perhaps of the most common), which seems like overkill for most, since most others (maybe all-of-interest) have a visible alternative.

Finally, though I disagree with permitting &nbsp;, I've tweaked the module to discount these markers. You can see the output for yourself at test_Mult_names in Module talk:Citation/CS1/testcases/errors, where the two affected test cases are orange as not-matching (because we just compare against the live version rather than the preferred output of course ;). --Izno (talk) 05:45, 2 November 2020 (UTC)

I guess I don't think that we should support the use of   in the namelists. We have noted at Template:Citation Style documentation#COinS that html entities should not be used in parameters that contribute to the citation's metadata; we should not allow something on the one hand but disallow it on the other hand. {{nbsp}} is not appropriate for use in cs1|2 templates because it will cause the inclusion of all of this in the name's metadata:

<span class="nowrap">&nbsp;</span>

cs1|2 wraps some or all of the value assigned to |access-date= in <span class="nowrap">...</span> because |access-date= is rendered at the end of the citation. That was an experiment conducted quite long ago. Did anyone notice? We don't similarly wrap |isbn= which, because of the permitted (desired) hyphens and occurring at the end of a book citation rendering, can break oddly. Did anyone notice?

And beyond the first name or maybe three, who reads the namelists in a citation? Yeah, I know, wandering a bit off topic, but wouldn't it be better for us to set a default |display-<names>= value so that all cs1|2 templates show the default number of names (+ et al when there are more names in the template)? Do we really need to display 400 names? or even 29? (that's a popular number; why?) who is going to read or even need all of those names to locate the source?

—Trappist the monk (talk) 13:03, 2 November 2020 (UTC)

Anecdotally I probably notice on occasion, but never something like "oh, I would miss this were it gone".

who reads the namelists in a citation I do not, but that might be something that varies by domain and no-doubt by personality. When I see namelists longer than 6 is when I personally add the et al in my gnoming.

I think some tool at some point was limited to 29, Citoid or refill perhaps. I've noticed a similar pattern (but again, maybe anecdotal).

It is interesting that there is a suggestion not to use nbsp in COinS parameters. I am not sure what opinion I have of that, but our typical implementation has been to categorize and remove metadata problems. Consider that we perform a substitution in page handling of dashes; we could do the same for author lists. --Izno (talk) 15:08, 2 November 2020 (UTC)

I added that suggestion, and though I don't remember exactly why, I suspect it was to avoid having to add support to translate every html entity into its unicode character form. The page handling of — and – was necessary to resolve a technical issue because editors will use a semicolon between individual page numbers when a comma should have been used.

—Trappist the monk (talk) 16:56, 2 November 2020 (UTC)

While I sometimes study author lists, including longer ones of a few dozens, I have yet to see and study a list of 400 names. Nevertheless, I don't think we should set a default limit for |display-name=. This should remain up to the editorial judgement of the article editors, not us. Setting a too low limit would also make it more difficult to enter longer lists, as one would first have to add |display-name=some-high-value to see the remaining names. Courtesy dictates to try to list all authors of a work and limit the display for practical reasons only where necessary. Depending on the "house standard" for author lists (alphabetical order, chronological increasing/decreasing order, increasing/decreasing importance by amount of contribution or "status", no order, etc.) being followed, the first author is not necessarily the main author. The editors of an article probably have the best insight into a source and context to set the display limit to an appropriate value for a citation, if necessary.

Regarding methods to avoid orphans, yes, I have occasionally recognized this (I'm one of those editors who sometimes inserts   between the last two words of a paragraph to improve text flow appearance on some browsers).

As an aside regarding <span class="nowrap">, does someone know if it is possible to define a kind-of-strength for nowrapping so that the browser tries not to wrap (for as long as possible), but would start wrapping anyway when it could otherwise not avoid a horizontal scrollbar or truncation on narrow windows?

--Matthiaspaul (talk) 02:02, 6 November 2020 (UTC)

DIEP flap – 380 names. Setting the default to say, six, accomplishes the purpose of helping readers locate the source. In other discussions, editors have stated that identifiers and their links are not reader friendly (I disagree, readers are not stupid) but if that argument maintains, then surely an excessive number of authors will also dissuade readers from seeking the source. If by Courtesy dictates to try to list all authors you mean courtesy to the authors, then I disagree. Citations are not here to serve as 'credits'; that is the duty of the publisher. Courtesy plays no part in citations except as a courtesy to the reader to provide consistent, understandable, identification of the sources used by en.wiki editors to create and maintain the encyclopedia's articles.

I don't know of any citation style that requires name-lists in citations to be ordered in any way except the order in which they are named in the source; to sort the names in a list any other way is to do a disservice to readers. Of course, editors of an article probably have the best insight into a source and context to set the display limit to an appropriate value; setting a default limit does not take away from that editorial discretion.

Isn't the insertion of   between the last two words of a paragraph discouraged because what you see on your screen doesn't necessarily mean that any other viewers will see the same thing?

I am not sufficiently versed in the minutia of css so I can't answer the kind-of-strength for nowrapping question though there is the html tag <wbr />. It is my understanding that using   to prevent line breaks is discouraged in favor of css: <span class="nowrap">$1</span>. That would add 28 characters to every |firstn= that is breakable. We could minimize that to some extent by nowrapping the entire name list and insert <wbr /> between authors and between last and first names:

<span class="nowrap">Black, <wbr/>A; <wbr/>Brown, <wbr/>B; <wbr/>Red, <wbr/>C; <wbr/>Orange, D.</span>

—Trappist the monk (talk) 14:50, 6 November 2020 (UTC)

Thanks for the link. :-) I don't find this list intimidating, except for that this is a clear case for list-defined references rather than inline references. If there would be many citations with such long lists of contributors in an article, it would probably start to look strange at some point - that's when |display-authors= would come in handy at the editor's discretion. Interestingly enough, in this example citation, the authors are listed in alphabetically ascending order (actually, in this particular example, two such lists), so, when you would cut the list at some arbitrary point, you'd risk missing main contributors. I don't find this desirable at all.

Regarding Courtesy dictates to try to list all authors, yes, I meant the authors of the cited work. If they are listed in the published work, we should specify them as well (by default). If those authors wouldn't have published their work, we could not cite it, so I see us as a continuation in a line of works built upon each other in an environment where it is common to list the sources (to avoid circular references and help identify false information).

Citations are not only used to locate a source, but also to evaluate the significance of statements ("Is there a widely known and trustable expert on a field among the authors?") or as a starting point for new research ("Let's check the authors' affiliations for related works and other publications."). Also, having a pre-defined default limit makes entering larger lists somewhat more difficult if there are more authors than what is defined as a limit. So, it's better to leave it to the article authors to set an upper limit (if necessary at all).

Regarding "house styles", here I meant publishing standards, not citation standards. Of course, we should list authors in the order given in the source, if such an order is determinable (as is the case most of the time). In many cases, the most important authors for a work are listed among the first, but unfortunately different organizations have different publication conventions to the effect that it is also possible that significant or even the most important contributors happen to be listed in the middle or the end.

Regarding concatenating the last two words of a paragraph with  , this is quite common among web designers. It dates back to times long before the introduction of CSS and works even with the oldest browsers. As you wrote, the text of a page will flow differently depending on the width of the window (and other things). However, the   will have no effect except for when the browser would otherwise move the last word of a paragraph into a new line, whereas with   in place the browser would ensure that there will be at least two words in the last line of a paragraph, thereby preventing the last word from becoming an orphan. This might no longer be necessary with browsers supporting CSS, but also can't harm (unless the two words would be long and force the browser to go into an otherwise unnecessary horizontal scrolling mode, which, of course, would be counter-productive).

--Matthiaspaul (talk) 12:47, 7 November 2020 (UTC)

Nbsps in MediaWiki

(Slightly offtopic to nbsps in citation templates so split Cobalt's reply from SMC's comment SMC at 22:15, 26 October 2020 (UTC) in #Nbsp_in_|author,_|last,_and_equivalents_for_other_contributors to its own thread.)

Assuming your browser renders the above character U+1F63C CAT FACE WITH WRY SMILE in a colorful way (as mine does), you can determine which font said browser is using, then edit that font to fill the glyph bounds for U+00A0 NO-BREAK SPACE with some light pastel color (instead of transparent nothingness). This will give every nbsp on the page a subtle glow (much like shining a UV flashlight across a motel room), without being too distracting to read. I use a technique similar to this myself. Among other things, you'll become aware of situations where the MediaWiki software replaces regular spaces with nbsp on its own for no apparent reason (e.g. before ! or ?). Perhaps if the rules for doing this could be configured on a per-wiki basis, everyone would be happy. ―cobaltcigs 01:40, 1 November 2020 (UTC)

P.S. Never pay for software. I use BirdFont (what, no article?) for editing and gucharmap for character lookup by name. Brief research suggests both have been ported to Windows—where they probably work equally well, but I can't confirm that. ―cobaltcigs 01:40, 1 November 2020 (UTC)

I assume you are referring to the edit window when discussing the novel (distinguishing color) markup for non-breaking spaces. The user (reader) version should be free of any visible formatting notation or artifact - transparent nothingness is best, in this case.

I haven't verified the MediaWiki soft-space replacement before punctuation that you indicated above. If true, it is odd. Normally, space of any kind is considered erroneous practice if it is before most punctuation - it breaks continuity between the punctuation mark and the text the punctuation is supposed to apply to. For similar semantic (and esthetic) reasons, sentences should not wrap until after punctuation marks. Adding a hard space is compounding an error. 98.0.246.242 (talk) 04:13, 1 November 2020 (UTC)

I know of one place where MediaWiki will insert non breaking spaces (before %), but that should only occur on French Wikipedia. --Izno (talk) 14:26, 1 November 2020 (UTC)

Not so. See example screenshot (enwiki edit preview, with highlighting hacks enabled). ―cobaltcigs 19:18, 1 November 2020 (UTC)

And another, lol. ―cobaltcigs 19:26, 1 November 2020 (UTC)

@Cobaltcigs: I went to verify on phab, apparently having researched this 3 years ago.... phab:T181441#3798402. --Izno (talk) 20:54, 1 November 2020 (UTC)

The exclamation-mark french-space case is problematic in enwiki, but I am not aware of the percent sign being used for punctuation in any language? Not to say there should be a leading space there. It seems that the situation hasn't been resolved, or if it was, there was a parser update or html update that messed up things again. 98.0.246.242 (talk) 21:28, 1 November 2020 (UTC)

The task linked directly in my comment discusses the % sign directly. --Izno (talk) 21:49, 1 November 2020 (UTC)

I went through it before my previous comment. I was just wondering why the behavior persists in enwiki. That is, why is french-spacing applied in situations where French terms are not used. Without examining the related patches (some of them are still in beta, I believe) it seems to me that the parser interprets a space before certain punctuation marks and other characters as attempts at french-spacing and applies the "correct" space format, i.e. a nbsp. However, this seems to be done indiscriminately, it should be done only when French-language terms include such syntax. In English, any such spacing would very likely be wrong. It seems that in the attempt to fix a special case, the general case was botched. 98.0.246.242 (talk) 23:14, 1 November 2020 (UTC)

In case you're confused about the functionality, &nbsp; is not inserted arbitrarily before these symbols. MediaWiki substitutes a plain-ol' space for the non-breaking space, where such a space is present. However, English doesn't use the plain-ol' space (indeed, as you suggest, such spacing would very likely be wrong), so it is usually not an issue here. One might argue that that code should not be executed in our locale at all, but I don't see the fundamental harm, since we wouldn't want those symbols, were they to be separated by a space, to have the same issues with wrapping that originally caused the behavior to be added to the software so long ago (... or at least, the I presume that was why). --Izno (talk) 02:36, 2 November 2020 (UTC)

Hinting on Citation Bot's duplicate parameters

When a citation contains duplicate parameters the Mediawiki software will display a yellow warning at the top of the page:

This is only a preview; your changes have not yet been saved!

Warning: xxxx is calling Template:yyyy with more than one value for the "zzzz" parameter. Only the last value provided will be used.

However, this warning will only be shown in edit preview.

When Citation Bot finds duplicate parameters in citations it renames them by adding a "DUPLICATE_" prefix to them. Our citation template then throws a red error message:

Unknown parameter |DUPLICATE_zzzz= ignored

Since our citation templates can optionally issue a parameter suggestion, I added a rule so that the template would display instead:

Unknown parameter |DUPLICATE_zzzz= ignored (|zzzz= suggested)

However, I was reverted by Izno stating that the parameters should be removed or merged. While this is correct in general, for users to select or merge into one of the duplicate parameters and remove the others, they first need to know the name of the underlying parameter in question. While this can be guessed from the DUPLICATE_* name, this is a private convention used by Citation Bot, and I think it is more user-friendly to name that parameter explicitly in the error message and for consistency to use our own established message system for this (hence my addition of that rule). (The "suggested" in our standard "(|zzzz= suggested)" message does not mean that the suggested parameter is necessarily a direct 1:1 replacement (although it often is), only that it is the (most likely) parameter target that needs to be dealt with to fix the issue and that additional changes may still be required in such a parameter transformation/merge.)

Opinions?

--Matthiaspaul (talk) 23:50, 1 November 2020 (UTC)

Fix Citation Bot so that it doesn't act like a template editor? Such function is way beyond its scope. 98.0.246.242 (talk) 00:11, 2 November 2020 (UTC)

Such function is exactly in its scope because finding duplicate parameter names is something that MediaWiki prevents all templates and modules from doing.

—Trappist the monk (talk) 00:49, 2 November 2020 (UTC)

I thought it was supposed to edit incorrect citations, not the code they are based on. That part, the new parameter class |DUPLICATE_(anything)=, and the accompanying terminology should be discussed, and here. If the bot has to do something it would do better to apply the error message of the preview, which follows longstanding practice in wiki (and many other coding environments). As I think you state below, the current bot action makes for a convoluted situation. 98.0.246.242 (talk) 01:17, 2 November 2020 (UTC)

Were this a serious problem, by which I mean lots of these kinds of error messages in Category:Pages with citations using unsupported parameters attributable to duplicate parameter names, I might be inclined to agree with you.

I don't know for sure, but a quick look into the Citation bot source (line 3271 et seq.) seems to suggest that the bot creates a single |DUPLICATE_zzzz= parameter name for each duplicated parameter name. I don't know if the bot applies this only to valid cs1|2 parameter names. If it doesn't and there are, for example, |blue=yellow and |blue=orange in a cs1|2 template, then the bot will rename one of these, perhaps the first it encounters, perhaps the last, I don't know, to say |DUPLICATE_blue=orange. Then, when cs1|2 sees that, your hint would cause cs1|2 to emit . Not much good to be gained by that.

Certainly, this ought to be mentioned at Help:CS1_errors#Unknown_parameter_|xxxx=_ignored.

—Trappist the monk (talk) 00:49, 2 November 2020 (UTC)

Citation Bot flags the one that is not used. Often the data is good stuff, just in the wrong place. For example the publisher might be set to Reuters and then some one else adds Fox News and fails to convert Reuters to agency. The bot makes the error apparent. AManWithNoPlan (talk) 01:06, 2 November 2020 (UTC)

I like the idea of suggesting a way to fix the problem, either at the category page or on the help page (or both; do they use the same text?), but as AManWithNoPlan says, the solution is usually to fix one of the labels, not simply reinstate the duplicated label. If there are two |publisher= or |last2= parameters, the solution is usually to change one of them (to e.g. |work= or |via= in the first case, or e.g. |last3= or |first2= in the second case). – Jonesey95 (talk) 02:09, 2 November 2020 (UTC)

Yes, the text at the help page is section-transcluded to the category. --Izno (talk) 02:24, 2 November 2020 (UTC)

Yeah, as I wrote the "(|zzzz= suggested)" should not imply that the solution is to just replace the parameter name (or even to just reinstate the duplicate parameter - that would be counter-productive). It just hints that the zzzz parameter is what (most likely) needs to be dealt with.

Still, it might be possible to further improve the hinting system by allowing the right sides of the rules to contain more than one word (or move those into a separate list of rules). The template's code could then issue this text instead of the preformatted "(|zzzz= suggested)" message. There are other cases, where this could be useful to give a few more hints what to do (for example in the case of |editors=, see Help_talk:Citation_Style_1/Archive_72#support_for_|editors=_withdrawn_(in_the_sandbox)).

['^DUPLICATE_(%w+)$'] = '$1'

could become

['^DUPLICATE_(%w+)$'] = 'merge into <code>|$1=</code>'

to display

"(merge into |zzzz=)"

Or

['ignore-isbn-error'] = 'isbn'

could become

['ignore-isbn-error'] = 'use <code>|isbn=((...))</code>'

to display

"(use |isbn=((...)))"

Or

['editors'] = 'editor'

could become

['editors'] = 'split into <code>|editor''n''=</code>'

to display

"(split into |editorn=)"

--Matthiaspaul (talk) 15:45, 3 November 2020 (UTC)

I guess, the |DUPLICATE_blue= scenario is very rare as hardly anyone would repeat a non-existing parameter |blue= more than once. It might occur in the case of previously supported parameters, but then the template would typically throw a message suggesting the new parameter name once someone would try to reintroduce |blue=. So, the user would be led to the correct solution at least by iteration (as in the |editors= example at present).

I found about a dozen uses in mainspace and some 150 in total (including some where the |DUPLICATE_zzzz= parameter was empty), probably because they are actively worked on by some editors. AManWithNoPlan probably has a better overview how often this parameter is being added by the bot.

--Matthiaspaul (talk) 15:45, 3 November 2020 (UTC)

Epic citations

Occasionally come across citations that might be described as "epic". From Parallel (operator):

<ref name="Cajori_1928">{{cite book |author-first=Florian |author-last=Cajori |author-link=Florian Cajori |title=A History of Mathematical Notations – Notations in Elementary Mathematics |chapter=§ 184, § 359, § 368 |volume=1 |orig-date=September 1928 |publisher=[[Open court publishing company]] |location=Chicago, US |date=1993 |edition=two volumes in one unaltered reprint |pages=[https://archive.org/details/historyofmathema00cajo_0/page/193 193, 402–403, 411–412] |isbn=0-486-67766-4 |lccn=93-29211 |url=https://archive.org/details/historyofmathema00cajo_0/page/193 |access-date=2019-07-22 |quote-pages=402–403, 411–412 |quote=§359. […] ∥ for parallel occurs in [[William Oughtred|Oughtred]]'s ''Opuscula mathematica hactenus inedita'' (1677) [p. 197], a posthumous work (§ 184) […] §368. Signs for parallel lines. […] when [[Robert Recorde|Recorde]]'s sign of equality won its way upon [[the Continent]], vertical lines came to be used for parallelism. We find ∥ for "parallel" in [[John Kersey the elder|Kersey]],{{citeref|A|ref=FC-A}} [[John Caswell|Caswell]], [[William Jones (mathematician)|Jones]],{{citeref|B|ref=FC-B}} Wilson,{{citeref|C|ref=FC-C}} [[William Emerson (mathematician)|Emerson]],{{citeref|D|ref=FC-D}} Kambly,{{citeref|E|ref=FC-E}} and the writers of the last fifty years who have been already quoted in connection with other pictographs. Before about 1875 it does not occur as often […] Hall and Stevens{{citeref|F|ref=FC-F}} use "par{{citeref|F|ref=FC-F}} or ∥" for parallel […] {{anchor|FC-A}}[A] [[John Kersey the elder|John Kersey]], ''{{citeref|Kersey (the elder)|1673|Algebra|style=plain}}'' (London, 1673), Book IV, p. 177. {{anchor|FC-B}}[B] [[William Jones (mathematician)|W. Jones]], ''Synopsis palmarioum matheseos'' (London, 1706). {{anchor|FC-C}}[C] John Wilson, ''Trigonometry'' (Edinburgh, 1714), characters explained. {{anchor|FC-D}}[D] [[William Emerson (mathematician)|W. Emerson]], ''Elements of Geometry'' (London, 1763), p. 4. {{anchor|FC-E}}[E] {{ill|Ludwig Kambly{{!}}L.<!-- Ludwig --> Kambly|de|Ludwig Kambly}}, ''Die Elementar-Mathematik'', Part 2: ''Planimetrie'', 43. edition (Breslau, 1876), p. 8. […] {{anchor|FC-F}}[F] H. S.<!-- Henry Sinclair --> Hall and F. H.<!-- Frederick Haller --> Stevens, ''Euclid's Elements'', Parts I and II (London, 1889), p. 10. […]}} [https://monoskop.org/images/2/21/Cajori_Florian_A_History_of_Mathematical_Notations_2_Vols.pdf]</ref>

Might we have a page to document epic/creative usage of a single CS1|2 citation. -- GreenC 14:49, 8 November 2020 (UTC)

Already exists, though likely, very few of us know of it: Module talk:Citation/CS1/Rogues gallery.

—Trappist the monk (talk) 15:05, 8 November 2020 (UTC)

It seems the main problem here is the misused |quote=. Personally I would only use that parameter to quote items relevant to the publication itself (from the verso, index, toc etc.). I would use footnotes for any quoted content. 65.204.10.231 (talk) 15:33, 8 November 2020 (UTC)

There is one even longer in Exponentiation. I think it will the specimen for the museum gallery. -- GreenC 02:56, 11 November 2020 (UTC)

Now on display (last entry). -- GreenC 03:05, 11 November 2020 (UTC)

Epic enough to have its own page in article space. 208.251.187.170 (talk) 13:08, 11 November 2020 (UTC)

A parameter for open content licenses (CC BY) and automatic filling/parsing via reFill and Autofill and/or a bot

Could you add a parameter to indicate open content licenses of studies? Especially (or only) Wikimedia-compatible ones and mainly CC BY 4.0.

Such tags would have many advantages for readers and editors − for instance, they can indicate that the source may have relevant freely licensed images which could be used by the reader or be uploaded (and possibly added to the article) by an editor.

It could work similar to the |doi-access=free parameter and would complement it. In particular this parameter is not about access to the (full-text of the) reference/paper but about the license of the content (in particular whether or not it's an open/compatible license and if so which).

It would be best if this parameter was set automatically by the Autofill tool (the magnify icon in the RefToolbar) and reFill. It could also be set by a bot similar to User:OAbot or even that same bot. Here's an example of one of the bot's changes. However, the parameter could be added to the template before any of these is implemented.

The visual display should include the CC BY 4.0 (or similar) logo, similar to the icon that is displayed for |doi-access=free, so that it's quickly and clearly visible that the respective study is licensed that way. The respective reference could then look like this:

Kawaguchi, Yuko; et al. (26 August 2020). "DNA Damage and Survival Time Course of Deinococcal Cell Pellets During 3 Years of Exposure to Outer Space". Frontiers in Microbiology. 11. doi:10.3389/fmicb.2020.02050. S2CID 221300151.{{cite journal}}: CS1 maint: unflagged free DOI (link) Text and images are available under a Creative Commons Attribution 4.0 International License.

(I'm currently adding it manually as in the above example to references at 2020 in science, which also helps in my, and possibly at some point others', efforts to upload relevant images from these studies to Commons. The above example is from that page.)

--Prototyperspective (talk) 13:49, 24 October 2020 (UTC)

This is a very bad idea - references should be chosen because they are the best, most suitable and reliable sources for the article, not whether they are released under a convenient license. This proposal would merely reinforce FUTON bias.Nigel Ish (talk) 14:03, 24 October 2020 (UTC)

This is not about which references to choose at all.

You could argue against pretty much all the other existing parameters like this; it's irrelevant to this proposal. --Prototyperspective (talk) 14:39, 24 October 2020 (UTC)

No. The purpose of a citation is to identify the source that editors consulted. Licensing of that source doesn't aid the reader in locating the source. Similar proposals have been rejected here before. You might want to troll through the archives of this talk page for those discussions.

—Trappist the monk (talk) 14:49, 24 October 2020 (UTC)

This is not about the selection of which reference to use at all. Agree on The purpose of a citation is to identify the source that editors consulted.

You could argue against pretty much all the other existing parameters (except for the DOI/URL and including the author parameters or the |doi-access= parameter) like this; it's irrelevant to this proposal. --Prototyperspective (talk) 15:08, 24 October 2020 (UTC)

See also:

• Help_talk:Citation_Style_1/Archive_31#Adding_a_license_parameter
• Help_talk:Citation_Style_1/Archive_61#Another_plea_for_a_licence_parameter
• Help_talk:Citation_Style_1/Archive_63#Add_license_parameter

--Matthiaspaul (talk) 12:20, 5 November 2020 (UTC)

• No, per all past discussions concerning this. Citations are there to verify the information, not to advertise, document, and promote whatever random license a specific article, chapter, book, webpage, etc. is published under. Headbomb {t · c · p · b} 17:33, 24 October 2020 (UTC)

• Again: you could argue against most other existing parameters (except for the DOI/URL) like this. Why do we hyperlink the URL, add the date, specify whether or not its full text is open access and specify the language for references? These things have utility for readers (and editors). I'll try to find and read the former discussions. --Prototyperspective (talk) 17:59, 24 October 2020 (UTC)

  Because we follow the best practice as outlined by style guides. Those things identify a citation and help verify information. Free or not let readers know that when clicking on a link, what's on the other end isn't a paywalled article. Language helps the reader know if they can read what's on the other end if they gain access (or who to get to translate if they can't). That an article is published under the GPL, CC-BY-SA, CC-BY-NC, CC-BY, MIT License, or any of dozens of random licenses doesn't help anyone verify the information. Headbomb {t · c · p · b} 18:13, 24 October 2020 (UTC)

  Because we have not discussed at any length removing those, much less obtained consensus. That said, our citation system has grown out of offwiki ones, so information like location and authorship comes from there. Language particularly has been discussed here but never given too much thought (some musings like "why is that there"), the usual answer for which is "I wouldn't want to get this book because I can't read French, and I should know that before trying to verify the content in the article". YMMV on the value. If you'd like to start a discussion on removing one or another parameters, you are free to. (Good luck.) --Izno (talk) 18:16, 24 October 2020 (UTC)

  About the parameters. Modern citation systems didn't just spring up out of nowhere. They were tailored to the needs of rapidly expanding scientific research and high volumes of institutional publications and archives, joined shortly by concerns (both legal and commercial) for attribution. All these works had to be categorized before they were cited. Before electricity and telecoms this was not an easy or standardized endeavor. The simplest solution, to this day, was to classify (and eventually index) by author, title, and date, most often in that order. The place where the work was published and name of those who made the work public came next. The subject was also included but this is dicey, since people 200 years ago had very different ideas of what, say, chemistry is about. Modern citation systems when first devised, followed this model, with some variation. They still do. Because the emphasis of citations is on verifying something easily and quickly (and not to provide encyclopedic-like metadata analysis like a bibliographic reference), many more location parameters were added. "Location" meaning something that helps the reader locate the information. Including marketing identifiers such as ISBN, chapter names, content locators such as URLs, page numbers, and, when the work is in a language different than the citation language, the language, because this makes for more efficient and effective use of the readers' time and resources. Maybe I am missing something, but I don't see any value-add by the proposed parameter. 98.0.246.242 (talk) 01:22, 25 October 2020 (UTC)

  I explained the value added by the parameter. Also see WP:NOTPAPER.

The sincere considerations to remove even information like location and authorship from reference is a perfect showcase of the prevailing thinking related to these matters here whereby improvements, if they are possibly slightly unconventional, are immediately rejected on that basis.

If the utility for verifying the information is the only thing any changes to the templated are being judged by / considered here – for yet unexplained reasons – then information on the license could help with verifying information by third parties via direct inclusion/use of content contained in these references. This shows that at the other end is a reference whose content could be used to verify information to others. --Prototyperspective (talk) 10:38, 25 October 2020 (UTC)

How does knowing the license, if any, tell a reader how to find the cited source? How does knowing the license, if any, tell a reader if the cited source can be read or even understood? The various bibliographic details, like author/date/title/publisher would allow me to find a source. The free access icon lets me know if the source is freely available and not locked behind a paywall. The language notation lets me know if the source is written in a language that I can understand. The license does not help me in those regards. Imzadi 1979 → 13:43, 25 October 2020 (UTC)

• A whole new parameter for this is overkill, but all of the |*-access= parameters (both sets of them) could accept a value of "open" indicating open content (free-as-in-freedom, not just -beer), without wallowing in exact specifics of any license, but perhaps with a particular icon. The preset behavior is that the *url-access group supports "registration", "limited", and "subscription" ("free", as in beer, is the default and isn't supported as an explicit parameter); but the bibcode/doi/hdl/jstor/ol/osti/s2cid-access group supports only "free" (as in beer), because some kind of paywall is the norm in those cases. A side bit is that arxiv/biorxiv/citeseerx/pmc/rfc/ssrn do not have a corresponding *-access parameter because they "are always free-to-read. For those named-identifiers there are no access-indicator parameters, the access level is automatically indicated by the template." Unless we really, really need to distinguish between beer-free and freedom-free in these cases, I'm skeptical that we'd need to add *-access parameters for that third group just to support =open. I think indicating "open" might be of some use. While the primary purpose of our citation is demonstrating that our article material isn't nonsense, we also know that one of the main purposes WP is put to by students and researchers, rather than just the casually curious, is "mining" WP for source material to reuse.  — SMcCandlish ☏ ¢ 😼  22:01, 26 October 2020 (UTC)

While I'm not convinced that we actually need this, I like your solution-oriented approach of attempting to think a problem from a user's perspective and trying to actually address it instead of just telling him it was a bad idea. We should always keep in mind that all the work we are doing while we are developing these templates is to serve editors solve their problems. If they use citation templates for things outside of the original narrow scope, they have a reason for this. In some cases, there are other solutions, but often enough such requests indicate some shortcoming in our templates or sensible new use cases. So, there is always something to learn from such requests. --Matthiaspaul (talk) 13:40, 5 November 2020 (UTC)

• I'm not convinced yet that we actually need this, but it is undeniable that there have been many requests for such a parameter in the past, so there obviously are users who have a need for such information and/or parameter. I don't like the verbose and obtrusive

" Text and images are available under a Creative Commons Attribution 4.0 International License."

appendage suggested by the OP, but providing this information in a very subtle way through a machine-readable parameter and displayed by adding some tool-tip to the title would seem to be an acceptable solution to me. Adding this info as a new value "open" etc. to our |-access= parameters would be misleading, as the license of a work belongs to the work/title "as is", not some specific link. Offline works have licensing terms as well. (The individual webpages for the given identifiers may have usage terms as well, but they are irrelevant in our context aiming to cite a source for the article.) So, the info would have to be associated with the |title=. Such a parameter could be named |title-status= (in analogy to |url-status=) or just |license=. Related, many bibliographic entries in literature databases and metadata also have something like |rights=. For example, in the OpenURL/COinS profile info:ofi/fmt:kev:mtx:dc it is collected in the &rft.rights= tag. So, this could be a suitable parameter name for such kind of information as well.

--Matthiaspaul (talk) 13:40, 5 November 2020 (UTC) (updated 15:11, 14 November 2020 (UTC))