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 19:43, 7 September 2015 edit64.134.64.231 (talk) →Italicization of websites in citationsTags: Mobile edit Mobile web edit← Previous edit Latest revision as of 11:46, 7 January 2025 edit undoClueBot III (talk | contribs)Bots1,378,475 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}}<!--
-->{{talk header|WT:CS1}} -->{{skip to bottom}}<!--
-->{{talk header|display_title=Help:Citation Style 1 and the CS1 templates|WT:CS1}}
{{Help Project|importance=High|class=B}}
{{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 ].}}
{{WikiProject banner shell|collapsed=yes|1=
{{Misplaced Pages Help Project|importance=High}}
{{WikiProject Academic Journals}}
{{WikiProject Magazines}}
}}
{{User:ClueBot III/ArchiveThis {{User:ClueBot III/ArchiveThis
|archiveprefix=Help talk:Citation Style 1/Archive |archiveprefix=Help talk:Citation Style 1/Archive
|format= %%i |format= %%i
|age=480
|numberstart=3
|header={{Automatic archive navigator}}
|age=720
|headerlevel=2
<!-- |index=yes -->
|maxarchsize=200000
<!-- |archivebox=yes -->
|minkeepthreads=6
|box-advert=yes
|numberstart=69
|minkeepthreads=1
|minarchthreads=2
|maxarchsize=500000
}} }}
{{Banner holder|collapsed=yes|
{{Help talk:Citation Style 1/Centralized discussions}}
{{tmbox
{{Auto archiving notice |bot=ClueBot III |age=30 |units=days |small=yes}}
| type = notice

| image = ]
== Feature request: |note= parameter ==
| imageright= ]

| text = Some of the templates discussed here were considered for ] at ]. Please review the prior discussions if you are considering re-nomination:
It'd be nice to have a {{para|note}} parameter, so that things like "Source is a blog, but published by a project of the city government; primary but not self-published.", kept with (inside) the citation instead of external to it in an HTML comment. It's pretty common to to use a pseudo-parameter like {{para|note}}, or (in other contexts, like cleanup/dispute templates) {{para|reason}}, for this purpose, but CS1's auto-detection and red-flagging of unrecognized parameters makes this impossible at present. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 16:06, 15 July 2015 (UTC)
*"'''Withdrawn'''" proposal to merge ] with ] on March 2, 2018, see ].
:It would be nicer still to have a {{para|null}} to work around the red-flagging because there are time when as SMcCandlish unrecognized parameters are convenient. -- ] (]) 22:56, 15 July 2015 (UTC)
::I think the problem with the example above is that all of the other parameters in CS1 are for bibliographic data that theoretically at least is understandable to readers and meaningful outside Misplaced Pages. Whereas that comment would be understandable to maybe 1 or 2 out of every 1,000 Misplaced Pages readers – the ones who are familiar with what WP editors usually mean when they call a source "primary". For that sort of thing, an HTML comment embedded in the wikitext seems like exactly the right way to handle it. Let's keep meta comments and WP-specific issues separate from the data. –&nbsp;] (]) 11:21, 16 July 2015 (UTC)
:::SMcCandlish is not proposing a display variable, but one to be used in place of <code><nowiki><!-- a hidden comment --></nowiki></code> as the parameter {{para|reason}} is used in the template {{tl|Clarify}}. -- ] (]) 19:35, 16 July 2015 (UTC)
::::I can see the advantage of a {{para|note}} parameter. I find the {{para|others}} parameter very useful - today I've used it to flag "(published anonymously)". Library catalogs sometimes use square brackets for this. ] (]) 20:19, 16 July 2015 (UTC)

:::::Like this from ]?:
::::::<code><nowiki>{{ cite book | last=Leach | first=William Elford | author-link=William Elford Leach | year=1820 | chapter=Eleventh Room | title= Synopsis of the Contents of the British Museum | place=London | publisher=British Museum | edition=17th| pages=65-70 | others=(published anonymously) }}</nowiki></code>
:::::Specifically these bits:
::::::<code><nowiki>| publisher=British Museum</nowiki></code> and <code><nowiki>| others=(published anonymously)</nowiki></code>
:::::One contradicts the other. And, from the template documentation at ]:
:::::*'''others''': To record other contributors to the work, including illustrators and translators. For the parameter value, write ''Illustrated by John Smith'' or ''Translated by John Smith''.
:::::I think that your use of {{para|others}} as {{diff|Finch|671678177|671554256|you have done}} is an improper use of the parameter.

:::::—] (]) 22:23, 16 July 2015 (UTC)
::::::I was well aware that my use was "improper" but I had wanted to say that the author wasn't specified rather than the publisher wasn't specified. I've now deleted the parameter.] (]) 07:05, 17 July 2015 (UTC)

:::::::At ] it now says: "The name of the author is not specified in the document." If that is so, then who is <code><nowiki>| last=Leach | first=William Elford</nowiki></code>?

:::::::—] (]) 09:31, 17 July 2015 (UTC)
::::::::I was trying to simplify as this isn't an important reference. In the Finch article I've actually cited two sources - the other is Bock 1994. It is Bock who gives the information about the publication: "All the parts of this public guide to the British Museum are unsigned, however, this part was clearly written by Leach as indicated by the fact that he was Keeper of Zoology at the time and by the numerous references to Leach's list of family-group names by his contemporaries." I'm reluctant to add a notelist with this info. It is not uncommon to have "unsigned" articles. I've met them in 19th century book reviews. Sometimes there is a RS giving the authors name. I've seen square brackets used in references when the information isn't present on the title page - such as the author or the year of publication. ] (]) 10:17, 17 July 2015 (UTC)

:::::::::If ''Synopsis ...'' doesn't identify the authors then <code><nowiki>| last=Leach | first=William Elford | author-link=William Elford Leach</nowiki></code> should be removed from that citation. You might then change the note to read: "Attributed to ] in Both 1994." I'm not at all sure that this is even important. Will knowing that Both thinks that Leach wrote "Eleventh Room" help readers find a copy of ''Synopsis ...''?

:::::::::—] (]) 12:13, 17 July 2015 (UTC)

{{od}}The conversation has moved a long way from ]'s request for a {{para|note}} parameter to allow a hidden editor to editors message, similar to {{para|reason}} in the cleanup templates. -- ] (]) 21:23, 30 July 2015 (UTC)
:And it would actually serve the purpose Aa77zz has in mind, anyway. So, I renew the request. All fields I'm aware of, including physical sciences, social sciences, humanities, law, etc., that regularly cite sources do in fact have definitions of "primary source" and so on (even if they sometimes differ in their particulars), so the objection to my example isn't even valid. And it was just an example. There are any number of reasons to use such a parameter, e.g.:
:*{{para|note|Titled "Blood of the Isles" in the UK printing.}}
:*{{para|note|Paywall can be bypassed by request at {{var|URL here}}.}}
:*{{para|note|Page 17 is missing from this Project Gutenberg scan, but is not part of the cited material.}}
:*{{para|note|There is a newer edition, but the cited section has not changed, according to {{var|URL to changes list}}.}}
:*{{para|note|This is a master's thesis, but was reviewed by {{var|Notable Researcher Here}}, and has been cited in 12 journal papers as of July 2015.}}
:etc. There's no reason to put these in messy HTML comments that some editors are apt to delete on sight because they don't like HTML comments. And, really, no one's head will asplode if someone happens to include a more WP-jargon-specific note. They'll just shrug and move on. No one will see them but wikitext-editing users anyway. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 23:15, 30 July 2015 (UTC)

: Are you hoping that the note will appear when a user mouses over the tag as with {{tlx|clarify-inline}} ? ] (] • ]) 08:12, 22 August 2015 (UTC)

== extra text in |edition= detection bug ==

There is a bug in the extra text detector. The current detector was intended to find {{para|edition|2nd ed.}} which would render as
:{{cite book |title=Title |edition=2nd ed.}}
But, it also finds the 'ed' at the end of illustrated, revised, etc:
:{{cite book |title=Title |edition=revised}}

So, I've adjusted the test:
:{{cite book/new |title=Title |edition=2nd ed.}} – should find 'ed.'
:{{cite book/new |title=Title |edition=revised}} – should not find 'ed'
—] (]) 11:38, 25 July 2015 (UTC)
:I'm still seeing the error raised with "revised": <code><nowiki>{{Cite book|authorlink=Maynard Solomon|last=Solomon|first=Maynard|title=Beethoven|edition=2nd revised|location=New York|publisher=Schirmer Books|year=2001|isbn=0-8256-7268-6}}</nowiki></code>:
:*{{Cite book|authorlink=Maynard Solomon|last=Solomon|first=Maynard|title=Beethoven|edition=2nd revised|location=New York|publisher=Schirmer Books|year=2001|isbn=0-8256-7268-6}} <-- shows "{{Font color|green|CS1 maint: Extra text}} (])"
:but not in {{tl|Cite book/new}}:
:*{{Cite book/new|authorlink=Maynard Solomon|last=Solomon|first=Maynard|title=Beethoven|edition=2nd revised|location=New York|publisher=Schirmer Books|year=2001|isbn=0-8256-7268-6}}
:Any reason why {{tl|Cite book/new}} cannot be deployed? -- ] (]) 13:42, 9 August 2015 (UTC)

::{{tlx|cite book/new}} is the same as {{tlx|cite book}} except that it uses the sandbox version of ]. Because every change to the live module dumps a couple of million articles on the job queue, we collect multiple changes in the sandbox before updating the live module.

::—] (]) 14:44, 9 August 2015 (UTC)

== How do you suppress errors when titles are missing? ==

For instance, in the ] article, we have citations such as
<pre>
*{{cite journal
|last1=Pontecorvo |first1=B.
|year=1957
|title=Mesonium and anti-mesonium
|journal=]
|volume=33 |pages=549–551
|bibcode=
|doi=
}} reproduced and translated in {{cite journal
|last1=<!----> |first1=<!---->
|year=1957
|title=<!---->
|journal=]
|volume=6 |pages=429
|bibcode=
|doi=
}} }}
</pre>

Giving out
*{{cite journal
|last1=Pontecorvo |first1=B.
|year=1957
|title=Mesonium and anti-mesonium
|journal=]
|volume=33 |pages=549–551
|bibcode=
|doi=
}} reproduced and translated in {{cite journal
|last1=<!----> |first1=<!---->
|year=1957
|title=<!---->
|journal=]
|volume=6 |pages=429
|bibcode=
|doi=
}} }}
{{FAQ|page=Help talk:Citation Style 1/FAQ}}


== Internet archive print disability book links ==
There's no reason why this should be considered invalid. How do you suppress the error message? <span style="font-variant:small-caps; whitespace:nowrap;">] {] / ] / ] / ]}</span> 15:34, 29 July 2015 (UTC)


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."
:Each citation template is a stand-alone object that produces stand-alone metadata. While the text "reproduced and translated in" visually connects the two in the article, there is no such connection in the metadata because there is no inter-template communication.


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)
:If both journal articles were consulted when writing ], then both templates should have all of the required information and both used separately. If only one journal article was consulted for PMNS matrix then only that template is required (the other, completed template could be added to §Further reading or similar section – perhaps with a note identifying it as the original or the translation).


:Alternatively (as with {{tlx|Hopcroft and Ullman 1979}}) should the link be appended to a reference a note? ] (]) 01:33, 29 November 2024 (UTC)
:When the article's citation style dictates it, you can use {{para|title|none}} in {{tlx|cite journal}} and {{tlx|citation}} when {{para|journal}} is set to suppress the error message. It is my belief that this sort of shorthand is inappropriate because it leaves the metadata incomplete.
::{{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. ==
:The parameters {{para|language}}; {{para|script-title}} for the original language and/or {{para|title}} for a transliterated title; and {{para|trans-title}} for the translated title would be appropriate for the first (original language) template.


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)
:—] (]) 16:16, 29 July 2015 (UTC)
: Seconding this! —&#8288;]<sup>] ]</sup> 22:10, 17 December 2024 (UTC)
:::This rigid attitude is driving people away from using the citation templates, with the result that no metadata at all is produced. For example, my recommendation here (as I have used and seen in several other articles) would be to manually format the second part of the citation (where this article appears in translation, or in some other cases where it appears in an edited volume of journal reprints) since our citation templates are unable to produce elided citations in an appropriate format, the appearance to our readers should be a much higher priority than the quality of the metadata, and (as evidenced above) our template software maintainer is unwilling to fix the problem. —] (]) 22:53, 3 August 2015 (UTC)
:
::Agreed. And see ]. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 23:37, 30 July 2015 (UTC)
:If that is true, why (as I write this) is {{cl|CS1 errors: DOI}} empty?
::<syntaxhighlight lang="wikitext" inline="1">{{PAGESINCATEGORY:CS1 errors: DOI}}</syntaxhighlight> → {{PAGESINCATEGORY:CS1 errors: DOI}}
:—] (]) 22:47, 17 December 2024 (UTC)
::@]: The article ] has a DOI of 10.70460/jpa.v7i1.183 in reference #1 that is incorrectly giving a "<code>Check |doi= value</code>" error. Could you please help fix this? ] (]) 19:41, 19 December 2024 (UTC)
:Fixed in sandbox:
<div style="margin-left:3.2em">{{Cite compare |template=journal |last=McNiven |first=Ian J |date=2016 |title=Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea |journal=Journal of Pacific Archaeology |volume=7 |issue=1 |pages=74–83|doi=10.70460/jpa.v7i1.183 }}</div>
:—] (]) 20:06, 19 December 2024 (UTC)
::Thank you! After this goes live, we could update the articles in ]. ] (]) 17:31, 26 December 2024 (UTC)
:::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)


== cite episode id parameter silently ignored ==
::I would be so glad if {{para|title|none}} worked as claimed, but, hmmm , it doesn't. And you seem to have missed the implication that if the metadata ''must'' always be complete, then only those sources with complete metadata - more precisely, complete ''COinS'' metadata - can be cited. ~ ] (]) 22:05, 3 August 2015 (UTC)


{{tl|cite episode}} currently silently ignores {{para|id}}. I have been using it to add IMDb identifiers to some items, eg. ] using {{tl|IMDb ID}}. I propose that we display the {{para|id}} parameter just like most other CS1 templates. A more elaborate discussion of IMDb in particular as an identifier is at {{slink|Misplaced Pages talk:IMDb link templates#IMDB as an identifier in citations}}. ] (]) 22:44, 4 December 2024 (UTC)
:::But it does work when you {{tq|use {{para|title|none}} in {{tlx|cite journal}} and {{tlx|citation}} when {{para|journal}} is set}}. Rewriting your example as cs1:
:{{para|id}} was:
::::<code><nowiki>{{cite journal |last1=Jones |year=1957 |title=none |journal=Journal}}</nowiki></code>
:*initially supported at ] 25 May 2009
:::::{{cite journal |last1=Jones |year=1957 |title=none |journal=Journal}}
:*reverted at ] 7 August 2009
:::and as cs2:
:*updated to use ] and simultaneously usurped as a vehicle to support {{para|network}} and {{para|station}} at ] 2 April 2012
::::<code><nowiki>{{citation |last1=Jones |year=1957 |title=none |journal=Journal}}</nowiki></code>
:Because it was the goal of the wikitext-to-module conversion to be transparent, it was necessary to overwrite whatever might be assigned to {{para|id}}. I do not recall any discussion here suggesting that we should change that.
:::::{{citation |last1=Jones |year=1957 |title=none |journal=Journal}}
:
:::Yes, I know that the metadata for such citations is incomplete and as such I don't care for this 'style' (which apparently really exists in some scholarly communities). I could have chosen to omit mention this functionality in my first post in this discussion. Of course, if I had omitted it, someone else would have pointed that out.
:I am not enthusiastic about making a change just to support an identifier for a source that editors at ] have determined to be generally unreliable.
:—] (]) 00:20, 5 December 2024 (UTC)
:I've commented at the other discussion, there's general agreement that IMDb should not appear in references. I don't see how a courtesy link to an unreliable source can help with verification. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 01:16, 5 December 2024 (UTC)
::I apologize for the delay in responding. {{u|Gonnym}} of ] two days after I raised the question here, making it difficult for me to determine how the template had been used. I strongly disagree with {{u|Gonnym}}'s claim that these uses of ] were "not what the ID= is for". It's exactly what {{para|id}} is for. Our current guideline is strong on this topic: {{slink|Misplaced Pages:Citing sources#Links and ID numbers}} says "{{tqi|A citation ideally includes a link or ID number to help editors locate the source.}}" Thus, '''according to this ]''', for these audiovisual materials where no link is suitable, '''some identifier ''should'' be included'''. I don't make a point of adding identifiers of this kind to citations generally, and I'm not sure I would advocate for the strength of that guideline's wording, but I believe that identifiers are beneficial to include for obscure content, such as old episodes of broadcast news. Contra {{u|ActivelyDisinterested}}, an identifier is not a ].
::This leads to the question of which identifier to use. Contra {{u|Trappist the monk}}, I don't think it matters whether IMDb is a reliable source. It matters whether its identifiers are ambiguous by being either underspecified or conflations. IMDb's primary benefit isn't the quality of its data or it's market share as {{u|Folly Mox}} suggests, but the breadth of its coverage. Other websites ] itself use its identifiers. If other identifiers were available, I would prefer to use them, but for items with no other identifier, we must use what we have.
::For example, I think this citation (featuring a permanently dead link with no archives available) would be greatly benefited from the addition of an identifier from IMDb or anywhere else:
::* {{cite episode | people=Mansbridge, Peter (host); Zaccardelli, Guiliano (guest) | title=Zaccardelli - On Maher Arar | url=http://www.cbc.ca/mrl3/23745/thenational/archive/zaccintvu-090308.wmv | series=] | publisher=] | airdate=September 3, 2008 | url-status=dead}}
::I can't find anything about this episode on the internet except https://www.cbc.ca/news/canada/zaccardelli-faults-u-s-government-for-arar-s-deportation-1.757351 .
::Perhaps a better solution than linking to IMDb would be to link to Wikidata using {{tl|QID}}. Wikidata's primary web interface isn't very navigable for readers, so perhaps a link target of Reasonator () or SQID ()? Forcing editors who want to add identifiers to create a Wikidata item linked to IMDb instead of using IMDb directly is more work for editors, which you may or may not find desirable. Searching revealed no existing policy or RFCs on using Wikidata an identifier in citations. ] (]) 02:04, 24 December 2024 (UTC)
:::The us of Wikidata on Misplaced Pages still has to comply with the consensus on Misplaced Pages. So using Wikidata to obfuscate a link to IMDb in a reference when there is a consensus against using IMDb in references sounds like a bad idea. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 10:52, 24 December 2024 (UTC)
::::{{re|ActivelyDisinterested}} I wouldn't call this obfuscating a link to IMDb. As far as consensus on Misplaced Pages, we have a content guideline that requires the use of an identifier. That's as strong a consensus as it gets on Misplaced Pages. If this local consensus wants to argue against the use of IMDb as a identifier, I may be willing to accept that if Wikidata is preferred instead. At this local venue, we don't have the option of overruling a content guideline, and so may not forbid both IMDb and Wikidata. ] (]) 15:11, 24 December 2024 (UTC)


:::—] (]) 00:43, 4 August 2015 (UTC) :::::The guideline doesn't require the use of an identifier, and certainly not these proposed identifiers. ] (]) 15:14, 24 December 2024 (UTC)
:::::No there is a strong general consensus across multiple discussions to not link IMDb in references, working out ways to circumvent that consensus is unadvisable.
:::::Also the guideline also doesn't agree with your interpretation. It doesn't say that an ID is ''required'', it says ideally an ID can be included if it helps locate the source - IMDb doesn't help in locating the source. Even if it did require such a link that still wouldn't support your point, as it doesn't say that link must be to IMDb. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 15:29, 24 December 2024 (UTC)
:::I think it ''does'' matter that IMdB is not a reliable source, and expect most editors would agree. Out of curiosity, is the IMDb page on the episode given as example here (which I could not find) any more informative than the which also includes a "shotlist" element allowing for verification of certain quotes? Does the IMDb page truly {{xt|help editors locate the source}}, or is it a user-generated summary of the source? (Incidentally, but Internet Archive are unable to display it, possibly as a result of their recent lawsuit.) ] (]) 13:25, 24 December 2024 (UTC)
::::{{re|Folly Mox}} Thank you for finding those archives! I was unable to do so despite significant effort, and obviously could learn a thing or two about finding them. I would regard the CBC archive summary as essentially the official website for the source, though not a manifestation of the source, and would certainly link to it.
::::I don't expect identifiers to be informative. Is an ISBN informative? An ISBN is a number, not a resolver, a database, or a source. ] (]) 15:39, 24 December 2024 (UTC)


== Request to edit note at top of Category:CS1 maint: unflagged free DOI ==
::::That's fine where the source is a journal. Can you make it work with {{para|chapter/contribution}} where the source is not a journal? ~ ] (]) 21:30, 4 August 2015 (UTC)
:::::And as I said in another post here, having the exact value {{para|title|none}} should work in some other situations. It's very irksome (both for make-work reasons and for accuracy reasons) to have to input fake "titles" for citing something's homepage, as in this example:<br />{{in5}}{{cite web |title=Ministry of Foreign Affairs Homepage |work=MoFA.gov.pk |url= http://www.mofa.gov.pk/index.php |publisher=Government of Pakistan |date=2013 |accessdate=4 August 2015}}<br />which I had to do yesterday at both ] and ] (and "Government of Pakistan" is kind of a lame {{para|publisher}} value). Properly, this would just be something like:<br />{{in5}}<code><nowiki>{{cite web |title=none&lt;!--homepage--> |work=MoFA.gov.pk |url= http://www.mofa.gov.pk/index.php |publisher=Pakistan Ministry of Foreign Affairs |date=2013 |accessdate=4 August 2015}}</nowiki></code><br />but the template won't permit this. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 00:11, 6 August 2015 (UTC)
::::::I would have used {{para|title|Ministry of Foreign Affairs }}, using the brackets to show that "homepage" didn't actually appear in the source. Printed style guides call for just using a description with no italics nor quote marks if a source has no title, but this family of templates can't do that. <small><span class="autosigned">—&nbsp;Preceding ] comment added by ] (] • ]) 00:20, 6 August 2015‎ </span></small><!-- Template:Unsigned -->
::::::::Reasoned, but my point is that it shouldn't be necessary. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 17:20, 6 August 2015 (UTC)
:::::::{{tlx|cite report}} renders title without title styling:
::::::::{{cite report |title=Ministry of Foreign Affairs |type=none |url= http://www.mofa.gov.pk/index.php |publisher=Government of Pakistan |date=2013 |accessdate=4 August 2015}}
:::::::Setting {{para|type|none}} disables the default type annotation.


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


:See ]. Also, I wonder why it dropped from 17. There hasn't been a template update in ages... I suspect someone performed bad fixes just to avoid the categorization. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 12:15, 10 December 2024 (UTC)
::::::::But it's not a report, so it's wrong. I consider lying to the template to make it look right intolerable. If I found an article that did that I would rip all the templates out and switch to a citation style based on a paper style guide. ] (]) 15:39, 6 August 2015 (UTC)
::@]: See ]. I don't know what the correct change should be, so it's better to get consensus here. ] (]) 19:38, 19 December 2024 (UTC)


== Citeref: if no year, use year from date ==
:::::::::You wrote: {{tq|a description with no italics nor quote marks if a source has no title, but this family of templates can't do that.}} I merely point out that, in fact, a member of this family of templates does render a description in lieu of title without styling.


Citeref is an html ID that is used to connect template:harv and template:sfn to cs1.
:::::::::Without doubt, we can concoct a mechanism that disables the default title styling; I once ] a separate title parameter for that purpose which conversation didn't go very far. Since we have parameters like {{para|name-list-format}} and {{para|mode}} we could have something similar for titles where the parameter takes a named constant and applies a defined rule to the content of {{para|title}} or not even bother with a new parameter and just change {{para|mode}} processing to accept a comma delimited list of descriptors so {{tld|cite web}} might have {{para|mode|cs2, desc}} to render a web cite in cs2 style with an unstyled title.


Problem to be solved:
:::::::::—] (]) 16:27, 6 August 2015 (UTC)
::::::::::Works for me. While I wouldn't go as far as Jc3s5h vows (probably tongue-in-cheek), I too object to having to use the wrong template, both on the basis that it's using the wrong template, and the more pragmatic one that the next editor to come along is liable to "fix" it to use the correct one that does the undesirable formatting. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 17:20, 6 August 2015 (UTC)


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


Expected breakages:
::::As before: can you make "none" work with {{para|chapter/contribution}} where the source is not a journal? ~ ] (]) 23:43, 11 August 2015 (UTC)


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


Solution:
:::::—] (]) 13:29, 12 August 2015 (UTC)


It does make sense to look for an year in date, when year is not given. An editor is not likely to duplicate the year when the date has already been given.
::::::No, I am asking for suppression of the "missing or empty title" error message, or explicit suppression of a title. Omitting use of a citation template is even simpler, but that is not a constructive answer.


Add the following to line 4115 of Module:Citation/CS1, keeping the line break that is there.
::::::To be more explicit, can you make {{para|title|none}} (or some variation) suppress the title without having to specify {{tlx|cite journal}} or {{para|journal}}? E.g., for <nowiki>"{{citation |year= 1990 |title=none |author= Folland et al. |chapter= Chap. 7: Observed Climate Variation and Change }}"</nowiki>, which produces: {{hilite|{{citation |year= 1990 |title=none |author= Folland et al. |chapter= Chap. 7: Observed Climate Variation and Change }}}}. ~ ] (]) 20:27, 12 August 2015 (UTC)

:::::::] again? My position as stated there has not changed.

:::::::—] (]) 11:59, 13 August 2015 (UTC)

What, that attitude again? Trappist, you're being a jerk. There are cases where it is quite valid to cite a ''chapter'' (or contribution) in a larger work without directly including the title of the ''work''. (For brevity I omit the winding, tendentious details we have previously traced out.) Yet you are obsessed with requiring a title for all uses. When this was discussed last January (see ]) you grudgingly ("{{tq|I'd rather not if I can avoid it}}") accepted Gadget850's proposal (endorsed by Imzadi) that {{para|title|none}} should suppress the error message. Yet you adamantly refuse to make any concession for other uses, You are fixated on this idea that every citation template must produce "stand-alone" (complete within itself?) COinS metadata, never mind that '''your rigid attitude''' (as enunciated above by David Eppstein) is going to drive people away from using templates and thereby reduce the metadata. The degree of your obsession is indicated in the time and effort you have spent objecting and resisting this (and in developing the misbegotten harvc template), which is likely more time than it would have taken to extend the "none" exception. (Or even better, to just eliminate the title test.) To insist that ALL citations must be "COinS complete" (which implies that only sources with complete COinS data can be cited using templates) is counter-productive. In the end your position is just "I don't like it." That is a very feeble argument. And your intransigence impairs the work of others. ~ ] (]) 21:00, 13 August 2015 (UTC)
:To be honest JJ, you haven't shown consensus for your change. Trappist has provided an alternative method, and your use case is unrelated to the thread above from my read. If you really think the template should change, start an RFC or a straw poll, lay out ''all'' the options (since there are now alternatives), and ask the community whether it makes sense to support what you think should be supported. --] (]) 21:17, 13 August 2015 (UTC)

::Consensus? Off-hand I don't recall where the consensus was for Trappist to ''break'' existing valid usage. Nor was any explicit consensus needed for him to add the 'journal' exception. As to alternatives, the one he provided is {{tl|harvc}}, which is an abomination that makes citation more complex and harder to understand (discussed elsewhere). The other alternatives are: 2) to characterize a non-journal source as a journal (which amounts to metadata corruption); 3) not use citation templates; 4) not write anything requiring citations. #2 seems the least offensive, but even so this "{{tq|lying to the template}}" (as Jc3s5h calls it) is "{{tq|right intolerable}}", while SMc has noted the pragmatic problem where such misuses are "fixed" by subsequent editors. None of these alternatives are good, but everyone else has to accept them because one editor "{{tq|don't care for this 'style'}}"? ~ ] (]) 22:28, 14 August 2015 (UTC)
::: ] is -> that way. --] (]) 04:46, 15 August 2015 (UTC)
::::''That'' way? What is wrong with ''here''? As stated at the top of this very page: "{{tq|This is the talk page for discussing improvements to the Citation Style 1 page}}". Not only is it a matter of a particular 'style' that is raised here, but ] is the very question I would like answered: ''How do you suppress errors when titles are missing?'' Trappist has provided an answer for use with 'cite journal'; my particular question is how to suppress these "errors" for ''non''-journal sources. As Trappist is the ] here, what would be the point of asking for comments from anyone else? ~ ] (]) 20:35, 16 August 2015 (UTC)
:::::Then what you're looking for is {{tl|RFC}}. Continuing to ask and ask and ask is not going to get you anywhere, so ''not'' asking for external comments is ''not'' an option. If consensus decides that it's a valuable change, then we'll go find a template editor/coder to make the desired change. If not, then you have an answer that ''isn't'' decided by a so-called WikiKing. It's really that simple. --] (]) 21:08, 16 August 2015 (UTC)
::::::Izno, are you even paying attention? You seem to be saying (yes?) that ''whatever I ask'' has to go through the hoop of an RfC. Perhaps you would permit me to ask you directly: Where was the Rfc that decided that this "title test" was a valuable change? Or the RfC to add the journal-only "title=none" exception? ~ ] (]) 23:28, 18 August 2015 (UTC)
:::::::Of course I'm paying attention. It seems ''you'' aren't, so I'm done replying. --] (]) 03:23, 19 August 2015 (UTC)
::::::::Your replies seem to consist solely of enabling for Trappist's intransigence, so that's probably a net positive. —] (]) 03:33, 19 August 2015 (UTC)
:::::::::Yours seem to be enabling JJ's. Starting an RFC is ''not'' hard and ''gets results''. Whining that process wasn't followed does not. Want something to change? ]. Can't change it yourself? Ask for help. If help does not want to be given by a certain person, or if it is not obvious ''what the consensus should be'' and so it is not obvious that your desired help is that consensus, find that consensus. How do we do that? An RFC. Or if you think the behavioral issues so insurmountable as to prevent you from such, take it to ]. As I said before, it's simple. Trappist seems unwilling to help you. Guess what that means: an RFC, or ANI. Or identify an expert-editor of templates/Lua, have said person take time to analyze the problem and provide the solution, and ''then'' convince Trappist not to edit war. You know which one gets a positive result? I certainly do. Since you decided to snipe at me instead of taking the literal 5 minutes for yourself to start the RFC, I'll take it that you don't. Or you don't care. One of the two. (And ''yes'', I understand the irony of "taking the literal 5 minutes for yourself...". I'm not the one who wants the change.) --] (]) 05:20, 19 August 2015 (UTC)
::::::::::Izno: I am sorry if you think I am sniping at you. Undoubtedly you understand that I am rather frustrated here; I think you will also understand why I might feel even more frustrated at your suggestion that I should jump through more hoops. But now you have clarified: you are suggesting with how I might deal with the ''intransigence''. Right? In your conception I can seek to build community consensus that a certain state of affairs is desireable (whether it be striking the title-test, adding a non-journal exception, or something else), and request to have it implemented. When the request is refused go back to the community for support - and then what? Sanction Trappist? I think that is where a formal by-the-rules (i.e., "Rfc") approach ends up, and, frankly, I don't like it. (Way too much drama, all around, not because I begrudge 5 minutes, literally or figuratively.) I would prefer to deal with this informally, here. With the understanding that I really don't want to go nuclear, would you have you have any suggestions how else I might proceed? ~ ] (]) 17:34, 19 August 2015 (UTC)
:::::::::::Quick Re On Sniping: No, I was commenting on David's comment at 3:33. --] (]) 18:22, 19 August 2015 (UTC)
::::::::::::Oh. I was wondering if he was chastising me. ~ ] (]) 18:32, 19 August 2015 (UTC)
::::::::::{{u|Izno}}: again, do you have any suggestions how to proceed, without going nuclear? ~ ] (]) 20:33, 23 August 2015 (UTC)



Returning to the original example, I would have written
<pre> <pre>
if Year == nil or "" then
*{{cite journal
Year = string.match(Date, "%d%d%d%d")
|last1=Pontecorvo |first1=B. |author-link=Bruno Pontecorvo
end
|year=1957
</pre> ] (]) 15:00, 15 December 2024 (UTC)
|title=Mesonium and anti-mesonium
|journal=]
|volume=6 |pages=429–431
|url=http://www.jetp.ac.ru/files/pontecorvo1957_en.pdf
}} English version of {{cite journal
|last1=Pontecorvo |first1=B. |author-mask=2
|year=1957
|title=Mezoniy i antimezoniy
|journal=]
|volume=33 |pages=549–551
|url=http://www.jetp.ac.ru/files/pontecorvo1957_ru.pdf
}}
</pre>
which yields
*{{cite journal
|last1=Pontecorvo |first1=B. |author-link=Bruno Pontecorvo
|year=1957
|title=Mesonium and anti-mesonium
|journal=]
|volume=6 |pages=429–431
|url=http://www.jetp.ac.ru/files/pontecorvo1957_en.pdf
}} English version of {{cite journal
|last1=Pontecorvo |first1=B. |author-mask=2
|year=1957
|title=Mezoniy i antimezoniy
|journal=]
|volume=33 |pages=549–551
|url=http://www.jetp.ac.ru/files/pontecorvo1957_ru.pdf
}}
] 15:56, 17 August 2015 (UTC)


:Having the same CITEREF in articles that do not use short form references is not an error that needs solving.
==Italicization of websites in citations==
:The year in {{para|date}} is already used if it is part of the cite. However the example in ] (CITEREFGreen) has no {{para|date}} parameter only {{para|access-date}} and {{para|archive-date}} neither of which would be appropriate to include in a short form reference. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 16:35, 15 December 2024 (UTC)
:{{ec}}
:No. At ] line 4114 is this:
::<syntaxhighlight lang="lua" inline="1">local year = first_set ({Year, anchor_year}, 2); -- Year first for legacy citations and for YMD dates that require disambiguation</syntaxhighlight>
:Normally, <code>Year</code> has been set to <code>nil</code> before this point in the code. <code>anchor_year</code> comes from ].
:
:This example has {{para|date}} but does not have {{para|year}}:
::<syntaxhighlight lang="wikitext" inline="1">{{cite book |title=Title |last=Greene |first=EB |date=15 December 2024}}</syntaxhighlight> → {{cite book |title=Title |last=Greene |first=EB |date=15 December 2024}}
:::{{code|lang=html|{{cite book |title=Title |last=Greene |first=EB |date=15 December 2024}}}}
:Note the value assigned to the <code>id=</code> attribute in the {{tag|cite|o}} tag; it has the year portion from {{para|date}}.
:
:If you know of cs1|2 templates that do not include the year portion from a publication-date parameter ({{para|date}}, {{para|publication-date}}, {{para|year}}) in the <code>CITEREF</code> anchor id, I'd like to see it.
:
:Editors do {{tq|duplicate the year when the date has already been given}}; {{cl|CS1 maint: date and year}} wouldn't be needed else.
:
:It used to be that cs1 templates did not automagically create <code>CITEREF</code> anchor ids. Some time back, there was discussion:
:*{{slink|Help_talk:Citation_Style_1/Archive_46|2=Proposal:_make_ref=harv_the_default_for_CS1}}
:*{{slink|Help_talk:Citation_Style_1/Archive_66|2=make_ref=harv_the_default_for_CS1}}
: Editors in those discussions decided that all cs1|2 templates would create <code>CITEREF</code> anchor ids, needed or not; the automagic <code>CITEREF</code> anchor id can be suppressed with {{para|ref|none}}. This linter thing is an artefact of that decision.
:—] (]) 17:01, 15 December 2024 (UTC)
:Sounds like the problem is the linter. We already have {{clc|Category:Harv and Sfn multiple-target errors}} for where this is an actual issue. ] (]) 12:37, 23 December 2024 (UTC)
::I have worked on Linter errors daily for over six years, and I am unconvinced that the new "Duplicate ID" tracking is identifying many actual errors that cause problems for readers or editors. I haven't had the energy to push back against it though. I just ignore it. – ] (]) 17:49, 25 December 2024 (UTC)


== Generic title ==
If I may revive an (pardon me if there are other threads), I don't understand why we are italicizing websites (thru the {{para|website}} parameter) in citation templates. The argument seems to be that the alias of {{para|website}} is {{para|work}} (meaning you can use one or the other but not both) and obviously {{para|work}}, {{para|journal}}, etc. should be italicized. But the plain fact is that, per the MOS, while we italicize the names of publications, we (generally) do not do so for websites. So these parameters should not be interchangeable. For example: ], ], BroadwayWorld.com and other sites and urls should not be italicized. And while for content found in both a print publication and on its website I may cite '']'' or '']'', if the actual url is being cited (Advocate.com or EW.com) it should not be italicized. This seems like a no-brainer.&mdash; ]<sup>]</sup> 21:16, 31 July 2015 (UTC)
:"Generally" is the key word here, though. The vast majority of the time when a WP article is referring to a website, it's referring to it a business entity (or other kind of entity, e.g. a nonprofit, a free software coding group, a government project, whatever), or in a functional way, e.g. as a service or product. But when we cite it as a source, we're referring to it as a major published work, like a book, journal, magazine, film, etc. So, whether the italics are "required" or not, they're definitely not incorrect when applied in this case. It's consistent and uncomplicated for us to continue italicizing them in source citations. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 09:53, 1 August 2015 (UTC)


is a generic title string. -- ]] 00:59, 19 December 2024 (UTC)
::As a journalist and editor, I need to disagree with the premise that when we cite ], or the ] or ] that these entities transmogrify into "a major published work, like a book, journal, magazine, film, etc."


== Cite case causes CS1 errors ==
::No mainstream source italicizes Amazon.com, British Board of Film Classification, Marvel.com, or, for that matter, ] or ], and none of these entities ''themselves'' italicize their names.


{{tl|Cite case}} maps {{para|court}} to {{para|agency}}, which is no longer supported by {{tl|cite book}} -- see ]. This was brought up at ] a few months ago by @] and @], but I'm bringing it here since this is a better-watched talk page. '''Jay8g''' <small>]•]•]<nowiki />]</small> 04:24, 20 December 2024 (UTC)
::Italicizing dotcom names is not done anywhere else, and I'm afraid I can't find a valid reason that Misplaced Pages should create a non-traditional form of punctuation. Indeed, not even Misplaced Pages italicizes these entities in their respective articles. So I'd like to ask for what compelling reason we do so here. --] (]) 19:43, 29 August 2015 (UTC)


:I ] to {{para|series}}, which renders in the same position in the citation. Hopefully no court cases are part of a series. Haven't checked all 52 transclusions, but none of the dozen or so I checked are in ], so it seems fine. No documentation at this template. ] (]) 17:04, 21 December 2024 (UTC)
:::I agree. Entirely. ~ ] (]) 22:25, 30 August 2015 (UTC)
::::With what, though? Half of that wasn't cogent. British Board of Film Classification is a publisher, not a work of any kind, and what source italicizes itself (except as an incidental stylistic matter)? Looking at an entire bookshelf, only a tiny handful of covers have italic titles, and if you look at the actual title on the frontispiece, and at the top or bottom of each (or every other) page in the book, it is not italicized. This tells us nothing at all about whether WP would italicize the book title in a citation to it. ] of "transmogrification". What I actually said was 'when we cite as a source, we're referring to it as a major published work, like a book, journal, magazine, film, etc. So, whether the italics are "required" or not, they're definitely not incorrect when applied in this case. It's consistent and uncomplicated for us to continue italicizing them in source citations.' This argument has not actually been responded to at all. Instead, Tenebrae told us what some other publishers are doing, and made some unrelated observations. But WP's citation system is not that of any other site or publication, and no case has been made for why WP should treat the titles of all major works consistently (italicizing them by template) except when they're online publications. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 23:21, 30 August 2015 (UTC)
:::::The problem is with how the website parameter is used. Since it's a synonym for work, it should only be used when a work is given as the value. "Amazon.com" is not a work. ] (]) 00:59, 31 August 2015 (UTC)
::::::Exactly. ''Titles'' can be italicized, so we could have ''Amazon.com'', but ''only because it is a title'', not because it refers to a url. As to usage outside of WP: while some aspects of other styles are questionable, and often contradictory, it is still a good idea to consider them: 1) They often reflect a lot of hard-earned experience, and it would be shameful waste to insist on having to re-experience more than is useful. 2) Making WP more different than standard uses makes it harder to edit, and can even lead to subtle problems of reading. ~ ] (]) 18:06, 2 September 2015 (UTC)


== Placement of "translator"/"page" fields ==
:::::::As ] rightly notes, "Amazon.com" is not a work or a title. "Rotten Tomatoes" or "Rotten Tomaotes.com" are not titles. "Sears.com" is not a title. Though I certainly agree with ] that no other reference source, nor newspapers or magazines, italicize dotcom names. There is no reason for Misplaced Pages to have a nonsensical deviation from every grammatical standard in this regard. --] (]) 21:40, 2 September 2015 (UTC)
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}}
{{od}}I think you all are missing a couple key things here:
#the name of the website very rarely includes the domain space (.com, .org, etc)...eg. it's "Misplaced Pages" not "Misplaced Pages.org"
#citation styles are, generally, an exception to the MoS...the citation styles are intended to reflect common citation styles. Of the common citation styles, condsider how the following handle the names of websites:
:#MLA (scroll down to the section "A page on a website")
:#Chicago
:# generally doesn't include the name of a website that's not scholarly website (eg. an online journal), but instead uses "Retrieved from ".
:# and also does not include the name of the website, but rather the url
:# (see page 5) does not italicize the name of the website, but includes "internet" in brackets after the website name, for example: Misplaced Pages .
While there are many exceptions, websites are generally a work/publication. Of the citation styles that include the name of the website, the two general style guides (MLA and Chicago) both italicize the name of the website, while the Vancouver style guide is generally reserved for the physical sciences. ] (]) 01:58, 3 September 2015 (UTC)


ISTM that the "translator" field should be followed by a period, or be placed before the volume/issue number fields, or after the pages field. —] (]) 05:48, 20 December 2024 (UTC)
:I don't think we need to research varied style guidelines. It's already established that websites/urls are generally not italicized at Misplaced Pages, and I'm not aware that we have separate formatting conventions for citations in this regard. The fact that cite templates equate "website" with "work" is the problem, because while one or the other should be required, they do not have the same established formatting style. Period. If I'm citing EW.com, I actually cite |work=] because the website is an obvious platform of that publication. But when you cite a website not affiliated with a conventional publication, yes it may be considered a "major published work" in the sense that it is a reliable source, but I don't see why it should be italicized when it does not meet the criteria for that formatting, and would not be italicized in other contexts at WP. I get SMcCandlish's basic argument, but it is not as if there a requirement somewhere that ''something'' has to be italicized in each citation, or that the source has to be italicized no matter what it is.&mdash; ]<sup>]</sup> 19:24, 3 September 2015 (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 {{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 ==
:::Okay, we need some clarification here, as it seems that "'''website'''" is being used in several different ways. Note that websites usually have a ''proper name'', such as "Google", "The New York Times", "Entertainment Weekly", and "Rotten Tomatoes". Websites also have ''hostnames'', such as (resp.) "www.google.com", "www.nytimes.com", "ew.com", and "wwww.rottentomatoes.com", which often (but not always) incorporate some form of the website's (or parent entity's) name. Hostnames are usually part of ]s (but see below), and as such have specific form and usage in the context of the Internet. ''As hostnames (URLs)'' they are '''not''' italicised, nor capitalized. What are italicized are ''titles'', such as the names of ''books'', ''periodicals'', and (generally) ''works''. A book title in the ''form'' of a hostname, such as ''Amazon.com'', would be italicized, but only because it is a title.


I propose to update the cs1|2 module suite over the weekend 28–29 December 2024. Here are the changes:
:::It seems to me the real issue here is what constitutes a '''title'''; particularly, the ''name'' of a source. "The New York Times" and "Entertainment Week" are the names of both publications and their associated websites; "nytimes.com" and "ew.com" are not. (''Entertainment Weekly'' could have named their website "EW.com", in which case it could be a title, but they did not.) Note that a further distinction can be made between a publi''sher'' and a publi''cation'' (or work). E.g., "Amazon" (the website) might be the publisher of a reveiw found there, but is it a publication? ~ ] (]) 21:34, 3 September 2015 (UTC)


]:
::::Amazon, or Amazon.com, indeed is not a publication. Neither is the publisher Simon & Schuster or simonandschuster.com. Likewise, Sears.com is not a publication, and citing, just for example, the number of stores that Sears owns would be to the website Sears.com, and not ''Sears.com.''
*convert {{cl|CS1 maint: unfit URL}} to properties cat {{cl|CS1: unfit URL}}; ]


]:
::::] is correct that if we're citing something created by the editorial department of '']'' or '']'', we credit the publication rather than ew.com or nytimes.com, and these publications of course are italicized. In such cases, we use "work=" or "newspaper=" or "journal=". But neither ] nor blackanddecker.com is italicized. Same with ] or homedepot.com.
*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; ]


]:
::::The sensible solution, I believe, is to have the "website" field not italicize its contents. That way we're not putting in " ''Amazon.com'' " or " ''Sears.com'' ". If we're citing an actual publication, we have three different fields we can use. --] (]) 22:48, 3 September 2015 (UTC)
*fix extended free doi bug; ]
*bump 5-digit doi prefix limit; ]


]:
:::::Careful! You seem to be sliding back to confusing the ''name'' (as in a ''proper name'') of a website with its ''hostname''. E.g., "Sears.com" is not the name of a website, so should not be put in anywhere. If you want to cite something from the ''Sears'' website (''located'' at "www.sears.com"), then you cite that, not its hostname. If a website is a publication (e.g., "Rotten Tomatoes") then its ''name'' is properly italicized. ~ ] (]) 23:27, 3 September 2015 (UTC)
*reworked hyphen_to_dash(); ]
—] (]) 01:57, 21 December 2024 (UTC)


:I don't have an opinion on most of these but am very happy to see the hyphen-to-dash fix. Thanks! —] (]) 06:01, 21 December 2024 (UTC)
::::::I don't think I am. And I think you are the only person on this thread making the argument that Amazon.com should be italicized. And, certainly, no one italicizes Rotten Tomatoes, not even Rotten Tomatoes, as it is not, by any definition, a publication.
:
::::::What do the other editors think? Aside from one holdout, the consensus seems to be to have the "website" field be non-ital. Do we need to create a formal RfC, or have we reached consensus? --] (])
: 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)
:::::::If all sources are italicized, including sources that contain the cited work, then websites should be italicized for both stylistic consistency and semantic reasons (e.g. to distinguish a webpage or section from the hosting website). <small class="autosigned">—&nbsp;Preceding ] comment added by ] (]) 21:43, 5 September 2015 (UTC)</small><!-- Template:Unsigned IP --> <!--Autosigned by SineBot-->
::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)


== Another generic title: "Conference Paper" ==
:::::::T: You don't seem to understand the distinction I am making, and have thereby misstated my view. Note: I believe we have no disagreement that (e.g.) '''titles''' can be (even should be) italicized. Also, that '''hostnames''' - such as found in URLs, and when ''used as hostnames'' - are NOT italicised. What you don't seem to understand is the {{hilite|use of a hostname in other contexts}}, such as in a title, '''or as the proper name of a website'''. Where I say that "'''A'''mazon.com" - note the capitalization, which is generally not done in urls - ''could'' be italicized it is very much dependent on it being used in the context of a title (like of a book) or proper name. That you think there is consensus to not italicize "website" is only because you have conflated "website" with "hostname". This is indicated by your earlier reference to "{{tq|dotcom names}}". Strictly speaking, there no such things, except in the casual use of "XXXX.com" to refer to the website of some company XXXX. While such uses are in the fashion of a hostname, simply adding ".com" to some name does not make it a hostname, and does not exclude it from italicization. ~ ] (]) 22:05, 5 September 2015 (UTC)
::::::::I believe this is a valid point. The print product Grapes of Wrath, delivered by a printer, is not the book ''Grapes of Wrath'' delivered by a publisher. The digital product Amazon.com, delivered by a software developer, is different from the website ''www.amazon.com'' delivered by an online publisher. In most cases what is cited as the source is the content, not the "delivery method/packaging", as it were.] (]) 14:43, 6 September 2015 (UTC)
{{outdent}}
I can only repeat my previous point. At present, {{para|website}} is simply a synonym of {{para|work}}, and so its value should be italicized, in line with the usual style for a work. It would be possible to give the two parameters a different meaning, but this would require a huge number of existing uses to be checked. Since "website" seems to be widely misunderstood, perhaps its use should be deprecated? ] (]) 19:28, 6 September 2015 (UTC)


See ] —] (]) 05:32, 24 December 2024 (UTC)
:I agree that "website" (as in "work") can be italicized; the problem seems to be where people mistakenly equate it with the url/hostname. Perhaps the documentation should be clearer about this. And perhaps a bot could flag all the instances where the value of {{para|website}} is a valid hostname. I am reluctant to deprecate {{para|website}} as I think it has a good use, but if the problem is too great then that is something to consider. ~ ] (]) 21:34, 6 September 2015 (UTC)


== certain parameters not displaying on ']' ==
::Editors were perplexed or confused with the term 'work'. In response to ], {{para|website}} became an alias of {{para|work}}.


For some reason, {{tl|cite map}} seems to have the following issues below:
::—] (]) 22:12, 6 September 2015 (UTC)


{{cite compare |template=map |comment=In this first instance, the parameter {{param|volume}} isn't being shown after {{param|others}}, unlike in the other instances, and neither is {{param|issue}}, while {{param|title}} is displayed in ''italics'', the latter two issues, like in the third instance. |header=(with 'title' parameter, without 'map' or 'website' parameters) |last=Bloggs |first=Joe |author-link=Joe Bloggs |date={{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} |editor-last=Doe |editor-first=John |editor-link=John Doe |title=title |url=https://www.example.com/ |format=format |type=type |edition=57 |others=others |volume=52 |issue=38}}
:::Suggesting that it is the ''concept'' of "website" as a "work" that is confusing. ~ ] (]) 22:36, 6 September 2015 (UTC)


{{cite compare |template=map |comment=In this second instance, the parameter {{param|edition}} isn't being shown at all, either after {{param|type}}, unlike in the first instance, or after {{param|format}}, unlike in the third or fourth instances, while the parameter {{param|title}} is displayed in "quotation marks", like in the fourth instance. |header=(with 'title' and 'website' parameters, without 'map' parameter) |last=Bloggs |first=Joe |author-link=Joe Bloggs |date={{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} |editor-last=Doe |editor-first=John |editor-link=John Doe |title=title |url=https://www.example.com/ |format=format |type=type |edition=57 |website=website |others=others |volume=52 |issue=38}}
::::So Amazon.com should not be italicized by www.amazon.com should, is what you're saying? First, I'm not sure how often we would be citing a raw URL. Second, I don't see URLs italicized in any mainstream source. I'm not sure it's a positive thing for WIkipedia credibility to be adopting highly non-standard forms of citation. I'm not sure this is any different from citing authors by first name rather than last. That would be a highly non-standard way of citing, and would only make Misplaced Pages look eccentric. I'm thinking that italicizing URLs where virtually no one else does might do the same. --] (]) 17:03, 7 September 2015 (UTC)
:::::No, I believe he's saying the reverse. Amazon.com is the name of a website, and as a major published work, it would be itaicized if included in a citation. On the oter hand, www.amazon.com is the hostname and wouldn't be itaicized nor would we need to cite it. <span style="background:#006B54; padding:2px;">''']&nbsp;]'''</span> 17:59, 7 September 2015 (UTC)


{{cite compare |template=map |comment=In this third instance, the parameter {{param|issue}} isn't being shown, while {{param|title}} is displayed in ''italics'', both like in the first instance. |header=(with 'map' and 'title' parameters, without 'website' parameter) |last=Bloggs |first=Joe |author-link=Joe Bloggs |date={{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} |map=map |map-url=https://www.example.com/map/ |type=type |editor-last=Doe |editor-first=John |editor-link=John Doe |title=title |url=https://www.example.com/ |format=format |edition=57 |others=others |volume=52 |issue=38}}
{{od}}Misplaced Pages is highly non-standard. Contributors are not vetted. Sources are not systematically checked. Citation styles are not enforced. Editors have widely varying expertise. Consumers cannot be assumed to be experts. The present problem should I think take this non-standard approach into account. If the source is a website (a collection of pages connected by hyperTEXT links and employing the digital equivalent of a markup language) then should be treated the same way CS1 treats other similar collections in other media.


{{cite compare |template=map |comment=In this fourth instance, the parameter {{param|website}} isn't being shown, unlike in the second instance, while {{param|title}} is displayed in "quotation marks", like in the second instance. |header=(with 'map', 'title' and 'website' parameters) |last=Bloggs |first=Joe |author-link=Joe Bloggs |date={{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} |map=map |map-url=https://www.example.com/map/ |type=type |editor-last=Doe |editor-first=John |editor-link=John Doe |title=title |url=https://www.example.com/ |format=format |website=website |edition=57 |others=others |volume=52 |issue=38}} ] (]; ]) 08:46, 26 December 2024 (UTC)
== deprecate enumerator-in-the-middle parameters ==
:Not really 'issues'. All of your examples are correct except for the fourth example:
:# cites a standalone or sheet map; {{para|volume}} and {{para|issue}} are inappropriate
:# cites a map in a periodical; the periodical parameters are: {{para|journal}}, {{para|magazine}}, {{para|newspaper}}, {{para|periodical}}, {{para|website}}, {{para|work}}; {{para|edition}} is ignored in the final assembly process
:# cites a map in a book or encyclopedia; cs1|2 book and encyclopedia citations do not support {{para|issue}} (a periodical parameter)
:# doesn't know what you're citing because you included {{para|map}}, {{para|title}}, and {{para|website}} which is an attempt to cite a map in a book and simultaneously in a periodical; don't do that.
:Cast about in the archives of this talk page for the discussions we had when developing the current version of {{tlx|cite map}}.
:—] (]) 15:02, 26 December 2024 (UTC)
:: I accidentally said the word {{'}}''italics''{{'}} instead of {{'}}"quotation marks"{{'}} for the fourth instance above in {{tl|cite map}} when I started this discussion; I just replaced that instance of the word 'italics' with 'quotation marks' now. -- ] (]; ]) 05:32, 27 December 2024 (UTC)


== Reformat dates v2 ==
See ].


Previous: ]<br>
I propose to deprecate these parameters and standardize on the enumerator-at-the-end form. The numbers in the preference ratio column are caclulated from the values in the tables in the archived discussion: (terminal enumerator ÷ medial enumerator). Where the cells are blank the denominator is zero.
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)
{|class="wikitable"
:What you mean by {{tq|variable that would allow me to display all dates}}.
|+CS1 parameters to be deprecated
:
! parameter!!extant replacement!!preference ratio
: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?
|-
:
|{{para|author''n''-last}} || {{para|author-last''n''}}||2.51
: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?
|-
:
|{{para|author''n''-first}} || {{para|author-first''n''}}||2.36
:Do you have an example sandbox somewhere that shows what you want and what you're getting?
|-
:—] (]) 18:37, 29 December 2024 (UTC)
|{{para|author''n''-link}} || {{para|author-link''n''}}{{dagger}}||1.91
::{{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).
|{{para|author''n''link}} || {{para|authorlink''n''}}||1066.9
|-
|{{para|author''n''-mask}} || {{para|author-mask''n''}}{{dagger}}||101.43
|-
|{{para|author''n''mask}} || {{para|authormask''n''}}||23.23
|-
|{{para|editor''n''-link}} || {{para|editor-link''n''}}{{dagger}}||1.54
|-
|{{para|editor''n''link}} || {{para|editorlink''n''}}||7.24
|-
|{{para|editor''n''-mask}} || {{para|editor-mask''n''}}{{dagger}}||3.17
|-
|{{para|editor''n''mask}} || {{para|editormask''n''}}||16
|-
|{{para|editor''n''-first}} || {{para|editor-first''n''}}||1.42
|-
|{{para|editor''n''-given}} || {{para|editor-given''n''}}||
|-
|{{para|editor''n''-last}} || {{para|editor-last''n''}}||1.58
|-
|{{para|editor''n''-surname}} || {{para|editor-surname''n''}}||
|-
|{{para|subject''n''-link}} || {{para|subject-link''n''}}{{dagger}}||47
|-
|{{para|subject''n''link}} || {{para|subjectlink''n''}}||
|}{{dagger}} these parameters are the canonical form
—] (]) 13:26, 4 August 2015 (UTC)
:Makes more conceptual sense the other way around. <code>editor2-last</code> implies the last name of editor #2, but <code>editor-last2</code> implies the second surname of the editor. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 23:33, 5 August 2015 (UTC)
::I agree with SMC on this point and think it would make more sense to keep the number in the middle than to have it out there hanging at the end. --] (]) 17:47, 6 August 2015 (UTC)

:::The implication arises from the sense of the digit binding more tightly than the hyphen. (I.e., to "last" rather than "editor-last".) On the otherhand, when indexing a list of authors/editors I have found it most useful to have the index digit next to the equals sign, which gives the index better visibility, and provides a handy anchor for a regex. It's also easier to scan a list of authors/editors when the index is not buried inside the string. Which all might explain the medial location is not as widespread as the terminal form. I prefer the latter. ~ ] (]) 20:16, 7 August 2015 (UTC)
::::And yet others of us view the number as better in the middle. Comparing {{para|editor2-last}} and {{para|editor-last2}}, I parse the first as being the last name of the second editor and the second as the second last name of the (singular) editor. YMMV, and as far as I'm concerned, there's no harm in retaining both forms. <span style="background:#006B54; padding:2px;">''']&nbsp;]'''</span> 20:44, 7 August 2015 (UTC)

:::::I am sympathetic to both points of view though my personal preference is terminal enumerator. I have added a column to the table that shows that overall, editors who have used these enumerated parameters generally prefer to use the terminal enumerator forms.

:::::—] (]) 12:26, 8 August 2015 (UTC)
::::::That's surely skewed by how they're documented, and likely also by some individuals, perhaps even with AWB scripts, manually changing them to your "preferred" version. I know I've occasionally seen diffs that include this change along with other "general cleanup". <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 04:06, 9 August 2015 (UTC)

:::::::Of course it's possible that the documentation has influenced one style choice over the other and its possible that editors change extant parameters to suit their own preferences. I don't know that AWB, as part of its general fixes, makes this kind of change; I haven't noticed changes of that kind. If you are suggesting that I have written an AWB script that changes enumerator-in-the-middle to enumerator-at-the-end, then you would be wrong.

:::::::—] (]) 12:35, 9 August 2015 (UTC)
*'''Strongly oppose deprecation'''. These are still listed as the primary parameter names for {{tl|citation}} and we should not diverge the CS1 and CS2 templates so far from each other as to deprecate one template's parameters in the other. Additionally, these are used by software for creating citation templates (I know, because I have written such software myself). What purpose is served by this change? What does it make better? It seems to me to be purely a foolish consistency. Finally, I note that once again Trappist is proposing major changes that relate to {{tl|citation}} without even bothering to mention the discussion on ]. Trappist, you have been told over and over again: don't do that. —] (]) 17:14, 8 August 2015 (UTC)
*:I don't understand why you think this affects {{tl|citation}}... when it doesn't. --] (]) 21:09, 8 August 2015 (UTC)

:::This change affects {{tlx|citation}} because {{tld|citation}}, despite being cs2, is rendered by ].

:::—] (]) 21:52, 8 August 2015 (UTC)
::::Yes, and also because it is desirable to continue the current state of affairs in which we can change CS1 to CS2 or vice versa just by changing the template name. Not that changing the citation style of an article is frequent nor usually a good idea. But finding articles that mix the two styles is common enough, and changing them to use only one is usually a (minor) improvement. Thanks to recent improvements it's also possible to do this using a parameter but changing the actual template name seems less likely to encourage more inconsistency later. —] (]) 06:27, 9 August 2015 (UTC)

:::::Standardizing on terminal enumerators will not prevent editors from changing {{tq|CS1 to CS2 or vice versa just by changing the template name.}} Standardizing on lowercase parameter names did not change that nor did standardizing on the hyphen as a separator in parameter names change that.

:::::—] (]) 12:35, 9 August 2015 (UTC)
::{{cs2}} is distinguished from {{cs1}} by its element separator (comma vs period), by lowercase static text (retrieved..., archived from ..., written at ..., etc. vs Retrieved..., Archived from ..., Written at ..., etc.), by terminal punctuation (none vs period), and cs2 automatically sets {{para|ref|harv}}, cs1 doesn't. cs2 is not distinguished from cs1 by some subset of the commonly shared parameters.

::The primary documentation for both cs1 and cs2 is {{tlx|csdoc}}. I grant that {{tld|csdoc}} has a cs1 bias, so does ] though I did a bit of work on that recently that removed some of the bias.

::Of the sixteen parameters in the above table, these seven are found in ] outside of the {{tld|csdoc}} content:
:::{{para|author''n''link}}
:::{{para|author''n''-link}}
:::{{para|editor''n''-first}}
:::{{para|editor''n''-last}}
:::{{para|editor''n''-link}}
:::{{para|editor''n''-given}}
:::{{para|editor''n''-surname}}
::Are we to believe then that the other nine are not or should not be supported by {{tlx|citation}}?

::Yep, it is just for consistency whether you think it foolish or not. This choice is no different from the choice we made to standardize on parameter names that use hyphens instead of underscores or spaces; and standardize on lowercase instead of capitalized or camel-case. Choosing one flavor or the other is merely for consistency.

::—] (]) 21:52, 8 August 2015 (UTC)
:::Yes, I think it is foolish to suddenly kill off the primary documented parameter choices of the sister CS2 style, that our templates have been handling perfectly well, for the sake of no reason at all but neatness. The costs of this proposal involve breaking software or forcing the developers of the software to make parallel changes, breaking the mental model of who knows how many editors (as an example, I am still months after you made this change unable to remember to use contribution-url= in place of url= for the url of book chapters, and this is causing actual citations to be formatted wrong), forcing edits to who knows how many live citations after the red error messages start showing up, etc. The benefit of the proposal is appeasing the OCD of one single software developer who wants all the ducks to be perfectly lined up in a precise row. It's a bad idea. —] (]) 02:52, 9 August 2015 (UTC)
::::Agreed (other than the assumption of mental issues), and as I said earlier, the proposed "norms" don't make conceptual sense: {{para|author2-last}} implies the surname of the second author, while {{para|author-last2}} implies the second surname of the (singular) author. I.e., there are multiple, independent reasons not to deprecate this, and at least one to actually prefer the form Trappist wants to deprecate. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 04:00, 9 August 2015 (UTC)

::::Deprecation does not {{tq|suddenly kill off}} anything.

::::—] (]) 12:35, 9 August 2015 (UTC)
:::::Must be why I still have an ant problem. This bug spray says "Deprecates on Contact!" <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 17:41, 10 August 2015 (UTC)
::::::<nowiki>:-} </nowiki> ~ ] (]) 23:38, 11 August 2015 (UTC)

== error handling for parameters with defined values ==

As the result of a conversation ], I have added a function <code>is_valid_parameter_value()</code> that checks a parameter's value against a list of accepted values. If the parameter value is not a member of the accepted list, the function emits an invalid parameter error. There is code in the current live module that detects these kinds of errors for {{para|mde}} and {{para|name-list-format}}. This new code extends that functionality to several other parameters.
;{{para|nopp}}
:accepted values are 'yes', 'true', 'y'
:*{{cite book/new |title=Title: nopp=y |page=pp. 45-46 |nopp=y}}
:*{{cite book/new |title=Title: nopp=true |page=pp. 45-46 |nopp=true}}
:*{{cite book/new |title=Title: nopp=yes |page=pp. 45-46 |nopp=yes}}
:*{{cite book/new |title=Title: nopp=1 |page=pp. 45-46 |nopp=1}}
;{{para|name-list-format}}
:accepted value is 'vanc'
:*{{cite book/new |title=Title: name-list-format=vanc |name-list-format=vanc |last=Last |first=Fred George |last2=Laster |first2=A. B. |last3=Lastest |first3=First}}
:*{{cite book/new |title=Title: name-list-format=venc |name-list-format=venc |last=Last |first=Fred George |last2=Laster |first2=A. B. |last3=Lastest |first3=First}}
;{{para|mode}} – accepted values are 'cs1', 'cs2'
:*{{citation/new |title=Title: mode=cs1 |mode=cs1 |last=Last |first=Fred George |last2=Laster |first2=A. B. |last3=Lastest |first3=First}}
:*{{cite book/new |title=Title: mode=cs2 |mode=cs2 |last=Last |first=Fred George |last2=Laster |first2=A. B. |last3=Lastest |first3=First}}
:*{{cite book/new |title=Title: mode=cs3 |mode=cs3 |last=Last |first=Fred George |last2=Laster |first2=A. B. |last3=Lastest |first3=First}}
;{{para|dead-url}}
:accepted values are 'yes', 'true', 'y', 'no'
:*{{cite web/new |url=//example.com |title=Title: dead-url=y |dead-url=y |archive-url=//example.org |archive-date=2015-08-07}}
:*{{cite web/new |url=//example.com |title=Title: dead-url=true |dead-url=true |archive-url=//example.org |archive-date=2015-08-07}}
:*{{cite web/new |url=//example.com |title=Title: dead-url=yes |dead-url=yes |archive-url=//example.org |archive-date=2015-08-07}}
:*{{cite web/new |url=//example.com |title=Title: dead-url=no |dead-url=no |archive-url=//example.org |archive-date=2015-08-07}}
:*{{cite web/new |url=//example.com |title=Title: dead-url=f |dead-url=f |archive-url=//example.org |archive-date=2015-08-07}}
;{{para|subscription}}
:accepted values are 'yes', 'true', 'y'
:*{{cite book/new |title=Title: subscription=y |subscription=y}}
:*{{cite book/new |title=Title: subscription=true |subscription=true}}
:*{{cite book/new |title=Title: subscription=yes |subscription=yes}}
:*{{cite book/new |title=Title: subscription=1 |subscription=1}}
;{{para|registration}}
:accepted values are 'yes', 'true', 'y'
:*{{cite book/new |title=Title: registration=y |registration=y}}
:*{{cite book/new |title=Title: registration=true |registration=true}}
:*{{cite book/new |title=Title: registration=yes |registration=yes}}
:*{{cite book/new |title=Title: registration=1 |registration=1}}
Have I missed any others?
—] (]) 17:11, 7 August 2015 (UTC)
:I did:
;;{{para|ignore-isbn-error}}
::accepted values are 'yes', 'true', 'y'
::*{{cite book/new |title=Title: ignore-isbn-error=y |ignore-isbn-error=y |isbn=1234567890}}
::*{{cite book/new |title=Title: ignore-isbn-error=true |ignore-isbn-error=true |isbn=1234567890}}
::*{{cite book/new |title=Title: ignore-isbn-error=yes |ignore-isbn-error=yes |isbn=1234567890}}
::*{{cite book/new |title=Title: ignore-isbn-error=1 |ignore-isbn-error=1 |isbn=1234567890}}
;;{{para|no-tracking}}
::accepted values are 'yes', 'true', 'y'
::*{{cite book/new |title=Title: no-tracking=y |no-tracking=y}}
::*{{cite book/new |title=Title: no-tracking=true |no-tracking=true}}
::*{{cite book/new |title=Title: no-tracking=yes |no-tracking=yes}}
::*{{cite book/new |title=Title: no-tracking=1 |no-tracking=1}}
:—] (]) 17:43, 7 August 2015 (UTC)
::and another:
;;;{{para|last-author-amp}}
:::accepted values are 'yes', 'true', 'y'
:::*{{cite book/new |title=Title: last-author-amp=y |last-author-amp=y}}
:::*{{cite book/new |title=Title: last-author-amp=true |last-author-amp=true}}
:::*{{cite book/new |title=Title: last-author-amp=yes |last-author-amp=yes}}
:::*{{cite book/new |title=Title: last-author-amp=1 |last-author-amp=1}}
::—] (]) 14:46, 10 August 2015 (UTC)
:::I've created a table of keywords in ] so that the keywords can be defined and the same reused; 'yes, true, y' is used for several parameters – no need to keep separate lists.
:::—] (]) 17:19, 15 August 2015 (UTC)
::::Why ], when we have {{tlx|yesno}}? --] (]) 17:34, 15 August 2015 (UTC)
:::::template vs module.
:::::—] (]) 17:39, 15 August 2015 (UTC)
::::::] does exist. My concern using it in general would be that in a number of cases we don't have a boolean consideration (e.g. yes v. no) but instead an enumerated comparison. --] (]) 19:02, 15 August 2015 (UTC)

== AWB or bot opportunity to fix 1000+ missing author errors ==

There are over 1,000 (around 1,200, I think) articles on towns in India that have citations with a {{para|first}} but no {{para|last}}. I have changed a few hundred of these from {{para|first}} to {{para|publisher}}, but my fingers are getting tired. If someone with AWB or some nice bot code wants to have a go at them, do a search for this:

insource:/\|first=Registrar General...Census Commissioner, India/

is a sample change.

If it would help to have a list of these article titles, let me know, and I'll compile one. – ] (]) 20:10, 9 August 2015 (UTC)
:Note that since the most recent edit to the CS1 module, these citations with a {{para|first}} but no {{para|last}} no longer generate a missing author error. The example article you give no longer shows a missing author error if you look at the revision immediately before your edit. The count of articles populating {{cl|CS1 errors: missing author or editor}} has dropped precipitously since the recent edit to the CS1 module, from almost 9000 articles to a current count of roughly 1300. ] (]) 00:22, 10 August 2015 (UTC)

::Fixed in the sandbox. See ]

::—] (]) 00:28, 10 August 2015 (UTC)
:::True, but these are definitely errors, and they are all of the same type, so a script or bot should be able to fix them quickly and easily. – ] (]) 03:34, 10 August 2015 (UTC)

== vancouver errors ==

From ] this cite:
:<code><nowiki>{{cite journal | vauthors = Lin F, Wang Hy, Malbon CC | title = Gravin-mediated formation of signaling complexes in beta 2-adrenergic receptor desensitization and resensitization | journal = J. Biol. Chem. | volume = 275 | issue = 25 | pages = 19025–34 | year = 2000 | pmid = 10858453 | doi = 10.1074/jbc.275.25.19025 }}</nowiki></code>
::{{cite journal | vauthors = Lin F, Wang Hy, Malbon CC | title = Gravin-mediated formation of signaling complexes in beta 2-adrenergic receptor desensitization and resensitization | journal = J. Biol. Chem. | volume = 275 | issue = 25 | pages = 19025–34 | year = 2000 | pmid = 10858453 | doi = 10.1074/jbc.275.25.19025 }}
The error occurs because the second author includes a lowercase initial. The author's name, according to the doi link is Hsien-yu Wang.

According to surnames are listed first followed by one or two uppercase initials. In this case, because the author is Asian, Hsien-yu is the surname and Wang the given name. Has PubMed got it wrong?

What advice should be given at ] to editors who encounter this sort of error?

—] (]) 15:37, 10 August 2015 (UTC)

:Few editors follow this page. You might to better to ask at the humanities reference desk about how asian authors shorten their name when using the Roman alphabet. Then there is the additional problem of how journals that use Vancouver style shorten the names of asian authors, which could be different. ] (]) 16:19, 10 August 2015 (UTC)

{{Ping|Trappist the monk}} It's also unlikely that the order given is wrong. Chinese names in the form Foo-bar are usually given names, so a Western source would be likely to call this person Hsien-yu Wang, who would be Wang Hsien-yu at home, and the proper family-name-first version in the Western bibliographic style is Wang, Hsien-yu. The "Foo-bar" convention is not universal, and the same name will often be rendered "Foo-Bar", and sometimes "Foo Bar" or even "Foobar", depending on how sources treat Chinese names in latin script. I encounter this issue a lot in ] writing, since China fields many players of pool, snooker, and carom billiards. "Foo-bar" seems to be something of a {{em|spreading}} convention, but it may vary geographically (you have Taiwan, Hong Kong, Macau, and Singapore to factor in, plus Chinese diaspora in the US, etc., and it's highly unlikely they're all converging on exactly the same format). Anyway, the point being you can get away with "Wang HY". <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 17:05, 10 August 2015 (UTC)
:Even western authors with hyphenated names should sometimes have the second part of the name included in the initials. And sometimes the correct initials really do include lower-case letters. I have a Belgian co-author named Jean-Claude who insists that the correct abbreviation of his name is J.-Cl. On the other hand I know a Japanese author named Ken-ichi who wants his name abbreviated K. rather than K.-I. or K.-i. My general feeling is that any attempt to automatically deduce how to rearrange human names is doomed to at least occasional failure (as usual, see ) so it is essential that there be some workaround that we can use when the machines get it wrong. In this case, "Hy" is the correct Vancouver initialization and there should be some way of persuading the template to allow it. —] (]) 17:21, 10 August 2015 (UTC)
:: Agreed. &ndash; S.McC.<br />PS: I wasn't meaning to imply "do the wrong thing to make the template happy", but rather that since the name is a transliteration anyway, in a style that's not used consistently, that it might not matter in this case. There are Europeans who abbreviate names like Christophe as "Ch.", so my lackadaisicalness on this wouldn't help them. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 17:37, 10 August 2015 (UTC)

::The rules for Vancouver system author name lists prohibit hyphens in the given name initials, see: . The error mentioned at the start of this conversation is not the result of an {{tq|attempt to automatically deduce how to rearrange human name}}, but arises because ] cannot know if the lowercase 'y' is intentionally lowercase (cases like this or as the result of Romanization: Θ → Th) or a typo. The error can be suppressed after review by treating the name as an institutional name: {{para|vauthors|Lin F, ((Wang Hy)), Malbon CC}}

::—] (]) 15:13, 14 August 2015 (UTC)

== DOI throwing an error ==
{{Disregard|PEBCAK!}}
The DOI found is not accepted by the DOI checking code called by {{tlx|Cite journal}}. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 16:54, 10 August 2015 (UTC)
:(Edit conflict: Trappist, you accidentally removed my earlier comment.)
:Looks ok to me: {{cite journal
| last1 = Pérez-García | first1 = Alejandro
| last2 = Romero | first2 = Diego
| last3 = Fernández-Ortuño | first3 = Dolores
| last4 = López-Ruiz | first4 = Francisco
| last5 = De Vicente | first5 = Antonio
| last6 = Torés | first6 = Juan A.
| doi = 10.1111/j.1364-3703.2008.00527.x
| issue = 2
| journal = Molecular Plant Pathology
| pages = 153–160
| title = The powdery mildew fungus Podosphaera fusca (synonym ''Podosphaera xanthii''), a constant threat to cucurbits
| volume = 10
| year = 2009}} Maybe you're incorrectly including the period that pubmed puts after it? —] (]) 17:04, 10 August 2015 (UTC)

::Not intentionally.

::—] (]) 17:10, 10 August 2015 (UTC)
:Don't include the terminal period that PubMed includes:
::{{cite journal |title=Title |journal=Journal |doi=10.1111/j.1364-3703.2008.00527.x.}}
:The doi checking code looks for a terminal comma or period. If one of those is found, the code emits the error message. Was the ] insufficient to the task?

:—] (]) 17:06, 10 August 2015 (UTC)

:@David: Ah, yeah, that would be it. Derp. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 17:07, 10 August 2015 (UTC)
:@Trappist: Yeah, it says "Check {{para|doi}} value (])", and I looked at the help but somehow did not see "does not end with punctuation". Total PEBCAK on my part. Time for coffee. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 17:30, 10 August 2015 (UTC)

== Suppress original URL ==

{{mdf|Module_talk:Citation/CS1/Feature_requests#Suppress_original_URL}}
Discussion moved here for a somewhat broader audience.

When urls die for whatever reason, normal practice is to keep the url and if possible, add {{para|archive-url}} and {{para|archive-date}}. Doing so links {{para|title}} to the archive copy and links static text provided by the template to the original url.

It has been suggested that we adopt a mechanism to suppress the original url when it is not dead in the sense of 404 or gateway errors and the like, but dead in the sense that the url has been taken over by someone and is now a link farm or advertising or phishing or porn or other generally inappropriate content.

To accomplish this I have suggested modifying the code that handles {{para|dead-url}}. This parameter takes a limited set of defined keywords (yes, true, y, no) and adjusts the rendered output accordingly. We could add another keyword that would render the static text in the same way as {{para|dead-url|yes}} except that this value would not link the static text with the original url.

The question is: What should this defined keyword be? These have been suggested: hide, nolink, origspam, originalspam, spam, advert, phishing, fraud, unfit, usurped.

Is any of these the best keyword? Is there another keyword that would be better?

—] (]) 15:05, 12 August 2015 (UTC)
:Commenters are encouraged to read through the original thread also. --] (]) 15:32, 12 August 2015 (UTC)

:I suggest '''topic-changed'''. This covers complete takeover by an undesireable publisher, but also covers the case of the original publisher no longer having a page that supports the material in the article. For example, software publisher X had a page about a quirk of version 99 of their software, which Misplaced Pages described with a citation to the relevant X webpage. Once version 100 of the software is released, X removes the relevant webpage and does not provide information about the quirk anywhere on their site. ] (]) 15:43, 12 August 2015 (UTC)
:The purpose of {{para|dead-url}} is to indicate for pages which are still live that they can be accessed (when an archive url is also present) (for the case of the original publisher). So from this point of view, adding an archiveurl solves that "broader" issue. Even in the case where an archiveurl cannot be identified and subsequently provided, you can set deadurl to yes and still have that case covered. --] (]) 16:06, 12 August 2015 (UTC)

::I don't see any benefit in having citations provide links to dead URLs. However, if other people do, then I suggest simply {{para|dead-url|nolink}} to describe the function, with an update to the template documentation describing when it is appropriate (or not) to not provide the link to a dead URL. Thanks! ] (]) 19:01, 12 August 2015 (UTC)
:::The benefit I see to providing links to dead URLs (not necessarily clickable) is that the editor who marked the URL as dead might not have the knowledge to find a substitute at a related web page, but a later editor might have that knowledge; the dead URL serves as a clue for finding a substitute. ] (]) 19:18, 12 August 2015 (UTC)
::::{{ping|Jc3s5h}} I agree that a later editor may be able to use the dead URL to find a substitute web page, and the archiveurl does not necessarily contain the original URL. I'm all for keeping the dead URL in the citation template for this purpose. However, I suggest that the citation only provide one link for the reader when the original URL is dead. Thanks! ] (]) 02:38, 13 August 2015 (UTC)

:What about adding a few more keywords, say:
:*<code>usurped</code> for domains now operated by a different entity (covers advertising, linkfarm, fraud, spam, phishing, or site/content unrelated to original)
:*<code>purged</code> for domains operated by original entity but for which the original website content has been deleted
:*<code>abandoned</code> for domains that are no longer registered
:The latter may not as desirable as the first two, as domain registrations can fluctuate. <font color="#8b4513">]</font><font color="#ee8811">]</font> 21:53, 12 August 2015 (UTC)

::Multiple keywords are possible. For the purposes of this conversation, I don't think abandoned domains need to be hidden because such domains are the definition of dead. I see no reason to hide links like that.

::—] (]) 10:22, 13 August 2015 (UTC)

Since it has gotten quiet here I have implemented {{para|dead-url|usurped}} to suppress the link to the original url:
{{cite compare |old=no |mode=news |first=Daniel |last=Frankel |title=''Artisan pulls the repackaged Hip Hop Witch'' |url=http://www.videobusiness.com/article/CA616459.html |publisher=Video Business |date=June 9, 2003 |accessdate=29 March 2009|archiveurl= https://web.archive.org/web/20061024013933/http://www1.videobusiness.com/article/CA616459.html|archivedate=24 October 2006 |dead-url=usurped}}
And here are tests to show that {{para|dead-url|no}} and {{para|dead-url|yes}} still works as they should:
:<code><nowiki>{{cite web/new |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=no}}</nowiki></code>
::{{cite web/new |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=no}}

:<code><nowiki>{{cite web/new |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=yes}}</nowiki></code>
::{{cite web/new |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=yes}}
—] (]) 16:39, 14 August 2015 (UTC)
:The documentation of the parameter value should make the intent of {{para|dead-url|usurped}} clear (in accordance with the discussion above). Other than that, looks good. --] (]) 16:54, 14 August 2015 (UTC)
:Looks good. <font color="#8b4513">]</font><font color="#ee8811">]</font> 15:09, 16 August 2015 (UTC)

::The more I think about the keyword <code>usurped</code>, the less I like it. The term certainly fits for those cases where a domain name has been usurped but does it fit for all other cases where it is prudent to suppress the original url? I'm not sure, so rather than use a keyword that may have limited specificity, I think we should switch to a more general keyword, perhaps <code>unfit</code>, which would covers a broader variety of reasons for suppression of the original url.

::—] (]) 19:26, 17 August 2015 (UTC)
:::At the risk of boring all of you, I will re-express my view that the parameter value should express the function, not the reason (as I said in the previous discussion linked above, and as {{U|GoingBatty}} said above. I like "hide" or "nolink".

:::TL:DR; version: The value of {{para|display-editors}}, for example, is either a number (to show a given number of editors) or "etal" (to show "et al." without listing all of the editors in the citation template. We don't dictate ''why'' an editor should use a specific value, we just show how to get the display you want, assuming that editors will make a good choice (a bad assumption, I know, but you have to start by treating people like competent adults). There are many reasons why someone might want to suppress a link to the original URL: it is a porn site, the site has been sold, the page has been moved or archived, the editor wants a consistent citation style, or other reasons I can't think of. We can list some of them in the documentation, but assuming only one reason for hiding the URL paints us into a corner. – ] (]) 19:42, 17 August 2015 (UTC)
::::I was hoping you wouldn't re-iterate your opinion so I wouldn't have to reiterate mine. To wit: {{tq|The problem I have with function over purpose is that function enables behavior that may not be desirable. For example, I can't think of ''any'' reason other than a link being a "bad" link to be correct to hide.}} And my feeling is that the suitable keyword should reflect the reason. This allows us to trivially say "yes, you have used this as intended". I want in fact to ''preempt'' other reasons for usage without associated keywords, because I do not want "oh, the site is dead" simply to cause the link to be suppressed (as I am sure there is at least ''one'' person who would be wont to do so). See above illustrative discussion on that point. --] (]) 21:59, 17 August 2015 (UTC)

::::In the cases of {{para|dead-url|hide}} or {{para|dead-url|nolink}} or similar, we create a mechanism that doesn't explain to editors of a later age why the action was taken. With {{para|display-editors|etal}}, {{para|mode|cs2}} it's pretty easy to determine why the parameter was set the way it was set and that it is, or is not, set properly. Setting {{para|dead-url|usurped}} or {{para|dead-url|unfit}} gives follow-on editors some indication why the original url is suppressed. Like Editor Izno, I can think of no real reason why an original url should be suppressed unless it leads to inappropriate content. As I indicated before, we can have a variety of keywords to use as reasons should experience dictate a need.

::::—] (]) 13:08, 18 August 2015 (UTC)

Supported keywords are now <code>unfit</code> and <code>usurped</code> (also shows that auto {{para|format|PDF}} works correctly when original url is suppressed):
:<code><nowiki>{{cite webnew |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=unfit}}</nowiki></code>
::{{cite web/new |title=Title |url=//example.com/file.pdf |archive-url=//example.net/file.pdf |archive-date=2015-08-14 |dead-url=unfit}}
:<code><nowiki>{{cite webnew |title=Title |url=//example.com |archive-url=//example.org |archive-date=2015-08-14 |dead-url=usurped}}</nowiki></code>
::{{cite web/new |title=Title |url=//example.com/file.pdf |archive-url=//example.net/file.pdf |archive-date=2015-08-14 |dead-url=usurped}}
—] (]) 16:45, 24 August 2015 (UTC)

==How to cite letter in CS1?==
I would like to cite the letter found . The hard copy of the letter appears to be held by the ] (NARA) in a box titled "HSCA Segregated CIA Collection, Box 19", and they appear to refer to the letter as "NARA Record Number: 1993.08.02.09:31:14:370053". If I use {{tlx|cite letter}}, then...
:<nowiki>{{cite letter |first=Sturgis |last=Frank |recipient=Gene Wilson |subject=Pre-freedom of information request notice of charges |date=May 7, 1976 |url=http://www.maryferrell.org/showDoc.html?docId=76999 |accessdate=August 11, 2015}}</nowiki>
...gives me...
:{{cite letter |first=Sturgis |last=Frank |recipient=Gene Wilson |subject=Pre-freedom of information request notice of charges |date=May 7, 1976 |url=http://www.maryferrell.org/showDoc.html?docId=76999 |accessdate=August 11, 2015}}
Unfortunately, with the above template I don't believe I am able to note additional information about where this original document may be found, such as the {{para|id}} noted above. Is there something similar in CS1 that I can use? If so, what is the equivalent of {{para|recipient}} in CS1? Also, should {{para|title}} be "Letter from Frank Sturgis to Gene Wilson" or the subject noted by the author, and NARA, as "Pre-freedom of information request notice of charges"? Sorry for so many questions. Thanks! - ] (]) 20:29, 12 August 2015 (UTC)
:Try:
::<nowiki>{{cite letter |first=Sturgis |last=Frank |recipient=Gene Wilson |subject=Pre-freedom of information request notice of charges |date=May 7, 1976 |url=http://www.maryferrell.org/showDoc.html?docId=76999 |accessdate=August 11, 2015 |via= National Archives and Records Administration (HSCA Segregated CIA Collection, Box 19) |id= NARA Record Number 1993.08.02.09:31:14:370053 }}</nowiki>
:which gives:
::{{cite letter |first=Sturgis |last=Frank |recipient=Gene Wilson |subject=Pre-freedom of information request notice of charges |date=May 7, 1976 |url=http://www.maryferrell.org/showDoc.html?docId=76999 |accessdate=August 11, 2015 |via= National Archives and Records Administration (HSCA Segregated CIA Collection, Box 19) |id= NARA Record Number 1993.08.02.09:31:14:370053 }}
:I just added {{para|id}} to the template, and {{para|via}} was already there. <span style="background:#006B54; padding:2px;">''']&nbsp;]'''</span> 20:51, 12 August 2015 (UTC)

:Are you citing the hard copy? Have you actually seen the hard copy? If not, and you are citing the copy at the Mary Ferrell Foundation website, then the direct cs1 equivalent to {{tlx|cite letter}} would be {{tlx|cite web}} (] applies). It should be noted that {{tld|cite letter}} is a meta-template of {{tlx|cite news}}. Such a citation might look like this:

::<code><nowiki>{{cite web |last=Sturgis |first=Frank |title=Pre-freedom of information request notice of charges |type=Letter to Gene Wilson |website=Mary Ferrell Foundation |date=May 7, 1976 |url=http://www.maryferrell.org/showDoc.html?docId=76999 |accessdate=August 11, 2015}}</nowiki></code>
:::{{cite web |last=Sturgis |first=Frank |title=Pre-freedom of information request notice of charges |type=Letter to Gene Wilson |website=Mary Ferrell Foundation |date=May 7, 1976 |url=http://www.maryferrell.org/showDoc.html?docId=76999 |accessdate=August 11, 2015}}

:In your example, {{para|last}} and {{para|first}} are swapped; the writer's name if 'Frank Sturgis'.

:—] (]) 21:01, 12 August 2015 (UTC)
::], ]: Thanks for the feedback! - ] (]) 22:49, 13 August 2015 (UTC)
I think the advice to use {{tl|cite web}} instead of a more specific citation type for a source found on the web rather than through hardcopy is wrongheaded. When we find books online through Google books, we should use {{tl|cite book}}, not {{tl|cite web}}. When we find academic journal articles online at their official publisher's online repository, we should use {{tl|cite journal}}, not {{tl|cite web}}, even for journals that have no print edition and are only online. And for the same reason, if we are viewing a facsimile of a written letter, we should still use {{tl|cite letter}}. —] (]) 23:51, 13 August 2015 (UTC)
:Yes, this is why the {{para|url}} parameter is not confined to {{tlx|cite web}} but is included in all the others. --] (]) 12:12, 14 August 2015 (UTC)

== |script-chapter= ==

Following up on ], I've added {{para|script-chapter}}. Styling and order of rendered chapter parts follows the same rules as {{para|script-title}}:
:<code><nowiki>{{cite book/new |title=Tōkyō tawā |script-title=ja:東京タワー |trans-title=Tokyo Tower}}</nowiki></code>
::{{cite book/new |title=Tōkyō tawā |script-title=ja:東京タワー |trans-title=Tokyo Tower}}

Here are those same parameter values moved to their chapter equivalents:
:<code><nowiki>{{cite book/new |title=Title |chapter=Tōkyō tawā |script-chapter=ja:東京タワー |trans-chapter=Tokyo Tower}}</nowiki></code>
::{{cite book/new |title=Title |chapter=Tōkyō tawā |script-chapter=ja:東京タワー |trans-chapter=Tokyo Tower}}
and with a link:
:<code><nowiki>{{cite book/new |title=Title |chapter=Tōkyō tawā |script-chapter=ja:東京タワー |trans-chapter=Tokyo Tower |chapter-url=//example.com}}</nowiki></code>
::{{cite book/new |title=Title |chapter=Tōkyō tawā |script-chapter=ja:東京タワー |trans-chapter=Tokyo Tower |chapter-url=//example.com}}
I wonder if the {{para|script-chapter}} value should be quoted when rendered especially in the case where the template also has {{para|script-title}} without {{para|title}}:
:<code><nowiki>{{cite book/new |script-title=ja:東京タワー |script-chapter=ja:東京タワー}}</nowiki></code>
::{{cite book/new |script-title=ja:東京タワー |script-chapter=ja:東京タワー}}
Still to do: include {{para|script-chapter}}value in the metadata; support {{para|script-title}} and {{para|script-chapter}} in {{tlx|cite encyclopedia}} and {{tlx|cite episode}}.

—] (]) 11:37, 15 August 2015 (UTC)

:Metadata support added, {{tlx|cite episode}} code tweaked which resolves ], and {{tlx|cite encyclopedia}} code tweaked which resolves ].

:—] (]) 12:50, 15 August 2015 (UTC)

== time to abandon protocol relative urls for the predefined identifiers? ==

There is a move afoot to replace http:// and relative protocol (//) with https: for certain urls in article space and in {{para|url}} in citations. These replacements mostly involve Google, YouTube, and Internet Archive. In September 2013, ] converted all of the identifier urls that could be converted to relative protocol. That was a time when logged-in users used https: but users who weren't logged in used http:. Since then, Wikimedia has migrated everyone to using https:. Part of the reason for the module's switch to protocol relative urls was to prevent switching back and forth from secure (at Misplaced Pages) to not-secure (the identifier's site).

It appears that all but two of the predefined identifiers supported by the module and that use external links can be accessed using https:. The two that cannot be accessed are bibcode and LCCN. Here is a list of the identifiers with the various flavors of url:

{{div col}}
* ARXIV :
**
**
**
*ASIN :
**
**
**
* BIBCODE :
**
** – does not work
** – does not work
* DOI :
**
**
**
* ISSN :
**
**
**
* JFM :
**
**
**
* JSTOR :
**
**
**
* LCCN :
**
** – does not work
** – does not work
* MR :
**
**
**
* OCLC :
**
**
**
* OL
**
**
**
* OSTI :
**
**
**
* PMC :
**
**
**
* PMID :
**
**
**
* RFC :
**
**
**
* SSRN :
**
**
**
* ZBL :
**
**
**
{{div col end}}
Is there any need to continue to support protocol relative urls for these identifiers?

—] (]) 22:41, 15 August 2015 (UTC)
:If everyone is using https, then protocol-relative links would use https also. Why change <code>//</code> to <code>https://</code>? It seems like another source of potential typos and errors. – ] (]) 00:34, 16 August 2015 (UTC)
:Then for bibcode and lccn, we make sure that all links are explicitly http: - since the rest are all working in each available method, we leave these links alone. --] (]) 08:04, 16 August 2015 (UTC)

::You can't be here (on Misplaced Pages) without your browser supports an https: connection. If the identifier sites support an https: connection (and all do except bibcode and LCCN) then there is no need for us to support the protocol relative scheme. For identifiers, editors don't have to type a url so I'm not clear on how this change would be a source of typos and errors. Can you expand on that?

::—] (]) 12:45, 17 August 2015 (UTC)
:::So the "https:" would be added by the module only for the identifiers linked above? In that case, I'm fine with that. The first sentence of this section made it sound like we were going to go around replacing "//" with "https:", which sounded unnecessary and potentially harmful.

:::Again, though, if it's not currently broken, I don't see why we should fix it. If it is broken in some way that I do not understand, I'll go along with it. – ] (]) 14:47, 17 August 2015 (UTC)

::::One conversation about changing http: to https: is ]. We change lots of stuff that isn't 'broken' for a variety of reasons. This is just another of those.

::::—] (]) 15:13, 17 August 2015 (UTC)

== urls in |title= ==

Per ], ], and ], I have added a test that finds external wikilinks within the content of {{para|title}}. I expect to add calls to this same test for {{para|chapter}} and {{para|website}}. Templates that fail the test are added to {{cl|CS1 errors: external links}}
:<code><nowiki>{{cite book/new |title=}}</nowiki></code>
::{{cite book/new |title=}}
:<code><nowiki>{{cite book/new |title=}}</nowiki></code>
::{{cite book/new |title=}}
External wikilink with leading text:
:<code><nowiki>{{cite book/new |title=Leading text }}</nowiki></code>
::{{cite book/new |title=Leading text }}
External wikilink with trailing text:
:<code><nowiki>{{cite book/new |title= trailing text}}</nowiki></code>
::{{cite book/new |title= trailing text}}
External wikilink with leading and trailing text:
:<code><nowiki>{{cite book/new |title=Leading text trailing text}}</nowiki></code>
::{{cite book/new |title=Leading text trailing text}}
The external wikilink must be protocol relative or have valid scheme (uses much the same test as is newly implemented for ]):
:<code><nowiki>{{cite book/new |title=}}</nowiki></code>
::{{cite book/new |title=}}
The external wikilink must be complete:
:<code><nowiki>{{cite book/new |title=[http://example.com Title}}</nowiki></code>
::{{cite book/new |title=[http://example.com Title}}
:<code><nowiki>{{cite book/new |title=http://example.com Title]}}</nowiki></code>
::{{cite book/new |title=http://example.com Title]}}
The limitations of the test as just described mean that it does not answer the challenge posed ]. I chose a vague error message so that should we decide to change the test to find urls, not just external wikilinks, in parameter values, we can do so without needing to change messaging and categorization.

—] (]) 22:27, 19 August 2015 (UTC)
:An external link on the whole title can obviously be replaced by {{para|url}}, but this change is going to prevent editors from making external links on only part of a title. I don't know of a valid use case for doing that, but maybe there is one. Before making this change, is there any way to search for the citations that already have links on part of but not the whole title, so that we can judge whether any of them are appropriate? —] (]) 22:31, 19 August 2015 (UTC)
::This search string should answer: <code>insource:/\| *title *=*http/</code> but it doesn't. The regex works in AWB but is not working for me as an insource: search. This search string: <code>insource:/\| *title *=*http/</code> at least returns {{para|title|http...}}

::The reason for this test is that external links (as external links, not plain text) in {{para|title}} corrupt the metadata. This is why we have {{para|url}}.

::—] (]) 23:09, 19 August 2015 (UTC)
:::Sure, but I'm primarily concerned about being able to generate a correct rendering of all valid citations, and only secondarily concerned about generating proper metadata for them. So if this change prevents us from formatting valid citations that happen to include external links in only part of the title, then it's a bad thing, even if it also constrains the citations in such a way as to make it easier to generate valid metadata. In this particular case, it seems likely enough that there are no valid citations that we'd be breaking, but I'm not certain of that, and you haven't convinced me that you have any evidence of that either. So running a search that would find them would be helpful, if we could get such a search to work. —] (]) 23:18, 19 August 2015 (UTC)

::::Perhaps it is working, sort of. <code>insource:/\| *title *=*http/</code> finds four results (it should find a lot more). The regex means:
:::::Find a pipe, zero or more spaces, the string 'title', zero or more spaces, an equal sign, zero or more characters that are not a pipe or closing curly brace, and the string 'http'.
::::That means it should find {{para|title|http...}}. It didn't, but it did find these (none of which are cs1|2):
:::::<code>| title = <nowiki></nowiki></code>
:::::<code><nowiki>|title=Jamaica by-election (April 13, 2005): Kingston West&lt;ref>http://www.eoj.com.jm/content-70-243.htm&lt;/ref></nowiki></code>
:::::<code><nowiki>|title = Surrey County Council election results, 2009, Guildford&lt;ref>Sources: http://www1.surreycc.gov.uk/election2009/&lt;/ref></nowiki></code>
:::::<code><nowiki>|title=2014 Minnesota Legislature - House District 39A&lt;ref>http://electionresults.sos.state.mn.us/Results/StateRepresentative/20?districtid=431&lt;/ref></nowiki></code>
::::If we can presume that the search tool works well enough to find these where the url occurs after the beginning of {{para|title}} then that may mean that cs1|2 templates that have urls embedded midway or at the end of {{para|title}} do not exist.
::: :::
:::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.
::::That leaves us with urls that begin the {{para|title}}parameter value. For that, this search string:
:::
:::::<code>insource:/\| *title *= *http/</code> (c. 290 hits)
:::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
::::This search string finds external wikilinks at the beginning of the {{para|title}} value:
return mw.language.new( 'ru' ):formatDate( 'j xg Y', date ); -- convert ymd to dMy
:::::<code>insource:/\| *title *= *\[http/</code> (c. 150 hits)
end
::::These are the type of url-in-title that the test is currently configured to catch.
</syntaxhighlight>

:::With that code in place, the remaining tests return 15 января 2001, 30 декабря 2024, and 31 декабря 2024.
::::—] (]) 00:26, 20 August 2015 (UTC)
:::—] (]) 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)
:::::I generally support this error check. I believe that due to the uncertainty that exists in describing this situation, the failure of the insource search, and the wide variety of weirdness that editors put into citation templates, we should either hide this error message by default and/or have this check result in a maintenance message rather than a red error message. I think that we are going to see some false positives. I think that our credibility is diminished when we roll out code to all readers that shows errors for valid text like {{para|edition|Illustrated}}, as we have recently done, and I think this particular check has a high likelihood of doing that.
:::::{{para|access-date}} and {{para|archive-date}} must include day, month, and year – the dates are meaningless else.

:::::
:::::One note about the terminology used in this discussion section: I believe that on WP, "wikilink" means a link to an article within WP, while "external link" means a link (generally a URL) that leads outside of WP. See ] and ]. I do not think that the phrase "external wikilink" used above has a valid meaning on WP. Let's be clear in our use of language. – ] (]) 04:41, 20 August 2015 (UTC)
:::::It is pointless to convert ym dates to ymd dates. Add this:
::::::If that's all this check dug up, I'm happy enough with this new restriction. I don't think any of those are good uses of external links in titles. BTW, re the above comment: I was assuming that "external link" meant single-bracketed links and that "wikilink" meant double-bracketed links. The double-bracketed kind usually stay within WP but not always; for instance, it's possible to use double-bracket syntax for doi or arXiv links. —] (]) 04:56, 20 August 2015 (UTC)
::::::<syntaxhighlight lang="lua"> if 'ymd' == format_param and 'ym' == pattern_idx then -- special case for ru.wiki
:::::::I've looked at about 50 of the c. 150 pages returned by the <code>insource:/\| *title *= *\[http/</code> search. Of those, I found three where the {{para|title}} value was more than just an external wikilink:
return mw.language.new( 'ru' ):formatDate( 'xg Y', date ); -- convert ym to My
::::::::<code><nowiki>{{cite web|last=Flexible Plug and Play website |title=''accessed 18 October 2012}}</nowiki>
end
</code>
</syntaxhighlight>
:::::::::{{cite web|last=Flexible Plug and Play website |title=''accessed 18 October 2012}}
:::::change the sequence in the first <code>if</code> in <code>reformatter()</code> to include <code>'ym', </code>.
::::::::<code><nowiki>{{cite web | last =FamilySearch.org | first = | coauthors = | title = and | publisher =FamilySearch.org | | url = |accessdate = 12 March 2014 }}</nowiki></code>
:::::
:::::::::{{cite web | last =FamilySearch.org | first = | coauthors = | title = and | publisher =FamilySearch.org | | url = |accessdate = 12 March 2014 }}
:::::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.
::::::::<code><nowiki>{{cite press release |title=
:::::—] (]) 15:02, 31 December 2024 (UTC)
LeTourneau University Names New President |publisher=LeTourneau University |date=2007-03-08 |url=http://www.letu.edu/opencms/opencms/_Other-Resources/presidents_office/news/presAnnouncement.html |accessdate=2007-08-09}}</nowiki></code>
::::::It works! Thanks! :) ] (]) 15:58, 31 December 2024 (UTC)
:::::::::{{cite press release |title=
:Consider the
LeTourneau University Names New President |publisher=LeTourneau University |date=2007-03-08 |url=http://www.letu.edu/opencms/opencms/_Other-Resources/presidents_office/news/presAnnouncement.html |accessdate=2007-08-09}}
:<code><nowiki>{{cite journal/песочница |title=Title |journal=Journal |date=23–29 February 1700}}</nowiki></code>
:::::::In each of the cases above, the templates are clearly malformed or misused.
: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
:::::::I chose to use the term 'external wikilink' because the code is looking for urls formatted with wiki markup: opening square bracket, url, optional link-label text, closing square bracket. I used this term to distinguish that form of url from a plain url or external link (one without the wiki markup).
:] (]) 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)
:::::::I did consider maintenance rather than errors but chose error because:
:::::::*url-in-title corrupts the metadata
:::::::*url-in-title can trigger access-date-requires-url errors
:::::::*for {{tlx|cite web}} url-in-title triggers missing-or-empty-url errors
:::::::*for other templates, url-in-title can trigger format-requires-url errors
:::::::*automatic pdf format annotation doesn't work when the url is part of title
:::::::If the insource search results are to be believed, there aren't enough url-in-title errors to warrant hiding them.
::::::
:::::::—] (]) 12:54, 20 August 2015 (UTC)
{{od}}
] is your friend:
:<code>insource:title insource:http insource:/\| *title *=*http/</code>
That search string first finds pages with the strings 'title' and 'http' and then does the regex search on those pages. However, more results aren't necessarily better results. In the first page of results, these:
:<code><nowiki>{{cite web | url= | title=http://www.edmonton.ca/city_government/documents/Callaghan_NASP_Consolidation.pdf Neighbourhood Area Structure Plan (Office Consolidation) | publisher=City of Edmonton | date=March 2011 | accessdate=2012-06-08}}</nowiki></code>
::{{cite web | url= | title=http://www.edmonton.ca/city_government/documents/Callaghan_NASP_Consolidation.pdf Neighbourhood Area Structure Plan (Office Consolidation) | publisher=City of Edmonton | date=March 2011 | accessdate=2012-06-08}}
:<code><nowiki>{{cite web|title=The Beverly clock|type=Abstract|journal= ]|publisher=IOPscience|title=http://iopscience.iop.org/0143-0807/5/4/002}}</nowiki></code>
::{{cite web|title=The Beverly clock|type=Abstract|journal= ]|publisher=IOPscience|title=http://iopscience.iop.org/0143-0807/5/4/002}}<!-- don't fix this duplicate |title= error; it is here as a demonstration -->
clearly, both malformed. But, the search also finds stuff like this:
:<code><nowiki><ref></ref>&lt;ref></ref></nowiki></code>
which is also clearly broken but outside the cs1|2 remit.

—] (]) 13:37, 20 August 2015 (UTC)

I have added code that also checks {{para|chapter}} and {{para|work}}:
:<code><nowiki>{{cite book/new |title=Title |chapter=}}</nowiki></code>
::{{cite book/new |title=Title |chapter=}}
:<code><nowiki>{{cite journal/new |title=Title |journal=}}</nowiki></code>
::{{cite journal/new |title=Title |journal=}}
The test can handle all three in the same template:
:<code><nowiki>{{cite encyclopedia/new |title=Title |article= |encyclopedia=}}</nowiki></code>
::{{cite encyclopedia/new |title= |article= |encyclopedia=}}
The error message lists the 'prime' (for lack of a better term) alias. Is there some way to mark the prime alias in an error message that tells readers that the message for this parameter may be aliased? For instance, {{para|work}} could be {{para|newspaper}}, {{para|journal}}, {{para|encyclopedia}}, ... We might tweak the error message so that it reads:
:External link in <kbd>|<work>=</kbd>
:External link in <kbd><|work=></kbd>
:External link in <kbd>|<u>work</u>=</kbd>
:External link in <kbd>|''work''=</kbd>

Other, better ideas?

—] (]) 22:16, 20 August 2015 (UTC)

== when both original and archive urls are dead ==

This conversation at ] is perhaps vaguely related to ] about suppressing the original url. In that discussion is this cs1 template:
:<code><nowiki>{{cite web| url=http://www.planning.org/thenewplanner/nonmember/default1.htm |title=The New Planner: Drowning Office Park Rescued by Students During High Tide | accessdate=2006-11-01 |archiveurl = http://web.archive.org/web/20060714232619/http://www.planning.org/thenewplanner/nonmember/default1.htm <!-- Bot retrieved archive --> |archivedate = 2006-07-14}}</nowiki></code>
::{{cite web| url=http://www.planning.org/thenewplanner/nonmember/default1.htm |title=The New Planner: Drowning Office Park Rescued by Students During High Tide | accessdate=2006-11-01 |archiveurl = http://web.archive.org/web/20060714232619/http://www.planning.org/thenewplanner/nonmember/default1.htm <!-- Bot retrieved archive --> |archivedate = 2006-07-14}}
Neither the original url nor the archive url work. To me this seems a case of 'find-another-source-to-cite'. Until that other source can be located, is there something that cs1|2 can/should do to indicate to readers that both urls are dead? Is this even in the cs1|2 remit?

—] (]) 20:25, 21 August 2015 (UTC)
:To me, archived copies of web sources are similar to, but not the same as, courtesy links to online copies of books. If we assume the underlying source is (or was) reliable when it was consulted, then there is a bit of a presumption that it is still reliable going forward. The archived copy makes otherwise inaccessible sources accessible again, much like a Google Books-hosted copy of a rare book. If that same Google Books link stopped working, it could be removed without changing the fact that the underlying source, the rare book, was used to source the cited information.
:In other words, if it were just me, and I discovered that an archived copy no longer worked, I'd remove or comment out {{para|archive-url}} and {{para|archive-date}} and add a {{tl|dead link}} tag to the citation. This would notify editors that we would want a new archive of the original source, if possible. We'd still be free to locate replacement sources to cite, just as we'd be free to attempt to find other books that are more accessible than rare books housed in only a few select libraries. Because our sources need to be accessible to someone somehow someway, we allow citation of very rare sources, and we'd eventually want a dead online source to be resurrected or replaced. I hope my thought processes make some sense. <span style="background:#006B54; padding:2px;">''']&nbsp;]'''</span> 03:15, 22 August 2015 (UTC)

Why is the archive URL not working? Sometimes it's a temporary issue with IA and it works again a few days later. In several cases, inspecting the edit history revealed a rogue edit had added or removed a character from the URL rendering it non-functional. -] (]) 23:31, 22 August 2015 (UTC)
:IA says "Page cannot be crawled or displayed due to robots.txt." It could be that planning.org added their robots.txt page after the archiveurl was added to the citation. ] (]) 18:43, 23 August 2015 (UTC)

== ISBN error category ==

So that it is consistent with the naming convention of other identifier error categories, and while it is mostly empty, I've changed the ISBN error category name from {{cl|Pages with ISBN errors‎}} to {{cl|CS1 errors: ISBN}} in ].

After the next module update, I think that the old category Pages with ISBN errors ‎can go away.

—] (]) 16:34, 22 August 2015 (UTC)
:Support. It helps distinguish it from {{cl|Articles with invalid ISBNs}} as well. – ] (]) 10:14, 23 August 2015 (UTC)

== url-wikilink conflict error category and error message change ==

To shorten and make it more consistent with other error categories, in ] I have changed the {{cl|Pages with citations having wikilinks embedded in URL titles}} to {{cl|CS1 errors: URL–wikilink conflict}}. Because of this change I have also changed the error message to reflect the category name: 'Wikilink embedded in URL title' to 'URL–wikilink conflict'.

—] (]) 17:10, 22 August 2015 (UTC)
:I support the two criteria listed, but I think that both the old and the new names are confusing to readers. I will try to come up with a proposal for one that meets the criteria: short, consistent, clear. I hope we don't have to settle for two out of three. (And a pedantic note: as I read the "In compounds when the connection might..." section of ], that should be an en dash, not a hyphen. Let's not pick that fight with pedants like me.)

:If these category name changes stick, we'll need to update the math on the CS1 errors category page and check for links to the old category names. – ] (]) 10:10, 23 August 2015 (UTC)

::I concur and have changed the sandbox to use ndashes. {{tlx|category redirect}} for hyphenated versions is appropriate.

::Internal–external link conflict? Clash? Collision?

::—] (]) 10:37, 23 August 2015 (UTC)
:::"URL overrides wikilink"? "Duplicate links"? "Redundant links"? "External link and wikilink?" I like the last two better than the first two ("duplicate links" makes it sound like they are identical). – ] (]) 11:04, 23 August 2015 (UTC)

== error handling for |trans-title= and |trans-chapter= ==

In ], there are two nearly identical entries in the error_conditions table for {{para|trans-title}} and {{para|trans-chapter}} missing their original language counterparts. I have tweaked the code in ] and ] to combine these two error handlers. Examples:
*{{cite book/new |chapter=Chapter |title=Title}}
*{{cite book/new |trans-chapter=Trans Chapter |title=Title}}
*{{cite book/new |trans-title=Trans Title |chapter=Chapter}}
*{{cite book/new |trans-title=Trans Title |trans-chapter=Trans Chapter}}
*{{cite book/new |trans-title=Trans Title |title=Title |trans-chapter=Trans Chapter |chapter=Chapter}}

Similarly, in ] the help text for these two errors is nearly identical. When we make the next update to the live module, the help text for trans-chapter should be merged into the help text for trans-title (trans-title has the common anchor for the error message help link).

The two error messages shared {{cl|Pages with citations using translated terms without the original}}. That category name changes to {{cl|CS1 errors: translated title}}.

—] (]) 21:50, 22 August 2015 (UTC)

== Yet another example of two levels of title within a journal publication ==

The following reference is a paper, part of a conference proceedings that was published as an issue of a journal (whose name indicates that it regularly publishes proceedings in this way, but with a combined volume and issue numbering system that looks much more like a journal than like a book series). The following formatting produces a citation that looks correct but with what I believe to be incorrect metadata. Is there a way to get the metadata right, too, or is this the best I can do?
:<nowiki>{{cite journal
| last = Charatonik | first = Janusz J.
| title = Selected problems in continuum theory
| url = http://topology.auburn.edu/tp/reprints/v27/tp27107.pdf
| issue = 1
| journal = Topology Proceedings
| mr = 2048922
| pages = 51–78
| department = Proceedings of the Spring Topology and Dynamical Systems Conference
| volume = 27
| year = 2003}}</nowiki>
produces
:{{cite journal
| last = Charatonik | first = Janusz J.
| title = Selected problems in continuum theory
| url = http://topology.auburn.edu/tp/reprints/v27/tp27107.pdf
| issue = 1
| journal = Topology Proceedings
| mr = 2048922
| pages = 51–78
| department = Proceedings of the Spring Topology and Dynamical Systems Conference
| volume = 27
| year = 2003}}
—] (]) 01:41, 25 August 2015 (UTC)

:Because there is no COinS record assigned to {{para|department}}, 'Proceedings of the Spring Topology and Dynamical Systems Conference' is not included in the metadata. Rewriting this cite to use {{tlx|cite conference}} isn't much better:
::<code><nowiki>{{cite conference
| last = Charatonik | first = Janusz J.
| title = Selected problems in continuum theory
| url = http://topology.auburn.edu/tp/reprints/v27/tp27107.pdf
| issue = 1
| journal = Topology Proceedings
| mr = 2048922
| pages = 51–78
| booktitle= Proceedings of the Spring Topology and Dynamical Systems Conference
| volume = 27
| year = 2003}}</nowiki></code>
:In this case, 'Topology Proceedings' is left out which isn't any better and is probably worse, because the journal title is common to the two volumes published each year.

:—] (]) 10:38, 25 August 2015 (UTC)

:Use of {{para|contribution/chapter}} seems more suitable, but – oops! – {{red|red messages}}:
:*{{cite journal
| last = Charatonik | first = Janusz J.
| chapter = Selected problems in continuum theory
| url = http://topology.auburn.edu/tp/reprints/v27/tp27107.pdf
| issue = 1
| journal = Topology Proceedings
| mr = 2048922
| pages = 51–78
| title = Proceedings of the Spring Topology and Dynamical Systems Conference
| volume = 27
| year = 2003}}
::~ ] (]) 20:55, 26 August 2015 (UTC)
:::Yes, that would be my preference, if it worked. But it doesn't, {{tl|cite journal}}/{{para|department}} does, and it appears from Trappist's message above that it doesn't even produce bogus metadata. So that's what I'll be using for now. —] (]) 20:11, 29 August 2015 (UTC)

::::On one hand, I would be happy for any reasonable work around. On the other hand, COinS is not the only kind of metadata here. The names of parameters also carry information regarding the nature of the data encoded. E.g., {{para|journal}} implies the source is ''journal'' (specfically, an ]), which is different from a newspaper or a book. Likewise, {{para|department}} is defined at ] as "{{tq|Title of a regular department, column, or section within the periodical or journal}}", and has specific effects on the resulting formatting. To use these parameters for other purposes is a form of metadata corruption. And (as has been previously commented) eventually leads to some unsuspecting editor attempting to "correct" what looks like an error. ~ ] (]) 22:18, 30 August 2015 (UTC)

== |translator= ==

For a very long time editors have been asking for {{para|translator}} in some form or other. For a very long time the answer has been {{para|others}}. While I have been hacking away at the {{para|coauthors}} problem in {{cl|Pages containing cite templates with deprecated parameters}} I have become somewhat sympathetic to that request. So, here it is, these new parameters:
:{{para|translator}}
:{{para|translator''n''}}
:{{para|translator-first}}
:{{para|translator-last}}
:{{para|translator-link}}
:{{para|translator-mask}}
:{{para|translator-first''n''}}
:{{para|translator-last''n''}}

And an example:
:<code><nowiki>{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford}}</nowiki></code>
::{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford}}

Relatively little is new as the translator-name-list makes use of existing author- and editor-name-list code. Currently, there is no support for et al. and no support for Vancouver styling.

Right now, {{para|others}} is appended to {{para|translator}} and the two rendered in the same place as {{para|others}}. This may not be the correct placement. There have been suggestions that {{para|translator}} belongs with {{para|author}}. What say you? Also, keep? Discard? What about punctuation? Static text?

—] (]) 17:36, 25 August 2015 (UTC)

:This is a good addition to the module. It will be welcomed by many editors. Here's how it looks with {{para|others}}:

::<code><nowiki>{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford|others=Illustrated by Jane Doe}}</nowiki></code>
:::{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford|others=Illustrated by Jane Doe}}

:That looks right to me. As for the fixed text "Translated by", I like it. Our guidance in the documentation for CS1 templates has contained only this recommended form , as far as I can tell. – ] (]) 18:17, 25 August 2015 (UTC)
:The ball on ] hasn't been resolved yet, so I would expect to see the number-in-the-middle variants also. --] (]) 21:40, 25 August 2015 (UTC)
::I don't think consistency requires us to introduce number-in-the-middle variants of new parameters, just because some of our old and entrenched parameters already have them. I'd prefer to see only one version of the new parameters rather than trying to duplicate all the variants of the old parameters. —] (]) 17:29, 27 August 2015 (UTC)
{{od}}
*{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=] |editor-first=Edward |editor-last=Smith |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford|others=Illustrated by Jane Doe}}

I wondered how the above would work in with an editor. Are the translator and the illustrator meant to be volume wide and not related to the chapter?

Translator is one option but another is "Reviewed by" which is used by the ODNB, another is "Illustrated by". So rather than having a specific type why not have other parameters with a "other string" it could default to ("translated by") but be set to another word such as "Reviewed" or "Illustrated" etc. or set to "none" if other is a mixture of more than one type (translated by some, and illustrated by others), and instead of {{para|translator-first''n''}} have {{para|other-first''n''}} etc. -- ] (]) 16:52, 27 August 2015 (UTC)

:Good, as long as these also work:
::{{para|translator{{var|n}}-first}}
::{{para|translator{{var|n}}-last}}
:Discussions above do not indicate a consensus in favor of this {{var|role}}-last{{var|n}} order, with multiple editors objecting to it as counter-intuitive. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 02:16, 29 August 2015 (UTC)

==Time of day field==
I would like to propose that we add an optional field to ] (and by extension also to ]) for the hours and minutes of the day, perhaps also time zone.

This data is sometimes available in things, and where it is, I think it would be a good thing to add it.

This helps in cases where there is a dispute on how to organize things, who said what first, etc.

Sometimes you might want to cite 2 news articles about something made in the same day (or 2 tweets) and knowing that information could be useful for putting them into the correct order without requiring people to constantly go and check what the tweet said. This is also particularly useful if the tweet is taken down and wasn't archived. ] (]) 22:02, 28 August 2015 (UTC)

:If a tweet is taken down, and has not been archived anywhere, then it is not verifiable, and I would question its suitability as a source. If you feel it is useful to document the exact time some tweet or other information is posted/published, you can always add that following the template. I am not aware that a "time" field is necessary. ~ ] (]) 22:47, 28 August 2015 (UTC)

::I would think that in the rare instance where it was necessary to discuss the time various sources were published, it would be necessary to describe the times in the body of the article rather than leaving it to the footnotes. ] (]) 00:09, 29 August 2015 (UTC)

:::"Footnotes" is a bit ambiguous. More particularly, if short cites are used then the time could be used in the same manner as a page number, perhaps using {{para|loc}}. But however this might be done, the bottom line here is that (lacking any specific demonstrated need) we seem to have adequate means for adding timestamps, and the proposed field is not needed. ~ ] (]) 19:26, 2 September 2015 (UTC)

== vancouver error tweak ==

I have noticed that a space between the two initials of a name in {{para|vauthors}} is not detected as an error. I think that I have fixed that:

{{cite compare |old=no |mode=book |title=Title |vauthors=Last AA, Last B B}}

—] (]) 21:55, 31 August 2015 (UTC)

== page protection applied to the suggestions list ==

] has been, since it creation, unprotected. ], I wondered if that page should be protected, but I didn't pursue it and have come to believe that protection of that page is not necessary.

The page was set to template editor level protection by Editor ] at the request of Editor ]. That discussion, since archived, is ]. Because it has been archived, I have raised the issue here.

Is the current (template editor) protection appropriate?

Should we keep or revert?

—] (]) 10:50, 4 September 2015 (UTC)
:As an editor with template editor rights, I don't mind, but I think it's odd that a page that has never been vandalized or even edited incorrectly, as far as I can tell, would be protected. The page has 42 edits total, by my count.

:Since you bring it up, is it somehow possible to use regular expressions on that page? I may have asked this before. There are a lot of creative spellings of {{para|access-date}}, for example, that could be caught with a few regular expressions. – ] (]) 14:01, 4 September 2015 (UTC)

::Perhaps improperly edited once ({{diff|Module:Citation/CS1/Suggestions|610830297|610814123|you reverted}}).

::] has your regex suggestion.

::—] (]) 15:32, 4 September 2015 (UTC)
:::Oops. I think my brain thought to set it to semi, and my fingers to template. ] (]) 17:32, 4 September 2015 (UTC)

== pattern matching for suggestion list ==

Perhaps there is reason to be somewhat optimistic. I think that all of these are caught by this pattern: <code> = 'accessdate'</code>

*{{cite web/new |url=//example.com |title=Title |acccessdate=2015-09-04}}
*{{cite web/new |url=//example.com |title=Title |accesdate=2015-09-04}}
*{{cite web/new |url=//example.com |title=Title |access date=2015-09-04}}
*{{cite web/new |url=//example.com |title=Title |accessate=2015-09-04}}
*{{cite web/new |url=//example.com |title=Title |accessdare=2015-09-04}}
*{{cite web/new |url=//example.com |title=Title |accessdatte=2015-09-04}}
*{{cite web/new |url=//example.com |title=Title |accessddate=2015-09-04}}
*{{cite web/new |url=//example.com |title=Title |accessdte=2015-09-04}}
*{{cite web/new |url=//example.com |title=Title |accessed=2015-09-04}}
*{{cite web/new |url=//example.com |title=Title |accessedate=2015-09-04}}
*{{cite web/new |url=//example.com |title=Title |accesssdate=2015-09-04}}
*{{cite web/new |url=//example.com |title=Title |accssdate=2015-09-04}} – {{para|accssdate}} missing first 'e' so not a pattern match
*{{cite web/new |url=//example.com |title=Title |acessdate=2015-09-04}}

As the pattern is written, {{para|accessdare}} returns a partial match 'accessda'. I guess that could be a good or bad; too tight and we might as well just use the exact-match-method we use now or too loose and we get a lot of false positives.

At the moment, ] only catches {{para|access-date}} errors – I did that so that I could be sure that the errors weren't being caught by the existing code. Now I have to figure out how to integrate this with the existing test. And of course, I need to ask, do we really need this?

—] (]) 18:45, 4 September 2015 (UTC)

Regular exact-match-method restored. I've added a second pattern for variations on a theme of publisher using this pattern: <code>+ers?$'] = 'publisher'</code>
*{{cite book/new |title=Title |pubisher=Publisher}}
*{{cite book/new |title=Title |publiser=Publisher}}
*{{cite book/new |title=Title |publishers=Publisher}}
*{{cite book/new |title=Title |publsher=Publisher}}
*{{cite book/new |title=Title |publsiher=Publisher}}
*{{cite book/new |title=Title |pulbisher=Publisher}}
*{{cite book/new |title=Title |pulisher=Publisher}}

—] (]) 22:21, 4 September 2015 (UTC)


== OCLC parameter now needs to allow 11 digits. ==
At the end of this ], I noted that the suggestion mechanism doesn't allow suggestions for enumerated parameters. This is true except for the specific case of {{para|autor2}} which has an exact-match rule <code> = 'author2'</code>. Using patterns may be a way to solve this weakness. Using this pattern: <code>+r%d+'] = 'author#'</code>:
*{{cite book/new |title=Title |autor1=Author}}


During a preview on ] I ran into this:
—] (]) 11:51, 5 September 2015 (UTC)
*<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:
:These new suggestions look helpful. Can we use something like '$1' in the suggestion to repeat the number that was detected by the pattern? – ] (]) 21:32, 5 September 2015 (UTC)
*:{{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 ==
::Without getting too complicated we can do one capture:
:::<code>+r(%d+)'] = 'author$1'</code> (see my previous example to see that it works)
::More than that and some more involved code will be required.


The language parameter is not recognising languages includes ] and ] by their iso code.––]<sup>(])(])</sup> 11:18, 4 January 2025 (UTC)
::—] (]) 22:58, 5 September 2015 (UTC)
:None of the language tags are supported by MediaWiki:
:*Nagpuri (Sadri) <code>sck</code>: <syntaxhighlight lang="wikitext" inline="1">{{#language:sck|en}}</syntaxhighlight> → {{#language:sck|en}}
:*Nagpuri (Oraon Sadri) <code>sdr</code>: <syntaxhighlight lang="wikitext" inline="1">{{#language:sdr|en}}</syntaxhighlight> → {{#language:sdr|en}}
:*Kharia <code>khr</code>: <syntaxhighlight lang="wikitext" inline="1">{{#language:khr|en}}</syntaxhighlight> → {{#language:khr|en}}
:See the documentation for {{para|]}} and, in particular, ].
:—] (]) 12:38, 4 January 2025 (UTC)
::Is there any way to get such languages included.––]<sup>(])(])</sup> 12:48, 4 January 2025 (UTC)


== Double period bug (again) == == Module support edit req ==


{{Edit protected|level=full|Module:Citation/CS1|answered=yes}}
I know this was ], but this bug is still alive and annoying.
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)
: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?
:
:Not clear to me that ] would benefit from this change. What am I missing?
:—] (]) 14:35, 4 January 2025 (UTC)
::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)
: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)
::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)
::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)
: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>
::*{{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}}
::*{{#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}}
::<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}}
::*{{#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}}
::<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>
::*{{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}}
::*{{#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}}
: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}}:
::<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>
::*{{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}}
:Conveniently, should we decide to implement this as a replacement for ] and the others, ] is currently available.
:—] (]) 19:49, 5 January 2025 (UTC)


== Requested move 4 January 2025 ==
'''Steps to replicate:''' give the <code>publisher</code> parameter a value that ends with a period.


{{requested move/dated|multiple=yes
'''Result:''' Two periods after the publisher. Which is wrong. Mature software such as ] and ] can deal with this.
|current1=Template:cite AV media|new1=Template:cite audiovisual media|current2=Template:cite AV media notes|new2=Template:cite audiovisual media notes|current3=Template:cite tech report|new3=Template:cite technical report|protected=Template:Cite AV media notes|}}


* ] → {{no redirect|Template:cite audiovisual media}}
'''Real-life example:''' Look for “Digitalcourage e.V.” on ]. --] (]) 08:08, 7 September 2015 (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)
:Here is the citation from ]:
::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)
::<code><nowiki>{{Cite web |title=Überwachung in und aus der Schweiz: Das volle Programm |url=https://digitalcourage.de/blog/2015/ueberwachung-in-und-aus-der-schweiz-das-volle-programm |author=Digitale Gesellschaft Schweiz |publisher=Digitalcourage e.V. |date=2015-08-18 |accessdate=2015-09-07 }}</nowiki></code>
*'''Oppose''' per the arguments of Izno and David. -- ] (]) 01:58, 5 January 2025 (UTC)
:::{{Cite web |title=Überwachung in und aus der Schweiz: Das volle Programm |url=https://digitalcourage.de/blog/2015/ueberwachung-in-und-aus-der-schweiz-das-volle-programm |author=Digitale Gesellschaft Schweiz |publisher=Digitalcourage e.V. |date=2015-08-18 |accessdate=2015-09-07 }}


: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)
:De:wp does not use the en:wp ] to render citation templates. The de:wp, <code>{{]}}</code> is a template that is written using wiki markup.
*'''Oppose''' for ''AV'', don't care on ''tech''. &#32;<span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 16:00, 5 January 2025 (UTC)
*'''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)
*'''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)


== Generic name ==
:Probably best to raise the issue at ].


I'm aware of Reuters and CNN as authors when I see citations in ]. ] (]) 23:13, 6 January 2025 (UTC)
:—] (]) 11:09, 7 September 2015 (UTC)

Latest revision as of 11:46, 7 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.

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

    cite episode id parameter silently ignored

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

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

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

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

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

    Citeref: if no year, use year from date

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

    Problem to be solved:

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

    Expected breakages:

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

    Solution:

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

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

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

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

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

    Generic title

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

    Cite case causes CS1 errors

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

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

    Placement of "translator"/"page" fields

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

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

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

    Another generic title: "Conference Paper"

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

    certain parameters not displaying on 'Template:cite map'

    For some reason, {{cite map}} seems to have the following issues below:

    Cite map comparison (with 'title' parameter, without 'map' or 'website' parameters)
    Wikitext {{cite map|author-link=Joe Bloggs|date=7 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}}
    Live Bloggs, Joe (7 January 2025). Doe, John (ed.). title (format) (type) (57 ed.). others.
    Sandbox Bloggs, Joe (7 January 2025). Doe, John (ed.). title (format) (type) (57 ed.). others.
    In this first instance, the parameter {{{volume}}} isn't being shown after {{{others}}}, unlike in the other instances, and neither is {{{issue}}}, while {{{title}}} is displayed in italics, the latter two issues, like in the third instance.
    Cite map comparison (with 'title' and 'website' parameters, without 'map' parameter)
    Wikitext {{cite map|author-link=Joe Bloggs|date=7 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}}
    Live Bloggs, Joe (7 January 2025). Doe, John (ed.). "title" (format) (type). website. others. Vol. 52, no. 38.
    Sandbox Bloggs, Joe (7 January 2025). Doe, John (ed.). "title" (format) (type). website. others. Vol. 52, no. 38.
    In this second instance, the parameter {{{edition}}} isn't being shown at all, either after {{{type}}}, unlike in the first instance, or after {{{format}}}, unlike in the third or fourth instances, while the parameter {{{title}}} is displayed in "quotation marks", like in the fourth instance.
    Cite map comparison (with 'map' and 'title' parameters, without 'website' parameter)
    Wikitext {{cite map|author-link=Joe Bloggs|date=7 January 2025|edition=57|editor-first=John|editor-last=Doe|editor-link=John Doe|first=Joe|format=format|issue=38|last=Bloggs|map-url=https://www.example.com/map/|map=map|others=others|title=title|type=type|url=https://www.example.com/|volume=52}}
    Live Bloggs, Joe (7 January 2025). "map" (type). In Doe, John (ed.). title (format) (57 ed.). others. Vol. 52.
    Sandbox Bloggs, Joe (7 January 2025). "map" (type). In Doe, John (ed.). title (format) (57 ed.). others. Vol. 52.
    In this third instance, the parameter {{{issue}}} isn't being shown, while {{{title}}} is displayed in italics, both like in the first instance.
    Cite map comparison (with 'map', 'title' and 'website' parameters)
    Wikitext {{cite map|author-link=Joe Bloggs|date=7 January 2025|edition=57|editor-first=John|editor-last=Doe|editor-link=John Doe|first=Joe|format=format|issue=38|last=Bloggs|map-url=https://www.example.com/map/|map=map|others=others|title=title|type=type|url=https://www.example.com/|volume=52|website=website}}
    Live Bloggs, Joe (7 January 2025). "map" (type). In Doe, John (ed.). "title" (format) (57 ed.). others. Vol. 52, no. 38.
    Sandbox Bloggs, Joe (7 January 2025). "map" (type). In Doe, John (ed.). "title" (format) (57 ed.). others. Vol. 52, no. 38.
    In this fourth instance, the parameter {{{website}}} isn't being shown, unlike in the second instance, while {{{title}}} is displayed in "quotation marks", like in the second instance.

    PK2 (talk; contributions) 08:46, 26 December 2024 (UTC)

    Not really 'issues'. All of your examples are correct except for the fourth example:
    1. cites a standalone or sheet map; |volume= and |issue= are inappropriate
    2. cites a map in a periodical; the periodical parameters are: |journal=, |magazine=, |newspaper=, |periodical=, |website=, |work=; |edition= is ignored in the final assembly process
    3. cites a map in a book or encyclopedia; cs1|2 book and encyclopedia citations do not support |issue= (a periodical parameter)
    4. doesn't know what you're citing because you included |map=, |title=, and |website= which is an attempt to cite a map in a book and simultaneously in a periodical; don't do that.
    Cast about in the archives of this talk page for the discussions we had when developing the current version of {{cite map}}.
    —Trappist the monk (talk) 15:02, 26 December 2024 (UTC)
    I accidentally said the word 'italics' instead of '"quotation marks"' for the fourth instance above in {{cite map}} when I started this discussion; I just replaced that instance of the word 'italics' with 'quotation marks' now. -- PK2 (talk; contributions) 05:32, 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)

    Requested move 4 January 2025

    It has been proposed in this section that multiple pages be renamed and moved.

    A bot will list this discussion on the requested moves current discussions subpage within an hour of this tag being placed. The discussion may be closed 7 days after being opened, if consensus has been reached (see the closing instructions). Please base arguments on article title policy, and keep discussion succinct and civil.

    Please use {{subst:requested move}}. Do not use {{requested move/dated}} directly. Links: current log • target log • direct move

    – 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)

    Generic name

    I'm aware of Reuters and CNN as authors when I see citations in Islamist insurgency in the Sahel. Achmad Rachmani (talk) 23:13, 6 January 2025 (UTC)

    Categories: