Misplaced Pages

Help talk:Citation Style 1: Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 15:36, 24 August 2020 editFrancis Schonken (talk | contribs)Extended confirmed users68,468 edits →Citation Style documentation/id2: rply to nemo← Previous edit Latest revision as of 15:39, 24 December 2024 edit undoDaask (talk | contribs)Autopatrolled, Extended confirmed users, New page reviewers, Pending changes reviewers31,526 edits →cite episode id parameter silently ignored: ReplyTag: Reply 
Line 1: Line 1:
<!-- Deny citation bot April 2015 because we often post broken citations here intentionally and do not want them to be "fixed" -->{{bots|deny=Citation bot,SporkBot}}<!-- <!-- Deny citation bot April 2015 because we often post broken citations here intentionally and do not want them to be "fixed". To avoid AnomieBOT substing, use |demo= or |nosubst= instead of adding it here. -->{{bots|deny=Citation bot,SporkBot,Cewbot}}<!--
-->{{skip to bottom}}<!--
-->{{central|text=the talk pages for all Citation Style 1 templates and modules redirect here. A list of those talk pages and their historical archives can be found at ].}}
{{talk header|display_title=Help:Citation Citation Style 1 and the CS1 templates|WT:CS1}} -->{{talk header|display_title=Help:Citation Style 1 and the CS1 templates|WT:CS1}}
{{central|text=the talk pages for all Citation Style 1 and Citation Style 2 templates and modules redirect here. A list of those talk pages and their historical archives can be found ].}}
{{WPBS|1=
{{WikiProject banner shell|collapsed=yes|1=
{{Misplaced Pages Help Project|class=B|importance=High}}
{{Misplaced Pages Help Project|importance=High}}
{{WikiProject Academic Journals}} {{WikiProject Academic Journals}}
{{WikiProject Magazines}} {{WikiProject Magazines}}
Line 10: Line 11:
|archiveprefix=Help talk:Citation Style 1/Archive |archiveprefix=Help talk:Citation Style 1/Archive
|format= %%i |format= %%i
|age=720 |age=480
|header={{Talk archive}} |header={{Automatic archive navigator}}
|headerlevel=2 |headerlevel=2
|maxarchsize=200000 |maxarchsize=200000
|minkeepthreads=2 |minkeepthreads=6
|numberstart=69 |numberstart=69
|minarchthreads=1 |minarchthreads=2
}} }}
{{Banner holder|collapsed=yes|
{{tmbox {{tmbox
| type = notice | type = notice
Line 25: Line 27:
*"'''Withdrawn'''" proposal to merge ] with ] on March 2, 2018, see ]. *"'''Withdrawn'''" proposal to merge ] with ] on March 2, 2018, see ].
}} }}
{{Auto archiving notice |bot=ClueBot III |age=30 |units=days }}
{|style=width:100%
|-
| style="vertical-align: top;" |
__TOC__
|style="text-align:right; vertical-align: top;"|
{{Multiple image
| direction = vertical
| header = Citation templates
| width = 250
| image1 = Rube Goldbergian music machine at COSI Toledo.JPG
| image2 = Rube goldberg machine.jpg
| caption1 = ... in conception
| caption2 = ... and in reality
}} }}
{{FAQ|page=Help talk:Citation Style 1/FAQ}}
|-
|}


== Internet archive print disability book links ==
== Auto-linking titles with free DOIs ==
{{collapse top}}
Hi all,


There are a number of links to books which have since lost their accessibility to the general public on Internet Archive (e.g., and of the same book). These are now " available to patrons with print disabilities."
I would like to propose extending the auto-linking mechanism (providing a default value for {{para|url}} when {{para|pmc}} is available) to also cover {{para|doi}} with {{para|doi-access|free}}.


Should the links like these which are ''not'' accessible to users ''without'' print disabilities be removed, or would it be possible to add another <code>|url-access</code> parameter to signify this? ] (]) 20:48, 28 November 2024 (UTC)
In short: if {{para|url}}, {{para|chapter-url}} and {{para|pmc}} are not set, but {{para|doi}} and {{para|doi-access|free}} are set, the title of the citation would be linked using the DOI.


:Alternatively (as with {{tlx|Hopcroft and Ullman 1979}}) should the link be appended to a reference a note? ] (]) 01:33, 29 November 2024 (UTC)
====Example====
::{{re|Tule-hog}} I don't think any of the values in ] accurately represent the access status you have described. I'd be inclined to leave {{para|url-access}} blank and create a new template to indicate this information after the citation template, similar to many of the templates in ]. ] (]) 17:06, 16 December 2024 (UTC)
:::I went with {{tlx|Internet Archive patrons}} as a temporary solution, which allows for tracking pages (and ]) that use it (which should make future modifications more streamline-able). ] (]) 17:14, 16 December 2024 (UTC)
::::], the book is fully searchable (click the magnifying glass). And, you can open it to any page like . This is the same as many books at Google Books. I would be careful about tagging books as "inaccessible" because there are many levels and types of access, beyond complete full access. We certainly don't tag Google Books. Also, access levels can change on a whim of the library based on publisher requirements, it's not set in stone, trying to maintain those tags over the years will be impossible. It's really beyond our scope or need. Readers are expected to be able to navigate and understand external websites. -- ]] 00:24, 17 December 2024 (UTC)
:::::That particular book is not fully browsable, click 'next page'.
:::::To clarify: are you in favor of deprecating <code>]</code> entirely, or are you making a point about Internet Archive's collections? ] (]) 00:39, 17 December 2024 (UTC)
::::::"Fully browsable" is a rare condition for (copyright) books, at any website. At Internet Archive, for example, permissions can include:
::::::* Full access for everyone
::::::* Full access if you login
::::::* Full access if you are disabled
::::::* Some book pages browsable for everyone
::::::* Some book pages browsable if you login
::::::* Search access for everyone but not browsable
::::::* Search access if you login but not browsable
::::::* There are other permissions controlling access to files
::::::Also, these permissions can, and frequently do, change at the whim of Internet Archive and the publishers, at any time. Including new types of permissions.
::::::So my question is how you plan on communicating AND maintaining this information on Misplaced Pages for the next 20 years for millions of books.
::::::Also, this is only one website. Google Books has similar gradations, is even more complex, and more opaque how it works. For these reasons we don't track the ''precise'' levels of access. It's generally understood that any copyright material is by default probably going to have ''some'' restrictions. It's a matter of practicality. -- ]] 02:50, 17 December 2024 (UTC)


== DOI prefix limits should be bumped. ==
With the following code:


We have DOI prefixes in the 10.70000s now. The limit should be bumped to 10.80000s &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 04:05, 1 December 2024 (UTC)
<code><nowiki>
: Seconding this! —&#8288;]<sup>] ]</sup> 22:10, 17 December 2024 (UTC)
{{cite journal | author = Hoffman S.J., Lavis J.N., Bennett S. | year = 2009 | title = The Use of Research Evidence in Two International Organizations' Recommendations about Health Systems | journal = Healthcare Policy | volume = 5 | issue = 1| pages = 66–86 | doi = 10.12927/hcpol.2009.21005 | doi-access = free }}
</nowiki></code>

You would get the same result as if {{para|url|https://doi.org/10.12927/hcpol.2009.21005}} was set:

* {{cite journal | author = Hoffman S.J., Lavis J.N., Bennett S. | year = 2009 | title = The Use of Research Evidence in Two International Organizations' Recommendations about Health Systems | journal = Healthcare Policy | volume = 5 | issue = 1| pages = 66–86 | doi = 10.12927/hcpol.2009.21005 | doi-access = free | url = https://doi.org/10.12927/hcpol.2009.21005 }}

====Motivation====

As a reader, it is natural to click on the title of a citation to access it. Clicking on identifiers is less intuitive, even when they are marked as free with {{free access}}. In fact, editors often [[Special:PermanentLink/947015413#Removing_a_url|fill the
{{para|url}} field with the URL the DOI resolves to]], to obtain this linked title (see statistics below).

When an article is free to read from the publisher, it is generally preferable to point readers to the publishers' version. Not only is it the version of record, but this is also the place where any errata or retraction will be published, and the DOI link
is less likely to ]. If for some
reason another version is preferred (because it is the one the editor read when citing the work, or because it is more directly accessible than via the publishers' website), it would still be possible to override the link with {{para|url}}, just like for {{para|pmc}}.

Since {{para|pmc}} is already used for auto-linking, I propose that {{para|pmc}} has priority over {{para|doi}}+{{para|doi-access|free}} to generate the title link. This will ensure that all titles currently linked will not be changed by this move.
PubMedCentral also stores versions of record, in a clean and readable way, so I do not think there is a need to override them.

Similar ideas have been suggested before, for instance ] by ].

====Statistics====

Here are some figures extracted from the enwiki dump of 2020-04-20. At this point, 189,097 citations had a {{para|doi}} and {{para|doi-access|free}} set.
* 1,773 (1%) of these also had a {{para|pmc}}
* 28,012 (15%) did not have a {{para|pmc}} but had a {{para|url}} or {{para|chapter-url}}
* 159,312 (84%) had none of {{para|pmc}}, {{para|url}} or {{para|chapter-url}}, so their title was not linked, but would be linked using the DOI with this proposal.

Among the templates with both a free-to-read DOI and a manually-specified URL, 66% of these are equivalent to the DOI link (they eventually redirect to the same website) or the URL points to the publishers' website but no longer works (404 error). This
figure was obtained by randomly sampling 100 pairs of DOI/URL from the dataset and comparing the links manually. This shows that editors are keen to link the title of their citations. This encourages link rot since they rarely use {{para|url|https://doi.org/...}} but rather the URL the DOI redirects to.

====Discussion====

Do we need to have an RFC about this? I am available to change the Lua code in the sandbox to implement the move if there is consensus for it. − ] (]) 12:55, 23 April 2020 (UTC)

:Previous relevant RFCs include:
:* ] (Aspect B4)
:* ]
:I don't think there is consensus for this change. ] 13:14, 23 April 2020 (UTC)
*'''Support''' There was an RFC about this a while back, and there was fairly widespread support for the idea (see B4 above, nearly every comment was in support, I have no idea how the closer got no consensus from this, and most the opposes didn't were self-contradictory or based on minor technical details that can be easily solved). Auto-linking would be absolutely great. The only things that really needs to be decided is two things
::What's the default hierarchy (e.g. PMC > free DOI > free Bibcode > etc...). This should only apply to garanteed version of records, and not include preprints/general repositories like ] and ]
::How do you overrule the default hierarchy (e.g. {{para|auto-url|bibcode}}, {{para|auto-url|citeseerx}}, etc...)
:&#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 13:15, 23 April 2020 (UTC)
:::Also I wouldn't say clicking on identifiers is any less intuitive. However auto-linking the title is certainly more accessible. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 13:18, 23 April 2020 (UTC)
::::My intention was to baby-step this by only adding DOIs first, as I think this is more likely to pass as a RFC (because the DOI normally points to the version of record) and does not require introducing heavy machinery to configure the auto-linking precedence. But I am not opposed with auto-linking other identifiers if there is broad support for it. The risk is repeating the RFC linked above (B4), and proposing an overly complicated system which puts off editors. − ] (]) 13:26, 23 April 2020 (UTC)
:::::I'm entirely fine by starting with DOIs autolinking (with something like PMC > DOI, with {{para|auto-url|doi}} over-riding the default) and then phasing in the others afterwards. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 13:39, 23 April 2020 (UTC)
:::There was substantial support in that RFC, but there was also substantial opposition, which would be why that aspect was closed as "no consensus". ] 13:47, 23 April 2020 (UTC)
* '''Support''' the proposal and thank you for the statistics. I think this proposal is consistent with consensus on how to work towards the overarching goal of ]. There was strong support for adding the ] parameter and use it for links, I think it was a success.</p>Given ] and ], I believe it would also appropriate to "linkify" the title when {{para|hdl-access|free}} is set. For context, this includes many ] URLs, like which goes to . These could be treated like PMC (used before the DOI, but after PMC), so as to preserve the links which no longer appear after a few thousand ] URLs were converted into {{para|hdl}} only. ] 13:24, 23 April 2020 (UTC)
::The hdl discussion which you linked to is as yet unresolved, so brought it back from the archive. If hdl is included, as you propose, that would be a firm '''oppose''' from me, as long as no clarity is given where we stand with that discussion. About the doi, I'm mildly positive. The hdl's access status is often difficult to define: it may be "free" when one visits the website from one country, and "non-free" if accessing the website from another (for that reason, I suppose, WorldCat's indications of whether a book is or isn't freely accessible at Hathitrust are notoriously unreliable) – dois have this problem far less in my experience: mostly either it's free for all, or subscription/registration for all. Anyway, bots should stop removing urls if there is a doi (there too, I don't know whether Citation bot or any other bot is still doing that – ]). So there too, although I'm mildly positive for the doi's, the idea would be a firm "no" as long as it can not be ascertained that presence or absence of urls and dois is *as decided by human editors*, not what one bot after another makes of it. --] (]) 14:10, 23 April 2020 (UTC)
:::You seem to be very confused about just about everything here. There is no "warring bots". Citation bot cleans up a DOI url to a {{para|doi}} parameter as it should (much like it cleans up handle links to {{para|hdl}}). What GreenCBot does there is adds a free archived version of the PDF. There was an issue with GreenC bot, which has subsequently been fixed. This has nothing to do with Citation bot, or auto-linking free DOIs.&#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 14:25, 23 April 2020 (UTC)
* '''Oppose''' as in the above RFC: Links for identifiers are generated anyway, but duplicating them on the title adds nothing but a bit more complexity and blue text. If a reader sees a linked title, is it an explicit {{para|url}} or a copy from one of the identifiers? If there is more than one identifier, which URL was copied? Let's avoid all that, by not copying. (I know we already copy links from {{para|pmc}}, and I'd like to remove that, but concede that there won't be consensus for that.) ] 13:47, 23 April 2020 (UTC)
::"If a reader sees a linked title, is it an explicit {{para|url}} or a copy from one of the identifiers?" Why does that even matter? The only thing that should matter here is getting the reader to the free version of record. We should be consistent and do it for DOIs as well as PMCs &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 13:51, 23 April 2020 (UTC)
:::I concur - I think most readers do not care about identifers. They should not need to know about the difference between a DOI and a HDL to read a cited article. − ] (]) 14:00, 23 April 2020 (UTC)
:::It matters because simplicity of interface is important. I am opposed to having this wedge pushed any further in. ] 14:04, 23 April 2020 (UTC)
::::"Click on the title" is about as simple as it gets. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 14:08, 23 April 2020 (UTC)
:::::If we duplicate free DOI URLs as well as PMC ones, the next step will be to duplicate the other free URLs, and then we will need a priority ordering as suggested above, and it will not be a simple matter for a reader to work out what they are going to get if they click on the title. As you say above, clicking on identifiers is simple (particularly when they are marked as free). ] 14:21, 23 April 2020 (UTC)
::::::{{xt|will not be a simple matter for a reader to work out what they are going to get if they click on the title}} They are going to get a free version of the article. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 14:28, 23 April 2020 (UTC)
:::::::Especially if you're on a desktop device and can hover over it, to see what link is ''actually'' there. (Don't tell me if you click on links without checking to see whether the alleged link is the real one, okay? That way lies hacked accounts.)
:::::::I think that the assumption that readers know what those weird numbers at the end of the citation mean is extremely doubtful, especially for the vast majority of readers without graduate degrees. I think it would be ideal to have a link on the title whenever possible, even when that link is a duplicate. ] (]) 15:17, 23 April 2020 (UTC)
* My position is the same as in the previous discussion. Yes, you'll need an RFC. No, I don't think here is where you should have it given the even split down the middle last time. ] or ] or ]. --] (]) 16:45, 23 April 2020 (UTC)
::Thanks, I'll start an RFC at ]. − ] (]) 18:52, 23 April 2020 (UTC)
{{collapse bottom}}
====RFC====

{{Ping|Kanguole|Headbomb|Nemo_bis|WhatamIdoing|Francis Schonken}} Here is an RFC: ]. − ] (]) 19:09, 23 April 2020 (UTC)
:And I forgot to ping {{U|Izno}}, sorry. − ] (]) 20:52, 23 April 2020 (UTC)

Is it time to ask someone to close the RfC? ] 06:10, 2 May 2020 (UTC)
: Early closes of RfCs can be proposed at ] (without much guarantee such early close proposal would be enacted upon). --] (]) 06:15, 2 May 2020 (UTC)
::I have done so. I agree it is early in comparison to the rest of the backlog but the participation has been good already and the consensus seems pretty clear. − ] (]) 17:45, 2 May 2020 (UTC)
:::Why? Is this a race? Will the sky fall if the rfc isn't decided {{em|now}}? I think that you should withdraw the early-closure request unless you can show that a normal rfc duration is somehow detrimental to something (what that might be, I don't know).
:::—] (]) 17:55, 2 May 2020 (UTC)
::::There's no such thing as "early closure" of this RfC, which didn't have an advertised end date. "An RfC should last until enough comment has been received that consensus is reached, or until it is apparent it won't be. There is no required minimum or maximum duration" (]). One week is a rather common timescale for a number of decision-making processes on the English Misplaced Pages, we're not in ] territory. Sure, the discussion can continue a few weeks if there's a point to it, but none has been offered so far. ] 18:12, 2 May 2020 (UTC)
:::::Legobot appears and adds an {{tlx|rfc}} template. Thirty days later, Legobot returns and removes the {{tld|rfc}} template. rfcs held here on this page over the last little while have all ended after Legobot removed the {{tld|rfc}} template. Is there a reason why it is necessary to close the rfc before the thirty days?
:::::—] (]) 18:49, 2 May 2020 (UTC)
::::::No opinion on whether or not this should be closed, but flipping the question around, is there a point to keeping the RFC open when the outcome is obvious? &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 18:51, 2 May 2020 (UTC)
:::::::I'm indifferent. When the norm around here has been to wait for Legobot to remove the {{tlx|rfc}} template, it just seems odd to me that there is this push to closure. I'm curious to know why there is such a rush.
:::::::—] (]) 19:13, 2 May 2020 (UTC)
::::::::There is no particular rush, just excitement about seeing the citation templates get better! Is it not thrilling when we have an opportunity to deliver a simple change that will make editors and readers' lives easier? Seeing the surge of enthusiasm for the move is definitely motivating me to implement it swiftly. But I will not make the change in the sandbox until the RFC is closed. A ] closure is proposed on the RFC, make sure you make yourself known if you oppose this closure (and more generally, your participation in the RFC would be welcome, of course, but I also understand if you prefer to remain neutral). − ] (]) 16:37, 4 May 2020 (UTC)
===Implementation===
The RFC has been closed, so I have ] the change in the sandbox:
{{cite compare |mode=journal |author1= Hoffman S.J. |author2=Lavis J.N. |author3=Bennett S. | year = 2009 | title = The Use of Research Evidence in Two International Organizations' Recommendations about Health Systems | journal = Healthcare Policy | volume = 5 | issue = 1| pages = 66–86 | doi = 10.12927/hcpol.2009.21005 | doi-access = free }}
Let me know if you spot any issue with the implementation. Thank you to everyone who participated! − ] (]) 18:32, 22 May 2020 (UTC)

====On title-link and other things====
: It already starts to get nasty...
:* The {{para|title-link}} parameter is not supported properly. If specified it must override any other settings. Right now (also in the current version), it throws the non-sensical error message: "|pmc= missing title" (or, in the sandbox version, also "|doi= missing title" if {{para|pmc}} is not given).
:* For cite templates supporting chapters (like with {{para|mode|book}}), there are a number of corner-cases if {{para|chapter-url}} is given instead or in addition to {{para|url}}, and with or without {{para|chapter}} given in addition to {{para|title}}. By default, {{para|title-link}} and {{para|url}} are for {{para|title}}, and {{para|chapter-url}} is for {{para|chapter}}. However, if {{para|chapter}}, {{para|url}} and {{para|title-link}} are not given, {{para|chapter-url}} should be used for {{para|title}} as well.
:* There is no parameter to define which identifier should be used if multiple are available, or to force the auto-linking feature to be disabled. There are cases where linking to the doi or pmc is undesirable. So, we need something link {{para|auto-link|none/pmc/doi}} - alternatively, the {{para|title-link}} parameter could be used for this as well, like {{para|title-link|none/pmc/doi/...}} (where ... could be any Misplaced Pages article name (except for those few tokens used to specify an identifier) and IMO the default should be "none").
: --] (]) 19:45, 24 May 2020 (UTC)
::Just as a clarification to your "non-sensical error message": The title-link parameter is for internal wikilinks on titles, most often used for books for which we have articles. It is an error to try to place both an internal wikilink and an external url link on the same title. The unclear error message that you are seeing is from that error. So I agree with your main point here: autolinking must detect the situation that there is an internal wikilink on a title, just like it detects the situation that there is an explicit url= link, and not try to autolink in that case. It would also be helpful to have a way to disable autolinking more generally, but I think using a link=yes parameter to specify link=no is not exactly an intuitive design. —] (]) 20:00, 24 May 2020 (UTC)
:::{{Re|Matthiaspaul}} good point about the issue with {{para|title-link}} - that was already an issue with {{para|pmc}} actually. I have disabled auto-linking when a {{para|title-link}} is provided - I think that is quite consensual? For your second point, could you give some examples of the issues you have noticed using {{tl|cite compare}}? About adding a parameter to disable auto-linking in general, I think the best way forward would be that the RFC participants play by the rules and accept the consensus instead of trying to introduce backdoors in its implementation. You are of course welcome to start a new RFC once this change has been deployed, or challenge the closure of this RFC if you think it was conducted inadequately. Thank you! − ] (]) 21:44, 24 May 2020 (UTC)
::::I disagree. Use of {{para|title-link}} must not usurp a link to the source.
::::
::::Auto-linking {{para|title}} with {{para|pmc}} / {{para|doi}} is only supported for {{tlx|cite journal}}. {{tlx|cite book}} has nothing at all to do with title auto-linking from identifiers; it does not happen.
::::
::::I do agree that the error message is less than helpful; it is there to catch the legitimate case when {{para|url}} is set but {{para|title}} is not set. I have sandboxed a correction that will emit the {{error-small|URL–wikilink conflict}} message when {{para|url}} and {{para|title-link}} are both set. I did not save that because I think that the edit granting {{para|title-link}} priority over {{para|url}} should be reverted.
::::—] (]) 22:12, 24 May 2020 (UTC)
:::::{{Re|Trappist the monk}} fair enough, I am happy with your solution too! Reverting my change now. − ] (]) 22:14, 24 May 2020 (UTC)
::::::Here is the fix:
<div style="margin-left:11.2em">{{cite compare |mode=journal |title=Title |title-link=Title |journal=Journal |pmc=12345}}</div>
<div style="margin-left:11.2em">{{cite compare |mode=book |title=Title |title-link=Title |url=//example.com}}</div>
::::::—] (]) 22:48, 24 May 2020 (UTC)
:::::::There are notable journal papers for which title-link would be appropriate and for which autolinking should not happen when title-link is set. ], as an example (of a notable journal paper, not of one with an open doi). As for autolinking not being available for {{tl|cite book}}: whyever not? Books can have dois and I don't see why those dois might not be open access in some cases. —] (]) 04:01, 25 May 2020 (UTC)
::::::::No doubt. Maybe that is why {{tlx|citation}} doesn't have auto-linking capability:
:::::::::<code><nowiki>{{citation/new|first=A.|last=Grothendieck|authorlink=Alexander Grothendieck|title=Sur quelques points d'algèbre homologique |title-link=Grothendieck's Tôhoku paper |journal=]|volume=9|issue=2|series=(2)|pages=119–221|year=1957|mr=0102537|doi=10.2748/tmj/1178244839|doi-access=free}}</nowiki></code>
::::::::::{{citation/new|first=A.|last=Grothendieck|authorlink=Alexander Grothendieck|title=Sur quelques points d'algèbre homologique |title-link=Grothendieck's Tôhoku paper |journal=]|volume=9|issue=2|series=(2)|pages=119–221|year=1957|mr=0102537|doi=10.2748/tmj/1178244839|doi-access=free}}
::::::::The same can be applied to books.
::::::::—] (]) 13:55, 25 May 2020 (UTC)
:::::::{{Re|Trappist the monk}} Just to be sure I understand: how are users supposed to solve the error that arises when both {{para|pmc}} and {{para|title-link}} are set? Remove one of them? Is that really satisfactory? I do not really see why we would forbid people from wikilinking the title if the PMC link is available as an identifier. Just like {{para|url}} can be used to override the link generated by auto-linking, I would expect the same of {{para|link-title}}. Of course we are talking about very rare corner cases, but it is worth getting them right. I am also not sure why {{tl|cite book}} would behave differently: this has been the case so far because {{para|pmc}} is probably never applicable to books, but as David points out there are plenty of books with DOIs nowadays. − ] (]) 05:22, 25 May 2020 (UTC)
:::::::: While I do not support the auto-linking feature myself (because it violates fundamental rules of good user interface design), if it gets implemented, it should be implemented as consistent as possible across all cite templates. Nobody can expect users to understand that it works for {{tl|cite journal}}, but not for {{tl|cite book}} etc. Implementing this differently and addressing the differences in the documentation would add unnecessary complexity without offering any benefit in return.
:::::::: Regarding priorities, I think it is paramount that {{para|title-link}} cannot be overridden by other possible link targets, because internal links have priority over external links. Since there is no way to support a wikilink and an URL link in the same title and we should not silently suppress information given in a cite template, I think it is desirable to display an error message if both are available at the same time. The normal solution would be to remove {{para|title-link}} rather than {{para|url}} (or, where applicable, {{para|chapter-url}}), but it is also possible the other way around but much less likely to happen.
:::::::: All the other external links from identifiers which could be used for auto-linking should only be used for the title link if {{para|url}} (or, where applicable, {{para|chapter-url}}) is not given. However, as this is an optional feature, the presence of external links from identifiers should also never override {{para|title-link}} and should never generate an error message, if both are present at the same time (after all, external links from identifiers are still present through their identifiers, so there is no display conflict).
:::::::: Again, there are cases were auto-linking is inappropriate and there must be some way to override it. Otherwise, people would solve the problem by not providing identifier information in the first place, or not using citation templates at all - hardly a good solution. Also, in the discussion and the RFC, people have already stated that PMC and DOI will just be a start and that they plan to add support for auto-linking further identifiers in the future. As multiple identifiers can be given at the same time, we must define auto-linking priorities to them, and since whatever scheme we will come up with will not work for some cases (PMCs are not always "better" than DOIs, etc.), there must be some way to override this automatic selection and deliberately specify a particular identifier to be used for auto-linking. For this, we could introduce a new parameter like {{para|auto-link}}, but I suggest to overload the normal functionality of the {{para|title-link}} parameter for this by letting the parameter accept a number of special tokens (that is, the keyword "none" and the parameter names of all supported identifiers). If none of these special symbols like "pmc" or "doi" is given, {{para|title-link}} is treated like before - defining the internal link. I think, the corner-case that we'd want to link to an article named after an identifier is very rare (and we could still go through a redirect in this case), so no actual conflict would arise out of this double-use of the parameter. If the selected identifier is not provided, this could either be silently ignored or a warning be given.
:::::::: One more thought: As already said, in contrast to the outcome of the RFC my personal preference for the auto-selection default would be "none", so that it would have to be deliberately enabled where actually needed (and possibly useful). If it would be implemented this way, we would not even need a "none" keyword and also would not have to set up priorities for the auto-selection; {{para|title-link|doi}} would enable auto-linking for the {{para|doi}}, {{para|title-link|pmc}} for the {{para|pmc}}, ..., {{para|title-link|Title}} would link to ] etc. This would reduce unnecessary complexity, be more predictable (no surprises because the title auto-linking feature is only used when deliberately enabled) and much easier to explain in the documentation:
::::::::: "''If the title link should duplicate one of the links given as identifiers, you can select the desired identifier through {{para|title-link|&lt;identifier-parameter>}} without having to duplicate the identifier link as {{para|url}}''".
:::::::: Clean and easy.
:::::::: --] (]) 12:42, 25 May 2020 (UTC)
:::::::::{{tq|because internal links have priority over external links}} I think that a citation is needed for that. In cs1|2, external links always have priority over internal links. We often see stuff like:
::::::::::<code><nowiki>{{cite book |title=] |url=//example.com}}</nowiki></code>
:::::::::which, because a single link cannot target multiple locations, produces an error message:
::::::::::{{cite book |title=] |url=//example.com}}
:::::::::{{para|title-link}} is handled in the same way; {{para|url}} links the title and the citation emits an error message:
::::::::::<code><nowiki>{{cite book/new |title=Abraham Lincoln |title-link=Abraham Lincoln |url=//example.com}}</nowiki></code>
:::::::::::{{cite book/new |title=Abraham Lincoln |title-link=Abraham Lincoln |url=//example.com}}
:::::::::In these cases we do not {{tq|silently suppress information given in a cite template}}.
:::::::::
:::::::::{{tq|this is an optional feature}} Ha! For {{para|pmc}}, not so (alas). When I disabled the {{tq|oddity that is <nowiki>{{cite journal}}</nowiki> with {{para|pmc|plain=yes}} set and {{para|url|plain=yes}} not set}} (a comment that used to be in the code) I died on that hill in a battle with ]. While I have some sympathy for your {{para|title-link}} solution (I would have chosen to add keywords to the various url-holding parameters instead) you too, will die on the hill if you attempt to switch WP:MED from the fully automatic {{para|pmc}} to some sort of semi-automatic mechanism. Were we to implement a semi-auto-link mechanism, we will still have the abomination of special-case code because {{para|pmc}} will be fully automatic.
:::::::::—] (]) 15:07, 25 May 2020 (UTC)
:::::::::: Thanks for correcting me regarding that {{para|url}} takes priority over {{para|title-link}}. However, the basic argument remains valid that both cannot exist at the same time and the user has to remove one of them to get rid of the error message - which one should be a deliberate decision of the editor.
:::::::::: Regarding auto-selection or not, regardless if auto-selection for auto-linking will be enabled by default (by absense of a {{para|title-link}} parameter) or only on demand (through {{para|title-link}}), we need a parameter to either override or control the behaviour. If we use something like {{para|title-link|doi}} (my suggestion) or {{para|url|doi}} (your suggestion) for this does not matter much, however, I find {{para|title-link}} more intuitive to remember for this (and it might cause less confusion for bots trying to make sense of invalid URLs like "doi".).
:::::::::: Regarding the MED folks, what is so difficult for them to add something like {{para|title-link|pmc}} to a citation, if it makes the auto-linking system as a whole more consistent and easier to understand for the majority of people outside of MED topics?
:::::::::: --] (]) 18:04, 30 May 2020 (UTC)
::::::::: Followup regarding {{tq|I think, the corner-case that we'd want to link to an article named after an identifier is very rare (and we could still go through a redirect in this case), so no actual conflict would arise out of this double-use of the parameter.}}
::::::::: Instead of going through redirects to work around a conflict of a desired target article name with a parameter name for an identifier, we could use the "]" syntax to enforce the interpretation as article name rather than parameter name. So {{para|title-link|((pmc))}} would link the title to ] instead of retrieving the link target from the {{para|pmc}} parameter, same for the other supported identifiers.
::::::::: --] (]) 18:04, 30 May 2020 (UTC)

::::::::In the first sentence of the ] you mention {{tq|]/]}} and in the second sentence you mention {{tq|{{para|chapter-url}}}}. I guess that when you did your research before proposing the doi auto-link RfC that you did not notice that the pmc auto-link applied only to {{tlx|cite journal}}, has always applied only to {{tld|cite journal}}. Go look at the pre-lua versions of the templates to see that.
::::::::
::::::::The Grothendieck citation that I mentioned above is a solution for both journal and book cites with {{para|pmc}} or free-to-read {{para|doi}}. The {{error-small|URL–wikilink conflict}} help text could use a bit of a tweak to suggest this solution (among other things that need fixing there). And, because it is the first error message mentioned, {{error-small|{{para|&lt;param>|plain=yes}} missing title}} could also use a bit of a tweak.
::::::::—] (]) 13:55, 25 May 2020 (UTC)
:::::::::{{Re|Trappist the monk}} Yes indeed, the RFC text implies that the auto-linking would be deployed not just to cite journal, but to other CS1/2 templates as well, otherwise I would not have mentioned {{para|chapter-url}}. Yes, so far it applied only to cite journal, but the point of this RFC is to introduce a ''change'' in the behaviour of the CS1/2. So I do not see why we should preserve this restriction: even editors who oppose auto-linking agree that it would not make sense to keep it. So: we should enable auto-linking for all CS1/2 which accept doi or pmc, and disable auto-linking when a link-title is supplied. We cannot expect editors to switch to {{tl|citation}} to disable auto-linking - even if we explicitly pointed to this "solution" in the error message: it just does not make sense. I understand you have a great knowledge of the internals and history of these templates and you probably find most of this very natural, but we cannot require editors to study the History of the English Misplaced Pages Citation Templates in five volumes, so that they know about the migration to Lua, the removal of pmc auto-linking, the WP:MED rebellion, and so on, to make sense of the historical oddities that we preserve for the enjoyment of future generations. Let's just make this usable. Please revert your own change to add the error message, I will then restore my version and generalize the auto-linking beyond {{tl|cite journal}}. − ] (]) 15:24, 25 May 2020 (UTC)
::::::::::Can you show how the error message fix that I made is somehow wrong and, because it is wrong, needs to be reverted?
::::::::::
::::::::::Here are sixteen {{tlx|cite journal}} templates that cover the sixteen possible combinations of {{para|pmc}}, {{para|title}}, {{para|url}}, and {{para|title-link}}. Where there is an error message, the template is being asked to do something that it cannot do because of insufficient parameters or too many parameters vying for the use of a single resource:
::::::::::*0000: {{cite journal/new |journal=Journal}} – no pmc, no title, no url, no title-link
::::::::::*0001: {{cite journal/new |journal=Journal |title-link=Title}} – title-link
::::::::::*0010: {{cite journal/new |journal=Journal |url=//example.com}} – url
::::::::::*0011: {{cite journal/new |journal=Journal |url=//example.com |title-link=Title}} – url, title-link
::::::::::*0100: {{cite journal/new |journal=Journal |title=Title}} – title
::::::::::*0101: {{cite journal/new |journal=Journal |title=Title |title-link=Title}} – title, title-link
::::::::::*0110: {{cite journal/new |journal=Journal |title=Title |url=//example.com}} – title, url
::::::::::*0111: {{cite journal/new |journal=Journal |title=Title |url=//example.com |title-link=Title}} – title, url, title-link
::::::::::*1000: {{cite journal/new |journal=Journal |pmc=12345}} – pmc
::::::::::*1001: {{cite journal/new |journal=Journal |pmc=12345 |title-link=Title}} – pmc, title-link
::::::::::*1010: {{cite journal/new |journal=Journal |pmc=12345 |url=//example.com}} – pmc, url
::::::::::*1011: {{cite journal/new |journal=Journal |pmc=12345 |url=//example.com |title-link=Title}} – pmc, url, title-link
::::::::::*1100: {{cite journal/new |journal=Journal |pmc=12345 |title=Title}} – pmc, title,
::::::::::*1101: {{cite journal/new |journal=Journal |pmc=12345 |title=Title |title-link=Title}} – pmc, title, title-link
::::::::::*1110: {{cite journal/new |journal=Journal |pmc=12345 |title=Title |url=//example.com}} – pmc, title, url
::::::::::*1111: {{cite journal/new |journal=Journal |pmc=12345 |title=Title |url=//example.com |title-link=Title}} – pmc, title, url, title-link
::::::::::Because cs1|2 prioritizes external links over internal links, these templates render the title linked with the value assigned to {{para|url}} (1st) or {{para|pmc}} (2nd) when in conflict with {{para|title-link}} (or with a wikilink embedded in the {{para|title}} value). This is consistent for all cs1|2 templates and should not change. Making it so that auto-links from {{para|pmc}} and {{para|doi}} yield to {{para|title-link}} is inconsistent with the current handling of URL–Wikilink conflicts. To make cs1|2 consistent in a way that makes external links yield to internal links would mean that when editors write stuff like:
:::::::::::<code><nowiki>{{cite book |title=Title with partially wikilinked ] |url=//example.com}}</nowiki></code>
::::::::::would render as:
:::::::::::''Title with partially wikilinked ]''. {{error-small|URL–wikilink conflict (])}}
::::::::::And that is nonsense.
::::::::::
::::::::::If this mechanism is to be made available to all cs1|2 templates and if it can be shown that it is absolutely required that auto-links yield to {{para|title-link}} then, no doubt, some sort of override mechanism can be concocted. Yes there are en.wiki articles about books and journal articles. I think that it misleads the reader who, seeing the blue-linked title, clicks it expecting to go to the actual book or journal article, and ends up at an en.wiki article about that book or journal article. It has happened to me. {{para|title}}, when linked, is an advertisement to see the actual source that is advertised. That was the whole purpose of this RfC was it not? Click this title to read the source.
::::::::::—] (]) 18:08, 25 May 2020 (UTC)
:::::::::::{{Re|Trappist the monk}} {{tq|Can you show how the error message fix that I made is somehow wrong and, because it is wrong, needs to be reverted}} yes, I have done so repeatedly, and so have David Eppstein and Matthiaspaul. You understand the problem very well, you are just trying to instrument this corner case to force the introduction of a parameter to disable auto-linking, because the outcome of the RFC is not to your taste. Statements such as "{{tq|{{para|title}}, when linked, is an advertisement to see the actual source that is advertised}}" are obviously wrong: in that case, using {{para|title-link}} to point to Misplaced Pages articles should be forbidden, as they violate this rule. You are well aware of the fact that internal and external links are not rendered the same way, see the difference between your cases 0101 and 0110. I will explain one last time what the issue is: raising an error when pmc, title and title-link are present (your 1101 case) is wrong: in this case, the {{para|title-link}} should be used to link the title, without raising an error. If an editor uses {{para|title-link}} in that situation, they want to use this link on the title, and we need to respect this choice. The auto-linked URL is only a default value, that can be overridden by editors with any external or internal link. I have reverted my own proposal to let you try yours, which does not suit anybody except you: now is the time to accept that. Thank you in advance for your cooperation and good faith. − ] (]) 18:36, 25 May 2020 (UTC)
::::::::::::I'm pretty sure that you do not understand what it is that my {{error-small|error message fix}} fixed. So, direct comparisons: old v. new from the examples above. Remember what I said: this is an {{error-small|error message fix}}; nothing more:
::::::::::::*0111 (old): {{cite journal |journal=Journal |title=Title |url=//example.com |title-link=Title}} – title, url, title-link
::::::::::::*0111 (new): {{cite journal/new |journal=Journal |title=Title |url=//example.com |title-link=Title}} – title, url, title-link
::::::::::::*1101 (old): {{cite journal |journal=Journal |pmc=12345 |title=Title |title-link=Title}} – pmc, title, title-link
::::::::::::*1101 (new): {{cite journal/new |journal=Journal |pmc=12345 |title=Title |title-link=Title}} – pmc, title, title-link
::::::::::::*1111 (old): {{cite journal |journal=Journal |pmc=12345 |title=Title |url=//example.com |title-link=Title}} – pmc, title, url, title-link
::::::::::::*1111 (new): {{cite journal/new |journal=Journal |pmc=12345 |title=Title |url=//example.com |title-link=Title}} – pmc, title, url, title-link
::::::::::::Presumably you intend to change:
:::::::::::::{{code|lang=lua|1=if config.CitationClass == "journal" and not is_set(URL) then}}
::::::::::::to something akin to:
:::::::::::::{{code|lang=lua|if not (is_set (TitleLink) or is_set(URL)) then}}
::::::::::::If that is your change, then the only thing that changes in the examples above is example 1101 which will not show an error. That does not make my {{error-small|error message fix}} wrong as you claim it to be.
::::::::::::
::::::::::::You wrote that {{tq| trying to instrument this corner case to force the introduction of a parameter to disable auto-linking}}. Where have I ever said that? In general I am opposed the the introduction of special case parameters of any sort into a template system that is already overburdened with too many parameters. It is highly unlikely that I would now start advocating for such a parameter either openly or {{lang|la|sub rosa}}. I am opposed to special-case anything and gnash my teeth when special cases are unavoidable.
::::::::::::
::::::::::::{{tq|{{para|title|plain=yes}}, when linked, is an advertisement to see the actual source that is advertised}} (my words) is not {{tq|obviously wrong}} (your words). The purpose of the RfC was to link {{para|title}} to the url created with the {{para|doi}} identifier when the source at that doi-identifier-url is free-to-read. A common rationale expressed at the RfC is that a linked title makes it easier for readers to get to that source when they might hesitate to click the doi identifier link because they don't know what a doi identifier is. The linked title is then an {{tq|advertisement}} that says to these hesitant readers, "click me, I am a link to the source." Yes, I know about external link icons and the differences between external and internal link colors. That does not change the fact that readers, even those of us who are experienced with how en.wiki citations are rendered, will click blue-linked titles and be disappointed/astonished/frustrated to land at en.wiki's article about the source.
::::::::::::
::::::::::::It is, in my opinion, poor practice to link a cs1|2 title to an article about that title. The purpose of a citation is to help readers locate the source that supports content in an en.wiki article. Articles about a source at en.wiki are not ] but linking to such articles through a link at {{para|title}} makes it seem that the en.wiki article is the source (after all, it {{em|has}} the blue link). If it is important to mention a particular source in an article, then that mention should be in the body of the article or in an article footnote with standard wikilinks to the en.wiki article about the source. There is a use for {{para|title-link}}: citing sources at Wikisource because the link is to the source and the source is reached though standard interwiki links:
:::::::::::::<code><nowiki>{{cite encyclopedia |title=Aard-vark |title-link=s:1911 Encyclopædia Britannica/Aard-vark |encyclopedia=Encyclopædia Britannica |year=1911}}</nowiki></code>
::::::::::::::{{cite encyclopedia |title=Aard-vark |title-link=s:1911 Encyclopædia Britannica/Aard-vark |encyclopedia=Encyclopædia Britannica |year=1911}}
::::::::::::and, no, I don't think that {{tq|using {{para|title-link|plain=yes}} to point to Misplaced Pages articles should be forbidden}}. Limited, certainly; forbidden, no.
::::::::::::—] (]) 23:31, 25 May 2020 (UTC)
:::::::::::::Your opinion that titles should not be linked to articles about the title is wrong, and you should feel bad about holding such a wrong opinion. My opinion, which is obviously the correct opinion, is that such links should always be made whenever we have an article about the reference that can be linked from its title. There are very good reasons for linking to an article about a reference: for instance, the article may include multiple free-to-read links where a reference can only have one, or the article may (and probably should) include opinions from the reviewers that may be relevant for how reliable it is as a reference (for an example see Osen's '']'', which has sometimes erroneously been used as a reference here). Your opinion is also at odds with the very existence of the title-link parameter. More importantly, it is an editorial decision that should be made by the editors of articles, not enforced by fiat by the behavior of a citation template. If the editors of an article want to control how a title is linked by using a title-link parameter, for a reference that has a pmid or open doi, they should be allowed to control it, just as they can control it by using a url parameter. If the editors of an article for whatever reason decide that a title should not be linked, even though the default would be to auto-link it, they should be allowed to. You should not be inserting your opinions about this into the behavior of the templates. —] (]) 00:04, 26 May 2020 (UTC)
::::::::::::::<s>{{Re|Trappist the monk}} Alright, let me put this differently. No matter whether you understand the problem with your change or not: you have in front of you three editors who disagree with it, and nobody to support it. You should recognize this situation and act accordingly. If you do not, you know what to expect. − ] (]) 06:28, 26 May 2020 (UTC)</s>
:::::::::::::::Ok, I take that back, let me just do the change you suggest then - I understood that you were against it. − ] (]) 06:36, 26 May 2020 (UTC)
::::::::::::::::Please do not interpret the silence of some of us as agreement with one of the many positions taken above. This discussion appears to have gone far afield from its original purpose, which was to auto-link the title when a DOI was present, unless I am mistaken. It would be great if discussions could stay on topic. If there is a problem with {{para|title-link}}, perhaps it should be addressed in a separate thread. – ] (]) 06:51, 26 May 2020 (UTC)
:::::::::::::::::Yes, this was just a corner case of the existing auto-linking mechanism, we should have had this discussion elsewhere in the first place. − ] (]) 07:00, 26 May 2020 (UTC)
:::::::::::::::::: Huh? This is not a corner case. The discussion belongs exactly here. It shows that the whole original proposal, which led to the RfC, was ill-defined. An RfC which cannot be implemented as proposed, because it conflicts with other functionality, is basically useless. What we can still extract from the RfC, even if it was not thought through, is the core message that many people want some form of auto-linking. But we are not going to break existing functionality for this, as the voters in the RfC certainly didn't intend to break existing functionality either. Instead, we will have to find solutions which solve all the issues brought up here before any of this can go live.
:::::::::::::::::: --] (]) 09:37, 9 June 2020 (UTC)

====Auto-linking for book chapters====
One issue with auto-linking for book chapters is that the DOI can potentially refer to the entire book or the individual chapter. If no {{para|chapter}} is present, I think we can auto-link the title safely. If a chapter is specified then there is a risk that we link the book title with a chapter DOI or that we link the chapter title with a book DOI. The simplest solution I can think of is to disable auto-linking when {{para|chapter}} is present, what do you think about that? − ] (]) 07:00, 26 May 2020 (UTC)
:The DOI is supposed to refer to the work actually being cited, so I don't see a problem with linking it. If the citation contains the DOI of the wrong work, it will need to be fixed but there's nothing the template can do to guess it. ] 19:15, 7 June 2020 (UTC)
:: Yeah, but if the DOI only belongs to the {{para|chapter}}, not the {{para|title}}, the auto-linking should be applied to the chapter rather than the title. Otherwise it would be the same as linking {{para|chapter-url}} to {{para|title}} even if {{para|chapter}} is present. That would be really messy.
:: --] (]) 09:57, 9 June 2020 (UTC)
: While this is complicating things even further unfortunately, you bring up a valid point. So far, I thought chapter DOIs would be just some "unofficial" private extension to DOIs by some publishers, but if they are not, we either need some means to declare the type of a given DOI or to provide up to two of them just like we have {{para|url}} and {{para|chapter-url}}: Perhaps {{para|doi}}/{{para|work-doi}} and {{para|chapter-doi}}?
: Disabling auto-linking when {{para|chapter}} is present would create even more "unnecessary complexity", making the whole auto-linking thing look unpredictable to normal users. --] (]) 09:57, 9 June 2020 (UTC)
: A related discussion: ]
: --] (]) 11:38, 13 June 2020 (UTC)
:: I have added {{para|doi}} aliases {{para|title-doi}} and {{para|chapter-doi}} to the sandboxed version of the template, see also . For now, they are treated equally and only one of them is allowed to be given at a time, but by providing these aliases we allow editors to be specific about the type of DOI they are entering. This is important information that may be needed when, following the various discussions, it becomes necessary to distinguish between these two types in the template (and potentially for additional error checking) f.e. so that a chapter DOI isn't accidently used to auto-link to a title etc. (At present, this isn't ruled out - and couldn't so far, because we didn't make any distinction here.) Giving users a chance to (optionally) specify what type of DOI they are providing (when known) reduces the amount of future maintenance work to disambiguate and sort the DOIs (using {{para|doi}}) where this information was not provided. --] (]) 13:27, 23 August 2020 (UTC)
:::This is premature. We don't have a design so we should not be making speculative changes to the module suite that may-or-may-not be used in an actual implementation if there ever is an implementation. Implement what we need when we need it; don't clutter the code with stuff that isn't used.
:::—] (]) 14:50, 23 August 2020 (UTC)
::::I wanted to say the exact same today when I saw the edits. I would additionally ask the question whether we open Pandora's box regarding a similar implementation for the other identifiers and the subsequent combinatorial explosion (an issue we have mostly avoided). --] (]) 15:57, 23 August 2020 (UTC)

====Proceeding====
I understand that , so we're ready to go, right? ] 19:15, 7 June 2020 (UTC)
: I don't think so. We still need some generic means to override and optionally disable the auto-linking behaviour (f.e. by the suggested {{para|title-link|none/identifier_parameter_name/article_name}} extension), and to sort out what to do with chapter DOIs (f.e. by adding {{para|chapter-doi}}).
: --] (]) 10:11, 9 June 2020 (UTC)
::As far as I am concerned this is ready to deploy. There is currently no problem with chapter DOIs since the mechanism is only implemented for {{tl|cite journal}} for now - once this is rolled out we can gradually expand to other citation templates if there is consensus around the course of action for chapter DOIs. − ] (]) 08:37, 14 June 2020 (UTC)
::: In the current implementation, there is still no way to (optionally) disable auto-linking or to override the auto-selection of PMCs or DOIs. Also, in ] ]s people are already asking about adding auto-linking support for S2CID as well. This clearly indicates that we need a proper generic solution instead of continuing to add kludges on kludges only complicating things on all fronts (in the implementation, in the documentation for users, and in the maintenance of citations) further in the long run.
::: In ], I was questioning the very need of existence of the {{para|title-link}} parameter, because, as was discussed in that thread, {{para|title}} allows for internal links as well (even more flexible than via {{para|title-link}} - so, if that parameter would have been removed to reduce unnecessary complexity, my proposal to overload the {{para|title-link|none/<identifier_parameter_name>/internal_link}} functionality to also control the auto-linking behaviour would have been voided as well, however, I meanwhile have come to the conclusion that {{para|title-link}} is still needed to link a combined title if both {{para|title}} and {{para|script-title}} are used at the same time, therefore my suggestion still remains a possible solution, fortunately. If I understood Trappist correctly, he suggested to use something like {{para|url|none/<identifier_parameter_name>/external_link}} instead. While the parameter name is less intuitive IMHO, it would even have the advantage that the auto-linking of titles and chapter titles could be controlled individually by something like {{para|chapter-url|none/<identifier_parameter_name>/external_link}}, whereas in my proposal this would be implicit.
::: (There are two more cases to be properly addressed in the future: Works without any title at all, and works with a so called descriptive title. At present, {{tl|cite journal}} already implements a special case {{para|title|none}} to specify a non-existing title. The discussion of these cases is not necessarily related to the question how to control the auto-linking behaviour above, but depending on what solution we would actually go for, it might be possible to address this in one coherent way in order to keep the user interface as easy and intuitive to use as possible. However, at present, my suggestion how to address these two cases would not involve {{para|title-link}} etc. at all, but other users might have other ideas.)
::: --] (]) 16:04, 14 June 2020 (UTC)

::::{{Re|Matthiaspaul}} I encourage you to run RFCs to get approval for the changes you propose. I suggest we do it only after the current version has been rolled out. − ] (]) 19:54, 14 June 2020 (UTC)

:::: Following-up on the proposals how to implement the auto-link override, I searched old threads for other proposals and found that Trappist the Monk already suggested {{para|url|none/<identifier_parameter_name>/external_link}} and Headbomb {{para|autolink|no/yes/<identifier_parameter_name>}} back in ]. In ], Headbomb suggested {{para|auto-url|none}}, whereas Nardog and I proposed {{para|url|none/<identifier_parameter_name>/external_link}}, followed by my newer proposal for {{para|title-link|none/<identifier_parameter_name>/internal_link}}. These proposals are all very similar in nature. In order not to introduce yet another parameter for this, I think, overloading either {{para|url}}/{{para|chapter-url}} or {{para|title-link}}/({{para|chapter-link}}) is the way to go. Overloading the url parameters could have the disadvantage of temporarily causing trouble for bots trying to make sense of these special values. Overloading {{para|title-link}} (without introducing {{para|chapter-link}}) leaves open the question of how to best cope with chapter identifiers. Therefore, if the potential bot issue could be ruled out or is found to be minor, I would also support Trappist's proposal of overloading {{para|url}}/{{para|chapter-url}}. Opinions?
:::: --] (]) 14:03, 15 June 2020 (UTC)
:::::Just like I respected the few who opposed my initial proposal on this page and required me to go through an RFC process for a change that turns out (surprise) to be very consensual, please respect my own opposition to your proposal. Is it too much to ask for? − ] (]) 18:25, 15 June 2020 (UTC)
:::::: If you cannot draw this from the very fact that I spent considerable time thinking about a solution how to properly integrate the auto-linking feature although I do not consider it useful, let me state that I do respect your opinion. That doesn't mean that I think it is correct.
:::::: However, as your RfC did not define the scope of the auto-linking feature and since it ignored addressing important real-world cases (which, however, need to be solved in an actual implemention), the only thing that can be drawn from the RfC reliably is that many people want some form of auto-linking, leaving it up to us to find a proper solution how to integrate it into the existing citation framework. Specifically, what cannot be drawn from that discussion is that they want to enforce autolinking without any means to override it, as you now seem to push for.
:::::: In that discussion, here, and in prior discussions over several years, the whole auto-linking idea was always discussed under the assumption that there is some means to override it where necessary. This was requested even by people who think auto-linking is a good idea. It is obvious that we need this before auto-linking can go live. While other implementation details (such as adding support for S2CID or extending the scope beyond {{tl|cite journal}} and thereby indirectly also addressing the case of chapter identifiers) can be delayed, the implementation of some override functionality can not be delayed any further as we now have two rather only one identifier to distinguish (PMCs and DOIs), and not having any means to override the behaviour when the auto-selection would select and link to the wrong identifier is violating ] and ]. It would destroy the trust we put into citations which were deliberately set up in a certain way and not in another by those who provided the citations originally.
:::::: So, for as long as no means to optionally override auto-linking are implemented, I oppose rolling out the currently half-finished implementation - as is, it is potentially harmful to the project.
:::::: Let's solve this issue by thinking through if overloading {{para|url}} (or {{para|title-link}}) is an extensible solution addressing all potentially desired future cases (I think it is) and not causing problems for bots (not sure about that). And if so, then let's implement it, so that auto-linking can go live without causing harm.
:::::: --] (]) 19:57, 15 June 2020 (UTC)
:::::::I have no interest in continuing this argument. I will just let other editors judge your attitude on their own. − ] (]) 07:29, 18 June 2020 (UTC)

Screenshot for reference: ]. ] 15:37, 12 July 2020 (UTC)

===Where are we on this?===
What's the progress/holdup on making all {{para|id-access-free}} auto-link? It's been over a month since there was movement on this. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 17:29, 4 August 2020 (UTC)
: See also: ]
: --] (]) 11:33, 10 August 2020 (UTC)

== trans-title= splits PDF format indication ==

In the following example, the "(PDF)" format designation comes after the translated title, which looks odd because the PDF symbol is displayed after the foreign language title:

: {{cite magazine |script-title=ru:ИДЕНТИФИКАЦИЯ ЧАСТНОй ПОлЕЗНОСТИ МНОГОФАКТОРНЫХ АлЬТЕРНАТИВ С ПОМОЩЬЮ S-ОБРАЗНЫХ ФУНКЦИй |trans-title=Identification of utility functions in multi-objective choice modelling by using S-shaped functions |author-first1=Vladimir V. |author-last1=Beskorovainyi |author-first2=Elena V. |author-last2=Soboleva |language=ru |publisher=] |date=2010 |volume=72 |number=1 |script-magazine=ru:БИОНИКА ИНТЕЛЛЕКТА |trans-magazine=Bionics of Intelligence |issn=0555-2656 |pages=50–54 |url=http://openarchive.nure.ua/bitstream/document/603/1/%D0%98%D0%94%D0%95%D0%9D%D0%A2%D0%98%D0%A4%D0%98%D0%9A%D0%90%D0%A6%D0%98%D0%AF%20%D0%A7%D0%90%D0%A1%D0%A2%D0%9D%D0%9E%D0%99%20%D0%9F%D0%9E%D0%9B%D0%95%D0%97%D0%9D%D0%9E%D0%A1%D0%A2%D0%98%20%D0%9C%D0%9D%D0%9E%D0%93%D0%9E%D0%A4%D0%90%D0%9A%D0%A2%D0%9E%D0%A0%D0%9D%D0%AB%D0%A5%20%D0%90%D0%9B%D0%AC%D0%A2%D0%95%D0%A0%D0%9D%D0%90%D0%A2%D0%98%D0%92%20%D0%A1%20%D0%9F%D0%9E%D0%9C%D0%9E%D0%A9%D0%AC%D0%AE%20S-%D0%9E%D0%91%D0%A0%D0%90%D0%97%D0%9D%D0%AB%D0%A5%20%D0%A4%D0%A3%D0%9D%D0%9A%D0%A6%D0%98%D0%99%20%2850-54%29.pdf}}
There are several potential ways to solve this:
# Include the translation in the link - undesirable because the translation does not actually belong into there.
# Move the (format) designator in front of the translation - undesirable because it looks out of place there
# Move the PDF symbol after the translation - undesirable because it also serves as "external link" indicator, also not sure if this is technically possible
# Suppress the PDF symbol and replace it by the normal "external link" symbol. Do we really need the PDF symbol, anyway? (Do we support any other file types with special symbols?)
Ideas?
--] (]) 14:28, 20 June 2020 (UTC)

: #4 is possible. Yes, other file types do have special symbols if the URL is a certain way and file type. PDF is understandably the most common. Because I have the link handy for Modern skin, the stylings applied to the others are . The other skins have similar rules, if not exactly the same. (See also ].)
: #3 is technically possibly. It would require including the trans-title in the link. (See also ].) If we do not want a sea of blue on this route, that is also technically possible but it would require an inaccessible design choice (to wit, making the link for some part of the title + trans-title not blue).
: I would favor #2 if there is a consensus that this needs to change. It's puzzling that you think this undesirable given our recent discussions on parentheses stacking... ;) --] (]) 14:59, 20 June 2020 (UTC)
:: Thanks for the links, Izno.
:: Well, I don't like #2, because it separates the actual title and the translation too much. To me, they belong together logically and therefore should not be separated - just like the format symbol and "(format)" text should be displayed in one location. To me, title information is far more important than format information, therefore, format information should not be inserted in the middle of title information, and in particular not given in two places.
:: Therefore, of the given choices, I would prefer #1 (which implies #3), that is, back to the old 2017 behaviour. Although I am not particularly fond of the potentially resulting long blue link labels, they would be of only minor concern to me (display cosmetics) - at least, they are logical.
:: For completeness, another solution would be to swap title and trans-title, but I don't actually suggest this, because I think the actual title should be displayed before the translation.
:: --] (]) 16:21, 20 June 2020 (UTC)
:<span class="template-ping">@]:</span> I've corrected the citation formatting above (but not in a way that affects the topic of this discussion). I hope you don't mind. ] (]) 07:03, 13 July 2020 (UTC)
::Good to know that we meanwhile support {{para|script-*}} and {{para|trans-*}} parameter variants for them. I've changed it to {{para|magazine}}, though - they describe themselves as a magazine rather than as a journal. {{para|work}} is too unspecific. I use {{para|work}} only when none of the more descriptive parameters applies (typically with {{tl|cite web}} or {{tl|cite book}}, rarely with {{tl|cite journal}} or {{tl|cite magazine}}). --] (]) 10:22, 13 July 2020 (UTC)
: There would be yet another way how this could be solved: Given that providing the PDF icon and a "(PDF)" text is redundant, we could simply suppress the "(format)" text if it resembles one of the external link types recognized and indicated by specific icons. If {{para|format}} is used to specify something different, it would be displayed as before, but then the icon and the text would not be redundant and therefore look much less out of place than now. --] (]) 18:12, 20 July 2020 (UTC)
::It is not a given that {{tq|the PDF icon and a "(PDF)" text is redundant}}. The pdf icon is rendered by MediaWiki as a css <code>background-image</code> property (]). Because it is not rendered from an html {{tag|img}} tag, it does not support the <code>alt=</code> attribute. In cs1|2, the automatic {{para|format|PDF}} is a way to notify screen-reader-users that the source is a pdf file. That functionality should not be degraded.
::—] (]) 18:56, 20 July 2020 (UTC)
::: I agree, accessibility is important. Still, there are potential remedies for this as well:
::: Instead of completely muting the "(format)" text when it would be redundant because of the icon, the text could then be made invisible to normal users, but left readable for screen-readers only:
:::* https://webaim.org/techniques/css/invisiblecontent/
:::* https://webaim.org/techniques/alttext/#background
::: Or, the global link decoration could be disabled and the PDF icon be displayed locally (as image, and with <code>alt=</code> text).
::: --] (]) 22:57, 20 July 2020 (UTC)
: Well, I proposed various ways how to possibly solve this. If they are undesirable, I think, per Izno's offer in the ] we should switch back to the 2017 behaviour (basically item #1 in the list). It might be a bit blueish at times, but at least it is logical.
: --] (]) 11:32, 10 August 2020 (UTC)
::I was referring you to the discussion where in fact I implemented the newer behavior. I am not interested in returning to the old behavior solely for this concern, and given the general lack of feedback, I'm not sure anyone sees this as a strong concern at this time. --] (]) 20:40, 10 August 2020 (UTC)

== Some maintenance items to upgrade to errors ==

Right now, ] and other friends are nearly always empty because they are nearly always an easy-to-correct error. I would like to propose upgrading them to errors accordingly, which will make them more visible to editors.

To make this easier to do in the future with maintenance messages we decide should be errors, I'd also like to see the error and maintenance system implementations be made the same (save for the obvious distinction). For this latter, I trip up really hard every time I want to get maintenance items turned into errors, and it's making it hard to parse how to make the necessary code modification for display-X.

Any concerns? --] (]) 12:45, 4 July 2020 (UTC)
:After the next update which I am about to announce.
:
:Error messages rely on tables defined in ]. Each error message has four properties: <code>message</code>, <code>anchor</code>, <code>category</code>, <code>hidden</code>. For maint cats, we might define these:
::<code>message</code> always <code>nil</code> or empty string
::<code>anchor</code> a unique value used to link into ] help text
::<code>category</code> the key that tells common <code>set_error()</code> how to handle the issue; maint cat names all begin with 'CS1 maint:' whereas error message cats aren't so consistent
::<code>hidden</code> ignored for maint cats which are always hidden
:{{cl|Pages with inactive DOIs}} is presently a member of {{cl|CS1 maintenance}} but doesn't necessarily belong there. In ] this cat and its dependents are treated as pseudo errors (the categories are created and added to the table <code>z.error_categories</code>. Property and maint cats have their own tables (<code>maintenance_cats</code> and <code>properties_cats</code>). Maint cats can display their names as an editor-option via css, prop cats display nothing.
:
:Before we embark on a messaging rewrite, we should normalize, somehow, the inactive doi handling. Inactive dois are not errors in the sense of cs1 errors like any of the categorized errors in {{cl|CS1 errors}}. Neither are they simple properties because they should be fixed. We could treat inactive dois as maint issues so that editors who have turned on maint messaging can see locate the inactive dois.
:
:Another thing that I would like to do is standardize the location of error messages. We have a mix of locations: some error messages are adjacent to where the element occurs in the rendered citation and the other are all listed at the end. I have a preference for grouping all of the error messages at the end. Maint messaging is all rendered at the end of the citation.
:
:Assuming that we do all of this, the simple case conversion from maint message to error message is to change <code>category</code> to the correct error cat; add the appropriate error message in <code>message</code>, and set <code>hidden</code> to the appropriate boolean.
:
:No doubt, this enumeration is incomplete ...
:—] (]) 15:30, 4 July 2020 (UTC)
::Speaking of error messages, it might be worthwhile to also improve the preview messages on duplicated parameters so that they provide some location information. In articles with many citations it sometimes takes quite a while to spot the citation using f.e. {{para|date}} twice. --] (]) 07:58, 7 July 2020 (UTC)
:::{{Re|Matthiaspaul}} That's a MediaWiki feature, unrelated to the citation templates. But there's a script, ], which can tell you which template call has the duplicate. -- ] (]) 08:42, 7 July 2020 (UTC)
:::: Thanks, John. --] (]) 14:27, 7 July 2020 (UTC)
:The error message function has been renamed <code>set_error()</code> → <code>set_message()</code> and been modified so that it will emit maintenance category 'messages' when the <code>message</code> property for that message is <code>nil</code>. Maint messaging is now part of the <code>error_conditions{}</code> table in ]; TODO: rename that table.
: :
:If that is true, why (as I write this) is {{cl|CS1 errors: DOI}} empty?
:]
::<syntaxhighlight lang="wikitext" inline="1">{{PAGESINCATEGORY:CS1 errors: DOI}}</syntaxhighlight> → {{PAGESINCATEGORY:CS1 errors: DOI}}
:—] (]) 14:37, 30 July 2020 (UTC)
:—] (]) 22:47, 17 December 2024 (UTC)
::@]: The article ] has a DOI of 10.70460/jpa.v7i1.183 in reference #1 that is incorrectly giving a "<code>Check |doi= value</code>" error. Could you please help fix this? ] (]) 19:41, 19 December 2024 (UTC)
:Fixed in sandbox:
<div style="margin-left:3.2em">{{Cite compare |template=journal |last=McNiven |first=Ian J |date=2016 |title=Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea |journal=Journal of Pacific Archaeology |volume=7 |issue=1 |pages=74–83|doi=10.70460/jpa.v7i1.183 }}</div>
:—] (]) 20:06, 19 December 2024 (UTC)


== spurious errors when fetching identifier limit data from commons ==
I worked my originating request as a result of this rework, which moves display_names messaging (inconsistently error and maintenance) to strictly errors. , and . Perhaps of note that this changes the error for the "don't know" case from invalid_param_values to disp_name; I made that change to centralize all the disp_name errors fixing. There may be further work that should be done so the other use of that error can be more definite. --] (]) 22:50, 8 August 2020 (UTC)


cs1|2 stores identifier limit values in tabular data on commons: ]. This little file allows us to keep identifier limits for all wikis using a recent version of the cs1|2 module suite up to date. Alas, there is some sort of spurious 'something' that sometimes causes the data fetch to fail. Currently, when a failure occurs, all cs1|2 templates on a page render a shrieking-red error message: {{error|Lua error in Module:Citation/CS1/Configuration at line 2083: attempt to index a boolean value}} and complaints at various help and village pump pages. The fix is a null edit.
One other thing: I am not personally convinced that we need 5 categories to handle display_names issues. I think 1 would suffice. Seeking feedback on that point. --] (]) 22:52, 8 August 2020 (UTC)


I have tweaked the sandbox so that it traps the boolean return, sets the identifier limits to 99,999,999,999 which will cause all limit checks to pass, and adds the page to {{cl|CS1 maint: ID limit load fail}}. Articles collected in the category can be null edited to clear the category. Unlike all other maintenance categories, this category does not have an accompanying {{color|#3a3|maintenance message}} because it would be repeated by every cs1|2 template.
== Editors ==


I tested this new code by disabling the category namespace limit so that a cs1|2 template in my sandbox would emit the error category when I forced a boolean <code>false</code> return from the data fetch.
Rats, I thought I might be able to make deprecating {{para|editors}} in this release. Just south of 800 to go. :^) --] (]) 02:50, 7 July 2020 (UTC)
:I'd be against deprecating {{para|editors}} much like I'd be against deprecating {{para|authors}}. They're convenient when you don't have the time or willpower to add {{para|editor-last1}}/{{para|editor-first1}} to {{para|editor-last#}}/{{para|editor-last#}} to a long list of editors. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 13:36, 7 July 2020 (UTC)
::It is already deprecated by the presence of ]. --] (]) 14:03, 7 July 2020 (UTC)
:::That's not deprecation, that's marking the usage as "not ideal, could probably be better". Very different things. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 14:35, 7 July 2020 (UTC)
:::: I have yet to be reverted in some 4000 edits removing the parameter. That's functionally deprecated, even if "CS1 maint" didn't give a strong clue as to our opinion on the condition existing. --] (]) 14:56, 7 July 2020 (UTC)
::::I'd be against deprecating those two parameters also. (And by the sound of it, they're not deprecated, strictly speaking, just advised against.) Authors= and Editors= allows for situations where there are multiple individuals to name but some are credited under "with", ie they appear to be afforded a lesser credit (and a smaller font size) on a book cover and title page. This is often the case with autobiographies (for journalist co-writers) and revised editions of multiple-author works (where a previous editor might be credited under "with" because content from a previous edition is reproduced without any change). Besides, as ever, I wish template editors here would stop trying to jam an overly simplified, one-size-fits-all model down everyone's throats ... The important thing is to present the source accurately. ] (]) 15:01, 7 July 2020 (UTC)
:::::I would be shocked if you need "with" to do so. Even if "with" is important, and you don't want to include that person as an {{para|editor<sub>n</sub>}}, you have {{para|others}} to express in total free-text the full relationship of {{em|any}} other people involved in the work. I have removed several "withs" in my run to remove {{para|editors}} ("with", er, replacement as a "full" editor) and again, no reversions if in fact anyone cares that deeply. --] (]) 15:26, 7 July 2020 (UTC)
::::::Well, you'll just have to be shocked then, won't you. I'd happily revert every single instance where including "with" ensures the ''''correct'''' author/editor credit appears. But that's because I write articles rather than gnome away. ] (]) 15:37, 7 July 2020 (UTC)
:::::Including attribution text in the rendering of a citation is one of the purposes of the {{para|&lt;{{var|name-list}}>-mask}} parameters – this particular use in mentioned in the ]. ] can be rewritten to avoid {{para|editors}} and maintain the proper metadata:
::::::<code><nowiki>{{cite book/new |last=Marcus |first=Greil |authorlink=Greil Marcus |chapter=The Beatles |chapter-url=https://greilmarcus.net/2014/07/11/the-beatles-1979/ |editor=DeCurtis, Anthony |editor2=Henke, James |editor3=George-Warren, Holly |editor-mask3=with George-Warren, Holly; |editor4=Miller, Jim |title=The Rolling Stone Illustrated History of Rock & Roll: The Definitive History of the Most Important Artists and Their Music |url=https://books.google.com.au/books/about/The_Rolling_Stone_Illustrated_History_of.html?id=ubWAht7N7zsC&redir_esc=y |year=1992 |orig-year=1979 |publisher=Straight Arrow |location=New York |isbn=0-679-73728-6 |via=greilmarcus.net}}</nowiki></code>
:::::::{{cite book/new |last=Marcus |first=Greil |authorlink=Greil Marcus |chapter=The Beatles |chapter-url=https://greilmarcus.net/2014/07/11/the-beatles-1979/ |editor=DeCurtis, Anthony |editor2=Henke, James |editor3=George-Warren, Holly |editor-mask3=with George-Warren, Holly; |editor4=Miller, Jim |title=The Rolling Stone Illustrated History of Rock & Roll: The Definitive History of the Most Important Artists and Their Music |url=https://books.google.com.au/books/about/The_Rolling_Stone_Illustrated_History_of.html?id=ubWAht7N7zsC&redir_esc=y |year=1992 |orig-year=1979 |publisher=Straight Arrow |location=New York |isbn=0-679-73728-6 |via=greilmarcus.net}}
:::::—] (]) 13:03, 8 July 2020 (UTC)
:::::: In another thread I give an example how this could be further improved upon with the introduction of a "smart" placeholder *:
:::::: ]
:::::: --] (]) 12:33, 10 August 2020 (UTC)


—] (]) 01:15, 2 December 2024 (UTC)
:::While I hate running into them in citations, I think, Headbomb has a good argument here for us multi-taskers. Sometimes, they really are convenient: When you are working on something different and don't want to or can't spend time on unrelated stuff, but just want to rush out a citation rather than to not provide the citation at all. However, someone will have to clean up the mess sooner or later. Putting them in a maintenance category is good, but perhaps we could also display a warning in article preview so that whoever edits the article will be made aware of the messy citation. Also, the parameters should be further marginalized in the documentation. This way, we could, perhaps, keep them longtime, but still reduce their use to a minimum.
:This seems like a functional workaround. Is it worth reporting a bug to Phabricator to get at the root cause, which may be affecting other processes on MediaWiki sites? A developer may be able to poke through logs to find out why this failure is occurring. – ] (]) 21:38, 2 December 2024 (UTC)
::: --] (]) 15:02, 7 July 2020 (UTC)
::There is ] which may be related.
:::: I empathize with the "convenient" argument, but after clearing out 5000 pages (some credit to Ttm who picked up a few hundred), I much-more-deeply empathize with the "as an author, do your job and indicate clearly who is an editor and who is not in the CS1/2 style". :) --] (]) 15:26, 7 July 2020 (UTC)
::—] (]) 22:32, 2 December 2024 (UTC)
:::::I'd be down for making most maintenance messages visible in previews (something like {{Xt|Preview message: consider replacing {{para|editors}} with {{para|editor<sub>n</sub>-last}}/{{para|editor<sub>n</sub>-last}}}}). &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 16:28, 7 July 2020 (UTC)
::::::Which is why we have ]. --] (]) 16:31, 7 July 2020 (UTC)
::::::Sounds like a good solution. ] (]) 16:39, 7 July 2020 (UTC)
And just now finished the category off save for some drafts that would be better off G13d. --] (]) 00:28, 8 July 2020 (UTC)
:: Call me ignorant, but what does G13d stand for?
:: --] (]) 12:45, 21 July 2020 (UTC)
:::{{slink|Misplaced Pages:Criteria_for_speedy_deletion#G13._Abandoned_Drafts_and_Articles_for_creation_submissions}}
:::—] (]) 13:20, 21 July 2020 (UTC)
:::: Thanks. :-) I was somehow trying to match that with numeronyms like ] or ]... ;->
:::: --] (]) 13:38, 21 July 2020 (UTC)
:So we should mark {{para|editors}} as deprecated. Because cs1|2 will never be smart enough to correctly parse-apart a string of human names in all of their possible forms, separated by an often inconsistent variety of separator characters, names listed in {{para|authors}} and {{para|editors}} have never and will never be included in the citation's metadata. It is time to deprecate and remove {{para|editors}}. Now seems as good a time as any.
:—] (]) 13:03, 8 July 2020 (UTC)
::That will just lead to further abuse of {{para|editor}} to contain multiple editors, without the benefit of the maintenance category. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 13:30, 8 July 2020 (UTC)
:::Possibly, but such misuse is caught and categorized in {{clc|CS1 maint: multiple names: editors list}}.
:::—] (]) 14:07, 8 July 2020 (UTC)
:::: Does it suppress metadata for as long as this condition applies?
:::: Can this condition be indicated in preview as well?
:::: --] (]) 14:21, 8 July 2020 (UTC)
:::::Multiple names in single-name parameters are all shoehorned into a single key/value pair in the metadata because cs1|2 expects, and the documentation requires, one name per parameter. The whole list of names is present but the metadata are corrupted because each name should be in its own k/v pair. As I said before, cs1|2 is not smart enough to parse-apart a list of human names.
:::::
:::::If editors have maintenance messaging turned on, the messages are always visible.
:::::—] (]) 14:47, 8 July 2020 (UTC)
:::::: Okay, but if the template can detect that there seems to be more than one name given in a single {{para|author}}/{{para|editor}} parameter in order to put it into a maintenance category, this could also be used to suppress metadata creation until someone has checked the issue and either splitted the list into many parameters or used (()) to ]. With (()), metadata creation would be turned on again, warnings disabled, and the citation would no longer be put into a maintenance catagory.
:::::: With this metadata suppression in place and with warnings shown to ''anyone'' (not only those who opted in) in preview, I think, we could safely deprecate the {{para|authors}} and {{para|editors}} parameters. Headbomb's concerns, that people will then use {{para|author}}/{{para|editor}} to "park" name lists, will likely hold true, but with metadata suppressed and warnings in place, no harm would be done by this and the situation would likely be fixed earlier than having dedicated parameters to take ''multiple'' names. Appears like a good compromise and "best of both worlds" approach to me.
:::::: --] (]) 13:54, 9 July 2020 (UTC)
There are sufficient other maintenance/error categories and correct uses of the templates that I have made changes to the sandboxes to mark editors as deprecated:
{{cite compare |mode=book |authors=Authors |editors=Editors |title=Title}}
--] (]) 14:02, 16 July 2020 (UTC)


== cite episode id parameter silently ignored ==
== Wikidata identifiers ==


{{tl|cite episode}} currently silently ignores {{para|id}}. I have been using it to add IMDb identifiers to some items, eg. ] using {{tl|IMDb ID}}. I propose that we display the {{para|id}} parameter just like most other CS1 templates. A more elaborate discussion of IMDb in particular as an identifier is at {{slink|Misplaced Pages talk:IMDb link templates#IMDB as an identifier in citations}}. ] (]) 22:44, 4 December 2024 (UTC)
I would like to see a {{para|wikidata}} parameter added to CS1. With the advent of things like {{wdq|Q45340488}} and {{wdq|Q22321052}} we now have a large body of scholarly articles indexed in Wikidata. I have manually added a few via {{para|id}} (which can be found via ]). I can understand the resistance to added any and all such identifiers (e.g., {{wdp|P4028}}, {{wdp|P4011}}, {{wdp|P6366}}, {{wdp|P2409}}, etc.; many more can be found at ]) however, I believe we should at least support our own WMF identifiers and then the rest can be linked from there. Thank you, —] (]) 17:20, 8 July 2020 (UTC)
:{{para|id}} was:
:I disagree. The purpose of a citation is to help the reader find a publication. The citation is not meant to be a list of all the places that have cataloged the publication. So please explain how your addition will help the reader find the publication. ] (]) 17:27, 8 July 2020 (UTC)
:*initially supported at ] 25 May 2009
::{{re|Jc3s5h}} It sounds like you are advocating more for adding things like {{wdp|P724}}. Have you looked at some the Wikidata records? For example, {{wdq|Q56672530}} has many links to actual PDFs of the article via {{wdp|P953}}. I do not see how this is much different from the likes of {{para|citeseerx}}, etc. —] (]) 17:31, 8 July 2020 (UTC)
:*reverted at ] 7 August 2009
:::This reminds me of {{tl|cite doi}} and its friends, which were rejected in multiple discussions: ] (Sep 2014) and ] (Sep 2015). Those discussions mentioned Wikidata as a possible repository for citation information, but I haven't seen any move in that direction. I think the original idea was that something like {{tl|Cite Q}} would be used in place of {{tl|cite journal}} rather than adding wikidata options to CS1 templates. I could be misremembering, though. – ] (]) 17:54, 8 July 2020 (UTC)
:*updated to use ] and simultaneously usurped as a vehicle to support {{para|network}} and {{para|station}} at ] 2 April 2012
::::{{re|Jonesey95}} if it isn't already, {{tl|Cite Q}} could just be a wrapper for CS1 pulling data from Wikidata and filling in fields. —] (]) 18:02, 8 July 2020 (UTC)
:Because it was the goal of the wikitext-to-module conversion to be transparent, it was necessary to overwrite whatever might be assigned to {{para|id}}. I do not recall any discussion here suggesting that we should change that.
:::::{{tlx|cite Q}} uses {{tlx|citation}} so that it can do both periodica and book type citations.
:::::—] (]) 20:03, 8 July 2020 (UTC)
::::Adding an identifier (as suggested here) is somewhat different than {{tl|cite Q}}, which is the parallel to {{tl|cite doi}}. --] (]) 18:00, 8 July 2020 (UTC)
:I'm not enthusiastic about this. There is ongoing discussion (thankfully, mostly elsewhere) where one camp apparently believes that identifiers are wholly ignored by readers because the readers don't know what the identifiers are so won't click them to get to a copy of the source. If that is true, you can be sure that no one will ever follow a wikidata identifier link and, even were they to do so, the wikidata presentation is so user-unfriendly that readers will flee from it.
: :
:I am not enthusiastic about making a change just to support an identifier for a source that editors at ] have determined to be generally unreliable.
:There is a possible issue of copyright. I notice that the example of Knuth's "Semantics of context-free languages" is behind a paywall at the publisher ({{doi|10.1007/BF01692511}}) yet there are 7 purportedly 'free' copies available under the 'full work available at URL' heading at ]. What is the copyright status of all of those?
:—] (]) 00:20, 5 December 2024 (UTC)
:
:I've commented at the other discussion, there's general agreement that IMDb should not appear in references. I don't see how a courtesy link to an unreliable source can help with verification. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 01:16, 5 December 2024 (UTC)
:And then there is the perennial issue of wikidata reliability ...
::I apologize for the delay in responding. {{u|Gonnym}} of ] two days after I raised the question here, making it difficult for me to determine how the template had been used. I strongly disagree with {{u|Gonnym}}'s claim that these uses of ] were "not what the ID= is for". It's exactly what {{para|id}} is for. Our current guideline is strong on this topic: {{slink|Misplaced Pages:Citing sources#Links and ID numbers}} says "{{tqi|A citation ideally includes a link or ID number to help editors locate the source.}}" Thus, '''according to this ]''', for these audiovisual materials where no link is suitable, '''some identifier ''should'' be included'''. I don't make a point of adding identifiers of this kind to citations generally, and I'm not sure I would advocate for the strength of that guideline's wording, but I believe that identifiers are beneficial to include for obscure content, such as old episodes of broadcast news. Contra {{u|ActivelyDisinterested}}, an identifier is not a ].
:—] (]) 20:03, 8 July 2020 (UTC)
::This leads to the question of which identifier to use. Contra {{u|Trappist the monk}}, I don't think it matters whether IMDb is a reliable source. It matters whether its identifiers are ambiguous by being either underspecified or conflations. IMDb's primary benefit isn't the quality of its data or it's market share as {{u|Folly Mox}} suggests, but the breadth of its coverage. Other websites ] itself use its identifiers. If other identifiers were available, I would prefer to use them, but for items with no other identifier, we must use what we have.
::Six of the seven copies to which you refer are on .edu domains. <span class="vcard"><span class="fn">]</span> (<span class="nickname">Pigsonthewing</span>); ]; ]</span> 21:17, 8 July 2020 (UTC)
::For example, I think this citation (featuring a permanently dead link with no archives available) would be greatly benefited from the addition of an identifier from IMDb or anywhere else:
:::Just because a University uses a reference in a course and uploads it to the internet for use of its students (presumably under fair-use terms) does not mean the original copyright holder has surrendered their rights. We need to be very careful about linking to such things. What is appropriate fair use for a student on a course is not necessarily fair use for random members of the public.] (]) 21:38, 8 July 2020 (UTC)
::* {{cite episode | people=Mansbridge, Peter (host); Zaccardelli, Guiliano (guest) | title=Zaccardelli - On Maher Arar | url=http://www.cbc.ca/mrl3/23745/thenational/archive/zaccintvu-090308.wmv | series=] | publisher=] | airdate=September 3, 2008 | url-status=dead}}
::::I checked one of the two instances of ] being used in a CS1 citation, in this case at ]. When I click through to the Wikidata page, I am met with a page whose title does not match that of the cited journal article, and also with a list of seven links to download the article. This article is not freely available; access to its contents is . Such linking is forbidden by ], which reminds us that {{tq|Knowingly and intentionally directing others to a site that violates copyright has been considered a form of contributory infringement in the United States}}. I did not see a corresponding page at Wikidata; clicking on "Wikidata item" from WP's copyright page leads to an irrelevant page, and I did not find a copyright policy linked at ]. I could just be bad at finding things, though.
::I can't find anything about this episode on the internet except https://www.cbc.ca/news/canada/zaccardelli-faults-u-s-government-for-arar-s-deportation-1.757351 .
::::
::Perhaps a better solution than linking to IMDb would be to link to Wikidata using {{tl|QID}}. Wikidata's primary web interface isn't very navigable for readers, so perhaps a link target of Reasonator () or SQID ()? Forcing editors who want to add identifiers to create a Wikidata item linked to IMDb instead of using IMDb directly is more work for editors, which you may or may not find desirable. Searching revealed no existing policy or RFCs on using Wikidata an identifier in citations. ] (]) 02:04, 24 December 2024 (UTC)
::::TL;DR: It appears that this Wikidata entry, chosen at random, is violating US copyright law, as least as described at en.WP's copyright page. I don't see how we can in good faith link to such Wikidata entries, over which we have no control or oversight. – ] (]) 18:36, 9 July 2020 (UTC)
:::The us of Wikidata on Misplaced Pages still has to comply with the consensus on Misplaced Pages. So using Wikidata to obfuscate a link to IMDb in a reference when there is a consensus against using IMDb in references sounds like a bad idea. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 10:52, 24 December 2024 (UTC)
:::::{{anchor|WD-P953}}Apparently, according to the discussion at ], the "full work available at URL" property under which those urls were listed was, until 2017, primarily intended and documented to be used for free links to non-free works. I.e., piracy. The property documentation now says it should be for "legal online providers" of the resource, but obviously from your example that's not very carefully enforced. —] (]) 19:01, 9 July 2020 (UTC)
::::{{re|ActivelyDisinterested}} I wouldn't call this obfuscating a link to IMDb. As far as consensus on Misplaced Pages, we have a content guideline that requires the use of an identifier. That's as strong a consensus as it gets on Misplaced Pages. If this local consensus wants to argue against the use of IMDb as a identifier, I may be willing to accept that if Wikidata is preferred instead. At this local venue, we don't have the option of overruling a content guideline, and so may not forbid both IMDb and Wikidata. ] (]) 15:11, 24 December 2024 (UTC)
::::::It is one thing to criticize Wikidata for copyright issues (linking or otherwise) but I do not see this as substantially different than linking to "] " which the same reference on ] also refers to with {{para|s2cid|2556127}}. You will notice Semantic Scholar also has a links to the full content—possibly in copyright violations as well. How is {{para|s2cid}} which already exists better than a potential {{para|wdqid}}, {{para|qid}}, or {{para|wikidata}}? If anything Wikidata is more readily accessibly and such issues could be more easily rectified. If not linking to something because it has issues is a compelling argument, I would advocate we should not allow linking to some other non-English Wikipedias (or even some local articles which are not in good shape in such regards). —] (]) 04:56, 17 July 2020 (UTC)
:::::::I agree that linking to this paper's s2cid page is not substantially different from linking to its Wikidata page. Both the s2cid page and the Wikidata page clearly link to freely downloadable copies of copyrighted material, in apparent contravention of copyright law. I think that we at Misplaced Pages should not link to that s2cid page or to the Wikidata page from any articles until the links to copyvio material have been removed. – ] (]) 05:40, 17 July 2020 (UTC)
:::::::: I see your point, but I think you put too much weight on one possibly weak spot completely ignoring the potential benefits.
:::::::: First of all, most of the listed links on these sites probably go to works which are legal to share, and second, at least in my judgement, links to copies of a work are the least interesting thing why we would want to link to Wikidata specifically:
:::::::: Wikidata is about semantic organization of data and advanced data retrieval and research methods around this concept - something that is not in the scope of citations at Misplaced Pages, but nevertheless is in the scope of at least some among our audience. For example: When I read about a topic, I am typically not only interested in the topic in itself, but also in the context, the history, etc. If I read a citation, I quite often do not only want to learn about the contents of the work, but also about the circumstances when the work was written, in the publication history, in the author (education, life, philosophy), the publisher (history as a company, other publications), other related works on a subject by the same or other authors or publishers, etc. To me, this is interesting in itself (YMMV), but studying the background often enough has helped (me) to get a better insight into a topic, and it also helps to improve the contents and citations in Misplaced Pages. Wikidata is (or will be) a resource for semantic research beyond what Misplaced Pages provides, so IMO it is quite important that we establish a link to the corresponding entries there.
:::::::: On a different matter, I do not in any way endorse the illegal distribution of works, but legally, it is not the act of pointing to, but the act of making available without appropriate license and the act of using of such material, that is illegal. By itself, pointing to is a neutral act, unless it would be deliberately misleading like advertising a link as a ''free'' download when the material is in fact not free. It is a (common) misconception to assume that anything that "opens" (without password) when clicking on it is free, and, by extension, that anything that is not free would be illegal to link to. By providing a link to Semantic Scholar or Wikidata, we do not assume responsibility for them.
:::::::: Also, as Uzume has pointed out already, in the case of Wikidata, we at least have means to correct problems there. Whenever we do, we help to reduce the amount of incorrect information floating around in the net, and since (among others) Wikidata is used by information providers which in turn are used by our editors, this will indirectly also help to reduce the amount of crap that gets imported into Misplaced Pages (by refill, citoid, etc.) So, helping them, we indirectly help ourselves.
:::::::: --] (]) 16:02, 17 July 2020 (UTC)


:::::The guideline doesn't require the use of an identifier, and certainly not these proposed identifiers. ] (]) 15:14, 24 December 2024 (UTC)
It's high time we have a Wikidata identifier (and possible one that's automatically appended when there's a matching doi/whatever). It's one database amongst many, but one we should highlight. If something is wrong on Wikidata, it's like anything on Misplaced Pages. Fix it. This is very different from {{tl|cite Q}} which ''imports'' things from Wikidata, and which should never be done. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 22:49, 8 July 2020 (UTC)
:::::No there is a strong general consensus across multiple discussions to not link IMDb in references, working out ways to circumvent that consensus is unadvisable.
:The problem with "so fix it" is that there is already plenty that needs fixing on Misplaced Pages without taking on responsibility for another project. ] 10:59, 12 July 2020 (UTC)
:::::Also the guideline also doesn't agree with your interpretation. It doesn't say that an ID is ''required'', it says ideally an ID can be included if it helps locate the source - IMDb doesn't help in locating the source. Even if it did require such a link that still wouldn't support your point, as it doesn't say that link must be to IMDb. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 15:29, 24 December 2024 (UTC)
:: I share most of the concerns regarding Wikidata (user interface, reliability, etc.), but nevertheless I think that it would be beneficial for ''both'' projects if semantically related entries are linked. For this, we do not have to take on responsibility for Wikidata. A link makes it easy to compare the data and possibly correct incorrect information, thereby reducing the amount of bogus info floating around in the net, which will indirectly also help us because auto-fill tools retrieving citation data from external resources will less likely import junk. Without a link, it is unlikely that errors will be detected until we would have an article about the title (which then has a link to Wikidata). Also, Wikidata's organization of data can aid further and deeper research in ways which would be out of scope for citations in Wikidata, but which nevertheless might be interesting for people researching a topic.
:::I think it ''does'' matter that IMdB is not a reliable source, and expect most editors would agree. Out of curiosity, is the IMDb page on the episode given as example here (which I could not find) any more informative than the which also includes a "shotlist" element allowing for verification of certain quotes? Does the IMDb page truly {{xt|help editors locate the source}}, or is it a user-generated summary of the source? (Incidentally, but Internet Archive are unable to display it, possibly as a result of their recent lawsuit.) ] (]) 13:25, 24 December 2024 (UTC)
:: --] (]) 11:36, 13 July 2020 (UTC)
::::{{re|Folly Mox}} Thank you for finding those archives! I was unable to do so despite significant effort, and obviously could learn a thing or two about finding them. I would regard the CBC archive summary as essentially the official website for the source, though not a manifestation of the source, and would certainly link to it.
:::So we fill Wikidata with rubbbish and they fill WP with rubbish? I really do not see the point - it is just creating a massive circular mess. - ] (]) 11:40, 13 July 2020 (UTC)
::::I don't expect identifiers to be informative. Is an ISBN informative? An ISBN is a number, not a resolver, a database, or a source. ] (]) 15:39, 24 December 2024 (UTC)
:::: I wonder how you read that from my comment, because I stated more or less the exact opposite. Can we focus on solutions rather than polemics?
:::: --] (]) 12:13, 13 July 2020 (UTC)
Another annual discussion. I'm afraid the position is uncharged. Wikidata still has reliability issues, possible copyvio traps, and circular reference/self-reference problems. CS1/2, which purports to be an aid to avoiding these, has a pretty good fix in place regarding Wikidata already. ] (]) 23:41, 8 July 2020 (UTC)
::Of course Wikidata has issues. Everything does but we are already importing data from there for certain things (I doubt anyone is going to make sitelinks go away anytime soon). That said isn't it high time these things are addressed and made better? Commons also has its problems. I do not think it should just be written off because they exist. Copyvio problems are hard to answer. Sure there is the question if that should be in Wikidata but is it better for us to link to CiteSeerX, Semantic Scholar, or Google Scholar, etc. which has many of the same links? That seems pointless. I agree "fair use" is not context insensitive but public Internet links ''are'', so these are copyvio and security concerns at the point of publication—as it has always been. Our linking to them or not isn't much different than using {{tl|external media}} over Commons and local hosting. Are we policing all the CS1 {{para|url}} values and article external links too? At least one of the <code>.edu</code> links for {{wdq|Q56672530}} is also found at ]. If they are to be policed they should be equally so. Is it better to police them from here or a more consolidated location like Wikidata? My point is that Wikidata is WMF data and as such is our data. For that reason I believe it is foolish for WMF wikis to intentionally ignore such because it might need work. —] (]) 02:56, 9 July 2020 (UTC)
:::Just because we are already doing it for some things does not mean we should expand it to others. There are already numerous problems with the some things, such as short descriptions, and your argument is sort-of circular - "we already use it, so use it". I would oppose pretty much any further integration of Wikidata into this project until that project has got its act together, which looks likely to take years. If you think our syntax etc is mystifying, it is nothing compared to the experiment that is Wikidata and increased obscurity does not make things easier to work with. We are mostly writers, not data scientists. - ] (]) 10:26, 9 July 2020 (UTC)
: I support linking to Wikidata. So far, if we had a Wikidata entry but no Misplaced Pages article about a title or one of its authors, I have used {{para|title-link|:wikidata:Q...}}, {{para|author-link|:wikidata:Q...}} or {{para|editor-link|:wikidata:Q...}} to establish a connection. If we have an article, there is no need to link to Wikidata directly, because the article (or redirect) will (or can) have a link to Wikidata instead. Bots running into iwls such as :<nowiki><language></nowiki>: or :wikidata: can follow the link and check if an article exists in the local Misplaced Pages meanwhile - if so, the link can be updated to point to the local article.
: Obviously, this doesn't work for titles if the citation has a {{para|url}} as well. This is, where a {{para|wikidata}} parameter could be useful.
: --] (]) 10:02, 9 July 2020 (UTC)
*To be fair, this isn't something we should be deciding with just a casual discussion. This should be a full RFC (which makes it painfully clear that we're not asking for a {{tl|cite Q}}/{{tl|cite DOI}} situation, but rather simply supporting links to WD). &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 14:15, 9 July 2020 (UTC)
:*If someone does put together an RFC, <em>please</em> make the question something other than "should a {{para|wikidata}} parameter be added to CS1?" RFCs cause lots of trouble when they are poorly worded and incompletely thought out. If someone here is contemplating an RFC to decide this issue, please start a discussion first to clarify (for both potential supporters and potential opponents) what you are really asking for, functionally, as a change. You are more likely to get the result you want with a clear RFC statement and question. – ] (]) 14:54, 9 July 2020 (UTC)
:::Wow, I figured it would be good to ask here first but I really did not think asking for the addition of a single identifier for a WMF sister project would required extended discussion (not that I am against such). I wonder if it would take as much for other potential identifiers like {{wdp|P8299}} or {{wdp|P5875}} (I am not suggestion they be auto-populated by Wikidata just CS1 parameters with arguments with the same well defined identifier meanings; any potential auto-population can be saved for the likes of {{tl|cite Q}}, etc.). Those can and do store/cache actual copies of scholarly articles much like CiteSeerX does (although I personally feel {{wde|Q22908627}} is the best of the three). —] (]) 17:00, 9 July 2020 (UTC)
::::It is likely that you have a clear vision of what you are asking for, but some of us here do not. Please give an example of how this proposed new parameter would work. Show us what an example cite template would look like in code and rendered. You don't have to actually code the template, just show us a mockup of the rendered wikicode. – ] (]) 17:17, 9 July 2020 (UTC)
It'd be something like
*{{cite journal |last=Smith |first=J. |year=2015 |title=Title of Things |journal=Journal of Stuff |volume=34 |issue=1 |pages=23–45 |doi=10.4321/3210 |pmid=012345 |id=]:]}}
&#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 17:38, 9 July 2020 (UTC)
:Thanks, that helps. So the QID would point to a Wikidata entry for the item described in {{para|title}} for {{tl|cite journal}}? Is that the only template in which {{para|wikidata}} would be supported? Are there a lot of useful Wikidata entries for journal articles? Can you provide a real-world example with a real article? I poked around at Wikidata for a bit, but none of my normal Misplaced Pages tricks like "What links here" work as I expect over there, so I was unable to find a transclusion count, or whatever it is called at Wikidata. – ] (]) 18:19, 9 July 2020 (UTC)
::That would be general parameter for for all CS1/CS2 templates, no different than {{para|bibcode}} or {{para|pmid}}. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 19:04, 9 July 2020 (UTC)
::: Since {{para|wikidata}} is a bit ambiguous and could mean a lot of things (some of which some people seem to be afraid of), perhaps it would make sense to name the parameter {{para|qid}} to make sure that we are linking only to item node IDs, not property IDs - this would also be more in line with the other parameters for identifiers, where we used the abbreviated name. Also, to make it impossible to link to other stuff, the "Q" prefix could be made part of the predefined part of the link, so it would look like:
:::*{{cite journal |last=Smith |first=J. |year=2015 |title=Title of Things |journal=Journal of Stuff |volume=34 |issue=1 |pages=23–45 |doi=10.4321/3210 |pmid=012345 |id=] Q]}}
:::or even just
:::*{{cite journal |last=Smith |first=J. |year=2015 |title=Title of Things |journal=Journal of Stuff |volume=34 |issue=1 |pages=23–45 |doi=10.4321/3210 |pmid=012345 |id=] ]}}
:::If this still isn't short enough to be unobtrusive, we could even think about reducing this to something like:
:::*{{cite journal |last=Smith |first=J. |year=2015 |title=Title of Things |journal=Journal of Stuff |volume=34 |issue=1 |pages=23–45 |doi=10.4321/3210 |pmid=012345 |id=] ]}}
::: After all, the QID number will be used only to establish a connection between the reference and the Wikidata entry, not to cite the work externally, so it is not really necessary to display the ID number in the citation for as long as there is some element a user can click on to jump to the Wikidata entry.
:::--] (]) 10:53, 12 July 2020 (UTC)
::::{{re|Matthiaspaul}} Being so short, I think "QID" is also too ambiguous and it has already been used by others (e.g., ). Why not {{para|wdqid}} which is inline with {{para|s2cid}} which CS1 already has (as a fairly recent addition)? It should perhaps be noted at this point that the QID is not really a Wikidata thing so much as a Wikibase thing. So far there are no other significant Wikibase databases besides Wikidata but nothing stops anyone from using Wikibase for something else in the future (e.g., Commons already has another but so far they are only using specialized MediaInfo entities and otherwise leveraging Wikidata item and property entities). ] is also some related discussion on this topic. —] (]) 03:46, 17 July 2020 (UTC)
::::: {{para|wdqid}} would be another possibility. IMO, it is better than {{para|wikidata}}, but not as good as {{para|qid}} - unless there would be other work or author identifiers named QID in use somewhere:
::::: The you provided lists one other identifier named QID, but it is not used in the context of citations. So far, I couldn't find any information on Commons' regarding how they call their IDs, but unless they would be called QIDs as well, I don't see a problem there as well - we would not link to both Wikidata and Commons, because the link to Commons could be found at Wikidata.
::::: Although this is not a hard requirement, ideally, the name of the parameter would match the abbreviated (official) name of the identifier for consistency, that's why I (still) prefer {{para|qid}}, but would support {{para|wdqid}} as well, of course.
::::: --] (]) 10:19, 18 July 2020 (UTC)
Can someone explain to me what useful information a wikidata link on a reference would provide to a reader of our articles? Because I'm not seeing it. It just looks like clutter to me. If we were storing reference metadata on wikidata and using a template parameter to tell the template code to expand the metadata from there, that would be one thing, but that's not what's being proposed. I don't see the value in making wikidata ids visible to readers. —] (]) 19:05, 9 July 2020 (UTC)
:Things like author affiliation, ]s, possibly other (more obscure) identifiers like holdings/links to specific libraries (e.g. ]) etc... Crossed-linked to information about the journal (e.g. ISSN, OCLC) and so on. It's not the most useful of things, but I'd consider it way more useful than an ISSN link personally. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 20:00, 9 July 2020 (UTC)
::The point of a citation is to enable the reader to find the source of the information should they want to. I'm with {{U|David Eppstein}} here; a wikidata link would provide no useful information to the reader <em>about the citation</em>. (An ISSN link isn't usually useful, I agree, but can very occasionally clarify which journal is meant when there are journals with very similar names or names which have changed over time.) ] (]) 20:16, 9 July 2020 (UTC)
::{{edit conflict}} If an editor thinks {{para|issn}}, {{para|oclc}}, or {{para|isbn}} are needed to identify/disambiguate/help locate a particular source, they're already going to add them to the citation. I'm not why it's useful to send readers to another site in order to get yet another, more obscure or less-useful identifier. IDs like ISSN/OCLC/ISBN are useful outside of the Wikimedia Foundation; if someone has a printed out copy of a Misplaced Pages article, they can use those IDs to fill out, an interlibrary loan request form, to search a library catalog, etc. I realize Misplaced Pages is an online encyclopedia and hence most viewers will be able to click on links (such as the present system of links from OCLCs and ISSNs to Worldcat and from ISBNs to ], which seems more than sufficient to help readers locate sources), but linking Wikidata entries just seems like extra clutter for not much added benefit. Citations are to help readers and editors find the source; being able to find fields like author affiliations and the like seem superfluous to me. ] (]) 20:31, 9 July 2020 (UTC)
:::I usually omit or remove ISSN identifiers for the same reason, unless it's a particularly obscure periodical whose identity might not be clear: they don't help readers locate the specific publication being cited. An ISBN at least goes to the specific book being cited, and can lead to online resources like Google Books or WorldCat, so those are more useful. —] (]) 20:36, 9 July 2020 (UTC)
::::...but ISSNs can ''also'' lead to WorldCat, which quickly lists libraries where issues of the periodical are available? I don't understand that part of your comparison. ] (]) 07:00, 10 July 2020 (UTC)
::::: It should be noted the {{Q|Q43649390}} can be used to link to other things besides the entity page, e.g., ] vs. @ {{Q|Q45340488}} vs. @ {{Q|Q20155952}}, etc. In my opinion some are considerably less "noisy" than others and even better ones could be built for citation purposes (if they do not already exist). —] (]) 05:28, 17 July 2020 (UTC)


== Request to edit note at top of Category:CS1 maint: unflagged free DOI ==
=== Another approach for Wikidata links ===
Thinking about how to integrate support for linking to Wikidata in a way acceptable to most users, I would like to discuss an alternative approach, making such links as unobtrusive as possible (and even conditional on user opt-in) by just providing a small clickable Wikidata symbol ] instead of listing them as "Wikidata:Q123456" or "QID Q123456" among the other identifiers (however, that would be possible as well). {{Anchor|Commons-links}}Commons does this in a similar way already, see f.e. in the "Summary" section here: ]


Hi there! Could someone please update the note at the top of ]? It mentions an issue affecting 17 Misplaced Pages articles, but there are now less than 10 articles in the category. Thanks! ] (]) 17:45, 8 December 2024 (UTC)
Rationale:


:See ]. Also, I wonder why it dropped from 17. There hasn't been a template update in ages... I suspect someone performed bad fixes just to avoid the categorization. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 12:15, 10 December 2024 (UTC)
* Wikidata is our sister project; this might warrant to special case them somewhat compared to other identifiers.
::@]: See ]. I don't know what the correct change should be, so it's better to get consensus here. ] (]) 19:38, 19 December 2024 (UTC)
* Wikidata QIDs are public and mostly static, but they are not designed to be semi-permanent. In contrast to other identifiers, they are not used in the outer world to refer to works in citations. Therefore, it is not actually necessary to present those Q numbers in a citation for as long as we can establish the link.
* {{anchor|IWL-links}}As soon as we have an article about a title (or an author) we do no longer need to link to Wikidata directly, as the corresponding entry can be reached through the "edit" link for inter-wiki links in an article's side bar. Therefore, direct links to Wikidata are often (although not always) a temporary measure in the process to set up infrastructure.
* At least I find it desirable to establish links to Wikidata for authors even more than for works, because author names are often ambiguous and therefore linking entries can help to determine a particular author and avoid possible mix-up of the names in the future (can also be used to help automate the process of establishing iwls).
* {{anchor|Two-links}}Introducing a dedicated parameter like {{para|qid}} or {{para|wdqid}} can help to simplify linking to Wikidata entries for works, but not for authors. In general, using {{para|-link}} parameters with <code>:d:</code> or <code>:wikidata:</code> prefixes is a more flexible approach, with the sole exception of a {{para|url}} external link to a work being provided as well. In this case, the two links should both be given (instead of disallowing this combination as we do when the {{para|title-link}} would not point to Wikidata), with the Wikidata link presented by a Wikidata icon immediately following the external link, only. (If it would be desirable to support {{para|-link}} links to Misplaced Pages articles in ''addition'' to links to Wikidata, a dedicated parameter like {{para|qid}} or {{para|wdqid}} would still be needed.)


== Links to preprint archives ==
Thereby we could integrate Wikidata links in a very "natural" way, {{anchor|No-surprise}}and even indicate to users that the link goes to Wikidata before they have to click the link (per the principle of least surprise and with all implied disclaimers regarding user interface, reliability, etc.). The approach would avoid to actually display the Q number or other extra clutter like "Wikidata:Q123456" or "QID Q123456" in the citation, and links to Wikidata entries for works and authors would work in an identical way.


It is usefull to have the link to arXiv with its own identification numbers in the citation template, but
{{anchor|Example-1A}}Example 1:
* why bioRχiv with the identification identical with the preprint DOI number,
* why not viXra with specific identifiers (as arXiv), and
* why not other archives without specific identifiers (only preprint DOI as in bioRχiv), as medRχiv (https://www.medrxiv.org/), ChemRxiv (https://chemrxiv.org/), EarthArXiv (https://eartharxiv.org/), PsyArXiv (https://osf.io/preprints/psyarxiv), ResearchSquare (https://www.researchsquare.com/) etc.?
] (]) 10:47, 10 December 2024 (UTC)


Proposal: Replace "biorxiv=" by "preprint DOI=" to include other preprint archives. The link to preprint is usefull when the final version is not free to access. --] (]) 11:19, 10 December 2024 (UTC)
: <nowiki>{{cite book |last=Burroughs |first=Edgar Rice |date=1922 |title=Tarzan and the Golden Lion |title-link=:d:Q9081967 |publisher=A. C. McClurg |page=3}}</nowiki>
:: Burroughs, Edgar Rice (1922). '']'' ]. A. C. McClurg. p. 3.


:Simply put, there's almost nothing on vixra we should want to cite. It is not a reliable source, worse than your usual repository of preprints. It's a nutjob farm. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 12:13, 10 December 2024 (UTC)
{{anchor|Example-1B}}Alternative implementation of example 1: If the title would not be included in the link, the icon labels to Wikidata could even be made conditional on user opt-in through CSS, so that they become available only to more advanced users:
:If you want to include a courtesy link to the free preprint, along with a citation to the print version, you can do so after the template but before the closing ref tag. As an example:
:<code><nowiki><ref>{{cite journal |author=Author |title=Title |journal=Journal |url=https://journal.org}} </ref></nowiki></code>
:Gives you the following:
:{{cite journal |author=((Author)) |title=((Title)) |journal=Journal |url=https://journal.org}} <br> -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 14:36, 10 December 2024 (UTC)
::I realize this is not the right place to bring this up, but the Visual Editor should really offer better support for this. ] (]) 22:34, 10 December 2024 (UTC)
::That workaround feels like a kludge. I would prefer to see preprint URL support integrated into the template as a {{code|preprint-url}} parameter, which for some reason, has not yet been proposed in any of the 96 archive pages of this talk page. The ] guideline states, {{xt|"links to such repositories can be used as open-access links for papers which have been subsequently published in acceptable literature"}}, and it would be useful for the template to link to both the paywalled published version and the unpaywalled preprint without any extra workaround. Using a template parameter would also make the preprint URL more machine-readable, compared to using a separate link.{{pb}}For example, I recently cited the following source:
::: {{cite journal |last1=Crowston |first1=Kevin |last2=Wei |first2=Kangning |last3=Howison |first3=James |last4=Wiggins |first4=Andrea |title=Free/Libre open-source software development: What we know and what we do not know |journal=] |publisher=] |date=5 March 2008 |volume=44 |issue=2 |pages=7:1–7:35 |doi=10.1145/2089125.2089127 |url=https://dl.acm.org/doi/10.1145/2089125.2089127 |url-access=subscription |access-date=15 December 2024 |issn=0360-0300}}
::I wanted to also include a link to hosted by the ]. It would have been nice to have a {{code|preprint-url}} parameter that would have allowed me to do this in the {{tl|Cite journal}} template. —&nbsp;''''']'''&nbsp;<small>]</small>'' 22:30, 15 December 2024 (UTC)
:::I've been just putting the preprint URL in {{para|url}}, because the publisher's version is already linked from {{para|doi}}. I realize this creates some confusion about which version the person creating the reference is actually looking at. I don't usually verify that the versions are identical, but if I have significant doubt, I include citations for both the preprint and the final published version in the same {{tag|ref}} with "Republished as/from" between them, with the first citation being the one I was actually looking at. The word "republished" to me leaves open the possibility of more substantial changes than "reprinted". I am surprised that neither {{slink|Misplaced Pages:Citing sources#Say where you read it}} nor {{slink|Misplaced Pages:Citing sources#Dates and reprints}} discuss the issue specifically. I welcome feedback from other editors on my practices.
:::The issue of multiple versions of a work is bigger than just preprints, and {{para|preprint-url}} feels to me like a partial solution to a bigger problem. In some fields (eg. economics, public policy) working papers with multiple drafts distributed over many years are normal prior to publication. ] (]) 16:42, 16 December 2024 (UTC)
::::I've also done that before, and I agree that it can be confusing for the reader, which is why I'm hesitant to include preprints in the {{code|url}} parameter now. Since the sole purpose of the {{code|preprint-url}} parameter would be to present the reader with an open-access link, I don't think it would be necessary to link multiple drafts in the citation template. —&nbsp;''''']'''&nbsp;<small>]</small>'' 08:53, 17 December 2024 (UTC)


== Cite chapter in book with no editor ==
:: Burroughs, Edgar Rice (1922). ''Tarzan and the Golden Lion'' ]. A. C. McClurg. p. 3.


I read part of ] (and somewhat related ]|) and I am not exactly clear on the result of that discussion.
{{anchor|Example-2}}Example 2: Special case if ] {{para|url}} and {{para|title-link}} to Wikidata would be given:


I would like to discuss a related use case to those above discussions which is old books where you have a collection of works in a single book with no editor. This was apparently somewhat common in miscellanies and anthologies compiled in the middle ages. Here is a pretty good example of a miscellany with no editor but with named contributors and chapters: https://mvm.dhil.lib.sfu.ca/manuscript/109. The issue with the current implementation is that the citation will look like the author of the chapter is the author of the entire book because there is no "''in''."
: <nowiki>{{cite book |last=Burroughs |first=Edgar Rice |date=1922 |title=Tarzan and the Golden Lion |title-link=:d:Q9081967 |publisher=A. C. McClurg |page=3 |url=https://books.google.com/books?id=Wrk8AAAAYAAJ}}</nowiki>
:: Burroughs, Edgar Rice (1922). '''']. A. C. McClurg. p. 3.


I don't have many examples but I have seen the form "chapter" ''in'' "book name," without an attribution to any editor, in history journals, so I think this may be common practice.
--] (]) 12:49, 18 July 2020 (UTC)
:What percentage of readers would recognize the Wikidata logo and understand that it is a clickable link? How would this usage meet ]? ] (]) 14:16, 18 July 2020 (UTC)
:: At least the people at Commons seem to assume that the Wikidata icon is already recognized widely enough for using it in their database interface templates (see the Commons link ]).
:: In the first variation of the ] above, the citation title is a clickable blue link as well, with just the Wikidata icon added afterwards. In that case there is almost no difference compared to other icons (like those "external link", "access lock" or "PDF" icons defined here (), in fact, this would be ] than the current state of affairs where {{para|-link}} links show as internal links without any special link decoration, so the users won't know that they will jump to Wikidata before clicking the link.
:: As shown in the ], only in the case that we would have to provide a {{para|url}} external link in ''addition'' to a {{para|title-link}} link to Wikidata, the icon would become a separate element by itself without some label text (except for the <code>]</code> text), but still next to the citation's title. (Same for the alternative proposal to support a {{para|-link}} link to Misplaced Pages and a {{para|qid}} link to Wikidata in parallel - personally, I think, we can treat links to internal articles and links to Wikidata as mutually ], but others might not agree on this.) An alternative would be to list the Wikidata link among the other identifiers as in the other examples ] above. (I support both approaches, but the community would have to agree on only one of them, of course.)
:: In this special case of providing ] links, some users may, for a while, miss the fact, that clicking on the blue title would jump to the external URL or Misplaced Pages's article and clicking on the icon would transport them to the corresponding Wikidata entry instead, but that is something than can be explained in the documentation, and the users would probably discover this by themselves as well. While it would be prohibitive to use a graphical-only element for some essential user interface, I do consider a graphical-only approach acceptable in this particular case because this scenario occurs only when two links are provided at the same time, and because the Wikidata link is a non-essential element. The icon is embedded in the normal text flow of a citation, instead of being some free-floating picture. Therefore, it can be selected even with text-only browsers and screen readers. They would either present the <code>alt=</code> description <code>"Wikidata link to Q9081967"</code> as link label or render the link similar to something like <code><nowiki/>]</code> or <code>]<nowiki/>]</code>. So, the feature is usable even by visually impaired people.
:: Finally, if we present these icons only after opt-in (even better would be to display them by default and mute them after opt-out, if that's technically possible), this would address any concerns regarding it being a non-recognized or "unwanted" icon.
:: --] (]) 18:04, 18 July 2020 (UTC)
::: Following up on this, I meanwhile found {{tl|Cite wikisource}}, a citation template I was unaware of. It is interesting in this context because it does something very similar for links to Wikisource already (although in a dedicated template, and not for ] title links) by appending the Wikisource icon as link decoration to Wikisource links:
:::: <nowiki>{{cite wikisource |editor-first=Hugh |editor-last=Chisholm |chapter=Aard-vark |wslink=1911 Encyclopædia Britannica |plaintitle=] |edition=11 |date=1911 |publisher=Cambridge University Press}}</nowiki>
::::: {{cite wikisource |editor-first=Hugh |editor-last=Chisholm |chapter=Aard-vark |wslink=1911 Encyclopædia Britannica |plaintitle=] |edition=11th |date=1911 |publisher=Cambridge University Press}}
::: Since links to Wikisource are on a middle-ground between internal and external links, I think, per the principle of least surprise, we should incorporate this idea into the other citation templates as well by appending the icon whenever a {{para|-link}} parameter points to Wikisource, that is, when its value is prefixed by <code>:s:</code> or <code>:wikisource:</code>.
::: And, by extension, the same should happen for links to Wikidata, when a <code>:d:</code> or <code>:wikidata:</code> prefix is used in a {{para|-link}} parameter.
::: --] (]) 20:45, 19 July 2020 (UTC)


So I guess my post has multiple aspects:
:::: See also: ]
:::: --] (]) 13:29, 9 August 2020 (UTC)
::Wikidata is our sister project, therefore it reflects worse on us than other sites might when they host pirate links and we boost their signal in doing so. Does Wikidata even have any guidelines or policies about which external links are or are not permissible? When I follow the wikidata link from ] to its equivalent page on Wikidata, I get a page https://www.wikidata.org/Q4657623 with no guidelines and no discussion. Maybe that is only the wikidata item hosting cross-links to different sites' external link guidelines and not the guidelines themselves, but it has no cross-link to Wikidata itself. —] (]) 18:38, 18 July 2020 (UTC)
::: You already linked to the discussion of property "full work available at URL" (P953) ]. I meanwhile found what appears to be the original proposal to add this property: https://www.wikidata.org/Wikidata:Property_proposal/Archive/15#P953
::: From this it can be deduced that the links are meant to point to legal free or non-free resources (including links pointing to resources behind a paywall). Pointing to openly accessible illegal copies of a work are not an intended use, so such links could be safely deleted when spotted.
::: My point is that this is an issue that can't be solved by ignoring it, in particular not ignored by ''us'' as Misplaced Pages is already interconnected with Wikidata in many ways, and (we may like it or not) the WMF is enforcing an even tighter integration in the future. So, if Wikidata looks bad, this ''already'' reflects bad on us. The only solution, as I see it, is to fix the issues at Wikidata as soon as possible. Providing links to Wikidata, as proposed in this thread, can IMO only ''help'' to put the focus on the corresponding Wikidata entries which are relevant for us and clean them up if necessary. As most citations at Misplaced Pages are probably better researched than Wikidata entries, Misplaced Pages's citations could become part of the necessary web of trust for a more reliably future Wikidata. Without a link, problems may continue to exist there for many years to come, which will fall back bad on us.
::: However, in all those years I am linking to Wikidata through {{para|-link}} parameters, I cannot remember a single case where the Wikidata entry contained links to illegal copies of a work. In most cases, the Wikidata entries didn't use P953 at all. If that would have been the case, I would probably have deleted the questionable links there - or would not have provided a link to the Wikidata entry in the first place.
::: Just because we would have integrated support for Wikidata links we are not ''obligated'' to provide such links if there is anything questionable about an entry (and cannot be fixed) there. This is not different from links provided via {{para|url}} - if we find one which is problematic, we would remove it from a citation.
::: So, arguing against links to Wikidata just because ''some'' entries over there are problematic despite the many other entries without issues seems like throwing the baby out with the bathwater to me. To make sure that such links would not be abused, we could add a reminder to the documentation that links to problematic entries should be removed. --] (]) 23:01, 18 July 2020 (UTC)
::::{{re|Matthiaspaul}} I like the idea and the logo is well associated with Wikidata even locally (see ), however, I wonder how this might fly in the face of current policy with regard to icons being the main link target label in main article space, e.g., see {{tl|Wikidata icon}} and and the results of its TFD: ]. On the other hand, we also have things like {{tl|EditAtWikidata}} (albeit with different icon) which is used extensively in main article space as the main link target label for Wikidata links. Perhaps the "edit at" pencil (which is specially locally cached, see ] and ]) would be better specialized with the Wikidata logo behind it (e.g., ], the Wikidata logo with a magnifying/search glass over it and of course ]). The icon used could also further be specialized by having a default icon sizing such as ]. —] (]) 20:17, 19 July 2020 (UTC)
::::: Thank you very much for the links, I wasn't aware of these templates and prior discussions.
::::: I would have no problems using a different icon, if that would improve acceptance (I particularly like the loupe). The pencil icon might be problematic, though, because it somehow implies that we would pull Wikidata contents into the local citation, which we expressively do ''not'' want to do in this proposal.
::::: --] (]) 21:22, 19 July 2020 (UTC)


1. Do journals use the "chapter" ''in'' "book name" form even with no editor? How commonplace is this? My assumption right now is that it is somewhat common.
== Template-specific help in preview ==


2. Should we support such a feature? My thought here is that we should.
Hi, I guess most of us do not remember all parameters supported by the various citation templates, in particular those which are not generic, but specific to certain templates.


3. How should this be supported? We can support this feature without necessarily implementing "''in''" for all book chapters. We could do so by using a new parameter "chapter author," which would then always use "''in''," without having to use it in all cases, for example. There could be multiple ways to achieve this result. I would not like a solution that leaves the
In order to make it easier (quicker) to look up the template specific help page, I propose to let the template display an unobtrusive link to its help page (only) in article preview, either in front of the citation or after it.


Any thoughts or questions on the above would be appreciated. I apologize if this is already a settled point. I did my best to search for previous discussions by searching "no editor" and '"editor" "is unknown"' in the archive. Lastly, if this is already supported, I suggest it be made more clear in the documentation as I could not find it.
This could look like<ref name="Smith_2015"></small>]] {{cite journal |last=Smith |first=John |date=2015 |title=Title of Things |journal=Journal of Stuff |volume=34 |issue=1 |pages=23–45 |doi=10.4321/3210 |pmid=012345}}</ref>


(edit: Reading 'Time to fix "In: <title>"?' again, it is actually the exact same issue. I'm not sure what I thought it meant when I first read it. Somehow I thought it was about citing a chapter of a book where the entire book was written by one author.) ] (]) 22:43, 12 December 2024 (UTC)
{{Reflist}}


:{{U|J2UDY7r00CRjH}}, it sounds here like the problem statement is a citation like {{tq|Author, Chapter. "Chapter title". ''Edited Volume''}} gives the impression that the chapter author contributed all the chapters, but the theory of change is that {{tq|Author, Chapter. "Chapter title". In ''Edited Volume''}} will convey the correct impression?{{pb}}I don't have an alternative solution to propose, but I do note that the opposite problem – volume or even series editors being attributed authorship of chapters – is more common by at least an order of magnitude. ] (]) 13:45, 13 December 2024 (UTC)
{{tl|Cite journal}} would have a link to ], {{tl|Cite conference}} to ], {{tl|Cite book}} to ] etc.
::>the theory of change is that Author, Chapter. "Chapter title". In Edited Volume will convey the correct impression?
::Yes, additionally, it seems that some styles already use this format. I first saw it in this journal article: https://www.tandfonline.com/doi/full/10.1080/09596410.2017.1401797 (paywalled) () ().
::Looking further, I found that the APA Publication Manual (7th Edition) seems to follow this rule:
::<blockquote>Example 47. Entry in a dictionary, thesaurus, or encyclopedia, with group author<br>American Psychological Association. (n.d.). Positive transference. In APA dictionary of psychology. Retrieved August 31, 2019, from https://dictionary.apa.org/positive-transference<br>Merriam-Webster. (n.d.). Self-report. In Merriam-Webster.com dictionary. Retrieved July 12, 2019, from https://www.merriam-webster.com/dictionary/self-report<br></blockquote>
::This is made more explicit in other guides:
::1.
::>Chapter in a book
::>If there is no editor, include the word "In" before the book title. (
::2.
::>Chapters, Short Stories, Essays, or Articles From a Book (Anthology or Collection)
::> Note: If there is no editor given you may leave out that part of the citation.(). This one is a bit ambiguous about what "that part of the citation" refers to. I don't think it includes "in."
::3.
::This
::So the second reason is to be in line with other citation styles. However, I'm not an expert on citation style and I may be missing something. I found these links above by searching 'how to cite volume with "no editor"' on Google. ] (]) 18:52, 13 December 2024 (UTC)
:::I think I agree that {{tq|In ''Edited Volume''}} is clearer. I wonder if instead of a whole new set of {{para|chapter-author''n''}} parameters and their attendant {{code|1=-link=}}s, {{code|1=-mask}}s etc, an easier implementation might be a specific override value for {{para|editor}}, so if it has that value then {{tq|In}} will appear before the book title (kinda like how {{para|author-mask}} will display text exactly as formatted, except numeric values which it displays as a string of dashes). ] (]) 21:45, 13 December 2024 (UTC)
::::An override value for the editor field would also work. Is there a standard value used for such cases? I think "editor=unknown" would work here. ] (]) 23:21, 14 December 2024 (UTC)


== Omitting location parameter when implied by the publisher ==
If even this small <small></small> would be found to be too obtrusive, it could be put into some CSS stuff so that it would show only when an editor has opted in to maintenance messages.


Presently, ] says {{xt|The location parameter should be omitted when it is implied by the name of the work, e.g. ''The Sydney Morning Herald''.}} Does this also apply to the name of the publisher, e.g. ''Cambridge University Press''? I've only just realized I've been conflating the two. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 19:29, 14 December 2024 (UTC)
--] (]) 11:01, 13 July 2020 (UTC)
:I don't think this advice is valid for publishers like CUP, OUP; they often publish in various locations. OTOH, it's probably trivial and doesn't matter. -- ] (]) 08:54, 15 December 2024 (UTC)
*I'm not sure I'd support that specific implementation, but the idea has merit and I'd support some variant of it. Possibly<ref name="Smith_2015">{{cite journal |last=Smith |first=John |date=2015 |title=Title of Things |journal=Journal of Stuff |volume=34 |issue=1 |pages=23–45 |doi=10.4321/3210 |pmid=012345}} ''(Need help? See ])''</ref>
::In my mind, omitting location would imply publication in the eponymous location. But yes, I'm thinking of how necessary the parameter even is in many situations. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 08:59, 15 December 2024 (UTC)
{{Reflist}}
As a preview/opt-in message.&#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 12:42, 13 July 2020 (UTC)
: Whatever we can agree upon. I deliberately tried to make it as short and unobtrusive as possible to not change the general appearance in preview, but if people would prefer longer messages as in your example, I would not be against it, either. --] (]) 12:54, 13 July 2020 (UTC)
: Perhaps something like this (image instead of text) would be aesthetically more pleasing?<ref name="Smith_2015">] {{cite journal |last=Smith |first=John |date=2015 |title=Title of Things |journal=Journal of Stuff |volume=34 |issue=1 |pages=23–45 |doi=10.4321/3210 |pmid=012345}}</ref>


== Citeref: if no year, use year from date ==
{{Reflist}}
: --] (]) 15:54, 13 July 2020 (UTC)
::Really should be at the end I feel, but YMMW. The real question is do we want this as default, or as an opt-in preview, or handled by a separate script? &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 18:45, 13 July 2020 (UTC)


Citeref is an html ID that is used to connect template:harv and template:sfn to cs1.
:::I definitely don’t think it should be the default. It’s confusing for editors to see things in the preview that don’t appear in the finished page, and question marks or comments like “need help?” suggest something is questionable or that editor needs help, implies something is wrong even when it’s formatted correctly. ] (]) 18:58, 13 July 2020 (UTC)
::::This seems like something that could be created as a javascript that would give the little icon or a link for all templates, not just CS1 templates. I see people having trouble with editing a wide variety of templates, putting in incorrect parameters and much more. – ] (]) 19:02, 13 July 2020 (UTC)
::::: Nothing against a script-based solution, but unfortunately I personally couldn't take much advantage of it then as I usually have JavaScript disabled for security reasons...
::::: --] (]) 20:55, 13 July 2020 (UTC)
:::: I don't think this would cause much confusion, as it is self-explanatory. The curious user would click it once or twice to see what it is, and then take it for granted almost as if it would be a style element of the skin. I don't think the user needs a lengthly description in each citation, because once read its purpose is obvious. Some users might even miss the feature for some while, but that's the same with other interface elements - they will be stumbled upon and then used (if intuitive). That's why my preferred implementation would use a link as small as possible - ideally, I would even "reuse" some existing style element (like the "^"), but then it would have to be implemented as part of Mediawiki's <nowiki><ref></nowiki> token rather than inside our local citation templates (however, this won't work because only the citation template itself knows the location of its help page).
:::: If a question mark would draw the wrong association, we could use something like a "book" or "file" icon to indicate "documentation" or even something more abstract like a (diagonally) upwards-pointing arrow (similar to the external-link icon, but pointing in one direction only) to indicate "look up".
:::: --] (]) 20:55, 13 July 2020 (UTC)
::: The reason why I prefer the link in front of the citation (at least when it remains as short as in my example) is because it then "blends in" visually with the other "strange" symbols (like the "1./2.", "^" typically found in front of citations), whereas at the end of a citation there is often other text following (inside the <nowiki><ref></nowiki> block), and it might look "out of place" there or actually cause confusion (when short).
::: If we'd use a long descriptive text label, we would definitely need to frame it for opt-in. If it remains just an icon (or similarly short) this would not be needed (thereby we'd include the large group of "normal" users who don't change their default configuration).
::: --] (]) 20:55, 13 July 2020 (UTC)
:::: Following up on icon prefixes, I just ran into {{tl|cite wikisource}}, a cite template I wasn't aware of. This actually uses a similar format already:
::::: {{cite wikisource |firsticon=yes |editor-first=Hugh |editor-last=Chisholm |chapter=Aard-vark |noicon=yes |wslink=1911 Encyclopædia Britannica |plaintitle=] |edition=11th |date=1911 |publisher=]}}
:::: So, with a question mark icon added in preview mode this would look similar to:<ref name="Chisholm_1911">] {{cite wikisource |firsticon=yes |editor-first=Hugh |editor-last=Chisholm |chapter=Aard-vark |noicon=yes |wslink=1911 Encyclopædia Britannica |plaintitle=] |edition=11th |date=1911 |publisher=]}}</ref>
:::: {{Reflist}}
:::: Not too bad, I would think...
:::: --] (]) 16:20, 19 July 2020 (UTC)
:::: Nice coincidence, when one clicks on "View history" on a page, a circled black question mark icon appears in the upper right corner leading to ]. So, there is even some precedent for this... ;-)
:::: --] (]) 20:58, 19 July 2020 (UTC)


Problem to be solved:
:cs1|2 renders differently in preview mode only when there are archive-url errors. The initial implementation of that queried the <code><nowiki>{{REVISIONID}}</nowiki></code> magic word for every citation whether there were errors or not. That implementation drew the attention of MediaWiki because it took longer to save pages. This because preview-pages are different from saved pages so MediaWiki can't reuse the preview and must parse the wikitext again before it can be saved. See {{slink|Help_talk:Citation_Style_1/Archive_20#archive_url_checks_and_preview_mode}} and the related discussion at {{slink|Misplaced Pages:Village_pump_(technical)/Archive_147#Preview-only_template_warnings_using_REVISIONID_magic_word}}.
:—] (]) 19:17, 13 July 2020 (UTC)


An SQL search over linter errors of citerefs ] gives that ], so no year. It does make sense to look if the year can be fetched from elsewhere. CS1 alone makes 1.7 million out of 3.8 million duplicate IDs, so something has to be done, the status quo is not an feasible outcome.
:: Obviously, I would have used <nowiki>{{REVISIONID}}</nowiki> as well to detect preview mode... Let's loop in ] to see if there is meanwhile another way to detect preview - after all, four years have passed...
:: Is there a CSS class for "preview messages", that is, something that is visible only in preview without being conditional on <nowiki>{{REVISIONID}}</nowiki>?
:: --] (]) 02:22, 14 July 2020 (UTC)


Expected breakages:
::: A bit too much insider jargon for me to decipher if the issue has been worked around by ] in 2019, so I'll drop these finds here for evaluation and comment by those who are familiar with the implementation:
:::* https://gerrit.wikimedia.org/r/c/mediawiki/core/+/294774/ 2019-04-02 "Disable expensive <nowiki>{{REVISIONID}}</nowiki> magic word in miser mode"
:::* https://phabricator.wikimedia.org/T137900 "Deal with poor edit stash hit rate due to Lua modules using <nowiki>{{REVISIONID}}</nowiki>"
:::* https://gerrit.wikimedia.org/r/c/mediawiki/core/+/503685/ 2019-04-15 "parser: use "-" for revision ID for non-preview edit filter parse during save"
:::* https://phabricator.wikimedia.org/T235957 2019-10-19 "Change <nowiki>{{REVISIONID}}</nowiki> from number to "-" in wgMiserMode"
:::* https://gerrit.wikimedia.org/r/c/mediawiki/core/+/570985/ 2020-02-18 "parser: apply $wgMiserMode restriction to REVISIONID for NS_USER/NS_PROJECT"
::: --] (]) 17:26, 15 July 2020 (UTC)
::: On 2019-04-04, ] wrote ():
:::: ''"The magic word <nowiki>{{REVISIONID}}</nowiki> is being deprecated for performance reasons. In the future, it will only return "" (empty string) when previewing edits, or "-" (dash) when reading pages. The release of next week, will only change this behaviour for articles in the content namespaces. It will not change for interface messages and other namespaces (such as talk pages, and user pages)."''
::: So, it basically has reduced to a flag now.
::: Anyway, I would prefer to see such help links in preview rather than saving a few seconds on save. Comments?
::: --] (]) 15:49, 18 July 2020 (UTC)
::: Having reread the other threads, I have come to the conclusion that we can assume the issue as being worked around at least to an extent that using <nowiki>{{REVISIONID}}</nowiki> does no longer cause a significant performance hit that could not be remedied on server side.
::: On 2016-06-22, ]/] wrote (]):
:::: ''We try to do all the work except actually save the edit to the database. If the user does not end up saving the edit or if the user goes back and makes additional changes, we just throw away whatever we computed. But if the user saves the edit, then often times a lot of the work is already done and all we have to do is commit it to the database. Whenever the REVISIONID magic word is used, this whole mechanism is basically subverted, because we can't reliable know in advance what the revision ID is going to be before we save it to the database.''
::: However, with <nowiki>{{REVISIONID}}</nowiki> reduced to something like a <nowiki>{{PREVIEWMODE}}</nowiki> flag, the pseudo-revision ID ''can'' be predicted (even during preview) to be "-" when later saving a page, thus the precompiled page can be reused with no or only minor fixups. What still might differ is the resulting HTML (with or without the help icons), but nobody would keep them from silently generating the HTML for the "-" case during preview already (in addition to the preview itself), so, while this may still require two passes, there is no need to defer the final pass until the user hits "Save", thus no performance penalty on the user side.
::: In the worst case, the feature could be made conditional on citation errors occuring. In this case, it would not show for ''all'' citations in preview but at least for those where errors were detected and thus help is particulary useful.
::: --] (]) 18:06, 19 July 2020 (UTC)
:::: Apparently, none of the three pinged server admins/developers can be bothered to reply. Since the problem apparently no longer exists, let's go for it. --] (]) 12:35, 8 August 2020 (UTC)


https://en.wikipedia.org/search/?search=hastemplate%3A%22Cite+journal%22+hastemplate%3A%22Harvard+citation%22+insource%3A%2F%5C%7B%5C%7Bharvard+citation%5C%7C%5Ba-zA-Z%5C%7C%5D%2B%5C%7D%5C%7D%2F&title=Special:Search&profile=advanced&fulltext=1&ns0=1 shows that among the usages of cite journal and harv there is only one that does not have a number, ] with its reference to Green, but that reference does not have an date, so it will not be affected by the change. Among the usages of cite journal and harv there are none with only page and not date, so nothing expected to break there. Overall, I do expect breakages, but that that they fix more duplicate ID's than they cause issues with harv. One could do an interim solution with both IDs showing up, causing no breakages for harv and sfn in the meantime.
==Publication date==
Is there a different validation for {{para|publication-date}} as it is reporting an error which does not happen if it is {{para|date}}?


Solution:
{{cite journal
|author= Rik Farrow |date= 2018 |editor= Rik Farrow
|url= https://www.usenix.org/system/files/login/articles/login_winter18_01_farrow.pdf
|title= Musings
|journal= ;login |publisher= ] |publication-date= Winter 2018 |volume= 43 |issue= 4 |page= 4 |issn= 1044-6397
}}</ref>


It does make sense to look for an year in date, when year is not given. An editor is not likely to duplicate the year when the date has already been given.
] (]) 21:17, 17 July 2020 (UTC)
:Yes. Seasons, named dates (Christmas, Easter), and quarter dates are only supported by {{para|date}}.
:—] (]) 21:33, 17 July 2020 (UTC)
:: Makes sense to support it in {{para|publication-date}} as well, I guess. --] (]) 11:20, 18 July 2020 (UTC)
::: Thanks. May be documentation could include a note to explain. ] (]) 12:02, 18 July 2020 (UTC)
:::: I would just make {{para|publication-date}} an alias of {{para|date}} and deprecate the long alias or remove it from the docs; we do not need to "advertise" every alias that has ever existed. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 13:04, 4 August 2020 (UTC)


Add the following to line 4115 of Module:Citation/CS1, keeping the line break that is there.
== Template:Cite book needs additional terms ==
<pre>

if Year == nil or "" then
"Template:Cite Book" needs terms for all of the MARC 21 fields, especially total pages, size, etc.] (]) 06:47, 24 July 2020 (UTC)
Year = string.match(Date, "%d%d%d%d")
:Why? The fields you mention are intended for cataloguing books. We are citing them, not cataloguing them. This information does not usually go into citations according to most commonly-used academic citation standards. Making fields for this information will just encourage people to fill them in under circumstances where they would be better off omitted. —] (]) 06:51, 24 July 2020 (UTC)
end
::Agreed. It's actually confusing and detrimental to citations to add claptrap like this, especially total page count, since it's often mistaken for the pages being cited for the information the citation pertains to. And we just have utterly no use for something like "{{para|size|quarto}}". Yeesh. ] anything like ]. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 13:00, 4 August 2020 (UTC)
</pre> ] (]) 15:00, 15 December 2024 (UTC)
:"References" are not just citations. A "citation" only needs to identify a known reference; we need to ''describe'' the reference, for readers not able to just go over to a shelf and pick it up, and to convince the reader that it is in fact a valid reference for the subject of the article. Thus the academic standard does not apply; whether something is published as manuscript, paperback or hardcover does matter. Should there be a different template, "identify book" instead of "cite book"?] (]) <!--Template:Undated--><small class="autosigned">—Preceding ] comment added 06:11, 7 August 2020 (UTC)</small> <!--Autosigned by SineBot-->

=== Fulltext access fields ===
I'm sure the way in which access is indicated in citations has been discussed extensively by the regulars here, and I apologize for my ignorance of your past discussions. Is there a field to indicate that a book is public-domain (in this case, a 2018 work of US government) and the fulltext is freely available online? This will make it obvious that it is easy to verify the cited statement, and increase the likelihood of editors and readers actually doing it. I understand that such access parameters are already common on journal article templates.

An additional winkle here: many medical journal articles are currently freely accessible due to a special action taken by publishers for the COVID-19 pandemic. At some future date to be decided upon by the publishers, they will put the articles back behind paywalls. Public licenses are permanent, but free access may be revoked. I'm not sure how widespread this is, but we might end up with a lot of incorrect information on access. ] (]) 17:29, 8 August 2020 (UTC)
:Does {{slink|Help:Citation_Style_1#Registration_or_subscription_required}} answer your question?
:—] (]) 17:36, 8 August 2020 (UTC)

== |subject-link= and |subject-mask= ==

The other day, I noticed that we don't have {{para|subject-mask}} or any of its enumerated forms. I have added {{para|subject-mask}}, {{para|subject{{var|n}}-mask}}, and {{para|subject-mask{{var|n}}}}
:<code><nowiki>{{cite interview/new |title=Title |subject=Abraham Lincoln |subject-mask=2}}</nowiki></code>
::{{cite interview/new |title=Title |subject=Abraham Lincoln |subject-mask=2}}
:<code><nowiki>{{cite interview/new |title=Title |subject=Abraham Lincoln |subject1-mask=2}}</nowiki></code>
::{{cite interview/new |title=Title |subject=Abraham Lincoln |subject1-mask=2}}
:<code><nowiki>{{cite interview/new |title=Title |subject=Abraham Lincoln |subject-mask1=2}}</nowiki></code>
::{{cite interview/new |title=Title |subject=Abraham Lincoln |subject-mask1=2}}
The {{para|subject}} and {{para|interviewer}} arrays of parameters are used primarily in {{tlx|cite interview}}. Because we don't have non-hyphenated forms of the {{para|interviewer}} parameters and because the preferred form for parameter names is hyphenated, I have deprecated {{para|subjectlink}}, {{para|subjectlink{{var|n}}}}, and {{para|subject{{var|n}}link}}. Here are some simple searches that indicate usage of these parameters:
*{{para|subjectlink}}:
*{{para|subjectlink{{var|n}}}}:
*{{para|subject{{var|n}}link}}:
**constrained to {{tlx|cite interview}}:
—] (]) 22:48, 26 July 2020 (UTC)

== |website= parameter ==

{{hidden ping|Impru20}}How should editors use the |website= parameter? I'm talking about and similar ones. The examples at ] use the website name (in this case, ''Parties and Elections in Europe''), but the automatic citation-creating tool uses the url of the website (in this case, ''www.parties-and-elections.eu''). However, I also tried to use the auto-citation tool with a Misplaced Pages article as the url to test, and it put ''Misplaced Pages'' in the website parameter. Is this a mistake in the auto-citation tool? Thanks, ] (]) 15:37, 27 July 2020 (UTC)
:The tool in question uses a system which has pre-configured settings for some websites (that you could get involved with if interested) and defaults to a certain setting. For e.g. Misplaced Pages, that setting indicates that Misplaced Pages is the website. For e.g. Parties and Elections, that's the default so it adds the website main URL. You should prefer the name if available and provide the URL if unavailable. --] (]) 15:55, 27 July 2020 (UTC)
::{{re|Izno}} To be clear, are you saying that both ''www.parties-and-elections.eu'' and ''Parties and Elections in Europe'' should be listed, or are you talking about the url of the web page (in this case, http://www.parties-and-elections.eu/basquecountry.html) being put in the url parameter? Is either the way I formatted it (prior to Impru20's edit linked above) or the way Impru20 formatted it considered "right" or "wrong"? Thanks, ] (]) 15:59, 27 July 2020 (UTC)
:::{{tq|both www.parties-and-elections.eu and Parties and Elections in Europe should be listed}} No, do pick one or the other. Our guidance at ] is currently the following: {{tq2|1=On websites, in most cases "work" is the name of the website (as usually given in the logo/banner area of the site, and/or appearing in the <title> of the homepage, which may appear as the page title in your browser tab, depending on browser). Do not append ".com" or the like if the site's actual title does not include it (thus <nowiki>|</nowiki>work=], not Salon.com). If no clear title can be identified, or the title explicitly is the domain name, then use the site's domain name. Do not falsify the work's name by adding descriptive verbiage like "Website of " or "'s Homepage". Capitalize for reading clarity, and omit "www.", e.g. convert "www.veterinaryresourcesuk.com" to "VeterinaryResourcesUK.com".}} Does that help you decide? --] (]) 16:02, 27 July 2020 (UTC)
::::Yes, thank you! ] (]) 16:18, 27 July 2020 (UTC)
::::{{re|Izno}} I still have another question about that page. How would you decide if "the title explicitly is the domain name"? ] (]) 16:23, 27 July 2020 (UTC)
:::::Basic duck test. Does it look like the same duck? Yes. Then it's probably the same duck. --] (]) 16:28, 27 July 2020 (UTC)
::::::Thank you for all your help! ] (]) 16:31, 27 July 2020 (UTC)
:Just to clarify further about "both www.parties-and-elections.eu and Parties and Elections in Europe should be listed ...?" Izno and the cited documentation are correct in answering "No." Either is okay; neither are an error, but both is an error. If the work has a proper title, then use that, but the domain name will suffice in absence of one, or if you don't have time to go look. It's okay that automated tools use the domain name, and it's also okay to cleanup up after them and change the auto-cites to use real titles. For a work without a title or whose title is literally its domain name, it's best to shave off the "www." if the site can be reached without it (most of them can, but it's worth testing; I ran into one only two days ago that 404'ed without the "www." prepended to it). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] 😼 </span> 12:56, 4 August 2020 (UTC)

== Support contribution/section in cite journal and others. ==

*<pre>{{Cite journal | first1 = Shana | last1 = Kusin | first2 = Teddy | last2 = Angert | first3 = Katie | last3 = von Derau | first4 = B. Zane | last4 = Horowitz | first5 = Sandy | last5 = Giffin | name-list-format = vanc | title= 2012 Annual Meeting of the North American Congress of Clinical Toxicology (NACCT) October 1–6, 2012 las Vegas, NV, USA | volume = 50 | issue = 7 | pages = 574–720 | url = http://www.ohsu.edu/emergency/about/news/2012/nacct/posters/squash.pdf | contribution= 189. Toxic Squash Syndrome: A case series of diarrheal illness following ingestion of bitter squash, 1999-2011 |journal=Clinical Toxicology | doi = 10.3109/15563650.2012.700015| year = 2012 }}</pre>
Gives
*{{Cite journal | first1 = Shana | last1 = Kusin | first2 = Teddy | last2 = Angert | first3 = Katie | last3 = von Derau | first4 = B. Zane | last4 = Horowitz | first5 = Sandy | last5 = Giffin | name-list-format = vanc | title= 2012 Annual Meeting of the North American Congress of Clinical Toxicology (NACCT) October 1–6, 2012 las Vegas, NV, USA | volume = 50 | issue = 7 | pages = 574–720 | url = http://www.ohsu.edu/emergency/about/news/2012/nacct/posters/squash.pdf | contribution= 189. Toxic Squash Syndrome: A case series of diarrheal illness following ingestion of bitter squash, 1999-2011 |journal=Clinical Toxicology | doi = 10.3109/15563650.2012.700015| year = 2012 }}

It should give something better, like
*Kusin S, Angert T, von Derau K, Horowitz BZ, Giffin S (2012). "189. Toxic Squash Syndrome: A case series of diarrheal illness following ingestion of bitter squash, 1999-2011" in "". ''Clinical Toxicology''. '''50''' (7): 574–720. {{doi|10.3109/15563650.2012.700015}}.
Or maybe
*Kusin S, Angert T, von Derau K, Horowitz BZ, Giffin S (2012). ": 189. Toxic Squash Syndrome: A case series of diarrheal illness following ingestion of bitter squash, 1999-2011". ''Clinical Toxicology''. '''50''' (7): 574–720. {{doi|10.3109/15563650.2012.700015}}.
&#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 18:31, 27 July 2020 (UTC)

:Pinging {{ping|David Eppstein}} since you have a lot of experience there with math citations to sections of journal articles/books. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 18:33, 27 July 2020 (UTC)
::Use {{para|department}}:
::*<pre>{{Cite journal | first1 = Shana | last1 = Kusin | first2 = Teddy | last2 = Angert | first3 = Katie | last3 = von Derau | first4 = B. Zane | last4 = Horowitz | first5 = Sandy | last5 = Giffin | name-list-format = vanc | department= 2012 Annual Meeting of the North American Congress of Clinical Toxicology (NACCT) October 1–6, 2012 las Vegas, NV, USA | volume = 50 | issue = 7 | pages = 574–720 | url = http://www.ohsu.edu/emergency/about/news/2012/nacct/posters/squash.pdf | title= 189. Toxic Squash Syndrome: A case series of diarrheal illness following ingestion of bitter squash, 1999-2011 |journal=Clinical Toxicology | doi = 10.3109/15563650.2012.700015| year = 2012 }}</pre>
::*{{Cite journal | first1 = Shana | last1 = Kusin | first2 = Teddy | last2 = Angert | first3 = Katie | last3 = von Derau | first4 = B. Zane | last4 = Horowitz | first5 = Sandy | last5 = Giffin | name-list-format = vanc | department= 2012 Annual Meeting of the North American Congress of Clinical Toxicology (NACCT) October 1–6, 2012 las Vegas, NV, USA | volume = 50 | issue = 7 | pages = 574–720 | url = http://www.ohsu.edu/emergency/about/news/2012/nacct/posters/squash.pdf | title= 189. Toxic Squash Syndrome: A case series of diarrheal illness following ingestion of bitter squash, 1999-2011 |journal=Clinical Toxicology | doi = 10.3109/15563650.2012.700015| year = 2012 }}
::—] (]) 18:40, 27 July 2020 (UTC)
:::That is very hacky. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 17:16, 30 July 2020 (UTC)
::::It is, as far as I know, the only way to get three levels of titling (title/department/journal) within a journal cite. The other way is to use chapter/title/series or contribution/title/series but then you would have to call Clin.Tox. a series rather than a journal, and the volume/issue formatting would be for a book not a journal, so that's worse. The department is not included in the COinS metadata (and in particular is not coded wrongly in COinS as a department rather than as the title of a special issue). —] (]) 17:35, 30 July 2020 (UTC)

== Please add param error checking for interwikis lacking leading colon ==

Hello, can you please add some error-check code and emit a big, red error message, if an editor codes a "link" param (author, title, translator, editor, contributor are the ones I'm aware of) to a sister wikipedia like fr-wiki without a leading colon on the lang code? What happens in this case, is various kinds of strange behavior, including dropping the field (author, say) and emitting only a semicolon or other punctuation; but worse is that the first of these, whatever it is, is picked up as an interwiki, and the entire article is linked under that language name in the left sidebar. Same thing occurs for fields with permissible wiki-linking, such as publisher. Beyond that, it screws up article links at Wikidata, as soon as their bot sees it.

You can see an example of the faulty behavior in revision ] of ]. Go to the language links in the left sidebar, and notice that the Hebrew and Arabic links point to the correct articles (Google translate does a sufficient job of transliterating the titles to confirm they are correct if you need it) but the French one is wrong, and links to ]. This happens to be the publisher of one of the sources listed in the ] section, namely "Lambert (2010)", but you won't see it on the rendered page, because it's been snatched by the wikimedia code and interpreted as the target of the "''Francais''" link in the language sidebar; all you will see in the Lambert citaton is extra punctuation between "Paris" and the ISBN. To actually see the linked publisher with the missing colon, you have to view the wikicode of ].

You can diff that version with current ('']''), to see that the only change was to add one colon in the Lambert publisher field. Notice that the ''Francais'' link in the sidebar is now correct. (Same thing happens if you forget the leading colon in authorlink, or any of the other *-link fields.) These should be flagged as errors, because they will escape the notice of many users. Also, the bots at Wikidata are rapid, and although I noticed and fixed the problem within minutes, I was too late, and the Wikidata bot had already linked my French Resistance guy at ] to the French publisher ] via item ] ("Éditions Philippe Rey"; '']''). I had to both unlink that connection, then go relink Diethelm to ] instead (same one that has the Hebrew and Arabic articles as well).


:Having the same CITEREF in articles that do not use short form references is not an error that needs solving.
This is too much to ask most users to do. A big, fat, red error for interwiki links that lack a leading colon would be a big help. Thanks, ] (]) 06:04, 28 July 2020 (UTC)
:The year in {{para|date}} is already used if it is part of the cite. However the example in ] (CITEREFGreen) has no {{para|date}} parameter only {{para|access-date}} and {{para|archive-date}} neither of which would be appropriate to include in a short form reference. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 16:35, 15 December 2024 (UTC)
: I added a request for such error handling at ]. Thanks, ] (]) 09:55, 3 August 2020 (UTC)
:{{ec}}
::That discussion closed. One discussion in one place.
:No. At ] line 4114 is this:
::—] (]) 20:06, 4 August 2020 (UTC)
::<syntaxhighlight lang="lua" inline="1">local year = first_set ({Year, anchor_year}, 2); -- Year first for legacy citations and for YMD dates that require disambiguation</syntaxhighlight>
:The {{para|publisher|<nowiki>]</nowiki>}} is not a {{para|&lt;{{var|param}}-link>}} problem; somewhat related, but not the same.
:Normally, <code>Year</code> has been set to <code>nil</code> before this point in the code. <code>anchor_year</code> comes from ].
: :
:This example has {{para|date}} but does not have {{para|year}}:
:I have hacked the module sandbox to catch {{para|&lt;{{var|param}}-link>}} where the assigned value begins with a known local inter-wiki prefix without a leading colon. There are a couple of exceptions. The <code>w:</code> and <code>wikipedia:</code> prefixes do not require leading colon. The <code>s:</code> and <code>wikisource:</code> prefixes have special meaning because cs1|2 creates urls from these inter-wiki links so that it can add the wikisource icon. From the example template, tweaked so that the author wikilink is missing the leading colon:
::<syntaxhighlight lang="wikitext" inline="1">{{cite book |title=Title |last=Greene |first=EB |date=15 December 2024}}</syntaxhighlight> → {{cite book |title=Title |last=Greene |first=EB |date=15 December 2024}}
::<code><nowiki>{{Cite book/new |first1=Gilles |last1=Lambert |author1link=fr:Gilles Lambert |title=Title}}</nowiki></code>
:::{{code|lang=html|{{cite book |title=Title |last=Greene |first=EB |date=15 December 2024}}}}
:::{{Cite book/new |first1=Gilles |last1=Lambert |author1link=fr:Gilles Lambert |title=Title}}
:Note the value assigned to the <code>id=</code> attribute in the {{tag|cite|o}} tag; it has the year portion from {{para|date}}.
:Inter-wiki links are apparently namespace sensitive. The above example shows a linked author name and there is no link under languages to the fr.wiki. When I copied the above example to a random article in en.wiki main space and previewed, the linked author name is missing and fr.wiki is listed in the languages list, linked to Gilles Lambert.
: :
:If you know of cs1|2 templates that do not include the year portion from a publication-date parameter ({{para|date}}, {{para|publication-date}}, {{para|year}}) in the <code>CITEREF</code> anchor id, I'd like to see it.
:The {{para|publisher}} inter-wiki link problem must be handled differently because for the most part, any cs1|2 parameter may be wiki-linked (despite documentation to the contrary). For all parameters in a cs1|2 template that are not {{para|&lt;{{var|param}}-link>}} parameters, inter-wiki links must begin with <code><nowiki>[[</nowiki>&lt;{{var|prefix}}>:</code> where <code>&lt;{{var|prefix}}></code> is a known local inter-wiki prefix, <code>s:</code>, <code>w:</code> and their long-forms again excepted. As each parameter name is validated, the cs1|2 sandbox looks for this pattern and emits and error message when detected:
::<code><nowiki>{{Cite book/new |title=]}}</nowiki></code>
:::{{Cite book/new |title=]}}
:In main space, the title from the above example is missing and fr.wiki is listed in the languages list, linked to Title.
:—] (]) 20:06, 4 August 2020 (UTC)
::There are other kinds of interwiki links that should (could?) be supported such as ]; interlanguage links are the ones that are problematic only. I do not understand why w: and wikipedia: (Misplaced Pages here is presumably its use as an interlanguage link as in ]?) are supported in this way. --] (]) 21:26, 4 August 2020 (UTC)
:::I included the <code>wikipedia:</code> in the exclusion list because it is listed at ] as the long form of <code>w:</code>. But, now that you point it out, <code>wikipedia:</code> the prefix makes no sense because it conflicts with <code>wikipedia:</code> the namespace. No doubt the exclusion list might include <code>]</code> (wikibooks), <code>]</code> (commons), <code>]</code> (wikidata), <code>]</code> (meta), <code>]</code> (wikinews), <code>]</code> (wikiquote), <code>]</code> (wikiversity).
:::—] (]) 22:11, 4 August 2020 (UTC)
::::<code>wikipedia:</code> does not conflict on other wikis as a thought. --] (]) 22:55, 4 August 2020 (UTC)
:::::<code>]</code> on ] links to the en.wiki main page. As a guess, I would say that <code>wikipedia:</code>, the name space, is common on encyclopedia wikis but not on other types of wiki.
:::::
:::::Because <code>]]]</code> appears to be a prefix that always links to en.wiki, I'm wondering if that prefix should continue to be excluded from the error check. Here at en.wiki, the <code>w:</code> prefix gets you to the article in the same way that the <code>en:</code> prefix or no prefix does:
::::::<code>]]]</code>
::::::<code>]]]</code>
::::::<code>]]]</code>
:::::At other wikipedias, the <code>w:</code> prefix links to the en.wiki article but isn't otherwise treated as a inter-language inter-wiki link.
:::::—] (]) 12:53, 5 August 2020 (UTC)
:::: Regarding, "{{xt|Inter-wiki links are apparently namespace sensitive}}", yes; see ]. And that's great that you were able to mock up something in the sandbox for the *-link case so quickly. I realize the other case (publisher, and other fields) is different, and is complicated by the legit shortcut codes that link to ]. Did anyone mention ], ], ], ]? See also, ]. ] (]) 09:35, 5 August 2020 (UTC) <small><small>updated 10:21, 5 August 2020 (UTC)</small></small>
:::::I mentioned <code>]</code> earlier.
:::::
:::::At present cs1|2 tests what it thinks is a prefix against the table of known inter-wiki prefixes returned from <code>mw.site.interwikiMap ('local')</code>. I am minded to change that and instead use the list of languages returned by <code>mw.language.fetchLanguageNames ('&lt;{{var|local wiki lang code}}>', 'all')</code> if I can show that all of the language codes in that list are also found in the inter-wiki map list.
:::::—] (]) 12:53, 5 August 2020 (UTC)
::::::I have changed the code so that ~/Configuration/sandbox creates a list of language prefixes from both <code>mw.site.interwikiMap ('local')</code> and <code>mw.language.fetchLanguageNames ('&lt;{{var|local wiki lang code}}>', 'all')</code>. Prefixes in <code>mw.site.interwikiMap ('local')</code> must match a language code in <code>mw.language.fetchLanguageNames ('&lt;{{var|local wiki lang code}}>', 'all')</code> to be added to the local list. There are seven 'language-like' codes in <code>mw.site.interwikiMap ('local')</code> that 'redirect' to another-language wiki but these codes do not contribute to the inter-wiki language list:
:::::::<code>]</code> → Mandarin Chinese (ISO 639-3 code); redirects to zh.wikipedia.org
:::::::<code>]</code> → Czech (ISO 3166 country code); redirects to cs.wikipedia.org
:::::::<code>]</code> → Danish (ISO 3166 country code); redirects to da.wikipedia.org
:::::::<code>]</code> → Esperanto (ISO 639-3 code); redirects to eo.wikipedia.org
:::::::<code>]</code> → Japanese (ISO 3166 country code); redirects to ja.wikipedia.org
:::::::<code>]</code> → invalid IETF language tag; redirects to zh-min-nan.wikipedia.org
:::::::<code>]</code> → invalid IETF language tag; redirects to zh-min-nan.wikipedia.org
::::::These are not included in the local prefix list.
::::::—] (]) 15:56, 5 August 2020 (UTC)
::::::: Can't remember anymore where I saw it, but there's a case where one type of Norwegian language code&mdash;whether <code>no</code> (Norwegian, in general) or <code>nn</code> (Nynorsk), I can't remember &mdash;is odd man out, wrt to a giant list of WP codes that generally match the ccTLD codes, except for that one case. (There's also Bokmal, <code>nb</code>, but it wasn't that.) This could be a red herring, but just wanted to recall it, in case it's relevant here. ] (]) 03:40, 6 August 2020 (UTC)
::::::::I'm not sure I understand what it is that you are saying. <code>]]]</code> links to the Norsk nynorsk nn.wiki, both of <code>]]]</code> and <code>]]]</code> link to the Norsk bokmål nb.wiki. I do remember that for a time, language code <code>no</code> was not supported by the <code><nowiki>{{#language:}}</nowiki></code> magic word. That has since been fixed:
:::::::::<code><nowiki>{{#language:nb|en}}</nowiki></code> → {{#language:nb|en}}
:::::::::<code><nowiki>{{#language:nn|en}}</nowiki></code> → {{#language:nn|en}}
:::::::::<code><nowiki>{{#language:no|en}}</nowiki></code> → {{#language:no|en}}
::::::::—] (]) 10:30, 6 August 2020 (UTC)
::::::::: Found it, and it doesn't affect this issue, because it's about translation, not linking. If you're curious, it's used at ]; note the diff between {{para|langcode}} and {{para|googlelangcode}}, not found in any other Expand language template (such as ]). The explanation at ] references Nynorsk. So, red herring, as far as we are concerned here. ] (]) 04:28, 7 August 2020 (UTC)

Also, while I'm thinking of it: despite the emission of a CS1 error in preview mode, the editor can still override and save anyway, as shown in your sandbox example above. This is fine, for the *-link case, but not so great for the publisher=<nowiki>]</nowiki> case, because if that link is saved like that, the Wikidata bot will likely do something strange. I don't know if this is beyond the scope of this template, but, for example, could you stop the user from saving it in that form, either by stripping out the brackets, or supplying the preceding colon? If not, maybe in that case we'd need to see about an ] to trap it, but I suppose that would be a discussion for somewhere else. ] (]) 09:50, 5 August 2020 (UTC)
: Hm, maybe not so fine in the *-link case, either; they can both lead to downstream problems of rendering and knock-on issues at Wikidata, if I'm not mistaken. ] (]) 03:47, 6 August 2020 (UTC)
: :
:Editors do {{tq|duplicate the year when the date has already been given}}; {{cl|CS1 maint: date and year}} wouldn't be needed else.
:Tweaks to the code:
::For {{para|&lt;{{var|param}}-link>}} parameters that fail the various link tests (has a url, has wikilink markup, has inter-wiki prefix without leading colon) the code simply unsets the parameter and declares the error:
:::<code><nowiki>{{Cite book/new |title=Title |title-link=//example.com}}</nowiki></code> → {{Cite book/new |title=Title |title-link=//example.com}}
:::<code><nowiki>{{Cite book/new |title=Title |title-link=]}}</nowiki></code> → {{Cite book/new |title=Title |title-link=]}}
:::<code><nowiki>{{Cite book/new |title=Title |title-link=nv:Title}}</nowiki></code> → {{Cite book/new |title=Title |title-link=nv:Title}}
::For {{para|&lt;{{var|param}}>|<nowiki>[[</nowiki>&lt;{{var|prefix}}>:&lt;{{var|value}}>}} the code extracts the label portion of the wikilink:
:::<code><nowiki>{{Cite book/new |title=]}}</nowiki></code> → {{Cite book/new |title=]}}
:::<code><nowiki>{{Cite book/new |title=]}}</nowiki></code> → {{Cite book/new |title=]}}
:These tweaks prevent the addition of extraneous inter-wiki links in the languages list.
: :
:It used to be that cs1 templates did not automagically create <code>CITEREF</code> anchor ids. Some time back, there was discussion:
:That languages inter-wiki list at left must have a proper name. What is that name?
:*{{slink|Help_talk:Citation_Style_1/Archive_46|2=Proposal:_make_ref=harv_the_default_for_CS1}}
:—] (]) 13:31, 6 August 2020 (UTC)
:*{{slink|Help_talk:Citation_Style_1/Archive_66|2=make_ref=harv_the_default_for_CS1}}
::Usually just inter-language list or inter-wiki list. The latter can be ambiguous since the introduction of the inter-project list. --] (]) 14:33, 6 August 2020 (UTC)
: Editors in those discussions decided that all cs1|2 templates would create <code>CITEREF</code> anchor ids, needed or not; the automagic <code>CITEREF</code> anchor id can be suppressed with {{para|ref|none}}. This linter thing is an artefact of that decision.
::: I've always just called it the "language links sidebar" (or "language sidebar", on the second occasion) because I've never seen anyone misunderstand what that means, but I don't know if there's an official term.
:—] (]) 17:01, 15 December 2024 (UTC)
::: Thanks so much for tweaks here and earlier; this is going to really improve things. I wonder how many "stealth errors" are out there&mdash;defining that as something that "seemed all right" until now, that suddenly will generate a CS1 error where it didn't before. Do we care? I imagine editors at the articles concerned will wonder why something turned red that never was before, but all they have to do is click the to find out. This is great stuff, thanks Trappist. ] (]) 03:07, 7 August 2020 (UTC)
:Sounds like the problem is the linter. We already have {{clc|Category:Harv and Sfn multiple-target errors}} for where this is an actual issue. ] (]) 12:37, 23 December 2024 (UTC)


== Using 'First' and 'last' over 'author' parameter ==
=== Proposal to support link decoration not only for links to Wikisource but also for other inter-wiki links ===
: @]: ] you wrote: "''The s: and wikisource: prefixes have special meaning because cs1|2 creates urls from these inter-wiki links so that it can add the wikisource icon.''" I didn't know that and thought it would be a special feature of {{tl|cite wikisource}} rather than a general CS1/CS2 feature. However, trying it out I found that it works only with prefix "<code>s:</code>", not with "<code>:s:</code>":
:: <code><nowiki>{{cite book |title=Aard-vark |title-link=s:1911 Encyclopædia Britannica/Aard-vark |work=Encyclopædia Britannica |date=1911}}</nowiki></code>
::: {{cite book |title=Aard-vark |title-link=s:1911 Encyclopædia Britannica/Aard-vark |work=Encyclopædia Britannica |date=1911}}
:: <code><nowiki>{{cite book |title=Aard-vark |title-link=:s:1911 Encyclopædia Britannica/Aard-vark |work=Encyclopædia Britannica |date=1911}}</nowiki></code>
::: {{cite book |title=Aard-vark |title-link=:s:1911 Encyclopædia Britannica/Aard-vark |work=Encyclopædia Britannica |date=1911}}
: Shouldn't this work for both variants?
: Actually, per the principle of least surprise, I think, it would be useful to add the same functionality also for links to other inter-wiki-links (iwl), but at least for links to the two most important ones, Wikidata (<code>:d:</code>/<code>:wikidata:</code>) and Commons (<code>:c:</code>/<code>:commons:</code>).
: In the case of iwls, the corresponding project logos could be used as icons (as per Wikisource).
: If we would extend the idea to inter-language-links (ill) as well and make it a general principle, we should not display iconized country flags, but instead just append a small text postfix composed of the prefix in square brackets (so, prefix <code>:de:</code> would result in <small></small> being appended to the link, similar to what links created by {{tl|ill}} look like).
: --] (]) 10:09, 9 August 2020 (UTC)
::The <code>s:</code> and <code>:s:</code> prefixes work as they should work. When the {{tlx|cite wikisource}} parameter {{para|noicon}} is present and has a value (do not display the icon), {{tlx|cite wikisource/make link}} creates an inter-wiki link with the <code>:s:</code> prefix; else {{tld|cite wikisource/make link}} creates an inter-wiki link with the <code>s:</code> prefix to show the icon.
::—] (]) 11:01, 9 August 2020 (UTC)
::: Okay, then it is a feature. But is it a ''useful'' feature to have this choice (as part of the link syntax being used, that is)? (This certainly could be controlled in different ways as well.)
::: I would think that in the majority of cases displaying the link decoration would be preferable - after all, we also cannot (at least not on user level) disable the external link arrow icon being displayed for external links. And in cases, where no icons should be displayed for some reason, it would be a template-wide rather than a link-specific setting (therefore having an option like {{para|noicon}} to control it).
::: Either way, if we have it for Wikisource, why not for Wikidata and Commons as well for reasons of consistency?
::: --] (]) 11:58, 9 August 2020 (UTC)


] states that {{para|first}} and {{para|last}} are preferred over {{para|author}}. I recently edited some citations accordingly and . Is there a reason {{para|first}} and {{para|last}} are preferred, or is this indeed a non-issue? ] (]) 00:42, 16 December 2024 (UTC)
== Citing third-party sources embedded in document ==


:Names are not universally consistent either in publishing or the world at large—given authors are generally identified primarily by surname, one can make a clear case for explicit specification. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 00:47, 16 December 2024 (UTC)
I'm trying to cite a newspaper source, for which the paper (or its website) doesn't exist anymore, but copies of the relevant article are embedded in a council ordinance. Can I do that, and if so, what would be the syntax?<br>
::Also, separating them out is necessary if you want short footnotes ({{tl|sfn}}) to link to the reference without a lot of extra hassle working around the lack of surnames. —] (]) 06:01, 16 December 2024 (UTC)
The full ordinance is , and I would like to reference page 106: ''"Success or failure?", Sean Robinson, The News Tribune''. ] (]) 14:23, 29 July 2020 (UTC)


:::Separate first/last names are generally better. As said above, {{tlx|sfn}} and the like work much better with last names. It also allows better web searching for a reference when the source website changes between using between "Dee Lightful", "D. Lightful" or "Lightful". However, sometimes it is hard for us English speakers to know which part of a non-English name is the family name and which is the personal name - eg, in Foo Ling Yu many Westerners don't realise that Foo is the family name (ie the last name in western terms, even though it is at the start of the name) and Ling-Yu is the personal part of her name (ie, the first name in western terms). There are also a few Western names that are hard (eg Douglas, Michael vs Michael, Douglas). Which is why the author field is allowed and does not produce errors - it is the ultimate fallback when you do not know the correct order. Which means that the reverter was quite wrong to revert you based on faulty logic. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 08:01, 16 December 2024 (UTC)
:If I understand correctly, you want to cite the newspaper article directly, as a sort of substitute stand-alone reference. If that is so, the answer is no, that is not correct. We must refer to sources as they are likely to be found. Here, the source is documentation of a local government ordinance. That is what should be cited. A location in the source is pertinent to the relevant wikitext. So the citation should be formatted exactly like that. Per your description, a reference to the particular news article cannot be sourced any other way. The answer was in the question. ] (]) 18:45, 30 July 2020 (UTC)
::::The parameters are perhaps misnamed as they really mean "given name" and "family name" regardless of name order, rather than first and last. But of course there are cultures (like say Iceland) where names don't work like that. —] (]) 08:25, 16 December 2024 (UTC)
:You could cite it as one document in a couple of ways (probably making use of {{para|via}}), but if you think it is helpful, you can instead cite both in one &lt;ref> statement; something like <code><nowiki>{{cite news |newspaper=The News Tribune |first=Sean |last=Robinson |title=Success or failure? Probing Prometa}} as in {{cite web |url=https://online.co.pierce.wa.us/cfapps/council/model/otDocDownload.cfm?id=1448900&fileName=2007-81s%20final%20Ord%20file%201.pdf |department=Today in the Trib |website=Pierce County, Washington |title=Ordinance No. 2007-81s: etc. |p=106}}</nowiki></code>: {{cite news |newspaper=The News Tribune |first=Sean |last=Robinson |title=Success or failure? Probing Prometa}} as in {{cite web |url=https://online.co.pierce.wa.us/cfapps/council/model/otDocDownload.cfm?id=1448900&fileName=2007-81s%20final%20Ord%20file%201.pdf |department=Today in the Trib |website=Pierce County, Washington |title=Ordinance No. 2007-81s: etc. |p=106}} --] (]) 02:18, 31 July 2020 (UTC)
:::::Well, what they <em>really</em> mean is "surname" and "not surname". <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 08:27, 16 December 2024 (UTC)
::The OP mentions that the original (the newspaper) is no longer in existence and cannot be found. If that is the case, citing the article directly is misleading and unverifiable. The use of {{para|via}} is I believe problematic: the source that includes the article is not an archive, repository, or other publisher. The article is included as supporting (incidental) documentation, as the OP described it, a source from a 3rd party. Tertiary sources should be referenced as such. ] (]) 02:16, 1 August 2020 (UTC)
::::::Difficult to generalise: Saddam Hussein al Tikriti: 2nd name father's "forename", no family name, normal (not informal) single-word name Saddam. Federico del Sagrado Corazón de Jesús García Lorca; normal Spanish surname García, but known, unusually, by mother's surname Lorca. María-José Pérez de Gómez, known sometimes as M-J Pérez, others as Sra Gómez. ] (]) 11:58, 16 December 2024 (UTC)
:::He has stated a belief the web content cannot be accessed any longer directly. It may still be present in archives, digital or in fact physical. Giving the details of the document itself and stating that it can be found in the council minutes doesn't mislead whatsoever and may in fact aid someone to find it in one oc those other two contexts. Via is used to indicate a republisher. A republisher does not need to be one of those groups that you limited it to and in fact the council here is acting as a republisher of the original report. --] (]) 03:00, 1 August 2020 (UTC)
:::::::True. But if you look at the revert there were only 2 names changed (although multiple times each): "Benjamin, Jeff" and "Caulfield, Keith". Both English. Both already separated into surname, comma, given name. No complications. No non-English names. Also, they are displayed to the reader exactly the same but as separate fields they are much more suitable for computer processing. There was no reason whatsoever for the revert apart from ]. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 04:45, 17 December 2024 (UTC)
::::]. Also, archives (not self-archiving services) and legitimate republishers are supposed to satisfy legal/copyright requirements and are liable. In those cases, use of {{para|via}} is justified. But even that case does not apply here. The relevant text is a fragment of the containing source. It should be cited as such. ] (]) 14:16, 2 August 2020 (UTC)
:::::One can also use the aliases {{para|given}} and {{para|surname}} for these parameters. ] 12:11, 16 December 2024 (UTC)
::::::Thank you. That's new to me and I will probably start using it. <span style="border:1px solid blue;border-radius:4px;color:blue;box-shadow: 3px 3px 4px grey;">]&nbsp;<span style="font-size:xx-small; vertical-align:top">]&nbsp;</span></span> 04:45, 17 December 2024 (UTC)
:::::::Unfortunately, ] presently undoes this. I should probably write a script that switches an article the other way, since the solution for automated RETAIN-vio is more automation, of course. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 22:18, 17 December 2024 (UTC)
::::::::ProveIt makes several changes to parameters, which it really shouldn't. One of the worst occurs when a reference has multiple authors – ProveIt renames the first one as {{para|first}} and {{para|last}} and moves the others later in the reference. (If Citation bot encounters these, it will change them to {{para|first1}} and {{para|last1}}, ready for ProveIt to "fix" them again.) It really should not be used on articles that already have consistent citations. ] 22:28, 17 December 2024 (UTC)
:::::::::I mostly used it before for its consistent ordering and spacing, but now I mostly avoid it, and make sure to manually tweak where it violates RETAIN. <span style="border-radius:2px;padding:3px;background:#1E816F">]<span style="color:#fff">&nbsp;‥&nbsp;</span>]</span> 22:30, 17 December 2024 (UTC)


== auto-link bug fix == == Generic title ==


is a generic title string. -- ]] 00:59, 19 December 2024 (UTC)
{{cite compare |mode=journal |last=Barry |first=R. G. |title=H.-B. de Saussure: The First Mountain Meteorologist |journal=Bulletin of the American Meteorological Society |volume=59 |issue=6 |year=1978 |issn=0003-0007 |doi=10.1175/1520-0477(1978)059<0702:hbdstf>2.0.co;2 |bibcode=1978BAMS...59..702B |pages=702–705 |doi-access=free}}
Fixed in the sandbox.


== Cite case causes CS1 errors ==
—] (]) 16:19, 29 July 2020 (UTC)
:Thank you! − ] (]) 20:04, 29 July 2020 (UTC)


{{tl|Cite case}} maps {{para|court}} to {{para|agency}}, which is no longer supported by {{tl|cite book}} -- see ]. This was brought up at ] a few months ago by @] and @], but I'm bringing it here since this is a better-watched talk page. '''Jay8g''' <small>]•]•]<nowiki />]</small> 04:24, 20 December 2024 (UTC)
== Newspaper Article on Two Pages ==


:I ] to {{para|series}}, which renders in the same position in the citation. Hopefully no court cases are part of a series. Haven't checked all 52 transclusions, but none of the dozen or so I checked are in ], so it seems fine. No documentation at this template. ] (]) 17:04, 21 December 2024 (UTC)
What is the standard, if any, for citing a newspaper article that is available online, that is split onto two webpages. This occurs a lot with ] sources. Generally speaking, the article is one source, with one title, author, date, etc. However, to assist with ] and to be able to archive each page of the article, I have been splitting it into two separate references, adding "Part 1" and "Part 2" to the title. See an example below:


== Placement of "translator"/"page" fields ==
*{{Cite news | first = Bill | last = Dow | title = Mann pioneer player in NFL: Part 1 | date = January 11, 2002 | access-date = November 22, 2019 | url-status = live | newspaper = ] | page = 1D | url = https://www.newspapers.com/clip/24262923/mann_pioneer_player_in_nfl/ | archive-url = https://web.archive.org/web/20191122153444/https://www.newspapers.com/clip/24262923/mann_pioneer_player_in_nfl/ | archive-date = November 22, 2019 | via = ] | type = clipping}}
Greetings and felicitations. When "translator" and "page" fields are used together in "Cite journal", it results in this:
*{{Cite news | first = Bill | last = Dow | title = Mann pioneer player in NFL: Part 2 | date = January 11, 2002 | access-date = November 22, 2019 | url-status = live | newspaper = ] | page = 8D | url = https://www.newspapers.com/clip/24262964/mann_end_was_one_of_1st_black_lions/ | archive-url = https://web.archive.org/web/20191122153540/https://www.newspapers.com/clip/24262964/mann_end_was_one_of_1st_black_lions/ | archive-date = November 22, 2019 | via = ] | type = clipping}}


* {{Cite journal |last1=Fujimoto |first1=Yukari |author-link=Yukari Fujimoto |date=2012 |title=Takahashi Macoto: The Origin of Shōjo Manga Style |journal=] |volume=7 |issue=1 |translator=] |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002|isbn=978-0-8166-8049-8}}
This allows me to cite each sentence in an article with the relevant page of the news article. But it does create some confusion and adds additional sources in the reference list. Is there a better way to do this? Does (or could) {{tl|Cite news}} support two urls and two archive-urls? Thanks for any insight.<span style="white-space:nowrap; font-family:Harlow Solid Italic;">] ] @ </span> 15:39, 3 August 2020 (UTC)
:I'd combine the two thusly:
:*{{Cite news |first = Bill |last = Dow |title = Mann pioneer player in NFL |date = January 11, 2002 |access-date = November 22, 2019 |newspaper = ] |pages = 1D, |url = https://www.newspapers.com/clip/24262923/mann_pioneer_player_in_nfl/ |via = ]}}
:I don't think an archive URL is needed with Newspapers.com. Even if the website ever shut down, you're ultimately citing the original newspaper via an accurate facsimile, and the URL is a courtesy, not the source itself, per se.
:Also, I don't think {{para|type|clipping}} is helpful because Newspapers.com will allow readers without an account to see the full page from which the clipping is drawn. <span style="background:#006B54; padding:2px;">''']&nbsp;]'''</span> 20:56, 3 August 2020 (UTC)


ISTM that the "translator" field should be followed by a period, or be placed before the volume/issue number fields, or after the pages field. —] (]) 05:48, 20 December 2024 (UTC)
== Add wayback-timestamp parameter ==
:Yeah, a known flaw but a pain to fix. If we really need to fix it, we should revisit the placement of all rendered parameters. As it is now, the code that orders the cs1|2 template parameters is ugly and confusing.

When an archive is added to a reference, the vast majority of the time it is just a Wayback Machine archive of the exact same URL. This bloats the source code of pages massively. It would be much simpler if a <code>wayback-timestamp</code> parameter was added, which would be set to the timestamp of the archive found in the page's URL. This was mentioned seven years ago ] but the discussion had no conclusion. Example: <code>|wayback-timestamp=20200721125421</code> in <code><nowiki>{{cite web|url=https://example.com/page|title=Example page|website=Example.com|date=2020-08-04|wayback-timestamp=20200721125421|archive-date=2020-07-21}}</nowiki></code> as opposed to the bloated <code><nowiki>{{cite web|url=https://example.com/page|title=Example page|website=Example.com|date=2020-08-04|archive-url=https://web.archive.org/web/20200721125421/https://example.com/page|archive-date=2020-07-21}}</nowiki></code>. Implementation: <code><nowiki>if waybackTimestamp then archiveUrl = 'https://web.archive.org/web/' + waybackTimestamp + '/' + url end</nowiki></code>. <b style="border:1px solid #0800aa"> ] </b> <b style="border:1px solid #006eff"> ] </b> <b style="border:1px solid #00a1ff"> ] </b>  05:15, 4 August 2020 (UTC)
: You're not wrong, but the thing is, server space keeps getting cheaper and cheaper, and programmer (paid, or volunteer time) keeps getting more expensive and scarcer. If you had to prioritize this against stuff that's either broken and needs fixing, or enhancements that would provide desired new functionality, well, you see the problem... ] (]) 04:00, 6 August 2020 (UTC)

=== Smart substitution token to reduce redundancy among input parameters ===
: I would propose a somewhat different implementation of ] introducing a generic placeholder * into the syntax of the {{para|archive-url}} parameter. This would result in:
:: <code><nowiki>{{cite web |url=https://example.com/page |title=Example page |website=Example.com |date=2020-08-04 |archive-url=https://web.archive.org/web/20200721125421/* |archive-date=2020-07-21}}</nowiki></code>
: The substitution would happen only if the {{para|archive-url}} contains exactly one * (not necessarily at the end of the link).
: * is not normally used in urls (even less in archive links), but it can. In the case of archive.org, it is used as a wildcard for the timestamp, however, this isn't used in valid archive links (only internally by the template to help users select a specific snapshot). To not cause misinterpretation, this archive.org special syntax would have to be special-cased, so that if the * would be located inside the timestamp no substitution by {{para|url}} should happen.
: My proposal is not as short as ], but it is more flexible and could work also for a number of other archivers - and without having to add a new parameter or even a bunch of special {{para|...-timestamp}} ones.
: The main reason, however, why I used * is another more generic feature proposal I planned to make for quite some while, where * would be a "smart" context-sensitive placeholder also supported in various other parameters:
: It would substitute whatever is a sensible replacement string in the context of a particular parameter:
:* For example, {{para|access-date|*}} would be substituted with the value of {{para|publication-date}} or {{para|date}} (if given, otherwise an error would be thrown instead of silently ignoring the parameter as what would happen for an empty parameter).
:* {{para|archive-date|*}} would be substituted with the value of {{para|access-date}} (likewise).
:* {{para|website|*}} would extract the domain name from {{para|url}}.
:* {{para|title-link|... * ...}} would implant the value of {{para|title}} at the position of the * (f.e. {{para|title-link|* (song)}}. Our {{para|title-link|((...))}} "]" ((syntax)) would allow for {{para|title-link}} to actually contain a * - in this case, the parameter substitution would be disabled. (TBD. What would be the best substitution if {{para|trans-title}} and/or {{para|script-title}} were used as well?)
::: Example: <code><nowiki>... {title=Flying Circus |title-link=Monty Python's * (album) |date=...</nowiki></code>
:* {{para|author-link''n''|... * ...}}/{{para|editor-link''n''|... * ...}} etc. In the simple case, the substitute for * would be the value from {{para|author''n''}}/{{para|editor''n''}}, the ((syntax)) would be supported as well. If the name is composed from multiple parameters such as {{para|author-first''n''}}/{{para|author-last''n''}}, the substitute would be the resulting string. This would allow for things like:
::: <code><nowiki>... |author-first=William |author-last=Shakespeare |author-link=* (author) |date=...</nowiki></code>
:: or
::: <code><nowiki>... |author-first=Otto |author-last=Sander |author-link=:de:* (actor) |date=...</nowiki></code>
:: A single * would result in the composition of "<first> <last>" (because this is the most likely substring used in article titles), a doubled ** would result in "<last>, <first>" (comma, semicolon etc. depending on other template settings), a triple *** in only the "<last>" name. If someone would use ** or *** in {{para|author-link''n''}} in conjunction with {{para|author''n''}} rather than {{para|author-first''n''}}/{{para|author-last''n''}}, this would result in the contents taken from {{para|author''n''}} as well (like a single *).
:: (TBD. At some point in the future we will probably support the full set of {{para|trans-author''n''}}/{{para|script-author''n''}} parameters. If they exist, the source values for the substitution should be derived from these parameters. The exact patterns are still TBD to maximize the utility value.)
:* {{para|author-mask''n''|... * ...}} etc. would support substitution as well. In this case, * would result in the composition of <first> and <last> according to the default order used by the template (or the setting of the {{para|af}} parameter once proposed by Headbomb to override the default order); at present (and without {{para|af}}), this would be "<last>, <first>" (because the format used in the {{para|-mask}} parameters is most likely needed to be in the same order as in the normal display of author names without {{para|author-mask}}). A doubled ** would result in the opposite order of the one selected by *; at present, this would be "<first> <last>". Triple *** would result in only the <last> name. Again, if someone uses *, ** or *** in {{para|author-mask''n''}} in conjunction with {{para|author''n''}} rather than {{para|author-first''n''}}/{{para|author-last''n''}}, the value of {{para|author''n''}} is taken as a replacement.
:: So much for the overview. There are a number of special cases not discussed yet, but I think you already get the idea: One easy to remember global placeholder * as a generic smart and context-specific placeholder, possibly doubled ** or tripled *** to switch the output format depending on context (similar to different signatures being issued with <nowiki>~ ~~ ~~~ ~~~~</nowiki> or different link types being used depending on if using single or doubled brackets etc.) Since, in the context of each parameter, it is quite obvious what would be a reasonable source for the substitution (AFAI see it, there is always only one source which really makes sense), this scheme is easy to remember and use. It would be backward compatible and optional to use, it would reduce the amount of required manual input, reduce the risk for many typos, may make many citation templates easier to read on source code level (YMMV) without having to reduce the amount of provided info, and it would even save some storage space.
:: --] (]) 14:48, 8 August 2020 (UTC)

Taking a citation from the ] thread, here are two examples, how they could be simplified using the * placeholder, avoiding the hardcoded name in the {{para|-mask}} parameter:

Example 1:

: <code><nowiki>{{cite book |title=The Rolling Stone Illustrated History of Rock & Roll |chapter=The Beatles |author-last=Marcus |author-first=Greil |author-link=Greil Marcus |editor1=DeCurtis, Anthony |editor2=Henke, James |editor3=George-Warren, Holly |editor-mask3=with George-Warren, Holly; |editor4=Miller, Jim}}</nowiki></code>

This could be reduced to:

: <code><nowiki>{{cite book |title=The Rolling Stone Illustrated History of Rock & Roll |chapter=The Beatles |author-last=Marcus |author-first=Greil |author-link=* |editor1=DeCurtis, Anthony |editor2=Henke, James |editor3=George-Warren, Holly |editor-mask3=with *; |editor4=Miller, Jim}}</nowiki></code>

(Note that the substitution in {{para|author-link}} would be "Marcus Greil" (contents of {{para|author-last}} and {{para|author-first}} combined in form "<first> <last>" per one *) and in {{para|editor-mask3}} it would be "George-Warren, Holly" (contents of {{para|editor3}}).)

Example 2:

: <code><nowiki>{{cite book |title=The Rolling Stone Illustrated History of Rock & Roll |chapter=The Beatles |author-last=Marcus |author-first=Greil |author-link=Greil Marcus |editor-last1=DeCurtis |editor-first1=Anthony |editor-last2=Henke |editor-first2=James |editor-last3=George-Warren |editor-first3=Holly |editor-mask3=with George-Warren, Holly;<!-- need to hardwire this here --> |editor-last4=Miller |editor-first4=Jim}}</nowiki></code>

This could be reduced to:

: <code><nowiki>{{cite book |title=The Rolling Stone Illustrated History of Rock & Roll |chapter=The Beatles |author-last=Marcus |author-first=Greil |author-link=* |editor-last1=DeCurtis |editor-first1=Anthony |editor-last2=Henke |editor-first2=James |editor-last3=George-Warren |editor-first3=Holly |editor-mask3=with *; |editor-last4=Miller |editor-first4=Jim}}</nowiki></code>
(Note that the substitution in {{para|author-link}} would be "Marcus Greil" (contents of {{para|author-last}} and {{para|author-first}} combined in form "<first> <last>" per one *) and in {{para|editor-mask3}} it would be "George-Warren, Holly" (contents of {{para|editor-last3}} and {{para|editor-first3}} combined in the (default) form "<last>, <first>" per one *).)

--] (]) 12:32, 10 August 2020 (UTC)

: See also: ]
: --] (]) 09:28, 16 August 2020 (UTC)

== New autolinking of free dois breaks citations that deliberately omit title ==

In the citation
:<nowiki>{{cite journal|last=Nespolo|first=Massimo|date=November 2019|doi=10.1107/s1600576719014055|issue=6|journal=Journal of Applied Crystallography|pages=1467–1468|title=none|volume=52|doi-access=free}}</nowiki>
currently formatted as
:{{cite journal|last=Nespolo|first=Massimo|date=November 2019|doi=10.1107/s1600576719014055|issue=6|journal=Journal of Applied Crystallography|pages=1467–1468|title=none|volume=52|doi-access=free}}
I am now seeing a visible url and a big red error "|doi= missing title" even in the not-logged-in view. This citation was previously error-free and was broken by recent changes to the citation template that added auto-linking of dois without taking adequate precautions that there is something to auto-link to.

I frequently and deliberately omit titles, using the documented method {{para|title|none}} of doing this, as part of lists of multiple reviews of the same book that do not have individual titles. Many such reviews are not formatted with titles so any title that one included would have to be a made-up placeholder. In this case the review actually is formatted with a title, but not one that would be useful to include in a citation: the title, as formatted in the review, is "Fat Chance! Probability from 0 to 1. By Benedict Gross, Joe Harris, and Emily Riehl. Cambridge University Press, 2019. Pp. Xi+200. Paperback price GBP 19.99, ISBN 9781108728188. Hardback price GBP 49.99, ISBN 9781108482967. Ebook price USD 21.00, ISBN 9781108598705."

It should not be an error to omit the title and it should not be an error to mark dois as free even when the title is deliberately omitted. Please stop making the citation templates even more brittle and unusable than they have become, restore the ability to deliberately omit titles on citations, and un-break the many citations already existing within Misplaced Pages articles that this change has broken. —] (]) 22:18, 4 August 2020 (UTC)
:This seems like a fairly clear bug to me. The tone from "please stop" was not necessary accordingly. --] (]) 22:49, 4 August 2020 (UTC)
: :
:For this particular case, if one follows the doi link to the publisher's website, Oxford Academic identifies "Takahashi Macoto: The Origin of Shōjo Manga Style" as a chapter in the book ''Mechademia 7: Lines of Sight''. It would seem then that {{tlx|cite book}} would be the appropriate template. I don't have access to the source, but Oxford Academic's recommended citation does not include Rachel Thorn (with an 'N'). The recommended citation lists a co-author(?) 'Matt Thorm' (with an 'M'). So, perhaps the correct template looks like this (without {{para|translator}}):
:<code><nowiki>{{cite journal/new|last=Nespolo|first=Massimo|date=November 2019|doi=10.1107/s1600576719014055|issue=6|journal=Journal of Applied Crystallography|pages=1467–1468|title=none|volume=52|doi-access=free}}</nowiki></code>
::<syntaxhighlight lang="wikitext" inline="1">{{Cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}}</syntaxhighlight>
::{{cite journal/new|last=Nespolo|first=Massimo|date=November 2019|doi=10.1107/s1600576719014055|issue=6|journal=Journal of Applied Crystallography|pages=1467–1468|title=none|volume=52|doi-access=free}}
:::{{Cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}}
:—] (]) 22:55, 4 August 2020 (UTC)
:or with {{para|translator}}:
::Thanks! It has historically not always been easy to distinguish changes that are recognized as bugs and fixed from changes that are intended to restrict how the template can be applied and are permanent. I'm glad this one landed on the fixed side. —] (]) 23:11, 4 August 2020 (UTC)
::<syntaxhighlight lang="wikitext" inline="1">{{Cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |translator=] |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}}</syntaxhighlight>
:::Perhaps some common sense would be useful next time? − ] (]) 07:08, 5 August 2020 (UTC)
:::{{Cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |translator=] |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}}
::::Us editors on this talk page have been accused of lacking such on occasion. --] (]) 18:54, 5 August 2020 (UTC)
:—] (]) 16:44, 20 December 2024 (UTC)
:::::Common sense is not as common as people think. It may also be not as sensible. ] (]) 17:26, 7 August 2020 (UTC)
::I don't have time right now to reply in full, but '']'' is a journal in the form of a book, and the correct spelling of the particular author's name is ]. —] (]) 20:14, 20 December 2024 (UTC)


== module suite update 28–29 December 2024 ==
=== Towards solving pending issues of the auto-link feature... ===
: ] was one of the (thankfully now fixed) open special cases already mentioned in the original thread (]). There are more (see also ]). Would be nice to see them addressed before the next update is about to be rolled out, at least the manual override/disable facility we agreed upon by overloading {{para|url|none/doi/pmc/<other-identifier-parameter-name>/<url>}}... --] (]) 12:26, 8 August 2020 (UTC)
::If it was not clear, I oppose the use of {{para|url|none/doi/pmc/...}}. Introducing these non-URL values in a field which currently expects URLs is likely to break many tools and scripts - this is a bad programming practice. Beyond that, I am yet to see an example of a citation where a {{para|url|none}} would be desirable. For {{para|url|doi}} and others, I would simply let people add those URLs directly in the URL field - there is no need for the additional complexity and indirections. If bots currently remove such URLs, they should stop doing that. − ] (]) 17:31, 8 August 2020 (UTC)
:::I agree that populating the url field with non-url content is not a good practice. I would make an exception for {{para|url|{{var|none}}}} as long as the current dependency of {{para|archive-url}} is in place. I am fairly certain that reliable archives may have fascimiles of originals that can no longer be found. ] (]) 00:04, 9 August 2020 (UTC)
::: Alright then, in the previous discussions I raised specifically this concern as a ''potential'' problem ''twice'', but over the course of weeks nobody confirmed it as a real problem, so weighing the various pros and cons we more or less settled on {{para|url|none/doi/pmc/...}} (and reserved {{para|chapter-url|none/doi/pmc/...}} for potential future use).
::: Avoiding this and leaving {{para|url}} (and {{para|chapter-url}}) for actual URLs only, the alternative is to overload {{para|title-link|none/doi/pmc/...}}, instead. (In this case we'd have to support our special "]" ((syntax)) for {{para|title-link}} to still allow linking to Misplaced Pages articles in the rare case where they might clash with the bunch of supported identifier parameter names (no problem for the current ones, but could be if the list gets longer, as already requested) - alternatively, in these few cases, we could go through a redirect to avoid the name conflict. So, not a real issue, either.) However, if, at some point in the future, we'd add auto-linking also for chapters (as was already requested as well), the user interface might no longer remain self-expaining, as there is no corresponding {{para|chapter-link}} parameter (and no need to add one, as we don't have Misplaced Pages articles on chapters, or do we?). So, if we would want to override the automatic behaviour in this case, we would have to add these cases as arguments to {{para|title-link}} in a sensible way as well - it's definitely doable, the only case we could not control then is when a title is linked to a Misplaced Pages article (thereby occupying the parameter) and the chapter title should be linked to something different than the automatic default (or not at all).
::: The third alternative is to have a separate parameter to control the auto-linking behaviour like {{para|auto-link|auto/none/doi/pmc/...}}. However, I don't like this variant much because it is bad user-interface design (and therefore difficult to remember for users) to scatter related functionality over multiple parameters in particular if they cover mutually exclusive cases like {{para|auto-link|doi}} {{para|title-link|WP-Article}} which requires error checking for cases (like "Conflicting link targets defined.") which could be ruled out simply by the underlying parameter logic already (because one parameter can hold only one value). The idea is to make existing parameters smarter rather than to introduce yet more new parameters for special cases which could be covered as part of existing parameters as well.
::: --] (])
::::In my opinion, all these proposals try to address a problem that does not exist. Editors can link citation titles with {{para|url}} or {{para|title-link}} to any URL or internal link, there is no need to introduce a complex machinery to provide a convoluted alternative. The simpler we can keep these templates, the more reliable and easier to maintain they will be. I still have not seen an example of a citation where disabling auto-linking is desirable, too. − ] (]) 15:07, 9 August 2020 (UTC)


I propose to update the cs1|2 module suite over the weekend 28–29 December 2024. Here are the changes:
== trans-quote? ==


]:
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, ] (]) 13:31, 5 August 2020 (UTC)
*convert {{cl|CS1 maint: unfit URL}} to properties cat {{cl|CS1: unfit URL}}; ]
:Never existed. {{para|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.
:—] (]) 13:56, 5 August 2020 (UTC)
::Thanks for the information and the advice. Something must have happened to my memory. ] (]) 14:01, 5 August 2020 (UTC)
::: You probably have seen one of the proposals to add this (and {{para|script-quote}}) in the past. While Trappist is right that {{para|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. --] (]) 12:03, 8 August 2020 (UTC)


]:
== Wayback Machine ==
*update emoji zwj table to Unicode v16.0; nothing changed except version and date;
*add script lang codes 'az', 'chr', 'zgh';
*add free DOI registrants 10.18637 – Foundation for Open Access Statistic, 10.1016/j.proche – Procedia Chemistry
*convert Category:CS1 maint: unfit URL to properties cat Category:CS1: unfit URL
*relax 'HugeDomains' generic title search; ]


]:
Hello, I came across a reference title of "Wayback Machine", having done a search there are close on 2,000 of these. Was wondering if it worth extending the "Archived copy" tracking to include this as well, so that the articles can be modified to give something useful. ] (]) 21:21, 5 August 2020 (UTC)
*fix extended free doi bug; ]
:This would be good. There is a tool (reFill) that when it encounters a bare or square ''web.archive.org'' link generates a {{tld|cite web}} set with {{para|title|Wayback Machine}} and {{para|website|web.archive.org}} (). My tool WaybackMedic unwinds some of it () but the title remains as "Wayback" -- ]] 01:47, 6 August 2020 (UTC)
*bump 5-digit doi prefix limit; ]
:: The sandboxed version of the template now adds such citations to a maintenance category:
::: <code><nowiki>{{Cite book/new |title=Wayback Machine}}</nowiki></code>
::: {{Cite book/new |title=Wayback Machine}}
:: (Of course, it is still empty until the change will be rolled out.)
:: --] (]) 23:20, 22 August 2020 (UTC)
:::In ] you included a comment {{tq|no translation necessary for this one}}. How do we know that?
:::
::: finds almost 2000 instances of this 'title'. I wonder if a maintenance category is proper here. To me, {{para|title|Wayback Machine}} just as bad a {{para|title}} (empty or missing); it is no help to the reader, maint cats are hidden so most editors don't notice that this bogus title replaces a real title; maint cats usually imply that whatever it is that they categorize is minor so there is no sense of urgency to fix them. I think that if we are going to retain this change, it should be as an error not as a maint cat.
:::—] (]) 11:03, 23 August 2020 (UTC)
:::: Regarding "no translation necessary", it is my assumption that the Wayback Machine has no alternative names in different countries. If it has, and the tools use different strings in different WP entities, then, of course, we may need translations. Does someone know for sure?
:::: Re error or maintenance, I was just following the example of "Archive copy", which should also be an error in my judgement, but is only flagged for maintenance (perhaps because of the extremely high number of hits?). Opinions? --] (]) 12:44, 23 August 2020 (UTC)
:::::Yeah, I think {{para|title|Archive copy}} should be an error but, you know, pitchforks and torches because oh-my-god-the-sky-is-falling. I have thought that we might somehow emit error messages in dribs and drabs; article titles ending with <code></code> only and then to be followed at the next update with article titles ending with <code></code> , etc. – last letters to reduce clumping which might provoke pitchforks and torches. We might even build in a timer release so that every month a new terminal letter is added. Or we could have an RfC on the topic ... wherein, of course, we will be admonished to have a bot fix all of those articles before we show the error messaging even though {{para|title|Archive copy}} is created by a bot when it cannot determine the title of the source. As you might guess, I have little faith in that path.
:::::
:::::I think we need to do something; if we don't, {{clc|CS1 maint: archived copy as title}} will continue to grow.
:::::—] (]) 14:20, 23 August 2020 (UTC)
::::::I also have been concerned about the continued failure of that category of clear errors to be cleaned by anyone. I do not think it would have the same reaction as last year's website given that these should ostensibly not occur more than a few times a page. --] (]) 16:00, 23 August 2020 (UTC)
:::::::For wayback titles we might do:
::::::::<syntaxhighlight lang="lua">err_suspect_title = {
message = 'Citation has a suspect title',
anchor = 'suspect_title',
category = 'CS1 errors: suspect title',
hidden = false,
},</syntaxhighlight>
:::::::Is there a better (less cryptic) error message? better cat name?
:::::::
:::::::When 'Wayback Machine' is a legitimate title, {{para|title|((Wayback Machine))}}.
:::::::—] (]) 16:25, 23 August 2020 (UTC)
::::::::I do not think we need to support the exception here (at this time); few or no citations will be citing the front page of Wayback (and where they do, more likely it should go in work or publisher or via parameters).
::::::::I would be more direct since this is the only set of titles we have worries about this concern: "Citation (title?) generated by web archive bot" or similar. Which is not strictly true in the "Wayback" title case but close enough for purposes. --] (]) 16:41, 23 August 2020 (UTC)
:::::::::Other ideas: "Citation has a generic bot-generated title", or "Citation has an ambiguous title". Possibly leave off "bot-generated" as in second case. -- ]] 18:54, 23 August 2020 (UTC)
:::::::::: Before I saw how many hits we have for "Archive copy" I was about to put "Wayback Machine" into the same category, possibly renaming the message and cat into something about "bogus titles". However, then I thought "Wayback Machine" would go under among "Archive copy" (thereby making its maintenance difficult) so introduced a new cat for it.
:::::::::: However, for a cat holding only a few thousand pages, I think we could lump together "Wayback Machine" with some other bogus strings in the title like "unknown " (in a category "Non-sensical" or "bogus titles").
:::::::::: --] (])
:::::::::::The problem with "bogus", "non-sensical" and "suspect" it will probably result in Phab tickets for IABot ("The bot is creating bogus titles") as if the bot was making a mistake and should stop doing that. Less judgemental and more objective words like ambiguous and generic would produce less friction. -- ]] 19:30, 23 August 2020 (UTC)
:::::::::::: In fact, I wonder if the bot isn't making a mistake. Correct would be to add an empty {{para|title}} parameter, causing the template to throw an error message. Alternatively, but only slightly better, the dummy title should trigger the template to throw a (more specific) error message, as we all seem to agree now. Maintenance cat won't cut it, if nobody is acting on it.
:::::::::::: --] (]) 20:30, 23 August 2020 (UTC)
::::::::::::: Nobody has been acting on it, but it can be acted on. See ]. Probably overkill to red error that many citations while there are still possibilities for correction. -- ]] 20:44, 23 August 2020 (UTC)
:::::::: Re error or maint for "Archive copy" I would support to change this to error as well. Yes, it will annoy readers, but apparently this is the only way to move forward.
:::::::: And if the number of entries in that cat actually still increases, we should block the tools introducing this mess (and also the careless users using these tools). While I prefer to have fully blown up citations (filled by humans), I would rather prefer to have citations missing some entries than citations containing pure junk.
:::::::: --] (]) 19:21, 23 August 2020 (UTC)
:::::::::IAbot made {{diff|Four:twenty_Recordings|974570314|954259388|this edit}} 2 minutes after your post.
:::::::::—] (]) 19:33, 23 August 2020 (UTC)
::::::::::Exactly. The alternative is bare link + {{tlx|webarchive}} which sucks for a number of reasons. The archive bot has to do something when it encounters bare-link link-rot and conversion to CS1|2 moves the process forward. The generic title is a flag for a title bot to fill in the correct title. There is currently no title bot, but we had them before. -- ]] 19:59, 23 August 2020 (UTC)
:::::::::::The point I was answering was {{tq|And if the number of entries in that cat actually still increases}}. Yep, it still increases; IAbot is not going to go away. The problem with {{para|title|Archived copy}} is that at a glance, everything appears to be correct because there are no red {{error-small|error messages}} and only those of use who have maintenance messaging enabled will see the {{color|#33aa33|maintenance category}} messages. For me, I have little faith in automation as a way of solving the archived copy title problem. IAbot is apparently capable of finding titles so when it can't, what makes us think that some other bot can?
:::::::::::—] (]) 22:02, 23 August 2020 (UTC)
::::::::::::IABot doesn't find titles. There are other title fixing bots operating back over 10 years ago, and Citation bot also has that feature when it is working (third party tool currently offline working to restore). -- ]] 00:41, 24 August 2020 (UTC)
:We should start a list of other 'titles' that might go into the same category as wayback machine titles. Here are a couple:
:*This website is for sale –
:*HugeDomains.com –
:I'm pretty sure that I've seen others; I've even seen the same sort of 'titles' in languages other than English.
:—] (]) 22:02, 23 August 2020 (UTC)
::Bloomberg's "Are you a robot?" Jumps immediately to mind. --] (]) 23:26, 23 August 2020 (UTC)
::* insource:/| *title *= *?nknown)]? */ -->
::* insource:/| *title *= *?nknown ?itle)]? */ -->
::* insource:/| *title *= *?itle ?nknown)]? */ -->
::* insource:/| *title *= *?mpty itle)]? */ -->
::* insource:/| *title *= *?ummy)]? */ -->
::* insource:/| *title *= *?laceholder)]? */ -->
::* insource:/| *title *= *??? */ -->
::* insource:/| *title *= *o ?o */ -->
::* insource:/| *title *= *??? */ -->
::* insource:/| *title *= *? ?? */ -->
::* insource:/| *title *= *?o ?itle)]? */ -->
::* insource:/| *title *= *one)] */ --> (not matching the reserved keyword "none")
::* insource:/| *title *= *None */ --> (not matching the reserved keyword "none")
:: --] (]) 00:37, 24 August 2020 (UTC)


]:
== Why does Wikiquote's Ref template and Misplaced Pages's Ref template handle commas in the date field differently? ==
*reworked hyphen_to_dash(); ]
—] (]) 01:57, 21 December 2024 (UTC)


:I don't have an opinion on most of these but am very happy to see the hyphen-to-dash fix. Thanks! —] (]) 06:01, 21 December 2024 (UTC)
(X-posting from the Tech Pump) Wikiquote's ref template will parse "July 2 1999" just fine, but our template requires a comma, e.g. "July 2, 1999". Why is that? Can someone fix our template to stop caring so much? I screw this up on my first pass something like 25% of the time. -- ]<sup>]</sup> 00:30, 7 August 2020 (UTC)
:"July 2 1999" is not a valid date format here on the English Misplaced Pages, per ], so our CS1 citation templates (e.g. {{tl|cite web}} and similar) display an error message. Wikiquote does not have enforceable date styles (per ]), so ambiguous and non-standard dates aren't marked as errors. – ] (]) 01:58, 7 August 2020 (UTC)
::What does MOS have to do with it? Wikiquote's template simply inserts the comma automatically, so the styling result is exactly the same. -- ]<sup>]</sup> 12:37, 7 August 2020 (UTC)
:::Which template is doing this formatting? See , where Template:cite news on wikiquote is leaving "July 2 1999" alone. You are welcome to add examples to that sandbox page. – ] (]) 15:43, 7 August 2020 (UTC)
::::Wikiquote's version of "cite web" is definitely adding the comma; I've added an example to your sandbox. I don't know why I expected consistency, lol. -- ]<sup>]</sup> 00:22, 8 August 2020 (UTC)

== Help ==

I have a question about a book that is divided into several individual sections with their own authors. ¿How should I cite that book? In my case I am only interested in one section of that book. --] (]) 23:11, 8 August 2020 (UTC)

:{{cite book|author=Author |chapter=Section |title=Title}} is the basic skeleton. If you have some more information we can fill out the rest for you. --] (]) 23:12, 8 August 2020 (UTC)

The book is called: ''Escuadra Nacional 1818-2018'' (no author, only publisher)

The title of the chapter or section of the book already mentioned is: ''De la Guerra del Pacífico hasta fines del siglo XIX''. The author is: Piero Castagneto Garviso. This author is just from the chapter or section of the book.

As I mentioned before, the book has other chapters or sections with their own authors, but I'm only interested in the one already mentioned. --] (]) 00:04, 9 August 2020 (UTC)

:{{cite book|author=Piero Castagneto Garviso |title=Escuadra Nacional 1818-2018 |chapter=De la Guerra del Pacífico hasta fines del siglo XIX |publisher=Publisher}} is how that is done indeed. I expect there is an editor too who you might want to include, and of course a year. --] (]) 00:25, 9 August 2020 (UTC)
::+{{para|url|<nowiki>http://anyflip.com/yccc/bhap</nowiki>}}:
:::{{cite book|author=Piero Castagneto Garviso |title=Escuadra Nacional 1818-2018 |chapter=De la Guerra del Pacífico hasta fines del siglo XIX |publisher=Publisher |url=http://anyflip.com/yccc/bhap}}
::—] (]) 00:30, 9 August 2020 (UTC)

== Placement of language annotation ==

When the source being cited is a chapter in an edited book or an article in a journal, the language of the source (specified with {{para|language}}) should be notated after the chapter or article, rather than after the book or journal, which may include items in several languages. For example, currently we have:
* {{cite book |author=Author |title=Buch |language=de |year=2020 |ref=none }}
* {{cite book |author=Autor |chapter=Kapitel |language=de |editor=Editor |title=Book |year=2020 |ref=none }}
* {{cite journal |author=Autorin |title=Artikel |language=de |journal=Journal |year=2020 |volume=3 |pages=1–20 |ref=none }}
The first is fine, but in the last two "(in German)" should be moved forward, after the chapter or article. ] 11:50, 9 August 2020 (UTC)
: Recently discussed ]; see particularly my comments. --] (]) 11:59, 9 August 2020 (UTC)
::It seems there was substantial support for putting the annotation after the title of the item, with a few in favour of putting it at the end. Either would be better that the current practice of placing it after the name of the book, journal or series, which may be in several languages. But then the discussion got derailed onto formatting of multiple parentheticals. ] 14:12, 9 August 2020 (UTC)
:::The conclusion you should draw is that the problem is not easy because of the paranetheticals. --] (]) 14:47, 9 August 2020 (UTC)
:::: Yeah, Kanguole summed it up well. While I have a preferences for moving it at the end (to avoid creating new problems), moving it after the most-specific title would have my support as well (but the parenthetical issues this creates would need more investigation IMO - some of them seem to be acceptable, whereas others just look too distracting to me - would be like trading one shortcoming for another).
:::: --] (]) 16:19, 9 August 2020 (UTC)

== Request for new maintenance category for abbreviated year ranges in the date= parameter ==

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 {{para|date}} parameter of citations at some point in the future (only there, not elsewhere where they are still allowed, including f.e. in {{para|title}}, {{para|chapter}}, or {{para|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).
--] (]) 13:19, 9 August 2020 (UTC)
:Can you please give a list of examples of what you consider abbreviated year ranges? It is unclear what you consider acceptable and unacceptable.
: :
: Instead of {{cl|CS1: unfit URL}} could it be {{cl|CS1: usurped URL}} - it is the majority by about 3:1: , . The usurped will grow indef due to ]. -- ]] 06:21, 21 December 2024 (UTC)
:Our date format checking follows ] and ]; is there an invalid format listed there that is not being detected? – ] (]) 15:01, 9 August 2020 (UTC)
::Here's an example of an invalid range that is currently detected as an error: {{citation|title=Title|date=1902–07}}. – ] (]) 15:03, 9 August 2020 (UTC) ::Makes sense just to reparent the existing cat: {{code|usurped}} is a subtype of {{code|unfit}}. Thanks for all your work, Trappist. ] (]) 16:46, 21 December 2024 (UTC)
:::Just so I understand what you are saying: You think that {{para|url-status|unfit}} should categorize to {{cl|CS1: unfit URL}} and {{para|url-status|usurped}} should categorize to {{cl|CS1: usurped URL}} where the latter is a sub-category of the former? Do we really need two categories?

:::—] (]) 19:10, 21 December 2024 (UTC)
:: I don't think so. The idea, however, is to deprecate abbreviated year ranges in citations in general, even where they are currently still allowed by MOS. (Before I hear people screaming: This change should ''only'' affect ''abbreviated year ranges in citations'', not other uses anywhere else in an article, which should continue to be allowed under the restrictions already applying per MOS.)
:: My feeling is that this minimal change to the MOS would impact only very few citations in existence, therefore it should have no actual negative effect on those who prefer abbreviated year ranges. (However, at a later point in time, it would have major advantages for the many articles using citations in ymd format, because then they could write "yyyy-mm" instead of "Month yyyy" when the day is not known.)
:: But in order to know the actual numbers, we need a maintenance category for abbreviated year ranges.
:: Here are some examples of abbreviated year ranges:
::: 1881–86, 1881–886, 1881–6, 1881–82, 1881–882, 1881–2
:: Of those, 1881–886, 1881–6, 1881–882, 1881–2 are not allowed anywhere in Misplaced Pages (and are probably already ruled out by our template - haven't tried), whereas 1881–86 is allowed in certain contexts if good reasons apply for using them, and 1881-82 (consecutive years) is allowed in more places, while still not being the preferred form.
:: I guess, it makes sense to also sense for the same pattern with hyphen (-) rather than endash (–).
:: I have never seen other forms, but perhaps there are variants with additional pre- or postfix notation. If so, they should be put into this category as well for evaluation. At present (before the proposed MOS change) this should not be flagged as error, as it is just for tracking.
:: --] (]) 16:08, 9 August 2020 (UTC)
:::{{citation|title=Title|date=1881–86}} {{green|(invalid per MOS except where "where space is limited"; accepted by CS1)}}
:::{{citation|title=Title|date=1881–886}} {{red|(invalid per MOS, error in CS1)}}
:::{{citation|title=Title|date= 1881–6}} {{red|(invalid per MOS, error in CS1)}}
:::{{citation|title=Title|date=1881–82}} {{green|(valid per MOS and accepted by CS1)}}
:::{{citation|title=Title|date=1881–882}} {{red|(invalid per MOS, error in CS1)}}
:::{{citation|title=Title|date=1881–2}} {{red|(invalid per MOS, error in CS1)}}
:::{{citation|title=Title|date=1881–22}} {{red|(invalid per MOS, error in CS1)}}
:::I feel like I'm doing your work for you. Does the above list help? Do you propose that CS1 mark the first case, "1881–86", as an error? All of the other cases appear to be processed correctly per MOS. – ] (]) 17:08, 9 August 2020 (UTC)
::::I think this is going in the wrong direction. The readers still would not know what the abbreviated date is meant to represent and not know that we disallow abbreviated years. We should be making it clear what we are using and disallow both yyyy-mm & yyyy-yy in citations. ] (]) 19:01, 9 August 2020 (UTC)
:::::Both of those formats are already flagged:
:::::{{citation|title=Title|date=2001-02}} {{red|(error in CS1)}}
:::::{{citation|title=Title|date=2020-21}} {{red|(maintenance message in CS1)}}
:::::Again, what is the exact proposal here? If the proposal is to change MOS, that should happen at a MOS talk page. – ] (]) 19:20, 9 August 2020 (UTC)
:::::: Jonesey, it is extremely hot over here, and possibly also where you live, but still I think I have been quite clear about that. The request, at this stage, is to put citations which contain abbreviated year ranges in the {{para|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.
:::::: ''This'' is not a request to change the MOS, but this will likely happen (f.e. ]) at a later stage pending the outcome of an evaluation of the citations accumulating in the requested maintenance category.
:::::: I deliberately remained somewhat vague in regard to the exact search pattern because there might be forms of abbreviated year range notations in the English language I am simply not aware of (as a non-native speaker), and the resulting pattern also depends on (the sequence of) pattern checks already carried out by the current implementation (f.e. your list above gives a good overview, but I found that yy <= 12 are special-cased - there might be more such peculiarities, leading zeros come to my mind).
:::::: At the risk of missing some special forms, something similar to yyyyyy would probably catch most already (based on some tests with "<code>insource:/| *date *= *{3,4} * *{1,2} */</code>" 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.
:::::: --] (]) 20:34, 9 August 2020 (UTC)
::::::: Forgot to mention year ranges in the {{para|publication-date}} and {{para|year}} parameters in addition to those in {{para|date}}.
::::::: --] (]) 16:31, 21 August 2020 (UTC)
::::::: See also: ] --] (]) 17:40, 23 August 2020 (UTC)

== Usurped must be reinstated as a valid url-status value! ==

I currently work as a computer security professional. There are times when the original ownership of a website has expired & a bad actor has acquired the website. In these cases, I absolutely want to completely suppress the original website & only display the archived link. We need to protect our users from malicious websites. ] (]) 00:37, 10 August 2020 (UTC)
:Umm, it never went away:
::<code><nowiki>{{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2020-08-09 |url-status=usurped}}</nowiki></code>
:::{{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2020-08-09 |url-status=usurped}}
:Also, one conversation in one place. I have closed the other dicussion.
:—] (]) 00:43, 10 August 2020 (UTC)
: {{re|Peaceray}}, you might be interested in ]. ] (]) 09:48, 12 August 2020 (UTC)

== "archive-url" dependency ==

Prompted by the recent discussion on auto-linking, which exposed cases of non-url data in {{para|url}}.

To mitigate, {{para|archive-url}} could formally depend on {{para|url-status}} instead of {{para|url}} (without checking the module code, I believe that programmatically, "archive-url" does depend on "url-status").

The option {{para|url-status|{{var|missing original}}}} would be one of the cases that would cause the archive to become the live location in the citation. If {{para|url}} needs to be present, perhaps a comment such as {{para|url|{{var|<nowiki><!--Original missing.--></nowiki>}}}} could be auto-inserted. ] (]) 02:28, 10 August 2020 (UTC)
: I'm not sure I understand you correctly, but the scenario you are describing appears to be covered by {{para|url-status|dead}} already. If only the archived URL is known, the original URL should be derived from the archived URL and inserted into {{para|url}}. In most cases, the archive URL contains (perhaps not exactly the URL the user used when invoking the page originally, but at least) the page used by the archiver when archiving the page. Displaying the archived web site may reveal the original URL as well (depends on the archiver, though). In the case of archive URLs in form of tiny URLs there are tools to expanded them into their long forms. This should allow most original URLs (or equivalents) to be recovered from their archived URLs.
: Of course, {{para|url}} would then no longer be available for overloading, but there are alternatives for this (f.e. using {{para|title-link}} instead. See ]
: --] (]) 12:19, 13 August 2020 (UTC)

::The discussion you linked is the one referenced in the OP. Basically, it is proposed to edit the doc so that it reflects the code: archive status depends on url status (which requires {{para|url}}). Not incidentally, this may help in keeping invalid data (non-URL entries) out of the URL field. Properly, all url indicators should be entered in the status parameter. An exception could be made for ''none'' in certain narrow well-defined cases. Since ''none'' is used elsewhere in the module, it wouldn't be a bad idea to declare it a special word. ] (]) 12:50, 15 August 2020 (UTC)

== How to disable the link? ==

There's a few links I've seen in references to old webpages with valid archive URLs of what the site looked like in 1997, but there's malware-downloading squatters at the URL now. Is there a way to suspend a link to the site in this template? Or should the URL just be replaced directly with the archive link in such cases? ] (]) 05:53, 10 August 2020 (UTC)
:{{Re|SnowFire}} If you add <code>|url-status=unfit</code> to the citation, the original URL will not be linked. Read more at ]. -- ] (]) 06:07, 10 August 2020 (UTC)

== Replacing |ignore-isbn-error= and |doi-broken= by |isbn/doi=((invalid-value)) syntax ==

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 {{para|ignore-isbn-error|true}} parameter (and its alias {{para|ignoreisbnerror|true}}) would be a good candidate to be replaced by adding support for the double-parentheses-syntax to ] in the {{para|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 {{para|ignore-isbn-error|true}} was almost undocumented (meanwhile it can be found listed nearby the documentation for {{para|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 {{para|isbn}} values - only to find out that it is not supported there.

So, for consistency, it should be supported there as well, and the {{para|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), f.e. we recently had a discussion about quarters in {{para|date}}, where it was recommended as a breakout as well, see ]. 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.)

--] (]) 10:30, 10 August 2020 (UTC)

Followup: {{para|doi-broken}}/{{para|doi-broken-date}}/{{para|doi-inactive-date}} would be other candidates. While these and the {{para|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 {{para|doi}} would accept the ((syntax)) as well for such invalid DOIs.

--] (]) 10:39, 10 August 2020 (UTC)

== ]: Proper markup for citing a paper at a conference. ==

I would like to cite a paper from the 1965 Fall Joint Computer Conference, sponsored by the ] (AFIPS). The title of the book is ''AFIPS CONFERENCE PROCEEDINGS VOLUME 17 PART 1 1965 FALL JOINT COMPUTER CONFERENCE''. There is no part= parameter for volumes that are subdivided, and no organizer= parameter. I get<ref>{{cite conference
| title = INTRODUCTION AND OVERVIEW OF THE MULTICS SYSTEM
| booktitle = AFIPS CONFERENCE PROCEEDINGS VOLUME 17 PART 1 1965 FALL JOINT COMPUTER CONFERENCE
| page = 185
| author1 = F. J. Corbaro
| author2 = V. A. Vyssotsky
| volume = 27 Part 1
| conference = Fall Joint Computer Conference
| publisher = Spartan Books
}}
</ref> when I use the markup
<pre>
<nowiki>{{cite conference
| title = INTRODUCTION AND OVERVIEW OF THE MULTICS SYSTEM
| booktitle = AFIPS CONFERENCE PROCEEDINGS VOLUME 27 PART 1 1965 FALL JOINT COMPUTER CONFERENCE
| page = 185
| author1 = F. J. Corbaro
| author2 = V. A. Vyssotsky
| volume = 27 Part 1
| conference = Fall Joint Computer Conference
| publisher = Spartan Books
}}</nowiki>
</pre>

Is that really how it should be rendered? ] (]) 22:58, 12 August 2020 (UTC)

{{Reflist-talk}}

:At the very least, you should change the capitalization; see ]. Either spell out the volume in the title or use a separate {{para|volume}} parameter, but don't do both. Also, I would generally use only one of {{para|booktitle}} and {{para|conference}}. Your formatting of the page numbers makes this look like a one-page paper (not true); the correct parameter would be {{para|pages|185–196}} (note en-dash not hyphen in the page range). And you should probably list a doi ({{doi|10.1145/1463891.1463912}}) and an ISBN if you can find it. —] (]) 23:34, 12 August 2020 (UTC)

:Thanks. I have a few questions:

:*Is there a web site for looking up the DOI of a paper?
:*If I am only citing a single sentence, should I still give the full page range of the paper? That would seem to make it more difficult for a reader to verify the quote.
:*To what extent is it permissible to redact the title? Is this<ref>{{cite conference
| title = Introduction and Overview of the Multics System
| booktitle = ] Conference Proceedings
| doi = 10.1145/1463891.1463912
| page = 185
| author1 = F. J. Corbaro
| author2 = V. A. Vyssotsky
| volume = 27 Part 1
| conference = ]
| year = 1965
| publisher = Spartan Books
}}</ref> permissible:
<pre>
<nowiki>{{cite conference
| title = Introduction and Overview of the Multics System
| booktitle = ] Conference Proceedings
| doi = 10.1145/1463891.1463912
| page = 185
| author1 = F. J. Corbaro
| author2 = V. A. Vyssotsky
| volume = 27 Part 1
| conference = ]
| year = 1965
| publisher = Spartan Books
}}</nowiki>
</pre>

To put it in context, I frequently need to cite documents that were printed before there was such a thing as a DOI, and that often don't even have an ISBN. ] (]) 01:44, 13 August 2020 (UTC)

: ], use the oclc number from WorldCat when there is no isbn (you can, even when there is): <code>oclc=8558302617</code>, thus.<ref name=AFIPS-1965>{{cite conference |title=Introduction and Overview of the Multics System |booktitle=] Conference Proceedings |doi=10.1145/1463891.1463912 |page=185 |first1=F. J. |last1=Corbaro |first2=V. A. |last2=Vyssotsky |volume=27 Part 1 |oclc=8558302617 |conference=] |year=1965 |publisher=Spartan Books }}</ref> Note that there is no reason to ] the ]; you can just use it directly. ] (]) 02:31, 13 August 2020 (UTC)

::I would use {{para|doi}} and {{para|oclc}} if I knew how to look them up given the title. ] (]) 04:42, 13 August 2020 (UTC)

{{Reflist-talk}}
:: Regarding page numbers, we recently had several discussions on page numbers where we came to the conclusion that, in cases such as yours, we need parameters to optionally specify both, individual pages and page ranges. We also discussed two notations how to display this. Until these new parameters materialize, you can do it manually by specifying {{para|pages|185–196 }}, assuming that 185–196 is the page range of the article or chapter, and 185 the individual page where you found the citation.
:: Also, it is a good idea to use the {{para|date}} parameter instead of the {{para|year}} parameter. {{para|year}} is a leftover to provide an additional disambiguator in some cases in conjunction with harv referencing, in all other cases, {{para|date}} is the preferred parameter to be used - it is also more flexible. --] (]) 07:05, 13 August 2020 (UTC)
:::For what it's worth, I found the doi in this case (and the full page number range) by searching for the title (in double quotes) on Google Scholar, and following the first link that it gave me. The doi was both shown in the text of the page and incorporated into its url. But in many cases there are bibliographic databases like DBLP for computer science papers or MathSciNet and zbMATH for mathematics papers that have cleaner data than Google Scholar. The doi system used to have their own search engine for dois but I don't think it's there any more. As for whether to cite full page number ranges: for journal or conference articles, yes, for books, no, just cite the page you are using. It may be helpful to write out which page you are getting some fact from in a journal article, especially in longer ones, but I don't think that should go in the citation template itself (it can instead be a plain text note immediately following the template), and it may be better to name the subsection of the paper than just to use a page number in case a reader uses a copy of the paper that is paginated differently. —] (]) 07:29, 13 August 2020 (UTC)

== Small glitches masking and linking author names ==

Hi. I just documented an apparently undocumented special case of the {{para|-mask}} parameters. A numerical value of 0 will not display a dash at all, but if a corresponding {{para|-link}} parameter is defined as well, this will be taken as (linked) text. However, experimenting a bit with the parameter, I found a number of corner cases, which still seem to be a bit rough, that's why I am bringing this up for discussion and possible improvement:

* Without corresponding {{para|-link}}, {{para|-mask|0}} will still display a separator (; by default with CS1) in front of the following author names. Is this really useful or would it be better to suppress the leading separator as well and just start with the second name?
* If a corresponding {{para|-link}} is defined, it will be linked even if {{para|-mask}} has a numerical value > 0. While it might make sense to still link to the masked name if {{para|-mask}} is used to define some alternative text (see below), does it really make sense to link to a name labelled as ''dash'' (like ])? After all, the supposed application of this parameter is a list of works by the same author, so it can be assumed that the author name is already linked to in an unmasked citation starting the list further above. Of course, a work-around is to not specify {{para|-link}} in conjunction with {{para|-mask}} > 1, but if there is no useful application to displayed linked dashes, it would be more logical to suppress linking in this case.
* If {{para|-mask}} defines some alternative text, it may or may not make sense being able to use it as link label, so {{para|-link}} might make sense here depending on the alternative text: If the alternative text is a "full replacement" of the original name (like "]" or "]"), linking to it can be useful. If, however, {{para|-mask}} is used to define some extra text in front or following the original name (f.e. {{para|-mask|with Doe, John}}, a usage recently suggested in several other threads, f.e. ]), the link should probably be applied to the embedded original name like "]" only, not to the whole alternative string like "]" (as it currently does). Since the template has no reliable way to distinguish extra text from names, I propose the following enhancement:
: If the string defined by {{para|-mask}} does not contain a * character, the whole string will be used as link label if {{para|-link}} is provided as well (as now). If, however, the mask text contains a *, the * will be treated as a "smart" placeholder and will be replaced by a string of the form "<code>&lt;last></code>" derived from the corresponding name parameters {{para|-last''n''}}/{{para|-first''n''}}. In this case, only this placeholder value will be used as link label if {{para|-link}} is provided as well.
: So, the combination of {{para|author-first|John}} {{para|author-last|Doe}} {{para|author-link|John Doe}} {{para|author-mask|with *}} would result in "with ]".
: This would solve the "what to use as link label" problem and also avoid the repetition and hard-wiring of the name in the {{para|-mask}} parameter. It would also be a partial implementation of my more general placeholder proposal, discussed here: ].
--] (]) 09:27, 16 August 2020 (UTC)
:I have tweaked the sandbox so that mdash-masked names don't link on the presumption that the unmasked name has been linked in a preceding citation.
<div style="margin-left:3.2em">{{cite compare |mode=book |title=Title |author=Author |author-mask=2 |author-link=Author}}</div>
:When {{para|&lt;{{var|name}}>-mask|0}}, the name is omitted from the rendering along with its separator:
<div style="margin-left:3.2em">{{cite compare |mode=book |title=Title |author=Author |author-mask=0 |author2=Author2}}</div>
:—] (]) 18:49, 18 August 2020 (UTC)
:: Hm, but now the "special case" ({{para|-mask''n''|0}} in conjunction with {{para|link''n''|...}}) no longer works:
<div style="margin-left:4.2em">{{cite compare |mode=book |title=Title |author1=Author1 |author-link1=John Doe |author-mask1=0 |author2=Author2}}</div>
:: or
<div style="margin-left:4.2em">{{cite compare |mode=book |title=Title |author1=Author1 |author2=Author2 |author-link2=John Doe |author-mask2=0}}</div>
:: --] (]) 20:15, 18 August 2020 (UTC)
:::Historically, we have taken the decision to hide the author / contributor / editor / interviewer / translator name when {{para|&lt;{{var|name}}>-mask|0}}. Historically, when {{para|&lt;{{var|name}}>-mask|&lt;{{var|n}}>}}, where <code>0 != &lt;{{var|n}}></code>, we have taken the decision to replace the name with a concatenation of <code>&lt;{{var|n}}></code> mdashes. In this discussion it is proposed that these mdash replacements of name shall not be linked regardless of the state of {{para|&lt;{{var|name}}>-link}}. It does not make sense to me to ignore the {{para|&lt;{{var|name}}>-mask|0}} rule when {{para|&lt;{{var|name}}>-link}} has a value because that kind of inconsistency just confuses editors. So the rule should be:
::::when {{para|&lt;{{var|name}}>-mask}} is assigned a numeric value, {{para|&lt;{{var|name}}>-link}} is ignored.
:::—] (]) 21:54, 18 August 2020 (UTC)

== Use of Years from the Jewish Calendar? ==

I'd like to reference http://www.ajcarchives.org/AJC_DATA/Files/Vol_33__1931_1932.pdf using cite journal. The Year that is used is 5692 in the Jewish Calendar Anno Mundi. Is there any way to include this in the Cite Journal or is using the fallback 1931-1932 the only way?] (]) 03:43, 17 August 2020 (UTC)

:According to ], "Sources are at liberty to use other ways of expressing dates.. such as religious calendars", but, "In cases where the date as expressed in the source is not compatible with the template software, the citation should be created without using a template." The principal of the template is to help readers find a source, for verifying a cite. If the reader can reliably find the source using the 1931-1932 date, it might be OK to use that if you still want to use the template. -- ]] 04:03, 17 August 2020 (UTC)
: In your specific case, you do not need to convert dates because the book itself is using the Gregorian calendar for publication dates: July 1931. You should not specifiy a year range, as the book was published on a specific date in 1931, and the fact that the ''application'' of the book as a ''year book'' spans from 1931 to 1932 is irrelevant in regard to the bibliographical data needed in a citation, and for all other purposes, that information is already in the title (otherwise, if important for the reader, it could be added as a note following the citation). Something like this:
:: <code><nowiki>{{cite book |title=The American Jewish Year Book 5692: September 12, 1931, to September 30, 1932 |date=1931-07-16 |volume=33 |editor-first=Harry |editor-last=Schneiderman |publisher=] |location=Philadelphia, Pennsylvania, USA |url=http://www.ajcarchives.org/AJC_DATA/Files/Vol_33__1931_1932.pdf |access-date=2020-08-17}}</nowiki></code>
::: {{cite book |title=The American Jewish Year Book 5692: September 12, 1931, to September 30, 1932 |date=1931-07-16 |volume=33 |editor-first=Harry |editor-last=Schneiderman |publisher=] |location=Philadelphia, Pennsylvania, USA |url=http://www.ajcarchives.org/AJC_DATA/Files/Vol_33__1931_1932.pdf |access-date=2020-08-17}}
: --] (]) 08:47, 17 August 2020 (UTC)

== Translating into Sanskrit ==

This template( there) is not translated properly on the sa-WP as can be seen on . I asked for help regarding the same in ] and I was asked to offer help in fixing this up on the talk page. It would be nice if someone could direct me regarding the same. --] (]) 10:02, 18 August 2020 (UTC)
:You have more problems than mere translation:
::] (not used on your example page) is from 2011 (pre-{{tlx|citation/core}})
::] is from 2012 and uses a 2012 version of {{tnull|citation/core}}
::] looks like it is from 2016 (the history is oddly muddled) also uses the 2012 {{tnull|citation/core}}
::] is from 2013 and uses a 2013 version of the ] suite
::] is from 2015 also uses the 2013 Module:Citation/CS1 suite
:I presume that sa.wiki has other cs1|2 templates (]) so I expect that they are in a similar state of disarray.
:
:My recommendation is to upgrade all of the cs1|2 templates to the current version of the Module:Citation/CS1 suite (not as simple as it sounds). The module suite has better support for other languages (you still have to translate the English into Sanskrit but nearly all of those translations are done at Module:Citation/CS1/Configuration. If the sa.wiki community decide to do this, and if you require assistance, let me know, I can help.
:—] (]) 11:39, 18 August 2020 (UTC)
::{{re|Trappist the monk}} Thanks, I would bring it to notice of an admin of the sa-WP.--] (]) 08:57, 20 August 2020 (UTC)

== |last-author-amp= ==

{{diff|Template:Citation_Style_documentation/display|973873255|973265866|This documentation edit}} reminds me that {{para|last-author-amp}} should be deprecated in favor of a new parameter with a better name. We do not have {{para|last-contributor-amp}}, {{para|last-editor-amp}}, {{para|last-interviewer-amp}}, or {{para|last-translator-amp}} parameters. When {{para|last-author-amp|yes}}, any of the other name lists that have two or more names will use the ampersand separator between the last two names in the list.

What is the new parameter name? {{para|last-name-amp}} is problematic for obvious reasons. {{para|last-sep-amp}}? Or, something different, perhaps: {{para|namelist-last-sep|&lt;{{var|keyword}}>}} where <code>&lt;{{var|keyword}}></code> is <code>&</code> or <code>amp</code> or <code>and</code>; possibly other keywords? Still needs the new parameter name and keyword definitions.

—] (]) 19:53, 19 August 2020 (UTC)
:How about {{para|author-ampersand}}, {{para|editor-ampersand}}, etc.? Spelling out "ampersand" is a bit awkward, but its meaning is clearer than "amp". The {{para|xxx-ampersand}} model is easily extensible to other parameters, such as those listed above. The documentation could make it clear that the parameter, when set to "yes" or "y", renders an ampersand between the final two author/editor/translator names. – ] (]) 21:16, 19 August 2020 (UTC)
::{{para|last-author-amp}} applies to all name lists even when there are no names in the author name list:
:::<code><nowiki>{{cite book |title=Title |translator=Translator |translator2=Translator2 |last-author-amp=yes}}</nowiki></code>
::::{{cite book |title=Title |translator=Translator |translator2=Translator2 |last-author-amp=yes}}
::This mechanism makes sense to me because the name lists in a citation should all render with the same style. A single parameter name not closely tied to a particular name list seems to me better than renaming {{para|last-author-amp}} and creating four aliases of that – I can imagine editors adding an (unnecessary) alias parameter for each name list in the citation...
::—] (]) 21:37, 19 August 2020 (UTC)
:I've been wondering if late whether this parameter is strongly needed at all. But that aside, I'd go for {{para|namelist-last-sep|&lt;{{var|keyword}}>}} or similar. --] (]) 21:45, 19 August 2020 (UTC)
::I confess to wondering the same, but it exists and were we to take it away, no doubt, no doubt, torches, pitchforks, ...
::—] (]) 21:50, 19 August 2020 (UTC)
:::My mistake. I would support something like {{para|name-list-ampersand}} then. And I would not be excited about an open-ended ''var'' option for the separator. The last thing we need around here is more citation variation, let alone within CS1 templates. – ] (]) 21:56, 19 August 2020 (UTC)
::::There was this discussion: {{slink|Help_talk:Citation_Style_1/Archive_44#Is_there_any_interest...}} I thought I remembered more than that one but it appears that my memory is faulty.
::::—] (]) 22:18, 19 August 2020 (UTC)
: (edit-conflict) If we switch to use a different parameter, I think, it should be one not only allowing the feature to be enabled or disabled, but to actually specify the separator as well. That would be your proposed {{para|namelist-last-sep}}, although, I think, that name is too complicated (and contains an abbreviation not all people will understand). The {{tl|catalog lookup link}} template uses {{para|list-leadout}} for this. Given that it would apply to all name lists, {{para|leadout-separator}} or just {{para|leadout}}/{{para|lead-out}} could work as well (but could be easily confused with the {{para|postscript}} parameter).
:
: Is there a chance that we'd need to specify alternative leadouts also for other lists in the future? Then, the parameter name should be chosen in a way already taking such extensions into account, namewise. However, the only other lists at present are identifier lists and pages &mdash; I don't see any possible need to divert from the default separation schemes there, hence, no issue.
:
: However, there are other options as well:
:
: If, for example, we would want to get rid of a parameter, the functionality could be merged into one of the existing parameters
:* {{para|name-list-format}} (either through a new token such as "<code>amp</code>", or by just taking all string values except for "<code>vanc</code>" as the actual leadout string &mdash; however, in the latter case, the parameter name should be changed to become more meaningful again)
: or
:* {{para|display-&lt;names&gt;}} (either using negative values -1, -2, etc. to use & instead of the default leadout, or any string values other than "<code>etal</code>" to define the leadout string &mdash; in the latter case, the feature could not be used in combination with actually display-truncated lists, and in both cases, the parameter name may need to be changed as well).
:
: If the feature is only rarely used, it could even be emulated manually using {{para|&lt;name&gt;-mask''n''}}, but this would give more options than necessary including some undermining the feature, so it would only be an option for occasional use.
: --] (]) 23:01, 19 August 2020 (UTC)
::I don't think that I like {{para|list-leadout}} because <code>leadout</code> seems rather more jargon-ish than most cs1|2 parameters. I don't particularly care for {{para|namelist-last-sep}} for the same reason.
::
::The language list uses <code>&lt;space>and&lt;space></code> (two languages) and <code>,&lt;space>and&lt;space></code> (three+ languages). I see no reason to change that.
::
::I do rather like {{para|name-list-format|amp}} and {{para|name-list-format|and}} because that parameter applies to all name lists. <code>amp</code> and <code>and</code> will not conflict with <code>vanc</code> because Vancouver style only supports comma separators between names.
::
::I don't think that name-list separators have anything to do with the purpose {{para|display-&lt;{{var|name-list}}>}} serves (and negative numbers are just too cryptic). As it works now, {{para|display-&lt;{{var|name-list}}>}} causes cs1|2 to ignore {{para|last-name-amp}}. I think that this is probably the correct action to take when both parameters are present.
::—] (]) 00:12, 20 August 2020 (UTC)
::: I forgot about the language list, but, like you, I don't see any need for a change there.
::: I mentioned {{para|display-&lt;{{var|names}}>}} only for completeness and because it also deals in some way with the last name in a list, but I completely agree with you, that semantically it has a very different purpose. (Talking about it, this reminds me that these parameters should better be named {{para|authors-display}}/{{para|editors-display}} than {{para|display-authors}}/{{para|editors-display}} to follow the naming scheme of most of the other modern parameters to further differentiate on the left rather than the right side.)
::: I, too, find {{para|name-list-format|amp/and/vanc}} a good name for the purpose (and much better than {{para|last-author-amp|yes}}), and also like the idea of limiting the choices to a few hardwired tokens instead of allowing this parameter to accept free text.
::: --] (]) 10:44, 20 August 2020 (UTC)
::::We really should rename {{para|name-list-format}} to something shorter, like {{para|nf}} (which is short for ''name format'') in parrallel to {{para|df}} (which is short for ''date format''). &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 19:58, 23 August 2020 (UTC)

== News article on two pages ==

Is there a best practice for citing a news article that starts on page 1, for instance, and continues on page 12? For instance, I have an article clipped on Newspapers.com and I had to do two separate clippings to get the whole thing. https://www.newspapers.com/clip/57596810/roads-an-explosive-issue-for-the-1980s/ and https://www.newspapers.com/clip/57596856/roads-an-explosive-issue-for-the-1980s/ and I'd like to link to both clippings in the ref. Thanks! –]] 22:22, 19 August 2020 (UTC)
: Sure, use the {{para|pages|1, 12}} parameter. Regarding two links, I would use {{para|url}} for the starting page of the article and append a convenience link (like ) at the end of the citation, that is immediately before the closing <code><nowiki></ref></nowiki></code>. For occasional use, you could also link the two pages {{para|pages|, }} (as it happens a lot with documents hosted at archive.org recently), but I don't like this very much and don't recommend it for frequent use.
: --] (]) 23:23, 19 August 2020 (UTC)

== Citation Style documentation/id2 ==

With {{diff|Template:Citation_Style_documentation/id2|974507123|969859790|this edit}} Editor ] added an {{tlx|under discussion}} template to ]. The {{tnull|under discussion}} template points to an RfC at {{slink|Misplaced Pages:Village_pump_(proposals)#Issues_raised_by_Citation_bot}}. Because that RfC is not about the cs1|2 identifier documentation template, I reverted. Editor Francis Schonken ignored ] and reverted me with the edit summary {{tq|The RfC might result in a rewrite of this template documentation}}. I will not edit war. Editor Francis Schonken: you should self revert and discuss here.

—] (]) 15:17, 23 August 2020 (UTC)
: I, too, think that the template does not belong there. On the other hand, the linked discussion won't last forever, so it is a temporary issue only.
: However, speaking about this documentation snippet, I take serious issue with the notion regarding {{para|url}} being a link to a free resource:
:: "''The |url= parameter 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.''"
: This is ''one'' possible use of the parameter, but ''not'' its ''primary purpose'' per our policies and guidelines on citations. While, of course, it is always great if the link points to a free resource, and it is perfectly fine to select a free one if we are in the luxury of having multiple links available (and there are no other reasons to prefer another link), there is no fundamental requirement for the link to point to a ''free'' resource.
: The requirement, per our policies, is that the link is the one used by the editor adding the citation to support a statement in an article. If this happens to be hidden behind a paywall or by other means limiting the access, that may make things more difficult for other readers but it does not invalidate the citation or the link. In fact, removing such an URL for being unfree would invalidate the citation.
: I can see the desire to promote free resources, but this is the wrong place for it - it is actually counter-productive here. The wording needs to be adjusted to be in sync with our policies and guidelines.
: --] (]) 18:24, 23 August 2020 (UTC)
::{{ping|Matthiaspaul}} I'd like to see your opinion in the ] RfC, instead of initiating, here, a same discussion about the same topic that is currently the subject of an open RfC. I assume that answers Trappist the monk's question too: could we all give it a little more effort not to duplicate the same discussion over multiple talk pages at the same time? It's not only against the rules on ], but entirely impractical. --] (]) 04:41, 24 August 2020 (UTC)
:: In view of a comment I got , pinging all participants in this talk page section, thus including {{u|Trappist the monk}}, asking to go express their opinion on the ground of the matter at ]. --] (]) 06:58, 24 August 2020 (UTC)

Considering that in the linked discussion some users have described the discussion on what templates do as a "red herring", I suggest that it's not at all clear whether this documentation is supposed to be affected. It's not clear whether this warning is neutral. ] 12:59, 24 August 2020 (UTC)
:{{ping|Nemo_bis}} Documentation is for users that use the template. Template documentation can be updated without a change in the template code (the code is what defines what the template "does"). Giving an example (for another template): was a major update of a template's documentation, without any change in the template's code. That update to the documentation had been discussed before it was implemented, and that prior discussion was in response to the outcome of an RfC. It seems rather useful to attract broad attention to the Citation bot RfC, drawing attention to the fact that it might affect the template documentation. If "it's not at all clear whether this documentation is supposed to be affected" and open-ended questions in an RfC allow to give answers that divert from what is written in the template documentation, then of course whether or not the template is directly or indirectly affected is part of the RfC's topic. Which should (as long as the RfC is open) be discussed at the RfC and not here. --] (]) 15:36, 24 August 2020 (UTC)

== Support for ISO:2019 month precision ==

Matthias had been adding support for ISO:2019 month precision in the sandbox based on ] (it comes up regularly here and there). I think it is prudent to advertise those changes here and verify there is consensus both for the functionality and for the particular implementation. (I for one think it is reasonable functionality; it may need testing on rtl wikis.)

Some examples:
* {{Cite book/new |title=Title |date=2020-01-XX}} with <code><nowiki>{{Cite book/new |title=Title |date=2020-01-XX}}</nowiki></code>
* {{Cite book/new |title=Title |date=2020-01-XX |df=mdy}} with <code><nowiki>{{Cite book/new |title=Title |date=2020-01-XX |df=mdy}}</nowiki></code>

And a few which still error (as expected):
* {{Cite book/new |title=Title |date=2020-01}}
* {{Cite book/new |title=Title |date=2011-12}}
* {{Cite book/new |title=Title |date=2020-01 |df=mdy}}

I do not personally like the -XX in the first example, but feel free to review. This may also be something to let ] know about.
--] (]) 16:19, 23 August 2020 (UTC)


== Another generic title: "Conference Paper" ==
:This should not be supported unless there's consensus at ] to consider 2010-01-XX an acceptable format. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 17:18, 23 August 2020 (UTC)


See ] —] (]) 05:32, 24 December 2024 (UTC)
: (edit-conflict) This is meant as kind of a compromise/workaround. It is deliberate that your second set of dates (in "yyyy-mm" format) still fails for now. My plan was/is to allow the ISO 8601:2019 form "yyyy-mm-XX" on template input parameter level only in order to give users some option to enter dates with unknown days in templates otherwise using the ymd format. At present, because the more obvious form "yyyy-mm" is still disallowed by MOS, users are forced to use "MMMM yyyy" instead, and some users are then trying to use this inconsistency to convert whole articles to use the dmy or mdy format in citations. No good.
: My plan was to convert dates entered in the form "yyyy-mm-XX" still display as "MMMM yyyy" for now, however, this automatic conversion didn't work as expected (I have to more carefully study the code around the reformatter routine for this), so that, at present, dates entered in the form "yyyy-mm-XX" are by default actually displayed as such as well (unless overridden by {{para|df}} or {{para|cs1-dates}}).
: At a later stage (but this actually requires a slight change of the MOS to disallow the "yyyy–yy" form in citations and instead allow the "yyyy-mm" form there), such dates could be more reasonably displayed as "yyyy-mm" instead of "MMMM yyyy" (or "yyyy-mm-XX"). At that later stage, we could allow the "yyyy-mm" form also on input level. However, I think, we should count in several months as a transitional period.
: It is my estimation that we have about 200 instances where abbreviated year ranges are used in the {{para|date}} parameter (but the insource search times out, so I don't know for sure). Oddly enough, abbreviated year ranges are more prevalent in the {{para|year}} parameter (probably for historical reasons), but, still, the usage is minimal compared to the literally millions of places where the "yyyy-mm" form could be reasonably used in citations in order to improve consistency and readability.
: Most of the uses of year ranges (abbreviated or not) in citations seem to be actually wrong and just rooted in the fact that the exact publication date isn't known. That's why I ] for this to make it easier to check these ranges. With the necessary research it should be possible to provide a specific publication date instead of a year range in most of the cases (example: ]). There might be a few exceptions, but in none of the citations I inspected so far was some underlying need to use an abbreviated year range, so that, even if the actual publication date remains unclear, it is still possible to convert such date ranges to their non-abbreviated form without any backdraws for the readers.
: --] (]) 17:35, 23 August 2020 (UTC)
::'''Oppose'''. This is a totally novel notation and should be strictly forbidden. It doesn't work with any tool that a person might use to help format citations for Misplaced Pages. It's confusing and hideous. ] (]) 19:27, 23 August 2020 (UTC)
::: It is an international standard notation (recommended by ISO, but also by various other institutions) - you can be sure tools will be updated to support it. However, I, too, don't find it visually particularly pleasing. But what I displease much more is that some users attempt to convert citations in ymd format into other formats for the occasional use of the "MMMM yyyy" form for incomplete dates. The goal is to eliminate a need to "abuse" the "MMMM yyyy" form and use a true ymd form also for incomplete dates for improved readability and consistency.
::: As I wrote (and this is also why I didn't announce this extension at this time), the implementation is not finished yet: The "yyyy-mm-XX" is not meant for display purposes, but only for entry purposes on source code level, so there won't be any visual change in how citations look like in articles.
::: --] (]) 19:56, 23 August 2020 (UTC)
:'''Oppose'''. Actually, I sometimes do use notation like 2020-08-XX — when I'm patrolling recently prodded articles by date, building a list of them to add to deletion sorting pages, and haven't filled in some of the dates yet. If they ever creep into an actual edit, it's a mistake and I want that mistake to be flagged, not treated as meaningful. I agree with {{u|Jc3s5h}}'s description of this as "confusing and hideous". Maybe "an abomination" would be more accurate. If the ISO approved these, it suggests that there's something seriously broken at the ISO. —] (]) 22:08, 23 August 2020 (UTC)
::: To me such rants suggest a seriously broken state of the English Misplaced Pages ("being almost too clumsy to move forward and not agile to address real-world needs any more") and that some of its users have lost contact with the progress in the outside world. Makes me sad.
::: It's not "''if''", the notation is part of ISO 8601, and has been adopted in countless country-specific standards internationally.
::: What might be even more shocking then is the fact that it was the US Library of Congress together with many other libraries and publishers who have been pushing this notation forward in particular for use in bibliographical contexts since 2012, see f.e. .
::: A usage even pre-dating this initiative has been in technical guidelines by the BSI for reliable and secure document exchange.
::: So, perhaps it is time to switch from foot-stomping fundamental opposition to versatile solution-oriented thinking again. F.e. in regard to your described personal habits, you would just have to use lowercase letters 'x' and your personal notation won't clash with the international standard any more. Much more sensible than trying to tell other users not to use a notation where appropriate, IMHO.
::: --] (]) 15:12, 24 August 2020 (UTC)
:'''Oppose'''. The date notation is unusual and confusing. We need to reduce date format options rather than extending them. The ISO date format is confusing to many and is not clear what it means. There are large numbers of people who cannot follow the rules and put it in incorrectly so it would be a much more sensible option to get rid of ISO date formats completely. ] (]) 22:56, 23 August 2020 (UTC)
:: Trying to tell users not to take advantage of a notation just because of the ignorance of a few does not sound very sensible to me, in particular because those few can continue to use whatever they have used so far ("backward-compatibility is built-in") and they won't even see a difference in the rendering of citations in articles despite this notation being used by other users. (What? No difference? How is that? Well, this requires reading before complaining...)
:: Proposing to get rid of one of the two most commonly used date formats on this planet is, IMHO, the opposite of smart. If there is ever a format to go away it would be the mdy format because this is only used by a minority of users on this planet and is causing an endless stream of confusion (and accidents). Actually, ''if'' we would have to adopt a single format only, it would be the ymd format for sure, as the international date format is understood anywhere on the planet (except for, perhaps, in a few ignorant holdouts living more than four decades in the past, that is, before ISO 8601 became an international standard).
:: No, I don't propose this, but it hopefully illustrates how arrogant and childish it is to deny other people's obvious needs.
:: Regarding reducing date format options, the very goal of this minimal change is actually to ''reduce'' the formats that have to be used in citations at the same time. But the solution cannot be to get rid of the ymd format, but to make it possible to use that format consistently also if the day is not known, that is, to first work around an arbitrary restriction only imposed by the current wording of the MOS, and at a later stage to eliminate the restriction completely. This will significantly improve the situation for millions of citations, and without any need to remove support for ymd (your proposal) or mdy (my somewhat pointy, but tongue-in-cheek counter-proposal). Peace.
:: --] (]) 15:12, 24 August 2020 (UTC)
:'''Oppose''' This date notation is very useful for a very specific use case, and we are not this case. ] (]) 23:07, 23 August 2020 (UTC)
:: Citing from the Library of Congress' EDTF documentation:
::: "''Unspecified digit(s) from the right: The character 'X' may be used in place of one or more rightmost digits to indicate that the value of that digit is unspecified, for the following cases: Year and month specified, day unspecified in a year-month-day expression (day precision) Example ‘1985-04-XX’''"
:: So, the usage of the "yyyy-mm-XX" notation (with uppercase letter 'X') is a perfect match for the intended purpose given that the only way we can currently specify a date in the "yyyy-mm-dd" mask (but with unknown day) is using its "yyyy-mm-XX" sub-format. Other ad-hoc forms I have seen being used in the wild over the years were "yyyy-mm-uu" (with lowercase letters 'u'), "yyyy-mm-00" and "yyyy-mm-??", but none of them was formally standardized. Of course, just using "yyyy-mm" would be even better. --] (]) 15:12, 24 August 2020 (UTC)

Latest revision as of 15:39, 24 December 2024

    This is the talk page for discussing improvements to the Help:Citation Style 1 and the CS1 templates page.
    Shortcut
    Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97Auto-archiving period: 20 days 
    To help centralize discussions and keep related topics together, the talk pages for all Citation Style 1 and Citation Style 2 templates and modules redirect here. A list of those talk pages and their historical archives can be found here.
    This help page does not require a rating on Misplaced Pages's content assessment scale.
    It is of interest to multiple WikiProjects.
    WikiProject iconMisplaced Pages Help High‑importance
    WikiProject iconThis page is within the scope of the Misplaced Pages Help Project, a collaborative effort to improve Misplaced Pages's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Misplaced Pages HelpWikipedia:Help ProjectTemplate:Misplaced Pages Help ProjectHelp
    HighThis page has been rated as High-importance on the project's importance scale.
    WikiProject iconAcademic Journals
    WikiProject iconThis page is within the scope of WikiProject Academic Journals, a collaborative effort to improve the coverage of Academic Journals on Misplaced Pages. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Academic JournalsWikipedia:WikiProject Academic JournalsTemplate:WikiProject Academic JournalsAcademic Journal
    WikiProject iconMagazines
    WikiProject iconThis page is within the scope of WikiProject Magazines, a collaborative effort to improve the coverage of magazines on Misplaced Pages. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.MagazinesWikipedia:WikiProject MagazinesTemplate:WikiProject Magazinesmagazine
    See WikiProject Magazines' writing guide for tips on how to improve this article.
              Other talk page banners
    Some of the templates discussed here were considered for merging or deletion at Misplaced Pages:Templates for discussion. Please review the prior discussions if you are considering re-nomination:
    ? view · edit Frequently asked questions
    I would like to add a free-to-read publisher to the DOI prefix list in Module:Citation/CS1/Configuration
    Module:Citation/CS1/Configuration needs the 10.xxxx/... part of the DOI associated with the publisher. All the publications of the publisher must be free-to read. Once that is done, the xxxx part can be added to the list under local function build_free_doi_registrants_table(). Also leave a note at User talk:Citation bot.
    I would like to add a free-to-read journal to the DOI prefix list in Module:Citation/CS1/Configuration
    Module:Citation/CS1/Configuration needs the 10.xxxx/yyyy part of the DOI associated with the journal. All the articles associated with that DOI pattern must be free-to read. Once that is done, the xxxx/yyyy parts can be added to the list under local extended_registrants_t = { with the format = {'YYYY'},. If there are multiple journals with the same DOI prefix, they can be grouped together with the format = {'YYYY', 'ZZZZ', '...'},. Also leave a note at User talk:Citation bot.
    I would like to add a geo-dead/geo-access URL keyword
    Previous discussions have come to the conclusion that this is not workable. Websites change which regions can access them regularly, and these websites are regardless not fundamentally dead.
    I would like support for PDF page numbers
    The specific page of a specific PDF may change between clients with the same file or files with the same client. Consider using a |chapter= or |quote= instead.
    I would like my change done now
    Local consensus is that these modules sync from their sandboxes approximately once every 3-6 months. This is due to complexity of changes, the number of transclusions these modules have, and to be sure sufficient consensus exists for a change.
    I don't like (identifier) in the links to identifier pages
    This is done to differentiate identifier links (... lorem ipsum dolor sit amet. ... ) from prose links (... the digital object identifier was introduced in 2000 by ... ) in Special:WhatLinksHere.

    Internet archive print disability book links

    There are a number of links to books which have since lost their accessibility to the general public on Internet Archive (e.g., and of the same book). These are now " available to patrons with print disabilities."

    Should the links like these which are not accessible to users without print disabilities be removed, or would it be possible to add another |url-access parameter to signify this? Tule-hog (talk) 20:48, 28 November 2024 (UTC)

    Alternatively (as with {{Hopcroft and Ullman 1979}}) should the link be appended to a reference a note? Tule-hog (talk) 01:33, 29 November 2024 (UTC)
    @Tule-hog: I don't think any of the values in the current current scheme accurately represent the access status you have described. I'd be inclined to leave |url-access= blank and create a new template to indicate this information after the citation template, similar to many of the templates in Category:External link note templates. Daask (talk) 17:06, 16 December 2024 (UTC)
    I went with {{Internet Archive patrons}} as a temporary solution, which allows for tracking pages (and ref-templates) that use it (which should make future modifications more streamline-able). Tule-hog (talk) 17:14, 16 December 2024 (UTC)
    User:Tule-hog, the book is fully searchable (click the magnifying glass). And, you can open it to any page like page 42. This is the same as many books at Google Books. I would be careful about tagging books as "inaccessible" because there are many levels and types of access, beyond complete full access. We certainly don't tag Google Books. Also, access levels can change on a whim of the library based on publisher requirements, it's not set in stone, trying to maintain those tags over the years will be impossible. It's really beyond our scope or need. Readers are expected to be able to navigate and understand external websites. -- GreenC 00:24, 17 December 2024 (UTC)
    That particular book is not fully browsable, click 'next page'.
    To clarify: are you in favor of deprecating url-access entirely, or are you making a point about Internet Archive's collections? Tule-hog (talk) 00:39, 17 December 2024 (UTC)
    "Fully browsable" is a rare condition for (copyright) books, at any website. At Internet Archive, for example, permissions can include:
    • Full access for everyone
    • Full access if you login
    • Full access if you are disabled
    • Some book pages browsable for everyone
    • Some book pages browsable if you login
    • Search access for everyone but not browsable
    • Search access if you login but not browsable
    • There are other permissions controlling access to files
    Also, these permissions can, and frequently do, change at the whim of Internet Archive and the publishers, at any time. Including new types of permissions.
    So my question is how you plan on communicating AND maintaining this information on Misplaced Pages for the next 20 years for millions of books.
    Also, this is only one website. Google Books has similar gradations, is even more complex, and more opaque how it works. For these reasons we don't track the precise levels of access. It's generally understood that any copyright material is by default probably going to have some restrictions. It's a matter of practicality. -- GreenC 02:50, 17 December 2024 (UTC)

    DOI prefix limits should be bumped.

    We have DOI prefixes in the 10.70000s now. The limit should be bumped to 10.80000s Headbomb {t · c · p · b} 04:05, 1 December 2024 (UTC)

    Seconding this! —⁠Collin 22:10, 17 December 2024 (UTC)
    If that is true, why (as I write this) is Category:CS1 errors: DOI empty?
    {{PAGESINCATEGORY:CS1 errors: DOI}} → 0
    —Trappist the monk (talk) 22:47, 17 December 2024 (UTC)
    @Trappist the monk: The article Kiwai Island has a DOI of 10.70460/jpa.v7i1.183 in reference #1 that is incorrectly giving a "Check |doi= value" error. Could you please help fix this? GoingBatty (talk) 19:41, 19 December 2024 (UTC)
    Fixed in sandbox:
    Cite journal comparison
    Wikitext {{cite journal|date=2016|doi=10.70460/jpa.v7i1.183|first=Ian J|issue=1|journal=Journal of Pacific Archaeology|last=McNiven|pages=74–83|title=Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea|volume=7}}
    Live McNiven, Ian J (2016). "Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea". Journal of Pacific Archaeology. 7 (1): 74–83. doi:10.70460/jpa.v7i1.183. {{cite journal}}: Check |doi= value (help)
    Sandbox McNiven, Ian J (2016). "Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea". Journal of Pacific Archaeology. 7 (1): 74–83. doi:10.70460/jpa.v7i1.183.
    —Trappist the monk (talk) 20:06, 19 December 2024 (UTC)

    spurious errors when fetching identifier limit data from commons

    cs1|2 stores identifier limit values in tabular data on commons: c:Data:CS1/Identifier limits.tab. This little file allows us to keep identifier limits for all wikis using a recent version of the cs1|2 module suite up to date. Alas, there is some sort of spurious 'something' that sometimes causes the data fetch to fail. Currently, when a failure occurs, all cs1|2 templates on a page render a shrieking-red error message: Lua error in Module:Citation/CS1/Configuration at line 2083: attempt to index a boolean value and complaints at various help and village pump pages. The fix is a null edit.

    I have tweaked the sandbox so that it traps the boolean return, sets the identifier limits to 99,999,999,999 which will cause all limit checks to pass, and adds the page to Category:CS1 maint: ID limit load fail. Articles collected in the category can be null edited to clear the category. Unlike all other maintenance categories, this category does not have an accompanying maintenance message because it would be repeated by every cs1|2 template.

    I tested this new code by disabling the category namespace limit so that a cs1|2 template in my sandbox would emit the error category when I forced a boolean false return from the data fetch.

    —Trappist the monk (talk) 01:15, 2 December 2024 (UTC)

    This seems like a functional workaround. Is it worth reporting a bug to Phabricator to get at the root cause, which may be affecting other processes on MediaWiki sites? A developer may be able to poke through logs to find out why this failure is occurring. – Jonesey95 (talk) 21:38, 2 December 2024 (UTC)
    There is Phab:T229742 which may be related.
    —Trappist the monk (talk) 22:32, 2 December 2024 (UTC)

    cite episode id parameter silently ignored

    {{cite episode}} currently silently ignores |id=. I have been using it to add IMDb identifiers to some items, eg. Special:Diff/1261220079 using {{IMDb ID}}. I propose that we display the |id= parameter just like most other CS1 templates. A more elaborate discussion of IMDb in particular as an identifier is at Misplaced Pages talk:IMDb link templates § IMDB as an identifier in citations. Daask (talk) 22:44, 4 December 2024 (UTC)

    |id= was:
    Because it was the goal of the wikitext-to-module conversion to be transparent, it was necessary to overwrite whatever might be assigned to |id=. I do not recall any discussion here suggesting that we should change that.
    I am not enthusiastic about making a change just to support an identifier for a source that editors at WP:RS/P have determined to be generally unreliable.
    —Trappist the monk (talk) 00:20, 5 December 2024 (UTC)
    I've commented at the other discussion, there's general agreement that IMDb should not appear in references. I don't see how a courtesy link to an unreliable source can help with verification. -- LCU ActivelyDisinterested «@» °∆t° 01:16, 5 December 2024 (UTC)
    I apologize for the delay in responding. Gonnym removed all transclusions of Template:IMDb ID two days after I raised the question here, making it difficult for me to determine how the template had been used. I strongly disagree with Gonnym's claim that these uses of Template:IMDb ID were "not what the ID= is for". It's exactly what |id= is for. Our current guideline is strong on this topic: Misplaced Pages:Citing sources § Links and ID numbers says "A citation ideally includes a link or ID number to help editors locate the source." Thus, according to this content guideline, for these audiovisual materials where no link is suitable, some identifier should be included. I don't make a point of adding identifiers of this kind to citations generally, and I'm not sure I would advocate for the strength of that guideline's wording, but I believe that identifiers are beneficial to include for obscure content, such as old episodes of broadcast news. Contra ActivelyDisinterested, an identifier is not a convenience link.
    This leads to the question of which identifier to use. Contra Trappist the monk, I don't think it matters whether IMDb is a reliable source. It matters whether its identifiers are ambiguous by being either underspecified or conflations. IMDb's primary benefit isn't the quality of its data or it's market share as Folly Mox suggests, but the breadth of its coverage. Other websites besides IMDb itself use its identifiers. If other identifiers were available, I would prefer to use them, but for items with no other identifier, we must use what we have.
    For example, I think this citation (featuring a permanently dead link with no archives available) would be greatly benefited from the addition of an identifier from IMDb or anywhere else:
    I can't find anything about this episode on the internet except https://www.cbc.ca/news/canada/zaccardelli-faults-u-s-government-for-arar-s-deportation-1.757351 .
    Perhaps a better solution than linking to IMDb would be to link to Wikidata using {{QID}}. Wikidata's primary web interface isn't very navigable for readers, so perhaps a link target of Reasonator (eg.) or SQID (eg.)? Forcing editors who want to add identifiers to create a Wikidata item linked to IMDb instead of using IMDb directly is more work for editors, which you may or may not find desirable. Searching revealed no existing policy or RFCs on using Wikidata an identifier in citations. Daask (talk) 02:04, 24 December 2024 (UTC)
    The us of Wikidata on Misplaced Pages still has to comply with the consensus on Misplaced Pages. So using Wikidata to obfuscate a link to IMDb in a reference when there is a consensus against using IMDb in references sounds like a bad idea. -- LCU ActivelyDisinterested «@» °∆t° 10:52, 24 December 2024 (UTC)
    @ActivelyDisinterested: I wouldn't call this obfuscating a link to IMDb. As far as consensus on Misplaced Pages, we have a content guideline that requires the use of an identifier. That's as strong a consensus as it gets on Misplaced Pages. If this local consensus wants to argue against the use of IMDb as a identifier, I may be willing to accept that if Wikidata is preferred instead. At this local venue, we don't have the option of overruling a content guideline, and so may not forbid both IMDb and Wikidata. Daask (talk) 15:11, 24 December 2024 (UTC)
    The guideline doesn't require the use of an identifier, and certainly not these proposed identifiers. Nikkimaria (talk) 15:14, 24 December 2024 (UTC)
    No there is a strong general consensus across multiple discussions to not link IMDb in references, working out ways to circumvent that consensus is unadvisable.
    Also the guideline also doesn't agree with your interpretation. It doesn't say that an ID is required, it says ideally an ID can be included if it helps locate the source - IMDb doesn't help in locating the source. Even if it did require such a link that still wouldn't support your point, as it doesn't say that link must be to IMDb. -- LCU ActivelyDisinterested «@» °∆t° 15:29, 24 December 2024 (UTC)
    I think it does matter that IMdB is not a reliable source, and expect most editors would agree. Out of curiosity, is the IMDb page on the episode given as example here (which I could not find) any more informative than the CBC archive summary, which also includes a "shotlist" element allowing for verification of certain quotes? Does the IMDb page truly help editors locate the source, or is it a user-generated summary of the source? (Incidentally, there is an archive, but Internet Archive are unable to display it, possibly as a result of their recent lawsuit.) Folly Mox (talk) 13:25, 24 December 2024 (UTC)
    @Folly Mox: Thank you for finding those archives! I was unable to do so despite significant effort, and obviously could learn a thing or two about finding them. I would regard the CBC archive summary as essentially the official website for the source, though not a manifestation of the source, and would certainly link to it.
    I don't expect identifiers to be informative. Is an ISBN informative? An ISBN is a number, not a resolver, a database, or a source. Daask (talk) 15:39, 24 December 2024 (UTC)

    Request to edit note at top of Category:CS1 maint: unflagged free DOI

    Hi there! Could someone please update the note at the top of Category:CS1 maint: unflagged free DOI? It mentions an issue affecting 17 Misplaced Pages articles, but there are now less than 10 articles in the category. Thanks! GoingBatty (talk) 17:45, 8 December 2024 (UTC)

    See WP:BOLD. Also, I wonder why it dropped from 17. There hasn't been a template update in ages... I suspect someone performed bad fixes just to avoid the categorization. Headbomb {t · c · p · b} 12:15, 10 December 2024 (UTC)
    @Headbomb: See WP:BOLD#Be careful. I don't know what the correct change should be, so it's better to get consensus here. GoingBatty (talk) 19:38, 19 December 2024 (UTC)

    Links to preprint archives

    It is usefull to have the link to arXiv with its own identification numbers in the citation template, but

    Petr Karel (talk) 10:47, 10 December 2024 (UTC)

    Proposal: Replace "biorxiv=" by "preprint DOI=" to include other preprint archives. The link to preprint is usefull when the final version is not free to access. --Petr Karel (talk) 11:19, 10 December 2024 (UTC)

    Simply put, there's almost nothing on vixra we should want to cite. It is not a reliable source, worse than your usual repository of preprints. It's a nutjob farm. Headbomb {t · c · p · b} 12:13, 10 December 2024 (UTC)
    If you want to include a courtesy link to the free preprint, along with a citation to the print version, you can do so after the template but before the closing ref tag. As an example:
    <ref>{{cite journal |author=Author |title=Title |journal=Journal |url=https://journal.org}} </ref>
    Gives you the following:
    Author. "Title". Journal. Free to access preprint
    -- LCU ActivelyDisinterested «@» °∆t° 14:36, 10 December 2024 (UTC)
    I realize this is not the right place to bring this up, but the Visual Editor should really offer better support for this. Rjj (talk) 22:34, 10 December 2024 (UTC)
    That workaround feels like a kludge. I would prefer to see preprint URL support integrated into the template as a preprint-url parameter, which for some reason, has not yet been proposed in any of the 96 archive pages of this talk page. The WP:PREPRINT guideline states, "links to such repositories can be used as open-access links for papers which have been subsequently published in acceptable literature", and it would be useful for the template to link to both the paywalled published version and the unpaywalled preprint without any extra workaround. Using a template parameter would also make the preprint URL more machine-readable, compared to using a separate link.For example, I recently cited the following source:
    Crowston, Kevin; Wei, Kangning; Howison, James; Wiggins, Andrea (5 March 2008). "Free/Libre open-source software development: What we know and what we do not know". ACM Computing Surveys. 44 (2). Association for Computing Machinery: 7:1–7:35. doi:10.1145/2089125.2089127. ISSN 0360-0300. Retrieved 15 December 2024.
    I wanted to also include a link to this preprint of the article hosted by the Internet Archive. It would have been nice to have a preprint-url parameter that would have allowed me to do this in the {{Cite journal}} template. — Newslinger talk 22:30, 15 December 2024 (UTC)
    I've been just putting the preprint URL in |url=, because the publisher's version is already linked from |doi=. I realize this creates some confusion about which version the person creating the reference is actually looking at. I don't usually verify that the versions are identical, but if I have significant doubt, I include citations for both the preprint and the final published version in the same <ref>...</ref> with "Republished as/from" between them, with the first citation being the one I was actually looking at. The word "republished" to me leaves open the possibility of more substantial changes than "reprinted". I am surprised that neither Misplaced Pages:Citing sources § Say where you read it nor Misplaced Pages:Citing sources § Dates and reprints discuss the issue specifically. I welcome feedback from other editors on my practices.
    The issue of multiple versions of a work is bigger than just preprints, and |preprint-url= feels to me like a partial solution to a bigger problem. In some fields (eg. economics, public policy) working papers with multiple drafts distributed over many years are normal prior to publication. Daask (talk) 16:42, 16 December 2024 (UTC)
    I've also done that before, and I agree that it can be confusing for the reader, which is why I'm hesitant to include preprints in the url parameter now. Since the sole purpose of the preprint-url parameter would be to present the reader with an open-access link, I don't think it would be necessary to link multiple drafts in the citation template. — Newslinger talk 08:53, 17 December 2024 (UTC)

    Cite chapter in book with no editor

    I read part of Help talk:Citation Style 1/Archive 61#Time to fix "In: <title>"? (and somewhat related Help talk:Citation Style 1/Archive 10#Foreword|) and I am not exactly clear on the result of that discussion.

    I would like to discuss a related use case to those above discussions which is old books where you have a collection of works in a single book with no editor. This was apparently somewhat common in miscellanies and anthologies compiled in the middle ages. Here is a pretty good example of a miscellany with no editor but with named contributors and chapters: https://mvm.dhil.lib.sfu.ca/manuscript/109. The issue with the current implementation is that the citation will look like the author of the chapter is the author of the entire book because there is no "in."

    I don't have many examples but I have seen the form "chapter" in "book name," without an attribution to any editor, in history journals, so I think this may be common practice.

    So I guess my post has multiple aspects:

    1. Do journals use the "chapter" in "book name" form even with no editor? How commonplace is this? My assumption right now is that it is somewhat common.

    2. Should we support such a feature? My thought here is that we should.

    3. How should this be supported? We can support this feature without necessarily implementing "in" for all book chapters. We could do so by using a new parameter "chapter author," which would then always use "in," without having to use it in all cases, for example. There could be multiple ways to achieve this result. I would not like a solution that leaves the

    Any thoughts or questions on the above would be appreciated. I apologize if this is already a settled point. I did my best to search for previous discussions by searching "no editor" and '"editor" "is unknown"' in the archive. Lastly, if this is already supported, I suggest it be made more clear in the documentation as I could not find it.

    (edit: Reading 'Time to fix "In: <title>"?' again, it is actually the exact same issue. I'm not sure what I thought it meant when I first read it. Somehow I thought it was about citing a chapter of a book where the entire book was written by one author.) J2UDY7r00CRjH (talk) 22:43, 12 December 2024 (UTC)

    J2UDY7r00CRjH, it sounds here like the problem statement is a citation like Author, Chapter. "Chapter title". Edited Volume gives the impression that the chapter author contributed all the chapters, but the theory of change is that Author, Chapter. "Chapter title". In Edited Volume will convey the correct impression?I don't have an alternative solution to propose, but I do note that the opposite problem – volume or even series editors being attributed authorship of chapters – is more common by at least an order of magnitude. Folly Mox (talk) 13:45, 13 December 2024 (UTC)
    >the theory of change is that Author, Chapter. "Chapter title". In Edited Volume will convey the correct impression?
    Yes, additionally, it seems that some styles already use this format. I first saw it in this journal article: https://www.tandfonline.com/doi/full/10.1080/09596410.2017.1401797 (paywalled) (Screenshot of the relevant citation) (link to the cited book).
    Looking further, I found that the APA Publication Manual (7th Edition) seems to follow this rule:

    Example 47. Entry in a dictionary, thesaurus, or encyclopedia, with group author
    American Psychological Association. (n.d.). Positive transference. In APA dictionary of psychology. Retrieved August 31, 2019, from https://dictionary.apa.org/positive-transference
    Merriam-Webster. (n.d.). Self-report. In Merriam-Webster.com dictionary. Retrieved July 12, 2019, from https://www.merriam-webster.com/dictionary/self-report

    This is made more explicit in other guides:
    1.
    >Chapter in a book
    >If there is no editor, include the word "In" before the book title. (link)
    2.
    >Chapters, Short Stories, Essays, or Articles From a Book (Anthology or Collection)
    > Note: If there is no editor given you may leave out that part of the citation.(link). This one is a bit ambiguous about what "that part of the citation" refers to. I don't think it includes "in."
    3.
    This academia.stackexchange post
    So the second reason is to be in line with other citation styles. However, I'm not an expert on citation style and I may be missing something. I found these links above by searching 'how to cite volume with "no editor"' on Google. J2UDY7r00CRjH (talk) 18:52, 13 December 2024 (UTC)
    I think I agree that In Edited Volume is clearer. I wonder if instead of a whole new set of |chapter-authorn= parameters and their attendant -link=s, -masks etc, an easier implementation might be a specific override value for |editor=, so if it has that value then In will appear before the book title (kinda like how |author-mask= will display text exactly as formatted, except numeric values which it displays as a string of dashes). Folly Mox (talk) 21:45, 13 December 2024 (UTC)
    An override value for the editor field would also work. Is there a standard value used for such cases? I think "editor=unknown" would work here. J2UDY7r00CRjH (talk) 23:21, 14 December 2024 (UTC)

    Omitting location parameter when implied by the publisher

    Presently, H:CS1 says The location parameter should be omitted when it is implied by the name of the work, e.g. The Sydney Morning Herald. Does this also apply to the name of the publisher, e.g. Cambridge University Press? I've only just realized I've been conflating the two. Remsense ‥ 论 19:29, 14 December 2024 (UTC)

    I don't think this advice is valid for publishers like CUP, OUP; they often publish in various locations. OTOH, it's probably trivial and doesn't matter. -- Michael Bednarek (talk) 08:54, 15 December 2024 (UTC)
    In my mind, omitting location would imply publication in the eponymous location. But yes, I'm thinking of how necessary the parameter even is in many situations. Remsense ‥ 论 08:59, 15 December 2024 (UTC)

    Citeref: if no year, use year from date

    Citeref is an html ID that is used to connect template:harv and template:sfn to cs1.

    Problem to be solved:

    An SQL search over linter errors of citerefs with the same id gives that around 280k do not have any number, so no year. It does make sense to look if the year can be fetched from elsewhere. CS1 alone makes 1.7 million out of 3.8 million duplicate IDs, so something has to be done, the status quo is not an feasible outcome.

    Expected breakages:

    https://en.wikipedia.org/search/?search=hastemplate%3A%22Cite+journal%22+hastemplate%3A%22Harvard+citation%22+insource%3A%2F%5C%7B%5C%7Bharvard+citation%5C%7C%5Ba-zA-Z%5C%7C%5D%2B%5C%7D%5C%7D%2F&title=Special:Search&profile=advanced&fulltext=1&ns0=1 shows that among the usages of cite journal and harv there is only one that does not have a number, Gordon Pask with its reference to Green, but that reference does not have an date, so it will not be affected by the change. Among the usages of cite journal and harv there are none with only page and not date, so nothing expected to break there. Overall, I do expect breakages, but that that they fix more duplicate ID's than they cause issues with harv. One could do an interim solution with both IDs showing up, causing no breakages for harv and sfn in the meantime.

    Solution:

    It does make sense to look for an year in date, when year is not given. An editor is not likely to duplicate the year when the date has already been given.

    Add the following to line 4115 of Module:Citation/CS1, keeping the line break that is there. 

    		if Year == nil or "" then
			Year = string.match(Date, "%d%d%d%d")
		end

    Snævar (talk) 15:00, 15 December 2024 (UTC)

    Having the same CITEREF in articles that do not use short form references is not an error that needs solving.
    The year in |date= is already used if it is part of the cite. However the example in Gordon Peak (CITEREFGreen) has no |date= parameter only |access-date= and |archive-date= neither of which would be appropriate to include in a short form reference. -- LCU ActivelyDisinterested «@» °∆t° 16:35, 15 December 2024 (UTC)
    (edit conflict)
    No. At Module:Citation/CS1 line 4114 is this:
    local year = first_set ({Year, anchor_year}, 2); -- Year first for legacy citations and for YMD dates that require disambiguation
    Normally, Year has been set to nil before this point in the code. anchor_year comes from Module:Citation/CS1/Date validation.
    This example has |date= but does not have |year=:
    {{cite book |title=Title |last=Greene |first=EB |date=15 December 2024}} → Greene, EB (15 December 2024). Title.
    '"`UNIQ--templatestyles-0000004B-QINU`"'<cite id="CITEREFGreene2024" class="citation book cs1">Greene, EB (15 December 2024). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2024-12-15&rft.aulast=Greene&rft.aufirst=EB&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
    Note the value assigned to the id= attribute in the <cite> tag; it has the year portion from |date=.
    If you know of cs1|2 templates that do not include the year portion from a publication-date parameter (|date=, |publication-date=, |year=) in the CITEREF anchor id, I'd like to see it.
    Editors do duplicate the year when the date has already been given; Category:CS1 maint: date and year wouldn't be needed else.
    It used to be that cs1 templates did not automagically create CITEREF anchor ids. Some time back, there was discussion:
    Editors in those discussions decided that all cs1|2 templates would create CITEREF anchor ids, needed or not; the automagic CITEREF anchor id can be suppressed with |ref=none. This linter thing is an artefact of that decision.
    —Trappist the monk (talk) 17:01, 15 December 2024 (UTC)
    Sounds like the problem is the linter. We already have Category:Harv and Sfn multiple-target errors (2) for where this is an actual issue. Folly Mox (talk) 12:37, 23 December 2024 (UTC)

    Using 'First' and 'last' over 'author' parameter

    Template:Citation states that |first= and |last= are preferred over |author=. I recently edited some citations accordingly and was reverted. Is there a reason |first= and |last= are preferred, or is this indeed a non-issue? Random86 (talk) 00:42, 16 December 2024 (UTC)

    Names are not universally consistent either in publishing or the world at large—given authors are generally identified primarily by surname, one can make a clear case for explicit specification. Remsense ‥ 论 00:47, 16 December 2024 (UTC)
    Also, separating them out is necessary if you want short footnotes ({{sfn}}) to link to the reference without a lot of extra hassle working around the lack of surnames. —David Eppstein (talk) 06:01, 16 December 2024 (UTC)
    Separate first/last names are generally better. As said above, {{sfn}} and the like work much better with last names. It also allows better web searching for a reference when the source website changes between using between "Dee Lightful", "D. Lightful" or "Lightful". However, sometimes it is hard for us English speakers to know which part of a non-English name is the family name and which is the personal name - eg, in Foo Ling Yu many Westerners don't realise that Foo is the family name (ie the last name in western terms, even though it is at the start of the name) and Ling-Yu is the personal part of her name (ie, the first name in western terms). There are also a few Western names that are hard (eg Douglas, Michael vs Michael, Douglas). Which is why the author field is allowed and does not produce errors - it is the ultimate fallback when you do not know the correct order. Which means that the reverter was quite wrong to revert you based on faulty logic.  Stepho  talk  08:01, 16 December 2024 (UTC)
    The parameters are perhaps misnamed as they really mean "given name" and "family name" regardless of name order, rather than first and last. But of course there are cultures (like say Iceland) where names don't work like that. —David Eppstein (talk) 08:25, 16 December 2024 (UTC)
    Well, what they really mean is "surname" and "not surname". Remsense ‥ 论 08:27, 16 December 2024 (UTC)
    Difficult to generalise: Saddam Hussein al Tikriti: 2nd name father's "forename", no family name, normal (not informal) single-word name Saddam. Federico del Sagrado Corazón de Jesús García Lorca; normal Spanish surname García, but known, unusually, by mother's surname Lorca. María-José Pérez de Gómez, known sometimes as M-J Pérez, others as Sra Gómez. Pol098 (talk) 11:58, 16 December 2024 (UTC)
    True. But if you look at the revert there were only 2 names changed (although multiple times each): "Benjamin, Jeff" and "Caulfield, Keith". Both English. Both already separated into surname, comma, given name. No complications. No non-English names. Also, they are displayed to the reader exactly the same but as separate fields they are much more suitable for computer processing. There was no reason whatsoever for the revert apart from WP:JUSTDONTLIKEIT.  Stepho  talk  04:45, 17 December 2024 (UTC)
    One can also use the aliases |given= and |surname= for these parameters. Kanguole 12:11, 16 December 2024 (UTC)
    Thank you. That's new to me and I will probably start using it.  Stepho  talk  04:45, 17 December 2024 (UTC)
    Unfortunately, Misplaced Pages:ProveIt presently undoes this. I should probably write a script that switches an article the other way, since the solution for automated RETAIN-vio is more automation, of course. Remsense ‥ 论 22:18, 17 December 2024 (UTC)
    ProveIt makes several changes to parameters, which it really shouldn't. One of the worst occurs when a reference has multiple authors – ProveIt renames the first one as |first= and |last= and moves the others later in the reference. (If Citation bot encounters these, it will change them to |first1= and |last1=, ready for ProveIt to "fix" them again.) It really should not be used on articles that already have consistent citations. Kanguole 22:28, 17 December 2024 (UTC)
    I mostly used it before for its consistent ordering and spacing, but now I mostly avoid it, and make sure to manually tweak where it violates RETAIN. Remsense ‥ 论 22:30, 17 December 2024 (UTC)

    Generic title

    Registered & Protected by MarkMonitor is a generic title string. -- GreenC 00:59, 19 December 2024 (UTC)

    Cite case causes CS1 errors

    {{Cite case}} maps |court= to |agency=, which is no longer supported by {{cite book}} -- see MKUltra#cite_note-107. This was brought up at Template talk:Cite case a few months ago by @DocWatson42 and @Isaidnoway, but I'm bringing it here since this is a better-watched talk page. Jay8g 04:24, 20 December 2024 (UTC)

    I remapped it to |series=, which renders in the same position in the citation. Hopefully no court cases are part of a series. Haven't checked all 52 transclusions, but none of the dozen or so I checked are in Category:Pages using duplicate arguments in template calls, so it seems fine. No documentation at this template. Folly Mox (talk) 17:04, 21 December 2024 (UTC)

    Placement of "translator"/"page" fields

    Greetings and felicitations. When "translator" and "page" fields are used together in "Cite journal", it results in this:

    ISTM that the "translator" field should be followed by a period, or be placed before the volume/issue number fields, or after the pages field. —DocWatson42 (talk) 05:48, 20 December 2024 (UTC)

    Yeah, a known flaw but a pain to fix. If we really need to fix it, we should revisit the placement of all rendered parameters. As it is now, the code that orders the cs1|2 template parameters is ugly and confusing.
    For this particular case, if one follows the doi link to the publisher's website, Oxford Academic identifies "Takahashi Macoto: The Origin of Shōjo Manga Style" as a chapter in the book Mechademia 7: Lines of Sight. It would seem then that {{cite book}} would be the appropriate template. I don't have access to the source, but Oxford Academic's recommended citation does not include Rachel Thorn (with an 'N'). The recommended citation lists a co-author(?) 'Matt Thorm' (with an 'M'). So, perhaps the correct template looks like this (without |translator=):
    {{Cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}}
    Fujimoto, Yukari; Thorm, Matt (2012). "Takahashi Macoto: The Origin of Shōjo Manga Style". In Lunning, Frenchy (ed.). Mechademia 7: Lines of Sight. pp. 24–55. doi:10.5749/minnesota/9780816680498.003.0002. ISBN 978-0-8166-8049-8.
    or with |translator=:
    {{Cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |translator=] |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}}
    Fujimoto, Yukari; Thorm, Matt (2012). "Takahashi Macoto: The Origin of Shōjo Manga Style". In Lunning, Frenchy (ed.). Mechademia 7: Lines of Sight. Translated by Thorn, Rachel. pp. 24–55. doi:10.5749/minnesota/9780816680498.003.0002. ISBN 978-0-8166-8049-8.
    —Trappist the monk (talk) 16:44, 20 December 2024 (UTC)
    I don't have time right now to reply in full, but Mechademia is a journal in the form of a book, and the correct spelling of the particular author's name is Matt Thorn. —DocWatson42 (talk) 20:14, 20 December 2024 (UTC)

    module suite update 28–29 December 2024

    I propose to update the cs1|2 module suite over the weekend 28–29 December 2024. Here are the changes:

    Module:Citation/CS1:

    Module:Citation/CS1/Configuration:

    • update emoji zwj table to Unicode v16.0; nothing changed except version and date;
    • add script lang codes 'az', 'chr', 'zgh';
    • add free DOI registrants 10.18637 – Foundation for Open Access Statistic, 10.1016/j.proche – Procedia Chemistry
    • convert Category:CS1 maint: unfit URL to properties cat Category:CS1: unfit URL
    • relax 'HugeDomains' generic title search; discussion

    Module:Citation/CS1/Identifiers:

    Module:Citation/CS1/Utilities:

    —Trappist the monk (talk) 01:57, 21 December 2024 (UTC)

    I don't have an opinion on most of these but am very happy to see the hyphen-to-dash fix. Thanks! —David Eppstein (talk) 06:01, 21 December 2024 (UTC)
    Instead of Category:CS1: unfit URL could it be Category:CS1: usurped URL - it is the majority by about 3:1: unfit 11,000, usurped 46,000. The usurped will grow indef due to WP:JUDI. -- GreenC 06:21, 21 December 2024 (UTC)
    Makes sense just to reparent the existing cat: usurped is a subtype of unfit. Thanks for all your work, Trappist. Folly Mox (talk) 16:46, 21 December 2024 (UTC)
    Just so I understand what you are saying: You think that |url-status=unfit should categorize to Category:CS1: unfit URL and |url-status=usurped should categorize to Category:CS1: usurped URL where the latter is a sub-category of the former? Do we really need two categories?
    —Trappist the monk (talk) 19:10, 21 December 2024 (UTC)

    Another generic title: "Conference Paper"

    See Special:Diff/1264743625 —David Eppstein (talk) 05:32, 24 December 2024 (UTC)

    Categories: