Help talk:Citation Style 1/Archive 71

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

Archive 65

←

Archive 69

→

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:

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)

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:

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.

Cite uses generic title and Cite has empty unknown parameter$1: $2 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. Empty citation 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}}

Omidsalar, Mahmoud (۱۵ دسامبر ۲۰۰۰). "GENIE". دانشنامه ایرانیکا. Archived from the original on ۲۹ آوریل ۲۰۱۱. Retrieved ۱۵ آوریل ۲۰۱۲. {{cite web}}: Check date values in: |access-date=, |date=, and |archive-date= (help); Unknown parameter |dead-url= ignored (|url-status= suggested) (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)

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

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)

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)

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)

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?

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 [1], 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:

Simply convert all the old URLs to the new URLs, leaving everything else unchanged
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}}
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)

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:^[1] Reference

^ "2012 Ford B-Max Overview". What Car?. Retrieved 2012-10-28.

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

For easier cross-refs some similar threads:

--Matthiaspaul (talk) 20:25, 20 September 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.

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]* *=/: [2] (~96 -> 0)
insource:/| *displayeditors *=/: [3] (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 *=[^}]*}}/ [4] 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 |no-tracking=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=: [5] (~0/~0)
|editorlast=: [6] (0/~0)
|editorgiven=: [7] (0/0)
|editorsurname=: [8] (0/0)
|editorlink=: [9] (3499/~3556)
|editormask=: [10] (0/(2))
|displayeditors=: [11] (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=: [12] (~1/~2)
|authorlast=: [13] (~1/~2)
|authorgiven=: [14] (~0/~0)
|authorsurname=: [15] (~0/~0)
|authorlink=: [16] (~66730/~91681)
|authormask=: [17] (~1939/~2125)
|displayauthors=: [18] (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)

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:

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)

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= [19] 0
|no-cat= [20] 0 (2 uses in non-citation templates)
|nocat= >=2 Paleocene Alabama (>15k uses in non-citation templates)
|no-tracking= [21] 0
|notracking= [22] 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)

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, e.g. 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= (|url-status= requires |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 ([24]), 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 Text "$1" ignored 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)

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.

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

Put the parentheticals where they belong – putting (in Lang) after a series, journal or edited book is clearly wrong.
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)

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

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

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

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.

Title. 1881–86. (invalid per MOS except where "where space is limited"; accepted by CS1)
Title. 1881–886. {{cite book}}: Check date values in: |date= (help) (invalid per MOS, error in CS1)
Title. 1881–6. {{cite book}}: 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. {{cite book}}: Check date values in: |date= (help) (invalid per MOS, error in CS1)
Title. 1881–2. {{cite book}}: Check date values in: |date= (help) (invalid per MOS, error in CS1)
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)

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:

The appropriate identifier parameter ... is more stable
The appropriate identifier parameter ... may allow to specify the access status
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
(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:

Does the functional impact, as currently experienced by readers, of the parameter exactly duplicate another parameter?
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?
Is the parameter free or behind a paywall?
Is the link dead? If yes does it make sense to rename it to a different parameter in keeping with question 2?
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. Le v!v ich 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)

--Matthiaspaul (talk) 18:58, 27 September 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)

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

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.

Module suite update 10–11 October 2020

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

Module:Citation/CS1:

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

Module:Citation/CS1/Configuration

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

Module:Citation/CS1/Whitelist

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

Module:Citation/CS1/Date validation

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

Module:Citation/CS1/Identifiers

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

Module:Citation/CS1/Utilities

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

Module:Citation/CS1/styles.css

Remove PNG icons as WMF dropped basic support for IE8

Module:Citation/CS1/Suggestions

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

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

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

I think the list includes Editor Matthiaspaul's changes.

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

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

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

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

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

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

Error messages for generic titles

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

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

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

It's that whole visibility thing isn't it? If editors don't know that the errors are there they won't know that something needs fixing. Why does Category:CS1 maint: archived copy as title (53,322) 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,929,563 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)

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

[1] "2012 Ford B-Max Overview". What Car?. Retrieved 2012-10-28.

[1]