Help talk:Citation Style 1/Archive 78

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

Archive 75

Archive 76

Archive 77

→

when |archive-url= is broken

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

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

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

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

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

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

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

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

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

Fixed the script error:

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

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

Cite magazine – why upper case Vol.?

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

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

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

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

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

"You may ask, how did this tradition start?

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

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

display-authors bug

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

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)

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)

See also:

Maybe Nurg has ideas for other suitable keywords?

--Matthiaspaul (talk) 11:04, 12 July 2021 (UTC) (updated 09:34, 13 August 2021 (UTC))

We could, perhaps, coin a term |url-status=ex-valid or |url-status=ex-support where the ex- prefix denotes 'former' as in 'ex-president'. Assuming that we settle on some appropriate keyword, what does the module do with that keyword? Render same as |url-status=dead? Render same as |url-status=unfit (no original link)? Something else?

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

Thanks for pinging me, Matthiaspaul. And thanks for raising this again, BrownHairedGirl, since I got no traction back in February.

What about |url-status=historical?

Trappist, I think it should render same as |url-status=dead. Nurg (talk) 04:55, 13 July 2021 (UTC)

Yeah, I too think it should render the same as |url-status=dead.

More ideas: |url-status=descended/inherited/ancestral/supplanted/superseded?

--Matthiaspaul (talk) 11:11, 16 July 2021 (UTC)

I don't know anything about the coding or program logic, but I wonder whether we don't really need a significant change to the logic. Would it be feasible to create an alias for |url-status=dead called |url-status=historical and an alias for |url-status=live called |url-status=current, with a view to eventually deprecating "live" and "dead"? Or something like that? Nurg (talk) 05:15, 20 July 2021 (UTC)

It is trivial to add such aliases. As far as the proposals go, there would be no changes to the program logic needed to implement them (as I already demonstrated when I temporarily implemented the archived keyword in the sandbox for illustration purposes, which, however, was reverted by Trappist and Izno).

Regarding the proposed keyword historical, I first thought this would be a good match, but later it occured to me that |url-status=historical could also be interpreted to mean just the opposite of what we want to express, as if the current page at the URL would be the historical one.

Regarding the proposed keyword current and from what you wrote about deprecating dead, I take it that you want to replace the currently assigned keyword(s) by (presumably) better one(s). This would be different from the original proposal where we were/are seeking for a keyword to define a separate new state for |url-status= which just happens to render the same (at least at present) as what we do for |url-status=dead. However, a dead URL is an URL for which your browser would not get any response at all any more when queried, whereas when querying an outdated/deviated/superseded page you would still get contents, even sensible contents, which can be seen as a continuation of the original contents, but just changed in ways so that its contents no longer supports the article any more.

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

Considering all proposed keywords for this new state so far, I find |url-status=deviated to be the most suitable one. It is reasonably short, a single keyword, and it implies something that is still live and not usurped, but changed enough from something that was once found good enough to support the article, but not changed drastically enough to be unfit for presentation. If there are no objections or better suggestions, I will implement that.

--Matthiaspaul (talk) 23:13, 29 July 2021 (UTC)

{{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=deviated |archive-url=https://web.archive.org/web/20151229222337/http://www.paulgogarty.com/about/ |archive-date=2015-12-29}}

"Profile of Paul Gogarty TD". Paul Gogarty's website. Archived from the original on 2015-12-29. Retrieved 2009-06-19.

Done.

--Matthiaspaul (talk) 00:03, 31 July 2021 (UTC)

No, I do not think adding content-related options to the parameter is the way to go.

Assuming the information removed from the source is still correct and pertinent, and there is a reliable archive available, I would cite the archive directly (using {{cite web}} in this case) and so avoid the |url-status= situation.

The url-status parameter is an editor utility parameter regarding the url ... status. It is named so. It is there to signal editors the reason a certain link cannot/should not be used. It makes no assumptions about the link's content. If the pertinent information is not there then there are verifiability, not citation, issues. If however there is an archive, see the previous paragraph. 69.203.140.37 (talk) 12:28, 17 June 2021 (UTC)

Hm, if I have to cite an archived version of some former site because the original site no longer exists or has changed in unsuitable ways, the proper way to do so is still to add the archive link to |archive-url=, extract the original link from it for |url= and set |url-status= so that the two links are swapped. I would typically use the keyword "dead" for it, but as others have stated already, this isn't exactly intuitive and might even be misleading at times. Adding the archived version to |url= will, in most cases, cause some bot to fix up the citation later on.

Yeah, I agree that |url-status= has a utility value for editors, that's exactly why it should have a well-defined set of non-misleading keywords to cover all practical cases, even if some of them would be handled the same by the software internally. --Matthiaspaul (talk) 13:06, 17 June 2021 (UTC)

Why should a bot mess with a perfectly good citation? Whether an archive is cited or the original is, it makes no difference as long as the wikitext is verified. There is also the issue of simplicity.

Citations have no business defining the content in any way. If the information is not there, there are other options, as shown. People should not expect a citation template, or any citation no matter how formatted, to address content issues. If it is not there, it should not be cited, period. Find another source where the information exists. Archive links are convenience links so editors won't have to reformat the entire citation if the original link (not its content) is inaccessible for any reason. In some cases though, the citation must be reformatted, rewritten, or removed. 50.74.165.202 (talk) 13:43, 17 June 2021 (UTC)

An archived copy is not a "perfectly good citation" in and of itself, since it is presumed that the archive is of a different URL which once contained reliable information. The archiving site itself isn't a source. So with that in mind, it's crucial to maintain information about what the original URL was that established the reliable website source. That is done via the URL parameter, with the archived copy linked through archive-url. The url-status then exists to tell us in what state the original URL is now, and in particular whether a user seeking the info should go to the source or the archive. I agree with the OP that having an "information no longer there" option would be good, although in terms of how the cite formats itself this will probably end up similar to "dead". — Amakuru (talk) 13:59, 17 June 2021 (UTC)

Not so at all. Any source that verifies the wikitext is a perfectly good source for a citation. A reliable archive is a source like any other ("reliable archive" meaning one that is known to faithfully reproduce the original). It is not at all crucial to maintain information about a previous location (the "original" URL). It is necessary to include information about the location that currently verifies the wikitext (including a current URL if it exists - whether pointing to an archive or not is immaterial). Citations are not historical information, nor are they future statements. They must prove the wikitext now. If they don't, they cite nothing. 65.88.88.69 (talk) 19:37, 17 June 2021 (UTC)

@65.88.88.69: I strongly disagree with the statement that Citations are not historical information, nor are they future statements.

The role of a citation is to allow readers to verify the information cited. Part of that task is to note issues in verifiability, which is why for example with a dead link we include both the live archive link and the original dead link. That helps readers to verify the citation. I see no reason to impede that verifiability for any of the situations discussed.

I agree with Amakuru's observation that in terms of how the cite formats itself this will probably end up similar to "dead". My goal is to assist editors by providing a more explicit label to achieve that. --BrownHairedGirl (talk) • (contribs) 09:53, 20 June 2021 (UTC)

@BrownHairedGirl: quite so. A citation without evidence that the thing being cited is reliable is useless. And as much as we've made the decision to trust sites like archive.org top maintain a historical record of what a reliable source once said, the presence or absence of that original source is still a matter of profound interest. In some cases, visiting the newly-updated version of the source might provide evidence to a reader or an editor that the information cited is actually not correct any more. — Amakuru (talk) 10:35, 20 June 2021 (UTC)

Indeed, @Amakauru. It is not hard to conceive of ways in which the archive sites could be compromised or games, or even become corrupt ... so we should facilitate those who want to conduct their own verification.

And there are many ways in which the current version of the page could be relevant, one of which is the example you give of the information being outdated. --BrownHairedGirl (talk) • (contribs) 10:42, 20 June 2021 (UTC)

Does everybody understand that the parameter in question is only an indicator about the state of the link. Nothing else belongs there, so please don't try to shoehorn extraneous stuff into it. If the verifying info is not there, a link is useless. To the reader trying to verify whatever is written in wikitext, prior or future iterations of the citation are also useless. To turn wikitext fiction into fact, a citation must (continuously) verify now. Notice that any article-space page does not carry information about previous versions of the article. If a reader cares, they can consult the history for previous iterations, including those of the citations. The source's underlying reliability is another issue, one that should be resolved prior to formatting of citations, and is a different discussion. 64.18.9.208 (talk) 12:38, 20 June 2021 (UTC)

We've discussed this one before, though I would not know what to search for. I think the correct way to cite such a case today, and I remember arguing the same then, would be simply setting to dead. The original source is effectively dead for the purposes of the citation, even if the site is still available. If you are dead set on including both that citation and information, you should add an archive URL, set to dead, add a wikitext comment about why you set to dead, and move on. The reason I add the latter two caveats is due to WP:BLP/WP:V/WP:NPOV. If the source is not independent, one should question whether it's appropriate to use that source and whether it is appropriate to include that information. If it is so important as to be clearly an NPOV piece of information, then one still needs to meet the bar associated with BLP (in this case). Izno (talk) 13:48, 17 June 2021 (UTC)

If we are going to consider additional keywords, perhaps blacklisted (or the politically correct term du jour) might be one to add. When |url= has a blacklisted url, the blacklist prevents saving of the article. To get round that, editors add an |archive-url= and either comment out, remove, or otherwise break the value in |url= so that the page will save. This gives a link to a snapshot of the source but also creates |archive-url= requires |url= errors. |url-status=blacklisted would allow |url= to be blank (commented) or missing; Module:Citation/CS1 would not emit error messages but would emit a maintenance category.

—Trappist the monk (talk) 14:04, 17 June 2021 (UTC)

The point is that the keywords indicated in the OP are not link (URL)-related, so they are outside the scope of a URL's status. "Blacklisted" passes the test, per your discussion fork above. In general and as you know, citations point to sources, they don't make statements about their content. That can be a subject of a footnote (if necessary) perhaps with its own citation track. 65.88.88.69 (talk) 19:55, 17 June 2021 (UTC)

@65.88.88.69: I strongly disagree. "URl no longer contains the cited information which it previously contained" (or some short form thereof) is very much a matter of the URI's s status.

Citations do indeed point to sources, and part of that task is to note issues wrt verifiability. --BrownHairedGirl (talk) • (contribs) 09:44, 20 June 2021 (UTC)

URIs are identifiers. They make no statements regarding the item they identify. Either the identification is correct (item exists) or is not. Let's not try to redefine a URI's function. It seems that there is a confusion regarding verifiability. Citations that resolve to existing sources by definition explicitly verify whatever is claimed in wikitext. If they don't, they are invalid, and should be removed. The reasons for the invalidation are not pertinent; the reader wants to see a valid citation, not explanations of why a citation is not currently valid. As was said earlier, if editors want to keep the wikitext they should find another source. 64.18.9.209 (talk) 13:10, 20 June 2021 (UTC)

~~I have hacked the module suite to accept |url-status=blacklisted.~~

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

and when used with {{cite book}} for |chapter-url=. In this example, |chapter-url= (where (dot) is a dot):

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

~~In this second example, because the module does not receive |chapter-url= it cannot know to apply |archive-url= to |chapter=.~~

This scheme may not work all the time. It's unclear to me when the blacklister steps in and prevents saving of a page with a blacklisted url. For example, I was able to save my sandbox that has actual blacklisted urls commented out (taken from Giulia Millanta) but I am unable to save the same thing here.

—Trappist the monk (talk) ~~16:10, 6 July 2021 (UTC)~~ 13:07, 8 July 2021 (UTC) (strikeout)

In your examples did you you omit the protocol (URI scheme) intentionally? (As it returns errors). Also, is it possible for the blacklisted url to be commented out by a routine? If it is too hard I guess it can always be done by hand.

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

Any ideas about adding an archive-url-status param? 65.88.88.57 (talk) 19:07, 6 July 2021 (UTC)

(edit conflict)

Not intentional and fixed. It is likely that I will revert this change because the regex that is the blacklister looks for anything following http:// or https:// until the line item found in MediaWiki:Spam-blacklist; see mw:Extension:SpamBlacklist#Performance. So for the boomerocity.com archive url here, https://web.archive.org/web/20200122204730/https://boomerocity(dot)com will match /https?:\/\/[a-z0-9\-.]*\bboomerocity\.com\b/Si.

As far as I know, no one has made a case for |archive-url-status=.

—Trappist the monk (talk) 19:41, 6 July 2021 (UTC)

I suppose I was asking whether something like this is feasible:

{{Cite web |title=Title |website=BlacklistedWebsite.com |url=http://blacklisted_url.com|archive-url=http://blacklisted_url.com-some_archive.org |archive-date=2021-07-06 |access-date=2021-07-06 |url-status=blacklisted|archive-url-status=blacklisted}}

to be auto-formatted as

{{Cite web |title=Title |website=BlacklistedWebsite.com |url=<!--http://blacklisted_url.com-->|archive-url=<!--http://blacklisted_url.com-some_archive.org--> |archive-date=2021-07-06 |access-date=2021-07-06 |url-status=blacklisted|archive-url-status=blacklisted}}

65.88.88.57 (talk) 19:30, 6 July 2021 (UTC)

If I understand what you are saying, then the answer is: no. Modules and templates cannot modify and save wikitext.

—Trappist the monk (talk) 19:43, 6 July 2021 (UTC)

Right. I was thinking about something similar to the way |url=original-url.com is auto-formatted when |url-status=dead, for example, to |url=archived-url.com (and the static text too). 65.88.88.57 (talk) 20:19, 6 July 2021 (UTC)

Blacklisted change has been reverted because it will not work properly.

—Trappist the monk (talk) 13:07, 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)

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)

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)

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)

Date quarters

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

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

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

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

"foo". Journal. Third Quarter 1984.

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

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

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

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

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

which yields

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

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

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

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

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

(my emphasis).^[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)

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)

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

[1]