Help talk:Citation Style 1: Difference between revisions

Latest revision as of 03:41, 7 September 2021

Skip to TOC
Skip to bottom

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.
Sign your posts by typing four tildes (~~~~).
New to Wikipedia? Welcome! Learn to edit; get help.

WT:CS1

To help centralise 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 page is of interest to multiple WikiProjects.

Other talk page banners

This talk page is automatically archived by ClueBot III. Threads with no replies in 30 days may be automatically moved.

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[1] 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)

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)

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. [https://www.dwc.knaw.nl/DL/publications/PU00018789.pdf I], [https://www.dwc.knaw.nl/DL/publications/PU00018803.pdf II], [https://www.dwc.knaw.nl/DL/publications/PU00018886.pdf III] | 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 = [https://www.dwc.knaw.nl/DL/publications/PU00018789.pdf 386–392], [https://www.dwc.knaw.nl/DL/publications/PU00018803.pdf 521–525], [https://www.dwc.knaw.nl/DL/publications/PU00018886.pdf 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", 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 [enough] 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. 3 September 1884. 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. 3 September 1884. 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 Wikipedia: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 [sic]. 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=[https://archive.org/details/cihm_07495/page/n255 237]. 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 know 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 Wikipedia. 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=[https://archive.org/details/cihm_07495/page/n255 237] (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=[*/page/n255 237] |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 />{{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 />{{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 ^{: bar, baz}, ^{: bar, baz} and ^{: p. bar, baz}. 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)

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.	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 Wikipedia: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 Wikipedia; 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[ing] 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 Wikipedia. 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)
Strongly 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)
Strong Support for Proposal 1. From a biology viewpoint the vast majority of of scientific journal citations are in an APA style-style which renders volume 8, issue 10 as 8(10) or 8(10) or 8(10). I feel it would be strange to include "vol." in a biology citation, but not unheard of. However, per MeegsC there really needs to be a change, there are so many scientific books published in volumes and cited with words to note the volumes. Jack (talk) 14:11, 22 August 2021 (UTC)
Proposal 1 - there is no way we can do proposal 2 without getting a lot of immediate friction from the community that will inevitably result in a workaround like the proposed |periodical-style= above which introduces yet more complication. Image the problem of creating a citation via automated means and trying to determine the right style to use for a particular article; then we need to have something like {{use dmy}} cluttering the top of every article. No, don't go that route. Proposal 1 maintains what already exists for {{cite journal}} which is by far the largest of all and will have the least friction while fixing the problem with the other smaller templates. -- GreenC 14:40, 22 August 2021 (UTC)

Wikipedia is not a science publication. It is also not a special-purpose vehicle for professionals of any sort, including those in the field of biology. There is also the argument that a solution tailored to the entire community (its readers) has to be bypassed because a minority (its editors, or a subset thereof) may cause a fuss. Not very surprising. "Wikipedians" :) often act with a sense of ownership, and also often throw fits. In the meantime Wikipedia, rather unselfconsciously, proclaims its own worthlessness. 195.123.233.197 (talk) 15:55, 22 August 2021 (UTC)

Definitely agree with the IP here. Articles are not WP:OWNed by any particular individuals, and if we decide here that using vol. 3 no. 2 is better than using 3 (2), a proposition I strongly agree with, then it is right and proper, for the benefit of our readers that we allow that to propagate to all articles which cite journals. — Amakuru (talk) 10:51, 23 August 2021 (UTC)

Who is "we"? Experience has shown, repeatedly, the community all million plus are sensitive to changes of status quo, and when "we" decide to changes things for their "readers" own good according to our expert and correct opinions, the 'pitchforks' come out and trenches are dug. IMO this is a more significant change then say |accessdate= vs. |access-date= and you know how that went, the battle lines now so hardened it is a dead issue, it will never get fixed. Once wide-scale attention is made to the issue, you loose control. Stay as close as possible to status quo and fix the small things that really need fixing, it will be successful. Come back later and deal with cite journal as a separate issue because chances are it will be no-consensus. -- GreenC 20:47, 23 August 2021 (UTC)

You are correct that any challenge to the status quo will cause a disturbance. Whether that should dissuade from applying the better solution is the question. If it does, mediocrity wins again. This is a norm here. After all, this is a project where without any sense of irony or self-awareness, the majority of its content is designated suspect by default. There is a small minority of so-called "good articles". Which one would think, should immediately give rise to the question, why should an encyclopedia publish articles that it has itself designated as non-good? Compared to such institutional schizophrenia the pitchforks no doubt already being sharpened over this thread seem like toothpicks. 195.123.233.197 (talk) 00:21, 24 August 2021 (UTC)

Proposal 2. I've long thought that the 3(2) format is not ideal for use in an encyclopedia, where most readers are not specialists and may not automatically know what it means. It's far better to explicitly spell out what is meant, using the vol. and no. nomenclature, as per the Chicago or MLA citation style. This should apply to any publication be it a journal, book, magazine or anything else. — Amakuru (talk) 10:47, 23 August 2021 (UTC)
Proposal 1. However, I would like a means to request that {{cite magazine}} use the same nomenclature as the publisher for the issue. --Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:18, 23 August 2021 (UTC)

error messaging

This is a sidetrack off of Help talk:Citation Style 1/Archive 77 § 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-00000079-QINU`"'<cite class="citation book cs1"></cite> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Empty citation ([[Help:CS1 errors#empty_citation|help]])</span>

{{cite book/new}}

{{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">{{[[Template:cite book|cite book]]}}</code>: </span><span class="cs1-visible-error citation-comment">Empty citation ([[Help:CS1 errors#empty_citation|help]])</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-00000083-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%2Fsafernicotine.wiki%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-hidden-error citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: </span><span class="cs1-hidden-error citation-comment">Cite journal requires <code class="cs1-code">&#124;journal=</code> ([[Help:CS1 errors#missing_periodical|help]])</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/Archive 77 § 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">{{[[Template:cite book|cite book]]}}</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> ([[Help:CS1 errors#accessdate_missing_url|help]])</span>[[Category:CS1 errors: access-date without URL]]

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

Authors. Title. {{cite book}}: |access-date= requires |url= (help)CS1 maint: uses authors parameter (link)

'"`UNIQ--templatestyles-00000090-QINU`"'<cite class="citation book cs1">Authors. ''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%2Fsafernicotine.wiki%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite book|cite book]]}}</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> ([[Help:CS1 errors#accessdate_missing_url|help]])</span><span class="cs1-maint citation-comment">CS1 maint: uses authors parameter ([[:Category:CS1 maint: uses authors parameter|link]])</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 [1961-10-09].

Manually crafted citation with COinS span inside <cite>:

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

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

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 "⧼globalcssjs-custom-css-js⧽" and "⧼prefs-reading⧽". 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)

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 Wikipedia, 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 Wikipedia 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 Wikipedia: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 Wikipedia 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, §[//example.com baz]}}

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 1 January 2019.

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 1 January 2019.

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 1 January 2019.

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. [xref Matthias P remark below]. 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 Wikipedia 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 [2]. —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
Holiday
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), 17:54, 27 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. Wikipedia 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 are 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 Wikipedia 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 Wikipedia'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 or so. 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 Wikipedia 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 (February 4, 2008). "Hijackers' Timeline" (PDF). NEFA Foundation. Archived from the original (PDF) on October 12, 2008. Retrieved October 6, 2008.

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: [3][4]. 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. November 14, 2003.

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: [5][6]

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". 3Q 1984. {{cite journal}}: Check date values in: |date= (help); Cite journal requires |journal= (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).^[1] 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 Wikipedia: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 18 August 2021. (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 Wikipedia'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 Wikipedia 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 Wikipedia 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 Wikipedia 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 Wikipedia 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}}

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)

I created a subcat for citation translation templates under Category:Citation Style 1 translation templates

--Matthiaspaul (talk) 10:02, 21 August 2021 (UTC)

Permanent errors

Note: I originally posted this[7] 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 Wikipedia 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 the inclusion of these pages prevents that. --BrownHairedGirl (talk) • (contribs) 01:47, 21 August 2021 (UTC)

I think minor formatting corrections that do not change the actual discussion text are allowed on closed AfDs. —David Eppstein (talk) 02:21, 21 August 2021 (UTC)

Thanks, @David Eppstein. I corrected two of them, but after a re-think, I reckoned it might cause grief, so I gave up. I will re-start.

Do you think the same applies to the Signpost pages? --BrownHairedGirl (talk) • (contribs) 02:26, 21 August 2021 (UTC)

Typos are routinely fixed on Signpost pages; cleaning up unsupported parameters should be uncontroversial. isaacl (talk) 02:49, 21 August 2021 (UTC)

Unless changing the citation parameters would undermine the illustration of a problem or the flow of arguments in threads about CS1/CS2 citation template issues themselves, cleaning up such errors "under the hood" can only help to restore the former display of a citation and thereby preserve its original meaning or intention, so it is helpful maintenance not controversial.

When I (have to) edit such pages I leave a HTML comment near the change indicating what was changed and why.

If the problem can't be fixed by adjusting the template parameters (for example because this would change the meaning of arguments), an alternative to actually fixing the problem is to disable the template's categorization by adding a |no-tracking=yes parameter to the offending citation. But this requires editing as well, of course.

--Matthiaspaul (talk) 07:35, 21 August 2021 (UTC)

The simple fix is |no-tracking=yes. It leaves the citation template as it was, shows the error messages, but keeps the page out of error categories.

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

Many thanks, Trappist the monk.

|no-tracking=yes is the least intrusive solution, so I will do that. --BrownHairedGirl (talk) • (contribs) 18:02, 21 August 2021 (UTC)

All those pages have now been cleared from the category. --BrownHairedGirl (talk) • (contribs) 18:38, 21 August 2021 (UTC)

I routinely correct the kinds of pages in question and have had only one editor be annoyed (after which I explained that it was fine for various reasons, and he assented). Izno (talk) 15:43, 21 August 2021 (UTC)

Reftag error messages

Hello, http://reftag.appspot.com/ has been generating this error message for most of this week. Reftag shortens a googlebook url and usually provides the complete cite book reference, including ISBN. Reftag is mentioned in See also at the end of this article Template:Cite book. It is also the topic of this article here.

Error: Server Error The server encountered an error and could not complete your request.

Please try again in 30 seconds.

Nothing improves in 30 seconds or 3 days. Has the link for this helpful tool in Cite Book format been changed?

Thanks. --Prairieplant (talk) 04:07, 21 August 2021 (UTC)

Unfortunately, we can't help you with that one here. This is not a CS1/CS2 citation template issue, but related to an external tool out of our control. You will have to ask the maintainer of the tool for help, who fortunately happens to have a Wikipedia account at User talk:Apoc2400. --Matthiaspaul (talk) 07:48, 21 August 2021 (UTC)

Thank you for the link to Apoc2400. I have left a message at the talk page, and it turns out I am the second person to mention these error messages when trying to use the citation tool. --Prairieplant (talk) 04:40, 23 August 2021 (UTC)

Template:Cite_serial#In-source_locations

Template:Cite_serial#In-source_locations says that |season= is a supported parameter.

But at Amy's Choice (Doctor Who)#Continuity (permalink to current version), two refs using |season= are throwing a error:

Russell T Davies (writer), Euros Lyn (director) (25 December 2009 – 1 January 2010). The End of Time. Doctor Who. BBC. BBC One. {{cite serial}}: Unknown parameter |season= ignored (help)
Robert Holmes (writer), Peter Moffatt (director) (16 February – 2 March 1985). The Two Doctors. Doctor Who. BBC. BBC One. {{cite serial}}: Unknown parameter |season= ignored (help)

How can this be fixed? --BrownHairedGirl (talk) • (contribs) 02:59, 22 August 2021 (UTC)

Try using |series= instead? In any case, this is the correct term for post-revival Doctor Who, see WP:WHO/MOS#Terminology. --Redrose64 🌹 (talk) 07:31, 22 August 2021 (UTC)

@Redrose64: see the examples above. |series= is already in use.

I have no interest in the topic. This is just drive-by maintenance.

I just want to get the citations to display the contents of each param to the citation, and thereby remove the page from Category:CS1 errors: unsupported parameter. The documentation says the current setup should work, but it doesn't

--BrownHairedGirl (talk) • (contribs) 10:38, 22 August 2021 (UTC)

Support for |season= was withdrawn from {{cite serial}} with this edit which updated the wikitext version of the template to use {{citation/core}}.

I have updated the {{cite serial}} doc.

—Trappist the monk (talk) 11:08, 22 August 2021 (UTC)

@Trappist the monk: thanks. --BrownHairedGirl (talk) • (contribs) 23:11, 23 August 2021 (UTC)

"With Smith, John" in work lists

Many pages for academics have a "Works" or "Books" section that lists out their authored books, etc. (example). For these, I often like to use the CS1 citation templates, just without the surrounding ref tags and without the author parameters, as the author can be presumed to be the subject of the page. However, this gets tricky when there are multiple authors, as listing out only the other authors would be confusing and give the impression that the subject wasn't actually involved. For these instances, I could just write out With {{citation|last=Smith|first=John|title=..., but I feel like that wouldn't be good for the metadata. Is there a way to do this better within the citation template itself? If not, could we create it? {{u|Sdkb}} ^talk 05:17, 27 August 2021 (UTC)

You're looking for the parameter |author-mask= and its cousins |author-maskn=, I believe. — JohnFromPinckney (talk / edits) 06:16, 27 August 2021 (UTC)

Thanks! I just tried it here; hopefully I did it right. {{u|Sdkb}} ^talk 06:34, 27 August 2021 (UTC)

You're welcome. You got close, but you've surely already seen that Headbomb and Redrose have tweaked the cites for you. HE, — JohnFromPinckney (talk / edits) 08:52, 27 August 2021 (UTC)

The proper solution has been found already but I'd like to add an additional remark against just leaving out (some or all of) the names (or in other cases omitting the title), as this would create incorrect metadata for the citation. Since our citations are machine-readable and are harvested by external parties, this would cause such incomplete citations to be distributed elsewhere (which can cause confusion and various synchronization or merging problems further down the chain, which eventually not only affects those third-parties but also ourselves when our editors use such external data in other articles).

So, the proper solution is, as correctly stated above, to provide all the data to make a citation self-complete, and then use special parameters (|author/editor/translator/...-maskn= for the names) to suppress certain values from the local output of the citation. (A similar case exists for titles, and we already have some means to mute titles but we are still lacking a proper method to specify a title for metadata but mask it in the local output - I hope we can address this when we add support for descriptive titles, which should show up locally without text decoration, but should not normally be made part of the metadata, or at least not without being specially marked).

--Matthiaspaul (talk) 18:35, 27 August 2021 (UTC)

Thanks; that's helpful to know! {{u|Sdkb}} ^talk 20:45, 27 August 2021 (UTC)

Same book source, different pages?

Good day,

Currently working on a major edit of MCW Metrobus, some of which involves adding book sources to previously unsourced content. But when using Template:Cite book, what general guidance is there for providing multiple sources from the same book? As in, one source uses the book on one set of pages, while another source uses the book on a different set of pages? Is there, perhaps, a way these sources can be 'combined' so there is no repetition, or is repetition the only way?

Cheers, Hullian111 (talk) 17:58, 27 August 2021 (UTC)

Hi Hullian, there are several ways how to accomplish this.

The easiest and most common method is to just combine the multiple pages into a list of cited pages in the |pages= parameter, and optionally merge the corresponding quotes from the source into the |quote= parameter (which has a separate |quote-pages= parameter, if the quotes are from a subset of those pages given in the |pages= parameter only). Once you have defined this citation through something like <ref name="YourRefName">{{cite book |YourCitationParameters=...}}</ref>, you can then invoke this citation by <ref name="YourRefName"/> whereever it is needed to support an article statement.

If you need to specify individual pages (or quotes) at the various places where you invoke your citation, you can append {{rp}} like this: <ref name="YourRefName"/>{{rp|YourPageNo}}. Some people like to combine this into a wrapper template {{r|YourRefName|p=YourPageNo}} - this gives exactly the same output but is shorter and easier to read.

All these methods are basically just variants of one main scheme how to produce citations. The advantage of all of them is that they require only one "References" section and that you can define the core citation either in the article body (so called "inline references") or, if you want to avoid the clutter a long citation definition might create in the middle of the wikitext for the article prose, it can be defined down in the "References" section (this is called "list defined references").

All the linking down to the citations and the backlinks from there up to the invocation is carried out automatically by Mediawiki without any necessary manual intervention.

There are a number of other citation methods as well, among them so called short references ({{sfn}}). Similar to {{rp}} they allow to specify short references with page numbers, but the linking works considerable different (the links are created by the templates, not by the underlying Mediawiki software which, depending on author names, dates and titles used in the core citation, can sometimes cause ambiguous or dangling pointers requiring manual fixup). Also, they require two special sections in the article, one for the short references (often named "References" or "Notes"), and another for the core citations (often named "Bibliography"). While it keeps the links in the prose extremely short even for citations with page number, this comes at the expense of an extra layer of indirection (the "References" section), which can add significant clutter to an article. Also, there are no backlinks from the core citations in the "Bibliography" section to the short references, which makes it more difficult to find and visit all invocations of a citation resolving to a single publication.

I think I would start with the first method because it is by far the most commonly used method, it covers the majority of scenarios well, and is the easiest to master. If you then need to specify individual pages this can be easily added using {{rp}} in a second step.

--Matthiaspaul (talk) 19:29, 27 August 2021 (UTC)

I think it is inaccurate to say that short references require two separate reference sections. A solution to this problem, using only a single references section, is: use a footnote containing the full reference for the first occurrence of the book among the references, and then use short citations created by {{sfn}} or {{sfnp}} for subsequent citations to different pages in the same book. Also, I would advise against using {{rp}}; it is an abomination that mixes up footnote markers with citation metadata and requires readers to remember one piece of a citation while they look up the other. I would prefer for all instances of it to be replaced by less-bad referencing styles. —David Eppstein (talk) 19:41, 27 August 2021 (UTC)

@Matthiaspaul:That’s a lot of wordage - I think I kind of understand what Matthias is going for in the first para. By the first method, I assume you mean typing out individual pages broken up by a comma? I’ve discovered you can type practically whatever you want in the page number section, so is that valid for a citation? Or do I have to break it down into individual cites?

@David Eppstein: Yeah, I have to agree on that. Breaking down cites like that seems overly complicated, and page numbers don’t exactly help when I’m linking to Google Books pages for the URL sections. The print copy I have of Wharmby’s Metrobus book probably won’t line up with the eBook version, so that’s bound to confuse readers. Especially since Google Books doesn’t provide page numbers.

Sorry if I’ve misunderstood anything, its late in the evening, and I’ll try and closely read what Matthias has proposed tomorrow. Hullian111 (talk) 22:12, 27 August 2021 (UTC)

Please do not put things in the |page= or |pages= parameter that are not page numbers. You can instead use |contribution=, |chapter=, or |at= (but |at= and |pages= cannot both be used in the same citation). For {{sfn}} there is also |loc=. —David Eppstein (talk) 22:17, 27 August 2021 (UTC)

That's something I happily agree with David. |pages= supports comma-separated lists of pages, page ranges and linked pages in any combination, but please don't put other information into the parameter. |page= is for singular pages, and |at= is for other location information (sheets, columns, paragraphs, etc.) for which the prefix p. or pp. would be misleading. These prefixes also do not belong into the parameter, they are generated by the template itself.

--Matthiaspaul (talk) 22:28, 27 August 2021 (UTC)

(edit-conflict) That's interesting, David, because I come to just the opposite conclusions. ;-) In your suggested use of {{sfn}} with the core citation defined at the first occurence, the citation ends up in the same section as the short references, and, as it also serves as the core citation for the following short references, it either cannot contain page information for the first invocation (putting the first invocation at disadvantage), or it would have to carry a combined list of pages for all invocations (and thereby would create misleading metadata for the first invocation), or it would carry the page information for the first invocation only (and then show wrong page information for all the other invocations linking to it). Certainly a way to avoid the symmetrical two-section setup, but hardy ideal. Also, in order to keep the space occupied by the often very long lists of short references smaller, this section is often formatted as multi-column list with a small column width, but this does not work well when long citations are part of this section as well - to the effect that the list of references cannot be broken into multiple narrow columns and thus occupies a lot of display space creating huge areas of white space.

I also don't understand your comment on {{rp}}. All it does is append some terse superscript page information to the superscripted links.^[1]^: 5 It does not deal with metadata at all and therefore cannot cause it to be mixed up.

Regarding your comment that it "requires readers to remember one piece of a citation while they look up the other", this is exactly the situation I find myself in when having to sift through articles containing short references created with {{sfn}} (because of the missing backlinks from the core citations to the short references or the invocations). One of the advantages of {{rp}} or {{r}} is just that they do not have this problem and automatically provide the backlinks necessary to jump between all pages cited from a single publication. To me, this is a serious shortcoming of the former.

To the OP it is important to know that the different systems obviously have different pros and cons (otherwise we wouldn't need them all ;-), and that WP:CITEVAR applies.

--Matthiaspaul (talk) 22:19, 27 August 2021 (UTC)

@Matthiaspaul: @David Eppstein: Morning all - now I’m able to look at this with a fresh head, with the recent arguments for and against in mind, I’m slowly coming round to think that {{rp}} might be my best bet for my intents and purposes. I will admit, I am still a bit of a novice at this whole Wikipedia thing despite massively picking up on editing this year, so thanks for additional clarification what shouldn’t go in the Template:Cite book page numbers area. Think I may have phrased it wrong by typing ‘anything’...

As I understand it, using {{rp}}, would this ^[2]^: 129 and ^[2]^: 178 be suitable solutions for my page number problem? Or would the other ones be an optimal way to go? Hullian111 (talk) 08:38, 28 August 2021 (UTC)

Yes, except that I would^[3]^: 131 use it like this:^[3]^: 185 See the added |pages=131, 185 parameter, merging the pages info from all short references like {{rp}}. This gives complete metadata, including page info, in the full citation. It may look a bit odd in the source code of this thread, because the definition of the full citation is located where we are actually only citing page 131, but it creates the correct output anyway, and the definition^[4]^: 201 could be added^[4]^: 205 into^[4]^: 231 the References section further down. I'm creating one here to illustrate this with a third citation:

References

^ Dummy citation
^ Jump up to: ^a ^b Paul Williams (15 September 2016). Manchester Buses. Amberley Publishing Limited. ISBN 978-1-4456-5315-0. Retrieved 27 August 2021.
^ Jump up to: ^a ^b Paul Williams (1 March 2018). Manchester Buses, Revised (2nd ed.). Amberley Publishing Limited. pp. 131, 185.
^ Jump up to: ^a ^b ^c Harold Smith (15 January 2020). The Return of the Manchester Bus. Manchester Publishing Company. pp. 201, 205, 231.

--Matthiaspaul (talk) 09:03, 28 August 2021 (UTC)

(edit-conflict) The alternative using {{sfn}} would^[1] look^[2] like^[3] this:^[4]

References

^ Williams 2019, p. 131.
^ Williams 2019, p. 185.
^ Williams 2019, p. 190.
^ Williams 2021, p. 102.

Bibliography

Williams, Paul (15 January 2019). Manchester Buses (corrected ed.). Amberley Publishing Limited. pp. 131, 185, 190.
Williams, Paul (1 August 2021). The New Manchester Buses (fully revised 3rd ed.). Amberley Publishing Limited. p. 102.

See, the actual links are a bit shorter because they don't show the page info embedded, but at the expense of an extra section, so you have to click twice to see the actual citation info. And once you reached the core citation, there are no links back to the individual short refs. Also, the linking itself relies on anchor names created by the citation templates (derived from the author surnames and year, and this can easily led to ambiguous anchor names and invalid HTML (when there are two publications by the same author in a year or two authors of the same name) or dangling pointers (if someone does not recognize that the citation in the bibliography section is referenced from the short references further up and changes or deletes it). There are sometimes also discrepancies between the anchor name created by the citation template and the assumed anchor name used in the short references (not in this example, of course). These errors can be fixed, but they are difficult to detect and therefore it often takes months or years until someone finally finds and fixes them (there are some tools to assist in this process). All in all this style requires careful testing and maintenance. This cannot happen with the style I am recommending further up because it does not rely on these self-created link names but only on those created and used by the underlying Mediawiki software (which reliably displays error messages when there are errors).

--Matthiaspaul (talk) 10:30, 28 August 2021 (UTC)

@Matthiaspaul: Thanks, think that's it! Testing it in Sandbox, I think that method you've suggested works well and should satisfy the issue for the four and potentially more page cites I need to insert into the article. Might take me a while to fully break it down, but I think that's my query solved. I'm going to be working on this MCW Metrobus page for a while over on Docs and Sandbox before I publish it, so if you happen to stop by, let me know if I'm doing it right. Still learning as I go along, after all.

Cheers, Hullian111 (talk) 11:40, 28 August 2021 (UTC)

@Hullian111: Have a look at Swindon railway station#History, references 1 through 7 inclusive. Is this what you are wanting? --Redrose64 🌹 (talk) 09:46, 28 August 2021 (UTC)

This is in fact an example of the unsymmetrical {{sfn}} style David was recommending. However, in addition to the general issues with {{sfn}} described by me above, it creates misleading (and incomplete) metadata (only valid for the first citation) and "nicely" illustrates the excessive white space caused because short and long references are mixed in the same section so that columns must be wide enough for the long references. I think, in this example, it's still tolerable, but there are examples with much longer lists of short references, where it really impacts the visual appearance of an article. On the other hand, when the in-article-location information becomes much longer than a short page or page range, the {{rp}} style can become distracting as well. So, what's best in a particular article depends on the circumstances.

--Matthiaspaul (talk) 10:46, 28 August 2021 (UTC)

To the OP: take a look at WP:LDR and also templates {{harv}} and {{sfn}}. The short citations can be displayed with {{reflist}} and the full citations with something like the {{refbegin}}/{{refend}} combination. 68.173.76.118 (talk) 23:12, 28 August 2021 (UTC)

Zotero not reading COinS

I have noticed several times recently that Zotero (in Firefox) is not detecting the COinS metadata emitted by our citation templates; for example on List of London medical students who assisted at Belsen.

I see the same problem when I am not logged in, so I don't think it has anything to do with my gadgets or user scripts.

Are there any known issues with our COinS?

One possible cause (related to JavaScript, so possibly not relevant), is described on "Connector intermittently does not recognize COinS", on the Zotero forums. It also suggests a fix, but not one we can apply in templates.

Can anyone suggest another cause, or fix? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:49, 28 August 2021 (UTC)

How recently is recently? The last cs1|2 module-suite update was 10 April 2021. Are you the only editor who is experiencing this problem with our citations? Do you have a problem getting the metadata from {{cite patent}} citations? That template does not use the cs1|2 module suite to emit metadata.

—Trappist the monk (talk) 14:10, 28 August 2021 (UTC)

In the last couple of weeks, though it is not something I do every week. I have not examined other editors' systems. Zotero found COinS on Template:Cite patent/testcases on first attempt. On re-examining "List of London medical students...", the issue seems intermittent, and not predictably reproducable. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:20, 28 August 2021 (UTC)

Haven't seen this yet.

When you run into this again, can you check the source code of the loaded web page if it actually contains the COinS data (and perhaps post an example here)?

Just a wild guess, but perhaps there is some instance removing the COinS span for being an empty span? In the current implementation they can be found immediately following the closing </cite>:

<cite>...</cite>

Also worth trying is if this also happens with JavaScript disabled.

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

s2cid limit reached

Just a heads up that there are starting to be articles populating in Category:CS1 errors: S2CID that seem to be correct with values greater than 237000000. --Lightlowemon (talk) 13:55, 31 August 2021 (UTC)

Proposition: "narrator" alias

For audiobooks, mainly. Whenever the various situations are sorted out and proper development restarts. This alias may be useful. 66.108.237.246 (talk) 13:39, 1 September 2021 (UTC)

Audiobook probably use {{cite media}} with |others=Narrated by Simon Vance. The free-form |others= allows for multiple narrators; or, "Full-cast" such as BBC radio adaptations of a book that are too many to list, or some staring roles. --GreenC 14:58, 1 September 2021 (UTC)

There are also other situations for a narrator role apart from audiobooks, such as TV programs, films, and also things like scripts (of plays etc). I don't know if it as common as the translator role that has its own alias, but I wouldn't be surprized. 65.88.88.46 (talk) 15:15, 1 September 2021 (UTC)

There are many roles (not a complete list): Author, Composer, Contributor, Cover artist, Cover designer, Designer, Director, Editor, Forward, Illustrator, Introduction, Narrator, Photographer, Preface, Translator. -- GreenC 15:25, 1 September 2021 (UTC)

|others= works fine for these roles. Almost none of them help with WP:V, which is the main purpose of these templates. – Jonesey95 (talk) 16:09, 1 September 2021 (UTC)

There is a rare case when the narrator info can contribute to verification. In many works (and unfortunately so, imo) the narration is acted rather than read straight. It is conceivable that the narrator's inflection may change the meaning for some listeners. Wikitext may claim a "fact" that depends on such meaning. There should be some indication that the wikitext claim is due to the narrator (as de facto editor) and not necessarily due to the author. But this may be better suited to a more complete citation system. 65.88.88.46 (talk) 17:09, 1 September 2021 (UTC)

Adding an observation made in this discussion about the illustrator role. Audiobook titles can be found by using the "narrator" info, even when the author is not used. The major trade databases (wholesale & retail) index the "narrator" field, and the narrator is prominently displayed in browse lists along with the author. 65.88.88.76 (talk) 21:00, 2 September 2021 (UTC)

`{{hyphen}}` converted to dash

Help:Citation Style 1#pagehyphen says For a hyphenated page, use |page=12{{hyphen}}34. This will not only properly display a hyphen... However, I don't believe this is true, as "{{cite book|title=Title|pages=1{{hyphen}}2}}" renders as "Title. pp. 1–2." with a dash. --Ahecht (TALK
PAGE) 02:27, 2 September 2021 (UTC)

|page= and |pages= are not the same thing. Compare your example:

{{cite book|title=Title|pages=1{{hyphen}}2}}

Title. pp. 1–2.

and the same citation according to the documentation:

{{cite book|title=Title|page=1{{hyphen}}2}}

Title. p. 1-2.

—Trappist the monk (talk) 02:40, 2 September 2021 (UTC)

@Trappist the monk Got it. I added to the "pages" section to clarify. While I have your attention, the "Accept-this-as-written markup" section says Markup can be applied to the entry as a whole or to individual list entries, but that doesn't seem to work for numbers with commas:

{{cite book|title=Title|pages=1, ((1,234))}}

Title. pp. 1, 1,234.

I understand that the logic for handling this case would be more complex than what the module currently does, and would require pre-processing the string before splitting it. If this behavior is intended, should the documentation clarify? --Ahecht (TALK
PAGE) 15:56, 2 September 2021 (UTC)

I saw your tweak to the documentation but the module is smart enough to handle the hyphenated case you demonstrated:

{{cite book |title=Title |pages=1-2–3-4}} – a range of hyphenated page numbers without the need for {{hyphen}} and {{endash}}

Title. pp. 1-2–3-4. – works properly

But if you prefer to use the templates:

{{cite book |title=Title |pages=1{{hyphen}}2{{endash}}3{{hyphen}}4}}

Title. pp. 1-2–3-4. – still works properly

We should reserve recommendation of the accept-this-as-written markup for those cases where it is truly needed so I am going to revert you.

—Trappist the monk (talk) 16:08, 2 September 2021 (UTC)

@Trappist the monk: I suppose a better example would be {{cite book|title=Title|pages=((1{{hyphen}}2)), ((3{{hyphen}}4))}} where those are intended to by hyphenated page numbers. Any objection to me adding that to the help page? --Ahecht (TALK
PAGE) 19:29, 2 September 2021 (UTC)

No objection. You might want to note the difference between your example and this:

{{cite book|title=Title|pages=((1{{hyphen}}2, 3{{hyphen}}4))}}

Title. pp. 1-2, 3-4.

because of what happens when a space character is omitted:

{{cite book|title=Title|pages=((1{{hyphen}}2,3{{hyphen}}4))}}

Title. pp. 1-2,3-4.

—Trappist the monk (talk) 19:41, 2 September 2021 (UTC)

illustrator

Propose adding illustrator to {{cite book}} and others:

|illustrator-last1= |illustrator-first1= |illustrator-link1=

.... 0mtwb9gd5wx (talk) 19:02, 2 September 2021 (UTC)

There is also similar topic above. Personally, I cannot conceive of any situation where the express addition of a book illustrator would help verify a book's content. It is highly unlikely that illustrators of books are indexed in reference databases, and therefore very hard to find the source (or help find the source) by that particular information. In contrast, relating to the "narrator" discussion linked previously, I have seen several trade databases that index the "narrator" field, as this is considered an important role in audiobooks. 65.88.88.76 (talk) 20:41, 2 September 2021 (UTC)

Just adding that my above opinion is limited to {{cite book}}. 65.88.88.76 (talk) 20:44, 2 September 2021 (UTC)

I wondered about this too. I would think that there are many cases where the illustrator is notable and it would be nice to have a wikilink to them. Laterthanyouthink (talk) 05:51, 5 September 2021 (UTC)

The situation is uncommon enough that |others= may be used, as in |others=illus. [[Quentin Blake]]. --Redrose64 🌹 (talk) 08:16, 5 September 2021 (UTC)

Suggestion for a change to a template

Please forgive me if this idea has has already been "considered" and rejected ... or something like that.

My suggestion was already entered in a place ("Wikipedia:Teahouse") that was perhaps ill-advised (and any link to the "new" section is liable to itself become a "^{[dead link]}", once that new section gets "archived"). (right?)

However, a "DIFF" URL which serves as a link to an "edit" ... remains valid for a longer time ... as long as the old ["non-latest"] versions of the page (in this case, a 'Teahouse' page) that got edited, are still extant. Here is an example of such a "DIFF" URL:

https://en.wikipedia.org/w/index.php?title=Wikipedia:Teahouse&diff=prev&oldid=1042098412

... and, even if ^H^H when that ['Teahouse' page] section does get "archived", there is probably some text inside the entries of that section, which is unique enough to be searched for, such that ... one could find the 'lost' ("archived") section, even after it has been "moved" to a different URL.

...In fact, I could even update the URL shown below! ... if I don't forget. In the mean time (at least until that that new section gets "archived"), my "suggestion" can be seen here:

Wikipedia:Teahouse#Suggestion for a change to a template

So ... there is no necessity for the suggestion to be "repeated" here. (right?)

--Mike Schwartz (talk) 06:39, 3 September 2021 (UTC)

The |url-access= parameter takes four possible values: "[free]", "subscription", "registration", "limited". The parameter |url-status= takes: "dead", "live", "unfit", "usurped" (and soon also "deviated"). As far as I was able to understand you, you were trying to add |url-access=paywall to a citation at Political family pointing to [8], but that was rejected by the citation template with an error message, so you switched to |url-status=unfit instead, adding a HTML comment:

"not really [exactly] unfit; but access to the web page at the "url" [...] is subject to some possible inconvenience or other issue, due to a paywall ['if applicable']; ... while it is free for anyone [...] to access the web page at the "archive-url"".)

If this is really what you meant to do, then |url-status= is the wrong parameter to be used (or even |url-status=live would be valid) and you should have instead added either |url-access=registration or |url-access=subscription depending on the type of "paywall" you see.

I'm not sure what you meant by "if applicable". If I have a look at the URL (and comparing with |archive-url= [9]), I can see what appears to be the whole article (free and without any kind of registration), so |url-access= would be inappropriate. Or is there a longer version of the article available after subscription? If so, then a combination of |url-access=subscription and |url-status=limited would be the way to go.

Are you seeing some other kind of access restriction? Do you think we are missing a state not already covered properly by the existing set of predefined values?

--Matthiaspaul (talk) 07:59, 3 September 2021 (UTC)

Here's a link to the documentation. Also, when you have a question, it helps to give a concise statement of it, in plain English. – Jonesey95 (talk) 13:40, 3 September 2021 (UTC)

Accept-this-as-written markup doesn't work on individual items with commas

The Accept-this-as-written markup section says Markup can be applied to the entry as a whole or to individual list entries, but that doesn't seem to work for numbers with commas, e.g. {{cite book|title=Title|pages=999, ((1,001))}} returns Title. pp. 999, 1,001.. This could be solved by adding the following to the top of hyphen_to_dash():

str = str:gsub("(%(%(.-%)%))", function(m) return m:gsub(",", "，"):gsub(";", "；") end)

After that line replaces commas and semicolons with their full-width equivalents, do the split, and then return

str:gsub("，", ","):gsub("；", ";")

at the end of the function. I've mocked it up in the sandbox here. --Ahecht (TALK
PAGE) 17:30, 3 September 2021 (UTC)

{{cite book|title=Title|pages=((999, 1,001))}} returns Title. pp. 999, 1,001. Headbomb {t · c · p · b} 17:47, 3 September 2021 (UTC)

@Headbomb Yes, but the documentation says that it can be applied to individual list entries as well, and doesn't need to be applied to the entire entry. The sandbox version with my changes, e.g. {{cite book/sandbox|title=Title|pages=999, ((1,001))}}, does return Title. pp. 999, 1,001. --Ahecht (TALK
PAGE) 20:36, 3 September 2021 (UTC)

I'm sure your contribution is appreciated, but isn't it easier to correct the documentation so that is in sync with the current production code? Also, the editor documentation follows module coding in that it focusses on field-level operations, including field-list separators. I think that this is a good design/coding decision presently. The formatting of individual field-list entries (such as the issue of notation in this discussion) can be handled by the special markup as pointed out. The complexity of the imo already tottering editor documentation will be increased in applying your otherwise good solution. Not a good thing, I think. 65.88.88.126 (talk) 21:43, 3 September 2021 (UTC)

It is important that the syntax works globally as well as for individual entries in the list, but there are several subtleties, so we need to be careful. As an example, the code in the sandbox reintroduces a bug trashing the data when only the outer list elements have the syntax, but not those in between, see:

Help_talk:Citation_Style_1/Archive_73#Fixed_evaluation_of_accept-this-as-is_syntax_in_parameters_supporting_item_lists

Help talk:Citation Style 1: Difference between revisions

Latest revision as of 03:41, 7 September 2021

Contents

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

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

How to extlink the components of a multi-component publication

Incorrect spacing

Param suggestion: |page-url=

Still an issue with book volumes

error messaging

HTML structure of a citation

display-authors bug

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

Reftag error messages

Template:Cite_serial#In-source_locations

"With Smith, John" in work lists

Same book source, different pages?

Zotero not reading COinS

s2cid limit reached

Proposition: "narrator" alias

`{{hyphen}}` converted to dash

illustrator

Suggestion for a change to a template

Accept-this-as-written markup doesn't work on individual items with commas

Navigation menu

Revision as of 03:07, 6 September 2021 view source Wikipedia>ClueBot III m Archiving 1 discussion to Help talk:Citation Style 1/Archive 78. (BOT)		Latest revision as of 03:41, 7 September 2021 view source Richardpruen (talk \| contribs) Administrators, administrator, Bureaucrats, developer, Interface administrators, Push subscription managers, Administrators (Semantic MediaWiki), Curators (Semantic MediaWiki), Editors (Semantic MediaWiki), Staff, Suppressors, Administrators, translator, Upload Wizard campaign editors, users, x-notes 11,051 edits m 1 revision imported
(No difference)

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)

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)

Help talk:Citation Style 1: Difference between revisions

Latest revision as of 03:41, 7 September 2021

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

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

How to extlink the components of a multi-component publication

Incorrect spacing

Param suggestion: |page-url=

Still an issue with book volumes

error messaging

HTML structure of a citation

display-authors bug

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

Reftag error messages

Template:Cite_serial#In-source_locations

"With Smith, John" in work lists

Same book source, different pages?

Zotero not reading COinS

s2cid limit reached

Proposition: "narrator" alias

{{hyphen}} converted to dash

illustrator

Suggestion for a change to a template

Accept-this-as-written markup doesn't work on individual items with commas

Navigation menu

Search

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

`{{hyphen}}` converted to dash