I'm adding/updating {{cite web}} entries on articles of towns and cities in Poland. The citation is to an official Polish website. Unfortunately, but not surprisingly, the website is almost entirely in Polish. I wish to add instructions to the citation that show how to perform the relevant search. At the moment, it seems as if the only way I can do this is to use the "quote" parameter. See, for example, this edit. I realise that this is not the intended use of this parameter, but it seems the best fit for what I'm trying to achieve. Is there another more appropriate way of doing what I'm trying here? Does there need to be a new parameter, for example? Regards, Kiwipete (talk) 03:36, 24 November 2024 (UTC)
Don't abuse cs1|2 template parameters. Put that extra stuff inside the <ref>...</ref> tags after the template's closing }}.
As with my previous edit request to the Configuration subpage, I have amended the local variable script_lang_codes to support an additional language being tagged in citation titles and chapter titles (this time Cherokeechr). As with last time, I have also amended the whole variable definition to balance the line-wrapping better, so please take the whole variable definition (lines 1177–1183).
This page (Help talk:Citation Style 1) is for discussion on how CS1 templates format citations, not about which books can be used to cite what. Discussion about citing this book would belong at Talk:Water polo. Discussion about the book's reliability in general would be at Wikipedia:Reliable sources/Noticeboard. Good luck, Rjjiii (talk) 23:34, 26 November 2024 (UTC)
Semi-protected edit request on 26 November 2024 (2)
Hi! I'm trying to figure out the date reformatting function: Module:Citation/CS1/Date validation#L-841. I see that the module can convert dates to {{#time:n F Y|2024-10-10}} -> 10 October 2024, is it possible to convert in {{#time:n xg Y|2024-10-10}} (month in genitive form) -> 10 October 2024?
It is not really clear to me what it is that you are asking. cs1|2 doesn't use the #time parser function to do date conversions.
The #time parser is not used because we can't write something like:
{{#time:Y-m-d|10 octobre 2024}}
on the French Wikipedia; doing so results in Erreur : durée invalide. This despite the #time parser's ability to render this at en.wiki:
{{#time:n F Y|2024-10-10|fr}} → 10 octobre 2024
You would think that, for an 'international' project, accepting dates with local-language month names as input would go hand-in-hand with rendering local-language month names.
Thanks for the answer! I mean that now the 'long' array from 'date_names' in Module:Citation/CS1/Configuration is used to form the date. There the months are in the nominative case, but for the Russian language the genitive case is needed for 'dmy' form and nominative case for 'my' form. Is it possible to add an additional array with genitive case? Iniquity (talk) 05:09, 21 November 2024 (UTC)
Just for clarity, you want:
10 октября 2024 ← {{#time:n xg Y|2024-10-10|ru}} – genitive for all 'dmy' dates; including ranges? what about mdy?
октябрь 2024 ← {{#time:F Y|2024-10-10|ru}} – nominative for 'my' dates only; including ranges?
#time parser function alludes to other languages that have nominative/genitive date forms. Do they follow the same rules as the Russian dates?
I have some ideas for resolution of this issue. I'll think more on it. My time is occupied elsewhere so I won't be able to get to this until later this week or next week. In the meantime, here is your assignment:
MediaWiki supports about 350 editions of Wikipedia. Assemble a list of those Wikipedia-edition languages that have nominative/genitive date forms.
determine which date formats from the above assembled list need nominative month names and which formats need genitive names.
10 октября 2024 ← {{#time:n xg Y|2024-10-10|ru}} My mistake, must be j not n - {{#time:j xg Y|2024-10-10|ru}}genitive for all 'dmy' dates; including ranges? Yes.what about mdy? We dont use this format, we can leave the nominative case, but I found something, I'll write it below.октябрь 2024 ← {{#time:F Y|2024-10-10|ru}} – nominative for 'my' dates only; including ranges? Yes, but the first letter of the first month must be capitalized.#time parser function alludes to other languages that have nominative/genitive date forms. Do they follow the same rules as the Russian dates? This is a relatively complex issue, I found such a list of formats for each language. And now it seems to me that the genitive case is not the only problem of internalization: https://codesearch.wmcloud.org/core/?q=dmy+date&files=languages%2Fmessages&excludeFiles=&repos=Iniquity (talk) 18:42, 21 November 2024 (UTC)
That can't be the whole list can it? Why is ru.wiki not on that list?
=mw.language.getContentLanguage():formatDate('j F Y') → 21 ноябрь 2024
I used that to get the month name. Then, I turned it round and attempted to get a YYYY-MM-DD date from the Russian DMY:
=mw.language.getContentLanguage():formatDate('Y-m-d','21 ноябрь 2024') → Ошибка Lua: bad argument #2 to 'formatDate': invalid timestamp '21 ноябрь 2024' ... and some other error message stuff
To prove that the call was structured correctly, I changed 'ноябрь' to 'November':
=mw.language.getContentLanguage():formatDate('Y-m-d','21 November 2024') → 2024-11-21
I was curious to see how your list of 70 matches direct testing of the time parser returns for each of the language names taken from Module:Citation/CS1/Configuration (the inter_wiki_map table). So I wrote Module:Sandbox/trappist the monk/genitive. You can see the results by adding one of these to a sandbox page:
{{#invoke:Sandbox/trappist the monk/genitive|main|a-m}}
{{#invoke:Sandbox/trappist the monk/genitive|main|n-z}}
where a-m and n-z match the first letter of a language tag. These are lua set patterns: lang:match('^[a-m]') etc.
Alas, you can't do a-z, nor can you have a-m and n-z on the same page at the same time, because the time parser chokes and emits the confusing error message: Error: Total length of format strings for #time exceeds 6000 bytes. For an explanation, see Phab:T299909 and the linked discussion.
When the test is run for each range, they find 143 languages where at least one month name returned by {{#time:F|2024-mm-01}} (mm is month number 1–12) differs from the month name returned by {{#time:xg|2024-mm-01}}.
Do all of these languages use nominative/genitive dating? I don't know.
mw.language:formatDate() won't work for this application because it does not accept (so far as I can tell from the documentation) a language parameter; You can use mw.language.new(code):formatDate(format,timestamp,local)Iniquity (talk) 19:25, 25 November 2024 (UTC)
Nope. From the documentation: "There is a limit of 200 on the number of distinct language codes that may be used on a page. Exceeding this limit will result in errors."
As idea: make a setting that will allow you to switch on the formatDate conversion function. Only ISO dates are passed to this function, and CS1 module only converts incoming dates to ISO format. Iniquity (talk) 17:35, 2 December 2024 (UTC)
Protected edit request on 1 December 2024
Can someone please add the parameters {{{quote-p}}} and {{{quote-pp}}} as aliases of {{{quote-page}}} and {{{quote-pages}}} respectively to all citation templates, excluding {{cite episode}}, {{cite podcast}}, {{cite AV media}}, {{cite mailing list}}, {{cite newsgroup}}, {{cite serial}}, {{cite sign}} and {{cite speech}}, because they're shorter forms of those parameters, and because the parameters {{{p}}} and {{{pp}}} are already aliases of {{{page}}} and {{{pages}}} respectively on all citation templates excluding those aformentioned ones? PK2 (talk; contributions) 06:42, 1 December 2024 (UTC)
This is something that needs further discussion and later will get synced through the periodic release process if wanted, not something an admin watching the edit requests queue should do immoderately, so deactivating the edit request template. * Pppery *it has begun...17:31, 1 December 2024 (UTC)
Another generic title
Hello, another generic title that we should be tracking is |title=x.com. There are about 600 of these at the moment. Keith D (talk) 21:23, 1 December 2024 (UTC)
spurious errors when fetching identifier limit data from commons
cs1|2 stores identifier limit values in tabular data on commons: c:Data:CS1/Identifier limits.tab. This little file allows us to keep identifier limits for all wikis using a recent version of the cs1|2 module suite up to date. Alas, there is some sort of spurious 'something' that sometimes causes the data fetch to fail. Currently, when a failure occurs, all cs1|2 templates on a page render a shrieking-red error message: Lua error in Module:Citation/CS1/Configuration at line 2083: attempt to index a boolean value and complaints at various help and village pump pages. The fix is a null edit.
I have tweaked the sandbox so that it traps the boolean return, sets the identifier limits to 99,999,999,999 which will cause all limit checks to pass, and adds the page to Category:CS1 maint: ID limit load fail. Articles collected in the category can be null edited to clear the category. Unlike all other maintenance categories, this category does not have an accompanying maintenance message because it would be repeated by every cs1|2 template.
I tested this new code by disabling the category namespace limit so that a cs1|2 template in my sandbox would emit the error category when I forced a boolean false return from the data fetch.
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)
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?
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."
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)
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
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:
I realize this is not the right place to bring this up, but the Visual Editor should really offer better support for this. Rjjiii (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:
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. — Newslingertalk08:53, 17 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 talk08: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)
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 talk04: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. Kanguole22: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)
Request to edit note at top of Category:CS1 maint: unflagged free DOI
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)
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.
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:
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)
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)
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/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
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)
{{cite book|title=Title |last=Greene |first=EB |date=15 December 2024}} → Greene, EB (15 December 2024). Title.
'"`UNIQ--templatestyles-0000003F-QINU`"'<citeid="CITEREFGreene2024"class="citation book cs1">Greene, EB (15 December 2024). ''Title''.</cite><spantitle="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%2FArchive+97"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 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.
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)
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=9 March 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}}
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=9 March 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}}
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.
Not really 'issues'. All of your examples are correct except for the fourth example:
cites a standalone or sheet map; |volume= and |issue= are inappropriate
cites a map in a periodical; the periodical parameters are: |journal=, |magazine=, |newspaper=, |periodical=, |website=, |work=; |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 |issue= (a periodical parameter)
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}}.
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)
{{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.
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?
"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. -- GreenC20: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.
{{cite journal |last1=Milona |first1=Michael |last2=Weindling |first2=Lauren |title=The Story of Romantic Love and Polyamory |journal=[[Journal of Applied Philosophy]] |date=2024 |doi=10.1111/japp.12764 |doi-access=free |issn=0264-3758 |oclc=10395234777}} produces:
There are a number of links to books which have since lost their accessibility to the general public on Internet Archive (e.g., [2] and [3] 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)
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. -- GreenC00:24, 17 December 2024 (UTC)
That particular book is not fully browsable, click 'next page'.
"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. -- GreenC02:50, 17 December 2024 (UTC)
Thank you for the clarification. Given that the current possibilities are:
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)
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}}
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)
Is there a full list of all names that are considered 'generic'?
I'm working on a script that searches through CS1 templates with generic names and provides a list of the most common first and last names that throw an error in the template. I couldn't find it on the category page, but is there a copy of the test that templates run through so I can do it locally on my machine?
There are some CS1 parameters that are not allowed in templates where they make sense and would be useful. An example is {{cite journal}}. Journal articles are often available on the WWW and often have numbered sections, but |section= and |section-link= are not available, although there is a hack (|at=link). -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 15:02, 8 January 2025 (UTC)
@Chatul Do the sections have different authors? I thought that was the purpose of section/chapter, to cite different pieces by different people within the same book, Rjjiii (talk) 15:23, 8 January 2025 (UTC)
|title= should be used for the article in the journal, so is this about a section of the article without page numbers? Do you have an example? If you're referencing part of an article without page numbers but numbered sections then |at= seems appropriate. -- LCU ActivelyDisinterested«@» °∆t°19:54, 8 January 2025 (UTC)
In this case there are no page numbers, but it wouldn't help if the were, since |at=, |page= and |pages= are mutually exclusive. In this case I am using
{{cite journal | journal = Communications of the ACM | volume = 6 | issue = 1 | date = January 1963 | title = Revised Report on the Algorithmic Language Algol 60 | editor = Peter Naur | editor-link = Peter Naur | author1 = J.W. Backus | author-link1 = John Backus | author2 = F.L. Bauer | author-link2 = Friedrich L. Bauer | author3 = J.Green | author4 = C. Katz | author5 = J. McCarthy | author-link5 = John McCarthy (computer scientist) | author6 = P. Naur | author-link6 = Peter Naur | author7 = A.J. Perlis | author-link7 = Alan Perlis | author8 = H. Rutishauser | author-link8 = Heinz Rutishauser | author9 = K. Samuelson | author10 = B. Vauquois | author-link10 = Bernard Vauquois | author11 = J.H. Wegstein | author-link11 = Joseph Henry Wegstein | author12 = A. van Wijngaarden | author-link12 = Adriaan van Wijngaarden | author13 = M. Woodger | author-link13 = Mike Woodger | at = 3.2.4. Standard functions | url = https://doi.org/10.1145/366193.366201 | publisher = Association for Computing Machinery | doi = 10.1145/366193.366201 | s2cid = 7853511 }}
That article has page numbers though? |pages=1–17 (section 3.2.4 is on p. 6). Also remember |doi-access=free. I could see wanting a |section= for online-only journals where there is no true pagination, but |at= does seem to be doing an adequate job. Folly Mox (talk) 21:44, 8 January 2025 (UTC)
Isn't this the purpose of |at=, for when a page number is inappropriate or insufficient? Section is even listed as an example usage in the documentation. -- LCU ActivelyDisinterested«@» °∆t°00:56, 9 January 2025 (UTC)
Strange placement of others in journal citation
"Others", in a journal citation, is placed between the issue number and the page numbers. Example (from Garden of Eden (cellular automaton)):
{{citation
| last = Bartholdi | first = Laurent
| others = with an appendix by Dawid Kielak
| arxiv = 1605.09133
| doi = 10.4171/JEMS/900
| issue = 10
| journal = Journal of the European Mathematical Society (JEMS)
| mr = 3994103
| pages = 3191–3197
| title = Amenability of groups is characterized by Myhill's theorem
| volume = 21
| year = 2019}}
Bartholdi, Laurent (2019), "Amenability of groups is characterized by Myhill's theorem", Journal of the European Mathematical Society (JEMS), 21 (10), with an appendix by Dawid Kielak: 3191–3197, arXiv:1605.09133, doi:10.4171/JEMS/900, MR3994103
Manually substed: Bartholdi, Laurent (2019), "Amenability of groups is characterized by Myhill's theorem", Journal of the European Mathematical Society (JEMS), 21 (10), with an appendix by Dawid Kielak: 3191–3197, arXiv:1605.09133, doi:10.4171/JEMS/900, MR3994103
Sandbox: Bartholdi, Laurent (2019), "Amenability of groups is characterized by Myhill's theorem", Journal of the European Mathematical Society (JEMS), 21 (10), with an appendix by Dawid Kielak: 3191–3197, arXiv:1605.09133, doi:10.4171/JEMS/900, MR3994103
This strikes me as unlikely to be the best place to put it. In this example, the arXiv version lists both authors. The journal article landing page puts the "with an appendix by..." text into a subtitle of the article title, as does the BibTeX that I get from doi.org. The MathSciNet BibTeX data which I used to generate this citation instead separates it out into a note= field of the BibTeX. zbMATH just omits Kielak from the metadata altogether. I think others= should be the correct way of handling this, if only it produced reasonable formatting. —David Eppstein (talk) 04:48, 9 January 2025 (UTC)
Putting aside how to get this specific citation formatted in a way that doesn't look stupid, maybe we could make the others= parameter useful instead of having to use hacks to work around its bad behavior? My strong suspicion is that using hacks to work around bad alternatives was also the motivation for putting the additional contributor in the subtitle rather than somewhere more principled. —David Eppstein (talk) 06:09, 9 January 2025 (UTC)
The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move reviewafter discussing it on the closer's talk page. No further edits should be made to this discussion.
– 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 per David Eppstein and ActivelyDisinterested. Redirects are cheap until someone decides they all need to be bypassed, which people often choose to do en masse for some reason. And it's not clear how "AV media" could be confused for anything but "audio-visual media". I legitimately checked for possible confounders and came up empty.As an aside, I have also seen {{Cite journal}} to cite a diary, but the more common cases of confusion – in steeply ascending order – are people trying to use {{Cite document}} inappropriately to cite an online source, because it's a "document" (as if any written material isn't), and User:Citation bot swapping in an incorrect template because it sees an isbn or something.{{Cite tech report}} → {{Cite technical report}} is less objectionable, but still seems undesirable. Again, what do people think "tech report" might mean apart from "technical report"? (I suppose "technology report" or "technique report" might be theoretically possible.) Good faith request, but unconvincing, and neglects drawbacks. Folly Mox (talk) 17:00, 5 January 2025 (UTC)
Oppose for the AV templates, I think there is a good argument that AV is more obvious than audiovisual. Meh on tech to technical. Skynxnex (talk) 02:46, 6 January 2025 (UTC)
Oppose for the same reasons. The clarity benefit is marginal, outweighed by the (much) longer name, and the change is likely to cause unwanted churn. Looking at the AV disambiguation page, I don't see anything potentially confusing. Do we cite to Adult Video a lot? 97.102.205.224 (talk) 21:51, 7 January 2025 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
How to cite one of them
I have three articles all published in the same publication (The Daily Telegraph), in year (1923) and the same month (January), but on different days. The question is how to cite one of them using sfn.
Smith, Graftoon Elliot (1923-01-19). "The Tomb of Tutankhamen". The Daily Telegraph. pp. 9–10.
Smith, Graftoon Elliot (1923-01-23). "The Tomb of Tutankhamen". The Daily Telegraph. p. 9.
Smith, Graftoon Elliot (1923-01-25). "The Tomb of Tutankhamen". The Daily Telegraph. p. 9.
Add "ERROR" to the "generic_titles" list in "Module:Citation/CS1/Configuration"
Hi, I noticed that a website has issues in their metadata and if you use VE Cite generator tool for that website, it gives you something just like this one. It should report the error for the |title=. Also, the link itself is not good for the references list; I don't know if there is something interesting like title to catch it's generated link too. Thanks! ⇒ AramTalk12:49, 11 January 2025 (UTC)
Module support edit req
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?
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)
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=[[Rachel Thorn|Thorn, Rachel]]|pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}}
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.
It cannot be worked around by (()) because the argument to the template is only a part of the title from which the template constructs the rest of the title. I changed it to L0033073, matching numero de notice in the top left of the link, but the double-slash form is not a typo; it comes from a line "Cote(s) : LH//33/73" in the main text of the link. I think this should not be flagged as an error. This template is transcluded some 50 times and at least some others of its transclusions are raising the same error message. —David Eppstein (talk) 06:40, 15 January 2025 (UTC)
Simpler case:
{{cite web |url=https://www.leonore.archives-nationales.culture.gouv.fr/ui/notice/5166 |title=Notice no. LH//33/73}}
I have tightened the protocol-relative test a bit so that the authority indicator (//) must be preceded by nothing or by whitespace to be recognized as a url:
I tried wrapping the whole title in double parens at {{Base Léonore}} and on the template's testcases page, but the URL error still appears. I may have done it wrong. Do double parens work for this purpose in |title=? – Jonesey95 (talk) 17:47, 16 January 2025 (UTC)
No. This particular test occurs very early in the basic validation of all template parameters; before we recognize the accept-as-written markup. Without someone has a better idea, fixing the error detector as I have done is the better solution to the apparent-authority-indicator-in-title problem.
Hello, a generic author starting like |author=Custom byline text. There are 18 cases at the moment, but I will tidy them up. Keith D (talk) 16:40, 16 January 2025 (UTC)
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?
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. (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 Wikipedia. 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_paramand'ymd'==pattern_idxthen-- special case for ru.wikireturnmw.language.new('ru'):formatDate('j xg Y',date);-- convert ymd to dMyend
With that code in place, the remaining tests return 15 января 2001, 30 декабря 2024, and 31 декабря 2024.
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_paramand'ym'==pattern_idxthen-- special case for ru.wikireturnmw.language.new('ru'):formatDate('xg Y',date);-- convert ym to Myend
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.
{{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:
I begin to wonder why you haven't written an ru-wiki-specific ~/Date validation module.
archive_date_check() compares |archive-date= in YYYY-MM-DD format to the timestamp date from |archive-url=, also in YYYY-MM-DD format. To do that it reformats whatever the current|archive-date= value is after reformatting. In your example, the template parameter is |archive-date=2009-02-22. The module then converts that to 22 февраля 2009 because that is your preferred format. If all dates in the template have valid formats, cs1|2 will check the archive date (22 февраля 2009) matches the archive url timestamp (20090222235636).
reformatter() correctly converts 22 февраля 2009 to 2009-02-22 but then, at line 1025 you force a conversion of 2009-02-22 back to 22 февраля 2009. The test at line 1244 then fails because 22 февраля 2009 ≠ 2009-02-22.
I don't know what you mean by something happened to the definition of the month.
I begin to wonder why you haven't written an ru-wiki-specific ~/Date validation module. 1. I don't have enough knowledge of Lua for this 2. I'm afraid writing a new module may become a critical problem when updating reformatter() correctly converts 22 февраля 2009 to 2009-02-22 but then, at line 1025 you force a conversion of 2009-02-22 back to 22 февраля 2009. The test at line 1244 then fails because 22 февраля 2009 ≠ 2009-02-22. Thank you! I'll go check if I can fix it. I don't know what you mean by something happened to the definition of the month. The month is always considered invalid: ru:Категория:Википедия:Обслуживание CS1 (DOI_неактивен). Iniquity (talk) 19:55, 18 January 2025 (UTC)
Hello, another candidate for generic title would be those starting |title=You are being redirected. Currently 416 instances of this. Keith D (talk) 22:19, 19 January 2025 (UTC)
Syntax highlighting inconsistency
There's an inconsistency in the Lua modules. Most are syntax highlighted with line numbers:
There is a size boundary beyond which syntax highlight dare not go. The boundary is set by the $wgSyntaxHighlightMaxLines and $wgSyntaxHighlightMaxBytes configuration settings which, according to Category:Pages with syntax highlighting errors, are currently specified as 1000 lines and 102,400 bytes. As of the 2024-12-28 update, Module:Citation/CS1 is 226,000+ bytes and 4500+ lines; Module:Citation/CS1/Configuration is 114,000+ bytes and 2500+ lines. All of the others have fewer than 80,000 bytes.
So the answer to your question is: refactor Module:Citation/CS1 and Module:Citation/CS1/Configuration into several smaller modules.
How to use it in Wiktionary (template / alternatives - templates- / alternative tools for conversion ??). 147.84.197.175 (talk) 14:02, 23 January 2025 (UTC)
I don't know what you're asking. According to Wikidata, some version of Module:Citation/CS1 exists on a mere handful of Wiktionaries. Which Wiktionary are you thinking about?
I've ran across several articles that actually have a double slash // in the title of the source, and for some reason it is being interpreted as a CS1 error: external link (This error occurs when a URL is found in any parameter that is not one of these URL-holding parameters), but they are not URLs; the double slashes are really in the title of the sources:
Is it okay to just remove them, or reduce them to just one slash/. In one instance, I removed them, and in another I reduced it to just one slash, which resolved the cite error. But it seems like a problem when I started to run across multiple instances.Isaidnoway(talk)07:23, 24 January 2025 (UTC)
|title=ON THE RECORD: //Civil Society in Kosovo// – Volume 9, Issue 1 – August 30, 1999 – THE BIRTH AND REBIRTH OF CIVIL SOCIETY IN KOSOVO – PART ONE: REPRESSION AND RESISTANCE
because a whitespace character precedes the first 'authority' indicator (//). A fix might be:
|title=ON THE RECORD: //Civil Society in Kosovo// – Volume 9, Issue 1 – August 30, 1999 – THE BIRTH AND REBIRTH OF CIVIL SOCIETY IN KOSOVO – PART ONE: REPRESSION AND RESISTANCE
CS1|2 maintains a short list of 'titles' that are typically not the title of the cited source. If you are aware of other common place-holder titles, please report them at Help talk:Citation Style 1, so that they can be added to the list.
Please add- Private Site, You are being redirected, Loading..., Privacy error, Domain for sale, Diese Website steht zum Verkauf!, Expired website. Some of these I have been working on for the last month so might not be many instances left Lyndaship (talk) 18:39, 21 January 2025 (UTC)
I was editing Åland and I found three books in the Further reading section with links to book reviews. I think the links should be deleted, but I ask anyway: is it legit to link a book to a review? Is there a template to use?-- Carnby (talk) 20:33, 25 January 2025 (UTC)
Yes, of course. Book reviews are one of the most important sources, because they demonstrate independent third party notability, see WP:NBOOK criteria #1. On Wikipedia, we report on what other people said about something. And that's what book reviews are. They are very important citations. No need for a special template for book reviews. -- GreenC20:41, 25 January 2025 (UTC)
Book reviews are appropriate references for an article on a book or an article on an author. And sometimes a book review can be a convenient reference for a claim that is described more clearly in the review than in the book that it reviews. But that is not what these ones are. Instead, they are reviews of books about a place, placed as footnotes on the listings of those books in the further reading section of the article about that place. Because the further reading section comes after the references section (as it should), these footnotes end up getting expanded at the bottom of the article after all the navboxes. I do not think they are needed in this context and agree with Carnby that they should be deleted.
As for a template to use: in contexts where they are used appropriately as references, book reviews published in academic journals (as these ones are) can be formatted using {{cite journal}}, book reviews published in newspapers can be formatted using {{cite news}}, etc. We don't have separate review templates. If we really wanted to keep these ones they could be more appropriately placed within the article by adding another "Reviews of further reading" section with another {{reflist}} but why would you want to do that? —David Eppstein (talk) 20:51, 25 January 2025 (UTC)
In this case it looks like the original editor was further reading the book about the place, not the review of the book, then included a citation to a review as a courtesy to learn more about the book and verify its existence, which is probably better than linking to a publisher or Google Books, which are often devoid of much contextual and contain commercial links for buying the book. -- GreenC21:21, 25 January 2025 (UTC)
There is also the problem of footnotes in the further reading section, per MOS:LAYOUT it goes after the reference section. Probably the best solution is delete the reviews and convert the books into {{cite book}} (not footnoted) with an |isbn=. -- GreenC21:30, 25 January 2025 (UTC)
Need help with a "CS1 errors: generic name" reference
|author3=((Board on Health Sciences Policy)) |author6=((Policy and Global Affairs))
Another approach would be to follow the citation suggested on the copyright page of the book, which shows only one author: National Academies of Sciences, Engineering, and Medicine. --Worldbruce (talk) 04:32, 27 January 2025 (UTC)
HTML ampersand-coded letters cause CS1 maint errors
HTML ampersand-coded letters (such as ö, ñ, é, ù) cause CS1 maint errors in human parameters such as |author=, |editor=, |interviewer=, |translator=, and their variants. If the parameter ends with an encoded letter, it generates a bogus CS1 maint: extra punctuation error. If the parameter includes an encoded letter, it generates a bogus CS1 maint: multiple names: ... list error. I haven't tested HTML ampersand-coded letters in any other parameters. For examples, see this version of my Lint Test sandbox. —Anomalocaris (talk) 06:51, 26 January 2025 (UTC)
I do not agree that they should be replaced. It is much easier to tell that − and – are properly distinguished from each other and used correctly than to look at "−" and "–" and tell which one of those is which. Spelling it out with ampersand-coding plays a valuable role here in making our orthography correct and maintainably correct. —David Eppstein (talk) 08:29, 26 January 2025 (UTC)
Which shows, incidentally, that these character codes don't cause spurious maintenance errors in |title=, viz: {{cite journal |journal=Journal |title=Über}}: "Über". Journal. —Anomalocaris (talk) 08:50, 26 January 2025 (UTC)
They do when at the very end of a parameter, or in the middle of a author/editor parameter, see Anomalocaris' sandbox, because a ; is considered stray punctuation when in that position (end), or a seperator (middle). Headbomb {t · c · p · b}08:52, 26 January 2025 (UTC)
I'm rather surprised these are being added in the first place (I thought everyone has copypaste). They must be unhealthy for the metadata. I agree that – in human parameters, which seem to be the scope here – they should be replaced with their equivalent plaintext glyphs.To that end, perhaps a better solution than baking into the module a translator for these or other complicated regex, would be to allow the errors to persist, but add a bot to patrol the maint cats periodically and fix them as they arise.I think it was established recently that edits which don't change the rendered page apart from removal of maintenance categorisation are not violations of COSMETICBOT. Can't remember where I read that though. Folly Mox (talk) 14:21, 26 January 2025 (UTC)
No, but I'm not sure that we need to. In general, I think that named html entities should be replaced with their glyphs so the maintenance message (not an error message) is appropriate. A few, like − (−), – (–), — (—), etc should be replaced with {{minus}}, {{en dash}}, {{em dash}} so, again maintenance message is appropriate.
We don't. If one is to believe this search, there are some 17000 articles that have %7C or %7c in |url= values. This search times out but for me showed only about 35 articles with %257C or %257c in |url= values. These results suggest that %7C, %7c, %257C or %257c commonly occur in valid urls
So, if we are to look for bogus urls, we will need to test the text that follows each occurance of %7C, %7c, %257C or %257c against our various parameter whitelists. This would be much like the tests we do for parameter names missing the leading pipe.
It would be good to track. 35 %257C looks in the ballpark. The hardest part is distinguishing errors from legitimate. Maybe try and see, filter out arguments that generate false positives. -- GreenC19:32, 26 January 2025 (UTC)
Some years ago one of you two posted this search (probably at this page). It didn't seem to time out and yields 735 mainspace hits. Not sure what the difference is. Folly Mox (talk) 12:37, 29 January 2025 (UTC)
Protected edit request on 29 January 2025
Hello. Can you please add EuDML and Numdam identifiers to the citation module?
within "local id_handlers", between "['EISSN']" and "['HDL']":
['EUDML']={parameters={'eudml','EUDML'},link='European Digital Mathematics Library',redirect='EuDML (identifier)',q='Q30897186',label='EuDML',prefix='https://eudml.org/doc/',COinS='pre',-- use prefix valueencode=true,separator=' ',},
between "['MR']" and "['OCLC']":
['NUMDAM']={parameters={'numdam','NUMDAM'},link='Numdam',redirect='Numdam (identifier)',q='Q3346322',label='EuDML',prefix='https://eudml.org/doc/',COinS='pre',-- use prefix valueencode=true,separator=' ',},
--[[--------------------------< E U D M L >-----------------------------------------------------------------------A numerical identifier of five or more digits.]]localfunctioneudml(options)localid=options.id;localhandler=options.handler;ifnotid:match('^%d%d%d%d%d+$')then-- is it normal format?set_message('err_bad_eudml');-- no, set an error messageoptions.coins_list_t['EUDML']=nil;-- when error, unset so not included in COinSendreturnexternal_link_id({link=handler.link,label=handler.label,q=handler.q,redirect=handler.redirect,prefix=handler.prefix,id=id,separator=handler.separator,encode=handler.encode});end
between "local function mr" and "local function oclc":
--[[--------------------------< N U M D A M >-----------------------------------------------------------------------A Numdam identifier consists of a string of upper case letters and five possibly empty strings of digits and possibly hyphen, separated by underscores, e.g. CM_1975__31_2_219_0 or SB_1987-1988__30__187_0.]]localfunctionnumdam(options)localid=options.id;localhandler=options.handler;ifnotid:match('^%u+_[%d-]*_[^_]*_[%d-]*_[%d-]*_[%d-]*_0$')then-- is it normal format?set_message('err_bad_numdam');-- no, set an error messageoptions.coins_list_t['NUMDAM']=nil;-- when error, unset so not included in COinSendreturnexternal_link_id({link=handler.link,label=handler.label,q=handler.q,redirect=handler.redirect,prefix=handler.prefix,id=id,separator=handler.separator,encode=handler.encode});end
Have you established somewhere a consensus that demonstrates a need to add these identifiers to cs1|2? Neither of your suggested links, European Digital Mathematics Library and Numdam, link to articles at en.wiki which, to me, suggests that they are not sufficiently used to warrant addition to the module. There is a template {{EuDML}} which is used in only two articles. Apparently no {{Numdam}} template.
慈居, the usual practice before adding a new identifier parameter is to use it in |id= along with an appropriate linking template. When the utility of a new identifier has been identified through its use in many pages, we can discuss converting it to a standalone identifier parameter. – Jonesey95 (talk) 19:33, 28 January 2025 (UTC)
My bad I haven't. I had linked EuDML in |id= without knowing there is a template for it [5]. I haven't linked Numdam so far. 慈居 (talk) 19:54, 28 January 2025 (UTC)
{{cite journal |title=none |journal=Journal}} but not {{cite magazine |title=none |magazine=Journal}}
{{citation |journal=Journal}} but not {{citation |magazine=Journal}}
I don't see why we allow |title=none, for citations other than journal citations, as a "get out of red jail free card", but for journal citations, it's a "go from red jail to green jail free card". This makes no sense to me at all. Respectfully, —Anomalocaris (talk) 03:05, 31 January 2025 (UTC)
Nested ref tags with title=none
If and when the <ref base=id>...</ref> support for nested references comes online, will it be appropriate to use |title=none for subordinate references, or will that mess up the metadata? -- Shmuel (Seymour J.) Metz Username:Chatul (talk)
Documentation missing for script-chapter and trans-chapter
I am unable to find any documentation on the {{cite}} template documentation for the parameters script-chapter and trans-chapter. Please add it. I would do so myself but I don't have the requisite knowledge about these parameters. Actually, the doc page doesn't even mention trans-chapter but I tried to use it and didn't get an error message, plus it generated the desired HTML, so it evidently exists. Thisisnotatest (talk) 10:48, 1 February 2025 (UTC)
{{cite}} is a redirect to {{citation}}. See Template:Citation § Title where, under the chapter bullet point, you will find documentation for |script-chapter= and |trans-chapter=.
I would recommend against a single template. Many non-English wikis import articles from en.wiki. It will be easier on your importers if you support the full suite of cs1|2 templates on your wiki.
I want to import it for Wiktionary so article importing is not a problem. Atm we have 1 generic template and community might want to still have one, but I would prefer to have separate templates. Sławobóg (talk) 17:52, 30 January 2025 (UTC)
It might be beneficial to add script- and trans- variations of the following parameters:
first
last
(and all the numbered versions of the above two)
journal
publisher
I had to manually add <bdi lang="zh">...</bdi> to various uses of {{cite}} on Checked tone which used Chinese characters for one or more of those parameters.
Do not include html markup in author/contributor/editor/interviewer/translator name-list parameters. See Template:Citation § COinS. I have removed that markup from Checked tone. See elsewhere on this page or in recent archives for discussion about a method used to support Asian names in proper family/given name-order.
To reiterate my position in the linked discussion, I think |script-human= parameters would be more intuitive and less hacky than the |person-mask= overloading we're currently doing, and also recognise this is an easy position for me to take, having no responsibility for updating the codebase. Folly Mox (talk) 18:58, 3 February 2025 (UTC)
@Trappist the monk: So my question would be, is author-maskn a legitimate place to introduce either a sub-template or HTML in order to provide WCAG-2.1-AA-3.1.2-Language-of-Parts-compliant markup in the generated HTML?
given that author-mask is not one of the parameters which is picked up as Wikidata?
There is the separate issue that |last1=童 |first1=庆炳 | doesn't get correct language markup in Wikidata's entry for the reference - presumably gleaned from the corresponding reference in Checked Tone - which is one more argument in favor of script-lastn and script-firstn. This applies to any field picked up by Wikidata that does not already have a means of language marking and which can contain non-English content.
That is, script-whatever would properly be used not just for non-Latin scripts, but for any non-English content in a reference so that it is correctly marked for language both on Wikipedia and on Wikidata.
Actually, Wikidata's entry for the reference doesn't link back to the Checked tone article in the Wikipedia section of the page, so it's not clear to me that Wikidata is even scanning these references. If I'm misunderstanding how Wikidata works, please be so kind as to point me to the appropriate reference. I read the Wikidata FAQ and Wikidata in Wikimedia projects and couldn't find anything on how citations automatically gets slurped from Wikipedia to Wikidata. Thisisnotatest (talk) 10:25, 2 February 2025 (UTC)
The skeptic in me suspects that wikidata does not extract language information from cs1|2 template parameters. I would expect to have participated in some sort of inter-project discussion were that the case. I could be wrong, of course; they might have set about doing on their own hoping that we wouldn't change how we do things here. You might ask the initial author of d:Q63758067 (Stevenliuyi) how it is that title (P1476) knows that 社会文化对文学修辞的影响 is Chinese.
You may use either method that you describe above in |author-mask=.
@Trappist the monk: Actually, I am informed that there is no automatic official transfer of data from Wikipedia cites to Wikidata. Presumably someone could create a bot that reads the COinS data and updates Wikidata, but it does not happen now. The entry I linked to was created manually, and the only bot update was to add an Arabic translation. My bad. That said, it would be good if all data on English Wikipedia not in English were properly marked for language so as not to result in inaccessible content in the COinS downstream. Thisisnotatest (talk) 02:37, 4 February 2025 (UTC)
Numbers follow the 'handedness' of adjacent text so right-to-left Arabic text causes left-to-right 2024-04-15 to render as right-to-left 15-04-2024.
If this reference is really a journal, use {{cite journal}}. Use |script-title= and |script-journal= (or |script-website=). Rewrite the date as |date=April 15, 2024 or as |date=15 April 2024:
{{cite web|access-date=2024-04-17 |archive-date=2024-04-18 |archive-url=https://web.archive.org/web/20240418005945/https://www.al-madina.com/article/883308/%D8%AB%D9%82%D8%A7%D9%81%D8%A9/%D8%AA%D9%83%D8%B1%D9%8A%D9%85-%D8%A7%D9%84%D8%B1%D9%88%D8%A7%D8%AF-%D9%8829-%D9%81%D9%8A%D9%84%D9%85%D8%A7-%D9%84%D8%B3%D8%A8%D8%A7%D9%82-%D8%A7%D9%84%D8%AC%D9%88%D8%A7%D8%A6%D8%B2 |author=جدة |date=15 April 2024 |first=سهيل طاشكندي- |script-website=ar:جريدة المدينة |language=ar |script-title=ar:تكريم الرواد.. و29 فيلماً لسباق الجوائز |url=https://www.al-madina.com/article/883308/%D8%AB%D9%82%D8%A7%D9%81%D8%A9/%D8%AA%D9%83%D8%B1%D9%8A%D9%85-%D8%A7%D9%84%D8%B1%D9%88%D8%A7%D8%AF-%D9%8829-%D9%81%D9%8A%D9%84%D9%85%D8%A7-%D9%84%D8%B3%D8%A8%D8%A7%D9%82-%D8%A7%D9%84%D8%AC%D9%88%D8%A7%D8%A6%D8%B2}}
cs1|2 looks at the parameter input values when deciding if there is an error. The input was 2024-04-15 which is valid so this template does not render a date error message.
Requested code changes for wikis that lack access to commons tabular data on Module:Citation/CS1/Configuration
On some wikis, line 2088 in Module:Citation/CS1/Configuration causes an error because CS1/Identifier limits.tab doesn't load, so calling .data on a falsey value throws an error rather than failing gracefully (as it looks like it was intended to do).
Really? There are wikis that exclude or prevent access to commons tabular data? Why? Which wikis? If there is a known list of these wikis then another solution would be preferable because the 'temporary' escape (setting id limits to 99999999999) is for those transient events that occur when commons fails to deliver the tabular data (this is perhaps Phab:T229742).
Izno is correct. The reason it doesn't (currently) work on test wiki is because it is (currently) configured to use a test commons which lacks the file, so that's unrelated to the phab task. All other WMF hosted wikis are connected to commons proper, so it shouldn't be an issue for them. It would be more an issue for third party mediawikis, or in testing environment where commons isn't set up. For test wikipedia and local testing environments this fix is probably fine, not sure how worth investing in it is for the use case of third party mediawiki installations who chose to import en wiki citation templates. Mvolz (WMF) (talk) 13:31, 4 February 2025 (UTC)
article-number= for cite conference?
It appears to be the case that article-number= works only for {{cite journal}} and not for {{cite conference}}. It also appears to be the case that conference papers published in the Proceedings of the SPIE series of proceedings (example: doi:10.1117/12.794626) use article numbers rather than page numbers. This is especially problematic because if one uses page=705902 rather than article-number=705902 one gets "p. 705902" when it is not a page number. In this particular case one could use pages=705902-1 – 705902-12 but there may be other cases where no page numbers can be found. Would it maybe be possible to allow article-number= to work in such cases? —David Eppstein (talk) 08:05, 4 February 2025 (UTC)
Where are you see it not work? In this example, |article-number=705902 renders just before the DOI:
{{cite conference|author=Julio C. Chaves |author2=Waqidi Falicoff |author3=Bill Parkyn |author4=Pablo Benítez |author5=Juan C. Miñano |date=2008 |title=Increased brightness by light recirculation through an LED source |editor=Roland Winston |editor2=R. John Koshel |book-title=Nonimaging Optics and Efficient Illumination Systems V |volume=7059 |article-number=705902 |doi=10.1117/12.794626}}
Julio C. Chaves; Waqidi Falicoff; Bill Parkyn; Pablo Benítez; Juan C. Miñano (2008). "Increased brightness by light recirculation through an LED source". In Roland Winston; R. John Koshel (eds.). Nonimaging Optics and Efficient Illumination Systems V. Vol. 7059, art. 705902. doi:10.1117/12.794626.
Ok, thanks. At some point I had it formatted (inaccurately) as cite book rather than cite conference; maybe that's where I saw it not working. —David Eppstein (talk) 08:23, 4 February 2025 (UTC)
Date: Fall 2020–2021
This source is dated Fall 2020–2021. Or more precisely "Fall semester 2020/21". I imagine it refers to the Fall term of the 2020–2021 academic year, or possibly instead a university term that began in Fall 2020 and continued into the next year. Searching Google for the exact strings "Fall Semester 2020-21" and "Fall Semester 2020-2021" finds many matches at many universities worldwide. Anyway, whatever it means, that is the date stated in the source, but setting the reference date to "Fall 2020–2021" generates an error. Double parens do not clear the error, they only make it worse by showing the parens. Spacing the en-dash also does not work. Please make it possible to correctly cite this source using the date that the source itself specifies. Replies suggesting that I should make up some other date than what the source specifies will not be taken seriously. —David Eppstein (talk) 06:50, 20 January 2025 (UTC)
And we already have our first attempt at distorting the date to something else than what the source says, triggered by the template's failure to accept the correct date: Special:Diff/1270588327. —David Eppstein (talk) 08:26, 20 January 2025 (UTC)
For those of us living in the southern hemisphere, we need to translate "fall 2020-2021" into "summer 2020-2021" - today was an over 40 °C (104 °F) summer day. It breaks our train of thought while we deal with this small but excessively annoying habit of northerners. Try hard to use months whenever possible unless it really is something to do with the seasons - eg sowing time, harvest time, skiing season, etc. See WP:SEASON. Stepho talk09:08, 20 January 2025 (UTC)
Well, no. It states that the preface (written as a personal address from the author) was dated August 2020. But it is not the preface that is being used as a source. —David Eppstein (talk) 21:10, 20 January 2025 (UTC)
Respectfully, I'm not interpreting Fall semester 2020/21 as a date of publication; but rather more along the lines of a subtitle, being the academic term the materials have been prepared for.I've also found dates of prefaces to be somewhat unreliable: although strictly preceding publication, they may be separated by months or more depending on the process of publication (clearly not much of an issue for this type of source). I feel like |date=2020 would be adequate here, but maybe I'm not sticklerish enough about this parameter. Folly Mox (talk) 13:53, 20 January 2025 (UTC)
Whoops sorry Stepho I meant to ping Benjamin Castro3; forgot it was a separate comment (scrolled off screen) by the time I finished editing out the pointless asides from my comment just above.I do try to disambiguate seasons with the descriptor Northern, but need to mention seasons with some frequency. Folly Mox (talk) 13:59, 20 January 2025 (UTC)
We really shouldn't be applying any semantics to the date. The date is whatever the publication says it is. If a periodical wants to publish five issues per year, labeled Winter, Spring, Early Summer, Late Summer, and Autumn, those are what we should put in the date field. It's a way to locate an item in a collection. What are you going to do if something lists its publication date on the Hebrew calendar? Or the Chinese? RoySmith(talk)20:18, 21 January 2025 (UTC)
We choose to check dates because editors here make errors all the time. "Fall 2020–2021" is meaningless as an actual date; I would use |date=2020 and put the bizarre issue description in |issue= and be done with it. It is useful to have the issue information as printed on the cover so that people looking for the source can find it more easily. – Jonesey95 (talk) 22:30, 21 January 2025 (UTC)
So you're in the camp that prefers to make up fake dates for references than to use the date as written, and prefers to confuse failure of imagination with meaninglessness. Got it. Also, in this case the reference is not a periodical. Its "Fall 2020–2021" date probably refers to a term in an academic year, and "2020" would actually be more ambiguous because that calendar year overlaps two different academic years. In the meantime, after yet another gnome came through to "fix" the date error by replacing the reference date by a made-up fake date, I have replaced the template formatting by a manually-formatted citation. You know that is the likely outcome of having a template that is too strict in enforcing bogus restrictions on what can be specified, right? —David Eppstein (talk) 22:39, 21 January 2025 (UTC)
For that, at least, there is the workaround of using author= for authors who do not have first and last names as conventionally defined (assuming they have a name at all, one of the false assumptions mentioned at that essay). But the templates appear to have no workaround for dates they do not understand. —David Eppstein (talk) 23:02, 21 January 2025 (UTC)
You are welcome to attack me for trying to be helpful; I have a thick skin. I'm in the camp that thinks there will always be edge cases that citation templates can't handle without causing problems with a much larger population of template transclusions. For those edge cases, we devise workarounds or forgo using the templates. The root problem is a publisher deciding that Season (or Month)YYYY–YYYY is a good idea for a publication date; "Winter 2020–2021" is somewhat reasonable in the northern hemisphere, but any other season or month used with that formatting is just a bad idea. I understand what they were going for, but bad design is bad design, and they are forcing us to come up with a workaround. – Jonesey95 (talk) 23:15, 21 January 2025 (UTC)
It's a perfectly reasonable date for a university, in a fixed hemisphere, that starts its academic year in the middle of one calendar year and ends in the middle of the next (as many universities do) and dates its terms by seasons (because they roughly align with seasons and cover multiple months).
Some (I think mostly British) universities use dates like "Michaelmas Term 2021". Do you think we should be unable to use those as dates? What we need is not a template that actually understands all these dates, but a way to work around the restricted date formats of the template and tell it to use dates with unrestricted formats. —David Eppstein (talk) 23:36, 21 January 2025 (UTC)
I believe it's reasonable to use a date format that has some restrictions, rather than try to code for every possibility. If |date= is meant to capture the date of publication, a span such as an academic term is rarely equivalent to that, unless the source is a course module or lecture notes that accreted progressively during the term.I understand that dating issues or volumes of academic journals with a year span or season is a time-honoured tradition, but I guess I haven't seen enough course modules cited in other works to know whether or not it's common for that type of source (citing a course module in theory seems inferior to citing a textbook assigned during the course, or sources cited within the module for the bit in question, but a course module being freely available online and potentially explaining concepts better than its own sources are very valid considerations).In this particular case, according to Burtscher's CV, the course was not taught that academic term due to a covid, so using the academic term as a publication date carries its own inaccuracy anyway. She no longer teaches the course, and it's not clear when the module was made available online. As mentioned above, the preface indicates a 2020 composition.To make this all about me, my personal bugaboo in this regard is very old texts. For a lot of early texts, all we have is a terminus post quem, and it's clear that a version anyone is consulting in modern times was published much later, but |orig-date= doesn't display in the absence of |date=, and it's not always possible to determine definitively which printing of a PD-old source is the one we're reading, much less which textual witness was used as a basis for that. But I get that |date=c. 80s or 90s BCE isn't really what the parameter is for, and composing matching rules that allow for something like that but properly identify all date format errors is a non-trivial task not likely to match the slim benefits.Returning to the source at hand, I probably mentioned last week that I'd go with |date=2020|type=Course module for NWI-WB046B, Fall semester 2020/21 (the format as recorded in the source, already different to the ndash-separated full years we prefer), with the understanding it's a personal preference, and the side note that I'd replace |type= with |subtitle= if such a parameter were supported. Folly Mox (talk) 15:07, 26 January 2025 (UTC)
I could see value in having two different fields. Let's call them "display-date" and "ordinal-date". Display-date is what what the content creator put on the item. So, "Winter 2023-2024". If I had a pile of course notes and I wanted to pick out the one that was being referred to, that's what I would be looking for. Ordinal-date is an unambiguously sortable value which could be used to answer questions like "Which of these is the most recent?"
Both of these are useful. The problem is, while it's common for a single string to satisfy both use cases, that's not universal. So maybe instead of arguing about which of these we should call "The Date", we should just admit that these are indeed two different things and add another field to cover the cases where a single value can't represent them both.
Of course, it's even uglier than just professors putting semester names on course notes. If I cite something from the New York Times, I put the date that's printed on the paper. But the NYT prints several editions throughout the day (or at least they used to; I'm not really up on how they run their dead tree edition any more). I used to get the first edition of the paper when it the newsstand at about 10 PM with tomorrow's date on it. So what would make sense to put in the "date" field? The date it was actually written, printed and sold, or the date that was on the masthead? RoySmith(talk)16:26, 26 January 2025 (UTC)
Check out this 1932 paper from the March 1932 issue of The Bryologist. There's a note at the bottom of the first page "The January number of The Broyologist was published June 18, 1932". The real oddity there is not that the January issue came out in June, but that this fact was reported in the past tense three months before it happened. So you tell me what "date" really means. RoySmith(talk)16:11, 27 January 2025 (UTC)
To necro this thread pointlessly, JSTOR3239724 (from the "September" 1933 issue of The Bryologist) notes that The combined January–March–May–July number of The Bryologist was published, October 1, 1933; JSTOR3239550 (from the November issue) states The September number of The Bryologist was published November 25, 1933. Failed ambition, looks like. Kind of reminds me of doi:10.1177/0075424290023001-201 (which the publisher's website dates as "April 1990"), where the editor of the Journal of English Linguistics apologises for both the 1993 publication of the 1989 volume and the 1995 publication of the 1990 volume.Anyway it sounds like what you are proposing may already exist as |publication-date=— although I imagine this parameter is checked for malformatted dates, which now that I think about it impetussed this whole thread.It may potentially be useful to transclude the publication-date description from § Work and publisher into § Dates, where I expected so hard for it to be documented that I actually composed a sentence about its lack of documentation before thinking to use my browser's "Find in page" search function to double check myself. Folly Mox (talk) 14:01, 8 February 2025 (UTC)
"Notes, News and Comment". Journal of the New York Botanical Garden. XXIII: 7. January 1922. ISSN 0885-4165. Archived from the original on November 4, 2021. Retrieved May 23, 2021 – via Google Books.
It's deliberate that when cite journal has a volume it omits the p or pp: "XXIII: 7" not "XXIII: p. 7". This is a common style in academic publishing, and cite journals is for academic journals. Whether it's a good style for an encyclopedia that mixes those kinds of sources with magazines and newspapers (which hold onto the p) is a different question. In this case this style is especially confusing because the page number almost looks like a date number in dmy style. —David Eppstein (talk) 01:26, 21 January 2025 (UTC)
Interesting, I hadn't seen that. What I had seen was Page in the source that supports the content; displays after 'p.' and Pages in the source that support the content (not an indication of the number of pages in the source; displays after 'pp.') which are the bits of help text that show up in the visual editor template tool. I guess this comes from Template:Cite journal#Template parameters? RoySmith(talk)15:33, 21 January 2025 (UTC)
Visual Editor looks at whatever is inside <templatedata>...</templatedata> tags, and ignores everything else. Another reason why I dislike VE, and never use it. --Redrose64 🌹 (talk) 15:48, 21 January 2025 (UTC)
Thanks, that makes sense; if nobody objects, I'll remove it from the docs. I suspect it is just on the /doc page for consistency or from a copy and paste because it's present in most of the other CS1 templates. Adavidb, I don't know if you will even remember, but was there a reason to add no pp back in 2013? Rjjiii (talk) 18:51, 21 January 2025 (UTC)
@RoySmith: Because VE doesn't look outside the templatedata. There are restrictions on what we may put in the templatedata - for instance, we can't use formatting or conditional markup - therefore, a fuller description is often given in the main doc. --Redrose64 🌹 (talk) 18:37, 21 January 2025 (UTC)
I added |number=265 (an alias of |issue=) to the citation under discussion here, since volume xxiii contains multiple issues. (Also fixed the gbooks link so it points to the page supporting the claim citing it.) The archive snapshot of the gbooks search result does not verify.Given some of the content published in Journal of the New York Botanical Garden, I'm not sure {{Cite journal}} is preferable over {{Cite periodical}} (which prepends "p." to the page number), so it seems like a template type swap could potentially be appropriate if the p is desired. Folly Mox (talk) 11:55, 21 January 2025 (UTC)
That's what I was hinting at. It looks like their content became more scientific between what I saw from 1920 and what I saw from 1922. Not a nomenclatural discussion I'd be very interested in participating in. Also noting that Template:Cite journal/doc twice mentions academic and scientific papers [published / not published] in bona fide journals, without ever offering a definition of bona fide journal. This documentation might also possibly be read as discouraging use of {{cite journal}} for source types like editors' statements, obituaries, books reviewed, (sur)rejoinders, errata et corrigenda, and maybe cetera— I doubt this is the intent, but the words aren't entirely unambiguous. Folly Mox (talk) 15:59, 21 January 2025 (UTC)
Does any established citation style make this distinction (between academic and non-academic periodicals)? If so, we can just use their definition, Rjjiii (talk) 16:50, 21 January 2025 (UTC)
APA style distinguishes between "journal articles" and "magazine articles" when formatting the date element: journal articles just get the year of publication, while magazine articles get the full year, month, and day (if available). In the Publication Manual, a "journal" always hosts peer-reviewed scientific research, but some "magazines" can also host such research. They don't elaborate on the distinction in the current version of their site (nor in the Publication Manual), but the archived version of their blog suggests a dividing line based on frequency:
Some journals seem to straddle the line between journal and magazine (e.g., Nature, Science, and The Lancet contain peer-reviewed scientific research but are published weekly). Which date format should you follow for articles from these publications? The determining factor is not whether they're called "journal" or "magazine" but how often they're published. In the case of these and other weeklies, use month, day, and year.
So the overall test would be, "Does the periodical primarily contain peer-reviewed scientific research, and is it published less than once per week? If so, it's a journal. Otherwise, it's not a journal, but a magazine, newspaper, book series, etc." LegionMammal978 (talk) 23:34, 26 January 2025 (UTC)
Surely the correct overall test should be "is this specific paper a piece of peer-reviewed scientific research published as such in a periodical?". Who cares whether the same periodical also functions as a magazine for other types of article. —David Eppstein (talk) 23:52, 26 January 2025 (UTC)
I'd say it makes sense to keep consistency across articles in the same periodical. The whole purpose of the date element is to help locate the "specific paper", so it's a function of the container (the periodical) rather than its contents. And academic journals tend to place less emphasis on their exact publication date than magazines do (since the latter tend to focus more on topical information), which is why the whole distinction presumably exists in the first place. But every hard dividing line will look a bit silly in edge cases. LegionMammal978 (talk) 21:32, 7 February 2025 (UTC)
We could implement error messages for unused parameters, but I expect these are fairly unlikely to occur anyhow, so it may not be worth the effort. I'm not here to advocate for changes in {{cite encyclopedia}}'s behavior. However, I do wonder which parameter names the documentation, TemplateData, and derivative templates should be encouraging.
I maintain a number of wrapper templates for {{cite encyclopedia}}. Through the documentation and error messages of these templates, I have been encouraging editors toward |article= and |article-url= rather than |title= and |url=. I thought this might train them in better habits for using {{cite encyclopedia}} directly, and help them avoid the confusions noted above.
However, I noticed that the examples and TemplateData in the documentation for {{cite encyclopedia}} seem to lean the other direction, preferring |title= for the article name. Should I defer to that documentation, or should the documentation be changed? Daask (talk) 16:55, 3 February 2025 (UTC)
It has been noted that cite encyclopedia is a pain in the ass (q.v. for usage statistics of various parameter combinations). I personally use |entry= for the specific bit and |title= for the name of the work as a whole, but I think with current parameters it could be replaced wholesale with {{cite book}} without loss of information. Folly Mox (talk) 18:54, 3 February 2025 (UTC)
More strongly, every cite variant whose parameters are incompatible with {{citation}} is a pain in the ass. Cite encyclopedia is one of the worst in that respect, but cite conference with title= conference= is also a problem. —David Eppstein (talk) 19:00, 3 February 2025 (UTC)
I've always used |encyclopedia= for the publication and |title= for the article, which seems the obvious way (similar for {{Cite dictionary}} and {{Cite conference}}), though I suppose |entry= or |article= might be better. Is this wrong? If not, could the documentation be improved? Without any deep thought, I use the article URL if available, else the publication URL. I don't know how these things affect statistics, but they seem obvious. Best wishes, Pol098 (talk) 15:35, 4 February 2025 (UTC)
In the course of fixing some bugs in Trappist the monk's queries on that page, I discovered that the majority of the ~150 uses |title-link= in {{cite encyclopedia}} either do not display at all or link the wrong part of the citation. Some of these were on highly trafficked pages, eg. [7][8][9][10] I'll follow up more after working on some queries... Daask (talk) 19:02, 4 February 2025 (UTC)
This is one of those intractable problems, because everyone has personal preferences, what parameters to use what they mean. To fix it, all hell breaks loose. To get consensus, impossible. Since we have no management who decides for us, it never gets fixed. It's a weakness of an open model of development. One suggestion: create a new cite encyclopedia template under a different name. The fork is well designed and thought out and addresses all the current problems. Begin migrating existing instances over. Eventually the old one goes to TfD for lack of usage, and rename the fork to cite encyclopedia .. this process could be done by a single person, and frankly I doubt anyone would complain, if done well. Just make sure the new design is good. -- GreenC20:43, 4 February 2025 (UTC)
Perhaps an easier first step is to change {{cite dictionary}} from the redirect to {{cite encyclopedia}} to a stand-alone cs1 template. In this new {{cite dictionary}} template, |entry= would identify the thing in the dictionary that is being referenced – for me, |title= doesn't seem to fit there. |title= holds the name of the dictionary. We could, though I'd rather not, create special case aliasing of |dictionary= ↔ |title=; special case code should be avoided if at all possible.
Once {{cite dictionary}} is separated from {{cite encyclopedia}} we might then consider switching to the preferred form (apparently 'encyclopedia title' → |encyclopedia= and 'article/entry title' → |title= – discussion might determine another preference). A bot or awb task could be run against articles using {{cite encyclopedia}} to switch them to the preferred format. When the bot is done, we modify the module to support only the preferred parameter combination.
One of the things I really like about |entry=|title= is that I can use |title-link= for an independently notable encyclopaedia / dictionary instead of double square bracketing its name (the other thing I really like is not having to type "encyclopedia").Any attempt to clean up {{cite encyclopedia}} (218282 transclusions) may be able to be started with bot runs for common sources, but there are going to be a vast number of edge cases, many / mainly due to User:Citation bot unnecessarily and without supervision altering {{cite web}} and {{cite book}} to {{cite encyclopedia}} because a parameter matches the string [Ee]ncyclopa?edia. Folly Mox (talk) 14:38, 8 February 2025 (UTC)
You would rather write:
{{cite encyclopedia|entry=Entry |title=Encyclopædia Britannica |title-link=Encyclopædia Britannica}} → "Entry". Encyclopædia Britannica.
Of course, some sort of automated process would be needed to normalize existing {{cite encyclopedia}} templates. How many is a vast number of edge cases? Examples? If some number of those templates ought not be {{cite encyclopedia}}, what kind of damage do you fear will come from normalizing those templates?
Oh right I forgot about this! I was under the impression that |title-link= is always superior to double square brackets, basically due to the existence of the parameter (and |author1-link= etc).As to converting the existing {{cite encyclopedia}} to a new one, upon reflection automatic conversion can't make the existing transclusions worse, so I suppose there's no danger there.For examples, I don't have diffs or time to dig them up, but I've seen Citation bot change {{cite book}} to {{cite encyclopedia}} a few times for single-author, zero-editor books with Encyclopedia in the title. It's also changed a reference of mine to an academic's contributor profile at Britannica from {{cite web}}, byt this is probably an uncommon type of source.No idea on the scope of this not-quite-problem: Citation bot regularly makes hundreds of edits per hour, so there's no way to keep track.Anyway, retracting my warning or whatever it was supposed to be. I do like the idea of a rebuilt template; should have left it at that. Folly Mox (talk) 19:00, 10 February 2025 (UTC)
Use of via in cite web for archiving sites
If a page is archived on archive.org so that there is an archive-url, archive-date, etc. should via be set to archive.org or not used?Naraht (talk) 16:02, 4 February 2025 (UTC)
|via= was designed for a special use case. Let's say you found an article on Yahoo! News that was originally published in Wired. You would cite the |work= as Wired and |via= the Yahoo News. Assuming you were unable to change the URL directly to Wired, which is often the case. -- GreenC20:27, 4 February 2025 (UTC)
Or the other use case is that you found an article in a print newspaper on Newspapers.com, Google News or another similar site. Like the Wired example given above, you're actually citing the original newspaper, but there is a desire to give some acknowledgement that the content was republished elsewhere per WP:SAYWHEREYOUGOTIT. Thus, I would say that I cited an article from The Grand Rapids Press via Newpapers.com. Ditto citing the scanned copy of a book from Google Books, I'd be citing the original book via Google Books. Imzadi 1979→18:40, 8 February 2025 (UTC)
Consider the article "Striving for Imperfection", linked from Collodion process, which is hosted on Adobe Express, but was released as part of the Fall 2022 issue of Aurora, an alumni magazine for the University of Alaska Fairbanks. Who is the proper |publisher= of this magazine article? Adobe or the University of Alaska Fairbanks?
(Also, the article's headline is actually capitalized in sentence case as "Striving for imperfection". Should the title be written in sentence case or title case? Help:CS1#Titles and chapters calls for consistently using one or the other in an article, but it basically seems to be a dead letter, since in practice, everyone uses the casing scheme pulled from each source's headline, creating a mixture of both.) LegionMammal978 (talk) 18:28, 9 February 2025 (UTC)
You can include |publisher= if you want but that is usually omitted from periodical citations. Writing it as I did puts the article in context and eliminates the need to worry about Adobe's hosting service.
True, that's a sensible way to do it for periodicals. But do you have any thoughts about the title-casing question? The CS1 page seems to pretty clearly recommend that title casing be normalized, but trying to enforce that (even on a single page as it gets edited by others) would be like boiling the ocean. LegionMammal978 (talk) 20:37, 9 February 2025 (UTC)
I'm more-or-less indifferent to casing so long as it isn't ALL-CAPS-ALL-THE-TIME. It would seem that you can't go wrong matching the dominant style in the article. No dominant style? Discuss at the article talk page.
I have a design principal that if you want to convince people to do something, one of the best ways is to provide tools that make it easy. In this case, updating the source (wikitext) and visual editors to have a case change menu that included
I'm aware of those deficiencies, but only now I searched WP:USL and found User:ZKang123/TitleCaseConverter. With only a few dozen users, that script is not widely known and seems to have some problems and only seems (I havn't installed it) to cover one of the items you mention (though I don't understand what "Camel case" is supposed to do or how "Flip case" may be useful). YMMV. -- Michael Bednarek (talk) 01:28, 11 February 2025 (UTC)
Camel case is a convention for variable names that is probably too much to expect from a simple tool.
The flip-case option is useful for people who sometimes don't notice or recall that Caps Lock is on. It would be useful for correcting the resulting typos.
It would be very helpful if {{cite journal}} and {{citation}} would properly support citations of book reviews, which typically have no independent title (e.g. JSTOR sometimes lists "Review: [Untitled]" as the title). From my understanding the current template best practice is something like:
{{cite journal|last=Bremner |first=Andrew
|title=Review of ''The Book of Numbers'', by John Horton Conway and Richard K. Guy
|journal=The American Mathematical Monthly
|volume=104 |number=9 |year=1997 |pages=884–888 |jstor=2975310}}
Bremner, Andrew (1997). "Review of The Book of Numbers, by John Horton Conway and Richard K. Guy". The American Mathematical Monthly. 104 (9): 884–888. JSTOR2975310.
Or:
{{cite journal|last=Bremner |first=Andrew |type=Book review
|title=''The Book of Numbers''. By John Horton Conway and Richard K. Guy.
|journal=The American Mathematical Monthly
|volume=104 |number=9 |year=1997 |pages=884–888 |jstor=2975310 }}
Bremner, Andrew (1997). "The Book of Numbers, by John Horton Conway and Richard K. Guy". The American Mathematical Monthly (Book review). 104 (9): 884–888. JSTOR2975310.
Or:
{{cite journal|last=Bremner |first=Andrew |department=Book Reviews
|title=''The Book of Numbers'', by John Horton Conway and Richard K. Guy
|journal=The American Mathematical Monthly
|volume=104 |number=9 |year=1997 |pages=884–888 |jstor=2975310 }}
Bremner, Andrew (1997). "The Book of Numbers, by John Horton Conway and Richard K. Guy". Book Reviews. The American Mathematical Monthly. 104 (9): 884–888. JSTOR2975310.
But frankly none of these is good; they are misleading to readers and confusing for editors. The quotation marks are outright incorrect, and we should put some word like "review" at the front, before the title/author of the book. Additionally, sometimes book reviews do have an independent title, but it is still desirable to include information about the title/authors of the books under review. It would be better to have input along the lines of:
{{cite journal|last=Bremner |first=Andrew
|reviewed-works=''The Book of Numbers'', by John Horton Conway and Richard K. Guy
|journal=The American Mathematical Monthly
|volume=104 |number=9 |year=1997 |pages=884–888 |jstor=2975310 }}
which could output as
Bremner, Andrew (1997). Review of The Book of Numbers, by John Horton Conway and Richard K. Guy. The American Mathematical Monthly. 104 (9): 884–888. JSTOR2975310.
or maybe
Bremner, Andrew (1997). Book review: The Book of Numbers, by John Horton Conway and Richard K. Guy. The American Mathematical Monthly. 104 (9): 884–888. JSTOR2975310.
without the quotation marks.
Edit (11 Feb): When there is also a title, it could look something like:
{{cite journal|last=Brown |first=Ezra
|title=A New Testament for the Book of Numbers
|reviewed-works=''The Book of Numbers'', by John Horton Conway and Richard K. Guy
|journal=The American Mathematical Monthly
|volume=17 |number=1 |year=2009 |page=29 |jstor=25678832 }}
Brown, Ezra (2009). "A New Testament for the Book of Numbers". Review of The Book of Numbers, by John Horton Conway and Richard K. Guy. Math Horizons. 17 (1): 29. JSTOR25678832.
Jstor lacking correct titles for book reviews shouldn't really concern us. It would be nice to have a standardised presentation, but personally I'd prefer implementation by a wrapper template like {{cite book review}} instead of introducing a new parameter and new formatting to an existing template.Some journals customarily include bibliographic details in their review titles like page count, binding, and price. Do you feel like those are appropriate for us to include in the title when citing such a review? Folly Mox (talk) 12:54, 11 February 2025 (UTC)
What JSTOR does is irrelevant to us, it's just an example of how these are considered to not have "titles" per se. Personally I leave off year, publisher, city, page count, etc. when citing a book review. –jacobolus(t)13:08, 11 February 2025 (UTC)
Yes, I support the {{cite review}} idea as it could be used for reviews of exhibitions, films, records, concerts etc etc. Hence "Book review: ...", "Film review: ..." etc. I'm less sure about leaving off the publisher, as it gives a degree of credibility to the reviewer. 𝕁𝕄𝔽 (talk) 15:07, 11 February 2025 (UTC)
I meant leaving off extra book metadata besides author/title that might be written at the top of the review, not leaving off the publisher (newspaper, scholarly journal, ...) of the review itself. –jacobolus(t)17:23, 11 February 2025 (UTC)
{{cite report|type=none seems to already be very close to what people are looking for. Example from below with or without brackets:
Bremner, Andrew (1997). [The Book of Numbers, by John Horton Conway and Richard K. Guy]. The American Mathematical Monthly. Vol. 104. pp. 884–888. JSTOR2975310.
Bremner, Andrew (1997). The Book of Numbers, by John Horton Conway and Richard K. Guy. The American Mathematical Monthly. Vol. 104. pp. 884–888. JSTOR2975310.
Also, the |title=none solution would probably work a lot better if the maintenance message didn't encourage editors to add a fake title. Rjjiii (talk) 18:38, 11 February 2025 (UTC)
{{Cite report}} is supposed to be for standalone documents that aren't books, e.g. published by a government or company, not for entries published in a periodical. Using it for reviews seems like misuse, and will likely lead to confused editors changing the citation later, because "hey this isn't a report". (For no obvious reason if the report is sufficiently "technical" there's {{cite tech report}} instead, which is the same thing except with "type=Technical report" as a default instead of "type=Report". Hooray for the copious abundance of trivially different CS1 templates.) –jacobolus(t)18:49, 11 February 2025 (UTC)
@Jacobolus, I'm not saying to use that in an article, but commenting how simple a wrapper template could be. If the discussion below results in hiding the maintenance messages, that is probably a good enough solution for nearly all cases, Rjjiii (talk) 18:54, 11 February 2025 (UTC)
If you let citation bot fill the template, you get
Bremner, Andrew (1997). "Reviewed work: The Book of Numbers, John Horton Conway, Richard K. Guy". The American Mathematical Monthly. 104 (9): 884–888. doi:10.2307/2975310. JSTOR2975310.
This is a perfectly acceptable and accurate result. "Review: [Untitled]" is a red herring/garbage output by jstor, which should just be ignored. There is no need for a {{cite review}}. See also [11]. Headbomb {t · c · p · b}16:25, 11 February 2025 (UTC)
It's a confusing and inaccurate result, bad for both editors and authors, since the part listed as a title is not a title. The quotation marks are inappropriate and the book title should be italicized. (And as a nit, "Reviewed work" is worse than either "Review" or "Book review" up front.) It would probably be preferable to just use plain mediawiki markup in {{wikicite}} if this is the best the templates can do. –jacobolus(t)16:46, 11 February 2025 (UTC)
What we have here is a non-title misleadingly presented as a title, something basically nobody ever does when citing book reviews anywhere other than Wikipedia. E.g. the MLA Handbook recommends the format: Reviewer-Last, First. Review of Title, by Author Name. Publisher. Date. –jacobolus(t)16:55, 11 February 2025 (UTC)
When I wrote the article on The Book of Numbers, I deliberately used title=none for all the reviews that didn't have an explicit title. Most were "Review: [Untitled]" at JSTOR and were printed under headings that had the book's title, the authors, the publisher, the year of publication, the number of pages, and/or the list price — not real titles. The example given above is actually the cleaned-up version of the full heading: The Book of Numbers. By John Horton Conway and Richard K. Guy. Springer-Verlag, 1996, 320, $29.95. The only exception was Ezra Brown's "A New Testament for the Book of Numbers", a retrospective written over a decade after the original publication. I've done it the same way on the handful of book articles I've started and across various academic biographies where the notability rested on WP:AUTHOR, meaning the references included multiple reviews for each of multiple books. I think I picked up this style from David Eppstein. Filling up the title field just makes for repetitive clutter. I don't think making up a non-title for a bibliography is the right way to go. Making up text for our own benefit and passing it off as someone else's choice rubs me the wrong way. If we're willing to trim the list price and such from the heading and not use that in our title field, and everything else in the title field is just repeating things the reader already knows because they're looking at an article about the book or a list in a bio that says "Reviews of this book include the following", what's the point of the title field at all? XOR'easter (talk) 18:05, 11 February 2025 (UTC)
I also generally use title=none when possible. It is certainly a better choice than the made-up titles you sometimes get from publisher data like "Siobhan Roberts.King of Infinite Space: Donald Coxeter, the Man Who Saved Geometry. xv + 399 pp., illus., figs., apps., bibl., index. New York: Walker & Company, 2006. $27.95 (cloth)." (this one is from doi:10.1086/529335, as obtained by curl -LH "Accept: application/x-bibtex" http://dx.doi.org/10.1086/529335). —David Eppstein (talk) 18:14, 11 February 2025 (UTC)
title=none would be great, except it throws a CS1 maintenance message up and there are some editors who insist on "fixing" those whenever they appear. I agree that in an article specifically about a book we don't really need redundant «Review of X Book by Y Author» added to every review citation. But in other types of articles it would be nice to include that information without making it appear like a title. –jacobolus(t)18:23, 11 February 2025 (UTC)
title=none is indeed a solution, but it's particular good in a list of such review, e.g.
How several common citation styles handle book reviews:
APA
Author of Review's Last Name, First Initial. (Year of Publication). [Review of the book Title of Book: Subtitle if Any, by Book Author's First Initial. Second Initial if Given Last Name]. Name of Journal, Volume Number(Issue Number), first page number-last page number. https://doi number if given[12]
Chicago
Reviewer's First Name Last Name, "Title of Review [if any]," review of Title of Book: Subtitle if Any, by Book Author/Editor's First Name Last Name, Name of Journal in which review appears Volume Number, no. Issue Number (Date of Publication): Page Number of Exact Citation, https://doi.org/DOI Number or Name of Database.[13]
MLA
Author's Last Name, First Name. Review of Title of Book: Subtitle if Any, by Book Author's First Name Last Name. Name of Journal, vol. Volume Number, no. Issue Number, Date of Publication, pp. First Page Number-Last Page Number. Name of Database. https://doi.org/DOI Number if Given.[14]
Not done: This is definitely not the right page to make whatever request this is you are making. PianoDan (talk) 18:00, 26 November 2024 (UTC)
, doi:10.4171/JEMS/900, MR3994103
Facepalm . I didn't even think of looking at that. Thank you! GoingBatty (talk) 20:10, 2 February 2025 (UTC)
You must be logged in to post a comment.