Help talk:Citation Style 1/Archive 47

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

I'm looking at rewriting an existing custom citation template ({{cite act}}) to instead use Module:Template wrapper plus one of the CS1 templates for most of its functionality. The "custom" parts of it look, so far, mostly to be a couple of custom parameters that need to be concatenated to form the |title= of one of the CS1 templates. However, one of those custom inputs is a date, and that date will form part of the title rather than be output as a separate date field like the CS1 templates do.

An example of such a title just for context (grey background marks each variable): Annex II, Directive No. 2000/13/EC of 20 March 2000

So what I would like to achieve is to appropriate most of CS1's date handling (parsing, validation, date-format formatting) on the input side, including forcing |df=dmy, but then to get that date back so I can stuff it into the |title=.

Would it be feasible to #invoke: something somewhere in Module:Citation/CS1/Date validation to do that, before doing the concatenation and then handing it off through Module:Template wrapper to {{cite web}} or {{cite book}} or something? --Xover (talk) 08:58, 1 September 2018 (UTC)

Module:Citation/CS1/Date validation does not support {{#invoke:}} – it was never intended for such use. One can require() it from another module. For validation, the calling module must construct a table of tables from the parameters in the {{#invoke:}} (date value and parameter name) and handle the returned values. For date reformatting, the values in the table of tables are modified so the {{#invoke:}} must extract the modified date and return it.

All of this is, of course, doable Have you considered using the time parser function? This will take {{{date|}}} in mdy and ymd and return dmy (if the input date isn't too badly mangled – in which case it will return an error message):

{{#iferror:{{#time:j F Y|September 1, 2018}}|do something about the error|{{#time:j F Y|September 1, 2018}}}}

1 September 2018

—Trappist the monk (talk) 10:25, 1 September 2018 (UTC)

require() on Module:Citation/CS1/Date validation does sound a bit excessive for the purpose, at least as a first approach. I'll take a look at using the parser function, I think, and check with the template's author (I'm just trying to help out) what the specific requirements for validation and error handling are. Thanks! --Xover (talk) 10:52, 1 September 2018 (UTC)

Is there a parameter in the citation templates for an editorial committee as opposed to a list of editors? This is needed for citing the Flora of North America, for instance, whose editors are given as "Flora of North America Editorial Committee" on their How to Cite page; see Template:eFloras for examples.

The template is currently using |editors=, but use of that is discouraged according to the documentation, and triggers a (normally hidden) maintenance message, which I wasn't aware of till now. User-duck changed this to |editor= because of the maintenance message, but the documentation says that is meant to be used for a single editor's name, so that seems like a fudge, like when someone uses |author= for an organization or a website name, or uses |first= for the first word in a list of authors and |last= for the rest of the list.

Why or in what sense is |editors= discouraged? My impression is that it is discouraged because |editor1=, |editor2=, etc. (or |editor1-first=, |editor1-last=, etc.) should be used instead. But it seems like it seems a better place to put an editorial committee, so it shouldn't be discouraged in the case of the Flora of North America. — Eru·tuon 07:32, 31 August 2018 (UTC)

The "s" in |editors= suggests that a list follows, which is discouraged in preference to separate identification of each editor. I don't see what is wrong with |editor=Flora of North America Editorial Committee. Peter coxhead (talk) 07:36, 31 August 2018 (UTC)

|editors= and |authors= (and aliases) are discouraged because the values assigned to these parameters are not made part of the template's COinS metadata. COinS does not have list-of-names key/value pairs to match these parameters so cs1|2 would need to somehow decode the free-form list of names to extract the individual names from the list; an onerous task because our editors can be wildly inconsistent when it comes to writing lists of names.

I guess it depends on which side of the common-language barrier you stand whether 'committee' is singular or plural. As I understand it, using British English: 'the committee are deciding', 'the committee have decided'; but in American English: 'the committee is deciding', 'the committee has decided'.

—Trappist the monk (talk) 10:18, 31 August 2018 (UTC)

@Trappist the monk: actually either are fine in British English and are used depending on the context. Peter coxhead (talk) 19:09, 31 August 2018 (UTC)

Well, I don't think the issue is whether committee is grammatically singular or plural, but whether it refers to a single editor or a group of editors. In this case, it must be a group, or they would have been able to list individual editor names.

To me (and I'm from the US), when |editor= is used and no authors have been provided, it's strange to have "(ed.)" rather than "(eds.)" tacked on to "Flora of North America Editorial Committee", because a committee is not an editor. (That's the only difference in output between the two parameters that I can spot.) Maybe I'm being too semantically restrictive about "editor", but it usually means a single person. But there aren't all that many articles without author names, and authors should generally be provided since usually the template is used to cite a specific treatment in the flora.

I'm not seeing the editorial committee in the COinS metadata even if |editor= is used, which surprises me: does the module have a way of determining that "Flora of North America Editorial Committee" is not a person's name? — Eru·tuon 19:25, 31 August 2018 (UTC)

I am also in the US and for me 'Flora of North America Editorial Committee' is a singular entity so 'ed.' is appropriate; for 'Members of the Flora of North America Editorial Committee': multiple entities so 'eds.' is appropriate. No doubt this is an issue that may never be resolved to the satisfaction of everyone so I'm done talking about it.

You don't see editors listed in the metadata because they aren't there; COinS does not have a key/value pair for editors. The rules for |editors= and |authors= are the same so that confusion amongst editors is minimized; too much technical detail is too much technical detail.

—Trappist the monk (talk) 18:36, 1 September 2018 (UTC)

Okay. I'll put editorial committees in |editor= from now on, and I've updated the documentation. — Eru·tuon 19:08, 1 September 2018 (UTC)

There are two parameters that allow lists (and are not discouraged), |veditors= and |vauthors=. They are intended for journal cites but I have successfully used them for book cites. They have a rigid syntax and only allow a limited character set which I believe allows the list to be parsed and separated for COinS metadata. This feature may be useful for committees and collaborations: "enclose corporate or institutional names in doubled parentheses". I have not used this but may give it a try on an article that I recently did maintenance.

—User-duck (talk) 16:20, 31 August 2018 (UTC)

Observation: The |editor= (and aliases) do not always add (ed.) or (eds.) to the list of names. Hopefully this complies with the citation styles but it is not consistent.

• Hatting J (1950). "Valgdeltagelsen efter 1866". In Fabricius K, Frisch H, Hjelholt H, Mackeprang M, Møller A (eds.). Den Danske Rigsdag 1849-1949 bind III - Rigsdagen og folket (in Danish). Copenhagen: J. H. Schultz Forlag. p. 89.
• Hatting J (1950). Fabricius K, Frisch H, Hjelholt H, Mackeprang M, Møller A (eds.). Den Danske Rigsdag 1849-1949 bind III - Rigsdagen og folket (in Danish). Copenhagen: J. H. Schultz Forlag. p. 89.
• Fabricius K, Frisch H, Hjelholt H, Mackeprang M, Møller A, eds. (1950). "Valgdeltagelsen efter 1866". Den Danske Rigsdag 1849-1949 bind III - Rigsdagen og folket (in Danish). Copenhagen: J. H. Schultz Forlag. p. 89.
• Fabricius K, Frisch H, Hjelholt H, Mackeprang M, Møller A, eds. (1950). Den Danske Rigsdag 1849-1949 bind III - Rigsdagen og folket (in Danish). Copenhagen: J. H. Schultz Forlag. p. 89.

I just noticed that the author name was changed to Vancouver style. Another surprise!

—User-duck (talk) 16:20, 31 August 2018 (UTC)

The examples that you give are working as they should do.

Using |veditors=((Editing Committee)) will 'work' (prevents the name from being rendered as 'Editing C') but, is rather the long-way-round to get the same result as |editor=Editing Committee and, as you note, will force the names in the author-list (if using |first= and |last=) to be rendered in

Vancouver style

; this too, is how the template is intended to work – editors should not be writing templates with different name-list styles.

—Trappist the monk (talk) 16:56, 31 August 2018 (UTC)

Thanks Trappist the monk for the verification. I do not want to study the various citation styles.

Changing the author list to

Vancouver style is undocumented and was unexpected, but it makes sense. I have not "written" a template, I "use" them trying to be consistent. I have edited a few templates trying to fix "errors" (e.g. Template:eFloras, now reverted). This |editors= vs. |editor= discussion is virtually moot since it does not effect the output of Template:eFloras

. But who knows what might happen in the future.

—User-duck (talk) 18:09, 31 August 2018 (UTC)

Well, there's one difference: the module tacks on "(eds.)") for |editors= and "(ed.)" for |editor= if no authors have been provided. — Eru·tuon 19:25, 31 August 2018 (UTC)

Although |time= is supported in {{

It looks like changing from |url= to id={{citeseerx}} (example) or |citeseerx= (example) causes errors because the |access-date= no longer has a |url=. Since the source is online and the citation has a link in it, should something be changed so that this doesn't show as an error, or should there be no access-dates because CiteSeer^x is stable enough that knowing when the link worked isn't helpful? If the latter, might fixing these cases be a job for CitationCleanerBot and are there other ID types (|JSTOR=?) that should be handled the same way? CC Gene Wilson who's also interested in clearing Category:Pages using citations with accessdate and no URL › Mortee _talk 10:16, 25 August 2018 (UTC)

Oh, this again. |access-date= applies to ephemeral sources; those sources that have a good likelihood of changing over time; it does not apply to named identifier links; see Help:Citation_Style_1#Access_date. cs1|2 supports |citeseerx= so you should be using that instead of |id={{citeseerx|...}}

—Trappist the monk (talk) 11:35, 25 August 2018 (UTC)

Great, thanks. I'll check in with the bot on its talk page. › Mortee _talk 12:17, 25 August 2018 (UTC)

Incidentally, I've found in spot-checking that a lot of the citeseerx ids used in Wikipedia citations violate

WP:ELNEVER. Whenever you add a link of this type you should look at where citeseerx found the paper (listed on citeseerx's metadata page for the paper) and make sure that it's either an open-access official publisher source, a properly licensed copy on a preprint server like arxiv or institutional repository, or a copy from the author's own web site. Copies that citeseerx grabbed from other sites, for instance on class reading lists of classes whose instructor is not an author, may meet the strict legal requirements for fair use on those sites but do not meet Wikipedia's standards for when we allow links to fair-use copies of copyrighted material. —David Eppstein (talk

) 05:27, 26 August 2018 (UTC)

@David Eppstein: good to know. I'm not adding these links at all, just working through access-date errors from Category:Pages using citations with accessdate and no URL. This case happened to have a working link already, by way of CiteSeerx rather than |url=, so I was seeing if there was a scalable fix for that class of errors. › Mortee _talk 07:30, 26 August 2018 (UTC)

(Today a bot came online doing just that for various cases User:GreenC bot/Job 5. It's causing trouble with {{cite news}} templates, but it's solving the sort of case I mentioned.) › Mortee _talk 23:27, 5 September 2018 (UTC)

I don't see a way to indicate in the citation that a book or an article was published posthumously. Is there guidance on this? Abductive (reasoning) 11:58, 1 September 2018 (UTC)

Is it necessary? If you are citing a published source that you consulted, isn't all that is needed is to include the publication date of that source so that readers may locate a copy of that source that you consulted?

Still, if this is somehow necessary, there are a couple of options:

{{cite book |title=Title |date=2018 |orig-year=2000}}

Title. 2018 [2000].

but that is a bit problematic because |orig-year= implies previous publication. The other option:

{{cite book |title=Title |publication-date=2018 |date=2000}}

Title (published 2018). 2000.

which can be taken to mean written 2000, published 2018.

—Trappist the monk (talk) 12:29, 1 September 2018 (UTC)

Whether the publication was posthumously is not a question for citations. If you absolutely must indicate the text was written posthumous e.g. in the context of a general reference, just include that fact before or after the use of the citation template. --Izno (talk) 13:14, 1 September 2018 (UTC)

Written posthumously would certainly be something to note. But likely you mean published. Which could be significant for the source, but, as you say, not a matter for citation. Depending on how important that is it might even be mentioned in the text. ♦ J. Johnson (JJ) (talk) 19:30, 6 September 2018 (UTC)

We need a new option for |url-access=. The current options don't cover the issue of when a user is prevented from seeing a reference because they are in the wrong region, it's happened to me a couple of times now, with US based sites blocking users from the EU. Something like |url-access= region_locked is needed to cover this problem. - X201 (talk) 16:10, 6 September 2018 (UTC)

IMO too many complications and maintenance issues. It's easy to say a site is blocked today (from your perspective), it's hard for someone else to go back and regularly verify the blocks are still live (for your perspective). Do we track blocks between China and Taiwan in which case most articles on these countries have block notices? Blocks can be transitory coming and going by human decree (Turkey and Russia perennial frenemies), and also sometimes it's not a block but a technical problem mistaken as a block (site down, network outage). -- GreenC 17:21, 6 September 2018 (UTC)

That's what |url-access=limited is for. Unless of course, the block is not from the journal, but rather the country. In which case that's something unrelated to |url-access=.

b

} 19:38, 6 September 2018 (UTC)

{{citation}} and {{cite journal}}'s |osti= parameter expands to an outdated external URL, and should be updated to https://www.osti.gov/biblio/$1. This change has already been applied to {{OSTI}} and OSTI article ID (P3894). +mt 01:56, 13 September 2018 (UTC)

Fixed in the sandbox. "Cataracts induced by microwave and ionizing radiation". Survey of Ophthalmology.

OSTI 6071133

.

--Izno (talk) 03:25, 13 September 2018 (UTC)

I have noticed that cs1|2 supports |ASIN-TLD=. With the exception of |url= the only parameter names that may be uppercase are the named identifiers (DOI, PMC, etc); |ASIN= among them. However, |asin-tld= is not an identifier but rather, is an identifier modifier. For this reason, I propose to deprecate and then remove |ASIN-TLD= support.

Objections?

—Trappist the monk (talk) 14:07, 22 August 2018 (UTC)

• Not really, although ASIN-tld might make sense... and at this point that's pretty close to ASIN-TLD. But it's not actually used anywhere [1], so whatever.
  b
  } 14:23, 22 August 2018 (UTC)
• In English, it is normal for acronyms and initialisms to be written in all caps. ASIN-TLD is an initialism (to be pedantic, two initialisms separated by a hyphen), and hence, all caps is normal style. – Jonesey95 (talk) 17:10, 22 August 2018 (UTC)

  I suppose that, were we being truly pedantic, and applying English grammar rules to all parameter names, then none would be hyphenated; those parameters that are proper names would needs be spelled with appropriate capitalization – |arXiv= instead of |arxiv=.

  DOI is an initialism so, by what I understand is your rule, |doi= should be disallowed, right?

  We have tests in Module:Citation/CS1 that take an unrecognized parameter, convert it to lowercase and, if that proves to be a valid parameter name, emits a suggested-parameter error message specifying the lowercase version.

  —Trappist the monk (talk) 12:03, 23 August 2018 (UTC)

there having been no further discussion, |ASIN-TLD= is deprecated.

—Trappist the monk (talk) 10:42, 15 September 2018 (UTC)

Links such as https://www.npr.org/sections/thetwo-way/2014/04/21/305688602/alaska-oks-bill-making-native-languages-official currently redirect to an interstitial https://choice.npr.org/index.html?origin=https://www.npr.org/sections/thetwo-way/2014/04/21/305688602/alaska-oks-bill-making-native-languages-official at least for EU users. Why not rewrite all of them to the lightweight version https://text.npr.org/s.php?sId=305688602, which seems preferable from all perspectives for all our users anywhere? Getting the 9 (?) digit ID from the full URL seems easy. --Nemo 10:53, 10 September 2018 (UTC)

Because that is not the function of these templates. You can modify the links in wikisource by writing an awb or similar-tool script or by building a bot to do that.

—Trappist the monk (talk) 11:13, 10 September 2018 (UTC)

The NYT had something like this for years, then it didn't work and we were left having to convert to the long form. Of course the opposite can also occur from long to short. Probably best not fix until broken. -- GreenC 12:52, 10 September 2018 (UTC)

Yes, which is a good reason to avoid making such changes in the wikitext when they can be handled centrally by the template. --Nemo 15:07, 15 September 2018 (UTC)

It's not in this template's domain to change the provided URL. Basically, it's out of scope. --Izno (talk) 15:33, 15 September 2018 (UTC)

Agreed regarding "don't fix what isn't broken". Interstitial suck, but they aren't the end of the world. --Izno (talk) 15:47, 10 September 2018 (UTC)

The links *are* broken. The interstitial goes to the main page https://text.npr.org/ . --Nemo 15:07, 15 September 2018 (UTC)

The links above are not broken for me, whether via the direct interstitial link you provided or the link directly to the news source. You may have some tool or extension which is preventing you from using the link meaningfully. --Izno (talk) 15:33, 15 September 2018 (UTC)

Can you clarify what you're doing? Do you click "Decline and visit plain text site" and end up on the right page? From the HTML it's hard to see how you could get such a result: <a class="user-action user-action--text" id="textLink" href="https://text.npr.org">Decline and Visit Plain Text Site</a> (and I don't see any JavaScript redirection either). --Nemo 12:05, 16 September 2018 (UTC)

Well, I missed that you are seemingly in the EU. Friday I was actually able to visit the interstitial but today I'm automatically redirected (I'm not sure I have ABP at work currently--might be the reason). For the interstitial, I did not see any option to access the plain text link, only to proceed to the article (or the other alternative to leave the page I think). Either way, I've found that one way to work around this kind of issue is to access the same page on archive.org, for which we have good reason to provide a link anyway. I usually use this kind of thing to get around registration/pay walls. --Izno (talk) 14:29, 16 September 2018 (UTC)

What would be the appropriate property for a doc reference in the UK National Archives. This is an example of the the ref:[2] scope_creep (talk) 21:57, 9 September 2018 (UTC)

@Scope creep: I'm not sure anyone understands your question. Perhaps {{cite document}} will help you? --Izno (talk) 14:33, 16 September 2018 (UTC)

Would it not be useful to have a parameter "Wikidata" as an identifier? We now have OCLC, ISBN, doi, jstor, etc. etc. but not an easy way to link to the Wikidata-item (if any exists). It would be of great help, for instance, to directly check if a text, or info about a text, is available anywhere on Wikipedia/Wikisource etc. --Dick Bos (talk) 05:07, 12 September 2018 (UTC)

@Dick Bos: You may want to search the archives, as your suggestion has been talked about before. --Izno (talk) 14:31, 16 September 2018 (UTC)

@Izno: Thank you very much for this suggestion. I found this and this discussions. If I understand things well, I can use the parameter "id={{Wikidata|Q38197781}}", if I want to link to Wikidata. Am I right? --Dick Bos (talk) 07:44, 17 September 2018 (UTC)

Example on Jerome Guillen#Further reading:

This works as expected, but gives the Check |doi= value warning because the Handle does not start with the DOI-specific 10.NNNN prefix. Is there a preferred solution for this, and where would be the best place to document the solution? —Sladen (talk) 10:25, 17 September 2018 (UTC)

Use the correct identifier; in this case |hdl=:

{{cite paper|title=Studies of the dynamics of dry-friction-damped blade assemblies|hdl=2027.42/131660}}

"Studies of the dynamics of dry-friction-damped blade assemblies".

hdl:2027.42/131660. {{cite journal}}: Cite journal requires |journal= (help

)

—Trappist the monk (talk) 10:45, 17 September 2018 (UTC)

Example. My bot does fix. They are somewhat common, editors are often misinformed about how to add archives. Is there a tracking category to find when the |url= contains a web archive URL? -- GreenC 18:33, 17 September 2018 (UTC)

This may not actually be a mistake - if the archive page is where the editor has originally seen the content.Nigel Ish (talk) 18:49, 17 September 2018 (UTC)

Archive.org in |url= is occasionally correct; for example magazines archived there. --Izno (talk) 20:03, 17 September 2018 (UTC)

At On Horsemanship I tried to change "Various translators" to "Ashley Cooper et al" only to find "et al" was removed. I can't add all translators because they're not all credited in the source (there are four credited plus "and others"). The error from adding explicit "et al" says to use |display-authors= instead, but that has no effect. There is a |display-editors= parameter for editors, but no |display-translators=. Is there any particular reason for this? Hairy Dude (talk) 13:37, 18 September 2018 (UTC)

Relative lack of need. As far as I know this one cs1 template is the only one that has required |display-translators= support. I'll at adding that support.

—Trappist the monk (talk) 15:12, 18 September 2018 (UTC)

Under the Parameters > COinS heading the help template states that:

COinS metadata is created for these parameters

...

any of the named identifiers (|isbn=, |issn=, |doi=, |pmc=, etc)

— https://en.wikipedia.org/wiki/Template:Cite_techreport

It was not clear to me where to look for a full list of these identifiers (in my case I had a SKU ID and wanted to check if there was a parameter for this).

I think a link to Help:CS1_errors would suffice? The help template is protected though, so I can't add the link. Does this seem like a good addition?

VeraqueVeritas (talk) 19:35, 20 September 2018 (UTC)

That same template page:

§Identifiers

.

—Trappist the monk (talk) 22:07, 20 September 2018 (UTC)

This category has been processed by User:GreenC bot/Job 5 per previous discussion. There's not much else that can effectively be done by bot. Per the RFC from 2013, the bot has fixed "resolvable instances" or a little over 50%. Recommend the remainder display a red notice, to manually find and fix. -- GreenC 00:05, 6 September 2018 (UTC)

Yes! I concur. The other two error categories should also be unhidden:

Category:Pages using citations with format and no URL

Category:Pages using web citations with no URL

—Trappist the monk (talk) 00:35, 6 September 2018 (UTC)

Absolutely support all three messages being enabled. Thank you so much, GreenC, for finally taking on this task. Having a bot run through the category was a necessary condition for enabling the error message. – Jonesey95 (talk) 03:56, 6 September 2018 (UTC)

I'd only support enabling those if we

b

} 17:35, 16 September 2018 (UTC)

Until Citation bot has the long list of bugs fixed and has been well tested to determine how useful it is in this scenario of missing URLs, I wouldn't support that proposal. In the meantime, that proposal shouldn't hold up this one as they are not dependent on one another. The community shouldn't have the warning messages withheld, they can begin fixing the problems immediately the old fashioned way. -- GreenC 14:20, 18 September 2018 (UTC)

It works fine in those cases. Only case we need to handle differently are those with {{

b

} 14:37, 18 September 2018 (UTC)

The bot doesn't limit itself to the cites it can fix error-free. Also, not a fan of inline bot/tool advertisement, it opens a can of worms. Anyone else want their bots/tools to have inline adds? If the tool was well established and working without many errors and could fix most cases maybe it would be different. -- GreenC 20:17, 18 September 2018 (UTC)

1) We already do it for {{

b

} 20:39, 18 September 2018 (UTC)

Is there a testcase page that demonstrates the bot is working correctly and is able to make fixes for this? What percentage of cases is it able to fix est.? -- GreenC 21:26, 18 September 2018 (UTC)

I set one up... but the bot failed to do anything. Either there's a regression, or I was confusing this with an AWB functionality. I filed a bug report at

Yeah I'd like to see you approve enabling the warning messages, show evidence that the bot works, and then see if the community supports adding it to the sandbox. I'm still not convinced it's a good idea, but maybe you can convince me. -- GreenC 01:29, 19 September 2018 (UTC)

Support enabling all three error messages. And I agree with GreenC regarding the orthogonal issue of a link to Citation bot. --Xover (talk) 17:54, 19 September 2018 (UTC)

unhidden in /sandbox.

—Trappist the monk (talk) 10:55, 23 September 2018 (UTC)

This section is related to the above thread, #Proposal: make ref=harv the default for CS1.

I assert that the present use of periods vs. commas as separators in templated citations evolved over time, and a discussion of what pattern would be most pleasing, with an audience of those who used or developed {{citation}} and those who used or developed the cite xxx family of templates has never happened.

I suggest that if such a discussion had occurred before thousands (or is it millions) of these templates were in place, the consensus would have been something like the following.

External style guides such as APA style and The Chicago Manual of Style usually use the comma as the field separator in footnotes and endnotes (hereinafter called endnotes because Wikipedia articles are not divided into pages, in the sense that pages exist in paper books and journals). Many of these styles, such as APA style, do not provide for endnotes at all; only parenthetical references to an alphabetical list of works cited are provided for.

In external style guides, the entries in the alphabetical list of works cited use periods as the field separator.

It is less jarring for Wikipedia to follow external customs to the extent possible. Therefore, articles that only use endnotes should use the {{citation}} template, or if that template does not work well with a particular source, the appropriate member of the cite xxx template with |mode=cs2 set. If this advice were followed, most invocations of {{citation}} would have no need for the anchor.

Articles that use an alphabetical list of works cited would use the period as the field separator and parenthetical citations would use the cite xxx family and would need |ref=harv or a manually set ref value on every entry in the list.

Articles that use numbered citations generated with {{sfn}}, which in turn link to an alphabetical list of works cited, would use a comma as a separator in the numbered citations (e.g. "Howse 1997, ch. 4.", with "Howse 1997" being a link). These articles would use the period as the field separator in the list of works cited, and would need |ref=harv or a manually set ref value on every entry in the list. Jc3s5h (talk) 16:38, 26 July 2018 (UTC)

This proposal appears to force the use of one particular citation format, (i.e. CS2) and is completely against the spirit of WP:CITEVAR, which does not even specify that templates be used. Nigel Ish (talk) 17:08, 26 July 2018 (UTC)

If I've reignited any sectarian struggles here, please slap me with several trouts as needed. That wasn't my intent (as I hoped was obvious from my flippant phrasing on the issue). But so that it's clear where I stand, to the degree that's relevant, I cannot quite bring myself to care about what punctuation to use or the specific order of various bibliographic details within a full citation, or other such minor formatting issues. I do care quite strongly about short inline citation + alphabetical list of full references (aka. a bibliography), and that the two should be linked (or at least linkable). I also believe parentethical referencing (i.e. without <ref>...</ref> tags) should be actively avoided. I also believe

WP:CITEVAR as it stands saves us from a lot of drama in the short and medium term, but that it's possible the reverse is true in the longer term. In any case, I truly believed my proposal above was independent of the "preferred citation style" issue, and I still don't see how making |ref=harv the default intersects with that issue. Or have I missed some faction that actually argues that {{cite book}}/{{cite journal}} without |mode=cs2 should be actively forbidden in works cited / bibliography lists (i.e. that they should be explicitly unlinkable)? --Xover (talk

) 17:42, 26 July 2018 (UTC)

"I also believe

WP:CITEVAR as it stands saves us from a lot of drama in the short and medium term, but that it's possible the reverse is true in the longer term." – This isn't even in doubt. It's already come true. But it will have to get much worse before the community will find the will to do anything about it.  — SMcCandlish ☏ ¢

 😼  16:14, 27 July 2018 (UTC)

Someone in the previous discussion seems to have said that the citation template (rather than the cite x series) should be used for Bibliographies and the like for reasons (which don't appear to be error related. As far as I could see, the error seems to be to do with ref templates generating duplicate ids - which are normally solved by using mangled years (i.e. 2003a, 2003b etc) or putting something in the ref= field. The more technically knowledgeable who can decipher the technobabble in the previous discussions will presumably be able to explain things better.Nigel Ish (talk) 18:13, 26 July 2018 (UTC)

My take from the thread above this one, and the discussions linked to from that thread, is that some people think it's bad to have duplicate IDs in the same article even if they don't cause an actual ambiguity, because it's invalid HTML. These IDs are, under the covers, HTML anchors. The links generated by <ref>, {{sfn}}, and harvard citations all rely on anchors, but of these, only <ref> generated links are guaranteed to be unique.

Some folks did some counting, and found that {{citation}} tended to be used with {{sfn}} or harvard citations, so making ref=none the default for {{citation}} would create lots of problems. But cite xxx tended to not be used with {{sfn}} or harvard citations, so most of those pages didn't need ref=harv. Also, historically, ref=harv hadn't been available for cite xxx, so affectionados of those templates weren't used to paying any attention to whether IDs were unique, so changing the default to ref=harv would start generating lots of non-unique IDs that people had never thought about before. Jc3s5h (talk) 19:01, 26 July 2018 (UTC)

Seems like a rather different discussion, but yes, we should avoid duplicate IDs. The entire point of an id (even before it was ever used for anchoring – that used to only be the name attribute) is to be unique.  — SMcCandlish ☏ ¢ 😼  16:14, 27 July 2018 (UTC)

This seems a bit misguided. If I were to ask a question, it would probably be "should we continue to have two separate citation styles by default, or should one or the other be moved to the other mode by default"? You would probably get as much acrimony but would have a definitive answer to "do we actually want two" instead of this particular question... --Izno (talk) 17:35, 26 July 2018 (UTC)

In short, I favor comma as a separator in endnotes and periods as a separator in alphabetical bibliographies. Jc3s5h (talk) 17:57, 26 July 2018 (UTC)

Re your initial commentary: TLDR. As to your succinctly stated preference: sure, suit yourself. Add |mode=cs2 or |mode=cs1 as desired. However, if you are thinking of having that enforced by the software: no way! ♦ J. Johnson (JJ) (talk) 19:27, 26 July 2018 (UTC)

Either way, it's a moot point, do what the hell you prefer, and follow

b

} 19:43, 26 July 2018 (UTC)

If I were in charge, I'd merge the two styles (use comma separators and end each in a period unless |postscript=; or similar is individually set to run two citations in the same footnote), or I'd clarify that there is some sort of footnote/endnote vs. bibliography context like CMOS referencing where one style is used for one and the other style is used in the other case. Imzadi 1979 → 02:45, 27 July 2018 (UTC)

Oh crap, not this again. Unwatching -

notify me if you need me. --Redrose64 🌹 (talk

) 09:11, 27 July 2018 (UTC)

• "Do we collectively want multiple citation styles?" – possibly not. "Could we agree on one style?" – definitely not. End of subject. Peter coxhead (talk) 09:33, 27 July 2018 (UTC)

  We can, however, have the cite templates do sensible things by default. They mostly seem to already. Given the complexity, it'll never be 100% perfect by every criterion. E.g., Johnson, P.; Chan, S., eds. doesn't make much sense; Johnson, P.; Chan, S. (eds.) would be better. Yet, a string like this is usually followed by a parenthesized date, so it would result in Johnson, P.; Chan, S. (eds.) (1998), which is arguably worse that the comma-eds. situation in the original.  — SMcCandlish ☏ ¢ 😼  16:14, 27 July 2018 (UTC)

• Jc3s5h's OP premise is faulty. There is no magical split between foot/end note style and bibliography style universally, even if there is for some particular publishers. Every issuer of a citation "standard" has chosen different typography and punctuation, and they're just all in conflict. Even within a discipline, sub-disciplines may use radically different citation style (e.g. cultural anthropology and archaeology, for an example that was the bane of my undergrad years).

  The best approach for our citation style defaults is to match natural English as much as possible. A citation is a non-sentence but sentence-like clause, similar to the typical image caption or list item. Ergo, we should use commas when practical, semicolons to separate material containing its own commas; semicolons between logically more separate things (e.g. author info; title info; publisher and location info), and use other punctuation as has become conventional across many citation styles, e.g. Location: Publisher with a colon, and (YYYY) parenthesized dates. Close the entire thing with a period (full point). Taking this approach will obviate annoying typographical gaffes like "Something something. pp 12–34". And pointless "full-stopping" like a machine gun after each little bit of data.

  When I encounter unpunctuated plain-text cites, and don't feel like templating them, I do this (to make up a rather maximal example): McNabb, J. P.; Heinz, Franziska (May 2011); [URL_here "Venting of blast doors to de-vulcanize flux capacitors"]; in Bluto, Jane; Fisk, P. J. (eds.); ''Neo-Boltospherical Spectroscopy'', "Studies in Arcturophasic Spectra" series, vol. 4, revised ed., pp. 12–34; Bumswaddle-on-Dee, England: University of Chickenham; via Google Books; ISBN: whatever, DOI: whatever, OtherID: whatever; accessed: date here. The date is often in another place in the order, though; many people put it toward the end, and if I'm going to move stuff around, I might as well template it. A good case could be made for using colons between the author(s) and paper/chapter title, and between the editors(s) and periodical/edited-volume title. (This would be my logical preference, but it looks nothing like what the cite templates do, so I don't impose it.) And "accessed: date here, via Google Books" would be better, but I'm basing this off examples I encounter where GB is often mis-credited as the publisher, so I look up the real one and insert it in-place. Regardless, other than for abbreviations like initials and "pp.", there is no reason for a "." anywhere is this until the end.

  However, because of the complexity of cite templates and the way they move stuff around depending on which parameters have data, making any changes to them in such a regard would be challenging, and would require a lot of testing with different templates and different bits of present and omitted data.  — SMcCandlish ☏ ¢ 😼  16:14, 27 July 2018 (UTC)

  Would not the full stops function as stronger separators of information, like the semi-colons are doing compared to the commas? The full stops can indicate stronger relationships between the data by grouping together strings using semi-colons and commas. Basically, what I am not understanding is your opposition to the use of periods in citations outside of abbreviations and such. —Nøkkenbuer (talk • contribs) 07:56, 16 August 2018 (UTC)

• If we were to have one template for all citations eg {{citation}}, then there is no reason to stop at just 2 modes we could add in CSVCAN and scrap the dedicated vancouver templates. There can be a many styles as wanted (groan), including ones the mimic the well know external (to Wikipedia) styles. This is the major advantage of citation templates over hand-rolling citation. It would be quite easy to set the default to whatever was the most common style (at the moment CS1), but still allow the editors of the articles to override that style in an article by setting the mode parameter to something else. The point about the mode switch is it should mean that debates like the one initiated by Jc3s5h at the start of this thread become redundant. Also if there were more modes that mimicked styles like APA and CMS it might persuade of those who are anti-citation-templates to start using them, or at least not be so anti-templates. -- PBS (talk) 19:14, 16 August 2018 (UTC)

Headbomb asked me a question about only using {{citation}} in place of all the "cite ..." templates. Copied from the section #Proposal: make ref=harv the default for CS1:

To answer your question

cite encyclopaedia}} or {{cite web}}? What should an editor to use for a book on at the website of Internet Archive {{cite web}} or {{cite book}}? What about a chapter of a book at the website of Electric Scotland? Another example are the books of journals often annuals, or books of magazines which are online (something that will only grow over time); how does an editor decide whether to use {{cite book}}, {{cite journal}}, {{cite magazine}} or {{cite web}}? If there is only one template like {{citation}} then there is only one set of documentation and if a set of parameters does not seem to fit then it is relatively easy to look for ones that do. With separate templates how does one choose the most appropriate for edge case? -- PBS (talk

) 08:26, 17 August 2018 (UTC)

Is the new update in Citation/CS1 working? Adithyak1997 (talk) 19:11, 26 July 2018 (UTC)

Do you mean the 10 June 2018 update? Are you seeing something that you think is not working properly?

—Trappist the monk (talk) 00:05, 27 July 2018 (UTC)

Do we have:

1. A list of parameters affected by doing things like parameter=<em>Foo</em> {{sc|Bar}} [[Baz]]?
2. A list of exactly what kinds of markup cause these problems, and which (like HTML character entities) do not?

 — SMcCandlish ☏ ¢ 😼  15:24, 27 July 2018 (UTC)

A list of cs1|2 parameters that contribute to COinS metadata is transcluded into every cs1|2 template doc page from Template:Citation_Style_documentation#COinS.

cs1|2 templates have the responsibility to render parameter values so that citation presentation is consistent among cs1|2 templates. Because the templates have the responsibility, there should be little call for editors to add markup to cs1|2 parameters. There are exceptions to that: common wiki italic markup can / should be used in title-holding parameters to distinguish scientific names, for example. Module:Citation/CS1/COinS removes all wiki apostrophe markup from title holding parameters before the title is included in the COinS metadata. Wikilinks are permitted because Module:Citation/CS1/COinS strips off the markup and uses only the label portion of the wikilink (if in the form [[target|label]]) or just the target portion (if in the form [[target]]).

For a while, we were plagued by cs1|2 templates that had {{

'}} or {{'s

}} templates in title-holding parameters so Module:Citation/CS1/COinS strips the html stuff that results from those templates and replaces them with a single apostrophe (') or 's. No-break space ( ) entities, tab, line feed, carriage return, and hair space (U+200A) characters are each replaced with a single space character. Zero-width joiner entities (‍), zero-width joiner, zero-width space, and soft hyphen characters (except when any of these are used in Indic script text) are all stripped without replacement.

At one time, before MediaWiki broke math stripmarker handling (T121085) in Scribunto, Module:Citation/CS1/COinS could decode the various math markup and render an understandable text version (essentially, the alt= image attribute text from the image that is rendered in place of the math markup). Since MediaWiki broke it, Module:Citation/CS1/COinS now replaces math strip markers with 'MATH RENDER ERROR' text so that we don't percent encode the strip marker text which would look like gibberish to COinS consumers; of course, 'MATH RENDER ERROR' isn't very helpful to those consumers either. Perhaps someday, MediaWiki will repair the damage they have done; I'm not going to hold my breath for that.

Certainly some html markup is desirable in title-holding parameters. There are cases where the <sub>...</sub> and <sup>...</sup> tags should be used (chemical and element names, simple math text, etc). Those are currently passed into the COinS (as is any of the markup that hasn't been stripped). There may be other specific cases where html markup is desirable, but for the most part, I think that such markup should not be used in cs1|2 parameters whether those parameters are made part of COinS or not.

—Trappist the monk (talk) 18:36, 27 July 2018 (UTC)

In the same order:

• Re "transcluded into every cs1|2 template doc page" – Okay. I wanted to make sure this was the total list, and not partial (i.e., depending on which template page you're looking at, the way the rest of the documentation subtly changes).
• I'm relieved that wiki-apostrophe italics (and bold?) will work fine; what about other non-HTML-tag wiki markup? I'm not sure much would be used, but it's worth knowing for sure.
• I'm not sure I understand the links part. It seems to suggest that |chapter=[[Politics and the English Language]] and (for journal or news) |title=[[When Zombies Attack!: Mathematical Modelling of an Outbreak of Zombie Infection]], and (for book) |title=[[On the Origin of Species]] are okay, yet the templates usually seem to throw link-in-title errors about this. The more general case of |work=[[The New York Times]], and other things that resolved to |work=, like |journal= and |website=, do seem to work.
• If {{
  "'
  }}, etc. As I reported earlier, people are definitely using them in title parameters and removing them all would be a massive hassle. Being able to use them would actually make the refs material easier to read.
• "line feed, carriage return ... characters are each replaced with a single space character" has not been my experience at all; the template instead throw a loud warning about linefeeds in the title, which makes no sense to me since HTML is whitespace-agnostic.
• "of course, 'MATH RENDER ERROR' isn't very helpful to those consumers either" – True, but they're readable by us, so we can at least try to do something manually.
• "I'm not going to hold my breath for that." No kidding. I've been waiting over a decade for some basic bugs to be fixed.
• "Certainly some html markup is desirable in title-holding parameters. There are cases where the <sub>...</sub> and <sup>...</sup> tags should be used.... Those are currently passed into the COinS" – So, COinS will literally receive E=mc<sup>2</sup>? If that's not a severe problem on the COinS side, then I'm not sure what the dividing line is supposed to be.
• It would be nice if some specific HTML was stripped, namely all the presentation and semantic markup tags like <u>, <em>, <code>, etc. I see these in titles frequently. What's the process for proposing something specific? I really have little awareness of where the "guts" of this system lives and who is managing it and where.
• "I think that such markup should not be used in cs1|2 parameters whether those parameters are made part of COinS or not." Well, why? It's nice that we're supplying COinS for people who might use it, but the central purpose of our cites is for WP readers, so making the material accurate and readable for them is the no. 1 priority. I really don't like not being able to use <code>...</code> in titles of various technical citations; some of them are difficult to interpret without it.

Anyway, thanks for the clarifications so far. I'll try revising

MOS:TITLES#Typographic conformity again to better account for some of this.  — SMcCandlish ☏ ¢

 😼  19:49, 27 July 2018 (UTC)

PS: What you've said above seems to contradict the docs transcluded into Template:Citation Style documentation#COinS, in at least two (contiguous) places: "Also, HTML entities, for example  , –, etc, should not be used in parameters that contribute to the metadata. Do not include Wiki markup '' (italic font) or ''' (bold font) because these markup characters will contaminate the metadata." Is the doc simply outdated?  — SMcCandlish ☏ ¢ 😼  19:56, 27 July 2018 (UTC)

I'm shocked. Shocked! to find that the documentation sucks.

• I think that those listed parameters are all, but as noted, the documentation sucks and often lags far behind the implementation.
• yeah, bold markup is supported in cs1|2 title holding parameters though perhaps it shouldn't be. Surely we should support necessary markup, but bold in citation renderings except where applied by the template is, I think, mere decoration
• wikilinks in titles are allowed (all of those cases you illustrate will work as long as |url= is not set. MediaWiki does not know what to do if you simultaneously try to make an external link and a wikiling of the same text. When you attempt that in cs1|2, Module:Citation/CS1 links |title= with the value assigned to |url=, shows the wiki markup and an error message; You get the same results when you simultaneously set |title=, |title-link=, and |url=.
• there is no reason for editors to be using {{
  "'
  }} and the like in cs1|2 templates; Module:Citation/CS1 has built-in kerning
• those characters are removed from a copy of the parameter value before it is added to the metadata; the error message is there so that editor know to remove these extraneous characters from the wikisource
• –
• –
• yes, COinS will get the <sup>...</sup> tags. The dividing line for me is simple, legitimate, html tags; that means no styling, no attributes, no classes, etc because that stuff is presentation information for a specific application (en.wiki) which may be (likely is) inappropriate for other applications; there has been little discussion about this and no action taken except to flag a bunch of templates as inappropriate for use in cs1|2 templates; arguably, rtl languages should be have markup; there has been very little discussion on that topic
• everything related to cs1|2 from complaints to rfcs should happen here on this talk page
• it is the duty and obligation of the cs1|2 templates to style rendered citations because consistent styling is important to editors at en.wiki; for that reason, there should be no need to markup anything except titles so that these titles comply with MOS and the common renderings of mathematical, chemical, and scientific terms and names; no doubt that there are other things that might be acceptably marked up.

—Trappist the monk (talk) 20:17, 28 July 2018 (UTC)

It's fine that journal volume and issue info come out as things like "5 (11)", but this isn't appropriate for books, which should be rendered "vol. 5". The journal style doesn't even make much sense in the (frequent) case of no issue number. It's the very juxtaposition of the bold volume and the parenthetical issue that makes the format easily parseable.  — SMcCandlish ☏ ¢ 😼  16:21, 27 July 2018 (UTC)

Honestly I think we should just ditch the special, not-parsed-by-anyone-except-journal-readers, bold and parentheses and actually provide the abbreviations in all cases, as {{cite magazine}} does presently. That's somewhere on my to do list... --Izno (talk) 18:00, 27 July 2018 (UTC)

I strongly support that idea (full "vol. 5, no. 11" style) but wasn't sure I should propose it, since the academical editors around here might revolt. At bare minimum, I want it back for non-serial publications, especially books, but it should also be done for videos and some other stuff that aren't magazines, journals, or newspapers.  — SMcCandlish ☏ ¢ 😼  19:22, 27 July 2018 (UTC)

I also support the idea, firstly because its much more intuitive, and also because on Wikipedia, we are much more likely to mix references of different types in articles, so clearer and more consistent presentation is better.Nigel Ish (talk) 19:56, 27 July 2018 (UTC)

• Support for books; indifferent for journals. Art of Programming vol. III is clear, but Art of Programming III is odd. Glrx (talk) 21:11, 27 July 2018 (UTC)

"Support"? Is there a definite proposal on the table?

As an aside I remind everyone that journal volume numbers are very significant and warrant bolding, while book (and other) volumes are not always appropriately rendered with "vol." ♦ J. Johnson (JJ) (talk) 22:58, 27 July 2018 (UTC)

Well, it looks like there's two proposals: 1) implement "vol." for books and such, and 2) do that plus also implement "vol." and "no." for periodicals. I'd support the latter as first choice and former as second, though I'd only intended to propose the former.

If there's a case where a book "volume" is not expressible with "vol." then that's probably the wrong parameter, since it's not actually a volume. If there is some case where it is the right parameter and "vol." still somehow couldn't apply (examples please), then we can use a "vol." label-suppressing parameter. Easy fix. Next, being significant doesn't equate to "warrants bolding". If the "5 (11)" style is used, it seems to make sense to bold the volume there, and this style is seen in some off-site citation formats, but it is not the only style, and it's geeky, so why not just do "vol. 5, no. 11"? It's understandable to more people, is not confusing with either volume or issue don't apply, and there are no readers who prefer "5 (11)" style who are unfamiliar with or won't understand the other style, while reverse is not true.

 — SMcCandlish ☏ ¢ 😼  23:20, 27 July 2018 (UTC)

Anyone that doesn't understand how to parse "Some Journal, 5 (11)" probably isn't up to mucking around in a journal environment in the first place, so that problem hardly arises. As to "vol. 5, no. 11": why abbreviate? Why not go for the whole hog with "volume 5, number 11"? One answer: excess packaging– i.e., clutter – for the information presented. Even though we are not subject to the same space constraints as (say) a journal, full citations can get long, and succinctness is not a sin. ♦ J. Johnson (JJ) (talk) 20:34, 28 July 2018 (UTC)

You appear to be saying that anyone who doesn't have an academic background and so isn't familiar with academic reference formatting, shouldn't be looking at references at all. If references aren't for the readers, who are they for?Nigel Ish (talk) 11:48, 29 July 2018 (UTC)

No, I am not saying that, not at all, and certainly not what anyone should or shouldn't be looking at. What I am saying is that anyone doesn't understand what "5 (11)" means probably is not looking into journal references in the first place. If someone lacking an "academic background" should follow a citation back to a journal source I think most people will quickly figure out the convention. If not, then they probably also lack understanding that "no." is an abbreviation for "number" (I was a little surprised to learn that–back in the 8th grade), which is the same as "issue number" or just "issue", and perhaps we should have such abbreviations wikilinked to an explanation. ♦ J. Johnson (JJ) (talk) 21:16, 30 July 2018 (UTC)

• Support for books, not for journals, at least at this moment.
  b
  } 12:49, 28 July 2018 (UTC)
• I generally prefer fewer abbreviations, and more clarity, so would go with volume and number as first choice, vol. and no. as second choice. We want people who are not familiar with the systems to find the reference as easily as possible. · · · Peter (Southwood) ^(talk): 12:11, 29 July 2018 (UTC)

For "find[ing] the reference as easily as possible" a direct link is generalliy preferred and sufficient, and all those other niggling descriptive details can be ignored. Lacking such a link the reader will likely be faced with more daunting challenges than not having a volume number explicitly labelled as such.

BTW, please note that I am talking about journals, not newspaper or popular magazines, for which "vol." and "no." are conventional. In that regard I am fine with not "using journal style for book volumes". (And when did we start doing that?) Note also that is is precisely for the purpose of finding (within the citation) as easily possible the volume number that they are bolded. ♦ J. Johnson (JJ) (talk) 21:38, 30 July 2018 (UTC)

Journal style for book volumes was implemented at this edit to {{cite book}}, at the time, still a stand-alone template, and at this edit to {{citation/core}}, about four months later. {{Citation}} had been using {{citation/core}} for more than a year by that time.

—Trappist the monk (talk) 22:20, 30 July 2018 (UTC)

Note that cite news also uses the numbers without label style, like cite book and cite journal. Should newspapers and the like follow the cite magazine styling or the cite journal styling?Nigel Ish (talk) 17:16, 12 August 2018 (UTC)

• Support. This is so confusing on books. I suspect many put the volume in the title parameter instead, and that's not good for the metadata. Even I've done it sometimes. – Finnusertop (talk ⋅ contribs) 10:24, 25 September 2018 (UTC)
  • Putting the volume in the title can be difficult to avoid, in cases where the volume has its own separate subtitle (the Knuth example discussed above) or for when a multi-volume book is also part of a book series and has a volume number (or multiple volume numbers) in the series that are different from the numbers of volumes within the book. —David Eppstein (talk) 10:33, 25 September 2018 (UTC)