Jump to content

Help talk:Citation Style 1/Archive 23

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 20Archive 21Archive 22Archive 23Archive 24Archive 25→Archive 30

The documentation for 'cite av media' needs to be improved...

I assume {{Cite AV media}} is supposed to be used for YouTube video references? Yet the documentation doesn't contain one "YouTube example". It would certainly help if such an example could be added to the documentation. Just sayin'... --IJBall (contribs • talk) 03:20, 17 August 2016 (UTC)

Hello, IJBall
Your assumption is wrong. YouTube is not a reliable source in Wikipedia and must never be used. (It can be used as a medium though, as opposed to a source, e.g. you link to a reliable source that has an embedded video.)
{{Cite AV media}} is used for film and audio recordings, e.g. a conference available for sale on a tape, CD, DVD, Blu-Ray and online streaming.
Best regards,
Codename Lisa (talk) 08:58, 17 August 2016 (UTC)
@IJBall: my opinion is a bit more nuanced than Codename Lisa's. If the appropriate entity uploads a video to YouTube, without violating copyright, and the video otherwise meets our requirements regarding reliable sources and self-published sources, then in that case the video is acceptable as a source. However, in this case, YouTube is not the publisher, but it's acting as a republisher of sorts. In that case, you'd cite the video as if YouTube had nothing to do with the video, crediting the original creators and publisher. Then you could add the appropriate |url= with |access-date= and append |via=YouTube to note where it was republished.
However, since most content on YouTube is self-published, it can't be used without complying with the exceptions noted at WP:SPS. Imzadi 1979 → 09:37, 17 August 2016 (UTC)
Looks to me we are actually on the same page. Just different opinions of how to word our approach... —Best regards, Codename Lisa (talk) 09:44, 17 August 2016 (UTC)
I actually knew all that. And, yes, I'm thinking of something like this which is simply a promo released directly from Nickelodeon on YouTube. Movie trailers direct from movie studios would be another example. In any case, this comes up a lot, and a "YouTube" example should be added to the {{Cite AV media}} documentation so that your garden variety editor knows how to properly cite YouTube, including the |via=YouTube parameter. --IJBall (contribs • talk) 15:01, 17 August 2016 (UTC)

Replacements (gsub) in Module:Citation/CS1

Should str= mw.ustring.gsub (str, '[“”]', '\"'); be changed to str= mw.ustring.gsub (str, '[“”]', '%"'); as Lua escape character should be %, not standard regex \?

Same applies for line below. --Obsuser (talk) 03:50, 24 August 2016 (UTC)

@Obsuser: In Lua, strings can use various escape sequences that start with \, including \". Further details at mw:LUAREF#string - Evad37 [talk] 08:57, 24 August 2016 (UTC)
@Obsuser: The Lua reference manual states that \" is a valid escape character for double quotes: Lexical Conventions. Normally %x is usable in describing a character class for x, (see Character Class, but within a replacement string a character class doesn't make sense, unless it's part of a capture. Try pasting:
  1. print( string.gsub('123abc', '[2a]', '\"') )
  2. print( string.gsub('123abc', '[2a]', '"') )
  3. print( string.gsub('123abc', '[2a]', '%"') )
into https://www.lua.org/cgi-bin/demo and you'll see that 1 & 2 work, but the interpreter barfs at the % in number 3. --RexxS (talk) 20:31, 24 August 2016 (UTC)
@Evad37 and RexxS: Thank you. I was confused with mw:LUAREF#string.gsub which says for replacement string that "The character % works as an escape character: any...". However, the following part of the sentence mentions captures.
I've tried to use :gsub(',', '%.') on one string in Wikipedia module and it worked as I thought it would: I got "." instead of ",", not "%." instead of "," (I want to say that % worked as escape character for dot; in https://www.lua.org/cgi-bin/demo it doesn't work that way). --Obsuser (talk) 21:01, 24 August 2016 (UTC)

The problem seems to have arisen nearly 6 years ago, when it was decided to link Google Books pages not adding pageurl to titleurl and chapterurl, but distorting the use of titleurl, which since then can also no longer be addressed to the front cover. Personally I solve by placing a link in the page or quote parameter, but some editors disagree and revert me. I mean, what do you think of updating the template {{cite book}}? --Mauro Lanari (talk) 09:51, 25 August 2016 (UTC)

A link to a particular page can be useful, but a link to the cover is just advertising Google Books for little benefit, since the same page is only one extra click away via the ISBN link. Kanguole 10:42, 25 August 2016 (UTC)
But since the title of a book is written on the front cover, the titleurl should direct there and nowhere else. Or not? In addition, the ISBN link often leads to a wrong edition of the book, or to one now out of print. --Mauro Lanari (talk) 11:30, 25 August 2016 (UTC)
The ISBN should lead to the edition of the book being cited, otherwise it tends to make page number useless. Nikkimaria (talk) 11:43, 25 August 2016 (UTC)
What are you talking about? That RFC did not make any decision regarding a (non-existent) |pageurl= parameter. In fact, |pageurl= is not mentioned in the RFC and only once is a cs1|2 template mentioned as an example – the editor described linked to a specific page using {{cite book}}. If there is a problem, I don't understand what it is. Can you elaborate?
—Trappist the monk (talk) 11:46, 25 August 2016 (UTC)
I'll try. I'm asking about the possibility of linking directly a Google Books page using an appropriate new parameter (for instance |pageurl=) instead of overloading the functions of the other already existing parameters. --Mauro Lanari (talk) 12:10, 25 August 2016 (UTC)
A |page-url= parameter is problematic because |pages= allows comma separated lists of page numbers. To do it 'properly', I think that we would need to deprecate that form of |pages= so that its only allowed value would be a single page-range (|pages=100–120). We would then need to enumerate both |pagen= and |pagesn= and create matching enumerated |page-urln= and |pages-urln= parameters. For semantic reasons it is desirable to keep |pages= because we shouldn't be using the singular form when identifying a page-range (|page=100–120).
—Trappist the monk (talk) 13:13, 25 August 2016 (UTC)
Really very interesting. Well: maybe (maybe) pagesurl is a false problem. A page-range always corresponds to a chapter or to a page ff, which means that no one is interested in a direct link to the last page. For example so far I have only ever linked the first page, while on the page parameter I have included the full range (pp./pages 100-120, p./page 100 ff and so on). --Mauro Lanari (talk) 14:13, 25 August 2016 (UTC)
There is no requirement that a page-range [shall] always [correspond] to a chapter (or journal article). It is a common practice in bibliographic cites, but in that case, the specific page numbers are stated in the accompanying short cites. cs1|2, as a style, does not limit editors' use of page ranges in that way. For in-line citations, if the source chapter or article includes pages 100–120 but the important bit that supports a statement in our article is on page 105, we should cite the chapter in |chapter= or the journal article in |title= and identify the location as |page=105 not as |pages=100–120. It is poor practice for us to make the reader search an entire article for a sentence or fact that lives on one page.
—Trappist the monk (talk) 14:48, 25 August 2016 (UTC)
As you know, there is substantial disagreement on this point. Kanguole 14:57, 25 August 2016 (UTC)
Every useful link to Google Books I have seen in cite templates links |title= to a URL for the page where the citation can be verified. That's the point of linking in citations – helping the reader verify the text in the article. – Jonesey95 (talk) 15:09, 25 August 2016 (UTC)
As I said above, by doing so you have overloaded the functions of the other existing parameters instead of adding a new appropriate one. This is an example of how all the info may be supplied in the unfortunately persistent absence of |pageurl=: Graham, Stephen (2008) [1st ed. 2004]. Cities, war, and terrorism. Towards an urban geopolitics. Hoboken, New Jersey: John Wiley & Sons. p. 51. ISBN 978-0-470-75302-6. {{cite book}}: More than one of |ISBN= and |isbn= specified (help), where the reader is helped in verifying the text in the article (SUV as a "defensive capsule") --Mauro Lanari (talk) 16:23, 25 August 2016 (UTC)
Linking to the front cover can only confuse the reader. The ISBN link and the URL link in the page number field are both one click away from the front cover page, and the front cover image is already in the left sidebar of the Google Books page. Just do this (I also removed a redundant ISBN): Graham, Stephen (2008) [2004]. Cities, war, and terrorism. Towards an urban geopolitics. Hoboken, New Jersey: John Wiley & Sons. p. 51. ISBN 978-0-470-75302-6. – Jonesey95 (talk) 16:35, 25 August 2016 (UTC)
@Kanguole: Last time that there was disagreement over what should be put in |pages=, I unwatched this page. I can easily do that again. --Redrose64 (talk) 16:40, 25 August 2016 (UTC)

Linking the front cover is the only correct use of titleurl: "URL of an online location where the text of the publication can be found." It's not provided any further usage, and if you collapse the front cover with the page, you're getting the opposite of what you would like to avoid: confusing the reader. --Mauro Lanari (talk) 17:19, 25 August 2016 (UTC)

There is no |titleurl= parameter, but the next sentence in the documentation for |url= is "If applicable, the link may point to the specific page(s) referenced." The link to the front cover is superfluous, so putting the specific page link in |url= may be inelegant, but is justifiable in terms of the purpose of the citation. Kanguole 17:32, 25 August 2016 (UTC)
I've always thought that where a link to the page is possible (where a preview is available, though it won't be available to all) then the link should be wrapped around the page number. Where no preview is possible, but you still want to point to the book somewhere, then the URL can be usefully wrapped around the title. Doing both is a bit of overkill. Sometimes I think it is not worth the bother, and no links at all is best. It is often more important to start from the front cover of the book, and assess its reliability, before turning to the page you have been directed at. Jumping straight to a page is lazy and encourages people to take things out of context. I hate it when people use search-string URLs - that is discouraged, isn't it? Carcharoth (talk) 18:26, 25 August 2016 (UTC)
Linking the Google Books title page ("About this book") is useful because it verifies the entire citation, in "§ Bibliographic information". I don't think linking to Google Books "About this book" pages is advertising, any more than mentioning the (original) publisher. After all, all citations could be conceivably reduced to just the identifier. That would make them extra-simple. In any case, my preference runs towards short citations; I link the page url at the short form, and often, the book title ("About this book") at the full citation. 72.43.99.146 (talk) 00:35, 26 August 2016 (UTC)
When a reader/user finds a {{cite book}} and sees the title book as a blue link, clicking on it (s)he expects anything but being directed to a specific page, furthermore "out of the context". To have discarded the idea of a |pageurl= parameter for "|url=: if applicable, the link may point to the specific page(s) referenced" is symptomatic of a lazy, confused, twisted mind. --95.234.110.97 (talk) 02:49, 26 August 2016 (UTC)

New categories

I have just created:

These are applied automatically, by {{cs1 wrapper}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:45, 27 August 2016 (UTC)

Google Books and page URLs

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Redundant thread; my bad.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:13, 28 August 2016 (UTC)
Moved to #About WP:PAGELINK

User Mauro Lanari (talk), at 02:06, 25 August 2016 (UTC), opened a WP:TFD about {{Cite book}}, and it was speedily closed as being in the wrong venue. As a procedural matter, I'm posting it to the correct one for him, in slightly clarified wording, though I haven't formulated a firm opinion about it myself:

About WP:PAGELINK: The problem seems to have arisen nearly 6 years ago, when it was decided to link Google Books pages in a way that distorts the purpose of |titleurl=, rather than adding a |pageurl= parameter to go along with |titleurl= and |chapterurl=. Since then, |titleurl= can also no longer be addressed to the front cover of a Google Book. Personally I [Maura Lanari] solve this by placing a link in the page or quote parameter, but some editors disagree and revert me. I mean, what do you think of updating the template {{cite book}}?

For Mauro Lanari (talk)  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  06:05, 28 August 2016 (UTC)

  • For my part, I'm uncertain we have an encyclopedic need to link to the front of a Google Book when citing a page in it. Most of us do not use |titleurl= but |url= (I didn't even know |titleurl= existed). A possible solution would be to enable a |pageurl=, and treat |url= as an alias of it if a separate |titleurl= is given, but otherwise treat |url= as synonymous with |pageurl=. A problem with treating any Google Books |url= as a |pageurl= is that people expect to see the title linked, not a tiny page number, and another is that we'd need the Lua to parse for books.google.com URLs in particular.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  06:05, 28 August 2016 (UTC)
    There is no |titleurl= to know about:
    Title. {{cite book}}: Unknown parameter |titleurl= ignored (help)
    —Trappist the monk (talk) 08:35, 28 August 2016 (UTC)
Okay!  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:13, 28 August 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Title2 or AltTitle

Is it possible to incorporate something into template:cite web to reflect when a piece has more than one title?

For example as you can see at http://web.archive.org/web/20160729014127/http://www.macleans.ca/news/justice-for-black-canadians-not/ the original title of the July 28 piece by Domise is "Justice for Black Canadians (not)" but the present version of the article at http://www.macleans.ca/news/justice-for-black-canadians-not/ has changed the title to "Why we can’t trust SIU to probe death of Abdirahman Abdi" even though the URL still reflects the old title.

I would like a way to convey in the citation both the original title of the piece and then the replacement title for the piece.

To give another example of what I mean, take this piece by Stephanie McCrummen in the Washington Post:

It's the same piece, but was given a new title. Ranze (talk) 06:32, 26 August 2016 (UTC)

I would use |orig-year=originally published 22 March 2005 as "Looking for Logic amid the Pain". 64.134.66.58 (talk) 11:43, 26 August 2016 (UTC)
I would not advise what the IP above suggests. In this case, I would only use the title for the version of the article that was consulted and cited. Yes, that could mean a mismatch between the title and the version of it repeated within the URL, but so be it. If necessary, it may be possible to additionally cite an archived copy of the old version of the article under the old title, but I would not try to combine what are really separate sources together. Imzadi 1979 → 15:19, 26 August 2016 (UTC)
I disagree. This is for all practical purposes a reprint, except for the article's title. For purposes of verification, nothing changed materially, and discovery of the source has not been affected. It is convenient to provide prior history for the title, but this is not necessary in this case. Why make it any more complicated? It would be a different story if this was a different title in a different edition. 72.43.99.138 (talk) 15:32, 26 August 2016 (UTC)
When you add the content to the article, with a ref, in that ref you should use the title as it is shown at that time, the date as it is shown, and the accessdate is today's date. If the title changes tomorrow, leave it alone together with the date, accessdate and anything else. --Redrose64 (talk) 19:20, 26 August 2016 (UTC)
If the title changes, the citation should be edited because this affects discovery of the source, and/or may confuse readers. This may be more pertinent when sources are online (eventually, all of them may be). Something should promptly alert the reader that they are looking at the right source, albeit with a different title. The use of |orig-year= was suggested in cases where the new title is cited, in order to provide title history as a convenience. 72.43.99.138 (talk) 14:47, 27 August 2016 (UTC)
If you went and looked (how else could you know the title changed?), then you have accessed it again, so should update the title to the current one and change the access-date. The purpose of the access-date parameter is to mark the date that something was most recently verified, not to freeze in time when a source was first added. In complex situations involving offline sources, you can just add a note after the citation template and before the closing </ref>. Another thing I've done when a work as two titles in different markets and they're they same down the page numbers, just with different covers and nominal publishers, is to do <ref>{{Cite book|...}} Also published as: {{Cite book|...}}</ref> There is no reason that every possible detail must be fitted into a single citation template.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:21, 28 August 2016 (UTC)

Sections of websites

Is there a correct way to link to a section of a website? Which of these three is best?

  • [1] put both section and title information in the 'title' parameter
  • [2] put the section information outside the citation template
  • [3] use the 'at' parameter to describe the section

I should provide the full examples here, but am not sure how to do that. Carcharoth (talk) 18:20, 25 August 2016 (UTC)

If the destination website provided an anchor to a section, then I'd use:
  • {{cite web |url=http://venn.lib.cam.ac.uk/Documents/acad/lists/P.html#Aeronautical_Engineering,_Francis_Mond_Professorship_of |title=Francis Mond Professor of Aeronautical Engineering |website=A Cambridge Alumni Database |publisher=University of Cambridge |accessdate=15 September 2013}}
  • "Francis Mond Professor of Aeronautical Engineering". A Cambridge Alumni Database. University of Cambridge. Retrieved 15 September 2013.
On the grounds that nobody actually cares what the title of the container is (i.e. page title) when they have the title of the section linked via the fragment in the url. But that's just me. As for the actual venn.lib.cam.ac.uk site, they haven't realised yet that the HTML5 spec at https://www.w3.org/TR/html-markup/a.html#a-constraints has now made obsolete the "name" attribute that the web-designers are using to create an anchor for each section - which is why the above doesn't actually work. Even dinosaurs like me have caught on to that. --RexxS (talk) 20:21, 25 August 2016 (UTC)
The spec that I normally refer to shows that name= is obsolete, but words it as "should not", which is weaker than "must not". It then describes how the name= attribute can be used in such a way that it won't conflict with other name= or id= attributes. Later on we find "The following attributes are obsolete (though the elements are still part of the language), and must not be used by authors ... name on a elements (except as noted in the previous section)". Here we have the strong "must not", but conditionally weakened. --Redrose64 (talk) 22:47, 25 August 2016 (UTC)
I would use the |at= solution here. The above suggestion of |title=Francis Mond Professor of Aeronautical Engineering is a made-up pseudo-title not appearing in the work, thus making it harder to find and verify the exact source material. I encounter this problem frequently, and fix it, of people trying to use the |title= parameter to describe or retitle a work because they think the actual title isn't clear enough or something. E.g., often I'll seen dictionary entries done as |title='anthropogenesis' entry, and this is simply incorrect; the correct value is |title=anthropogenesis. Don't second-guess the title even if you don't like it.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:31, 28 August 2016 (UTC)

Edited collections and chapters

Is there a difference between edited collections and books with chapters with different authors? Template:Cite book says: "For edited collections, use {{cite encyclopedia}}". But 'cite book' also gives the option for 'Citing a chapter in a book with different authors for different chapters and an editor'. This seems identical to 'cite encyclopedia'. Is there a difference? Some collections are arranged in chapters, some are not. Is that the main difference? That non-chapter collections should use 'cite encyclopedia' and collections arranged in chapters can use either? (In passing, people do sometimes use 'contribution' for chapters in a collection, when 'contribution' should really be for "afterword, foreword, introduction, or preface"). Carcharoth (talk) 12:06, 23 August 2016 (UTC)

Everything makes sense when you realize that the doc is actually a story by Lewis Carrol. 108.55.199.227 (talk) 12:43, 23 August 2016 (UTC)
Am I supposed to find a queen somewhere on the documentation page? Clearly I'm looking in the wrong places. --Izno (talk) 13:08, 23 August 2016 (UTC)
I'm not sure where the use-{{cite encyclopedia}}-for-edited-collections notion comes from. Perhaps it is a documentation artifact from the early days of the cs1 templates when those templates were much less capable than they are today. Scholarly works on some topic are often edited collections of writings by many authors compiled into a book of chapters. I see no reason to prefer {{cite encyclopedia}} over {{cite book}} for these works.
There is no requirement that states that |contribution= is specifically limited to afterword, foreword, introduction, and preface. The requirement that I think you allude to is for |contributor= which requires |contribution=. The contribution can be anything but is typically one of the afterword, foreword, etc.
—Trappist the monk (talk) 13:18, 23 August 2016 (UTC)
Puzzling. I use 'cite encyclopedia' all the time. Quoting from {{cite encyclopedia}}:

"This Citation Style 1 template is used to create citations for articles or chapters in edited collections such as encyclopedias and dictionaries, but more generally any book or book series containing individual sections or chapters written by various authors, and put together by one or more editors."

Example of my use of 'cite encyclopedia': [4], [5]. Another example is the Dictionary of Scottish Architects, which could be cited as a collection (more strictly, it is an online database). Many of these online collections would be encyclopedias if printed. Carcharoth (talk) 13:39, 23 August 2016 (UTC)
Certainly your first example could use {{cite book}}. Your second could use {{cite web}} especially if the online version is the source that you consulted:
{{cite web|last=Brody|first=David|author-link=David Brody|title=Meany, George|url=http://www.anb.org/articles/15/15-01098.html|website=American National Biography Online|publisher=Oxford University Press and American Council of Learned Societies|subscription=yes|date=February 2000|access-date=12 August 2016}}
Brody, David (February 2000). "Meany, George". American National Biography Online. Oxford University Press and American Council of Learned Societies. Retrieved 12 August 2016. {{cite web}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)
—Trappist the monk (talk) 14:16, 23 August 2016 (UTC)
I don't think that any editor actually makes use of the information contained in the name of the cite template. {{Cite encyclopedia}} treats the container |encyclopedia= rather like MLA's style of using quotes, while {{cite book}} treats it as an alias for |work= so it is italicised. Chacun à son goût.
  • Cavell, Richard (2015). "Remembering Canada: The Politics of Cultural Memory". In Sugars, Cynthia (ed.). The Oxford Handbook of Canadian Literature. Oxford University Press. pp. 64–79. ISBN 9780199941865. - cite encyclopedia
  • Cavell, Richard (2015). Sugars, Cynthia (ed.). Remembering Canada: The Politics of Cultural Memory. Oxford University Press. pp. 64–79. ISBN 9780199941865. {{cite book}}: Unknown parameter |encyclopedia= ignored (help) - cite book with |encyclopedia=
  • Cavell, Richard (2015). Sugars, Cynthia (ed.). Remembering Canada: The Politics of Cultural Memory. Oxford University Press. pp. 64–79. ISBN 9780199941865. {{cite book}}: |work= ignored (help) - cite book with |work=
--RexxS (talk) 14:27, 23 August 2016 (UTC)
I don't think a chapter in a book is supposed to be rendered in italics. The citation immediately above should be rendered as:
  • Cavell, Richard (2015). "Remembering Canada: The Politics of Cultural Memory". In Sugars, Cynthia (ed.). The Oxford Handbook of Canadian Literature. Oxford University Press. pp. 64–79. ISBN 9780199941865. - cite book with |chapter=
– Jonesey95 (talk) 14:37, 23 August 2016 (UTC)
Jonesy is right. 'Title' in cite encyclopedia is equivalent to 'chapter' in cite book. This can confuse people. Carcharoth (talk) 15:10, 23 August 2016 (UTC)
Quite. I'm sorry I wasn't clearer: I was trying to show what would happen if you were to use |encyclopedia= in {{cite book}}, not advocate its use! There is a case you could make for using {{cite book}} for all works written on paper with covers on the front and back. You just learn one set of parameters and the output they produce. Personally, I don't care if chapter titles are in quotes or offset in superscripted Comic Sans with a pink shadow. As long as we all agree on something recognisable and use it consistently. --RexxS Call me Dino (talk) 16:39, 23 August 2016 (UTC)
I realise they produce the same output. It is more a case of when I look at a source, I think to myself "what type of source is this?". If it is a printed book, that is obvious. If it is is a collection, I tend to reach for 'cite encylopedia'. If it is a news publication, then 'cite news'. When it is a webpage, I know I should really use 'cite web', but there is a distinction in my mind between webpages with no named author and no obvious date on a website with no clear structure, and more organised online websites clearly intended to replicate the organisation of a collection of entries under a named work (sometimes with a named author, sometimes not). The DSA and ANB are examples of the latter, while an example of the former would be this. In those cases, it is sometimes only really possible to identity the title of the webpage and the publishing organisation (usually obvious from the website home page). The authority (i.e. 'reliability') of a citation with no named author rests on the reputation of the publisher. I'm not consistent, though, as citations to various online databases I do often format using cite web. What I think people struggle with is the idea that the webpage is the thing with the 'title' and the 'website' is the 'work', when in the case of a book, the 'work' is the 'title' and bits within it (the webpages in the case of the website) are pages or chapters and so on. What I am saying is that in some cases, it is obvious that the website as a whole is the 'work', but for other websites, they are more a collection of pages that sometimes bear little relation to each other except for being on the same domain name. This is a well-defined website, but this is more a loose grouping of pages published by the same organisation. Does that make sense of the difference I'm trying to describe? Carcharoth (talk) 15:04, 23 August 2016 (UTC)
The documentation is inconsistent and confusing, but sometimes this results from design flaws, such as the dual use of |title= as remarked. Not that this hasn't come up before, it has, several times in the past 5 years (or more). Fixing these flaws (there are several) should be the first order of business. In my mind, this is much more pressing than adding nice little icons, or making sure that machines can exchange metadata, or making the native citation system comfortable for users of other systems. A moratorium on any new features until a clean easy-to-use design emerges, would not be a bad idea imo. Otherwise the rabbit hole may keep getting larger. 72.43.99.146 (talk) 23:31, 23 August 2016 (UTC)
Agree the docs are contradictory and this should be resolved. I would advocate re-documenting {{Cite encyclopedia}} as for being for tertiary sources composed of numerous encyclopedia- or dictionary-style entries (whether it's a multi-author work or not is irrelevant, as a large number, maybe even a majority, of topical specialist encyclopedias and dictionaries are single-author). For my part, any time I'm citing a multi-author academic book composed of papers by authors, presented as chapters, with a volume editor, I use {{Cite book}} and treat the paper/chapter as |chapter=. I one case I ran into trouble because the paper itself had chapters, and I dealt with this with |at= to site both the subchapter and the page number, though technically it was overkill since a page number was probably sufficient. I have not monkeyed with |contribution= much, so I'm not sure how nice it plays with |chapter=; I've always reserved it for forewords, afterwords, and introductions.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:40, 28 August 2016 (UTC)

Adding a "disable italics on work" parameter?

I know there's a history about the use of italics for websites or not (which comes from MOS:TITLE) and whether to use the work= or publisher= parameter to achieve the right effect. We're having a discussion on WT:VG for websites like Rotten Tomatoes and Metacritic which seem to have, in common practice around WP, to not be italicized as websites (as they aren't creative work websites but more as services). Past discussion on CS1 suggests they should be entered as publisher=, but this is not true as they have a separate publishing entity.

The only trick with CS1 that can make these appear non-italic in citations is to italic the name in the template entry , but this has this data passed into wikidata so it is undesirable.

Is it possible if we could get a field like "workni=y" or "wni=y" added to CS1 that, if set, disables the italics on the work= entry, so that we respect the general styling these types of sites have in prose, while also respecting how they are entered as wikidata? If the field is not set (eg applying to all existing templates), then there should be no change in behavior, the work entry is still italicized.

This type of change probably would affect less than 1% of the citations out there, while also making these templates consistent with the openness of MOS:TITLE which does not fully prescribe how to handle websites. --MASEM (t) 16:26, 27 August 2016 (UTC)

Oppose. We need to put to bed any further coddling of people who want to force-format things to suit their personal peccadilloes. People are just going to have to live with the fact that WP is not their personal blog, and has it's own style guide. Every citation style in the world is different in minor details, zero of them satisfy 100% of the people, and probably no one is 100% satisfied with every nit-pick any any of them. People just get over it. If someone is abusing the |publisher= parameter for the |website= title just to force it to not be italic, this is an error and should be reverted.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  06:09, 28 August 2016 (UTC)

I looked over that thread, and the entire thing is just because some people do not think clearly about the difference between a publication, a [re]distribution, and a publishing company, nor bother to figure out what the template parameters are. There is no use case at all in which we could need some |workni=. I've laid this out as a mini-tutorial at Wikipedia talk:WikiProject Video games#This really isn't difficult once you sort it out.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  09:09, 28 August 2016 (UTC)

The problem is that CS1 is forcing a choice that MOS:TITLE does not fully define. MOS:TITLE only speaks to using italics to a specific type of website but does not describes for all websites, and practice (which defines policy not the reverse) clearly shows that we don't italicize certain types of websites in running prose. So CS1 should be flexible to the openness that MOS:TITLE has, and not force a style choice nor encourage poor use of parameters to make a style choice work. --MASEM (t) 14:40, 28 August 2016 (UTC)
??? CS1 is a style, and it is optional. Styles must be internally consistent. Templated styles like CS1 must be standardized. In this optional, templated style, |work= is always italicized. Unless you want to change the font-style rendering of the parameter (a different discussion, imo) I suggest using a different citation style, maybe a non-templated one. 72.43.99.138 (talk) 15:35, 28 August 2016 (UTC)

Url validation

@Trappist the monk: and others: Why is http://нижнийновгород.рф/references/inter/tampere.html not recognized as good url? I found it on one page and error is raised. However, if I copy it in Chrome and paste it – I get form converted into standard latin characters: http://xn--b1acdfjbh2acclca1a.xn--p1ai/references/inter/tampere.html. --Obsuser (talk) 10:17, 25 August 2016 (UTC)

Because the domain name is not written using the Latin character set. When you paste that url into Chome, it translates it into an internationalized domain name so that the internet infrastructure can understand it. Module:Citation/CS1 uses the standardized rules for domain name validation which requires domain names to be in the Latin character set.
—Trappist the monk (talk) 11:23, 25 August 2016 (UTC)
Using Firefox, I don't find any difference between the two types of url: both work well. --Mauro Lanari (talk) 11:44, 25 August 2016 (UTC)
The translation is still done; firefox apparently doesn't show that it is done.
—Trappist the monk (talk) 11:48, 25 August 2016 (UTC)
We have a magic word, {{urlencode:}}, that could be used to wrap URLs like that provided by the OP. Can this be built into CS1's Lua module? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:30, 30 August 2016 (UTC)
Different kind of encoding. Percent-encoding is not ASCII Compatible Encoding. Here is what the magic word produces:
http%3A%2F%2F%D0%BD%D0%B8%D0%B6%D0%BD%D0%B8%D0%B9%D0%BD%D0%BE%D0%B2%D0%B3%D0%BE%D1%80%D0%BE%D0%B4.%D1%80%D1%84%2Freferences%2Finter%2Ftampere.html
—Trappist the monk (talk) 17:59, 30 August 2016 (UTC)
Is there some other template that will do the job, then? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:30, 30 August 2016 (UTC)

New access-date check leads to bad bot proposal

I understand that the date validation code now produces an error message if the access date is not precise to the day:

  • {{cite journal | title = Three-body problem, the measure of oscillating types. A short review | url = http://journals.cambridge.org/action/displayIssue?jid=IAU&volumeId=9&issueId=S310 | access-date = August 4, 2016 | last1 = Marchal | first1 = Christian | journal = Proceedings of the International Astronomical Union | date = July 2014 | pages = 43–44 | volume = 9 | issue = S310}}

    Marchal, Christian (July 2014). "Three-body problem, the measure of oscillating types. A short review". Proceedings of the International Astronomical Union. 9 (S310): 43–44. Retrieved August 4, 2016.

  • {{cite journal | title = Three-body problem, the measure of oscillating types. A short review | url = http://journals.cambridge.org/action/displayIssue?jid=IAU&volumeId=9&issueId=S310 | access-date = August 2016 | last1 = Marchal | first1 = Christian | journal = Proceedings of the International Astronomical Union | date = July 2014 | pages = 43–44 | volume = 9 | issue = S310}}

    Marchal, Christian (July 2014). "Three-body problem, the measure of oscillating types. A short review". Proceedings of the International Astronomical Union. 9 (S310): 43–44. Retrieved August 2016. {{cite journal}}: Check date values in: |access-date= (help)

The unfortunate response to these error messages is a proposal to falsify all the old imprecise access dates by using a bot to falsely assert the access occurred on the first of the month: Wikipedia:Bot requests#Fix thousands of citation errors in accessdate

Of course, the only ways to "correct" an old access date is to have the editor who accessed the source to provide the day of the month the access occurred, or to revisit the source and provide the date of the revisit (provided, of course, the source in its current form still supports the claim(s) in the article. Jc3s5h (talk) 16:31, 4 August 2016 (UTC)

Or remove the access date for articles with DOI or other identifiers, per the {{cite journal}} documentation. – Jonesey95 (talk) 18:29, 4 August 2016 (UTC)
Or have the bot access the url in the citation and if error=0 input the date of the bot access. If any webpage-related http errors appear (404 etc.) remove |access-date= altogether. Then, in phase 2, the bot could check to see whether in pages that it successfully accessed, the content actually verifies the respective citations. That 1. could keep bot writers busy for a few years/decades, and therefore, 2. keep CS1 relatively unsullied. 65.88.88.127 (talk) 21:15, 4 August 2016 (UTC)
Use the date the URL was added to the article which the BOT could extract from the history. Keith D (talk) 00:21, 5 August 2016 (UTC)
That may or may not be the date the source was accessed. Revision date does not automatically imply access date. Also, inputting a prior (or forward) date violates WP:SAYWHEREYOUGOTIT. Only the editor who accesses the source can make such corrections after the fact. 72.43.99.146 (talk) 00:37, 5 August 2016 (UTC)

One solution would be to only output the error warning if the MM YYYY date is Sept 2016 or later (or a year of 2017 or later) - thereby catching (mostly) new instances, but not historic ones. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:30, 6 August 2016 (UTC)

Why should past instances be ignored? They are still wrong. Not flagging such obvious incogruities diminishes confidence in the encyclopedia. 64.134.101.16 (talk) 19:25, 6 August 2016 (UTC)
Firstly, they are not wrong, although they may be imprecise. And they should not generate an error for that reason, and for the reasons stated above, in this section. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:51, 11 August 2016 (UTC)
Since we are discussing the date when an anonymous editor claims to have verified the particulars of a citation by accessing it, not entering the exact, full date this happened is a bit more than imprecise, or careless, or just not following the correct procedure. Entering such exact information is as easy as not entering it. Therefore, other questions now arise. Afaic, something is wrong with such a citation and it should be flagged. 65.88.88.127 (talk) 19:43, 11 August 2016 (UTC)

Partial access dates

CS1 is generating an error if |accessdate= is partial. For example these generate an error:

|accessdate=2015
|accessdate=May 2015

This is good:

|accessdate=May 1, 2015

The number of articles impacted is 14665 in 32255 citations. The error is a new feature added recently from Help_talk:Citation_Style_1/Archive_19#incomplete_access_dates. This led to a proposal for a bot fix: Wikipedia:Bot_requests#Fix_thousands_of_citation_errors_in_accessdate .. However the Oppose camp do not believe an access-date with two parameters (Month Year) should generated a CS1 error. There is no way to fix 32255 citations without a bot, and no way to do a bot without consensus for the error message.

  1. Should CS1 generate an error in accessdate's with only a year |accessdate=2015 ?
  2. Should CS1 generate an error in accessdate's with only a month year |accessdate=May 2015 ?

Pinging previously involved parties: @Trappist the monk, 72.43.99.138, Matthiaspaul, 65.88.88.62, Rfassbind, Jonesey95, Jc3s5h, Cyberpower678, Redrose64, Magioladitis, PBS, Tom.Reding, BabbaQ, and Finnusertop:

Note: this is not an RfC please consider discussion rather than vote-style. If we need an RfC it will become evident and we can announce to the community a separate RfC here or Village pump. -- GreenC 16:56, 30 August 2016 (UTC)

It should. Having accessed an article in August 2015 doesn't help you if the page got updated on August 17th of that year. You the day needs to be specified for that reason, as recommended by every style guide out there. Bots can retrieve the date a link got added (with some fancy logic to rule out corner cases) to take care of most of those. Headbomb {talk / contribs / physics / books} 17:10, 30 August 2016 (UTC)
The templates should not generate error messages if the access date is earlier than the date the "feature" was added to the templates. Jc3s5h (talk) 17:30, 30 August 2016 (UTC)
@Headbomb In practice there is little point to the precise date to the day because in the example you gave let us suppose that the accessdate was 2 August 2015 and the page was updated on 17 August. Then August 2015 is sufficient to check for the nearest update in the archives of a page, because the day is normally irrelevant as one is usually lucky if there is more than a couple of archives a year for most web sites. As a practical example take the article Prussian Trust and the archive links Polish Foreign Affairs German Foreign Office, as by chance there is an additional access date on a third citation set to "December 2006" which is not strictly necessary as the date of the article is given as 18 December 2006, but to red flag the accessdate is I think unnecessary. This an interesting page to use as an exaple because the comments by the foreign office/affairs change relatively frequently so the only hope of capturing the text is via web archives. -- PBS (talk) 18:19, 30 August 2016 (UTC)
  • Comment' Help talk:Citation Style 1/Archive 19#incomplete_access_dates: Two user accounts and an IP address should not be making changes to templates that end in a bot making mass changes to thousands of articles. As there are relativity few people changing the Module:Citation/CS1 because few know how to modify such code as few editors know Lua, those that do ought not to make changes like this without wide consultation first. There is far too cavalier attitude to making changes to the LULA functions that affect thousands of articles with next to no wider consultation. I think that changes like this to the CS1/CS2 templates ought not to be made unless there is a well attended RfC to agree the change, otherwise the status quo should prevail. -- PBS (talk) 18:36, 30 August 2016 (UTC)
The discussion was initially about year-only of which there were around 100 cases. That is reasonable. Somehow that morphed into requiring full dates without thinking through the scale of errors generated by Month Year cases. -- GreenC 21:40, 30 August 2016 (UTC)
  • I'm impartial to whether or not they should be complete or not. I know I have a way of reasonably extrapolating the true access-date if we want a bot to do this, and no, it's not by putting a 1 as the day.—cyberpowerChat:Limited Access 19:08, 30 August 2016 (UTC)
  • Comment—the dates should be complete to the day, and if they aren't, they should flag an error. Major style guides follow this best practice, and so should we. Imzadi 1979 → 22:47, 30 August 2016 (UTC)

Here is a bit of history. The current cs1|2 documentation defines |access-date=:

  • access-date: Full date when the content pointed to by url was last verified to support the text in the article; do not wikilink; requires url; use the same format as other access and archive dates in the citations. Not required for linked documents that do not change. For example, access-date is not required for links to copies of published research papers accessed via DOI or a published book, but should be used for links to news articles on commercial websites (these can change from time to time, even if they are also published in a physical medium). Note that access-date is the date that the URL was checked to not just be working, but to support the assertion being cited (which the current version of the page may not do). Can be hidden or styled by registered editors. Alias: accessdate.

For this discussion, the important bit of that definition is the first two words. I wondered when the 'full date' requirement entered the documentation so I trolled through the template doc histories of the five most commonly used cs1|2 templates:

  1. {{citation}}
    3 Jun 2007 – first documentation of access date does not require full date
    14 Jan 2012 – addition of {{Citation Style documentation/url}} requires full date
    12 Jan 2012 – first version of {{Citation Style documentation/url}} requires full date
  2. {{cite web}}
    31 Aug 2006 – first template documentation requires full date
  3. {{cite journal}}
    12 Sep 2006 – first template documentation requires full date
  4. {{cite news}}
    16 Aug 2006 – first template documentation does not require full date
    7 Oct 2008 – documentation change requires full date
  5. {{cite book}}
    9 Sep 2006 – first template documentation requires full date

—Trappist the monk (talk) 11:24, 31 August 2016 (UTC)

Free-to-read icon

In Module:Citation/CS1/Configuration/sandbox:135, I vertically aligned the green lock icon that appears after PMC identifiers () and added an entry to {{cite journal/testcases}}. The change is minor and straightforward, but given the propagation of the change, I’m checking in here first. Thank you. —LLarson (said & done) 18:42, 5 August 2016 (UTC)

I'm going to undo that part of your change. We did this comparison earlier at Help talk:Citation Style 1#adding free-to-read icons (I've modified that test here to use the same image as is used in the Module:
qK
and here's another:
[]
and with your change:
qK
[]
—Trappist the monk (talk) 19:08, 5 August 2016 (UTC)
Thanks as always, Trappist! What about this though?
Current:
qKOpen access icon
[]Open access icon
Proposed:
qKOpen access icon
[]Open access icon
—LLarson (said & done) 19:22, 5 August 2016 (UTC)
Looks to me like the {{open access}} lock is too high. It should be lowered so that it more-or-less spans the distance between the lowest descender and the highest ascender.
—Trappist the monk (talk) 20:36, 5 August 2016 (UTC)
I also find it more natural to have the main circle at the same height as a "o" letter (so, LLarson's proposal) − Pintoch (talk) 20:50, 5 August 2016 (UTC)
I'm on Team LLarson for height. Headbomb {talk / contribs / physics / books} 20:22, 9 August 2016 (UTC)
Quick question, but what is the difference in the meaning of the green "free to read" icon () and the orange "open access" icon (Open access icon)? --bender235 (talk) 16:46, 24 August 2016 (UTC)
As I understand it, the orange icon is meant to identify sources that are free to reuse. The green only indicates that the source may be read without cost to the reader. Reuse rights are determined by agreement between the publisher and the author(s).
—Trappist the monk (talk) 16:51, 24 August 2016 (UTC)
Hmm, well if so, then the "open access" icon suggested for Newspapers.com citations is wrong, isn't it? --bender235 (talk) 17:50, 24 August 2016 (UTC)
I think you're right, that use of the orange icon there is inappropriate. I don't think that newspaper.com urls in a cs1|2 template need either of these icons because the norm for urls that link title-holding parameters in cs1|2 templates is that the linked source can be read without the reader jumping through registration or paywall hoops.
—Trappist the monk (talk) 19:00, 24 August 2016 (UTC)
The suggestion for Newspapers.com links is to use clippings which do not require registration. Others can read the clipping, but they'd need an account to see the rest of the page from which it originated. Imzadi 1979 → 21:14, 31 August 2016 (UTC)

Porting into another wiki with localisation

I've tried to port the module code into the local wiki and found out that the $1 value in element 'mult_names' in this module may not be localisable. Is anyone know how to localise the value for that? (typically the $1 maybe "authors list", "editors list" or similar.) Shinjiman ⇔ ♨ 05:58, 30 August 2016 (UTC)

I think that you need to better explain what the problem is. What and where is the local wiki? Does the module properly render author lists, editor lists?
—Trappist the monk (talk) 09:41, 30 August 2016 (UTC)
Forgot to mention the module would be modified was listed in zh-yue:Module:Citation/CS1/Configuration. And seems by the current code, the category name which cannot be localised (like that one listed below). :D Shinjiman ⇔ ♨ 14:00, 30 August 2016 (UTC)
['mult_names'] = 'CS1 maint: Multiple names: $1', -- $1 is authors or editors

As an experiment, I've created a special_case_translation table in Module:Citation/CS1/Configuration/sandbox, provided the English words that replace $1 in the category names for mult_names and disp_auth_ed, and made the appropriate changes to extract_names(), name_has_mult_names(), and get_display_authors_editors():

Cite book comparison
Wikitext {{cite book|author=blue, black, brown|title=Title}}
Live blue, black, brown. Title.{{cite book}}: CS1 maint: multiple names: authors list (link)
Sandbox blue, black, brown. Title.{{cite book}}: CS1 maint: multiple names: authors list (link)
Cite book comparison
Wikitext {{cite book|author2=black|author3=brown|author=blue|display-authors=6|title=Title}}
Live blue; black; brown. Title. {{cite book}}: Invalid |display-authors=6 (help)
Sandbox blue; black; brown. Title. {{cite book}}: Invalid |display-authors=6 (help)

Does this work in your application?

—Trappist the monk (talk) 15:42, 30 August 2016 (UTC)

Seem this one works, verified in zh-yue:鄧芝 as an example. :) Shinjiman ⇔ ♨ 01:43, 1 September 2016 (UTC)
Good. I'll leave the translation table in the en.wiki module.
—Trappist the monk (talk) 11:12, 2 September 2016 (UTC)

Inconsistency between older documentation and template data re: location vs. place?

Hi, in the older documentation it says that place is the preferred parameter, and that location is an alias of place. However, in most of the examples, location is used, and also the template data uses location as the parameter and does not use place at all (which is funny because the copied over description in TD claims it's an alias). Which is it? Should the templatedata be fixed to reflect the older documentation, or should the description of location/place be fixed? Mvolz (WMF) (talk) 13:56, 2 September 2016 (UTC)

It looks like the documentation used to list |location= as the preferred identifier. The documentation was changed on 6 May 2013 by Gadget850, who added documentation for |publication-place= in the same edit. I was unable to find a corresponding discussion on the talk page.
Almost every template I have seen that populates |location= or |place=, perhaps 99%, uses |location=. I recommend changing the documentation to show |location= as the preferred parameter and |place= as an alias, although functionally, it makes no difference. – Jonesey95 (talk) 14:53, 2 September 2016 (UTC)
The cs1|2 templates rarely, if ever, have 'preferred' parameters. In your example, |place= was the term that the contributing editor chose to 'define' (you will also notice that in the same definition, the editor uses the alias |location=).
Should template data be fixed? Hell, yes! Keeping and maintaining two separate and wholly incompatible sets of documentation is madness.
—Trappist the monk (talk) 14:54, 2 September 2016 (UTC)

Protected edit request on 4 September 2016


Prospect Reservoir - just edited up the access dates because the day had been left off two. They now show correctly, were showing a red error for check dates.

The 4th reference, a cite journal, the previous two are cite web, it will show the error if it is present, but when the syntax is correct it doesn't show in the displayed text.

Dave Rave (talk) 08:16, 4 September 2016 (UTC)

 Not done
No specific request made. The template appears to be rendering correctly.
—Trappist the monk (talk) 09:41, 4 September 2016 (UTC)
The cite journal reference that I think you are concerned with, has a doi id. Access date is superfluous. Perhaps the doc should make it clearer that some ids exclude access dates. 72.43.99.138 (talk) 14:28, 4 September 2016 (UTC)

cs3 for a new separator.

A recent technical change to Template:nlab to use cite-web broke the display style there. It dropped the word "in", and I can't figure out how to reinstate it. Viz. it now reads, for example, Pointed object at the nLab whereas it used to read, last week, Pointed object in nLab. (without the quotes, with the word "in"). The new format is awkward and visually ugly, and (most importantly) confusing to look at (to non-afficionados who may not know what ncatlab is). So... I'd like to get the old display style back, while keeping whatever the technical reasons are for converting the the cite-web template. It would seem that proposing a mode=cs3 that drops the quotes, and adds the word "in" is the only way to do this. Is there another way? How can we get the technical advantages(?) of using cite-web, and still get the prettier formatting of the older template? 67.198.37.16 (talk) 19:03, 2 September 2016 (UTC)

That would be a heck of a change to accommodate one external link template that is used just a few times. The more straightforward way to get what you want would be to discuss the change on the template's talk page or at the relevant WikiProject and decide whether the template should use the cite web template at all. Since it is used to link to a wiki, using the cite web template may be misleading to editors and may lead them to use it in references instead of just in external links. – Jonesey95 (talk) 20:52, 2 September 2016 (UTC)
that would result in us loosing all the other advantages of wrapping {{Cite web}}, such as validation, and COinS. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:02, 2 September 2016 (UTC)
OK, never mind, I'm just being stupid, there is an obvious alternative. 67.198.37.16 (talk) 17:09, 3 September 2016 (UTC)
Yes; you've canvassed another editor to revert my changes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:11, 7 September 2016 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1/Archive_23&oldid=1041552477"