Help talk:Citation Style 1/Archive 75

From Wikipedia, the free encyclopedia

Archive 70←Archive 73Archive 74Archive 75Archive 76Archive 77→Archive 80

|work= aliases in cite book

A discussion at {{cite q}} got me wondering why cs1|2 doesn't emit error messages when {{cite book}} has a |work= (or alias) parameter. A |work= parameter in {{cite book}} is visibly rendered but whatever it contains is not made part of the citation's metadata:

{{cite book |title=Title |work=Work}}
Title. {{cite book}}: |work= ignored (help)
<templatestyles src="Module:Citation/CS1/styles.css"></templatestyles><cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+75" 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;work=</code> ignored ([[Help:CS1 errors#periodical_ignored|help]])</span>

Error messages are emitted when |encyclopedia= is used in other than {{cite encyclopedia}} or {{citation}}. Similarly, error messages are emitted when |chapter= (or alias) is used in a 'periodical' template ({{cite web}}, {{cite news}}, {{cite journal}}, {{cite magazine}}, {{cite pressrelease}}, {{cite podcast}}, {{cite newsgroup}}, {{cite arxiv}}, {{cite biorxiv}}, {{cite citeseerx}}, {{cite ssrn}}). So why shouldn't a |work= (or alias) parameter cause {{cite book}} to emit an error message? These searches time out but serve to show that |work= aliases are (improperly) used with {{cite book}}:

—Trappist the monk (talk) 21:38, 30 January 2021 (UTC)

This has nothing to do |work= but with the flawed module design which assigns the same label ("title") to parameters for different types of variables, depending on the downstream application. The entire module should emit an error. Another option is to double-down on the error and have "page" mean "chapter", again depending on the downstream template. Somewhat similar fun in the discussion about |postscript=, above. 98.0.246.242 (talk) 23:46, 30 January 2021 (UTC)
The citation template parameters correctly reflect the terminology used in the real world to describe citations. E.g., for journals, "title" means the article title, whereas for books it means the book title. The COinS metadata also has a degree of contextual ambiguity, e.g. rft.atitle is the "article title", which is used for book chapters, encyclopedia articles and journal articles. The citation templates seem to me to manage the disambiguation about as well as could be expected. Peter coxhead (talk) 07:37, 31 January 2021 (UTC)
This seems backwards to me. Do not introduce ambiguity in the module in the first place by having something mean 2 different things depending on arbitrarily defined context. The semantic meaning of "title" in some templates is "location within a source". That would be a journal article, a track in a musical work, an episode in a TV series, or a chapter in a book etc. In other templates the semantic meaning of title is "the source". A million convoluted discussions can result from this, and they do. After all the source and whatever it is labelled programmatically ("work" pretty much fits the bill since it covers any type of source) is the single most important parameter. And by all means give the metadata its proper place: they are secondary relative to the data, and should take their cue accordingly. Instead we have even more fog developing here. 98.0.246.242 (talk) 15:34, 31 January 2021 (UTC)
As I say any time the IP shows up for his rant (with which I more or less agree), I'd remove |title= entirely given that we should want a consistent system, and that parameter is the least consistent of the batch. --Izno (talk) 07:49, 31 January 2021 (UTC)
Well, hardly a rant, in the sense that it doesn't ruin my day either way. I just point out the underlying issue. Bad design will inevitably lead to incongruous situations, and treating the symptoms will not make the disease go away. 98.0.246.242 (talk) 15:19, 31 January 2021 (UTC)
The reason I call it a rant is that it assumes there was active design in what the parameters were called when taken as a group over all the templates of interest as the templates were created. There was not. They all sprang up individually (also why we have two styles and not one). That the general opinion that the module is defective at its core appears almost without fail is a second reason I call it one. We all know there is something technically wrong; our problem is that the alternative (deprecating and/or removing title being the solution I know) would be a social wrong by this point. So it doesn't help to remind us of that. If you particularly would like to start an RFC on the point, which would surely be needed, have at it. Or suggest a better solution. --Izno (talk) 17:31, 31 January 2021 (UTC)
Believe me, there were objections to this from the very beginning (pre-Lua). So after all these years of avoidable disputes and frequent reminders that made no difference whatsoever, this has settled into the "always-done-this-way" category, a false premise. Uncool. In the meantime, ignoring a wrong approach is entrenching it further, so there we are. 98.0.246.242 (talk) 22:33, 31 January 2021 (UTC)
|work= should stand for a greater work, which is anything in italics in this template. That it is not is a failing of the module. I long for the day where I could generically say {{cite book |work=Work |chapter=Chapter}} as easily as I can {{cite website |work=Website |webpage<!-- why doesn't that parameter exist -->title=Webpage}} as easily as I can {{cite news |work=Work |article<!-- another one that probably doesn't work in cite web and should though I haven't checked -->title=Article}}. And have all the synonyms for a work be actual synonyms: journal, encyc, report, conference, book(-title...), website.... --Izno (talk) 07:49, 31 January 2021 (UTC)
Then {{Citation}} would have to have different parameters from the "cite family", because a fully aliased and hence generic |work= would not identify the type of the source, which is needed to map the components into COinS and the other metadata systems used by reference managers as well as format them in the displayed citation. Peter coxhead (talk) 11:32, 31 January 2021 (UTC)
Citation would need to use anything but work, but this is essentially already true. That it happens to alias to some parameters rather than others (or none) is another failure. And, we were talking about CS1 in this conversation anyway, not CS2. --Izno (talk) 17:31, 31 January 2021 (UTC)

Inconsistent removal of period/full stop

Consider the display produced in these two examples:

  1. {{cite web |title=''Papaver cambricum'' L. |work=The International Plant Names Index |url=https://www.ipni.org/n/673433-1}} → "Papaver cambricum L." The International Plant Names Index.
  2. {{cite web |title=''Meconopsis'' Vig. |work=The International Plant Names Index |url=https://www.ipni.org/n/30149252-2}} → "Meconopsis Vig". The International Plant Names Index.

The "." in both "L." and "Vig." is a key part of the standard abbreviation of the botanists' names. But in the second example it disappears, so I have to remember to put either "Vig.." or "Vig&#46;" in the wikitext. Is this fixable? Peter coxhead (talk) 11:42, 31 January 2021 (UTC)

{{cite web |title=((''Meconopsis'' Vig.)) |work=The International Plant Names Index |url=https://www.ipni.org/n/30149252-2}} → "Meconopsis Vig." The International Plant Names Index.
—Trappist the monk (talk) 11:57, 31 January 2021 (UTC)
I'm doubtful that this is any more sustainable than e.g. my use of &#46;. My experience is that unless I also remember to include an HTML comment to explain, a copy editor is likely to "correct" the citation without noticing the disappearance of the stop. Anyway, it's another alternative, so thanks.
So how can the problem be fixed with {{IPNI}}? Double parentheses don't work here.
{{IPNI |id=30149252-2 |taxon=Meconopsis |authority=Vig.}} → "Meconopsis Vig". International Plant Names Index (IPNI). Royal Botanic Gardens, Kew; Harvard University Herbaria & Libraries; Australian National Botanic Gardens.
{{IPNI |id=30149252-2 |taxon=Meconopsis |authority=((Vig.))}} → "Meconopsis ((Vig.))". International Plant Names Index (IPNI). Royal Botanic Gardens, Kew; Harvard University Herbaria & Libraries; Australian National Botanic Gardens.
Peter coxhead (talk) 09:52, 1 February 2021 (UTC)
The double parenthesis only works on the whole title, so you need to do this:
{{IPNI |id=30149252-2 |taxon=((Meconopsis |authority=Vig.))}} → "Meconopsis Vig." International Plant Names Index (IPNI). Royal Botanic Gardens, Kew; Harvard University Herbaria & Libraries; Australian National Botanic Gardens.
Would make the code confusing for editors without explanation. Perhaps the template should be edited to always bracket the title. —  Jts1882 | talk  10:38, 1 February 2021 (UTC)
@Jts1882: done in the sandbox. Now
{{IPNI/sandbox |id=30149252-2 |taxon=Meconopsis |authority=Vig.}} → "Meconopsis Vig". International Plant Names Index (IPNI). Royal Botanic Gardens, Kew; Harvard University Herbaria & Libraries; Australian National Botanic Gardens.
{{IPNI/sandbox |mode=cs2 |id=30149252-2 |taxon=Meconopsis |authority=Vig.}} → "Meconopsis Vig.", International Plant Names Index (IPNI), Royal Botanic Gardens, Kew; Harvard University Herbaria & Libraries; Australian National Botanic Gardens
BUT the use of ((..)) prevents the italicization of the taxon name, as it does in Trappist's example above, so isn't the solution. Substituting "&#46;" for the terminal "." may be the answer. Now fixed by Trappist. Peter coxhead (talk) 20:12, 1 February 2021 (UTC)
The use-as-written markup support was added to the module in response to this discussion.
—Trappist the monk (talk) 12:48, 1 February 2021 (UTC)

Authorlink

As there is an |authorlink= parameter in the citebook template for the |first= and |last= name parameters, I was wondering if we could incorporate an |authorlink2= parameter for the |last2= and |first2= parameters, as sometimes a work is authored by two or more noted authors who have articles here at Wikipedia. Would it be possible to add an |authorlink2=, and even an |authorlink3=, parameter to the citebook template? -- Gwillhickers (talk) 19:24, 1 February 2021 (UTC)

It's already there, though the hyphenated forms |author2-link= or |author-link2= are preferred. Kanguole 19:36, 1 February 2021 (UTC)
{{cite book |title=Title |last=Brown |first=AB |last2=Red |first2=CD |author-link1=Brown |author-link2=Red}}
Brown, AB; Red, CD. Title.
ad nauseum
—Trappist the monk (talk) 19:40, 1 February 2021 (UTC)
I tried using |authorlink2= before but it resulted in an "unrecognized parameter" error. I must have messed up the syntax or something. In any case, both the hyphenated and un-hyphenated types are working fine now.  Many thanks! -- Gwillhickers (talk) 23:39, 1 February 2021 (UTC)

PDF Formatting bug

Sorry if this is the wrong place to post this. In source reviewing Edvard August Vainio I discovered that PDFS with trans-title parameters (for Journals, at least) end up splitting up the PDF icon from the "PDF" abbreviation. E.g.:

Is this something that can be fixed in the template's code...? Aza24 (talk) 07:57, 2 February 2021 (UTC)

Previous discussion at Help talk:Citation Style 1/Archive 69 § trans-title= splits PDF format indication
—Trappist the monk (talk) 11:27, 2 February 2021 (UTC)

Numeric author check

Hello, the check for numerics in the |last= parameter does not appear to work in this case. Would have expected it to appear in Category:CS1 maint: numeric names: authors list

{{Cite web|last=2005-02-02T11:48:01|title=Must Have It has had it|url=https://www.retail-week.com/must-have-it-has-had-it/40302.article}}

2005-02-02T11:48:01. "Must Have It has had it".{{cite web}}: CS1 maint: numeric names: authors list (link)

Keith D (talk) 16:38, 2 February 2021 (UTC)

Help talk:Citation Style 1/Archive 64 § Check author names are not numeric for Cite web Alphanumeric 'names' are not detected because it is possible that such names might be legitimate.
—Trappist the monk (talk) 17:16, 2 February 2021 (UTC)

publication-date is a season

I have a citation to an article that showed up in an alumni magazine. The magazine itself was the Spring 2013 edition, and the article was posted to the website on June 27, 2013. However setting |publication-date=Spring 2013 gives me a Check date values error.

Any suggestions? AngusW🐶🐶F (bark • sniff) 00:05, 4 February 2021 (UTC)

WP:SAYWHEREYOUREADIT: If you read the website, cite that; if you read the magazine, cite that. A single cs1|2 template may cite the magazine or may cite the website but not both at the same time. If you want to cite both: two templates. Of course, it is common to fudge that and cite the magazine with a courtesy link to the website.
—Trappist the monk (talk) 00:59, 4 February 2021 (UTC)
If identical versions of a work are published on paper and online, it's common to write the citation as if citing the paper version, even though it was read online; the URL would be included. But date and publication-date are aliases of each other, so only one should be in the citation. If they are indeed identical, the "Spring 2013" date would probably be best, because it would allow those who prefer to read online, and those who prefer to read paper, to find and confirm they have the correct publication. Jc3s5h (talk) 01:35, 4 February 2021 (UTC)
Your reference throws an error because |publication-date= is not supported programmatically the way |date= is. So a perfectly correct variable in one parameter is wrong when applied to another parameter of the same class. Why, you ask? I guess the answer is, why not? Expectations that things should make sense may be misplaced. Anyway, there's a fair chance |publucation-date= will soon be deprecated, so I wouldn't expect a fix. 66.65.114.61 (talk) 21:59, 4 February 2021 (UTC)

S2CID Style requires update

S2CID value currently is 230000000, but recent reference numbers are higher. Citation Style to be updated. Example: Reference ID 231590107 https://www.semanticscholar.org/paper/Resilience-of-trees-and-the-vulnerability-of-to-in-Saintilan-Bowen/97f77008d54ab237b93fd71d72c30f5582d71872 Cited here: Bush encroachment Sekundemal (talk) 05:05, 25 January 2021 (UTC)

Thanks for reporting. Updated the limit to 235000000 in the sandbox.
--Matthiaspaul (talk) 07:23, 25 January 2021 (UTC)

RFC on hyphenated citation template parameters

An RFC that probably should have been held on this page has been posted at VPP. It asks: "Should non-hyphenated parameters be fully removed from the CS1|2 family of templates?" Please make your views known there, if you have them. – Jonesey95 (talk) 04:07, 11 February 2021 (UTC)

i18n of invisible_chars table

Just to drop a note that there should be a way to do i18n of the invisible_chars table in the Configuration module, since the names are used in error messages. Changing the names directly (e.g. from 'zero width joiner' to 'ゼロ幅接合子' in the case of jawiki) does not work well since the English name is referenced in the has_invisible_chars function. I had to fix the jawiki module by making the same name changes in that function. ネイ (talk) 14:34, 12 February 2021 (UTC)

I've hacked the module so that the invisible character finder uses the zwj or del character itself as the tested value in has_invisible_chars(). It isn't pretty but will do until I can figure out a better way to do it.
—Trappist the monk (talk) 19:44, 12 February 2021 (UTC)
Thank you! Looks good to me. ネイ (talk) 05:59, 13 February 2021 (UTC)

Mention of {{citation}}

There is only one mention of the general-purpose {{citation}} template in this help page. It is widely used, convenient since it works for any source, and not controversial or deprecated, as far as I know. Is there any objection to adding it to the "Templates" list? Aymatth2 (talk) 12:48, 13 February 2021 (UTC)

No templates in headers.
I presume that you are referring to the table at Help:Citation Style 1 § Templates. That table is for cs1 templates. {{citation}} is a cs2 template and has its own page: Help:Citation Style 2. Until there is movement to fully merge Help:Citation Style 1 and Help:Citation Style 2 into a single help page, I don't think that the distinction should be blurred.
—Trappist the monk (talk) 12:59, 13 February 2021 (UTC)
The templates are not cs1 or cs2, but just differ in their default modes. They can all render cs1 or cs2.
{{Citation}} renders cs1 format if |mode=cs1 is specified.
{{Cite book}} renders cs2 format if |mode=cs2 is specified.
If we add {{citation}} to the "Templates" list we can include a note on |mode=cs1. I would support merging the two help pages, but that seems like a separate discussion. Aymatth2 (talk) 15:35, 13 February 2021 (UTC)

Freetext editors field, lack of

As at the Village Pump survey this was said to be the venue for feedback... For what it is or isn't worth, and just for the record, I was sufficiently incandescent about the recent removal of the freetext editors field to abandon using citation templates altogether. I have actually found this quite freeing; no more looking up the documentation repetitively and trying to squeeze whatever oddity I've got in front of me now into the increasingly tight straitjacket of the templates. No more trying to work out why what it says for CS1 doesn't work in CS2. No more magically appearing little red error notices. No more bot edits to check. Simples, as the meerkat says. Espresso Addict (talk) 00:22, 16 February 2021 (UTC)

@Espresso Addict: Yes, and you'll have something like John,S.; John, W. (eds) John Smith "Title of something Journal of Something" https://10.1111/10321.32156 volum. 34 issu. ("3") pages=32304-223, and not notice the dozen errors you have in it.
Everything you can put in CS1 works in CS2. And, unless you're doing something really weird, you don't have to learn anything much save for the basic |last#= |first#= |year= |editor#-last |editor#-first= |chapter= |title= |journal/magazine/...= |publisher= |location= |volume= |issue= |pages |doi= |isbn=, leaving out those you don't need.
Or even simpler just use <ref>{{doi|10.1155/....}}</ref> and let Citation bot fill in the stuff for you. Headbomb {t · c · p · b} 03:00, 16 February 2021 (UTC)
Well, you might generate a dozen errors per reference, but I don't.
If you choose to accept what the various citation tools create, great. I find they make such code soup of anything other than the simplest reference that it's nearly always easier to redo by hand. Even worse, absurd pages like one I saw the other day but can't now locate, where literally an entire column was filled with the authors for a single reference, which discourage readers from checking out the sources by making reference lists bloated. Espresso Addict (talk) 03:35, 16 February 2021 (UTC)
|display-authors=1 is there for those cases. Headbomb {t · c · p · b} 04:06, 16 February 2021 (UTC)
I use {{citation}} for all source definitions and stick them in a single-column alphabetic list in a "==Sources==" section after the {{reflist}}, then use {{sfn}} to cite pages in the sources. This declutters the article text and gives precise citations without duplication. For Google Books, reftag formats the citation. For other sources, I just cut and paste whatever identifying information I can find, stick in labels like |first= ... |last= ... |title= ... |url= ... etc., then glance at the result to make sure there are no error messages. I have provided all the information I can and {{citation}} has rendered it in the format that has evolved over the years through consensus among many editors. I can't imagine why I would try to do that by hand. Aymatth2 (talk) 14:07, 16 February 2021 (UTC)
No more magically appearing little red error notices. No more bot edits to check. And no more automatically-generated targets for {{sfn}}? David Brooks (talk) 23:55, 16 February 2021 (UTC)

Cite news does not accommodate separately paginated sections of newspapers

I've just discovered a flaw in {{cite news}}. It does not allow one to fully cite a section of a newspaper that has separately numbered pages, such as a "Sport" or "Financial" section. Correctly citing an article on e.g. page 3 of the Sport section will mislead the reader to look on page 3 of the main section. It isn't possible to add "section=Sport", it just gives an ugly red error message. Roger (Dodger67) (talk) 18:38, 12 February 2021 (UTC)

Use |department=. --Izno (talk) 18:57, 12 February 2021 (UTC)
Thanks Izno - the mention of "section=department" is rather deeply buried in the template documentation. As "Section" is a fairly common term for such parts of newspapers, perhaps some adjustment could be done to make it a bit more obvious? Roger (Dodger67) (talk) 21:42, 14 February 2021 (UTC)
I doubt anyone will stop you modifying the documentation as you please. --Izno (talk) 21:45, 14 February 2021 (UTC)

Warning when url and archive-url are identical

Could we have the citation templates give one of those red warning messages when someone adds an archive-url that is identical to what's already in url, like here by Asdasdasdff? --bender235 (talk) 17:56, 19 February 2021 (UTC)

Like this?
More information Wikitext, Live ...
Cite book comparison
Wikitext {{cite book|archive-date=2021-02-19|archive-url=//example.com|title=Title|url=//example.com}}
Live Title. {{cite book}}: Check |archive-url= value (help)
Sandbox Title. {{cite book}}: Check |archive-url= value (help)
Close
and for |chapter-url= aliases
More information Wikitext, Live ...
Cite book comparison
Wikitext {{cite book|archive-date=2021-02-19|archive-url=//example.com|chapter-url=//example.com|chapter=Chapter|title=Title}}
Live "Chapter". Title. {{cite book}}: Check |archive-url= value (help)
Sandbox "Chapter". Title. {{cite book}}: Check |archive-url= value (help)
Close
—Trappist the monk (talk) 19:00, 19 February 2021 (UTC)
That's what I meant, yes. But maybe it could be a bit more explicit on what's the problem. Simply "check value" might be misinterpreted as "there's a typo in the URL." --bender235 (talk) 21:12, 19 February 2021 (UTC)

URL is live but no longer supports the article

What is best practice when using 'cite web' and:

  1. The url is still live but no longer supports the text in the article.
  2. An archived version of the webpage does support the text.

'url-status=live' is correct but puts the current, non-supporting URL first, before the archive url.

'url-status=dead' puts the text-supporting, archived url first, but the original url is not actually dead.

Thanks. Nurg (talk) 23:43, 19 February 2021 (UTC)

If it is the case the URL was usurped e.g. by spam, |url-status=usurped; if the living link is no longer useful, |url-status=unfit.
If it is the case the citation no longer supports the page content because the information in the citation was retracted, you should probably find a new citation. --Izno (talk) 01:08, 20 February 2021 (UTC)

Added asin-tld= range checking

Speaking of ASIN TLDs, we currently support com, co.jp, co.uk, com.au, com.br and com.mx as TLD special cases. According to:

there are a few more combinations. Therefore I have added them to the |asin-tld= values supported by us. Unknown combinations now throw an error message:

  • More information Wikitext, Live ...
    Cite book comparison
    Wikitext {{cite book|asin-tld=xy|asin=6305277001|title=Title}}
    Live Title. ASIN 6305277001. {{cite book}}: Check |asin-tld= value (help)
    Sandbox Title. ASIN 6305277001. {{cite book}}: Check |asin-tld= value (help)
    Close

This will also show citations where |asin= and |asin-tld= have been mixed up. --Matthiaspaul (talk) 20:48, 25 January 2021 (UTC)

Also added error messages for |asin-tld= without |asin=, |class= without |arxiv=, and |pmc-embargo-date= without |pmc=.
  • More information Wikitext, Live ...
    Cite book comparison
    Wikitext {{cite book|asin-tld=uk|title=Title}}
    Live Title. {{cite book}}: |asin-tld= requires |asin= (help)
    Sandbox Title. {{cite book}}: |asin-tld= requires |asin= (help)
    Close
--Matthiaspaul (talk) 01:02, 27 January 2021 (UTC)
Rewritten. And, I removed the |class= test and error message because |class= is only supported by {{cite arxiv}} which in itself requires |arxiv= so a |class= requires |arxiv= is just redundant.
—Trappist the monk (talk) 23:19, 27 January 2021 (UTC)
This makes sense. :-) Thanks.
--Matthiaspaul (talk) 13:30, 21 February 2021 (UTC)

Bogus CS1 sub-categories

The following four CS1 categories indicate they have sub-categories, but when trying to open them, they only show "nothing found":

A similar problem was already reported some while ago at:

--Matthiaspaul (talk) 01:07, 26 January 2021 (UTC)

I just had a look again and tried to open the above mentioned subcategories at Category:CS1 errors and Category:CS1 foreign language sources‎. It's still showing blue rather than white "arrows" there, indicating non-existent sub-categories. So, it is persistent rather than some temporary glitch. No idea how to fix this...
--Matthiaspaul (talk) 10:33, 21 February 2021 (UTC)
Null editing the parent & child doesn't fix this either.   ~ Tom.Reding (talk ⋅dgaf)  13:34, 21 February 2021 (UTC)

propose: add "chapter-archive-url"

We have "chapter-url" but we need a parameter to fill in the archiveurl for that chapter (which is different from "url", which is for the whole book). I propose to add "chapter-archive-url" and "chapter-archive-date". -- love.wh 15:55, 18 February 2021 (UTC)

Previous discussions:
Help talk:Citation Style 1 § Archive url/date for chapters
Help talk:Citation Style 1/Archive 74 § Why no archive-chapterurl?
—Trappist the monk (talk) 16:08, 18 February 2021 (UTC)
  • Having proposed this previously, I still agree. --bender235 (talk) 17:53, 19 February 2021 (UTC)
Same here (for a parameter name |archive-chapter-url= rather than |chapter-archive-url=, that is). --Matthiaspaul (talk) 13:56, 21 February 2021 (UTC)

Postscript redux

Per a previous discussion, stable documented use, and a tangential discussion elsewhere on wiki, I've added a maintenance category for |postscript=s longer than 1 character.

More information Wikitext, Live ...
Cite book comparison
Wikitext {{cite book|author=A|postscript=none|title=T}}
Live A. T
Sandbox A. T
Close
More information Wikitext, Live ...
Cite book comparison
Wikitext {{cite book|author=A|postscript=,|title=T}}
Live A. T,
Sandbox A. T,
Close
More information Wikitext, Live ...
Cite book comparison
Wikitext {{cite book|author=A|postscript=.|title=T}}
Live A. T.{{cite book}}: CS1 maint: postscript (link)
Sandbox A. T.{{cite book}}: CS1 maint: postscript (link)
Close
More information Wikitext, Live ...
Cite book comparison
Wikitext {{cite book|author=A|postscript=. A|title=T}}
Live A. T. A{{cite book}}: CS1 maint: postscript (link)
Sandbox A. T. A{{cite book}}: CS1 maint: postscript (link)
Close
More information Wikitext, Live ...
Citation comparison
Wikitext {{citation|author=A|postscript=none|title=T}}
Live A, T{{citation}}: CS1 maint: postscript (link)
Sandbox A, T{{citation}}: CS1 maint: postscript (link)
Close
More information Wikitext, Live ...
Citation comparison
Wikitext {{citation|author=A|postscript=,|title=T}}
Live A, T,
Sandbox A, T,
Close
More information Wikitext, Live ...
Citation comparison
Wikitext {{citation|author=A|postscript=.|title=T}}
Live A, T.
Sandbox A, T.
Close
More information Wikitext, Live ...
Citation comparison
Wikitext {{citation|author=A|postscript=. A|title=T}}
Live A, T. A{{citation}}: CS1 maint: postscript (link)
Sandbox A, T. A{{citation}}: CS1 maint: postscript (link)
Close

Points of interest:

  1. Whether this should be more than 1 byte (ASCII character) or more than 1 code point (Unicode character)?
  2. Whether 1 should be configurable for other wikis with possibly different punctuation expectations? (Alleviates question 1 answer.)
  3. Whether instead of quantity it assesses a specific pattern for goodness and emits the category otherwise (e.g. whether we should just look for 1 [.,;:] or similar)?
  4. Whether the user-specified postscript matches the mode's postscript (for more cleaning like ref similar to the above).

--Izno (talk) 09:37, 30 January 2021 (UTC)

While |postscript= seems to have been intended to define the lead-out character originally, I have seen it being used to specify various longer "post scriptums" as well. I remember that some people even started edit-warring over it when I tried to reduce this to a dot or comma in the past. So, obviously, some people have a need to specify more than a single character there.
Therefore, I have, at several times in the past years, thought that it might be better to officially broaden the intended use-cases for this parameter also in the documentation - this would also better reflect the name of the parameter for post scriptums, rather than only for lead-out characters.
So, if we would enforce this to hold only a specific character (or none) in the future, we should have a good answer for why we actually do this. Is it just riding a principle even if it is against some people's needs, or is enforcing this actually necessary or beneficial for something? Is their actual harm done if people use it to specify more than a single character? What alternatives could we introduce for users needing to specify more than a single character there? Either way, is |postscript= the best parameter name for it?
--Matthiaspaul (talk) 17:43, 30 January 2021 (UTC)
The situations you describe (and several others) arise from the fact that |postscript= in the cs1/2 templates does not mean a postscript. Programmatically it is not even the lead-out character. It is the separator of the last displayed field, and very much a part of the "script", to use another wrong term for displayed output. The parameter-naming fog then causes all the unnecessary confusion and disputes. Give the parameter a proper, self-explanatory label and many of these situations may disappear. 98.0.246.242 (talk) 23:33, 30 January 2021 (UTC)
I do not personally care about the parameter name. If you (all) would like to introduce an alias and/or deprecate the current name, go for it. In the middle of another giant deprecation? Not sure about that. :) --Izno (talk) 07:59, 31 January 2021 (UTC)
As I said in the earlier discussion, |comment=, which is what |postscript= is being abused for, has never had sufficient support for implementation at this talk page. If users want it, they should get an RFC together and show there is a consensus for implementation.
That people have edit warred over it, I can only shake my head. You should point them to the documentation the next time. Since you framed it ambiguously, be aware that we generally support editors placing a comment after the citation-proper in references, so I should hope you were reducing it to a character by simply moving the end curly-brackets.
(None of my actual questions have been answered. ;) --Izno (talk) 07:59, 31 January 2021 (UTC)
A bit confused. Are you advocating for |comment= here? Not a good idea, I don't think. Supposing |postscript= is renamed into something more precise (|final-punctuation=? |end-mark=? there's many ugly choices) then I think the Unicode presentation would be best as it should be more flexible. I would think the answers to the rest follow from this choice. 98.0.246.242 (talk) 15:44, 31 January 2021 (UTC)
Are you advocating for |comment= here? ... I would think the answers to the rest follow from this choice. No. And flexibility may not be necessary. --Izno (talk) 17:25, 31 January 2021 (UTC)
Sure, I pointed to the documentation and engaged into a discussion, but to no avail. The editor was (and is) putting various identifiers, extra links and additional annotation into |postscript=. I moved the identifiers to the |id= parameter, the remainder out of the citation template (but inside the <ref> tags). One of his arguments for putting identifiers into |postscript= was that |id= was only for publisher-supplied identifiers, not for identifiers associated with the work by independent parties or at a later point in time. Of course, we do not make that distinction at present. (This might give us at least a hint how to further improve the templates, but that would be unrelated to |postscript= and hence off-topic here.)
--Matthiaspaul (talk) 12:25, 21 February 2021 (UTC)
only for publisher-supplied identifiers is certainly not how it is documented. Users who make stuff up drive me crazy. :^) --Izno (talk) 17:27, 21 February 2021 (UTC)
1. code points because this module is used in wikis that have multi-byte punctuation characters
2. |postscript= should be just 1 character
3. nah, presentation['ps_cs1'] and presentation['ps_cs2'] are sufficient
4. monkbot task 18 is currently removing |postscript=. for cs1 templates and |postscript=none for cs2 templates; having a maint cat or error message for these conditions seems a good idea.
Although I don't have much to suggest, the terminal punctuation article names 'end mark' and 'stop' as commonly used terms. We might also use |terminator= or |terminal-char=. 'Postscript' does suggest free-form text like an appendix ...
—Trappist the monk (talk) 00:00, 1 February 2021 (UTC)
Noted.
I am not sure you understood my third question. It would be something like 
if not mw.ustring.match(s, '[%.:;,]') then -- a different configurable? list than in (2)
or 
if mw.ustring.match(s, '%P') then -- %P is the complement of the Unicode punctuation group
for the condition as allowing only specific punctuation characters rather than the current 
if #s > 1 then
. I don't know why someone would want to put something there that wasn't punctuation, so that is why I ask. --Izno (talk) 01:16, 1 February 2021 (UTC)
|end-mark= and |terminal(-char|-mark)= seem like good options, but I note the comma is not included in the group per our article. (I'll be back.) --Izno (talk) 01:20, 1 February 2021 (UTC)
I used |list-leadout= in {{Catalog lookup link}} also allowing for prepositions like "and", "or", "as well as" or " & ", but this can be emulated using |postscript=none, so it is not really necessary to support them as valid parameter input.
Searching for a better parameter name, I was thinking about |end-mark= as well, but, as you said, it is an established term and the common definition does not include the comma, so it might be misleading.
As a variation on your |terminal-mark=, |termination-mark= comes to my mind. "Termination mark" is an established term (alongside "continuation mark") in some programming languages and command-line interfaces, where it is used as input to end a command line prematurely before the physical end of the line (or to extend some logical line input beyond the physical line), whereas here we would use it for output. Still, it appears to be conceptually related and descriptive enough to avoid misinterpretation in the context of citation templates.
Ending the parameter name on |-mark= (or |-character=) seems desirable because this could be (re-)used to define special marks for other purposes as well would this become necessary in the future, whereas something like |-separator= might be already too narrow a definition.
--Matthiaspaul (talk) 12:25, 21 February 2021 (UTC)
I guess I gotta wonder: why shouldn't |postscript= (or its 'better' name if one can be found) be constrained to accept only the keyword none? If editors want to add a 'postscript' (of any sort), they can do so after the template's closing }}. Use |postscript=none to suppress cs1 terminal punctuation. When used with cs2, |postscript=none is ignored except that the template emits a maintenance message as described above. I've been noticing recently that there are quite a few instances of {{citation}} that are 'terminated' with a dot outside the closing }} which suggests that editors would rather do that than type the extra 12 characters required for |postscript=..
—Trappist the monk (talk) 14:32, 21 February 2021 (UTC)
Another possibility is that they are unaware of the parameter. Kanguole 14:36, 21 February 2021 (UTC)
Seems like a reasonable question. I know we recommend placing stuff outside the citation template but I also know that VisualEditor's reference tooling does not support 'mixed style' references (which is one reason one might choose to support |comment= also, on that note). I agree with Kanguole about users not knowing about it may be a reason. --Izno (talk) 17:28, 21 February 2021 (UTC)

Allow YYYY-MM format for cite journal?

YYYY-MM-DD is not a valid date for publication dates

Archive url/date for chapters

Pages

Year/date mismatch error config to be moved to config module

ISO date display

Issue with {{{issue}}}

Bad missing URL tag?

Why is {{cite book |isbn=X}} not enough?

Title links bug from PMC, free-doi, etc

Undefined error condition

Support fix-attempted=yes, and categorization for it

Error when using |doi=

further deprecations

cite preprint meta-template

Cite book display: contributors/contribution should FOLLOW author/title, not precede them

Bug in cfg.special_case_translation [list_name]

DOI ends with #

Requested move 8 March 2021

Help:Citation Style 1/test problems

Should cite comic be part of CS1?

"I don't see a reason for that"

Reference and Bibliography?

"Log into Facebook"

Autolinking

Finding errors in Vancouver names

edtf date formats as cs1|2 date parameter values (2)

DOIs greater than 10.49999

asin & isbn

Chuj is unsupported in |language

lua error with invalid access parameter

References listed by editor of the book, but Bibliography lists by author of the chapter

Report style

Help with a citation

Obtuse template style

ISO dates

name-list-format= still in article space

Best way to cite the Vth volume of something?

Related Articles

Wikiwand AI