Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
  (Redirected from Template talk:Cite encyclopedia)
Jump to: navigation, search

Bug when title ends with single quote[edit]

{{Cite journal |last1=Shea |first1=Christopher |title=A Radical Anthropologist Finds Himself in Academic 'Exile' |journal=[[Chronicle of Higher Education]] |volume=59 |issue=32 |pages=A14–A15 |date=2013-04-19 |url=http://www.chronicle.com/article/A-Radical-Anthropologist-Finds/138499/ |issn=00095982 |via=[[EBSCOhost]] |df=mdy-all }}

Add |url-access=subscription:

I.e., title displays as "A Radical Anthropologist Finds Himself in Academic 'Exile<span style="padding-right:0.2em;">'"

(Not watching—please {{ping}} me with your responses.) czar 16:23, 29 June 2017 (UTC)

This discussion may be related. If the CS1 module calls Module:URL, the fix for both problems might be to modify that module. This is pure speculation, but it looks similar. – Jonesey95 (talk) 19:09, 29 June 2017 (UTC)
Not the same problem because cs1|2 does not use Module:URL.
Our problem is a conflict between the need to kern quote marks and the need to prevent the access signal from wrapping to the next line. In this simpler example you can see how we kern the opening quote mark. The closing quote mark is supposed to be similar but the access signal no-wrapping (which occurs later) interferes:
{{Cite journal |title='Title' |url=http://www.example.com |url-access=subscription}}
"'Title<span style="padding-right:0.2em;">'"Paid subscription required. 
<cite class="citation journal"><span class="plainlinks">[http://www.example.com "<span style="padding-left:0.2em;">'</span>Title<span <span class="nowrap">style="padding-right:0.2em;">'</span>"<span style="padding-left:0.15em">[[File:Lock-red-alt.svg|9px|link=|alt=Paid subscription required|Paid subscription required]]</span></span>]</span>.</cite><span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1&rft.atitle=%27Title%27&rft.genre=article&rft_id=http%3A%2F%2Fwww.example.com&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal" class="Z3988"><span style="display:none;">&nbsp;</span></span>
I'll think on it.
Trappist the monk (talk) 19:54, 29 June 2017 (UTC)
I think I have a fix; not pretty, but I think it works. There are several kerning conditions that we need to worry about. These only apply to quoted titles (journal article, website titles, etc):
  1. multi-word titles:
    1. title has leading and trailing quote marks:
      {{cite journal/new |title='multi-word title' |url=//example.com |url-access=registration}}
      "'multi-word title'"Free registration required. 
    2. title has trailing quote mark:
      {{cite journal/new |title=multi-word 'title' |url=//example.com |url-access=registration}}
      "multi-word 'title'"Free registration required. 
    3. title has leading quote mark (not an issue but proof that this form isn't broken):
      {{cite journal/new |title='multi-word' title |url=//example.com |url-access=registration}}
      "'multi-word' title"Free registration required. 
  2. single-word titles:
    1. title has leading and trailing quote marks:
      {{cite journal/new |title='title' |url=//example.com |url-access=registration}}
      "'title'"Free registration required. 
    2. title has trailing quote mark:
      {{cite journal/new |title=title' |url=//example.com |url-access=registration}}
      "title'"Free registration required. 
    3. title has leading quote mark:
      {{cite journal/new |title='title |url=//example.com |url-access=registration}}
      "'title"Free registration required. 
and OP's original:
Shea, Christopher (April 19, 2013). "A Radical Anthropologist Finds Himself in Academic 'Exile'"Paid subscription required. Chronicle of Higher Education. 59 (32): A14–A15. ISSN 0009-5982 – via EBSCOhost. 
Trappist the monk (talk) 13:44, 9 July 2017 (UTC)

Question on the use of the "language" field[edit]

Recently I've been running across instances (in English Wikipedia) of the language field being used to denote that the source is in English. E.g., "|language=english-US" and "|language=eng-GB". Is this (now) recommended? To me it seems redundant, that the field should be used to denote non-English sources. Comments? —DocWatson42 (talk) 09:36, 1 July 2017 (UTC)

Commonly an artifact of VisualEditor. cs1|2 does not render the language parameters when the only language specified in |language= is the language of the local wiki. So at en.wiki, |language=en or |language=English does not render. At one time, cs1|2 emitted an error message but because so many cs1|2 citations are exported to other wikis |language=en will be rendered and may be helpful to readers and editors there. Adding |language=en is neither recommended nor discouraged.
cs1|2 does not recognize the two examples that you give. The form for languages that cs1|2 recognizes is <ISO 639-1 code><hyphen><ISO 3166 alpha 2 country code> so: en-US, en-GB. I found and fixed four |language=eng-US but found none of the |language=eng-GB or |language=english-XX form.
Trappist the monk (talk) 11:20, 1 July 2017 (UTC)
See also Help talk:Citation Style 1/Archive 30#Misuse of language parameter. --Redrose64 🌹 (talk) 13:30, 1 July 2017 (UTC)
@Redrose64 and Trappist the monk: Ah. Thank you for the explanation. ^_^ — DocWatson42 (talk) 05:01, 16 July 2017 (UTC)

Book edition vs series edition[edit]

When both |series and |volume are specified in a book citation, it can give the impression that the edition pertains to the series name, rather than the book itself, as in:

Book Title. Book Series (4th ed.)

Is there a reason why this format is preferable to placing the edition between the book title and the series name? E.g.,

Book Title. (4th ed.) Book Series.

Ringbang (talk) 22:52, 3 July 2017 (UTC)

I have no opinion really. I will just note that the current templates render in the same way that the old templates did so the ordering decision predates the Lua implementation:
Cite book compare
{{ cite book | series=Book Series | title=Book Title | edition=4th }}
Old Book Title. Book Series (4th ed.). 
Live Book Title. Book Series (4th ed.). 
Trappist the monk (talk) 00:53, 4 July 2017 (UTC)
Book series do appear in new editions, with new identifiers. Regularly, [volume edition]=[series edition]. Conceivably, editions of individual volumes could differ from the overall series edition, but I would think this would be rare, perhaps too rare to justify changes in code. 72.43.99.138 (talk) 13:04, 6 July 2017 (UTC)
I agree with 72's conclusion, but will note stuff like The Arden Shakespeare (the series) that is currently in its third series (the series edition), where individual books in the series have multiple editions (sometimes with significant changes, like their latest edition of The Tempest). It leads to slightly awkward workarounds like concatenating the series and the series edition and using the result as the |series=The Arden Shakespeare, third series to free up |edition= for the volume edition. It's a minor issue. Slightly more annoying, but still very minor, are books with multiple volume numbers. For instance, a specific reference work published in four volumes, that also happens to belong to a series of related reference works where each overall work has a series volume number. Or works which belong to multiple series, but is a different volume in each series (one is perhaps a subset of the other: Cambridge Companions to Literature, v. 123 and Cambridge Companions to Shakespeare, v. 4). None of these issues are worth expending code over, unless it happens as part of some larger generalization of the code which happens to allow for such things to be handled where needed as a side effect. I'd be all for it, except I don't think publishers are sufficiently consistent in their usage for it to be possible to handle in any sensible way in these templates. --Xover (talk) 13:27, 6 July 2017 (UTC)
@72.43.99.138: Could you list the examples you found of series that have editions? They could make for useful test cases. After considering any test cases and the ambiguity of the current parameter order, template maintainers can assess the level of effort and the regression risk of swapping the placement of these two parameters. Trappist the monk, if you're in a position to comment on LoE and risk, that would be helpful. —Ringbang (talk) 18:14, 9 July 2017 (UTC)
Minimal for both. The most difficult task is yours: convincing others that your proposed change is worth the doing.
Trappist the monk (talk) 00:43, 10 July 2017 (UTC)
Offhand, I cannot list any examples, but I believe Xover presented some. AFAIK series volumes normally have individual ids (ISBNs) in addition to (or in the absence of) a series ISBN (or ISSN). For citation purposes, an editor can use the volume ISBN. The series info would then be a convenience. Obviously in rare (I think) cases a series may need to be cited. In that case the series identifier and edition are pertinent. None of these cases needs any changes in code, imo. 72.43.99.138 (talk) 14:43, 11 July 2017 (UTC)
The primary raised I raised the issue was that placing the edition number after the book title, rather after than the series name, seems the clearest, most conventional place for this information. Since the cost to implement is negligible, the question becomes: Is there any reason to prefer putting the edition after the series name? If we were designing this template for the first time, which would we choose? If there is no reason to prefer the post-series placement, and since the improvement is so simple and devoid of risk, why not do it? —Ringbang (talk) 15:07, 11 July 2017 (UTC)
In principle, I agree. It would be a small if …then … else routine as in the following pseudocode:
If exist book-ed. show after book-title
else
If exist series-ed. show after series-title
Assuming a proper identifier is present, do you agree that citing both a book edition and series edition would be redundant? 65.88.88.214 (talk) 17:16, 11 July 2017 (UTC)
Note that the above was proposed without examining that area of the code. For all I know there may be dependencies. 65.88.88.214 (talk) 17:18, 11 July 2017 (UTC)
There is no conditional logic. The |edition always applies to the book and never to the series. That's the way the template works now, and that's the way it would continue to work. Only the sequence changes, for clarity and to agree with convention. If a series has a salient edition number that differs from the publication edition, that number can be included with the series name in the |series parameter. I don't advocate a "series edition" parameter. —Ringbang (talk) 17:59, 11 July 2017 (UTC)
Ok, your proposal makes sense to me. 65.88.88.126 (talk) 13:03, 12 July 2017 (UTC)

Zotero now has a Wikidata translator[edit]

Citation management tool Zotero now has a Wikidata translator. Not only does it read metadata from Wikidata items about works, so you can add them to your Zotero library, but it can export metadata in a format understood by QuickStatements, enabling users to more easily create Wikidata items about the works already in their Zotero libraries. Since Zotero can already read metadata about works from other websites, or data files such as BibTeX and COinS, it can now be used as an intermediary to import that data. The translator was developed at the recent WikiCite event in Vienna. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:03, 6 July 2017 (UTC)

What is the first version number of Zotero to support this feature? Jc3s5h (talk) 12:32, 6 July 2017 (UTC)

e-book location[edit]

How do I cite an e-book with locations instead of page numbers? citing e-book got redirected to citing book, but I can't find any format for putting in location= instead of p= or pp=


Marcus Pedersen (talk) 23:41, 6 July 2017 (UTC)

|at= might work. Such documentation as there is for that parameter is at Template:Cite book#In-source locations.
Trappist the monk (talk) 00:14, 7 July 2017 (UTC)

I tried that but it didn't work:

[1]

Comes up as in the notes: 1.^Title 2017.

Whereas [2] comes up 1.^ Title 2017, p. 5189.

I would like the end result to look more like this: 1.^ Title 2017, loc. 5189.

@Marcus Pedersen: {{sfn}} isn't strictly a CS1 template, per se. Instead of |At= 5189 or |p= 5189 try |loc=loc. 5189, which would give you:
[3]

That should work for you. Imzadi 1979  01:17, 11 July 2017 (UTC)

Yes that works very well, thank you! Marcus Pedersen (talk) 01:50, 11 July 2017 (UTC)


References

  1. ^ Title 2017.
  2. ^ Title 2017, p. 5189.
  3. ^ Title 2017, loc. 5189.

ISBN[edit]

Shouldn't the reference to ISBN be changed from isbn=xxx to {{ISBN xxx? I realize that this is change is going to generate a lot of server load, but what's to be done? I certainly am not going to try anything of this magnitude myself. Just asking. TomS TDotO (talk) 11:21, 7 July 2017 (UTC)

No, that would be counterproductive. --Redrose64 🌹 (talk) 11:29, 7 July 2017 (UTC)
Please explain. TomS TDotO (talk) 11:44, 7 July 2017 (UTC)
@TomS TDotO: Why do you think this would be a good change? It might help if you explained why you think this is a good idea, so that we can help correct some incorrect belief you hold. --Izno (talk) 12:27, 7 July 2017 (UTC)
As I understand things, it is now the standard way of giving the ISBN number to use the ISBN template. If one uses the parameter isbn= there is a bot which will change it. TomS TDotO (talk) 12:35, 7 July 2017 (UTC)
Can you show where a bot is changing |isbn= in cs1|2 templates. If there is a bot doing this, it must be stopped.
Trappist the monk (talk) 12:42, 7 July 2017 (UTC)
The bots doing the conversion are catching ISBN usage in |id=. --Izno (talk) 12:50, 7 July 2017 (UTC)
Everything that the {{ISBN|123456789X}} template does, is done by cs1|2 when you write |isbn=123456789X. In fact, code that originated in cs1|2 is now used in the {{ISBN}} template. In cs1|2 templates, all parameters are named so you can't use the unnamed parameter construct |{{ISBN|123456789X}}. You can, but probably shouldn't, use |id=|{{ISBN|123456789X}} if there is a second ISBN (a second ISBN usually implies a second source and cs1|2 templates are single-source only).
Using |isbn={{ISBN|123456789X}} is bad because the {{ISBN|123456789X}} template drags in a whole lot of wiki markup that just confuses the MediaWiki parser and corrupts the cs1|2 template's metadata:
{{cite book |title=Title |isbn=123456789X |id={{ISBN|123456789X}}}}
Title. ISBN [[Special:BookSources/ISBN 123456789X|[[International Standard Book Number|ISBN]] [[Special:BookSources/123456789X|123456789X]]]] Check |isbn= value: invalid character (help). 
The purpose of the {{ISBN}} template is to be a replacement for the plain-text magic link which will be going away. cs1|2 never used the magic link capabilities so have no reason to use the {{ISBN}} template.
Trappist the monk (talk) 12:40, 7 July 2017 (UTC)
"code that originated in cs1|2 is now used in the {{ISBN}} template" Shouldn't {{ISBN}} and cs1|2 call a single, common, Module:ISBN (or whatever it would be called)? Or am I missing something? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:29, 8 July 2017 (UTC)

script-title needs error message[edit]

If a cite only contains a |script-title=, without |title= or |trans_title=, should we get an error message that either |title= or |trans_title= is missing from the reference as there should always be an English translation of the title.

Thus I would have expected an error from the following -

{{cite news|script-title=英投资方决定成都谢菲联不出售 尽快解决欠薪稳军心|url=http://sports.sina.com.cn/s/2010-12-09/06071693872s.shtml}}

Keith D (talk) 00:19, 10 July 2017 (UTC)

There is no rule requiring an English translation of the German |title=Die Zauberflöte. Why then should there be a rule requiring an English translation for |script-title=zh:英投资方决定成都谢菲联不出售 尽快解决欠薪稳军心? The purpose of |script-title= is to render non-Latin scripts without italics and to correctly handle those scripts that are written right-to-left. I have thought that cs1|2 might emit an error message when |script-title= is missing its language code.
Trappist the monk (talk) 00:41, 10 July 2017 (UTC)

Regnal numbering (Roman numerals) in names[edit]

Documentation:

first: Given or first names of author; for example: ... Firstname M., Sr.

Doesn't it screw up the metadata to put Jr., Sr., II, III, etc. into the "first" param? Or is it automatically trimmed out and reformatted? If the latter, would be nice to note in the documentation. I am no longer watching this page--ping if you'd like a response czar 18:34, 10 July 2017 (UTC)

Are you asking about generational suffixes or regnal numbers? I'm not sure that the two are the same thing.
COinS has a a keyword for generational suffixes: rft.ausuffix. That keyword applies only to the first author name and, like rft.auinit, rft.auinit1, and rft.auinitm, has never been supported in cs1|2. For us to use those keywords would require extra work on the part of editors and programmers.
Trappist the monk (talk) 19:05, 10 July 2017 (UTC)

"Chapters" in web pages[edit]

I believe it would be helpful if chapter or section entries could be made in the cite web environment, in particular if one wishes to refer to an anchor which has its own sub-heading within a web page. While including the sub-heading in the title parameter works after a fashion, the use of the chapter parameter (or an appropriately named alternative) seems more logical. --Schlosser67 (talk) 07:23, 12 July 2017 (UTC)

Which web pages have chapters? If you're citing an online book, use {{cite book}} with |chapter= and |chapter-url=. --Redrose64 🌹 (talk) 08:54, 12 July 2017 (UTC)
"in particular if one wishes to refer to an anchor which has its own sub-heading within a web page." -- PBS (talk) 11:31, 12 July 2017 (UTC)
Use |at=§ page-section? Though it seems clumsy. 65.88.88.126 (talk) 13:10, 12 July 2017 (UTC)
@Schlosser67: There is a convention you can use when the link contains an anchor: the section sign (§). You can generate this character using the "Insert" menu that's directly beneath the pane of the source editor, or the Ω menu that's above the pane in VisualEditor.
{{cite web |url=http://lor.em/ipsum#foo |title=Web Page Name § Section Name}}
For anchoring in a web page, I think this is preferable to a "chapter" designation (unless you really are linking to a chapter heading in a book). A chapter can have many pages, but we don't think of a "page" as having chapters. The section sign is a good way to express in a citation that a link has an anchor, and Wikipedia uses this convention.
If you want to refer the reader to a section but you can't use an anchor, indicate the section in the |at field:
{{cite web |url=http://lor.em/ipsum |title=Web Page Name |at=section "Section Name"}}
I disagree with 65.88.88.126's suggestion to link within |at. Since |url must be populated, there would be two links. Should the reader expect the link in |at to anchor and the link in |url not to anchor? My feeling is that if the link in |url anchors, we should communicate that in the link label, because that is where the link leads. But if only the |at link anchors, then that is a problem because nearly everyone will click the |url link. —Ringbang (talk) 14:22, 12 July 2017 (UTC)
One could always use "§" or ":" in any book title, so why not dispense with the chapter parameter in {{cite book}}? For that matter we could probably make do with a lot less parameters. As an example why bother with "location" just include the location information in the "publisher" parameter, and why bother a volume parameter as the volume information can be included as part of the title? -- PBS (talk) 14:47, 12 July 2017 (UTC)
@Schlosser67 as an alternative consider using {{citation}} with the parameter mode=cs1 set, you should then find that you can use chapter. -- PBS (talk) 14:47, 12 July 2017 (UTC)
Hi PBS, If you want to ask why certain parameters are useful and desirable, please create a new thread. —Ringbang (talk) 16:59, 12 July 2017 (UTC)
I was making a point! -- PBS (talk) 06:27, 13 July 2017 (UTC)
@PBS: Oh yes, I didn't mean to sound dismissive, but to answer the analogy you were making would hijack the thread. —Ringbang (talk) 18:28, 15 July 2017 (UTC)
The point is if we have other subdivisions what is the reason for not creating a similar subdivision along the lines requested. People have suggested work around, but they have not addressed the initial proposal "could be made in the cite web environment" and explained why a new subdivision ought/can not be added to the template.-- PBS (talk) 10:05, 16 July 2017 (UTC)
Thanks for all the suggestions. I'll have to see which works best. My point was that there are some long web pages with anchored sub-headings that could well be chapters in a thin book, and if the link in |url points to an anchor, then it makes sense to have the appropriate heading, too, no matter how long the work in question is. I did not expect to open such a can of worms ;-) --Schlosser67 (talk) 17:23, 12 July 2017 (UTC)
Please consider the rationale for structuring citations: ideally one would want a source that is as easily accessible/discoverable as possible. In the case of http-based sources, the accessible/retrievable entity is the page, just as in the case of book-based sources the relevant entity is the title. This is how users will retrieve the source, therefore that would be the primary (citation) index. To also make it easy to verify, we use the in-source locations within the accessible source, such as chapters, page-numbers or sections. Even when a webpage section is the verification target, the retrievable source is still the webpage. So imo, the source (the webpage) must be clearly distinct from any navigation target. I believe that users must know unambiguously and at a glance where the info comes from. Adding the section info to the title/page info is not a best practice, imo. 65.88.88.69 (talk) 20:26, 12 July 2017 (UTC)
"Adding the section info to the title/page info is not a best practice, imo".While you can argue that https://en.wikisource.org/wiki/1911_Encyclop%C3%A6dia_Britannica/Great_Rebellion#The_Invasion_of_Scotland is page based (although sections is another way to access the data), but this is not always so https://en.wikisource.org/wiki/Final_Act_of_the_Congress_of_Vienna/General_Treaty#ART.LIII Being able to access specific articles in a treaty is useful here is another example http://avalon.law.yale.edu/19th_century/hague01.asp#art57 -- PBS (talk) 06:44, 13 July 2017 (UTC)
The comment was about how the info would be presented to the reader, not how the navigation would be structured by the editor.
This
{{cite web|title=PageTitle|at=PageSection|website=Website|url=http://www.page.com#section}}
"PageTitle". Website. PageSection. 
Versus this
{{cite web|title=PageTitle PageSection|website=Website|url=http://www.page.com#section}}
"PageTitle PageSection". Website. 
Obviously, the first example is not entirely correct as the title-url navigates to the section-url. But I believe it is more reader-friendly. 72.43.99.146 (talk) 15:03, 13 July 2017 (UTC)

Proposal to default references element to column mode[edit]

I have started a proposal to switch the default behaviour of <references /> to automatic column mode. —TheDJ (talkcontribs) 09:22, 13 July 2017 (UTC)

Access level parameters[edit]

At least in {{cite web}}, but I suppose in all the allied templates, we have |url-access= (and the related |doi-access= and parameters for various other identifiers). We also have |subscription= and |registration=. The doc advises the use of the former. However, the former produces a lock icon, and the user must hover with the mouse to see its meaning. The latter (|subscription=) produces a textual note "Subscription required", plus a mouse over for more detail. Using both in an effort to get the icon and the note produces an error. |url-access= should produce a note, in addition to an icon. Until it does, i will use |subscription= exclusively, and convert any uses of |url-access= that I find on pages I am editing for other reasons. DES (talk)DESiegel Contribs 15:02, 15 July 2017 (UTC)

The only unequivocal determination resulting from this RFC is that we should be deprecating |subscription= and |registration=. Sometime in the future you should expect that those two parameters will be deprecated, replaced, and then dismissed. Now that I'm minded of the RFC results, I may begin this process.
Trappist the monk (talk) 15:37, 15 July 2017 (UTC)
You are going to get pushback from me on that, as at the moment this is a loss of functionality. In fact I'm tempted to get out AWB right now. DES (talk)DESiegel Contribs 16:02, 15 July 2017 (UTC)
If you are going to challenge the results of an RFC, that's a likely a separately-held RFC. And at Wikipedia, while consensus can change, we don't make people jump through more than a few hoops to get something done. As it is, the implementation of that RFC has been fairly-well delayed, so you better have some stronger reasoning than the above. I would see convert any uses of |url-access= that I find on pages I am editing for other reasons as somewhat tendentious, because an editor likely knowingly and preferably used that method of signaling the accessibility of the information at the URL in question. --Izno (talk) 18:12, 15 July 2017 (UTC)
That said, there probably needs to be a followup RFC, given the discussion regarding the icons being so split. There may be a better way of signaling to the reader (and not the editor) than those icons. But I'm not one to start it, certainly, and anyone who does better have a well-thought and well-written RFC question or three to pose. (And this is requested by the closer of the discussion: There is, however, a greater issue: A significant body of opinion has been expressed below that the entire visual status indicator idea is not acceptable. The above assessment must be interpreted in light of this. I would urge that this close is treated as a tentative indication of how the Citation Template processing would work in a new RfC to see if there is significant buy-in to proceed forward. To move forward with the shaky consensus established below would not comport with WP:CONS. Overall, there is not yet significant consensus on implementation of these citation template behaviors.) --Izno (talk) 18:16, 15 July 2017 (UTC)
Yes, there has been no consensus at all about the use of lock icons, and the RFC was inconclusive on that point. The status of parameters |registration= and |subscription= depended (per the RFC) on the approval or non-approval of the lock-icon scheme. In the absence of consensus on the lock icon scheme, any move towards deprecating these two parameters goes against the community's current position. 72.43.99.138 (talk) 14:14, 16 July 2017 (UTC)
There is consensus for deprecation of those parameters, the issue how exactly should we mark the access levels if different links. We could, for instance, place text after each of them J. Smith (2006) "Title" (free to read) Journal of things 3(1):4–23 arXiv:1023.2344 (free to read) doi:10.1234/123134 (subscription required). Headbomb {t · c · p · b} 17:51, 16 July 2017 (UTC)
The deprecation of these parameters was a sub item of the lock icons proposal. Nowhere in that RFC was it presented as an independent item. The overarching question was inconclusive; the dependent items (including the fate of these parameters) are moot. ANY unilateral action on this issue would be counter to the RFC's result. Start a new RFC on the particular issue. 146.111.225.160 (talk) 22:07, 16 July 2017 (UTC)

"the format used for publication dates"[edit]

"Access and archive dates in references should be in either the format used for publication dates, or YYYY-MM-DD". It could be useful to be more specific about what this means. Does this mean the "use xxx" date format template for that article, if any, or the citation's publisher's preference? Thanks, —PaleoNeonate - 03:50, 17 July 2017 (UTC)

It means the format chosen for that Wikipedia article, not by the citation's publisher. All publication dates in a single Wikipedia article should be in a single format, regardless of how the publishers formatted them. This line lets you instead format accessdates as YYYY-MM-DD but that's the only exception to the requirement of uniform date formatting. —David Eppstein (talk) 04:11, 17 July 2017 (UTC)
Thank you David Eppstein. Just before posting this question I was participating at WP:VPT#Date_Formatting where I suggested something similar, I wanted to make sure that this answer was correct. Feel free to correct me there otherwise. Thanks again, —PaleoNeonate - 04:16, 17 July 2017 (UTC)
See MOS:DATEUNIFY. – Jonesey95 (talk) 04:28, 17 July 2017 (UTC)
Thank you, I added this link to clarify what "publication dates" are. —PaleoNeonate - 04:36, 17 July 2017 (UTC)

Order of authors, redux[edit]

In this recent discussion, Trappist the monk wrote:

The change to Module:Citation/CS1/sandbox that added the sorting was done here and appears to have been done for the convenience of the editor.

Can that edit be reverted? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:27, 19 July 2017 (UTC)

Looking at the previous discussion, it looks like I made this change in the module's sandbox, but it hasn't gone live yet. The last update was on April 29, 2017, so we are probably due for an update. – Jonesey95 (talk) 03:21, 20 July 2017 (UTC)

Another order problem[edit]

A problem that has been previously discussed, but never fixed, is the change in the order of elements depending on whether there is an author or not:

  • "Trump criticized for treatment of female reporter". The Boston Globe. June 29, 2017. p. 2. 
  • Nanos, Janelle; Chesto, John (June 29, 2017). "Struggling Staples OK's $6.9b sale". The Boston Globe. p. 1. 

In the first example, the date is near the end and not in parentheses and near the end. In the second example the date is the second element, right after the element that determines order in an alphabetical list. If there were two items by same article in an alphabetical list, the date would be the tie-breaker. Likewise, if there were two references with no author and the same title, the date would still serve as the tie-breaker, so should be the next element, like this:

"Trump criticized for treatment of female reporter". (June 29, 2017) The Boston Globe. p. 2.

Jc3s5h (talk) 10:50, 20 July 2017 (UTC)

@Jc3s5h: if I arranged citations in alphabetic order, then in your first example I would treat "Boston Globe" as the equivalent of the author, i.e. the first ordering field. So it makes sense to me for "Boston Globe" and the date to be next to one another. The alternative, I suppose, is to use "Anon." for the author. What would you treat as the first ordering field in your first example? Peter coxhead (talk) 11:08, 20 July 2017 (UTC)
There is a somewhat-ancient consensus for this change documented either in the CS1 talk archives or on the feature request page. It's not a trivial change to make in the code, and we end up running into the "stacked" parentheses issue I've noticed. --Izno (talk) 11:20, 20 July 2017 (UTC)
As for "anonymous", I'd say that CS1 is more like APA style than any other, and that style calls for not mentioning "anonymous" in the citation unless the publication actually shows "anonymous" as the author. Both APA and Chicago call for placing the title (in the case of newspapers and journals, the article title, not the newspaper or journal title) in the place of the author. The case of using the date as a tie-breaker is only addressed for authors, not works lacking an author, but if we're treating the article title as if it were the author, it stands to reason the date would be the tie-breaker. Jc3s5h (talk) 11:33, 20 July 2017 (UTC)
I found the previous discussion here. I would add that the publications most likely to lack authors are newspaper articles. The type of information found in newspapers is more likely to become outdated that information found in peer-reviewed journals or books, so to tend to put the date near the beginning of the cite for publications that are less likely to be outdated, and put the date near the end for publications that quickly become outdated, seems topsy-turvy. Jc3s5h (talk) 12:23, 20 July 2017 (UTC)

Using names of months[edit]

i have two connected problems on Cite news on cywiki: 1. When I copy this most recent version to our older module on cywiki, it causes an error which I'm unable to correct and 2. The date format on cywiki is always dd name of month yyyy (eg 19 Gorffennaf 2017), but as you can see on cy:Alfred Russel Wallace we can only use yyy-mm-dd (eg 2017-07-19). Any help would be warmly received! Llywelyn2000 (talk) 04:40, 22 July 2017 (UTC)

@Llywelyn2000: What is "an error which I'm unable to correct"?
Does the date format problem only happen with cy:Template:Cite news, or does it affect cy:Template:Cite web as well? Is it only the |access-date= parameter, or |date= as well? What happens if you use English-language dates like 19 July 2017 - does the problem disappear? --Redrose64 🌹 (talk) 08:30, 22 July 2017 (UTC)

I'm also perplexed. You said this most recent version by which I would expect the 28 May 2017 version of the module suite. But, at cy.wiki, the date there looks to be 26 May 2016.

The |access-date= validation at cy.wiki does not work because the MediaWiki time parser does not understand non-English month names. Try this in your sandbox at cy.wiki:

{{#time:U|5 Ebrill 2007}}

then try this:

{{#time:U|5 April 2007}}

you should get:

{{#time:U|5 April 2007}} → 1175731200

Because this problem exists in all non-English wikis, all versions of the module suite since 30 July 2016 have a fix for the problem.

What is your intent? Do you want to just fix your version of your older fork of the module suite? Do you want to the cy.wiki module suite to track the en.wiki modules?

I can see that someone has copied en:Module:Citation/CS1/Date validation/sandbox to cy:Modiwl:Citation/CS1/Date validation/sandbox, changed the month names to Welsh and then reverted. I would not recommend ever taking the en.wiki sandbox versions of the module suite; they are never guaranteed to be working. You should, instead, take the current live version into your sandboxen and make sure that whatever changes are required to suit your particular language are made first there before upgrading the live versions.

Trappist the monk (talk) 11:59, 22 July 2017 (UTC)

Many thanks to both of you. I've reproduced the problem here. I managed to translate the months, so we're partly there! @Redrose64: - I've also added your bits; the Welsh one doesn't work. Intent - to enable any form of input to produce our usual format (27 Mai 2017). Thanks again! Llywelyn2000 (talk) 05:53, 24 July 2017 (UTC)
The dates rendered in the citation at test 1 are (for me): 2017-07-19 and Adalwyd 2017-07-19. I see no 19/07/2017 in that page except where you write that the dd/mm/yyyy style is not used on cy.wiki. Test 1 apparently shows that the module suite is working correctly; can't fix it if it ain't broke.
The reason for the failure of test 2 is described above and confirmed by the results of test 3.
Intent - to enable any form of input to produce our usual format (27 Mai 2017). Do you mean that you want the module suite to automatically reformat dates in mdy and ymd formats to dmy format?
Trappist the monk (talk) 10:17, 24 July 2017 (UTC)

Identifier order messed up.[edit]

Why is bibcode displaying before arxiv in?

Identifiers should be listed in alphabetical order. Headbomb {t · c · p · b} 13:49, 10 June 2017 (UTC)

The identifier labels are sorted with a case sensitive sort. 'B' has an ascii numerical value of 66 (0x42) and 'a' has an ascii numerical value of 97 (0x61). Proof for that is here, where I've added |eissn=1365-2966 and |issn=0035-8711 from the journal's wikipedia article:
Corbelli, E. & Salucci, P. (2000). "The extended rotation curve and the dark matter halo of M33". Monthly Notices of the Royal Astronomical Society. 311 (2): 441–447. Bibcode:2000MNRAS.311..441C. ISSN 0035-8711. arXiv:astro-ph/9909252Freely accessible. doi:10.1046/j.1365-8711.2000.03075.x. eISSN 1365-2966. 
Trappist the monk (talk) 14:42, 10 June 2017 (UTC)
Well, that ought to be fixed then, either with case-insensitive sorting, or by putting the sortkey in a {{lc:IDENTIFIERNAME}} type of thing. Because it wasn't like that before. Headbomb {t · c · p · b} 15:18, 10 June 2017 (UTC)
There have been no changes to the identifier sorting since at least this version (April 2013) of Module:Citation/CS1.
Trappist the monk (talk) 15:59, 10 June 2017 (UTC)
I distinctly remember those to be sorted correctly as late as this spring. But even if my memory somehow fails me, those should be sorted alphabetically, regardless of casing. Headbomb {t · c · p · b} 17:02, 10 June 2017 (UTC)
De-archived as unresolved and still in need of a fix. Headbomb {t · c · p · b} 13:32, 22 July 2017 (UTC)

Any update on doi-broken-date?[edit]

If anything, the doi should at the very least still link. Other improvements can wait/get more discussion, but the linking part should be easy to fix. Headbomb {t · c · p · b} 14:25, 11 April 2017 (UTC)

@Trappist the monk: Any way we can get this bundled in the weekend's update? Headbomb {t · c · p · b} 05:29, 26 April 2017 (UTC)
The purpose of this interstitial period is to have a last chance to find and fix bugs; to create or modify supporting documentation, categories, templates, etc. – housekeeping preparatory to the update. It is not the time for new development or new features.
Trappist the monk (talk) 11:28, 26 April 2017 (UTC)
Yeah well this has been requested a long while ago, is an easy fix, and we have over half a week left. WP:BURO applies here. Headbomb {t · c · p · b} 11:57, 26 April 2017 (UTC)

Can we now implement this? Headbomb {t · c · p · b} 00:27, 2 May 2017 (UTC)

De-archived because discussion is ongoing/unresolved. @Trappist the monk:. Headbomb {t · c · p · b} 17:20, 23 May 2017 (UTC)
@Trappist the monk and Jonesey95: pinging. Headbomb {t · c · p · b} 19:13, 12 June 2017 (UTC)
It makes sense to me to have allegedly broken DOIs linked, since the doi-broken-date is checked by a bot and (a) could have been wrongly applied or (b) could have been a temporary problem or (c) both. There are plenty of links that don't work and are not flagged as such. That's just the state of the web, and always has been. – Jonesey95 (talk) 02:00, 13 June 2017 (UTC)
De-archived as unresolved and still in need of a fix. Headbomb {t · c · p · b} 13:32, 22 July 2017 (UTC)

Instructions when info is hard to find at source page[edit]

Occasionally there are certain quirks in web pages that make it harder to find the source information being cited. For example, in the article on Kevin Quackenbush, I sourced some information from his bio on MLB.com, but to get to that information requires an additional click (on the not-so-obvious "View More Bio Info +" link), which then produces a popup window that doesn't seem to have a URL of its own. In these cases, I believe it would be useful to provide some instruction to the reader on how to navigate to the relevant information, e.g. click the "View More Bio Info +" link. Is there a parameter within the template that can be used for this or another standard way of doing so? Thanks. --Jameboy (talk) 17:44, 24 July 2017 (UTC)

@Jameboy: |at= or choosing to put the information outside the template would both be reasonable, I think. --Izno (talk) 18:49, 24 July 2017 (UTC)
That seems sensible, good suggestion, thanks. --Jameboy (talk) 19:09, 24 July 2017 (UTC)
You can use "postscript=Click View More Bio Info" and put some further instructions there. AngusWOOF (barksniff) 08:10, 25 July 2017 (UTC)
@AngusWOOF: This is a misuse of |postscript=. --Izno (talk) 12:00, 25 July 2017 (UTC)