This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 65 | ← | Archive 69 | Archive 70 | Archive 71 | Archive 72 | Archive 73 | → | Archive 75 |
|badauthor=
" parameter alias in the
linked thread. In fact, I was thinking about something similar myself some while ago:The prefix would have to be worded more neutrally like |debug-*=
, |check-*=
, |recheck-*=
, |TEMP-*=
, |-*
("minus"), |~*
("uncertain"), |?*
("question mark") or similar, and the prefix should be applicable to all template parameters in general, like |recheck-editor-last3=Radcliffe
, |-issn=0367-9950
or |?publication-date=29 February 1866
.
If an editor runs into a parameter value that appears to be incorrect and that should be double-checked, but cannot be verified immediately, the editor would just add the prefix to mark it for future review. Once this or another editor has checked a parameter flagged this way, s/he would correct the value if necessary and/or simply remove the prefix again.
The template could populate a special maintenance category for this, but otherwise these aliases would be treated exactly as their canonical forms, including error checking. This way, this feature could be coded as a general exception to the normal parameter evaluation and therefore without overhead and it could be documented in a single place like our (( accept-this-as-it-is)) syntax, without having to list it as an alias everywhere.
An alternative to this are HTML comments, but they are not machine-readable and wouldn't cause the citation to show up in a maintenance category.
The system could be extended to bot edits as well in two ways:
Bots running into entries they find fishy but cannot resolve reliably (that is, with 100% accuracy) could instead mark the parameter with the prefix and leave it to humans to actually check and possibly correct it, instead of applying guesswork themselves. This would extend the model of a bot/tool assisting a specific user synchronously to assisting all possible editors, and asynchronously, without causing harm in case of problems.
Also, bots and similar tools could be asked to flag all entries where they changed values with |-
, and prefix all parameters where they added information with |~
(or at least those where potentially inaccurate info was added - this should never happen in the first place, but we all know that in reality it happens quite often at least with some bots/tools). Parameters prefixed with |~
would be ignored by the citation template, except for, perhaps, populating a maintenance category, and, possibly, show up in preview already (but framed somehow). Editors working on the article and improving citations would simply have to remove the prefixes after reviewing them.
Thereby, it would be much easier for humans to identify bot edits for review (also long after the fact when it might no longer be listed among the recent edits in the edit history) and to double-check some additions before they go live. It would take some time for this new process to trickle through, but since it's technically optional the transition would be smooth and the situation would gradually improve with each new bot/tool adopting it.
IMO, this could solve many problems with Citation Bot and similar overambitious tools by allowing them to make suggestions instead of actually carrying out the edits and often messing up citations. Even if the concept would not be adopted community-wide, it could still be used by those who decide to use it.
For readers, the |-
idea would have no visible impact at all, whereas |~
prefixed information would only become visible with some delay. But for anyone looking at the source code (or preview), the scheme would be completely transparent.
I see this as kind of an informal but formalized and thus machine-readable light-weight communication and process model which can be voluntarily adopted by anyone to ease the normal communication and ad-hoc citation improvement process among human editors and bots (instead of leaving HTML comments, having to discuss temporary details on talk pages, or fighting against each other).
-- Matthiaspaul ( talk) 14:39, 3 September 2020 (UTC)
Further extending the notation of using |-
(or |?
or |~
) prefixes, it would also be possible to mark parameter values, which have been verified by humans already, with a |+
(or even a |!
) prefix. At the same time this could be used as a flag to tell bots to leave a particular parameter alone, like |+author-last=Gray
. This would hardly be necessary for all given parameters in a template, but could be convenient to have if a known correct value will likely (or has already) trigger(ed) false alarms (like a name including what appears to be a typo but isn't). In contrast to a HTML comment, it would be shorter and machine-readable. As a template-wide "global" feature applicable to all parameters this could be coded with minimal overhead.
If the |-
prefix would be used for to-be-checked parameter values, |~
could be conveniently used for bot-added values, or vice versa.
-- Matthiaspaul ( talk) 20:49, 3 September 2020 (UTC)
|-
, |+
and |~
could be utilized to solve this dilemma as well:|-
would indicate "this parameter value needs to be reviewed" to other editors, so, if, by the same principle, an editor would prefix an empty parameter with |-
this would mean "Hey, I'm deliberately adding this empty parameter here because this missing information should be part of this citation, therefore please review and possibly add the info if you can". Example: |-author=
. Once an editor adds the missing info, he would remove the parameter prefix again. Example: |author=John Doe
.|-author=John Doe
, thereby telling other editors "Hey, this name looks fishy to me and might be a placeholder rather than the correct name, but I can't prove it right now. Please review if you can". Later, another editor would stop by and scrutinize the citation, and if s/he finds that the value is correct as it is, s/he would either remove the prefix again or, if it is likely that the value will stir up questions again, indicate that the value has been verified to be correct |+author=John Doe
, thereby telling other editors "Yeah, this doesn't look right, but I verified it and this particular author is actually named John Doe. Everything is fine". Something along this line...|-
in order to avoid their removal.I think that all cs1|2 error categories should have consistent naming as we have done for maintenance cats. We have standardized on CS1 errors: <descriptor> as a naming convention. This is a list of existing non-standard error categories, their page counts, and proposed replacements:
additions:
I don't think that it matters how many articles are listed in a category; if this change is accepted, old cats will depopulate as articles wend their way through the job queue until empty and new cats will populate in the same manner.
Any reasons we shouldn't do this? Better cat descriptors?
—
Trappist the monk (
talk) 13:33, 12 September 2020 (UTC) 00:49, 14 September 2020 (UTC) (addition) 14:16, 14 September 2020 (UTC) (better name)
|archiveurl=
and |accessdate=
to their hyphenated variants in the category names. Therefore, full support.|url-status=unfit
.
Category:CS1 maint: unfit url also holds articles that have cs1|2 templates that use |url-status=usurped
. cs1|2 does not distinguish one from the other as humans do.|url-status=unknown
; there is not. The BOT:
part of that category name is to suggest that bots using, |url-status=bot: unknown
, are responsible for adding articles to the category. The primary (only?) bot using this is InternetArchiveBot.{{یادکرد وب|نام خانوادگی= Omidsalar|نام= Mahmoud|پیوند نویسنده= محمود امیدسالار|عنوان= GENIE|نشانی= http://www.iranicaonline.org/articles/genie-|بازبینی= ۱۵ آوریل ۲۰۱۲|اثر= |تاریخ= ۱۵ دسامبر ۲۰۰۰|ناشر= [[دانشنامه ایرانیکا]]|نشانی بایگانی= https://web.archive.org/web/20110429185114/http://www.iranicaonline.org/articles/genie-|تاریخ بایگانی= ۲۹ آوریل ۲۰۱۱|کد زبان= en|dead-url= no}}
{{
cite web}}
: Check date values in: |access-date=
, |date=
, and |archive-date=
(
help); Unknown parameter |dead-url=
ignored (|url-status=
suggested) (
help)url
), but to the abbreviation URL (Uniform Resource Locator), hence should be uppercased:|url-status=
should be hyphenated. If this is not related to the parameter but to URLs, the abbreviation should be uppercased. (On a different note: Why did we name the value "bot: unknown" rather than just "unknown"?){{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2020-09-13}}
→
Title. Archived from
the original on 2020-09-13.bot: unknown
starts at
User talk:Cyberpower678/Archive 36#alternate |dead-url= keyword.{{
cite mailinglist}}
.|url-status=bot: unknown
. Makes a lot of sense to have the keywords based on semantics/purposes (my saying as well). Still, it always kind-of-strikes me as odd when I see this bot:
in citations (probably, because this is a one-off syntactical concept rather than something used in other parameters as well). If we had to introduce this today I would probably suggest a hyphen-affixed bot-
prefix (like in |url-status=bot-unknown
) or would try to embed this into the more general
parameter review scheme proposal (similar to |~url-status=unknown
). Although, in the current version of that proposal, this would not change the linking behaviour and just put the citation into some special category, so that, for the link to be suppressed (as with bot: unknown
), that proposal would have to be adjusted/extended somewhat. Something to think about...Question, isn't "Category:CS1 errors: bare URL" the same error as "Category:CS1 errors: missing title"? Those don't seem to be independent. AFAICT, the first is missing titles when there's a URL, the second is missing titles regardless of if there is a URL. Headbomb { t · c · p · b} 16:02, 13 September 2020 (UTC)
|chapter-url=
without |chapter=
:
{{cite book |title=Title |chapter-url=//example.com}}
→
//example.com. Title. {{
cite book}}
: |chapter-url=
missing title (
help)|title=
, |trans-title=
, and |script-title=
(no main-title parameter):
{{
cite podcast}}
.Recently, Matthias has added support in the suggestions list to parameters that have been removed, listing a few related discussions but none which directly cite a decision to support parameters that are removed. Is this something we want to do? I am not generally in support of it -- we've removed the parameters from support, so why are we continuing to support them? -- Izno ( talk) 18:22, 16 September 2020 (UTC)
{{
cite web}}
: Unknown parameter |werk=
ignored (|work=
suggested) (
help). Or perhaps I misunderstand what is at issue. –
Jonesey95 (
talk) 19:42, 16 September 2020 (UTC)
|trans_title=
).|laysummary=
recently). In some sense, these can be considered "misspellings", but I would also classify them as "former parameters". I think it is important to document their type in the comments (this might be helpful when the current list might need to be turned into a more complex table with various flags in the future). In the case of old parameters, it might even make sense to record the date of deprecation, so this can be reevaluated a couple of years later.|transcript=
, |transcript-format=
, |transcripturl=
, and |transcript-url=
are unique to {{
cite av media}}
and {{
cite episode}}
I have moved them to the unique_arguments{}
table in the whitelist sandbox.
— Trappist the monk ( talk) 19:02, 11 September 2020 (UTC)
{{
cite podcast}}
but that apparently fizzled for who-knows-why.Pyramus in Shakespeare's A Midsummer Night's Dream Act 5, Scene 1
Yesterday I thought to create a common function to handle accept-as-written markup. There are several places in
Module:Citation/CS1/sandbox that detect and strip that markup so starting at the top of the module and working down, I replaced each independent detect-and-strip with a call to the new function, testing as I went. Worked great until I got to citation0()
and bam! ran straight into a wall at full speed.
Lua has a built-in, unalterable limit of 60 upvalues. Roughly speaking, an upvalue is anything in a module that has the same scope as the function in question and is directly used by the function. In ~/sandbox, there are some 61 functions that may be used by citation0()
(not all of them are directly used). Additionally there are 24 functions held in various other modules (most of them used by citation0()
) that count against the upvalue limit.
We have been close to this limit for some time. Since the last update, ~/sandbox has gotten two new functions, list_make()
and is_generic_title()
, and one new table auto_link_urls{}
and dropped the function is_embargoed()
. At the time that I hit the wall, we were sitting right at an upvalue count of 60.
So, what to do? For the nonce, I have taken the cheap and easy way out. The 24 functions held in various other modules were declared as local names to make life a bit easier so, for example,
Module:Citation/CS1/Utilities/sandbox has a very commonly used function is_set()
. To make that easier to type, the cross-module name utilities.is_set
was mapped to a local name is_set
. I have changed all of the remapped names to their cross-module names. Doing that reduced the upvalue count by 20 (I believe – not tested). There were 24 functions from four modules so should be 20.
citation0()
is an enormous beast. It can be reorganized and split into multiple sections which is something that I have wanted to do for a long long time. But it isn't an easy task so I have been putting it off and putting it off ... 'O wicked wall...'
— Trappist the monk ( talk) 15:18, 13 September 2020 (UTC)
"Access dates are not required for links to published research papers, published books, or news articles with publication dates."
With regard to the last of those, bear in mind that news articles are often revised some time after publication, and the date of revision (along with the reason/s for doing so) will be noted in the text. Additionally, my own experience suggests that even though the content of an article may not be revised, revisiting an article some years after publication can result in the discovery of a very different headline from the one noted in the citation, filled out earlier in the article's existence. Harfarhs ( talk) 22:30, 18 September 2020 (UTC)
|date=
for the date of the last update, which I do not.
Glades12 (
talk) 05:10, 19 September 2020 (UTC)
|date=
parameter is that of the latest date (of revision) that is known.|access-date=
is quite important.|access-date=
is never required, but optional. (In my opinion it is always desirable to have per
WP:V, whereas some editors see it as clutter.) Basically, it is up to the editorial judgement of the editor adding a citation if s/he thinks it is useful in a citation or not. Therefore, let's delete that misleading sentence completely. It has no place in a template's documentation.What should you do when the appropriate value for |place=
(i.e. the place where a source was written (or otherwise created)) is known, but not |publication-place=
? An example is the video
Hirokazu Tanaka on Nintendo Game Music, Reggae and Tetris (used at
Hirokazu Tanaka), which was recorded in Tokyo, but could have been published at just about any place with a Red Bull office.
Glades12 (
talk) 05:33, 19 September 2020 (UTC)
|place=
like everyone else? The distinction, for all intents and purposes, is nil at this point. (That aside, citing the location matters less and less entirely these days for anything of relevant sort from what I have observed.) (Also, Ttm, weren't we going to look at place/pub-place?) --
Izno (
talk) 06:15, 19 September 2020 (UTC)
|publication-place=
and |location=
/|place=
are used at the same time. Then |location=
/|place=
becomes a parameter only for the written-at-place.|place=
and |location=
are unfortunate because of their ambiguity. Therefore we should introduce a new dedicated parameter for the written-at-place, like |written-place=
. However, given that |place=
/|location=
can also be used to specify the publication place for as long as |publication-place=
is not present, and some editors have a very bad habit of changing |publication-place=
to |place=
, existing entries of |place=
/|location=
cannot be automatically converted into |written-place=
(nor |publication-place=
), but will, once the new parameter has been introduced, have to be reviewed individually.See also XKCD standards strip.This one?
HI all
Is the template currently broken?
I have used it for a time code in a film, but it seems to be just priting the parameters onto the article text for the viewing public:
(Last paragraph)
There are quotation marks around the last iteration of "Kevin Reynolds", but these are not selected when copy/pasting I am going to have to remove access date, as it is asking me for a url for the access date ... of course it came from my brain, as i know what date it is today lol
and now going to hide the whole mess ...
Chaosdruid ( talk) 17:47, 19 September 2020 (UTC)
<ref>...</ref>
tags?Our recent discussion
Help_talk:Citation_Style_1#Guidance_about_indexing_by_first_name? made me think (again) about the best choice for the canonical parameter names of the various name-related parameters. We currently support the variant pairs |first=
/|last=
and |given=
/|surname=
for all our name parameter sets |author=
, |editor=
, |contributor=
, |translator=
and |interviewer=
.
While the first pair (our default) does not create problems for (most) Western names, it actually is ambiguous. Even our citation templates render the names in the order "last, first", something we accept without much thinking because we are so used to it. However, for names not following the Western name order, it is not obvious which part of the name belongs into which parameter, as what is displayed first and last may depend on context.
An alternative concept that works across almost all (Western and Eastern) cultures is to distinguish not the first and the last name, but the given and the family name (which we, somewhat oddly, call surname in our parameter interface, although that would better pair with forename, but anyway).
Since proper semantics are more important for input data than "proper" display order (which can be changed through other means if necessary), I think, we should switch to use |given=
/|surname=
as our canonical defaults. |first=
/|last=
would be supported as before, just not be the defaults any more.
The only difference would be that |given=
/|surname=
would be listed first in the list of alias names, and |first=
/|last=
a bit later.
The advantage of this minimal change would be that the risk of mixing up the given and family name of names in
Eastern name order would be significantly reduced (if not eliminated, except for when they aren't known in the first place) in all new citations entered. Some bots (and probably also VE) would automatically start to use |given=
/|surname=
rather than |first=
/|last=
when adding new names to a template.
-- Matthiaspaul ( talk) 01:52, 20 September 2020 (UTC)
There has been an internal reorganisation of the horse profiles database at Racing Post (formerly at bloodstock.racingpost.com), so a number of citations (probably a couple of thousand, almost all using {{ cite web}}) will have to change to match. Fortunately the mapping from the old to the new URLs is straightforward. As I see it, there are three possible approaches:
|id=
parameter, in the same way as templates such as {{
ProQuest}}All of these options involve about the same amount of work, and all could be done by bot or by AWB. My own feeling is that option 1 would be to miss an opportunity to futurepoof these citations, so the only real choice is between options 2 and 3. Because the citations currently use {{
cite web}}, option 2 leads to error messages complaining about the lack of a URL. This can be fixed by changing to another citation template such at {{
cite journal}}. but is obviously undesirable as the Racing Post database is not a journal. Option 3 seems the best to me, but I'd appreciate input from citation specialists here. (And as a supplementary question: the current citations mostly include parameters |date=
and |access-date=
- I don't think these are either necessary or beneficial when citing this sort of database and I'm inclined to just discard them - any thoughts?)
Colonies Chris (
talk) 10:58, 20 September 2020 (UTC)
{{
cite web}}
parameters they want to the basic template. {{
cite Grove}}
is one example of a wrapper template.|date=
is concerned, this is a bit tricky when it comes to databases. Citing a record (a particular horse profile) is pointing to an in-source location, the source being the database. One should date the database edition/version normally. However, individual records may be revised or updated more often than the database itself and this should be cited too. I would utilize {{
citation}}. I would use (clumsily) |date=
for the record revision date. I would use |edition=
for the database revision/version (this may also be a date). Access dates are not needed in such rendition. This is not perfect but should work, assuming the database is indexed by record-subject+record-revision.
172.254.241.58 (
talk) 13:12, 20 September 2020 (UTC)
|access-date=
is apt, as the proper entry for date would be |date=n.d.
. This would be awkward in the specific-source template you have in mind, you may want to leave |date=
out altogether. The other option involves wading into the source code to figure out the revision date, which is convoluted. And {{
cite web}} is now as good or better than {{
citation}} as the base template imo.
64.18.9.222 (
talk) 03:53, 21 September 2020 (UTC)British motoring magazine What Car? makes for rather silly looking punctuation. How can I best avoid the period after the "magazine" field in template:cite magazine? It currently ends up looking like this: [1] Reference
Thank you, Mr.choppers | ✎ 18:24, 20 September 2020 (UTC)
Following up on the recent thread Help_talk:Citation_Style_1/Archive_69#subject-link=_and_subject-mask=, I have gone through the list of supported name parameters.
In the parameter sets for |author=
, |contributor=
, |editor=
, |interviewer=
, |subject=
and |translator=
we generally support |-first=
, |-last=
, |-given=
, |-surname=
, |-link=
and |-mask=
variants and their enumerated forms. (Some combinations also exist in non-hyphenated variants for legacy support, see below.)
I noticed the following irregularities:
|interviewerlink=
and |interviewermask=
were unsupported and unused but were still listed as supported in the Whitelist.|author-/interviewer-/-given/-surname=
as well as their numbered variants were missing from the set.|display-subjects=
as an alias for |display-authors=
was missing from the set.I have therefore removed support for the first two parameters and added the missing variants, so that we now have a fully symmetrical list of name parameters, making it easier to document and use them without having to look up which exact variants are supported by which group. |subject=
is special as it (apparently deliberately?) does not support any of the |-first=
, |-last=
, |-given=
and |-surname=
variants. In addition to this, |author=
and |editor=
also support several non-hyphenated forms for legacy support, but it is good to know that at least |contributor=
, |interviewer=
, |subject=
and |translator=
are free of them now.
For the records, these non-hyphenated aliases are used only a few times and could be cleaned up and deprecated as well:
insource:/| *editor[0-9]*mask[0-9]* *=/
:
[2] (~96 -> 0)insource:/| *displayeditors *=/
:
[3] (137 -> 0)-- Matthiaspaul ( talk) 21:54, 10 September 2020 (UTC)
|nocat=
parameter (a parameter name unfortunately also used by various other templates in huge numbers, whereas the usage number in citation templates is probably very small)? I came up with insource:nocat insource:/\{\{ *[cC]it[ea][^|]*\|[^n]*nocat *=[^}]*}}/
[4] but this could still be fooled. --
Matthiaspaul (
talk) 21:00, 11 September 2020 (UTC)
name="mlvguh">{{cite Earth Impact DB |name= Wetumpka |accessdate =August 20, 2009 |no-tracking=1}}</ref>
. Upper bounds is probably in the realm of
1300. --
Izno (
talk) 01:08, 12 September 2020 (UTC)editor
-related parameters, only |editorlink=
(and enumerated variants) has a large number of hits at all, so we can deprecate the others:
name
-related parameters, only the group of author
-related parameters are using non-hyphenated parameter variants in really huge numbers any more (which, at least, is easy to remember) — too much to fix them up any time soon without bot assistance.author
-related parameters, only some of them are used:
|editor[0-9]link[0-9]=
, |author[0-9]mask[0-9]=
, and |displayauthors=
parameter aliases are already low enough to set these parameters to "deprecated" while continuing to fully support them (despite the deprecation maintenance message) for another year or however long it takes to reduce their numbers, so that editors will gradually switch them to their hyphenated forms when they edit the corresponding articles.|author[0-9]link[0-9]=
(non-hyphenated) as well, or would we first have to reduce the much higher usage numbers considerably?I am still seeing errors from {{
cite journal}} with |title=none
+ |doi-access=free
. I thought this was supposed to be fixed? An example (a book review headed by the name of the book it reviews without having its own separate title):
{{
cite journal}}
: CS1 maint: untitled periodical (
link)This one, if cited by itself, would not be too ridiculous to make up a fake title like "Magical Mathematics" (the title of the book it reviews). But when it is part of a bulleted list of 15 reviews, all of the same book, all given the same fake title, it just looks ridiculous. And if instead of making up something fake but plausible you copy what appears at the top of each review and pretend it's a title, you get monstrosities like (from a different review of the same book) "Featured Review: Magical Mathematics: The Mathematical Ideas That Animate Great Magic Tricks. By Persi Diaconis and Ron Graham. Princeton University Press, Princeton, NJ, 2012. $29.95. xiv+244pp, hardcover. ISBN 978-0-691-15164-9." So I prefer to omit them, which per WP:CITEVAR should be a perfectly acceptable citation style that the templates support. Adding a little lock icon to the doi shouldn't change anything about that.
To put it more bluntly, the autolinking RFC did not address citations with no title, and did not have consensus for imposing a new requirement that all journal citations list a title. Therefore, it should not have been implemented in a way that implicitly imposed such a requirement. — David Eppstein ( talk) 21:45, 20 September 2020 (UTC)
{{
cite journal}}
: CS1 maint: untitled periodical (
link)|authormask=
.) --
Izno (
talk) 02:22, 21 September 2020 (UTC)
{{
cite journal}}
: CS1 maint: untitled periodical (
link){{
cite journal}}
: CS1 maint: untitled periodical (
link)Hi, the CS1 templates support a debug feature to disable categorization. This is currently supported by five parameter aliases, which is overkill for such a rarely used feature:
|template-doc-demo=
[19] 0|no-cat=
[20] 0 (2 uses in non-citation templates)|nocat=
>=2
Paleocene
Alabama (>15k uses in non-citation templates)|no-tracking=
[21] 0|notracking=
[22] 0In our cleanup effort, I think, we should, in a first step, deprecate the unused parameter names |template-doc-demo=
, |no-tracking=
and |notracking=
, making |no-cat=
the canonical name and |nocat=
its alias, and - despite the name - put them in (only) a special hidden category to find out how many citation templates actually use this feature. I think, the number will be very low (perhaps a handful, at most a few dozens), but given the fact that the template uses the "generic" parameter name |nocat=
and that Cirrus search for this times out, we cannot find out easily.
Once knowing the citation templates using this feature and evaluating the reasons for its use, we might, in a second step, switch the parameter name to something unique (and thus easily searchable) but still more sensibly named than |template-doc-demo=
, perhaps |cite-no-cat=
(so that it can still be found if someone searches for a "no-cat" parameter), but ideally even something that fits into our naming scheme better: Perhaps it can be merged into |(cite-)mode=
or integrated into a new, more general debug parameter like |debug-mode=
, also controlling namespaces. This would be something to discuss in the next round.
If we support the (( accept-this-as-it-is)) syntax for more parameters (per Help_talk:Citation_Style_1#i18n_doi_inactive_categories, Help_talk:Citation_Style_1#Replacing_ignore-isbn-error=_and_doi-broken=_by_isbn/doi=((invalid-value))_syntax), we might even be able to eliminate some of the reasons for the feature's (ab)use in mainspace, thus reducing this again to a pure debug parameter.
-- Matthiaspaul ( talk) 08:56, 13 September 2020 (UTC)
|no-tracking=
to avoid being put into an "invalid DOI" error category (the DOI is oddly formed with a pending dot, but valid):
{{cite journal/new |last1=Belcher |first1=C. M. |title=Reigniting the Cretaceous-Palaeogene firestorm debate |journal=Geology |year=2009 |volume=37 |issue=12 |pages=1147–1148 |doi=10.1130/focus122009.1. |no-tracking=yes}}
→ Belcher, C. M. (2009). "Reigniting the Cretaceous-Palaeogene firestorm debate". Geology. 37 (12): 1147–1148.
doi:
10.1130/focus122009.1. {{
cite journal}}
: Check |doi=
value (
help)|doi=
parameter meanwhile supports our ((syntax)) to disable our validation check, this can be achieved without abusing |no-tracking=
now:
{{cite journal/new |last1=Belcher |first1=C. M. |title=Reigniting the Cretaceous-Palaeogene firestorm debate |journal=Geology |year=2009 |volume=37 |issue=12 |pages=1147–1148 |doi=((10.1130/focus122009.1.))}}
→ Belcher, C. M. (2009). "Reigniting the Cretaceous-Palaeogene firestorm debate". Geology. 37 (12): 1147–1148.
doi:
10.1130/focus122009.1.{{
cite journal}}
: CS1 maint: ignored DOI errors (
link)|notracking=
and |no-cat=
have been brought down to zero (switching them to |no-tracking=
for now, the most sensibly named one of the remaining aliases. Support for these parameter variants was disabled, and |no-tracking=
is now the canonical form.|nocat=
nightmare, we need a temporary tracking category. I would appreciate if Trappist could take care of this, as the code for this is a bit tricky and he is already familiar with it. I think it is important to have this in the forthcoming template update, so that we don't lose too much time until the next round.|no-tracking=
, at least the name is unique, but otherwise it's far from perfect. The jury is still open to find a parameter name better fitting into our parameter naming scheme...|nocat=
only? So:
{{cite book/new |title=Title |no-tracking=true}}
→ Title.{{cite book/new |title=Title |no-tracking=true}}
→ Title.|template-doc-demo=
has been eliminated as well now.|template doc demo=
parameter. They have been updated to accept |no-tracking=
as well now, but the following 80 occurences should be fixed up as well: insource:/\| *template +doc +demo *=/
[23].|nocat=
is {{
Citation error}}.|template-doc-demo=
and its aliases should be cleaned up and replaced by something with a more sensible name and possibly modified functionality. |template-doc-demo=
is about the most nightmarish parameter name I can think of. Although |no-tracking=
does not fit well into our parameter naming scheme either, it is a much more user-compatible parameter name. In the long run we should be able to come up with a better name, anyway.|nocat=
stuff after the next update, we should ask us the following questions:
Half the examples for
{{Cite press release}} put date=...
near the beginning and half at the end. I know order doesn't matter, but the inconsistency hurts comprehension. Thanks y'all! --
Skierpage (
talk) 23:21, 7 September 2020 (UTC)
Hi, invalid template parameters throw an error message (and optionally a hint) when they contain a value, but are ignored when empty.
While it is okay to leave (some) empty parameters in a citation in order to point editors to missing information, I think, unrecognized parameter names should always generate an error, regardless if they contain a value or not. -- Matthiaspaul ( talk) 09:24, 9 September 2020 (UTC)
if
statement that looks for a parameter value. When the parameter value is an empty string, the code goes on to the next parameter in the template. For unknown parameters without assigned values, we simply follow the currently non-existent else
where we do a quick check to see if the parameter name is in the whitelist; ignore when it is, error message when it isn't.|url-status=live
when it adds empty |archive-url=
and |archive-date=
. I would be in favor of including |url-status=
without |archive-url=
(|url-status=
requires |archive-url=
) as one of those errors that populate
Category:Pages with archiveurl citation errors (another category that needs a name change).|url-status=live
, I must admit that I typically add this as well when I add |url=
and |access-date=
. While I normally try to provide |archive-url=
and |archive-date=
at the same time, sometimes this is not possible because archive.org
is down again or refuses to archive a site. In my opinion |url-status=
semantically belongs to |url=
primarily, only secondarily to |archive-url=
. While removing |url-status=live
in absence of |archive-url=
is debatable (in a citation I favour explicit settings rather than relying on default assumptions, because the former work as kind of documentation and the latter can change over time), I have recently seen a bot (IIRC it was GreenC Bot) removing |url-status=dead
in absence of |archive-url=
as well - this is annoying and clearly a bot error, because, if a URL goes dead or gets usurped by something else, this is a condition that should be recorded in |url-status=dead
even if no |archive-url=
is available (and in some cases there may not even be an alternative |url=
available). If this would be put into an error category, I can already see some careless editor or bot coming around removing the citation completely (although the document once was available and verified per |access-date=
). Therefore, we shouldn't remove |url-status=
and don't issue errors on this.{{cite book/new |title=Title |blue= |editors= |author=}}
{{cite book/new |title=Title |editors=Editors}}
{{cite book/new |title=Title |blue= ||author=}}
{{cite book/new |title=Title |blue= | |author=}}
Take a look at
Special:Diff/979504621 -- it looks like
PROVEIT is automatically placing the |url=
parameter after the author and name fields in {{
cite web}}. But on the documentation for that template, the provided formats all put that field first. It doesn't really matter to me either way, but it seems a little silly for the parameters to have two different canonical orderings. Anyone capable of shedding some light on this?
{
} 05:41, 21 September 2020 (UTC)
|url=
as the semantically most important parameter in the specific template context, whereas Provelt orders according to most common index fields. I consider this more of a cosmetic difference. I am not sure that dictating a canonical order to editors adds value. The required parameters are signaled. The software formatting can handle the rest.
64.18.9.222 (
talk) 11:05, 21 September 2020 (UTC)
In the past, a lot academic journals printed articles in different languages even in the same volume. The |language=
indicator of {{
cite journal}} should thus be article-specific, not journal-specific. By that I mean instead of
it should be
This suggestion is actually related to a similar one I made in May regarding the language indicator placement in {{ cite book}}. -- bender235 ( talk) 15:48, 24 September 2020 (UTC)
|language=
normally indicates the language of the work, but not necessarily that of |title=
because if the original language title is not known, |title=
(rather than |trans-title=
) may contain the translated (here typically: English) title. But what, if |script-title=
is used as well and its language prefix indicates a different language from |language=
? Assuming that noone would go through the hurdles of writing a title in a non-Latin script if the work would not be in this very language as well, shouldn't the prefix language be considered the more accurate info and override the language provided by the |language=
parameter? And, wouldn't it be possible that, if both are present and different, |language=
actually was meant to apply to the journal/book as a whole (based on its display position) rather than the article/chapter? Should we display two "(in language)" then?Only a minor point, and even one that would require a few hours work to clean up existing citations, so no priority, but in the long-run attempt to improve the consistency of the parameter interface of the citation templates and, where reasonably possible, reduce the number of parameters by making some of the existing parameters "smarter", I think, the |ignore-isbn-error=true
parameter (and its alias |ignoreisbnerror=true
) would be a good candidate to be replaced by adding support for the double-parentheses-syntax to
((accept this value as it is)) in the |isbn=
parameter.
For a long while, when I occasionally ran into "valid invalid" ISBNs, it always took me quite some time to look up the exact parameter name to disable the ISBN validation check because |ignore-isbn-error=true
was almost undocumented (meanwhile it can be found listed nearby the documentation for |isbn=
, so is easy to find).
Things would have been easier, if the template would have supported the ((syntax)) instead of using a separate parameter for this.
While this syntax is a bit cumbersome in itself (it needs to be), once you learn about it and have realized that this is a generic escape method used in various places to let the template accept parameter values it otherwise would not for some (normally but not in this particular case valid) reason, it becomes only natural to also try it when running into invalid |isbn=
values - only to find out that it is not supported there.
So, for consistency, it should be supported there as well, and the |ignore-isbn-error=
parameter be deprecated after existing citations have been adjusted accordingly (possibly by a bot).
(There are other cases, where the ((syntax)) should be supported as well (but still isn't), e.g. we recently had a discussion about quarters in |date=
, where it was recommended as a breakout as well, see
Help talk:Citation Style 1/Archive 68#Needs exception for unusual-format dates (2). The idea there was ((to reluctantly accept the input)) to not frustrate and block the editor in his/her endeavour to improve the encyclopedia, but to put such escaped forms into a maintenance category for evaluation in order to detect missing template functionality and for possibly necessary post-processing.)
-- Matthiaspaul ( talk) 10:30, 10 August 2020 (UTC)
Followup: |doi-broken=
/|doi-broken-date=
/|doi-inactive-date=
would be other candidates. While these and the |ignore-isbn-error=
parameter are reasonably named as is, they don't follow some overarching naming scheme and therefore are difficult to remember (and, as a consequence, need to be looked up whenever needed). It would be much more consistent and easier to remember if |doi=
would accept the ((syntax)) as well for such invalid DOIs.
-- Matthiaspaul ( talk) 10:39, 10 August 2020 (UTC)
|ignore-isbn-error=
has been set to "deprecated", and the remaining < 300 uses (
[25]) can be easily switched to use the ((accept-this-as-is)) syntax manually as soon as the template goes live, so that support for that parameter can be disabled in the subsequent update.
{{cite book/new |title=Title |author=Author |isbn=0-7506-4588-2}}
→ Author. Title.
ISBN
0-7506-4588-2. {{
cite book}}
: |author=
has generic name (
help); Check |isbn=
value: checksum (
help){{cite book/new |title=Title |author=Author |isbn=0-7506-4588-2 |ignore-isbn-error=yes}}
→ Author. Title.
ISBN
0-7506-4588-2. {{
cite book}}
: |author=
has generic name (
help); Check |isbn=
value: checksum (
help); Unknown parameter |ignore-isbn-error=
ignored (|isbn=
suggested) (
help){{cite book/new |title=Title |author=Author |isbn=((0-7506-4588-2))}}
→ Author. Title.
ISBN
0-7506-4588-2. {{
cite book}}
: |author=
has generic name (
help)CS1 maint: ignored ISBN errors (
link){{cite journal/new |title=Title |author=Author |journal=Journal |issn=0028-0836}}
→ Author. Title.
ISSN
0028-0836. {{
cite book}}
: |author=
has generic name (
help); |journal=
ignored (
help) (valid ISSN){{cite journal/new |title=Title |author=Author |journal=Journal |issn=1028-0836}}
→ Author. Title.
ISSN
1028-0836. {{
cite book}}
: |author=
has generic name (
help); |journal=
ignored (
help); Check |issn=
value (
help) (invalid ISSN){{cite journal/new |title=Title |author=Author |journal=Journal |issn=((1028-0836))}}
→ Author. Title.
ISSN
1028-0836. {{
cite book}}
: |author=
has generic name (
help); |journal=
ignored (
help)CS1 maint: ignored ISSN errors (
link) (ignored invalid ISSN)has_accept_as_written()
in
Module:Citation/CS1/Utilities/sandbox and used it in
Module:Citation/CS1/Identifiers/sandbox to replace v, count_accept = v:gsub ('^%(%((.*)%)%)$', '%1');
.Further researching possible options for
my proposal to streamline override options for ISBN and DOI error handling, I was going through the list of currently supported parameter aliases and I found that |ignoreisbnerror=
is actually unused. Given that, according to
this thread, we don't want to introduce new non-hyphenated parameter aliases any more and keep the existing non-hyphenated variants only for legacy support, I don't think it makes any sense to keep support for non-hyphenated parameter aliases if they are unused, in particular if they belong to such rarely used features. Therefore, I want to deprecate the |ignoreisbnerror=
alias.
Likewise, I was curious about the usage statistics of the many aliases parameter names for a small feature such as the DOI error override and found |doi-inactive-date=
to be used only as an empty parameter, apparently from copying empty templates into articles - meanwhile removed. Astonishingly, there were also a few live occurences of empty template parameters |doi-inactive=
/|doiinactive=
/|doibroken=
, although these are not supported as actual parameters by the templates (perhaps they were in the past and have never been cleaned up - done now).
There were three occurences of |doi-broken=
actually being used, which I switched to use |doi-broken-date=
instead, so that we are free to fade out |doi-broken=
as well.
Removing support for these aliases we'd end up with the two canonical parameter forms |ignore-isbn-error=
and |doi-broken-date=
only.
-- Matthiaspaul ( talk) 14:51, 6 September 2020 (UTC)
|ignore-isbn-error=
and |ignoreisbnerror=
are not new but were simultaneously introduced in April 2013 (
this edit) – that was before the
RfC that established our preference for hyphenated parameter names. Still, I, for one, do not object to deprecation and removal of little-used non-hyphenated parameter names.|doi-broken=
should be deprecated and removed because that parameter requires a date so its name should declare that. In the sandbox I have made |doi-broken-date=
the canonical parameter name. Similarly, |embargo=
should be deprecated and replaced with |embargo-date=
.|embargo=
in use, and in all of these cases the parameter value was empty - therefore I cleaned them up. I support the switch to |embargo-date=
or even better |pmc-embargo-date=
given that the parameter applies only to PMCs.|ignoreisbnerror=
, |doi-broken=
, |embargo=
, and ... ? You didn't mention |doi-inactive-date=
, which I think we can deprecate as well - it's not used. I don't see a reason why we would need to support |doi-broken-date=
and |doi-inactive-date=
in parallel, or are these two different use cases which might need to be distinguished in the future?|doi-status=dead
or even
eliminate it completely by using our special syntax as in |doi=((invalid-number))
.{{cite book/new |title=Title |author=Author |isbn=0-7506-4588-2 |ignore-isbn-error=yes |doi=10.1007/978-3-642-86187 |doi-broken-date=2020-08-30 |pmc=7135076 |pmc-embargo-date=2020-12-31}}
→ Author. Title.
doi:
10.1007/978-3-642-86187 (inactive 2020-08-30).
ISBN
0-7506-4588-2.
PMC
7135076. {{
cite book}}
: |author=
has generic name (
help); Check |isbn=
value: checksum (
help); Unknown parameter |ignore-isbn-error=
ignored (|isbn=
suggested) (
help)CS1 maint: DOI inactive as of August 2020 (
link) CS1 maint: PMC embargo expired (
link)|doi-broken=
(3× uses that you changed to |doi-broken-date=
so we are free to fade out |doi-broken=
) I have removed |chapter-doi=
and |title-doi=
as unused and unsupported from ~/Configuration/sandbox, ~/Whitelist/sandbox, ~/Suggestions/sandbox. Did I miss any? If / when there is support for these parameters, that is the time to introduce them; we should not speculatively add parameters.Hi, I feel like I remember a parameter trans-quote for translated quotes from citations in foreign languages. Am I remembering incorrectly, or has this been removed? Thanks, Ezhao02 ( talk) 13:31, 5 August 2020 (UTC)
|quote=
is a free-form parameter so you can include translations in it if you would like. Better in my mind, if the quoted material is important to the article, put that material in the article, translate it there and cite both; don't clutter the references section with quotations.|script-quote=
) in the past. While Trappist is right that |quote=
is a free-form parameter so you can add your own formatting, it would be desirable to have a consistent style centrally maintained instead of every editor having to invent his own conventions for this. Therefore, such a parameter is desirable. --
Matthiaspaul (
talk) 12:03, 8 August 2020 (UTC)In the absence of such a parameter, I prefer to format foreign-language quotations like this: "Lorem ipsum dolor sit amet. [This is a nonsensical example sentence.]" Glades12 ( talk) 13:18, 4 September 2020 (UTC)
{{cite book/new |editor-first=Diogenes |editor-last=Laertius |editor-link=Diogenes Laertius |title=On Plato's Apology of Socrates |title-link=I know that I know nothing |quote-pages=5 |quote=Εn oîda óti oudèn oîda. |script-quote=el:Ἓν οἶδα ὅτι οὐδὲν οἶδα. |trans-quote=I know that I know nothing.}}
→Εn oîda óti oudèn oîda.Ἓν οἶδα ὅτι οὐδὲν οἶδα. [I know that I know nothing.]
I would also [include the
many variants of expressing "No title" and] add support for a special token like "no-title" to indicate this condition; so, |title=none
would mute the display of a title, whereas |title=no-title
would display the descriptive title "[No title]" instead. (Well, if |title=none
would not be an established case already, I would recommend |title=off
for this instead, so that |title=none
would be free to display the "[No title]" message.) While these conditions are more likely to occur in newspapers and journals, the tokens should work in all cite variants, not only some of them (as "none" does at present). This would also simplify the code and documentation.
This way, we would improve consistency across the project, keep editors from inventing their own ways to express this special condition, and enable us to centrally update the message if this would become necessary in the future (e.g. due to a MOS change).
Which brings up another related topic: While the "no title" condition should IMO be a tokenized special case, I think, we should also have a dedicated parameter to enter other so called descriptive titles. (Descriptive titles are titles provided by the editor of a citation which differ from the actual title (if one exists) given by the author of the work. They are used in cases where the actual title is unsuitable to be reproduced in a citation for some reason (like being completely misleading, too long, historical alias names, non-existent etc.).)
We could use something like |desc-title=
, |descriptive-title=
, |description-title=
or just |description=
to distinguish them from actual titles. APA recommends to put descriptive titles in square brackets, some other style guides recommend to just write them without any text decoration (including without quotes)). See also:
It could be useful to treat them differently (or even to suppress them) in meta-data, so that descriptive titles don't end up polluting databases without any means to tell them apart from actual titles.
The handling of descriptive titles could be somewhat similar to how we treat |trans-title=
already, which reminds me of another related topic that |trans-title=
should also work without |title=
(instead of throwing an error), so that editors don't have to stuff translated titles into |title=
(if the original-language title is not known) causing readers to assume these were the actual titles of a work and thereby causing confusion when trying to locate the work. See
Help_talk:Citation_Style_1/Archive_67#Possible_improved_treatment_of_title_parameters_and_language_attributes
Both features, tokenizing the "no title" condition and adding some means to enter descriptive titles differently were requested by several editors in the past already.
-- Matthiaspaul ( talk) 16:37, 4 September 2020 (UTC)
Hi. Non-abbreviated year ranges are our preferred format for year ranges and there is certainly no particular need to support abbreviated year ranges in citations (except for if we can) - they could certainly be written in non-abbreviated form as well. Year ranges are comparably rare in citations, even more so abbreviated ones, as in most cases the publication date specifies a specific point in time rather than a span. I have seen less than a handful of abbreviated year ranges in citations in all those years.
On the other hand, incomplete dates consisting of only the month and the year and no day are very common in citations (I see them every day), but in the case of the ymd date format, the form "yyyy-mm" is disallowed in order to avoid a possible confusion with "yyyy–yy". Since the EDTF form "yyyy-mm-XX" is not currently supported as well (would be useful at least on source code level, not for display), this leads to such dates being rewritten as "Month yyyy", which unnecessarily creates inconsistency when all the other dates in the citations are given in ymd format.
Hence, it is reasonable to swap this around and fade out and ultimately disallow abbreviated year ranges in the |date=
parameter of citations at some point in the future (only there, not elsewhere where they are still allowed, including e.g. in |title=
, |chapter=
, or |quote=
parameters), so that, at some further point in the future, we can officially allow "yyyy-mm" in citations already using the ymd format. (In order to keep the change as minimal as possible, this is meant to affect only citations, not dates in tables or in the article body.)
In order to get a grip on how many citations actually have dates formatted this way at all, I would appreciate a tracking/maintenance category for citations using any detectable form of abbreviated year range (but at least the "yyyy–yy" form). -- Matthiaspaul ( talk) 13:19, 9 August 2020 (UTC)
{{
citation}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
citation}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
citation}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
citation}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
citation}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
citation}}
: Check date values in: |date=
(
help) (error in CS1){{
citation}}
: CS1 maint: date format (
link) (maintenance message in CS1)|date=
parameter into a dedicated maintenance category for further evaluation. The request is not to check the current implementation to be in sync and to be compliant with the MOS, nor is it to throw any additional error messages. The question I hope to be able to answer is the extent to which such abbreviated year ranges are used in citations at present (although I already assume them to be rarely used), and if there is anything special about the articles using such citations.insource:/| *date *= *[0-9]{3,4} *[-–] *[0-9]{1,2} *[|}]/
" as a search pattern, which, however, times out, therefore does not give accurate figures). At this stage, this does not need to be 100% exact math, although someone reading my intentions for this request above and being familiar with the actual implementation would probably be able to nail it down with precision right from the start.|publication-date=
and |year=
parameters in addition to those in |date=
.|date=
, |year=
or |publication-date=
parameter will now be indicated by an optional maint message and put into new category "Category:CS1 maint: abbreviated year range" for further evaluation:It looks like the code may need refinement.
{{
cite book}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
cite book}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
cite book}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
cite book}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
cite book}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1)Case 4 is incorrectly marked with a maintenance message. Case 7 already fails the date check, so it does not need a maintenance message. – Jonesey95 ( talk) 00:09, 20 September 2020 (UTC)
|date=
, |year=
, and |publication-date=
). Your cases 1, 4 and 7 are actually those cases I am looking for, as detailed further above. The behaviour of the existing date validation code was deliberately not changed. --
Matthiaspaul (
talk) 00:28, 20 September 2020 (UTC)
add_prop_cat()
from
Module:Citation/CS1/sandbox to
Module:Citation/CS1/Utilities/sandbox.|orig-date=
). In rare cases, the publisher's data actually specified a year range, in those cases mostly for consecutive years.The RfC on title-linking was concluded yesterday. A related WP:AN discussion is still open. I'd like to prepare updates that will be necessary to Template:Citation Style documentation, including its id2 subtemplate, to make it conform to the outcome of the RfC. Thoughts? Or is it best to wait until the AN thread is closed? -- Francis Schonken ( talk) 13:25, 20 September 2020 (UTC)
(my emphasis). The RfC close contains:When an URL is equivalent to the link produced by the corresponding identifier (such as a DOI), don't add it to any URL parameter but use the appropriate identifier parameter, ...
There is consensus against removing a parameter just because it is a duplicate.
|url=
parameter or title link can then be used for its prime purpose of providing a
convenience link to a
free-to-read copy of the source that would not otherwise be obviously accessible|url=
value (like
[31]) when a |doi=
(pointing to
[32]) is present. (In the given recent example, CitationBot also removed the |archive-url=
alongside the |url=
, thereby causing even more damage.) As I pointed out in the RfC, the terms "equivalent", "redundant" and even "duplicate" are apparently not clear enough to transfer the message unmistakably, therefore the wording should be actually changed to "exactly the same" or "identical".|url-access=
(and |url-status=
and |access-date=
) to specify the access status of |url=
just like we have |doi-access=
(and |doi-broken-date=
) for |doi=
etc. Also, while DOIs are designed to be long-living, they are not necessarily longer living than URLs. I have seen citations with broken URL and working DOI but also vice versa. So, the key against link rot is redundancy through archives and alternative links. As this is not actually relevant for template documentation purpose, we could either correct the statement or remove the sentence completely.|url=
is not to provide a free-to-read copy of the source, but to point to the cited document, regardless if it is free or not. This doesn't rule out free documents, which are always nice to have, of course, but the notion that |url=
was only for free documents crept further elsewhere and was (ab)used by some editors as an argument to remove |url=
parameters from citations as well.|url=
to exist, therefore this could be reduced to something like "The |url= parameter [...] can then be used for other purposes." or be removed completely.|url=
can be considered unnecessary, if exactly the same link can also be established via auto-linking of one of the provided identifiers in a citation, but the condition really is "exactly the same" and not "similar" or "equivalent". (Only) under this specific condition removal of |url=
would have zero effect on how a citation looks like and functions on user level, and therefore could be considered harmless, if not even beneficial (cleaner and easier to maintain citation code).)|url=none/(title-)doi/pmc/<other-identifier-parameter-name>/<url>
/|chapter-url=none/(chapter-)doi/pmc/<other-identifier-parameter-name>/<url>
only to (again) switch to use |title-link=none/doi/pmc/<other-identifier-parameter-name>/<link>
instead in
Help_talk:Citation_Style_1/Archive_70#Towards_solving_pending_issues_of_the_auto-link_feature.... Despite Pintoch's negative opinion on this, other users (proponents as well as editors opposing auto-linking in general) including Trappist the monk, Headbomb, Nardog, David Eppstein, myself and others have repeatedly asked over the years that auto-linking, if implemented, should have such a control. I won't go as far as to request for the setting "none" to become the default, still I think, also in the light of the outcome of this new RfC, that this facility should be implemented ASAP (ideally before the next update) to finally settle the case (so that future enhancements of auto-linking, some of which have been requested already, can be based on a solid implementation). --
Matthiaspaul (
talk) 11:21, 22 September 2020 (UTC)
I propose moving |format=
content so that it is positioned after title and not after text "Archived from the original". --
5.43.72.55 (
talk) 19:50, 27 September 2020 (UTC)
For a while now I have intended to begin the live-module update process. Whenever I got myself ready to do that, someone changed something so I put it off.
It is time to freeze changes to the module suite sandboxen so that we can update the live modules. Finish what you are doing this weekend. No changes after Sunday except to fix something that is obviously broken. Next weekend we can announce an update for 10–11 October 2020.
— Trappist the monk ( talk) 16:10, 26 September 2020 (UTC)
As extensively discussed in the past months, a manual override facility has now been implemented for the auto-linking feature.
For this, |title-link=
now supports a number of additional keywords: none
, pmc
, doi
. They can be used to manually select one of the identifiers enabled for auto-linking (currently only PMCs and DOIs) or to completely disable auto-linking. Any values not matching one of these keywords will be interpreted as link target to a Wikipedia page (or one of its sister projects), as before. If such a link target would clash with one of the keywords, the
((accept-this-as-is)) syntax can be used to enforce the interpretation as a link target.
Auto-linking is also disabled if the display of the title has been disabled by |title=off
(currently also still |title=none
), whereas it remains enabled for descriptive titles (including the "No title" case, which can be specified by |title=none
in the future).
If the |title-link=
parameter is left empty and no |url=
is specified, the template will automatically select an identifier for auto-linking, whereby the current priorities will let PMCs take precedence over DOIs, assuming both to be valid and active. Invalid or embargoed PMCs as well as non-free, inactive or invalid DOIs will be ignored in this selection. To play it safe, the present implementation also ignores "invalid" DOIs accepted using the accept-this-as-is syntax - after all, auto-linking is a non-essential feature and the identifier link is always available through the normal identifier link as well.
At present, auto-linking is only enabled for {{ cite journal}}, but it could be generalized to be supported by other cite templates as well (as was requested already).
The list of supported identifiers can be extended in the future (also already requested), but I recommend that only manual auto-linking will be used for a larger list of identifiers, unless the identifier will have a similar "prominence" as DOIs or PMCs. Otherwise, the priority-based auto-selection may appear "arbitrary" to readers.
Another possible future extension (also already requested) would be to allow auto-linking of chapters in addition to titles.
See also:
Some examples:
Extended content
|
---|
|
-- Matthiaspaul ( talk) 18:51, 27 September 2020 (UTC) (updated 14:45, 30 September 2020 (UTC))
Extended content
|
---|
|
|title-link=
instead of embedding the link into |title=
itself, this is not blocking a release.|auto-link=
or |auto-url=
(both originally suggested by Headbomb), and two overloading existing parameters, |url=
(originally suggested by
Trappist the monk,
Nardog and me) and |title-link=
(also suggested by me, but Trappist also noted sympathies for this). Headbomb's proposal would have added a new parameter and the names suggested so far did not fit into our naming scheme well, but he was generally open to other parameter names and implementations. When requests regarding auto-linking of chapters came up, I abandoned my |title-link=
proposal in favour to Trappist's because it appeared slightly more flexible in the long run, but switched back to |title-link=
to address your concerns that overloading |url=
might cause problems with external scripts needing to be updated. In the post above I gave links to some of the past discussions regarding this.|url=doi/pmc/jstor/etc/none
/ |chapter-url=doi/pmc/jstor/etc/none
. If you want an example where a link is not desired, title-less journal citations would be the go-to example.
{{
cite journal}}
: CS1 maint: untitled periodical (
link)|url=
and |title-link=
proposals code-wise, I have come the conclusion that the latter was even easier to implement. (I have a solution for the chapter link issue also for |title-link=
but this will need more discussion, therefore it's not included at this time.)|title-link=
is a terrible use for this because it is overwhelmingly used for links to Wikipedia and sister projects like Wikisource. This replaces URL, so it should use the URL parameters. Difficulty of implementation matters a whole lot less than ease of use (|url=
is both much shorter to type than |title-link=
, and guarantees there is no conflicting url/title-link like someone adding |url=
https://example.com
to a citation with |title-link=doi
.
Headbomb {
t ·
c ·
p ·
b} 19:30, 1 October 2020 (UTC)
|title-link=
is "terrible", I see your point (that's why I proposed |url=
for a long while as well ;-). Also, I specifically agree with that difficulty of implementation does not matter (we should always strive for the best-possible solution for users, no matter if it is difficult to code or not). Among the cons for |url=
is that bots reading citations might be confused if they find something like "doi" in this prominent parameter, whereas it is very unlikely that they care about the value of an "inward-bound" parameter such as |title-link=
. Among the pros for |title-link=
is that something like |title-link=doi
or |title-link=none
is semantically much more to the point than |url=doi
or |url=none
. An the argument of states being mutually excluded by the underlying parameter logic applies to both parameters as well, just that |url=
is probably more commonly used than |title-link=
. I was (and still are) open to both, but now slightly favour |title-link=
. Functionality-wise, both solutions are equivalent. --
Matthiaspaul (
talk) 20:06, 1 October 2020 (UTC)|url=
is that bots reading citations might be confused if they find something like "doi" in this prominent parameter, whereas it is very unlikely that they care about the value of an "inward-bound" parameter such as |title-link=
.{{cite web|url=htp:s//example.com|title=Title}}
. There are tons of those in
Category:Pages with URL errors. Most such tools or bots already correctly handle such errors either by failing, or by not touching |url=
because they don't know what to do with it. Using the existing parameter |url=
/|chapter-url=
/|contribution-url=
/|foobar-url=
greatly reduced complexity for users, who then don't need to learn the arcane |title-link/chapter-link/contribution-link=
and wrap their heads around why a -url
parameter is renamed -link
.
Headbomb {
t ·
c ·
p ·
b} 20:32, 1 October 2020 (UTC)I propose to update cs1|2 module suite over the weekend 10–11 October 2020. Here are the changes:
|editors=
parameter;
discussion|<name>-link=
and |<name>-mask=
interaction;
discussion|orig-date=
preferred over |orig-year=
, change metaparameters;
discussion<module>.<function>()
calls to avoid upvalue limit;
discussionadd_prop_cat()
to
Module:Citation/CS1/Utilities/sandbox;
discussion|title=
;
discussion|trans-quote=
, |script-quote=
, |page(s)-quote=
;
discussion|last-author-amp=
;
discussionModule:Citation/CS1/Configuration
|editors=
parameter|subject-mask=
parameters;
discussion|orig-date=
;
discussion|series-separator=
;
discussion|ignoreisbnerror=
, |doi-broken=
, |doi-inactive-date=
and rename |embargo=
to |pmc-embargo-date=
;
discussion|author-given#=
, |author#-given=
, |author-surname#=
, |author#-surname=
, |interviewer-given#=
, |interviewer#-given=
, |interviewer-surname#=
, |interviewer#-surname=
, |display-subjects=
;
discussion|displayeditors=
, |editormask=
and enumerated forms;
discussion|notracking=
and |no-cat=
, made |no-tracking=
the canonical form for now;
discussion|title=
;
discussion,
discussion|trans-quote=
, |script-quote=
, |page(s)-quote=
|name-list-style=
as preferred alias of |name-list-format=
;
discussion|editors=
parameter|subject-mask=
parameters; deprecate non-hyphenated subjectlink params;
discussion|orig-date=
|series-separator=
|ignoreisbnerror=
, |doi-broken=
, |doi-inactive-date=
and rename |embargo=
to |pmc-embargo-date=
|interviewerlink=
and |interviewermask=
; add support for missing aliases |author-given=
, |author-surname=
, |author-given#=
, |author#-given=
, |author-surname#=
, |author#-surname=
, |interviewer-given#=
, |interviewer#-given=
, |interviewer-surname#=
, |interviewer#-surname=
, |display-subjects=
;
discussion|transcript=
, |transcript-format=
, |transcripturl=
,|transcript-url=
, and |inset=
to unique arguments table;
discussion|mailinglist=
, |mailing-list=
to unique arguments table;
discussion|displayeditors=
, |editormask=
and enumerated forms;
discussion|displayauthors=
as well as |editorlink=
, |authormask=
and enumerated forms;
discussion|ignore-isbn-error=
;
discussion
discussion|notracking=
and |no-cat=
, made |no-tracking=
the canonical form for now|trans-quote=
, |script-quote=
, |page(s)-quote=
|name-list-style=
as preferred alias of |name-list-format=
|last-author-amp=
Module:Citation/CS1/Date validation
Module:Citation/CS1/Identifiers
|doi=
& |pmc=
when embargoed, broken, or fail validation; convert inactive doi categories to proper maint cats;
discussion|doi=
, |eissn=
, |isbn=
, |issn=
, |sbn=
;
discussion
discussion,
discussionModule:Citation/CS1/styles.css
Module:Citation/CS1/Suggestions
|orig-date=
instead of |orig-year=
parameter;
discussion|ignoreisbnerror=
, |doi-broken=
, |doi-inactive-date=
and |embargo=
;
discussion and
discussion|interviewerlink=
and |interviewermask=
;
discussion|eprint=
, |inset=
, |network=
, |newsgroup=
, |newspaper=
, |postscript=
, |surname=
, |transcript=
, |vauthors=
, |veditors=
)|authorfirst=
, |authorlast=
, |authorgiven=
|authorsurname=
, |displayeditors=
, |editorfirst=
, |editorlast=
, |editorgiven=
, |editorsurname=
, |editormask=
and enumerated variants;
discussion and
discussion|laysummary=
and |lay-summary=
.|forename=
and |family=
due to our support for given/surname instead of given/family and forename/surname|notracking=
and |no-cat=
;
discussion—
Trappist the monk (
talk) 10:18, 3 October 2020 (UTC) 10:42, 4 October 2020 (UTC) (+empty unknowns) 14:04, 4 October 2020 (UTC) (+|last-author-amp=
) 15:07, 5 October 2020 (UTC) (+interwiki link check)
Wikitext | {{cite book
|
---|---|
Live | Smith, Harvey Jnr. Title. {{
cite book}} : Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (
help)
|
Sandbox | Smith, Harvey Jnr. Title. {{
cite book}} : Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (
help)
|
* "error messaging for 'Wayback Machine' and other generic titles" .. this one will probably generate community discussion due to the volume of red messages. Possible outcomes include:
|title=no-title
will come up and people will begin using no-title in some automated fashion to squelch errors. Then we don't know what is a legit no-title versus one that was a generic title needing filling in.Once it becomes a general VP/community issue developers can loose control of what they think is best due to RfC outcomes. if we are lucky that won't happen but given the scale of red errors it's a real possibility. There are also the other stakeholders involved IABot, Citation bot, WaybackMedic, Refill and others. Personally of the opinion we should try and reduce cases before adding red errors, or at least announce the intention and give the community some time (6 months etc) to respond. -- Green C 17:03, 3 October 2020 (UTC)
cs1|2 does not support 'dynamic' error category names. It could, because we create some maintenance category names dynamically, it just doesn't because there has been no need.
In this case there is no need for five separate error categories when one will be sufficient. So, I have tweaked the code so that these errors will all be listed in the single category: Category:CS1 errors: display-names.
— Trappist the monk ( talk) 18:33, 5 October 2020 (UTC)
Would it be possible to add a "Revised by" parameter for Template:Cite encyclopedia? I'm speaking specifically of using it for Grove articles, such as this one, where having the person who revised the article as the second author wouldn't make sense (because they didn't add the bulk of the article) and having them as the editor wouldn't either (because they aren't the editor of the encyclopedia as a whole, which is how it would display). Aza24 ( talk) 18:34, 5 October 2020 (UTC)
|others=
is useful for edge cases like this. –
Jonesey95 (
talk) 21:06, 5 October 2020 (UTC)|others=
. I don't think cases with sources that name their revisors are common enough to make an entirely new parameter worthwhile.
Glades12 (
talk) 18:40, 6 October 2020 (UTC)
I must have missed the discussion/rationale for replacing the parameter labels p and pp, with page and pages respectively, in {{cite xxx}} templates. Can you please point me to the relevant section(s)? Thanks. I just noticed Citation Bot making the related edits. 98.0.246.242 ( talk) 22:44, 5 October 2020 (UTC)
|p=
with |page=
and |pp=
with |pages=
then you should take that up at
User:Citation bot. All four of those parameters are legitimate aliases; |page=
and |pages=
are the canonical forms.|p=
and |pp=
. The edit that appears to make aliases of |p=
and |page=
and of |pp=
and |pages=
is
this edit. Was that discussed? Don't know. You might troll through the archives of this page and the
Module talk:Citation/CS1 archives to see if it was discussed.This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 65 | ← | Archive 69 | Archive 70 | Archive 71 | Archive 72 | Archive 73 | → | Archive 75 |
|badauthor=
" parameter alias in the
linked thread. In fact, I was thinking about something similar myself some while ago:The prefix would have to be worded more neutrally like |debug-*=
, |check-*=
, |recheck-*=
, |TEMP-*=
, |-*
("minus"), |~*
("uncertain"), |?*
("question mark") or similar, and the prefix should be applicable to all template parameters in general, like |recheck-editor-last3=Radcliffe
, |-issn=0367-9950
or |?publication-date=29 February 1866
.
If an editor runs into a parameter value that appears to be incorrect and that should be double-checked, but cannot be verified immediately, the editor would just add the prefix to mark it for future review. Once this or another editor has checked a parameter flagged this way, s/he would correct the value if necessary and/or simply remove the prefix again.
The template could populate a special maintenance category for this, but otherwise these aliases would be treated exactly as their canonical forms, including error checking. This way, this feature could be coded as a general exception to the normal parameter evaluation and therefore without overhead and it could be documented in a single place like our (( accept-this-as-it-is)) syntax, without having to list it as an alias everywhere.
An alternative to this are HTML comments, but they are not machine-readable and wouldn't cause the citation to show up in a maintenance category.
The system could be extended to bot edits as well in two ways:
Bots running into entries they find fishy but cannot resolve reliably (that is, with 100% accuracy) could instead mark the parameter with the prefix and leave it to humans to actually check and possibly correct it, instead of applying guesswork themselves. This would extend the model of a bot/tool assisting a specific user synchronously to assisting all possible editors, and asynchronously, without causing harm in case of problems.
Also, bots and similar tools could be asked to flag all entries where they changed values with |-
, and prefix all parameters where they added information with |~
(or at least those where potentially inaccurate info was added - this should never happen in the first place, but we all know that in reality it happens quite often at least with some bots/tools). Parameters prefixed with |~
would be ignored by the citation template, except for, perhaps, populating a maintenance category, and, possibly, show up in preview already (but framed somehow). Editors working on the article and improving citations would simply have to remove the prefixes after reviewing them.
Thereby, it would be much easier for humans to identify bot edits for review (also long after the fact when it might no longer be listed among the recent edits in the edit history) and to double-check some additions before they go live. It would take some time for this new process to trickle through, but since it's technically optional the transition would be smooth and the situation would gradually improve with each new bot/tool adopting it.
IMO, this could solve many problems with Citation Bot and similar overambitious tools by allowing them to make suggestions instead of actually carrying out the edits and often messing up citations. Even if the concept would not be adopted community-wide, it could still be used by those who decide to use it.
For readers, the |-
idea would have no visible impact at all, whereas |~
prefixed information would only become visible with some delay. But for anyone looking at the source code (or preview), the scheme would be completely transparent.
I see this as kind of an informal but formalized and thus machine-readable light-weight communication and process model which can be voluntarily adopted by anyone to ease the normal communication and ad-hoc citation improvement process among human editors and bots (instead of leaving HTML comments, having to discuss temporary details on talk pages, or fighting against each other).
-- Matthiaspaul ( talk) 14:39, 3 September 2020 (UTC)
Further extending the notation of using |-
(or |?
or |~
) prefixes, it would also be possible to mark parameter values, which have been verified by humans already, with a |+
(or even a |!
) prefix. At the same time this could be used as a flag to tell bots to leave a particular parameter alone, like |+author-last=Gray
. This would hardly be necessary for all given parameters in a template, but could be convenient to have if a known correct value will likely (or has already) trigger(ed) false alarms (like a name including what appears to be a typo but isn't). In contrast to a HTML comment, it would be shorter and machine-readable. As a template-wide "global" feature applicable to all parameters this could be coded with minimal overhead.
If the |-
prefix would be used for to-be-checked parameter values, |~
could be conveniently used for bot-added values, or vice versa.
-- Matthiaspaul ( talk) 20:49, 3 September 2020 (UTC)
|-
, |+
and |~
could be utilized to solve this dilemma as well:|-
would indicate "this parameter value needs to be reviewed" to other editors, so, if, by the same principle, an editor would prefix an empty parameter with |-
this would mean "Hey, I'm deliberately adding this empty parameter here because this missing information should be part of this citation, therefore please review and possibly add the info if you can". Example: |-author=
. Once an editor adds the missing info, he would remove the parameter prefix again. Example: |author=John Doe
.|-author=John Doe
, thereby telling other editors "Hey, this name looks fishy to me and might be a placeholder rather than the correct name, but I can't prove it right now. Please review if you can". Later, another editor would stop by and scrutinize the citation, and if s/he finds that the value is correct as it is, s/he would either remove the prefix again or, if it is likely that the value will stir up questions again, indicate that the value has been verified to be correct |+author=John Doe
, thereby telling other editors "Yeah, this doesn't look right, but I verified it and this particular author is actually named John Doe. Everything is fine". Something along this line...|-
in order to avoid their removal.I think that all cs1|2 error categories should have consistent naming as we have done for maintenance cats. We have standardized on CS1 errors: <descriptor> as a naming convention. This is a list of existing non-standard error categories, their page counts, and proposed replacements:
additions:
I don't think that it matters how many articles are listed in a category; if this change is accepted, old cats will depopulate as articles wend their way through the job queue until empty and new cats will populate in the same manner.
Any reasons we shouldn't do this? Better cat descriptors?
—
Trappist the monk (
talk) 13:33, 12 September 2020 (UTC) 00:49, 14 September 2020 (UTC) (addition) 14:16, 14 September 2020 (UTC) (better name)
|archiveurl=
and |accessdate=
to their hyphenated variants in the category names. Therefore, full support.|url-status=unfit
.
Category:CS1 maint: unfit url also holds articles that have cs1|2 templates that use |url-status=usurped
. cs1|2 does not distinguish one from the other as humans do.|url-status=unknown
; there is not. The BOT:
part of that category name is to suggest that bots using, |url-status=bot: unknown
, are responsible for adding articles to the category. The primary (only?) bot using this is InternetArchiveBot.{{یادکرد وب|نام خانوادگی= Omidsalar|نام= Mahmoud|پیوند نویسنده= محمود امیدسالار|عنوان= GENIE|نشانی= http://www.iranicaonline.org/articles/genie-|بازبینی= ۱۵ آوریل ۲۰۱۲|اثر= |تاریخ= ۱۵ دسامبر ۲۰۰۰|ناشر= [[دانشنامه ایرانیکا]]|نشانی بایگانی= https://web.archive.org/web/20110429185114/http://www.iranicaonline.org/articles/genie-|تاریخ بایگانی= ۲۹ آوریل ۲۰۱۱|کد زبان= en|dead-url= no}}
{{
cite web}}
: Check date values in: |access-date=
, |date=
, and |archive-date=
(
help); Unknown parameter |dead-url=
ignored (|url-status=
suggested) (
help)url
), but to the abbreviation URL (Uniform Resource Locator), hence should be uppercased:|url-status=
should be hyphenated. If this is not related to the parameter but to URLs, the abbreviation should be uppercased. (On a different note: Why did we name the value "bot: unknown" rather than just "unknown"?){{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2020-09-13}}
→
Title. Archived from
the original on 2020-09-13.bot: unknown
starts at
User talk:Cyberpower678/Archive 36#alternate |dead-url= keyword.{{
cite mailinglist}}
.|url-status=bot: unknown
. Makes a lot of sense to have the keywords based on semantics/purposes (my saying as well). Still, it always kind-of-strikes me as odd when I see this bot:
in citations (probably, because this is a one-off syntactical concept rather than something used in other parameters as well). If we had to introduce this today I would probably suggest a hyphen-affixed bot-
prefix (like in |url-status=bot-unknown
) or would try to embed this into the more general
parameter review scheme proposal (similar to |~url-status=unknown
). Although, in the current version of that proposal, this would not change the linking behaviour and just put the citation into some special category, so that, for the link to be suppressed (as with bot: unknown
), that proposal would have to be adjusted/extended somewhat. Something to think about...Question, isn't "Category:CS1 errors: bare URL" the same error as "Category:CS1 errors: missing title"? Those don't seem to be independent. AFAICT, the first is missing titles when there's a URL, the second is missing titles regardless of if there is a URL. Headbomb { t · c · p · b} 16:02, 13 September 2020 (UTC)
|chapter-url=
without |chapter=
:
{{cite book |title=Title |chapter-url=//example.com}}
→
//example.com. Title. {{
cite book}}
: |chapter-url=
missing title (
help)|title=
, |trans-title=
, and |script-title=
(no main-title parameter):
{{
cite podcast}}
.Recently, Matthias has added support in the suggestions list to parameters that have been removed, listing a few related discussions but none which directly cite a decision to support parameters that are removed. Is this something we want to do? I am not generally in support of it -- we've removed the parameters from support, so why are we continuing to support them? -- Izno ( talk) 18:22, 16 September 2020 (UTC)
{{
cite web}}
: Unknown parameter |werk=
ignored (|work=
suggested) (
help). Or perhaps I misunderstand what is at issue. –
Jonesey95 (
talk) 19:42, 16 September 2020 (UTC)
|trans_title=
).|laysummary=
recently). In some sense, these can be considered "misspellings", but I would also classify them as "former parameters". I think it is important to document their type in the comments (this might be helpful when the current list might need to be turned into a more complex table with various flags in the future). In the case of old parameters, it might even make sense to record the date of deprecation, so this can be reevaluated a couple of years later.|transcript=
, |transcript-format=
, |transcripturl=
, and |transcript-url=
are unique to {{
cite av media}}
and {{
cite episode}}
I have moved them to the unique_arguments{}
table in the whitelist sandbox.
— Trappist the monk ( talk) 19:02, 11 September 2020 (UTC)
{{
cite podcast}}
but that apparently fizzled for who-knows-why.Pyramus in Shakespeare's A Midsummer Night's Dream Act 5, Scene 1
Yesterday I thought to create a common function to handle accept-as-written markup. There are several places in
Module:Citation/CS1/sandbox that detect and strip that markup so starting at the top of the module and working down, I replaced each independent detect-and-strip with a call to the new function, testing as I went. Worked great until I got to citation0()
and bam! ran straight into a wall at full speed.
Lua has a built-in, unalterable limit of 60 upvalues. Roughly speaking, an upvalue is anything in a module that has the same scope as the function in question and is directly used by the function. In ~/sandbox, there are some 61 functions that may be used by citation0()
(not all of them are directly used). Additionally there are 24 functions held in various other modules (most of them used by citation0()
) that count against the upvalue limit.
We have been close to this limit for some time. Since the last update, ~/sandbox has gotten two new functions, list_make()
and is_generic_title()
, and one new table auto_link_urls{}
and dropped the function is_embargoed()
. At the time that I hit the wall, we were sitting right at an upvalue count of 60.
So, what to do? For the nonce, I have taken the cheap and easy way out. The 24 functions held in various other modules were declared as local names to make life a bit easier so, for example,
Module:Citation/CS1/Utilities/sandbox has a very commonly used function is_set()
. To make that easier to type, the cross-module name utilities.is_set
was mapped to a local name is_set
. I have changed all of the remapped names to their cross-module names. Doing that reduced the upvalue count by 20 (I believe – not tested). There were 24 functions from four modules so should be 20.
citation0()
is an enormous beast. It can be reorganized and split into multiple sections which is something that I have wanted to do for a long long time. But it isn't an easy task so I have been putting it off and putting it off ... 'O wicked wall...'
— Trappist the monk ( talk) 15:18, 13 September 2020 (UTC)
"Access dates are not required for links to published research papers, published books, or news articles with publication dates."
With regard to the last of those, bear in mind that news articles are often revised some time after publication, and the date of revision (along with the reason/s for doing so) will be noted in the text. Additionally, my own experience suggests that even though the content of an article may not be revised, revisiting an article some years after publication can result in the discovery of a very different headline from the one noted in the citation, filled out earlier in the article's existence. Harfarhs ( talk) 22:30, 18 September 2020 (UTC)
|date=
for the date of the last update, which I do not.
Glades12 (
talk) 05:10, 19 September 2020 (UTC)
|date=
parameter is that of the latest date (of revision) that is known.|access-date=
is quite important.|access-date=
is never required, but optional. (In my opinion it is always desirable to have per
WP:V, whereas some editors see it as clutter.) Basically, it is up to the editorial judgement of the editor adding a citation if s/he thinks it is useful in a citation or not. Therefore, let's delete that misleading sentence completely. It has no place in a template's documentation.What should you do when the appropriate value for |place=
(i.e. the place where a source was written (or otherwise created)) is known, but not |publication-place=
? An example is the video
Hirokazu Tanaka on Nintendo Game Music, Reggae and Tetris (used at
Hirokazu Tanaka), which was recorded in Tokyo, but could have been published at just about any place with a Red Bull office.
Glades12 (
talk) 05:33, 19 September 2020 (UTC)
|place=
like everyone else? The distinction, for all intents and purposes, is nil at this point. (That aside, citing the location matters less and less entirely these days for anything of relevant sort from what I have observed.) (Also, Ttm, weren't we going to look at place/pub-place?) --
Izno (
talk) 06:15, 19 September 2020 (UTC)
|publication-place=
and |location=
/|place=
are used at the same time. Then |location=
/|place=
becomes a parameter only for the written-at-place.|place=
and |location=
are unfortunate because of their ambiguity. Therefore we should introduce a new dedicated parameter for the written-at-place, like |written-place=
. However, given that |place=
/|location=
can also be used to specify the publication place for as long as |publication-place=
is not present, and some editors have a very bad habit of changing |publication-place=
to |place=
, existing entries of |place=
/|location=
cannot be automatically converted into |written-place=
(nor |publication-place=
), but will, once the new parameter has been introduced, have to be reviewed individually.See also XKCD standards strip.This one?
HI all
Is the template currently broken?
I have used it for a time code in a film, but it seems to be just priting the parameters onto the article text for the viewing public:
(Last paragraph)
There are quotation marks around the last iteration of "Kevin Reynolds", but these are not selected when copy/pasting I am going to have to remove access date, as it is asking me for a url for the access date ... of course it came from my brain, as i know what date it is today lol
and now going to hide the whole mess ...
Chaosdruid ( talk) 17:47, 19 September 2020 (UTC)
<ref>...</ref>
tags?Our recent discussion
Help_talk:Citation_Style_1#Guidance_about_indexing_by_first_name? made me think (again) about the best choice for the canonical parameter names of the various name-related parameters. We currently support the variant pairs |first=
/|last=
and |given=
/|surname=
for all our name parameter sets |author=
, |editor=
, |contributor=
, |translator=
and |interviewer=
.
While the first pair (our default) does not create problems for (most) Western names, it actually is ambiguous. Even our citation templates render the names in the order "last, first", something we accept without much thinking because we are so used to it. However, for names not following the Western name order, it is not obvious which part of the name belongs into which parameter, as what is displayed first and last may depend on context.
An alternative concept that works across almost all (Western and Eastern) cultures is to distinguish not the first and the last name, but the given and the family name (which we, somewhat oddly, call surname in our parameter interface, although that would better pair with forename, but anyway).
Since proper semantics are more important for input data than "proper" display order (which can be changed through other means if necessary), I think, we should switch to use |given=
/|surname=
as our canonical defaults. |first=
/|last=
would be supported as before, just not be the defaults any more.
The only difference would be that |given=
/|surname=
would be listed first in the list of alias names, and |first=
/|last=
a bit later.
The advantage of this minimal change would be that the risk of mixing up the given and family name of names in
Eastern name order would be significantly reduced (if not eliminated, except for when they aren't known in the first place) in all new citations entered. Some bots (and probably also VE) would automatically start to use |given=
/|surname=
rather than |first=
/|last=
when adding new names to a template.
-- Matthiaspaul ( talk) 01:52, 20 September 2020 (UTC)
There has been an internal reorganisation of the horse profiles database at Racing Post (formerly at bloodstock.racingpost.com), so a number of citations (probably a couple of thousand, almost all using {{ cite web}}) will have to change to match. Fortunately the mapping from the old to the new URLs is straightforward. As I see it, there are three possible approaches:
|id=
parameter, in the same way as templates such as {{
ProQuest}}All of these options involve about the same amount of work, and all could be done by bot or by AWB. My own feeling is that option 1 would be to miss an opportunity to futurepoof these citations, so the only real choice is between options 2 and 3. Because the citations currently use {{
cite web}}, option 2 leads to error messages complaining about the lack of a URL. This can be fixed by changing to another citation template such at {{
cite journal}}. but is obviously undesirable as the Racing Post database is not a journal. Option 3 seems the best to me, but I'd appreciate input from citation specialists here. (And as a supplementary question: the current citations mostly include parameters |date=
and |access-date=
- I don't think these are either necessary or beneficial when citing this sort of database and I'm inclined to just discard them - any thoughts?)
Colonies Chris (
talk) 10:58, 20 September 2020 (UTC)
{{
cite web}}
parameters they want to the basic template. {{
cite Grove}}
is one example of a wrapper template.|date=
is concerned, this is a bit tricky when it comes to databases. Citing a record (a particular horse profile) is pointing to an in-source location, the source being the database. One should date the database edition/version normally. However, individual records may be revised or updated more often than the database itself and this should be cited too. I would utilize {{
citation}}. I would use (clumsily) |date=
for the record revision date. I would use |edition=
for the database revision/version (this may also be a date). Access dates are not needed in such rendition. This is not perfect but should work, assuming the database is indexed by record-subject+record-revision.
172.254.241.58 (
talk) 13:12, 20 September 2020 (UTC)
|access-date=
is apt, as the proper entry for date would be |date=n.d.
. This would be awkward in the specific-source template you have in mind, you may want to leave |date=
out altogether. The other option involves wading into the source code to figure out the revision date, which is convoluted. And {{
cite web}} is now as good or better than {{
citation}} as the base template imo.
64.18.9.222 (
talk) 03:53, 21 September 2020 (UTC)British motoring magazine What Car? makes for rather silly looking punctuation. How can I best avoid the period after the "magazine" field in template:cite magazine? It currently ends up looking like this: [1] Reference
Thank you, Mr.choppers | ✎ 18:24, 20 September 2020 (UTC)
Following up on the recent thread Help_talk:Citation_Style_1/Archive_69#subject-link=_and_subject-mask=, I have gone through the list of supported name parameters.
In the parameter sets for |author=
, |contributor=
, |editor=
, |interviewer=
, |subject=
and |translator=
we generally support |-first=
, |-last=
, |-given=
, |-surname=
, |-link=
and |-mask=
variants and their enumerated forms. (Some combinations also exist in non-hyphenated variants for legacy support, see below.)
I noticed the following irregularities:
|interviewerlink=
and |interviewermask=
were unsupported and unused but were still listed as supported in the Whitelist.|author-/interviewer-/-given/-surname=
as well as their numbered variants were missing from the set.|display-subjects=
as an alias for |display-authors=
was missing from the set.I have therefore removed support for the first two parameters and added the missing variants, so that we now have a fully symmetrical list of name parameters, making it easier to document and use them without having to look up which exact variants are supported by which group. |subject=
is special as it (apparently deliberately?) does not support any of the |-first=
, |-last=
, |-given=
and |-surname=
variants. In addition to this, |author=
and |editor=
also support several non-hyphenated forms for legacy support, but it is good to know that at least |contributor=
, |interviewer=
, |subject=
and |translator=
are free of them now.
For the records, these non-hyphenated aliases are used only a few times and could be cleaned up and deprecated as well:
insource:/| *editor[0-9]*mask[0-9]* *=/
:
[2] (~96 -> 0)insource:/| *displayeditors *=/
:
[3] (137 -> 0)-- Matthiaspaul ( talk) 21:54, 10 September 2020 (UTC)
|nocat=
parameter (a parameter name unfortunately also used by various other templates in huge numbers, whereas the usage number in citation templates is probably very small)? I came up with insource:nocat insource:/\{\{ *[cC]it[ea][^|]*\|[^n]*nocat *=[^}]*}}/
[4] but this could still be fooled. --
Matthiaspaul (
talk) 21:00, 11 September 2020 (UTC)
name="mlvguh">{{cite Earth Impact DB |name= Wetumpka |accessdate =August 20, 2009 |no-tracking=1}}</ref>
. Upper bounds is probably in the realm of
1300. --
Izno (
talk) 01:08, 12 September 2020 (UTC)editor
-related parameters, only |editorlink=
(and enumerated variants) has a large number of hits at all, so we can deprecate the others:
name
-related parameters, only the group of author
-related parameters are using non-hyphenated parameter variants in really huge numbers any more (which, at least, is easy to remember) — too much to fix them up any time soon without bot assistance.author
-related parameters, only some of them are used:
|editor[0-9]link[0-9]=
, |author[0-9]mask[0-9]=
, and |displayauthors=
parameter aliases are already low enough to set these parameters to "deprecated" while continuing to fully support them (despite the deprecation maintenance message) for another year or however long it takes to reduce their numbers, so that editors will gradually switch them to their hyphenated forms when they edit the corresponding articles.|author[0-9]link[0-9]=
(non-hyphenated) as well, or would we first have to reduce the much higher usage numbers considerably?I am still seeing errors from {{
cite journal}} with |title=none
+ |doi-access=free
. I thought this was supposed to be fixed? An example (a book review headed by the name of the book it reviews without having its own separate title):
{{
cite journal}}
: CS1 maint: untitled periodical (
link)This one, if cited by itself, would not be too ridiculous to make up a fake title like "Magical Mathematics" (the title of the book it reviews). But when it is part of a bulleted list of 15 reviews, all of the same book, all given the same fake title, it just looks ridiculous. And if instead of making up something fake but plausible you copy what appears at the top of each review and pretend it's a title, you get monstrosities like (from a different review of the same book) "Featured Review: Magical Mathematics: The Mathematical Ideas That Animate Great Magic Tricks. By Persi Diaconis and Ron Graham. Princeton University Press, Princeton, NJ, 2012. $29.95. xiv+244pp, hardcover. ISBN 978-0-691-15164-9." So I prefer to omit them, which per WP:CITEVAR should be a perfectly acceptable citation style that the templates support. Adding a little lock icon to the doi shouldn't change anything about that.
To put it more bluntly, the autolinking RFC did not address citations with no title, and did not have consensus for imposing a new requirement that all journal citations list a title. Therefore, it should not have been implemented in a way that implicitly imposed such a requirement. — David Eppstein ( talk) 21:45, 20 September 2020 (UTC)
{{
cite journal}}
: CS1 maint: untitled periodical (
link)|authormask=
.) --
Izno (
talk) 02:22, 21 September 2020 (UTC)
{{
cite journal}}
: CS1 maint: untitled periodical (
link){{
cite journal}}
: CS1 maint: untitled periodical (
link)Hi, the CS1 templates support a debug feature to disable categorization. This is currently supported by five parameter aliases, which is overkill for such a rarely used feature:
|template-doc-demo=
[19] 0|no-cat=
[20] 0 (2 uses in non-citation templates)|nocat=
>=2
Paleocene
Alabama (>15k uses in non-citation templates)|no-tracking=
[21] 0|notracking=
[22] 0In our cleanup effort, I think, we should, in a first step, deprecate the unused parameter names |template-doc-demo=
, |no-tracking=
and |notracking=
, making |no-cat=
the canonical name and |nocat=
its alias, and - despite the name - put them in (only) a special hidden category to find out how many citation templates actually use this feature. I think, the number will be very low (perhaps a handful, at most a few dozens), but given the fact that the template uses the "generic" parameter name |nocat=
and that Cirrus search for this times out, we cannot find out easily.
Once knowing the citation templates using this feature and evaluating the reasons for its use, we might, in a second step, switch the parameter name to something unique (and thus easily searchable) but still more sensibly named than |template-doc-demo=
, perhaps |cite-no-cat=
(so that it can still be found if someone searches for a "no-cat" parameter), but ideally even something that fits into our naming scheme better: Perhaps it can be merged into |(cite-)mode=
or integrated into a new, more general debug parameter like |debug-mode=
, also controlling namespaces. This would be something to discuss in the next round.
If we support the (( accept-this-as-it-is)) syntax for more parameters (per Help_talk:Citation_Style_1#i18n_doi_inactive_categories, Help_talk:Citation_Style_1#Replacing_ignore-isbn-error=_and_doi-broken=_by_isbn/doi=((invalid-value))_syntax), we might even be able to eliminate some of the reasons for the feature's (ab)use in mainspace, thus reducing this again to a pure debug parameter.
-- Matthiaspaul ( talk) 08:56, 13 September 2020 (UTC)
|no-tracking=
to avoid being put into an "invalid DOI" error category (the DOI is oddly formed with a pending dot, but valid):
{{cite journal/new |last1=Belcher |first1=C. M. |title=Reigniting the Cretaceous-Palaeogene firestorm debate |journal=Geology |year=2009 |volume=37 |issue=12 |pages=1147–1148 |doi=10.1130/focus122009.1. |no-tracking=yes}}
→ Belcher, C. M. (2009). "Reigniting the Cretaceous-Palaeogene firestorm debate". Geology. 37 (12): 1147–1148.
doi:
10.1130/focus122009.1. {{
cite journal}}
: Check |doi=
value (
help)|doi=
parameter meanwhile supports our ((syntax)) to disable our validation check, this can be achieved without abusing |no-tracking=
now:
{{cite journal/new |last1=Belcher |first1=C. M. |title=Reigniting the Cretaceous-Palaeogene firestorm debate |journal=Geology |year=2009 |volume=37 |issue=12 |pages=1147–1148 |doi=((10.1130/focus122009.1.))}}
→ Belcher, C. M. (2009). "Reigniting the Cretaceous-Palaeogene firestorm debate". Geology. 37 (12): 1147–1148.
doi:
10.1130/focus122009.1.{{
cite journal}}
: CS1 maint: ignored DOI errors (
link)|notracking=
and |no-cat=
have been brought down to zero (switching them to |no-tracking=
for now, the most sensibly named one of the remaining aliases. Support for these parameter variants was disabled, and |no-tracking=
is now the canonical form.|nocat=
nightmare, we need a temporary tracking category. I would appreciate if Trappist could take care of this, as the code for this is a bit tricky and he is already familiar with it. I think it is important to have this in the forthcoming template update, so that we don't lose too much time until the next round.|no-tracking=
, at least the name is unique, but otherwise it's far from perfect. The jury is still open to find a parameter name better fitting into our parameter naming scheme...|nocat=
only? So:
{{cite book/new |title=Title |no-tracking=true}}
→ Title.{{cite book/new |title=Title |no-tracking=true}}
→ Title.|template-doc-demo=
has been eliminated as well now.|template doc demo=
parameter. They have been updated to accept |no-tracking=
as well now, but the following 80 occurences should be fixed up as well: insource:/\| *template +doc +demo *=/
[23].|nocat=
is {{
Citation error}}.|template-doc-demo=
and its aliases should be cleaned up and replaced by something with a more sensible name and possibly modified functionality. |template-doc-demo=
is about the most nightmarish parameter name I can think of. Although |no-tracking=
does not fit well into our parameter naming scheme either, it is a much more user-compatible parameter name. In the long run we should be able to come up with a better name, anyway.|nocat=
stuff after the next update, we should ask us the following questions:
Half the examples for
{{Cite press release}} put date=...
near the beginning and half at the end. I know order doesn't matter, but the inconsistency hurts comprehension. Thanks y'all! --
Skierpage (
talk) 23:21, 7 September 2020 (UTC)
Hi, invalid template parameters throw an error message (and optionally a hint) when they contain a value, but are ignored when empty.
While it is okay to leave (some) empty parameters in a citation in order to point editors to missing information, I think, unrecognized parameter names should always generate an error, regardless if they contain a value or not. -- Matthiaspaul ( talk) 09:24, 9 September 2020 (UTC)
if
statement that looks for a parameter value. When the parameter value is an empty string, the code goes on to the next parameter in the template. For unknown parameters without assigned values, we simply follow the currently non-existent else
where we do a quick check to see if the parameter name is in the whitelist; ignore when it is, error message when it isn't.|url-status=live
when it adds empty |archive-url=
and |archive-date=
. I would be in favor of including |url-status=
without |archive-url=
(|url-status=
requires |archive-url=
) as one of those errors that populate
Category:Pages with archiveurl citation errors (another category that needs a name change).|url-status=live
, I must admit that I typically add this as well when I add |url=
and |access-date=
. While I normally try to provide |archive-url=
and |archive-date=
at the same time, sometimes this is not possible because archive.org
is down again or refuses to archive a site. In my opinion |url-status=
semantically belongs to |url=
primarily, only secondarily to |archive-url=
. While removing |url-status=live
in absence of |archive-url=
is debatable (in a citation I favour explicit settings rather than relying on default assumptions, because the former work as kind of documentation and the latter can change over time), I have recently seen a bot (IIRC it was GreenC Bot) removing |url-status=dead
in absence of |archive-url=
as well - this is annoying and clearly a bot error, because, if a URL goes dead or gets usurped by something else, this is a condition that should be recorded in |url-status=dead
even if no |archive-url=
is available (and in some cases there may not even be an alternative |url=
available). If this would be put into an error category, I can already see some careless editor or bot coming around removing the citation completely (although the document once was available and verified per |access-date=
). Therefore, we shouldn't remove |url-status=
and don't issue errors on this.{{cite book/new |title=Title |blue= |editors= |author=}}
{{cite book/new |title=Title |editors=Editors}}
{{cite book/new |title=Title |blue= ||author=}}
{{cite book/new |title=Title |blue= | |author=}}
Take a look at
Special:Diff/979504621 -- it looks like
PROVEIT is automatically placing the |url=
parameter after the author and name fields in {{
cite web}}. But on the documentation for that template, the provided formats all put that field first. It doesn't really matter to me either way, but it seems a little silly for the parameters to have two different canonical orderings. Anyone capable of shedding some light on this?
{
} 05:41, 21 September 2020 (UTC)
|url=
as the semantically most important parameter in the specific template context, whereas Provelt orders according to most common index fields. I consider this more of a cosmetic difference. I am not sure that dictating a canonical order to editors adds value. The required parameters are signaled. The software formatting can handle the rest.
64.18.9.222 (
talk) 11:05, 21 September 2020 (UTC)
In the past, a lot academic journals printed articles in different languages even in the same volume. The |language=
indicator of {{
cite journal}} should thus be article-specific, not journal-specific. By that I mean instead of
it should be
This suggestion is actually related to a similar one I made in May regarding the language indicator placement in {{ cite book}}. -- bender235 ( talk) 15:48, 24 September 2020 (UTC)
|language=
normally indicates the language of the work, but not necessarily that of |title=
because if the original language title is not known, |title=
(rather than |trans-title=
) may contain the translated (here typically: English) title. But what, if |script-title=
is used as well and its language prefix indicates a different language from |language=
? Assuming that noone would go through the hurdles of writing a title in a non-Latin script if the work would not be in this very language as well, shouldn't the prefix language be considered the more accurate info and override the language provided by the |language=
parameter? And, wouldn't it be possible that, if both are present and different, |language=
actually was meant to apply to the journal/book as a whole (based on its display position) rather than the article/chapter? Should we display two "(in language)" then?Only a minor point, and even one that would require a few hours work to clean up existing citations, so no priority, but in the long-run attempt to improve the consistency of the parameter interface of the citation templates and, where reasonably possible, reduce the number of parameters by making some of the existing parameters "smarter", I think, the |ignore-isbn-error=true
parameter (and its alias |ignoreisbnerror=true
) would be a good candidate to be replaced by adding support for the double-parentheses-syntax to
((accept this value as it is)) in the |isbn=
parameter.
For a long while, when I occasionally ran into "valid invalid" ISBNs, it always took me quite some time to look up the exact parameter name to disable the ISBN validation check because |ignore-isbn-error=true
was almost undocumented (meanwhile it can be found listed nearby the documentation for |isbn=
, so is easy to find).
Things would have been easier, if the template would have supported the ((syntax)) instead of using a separate parameter for this.
While this syntax is a bit cumbersome in itself (it needs to be), once you learn about it and have realized that this is a generic escape method used in various places to let the template accept parameter values it otherwise would not for some (normally but not in this particular case valid) reason, it becomes only natural to also try it when running into invalid |isbn=
values - only to find out that it is not supported there.
So, for consistency, it should be supported there as well, and the |ignore-isbn-error=
parameter be deprecated after existing citations have been adjusted accordingly (possibly by a bot).
(There are other cases, where the ((syntax)) should be supported as well (but still isn't), e.g. we recently had a discussion about quarters in |date=
, where it was recommended as a breakout as well, see
Help talk:Citation Style 1/Archive 68#Needs exception for unusual-format dates (2). The idea there was ((to reluctantly accept the input)) to not frustrate and block the editor in his/her endeavour to improve the encyclopedia, but to put such escaped forms into a maintenance category for evaluation in order to detect missing template functionality and for possibly necessary post-processing.)
-- Matthiaspaul ( talk) 10:30, 10 August 2020 (UTC)
Followup: |doi-broken=
/|doi-broken-date=
/|doi-inactive-date=
would be other candidates. While these and the |ignore-isbn-error=
parameter are reasonably named as is, they don't follow some overarching naming scheme and therefore are difficult to remember (and, as a consequence, need to be looked up whenever needed). It would be much more consistent and easier to remember if |doi=
would accept the ((syntax)) as well for such invalid DOIs.
-- Matthiaspaul ( talk) 10:39, 10 August 2020 (UTC)
|ignore-isbn-error=
has been set to "deprecated", and the remaining < 300 uses (
[25]) can be easily switched to use the ((accept-this-as-is)) syntax manually as soon as the template goes live, so that support for that parameter can be disabled in the subsequent update.
{{cite book/new |title=Title |author=Author |isbn=0-7506-4588-2}}
→ Author. Title.
ISBN
0-7506-4588-2. {{
cite book}}
: |author=
has generic name (
help); Check |isbn=
value: checksum (
help){{cite book/new |title=Title |author=Author |isbn=0-7506-4588-2 |ignore-isbn-error=yes}}
→ Author. Title.
ISBN
0-7506-4588-2. {{
cite book}}
: |author=
has generic name (
help); Check |isbn=
value: checksum (
help); Unknown parameter |ignore-isbn-error=
ignored (|isbn=
suggested) (
help){{cite book/new |title=Title |author=Author |isbn=((0-7506-4588-2))}}
→ Author. Title.
ISBN
0-7506-4588-2. {{
cite book}}
: |author=
has generic name (
help)CS1 maint: ignored ISBN errors (
link){{cite journal/new |title=Title |author=Author |journal=Journal |issn=0028-0836}}
→ Author. Title.
ISSN
0028-0836. {{
cite book}}
: |author=
has generic name (
help); |journal=
ignored (
help) (valid ISSN){{cite journal/new |title=Title |author=Author |journal=Journal |issn=1028-0836}}
→ Author. Title.
ISSN
1028-0836. {{
cite book}}
: |author=
has generic name (
help); |journal=
ignored (
help); Check |issn=
value (
help) (invalid ISSN){{cite journal/new |title=Title |author=Author |journal=Journal |issn=((1028-0836))}}
→ Author. Title.
ISSN
1028-0836. {{
cite book}}
: |author=
has generic name (
help); |journal=
ignored (
help)CS1 maint: ignored ISSN errors (
link) (ignored invalid ISSN)has_accept_as_written()
in
Module:Citation/CS1/Utilities/sandbox and used it in
Module:Citation/CS1/Identifiers/sandbox to replace v, count_accept = v:gsub ('^%(%((.*)%)%)$', '%1');
.Further researching possible options for
my proposal to streamline override options for ISBN and DOI error handling, I was going through the list of currently supported parameter aliases and I found that |ignoreisbnerror=
is actually unused. Given that, according to
this thread, we don't want to introduce new non-hyphenated parameter aliases any more and keep the existing non-hyphenated variants only for legacy support, I don't think it makes any sense to keep support for non-hyphenated parameter aliases if they are unused, in particular if they belong to such rarely used features. Therefore, I want to deprecate the |ignoreisbnerror=
alias.
Likewise, I was curious about the usage statistics of the many aliases parameter names for a small feature such as the DOI error override and found |doi-inactive-date=
to be used only as an empty parameter, apparently from copying empty templates into articles - meanwhile removed. Astonishingly, there were also a few live occurences of empty template parameters |doi-inactive=
/|doiinactive=
/|doibroken=
, although these are not supported as actual parameters by the templates (perhaps they were in the past and have never been cleaned up - done now).
There were three occurences of |doi-broken=
actually being used, which I switched to use |doi-broken-date=
instead, so that we are free to fade out |doi-broken=
as well.
Removing support for these aliases we'd end up with the two canonical parameter forms |ignore-isbn-error=
and |doi-broken-date=
only.
-- Matthiaspaul ( talk) 14:51, 6 September 2020 (UTC)
|ignore-isbn-error=
and |ignoreisbnerror=
are not new but were simultaneously introduced in April 2013 (
this edit) – that was before the
RfC that established our preference for hyphenated parameter names. Still, I, for one, do not object to deprecation and removal of little-used non-hyphenated parameter names.|doi-broken=
should be deprecated and removed because that parameter requires a date so its name should declare that. In the sandbox I have made |doi-broken-date=
the canonical parameter name. Similarly, |embargo=
should be deprecated and replaced with |embargo-date=
.|embargo=
in use, and in all of these cases the parameter value was empty - therefore I cleaned them up. I support the switch to |embargo-date=
or even better |pmc-embargo-date=
given that the parameter applies only to PMCs.|ignoreisbnerror=
, |doi-broken=
, |embargo=
, and ... ? You didn't mention |doi-inactive-date=
, which I think we can deprecate as well - it's not used. I don't see a reason why we would need to support |doi-broken-date=
and |doi-inactive-date=
in parallel, or are these two different use cases which might need to be distinguished in the future?|doi-status=dead
or even
eliminate it completely by using our special syntax as in |doi=((invalid-number))
.{{cite book/new |title=Title |author=Author |isbn=0-7506-4588-2 |ignore-isbn-error=yes |doi=10.1007/978-3-642-86187 |doi-broken-date=2020-08-30 |pmc=7135076 |pmc-embargo-date=2020-12-31}}
→ Author. Title.
doi:
10.1007/978-3-642-86187 (inactive 2020-08-30).
ISBN
0-7506-4588-2.
PMC
7135076. {{
cite book}}
: |author=
has generic name (
help); Check |isbn=
value: checksum (
help); Unknown parameter |ignore-isbn-error=
ignored (|isbn=
suggested) (
help)CS1 maint: DOI inactive as of August 2020 (
link) CS1 maint: PMC embargo expired (
link)|doi-broken=
(3× uses that you changed to |doi-broken-date=
so we are free to fade out |doi-broken=
) I have removed |chapter-doi=
and |title-doi=
as unused and unsupported from ~/Configuration/sandbox, ~/Whitelist/sandbox, ~/Suggestions/sandbox. Did I miss any? If / when there is support for these parameters, that is the time to introduce them; we should not speculatively add parameters.Hi, I feel like I remember a parameter trans-quote for translated quotes from citations in foreign languages. Am I remembering incorrectly, or has this been removed? Thanks, Ezhao02 ( talk) 13:31, 5 August 2020 (UTC)
|quote=
is a free-form parameter so you can include translations in it if you would like. Better in my mind, if the quoted material is important to the article, put that material in the article, translate it there and cite both; don't clutter the references section with quotations.|script-quote=
) in the past. While Trappist is right that |quote=
is a free-form parameter so you can add your own formatting, it would be desirable to have a consistent style centrally maintained instead of every editor having to invent his own conventions for this. Therefore, such a parameter is desirable. --
Matthiaspaul (
talk) 12:03, 8 August 2020 (UTC)In the absence of such a parameter, I prefer to format foreign-language quotations like this: "Lorem ipsum dolor sit amet. [This is a nonsensical example sentence.]" Glades12 ( talk) 13:18, 4 September 2020 (UTC)
{{cite book/new |editor-first=Diogenes |editor-last=Laertius |editor-link=Diogenes Laertius |title=On Plato's Apology of Socrates |title-link=I know that I know nothing |quote-pages=5 |quote=Εn oîda óti oudèn oîda. |script-quote=el:Ἓν οἶδα ὅτι οὐδὲν οἶδα. |trans-quote=I know that I know nothing.}}
→Εn oîda óti oudèn oîda.Ἓν οἶδα ὅτι οὐδὲν οἶδα. [I know that I know nothing.]
I would also [include the
many variants of expressing "No title" and] add support for a special token like "no-title" to indicate this condition; so, |title=none
would mute the display of a title, whereas |title=no-title
would display the descriptive title "[No title]" instead. (Well, if |title=none
would not be an established case already, I would recommend |title=off
for this instead, so that |title=none
would be free to display the "[No title]" message.) While these conditions are more likely to occur in newspapers and journals, the tokens should work in all cite variants, not only some of them (as "none" does at present). This would also simplify the code and documentation.
This way, we would improve consistency across the project, keep editors from inventing their own ways to express this special condition, and enable us to centrally update the message if this would become necessary in the future (e.g. due to a MOS change).
Which brings up another related topic: While the "no title" condition should IMO be a tokenized special case, I think, we should also have a dedicated parameter to enter other so called descriptive titles. (Descriptive titles are titles provided by the editor of a citation which differ from the actual title (if one exists) given by the author of the work. They are used in cases where the actual title is unsuitable to be reproduced in a citation for some reason (like being completely misleading, too long, historical alias names, non-existent etc.).)
We could use something like |desc-title=
, |descriptive-title=
, |description-title=
or just |description=
to distinguish them from actual titles. APA recommends to put descriptive titles in square brackets, some other style guides recommend to just write them without any text decoration (including without quotes)). See also:
It could be useful to treat them differently (or even to suppress them) in meta-data, so that descriptive titles don't end up polluting databases without any means to tell them apart from actual titles.
The handling of descriptive titles could be somewhat similar to how we treat |trans-title=
already, which reminds me of another related topic that |trans-title=
should also work without |title=
(instead of throwing an error), so that editors don't have to stuff translated titles into |title=
(if the original-language title is not known) causing readers to assume these were the actual titles of a work and thereby causing confusion when trying to locate the work. See
Help_talk:Citation_Style_1/Archive_67#Possible_improved_treatment_of_title_parameters_and_language_attributes
Both features, tokenizing the "no title" condition and adding some means to enter descriptive titles differently were requested by several editors in the past already.
-- Matthiaspaul ( talk) 16:37, 4 September 2020 (UTC)
Hi. Non-abbreviated year ranges are our preferred format for year ranges and there is certainly no particular need to support abbreviated year ranges in citations (except for if we can) - they could certainly be written in non-abbreviated form as well. Year ranges are comparably rare in citations, even more so abbreviated ones, as in most cases the publication date specifies a specific point in time rather than a span. I have seen less than a handful of abbreviated year ranges in citations in all those years.
On the other hand, incomplete dates consisting of only the month and the year and no day are very common in citations (I see them every day), but in the case of the ymd date format, the form "yyyy-mm" is disallowed in order to avoid a possible confusion with "yyyy–yy". Since the EDTF form "yyyy-mm-XX" is not currently supported as well (would be useful at least on source code level, not for display), this leads to such dates being rewritten as "Month yyyy", which unnecessarily creates inconsistency when all the other dates in the citations are given in ymd format.
Hence, it is reasonable to swap this around and fade out and ultimately disallow abbreviated year ranges in the |date=
parameter of citations at some point in the future (only there, not elsewhere where they are still allowed, including e.g. in |title=
, |chapter=
, or |quote=
parameters), so that, at some further point in the future, we can officially allow "yyyy-mm" in citations already using the ymd format. (In order to keep the change as minimal as possible, this is meant to affect only citations, not dates in tables or in the article body.)
In order to get a grip on how many citations actually have dates formatted this way at all, I would appreciate a tracking/maintenance category for citations using any detectable form of abbreviated year range (but at least the "yyyy–yy" form). -- Matthiaspaul ( talk) 13:19, 9 August 2020 (UTC)
{{
citation}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
citation}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
citation}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
citation}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
citation}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
citation}}
: Check date values in: |date=
(
help) (error in CS1){{
citation}}
: CS1 maint: date format (
link) (maintenance message in CS1)|date=
parameter into a dedicated maintenance category for further evaluation. The request is not to check the current implementation to be in sync and to be compliant with the MOS, nor is it to throw any additional error messages. The question I hope to be able to answer is the extent to which such abbreviated year ranges are used in citations at present (although I already assume them to be rarely used), and if there is anything special about the articles using such citations.insource:/| *date *= *[0-9]{3,4} *[-–] *[0-9]{1,2} *[|}]/
" as a search pattern, which, however, times out, therefore does not give accurate figures). At this stage, this does not need to be 100% exact math, although someone reading my intentions for this request above and being familiar with the actual implementation would probably be able to nail it down with precision right from the start.|publication-date=
and |year=
parameters in addition to those in |date=
.|date=
, |year=
or |publication-date=
parameter will now be indicated by an optional maint message and put into new category "Category:CS1 maint: abbreviated year range" for further evaluation:It looks like the code may need refinement.
{{
cite book}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
cite book}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
cite book}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
cite book}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1){{
cite book}}
: Check date values in: |date=
(
help) (invalid per MOS, error in CS1)Case 4 is incorrectly marked with a maintenance message. Case 7 already fails the date check, so it does not need a maintenance message. – Jonesey95 ( talk) 00:09, 20 September 2020 (UTC)
|date=
, |year=
, and |publication-date=
). Your cases 1, 4 and 7 are actually those cases I am looking for, as detailed further above. The behaviour of the existing date validation code was deliberately not changed. --
Matthiaspaul (
talk) 00:28, 20 September 2020 (UTC)
add_prop_cat()
from
Module:Citation/CS1/sandbox to
Module:Citation/CS1/Utilities/sandbox.|orig-date=
). In rare cases, the publisher's data actually specified a year range, in those cases mostly for consecutive years.The RfC on title-linking was concluded yesterday. A related WP:AN discussion is still open. I'd like to prepare updates that will be necessary to Template:Citation Style documentation, including its id2 subtemplate, to make it conform to the outcome of the RfC. Thoughts? Or is it best to wait until the AN thread is closed? -- Francis Schonken ( talk) 13:25, 20 September 2020 (UTC)
(my emphasis). The RfC close contains:When an URL is equivalent to the link produced by the corresponding identifier (such as a DOI), don't add it to any URL parameter but use the appropriate identifier parameter, ...
There is consensus against removing a parameter just because it is a duplicate.
|url=
parameter or title link can then be used for its prime purpose of providing a
convenience link to a
free-to-read copy of the source that would not otherwise be obviously accessible|url=
value (like
[31]) when a |doi=
(pointing to
[32]) is present. (In the given recent example, CitationBot also removed the |archive-url=
alongside the |url=
, thereby causing even more damage.) As I pointed out in the RfC, the terms "equivalent", "redundant" and even "duplicate" are apparently not clear enough to transfer the message unmistakably, therefore the wording should be actually changed to "exactly the same" or "identical".|url-access=
(and |url-status=
and |access-date=
) to specify the access status of |url=
just like we have |doi-access=
(and |doi-broken-date=
) for |doi=
etc. Also, while DOIs are designed to be long-living, they are not necessarily longer living than URLs. I have seen citations with broken URL and working DOI but also vice versa. So, the key against link rot is redundancy through archives and alternative links. As this is not actually relevant for template documentation purpose, we could either correct the statement or remove the sentence completely.|url=
is not to provide a free-to-read copy of the source, but to point to the cited document, regardless if it is free or not. This doesn't rule out free documents, which are always nice to have, of course, but the notion that |url=
was only for free documents crept further elsewhere and was (ab)used by some editors as an argument to remove |url=
parameters from citations as well.|url=
to exist, therefore this could be reduced to something like "The |url= parameter [...] can then be used for other purposes." or be removed completely.|url=
can be considered unnecessary, if exactly the same link can also be established via auto-linking of one of the provided identifiers in a citation, but the condition really is "exactly the same" and not "similar" or "equivalent". (Only) under this specific condition removal of |url=
would have zero effect on how a citation looks like and functions on user level, and therefore could be considered harmless, if not even beneficial (cleaner and easier to maintain citation code).)|url=none/(title-)doi/pmc/<other-identifier-parameter-name>/<url>
/|chapter-url=none/(chapter-)doi/pmc/<other-identifier-parameter-name>/<url>
only to (again) switch to use |title-link=none/doi/pmc/<other-identifier-parameter-name>/<link>
instead in
Help_talk:Citation_Style_1/Archive_70#Towards_solving_pending_issues_of_the_auto-link_feature.... Despite Pintoch's negative opinion on this, other users (proponents as well as editors opposing auto-linking in general) including Trappist the monk, Headbomb, Nardog, David Eppstein, myself and others have repeatedly asked over the years that auto-linking, if implemented, should have such a control. I won't go as far as to request for the setting "none" to become the default, still I think, also in the light of the outcome of this new RfC, that this facility should be implemented ASAP (ideally before the next update) to finally settle the case (so that future enhancements of auto-linking, some of which have been requested already, can be based on a solid implementation). --
Matthiaspaul (
talk) 11:21, 22 September 2020 (UTC)
I propose moving |format=
content so that it is positioned after title and not after text "Archived from the original". --
5.43.72.55 (
talk) 19:50, 27 September 2020 (UTC)
For a while now I have intended to begin the live-module update process. Whenever I got myself ready to do that, someone changed something so I put it off.
It is time to freeze changes to the module suite sandboxen so that we can update the live modules. Finish what you are doing this weekend. No changes after Sunday except to fix something that is obviously broken. Next weekend we can announce an update for 10–11 October 2020.
— Trappist the monk ( talk) 16:10, 26 September 2020 (UTC)
As extensively discussed in the past months, a manual override facility has now been implemented for the auto-linking feature.
For this, |title-link=
now supports a number of additional keywords: none
, pmc
, doi
. They can be used to manually select one of the identifiers enabled for auto-linking (currently only PMCs and DOIs) or to completely disable auto-linking. Any values not matching one of these keywords will be interpreted as link target to a Wikipedia page (or one of its sister projects), as before. If such a link target would clash with one of the keywords, the
((accept-this-as-is)) syntax can be used to enforce the interpretation as a link target.
Auto-linking is also disabled if the display of the title has been disabled by |title=off
(currently also still |title=none
), whereas it remains enabled for descriptive titles (including the "No title" case, which can be specified by |title=none
in the future).
If the |title-link=
parameter is left empty and no |url=
is specified, the template will automatically select an identifier for auto-linking, whereby the current priorities will let PMCs take precedence over DOIs, assuming both to be valid and active. Invalid or embargoed PMCs as well as non-free, inactive or invalid DOIs will be ignored in this selection. To play it safe, the present implementation also ignores "invalid" DOIs accepted using the accept-this-as-is syntax - after all, auto-linking is a non-essential feature and the identifier link is always available through the normal identifier link as well.
At present, auto-linking is only enabled for {{ cite journal}}, but it could be generalized to be supported by other cite templates as well (as was requested already).
The list of supported identifiers can be extended in the future (also already requested), but I recommend that only manual auto-linking will be used for a larger list of identifiers, unless the identifier will have a similar "prominence" as DOIs or PMCs. Otherwise, the priority-based auto-selection may appear "arbitrary" to readers.
Another possible future extension (also already requested) would be to allow auto-linking of chapters in addition to titles.
See also:
Some examples:
Extended content
|
---|
|
-- Matthiaspaul ( talk) 18:51, 27 September 2020 (UTC) (updated 14:45, 30 September 2020 (UTC))
Extended content
|
---|
|
|title-link=
instead of embedding the link into |title=
itself, this is not blocking a release.|auto-link=
or |auto-url=
(both originally suggested by Headbomb), and two overloading existing parameters, |url=
(originally suggested by
Trappist the monk,
Nardog and me) and |title-link=
(also suggested by me, but Trappist also noted sympathies for this). Headbomb's proposal would have added a new parameter and the names suggested so far did not fit into our naming scheme well, but he was generally open to other parameter names and implementations. When requests regarding auto-linking of chapters came up, I abandoned my |title-link=
proposal in favour to Trappist's because it appeared slightly more flexible in the long run, but switched back to |title-link=
to address your concerns that overloading |url=
might cause problems with external scripts needing to be updated. In the post above I gave links to some of the past discussions regarding this.|url=doi/pmc/jstor/etc/none
/ |chapter-url=doi/pmc/jstor/etc/none
. If you want an example where a link is not desired, title-less journal citations would be the go-to example.
{{
cite journal}}
: CS1 maint: untitled periodical (
link)|url=
and |title-link=
proposals code-wise, I have come the conclusion that the latter was even easier to implement. (I have a solution for the chapter link issue also for |title-link=
but this will need more discussion, therefore it's not included at this time.)|title-link=
is a terrible use for this because it is overwhelmingly used for links to Wikipedia and sister projects like Wikisource. This replaces URL, so it should use the URL parameters. Difficulty of implementation matters a whole lot less than ease of use (|url=
is both much shorter to type than |title-link=
, and guarantees there is no conflicting url/title-link like someone adding |url=
https://example.com
to a citation with |title-link=doi
.
Headbomb {
t ·
c ·
p ·
b} 19:30, 1 October 2020 (UTC)
|title-link=
is "terrible", I see your point (that's why I proposed |url=
for a long while as well ;-). Also, I specifically agree with that difficulty of implementation does not matter (we should always strive for the best-possible solution for users, no matter if it is difficult to code or not). Among the cons for |url=
is that bots reading citations might be confused if they find something like "doi" in this prominent parameter, whereas it is very unlikely that they care about the value of an "inward-bound" parameter such as |title-link=
. Among the pros for |title-link=
is that something like |title-link=doi
or |title-link=none
is semantically much more to the point than |url=doi
or |url=none
. An the argument of states being mutually excluded by the underlying parameter logic applies to both parameters as well, just that |url=
is probably more commonly used than |title-link=
. I was (and still are) open to both, but now slightly favour |title-link=
. Functionality-wise, both solutions are equivalent. --
Matthiaspaul (
talk) 20:06, 1 October 2020 (UTC)|url=
is that bots reading citations might be confused if they find something like "doi" in this prominent parameter, whereas it is very unlikely that they care about the value of an "inward-bound" parameter such as |title-link=
.{{cite web|url=htp:s//example.com|title=Title}}
. There are tons of those in
Category:Pages with URL errors. Most such tools or bots already correctly handle such errors either by failing, or by not touching |url=
because they don't know what to do with it. Using the existing parameter |url=
/|chapter-url=
/|contribution-url=
/|foobar-url=
greatly reduced complexity for users, who then don't need to learn the arcane |title-link/chapter-link/contribution-link=
and wrap their heads around why a -url
parameter is renamed -link
.
Headbomb {
t ·
c ·
p ·
b} 20:32, 1 October 2020 (UTC)I propose to update cs1|2 module suite over the weekend 10–11 October 2020. Here are the changes:
|editors=
parameter;
discussion|<name>-link=
and |<name>-mask=
interaction;
discussion|orig-date=
preferred over |orig-year=
, change metaparameters;
discussion<module>.<function>()
calls to avoid upvalue limit;
discussionadd_prop_cat()
to
Module:Citation/CS1/Utilities/sandbox;
discussion|title=
;
discussion|trans-quote=
, |script-quote=
, |page(s)-quote=
;
discussion|last-author-amp=
;
discussionModule:Citation/CS1/Configuration
|editors=
parameter|subject-mask=
parameters;
discussion|orig-date=
;
discussion|series-separator=
;
discussion|ignoreisbnerror=
, |doi-broken=
, |doi-inactive-date=
and rename |embargo=
to |pmc-embargo-date=
;
discussion|author-given#=
, |author#-given=
, |author-surname#=
, |author#-surname=
, |interviewer-given#=
, |interviewer#-given=
, |interviewer-surname#=
, |interviewer#-surname=
, |display-subjects=
;
discussion|displayeditors=
, |editormask=
and enumerated forms;
discussion|notracking=
and |no-cat=
, made |no-tracking=
the canonical form for now;
discussion|title=
;
discussion,
discussion|trans-quote=
, |script-quote=
, |page(s)-quote=
|name-list-style=
as preferred alias of |name-list-format=
;
discussion|editors=
parameter|subject-mask=
parameters; deprecate non-hyphenated subjectlink params;
discussion|orig-date=
|series-separator=
|ignoreisbnerror=
, |doi-broken=
, |doi-inactive-date=
and rename |embargo=
to |pmc-embargo-date=
|interviewerlink=
and |interviewermask=
; add support for missing aliases |author-given=
, |author-surname=
, |author-given#=
, |author#-given=
, |author-surname#=
, |author#-surname=
, |interviewer-given#=
, |interviewer#-given=
, |interviewer-surname#=
, |interviewer#-surname=
, |display-subjects=
;
discussion|transcript=
, |transcript-format=
, |transcripturl=
,|transcript-url=
, and |inset=
to unique arguments table;
discussion|mailinglist=
, |mailing-list=
to unique arguments table;
discussion|displayeditors=
, |editormask=
and enumerated forms;
discussion|displayauthors=
as well as |editorlink=
, |authormask=
and enumerated forms;
discussion|ignore-isbn-error=
;
discussion
discussion|notracking=
and |no-cat=
, made |no-tracking=
the canonical form for now|trans-quote=
, |script-quote=
, |page(s)-quote=
|name-list-style=
as preferred alias of |name-list-format=
|last-author-amp=
Module:Citation/CS1/Date validation
Module:Citation/CS1/Identifiers
|doi=
& |pmc=
when embargoed, broken, or fail validation; convert inactive doi categories to proper maint cats;
discussion|doi=
, |eissn=
, |isbn=
, |issn=
, |sbn=
;
discussion
discussion,
discussionModule:Citation/CS1/styles.css
Module:Citation/CS1/Suggestions
|orig-date=
instead of |orig-year=
parameter;
discussion|ignoreisbnerror=
, |doi-broken=
, |doi-inactive-date=
and |embargo=
;
discussion and
discussion|interviewerlink=
and |interviewermask=
;
discussion|eprint=
, |inset=
, |network=
, |newsgroup=
, |newspaper=
, |postscript=
, |surname=
, |transcript=
, |vauthors=
, |veditors=
)|authorfirst=
, |authorlast=
, |authorgiven=
|authorsurname=
, |displayeditors=
, |editorfirst=
, |editorlast=
, |editorgiven=
, |editorsurname=
, |editormask=
and enumerated variants;
discussion and
discussion|laysummary=
and |lay-summary=
.|forename=
and |family=
due to our support for given/surname instead of given/family and forename/surname|notracking=
and |no-cat=
;
discussion—
Trappist the monk (
talk) 10:18, 3 October 2020 (UTC) 10:42, 4 October 2020 (UTC) (+empty unknowns) 14:04, 4 October 2020 (UTC) (+|last-author-amp=
) 15:07, 5 October 2020 (UTC) (+interwiki link check)
Wikitext | {{cite book
|
---|---|
Live | Smith, Harvey Jnr. Title. {{
cite book}} : Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (
help)
|
Sandbox | Smith, Harvey Jnr. Title. {{
cite book}} : Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (
help)
|
* "error messaging for 'Wayback Machine' and other generic titles" .. this one will probably generate community discussion due to the volume of red messages. Possible outcomes include:
|title=no-title
will come up and people will begin using no-title in some automated fashion to squelch errors. Then we don't know what is a legit no-title versus one that was a generic title needing filling in.Once it becomes a general VP/community issue developers can loose control of what they think is best due to RfC outcomes. if we are lucky that won't happen but given the scale of red errors it's a real possibility. There are also the other stakeholders involved IABot, Citation bot, WaybackMedic, Refill and others. Personally of the opinion we should try and reduce cases before adding red errors, or at least announce the intention and give the community some time (6 months etc) to respond. -- Green C 17:03, 3 October 2020 (UTC)
cs1|2 does not support 'dynamic' error category names. It could, because we create some maintenance category names dynamically, it just doesn't because there has been no need.
In this case there is no need for five separate error categories when one will be sufficient. So, I have tweaked the code so that these errors will all be listed in the single category: Category:CS1 errors: display-names.
— Trappist the monk ( talk) 18:33, 5 October 2020 (UTC)
Would it be possible to add a "Revised by" parameter for Template:Cite encyclopedia? I'm speaking specifically of using it for Grove articles, such as this one, where having the person who revised the article as the second author wouldn't make sense (because they didn't add the bulk of the article) and having them as the editor wouldn't either (because they aren't the editor of the encyclopedia as a whole, which is how it would display). Aza24 ( talk) 18:34, 5 October 2020 (UTC)
|others=
is useful for edge cases like this. –
Jonesey95 (
talk) 21:06, 5 October 2020 (UTC)|others=
. I don't think cases with sources that name their revisors are common enough to make an entirely new parameter worthwhile.
Glades12 (
talk) 18:40, 6 October 2020 (UTC)
I must have missed the discussion/rationale for replacing the parameter labels p and pp, with page and pages respectively, in {{cite xxx}} templates. Can you please point me to the relevant section(s)? Thanks. I just noticed Citation Bot making the related edits. 98.0.246.242 ( talk) 22:44, 5 October 2020 (UTC)
|p=
with |page=
and |pp=
with |pages=
then you should take that up at
User:Citation bot. All four of those parameters are legitimate aliases; |page=
and |pages=
are the canonical forms.|p=
and |pp=
. The edit that appears to make aliases of |p=
and |page=
and of |pp=
and |pages=
is
this edit. Was that discussed? Don't know. You might troll through the archives of this page and the
Module talk:Citation/CS1 archives to see if it was discussed.