Help talk:Citation Style 1/Archive 45

New parameter: af
Similar to df, it would be immensely useful to have a af, covering author format. Right now we have name-list-format (which accepts ), but that's just awful to remember.

You could have

Those would kick in for authors/editors and format them in the specified manner, e.g.


 * Dickinson Emily Fitzgerald Francis Scott Key Last, F.M. → Dickinson, E.; Fitzgerald, F.S.K.
 * Dickinson Emily Fitzgerald Francis Scott Key Last, FM → Dickinson, E; Fitzgerald, FSK
 * Dickinson Emily Fitzgerald Francis Scott Key F. M. Last → E. Dickinson; F. S. K. Fitzgerald
 * Dickinson Emily Fitzgerald Francis Scott Key Vanc → Dickinson E, Fitzgerald FS

and throw in error messages when the conversion to the specified format couldn't work.
 * Emily Dickinson Fitzgerald Francis Scott Key F. M. Last → Emily Dickinson; F. S. K. Fitzgerald ( Error: F. M. Last requires lastn/firstn to be used consistently, convert author1 to last1/first1. )

or have other issues
 * Dickinson E., Fitzgerald F. S.K. af → Dickinson, E.; F. S.K. Fitzgerald ( Error: first2 has spacing issues )
 * Languillat J. -C → Languillat, J. -C ( Error: J. -C is mis-abbreviated. )
 * Howard J. B.C → Languillat, J. B.C ( Error: J. B.C is mis-abbreviated. )

And then we could deprecate the god-awful name-list-format. Headbomb {t · c · p · b} 14:30, 5 July 2018 (UTC)
 * A more flexible solution would be a new parameter, ao, or the long version, author-order, with the allowable values being
 * lf
 * Last name first, last name separated from first name by a comma
 * ff
 * First name first
 * lnf
 * Last normally first. The author comes from a culture where the family name is normally written first, so no comma is added between the family name and the rest of the name.
 * Jc3s5h (talk) 15:53, 5 July 2018 (UTC)
 * The cultural name order, if we need it at all, should be on individual authors not the whole author list. —David Eppstein (talk) 16:06, 5 July 2018 (UTC)
 * lf/ff and the like are partial solutions at best, and will still produce inconsistent abbreviations. However, I've updated the proposal to include 'cultural' names and use codes to simplify. If something needs to be bypassed for some reason you could have AF1 to display Liu Jianguo one as the Chinese order Liu Jianguo, rather than Western order Jianguo Liu. Headbomb {t · c · p · b} 16:31, 5 July 2018 (UTC)
 * The only real reason we have df is because Citoid, and its engineers, didn't want to fight with date formatting. I would oppose a spread of "X-format" parameters, since no need has been demonstrated here and adds a significant deviation in formatting. (We have the Vancouver formatting to draw Vancouverites trivially into the fold from using authors, so I don't see an analog there, either.) --Izno (talk) 17:18, 5 July 2018 (UTC)
 * Here's a typical case where this would be useful. CitationBot adds authors (or the WP:REFTOOLBAR), then editors need to clean them up to bring them in line with the style used. That means hunting down every first# manually, and then manually editing everything to use initials, as well as converting author to last/first in the proper format. This also reduces the value of metadata a bit. Applying LF4 to all citations would be so much easier and quicker to bring everything in a consistent format, find errors, and future proof the article's existing citation. User:Citation Bot could then see that LF4 is used in the article, and whenever it adds citations, it could then use LF4 too. (Likewise for Citoid.) Headbomb {t · c · p · b} 18:07, 5 July 2018 (UTC)
 * You're arguing that a barely-maintained-as-it-is bot could use this? Forgive me if I might be a bit skeptical of that suggested use. :) --Izno (talk) 19:29, 5 July 2018 (UTC)
 * Citation Bot has resumed a normal maintenance cycle for a few while now. Same idea for the WP:REFTOOLBAR and WP:CITOID in general. Either way, even if the bot doesn't use it, adding LF4 (or whichever style) afterwards make cleanup a million times quicker. Headbomb {t · c · p · b} 20:23, 5 July 2018 (UTC)
 * A maintenance cycle. Not a new-features cycle (this is a new feature). (You'll note that the talk page there says exactly this.) And as for the maintenance, the code developed 6 months ago still has yet to be deployed. Making Citoid aware of the rest of the text on the page isn't in its scope. Nor is reftoolbar's. It might be reasonable to have a use author citation style and have a script to enforce that, but your point wasn't about that. ;) --Izno (talk) 16:21, 8 July 2018 (UTC)
 * Why should citoid or the ref toolbar not be updated to make use of the new features? Headbomb {t · c · p · b} 16:39, 8 July 2018 (UTC)
 * An interesting idea. Supporting all of these variants may result in excessively complex template code and may confuse editors. However I think CS1 or LF4 would be useful to render vauthors in standard CS1 author format in cases where CS1 is the predominate/first established style. Boghog (talk) 19:45, 5 July 2018 (UTC)
 * Per my thread above this one, I support a simple way to turn on Vancouver formatting without losing underlying data, so we can deprecate (and eventually convert then disable) vauthors. However, we don't need this many citation formats.  We should be moving toward consistency, not chaos.  No one would remember that table of codes, nor use them consistently.  We shouldn't have a name output formatting option that isn't either CS1/CS2 as defaults, depending on the template used, or output that is required (not just optional) by a particular major off-site citation style – one that can be reliably sourced in detail and as in current use, e.g. listed in Turabian, or as the mandatory style of some major journal publisher, or otherwise neither WP:NFT nor obsolete.  That is, if the citation style permits either "Chung, Margaret T." or "Chung, M. T." then we need no option to truncate to the latter (unless that abbreviated form is a hard requirement in some other cite style ).  We have no editorial or reader interest in truncating the name data if not forced to do so.  We likewise have no reason for any MOS:INITIALS-defying formats (without the dots and/or spaces), absent a hard requirement like Vancouver's "Chung MT".  — SMcCandlish ☏ ¢ 😼  22:10, 5 July 2018 (UTC)
 * I'm not saying all the above absolutely need to be supported natively, but all those styles are used somewhere and we could support them per WP:CITEVAR. The cost of not supporting them will be: they'll still be used, you still won't be able to change them per WP:CITEVAR, and you won't be able to get the full benefits of error checking / metadata that comes with supporting them. Headbomb {t · c · p · b} 22:24, 5 July 2018 (UTC)
 * Re "you still won't be able to change them per WP:CITEVAR": bullshit. CITEVAR says only to first seek consensus. It doesn't even require consensus, only to first seek it. Having af is a good idea, but invoking CITEVAR drama to argue a piddling detail is not helpful. &diams; J. Johnson (JJ) (talk) 19:44, 8 July 2018 (UTC)
 * I meant on a mass scale, not individual articles. Headbomb {t · c · p · b} 19:59, 8 July 2018 (UTC)
 * There are a variety of reason why some editors support CITEVAR, one of those reasons is that if you're familiar with a particular citation style, such as APA, it's easier to type it than to type a template. It also makes the wikitext shorter, and thus easier to edit. I don't know anything about Vancouver, but for most of the time that citation templates have existed, they did not produce the same appearance as any external style guide. Thus, the question of whether it would be acceptable to change an article that didn't use citation templates and consistently followed an external style to templates that produced the same appearance never arose. It isn't at all clear that such a switch would be accepted. Jc3s5h (talk) 23:07, 5 July 2018 (UTC)
 * Well, you can still do it all by hand manually if you want. But that means lots of manual cleanup after bots whenever someone adds something. Headbomb {t · c · p · b} 00:44, 6 July 2018 (UTC)

Refined proposal
I took the feedback from above, and refined the proposal. I've separated the outputs into those that are MOS:INITIALS-compliant and those that aren't, and got rid of the obscure 'codes' in favor of obvious things people don't need to remember or look up. The ideal solution (maybe this would be possible with WP:TemplateStyles) would be to declare one what the author format is once (e.g. ), and have citations inherit the style from there, but failing that a (non-mandatory, of course) af in the citation themselves would allow to have much of the same effect. Headbomb {t · c · p · b} 00:49, 6 July 2018 (UTC)
 * I hope that this is not done. It would considerably complicate the templates, for no gain in expressiveness.  It would also give people a whole new set of knobs to fiddle with and argue over.  Kanguole 22:41, 7 July 2018 (UTC)
 * Not really no. The current situation is a huge mess which is incredibly hard to cleanup. In the same article you'll have a mix of Smith/J.F., John Smith, Smith/JF and Smith/John. Often in the same citation. This isn't a proposal to deploy those by bots, but to allow humans to more easily standardize citation articles and clean them up when they need to be, and help bots respect an existing style. Headbomb {t · c · p · b} 22:51, 7 July 2018 (UTC)
 * For example, compare Special:Permalink/842230702 with Sex_manual. This is the diff required to make that happen, and involves reviewing every citation. Now if someone uses the ref toolbar to add, you'll have , which again breaks the style, and needs a cleanup edit. This could be made much, much easier by simply adding Last, F. M., rather than changing  to   manually. Headbomb {t · c · p · b} 23:17, 7 July 2018 (UTC)
 * If this can be mostly automated, but a human needs to decide which correction to apply to which citation, maybe someone could write some sort of script or app where the wikitext is parsed, the correction possibilities put next to each citation, and the editor checks which correction to apply to each citation. Then a new version of the wikitext, compatible with the existing citation module, is saved. Jc3s5h (talk) 23:06, 7 July 2018 (UTC)
 * I think we should not provide more options for last/first ordering. Having the name of the lead author in "last-first" order is pretty much the standard for lexicographical ordering; the variance among styles has been whether coauthors should be first-last or last-first (inverted). In that we have a predominant "last-first" style we should lean towards having that a consistent standard.
 * To the argument that providing a "first-last" option will encourage some number of (probably extremely few) editors to use templates: I think it is more likely to enable expanded use of "first-last" ordering, and make citations less consistent. Other options are available to persuade (or simply coerce) use of templates; this option would create other problems.
 * On the otherhand, dealing with initialization would, indeed, be immensely useful. Inconsistent use (within an article) of first names versus initials only is annoying. But while I favor having first names, on some topics I have so many sources (usually journals) that supply only initials that the work digging out complete names dissuades me from providing first names even where I do have them. With something like initials I could supply what I have, and the article could be consistent using just initials.
 * Anyway, supplying a pattern is too complex. Let the parameter values (options) be:
 * default: firstX displayed as specified (first name, middle initials, "Jr.", etc.).
 * initials: initial (with period) of first name, with middle initials.
 * vanc: displayed in Vancouver style.
 * bluebook (or caps): last name in small-caps.
 * With due respect to AMA style, I think we should consistently use a comma following the surname. That is an aid to the reader in showing that the ordinary (in English) first-last order has been inverted, and also distinguishes compound surnames. &diams; J. Johnson (JJ) (talk) 19:51, 8 July 2018 (UTC)
 * Regarding initials, it is indeed untidy to have full names for some authors and only initials for others, and, as you say, sometimes that's all that is available. But tidying that up by uniformly displaying only initials would be hiding information that could be useful to readers.  Kanguole 09:29, 9 July 2018 (UTC)
 * The underlying question is: how important is consistency in using initials (in lieu of first names) or not? If consistency is important, then is it better to merely "hide" (not display) information? Or not include it at all? Having this option means that consistency can be readily arranged if someone insists on it, without real loss of information. Which the s/w can still access, and allows incremental augmentation. &diams; J. Johnson (JJ) (talk) 21:56, 9 July 2018 (UTC)
 * The point is to accommodate all the valid styles (or at least the MOS-compliant ones), and help achieve those consistently, not to force an artificial preference for one style over the other. We should not force people to use full first names when they don't want to. If you want to supply them, that's allowed. If you want to initialize, that's allowed too. No one needs full names to find a citation, unless the information provided is grossly incomplete. Headbomb {t · c · p · b} 13:46, 9 July 2018 (UTC)
 * A reader might well be interested in knowing which "A. Jones" is being cited as an authority for a particular statement. If the full name is already in the wikisource, it is unhelpful to hide it.  Kanguole 14:21, 9 July 2018 (UTC)
 * That's a matter for prose, distinct from referencing matters. Again, "Jones, Alphonso" is allowed in references but so is "Jones, A." and if that's the style the article uses, there is no reason not to support it, and WP:CITEVAR applies. Headbomb {t · c · p · b} 16:25, 9 July 2018 (UTC)
 * added a "MOS style". Headbomb {t · c · p · b} 17:48, 9 July 2018 (UTC)

Further refined proposal
I took the feedback from both sections above, and I realize this was turning into something way more complicated than it needed to be. So instead, I've refocused this into something more straightforward, focusing on flagging downright errors at 99% case use, rather than minor style variations (but still allowing them).


 * The default case (af left empty) would simply verify that last#/first#/author# are not wrong. It would report a variety of issues like bad hyphenation (J.- H., bad abbreviations (J. H, bad capitalizations J. h., or bad punctuation (John,. No error messages are thrown if you have a mixture of "Smith, John H." and "Jones, A. F.".
 * Using a specific order (First Last simply displays the first/last names in that order, checks that the parameters themselves are not wrong, and makes sures that last#/first# is not mixed with author#. This can be overridden by ignore so single names / corporate names can still be used.
 * For the MOS:INITIALS-centric, MOS would ensure that initials, if used, would be in the MOS-format. This can help catch inconsistent abbreviations, when used (e.g. J.H. + A F), but does not force abbreviations to be used.
 * For those with a specific abbreviation style in mind, they can use Last, F. M. or F.M. Last or whatever to present things in that specific format. If F.M. Last is used, both Smith John H. / Smith J. H. are presented as J.H. Smith. Errors are only reported when the parameters themselves are wrong or the output cannot be presented in the specified format.

Headbomb {t · c · p · b} 19:17, 9 July 2018 (UTC)


 * Headbomb {t · c · p · b} 19:30, 9 July 2018 (UTC)
 * When you say "report a variety of issues" do you mean that the template would not properly function for names with those issues, or merely that the article would be thrown into a maintenance category? Not working for single-letter-but-unpunctuated names would be bad for people like U Thant. —David Eppstein (talk) 20:19, 9 July 2018 (UTC)
 * Or J Harlan Bretz. &diams; J. Johnson (JJ) (talk) 22:00, 9 July 2018 (UTC)
 * I mean that the template would keep displayed things as best it could and throw error messages when things were wrong or couldn't display them in the specified format. For single name authors like Thant, Thant is all that's needed (or possibly U Thant if the honorific is needed, although we don't usually include those). But let's say there's someone out there with the first name O and a last name of Johnson, well there's nothing wrong with Johnson O, so there wouldn't be any errors shown there. You would get an error if you specified MOS, but it's something you could overide with ignore. Headbomb {t · c · p · b} 20:36, 9 July 2018 (UTC)
 * This seems over-complicated (and don't forget cases like Jennifer 8. Lee). For one thing MOS should be a default not an option; MoS applies to citation material except when a citation style  (not just optionally permits) a variance from it, and that citation style is used consistently in the article (and even then we might have a consensus discussion to change it).  Second, we don't need to throw errors for trivial problems, except maybe in preview mode. Better to have a cleanup category and may be WP:GENFIXES deal with it.  — SMcCandlish ☏ ¢ 😼  22:05, 9 July 2018 (UTC)
 * MOS being the default would lead to hundreds of thousands of errors for perfectly valid styles. So no, we can't make that default. And cases like Jennifer 8. Lee are not forgotten, that's what ignore is for. Headbomb {t · c · p · b} 22:08, 9 July 2018 (UTC)
 * Which brings me right back to "This seems over-complicated". I.e., I don't think anyone's going want to try to learn and remember all this stuff. The more complications we add to cite templates the more we drive people away from them. This is one of the reasons I started thread above this one; vauthors is an unnecessary divergence from how to enter author data, so it needs to go away (even aside from metadata loss problem).  — SMcCandlish ☏ ¢ 😼  06:41, 16 July 2018 (UTC)
 * As I said above: I think we should not provide more options for last/first ordering (or what it boils down to: inverting, or not, co-author names). As an inducement for using templates it is very slight, and likely quite unnecessary, and it opens a prospect of greater inconsistency.
 * As a general rule: option codes in the nature of patterns would be too complicated, and way too intimidating for most editors. Also, "FirstLast" would be better than "First Last" (because the included space makes it look like two values). But like I said, name order should not be a formatting option. &diams; J. Johnson (JJ) (talk) 22:03, 9 July 2018 (UTC)
 * "Option codes in the nature of patterns would be too complicated, and way too intimidating" quite the opposite. They make it crystal clear what the pattern is, and are completely optional. Don't what to deal with them? Don't use them. They won't be used in the majority of cases but will make gnome life much, much easier. Headbomb {t · c · p · b} 22:13, 9 July 2018 (UTC)
 * Some of the resistance to citation templates is based on a perception of complexity, which this proposal would exacerbate.
 * Not using these features would not avoid their costs. Editors need to read wikitext added by others.  Watchlists will be full of fiddling with these display parameters, and talk pages full of arguments about the best settings for them, all irrelevant to content.  Kanguole 22:39, 9 July 2018 (UTC)
 * I tend to agree with Kanguola that the templates are already too confusing to use manually (and if you can't use the templates without having additional software to help, something is wrong). The cryptic abbreviated parameter names do not help. But, taking a step back to look at the bigger picture: we already have too much variation in allowed reference formatting. We should be working to reduce that variation. Instead, this proposal encourages us to vary even more. —David Eppstein (talk) 22:56, 9 July 2018 (UTC)
 * Yes. Aside from supporting major "styles" with significant usage on Wikipedia, we should be reducing variation that does not serve a useful purpose. Particularly: as the standard order of author names here is last-first (inverted), we should not enable a variant usage of no significant value.
 * The complexity problem is not entirely the template options themseles, but the documentation. Those of a gnomish bent won't know of the options unless they are documented, and then everyone else gets lost in all the arcane detail. &diams; J. Johnson (JJ) (talk) 19:23, 10 July 2018 (UTC)

You can wish the templates/people worked in a way until you're blue in the face, the fact remain that people use them and errors creep in. For instance, in Jyoti Bhusan Chatterjea you have the following Should we do nothing? Or should we tell people "Hey, this is not how you should use last"? This way the error can be fixed and the citation turned into a proper: This sort of error checking would lead to vast amounts of citation improvements and fixes. For instance, the very basic error of the type J. are so numerous you cannot find them all with straightfoward searches.

Also the parameters values are not cryptic, they are explicit in what the format should be. If you've got better names for parameter values, put them forward, but I don't feel you could be clearer. Headbomb {t · c · p · b} 23:16, 9 July 2018 (UTC)


 * You are mixing together error checking of parameter values and tweaking formatting of the displayed output. Surely these should be orthogonal issues.  Kanguole 23:39, 9 July 2018 (UTC)
 * Sure, but both are related. Quark uses "F.M. Last" format. Why should we forgo error checking and full name metadata simply because the author format isn't the default one? Or require that editors spend more time than needed reviewing every new citation added to ensure this format is respected? Headbomb {t · c · p · b} 00:00, 10 July 2018 (UTC)


 * Oppose additional options. Agree with notion of keeping templates simple and template output to be more uniform than varied. Glrx (talk) 20:57, 27 July 2018 (UTC)

Proposal to end conflicting date formats within the same citation
Please see Wikipedia talk:Manual of Style/Dates and numbers — SMcCandlish ☏ ¢ 😼  15:20, 29 July 2018 (UTC)

lang on suggestion list removed; general q about suggestion list
I have removed lang in Module:Citation/CS1/Suggestions/sandbox as it was whitelisted previously.

I also have a question regarding the suggestions list: the module documentation says the main list is only semi-protected. Does that mean we are invited to make a change there without sandboxing it first and waiting for the general cadence of rollouts? Or should that be full/template-protected given that it is presently transcluded on 20k pages? --Izno (talk) 21:53, 31 July 2018 (UTC)
 * Invited? I don't know about that but I suspect that the amount of damage that can be done to cs1|2 templates by a vandal is relatively minimal – the suggestions file isn't read unless there is a parameter that Module:Citation/CS1 doesn't recognize, and even then, the unrecognized parameter merely produces one of two error messages so I suspect that semi-protection is plenty.  The sandbox version is there because humans err, always best to test whatever you want to do before committing to it.
 * —Trappist the monk (talk) 22:21, 31 July 2018 (UTC)

Citing a portion of a work in a larger volume
This might be a frequent question, but how is one supposed to cite a portion (certain page(s)) of an article in a periodical, or a chapter from a book, in a Wikipedia article that does not have separate lists of references and bibliography, especially when the said work is cited only once in the article?

I know there are r, rp, sfn, etc., but AFAIK they are seldom used for works cited only once in such an article, and quite often do I see page(s) used for the range of pages of the work that is relevant to the claim, not of where to locate the work as a whole in a larger volume (which is permitted according to the template documentation). But it is also the usual practice (not just on Wikipedia but in scholarly works in general) to indicate the range of pages the cited work occupies in a volume so that the reader knows where to look for it. But in the CS1 templates, only one of page, pages and at is allowed to appear, so these two practices are not feasible at the same time at least in a CS1 template.

So how is one supposed to indicate the relevant part of a source that is in turn a part of a larger volume? Need one indicate only the relevant portion and not the location of the work itself? Or indicate the the location of the work in the template and use rp etc. to show the relevant part, even if the work is cited only once? Nardog (talk) 20:37, 30 July 2018 (UTC)
 * I don't understand what you are asking? Is this about CS1 or Harvard referencing? Emir of Wikipedia (talk) 20:51, 30 July 2018 (UTC)
 * Let's say I want to cite a chapter that is 50 pages long in a 300-page anthology book, in an article where every citation uses, but the relevant information that backs up my claim is only on page 30. The book is not cited anywhere else in the article. What should I do? Nardog (talk) 21:04, 30 July 2018 (UTC)
 * I would fill in the chapter parameter with the name of the parameter and the page parameter with the number 30. The page parameter in my personal preference as well as my reading of Template:Cite book is that it is intended for the page which supports the content not to say which pages the chapter is. The documentation says page: The number of a single page in the source that supports the content. it doesn't say to specify what pages the chapters are. Emir of Wikipedia (talk) 21:09, 30 July 2018 (UTC)
 * Thanks. Would you do the same for a paper from a journal that has a DOI? Nardog (talk) 21:11, 30 July 2018 (UTC)
 * Yep I would do the same for that as Template:Cite journal has the same thing written in it as template book. Emir of Wikipedia (talk) 21:19, 30 July 2018 (UTC)
 * Yes, I think so. Except in bibliographies, where identifying a source article's page-range is common practice, in stand-alone journal -article citations, list only the relevant page(s) that identify the location(s) of the information supporting our article; don't make readers search through every damn page of a 50-page journal article to find the one page with the one sentence that supports our article; that's just cruel.  There are others here who believe that there is some requirement to identify a journal-article's entire page range whenever citing a journal article.  We have never seen eye-to-eye on this.  There is no such requirement
 * —Trappist the monk (talk) 21:23, 30 July 2018 (UTC)
 * Then shouldn't ISBN, DOI, etc. appear before the page range? Especially for a journal, it appears like "Journal. 42 (1): 30. doi:xx.xxx/xxx". I don't think the average reader expects "30" to refer to the portion relevant to the claim, yet the DOI to refer to the whole paper.
 * Also, is this a practice recommended in any existing style guide out there? Nardog (talk) 21:38, 30 July 2018 (UTC)
 * cs1|2 were developed using the standard printed style manuals as guides. cs1|2 hew to none but have taken bits and pieces from the variety of style manuals to become their styles.  The volume(issue): page notation is very common to academic journals so is supported here for  which is our template for those journals.  cs1|2 have elected to lump all identifiers together at the end of the rendered citation (it has been this way for many a year.
 * —Trappist the monk (talk) 22:30, 30 July 2018 (UTC)
 * Do those academic journals indicate inside a citation the page range of the relevant part of the work instead of that of the work as a whole? Nardog (talk) 22:41, 30 July 2018 (UTC)
 * I think that you are asking me to comment about the house style of those academic journals (whichever they might be). Not going to do that except to say: the citation style used by any particular academic journal has no bearing on how cs1|2 render citations at en.wiki; has no bearing on how the community here have decided that cs1|2 shall execute those renderings; has no bearing on what the community here have decided are the appropriate uses of the template parameters.
 * —Trappist the monk (talk) 00:15, 31 July 2018 (UTC)
 * I'm not asking about notation. I'm asking you if you know of any academic publication or house style that indicates, inside a citation (not in-text references), the page range of the relevant part of the cited work in place of that of the entire work in a larger work, such as a book or journal. Nardog (talk) 18:54, 31 July 2018 (UTC)
 * I wrote nothing about notation so I guess I have no idea what it is that you are asking.
 * —Trappist the monk (talk) 19:36, 31 July 2018 (UTC)
 * Yes you did. Both "academic journals" and "notation" are your words. Nardog (talk) 19:39, 31 July 2018 (UTC)
 * So I did. I used 'notation' in response to  regarding cs1|2 journal volume-issue-pagination / identifier style.  But, since you did not take up 'notation' with your {{diff|Help talk:Citation Style 1|852720575|852720166}subsequent reply}}, I presumed that we were done with that topic so when I wrote I wrote nothing about notation, I was referring to my previous post, where, in fact, I had written nothing about notation.
 * Now, can we set these little quibbles aside and figure out what it is that you are really asking?
 * —Trappist the monk (talk) 20:03, 31 July 2018 (UTC)
 * I'm asking you if you know of any academic publication or house style that indicates, inside a citation (not in-text references), the page range of the relevant part of the cited work in place of that of the entire work in a larger work, such as a book or journal. Nardog (talk) 20:11, 31 July 2018 (UTC)
 * Repeating the words in green text doesn't making the question that you really want to ask any clearer. I still think that you are asking about some journal's house style.  As I said before, I have nothing to say about any particular academic journal's house style.
 * —Trappist the monk (talk) 21:17, 31 July 2018 (UTC)
 * I know of such cases. Several, in fact. E.g.: the Geological Society of America. See this article from GSA Today for several citations with page ranges.


 * See also what Jc3s5h has quoted (below) from CMS-17. &diams; J. Johnson (JJ) (talk) 21:43, 31 July 2018 (UTC)
 * Thanks for the link, but I don't see any instance of what we're talking about in that paper (admittedly I didn't check every citation with a page range though). Not only that, it even uses parenthetical referencing. Could you point to an example of a citation in which the page range of only a portion of the source is given? Nardog (talk) 22:24, 31 July 2018 (UTC)


 * Whether the short-cites – the "Baker et al., 1998" bits — are placed in the text (with or without parentheses), or in a note, is entirely immaterial to question of page ranges in the full citation. In the example provided (here) the full citations are collected in a "References Cited" section (here). The second reference in that article is as follows:


 * I have highlighted the page range. Additional page ranges can be found in most of the other references.
 * Please note that it appear you are getting tangled up on two kinds of "page ranges". What I was just describing is where the source is a chapter, report, or article that is found in a larger work (such as book, journal issue, encyclopedia, etc.), where the page range used in a full citation to describe where that source is found in the larger work. A page range can also be specified as the in-source location of the specific material or passage you are citing. But note: that does not go into the full citation. It can be appended to a full citation (as explained previously, when the source is cited only once), or it can be specified in the short cite.


 * You don't see any in-source page ranges in the example article because in-source page numbers are usually omitted, on the assumption that the reader can find the proper passage on his or her own. (Though we have an exception here with "Chamberlin and Leverett, 1894, p. 265".) &diams; J. Johnson (JJ) (talk) 00:59, 2 August 2018 (UTC)
 * I'm afraid it seems to me you're the one who is tangled up on two kinds of "work" (or "source"). What I've been asking is (I quote now with added annotations) if you know of any academic publication [such as a journal or book] or house style [such as CMS, APA, MLA, AP, or whatever a publisher adopts] that indicates, inside a [full] citation (not in-text references ["short-cites" as you call them]), the page range of the relevant part [or, "the in-source location of the specific material or passage you are citing"] of the cited work [such as a journal paper or book chapter] in place of [the page range] of [the entirety of the aforementioned journal paper or book chapter] in [the journal issue or book the said paper or chapter is included in]. Now is that clearer to you? Nardog (talk) 01:26, 2 August 2018 (UTC)
 * It's obviously not clearer to you what you are asking about. As you insist on being obtuse I think we are done here. &diams; J. Johnson (JJ) (talk) 21:00, 2 August 2018 (UTC)
 * Yeah, to me the question could not be any clearer, so I pretty much give up at this point. Nardog (talk) 22:48, 2 August 2018 (UTC)


 * [edit conflict] rp is an abomination. Especially if it's only cited once, in a citation where you also need to specify a page range for the whole work (like a journal article or book chapter) my usual technique would be to add a note about where in the work to find the specific contribution, as text after the end of the citation template within the same footnote. Like " Theorem 4, p. 29." or " See in particular p. 29." —David Eppstein (talk) 20:54, 30 July 2018 (UTC)
 * "See in " is my standard way of doing it. Headbomb {t · c · p · b} 21:02, 30 July 2018 (UTC)
 * Don't you think using CS2 would be more appropriate in that construction in terms of punctuation? (Although admittedly my original question pertains to CS2 as well.) Nardog (talk) 22:01, 30 July 2018 (UTC)
 * I personally, if revamping the citations in an article with no discernible existing style, would use CS2 if there weren't enough references to bother with an alphabetical list of sources. If I do an alphabetical list of sources, I use CS1 and short footnotes, or CS1 and parenthetical referencing. Jc3s5h (talk) 22:13, 30 July 2018 (UTC)


 * More likely short cites, or even shortened citations, placed in a footnote? &diams; J. Johnson (JJ) (talk) 22:38, 30 July 2018 (UTC)


 * {Rp} is, indeed, an abomination.


 * The question arises from an incomplete understanding of the purpose and proper use of full citations, such as produced by the cite xxx and citation templates. They refer to the whole source, be it an entire book, a chapter in a book, an article in an encyclopedia or journal, etc.  Where your source is only a portion (such as a chapter) of larger work use pages to show the location (page range) of that portion in the larger work.  (Note that I dispute the use of pages for in-source speicification.)


 * To refer to one or more specific locations (pages) within a source, just add that information following citation. (That is, outside the template.) If elsewhere you want refer to that source again, but a different page, use a harv template. These link to the full citation (some caveats here) so you don't have repeat it.


 * Regarding page ranges: this provides useful information on the length of the article or chapter (and I have seen "chapters" of a single page). It also verifies which article/chapter/report is being referred to, and serves as a check on specific references within the source. (Which is particularly useful for checking that one has cited the right chapter.) &diams; J. Johnson (JJ) (talk) 22:42, 30 July 2018 (UTC)
 * I wholeheartedly concur with this. No style that I'm familiar with condones such a practice and the template documentation is woefully misleading in this regard. In-source specification, as you call it, is unjustly common, which I think is thanks in no small part to the fact that your suggested alternative is not natively supported by those templates. I've seen even rp turned into page(s). Nardog (talk) 23:06, 30 July 2018 (UTC)
 * Huh? I am having some trouble understanding what you are saying. (Especially with "unjustly common".) As to my "suggested alternative" – in essence, to use Harv templates to create short-cites – being "not natively supported by those templates": ah, perhaps you are referring to the current necessity of adding a harv line when using CS1 templates. Which is certainly easy enough. And see also the discussion above about having "ref" default to "harv" for CS1 templates. Or just use citation, where "ref=harv" is already the default. &diams; J. Johnson (JJ) (talk) 21:48, 31 July 2018 (UTC)
 * Harv and harv don't have much use for a source that appear only once in an article without a bibliography, do they?
 * By "your suggested alternative" I meant adding in-source specification following the citation. People rarely add anything else inside  with a cite template in it. If had a built-in ability to indicate where the portion of the source relevant to the claim is outside the main citation in addition to where to find the entire source, don't you think that would deter people from using page(s) for in-source specifications? Nardog (talk) 22:02, 31 July 2018 (UTC)
 * Short answer: No. That, as you say, editors "rarely add anything else" inside the note tags is due to a general failure to distinguish notes from the citations the notes generally contain, even to the point of thinking that the  tags are part of the citation itself. That one can add all sorts of stuff inside a note seems to be not well known. I don't know what kind of {cite} feature would fix that.


 * A source cited only once in an article, and inserted "in-line", doesn't need a Harv template. Just append the in-source location after the template. &diams; J. Johnson (JJ) (talk) 22:51, 31 July 2018 (UTC)

Chicago Manual of Style, 17th ed., in the chapter on the notes & bibliography system of citation, p. 752, states "Page numbers and other locators. In notes, where reference is usually to a particular passage in a book or journal, only the page numbers pertaining to that passage are given. In bibliographies, no page numbers are given for books cited as a whole; for easier location of journal articles or for chapeters or other sections of a book, the beginning and ending page numbers of the entire article or chapter are given." Jc3s5h (talk) 19:10, 31 July 2018 (UTC)
 * Does Chicago's notes and bibliography system allow having only notes and not a bibliography? Nardog (talk) 19:23, 31 July 2018 (UTC)
 * Notes without a bibliography is allowed, but p. 743 states notes are usually used together with a bibliography. Jc3s5h (talk) 19:29, 31 July 2018 (UTC)
 * This question was what to do if no bibliography is present. Emir of Wikipedia (talk) 19:33, 31 July 2018 (UTC)
 * I wonder if "only the page numbers pertaining to that passage are given" still applies when no bibliography is employed. Nardog (talk) 19:37, 31 July 2018 (UTC)


 * Of course "notes without a bibliography" is allowed. More pertinent to the Wikipedia context, and particularly to the use of Harv templates: collecting the full citations in a separate bibliography is not required. Stuff the full citations where ever you want, and the Harv templates will link to them. It's not just magical, its automagical.


 * And page ranges are useful in full citations regardless of where they get put. But your "page numbers pertaining to that passage are given" (italics added) sounds like an in-source specifier. Those go with the short-cites; they do not apply to the full citations that might be collected in a bibliography, and are not contingent on having a biblography. &diams; J. Johnson (JJ) (talk) 22:22, 31 July 2018 (UTC)

Side note: Editors who believe that rp is an abomination should watch m:WMDE Technical Wishes/Book referencing. The creator of the rp template is hoping that his old template could be retired after this long-discussed system is (eventually) implemented. WhatamIdoing (talk) 05:09, 1 August 2018 (UTC)

Dashify issues too
Just like 1-15 renders as 1–15, rather than 1-15, so should 1-2 render as 1–2, rather than 1-2. Headbomb {t · c · p · b} 14:17, 30 July 2018 (UTC)
 * Done in sandbox:


 * But, while doing that, I noticed that we do the same for volume but only when rendering in bold font; not when volume renders in normal font:
 * Yeah, I know, I wrote that code so the likelihood is that it's incomplete or just wrong. Is there a reason (that I failed to document in the code, and no longer remember) that a volume range should use a hyphen separator in preference to an unspaced endash when volume is rendered in normal font?
 * —Trappist the monk (talk) 14:02, 1 August 2018 (UTC)
 * The only case I could think of not making this default behavior are in cases like 3-A/3-A/3-A, e.g.
 * None of those should be dashified. And the volume shouldn't be lowercased automatically either. Headbomb {t · c · p · b} 15:23, 1 August 2018 (UTC)
 * Volume is lowercased in your example because that is how you wrote it; the module does not modify case for any of these parameters:
 * —Trappist the monk (talk) 15:40, 1 August 2018 (UTC)
 * Stray capslock/shift thing. My bad. However, it does dashify 3-A to 3–A. Headbomb {t · c · p · b} 15:47, 1 August 2018 (UTC)
 * Tweaked sandbox so that simple cases of different character types on opposite sides of a hyphen (&lt;letter(s)>&lt;hyphen>&lt;digit(s)> or &lt;digit(s)>&lt;hyphen>&lt;letter(s)>) are not modified:
 * None of those should be dashified. And the volume shouldn't be lowercased automatically either. Headbomb {t · c · p · b} 15:23, 1 August 2018 (UTC)
 * Volume is lowercased in your example because that is how you wrote it; the module does not modify case for any of these parameters:
 * —Trappist the monk (talk) 15:40, 1 August 2018 (UTC)
 * Stray capslock/shift thing. My bad. However, it does dashify 3-A to 3–A. Headbomb {t · c · p · b} 15:47, 1 August 2018 (UTC)
 * Tweaked sandbox so that simple cases of different character types on opposite sides of a hyphen (&lt;letter(s)>&lt;hyphen>&lt;digit(s)> or &lt;digit(s)>&lt;hyphen>&lt;letter(s)>) are not modified:
 * Tweaked sandbox so that simple cases of different character types on opposite sides of a hyphen (&lt;letter(s)>&lt;hyphen>&lt;digit(s)> or &lt;digit(s)>&lt;hyphen>&lt;letter(s)>) are not modified:


 * Same types are:
 * —Trappist the monk (talk) 16:14, 1 August 2018 (UTC)
 * what about cases like L21-L23? Those are pretty common. Headbomb {t · c · p · b} 04:16, 2 August 2018 (UTC)
 * Tweaked; now handles a comma- or semicolon-separated list of ranges and singles; removes extraneous spacing around the hyphen/endash; skips linked ranges:
 * Tweaked; now handles a comma- or semicolon-separated list of ranges and singles; removes extraneous spacing around the hyphen/endash; skips linked ranges:


 * when ranges have spaced or unspaced endash or emdash separators, emdash is replaced with endash and extraneous whitespace removed, linked ranges skipped:


 * —Trappist the monk (talk) 12:35, 2 August 2018 (UTC)
 * And one last tweak: ranges of hyphenated numbers (also dot separators):


 * This does not fix the single hyphenated number, 1-2 is still converted to use an endash. Elsewhere I suggested a mechanism that could be used to mean "accept this as written" which uses the doubled-parentheses markup supported by vauthors as ((1-2))
 * —Trappist the monk (talk) 13:45, 2 August 2018 (UTC)
 * Help:CS1 details the simplest way: just use hyphen. Headbomb {t · c · p · b} 14:16, 2 August 2018 (UTC)
 * ... says the editor who finds adding harv onerous. If we are looking for ease-of-typing, adding   and   seems easier to me than typing out the ten characters required for .  This works:
 * —Trappist the monk (talk) 11:30, 3 August 2018 (UTC)
 * Which WP:AWB won't respect, and will need to be fixed to hyphen by editors. This is bad, especially when combined with things like 3 (23), and should be undone. Headbomb {t · c · p · b} 11:59, 3 August 2018 (UTC)
 * —Trappist the monk (talk) 11:30, 3 August 2018 (UTC)
 * Which WP:AWB won't respect, and will need to be fixed to hyphen by editors. This is bad, especially when combined with things like 3 (23), and should be undone. Headbomb {t · c · p · b} 11:59, 3 August 2018 (UTC)

Phase out |vauthors=
We need to ditch this. All it's doing is producing shite metadata, and people are abusing it to destroy good metadata we already have. I keep having to revert this all the time. vauthors is a pointless drain on other editors' time. If someone wants Vancouver-style names, they can do CeesdaleAB EfflyDE .... — SMcCandlish ☏ ¢ 😼  07:40, 5 July 2018 (UTC)
 * Do you have evidence that the metadata that derives from vauthors is not the same as that produced by last first?
 * With the exception that Vancouver system style renders name lists slightly differently from cs1|2 style, the metadata for the above examples are exactly the same.
 * —Trappist the monk (talk) 09:09, 5 July 2018 (UTC)
 * vauthors has advanced logic because it expects a very specific format and will throw errors if things are not declared in that format. That's why it can produce the correct metadata. Headbomb {t · c · p · b} 14:33, 5 July 2018 (UTC)
 * And there's more than one kind of metadata. The template coding itself is meta-data for editors and source-aware readers. Keeping sur- and given names separate is future-proof, and also directly operable upon by tools. vauthors should just be deprecated and replaced with a vanc parameter that applies visual output munging to data submitted as parameter information – loss of actual data; i.e. render SamuelsDiana R.y as Samuels DR, without costing us the full name, which may be the only way to tell one author apart from another without digging around in journal sites that , if you're lucky, will give you the full name.  Any time people convert other citation formats to Vancouver, they  (not just metadata). This makes it pointlessly onerous to convert back (either re-research the sources, or dig back in page history) even when there's a WP:CITEVAR consensus to do so.  For this reason, I revert on sight every attempt to convert a cite to Vancouver, unless there's a consensus on the talk page that this article uses Vancouver citation format (which is rare, and I would be prone to challenge it if the article didn't begin in that format).  The issue is important enough, I've considered a WP:VPPOL RfC to ban the Vancouver format as antithetical to our goals.  The input needs to be cite-format-neutral or it breaks cross-format compatibility of the raw information.  — SMcCandlish ☏ ¢ 😼  21:55, 5 July 2018 (UTC)  Maybe this is actually essentially the same proposal as the af one below.  Nope, definitely not.  — SMcCandlish ☏ ¢ 😼  21:58, 5 July 2018 (UTC); updated:  — SMcCandlish ☏ ¢ 😼  23:34, 27 July 2018 (UTC)
 * Citations exist to verify the material provided, not to provide full author information every time one cites something. Good metadata benefits is a bonus, not a goal, and this is no different than converting things to "Smith, J." or "J. Smith". That said, see my proposal below. Headbomb {t · c · p · b} 22:00, 5 July 2018 (UTC)
 * Truncating the author names for no legitimate reason makes that citation verification more difficult. It also makes our metadata work more difficult (e.g. determining whether someone qualifies for an authorn-link).  — SMcCandlish ☏ ¢ 😼  22:13, 5 July 2018 (UTC)
 * I like having a vanc parameter, provided it's smart enough to extract the proper initials from several forms of input. Also a similar initials parameter that displays as "Samuels, D. R." Given both of those then we could push for always encoding the full personal names even where an article's consistent displayed style is initials. And then we could push for phasing out vauthors= and requiring "no loss of data".
 * Hmmm, could something similar be done for the extremely small number of editors that like small caps ("bluebook" style)? &diams; J. Johnson (JJ) (talk) 23:38, 5 July 2018 (UTC)
 * I would certainly hope note. That style should just be nuked as a readability problem (and another loss of data: it won't distinguish between the name Devine, which is Irish, and DeVine which is French, or Flemish or something).  — SMcCandlish ☏ ¢ 😼  06:37, 16 July 2018 (UTC)
 * It does? vs . Headbomb {t · c · p · b} 10:40, 16 July 2018 (UTC)
 * That's assuming anyone uses the right smallcaps markup and input the name correctly. What's very likely to happen is that one of those people who likes this format is going to enter the name as DEVINE.  — SMcCandlish ☏ ¢ 😼  23:34, 27 July 2018 (UTC)
 * There is vanc which has been in place for years. For consistency, all name-lists, author, editor, translator, interviewer are rendered in Vancouver style when vanc:
 * —Trappist the monk (talk) 10:40, 6 July 2018 (UTC)
 * Oh, so the functionality is already present, right? The name is bit putting-offish, though. (I reckon especially for editors that find the templates challenging as it is.) Could we have y as a synonym? &diams; J. Johnson (JJ) (talk) 22:37, 6 July 2018 (UTC)
 * Or vanc so that it scales to other systems if we end up supporting them. Headbomb {t · c · p · b} 22:41, 6 July 2018 (UTC)
 * That might be better. And, in having the same value as the long-form, easier to implement. &diams; J. Johnson (JJ) (talk) 23:16, 6 July 2018 (UTC)
 * If I recall correctly the reason for naming name-list-format as such was that it includes editors as well as authors, as noted above…or were you considering also having vanc, vanc, vanc, etc.? —Phil | Talk 15:06, 9 July 2018 (UTC)
 * I've commented for a week+ in the mutating thread below, and have to come back to this one: We need a short y, even if it just resolves to vanc (which pretty much no one is ever going to remember or use), the deprecated vauthors.  — SMcCandlish ☏ ¢ 😼  06:37, 16 July 2018 (UTC)
 * So, can anyone actually articulate an objection to this deprecation of and phasing out of vauthors? I don't see any above that haven't been addressed. It appears that any use of this parameter can be replaced by standardized first1, last1, and vanc, which could have a short alias.  I would like to see this proceed, because vauthors is a bletcherous, legacy workaround that has been surpassed, and cleaning up after it is an increasing editorial drain. It needs to stop. At least 19 out of 20 uses of it I encounter are someone inserting it willy-nilly into an article that does not use Vancouver citation style anyway.  — SMcCandlish ☏ ¢ 😼  23:34, 27 July 2018 (UTC)
 * —Trappist the monk (talk) 10:40, 6 July 2018 (UTC)
 * Oh, so the functionality is already present, right? The name is bit putting-offish, though. (I reckon especially for editors that find the templates challenging as it is.) Could we have y as a synonym? &diams; J. Johnson (JJ) (talk) 22:37, 6 July 2018 (UTC)
 * Or vanc so that it scales to other systems if we end up supporting them. Headbomb {t · c · p · b} 22:41, 6 July 2018 (UTC)
 * That might be better. And, in having the same value as the long-form, easier to implement. &diams; J. Johnson (JJ) (talk) 23:16, 6 July 2018 (UTC)
 * If I recall correctly the reason for naming name-list-format as such was that it includes editors as well as authors, as noted above…or were you considering also having vanc, vanc, vanc, etc.? —Phil | Talk 15:06, 9 July 2018 (UTC)
 * I've commented for a week+ in the mutating thread below, and have to come back to this one: We need a short y, even if it just resolves to vanc (which pretty much no one is ever going to remember or use), the deprecated vauthors.  — SMcCandlish ☏ ¢ 😼  06:37, 16 July 2018 (UTC)
 * So, can anyone actually articulate an objection to this deprecation of and phasing out of vauthors? I don't see any above that haven't been addressed. It appears that any use of this parameter can be replaced by standardized first1, last1, and vanc, which could have a short alias.  I would like to see this proceed, because vauthors is a bletcherous, legacy workaround that has been surpassed, and cleaning up after it is an increasing editorial drain. It needs to stop. At least 19 out of 20 uses of it I encounter are someone inserting it willy-nilly into an article that does not use Vancouver citation style anyway.  — SMcCandlish ☏ ¢ 😼  23:34, 27 July 2018 (UTC)


 * I don't see that we have a clear vision of how to proceed. Removing vauthors seems acceptable, but there is still a question regarding doing y or vanc or some such. I think this discussion is on hold until the following discussion ("New parameter: af") is resolved. &diams; J. Johnson (JJ) (talk) 23:01, 5 August 2018 (UTC)

Arbitrary break

 * This proposal is a complete non-starter. The citations to tens of thousands of biomedical and scientific articles were first added using Wikipedia template filling tool which initially used authors which later was replaced with vauthors. WP:CITEVAR covers not only the rendered citation but also how citations are formatted in the raw wiki text. Hence replacing vauthors with the much more verbose first1, last1, ... in articles where Vancouver was the first established citation style would violate CITEVAR. The rationale for using vauthors may be found here. In addition firstn imposes few restrictions on how first name are stored, rendered, and displayed in the meta data.  They can be spelled out in full, may or may not include middle names, use inititials with or without periods. In contrast, vauthors imposes strict formatting requirements on first initials.  In short, vauthors is much more efficient and insures consistency.
 * I also find the argument that we need first names spelled out to distinguish between authors that have identical same last names and first initials unpersuasive. First of all, this is a rather uncommon occurrence. Second, why is it important to distinguish between authors in the first place? The Vancouver System has been adopted by several thousand journals. It doesn't cause problems for the readers of these journals, so why would it cause problems for readers of Wikipedia articles? Third, most citations, at least the more recent ones, contain links to the original source, so it it is easy to determine the first name if someone so desires. Finally the use of meta data is over rated. Wikipedia is not a reliable source and that includes bibliographic information.  If possible, one really should avoid copying citation meta data from one article to the next because the data my be corrupted or inaccurate through honest mistakes or vandalism.  It is much better to harvest a pmid (or isbn) ID and recreate the citation from scratch (including full author names if so desired) using one of the many available tools for doing so.  Why replicate PubMed within Wikipedia? Boghog (talk) 01:11, 6 August 2018 (UTC)
 * determining whether someone qualifies for an authorn-link – one really should go back to the original source to check the authors affiliation before linking authors. Boghog (talk) 01:23, 6 August 2018 (UTC)
 * vauthors is a bletcherous, legacy workaround ... Beauty is simplicity. vauthors is minimalist, clean, and uncluttered. first1, last1, .... is bletcherous. Boghog (talk) 08:52, 6 August 2018 (UTC)

Further DOI checking
Per the DOI standard, the approved character set for DOI suffixes is: "a-z", "A-Z", "0-9" and "-._;/" since 2008. A "check DOI" error should be thrown if a doi with an non-approved character is found in a publication dated 2009 or later. It would help find these sort of errors. Headbomb {t · c · p · b} 18:57, 23 June 2018 (UTC)
 * Problematic. That particular (dead) doi  is 'allowed' by the current standard: "An expanded set of characters was supported prior to 2008, so you may see DOIs with now-banned characters (such as #, +, <, and >). DOIs created before the character set was restricted are still supported..."  If we tighten the doi validity test to accept only dois compliant with the post-2k8 standard, we risk falsely catching pre-2k8 dois that use the previously allowed character set (which the current standard does not clearly define).
 * —Trappist the monk (talk) 19:33, 23 June 2018 (UTC)
 * I agree. I don't recall seeing # but I've definitely seen some with, e.g. . We need to continue allowing those. —David Eppstein (talk) 20:02, 23 June 2018 (UTC)
 * That DOI dates from 2000, which is before 2008., the point isn't to catch all such errors, but to catch those we can, e.g. if date/year is >=2009, then have the template flag those errors. If the date is before that, don't flag the errors. Headbomb {t · c · p · b} 20:20, 23 June 2018 (UTC)

I just realized that displays rather incorrectly... Headbomb {t · c · p · b} 16:36, 1 August 2018 (UTC)


 * any help here? Both for the new error and the doi fuckup above? Headbomb {t · c · p · b} 04:52, 9 August 2018 (UTC)

Cross check year/date with the arxiv/bibcode

 * This is a follow up to Help talk:Citation Style 1/Archive 16

I've done a lot of cleanup related to bad arxiv/bibcodes, but a thing that would greatly help is we had some sort of validation / verification that the date is consistent with the date part of identifiers.

For arxiv identifier, the date info is encoded in this format
 * New style  or   (e.g. : January 2013, submission #2341)
 * Old style  (e.g. : December 1997, submission #032)

Because arxivs are normally preprints, we should have a silent maintenance category Category:CS1: arXiv date mismatch whenever date is younger than what you can infer from the arxiv identifier.

For bibcodes, the format is the leading 4 digits refer to the year. Since bibcodes are normally for the version of record, we should have a silent maintenance category Category:CS1: bibcode date mismatch whenever the date doesn't match what you can infer from the bibcode.

This is fine This would throw the bibcode date mismatch error This would throw both the arxiv and bibcode date mismatch errors With a yes to suppress the categories when the mismatch is legit for a variety of reasons. Headbomb {t · c · p · b} 16:14, 24 February 2018 (UTC)
 * can you offer any help here? Headbomb {t · c · p · b} 14:35, 22 March 2018 (UTC)
 * I don't have the coding chops for this work. I think it's a reasonable idea, as long as arXiv and Bibcode IDs all come in a consistent format. I seem to remember some oddball identifiers, but those might have been something other than arXiv and Bibcode.
 * Parameter names are difficult. ignore-date-mismatch is too ambiguous for my taste; the parameter name should indicate what it applies to, ideally, and this one is just for arXiv and Bibcode, not dates in general. See other discussions on this page about the difficulty of naming parameters and the confusion that it causes when editors misinterpret the names. – Jonesey95 (talk) 16:31, 22 March 2018 (UTC)
 * how about ignore/ignore? Headbomb {t · c · p · b} 17:22, 26 April 2018 (UTC)
 * can you help here? Headbomb {t · c · p · b} 13:25, 30 April 2018 (UTC)
 * can you help here? Headbomb {t · c · p · b} 21:27, 11 June 2018 (UTC)
 * can you help here? Headbomb {t · c · p · b} 21:27, 11 June 2018 (UTC)


 * can you help here? Headbomb {t · c · p · b} 04:55, 9 August 2018 (UTC)

Sfn for Episodes?
Does anyone know what the sfn is for episodes? I'm having trouble finding it. Armegon (talk) 04:44, 9 August 2018 (UTC)
 * See User:Jonesey95/Tools. – Jonesey95 (talk) 11:19, 9 August 2018 (UTC)

Best practice for this citation
What would be the best way to form this citation?

Note that newspapers.com is not a web archive but similar to JSTOR and other commercial database providers and I believe shouldn't be in the archiveurl but what to do with it is unclear. -- Green  C  13:47, 10 August 2018 (UTC)
 * I assume there is an author. I suppose you could do MOS:US in the title but I don't feel strongly on the point. Access date here doesn't feel great but it doesn't feel horrid either. --Izno (talk) 13:55, 10 August 2018 (UTC)
 * This works, but it drops the original URL if newspapers.com goes defunct we couldn't easily find alternative archives. Maybe have two cite templates, the above and one for the original URL with a tag? --  Green  C  14:34, 10 August 2018 (UTC)
 * Would this work, or would having an external link in the via field be undesirable?    Laatu (talk) 14:59, 10 August 2018 (UTC)
 * I think the via is a plain text field, not for URLs. -- Green  C  15:50, 10 August 2018 (UTC)
 * Would this work, or would having an external link in the via field be undesirable?    Laatu (talk) 14:59, 10 August 2018 (UTC)
 * I think the via is a plain text field, not for URLs. -- Green  C  15:50, 10 August 2018 (UTC)

Slide parameter
Is it possible to add this parameter to Template:Cite web? It will be easy to cite sources using slides which are hard to link to. -- Kailash29792 (talk)  07:30, 13 August 2018 (UTC)
 * Real life example of what you mean please?
 * —Trappist the monk (talk) 08:43, 13 August 2018 (UTC)
 * The numerous slideshows at Rediff.com are perfect examples, such as this. I cannot link the slides here as they would just redirect to the first slide. That is why I use the "page" parameter, simply to indicate the slide number if I can't link it. But I think it's high time they added a parameter called "slide". -- Kailash29792 (talk)  09:13, 13 August 2018 (UTC)
 * This is what at is for. See the documentation for cite web. – Jonesey95 (talk) 11:26, 13 August 2018 (UTC)

Surname placement
Right now, the citation templates like the cite book template prefers to place the surname before the first name, eg. "Smith, John". I'd rather it be "John Smith". The reason is that some names have unusual orderings. For example, Korean names place the family name first (eg Kim Il Sung, Kim Jong Il, Kim Jong Un). I'm also a bit uncertain where to place particles, like in "Victor von Doom". Is the "von" part of the surname or the first name? I think this template should lay out the names in their proper order. Kurzon (talk) 06:14, 10 August 2018 (UTC)


 * What is the "proper" order? In some cultures the "proper" order is the surname or family first, in others it comes last. In Spanish the family name – what in English we consider the "last" name – can have other names after it. In short, there is no universal "proper" order.


 * We invert European-style "John Smith" name order to "Smith, John" because the surname is recognized as the primary key in identifying, listing, and finding names, and it is handier, more visisbile, to have it out in front. (Also makes sorting easier.)


 * I believe particles are generally kept in front of the surname, but ignored for sorting and searching. Perhaps someone else knows more about that. &diams; J. Johnson (JJ) (talk) 23:06, 13 August 2018 (UTC)
 * If you are concerned that readers understand which names are surnames and which are first names, you should prefer surname-first with commas. Because that way, "Smith, John", "Kim, Il Sung", "von Doom, Victor", and "Montarcé Lastra, Antonio" are all unambiguous. If you tried to write them in culture-specific orders (given name first for most Western countries, surname first but no commas for most Eastern countries), then readers would have to know much more about local cultures to understand that "Kim" and "Montarcé" are surnames, and that "van" is not a middle name. (It's not perfect — for instance readers might still not know that Kim's whole first name is Il Sung, and that it does not make sense to separate those pieces into a first and middle name — but it's better than the alternatives.) —David Eppstein (talk) 23:31, 13 August 2018 (UTC)

Writer(s)
I was told to discuss first. My change is a simplification, and I didn't think it was a bold change in need of discussion but here goes.

The documentation makes pedantic use of parentheses in the case of the phrase "Writer(s)". I understand as a matter of writing style some overly cautious editors are worried about the possibility of it being only one Writer or possibly multiple Writers, but this is complication is never necessary (instead of complicating the base case, editors should keep the base case simple, and then only in exceptional cases fully explain why the possible case of only 1 item is notable or requires warning). In the specific case of this documentation where no author is specified and an unknown Staff byline is used we simply cannot know the unknown, it might be one or many writers but it doesn't matter. In addition this is specifically a wikimarkup comment for the benefit of other editors, to indicate that the author was intentionally left blank because a staff byline was used.

Keep it simple, if the possibility of one or none is important say so, otherwise avoid over-punctuated plural(s). -- 37.110.218.43 (talk) 15:20, 15 August 2018 (UTC)
 * "Writer(s)" is straightforward. It means that editors can choose to write "writer" or "writers" or "writer(s)", as they choose. It also means that the editor does not know if there is one writer or many, so the "(s)" indicates that unknown. – Jonesey95 (talk) 19:22, 15 August 2018 (UTC)

Tidy hack regarding Coins span
FYI, I have removed a hack for Tidy. The problem was documented in phab:T29786 and is now fixed by Remex. --Izno (talk) 16:41, 16 August 2018 (UTC)