Help talk:Citation Style 1/Archive 45

Archive 40

←

Archive 43

Archive 44

Archive 45

Archive 46

Archive 47

→

Archive 50

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 vanc), but that's just awful to remember.

You could have

|last#=Smith |first#=John Howard (or |editor#-last=Smith |editor#-first=John Howard)
Core proposal
Last, First	Last First	First Last	MOS:INITIALS-compliant
|af=Last, First → Smith, John Howard	|af=Last First → Smith John Howard	|af=First Last → John Howard Smith	Any of |af=MOS → Smith, John Howard Smith, John H. Smith, J. H.
Extended
Last, First	Last First	First Last	Specific style
|af=Last, F. M. → Smith, J. H. |af=Last, F.M. → Smith, J.H. |af=Last, F M → Smith, J H |af=Last, FM → Smith, JH	|af=Last F. M. → Smith J. H. |af=Last F.M. → Smith J.H. |af=Last F M → Smith J H |af=Last FM → Smith JH	|af=F. M. Last → J. H. Smith |af=F.M. Last → J.H. Smith |af=F M Last → J H Smith |af=FM Last → JH Smith	|af=AMA → AMA |af=APA → APA |af=Bluebook → Bluebook |af=Vancouver → Vancouver
Overide
|af#=ignore would ignore validation for |last#=/|first#=/|author#= specifically. This would allow for single-name authors (e.g. |author1=Riazuddin |author2=Fayyazuddin |last3=Rashid |first3=M. A.) and corporate names (e.g. |author=RAND Corporation) without losing the benefits of specific formats (e.g. |af=F. M. Last).

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

• |last1=Dickinson |first1=Emily |last2=Fitzgerald |first2=Francis Scott Key |af=Last, F.M. → Dickinson, E.; Fitzgerald, F.S.K.
• |last1=Dickinson |first1=Emily |last2=Fitzgerald |first2=Francis Scott Key |af=Last, FM → Dickinson, E; Fitzgerald, FSK
• |last1=Dickinson |first1=Emily |last2=Fitzgerald |first2=Francis Scott Key |af=F. M. Last → E. Dickinson; F. S. K. Fitzgerald
• |last1=Dickinson |first1=Emily |last2=Fitzgerald |first2=Francis Scott Key |af=Vanc → Dickinson E, Fitzgerald FS

and throw in error messages when the conversion to the specified format couldn't work.

• |author1=Emily Dickinson |last2=Fitzgerald |first2=Francis Scott Key |af=F. M. Last → Emily Dickinson; F. S. K. Fitzgerald ()

or have other issues

• |last1=Dickinson |first1=E., |last2=Fitzgerald |first2=F. S.K. |af=af → Dickinson, E.; F. S.K. Fitzgerald ()
• |last1=Languillat |first1=J. -C → Languillat, J. -C ()
• |last1=Howard |first1=J. B.C → Languillat, J. B.C ()

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 |af3=AF1 to display |last3=Liu |first3=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)

@Izno: 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 |af=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 |af=LF4 is used in the article, and whenever it adds citations, it could then use |af=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)

@Izno: 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 |af=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 |name-list-format=CS1 or |af=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. ♦ 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. {{reflist|af=Last, F. M.}}), 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)

@Kanguole: 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 |last=Smith/|first=J.F., |author=John Smith, |last=Smith/|first=JF and |last=Smith/|first=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#References with Sex_manual#Modern_sex_manuals. This is the diff required to make that happen, and involves reviewing every citation. Now if someone uses the ref toolbar to add doi:10.1080/00224490509552267, you'll have DeLamater, John D.; Sill, Morgan (May 2005). "Sexual desire in later life". Journal of Sex Research. 42 (2): 138–149. doi:10.1080/00224490509552267., which again breaks the style, and needs a cleanup edit. This could be made much, much easier by simply adding |af=Last, F. M., rather than changing |last1=DeLamater |first1=John D. |last2=Sill |first2=Morgan to |last1=DeLamater |first1=J. D. |last2=Sill |first2=M. 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 |af=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.).
• |af=initials: initial (with period) of first name, with middle initials.
• |af=vanc: displayed in Vancouver style.
• |af=bluebook (or |af=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. ♦ J. Johnson (JJ) (talk) 19:51, 8 July 2018 (UTC)

Regarding |af=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. ♦ 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)

@Kanguole: 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 (|first=J.- H., bad abbreviations (|first=J. H, bad capitalizations |first=J. h., or bad punctuation (|first=John,. No error messages are thrown if you have a mixture of "Smith, John H." and "Jones, A. F.".
• Using a specific order (|af=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 |af#=ignore so single names / corporate names can still be used.
• For the MOS:INITIALS-centric, |af=MOS would ensure that initials, if used, would be in the MOS-format. This can help catch inconsistent abbreviations, when used (e.g. |first1=J.H. + |first2=A F), but does not force abbreviations to be used.
• For those with a specific abbreviation style in mind, they can use |af=Last, F. M. or |af=F.M. Last or whatever to present things in that specific format. If |af=F.M. Last is used, both |last=Smith |first=John H. / |last=Smith |first=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)

@David Eppstein, Izno, Boghog, SMcCandlish, Jc3s5h, J. Johnson, Kanguole, and Trappist the Monk: 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. ♦ J. Johnson (JJ) (talk) 22:00, 9 July 2018 (UTC)

@David Eppstein: 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, |author#=Thant is all that's needed (or possibly |author#=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 |last=Johnson |first=O, so there wouldn't be any errors shown there. You would get an error if you specified |af=MOS, but it's something you could overide with |af#=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 |af=MOS should be a default not an option; MoS applies to citation material except when a citation style requires (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)

|af=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 |af#=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 unnecessary 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. ♦ 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. ♦ 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

• A, K, Basu (2017). "Obituary". Calcutta School of Tropical Medicine.{{cite web}}: CS1 maint: multiple names: authors list (link)

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:

• Basu, A. K. (2017). "Obituary". Calcutta School of Tropical Medicine.

This sort of error checking would lead to vast amounts of citation improvements and fixes. For instance, the very basic error of the type |last=J. are so numerous you cannot find them all with straightfoward searches (Search for insource:/last *= *[A-Z]\./).

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)

@Kanguole: 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

FYI

 – Pointer to relevant discussion elsewhere.

Please see Wikipedia talk:Manual of Style/Dates and numbers#Proposal: End "date-forking" into different styles for publication and access/archive in same cite
 — 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)

@Emir of Wikipedia: 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 <ref>{{cite book/journal/etc|...}}</ref>, 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 {{cite journal}} 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 your statements regarding cs1|2 journal volume-issue-pagination / identifier style. But, since you did not take up 'notation' with your 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. ♦ 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:

2. Baker, R.W., Knox, J.C., Lively, R.S., and Olsen, B.R., 1998, Evidence for early entrenchment of the upper Mississippi River valley, in Patterson, C.J., and Wright, H.E., Jr., eds., Contributions to Quaternary Studies in Minnesota: Minnesota Geological Survey Report of Investigations 49, p. 113–120.

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".) ♦ 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. ♦ 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 "{{cite journal|...}} Theorem 4, p. 29." or "{{cite journal|...}} See in particular p. 29." —David Eppstein (talk) 20:54, 30 July 2018 (UTC)

"See <whatever> in {{cite xxx}}" 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? ♦ 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.) ♦ 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 |ref=harv line when using CS1 templates. Which is certainly easy enough. And see also the #Proposal: make ref=harv the default for CS1 discussion above about having "ref" default to "harv" for CS1 templates. Or just use {{citation}}, where "ref=harv" is already the default. ♦ J. Johnson (JJ) (talk) 21:48, 31 July 2018 (UTC)

{{Harv}} and |ref=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 <ref>...</ref> with a cite template in it. If {{cite xxx}} 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 <ref>...</ref> 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. ♦ 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. ♦ 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 |pages=1-15 renders as 1–15, rather than 1-15, so should |issue=1-2 render as 1–2, rather than 1-2. Headbomb {t · c · p · b} 14:17, 30 July 2018 (UTC)

Done in sandbox:

Cite journal comparison

Wikitext	{{cite journal|issue=3-4|journal=Journal|pages=5-6|title=Title|volume=1}}
Live	"Title". Journal. 1 (3–4): 5–6.
Sandbox	"Title". Journal. 1 (3–4): 5–6.

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:

{{cite journal/new |title=Title |journal=Journal |volume=1-2}}

"Title". Journal. 1–2.

{{cite journal/new |title=Title |journal=Journal |volume=1-2}}

"Title". Journal. 11–22.

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 |pages=3-A/|issue=3-A/|volume=3-A, e.g.

"Title". 3-A (3-A): 3-A. {{cite journal}}: Cite journal requires |journal= (help)

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:

{{cite journal |title=Title |volume=3-a |issue=3-A |pages=3-A}}

—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 (<letter(s)><hyphen><digit(s)> or <digit(s)><hyphen><letter(s)>) are not modified:

Cite journal comparison

Wikitext	{{cite journal|issue=a-3|pages=3-15|title=Title|volume=3-A}}
Live	"Title". 3-A (a-3): 3–15. {{cite journal}}: Cite journal requires |journal= (help)
Sandbox	"Title". 3-A (a-3): 3–15. {{cite journal}}: Cite journal requires |journal= (help)

Same types are:

"Title". 3–4 (a–b): 3–15. {{cite journal}}: Cite journal requires |journal= (help)

—Trappist the monk (talk) 16:14, 1 August 2018 (UTC)

@Trappist the monk: what about cases like |pages=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:

Cite book comparison

Wikitext	{{cite book|pages=3 - 6, A – C, R-S; [http://www.example.com L3 - L6], H4-H9, 3A - 6B, 15, A|title=Title}}
Live	Title. pp. 3–6, A–C, R–S, L3 - L6, H4–H9, 3A–6B, 15, A.
Sandbox	Title. pp. 3–6, A–C, R–S, L3 - L6, H4–H9, 3A–6B, 15, A.

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

Cite book comparison

Wikitext	{{cite book|pages=3 – 6, A — C, R–S; [http://www.example.com L3 – L6], 3A—6B|title=Title}}
Live	Title. pp. 3–6, A–C, R–S, L3 – L6, 3A–6B.
Sandbox	Title. pp. 3–6, A–C, R–S, L3 – L6, 3A–6B.

—Trappist the monk (talk) 12:35, 2 August 2018 (UTC)

And one last tweak: ranges of hyphenated numbers (also dot separators):

Cite book comparison

Wikitext	{{cite book|pages=3.a - 6.a, A-1 - C-5, 1-2-1-5|title=Title}}
Live	Title. pp. 3.a–6.a, A-1–C-5, 1-2–1-5.
Sandbox	Title. pp. 3.a–6.a, A-1–C-5, 1-2–1-5.

This does not fix the single hyphenated number, |page=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 |page=((1-2))

—Trappist the monk (talk) 13:45, 2 August 2018 (UTC)

Help:CS1#Pages details the simplest way: just use {{hyphen}}. Headbomb {t · c · p · b} 14:16, 2 August 2018 (UTC)

... says the editor who finds adding |ref=harv onerous. If we are looking for ease-of-typing, adding (( and )) seems easier to me than typing out the ten characters required for {{hyphen}}. This works:

{{cite book/new |title=Title |pages=3.a - 6.a, A-1 - C-5, ((1-2a)), 1-2-1-5}}

Title. pp. 3.a–6.a, A-1–C-5, 1-2a, 1-2–1-5.

—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 |issue=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 |last1=Ceesdale|first1=AB |last2=Effly|first2=DE ....
 — 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=?

{{cite book |title=Title |last1=Ceesdale |first1=AB |last2=Effly |first2=DE}}

'"`UNIQ--templatestyles-0000004A-QINU`"'<cite id="CITEREFCeesdaleEffly" class="citation book cs1">Ceesdale, AB; Effly, DE. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.aulast=Ceesdale&rft.aufirst=AB&rft.au=Effly%2C+DE&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+45" class="Z3988"></span>

{{cite book |title=Title |vauthors=Ceesdale AB, Effly DE}}

'"`UNIQ--templatestyles-0000004D-QINU`"'<cite id="CITEREFCeesdaleEffly" class="citation book cs1">Ceesdale AB, Effly DE. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.aulast=Ceesdale&rft.aufirst=AB&rft.au=Effly%2C+DE&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+45" class="Z3988"></span>

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 – without loss of actual data; i.e. render |last1=Samuels|first1=Diana R.|vanc=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 maybe, if you're lucky, will give you the full name.

Any time people convert other citation formats to Vancouver, they cost us information (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)? ♦ 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? Devine vs DeVine. 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 |name-list-format=vanc which has been in place for years. For consistency, all name-lists, author, editor, translator, interviewer are rendered in Vancouver style when |name-list-format=vanc:

{{cite book |title=Title |chapter=Chapter |last=Brown |first=Ralph B. |editor-last=Green |editor-first=A. Gardner |name-list-style=vanc}}

Brown RB. "Chapter". In van Green AG (ed.). Title.

—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 |vanc=y as a synonym? ♦ J. Johnson (JJ) (talk) 22:37, 6 July 2018 (UTC)

Or |af=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. ♦ 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 |ef=vanc, |tf=vanc, |if=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 |vanc=y, even if it just resolves to |name-list-format=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 |name-list-format=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 |vanc=y or |af=vanc or some such. I think this discussion is on hold until the following discussion ("New parameter: af") is resolved. ♦ 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 [1]. Headbomb {t · c · p · b} 18:57, 23 June 2018 (UTC)

Problematic. That particular (dead) doi (doi:10.7249/mg702wf.9#page_scan_tab_contents) 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 < and >, e.g. doi:10.1002/1097-0207(20000910/20)49:1/2<61::AID-NME923>3.0.CO;2-Y. We need to continue allowing those. —David Eppstein (talk) 20:02, 23 June 2018 (UTC)

@David Eppstein: That DOI dates from 2000, which is before 2008. @Trappist the monk:, 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 doi:10.1002/1097-0207(20000910/20)49:1/2<61::AID-NME923>3.0.CO;2-Y displays rather incorrectly... Headbomb {t · c · p · b} 16:36, 1 August 2018 (UTC)

@Trappist the monk: 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#Cross check date/year with arxiv and bibcode?

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 YYMM.#### or YYMM.#### (e.g. arXiv:1301.2341: January 2013, submission #2341)

Old style foobar/YYMM### (e.g. arXiv:alg-geom/9712032: 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

• Perlmutter, S.; et al. (1 January 1998). "Discovery of a supernova explosion at half the age of the universe". Nature. 391: 51. arXiv:astro-ph/9712212. Bibcode:1998Natur.391...51P. doi:10.1038/34124.

This would throw the bibcode date mismatch error

• Perlmutter, S.; et al. (1 January 2000). "Discovery of a supernova explosion at half the age of the universe". Nature. 391: 51. arXiv:astro-ph/9712212. Bibcode:1998Natur.391...51P. doi:10.1038/34124.

This would throw both the arxiv and bibcode date mismatch errors

• Perlmutter, S.; et al. (1 January 1994). "Discovery of a supernova explosion at half the age of the universe". Nature. 391: 51. arXiv:astro-ph/9712212. Bibcode:1998Natur.391...51P. doi:10.1038/34124.

With a |ignore-date-mismatch=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)

@Trappist the monk and Jonesey95: 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)

@Jonesey95: how about |arxiv-date-mismatch=ignore/|bibcode-date-mismatch=ignore? Headbomb {t · c · p · b} 17:22, 26 April 2018 (UTC)

@Trappist the monk: can you help here? Headbomb {t · c · p · b} 13:25, 30 April 2018 (UTC)

@Trappist the monk: can you help here? Headbomb {t · c · p · b} 21:27, 11 June 2018 (UTC)

@Trappist the monk: 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#How to see CITEREF. – Jonesey95 (talk) 11:19, 9 August 2018 (UTC)

Best practice for this citation

What would be the best way to form this citation?

{{cite web|url=http://archives.chicagotribune.com/1963/03/05/page/B11/article/irving-s-olds-u-s-steel-war-chief-is-dead|archive-url=https://www.newspapers.com/image/374753268/?terms=irving%2Bolds%2Bdead%2Bchicago|archive-date=2018|title=IRVING S. OLDS, U. S. STEEL WAR CHIEF, IS DEAD (March 5, 1963)|author=|date=|work=chicagotribune.com|accessdate=17 April 2017}} {{subscription required}}

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. -- GreenC 13:47, 10 August 2018 (UTC)

{{cite news|url=https://chicagotribune.newspapers.com/image/374753268/?terms=IRVING%2BS.%2BOLDS%2C%2BU.%2BS.%2BSTEEL%2BWAR%2BCHIEF%2C%2BIS%2BDEAD|title=Irving S. Olds, U. S. steel war chief, is dead |author=|date=March 5, 1963|work=Chicago Tribune|accessdate=10 August 2018|subscription=yes |p=49 |via=Newspapers.com}}

"Irving S. Olds, U. S. steel war chief, is dead". Chicago Tribune. March 5, 1963. p. 49. Retrieved 10 August 2018 – via Newspapers.com. {{cite news}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)

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 {{dead link}} tag? -- GreenC 14:34, 10 August 2018 (UTC)

Would this work, or would having an external link in the via field be undesirable?

{{cite web|url=http://archives.chicagotribune.com/1963/03/05/page/B11/article/irving-s-olds-u-s-steel-war-chief-is-dead|via=[https://www.newspapers.com/image/374753268/?terms=irving%2Bolds%2Bdead%2Bchicago]|title=IRVING S. OLDS, U. S. STEEL WAR CHIEF, IS DEAD (March 5, 1963)|author=|date=|work=chicagotribune.com|accessdate=17 April 2017}} {{subscription required}}

"IRVING S. OLDS, U. S. STEEL WAR CHIEF, IS DEAD (March 5, 1963)". chicagotribune.com. Retrieved 17 April 2017 – via [2](subscription required). {{cite web}}: External link in |via= (help) Laatu (talk) 14:59, 10 August 2018 (UTC)

I think the |via= is a plain text field, not for URLs. -- GreenC 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. ♦ J. Johnson (JJ) (talk) 23:06, 13 August 2018 (UTC)

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