Help talk:Citation Style 1/Archive 35

Archive 30

←

Archive 33

Archive 34

Archive 35

Archive 36

Archive 37

→

Archive 40

script-title needs error message

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

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

e-book location

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:

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

Whereas 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:

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

Book edition vs series edition

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 comparison

Wikitext	{{cite book|edition=4th|series=Book Series|title=Book Title}}
Live	Book Title. Book Series (4th ed.).
Sandbox	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)

Proposal to default references element to column mode

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

Question on the use of the "language" field

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)

"Chapters" in web pages

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)

Access level parameters

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"

"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

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

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)

Instructions when info is hard to find at source page

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 (bark • sniff) 08:10, 25 July 2017 (UTC)

@AngusWOOF: This is a misuse of |postscript=. --Izno (talk) 12:00, 25 July 2017 (UTC)

Citing Foreign Affairs

Foreign Affairs comes out six times a year, and the issues are dated with two months; the current issue is the "July/August" issue. If I put "July/August" into the date= variable of cite magazine, as I did at Ryukyu_Islands#Okinawa_Islands, the template throws up an error. What's the correct method here? Thanks in advance, A Train^talk 17:42, 29 July 2017 (UTC)

cs1|2 adheres to the date-range rules set by MOS:DATERANGE modified as described at Help:Citation_Style_1#Dates. Dates always require a year. |date=July–August yyyy where yyyy is the year of issue. Did the help text linked by the error message not answer this question? How can the help text be improved?

Please fix the unclosed italics wiki markup in your signature (the user talk link).

—Trappist the monk (talk) 18:07, 29 July 2017 (UTC)

Thanks for that -- the problem wasn't that I hadn't included a year, it was that I had used a slash to separate the months instead of a dash. Also, thanks for the heads-up on the signature. No one had noticed that in over ten years. :) A Train^talk 18:23, 29 July 2017 (UTC)