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 09:28, 17 August 2021 editHeadbomb (talk | contribs)Edit filter managers, Autopatrolled, Extended confirmed users, Page movers, File movers, New page reviewers, Pending changes reviewers, Rollbackers, Template editors454,750 edits →bad DOI check: +~~~~← Previous edit Latest revision as of 02:40, 17 January 2025 edit undoClueBot III (talk | contribs)Bots1,383,235 editsm Archiving 2 discussions to Help talk:Citation Style 1/Archive 97. (BOT) 
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}} -->{{skip to bottom}}<!--
{{talk header|display_title=Help: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 templates and modules redirect here. A list of those talk pages and their historical archives can be found ].}} {{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|collapsed=yes|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 11: 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={{Automatic archive navigator}} |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| {{Banner holder|collapsed=yes|
Line 27: Line 27:
*"'''Withdrawn'''" proposal to merge ] with ] on March 2, 2018, see ]. *"'''Withdrawn'''" proposal to merge ] with ] on March 2, 2018, see ].
}} }}
{{copied|collapse=yes
|from1=Template:Cite_book |from_oldid1=810449908 |to1=:incubator:Template:Wp/nod/cite_book |to_diff1=4307029
|from2=Template:Cite_journal |from_oldid2=690395473 |to2=:incubator:Template:Wp/nod/cite_journal |to_diff2=4333078
|from3=Template:Cite_web |from_oldid3=753103437 |to3=:incubator:Template:Wp/nod/cite_web |to_diff3=4307058
|from4=Module:Citation/CS1 |from_oldid4=967170285|to4=:incubator:Module:Wp/nod/Citation/CS1|to_diff4=4914098
|from5=Module:Citation/CS1/Configuration |from_oldid5=967154995|to5=:incubator:Module:Wp/nod/Citation/CS1/Configuration|to_diff5=4914022
|from6=Module:Citation/CS1/Suggestions |from_oldid6=777797913 |to6=:incubator:Module:Wp/nod/Citation/CS1/Suggestions |to_diff6=4307056
|from8=Module:Citation/CS1/Whitelist |from_oldid8=967154988|to8=:incubator:Module:Wp/nod/Citation/CS1/Whitelist|to_diff8=4914043
|from9=Module:Citation/CS1/styles.css |from_oldid9=951705291|to9=:incubator:Module:Wp/nod/Citation/CS1/styles.css|to_diff9=4913948
|from7=Module:Citation/CS1/Utilities |from_oldid7=935243617|to7=:incubator:Module:Wp/nod/Citation/CS1/Utilities|to_diff7=4914061
}} }}
{{FAQ|page=Help talk:Citation Style 1/FAQ}}
}}
{{Auto archiving notice |bot=ClueBot III |age=30 |units=days |small=yes}}
{{Multiple image
| align = right
| 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
}}
__TOC__

== Current version of page no longer contains cited facts. url-status=? ==


{{old move|date=4 January 2025|destination=Template:cite audiovisual media|result=not moved|link=Special:Permalink/1268767549#Requested move 4 January 2025}}
It seems to me that there {{para|url-status}} needs another option, for a webpage which is live and has not been usurped, but where the current version no longer contains the cited info.


== Internet archive print disability book links ==
I have been archiving the refs on the article ] (an Irish politician), and the page http://www.paulgogarty.com/about/ was cited in 2009 as a ref for the assertion that he {{tq|joined the Green Party in 1989 as a student|q=y}}. That current live age doesn't say that, because Gogarty left the Green party 10 years ago, and has been an independent since 2011. So his biog page now focuses more on his status as an independent.


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."
However, the relevant facts are in an archived version of the page, from 2009: https://web.archive.org/web/20151229222337/http://www.paulgogarty.com/about/


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)
I was unsure what value to give for {{para|url-status}}. None of the options was a good fit:
# {{para|url-status|live}} makes the current version the primary link, which is not helpful
# {{para|url-status|usurped}} would be untrue, because the domain has not been usurped
# {{para|url-status|unfit}} initially seemed like the best option, but it does not link the original URL, which seems unhelpful
# {{para|url-status|dead}} isn't strictly true, because the original page is still live ... but this option ''does'' link the original URL


:Alternatively (as with {{tlx|Hopcroft and Ullman 1979}}) should the link be appended to a reference a note? ] (]) 01:33, 29 November 2024 (UTC)
So in this edit I used {{para|url-status|dead}} as the least-worst option.
::{{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)
:::::::Thank you for the clarification. Given that the current possibilities are:
:::::::* registration = 'Free registration required'
:::::::* limited = 'Free access subject to limited trial, subscription normally required'
:::::::* subscription = 'Paid subscription required'
:::::::do you think it would be unreasonable to collapse the tertiary possibilities discussed (e.g., search access only, some pages browsable, special permissions) into a fourth parameter:
:::::::* partial = 'Partial access, not fully readable' (or something)
:::::::The motivation for the parameter is the same as the other 3, with no more or less difficulty in implementation. In particular, it is to emphasize that the URL supplied is not "full access", in one way or another. ] (]) 00:21, 5 January 2025 (UTC)
::::::::If the proposed fourth parameter is not reasonable, I will collapse the use of {{tlx|IAp}} to a simple <code>|url=</code> with no indicator. As a reader, I would find an indicator an appreciated convenience, but I don't see another solution. ] (]) 00:22, 5 January 2025 (UTC)


== DOI prefix limits should be bumped. ==
However, it would be better to have some option which more accurately describes the situation. Maybe {{para|url-status|rewritten}} or {{para|url-status|revised}}?


It seems to me that this situation is not uncommon, so there should be an option which supports it. --] <small>] • (])</small> 06:03, 17 June 2021 (UTC) 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)
: Seconding this! —&#8288;]<sup>] ]</sup> 22:10, 17 December 2024 (UTC)
: This is indeed a common situation, e.g. in websites of scientific organisations. A {{para|url-status|revised}} (or {{para|url-status|updated}} or {{para|url-status|changed}}) as short for ''changed and no longer containing the cited information'' and linking to an archived version would be more informative than shoe-horning {{para|url-status|dead}}. —&nbsp;<span style="font-family:Arial;background:#d6ffe6;border:solid 1px;border-radius:5px;box-shadow:darkcyan 0px 1px 1px;">&nbsp;]&nbsp;&#124;]&nbsp;</span> 07:53, 17 June 2021 (UTC)
: I support the idea, but we should try and find a keyword which cannot be misunderstood. "changed", "updated", "revised" or even "rewritten" could mean all kinds of changes to the page, including those which are still supporting the statement and for which we would ''not'' want to swap the {{para|url}} and {{para|archive-url}} links. Perhaps {{para|url-status|outdated}} would transport that message? --] (]) 12:08, 17 June 2021 (UTC)
:: Thinking about alternative keywords properly describing the situation, {{para|url-status|outdated}}, {{para|url-status|substituted}}, {{para|url-status|replaced}}, and {{para|url-status|archived}} came to my mind so far. Perhaps <code>archived</code> would be the most universal one as it does not make a statement in regard to the potentially changed contents of the live site and its validity, just that an archived snapshot exists (and therefore can be linked to if the editor wants to). Codewise, this would be treated as an alias to <code>dead</code> for now.
:: --] (]) 19:15, 6 July 2021 (UTC)
:::BrownHairedGirl's example could thus look like:
:::<code><nowiki>Gogarty joined the Green Party in 1989 as a student.<ref>{{cite web |title=Profile of Paul Gogarty TD |work=Paul Gogarty's website |access-date=2009-06-19 |url=http://www.paulgogarty.com/index.php/about/ |url-status=archived |archive-url=https://web.archive.org/web/20151229222337/http://www.paulgogarty.com/about/ |archive-date=2015-12-29}}</ref></nowiki></code>
:::: {{cite web/new |title=Profile of Paul Gogarty TD |work=Paul Gogarty's website |access-date=2009-06-19 |url=http://www.paulgogarty.com/index.php/about/ |url-status=archived |archive-url=https://web.archive.org/web/20151229222337/http://www.paulgogarty.com/about/ |archive-date=2015-12-29}}
:::--] (]) 15:09, 7 July 2021 (UTC)
::::I'm not convinced that {{para|url-status|archived}} is all that meaningful. Looking at the wikitext of your example template, a generic editor might think, "of course its archived, it has {{para|archive-url}} ..." If this new keyword (presuming that we can find one), is to convey the meaning that the original url no longer supports our article's text, then that keyword should be sufficiently descriptive to convey that meaning. {{para|url-status|archived}} doesn't do it for me.
::::
::::As an aside, I am going to delete my {{para|url-status|blacklisted}} changes because they won't work; your change will be swept away by that revert.
::::—] (]) 17:26, 7 July 2021 (UTC)
::::: Well, I thought that perhaps ''not'' conveying that meaning would be a good thing here, but I see the point. What about {{para|url-status|diverging/diverged}}, {{para|url-status|deviating/deviated}}, {{para|url-status|differing/differed/different}} or {{para|url-status|drifted}}?
::::: --] (]) 17:49, 7 July 2021 (UTC)
:::::If this really is a good idea, and I remain skeptical, {{para|url-status|archive-verified}}. It's not going to be intuitive regardless, and we're probably not going to be able to find a single word to do what you want. ] (]) 18:15, 7 July 2021 (UTC)
::::: I guess, {{para|url-status|invalid}} would be too close to {{para|url-status|unfit}} and imply either gross or corrupt contents or an error, but {{para|url-status|invalidated}} would convey the message that there once actually was ''valid'' contents (as verifiable by the archived snapshot - somewhat in line with Izno's <code>archive-verified</code> above), that there was a ''change'' in contents, and that the current one isn't ''good'' any more, but still not dead, or unfit, or usurped... Perhaps ], ], or ] have ideas for even better keywords?
::::: --] (]) 18:51, 7 July 2021 (UTC)
:::::: Unfortunately, I have no better suggestion. I struggled to find something pithy for ''content changed and no longer containing the cited information'' and {{para|url-status|revised/updated/changed}}) were the best one word options I could think of. Izno's {{para|url-status|archive-verified}} conveys the right message that the content was verifiable and can still be checked in the archive. —&nbsp;<span style="font-family:Arial;background:#d6ffe6;border:solid 1px;border-radius:5px;box-shadow:darkcyan 0px 1px 1px;">&nbsp;]&nbsp;&#124;]&nbsp;</span> 09:01, 8 July 2021 (UTC)
::::::: We should try hard to find a suitable one-word keyword. I mean, <code>live</code>, <code>dead</code>, <code>unfit</code> and <code>usurped</code> ''also'' do not convey ''all'' implied meanings associated with them, but they come close enough to be memorizable.
::::::: Unfortunately, <code>archive-verified</code> is too long IMO, and, while true, it is also a bit too much on the policy side - I mean, we do not necessarily need to explicitly state in the keyword that the contents is verified (verifiable from the archive), because that's what ] need to be in the first place. What's more important to convey is that the live contents has ''changed'' and ''deviates'' from the former contents which supported the statement.
::::::: {{para|url-status|revised/updated/changed}} would be nice short keywords to reflect the change in general, but they miss a notion of the original information not being supported any more. {{para|url-status|substituted/replaced/reworked}} do convey that message better, but are perhaps a bit too close to {{para|url-status|usurped}} already, after all, substitution or replacement could also indicate a site holding completely new information rather than a page that is still rooted in the original one, but has changed enough (just) to no longer support the statement. IMO, {{para|url-status|diverged}} or {{para|url-status|deviated}} transports that message quite well. {{para|url-status|invalidated}} could do it as well (and even has a notion of former validation/verifiability), but is closer to {{para|url-status|unfit}} already. None of them implies the existence of an archived snapshot, but the existing keywords don't do that as well, so this is not necessarily a bad thing. If we would want to put the emphasis on the availabilty of an archive rather than the reasons for why it might be necessary to refer to it, {{para|url-status|archived}} could be a suitable purely descriptive option as well. Finally, here is another one which (only indirectly) implies change and a need to recover the original information, but also has aspects of information being archived and verified: {{para|url-status|retrievable}}.
::::::: --] (]) 13:22, 8 July 2021 (UTC)
::::::: See also:
:::::::* ]
:::::::* ]
:::::::* ]
:::::::* ]
::::::: Maybe ] has ideas for other suitable keywords?
::::::: --] (]) 11:04, 12 July 2021 (UTC) (updated 09:34, 13 August 2021 (UTC))
::::::We could, perhaps, coin a term {{para|url-status|ex-valid}} or {{para|url-status|ex-support}} where the <code>ex-</code> prefix denotes 'former' as in 'ex-president'. Assuming that we settle on some appropriate keyword, what does the module do with that keyword? Render same as {{para|url-status|dead}}? Render same as {{para|url-status|unfit}} (no original link)? Something else?
::::::—] (]) 11:39, 12 July 2021 (UTC)
:::::::Thanks for pinging me, Matthiaspaul. And thanks for raising this again, BrownHairedGirl, since I got no traction back in February.
:::::::What about {{para|url-status|historical}}?
:::::::Trappist, I think it should render same as {{para|url-status|dead}}. ] (]) 04:55, 13 July 2021 (UTC)
:::::::: Yeah, I too think it should render the same as {{para|url-status|dead}}.
:::::::: More ideas: {{para|url-status|descended/inherited/ancestral/supplanted/superseded}}?
:::::::: --] (]) 11:11, 16 July 2021 (UTC)
:::::::::I don't know anything about the coding or program logic, but I wonder whether we don't really need a significant change to the logic. Would it be feasible to create an alias for {{para|url-status|dead}} called {{para|url-status|historical}} and an alias for {{para|url-status|live}} called {{para|url-status|current}}, with a view to eventually deprecating "live" and "dead"? Or something like that? ] (]) 05:15, 20 July 2021 (UTC)
:::::::::: It is trivial to add such aliases. As far as the proposals go, there would be no changes to the program logic needed to implement them (as I already demonstrated when I temporarily implemented the <code>archived</code> keyword in the sandbox for illustration purposes, which, however, was reverted by Trappist and Izno).
:::::::::: Regarding the proposed keyword <code>historical</code>, I first thought this would be a good match, but later it occured to me that {{para|url-status|historical}} could also be interpreted to mean just the opposite of what we want to express, as if the current page at the URL would be the historical one.
:::::::::: Regarding the proposed keyword <code>current</code> and from what you wrote about deprecating <code>dead</code>, I take it that you want to replace the currently assigned keyword(s) by (presumably) better one(s). This would be different from the original proposal where we were/are seeking for a keyword to define a separate new state for {{para|url-status}} which just happens to render the same (at least at present) as what we do for {{para|url-status|dead}}. However, a dead URL is an URL for which your browser would not get any response at all any more when queried, whereas when querying an outdated/deviated/superseded page you would still get contents, even sensible contents, which can be seen as a continuation of the original contents, but just changed in ways so that its contents no longer supports the article any more.
:::::::::: --] (]) 09:14, 20 July 2021 (UTC)
:::::::::: Considering all proposed keywords for this new state so far, I find {{para|url-status|deviated}} to be the most suitable one. It is reasonably short, a single keyword, and it implies something that is still live and not usurped, but changed enough from something that was once found good enough to support the article, but not changed drastically enough to be unfit for presentation. If there are no objections or better suggestions, I will implement that.
:::::::::: --] (]) 23:13, 29 July 2021 (UTC)
::::::::::: <code><nowiki>{{cite web |title=Profile of Paul Gogarty TD |work=Paul Gogarty's website |access-date=2009-06-19 |url=http://www.paulgogarty.com/index.php/about/ |url-status=deviated |archive-url=https://web.archive.org/web/20151229222337/http://www.paulgogarty.com/about/ |archive-date=2015-12-29}}</nowiki></code>
:::::::::::: {{cite web/new |title=Profile of Paul Gogarty TD |work=Paul Gogarty's website |access-date=2009-06-19 |url=http://www.paulgogarty.com/index.php/about/ |url-status=deviated |archive-url=https://web.archive.org/web/20151229222337/http://www.paulgogarty.com/about/ |archive-date=2015-12-29}}
::::::::::: Done.
::::::::::: --] (]) 00:03, 31 July 2021 (UTC)
: No, I do not think adding content-related options to the parameter is the way to go.
: Assuming the information removed from the source is still correct and pertinent, and there is a reliable archive available, I would cite the archive directly (using {{tl|cite web}} in this case) and so avoid the {{para|url-status}} situation.
: The '''url-status''' parameter is an editor utility parameter regarding the url ... status. It is named so. It is there to signal editors the reason a certain link cannot/should not be used. It makes no assumptions about the link's content. If the pertinent information is not there then there are verifiability, not citation, issues. If however there is an archive, see the previous paragraph. ] (]) 12:28, 17 June 2021 (UTC)
:: Hm, if I have to cite an archived version of some former site because the original site no longer exists or has changed in unsuitable ways, the proper way to do so is still to add the archive link to {{para|archive-url}}, extract the original link from it for {{para|url}} and set {{para|url-status}} so that the two links are swapped. I would typically use the keyword "dead" for it, but as others have stated already, this isn't exactly intuitive and might even be misleading at times. Adding the archived version to {{para|url}} will, in most cases, cause some bot to fix up the citation later on.
:: Yeah, I agree that {{para|url-status}} has a utility value for editors, that's exactly why it should have a well-defined set of non-misleading keywords to cover all practical cases, even if some of them would be handled the same by the software internally. --] (]) 13:06, 17 June 2021 (UTC)
::: Why should a bot mess with a perfectly good citation? Whether an archive is cited or the original is, it makes no difference as long as the wikitext is verified. There is also the issue of simplicity.
::: Citations have no business defining the content in any way. If the information is not there, there are other options, as shown. People should not expect a citation template, or any citation no matter how formatted, to address content issues. If it is not there, it should not be cited, period. Find another source where the information exists. Archive links are convenience links so editors won't have to reformat the entire citation if the original link (not its content) is inaccessible for any reason. In some cases though, the citation must be reformatted, rewritten, or removed. ] (]) 13:43, 17 June 2021 (UTC)
::::An archived copy is not a "perfectly good citation" in and of itself, since it is presumed that the archive is of a different URL which once contained reliable information. The archiving site itself isn't a source. So with that in mind, it's crucial to maintain information about what the original URL was that established the reliable website source. That is done via the URL parameter, with the archived copy linked through archive-url. The url-status then exists to tell us in what state the original URL is now, and in particular whether a user seeking the info should go to the source or the archive. I agree with the OP that having an "information no longer there" option would be good, although in terms of how the cite formats itself this will probably end up similar to "dead". &nbsp;&mdash;&nbsp;] (]) 13:59, 17 June 2021 (UTC)
:::::Not so at all. Any source that verifies the wikitext is a perfectly good source for a citation. A reliable archive is a source like any other ("reliable archive" meaning one that is known to faithfully reproduce the original). It is not at all crucial to maintain information about a previous location (the "original" URL). It is necessary to include information about the location that currently verifies the wikitext (including a current URL if it exists - whether pointing to an archive or not is immaterial). Citations are not historical information, nor are they future statements. They must prove the wikitext now. If they don't, they cite nothing. ] (]) 19:37, 17 June 2021 (UTC)
::::::{{yo|65.88.88.69}} I strongly disagree with the statement that {{tq|Citations are not historical information, nor are they future statements|q=y}}.
::::::The role of a citation is to allow readers to verify the information cited. Part of that task is to note issues in verifiability, which is why for example with a dead link we include both the live archive link and the original dead link. That helps readers to verify the citation. I see no reason to impede that verifiability for any of the situations discussed.
::::::I agree with {{u|Amakuru}}'s observation that {{tq|in terms of how the cite formats itself this will probably end up similar to "dead"|q=y}}. My goal is to assist editors by providing a more explicit label to achieve that. --] <small>] • (])</small> 09:53, 20 June 2021 (UTC)
:::::::{{ping|BrownHairedGirl}} quite so. A citation without evidence that the thing being cited is reliable is useless. And as much as we've made the decision to trust sites like archive.org top maintain a historical record of what a reliable source once said, the presence or absence of that original source is still a matter of profound interest. In some cases, visiting the newly-updated version of the source might provide evidence to a reader or an editor that the information cited is actually not correct any more. &nbsp;&mdash;&nbsp;] (]) 10:35, 20 June 2021 (UTC)
::::::::Indeed, @{{u|Amakauru}}. It is not hard to conceive of ways in which the archive sites could be compromised or games, or even become corrupt ... so we should facilitate those who want to conduct their own verification.
::::::::And there are many ways in which the current version of the page could be relevant, one of which is the example you give of the information being outdated. --] <small>] • (])</small> 10:42, 20 June 2021 (UTC)
:::::::::Does everybody understand that the parameter in question is only an indicator about the state of the link. Nothing else belongs there, so please don't try to shoehorn extraneous stuff into it. If the verifying info is not there, a link is useless. To the reader trying to verify whatever is written in wikitext, prior or future iterations of the citation are also useless. To turn wikitext fiction into fact, a citation must (continuously) verify now. Notice that any article-space page does not carry information about previous versions of the article. If a reader cares, they can consult the history for previous iterations, including those of the citations. The source's underlying reliability is another issue, one that should be resolved prior to formatting of citations, and is a different discussion. ] (]) 12:38, 20 June 2021 (UTC)
:We've discussed this one before, though I would not know what to search for. I think the correct way to cite such a case today, and I remember arguing the same then, would be simply setting to dead. The original source is effectively dead for the purposes of the citation, even if the site is still available. If you are dead set on including both that citation and information, you should add an archive URL, set to dead, add a wikitext comment about why you set to dead, and move on. The reason I add the latter two caveats is due to ]/]/]. If the source is not independent, one should question whether it's appropriate to use that source and whether it is appropriate to include that information. If it is so important as to be clearly an NPOV piece of information, then one still needs to meet the bar associated with BLP (in this case). ] (]) 13:48, 17 June 2021 (UTC)
: :
:If that is true, why (as I write this) is {{cl|CS1 errors: DOI}} empty?
:If we are going to consider additional keywords, perhaps <code>blacklisted</code> (or the politically correct term du jour) might be one to add. When {{para|url}} has a blacklisted url, the blacklist prevents saving of the article. To get round that, editors add an {{para|archive-url}} and either comment out, remove, or otherwise break the value in {{para|url}} so that the page will save. This gives a link to a snapshot of the source but also creates {{error-small|{{para|archive-url|plain=yes}} requires {{para|url|plain=yes}}}} errors. {{para|url-status|blacklisted}} would allow {{para|url}} to be blank (commented) or missing; ] would not emit error messages but would emit a maintenance category.
::<syntaxhighlight lang="wikitext" inline="1">{{PAGESINCATEGORY:CS1 errors: DOI}}</syntaxhighlight> → {{PAGESINCATEGORY:CS1 errors: DOI}}
:—] (]) 14:04, 17 June 2021 (UTC)
:—] (]) 22:47, 17 December 2024 (UTC)
::The point is that the keywords indicated in the OP are not link (URL)-related, so they are outside the scope of a URL's status. "Blacklisted" passes the test, per your discussion fork above. In general and as you know, citations point to sources, they don't make statements about their content. That can be a subject of a footnote (if necessary) perhaps with its own citation track. ] (]) 19:55, 17 June 2021 (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)
:::{{yo|65.88.88.69}} I strongly disagree. "URl no longer contains the cited information which it previously contained" (or some short form thereof) is very much a matter of the URI's s status.
:Fixed in sandbox:
:::Citations do indeed point to sources, and part of that task is to note issues wrt verifiability. --] <small>] • (])</small> 09:44, 20 June 2021 (UTC)
<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>
::::URIs are identifiers. They make no statements regarding the item they identify. Either the identification is correct (item exists) or is not. Let's not try to redefine a URI's function. It seems that there is a confusion regarding verifiability. Citations that resolve to existing sources by definition explicitly verify whatever is claimed in wikitext. If they don't, they are invalid, and should be removed. The reasons for the invalidation are not pertinent; the reader wants to see a valid citation, not explanations of why a citation is not currently valid. As was said earlier, if editors want to keep the wikitext they should find another source. ] (]) 13:10, 20 June 2021 (UTC)
:—] (]) 20:06, 19 December 2024 (UTC)
::<s>I have hacked the module suite to accept {{para|url-status|blacklisted}}.</s>
::Thank you! After this goes live, we could update the articles in ]. ] (]) 17:31, 26 December 2024 (UTC)
<div style="margin-left:4.8em">{{Cite compare |mode=web |title=Title |website=Boomerocity.com |url=<!-- blacklisted_url.com --> |archive-url=archive.org |archive-date=2021-07-06 |access-date=2021-07-06 |url-status=blacklisted}}</div>
:::I reviewed each article in ] and removed the temporary error hiding for the 10.7#### DOIs that were kindly added by users such as {{U|Metamd}}, {{U|AManWithNoPlan}} and {{U|Snowman304}}. ] (]) 20:55, 2 January 2025 (UTC)
::<s>and when used with {{tlx|cite book}} for {{para|chapter-url}}. In this example, {{para|chapter-url|<nowiki><!-- blacklisted https://www(dot)boomerocity(dot)com/moonbeam-parade(dot)html blacklisted --></nowiki>}} (where (dot) is a dot):</s>
<div style="margin-left:4.8em">{{Cite compare |mode=book |chapter=Chapter |title=Title |url=<!-- blacklisted_url.com --> |archive-url=archive.org |archive-date=2021-07-06 |access-date=2021-07-06 |url-status=blacklisted}}</div>
::<s>In this second example, because the module does not receive {{para|chapter-url}} it cannot know to apply {{para|archive-url}} to {{para|chapter}}.</s>
::
::<s>This scheme may not work all the time. It's unclear to me when the blacklister steps in and prevents saving of a page with a blacklisted url. For example, I was able to save my sandbox that has actual blacklisted urls commented out (taken from ]) but I am unable to save the same thing here.</s>
::—] (]) <s>16:10, 6 July 2021 (UTC)</s> 13:07, 8 July 2021 (UTC) {{small|(strikeout)}}
:::In your examples did you you omit the protocol (URI scheme) intentionally? (As it returns errors). Also, is it possible for the blacklisted url to be commented out by a routine? If it is too hard I guess it can always be done by hand.
<div style="margin-left:4.8em">{{Cite compare |mode=web |title=Title |website=BlacklistedWebsite.com |url=http://blacklisted_url.com|archive-url=http://archive.org |archive-date=2021-07-06 |access-date=2021-07-06 |url-status=blacklisted}}</div>
:::Any ideas about adding an '''archive-url-status''' param? ] (]) 19:07, 6 July 2021 (UTC)
::::{{ec}}
::::Not intentional and fixed. It is likely that I will revert this change because the regex that is the blacklister looks for anything following <code>http://</code> or <code>https://</code> until the line item found in ]; see ]. So for the boomerocity.com archive url ], <code><nowiki>https://web.archive.org/web/20200122204730/https://boomerocity(dot)com</nowiki></code> will match <code><nowiki>/https?:\/\/*\bboomerocity\.com\b/Si</nowiki></code>.
::::
::::As far as I know, no one has made a case for {{para|archive-url-status}}.
::::—] (]) 19:41, 6 July 2021 (UTC)
::::I suppose I was asking whether something like this is feasible:
:::::<code><nowiki>{{Cite web |title=Title |website=BlacklistedWebsite.com |url=http://blacklisted_url.com|archive-url=http://blacklisted_url.com-some_archive.org |archive-date=2021-07-06 |access-date=2021-07-06 |url-status=blacklisted|archive-url-status=blacklisted}}</nowiki></code>
:::::to be auto-formatted as
:::::<code><nowiki>{{Cite web |title=Title |website=BlacklistedWebsite.com |url=<!--http://blacklisted_url.com-->|archive-url=<!--http://blacklisted_url.com-some_archive.org--> |archive-date=2021-07-06 |access-date=2021-07-06 |url-status=blacklisted|archive-url-status=blacklisted}}</nowiki></code>
::::] (]) 19:30, 6 July 2021 (UTC)
:::::If I understand what you are saying, then the answer is: no. Modules and templates cannot modify and save wikitext.
:::::—] (]) 19:43, 6 July 2021 (UTC)
::::::Right. I was thinking about something similar to the way {{para|url|{{var|original-url.com}}}} is auto-formatted when {{para|url-status|{{var|dead}}}}, for example, to {{para|url|{{var|archived-url.com}}}} (and the static text too). ] (]) 20:19, 6 July 2021 (UTC)
:::Blacklisted change has been reverted because it will not work properly.
:::—] (]) 13:07, 8 July 2021 (UTC)
::: See also: ] --] (]) 09:34, 13 August 2021 (UTC)


== Replacing "--" by "–"... == == Placement of "translator"/"page" fields ==
Greetings and felicitations. When "translator" and "page" fields are used together in "Cite journal", it results in this:


* {{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}}
Hi, this is a followup to a recent but meanwhile archived discussion at ], which was about converting double-hyphens and triple-hyphens in page ranges to en dashes and em dashes.


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)
I originally implemented that on 2020-11-17 based on some suggestion that double-hyphens could occur in BibTeX entries and thereby could end up here as well occasionally. Unfortunately, I introduced a bug into the code trashing stripmarkers ("never do any last-minute changes after having already tested the code..." ;-) and because I could not locate the original discussion any more, it was removed rather than fixed. Well, I still haven't found the original discussion, so it probably wasn't here, but I just ran into a site (by renowned Nelson H. F. Beebe) excessively using double-hyphens in (hundreds of) BibTeX citations, so I thought I would drop a link here just for reference:
: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 {{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}}):
::<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 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}}
:or with {{para|translator}}:
::<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>
:::{{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}}
:—] (]) 16:44, 20 December 2024 (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)
::I know this is pretty stale (and evidently a pain to fix), but I'd support the eventual, non-urgent relocation of the {{para|translator-''n''*}} parameters to render immediately following {{para|chapter}} / {{para|entry}} if available, or immediately following {{para|title}} otherwise.{{pb}}As someone who has previously worked in translation, I can affirm that there is a reason why publishers may recommend the translator be attributed as coauthor. Unless machine translation is used as a jumping off point, translation is a significant and very personal contribution; it makes sense to credit close to the title. No rush though. ] (]) 17:15, 5 January 2025 (UTC)
:::That sounds good (logical) to me. And I hope the overhaul of parameters happens sooner rather than later. —] (]) 22:21, 6 January 2025 (UTC)


== module suite update 28–29 December 2024 ==
http://ftp.math.utah.edu/pub/tex/bib/bstj1930.html


I propose to update the cs1|2 module suite over the weekend 28–29 December 2024. Here are the changes:
Since we are doing all kinds of plausibility checks and also some on-the-fly conversions (including with pages and page ranges), I still think we should cover this case. After all, a double-hyphen in a page range can never be part of the page designation itself and the only reasonable interpretation is as an endash in a page range. The alternative to just silently converting them to improve our display and make our metadata output more consistent would be to throw a maintenance message, but this would require more code.
--] (]) 12:46, 17 June 2021 (UTC)
:Searches:
::<code>--</code> (times out)
::<code>---</code>
:—] (]) 12:59, 17 June 2021 (UTC)
::Not sure why you escaped the dashes, but .
::I do not see a need for this change. There are sufficiently few and clearly not many being introduced that the interested user can just work from a search. ] (]) 13:51, 17 June 2021 (UTC)
:::In fact, I can refine this to
:::* ,
:::* ,
:::*
:::Still don't think we need it. ] (]) 14:23, 17 June 2021 (UTC)
:::: I, on the contrary, don't see how it could cause any harm. It would improve consistency in how citations are displayed and metadata is generated. Using two consecutive hyphens for an endash was a common notation in pre-Unicode times and many people are still accustomed to it. While we support Unicode and therefore do not technically ''need'' this any more, in general it is still a good idea to maintain compatibility with ASCII conventions for as long as they don't step in the way of more modern conventions. En dashes are still difficult to type in many keyboard layouts and visually almost impossible to distingish from a hyphen in many fonts. So, while they are technically the correct thing to use, they are not convenient to use. Why not let the templates do the translation for the editors' convenience? After all, we already translate a variety of other special character "transliterations" on the fly, so this would not be anything new. Alternatively we could have someone looking for these strings every once in a while and fix them in citations, but this is a never-ending endeavour, and we would continue to generate strange looking citations and metadata until fixed.
:::: Alternatively, we could detect the pattern and issue an error message in order to ''force'' editors to use en dashes. However, this would require more code than to just translate this on the fly, so if code complexity would be the issue, an on-the-fly translation would be the preferable solution. --] (]) 14:41, 19 July 2021 (UTC)
:::: ] asks us to avoid double and triple dashes. MOS is generally about the visible output, not necessarily about parameter input on source code level, but what we can draw from this is that we should not have "--" or "---" showing up in rendered citations and metadata (well, unless the metadata standard would require en/em dashes to be transliterated this way, which COinS, however, does not). So, we should either accept them on source code level and convert them on the fly for proper output as "–" or "—", or, since they can never be a valid part of a single page designation, we should check for this condition (similar to our various extra text checks) and emit an error message. I still prefer the former alternative because it is easier to implement and in some cases might even become useful when people want to enter an en dash in an environment not supporting direct entry of the glyph, but I would also support the latter alternative.
:::: --] (]) 10:42, 13 August 2021 (UTC)


]:
== summary messaging in the preview warning header ==
*convert {{cl|CS1 maint: unfit URL}} to properties cat {{cl|CS1: unfit URL}}; ]


]:
Whenever you preview a page, above the previewed text there is a yellowish message box that reads: 'This is only a preview; your changes have not yet been saved!' Scribunto has a function <code>mw.addWarning()</code> that can add text to that box. Usually I only notice that box when some template has duplicate parameters. For example, this template:
*update emoji zwj table to Unicode v16.0; nothing changed except version and date;
:<code><nowiki>{{cite book |title=Title |title=Title}}</nowiki></code>
*add script lang codes 'az', 'chr', 'zgh';
causes this message:
*add free DOI registrants 10.18637 – Foundation for Open Access Statistic, 10.1016/j.proche – Procedia Chemistry
:'''Warning: Help talk:Citation Style 1''' is calling ] with more than one value for the "title" parameter. Only the last value provided will be used.
*convert Category:CS1 maint: unfit URL to properties cat Category:CS1: unfit URL
It occurred to me this morning that adding generic messaging about cs1|2 errors and maintenance messages might help editors notice that there are errors in an article's cs1|2 templates. So I've hacked ] as an experiment. To see this experiment, edit and then preview ].
*relax 'HugeDomains' generic title search; ]


]:
Opinions?
*fix extended free doi bug; ]
*bump 5-digit doi prefix limit; ]


]:
—] (]) 14:16, 12 July 2021 (UTC)
*reworked hyphen_to_dash(); ]
:I like it in general, and I can imagine it being useful for a variety of template errors. There is precedent for using it for duplicate parameters, but those are rare since they were cleaned up, so most editors probably haven't seen such an error. I think we would have to get buy-in from the community, since these messages would be appearing on every editor's preview screen. Pitchforks, etc. I wonder if there is a way to do a small-scale test. – ] (]) 16:24, 12 July 2021 (UTC)
—] (]) 01:57, 21 December 2024 (UTC)
::I suppose that, if we must, we could limit the output to cs1|2 templates that are not {{tlx|cite book}}, not {{tlx|cite journal}}, not {{tlx|cite news}}, not {{tlx|cite web}}, and not {{tlx|citation}}. Or, conversely, to just one of the 'big 5' ...
::—] (]) 17:24, 12 July 2021 (UTC)
:I agree that this looks like a good idea. Might one possibility for a test be to limit it to a single additional class of error, and to pick something that's clearly always a significant error: e.g. {{tl|cite journal}} being used without <code>journal=</code>? ] (]) 18:00, 12 July 2021 (UTC)
::The {{error-small|Cite &lt;template> requires {{para|&lt;param>|plain=yes}}}} error messages are hidden so don't seem to me to be a good candidate for a test. Though I haven't tried it, I think that picking a particular error is rather more difficult and goes beyond the intent of this messaging which is more summary than detail. But, it does raise an issue: what to do about hidden error messages? We might change the message so that it reads:
:::<span class="error" style="font-size:100%">&#123;{&lt;{{var|template}}>}} template has {{var|n}}× errors; messages may be hidden (])</span>
::I've also noticed that exact duplicates of the messages added to the yellowish box are not repeated so it would make some sense to have the messages read:
:::<span class="error" style="font-size:100%">One or more &#123;{&lt;{{var|template}}>}} template has {{var|n}}× errors; messages may be hidden (])</span>
::—] (]) 19:04, 12 July 2021 (UTC)
: {{anchor|CITEREFAuthor2020|CITEREFAuthor2021}}I like this as well. Would it be possible to let the "cite xyz" prefix in the messages link to the template's help page, like in "{{tl|cite book}}"? This would make it easier to look up the template-specific help in case of errors and would follow the same idea as this older proposal to add small "]" icons in front of the citations in preview mode: ]. --] (]) 18:22, 12 July 2021 (UTC)
: What's interesting is that if identically looking messages are added, only one of them will be shown. To avoid this, a template would have to provide some disambiguating information (like its CITEREF anchor):
:: {{tl|citation}} template "]" has 2× errors
:: {{tl|citation}} template "]" has 1× errors
: This would help to avoid oddly looking messages such as
:: {{tl|citation}} template has 2× errors
:: {{tl|citation}} template has 1× errors
: and also help to locate the problematic template if there are many uses of the same template, but on pages with many citations (with errors) the list could become very long.
: On the other hand, it could also be used to keep the message very short in total by just stating that there ''are'' errors instead of how many:
:: {{tl|citation}} template has errors
: --] (]) 18:42, 12 July 2021 (UTC)
::I've tweaked the test a bit (error messages only) because of that identical-messages-not-repeated thing, linked to the template pages and corrected for <code>config.CitationClass</code> that doesn't exactly match the template's canonical name. I'm not wedded to the '{{var|n}}× errors' text; I added it because I wanted to see how easy it would be to include that kind of information. It is perhaps too much detail; this is supposed to be summary (I've also changed the topic's title to reflect 'summary' rather than 'generic')
::—] (]) 19:04, 12 July 2021 (UTC)
::: If it's only meant as a summary to alert the editor that there ''are'' errors to look at (further down), I think, the number of errors is not important to know at all. It's also irrelevant to know that different citations using the same template might contain different numbers of errors. By eliminating the number we would avoid such odd looking messages.
::: Still good to know how to include additional information for cases where this might be useful to provide in the future.
::: --] (]) 19:38, 12 July 2021 (UTC)
::: I personally like the colored messages, but for consistency with the messages issued by MW itself, perhaps it would better if our messages were using the same style and capitalization. This could look similar to:
:::: '''Warning: Help talk:Citation Style 1''' is calling ] with more than one value for the "title" parameter. Only the last value provided will be used. (])
:::: '''Warning: Help talk:Citation Style 1''' is calling ] with {{red|errors}}. Messages may be hidden. (])
:::: '''Warning: Help talk:Citation Style 1''' is calling ] with {{green|warnings}}. Messages may be hidden. (])
::::
::: --] (]) 17:01, 13 July 2021 (UTC)
::: For comparison, the {{tl|infobox}} templates don't use <code>mw.AddWarning()</code> but issue error messages looking somewhat similar to MW's:
:::: ''{{red|'''Preview warning:''' Page using ] with unknown parameter "unknown"}}''
::: This message shows up at the location of the template's invocation (that is typically just below the yellowish preview box). What we can draw from this is that issuing inline messages only in preview would be an option for us as well. So, it we would want to keep the message in the yellowish preview box really short, it could be reduced to a single line even in case of multiple templates generating errors like:
:::: '''Warning: Help talk:Citation Style 1''' is calling citation templates with {{red|errors}} or {{green|warnings}}. Messages may be hidden. (])
::: We would still be able to provide links to the individual templates' help pages by using the same preview messaging mechanism as {{tl|infobox}} to insert those small "]" icons (per the above linked thread) in front of the citations (at least those, which have errors):<ref name="Smith_2015">] {{cite journal |last=Smith |first=John |date=9999 |title=Title of Things |journal=Journal of Stuff |volume=34 |issue=1 |pages=23–45 |doi=10.4321/3210 |pmid=012345}}</ref>
<div style="margin-left:6.4em">{{Reflist}}</div>
::: --] (]) 17:43, 13 July 2021 (UTC)
::::I don't particularly care for the MediaWiki warning style. I'm pretty sure that I know what page it is that I'm editing so that information isn't needed. I've tweaked the colored messages so they don't bleed quite so much and removed the error-tally from the messages. The point is to draw attention to the need for repairs so the color is, I think, important. If the cs1|2 messages look too much like the MediaWiki messages, I fear that they will be ignored.
::::—] (]) 21:42, 13 July 2021 (UTC)
:::::I think that the revisions are an improvement. I noticed one apparent typo: "One or more {{tlx|cite book}} template has errors" should read "... templates ..." – ] (]) 17:26, 14 July 2021 (UTC)
::::::Are you sure? Plural 'templates' just sounds wrong to me because 'One' dominates and 'or more' could almost be set off with commas or parentheses:
:::::::One, or more, {{tlx|cite book}} template has errors
:::::::One (or more) {{tlx|cite book}} template has errors
::::::And, if it is as you say, wouldn't it be: "One or more {{tlx|cite book}} templates <u>have</u> errors"?
::::::
::::::I suppose we could evade the issue and rewrite – though this doesn't share nicely with maintenance messaging:
:::::::{{tlx|cite book}} template errors detected
::::::or we could write:
:::::::{{tlx|cite book}} template has errors
:::::::{{tlx|cite book}} template has maintenance message
::::::—] (]) 17:54, 14 July 2021 (UTC)
:::::::I missed the verb. It should be "templates have". (which do not always agree, of course). If we can't agree, a slightly uglier phrasing of "At least one cite book template has errors" would be grammatical. – ] (]) 22:54, 14 July 2021 (UTC)
::::::: Some observations:
::::::: The preview messages give the canonical name of the template. It would show, for example, {{tlx|cite book}} even if {{tlx|cite book/new}} is what was invoked. Similar, it would show {{tlx|cite news}} even when the actually used template is {{tlx|cite newspaper}}, a redirect. While the first case could be fixed programmatically, there is no cure for the second type of cases. However, perhaps no actual fix is necessary. The wording could be adjusted accordingly, for example:
:::::::* {{tlx|cite book}}-type templates have errors
:::::::* {{tlx|cite book}}-related templates have errors
::::::: or something along this line. Alternatively, since noone commented negatively on my proposal for template-specific "]"-style help links in front of the problematic citation templates themselves above, I'm bringing this up again in this context. Thereby we could eliminate the need to explicitly state the name of a template in the preview at all:
:::::::* A CS1/CS2 citation template has errors
:::::::* A {{tlx|cite ...|nolink=yes}} template has errors
:::::::* CS1/CS2 citation templates have errors
:::::::* {{tlx|cite ...|nolink=yes}} templates have errors
::::::: As can be seen on this page, the preview message also occurs on talk pages. While this is certainly desirable here (to illustrate the messages) this could encourage editors on other talk pages to correct errors in templates even in other editors' talk page contributions - while this would be in most cases harmless, I'm not sure if we should encourage this. However, disabling the messages on all talk pages we would need some means to override this (for example, to still show them on ''this'' talk page, where the automatic disabling could be overridden by our debug parameter {{para|template-doc-demo/no-tracking|yes}}, for which BTW we are still seeking a better name).
::::::: --] (]) 14:32, 21 July 2021 (UTC)
::::::::It is not possible to know the name of the template that <code><nowiki>{{#invoke:}}</nowiki></code>s ]. We can spoof {{tlx|cite book/new}} if we modify that template to use {{para|CitationClass|book/new}} (and then modify the module so that it recognizes both forms ...). Not worth the effort to do that.
::::::::
::::::::I have no enthusiasm for {{tq|template-specific "]"-style help links}}. And, {{para|link}} has the same 'canonical name only' problem that you are complaining about with the preview messages...
::::::::
::::::::We can use the same mechanism that we use to prevent talk-page-categorization to prevent preview messaging in those same namespaces. We might need to create a variable <code>no_preview_msgs</code> so that we allow preview messaging in ~/sandbox pages else we can just reuse <code><code>no_tracking_cats</code></code>.
::::::::—] (]) 15:22, 21 July 2021 (UTC)
::::::::: Just in case this somehow went down the wrong throat, I was not ''complaining'' at all, just listing observations and possible options in our quest to find the best-possible solution.
::::::::: Also, I agree with you that gettting {{tlx|cite book/new}} right would not be worth the effort.
::::::::: Regarding the template-specific help icon, I don't understand your {{para|link}} argument. Of course, for the reasons stated, the help link would point to {{tlx|cite news}} even if the actual invocation would be from {{tlx|cite newspaper}} or {{tlx|cite news/new}}. But by using an icon instead of text we would not have to explicitly state the target name as in the preview message, thereby avoiding the issue altogether.
::::::::: From the usability point of view, both ways provide the template-specific help link. There are probably some minor pros and cons depending on if the context-link is in the preview box at the top of the screen (getting sort-of the template's name to search for, but having to look up the error messages elsewhere) or in front of the offending citation (getting a help link in the immediate vincity of the template throwing the error/warning, but not getting any hint at the template's name at all) - but I would consider them both as good enough for the purpose. It would even be possible to combine them.
::::::::: From the coding perspective, the box message gets issued through <code>mw.addWarning()</code>, whereas the icon would depend on <code><nowiki>{{REVISIONID}}</nowiki></code>, not much code overhead either way.
::::::::: Regarding not being enthusiastic, I would appreciate if you could explain this a bit more rationally to better understand your thinking. Is it related to the look, the usability, the implementation, or just a lack of fun doing it?
::::::::: --] (]) 17:34, 21 July 2021 (UTC)
::::::::::Using an icon image does not avoid the issue of explicitly stating the target name because, for accessibility, we must supply values for the icon's {{para|alt}} and {{para|link}} parameters. {{para|alt}} might get something like <code>link to cite news template documentation</code> so alt text and the link suffer from the same problem as the preview warning when the offending template is a redirect or a wrapper. Omitting the canonical template name from the alt text (<code>link to template documentation</code>) is not acceptable because we should identify the icon's link target.
::::::::::
::::::::::I don't think that lack of enthusiasm demonstrates irrationality on my part. I am not enthusiastic about icons because I'm not enthusiastic about icons. I don't like that these proposed icons are at one end of the rendered citation while the error messaging is (primarily) at the other end. I wonder if we should include a list of cs1|2 templates somewhere on ] and then link to that list from each error message section in the same manner that we link to the help desk. Or, perhaps, modify the error messaging so that the linked canonical template name prefixes the error messages in preview. To do that will require a bit of work to move all error messages that now render mid-citation to the end of the rendering (something that I think should be done anyway):
::::::::::: {{error-small|1=<code style="color: inherit; background: inherit; border: none; padding: inherit;">&#x7B;&#x7B;]&#x7D;&#x7D;</code>: &lt;{{var|error message}}> (])}}
::::::::::—] (]) 13:51, 22 July 2021 (UTC)
::::::::::: Thanks, this is exactly the type of explanation I was missing. I did not intend at all to imply irrationality on your side. But to understand each other we need to explain our feelings and reasoning to others. I did not consider the lack of alt text an accessibility issue here because I saw the icon as a non-essential part of the UI and was willing to compromise on it in order to keep it as short and unobtrusive as possible. In the old thread, I was also proposing to alternatively just use a text question mark. But I can see your point. In the old thread, Headbomb suggested adding a whole sentence fragment following the citation, something that I found too long for what we wanted to achieve, but I like your proposal to move all mid-citation messages to the end and prefix them with just the canonical name of the template - this way, it remains unobtrusive and short.
:::::::::::--] (]) 01:57, 24 July 2021 (UTC)
::::::::::::I have hacked ] so that all of the error messages that it produces are now listed at the end. These error messages account for the preponderance of mid-citation error messages. I have added the template name prefix and an error message sort to ] so that error messages are listed, more-or-less, in alpha-order. The sort is simple ascii and isn't perfect because the error messages to be sorted have html markup and html entities; for example, these sort in this order:
::::::::::::#{{code|lang=html|1=<span class=\"cs1-hidden-error citation-comment\"><code class=\"cs1-code\">&#124;volume=</code> has extra text (])</span>}}
::::::::::::#{{code|lang=html|1=<span class=\"cs1-visible-error citation-comment\"><code class=\"cs1-code\">&#124;issue=</code> has extra text (])</span>}}
::::::::::::#{{code|lang=html|1=<span class=\"cs1-visible-error citation-comment\">Check <code class=\"cs1-code\">&#124;arxiv=</code> value (])</span>}}
::::::::::::A good place to see this in action is at ]. Still need to seek through error message creation in other module pages to find the remaining mid-citation error messages and move them to the end. Once that's done, I think that further optimization can be done because messages can (should be?) added to <code>z.message_tail</code> by <code>set_message()</code> instead of where the message occurs unless something special is required for a particular message.
::::::::::::—] (]) <s>11:56, 25 July 2021 (UTC)</s> 19:52, 25 July 2021 (UTC) {{small|(better sort example)}}
::::::::::::: I like this (most of it). One further idea:
::::::::::::: In order to make it easier to put the focus on the rendered citations with the detailed error messages, I think, the messages in the preview box should contain a link to this location. As a matter of fact, we can't link to all of them, but the most reasonable location to link to would be the first citation throwing an error. Once fixed, the link would point to the next offending citation in the row, and so on, so this linking scheme would appear to be quite natural in the process of fixing errors. Also, clicking the link would (and should) work even for citations generating "invisible" messages, so the editor would at least see the (first) offending citation, even if not the actual message.
::::::::::::: Implementing this would be quite easy: All we would need is a template-specific anchor for errors and for maintenance created in front of a citation if (and only if) this citation throws the corresponding type of message (regardless of visibility). The message in the preview box could then link to this anchor. If multiple citations of the same type would throw messages, they would all create identically named anchors and, clicking the link in the preview box, the browser would focus on the first of them.
::::::::::::: In theory, creating identically named anchors is invalidating the HTML, but this does not cause any real-world issues and it also happens with non-disambiguated ({{tl|harv}}-style) references. Still, to avoid this at least in the normal article view we could generate these invisible anchors only in article preview (using <code><nowiki>{{REVISIONID}}</nowiki></code>), so that they would only exist when an editor is previewing a page, and there is actually a preview box with errors containing links to them.
::::::::::::: The preview messages could look like (mockup):
:::::::::::::: {{red|One or more {{tl|cite journal}} templates issue ]}}; messages may be hidden (])
:::::::::::::: {{green|One or more {{tl|cite book}} templates need ]}}; messages may be hidden (])
::::::::::::: --] (]) 10:32, 29 July 2021 (UTC) (updated 11:01, 29 July 2021 (UTC))
::::::::::::::As a simple experiment, I have hacked ] to create an anchor from <code>config.CitationClass</code> for the error warnings (not for maintenance). , preview.
::::::::::::::
::::::::::::::I'm not sure that the word 'errors' should be linked; that doesn't make it obvious that the link takes the editor to a broken citation. Perhaps something like:
:::::::::::::::{{error-small|One or more {{tl|cite journal}} template has errors}}; messages may be hidden (]). ]
::::::::::::::—] (]) 13:38, 29 July 2021 (UTC)
:::::::::::::::And now maint warnings.
:::::::::::::::—] (]) 14:56, 29 July 2021 (UTC)
:::::::::::::::: We could use the same style as MW:
::::::::::::::::: This is only a preview; your changes have not yet been saved! ]
::::::::::::::::: {{red|One or more {{tl|cite journal}} templates have errors}}; messages may be hidden (]). ]
:::::::::::::::: --] (]) 17:07, 29 July 2021 (UTC)
:::::::::::::::::Meh. We are not MW so why would we want to look like MW?
:::::::::::::::::—] (]) 17:29, 29 July 2021 (UTC)
:::::::::::::::::: Consistency of the user interface, to give the user a smooth and seamless experience and let it look as if it was designed as "one thing" as much as possible instead of everyone inventing their own style.
::::::::::::::::::--] (]) 20:09, 29 July 2021 (UTC)
::::::::::::::::::: Thanks for implementing it. I have changed the trailing semicolon into a dot to properly stop the sentence and for consistency with the MW message above.
::::::::::::::::::: Playing with the feature I must say I really like it and hope that it will be well-accepted by the community and help to spot citation errors more easily. :-)
::::::::::::::::::: Still, I think, that some more refinement is desirable in regard to the message text:
:::::::::::::::::::: {{red|One or more {{tl|cite book}} template has errors}}; messages may be hidden (]). ]
:::::::::::::::::::: {{green|One or more {{tl|cite book}} template has maintenance messages}}; messages may be hidden (]). ]
::::::::::::::::::: To me the combination of "more" and singular "template has" sounds odd. Jonesey suggested plural "templates have". You mentioned that, for you, "one" dominates. There is a singular-rule for or-clauses, but it applies only for as long as all individually listed items are singular. To me, "more" implies plural of templates, and the verb follows the {{lang|la|numerus}} of the nearest subject.
::::::::::::::::::: Another observation is semantically: In a strict sense, it is (hopefully) not the template having errors, but the template's invocation (the citation) in the article. Perhaps this could be remedied without complicating things too much simply by using verbs like "issue errors" or "emit errors" (or your "detected errors" above) instead of "have errors". In the maintenance case, we could use "need maintenance" instead of "have maintenance messages":
:::::::::::::::::::: {{red|One or more {{tl|cite book}} templates issue errors}}; messages may be hidden (]). ]
:::::::::::::::::::: {{green|One or more {{tl|cite book}} templates need maintenance}}; messages may be hidden (]). ]
::::::::::::::::::: or perhaps something like
:::::::::::::::::::: {{red|Template {{tl|cite book}} signals citation errors}}; messages may be hidden (]). ]
:::::::::::::::::::: {{green|Template {{tl|cite book}} requests citation maintenance}}; messages may be hidden (]). ]
::::::::::::::::::: --] (]) 18:27, 31 July 2021 (UTC)
::::::::::::::::::::{{tq|Template {{tl|cite book}} requests citation maintenance}}. Do not like. Too anthropomorphic. I still prefer 'One or more cite xxx template has ...' but I would also write 'the government are morally bankrupt' instead of '... is morally bankrupt'. But the tide is against me so I've changed to 'One or more cite xxx templates have ...'
::::::::::::::::::::—] (]) 18:46, 1 August 2021 (UTC)
::::::::::::: Regarding alpha-sorting of the messages, I think this is good enough for now, although this sometimes leads to somewhat odd results when there are many messages at once. In the long run, I think, we would have to add some weighting to group the more essential messages first, possibly ordered by occurence in the citation's rendering, followed by ID-related messages sorted alphabetically (or, more indirectly, by order of IDs in the table). But since there are typically not many messages at once, I think it is already good enough for a release.
::::::::::::: --] (]) 13:18, 1 August 2021 (UTC)
::::::::::::::It isn't hard to strip html and html-like tags from the error messages and sort by the message text:
:::::::::::::::<syntaxhighlight lang="lua">table.sort (z.error_msgs_t,
function (a, b)
return a:gsub ('%b<>', '') < b:gsub ('%b<>', '') end
)
</syntaxhighlight>
::::::::::::::and then if you really want to sort by first letter of the error message, you have to also strip leading pipes from those messages that begin with a parameter name. Unless it is {{em|really}} necessary, we document the apparent anomalies and leave it at that.
::::::::::::::—] (]) 18:46, 1 August 2021 (UTC)
:I suppose anything that points out errors before the edit is committed is a good thing. I don't see any obvious negatives, except that the usual chorus of snowflakes may find something else to complain about, regardless. ] (]) 12:12, 13 July 2021 (UTC)
: Wild brainstorming: Is there a way to make the text of added preview warnings invisible somehow, and does <code>mw.addWarning()</code> provide return codes, perhaps even a special one when a message gets discarded for being a duplicate? If so, perhaps this mechanism could be utilized to let a citation detect that it is using the same CITEREF anchor as another citation on the same page and therefore would need disambiguation in conjunction with {{tl|sfn}}... --] (]) 19:00, 13 July 2021 (UTC)
::Why would you want to hide a preview message? It can be done with css <code>display: none;</code> but why? Are you suggesting that this could be (mis)used as a inter-template mailbox? Sort of a one-way mailbox though, isn't it?
::
::], such as it is, for <code>mw.addWarning()</code>. No return value but if you write this in the debug console the 'return' value is 'nil':
:::{{code|lang=lua|1==(nil == mw.addWarning('warning text')) and 'nil' or 'sommat else'}}
::—] (]) 19:31, 13 July 2021 (UTC)
::: Exactly, the wild idea was to send "invisible" messages containing the CITEREF anchor name to the preview box and act on the return code (if there would be a special one when discarding duplicate messages). However, just wishful thinking... --] (]) 20:04, 13 July 2021 (UTC)
::: BTW. The German documentation is somewhat better, but still no return code: ] --] (]) 20:08, 13 July 2021 (UTC)
:While I heartilly endorse having an error summary at the beginning or end, I would prefer to keep or improve the exiting inline error messages. The easier it is to find the offending markup, the better, and removing the messages from the citations would be a step backwards. --] (]) 12:43, 25 July 2021 (UTC)
::Umm, where did you get the idea that this proposal will remove error messages attached to individual citations? It will not. The summary at the top is intended to alert editors that errors are present at the bottom of an article preview where editors might not think to look before saving an edit.
::—] (]) 13:59, 25 July 2021 (UTC)
: See also: ] --] (]) 10:32, 29 July 2021 (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)
== How to extlink the components of a multi-component publication ==
:
: 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)
::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)
::::"Is a sub-type of unfit" .. ? Unfit are individual URLs that are a problem in an otherwise legitimate website/domain. Usurped are URLs for an entire websites/domains. They are tracking similar problem URLs but of different scope. I agree it works to have one category, but thought the category placeholder name could be the larger more common set. Usurped is now up to and I forecast this number will be 100s k if not millions, dwarfing unfit. -- ]] 20:06, 1 January 2025 (UTC)
:I forgot to mention that some time ago I implemented a prospective work-around for the {{error-small|Lua error in Module:Citation/CS1/Configuration at line 2083: attempt to index a boolean value}} messages. These messages occur when the attempt to fetch ID limits from Commons (]) fails. When the fetch fails, ] will use default limit values of 99999999999 so that individual limit tests will not fail. Articles where this happens will be added to {{cl|CS1 maint: ID limit load fail}}. Unlike all other maintenance categories, this category will not emit the maintenance message because it would appear in every cs1|2 template rendered in the article. A null edit should remove an article from the category. It is nearly impossible to test this code because the load failure is rare and random but, famous last words, I believe that I haven't done anything too stupid.
:—] (]) 15:32, 27 December 2024 (UTC)
::I've added the cat to list of things to watch. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 15:43, 27 December 2024 (UTC)


== Reformat dates v2 ==
This citation:
*<nowiki>{{citation
| last = Theil | first = H. | authorlink = Henri Theil
| journal = Nederl. Akad. Wetensch., Proc.
| pages = 386–392, 521–525, 1397–1412
| title = A rank-invariant method of linear and polynomial regression analysis. , ,
| volume = 53
| year = 1950}}</nowiki>
*{{citation
| last = Theil | first = H. | authorlink = Henri Theil
| journal = Nederl. Akad. Wetensch., Proc.
| pages = 386–392, 521–525, 1397–1412
| title = A rank-invariant method of linear and polynomial regression analysis. , ,
| volume = 53
| year = 1950}}
is throwing a CS1 error "External link in |title= (help)". But obviously it wouldn't work to use {{para|title-link}} (the only suggestion at the help link) because the three components of this multi-component work need to be linked separately. Can anyone suggest a way to make this citation work without errors and without splitting it into three separate citations? All I would really want is to disable the CS1 error message, because except for that message the citation template appears to format the citation adequately. —] (]) 17:14, 13 July 2021 (UTC)
:You can link the page numbers:
:*<code><nowiki>{{citation
| last = Theil | first = H. | authorlink = Henri Theil
| journal = Nederl. Akad. Wetensch., Proc.
| pages = , ,
| title = A rank-invariant method of linear and polynomial regression analysis
| volume = 53
| year = 1950}}</nowiki></code>
:*{{citation
| last = Theil | first = H. | authorlink = Henri Theil
| journal = Nederl. Akad. Wetensch., Proc.
| pages = , ,
| title = A rank-invariant method of linear and polynomial regression analysis
| volume = 53
| year = 1950}}
:—] (]) 17:48, 13 July 2021 (UTC)
:: This might be a good solution in the current implementation as we strip off the link before generating the metadata for {{para|pages}} and friends. It might be a good idea to consider to do the same for {{para|volume}}, {{para|number}} and {{para|issue}} as well in order to better support various kinds of multi-partite publications (currently we don't, so adding the links to those parameters would, while still looking nice, mess up the metadata).
:: In this specific case the perfect solution would be to add support for a dedicated {{para|part}} parameter. Even ] has a special attribute for this (<code>rft.part</code>, which we do not use at present), indicating that this is really something we are lacking support for in our current implementation. As far I see it, parts are typically displayed following the title, but before volumes.
:: --] (]) 18:38, 13 July 2021 (UTC)
:::Thanks for the suggestions. I think support for parts would be a good idea, but I think for now I'll follow trappist's suggestion of putting the links on the pages. —] (]) 21:01, 13 July 2021 (UTC)
:::The simplest solution may be implementing {{para|page-link{{var|n}}}}, this assumes the editor should match the link number to the page sequence in {{para|pages}}. ] (]) 13:33, 14 July 2021 (UTC)
:::: There is no need for separate {{para|page-link{{var|n}}}} parameters. {{para|pages}} and friends already support page ranges, page lists as well as external links without messing up the metadata. ({{para|volume}}, {{para|number}} and {{para|issue}} don't support external links at present, though.) Hence, there is no need for a separate {{para|page-link{{var|n}}}} parameter to provide links. Associating the ''n''th-link with a particular list item would considerably complicate the code. --] (]) 20:41, 14 July 2021 (UTC)
::::: There is a need for link parameters only when the module is designed logically. An entity and a link to the entity are not the same thing and should be represented separately, not with the same parameter. This is flexible and understandable by editors. On a lower level, data types should correspond to unique parameters. You shouldn't have the same field accepting images and free-form text for example, or URLs and plain text as another example. But as stated, this presumes a logical module design. So this is probably off-topic. ] (]) 20:57, 14 July 2021 (UTC)
:::::: During the great hyphen war many users didn't care about logical design vs. ease of use. -- ]] 16:15, 15 July 2021 (UTC)
:::::::Another assessment would be that entrenched ways are largely immune to logic, especially when work is required to arrive at a rational state. Also, zealotry to do something is just as bad as inertia, as the tracking-category-deletion phase of the hyphen wars shows. ] (]) 17:45, 15 July 2021 (UTC)
: A related discussion: ]
: --] (]) 13:42, 21 July 2021 (UTC)
: Another related discussion: ]
: --] (]) 03:49, 17 August 2021 (UTC)


Previous: ]<br>
==Incorrect spacing==
Hi! I'm trying to find a variable that would allow me to display all dates (we use a bot to convert them into ISO format) using <code>formatDate</code>: https://ru.wikipedia.org/search/?diff=142375001&oldid=141847966. Can you tell me what I'm doing wrong and where it needs to be corrected? ] (]) 17:42, 29 December 2024 (UTC)
Hello, there appears to be some spacing problem in the {{para|issue}} field of {{tl|cite news}} it appears to add a space after the comma for some reason.
:What you mean by {{tq|variable that would allow me to display all dates}}.
:
:You {{tq|use a bot to convert them into ISO format}}. Does that mean that your bot converts all wikitext dates to {{tq|ISO format}} so that cs1|2 never sees anything but ISO format dates? Even date ranges? (YYYY-MM-DD/YYYY-MM-DD) Seasons? Named dates (Christmas, Easter, etc)? What about dates outside of the Gregorian calendar?
:
:At ] you use <code>formatDate()</code> to format the value returned from <code>reformatter()</code> (called from either ] or ]). At ] you use <code>formatDate()</code> to format the date that was just formatted at line 1002. Why?
:
:Do you have an example sandbox somewhere that shows what you want and what you're getting?
:—] (]) 18:37, 29 December 2024 (UTC)
::{{tq|1=What you mean by variable that would allow me to display all dates.}}<br>I mean the variable that is returned in AccessDate, ArchiveDate and Date in ].{{pb}}{{tq|1=Does that mean that your bot converts all wikitext dates to <q>ISO format</q> so that cs1{{!}}2 never sees anything but ISO format dates?}}<br>So far only English and Russian dates supported by Citoid. Perhaps in the future we will try to convert all Russian and English dates, and another languages. <br>I thought to use additionally your date converter to convert maximum number of dates to iso (by using <syntaxhighlight lang="lua" inline>global_df = 'ymd-all',</syntaxhighlight>), and then pass what is obtained through the <code>formatDate()</code>. And if the <code>formatDate()</code> displays an error, then display your output without <code>formatDate()</code>.{{pb}}{{tq|1=At ] you use <code>formatDate()</code> to format the value returned from <code>reformatter()</code> (called from either ] or ]). At ] you use <code>formatDate()</code> to format the date that was just formatted at line 1002. Why?}}<br>I was trying to figure out how it works.{{pb}}{{tq|1=Do you have an example sandbox somewhere that shows what you want and what you're getting?}}<br>] - first table. {{pb}}I am currently using a local module to convert dates, but I don't like the location where I am using it.<br>https://ru.wikipedia.org/search/?title=Module:Citation/CS1&action=edit (line 436) ] (]) 19:00, 29 December 2024 (UTC)
:::The first three testcases ({{para|access-date|2001-01-14}}, {{para|access-date|January 14, 2001}}, {{para|access-date|14 January 2001}}) are not modified because those dates are invalid – there cannot be an access date that precedes the creation of Misplaced Pages. The last testcase is also invalid because that date exists in the future (day after tomorrow).
:::
:::When <code>reformatter()</code> returns <syntaxhighlight lang="lua" inline="1">mw.language.new( 'ru' ):formatDate( 'j xg Y', new_date );</syntaxhighlight>, two testcases, {{para|access-date|January 15, 2001}} and {{para|access-date|15 January 2001}}, both return 15 января 2001.
:::
:::The remaining testcases ({{para|access-date|2001-01-15}}, {{para|access-date|2024-12-30}} – today's date, {{para|access-date|2024-12-30}} – tomorrow's date) return their inputs because you specify <syntaxhighlight lang="lua" inline>global_df = 'ymd-all',</syntaxhighlight>. The code at ] terminates the conversion because converting ymd to ymd is a pointless waste of processor cycles. I added a test at line 932:
::::<syntaxhighlight lang="lua"> if 'ymd' == format_param and 'ymd' == pattern_idx then -- special case for ru.wiki
return mw.language.new( 'ru' ):formatDate( 'j xg Y', date ); -- convert ymd to dMy
end
</syntaxhighlight>
:::With that code in place, the remaining tests return 15 января 2001, 30 декабря 2024, and 31 декабря 2024.
:::—] (]) 16:35, 30 December 2024 (UTC)
::::Yeah! Thanks, it works, but I have some problems with dates without day.<br>].<br>If the date parameter is specified without a day, the conversion through formatDate does not occur. However, if it is specified in the archival date or access date, all dates break. ] (]) 19:46, 30 December 2024 (UTC)
:::::{{para|access-date}} and {{para|archive-date}} must include day, month, and year – the dates are meaningless else.
:::::
:::::It is pointless to convert ym dates to ymd dates. Add this:
::::::<syntaxhighlight lang="lua"> if 'ymd' == format_param and 'ym' == pattern_idx then -- special case for ru.wiki
return mw.language.new( 'ru' ):formatDate( 'xg Y', date ); -- convert ym to My
end
</syntaxhighlight>
:::::change the sequence in the first <code>if</code> in <code>reformatter()</code> to include <code>'ym', </code>.
:::::
:::::You still need to add the call to <code>formatDate()</code> at the end of <code>reformatter()</code>. Without you do that, the 5th and 6th test_access_dates tests at ] do not convert.
:::::—] (]) 15:02, 31 December 2024 (UTC)
::::::It works! Thanks! :) ] (]) 15:58, 31 December 2024 (UTC)
:Consider the
:<code><nowiki>{{cite journal/песочница |title=Title |journal=Journal |date=23–29 February 1700}}</nowiki></code>
:Leaving aside whether all the functions used can handle the date 29 February 1700. The correct result needs careful inspection because no real journal is specified, therefore it's unknown whether the journal used the Gregorian or Julian calendar until we examine the date. But the date 29 February 1700 tells us it must be a Julian date because 1700 was not a leap year in the Gregorian calendar. Since it is a Julian calendar, the choices are to keep the date in the original format, or change it to the corresponding Gregorian ISO 8601-1-2019 date range:
::1700-03-05/03-11
:] (]) 17:11, 31 December 2024 (UTC)
::I agree with you, but as long as the core MediaWiki functions do not support date ranges and other mechanisms, I prefer not to use them in templates :)<br>]<br>] ] (]) 17:23, 31 December 2024 (UTC)


== OCLC parameter now needs to allow 11 digits. ==
<blockquote><nowiki>{{cite news |title=The new Exchange railway station at Bradford |work=The Leeds Mercury |issue=14,479 |date=3 September 1884 |location=Column F |page=3}}</nowiki>
<br />
{{cite news |title=The new Exchange railway station at Bradford |work=The Leeds Mercury |issue=14,479 |date=3 September 1884 |location=Column F |page=3}}</blockquote>
] (]) 19:41, 16 July 2021 (UTC)
:{{slink|Help:Citation_Style_1|Accept-this-as-written_markup}}
::<code><nowiki>{{cite news |title=The new Exchange railway station at Bradford |work=The Leeds Mercury |issue=((14,479)) |date=3 September 1884 |location=Column F |page=3}}</nowiki></code>
:::{{cite news |title=The new Exchange railway station at Bradford |work=The Leeds Mercury |issue=((14,479)) |date=3 September 1884 |location=Column F |page=3}}
:—] (]) 20:01, 16 July 2021 (UTC)
:::Thanks - I have not come across this before. ] (]) 21:21, 16 July 2021 (UTC)
::::@] Is this really worth applying to all the instances of cite news in which it occurs when the vast majority of users who add citations using cite news will be oblivious of the issue and will not be using some obscure markup when they add the citation? If effort cannot/has not been put into preventing the template behaving in this way in the first place - a never ending battle in applying a manual fix appears to be fruitless. This is bordering on ] territory. ] (]) 21:52, 17 July 2021 (UTC)
:::::I am just trying to fix the problem, I cannot see it as cosmetic as it is changing the displayed text to remove a space inserted by the templates. ] (]) 21:59, 17 July 2021 (UTC)
:::::This is a "workaround" that is really a "make-work". When was it decided that an issue number including a comma needs a space after that comma? It certainly hasn't always behaved that way. Now my watchlist is flooding with edits {{diff|List of rolling stock items in the UK National Collection|prev|1034110878|like this}} that simply should not be necessary. --] &#x1f339; (]) 22:15, 17 July 2021 (UTC)
::::::@] I don't think this was a deliberate introduction but reading the section Trappist linked to is some bug in CS1 templates that sometimes (always?) shows itself. If it really is a major issue then it should be fixed but @], I'm sorry the way to resolve the issue is to fix the template's behaviour, not by applying some little known manual workaround that simply masks the issue and does not fix it. ] (]) 22:25, 17 July 2021 (UTC)
:::::::This is definitely not cosmetic. The in-source location (the page #) must be given exactly. The behavior you see in this case is because the module regards comma as a separator and formats the number as a sequence of pages, adding a space after the comma (as is proper in such cases). If you dislike the workaround offered, remove the comma from the page number. ] (]) 23:29, 17 July 2021 (UTC)
::::::::Keith D and myself are not talking about page numbers, we're talking about ''issue'' numbers. A physical newspaper or magazine with a particular cover date may have an issue number, or it may not; but if it has one, there won't be more than one for any given date. A daily newspaper will use approximately 313 issue numbers in one year; a monthly magazine will use twelve issue numbers in a year. --] &#x1f339; (]) 08:11, 18 July 2021 (UTC)
::::::::: While there are differences elsewhere, for the interpretation of lists, {{para|volume}}, {{para|number}}, {{para|issue}},{{para|pages}}, {{para|pp}}, {{para|quote-pages}} use the same code, and it would be highly unintuitive, if they would use different rules and syntaxes. --] (]) 08:58, 18 July 2021 (UTC)
::::::::::I know of no cases where {{para|issue}}, {{para|number}} or {{para|volume}} might need to contain a list. In my experience, they're always single values, and should be treated as such. {{para|pages}} is a different matter, and we do provide it as a parameter distinct from {{para|page}} to recognise the fact that a list may often be required. --] &#x1f339; (]) 09:11, 18 July 2021 (UTC)
:::::::::::What about multi-part articles, split between different issues etc of a work (I would normally split these out into separate references, but some people wouldn't.] (]) 10:18, 18 July 2021 (UTC)
::::::::::::Two issues - two references. --] &#x1f339; (]) 20:26, 18 July 2021 (UTC)
: (edit-conflict) There isn't much the template can do about it. These parameters support comma-separated item lists, so if the comma is meant as thousands separator rather than list separator, the ((accept-as-is-syntax)) must be used to indicate this. See also:
:*]
:*]
:*]
:*]
:*]
:IMO, the easiest solution is to simply not use thousands separators. They often cause confusion anyway, because the exact rules and characters used very much depend on the locale you live in (i.e. some countries start grouping at 999, others at 9999, some countries group by 3 digits others by 4 digits, some countries use commas, others use dots, apostrophes or a number of other characters). If anything, thousands separators should be generated by the template itself (using thin-spaces). Another solution would be to use wrapper templates for those rare cases, where the number exceeds 999.
:--] (]) 23:43, 17 July 2021 (UTC)
:: Thinking about it there is one way how to possibly improve the situation slightly (at least in some cases): At present, the templates interpret both, commas and semicolons as list separators. If semicolons are used, they will be translated into commas on the fly for display and metadata purposes. It is important that we support both list separators because different users are used to different separators, however, if we assume that editors will not normally switch between these separators within a single list, we could define one additional rule: If a given list contains at least one semicolon, the comma will no longer work as a list separator but as a thousands separator. Therefore {{para|issue|14,479,800}} would be interpreted as three items "14, 479, 800" and {{para|issue|((14,479)),800}} as two items "14,479, 800", but {{para|issue|14,479;800}} would be interpreted as "14,479, 800" instead of "14, 479, 800". The scheme would only work for arguments containing lists, that is, a single item like "14,479" would still require the accept-as-is syntax {{para|issue|((14,479))}} to keep it from being interpreted as two list items "14, 479". So, effectively, this would still require the usage of a special syntax, but at least some cases might be more intuitive to write than before. Also, it is important to understand that if a scheme like this would be implemented it would work for all parameters taking argument lists for reasons of consistency.
:: --] (]) 08:52, 18 July 2021 (UTC) (updated 11:39, 7 August 2021 (UTC))
:::] seems to suggest that separate logic can be applied to each parameter. Apart from the multi-part article case mentioned about by ], I'm struggling to see any case for space after comma in the issue parameter. And even in the multi-part case I think that is misuse of the template e.g. in listing a bibliography entry rather than as a citation. ] (]) 11:44, 18 July 2021 (UTC)
:::: Citation templates are used for more then references only, so bibliography entries (i.e. in "Works" or "Further reading" sections) are perfectly within the scope of them. Personally, I have also used lists of volumes, numbers and issues in references as well.
:::: Likewise, except for the few cases mentioned here, I never saw issues or numbers higher than 999 in real life as an editor, so they are comparibly rare as well. I guess, it either way depends on what kind of articles and sources one is working on.
:::: It would be possible to treat lists in the various parameters differently, but it would complicate the code (and thereby make it more difficult to maintain) and we frequently receive requests to make citation templates behave more logical and consistent, so not treating list arguments the same everywhere appears to be counter-productive.
:::: Above, I proposed three ways how to possibly make it easier to enter publications with issue numbers higher than 999: The first is to not use thousands separators in the first place - this is syntactical sugar that is basically not needed to convey the message, and they are ambiguous and inconsistent in themselves. Another solution would be to create dedicated wrapper templates for those few newspaper using higher numbers. The third one would be to no longer allow for mixed separator lists using both comma and semicolons, but to disallow commas as list separators as soon as a semicolon is used in the same list. These solutions might improve the sitation without compromising the existing general scheme.
:::: --] (]) 12:13, 18 July 2021 (UTC)
::::: Disagree. Citations are not biblio entries, and citation templates should not be used as bibliography templates. It is better to stop thinking that a rigidly defined set of forms can encompass even the majority of citation cases. Templates are just that, formatted applications of the most general/generic instances. These templates handle most general functions fairly well, but they have a way to go to reach the above-average mark, and the documentation is below par. This is what should be the prime objective, imo (but not under the current environment when even the provenance of tracking categories is questioned). The templates do handle a few special cases tolerably. But multipart sources are a tight-corner case that can be adequately cited with a combination of cs1 templates and {{tl|harvs}} plus custom anchors. As stated, it is not correct to cite multiple issues, volumes, URLs, etc. in a single citation. These are discrete items and should be cited in a discrete fashion, please do not convolute them into a single bibliographic record as a pseudo-citation. After developers are given a free hand to develop as they see fit, and after the essentials are correctly applied, then perhaps exotic items such as multipart citations can be considered. ] (]) 13:05, 18 July 2021 (UTC)
:::::'']'' reached issue 1000 with cover date August 1984. Yes, I've got it - I also have a continuous run of issues 521 through to the current issue, which is no. 1,444 {{sic}}. If you like, I can analyse which have commas and which don't. --] &#x1f339; (]) 21:17, 18 July 2021 (UTC)
: I wonder if we could add some code to detect all-numerical values (optionally in ranges or lists) of more than 4 (not 3 per MOS) digits, and if they exist, to automatically add thousands-separators in form of thin-spaces to them. Numerical values combined with letters or other symbols would be left alone, because then adding thousands-separators to the numerical part might cause confusion.
: Thin-space ("&thinsp;") thousands-separators are one of the styles recommended by ] (and ISO and {{tl|val}}: {{nowrap|12&thinsp;345}}) and they would have the advantage that they cannot be confused with decimal or list separators, no matter of locale. We would probably have to do something about line-wrapping, but otherwise I can't see any problems arising from them. Either way, if it would still be desirabe to leave the numbers alone, the automatic addition of thin-space thousands-separators could be suppressed using our ((syntax)).
: For our purposes, this could help to eliminate the need or urge of some editors to provide thousands-separators in large numerical values in the first place, and thereby reduce the risk of confusion. (IMHO, providing thousands-separators of any kind is a bad practise on parameter input level - the generation of thousands-separators should be left to presentation layer only, therefore done automatically inside the template, if at all.) If there really are large all-numerical page (or volume or issue) numbers which ''must'' use a comma as thousands-separator in order to faithfully reproduce a source also using commas as thousands-separator for some reason, they could still be given using a comma, but then the user would have to use our ((syntax)) to avoid misinterpretation as list separator - just as before.
: Nevertheless, this scheme would cover the majority of standard cases and leave our ((syntax)) for the special cases.
: --] (]) 09:39, 29 July 2021 (UTC)
::I'd be happy with no thin space or no separator in issue numbers or page numbers for that matter. Regarding line-breaks is there a thin non-breaking space? volume and issue that ] (]) 14:18, 29 July 2021 (UTC)
{{outdent|2}} So are we anywhere near a consensus to either:
# do nothing and continue to rely on the clumsy (( )) syntax, or
# do nothing and not worry about spaces after commas in the issue parameter, or
# remove the issue parameter from the list of those parameters where commas are used as list separators, or
# remove all thousands-separators from the issue parameter, or
# replace any thousand-separators with a thin (non-breaking) space?
] (]) 19:38, 11 August 2021 (UTC)
:the simplest, easiest to apply, perfectly legitimate, and correctly-weighted option is to remove thousands separator and explicitly advise editors about it. All other options have flaws. I assign this option the most significant weight because of virtual certainty that citations with issue-no>999 will be encountered several decimal points to the right of the dot. Probably at less than .001. ] (]) 21:35, 11 August 2021 (UTC)
::Not when you're dealing with old newspapers that have been going since the early 19th century. Then it easy to be dealing with five figure issue numbers. I don't have a problem with omitting thousands separators but we need to be clear on the look. ] (]) 11:02, 12 August 2021 (UTC)
:::Issue number is not necessary in newspapers. They are indexed (and commonly referred to) by issue date, not issue number. ] (]) 11:42, 12 August 2021 (UTC)
::::so are many periodicals but nobody is suggesting just to use issue date and not number as well if it is available. ] (]) 13:34, 12 August 2021 (UTC)
:::::Was only referring to newspaper indexing. The reasoning for choosing option 4 was given above. ] (]) 14:08, 12 August 2021 (UTC)
:I would go with 3 as first choice, otherwise 1. Certainly there should be no space in the issue and those above 999 need a seperator. ] (]) 23:39, 11 August 2021 (UTC)
::Why do they need a separator? ] (]) 00:36, 12 August 2021 (UTC)


During a preview on ] I ran into this:
== Param suggestion: |page-url= ==
*<code><nowiki>{{cite journal |last1=Milona |first1=Michael |last2=Weindling |first2=Lauren |title=The Story of Romantic Love and Polyamory |journal=] |date=2024 |doi=10.1111/japp.12764 |doi-access=free |issn=0264-3758 |oclc=10395234777}}</nowiki></code> produces:
*:{{cite journal |last1=Milona |first1=Michael |last2=Weindling |first2=Lauren |title=The Story of Romantic Love and Polyamory |journal=] |date=2024 |doi=10.1111/japp.12764 |doi-access=free |issn=0264-3758 |oclc=10395234777}}
:This gave this error: <code>{{!xt|&lcub;&lcub;}}]{{!xt|<nowiki>}}: Check </nowiki>}}{{!xt|<nowiki>|oclc=</nowiki>}}</code> {{!xt|value &#40;}}]{{!xt|&#41;}}
*{{tl|OCLC}} works fine. <code><nowiki>{{OCLC|10395234777}}</nowiki></code> produces:
*:{{OCLC|10395234777}}
Click through on that 11-digit OCLC # to see that it links to a WorldCat record. ] (]) 22:10, 29 December 2024 (UTC)


== language parameter is not recognising languages ==
A lot of the citations that I see pointing to references on archive.org include urls to the specific pages in the {{para|page}} parameter as in {{para|page|<nowiki></nowiki>}}. It seems like an additional parameter, perhaps named {{para|page-url}}, would be handy to keep track of this information separately. So far, I've been leaving the links like this because they don't appear to be breaking anything yet. ] ] 15:43, 20 July 2021 (UTC)
:It should be an alias of {{para|url}}, not a new parameter. Only 1 URL, the more specific one should be entered in citations, with the page, or the first page in a page range. In any case, I would remove the url from the page param and insert the url param. If the citation includes a page number, it is understood that the link may lead to the pertinent page. If one needs to link multiple pages, short refs would be more apt imo. ] (]) 17:46, 20 July 2021 (UTC)
::Why? The URL of the publication provides access to information on the context of the cited pages. --] (]) 14:04, 21 July 2021 (UTC)
:::That is correct. But also potentially confusing, in the sense of having two URLs pointing to different things, i.e. information/context about the work (the work's URL) and the in-work location (the page's URL). I am not certain the average reader will be able to navigate this with ease. I suppose personally I would include the work's URL in the full citation, and the page URLs on short references. But this is just a preference. ] (]) 16:54, 21 July 2021 (UTC)
: We recently had a related discussion at ].
: These page links are typically added by bots. When I first saw them added to articles a couple of years back I too thought they would be a bad idea (because they add clutter to the {{para|pages}} parameters), however, they are not as bad as they might look at first sight: Like you already observed, they are not breaking anything (in any of the page-related parameters, that is), because the links are automatically removed before using the page information for metadata.
: Regarding the suggestion of having (only) one alias to {{para|url}} for a "page link" and for the proposal to have numbered page parameters (in the other thread), this wouldn't work:
: To the contrary of what the IP stated, the {{para|pages}} parameter often contains a list of pages or even page ranges, and it is not at all desirable to split them up into individual pages or use short references for them. Splitting up into individual pages is only necessary when it is particularly important to document the exact locations where multiple independent statements are sourced. In the vast majority of cases, this is not important, and combining all references to a single publication and providing a list of pages is sufficient. In most cases, it is easy enough to flip through these pages to find the one supporting a specific statement, so having individual references for each of them would only add redundancy and clutter to the article. Short references add an extra layer of indirection and don't allow for backlinks, therefore they are often inconvenient to use - they kind of solve one problem by adding a bunch of other problems. Per ], they are ''not'' a requirement at all to use and many people do not (want) to use them because of their shortcomings. So, suggesting anything that would force us to split up citations is simply no solution at all.
: Regarding numbered page links (as suggested in the other thread), this would require not only numbered page link parameters but also numbered page parameters, as otherwise it would be next to impossible to known which link belongs to which page. While this would be technically a workable solution, it would not be a good one, because it would make the list of pages even more difficult to read and add an enourmous amount of parameter clutter to citations. It would also make the code much more complex and difficult to maintain. I mean, we ''do'' have numbered parameters for the various types of contributors, but we don't have them because this would be a particularly great idea but simply because the template has a need to know the given name, surname and optionally the link to generate the proper representation for display and metadata purposes from this, and the complexity of naming schemes makes it impossible to just provide a name list and let the template ''reliably'' extract the informational bits from it. It would work in some cases, but not in general, that's why we need a set of numbered parameters for the names. However, although there is a huge variety in page numbering schemes, they are still much simplier than names and therefore the code can be made smart enough to reliably extract all the necessary information from a single parameter argument.
: Finally, there was a complaint that it would be a bad design decision for parameters to accept multiple types of input. I can see where this comes from, and it sometimes holds true, but not for citation templates in Misplaced Pages. I consider our approach to be kind of ] (or at least we try to give this impression to users). There are limits, but ideally, you could throw any kind of "data objects" holding the relevant information at a parameter and the template would be able to figure everything out by itself. From the viewpoint of users, the most intuitive way to give a link is to use our standard Mediawiki wikitext syntax. Also, it simply should not matter if they provide a single page, a page range, a list of single pages, a list of page ranges, any kind of combination of them, a linked page, linked page range, list of linked pages or linked ranges, you got it... (Not in the case of page-related parameters, but for completeness, in some cases, parameters also accept some symbolic keywords in addition to text objects.) What can be more simple and intuitive from a user's perspective than to allow them to use the normal Wikitext syntax and just provide a list of data items? Actually, it can't be easier than this. (Unfortunately, we can't do this for names, at least not without introducing a special syntax, which would defeat the idea.)
: One more thought on this: As stated above already, I too do not particuarly like these long strings such as {{para|page|<nowiki></nowiki>}} (but I've come to accept them given that they add useful information for readers and that citations would only become longer when using special parameters for this). However, in many cases the first part of these links is the same as the link provided in the {{para|url}} parameter, like in {{para|url|https://archive.org/details/cihm_07495}}. For these cases, I can envision some kind of shortcut notation like {{para|page|<nowiki></nowiki>}} {{para|url|https://archive.org/details/cihm_07495}}. This obviously would not work for all cases, but it would reduce the clutter and redundancy in many cases already.
: Somewhat related:
:*]
:*]
: --] (]) 12:11, 21 July 2021 (UTC) (updated 13:45, 13 August 2021 (UTC))
::You say {{tq|Short references add an extra layer of indirection and don't allow for backlinks,}}; however, I see back references to, e.g., ], in ]. Admittedly it's a bit clunky, but it works. --] (]) 14:04, 21 July 2021 (UTC)
::: I meant backlinks from the "base citations" back to the various short references. In your example, if you arrive at e.g. the "3270Intro" citation, there are no links to go to all the short references pointing to this entry; you would have to search for them by going through all the references. However, if I would arrive there, I would want to see all the other locations citing from this publication. With an extreme amount of work something like this could be constructed manually, but it would be prone to errors and very difficult to maintain. In your specific example of "3270Intro" there are only two short references pointing there, so they could be easily merged into one with no loss of information. Even in cases such as "3270DS", which have many more short references, most of them are referring to adjacent pages in chapter 3, so it is probably enough to refer to chapter 3 and perhaps the page range, but not to individual pages, and thereby avoid most if not all those short references. If there is a particularly important statement to be referred to, {{para|quote}} and {{para|quote-pages}} can be helpful as well. If the individual page numbers should be preserved, {{tl|rp}} can be used for the individual pages and {{para|pages}} for the combined pages. This way, the additional layer of indirection can be avoided and automatic backlinks are possible.
::: --] (]) 15:00, 21 July 2021 (UTC)


The language parameter is not recognising languages includes ] and ] by their iso code.––]<sup>(])(])</sup> 11:18, 4 January 2025 (UTC)
::::Using {{tag|ref|s|attribs=name{{=}}foo}}{{tlx|rp|bar}} works well when you are only adding a page number to the base citation, but what is the equivalent to {{tlx|sfn|foo|p{{=}}bar|loc{{=}}baz}}? --] (]) 21:52, 21 July 2021 (UTC)
:None of the language tags are supported by MediaWiki:
::::: I would just append it, separated by a comma, like in {{tag|ref|s|attribs=name{{=}}"foo"}}{{tlx|rp|bar, baz}}. Alternatively, you could probably use something like {{tlx|rp|at{{=}}p. bar, baz}} or {{tlx|rp|at{{=}}baz}}. Even page links can be used in combination with {{tlx|rp}}, although this may sometimes require to use of numbered parameters like <code>|1=</code>.
:*Nagpuri (Sadri) <code>sck</code>: <syntaxhighlight lang="wikitext" inline="1">{{#language:sck|en}}</syntaxhighlight> → {{#language:sck|en}}
::::: However, ] applies and you can use {{tlx|sfn}} etc. if you want. My point above was mostly that multiple pages are perfectly fine in a citation (even when used to support multiple independent statements in an article) and that there is no requirement and often no benefit splitting citations into individual short references - it comes with a price, and the disadvantages are often larger than the advantages - as usual, it depends on the circumstances. I made this point to illustrate why we need to support multiple pages and why proposals which would allow us to deal only with single (or related) pages in a citation do not lead anywhere.
:*Nagpuri (Oraon Sadri) <code>sdr</code>: <syntaxhighlight lang="wikitext" inline="1">{{#language:sdr|en}}</syntaxhighlight> → {{#language:sdr|en}}
::::: --] (]) 12:53, 22 July 2021 (UTC)
:*Kharia <code>khr</code>: <syntaxhighlight lang="wikitext" inline="1">{{#language:khr|en}}</syntaxhighlight> → {{#language:khr|en}}
::::::Adding multiple page numbers that support different statements in a single citation is not a problem, but isn't this discussion about page links? It seems to me a full citation with multiple page links is unwieldy and full of clutter. A short ref with the specific page link for the specific wikitext seems more intuitive and easier to understand. ] (]) 17:10, 22 July 2021 (UTC)
:See the documentation for {{para|]}} and, in particular, ].
::::::Using {{tlx|rp|bar|at{{=}}baz}}, {{tlx|rp|bar, baz}} and {{tlx|rp|at=p. bar, baz}} gives me {{rp|bar|at=baz}}, {{rp|bar, baz}} and {{rp|at=p. bar, baz}}. The second an third have the right information, but the location is likely to be long and should be in the reference list rather than inline. --] (]) 19:35, 22 July 2021 (UTC)
:—] (]) 12:38, 4 January 2025 (UTC)
::Is there any way to get such languages included.––]<sup>(])(])</sup> 12:48, 4 January 2025 (UTC)


== Module support edit req ==
== Invalid Cite web aliases in TemplateData ==


{{Edit protected|level=full|Module:Citation/CS1|answered=yes}}
{{Help me-helped}}
I would like to have the following code added to ] - ]. This was previously discussed at ] without any convincing arguments against it. This adds support for modules to call the module directly, instead of using metatables or templates. ] is one of the usecases. The "citation" function was renamed to "_citation", and a new "citation" function made. The "_citation" function would be the entry point for any module, and that module calling it would have to provide the same information as the "citation" function provides. This _x and x naming scheme is consistent with other modules providing access from other modules. Any frame dependant functionality was moved to the "citation" function. Only 4 tests failed at ]. ] (]) 13:03, 4 January 2025 (UTC)
{{For|a list of depreciated Cite web parameters|Cite web#Deprecated}}
:That ] did not, it seems, generate enthusiastic support either. From that discussion, are we to infer that you mean to replace ] (and the others) with a single module that then calls the ] function <code>_citation()</code> with the appropriate arguments? Have you written that replacement module? Where can we see it working?
I have attempted to edit the TemplateData shown for the {{tl|Cite web}}. In the previous iteration, depreciated aliases for the various '''editor<small>''n''</small>-link''' parameters were listed. These invalid aliases were: <code>editor<small>''n''</small>link</code> and <code>editorlink<small>''n''</small></code>. I am trying to remove the nonexistent aliases from the TemplateData, but Misplaced Pages won't let me save my changes, citing JSON errors. <span class="nowrap">&#8212;&#160;]&#160;(]) 19:05, 20 July 2021 (UTC)</span> <span class="nowrap">(edited 19:11, 20 July 2021 (UTC))</span>
:

:Not clear to me that ] would benefit from this change. What am I missing?
I have attempted to resolve the JSON syntax errors per ], believing that I had orphaned commas in my edit (which was true), but it still won't let me save changes due to other unidentified JSON syntax error present. <span class="nowrap">&#8212;&#160;]&#160;(]) 19:30, 20 July 2021 (UTC)</span>
:—] (]) 14:35, 4 January 2025 (UTC)
:JSON is fragile and the error reporting is laughable so it is probably best to use '''Manage TemplateData''' button at the top of the page when viewed using the wikitext editor using the section link (the button is directly under the main page header).
::The modules and what parameters they support are distinct on purpose. This is a feature, not a bug. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 16:42, 4 January 2025 (UTC)
:—] (]) 19:40, 20 July 2021 (UTC)
::Thank you. I will try that later, but I'm taking a break for now. If I'm not mistaken, I believe <code>true</code> is supposed to be encased in quotation marks, but that hasn't cleared the JSON syntax error messages. <span class="nowrap">&#8212;&#160;]&#160;(]) 19:58, 20 July 2021 (UTC)</span> :I unequivocally support adding module access to this module. I have looked at it many times and have not been able to figure it out, so kudos to someone for taking a hack at it. ] (]) 21:32, 4 January 2025 (UTC)
:::The Boolean constants <code>true</code> and <code>false</code> should not be quoted - if they are, they get casted to string type and may not test correctly. --] &#x1f339; (]) 20:07, 20 July 2021 (UTC) ::I have a criticism though. The templatestyles should be in _citation. If you need to get another frame inside there that's fine. ] (]) 21:37, 4 January 2025 (UTC)
:{{Done|Done:}} I have performed the '''editor<small>''n''</small>-link''' edit in the manner suggested. Thank you. <span class="nowrap">&#8212;&#160;]&#160;(]) 20:14, 20 July 2021 (UTC)</span> ::And actually, I think all the <code>lookups</code> should be in _citation. ] (]) 21:37, 4 January 2025 (UTC)
:::Concur. I've moved all that stuff into <code>_citation()</code>. Not yet tested calls from another module.

:::—] (]) 01:03, 5 January 2025 (UTC)
== doi:10.119.1/foobar should throw an error ==
:I have hacked a proof of concept module in ] that appears to demonstrate that ] can be called from another module. The first three examples were scraped from elsewhere on this page, live template rendering above the sandbox rendering:

::<syntaxhighlight lang="wikitext" inline="1">{{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}}</syntaxhighlight>
See
::*{{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}}
*{{Cite journal
::*{{#invoke:Sandbox/trappist the monk/cite|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}}
|first=R.
::<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>
|last=Scurek
::*{{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}}
|title=Understanding the CPT group in particle physics: Standard and nonstandard representations.
::*{{#invoke:Sandbox/trappist the monk/cite|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}}
|journal=Am. J. Phys.
::<syntaxhighlight lang="wikitext" inline="1">{{cite map|author-link=Joe Bloggs|date=5 January 2025|edition=57|editor-first=John|editor-last=Doe|editor-link=John Doe|first=Joe|format=format|issue=38|last=Bloggs|others=others|title=title|type=type|url=https://www.example.com/|volume=52|website=website}}</syntaxhighlight>
|volume=75
::*{{cite map|author-link=Joe Bloggs|date=5 January 2025|edition=57|editor-first=John|editor-last=Doe|editor-link=John Doe|first=Joe|format=format|issue=38|last=Bloggs|others=others|title=title|type=type|url=https://www.example.com/|volume=52|website=website}}
|issue=5
::*{{#invoke:Sandbox/trappist the monk/cite|cite|map|author-link=Joe Bloggs|date=5 January 2025|edition=57|editor-first=John|editor-last=Doe|editor-link=John Doe|first=Joe|format=format|issue=38|last=Bloggs|others=others|title=title|type=type|url=https://www.example.com/|volume=52|website=website}}
|year=2004
:For most cs1|2 templates, the {{para|CitationClass}} parameter is set to the lowercase version of the canonical template name. There are six for which that is not true; {{tlx|cite encyclopedia}} sets {{para|CitationClass|encyclopaedia}}:
|pages=638-643
::<syntaxhighlight lang="wikitext" inline="1">{{cite encyclopedia |last=Seberg |first=Ole |editor1-last=Heywood |editor1-first=Vernon H. |editor2-last=Brummitt |editor2-first=Richard K. |editor3-last=Culham |editor3-first=Alastair |title=Alliaceae |encyclopedia=Flowering Plant Families of the World |url={{google books |plainurl=y |id=Jy1FAQAAIAAJ|page=340}}|date=2007 |publisher=Firefly Books |location=Richmond Hill, Ontario |isbn=978-1-55407-206-4 |pages=340–341}}</syntaxhighlight>
|doi=10.119.1/1.1629087
::*{{cite encyclopedia |last=Seberg |first=Ole |editor1-last=Heywood |editor1-first=Vernon H. |editor2-last=Brummitt |editor2-first=Richard K. |editor3-last=Culham |editor3-first=Alastair |title=Alliaceae |encyclopedia=Flowering Plant Families of the World |url={{google books |plainurl=y |id=Jy1FAQAAIAAJ|page=340}}|date=2007 |publisher=Firefly Books |location=Richmond Hill, Ontario |isbn=978-1-55407-206-4 |pages=340–341}}
}}
::*{{#invoke:Sandbox/trappist the monk/cite|cite|encyclopedia |last=Seberg |first=Ole |editor1-last=Heywood |editor1-first=Vernon H. |editor2-last=Brummitt |editor2-first=Richard K. |editor3-last=Culham |editor3-first=Alastair |title=Alliaceae |encyclopedia=Flowering Plant Families of the World |url={{google books |plainurl=y |id=Jy1FAQAAIAAJ|page=340}}|date=2007 |publisher=Firefly Books |location=Richmond Hill, Ontario |isbn=978-1-55407-206-4 |pages=340–341}}
&#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 20:40, 22 July 2021 (UTC)
:Conveniently, should we decide to implement this as a replacement for ] and the others, ] is currently available.
: The correct DOI would be 10.1119/1.1629087, but wouldn't the registrant code in your example "119.1" be in a valid format as well (that is, at least four digits, larger than 1000, possibly subdivided with dots)? What kind of pattern do you suggest to look for?
: --] (]) 00:32, 23 July 2021 (UTC) :—] (]) 19:49, 5 January 2025 (UTC)
: :
:Are we keeping this or should I discard these changes?
:I imagine that if we troll back through this page's archives we will find a discussion where it was decided that we will allow registrant portion of the doi to have fewer than four digits when it has a subcode (]).
:—] (]) 00:48, 23 July 2021 (UTC) :—] (]) 15:17, 15 January 2025 (UTC)
::Possibly ]. – ] (]) 06:00, 23 July 2021 (UTC)


== Requested move 4 January 2025 ==
== ref-duplicates-default detector flaw ==


<div class="boilerplate mw-archivedtalk" style="background-color: var(--background-color-success-subtle, #efe); color: var(--color-base, inherit); margin: 0; padding: 0 10px 0 10px; border: 1px dotted var(--border-color-subtle, #AAAAAA);"><!-- Template:RM top -->
This should emit a maintenance message but doesn't:
:''The following is a closed discussion of a ]. <span style="color: var(--color-error, red);">'''Please do not modify it.'''</span> Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a ] '''after''' discussing it on the closer's talk page. No further edits should be made to this discussion.''
:<code><nowiki>{{cite book |title=Title |author=Last, First |year=1953 |ref=CITEREFLast,_First1953}}</nowiki></code>
::{{cite book |title=Title |author=Last, First |year=1953 |ref=CITEREFLast,_First1953}}
The value assigned to {{para|ref}} is the same as is produced by {{tlx|sfnref}}:
:<code><nowiki>{{sfnref|Last, First|1953}}</nowiki></code>
::{{sfnref|Last, First|1953}}
But, the comparison between {{para|ref}} and the CITEREF ID created by ] is made before the newly created CITEREF ID has been anchor encoded: CITEREFLast, First1953 (space character instead of an underscore). Because the two values are different, no maintenance message.


The result of the move request was: '''not moved.''' <small>(])</small> ] 00:13, 12 January 2025 (UTC)
Fixed:
----
:<code><nowiki>{{cite book/new |title=Title |author=Last, First |year=1953 |ref=CITEREFLast,_First1953}}</nowiki></code>
::{{anchor|cite-book-maint}}{{cite book/new |title=Title |author=Last, First |year=1953 |ref=CITEREFLast,_First1953}}
And, when they really are different:
:<code><nowiki>{{cite book/new |title=Title |author=Last, First |year=1953 |ref=CITEREFLast,_First2020}}</nowiki></code>
::{{cite book/new |title=Title |author=Last, First |year=1953 |ref=CITEREFLast,_First2020}}
no maintenance message.


* ] → {{no redirect|Template:cite audiovisual media}}
—] (]) 17:59, 23 July 2021 (UTC)
* ] → {{no redirect|Template:cite audiovisual media notes}}
* ] → {{no redirect|Template:cite technical report}}
– The reason I'm requesting for these templates to be moved to their respective new titles is per ]; because template function should be clear from the template name, but redirects can be created to assist everyday use of very popular templates, because ]. ] (]; ]) 23:50, 4 January 2025 (UTC)


:References are used often and inline, which makes them noisy. These are some of the longer names. I would not support a move of any of the above. ] (]) 01:35, 5 January 2025 (UTC)
== Still an issue with book volumes ==
::The problem with the "redirects are cheap" argument is that redirected templates often lead to gnomes or bots replacing the templates with the redirect target (despite ]) and this leads to a lot of clutter on everyone's watchlists, and the resulting waste of human editors' attention is not so cheap. —] (]) 01:39, 5 January 2025 (UTC)
*'''Oppose''' per the arguments of Izno and David. -- ] (]) 01:58, 5 January 2025 (UTC)


:I'm unconvinced by the argument for this. I've never seen a confused misuse of {{tl|Cite AV media}}. I don't see that it's purpose is unclear. On the other hand I've seen {{tl|Cite journal}} used several times for people's diaries, but even that is an extremely rare issue. As other have said this will just result in the longer title being used, creating clutter for no practical effect. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 13:42, 5 January 2025 (UTC)
All these months later, and the issue with book volumes is still not being addressed. I understand why we don't want an explicit "volume" with a journal/magazine. I do '''not''' understand the issue with books. If Birds of North America has 13 volumes, displaying "Birds of North America. 2." does not, to most humans, clearly indicate that the 2 refers to volume 2 – particularly given that the average reader probably has '''no idea''' that there are 13 volumes in the set. Why can template not behave differently depending on whether the item is a book or a journal?! I know it's possible to do so, so somebody must have some rationale for why we don't. Please explain! ] (]) 20:25, 27 July 2021 (UTC)
*'''Oppose''' for ''AV'', don't care on ''tech''. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 16:00, 5 January 2025 (UTC)
:Inertia, basically.
*'''Oppose''' per {{noping|David Eppstein}} and {{noping|ActivelyDisinterested}}. Redirects are cheap until someone decides they all need to be bypassed, which people often choose to do en masse for some reason. And it's not clear how "AV media" could be confused for anything but "audio-visual media". I legitimately checked for possible confounders and came up empty.{{pb}}{{small|As an aside, I have also seen {{tl|Cite journal}} to cite a diary, but the more common cases of confusion – in steeply ascending order – are people trying to use {{tl|Cite document}} inappropriately to cite an online source, because it's a "document" (as if any written material isn't), and ] swapping in an incorrect template because it sees an isbn or something.}}{{pb}}{{tl|Cite tech report}} → {{tl|Cite technical report}} is less objectionable, but still seems undesirable. Again, what do people think "tech report" might mean apart from "technical report"? (I suppose "technology report" or "technique report" might be theoretically possible.) Good faith request, but unconvincing, and neglects drawbacks. ] (]) 17:00, 5 January 2025 (UTC)
:Previous discussions have yielded two proposed alternative styles for rendering {{para|volume}}, {{para|number}}/{{para|issue}} (only used with journals) and {{para|pages}}:
*'''Oppose''' for the AV templates, I think there is a good argument that AV is more obvious than audiovisual. '''Meh''' on tech to technical. ] (]) 02:46, 6 January 2025 (UTC)
:{| class="wikitable" style="text-align: center;"
*'''Oppose''' for the same reasons. The clarity benefit is marginal, outweighed by the (much) longer name, and the change is likely to cause unwanted churn. Looking at the ] disambiguation page, I don't see anything potentially confusing. Do we cite to Adult Video a lot? ] (]) 21:51, 7 January 2025 (UTC)
|-
! !! Journal !! Not journal !! Notes
|-
! Current
| {{nowrap|'''3''' (4): 12–56.}} || {{nowrap|'''3''', pp. 12–56.}}
| Long volume names are not bolded, but {{para|volume|vol. 3}} is considered an error.
|-
! {{nowrap|Proposal 1}}
| {{nowrap|'''3''' (4): 12–56.}} || {{nowrap|vol. 3, pp. 12–56.}} ||
|-
! Proposal 2
| colspan="2" | vol. 3, no. 4, pp. 12–56.
| Non-journals would not have a number or issue.
|}
:The current definition of "journal" is
:* {{tlx|cite journal}}, or
:* {{tlx|citation}}/{{tlx|cite map}}/{{tlx|cite interview}} with {{para|journal}} specified.
:I believe we should offer these alternatives for wider consideration. ] 09:37, 28 July 2021 (UTC)
::{{tlx|cite magazine}}?
::—] (]) 11:07, 28 July 2021 (UTC)
:::Adding magazine to the current row:
:::{| class="wikitable" style="text-align: center;"
|-
! !! journal !! magazine !! others
|-
! Current
| '''3''' (4): 12–56. || Vol. 3 no. 4. pp. 12–56. || '''3''', pp. 12–56.
|-
! Proposal 1
| '''3''' (4): 12–56. || colspan="2" | vol. 3, no. 4, pp. 12–56.
|-
! Proposal 2
| colspan="3" | vol. 3, no. 4, pp. 12–56.
|}
:::] 14:10, 28 July 2021 (UTC)
:::: I support the proposed standardization, but I think that the "scientific" nomenclature might still be desirable to have in heavily academic articles, therefore, I suggest to introduce a {{para|periodical-style}} or {{para|serial-style}} (or whatever) parameter to select the desired format if this is not the default already. (At a later stage, this could be supported by templates similar to the {{para|cs1-dates}} parameter of templates {{tl|use dmy dates}}/{{tl|use mdy dates}} to globally switch the display format for all citations in an article instead of having to use it in individual citations. I had some experimental code for this a year ago, but it would have to be adjusted to the current significantly changed code base.)
:::: I believe that having such an option to override the default would significantly raise community acceptance of a general change to a more standardized format - without it, I already see the next tumult emerging from militant proposers of one of these formats. With such a parameter implemented, we would still instantly have a consistent format in the majority of articles (the goal, we want to achieve), but allow editors to override the default to address special needs in specific citations (and articles). Best of both worlds.
:::: We could either use Proposal 1 as the default formats for the various templates and the parameter would allow to override the default and select the other format, or, we could choose Proposal 2 as the new general default format for all citation types and the parameter would have to be used in individual citations to switch to the scientific format.
:::: --] (]) 16:53, 28 July 2021 (UTC)
:::::I would be strongly against introducing another style configuration parameter. It would be another knob for people to twiddle and fight over, and we already have plenty of those clogging our watchlists. I would rather have a less-preferred option than that.
:::::As for raising acceptance, I don't think anyone out there loves bold volumes for books. The choice between the other two should be settled at an RFC. ] 17:11, 28 July 2021 (UTC)
::::::Design by rfc; how appalling.
::::::
::::::I too, am opposed to yet-another-style-parameter. {{tlx|cite journal}} renders the academic-journal-style. If you don't like that, use {{tlx|cite magazine}} or {{tlx|cite periodical}}. No need for special parameters.
::::::—] (]) 17:58, 28 July 2021 (UTC)
:::::::If we want people to be able to use cite magazine - then it needs to be added to Misplaced Pages:RefToolbar/2.0 - otherwise most editors will just use the templates which the tools force upon them.] (]) 18:29, 28 July 2021 (UTC)
::::::::You'll get no opposition from me but, good luck with that:
::::::::*{{slink|Wikipedia_talk:RefToolbar/Archive_2|Enhanced_toolbar_drop_down_templates}}
::::::::*{{slink|Wikipedia_talk:RefToolbar/Archive_2|Cite_magazine}}
::::::::*{{slink|Wikipedia_talk:RefToolbar/Archive_3|Request_for_Wikipedia_to_add_the_%22cite_magazine%22_citation_template_to_RefToolbar}}
::::::::*{{slink|Wikipedia_talk:RefToolbar/Archive_3|Request_for_Wikipedia_to_add_the_%22cite_magazine%22_citation_template_to_RefToolbar,_2021}}
::::::::Maybe, if enough editors make noise about it, someone will do the necessary (thankless) labor that will give them what they want. Perhaps you?
::::::::—] (]) 19:12, 28 July 2021 (UTC)
::::::::: Well, if as indicated by the discussions on the RefToolbar page, the tool is not being maintained, then it should be deactivated.] (]) 20:34, 28 July 2021 (UTC)
::::::::::I think that you are mistaken. Multiple javascript pages implement ]. The tool is mostly stable so there is little to do to it. Still, these parts of it were updated this year:
::::::::::*{{diff|MediaWiki:Gadget-refToolbar.js|1021366607|893115868|MediaWiki:Gadget-refToolbar.js}}
::::::::::*{{diff|MediaWiki:RefToolbar.js|1031411202|1031410067|MediaWiki:RefToolbar.js}}
::::::::::*{{diff|MediaWiki:RefToolbarMessages-en.js|1021363949|1017866393|MediaWiki:RefToolbarMessages-en.js}}
::::::::::*{{diff|MediaWiki:RefToolbarMessages-de.js|1021365493|554845010|MediaWiki:RefToolbarMessages-de.js}} – this is the English Misplaced Pages; why do we care about the German version here?
::::::::::As I said before, {{tq|if enough editors make noise about it, someone will do the necessary (thankless) labor that will give them what they want.}} If you want the change, recruit enough editors who also want the change, or, failing that, do it yourself.
::::::::::—] (]) 13:10, 29 July 2021 (UTC)
::::::: Design by RfC has proven to result in inconsistent, incoherent and typically less-powerful solutions. But forcing our own (typically great ;-) ideas onto the community is also no option. I mean, even here in this dedicated place where most of us have quite some experience with citation formats we often have vastly different views in regard to the best solution to a problem, clearly indicating that we have a diverse array of needs and therefore need flexibility to address them. That's why I think we should give the users some guidance (in form of reasonable defaults and good documentation) but also the necessary flexibility so that they can (if they need to) get the results they want to suit more special requirements. Otherwise, they will either complain about our templates or not use them. Both is unsatisfactory for them and us - and for the project as a whole.
::::::: I agree that in principal it would be enough to let {{tl|cite journal}} use the scientific format and {{tl|cite magazine}} the verbose format - basically that's a style-parameter in disguise. However, we have readers switching between these templates based on the nature of the periodical which would defeat the idea to choose the template based on the display format.
::::::: To sum it up, without a style-parameter to optionally override the default I could still support proposal 1, but not proposal 2.
::::::: --] (]) 02:05, 29 July 2021 (UTC)
::::::::{{replyto|Matthiaspaul}} {{tq|we have readers switching between these templates based on the nature of the periodical}} - I do that frequently ({{diff|Mansfield Railway|prev|1033208111|example}}), because I often find that some people are inappropriately using {{tlx|cite journal}}, {{tlx|cite news}} and {{tlx|cite web}} for magazines - for me, it's not a case of {{tq|choos the template based on the display format}} but of choosing the most appropriate template for the source. Each of these four has documentation that gives such advice:
::::::::*{{tlx|cite journal}} - academic and scientific papers published in bona fide journals
::::::::*{{tlx|cite magazine}} - articles in magazines and newsletters
::::::::*{{tlx|cite news}} - news articles in print, video, audio or web
::::::::*{{tlx|cite web}} - web sources that are not characterized by another CS1 template
::::::::I believe that the people who do not use {{tlx|cite magazine}} do so partly because they don't read the documentation, but mainly because it's not offered by the cite tool that they use (see post by Nigel Ish at 18:29, 28 July 2021 (UTC) and the reply by Trappist. So long as that remains the case, there will always be the need to amend the citation. --] &#x1f339; (]) 09:58, 29 July 2021 (UTC)
::::::::: Yeah, that's right. In fact, I'm doing this as well, but I'm reasonably happy with the difference in output formats between {{tl|cite journal}} and {{tl|cite magazine}}. I think we should continue to maintain this idea by choosing the most suitable ''parameter'' {{para|journal}} or {{para|magazine}} based on the ''nature'' of the periodical. Typically, we would use {{para|journal}} in {{tl|cite journal}} and {{para|magazine}} in {{tl|cite magazine}}, but following Trappist's comment to choose the template depending on the desired output format above, we would need to acknowledge that some people might have deliberately chosen to use {{tl|cite journal}} for {{para|magazine}} or {{tl|cite magazine}} for {{para|journal}}, and that, if this makes sense in a particular article rendering as a whole, we should leave this alone.
::::::::: --] (]) 10:14, 29 July 2021 (UTC)
::::::::::I think that what you are saying without actually voicing it is that {{tlx|cite journal}}, {{tlx|cite magazine}}, {{tlx|cite news}} all become redirects to the canonical template {{tlx|cite periodical}}. {{tld|cite periodical}} then renders volume/issue/page in the style dictated by the {{para|work}} parameter alias that is used in the template. That would likely be a significant challenge, mostly elsewhere than in ]. Some one or some series of bots would need to convert existing templates; tools like ] would need updating, etc. I rather like this idea but I foresee torches and pitch forks because en.wiki editors hate, hate, hate change...
::::::::::—] (]) 13:10, 29 July 2021 (UTC)
{{od}} I generally favor some form of Proposal 1. Let {{tl|cite journal}} use the shorter format. In {{tl|cite magazine}}, get the page number next to the volume and issue number. (Currently if a publisher is specified, it splits the volume/issue from the page number.) In {{tl|cite map}}, et al., tie the output to whether {{para|journal}} or {{para|magazine}} is used.{{pb}}For books though, I'd leave volume number next to title as a function of the title and retain the page number at the end, but otherwise add the "vol." text to the volume number for consistency. <span style="background:#006B54; padding:2px;">''']&nbsp;]'''</span> 22:46, 28 July 2021 (UTC)


<div style="padding-left: 1.6em; font-style: italic; border-top: 1px solid #a2a9b1; margin: 0.5em 0; padding-top: 0.5em">The discussion above is closed. <b style="color: var(--color-error, red);">Please do not modify it.</b> Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.</div><!-- from ] -->
Proposal 2 is the only scheme that makes sense for a project like Misplaced Pages. It is easily understandable by readers. The comma separator will have to be explained to editors since it violates style. This is because of the current rigid implementation of separators into "style 1" and "style 2", that carries no functional utility. ] (]) 23:40, 28 July 2021 (UTC)
</div><div style="clear:both;" class=></div>


== Is there a full list of all names that are considered 'generic'? ==
* '''Support Proposal 2''' Although I would be happy enough with Proposal 1. Agree with Imzadi about not splitting title from volume. I thought that the maintainers already turned this down. ] ] 23:49, 28 July 2021 (UTC)
**I'd personally prefer Proposal 2, but I think there would be too much inertia to completely move away from the abbreviated journal format. <span style="background:#006B54; padding:2px;">''']&nbsp;]'''</span> 00:16, 29 July 2021 (UTC)
*'''Prefer 1, but could live with 2'''. Status quo is unacceptable. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 01:22, 29 July 2021 (UTC)
*'''Support Proposal 1'''; I agree that the status quo doesn't work at all. And proposal 2 certainly "isn't the only one that makes sense", despite what an anonymous IP might assert. I'm assuming that if the "number" field is left blank, that parameter won't appear at all – i.e. vol. 2, pp. 12–56. ] (]) 10:28, 29 July 2021 (UTC)
::Are you saying that readers are better served by different (and convoluted) renditions of issue and volume depending on the use of a template they know nothing about? And why is an assertion by something called "MeegsC" any better on the face of it? ] (]) 11:16, 29 July 2021 (UTC)
*'''Prefer Proposal 2''' but also support Proposal 1 and strongly prefer either to the status quo. I think (based on no evidence, obvs) that the majority of editors who add citations to journal articles are probably happy with the academic shorthand since they are accustomed to it; hence the change will annoy them since style changes are always annoying. On the other hand, (still based on no evidence) our average reader probably hardly ever looks at an academic journal and is left to guess what the terse encoding means. I think we should prioritize clarity for the reader over the comfort of familiarity for the editor. This goes doubly for books where the shorthand is not, as far as I know, widely used. ] (]) 11:11, 29 July 2021 (UTC)
*'''Strong support for Proposal 1'''. This gives the output for journals and books I'd expect to see in scientific literature. Books use Volume or Vol, while journals just have the number, which may be in bold (most?), italics (a few) or with no emphasis. —&nbsp;<span style="font-family:Arial;background:#d6ffe6;border:solid 1px;border-radius:5px;box-shadow:darkcyan 0px 1px 1px;">&nbsp;]&nbsp;&#124;]&nbsp;</span> 12:17, 29 July 2021 (UTC)
*'''Proposal 2''' - is unambiguous, where proposal 1 leaves ambiguity and leaves you scrtching your head as to what the numbers mean. And the opportunity of mixing styles in a single article is not very good. ] (]) 12:50, 29 July 2021 (UTC)


I'm working on a script that searches through CS1 templates with generic names and provides a list of the most common first and last names that throw an error in the template. I couldn't find it ], but is there a copy of the test that templates run through so I can do it locally on my machine?
== Date validation error ==


Thanks ] <sub>''(], ])''</sub> 07:41, 8 January 2025 (UTC)
A recent edit ] introduced two "Lua error in Module:Citation/CS1/Date_validation at line 936: attempt to compare nil with number" at ]. The edit did not change the bibliography but it added "|cs1-dates=y" to give <code><nowiki>{{Use mdy dates|date=July 2020|cs1-dates=y}}</nowiki></code>. The problem is probably due to the letters in the two problematic {{tl|cite web}} instances: |date=August 9, 2010a and |date=August 17, 2010b and that should be fixed. However I'm wondering if some tweak to ] should occur, possibly to change <code>tonumber(t.y)</code> to <code>(tonumber(t.y)&nbsp;or&nbsp;0)</code> at line 936. ] (]) 07:22, 28 July 2021 (UTC)
:{{Re|EatingCarBatteries}} The full list is a mixture of exact titles such as <code>contact us</code> and LUA string-matching patterns such as <code>ews?oom</code>; search for <code>generic_titles</code> in ]. -- ] (]) 07:48, 8 January 2025 (UTC)
:Thanks for that suggestion. I implemented it. But, as soon as I did, I realized that a better solution is to strip the CITEREF disambiguator and let the process proceed. Doing that gives the desired rendering in the citation. It would seem that a maintenance message when this occurs might be appropriate.
::Thank you John! ] <sub>''(], ])''</sub> 07:50, 8 January 2025 (UTC)
:—] (]) 11:06, 28 July 2021 (UTC)
:: Thanks to you both for the hint and fix. I too think that a maintenance message might be useful.
:: However, thinking about those odd disambiguators in dates, I really think that we should slowly start to deprecate and find a better solution for them. Some while back I proposed to add this functionality to the {{para|ref}} parameter: ]
:: --] (]) 17:10, 28 July 2021 (UTC)


== error messaging == == Lack of orthogonality ==
This is a sidetrack off of {{slink|Help_talk:Citation_Style_1|summary_messaging_in_the_preview_warning_header}}. Over the past few days I have been reworking how error messaging is handled in the various modules (primarily ] and ] which emit the most errors). In the previous conversation, I suggested that it would be a good thing to move all error messages to the end of the citation. As it is right now, some error messages are made part of the template's rendering which, to me, looks bad.


There are some CS1 parameters that are not allowed in templates where they make sense and would be useful. An example is {{tl|cite journal}}. Journal articles are often available on the ] and often have numbered sections, but {{para|section}} and {{para|section-link}} are not available, although there is a hack ({{para|at|''link''}}). -- ] (]) 15:02, 8 January 2025 (UTC)
The live module has a table called <code>z.message_tail</code> which holds all of the error messages that are rendered following the citation. To load that table, it is necessary for the code to call <code>]</code> in ]. That function returns the error message as a plain message or as a message wrapped in {{tag|span}} tags appropriately classed for hidden or visible error messages. The function that called <code>set_message()</code> then has to use the returned message as an appendage on a parameter's data or as a replacement for it; or, the function must insert the returned message into the <code>z.message_tail</code> table. Moving all error messages to the end of the citation means that <code>set_message()</code> can insert the message in <code>z.message_tail</code> as part of its normal operation and so the code is simpler and more consistent.


:@] Do the sections have different authors? I thought that was the purpose of section/chapter, to cite different pieces by different people within the same book, ] (]) 15:23, 8 January 2025 (UTC)
I have done that. The change primarily impacts ] and ] but also impacts ]. I have renamed <code>z.message_tail</code> to <code>z.error_msgs_t</code> so that the name reflects its content.
::I'm not aware of anything that ties author with in-source locations in general, and with {{para|section}} in particular. -- ] (]) 19:17, 8 January 2025 (UTC)
:{{para|title}} should be used for the article in the journal, so is this about a section of the article without page numbers? Do you have an example? If you're referencing part of an article without page numbers but numbered sections then {{para|at}} seems appropriate. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 19:54, 8 January 2025 (UTC)
::In this case there are no page numbers, but it wouldn't help if the were, since {{para|at}}, {{para|page}} and {{para|pages}} are mutually exclusive. In this case I am using
::<blockquote><code><nowiki> {{cite journal | journal = Communications of the ACM | volume = 6 | issue = 1 | date = January 1963 | title = Revised Report on the Algorithmic Language Algol 60 | editor = Peter Naur | editor-link = Peter Naur | author1 = J.W. Backus | author-link1 = John Backus | author2 = F.L. Bauer | author-link2 = Friedrich L. Bauer | author3 = J.Green | author4 = C. Katz | author5 = J. McCarthy | author-link5 = John McCarthy (computer scientist) | author6 = P. Naur | author-link6 = Peter Naur | author7 = A.J. Perlis | author-link7 = Alan Perlis | author8 = H. Rutishauser | author-link8 = Heinz Rutishauser | author9 = K. Samuelson | author10 = B. Vauquois | author-link10 = Bernard Vauquois | author11 = J.H. Wegstein | author-link11 = Joseph Henry Wegstein | author12 = A. van Wijngaarden | author-link12 = Adriaan van Wijngaarden | author13 = M. Woodger | author-link13 = Mike Woodger | at = 3.2.4. Standard functions | url = https://doi.org/10.1145/366193.366201 | publisher = Association for Computing Machinery | doi = 10.1145/366193.366201 | s2cid = 7853511 }} </nowiki></code></blockquote> which renders as {{cite journal
| journal = Communications of the ACM
| volume = 6
| issue = 1
| date = January 1963
| title = Revised Report on the Algorithmic Language Algol 60
| editor = Peter Naur
| editor-link = Peter Naur
| author1 = J.W. Backus
| author-link1 = John Backus
| author2 = F.L. Bauer
| author-link2 = Friedrich L. Bauer
| author3 = J.Green
| author4 = C. Katz
| author5 = J. McCarthy
| author-link5 = John McCarthy (computer scientist)
| author6 = P. Naur
| author-link6 = Peter Naur
| author7 = A.J. Perlis
| author-link7 = Alan Perlis
| author8 = H. Rutishauser
| author-link8 = Heinz Rutishauser
| author9 = K. Samuelson
| author10 = B. Vauquois
| author-link10 = Bernard Vauquois
| author11 = J.H. Wegstein
| author-link11 = Joseph Henry Wegstein
| author12 = A. van Wijngaarden
| author-link12 = Adriaan van Wijngaarden
| author13 = M. Woodger
| author-link13 = Mike Woodger
| at = 3.2.4. Standard functions
| url = https://doi.org/10.1145/366193.366201
| publisher = Association for Computing Machinery
| doi = 10.1145/366193.366201
| s2cid = 7853511
}}. -- ] (]) 20:58, 8 January 2025 (UTC)
:::That article has page numbers though? {{para|pages|1–17}} (section 3.2.4 is on p. 6). Also remember {{para|doi-access|free}}. I could see wanting a {{para|section}} for online-only journals where there is no true pagination, but {{para|at}} does seem to be doing an adequate job. ] (]) 21:44, 8 January 2025 (UTC)
::::Isn't this the purpose of {{para|at}}, for when a page number is inappropriate or insufficient? Section is even listed as an example usage in the documentation. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 00:56, 9 January 2025 (UTC)


== Strange placement of others in journal citation ==
As part of this I have spent a bit of time refining the assembly of the various parts of the finished citation (the citation itself, the anchor ID and the css classes in the {{tag|cite|o}} tag, the metadata, the error messages, the maintenance messages, and the categories (roughly the 100ish lines of code beginning at about line 3844 of Module:Citation/CS1/sandbox). This includes the error and maintenance summaries and the error message prefixes discussed in the previous conversation, sorting of error and maintenance messages. Empty citations will no longer produce metadata because why bother:
:<code><nowiki>{{cite book}}</nowiki></code>
::{{cite book}}
:::{{code|lang=html|{{cite book}}}}
:<code><nowiki>{{cite book/new}}</nowiki></code>
::{{cite book/new}}
:::{{code|lang=html|{{cite book/new}}}}
—] (]) 22:02, 28 July 2021 (UTC)


"Others", in a journal citation, is placed between the issue number and the page numbers. Example (from ]):
:I wonder if some kind of "error framing" could be done (at least in preview) to make it easier for editors to spot the errors. Mockup:
*<nowiki>{{citation
:<code><nowiki>{{cite journal |last=Smith |first=John |date=9999 |title=Title of Things |journal=Journal of Stuff |volume=Vol. 34 |issue=1 |pages=23–45 |doi=10.4321/3210 |pmid=012345}}</nowiki></code>
| last = Bartholdi | first = Laurent
:: {{anchor|cite-journal-error}}Smith, John (<span class="{{{span-class|cleanup-needed-content}}}" style="padding-left:0.1em; padding-right:0.1em; color:#595959; border:1px solid red;">9999</span>). "Title of Things". ''Journal of Stuff.'' <span class="{{{span-class|cleanup-needed-content}}}" style="padding-left:0.1em; padding-right:0.1em; color:#595959; border:1px solid red;">Vol. 34</span> (1): 23–45. ]:. ] . {{red|{{tl|cite journal}}: <code>{{!}}volume{{=}}</code> has extra text (]); Check date values in: <code>{{!}}date{{=}}</code> (])}}
| others = with an appendix by Dawid Kielak
: I assume it would complicate the code too much but still wanted to mention it to spread the idea.
| arxiv = 1605.09133
: --] (]) 00:59, 29 July 2021 (UTC)
| doi = 10.4171/JEMS/900
: In your example above
| issue = 10
:: <code><nowiki><span class="cs1-visible-error citation-comment">*</span><span class="cs1-visible-error citation-comment">*</span></nowiki></code>
| journal = Journal of the European Mathematical Society (JEMS)
: the two message spans could be combined into one:
| mr = 3994103
:: <code><nowiki><span class="cs1-visible-error citation-comment">**</span></nowiki></code>
| pages = 3191–3197
: to reduce the size of the resulting HTML. However, I understand that this might not always be possible if they are interwoven with hidden messages, so I'm mentioning this just in case you see an easy way to do it anyway.
| title = Amenability of groups is characterized by Myhill's theorem
:--] (]) 12:07, 1 August 2021 (UTC)
| volume = 21
::Yeah, they could be combined but it is much easier in the code to have them as separate spans because we can't always and forever know that the first error message after the {{error-small|&#123;{]}&#125;}} prefix will be a visible error message. However, that does highlight a flaw in the prefix design; if all error messages emitted by a citation are hidden, then the prefix should also be hidden. As it is, it is always visible. I'll think about that ...
| year = 2019}}</nowiki>
::—] (]) 15:10, 1 August 2021 (UTC)
*{{citation
:::Citations emitting only hidden error messages will also hide the error message prefix:
| last = Bartholdi | first = Laurent
::::<code><nowiki>{{cite journal/new |title=Title}}</nowiki></code>
| others = with an appendix by Dawid Kielak
:::::{{cite journal/new |title=Title}}
| arxiv = 1605.09133
::::::{{code|lang=html|{{cite journal/new |title=Title}}}}
| doi = 10.4171/JEMS/900
:::—] (]) 16:29, 1 August 2021 (UTC)
| issue = 10
:Do not emit duplicate IDs in any case. Our objective is to comply with HTML and that does not. Thanks. I'll revert the lot of the sandbox if that remains in the code. The supposed gain is not worth that. ] (]) 14:12, 3 August 2021 (UTC)
| journal = Journal of the European Mathematical Society (JEMS)
::Presumably this is related to discussion that occurred at {{slink|Help talk:Citation Style 1|summary messaging in the preview warning header}} regarding links from the preview warning messages to citations elsewhere in the previewed article. Where were you and your objections when we first discussed this? You were around and even {{diff|Help_talk%3ACitation_Style_1|1036262099|1036257141|edited this page}} during the period of that conversation. Instead of swooping in with drama and threats after the fact, it would have been better for you to participate in the discussion as it was on-going.
| mr = 3994103
::
| pages = 3191–3197
::The point is taken and I have removed the spans and go-to links.
| title = Amenability of groups is characterized by Myhill's theorem
::—] (]) 15:37, 3 August 2021 (UTC)
| volume = 21
:::Busy trying not to care about Matthias' outlandish requests? :) ] (]) 15:51, 3 August 2021 (UTC)
| year = 2019}}
:::: Not funny, and not outlandish at all. It's all about user-friendliness and usability.
*Manually substed: Bartholdi, Laurent (2019), "Amenability of groups is characterized by Myhill's theorem", ''Journal of the European Mathematical Society (JEMS)'', '''21''' (10), with an appendix by Dawid Kielak: 3191–3197, ]:]&nbsp;<span style="position:relative; top: -2px;">]</span>, {{#if:{{#invoke:string2|startswith|1=10.4171/JEMS/900|2=10.}}|{{Catalog lookup link|10.4171/JEMS/900|article-suffix={{#if:||]:}}|link-prefix=https://doi.org/ |url-access1={{#ifeq:|free|free}}}}|]<span class="error">Error: Bad DOI specified!</span>}}, ]{{Catalog lookup link|3994103|||||||||link-prefix=https://mathscinet.ams.org/mathscinet-getitem?mr=|list-separator=,&#32;MR|list-leadout=|leadout-postfix=&#32;MR}}
:::: The anchors/spans are added only if there is a problem in a citation. So articles without problematic citations will never have them. Also, above I proposed to add them only in preview in order to not invalidate HTML in normal article view. Even web designers who otherwise care about good HTML often deliberately ignore trivialities like this, in particular if it is known to not cause any harm.
*Sandbox: {{citation/sandbox
:::: Further, all articles with citations lacking disambiguation contain identical anchors and thereby contain invalid HTML - and not only in preview or with actual citation errors, but in normal article view for as long until the disambiguation gets fixed. And in this case, a doubled anchor actually causes "harm" as it makes subsequent citations "unreachable". When we discussed this when making {{para|ref|harv}} the default, we decided to ignore this because the benefit far outweights the problem. Nobody complained about it.
| last = Bartholdi | first = Laurent
:::: We should do the same here as well, in particular as in this case the doubled anchors do not create any practical problem for browsers at all and do only exist in preview and when citations have errors, anyway. So, ignoring the "no double anchors" doctrine would be a valid engineering decision. If we do not, we should immediately switch off harv-style anchors as well.
| others = with an appendix by Dawid Kielak
:::: --] (]) 17:28, 3 August 2021 (UTC)
| arxiv = 1605.09133
| doi = 10.4171/JEMS/900
| issue = 10
| journal = Journal of the European Mathematical Society (JEMS)
| mr = 3994103
| pages = 3191–3197
| title = Amenability of groups is characterized by Myhill's theorem
| volume = 21
| year = 2019}}
This strikes me as unlikely to be the best place to put it. In this example, the arXiv version lists both authors. The journal article landing page puts the "with an appendix by..." text into a subtitle of the article title, as does the BibTeX that I get from doi.org. The ] BibTeX data which I used to generate this citation instead separates it out into a note= field of the BibTeX. ] just omits Kielak from the metadata altogether. I think others= should be the correct way of handling this, if only it produced reasonable formatting. —] (]) 04:48, 9 January 2025 (UTC)
:Why not just put the "With an appendix ..." text in the title, as recommended at the source? – ] (]) 05:30, 9 January 2025 (UTC)
::Putting aside how to get this specific citation formatted in a way that doesn't look stupid, maybe we could make the others= parameter useful instead of having to use hacks to work around its bad behavior? My strong suspicion is that using hacks to work around bad alternatives was also the motivation for putting the additional contributor in the subtitle rather than somewhere more principled. —] (]) 06:09, 9 January 2025 (UTC)
:This is more-or-less the same issue as {{slink|Help_talk:Citation_Style_1|Placement_of_"translator"/"page"_fields|nopage=y}} above.
:—] (]) 15:44, 9 January 2025 (UTC)


=== HTML structure of a citation === == How to cite one of them ==
I have three articles all published in the same publication (The Daily Telegraph), in year (1923) and the same month (January), but on different days. The question is how to cite one of them using sfn.
However, there is a related, more general issue. This is unrelated to preview messages and the restructuring of error messages, but since we are talking about the structure of the HTML for a citation, I'm bringing this up anyway.


*{{cite news |last=Smith|first=Graftoon Elliot|title=The Tomb of Tutankhamen |newspaper=] |date=1923-01-19|pp=9-10}}
The general structure of a citation (in the sandbox, that is, including the preview message) is as follows:
*{{cite news |last=Smith|first=Graftoon Elliot|title=The Tomb of Tutankhamen |newspaper=] |date=1923-01-23|pp=9}}
: <code><nowiki><span id="cite-book-error"></span><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite><span title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=*" class="Z3988"></span></nowiki></code>
*{{cite news |last=Smith|first=Graftoon Elliot|title=The Tomb of Tutankhamen |newspaper=] |date=1923-01-25|pp=9}}
:: <span id="cite-book-error"></span><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite><span title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=*" class="Z3988"></span>
Some browers and tools allow to highlight the scope of elements and navigate from element to element or otherwise take advantage of knowing the scope of data elements (screenreaders and browsing assistance tools, web development tools, web harvesters). Right now, they see a citation as an empty preview error span, the actual citation with optional messages appended, followed by the COinS info.


--] (]) 10:06, 10 January 2025 (UTC)
This is somewhat suboptimal. The preview error span should span over the whole citation including messages and COinS data.
:Text to be proven,{{sfn|Smith|1923a}} and more,{{sfn|Smith|1923b}} and even more.{{sfn|Smith|1923c}}
{{Reflist-talk}}
:'''Sources'''
:*{{cite news |last=Smith|first=Graftoon Elliot|title=The Tomb of Tutankhamen |newspaper=] |date=19 January 1923a|pp=9-10}}
:*{{cite news |last=Smith|first=Graftoon Elliot|title=The Tomb of Tutankhamen |newspaper=The Daily Telegraph |date=19 January 1923b|pp=9}}
:*{{cite news |last=Smith|first=Graftoon Elliot|title=The Tomb of Tutankhamen |newspaper=The Daily Telegraph |date=19 January 1923c|pp=9}}
:HTH -- ] (]) 12:25, 10 January 2025 (UTC)


== How to cite an unsigned article ==
In addition to this, the COinS span should ideally span over the citation and messages as well in order to declare the context of the COinS data. This would result in the following nested structure:
For example
: <code><nowiki><span id="cite-book-error"><span title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=*" class="Z3988"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite></span></span></nowiki></code>
*{{cite news |title=Towards Balkan Peace|newspaper=] |date=1925-09-22|pp=15}}
:: <span id="cite-book-error"><span title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=*" class="Z3988"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite></span></span>
The only adverse effect of this rearrangement I can see right now is that the browser will now display the COinS data as tooltip, which might be confusing. So, if the contents of the COinS span really ''must'' be empty, it might be possible to do it the other way around and embed it into the cite element. The preview error span could still wrap around both:
: <code><nowiki><span id="cite-book-error"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages<span title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=*" class="Z3988"></span></cite></span></nowiki></code>
:: <span id="cite-book-error"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages<span title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=*" class="Z3988"></span></cite></span>
In both of these two cases, the proper extraction of COinS data by existing tools would have to be tested, because in the examples I could find on the web they always suggest that this is an empty element (or only containing a space) immediately following the citation.
At least wrapping the preview span around both of them will work regardlessly:
: <code><nowiki><span id="cite-book-error"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite><span title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=*" class="Z3988"></span></span></nowiki></code>
: <span id="cite-book-error"><cite id="CITEREF*" class="citation book cs1">Citation with appended messages</cite><span title="ctx_ver=Z39.88-2004&amp;rft_val_fmt=*" class="Z3988"></span></span>
--] (]) 12:07, 1 August 2021 (UTC)
:Umm, the general structure of a sandbox citation is not quite what you say it is. See for example this:
::<code><nowiki>{{cite book/new |title=Title |access-date=2021-08-01}}</nowiki></code>
:::{{cite book/new |title=Title |access-date=2021-08-01}}
::::<syntaxhighlight lang="html"><templatestyles src="Module:Citation/CS1/sandbox/styles.css"></templatestyles><span id="cite-book-error"></span><cite class="citation book cs1">''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rfr_id=info%3Asid%2Fen.wikipedia.org%3ABlue" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{]}}</code>: </span><span class="cs1-visible-error citation-comment"><code class="cs1-code">&#124;access-date=</code> requires <code class="cs1-code">&#124;url=</code> (])</span>]</syntaxhighlight>
:so what we have is:
::{{tag|templatestyles|content=}}{{tag|span|attribs=id=&lt;{{var|cite book error anchor}}>|content=}}{{tag|cite|content=The Citation}}{{tag|span|attribs=&lt;{{var|COinS metadata}}>|content=}}<code>&lt;{{var|messaging}}></code><code>&lt;{{var|categories}}></code>
:I created empty error-anchor and maint-anchor spans because that is how {{tlx|anchor}} implements anchors. It is easy enough to wrap the entire rendering from {{tag|cite|o}} to the end of the last category in the error-anchor and maint-anchor spans. If we did that, we could add an undefined class so that editors can style the anchored citations; don't know how beneficial that would be ...
:
:I am unwilling to change how the metadata span is handled without someone having conducted extensive research to prove that your suggestion does not break external tools. Apparently metadata works now so ain't-broke-don't-fix applies.
:—] (]) 14:55, 1 August 2021 (UTC)
::Error-anchor and maint-anchors now wrapp entire citation from {{tag|cite|o}} to the end of the last category:
:::<code><nowiki>{{cite book/new |title=Title |access-date=2021-08-01 |authors=Authors}}</nowiki></code>
::::{{cite book/new |title=Title |access-date=2021-08-01 |authors=Authors}}
:::::{{code|lang=html|{{cite book/new |title=Title |access-date=2021-08-01 |authors=Authors}}}}
::—] (]) 16:19, 1 August 2021 (UTC)
::: Looks good, thanks.
::: I agree, moving the COinS info will require more research in regard to what works with existing tools, and what might not. That's why I was bringing this up.
::: Unfortunately, the standard itself is not very clear about it, so implementations might vary in regard to what they expect. As far as I understand it, there should be no inherent dependency of the COinS span from <code><nowiki><cite></nowiki></code>, therefore from the viewpoint of data extraction, it should not matter, if one gets embedded into the other.
::: Regarding the contents of the COinS span, they suggest to use a space in environments where an empty span would be removed in some HTML optimization processes. From this we can at least derive that the span does not need to be empty.
::: They also talk about the possibility to place some default text in there, leaving it open to interpretation if COinS-aware browser plug-ins are meant to ''replace'' this text with some link/icon to a pop-up etc., or if they are meant to ''insert'' such links/icon after the text. If we find a browser plug-in which would replace the text, we obviously cannot place the citation there, otherwise this would be the most-"natural" place for it. It would be interesting to learn from the community which tools they use and how they behave on the following two test citations:
::: Manually crafted citation with <code><nowiki><cite></nowiki></code> inside COinS span:
:::: <span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.btitle=Statement+of+Principles&rft.place=Paris%2C+France&rft.date=1961-10-18&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"><cite class="citation conference cs1">]. The International Conference on Cataloguing Principles (CCP). Paris, France. 1961-10-18 .</cite></span>
::: Manually crafted citation with COinS span inside <code><nowiki><cite></nowiki></code>:
:::: <cite class="citation conference cs1">]. The International Conference on Cataloguing Principles (CCP). Paris, France. 1961-10-18 .<span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=conference&rft.btitle=Statement+of+Principles&rft.place=Paris%2C+France&rft.date=1961-10-18&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span></cite>
::: --] (]) 11:18, 3 August 2021 (UTC)
::::Given that the COINS span outputs its content as a title, putting cite inside the span is a non-starter. Everything internal will have a hover over title completely meaningless to users and defeating the other over hovers we have (links predominantly). ] (]) 14:10, 3 August 2021 (UTC)


--] (]) 11:17, 10 January 2025 (UTC)
== Visual Editor claims that usurped is not expected in the url-status field ==


Lets see:
Whenever I am trying to switch a deadlink citation to an archive link, I sometimes need to mark it as usurped. But it seems that the only values that the Visual Editor expects are "live" (the default) and "dead". Adding usurped or unfit gives the warning "
This is not one of the suggested values and may not work with the template". Can they be added as legitimate values please. By experimentation, they do actually work as expected if added, but the message would have you think otherwise. Thanks ] (]) 05:49, 30 July 2021 (UTC)
:That is not a cs1|2 issue but rather is an issue with VE's template data. You are free to edit the template data to add <code>usurped</code> and <code>unfit</code>. There are 27 cs1|2 templates so you should check and update all of them.
:—] (]) 12:01, 30 July 2021 (UTC)
:I've added the two to cite web as well as all four to cite news. Others may make similar edits for other templates. ] (]) 12:52, 30 July 2021 (UTC)


{{sfn|The Times|1925-09-22}}
== Identifier-specific template EBSCOhost ==
Moved thread to ].
--] (]) 22:29, 31 July 2021 (UTC)


--] (]) 11:29, 10 January 2025 (UTC)
== display-authors bug ==
If you specify just one <tt>author</tt> and then invoke <tt>display-authors=1</tt>, you get an error. You need to specify an <tt>author2</tt> to make it go away (even though <tt>author2</tt> isn't displayed!). ] (]) 15:19, 4 August 2021 (UTC)
:You will get the same error when you have two authors and set {{para|display-authors|2}}:
::<code><nowiki>{{cite book |title=Title |author=First Author |author2=Second Author |display-authors=2}}</nowiki></code>
:::{{cite book |title=Title |author=First Author |author2=Second Author |display-authors=2}}
:It is supposed to work that way. When there are only two authors, setting {{para|display-authors|2}} becomes meaningless. When there are more than two authors and you only want to display one of their names, then {{para|display-authors|1}} will suppress display of the second author name and add et al. to the rendering:
::<code><nowiki>{{cite book |title=Title |author=First Author |author2=Second Author |display-authors=1}}</nowiki></code>
:::{{cite book |title=Title |author=First Author |author2=Second Author |display-authors=1}}
:When the template has only one of the two authors, set {{para|display-authors|etal}} to indicate that the work has more authors whose names are not shown:
::<code><nowiki>{{cite book |title=Title |author=First Author |display-authors=etal}}</nowiki></code>
:::{{cite book |title=Title |author=First Author |display-authors=etal}}
:—] (]) 15:28, 4 August 2021 (UTC)
:The (help) link provides the three paths to fixing this error. ] (]) 16:14, 4 August 2021 (UTC)
::As an aside - the Harv warning has changed to be bold from a brown-ish colour in the last couple of days - any idea what has changed? ] (]) 13:00, 6 August 2021 (UTC)
:::There are two warnings for SFN. One set is emitted by the SFN module. Those are in red. The other set are from whichever of the three-ish scripts that detect bad SFNs. Those are the brown-ish color. While they may have changed in shade or something, the latter has always been that color. ] (]) 13:36, 6 August 2021 (UTC)
:::
:::My script has not changed and shows the warning messages for the above citations like this:
::::{{code|lang=html|1=<span class=warning style="font-size:100%">Harv warning: There is no link pointing to this citation. The anchor is named CITEREFFirst_Author.</span>}}
:::::<span class=warning style="font-size:100%">Harv warning: There is no link pointing to this citation. The anchor is named CITEREFFirst_Author.</span>
:::But isn't <code>class=warning</code> going away? If it is, I should change the warning markup to:
::::{{code|lang=html|1=<span style="color:#ac6600">Harv warning: There is no link pointing to this citation. The anchor is named CITEREFFirst_Author.</span>}}
:::::<span style="color:#ac6600">Harv warning: There is no link pointing to this citation. The anchor is named CITEREFFirst_Author.</span>
:::—] (]) 14:12, 6 August 2021 (UTC)
::::You might consider emitting a class still so people can customize the color, but sure. ] (]) 14:55, 6 August 2021 (UTC)
:::I am using ] ] (]) 19:15, 6 August 2021 (UTC)
::::No changes to that script since {{diff|User:Ucucha/HarvErrors.js|1013243348|816194020|this edit}} in March 2021. Yesterday was ], there is some small discussion about skins at ] about monobook skin stuff; related?
::::—] (]) 19:45, 6 August 2021 (UTC)
:::::It could be but not clear from that what the changes would be. Looking at ] seems to imply some changes needed in preferences, but cannot locate checkbox "Enable responsive MonoBook design". I have tried unticking "Enable responsive mode" but that makes no difference. ] (]) 20:18, 6 August 2021 (UTC)
::::::{{replyto|Keith D}} "Enable responsive MonoBook design" is no longer there. It was at {{myprefs|Appearance}}, between "{{int:globalcssjs-custom-css-js}}" and "{{int:prefs-reading}}". I think it was removed when "{{int:prefs-skin-responsive}}" was added a little higher up. --] &#x1f339; (]) 22:41, 6 August 2021 (UTC)
:::::::Yes, these preferences were flipped; this was in either last week's tech news or the week before's. ] (]) 17:41, 8 August 2021 (UTC)


{{sfn|The Times|1925}}
== when |archive-url= is broken ==


--] (]) 11:30, 10 January 2025 (UTC)
In normal display mode (what readers see), broken archive urls are ignored except that the module emits an error message. When editors view the same article in preview mode, and when the archive url is an archive.org url, the module uses a modified form of the archive url. The purpose of that is to enable editors to see archive.org's calendar view so that they might choose the url of an appropriate snapshot to replace the malformed archive url in the template. When {{para|archive-url}} holds a malformed archive url, the live module truncates the timestamp from 14 to 6 digits and appends a splat (<code>*</code>). That used to work. So, I have tweaked the code so that the new preview-mode archive url uses the first six (YYYYMM) or four (YYYY) digits of the timestamp, zero-fills to 14 digits, and then appends the splat. To see this in action, you must edit this section (or page) and preview.
{{Reflist-talk}}
{{cite compare |mode=web |url=http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html |archive-url=https://web.archive.org/web/20170614/http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html |archive-date=2017-06-14 |title=Ask Hal: Frequently Asked Questions to the Blue Sky Rangers |publisher=Intellivision Productions |access-date=November 3, 2008}}
:Text to be proven.{{sfn|Anon.|1925}}
In the above examples, the live version links to a "We're sorry — something's gone wrong" page while the sandbox links to the calendar view.
{{Reflist-talk}}

:'''Sources'''
—] (]) 19:38, 5 August 2021 (UTC)
*{{cite news|author=Anon.|title=Towards Balkan Peace|newspaper=] |date=1925-09-22|pp=15}}
: Thanks for making this feature work again. (For those interested in the background of this feature, see: ])
:HTH -- ] (]) 12:28, 10 January 2025 (UTC)
: However, the "*"-wildcard still seems to work fine with 0-, 4- and 8-digit timecodes, so the zero-filling does not appear to be necessary in all cases:
:* https://web.archive.org/web/*/http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html works
:* https://web.archive.org/web/2017*/http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html works
:* https://web.archive.org/web/201706*/http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html now fails
:* https://web.archive.org/web/20170614*/http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html works (but zero-fills automatically)
: BTW, if you truncate the archive URL to {{para|archive-url|https://web.archive.org/web/20170614}} or shorter, the new implementation throws a Lua error in "Module:Citation/CS1/sandbox at line 2379: attempt to index local 'timestamp' (a nil value)."
: The utility of the feature could be further improved if we would allow it to accept {{para|archive-url|http://web.archive.org/web/}} as an entry shortcut forcing it to take the URL from the {{para|url}} parameter and optionally the timestamp from the {{para|archive-date}} parameter to automatically form archive URLs like <code>https://web.archive.org/web/*/http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html</code> or <code>https://web.archive.org/web/20170614*/http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html</code> for the error message, so that editors could utilize our preview to select or create a snapshot from/at archive.org with a minimum amount of keystrokes.
: --] (]) 02:55, 6 August 2021 (UTC)
::Fixed the script error:
<div style="margin-left:4.8em">{{cite compare |mode=web |url=http://www.intellivisionlives.com/bluesky/people/askhal/askhal.html |archive-url=https://web.archive.org/web/20170614 |archive-date=2017-06-14 |title=Ask Hal: Frequently Asked Questions to the Blue Sky Rangers |publisher=Intellivision Productions |access-date=November 3, 2008}}</div>
::—] (]) 11:39, 6 August 2021 (UTC)

==Cite magazine – why upper case Vol.?==
Why does {{T|Cite magazine}} emit volume in upper case: <nowiki>{{cite magazine|title=Some title|magazine=Some Magazine|volume=17}}</nowiki> -> {{cite magazine|title=Some title|magazine=Some Magazine|volume=17}} ? -- ] (]) 09:23, 7 August 2021 (UTC)
:Because it follows a period. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 10:39, 7 August 2021 (UTC)
::OK. Sorry if I'm a pest, but why then is page in lower case? — {{cite magazine|title=Some title|magazine=Some Magazine|volume=17|page=18}} -- ] (]) 13:36, 7 August 2021 (UTC)
:::I don't think you're a pest, but the odds against getting a coherent answer to that are astronomical. Headbomb is right, of course, as you are in your question. ] (]) 14:16, 7 August 2021 (UTC)
:::
:::Why do I hear ] in my head when he says, while singing "]":
::::"You may ask, how did this tradition start?
::::I'll tell you – I don't know. But it's a tradition..."
:::—] (]) 16:10, 7 August 2021 (UTC)

== Markup in titles ==

Peeking at ], I see it doesn't include fields like "title". I'm in the process of cleaning up lots of HTML entities (which shouldn't be in these fields either), and I've seen lots of instances of double single quotes (<nowiki>''...''</nowiki>) in the title field. On Misplaced Pages, this will make italics, but apparently italics are not allowed in COinS fields? Is this something that should be systematically fixed? -- ] (]) 07:48, 9 August 2021 (UTC)
:If the title of an article includes a ] or the name of a genus then by convention this is placed in italics (using double single quotes). - ] (]) 08:55, 9 August 2021 (UTC)
::Absolutely, and anything else would be utterly wrong and strongly resisted by those who edit organism articles. ] (]) 09:32, 9 August 2021 (UTC)
:::Is this about Misplaced Pages article titles or the title field of a citation? If it is the latter, then it crashes into one of the CS1 non-sensical flaws, the fact that {{para|title}} may be the source (as in {{tl|cite book}}), or a location within the source (as in {{tl|cite journal}}). This is pertinent, because the title value is auto-formatted differently. In the case of title=source it would be in italics. Including italics markup, would cause the affected text to display in straight type. Because of the fundamental error of mis-defined and mis-applied parameters, more convoluted acrobatics have to be employed. Good luck! ] (]) 11:48, 9 August 2021 (UTC)
:Italic wikimarkup is permitted where it is appropriate to use it. Bold markup is also allowed though I wonder if '''bold''' makes much sense in the context of a citation's title. This (times out) finds some use of bold markup in {{para|title}}. We might create a maintenance category to track bold markup in {{para|title}}, {{para|chapter}} and aliases. Such categorization must be mindful of <code><nowiki>'''s</nowiki> </code> (possessive form of italicized text).
:—] (]) 11:13, 9 August 2021 (UTC)
::I thought kerning was handled in {{para|title}}. ] (]) 11:48, 9 August 2021 (UTC)
:::In titles that will be rendered in quotations ({{tlx|cite web}}, {{tlx|cite journal}}, etc), cs1|2 adds kerning when the title text has leading or trailing quote marks
::::<code><nowiki>{{cite periodical |title='leading' quote and trailing "quote" |periodical=Periodical}}</nowiki></code>
:::::{{cite periodical |title='leading' quote and trailing "quote" |periodical=Periodical}}
:::—] (]) 12:01, 9 August 2021 (UTC)
::::Ok, this is the most basic case. Is there a problem with inserting a hair-space in code to account for others?
::::Also, I would include typographic emphasis in {{para|title}} if that is how the source is formatted, only as a help for the reader. There may be a minority of readers for whom anything but exact representation may cause confusion. However this additional emphasis should not be a requirement, just as (generally) adherence to case is not a requirement. There is already the semantic emphasis built in to the presentation of the work argument, and the occasional emphasis on {{para|volume}} (depending on day of the week, or something). This should be enough to attract readers' attention to the most important information in the citation. But there may be another minority of readers for whom any added emphasis may confuse. ] (]) 12:16, 9 August 2021 (UTC)
::Triple quotation mark in such a case will cause an error anyway as it will bold the rest of the sentence, not close the italic. ] (]) 13:16, 9 August 2021 (UTC)
:::Umm, nope:
::::<code><nowiki>{{cite periodical |title=''Possessive italics'''s in title |periodical=Periodical}} and some trailing text</nowiki></code>
:::::{{cite periodical |title=''Possessive italics'''s in title |periodical=Periodical}} and some trailing text
:::—] (]) 13:56, 9 August 2021 (UTC)

== <code><nowiki>{{cite web}}</nowiki></code> template: please make the <code>title</code> parameter optional ==

For web sources, specifying titles often is not necessary but makes code longer and wastes editor’s time. There is no reason to make it required. Let editors decide whether the title is needed. ] (]) 03:58, 10 August 2021 (UTC)
:Well it raises the question, necessary for what? What do you believe is the purpose of a citation? -- ]] 04:06, 10 August 2021 (UTC)
:{{ping|VSL0}} Could you please provide some specific examples of citations where you believe specifying titles is not necessary? Thanks! ] (]) 04:18, 10 August 2021 (UTC)
:{{ping|GoingBatty}} {{ping|GreenC}} The <code><nowiki>{{cite web}}</nowiki></code> template is often used just for referencing (providing the source of information), not necessary for a citation. ] (]) 04:45, 10 August 2021 (UTC)
::"Just for referencing" "not necessary for a citation" is a contradiction. A reference is a citation and vice versa. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 09:22, 10 August 2021 (UTC)
{{ping|GoingBatty}} {{ping|GreenC}} {{ping|Headbomb}} The purpose of using <code><nowiki>{{cite web}}</nowiki></code> may be just providing the link to the source with specifying its <code>date</code> or <code>access-date</code> in a standard way. In case of accessible web sources there may be no need for knowing their titles in advance (especially if they don’t represent books, articles, publications), and this is enough for making the <code>title</code> parameter optional. Could anyone modify the template? ] (]) 07:44, 11 August 2021 (UTC)
::I know the topic is considered closed, but if you allow, I believe an observation must be made. The purpose of {{tlf|cite web}} stated above is incorrect. Like all citation templates, its purpose is to formalize a citation according to a citation system, in this case CS1/2. Citations don't exist to provide links although they should, if they can. Linking is an ancillary to discovery and wikitext verification. As far as {{para|title|{{var|"Webpage Title"}}}} is concerned, it is rather helpful to the lay reader, the same way an in-source location such as "chapter" or "page" would be in print. The related comments below are also pertinent. ] (]) 15:51, 11 August 2021 (UTC)
*My opinion is that very occasionally be some merit in omitting a title – for example, not every web page has a useful title. But those are rare cases, and I wouldn't support removing title as a required parameter, for the reasons outlined at ] In the vast majority of cases editors should be adding titles to their cites. Also, as a final point, it doesn't actually break anything if you omit the title - you'll still generate a cite, and if it's really "wasting your time" to add a title, then don't do it. Per the page I linked above, {{xt|"If you only have time and inclination to copy the reference URL you found, we thank you for your contribution!"}} But such a cite should display a red error message, simply because it's very useful for you or anyone else who comes to the page after you, to know that a title ideally should be added. &nbsp;&mdash;&nbsp;] (]) 08:27, 11 August 2021 (UTC)

:There are several reasons why this is not a good idea:
:# omitting the title makes the link as susceptible to linkrot as using a bare url rather than the template.
:# titles are an indicator to the reader as to what the linked web page is about.
:# if a web page is so poorly designed as to not have a title then I'd be questioning it's suitability as a reliable source. ] (]) 08:30, 11 August 2021 (UTC)
{{ping|Amakuru}} {{ping|Nthep}} I rather agree, and the topic may be considered closed. ] (]) 11:52, 11 August 2021 (UTC)

IMO now theoretical since the discussion is closed anyway, the purpose of a citation on Misplaced Pages is to facilitate finding and verifying a source. The citation is a means to an end. If a title exists, it would be so significant to finding the source it would be required. If no title exists, I don't know. Would need to see examples. Often in those cases the title is descriptive eg. "Facebook post by A_User on a Topic". -- ]] 16:46, 11 August 2021 (UTC)

== Location within large tree-structured documents with no page numbers ==

I often need to cite material from a tree-structured document with no page numbers. Typically there is a sidebar for navigation. If section foo.bar.baz has a stable URL then I can use {{para|section-url}}, but often there is none. Ideally I would like to mark it up with something like

<pre>
<nowiki>{{cite document
| title = Manual with nested sections and no page numbers
| section-1 = foo
| section-2 = bar
| section-3 = baz
}}</nowiki>
</pre>
However, nothing like {{para|section-n}} is implemented. {{para|section|foo: bar: baz}} and {{para|section|foo - bar - baz}} look clunky. What is the best way to mark up such citations? --] (]) 16:42, 11 August 2021 (UTC)
:This looks like you are trying to cite multiple sources with a cs1|2 template that is designed to cite one source at a time. Along with your {{para|section1}}, {{para|section2}}, {{para|section3}} your next request will be for {{para|section-url1}}, {{para|section-url2}}, {{para|section-url3}}, etc. And, how would that render? cs1|2 citations are complex enough, I don't think that we should be making them more complex by attempting to cite multiple sources with a single template. As an aside, this is why I want to do away with {{para|lay-url}} and its companions.
:
:Still, perhaps something like what you want is already available and linking is possible but ugly, very ugly:
::<code><nowiki>{{cite manual |title=Manual with nested sections and no page numbers |at=§foo, §bar, §}}</nowiki></code>
:::{{cite manual |title=Manual with nested sections and no page numbers |at=§foo, §bar, §}}
:And don't use {{tlx|cite document}} to cite a manual. {{tld|cite document}} is a redirect to {{tlx|cite journal}}. Why? Don't know; it really ought not to redirect there... {{tlx|cite manual}} as I used here is a redirect to {{tlx|cite book}}.
:—] (]) 17:14, 11 August 2021 (UTC)
::I don't know why you wrote {{tq|This looks like you are trying to cite multiple sources with a cs1{{!}}2 template that is designed to cite one source at a time.}}, since the first three sentences clearly are describing a '''single''' source that is at a third level branch of the navigation sidebar. That is, on the navigation bar of the web page, you have something like
::* Extraneous content entries
::* Content entry for section foo
::** Extraneous content entries
::** Content entry for subsection bar of section foo
::*** Extraneous content entries
::*** Content entry for subsubsection baz of subsection bar of foo
::where the intended citation is for only for subsubsection baz of subsection bar of foo, not for the enclosing foo or bar. --] (]) 11:28, 12 August 2021 (UTC)
:::I know what you wrote, but to me, your example template skeleton seems to contradict your initial statement; mostly because you did not describe how such an assemblage of parameters is to be rendered. That is why I wrote what I wrote. If you are citing section 'baz', then the title of section baz should be all that you need.
:::
:::Even were we to create enumerated {{para|section&lt;{{var|n}}>}} parameters, you still have some sort of {{tq|clunky}} rendering if you want all of those hierarchical names in the rendered citation:
::::{{cite manual |title=Manual Title |section=Content entry for section foo > Content entry for subsection bar of section foo > Content entry for subsubsection baz of subsection bar of foo}}
:::Isn't {{para|section|Content entry for subsubsection baz of subsection bar of foo}} sufficient?
:::—] (]) 12:04, 12 August 2021 (UTC)
::::I didn't mention rendering because I'm more concerned with semantics than layout. If someone implements {{para|level-{{var|n}}-section}} then I could live with whatever rendering they chose. I'd probably prefer "{{var|level-1}} &gt; {{var|level-2}} &gt; {{var|level-3}}", but that's a nit.
::::The name of the lowest level branch is definitely not all I need, since it doesn't tell the reader how to navigate to that. {{para|section|Content entry for subsubsection baz of subsection bar of foo}} is sufficient. --] (]) 19:10, 13 August 2021 (UTC)


] -- So, I need to write Anon, or something (anonymous) just to fill that parameter field with something.--] (]) 20:46, 10 January 2025 (UTC)
== Identificativo SBN ==


Is there a way to put an Identificativo SBN (Italian identifier) in Cite book and similar templates?--] (]) 08:10, 12 August 2021 (UTC) Can I bind multiple references into a single one?--] (]) 20:48, 10 January 2025 (UTC)
:If you want to use {{tl|sfn}} as you did, simply add <code>|ref={{tlx|sfnref|The Times|1925}}</code> to your references, e.g.
:{{rto|Carnby}} The cheap and nasty workaround is to use {{code|1=others=SBN 123456}}. Otherwise you have to request an addition to the template: I have no idea how you would do that. --] (]) 09:53, 12 August 2021 (UTC)
:*<code><nowiki>{{cite news |title=Towards Balkan Peace|newspaper=] |date=1925-09-22|pp=15|ref={{sfnref|The Times|1925}}}}</nowiki></code>
::@]: {{para|others}} is for 'other' contributors; not for miscellaneous identifiers.
:to give
::
:*{{cite news |title=Towards Balkan Peace|newspaper=] |date=1925-09-22|pp=15|ref={{sfnref|The Times|1925}}}}
::]: use {{para|id|Identificativo SBN: &lt;{{var|identifier number}}>}}
&#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 21:40, 10 January 2025 (UTC)
::—] (]) 11:39, 12 August 2021 (UTC)
::We have a dedicated template for this, so ideally you would use {{para|id|{{tlx|ICCU|number}}}}. (It is not named {{tl|SBN}} because of the name conflict with the ] predecessor.)
:: --] (]) 10:57, 13 August 2021 (UTC)
:::Thank you very much, I didn't find that! Is it possible to add it as a normal identifier i.e. |iccu=? Thanks in advance.--] (]) 05:42, 14 August 2021 (UTC)


:{{ping|Trappist the monk}}: It's probably worth considering to extend the current CS1 functionality to fallback on CITEREF''WORK+YEAR'' when authors aren't specified. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 23:45, 10 January 2025 (UTC)
== Undesirable behaviour of issue= in cite magazine when the issue is a month or months ==


== Add "ERROR" to the "generic_titles" list in "Module:Citation/CS1/Configuration" ==
No doubt this is in the archives but I can't find it. Take for example this citation:
* {{cite magazine |url=https://www.soundvision.com/article/the-beginning-of-hijri-calendar |title=The Beginning of Hijri calendar |author=Paul Lunde |magazine=Saudi Aramco World Magazine |issue=November/December 2005 |access-date=1 January 2019}}
The issue is "November/December 2005", it is nonsense to show it as "no. November/December 2005". The same problem would occur with "issue=Spring 2021" etc. Surely in the case where issues are numbered, the correct argument to use is "number="? How does it make sense to add a "no." prefix to "issue"? --] (]) 09:46, 12 August 2021 (UTC)
:Aren't those better handled as dates? (Doing so would require changing November/December to November–December)] (]) 10:56, 12 August 2021 (UTC)
::Agreed. In such cases, issues are dated, not numbered. ] (]) 11:46, 12 August 2021 (UTC)
:::No, that gives a very ugly result:
:::* {{cite magazine |url=https://www.soundvision.com/article/the-beginning-of-hijri-calendar |title=The Beginning of Hijri calendar |author=Paul Lunde |magazine=Saudi Aramco World Magazine |date=November{{ndash}}December 2005 |access-date=1 January 2019}}
:::which I admit is used and works fine for {{tl|cite news}}. In this example, the 'issue=' setting puts the information in the logical place (after the title) in the citation: the only problem is that addition of the inappropriate 'no.' Why is that intrusion ever needed?
:::Using (a test) number= gives
:::* {{cite magazine |url=https://www.soundvision.com/article/the-beginning-of-hijri-calendar |title=The Beginning of Hijri calendar |author=Paul Lunde |magazine=Saudi Aramco World Magazine |number=567 |access-date=1 January 2019}}
:::where the element is positioned logically and the insertion of 'No.' is entirely appropriate. --] (]) 13:24, 12 August 2021 (UTC)
::::Here is the pdf of the magazine issue in question. Note that this issue is volume 56 number 6 and the date is November/December 2005 so:
:::::<code><nowiki>{{cite magazine |url=https://archive.aramcoworld.com/pdf/2000/200506.pdf |title=Patterns of Moon, Patterns of Sun |first=Paul |last=Lunde |magazine=Saudi Aramco World |date=November–December 2005 |volume=56 |issue=6 |access-date=2021-08-12}}</nowiki></code>
::::::{{cite magazine |url=https://archive.aramcoworld.com/pdf/2000/200506.pdf |title=Patterns of Moon, Patterns of Sun |first=Paul |last=Lunde |magazine=Saudi Aramco World |date=November–December 2005 |volume=56 |issue=6 |access-date=2021-08-12}}
::::—] (]) 14:04, 12 August 2021 (UTC)
:::::Touché! I shall go and stand in the corner for the rest of the class for not having checked a citation after I cleaned it up.
:::::BTW, why did you use "issue=6" and not "number=6"? Are they in fact synonymous, two names for the same bit of programming? If so, then that would explain everything and it will be obvious that my proposal (that {{code|1=issue=}} should not insert {{xt|No. }}) must get spiked. --] (]) 17:51, 13 August 2021 (UTC)
::::::{{para|issue}} and {{para|number}} are aliases.
::::::—] (]) 18:11, 13 August 2021 (UTC)
:::::::{{replyto|John Maynard Friedman}} Further to what Trappist wrote, ] explicitly shows that {{para|number}} is an alias for {{para|issue}}. So they must be expected to behave identically. --] &#x1f339; (]) 22:56, 13 August 2021 (UTC)
::::::::{{rto|Redrose64}} Add failure to RTFM to my sins. Detention as well for my pains.
::::::::(But they ''should'' be different, they have different meanings, so it was not just a lazy assumption. . In my sample citation, the ''issue'' is November/December, the ''number'' is 6. The ''date of publication'' is most likely to have been October. Most "in your local newsagent" magazines come out best part of a month before their declared issue date .) --] (]) 23:23, 13 August 2021 (UTC)
:::::: (edit-conflict) {{para|issue|6}} is not wrong at present, but {{para|number|6}} would be better in this case to improve forward compatibility. At present, both parameters are treated as aliases and produce identical output. But different periodicals use different nomenclatures. It is therefore a good idea to use {{para|issue}} when the publication uses "Issues" as well, and {{para|number}} when they use "Numbers", so that the template can adapt and generate the appropriate prefix "Iss." or "No.". If the publication itself does not prescribe a certain nomenclature, it is best to use issues for volume-relative numbering schemes (as well as non-numeric issue names/titles) and number for absolute numbering schemes (because that's what most periodicals use - but not all).
:::::: Also, when we will finally add support for periodicals featuring both, a number and an issue (requested multiple times and planned for a long while), we will have to better distinguish between them to generate the proper output.
:::::: As discussed above, a date belongs into the {{para|date}} parameter, but there are cases where issues have actual names or titles. This still looks reasonably good in conjunction with {{para|issue}} ("Special issue") but not with {{para|number}}.
:::::: --] (]) 18:23, 13 August 2021 (UTC)
::::I suggest you put aside notions of "ugly". Most citation systems use terse, functional statements. Aesthetics rarely if at all enter the discussion. That doesn't mean that formatting cannot be improved, but such improvement must primarily enhance understanding and utility. ] (]) 14:32, 12 August 2021 (UTC)
:::::I think that misses the point. The description "November/December 2005" is an adjectival phrase that relates to the magazine, not to the author. Fine, forget "ugly": let's be honest and say "amateurish". --] (]) 17:51, 13 August 2021 (UTC)
:::::: That part of the style is consistent with the academic citation styles on which it is based.] (]) 18:03, 13 August 2021 (UTC)
:::::: Well, the entire Misplaced Pages citation ecosystem, including CS1/2 has many, many faults in design, implementation, and documentation, not all which stem from misconceptions of what a citation system geared to non-expert users (readers) should be. But this case is fairly straightforward and easily addressable. The issue number and/or date are useful in locating the source, and if known should be made available, in a way that is obvious and clear. If the issue series is dated rather than numbered, use that information anywhere it makes sense. There is nothing wrong, ugly or amateurish in entering the issue date in the date field. This is correct. The formatting of the date itself is a different issue and does not affect the needed data. ] (]) 21:19, 13 August 2021 (UTC)
:::::::There may be nothing wrong with entering the issue date in the date field, but there are occasional instances when it won't work; notably, when journals use wacky dates like "Michaelmas" and "Trinity" for their issues . —] (]) 21:36, 13 August 2021 (UTC)
::::::::OK, some magical process will turn static forms that apply certain generic positional & formatting rules - the so-called CS1/CS2 citation statements - into dymamic AI appliances that will perfectly account for every single special case under the sun, no matter how rare. Even though the current existing non-magical documentation at least hints otherwise, and even though 1. templates are not the only way to present CS1/CS2 citations and 2. CS1/2 citations are not the only way to reference. ] (]) 22:27, 13 August 2021 (UTC)
:::::::: The templates can already accommodate some "non-date dates" - i.e. seasons, Easter and Christmas according to ] - whether the templates are modified to accommodate others will depend on how often they are used.] (]) 11:03, 16 August 2021 (UTC)


Hi, I noticed that a website has issues in their metadata and if you use VE Cite generator tool for that website, it gives you something just like ]. It should report the error for the {{para|title}}. Also, the link itself is not good for the references list; I don't know if there is something interesting like ''title'' to catch it's generated link too. Thanks! ⇒ ]] 12:49, 11 January 2025 (UTC)
== Multiple URLs (split file) ==


== Double slash (but not URL) in title causes cite web to think title contains URL ==
We have this ref at ]
* {{cite web |url=http://www.nefafoundation.org/miscellaneous/FeaturedDocs/FBI911Timeline.pdf |title=Hijackers' Timeline |author=Federal Bureau of Investigation |publisher=] |date=February 4, 2008 |access-date=October 6, 2008 |url-status=dead |archive-url=https://web.archive.org/web/20081012013300/http://www.nefafoundation.org/miscellaneous/FeaturedDocs/FBI911Timeline.pdf |archive-date=October 12, 2008 }}
It's cited to a page on "NEFA Foundation", which isn't exactly reliable, but the report is the FBI's. The same report can be found on their website, but split into two portions (part-01-of-02, part-02-of-02) (perhaps for file size reasons). FBI site: . How can we use the URLs from fbi.gov directly, but only using one cite tag? ] (]) 13:54, 15 August 2021 (UTC)
:cs1|2 templates are designed to cite one source at a time. In ], pages 218, 261, and 288 are the only pages cited in that report so the FBI part 2 source is all that is needed:
::<code><nowiki>{{cite web |url=https://vault.fbi.gov/9-11%20Commission%20Report/9-11-chronology-part-02-of-02/ |title=Hijackers' Timeline (Redacted) (part 2 of 2) |website=Federal Bureau of Investigation |date=November 14, 2003 |access-date= |ref={{sfnref|''Federal Bureau of Investigation''|2003}}}}</nowiki></code>
:::{{cite web |url=https://vault.fbi.gov/9-11%20Commission%20Report/9-11-chronology-part-02-of-02/ |title=Hijackers' Timeline (Redacted) (part 2 of 2) |website=Federal Bureau of Investigation |date=November 14, 2003 |access-date= |ref={{sfnref|''Federal Bureau of Investigation''|2003}}}}
:You could include a link to part 1 of 2 under §Further reading if it is important.
:—] (]) 14:55, 15 August 2021 (UTC)
: If I run into this situation, I typically append such extra links as raw URLs in square brackets (without title) to the end of the citation between the template's closing <code><nowiki>}}</nowiki></code> brackets and Mediawiki's closing <code><nowiki>&lt;/ref></nowiki></code> tag:
: Most often, such extra links are only meant to help prevent future link rot, so I want them to be rendered as short and unobtrusive as possible and deliberately don't add titles so that they don't consume much extra space in the reference. Since they are outside of the template's special handling for archived links, I typically chose archived links for them if available.
: If the source is available only in form of individual PDFs on a per-page basis, the links are probably better worked into the {{para|pages}} parameter instead.
: When the source is splitted over several multi-page-files (as in your example) and the reference is citing multiple pages distributed over several files, splitting the reference into multiple citations (as indirectly suggested by Trappist above) is certainly an option, but in most cases I find references to the same source (but page numbers) in multiple citations are adding too much redundancy and I therefore try to combine them into a single reference including such appended raw links.
: Not ideal, but there isn't much the templates could do to improve this situation because there is only one title. The only thing that could be improved by having multiple numbered {{para|url''n''}} parameters would be that the extra links could be displayed immediately following the title instead of at the end of the main citation, like:
::
: But still, display of dates and handling of archive links would only work for the main link, and metadata creation would be more complicated. Not sure if this would be worth it.
: --] (]) 21:43, 15 August 2021 (UTC)
: Abusing the {{para|type}} parameter (which does not become part of the COinS metadata) could be used to produce a more reasonable rendering of multiple links - without solving the underlying problems with handling multiple dates and archive links, of course. However, while the current live version of the template does not produce any error message, the sandboxed version will throw an "{{red|External link in {{!}}type{{=}}}}" error (per ]). For illustration purposes only:
:: {{cite web |url=http://www.nefafoundation.org/miscellaneous/FeaturedDocs/FBI911Timeline.pdf |title=Hijackers' Timeline |author=Federal Bureau of Investigation |type= |publisher=] |date=2008-02-04 |access-date=2008-10-06 |url-status=dead |archive-url=https://web.archive.org/web/20081012013300/http://www.nefafoundation.org/miscellaneous/FeaturedDocs/FBI911Timeline.pdf |archive-date=2008-10-12}}
: Related topic: ]
: So, if we would want to add some limited support for multiple links, it could be implemented similar to {{para|type}}. Perhaps this could be combined with the rendering of what an already proposed {{para|part}} parameter would produce (if we would allow external links there).
: --] (]) 03:48, 17 August 2021 (UTC)


A title with a URL in it is an error. A title with a double slash in it that is not a URL should not be an error, but is flagged as one. I found this in https://en.wikipedia.org/search/?title=D%C3%A9sir%C3%A9_Andr%C3%A9&oldid=1266756491 in a template that expands to cite web:
== Date quarters ==
*<nowiki>{{Base Léonore|LH//33/73|id=5166}}</nowiki>
*{{Base Léonore|LH//33/73|id=5166}}
It cannot be worked around by (()) because the argument to the template is only a part of the title from which the template constructs the rest of the title. I changed it to L0033073, matching ''numero de notice'' in the top left of the link, but the double-slash form is not a typo; it comes from a line "Cote(s) : LH//33/73" in the main text of the link. I think this should not be flagged as an error. This template is transcluded some 50 times and at least some others of its transclusions are raising the same error message. —] (]) 06:40, 15 January 2025 (UTC)


Simpler case:
Some publications give a date as year and quarter, but, e.g., {{para|date|3Q 1984}}, yields an error message:
*<code><nowiki>{{cite web |url=https://www.leonore.archives-nationales.culture.gouv.fr/ui/notice/5166 |title=Notice no. LH//33/73}}</nowiki></code>
<blockquote>{{cite document
*{{cite web |url=https://www.leonore.archives-nationales.culture.gouv.fr/ui/notice/5166 |title=Notice no. LH//33/73}}
| title = foo
&#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 08:12, 15 January 2025 (UTC)
| date = 3Q 1984
:I have tightened the protocol-relative test a bit so that the authority indicator (<code>//</code>) must be preceded by nothing or by whitespace to be recognized as a url:
}}</blockquote>
<div style="margin-left:3.2em">{{cite compare |template=web |url=https://www.leonore.archives-nationales.culture.gouv.fr/ui/notice/5166 |title=Notice no. LH//33/73}}
Is there a legitimate way to enter a quarter in {{para|date}}? --] (]) 14:49, 16 August 2021 (UTC)
{{cite compare |template=web |url=https://www.leonore.archives-nationales.culture.gouv.fr/ui/notice/5166 |title=Notice no. LH //33/73}}
:<code><nowiki>{{cite journal |title=foo |journal=Journal |date=Third Quarter 1984}}</nowiki></code>
{{cite compare |template=web |url=https://www.leonore.archives-nationales.culture.gouv.fr/ui/notice/5166 |title=//33/73}}</div>
::{{cite journal |title=foo |journal=Journal |date=Third Quarter 1984}}
:—] (]) 15:29, 16 August 2021 (UTC) :—] (]) 15:14, 15 January 2025 (UTC)
::I tried wrapping the whole title in double parens at {{tl|Base Léonore}} and on the template's testcases page, but the URL error still appears. I may have done it wrong. Do double parens work for this purpose in {{para|title}}? – ] (]) 17:47, 16 January 2025 (UTC)
::But be prepared for a strange result when the author name is provided
:::No. This particular test occurs very early in the basic validation of all template parameters; before we recognize the accept-as-written markup. Without someone has a better idea, fixing the error detector as I have done is the better solution to the apparent-authority-indicator-in-title problem.
:::{{cite journal |title= The unbearable brightness of fooing |journal=Journal of Forensic Fooology |date=Third Quarter 1984 |first=John |last=Doe}}
:::—] (]) 18:03, 16 January 2025 (UTC)
::which is far from ideal. Would {{u|Chatul}} be better advised to use {{code|1=issue=}} rather than (or even as well as) {{code|1=date=}} ?
::::Thanks. I've made a note in the help doc. – ] (]) 18:30, 16 January 2025 (UTC)
::* <code><nowiki>{{cite journal |title= The unbearable brightness of fooing |journal=Journal of Forensic Fooology |date=1984 |issue=Third Quarter 1984 |first=John |last=Doe}}</nowiki></code> <br />
::which yields
::* {{cite journal |title= The unbearable brightness of fooing|journal=Journal of Forensic Fooology |date=1984 |issue=Third Quarter 1984 |first=John |last=Doe}}
::which I suspect is what {{u|Chatul}} might prefer (and be more convenient to use with {{tl|harv}} or {{tl|sfn}}. --] (]) 16:48, 16 August 2021 (UTC)
:::No. The date parameter was specifically changed in the past year or so to accept quarterly dates. Your opinion on the appearance is, uh, noted elsewhere. ] (]) 18:34, 16 August 2021 (UTC)
::::And anyway, sfn/harv will still be put in as the year. ] (]) 18:38, 16 August 2021 (UTC)


== bad DOI check == == Generic author ==


Hello, a generic author starting like {{para|author|Custom byline text}}. There are 18 cases at the moment, but I will tidy them up. ] (]) 16:40, 16 January 2025 (UTC)
The following throws an error, but it's resolving correctly
*{{Cite journal| vauthors = O'Mullane DM |date=2016|title=Fluoride and Oral Health |journal=Community Dental Health|issue=33|pages=69–99|doi=10.1922/CDH_3707O’Mullane31}}
&#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 09:27, 17 August 2021 (UTC)

Latest revision as of 02:40, 17 January 2025

    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.
    On 4 January 2025, it was proposed that this page be moved to Template:cite audiovisual media. The result of the discussion was not moved.

    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)
    Thank you for the clarification. Given that the current possibilities are:
    • registration = 'Free registration required'
    • limited = 'Free access subject to limited trial, subscription normally required'
    • subscription = 'Paid subscription required'
    do you think it would be unreasonable to collapse the tertiary possibilities discussed (e.g., search access only, some pages browsable, special permissions) into a fourth parameter:
    • partial = 'Partial access, not fully readable' (or something)
    The motivation for the parameter is the same as the other 3, with no more or less difficulty in implementation. In particular, it is to emphasize that the URL supplied is not "full access", in one way or another. Tule-hog (talk) 00:21, 5 January 2025 (UTC)
    If the proposed fourth parameter is not reasonable, I will collapse the use of {{IAp}} to a simple |url= with no indicator. As a reader, I would find an indicator an appreciated convenience, but I don't see another solution. Tule-hog (talk) 00:22, 5 January 2025 (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}} → 1
    —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.
    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)
    Thank you! After this goes live, we could update the articles in Category:CS1 maint: ignored DOI errors. GoingBatty (talk) 17:31, 26 December 2024 (UTC)
    I reviewed each article in Category:CS1 maint: ignored DOI errors and removed the temporary error hiding for the 10.7#### DOIs that were kindly added by users such as Metamd, AManWithNoPlan and Snowman304. GoingBatty (talk) 20:55, 2 January 2025 (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)
    I know this is pretty stale (and evidently a pain to fix), but I'd support the eventual, non-urgent relocation of the |translator-n*= parameters to render immediately following |chapter= / |entry= if available, or immediately following |title= otherwise.As someone who has previously worked in translation, I can affirm that there is a reason why publishers may recommend the translator be attributed as coauthor. Unless machine translation is used as a jumping off point, translation is a significant and very personal contribution; it makes sense to credit close to the title. No rush though. Folly Mox (talk) 17:15, 5 January 2025 (UTC)
    That sounds good (logical) to me. And I hope the overhaul of parameters happens sooner rather than later. —DocWatson42 (talk) 22:21, 6 January 2025 (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)
    "Is a sub-type of unfit" .. ? Unfit are individual URLs that are a problem in an otherwise legitimate website/domain. Usurped are URLs for an entire websites/domains. They are tracking similar problem URLs but of different scope. I agree it works to have one category, but thought the category placeholder name could be the larger more common set. Usurped is now up to 55,000 and I forecast this number will be 100s k if not millions, dwarfing unfit. -- GreenC 20:06, 1 January 2025 (UTC)
    I forgot to mention that some time ago I implemented a prospective work-around for the Lua error in Module:Citation/CS1/Configuration at line 2083: attempt to index a boolean value messages. These messages occur when the attempt to fetch ID limits from Commons (c:Data:CS1/Identifier limits.tab) fails. When the fetch fails, Module:Citation/CS1/Configuration will use default limit values of 99999999999 so that individual limit tests will not fail. Articles where this happens will be added to Category:CS1 maint: ID limit load fail. Unlike all other maintenance categories, this category will not emit the maintenance message because it would appear in every cs1|2 template rendered in the article. A null edit should remove an article from the category. It is nearly impossible to test this code because the load failure is rare and random but, famous last words, I believe that I haven't done anything too stupid.
    —Trappist the monk (talk) 15:32, 27 December 2024 (UTC)
    I've added the cat to list of things to watch. -- LCU ActivelyDisinterested «@» °∆t° 15:43, 27 December 2024 (UTC)

    Reformat dates v2

    Previous: Help talk:Citation Style 1/Archive 97#'Reformat dates' function
    Hi! I'm trying to find a variable that would allow me to display all dates (we use a bot to convert them into ISO format) using formatDate: https://ru.wikipedia.org/search/?diff=142375001&oldid=141847966. Can you tell me what I'm doing wrong and where it needs to be corrected? Iniquity (talk) 17:42, 29 December 2024 (UTC)

    What you mean by variable that would allow me to display all dates.
    You use a bot to convert them into ISO format. Does that mean that your bot converts all wikitext dates to ISO format so that cs1|2 never sees anything but ISO format dates? Even date ranges? (YYYY-MM-DD/YYYY-MM-DD) Seasons? Named dates (Christmas, Easter, etc)? What about dates outside of the Gregorian calendar?
    At line 1002 you use formatDate() to format the value returned from reformatter() (called from either line 1060 or line 1062). At line 1066 you use formatDate() to format the date that was just formatted at line 1002. Why?
    Do you have an example sandbox somewhere that shows what you want and what you're getting?
    —Trappist the monk (talk) 18:37, 29 December 2024 (UTC)
    What you mean by variable that would allow me to display all dates.
    I mean the variable that is returned in AccessDate, ArchiveDate and Date in Module:Citation/CS1.Does that mean that your bot converts all wikitext dates to ISO format so that cs1|2 never sees anything but ISO format dates?
    So far only English and Russian dates supported by Citoid. Perhaps in the future we will try to convert all Russian and English dates, and another languages.
    I thought to use additionally your date converter to convert maximum number of dates to iso (by using global_df = 'ymd-all',), and then pass what is obtained through the formatDate(). And if the formatDate() displays an error, then display your output without formatDate().At line 1002 you use formatDate() to format the value returned from reformatter() (called from either line 1060 or line 1062). At line 1066 you use formatDate() to format the date that was just formatted at line 1002. Why?
    I was trying to figure out how it works.Do you have an example sandbox somewhere that shows what you want and what you're getting?
    ru:Обсуждение модуля:Citation/CS1/testcases/dates - first table. I am currently using a local module to convert dates, but I don't like the location where I am using it.
    https://ru.wikipedia.org/search/?title=Module:Citation/CS1&action=edit (line 436) Iniquity (talk) 19:00, 29 December 2024 (UTC)
    The first three testcases (|access-date=2001-01-14, |access-date=January 14, 2001, |access-date=14 January 2001) are not modified because those dates are invalid – there cannot be an access date that precedes the creation of Misplaced Pages. The last testcase is also invalid because that date exists in the future (day after tomorrow).
    When reformatter() returns mw.language.new( 'ru' ):formatDate( 'j xg Y', new_date );, two testcases, |access-date=January 15, 2001 and |access-date=15 January 2001, both return 15 января 2001.
    The remaining testcases (|access-date=2001-01-15, |access-date=2024-12-30 – today's date, |access-date=2024-12-30 – tomorrow's date) return their inputs because you specify global_df = 'ymd-all',. The code at lines 933–935 terminates the conversion because converting ymd to ymd is a pointless waste of processor cycles. I added a test at line 932: 
    	if 'ymd' == format_param and 'ymd' == pattern_idx then						-- special case for ru.wiki
		return mw.language.new( 'ru' ):formatDate( 'j xg Y', date );			-- convert ymd to dMy
	end
    With that code in place, the remaining tests return 15 января 2001, 30 декабря 2024, and 31 декабря 2024.
    —Trappist the monk (talk) 16:35, 30 December 2024 (UTC)
    Yeah! Thanks, it works, but I have some problems with dates without day.
    ru:User:Iniquity/dates.
    If the date parameter is specified without a day, the conversion through formatDate does not occur. However, if it is specified in the archival date or access date, all dates break. Iniquity (talk) 19:46, 30 December 2024 (UTC)
    |access-date= and |archive-date= must include day, month, and year – the dates are meaningless else.
    It is pointless to convert ym dates to ymd dates. Add this: 
    	if 'ymd' == format_param and 'ym' == pattern_idx then						-- special case for ru.wiki
		return mw.language.new( 'ru' ):formatDate( 'xg Y', date );			-- convert ym to My
	end
    change the sequence in the first if in reformatter() to include 'ym', .
    You still need to add the call to formatDate() at the end of reformatter(). Without you do that, the 5th and 6th test_access_dates tests at ru:Обсуждение модуля:Citation/CS1/testcases/dates do not convert.
    —Trappist the monk (talk) 15:02, 31 December 2024 (UTC)
    It works! Thanks! :) Iniquity (talk) 15:58, 31 December 2024 (UTC)
    Consider the testcase
    {{cite journal/песочница |title=Title |journal=Journal |date=23–29 February 1700}}
    Leaving aside whether all the functions used can handle the date 29 February 1700. The correct result needs careful inspection because no real journal is specified, therefore it's unknown whether the journal used the Gregorian or Julian calendar until we examine the date. But the date 29 February 1700 tells us it must be a Julian date because 1700 was not a leap year in the Gregorian calendar. Since it is a Julian calendar, the choices are to keep the date in the original format, or change it to the corresponding Gregorian ISO 8601-1-2019 date range:
    1700-03-05/03-11
    Jc3s5h (talk) 17:11, 31 December 2024 (UTC)
    I agree with you, but as long as the core MediaWiki functions do not support date ranges and other mechanisms, I prefer not to use them in templates :)
    phab:T381313
    meta:Community Wishlist/Wishes/Support for ISO, EDTF or IETF Date Standards in MediaWiki Parser Functions Iniquity (talk) 17:23, 31 December 2024 (UTC)

    OCLC parameter now needs to allow 11 digits.

    During a preview on Polyamory I ran into this:

    This gave this error: {{cite journal}}: Check |oclc= value (help)

    Click through on that 11-digit OCLC # to see that it links to a WorldCat record. Peaceray (talk) 22:10, 29 December 2024 (UTC)

    language parameter is not recognising languages

    The language parameter is not recognising languages includes Nagpuri language and Kharia language by their iso code.––kemel49 11:18, 4 January 2025 (UTC)

    None of the language tags are supported by MediaWiki:
    • Nagpuri (Sadri) sck: {{#language:sck|en}} → sck
    • Nagpuri (Oraon Sadri) sdr: {{#language:sdr|en}} → sdr
    • Kharia khr: {{#language:khr|en}} → khr
    See the documentation for |language= and, in particular, the list of supported codes and names.
    —Trappist the monk (talk) 12:38, 4 January 2025 (UTC)
    Is there any way to get such languages included.––kemel49 12:48, 4 January 2025 (UTC)

    Module support edit req

    This edit request to Module:Citation/CS1 has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.

    I would like to have the following code added to Module:Citation/CS1 - DIFF. This was previously discussed at Help talk:Citation Style 1/Archive 94#Module access without any convincing arguments against it. This adds support for modules to call the module directly, instead of using metatables or templates. Module:CS1 translator is one of the usecases. The "citation" function was renamed to "_citation", and a new "citation" function made. The "_citation" function would be the entry point for any module, and that module calling it would have to provide the same information as the "citation" function provides. This _x and x naming scheme is consistent with other modules providing access from other modules. Any frame dependant functionality was moved to the "citation" function. Only 4 tests failed at Module talk:Citation/CS1/testcases. Snævar (talk) 13:03, 4 January 2025 (UTC)

    That previous discussion did not, it seems, generate enthusiastic support either. From that discussion, are we to infer that you mean to replace Module:Cite book (and the others) with a single module that then calls the Module:Citation/CS1 function _citation() with the appropriate arguments? Have you written that replacement module? Where can we see it working?
    Not clear to me that Module:CS1 translator would benefit from this change. What am I missing?
    —Trappist the monk (talk) 14:35, 4 January 2025 (UTC)
    The modules and what parameters they support are distinct on purpose. This is a feature, not a bug. Headbomb {t · c · p · b} 16:42, 4 January 2025 (UTC)
    I unequivocally support adding module access to this module. I have looked at it many times and have not been able to figure it out, so kudos to someone for taking a hack at it. Izno (talk) 21:32, 4 January 2025 (UTC)
    I have a criticism though. The templatestyles should be in _citation. If you need to get another frame inside there that's fine. Izno (talk) 21:37, 4 January 2025 (UTC)
    And actually, I think all the lookups should be in _citation. Izno (talk) 21:37, 4 January 2025 (UTC)
    Concur. I've moved all that stuff into _citation(). Not yet tested calls from another module.
    —Trappist the monk (talk) 01:03, 5 January 2025 (UTC)
    I have hacked a proof of concept module in my sandbox that appears to demonstrate that Module:Citation/CS1/sandbox can be called from another module. The first three examples were scraped from elsewhere on this page, live template rendering above the sandbox rendering:
    {{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}}
    • 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.
    • 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 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}}
    {{cite map|author-link=Joe Bloggs|date=5 January 2025|edition=57|editor-first=John|editor-last=Doe|editor-link=John Doe|first=Joe|format=format|issue=38|last=Bloggs|others=others|title=title|type=type|url=https://www.example.com/|volume=52|website=website}}
    For most cs1|2 templates, the |CitationClass= parameter is set to the lowercase version of the canonical template name. There are six for which that is not true; {{cite encyclopedia}} sets |CitationClass=encyclopaedia:
    {{cite encyclopedia |last=Seberg |first=Ole |editor1-last=Heywood |editor1-first=Vernon H. |editor2-last=Brummitt |editor2-first=Richard K. |editor3-last=Culham |editor3-first=Alastair |title=Alliaceae |encyclopedia=Flowering Plant Families of the World |url={{google books |plainurl=y |id=Jy1FAQAAIAAJ|page=340}}|date=2007 |publisher=Firefly Books |location=Richmond Hill, Ontario |isbn=978-1-55407-206-4 |pages=340–341}}
    • Seberg, Ole (2007). "Alliaceae". In Heywood, Vernon H.; Brummitt, Richard K.; Culham, Alastair (eds.). Flowering Plant Families of the World. Richmond Hill, Ontario: Firefly Books. pp. 340–341. ISBN 978-1-55407-206-4.
    • Seberg, Ole (2007). "Alliaceae". In Heywood, Vernon H.; Brummitt, Richard K.; Culham, Alastair (eds.). Flowering Plant Families of the World. Richmond Hill, Ontario: Firefly Books. pp. 340–341. ISBN 978-1-55407-206-4.
    Conveniently, should we decide to implement this as a replacement for Module:Cite book and the others, Module:Cite is currently available.
    —Trappist the monk (talk) 19:49, 5 January 2025 (UTC)
    Are we keeping this or should I discard these changes?
    —Trappist the monk (talk) 15:17, 15 January 2025 (UTC)

    Requested move 4 January 2025

    The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

    The result of the move request was: not moved. (closed by non-admin page mover) Frost 00:13, 12 January 2025 (UTC)

    – The reason I'm requesting for these templates to be moved to their respective new titles is per WP:TG; because template function should be clear from the template name, but redirects can be created to assist everyday use of very popular templates, because redirects are cheap. PK2 (talk; contributions) 23:50, 4 January 2025 (UTC)

    References are used often and inline, which makes them noisy. These are some of the longer names. I would not support a move of any of the above. Izno (talk) 01:35, 5 January 2025 (UTC)
    The problem with the "redirects are cheap" argument is that redirected templates often lead to gnomes or bots replacing the templates with the redirect target (despite WP:COSMETICBOT) and this leads to a lot of clutter on everyone's watchlists, and the resulting waste of human editors' attention is not so cheap. —David Eppstein (talk) 01:39, 5 January 2025 (UTC)
    I'm unconvinced by the argument for this. I've never seen a confused misuse of {{Cite AV media}}. I don't see that it's purpose is unclear. On the other hand I've seen {{Cite journal}} used several times for people's diaries, but even that is an extremely rare issue. As other have said this will just result in the longer title being used, creating clutter for no practical effect. -- LCU ActivelyDisinterested «@» °∆t° 13:42, 5 January 2025 (UTC)
    • Oppose for AV, don't care on tech. Headbomb {t · c · p · b} 16:00, 5 January 2025 (UTC)
    • Oppose per David Eppstein and ActivelyDisinterested. Redirects are cheap until someone decides they all need to be bypassed, which people often choose to do en masse for some reason. And it's not clear how "AV media" could be confused for anything but "audio-visual media". I legitimately checked for possible confounders and came up empty.As an aside, I have also seen {{Cite journal}} to cite a diary, but the more common cases of confusion – in steeply ascending order – are people trying to use {{Cite document}} inappropriately to cite an online source, because it's a "document" (as if any written material isn't), and User:Citation bot swapping in an incorrect template because it sees an isbn or something.{{Cite tech report}} → {{Cite technical report}} is less objectionable, but still seems undesirable. Again, what do people think "tech report" might mean apart from "technical report"? (I suppose "technology report" or "technique report" might be theoretically possible.) Good faith request, but unconvincing, and neglects drawbacks. Folly Mox (talk) 17:00, 5 January 2025 (UTC)
    • Oppose for the AV templates, I think there is a good argument that AV is more obvious than audiovisual. Meh on tech to technical. Skynxnex (talk) 02:46, 6 January 2025 (UTC)
    • Oppose for the same reasons. The clarity benefit is marginal, outweighed by the (much) longer name, and the change is likely to cause unwanted churn. Looking at the AV disambiguation page, I don't see anything potentially confusing. Do we cite to Adult Video a lot? 97.102.205.224 (talk) 21:51, 7 January 2025 (UTC)
    The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

    Is there a full list of all names that are considered 'generic'?

    I'm working on a script that searches through CS1 templates with generic names and provides a list of the most common first and last names that throw an error in the template. I couldn't find it on the category page, but is there a copy of the test that templates run through so I can do it locally on my machine?

    Thanks EatingCarBatteries (contributions, talk) 07:41, 8 January 2025 (UTC)

    @EatingCarBatteries: The full list is a mixture of exact titles such as contact us and LUA string-matching patterns such as ews?oom; search for generic_titles in Module:Citation/CS1/Configuration. -- John of Reading (talk) 07:48, 8 January 2025 (UTC)
    Thank you John! EatingCarBatteries (contributions, talk) 07:50, 8 January 2025 (UTC)

    Lack of orthogonality

    There are some CS1 parameters that are not allowed in templates where they make sense and would be useful. An example is {{cite journal}}. Journal articles are often available on the WWW and often have numbered sections, but |section= and |section-link= are not available, although there is a hack (|at=link). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:02, 8 January 2025 (UTC)

    @Chatul Do the sections have different authors? I thought that was the purpose of section/chapter, to cite different pieces by different people within the same book, Rjj (talk) 15:23, 8 January 2025 (UTC)
    I'm not aware of anything that ties author with in-source locations in general, and with |section= in particular. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:17, 8 January 2025 (UTC)
    |title= should be used for the article in the journal, so is this about a section of the article without page numbers? Do you have an example? If you're referencing part of an article without page numbers but numbered sections then |at= seems appropriate. -- LCU ActivelyDisinterested «@» °∆t° 19:54, 8 January 2025 (UTC)
    In this case there are no page numbers, but it wouldn't help if the were, since |at=, |page= and |pages= are mutually exclusive. In this case I am using

    {{cite journal | journal = Communications of the ACM | volume = 6 | issue = 1 | date = January 1963 | title = Revised Report on the Algorithmic Language Algol 60 | editor = Peter Naur | editor-link = Peter Naur | author1 = J.W. Backus | author-link1 = John Backus | author2 = F.L. Bauer | author-link2 = Friedrich L. Bauer | author3 = J.Green | author4 = C. Katz | author5 = J. McCarthy | author-link5 = John McCarthy (computer scientist) | author6 = P. Naur | author-link6 = Peter Naur | author7 = A.J. Perlis | author-link7 = Alan Perlis | author8 = H. Rutishauser | author-link8 = Heinz Rutishauser | author9 = K. Samuelson | author10 = B. Vauquois | author-link10 = Bernard Vauquois | author11 = J.H. Wegstein | author-link11 = Joseph Henry Wegstein | author12 = A. van Wijngaarden | author-link12 = Adriaan van Wijngaarden | author13 = M. Woodger | author-link13 = Mike Woodger | at = 3.2.4. Standard functions | url = https://doi.org/10.1145/366193.366201 | publisher = Association for Computing Machinery | doi = 10.1145/366193.366201 | s2cid = 7853511 }}

    which renders as J.W. Backus; F.L. Bauer; J.Green; C. Katz; J. McCarthy; P. Naur; A.J. Perlis; H. Rutishauser; K. Samuelson; B. Vauquois; J.H. Wegstein; A. van Wijngaarden; M. Woodger (January 1963). Peter Naur (ed.). "Revised Report on the Algorithmic Language Algol 60". Communications of the ACM. 6 (1). Association for Computing Machinery. 3.2.4. Standard functions. doi:10.1145/366193.366201. S2CID 7853511.. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 20:58, 8 January 2025 (UTC)
    That article has page numbers though? |pages=1–17 (section 3.2.4 is on p. 6). Also remember |doi-access=free. I could see wanting a |section= for online-only journals where there is no true pagination, but |at= does seem to be doing an adequate job. Folly Mox (talk) 21:44, 8 January 2025 (UTC)
    Isn't this the purpose of |at=, for when a page number is inappropriate or insufficient? Section is even listed as an example usage in the documentation. -- LCU ActivelyDisinterested «@» °∆t° 00:56, 9 January 2025 (UTC)

    Strange placement of others in journal citation

    "Others", in a journal citation, is placed between the issue number and the page numbers. Example (from Garden of Eden (cellular automaton)):

    • {{citation | last = Bartholdi | first = Laurent | others = with an appendix by Dawid Kielak | arxiv = 1605.09133 | doi = 10.4171/JEMS/900 | issue = 10 | journal = Journal of the European Mathematical Society (JEMS) | mr = 3994103 | pages = 3191–3197 | title = Amenability of groups is characterized by Myhill's theorem | volume = 21 | year = 2019}}
    • Bartholdi, Laurent (2019), "Amenability of groups is characterized by Myhill's theorem", Journal of the European Mathematical Society (JEMS), 21 (10), with an appendix by Dawid Kielak: 3191–3197, arXiv:1605.09133, doi:10.4171/JEMS/900, MR 3994103
    • Manually substed: Bartholdi, Laurent (2019), "Amenability of groups is characterized by Myhill's theorem", Journal of the European Mathematical Society (JEMS), 21 (10), with an appendix by Dawid Kielak: 3191–3197, arXiv:1605.09133 Free access icon, doi:10.4171/JEMS/900, MR3994103
    • Sandbox: Bartholdi, Laurent (2019), "Amenability of groups is characterized by Myhill's theorem", Journal of the European Mathematical Society (JEMS), 21 (10), with an appendix by Dawid Kielak: 3191–3197, arXiv:1605.09133, doi:10.4171/JEMS/900, MR 3994103

    This strikes me as unlikely to be the best place to put it. In this example, the arXiv version lists both authors. The journal article landing page puts the "with an appendix by..." text into a subtitle of the article title, as does the BibTeX that I get from doi.org. The MathSciNet BibTeX data which I used to generate this citation instead separates it out into a note= field of the BibTeX. zbMATH just omits Kielak from the metadata altogether. I think others= should be the correct way of handling this, if only it produced reasonable formatting. —David Eppstein (talk) 04:48, 9 January 2025 (UTC)

    Why not just put the "With an appendix ..." text in the title, as recommended at the source? – Jonesey95 (talk) 05:30, 9 January 2025 (UTC)
    Putting aside how to get this specific citation formatted in a way that doesn't look stupid, maybe we could make the others= parameter useful instead of having to use hacks to work around its bad behavior? My strong suspicion is that using hacks to work around bad alternatives was also the motivation for putting the additional contributor in the subtitle rather than somewhere more principled. —David Eppstein (talk) 06:09, 9 January 2025 (UTC)
    This is more-or-less the same issue as § Placement of "translator"/"page" fields above.
    —Trappist the monk (talk) 15:44, 9 January 2025 (UTC)

    How to cite one of them

    I have three articles all published in the same publication (The Daily Telegraph), in year (1923) and the same month (January), but on different days. The question is how to cite one of them using sfn.

    --TheDiaboloBoy (talk) 10:06, 10 January 2025 (UTC)

    Text to be proven, and more, and even more.

    References

    1. Smith 1923a.
    2. Smith 1923b.
    3. Smith 1923c.
    Sources
    • Smith, Graftoon Elliot (19 January 1923a). "The Tomb of Tutankhamen". The Daily Telegraph. pp. 9–10.
    • Smith, Graftoon Elliot (19 January 1923b). "The Tomb of Tutankhamen". The Daily Telegraph. p. 9.
    • Smith, Graftoon Elliot (19 January 1923c). "The Tomb of Tutankhamen". The Daily Telegraph. p. 9.
    HTH -- Michael Bednarek (talk) 12:25, 10 January 2025 (UTC)

    How to cite an unsigned article

    For example

    • "Towards Balkan Peace". The Times. 1925-09-22. p. 15.

    --TheDiaboloBoy (talk) 11:17, 10 January 2025 (UTC)

    Lets see:

    --TheDiaboloBoy (talk) 11:29, 10 January 2025 (UTC)

    --TheDiaboloBoy (talk) 11:30, 10 January 2025 (UTC)

    References

    1. The Times & 1925-09-22. sfn error: no target: CITEREFThe_Times1925-09-22 (help)
    2. The Times 1925.
    Text to be proven.

    References

    1. Anon. 1925.
    Sources
    • Anon. (1925-09-22). "Towards Balkan Peace". The Times. p. 15.
    HTH -- Michael Bednarek (talk) 12:28, 10 January 2025 (UTC)

    Michael Bednarek -- So, I need to write Anon, or something (anonymous) just to fill that parameter field with something.--TheDiaboloBoy (talk) 20:46, 10 January 2025 (UTC)

    Can I bind multiple references into a single one?--TheDiaboloBoy (talk) 20:48, 10 January 2025 (UTC)

    If you want to use {{sfn}} as you did, simply add |ref={{sfnref|The Times|1925}} to your references, e.g.
    • {{cite news |title=Towards Balkan Peace|newspaper=] |date=1925-09-22|pp=15|ref={{sfnref|The Times|1925}}}}
    to give
    • "Towards Balkan Peace". The Times. 1925-09-22. p. 15.

    Headbomb {t · c · p · b} 21:40, 10 January 2025 (UTC)

    @Trappist the monk:: It's probably worth considering to extend the current CS1 functionality to fallback on CITEREFWORK+YEAR when authors aren't specified. Headbomb {t · c · p · b} 23:45, 10 January 2025 (UTC)

    Add "ERROR" to the "generic_titles" list in "Module:Citation/CS1/Configuration"

    Hi, I noticed that a website has issues in their metadata and if you use VE Cite generator tool for that website, it gives you something just like this one. It should report the error for the |title=. Also, the link itself is not good for the references list; I don't know if there is something interesting like title to catch it's generated link too. Thanks! ⇒ AramTalk 12:49, 11 January 2025 (UTC)

    Double slash (but not URL) in title causes cite web to think title contains URL

    A title with a URL in it is an error. A title with a double slash in it that is not a URL should not be an error, but is flagged as one. I found this in https://en.wikipedia.org/search/?title=D%C3%A9sir%C3%A9_Andr%C3%A9&oldid=1266756491 in a template that expands to cite web:

    It cannot be worked around by (()) because the argument to the template is only a part of the title from which the template constructs the rest of the title. I changed it to L0033073, matching numero de notice in the top left of the link, but the double-slash form is not a typo; it comes from a line "Cote(s) : LH//33/73" in the main text of the link. I think this should not be flagged as an error. This template is transcluded some 50 times and at least some others of its transclusions are raising the same error message. —David Eppstein (talk) 06:40, 15 January 2025 (UTC)

    Simpler case:

    • {{cite web |url=https://www.leonore.archives-nationales.culture.gouv.fr/ui/notice/5166 |title=Notice no. LH//33/73}}
    • "Notice no. LH//33/73". {{cite web}}: External link in |title= (help)

    Headbomb {t · c · p · b} 08:12, 15 January 2025 (UTC)

    I have tightened the protocol-relative test a bit so that the authority indicator (//) must be preceded by nothing or by whitespace to be recognized as a url:
    Cite web comparison
    Wikitext {{cite web|title=Notice no. LH//33/73|url=https://www.leonore.archives-nationales.culture.gouv.fr/ui/notice/5166}}
    Live "Notice no. LH//33/73". {{cite web}}: External link in |title= (help)
    Sandbox "Notice no. LH//33/73".
    Cite web comparison
    Wikitext {{cite web|title=Notice no. LH //33/73|url=https://www.leonore.archives-nationales.culture.gouv.fr/ui/notice/5166}}
    Live "Notice no. LH //33/73". {{cite web}}: External link in |title= (help)
    Sandbox "Notice no. LH //33/73". {{cite web}}: External link in |title= (help)
    Cite web comparison
    Wikitext {{cite web|title=//33/73|url=https://www.leonore.archives-nationales.culture.gouv.fr/ui/notice/5166}}
    Live "//33/73". {{cite web}}: External link in |title= (help)
    Sandbox "//33/73". {{cite web}}: External link in |title= (help)
    —Trappist the monk (talk) 15:14, 15 January 2025 (UTC)
    I tried wrapping the whole title in double parens at {{Base Léonore}} and on the template's testcases page, but the URL error still appears. I may have done it wrong. Do double parens work for this purpose in |title=? – Jonesey95 (talk) 17:47, 16 January 2025 (UTC)
    No. This particular test occurs very early in the basic validation of all template parameters; before we recognize the accept-as-written markup. Without someone has a better idea, fixing the error detector as I have done is the better solution to the apparent-authority-indicator-in-title problem.
    —Trappist the monk (talk) 18:03, 16 January 2025 (UTC)
    Thanks. I've made a note in the help doc. – Jonesey95 (talk) 18:30, 16 January 2025 (UTC)

    Generic author

    Hello, a generic author starting like |author=Custom byline text. There are 18 cases at the moment, but I will tidy them up. Keith D (talk) 16:40, 16 January 2025 (UTC)

    Categories:
    Help talk:Citation Style 1: Difference between revisions Add topic