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)

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=2020-07-21}}

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)

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 "safe" 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)

Possible scheme to mark parameter values for review

As a sidenote from the thread above, I like J. Johnson's idea of a "|badauthor=" parameter alias in the linked thread. In fact, I was thinking about something similar myself some while ago:

The prefix would have to be worded more neutrally like |debug-*=, |check-*=, |recheck-*=, |TEMP-*=, |-* ("minus"), |~* ("uncertain"), |?* ("question mark") or similar, and the prefix should be applicable to all template parameters in general, like |recheck-editor-last3=Radcliffe, |-issn=0367-9950 or |?publication-date=29 February 1866.

If an editor runs into a parameter value that appears to be incorrect and that should be double-checked, but cannot be verified immediately, the editor would just add the prefix to mark it for future review. Once this or another editor has checked a parameter flagged this way, s/he would correct the value if necessary and/or simply remove the prefix again.

The template could populate a special maintenance category for this, but otherwise these aliases would be treated exactly as their canonical forms, including error checking. This way, this feature could be coded as a general exception to the normal parameter evaluation and therefore without overhead and it could be documented in a single place like our ((accept-this-as-it-is)) syntax, without having to list it as an alias everywhere.

An alternative to this are HTML comments, but they are not machine-readable and wouldn't cause the citation to show up in a maintenance category.

The system could be extended to bot edits as well in two ways:

Bots running into entries they find fishy but cannot resolve reliably (that is, with 100% accuracy) could instead mark the parameter with the prefix and leave it to humans to actually check and possibly correct it, instead of applying guesswork themselves. This would extend the model of a bot/tool assisting a specific user synchronously to assisting all possible editors, and asynchronously, without causing harm in case of problems.

Also, bots and similar tools could be asked to flag all entries where they changed values with |-, and prefix all parameters where they added information with |~ (or at least those where potentially inaccurate info was added - this should never happen in the first place, but we all know that in reality it happens quite often at least with some bots/tools). Parameters prefixed with |~ would be ignored by the citation template, except for, perhaps, populating a maintenance category, and, possibly, show up in preview already (but framed somehow). Editors working on the article and improving citations would simply have to remove the prefixes after reviewing them.

Thereby, it would be much easier for humans to identify bot edits for review (also long after the fact when it might no longer be listed among the recent edits in the edit history) and to double-check some additions before they go live. It would take some time for this new process to trickle through, but since it's technically optional the transition would be smooth and the situation would gradually improve with each new bot/tool adopting it.

IMO, this could solve many problems with Citation Bot and similar overambitious tools by allowing them to make suggestions instead of actually carrying out the edits and often messing up citations. Even if the concept would not be adopted community-wide, it could still be used by those who decide to use it.

For readers, the |- idea would have no visible impact at all, whereas |~ prefixed information would only become visible with some delay. But for anyone looking at the source code (or preview), the scheme would be completely transparent.

I see this as kind of an informal but formalized and thus machine-readable light-weight communication and process model which can be voluntarily adopted by anyone to ease the normal communication and ad-hoc citation improvement process among human editors and bots (instead of leaving HTML comments, having to discuss temporary details on talk pages, or fighting against each other).

--Matthiaspaul (talk) 14:39, 3 September 2020 (UTC)

Further extending the notation of using |- (or |? or |~) prefixes, it would also be possible to mark parameter values, which have been verified by humans already, with a |+ (or even a |!) prefix. At the same time this could be used as a flag to tell bots to leave a particular parameter alone, like |+author-last=Gray. This would hardly be necessary for all given parameters in a template, but could be convenient to have if a known correct value will likely (or has already) trigger(ed) false alarms (like a name including what appears to be a typo but isn't). In contrast to a HTML comment, it would be shorter and machine-readable. As a template-wide "global" feature applicable to all parameters this could be coded with minimal overhead.

If the |- prefix would be used for to-be-checked parameter values, |~ could be conveniently used for bot-added values, or vice versa.

--Matthiaspaul (talk) 20:49, 3 September 2020 (UTC)

Following up on this idea, we had a discussion about empty parameters in a (somewhat related) thread about unknown parameters, and it turned out that some users see empty parameters as clutter that should be removed (some don't) whereas others use empty parameters as reminders and hints to point themselves and other editors to some important but still missing information in a citation.

I belong to the second group but can also understand the former when a citation contains a lot of empty parameters which have not been placed there deliberately but simply by stuffing some empty default template into an article which was never filled out.

I think, my above proposal for template-wide supported parameter prefixes like |-, |+ and |~ could be utilized to solve this dilemma as well:

Following the proposal, prefixing a parameter with |- would indicate "this parameter value needs to be reviewed" to other editors, so, if, by the same principle, an editor would prefix an empty parameter with |- this would mean "Hey, I'm deliberately adding this empty parameter here because this missing information should be part of this citation, therefore please review and possibly add the info if you can". Example: |-author=. Once an editor adds the missing info, he would remove the parameter prefix again. Example: |author=John Doe.

Further spinning this example for illustration purposes, another editor might come around who finds this name suspicious and consequently would set it to |-author=John Doe, thereby telling other editors "Hey, this name looks fishy to me and might be a placeholder rather than the correct name, but I can't prove it right now. Please review if you can". Later, another editor would stop by and scrutinize the citation, and if s/he finds that the value is correct as it is, s/he would either remove the prefix again or, if it is likely that the value will stir up questions again, indicate that the value has been verified to be correct |+author=John Doe, thereby telling other editors "Yeah, this doesn't look right, but I verified it and this particular author is actually named John Doe. Everything is fine". Something along this line...

Now, if this review scheme would be communicated and gradually adopted by more and more editors, we could allow editors and bots to remove all empty parameters which have not been prefixed, because it would be easy for the editor who deliberately added a few empty parameters to prefix them with |- in order to avoid their removal.

Thereby we could address both scenarios at the same time without causing damage, improve the interaction between editors and bots, making their collaboration more efficient and less stressful, and effectively increase the quality of citations with less communication overhead.

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

name-given= and -surname parameter variants

Following up on the recent thread Help_talk:Citation_Style_1/Archive_69#subject-link=_and_subject-mask=, I have gone through the list of supported name parameters.

In the parameter sets for |author=, |contributor=, |editor=, |interviewer=, |subject= and |translator= we generally support |-first=, |-last=, |-given=, |-surname=, |-link= and |-mask= variants and their enumerated forms. (Some combinations also exist in non-hyphenated variants for legacy support, see below.)

I noticed the following irregularities:

• |interviewerlink= and |interviewermask= were unsupported and unused but were still listed as supported in the Whitelist.
• |author-/interviewer-/-given/-surname= as well as their numbered variants were missing from the set.
• |display-subjects= as an alias for |display-authors= was missing from the set.

I have therefore removed support for the first two parameters and added the missing variants, so that we now have a fully symmetrical list of name parameters, making it easier to document and use them without having to look up which exact variants are supported by which group. |subject= is special as it (apparently deliberately?) does not support any of the |-first=, |-last=, |-given= and |-surname= variants. In addition to this, |author= and |editor= also support several non-hyphenated forms for legacy support, but it is good to know that at least |contributor=, |interviewer=, |subject= and |translator= are free of them now.

For the records, these non-hyphenated aliases are used only a few times and could be cleaned up and deprecated as well:

• insource:/| *editor[0-9]*mask[0-9]* *=/: [3] (~96 -> 0)
• insource:/| *displayeditors *=/: [4] (137 -> 0)

--Matthiaspaul (talk) 21:54, 10 September 2020 (UTC)

This editormask does not time out. 87. --Izno (talk) 19:48, 11 September 2020 (UTC)

@Izno, do you have a reliable Cirrus search pattern to determine the exact number of articles containing cite templates including a |nocat= parameter (a parameter name unfortunately also used by various other templates in huge numbers, whereas the usage number in citation templates is probably very small)? I came up with insource:nocat insource:/\{\{ *[cC]it[ea][^|]*\|[^n]*nocat *=[^}]*}}/ [5] but this could still be fooled. --Matthiaspaul (talk) 21:00, 11 September 2020 (UTC)

It's not 0, certainly; Alabama has name="mlvguh">{{cite Earth Impact DB |name= Wetumpka |accessdate =August 20, 2009 |nocat=1}}</ref>. Upper bounds is probably in the realm of 1300. --Izno (talk) 01:08, 12 September 2020 (UTC)

Of the set of non-hyphenated editor-related parameters, only |editorlink= (and enumerated variants) has a large number of hits at all, so we can deprecate the others:

• |editorfirst=: [6] (~0/~0)
• |editorlast=: [7] (0/~0)
• |editorgiven=: [8] (0/0)
• |editorsurname=: [9] (0/0)
• |editorlink=: [10] (3499/~3556)
• |editormask=: [11] (0/(2))
• |displayeditors=: [12] (0/27)

So, we are almost there that, among the name-related parameters, only the group of author-related parameters are using non-hyphenated parameter variants in really huge numbers any more (which, at least, is easy to remember) — too much to fix them up any time soon without bot assistance.

--Matthiaspaul (talk) 14:05, 16 September 2020 (UTC)

Actually, even in the group of author-related parameters, only some of them are used:

• |authorfirst=: [13] (~1/~2)
• |authorlast=: [14] (~1/~2)
• |authorgiven=: [15] (~0/~0)
• |authorsurname=: [16] (~0/~0)
• |authorlink=: [17] (~66730/~91681)
• |authormask=: [18] (~1939/~2125)
• |displayauthors=: [19] (2774/3145)

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

I think that the usage numbers of the non-hyphenated |editor[0-9]link[0-9]=, |author[0-9]mask[0-9]=, and |displayauthors= parameter aliases are already low enough to set these parameters to "deprecated" while continuing to fully support them (despite the deprecation maintenance message) for another year or however long it takes to reduce their numbers, so that editors will gradually switch them to their hyphenated forms when they edit the corresponding articles.

Would this be acceptable for |author[0-9]link[0-9]= (non-hyphenated) as well, or would we first have to reduce the much higher usage numbers considerably?

--Matthiaspaul (talk) 14:48, 17 September 2020 (UTC)

• editorfirst, editorlast, editorgiven, editorlast, editormask, displayeditors, authorfirst, authorlast, authorgiven, authorsurname are indeed ~0.
• editorlink#* 3.4k + editor#+link 140 ~ 3.5k uses.
• authorlink#* ~253k + author#+link ~1.2k ~ 255k uses.
• authormask#* ~2.1k + author#+mask ~10 ~ 2.1k uses.
• displayauthors 2.8k (same link).
• I see no harm in deprecating/removing the practically-unused ones. You should consider working through the parameter names in the template space as well for templates which implement these templates as a passthrough.

I think you can sell me on deprecating the others besides authorlink. 255k is not a number I want to drop in the deprecated pile. --Izno (talk) 05:52, 19 September 2020 (UTC)

Okay. I share your view in regard to this and consequently have set the three aliases (including their enumerated variants) to deprecated but left authorlink for it still has way too many active uses. The other aliases, which are already at 0 hits, were already disabled.

--Matthiaspaul (talk) 16:07, 19 September 2020 (UTC)

transcript

|transcript=, |transcript-format=, |transcripturl=, and |transcript-url= are unique to {{cite av media}} and {{cite episode}} I have moved them to the unique_arguments{} table in the whitelist sandbox.

—Trappist the monk (talk) 19:02, 11 September 2020 (UTC)

Should these be available for {{cite speech}}, {{cite serial}}, {{cite podcast}}, {{cite interview}}? --Izno (talk) 19:42, 11 September 2020 (UTC)

That could be done. There has been some interest for supporting these parameters in {{cite podcast}} but that apparently fizzled for who-knows-why.

—Trappist the monk (talk) 21:52, 11 September 2020 (UTC)

{{cite serial}} documentation says it supports transcript-url.

Following up on the stupid questions, I wonder why we have so many templates like this. cite av media should cover most of them (and perhaps a new cite online av media to cover cite podcast requirement for a URL, if that really is necessary). (Also also, I know that it will apparently take an act of God to get people to agree that a serial and an episode are actually the same thing.) --Izno (talk) 05:59, 19 September 2020 (UTC)

error category names standardization

I think that all cs1|2 error categories should have consistent naming as we have done for maintenance cats. We have standardized on CS1 errors: <descriptor> as a naming convention. This is a list of existing non-standard error categories, their page counts, and proposed replacements:

• Category:Pages using citations with accessdate and no URL (0) → Category:CS1 errors: access-date without URL
• Category:Pages with archiveurl citation errors (0) → Category:CS1 errors: archive-url
• Category:Pages with URL errors (0) → Category:CS1 errors: URL
• Category:Pages with citations having bare URLs (0) → Category:CS1 errors: bare URL
• Category:Pages with citations lacking titles (0) → Category:CS1 errors: missing title
• Category:Pages using web citations with no URL (0) → Category:CS1 errors: web cite without URL Category:CS1 errors: requires URL
• Category:Pages with empty citations (0) → Category:CS1 errors: empty citation
• Category:Pages using citations with format and no URL (0) → Category:CS1 errors: format without URL
• Category:Pages with citations using unsupported parameters (0) → Category:CS1 errors: unsupported parameter
• Category:Pages with citations having redundant parameters (0) → Category:CS1 errors: redundant parameter
• Category:Pages with citations using unnamed parameters (0) → Category:CS1 errors: unrecognized text

additions:

• Category:CS1 maint: unfit url (0) → Category:CS1 maint: unfit URL

I don't think that it matters how many articles are listed in a category; if this change is accepted, old cats will depopulate as articles wend their way through the job queue until empty and new cats will populate in the same manner.

Any reasons we shouldn't do this? Better cat descriptors?

—Trappist the monk (talk) 13:33, 12 September 2020 (UTC) 00:49, 14 September 2020 (UTC) (addition) 14:16, 14 September 2020 (UTC) (better name)

A minor point re unsupported parameters. This may imply a parameter supported elsewhere in the system, such as the template-specific parameters you discussed above. Unknown parameters may be better described as "unrecognized" (by the system), and would be obviously unsupported. 64.18.9.247 (talk) 20:43, 12 September 2020 (UTC)

It is good that you bring this up, I was about to ask the very similar question if these two category naming schemes would serve a purpose or should be harmonized. I was also about to propose to change the non-hyphenated parameter names |archiveurl= and |accessdate= to their hyphenated variants in the category names. Therefore, full support.

In your list of proposed new names above, one category uses "citation" another "cite", I would prefer both of them using "citation".

There are two more category names that might need touches:

• Category:CS1 maint: unfit url (0) → Category:CS1 maint: url-status=unfit
• Category:CS1 maint: BOT: original-url status unknown (0) → Not sure why this includes "original", wouldn't this be better something like Category:CS1 maint: BOT: url-status=unknown or even just Category:CS1 maint: url-status=unknown?

--Matthiaspaul (talk) 07:50, 13 September 2020 (UTC)

Category:CS1 maint: url-status=unfit suggests that the category is only for those articles that have cs1|2 templates using |url-status=unfit. Category:CS1 maint: unfit url also holds articles that have cs1|2 templates that use |url-status=usurped. cs1|2 does not distinguish one from the other as humans do.

Category:CS1 maint: BOT: url-status=unknown and Category:CS1 maint: url-status=unknown suggest that there is a valid parameter/keyword pair |url-status=unknown; there is not. The BOT: part of that category name is to suggest that bots using, |url-status=bot: unknown, are responsible for adding articles to the category. The primary (only?) bot using this is InternetArchiveBot.

and are the only error messages that use 'cite'. In Category:CS1 errors: web cite without URL, 'web cite' is intended as a stand-in for 'cite web' and 'cite podcast', both of which populate this category. refers to the rendered citation, not to the cs1|2 template – which may not be empty (this from Jinn):

{{یادکرد وب|نام خانوادگی= Omidsalar|نام= Mahmoud|پیوند نویسنده= محمود امیدسالار|عنوان= GENIE|نشانی= http://www.iranicaonline.org/articles/genie-|بازبینی= ۱۵ آوریل ۲۰۱۲|اثر= |تاریخ= ۱۵ دسامبر ۲۰۰۰|ناشر= [[دانشنامه ایرانیکا]]|نشانی بایگانی= https://web.archive.org/web/20110429185114/http://www.iranicaonline.org/articles/genie-|تاریخ بایگانی= ۲۹ آوریل ۲۰۱۱|کد زبان= en|dead-url= no}}

{{cite web}}: Empty citation (help)

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

Regarding "unfit", I see your point, but then the message refers not to one of the parameters (lowercase url), but to the abbreviation URL (Uniform Resource Locator), hence should be uppercased:

Category:CS1 maint: unfit url → Category:CS1 maint: unfit URL

Regarding Category:CS1 maint: BOT: original-url status unknown (0), perhaps it is just me, but to me the current category name is somewhat cryptic. What does "original" mean here specifically? If this is related to the parameter, |url-status= should be hyphenated. If this is not related to the parameter but to URLs, the abbreviation should be uppercased. (On a different note: Why did we name the value "bot: unknown" rather than just "unknown"?)

Regarding "cite" vs. "citation", not sure if using 'web cite' as stand-in for 'cite web' and 'cite podcast' really works (at least the intended association doesn't work for me). Perhaps Category:CS1 errors: web cite without URL → Category:CS1 errors: web-related citation without URL

--Matthiaspaul (talk) 18:44, 13 September 2020 (UTC)

I've added Category:CS1 maint: unfit URL to the list.

Yeah, it is a bit cryptic but that is why we have documentation at the category. If the documentation isn't sufficient to decrypt the meaning, then tweak the documentation. When rendered, the url that is replaced by an archive url is the original url:

{{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2020-09-13}} → Title. Archived from the original on 2020-09-13.

One place to start for the history of bot: unknown starts at User talk:Cyberpower678/Archive 36#alternate |dead-url= keyword.

Just about any cs1|2 template can be considered 'web related' if it has a url. This cat is for those templates that require a url. Perhaps drop the 'web' and say Category:CS1 errors: requires URL. This cat also applies to {{cite mailinglist}}.

—Trappist the monk (talk) 00:49, 14 September 2020 (UTC)

Category:CS1 errors: requires URL is straight to the point. Perfect.

Thanks for the pointer to the history of |url-status=bot: unknown. Makes a lot of sense to have the keywords based on semantics/purposes (my saying as well). Still, it always kind-of-strikes me as odd when I see this bot: in citations (probably, because this is a one-off syntactical concept rather than something used in other parameters as well). If we had to introduce this today I would probably suggest a hyphen-affixed bot- prefix (like in |url-status=bot-unknown) or would try to embed this into the more general parameter review scheme proposal (similar to |~url-status=unknown). Although, in the current version of that proposal, this would not change the linking behaviour and just put the citation into some special category, so that, for the link to be suppressed (as with bot: unknown), that proposal would have to be adjusted/extended somewhat. Something to think about...

--Matthiaspaul (talk) 13:01, 14 September 2020 (UTC)

Question, isn't "Category:CS1 errors: bare URL" the same error as "Category:CS1 errors: missing title"? Those don't seem to be independent. AFAICT, the first is missing titles when there's a URL, the second is missing titles regardless of if there is a URL. Headbomb {t · c · p · b} 16:02, 13 September 2020 (UTC)

Also "web cite" should be "cite web" or "web citation". Headbomb {t · c · p · b} 16:03, 13 September 2020 (UTC)

Category:Pages with citations having bare URLs collects articles that have cs1|2 templates that have a url-holding parameter without its matching title-holding parameter: |chapter-url= without |chapter=:

{{cite book |title=Title |chapter-url=//example.com}} → //example.com. Title. {{cite book}}: |chapter-url= missing title (help)

Category:Pages with citations lacking titles – collects articles that have cs1|2 template that do not have any of |title=, |trans-title=, and |script-title= (no main-title parameter):

{{cite book |chapter=Chapter}} → "Chapter". {{cite book}}: Missing or empty |title= (help)

Should not be 'cite web' because that category also applies to {{cite podcast}}.

—Trappist the monk (talk) 18:09, 13 September 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= [20] 0
• |no-cat= [21] 0 (2 uses in non-citation templates)
• |nocat= >=2 Paleocene Alabama (>15k uses in non-citation templates)
• |no-tracking= [22] 0
• |notracking= [23] 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 *=/ [24].

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)

O wicked wall, through whom I see no bliss!

Pyramus in Shakespeare's A Midsummer Night's Dream Act 5, Scene 1

Yesterday I thought to create a common function to handle accept-as-written markup. There are several places in Module:Citation/CS1/sandbox that detect and strip that markup so starting at the top of the module and working down, I replaced each independent detect-and-strip with a call to the new function, testing as I went. Worked great until I got to citation0() and bam! ran straight into a wall at full speed.

Lua has a built-in, unalterable limit of 60 upvalues. Roughly speaking, an upvalue is anything in a module that has the same scope as the function in question and is directly used by the function. In ~/sandbox, there are some 61 functions that may be used by citation0() (not all of them are directly used). Additionally there are 24 functions held in various other modules (most of them used by citation0()) that count against the upvalue limit.

We have been close to this limit for some time. Since the last update, ~/sandbox has gotten two new functions, list_make() and is_generic_title(), and one new table auto_link_urls{} and dropped the function is_embargoed(). At the time that I hit the wall, we were sitting right at an upvalue count of 60.

So, what to do? For the nonce, I have taken the cheap and easy way out. The 24 functions held in various other modules were declared as local names to make life a bit easier so, for example, Module:Citation/CS1/Utilities/sandbox has a very commonly used function is_set(). To make that easier to type, the cross-module name utilities.is_set was mapped to a local name is_set. I have changed all of the remapped names to their cross-module names. Doing that reduced the upvalue count by 20 (I believe – not tested). There were 24 functions from four modules so should be 20.

citation0() is an enormous beast. It can be reorganized and split into multiple sections which is something that I have wanted to do for a long long time. But it isn't an easy task so I have been putting it off and putting it off ... 'O wicked wall...'

—Trappist the monk (talk) 15:18, 13 September 2020 (UTC)

I appreciate your dedication to these modules, Trappist, and I have confidence that these stony limits will not thwart you.
With love's light wings did I o'er-perch these walls, for stony limits cannot hold love out. – Jonesey95 (talk) 15:34, 13 September 2020 (UTC)

Best wishes of recovery from hitting that wall. ;-)

Regarding ((syntax)) detection, it happens that I planned for today to add ((accept-this-as-it-is)) detection code at the beginning of the identifier evaluation code, unconditionally stripping of the parentheses whenever they exist (that is, regardless of identifier parameter) and recording a flag on which the code further down would act in the cases of the identifiers which can make use of it already, like the ISBN and DOI examples. The idea for this was to not introduce the detection and stripping code for each identifier individually in order to avoid unnecessary code repetition.

Of course, this could be further generalized by running the ((syntax)) detection and stripping code over all parameters, keep record of the results alongside the parameters for later evaluation in the code dealing with the individual parameters supporting this feature. For all other parameters, the corresponding flag would just be ignored. This works on the assumption that a usage of ((syntax)) in the outside world can be basically ruled out in any context even remotely related to citation-related information, and that it is very unlikely that the ((syntax)) would be applied by a user in a parameter not supporting the feature, but if a user would apply it anyway, the parentheses would silently be stripped off and the template would behave as if they would not have been provided in the first place. This would reduce the number of instances where the detection code would have to be invoked to one (or at most very few places) making it unnecessary to even implement it as a subroutine (except for that it looks nicer).

--Matthiaspaul (talk) 20:15, 13 September 2020 (UTC)

Regarding accept-as-written markup, I am still under the firm belief that should not be expanded, and I have not seen an active consensus that it should even be in use today (even, TBH, for organizational authors in Vancouver--instead we should support that use case directly as I have mentioned elsewhere). We are not tracking it today (though we should tomorrow for where we do provide it), and I would guess it is hiding some articles best unhidden. --Izno (talk) 06:16, 19 September 2020 (UTC)

Should removed parameters be in the list of suggestions?

Recently, Matthias has added support in the suggestions list to parameters that have been removed, listing a few related discussions but none which directly cite a decision to support parameters that are removed. Is this something we want to do? I am not generally in support of it -- we've removed the parameters from support, so why are we continuing to support them? --Izno (talk) 18:22, 16 September 2020 (UTC)

Removed parameters are not supported, AFAICT. We are helping editors fix their errors instead of simply showing an error message. "Title". {{cite web}}: Unknown parameter |werk= ignored (|work= suggested) (help). Or perhaps I misunderstand what is at issue. – Jonesey95 (talk) 19:42, 16 September 2020 (UTC)

The suggestions module indeed provides suggestions. By "support" I mean "we have modules that will provide that suggestion when we have chosen deliberately to remove the attributes in question". (I'm sure also that we pay some non-zero price for the suggestions list.) Prior to Matthias's changes, I'd classify the set in this way: misspellings and translations. These additions are not really in keeping with what was in there prior, and I'd like an affirmative agreement that "yes, we want to continue to provide some moderate level of support for these". The point of deprecation and removal is to say "no, we don't want to continue to support these". --Izno (talk) 21:23, 16 September 2020 (UTC)

We did this before as well, but perhaps only occasionally (f.e. |trans_title=).

The reason I added the removed parameters to the suggestion list is that despite our efforts to clean them up at least in mainspace, they occasionally show up (again) and I think it is desirable to make the transition as smooth as possible and give editors a hint on the new parameter if there is a replacement (the CS documentation lists recently deprecated parameters, but not older ones, so editors might be clueless running into them - like I was for a moment running into |laysummary= recently). In some sense, these can be considered "misspellings", but I would also classify them as "former parameters". I think it is important to document their type in the comments (this might be helpful when the current list might need to be turned into a more complex table with various flags in the future). In the case of old parameters, it might even make sense to record the date of deprecation, so this can be reevaluated a couple of years later.

I was living under the impression that this part of the code is only executed when the main code has detected an unsupported parameter already, issuing an error message. So, it doesn't affect the performance of well-maintained citations. Also, for cleanness of code it is important to get rid of any traces of former parameters from the main modules, but in the suggestion module, it doesn't harm to keep mentioning them (in fact, I think, it is improving the list if they are mentioned).

--Matthiaspaul (talk) 10:07, 17 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)

Access dates sometimes superfluous

"Access dates are not required for links to published research papers, published books, or news articles with publication dates."

With regard to the last of those, bear in mind that news articles are often revised some time after publication, and the date of revision (along with the reason/s for doing so) will be noted in the text. Additionally, my own experience suggests that even though the content of an article may not be revised, revisiting an article some years after publication can result in the discovery of a very different headline from the one noted in the citation, filled out earlier in the article's existence. Harfarhs (talk) 22:30, 18 September 2020 (UTC)

I agree. It's not even remotely uncommon for news articles to be updated, and thus potentially no longer support content in a Wikipedia article. I think we should remove that last part. Glades12 (talk) 05:00, 19 September 2020 (UTC)

As stated earlier, such articles in the kinds of sources we trust will almost always provide a revision date. News articles with publication dates indeed do not need access dates. --Izno (talk) 05:03, 19 September 2020 (UTC)

That makes no sense, unless you're using |date= for the date of the last update, which I do not. Glades12 (talk) 05:10, 19 September 2020 (UTC)

Why aren't you? :) Just because you aren't, doesn't mean you shouldn't. You don't know what may have changed between the original publication date and the amended date (you should, but you might not), so you should cite the date of the copy you referenced, not an earlier or later date. (Best yet, ensure you always provide an archive URL!) --Izno (talk) 06:11, 19 September 2020 (UTC)

Yes, the date that belongs into the |date= parameter is that of the latest date (of revision) that is known.

However, I, too, have seen quite many online magazine and news articles with sometimes vastly differing headlines and no indication of any revision or revision dates. So, the only specified date may be the original publication or a revision date - without knowing the publication history of an article, a normal reader will never know. Quite shockingly, in recent years I have even seen many online articles which carry no date information at all. So, |access-date= is quite important.

--Matthiaspaul (talk) 07:32, 19 September 2020 (UTC)

This sentence is one of those "guidelineish" pseudo-advices (I complained about here) that crept into our template documentation, but doesn't belong there (it is not a guideline, and shouldn't be one). I take issue with some editors trying to push their personal preferences this way. |access-date= is never required, but optional. (In my opinion it is always desirable to have per WP:V, whereas some editors see it as clutter.) Basically, it is up to the editorial judgement of the editor adding a citation if s/he thinks it is useful in a citation or not. Therefore, let's delete that misleading sentence completely. It has no place in a template's documentation.

--Matthiaspaul (talk) 07:32, 19 September 2020 (UTC)

Place but no publication place

What should you do when the appropriate value for |place= (i.e. the place where a source was written (or otherwise created)) is known, but not |publication-place=? An example is the video Hirokazu Tanaka on Nintendo Game Music, Reggae and Tetris (used at Hirokazu Tanaka), which was recorded in Tokyo, but could have been published at just about any place with a Red Bull office. Glades12 (talk) 05:33, 19 September 2020 (UTC)

Just put it in |place= like everyone else? The distinction, for all intents and purposes, is nil at this point. (That aside, citing the location matters less and less entirely these days for anything of relevant sort from what I have observed.) (Also, Ttm, weren't we going to look at place/pub-place?) --Izno (talk) 06:15, 19 September 2020 (UTC)

I figured that was the best option. Glades12 (talk) 07:16, 19 September 2020 (UTC)

A distinction is made when both |publication-place= and |location=/|place= are used at the same time. Then |location=/|place= becomes a parameter only for the written-at-place.

The names |place= and |location= are unfortunate because of their ambiguity. Therefore we should introduce a new dedicated parameter for the written-at-place, like |written-place=. However, given that |place=/|location= can also be used to specify the publication place for as long as |publication-place= is not present, and some editors have a very bad habit of changing |publication-place= to |place=, existing entries of |place=/|location= cannot be automatically converted into |written-place= (nor |publication-place=), but will, once the new parameter has been introduced, have to be reviewed individually.

This is another place (no pun intended) where too unspecific parameter names are biting us badly.

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

publication place was intended to be that new separate parameter when it was first introduced. (See also XKCD standards strip.) I do not see a benefit, as was discussed sometime in the past year that instituted Category:CS1 location test, to retaining the two separate meanings, where there are ~500 instances of such. Pick one location and be done with it. --Izno (talk) 15:27, 19 September 2020 (UTC)

See also XKCD standards strip. This one?

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

Indeed. --Izno (talk) 17:05, 19 September 2020 (UTC)

Borked?

HI all

Is the template currently broken?

I have used it for a time code in a film, but it seems to be just priting the parameters onto the article text for the viewing public:

Waterworld#Production

(Last paragraph)

Reynolds still received full credit as director.Kevin Reynolds (1995). Waterworld (Film). Universal City Studios, Inc. Event occurs at 02:15:11. Directed by Kevin Reynolds

There are quotation marks around the last iteration of "Kevin Reynolds", but these are not selected when copy/pasting I am going to have to remove access date, as it is asking me for a url for the access date ... of course it came from my brain, as i know what date it is today lol

Reynolds still received full credit as director.Kevin Reynolds (1995). Waterworld (Film). Universal City Studios, Inc. Event occurs at 02:15:11. Directed by Kevin Reynolds |access-date= requires |url= (help)

and now going to hide the whole mess ...

Chaosdruid (talk) 17:47, 19 September 2020 (UTC)

Not wrapped in <ref>...</ref> tags?

— Preceding unsigned comment added by Trappist the monk (talk • contribs) 17:52, 19 September 2020 (UTC)

Yep, that was probably the biggest problem. Jonesey95 shows how to do it (and simultaneously fixes the citation, making this discussion pointless) in this edit. Glades12 (talk) 06:36, 20 September 2020 (UTC)

First/last or given/surname canonical form?

Our recent discussion Help_talk:Citation_Style_1#Guidance_about_indexing_by_first_name? made me think (again) about the best choice for the canonical parameter names of the various name-related parameters. We currently support the variant pairs |first=/|last= and |given=/|surname= for all our name parameter sets |author=, |editor=, |contributor=, |translator= and |interviewer=.

While the first pair (our default) does not create problems for (most) Western names, it actually is ambiguous. Even our citation templates render the names in the order "last, first", something we accept without much thinking because we are so used to it. However, for names not following the Western name order, it is not obvious which part of the name belongs into which parameter, as what is displayed first and last may depend on context.

An alternative concept that works across almost all (Western and Eastern) cultures is to distinguish not the first and the last name, but the given and the family name (which we, somewhat oddly, call surname in our parameter interface, although that would better pair with forename, but anyway).

Since proper semantics are more important for input data than "proper" display order (which can be changed through other means if necessary), I think, we should switch to use |given=/|surname= as our canonical defaults. |first=/|last= would be supported as before, just not be the defaults any more.

The only difference would be that |given=/|surname= would be listed first in the list of alias names, and |first=/|last= a bit later.

The advantage of this minimal change would be that the risk of mixing up the given and family name of names in Eastern name order would be significantly reduced (if not eliminated, except for when they aren't known in the first place) in all new citations entered. Some bots (and probably also VE) would automatically start to use |given=/|surname= rather than |first=/|last= when adding new names to a template.

--Matthiaspaul (talk) 01:52, 20 September 2020 (UTC)

The disadvantage is that first/last (the order in which the parts of the name are presented) is meaningful for patronymic-without-surname systems like the Indian or Icelandic ones, whereas given/surname forces names in those systems into boxes into which they do not fit. —David Eppstein (talk) 05:42, 20 September 2020 (UTC)

Thanks for bringing in this interesting aspect.

According to our article on Icelandic names, they seem to be composed of given name plus surname, with given name and first name referring to the same part of the name. So, it seems as if the entry of Icelandic names would not be negatively affected if we would switch to given/surname (whereas the pair given/family would not fit well).

The article on Indian names, however, mentions many variants and leaves me unconclusive. I have invited the visitors of that article's talk page to share their views on this.

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

You are incorrect. Most Icelandic people do not have a surname. What they have is a patronymic. The differences are (1) that they are not generally called by that name by itself even in formal writing (so in a Wikipedia article about a person using this system we should refer to them by given name rather than by their patronymic, even though we generally refer to people with surnames by their surname), and (2) it is not a family name, passed down from generation to generation, but rather it is just one of the parents' given names (traditionally the father's), suffixed by "son" or "dottir" (same as English "son" or "daughter"). So e.g. Leif Erikson does not mean that Leif was from a family called "Erikson", as it might mean for an American name of similar form; it means that Leif's father had the given name Erik (and full name Erik Thorvaldsson etc). That's a historic example but they still use the same system. So it may seem to you that it is ok to call it a surname, but it really is not a surname and you are imposing your culture on their own in an inappropriate way. It sounds like you need to read https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ . —David Eppstein (talk) 07:50, 20 September 2020 (UTC)

Regarding Icelanding surnames, that's why I wrote given/surname (not given/family name). Our article on Icelandic names uses the term "surname" as well, as do referencing guides such as [25], so, while what you write is correct, the term "surname" can't be wrong either (unless someone would take surname as synonym for family name, which would not be correct for Icelandic names).

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

Horse profile citations

There has been an internal reorganisation of the horse profiles database at Racing Post (formerly at bloodstock.racingpost.com), so a number of citations (probably a couple of thousand, almost all using {{cite web}}) will have to change to match. Fortunately the mapping from the old to the new URLs is straightforward. As I see it, there are three possible approaches:

1. Simply convert all the old URLs to the new URLs, leaving everything else unchanged
2. Create a new template (I've set up a proof-of-concept {{Racing Post horse}}) which would be passed the horse id (a 6-digit number) and use it to construct the URL, and would be attached to the |id= parameter, in the same way as templates such as {{ProQuest}}
3. Create a new specific-source citation template such as {{cite Racing Post horse profile}}, which would build the entire citation given the horse id and the title (similar to {{cite Mountain Project}} and many others)

All of these options involve about the same amount of work, and all could be done by bot or by AWB. My own feeling is that option 1 would be to miss an opportunity to futurepoof these citations, so the only real choice is between options 2 and 3. Because the citations currently use {{cite web}}, option 2 leads to error messages complaining about the lack of a URL. This can be fixed by changing to another citation template such at {{cite journal}}. but is obviously undesirable as the Racing Post database is not a journal. Option 3 seems the best to me, but I'd appreciate input from citation specialists here. (And as a supplementary question: the current citations mostly include parameters |date= and |access-date= - I don't think these are either necessary or beneficial when citing this sort of database and I'm inclined to just discard them - any thoughts?) Colonies Chris (talk) 10:58, 20 September 2020 (UTC)

I would say option three. Use Module:template wrapper so that editors can add whatever {{cite web}} parameters they want to the basic template. {{cite Grove}} is one example of a wrapper template.

—Trappist the monk (talk) 11:53, 20 September 2020 (UTC)

Agreed on option 3, for consistency and flexibility. As far |date= is concerned, this is a bit tricky when it comes to databases. Citing a record (a particular horse profile) is pointing to an in-source location, the source being the database. One should date the database edition/version normally. However, individual records may be revised or updated more often than the database itself and this should be cited too. I would utilize {{citation}}. I would use (clumsily) |date= for the record revision date. I would use |edition= for the database revision/version (this may also be a date). Access dates are not needed in such rendition. This is not perfect but should work, assuming the database is indexed by record-subject+record-revision. 172.254.241.58 (talk) 13:12, 20 September 2020 (UTC)

I see your point, but there doesn't seem to be any sort of date or version id available, either for the database as a whole or for any specific record (see Port Etienne for a typical example). Colonies Chris (talk) 15:28, 20 September 2020 (UTC)

I followed the link you provided (I wonder if there's a profile for Citation (horse)) and the earlier comment should be amended, as this is not a free-standing database. It is a website that includes a breeding/past performance database that may be continuously updated. The source (racingpost.com) is fixed. The horse profile webpage is now the in-source location. In this case |access-date= is apt, as the proper entry for date would be |date=n.d.. This would be awkward in the specific-source template you have in mind, you may want to leave |date= out altogether. The other option involves wading into the source code to figure out the revision date, which is convoluted. And {{cite web}} is now as good or better than {{citation}} as the base template imo. 64.18.9.222 (talk) 03:53, 21 September 2020 (UTC)

Leave a request at WP:URLREQ regardless. --Izno (talk) 13:26, 20 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 ([26]) who reverted ([27][28]) my attempts to correct ([29] [30]) 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 [31]) when a |doi= (pointing to [32]) 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)

Remove period after Magazine name

British motoring magazine What Car? makes for rather silly looking punctuation. How can I best avoid the period after the "magazine" field in template:cite magazine? It currently ends up looking like this: Reference

Thank you,  Mr.choppers | ✎  18:24, 20 September 2020 (UTC)

For easier cross-refs some similar threads:

• Help_talk:Citation_Style_1/Archive_62#Problem_with_"."_separator_in_front_of_work_or_series_info_in_conjunction_with_titles_ending_on_"?"_or_"!"
• Module_talk:Citation/CS1/Feature_requests#Separator_suppression

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

Still broken: title=none + doi-access=free

I am still seeing errors from {{cite journal}} with |title=none + |doi-access=free. I thought this was supposed to be fixed? An example (a book review headed by the name of the book it reviews without having its own separate title):

• Van Osdol, Donovan H. (August 2012). Notices of the American Mathematical Society. 59 (7): 960–961. doi:10.1090/noti875.{{cite journal}}: CS1 maint: untitled periodical (link)

This one, if cited by itself, would not be too ridiculous to make up a fake title like "Magical Mathematics" (the title of the book it reviews). But when it is part of a bulleted list of 15 reviews, all of the same book, all given the same fake title, it just looks ridiculous. And if instead of making up something fake but plausible you copy what appears at the top of each review and pretend it's a title, you get monstrosities like (from a different review of the same book) "Featured Review: Magical Mathematics: The Mathematical Ideas That Animate Great Magic Tricks. By Persi Diaconis and Ron Graham. Princeton University Press, Princeton, NJ, 2012. $29.95. xiv+244pp, hardcover. ISBN 978-0-691-15164-9." So I prefer to omit them, which per WP:CITEVAR should be a perfectly acceptable citation style that the templates support. Adding a little lock icon to the doi shouldn't change anything about that.

To put it more bluntly, the autolinking RFC did not address citations with no title, and did not have consensus for imposing a new requirement that all journal citations list a title. Therefore, it should not have been implemented in a way that implicitly imposed such a requirement. —David Eppstein (talk) 21:45, 20 September 2020 (UTC)

Another use for this that I'm seeing, in trying to clean up these errors in existing articles, is when a publication with a normal title is reprinted in another source and the citation refers to both copies. It is typical to omit the title for the second reference, but this is now broken when the second copy would autolink. An example, from Pioneer anomaly:

• Fienga, A.; et al. (2009). "Gravity tests with INPOP planetary ephemerides" (PDF). Proceedings of the Annual Meeting of the French Society of Astronomy and Astrophysics: 105–109. Bibcode:2009sf2a.conf..105F. Archived from the original (PDF) on 2011-07-20. Also published in Proceedings of the International Astronomical Union. 5: 159–169. 2010. arXiv:0906.3962. Bibcode:2010IAUS..261..159F. doi:10.1017/S1743921309990330.{{cite journal}}: CS1 maint: untitled periodical (link)

—David Eppstein (talk) 22:29, 20 September 2020 (UTC)

Cite the copy that was read per SAYWHERE. If they are the same for the fact of interest, cite the one more likely to be accessible for the common user. (Or, fill in the details and then use e.g. |authormask=.) --Izno (talk) 02:22, 21 September 2020 (UTC)

Your opinion on how you would have chosen differently which of multiple versions to cite in this instance is noted but not particularly relevant to a problem that concerns other editors being unable to format citations in the way that they prefer. And especially irrelevant because whoever actually made that choice, in this instance, is nowhere in sight to be lectured to about how their preference is wrong. —David Eppstein (talk) 06:27, 21 September 2020 (UTC)

It's fixed in the sandbox. As always, the issue is that this template is treated like it will cause the financial markets to crash if it's updated more than thrice a year. Headbomb {t · c · p · b} 22:31, 20 September 2020 (UTC)

As I have specifically said before, establish that consensus should be otherwise. Thanks. --Izno (talk) 02:22, 21 September 2020 (UTC)

Where is the consensus that it should be this way to begin with. This update schedule is the result of one person's preference for that update schedule and the template being locked behind an admin and LUA barrier. Headbomb {t · c · p · b} 21:55, 21 September 2020 (UTC)

WP:REDLOCK and Wikipedia:High-risk templates and WP:STATUSQUO. I see no reason to disrupt the release pace. If you believe it should be faster, you may establish a consensus for that position at your leisure. --Izno (talk) 23:38, 21 September 2020 (UTC)

How about fixing a thing that is broken. WP:PERF applies. WP:REDLOCK doesn't. The fix is tested. It works. It should be deployed. Headbomb {t · c · p · b} 03:07, 22 September 2020 (UTC)

As Headbomb wrote, the sandboxed version looks like this:

• Van Osdol, Donovan H. (August 2012). Notices of the American Mathematical Society. 59 (7): 960–961. doi:10.1090/noti875.{{cite journal}}: CS1 maint: untitled periodical (link)
• Fienga, A.; et al. (2009). "Gravity tests with INPOP planetary ephemerides" (PDF). Proceedings of the Annual Meeting of the French Society of Astronomy and Astrophysics: 105–109. Bibcode:2009sf2a.conf..105F. Archived from the original (PDF) on 2011-07-20. Also published in Proceedings of the International Astronomical Union. 5: 159–169. 2010. arXiv:0906.3962. Bibcode:2010IAUS..261..159F. doi:10.1017/S1743921309990330.{{cite journal}}: CS1 maint: untitled periodical (link)

David, isn't this fixing the reported issue?

Related threads:

• Help_talk:Citation_Style_1/Archive_70#New_autolinking_of_free_dois_breaks_citations_that_deliberately_omit_title
• Help_talk:Citation_Style_1/Archive_70#Towards_solving_pending_issues_of_the_auto-link_feature...
• Help_talk:Citation_Style_1#Proceeding

Assuming a normal schedule for rollout, the update would probably happen on the weekend of the 2020-10-10/11.

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

Is there a good reason for having left it in a broken state for four months and for continuing to leave it in a broken state for another month, all the while bots continue to break more citations because of this? —David Eppstein (talk) 22:06, 21 September 2020 (UTC)

None but the belief that Wikipedia servers will be unhappy if we fix things. Headbomb {t · c · p · b} 03:08, 22 September 2020 (UTC)

I don't mean to ask even more from those who tirelessly work on these templates, but any willing sysop is free to publish the fixes from the sandbox. WMF sysadmins have said it's fine to update the templates more frequently, preferably during business hours (EU/USA time). Nemo 13:56, 22 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 ([33]), 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)

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 (54,015) 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,832,335 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)

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