To help centralize discussions and keep related topics together, the talk pages for all Citation Style 1 and Citation Style 2 templates and modules redirect here. A list of those talk pages and their historical archives can be found here.
This help page does not require a rating on Wikipedia's content assessment scale. It is of interest to multiple WikiProjects.
This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.Wikipedia HelpWikipedia:Help ProjectTemplate:Wikipedia Help ProjectHelp
This page is within the scope of WikiProject Academic Journals, a collaborative effort to improve the coverage of Academic Journals on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Academic JournalsWikipedia:WikiProject Academic JournalsTemplate:WikiProject Academic JournalsAcademic Journal
This page is within the scope of WikiProject Magazines, a collaborative effort to improve the coverage of magazines on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.MagazinesWikipedia:WikiProject MagazinesTemplate:WikiProject Magazinesmagazine
Module:Citation/CS1/Configuration needs the 10.xxxx/... part of the DOI associated with the publisher. All the publications of the publisher must be free-to read. Once that is done, the xxxx part can be added to the list under local function build_free_doi_registrants_table(). Also leave a note at User talk:Citation bot.
Module:Citation/CS1/Configuration needs the 10.xxxx/yyyy part of the DOI associated with the journal. All the articles associated with that DOI pattern must be free-to read. Once that is done, the xxxx/yyyy parts can be added to the list under local extended_registrants_t = { with the format ['XXXX'] = {'YYYY'},. If there are multiple journals with the same DOI prefix, they can be grouped together with the format ['XXXX'] = {'YYYY', 'ZZZZ', '...'},. Also leave a note at User talk:Citation bot.
I would like to add a geo-dead/geo-access URL keyword
Previous discussions have come to the conclusion that this is not workable. Websites change which regions can access them regularly, and these websites are regardless not fundamentally dead.
I would like support for PDF page numbers
The specific page of a specific PDF may change between clients with the same file or files with the same client. Consider using a |chapter= or |quote= instead.
I would like my change done now
Local consensus is that these modules sync from their sandboxes approximately once every 3-6 months. This is due to complexity of changes, the number of transclusions these modules have, and to be sure sufficient consensus exists for a change.
I don't like (identifier) in the links to identifier pages
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)[reply]
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)[reply]
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)[reply]
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)[reply]
There are a number of links to books which have since lost their accessibility to the general public on Internet Archive (e.g., [1] and [2] of the same book). These are now "[books] available [only] to patrons with print disabilities."
Should the links like these which are not accessible to users without print disabilities be removed, or would it be possible to add another |url-access parameter to signify this? Tule-hog (talk) 20:48, 28 November 2024 (UTC)[reply]
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)[reply]
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)[reply]
{{cite journal|date=2016|doi=10.70460/jpa.v7i1.183|first=Ian J|issue=1|journal=Journal of Pacific Archaeology|last=McNiven|pages=74–83|title=Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea|volume=7}}
Live
McNiven, Ian J (2016). "Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea". Journal of Pacific Archaeology. 7 (1): 74–83. doi:10.70460/jpa.v7i1.183. {{cite journal}}: Check |doi= value (help)
Sandbox
McNiven, Ian J (2016). "Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea". Journal of Pacific Archaeology. 7 (1): 74–83. doi:10.70460/jpa.v7i1.183.
This edit request to Template:Cite web has been answered. Set the |answered= or |ans= parameter to no to reactivate your request.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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:
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)[reply]
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)[reply]
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)[reply]
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)[reply]
>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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
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)[reply]
{{cite book|title=Title |last=Greene |first=EB |date=15 December 2024}} → Greene, EB (15 December 2024). Title.
'"`UNIQ--templatestyles-00000065-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"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.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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}}
