Help talk:Citation Style 1/Archive 71

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)

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), e.g. 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 ([25]) 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.
  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)

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)

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

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 e.g. 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: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 (e.g. 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 (e.g. 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)

The RfC on title-linking was concluded yesterday. A

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)

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)

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

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:

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

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
  )

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.

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

b

} 20:32, 1 October 2020 (UTC)

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.

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,340) 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

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)

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)

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)

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

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)