Help talk:Citation Style 1

Citation templates

... in conception

... and in reality

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#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)

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 * (f.e. |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)

trans-quote?

Hi, I feel like I remember a parameter trans-quote for translated quotes from citations in foreign languages. Am I remembering incorrectly, or has this been removed? Thanks, Ezhao02 (talk) 13:31, 5 August 2020 (UTC)

Never existed. |quote= is a free-form parameter so you can include translations in it if you would like. Better in my mind, if the quoted material is important to the article, put that material in the article, translate it there and cite both; don't clutter the references section with quotations.

—Trappist the monk (talk) 13:56, 5 August 2020 (UTC)

Thanks for the information and the advice. Something must have happened to my memory. Ezhao02 (talk) 14:01, 5 August 2020 (UTC)

You probably have seen one of the proposals to add this (and |script-quote=) in the past. While Trappist is right that |quote= is a free-form parameter so you can add your own formatting, it would be desirable to have a consistent style centrally maintained instead of every editor having to invent his own conventions for this. Therefore, such a parameter is desirable. --Matthiaspaul (talk) 12:03, 8 August 2020 (UTC)

In the absence of such a parameter, I prefer to format foreign-language quotations like this: "Lorem ipsum dolor sit amet. [This is a nonsensical example sentence.]" Glades12 (talk) 13:18, 4 September 2020 (UTC)

This is exactly how I do it as well.

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

As this request comes up often enough, I have added support for it:

• {{cite book/new |editor-first=Diogenes |editor-last=Laertius |editor-link=Diogenes Laertius |title=On Plato's Apology of Socrates |title-link=I know that I know nothing |quote-pages=5 |quote=Εn oîda óti oudèn oîda. |script-quote=el:Ἓν οἶδα ὅτι οὐδὲν οἶδα. |trans-quote=I know that I know nothing.}} →

Laertius, Diogenes (ed.). On Plato's Apology of Socrates. p. 5: Εn oîda óti oudèn oîda. Ἓν οἶδα ὅτι οὐδὲν οἶδα. [I know that I know nothing.]

The rendering is not exactly as we both have used it in the past, but it was easier to implement this way. This can be further tweaked in the future.

--Matthiaspaul (talk) 20:33, 27 September 2020 (UTC)

Descriptive titles and tokenizing the "No title" case

Splitted out from the "Wayback Machine" thread above:

I would also [include the many variants of expressing "No title" and] add support for a special token like "no-title" to indicate this condition; so, |title=none would mute the display of a title, whereas |title=no-title would display the descriptive title "[No title]" instead. (Well, if |title=none would not be an established case already, I would recommend |title=off for this instead, so that |title=none would be free to display the "[No title]" message.) While these conditions are more likely to occur in newspapers and journals, the tokens should work in all cite variants, not only some of them (as "none" does at present). This would also simplify the code and documentation.

This way, we would improve consistency across the project, keep editors from inventing their own ways to express this special condition, and enable us to centrally update the message if this would become necessary in the future (f.e. due to a MOS change).

Which brings up another related topic: While the "no title" condition should IMO be a tokenized special case, I think, we should also have a dedicated parameter to enter other so called descriptive titles. (Descriptive titles are titles provided by the editor of a citation which differ from the actual title (if one exists) given by the author of the work. They are used in cases where the actual title is unsuitable to be reproduced in a citation for some reason (like being completely misleading, too long, historical alias names, non-existent etc.).)

We could use something like |desc-title=, |descriptive-title=, |description-title= or just |description= to distinguish them from actual titles. APA recommends to put descriptive titles in square brackets, some other style guides recommend to just write them without any text decoration (including without quotes)). See also:

• https://ucmrp.edmc.edu/idc/groups/webcontent/@edmc_library_bmc/documents/webcontent/edmc-03350678.pdf
• https://blog.apastyle.org/apastyle/2012/05/missing-pieces.html

It could be useful to treat them differently (or even to suppress them) in meta-data, so that descriptive titles don't end up polluting databases without any means to tell them apart from actual titles.

The handling of descriptive titles could be somewhat similar to how we treat |trans-title= already, which reminds me of another related topic that |trans-title= should also work without |title= (instead of throwing an error), so that editors don't have to stuff translated titles into |title= (if the original-language title is not known) causing readers to assume these were the actual titles of a work and thereby causing confusion when trying to locate the work. See Help_talk:Citation_Style_1/Archive_67#Possible_improved_treatment_of_title_parameters_and_language_attributes

Both features, tokenizing the "no title" condition and adding some means to enter descriptive titles differently were requested by several editors in the past already.

--Matthiaspaul (talk) 16:37, 4 September 2020 (UTC)

An example for the usage of the keyword "off" to disable the display of the title and the tokenized descriptive title "No title" in conjunction with auto-linking can be found in Help_talk:Citation_Style_1#Manual_override_of_auto-linking.

--Matthiaspaul (talk) 19:37, 27 September 2020 (UTC)

Request for new maintenance category for abbreviated year ranges in the date= parameter

Hi. Non-abbreviated year ranges are our preferred format for year ranges and there is certainly no particular need to support abbreviated year ranges in citations (except for if we can) - they could certainly be written in non-abbreviated form as well. Year ranges are comparably rare in citations, even more so abbreviated ones, as in most cases the publication date specifies a specific point in time rather than a span. I have seen less than a handful of abbreviated year ranges in citations in all those years.

On the other hand, incomplete dates consisting of only the month and the year and no day are very common in citations (I see them every day), but in the case of the ymd date format, the form "yyyy-mm" is disallowed in order to avoid a possible confusion with "yyyy–yy". Since the EDTF form "yyyy-mm-XX" is not currently supported as well (would be useful at least on source code level, not for display), this leads to such dates being rewritten as "Month yyyy", which unnecessarily creates inconsistency when all the other dates in the citations are given in ymd format.

Hence, it is reasonable to swap this around and fade out and ultimately disallow abbreviated year ranges in the |date= parameter of citations at some point in the future (only there, not elsewhere where they are still allowed, including f.e. in |title=, |chapter=, or |quote= parameters), so that, at some further point in the future, we can officially allow "yyyy-mm" in citations already using the ymd format. (In order to keep the change as minimal as possible, this is meant to affect only citations, not dates in tables or in the article body.)

In order to get a grip on how many citations actually have dates formatted this way at all, I would appreciate a tracking/maintenance category for citations using any detectable form of abbreviated year range (but at least the "yyyy–yy" form). --Matthiaspaul (talk) 13:19, 9 August 2020 (UTC)

Can you please give a list of examples of what you consider abbreviated year ranges? It is unclear what you consider acceptable and unacceptable.

Our date format checking follows MOS:DATESNO and MOS:DATERANGE; is there an invalid format listed there that is not being detected? – Jonesey95 (talk) 15:01, 9 August 2020 (UTC)

Here's an example of an invalid range that is currently detected as an error: Title, 1902–07 {{citation}}: Check date values in: |date= (help). – Jonesey95 (talk) 15:03, 9 August 2020 (UTC)

I don't think so. The idea, however, is to deprecate abbreviated year ranges in citations in general, even where they are currently still allowed by MOS. (Before I hear people screaming: This change should only affect abbreviated year ranges in citations, not other uses anywhere else in an article, which should continue to be allowed under the restrictions already applying per MOS.)

My feeling is that this minimal change to the MOS would impact only very few citations in existence, therefore it should have no actual negative effect on those who prefer abbreviated year ranges. (However, at a later point in time, it would have major advantages for the many articles using citations in ymd format, because then they could write "yyyy-mm" instead of "Month yyyy" when the day is not known.)

But in order to know the actual numbers, we need a maintenance category for abbreviated year ranges.

Here are some examples of abbreviated year ranges:

1881–86, 1881–886, 1881–6, 1881–82, 1881–882, 1881–2

Of those, 1881–886, 1881–6, 1881–882, 1881–2 are not allowed anywhere in Wikipedia (and are probably already ruled out by our template - haven't tried), whereas 1881–86 is allowed in certain contexts if good reasons apply for using them, and 1881-82 (consecutive years) is allowed in more places, while still not being the preferred form.

I guess, it makes sense to also sense for the same pattern with hyphen (-) rather than endash (–).

I have never seen other forms, but perhaps there are variants with additional pre- or postfix notation. If so, they should be put into this category as well for evaluation. At present (before the proposed MOS change) this should not be flagged as error, as it is just for tracking.

--Matthiaspaul (talk) 16:08, 9 August 2020 (UTC)

Title, 1881–86 (invalid per MOS except where "where space is limited"; accepted by CS1)

Title, 1881–886 {{citation}}: Check date values in: |date= (help) (invalid per MOS, error in CS1)

Title, 1881–6 {{citation}}: Check date values in: |date= (help) (invalid per MOS, error in CS1)

Title, 1881–82 (valid per MOS and accepted by CS1)

Title, 1881–882 {{citation}}: Check date values in: |date= (help) (invalid per MOS, error in CS1)

Title, 1881–2 {{citation}}: Check date values in: |date= (help) (invalid per MOS, error in CS1)

Title, 1881–22 {{citation}}: Check date values in: |date= (help) (invalid per MOS, error in CS1)

I feel like I'm doing your work for you. Does the above list help? Do you propose that CS1 mark the first case, "1881–86", as an error? All of the other cases appear to be processed correctly per MOS. – Jonesey95 (talk) 17:08, 9 August 2020 (UTC)

I think this is going in the wrong direction. The readers still would not know what the abbreviated date is meant to represent and not know that we disallow abbreviated years. We should be making it clear what we are using and disallow both yyyy-mm & yyyy-yy in citations. Keith D (talk) 19:01, 9 August 2020 (UTC)

Both of those formats are already flagged:

Title, 2001-02 {{citation}}: Check date values in: |date= (help) (error in CS1)

Title, 2020–21{{citation}}: CS1 maint: date format (link) (maintenance message in CS1)

Again, what is the exact proposal here? If the proposal is to change MOS, that should happen at a MOS talk page. – Jonesey95 (talk) 19:20, 9 August 2020 (UTC)

Jonesey, it is extremely hot over here, and possibly also where you live, but still I think I have been quite clear about that. The request, at this stage, is to put citations which contain abbreviated year ranges in the |date= parameter into a dedicated maintenance category for further evaluation. The request is not to check the current implementation to be in sync and to be compliant with the MOS, nor is it to throw any additional error messages. The question I hope to be able to answer is the extent to which such abbreviated year ranges are used in citations at present (although I already assume them to be rarely used), and if there is anything special about the articles using such citations.

This is not a request to change the MOS, but this will likely happen (f.e. there) at a later stage pending the outcome of an evaluation of the citations accumulating in the requested maintenance category.

I deliberately remained somewhat vague in regard to the exact search pattern because there might be forms of abbreviated year range notations in the English language I am simply not aware of (as a non-native speaker), and the resulting pattern also depends on (the sequence of) pattern checks already carried out by the current implementation (f.e. your list above gives a good overview, but I found that yy <= 12 are special-cased - there might be more such peculiarities, leading zeros come to my mind).

At the risk of missing some special forms, something similar to yyyy[–|-]yy would probably catch most already (based on some tests with "insource:/| *date *= *[0-9]{3,4} *[-–] *[0-9]{1,2} *[|}]/" as a search pattern, which, however, times out, therefore does not give accurate figures). At this stage, this does not need to be 100% exact math, although someone reading my intentions for this request above and being familiar with the actual implementation would probably be able to nail it down with precision right from the start.

--Matthiaspaul (talk) 20:34, 9 August 2020 (UTC)

Forgot to mention year ranges in the |publication-date= and |year= parameters in addition to those in |date=.

--Matthiaspaul (talk) 16:31, 21 August 2020 (UTC)

See also: Help_talk:Citation_Style_1#Support_for_ISO:2019_month_precision --Matthiaspaul (talk) 17:40, 23 August 2020 (UTC)

Abbreviated year ranges in the |date=, |year= or |publication-date= parameter will now be indicated by an optional maint message and put into new category "Category:CS1 maint: abbreviated year range" for further evaluation:

Title. 1922–29.

--Matthiaspaul (talk) 23:43, 19 September 2020 (UTC)

It looks like the code may need refinement.

1. Title. 1881–86. (invalid per MOS except where "where space is limited"; accepted by CS1)
2. Title. 1881–886. {{cite book}}: Check date values in: |date= (help) (invalid per MOS, error in CS1)
3. Title. 1881–6. {{cite book}}: Check date values in: |date= (help) (invalid per MOS, error in CS1)
4. Title. 1881–82. (valid per MOS and accepted by CS1)
5. Title. 1881–882. {{cite book}}: Check date values in: |date= (help) (invalid per MOS, error in CS1)
6. Title. 1881–2. {{cite book}}: Check date values in: |date= (help) (invalid per MOS, error in CS1)
7. Title. 1881–22. {{cite book}}: Check date values in: |date= (help) (invalid per MOS, error in CS1)

Case 4 is incorrectly marked with a maintenance message. Case 7 already fails the date check, so it does not need a maintenance message. – Jonesey95 (talk) 00:09, 20 September 2020 (UTC)

Not really. As I wrote, the purpose of this category is not to check any compliance with MOS, but to collect certain abbreviated year ranges used in a publication-related date parameter (that is, |date=, |year=, and |publication-date=). Your cases 1, 4 and 7 are actually those cases I am looking for, as detailed further above. The behaviour of the existing date validation code was deliberately not changed. --Matthiaspaul (talk) 00:28, 20 September 2020 (UTC)

If maintenance is not required, then maintenance categorization is not appropriate. Better to use a properties category.

—Trappist the monk (talk) 12:41, 20 September 2020 (UTC)

Because maintenance is not required, switched maint cat to properties cat. To accomplish this, moved add_prop_cat() from Module:Citation/CS1/sandbox to Module:Citation/CS1/Utilities/sandbox.

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

According to my evaluation of several dozens of these citations, most of them actually need maintenance. In most cases, people specified assumed year ranges if they didn't know the actual publication year, or specified the span of availability of a source (which is one of the purposes of |orig-date=). In rare cases, the publisher's data actually specified a year range, in those cases mostly for consecutive years.

However, as this kind of maintenance applies to all year ranges, not only the abbreviated ones, I agree, that for the present investigation detailed future above, a tracking category without maintenance message is good enough. In the future, however, we may add a maintenance category for all year ranges, though, so that the above mentioned misuses can be cleaned up - however, this requires actually researching the citations, therefore it is time-consuming work.

--Matthiaspaul (talk) 19:14, 27 September 2020 (UTC)

Replacing ignore-isbn-error= and doi-broken= by isbn/doi=((invalid-value)) syntax

Only a minor point, and even one that would require a few hours work to clean up existing citations, so no priority, but in the long-run attempt to improve the consistency of the parameter interface of the citation templates and, where reasonably possible, reduce the number of parameters by making some of the existing parameters "smarter", I think, the |ignore-isbn-error=true parameter (and its alias |ignoreisbnerror=true) would be a good candidate to be replaced by adding support for the double-parentheses-syntax to ((accept this value as it is)) in the |isbn= parameter.

For a long while, when I occasionally ran into "valid invalid" ISBNs, it always took me quite some time to look up the exact parameter name to disable the ISBN validation check because |ignore-isbn-error=true was almost undocumented (meanwhile it can be found listed nearby the documentation for |isbn=, so is easy to find). Things would have been easier, if the template would have supported the ((syntax)) instead of using a separate parameter for this. While this syntax is a bit cumbersome in itself (it needs to be), once you learn about it and have realized that this is a generic escape method used in various places to let the template accept parameter values it otherwise would not for some (normally but not in this particular case valid) reason, it becomes only natural to also try it when running into invalid |isbn= values - only to find out that it is not supported there.

So, for consistency, it should be supported there as well, and the |ignore-isbn-error= parameter be deprecated after existing citations have been adjusted accordingly (possibly by a bot).

(There are other cases, where the ((syntax)) should be supported as well (but still isn't), f.e. we recently had a discussion about quarters in |date=, where it was recommended as a breakout as well, see Help talk:Citation Style 1/Archive 68#Needs exception for unusual-format dates (2). The idea there was ((to reluctantly accept the input)) to not frustrate and block the editor in his/her endeavour to improve the encyclopedia, but to put such escaped forms into a maintenance category for evaluation in order to detect missing template functionality and for possibly necessary post-processing.)

--Matthiaspaul (talk) 10:30, 10 August 2020 (UTC)

Followup: |doi-broken=/|doi-broken-date=/|doi-inactive-date= would be other candidates. While these and the |ignore-isbn-error= parameter are reasonably named as is, they don't follow some overarching naming scheme and therefore are difficult to remember (and, as a consequence, need to be looked up whenever needed). It would be much more consistent and easier to remember if |doi= would accept the ((syntax)) as well for such invalid DOIs.

--Matthiaspaul (talk) 10:39, 10 August 2020 (UTC)

• Weak support. Sounds reasonable, though it should definitely be low on the priority list. Glades12 (talk) 18:06, 6 September 2020 (UTC)

The template now supports both methods to indicate invalid ISBNs. The oddball parameter |ignore-isbn-error= has been set to "deprecated", and the remaining < 300 uses ([1]) can be easily switched to use the ((accept-this-as-is)) syntax manually as soon as the template goes live, so that support for that parameter can be disabled in the subsequent update.

• {{cite book/new |title=Title |author=Author |isbn=0-7506-4588-2}} → Author. Title. ISBN 0-7506-4588-2. {{cite book}}: |author= has generic name (help); Check |isbn= value: checksum (help)
• {{cite book/new |title=Title |author=Author |isbn=0-7506-4588-2 |ignore-isbn-error=yes}} → Author. Title. ISBN 0-7506-4588-2. {{cite book}}: |author= has generic name (help); Check |isbn= value: checksum (help); Unknown parameter |ignore-isbn-error= ignored (|isbn= suggested) (help)
• {{cite book/new |title=Title |author=Author |isbn=((0-7506-4588-2))}} → Author. Title. ISBN 0-7506-4588-2. {{cite book}}: |author= has generic name (help)CS1 maint: ignored ISBN errors (link)

--Matthiaspaul (talk) 15:59, 19 September 2020 (UTC)

Same support now for to-be-ignored ISSN/EISSN errors:

• {{cite journal/new |title=Title |author=Author |journal=Journal |issn=0028-0836}} → Author. Title. ISSN 0028-0836. {{cite book}}: |author= has generic name (help); |journal= ignored (help) (valid ISSN)
• {{cite journal/new |title=Title |author=Author |journal=Journal |issn=1028-0836}} → Author. Title. ISSN 1028-0836. {{cite book}}: |author= has generic name (help); |journal= ignored (help); Check |issn= value (help) (invalid ISSN)
• {{cite journal/new |title=Title |author=Author |journal=Journal |issn=((1028-0836))}} → Author. Title. ISSN 1028-0836. {{cite book}}: |author= has generic name (help); |journal= ignored (help)CS1 maint: ignored ISSN errors (link) (ignored invalid ISSN)

--Matthiaspaul (talk) 22:03, 22 September 2020 (UTC)

I have created has_accept_as_written() in Module:Citation/CS1/Utilities/sandbox and used it in Module:Citation/CS1/Identifiers/sandbox to replace v, count_accept = v:gsub ('^%(%((.*)%)%)$', '%1');.

This new function also replaces similar code in Module:Citation/CS1/sandbox.

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

Deprecating some unused parameter aliases

Further researching possible options for my proposal to streamline override options for ISBN and DOI error handling, I was going through the list of currently supported parameter aliases and I found that |ignoreisbnerror= is actually unused. Given that, according to this thread, we don't want to introduce new non-hyphenated parameter aliases any more and keep the existing non-hyphenated variants only for legacy support, I don't think it makes any sense to keep support for non-hyphenated parameter aliases if they are unused, in particular if they belong to such rarely used features. Therefore, I want to deprecate the |ignoreisbnerror= alias.

Likewise, I was curious about the usage statistics of the many aliases parameter names for a small feature such as the DOI error override and found |doi-inactive-date= to be used only as an empty parameter, apparently from copying empty templates into articles - meanwhile removed. Astonishingly, there were also a few live occurences of empty template parameters |doi-inactive=/|doiinactive=/|doibroken=, although these are not supported as actual parameters by the templates (perhaps they were in the past and have never been cleaned up - done now).

There were three occurences of |doi-broken= actually being used, which I switched to use |doi-broken-date= instead, so that we are free to fade out |doi-broken= as well.

Removing support for these aliases we'd end up with the two canonical parameter forms |ignore-isbn-error= and |doi-broken-date= only.

--Matthiaspaul (talk) 14:51, 6 September 2020 (UTC)

|ignore-isbn-error= and |ignoreisbnerror= are not new but were simultaneously introduced in April 2013 (this edit) – that was before the RfC that established our preference for hyphenated parameter names. Still, I, for one, do not object to deprecation and removal of little-used non-hyphenated parameter names.

I think that |doi-broken= should be deprecated and removed because that parameter requires a date so its name should declare that. In the sandbox I have made |doi-broken-date= the canonical parameter name. Similarly, |embargo= should be deprecated and replaced with |embargo-date=.

—Trappist the monk (talk) 17:54, 6 September 2020 (UTC)

Thanks for looking up the link to that old RfC.

There were only 14 occurences of |embargo= in use, and in all of these cases the parameter value was empty - therefore I cleaned them up. I support the switch to |embargo-date= or even better |pmc-embargo-date= given that the parameter applies only to PMCs.

So, we deprecate |ignoreisbnerror=, |doi-broken=, |embargo=, and ... ? You didn't mention |doi-inactive-date=, which I think we can deprecate as well - it's not used. I don't see a reason why we would need to support |doi-broken-date= and |doi-inactive-date= in parallel, or are these two different use cases which might need to be distinguished in the future?

In either case, is it important to document the fail-date of a DOI in a citation at all? I'm asking, because, if it is not, we could streamline the parameter name even more by changing it to |doi-status=dead or even eliminate it completely by using our special syntax as in |doi=((invalid-number)).

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

• {{cite book/new |title=Title |author=Author |isbn=0-7506-4588-2 |ignore-isbn-error=yes |doi=10.1007/978-3-642-86187 |doi-broken-date=2020-08-30 |pmc=7135076 |pmc-embargo-date=2020-12-31}} → Author. Title. doi:10.1007/978-3-642-86187 (inactive 2020-08-30). ISBN 0-7506-4588-2. PMC 7135076. {{cite book}}: |author= has generic name (help); Check |isbn= value: checksum (help); Unknown parameter |ignore-isbn-error= ignored (|isbn= suggested) (help)CS1 maint: DOI inactive as of August 2020 (link) CS1 maint: PMC embargo expired (link)

--Matthiaspaul (talk) 12:57, 10 September 2020 (UTC)

Further, following your reasoning with regard to |doi-broken= (3× uses that you changed to |doi-broken-date= so we are free to fade out |doi-broken=) I have removed |chapter-doi= and |title-doi= as unused and unsupported from ~/Configuration/sandbox, ~/Whitelist/sandbox, ~/Suggestions/sandbox. Did I miss any? If / when there is support for these parameters, that is the time to introduce them; we should not speculatively add parameters.

—Trappist the monk (talk) 18:16, 6 September 2020 (UTC)

See also Help_talk:Citation_Style_1#Auto-linking_for_book_chapters

--Matthiaspaul (talk) 16:32, 10 September 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)

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

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

Please use consistent ordering in examples

Half the examples for {{Cite press release}} put date=... near the beginning and half at the end. I know order doesn't matter, but the inconsistency hurts comprehension. Thanks y'all! -- Skierpage (talk) 23:21, 7 September 2020 (UTC)

If you see where improvements can be made in the cs1|2 documentation, please improve it.

—Trappist the monk (talk) 00:25, 8 September 2020 (UTC)

While it may be difficult to come up with one order suiting all cases, I'm sure most editors have some kind of default order and reoccuring patterns they use at least when editing citations manually. I can see three major sorting criteria:

• Semantically (descending order based on importance of entry in identifying a specific citation)
• Convenient ("chronological" order of appearance when writing down and subsequently completing a citation, f.e. with url= before title= in cite web)
• Alphabetically (ascending order, only useful in documentation)

FWIW, I typically try to use a semantical order similar to the following, but deviate from it when editing existing citations:

• control parameters (ref, mode)
• title-/chapter-related parameters (title, script-title, trans-title, title-link, chapter, script-chapter, trans-chapter, chapter-link)
• author-/editor-related parameters (author list, editor list, contributor list, translator list, each entry ordered first, last, link, optionally name-list-format, *-mask, display-*)
• publication-date-related parameters (publication-date, date, orig-date)
• version-related parameters (edition, version)
• venue-related parameters (magazine/journal/conference, series/work, volume, issue/number)
• page-related parameters (page, pages, at, optionally nopp)
• publisher-related parameters (publisher, via)
• location-related parameters (publication-place, location)
• identifier-related parameters (with issn and isbn first and id last in the list)
• url-related parameters (url, url-access, chapter-url, chapter-url-access, access-date, url-status, archive-url, archive-date)
• quote
• postscript

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

A somewhat related thread:

Help_talk:Citation_Style_1#Potential_conflict_between_"Cite_web"_documentation_and_ProveIt? --Matthiaspaul (talk) 16:47, 24 September 2020 (UTC)

Invalid parameters ignored when empty

Hi, invalid template parameters throw an error message (and optionally a hint) when they contain a value, but are ignored when empty.

While it is okay to leave (some) empty parameters in a citation in order to point editors to missing information, I think, unrecognized parameter names should always generate an error, regardless if they contain a value or not. --Matthiaspaul (talk) 09:24, 9 September 2020 (UTC)

Probably more trouble than is worth. It is clear that unknown parameters are ignored, and any editor would probably realize something is wrong when the input doesn't display. The coding routines to implement this may not be simple and would have to be amended any time there is any change in the "legal" parameters. 65.88.88.57 (talk) 12:51, 9 September 2020 (UTC)

Actually, very simple, and the code already uses Module:Citation/CS1/Whitelist as a reference; any parameter name not in the whitelists is an unknown parameter. At present there is an if statement that looks for a parameter value. When the parameter value is an empty string, the code goes on to the next parameter in the template. For unknown parameters without assigned values, we simply follow the currently non-existent else where we do a quick check to see if the parameter name is in the whitelist; ignore when it is, error message when it isn't.

No changes to the code required when the whitelist is updated. This same mechanism will also catch empty deprecated parameters.

—Trappist the monk (talk) 13:24, 9 September 2020 (UTC)

We could do this. Were we to do it, I think that we should limit the checking to the basics. Is this a known and properly formed parameter? No checking the suggestion list. I don't know how to predict how many of these kind of parameters exist in the wild so we could be in for torches and pitchforks if we do this with message-display enabled. Separate category and error message from Category:Pages with citations using unsupported parameters (which category needs renaming) so that we don't turn off error messaging for unknown-parameters-with-values. Once the majority of the unknown-parameters-without-values errors are remedied, we can combine the two categories and unify the error messaging.

The inclusion of empty parameters is, I think, pointless and just makes cs1|2 templates harder to read, clutters the wikitext so that the article text is harder to read in edit mode, and, in my experience, these empty parameters rarely get filled by subsequent editors. Just as bad is the inclusion of meaningless parameters with values – the abomination that is ve adds |url-status=live when it adds empty |archive-url= and |archive-date=. I would be in favor of including |url-status= without |archive-url= () as one of those errors that populate Category:Pages with archiveurl citation errors (another category that needs a name change).

—Trappist the monk (talk) 13:24, 9 September 2020 (UTC)

Regarding unknown parameters (with or without values), sounds good to me.

Regarding known parameters with empty values, however, I differentiate between two cases:

• Cleaning up some of the alias parameters recently, I ran into cases like this one ([2]), where empty template prototypes were copied into an article but never filled out, amounting to 2 KB of needless clutter in the given example. This obviously needs to be cleaned up and I don't object even when bots do it.
• On the other hand, I often leave (for myself and other future editors) a couple of empty parameters in a citation pointing to specific missing info that I expect to be included in a complete citation but was unable to provide at the time I carried out the edit. In many of these cases, I will fill out these parameters at a later stage after further researching a topic (but this may take up to months, sometimes even years). I get quite upset if someone (typically drive-by editors) comes around and deletes those empty parameters, because it makes it more difficult for me to further improve such citations. It's like throwing sand in the gear.

The difference between these two cases is that the first case is about a large number of empty parameters left in a citation more or less mindlessly, and in the second case a few empty parameters left in a citation deliberately (and most likely only temporarily until the citation is complete).

If I had to program a bot rule for this, incorporating a threshold might allow to detect and eliminate the majority of instances of the first type while leaving most of the second type intact:

"If there are more than about five empty parameters in a citation, it is likely that someone just copied a template prototype, if there are fewer, the parameters were likely deliberately left by editors as hints for further research."

(A possible way to solve this in a way satisfactory for both parties could be to adopt my parameter review proposal also for empty parameters.)

Regarding |url-status=live, I must admit that I typically add this as well when I add |url= and |access-date=. While I normally try to provide |archive-url= and |archive-date= at the same time, sometimes this is not possible because archive.org is down again or refuses to archive a site. In my opinion |url-status= semantically belongs to |url= primarily, only secondarily to |archive-url=. While removing |url-status=live in absence of |archive-url= is debatable (in a citation I favour explicit settings rather than relying on default assumptions, because the former work as kind of documentation and the latter can change over time), I have recently seen a bot (IIRC it was GreenC Bot) removing |url-status=dead in absence of |archive-url= as well - this is annoying and clearly a bot error, because, if a URL goes dead or gets usurped by something else, this is a condition that should be recorded in |url-status=dead even if no |archive-url= is available (and in some cases there may not even be an alternative |url= available). If this would be put into an error category, I can already see some careless editor or bot coming around removing the citation completely (although the document once was available and verified per |access-date=). Therefore, we shouldn't remove |url-status= and don't issue errors on this.

--Matthiaspaul (talk) 18:03, 9 September 2020 (UTC)

Responding to the OP: I would strongly object to the display of any error message to regular editors where unsupported but empty parameters are present. They do no harm. The normal use of Module:Check for unknown parameters in infoboxes and other templates, for example, does not display an error message or a hidden category when unsupported parameters are blank, because they do no harm. I have heard the argument that they are somehow an attractive nuisance, that editors will be tempted to put values in them, but there is little to no evidence that this happens, and if it did happen, the editor would encounter null display of the parameter value, along with an error message and a hidden category. I recommend letting sleeping dogs lie.

All of that said, if someone wanted to program AWB to remove empty, unsupported parameters from CS1 templates as part of AWB's general fixes, I would not object. They should be removed only as part of a substantive edit. – Jonesey95 (talk) 15:46, 9 September 2020 (UTC)

While I personally don't see a problem displaying an error message because the problem should be easy to fix even by unexperienced editors when the error message contains the name of the unsupported parameter, we could start with a preview message or opt-in maintenance message and maintenance category first to see how many of them are around.

--Matthiaspaul (talk) 18:03, 9 September 2020 (UTC)

To be clear, I am taking issue with Matthiaspaul's implication that there is a problem at all. Empty parameters in CS1 templates do not cause any problems. We can safely ignore them. – Jonesey95 (talk) 18:15, 9 September 2020 (UTC)

Thanks for the clarification, I really took your comment as a recommendation to take less drastic measures than to throw an actual error message in the face of normal users.

My request, however, was primarily about unknown parameters (regardless of them being empty or not). I don't think we should ignore them, that's bad interface design (and also bad programming practise). Detecting and removing junk can help to reduce potential sources of confusion and to clean up clutter in badly maintained articles. We already throw an error message if an unknown parameter contains a value, so it would only be consistent to also throw an error message if an unknown parameter does not contain a value.

I could follow your argument in a discussion about how strong we should act on them, that is, if we should throw a hammer in form of an error message (my original proposal), or just give a nice hint in article preview and possibly populate a maintenance message for gnomes to clean them up (my compromise).

But I honestly cannot understand why someone would oppose a cleanup effort for as long as he would not be forced to participate in it. This looks as opposing something for the sake of opposing. While it is always possible that someone does not recognize something as a problem, this is not a good reason to oppose actions to remove problems seen by others for as long as such effort does not negatively get into his way. Do you see a use case for leaving unsupported parameters in citations? Do they carry some value for you?

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

When the tiny community of editors at this page makes a change that affects millions of CS1 template transclusions, thousands of editors who normally do not care about, or barely tolerate, CS1 templates and their complexity will see that change. If that change appears to those editors to be pointless, those editors form a negative opinion of the community that maintains those widely used templates, and they are less likely to support proposed changes that actually improve the quality of Wikipedia. All of that means that we need to be judicious about implementing change. – Jonesey95 (talk) 21:51, 9 September 2020 (UTC)

Indeed. Not signaling empty (optional) parameters is the norm in the Wikipedia platform. Required parameters are already properly addressed in cs1/2. Informational messages about unknown parameters are harmless and as stated above by Trappist apparently easily implemented. 172.254.241.58 (talk) 12:15, 10 September 2020 (UTC)

I've hacked the sandbox to emit an error message when cs1|2 encounters an unknown parameter that doesn't have an assigned value. Right now it uses the same error messaging as an unknown parameter with an assigned value. If we retain this change, perhaps a better category and message is appropriate. Also finds empty deprecated parameters. Empty known parameters do not cause an error message:

{{cite book/new |title=Title |blue= |editors= |author=}}

Title. {{cite book}}: Cite has empty unknown parameters: |editors= and |blue= (help)

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

Thank you, Trappist, for demonstrating a proposed change. I object strongly to displaying error messages for empty parameters. I expect that it would cause a storm of trouble among non-technical editors. – Jonesey95 (talk) 15:02, 10 September 2020 (UTC)

In my first two posts on this topic I suggested, perhaps not clearly enough, that because I don't know how to predict how many articles have cs1|2 templates holding empty-unknown-parameters that if we include this detection, any messaging it produces should be hidden until the associated category is emptied sufficiently that enabling display will not cause torches pitchforks drama.

You are right, empty parameters don't cause problems in the sense that nothing technical breaks. cs1|2 doesn't care. MediaWiki doesn't die. Both render perfectly readable articles. But cs1|2 templates in wikitext do impede editors when they are reading and editing wikitext. This is true even when cs1|2 templates use only the parameters and values that they need; retaining unused parameters (known or unknown) compounds effort required for reading and editing. This change does not propose to fix the empty-parameter-clutter problem.

—Trappist the monk (talk) 15:47, 10 September 2020 (UTC)

While I don't think the error message would actually cause a stir up, I don't mind if we make it a maint message first. Looks good to me.

--Matthiaspaul (talk) 12:44, 11 September 2020 (UTC)

I do think old parameters that are blank should be set in a category of some sort though I tend to agree it probably should not be visible. --Izno (talk) 16:14, 10 September 2020 (UTC)

I cannot think of a single instance where the case of optional parameters not being used is signaled to end-users in any programming environment. Any more than telling the user of any form (aka template) that they did not fill in optional fields. The person using the form knows that. If certain fields are consistently not used would be of interest to the form designer only. And then only if the unpopular fields consume resources better utilised elsewhere. 64.18.9.231 (talk) 13:06, 11 September 2020 (UTC)

I have tweaked the test a bit and changed its error message. Instead of independent error messages for each unknown empty parameter, the module now collects a table of unknown empty parameters and then creates a single list in a single error message. Empty deprecated parameters are, for the purposes of this test, treated as unknown because they will become unknown at the end of the deprecation period. Empty positional parameters are not ignored (positional parameters with some sort of value cause the error message). The error message produced by this test is hidden from readers and from all editors who have not opted to see hidden error messages.

{{cite book/new |title=Title |blue= |editors= |author=}}

Title. {{cite book}}: Cite has empty unknown parameters: |editors= and |blue= (help) – |editors= is deprecated so is included in the unknown empties error message

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

Title. {{cite book}}: Unknown parameter |editors= ignored (|editor= suggested) (help) – deprecated parameters that have an assigned value are not treated as unknown

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

Title. {{cite book}}: Cite has empty unknown parameters: |1= and |blue= (help) – extraneous pipe creates empty positional parameter

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

Title. {{cite book}}: Cite has empty unknown parameters: |1= and |blue= (help) – extraneous pipe followed by whitespace is empty but not detected; I'll fix that fixed

—Trappist the monk (talk) 12:07, 12 September 2020 (UTC) 12:54, 12 September 2020 (UTC)

Logic looks good, but I would change the presentation slightly. Unknown parameters are rejected because they are unknown, not because they are "empty'. Some people may wrongly presume an implication. In other news regarding precision, parameters are never "empty". Perhaps they have not been assigned a value. Their data field could be empty though. 65.88.88.69 (talk) 13:14, 12 September 2020 (UTC)

Meh, I don't see the point. Only editors are even as much as annoyed by them (as long as they remain empty). Glades12 (talk) 18:15, 24 September 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 ways 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)

no-cat parameter cleanup

Hi, the CS1 templates support a debug feature to disable categorization. This is currently supported by five parameter aliases, which is overkill for such a rarely used feature:

• |template-doc-demo= [3] 0
• |no-cat= [4] 0 (2 uses in non-citation templates)
• |nocat= >=2 Paleocene Alabama (>15k uses in non-citation templates)
• |no-tracking= [5] 0
• |notracking= [6] 0

In our cleanup effort, I think, we should, in a first step, deprecate the unused parameter names |template-doc-demo=, |no-tracking= and |notracking=, making |no-cat= the canonical name and |nocat= its alias, and - despite the name - put them in (only) a special hidden category to find out how many citation templates actually use this feature. I think, the number will be very low (perhaps a handful, at most a few dozens), but given the fact that the template uses the "generic" parameter name |nocat= and that Cirrus search for this times out, we cannot find out easily.

Once knowing the citation templates using this feature and evaluating the reasons for its use, we might, in a second step, switch the parameter name to something unique (and thus easily searchable) but still more sensibly named than |template-doc-demo=, perhaps |cite-no-cat= (so that it can still be found if someone searches for a "no-cat" parameter), but ideally even something that fits into our naming scheme better: Perhaps it can be merged into |(cite-)mode= or integrated into a new, more general debug parameter like |debug-mode=, also controlling namespaces. This would be something to discuss in the next round.

If we support the ((accept-this-as-it-is)) syntax for more parameters (per Help_talk:Citation_Style_1#i18n_doi_inactive_categories, Help_talk:Citation_Style_1#Replacing_ignore-isbn-error=_and_doi-broken=_by_isbn/doi=((invalid-value))_syntax), we might even be able to eliminate some of the reasons for the feature's (ab)use in mainspace, thus reducing this again to a pure debug parameter.

--Matthiaspaul (talk) 08:56, 13 September 2020 (UTC)

In the Paleocene article above, this citation currently uses |no-tracking= to avoid being put into an "invalid DOI" error category (the DOI is oddly formed with a pending dot, but valid):

• {{cite journal/new |last1=Belcher |first1=C. M. |title=Reigniting the Cretaceous-Palaeogene firestorm debate |journal=Geology |year=2009 |volume=37 |issue=12 |pages=1147–1148 |doi=10.1130/focus122009.1. |no-tracking=yes}} → Belcher, C. M. (2009). "Reigniting the Cretaceous-Palaeogene firestorm debate". Geology. 37 (12): 1147–1148. doi:10.1130/focus122009.1. {{cite journal}}: Check |doi= value (help)

As the |doi= parameter meanwhile supports our ((syntax)) to disable our validation check, this can be achieved without abusing |no-tracking= now:

• {{cite journal/new |last1=Belcher |first1=C. M. |title=Reigniting the Cretaceous-Palaeogene firestorm debate |journal=Geology |year=2009 |volume=37 |issue=12 |pages=1147–1148 |doi=((10.1130/focus122009.1.))}} → Belcher, C. M. (2009). "Reigniting the Cretaceous-Palaeogene firestorm debate". Geology. 37 (12): 1147–1148. doi:10.1130/focus122009.1.{{cite journal}}: CS1 maint: ignored DOI errors (link)

DOI values framed this way will now be put into a special maintenance category so we can try and derive patterns to further improve our DOI validation code.

--Matthiaspaul (talk) 20:02, 19 September 2020 (UTC)

Related links:

* Help_talk:Citation_Style_1/Archive_61#Valid_DOI_ending_in_punctuation

* Help_talk:Citation_Style_1/Archive_62#template-doc-demo_should_be_a_bad_parameter_in_the_mainspace

--Matthiaspaul (talk) 20:29, 20 September 2020 (UTC)

All of those searches are confined to article space. These parameters are mostly used outside of article space, often to suppress error categorization when template errors occur in discussions and in template docs where showing the error messaging is undesirable. Some sort of special case code will be required to categorize the use of these parameters.

—Trappist the monk (talk) 11:36, 13 September 2020 (UTC)

See also recent discussion. --Izno (talk) 12:33, 13 September 2020 (UTC)

In all spaces (I'm not going to try for nocat given all the overlap):

• 77 template-doc-demo
• 38 no-cat
• 475 no-tracking
• 17 notracking

I would probably support removal of no-cat/nocat regardless of counts or the above-linked discussion given the overlap with other templates making it hard to find instances, and probably also notracking given the few uses. Whether we should remove no-tracking would probably be dependent on the purpose of this parameter in mainspace. --Izno (talk) 14:36, 13 September 2020 (UTC)

Good point, the uses outside mainspace can't be ignored here. Given the numbers I think we should proceed by trying to find out why the parameter was used in mainspace. However, to find all occurences we might need to temporarily introduce a special "uses nocat" category.

--Matthiaspaul (talk) 20:02, 19 September 2020 (UTC)

The usage numbers of the aliases |notracking= and |no-cat= have been brought down to zero (switching them to |no-tracking= for now, the most sensibly named one of the remaining aliases. Support for these parameter variants was disabled, and |no-tracking= is now the canonical form.

In order to sort out the |nocat= nightmare, we need a temporary tracking category. I would appreciate if Trappist could take care of this, as the code for this is a bit tricky and he is already familiar with it. I think it is important to have this in the forthcoming template update, so that we don't lose too much time until the next round.

Regarding |no-tracking=, at least the name is unique, but otherwise it's far from perfect. The jury is still open to find a parameter name better fitting into our parameter naming scheme...

--Matthiaspaul (talk) 20:29, 22 September 2020 (UTC)

You want this maint cat for |nocat= only? So:

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

{{cite book/new |title=Title |no-tracking=true}} → Title.

—Trappist the monk (talk) 23:27, 22 September 2020 (UTC)

Thanks, that was straight-forward. :-) Somehow, I had expected something more complicated...

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

Okay, |template-doc-demo= has been eliminated as well now.

The following two pages are protected and therefore need to be updated by an admin:

• Wikipedia:List_of_hoaxes_on_Wikipedia/Richard_Hopkins_(chess_player)
• User:Jonesey95/AutoEd/unnamed.js

I found that some secondary templates still use the former |template doc demo= parameter. They have been updated to accept |no-tracking= as well now, but the following 80 occurences should be fixed up as well: insource:/\| *template +doc +demo *=/ [7].

NB. One citation-related template using |nocat= is {{Citation error}}.

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

Matthias, you need to go slower or get opinions about some of your changes first. I don't agree to deprecating/removing template-doc-demo as I believe that should be the sole-purpose of the parameter (and which no-tracking and variants do not communicate). See the discussion I linked above. Reverted all of those changes. --Izno (talk) 23:16, 23 September 2020 (UTC)

Huh? I think I was quite clear right from the start (11 days ago) that |template-doc-demo= and its aliases should be cleaned up and replaced by something with a more sensible name and possibly modified functionality. |template-doc-demo= is about the most nightmarish parameter name I can think of. Although |no-tracking= does not fit well into our parameter naming scheme either, it is a much more user-compatible parameter name. In the long run we should be able to come up with a better name, anyway.

So far, I have not found another use in article space. Once we have sorted and cleaned up the |nocat= stuff after the next update, we should ask us the following questions:

• 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 serve as a search pattern.

--Matthiaspaul (talk) 01:11, 24 September 2020 (UTC)

My point is that these questions should be answered before we remove the parameter name that indicates it should not be used in mainspace. :^) Removing it was a cart before the horse thing. What's your answer to the questions, to get that started? --Izno (talk) 02:12, 24 September 2020 (UTC)

Guidance about indexing by first name?

Is there any guidance about how to handle instances where authors should be indexed by first rather than last name? E.g. Chinese names where family name comes first, or Thai names where given name (which comes first) is the polite term of address? For example, should I call a Thai given name "last=" so the correct name comes first, as you would see in an index? Calliopejen1 (talk) 17:00, 17 September 2020 (UTC)

If you are uncomfortable using first/last in such cases, you may use |given= and |surname=. --Izno (talk) 17:50, 17 September 2020 (UTC)

What do you mean by indexed?

Whatever name you give |last= or |surname= will appear first in the rendered citation. |first= or |given= is always follows and is separated from |last= or |surname= with a comma and a space character. The only way to get cs1|2 to render a person's names in a particular order with particular punctuation is to do it manually with |author=. This same applies to the other name lists (contributor names, editor names, interviewer names, translator names). But none of this has anything to do with indexing.

What do you mean by indexed?

—Trappist the monk (talk) 18:00, 17 September 2020 (UTC)

I assume that an author name in a citation should be rendered in the way it would be listed in an index, which is what I'm referring to. There are plenty of external guidelines about this, e.g. Chicago Manual of Style 16.76-16.87. Thai names should appear in an index by first/given name. To respond to Izno, simply using given/surname doesn't work for Thai names because the given name is what they should be referred to by, though it comes first. I suppose I could just do author=, but then I would need to add ref={{harvid|first|year}} because short-form citations (which should use only the given name) wouldn't work properly. Calliopejen1 (talk) 18:10, 17 September 2020 (UTC)

Before electronic indexing this was important. Indeed, citation element order followed the indexing in printed reference works. The primary index often being published main-author-name with publish-date being a secondary index. Today though such reference works are electronic databases with flexible options regarding indexing and sub-indexing (the present discussion). Which makes the positioning of citation elements more of a presentation issue. There is however an existing guideline: present the author name the way you saw it published. Presumably, that would be the easiest way to find it. The parameter |author= fits the bill. 65.88.88.69 (talk) 18:38, 17 September 2020 (UTC)

I agree that it is a presentation issue, but I don't think that presentation is unimportant. For example, I wouldn't want us to be using the wrong part of the name in short-form citations because {{harvnb}} links to "last"/"surname" by default. That would as akin to doing a short-form citation with "Melissa" or "Jennifer" (i.e. inappropriate). And highlighting the wrong portion of the name through inversion is also odd, as is alphabetizing a work in the wrong place in a works cited list. I do think that "author" combined with ref= is probably the way to go. I'm not sure if any other cultures have this particular issue that can't be sorted out by doing given/surname. Possible it's unique to Thai names.... Calliopejen1 (talk) 18:48, 17 September 2020 (UTC)

...existing guideline: present the author name the way you saw it published. Is there? Where?

—Trappist the monk (talk) 18:46, 17 September 2020 (UTC)

It is in the same page where it is said that titles should render as published. We are not allowed to be creative with most citation elements if we want verification to be as easy ss possible. There are presentation options with dates for example (within the given dating system). But when one is trying to present a date in a foreign system, it is better to do so verbatim. 65.88.88.69 (talk) 19:23, 17 September 2020 (UTC)

What page is this, out of curiosity? Also interested in the dating issue -- should we be giving Thai solar calendar dates for Thai sources? That seems pretty unhelpful to readers, who may want to know at a glance what year a work was published (i.e. is it an up-to-date source or not?). I checked two Thai works on Worldcat, and one had no date, while another had a Gregorian date. I assume the dates in Thai library catalogs are the usual Thai solar calendar dates though... Calliopejen1 (talk) 19:34, 17 September 2020 (UTC)

I was referring to the general guidelines re: verification. It was not my intent to be mysterious or snarky, and hopefully it will not be seen so. The question the way I understand it, is how to present foreign terms to an English-speaking audience for purposes of verification. Doesn't this answer itself? The technicalities of implementation (the parameter "author", custom short reference anchors etc) will then present themselves in the discussion. 65.88.88.69 (talk) 20:00, 17 September 2020 (UTC)

I don't have access to the on-line CMOS but a cursory look-through of this copy of "Indexes" 15th edition (different chapter number but apparently same title) seems to indicate that "Indexes" is about indexes, not about citation style. But, yeah, if the affect you are wanting to achieve is given name followed by surname and linkable from a short-form template, then |author=<given> <surname> and |ref={{sfnref|<given>|<year>}} will do that. You might want to leave <!--<hidden comments>--> so that editors who visit the article after you have finished with it know your intent.

—Trappist the monk (talk) 18:46, 17 September 2020 (UTC)

I agree it is about indexes. But where we have works cited lists, I assume we want them alphabetized in the same way/order they would appear in an index, no? Isn't that implicit in our inversion of first/last names? Calliopejen1 (talk) 18:49, 17 September 2020 (UTC)

Yeah, generally, per WP:CITE we sort by surname – that guideline seems to be mute on the topic of non-western name order. But, this is Wikipedia; I have seen (western) given-name-first reference lists sorted by surname. Why would anyone do that? I don't know, but, as long as it is consistent in the article, WP:CITEVAR protects that style.

The topic of non-western-name-order comes up here periodically. We just haven't determined how-best to deal with it. It is complicated because transliterations of Chinese and Japanese names are apparently not reversible – it is possible to transliterate a to Latin script but not possible to transliterate back to the original – so 'properly' supporting these kinds of names is more than just rendering the transliterated names without the inversion indicator (comma).

—Trappist the monk (talk) 19:15, 17 September 2020 (UTC)

See also: Help_talk:Citation_Style_1/Archive_64#Citing_native_scripts_of_the_author's_name_and/or_title_of_a_work_in_Citation_Style_1

--Matthiaspaul (talk) 04:14, 22 September 2020 (UTC)

(edit-conflict) I would also advise to use the |given= and |surname= parameter variants rather than the |first= and |last= ones. While the order of display for names is "last, first" or "surname, given" at present, this does not necessarily remain so forever. Our style guide may change or we may introduce an |af= ('author format') parameter (as suggested by Headbomb) in the future to control the display order. (See also: Help_talk:Citation_Style_1#First/last_or_given/surname_canonical_form?)

What is important for semantical reasons is that the part of the name that fits into the concept of a family/group name belongs into |surname= (or |last=) and the part of the name that fits into the concept of an individual name into the |given= (or |first=) parameter variant, regardless of their order of display in citations. I think, this is also important for proper meta-data creation.

If, by applying this rule, the current display order or interpunctuation does not look correct for some reason, the display can be overridden using the corresponding -mask parameter variant (like |author-given=Given |author-surname=Surname |author-mask=Given Surname or |author-mask=Surname Given). This is more complicated than just using |author=, but better (at least for as long as the concept of a family and an individual name applies - not sure if this holds true everywhere on this planet).

Now, the anchor is derived from what's in the |surname= or |author= parameter. If it is true that, in the case of Thai names, it should better be derived from what's in the |given= parameter, it might be worth considering a new option like |ref=thai (or |ref=given) for this. (Or, if this should still run under the |ref=harv moniker, a new parameter like |ref-mask=given could be used for this, or this could be even be combined with the proposed |af= into something like |name-mode=Western/Eastern/Chinese/Japanese/Thai/Malay/Indian/Indian-surname/Icelandic/Hungarian/... to control the name display order and style as well as Harvard ref-ID composition and proper meta-data creation by a single parameter.)

--Matthiaspaul (talk) 19:36, 17 September 2020 (UTC) (updated 18:25, 24 September 2020 (UTC))

I may be missing something here. When "indexing" is mentioned, I understand it to mean bibliographic/citation reference indexing. As mentioned earlier, nowadays such databases can be searched via several indices, including combinations. So discovering a work with a "foreign" author name is much easier. But it seems that this is about how such works are indexed in "internal" Wikipedia lists, a presentation issue. I believe they should follow the published rendition. As stated above regarding {{harv}} a custom anchor could work in these cases. 65.88.88.69 (talk) 19:49, 17 September 2020 (UTC)

(edit conflict) Yeah, it's true that a custom anchor can be created manually using {{harvid}} (and is the way to do it now), but assembling an anchor this way is a bit like "open-heart-surgery". (Ideally, the whole information about how CITEREF anchors look like should be "internal" to template editors and no normal editor should have any need to deal with it, so that the implementation could be changed whenever a need would arise for this.)

If, however, this "given name thing" is a general concept for Thai names (I don't know), it would be worth to capsule the assembly of these anchors away from the user and invoke the creation of suitable anchors by some kind of citation template option. This way, the given name and date would not have to be repeated as arguments for {{harvid}}, following the idea of having to provide one piece of information only once for traceability, to ease its maintenance, and also to save some storage space. (In my example above this principle isn't followed for the |author-mask= parameter as well, but this is another possible "shortcoming" of the current implementation, whereas in a hypothetical future version it might be possible to have the template create a suitable display mask automatically if it knows it's a Thai name (this proposal goes in this direction, although related to display styles not naming conventions in general). However, the problem is that on a global scale there are many different naming conventions and once we enhance the current implementation we should ideally find a solution that works good for all of them. Therefore, we are still in learning mode tinkering about possible solutions whenever such a topic comes up.)

--Matthiaspaul (talk) 20:24, 17 September 2020 (UTC)

@Matthiaspaul: One semi-related note in case in case the template's handling of these sorts of things comes up again in the future... My understanding is that Cambodian names are first=surname, last=given name, but the proper mode of address (or anchor) is given name. Right now it's fine just to use first/last for these. (That's what I did, after giving it some thought, in Ratanakiri Province. But it's another instance where given is the proper term of address, but it falls in a different place in the name. You recommend doing given/surname variants, but that wouldn't work for Cambodian names unless you're also going to do author-mask and a custom anchor. Calliopejen1 (talk) 20:09, 17 September 2020 (UTC)

Thanks, this sort of info is always useful. Another example are Hungarian names. Eastern name order has a bit on this, but unfortunately does not name Thai names specifically. --Matthiaspaul (talk) 16:21, 19 September 2020 (UTC)

But we have Thai names... --Matthiaspaul (talk) 16:24, 19 September 2020 (UTC)

@Matthiaspaul: The thing is that Thai names don't use Eastern name order. They use Western name order, but the polite way to address someone is by their first name (i.e. given name). Calliopejen1 (talk) 04:47, 22 September 2020 (UTC)

BTW I assume the reason Thai names are how they are is that Thai people didn't use family names until relatively recently, and the family-name initiative was a reform to "modernize" Thai names. Perhaps the Western way of doing things was viewed as more "modern" at the time (?). This also may be why last names as a term of address didn't really catch on... Calliopejen1 (talk) 04:52, 22 September 2020 (UTC)

Providing an option to switch the composition of reference anchors from "last" to "first" (or other schemes, if necessary for some locales) would be very easy. Above, I suggested to add something like |ref=thai for this purpose or combine this into something like a |name-mode= parameter, which would allow us to select from a number of predefined combinations of display order and anchor composition styles.

However, meanwhile it occured to me that a work may have more than one author and that different settings may be necessary for different authors, if, for example, an English, a Thai, a Hungarian, an Icelandic and a Chinese author collaborated.

In order to enter the names in their various forms (native script, transliterated and/or translated) we need the generic parameter prefixes |script-= and |trans-= to be available as prefixes to name parameters (this has been requested many times already, we "just" need to implement it somewhen). This will ensure that the information can be provided accurately on a technical level.

Likewise, for reliable data entry on a semantical level, editors would choose from the parameter postfixes |-first=/|-last=/|-given=/|-family=/|-forename=/|-surname= the (one or) two that most accurately agree with the naming scheme present in an author's name. (This thread (Help_talk:Citation_Style_1#First/last_or_given/surname_canonical_form?) has a bit on selecting the most suitable postfixes during data entry.)

In this thread (Help_talk:Citation_Style_1/Archive_67#Possible_improved_treatment_of_title_parameters_and_language_attributes), I proposed how the scheme of language prefixes of the |script-= parameters could be expanded from only supporting a number of non-Latin scripts to all language codes without introducing any backward-compatibility problems. We could then use these language prefixes to control, (like that hypothetical |name-mode= parameter above, but) on a name-by-name basis, the various settings needed to display the name correctly (display order and possibly necessary text decoration), to generate the correct meta-data for it, and to derive the name parts for an anchor in Harvard style from it.

The current assignment of first=given=forename and last=family=surname would continue to hold true by default (also for backward compatibility with names provided without |script-=). However, if a name would be entered with f.e. the language prefix zh indicating a Chinese name, the internal assignments would become last=given and first=family, so that |script-author-given=zh:Given and|script-author-surname=zh:Surname would work just as well as |script-author-last=zh:Given and |script-author-first=zh:Surname and be rendered as "Surname Given" (no comma) (whereas the conventional |author-given=Given and|author-surname=Surname or |author-last=Surname and |author-first=Given would be rendered as "Surname, Given").

These settings could be implemented as properties in a table of language codes. Also, now, that the non-hyphenated name parameter forms will soon be gone, the code could take advantage of the symmetries in the parameter naming scheme to fold the name parameters into one "[prefix-][name[#]][-postfix[#]]" form (where name would be author/editor/contributor/translator/subject/interviewer). This would reduce redundancies in the code and avoid an endlessly long parameter whitelist.

I think, this extensible scheme would allow us to enter any kind of name in a semantically and technically correct way and process the data according to the rules necessary to be obeyed for each individual name for proper output on all ends.

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

Guidance on title-linking: update after RfC

The RfC on title-linking was concluded yesterday. A related WP:AN discussion is still open. I'd like to prepare updates that will be necessary to Template:Citation Style documentation, including its id2 subtemplate, to make it conform to the outcome of the RfC. Thoughts? Or is it best to wait until the AN thread is closed? --Francis Schonken (talk) 13:25, 20 September 2020 (UTC)

It's not clear that the RfC affects any of the existing guidelines, on which the template documentation is based. What makes you think it does? Nemo 13:50, 20 September 2020 (UTC)

As the closer of the RfC, I don't think it requires any change to the templates either. That certainly did not seem to be the desire that I can find of any consensus or even substantial minority of people. But perhaps there are second or third order technical effects that I am not aware of. Best, Barkeep49 (talk) 15:18, 20 September 2020 (UTC)

@Barkeep49: Template:Citation Style documentation/id2 currently contains:

When an URL is equivalent to the link produced by the corresponding identifier (such as a DOI), don't add it to any URL parameter but use the appropriate identifier parameter, ...

(my emphasis). The RfC close contains:

There is consensus against removing a parameter just because it is a duplicate.

Rationale given in the id2 documentation:

1. The appropriate identifier parameter ... is more stable
2. The appropriate identifier parameter ... may allow to specify the access status
3. The |url= parameter or title link can then be used for its prime purpose of providing a convenience link to a free-to-read copy of the source that would not otherwise be obviously accessible
4. (in a footnote:) This guidance does not restrict linking to websites that are being used as sources to provide content in articles.

In the RfC close the perspective is broader: "... there is an agreement that sometimes removing duplicates can be appropriate. This decision should be made on an article by article basis, unless it is a copyright violation for which there is consensus to remove. Questions that can help guide a discussion include:

1. Does the functional impact, as currently experienced by readers, of the parameter exactly duplicate another parameter?
2. Does including a duplicate link help to establish intent of the person adding the citation by helping them to say where they got it or otherwise enhance verifiability in some way?
3. Is the parameter free or behind a paywall?
4. Is the link dead? If yes does it make sense to rename it to a different parameter in keeping with question 2?
5. What will best respect WP:CITEVAR?"

I think it best to improve the template documentation along the lines proposed in the RfC close. --Francis Schonken (talk) 16:01, 20 September 2020 (UTC)

Francis Schonken, hmm. I see your point. I leave it to you and other editors of this page to decide on what actions, if any, are needed here as per our standard advice. Best, Barkeep49 (talk) 16:05, 20 September 2020 (UTC)

Regarding this particular "id2" part of the template documentation, I see three problematic statements in there. All of them were introduced by "Nemo bis" about a year ago ([8]) who reverted ([9][10]) my attempts to correct ([11] [12]) the misleading statements twice:

• The term "equivalent" in "When an URL is equivalent to the link produced by the corresponding identifier (such as a DOI), don't add it to any URL parameter but use the appropriate identifier parameter, which is more stable and may allow to specify the access status". Terms like "equivalent" or "redundant" are actually (and apparently deliberately) misinterpreted as "remotely similar" by some editors (and not as "exactly the same"). This is actively used by CitationBot to remove even unrelated |url= value (like [13]) when a |doi= (pointing to [14]) is present. (In the given recent example, CitationBot also removed the |archive-url= alongside the |url=, thereby causing even more damage.) As I pointed out in the RfC, the terms "equivalent", "redundant" and even "duplicate" are apparently not clear enough to transfer the message unmistakably, therefore the wording should be actually changed to "exactly the same" or "identical".
• The statement that DOIs are more stable and may allow to specify the access status is factually misleading. We have |url-access= (and |url-status= and |access-date=) to specify the access status of |url= just like we have |doi-access= (and |doi-broken-date=) for |doi= etc. Also, while DOIs are designed to be long-living, they are not necessarily longer living than URLs. I have seen citations with broken URL and working DOI but also vice versa. So, the key against link rot is redundancy through archives and alternative links. As this is not actually relevant for template documentation purpose, we could either correct the statement or remove the sentence completely.
• "The |url= parameter [...] can then be used for its prime purpose of providing a convenience link to a free-to-read copy of the source that would not otherwise be obviously accessible.": This highly misleading sentence (see also: Help_talk:Citation_Style_1#Citation_Style_documentation/id2) should be removed completely. The primary purpose of |url= is not to provide a free-to-read copy of the source, but to point to the cited document, regardless if it is free or not. This doesn't rule out free documents, which are always nice to have, of course, but the notion that |url= was only for free documents crept further elsewhere and was (ab)used by some editors as an argument to remove |url= parameters from citations as well.

Now, the RfC is very clear about that being free is not a requirement for |url= to exist, therefore this could be reduced to something like "The |url= parameter [...] can then be used for other purposes." or be removed completely.

In general, I can only repeat myself, that the template documentation is not a guideline and should not attempt to be one.

--Matthiaspaul (talk) 17:57, 20 September 2020 (UTC)

Basically +1 to all of that, but also "When an URL is equivalent to the link produced by the corresponding identifier (such as a DOI), don't add it to any URL parameter but use the appropriate identifier parameter, which is more stable and may allow to specify the access status" should be removed altogether. The RFC concluded with consensus to link titles, which means a URL should be provided even if there is an identifier. Lev!vich 00:22, 21 September 2020 (UTC)

Identifiers can also link titles. Nemo 06:12, 21 September 2020 (UTC)

Regarding Barkeep49's mentioning of possible second or third order technical effects above, I actually see one such issue, which affects the template's implementation (and not only its documentation). I interpret the RfC's closure summary as a general reestablishment of the idea that editors should have full control over the title link and URL.

(IMO, a link provided via |url= can be considered unnecessary, if exactly the same link can also be established via auto-linking of one of the provided identifiers in a citation, but the condition really is "exactly the same" and not "similar" or "equivalent". (Only) under this specific condition removal of |url= would have zero effect on how a citation looks like and functions on user level, and therefore could be considered harmless, if not even beneficial (cleaner and easier to maintain citation code).)

However, for the editor to have full control over the linking, it is important that an option to override the auto-linking exists, a premise under which the auto-linking feature has been discussed from the beginnings several years ago in 2016 (until and beyond the auto-linking RfC in spring 2020). We discussed several options how to achieve this in a way nicely blending into our existing user interface and basically settled on overloading |url=none/(title-)doi/pmc/<other-identifier-parameter-name>/<url>/|chapter-url=none/(chapter-)doi/pmc/<other-identifier-parameter-name>/<url> only to (again) switch to use |title-link=none/doi/pmc/<other-identifier-parameter-name>/<link> instead in Help_talk:Citation_Style_1/Archive_70#Towards_solving_pending_issues_of_the_auto-link_feature.... Despite Pintoch's negative opinion on this, other users (proponents as well as editors opposing auto-linking in general) including Trappist the monk, Headbomb, Nardog, David Eppstein, myself and others have repeatedly asked over the years that auto-linking, if implemented, should have such a control. I won't go as far as to request for the setting "none" to become the default, still I think, also in the light of the outcome of this new RfC, that this facility should be implemented ASAP (ideally before the next update) to finally settle the case (so that future enhancements of auto-linking, some of which have been requested already, can be based on a solid implementation). --Matthiaspaul (talk) 11:21, 22 September 2020 (UTC)

See also: Help_talk:Citation_Style_1#Manual_override_of_auto-linking

--Matthiaspaul (talk) 18:58, 27 September 2020 (UTC)

Potential conflict between "Cite web" documentation and ProveIt?

Take a look at Special:Diff/979504621 -- it looks like PROVEIT is automatically placing the |url= parameter after the author and name fields in {{cite web}}. But on the documentation for that template, the provided formats all put that field first. It doesn't really matter to me either way, but it seems a little silly for the parameters to have two different canonical orderings. Anyone capable of shedding some light on this? {$\mathbb {JPG}$} 05:41, 21 September 2020 (UTC)

Perhaps the examples treat |url= as the semantically most important parameter in the specific template context, whereas Provelt orders according to most common index fields. I consider this more of a cosmetic difference. I am not sure that dictating a canonical order to editors adds value. The required parameters are signaled. The software formatting can handle the rest. 64.18.9.222 (talk) 11:05, 21 September 2020 (UTC)

Would be better if it left the order of parameters alone as it is a pain in differences. It should just change the parameter in-situ and not do any reordering. Keith D (talk) 11:59, 21 September 2020 (UTC)

There is no "canonical ordering". Ideally, tools should not change the order of parameters; as Keith D says, it makes diffs harder to inspect. – Jonesey95 (talk) 13:17, 21 September 2020 (UTC)

I also think that bots should normally leave the parameter order unchanged. Still, it might make sense to streamline our examples and template prototypes a bit to use a single order, ideally one that is semantically logical and thus can be memorized easily and that can be maintained over all CS1/CS2 citation templates.

A somewhat related thread: Help_talk:Citation_Style_1#Please_use_consistent_ordering_in_examples

--Matthiaspaul (talk) 16:46, 24 September 2020 (UTC)

Language indicator for article, not journal

In the past, a lot academic journals printed articles in different languages even in the same volume. The |language= indicator of {{cite journal}} should thus be article-specific, not journal-specific. By that I mean instead of

• Jacobi, C. G. (1834). "Ueber die Figur des Gleichgewichts". Annalen der Physik (in German). 109 (8–16): 229–233. doi:10.1002/andp.18341090808.

it should be

• Jacobi, C. G. (1834). "Ueber die Figur des Gleichgewichts" (in German). Annalen der Physik. 109 (8–16): 229–233. doi:10.1002/andp.18341090808.

This suggestion is actually related to a similar one I made in May regarding the language indicator placement in {{cite book}}. --bender235 (talk) 15:48, 24 September 2020 (UTC)

I agree, both for articles in a journal and books in a series, and also for separately-authored chapters in an edited book. Kanguole 16:06, 24 September 2020 (UTC)

FWIW, the topic was also touched here: Help talk:Citation Style 1/Archive 69#Placement of language annotation --Matthiaspaul (talk) 16:33, 24 September 2020 (UTC)

Oh, glad someone managed to dig that out quicker than I did.

To wit, please consider Module talk:Citation/CS1/Feature requests#Fix stacked parentheses problem and see if any of the suggested outputs look like they should not. --Izno (talk) 16:40, 24 September 2020 (UTC)

That is too complex to be confident of correctness. I suggest solving this in two stages:

1. Put the parentheticals where they belong – putting (in Lang) after a series, journal or edited book is clearly wrong.
2. Combine adjacent parentheticals.

Kanguole 17:08, 24 September 2020 (UTC)

It's not like either is trivial... --Izno (talk) 17:48, 24 September 2020 (UTC)

All the more reason to stage them. Kanguole 18:14, 24 September 2020 (UTC)

(edit-conflict) There is a somewhat related topic not in regard to the position of the language indicator, but in regard to the language value that should be displayed:

• Help_talk:Citation_Style_1/Archive_67#Possible_improved_treatment_of_title_parameters_and_language_attributes

|language= normally indicates the language of the work, but not necessarily that of |title= because if the original language title is not known, |title= (rather than |trans-title=) may contain the translated (here typically: English) title. But what, if |script-title= is used as well and its language prefix indicates a different language from |language=? Assuming that noone would go through the hurdles of writing a title in a non-Latin script if the work would not be in this very language as well, shouldn't the prefix language be considered the more accurate info and override the language provided by the |language= parameter? And, wouldn't it be possible that, if both are present and different, |language= actually was meant to apply to the journal/book as a whole (based on its display position) rather than the article/chapter? Should we display two "(in language)" then?

--Matthiaspaul (talk) 17:52, 24 September 2020 (UTC)

The language prefix and the language of the work will usually be the same, but there might be situations where they differ, and it's simple enough to continue to ask people to supply both.

The concern of a citation is the language of the work being cited, in this case a journal article or separately-authored chapter in an edited book. The language of the whole journal or book is not particularly relevant. Kanguole 18:14, 24 September 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 ([15]), 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)

freeze changes to the module suite

For a while now I have intended to begin the live-module update process. Whenever I got myself ready to do that, someone changed something so I put it off.

It is time to freeze changes to the module suite sandboxen so that we can update the live modules. Finish what you are doing this weekend. No changes after Sunday except to fix something that is obviously broken. Next weekend we can announce an update for 10–11 October 2020.

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

Matthiaspaul, have you seen this message? Do you have a timetable for finishing your proposed changes so that we can discuss updating the module? And are you planning to document, explain, or discuss the functional changes that you are making to the sandboxes with edits like these that are marked as copy edits? When we have updated the modules in the past, Trappist has provided a careful, detailed list of all of the changes, along with links to the discussions where those changes were proposed and discussed. – Jonesey95 (talk) 13:06, 29 September 2020 (UTC)

I wonder how you could miss that I am motivating, documenting and discussing most any changes I do (except for trivialities) all the time, probably more than anyone else in this forum.

From Trappist's comment above I take it that he wants to set up the list, but as I keep track of my changes, I could do that just as well (if I'll have time then).

In general, I try to always keep the code in a releasable state, except for the very short periods of time while I am actively working on or testing something. So, if Trappist wants to take a snapshot for release he can do so (and could have done so in the past as well) at almost any time. I certainly don't hinder any admin from carrying out the update, in particular not as there have been repeated complaints by other editors to release more frequently (f.e. Help_talk:Citation_Style_1#Still_broken:_title=none_+_doi-access=free).

I would also have no problems to update every one or two months, or at least when we have bug fixes for serious bugs or major new features to be rolled out. On the other hand, I also think that we should not update yet more frequently (except for in emergency cases), because if everything is in flow, it is more difficult to detect bugs. Also, even though the update itself is trivially easy to do, we need to be careful because of the high transclusion count and the relatively fragile nature of the Lua interpreter language and limited debug facilities.

However, in general, I think that in a collaborative project things need to be negotiated, not dictated. So, if Trappist would have mentioned that he has time to work on the update on the next two weekends and asked if we could arrange for the update to happen then because it would be convenient for him, I would have answered long ago offering my support. I think I am normally a nice person and quite approachable, but I expect this from others as well. So, if one decides to enforce something on fixed dates without negotiation with other developers he certainly can do so, but then I feel not obligated to answer or interact.

I don't think we need to block the sandbox for two weeks just to prepare an update, that's too much precious potential development time wasted. (Perhaps we should think about a separate release stage area in addition to the sandbox in the next round.) But, nevertheless, as I don't want to hinder Trappist's pace, I have not added new features after the weekend, only cleanups and minor tweaks, although I have several features pending for inclusion already (which I would have included otherwise).

If we ignore a schedule for a moment, from a perspective which changes might still make sense before the update, these are the things I would normally like to see being addressed before the update:

• Fix of one remaining bug in the code related to (auto-)linking when the title has embedded links. This is an old bug also present in the live template (but not yet discussed) and it is partially addressed in the sandbox already, but not completely. I hope to find the time to look into this before the weekend, but either case, as there are workarounds this should not block an update.
• I think it would be convenient for users if the template would optionally issue suggestions not only for unsupported parameters (as it does now), but also for parameters currently deprecated (in addition to the help link). Since deprecation only affects a few parameters temporarily, only few citations would be affected, therefore I think the performance hit would be acceptable. I assume that adding this would not be difficult, but I haven't studied that part of the code thoroughly, so I don't know for certain. With luck, someone else (or I) would look into this before the weekend, but if not, we should roll out without it.
• If there is enough time, I could add some error messages for certain parameter error conditions not currently addressed, but this is non-blocking as well.
• The current preparations for descriptive titles are incomplete and kept in an interim state for a potential update of the template. However, if there would be a couple of days more time, I would like to rework and finish it, but this can also happen after the next update.
• We should certainly also check secondary templates for pass-through parameters to now disabled/deprecated parameters and update them accordingly.

I don't know if I will have time on the weekends of the 2020-10-10/11 and 2020-10-17/18, which is bad, because we will have to update various error/maint category names during the update. And in the days following the update we will have to fix up deprecated parameter names in articles, and also update the documentation. So, IMO, we could even release in the middle of the next week already.

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

I called for a freeze because the module sandboxen have been in a state of more-or-less continuous churn since about 19 September. The editors who usually comment here seem to me to have become remarkably quiet. I wonder why that is.

We are not in a race. If something isn't part of this update, there will be another update.

—Trappist the monk (talk) 16:09, 30 September 2020 (UTC)

I, for one, have become "remarkably quiet" because of the overwhelming volume of changes and proposed changes, and the huge blocks of text that the proposers of these changes have added to this normally concise talk page. I have simply been unable to understand and track all of them. As I have indicated above, I worry that a significant amount of under-discussed change will result in a backlash from regular editors, as has happened in the past. I hope that I am wrong.

I look forward to seeing a complete, concise list of the functional differences between the live modules and the sandbox modules. – Jonesey95 (talk) 18:52, 30 September 2020 (UTC)

I concur. I would add that implementation of closed RFCs or of any outstanding consensus should perhaps take precedence over any changes other than stability/security related ones. Let's play nice. 98.0.246.242 (talk) 19:39, 30 September 2020 (UTC)

I am the same as Jonesey and the IP. I'm about || close from reverting everything to prior to the churn and having a proper discussion; much of what was added had certain decisions made that were poor in some fashion or another and some of what was added or changed did not obviously have consensus to me. --Izno (talk) 23:50, 30 September 2020 (UTC)

I agree, please revert. Rushing changes to the module just before an announced deployment to prevent them from being reviewed and discussed is very counter-productive and partial. − Pintoch (talk) 07:29, 1 October 2020 (UTC)

To move this groundless "witch-hunt" into a constructive direction again, Trappist, will you provide the list of changes or should I?

--Matthiaspaul (talk) 20:21, 1 October 2020 (UTC)

Manual override of auto-linking

As extensively discussed in the past months, a manual override facility has now been implemented for the auto-linking feature.

For this, |title-link= now supports a number of additional keywords: none, pmc, doi. They can be used to manually select one of the identifiers enabled for auto-linking (currently only PMCs and DOIs) or to completely disable auto-linking. Any values not matching one of these keywords will be interpreted as link target to a Wikipedia page (or one of its sister projects), as before. If such a link target would clash with one of the keywords, the ((accept-this-as-is)) syntax can be used to enforce the interpretation as a link target.

Auto-linking is also disabled if the display of the title has been disabled by |title=off (currently also still |title=none), whereas it remains enabled for descriptive titles (including the "No title" case, which can be specified by |title=none in the future).

If the |title-link= parameter is left empty and no |url= is specified, the template will automatically select an identifier for auto-linking, whereby the current priorities will let PMCs take precedence over DOIs, assuming both to be valid and active. Invalid or embargoed PMCs as well as non-free, inactive or invalid DOIs will be ignored in this selection. To play it safe, the present implementation also ignores "invalid" DOIs accepted using the accept-this-as-is syntax - after all, auto-linking is a non-essential feature and the identifier link is always available through the normal identifier link as well.

At present, auto-linking is only enabled for {{cite journal}}, but it could be generalized to be supported by other cite templates as well (as was requested already).

The list of supported identifiers can be extended in the future (also already requested), but I recommend that only manual auto-linking will be used for a larger list of identifiers, unless the identifier will have a similar "prominence" as DOIs or PMCs. Otherwise, the priority-based auto-selection may appear "arbitrary" to readers.

Another possible future extension (also already requested) would be to allow auto-linking of chapters in addition to titles.

See also:

• Wikipedia:Village_pump_(proposals)/Archive_135#Access_Locks:_Citation_Template_Behaviour_RFC
• Help_talk:Citation_Style_1/Archive_59#RfC_on_linking_title_to_PMC
• Help_talk:Citation_Style_1#Implementation
• Help_talk:Citation_Style_1/Archive_68#module_suite_update_11–12_July_2020
• Help_talk:Citation_Style_1/Archive_70#Towards_solving_pending_issues_of_the_auto-link_feature...
• Help_talk:Citation_Style_1#Guidance_on_title-linking:_update_after_RfC

Some examples:

Extended content

{{cite journal/new |title=Title |author=Author |journal=Journal}} → Author. "Title". Journal. {{cite journal}}: |author= has generic name (help) (DOI+PMC not given, nothing selected) {{cite journal/new |title=Title |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free}} → Author. "Title". Journal. doi:10.1145/36204.36194. {{cite journal}}: |author= has generic name (help) (DOI given, DOI auto-selected) {{cite journal/new |title=Title |author=Author |journal=Journal |pmc=7135076}} → Author. "Title". Journal. PMC 7135076. {{cite journal}}: |author= has generic name (help) (PMC given, PMC auto-selected) {{cite journal/new |title=Title |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076}} → Author. "Title". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help) (DOI+PMC given, PMC auto-selected) {{cite journal/new |title=Title |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076 |title-link=pmc}} → Author. "Title". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help) (DOI+PMC given, PMC manually selected) {{cite journal/new |title=Title |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076 |title-link=doi}} → Author. "Title". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help) (DOI+PMC given, DOI manually selected) {{cite journal/new |title=Title |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076 |title-link=none}} → Author. "Title". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help) (DOI+PMC given, auto-linking disabled) {{cite journal/new |title=Title |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076 |pmc-embargo-date=2020-12-31}} → Author. "Title". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help)CS1 maint: PMC embargo expired (link) (DOI+PMC given, PMC embargoed, DOI auto-selected) {{cite journal/new |title=Title |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |doi-broken-date=2020-09-01}} → Author. "Title". Journal. doi:10.1145/36204.36194 (inactive 2020-09-01). {{cite journal}}: |author= has generic name (help)CS1 maint: DOI inactive as of September 2020 (link) (inactive DOI given, nothing auto-selected, correct maint message) {{cite journal/new |title=Title |author=Author |journal=Journal |doi=10.1130/focus122009.1. |doi-access=free}} → Author. "Title". Journal. doi:10.1130/focus122009.1.. {{cite journal}}: |author= has generic name (help); Check |doi= value (help) (invalid DOI given, nothing auto-selected, correct error message) {{cite journal/new |title=Title |author=Author |journal=Journal |doi=((10.1130/focus122009.1.)) |doi-access=free}} → Author. "Title". Journal. doi:10.1130/focus122009.1.. {{cite journal}}: |author= has generic name (help)CS1 maint: ignored DOI errors (link) (invalid DOI given, but accepted, nothing auto-selected, correct maint message) {{cite journal/new |title=Title |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076 |title-link=Title}} → Author. "Title". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help) (DOI+PMC given, title target article "Title" selected) {{cite journal/new |title=Title |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076 |title-link=((doi))}} → Author. "Title". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help) (DOI+PMC given, title target article "doi" selected) {{cite journal/new |title=off |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076}} → Author. Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help)CS1 maint: untitled periodical (link) (DOI+PMC given, title disabled, no auto-linking, correct maint message) {{cite journal/new |title=(())<!-- in the future also: none --> |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076}} → Author. No title. Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help)CS1 maint: untitled periodical (link) (DOI+PMC given, descriptive "no title" specified, PMC auto-selected, correct maint message) {{cite journal/new |title=((off)) |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076}} → Author. "off". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help) (DOI+PMC given, title label "off" selected, PMC auto-selected) {{cite journal/new |title=((off)) |title-link=((doi)) |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076}} → Author. "off". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help) (DOI+PMC given, title label "off" selected, title target article "doi" selected) {{cite journal/new |title=Title |author=Author |journal=Journal |url=https://en.wikipedia.org}} → Author. "Title". Journal. {{cite journal}}: |author= has generic name (help) (DOI+PMC not given, URL given, URL selected) {{cite journal/new |title=Title |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076 |url=https://en.wikipedia.org}} → Author. "Title". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help) (DOI+PMC given, URL given, URL selected) {{cite journal/new |title=Title |title-link=Title |author=Author |journal=Journal |url=https://en.wikipedia.org}} → Author. "Title". Journal. {{cite journal}}: |author= has generic name (help); URL–wikilink conflict (help) (DOI+PMC not given, URL and title link given, URL selected, correct error message) {{cite journal/new |title=Title |title-link=Title |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076 |url=https://en.wikipedia.org}} → Author. "Title". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help); URL–wikilink conflict (help) (DOI+PMC given, URL and title link given, URL selected, correct error message) {{cite journal/new |title=Title |title-link=Title |author=Author |journal=Journal |url=https://en.wikipedia.org}} → Author. "Title". Journal. {{cite journal}}: |author= has generic name (help); URL–wikilink conflict (help) (DOI+PMC not given, URL and title link given, URL selected, correct error message) {{cite journal/new |title=Title |title-link=Title |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076 |url=https://en.wikipedia.org}} → Author. "Title". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help); URL–wikilink conflict (help) (DOI+PMC given, URL and title link given, URL selected, correct error message) {{cite journal/new |title=[[Title]] |author=Author |journal=Journal |url=https://en.wikipedia.org}} → Author. "[[Title]]". Journal. {{cite journal}}: |author= has generic name (help); URL–wikilink conflict (help) (DOI+PMC not given, URL and embedded title link given, URL selected, correct error message) {{cite journal/new |title=[[Title]] |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076 |url=https://en.wikipedia.org}} → Author. "[[Title]]". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help); URL–wikilink conflict (help) (DOI+PMC given, URL and embedded title link given, URL selected, correct error message) {{cite journal/new |title=[[Title]] |author=Author |journal=Journal |url=https://en.wikipedia.org}} → Author. "[[Title]]". Journal. {{cite journal}}: |author= has generic name (help); URL–wikilink conflict (help) (DOI+PMC not given, URL and embedded title link given, URL selected, correct error message) {{cite journal/new |title=[[Title]] |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076 |url=https://en.wikipedia.org}} → Author. "[[Title]]". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help); URL–wikilink conflict (help) (DOI+PMC given, URL and embedded title link given, URL selected, correct error message) {{cite journal/new |title=[[Title]] |author=Author |journal=Journal}} → Author. "Title". Journal. {{cite journal}}: |author= has generic name (help) (DOI+PMC not given, embedded title link given, title selected) {{cite journal/new |title=[[Wikipedia|Title]] |author=Author |journal=Journal}} → Author. "Title". Journal. {{cite journal}}: |author= has generic name (help) (DOI+PMC not given, piped embedded title link "Wikipedia" with label "Title" given, title selected)

--Matthiaspaul (talk) 18:51, 27 September 2020 (UTC) (updated 14:45, 30 September 2020 (UTC))

These two examples still show incorrect behaviour related to embedded title links (but this old bug is present in the live version of the template as well and some corner cases of it are already fixed in the sandbox):

Extended content

{{cite journal/new |title=[[Title]] |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076}} → Author. "[[Title]]". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help); URL–wikilink conflict (help) (DOI+PMC given, embedded title link given, PMC incorrectly selected, incorrect error message) {{cite journal/new |title=[[Wikipedia|Title]] |author=Author |journal=Journal |doi=10.1145/36204.36194 |doi-access=free |pmc=7135076}} → Author. "[[Wikipedia|Title]]". Journal. doi:10.1145/36204.36194. PMC 7135076. {{cite journal}}: |author= has generic name (help); URL–wikilink conflict (help) (DOI+PMC given, embedded title link "Wikipedia" with label "Title" given, PMC incorrectly selected, incorrect error message)

Since the bug is old and can be easily worked around by using |title-link= instead of embedding the link into |title= itself, this is not blocking a release.

--Matthiaspaul (talk) 14:45, 30 September 2020 (UTC)

Hi Matthiaspaul, I do not think there is consensus for this change (as extensively discussed before). Please revert your changes. Thank you! − Pintoch (talk) 07:08, 1 October 2020 (UTC)

Auto-linking has always (since 2016 up to after the RfC in 2020) been discussed under the assumption that there is or will be a way to manually override it if necessary, because there obviously are cases where it will link to the wrong target. This was mentioned by users who opposed auto-linking (like David Eppstein or myself), but also by vivid proponents of the feature (like Headbomb). Without some override facility people will either have to remove the PMCs and DOIs from such citations or stop using citation templates at all, both options which are directly diametral to the purpose of citation templates of making it as easy as possible to provide fully-fledged citations, and thus not desirable at all. The recent RfC on title linking also concluded that users should have full control over what is linked to a title and what not.

Since your original implementation did not address this, introduced several bugs (all but one finally addressed with this pending update) and unconditionally enforced auto-linking, we have, over the course of months, discussed possible ways how to integrate this into the system in a seamless way.

We basically had three models, one using a separate parameter like |auto-link= or |auto-url= (both originally suggested by Headbomb), and two overloading existing parameters, |url= (originally suggested by Trappist the monk, Nardog and me) and |title-link= (also suggested by me, but Trappist also noted sympathies for this). Headbomb's proposal would have added a new parameter and the names suggested so far did not fit into our naming scheme well, but he was generally open to other parameter names and implementations. When requests regarding auto-linking of chapters came up, I abandoned my |title-link= proposal in favour to Trappist's because it appeared slightly more flexible in the long run, but switched back to |title-link= to address your concerns that overloading |url= might cause problems with external scripts needing to be updated. In the post above I gave links to some of the past discussions regarding this.

So, there is a clear desire to have some means to control auto-linking when the automatic default doesn't work. Among those proposals offered over the course of months, I think, we have found the best solution, and, to be honest, I really can't see how this would interfere with your desire for auto-linking in general (actually, it helps to make auto-linking a feature which can be accepted by anyone), unless there is some dogmatics/politics involved why you deliberately don't want to give editors the control over citations they need - but I can't see how this would be in agreement with our core principles regarding verifiability and NPOV.

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

I have better things to do than repeating arguments over and over. If you genuinely intend to address my concerns with your move, you would have addressed them months ago already (such as giving an example of a citation where it is desirable to disable auto-linking). I just wanted to note my opposition to your changes and generally to your attitude (squeezing a big change like this just before an update to bypass discussion is not very considerate to your fellow editors). − Pintoch (talk) 16:10, 1 October 2020 (UTC)

This is really such a waste of time. So far, you did not provide any arguments except for that you don't like it, which is not a useful argument at all. Simply stating that a feature is not needed because you don't need (want?) it in the face of other users asking for it, is denialist behaviour not up to communication standards between intelligent people. (See, I personally do not consider auto-linking a desirable feature at all, but obviously there are other users who want it, so any arguments that it would not be desirable in general would be stupid. Instead, I try to destill the reasons for why some people want it and others don't, and seek a solution addressing the wishes and concerns of both parties. This approach of trying to learn from opposing arguments is what I expect from other editors as well. But it requires that people bring forward actual arguments not groundless opinions.)

You did not bother to fix the various bugs you introduced into the implementation over the course of months and you very prominently and rudely backed out of the constructive discussion which was seeking for solutions. Basically, if you have nothing constructive to contribute, it might be better to really spend your time on other things instead of attempting to hinder constructive editors in improving the project, in particular as the solution is giving you exactly what you wanted (automatic auto-linking by default).

I also ask you to stop your repeated bad faith accusations, they are completely groundless. In fact, I waited long enough for someone else to fix your bugs and address the concerns (because I also have better things to do) before I started to code the solution myself because I couldn't stand this complete lack of progress any more - it's harmful to the reputation of the project. Before that, because I very much value any constructive comments by my fellow editors (even if I don't agree with all of them), I very carefully discussed and weighted the various options we have, involving the community in utmost possible ways. And I did not squezze any big changes in before any update, actually, my code existed before Trappist's announcement (which he should have first negotiated with other developers, anyway) and I removed several features from the to-be-submitted code because they need more discussion.

--Matthiaspaul (talk) 19:16, 1 October 2020 (UTC)

There should be an overide mechanism. The simplest being |url=doi/pmc/jstor/etc/none / |chapter-url=doi/pmc/jstor/etc/none. If you want an example where a link is not desired, title-less journal citations would be the go-to example.

• Smith, J. (2020). Journal of Stuff. 3 (31): 20–12. doi:10.4321/example.{{cite journal}}: CS1 maint: untitled periodical (link)

Headbomb {t · c · p · b} 16:26, 1 October 2020 (UTC)

Yep. Having internally considered and compared the |url= and |title-link= proposals code-wise, I have come the conclusion that the latter was even easier to implement. (I have a solution for the chapter link issue also for |title-link= but this will need more discussion, therefore it's not included at this time.)

Another example where override is needed are chapter DOIs which would be accidently linked to a title (instead of a chapter title) if there would be no way to override the behaviour.

Also, if the original editor providing a citation linked the title to a DOI, this should not be suddenly overruled by auto-linking to a link to PMCs just because some drive-by editor or bot added a PMC without at least given the editor the chance to reselect the DOI. It would invalidate the citation.

--Matthiaspaul (talk) 19:16, 1 October 2020 (UTC)

|title-link= is a terrible use for this because it is overwhelmingly used for links to Wikipedia and sister projects like Wikisource. This replaces URL, so it should use the URL parameters. Difficulty of implementation matters a whole lot less than ease of use (|url= is both much shorter to type than |title-link=, and guarantees there is no conflicting url/title-link like someone adding |url=https://example.com to a citation with |title-link=doi. Headbomb {t · c · p · b} 19:30, 1 October 2020 (UTC)

While I don't think |title-link= is "terrible", I see your point (that's why I proposed |url= for a long while as well ;-). Also, I specifically agree with that difficulty of implementation does not matter (we should always strive for the best-possible solution for users, no matter if it is difficult to code or not). Among the cons for |url= is that bots reading citations might be confused if they find something like "doi" in this prominent parameter, whereas it is very unlikely that they care about the value of an "inward-bound" parameter such as |title-link=. Among the pros for |title-link= is that something like |title-link=doi or |title-link=none is semantically much more to the point than |url=doi or |url=none. An the argument of states being mutually excluded by the underlying parameter logic applies to both parameters as well, just that |url= is probably more commonly used than |title-link=. I was (and still are) open to both, but now slightly favour |title-link=. Functionality-wise, both solutions are equivalent. --Matthiaspaul (talk) 20:06, 1 October 2020 (UTC)

Among the cons for |url= is that bots reading citations might be confused if they find something like "doi" in this prominent parameter, whereas it is very unlikely that they care about the value of an "inward-bound" parameter such as |title-link=.

Any tool or bot that gets confused by that would get confused by any invalid URL parameter like {{cite web|url=htp:s//example.com|title=Title}}. There are tons of those in Category:Pages with URL errors. Most such tools or bots already correctly handle such errors either by failing, or by not touching |url= because they don't know what to do with it. Using the existing parameter |url=/|chapter-url=/|contribution-url=/|foobar-url= greatly reduced complexity for users, who then don't need to learn the arcane |title-link/chapter-link/contribution-link= and wrap their heads around why a -url parameter is renamed -link. Headbomb {t · c · p · b} 20:32, 1 October 2020 (UTC)

Format parameter

I propose moving |format= content so that it is positioned after title and not after text "Archived from the original". --5.43.72.55 (talk) 19:50, 27 September 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#PMID_limit

--Matthiaspaul (talk) 21:30, 12 October 2020 (UTC)

Module suite update 10–11 October 2020

I propose to update cs1|2 module suite over the weekend 10–11 October 2020. Here are the changes:

Module:Citation/CS1:

• deprecate |editors= parameter; discussion
• fix duplicate error message; discussion
• auto-link bug fix; discussion
• unify handling of error and maint messaging; upgrade disp_names maintenance messaging to error, change unrecognized display name values from invalid_param_value to disp_name; discussion
• tweak |<name>-link= and |<name>-mask= interaction; discussion
• fix given-missing-surname error message; discussion
• check for more than 0 semicolons; discussion
• |orig-date= preferred over |orig-year=, change metaparameters; discussion
• error messaging for 'Wayback Machine' and other generic titles; discussion
• use common function to render comma-separated lists; discussion
• convert to <module>.<function>() calls to avoid upvalue limit; discussion
• move add_prop_cat() to Module:Citation/CS1/Utilities/sandbox; discussion
• add keyword "off" to distinguish from "none" in |title=; discussion
• add override and disable capability for auto-linking; discussion, discussion, discussion, discussion
• add |trans-quote=, |script-quote=, |page(s)-quote=; discussion
• detect and report empty invalid parameters; discussion
• deprecate |last-author-amp=; discussion
• detect and report malformed interwiki links; discussion

Module:Citation/CS1/Configuration

• deprecate |editors= parameter
• add |subject-mask= parameters; discussion
• unify handling of error and maint messaging; discussion
• upgrade disp_names maintenance messaging to error; discussion
• error messaging for 'Wayback Machine' and other generic titles
• revise df_template_patterns{} table; discussion
• add |orig-date=; discussion
• remove support for |series-separator=; discussion
• remove support for |ignoreisbnerror=, |doi-broken=, |doi-inactive-date= and rename |embargo= to |pmc-embargo-date=; discussion
• convert inactive doi categories to proper maint cats; discussion
• add support for missing aliases |author-given#=, |author#-given=, |author-surname#=, |author#-surname=, |interviewer-given#=, |interviewer#-given=, |interviewer-surname#=, |interviewer#-surname=, |display-subjects=; discussion
• remove support for unused aliases |displayeditors=, |editormask= and enumerated forms; discussion
• support ((accept-this-as-written)) syntax for used DOIs not matching our validity check; discussion, discussion, discussion
• remove support for unused aliases |notracking= and |no-cat=, made |no-tracking= the canonical form for now; discussion
• support ((accept-this-as-written)) syntax for invalid ISSNs; discussion
• add year range abbreviated properties cat; discussion
• add keyword "off" to distinguish from "none" in |title=; discussion, discussion
• add |trans-quote=, |script-quote=, |page(s)-quote=
• add |name-list-style= as preferred alias of |name-list-format=; discussion
• bump pmc limit; discussion
• detect and report malformed interwiki links

Module:Citation/CS1/Whitelist

• deprecate |editors= parameter
• add |subject-mask= parameters; deprecate non-hyphenated subjectlink params; discussion
• add |orig-date=
• remove support for |series-separator=
• remove support for |ignoreisbnerror=, |doi-broken=, |doi-inactive-date= and rename |embargo= to |pmc-embargo-date=
• remove support for |interviewerlink= and |interviewermask=; add support for missing aliases |author-given=, |author-surname=, |author-given#=, |author#-given=, |author-surname#=, |author#-surname=, |interviewer-given#=, |interviewer#-given=, |interviewer-surname#=, |interviewer#-surname=, |display-subjects=; discussion
• moved |transcript=, |transcript-format=, |transcripturl=,|transcript-url=, and |inset= to unique arguments table; discussion
• moved |mailinglist=, |mailing-list= to unique arguments table; discussion
• remove support for unused aliases |displayeditors=, |editormask= and enumerated forms; discussion
• deprecate |displayauthors= as well as |editorlink=, |authormask= and enumerated forms; discussion
• deprecate |ignore-isbn-error=; discussion discussion
• remove support for unused aliases |notracking= and |no-cat=, made |no-tracking= the canonical form for now
• add |trans-quote=, |script-quote=, |page(s)-quote=
• add |name-list-style= as preferred alias of |name-list-format=
• deprecate |last-author-amp=

Module:Citation/CS1/Date validation

• fix dmy-dmy and mdy-mdy month spelling error detection; detect same-season-to-same-season errors in s-s y dates; discussion
• use common function to render comma-separated lists
• add year range abbreviated properties cat; discussion

Module:Citation/CS1/Identifiers

• auto-link bug fix
• unify handling of error and maint messaging
• disable auto-linking from |doi= & |pmc= when embargoed, broken, or fail validation; convert inactive doi categories to proper maint cats; discussion
• fix PMC link composition to go through redirect also if still under embargo; discussion
• use utilities.has_accept_as_written() for |doi=, |eissn=, |isbn=, |issn=, |sbn=; discussion discussion, discussion

Module:Citation/CS1/Utilities

• unify handling of error and maint messaging
• create has_accept_as_written(); discussion
• add_prop_cat() moved here from Module:Citation/CS1/sandbox

Module:Citation/CS1/styles.css

• Remove PNG icons as WMF dropped basic support for IE8

Module:Citation/CS1/Suggestions

• suggest |orig-date= instead of |orig-year= parameter; discussion
• add hints for removed parameter names |ignoreisbnerror=, |doi-broken=, |doi-inactive-date= and |embargo=; discussion and discussion
• add hints for removed parameter names |interviewerlink= and |interviewermask=; discussion
• add hints for some likely misspellings of parameter names which do not have hyphenated forms (|eprint=, |inset=, |network=, |newsgroup=, |newspaper=, |postscript=, |surname=, |transcript=, |vauthors=, |veditors=)
• add hints for parameters from citation templates in Italian and Spanish Wikipedia
• add hints for removed parameter names |authorfirst=, |authorlast=, |authorgiven= |authorsurname=, |displayeditors=, |editorfirst=, |editorlast=, |editorgiven=, |editorsurname=, |editormask= and enumerated variants; discussion and discussion
• add hint for old parameters |laysummary= and |lay-summary=.
• add hints for two likely misguesses |forename= and |family= due to our support for given/surname instead of given/family and forename/surname
• added hints for removed aliases |notracking= and |no-cat=; discussion

—Trappist the monk (talk) 10:18, 3 October 2020 (UTC) 10:42, 4 October 2020 (UTC) (+empty unknowns) 14:04, 4 October 2020 (UTC) (+|last-author-amp=) 15:07, 5 October 2020 (UTC) (+interwiki link check)

Matthiaspaul, can you please add your changes to this list when you have time? – Jonesey95 (talk) 13:46, 3 October 2020 (UTC)

I think the list includes Editor Matthiaspaul's changes.

—Trappist the monk (talk) 14:31, 3 October 2020 (UTC)

I did a Find in the list above for the modified processing of "Jnr" and additional suffixes, but I did not see them mentioned.

Cite book comparison

Wikitext	{{cite book|first=Harvey Jnr|last=Smith|name-list-format=vanc|title=Title}}
Live	Smith, Harvey Jnr. Title. {{cite book}}: Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (help)
Sandbox	Smith, Harvey Jnr. Title. {{cite book}}: Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (help)

Maybe that change is too trivial for a bullet, but it makes me wonder what else has been missed. – Jonesey95 (talk) 05:13, 4 October 2020 (UTC)

Alas, none of us are perfect. You and other editors have made additions to past lists when I have failed to include those items. This time I also missed the empty unknown parameter detection (now included).

—Trappist the monk (talk) 10:42, 4 October 2020 (UTC)

Error messages for generic titles

* "error messaging for 'Wayback Machine' and other generic titles" .. this one will probably generate community discussion due to the volume of red messages. Possible outcomes include:

• The new |title=no-title will come up and people will begin using no-title in some automated fashion to squelch errors. Then we don't know what is a legit no-title versus one that was a generic title needing filling in.
• As in the past when a large payload of new error messages are introduced, the community requests they be lifted until a bot can clean up legacy cases (bots can and have determined page titles)
• The community is OK with generic title placeholders + tracking cat, and doesn't want error messages.
• Some mix of these or others.

Once it becomes a general VP/community issue developers can loose control of what they think is best due to RfC outcomes. if we are lucky that won't happen but given the scale of red errors it's a real possibility. There are also the other stakeholders involved IABot, Citation bot, WaybackMedic, Refill and others. Personally of the opinion we should try and reduce cases before adding red errors, or at least announce the intention and give the community some time (6 months etc) to respond. -- GreenC 17:03, 3 October 2020 (UTC)

It's that whole visibility thing isn't it? If editors don't know that the errors are there they won't know that something needs fixing. Why does Category:CS1 maint: archived copy as title (53,987) list so many articles? Because maintenance messaging is hidden unless editors turn it on. According to this search, there are about 20 of us who have it turned on. So, essentially, no one knows that there is a problem ...

It's worse for error messaging because the 'show all error messages' css that used to be at Help:CS1 errors § Controlling error message display (until this edit where it was commented out) provided a way for editors to see hidden error messages. According to this search, there are 7 of us who can see all error messages. Again, no one knows that there are problems. We should fix Help:CS1 errors so that editors who care can learn how to show hidden error messages.

So, yeah, we can hide the generic title error messages but only "we few, we happy few" will know that they exist. You were a participant in the Wayback Machine discussions. You know the numbers we were seeing for the various proposed generic titles. Given that there are 6,837,424 articles, the few thousand articles that we found by the various searches do not seem to me to be an intolerable quantity. Of course, all it takes is one "shrill shrieking" editor who perceives that the sky is falling and we'll be back at WP:AN and "spitted upon pikes" ...

Quotes from Shakespeare's Henry V

—Trappist the monk (talk) 18:37, 3 October 2020 (UTC)

Restored show-all-errors css at Help:CS1 errors § Controlling error message display.

—Trappist the monk (talk) 18:46, 3 October 2020 (UTC)

... and I've been reverted.

—Trappist the monk (talk) 19:02, 3 October 2020 (UTC)

We have no hidden errors so I have reverted your change. (Which is also why "for l10n/i18n" is in the wikitext comment.) The change which removed the 'show everything at all times' is here, and is not necessary because the only hidden citation notations are maintenance messages, for which the CSS of interest is provided. The set of people who can see everything is still that CSS, which is probably closer to this search. 350 is still abysmal (and includes editors who are no longer editing/have hidden everything). --Izno (talk) 19:10, 3 October 2020 (UTC)

Actually, we do: Category:CS1 errors: missing periodical is hidden and Category:CS1 errors: empty unknown parameters will be hidden.

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

Ah, I forgot that one is hidden. Okay then. --Izno (talk) 19:23, 3 October 2020 (UTC)

Some maintenance items to upgrade to errors (2)

original discussion

cs1|2 does not support 'dynamic' error category names. It could, because we create some maintenance category names dynamically, it just doesn't because there has been no need.

In this case there is no need for five separate error categories when one will be sufficient. So, I have tweaked the code so that these errors will all be listed in the single category: Category:CS1 errors: display-names.

—Trappist the monk (talk) 18:33, 5 October 2020 (UTC)

I guess there's my opinion. :) --Izno (talk) 19:11, 5 October 2020 (UTC)

"Revised by" parameter for Cite Encyclopedia

Would it be possible to add a "Revised by" parameter for Template:Cite encyclopedia? I'm speaking specifically of using it for Grove articles, such as this one, where having the person who revised the article as the second author wouldn't make sense (because they didn't add the bulk of the article) and having them as the editor wouldn't either (because they aren't the editor of the encyclopedia as a whole, which is how it would display). Aza24 (talk) 18:34, 5 October 2020 (UTC)

The catch-all parameter |others= is useful for edge cases like this. – Jonesey95 (talk) 21:06, 5 October 2020 (UTC)

I agree with using |others=. I don't think cases with sources that name their revisors are common enough to make an entirely new parameter worthwhile. Glades12 (talk) 18:40, 6 October 2020 (UTC)

Indeed, I wasn't even aware that "others" existed, thank you both for letting me know. Aza24 (talk) 18:44, 6 October 2020 (UTC)

Labels for the "page" parameter

I must have missed the discussion/rationale for replacing the parameter labels p and pp, with page and pages respectively, in {{cite xxx}} templates. Can you please point me to the relevant section(s)? Thanks. I just noticed Citation Bot making the related edits. 98.0.246.242 (talk) 22:44, 5 October 2020 (UTC)

If you mean that Citation bot is replacing |p= with |page= and |pp= with |pages= then you should take that up at User:Citation bot. All four of those parameters are legitimate aliases; |page= and |pages= are the canonical forms.

—Trappist the monk (talk) 22:48, 5 October 2020 (UTC)

The documentation disagrees with you. There is no mention of aliases for the parameter, and p or pp are not there at all. So, when was this change discussed? 98.0.246.242 (talk) 23:32, 5 October 2020 (UTC)

Good catch. I have updated the documentation. – Jonesey95 (talk) 00:02, 6 October 2020 (UTC)

You know, the cs1|2 documentation has never been great. If you can see how it might be improved, please do so.

The first version of Module:Citation/CS1/Whitelist has entries for |p= and |pp=. The edit that appears to make aliases of |p= and |page= and of |pp= and |pages= is this edit. Was that discussed? Don't know. You might troll through the archives of this page and the Module talk:Citation/CS1 archives to see if it was discussed.

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

Well, I am not averse to the change, only of the fact that I could not find explanation for it. This may have widespread consequences as the bot is working through what I would presume to be many citations using the abbreviated form. For many editors this may seem an unnecessary/pedantic cosmetic edit. On the other hand, in today's digital age, abbreviations that were common in the print era may seem antiquated. There is also the general argument that abbreviations should be avoided as non-user friendly and cryptic. And thanks to Jonesey for restoring the documentation. The absence of the abbreviations from the doc (they were there previously) shows intent. 98.0.246.242 (talk) 00:41, 6 October 2020 (UTC)

It is not clear what change you are talking about. If you object to the change that the Citation bot tool made, you should bring it up at the bot's talk page. As for "restoring" the documentation, I don't think the aliases were ever in the documentation before, or when they might have been removed; you might check that page's history to be sure. – Jonesey95 (talk) 02:28, 6 October 2020 (UTC)

Reread the OP. As for the documentation, p and pp were always there as aliases or labels, pick any revision before September 2020. They disappeared a few days ago whereupon the bot went to work. Which is fine except for one thing: why didn't we know about it? 65.88.88.69 (talk) 18:31, 6 October 2020 (UTC)

Are you talking about Template:Citation_Style_documentation/pages or some other page? If another page, please link to it. – Jonesey95 (talk) 20:17, 6 October 2020 (UTC)

This is getting interesting. There is {{Citation Style documentation/doc}}. In this one, "p" and "pp" appeared 2012-02-17 2012-02-16. There are also specific template docs which I presume would be the documentation editors would be more prone to check, as it is transcluded in the template itself. An example is {{Cite book/doc}}. First appearance of "p" and "pp" is a day earlier on on the same day 2012-02-16. And then we have the documentation subtemplate you edited ({{Citation Style documentation/pages}}) which was more or less dormant/inactive until relatively recently, and where "p" and "pp" never existed. All purport to be based on {{csdoc}} ofcourse, but it seems there is a perfect storm of version-control confusion here. Under the circumstances I cannot blame the bot for the edits indicated in the OP, or the lack of discussion. This is caught in the cobwebs of CS1 documentation and apparently there is a huge, insincere spider at the center of it all. Nobody can get at it. 64.61.73.84 (talk) 00:38, 7 October 2020 (UTC)

I mentioned {{csdoc}} above. In it, "p" and "pp" appear earlier, on 2011-12-21. This, the day the template was created. 64.61.73.84 (talk) 00:59, 7 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)

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)

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#Guidance about indexing by first name?

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

PMID limit

At Special:Permalink/982911547#PMID error, Nixinova was concerned that PMID 33022132 was outside the range specified at Help:CS1 errors#bad_pmid. This turns out not to be the case, as the limit specificed there is 33100000. However, it's awfully close, which led me to investigate it.

• #1426 @ 2020-10-10: last id 33038074
• #1423 @ 2020-10-07: last id 33026741
  • 33038074 - 33026741 = 11333 ids / 3 days = 3778 ids/day
• #1334 @ 2020-09-11: last id 32915410
  • 33038074 - 32915410 = 122664 ids / 29 days = 4230 ids/day
• #1100 @ 2020-03-01: last id 32113198
  • 33038074 - 32113198 = 924876 ids / 223 days = 4147 ids/day

The PMIDs appear to be assigned sequentially and are documented to "not be re-used". Based on the highest numbers found in several daily files here, the rate is roughly 4000 per day. The latest PMID as of the 2020-10-10 file is 33038074, which means it will hit 33100000 in less than 16 days. Was there a reason for the (strangely specific) 33100000 limit, should it be increased (soon), and to what? —[AlanM1 (talk)]— 15:25, 11 October 2020 (UTC)

I see Trappist the monk has been maintaining Module:Citation/CS1/Configuration. —[AlanM1 (talk)]— 15:30, 11 October 2020 (UTC)

I picked 33100000 just to clear the error. The limit exists to catch simple typos: too many digits, most significant digits out of bounds. Alas, we can't catch too-few-digits or typos that produce in-bounds results... cs1|2 can't do much more to protect editors from these kinds of mistakes. The limit should be sufficiently tight that we catch typos but not so tight that we overrun the limit every few days.

We might set the limit at 33500000 which, at 4k/day, will last us 100+ days. Elsewhere on this talk page it is suggested that we automatically increment the limits for the various identifiers. I don't particularly like that as a solution because there is no way to automatically close the loop to reduce or increase the limit-deltas as conditions warrant.

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

Not without some arbitrary number like we have today, of course. --Izno (talk) 18:04, 11 October 2020 (UTC)

If someone has a general purpose bot, perhaps a job could be added to it, to be run monthly. It could retrieve the latest XML file from the FTP link above, find the highest PMID value, add 120,000 (30 days' use), round up to the next 100,000, and update the id_handlers['PMID'].id_limit value in the config file. Or someone could do it manually. While I do have a couple of things I do monthly manually, I don't have a foolproof system in place to ensure things get done and it would seem like this is too important for my casual approach. Are there other values here that can/should be updated, too? —[AlanM1 (talk)]— 06:05, 12 October 2020 (UTC)

We could also define a bot task to scan for the highest identifier value used in an article while performing other tasks (or have a bot continously loop over all articles), check this value against a value recorded in a new "/Limits" sub-page of the citation template, and update that value if the found value is higher. This sub-page would have to be unprotected to be easily accessible by bots and editors. The citation template could read this value and compare it against the value specified in its "/Configuration" module (which is protected), take the higher value, add some safety margin to it, and treat the result as the allowed upper limit in citations (with or without some extrapolation facility). Many variants of this are possible.

Using this approach would make it possible to more frequently update the limits while still ensuring that at least all values below the value specified in "/Configuration" are treated as valid. The limits in "/Configuration" would be updated whenever the template gets updated. By specifying a much too high value in "/Limits" vandals could temporarily disable the upper limit check but they could not cause the template to use much too low values in an attempt to invalidate (older) values in citations.

--Matthiaspaul (talk) 21:58, 12 October 2020 (UTC)

At least in theory Wikidata could also be used to retrieve some useful information instead or in addition to something like "/Limits": PMID has a property "number of records" P4876.

• 30060294 @ 2019-08-01
• 30178674 @ 2019-11-19

However, the info there is outdated.

--Matthiaspaul (talk) 19:24, 14 October 2020 (UTC)

That was here: Help_talk:Citation_Style_1#Bump_PMC_to_8000000.

This "auto-increment" would still require monitoring/updates/adjustments of the limits and factors, but less frequently.

--Matthiaspaul (talk) 21:58, 12 October 2020 (UTC)

Sounds more complicated and error-prone than using the latest XML change file at PubMed for the max value and adding enough headroom to get past the next anticipated run. I don't think it should try to be exact, since new IDs are constantly being assigned and the latest articles may not be cited for some time. The new increment could even be re-calculated on each run based on the current and previous months' max values and file dates, plus a fudge factor based on some stats I can get from the variance in the current history file set. —[AlanM1 (talk)]— 00:16, 13 October 2020 (UTC)

Yes, for as long as such an XML file exists as an external resource, but this does not seem to be the case for all identifiers which need to be bumped up frequently. --Matthiaspaul (talk) 00:58, 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)

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)

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)Template:Z48

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)

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)

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)

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=.

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)

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, 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'm having a hard time thinking of a case where we need this parameter in this template. (But, maybe that's just insufficient caffeination on my part.)

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=June 18, 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 June 18, 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)