This page is of interest to multiple WikiProjects. | ||||||||||||||||||||||||||||||||||||||||||||||
|
asin & isbn
|asin=
accepts 10-digit numbers that can be 10-digit ISBNs or 10-digit numbers that begin with 630 or 631 which are not (currently) ISBNs but are ASINs. We have Category:CS1 maint: ASIN uses ISBN where we keep track of |asin=
with a numerical value that is probably an ISBN – the number checks as a numerically valid ISBN.
I have tweaked Module:Citation/CS1/Identifiers/sandbox so that it emits error (red) messages when |asin=
has an assigned numerical value that does not begin with 630 or 631. Additionally, I have tweaked the ISBN-10 validation code so that it emits an error message when |isbn=
has an assigned value beginning with 630 or 631 (probably an ASIN):
Wikitext | {{cite book |title=Title |asin=412346789X}}
|
---|---|
Live | Title. ASIN 412346789X.CS1 maint: ASIN uses ISBN (link) |
Sandbox | Title. ASIN 412346789X Check |asin= value (help).
|
Wikitext | {{cite book |title=Title |asin=6305277001}}
|
---|---|
Live | Title. ASIN 6305277001. |
Sandbox | Title. ASIN 6305277001. |
Wikitext | {{cite book |title=Title |asin=6317484546}}
|
---|---|
Live | Title. ASIN 6317484546.CS1 maint: ASIN uses ISBN (link) |
Sandbox | Title. ASIN 6317484546. |
Wikitext | {{cite book |title=Title |isbn=412346789X}}
|
---|---|
Live | Title. ISBN 412346789X. |
Sandbox | Title. ISBN 412346789X. |
Wikitext | {{cite book |title=Title |isbn=6305277001}}
|
---|---|
Live | Title. ISBN 6305277001. |
Sandbox | Title. ISBN 6305277001 Check |isbn= value: invalid group id (help).
|
Wikitext | {{cite book |title=Title |isbn=6317484546}}
|
---|---|
Live | Title. ISBN 6317484546. |
Sandbox | Title. ISBN 6317484546 Check |isbn= value: invalid group id (help).
|
If this is accepted, Category:CS1 maint: ASIN uses ISBN will go away; these asin errors will categorize in Category:CS1 errors: ASIN. The error message for |isbn=63[0|1].......
reuses an existing error message supplement currently only used for ISBN-13 / ISMN group id errors.
—Trappist the monk (talk) 20:42, 24 January 2021 (UTC)
- Don't see why it would not be accepted. Seems non-controversial and intuitive. 98.0.246.242 (talk) 21:09, 24 January 2021 (UTC)
- Looks good to me as well.
- Speaking of ASINs, we do not currently generate COinS data for ASINs and OLs because we would first need to communicate the ASIN TLD info and the OL A/M/W/X type to the COinS module. Some months back I was in the process of devising some way how to achieve this with minimal changes, but since the internal organization was changed considerable recently and you are more familiar with it I would appreciate if you could have a look at this for a probably more general solution.
- --Matthiaspaul (talk) 22:19, 24 January 2021 (UTC)
- Perhaps I have a solution. If
asin()
gets a pointer toID_list_coins_t{}
in Module:Citation/CS1/Identifiers/sandbox,asin()
can overwrite the plain identifier with a properly assembled url. If we also changeid_handlers['ASIN']['COinS']
to something other thannil
in Module:Citation/CS1/Configuration/sandbox, Module:Citation/CS1/COinS/sandbox will use that value (the url) in an&rft_id=
attribute:{{cite book/new |title=Title |asin=6305277001}}
- Title. ASIN 6305277001.
'"`UNIQ--templatestyles-0000002C-QINU`"'<cite class="citation book cs1">''Title''. [[ASIN (identifier)|ASIN]] [//www.amazon.com/dp/6305277001 6305277001].</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft_id=%2F%2Fwww.amazon.com%2Fdp%2F6305277001%23id-name%3DASIN&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
- Title. ASIN 6305277001.
- I presume that this same scheme will also work for
|OL=
. Also, with a bit of a tweak overwrite an erroneous plain identifier value withnil
(each identifier function in ~/Identifiers/sandbox), and a bit of a tweak to ~/COinS/sandbox so that it can detectnil
identifier values, prevent erroneous identifiers from getting into the metadata. - —Trappist the monk (talk) 17:54, 26 January 2021 (UTC)
- Sorry for the long delay, Trappist, it is only now that I found the time to have a look at your proposed solution. It looks good to me, thanks.
- Getting some means to suppress metadata generation for erroneous identifiers is desirable as well.
- --Matthiaspaul (talk) 12:49, 28 February 2021 (UTC)
- I have hacked Module:Citation/CS1/Identifiers/sandbox to suppress metadata generation for erroneous identifiers. Values from those identifiers that support accept-as-written markup (
|doi=
,|isbn=
,|eissn=
, and|issn=
) are included in the metadata when so marked regardless of validity.|sbn=
supports accept-as-written markup but is not (never has been) included in the metadata because we don't create a url for it, becauserft.sbn
is not a COinS-defined key, and becausesbn
is not registered at info-uri.info (for theinfo:
URI scheme). - This change breaks almost all of the testcases at Module talk:Citation/CS1/testcases/identifiers.
|sbn=
is not broken because metadata are not created for that parameter. I discovered a long-standing bug in Module:Citation/CS1/Configuration/sandbox for|ismn=
. Theid_handlers['ISMN'].COinS
assignment was'nil'
, a string, when it should benil
, the datatype (represents the absence of a value). That was causing the module suite to add a malformedrft_id=<ismn value>
k/v pair to the metadata for citations that use|ismn=
. Fixing that breaks everyismn
testcase. - —Trappist the monk (talk) 21:01, 9 March 2021 (UTC)
- I now see some bogus error messages I didn't recognize two months back, therefore I assume that this is a new issue possibly caused by the changes above:
- No ASIN, invalid TLD:
- I now see some bogus error messages I didn't recognize two months back, therefore I assume that this is a new issue possibly caused by the changes above:
- Perhaps I have a solution. If
Wikitext | {{cite book |title=Title |asin-tld=xy}}
|
---|---|
Live | Title. |
Sandbox | Title. |asin-tld= requires |asin= (help)
|
misses the "Check |asin-tld= value" message.
- No ASIN, valid TLD:
Wikitext | {{cite book |title=Title |asin-tld=de}}
|
---|---|
Live | Title. |
Sandbox | Title. |asin-tld= requires |asin= (help)
|
OK.
- Valid ASIN, invalid TLD:
Wikitext | {{cite book |asin=6305277001 |title=Title |asin-tld=xy}}
|
---|---|
Live | Title. ASIN 6305277001. |
Sandbox | Title. ASIN 6305277001 Check |asin-tld= value (help). |asin-tld= requires |asin= (help)
|
has extra "|asin-tld= requires |asin=" message.
- Valid ASIN, valid TLD:
Wikitext | {{cite book |asin=6305277001 |title=Title |asin-tld=de}}
|
---|---|
Live | Title. ASIN 6305277001. |
Sandbox | Title. ASIN 6305277001. |
OK.
- Invalid ASIN, invalid TLD:
Wikitext | {{cite book |asin=xyz5277001 |title=Title |asin-tld=xy}}
|
---|---|
Live | Title. ASIN xyz5277001 Check |asin= value (help).
|
Sandbox | Title. ASIN xyz5277001 Check |asin-tld= value (help). |asin-tld= requires |asin= (help)
|
has "|asin-tld= requires |asin=" message instead of "check |asin= value".
- Invalid ASIN, valid TLD:
Wikitext | {{cite book |asin=xyz5277001 |title=Title |asin-tld=de}}
|
---|---|
Live | Title. ASIN xyz5277001 Check |asin= value (help).
|
Sandbox | Title. ASIN xyz5277001 Check |asin= value (help). |asin-tld= requires |asin= (help)
|
has extra "|asin-tld= requires |asin=" message.
- Valid ASIN, no TLD:
Wikitext | {{cite book |title=Title |asin=6305277001}}
|
---|---|
Live | Title. ASIN 6305277001. |
Sandbox | Title. ASIN 6305277001. |
OK.
- Invalid ASIN, no TLD:
Wikitext | {{cite book |title=Title |asin=xyz5277001}}
|
---|---|
Live | Title. ASIN xyz5277001 Check |asin= value (help).
|
Sandbox | Title. ASIN xyz5277001 Check |asin= value (help).
|
OK.
- I haven't had a chance to look into this so far.
- --Matthiaspaul (talk) 00:01, 30 March 2021 (UTC)
I'm not sure I understand why Category:CS1 maint: ASIN uses ISBN should be gotten rid of. It's a very useful category, and an ISBN for an ASIN doesn't mean it's an invalid ASIN, just a redundant one that should be converted to an ISBN. Headbomb {t · c · p · b} 17:19, 1 February 2021 (UTC)
This belongs more into the already archived thread at Help_talk:Citation_Style_1/Archive_75#Added_asin-tld=_range_checking, but since I don't want to start a new thread for this minor bit, I'm hijacking this one just to note down that support for Polish ASINs ("pl"), which were introduced earlier this month, has now been added to the template's |asin-tld=
parameter as well.
--Matthiaspaul (talk) 15:23, 29 March 2021 (UTC)
further deprecations
Shall we deprecate some more nonhyphenated parameters? Specifically:
|booktitle=
– None from CS1|chapterurl=
– 9, None from CS1|episodelink=
– 0|mailinglist=
– None from CS1|mapurl=
– All bing URLs|nopp=
– None from CS1|publicationdate=
– None from CS1|publicationplace=
– 0|serieslink=
– 0|transcripturl=
– 0
We might also include |origyear=
but is still used in quite a few articles (search).
—Trappist the monk (talk) 14:02, 3 February 2021 (UTC)
- Support standardization, especially given their mostly extremely low usages.
|origyear=
's 10k usage vs.|orig-year=
's ~60k usage might find some resistance, so I support deferral there, if necessary. ~ Tom.Reding (talk ⋅dgaf) 14:24, 3 February 2021 (UTC) - Support standardization. Also, many of the above numbers are greatly inflated by other templates and urls that have the searched for phrase. AManWithNoPlan (talk) 15:17, 3 February 2021 (UTC)
- Support the continued move away from unhyphenated multi-word parameters, including
|origyear=
. With any other template, it would have been the work of a few days to standardize on one style of parameter name and convert all of the transclusions. The only reason that the process for CS1 templates is different is that there are millions of transclusions instead of hundreds. – Jonesey95 (talk) 17:23, 3 February 2021 (UTC)
- Note - none of the above are from cite/citation template parameters. AManWithNoPlan (talk) 22:19, 3 February 2021 (UTC)
- Thanks for that. I've marked all but
|origyear=
as deprecated. We might add that param to Wikipedia:AutoWikiBrowser/Rename template parameters as a way to push the numbers down. - —Trappist the monk (talk) 23:09, 3 February 2021 (UTC)
- @Trappist the monk: Should we add
|original-year=
as an alias for|orig-year=
? –MJL ‐Talk‐☖ 18:21, 7 February 2021 (UTC)- Could. I'm more-or-less indifferent. If we do add a 'long-form' name, oughtn't it to be
|original-date=
? After all,|orig-date=
is the 'new' canonical form... - —Trappist the monk (talk) 19:15, 7 February 2021 (UTC)
- Could. I'm more-or-less indifferent. If we do add a 'long-form' name, oughtn't it to be
- @Trappist the monk: Should we add
- Thanks for that. I've marked all but
As of this time stamp, I have removed the above parameters from all of the transcludable templates that I could find with searches (about 150 templates). I haven't bothered with /sandbox, /doc, or /testcases pages yet. I also took care of |origyear=
and |authorlink=
, since concerns have been raised about the latter at the hyphenation RFC linked below. – Jonesey95 (talk) 01:12, 20 February 2021 (UTC)
- It looks like
|archiveurl=
and|archivedate=
and|airdate=
are also cleared from transcluded templates. As far as I can tell, the only unhyphenated parameter left in use in template space, excepting a few inevitable stragglers, is accessdate, used in up to 1,100 templates (there are no doubt some false positives in those search results). – Jonesey95 (talk) 03:46, 22 February 2021 (UTC)|authorlink=
is also used in three non-archived places, all apparently used to construct a base CS1 citation to a specific source. David Brooks (talk) 04:52, 22 February 2021 (UTC)Links to those three places would be helpful.Here's what I get when I search. (Edited to add: I just found your helpful link at VPP. Thanks!) – Jonesey95 (talk) 05:33, 22 February 2021 (UTC)- FWIW, nearly all of the direct uses of
|accessdate=
have now been removed from transcluded templates that use CS1 templates. If you click on the link above, you will get a lot of hits for non-CS1 templates that use the unhyphenated parameter, and a few DYK pages that do not get transcluded in article space. If the VPP RFC closes in favor of deprecation (option A or B; there is still time to make a statement there if you wish), we should find that very few of the errors are generated by the use of|accessdate=
in transcluded templates. Possibly none, but I don't entirely trust WP's search engine to give me complete results. – Jonesey95 (talk) 06:28, 7 March 2021 (UTC)
- FWIW, nearly all of the direct uses of
This is just a note to say that the VPP discussion/RFC about deprecation of unhyphenated multi-word parameters is ongoing, and it is unclear how it will end up. It does appear to me that if the parameters are deprecated, there is consensus to not display deprecation error messages to normal readers and editors until a bot has removed all or most of the deprecated parameters. Also, if we are going to deprecate the above parameters by moving the sandbox modules to the live modules sometime soon, including or not including |origyear=
, we may want to do it without displaying error messages, as a good-faith acknowledgement of many editors' frustration with these changes. I will note that nearly all templates that use Module:Check for unknown parameters use hidden categories and show error messages only in Preview mode, which seems to comport with a general consensus that these errors are only for the cognoscenti and do not need to be displayed to readers. – Jonesey95 (talk) 18:51, 4 March 2021 (UTC)
cite preprint meta-template
It's high time we have a template that can support both specific and generic preprint services, and scales accordingly.
{{cite preprint |last# |first#= |year#= ... |title=... |repository= ... |arxiv=... |citeseerx=... |ssrn=...}}
Which could then be used for things like
{{cite preprint |last1=Ambale-Venkatesh |first1=Bharath |last2=Quinaglia |first2=Thiago |last3=Shabani |first3=Mahsima |last4=Sesso |first4=Jaclyn |last5=Kapoor |first5=Karan |last6=Matheson |first6=Matthew B. |last7=Wu |first7=Colin O. |last8=Cox |first8=Christopher |last9=Lima |first9=Joao A C. |year=2021 |title=Prediction of Mortality in hospitalized COVID-19 patients in a statewide health network |repository=[[medRxiv]] |doi=10.1101/2021.02.17.21251758 |pmid=33619510 |pmc=7899480 |s2cid=231959570}}
and give
- Ambale-Venkatesh, Bharath; Quinaglia, Thiago; Shabani, Mahsima; Sesso, Jaclyn; Kapoor, Karan; Matheson, Matthew B.; Wu, Colin O.; Cox, Christopher; Lima, Joao A C. (2021). "Prediction of Mortality in hospitalized COVID-19 patients in a statewide health network". medRxiv. doi:10.1101/2021.02.17.21251758. PMC 7899480. PMID 33619510. S2CID 231959570.
Headbomb {t · c · p · b} 18:07, 23 February 2021 (UTC)
- @Headbomb: Except we shouldn't be citing preprints - if the article is published in a journal afterwards, cite the reviewed version instead... RandomCanadian (talk / contribs) 20:45, 7 March 2021 (UTC)
Title links bug from PMC, free-doi, etc
"[[H]]". PMC 12345. Cite journal requires |journal=
(help); URL–wikilink conflict (help). Same with free doi, etc. AManWithNoPlan (talk) 02:13, 24 February 2021 (UTC)
- That doesn't look like a bug. You can't have a wiklink in
|title=
and also a URL. PMC provides a URL. – Jonesey95 (talk) 04:19, 24 February 2021 (UTC)- If you really want to override the pmc link, the way to do that is to use
|title-link=
:- {{cite journal|title=H|title-link=H|pmc=12345}}
- produces
- (This only lets you link the whole title. But in general, if you wikilink a title, you should wikilink the whole title, to an article about the source being linked; do not link title words to articles about those words.)
- —David Eppstein (talk) 06:06, 24 February 2021 (UTC)
- If you really want to override the pmc link, the way to do that is to use
- I would consider this as a bug (introduced with the original implementation of auto-linking in early 2020). The correct behaviour would be to detect this special case and mute the identifier-derived URL. I already mentioned this at Help_talk:Citation_Style_1/Archive_71#Manual_override_of_auto-linking when I implemented auto-link-overriding, but have not come around to fix it yet.
- One workaround is to use
|title-link=
to provide the link, as David suggests above. Another way is to set|title-link=none
. The latter method even allows to link individual words in the title (although this is not recommended). - It might be worth noting that the COinS metadata remains clean and still contains the title as
rft.atitle=ABC
only (that is, without the embedded link):'"`UNIQ--templatestyles-00000057-QINU`"'<cite class="citation journal cs1">"A[[B]]C". ''Journal''. [[PMC (identifier)|PMC]] <span class="cs1-lock-free" title="Freely accessible">[//www.ncbi.nlm.nih.gov/pmc/articles/PMC12345 12345]</span>.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.jtitle=Journal&rft.atitle=ABC&rft_id=%2F%2Fwww.ncbi.nlm.nih.gov%2Fpmc%2Farticles%2FPMC12345%23id-name%3DPMC&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
- --Matthiaspaul (talk) 13:43, 24 February 2021 (UTC) (updated 22:07, 5 March 2021 (UTC))
"Log into Facebook"
Should we add "Log into Facebook" (and "Log into Facebook - Facebook", "Log into Facebook | Facebook") to Category:CS1 errors: generic title? 83 results in article space. – Finnusertop (talk ⋅ contribs) 04:10, 24 February 2021 (UTC)
- 83 hits is not exactly a lot but I would add it anyway:
- Other related threads:
- --Matthiaspaul (talk) 13:59, 24 February 2021 (UTC) (updated 21:43, 5 March 2021 (UTC))
- Added to sandbox:
Wikitext | {{cite book |title=Log into Facebook}}
|
---|---|
Live | Log into Facebook. |
Sandbox | Log into Facebook. Cite uses generic title (help) |
- --Matthiaspaul (talk) 21:43, 5 March 2021 (UTC)
- @Matthiaspaul: one more that is related to Facebook: "Redirecting...". Searching for "Redirecting... facebook" returns 8 results, but this is not the proper way to search. – Finnusertop (talk ⋅ contribs) 20:04, 11 March 2021 (UTC)
- This search finds ~80 results.
- —Trappist the monk (talk) 20:27, 11 March 2021 (UTC)
- Added to sandbox:
- @Matthiaspaul: one more that is related to Facebook: "Redirecting...". Searching for "Redirecting... facebook" returns 8 results, but this is not the proper way to search. – Finnusertop (talk ⋅ contribs) 20:04, 11 March 2021 (UTC)
- --Matthiaspaul (talk) 21:43, 5 March 2021 (UTC)
Wikitext | {{cite book |title=Redirecting...}}
|
---|---|
Live | Redirecting... |
Sandbox | Redirecting... Cite uses generic title (help) |
- --Matthiaspaul (talk) 14:55, 20 March 2021 (UTC)
generic title
Added internet archive wayback machine
~560 hits
These were added by REFLINKS c. 2012.
—Trappist the monk (talk) 13:08, 3 March 2021 (UTC)
- And added
webcite query result
~300 hits - And these were (are) added by reFill and reFill 2.
- —Trappist the monk (talk) 19:09, 18 March 2021 (UTC)
- And another
wikiwix's cache
~200 hits - —Trappist the monk (talk) 19:22, 25 March 2021 (UTC)
Cite book display: contributors/contribution should FOLLOW author/title, not precede them
Here I'm editing Carl Marzani#Published by Marzani & Munsell. The entry of concern displays as
- King, Jr, Martin Luther; Nelson, Truman (1962). Foreword. Negroes with Guns. By Williams, Robert F. New York: Marzani & Munsell. OCLC 340047.
Only on Wikipedia does the citation give top billing to the author of the Foreword. That's not good, please fix it, so that the entry appears like this:
- Williams, Robert F. (1962). Negroes with Guns. with Foreword by Martin Luther King, Jr; Truman Nelson. New York: Marzani & Munsell. OCLC 340047.
Even better, since the "Foreword" is actually two separate essays by King & one by Nelson, it would be best to have contribution1, contribution2 and contribution3 as parameters.
Nota bene: I put the above into Wikipedia:Village pump (proposals) and a friendly user responded: "Please raise this at Help talk:Citation Style 1 which is where citation template issues are discussed." So here we are. Larry Koenigsberg (talk) 21:46, 1 March 2021 (UTC)
- If you're citing the foreword, then you are citing King & Nelson, whose foreword appeared in a work by Williams. So the template is correct in its presentation order. This isn't a general book reference you find in a list of works cited, it's a specific targeted reference to the foreword itself. If you are not citing the foreword, then you don't to have that information in the template. Headbomb {t · c · p · b} 21:56, 1 March 2021 (UTC)
- If the part you're citing (the part you name in the "contribution" field) is the foreword, then it should be front and center. If you are citing some other part of the book, then you should cite that other part of the book; the contribution field is there to say what you're citing, not to list other stuff that you're not citing. —David Eppstein (talk) 21:58, 1 March 2021 (UTC)
- If you just want to add a mention of the foreword, use
|others=
, such as: - Otherwise, as noted, if you're citing the foreword itself, you'd use
|contribution=Foreward
etc. Imzadi 1979 → 23:26, 1 March 2021 (UTC)
- If you just want to add a mention of the foreword, use
- Some older related threads:
- --Matthiaspaul (talk) 10:50, 7 March 2021 (UTC)
Should cite comic be part of CS1?
As titled - should {{Cite comic}} be incorporated into the CS1 module? (Previous discussion in 2013: Template talk:Cite comic#CS1)
Some observations on the template:
- In Template talk:Cite comic#Language field (2011 and 2013), there were some complaints on the lack of
|trans-title=
which is currently already available in CS1. - Other than that, the template also lacks stuff like
|url-access=
,|archive-url=
,|via=
, etc. |isbn=
is not available and has to be manually entered in the format of|id=ISBN 0123456789
.- No COinS is generated.
Note: The template has a unique display for the various author fields (|writer=
, |artist=
, etc.) and might not be straightforward to merge into CS1; hence bringing this up but not making it an official tfm nomination. ネイ (talk) 15:36, 3 March 2021 (UTC)
- It seems like it wouldn't be that difficult to make it a wrapper of {{citation}} or {{cite book}}. Give it a try in the sandbox. – Jonesey95 (talk) 16:25, 3 March 2021 (UTC)
- Depends on what is meant by cite comic. Is it a specific issue? Then probably the closest analog is {{cite magazine}}. Is it an anthology or collection? Then probably the closest is {{cite encyclopedia}} or one of the other redirects of that sort. The other issue of course is similar to the one that {{cite AV media}} and notes has in that it has many other fields for people who are not the author (and which subsequently do not necessarily fit into the CS1/2 mechanism all that well). Izno (talk) 03:37, 21 March 2021 (UTC)
Why is {{cite book |isbn=X}} not enough?
This is a fundamental design question relating to Wikipedia infrastructure. It has probably been discussed but I do not know where (hints appreciated). It does not seem to have been implemented. If Wikipedia were designed like any sane relational database, every source (book, website) would have its own record (i.e. a unique page) with fields (author name, publisher, date etc) already populated and verified. For any given source this would be done once, ever. And then any article in the whole encyclopedia could reference the source with a simple {{ cite book |id=x}} or {{ cite website |id=X }} (adding page number or URL path for precision). Unique IDs exist already: ISBN for books, registered domains for websites. Instead, authors are having to laboriously re-enter this data for every article, with the obvious risk of corruptions and disparities. This situation seems almost unbelievably inefficient. What am I missing? Rollo (talk) 22:32, 3 March 2021 (UTC)
- @Rollo: You may be looking for {{cite q}}. Wikipedia tried cite doi and didn't like it, but maybe cite q will go better. --Izno (talk) 22:46, 3 March 2021 (UTC)
- Further to what Editor Izno stated, ISBNs, while they are supposed to be unique, are not. Citoid (used by RefToolbar and by the abomination that is Visual Editor) draws information from WorldCat to fill citations in a manner somewhat akin to what you describe. WorldCat is full of these non-unique ISBNs. There is a move afoot to do something like you suggest. See WikiCite (but don't hold your breath for that to happen any time soon ...)
- —Trappist the monk (talk) 23:00, 3 March 2021 (UTC)
- I believe the problem with bad ISBNs of any kind was more due to governance issues with the various ISBN authorities. Some of them were pretty lax and the International body had been aloof. It seems things are run much better now, but of course that doesn't help with these "historical" ISBNs. 98.0.246.242 (talk) 04:31, 4 March 2021 (UTC)
- The modern "unique" ISBNs are in fact less in line with Wikipedia's purposes (the main purpose in this context being WP:V). A 21st-century book can be published concurrently in several formats (paperback, eBook, ...), by different publishers (e.g. one publisher in the UK, and another publisher in the US), and there may be reprints, etc. In a modern approach, all these editions have different ISBNs. Now, for Wikipedia's purposes, i.e. WP:V, it really doesn't matter whether the reference to the source is to the 'linen bound' or 'paperback' version. But one version (e.g. a pre-ISBN original print) may be available for free at archive.org, large sections of another print of the same book (e.g. one published in 10-digit ISBN era) may be available at Google books, while its most recent print, by yet another publisher, and with a "modern" ISBN, is only available as dead wood copy. WP:V aims at assisting Wikipedia editors checking ("verifying") article content to reliable sources: in the case of the example above, giving only the "modern" 13-digit ISBN is counterproductive to a swift verification of article content. Similar for paperback vs. ebook (etc): one may (partially) accessible online, while another isn't. Giving only one modern ISBN can, in this case, also be counterproductive to WP:V expectations. For clarity, a reliable source which is only available off-line is of course OK for WP:V, but why give the impression a book is only available off-line when it is accessible on-line? Besides, what I'm trying to say here also applies when only paper copies exist: a Wikipedia editor may own a 'paperback' version, while the reference in an article gives the ISBN for a 'hardcover' version of the same book: ideally we would have a unique identification of a book with a certain content, independent of the distribution format – when the reference uses page numbers the identification would ideally be for books with the same content and the same pagination. None of that is the same as a unique identification via a modern ISBN number (except if there's only one single edition of the book, but that is becoming rare nowadays as modern books are often concurrently published in paper and eBook versions, and older books are easily republished in eBook format, with a new ISBN). --Francis Schonken (talk) 07:41, 4 March 2021 (UTC)
- To verify content needs a link to the source that was actually used - we cannot use an old edition to verify what is said in a later edition and vice-versa - contents may vary with time and location of publication and even with consecutive publication of different print and electronic editions, things like page numbering will differ. Automatic systems for filling in references are limited by the fact that often the databases which these are based on, like Worldcat are error-strewn, thus there are often dozens of entries for the same edition of the same book, or worldcat entries that give incorrect author/editor information - (for example people who have been dead for 20 years listed as author/editor for editions of annuals like Jane's All the World's Aircraft). And then of course you still get high quality books by reputable publishers issued with the wrong ISBN number.Nigel Ish (talk) 08:56, 4 March 2021 (UTC)
- Re. "To verify content needs a link to the source that was actually used" – no, it doesn't. Off-line sources are perfectly acceptable (see WP:V). The source needs identification (not necessarily a "link"), and ISBNs are far from the ideal tool for unique identification of book content (that is, in Wikipedia's WP:V context, which is the context of importance here). --Francis Schonken (talk) 09:26, 4 March 2021 (UTC)
- Link is perhaps the wrong word, but WP:SAYWHEREYOUGOTIT still applies - you can't necessarily say that two different editions of the same work say the same thing - information may have been superceded in later editions or been removed for spacing reasons, and page numbering may differ between different format versions issued at the same - it's no good pointing to page 32 of a book unless you also say which edition of the book to point to - if you point to ta different edition to that used to cite the information, then there is every chance that verification attempts will fail.Nigel Ish (talk) 13:54, 4 March 2021 (UTC)
- WP:SAYWHEREYOUGOTIT does not speak about quality of references, only about a minimum. It does not prevent a reformatting or expansion of references in view of a better compliance to WP:V. Neither does it necessitate usage of an ISBN. Not even for books. Not even for books that have an ISBN. I don't even see what WP:SAYWHEREYOUGOTIT has to do with this.
- Example: page 1 of ISBN 0199248842 is exactly identical to page 1 of ISBN 039304825X, and so on for hundreds more pages of these two publications of the same book. And the book still has a few other ISBN numbers (all with identical pagination). In which case none of these ISBN numbers is a unique identification number for the content of this book that can be used for references in Wikipedia (well, it frequently is). So, only giving one of these ISBNs (without even naming title, author, publication date, publisher), is not very generous (as in: not all too helpful) WP:V-wise for those who want to verify Wikipedia's content, although, of course, any of these ISBNs, with a page number, could be a "SAYWHEREYOUGOTIT" for the Wikipedia editor who based mainspace content on it. But for the OP's question: no, only an ISBN number without other particulars of the publication (or, in an opposite direction: not mentioning the ISBN of a reference work that has an ISBN), may get you past WP:SAYWHEREYOUGOTIT, but is indeed "not enough" WP:V-wise. --Francis Schonken (talk) 14:31, 4 March 2021 (UTC)
- Link is perhaps the wrong word, but WP:SAYWHEREYOUGOTIT still applies - you can't necessarily say that two different editions of the same work say the same thing - information may have been superceded in later editions or been removed for spacing reasons, and page numbering may differ between different format versions issued at the same - it's no good pointing to page 32 of a book unless you also say which edition of the book to point to - if you point to ta different edition to that used to cite the information, then there is every chance that verification attempts will fail.Nigel Ish (talk) 13:54, 4 March 2021 (UTC)
- Re. "To verify content needs a link to the source that was actually used" – no, it doesn't. Off-line sources are perfectly acceptable (see WP:V). The source needs identification (not necessarily a "link"), and ISBNs are far from the ideal tool for unique identification of book content (that is, in Wikipedia's WP:V context, which is the context of importance here). --Francis Schonken (talk) 09:26, 4 March 2021 (UTC)
- To verify content needs a link to the source that was actually used - we cannot use an old edition to verify what is said in a later edition and vice-versa - contents may vary with time and location of publication and even with consecutive publication of different print and electronic editions, things like page numbering will differ. Automatic systems for filling in references are limited by the fact that often the databases which these are based on, like Worldcat are error-strewn, thus there are often dozens of entries for the same edition of the same book, or worldcat entries that give incorrect author/editor information - (for example people who have been dead for 20 years listed as author/editor for editions of annuals like Jane's All the World's Aircraft). And then of course you still get high quality books by reputable publishers issued with the wrong ISBN number.Nigel Ish (talk) 08:56, 4 March 2021 (UTC)
- The modern "unique" ISBNs are in fact less in line with Wikipedia's purposes (the main purpose in this context being WP:V). A 21st-century book can be published concurrently in several formats (paperback, eBook, ...), by different publishers (e.g. one publisher in the UK, and another publisher in the US), and there may be reprints, etc. In a modern approach, all these editions have different ISBNs. Now, for Wikipedia's purposes, i.e. WP:V, it really doesn't matter whether the reference to the source is to the 'linen bound' or 'paperback' version. But one version (e.g. a pre-ISBN original print) may be available for free at archive.org, large sections of another print of the same book (e.g. one published in 10-digit ISBN era) may be available at Google books, while its most recent print, by yet another publisher, and with a "modern" ISBN, is only available as dead wood copy. WP:V aims at assisting Wikipedia editors checking ("verifying") article content to reliable sources: in the case of the example above, giving only the "modern" 13-digit ISBN is counterproductive to a swift verification of article content. Similar for paperback vs. ebook (etc): one may (partially) accessible online, while another isn't. Giving only one modern ISBN can, in this case, also be counterproductive to WP:V expectations. For clarity, a reliable source which is only available off-line is of course OK for WP:V, but why give the impression a book is only available off-line when it is accessible on-line? Besides, what I'm trying to say here also applies when only paper copies exist: a Wikipedia editor may own a 'paperback' version, while the reference in an article gives the ISBN for a 'hardcover' version of the same book: ideally we would have a unique identification of a book with a certain content, independent of the distribution format – when the reference uses page numbers the identification would ideally be for books with the same content and the same pagination. None of that is the same as a unique identification via a modern ISBN number (except if there's only one single edition of the book, but that is becoming rare nowadays as modern books are often concurrently published in paper and eBook versions, and older books are easily republished in eBook format, with a new ISBN). --Francis Schonken (talk) 07:41, 4 March 2021 (UTC)
- I believe the problem with bad ISBNs of any kind was more due to governance issues with the various ISBN authorities. Some of them were pretty lax and the International body had been aloof. It seems things are run much better now, but of course that doesn't help with these "historical" ISBNs. 98.0.246.242 (talk) 04:31, 4 March 2021 (UTC)
Undefined error condition
Some recent edits at Triple H (see ref [253]) show that bad input can give the error shown:
{{cite web|url=https://example.com|title=Example|date=February 6, 2019|osti-access=February 19, 2021}}
- Lua error in Module:Citation/CS1/Utilities at line 127: Called with an undefined error condition: invalid_param_val.
Does something in the module need tweaking? Johnuniq (talk) 06:58, 5 March 2021 (UTC)
- Backtrace as provided there:
[C]: in function "error" Module:Citation/CS1/Utilities:127: in function "set_message" Module:Citation/CS1/Identifiers:1416: in function "extract_id_access_levels" Module:Citation/CS1/Identifiers:1516: in function "identifier_lists_get" Module:Citation/CS1:3022: in function "citation0" Module:Citation/CS1:4123: in function "chunk" mw.lua:518: ? [C]: ?
- --Izno (talk) 07:14, 5 March 2021 (UTC)
- Fixed in sandbox:
- —Trappist the monk (talk) 12:16, 5 March 2021 (UTC)
Support fix-attempted=yes, and categorization for it
The CS1 templates that support |url=
and |url-status=
should also support the following from {{dead link}}
:
fix-attempted
- Set this to "yes" if you have tried unsuccessfully to find an archived copy, or a copy with a different URL. This will put the page in Category:Articles with permanently dead external links. Note that a link that is not in the Internet Archive (Wayback machine) can very often be found, e.g. by a search for the full title, in quotes, on the original Web site or the Internet at large, if the Wayback machine fails.
We lose functionality by recording the link death in the citation template instead of with that stand-alone template (which we generally should not be using except for citations anyway; if a link in "External links" has gone dead, it should just be removed since the entire section is optional and is not part of the encyclopedia content per se, i.e. there is no WP priority to fix dead links in that section, but a high priority to do so in citations that have broken). — SMcCandlish ☏ ¢ 😼 11:54, 5 March 2021 (UTC)
Error when using |doi=
See this. The doi parameter is, by the nature of things, effectively an URL, so it shouldn't be causing an error. Unless this is intentional? RandomCanadian (talk / contribs) 04:24, 6 March 2021 (UTC)
- The problem has nothing to do with the doi. If you removed the doi from the citation you would get the same error message. The problem is that {{cite web}} is only for web pages (with urls) and you are trying to use it for something that you are not linking as a web page (with a url). I think {{cite encyclopedia}} is probably the right choice for this citation, or you could use {{cite Grove}}. —David Eppstein (talk) 05:01, 6 March 2021 (UTC)
- Had no clue that existed. Still counter-intuitive because a doi is usually also a valid url; i.e. in this case if you just append "https://" in front of "10.1093/gmo/9781561592630.article.13655" then you have a perfectly valid url... The template should recognize that and not throw an error. Cheers, RandomCanadian (talk / contribs) 05:17, 6 March 2021 (UTC)
- It is not a url. It tells you the identity of the document you are looking for, not the address on the internet that you should get it from. You have to go through the doi system (the https://doi.org server) to convert it into a url, and the result of the conversion could theoretically be different depending on when you did it or where you were coming from when you did it. In any case, even when you are linking to journal articles or books or newspaper articles by their urls, it is better to use the {{cite journal}} or {{cite book}} or {{cite news}} templates so that the citation has the other appropriate metadata, rather than just using {{cite web}} for everything. As the cite web documentation says, it is "for web sources that are not characterized by another CS1 template". —David Eppstein (talk) 05:39, 6 March 2021 (UTC)
- Correct. If I may be excessively pedantic, the doi.org servers do not "convert" the doi into a url, they resolve it, using their authoritative database (the directory of all doi numbers). Sorry about the geekfest. 69.193.220.107 (talk) 18:52, 6 March 2021 (UTC)
- It is not a url. It tells you the identity of the document you are looking for, not the address on the internet that you should get it from. You have to go through the doi system (the https://doi.org server) to convert it into a url, and the result of the conversion could theoretically be different depending on when you did it or where you were coming from when you did it. In any case, even when you are linking to journal articles or books or newspaper articles by their urls, it is better to use the {{cite journal}} or {{cite book}} or {{cite news}} templates so that the citation has the other appropriate metadata, rather than just using {{cite web}} for everything. As the cite web documentation says, it is "for web sources that are not characterized by another CS1 template". —David Eppstein (talk) 05:39, 6 March 2021 (UTC)
- Had no clue that existed. Still counter-intuitive because a doi is usually also a valid url; i.e. in this case if you just append "https://" in front of "10.1093/gmo/9781561592630.article.13655" then you have a perfectly valid url... The template should recognize that and not throw an error. Cheers, RandomCanadian (talk / contribs) 05:17, 6 March 2021 (UTC)
Bug in cfg.special_case_translation [list_name]
@Trappist the monk: About the cfg.special_case_translation [list_name], this may have no effect on enwiki, but it has affected the results of non-English wikis, shows like "|display-作者=10 (帮助)" error messages, this is not a real parameter name.
p.s. I am updating the CS1 to zhwiki (it is an old versions from five years ago), and I have trouble due to format changes and deprecated parameters like dead-url. Looking forward to a better internationalization. --YFdyh000 (talk) 12:34, 7 March 2021 (UTC)
- That happens because error_conditions.err_disp_name[message] hasn't been translated.
- —Trappist the monk (talk) 12:45, 7 March 2021 (UTC)
- I think this is wrong, the err_disp_name message should not get special translation for parameter $1, this creates a combination of content that should not be translated.--YFdyh000 (talk) 10:58, 8 March 2021 (UTC)
- If I have correctly decoded what it is that you are really complaining about, it is that current error message mechanism doesn't adequately handle locally named aliases of the en.wiki parameter names. If that is what you are really saying, then I have some sympathy for that position. I have tweaked Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox so that the module no-longer assembles the parameter name but instead uses the parameter name given in the template.
{{cite book/new |title=Title |author=Author |display-authors=3}}
- Author. Title. Invalid
|display-authors=3
(help)
- Author. Title. Invalid
- —Trappist the monk (talk) 13:58, 8 March 2021 (UTC)
- If I have correctly decoded what it is that you are really complaining about, it is that current error message mechanism doesn't adequately handle locally named aliases of the en.wiki parameter names. If that is what you are really saying, then I have some sympathy for that position. I have tweaked Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox so that the module no-longer assembles the parameter name but instead uses the parameter name given in the template.
- I think this is wrong, the err_disp_name message should not get special translation for parameter $1, this creates a combination of content that should not be translated.--YFdyh000 (talk) 10:58, 8 March 2021 (UTC)
Requested move 8 March 2021
- The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.
The result of the move request was: Not moved (non-admin closure) (t · c) buidhe 02:23, 15 March 2021 (UTC)
– It's not really possible to cite a conference, only a specific presentation at one, the actual work. Trying to "cite a conference" would be like trying to "cite a corporation" or "cite a TV network". Not something WP would do. If one means to cite some written material that was included in a conference proceedings book, but which was not a presentation (e.g. some kind of post hoc introductory or analysis material), that would be better with {{cite paper}}
or {{cite report}}
). PS: I'm listing this here because Template talk:Cite conference redirects to this talk page. — SMcCandlish ☏ ¢ 😼 02:22, 8 March 2021 (UTC)
- You have requested a name change based on a misunderstanding. {{cite conference}} is to cite the proceedings, not a conference per se. The documentation has said as such for a long time. --Izno (talk) 02:34, 8 March 2021 (UTC)
- Speedy oppose seemingly a misunderstanding. A parallel can be made: we don't cite a journal, we cite an article within it. The documentation is rather clear. Cheers, RandomCanadian (talk / contribs) 03:40, 8 March 2021 (UTC)
- There's no such thing as a "speedy oppose". All your response has done, really, is point out that the template-and-redirect relationship of
{{cite journal}}
and{{cite paper}}
should probably be flipped. — SMcCandlish ☏ ¢ 😼 08:42, 8 March 2021 (UTC)- Seems like making a point just to make a point. cite paper has so few uses, I don't see why we'd want to change a long standing practice just out of some arcane reasoning that it's the "correct" way to refer to things. As for why it's "{{cite journal}}", that's because an 'article' ['paper' is a misnomer when the format is usually electronic...] could also refer to {{cite news}}. RandomCanadian (talk / contribs) 16:08, 8 March 2021 (UTC)
- Template redirects usually have few uses (unless they are convenient shortcuts like
{{cn}}
), precisely because they are redirects. We have bots and AWB scripts that auto-replace those redirects with the names of the actual templates (while making a more substantive edit of some kind, per WP:MEATBOT). So your sense that the redirect isn't used much is meaninless. It's weird to me that zero of the opposition responses here have been substantive in any way, much less actually addressed the rationale of the proposal. It's all WP:IDONTLIKEIT handwringing about change in general. This is not NeophobiaPedia last I looked. — SMcCandlish ☏ ¢ 😼 02:19, 9 March 2021 (UTC)- You want to change something that is most definitively not broken; like the template parameters annoyance of late. Your sole argument is what exactly? {{cite news}} does not cite a whole newspaper, only one article. {{cite journal}} does not cite a whole journal, only an article. {{cite conference}} does not cite a whole conference, only a part of it. The current title is meeting WP:CONSISTENCY with the existing style and is also more helpful by avoiding possible ambiguities in other areas (not all instances of citing a journal are what is termed a "paper" - occasionally this can be a review or something; and well "article" could refer both to a scholarly [journal] as well as to a popular press [news] publication)... As for "redirects usually have few uses": it also shows that the current style is well understood and well established and changing it on a technical whim likely isn't a productive spending of time. RandomCanadian (talk / contribs) 03:06, 9 March 2021 (UTC)
- Template redirects usually have few uses (unless they are convenient shortcuts like
- Seems like making a point just to make a point. cite paper has so few uses, I don't see why we'd want to change a long standing practice just out of some arcane reasoning that it's the "correct" way to refer to things. As for why it's "{{cite journal}}", that's because an 'article' ['paper' is a misnomer when the format is usually electronic...] could also refer to {{cite news}}. RandomCanadian (talk / contribs) 16:08, 8 March 2021 (UTC)
- There's no such thing as a "speedy oppose". All your response has done, really, is point out that the template-and-redirect relationship of
- Comment @SMcCandlish:, although personally I'm fine with "Cite conference", I was going to create {{Cite proceedings}} for you and link it here since I get your point, and logically "Cite proceedings" is unambiguous where "Cite conference" might not be. As it turns out, someone created it ages ago. I'll probably start using that redirect myself, as I think it makes more sense. Mathglot (talk) 04:43, 8 March 2021 (UTC)
- Agree that "Cite proceedings" is probably the better format. In which case this should be procedurally closed and a new one with the better target opened. RandomCanadian (talk / contribs) 04:58, 8 March 2021 (UTC)
- It's a good redirect to have, but in this day and age we're often enough actually citing the presentation itself, since plenty of conferences are videoed in their entirety and available as online video. While one could also use
{{cite video}}
or{{cite web}}
(or probably even{{cite speech}}
for that matter), the ability to cite the same thing with any of several templates is nothing new, and not a problem, nor of any real relevance to the RM, which is about this particular template not being well-named. Anyway, whether we're citing the paper version of the presentation printed in the proceedings (or e-printed in the online copy of the proceedings), or we're citing an actual recording of the presentation, we're still citing the presentation, not the entire conference and not the entire proceedings volume, per se, so I stand by the rename proposal. — SMcCandlish ☏ ¢ 😼 08:42, 8 March 2021 (UTC)- I don't mind if "Cite proceedings" is created as a redirect to "Cite conference". But I oppose making "Cite proceedings" as the main name of the template because many journals are titled "Proceedings of ...". Examples include Proceedings of the IEEE, Proceedings of the National Academy of Sciences, and Proceedings of the Royal Society B: Biological Sciences. Jc3s5h (talk) 16:25, 8 March 2021 (UTC)
- Well, that's not the rename proposed here (it's to
{{Cite presentation}}
). And I'm not sure that "titles starting with ..." thing would matter anyway. Various movies and such are named "[The] Book of ...", yet this has no pro or con effect on whether we have a template named{{Cite book}}
. If someone can't tell whether they are citing a journal versus a conference proceedings volume (or whether they're citing a film versus a book), they're not competent to create citations in the first place. — SMcCandlish ☏ ¢ 😼 02:19, 9 March 2021 (UTC)
- Well, that's not the rename proposed here (it's to
- I don't mind if "Cite proceedings" is created as a redirect to "Cite conference". But I oppose making "Cite proceedings" as the main name of the template because many journals are titled "Proceedings of ...". Examples include Proceedings of the IEEE, Proceedings of the National Academy of Sciences, and Proceedings of the Royal Society B: Biological Sciences. Jc3s5h (talk) 16:25, 8 March 2021 (UTC)
- Oppose move on the basis that we already have too much churn in citation template parameter names and too many robots cluttering up our watchlists with too many edits changing working parameter names to other parameter names, and this will lead to many more of the same wasteful, useless, and distracting edits. —David Eppstein (talk) 17:00, 8 March 2021 (UTC)
- Not a valid rationale. This has nothing to do with (and will have no effect on) bots changing parameter names. You're making an argument like "I hate cats because a dog bit me once, so all small furry things must be bad." — SMcCandlish ☏ ¢ 😼 02:09, 9 March 2021 (UTC)
- Are you being deliberately obtuse? Changing the canonical name of the template is likely to lead to requests by the bot-people to allow their bots to go through articles and make the same change to those articles, just as changing the canonical name of some parameters has led to the same sort of make-work changes by bots. —David Eppstein (talk) 02:48, 9 March 2021 (UTC)
- Not a valid rationale. This has nothing to do with (and will have no effect on) bots changing parameter names. You're making an argument like "I hate cats because a dog bit me once, so all small furry things must be bad." — SMcCandlish ☏ ¢ 😼 02:09, 9 March 2021 (UTC)
- Oppose: The current template title is stable and the proposer has had an option to withdraw at this point. Where one wishes to cite a live presentation, one has {{cite AV media}}. I might even suggest that one could use {{cite AV media notes}} if one wanted to cite the presentation itself (the "slides", as they usually go). But the point of the template is neither of those two items but instead to cite the proceedings and the articles/papers contained therein. There are many hills one might die on regarding CS1/2, but this ain't one of them. (I would entirely prefer if this template simply disappeared and any necessary parameters added to {{cite journal}} given what they are citing, but that is neither the proposal on the table nor proposed by the proposal mechanism used here.) --Izno (talk) 03:14, 9 March 2021 (UTC)
- Oppose: As others have remarked/hinted, the source that the template cites is the entire published conference proceedings (the "conference"). A conference presentation that assumes a publishing life of its own can be cited with the template appropriate for that situation. If that is not the case, it should be cited as a location within the source. 98.0.246.242 (talk) 05:39, 9 March 2021 (UTC)
- Oppose per Izno. --NSH001 (talk) 02:07, 14 March 2021 (UTC)
DOI ends with #
Smith, J. (2006). Journal of Nothing. 1 (2): 3–4. doi:10.1039/B909133E#.CS1 maint: untitled periodical (link)
Should throw an error. Headbomb {t · c · p · b} 04:19, 8 March 2021 (UTC)
- Why? Is there something in the DOI specification that forbids the # character in a DOI suffix? I am unable to find it. It looks to me as if DOI suffixes can even contain emojis, perversely enough, though I could be wrong:
The DOI name is case-insensitive and can incorporate any printable characters from the legal graphic characters of Unicode.
– Jonesey95 (talk) 06:04, 8 March 2021 (UTC)- There's a bunch of things about DOIs that are technically legal, but aren't used. You could, in theory, have 10.14asdfa14234/something, but in practice, it's 10.####/something or 10.#####/something. You can search for DOIs ending in #, none resolve to anything. Headbomb {t · c · p · b} 08:36, 8 March 2021 (UTC)
- The module can enforce the correct identifier format. It is beyond scope to ascertain that the target exists, or that it is the correct one. 24.103.251.114 (talk) 13:01, 8 March 2021 (UTC)
- The module already enforces known bad DOIs, like Smith, J. (2006). Journal of Nothing. 1 (2): 3–4. doi:10.155555/foobar Check
|doi=
value (help).CS1 maint: untitled periodical (link) even if they fit what is technically allowed. Headbomb {t · c · p · b} 17:14, 8 March 2021 (UTC)- This may be jumping the gun. For all one knows, this may come to pass in the future, since it is allowed. I see no downside from removing the particular checking function, and any other that devotes processing time to something that is technically allowed but not presently used. Apart from wasting cycles, it seems like an unnecessary limitation that produces no tangibles. There's another minus: while I have no way to forecast whether "foobar" will ever be used in a doi, if it does the module will have to be modified yet again, to amend the doi-checking function. 98.0.246.242 (talk) 05:12, 9 March 2021 (UTC)
- Then you lack both imagination and experience doing cleanup on Wikipedia, because DOI checking yields tons of errors and fixes. Headbomb {t · c · p · b} 05:15, 9 March 2021 (UTC)
- We are discussing something that is not an error and therefore does not need a fix. Especially not one that comes with overhead. 98.0.246.242 (talk) 05:25, 9 March 2021 (UTC)
- FYI to the OP, searching the web for "doi regular expression match" (without the quotes) will yield some interesting attempts at trying to solve the problem of how to find a valid DOI. I don't think any of the people in the threads I read were able to solve the problem fully, because the spec is so permissive. – Jonesey95 (talk) 05:49, 9 March 2021 (UTC)
- We are discussing something that is not an error and therefore does not need a fix. Especially not one that comes with overhead. 98.0.246.242 (talk) 05:25, 9 March 2021 (UTC)
- Then you lack both imagination and experience doing cleanup on Wikipedia, because DOI checking yields tons of errors and fixes. Headbomb {t · c · p · b} 05:15, 9 March 2021 (UTC)
- This may be jumping the gun. For all one knows, this may come to pass in the future, since it is allowed. I see no downside from removing the particular checking function, and any other that devotes processing time to something that is technically allowed but not presently used. Apart from wasting cycles, it seems like an unnecessary limitation that produces no tangibles. There's another minus: while I have no way to forecast whether "foobar" will ever be used in a doi, if it does the module will have to be modified yet again, to amend the doi-checking function. 98.0.246.242 (talk) 05:12, 9 March 2021 (UTC)
- The module already enforces known bad DOIs, like Smith, J. (2006). Journal of Nothing. 1 (2): 3–4. doi:10.155555/foobar Check
- The module can enforce the correct identifier format. It is beyond scope to ascertain that the target exists, or that it is the correct one. 24.103.251.114 (talk) 13:01, 8 March 2021 (UTC)
- There's a bunch of things about DOIs that are technically legal, but aren't used. You could, in theory, have 10.14asdfa14234/something, but in practice, it's 10.####/something or 10.#####/something. You can search for DOIs ending in #, none resolve to anything. Headbomb {t · c · p · b} 08:36, 8 March 2021 (UTC)
Autolinking
Please autolink the title when |hdl=
and |hdl-access=
are provided similar to how it works with a supplied |doi=
. Please add hdl
as an option for |title-link=
with |hdl=
for cite journal. It would be useful if the combination of |hdl=
, |hdl-access=
, and |title-link=
worked for cite report, techreport, or web too. Thank you. --Whywhenwhohow (talk) 04:30, 8 March 2021 (UTC)
- The PMC content is sometimes stale when compared with the journal article and should not be the default when a free doi or free hdl is present. The existence of the paramaters
|doi-free=
or|hdl-free=
should cause the doi or hdl to have priority and be used instead of the pmc for the title link. --Whywhenwhohow (talk) 23:59, 8 March 2021 (UTC)
- What is the process to implement these recommendations? --Whywhenwhohow (talk) 05:27, 26 March 2021 (UTC)
- For the articles you edit? Add the url you want to link as the
|url=
parameter. That way the logic for which thing somehow overrides which other thing can be as convoluted as you like and the rest of us don't have to try to understand or remember it. —David Eppstein (talk) 06:14, 26 March 2021 (UTC)
- For the articles you edit? Add the url you want to link as the
- What is the process to implement these recommendations? --Whywhenwhohow (talk) 05:27, 26 March 2021 (UTC)
Obtuse template style
Why are volume, number, and page labels suppressed in {{cite journal}}? For example, volume=5 number=37 page=17 renders as an inscrutable 5 (37):17
. Why not show vol: and p: ? There is also an inconsistency. For example, if {{cite news}} or {{cite web}} are used, page does display as "p." and pages as "pp." JGHowes talk 18:26, 12 March 2021 (UTC)
- Because outside of Wikipedia, scholarly and academic journals commonly use that style so cs1|2 reflects that.
{{cite journal}}
has used this style since it's very early days. There has been some discussion, on and off, about changing that. - —Trappist the monk (talk) 18:43, 12 March 2021 (UTC)
- The last planning discussion and the last unplanned discussion. I'm pretty close to starting an RFC, just need to get some stuff written down. --Izno (talk) 19:45, 12 March 2021 (UTC)
- I don't know for cite journal but {{cite book}}, if you put anything besides a plain number in |volume=, it isn't bolded, ex. [1], so there's that. I mean, it shouldn't be much of a problem changing the journal template so it displays "vol. x"; but again it's really a minor issue of citation style and so long the source is uniquely identifiable we shouldn't be worrying too much about that. RandomCanadian (talk / contribs) 20:10, 12 March 2021 (UTC)
- That happens because you wrote
|volume=vol. 1
which value causes Module:Citation/CS1 to render no-bold-volume because the value is five-characters in length. You should not be doing what you did. It is the responsibility of the templates to format the values supplied in parameters when the citation is rendered. If this discussion or some other discussion leads us to change how{{cite book}}
renders|volume=
so that it renders as 'vol. <volume value>', your citation will then render as 'vol. vol. 1.' and someone will have to fix it. Please don't include extraneous text in cs1|2 parameter values. - —Trappist the monk (talk) 20:31, 12 March 2021 (UTC)
- That was very much an intentional work-around because I'm personally not happy with that formatting - I have seen it used for journals but not for books. RandomCanadian (talk / contribs) 20:39, 12 March 2021 (UTC)
- With all respect, is it not simpler to not use CS1 templates? Then you format the citation the way you see fit. The rationale behind emphasizing the volume was to make people aware that this is a multi-part source, the search for which does not end with locating the title, one should dig deeper to find the appropriate part. Bold weight is used as emphasis to distinguish from the emphasis given to the title, which is in italic type. And obviously the template rendering of the volume parameter is confusing and contradictory, and the instructions are inadequate. I would use a freehand citation rather than trying to figure out the nonsensical. 98.0.246.242 (talk) 01:09, 13 March 2021 (UTC)
- The only problem with doing a freehand citation is that, if you're trying to get the article promoted to GA or FA, you're likely to encounter objections to inconsistent citation formatting. JGHowes talk 01:30, 13 March 2021 (UTC)
- Not using citation templates is a bad thing, IMO, in particular if it is only for stylistic reasons. If there is a demand to support something that our current templates do not allow for, the templates should be improved rather than not used.
- --Matthiaspaul (talk) 13:14, 13 March 2021 (UTC)
- Templates are forms. Would you ever use a form that requires you to enter your name in uppercase if it is more than 5 characters long and in lowercase otherwise? This is not just bad template design, it is lacking sense. The module should emit the error "do not use - illogical" (in red letters of course). Just in case people think that this just popped up, it hasn't. It has been pointed out for years. 64.61.73.84 (talk) 15:23, 14 March 2021 (UTC)
- Templates are also functions. If used, they add value (like more consistent formatting of citations in articles, central maintenance, error checking, machine readability and meta-data generation). These features directly or indirectly help to improve the quality of the content we provide, and also help a multitude of other projects).
- Regarding the error message, as you can see below, we are just in the process to add it.
- --Matthiaspaul (talk) 17:21, 14 March 2021 (UTC)
- Functionally, these are editor-, not administrator/programmer helper-templates. The various quirks & the nonsense do not age well. 98.0.246.242 (talk) 02:45, 15 March 2021 (UTC)
- Templates are forms. Would you ever use a form that requires you to enter your name in uppercase if it is more than 5 characters long and in lowercase otherwise? This is not just bad template design, it is lacking sense. The module should emit the error "do not use - illogical" (in red letters of course). Just in case people think that this just popped up, it hasn't. It has been pointed out for years. 64.61.73.84 (talk) 15:23, 14 March 2021 (UTC)
- With all respect, is it not simpler to not use CS1 templates? Then you format the citation the way you see fit. The rationale behind emphasizing the volume was to make people aware that this is a multi-part source, the search for which does not end with locating the title, one should dig deeper to find the appropriate part. Bold weight is used as emphasis to distinguish from the emphasis given to the title, which is in italic type. And obviously the template rendering of the volume parameter is confusing and contradictory, and the instructions are inadequate. I would use a freehand citation rather than trying to figure out the nonsensical. 98.0.246.242 (talk) 01:09, 13 March 2021 (UTC)
- That was very much an intentional work-around because I'm personally not happy with that formatting - I have seen it used for journals but not for books. RandomCanadian (talk / contribs) 20:39, 12 March 2021 (UTC)
- That happens because you wrote
- I don't know for cite journal but {{cite book}}, if you put anything besides a plain number in |volume=, it isn't bolded, ex. [1], so there's that. I mean, it shouldn't be much of a problem changing the journal template so it displays "vol. x"; but again it's really a minor issue of citation style and so long the source is uniquely identifiable we shouldn't be worrying too much about that. RandomCanadian (talk / contribs) 20:10, 12 March 2021 (UTC)
- The above caused me to wonder how often
|volume=vol. ...
is used in{{cite book}}
. This search says that there are 14.5k+ articles with malformed|volume=
parameters (search times out). Of those, some 1400ish are roman numerals (also times out). For comparison, there are about 72kish articles that use{{cite book}}
with|volume=
values that do not begin with 'V' or 'v' (and yes, times out). - If we are going to look at
|volume=
, we should also look at|issue=
even though{{cite book}}
doesn't support|issue=
: ~100 (timed out). - Switching to
{{cite journal}}
, same searches, just different template name gives inconclusive search results (all timed out) so making any judgement based on these is pretty much pointless: - What I think can be said is that like
|page=
and|pages=
, we should be trapping|volume=
and|issue=
when these have some form of extra text that looks something like the parameter's name. - —Trappist the monk (talk) 23:03, 12 March 2021 (UTC)
- And I have hacked Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox to implement this. A single function does both
|volume=
and|issue=
. The tests are case insensitive and look for various volume and issue designators:|volume=
value begins with:volume
vol
(with or without terminal dot)v.
(requires terminal dot because 'v' can be an allowed Roman numeral)
|issue=
value begins with:issue
iss
(with or without terminal dot)i.
(requires terminal dot because 'i' can be an allowed Roman numeral)no
(with or without terminal dot)
- Are there other patterns that we should look for?
- —Trappist the monk (talk) 23:45, 13 March 2021 (UTC)
- I added
number
nr
(with or without terminal separator)- Rarely, I have also seen a colon (:) used instead of a dot (.), therefore I have added : and = as separators detected.
- I think, we should move the patterns to /Configuration for easier localization.
- And I have hacked Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox to implement this. A single function does both
Wikitext | {{cite journal |number=I.3 |title=Title |volume=Vol:3 |journal=Journal}}
|
---|---|
Live | "Title". Journal. Vol:3 (I.3). |
Sandbox | "Title". Journal. Vol:3 (I.3). |volume= has extra text (help); |number= has extra text (help)
|
- --Matthiaspaul (talk) 15:29, 14 March 2021 (UTC)
- I tweaked the single-character patterns ('v', 'i', 'n') so that they catch <char><space>. Whitespace is trimmed from parameter values before delivery to the module so these tweaks catch
|volume=V 123
etc. - Keeping the patterns local to the function until we settle on what the code will be doing is better for now. Yeah, should be moved before the next sync.
- —Trappist the monk (talk) 16:31, 14 March 2021 (UTC)
- Added plural forms "volumes", "vols", "numbers", "nos", "issues" (plus variants). Rarely seen, but given that we support parameter ranges, they could occur.
- I tweaked the single-character patterns ('v', 'i', 'n') so that they catch <char><space>. Whitespace is trimmed from parameter values before delivery to the module so these tweaks catch
- --Matthiaspaul (talk) 15:29, 14 March 2021 (UTC)
Wikitext | {{cite journal |number=3, 5 |title=Title |volume=I–II |journal=Journal}}
|
---|---|
Live | "Title". Journal. I–II (3, 5). |
Sandbox | "Title". Journal. I–II (3, 5). |
Wikitext | {{cite journal |number=nos. 3, 5 |title=Title |volume=vols. I–II |journal=Journal}}
|
---|---|
Live | "Title". Journal. vols. I–II (nos. 3, 5). |
Sandbox | "Title". Journal. vols. I–II (nos. 3, 5). |volume= has extra text (help); |number= has extra text (help)
|
Wikitext | {{cite magazine |number=3, 5 |title=Title |volume=I–II |journal=Journal}}
|
---|---|
Live | "Title". Journal. Vol. I–II no. 3, 5. |
Sandbox | "Title". Journal. Vol. I–II no. 3, 5. |
Wikitext | {{cite magazine |number=nos. 3, 5 |title=Title |volume=vols. I–II |journal=Journal}}
|
---|---|
Live | "Title". Journal. Vol. vols. I–II no. nos. 3, 5. |
Sandbox | "Title". Journal. Vol. vols. I–II no. nos. 3, 5. |volume= has extra text (help); |number= has extra text (help)
|
- --Matthiaspaul (talk) 18:51, 30 March 2021 (UTC)
- If some form of the RFC below is to run, deferring action on these cases until afterwards might create less friction. It might happen, for example, that the RFC removes the issue that these forms were created to work around, in which case no-one will miss them. Kanguole 15:35, 14 March 2021 (UTC)
- Doesn't matter. cs1|2 is responsible for the annotation used when rendering
|volume=
and|issue=
. These tests catch inappropriate volume and issue annotations in the parameters' assigned values. Inappropriate extra annotations will always be inappropriate regardless of the outcome of an rfc (if there is an rfc). - —Trappist the monk (talk) 15:44, 14 March 2021 (UTC)
- I am hopeful that these messages will be hidden maintenance messages when they are initially deployed. Given the current discussion about hyphens at VPP, it would behoove us to avoid being tone-deaf to editors' concerns about error messages and changes to the CS1 templates based on limited discussions. – Jonesey95 (talk) 04:36, 15 March 2021 (UTC)
- Doesn't matter. cs1|2 is responsible for the annotation used when rendering
Draft RFC
- I have written up a a draft RFC over the past couple hours based on the previous planning done. Happy to see feedback on wording changes, bold tweaks, etc. --Izno (talk) 22:44, 12 March 2021 (UTC)
- It is well thought-out and nicely depicted. But in this form, you will be able to hear the collective editor head-scratching across the internet. Not to say that I know how to make it simpler. I would subjectively slant the argument in favor of easily recognizable consistency, and damn the experts. Render a page "page/p", issue "issue/no" and volume "volume/vol". Then sit back and enjoy less fruitless discussion. 98.0.246.242 (talk) 01:23, 13 March 2021 (UTC)
- I appreciate the effort, but, I think, in this form it is too complicated for an RFC, and, giving readers almost complete freedom of choice, it will be difficult to derive a clear picture from the answers.
- I think, what we actually seek is community input to get a better understanding on the community's general preferences, whereas, while adjusting the templates according to the outcome of the RFC, sorting out the corner cases and nitty-gritty details can be left to later local discussions. Hence, in order to keep things as simple as possible for them (so they get the general picture), we should not discuss in this RFC:
- Which parameters should be actually supported by which template
- Considerations in regard to publications which have both number and issue designations
- Minor style variations between singular and plural forms, lists and ranges
- If we should add commas between the values in "abbreviated" style or not
- If volumes should be presented in boldface in "scientific" or "symbolic" style or not, or leave it conditional on length and internal format
- (For most of these questions we don't actually need wide community input, except for, perhaps, the last one. Where necessary, these topics can be addressed in subsequent local discussions.)
- Thereby, the styles to choose from can be boiled down to four major variants, with #1 and #3 being the most important ones (where V is a placeholder for the volume, N a placeholder for the issue number, P a placeholder for the page info, and all other letters and symbols elements of the style itself):
- "Scientific": V (N): P. Example: 15 (11): 14–23.
- "Symbolic": V (N), pp. P. Example: 15 (11), pp. 14–23.
- "Abbreviated": Vol. V no. N. ... pp. P. Example: Vol. 15 no. 11. ... pp. 14–23.
- "Full": Volume V, number N. ... pages P. Example: Volume 15, number 11. ... pages 14–23.
- The two main questions that need be answered:
- Should all templates switch to use one of these styles for consistency or should the templates continue to use different styles depending on the publication type? If all should use the same style, which one of these four? When only a particular template should switch to a different style, the readers can mention this as well, but asking for the preferred style of each template individually would unnecessarily overcomplicate things.
- Should there be a way to override the default style used by a template (like through a
|periodical-style=scientific/symbolic/abbreviated/full
parameter - parameter name and keywords are only working handles, the actual names could be discussed locally later on). This would allow editors to enforce consistency of style within an article even if the templates would continue to have different default styles, or to switch to a different presentation style where desirable (f.e. to have some means to use "scientific" style in a heavily scientific article even if the templates would use "abbreviated" style by default.)
- --Matthiaspaul (talk) 13:14, 13 March 2021 (UTC)
- I share the concern that the proposed four questions are likely to start a wide-ranging discussion from which it will be difficult to extract concrete actions. It might be more fruitful to present a short menu of choices, and ask for people's preferences. Moreover, I think previous discussions have identified three clear options:
- status quo
- 1 (2): 34–56 for journals, and vol. 1, no. 2, pp. 34–56 for everything else (though issue/number tends to be a journal thing)
- vol. 1, no. 2, pp. 34–56 for everything
- Some people argued for fully spelling out "volume", "number" and "pages" – perhaps that could be a second question.
- I don't think it would be a good idea to offer more formatting option parameters. Kanguole 14:31, 13 March 2021 (UTC)
- Regarding an option to override the default format, I am generally a proponent of consistency but I also acknowledge that some people might have deviating needs in specific articles. The idea of such a parameter is to make it easier for them to vote for a standard default format in an RfC even if this is not their preferred format as they could still override the default where actually needed. Thereby the outcome of the RfC will have more chances to be accepted by the community as a whole. Achieve more consistency in general by default, and still keep everyone happy. Friendlier place, better project outcome. --Matthiaspaul (talk) 17:21, 14 March 2021 (UTC)
My comment on that RFC is that it's overwhelming and overloaded with information and options.
- The table should have only a single column with displaying all supported parameters (VIP for journals, VP for books, P for arxiv, I for podcasts, etc...).
- The RFC should be specifically about explicit (abbreviated Vol. 1 no. 2 p. 3) vs implicit (bolded and positional 1 (2): 3). Leave capitalization issues out, since that should just be made consistent with grammar rules (Vol. 1. No. 2. P. 3. with dotted separations or Vol. 1 no. 2 p. 3 / Vol. 1, no 2., p. 3 with no or comma separators, with Vol. being capitalized or not depending on it following a dot separator or not).
Headbomb {t · c · p · b} 15:26, 13 March 2021 (UTC)
Answering no-one in particular, but trying to cover the commentary:
- I am not in favor of custom switches. I will not propose it and I will attempt to make it clear in the RFC that that is not on the table. Adding customization in these templates deliberately works against any reason or rationale to have an RFC.
- I am interested in nitty-grittys. The community never gets to a consensus with some vague "Wikipedia should do this" which is +-'d by the community because the community always brings up the nitty-grittys separately in some unstructured way, rather than being invited to comment directly.
- I appreciate that there is a lot of leeway given in the questions. I do agree that some information (the bullets as listed by Matthias, perhaps besides the last bullet) is presented but is not part of the core question. I will attempt to make that clearer. (Ordering of the parameters in a specific citation is another one? I am not sure. Commas another -- I don't necessarily agree that volume - number needs a comma between, but it's a point of appearance that given we still can't get rid of CS2 [he displays his clear bias] is likely open to disagreement.)
- I deliberately have given the community leeway. If they want to go "boldface volume, with page indicator, as in cite book, for all templates, or all templates beside cite journal", that should be their choice. The community is going to get into such questions whether I want it or not just because of the sensitivity of citations.
- No, I do not think previous discussions have illustrated any particular preferred choices. I think we have some templates that look the way they do, and some previous discussions about how some templates should look, but none which have examined the set systematically. I do have faith in the community however, that the majority of the community will hew to the general look and feel of the templates today rather than propose crazy styles.
- I considered presenting the table in one column or similar. The problem is that not all templates will have all parameters filled and readers may be interested in how templates will look other. Cite journal is perhaps alone among the set that can be expected to be filled in for all 3 parameters on a regular basis, and even then I suspect it would not take long to find counterexamples.
- Overall density of information: I don't want to make people hunt for what it looks like today or what the templates do in the aggregate. I don't expect loud complaints if that information is missing, but I do expect complaints. Open to suggestions, specific reduction points (taking into account some 'don't talk about this stuff' to be added as indicated), or even someone else forking their own draft for comparison.
--Izno (talk) 03:27, 21 March 2021 (UTC)
"I don't see a reason for that"
Please be more specific than WP:IDONTLIKEIT, User:Izno. Thank you CapnZapp (talk) 18:44, 15 March 2021 (UTC)
- "I don't like it" and "I don't see value in your addition in this context/on this page" are not equivalent. --Izno (talk) 20:34, 15 March 2021 (UTC)
- No, Izno - you do not get to revert content without an explanation. I have started this talk section for you to explain what you mean by "I don't see a reason for that". And the fact you don't happen to see "value" in my addition is not sufficient. Am I supposed to read your mind? Or just try rewording over and over until I happen to find a version you deign to allow? CapnZapp (talk) 11:49, 16 March 2021 (UTC)
- This discussion appears to refer to Help:Citation Style 1#Using_|format=; particularly this addition and the subsequent revert. For me, I'm not convinced that the addition is required because it is not clear to me how regular editors benefit from the added text.
- —Trappist the monk (talk) 12:19, 16 March 2021 (UTC)
- If we assume that an editor will turn to a help page to quickly find concise, up-to-date, focused pointers, then the reverted note is dead weight. I am not discussing the merits of its content, just that, imo, it is out of place in a page that purports to be a practical guide. 98.0.246.242 (talk) 04:18, 17 March 2021 (UTC)
ISO dates
Can we add support for long ISO dates, e.g. 2021 March 16? — kwami (talk) 01:43, 17 March 2021 (UTC)
- Umm, that isn't an ISO 8601 date format. cs1|2 adheres as closely as it can to MOS:DATES; when MOS:DATES allows YYYY Month dd date format, cs1|2 will follow.
- —Trappist the monk (talk) 02:10, 17 March 2021 (UTC)
Help:Citation Style 1/test problems
Hello,
Something has caused this page to now have the red link category Category:CS1 errors: extra text: issue. I can't find a recent edit that would cause this category to appear. Can anyone help either fix this so the nonexistent category doesn't show up on error lists or create this category if it is now needed? Thank you. Liz Read! Talk! 05:06, 18 March 2021 (UTC)
- Thanks. This is probably a temporary issue caused by the (still incomplete) preparations to add extra text warnings to
|issue=
,|number=
and|volume=
according to this thread: Help_talk:Citation_Style_1#Obtuse_template_style - --Matthiaspaul (talk) 11:09, 18 March 2021 (UTC)
- Was even simplier: The example at Help:Citation Style 1/test problems contained
|issue=Issue
but was missing the|no-tracking=yes
parameter causing the categorization now that we added the "issue" extra text warning to the template. --Matthiaspaul (talk) 18:36, 19 March 2021 (UTC)
- Was even simplier: The example at Help:Citation Style 1/test problems contained
References listed by editor of the book, but Bibliography lists by author of the chapter
I'm citing a chapter with a specific author in a book that has another person as the editor, and I'm seeing that the Harvard citation cites the book by the editor's last name in the References section and by the chapter author's last name in the Bibliography. Is there a way to fix this, or has it not been a problem for anyone? Danaphile (talk) 23:48, 19 March 2021 (UTC)
- When creating a CITEREF anchor, cs1|2 always uses the author name(s) if available; if not, it falls back on the editor name(s). If you only need to cite one author's work from an edited collection, rewrite the cs1|2 template to include the author and the author's contribution. If you need to cite the contributions of multiple authors from an edited collection, omit author names from the cs1|2 citation and for each author contribution add
{{harvc}}
. In the article text then, the{{sfn}}
(or{{harv}}
) template has the author name and links to the appropriate{{harvc}}
template which, in turn, links to the cs1|2 template. - An example: here are a pair of
{{sfn}}
templates.[1][2]
References
- ^ Blue 2021, p. 13.
- ^ Greene 2021, p. 45.
- And a
{{cite book}}
template and two{{harvc}}
templates in §Bibliography:- Black, ed. (2021). All about Colors.
- Blue. "Why Blue is the best color". In Black (2021).
- Greene. "Green is better than Blue because it has Yellow". In Black (2021).
- Black, ed. (2021). All about Colors.
- —Trappist the monk (talk) 00:20, 20 March 2021 (UTC)
- Thanks for this pointer to {{harvc}}. This is extremely useful when citing encyclopedias, and I didn't know about this until now. {{sfnm}} is another that I came across only recently. Is there a list somewhere of the family of sfn/harv templates? -- Michael Bednarek (talk) 03:55, 21 March 2021 (UTC)
- Template:Sfn § Author–date citation templates is the only list that I know of.
- —Trappist the monk (talk) 11:28, 21 March 2021 (UTC)
- Thanks for this pointer to {{harvc}}. This is extremely useful when citing encyclopedias, and I didn't know about this until now. {{sfnm}} is another that I came across only recently. Is there a list somewhere of the family of sfn/harv templates? -- Michael Bednarek (talk) 03:55, 21 March 2021 (UTC)
Reference and Bibliography?
Is there a simple way to add e.g. {{cite journal}} just once either as an inline <ref>
or in the Bibliography section and invoke it by name in the other occurrence? It seems fragile to have to include it twice. Urhixidur (talk) 11:34, 23 March 2021 (UTC)
{{sfn}}
/{{sfnp}}
do that. You give the full citation, with the full page range of the article, in the bibliography and have short references with the specific pages at each use. Kanguole 11:41, 23 March 2021 (UTC)- See WP:REFNAME. – Jonesey95 (talk) 15:17, 23 March 2021 (UTC)
Report style
{{cite report}} should, like {{cite journal}} and others, quote the title instead of just spitting it out in Roman letters. Urhixidur (talk) 13:03, 23 March 2021 (UTC)
{{cite report}}
is the way it is because that was the way it was created all those many many years ago. For the discussion that occurred around the time that I migrated{{cite report}}
from{{citation/core}}
to Module:Citation/CS1, see Help talk:Citation Style 1/Archive 6 § Cite report.- —Trappist the monk (talk) 13:27, 23 March 2021 (UTC)
- We talk about cite report on occasion. Please take a look at the archives. Izno (talk) 14:28, 23 March 2021 (UTC)
Finding errors in Vancouver names
Based on an offwiki discussion about how difficult it is to find errors in Vancouver names listings, I have modified the sandboxes such that they report an nth name containing the error. It is a first cut and I welcome 'better' changes. Particularly, I am not sure of the best way to deal with vauthors versus veditors and vauthors versus name list (and the combination) - it may not be particularly important though. The interested coder may wish to modify the particulars being reported by the module.
Adding "in name X" may also be better before the colon rather than after. I have no strong opinion on that point but I'm kind of liking it after rather than before.
Interested readers can review Module talk:Citation/CS1/testcases/errors at test_vancouver and test_vauthors. Izno (talk) 02:42, 27 March 2021 (UTC)
DOIs greater than 10.49999
Hello! There now appear to be valid DOIs with prefixes of 10.50000 and above (cited, for instance, here) but these cause the templates to flag them for checking ("Check |doi= value (help).") Should the templates be amended not to flag the 10.50000–10.59999 range? Thanks! —Collint c 16:10, 28 March 2021 (UTC)
- Already been fixed in the sandbox.
- —Trappist the monk (talk) 16:18, 28 March 2021 (UTC)
- Since January. It should not take several months to roll out routine limit increases on identifiers. Headbomb {t · c · p · b} 16:25, 28 March 2021 (UTC)
- They still produce a link and the error message can be suppressed with
((...))
around the DOI per Help:Citation Style 1#Accept-this-as-written markup. A search [2] currently finds seven working DOI doing that: - An edit to Module:Citation/CS1/Identifiers forces 4.8 million pages to be rendered so it shouldn't be updated too frequently either. PrimeHunter (talk) 18:55, 28 March 2021 (UTC)
- We have a pretty big stack of changes ready to go in the sandbox. We should probably update the live modules, or at least post a list of the changes and discuss whether we want all of them to go live. Once every couple of months shouldn't put a heavy load on the servers. – Jonesey95 (talk) 02:27, 29 March 2021 (UTC)
- Right now updates are quarterly, usually early in months 1/4/7/10. Headbomb is just annoyed because he hasn't tried to get/gotten consensus to make it more often. Izno (talk) 04:33, 29 March 2021 (UTC)
- I am annoyed because this template is controlled by a small minority of people that can't be arsed to update the template when it needs to be updated. There is zero reason or consensus to have these updates happen once every 43 centuries. Show me the consensus for that. Headbomb {t · c · p · b} 19:03, 29 March 2021 (UTC)
- Thanks all, I appreciate the info and work! —Collint c 18:35, 29 March 2021 (UTC)
- Right now updates are quarterly, usually early in months 1/4/7/10. Headbomb is just annoyed because he hasn't tried to get/gotten consensus to make it more often. Izno (talk) 04:33, 29 March 2021 (UTC)
- We have a pretty big stack of changes ready to go in the sandbox. We should probably update the live modules, or at least post a list of the changes and discuss whether we want all of them to go live. Once every couple of months shouldn't put a heavy load on the servers. – Jonesey95 (talk) 02:27, 29 March 2021 (UTC)
- They still produce a link and the error message can be suppressed with
- Since January. It should not take several months to roll out routine limit increases on identifiers. Headbomb {t · c · p · b} 16:25, 28 March 2021 (UTC)
- In my humble opinion it does not make sense to set upper limits on ids for validation. How often will that actually help editors? And how often will it raise false alarms because the bound is outdated? And how much trouble is it to maintain, when edits to the module trigger huge rendering backlogs? Keep it simple, spare everyone's time and just remove those limits. − Pintoch (talk) 09:23, 31 March 2021 (UTC)
- I see good arguments pro and con those limits. One possible way to solve the problems would be to make the limits "self-servicable", that is, to create a special limits configuration file, which would allow to override the internally defined limits (only) in the upward direction. This file should not be protected, so that it can be edited by anyone (except for, perhaps, IPs), so that virtually any editor running into a limit could (guided by the help section linked to in the error message) edit the file and increase the limit. Occasionally, a vandal might try to sabotage the limits by setting too high or too low values, but for as long as the limits cannot be set to lower values than those defined internally (if so, they would just be ignored by the module), and for as long as reading a possibly syntax-trashed limits file does not provoke any Lua errors, no actual harm could be done, except for that the limits would be effectively disabled temporarily. Whenever the module suite gets updated, the internal limits would be updated to reflect the limits defined in the limits file (plus some margin). The overhead to implement such a scheme should be small, but it would reduce necessary maintenance to a minimum and eliminate the need for those frequent "please update the limit" threads. Best of both worlds?
- --Matthiaspaul (talk) 13:28, 31 March 2021 (UTC)
- @Matthiaspaul: I do not think that changing the permissions needed to edit those limits would solve the problem that re-rendering all the pages that rely on it is costly. − Pintoch (talk) 14:38, 31 March 2021 (UTC)
- That's true if it would happen very frequently (say, every couple of days). But we have been indicated by site admins in the past that occasional updates (say, once a week or every couple of weeks) are not actually a problem.
- However, updating the whole module suite at that fast pace would make it more difficult to find and fix errors before changes go live and it would also be too much maintenance overhead, not only for the update itself but also for the gnomish actions that typically happen in preparation for an update and immediately afterwards. Documentation needs to be kept in sync as well. So, I think, it's good that we have longer semi-static times between the updates for things to settle - if, in the live system, everything would be in flow all the time, it would be more difficult to spot issues.
- Personally, I think, the updates of the module suite should not happen more often than every two months, but I am also happy with the current three-month scheme. Maintaining some semi-fixed schedule helps to give structure to the project. However, bug fixes for frequently occuring non-trivial issues should be rolled out whenever they become available in order to not annoy a lot of readers longer than necessary. And limit updates could happen much more often as well, because we have meanwhile an infrastructure (with help pages updating automatically) making it very easy to implement them, and by just changing a number there is (almost) no risk to introduce new bugs. Most readers won't have recognized this because it mostly happened silently, but starting this year Trappist actually moved some bug fixes and limit updates to the live system shortly after they became available in the sandbox. So, some of the changes implemented after the last module suite update are in fact already live. I think, this is a good solution, but given the frequently necessary limit updates this could become tiresome over time.
- Therefore, I think, something along the line of my proposal could be actually a solution.
- --Matthiaspaul (talk) 16:59, 31 March 2021 (UTC)
- @Matthiaspaul: I do not think that changing the permissions needed to edit those limits would solve the problem that re-rendering all the pages that rely on it is costly. − Pintoch (talk) 14:38, 31 March 2021 (UTC)
Automating URL access tags
A few of us on WP:Discord have been chatting about the potential for automating the URL access parameter on this citation. Floydian suggested building a Lua dataset that has a bunch of URLs for frequently-used online sources, and then having {{Citation}} automatically assign the URL access tag associated with that website if a manual one is not provided. This wouldn't work for all sources, as some surely have multiple access levels or other confounding factors, but even if we can only use it for a subset of sources, it'd help get these parameters used a lot more widely and kept up to date better as paywalls are raised/lowered, and we could make the system more advanced over time. What do you all think? {{u|Sdkb}} talk 02:18, 31 March 2021 (UTC)
- Adding on a bit, the datasets would essentially be URL lists, similar to the whitelists and blacklists we use, that would assign those base URLs as, say: subscription, registration, free, sites that are two or more of those, and possibly another category for sites known to be free in certain locations. - Floydian τ ¢ 02:21, 31 March 2021 (UTC)
- I assume you have in mind external code that is called by the module when these parameters are set, so that the relevant processing is offloaded. An editor override should be an option. In general, because humans should should have control over all processes, and in particular because access status may restate faster than database updates. 64.61.73.84 (talk) 03:15, 31 March 2021 (UTC)
- I appreciate the intention but we should think twice about adding hard-coded lists like this - it will be significant work to maintain. I am concerned by the rising complexity of this module and the sustainability of its maintenance. Would you consider adding support for this in a bot instead? We already do quite a lot of tagging with User:OAbot, this sort of tagging would easily be in scope for it. Also I suspect not that many domains can be considered as mostly paywalled, with the generalization of hybrid open access among scholarly publishers, so it's not clear to me it would be that useful in practice. Perhaps you have specific domains in mind? − Pintoch (talk) 09:30, 31 March 2021 (UTC)
- Pintoch, I don't have a strong opinion about whether we should do automation via a bot or something else, just that if we want the tags to appear widely outside of GAs/FAs, there should be some sort of automation. Maintaining a database of URLs with their statuses is a lot less work than maintaining references individually, since each website is likely used hundreds or thousands of times. I don't have specific domains in mind, although I think big newspapers might be a good place to start. {{u|Sdkb}} talk 10:00, 31 March 2021 (UTC)
- @Sdkb: then I would warmly invite you to carry out this project via WP:OABOT. If you want to curate the list of paywalled sources I am sure we can find someone to add the relevant Python code there to make it work. It should be a lot easier to get this through BRFA than to implement this in the citation modules. − Pintoch (talk) 14:41, 31 March 2021 (UTC)
- Pintoch, I don't have a strong opinion about whether we should do automation via a bot or something else, just that if we want the tags to appear widely outside of GAs/FAs, there should be some sort of automation. Maintaining a database of URLs with their statuses is a lot less work than maintaining references individually, since each website is likely used hundreds or thousands of times. I don't have specific domains in mind, although I think big newspapers might be a good place to start. {{u|Sdkb}} talk 10:00, 31 March 2021 (UTC)
- My gut reaction to this proposal is that it will be just one more thing over which editors will squabble. What to do when the base url can be free and can be subscription? Who is to be tasked with designing and maintaining this database? If the goal of this proposal is to
help get these parameters used a lot more widely
, how does automatic application of the access icon further that goal? Module:Citation/CS1 cannot rewrite article wikitext so editors looking at wikitext will never see|url-access=
except when it has been added to the citation template by a human or by a bot. - —Trappist the monk (talk) 10:59, 31 March 2021 (UTC)
edtf date formats as cs1|2 date parameter values (2)
The original discussion is at Help talk:Citation Style 1/Archive 33#edtf date formats as cs1|2 date parameter values and at the same phabricator task: T132308. The EDTF standard is here.
In that phabricator task you can see that citoid will soon be returning month and year dates in the EDTF format: YYYY-MM-XX
where the XX
are literal characters that act as placeholders for unspecified days. Citoid is currently returning these dates in the YYYY-MM
format which is incompatible with MOS:DATE.
Because of T132308, I have resurrected the 2017 code that I wrote for the EDTF format, tweaked a bit to accommodate intervening changes in Module:Citation/CS1/Date validation.
Citoid will give us cs1|2 templates with dates that look like this when the source gives month and year dates:
{{cite book/new |title=Title |date=2021-03-XX}}
- Title. March 2021.
—Trappist the monk (talk) 23:56, 31 March 2021 (UTC)