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. |
Archive 40 | ← | Archive 45 | Archive 46 | Archive 47 | Archive 48 | Archive 49 | Archive 50 |
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)
{{#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.{{{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}}}}
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)
|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.|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.|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)
|editors=
and |authors=
are the same so that confusion amongst editors is minimized; too much technical detail is too much technical detail.|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.|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.
|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.|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.Although |time=
is supported in {{
cite web}} (e.g.
TM4 reference #6), it is not mentioned in
Template:Cite web/doc. Could someone please update the documentation? Thanks!
GoingBatty (
talk) 02:34, 4 September 2018 (UTC)
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 CiteSeerx 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)
|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|...}}
|url=
, so I was seeing if there was a scalable fix for that class of errors. ›
Mortee
talk 07:30, 26 August 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)
{{cite book |title=Title |date=2018 |orig-year=2000}}
|orig-year=
implies previous publication. The other option:
{{cite book |title=Title |publication-date=2018 |date=2000}}
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)
{{
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). +
m
t 01:56, 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)
|arXiv=
instead of |arxiv=
.|doi=
should be disallowed, right?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)
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)
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)
Example on Jerome Guillen#Further reading:
{{
cite journal}}
: Check |doi=
value (
help); Cite journal requires |journal=
(
help)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)
|hdl=
:{{cite paper|title=Studies of the dynamics of dry-friction-damped blade assemblies|hdl=2027.42/131660}}
{{
cite journal}}
: Cite journal requires |journal=
(
help)
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? --
Green
C 18:33, 17 September 2018 (UTC)
|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)
|display-translators=
support. I'll at adding that support.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)
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)
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. -- Green C 00:05, 6 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 here, and those usually get done in a few days. We can have a mockup in the sandbox for now, and pull it down if the bug hasn't been fixed live update time. Headbomb { t · c · p · b} 23:23, 18 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)
<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)
name
attribute) is to be unique. —
SMcCandlish
☏
¢ 😼 16:14, 27 July 2018 (UTC)|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)
|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)
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)
{{
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:
Because different types of citations need to be handled differently, and presenting strong and recognizable "default" parameters names matter. What should you use to cite a book in {{
citation}}? Is is |title=
? Is that |work=
? But if |work=
is the title of a book, how can it be the title of a journal, rather than the title of the article? All of those things have answers, but they're complex. {{
cite arxiv}} makes it clear which parameters you need to use when citing an arxiv preprint, and which you don't need to bother with. Same for cite journal vs cite book.
Headbomb {
t ·
c ·
p ·
b} 19:01, 16 August 2018 (UTC)
{{
citation}}
template. It seem to me that you are suggestion it is easier for an inexperienced template user to decide first on what it is that they are citing and then choose an appropriate template. I suggest is is simpler to have one template and one set of documentation (if needs be a table of what to use for what would be appropriate). The problem for editors new to citation templates is not the obvious case, but the one on the edge. For an online dictionary should one use {{
cite book}}
{{
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 we have:
parameter=<em>Foo</em> {{sc|Bar}} [[Baz]]
?— SMcCandlish ☏ ¢ 😼 15:24, 27 July 2018 (UTC)
[[target|label]]
) or just the target portion (if in the form [[target]]
).{{
'}}
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.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.<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.|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.{{
'}}
and {{
's}}
are being filtered out, might want to do that with {{
"'}}
, 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.<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.<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.<code>...</code>
in titles of various technical citations; some of them are difficult to interpret without it.
, –
, 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)
|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=
.{{
"'}}
and the like in cs1|2 templates; Module:Citation/CS1 has built-in kerning<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 topicIt'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)
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)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.
{{
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.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. |
Archive 40 | ← | Archive 45 | Archive 46 | Archive 47 | Archive 48 | Archive 49 | Archive 50 |
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)
{{#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.{{{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}}}}
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)
|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.|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.|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)
|editors=
and |authors=
are the same so that confusion amongst editors is minimized; too much technical detail is too much technical detail.|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.|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.
|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.|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.Although |time=
is supported in {{
cite web}} (e.g.
TM4 reference #6), it is not mentioned in
Template:Cite web/doc. Could someone please update the documentation? Thanks!
GoingBatty (
talk) 02:34, 4 September 2018 (UTC)
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 CiteSeerx 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)
|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|...}}
|url=
, so I was seeing if there was a scalable fix for that class of errors. ›
Mortee
talk 07:30, 26 August 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)
{{cite book |title=Title |date=2018 |orig-year=2000}}
|orig-year=
implies previous publication. The other option:
{{cite book |title=Title |publication-date=2018 |date=2000}}
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)
{{
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). +
m
t 01:56, 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)
|arXiv=
instead of |arxiv=
.|doi=
should be disallowed, right?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)
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)
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)
Example on Jerome Guillen#Further reading:
{{
cite journal}}
: Check |doi=
value (
help); Cite journal requires |journal=
(
help)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)
|hdl=
:{{cite paper|title=Studies of the dynamics of dry-friction-damped blade assemblies|hdl=2027.42/131660}}
{{
cite journal}}
: Cite journal requires |journal=
(
help)
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? --
Green
C 18:33, 17 September 2018 (UTC)
|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)
|display-translators=
support. I'll at adding that support.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)
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)
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. -- Green C 00:05, 6 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 here, and those usually get done in a few days. We can have a mockup in the sandbox for now, and pull it down if the bug hasn't been fixed live update time. Headbomb { t · c · p · b} 23:23, 18 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)
<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)
name
attribute) is to be unique. —
SMcCandlish
☏
¢ 😼 16:14, 27 July 2018 (UTC)|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)
|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)
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)
{{
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:
Because different types of citations need to be handled differently, and presenting strong and recognizable "default" parameters names matter. What should you use to cite a book in {{
citation}}? Is is |title=
? Is that |work=
? But if |work=
is the title of a book, how can it be the title of a journal, rather than the title of the article? All of those things have answers, but they're complex. {{
cite arxiv}} makes it clear which parameters you need to use when citing an arxiv preprint, and which you don't need to bother with. Same for cite journal vs cite book.
Headbomb {
t ·
c ·
p ·
b} 19:01, 16 August 2018 (UTC)
{{
citation}}
template. It seem to me that you are suggestion it is easier for an inexperienced template user to decide first on what it is that they are citing and then choose an appropriate template. I suggest is is simpler to have one template and one set of documentation (if needs be a table of what to use for what would be appropriate). The problem for editors new to citation templates is not the obvious case, but the one on the edge. For an online dictionary should one use {{
cite book}}
{{
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 we have:
parameter=<em>Foo</em> {{sc|Bar}} [[Baz]]
?— SMcCandlish ☏ ¢ 😼 15:24, 27 July 2018 (UTC)
[[target|label]]
) or just the target portion (if in the form [[target]]
).{{
'}}
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.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.<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.|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.{{
'}}
and {{
's}}
are being filtered out, might want to do that with {{
"'}}
, 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.<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.<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.<code>...</code>
in titles of various technical citations; some of them are difficult to interpret without it.
, –
, 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)
|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=
.{{
"'}}
and the like in cs1|2 templates; Module:Citation/CS1 has built-in kerning<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 topicIt'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)
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)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.
{{
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.