Help talk:Citation Style 1: Difference between revisions

Browse history interactively ← Previous edit Next edit →Content deleted Content addedVisual WikitextInline

Revision as of 18:30, 20 August 2021 editTrappist the monk (talk \| contribs)Administrators480,028 edits →non-English translator templates and substing ← Previous edit		Revision as of 01:47, 21 August 2021 edit undoBrownHairedGirl (talk \| contribs)Autopatrolled, Extended confirmed users, File movers, Pending changes reviewers, Rollbackers2,942,733 edits →Permanent errors: new sectionNext edit →
Line 1,203:		Line 1,203:
	:::Discussion about the change to ] is at {{slink\|Module_talk:Unsubst\|template_invocation_name_override}}.		:::Discussion about the change to ] is at {{slink\|Module_talk:Unsubst\|template_invocation_name_override}}.
	:::—] (]) 18:30, 20 August 2021 (UTC)		:::—] (]) 18:30, 20 August 2021 (UTC)

			== Permanent errors ==

			::''Note: I originally posted this at ], but moved it here 'cos I think this is a more appropraite location.''

			] includes 22 pages in the Misplaced Pages namespace: 14 AFD pages, and 8 pages from the Signpost.

			These pages should not be edited, so they are perma-clutter in this cleanup category.

			Please can the CS1/2 module(s) be modified to stop categorising citation errors in these pages? Cleanup categories should be capable of being fully cleaned up, but these pages prevent that. --] <small>] • (])</small> 01:47, 21 August 2021 (UTC)

Revision as of 01:47, 21 August 2021

This is the talk page for discussing improvements to the Help:Citation Style 1 and the CS1 templates page.

Put new text under old text. Click here to start a new topic.
New to Misplaced Pages? Welcome! Learn to edit; get help.

Shortcut

WT:CS1

Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97Auto-archiving period: 30 days

To help centralize discussions and keep related topics together, the talk pages for all Citation Style 1 templates and modules redirect here. A list of those talk pages and their historical archives can be found here.

This help page does not require a rating on Misplaced Pages's content assessment scale.
It is of interest to multiple WikiProjects.

Misplaced Pages Help High‑importance

	This page is within the scope of the Misplaced Pages Help Project, a collaborative effort to improve Misplaced Pages's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Misplaced Pages HelpWikipedia:Help ProjectTemplate:Misplaced Pages Help ProjectHelp
High	This page has been rated as High-importance on the project's importance scale.

Academic Journals

This page is within the scope of WikiProject Academic Journals, a collaborative effort to improve the coverage of Academic Journals on Misplaced Pages. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Academic JournalsWikipedia:WikiProject Academic JournalsTemplate:WikiProject Academic JournalsAcademic Journal

Magazines

	This page is within the scope of WikiProject Magazines, a collaborative effort to improve the coverage of magazines on Misplaced Pages. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.MagazinesWikipedia:WikiProject MagazinesTemplate:WikiProject Magazinesmagazine
See WikiProject Magazines' writing guide for tips on how to improve this article.

Other talk page banners

Some of the templates discussed here were considered for merging or deletion at Misplaced Pages:Templates for discussion. Please review the prior discussions if you are considering re-nomination:

"Withdrawn" proposal to merge Template:Cite press release with Template:Cite news on March 2, 2018, see discussion.

Text has been copied to or from this page; see the list below. The source pages now serve to provide attribution for the content in the destination pages and must not be deleted as long as the copies exist. For attribution and to access older versions of the copied text, please see the history links below.

Copied pages:

Copied Template:Cite_book (oldid, history) → incubator:Template:Wp/nod/cite_book (diff)
Copied Template:Cite_journal (oldid, history) → incubator:Template:Wp/nod/cite_journal (diff)
Copied Template:Cite_web (oldid, history) → incubator:Template:Wp/nod/cite_web (diff)
Copied Module:Citation/CS1 (oldid, history) → incubator:Module:Wp/nod/Citation/CS1 (diff)
Copied Module:Citation/CS1/Configuration (oldid, history) → incubator:Module:Wp/nod/Citation/CS1/Configuration (diff)
Copied Module:Citation/CS1/Suggestions (oldid, history) → incubator:Module:Wp/nod/Citation/CS1/Suggestions (diff)
Copied Module:Citation/CS1/Utilities (oldid, history) → incubator:Module:Wp/nod/Citation/CS1/Utilities (diff)
Copied Module:Citation/CS1/Whitelist (oldid, history) → incubator:Module:Wp/nod/Citation/CS1/Whitelist (diff)
Copied Module:Citation/CS1/styles.css (oldid, history) → incubator:Module:Wp/nod/Citation/CS1/styles.css (diff)

This is the talk page for discussing improvements to the Citation Style 1 page.

Put new text under old text. Click here to start a new topic.
New to Misplaced Pages? Welcome! Learn to edit; get help.

Citation templates

... in conception

... and in reality

Current version of page no longer contains cited facts. url-status=?

It seems to me that there |url-status= needs another option, for a webpage which is live and has not been usurped, but where the current version no longer contains the cited info.

I have been archiving the refs on the article Paul Gogarty (an Irish politician), and the page http://www.paulgogarty.com/about/ was cited in 2009 as a ref for the assertion that he joined the Green Party in 1989 as a student. That current live age doesn't say that, because Gogarty left the Green party 10 years ago, and has been an independent since 2011. So his biog page now focuses more on his status as an independent.

However, the relevant facts are in an archived version of the page, from 2009: https://web.archive.org/web/20151229222337/http://www.paulgogarty.com/about/

I was unsure what value to give for |url-status=. None of the options was a good fit:

|url-status=live makes the current version the primary link, which is not helpful
|url-status=usurped would be untrue, because the domain has not been usurped
|url-status=unfit initially seemed like the best option, but it does not link the original URL, which seems unhelpful
|url-status=dead isn't strictly true, because the original page is still live ... but this option does link the original URL

So in this edit I used |url-status=dead as the least-worst option.

However, it would be better to have some option which more accurately describes the situation. Maybe |url-status=rewritten or |url-status=revised?

It seems to me that this situation is not uncommon, so there should be an option which supports it. --BrownHairedGirl (talk) • (contribs) 06:03, 17 June 2021 (UTC)

This is indeed a common situation, e.g. in websites of scientific organisations. A |url-status=revised (or |url-status=updated or |url-status=changed) as short for changed and no longer containing the cited information and linking to an archived version would be more informative than shoe-horning |url-status=dead. — Jts1882 | talk 07:53, 17 June 2021 (UTC)

I support the idea, but we should try and find a keyword which cannot be misunderstood. "changed", "updated", "revised" or even "rewritten" could mean all kinds of changes to the page, including those which are still supporting the statement and for which we would not want to swap the |url= and |archive-url= links. Perhaps |url-status=outdated would transport that message? --Matthiaspaul (talk) 12:08, 17 June 2021 (UTC)

Thinking about alternative keywords properly describing the situation, |url-status=outdated, |url-status=substituted, |url-status=replaced, and |url-status=archived came to my mind so far. Perhaps archived would be the most universal one as it does not make a statement in regard to the potentially changed contents of the live site and its validity, just that an archived snapshot exists (and therefore can be linked to if the editor wants to). Codewise, this would be treated as an alias to dead for now.

--Matthiaspaul (talk) 19:15, 6 July 2021 (UTC)

BrownHairedGirl's example could thus look like:

Gogarty joined the Green Party in 1989 as a student.<ref>{{cite web |title=Profile of Paul Gogarty TD |work=Paul Gogarty's website |access-date=2009-06-19 |url=http://www.paulgogarty.com/index.php/about/ |url-status=archived |archive-url=https://web.archive.org/web/20151229222337/http://www.paulgogarty.com/about/ |archive-date=2015-12-29}}</ref>

"Profile of Paul Gogarty TD". Paul Gogarty's website. Archived from the original on 2015-12-29. Retrieved 2009-06-19. {{cite web}}: Invalid |url-status=archived (help)

--Matthiaspaul (talk) 15:09, 7 July 2021 (UTC)

I'm not convinced that |url-status=archived is all that meaningful. Looking at the wikitext of your example template, a generic editor might think, "of course its archived, it has |archive-url= ..." If this new keyword (presuming that we can find one), is to convey the meaning that the original url no longer supports our article's text, then that keyword should be sufficiently descriptive to convey that meaning. |url-status=archived doesn't do it for me.

As an aside, I am going to delete my |url-status=blacklisted changes because they won't work; your change will be swept away by that revert.

—Trappist the monk (talk) 17:26, 7 July 2021 (UTC)

Well, I thought that perhaps not conveying that meaning would be a good thing here, but I see the point. What about |url-status=diverging/diverged, |url-status=deviating/deviated, |url-status=differing/differed/different or |url-status=drifted?

--Matthiaspaul (talk) 17:49, 7 July 2021 (UTC)

If this really is a good idea, and I remain skeptical, |url-status=archive-verified. It's not going to be intuitive regardless, and we're probably not going to be able to find a single word to do what you want. Izno (talk) 18:15, 7 July 2021 (UTC)

I guess, |url-status=invalid would be too close to |url-status=unfit and imply either gross or corrupt contents or an error, but |url-status=invalidated would convey the message that there once actually was valid contents (as verifiable by the archived snapshot - somewhat in line with Izno's archive-verified above), that there was a change in contents, and that the current one isn't good any more, but still not dead, or unfit, or usurped... Perhaps BrownHairedGirl, Jts1882, or Amakuru have ideas for even better keywords?

--Matthiaspaul (talk) 18:51, 7 July 2021 (UTC)

Unfortunately, I have no better suggestion. I struggled to find something pithy for content changed and no longer containing the cited information and |url-status=revised/updated/changed) were the best one word options I could think of. Izno's |url-status=archive-verified conveys the right message that the content was verifiable and can still be checked in the archive. — Jts1882 | talk 09:01, 8 July 2021 (UTC)

We should try hard to find a suitable one-word keyword. I mean, live, dead, unfit and usurped also do not convey all implied meanings associated with them, but they come close enough to be memorizable.

Unfortunately, archive-verified is too long IMO, and, while true, it is also a bit too much on the policy side - I mean, we do not necessarily need to explicitly state in the keyword that the contents is verified (verifiable from the archive), because that's what WP:RS need to be in the first place. What's more important to convey is that the live contents has changed and deviates from the former contents which supported the statement.

|url-status=revised/updated/changed would be nice short keywords to reflect the change in general, but they miss a notion of the original information not being supported any more. |url-status=substituted/replaced/reworked do convey that message better, but are perhaps a bit too close to |url-status=usurped already, after all, substitution or replacement could also indicate a site holding completely new information rather than a page that is still rooted in the original one, but has changed enough (just) to no longer support the statement. IMO, |url-status=diverged or |url-status=deviated transports that message quite well. |url-status=invalidated could do it as well (and even has a notion of former validation/verifiability), but is closer to |url-status=unfit already. None of them implies the existence of an archived snapshot, but the existing keywords don't do that as well, so this is not necessarily a bad thing. If we would want to put the emphasis on the availabilty of an archive rather than the reasons for why it might be necessary to refer to it, |url-status=archived could be a suitable purely descriptive option as well. Finally, here is another one which (only indirectly) implies change and a need to recover the original information, but also has aspects of information being archived and verified: |url-status=retrievable.

--Matthiaspaul (talk) 13:22, 8 July 2021 (UTC)

Cite web comparison
Wikitext	`{{cite web\|access-date=2021-07-06\|archive-date=2021-07-06\|archive-url=archive.org\|title=Title\|url-status=blacklisted\|website=Boomerocity.com}}`
Live	"Title". Boomerocity.com. `{{cite web}}`: `\|access-date=` requires `\|url=` (help); `\|archive-url=` requires `\|url=` (help); Invalid `\|url-status=blacklisted` (help); Missing or empty `\|url=` (help)
Sandbox	"Title". Boomerocity.com. `{{cite web}}`: `\|access-date=` requires `\|url=` (help); `\|archive-url=` requires `\|url=` (help); Invalid `\|url-status=blacklisted` (help); Missing or empty `\|url=` (help)

Cite book comparison
Wikitext	`{{cite book\|access-date=2021-07-06\|archive-date=2021-07-06\|archive-url=archive.org\|chapter=Chapter\|title=Title\|url-status=blacklisted}}`
Live	"Chapter". Title. `{{cite book}}`: `\|access-date=` requires `\|url=` (help); `\|archive-url=` requires `\|url=` (help); Invalid `\|url-status=blacklisted` (help)
Sandbox	"Chapter". Title. `{{cite book}}`: `\|access-date=` requires `\|url=` (help); `\|archive-url=` requires `\|url=` (help); Invalid `\|url-status=blacklisted` (help)

Cite web comparison
Wikitext	`{{cite web\|access-date=2021-07-06\|archive-date=2021-07-06\|archive-url=http://archive.org\|title=Title\|url-status=blacklisted\|url=http://blacklisted_url.com\|website=BlacklistedWebsite.com}}`
Live	"Title". BlacklistedWebsite.com. Archived from the original on 2021-07-06. Retrieved 2021-07-06. `{{cite web}}`: Invalid `\|url-status=blacklisted` (help)
Sandbox	"Title". BlacklistedWebsite.com. Archived from the original on 2021-07-06. Retrieved 2021-07-06. `{{cite web}}`: Invalid `\|url-status=blacklisted` (help)

Replacing "--" by "–"...

Hi, this is a followup to a recent but meanwhile archived discussion at Help talk:Citation_Style_1/Archive_75#Issue_with_{{{issue}}}, which was about converting double-hyphens and triple-hyphens in page ranges to en dashes and em dashes.

I originally implemented that on 2020-11-17 based on some suggestion that double-hyphens could occur in BibTeX entries and thereby could end up here as well occasionally. Unfortunately, I introduced a bug into the code trashing stripmarkers ("never do any last-minute changes after having already tested the code..." ;-) and because I could not locate the original discussion any more, it was removed rather than fixed. Well, I still haven't found the original discussion, so it probably wasn't here, but I just ran into a site (by renowned Nelson H. F. Beebe) excessively using double-hyphens in (hundreds of) BibTeX citations, so I thought I would drop a link here just for reference:

http://ftp.math.utah.edu/pub/tex/bib/bstj1930.html

Since we are doing all kinds of plausibility checks and also some on-the-fly conversions (including with pages and page ranges), I still think we should cover this case. After all, a double-hyphen in a page range can never be part of the page designation itself and the only reasonable interpretation is as an endash in a page range. The alternative to just silently converting them to improve our display and make our metadata output more consistent would be to throw a maintenance message, but this would require more code. --Matthiaspaul (talk) 12:46, 17 June 2021 (UTC)

Searches:

-- 25 (times out)

--- none

—Trappist the monk (talk) 12:59, 17 June 2021 (UTC)

Not sure why you escaped the dashes, but I can get to 36 with timeout.

I do not see a need for this change. There are sufficiently few and clearly not many being introduced that the interested user can just work from a search. Izno (talk) 13:51, 17 June 2021 (UTC)

In fact, I can refine this to

Still don't think we need it. Izno (talk) 14:23, 17 June 2021 (UTC)

I, on the contrary, don't see how it could cause any harm. It would improve consistency in how citations are displayed and metadata is generated. Using two consecutive hyphens for an endash was a common notation in pre-Unicode times and many people are still accustomed to it. While we support Unicode and therefore do not technically need this any more, in general it is still a good idea to maintain compatibility with ASCII conventions for as long as they don't step in the way of more modern conventions. En dashes are still difficult to type in many keyboard layouts and visually almost impossible to distingish from a hyphen in many fonts. So, while they are technically the correct thing to use, they are not convenient to use. Why not let the templates do the translation for the editors' convenience? After all, we already translate a variety of other special character "transliterations" on the fly, so this would not be anything new. Alternatively we could have someone looking for these strings every once in a while and fix them in citations, but this is a never-ending endeavour, and we would continue to generate strange looking citations and metadata until fixed.

Alternatively, we could detect the pattern and issue an error message in order to force editors to use en dashes. However, this would require more code than to just translate this on the fly, so if code complexity would be the issue, an on-the-fly translation would be the preferable solution. --Matthiaspaul (talk) 14:41, 19 July 2021 (UTC)

MOS:DASH asks us to avoid double and triple dashes. MOS is generally about the visible output, not necessarily about parameter input on source code level, but what we can draw from this is that we should not have "--" or "---" showing up in rendered citations and metadata (well, unless the metadata standard would require en/em dashes to be transliterated this way, which COinS, however, does not). So, we should either accept them on source code level and convert them on the fly for proper output as "–" or "—", or, since they can never be a valid part of a single page designation, we should check for this condition (similar to our various extra text checks) and emit an error message. I still prefer the former alternative because it is easier to implement and in some cases might even become useful when people want to enter an en dash in an environment not supporting direct entry of the glyph, but I would also support the latter alternative.

--Matthiaspaul (talk) 10:42, 13 August 2021 (UTC)

summary messaging in the preview warning header

Whenever you preview a page, above the previewed text there is a yellowish message box that reads: 'This is only a preview; your changes have not yet been saved!' Scribunto has a function mw.addWarning() that can add text to that box. Usually I only notice that box when some template has duplicate parameters. For example, this template:

{{cite book |title=Title |title=Title}}

causes this message:

Warning: Help talk:Citation Style 1 is calling Template:Cite book with more than one value for the "title" parameter. Only the last value provided will be used.

It occurred to me this morning that adding generic messaging about cs1|2 errors and maintenance messages might help editors notice that there are errors in an article's cs1|2 templates. So I've hacked Module:Citation/CS1/sandbox as an experiment. To see this experiment, edit and then preview this version of my sandbox.

Opinions?

—Trappist the monk (talk) 14:16, 12 July 2021 (UTC)

I like it in general, and I can imagine it being useful for a variety of template errors. There is precedent for using it for duplicate parameters, but those are rare since they were cleaned up, so most editors probably haven't seen such an error. I think we would have to get buy-in from the community, since these messages would be appearing on every editor's preview screen. Pitchforks, etc. I wonder if there is a way to do a small-scale test. – Jonesey95 (talk) 16:24, 12 July 2021 (UTC)

I suppose that, if we must, we could limit the output to cs1|2 templates that are not {{cite book}}, not {{cite journal}}, not {{cite news}}, not {{cite web}}, and not {{citation}}. Or, conversely, to just one of the 'big 5' ...

—Trappist the monk (talk) 17:24, 12 July 2021 (UTC)

I agree that this looks like a good idea. Might one possibility for a test be to limit it to a single additional class of error, and to pick something that's clearly always a significant error: e.g. {{cite journal}} being used without journal=? Wham2001 (talk) 18:00, 12 July 2021 (UTC)

The Cite <template> requires |<param>= error messages are hidden so don't seem to me to be a good candidate for a test. Though I haven't tried it, I think that picking a particular error is rather more difficult and goes beyond the intent of this messaging which is more summary than detail. But, it does raise an issue: what to do about hidden error messages? We might change the message so that it reads:

{{<template>}} template has n× errors; messages may be hidden (help)

I've also noticed that exact duplicates of the messages added to the yellowish box are not repeated so it would make some sense to have the messages read:

One or more {{<template>}} template has n× errors; messages may be hidden (help)

—Trappist the monk (talk) 19:04, 12 July 2021 (UTC)

I like this as well. Would it be possible to let the "cite xyz" prefix in the messages link to the template's help page, like in "{{cite book}}"? This would make it easier to look up the template-specific help in case of errors and would follow the same idea as this older proposal to add small "

" icons in front of the citations in preview mode: Help_talk:Citation_Style_1/Archive_69#Template-specific_help_in_preview. --Matthiaspaul (talk) 18:22, 12 July 2021 (UTC)

What's interesting is that if identically looking messages are added, only one of them will be shown. To avoid this, a template would have to provide some disambiguating information (like its CITEREF anchor):

{{citation}} template "Author2020" has 2× errors

{{citation}} template "Author2021" has 1× errors

This would help to avoid oddly looking messages such as

{{citation}} template has 2× errors

{{citation}} template has 1× errors

and also help to locate the problematic template if there are many uses of the same template, but on pages with many citations (with errors) the list could become very long.

On the other hand, it could also be used to keep the message very short in total by just stating that there are errors instead of how many:

{{citation}} template has errors

--Matthiaspaul (talk) 18:42, 12 July 2021 (UTC)

I've tweaked the test a bit (error messages only) because of that identical-messages-not-repeated thing, linked to the template pages and corrected for config.CitationClass that doesn't exactly match the template's canonical name. I'm not wedded to the 'n× errors' text; I added it because I wanted to see how easy it would be to include that kind of information. It is perhaps too much detail; this is supposed to be summary (I've also changed the topic's title to reflect 'summary' rather than 'generic')

—Trappist the monk (talk) 19:04, 12 July 2021 (UTC)

If it's only meant as a summary to alert the editor that there are errors to look at (further down), I think, the number of errors is not important to know at all. It's also irrelevant to know that different citations using the same template might contain different numbers of errors. By eliminating the number we would avoid such odd looking messages.

Still good to know how to include additional information for cases where this might be useful to provide in the future.

--Matthiaspaul (talk) 19:38, 12 July 2021 (UTC)

I personally like the colored messages, but for consistency with the messages issued by MW itself, perhaps it would better if our messages were using the same style and capitalization. This could look similar to:

Warning: Help talk:Citation Style 1 is calling Template:Cite book/new with more than one value for the "title" parameter. Only the last value provided will be used. (Help)

Warning: Help talk:Citation Style 1 is calling Template:Cite book/new with errors. Messages may be hidden. (Help)

Warning: Help talk:Citation Style 1 is calling Template:Cite book/new with warnings. Messages may be hidden. (Help)

--Matthiaspaul (talk) 17:01, 13 July 2021 (UTC)

For comparison, the {{infobox}} templates don't use mw.AddWarning() but issue error messages looking somewhat similar to MW's:

Preview warning: Page using Template:Infobox with unknown parameter "unknown"

This message shows up at the location of the template's invocation (that is typically just below the yellowish preview box). What we can draw from this is that issuing inline messages only in preview would be an option for us as well. So, it we would want to keep the message in the yellowish preview box really short, it could be reduced to a single line even in case of multiple templates generating errors like:

Warning: Help talk:Citation Style 1 is calling citation templates with errors or warnings. Messages may be hidden. (Help)

We would still be able to provide links to the individual templates' help pages by using the same preview messaging mechanism as {{infobox}} to insert those small "

" icons (per the above linked thread) in front of the citations (at least those, which have errors):

Smith, John (9999). "Title of Things". Journal of Stuff. 34 (1): 23–45. doi:10.4321/3210. PMID 012345. {{cite journal}}: Check date values in: |date= (help)

--Matthiaspaul (talk) 17:43, 13 July 2021 (UTC)

I don't particularly care for the MediaWiki warning style. I'm pretty sure that I know what page it is that I'm editing so that information isn't needed. I've tweaked the colored messages so they don't bleed quite so much and removed the error-tally from the messages. The point is to draw attention to the need for repairs so the color is, I think, important. If the cs1|2 messages look too much like the MediaWiki messages, I fear that they will be ignored.

—Trappist the monk (talk) 21:42, 13 July 2021 (UTC)

I think that the revisions are an improvement. I noticed one apparent typo: "One or more {{cite book}} template has errors" should read "... templates ..." – Jonesey95 (talk) 17:26, 14 July 2021 (UTC)

Are you sure? Plural 'templates' just sounds wrong to me because 'One' dominates and 'or more' could almost be set off with commas or parentheses:

One, or more, {{cite book}} template has errors

One (or more) {{cite book}} template has errors

And, if it is as you say, wouldn't it be: "One or more {{cite book}} templates have errors"?

I suppose we could evade the issue and rewrite – though this doesn't share nicely with maintenance messaging:

{{cite book}} template errors detected

or we could write:

{{cite book}} template has errors

{{cite book}} template has maintenance message

—Trappist the monk (talk) 17:54, 14 July 2021 (UTC)

I missed the verb. It should be "templates have". Here's a lively thread with references to sources (which do not always agree, of course). If we can't agree, a slightly uglier phrasing of "At least one cite book template has errors" would be grammatical. – Jonesey95 (talk) 22:54, 14 July 2021 (UTC)

Some observations:

The preview messages give the canonical name of the template. It would show, for example, {{cite book}} even if {{cite book/new}} is what was invoked. Similar, it would show {{cite news}} even when the actually used template is {{cite newspaper}}, a redirect. While the first case could be fixed programmatically, there is no cure for the second type of cases. However, perhaps no actual fix is necessary. The wording could be adjusted accordingly, for example:

{{cite book}}-type templates have errors
{{cite book}}-related templates have errors

or something along this line. Alternatively, since noone commented negatively on my proposal for template-specific "

"-style help links in front of the problematic citation templates themselves above, I'm bringing this up again in this context. Thereby we could eliminate the need to explicitly state the name of a template in the preview at all:

A CS1/CS2 citation template has errors
A {{cite ...}} template has errors
CS1/CS2 citation templates have errors
{{cite ...}} templates have errors

As can be seen on this page, the preview message also occurs on talk pages. While this is certainly desirable here (to illustrate the messages) this could encourage editors on other talk pages to correct errors in templates even in other editors' talk page contributions - while this would be in most cases harmless, I'm not sure if we should encourage this. However, disabling the messages on all talk pages we would need some means to override this (for example, to still show them on this talk page, where the automatic disabling could be overridden by our debug parameter |template-doc-demo/no-tracking=yes, for which BTW we are still seeking a better name).

--Matthiaspaul (talk) 14:32, 21 July 2021 (UTC)

It is not possible to know the name of the template that {{#invoke:}}s Module:Citation/CS1. We can spoof {{cite book/new}} if we modify that template to use |CitationClass=book/new (and then modify the module so that it recognizes both forms ...). Not worth the effort to do that.

I have no enthusiasm for template-specific "

"-style help links. And, |link= has the same 'canonical name only' problem that you are complaining about with the preview messages...

We can use the same mechanism that we use to prevent talk-page-categorization to prevent preview messaging in those same namespaces. We might need to create a variable no_preview_msgs so that we allow preview messaging in ~/sandbox pages else we can just reuse no_tracking_cats.

—Trappist the monk (talk) 15:22, 21 July 2021 (UTC)

Just in case this somehow went down the wrong throat, I was not complaining at all, just listing observations and possible options in our quest to find the best-possible solution.

Also, I agree with you that gettting {{cite book/new}} right would not be worth the effort.

Regarding the template-specific help icon, I don't understand your |link= argument. Of course, for the reasons stated, the help link would point to {{cite news}} even if the actual invocation would be from {{cite newspaper}} or {{cite news/new}}. But by using an icon instead of text we would not have to explicitly state the target name as in the preview message, thereby avoiding the issue altogether.

From the usability point of view, both ways provide the template-specific help link. There are probably some minor pros and cons depending on if the context-link is in the preview box at the top of the screen (getting sort-of the template's name to search for, but having to look up the error messages elsewhere) or in front of the offending citation (getting a help link in the immediate vincity of the template throwing the error/warning, but not getting any hint at the template's name at all) - but I would consider them both as good enough for the purpose. It would even be possible to combine them.

From the coding perspective, the box message gets issued through mw.addWarning(), whereas the icon would depend on {{REVISIONID}}, not much code overhead either way.

Regarding not being enthusiastic, I would appreciate if you could explain this a bit more rationally to better understand your thinking. Is it related to the look, the usability, the implementation, or just a lack of fun doing it?

--Matthiaspaul (talk) 17:34, 21 July 2021 (UTC)

Using an icon image does not avoid the issue of explicitly stating the target name because, for accessibility, we must supply values for the icon's |alt= and |link= parameters. |alt= might get something like link to cite news template documentation so alt text and the link suffer from the same problem as the preview warning when the offending template is a redirect or a wrapper. Omitting the canonical template name from the alt text (link to template documentation) is not acceptable because we should identify the icon's link target.

I don't think that lack of enthusiasm demonstrates irrationality on my part. I am not enthusiastic about icons because I'm not enthusiastic about icons. I don't like that these proposed icons are at one end of the rendered citation while the error messaging is (primarily) at the other end. I wonder if we should include a list of cs1|2 templates somewhere on Help:CS1 errors and then link to that list from each error message section in the same manner that we link to the help desk. Or, perhaps, modify the error messaging so that the linked canonical template name prefixes the error messages in preview. To do that will require a bit of work to move all error messages that now render mid-citation to the end of the rendering (something that I think should be done anyway):

{{cite news}}: <error message> (help)

—Trappist the monk (talk) 13:51, 22 July 2021 (UTC)

Thanks, this is exactly the type of explanation I was missing. I did not intend at all to imply irrationality on your side. But to understand each other we need to explain our feelings and reasoning to others. I did not consider the lack of alt text an accessibility issue here because I saw the icon as a non-essential part of the UI and was willing to compromise on it in order to keep it as short and unobtrusive as possible. In the old thread, I was also proposing to alternatively just use a text question mark. But I can see your point. In the old thread, Headbomb suggested adding a whole sentence fragment following the citation, something that I found too long for what we wanted to achieve, but I like your proposal to move all mid-citation messages to the end and prefix them with just the canonical name of the template - this way, it remains unobtrusive and short.

--Matthiaspaul (talk) 01:57, 24 July 2021 (UTC)

I have hacked Module:Citation/CS1/Identifiers/sandbox so that all of the error messages that it produces are now listed at the end. These error messages account for the preponderance of mid-citation error messages. I have added the template name prefix and an error message sort to Module:Citation/CS1/sandbox so that error messages are listed, more-or-less, in alpha-order. The sort is simple ascii and isn't perfect because the error messages to be sorted have html markup and html entities; for example, these sort in this order:

<code class=\"cs1-code\">|volume=</code> has extra text (])
<code class=\"cs1-code\">|issue=</code> has extra text (])
Check <code class=\"cs1-code\">|arxiv=</code> value (])

A good place to see this in action is at Module talk:Citation/CS1/testcases. Still need to seek through error message creation in other module pages to find the remaining mid-citation error messages and move them to the end. Once that's done, I think that further optimization can be done because messages can (should be?) added to z.message_tail by set_message() instead of where the message occurs unless something special is required for a particular message.

—Trappist the monk (talk) ~~11:56, 25 July 2021 (UTC)~~ 19:52, 25 July 2021 (UTC) (better sort example)

I like this (most of it). One further idea:

In order to make it easier to put the focus on the rendered citations with the detailed error messages, I think, the messages in the preview box should contain a link to this location. As a matter of fact, we can't link to all of them, but the most reasonable location to link to would be the first citation throwing an error. Once fixed, the link would point to the next offending citation in the row, and so on, so this linking scheme would appear to be quite natural in the process of fixing errors. Also, clicking the link would (and should) work even for citations generating "invisible" messages, so the editor would at least see the (first) offending citation, even if not the actual message.

Implementing this would be quite easy: All we would need is a template-specific anchor for errors and for maintenance created in front of a citation if (and only if) this citation throws the corresponding type of message (regardless of visibility). The message in the preview box could then link to this anchor. If multiple citations of the same type would throw messages, they would all create identically named anchors and, clicking the link in the preview box, the browser would focus on the first of them.

In theory, creating identically named anchors is invalidating the HTML, but this does not cause any real-world issues and it also happens with non-disambiguated ({{harv}}-style) references. Still, to avoid this at least in the normal article view we could generate these invisible anchors only in article preview (using {{REVISIONID}}), so that they would only exist when an editor is previewing a page, and there is actually a preview box with errors containing links to them.

The preview messages could look like (mockup):

One or more {{cite journal}} templates issue errors; messages may be hidden (help)

One or more {{cite book}} templates need maintenance; messages may be hidden (help)

--Matthiaspaul (talk) 10:32, 29 July 2021 (UTC) (updated 11:01, 29 July 2021 (UTC))

As a simple experiment, I have hacked Module:Citation/CS1 to create an anchor from config.CitationClass for the error warnings (not for maintenance). Edit this page, preview.

I'm not sure that the word 'errors' should be linked; that doesn't make it obvious that the link takes the editor to a broken citation. Perhaps something like:

One or more {{cite journal}} template has errors; messages may be hidden (help). Jump to citation.

—Trappist the monk (talk) 13:38, 29 July 2021 (UTC)

And now maint warnings.

—Trappist the monk (talk) 14:56, 29 July 2021 (UTC)

We could use the same style as MW:

This is only a preview; your changes have not yet been saved! → Go to editing area

One or more {{cite journal}} templates have errors; messages may be hidden (help). → Go to citation

--Matthiaspaul (talk) 17:07, 29 July 2021 (UTC)

Meh. We are not MW so why would we want to look like MW?

—Trappist the monk (talk) 17:29, 29 July 2021 (UTC)

Consistency of the user interface, to give the user a smooth and seamless experience and let it look as if it was designed as "one thing" as much as possible instead of everyone inventing their own style.

--Matthiaspaul (talk) 20:09, 29 July 2021 (UTC)

Thanks for implementing it. I have changed the trailing semicolon into a dot to properly stop the sentence and for consistency with the MW message above.

Playing with the feature I must say I really like it and hope that it will be well-accepted by the community and help to spot citation errors more easily. :-)

Still, I think, that some more refinement is desirable in regard to the message text:

One or more {{cite book}} template has errors; messages may be hidden (help). → Go to citation

One or more {{cite book}} template has maintenance messages; messages may be hidden (help). → Go to citation

To me the combination of "more" and singular "template has" sounds odd. Jonesey suggested plural "templates have". You mentioned that, for you, "one" dominates. There is a singular-rule for or-clauses, but it applies only for as long as all individually listed items are singular. To me, "more" implies plural of templates, and the verb follows the numerus of the nearest subject.

Another observation is semantically: In a strict sense, it is (hopefully) not the template having errors, but the template's invocation (the citation) in the article. Perhaps this could be remedied without complicating things too much simply by using verbs like "issue errors" or "emit errors" (or your "detected errors" above) instead of "have errors". In the maintenance case, we could use "need maintenance" instead of "have maintenance messages":

One or more {{cite book}} templates issue errors; messages may be hidden (help). → Go to citation

One or more {{cite book}} templates need maintenance; messages may be hidden (help). → Go to citation

or perhaps something like

Template {{cite book}} signals citation errors; messages may be hidden (help). → Go to citation

Template {{cite book}} requests citation maintenance; messages may be hidden (help). → Go to citation

--Matthiaspaul (talk) 18:27, 31 July 2021 (UTC)

Template {{cite book}} requests citation maintenance. Do not like. Too anthropomorphic. I still prefer 'One or more cite xxx template has ...' but I would also write 'the government are morally bankrupt' instead of '... is morally bankrupt'. But the tide is against me so I've changed to 'One or more cite xxx templates have ...'

—Trappist the monk (talk) 18:46, 1 August 2021 (UTC)

Regarding alpha-sorting of the messages, I think this is good enough for now, although this sometimes leads to somewhat odd results when there are many messages at once. In the long run, I think, we would have to add some weighting to group the more essential messages first, possibly ordered by occurence in the citation's rendering, followed by ID-related messages sorted alphabetically (or, more indirectly, by order of IDs in the table). But since there are typically not many messages at once, I think it is already good enough for a release.

--Matthiaspaul (talk) 13:18, 1 August 2021 (UTC)

It isn't hard to strip html and html-like tags from the error messages and sort by the message text:

table.sort (z.error_msgs_t,
	function (a, b)
		return a:gsub ('%b<>', '') < b:gsub ('%b<>', '') end
	)

and then if you really want to sort by first letter of the error message, you have to also strip leading pipes from those messages that begin with a parameter name. Unless it is really necessary, we document the apparent anomalies and leave it at that.

—Trappist the monk (talk) 18:46, 1 August 2021 (UTC)

I suppose anything that points out errors before the edit is committed is a good thing. I don't see any obvious negatives, except that the usual chorus of snowflakes may find something else to complain about, regardless. 64.18.9.209 (talk) 12:12, 13 July 2021 (UTC)

Wild brainstorming: Is there a way to make the text of added preview warnings invisible somehow, and does mw.addWarning() provide return codes, perhaps even a special one when a message gets discarded for being a duplicate? If so, perhaps this mechanism could be utilized to let a citation detect that it is using the same CITEREF anchor as another citation on the same page and therefore would need disambiguation in conjunction with {{sfn}}... --Matthiaspaul (talk) 19:00, 13 July 2021 (UTC)

Why would you want to hide a preview message? It can be done with css display: none; but why? Are you suggesting that this could be (mis)used as a inter-template mailbox? Sort of a one-way mailbox though, isn't it?

Here is the documentation, such as it is, for mw.addWarning(). No return value but if you write this in the debug console the 'return' value is 'nil':

=(nil == mw.addWarning('warning text')) and 'nil' or 'sommat else'

—Trappist the monk (talk) 19:31, 13 July 2021 (UTC)

Exactly, the wild idea was to send "invisible" messages containing the CITEREF anchor name to the preview box and act on the return code (if there would be a special one when discarding duplicate messages). However, just wishful thinking... --Matthiaspaul (talk) 20:04, 13 July 2021 (UTC)

BTW. The German documentation is somewhat better, but still no return code: de:Hilfe:Lua/Programmierung#mw.addWarning() --Matthiaspaul (talk) 20:08, 13 July 2021 (UTC)

While I heartilly endorse having an error summary at the beginning or end, I would prefer to keep or improve the exiting inline error messages. The easier it is to find the offending markup, the better, and removing the messages from the citations would be a step backwards. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:43, 25 July 2021 (UTC)

Umm, where did you get the idea that this proposal will remove error messages attached to individual citations? It will not. The summary at the top is intended to alert editors that errors are present at the bottom of an article preview where editors might not think to look before saving an edit.

—Trappist the monk (talk) 13:59, 25 July 2021 (UTC)

How to extlink the components of a multi-component publication

This citation:

{{citation | last = Theil | first = H. | authorlink = Henri Theil | journal = Nederl. Akad. Wetensch., Proc. | pages = 386–392, 521–525, 1397–1412 | title = A rank-invariant method of linear and polynomial regression analysis. , , | volume = 53 | year = 1950}}
Theil, H. (1950), "A rank-invariant method of linear and polynomial regression analysis. I, II, III", Nederl. Akad. Wetensch., Proc., 53: 386–392, 521–525, 1397–1412 {{citation}}: External link in |title= (help)

is throwing a CS1 error "External link in |title= (help)". But obviously it wouldn't work to use |title-link= (the only suggestion at the help link) because the three components of this multi-component work need to be linked separately. Can anyone suggest a way to make this citation work without errors and without splitting it into three separate citations? All I would really want is to disable the CS1 error message, because except for that message the citation template appears to format the citation adequately. —David Eppstein (talk) 17:14, 13 July 2021 (UTC)

You can link the page numbers:

{{citation | last = Theil | first = H. | authorlink = Henri Theil | journal = Nederl. Akad. Wetensch., Proc. | pages = , , | title = A rank-invariant method of linear and polynomial regression analysis | volume = 53 | year = 1950}}
Theil, H. (1950), "A rank-invariant method of linear and polynomial regression analysis", Nederl. Akad. Wetensch., Proc., 53: 386–392, 521–525, 1397–1412

—Trappist the monk (talk) 17:48, 13 July 2021 (UTC)

This might be a good solution in the current implementation as we strip off the link before generating the metadata for |pages= and friends. It might be a good idea to consider to do the same for |volume=, |number= and |issue= as well in order to better support various kinds of multi-partite publications (currently we don't, so adding the links to those parameters would, while still looking nice, mess up the metadata).

In this specific case the perfect solution would be to add support for a dedicated |part= parameter. Even COinS has a special attribute for this (rft.part, which we do not use at present), indicating that this is really something we are lacking support for in our current implementation. As far I see it, parts are typically displayed following the title, but before volumes.

--Matthiaspaul (talk) 18:38, 13 July 2021 (UTC)

Thanks for the suggestions. I think support for parts would be a good idea, but I think for now I'll follow trappist's suggestion of putting the links on the pages. —David Eppstein (talk) 21:01, 13 July 2021 (UTC)

The simplest solution may be implementing |page-linkn=, this assumes the editor should match the link number to the page sequence in |pages=. 66.108.237.246 (talk) 13:33, 14 July 2021 (UTC)

There is no need for separate |page-linkn= parameters. |pages= and friends already support page ranges, page lists as well as external links without messing up the metadata. (|volume=, |number= and |issue= don't support external links at present, though.) Hence, there is no need for a separate |page-linkn= parameter to provide links. Associating the nth-link with a particular list item would considerably complicate the code. --Matthiaspaul (talk) 20:41, 14 July 2021 (UTC)

There is a need for link parameters only when the module is designed logically. An entity and a link to the entity are not the same thing and should be represented separately, not with the same parameter. This is flexible and understandable by editors. On a lower level, data types should correspond to unique parameters. You shouldn't have the same field accepting images and free-form text for example, or URLs and plain text as another example. But as stated, this presumes a logical module design. So this is probably off-topic. 65.88.88.126 (talk) 20:57, 14 July 2021 (UTC)

During the great hyphen war many users didn't care about logical design vs. ease of use. -- GreenC 16:15, 15 July 2021 (UTC)

Another assessment would be that entrenched ways are largely immune to logic, especially when work is required to arrive at a rational state. Also, zealotry to do something is just as bad as inertia, as the tracking-category-deletion phase of the hyphen wars shows. 65.88.88.57 (talk) 17:45, 15 July 2021 (UTC)

--Matthiaspaul (talk) 13:42, 21 July 2021 (UTC)

Another related discussion: Help_talk:Citation_Style_1#Multiple_URLs_(split_file)

--Matthiaspaul (talk) 03:49, 17 August 2021 (UTC)

Incorrect spacing

Hello, there appears to be some spacing problem in the |issue= field of {{cite news}} it appears to add a space after the comma for some reason.

{{cite news |title=The new Exchange railway station at Bradford |work=The Leeds Mercury |issue=14,479 |date=3 September 1884 |location=Column F |page=3}}

"The new Exchange railway station at Bradford". The Leeds Mercury. No. 14, 479. Column F. 1884-09-03. p. 3.

Keith D (talk) 19:41, 16 July 2021 (UTC)

Help:Citation Style 1 § Accept-this-as-written markup

{{cite news |title=The new Exchange railway station at Bradford |work=The Leeds Mercury |issue=((14,479)) |date=3 September 1884 |location=Column F |page=3}}

"The new Exchange railway station at Bradford". The Leeds Mercury. No. 14,479. Column F. 1884-09-03. p. 3.

—Trappist the monk (talk) 20:01, 16 July 2021 (UTC)

Thanks - I have not come across this before. Keith D (talk) 21:21, 16 July 2021 (UTC)

@Keith D Is this really worth applying to all the instances of cite news in which it occurs when the vast majority of users who add citations using cite news will be oblivious of the issue and will not be using some obscure markup when they add the citation? If effort cannot/has not been put into preventing the template behaving in this way in the first place - a never ending battle in applying a manual fix appears to be fruitless. This is bordering on Misplaced Pages:Cosmetic edit territory. Nthep (talk) 21:52, 17 July 2021 (UTC)

I am just trying to fix the problem, I cannot see it as cosmetic as it is changing the displayed text to remove a space inserted by the templates. Keith D (talk) 21:59, 17 July 2021 (UTC)

This is a "workaround" that is really a "make-work". When was it decided that an issue number including a comma needs a space after that comma? It certainly hasn't always behaved that way. Now my watchlist is flooding with edits like this that simply should not be necessary. --Redrose64 🌹 (talk) 22:15, 17 July 2021 (UTC)

@Redrose64 I don't think this was a deliberate introduction but reading the section Trappist linked to is some bug in CS1 templates that sometimes (always?) shows itself. If it really is a major issue then it should be fixed but @Keith D, I'm sorry the way to resolve the issue is to fix the template's behaviour, not by applying some little known manual workaround that simply masks the issue and does not fix it. Nthep (talk) 22:25, 17 July 2021 (UTC)

This is definitely not cosmetic. The in-source location (the page #) must be given exactly. The behavior you see in this case is because the module regards comma as a separator and formats the number as a sequence of pages, adding a space after the comma (as is proper in such cases). If you dislike the workaround offered, remove the comma from the page number. 64.18.9.201 (talk) 23:29, 17 July 2021 (UTC)

Keith D and myself are not talking about page numbers, we're talking about issue numbers. A physical newspaper or magazine with a particular cover date may have an issue number, or it may not; but if it has one, there won't be more than one for any given date. A daily newspaper will use approximately 313 issue numbers in one year; a monthly magazine will use twelve issue numbers in a year. --Redrose64 🌹 (talk) 08:11, 18 July 2021 (UTC)

I know of no cases where |issue=, |number= or |volume= might need to contain a list. In my experience, they're always single values, and should be treated as such. |pages= is a different matter, and we do provide it as a parameter distinct from |page= to recognise the fact that a list may often be required. --Redrose64 🌹 (talk) 09:11, 18 July 2021 (UTC)

What about multi-part articles, split between different issues etc of a work (I would normally split these out into separate references, but some people wouldn't.Nigel Ish (talk) 10:18, 18 July 2021 (UTC)

Two issues - two references. --Redrose64 🌹 (talk) 20:26, 18 July 2021 (UTC)

(edit-conflict) There isn't much the template can do about it. These parameters support comma-separated item lists, so if the comma is meant as thousands separator rather than list separator, the ((accept-as-is-syntax)) must be used to indicate this. See also:

IMO, the easiest solution is to simply not use thousands separators. They often cause confusion anyway, because the exact rules and characters used very much depend on the locale you live in (i.e. some countries start grouping at 999, others at 9999, some countries group by 3 digits others by 4 digits, some countries use commas, others use dots, apostrophes or a number of other characters). If anything, thousands separators should be generated by the template itself (using thin-spaces). Another solution would be to use wrapper templates for those rare cases, where the number exceeds 999.

--Matthiaspaul (talk) 23:43, 17 July 2021 (UTC)

Thinking about it there is one way how to possibly improve the situation slightly (at least in some cases): At present, the templates interpret both, commas and semicolons as list separators. If semicolons are used, they will be translated into commas on the fly for display and metadata purposes. It is important that we support both list separators because different users are used to different separators, however, if we assume that editors will not normally switch between these separators within a single list, we could define one additional rule: If a given list contains at least one semicolon, the comma will no longer work as a list separator but as a thousands separator. Therefore |issue=14,479,800 would be interpreted as three items "14, 479, 800" and |issue=((14,479)),800 as two items "14,479, 800", but |issue=14,479;800 would be interpreted as "14,479, 800" instead of "14, 479, 800". The scheme would only work for arguments containing lists, that is, a single item like "14,479" would still require the accept-as-is syntax |issue=((14,479)) to keep it from being interpreted as two list items "14, 479". So, effectively, this would still require the usage of a special syntax, but at least some cases might be more intuitive to write than before. Also, it is important to understand that if a scheme like this would be implemented it would work for all parameters taking argument lists for reasons of consistency.

--Matthiaspaul (talk) 08:52, 18 July 2021 (UTC) (updated 11:39, 7 August 2021 (UTC))

Help_talk:Citation_Style_1/Archive_57#pages=_parameter_when_there_are_more_than_1,000_pages_in_a_work seems to suggest that separate logic can be applied to each parameter. Apart from the multi-part article case mentioned about by Nigel Ish, I'm struggling to see any case for space after comma in the issue parameter. And even in the multi-part case I think that is misuse of the template e.g. in listing a bibliography entry rather than as a citation. Nthep (talk) 11:44, 18 July 2021 (UTC)

Citation templates are used for more then references only, so bibliography entries (i.e. in "Works" or "Further reading" sections) are perfectly within the scope of them. Personally, I have also used lists of volumes, numbers and issues in references as well.

Likewise, except for the few cases mentioned here, I never saw issues or numbers higher than 999 in real life as an editor, so they are comparibly rare as well. I guess, it either way depends on what kind of articles and sources one is working on.

It would be possible to treat lists in the various parameters differently, but it would complicate the code (and thereby make it more difficult to maintain) and we frequently receive requests to make citation templates behave more logical and consistent, so not treating list arguments the same everywhere appears to be counter-productive.

Above, I proposed three ways how to possibly make it easier to enter publications with issue numbers higher than 999: The first is to not use thousands separators in the first place - this is syntactical sugar that is basically not needed to convey the message, and they are ambiguous and inconsistent in themselves. Another solution would be to create dedicated wrapper templates for those few newspaper using higher numbers. The third one would be to no longer allow for mixed separator lists using both comma and semicolons, but to disallow commas as list separators as soon as a semicolon is used in the same list. These solutions might improve the sitation without compromising the existing general scheme.

--Matthiaspaul (talk) 12:13, 18 July 2021 (UTC)

Disagree. Citations are not biblio entries, and citation templates should not be used as bibliography templates. It is better to stop thinking that a rigidly defined set of forms can encompass even the majority of citation cases. Templates are just that, formatted applications of the most general/generic instances. These templates handle most general functions fairly well, but they have a way to go to reach the above-average mark, and the documentation is below par. This is what should be the prime objective, imo (but not under the current environment when even the provenance of tracking categories is questioned). The templates do handle a few special cases tolerably. But multipart sources are a tight-corner case that can be adequately cited with a combination of cs1 templates and {{harvs}} plus custom anchors. As stated, it is not correct to cite multiple issues, volumes, URLs, etc. in a single citation. These are discrete items and should be cited in a discrete fashion, please do not convolute them into a single bibliographic record as a pseudo-citation. After developers are given a free hand to develop as they see fit, and after the essentials are correctly applied, then perhaps exotic items such as multipart citations can be considered. 12.166.107.91 (talk) 13:05, 18 July 2021 (UTC)

Railway Magazine reached issue 1000 with cover date August 1984. Yes, I've got it - I also have a continuous run of issues 521 through to the current issue, which is no. 1,444 . If you like, I can analyse which have commas and which don't. --Redrose64 🌹 (talk) 21:17, 18 July 2021 (UTC)

I wonder if we could add some code to detect all-numerical values (optionally in ranges or lists) of more than 4 (not 3 per MOS) digits, and if they exist, to automatically add thousands-separators in form of thin-spaces to them. Numerical values combined with letters or other symbols would be left alone, because then adding thousands-separators to the numerical part might cause confusion.

Thin-space (" ") thousands-separators are one of the styles recommended by MOS:DIGITS (and ISO and {{val}}: 12 345) and they would have the advantage that they cannot be confused with decimal or list separators, no matter of locale. We would probably have to do something about line-wrapping, but otherwise I can't see any problems arising from them. Either way, if it would still be desirabe to leave the numbers alone, the automatic addition of thin-space thousands-separators could be suppressed using our ((syntax)).

For our purposes, this could help to eliminate the need or urge of some editors to provide thousands-separators in large numerical values in the first place, and thereby reduce the risk of confusion. (IMHO, providing thousands-separators of any kind is a bad practise on parameter input level - the generation of thousands-separators should be left to presentation layer only, therefore done automatically inside the template, if at all.) If there really are large all-numerical page (or volume or issue) numbers which must use a comma as thousands-separator in order to faithfully reproduce a source also using commas as thousands-separator for some reason, they could still be given using a comma, but then the user would have to use our ((syntax)) to avoid misinterpretation as list separator - just as before.

Nevertheless, this scheme would cover the majority of standard cases and leave our ((syntax)) for the special cases.

--Matthiaspaul (talk) 09:39, 29 July 2021 (UTC)

I'd be happy with no thin space or no separator in issue numbers or page numbers for that matter. Regarding line-breaks is there a thin non-breaking space? volume and issue that Nthep (talk) 14:18, 29 July 2021 (UTC)

So are we anywhere near a consensus to either:

do nothing and continue to rely on the clumsy (( )) syntax, or
do nothing and not worry about spaces after commas in the issue parameter, or
remove the issue parameter from the list of those parameters where commas are used as list separators, or
remove all thousands-separators from the issue parameter, or
replace any thousand-separators with a thin (non-breaking) space?

Nthep (talk) 19:38, 11 August 2021 (UTC)

the simplest, easiest to apply, perfectly legitimate, and correctly-weighted option is to remove thousands separator and explicitly advise editors about it. All other options have flaws. I assign this option the most significant weight because of virtual certainty that citations with issue-no>999 will be encountered several decimal points to the right of the dot. Probably at less than .001. 72.229.23.69 (talk) 21:35, 11 August 2021 (UTC)

Not when you're dealing with old newspapers that have been going since the early 19th century. Then it easy to be dealing with five figure issue numbers. I don't have a problem with omitting thousands separators but we need to be clear on the look. Nthep (talk) 11:02, 12 August 2021 (UTC)

Issue number is not necessary in newspapers. They are indexed (and commonly referred to) by issue date, not issue number. 100.2.235.66 (talk) 11:42, 12 August 2021 (UTC)

so are many periodicals but nobody is suggesting just to use issue date and not number as well if it is available. Nthep (talk) 13:34, 12 August 2021 (UTC)

Was only referring to newspaper indexing. The reasoning for choosing option 4 was given above. 64.18.9.201 (talk) 14:08, 12 August 2021 (UTC)

I would go with 3 as first choice, otherwise 1. Certainly there should be no space in the issue and those above 999 need a seperator. Keith D (talk) 23:39, 11 August 2021 (UTC)

Why do they need a separator? 38.88.211.114 (talk) 00:36, 12 August 2021 (UTC)

Param suggestion: |page-url=

A lot of the citations that I see pointing to references on archive.org include urls to the specific pages in the |page= parameter as in |page=. It seems like an additional parameter, perhaps named |page-url=, would be handy to keep track of this information separately. So far, I've been leaving the links like this because they don't appear to be breaking anything yet. Slambo (Speak) 15:43, 20 July 2021 (UTC)

It should be an alias of |url=, not a new parameter. Only 1 URL, the more specific one should be entered in citations, with the page, or the first page in a page range. In any case, I would remove the url from the page param and insert the url param. If the citation includes a page number, it is understood that the link may lead to the pertinent page. If one needs to link multiple pages, short refs would be more apt imo. 50.74.114.218 (talk) 17:46, 20 July 2021 (UTC)

Why? The URL of the publication provides access to information on the context of the cited pages. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:04, 21 July 2021 (UTC)

That is correct. But also potentially confusing, in the sense of having two URLs pointing to different things, i.e. information/context about the work (the work's URL) and the in-work location (the page's URL). I am not certain the average reader will be able to navigate this with ease. I suppose personally I would include the work's URL in the full citation, and the page URLs on short references. But this is just a preference. 65.88.88.126 (talk) 16:54, 21 July 2021 (UTC)

We recently had a related discussion at Help_talk:Citation_Style_1#How_to_extlink_the_components_of_a_multi-component_publication.

These page links are typically added by bots. When I first saw them added to articles a couple of years back I too thought they would be a bad idea (because they add clutter to the |pages= parameters), however, they are not as bad as they might look at first sight: Like you already observed, they are not breaking anything (in any of the page-related parameters, that is), because the links are automatically removed before using the page information for metadata.

Regarding the suggestion of having (only) one alias to |url= for a "page link" and for the proposal to have numbered page parameters (in the other thread), this wouldn't work:

To the contrary of what the IP stated, the |pages= parameter often contains a list of pages or even page ranges, and it is not at all desirable to split them up into individual pages or use short references for them. Splitting up into individual pages is only necessary when it is particularly important to document the exact locations where multiple independent statements are sourced. In the vast majority of cases, this is not important, and combining all references to a single publication and providing a list of pages is sufficient. In most cases, it is easy enough to flip through these pages to find the one supporting a specific statement, so having individual references for each of them would only add redundancy and clutter to the article. Short references add an extra layer of indirection and don't allow for backlinks, therefore they are often inconvenient to use - they kind of solve one problem by adding a bunch of other problems. Per WP:CITEVAR, they are not a requirement at all to use and many people do not (want) to use them because of their shortcomings. So, suggesting anything that would force us to split up citations is simply no solution at all.

Regarding numbered page links (as suggested in the other thread), this would require not only numbered page link parameters but also numbered page parameters, as otherwise it would be next to impossible to known which link belongs to which page. While this would be technically a workable solution, it would not be a good one, because it would make the list of pages even more difficult to read and add an enourmous amount of parameter clutter to citations. It would also make the code much more complex and difficult to maintain. I mean, we do have numbered parameters for the various types of contributors, but we don't have them because this would be a particularly great idea but simply because the template has a need to know the given name, surname and optionally the link to generate the proper representation for display and metadata purposes from this, and the complexity of naming schemes makes it impossible to just provide a name list and let the template reliably extract the informational bits from it. It would work in some cases, but not in general, that's why we need a set of numbered parameters for the names. However, although there is a huge variety in page numbering schemes, they are still much simplier than names and therefore the code can be made smart enough to reliably extract all the necessary information from a single parameter argument.

Finally, there was a complaint that it would be a bad design decision for parameters to accept multiple types of input. I can see where this comes from, and it sometimes holds true, but not for citation templates in Misplaced Pages. I consider our approach to be kind of object-oriented (or at least we try to give this impression to users). There are limits, but ideally, you could throw any kind of "data objects" holding the relevant information at a parameter and the template would be able to figure everything out by itself. From the viewpoint of users, the most intuitive way to give a link is to use our standard Mediawiki wikitext syntax. Also, it simply should not matter if they provide a single page, a page range, a list of single pages, a list of page ranges, any kind of combination of them, a linked page, linked page range, list of linked pages or linked ranges, you got it... (Not in the case of page-related parameters, but for completeness, in some cases, parameters also accept some symbolic keywords in addition to text objects.) What can be more simple and intuitive from a user's perspective than to allow them to use the normal Wikitext syntax and just provide a list of data items? Actually, it can't be easier than this. (Unfortunately, we can't do this for names, at least not without introducing a special syntax, which would defeat the idea.)

One more thought on this: As stated above already, I too do not particuarly like these long strings such as |page= (but I've come to accept them given that they add useful information for readers and that citations would only become longer when using special parameters for this). However, in many cases the first part of these links is the same as the link provided in the |url= parameter, like in |url=https://archive.org/details/cihm_07495. For these cases, I can envision some kind of shortcut notation like |page= |url=https://archive.org/details/cihm_07495. This obviously would not work for all cases, but it would reduce the clutter and redundancy in many cases already.

Somewhat related:

--Matthiaspaul (talk) 12:11, 21 July 2021 (UTC) (updated 13:45, 13 August 2021 (UTC))

You say Short references add an extra layer of indirection and don't allow for backlinks,; however, I see back references to, e.g., 3270Intro, in IBM 3270#References. Admittedly it's a bit clunky, but it works. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:04, 21 July 2021 (UTC)

I meant backlinks from the "base citations" back to the various short references. In your example, if you arrive at e.g. the "3270Intro" citation, there are no links to go to all the short references pointing to this entry; you would have to search for them by going through all the references. However, if I would arrive there, I would want to see all the other locations citing from this publication. With an extreme amount of work something like this could be constructed manually, but it would be prone to errors and very difficult to maintain. In your specific example of "3270Intro" there are only two short references pointing there, so they could be easily merged into one with no loss of information. Even in cases such as "3270DS", which have many more short references, most of them are referring to adjacent pages in chapter 3, so it is probably enough to refer to chapter 3 and perhaps the page range, but not to individual pages, and thereby avoid most if not all those short references. If there is a particularly important statement to be referred to, |quote= and |quote-pages= can be helpful as well. If the individual page numbers should be preserved, {{rp}} can be used for the individual pages and |pages= for the combined pages. This way, the additional layer of indirection can be avoided and automatic backlinks are possible.

--Matthiaspaul (talk) 15:00, 21 July 2021 (UTC)

Using <ref name=foo />{{rp|bar}} works well when you are only adding a page number to the base citation, but what is the equivalent to {{sfn|foo|p=bar|loc=baz}}? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 21:52, 21 July 2021 (UTC)

I would just append it, separated by a comma, like in <ref name="foo" />{{rp|bar, baz}}. Alternatively, you could probably use something like {{rp|at=p. bar, baz}} or {{rp|at=baz}}. Even page links can be used in combination with {{rp}}, although this may sometimes require to use of numbered parameters like |1=.

However, WP:CITEVAR applies and you can use {{sfn}} etc. if you want. My point above was mostly that multiple pages are perfectly fine in a citation (even when used to support multiple independent statements in an article) and that there is no requirement and often no benefit splitting citations into individual short references - it comes with a price, and the disadvantages are often larger than the advantages - as usual, it depends on the circumstances. I made this point to illustrate why we need to support multiple pages and why proposals which would allow us to deal only with single (or related) pages in a citation do not lead anywhere.

--Matthiaspaul (talk) 12:53, 22 July 2021 (UTC)

Adding multiple page numbers that support different statements in a single citation is not a problem, but isn't this discussion about page links? It seems to me a full citation with multiple page links is unwieldy and full of clutter. A short ref with the specific page link for the specific wikitext seems more intuitive and easier to understand. 65.88.88.127 (talk) 17:10, 22 July 2021 (UTC)

Using {{rp|bar|at=baz}}, {{rp|bar, baz}} and {{rp}} gives me , and . The second an third have the right information, but the location is likely to be long and should be in the reference list rather than inline. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:35, 22 July 2021 (UTC)

doi:10.119.1/foobar should throw an error

See

Scurek, R. (2004). "Understanding the CPT group in particle physics: Standard and nonstandard representations". Am. J. Phys. 75 (5): 638–643. doi:10.119.1/1.1629087.

Headbomb {t · c · p · b} 20:40, 22 July 2021 (UTC)

The correct DOI would be 10.1119/1.1629087, but wouldn't the registrant code in your example "119.1" be in a valid format as well (that is, at least four digits, larger than 1000, possibly subdivided with dots)? What kind of pattern do you suggest to look for?

--Matthiaspaul (talk) 00:32, 23 July 2021 (UTC)

I imagine that if we troll back through this page's archives we will find a discussion where it was decided that we will allow registrant portion of the doi to have fewer than four digits when it has a subcode (line 564).

—Trappist the monk (talk) 00:48, 23 July 2021 (UTC)

Possibly this discussion from December 2019. – Jonesey95 (talk) 06:00, 23 July 2021 (UTC)

ref-duplicates-default detector flaw

This should emit a maintenance message but doesn't:

{{cite book |title=Title |author=Last, First |year=1953 |ref=CITEREFLast,_First1953}}

Last, First (1953). Title.{{cite book}}: CS1 maint: ref duplicates default (link)

The value assigned to |ref= is the same as is produced by {{sfnref}}:

{{sfnref|Last, First|1953}}

CITEREFLast,_First1953

But, the comparison between |ref= and the CITEREF ID created by Module:Citation/CS1 is made before the newly created CITEREF ID has been anchor encoded: CITEREFLast, First1953 (space character instead of an underscore). Because the two values are different, no maintenance message.

Fixed:

{{cite book/new |title=Title |author=Last, First |year=1953 |ref=CITEREFLast,_First1953}}

Last, First (1953). Title.{{cite book}}: CS1 maint: ref duplicates default (link)

And, when they really are different:

{{cite book/new |title=Title |author=Last, First |year=1953 |ref=CITEREFLast,_First2020}}

Last, First (1953). Title.

no maintenance message.

—Trappist the monk (talk) 17:59, 23 July 2021 (UTC)

Still an issue with book volumes

All these months later, and the issue with book volumes is still not being addressed. I understand why we don't want an explicit "volume" with a journal/magazine. I do not understand the issue with books. If Birds of North America has 13 volumes, displaying "Birds of North America. 2." does not, to most humans, clearly indicate that the 2 refers to volume 2 – particularly given that the average reader probably has no idea that there are 13 volumes in the set. Why can template not behave differently depending on whether the item is a book or a journal?! I know it's possible to do so, so somebody must have some rationale for why we don't. Please explain! MeegsC (talk) 20:25, 27 July 2021 (UTC)

Inertia, basically.

Previous discussions have yielded two proposed alternative styles for rendering |volume=, |number=/|issue= (only used with journals) and |pages=:

	Journal	Not journal	Notes
Current	3 (4): 12–56.	3, pp. 12–56.	Long volume names are not bolded, but `\|volume=vol. 3` is considered an error.
Proposal 1	3 (4): 12–56.	vol. 3, pp. 12–56.
Proposal 2	vol. 3, no. 4, pp. 12–56.		Non-journals would not have a number or issue.

The current definition of "journal" is

{{cite journal}}, or
{{citation}}/{{cite map}}/{{cite interview}} with |journal= specified.

I believe we should offer these alternatives for wider consideration. Kanguole 09:37, 28 July 2021 (UTC)

{{cite magazine}}?

—Trappist the monk (talk) 11:07, 28 July 2021 (UTC)

Adding magazine to the current row:

	journal	magazine	others
Current	3 (4): 12–56.	Vol. 3 no. 4. pp. 12–56.	3, pp. 12–56.
Proposal 1	3 (4): 12–56.	vol. 3, no. 4, pp. 12–56.
Proposal 2	vol. 3, no. 4, pp. 12–56.

Kanguole 14:10, 28 July 2021 (UTC)

I support the proposed standardization, but I think that the "scientific" nomenclature might still be desirable to have in heavily academic articles, therefore, I suggest to introduce a |periodical-style= or |serial-style= (or whatever) parameter to select the desired format if this is not the default already. (At a later stage, this could be supported by templates similar to the |cs1-dates= parameter of templates {{use dmy dates}}/{{use mdy dates}} to globally switch the display format for all citations in an article instead of having to use it in individual citations. I had some experimental code for this a year ago, but it would have to be adjusted to the current significantly changed code base.)

I believe that having such an option to override the default would significantly raise community acceptance of a general change to a more standardized format - without it, I already see the next tumult emerging from militant proposers of one of these formats. With such a parameter implemented, we would still instantly have a consistent format in the majority of articles (the goal, we want to achieve), but allow editors to override the default to address special needs in specific citations (and articles). Best of both worlds.

We could either use Proposal 1 as the default formats for the various templates and the parameter would allow to override the default and select the other format, or, we could choose Proposal 2 as the new general default format for all citation types and the parameter would have to be used in individual citations to switch to the scientific format.

--Matthiaspaul (talk) 16:53, 28 July 2021 (UTC)

I would be strongly against introducing another style configuration parameter. It would be another knob for people to twiddle and fight over, and we already have plenty of those clogging our watchlists. I would rather have a less-preferred option than that.

As for raising acceptance, I don't think anyone out there loves bold volumes for books. The choice between the other two should be settled at an RFC. Kanguole 17:11, 28 July 2021 (UTC)

Design by rfc; how appalling.

I too, am opposed to yet-another-style-parameter. {{cite journal}} renders the academic-journal-style. If you don't like that, use {{cite magazine}} or {{cite periodical}}. No need for special parameters.

—Trappist the monk (talk) 17:58, 28 July 2021 (UTC)

If we want people to be able to use cite magazine - then it needs to be added to Misplaced Pages:RefToolbar/2.0 - otherwise most editors will just use the templates which the tools force upon them.Nigel Ish (talk) 18:29, 28 July 2021 (UTC)

You'll get no opposition from me but, good luck with that:

Maybe, if enough editors make noise about it, someone will do the necessary (thankless) labor that will give them what they want. Perhaps you?

—Trappist the monk (talk) 19:12, 28 July 2021 (UTC)

Well, if as indicated by the discussions on the RefToolbar page, the tool is not being maintained, then it should be deactivated.Nigel Ish (talk) 20:34, 28 July 2021 (UTC)

I think that you are mistaken. Multiple javascript pages implement WP:RefToolbar. The tool is mostly stable so there is little to do to it. Still, these parts of it were updated this year:

MediaWiki:Gadget-refToolbar.js
MediaWiki:RefToolbar.js
MediaWiki:RefToolbarMessages-en.js
MediaWiki:RefToolbarMessages-de.js – this is the English Misplaced Pages; why do we care about the German version here?

As I said before, if enough editors make noise about it, someone will do the necessary (thankless) labor that will give them what they want. If you want the change, recruit enough editors who also want the change, or, failing that, do it yourself.

—Trappist the monk (talk) 13:10, 29 July 2021 (UTC)

Design by RfC has proven to result in inconsistent, incoherent and typically less-powerful solutions. But forcing our own (typically great ;-) ideas onto the community is also no option. I mean, even here in this dedicated place where most of us have quite some experience with citation formats we often have vastly different views in regard to the best solution to a problem, clearly indicating that we have a diverse array of needs and therefore need flexibility to address them. That's why I think we should give the users some guidance (in form of reasonable defaults and good documentation) but also the necessary flexibility so that they can (if they need to) get the results they want to suit more special requirements. Otherwise, they will either complain about our templates or not use them. Both is unsatisfactory for them and us - and for the project as a whole.

I agree that in principal it would be enough to let {{cite journal}} use the scientific format and {{cite magazine}} the verbose format - basically that's a style-parameter in disguise. However, we have readers switching between these templates based on the nature of the periodical which would defeat the idea to choose the template based on the display format.

To sum it up, without a style-parameter to optionally override the default I could still support proposal 1, but not proposal 2.

--Matthiaspaul (talk) 02:05, 29 July 2021 (UTC)

@Matthiaspaul: we have readers switching between these templates based on the nature of the periodical - I do that frequently (example), because I often find that some people are inappropriately using {{cite journal}}, {{cite news}} and {{cite web}} for magazines - for me, it's not a case of choos the template based on the display format but of choosing the most appropriate template for the source. Each of these four has documentation that gives such advice:

{{cite journal}} - academic and scientific papers published in bona fide journals
{{cite magazine}} - articles in magazines and newsletters
{{cite news}} - news articles in print, video, audio or web
{{cite web}} - web sources that are not characterized by another CS1 template

I believe that the people who do not use {{cite magazine}} do so partly because they don't read the documentation, but mainly because it's not offered by the cite tool that they use (see post by Nigel Ish at 18:29, 28 July 2021 (UTC) and the reply by Trappist. So long as that remains the case, there will always be the need to amend the citation. --Redrose64 🌹 (talk) 09:58, 29 July 2021 (UTC)

Yeah, that's right. In fact, I'm doing this as well, but I'm reasonably happy with the difference in output formats between {{cite journal}} and {{cite magazine}}. I think we should continue to maintain this idea by choosing the most suitable parameter |journal= or |magazine= based on the nature of the periodical. Typically, we would use |journal= in {{cite journal}} and |magazine= in {{cite magazine}}, but following Trappist's comment to choose the template depending on the desired output format above, we would need to acknowledge that some people might have deliberately chosen to use {{cite journal}} for |magazine= or {{cite magazine}} for |journal=, and that, if this makes sense in a particular article rendering as a whole, we should leave this alone.

--Matthiaspaul (talk) 10:14, 29 July 2021 (UTC)

I think that what you are saying without actually voicing it is that {{cite journal}}, {{cite magazine}}, {{cite news}} all become redirects to the canonical template {{cite periodical}}. {{cite periodical}} then renders volume/issue/page in the style dictated by the |work= parameter alias that is used in the template. That would likely be a significant challenge, mostly elsewhere than in Module:Citation/CS1. Some one or some series of bots would need to convert existing templates; tools like WP:RefToolbar would need updating, etc. I rather like this idea but I foresee torches and pitch forks because en.wiki editors hate, hate, hate change...

—Trappist the monk (talk) 13:10, 29 July 2021 (UTC)

I generally favor some form of Proposal 1. Let {{cite journal}} use the shorter format. In {{cite magazine}}, get the page number next to the volume and issue number. (Currently if a publisher is specified, it splits the volume/issue from the page number.) In {{cite map}}, et al., tie the output to whether |journal= or |magazine= is used.

For books though, I'd leave volume number next to title as a function of the title and retain the page number at the end, but otherwise add the "vol." text to the volume number for consistency. Imzadi 1979 → 22:46, 28 July 2021 (UTC)

Proposal 2 is the only scheme that makes sense for a project like Misplaced Pages. It is easily understandable by readers. The comma separator will have to be explained to editors since it violates style. This is because of the current rigid implementation of separators into "style 1" and "style 2", that carries no functional utility. 64.18.9.208 (talk) 23:40, 28 July 2021 (UTC)

Support Proposal 2 Although I would be happy enough with Proposal 1. Agree with Imzadi about not splitting title from volume. I thought that the maintainers already turned this down. Hawkeye7 (discuss) 23:49, 28 July 2021 (UTC)
- I'd personally prefer Proposal 2, but I think there would be too much inertia to completely move away from the abbreviated journal format. Imzadi 1979 → 00:16, 29 July 2021 (UTC)
Prefer 1, but could live with 2. Status quo is unacceptable. Headbomb {t · c · p · b} 01:22, 29 July 2021 (UTC)
Support Proposal 1; I agree that the status quo doesn't work at all. And proposal 2 certainly "isn't the only one that makes sense", despite what an anonymous IP might assert. I'm assuming that if the "number" field is left blank, that parameter won't appear at all – i.e. vol. 2, pp. 12–56. MeegsC (talk) 10:28, 29 July 2021 (UTC)

Are you saying that readers are better served by different (and convoluted) renditions of issue and volume depending on the use of a template they know nothing about? And why is an assertion by something called "MeegsC" any better on the face of it? 64.18.9.201 (talk) 11:16, 29 July 2021 (UTC)

Prefer Proposal 2 but also support Proposal 1 and strongly prefer either to the status quo. I think (based on no evidence, obvs) that the majority of editors who add citations to journal articles are probably happy with the academic shorthand since they are accustomed to it; hence the change will annoy them since style changes are always annoying. On the other hand, (still based on no evidence) our average reader probably hardly ever looks at an academic journal and is left to guess what the terse encoding means. I think we should prioritize clarity for the reader over the comfort of familiarity for the editor. This goes doubly for books where the shorthand is not, as far as I know, widely used. Wham2001 (talk) 11:11, 29 July 2021 (UTC)
Strong support for Proposal 1. This gives the output for journals and books I'd expect to see in scientific literature. Books use Volume or Vol, while journals just have the number, which may be in bold (most?), italics (a few) or with no emphasis. — Jts1882 | talk 12:17, 29 July 2021 (UTC)
Proposal 2 - is unambiguous, where proposal 1 leaves ambiguity and leaves you scrtching your head as to what the numbers mean. And the opportunity of mixing styles in a single article is not very good. Keith D (talk) 12:50, 29 July 2021 (UTC)

Date validation error

A recent edit diff introduced two "Lua error in Module:Citation/CS1/Date_validation at line 936: attempt to compare nil with number" at 1985–1986 Hormel strike#Bibliography. The edit did not change the bibliography but it added "|cs1-dates=y" to give {{Use mdy dates|date=July 2020|cs1-dates=y}}. The problem is probably due to the letters in the two problematic {{cite web}} instances: |date=August 9, 2010a and |date=August 17, 2010b and that should be fixed. However I'm wondering if some tweak to Module:Citation/CS1/Date validation should occur, possibly to change tonumber(t.y) to (tonumber(t.y) or 0) at line 936. Johnuniq (talk) 07:22, 28 July 2021 (UTC)

Thanks for that suggestion. I implemented it. But, as soon as I did, I realized that a better solution is to strip the CITEREF disambiguator and let the process proceed. Doing that gives the desired rendering in the citation. It would seem that a maintenance message when this occurs might be appropriate.

—Trappist the monk (talk) 11:06, 28 July 2021 (UTC)

Thanks to you both for the hint and fix. I too think that a maintenance message might be useful.

However, thinking about those odd disambiguators in dates, I really think that we should slowly start to deprecate and find a better solution for them. Some while back I proposed to add this functionality to the |ref= parameter: Help_talk:Citation_Style_1/Archive_76#Module:Citation/CS1/testcases/anchor_and_some_questionable_tests

--Matthiaspaul (talk) 17:10, 28 July 2021 (UTC)

error messaging

This is a sidetrack off of Help talk:Citation Style 1 § summary messaging in the preview warning header. Over the past few days I have been reworking how error messaging is handled in the various modules (primarily Module:Citation/CS1 and Module:Citation/CS1/Identifiers which emit the most errors). In the previous conversation, I suggested that it would be a good thing to move all error messages to the end of the citation. As it is right now, some error messages are made part of the template's rendering which, to me, looks bad.

The live module has a table called z.message_tail which holds all of the error messages that are rendered following the citation. To load that table, it is necessary for the code to call set_message() in Module:Citation/CS1/Utilities. That function returns the error message as a plain message or as a message wrapped in ... tags appropriately classed for hidden or visible error messages. The function that called set_message() then has to use the returned message as an appendage on a parameter's data or as a replacement for it; or, the function must insert the returned message into the z.message_tail table. Moving all error messages to the end of the citation means that set_message() can insert the message in z.message_tail as part of its normal operation and so the code is simpler and more consistent.

I have done that. The change primarily impacts Module:Citation/CS1/sandbox and Module:Citation/CS1/Identifiers/sandbox but also impacts Module:Citation/CS1/Utilities/sandbox. I have renamed z.message_tail to z.error_msgs_t so that the name reflects its content.

As part of this I have spent a bit of time refining the assembly of the various parts of the finished citation (the citation itself, the anchor ID and the css classes in the <cite> tag, the metadata, the error messages, the maintenance messages, and the categories (roughly the 100ish lines of code beginning at about line 3844 of Module:Citation/CS1/sandbox). This includes the error and maintenance summaries and the error message prefixes discussed in the previous conversation, sorting of error and maintenance messages. Empty citations will no longer produce metadata because why bother:

{{cite book}}

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

'"`UNIQ--templatestyles-0000007C-QINU`"'<cite class="citation book cs1"></cite> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{]}}</code>: </span><span class="cs1-visible-error citation-comment">Empty citation (])</span>

{{cite book/new}}

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

'"`UNIQ--templatestyles-0000007F-QINU`"'<cite class="citation book cs1"></cite> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{]}}</code>: </span><span class="cs1-visible-error citation-comment">Empty citation (])</span>

—Trappist the monk (talk) 22:02, 28 July 2021 (UTC)

I wonder if some kind of "error framing" could be done (at least in preview) to make it easier for editors to spot the errors. Mockup:

{{cite journal |last=Smith |first=John |date=9999 |title=Title of Things |journal=Journal of Stuff |volume=Vol. 34 |issue=1 |pages=23–45 |doi=10.4321/3210 |pmid=012345}}

Smith, John (9999). "Title of Things". Journal of Stuff. Vol. 34 (1): 23–45. doi:10.4321/3210. PMID 012345. {{cite journal}}: |volume= has extra text (help); Check date values in: |date= (help)

I assume it would complicate the code too much but still wanted to mention it to spread the idea.

--Matthiaspaul (talk) 00:59, 29 July 2021 (UTC)

In your example above

**

the two message spans could be combined into one:

**

to reduce the size of the resulting HTML. However, I understand that this might not always be possible if they are interwoven with hidden messages, so I'm mentioning this just in case you see an easy way to do it anyway.

--Matthiaspaul (talk) 12:07, 1 August 2021 (UTC)

Yeah, they could be combined but it is much easier in the code to have them as separate spans because we can't always and forever know that the first error message after the {{Cite book}} prefix will be a visible error message. However, that does highlight a flaw in the prefix design; if all error messages emitted by a citation are hidden, then the prefix should also be hidden. As it is, it is always visible. I'll think about that ...

—Trappist the monk (talk) 15:10, 1 August 2021 (UTC)

Citations emitting only hidden error messages will also hide the error message prefix:

{{cite journal/new |title=Title}}

"Title". {{cite journal}}: Cite journal requires |journal= (help)

'"`UNIQ--templatestyles-00000086-QINU`"'<cite class="citation journal cs1">"Title".</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{]}}</code>: </span><span class="cs1-visible-error citation-comment">Cite journal requires <code class="cs1-code">&#124;journal=</code> (])</span>

—Trappist the monk (talk) 16:29, 1 August 2021 (UTC)

Do not emit duplicate IDs in any case. Our objective is to comply with HTML and that does not. Thanks. I'll revert the lot of the sandbox if that remains in the code. The supposed gain is not worth that. Izno (talk) 14:12, 3 August 2021 (UTC)

Presumably this is related to discussion that occurred at Help talk:Citation Style 1 § summary messaging in the preview warning header regarding links from the preview warning messages to citations elsewhere in the previewed article. Where were you and your objections when we first discussed this? You were around and even edited this page during the period of that conversation. Instead of swooping in with drama and threats after the fact, it would have been better for you to participate in the discussion as it was on-going.

The point is taken and I have removed the spans and go-to links.

—Trappist the monk (talk) 15:37, 3 August 2021 (UTC)

Busy trying not to care about Matthias' outlandish requests? :) Izno (talk) 15:51, 3 August 2021 (UTC)

Not funny, and not outlandish at all. It's all about user-friendliness and usability.

The anchors/spans are added only if there is a problem in a citation. So articles without problematic citations will never have them. Also, above I proposed to add them only in preview in order to not invalidate HTML in normal article view. Even web designers who otherwise care about good HTML often deliberately ignore trivialities like this, in particular if it is known to not cause any harm.

Further, all articles with citations lacking disambiguation contain identical anchors and thereby contain invalid HTML - and not only in preview or with actual citation errors, but in normal article view for as long until the disambiguation gets fixed. And in this case, a doubled anchor actually causes "harm" as it makes subsequent citations "unreachable". When we discussed this when making |ref=harv the default, we decided to ignore this because the benefit far outweights the problem. Nobody complained about it.

We should do the same here as well, in particular as in this case the doubled anchors do not create any practical problem for browsers at all and do only exist in preview and when citations have errors, anyway. So, ignoring the "no double anchors" doctrine would be a valid engineering decision. If we do not, we should immediately switch off harv-style anchors as well.

--Matthiaspaul (talk) 17:28, 3 August 2021 (UTC)

HTML structure of a citation

However, there is a related, more general issue. This is unrelated to preview messages and the restructuring of error messages, but since we are talking about the structure of the HTML for a citation, I'm bringing this up anyway.

The general structure of a citation (in the sandbox, that is, including the preview message) is as follows:

<span id="cite-book-error"></span><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"></span>

Citation with appended messages

Some browers and tools allow to highlight the scope of elements and navigate from element to element or otherwise take advantage of knowing the scope of data elements (screenreaders and browsing assistance tools, web development tools, web harvesters). Right now, they see a citation as an empty preview error span, the actual citation with optional messages appended, followed by the COinS info.

This is somewhat suboptimal. The preview error span should span over the whole citation including messages and COinS data.

In addition to this, the COinS span should ideally span over the citation and messages as well in order to declare the context of the COinS data. This would result in the following nested structure:

<span id="cite-book-error"><span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite></span></span>

Citation with appended messages

The only adverse effect of this rearrangement I can see right now is that the browser will now display the COinS data as tooltip, which might be confusing. So, if the contents of the COinS span really must be empty, it might be possible to do it the other way around and embed it into the cite element. The preview error span could still wrap around both:

<span id="cite-book-error"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages<span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"></span></cite></span>

Citation with appended messages

In both of these two cases, the proper extraction of COinS data by existing tools would have to be tested, because in the examples I could find on the web they always suggest that this is an empty element (or only containing a space) immediately following the citation. At least wrapping the preview span around both of them will work regardlessly:

<span id="cite-book-error"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=*" class="Z3988"></span></span>

Citation with appended messages

--Matthiaspaul (talk) 12:07, 1 August 2021 (UTC)

Umm, the general structure of a sandbox citation is not quite what you say it is. See for example this:

{{cite book/new |title=Title |access-date=2021-08-01}}

Title. {{cite book}}: |access-date= requires |url= (help)

<templatestyles src="Module:Citation/CS1/sandbox/styles.css"></templatestyles><span id="cite-book-error"></span><cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3ABlue" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;access-date=</code> requires <code class="cs1-code">&#124;url=</code> (])</span>]

so what we have is:

<templatestyles></templatestyles>><cite>The Citation</cite>><messaging><categories>

I created empty error-anchor and maint-anchor spans because that is how {{anchor}} implements anchors. It is easy enough to wrap the entire rendering from <cite> to the end of the last category in the error-anchor and maint-anchor spans. If we did that, we could add an undefined class so that editors can style the anchored citations; don't know how beneficial that would be ...

I am unwilling to change how the metadata span is handled without someone having conducted extensive research to prove that your suggestion does not break external tools. Apparently metadata works now so ain't-broke-don't-fix applies.

—Trappist the monk (talk) 14:55, 1 August 2021 (UTC)

Error-anchor and maint-anchors now wrapp entire citation from <cite> to the end of the last category:

{{cite book/new |title=Title |access-date=2021-08-01 |authors=Authors}}

Title. {{cite book}}: |access-date= requires |url= (help); Unknown parameter |authors= ignored (help)

'"`UNIQ--templatestyles-00000092-QINU`"'<cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;access-date=</code> requires <code class="cs1-code">&#124;url=</code> (])</span>; <span class="cs1-visible-error citation-comment">Unknown parameter <code class="cs1-code">&#124;authors=</code> ignored (])</span>

—Trappist the monk (talk) 16:19, 1 August 2021 (UTC)

Looks good, thanks.

I agree, moving the COinS info will require more research in regard to what works with existing tools, and what might not. That's why I was bringing this up.

Unfortunately, the standard itself is not very clear about it, so implementations might vary in regard to what they expect. As far as I understand it, there should be no inherent dependency of the COinS span from <cite>, therefore from the viewpoint of data extraction, it should not matter, if one gets embedded into the other.

Regarding the contents of the COinS span, they suggest to use a space in environments where an empty span would be removed in some HTML optimization processes. From this we can at least derive that the span does not need to be empty.

They also talk about the possibility to place some default text in there, leaving it open to interpretation if COinS-aware browser plug-ins are meant to replace this text with some link/icon to a pop-up etc., or if they are meant to insert such links/icon after the text. If we find a browser plug-in which would replace the text, we obviously cannot place the citation there, otherwise this would be the most-"natural" place for it. It would be interesting to learn from the community which tools they use and how they behave on the following two test citations:

Manually crafted citation with <cite> inside COinS span:

Statement of Principles. The International Conference on Cataloguing Principles (CCP). Paris, France. 1961-10-18 .

Manually crafted citation with COinS span inside <cite>:

Statement of Principles. The International Conference on Cataloguing Principles (CCP). Paris, France. 1961-10-18 .

--Matthiaspaul (talk) 11:18, 3 August 2021 (UTC)

Given that the COINS span outputs its content as a title, putting cite inside the span is a non-starter. Everything internal will have a hover over title completely meaningless to users and defeating the other over hovers we have (links predominantly). Izno (talk) 14:10, 3 August 2021 (UTC)

Visual Editor claims that usurped is not expected in the url-status field

Whenever I am trying to switch a deadlink citation to an archive link, I sometimes need to mark it as usurped. But it seems that the only values that the Visual Editor expects are "live" (the default) and "dead". Adding usurped or unfit gives the warning " This is not one of the suggested values and may not work with the template". Can they be added as legitimate values please. By experimentation, they do actually work as expected if added, but the message would have you think otherwise. Thanks Kerry (talk) 05:49, 30 July 2021 (UTC)

That is not a cs1|2 issue but rather is an issue with VE's template data. You are free to edit the template data to add usurped and unfit. There are 27 cs1|2 templates so you should check and update all of them.

—Trappist the monk (talk) 12:01, 30 July 2021 (UTC)

I've added the two to cite web as well as all four to cite news. Others may make similar edits for other templates. Izno (talk) 12:52, 30 July 2021 (UTC)

Identifier-specific template EBSCOhost

Moved thread to Template talk:EBSCOhost#Identifier-specific template EBSCOhost. --Matthiaspaul (talk) 22:29, 31 July 2021 (UTC)

display-authors bug

If you specify just one author and then invoke display-authors=1, you get an error. You need to specify an author2 to make it go away (even though author2 isn't displayed!). Urhixidur (talk) 15:19, 4 August 2021 (UTC)

You will get the same error when you have two authors and set |display-authors=2:

{{cite book |title=Title |author=First Author |author2=Second Author |display-authors=2}}

First Author; Second Author. Title. {{cite book}}: |author= has generic name (help); Invalid |display-authors=2 (help)

It is supposed to work that way. When there are only two authors, setting |display-authors=2 becomes meaningless. When there are more than two authors and you only want to display one of their names, then |display-authors=1 will suppress display of the second author name and add et al. to the rendering:

{{cite book |title=Title |author=First Author |author2=Second Author |display-authors=1}}

First Author; et al. Title. {{cite book}}: |author= has generic name (help)

When the template has only one of the two authors, set |display-authors=etal to indicate that the work has more authors whose names are not shown:

{{cite book |title=Title |author=First Author |display-authors=etal}}

First Author; et al. Title. {{cite book}}: |author= has generic name (help)

—Trappist the monk (talk) 15:28, 4 August 2021 (UTC)

The (help) link provides the three paths to fixing this error. Izno (talk) 16:14, 4 August 2021 (UTC)

As an aside - the Harv warning has changed to be bold from a brown-ish colour in the last couple of days - any idea what has changed? Keith D (talk) 13:00, 6 August 2021 (UTC)

There are two warnings for SFN. One set is emitted by the SFN module. Those are in red. The other set are from whichever of the three-ish scripts that detect bad SFNs. Those are the brown-ish color. While they may have changed in shade or something, the latter has always been that color. Izno (talk) 13:36, 6 August 2021 (UTC)

My script has not changed and shows the warning messages for the above citations like this:

<span class=warning style="font-size:100%">Harv warning: There is no link pointing to this citation. The anchor is named CITEREFFirst_Author.</span>

Harv warning: There is no link pointing to this citation. The anchor is named CITEREFFirst_Author.

But isn't class=warning going away? If it is, I should change the warning markup to:

<span style="color:#ac6600">Harv warning: There is no link pointing to this citation. The anchor is named CITEREFFirst_Author.</span>

Harv warning: There is no link pointing to this citation. The anchor is named CITEREFFirst_Author.

—Trappist the monk (talk) 14:12, 6 August 2021 (UTC)

You might consider emitting a class still so people can customize the color, but sure. Izno (talk) 14:55, 6 August 2021 (UTC)

I am using User:Ucucha/HarvErrors.js Keith D (talk) 19:15, 6 August 2021 (UTC)

No changes to that script since this edit in March 2021. Yesterday was WP:ITSTHURSDAY, there is some small discussion about skins at WP:VPT about monobook skin stuff; related?

—Trappist the monk (talk) 19:45, 6 August 2021 (UTC)

It could be but not clear from that what the changes would be. Looking at phab:T285991 seems to imply some changes needed in preferences, but cannot locate checkbox "Enable responsive MonoBook design". I have tried unticking "Enable responsive mode" but that makes no difference. Keith D (talk) 20:18, 6 August 2021 (UTC)

@Keith D: "Enable responsive MonoBook design" is no longer there. It was at Preferences → Appearance, between "Shared CSS/JavaScript for all wikis (more information):" and "Reading preferences". I think it was removed when "Enable responsive mode" was added a little higher up. --Redrose64 🌹 (talk) 22:41, 6 August 2021 (UTC)

Yes, these preferences were flipped; this was in either last week's tech news or the week before's. Izno (talk) 17:41, 8 August 2021 (UTC)

when |archive-url= is broken

In normal display mode (what readers see), broken archive urls are ignored except that the module emits an error message. When editors view the same article in preview mode, and when the archive url is an archive.org url, the module uses a modified form of the archive url. The purpose of that is to enable editors to see archive.org's calendar view so that they might choose the url of an appropriate snapshot to replace the malformed archive url in the template. When |archive-url= holds a malformed archive url, the live module truncates the timestamp from 14 to 6 digits and appends a splat (*). That used to work. So, I have tweaked the code so that the new preview-mode archive url uses the first six (YYYYMM) or four (YYYY) digits of the timestamp, zero-fills to 14 digits, and then appends the splat. To see this in action, you must edit this section (or page) and preview.

Cite web comparison
Wikitext	`{{cite web\|access-date=November 3, 2008\|archive-date=2017-06-14\|archive-url=https://web.archive.org/web/20170614/http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html\|publisher=Intellivision Productions\|title=Ask Hal: Frequently Asked Questions to the Blue Sky Rangers\|url=http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html}}`
Live	"Ask Hal: Frequently Asked Questions to the Blue Sky Rangers". Intellivision Productions. Retrieved 2008-11-03. `{{cite web}}`: `\|archive-url=` is malformed: timestamp (help)
Sandbox	"Ask Hal: Frequently Asked Questions to the Blue Sky Rangers". Intellivision Productions. Retrieved 2008-11-03. `{{cite web}}`: `\|archive-url=` is malformed: timestamp (help)

In the above examples, the live version links to a "We're sorry — something's gone wrong" page while the sandbox links to the calendar view.

—Trappist the monk (talk) 19:38, 5 August 2021 (UTC)

Thanks for making this feature work again. (For those interested in the background of this feature, see: Help_talk:Citation_Style_1/Archive_13#web.archive.org/save/...)

However, the "*"-wildcard still seems to work fine with 0-, 4- and 8-digit timecodes, so the zero-filling does not appear to be necessary in all cases:

BTW, if you truncate the archive URL to |archive-url=https://web.archive.org/web/20170614 or shorter, the new implementation throws a Lua error in "Module:Citation/CS1/sandbox at line 2379: attempt to index local 'timestamp' (a nil value)."

The utility of the feature could be further improved if we would allow it to accept |archive-url=http://web.archive.org/web/ as an entry shortcut forcing it to take the URL from the |url= parameter and optionally the timestamp from the |archive-date= parameter to automatically form archive URLs like https://web.archive.org/web/*/http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html or https://web.archive.org/web/20170614*/http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html for the error message, so that editors could utilize our preview to select or create a snapshot from/at archive.org with a minimum amount of keystrokes.

--Matthiaspaul (talk) 02:55, 6 August 2021 (UTC)

Fixed the script error:

Cite web comparison
Wikitext	`{{cite web\|access-date=November 3, 2008\|archive-date=2017-06-14\|archive-url=https://web.archive.org/web/20170614\|publisher=Intellivision Productions\|title=Ask Hal: Frequently Asked Questions to the Blue Sky Rangers\|url=http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html}}`
Live	"Ask Hal: Frequently Asked Questions to the Blue Sky Rangers". Intellivision Productions. Retrieved 2008-11-03. `{{cite web}}`: `\|archive-url=` is malformed: timestamp (help)
Sandbox	"Ask Hal: Frequently Asked Questions to the Blue Sky Rangers". Intellivision Productions. Retrieved 2008-11-03. `{{cite web}}`: `\|archive-url=` is malformed: timestamp (help)

—Trappist the monk (talk) 11:39, 6 August 2021 (UTC)

Cite magazine – why upper case Vol.?

Why does {{Cite magazine}} emit volume in upper case: {{cite magazine|title=Some title|magazine=Some Magazine|volume=17}} -> "Some title". Some Magazine. Vol. 17. ? -- Michael Bednarek (talk) 09:23, 7 August 2021 (UTC)

Because it follows a period. Headbomb {t · c · p · b} 10:39, 7 August 2021 (UTC)

OK. Sorry if I'm a pest, but why then is page in lower case? — "Some title". Some Magazine. Vol. 17. p. 18. -- Michael Bednarek (talk) 13:36, 7 August 2021 (UTC)

I don't think you're a pest, but the odds against getting a coherent answer to that are astronomical. Headbomb is right, of course, as you are in your question. 12.182.249.131 (talk) 14:16, 7 August 2021 (UTC)

Why do I hear Tevye in my head when he says, while singing "Tradition":

"You may ask, how did this tradition start?

I'll tell you – I don't know. But it's a tradition..."

—Trappist the monk (talk) 16:10, 7 August 2021 (UTC)

Markup in titles

Peeking at Category:CS1 errors: markup, I see it doesn't include fields like "title". I'm in the process of cleaning up lots of HTML entities (which shouldn't be in these fields either), and I've seen lots of instances of double single quotes (''...'') in the title field. On Misplaced Pages, this will make italics, but apparently italics are not allowed in COinS fields? Is this something that should be systematically fixed? -- Beland (talk) 07:48, 9 August 2021 (UTC)

If the title of an article includes a binomial name or the name of a genus then by convention this is placed in italics (using double single quotes). - Aa77zz (talk) 08:55, 9 August 2021 (UTC)

Absolutely, and anything else would be utterly wrong and strongly resisted by those who edit organism articles. Peter coxhead (talk) 09:32, 9 August 2021 (UTC)

Is this about Misplaced Pages article titles or the title field of a citation? If it is the latter, then it crashes into one of the CS1 non-sensical flaws, the fact that |title= may be the source (as in {{cite book}}), or a location within the source (as in {{cite journal}}). This is pertinent, because the title value is auto-formatted differently. In the case of title=source it would be in italics. Including italics markup, would cause the affected text to display in straight type. Because of the fundamental error of mis-defined and mis-applied parameters, more convoluted acrobatics have to be employed. Good luck! 65.88.88.57 (talk) 11:48, 9 August 2021 (UTC)

Italic wikimarkup is permitted where it is appropriate to use it. Bold markup is also allowed though I wonder if bold makes much sense in the context of a citation's title. This search (times out) finds some use of bold markup in |title=. We might create a maintenance category to track bold markup in |title=, |chapter= and aliases. Such categorization must be mindful of '''s (possessive form of italicized text).

—Trappist the monk (talk) 11:13, 9 August 2021 (UTC)

I thought kerning was handled in |title=. 65.88.88.57 (talk) 11:48, 9 August 2021 (UTC)

In titles that will be rendered in quotations ({{cite web}}, {{cite journal}}, etc), cs1|2 adds kerning when the title text has leading or trailing quote marks

{{cite periodical |title='leading' quote and trailing "quote" |periodical=Periodical}}

"'leading' quote and trailing "quote"". Periodical.

—Trappist the monk (talk) 12:01, 9 August 2021 (UTC)

Ok, this is the most basic case. Is there a problem with inserting a hair-space in code to account for others?

Also, I would include typographic emphasis in |title= if that is how the source is formatted, only as a help for the reader. There may be a minority of readers for whom anything but exact representation may cause confusion. However this additional emphasis should not be a requirement, just as (generally) adherence to case is not a requirement. There is already the semantic emphasis built in to the presentation of the work argument, and the occasional emphasis on |volume= (depending on day of the week, or something). This should be enough to attract readers' attention to the most important information in the citation. But there may be another minority of readers for whom any added emphasis may confuse. 65.88.88.57 (talk) 12:16, 9 August 2021 (UTC)

Triple quotation mark in such a case will cause an error anyway as it will bold the rest of the sentence, not close the italic. Izno (talk) 13:16, 9 August 2021 (UTC)

Umm, nope:

{{cite periodical |title=''Possessive italics'''s in title |periodical=Periodical}} and some trailing text

"Possessive italics's in title". Periodical. and some trailing text

—Trappist the monk (talk) 13:56, 9 August 2021 (UTC)

`{{cite web}}` template: please make the `title` parameter optional

For web sources, specifying titles often is not necessary but makes code longer and wastes editor’s time. There is no reason to make it required. Let editors decide whether the title is needed. VSL0 (talk) 03:58, 10 August 2021 (UTC)

Well it raises the question, necessary for what? What do you believe is the purpose of a citation? -- GreenC 04:06, 10 August 2021 (UTC)

@VSL0: Could you please provide some specific examples of citations where you believe specifying titles is not necessary? Thanks! GoingBatty (talk) 04:18, 10 August 2021 (UTC)

@GoingBatty: @GreenC: The {{cite web}} template is often used just for referencing (providing the source of information), not necessary for a citation. VSL0 (talk) 04:45, 10 August 2021 (UTC)

"Just for referencing" "not necessary for a citation" is a contradiction. A reference is a citation and vice versa. Headbomb {t · c · p · b} 09:22, 10 August 2021 (UTC)

@GoingBatty: @GreenC: @Headbomb: The purpose of using {{cite web}} may be just providing the link to the source with specifying its date or access-date in a standard way. In case of accessible web sources there may be no need for knowing their titles in advance (especially if they don’t represent books, articles, publications), and this is enough for making the title parameter optional. Could anyone modify the template? VSL0 (talk) 07:44, 11 August 2021 (UTC)

I know the topic is considered closed, but if you allow, I believe an observation must be made. The purpose of {{cite web}} stated above is incorrect. Like all citation templates, its purpose is to formalize a citation according to a citation system, in this case CS1/2. Citations don't exist to provide links although they should, if they can. Linking is an ancillary to discovery and wikitext verification. As far as |title="Webpage Title" is concerned, it is rather helpful to the lay reader, the same way an in-source location such as "chapter" or "page" would be in print. The related comments below are also pertinent. 65.88.88.46 (talk) 15:51, 11 August 2021 (UTC)

My opinion is that very occasionally be some merit in omitting a title – for example, not every web page has a useful title. But those are rare cases, and I wouldn't support removing title as a required parameter, for the reasons outlined at Misplaced Pages:Bare URLs#What is wrong with bare URLs? In the vast majority of cases editors should be adding titles to their cites. Also, as a final point, it doesn't actually break anything if you omit the title - you'll still generate a cite, and if it's really "wasting your time" to add a title, then don't do it. Per the page I linked above, "If you only have time and inclination to copy the reference URL you found, we thank you for your contribution!" But such a cite should display a red error message, simply because it's very useful for you or anyone else who comes to the page after you, to know that a title ideally should be added. — Amakuru (talk) 08:27, 11 August 2021 (UTC)

There are several reasons why this is not a good idea:

omitting the title makes the link as susceptible to linkrot as using a bare url rather than the template.
titles are an indicator to the reader as to what the linked web page is about.
if a web page is so poorly designed as to not have a title then I'd be questioning it's suitability as a reliable source. Nthep (talk) 08:30, 11 August 2021 (UTC)

@Amakuru: @Nthep: I rather agree, and the topic may be considered closed. VSL0 (talk) 11:52, 11 August 2021 (UTC)

IMO now theoretical since the discussion is closed anyway, the purpose of a citation on Misplaced Pages is to facilitate finding and verifying a source. The citation is a means to an end. If a title exists, it would be so significant to finding the source it would be required. If no title exists, I don't know. Would need to see examples. Often in those cases the title is descriptive eg. "Facebook post by A_User on a Topic". -- GreenC 16:46, 11 August 2021 (UTC)

Location within large tree-structured documents with no page numbers

I often need to cite material from a tree-structured document with no page numbers. Typically there is a sidebar for navigation. If section foo.bar.baz has a stable URL then I can use |section-url=, but often there is none. Ideally I would like to mark it up with something like

{{cite document
 |     title =  Manual with nested sections and no page numbers
 | section-1 =  foo
 | section-2 =  bar
 | section-3 =  baz
 }}

However, nothing like |section-n= is implemented. |section=foo: bar: baz and |section=foo - bar - baz look clunky. What is the best way to mark up such citations? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:42, 11 August 2021 (UTC)

This looks like you are trying to cite multiple sources with a cs1|2 template that is designed to cite one source at a time. Along with your |section1=, |section2=, |section3= your next request will be for |section-url1=, |section-url2=, |section-url3=, etc. And, how would that render? cs1|2 citations are complex enough, I don't think that we should be making them more complex by attempting to cite multiple sources with a single template. As an aside, this is why I want to do away with |lay-url= and its companions.

Still, perhaps something like what you want is already available and linking is possible but ugly, very ugly:

{{cite manual |title=Manual with nested sections and no page numbers |at=§foo, §bar, §}}

Manual with nested sections and no page numbers. §foo, §bar, §baz.

And don't use {{cite document}} to cite a manual. {{cite document}} is a redirect to {{cite journal}}. Why? Don't know; it really ought not to redirect there... {{cite manual}} as I used here is a redirect to {{cite book}}.

—Trappist the monk (talk) 17:14, 11 August 2021 (UTC)

I don't know why you wrote This looks like you are trying to cite multiple sources with a cs1|2 template that is designed to cite one source at a time., since the first three sentences clearly are describing a single source that is at a third level branch of the navigation sidebar. That is, on the navigation bar of the web page, you have something like

Extraneous content entries
Content entry for section foo
- Extraneous content entries
- Content entry for subsection bar of section foo
  - Extraneous content entries
  - Content entry for subsubsection baz of subsection bar of foo

where the intended citation is for only for subsubsection baz of subsection bar of foo, not for the enclosing foo or bar. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 11:28, 12 August 2021 (UTC)

I know what you wrote, but to me, your example template skeleton seems to contradict your initial statement; mostly because you did not describe how such an assemblage of parameters is to be rendered. That is why I wrote what I wrote. If you are citing section 'baz', then the title of section baz should be all that you need.

Even were we to create enumerated |section<n>= parameters, you still have some sort of clunky rendering if you want all of those hierarchical names in the rendered citation:

"Content entry for section foo > Content entry for subsection bar of section foo > Content entry for subsubsection baz of subsection bar of foo". Manual Title.

Isn't |section=Content entry for subsubsection baz of subsection bar of foo sufficient?

—Trappist the monk (talk) 12:04, 12 August 2021 (UTC)

I didn't mention rendering because I'm more concerned with semantics than layout. If someone implements |level-n-section= then I could live with whatever rendering they chose. I'd probably prefer "level-1 > level-2 > level-3", but that's a nit.

The name of the lowest level branch is definitely not all I need, since it doesn't tell the reader how to navigate to that. |section=Content entry for subsubsection baz of subsection bar of foo is sufficient. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:10, 13 August 2021 (UTC)

Identificativo SBN

Is there a way to put an Identificativo SBN (Italian identifier) in Cite book and similar templates?--Carnby (talk) 08:10, 12 August 2021 (UTC)

@Carnby: The cheap and nasty workaround is to use others=SBN 123456. Otherwise you have to request an addition to the template: I have no idea how you would do that. --John Maynard Friedman (talk) 09:53, 12 August 2021 (UTC)

@John Maynard Friedman: |others= is for 'other' contributors; not for miscellaneous identifiers.

Carnby: use |id=Identificativo SBN: <identifier number>

—Trappist the monk (talk) 11:39, 12 August 2021 (UTC)

We have a dedicated template for this, so ideally you would use |id={{ICCU|number}}. (It is not named {{SBN}} because of the name conflict with the ISBN predecessor.)

--Matthiaspaul (talk) 10:57, 13 August 2021 (UTC)

Thank you very much, I didn't find that! Is it possible to add it as a normal identifier i.e. |iccu=? Thanks in advance.--Carnby (talk) 05:42, 14 August 2021 (UTC)

Undesirable behaviour of issue= in cite magazine when the issue is a month or months

No doubt this is in the archives but I can't find it. Take for example this citation:

Paul Lunde. "The Beginning of Hijri calendar". Saudi Aramco World Magazine. No. November/December 2005. Retrieved 2019-01-01.

The issue is "November/December 2005", it is nonsense to show it as "no. November/December 2005". The same problem would occur with "issue=Spring 2021" etc. Surely in the case where issues are numbered, the correct argument to use is "number="? How does it make sense to add a "no." prefix to "issue"? --John Maynard Friedman (talk) 09:46, 12 August 2021 (UTC)

Aren't those better handled as dates? (Doing so would require changing November/December to November–December)Nigel Ish (talk) 10:56, 12 August 2021 (UTC)

Agreed. In such cases, issues are dated, not numbered. 100.2.235.66 (talk) 11:46, 12 August 2021 (UTC)

No, that gives a very ugly result:

Paul Lunde (November–December 2005). "The Beginning of Hijri calendar". Saudi Aramco World Magazine. Retrieved 2019-01-01.

which I admit is used and works fine for {{cite news}}. In this example, the 'issue=' setting puts the information in the logical place (after the title) in the citation: the only problem is that addition of the inappropriate 'no.' Why is that intrusion ever needed?

Using (a test) number= gives

Paul Lunde. "The Beginning of Hijri calendar". Saudi Aramco World Magazine. No. 567. Retrieved 2019-01-01.

where the element is positioned logically and the insertion of 'No.' is entirely appropriate. --John Maynard Friedman (talk) 13:24, 12 August 2021 (UTC)

Here is the pdf of the Saudi Aramco World magazine issue in question. Note that this issue is volume 56 number 6 and the date is November/December 2005 so:

{{cite magazine |url=https://archive.aramcoworld.com/pdf/2000/200506.pdf |title=Patterns of Moon, Patterns of Sun |first=Paul |last=Lunde |magazine=Saudi Aramco World |date=November–December 2005 |volume=56 |issue=6 |access-date=2021-08-12}}

Lunde, Paul (November–December 2005). "Patterns of Moon, Patterns of Sun" (PDF). Saudi Aramco World. Vol. 56, no. 6. Retrieved 2021-08-12.

—Trappist the monk (talk) 14:04, 12 August 2021 (UTC)

Touché! I shall go and stand in the corner for the rest of the class for not having checked a citation after I cleaned it up.

BTW, why did you use "issue=6" and not "number=6"? Are they in fact synonymous, two names for the same bit of programming? If so, then that would explain everything and it will be obvious that my proposal (that issue= should not insert No. ) must get spiked. --John Maynard Friedman (talk) 17:51, 13 August 2021 (UTC)

|issue= and |number= are aliases.

—Trappist the monk (talk) 18:11, 13 August 2021 (UTC)

@John Maynard Friedman: Further to what Trappist wrote, the documentation explicitly shows that |number= is an alias for |issue=. So they must be expected to behave identically. --Redrose64 🌹 (talk) 22:56, 13 August 2021 (UTC)

@Redrose64: Add failure to RTFM to my sins. Detention as well for my pains.

(But they should be different, they have different meanings, so it was not just a lazy assumption. . In my sample citation, the issue is November/December, the number is 6. The date of publication is most likely to have been October. Most "in your local newsagent" magazines come out best part of a month before their declared issue date .) --John Maynard Friedman (talk) 23:23, 13 August 2021 (UTC)

(edit-conflict) |issue=6 is not wrong at present, but |number=6 would be better in this case to improve forward compatibility. At present, both parameters are treated as aliases and produce identical output. But different periodicals use different nomenclatures. It is therefore a good idea to use |issue= when the publication uses "Issues" as well, and |number= when they use "Numbers", so that the template can adapt and generate the appropriate prefix "Iss." or "No.". If the publication itself does not prescribe a certain nomenclature, it is best to use issues for volume-relative numbering schemes (as well as non-numeric issue names/titles) and number for absolute numbering schemes (because that's what most periodicals use - but not all).

Also, when we will finally add support for periodicals featuring both, a number and an issue (requested multiple times and planned for a long while), we will have to better distinguish between them to generate the proper output.

As discussed above, a date belongs into the |date= parameter, but there are cases where issues have actual names or titles. This still looks reasonably good in conjunction with |issue= ("Special issue") but not with |number=.

--Matthiaspaul (talk) 18:23, 13 August 2021 (UTC)

I suggest you put aside notions of "ugly". Most citation systems use terse, functional statements. Aesthetics rarely if at all enter the discussion. That doesn't mean that formatting cannot be improved, but such improvement must primarily enhance understanding and utility. 64.18.9.209 (talk) 14:32, 12 August 2021 (UTC)

I think that misses the point. The description "November/December 2005" is an adjectival phrase that relates to the magazine, not to the author. Fine, forget "ugly": let's be honest and say "amateurish". --John Maynard Friedman (talk) 17:51, 13 August 2021 (UTC)

That part of the style is consistent with the academic citation styles on which it is based.Nigel Ish (talk) 18:03, 13 August 2021 (UTC)

Well, the entire Misplaced Pages citation ecosystem, including CS1/2 has many, many faults in design, implementation, and documentation, not all which stem from misconceptions of what a citation system geared to non-expert users (readers) should be. But this case is fairly straightforward and easily addressable. The issue number and/or date are useful in locating the source, and if known should be made available, in a way that is obvious and clear. If the issue series is dated rather than numbered, use that information anywhere it makes sense. There is nothing wrong, ugly or amateurish in entering the issue date in the date field. This is correct. The formatting of the date itself is a different issue and does not affect the needed data. 69.193.187.30 (talk) 21:19, 13 August 2021 (UTC)

There may be nothing wrong with entering the issue date in the date field, but there are occasional instances when it won't work; notably, when journals use wacky dates like "Michaelmas" and "Trinity" for their issues . —David Eppstein (talk) 21:36, 13 August 2021 (UTC)

OK, some magical process will turn static forms that apply certain generic positional & formatting rules - the so-called CS1/CS2 citation statements - into dymamic AI appliances that will perfectly account for every single special case under the sun, no matter how rare. Even though the current existing non-magical documentation at least hints otherwise, and even though 1. templates are not the only way to present CS1/CS2 citations and 2. CS1/2 citations are not the only way to reference. 68.173.76.118 (talk) 22:27, 13 August 2021 (UTC)

The templates can already accommodate some "non-date dates" - i.e. seasons, Easter and Christmas according to Help:Citation_Style_1#Dates - whether the templates are modified to accommodate others will depend on how often they are used.Nigel Ish (talk) 11:03, 16 August 2021 (UTC)

I think for this to be useful, we should support more or less complete sets. An editor of Christian topics would certainly wonder why s/he can enter "Christmas 2020", but not "Pentecost 2020", which both are used in clerical publications.

Let's try to come up with some list of named dates to be supported:

Michaelmas, Martinmas, Advent, Christmas, Candlemas, Hilary, Epiphany, Lent, Easter, Pentecost, Trinity
Midspring, Midsummer, Midautumn, Midwinter
Carnival
First Semester, Second Semester
Winter Semester, Summer Semester
First Quadrimester, Second Quadrimester, Third Quadrimester

--Matthiaspaul (talk) 03:08, 18 August 2021 (UTC) (updated 13:25, 18 August 2021 (UTC))

In some cases, suffixed with the word 'term', as in Michaelmas term, Easter term, Epiphany term, Hilary term, Lent term, Summer term and Trinity term. --John Maynard Friedman (talk) 20:51, 18 August 2021 (UTC)

For this to be useful, may I suggest to stop proposing additional unnecessary complexity. Especially when there are other issues with the existing modules. Misplaced Pages is not a science publication or a clerical publication, or whatever your area of expertise or interest may be. There is more than enough badly presented complexity already. How many citations dated "Pentecost (year)" justify the additional coding and documentation (and for non-Christians, additional explanation)? There is |issue= and |date=, and also |quote= where you can quote the date period verbatim. One or more of those 3 should be sufficient for a small minority of cases. 184.75.82.14 (talk) 21:35, 18 August 2021 (UTC)

I agree completely. These notations invariably indicate the issue of the periodical, not its date. But it seems that there is no consensus here for that view, despite it being the style used everywhere else. --John Maynard Friedman (talk) 22:20, 18 August 2021 (UTC)

It would certainly be easier if this would always be the case. Unfortunately, the real world is often more complicated than this. Please read up the old discussions which led to general support for seasons, quarters and named dates in our citation templates. As you write, sometimes these names can be seen as part of the issue (and then should also be reported as named issue in |issue=), but sometimes publications carry an |issue= in addition to a named date (and often no "normal" date at all). In these latter cases, these named dates need to be actually handled as a date in |date=, also for proper metadata generation. If not, it will become more difficult to locate these sources and obtain a copy of these publications in libraries, as they are often not found when stored under a different search key. There are even a number of dedicated COinS keys reserved for seasons (rft.ssn), quarters (rft.quarter) and named dates (rft.chron), clearly indicating that such dates are actually used in the publishing industry and that they need to be supported in the library business.

As editors of this encyclopedia, we have a duty to reproduce reference parameters as we find them (per our core policies on verifiability WP:V, neutral point of view WP:NPOV, and no original search WP:NOR), so we cannot simply "translate" a "Christmas issue" into a "December 24 issue" or a "Second Quarter issue" into an "April–June issue" just because we don't like these special dates - it would invalidate the reference making it difficult to find the publications. Also, we may be making invalid assumptions, as in some locales Christmas is in January, and quarters may start in different months depending on context.

As developers and maintainers of our citation templates we should make sure that editors are able to create citations faithfully reflecting what they find in the sources (perhaps after some minor normalization) without having to trick the templates or fall back to non-templated citations.

Editors like David Eppstein, Imzadi, Andy Dingley or Carcharoth have repeatedly asked to add support for them, not because they particularly "like" them, but simply because they run into them occasionally in their editing work. Many other editors don't have the stamina to come here asking but either give up on citation templates or invent unsupported workarounds which will lead to more inconsistency, more difficult maintainability, and lower accuracy and reliability.

Commentors in this forum should seek for ways how to make life easier for readers and editors, not unnecessarily worry about (often enough incorrectly) anticipated implementation difficulties most of them cannot fathom anyway or trying to set priorities - they can leave that to the few volunteering programmers.

What we do need your input for is when you see areas not fully or adequately covered by our templates yet and what kind of difficulties you run into or questions you might have when entering non-mainstream citations. Sharing these experiences with us will help to improve the templates and hence the quality of this encyclopedia (and quite a number of other projects taking indirectly advantage of our citations as well). Lamenting over the assumed complexity of a potential implementation does not - in the current somewhat schizophrenic situation, where people are criticizing our citation templates for non-performance in certain areas and at the same time actively hindering the developers to implement the necessary improvements, it will only slow down the process and thereby progress as a whole. Citations are diverse and therefore complex by their underlying nature, we can't change this, but what we can help do is making it easier and more reliable to enter them anyway.

The good news in this case is that, thanks to Trappist's great work, the infrastructure to support such special dates already exists in our templates since a couple of years (including the code for proper metadata generation), so adding more named dates does not actually add more complexity to the templates - it is, with minor exceptions, just adding more entries to an already existing table of named dates.

--Matthiaspaul (talk) 11:34, 19 August 2021 (UTC)

You make several assumptions and statements above that are not based on fact. First, there are several large and small issues with the module design and with the implementation of that design. Secondly, the documentation (at all levels: for readers, editors, and developers) is hardly adequate. These existing issues should imo be addressed first.

The policies of Misplaced Pages you mention apply mainly (and in some cases exclusively) to wikitext in article space. They also apply to things like having different citations that verify claims of all viewpoints present in the article, the citations mostly involving third-party sources with some past history of reliability. They do not apply to how citations themselves are structured. Instead, understandable citations are required to apply some of these policies. And that is it. Everything else: modules, templates, COins, formatting rules, etc. is irrelevant. Readers, who are Misplaced Pages's consumers, and the targeted recipients of its policies, do not need any of these add-ons to verify whatever nonsense one writes in article space. So, may I suggest that we make sure readers know why citations should exist. Make sure that they are presented in an understandable manner. Make sure that readers know what they consist of and why. And show them how they can verify the claims made in wikitext. Once you have a good idea about how to do all that, you can use it as the input for a citation system. You can even automate parts of that citation system, as one example, by using forms (templates). Any form standardizes a process, and thereby limits it, in order to be efficient, avoid the law of diminishing returns, for positive benefit/cost ratio etc. No form will ever account for all cases, but it can account for the basic, and most common cases. The basic cases are not a mystery. They are the minimal information needed to easily and quickly find the source that verifies the wikitext, because that is the point, and not how to embroider a citation.

When readers try to discover a source, they have several options: libraries, museums, bookstores etc., other repositories of sources, and of course electronic searches online. The institutions/trade entities may or may not keep their own catalogs, but they as well as the online search engines, closely follow the way marketing, trade, and bibliographic databases are indexed. Traditionally (and presently) these indices may use the author name, the source name, and a subset of the publication info: the publishing source, the publishing date, the published version, the publishing location, etc. And also one or more marketing, classification or content-location identifiers. Every time a reader asks a person or a piece of software to find them a source, someone or something will eventually or immediately consult one or more of those (relatively few) classification databases, whether they realize it or not. As pointed out in another post, in these classification databases date indices do not order text data, but date data. The calendars used are reduced to certain date formats that include numbers and a small number of keywords (days of week, month-names etc). Personally I have not ever encountered a periodical classification database that includes keywords such as "Christmas" in their date indices. I have seen such keywords in the very rare "Issue name" field, but mostly in special fields such as "Notes", "Other", "Misc."

So yes, even with their existing problems, CS1 templates can account for a "Christmas (year)" issue, by using one or more parameter as suggested in the previous post above. The source will be found. Resources can be used where needed in order to make a citation system that responds to readers first. Then we'll see about rare cases and if it is worth doing anything about them. 65.88.88.76 (talk) 21:09, 19 August 2021 (UTC)

It is certainly important both to the editor and the reader that the reference matches as far as is reasonable how the date is presented by the publication - we shouldn't expect people who are trawling through piles of magazines (or possibly having to buy back issues) to have to infer dates which differ between the actual paper copy and the citation. The key question is how often these non-standard dates are used - ones like seasons, quarters and to a lesser extent Christmas and Easter are used sufficiently frequently (I've seen most of these in real life, often without a corresponding 'normal' date) for them to be already implemented (after much discussion) - how frequently are the suggested extra examples (and other possible examples such as say Passover or Eid) actually used?Nigel Ish (talk) 21:47, 19 August 2021 (UTC)

Yeah, but back then our citation templates were really lacking support for them at a fundamental level. So this was a bigger issue. The infrastructure to support them first had to be implemented. Now, the effort isn't much more than adding a few more entries to a table.

The point here is that most editors running into these things in real life won't come here asking us to add support for them, and even if the occasional editor finds the way into our forum, it is very inefficient to add them one after another over a period of a decade. If someone can run into examples using "Christmas" or "Easter" it is quite obvious by extension, that there will also be publications using some of the other important Christian liturgical dates, maybe a little less common but this doesn't really matter as it doesn't add complexity, and, in fact, someone found examples for "Trinity", etc. a couple of years later. That's why I think we should do this a little bit more systematically, and add them in sets, rather than individually. We'd stop annoying those editors running into them but not reporting them here until someone finally comes around, and it will free our minds to work on other, probably more important things.

Regarding frequency of occurrence, fortunately they are rare. But they are also cheap to add. Until I was pointed to them in discussions I never saw those liturgical dates in publications, but I don't normally edit religious articles so the likelihood was low that I would run into them. Evidence has been given that they are actually used. Regarding the other entries, I personally ran into Midsummer, Carnival (as Karneval), and the various semester variants. Doing some dedicated research I also saw midwinter, midautumn and midspring, but I wouldn't have run into them if I wouldn't have searched for them. The quadrimester entries are derived from EDTF, a standard set up by the Library of Congress and many bibliographical institutions from all over the world (meanwhile also adopted by ISO). Obviously they saw a need to support them, and they are experts in the fields. Personally, I never saw them as "quadrimeters", only as "trimesters" (but apparently that's the same).

--Matthiaspaul (talk) 00:10, 20 August 2021 (UTC)

@Nigel Ish. These days, it is probable that the number of readers going through stacks of periodicals or buying back issues in order to verify a wikitext claim is smaller than the number of times an issue dated or labeled "Christmas (year)" appears in Misplaced Pages citations. It is much more likely they will ask someone or some thing for help. It was explained above what is likely to happen then. As was also pointed out before, there are ways to present rare dating info right now, even with rigid elements like templates. Sure, these ways may be stretching the use of the templates, but that is because the rare dating stretches the notion of "date". The entire point is that when there are other, more substantial issues regarding CS1, this and other minor (because rare) items can wait further judgement in time. In the meantime, one of the available fixes can be used. 64.18.10.203 (talk) 04:41, 20 August 2021 (UTC)

I have a list of 2.4 million journal and magazines like:

journal-of-black-psychology_2014-08_40_4
journal-of-primary-prevention_1982_spring_2_3
journal-of-occupational-and-environmental-medicine_1959-07_1_7

Note the "spring". The four seasons are most common. There are many "supplement, "index", "special issue". Also "first quarter". Many date ranges such as "jan-apr" (or "january-april"). And "winter-spring". Combos like "fourth quarter supplement" and "january-october cumulative". About 80 "christmas". About 20 "midsummer". Nothing with "semester" or "quadrimester". -- GreenC 05:17, 20 August 2021 (UTC)

Multiple URLs (split file)

We have this ref at United Airlines Flight 175

Federal Bureau of Investigation (2008-02-04). "Hijackers' Timeline" (PDF). NEFA Foundation. Archived from the original (PDF) on 2008-10-12. Retrieved 2008-10-06.

It's cited to a page on "NEFA Foundation", which isn't exactly reliable, but the report is the FBI's. The same report can be found on their website, but split into two portions (part-01-of-02, part-02-of-02) (perhaps for file size reasons). FBI site: . How can we use the URLs from fbi.gov directly, but only using one cite tag? ProcrastinatingReader (talk) 13:54, 15 August 2021 (UTC)

cs1|2 templates are designed to cite one source at a time. In United Airlines Flight 175, pages 218, 261, and 288 are the only pages cited in that report so the FBI part 2 source is all that is needed:

{{cite web |url=https://vault.fbi.gov/9-11%20Commission%20Report/9-11-chronology-part-02-of-02/ |title=Hijackers' Timeline (Redacted) (part 2 of 2) |website=Federal Bureau of Investigation |date=November 14, 2003 |access-date= |ref={{sfnref|''Federal Bureau of Investigation''|2003}}}}

"Hijackers' Timeline (Redacted) (part 2 of 2)". Federal Bureau of Investigation. 2003-11-14.

You could include a link to part 1 of 2 under §Further reading if it is important.

—Trappist the monk (talk) 14:55, 15 August 2021 (UTC)

If I run into this situation, I typically append such extra links as raw URLs in square brackets (without title) to the end of the citation, that is, between the template's closing }} brackets and Mediawiki's closing </ref> tag:

Most often, such extra links are only meant to help prevent future link rot, so I want them to be rendered as short and unobtrusive as possible and deliberately don't add titles so that they don't consume much extra space in the reference. Since they are outside of the template's special handling for archived links, I typically choose archived links for them if available.

If the source is available only in form of individual PDFs on a per-page basis, the links are probably better worked into the |pages= parameter instead.

When the source is splitted over several multi-page-files (as in your example) and the reference is citing multiple pages distributed over several files, splitting the reference into multiple citations (as indirectly suggested by Trappist above) is certainly an option, but in most cases I find references to the same source (but page numbers) in multiple citations are adding too much redundancy and I therefore try to combine them into a single reference including such appended raw links.

Not ideal, but there isn't much the templates could do to improve this situation because there is only one title. The only thing that could be improved by having multiple numbered |urln= parameters would be that the extra links could be displayed immediately following the title instead of at the end of the main citation, like:

Hijackers' Timeline (Redacted)I II

But still, display of dates and handling of archive links would only work for the main link, and metadata creation would be more complicated. Not sure if this would be worth it.

--Matthiaspaul (talk) 21:43, 15 August 2021 (UTC)

Abusing the |type= parameter (which does not become part of the COinS metadata) could be used to produce a more reasonable rendering of multiple links - without solving the underlying problems with handling multiple dates and archive links, of course. However, while the current live version of the template does not produce any error message, the sandboxed version will throw an "External link in |type=" error (per Help_talk:Citation_Style_1/Archive_77#url_in_name_parameters). For illustration purposes only:

Federal Bureau of Investigation (2008-02-04). "Hijackers' Timeline" (PDF) (I II). NEFA Foundation. Archived from the original (PDF) on 2008-10-12. Retrieved 2008-10-06. {{cite web}}: External link in |type= (help)

So, if we would want to add some limited support for multiple links, it could be implemented similar to |type=. Perhaps this could be combined with the rendering of what an already proposed |part= parameter would produce (if we would allow external links there).

--Matthiaspaul (talk) 03:48, 17 August 2021 (UTC)

Date quarters

Some publications give a date as year and quarter, but, e.g., |date=3Q 1984, yields an error message:

"foo" (Document). 3Q 1984. {{cite document}}: Check date values in: |date= (help); Cite document requires |publisher= (help)

Is there a legitimate way to enter a quarter in |date=? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:49, 16 August 2021 (UTC)

{{cite journal |title=foo |journal=Journal |date=Third Quarter 1984}}

"foo". Journal. Third Quarter 1984.

—Trappist the monk (talk) 15:29, 16 August 2021 (UTC)

But be prepared for a strange result when the author name is provided

Doe, John (Third Quarter 1984). "The unbearable brightness of fooing". Journal of Forensic Fooology.

which is far from ideal. Would Chatul be better advised to use issue= rather than (or even as well as) date= ?

{{cite journal |title= The unbearable brightness of fooing |journal=Journal of Forensic Fooology |date=1984 |issue=Third Quarter 1984 |first=John |last=Doe}}

which yields

Doe, John (1984). "The unbearable brightness of fooing". Journal of Forensic Fooology (Third Quarter 1984).

which I suspect is what Chatul might prefer (and be more convenient to use with {{harv}} or {{sfn}}. --John Maynard Friedman (talk) 16:48, 16 August 2021 (UTC)

No. The date parameter was specifically changed in the past year or so to accept quarterly dates. Your opinion on the appearance is, uh, noted elsewhere. Izno (talk) 18:34, 16 August 2021 (UTC)

@Izno: It is not just my opinion. I don't have access to Cite them right, but this document from Library Services at London Metropolitan University says that it is based on Pears, R; Shields, G (2013). Cite them right: the essential referencing guide (9th ed.). Basingstoke: Palgrave Macmillan.:

Some journals use the month or season of publication, or just a number instead of the volume and issue numbers. Enter these details after the journal title in your reference list.

(my emphasis). I have never, ever, seen a citation that looks like Izno (Spring-Summer 1821); every case I have found is simply Izno (1821). Maybe you have access and there is a case in point? I am very happy to be put right if I am mistaken. --John Maynard Friedman (talk) 15:07, 18 August 2021 (UTC)

cs1|2 is not beholden to Cite them right: the essential referencing guide or to Chicago Manual of Style or to any other style guide. In cs1|2 'style', when an author list is present, the publication date (|date= or |year=) is rendered after the author list. It has been thus since forever. Editors at en.wiki commonly provide seasonal dates:

Spring: ~8600 hits (search times out)

Summer: ~7400 hits (search times out)

Winter: ~5000 hits (search times out)

Fall: ~6300 hits (search times out)

Autumn: ~3700 (search times out)

and they even provide seasonal ranges:

Spring–Summer: ~700 hits

Summer–Fall: ~150 hits

Summer–Autumn: ~60 hits

Fall–Winter: ~280 hits

Autumn–Winter: ~100 hits

Winter–Spring: ~230 hits

there are other combinations that I leave to the reader.

—Trappist the monk (talk) 15:45, 18 August 2021 (UTC)

And anyway, sfn/harv will still be put in as the year. Izno (talk) 18:38, 16 August 2021 (UTC)

Where is |date=ordinal quarter year documented? Shouldn't it be included in the table of examples? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 16:56, 17 August 2021 (UTC)

They are documented at Help:Citation_Style_1#Dates. I have added them to the error help as well. --Matthiaspaul (talk) 17:42, 17 August 2021 (UTC)

I've added examples at Misplaced Pages:Manual of Style/Dates and numbers#Formats; do they look okay? --Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:30, 18 August 2021 (UTC)

I'm not convinced that the new examples belong in those two tables. MOS:DATES and those two tables were written to govern dates in article prose. cs1|2 has adopted MOS:DATES as the standard that governs date formats in the templates but cs1|2 does not have any authority to write the rules for article prose. Quarterly dates in article prose are not obliged to adhere to cs1|2 format rules. I think that the examples should be removed until there is a consensus at MOS:DATES to require a particular quarterly date format in article prose.

—Trappist the monk (talk) 12:59, 18 August 2021 (UTC)

References

Library Services (February 2016). "Harvard Referencing Guide" (PDF). London Metropolitan University. Retrieved 2021-08-18. (Section: Journal articles – print and electronic)

bad DOI check

The following throws an error, but it's resolving correctly

O'Mullane DM (2016). "Fluoride and Oral Health". Community Dental Health (33): 69–99. doi:10.1922/CDH_3707O’Mullane31.

Headbomb {t · c · p · b} 09:27, 17 August 2021 (UTC)

Given that we support both U+0027 and U+02BC, it seems we should support U+2019 as well (although I hate it).

--Matthiaspaul (talk) 10:38, 17 August 2021 (UTC)

Don't edit other editors' posts. I have restored the U+2019 character.

—Trappist the monk (talk) 11:51, 17 August 2021 (UTC)

Sorry, that was completely unintentional - AGF, it should have been obvious that this was just a mistake. I used the preview to experiment with different characters inserted into the citation, got distracted with something else, and simply overlooked the changed character when I wrote my comment later on...

--Matthiaspaul (talk) 12:51, 17 August 2021 (UTC)

Fixed in the sandbox.

Cite journal comparison
Wikitext	`{{cite journal\|date=2016\|doi=10.1922/CDH_3707O’Mullane31\|issue=33\|journal=Community Dental Health\|pages=69–99\|title=Fluoride and Oral Health\|vauthors=O'Mullane DM}}`
Live	O'Mullane DM (2016). "Fluoride and Oral Health". Community Dental Health (33): 69–99. doi:10.1922/CDH_3707O’Mullane31.
Sandbox	O'Mullane DM (2016). "Fluoride and Oral Health". Community Dental Health (33): 69–99. doi:10.1922/CDH_3707O’Mullane31.

—Trappist the monk (talk) 11:51, 17 August 2021 (UTC)

There are probably other string functions we should be using mw.ustring for instead. You might consider having a general look. Izno (talk) 16:38, 17 August 2021 (UTC)

Support for slash in some date ranges?

Inspired by the discussion at Help_talk:Citation_Style_1#Undesirable_behaviour_of_issue=_in_cite_magazine_when_the_issue_is_a_month_or_months, I wonder if we should add support for two more date range formats allowed by our MOS, but not supported by CS1/CS2 at present:

Ranges with consecutive month names or years separated by "/" instead of "–". At present, they have to be "converted" into en-dash ranges:

"November/December 2020" → "November–December 2020"
"2020/2021" → "2020–2021"

For as long as only (non-digit) month names and/or 4-digit years are involved they appear to be free from any possible ambiguities.

The reason why it might be good to support them in citations is that, in the context of publications, if date ranges are used at all, they most often involve consecutive (weeks,) months or years, and if they are printed on a publications' cover, most often slashes are used rather than en-dashes, so a slash would look more "natural" in a citation when citing from, i.e., a bimonthly publication. It may also make entry of those ranges easier.

--Matthiaspaul (talk) 17:32, 17 August 2021 (UTC)

Your first step would be to change MOS:DATERANGE. – Jonesey95 (talk) 20:34, 17 August 2021 (UTC)

For the purposes of determining if adding support for this would be found useful, please assume MOS support to be a given.

Actually, the slash is one of the explictly allowed formats already for year ranges with consecutive years, so no changes to the MOS would be required:

"The slash notation (2005/2006) may be used to signify a fiscal year or other special period, if that convention is used in reliable sources"

"fiscal year or other special period in reliable sources" is exactly where we would use this in citations, that is, when the source uses this format as well (else we have little need to use it).

And somewhat further down:

"An overnight period may be expressed using a slash between two contiguous dates: the night raids of 30/31 May 1942 or raids of 31 May / 1 June 1942."

By extension and because it is not mentioned as disallowed, this would apply to consecutive months as well.

I have never seen consecutive days being used in publication dates, but consecutive months separated by a slash are quite common in bimonthly publications and special issues. I have very rarely seen endashes being used there, hence this proposal.

--Matthiaspaul (talk) 21:51, 17 August 2021 (UTC)

a given No, that's a waste of our time to entertain the idea. Please get support there first. Izno (talk) 21:53, 17 August 2021 (UTC)

Reliable sources, for the purposes of citations, are either our MOS directly or other style/citation guides, not reliable sources for a specific domain as with TNYT or a specific journal source.

Regarding slash between contiguous dates, that has a key word: "overnight". The examples are clearly not relevant. Izno (talk) 21:56, 17 August 2021 (UTC)

I recommend that the OP dig through the MOS talk page archives to find the origin of the support for the slash notation, which clearly means "one part of one period, connected to a contiguous part of a subsequent period", like July 2005 through June 2006 for a fiscal year, or 9 pm on 30 May through 5 am on 31 May for a "night of". The slash notation is clearly not applicable to a range covering two full time periods, like November–December, which is what the date of a periodical intends. To say it another way, you could have "the nights of 29/30 May and 30/31 May" as acceptable usage, but not "the magazine issues for October/November 2005 and November/December 2005". – Jonesey95 (talk) 00:51, 18 August 2021 (UTC)

Jonesey, thanks for taking up this discussion constructively. You are bringing up an interesting aspect.

I can't see these implied differences being made in the relevant MOS text, but from my personal experience I agree that the slash notation has multiple implied meanings whereas the en-dash notation almost always means a complete period.

However, if these differences are real, it would be even less desirable to blindly convert "2020/2021" or "November/December 2020" found in a source into "2020–2021" or "November–December 2020" in a citation (as we currently have to do because CS1/CS2 does not support the slash notation). Depending on circumstances it could change the meaning considerably and thereby invalidate the citation. If we do not know exactly what it means in a particular context, it is best to just use what is used in the source, similar to keeping a "Christmas 2020" date designation "as is" in a citation instead of trying to convert this into a specific date - because even in the Western world it could refer to the 2020-12-23, 2020-12-24, 2020-12-25 or 2020-12-26 or various combinations thereof (and in most cases the actual publication date would be several days earlier, anyway).

--Matthiaspaul (talk) 02:29, 18 August 2021 (UTC)

I, too, often find the date and issue CS1 rules too restrictive. If we remember that the whole purpose of bibliographical references is to provide the most complete and unambiguous link to the source, then if the source says "July/August 2021 issue", that is exacly how you would find it on the shelf in your library. In this case, July/August means "July and August" issue, so it is not a MOS:DATERANGE thing (July to August issue does not sound right, right?). Example here (title:&, text: /, and). In the past, a slash was used instead of today's comma, meaning "and" or "or". What gives us right to say Vanity Fair, Vogue, Elle, The Architectural Review, Dwell, Smithsonian Magazine, Men's Health, BA, The Atlantic (…) are all wrong and should be corrected to use an en-dash instead of their forward slashes? Ponor (talk) 02:56, 18 August 2021 (UTC)

Citations are not bibliographic references. Also, any contiguous dates/date elements taken together constitute a time interval (range) irrespective of their separator. "July and August" is a range. The norm in CS1 has been to follow Misplaced Pages's MOS when possible, including the presentation of date ranges, although there are significant exceptions. But the date field in any citation system does not have to be presented verbatim. As long as the correct data is input in some form the work will be found by date, Date indices do not index text strings, but date data formatted according to masks/templates that may include ranges and the like. You would be just as likely to find a "July/August" item as a "July–August" item. The significant info, which indices understand, is "July" (in proximity, {AND/OR}) to "August". The separator used in the literal expression is a matter of presentation. 24.103.251.114 (talk) 12:16, 18 August 2021 (UTC)

The bigger question is why do people expect that the templated CS1 solutions will apply to every case they can think of, and generally solve all problems. Where does this expectation come from? It is not as if these templates are obligatory. Development-wise such minor issues of presentation like the object of this thread are very much secondary. There are far more substantial development issues that may be tackled. Although, if I was a developer here I wouldn't lift a finger to cross a t. In this environment developers are expected to justify use of tracking elements. Any serious programmer would laugh you out of the room :) 24.103.251.114 (talk) 12:30, 18 August 2021 (UTC)

I don't know what citations and bibliographical references are to you, we're discussing the latter. Those who (actually) write Misplaced Pages articles will find sources that have "July/August 2021" as their publication date, and will (not knowing the ""correct"" way) try to use them verbatim:

"Laughter". Journal of Serious Programmers. July/August 2021. {{cite journal}}: Check date values in: |date= (help).

See what happens here, see all the redness? It says it's wrong, even though it's not. This is a citation template (producing a bibl. reference) being smarter than the editor in a pretty common use case. That's not nice, just as it's not nice to be laughed at by a bunch of serious programmers... but I see that as their problem, not mine. Ponor (talk) 13:22, 18 August 2021 (UTC)

CS1 is its own style regarding dates which comes out of WP:MOSDATE. I do not see anyone laughing at you. We have instead pointed you to the correct location if you should want to change that style. Izno (talk) 14:40, 18 August 2021 (UTC)

The documentation, with all its problems, nevertheless clearly lays out what is right and wrong in the context of the non-obligatory CS1 templates. If you wish to use these templates, follow the guidelines. A bibliographical reference is information about a certain work. It usually includes a wealth of detail (depending on the bibliographic database) about the provenance, publishing history, editions etc. of the work. A citation in Misplaced Pages is information about quickly and easily locating a source in order to verify claims in wikitext. It is a different kind of animal. Those people who write articles in Misplaced Pages without reading the pertinent documentation will see all kinds of red messages. As for this minor issue, first clear it at MOS:DATERANGE. Don't "interpret" what is being stated regarding slashes and ranges, get an explicit answer. Then we can further discuss it here. I will add to Izno's comment: nobody is laughing at you, and the comment was referring to something else. It's not about you. 65.88.88.126 (talk) 15:45, 18 August 2021 (UTC)

So according to you, 24.103.251.114 or 65.88.88.126 or ???, nothing should ever be discussed on this page because CS1 templates are non-obligatory. Use them as they are or leave? What a bureaucratic argument, I'd never expect that from an Wikipedian. I think you're confusing bibliographical references with Bibliographic records (note wikilinks). Also, a Citation is only a little (inline) pointer to the full reference, even Misplaced Pages can teach us that. My argument is that WP:MOS should not apply to bibliographic data, because those data are used to locate sources. You wouldn't correct this title "Everything You Need to Know About the July/August Issue of ‘Men’s Fitness,’ Starring M…." would you? So why enforce July–August when that's not what you'd find in your library? Minor or not, it's an issue. Discussing it is non-obligatory. But whoever wants to discuss it, and has time to discuss it, and doesn't feel it's waste of her time to discuss it, should discuss it with arguments other than "waste of our time", "go change WP:MOS first"... That's not how Consensus is built. I'm sorry, but no one has answered any of Matthiaspaul's or my concerns yet. Ponor (talk) 02:31, 20 August 2021 (UTC)

I believe you misunderstand everything stated in the previous post, and that's fine. What is not fine is that you presume to know the motivation and thinking of others and then proceed on that presumption to make judgements and accusations out of thin air. That, coupled with putting your words on somebody else's mouth. A point-by-point rebuttal could be made, but what for? 64.18.10.208 (talk) 04:11, 20 August 2021 (UTC)

Push PMID limit up

Donders, T.; Panagiotopoulos, K.; Koutsodendris, A.; Bertini, A.; Mercuri, A. M.; Masi, A.; Combourieu-Nebout, N.; Joannin, S.; Kouli, K.; Kousis, I.; Peyron, O.; Torri, P.; Florenzano, A.; Francke, A.; Wagner, B.; Sadori, L. (2021). "1.36 million years of Mediterranean forest refugium dynamics in response to glacial–interglacial cycle strength". Proceedings of the National Academy of Sciences of the United States of America. 118 (34): e2026111118. doi:10.1073/pnas.2026111118. PMID 34400496.

This should not throw an error. Headbomb {t · c · p · b} 03:52, 18 August 2021 (UTC)

Seems fixed now... thanks to whoever did it. Headbomb {t · c · p · b} 15:55, 18 August 2021 (UTC)

non-English translator templates and substing

I have hacked an experiment to make {{literatur/sandbox}} invoke a lua module. That is discussed at Template talk:Literatur § lua module experiment.

Because that template is supposed to be subst'd when used, for the experimental module to work with the live Module:Citation/CS1, it will be necessary to change {{citation}} as I did to {{citation/new}} with this edit. Without that change, the subst returns the content of the citation template:

{{#invoke:citation/CS1/sandbox|citation
|CitationClass=citation
}}

and that is a pretty much pointless {{citation}}: Empty citation (help).

If the {{literatur/sandbox}} experiment is successful, then it makes some sense to do the same thing for other translation templates:

{{Cita news}} – requires the subst fix for {{cite news}} and {{cite book}}

{{Cita libro}} – requires the subst fix for {{cite book}}

{{Cite web/German}} – these require the subst fix for {{cite web}}

{{Cite web/Finnish}}

{{Cite web/Swedish}}

{{Cite web/Portuguese}}

{{Cite web/Danish}}

{{Cite web/French}}

{{Cite web/Polish}}

no doubt there are other translation templates (some of this list I found in Category:Infobox importer templates – why there?) You might think that there is a subcategory in Category:Citation Style 1 templates for translation templates ... There isn't.

So, I propose to modify {{citation}}, {{cite book}}, {{cite news}}, and {{cite web}} so that translation templates can be subst'd.

Opinions? Objections?

—Trappist the monk (talk) 20:03, 19 August 2021 (UTC)

Please test the change on one or another of the larger articles in existence (we really should have a list of go-tos) to establish that parser/expansion times are not problematically increased. Izno (talk) 14:57, 20 August 2021 (UTC)

Alas, that will be a problem. I don't know where one might find a large article with only {{citation}} templates so I created a test page (not saved) that had 1000 of this (grabbed from Module:Citation/CS1/testcases):

{{citation| url=http://books.google.ca/books?id=WrkzPcxBnLMC |title=Takhta untuk Rakyat: Celah-celah Kehidupan Sultan Hamengku Buwono IX |trans-title=Serving the People: The Life Story of Sultan Hamengku Buwono IX |language=Indonesian |isbn=978-979-22-6767-9 |editor1-first=Mohamad |editor1-last=Roem |editor1-link=Mohamad Roem |editor2-first=Mochtar |editor2-last=Lubis |editor2-link=Mochtar Lubis |editor3-first=Kustiniyati |editor3-last=Mochtar |editor4-first=Maimoen |editor4-last=S. |last=Nasution |first=A. H. |author-link=Abdul Haris Nasution |publisher=Gramedia Pustaka Utama |location=Jakarta |year=2011 |origyear=1982 |edition=Revised}}

Previewing that page rendered 930 templates before post‐expand include size limit was exceeded. The various times from the NewPP limit report were:

CPU time usage: 8.633 seconds

Real time usage: 8.611 seconds

Lua time usage: 6.165/10.000 seconds

and the Transclusion expansion time report (%,ms,calls,template)

100.00% 6926.279 1 -total

98.66% 6833.462 1000 Template:Citation

Then I changed the 1000 {{citation}} templates to {{citation/new}}. Previewing the page again, only 604 template rendered before post‐expand include size limit was exceeded. The various times from the NewPP limit report were:

CPU time usage: 13.342 seconds

Real time usage: 13.380 seconds

Lua time usage: 10.026/10.000 seconds

and the Transclusion expansion time report (%,ms,calls,template)

100.00% 11348.237 1 -total

98.16% 11139.520 1000 Template:Citation/new

I tried an experiment where I used {{ifsubst}} to choose between the subst'd form of the #invoke and the un-subst'd form

CPU time usage: 12.853 seconds

Real time usage: 12.828 seconds

Lua time usage: 9.639/10.000 seconds

and the Transclusion expansion time report (%,ms,calls,template)

100.00% 11316.758 1 -total

98.57% 11154.984 1000 Template:Citation/new

94.54% 10698.378 1000 Template:Ifsubst

I have removed the experiment so timing for {{citation/new}} is:

CPU time usage: 9.469 seconds

Real time usage: 9.441 seconds

Lua time usage: 6.951/10.000 seconds

and Transclusion expansion time report (%,ms,calls,template)

100.00% 7732.135 1 -total

98.69% 7630.937 1000 Template:Citation/new

So, I guess that we can say that for now, any module-based translation templates must not be subst'd.

I wonder if it's possible to have a {{citation/subst}} template that the translation template could call. The inside of that template would have the substable version of the Module:Citation/CS1 #invoke so when subst'd, would return a normal {{citation}} template except with the {{citation/subst}} name. If subst'd we might include a maint cat so that {{citation/subst}} might be manually tweaked back to {{citation}}. Perhaps a tweak to Module:Unsubst to add an expicit template-name override parameter to that would be in order... I'll ponder these ideas. For now, the subst experiment at {{citation/new}} has been reverted.

—Trappist the monk (talk) 17:14, 20 August 2021 (UTC)

Created {{citation/subst}} which can be called by the translator module. Without modification to Module:Unsubst, the resulting substitution of a {{Literatur/sandbox}} template is a {{citation/subst}} template. I have tweaked Module:Unsubst/sandbox so that {{citation/subst}} can supply an alternate name (in the current case, |$template-name=citation). When substing a {{Literatur/sandbox}} template using the Unsubst sandbox, the resulting substitution is a {{citation}} template. This, I think, solves the problem because {{citation/subst}} is only called by translation templates that need substing and then once subst'd, the template is a normal cs1|2 template.

Discussion about the change to Module:Unsubst is at Module talk:Unsubst § template invocation name override.

—Trappist the monk (talk) 18:30, 20 August 2021 (UTC)

Permanent errors

Note: I originally posted this at Template talk:Citation, but moved it here 'cos I think this is a more appropraite location.

Category:CS1 errors: unsupported parameter includes 22 pages in the Misplaced Pages namespace: 14 AFD pages, and 8 pages from the Signpost.

These pages should not be edited, so they are perma-clutter in this cleanup category.

Please can the CS1/2 module(s) be modified to stop categorising citation errors in these pages? Cleanup categories should be capable of being fully cleaned up, but these pages prevent that. --BrownHairedGirl (talk) • (contribs) 01:47, 21 August 2021 (UTC)

Categories:

Revision as of 01:47, 21 August 2021

Current version of page no longer contains cited facts. url-status=?

Replacing "--" by "–"...

summary messaging in the preview warning header

How to extlink the components of a multi-component publication

Incorrect spacing

Param suggestion: |page-url=

doi:10.119.1/foobar should throw an error

ref-duplicates-default detector flaw

Still an issue with book volumes

Date validation error

error messaging

HTML structure of a citation

Visual Editor claims that usurped is not expected in the url-status field

Identifier-specific template EBSCOhost

display-authors bug

when |archive-url= is broken

Cite magazine – why upper case Vol.?

Markup in titles

{{cite web}} template: please make the title parameter optional

Location within large tree-structured documents with no page numbers

Identificativo SBN

Undesirable behaviour of issue= in cite magazine when the issue is a month or months

Multiple URLs (split file)

Date quarters

bad DOI check

Support for slash in some date ranges?

Push PMID limit up

non-English translator templates and substing

Permanent errors

`{{cite web}}` template: please make the `title` parameter optional