Help talk:Citation Style 1

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., [1] and [2] of the same book). These are now "[books] available [only] 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 Wikipedia for the next 20 years for millions of books.

Also, this is only one website. Google Books has similar gradations, is even more complex, and more opaque how it works. For these reasons we don't track the precise levels of access. It's generally understood that any copyright material is by default probably going to have some restrictions. It's a matter of practicality. -- GreenC 02:50, 17 December 2024 (UTC)

DOI prefix limits should be bumped.

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

Seconding this! —⁠Collin^{t c} 22:10, 17 December 2024 (UTC)

If that is true, why (as I write this) is Category:CS1 errors: DOI empty?

{{PAGESINCATEGORY:CS1 errors: DOI}} → 0

—Trappist the monk (talk) 22:47, 17 December 2024 (UTC)

@Trappist the monk: The article Kiwai Island has a DOI of 10.70460/jpa.v7i1.183 in reference #1 that is incorrectly giving a "Check |doi= value" error. Could you please help fix this? GoingBatty (talk) 19:41, 19 December 2024 (UTC)

Fixed in sandbox:

Cite journal comparison

Wikitext	{{cite journal|date=2016|doi=10.70460/jpa.v7i1.183|first=Ian J|issue=1|journal=Journal of Pacific Archaeology|last=McNiven|pages=74–83|title=Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea|volume=7}}
Live	McNiven, Ian J (2016). "Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea". Journal of Pacific Archaeology. 7 (1): 74–83. doi:10.70460/jpa.v7i1.183. {{cite journal}}: Check |doi= value (help)
Sandbox	McNiven, Ian J (2016). "Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea". Journal of Pacific Archaeology. 7 (1): 74–83. doi:10.70460/jpa.v7i1.183.

—Trappist the monk (talk) 20:06, 19 December 2024 (UTC)

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)

spurious errors when fetching identifier limit data from commons

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

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

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

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

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

There is Phab:T229742 which may be related.

—Trappist the monk (talk) 22:32, 2 December 2024 (UTC)

cite episode id parameter silently ignored

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

|id= was:

• initially supported at this edit 25 May 2009
• reverted at this edit 7 August 2009
• updated to use Template:Citation/core and simultaneously usurped as a vehicle to support |network= and |station= at this edit 2 April 2012

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: Wikipedia: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:

• Mansbridge, Peter (host); Zaccardelli, Guiliano (guest) (September 3, 2008). "Zaccardelli - On Maher Arar". The National. CBC News.{{cite episode}}: CS1 maint: url-status (link)

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 Wikipedia still has to comply with the consensus on Wikipedia. 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 Wikipedia, we have a content guideline that requires the use of an identifier. That's as strong a consensus as it gets on Wikipedia. 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 Wikipedia articles, but there are now less than 10 articles in the category. Thanks! GoingBatty (talk) 17:45, 8 December 2024 (UTC)

See WP:BOLD. Also, I wonder why it dropped from 17. There hasn't been a template update in ages... I suspect someone performed bad fixes just to avoid the categorization. Headbomb {t · c · p · b} 12:15, 10 December 2024 (UTC)

@Headbomb: See WP:BOLD#Be careful. I don't know what the correct change should be, so it's better to get consensus here. GoingBatty (talk) 19:38, 19 December 2024 (UTC)

Links to preprint archives

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

• why bioRχiv with the identification identical with the preprint DOI number,
• why not viXra with specific identifiers (as arXiv), and
• why not other archives without specific identifiers (only preprint DOI as in bioRχiv), as medRχiv (https://www.medrxiv.org/), ChemRxiv (https://chemrxiv.org/), EarthArXiv (https://eartharxiv.org/), PsyArXiv (https://osf.io/preprints/psyarxiv), ResearchSquare (https://www.researchsquare.com/) etc.?

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

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

Simply put, there's almost nothing on vixra we should want to cite. It is not a reliable source, worse than your usual repository of preprints. It's a nutjob farm. Headbomb {t · c · p · b} 12:13, 10 December 2024 (UTC)

If you want to include a courtesy link to the free preprint, along with a citation to the print version, you can do so after the template but before the closing ref tag. As an example:

<ref>{{cite journal |author=Author |title=Title |journal=Journal |url=https://journal.org}} [https://eartharxiv.org/ Free to access preprint]</ref>

Gives you the following:

Author. "Title". Journal. Free to access preprint
-- LCU ActivelyDisinterested «@» °∆t° 14:36, 10 December 2024 (UTC)

I realize this is not the right place to bring this up, but the Visual Editor should really offer better support for this. Rjjⁱⁱⁱ (talk) 22:34, 10 December 2024 (UTC)

That workaround feels like a kludge. I would prefer to see preprint URL support integrated into the template as a preprint-url parameter, which for some reason, has not yet been proposed in any of the 96 archive pages of this talk page. The WP:PREPRINT guideline states, "links to such repositories can be used as open-access links for papers which have been subsequently published in acceptable literature", and it would be useful for the template to link to both the paywalled published version and the unpaywalled preprint without any extra workaround. Using a template parameter would also make the preprint URL more machine-readable, compared to using a separate link.

For example, I recently cited the following source:

Crowston, Kevin; Wei, Kangning; Howison, James; Wiggins, Andrea (5 March 2008). "Free/Libre open-source software development: What we know and what we do not know". ACM Computing Surveys. 44 (2). Association for Computing Machinery: 7:1–7:35. doi:10.1145/2089125.2089127. ISSN 0360-0300. Retrieved 15 December 2024.

I wanted to also include a link to this preprint of the article hosted by the Internet Archive. It would have been nice to have a preprint-url parameter that would have allowed me to do this in the {{Cite journal}} template. — Newslinger talk 22:30, 15 December 2024 (UTC)

I've been just putting the preprint URL in |url=, because the publisher's version is already linked from |doi=. I realize this creates some confusion about which version the person creating the reference is actually looking at. I don't usually verify that the versions are identical, but if I have significant doubt, I include citations for both the preprint and the final published version in the same <ref>...</ref> with "Republished as/from" between them, with the first citation being the one I was actually looking at. The word "republished" to me leaves open the possibility of more substantial changes than "reprinted". I am surprised that neither Wikipedia:Citing sources § Say where you read it nor Wikipedia:Citing sources § Dates and reprints discuss the issue specifically. I welcome feedback from other editors on my practices.

The issue of multiple versions of a work is bigger than just preprints, and |preprint-url= feels to me like a partial solution to a bigger problem. In some fields (eg. economics, public policy) working papers with multiple drafts distributed over many years are normal prior to publication. Daask (talk) 16:42, 16 December 2024 (UTC)

I've also done that before, and I agree that it can be confusing for the reader, which is why I'm hesitant to include preprints in the url parameter now. Since the sole purpose of the preprint-url parameter would be to present the reader with an open-access link, I don't think it would be necessary to link multiple drafts in the citation template. — Newslinger talk 08:53, 17 December 2024 (UTC)

Cite chapter in book with no editor

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

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

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

So I guess my post has multiple aspects:

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

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

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

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

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

J2UDY7r00CRjH, it sounds here like the problem statement is a citation like Author, Chapter. "Chapter title". Edited Volume gives the impression that the chapter author contributed all the chapters, but the theory of change is that Author, Chapter. "Chapter title". In Edited Volume will convey the correct impression?

I don't have an alternative solution to propose, but I do note that the opposite problem – volume or even series editors being attributed authorship of chapters – is more common by at least an order of magnitude. Folly Mox (talk) 13:45, 13 December 2024 (UTC)

>the theory of change is that Author, Chapter. "Chapter title". In Edited Volume will convey the correct impression?

Yes, additionally, it seems that some styles already use this format. I first saw it in this journal article: https://www.tandfonline.com/doi/full/10.1080/09596410.2017.1401797 (paywalled) (Screenshot of the relevant citation) (link to the cited book).

Looking further, I found that the APA Publication Manual (7th Edition) seems to follow this rule:

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

This is made more explicit in other guides:

1.

>Chapter in a book

>If there is no editor, include the word "In" before the book title. (link)

2.

>Chapters, Short Stories, Essays, or Articles From a Book (Anthology or Collection)

>[..] Note: If there is no editor given you may leave out that part of the citation.(link). This one is a bit ambiguous about what "that part of the citation" refers to. I don't think it includes "in."

3.

This academia.stackexchange post

So the second reason is to be in line with other citation styles. However, I'm not an expert on citation style and I may be missing something. I found these links above by searching 'how to cite volume with "no editor"' on Google. J2UDY7r00CRjH (talk) 18:52, 13 December 2024 (UTC)

I think I agree that In Edited Volume is clearer. I wonder if instead of a whole new set of |chapter-authorn= parameters and their attendant -link=s, -masks etc, an easier implementation might be a specific override value for |editor=, so if it has that value then In will appear before the book title (kinda like how |author-mask= will display text exactly as formatted, except numeric values which it displays as a string of dashes). Folly Mox (talk) 21:45, 13 December 2024 (UTC)

An override value for the editor field would also work. Is there a standard value used for such cases? I think "editor=unknown" would work here. J2UDY7r00CRjH (talk) 23:21, 14 December 2024 (UTC)

Omitting location parameter when implied by the publisher

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

I don't think this advice is valid for publishers like CUP, OUP; they often publish in various locations. OTOH, it's probably trivial and doesn't matter. -- Michael Bednarek (talk) 08:54, 15 December 2024 (UTC)

In my mind, omitting location would imply publication in the eponymous location. But yes, I'm thinking of how necessary the parameter even is in many situations. Remsense ‥ 论 08:59, 15 December 2024 (UTC)

Citeref: if no year, use year from date

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

Problem to be solved:

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

Expected breakages:

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

Solution:

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

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

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

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

Having the same CITEREF in articles that do not use short form references is not an error that needs solving.

The year in |date= is already used if it is part of the cite. However the example in Gordon Peak (CITEREFGreen) has no |date= parameter only |access-date= and |archive-date= neither of which would be appropriate to include in a short form reference. -- LCU ActivelyDisinterested «@» °∆t° 16:35, 15 December 2024 (UTC)

(edit conflict)

No. At Module:Citation/CS1 line 4114 is this:

local year = first_set ({Year, anchor_year}, 2); -- Year first for legacy citations and for YMD dates that require disambiguation

Normally, Year has been set to nil before this point in the code. anchor_year comes from Module:Citation/CS1/Date validation.

This example has |date= but does not have |year=:

{{cite book |title=Title |last=Greene |first=EB |date=15 December 2024}} → Greene, EB (15 December 2024). Title.

'"`UNIQ--templatestyles-0000004B-QINU`"'<cite id="CITEREFGreene2024" class="citation book cs1">Greene, EB (15 December 2024). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2024-12-15&rft.aulast=Greene&rft.aufirst=EB&rfr_id=info%3Asid%2Fen.wiki.x.io%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:

• Help talk:Citation Style 1/Archive 46 § Proposal: make ref=harv the default for CS1
• Help talk:Citation Style 1/Archive 66 § make ref=harv the default for CS1

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 (1) 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)

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

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

Names are not universally consistent either in publishing or the world at large—given authors are generally identified primarily by surname, one can make a clear case for explicit specification. Remsense ‥ 论 00:47, 16 December 2024 (UTC)

Also, separating them out is necessary if you want short footnotes ({{sfn}}) to link to the reference without a lot of extra hassle working around the lack of surnames. —David Eppstein (talk) 06:01, 16 December 2024 (UTC)

Separate first/last names are generally better. As said above, {{sfn}} and the like work much better with last names. It also allows better web searching for a reference when the source website changes between using between "Dee Lightful", "D. Lightful" or "Lightful". However, sometimes it is hard for us English speakers to know which part of a non-English name is the family name and which is the personal name - eg, in Foo Ling Yu many Westerners don't realise that Foo is the family name (ie the last name in western terms, even though it is at the start of the name) and Ling-Yu is the personal part of her name (ie, the first name in western terms). There are also a few Western names that are hard (eg Douglas, Michael vs Michael, Douglas). Which is why the author field is allowed and does not produce errors - it is the ultimate fallback when you do not know the correct order. Which means that the reverter was quite wrong to revert you based on faulty logic.  Stepho  talk  08:01, 16 December 2024 (UTC)

The parameters are perhaps misnamed as they really mean "given name" and "family name" regardless of name order, rather than first and last. But of course there are cultures (like say Iceland) where names don't work like that. —David Eppstein (talk) 08:25, 16 December 2024 (UTC)

Well, what they really mean is "surname" and "not surname". Remsense ‥ 论 08:27, 16 December 2024 (UTC)

Difficult to generalise: Saddam Hussein al Tikriti: 2nd name father's "forename", no family name, normal (not informal) single-word name Saddam. Federico del Sagrado Corazón de Jesús García Lorca; normal Spanish surname García, but known, unusually, by mother's surname Lorca. María-José Pérez de Gómez, known sometimes as M-J Pérez, others as Sra [de] Gómez. Pol098 (talk) 11:58, 16 December 2024 (UTC)

True. But if you look at the revert there were only 2 names changed (although multiple times each): "Benjamin, Jeff" and "Caulfield, Keith". Both English. Both already separated into surname, comma, given name. No complications. No non-English names. Also, they are displayed to the reader exactly the same but as separate fields they are much more suitable for computer processing. There was no reason whatsoever for the revert apart from WP:JUSTDONTLIKEIT.  Stepho  talk  04:45, 17 December 2024 (UTC)

One can also use the aliases |given= and |surname= for these parameters. Kanguole 12:11, 16 December 2024 (UTC)

Thank you. That's new to me and I will probably start using it.  Stepho  talk  04:45, 17 December 2024 (UTC)

Unfortunately, Wikipedia:ProveIt presently undoes this. I should probably write a script that switches an article the other way, since the solution for automated RETAIN-vio is more automation, of course. Remsense ‥ 论 22:18, 17 December 2024 (UTC)

ProveIt makes several changes to parameters, which it really shouldn't. One of the worst occurs when a reference has multiple authors – ProveIt renames the first one as |first= and |last= and moves the others later in the reference. (If Citation bot encounters these, it will change them to |first1= and |last1=, ready for ProveIt to "fix" them again.) It really should not be used on articles that already have consistent citations. Kanguole 22:28, 17 December 2024 (UTC)

I mostly used it before for its consistent ordering and spacing, but now I mostly avoid it, and make sure to manually tweak where it violates RETAIN. Remsense ‥ 论 22:30, 17 December 2024 (UTC)

Generic title

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

Cite case causes CS1 errors

{{Cite case}} maps |court= to |agency=, which is no longer supported by {{cite book}} -- see MKUltra#cite_note-107. This was brought up at Template talk:Cite case a few months ago by @DocWatson42 and @Isaidnoway, but I'm bringing it here since this is a better-watched talk page. Jay8g [V•T•E] 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:

• Fujimoto, Yukari (2012). "Takahashi Macoto: The Origin of Shōjo Manga Style". Mechademia. 7 (1). Translated by Thorn, Rachel: 24–55. doi:10.5749/minnesota/9780816680498.003.0002. ISBN 978-0-8166-8049-8.

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=[[Rachel Thorn|Thorn, Rachel]] |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}}

Fujimoto, Yukari; Thorm, Matt (2012). "Takahashi Macoto: The Origin of Shōjo Manga Style". In Lunning, Frenchy (ed.). Mechademia 7: Lines of Sight. Translated by Thorn, Rachel. pp. 24–55. doi:10.5749/minnesota/9780816680498.003.0002. ISBN 978-0-8166-8049-8.

—Trappist the monk (talk) 16:44, 20 December 2024 (UTC)

I don't have time right now to reply in full, but Mechademia is a journal in the form of a book, and the correct spelling of the particular author's name is Matt Thorn. —DocWatson42 (talk) 20:14, 20 December 2024 (UTC)

module suite update 28–29 December 2024

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

Module:Citation/CS1:

• convert Category:CS1 maint: unfit URL to properties cat Category:CS1: unfit URL; discussion

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:

• fix extended free doi bug; discussion
• bump 5-digit doi prefix limit; discussion

Module:Citation/CS1/Utilities:

• reworked hyphen_to_dash(); discussion

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

I don't have an opinion on most of these but am very happy to see the hyphen-to-dash fix. Thanks! —David Eppstein (talk) 06:01, 21 December 2024 (UTC)

Instead of Category:CS1: unfit URL could it be Category:CS1: usurped URL - it is the majority by about 3:1: unfit 11,000, usurped 46,000. The usurped will grow indef due to WP:JUDI. -- GreenC 06:21, 21 December 2024 (UTC)

Makes sense just to reparent the existing cat: usurped is a subtype of unfit. Thanks for all your work, Trappist. Folly Mox (talk) 16:46, 21 December 2024 (UTC)

Just so I understand what you are saying: You think that |url-status=unfit should categorize to Category:CS1: unfit URL and |url-status=usurped should categorize to Category:CS1: usurped URL where the latter is a sub-category of the former? Do we really need two categories?

—Trappist the monk (talk) 19:10, 21 December 2024 (UTC)

Another generic title: "Conference Paper"

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

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=27 December 2024|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 (27 December 2024). Doe, John (ed.). title (format) (type) (57 ed.). others.
Sandbox	Bloggs, Joe (27 December 2024). 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=27 December 2024|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 (27 December 2024). Doe, John (ed.). "title" (format) (type). website. others. Vol. 52, no. 38.
Sandbox	Bloggs, Joe (27 December 2024). 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=27 December 2024|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 (27 December 2024). "map" (type). In Doe, John (ed.). title (format) (57 ed.). others. Vol. 52.
Sandbox	Bloggs, Joe (27 December 2024). "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=27 December 2024|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 (27 December 2024). "map" (type). In Doe, John (ed.). "title" (format) (57 ed.). others. Vol. 52, no. 38.
Sandbox	Bloggs, Joe (27 December 2024). "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)