| Revision as of 19:54, 8 October 2015 editTenebrae (talk | contribs)Extended confirmed users155,424 edits comment← Previous edit | Latest revision as of 11:46, 7 January 2025 edit undoClueBot III (talk | contribs)Bots1,378,498 editsm Archiving 2 discussions to Help talk:Citation Style 1/Archive 97. (BOT) | ||
| Line 1: | Line 1: | ||
| <!-- Deny citation bot April 2015 because we often post broken citations here intentionally and do not want them to be "fixed" -->{{bots|deny=Citation bot,SporkBot}}<!-- | <!-- Deny citation bot April 2015 because we often post broken citations here intentionally and do not want them to be "fixed". To avoid AnomieBOT substing, use |demo= or |nosubst= instead of adding it here. -->{{bots|deny=Citation bot,SporkBot,Cewbot}}<!-- | ||
| -->{{ |
-->{{skip to bottom}}<!-- | ||
| -->{{talk header|display_title=Help:Citation Style 1 and the CS1 templates|WT:CS1}} | |||
| {{Help Project|importance=High|class=B}} | |||
| {{central|text=the talk pages for all Citation Style 1 and Citation Style 2 templates and modules redirect here. A list of those talk pages and their historical archives can be found ].}} | |||
| {{WikiProject banner shell|collapsed=yes|1= | |||
| {{Misplaced Pages Help Project|importance=High}} | |||
| {{WikiProject Academic Journals}} | |||
| {{WikiProject Magazines}} | |||
| }} | |||
| {{User:ClueBot III/ArchiveThis | {{User:ClueBot III/ArchiveThis | ||
| |archiveprefix=Help talk:Citation Style 1/Archive | |archiveprefix=Help talk:Citation Style 1/Archive | ||
| |format= %%i | |format= %%i | ||
| |age=480 | |||
| |numberstart=3 | |||
| |header={{Automatic archive navigator}} | |||
| |age=720 | |||
| |headerlevel=2 | |||
| <!-- |index=yes --> | |||
| |maxarchsize=200000 | |||
| <!-- |archivebox=yes --> | |||
| |minkeepthreads=6 | |||
| |box-advert=yes | |||
| |numberstart=69 | |||
| |minkeepthreads=1 | |||
| |minarchthreads=2 | |||
| |maxarchsize=500000 | |||
| }} | }} | ||
| {{Banner holder|collapsed=yes| | |||
| {{Help talk:Citation Style 1/Centralized discussions}} | |||
| {{tmbox | |||
| {{Auto archiving notice |bot=ClueBot III |age=30 |units=days |small=yes}} | |||
| | type = notice | |||
| | image = ] | |||
| == Feature request: |note= parameter == | |||
| | imageright= ] | |||
| | text = Some of the templates discussed here were considered for ] at ]. Please review the prior discussions if you are considering re-nomination: | |||
| It'd be nice to have a {{para|note}} parameter, so that things like "Source is a blog, but published by a project of the city government; primary but not self-published.", kept with (inside) the citation instead of external to it in an HTML comment. It's pretty common to to use a pseudo-parameter like {{para|note}}, or (in other contexts, like cleanup/dispute templates) {{para|reason}}, for this purpose, but CS1's auto-detection and red-flagging of unrecognized parameters makes this impossible at present. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 16:06, 15 July 2015 (UTC) | |||
| *"'''Withdrawn'''" proposal to merge ] with ] on March 2, 2018, see ]. | |||
| :It would be nicer still to have a {{para|null}} to work around the red-flagging because there are time when as SMcCandlish unrecognized parameters are convenient. -- ] (]) 22:56, 15 July 2015 (UTC) | |||
| ::I think the problem with the example above is that all of the other parameters in CS1 are for bibliographic data that theoretically at least is understandable to readers and meaningful outside Misplaced Pages. Whereas that comment would be understandable to maybe 1 or 2 out of every 1,000 Misplaced Pages readers – the ones who are familiar with what WP editors usually mean when they call a source "primary". For that sort of thing, an HTML comment embedded in the wikitext seems like exactly the right way to handle it. Let's keep meta comments and WP-specific issues separate from the data. – ] (]) 11:21, 16 July 2015 (UTC) | |||
| :::SMcCandlish is not proposing a display variable, but one to be used in place of <code><nowiki><!-- a hidden comment --></nowiki></code> as the parameter {{para|reason}} is used in the template {{tl|Clarify}}. -- ] (]) 19:35, 16 July 2015 (UTC) | |||
| ::::I can see the advantage of a {{para|note}} parameter. I find the {{para|others}} parameter very useful - today I've used it to flag "(published anonymously)". Library catalogs sometimes use square brackets for this. ] (]) 20:19, 16 July 2015 (UTC) | |||
| :::::Like this from ]?: | |||
| ::::::<code><nowiki>{{ cite book | last=Leach | first=William Elford | author-link=William Elford Leach | year=1820 | chapter=Eleventh Room | title= Synopsis of the Contents of the British Museum | place=London | publisher=British Museum | edition=17th| pages=65-70 | others=(published anonymously) }}</nowiki></code> | |||
| :::::Specifically these bits: | |||
| ::::::<code><nowiki>| publisher=British Museum</nowiki></code> and <code><nowiki>| others=(published anonymously)</nowiki></code> | |||
| :::::One contradicts the other. And, from the template documentation at ]: | |||
| :::::*'''others''': To record other contributors to the work, including illustrators and translators. For the parameter value, write ''Illustrated by John Smith'' or ''Translated by John Smith''. | |||
| :::::I think that your use of {{para|others}} as {{diff|Finch|671678177|671554256|you have done}} is an improper use of the parameter. | |||
| :::::—] (]) 22:23, 16 July 2015 (UTC) | |||
| ::::::I was well aware that my use was "improper" but I had wanted to say that the author wasn't specified rather than the publisher wasn't specified. I've now deleted the parameter.] (]) 07:05, 17 July 2015 (UTC) | |||
| :::::::At ] it now says: "The name of the author is not specified in the document." If that is so, then who is <code><nowiki>| last=Leach | first=William Elford</nowiki></code>? | |||
| :::::::—] (]) 09:31, 17 July 2015 (UTC) | |||
| ::::::::I was trying to simplify as this isn't an important reference. In the Finch article I've actually cited two sources - the other is Bock 1994. It is Bock who gives the information about the publication: "All the parts of this public guide to the British Museum are unsigned, however, this part was clearly written by Leach as indicated by the fact that he was Keeper of Zoology at the time and by the numerous references to Leach's list of family-group names by his contemporaries." I'm reluctant to add a notelist with this info. It is not uncommon to have "unsigned" articles. I've met them in 19th century book reviews. Sometimes there is a RS giving the authors name. I've seen square brackets used in references when the information isn't present on the title page - such as the author or the year of publication. ] (]) 10:17, 17 July 2015 (UTC) | |||
| :::::::::If ''Synopsis ...'' doesn't identify the authors then <code><nowiki>| last=Leach | first=William Elford | author-link=William Elford Leach</nowiki></code> should be removed from that citation. You might then change the note to read: "Attributed to ] in Both 1994." I'm not at all sure that this is even important. Will knowing that Both thinks that Leach wrote "Eleventh Room" help readers find a copy of ''Synopsis ...''? | |||
| :::::::::—] (]) 12:13, 17 July 2015 (UTC) | |||
| {{od}}The conversation has moved a long way from ]'s request for a {{para|note}} parameter to allow a hidden editor to editors message, similar to {{para|reason}} in the cleanup templates. -- ] (]) 21:23, 30 July 2015 (UTC) | |||
| :And it would actually serve the purpose Aa77zz has in mind, anyway. So, I renew the request. All fields I'm aware of, including physical sciences, social sciences, humanities, law, etc., that regularly cite sources do in fact have definitions of "primary source" and so on (even if they sometimes differ in their particulars), so the objection to my example isn't even valid. And it was just an example. There are any number of reasons to use such a parameter, e.g.: | |||
| :*{{para|note|Titled "Blood of the Isles" in the UK printing.}} | |||
| :*{{para|note|Paywall can be bypassed by request at {{var|URL here}}.}} | |||
| :*{{para|note|Page 17 is missing from this Project Gutenberg scan, but is not part of the cited material.}} | |||
| :*{{para|note|There is a newer edition, but the cited section has not changed, according to {{var|URL to changes list}}.}} | |||
| :*{{para|note|This is a master's thesis, but was reviewed by {{var|Notable Researcher Here}}, and has been cited in 12 journal papers as of July 2015.}} | |||
| :etc. There's no reason to put these in messy HTML comments that some editors are apt to delete on sight because they don't like HTML comments. And, really, no one's head will asplode if someone happens to include a more WP-jargon-specific note. They'll just shrug and move on. No one will see them but wikitext-editing users anyway. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 23:15, 30 July 2015 (UTC) | |||
| : Are you hoping that the note will appear when a user mouses over the tag as with {{tlx|clarify-inline}} ? ] (] • ]) 08:12, 22 August 2015 (UTC) | |||
| ::That might be useful, sure, but was not central to the nature of the request, which is about keeping these notes with (i.e., inside) the citations, so that nothing is put between them, etc. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 12:50, 12 September 2015 (UTC) | |||
| ==Italicization of websites in citations== | |||
| {{Stale|Discussion has moved on, to ].}} | |||
| If I may revive an (pardon me if there are other threads), I don't understand why we are italicizing websites (thru the {{para|website}} parameter) in citation templates. The argument seems to be that the alias of {{para|website}} is {{para|work}} (meaning you can use one or the other but not both) and obviously {{para|work}}, {{para|journal}}, etc. should be italicized. But the plain fact is that, per the MOS, while we italicize the names of publications, we (generally) do not do so for websites. So these parameters should not be interchangeable. For example: ], ], BroadwayWorld.com and other sites and urls should not be italicized. And while for content found in both a print publication and on its website I may cite '']'' or '']'', if the actual url is being cited (Advocate.com or EW.com) it should not be italicized. This seems like a no-brainer.— ]<sup>]</sup> 21:16, 31 July 2015 (UTC) | |||
| :"Generally" is the key word here, though. The vast majority of the time when a WP article is referring to a website, it's referring to it a business entity (or other kind of entity, e.g. a nonprofit, a free software coding group, a government project, whatever), or in a functional way, e.g. as a service or product. But when we cite it as a source, we're referring to it as a major published work, like a book, journal, magazine, film, etc. So, whether the italics are "required" or not, they're definitely not incorrect when applied in this case. It's consistent and uncomplicated for us to continue italicizing them in source citations. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 09:53, 1 August 2015 (UTC) | |||
| ::As a journalist and editor, I need to disagree with the premise that when we cite ], or the ] or ] that these entities transmogrify into "a major published work, like a book, journal, magazine, film, etc." | |||
| ::No mainstream source italicizes Amazon.com, British Board of Film Classification, Marvel.com, or, for that matter, ] or ], and none of these entities ''themselves'' italicize their names. | |||
| ::Italicizing dotcom names is not done anywhere else, and I'm afraid I can't find a valid reason that Misplaced Pages should create a non-traditional form of punctuation. Indeed, not even Misplaced Pages italicizes these entities in their respective articles. So I'd like to ask for what compelling reason we do so here. --] (]) 19:43, 29 August 2015 (UTC) | |||
| :::I agree. Entirely. ~ ] (]) 22:25, 30 August 2015 (UTC) | |||
| ::::With what, though? Half of that wasn't cogent. British Board of Film Classification is a publisher, not a work of any kind, and what source italicizes itself (except as an incidental stylistic matter)? Looking at an entire bookshelf, only a tiny handful of covers have italic titles, and if you look at the actual title on the frontispiece, and at the top or bottom of each (or every other) page in the book, it is not italicized. This tells us nothing at all about whether WP would italicize the book title in a citation to it. ] of "transmogrification". What I actually said was 'when we cite as a source, we're referring to it as a major published work, like a book, journal, magazine, film, etc. So, whether the italics are "required" or not, they're definitely not incorrect when applied in this case. It's consistent and uncomplicated for us to continue italicizing them in source citations.' This argument has not actually been responded to at all. Instead, Tenebrae told us what some other publishers are doing, and made some unrelated observations. But WP's citation system is not that of any other site or publication, and no case has been made for why WP should treat the titles of all major works consistently (italicizing them by template) except when they're online publications. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 23:21, 30 August 2015 (UTC) | |||
| :::::The problem is with how the website parameter is used. Since it's a synonym for work, it should only be used when a work is given as the value. "Amazon.com" is not a work. ] (]) 00:59, 31 August 2015 (UTC) | |||
| ::::::Exactly. ''Titles'' can be italicized, so we could have ''Amazon.com'', but ''only because it is a title'', not because it refers to a url. As to usage outside of WP: while some aspects of other styles are questionable, and often contradictory, it is still a good idea to consider them: 1) They often reflect a lot of hard-earned experience, and it would be shameful waste to insist on having to re-experience more than is useful. 2) Making WP more different than standard uses makes it harder to edit, and can even lead to subtle problems of reading. ~ ] (]) 18:06, 2 September 2015 (UTC) | |||
| :::::::As ] rightly notes, "Amazon.com" is not a work or a title. "Rotten Tomatoes" or "Rotten Tomaotes.com" are not titles. "Sears.com" is not a title. Though I certainly agree with ] that no other reference source, nor newspapers or magazines, italicize dotcom names. There is no reason for Misplaced Pages to have a nonsensical deviation from every grammatical standard in this regard. --] (]) 21:40, 2 September 2015 (UTC) | |||
| {{od}}I think you all are missing a couple key things here: | |||
| #the name of the website very rarely includes the domain space (.com, .org, etc)...eg. it's "Misplaced Pages" not "Misplaced Pages.org" | |||
| #citation styles are, generally, an exception to the MoS...the citation styles are intended to reflect common citation styles. Of the common citation styles, condsider how the following handle the names of websites: | |||
| :#MLA (scroll down to the section "A page on a website") | |||
| :#Chicago | |||
| :# generally doesn't include the name of a website that's not scholarly website (eg. an online journal), but instead uses "Retrieved from ". | |||
| :# and also does not include the name of the website, but rather the url | |||
| :# (see page 5) does not italicize the name of the website, but includes "internet" in brackets after the website name, for example: Misplaced Pages . | |||
| While there are many exceptions, websites are generally a work/publication. Of the citation styles that include the name of the website, the two general style guides (MLA and Chicago) both italicize the name of the website, while the Vancouver style guide is generally reserved for the physical sciences. ] (]) 01:58, 3 September 2015 (UTC) | |||
| :I don't think we need to research varied style guidelines. It's already established that websites/urls are generally not italicized at Misplaced Pages, and I'm not aware that we have separate formatting conventions for citations in this regard. The fact that cite templates equate "website" with "work" is the problem, because while one or the other should be required, they do not have the same established formatting style. Period. If I'm citing EW.com, I actually cite |work=] because the website is an obvious platform of that publication. But when you cite a website not affiliated with a conventional publication, yes it may be considered a "major published work" in the sense that it is a reliable source, but I don't see why it should be italicized when it does not meet the criteria for that formatting, and would not be italicized in other contexts at WP. I get SMcCandlish's basic argument, but it is not as if there a requirement somewhere that ''something'' has to be italicized in each citation, or that the source has to be italicized no matter what it is.— ]<sup>]</sup> 19:24, 3 September 2015 (UTC) | |||
| :::Okay, we need some clarification here, as it seems that "'''website'''" is being used in several different ways. Note that websites usually have a ''proper name'', such as "Google", "The New York Times", "Entertainment Weekly", and "Rotten Tomatoes". Websites also have ''hostnames'', such as (resp.) "www.google.com", "www.nytimes.com", "ew.com", and "wwww.rottentomatoes.com", which often (but not always) incorporate some form of the website's (or parent entity's) name. Hostnames are usually part of ]s (but see below), and as such have specific form and usage in the context of the Internet. ''As hostnames (URLs)'' they are '''not''' italicised, nor capitalized. What are italicized are ''titles'', such as the names of ''books'', ''periodicals'', and (generally) ''works''. A book title in the ''form'' of a hostname, such as ''Amazon.com'', would be italicized, but only because it is a title. | |||
| :::It seems to me the real issue here is what constitutes a '''title'''; particularly, the ''name'' of a source. "The New York Times" and "Entertainment Week" are the names of both publications and their associated websites; "nytimes.com" and "ew.com" are not. (''Entertainment Weekly'' could have named their website "EW.com", in which case it could be a title, but they did not.) Note that a further distinction can be made between a publi''sher'' and a publi''cation'' (or work). E.g., "Amazon" (the website) might be the publisher of a reveiw found there, but is it a publication? ~ ] (]) 21:34, 3 September 2015 (UTC) | |||
| ::::Amazon, or Amazon.com, indeed is not a publication. Neither is the publisher Simon & Schuster or simonandschuster.com. Likewise, Sears.com is not a publication, and citing, just for example, the number of stores that Sears owns would be to the website Sears.com, and not ''Sears.com.'' | |||
| ::::] is correct that if we're citing something created by the editorial department of '']'' or '']'', we credit the publication rather than ew.com or nytimes.com, and these publications of course are italicized. In such cases, we use "work=" or "newspaper=" or "journal=". But neither ] nor blackanddecker.com is italicized. Same with ] or homedepot.com. | |||
| ::::The sensible solution, I believe, is to have the "website" field not italicize its contents. That way we're not putting in " ''Amazon.com'' " or " ''Sears.com'' ". If we're citing an actual publication, we have three different fields we can use. --] (]) 22:48, 3 September 2015 (UTC) | |||
| :::::Careful! You seem to be sliding back to confusing the ''name'' (as in a ''proper name'') of a website with its ''hostname''. E.g., "Sears.com" is not the name of a website, so should not be put in anywhere. If you want to cite something from the ''Sears'' website (''located'' at "www.sears.com"), then you cite that, not its hostname. If a website is a publication (e.g., "Rotten Tomatoes") then its ''name'' is properly italicized. ~ ] (]) 23:27, 3 September 2015 (UTC) | |||
| ::::::I don't think I am. And I think you are the only person on this thread making the argument that Amazon.com should be italicized. And, certainly, no one italicizes Rotten Tomatoes, not even Rotten Tomatoes, as it is not, by any definition, a publication. | |||
| ::::::What do the other editors think? Aside from one holdout, the consensus seems to be to have the "website" field be non-ital. Do we need to create a formal RfC, or have we reached consensus? --] (]) | |||
| :::::::If all sources are italicized, including sources that contain the cited work, then websites should be italicized for both stylistic consistency and semantic reasons (e.g. to distinguish a webpage or section from the hosting website). <small class="autosigned">— Preceding ] comment added by ] (]) 21:43, 5 September 2015 (UTC)</small><!-- Template:Unsigned IP --> <!--Autosigned by SineBot--> | |||
| :::::::T: You don't seem to understand the distinction I am making, and have thereby misstated my view. Note: I believe we have no disagreement that (e.g.) '''titles''' can be (even should be) italicized. Also, that '''hostnames''' - such as found in URLs, and when ''used as hostnames'' - are NOT italicised. What you don't seem to understand is the {{hilite|use of a hostname in other contexts}}, such as in a title, '''or as the proper name of a website'''. Where I say that "'''A'''mazon.com" - note the capitalization, which is generally not done in urls - ''could'' be italicized it is very much dependent on it being used in the context of a title (like of a book) or proper name. That you think there is consensus to not italicize "website" is only because you have conflated "website" with "hostname". This is indicated by your earlier reference to "{{tq|dotcom names}}". Strictly speaking, there no such things, except in the casual use of "XXXX.com" to refer to the website of some company XXXX. While such uses are in the fashion of a hostname, simply adding ".com" to some name does not make it a hostname, and does not exclude it from italicization. ~ ] (]) 22:05, 5 September 2015 (UTC) | |||
| ::::::::I believe this is a valid point. The print product Grapes of Wrath, delivered by a printer, is not the book ''Grapes of Wrath'' delivered by a publisher. The digital product Amazon.com, delivered by a software developer, is different from the website ''www.amazon.com'' delivered by an online publisher. In most cases what is cited as the source is the content, not the "delivery method/packaging", as it were.] (]) 14:43, 6 September 2015 (UTC) | |||
| {{outdent}} | |||
| I can only repeat my previous point. At present, {{para|website}} is simply a synonym of {{para|work}}, and so its value should be italicized, in line with the usual style for a work. It would be possible to give the two parameters a different meaning, but this would require a huge number of existing uses to be checked. Since "website" seems to be widely misunderstood, perhaps its use should be deprecated? ] (]) 19:28, 6 September 2015 (UTC) | |||
| :I agree that "website" (as in "work") can be italicized; the problem seems to be where people mistakenly equate it with the url/hostname. Perhaps the documentation should be clearer about this. And perhaps a bot could flag all the instances where the value of {{para|website}} is a valid hostname. I am reluctant to deprecate {{para|website}} as I think it has a good use, but if the problem is too great then that is something to consider. ~ ] (]) 21:34, 6 September 2015 (UTC) | |||
| ::Editors were perplexed or confused with the term 'work'. In response to ], {{para|website}} became an alias of {{para|work}}. | |||
| ::—] (]) 22:12, 6 September 2015 (UTC) | |||
| :::Suggesting that it is the ''concept'' of "website" as a "work" that is confusing. ~ ] (]) 22:36, 6 September 2015 (UTC) | |||
| ::::So Amazon.com should not be italicized by www.amazon.com should, is what you're saying? First, I'm not sure how often we would be citing a raw URL. Second, I don't see URLs italicized in any mainstream source. I'm not sure it's a positive thing for WIkipedia credibility to be adopting highly non-standard forms of citation. I'm not sure this is any different from citing authors by first name rather than last. That would be a highly non-standard way of citing, and would only make Misplaced Pages look eccentric. I'm thinking that italicizing URLs where virtually no one else does might do the same. --] (]) 17:03, 7 September 2015 (UTC) | |||
| :::::No, I believe he's saying the reverse. Amazon.com is the name of a website, and as a major published work, it would be itaicized if included in a citation. On the oter hand, www.amazon.com is the hostname and wouldn't be itaicized nor would we need to cite it. <span style="background:#006B54; padding:2px;">'''] ]'''</span> 17:59, 7 September 2015 (UTC) | |||
| :::::::::Again, no one italicizes Amazon.com or Sears.com, RottenTomatoes.com, etc., including those companies themselves. A URL / hostname / website does not suddenly change and become a book, magazine, newspaper or other "major published work." There's a reason we say things are "posted to the Web" and not "published to the Web". I think the fact no one in the mainstream italicizes these things should be a significant factor in this discussion. --] (]) 18:24, 8 September 2015 (UTC) | |||
| :::::::Exactly. Tenebrae, you started off with an incorrect understanding, so everything else that follows is invalid. If you start off the right way (and if you understand/accept that "website" ≠ hostname) I think you will find that we are largely in agreement. ~ ] (]) 20:40, 7 September 2015 (UTC) | |||
| ::::::::I would like to think so, but a fundamental issue is that I believe the "website" parameter should not be italicized. Virtually no mainstream source italicizes either website names or URLs, which I take it is what you mean by "hostname". Italicizing websites/URLs is non-standard and does Misplaced Pages no good. --] (]) 21:52, 7 September 2015 (UTC) | |||
| :::::::::You need to loosen your death-grasp on '{{tq|the "website" parameter should not be italicized}}'. Your implicit argument is that ''URLs'' (which includes ''hostnames'') are not italicized. Look, '''we all get that part''' - everyone agrees that ''URLs'' should not be italicized. And that includes ''parts'' of a URL, such as ''hostnames''. So it is a bit annoying that you keep asserting that. What ''you'' don't get is that this is '''irrelevant''', because "website" does '''not''' equal URL/hostname. In particular, what you don't get is that a ''website'' - that is, a site on the World Wide Web with "web page" (HTML) content - can have a '''proper''' name. E.g.: the ''name'' of the website located at the WWW address "www.nytimes.com" is ''The New York Times'' - which ''is'' properly italicized. I repeat: {{hilite|"website" '''≠''' hostname.}} ~ ] (]) 21:58, 8 September 2015 (UTC) | |||
| ::::::::::With all respect, we're talking specifically about a field in "cite web" called "website". If we're citing ''The New York Times'', we use "cite news or "cite newspaper" and enter the name of the paper in the field "work". | |||
| ::::::::::But I ''am'' confused, because it ''does'' sound as if we both agree that the name of a website is not italicized unless it's a newspaper, magazine, etc. ... in which case we wouldn't use "cite web." So ... am I wrong or do we agree that if we use "cite web" that the field "website" should not be italicized?--] (]) 22:29, 8 September 2015 (UTC) | |||
| :::::::::::Suppose one wanted to cite this . Becuase it isn't a newspaper, it isn't a journal, nor a book, nor anything but a web page, then I would cite it with {{tlx|cite web}} like this: | |||
| ::::::::::::<code><nowiki>{{cite web |url=http://www.cdc.gov/ncbddd/autism/data.html |title=Autism Spectrum Disorder (ASD) |website=] |date=12 August 2015}}</nowiki></code> | |||
| :::::::::::::{{cite web |url=http://www.cdc.gov/ncbddd/autism/data.html |title=Autism Spectrum Disorder (ASD) |website=] |date=12 August 2015}} | |||
| :::::::::::—] (]) 23:04, 8 September 2015 (UTC) | |||
| ::::::::::::Yet nowhere else is the Centers for Disease Control and Prevention italicized. Same with CNN or CBS News. They are not publications, and I'm not sure it makes sense for Misplaced Pages to transmogrify them and pretend that they are publications. CBS News is never italicized. CNN, Sears, BBC, Rotten Tomatoes — none of these are italicized. If virtually no one else in the mainstream is italicizing these entities, I'm not sure why Misplaced Pages would. It makes us look eccentric. Do you see my reasoning?--] (]) 23:54, 8 September 2015 (UTC) | |||
| :::::::::::::Agreed, yet the name of the website at http://www.michiganhighways.org , if it were being cited, is "Michigan Highways" per the site's mastheads. If it were being cited, it should appear in italics as the name of a major work (as opposed to individual webpages within the site which would be minor works in quotation marks). There is no entity named "Michigan Highways" to be called a publisher. In some of those cases being mentioned above, what is being claimed as the name of a website is the publisher. Not all websites have names, but when they do, they should be in italics. If a website lacks a separate name, without resorting to creating "Official website of X", then {{para|website}} should be left blank. It's the same in comparing the news sites of WLUC-TV (''Upper Michigan's Source'') with that of WBUP-TV (no name). <span style="background:#006B54; padding:2px;">'''] ]'''</span> 00:48, 9 September 2015 (UTC) | |||
| :::::::::::::cs1|2 take their styling cues from ], ], ], and, no doubt, stuff we've made up ourselves. There is this, which on pages 4 and 5, compares three style guides for citing online material: | |||
| ::::::::::::::{{cite web |url=https://owl.english.purdue.edu/media/pdf/20110928111055_949.pdf |title=The Purdue OWL: Citation Chart |website=Online Writing Lab |publisher=Purdue University |pages=4–5}} | |||
| :::::::::::::If one is to believe that, website names are rendered in italics in citations so my CDC citation above is correctly rendered. | |||
| :::::::::::: | |||
| :::::::::::::—] (]) 00:51, 9 September 2015 (UTC) | |||
| {{od}}Misplaced Pages is highly non-standard. Contributors are not vetted. Sources are not systematically checked. Citation styles are not enforced. Editors have widely varying expertise. Consumers cannot be assumed to be experts. The present problem should I think take this non-standard approach into account. If the source is a website (a collection of pages connected by hyperTEXT links and employing the digital equivalent of a markup language) then should be treated the same way CS1 treats other similar collections in other media. --<small><span class="autosigned">— Preceding ] comment added by ] (] • ]) </span></small><!-- Template:Unsigned --> 19:43, 7 September 2015 | |||
| :{{u|Tenebrae}}, lets say I want to something from the website, something that only appears on the website, and is not in any book, pamphlet, etc. So I use cite web. And I use {{para|website}} = New York State DMV because that is the title of the web site. I know it is the title of the website because when I examine the html source for the home page of the web site I find <title>New York State DMV</title>. It should be italicised because that is the title of the work. ] (]) 23:06, 8 September 2015 (UTC) | |||
| ::Except no one other than we italicize it. New York State DMV is a proper-noun entity, but to suggest that all proper-noun entities be italicized — I dunno. I mean, what's the advantage of italicizing CBS News, Sears, New York State DMV, Yellowstone Park or United Airlines? Would readers ''not'' understand that " 'Traffic Laws in 2015'. New York State DMV." comes from the New York State DMV? I'm not sure what the advantage is of going with a deliberately eccentric format.--] (]) 23:58, 8 September 2015 (UTC) | |||
| :::At the NYS DMV website, the <title>New York State DMV</title> html officially declares to the world "the title of our website is ''New York State DMV''. My Firefox browser responds to that declaration by putting that title in the tab associated with the web page. Style guides outside Misplaced Pages, mentioned in this discussion, explain that when a website has a title, that title is italicised, and we have decided to follow that guidance. It has nothing to do with whether "New York State DMV" is a proper noun phrase or not. ] (]) 14:15, 9 September 2015 (UTC) | |||
| ::::And my Google Chrome does not italicize anything at http://dmv.ny.gov/. Nor does the title of the page itself, in big blue letters. As for "we have decided," that's what this discussion is for, to discuss a change. Because having a style that virtually no one else uses just seems remarkably eccentric for no purpose. I don't believe any of us has ever seen, anywhere, "Author's Page". ''Simon & Schuster''. No one would ever italicize the publisher Simon & Schuster. And to suggest that Rotten Tomatoes, which is not italicized in article text, be italicized in the footnote seems determinedly inconsistent. I think we're going to need wider input from all of Misplaced Pages.--] (]) 16:35, 9 September 2015 (UTC) | |||
| :::::T: We are ''not'' saying that "{{tq|that all proper-noun entities be italicized}}". In the context of citation ''publications'' ("works") are italicized, ''publishers'' are not. This is ''not'' "eccentric", this is a standard convention. So we italicize the ''titles'' of webpages (as Jc3s5h just explained), such as ''Sears'' or ''New York State DMV''. We do not italicize Simon & Schuster, Sears (the company), nor the New York State Department of Motor Vehicles. What kind of font is used on the website has nothing to do with it. (E.g., that the New York Times uses a serif title font has ''absolutely no bearing whatsoever'' on how a citation is formatted.) | |||
| :::::Your persistent failure to understand this is starting to sound like a ]ing problem. ~ ] (]) 01:13, 10 September 2015 (UTC) | |||
| ::::::No, it is the other way around, and I'll thank you stop casting aspersions. Pick up some books with footnotes and see whether web pages are italicized. See what ''AP Stylebook'', the largest style guide in the English-speaking world, has to say. ''Nobody'' properly writes Rotten Tomatoes in regular font in article prose and then, inconsistently, puts it in italics in footnotes. Virtually no one in the world would italicize an organization like CBS News when citing something from the CBS News website. Organizations and institutions don't suddenly become titles because they have a web page. | |||
| ::::::Try and ] this: The information we get from the New York State Department of Motor Vehicles comes, ultimately, under the auspices of the New York State Department of Motor Vehicles and ''not'' from the Web editor who inserted the information onto the web. Just as we cite ''The New York Times'' and ''Entertainment Weekly'' and not NYTimes.com or EW.com, the information from those websites ultimately comes under the auspices of those organizations. And in the case of non-publications, those organizations' names are not italicized. Now stop making false accusations — I understand perfectly, as I've said. It's you who seem to have trouble grasping the concept. --] (]) 20:26, 10 September 2015 (UTC) | |||
| :::::::False accustations? Aspersions? Perhaps you should review the bit at ] that accusing someone of a personal attack can also be considered a personal attack. | |||
| :::::::My "accusation" is that you have ''repeatedly failed to understand what is being said here''. E.g., you have just insisted that "{{tq|no one in the world would italicize an organization like CBS News}}", and "{{tq|those organizations' names are not italicized.}}" '''But who has said we should?''' You have implied that I did (and {{diff2|680307921|again}} at the RfC (]). But that is false. I have no where said that names of ''organizations'' should be italicized. And you seem to have totally missed what I said in my last comment regarding organizations: '''We do not italicize Simon & Schuster, Sears (the company), nor the New York State Department of Motor Vehicles.''' (Emphasis added for the hard of hearing.) You have mis-taken my position, and are arguing against something (italicization of organizational names) that nobody is arguing for. If you in fact do "{{tq|understand perfectly}}" then why are you arguing a non-issue? I surmise that you have confused "website" with "publisher", just as you earlier confused it with "hostname". I submit that not understanding this despite repeated explanations does sound like a ]ing problem. ~ ] (]) 22:38, 10 September 2015 (UTC) | |||
| ::::::::Don't you dare accuse me of uncivil behavior, when you were the first to say that anyone who took a different position from yours must, of course, have "faulty" reasoning. And you compound your incivility by falsely claiming I was ]. How dare you. Look around this RfC — other people have no problem whatsoever understanding my point, so the fact that only ''you'' seem to have a problem understanding seems ironic, given your accusations. You say organizations should not be italicized, but you support leaving the "website" field italicized (01:19, 10 September 2015) because the very same words are not, in your view, that of organization anymore but of a page title. That seem contradictory. I've already explained that when we're using publications, we wouldn't be using "cite web" field but "cite news" etc., so why you keep bringing up publications is beyond me. --] (]) 23:23, 10 September 2015 (UTC) | |||
| :::::::::Yes, I think I will dare to accuse you of uncivil behavior: of grotesquely misrepresenting my views, of attributing to me things I have clearly not said. Let's start with your statement that I was "{{tq|the first to say that anyone who took a different position from yours must, of course, have "faulty" reasoning.}}" Where? Give us a diff. That view is entirely your interpretation. As I said at the RfC, you it have backwards: I disagree with your position because your reasoning is faulty, not the other way around. As to your "{{tq|deliberately misunderstanding in order to obfuscate}}: I asked why (if, as you stated, you "{{tq|understand perfectly}}") you are arguing a non-issue. Again, the suggestion "in order to obfuscate" is entirely yours, not mine. But now that you have raised it, is that your answer to my question? | |||
| :::::::::I think it is quite evident that your understanding of matters here (and reasoning) is faulty, but as all efforts (of others as well as mine) to explain this to you are unavailing it seems pointless to continue. If you can provide that diff, fine, but otherwise you should cease your flailing about. If anyone else thinks that ''I'' have misunderstood something, please bring it to my attention. ~ ] (]) 23:48, 11 September 2015 (UTC) | |||
| == deprecate enumerator-in-the-middle parameters == | |||
| See ]. | |||
| I propose to deprecate these parameters and standardize on the enumerator-at-the-end form. The numbers in the preference ratio column are caclulated from the values in the tables in the archived discussion: (terminal enumerator ÷ medial enumerator). Where the cells are blank the denominator is zero. | |||
| {|class="wikitable" | |||
| |+CS1 parameters to be deprecated | |||
| ! parameter!!extant replacement!!preference ratio | |||
| |- | |||
| |{{para|author''n''-last}} || {{para|author-last''n''}}||2.51 | |||
| |- | |||
| |{{para|author''n''-first}} || {{para|author-first''n''}}||2.36 | |||
| |- | |||
| |{{para|author''n''-link}} || {{para|author-link''n''}}{{dagger}}||1.91 | |||
| |- | |||
| |{{para|author''n''link}} || {{para|authorlink''n''}}||1066.9 | |||
| |- | |||
| |{{para|author''n''-mask}} || {{para|author-mask''n''}}{{dagger}}||101.43 | |||
| |- | |||
| |{{para|author''n''mask}} || {{para|authormask''n''}}||23.23 | |||
| |- | |||
| |{{para|editor''n''-link}} || {{para|editor-link''n''}}{{dagger}}||1.54 | |||
| |- | |||
| |{{para|editor''n''link}} || {{para|editorlink''n''}}||7.24 | |||
| |- | |||
| |{{para|editor''n''-mask}} || {{para|editor-mask''n''}}{{dagger}}||3.17 | |||
| |- | |||
| |{{para|editor''n''mask}} || {{para|editormask''n''}}||16 | |||
| |- | |||
| |{{para|editor''n''-first}} || {{para|editor-first''n''}}||1.42 | |||
| |- | |||
| |{{para|editor''n''-given}} || {{para|editor-given''n''}}|| | |||
| |- | |||
| |{{para|editor''n''-last}} || {{para|editor-last''n''}}||1.58 | |||
| |- | |||
| |{{para|editor''n''-surname}} || {{para|editor-surname''n''}}|| | |||
| |- | |||
| |{{para|subject''n''-link}} || {{para|subject-link''n''}}{{dagger}}||47 | |||
| |- | |||
| |{{para|subject''n''link}} || {{para|subjectlink''n''}}|| | |||
| |}{{dagger}} these parameters are the canonical form | |||
| —] (]) 13:26, 4 August 2015 (UTC) | |||
| :Makes more conceptual sense the other way around. <code>editor2-last</code> implies the last name of editor #2, but <code>editor-last2</code> implies the second surname of the editor. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 23:33, 5 August 2015 (UTC) | |||
| ::I agree with SMC on this point and think it would make more sense to keep the number in the middle than to have it out there hanging at the end. --] (]) 17:47, 6 August 2015 (UTC) | |||
| :::The implication arises from the sense of the digit binding more tightly than the hyphen. (I.e., to "last" rather than "editor-last".) On the otherhand, when indexing a list of authors/editors I have found it most useful to have the index digit next to the equals sign, which gives the index better visibility, and provides a handy anchor for a regex. It's also easier to scan a list of authors/editors when the index is not buried inside the string. Which all might explain the medial location is not as widespread as the terminal form. I prefer the latter. ~ ] (]) 20:16, 7 August 2015 (UTC) | |||
| ::::And yet others of us view the number as better in the middle. Comparing {{para|editor2-last}} and {{para|editor-last2}}, I parse the first as being the last name of the second editor and the second as the second last name of the (singular) editor. YMMV, and as far as I'm concerned, there's no harm in retaining both forms. <span style="background:#006B54; padding:2px;">'''] ]'''</span> 20:44, 7 August 2015 (UTC) | |||
| :::::I am sympathetic to both points of view though my personal preference is terminal enumerator. I have added a column to the table that shows that overall, editors who have used these enumerated parameters generally prefer to use the terminal enumerator forms. | |||
| :::::—] (]) 12:26, 8 August 2015 (UTC) | |||
| ::::::That's surely skewed by how they're documented, and likely also by some individuals, perhaps even with AWB scripts, manually changing them to your "preferred" version. I know I've occasionally seen diffs that include this change along with other "general cleanup". <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 04:06, 9 August 2015 (UTC) | |||
| :::::::Of course it's possible that the documentation has influenced one style choice over the other and its possible that editors change extant parameters to suit their own preferences. I don't know that AWB, as part of its general fixes, makes this kind of change; I haven't noticed changes of that kind. If you are suggesting that I have written an AWB script that changes enumerator-in-the-middle to enumerator-at-the-end, then you would be wrong. | |||
| :::::::—] (]) 12:35, 9 August 2015 (UTC) | |||
| *'''Strongly oppose deprecation'''. These are still listed as the primary parameter names for {{tl|citation}} and we should not diverge the CS1 and CS2 templates so far from each other as to deprecate one template's parameters in the other. Additionally, these are used by software for creating citation templates (I know, because I have written such software myself). What purpose is served by this change? What does it make better? It seems to me to be purely a foolish consistency. Finally, I note that once again Trappist is proposing major changes that relate to {{tl|citation}} without even bothering to mention the discussion on ]. Trappist, you have been told over and over again: don't do that. —] (]) 17:14, 8 August 2015 (UTC) | |||
| *:I don't understand why you think this affects {{tl|citation}}... when it doesn't. --] (]) 21:09, 8 August 2015 (UTC) | |||
| :::This change affects {{tlx|citation}} because {{tld|citation}}, despite being cs2, is rendered by ]. | |||
| :::—] (]) 21:52, 8 August 2015 (UTC) | |||
| ::::Yes, and also because it is desirable to continue the current state of affairs in which we can change CS1 to CS2 or vice versa just by changing the template name. Not that changing the citation style of an article is frequent nor usually a good idea. But finding articles that mix the two styles is common enough, and changing them to use only one is usually a (minor) improvement. Thanks to recent improvements it's also possible to do this using a parameter but changing the actual template name seems less likely to encourage more inconsistency later. —] (]) 06:27, 9 August 2015 (UTC) | |||
| :::::Standardizing on terminal enumerators will not prevent editors from changing {{tq|CS1 to CS2 or vice versa just by changing the template name.}} Standardizing on lowercase parameter names did not change that nor did standardizing on the hyphen as a separator in parameter names change that. | |||
| :::::—] (]) 12:35, 9 August 2015 (UTC) | |||
| ::{{cs2}} is distinguished from {{cs1}} by its element separator (comma vs period), by lowercase static text (retrieved..., archived from ..., written at ..., etc. vs Retrieved..., Archived from ..., Written at ..., etc.), by terminal punctuation (none vs period), and cs2 automatically sets {{para|ref|harv}}, cs1 doesn't. cs2 is not distinguished from cs1 by some subset of the commonly shared parameters. | |||
| ::The primary documentation for both cs1 and cs2 is {{tlx|csdoc}}. I grant that {{tld|csdoc}} has a cs1 bias, so does ] though I did a bit of work on that recently that removed some of the bias. | |||
| ::Of the sixteen parameters in the above table, these seven are found in ] outside of the {{tld|csdoc}} content: | |||
| :::{{para|author''n''link}} | |||
| :::{{para|author''n''-link}} | |||
| :::{{para|editor''n''-first}} | |||
| :::{{para|editor''n''-last}} | |||
| :::{{para|editor''n''-link}} | |||
| :::{{para|editor''n''-given}} | |||
| :::{{para|editor''n''-surname}} | |||
| ::Are we to believe then that the other nine are not or should not be supported by {{tlx|citation}}? | |||
| ::Yep, it is just for consistency whether you think it foolish or not. This choice is no different from the choice we made to standardize on parameter names that use hyphens instead of underscores or spaces; and standardize on lowercase instead of capitalized or camel-case. Choosing one flavor or the other is merely for consistency. | |||
| ::—] (]) 21:52, 8 August 2015 (UTC) | |||
| :::Yes, I think it is foolish to suddenly kill off the primary documented parameter choices of the sister CS2 style, that our templates have been handling perfectly well, for the sake of no reason at all but neatness. The costs of this proposal involve breaking software or forcing the developers of the software to make parallel changes, breaking the mental model of who knows how many editors (as an example, I am still months after you made this change unable to remember to use contribution-url= in place of url= for the url of book chapters, and this is causing actual citations to be formatted wrong), forcing edits to who knows how many live citations after the red error messages start showing up, etc. The benefit of the proposal is appeasing the OCD of one single software developer who wants all the ducks to be perfectly lined up in a precise row. It's a bad idea. —] (]) 02:52, 9 August 2015 (UTC) | |||
| ::::Agreed (other than the assumption of mental issues), and as I said earlier, the proposed "norms" don't make conceptual sense: {{para|author2-last}} implies the surname of the second author, while {{para|author-last2}} implies the second surname of the (singular) author. I.e., there are multiple, independent reasons not to deprecate this, and at least one to actually prefer the form Trappist wants to deprecate. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 04:00, 9 August 2015 (UTC) | |||
| ::::Deprecation does not {{tq|suddenly kill off}} anything. | |||
| ::::—] (]) 12:35, 9 August 2015 (UTC) | |||
| :::::Must be why I still have an ant problem. This bug spray says "Deprecates on Contact!" <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 17:41, 10 August 2015 (UTC) | |||
| ::::::<nowiki>:-} </nowiki> ~ ] (]) 23:38, 11 August 2015 (UTC) | |||
| {{od}}While all these are valid and could exist in the same article | |||
| :{{para|author''n''-last}} vs. {{para|last''n''}} | |||
| :{{para|editor''n''-first}} vs. {{para|first''n''}} | |||
| they are also inconsistent. Just as parameter case was decided to be lower-case, this could also be decided in similar fashion.] (]) 19:34, 9 September 2015 (UTC) | |||
| == ISBN error category == | |||
| So that it is consistent with the naming convention of other identifier error categories, and while it is mostly empty, I've changed the ISBN error category name from {{cl|Pages with ISBN errors}} to {{cl|CS1 errors: ISBN}} in ]. | |||
| After the next module update, I think that the old category Pages with ISBN errors can go away. | |||
| —] (]) 16:34, 22 August 2015 (UTC) | |||
| :Support. It helps distinguish it from {{cl|Articles with invalid ISBNs}} as well. – ] (]) 10:14, 23 August 2015 (UTC) | |||
| This will break some ISBN fixing tools such as WPCleaner. -- ] (]) 12:39, 19 September 2015 (UTC) | |||
| :If {{cl|Pages with ISBN errors}} is hard coded into the tool, I have no sympathy. ] suggests that ISBN categories are kept in a configuration file somewhere though that isn't at all clear from the documentation. If this latter is true, then I see no reason not to proceed. | |||
| :—] (]) 13:39, 19 September 2015 (UTC) | |||
| ::{{U|Magioladitis}}, can you provide some details? If we are breaking something by standardizing this category name, we are willing to help fix it or test the tool after the change. It looks like we may need to change the second category name at ]; will that fix the problem? – ] (]) 13:46, 19 September 2015 (UTC) | |||
| == |translator= == | |||
| For a very long time editors have been asking for {{para|translator}} in some form or other. For a very long time the answer has been {{para|others}}. While I have been hacking away at the {{para|coauthors}} problem in {{cl|Pages containing cite templates with deprecated parameters}} I have become somewhat sympathetic to that request. So, here it is, these new parameters: | |||
| :{{para|translator}} | |||
| :{{para|translator''n''}} | |||
| :{{para|translator-first}} | |||
| :{{para|translator-last}} | |||
| :{{para|translator-link}} | |||
| :{{para|translator-mask}} | |||
| :{{para|translator-first''n''}} | |||
| :{{para|translator-last''n''}} | |||
| And an example: | |||
| :<code><nowiki>{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford}}</nowiki></code> | |||
| ::{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford}} | |||
| Relatively little is new as the translator-name-list makes use of existing author- and editor-name-list code. Currently, there is no support for et al. and no support for Vancouver styling. | |||
| Right now, {{para|others}} is appended to {{para|translator}} and the two rendered in the same place as {{para|others}}. This may not be the correct placement. There have been suggestions that {{para|translator}} belongs with {{para|author}}. What say you? Also, keep? Discard? What about punctuation? Static text? | |||
| —] (]) 17:36, 25 August 2015 (UTC) | |||
| :This is a good addition to the module. It will be welcomed by many editors. Here's how it looks with {{para|others}}: | |||
| ::<code><nowiki>{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford|others=Illustrated by Jane Doe}}</nowiki></code> | |||
| :::{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=] |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford|others=Illustrated by Jane Doe}} | |||
| :That looks right to me. As for the fixed text "Translated by", I like it. Our guidance in the documentation for CS1 templates has contained only this recommended form , as far as I can tell. – ] (]) 18:17, 25 August 2015 (UTC) | |||
| :The ball on ] hasn't been resolved yet, so I would expect to see the number-in-the-middle variants also. --] (]) 21:40, 25 August 2015 (UTC) | |||
| ::I don't think consistency requires us to introduce number-in-the-middle variants of new parameters, just because some of our old and entrenched parameters already have them. I'd prefer to see only one version of the new parameters rather than trying to duplicate all the variants of the old parameters. —] (]) 17:29, 27 August 2015 (UTC) | |||
| {{od}} | |||
| *{{cite book/new |chapter=Works and Days |title=English Translations: From Ancient and Modern Poems |volume=2 |chapter-url=https://books.google.com/books?id=mHNHAQAAMAAJ&pg=PA745 |page=745 |last=] |editor-first=Edward |editor-last=Smith |translator-first=Thomas |translator-last=Cooke |translator-link=Thomas Cooke (author) |date=1810 |publisher=N. Blandford|others=Illustrated by Jane Doe}} | |||
| I wondered how the above would work in with an editor. Are the translator and the illustrator meant to be volume wide and not related to the chapter? | |||
| Translator is one option but another is "Reviewed by" which is used by the ODNB, another is "Illustrated by". So rather than having a specific type why not have other parameters with a "other string" it could default to ("translated by") but be set to another word such as "Reviewed" or "Illustrated" etc. or set to "none" if other is a mixture of more than one type (translated by some, and illustrated by others), and instead of {{para|translator-first''n''}} have {{para|other-first''n''}} etc. -- ] (]) 16:52, 27 August 2015 (UTC) | |||
| :Good, as long as these also work: | |||
| ::{{para|translator{{var|n}}-first}} | |||
| ::{{para|translator{{var|n}}-last}} | |||
| :Discussions above (e.g. ]) do not indicate a consensus in favor of this {{var|role}}-last{{var|n}} order, with multiple editors objecting to it as counter-intuitive. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 02:16, 29 August 2015 (UTC) | |||
| ::As also noted in the relevant discussion, retaining both | |||
| :::{{para|{{var|}}{{var|n}}-last}} | |||
| :::{{para|last{{var|n}}}} | |||
| ::and | |||
| :::{{para|{{var|}}{{var|n}}-first}} | |||
| :::{{para|first{{var|n}}}} | |||
| ::is inconsistent and could also be counterintuitive. Per your suggestion then, {{para|last{{var|n}}}}, {{para|first{{var|n}}}} should be deprecated? ] (]) 14:52, 12 September 2015 (UTC) | |||
| ==Request for Comments: Italics or Non-Italics in "website" field== | |||
| {{rfc|tech|rfcid=7AC6FBB}} | |||
| In the template "cite web", which is used when "cite news", "cite newspaper" or "cite journal" is not, should the "website" field italicize the name of websites, in the manner of books or periodicals? | |||
| *'''Oppose''' No mainstream source italicizes British Board of Film Classification, U.S. State Department, Sears, Rotten Tomatoes, New York State Department of Motor Vehicles or other entities. Indeed, none of these entities themselves italicize their names on their own websites. These aren't publications, and we have templates like "cite newspaper" that we use for publications. It seems eccentric to use a citation format virtually no one else uses, and it also seems inconsistent that a movie article, for example, would mention Rotten Tomatoes in text but call it ''Rotten Tomatoes'' in a footnote. --] (]) 16:50, 9 September 2015 (UTC) | |||
| ::"No mainstream source italicizes ". Wrong. The most commonly-used style guides MLA (, scroll down to the section "A page on a website") and the Chicago Manual of Style () both use italics for all websites. (generally used in sociology field) and only include the url, not the website name. , generally used in the field of psychology, doesn't include the name of a website unless it corresponds to a scholarly journal (otherwise, it uses "Retrieved from "). Vancouver style (, generally used in the bio-sciences) does not italicize the name of the website, but includes "internet" in brackets after the website name, for example: Misplaced Pages . Since the AP style guide is intended for new stories, it does not cover footnote/bibliographic citations, since new stories use in-text attribution. "AP doesn't use italics in news stories. That includes newspaper names and magazine references. No italics." (). So BOTH of the major style guides (MLA & Chicago) that are used for general writing italicize the name of a website, while one (Oxford) does not include the name of a website. Of the style guides that are widely used only in a limited field, only one style guide for citations (Vancouver) does not italicize the names of websites and two generally do not include the names of the website (ASA, APA). ] (]) 22:19, 11 September 2015 (UTC) | |||
| :::*The MLA is an inapplicable example. It says to include the additional information or otherwise modified information, like domain names " (brackets in original source) ''and'' to even do so if it's a publication name. It's well-established that Misplaced Pages cites ''The New York Times'' and not ''nytimes.com'', and even editors who who want to keep the "website" field italicized agree Misplaced Pages does not and should not cite "Sears.com" or italicize names with ".com" in the formal name, like Amazon.com. So MLA has no bearing on the disucssion here. --] (]) 22:35, 11 September 2015 (UTC) | |||
| :::*Additionally, it is not, in fact, wrong to say "No mainstream source italicizes ". I'm referring to the fact that Amazon.com, Sears, CBS News, etc. are not italicized terms in general prose use. Yes, you can find a style guide that italicizes website names in footnotes. And you can find style guides that do not, so that part's a wash. The fact is that unlike periodicals, entities such as Amazon.com, Sears, CBS News, etc. are not normally italicized in prose text, and there's no reason to have a non-periodical in regular font in prose and italicized i footnote. One can always find someone doing things eccentrically — I believe ''The New York Times'', maddeningly, says 1950's rather than 1950s when it means the entire decade. But just because ''The New York Times'' or Chicago Manual of Style does something eccentrically that we have to be eccentric as well. We can use common sense. --] (]) 22:42, 11 September 2015 (UTC) | |||
| ::::MLA does not say to use the domain name, except in limited circumstances where the publisher uses the domain name in the website name. The full quote, which you conveniently did not include, is: "Remember that some Print publications have Web publications with slightly different names. They '''may''', for example, include the additional information or otherwise modified information, like domain names ." It's not common, but some publishers include the domain name, " online", or do something similar with the name of their website. It is absolutely not eccentric to italicize all websites. It '''''is''''' eccentric to have a policy that is inconsistent and determines which sites to italicize based on users' opinions. For example, you give the example of CBS News, but it is a major news site that is little different than a newspaper or TV news program, which is considered a work by any sensible person, except that it is on the internet. Websites like the New York Times have content on their websites that are not published in print. Your comments drive home the reason why we need a simple, common-sense policy about italics...there should not be excessive dispute about which websites merit italics and which do not. Common sense is to italicize all websites, rather than have a policy that is open to differing opinions among users. ] (]) 03:24, 12 September 2015 (UTC) | |||
| ::Um, most of those examples are not {{para|work}} (i.e. {{para|website}}) values but {{para|publisher}}. Of the entire list only ''Rotten Tomatoes'' is a {{para|work}}, and, yes, various sources do, and various style guides would, recommend italicizing it (same goes for ''CBS News'' as a news source rather than as an intellectual property business entity. I'm not sure what relevance that {{em|external}} style guides are thought to have here, and that's all I'll say on that matter for now. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 12:22, 12 September 2015 (UTC) | |||
| *'''Comment:''' ] says, ''"Website titles may or may not be italicized depending on the type of site and what kind of content it features. Online magazines, newspapers, and news sites with original content should generally be italicized (''Salon.com'' or ''The Huffington Post''). Online encyclopedias and dictionaries should also be italicized (''Scholarpedia'' or ''Merriam-Webster Online''). Other types of websites should be decided on a case-by-case basis."'' I think if the website title is italicized in its Misplaced Pages article, it should be italicized in the citation template as well (and probably should use the {{tl|cite news}} template as well). We do have a challenge here when it comes to websites that are not identical to news sources. Rotten Tomatoes and Box Office Mojo are more like database sources, but they do have parts of the website where there are write-ups that are basically like news articles. (Rotten Tomatoes has a "Critics Consensus" news column, and Box Office Mojo summarizes box office forecasts and actual performances in such articles.) I suppose if websites like these are not primarily news-type outlets, we do not italicize them? ] (] | ]) <sup>(])</sup> 17:03, 9 September 2015 (UTC) | |||
| *'''Italicise value of website parameter'''. This is supported in ''Chicago Manual of Style'' 16th ed. p. 754 which I quote: | |||
| :<blockquote>16. Ellis, Rhian, J. Robert Lennon, and Ed Skoog. ''Ward Six'' (blog). <nowiki>http://wardsix.bog.spot.com/.</nowiki></blockquote> | |||
| :] (]) 17:12, 9 September 2015 (UTC) | |||
| :::And other style guides do not. Some do, some don't. Cherrypicking just one that supports your arguments isn't helpful. --] (]) 22:46, 11 September 2015 (UTC) | |||
| *'''Italicize''' and on a case-by-case, editors ''can'' omit the name of a website that matches its publishing entity and give just the {{para|publisher}} instead. So to reply to {{u|Tenebrae}}, {{para|publisher|British Board of Film Classification}} would be 100% appropriate and correct, and the rendered formatting for the publisher would not be in italics. <span style="background:#006B54; padding:2px;">'''] ]'''</span> 17:30, 9 September 2015 (UTC) | |||
| *'''Italicise''' per {{U|Jc3s5h}}, we should take our lead from mainstream style guides. According to Jc3s5h, ''Chicago Manual of Style'' italicises them. Likewise the 19th edition of '']'' (legal citation) requires them to be in small caps, which is also how it treats books and magazines (italics being largely reserved for case names). By contrast however, ] is to use standard type but title-style capitalization, so its not uniform. ~ '']''<sup>(]|])</sup><small>]</small> 17:31, 9 September 2015 (UTC) | |||
| *'''Leave default alone''' but add named parameters to give editors control of how this is displayed, e.g. {{para|title-format}}, {{para|publisher-format}}, {{para|website-format}}, etc. with values that correspond to "quoted," "italic," and "plain". ]/<small><small>(])/(])</small></small> 18:35, 9 September 2015 (UTC) | |||
| *'''Leave un-italicized''' - There have been many discussions at the MOS about whether or not to italicize website names. Our current guidelines are a sensible compromise. By leaving them un-italicized by default, we allow the editor to choose (and thus to properly conform to the MOS). I would probably support making them italic by default if either the MOS is changed or a new parameter is added to allow overriding the default italicization. ] (]) 22:41, 9 September 2015 (UTC) | |||
| * '''Yes, italicize''', as it is standard practices to italicize the names of ''publications''. Tenebrae's opposition is faulty because he has persistently misunderstood (see the extended discussion ]) the intended scope of the {{para|website}} parameter, first conflating it with ''hostnames'' (URLs), now with ''publishers''. ~ ] (]) 01:19, 10 September 2015 (UTC) | |||
| :::No. Just because you disagree with me does not make my position faulty. I am not misunderstanding anything. You are claiming that corporations and government agencies suddenly transmogrify by magic into publications. I've tried to be politic here, but if you're going to get personal and suggest that anyone who disagrees with you must have "faulty" reasoning is insulting and plain wrong. Virtually no mainstream source italicizes Sears, Home Depot, Simon & Schuster or the New York State Department of Motor Vehicles. We don't italicize Rotten Tomatoes in article prose, yet you want a field that italicizes it in footnotes. That's ridiculous. --] (]) 01:30, 10 September 2015 (UTC) | |||
| ::::Again you have it backwards. Your position is faulty because of ''your'' imprecise thinking, quite independently of what ever I think about it (or you). You certainly misstate my position: I have '''not''' "{{tq|claim that corporations and government agencies suddenly transmogrify by magic into publications}}", and I will thank you to stop such misrepresentation. If you are going to take disagreement as a form of insult perhaps you should refrain from requesting comments. ~ ] (]) 22:47, 10 September 2015 (UTC) | |||
| *'''Comment''' It depends on usage. Sometimes, a web site is semantically almost the same as a ''publication''. Other times it is semantically almost the same as a publisher (no italics). At other times, it is semantically more akin to a bookstore or library (again, no italics). We need a clean, somewhat consistent way for editors to cite the website by name and give it the proper italics or lack of italics depending on the semantics. Here's an example: If you cite a copy of a pre-1923-century National Geographic Magazine article hosted at Project Gutenberg, you probably don't want {{para|website|Project Gutenberg}} to show up in Italics. On the other hand, if you cite the same article hosted at http://ngm.nationalgeographic.com/, you probably may very well want {{para|website|National Geographic Magazine}} italicized. <small>Note - for those counting noses I already made my main comment above - see "Leave default alone."</small> ]/<small><small>(])/(])</small></small> 02:08, 10 September 2015 (UTC) | |||
| ::I understand the comment about the bookstore/library, but it's is important to note that your example is bad. The "via" parameter in Citation Style 1 templates is intended for this purpose. Your example should use ] with {{para|via|Project Gutenberg}}. ] (]) 22:19, 11 September 2015 (UTC) | |||
| *'''Oppose''' forcing italicization for reasons explained by Davidwr above. Granting users the right to understand context, and italicize properly on their own should be what we do. As noted, there are many cases where the name of the website itself should not be italicized. And many cases where it should. Having a single "one size fits all" solution is not good, as having a template that ''forces'' a certain style which may not be universal would do. Yes, we should italicize appropriately. But is it really that hard for users to type four apostrophes when needed? --]] 02:30, 10 September 2015 (UTC) | |||
| :*Thanks for the endorsement, but the "two apostrophes" solution may not be the best solution, in that computer programs that parse this template for ''meaning'' may be confused. See my suggestion above ("Leave default alone") for having a different parameter to govern the formatting. ]/<small><small>(])/(])</small></small> 02:57, 10 September 2015 (UTC) | |||
| :**Actually, I think both of you are on the right track. Normally, editors add the two apostrophes before and after a word or phrase to italicize it. So while that can work in reverse — ading two apostrophes before and after a word or phrase in an italicized field to un-italicize it — that's counterintuitive. So wouldn't it make sense to have the website field non-ital, and that way editor who want to italicize something there can do so the normal way. --] (]) 23:28, 10 September 2015 (UTC) | |||
| :**Add to address ]'s astute point, I think if we were citing ''National Geographic'' we would use "cite news" or "cite journal", so the question of having a publication in the "cite web" website field shouldn't really be an issue. --] (]) 23:31, 10 September 2015 (UTC) | |||
| ::The template's we're discussing are Citation Style 1 templates, so all usage of the templates should be the same style. If an article is using a different style (eg. MLA, Vancouver, APA), then these templates shouldn't be used. ] (]) 22:19, 11 September 2015 (UTC) | |||
| *'''Leave default/italicized'''. As has been stated in the discussion ], the title of the website is used, not the domain name or the URL. The website is generally not the publisher; e.g., ], ], ], ], Rotten Tomatoes, and Metacritic are not publishers (editors have added them to the publisher= field). Moreover, other style guides, such as the ''Chicago Manual of Style'', italicize the name of the online source. Some editors either confuse the name of the website as the publisher or just use the publisher parameter so the online source isn't italicized. ] says, "Do not use the '''publisher''' parameter for the name of a work (e.g. a book, encyclopedia, newspaper, magazine, journal, website). ... Omit where the publisher's name is substantially the same as the name of the work (for example, The New York Times Co. publishes The New York Times newspaper, so there is no reason to name the publisher)". ] says, "The medium of publication or presentation is not a factor"; whether or not the online source/website is also a print publication is irrelevant; it's the name of a work - which has produced the content cited - therefore it should be italicized. I'd say one should use the work= parameter to cite print publication and online sources/websites that are also print publications; use website= parameter for strictly online sources. ] (]) 02:20, 11 September 2015 (UTC) | |||
| ::Indeed, the "publisher" field is being used for, say, Rotten Tomatoes since the "website" field italicizes it, and Rotten Tomatoes simply isn't italicized. Same with Metacritic and Box Office Mojo, these all being commonly used in ] articles. | |||
| ::] says, as you note, "Do not use the publisher parameter for the name of a work (e.g. a book, encyclopedia, newspaper, magazine, journal, website)." Yet having that last word in this list of examples, "website", does not mean websites are automatically italicized, because ] states, "Website titles '''may or may not be italicized''' depending on the type of site and what kind of content it features." It goes on to gives examples of what should be italicized: "Online magazines, newspapers, and news sites with original content should generally be italicized (Salon.com or The Huffington Post). Online encyclopedias and dictionaries should also be italicized (Scholarpedia or Merriam-Webster Online)." And then it specifically notes, "Other types of websites should be decided on a case-by-case basis." | |||
| ::Case-by-case basis. So websites are ''not'' to be automatically italicized. It would seem to make sense, then, that the "website" field not automatically italicize, since things that need to be italicized can still be italicized in the regular manner if the field doesn't do it automatically. --] (]) 03:33, 11 September 2015 (UTC) | |||
| :::I'm repeating one of Tenebrae's comments above for emphasis: editors specifically use the "publisher" parameter for website titles because the "website" parameter italicizes by default, and every commonly used website title I've seen is not italicized by our own MOS guidelines. As I note below, the very examples Lapadite77 cites in his argument above to keep the italics are not italicized in their own articles. The number of website names established as "major works" that should be italicized is relatively small compared to those that are not. — ]<sup>]</sup> 19:54, 11 September 2015 (UTC) | |||
| *'''Oppose''' default italics, as is currently in place. See ], above. Most website names and/or urls are not italicized per current MOS convention, so this should not be the default. A general discussion about outside style guides is irrelevant because the current Misplaced Pages style guides establish that website names are not italicized like "publications" are, as in the given examples of ], ] and ]. If our articles about these websites establish and confirm this style, citations should not diverge from it. In the case of items like '']'', the publication should be cited as |work=] rather than |website=HuffingtonPost.com anyway, but even if the url is preferred to be shown, it should be HuffingtonPost.com and not ''HuffingtonPost.com''. — ]<sup>]</sup> 17:17, 11 September 2015 (UTC) | |||
| ::The "url" form is NOT preferred. Unless, of course, it has been adopted as the name of an organization, publication, or (horrors) website. ~ ] (]) 23:57, 11 September 2015 (UTC) | |||
| *'''Italics by default''' As I mentioned in the previous discussion above ("Italicization of websites in citations") and in the response to the first comment by Tenebrae, the two most widely-used style guides (MLA and the Chicago Manual of Style) both use italics for the names of all websites. A citation style should be as uniform as possible, not filled with vague criteria. How will we determine which websites merit italics and which do not? This can especially be a point of disagreement in a featured article/list nomination. The problem is that there is an increasing amount of websites that function much like a publication such as a book or magazine, without a print equivalent, and in such cases the website is essentially a work similar to a book or magazine. There is too much opinion involved in distinguishing a website that should be italicized and one that shouldn't. Adding a parameter to not italicize something would not fix this problem. Furthermore, I think the implications of a change haven't been appreciated by the other commenters. The citation style 1 templates are used millions of times on Misplaced Pages (there are almost 5 million articles on en-wp, most use CS1 templates, and the articles with no CS1 citation templates are balanced by articles with 20..50...100...200+ CS1 templates). Changing the default behavior of these templates to not italicize websites and forcing users to manually add italics would be a monumental task to implement and not very easy to do with a bot. Using italics for all website names is simply the easiest way to format citations, eliminates disputes over which websites should and should not be italicized, and matches the two most widely-used style guidelines. ] (]) 22:19, 11 September 2015 (UTC) | |||
| ::Here's the thing, if these are the (external) style guidelines Misplaced Pages should be following, why are the majority of website titles which are the subject of articles currently not italicized? And where is the discussion that initiated the idea that the website parameter be italicized? The fact that the template is in use by a trillion articles means nothing if the format was not set with an adequate discussion, or for that matter, if it is now being challenged. — ]<sup>]</sup> 00:40, 12 September 2015 (UTC) | |||
| :::In 2009, there was ] about italicizing everything in the work parameter, including websites. At the time, neither the nor pages addressed whether italics should be applied to websites or not. The titles page simply said (emphasis mine) "Italic type (text like this) is '''generally''' used for the following categories of titles:" followed by a list of things. ] (]) 03:24, 12 September 2015 (UTC) | |||
| *'''Support italics'''. When we cite, in {{para|website}} (which is {{tlx|Cite web}}'s {{para|work}} parameter), something like <code>FooBarBaz.com</code> we're citing it as the title of a publication, not referring to it as an entity, so it is properly italicized as the title of major work, like a journal, book, or feature film. When I say "Jane works at FooBarBaz.com", I'm referring to a business entity. When the site has a conventional title, without the <code>.com</code> or whatever, we use that: {{bxt|1={{tlx|Cite web|website{{=}}<nowiki>]</nowiki>|...}}}}, not {{!bxt|1={{tlx|Cite web|website{{=}}<nowiki>]</nowiki>|...}}}}. When the site has no such non-domain-name title, the domain name {{em|is}} the title, and this quite common for online publications, as in our FooBarBaz.com example. In running prose, write: "According to a ''FooBarBaz.com'' article ...", but "...as the new CEO of 's.com". When the website/work and publisher are the same or essentially the same, omit the publisher, exactly as we do for newspapers: {{bxt|1={{tlx|Cite web|news{{=}}<nowiki>]</nowiki>|...}}}}, not {{!bxt|1={{tlx|Cite web|news{{=}}<nowiki>]</nowiki>|publisher{{=}}<nowiki>]</nowiki>|...}}}}. This is quite common with online publications, where the business entity does not really exist separately from the website for our intents and purposes. This is usually apparent in the copyright notice; if the indicia for SnorkelWeasels.com says "Copyright 2015 SnorkelWeasels.com" or "Copyright 2015 Snorkel Weasels LLC", you can usually safely omit the publisher parameter.<p>This would necessarily invalidate much of the ''oppose'' reasoning above relating to stuff like "British Board of Film Classification, U.S. State Department, Sears ... New York State Department of Motor Vehicles or other entities"; those are all {{para|publisher}} (as "entities" indicates), and their corresponding {{para|website}} a.k.a. {{para|work}} parameters are, respectively: <code>BBFC.co.uk</code>, <code>State.gov</code>, <code>Sears.com</code>, and <code>DMV.NY.gov</code>. This is important, because most such entities have multiple publications, online and offline. "U.S. State Department" is {{em|absolutely not}} a work title. It's typical, not just common, for universities to have dozens of websites on a departmental level (<code>foo.bar.UofBaz.edu</code>) that are often separately written, maintained, and funded, with separate purposes and audiences, and with their own editorial processes. It's also common for major governmental departments/ministries to do likewise (e.g. USEmbassy.gov is also a US State Dept. website). And it's fairly common for business entities to have multiple consumer-facing websites (usually divisional and/or world-regional), plus a separate <code>Corporate.Quux.com</code> type of site for non-consumer information about the company. And so on. Even Sears has multiple websites (I know, because it gives me a headache to remember which one to log into with what password to pay my bill); we might cite any of them (even the Sears bill-paying one, e.g. for what their privacy policy states vs. what some journalist wrote about it in a security scandal article or whatever). For any news publisher with multiple publications and different editorial boards, such that the paper and online editions may differ radically in content, it is safest to cite the online edition by its domain name (without "www." unless DNS resolving fails without it) as the work (or the online one's separate title if there is one, e.g. ''Wired News'' vs. ''Wired'' the magazine, which are from the same publisher) rather than the name of the paper publication. I tend to do this to be safe anyway, and cite, e.g. ''Guardian.co.uk'' not ''The Guardian'', because I don't know their online vs. paper editorial process.</p><p>The easiest way to keep this straight in one's head is probably to stop using {{para|website}} and always use {{para|work}}, to remind oneself that the parameter is about {{em|a publication}}. And if ever in doubt, remind yourself that Apple Records is a publisher and ''The Magical Mystery Tour'' is a work. It never ceases to amaze me how frequently people confuse {{para|publisher}} with {{para|work}} and its aliases. There's no reason for it. We all understand the difference between Marvel Comics, the business entity, and ''Ultimate Fantastic Four'', the comic book series, don't we? Apply the same reasoning to websites. Oxford University Press is a publisher, not a book. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 12:22, 12 September 2015 (UTC)</p><p>{{small|1=Self-correction: ''Salon'' has gone back to using ''Salon'' instead of ''Salon.com'' as the title, and the business name has changed, to Salon Media Group, so it's essentially the same as ''Wired News'' as an example; I've changed the Salon example to a hypothetical one. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 15:46, 14 September 2015 (UTC)}}</p> | |||
| ::I, for one, appreciate anyone willing to do a detailed analysis, although a non-succinct wall of text such as this, as we've seen in countless previous discussions all over Misplaced Pages, can sometimes be used to overwhelm a discussion. I'm not saying that's the intent here, and in fact, I see things I agree with and things I disagree with in the text above, which suggests it's an attempt at a fair analysis (though the lack of paragraph breaks makes it all a little hard to follow). It also sounds as if while he says "Support Italics", he actually doesn't support them in the website field: "Oxford University Press is a publisher, not a book." Absolutely. So it sounds as if he would ''not'' italicize "Oxford University Press". | |||
| ::I absolutely agree with him, and I think we all do, that when dealing with something that's unquestionably a publication, like ''The New York Times'', "The easiest way to keep this straight in one's head is probably to stop using |website= and always use |work=, to remind oneself that the parameter is about a publication." | |||
| ::But as we're dealing with the field "website" here, we still need to reach consensus on that. I think the simplest way to address this is to note that ] states, "Website titles '''may or may not be italicized''' depending on the type of site and what kind of content it features." Since we have a a choice of whether to italicize or not, I'm not sure why we're ''forcing'' italics in the field rather than not italicizing and letting editor italicize when appropriate. --] (]) 20:26, 13 September 2015 (UTC) | |||
| :::Thank you, Mac. Tenebrae, you say you "{{tq|absolutely agree with him}}", even though you also say there are things you with which disagree. I think what you agree with is that the title of ''works'' are italicized. What you object to is the italicization of certain cases, such ''hostnames'' (from a URL) and names of ''organizations'' (including publishers). But that is ''not'' a matter of disagreement, because no one here accepts such italicization. Your more particular objection – to "{{tq|''forcing'' italics}}" on the content of {{para|website}} when the content is such as we all agree should not italicized – overlooks a very essential point: if the content is not the name of the ''work'' then it should not be in "website" in the first place. The problem there is not the italicization, but misuse of the parameter. | |||
| :::You have cited the MOS that "{{tq|Website titles may or may not be italicized ...}}". Please note that that section gives no examples of a website whose name ought not to be italicized. If you have any such examples it might be useful to mention them. ~ ] (]) 22:58, 13 September 2015 (UTC) | |||
| :::::What I ''said'' was that I absolutely agreed with him on the specific point that we italicize something that is "unquestionably a publication, like ''The New York Times''. You were deliberately misrepresenting my stance with your opening sentence above in a false attempt at making me appear contradictory. You additionally put words in my mouth. I can state my position; I don't need you to misstate it. | |||
| :::::And, again, you refuse to listen to examples I've made previously: Rotten Tomatoes and Metacritic, to name just two websites, are websites. They are not italicized. No one italicizes them in prose, not even RT and MC themselves, and they don't suddenly become ''The New York Times'' in a footnote. And I shouldn't have to give examples when the MOS itself says there are website titles that may not be italicized. | |||
| :::::And since the MOS says "{{tq|Website titles may or may not be italicized ...}}", I'm not sure why we're forcing titles in the "website" field to italicize.--] (]) 15:10, 15 September 2015 (UTC) | |||
| ::::::Jeez, will you ever learn to pay attention? My "opening sentence above" '''in no way misrepresents''' what you said. I quite understand that your "absolute agreement" is not universal (i.e., applies to a specific point); I have not said otherwise. The only problem here is where '''you assumed''' that I was asserting your agreement as applying universally, and then '''further assumed''' I that was acting in '''bad-faith'''. If you thought I had misstated something you could have asked for clarification, but no, you just start assuming bad motives. This is a clear violation of ]. And you're so wrapped up in this that it seems you have totally missed why your "forced italics" is a false issue. | |||
| ::::::As to why we italicize titles in {{para|website}}: because by definition they are titles of ''works'', which are italicized by standard citation convention. | |||
| ::::::I will address your other points below. ~ ] (]) 22:47, 15 September 2015 (UTC) | |||
| :::{{ec}}Tenebrae, thanks ever so much for coming to the conclusion that maybe my faith was good after all, because you happen to agree with some of what I said (or think you do). Some of us value precision over convenience. I'm getting a bit tired of being berated for being in the former camp. I don't see the point in grousing about a few paragraphs of text on a site that consists of about 99.5% paragraphs of text. How can paragraph breaks make text hard to follow? The very purpose of them is that they make text easier to follow; that's why they were introduced so many centuries ago.<p>Anyway, {{em|of course}} we would not italicize Oxford University Press. "Oxford University Press" does not go in the website field, it goes in the publisher field, just like Apple Records or Universal Studios, or Marvel Comics, etc. It appears to me that you skimmed what I wrote, concluded what you wanted to, and are now putting words in my mouth that are the exact opposite of what I said, e.g. 'It also sounds as if while he says "Support Italics", he actually doesn't support them in the website field', which is bassackwards. No separate consensus needs to be reached on {{para|website}}; it's the same thing as {{para|work}}, just as {{para|journal}} is in {{tlx|Cite journal}}. I just use {{para|work}} in all of them, and it works fine.</p><p>The poorly-worded guideline quote is trying awkwardly to get at the "according to a ''FooBarBaz.com'' article" vs. "according to FooBarBaz.com's privacy policy" distinction drawn earlier, and to separate sites that intrinsically are publications (like ''Slate'' or ''xkcd'') from those that are services/applications/shops (Gmail, Yandex, Amazon.com). That's about use in running prose; in a citation, if we use {{para|website}} a.k.a. {{para|work}}, we're citing something as a published work, whatever it's other possible uses.<p>Contrived example where the publisher shares essentially the same name as the publication, and it's name is ''Billiards.info'' (not ''Billiards''):</p> | |||
| {{collapse|title=Examples and stuff|1=<nowiki /> | |||
| :::*If you want to cite an article: {{tlx|Cite web|title{{=}}How to Win a Lot |first{{=}}Sam|last{{=}}Jones|website{{=}}Billiards.info|url{{=}}...}} | |||
| :::*If you want to cite their privacy policy, which is not really part of the publication but part of the entity's corporate e-paper: {{tlx|Cite web|title{{=}}Privacy Policy |author=Board of Directors |publisher{{=}}Billiards.info Inc. |url{{=}}...}} | |||
| :::Easy-peasy. If it were stuff where the publisher, the domain name, and the title of the publication are all distinct, it could be done this way, also easy: | |||
| :::*Article: {{tlx|Cite web|title{{=}}You Can't Outrun a Komodo Dragon |first{{=}}Chris|last{{=}}Chan|website{{=}}<nowiki>]</nowiki>|publisher{{=}}Condé Nast|url{{=}}...}} (note piped link to distinguish from paper edition) | |||
| :::*Something else: {{tlx|Cite web|title{{=}}Wired.com Terms of Use |author{{=}}Digital Properties Legal Department |publisher{{=}}Condé Nast |url{{=}}...}}, with no need to insert {{para|website|Wired.com}} at all (and using {{para|website|]}} might be questionable, since the policy is about use of the online service, Wired.com, not use of the publication as a publication, and might cover other things at that site, such as user forums, that are not part of the publication proper). | |||
| }} | }} | ||
| :::But all of this is really hair-splitting; I'm skeptical that enough editors could care that we need to get into this in any more detail. What's important is that citations be usable to find sources accurately, and secondarily that they be consistent enough to be usable in this way. We don't need micro-formatting exceptions that don't help in that regard. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 15:46, 14 September 2015 (UTC) | |||
| *'''Italics by default''' -- ] 11:54, 14 September 2015 (UTC) | |||
| **And I ask, for what reason? Because the MOS says "{{tq|Website titles may or may not be italicized ...}}". Since that's the case, why are we forcing titles in the "website" field to italicize? On its face, that goes against the MOS. --] (]) 15:13, 15 September 2015 (UTC) | |||
| ::*] does not say "Website titles may or may not be italicized". <small><span class="autosigned">— Preceding ] comment added by ] (] • ]) </span></small><!-- Template:Unsigned --> 16:01, 15 September 2015 | |||
| ::**The MOS we've been talkng about this entire thread absolutely does say, " "Website titles may or may not be italicized": ]. --] (]) 16:20, 15 September 2015 (UTC) | |||
| :::The MOS does say "may or may not be italicized." (Second paragraph from the bottom of the seciton.) However, what Tenebrae seems to have missed is that this is not permissive, at the whim of individual editors. It depends "{{tq|on the type of site and what kind of content it features.}} But while the MOS provides several examples that ''should'' be italicized, it does not provide any contra-examples. It says only: "{{tq|Other types of websites should be decided on a case-by-case basis.}}" In a previous comment (above) I suggested to Tenebrae that if he had any useful examples it might be useful to mention them. He said ({{diff2|681162849|15:10, 15 Sep}}) that he "{{tq|shouldn't have to give examples when the MOS itself says there are website titles that may not be italicized.}}" Which is partly true — and partly false. What is '''false''' is the assertion that "{{tq|the MOS itself says there are website titles that may not be italicized.}}" The MOS makes no such assertion that such titles exist, and certainly ''not'' that "{{tq|may not be italicized}}" (in the sense of ''not permitting''). It only allows the ''possibility'' of such cases. And so far we have not seen any clear instances of "website titles" ''as titles of works'' - which is how {{para|website}} is defined - which should not be italicized. Lacking any such instances the argument for non-italics seems distinctly hypothetical. ~ ] (]) 22:55, 15 September 2015 (UTC) | |||
| ::***I'm rather tired of ] not listening to the examples I've constantly given. For the fourth or fifth time: Rotten Tomatoes, Box Office Mojo and Metacritic are website names that are not italicized. | |||
| ::***This editor also apparently has never encountered the concept of "corollary": If MOS says, "Website titles may or may not be italicized", then the inherent ''corollary'' is that some website titles are not italicized. That's basic use of the English language. --] (]) 17:36, 17 September 2015 (UTC) | |||
| :::And I am rather tired of your constant misrepresentations, failure to understand, and AGF failure. But perhaps you are ready to listen this time? | |||
| :::As I have been trying to explain to you for some time: the problem with these hypothetical italicizations that you object to – that ''everyone agrees'' would be improper – is ''not'' with the ''handling'' of {{para|website}}, but with the '''improper use''' of {{para|website}}. This parameter is defined at ] as an alias for {{para|work}}, which contains the name of certain kinds of ''publications''. '''Note''': places, hosts, organizations, and publishers are NOT ''works''. The problems you object to arise solely from your vague, ill-defined, and over-inclusive concept of "website names". In regard of (and your other examples): is that a ''publication'' (work), such as regularly publishes articles? Or is it a ''place'', where a whole lot of diverse and constantly changing content can be found? If it is a ''place'' it '''does not belong in {{para|website}}''', and there is no issue with italicization. Your entire tendentious complaint here rests entirely on such incorrect usage. | |||
| :::BTW, your understanding of '']'' is faulty. The ''implication'' that there ''might'' exist a "website title" that 1) is properly used in {{para|website}} as the title of a ''work'', and 2) should not be italicized, in no way establishes whether such an instance actually ''does'' exist. The examples you have offered are worthless because of their ''work''/non-''work'' ambiguity. ~ ] (]) 22:20, 17 September 2015 (UTC) | |||
| Checking back in on this messy debate, and J. Johnson I'm trying to follow your logic. Are you saying that ] is a place/publisher and not a website? Then what is {{para|website}} used for? My original point in all this is that it makes no sense to me why {{para|work}} and {{para|website}} are interchangeable when in many (most?) instances they are not ''publications''. This is the issue Tenebrae and I seem to be stuck on: The ] article asserts that it is a website, but "Rotten Tomatoes" is not italicized. Either: | |||
| :1. This is improper application of the MOS, and similar website titles (Box Office Mojo, Metacritic, etc) should be italicized in their articles, or | |||
| :2. The {{para|website}} should not italicize by default, or | |||
| :3. (By your logic above) The Rotten Tomatoes article should call it an "online publisher" rather than a website. | |||
| I see the distinction you are making, that we should be putting sites like Rotten Tomatoes in {{para|publisher}}, but that is counterintuitive to most editors, and {{para|website}} is mostly used for urls and website titles.— ]<sup>]</sup> 22:40, 17 September 2015 (UTC) | |||
| ' | |||
| :No. What I am saying is that <b>''if''</b> the Rotten Tomatoes website is deemed to be a place/publisher/etc. – and I leave that determination to whoever wants to take it on – <b>''then''</b> it is {{hilite|not a ''work''}}, and therefore ''does not belong'' in {{para|website}}. The question is not whether whether RT is a website (that is, an Internet location containing "web" content), but whether that website is a kind of ''publication'' (i.e., a ''work''), or something else. (And incidentally: RT ''is'' a website, and the ''publisher'' is probably Flixter, Inc.) | |||
| :Whether the articles for all ] should be italicized in the same manner as done for newspapers is a MOS issue, and would depend on whether they are newspaper-like ''works''. If they are not italicized, then presumably they are not "works". In that case they should not be used in {{para|work}} – ''or its aliases''. | |||
| :It is a standard citation convention, and established here by default, that the titles of ''works'' are italicized. The whole problem here seems to come to some editors thinking {{para|website}} encompasses ''all'' websites, including those that are ''not'' "works". (It certainly should not be used for urls.) If this is too difficult for general understanding then perhaps this parameter should be removed. ~ ] (]) 00:18, 18 September 2015 (UTC) | |||
| ::'''On removing "website" altogether''': You bring up a good point. As an editor, I just assumed that the website= parameter was for the web site itself, but that it should only be used if adding the web site was helpful. I did not, do not, and probably will not assume that "website=" should only be used when the website is a "work," unless/until the documentation is updated to reflect this. '''If the consensus here is that {{para|website}} should only be used when the web site is a "work" and that it should not be used when it is a "place" or other "non-work descriptor" then all related documentation should be updated to make this point crystal-clear.''' Ditto if that's not the current consensus but the consensus evolves to that in the future. ]/<small><small>(])/(])</small></small> 04:19, 18 September 2015 (UTC) | |||
| :::I believe all related documentation should be updated to make it crystal clear that {{para|website}} is an alias of {{para|work}} and should be used for the ''title'' of the website. There are two situations where the website (or work) parameters should not be used. One is if the website does not have a title (the html title tag might have a value, but that value might actually be nonsense, or the name of a company, and there is no large text near the top of the page that serves as a title). The other situation is where {{para|title}} is also the title of the "home page" where the information is found. A large website with many subpages can be a work, whether it has been assigned a title or not, and whether it corresponds to a traditional paper or film work or not. If it hasn't been assigned a title, I would just set {{para|title}} and leave it at that. ] (]) 12:04, 18 September 2015 (UTC) | |||
| ::::It seems funny to me to try and force/enforce a counterintuitive usage of a parameter, especially when novice editors may not read the documentation in depth or at all, or may use the wizard tools. J. Johnson has made a valid argument (that I agree with) to consider certain websites to be "publishers" if they are not considered "works", but I think that distinction will be lost on the common editor, documentation or not. Of course, I am saying this from my belief that most of the websites I have seen cited as such (those without associated magazines or newspapers etc.) seem to fall into the "publisher" category.— ]<sup>]</sup> 15:29, 18 September 2015 (UTC) | |||
| :::::To do a little fine-tuning: not necessarily ''publisher'', as many of these sites are aggregators, more in the nature of a big wall where individuals hang their posters. The key point is ''not a "work"''. The term "website" gives no clue that it is meant to be used in such a carefully distinguished manner. (Cf. "website-as-a-work".) Given this basic weakness, a similar weakness in understanding the nature of a "work", existing mis-usage, and a general disdain for RTFD (especially when a term and its intended use seems "obvious"), I rather doubt that documentation will have much effect. | |||
| :::::At this point I am thinking that {{para|website}} could be deprecated, with better documentation of where to use {{para|work}}. (Those editors that understand it can use it, and the others won't be mislead.) But this is getting beyond the scope of this RfC. ~ ] (]) 22:12, 18 September 2015 (UTC) | |||
| ::::::I'm going to try to stay positive here and say that I agree with ] that this particular template field, "website", be deprecated. It does seems to have such an inherent ambiguity that it creates confusion and definitional issues. Since it has to be replaced with ''something'', would it be "work = | publisher = ", as we have for other templates? --] (]) 20:34, 20 September 2015 (UTC) | |||
| :::::::<s>Thank you.</s> I don't see that {{para|website}}, as an alias for {{para|work}}, requires any replacement. Where the content of a "website" (in the broader usage) can be taken as a "work" that parameter is still available. I think that ''not'' using {{para|work}} when it might be applicable is a lesser (and addressable) problem than the misuse of {{para|website}}. However, all this is getting into a follow-up discussion. For the purpose of this RfC I think there is consensus that the contents of the {{para|website}} parameter, in the scope of its proper and restricted usage, ''should'' be italicized. ~ ] (]) 20:55, 20 September 2015 (UTC) | |||
| ::::::::Oh, for goodness' sakes: No. Italicizing it goes directly against the MOS, which says that website names can be either italicized or not — and so forcing italics, rather than leaving the field open to italicize or not, is contrary to MOS. --] (]) 21:29, 20 September 2015 (UTC) | |||
| :::::::::Wrong. As previously explained ({{diff2|681223536|22:55, 15 Sep}}), and recapped below. ~ ] (]) 22:30, 21 September 2015 (UTC) | |||
| ::::::::::Jeeminy Christmas, no. The MOS absolutely says website names can be either italicized or not. And I even agree with you that it's not subject to individual editors whims. That why I say below that Rotten Tomatoes is not italicized '''as per ] consensus and even a citation template''' at WikiProject:Film. Forcing the field to italicize when the MOS itself says website names such as this example don't have to be italicized goes completely against the MOS. --] (]) 22:50, 21 September 2015 (UTC) | |||
| *'''Italicize''' as {{para|work}} does. I didn't even know {{para|website}} existed until stumbling upon it yesterday, and I still can honestly say I (and perhaps others) do not know when to use {{para|website}} over {{para|work}}. Assume that they are used interchangeably, and have the format be consistent between them. No prejudice if they are both not italicized, as long as they are consistent.—] (]) 22:44, 15 September 2015 (UTC) | |||
| * '''Summary''': I think <u>most (sigh)</u> everyone's understanding is now adequate for the following summary. As the contents of the {{para|work}} parameter are ''titles of "works"'', which by standard convention are properly italicized, the contents of {{para|website}}, being an alias of {{para|work}}, and intended for those cases where the ''contents'' of a website are deemed to be "works", are also properly italicized. The objections raised here about improper italicization arise from {{hilite|''improper use of the parameter'' for the names of ''non''-works}}, such as hostnames or names of publishers. This misuse appears to arise from non-recognition of the non-obvious restriction of "website" to a form of ''title of a work''. ~ ] (]) 20:59, 20 September 2015 (UTC) | |||
| *'''That Is a False Summary''': I take exception to a participant in the discussion, as opposed to a disinterested third party, giving any summary at all, let alone one that favors his personal opinion. Italicizing the "website" field goes directly against the MOS, which says that website names can be either italicized or not — and so forcing italics, rather than leaving the field open to italicize or not, is contrary to MOS. If a field is called "website", then editors naturally assume that any website name goes there. Rotten Tomatoes is a website. But Rotten Tomatoes, as per ] consensus and even a citation template there, is not italicized. This is just one example of why "website" should not force italics. --] (]) 21:29, 20 September 2015 (UTC) | |||
| *:The template at the top of all MOS pages begins (emphasis added): "This guideline is a part of the English Misplaced Pages's Manual of Style. '''Use common sense in applying it; it will have occasional exceptions.'''" The subject of this discussion can be considered a reasonable exception. ] (]) 17:14, 21 September 2015 (UTC) | |||
| *::A "regular" or "expected" exception is an oxymoron. --] (]) 19:10, 21 September 2015 (UTC) | |||
| *:::No. A well-defined exception is a normal part of any process or system description. – ] (]) 19:13, 21 September 2015 (UTC) | |||
| *::::I'm a little confused. By saying an exceptions can be made, are we saying we want to italicize things that should not be italicized? That doesn't really make sense. Rotten Tomatoes and Metacritic, for example, are websites that aren't italicized. So I'm not sure what ] is saying.--] (]) 21:32, 21 September 2015 (UTC) | |||
| === Comments re misrepresentation, "smokescreening", etc. === | |||
| <small> I have split off the following comments as they only rehash what has been said above (or in the previous discussion) without adding anything new (to date) on the question of the RfC ("Italics or Non-Italics ..."). ~ ] (]) 21:34, 7 October 2015 (UTC)</small> | |||
| ::I have qualified my prior comment with ''most'', as ''one'' editor keeps going around and around and around like a broken record. Tenebrae: your objections are getting tiresome, even tendentious. To your objection to certain names being italicized when they get stuffed into the 'website' parameter, my simple suggestion is this (are you paying attention?): {{hilite|''don't stuff those names into the 'website' parameter''}}. At a slightly higher level you object that "{{tq|f a field is called "website", then editors naturally assume that any website name goes there.}}" While that is an understandable assumption, it remains a '''fact''' that <b>'website=' is an alias of 'work='</b>, and thus restricted to the latter's use for ''titles of works'', and thus italicized. | |||
| ::Your assertion that all this "{{tq|goes directly against the MOS}}" is flat-out '''wrong''', because ({{diff2|681223536|''as previously explained''}}) you keep forgetting the bit about "{{tq|depending on the type of site and what kind of content it features.}}" Your Rotten Tomatoes example is rotten because you have '''not shown''' that it is the ''title of a work''. Failing that, it {{hilite|does not belong in 'website'}}, and thus is irrelevant. ~ ] (]) 22:49, 21 September 2015 (UTC) | |||
| :::No. And stop with the name-calling. The only thing tendentious is your suggesting that Rotten Tomatoes is not a website. That's just remarkable. As for " 'website=' is an alias of 'work=' ", that's what this entire RfC is ''about'': whether it's proper for website= to be an alias of work=. And since the MOS says website names aren't required to be italicized, it's improper for it to be an alias of work= and force italicization in the field. If anything, it should be an alias of publisher=, so that if someone wants something italicized in that field, they can always add two quote marks to the beginning and end of the term. What the heavy burden or big deal is to do that, I have no idea. --] (]) 22:57, 21 September 2015 (UTC) | |||
| ::::There you go again. Flat-out wrong. Not only have I '''not''' suggested (as you state) that "{{tq| Rotten Tomatoes is not a website}}", it seems you completely missed where I said that it ''is'' a website. <small>(Which statement is likely to confuse you even further, as you quite evidently do not understand the distinction between 1) name of ''an Internet location containing web content'', and 2) name of a ''work''.) </small> As to "{{tq|what this entire RfC is ''about''}}", I will quote your very own words when you opened this disucssion: "{{tq|... should the "website" field italicize the name of websites, in the manner of books or periodicals?}}". That {{para|website}} is an alias of {{para|work}} is a given. If you want to discuss whether this is proper open another discussion. ~ ] (]) 00:08, 22 September 2015 (UTC) | |||
| :::::Your double-talk is such that I'm beginning to think you're pranking me and seeing how far you can go before I realize you're pulling my leg.. You said: "Your Rotten Tomatoes example is rotten because you have '''not shown''' that it is the ''title of a work''." The field we are talking about is called '''"website"'''. Whether RT is a "work" or not is irrelevant. The field is not called "work" — it's called "website." So, yes, if you're saying it doesn't belong in the "website" field, you're saying it's not a website. That's obviously ridiculous. | |||
| :::::RE: "That {{para|website}} is an alias of {{para|work}} is a given." It is ''nothing'' of the sort. Nothing is a "given". This entire RfC is about whether or not the "website" field should be italicized, and your bringing in irrelevant, extraneous points to create a smokescreen because ] the field to be italicized is just remarkable. | |||
| :::::You refuse to address a point I keep bringing up: The MOS says website names can be either italicized or not. So ''forcing'' the "website" field to italicize goes completely against the MOS. --] (]) 02:43, 22 September 2015 (UTC) | |||
| :::::::Wrong again. See below. ~ ] (]) 20:54, 23 September 2015 (UTC) | |||
| ::::::::What are you, five? I've seen below. You continue to refuse to address the fact that the MOS says website names can be either italicized or not. So ''forcing'' the "website" field to italicize goes completely against the MOS. --] (]) 22:21, 23 September 2015 (UTC) | |||
| :::::::::What are you, blind? The MOS does '''not''' say "{{tq|website names can be either italicized or not'''.'''}}" (Note the closing full-stop.) It says: "{{tq|Website titles may or may not be italicized '''depending on the type of site and what kind of content it features.'''}}" (Emphasis added.) What part of the qualifying "depends on ..." do you not understand? Oh, sorry, I forgot: none of it. Never mind. ~ ] (]) 22:41, 23 September 2015 (UTC) | |||
| ::::::::::OK, I've tried my best to keep a civil tongue, but your baiting me with insults has just pushed me over the line. I've been a professional writer and editor for over 35 years, and the garbled, verbose, unclear nature of your writing as seen here would never be acceptable in any mainstream periodical. I'm tired of what I now believe is your deliberate dissembling and your ignoring my addressing of your points. I have twice now addressed "depending on the type of site and what kind of content it features" — on Sept. 11 and again today — so just stop your smoke-screening and your arguments that come down to ]. I will say it again since you appear slow: "Case-by-case basis" means editors reach consensus whether to italicize ''or not''. So forcing italics is '''wrong''' because it's simpler and more intuitive to italicize something that needs italics than to de-italicize something that doesn't. Your ridiculous argument only results in things being italicized that should not be. --] (]) 23:20, 23 September 2015 (UTC) | |||
| :::::::::::You consider characterizations like "{{tq|double-talk}}", "{{tq|ridiculous}}", "{{tq|what are you, five?}}", "{{tq|smoke-screen}}", and "{{tq|the garbled, verbose, unclear nature of your writing}}" (all from you) to be '''civil??''' Not the slightest bit provocative? Attributing your failure to understand to "{{tq|deliberate dissembling}}" on my part is not civil (and also violates ]), nor does it encourage any continuance of a civil discussion. Whether we continune ''this'' discussion is another matter. ~ ] (]) 22:01, 24 September 2015 (UTC) | |||
| ::::::This discussion seems to be getting a bit personal, which is not helpful. It's simply a fact that {{em|at present}}, {{para|website}} is an alias of {{para|work}}. Of course, this could be changed and they could be made two separate parameters with different behaviours. {{em|But}}, and it's a big "but", first thousands of uses would have to be checked to see which meaning was intended, since there's no guarantee that editors have used the parameters with different meanings. I can only say that since I know they are aliases, I've not been consistent in which I used. So to this extent, ] is right to say that the current aliasing is a given. If separate parameters were agreed, then one could indeed be italicized and one not, but this is a different issue. ] (]) 08:14, 22 September 2015 (UTC) | |||
| :::::::I appreciate your trying to cool the waters. I do have to say I've never heard of any RfC where someone contends we'd have to check "thousands of uses" before we make a change. This RfC is no different than any other, where a consensus is reached among the editors discussing it, and to throw in some clearly undoable obstacle in order to retain the status quo is a bit questionable. You also seem to be saying that "since the website field is italicized currently, then it's a given that it's italicized". That seems a circular argument at best: It's not ''inherently'' italicized, as if anointed by God. That's what we're here to decide. And I'm still getting no one to address a point I keep bringing up: If the MOS says website names can either be italicized or not, why should the field ''force'' website names to be italicized? The website Rotten Tomatoes, for example, is not italicized, per ] consensus. Why would we force it to be? --] (]) 13:04, 22 September 2015 (UTC) | |||
| ::::::::Tenebrae, I ''have'' addressed the point you keep bringing up, multiple times even. (As well as several other points you keep bringing up.) In your obsession with that bit at ] ''you keep quoting only part'' of it. So here is the whole of it, with '''the part you keep leaving off''' emphasized: "{{tq|Website titles may or may not be italicized '''depending on the <i>type of site</i> and what <i>kind of content</i> it features'''.}}" The "or may not be italicized" is '''not''' a general permission for individual discretion, it is ''contingent'' (depends) on a certain distinction of site and content. There is no "forcing" of italics as use of 'website=' is entirely voluntary. But as you are ] any of this further explanation seems futile. Calling my efforts "{{tq|double talk}}" only underscores your lack of understanding. | |||
| ::::::::The bottom line here is that a majority of respondents favor italicization. As to keeping "Rotten Tomatoes" (or any other name) ''non''-italic in a citation, there is a very simple solution for you: '''do not stuff it into {{para|website}}'''. That the ''established and documented use'' of this parameter does not conform to your notion of what the general term "website" should cover: that is not what you requested comments on. ~ ] (]) 21:01, 23 September 2015 (UTC) | |||
| ::::::::*Sigh*. Anyone who has spent enough time on Misplaced Pages knows very well that in RfC discussions we don't count "votes" but try to achieve consensus. One third of the respondents here oppose forcing italics in the "website" field. That's a a large enough opposition that we're far from ''consensus''. | |||
| ::::::::And you are I hope inadvertently and not purposefully inaccurate when you claim I haven't addressed "depending on the type of site and what kind of content it features". At 03:33, 11 September 2015, '''I used those very words''': "] states, 'Website titles '''may or may not be italicized''' depending on the type of site and what kind of content it features.' ... it specifically notes, 'Other types of websites should be decided on a case-by-case basis.'" And you can read my analysis of this in that Sept. 11 post, so don't you dare make up false claims and accusations, and dissemble like that. | |||
| ::::::::"Case-by-case basis" means that editors reach consensus whether to italicize ''or not''. You refuse to understand that simple point. | |||
| ::::::::Nor the point that it's simpler and more intuitive to italicize something that needs italics than to de-italicize something that doesn't. You refuse to address the fact MOS says website names can be either italicized or not and so ''forcing'' the "website" field to italicize goes against the MOS. Rather, you point to something else in the MOS ''that I addressed 12 full days ago'' and claim I didn't address it. Well, I address it once again here. --] (]) 22:36, 23 September 2015 (UTC) | |||
| ::::::::And it is completely disingenuous to claim that most editors will not put a website into the "website" field. Why you want to encourage editors to wrongly italicize (and this is just one example of many) Rotten Tomatoes is incomprehensible to me. --] (]) 22:37, 23 September 2015 (UTC) | |||
| :::::::::Your assertion that I "{{tq|want to encourage editors to wrongly italicize}}" is '''completely false''', and I will yet again request that you refrain from misrepresenting my positions. I say that what should not be italicized should ''not go into'' the 'website=' parameter. Your argument is that certain names ''should'' go into 'website=', and then you are unhappy because it got italicized. | |||
| :::::::::You should note that ''lack of consensus'' is '''not''' grounds for changing established usage. Where you don't want something italicized, don't use 'website='. No one is forcing you to use it, so all your jabbering about "{{tq|forcing}}" of italics is just a ]. The rest of your comments I reject categorically. ~ ] (]) 22:11, 24 September 2015 (UTC) | |||
| ::::::::::I'm not misrepresenting anything. The field's name is '''"website"'''. Non-italicized aggregators like Rotten Tomatoes and the Grand Comics Database are '''websites'''. If you're suggesting that the average editor doesn't know what "website" means and won't naturally put websites in the "website" field ... wow!! | |||
| ::::::::::And how can anyone say that putting something in the current "website" field won't force italics? You've said yourself the field "website=" is an alias of "work=", which automatically italicizes whatever's in the field. "Automatically italicizing" ''means the same thing'' as "forcing". Good gracious. | |||
| ::::::::::Maybe a consensus solution is this: We change the name of the field from "website" to the extant "work." Boom. No more confusion, no more chance of someone putting a website into "website=" that shouldn't be italicized. --] (]) 22:35, 28 September 2015 (UTC) | |||
| :::::::::::In your comment just above (22:37, 23 Sep) you imputed that I "{{tq|want to encourage editors to wrongly italicize}}". '''That is false''', and absolutely contrary to everything I have said here; it constitutes a '''misrepresentation of my views'''. You have done this several times before. That you do not listen, or perhaps lack the intellectual competency to understand, does not excuse your bad manners, and interferes with any progress in this discussion. And I have had enough. I demand an apology for this and other misrepresentations <small><span class="autosigned">— Preceding ] comment added by ] (] • ]) 02:47, 30 September 2015 (UTC)</span></small><!-- Template:Unsigned --> | |||
| {{od}} | |||
| Only someone who knows he has no valid argument is going to start insulting another person, since that's a form of misdirection, and you've been smokescreening for most of this discussion. You're clearly so angry that rather than read thoroughly and think straight, you evidently only skim what I've been writing here. I've repeated myself blue in the face, and you still act as if you don't understand. That's just remarkable behavior. And it's typical of someone such as this that that you won't consider or even acknowledge a compromise suggestion but instead insist on some scorched-ground approach. I'm appalled and sad. | |||
| Once again: The field's name is '''"website"'''. Non-italicized aggregators like Rotten Tomatoes and the Grand Comics Database are '''websites'''. The average editor who knows the definition of "website" will put websites in the "website" field. Are you following? Now, the "website" field forces italics. I know you understand that. Italicizing websites that should not be italicized goes against the MOS, which allows for italics or non-italics depending on the website. I don't know how to explain it any more simply. | |||
| The solutions are simple: 1) make the website field not italicize automatically, so that editors can add the double-quote italic code in order to italicize, or 2) change the name of the field to something other than "website". That way, '''websites''' like Rotten Tomatoes and Grand Comics Database can go in a non-italicized field. There ''is'' a middle ground unless you simply want to have things your way without reaching reasonable compromise like an adult. --] (]) 03:43, 30 September 2015 (UTC) | |||
| :That is a very impressive piece of "smokescreening" you have just done, dancing all around and accusing me of the very things you are doing without addressing the '''fact''' that you have misrepresented me. Would someone else please step in and explain this to him? | |||
| :For the record, I quite understand what you are saying. As before ({{diff2|682622085|22:11, 24 Sep}}): {{hilite|1=I say that what should not be italicized should ''not go into'' the 'website=' parameter. Your argument is that certain names ''should'' go into 'website=', and then you are unhappy because it got italicized.}} And as I have also previously said, no one is forcing you to use "website=", so you have no basis for complain when you '''voluntarily elect''' to '''mis-use''' it. The problem here is that ''you'' don't understand (hear) any of this (or the MOS), insisting on your own idiosyncratic interpretations. As long as that condition continues there is no basis for further discussion. ~ ] (]) 21:56, 30 September 2015 (UTC) | |||
| ::No, again it is you who appears to be purposefully misunderstanding. Once again — and no one else is saying they have trouble following this — the field's name is '''"website"'''. Non-italicized aggregators like Rotten Tomatoes and the Grand Comics Database are '''websites'''. The average editor who knows the definition of "website" will put websites in the "website" field. | |||
| ::I never said anyone "is forcing you to use 'website='", so that's simply a false, straw-man argument. You know very well that editors know the definition of "website", and would have no reason not to put websites into a field named "website". You continue to refuse to address this simple fact. You don't want to discuss it further, fine. The fact you refuse to address this elementary point speaks volumes. --] (]) 20:05, 6 October 2015 (UTC) | |||
| :::Except that I never said that ''you said'' anyone "is forcing you to use 'website='." That is what ''I'' said, except that you left off the bit about "'''no one''' is forcing you...", which constitutes a blatant misquotation of my statement in the immediately preceeding comment. Your denial of having said what no one attributes to you is the very strawman argument that you then attribute to me. As to your "{{tq|editors know the definition of "website"}}": that assertion has been questioned, and that issue addressed. Did you forget? ~ ] (]) 00:12, 7 October 2015 (UTC) | |||
| ::::Your comment of 21:56, 30 September 2015: "And as I have also previously said, no one is forcing you to use 'website='..." And as I replied, "I never said anyone 'is forcing you to use "website=" ' ". And ''that'' is your smokescreening. I'll explain again: Non-italicized aggregators like Rotten Tomatoes and the Grand Comics Database are '''websites'''. The average editor who knows the definition of "website" will put websites in the "website" field. No one is "forcing" them, but the definition of "website" directs them to do so. (And the only time I used the word "force" is saying that the "website=" field is coded to force italics, which it does.) | |||
| ::::It's blatantly obvious that "website" is a poor name for the field since it communicates something unintended — and I say this as an editor, journalist and author of over over 35 years. --] (]) 18:53, 7 October 2015 (UTC) | |||
| I have repeatedly objected to Tenebrae's misrepresentation of my views, which he has rejected as "smokescreening". Before I take this elsewhere would anyone else care to offer any comments? ~ ] (]) 21:37, 7 October 2015 (UTC) | |||
| :And I object to J. Johnson's refusal to respond to my repeated statement that if you call a field '''"website",''' editors will put the names of '''websites''' in it — whether a particular website should be italicized or not. The field's name is needlessly misleading. If we're going to have a field that forces italics, logic demands it be called something other than "website". --] (]) 19:54, 8 October 2015 (UTC) | |||
| == Add citationstyle= parameter to CS1 templates == | |||
| All the talk about having {{para|website}} in italics or not got me thinking: | |||
| What if the cs1 templates like {{tl|cite web}} etc. had a {{para|citationstyle}} parameter, with values of '''LSA''', '''Vancouver''', etc. | |||
| When these values are used, the CS1 templates would become "wrapper" templates to the existing Vancouver, LSA, etc. templates. | |||
| This would be a lot of work, but assuming the work got done, do you think the parameter would get a lot of use? ]/<small><small>(])/(])</small></small> 02:47, 11 September 2015 (UTC) | |||
| :We have a start to this in {{para|mode}} and {{para|name-list-format}}, but you're right, it would take some work. – ] (]) 02:58, 11 September 2015 (UTC) | |||
| :Your idea has been in the back of my mind since the introduction of {{para|mode}} or there abouts. At about the same time there was a kerfuffle regarding small caps and LSA if I recall correctly. I have thought that we can extend {{para|mode}} to support clearly defined styles. Step 1 after we decide that this is something that we should be doing is to set down just exactly what it is that defines a particular style and then and only then hack the code to make it a reality. | |||
| :—] (]) 03:04, 11 September 2015 (UTC) | |||
| ::I strongly favour this idea. It would render the maintenance of citations easier if there are fewer citation template types. Also, fixing inconsistent citation styles or changing them when there is consensus to do so would be much easier.] (], ]) 08:54, 12 September 2015 (UTC) | |||
| ::Ideally, in my view, {{para|mode}} would be used with the {{tlx|citation}} template, which would make life much simpler for users – no need to choose which of the <code>cite</code> templates to use. However, I suspect this is difficult or impossible in all cases because there isn't always enough information to pick the right formatting. The {{para|website}} discussion above exemplifies one issue: having it as an alias of {{para|work}} loses information. ] (]) 10:00, 12 September 2015 (UTC) | |||
| :I strongly oppose having multiple citation styles at all, much less supporting external ones (i.e. other than CS1 and CS2, and we should retire CS2). ''But if we're stuck with it'', something like this is the way to do it, and we should get rid of external-citation-style-specific templates for Vancouver, etc., and just have it all done by the Lua module on the fly. So consider this "'''support''' until we come to our senses and have a single citation style like, well, every other publication in the world". <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 12:31, 12 September 2015 (UTC) | |||
| :::If we are to retire one of CS1 or CS2, I would strongly prefer it to be CS1. All. Those. Periods. Make. It. Very. Difficult. To. Read. And. Really. What's. The. Point. Of. Them? —] (]) 20:28, 15 September 2015 (UTC) | |||
| ::Not sure how I feel about this being in {{tl|cite xxx}} / {{tl|citation}}, but I'd definitely support this feature if it could be shoved in {{tl|reflist}}. <span style="font-variant:small-caps; whitespace:nowrap;">] {] / ] / ] / ]}</span> 13:27, 12 September 2015 (UTC) | |||
| :::Reflist is only capable controlling styling of what's inside it, but that requires a strong classing dicsipline inside the templates (so same problem as above). It has absolutely no way of controling content of these templates. <code style="font-size:small;white-space:nowrap">-- ]]] {{]}}</code> 09:06, 13 September 2015 (UTC) | |||
| == <cite> has been fixed, so we can now use it for entire citation == | |||
| Yay! {{tag|cite}} has now been fixed to stop forcing italicization, so we can now use it instead of {{tag|span}} to wrap the entire citation. This, BTW, has been interesting in that WP as a "developer user" of HTML & CSS has actually gotten W3C to fix things. Their own advice with regard to this element was self-contradictory between documents, and I got them to normalize to the current HTML5 description of the element. Details at ] (anchor to update reporting in middle of larger thread about this issue over the last month or two). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 12:54, 12 September 2015 (UTC) | |||
| :Done in the sandbox; compare live: | |||
| ::{{code|{{cite book |title=Title}}}} | |||
| :to sandbox: | |||
| ::{{code|{{cite book/new |title=Title}}}} | |||
| :—] (]) 13:47, 12 September 2015 (UTC) | |||
| ::Two comments: | |||
| ::# {{ping|Pigsonthewing}}, I think this may be the incorrect way to handle the microformat. Have a look, if indeed that first span is intended as a microformat. | |||
| ::# The intent was for the {{tag|cite|o}} to wrap the entire citation, whereas the sandbox is only wrapping the title. --] (]) 19:30, 12 September 2015 (UTC) | |||
| ::::Re: #1: why do you think it's wrong? | |||
| ::::Re: #2: I made a minimal example because that is easier to read. Here is one that is more complex: | |||
| :::::{{code|{{cite web/new |url=http://www.cdc.gov/ncbddd/autism/data.html |title=Autism Spectrum Disorder (ASD) |website=] |date=12 August 2015}}}} | |||
| ::::—] (]) 19:41, 12 September 2015 (UTC) | |||
| :::::<p>The <code>class=citation book</code> looked like a microformat pair of classes to me, rather than what is their more likely use of just plain ol' CSS classes.<p>Didn't realize the COinS was dumped at the end of the citation. I haven't looked too closely at the HTML behind the template system before.... --] (]) 00:08, 13 September 2015 (UTC) | |||
| :::Looks OK to me. Strictly, ] isn't a microformat, and works differently to them. <span class="vcard"><span class="fn">]</span> (<span class="nickname">Pigsonthewing</span>); ]; ]</span> 22:12, 12 September 2015 (UTC) | |||
| ::I would check and make sure that Mediawiki:* and other parts of the CSS cascade aren't anywhere doing anything that relies on <code>span.citation</code> vs just <code>.citation</code>, and same for the <code>.book</code> class selector. I.e., ensure that moving the classes from {{tag|span|o}} to {{tag|cite|o}} doesn't break something we don't notice immediately. Then again, if it does, I'm sure someone will tell us. I've not looked at COinS much; if the <code>book</code>, etc., classes are part of COinS, they do seem to need to be in {{tag|span|o}}, so we might need both (presumably the {{tag|span|o}} inside the {{tag|cite|o}}, since the span by itself would have no semantic "reality" on its own); but if that's just one of WP's own classes, it can be in the {{tag|cite|o}}. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 22:43, 12 September 2015 (UTC) | |||
| :::The extent of <code>.citation</code> in Common.css is the following: <source lang="css">/* Highlight clicked reference in blue to help navigation */ | |||
| span.citation:target { | |||
| background-color: #DEF; | |||
| } | |||
| /* Styling for citations (CSS3). Breaks long urls, etc., rather than overflowing box */ | |||
| .citation { | |||
| word-wrap: break-word; | |||
| } | |||
| /* For linked citation numbers and document IDs, where | |||
| the number need not be shown on a screen or a handheld, | |||
| but should be included in the printed version */ | |||
| @media screen, handheld { | |||
| .citation .printonly { | |||
| display: none; | |||
| } | |||
| }</source> Indeed, {{ping|Edokter}} I'm not sure about that first item there. Does the {{tag|ref}} include a span when it drops its content into the bottom of the page, or is that meant to specifically target our various and sundry reference templates? --] (]) 00:13, 13 September 2015 (UTC) | |||
| ::::That's the thing that makes the <sup></sup> or whatever of the ref citation turn light blue when you are in the refs section and click on the ^ link to get back to where you were in the text. So, yeah, that would need to change to refer to the {{tag|cite|o}}, or to be a class by itself without the element being named (unless we really do need the span as well; I'm still not sure if that class has anything to do with COinS). Ultimately it probably does not matter if have a <code><nowiki><cite><span>{{cite journal|...}}</span></cite></nowiki></code> structure; costs nothing but a few bytes. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 03:21, 13 September 2015 (UTC) | |||
| :::::The Cite extension already provides the styles to turn the automatically generated referneces blue with the selector <code>ol.references li:target, sup.reference:target</code>. <small></small> The <code>span.citation:target</code> snippet is an old remnant of the old link targeting mechanism, before the extension took over. The current snippet is useless and can be safely removed, because 1) references generated by citation templates, by themselves (ususally appearing between {{tl|refbegin}}/{{tl|refend}}), have no id and therefor 2) are not (and cannot) be linked to. That makes <code>:target</code> pretty pointless. <code style="font-size:small;white-space:nowrap">-- ]]] {{]}}</code> 10:01, 13 September 2015 (UTC) | |||
| {{od}} | |||
| <code>class="citation"</code> is required so that a cs1|2 template in a bibliography gets the blue highlight when linked from a reference in a reference list.{{sfn|Blue|2008}} <s>I've hacked the sandbox code so that <code>class="citation"</code> is not part of the {{tag|class|o}} as an illustration.{{sfn|Not blue|2008}}</s> | |||
| {{reflist-talk}} | |||
| *<s>{{cite book |author=Blue |title=Title |date=2008 |ref=harv}}</s> | |||
| *<s>{{cite book/new |author=Not blue |title=Title |date=2008 |ref=harv}}</s> | |||
| —] (]) 11:05, 13 September 2015 (UTC) | |||
| :I see. In that case, The <code>span</code> should be removed or replaced by {{tag|cite|o}}. Though it will work without the element in the selector, I'd prefer to keep the specificity consistent to prevent accidental linking to other elements with the <code>.citation</code> class. But that should not be a problem until the conversion is complete. <code style="font-size:small;white-space:nowrap">-- ]]] {{]}}</code> 12:36, 13 September 2015 (UTC) | |||
| ::Sorry, I do not understand what you just wrote. In ], the cs1|2 template output (except for the COinS) was wrapped in {{tag|span}}. It is now wrapped in {{tag|cite}}. My example shows, I think, that {{tag|cite|params=class="citation"|o}} is required to get the blue highlight when the target cs1|2 template is outside of a {{tlx|reflist}} as commonly occurs when an article uses {{tlx|sfn}} and {{tlx|harv}} et al. | |||
| ::—] (]) 13:19, 13 September 2015 (UTC) | |||
| :::I was talking about the selector in Common.css. It should match whatever the module outputs. It now targets neither span or cite tags; just the .citation class, which is too broad. So I will make it target only <code>cite.citation</code> once the modules have been converted. If you still don't understand, don't worry about it. <code style="font-size:small;white-space:nowrap">-- ]]] {{]}}</code> 21:52, 13 September 2015 (UTC) | |||
| ::FWIW, I am seeing blue highlight for the <sup></sup> ref even for the "Not blue" sample above, when I click on it's "^" link-back. I'm supposing this is because the underlying sandbox code has changed in the interim, but thought I'd report it in case not, and the example is supposed to do something else, since it might be relevant for debugging, if so. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 16:21, 14 September 2015 (UTC) | |||
| :::The superscripts do have the blue highlight; that isn't the issue. The issue is with the long-form citations; these links: <s>] and ] (or their mates in the reference list)</s>. The 'Blue' citation was rendered with {{tag|cite|params=class="citation book"|o}} but the 'Not blue' citation was rendered with {{tag|cite|params=class="book"|o}}. | |||
| :::—] (]) 16:33, 14 September 2015 (UTC) | |||
| ::::Hack to ] in support of the examples I made here is undone. | |||
| ::::—] (]) 11:23, 19 September 2015 (UTC) | |||
| :{{Ping|SMcCandlish}} Congratulations on getting this fixed; it's good to see us as a movement contributing in that way. I've previously had WP:NOT cited at me when I've tried to get us to lead by example in similar areas. <span class="vcard"><span class="fn">]</span> (<span class="nickname">Pigsonthewing</span>); ]; ]</span> 22:12, 12 September 2015 (UTC) | |||
| ::{{small|1=Pfft! ] has no power whatsoever to tell me who I can and can't contact off-wiki to fix things like W3C contradicting their own standards. >;-) It's the kind of thing I'd do anyway; the WP issue just made me notice this particular case. This may actually have quite noteworthy longer-term effects; apparently the entire W3C Cheatsheet was not being synched with the actual, live W3C Recommendation (the real spec), but had only been synched by hand or something to some old version in 2009! And WHATWG does what the Cheatsheet says. And browser makers and many others do what WHATWG says, to some extent. As far as I know, WHATWG has not updated its own materials yet since this W3C fix, but they should soon enough. I suspect and hope that much of what we're seeing with browsers lagging so far behind what the W3C HTML5 Recommendation says to do may be directly and primarily due to this synchronization failure. It would certainly be hot if that's the case, and all of sudden they started consistently implementing stuff we've been waiting on since 2013. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 22:28, 12 September 2015 (UTC)}} | |||
| :::<small>2013 is awfully optimistic. --] (]) 00:06, 13 September 2015 (UTC)</small> | |||
| ::::{{small|1=Hee haw! Yeah, I mean just the new stuff; I wasn't talking about stuff we've been waiting to work properly since the '90s. LOL. There did seem to be a rush to implement (at least with prefixes) lots and lots of stuff from the old draft and early release versions of HTML5, and then it just kind of stopped. I think it's because the Cheatsheet wasn't updated, so WHATWG didn't update. Then the HTML5 spec was revamped in 2013, and kinda nothing happened. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 03:09, 13 September 2015 (UTC)}} | |||
| In my opinion the CS1 and CS2 templates should produce HTML that not only gives the desired appearance at this moment, but also uses the HTML tags correctly. This thread should have begun with a link to the current official definition of the <cite> element so we could evaluate whether the changes discussed in this thread obey the documentation. ] (]) 15:22, 13 September 2015 (UTC) | |||
| :] is only important when it's important. :-) That documentation was already provided and discussed in the previous edition of this thread just a couple of weeks ago, and is also provided prominently in the ] discussion linked to in the first post in this thread, where I indicated the matter had been discussed at length. ] it is again, with all the relevant off-site links. The purpose of pointers to such discussions is to avoid rehashing the same discussions. The entire point of these threads is, yes, to use the HTML correctly; the limitation of {{tag|cite|o}} to title only was a 2009–2013 experiment that the HTML-using community rejected. As in HTML 4, the HTML5 spec allows this to cover citation data generally (the only required part is that at least one of the following must be present to use {{tag|cite|o}}: author, title, URL). <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 13:53, 14 September 2015 (UTC) | |||
| Update: I've fixed the placement and styling of {{tag|cite}} in all the templates using it that are not <code>Template:Cite <var>something</var></code>, <code>Template:Cite/<var>something</var></code>, or <code>Template:Citation/<var>something</var></code>, which I've deferred here to ]. (This was mostly fixing it in single-source citations and in quotation templates). All that remains is for it to be integrated into the more complex citation templates. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 13:53, 14 September 2015 (UTC) | |||
| == Handling multiple italicized titles == | |||
| Notwithstanding the above RfC, which appears to be firmly in favor of retaining the italics by default, we might actually want a {{para|work-noitalic|yes}}, as something to be used on a case-by-case basis for a reason, and not just created so people can evade a style they don't like. A genuine use case for it would be books (discrete major works) that have been published inside other books (bound paper things) with separate titles. I'd like to be able to do: {{tlx|Cite book|chapter{{=}}Foreign Words and Phrases|work-noitalic{{=}}yes|work{{=}}<nowiki>''The Oxford Guide to Style'', in ''Oxford Style Manual''</nowiki>|...}}. | |||
| Another example would be: {{tlx|Cite book|chapter{{=}}Foreign Words and Phrases|work-noitalic{{=}}yes|work{{=}}<nowiki>''Blood of the Isles: Exploring the Genetic Roots of Our Tribal History'' </nowiki>|...}}. | |||
| Another approach to this, that might be less prone to "gimme my own style" abuse, would be to distinguishing the two use cases: | |||
| * {{tlx|Cite book|chapter{{=}}Foreign Words and Phrases|title{{=}}The Oxford Guide to Style|anthology{{=}}Oxford Style Manual|...}} | |||
| * {{tlx|Cite book|chapter{{=}}Foreign Words and Phrases|title{{=}}Blood of the Isles: Exploring the Genetic Roots of Our Tribal History |alt-title{{=}}Saxons, Vikings and Celts: The Genetic Roots of Britain and Ireland |alt-title-label{{=}}North American title|...}} | |||
| My approach to handling the former case has been {{tlx|Cite book|chapter{{=}}Foreign Words and Phrases|title{{=}}The Oxford Guide to Style|...}} (published as part of {{tlx|Cite book|title{{=}}Oxford Style Manual|...}}. For the latter I've been doing something similar, using two citation templates. It's an unnecessarily longwinded way to do it, and prone to breakage because it doesn't keep all the citation's details in one template "package". <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 16:12, 14 September 2015 (UTC) | |||
| :{{tlx|cite encyclopedia}} does something like this: | |||
| ::<code><nowiki>{{cite encyclopedia |chapter=Chapter |title=Title |encyclopedia=Anthology}}</nowiki></code> | |||
| :::{{cite encyclopedia |chapter=Chapter |title=Title |encyclopedia=Anthology}} | |||
| :and so does {{tlx|cite book}} (sort of): | |||
| ::<code><nowiki>{{cite book |chapter=Chapter |title=Title |encyclopedia=Anthology}}</nowiki></code> | |||
| :::{{cite book |chapter=Chapter |title=Title |encyclopedia=Anthology}} | |||
| :There are constraints imposed by the metadata. A book title in the metadata is two parts: article (chapter) title and book title. {{tld|cite encyclopedia}} emits the value from {{para|chapter}} and {{para|encyclopedia}}. {{tld|cite book}} on the other hand, emits the values from {{para|chapter}} and {{para|title}}. Presumably, the {{tld|cite encyclopedia}} model is the preferred model for an anthology because, one presumes, that parameters like ISBN, publisher, etc. apply to the anthology and not to the component book. There is no way that I know of to feed a three-part title to the metadata. | |||
| :It would seem not to difficult a task to create {{tld|cite anthology}} and {{para|anthology}} so that we don't 'misuse' {{tld|cite encyclopedia}}. | |||
| :—] (]) 17:15, 14 September 2015 (UTC) | |||
| ::The example of different titles depending on place of publication seems to go against the principle of editors citing the copy that they examined. In most cases one editor would add the cite, and would have had access to only one copy. If an American and UK edition were used, probably they were used by two different editors, and the two editors would not necessarily know if the pagination in the two versions was the same. ] (]) 17:55, 14 September 2015 (UTC) | |||
| :::Right. Titles are the primary identifier of books (and other items), and if a publisher changes the title there is no telling what else may have been changed. If two titles are actually identical than one might be considered a reprint of the other, but how would an editor know that? Best that distinct titles have distinct citations. If a book or article has been republished under a different title that can be mentioned following the citation. ~ ] (]) 22:40, 14 September 2015 (UTC) | |||
| ::::This isn't quite what I'm getting at. These are works that I have on hand, and they have three relevant titles: "Chapter/Article", ''Logical Book'', ''Physical Book'', in the one case, and "Chapter/Article", ''Regional Book Title I'' , in the other. In the first case, I'm citing the specifics of a single work that has a hierarchy of three, not two, titles. In the other, I'm providing information to help readers locate the same source under two names (it has a typical hierarchy of two titles, but the major title has two variants). They're different cases. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 01:23, 15 September 2015 (UTC) | |||
| :::::Oh. What you are talking about is not ''alternative'' titles, but titles at hierarchial ''levels'' of organization (e.g., work/chapter/section) - right? I got into that with the IPCC citations, but I am disinclined to re-visit it. ~ ] (]) 23:04, 15 September 2015 (UTC) | |||
| == Cite book needs <samp>work</samp> alias for <samp>title</samp> == | |||
| The above reminds me: {{tlx|Cite book}} needs to support {{para|work}} as an alias of what it calls {{para|title}}; as far as I recall, it's the only template in the series that doesn't support {{para|work}}, and this is a hassle for multiple reasons (having to remember which template demands what, not being able to convert easily between {{tlx|cite web}} and {{tnull|cite book}} for e-books, etc.). | |||
| Strictly speaking, it might make the most sense to re-code the {{tlx|Cite book}}'s {{para|title}} as an alias of existing {{para|work}} code (the input that gets italicized as a major work) in Cite/core, and use the same code to generate all {{para|work}} titles across all the templates. What is presently handled as {{para|title}} in almost all the templates (i.e., the input that gets quotation marks as a minor work) could be turned into an object called {{para|item}} or something, with {{para|title}} usually being an alias to it, and {{tlx|Cite book}}'s {{para|chapter}} being one, but using the same function to generate it regardless what template calls it. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 16:12, 14 September 2015 (UTC) | |||
| :For the purposes of cs1|2, {{tlx|citation/core}} is dead. | |||
| :{{tlx|cite book}} only supports {{para|work}} visually (discussed ]) for which reason I have suggested ] in these pages that {{para|work}} and its aliases should be ignored by {{tld|cite book}} as they were in the old days of {{tld|citation/core}}. | |||
| :—] (]) 17:54, 14 September 2015 (UTC) | |||
| ::That you have a preference in this regard doesn't address why lack of support for {{para|work}} is problematic. I'm not suggesting that {{tlx|Cite book}} handle {{para|title}} and {{para|work}} as separate entities, but rather alias one to the other, the same way {{para|accessdate}} can also be called {{para|access-date}}. I'm not sure what "only supports {{para|work}} visually" even means, but have to run for now; will re-read that stuff and see if I can suss your meaning, if you don't clarify in the interim. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 01:27, 15 September 2015 (UTC) | |||
| :::{{tq|{{tlx|cite book}} only supports {{para|work}} visually...}} means that you can have {{para|work}} in {{tld|cite book}} with {{para|title}} and you will see it in the rendered citation. But, a value in {{para|work}} without {{para|chapter}} causes an error in the metadata – the citation is treated as a journal article (a bug I think that bears some thinking on). When {{para|chapter}} is included with {{para|title}} and {{para|work}} in {{tld|cite book}}, {{para|work}} is rendered but not made part of the metadata while the other two parameters are (correctly this time). | |||
| :::—] (]) 03:03, 15 September 2015 (UTC) | |||
| ::::That sounds like it would be fixed by having {{para|work}} and {{para|title}} be the same thing (one an alias for the other). Why would we want {{tlx|Cite book|title{{=}}...|work{{=}}...}}? That would {{em|generally}} make the same not-sense as {{tlx|Cite journal|journal{{=}}...|work{{=}}...}}. That said, having a {{em|special case}} where the use of both would case {{para|work}} to render but be omitted from the metadata would actually resolve my above need for being able to cite ''The Oxford Guide to Style'' (a logical {{para|work}}, and previously published as a separate volume, and in both editions having its own chapters and authors and such), and the ''Oxford Style Guide'' (a published {{para|title}} of the book in the "bound thing of paper in my hands" sense). In pseudocode: | |||
| :::::<code> | |||
| :::::if $title | |||
| :::::::if $work | |||
| ::::::::: | |||
| ::::::::: print italicized $work ; print ', in '; print italicized $title ; | |||
| :::::::else print italicized $title | |||
| :::::else if $work | |||
| :::::::print $work | |||
| :::::else throw missing-title error | |||
| ::::</code> | |||
| ::::Seems pretty simple, though I forget what is using template code and what is using Lua in these things. This could even be used for bound journals, with the bound physical book being cited as the {{para|work}} and the journal issue being cited as {{para|journal}}. I ran into this problem before trying to cite my bound volumes of ], ], etc., in some ] articles, and again ended up doing the two-citations-back-to-back thing: {{tlx|Cite journal}} followed by a {{tlx|Cite book}} for the bound volume that was largely a redundant citation, but necessary to both ] and preserve the details of the bound and original publications. This can be important because, e.g. ''The International Studio'' was bound by more than one operation, and differently; I have some bound volumes of it that {{em|overlap}}, with some being bound by calendar year, the others being bound by the journal's own volume/issue numbering order. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 23:49, 16 September 2015 (UTC) | |||
| The main use case I can see for having both {{para|title}} and {{para|work}} in a {{tl|cite book}} would be for a long multivolume work where you want to separately represent the titles of the whole work and of the volume. But that's better handled with {{para|title}} and {{para|volume}} now that the volume parameter knows to not boldface long parameter values, as for instance in | |||
| :<nowiki>{{cite book|first1=Elwyn R.|last1=Berlekamp|first2=John H.|last2=Conway|first3=Richard K.|last3=Guy|title=]|volume=Volume 2: Games in Particular|year=1982|publisher=Academic Press}}</nowiki> | |||
| :{{cite book|first1=Elwyn R.|last1=Berlekamp|first2=John H.|last2=Conway|first3=Richard K.|last3=Guy|title=]|volume=Volume 2: Games in Particular|year=1982|publisher=Academic Press}} | |||
| So I agree with the general sentiment that having title and work be aliases of each other seems harmless enough, as long as we can get an error flag when both are used together to let us find them and replace one of the two parameters by volume or series or whatever the replacement should be. However, this does bring up a different issue (not really solved very well by misuse of the work parameter): what do we do when we have a book series that contains a multivolume book and we want to refer to one volume of that book? The {{para|volume}} parameter currently has two quite different semantics: the number of a book within a series of books, and the number or title of a volume within a single multivolume book. Is there some way to add a {{para|series-volume}} parameter to be used in ambiguous cases, or something like that? —] (]) 00:37, 17 September 2015 (UTC) | |||
| == Request move for Module talk:Citation/CS1 == | |||
| Could use some eyeballs at ]. Thanks! ] (]) 01:37, 15 September 2015 (UTC) | |||
| == choosing the correct metadata when |chapter=, |title=, and |work= are all set == | |||
| Here is a list of all of the cs1 templates in the form: | |||
| :<code><nowiki>{{cite ___ |title=Title |chapter=Chapter |work=Work}}</nowiki></code> | |||
| *arXiv: {{Cite arxiv |title=Title |chapter=Chapter |work=Work |author=Author}} – chapter and work not supported in this template; includes {{para|author}} to avoid the bot invocation message | |||
| *AV media: {{Cite AV media |title=Title |chapter=Chapter |work=Work}} | |||
| *AV media notes: {{Cite AV media notes |title=Title |chapter=Chapter |work=Work}} | |||
| *book: {{Cite book |title=Title |chapter=Chapter |work=Work}} | |||
| *conference: {{Cite conference |title=Title |chapter=Chapter |work=Work}} | |||
| *DVD notes: {{Cite DVD notes |title=Title |chapter=Chapter |work=Work}} | |||
| *encyclopedia: {{Cite encyclopedia |title=Title |chapter=Chapter |work=Work}} | |||
| *episode: {{Cite episode/new |title=Title |chapter=Chapter |work=Work}} – chapter not supported; title is promoted to chapter; series is promoted to title; work ignored | |||
| *interview: {{Cite interview |title=Title |chapter=Chapter |work=Work}} | |||
| *journal: {{Cite journal |title=Title |chapter=Chapter |work=Work}} – chapter ignored | |||
| *mailing list: {{Cite mailing list |title=Title |chapter=Chapter |work=Work}} – work not supported; chapter is but shouldn't be | |||
| *map: {{Cite map |title=Title |chapter=Chapter |work=Work}} – chapter not supported; | |||
| *news: {{Cite news |title=Title |chapter=Chapter |work=Work}} – chapter ignored | |||
| *newsgroup: {{Cite newsgroup |title=Title |chapter=Chapter |work=Work}} – chapter ignored | |||
| *podcast: {{Cite podcast |title=Title |chapter=Chapter |work=Work}} – chapter ignored | |||
| *press release: {{Cite press release |title=Title |chapter=Chapter |work=Work}} – chapter ignored | |||
| *serial: {{Cite serial |title=Title |chapter=Chapter |work=Work}} – chapter not supported | |||
| *sign: {{Cite sign |title=Title |chapter=Chapter |work=Work}} – should only support title | |||
| *speech: {{Cite speech |title=Title |chapter=Chapter |work=Work}} – should only support title | |||
| *techreport: {{Cite techreport |title=Title |chapter=Chapter |work=Work}} | |||
| *thesis: {{Cite thesis |title=Title |chapter=Chapter |work=Work}} | |||
| *web: {{Cite web |title=Title |chapter=Chapter |work=Work}} – chapter ignored | |||
| and cs2: | |||
| *citation: {{Citation |title=Title |chapter=Chapter |work=Work}} – chapter ignored | |||
| The purpose of this list is to examine how the various templates handle the three parameters when all are set. ] led me to discover that ] may not be emitting correct metadata when {{para|work}} is set. | |||
| In Module:Citation/CS1 (and in {{tlx|citation/core}} before it), {{para|work}} and its aliases ({{para|journal}}, {{para|newspaper}} etc.) map to the meta-parameter <code>Periodical</code>. Similarly, {{para|chapter}} (and its aliases {{para|article}}, {{para|contribution}}, etc.) map to the meta-parameter <code>Chapter</code>. | |||
| There are two types of metadata: book and journal. When creating the citation's metadata, the module looks first at <code>Chapter</code>. If <code>Chapter</code> is set then the metadata type is set to book. If <code>Chapter</code> is not set but <code>Periodical</code> is set then the metadata type is set to journal. For all other cases, the metadata type is set to book. | |||
| Because the module knows which of the cs1|2 templates it is processing, we can use that knowledge to fix this issue. I will change the module so that these templates produce journal type metadata: | |||
| *arXiv | |||
| *conference – only when {{para|work}} is set (conference paper published in a journal) | |||
| *interview – only when {{para|work}} is set (interview published in a magazine, newspaper, television broadcast, etc.) | |||
| *journal | |||
| *news | |||
| *press release – only when {{para|work}} is set (published in a newspaper, magazine, etc.) | |||
| *citation – only when {{para|work}} is set | |||
| Then comes a more difficult question. The metadata can accommodate two title-holding parameters: <code>rft.jtitle</code> and <code>rft.atitle</code> for journals, or <code>rft.btitle</code> and <code>rft.atitle</code> for books. When cs1 templates use three title-holding parameters {{para|chapter}}, {{para|title}}, and {{para|work}}, which two of these should be made part of the metadata? Some templates are already constrained to one or two title-holding parameters; should others be similarly constrained? | |||
| —] (]) 13:35, 15 September 2015 (UTC) | |||
| :] tweaked. These are {{tlx|cite conference}} examples: | |||
| :*{{para|title}}, {{para|chapter}}, {{para|work}} – uses jtitle, atitle, and sets genre to article | |||
| :**{{code|{{Cite conference/new |title=Title |chapter=Chapter |work=Work}}}} | |||
| :*{{para|title}}, {{para|chapter}} – uses btitle, atitle, and sets genre to bookitem | |||
| :**{{code|{{Cite conference/new |title=Title |chapter=Chapter}}}} | |||
| :*{{para|title}} – uses btitle and sets genre to book | |||
| :**{{code|{{Cite conference/new |title=Title}}}} | |||
| :the same but this time with the one-way alias {{para|book-title}}; chapter is held in {{para|title}} ({{para|chapter}} is ignored when {{para|book-title}} is set): | |||
| :*{{para|book-title}}, {{para|title}}, {{para|work}} – uses jtitle, atitle, and sets genre to article | |||
| :**{{code|{{Cite conference/new |book-title=Title |title=Chapter |work=Work}}}} | |||
| :*{{para|book-title}}, {{para|title}} – uses btitle, atitle, and sets genre to bookitem | |||
| :**{{code|{{Cite conference/new |book-title=Title |title=Chapter}}}} | |||
| :*{{para|book-title}} – uses btitle and sets genre to book | |||
| :**{{code|{{Cite conference/new |book-title=Title}}}} | |||
| :—] (]) 15:05, 15 September 2015 (UTC) | |||
| == |section= not working in cite news? == | |||
| I used |section= in a {{tld|cite news}} in the ] article, and I got the error: "|chapter= ignored (help)". ] <span style="color:red">🍁</span> ] 23:13, 15 September 2015 (UTC) | |||
| :This? | |||
| ::<code><nowiki>{{cite news | |||
| |last = Hampton | |||
| |first = Howard | |||
| |title = Black Flag: Waving Goodbye to the World | |||
| |newspaper = ] | |||
| |date = 1984-04-17 | |||
| |page = 8 | |||
| |section = 3 | |||
| |url = https://news.google.com/newspapers?nid=1959&dat=19840417&id=OXMhAAAAIBAJ&sjid=OogFAAAAIBAJ&pg=2247,1781571&hl=en | |||
| |ref = harv}}</nowiki></code> | |||
| :::{{cite news | |||
| |last = Hampton | |||
| |first = Howard | |||
| |title = Black Flag: Waving Goodbye to the World | |||
| |newspaper = ] | |||
| |date = 1984-04-17 | |||
| |page = 8 | |||
| |section = 3 | |||
| |url = https://news.google.com/newspapers?nid=1959&dat=19840417&id=OXMhAAAAIBAJ&sjid=OogFAAAAIBAJ&pg=2247,1781571&hl=en | |||
| |ref = harv}} | |||
| :{{para|section}} is an alias of {{para|chapter}}, hence the error message. Consider {{para|at|Section 3, p. 8}} | |||
| ::{{cite news | |||
| |last = Hampton | |||
| |first = Howard | |||
| |title = Black Flag: Waving Goodbye to the World | |||
| |newspaper = ] | |||
| |date = 1984-04-17 | |||
| |at= Section 3, p. 8 | |||
| |url = https://news.google.com/newspapers?nid=1959&dat=19840417&id=OXMhAAAAIBAJ&sjid=OogFAAAAIBAJ&pg=2247,1781571&hl=en | |||
| |ref = harv}} | |||
| :—] (]) 23:24, 15 September 2015 (UTC) | |||
| ::: Is |section= (or |chapter= or whatever) not supposed to work, then? ] <span style="color:red">🍁</span> ] 00:29, 16 September 2015 (UTC) | |||
| ::::The mention of {{para|chapter}} and {{para|section}} in ] could lead someone to think it is OK to use those parameters in {{tl|cite news}}. ] (]) 02:31, 16 September 2015 (UTC) | |||
| ::::: I sthere some reason it shouldn't be? The newspaper I cited had sections with their own paginations. ] <span style="color:red">🍁</span> ] 03:58, 16 September 2015 (UTC) | |||
| ::::::Isn't it true that most newspapers have separate sections and pagination? The documentation for {{para|at}} at <code><nowiki>{{</nowiki>]}}</code> specifically includes Section. The decision to make {{para|section}} an alias of {{para|chapter}} was taken long ago in support of another template ({{tlx|cite manual}} I think). Chapters are not supported in periodicals because it is not possible to shoehorn three cs1|2 title-holding parameters ({{para|newspaper}}, {{para|title}}, and {{para|section}} in this case) into the two metadata title-holding parameters (<code>rft.jtitle</code> and <code>rft.atitle</code>). Because there is an in-source metadata parameter (<code>rft.pages</code>), setting {{para|at|Section 3, p. 8}} renders the complete citation visually as well as in the metadata. | |||
| ::::::—] (]) 10:46, 16 September 2015 (UTC) | |||
| ::::::: Well, that went over my head, but okay ... But wouldn't it be better to have the template automatically format it at least, rather than spit out an error? ] <span style="color:red">🍁</span> ] 12:18, 16 September 2015 (UTC) | |||
| ::::::::The template spits out an error because it doesn't know what to do with a chapter alias in a periodical-style citation. How should it be automatically formatted? Quoted? Italics? Neither of those? Where in the rendered citation should it go? The answers to these questions must apply to a very large majority of the templates in which {{para|section}} is used. | |||
| ::::::::—] (]) 15:02, 16 September 2015 (UTC) | |||
| ::::::::: Well, if it's what I have to do then it's what I have to do, but it (a) feels like a hack, and (b) is totally unintuitive. |at= "May be used instead of 'page' or 'pages' where a page number is inappropriate or insufficient"—in this case |page= sure doesn't ''seem'' insufficient (it's on page 8!), and |at= isn't the obvious answer (you have to dig to find it, and then interpret the documentation as "Aha! This situation!"). | |||
| ::::::::: if |section= et. al don't work, then shouldn't they be removed from the "COinS metadata is created for these parameters" section? ] <span style="color:red">🍁</span> ] 23:27, 16 September 2015 (UTC) | |||
| :::::{{para|section}} ''should'' be supported in periodicals, independently of {{para|chapter}}, because there are important sources that do break articles by sections. Also by paragraphs. ~ ] (]) 22:40, 17 September 2015 (UTC) | |||
| == error message tweak == | |||
| I have tweaked ]. The current live version of the module lumps all aliases of {{para|chapter}} into a single '|chapter= ignored' error message. This tweak causes the error message to identify the alias that is used in the cs1|2 template: | |||
| *{{cite journal/new |title=Title |journal=Journal |chapter=Chapter}} | |||
| *{{cite journal/new |title=Title |journal=Journal |contribution=Contribution}} | |||
| *{{cite journal/new |title=Title |journal=Journal |entry=Entry}} | |||
| *{{cite journal/new |title=Title |journal=Journal |article=Article}} | |||
| *{{cite journal/new |title=Title |journal=Journal |section=Section}} | |||
| —] (]) 23:53, 15 September 2015 (UTC) | |||
| :Wouldn't it be far more helpful to directly alias these to cite journal's version of {{para|title}}, given that that's what they mean? If they're used at the same time, then {{para|chapter}} could be treated as {{para|at}}, within {{para|title}}. And if {{para|at}} is {{em|also}} present, well, I dunno; have an {{para|at2}}.<p>This brings me back to my earlier proposal of normalizing all these parameter names across all the templates. It would be so much simpler if we had something like this: | |||
| <code><poem><nowiki>{{Cite ______ | |||
| |cite= | |||
| |at= | |||
| |work= | |||
| |... | |||
| }}</poem></nowiki></code> | |||
| where {{para|cite}} is the minor work being cited (article, episode, book chapter, song on album, etc.); {{para|at}} is a subset there of, where relevant (section of article, section of book chapter, whatever); {{para|work}} is the major work (journal/newspaper/magazine, website, book title, album, TV series, etc.). I get more and more tempted all the time to just go create a CS3 designed from the start to be mutually consistent across all media types, so someone could learn how to cite in {{em|one sitting}} and get it right no matter what they're citing. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 23:12, 16 September 2015 (UTC) | |||
| :Hindsight being what it is, were we to do it again, crafting a citation system from the ground up by starting with a real style guide and then coding to that would be preferable. But that isn't how it happened. We started with one or two templates that evolved into some twenty, all written independently. {{tlx|citation/core}} reduced the differences amongst the templates and ] continues that with varying amounts of success. That is the problem with the evolutionary nature of Misplaced Pages: start with something disruptive and then tweak it until it's just good enough. | |||
| :—] (]) 09:59, 17 September 2015 (UTC) | |||
| == COinS and smallcaps == | |||
| ] needs an update (where the {{tlx|clarify}} tag is) on what people should do to get the desired {{smallcaps|Small Caps}} effect for certain things in particular citation styles, given that {{tlx|Smallcaps}} is not COinS-safe. <span style="white-space:nowrap;font-family:'Trebuchet MS'"> — ] ] ] ≽<sup>ʌ</sup>ⱷ҅<sub>ᴥ</sub>ⱷ<sup>ʌ</sup>≼ </span> 23:02, 16 September 2015 (UTC) | |||
| :{{done}}. Let me know if my edits are unclear in incomplete. – ] (]) 03:37, 17 September 2015 (UTC) | |||
| == Proposal for lead with the main cite that Wikipedians come to this page for == | |||
| I think right on the "first screen" that the reader sees, without having to scroll down, she should see what is probably the main cite format that people to come to this page for: <nowiki>cite web |url= |title= |last1= |first1= |last2= |first2= |date= |website= |publisher= |access-date= |quote=}}</nowiki>. I think this would be helpful : )<small><span style="text-shadow:4px 4px 15px #00F,-4px -4px 15px #49F;">]</span> • <span style="text-shadow:4px 4px 15px #F80,-4px -4px 15px #F08;">]</span></small> 17:03, 17 September 2015 (UTC) | |||
| :To be consistent, we would need to change the documentation for dozens of cite templates. Are there other templates whose documentation is structured in this way? I clicked on a sample of templates that I watch, including {{tl|Birth date}}, {{tl|Birth date and age}}, {{tl|Death date and age}}, {{tl|GOCE award}}, {{tl|Infobox body of water}}, and {{tl|Template for discussion}}. Of those that have a lead section and a table of contents, none of them do what {{U|OnBeyondZebrax}} proposes. – ] (]) 01:02, 18 September 2015 (UTC) | |||
| I think this would be quite unhelpful, actually. We should be encouraging Misplaced Pages editors to cite newspapers, books, and academic journals rather than web pages. And when they do cite those things, we should not be encouraging them to use the wrong template to do so. —] (]) 01:12, 18 September 2015 (UTC) | |||
| ::Yes. ''Especially'' where a web "source" only echoes a printed source. A large proportion of WP editors are quite unacquainted with the broad range of possible sources, and we need to gently encourage them to see beyond the web. ~ ] (]) 21:20, 23 September 2015 (UTC) | |||
| == Update to the live CS1 module weekend of 26–27 September 2015 == | |||
| On the weekend of 26–27 September I propose to update the live CS1 module files from the sandbox counterparts: | |||
| Changes to ] are: | |||
| #bug fix in {{para||edition}} test; ] | |||
| #bug fix in <code>parse_vauthors_veditors()</code>; ] | |||
| #add test for 'and others' text to <code>name_has_etal ()</code>; ] | |||
| #enhanced {{para|url}} scheme test; ] | |||
| #fix cite episode missing {{para|series}} error message; ] | |||
| #bug fix in <code>select_author_editor_source ()</code> that skipped extract_name(); ] | |||
| #remove support for deprecated parameters, including {{para|month}}; ] | |||
| #expand defined-value error detection; ] | |||
| #add Macedonian (mk) to languages supported by {{para|script-title}}; | |||
| #suppress original url when {{para|dead-url|usurped}}; ] | |||
| #add support for {{para|script-chapter}}; ] | |||
| #hyphenate parameter names in error messages; ] | |||
| #move url prefixes for identifiers {{para|asin}} and {{para|ol}} to /Configuration; | |||
| #add url in {{para|title}}, {{para|chapter}}, {{para|work}} parameters; ] | |||
| #combine {{para|trans-title}} & {{para|trans-chapter}} error messages; ] | |||
| #remove stray colon from ismn rendering; | |||
| #add translator support; ] | |||
| #tweak COinS to prevent duplication of first author; ] | |||
| #enhance {{para|vauthors}} error checking; ] | |||
| #replace wrapping {{tag|span}} with {{tag|cite}}; ] | |||
| #COinS output by <code>citationClass</code> rather than by parameter; ] | |||
| #tweak missing chapter error messages; ] | |||
| Changes to ] are: | |||
| #deactivated 24 deprecated parameters; ] | |||
| #create table of keywords used by <code>is_valid_parameter_value()</code>; ] | |||
| #hyphenate parameter names in error messages; ] | |||
| #add translator support; ] | |||
| #move url prefixes for identifiers {{para|asin}} and {{para|ol}} from Module:Citation/CS1 | |||
| #add url in {{para|title}}, {{para|chapter}}, {{para|work}} parameters; ] | |||
| #change isbn error category name; ] | |||
| #change embedded wikilink error message and category; ] | |||
| #combine {{para|trans-title}} & {{para|trans-chapter}} error messages; ] | |||
| Changes to ] are: | |||
| #deactivated 24 deprecated parameters; ] | |||
| #deprecate {{para|Ref}}; non-standard capitalization; ] | |||
| #add translator support; ] | |||
| Changes to ] are: | |||
| #hyphenate parameter names in error messages; ] | |||
| —] (]) 12:10, 19 September 2015 (UTC) | |||
| :Looks good to me. Look at all of the good work we have accomplished in the last couple of months! – ] (]) 13:45, 19 September 2015 (UTC) | |||
| ::For the record, this update happened about 40 minutes before my time stamp. – ] (]) 16:54, 26 September 2015 (UTC) | |||
| == Test for date in <code>|author=</code>? == | |||
| I came across a date in {{para|author}} while working on . How hard would it be to test for dates, or at least well-formed dates, in {{para|author}} fields? As always, I worry about false positives, so it may be something to put in a maintenance category. | |||
| I suspect that some sort of automated reference-filling tool populated {{para|author}} with dates, or at least included dates along with the author name, due to bad metadata on the source web page or bad processing of the page's data. – ] (]) 13:58, 19 September 2015 (UTC) | |||
| :If such a test is to be created, bear in mind we allow editors to enter corporate authors in this field. Some organizations have a date fragment in their name. So the test should only be triggered if a well-formed date containing a year, month, and day is present. ] (]) 14:11, 19 September 2015 (UTC) | |||
| :{{ping|Jonesey95}} Edits like {{diff|Ann_Gregory|prev|647175768|the one you've mentioned}} are a result of editors not fixing the suggestions given by ] before saving their edits. ] with {{u|Dispenser}} but did not get any answer. ] tries to fix/remove some bad author values, but can't fix them all. Therefore, I support a maintenance category. ] (]) 14:16, 19 September 2015 (UTC) | |||
| :] was the tool: {{diff|Ann Gregory|647156958|647156652|diff}} and {{diff|Ann Gregory|647175768|647175718|diff}}. But, like any edit, the tool-user is equally culpable. | |||
| :If this is a problem caused by a tool, then the tool should be fixed. I suspect that searching for date formats that both do and don't comply with ] is a challenge that we should only accept if there is significant evidence of widespread malformed {{para|author}} parameters in the field. | |||
| :(I've renamed this section to remove {{tlx|para}} so that section links from watch lists work.) | |||
| :—] (]) 14:31, 19 September 2015 (UTC) | |||
| ::{{ping|Trappist the monk}} A quick search of the September 2015 database dump of <code></code> found 2,304 results. I'm sure other formats will find additional instances. I'm adding some rules for BattyBot to remove the date from the author parameter when it matched the YYYY-MM-DD date in the date parameter. I'd also be happy if {{U|ReferenceBot}} would notify editors when they added references with incorrect parameters like this. ] (]) 15:40, 19 September 2015 (UTC) | |||
| :::Is that number sufficiently large to make us add code to the module and create some sort of category to support it? Is this an automated tool issue or is it an error commonly made by editors filling out the template? | |||
| :::—] (]) 16:06, 19 September 2015 (UTC) | |||
| ::::{{ping|Trappist the monk}} To determine if it's sufficiently large enough, I guess you would first identify the most common incorrect formats, see how many added/tweaked rules could be added to BattyBot, and then see how many are left. My guess is this is commonly an issue of people not taking care when using automated tools (and people unwilling to fix their tools), but I have no statistics on that. ] (]) 18:32, 19 September 2015 (UTC) | |||
| :::::How can BattyBot fix these errors if they are not yet in a category? – ] (]) 20:31, 19 September 2015 (UTC) | |||
| ::::::{{ping|Jonesey95}} I built the list of articles based on a database search for <code>author\s*=\s*(January|February|March|April|May|June|July|August|September|October|November|December)\s+\d{1,2},\s+\d{4}</code>. ] (]) 20:40, 19 September 2015 (UTC) | |||
| ==Citeweb website parameter== | |||
| Would it be possible to make this respond to typing "site=" as well as "website=" ? "Web" is implied by the use of the template and this would take up less space and I find myself using that by accident a lot. ] (]) 14:52, 22 September 2015 (UTC) | |||
| == Foreign language authors & publishers == | |||
| I'm wondering whether we should establish a way that foreign language author and publisher names should be handled in citation templates. This has been addressed before here: ] (perhaps elsewhere but I was unable to find it) but there wasn't consensus on what should be done with author names that are written in non-Latin scripts. I understand that English sources are preferred on the English Misplaced Pages, but if the only sources available are written in Korean or Chinese, how should the author's name be included? Including only a transliteration does nothing to help someone who is trying to locate an article if its URL is dead. Since using the script-title and trans-title parameters produces "Script title ", perhaps something similar should be prescribed for author and publisher names? For example: <ref>{{cite news|author1=고경석 |script-title='헬로우 고스트' 명품조연 고창석-장영남, 코믹귀신 '변신'|trans-title="Hello Ghost" Supporting Actors Ko Chang-seok & Jang Young-nam, Comic Ghost "Transformation"|url=http://www.asiae.co.kr/news/view.htm?idxno=2010120302200141820|accessdate=22 September 2015|work=아시아경제 |date=3 December 2010}}</ref> | |||
| {{talk-reflist}} | |||
| As someone who has done a lot of work trying to rescue dead references, I've found it very frustrating if all I have available is the URL and an author name that was romanized in a non-standardized manner. Thanks, and I'm looking forward to your input, <span style="text-shadow:black 0.1em 0.1em 0.1em; font-family: georgia">]</span> <sup>(]|])</sup> 18:05, 22 September 2015 (UTC) | |||
| :Non-standard romanisations could be addressed by including the author's ] iD, or other authority control (or even a Wikidata ID), where they have one. <span class="vcard"><span class="fn">]</span> (<span class="nickname">Pigsonthewing</span>); ]; ]</span> 22:11, 23 September 2015 (UTC)r | |||
| :: Thanks for your response. Most of the references I come across are Korean online newspapers and the authors are generally not notable enough to have any data on Wikidata and there is no ID identifying them. In the past I have used the romanization with the corresponding ] in parentheses for author names, and have had others remove the Hangul because they thought that I hadn't formatted the reference correctly. As the citation templates' documentation are written now, there's nothing specifying whether the original script name or romanization should be included. <span style="text-shadow:black 0.1em 0.1em 0.1em; font-family: georgia">]</span> <sup>(]|])</sup> 06:54, 24 September 2015 (UTC) | |||
| == Cite video game == | |||
| I'm wondering if it's possible to get default support for ] in ] or perhaps some help with integrating it better with CS1. Right now, it bizarrely relies on ] (for the metadata???), which is inhibiting the correct citation of a video game with italics. Current example of an outputted title would be: "Example", as opposed to the correct ''Example''. Previous discussion at ] petered out in 2013 regarding the change (incorrectly) from quotation marks to italics. --] (]) 00:10, 24 September 2015 (UTC) | |||
| {{tlx|cite AV media}}? | |||
| <pre>{{cite AV media | |||
| |title=] | |||
| |author=] <!-- developer --> | |||
| |publisher=] | |||
| |date=2007-09-25 | |||
| |series=] v1.0 <!-- concatenation of |platform= and |version= --> | |||
| |at=The Storm | |||
| |language= | |||
| |quote='''Arbiter''': "More Brutes?" / '''Master Chief''': "Worse." | |||
| }}</pre> | |||
| {{cite AV media | |||
| |title=] | |||
| |author=] <!-- developer --> | |||
| |publisher=] | |||
| |date=2007-09-25 | |||
| |series=] v1.0 <!-- concatenation of |platform= and |version= --> | |||
| |at=The Storm | |||
| |language= | |||
| |quote='''Arbiter''': "More Brutes?" / '''Master Chief''': "Worse." | |||
| }} | }} | ||
| {{FAQ|page=Help talk:Citation Style 1/FAQ}} | |||
| == Internet archive print disability book links == | |||
| —] (]) 00:53, 24 September 2015 (UTC) | |||
| : {{para|series}} probably isn't much worse than {{para|volume}} + {{para|issue}}, I guess. {{para|via}} might be better but for the fact of the pre-output "via". --] (]) 01:20, 24 September 2015 (UTC) | |||
| ::I modified the sandbox of {{tl|Cite video game}} to use {{tl|cite book}} instead of {{tl|cite journal}}. It looks like this: | |||
| :::<code><nowiki>{{cite video game/sandbox | |||
| |title=] | |||
| |developer=] | |||
| |publisher=] | |||
| |date=2007-09-25 | |||
| |platform=] | |||
| |version=1.0 | |||
| |level=The Storm | |||
| |language= | |||
| |quote='''Arbiter''': 'More Brutes?' / '''Master Chief''': 'Worse.' | |||
| }}</nowiki></code> | |||
| ::Yields: | |||
| :::{{cite video game/sandbox | |||
| |title=] | |||
| |developer=] | |||
| |publisher=] | |||
| |date=2007-09-25 | |||
| |platform=] | |||
| |version=1.0 | |||
| |level=The Storm | |||
| |language= | |||
| |quote='''Arbiter''': 'More Brutes?' / '''Master Chief''': 'Worse.' | |||
| }} | |||
| ::Compare to the current template: | |||
| :::{{cite video game | |||
| |title=] | |||
| |developer=] | |||
| |publisher=] | |||
| |date=2007-09-25 | |||
| |platform=] | |||
| |version=1.0 | |||
| |level=The Storm | |||
| |language= | |||
| |quote='''Arbiter''': 'More Brutes?' / '''Master Chief''': 'Worse.' | |||
| }} | |||
| ::It looks like the sandbox results in the current rendering, except with italics for the title, per ]. – ] (]) 03:31, 24 September 2015 (UTC) | |||
| :::I updated the module. If we see a regression, someone can come bug me. --] (]) 17:03, 24 September 2015 (UTC) | |||
| ::::You should probably post a note at the very active ], citing ] as the reason for the change. Citation-related talk pages are often watched by few people compared to the number who watch project pages. – ] (]) 17:14, 24 September 2015 (UTC) | |||
| ::::: I'm part of ], but I probably should anyway. ;) --] (]) 17:44, 24 September 2015 (UTC) | |||
| I'm not sure that {{tlx|cite book}} is the right template. One of the things that will change with the next update to the module is that the metadata will be in slightly closer alignment to the template that creates it; see ]. | |||
| Also see ]. The Used keys table there shows which metadata keywords are supported for the two object types available to us. Right now, everything is a book unless it is {{tlx|cite arxiv}}, {{tlx|cite journal}} or {{tlx|cite news}} in which case it is a journal. {{tlx|citation}}, {{tlx|cite conference}}, {{tlx|cite interview}}, and {{tlx|cite press release}} are treated as journal when the the module's metaparameter <code>Periodical</code> is set; otherwise these are treated as book. | |||
| The metadata keyword <code>rft.genre</code> has several set values that it can hold depending on the object (book or journal). After this next update to the module, I intend to refine how <code>rft.genre</code> is used for the individual templates. | |||
| Getting back to the topic, because {{tlx|cite video game}} uses {{tld|cite book}}, the metadata will describe the video game as a book. Just as {{tld|cite journal}} was the wrong template because of visual styling, so too is {{tld|cite book}} the wrong template because of the metadata that will/are being produced. Because those things typically cited with {{tld|cite AV media}} are not books or journals and because the metadata only give us book or journal, we should choose book for the metadata and then set <code>rft.genre</code> to <code>unknown</code>. Because {{para|volume}} and {{para|issue}} are not supported in the metadata for book, {{para|series}} is an appropriate choice to receive both {{para|platform}} and {{para|version}}. | |||
| I have hacked the {{tld|cite video game}} sandbox to use {{tld|cite AV media}}: | |||
| :{{cite video game/sandbox |title=] |developer=] |publisher=] |date=2007-09-25 |platform=] |version=1.0 |level=The Storm |language= |quote='''Arbiter''': 'More Brutes?' / '''Master Chief''': 'Worse.'}} | |||
| Visually similar except for the parentheses around {{para|version}}. | |||
| —] (]) 23:41, 24 September 2015 (UTC) | |||
| == techreport in a collection? == | |||
| What is the proper markup to use for a tech report that's published as part of a collection of such papers? Specifically, what's the term to use to indicate the collection's title, as opposed to the article within it? ] (]) 19:17, 24 September 2015 (UTC) | |||
| :Would {{para|series}} work for your source? See ]. – ] (]) 19:46, 24 September 2015 (UTC) | |||
| ::I believe a "series" is usually taken as, well, a ''series'' of separate publications over a period of time (i.e., "periodically"). For a collection of articles (or reports) published together "work" seems more appropriate. The documentation suggests that "works" are only newspapers, magazines, and journals – i.e., periodicals – but "work" as a collection seems well established. Perhaps at some point that should be documented. ~ ] (]) 20:04, 25 September 2015 (UTC) | |||
| So <nowiki>{{cite work</nowiki>? That seems appropriate. ] (]) 13:33, 4 October 2015 (UTC) | |||
| == How to fix this external link error? == | |||
| There are articles showing up in the new {{cl|CS1 errors: external links}} because of the following citation format: | |||
| {{cite compare|mode=citation |contribution=] |title=''], ]'' |editor-last=Baynes |editor-first=Thomas Spencer |display-editors=0 |publisher=Charles Scribner's Sons |location=New York |date=1878 |ref={{harvid|EB|1878}} |p=45|old=no}} | |||
| I have seen a few in this format in a sample of articles from the category. We should probably have a recommended way of fixing these. Any proposals? – ] (]) 16:35, 26 September 2015 (UTC) | |||
| :Follow-up: {{tl|EB1911}} is also generating this error message. It is transcluded in 12,387 articles. It uses {{tl|Cite EB1911}}, which is transcluded in 16,067 articles. It would be good for us to find a fix for this template before this red error message is displayed on that many pages. – ] (]) 16:49, 26 September 2015 (UTC) | |||
| The test was fooled by the <code><nowiki>[[s:</nowiki></code> the last three characters of which look like a legitimate uri scheme. I've added a check for internal wikilinks to a namespace. Here we see that the rest of the code still catches a legitimate uri scheme: | |||
| :<code><nowiki>{{cite book/new |title=}}</nowiki></code> | |||
| ::{{cite book/new |title=}} | |||
| Live module updated. | |||
| —] (]) 17:19, 26 September 2015 (UTC) | |||
| :That works for me. Thanks. This pattern may need some more tweaking. This citation is causing an error message: | |||
| {{cite compare|mode=journal|url=http://www.ljubljana.si/file/1174311/gl_2012_07_internet.pdf|title=2000 let Emone? Kaj bomo praznovali?|language=sl|trans_title=2000 Years of Emona? What Will We Celebrate?|first=Marjeta|last=Šašel Kos|journal=Ljubljana: glasilo Mestne občine Ljubljana |volume=XVII|issue=7|date=September 2012|issn=1318-797X|pages=28–29|accessdate=2013-07-01|archiveurl=http://www.webcitation.org/6HsSVueeU|archivedate=2013-07-05|deadurl=no|old=no}} | |||
| :We'll get this thing debugged. We may need to settle for finding specific patterns, like "<nowiki>http://</nowiki>". – ] (]) 17:52, 26 September 2015 (UTC) | |||
| ::The fix for this is pretty easy. In correctly formed external wikilinks, the first character after the required colon should not be a space. The fix then is changing: | |||
| :::<code>value:match ("%*:.*%]")</code> | |||
| ::to | |||
| :::<code>value:match ("%*:%S.*%]")</code> | |||
| ::But, should we? Should {{para|journal}} be holding both original and translated journal titles? (In this discussion, that is a rhetorical question that should be taken up and answered.) The url test, as it is, may find other templates that look like this one but I suspect that there won't be many of them. If that is a reasonable assumption, I'll tweak the sandbox but leave the live version alone. | |||
| ::—] (]) 18:33, 26 September 2015 (UTC) | |||
| :::As far as I know, we don't have a {{para|trans-work}} or {{trans-journal}} parameter, so what's an editor to do if that editor wants to be helpful by providing a translation of a journal name? | |||
| :::As the category populates, we'll get a better sense of how much of this stuff is out there. – ] (]) 19:01, 26 September 2015 (UTC) | |||
| I have refined the test pursuant to ]. The new test is: | |||
| :<code>value:match ("%f%*:%S.*%]")</code> | |||
| The frontier pattern adds the requirement that any character immediately preceding an external wikilink's opening square bracket must be something other than another square bracket: | |||
| :{{cite book/new |title=pass: doesn't find interwiki link ]}} | |||
| :{{cite book/new |title=] pass: doesn't find interwiki link at start of title}} | |||
| :{{cite book/new |title=fail: finds external link }} | |||
| :{{cite book/new |title= fail: finds external link at start of title}} | |||
| :{{cite book/new |title=fail: ] finds external link even with interwiki link}} | |||
| —] (]) 12:12, 27 September 2015 (UTC) | |||
| == Bad rendering and erroneous "extra text" message for author=Beaudet AL == | |||
| I found this citation in ]: | |||
| {{cite compare|mode=journal |author=Sahoo T, del Gaudio D, German JR, Shinawi M, Peters SU, Person RE, Garnica A, Cheung SW, Beaudet AL |title=Prader-Willi phenotype caused by paternal deficiency for the HBII-85 C/D box small nucleolar RNA cluster. |journal=Nat Genet |volume=40 |issue=6 |pages=719–21 |year=2008 |pmid=18500341 |doi=10.1038/ng.158 |pmc=2705197|old=no}} | |||
| The {{para|author|...Beaudet AL}} causes an "extra text" message to appear, and the author's name is not rendered correctly, presumably because the author's name ends in "et AL". I suppose you could say "don't list the authors that way", but a single author listed as {{para|author|Beaudet AL}} is acceptable, and it generates the same error: | |||
| {{cite compare|mode=journal |author=Beaudet AL |title=Prader-Willi phenotype caused by paternal deficiency for the HBII-85 C/D box small nucleolar RNA cluster. |journal=Nat Genet |volume=40 |issue=6 |pages=719–21 |year=2008 |pmid=18500341 |doi=10.1038/ng.158 |pmc=2705197|old=no}} | |||
| Just a minor bug to squish. – ] (]) 20:00, 26 September 2015 (UTC) | |||
| :squished. | |||
| :—] (]) 21:33, 26 September 2015 (UTC) | |||
| == Cite xxx defaults to {{para|nopp|y}} == | |||
| Please revert to prior. ] (]) 20:01, 26 September 2015 (UTC) | |||
| :]. | |||
| :—] (]) 21:34, 26 September 2015 (UTC) | |||
| == last-author-amp change == | |||
| For some reason this parameter is now reporting as invalid if the value is 1, as I've been using in hundreds of articles. Changing the value to y makes it display properly. Looking at the documentation any value should work, including 1. What has happened?--] (]) 23:01, 26 September 2015 (UTC) | |||
| :Good catch. I updated the documentation. This changed today; some parameters that had previously been lax about checking for appropriate values have been made more strict. One of the friendly gnomes here, maybe me, will be sweeping through with a script to update all of those "1" values. – ] (]) 23:22, 26 September 2015 (UTC) | |||
| ::Paging {{U|GoingBatty}} or someone else with access to AWB and some time on your hands. Do a search for <code><nowiki>insource:/\|\s*lastauthoramp\s*=\s*/</nowiki></code> to see a list of between 750 and 1,000 articles containing values of "1" or "&" for {{para|lastauthoramp}}. – ] (]) 01:30, 27 September 2015 (UTC) | |||
| :::{{ping|Jonesey95}} {{BOTREQ|BRFA|BattyBot 48}}. ] (]) 12:29, 27 September 2015 (UTC) | |||
| ::::While you were doing that I hacked a simple script to fix those {{para|last-author-amp}} parameters with something other than yes-true-y and remove {{para|last-author-amp|no}} and {{para|last-author-amp|n}} and that were in {{cl|CS1 errors: invalid parameter value}}. | |||
| :::::Find: <code>\|\s*last\-?author\-?amp\s*=\s*(?:no|n)</code> Replace: with nothing | |||
| :::::Find: <code>\|\s*last\-?author\-?amp\s*=\s**(+)</code> Replace: <code>|last-author-amp=yes$1</code> | |||
| ::::—] (]) 13:04, 27 September 2015 (UTC) | |||
| ::::::Nice. I've done a few dozen with an AutoEd script, but (a) 1,000 or so is more of a bot task, and (b) the errors are trickling into the category slowly, so if we can go find them before the red error messages show up for readers, that is a better approach. – ] (]) 14:57, 27 September 2015 (UTC) | |||
| {{od|::::::}}I asked this on the BRFA, and was suggested by Batty to repeat it here: Why do we need to make the parameter more strict? Some users are likely to continue to use the old values; can't we leave in support for it but have the alternate values be undocumented? Thanks. — ] <sup>'']''</sup> 22:38, 27 September 2015 (UTC) | |||
| :See ] and the ]. We had a number of parameters that were documented inconsistently and that functioned inconsistently and, sometimes, counterintuitively. For example, setting {{para|last-author-amp|no}} would give you an ampersand before the last author, even though you thought you were asking to the ampersand to be suppressed. On the other hand, setting {{para|subscription|no}} worked as expected. We made these parameters work consistently. | |||
| :Because some of the parameters' documentation instructed editors to use any value to make the parameter work, we are cleaning up these now non-standard usages to preserve the editors' intent. – ] (]) 23:10, 27 September 2015 (UTC) | |||
| ::Thanks, this helps clarify things. — ] <sup>'']''</sup> 01:26, 28 September 2015 (UTC) | |||
| == External link in |work= (help) == | |||
| I'm seeing a template with 100s of uses throwing this error message everywhere (which it didn't previously). The help link says to not put a URL in the work but put it in the url field. But what if the specific citation AND the work as a whole each have a URL, having just one url field isn't sufficient, so you have to do |work= as your only option. We often see the same problem with online accessible books/journals where you would like to have a URL for both the metadata (usually a library catalogue entry) as well as for the fulltext. One url field isn't sufficient, you really need at least 2 URL fields, one that takes you to the actual data and one that takes you to the work or meta-data that provides the contextual information surrounding the data (which might include how to interpret the data, the licensing etc). Until now you could do the work-around of having an external link in the work field or other field as necessary, but now this is prevented, how do we provide these 2 urls to the reader? I hope this can be fixed quickly. ] (]) 06:51, 27 September 2015 (UTC) | |||
| :{{ping|Kerry Raymond}} could you provide a specific example of a citation that causes you this problem? Note that two URLs are available via {{para|contribution-url}} and {{para|url}}. ] (]) 08:18, 27 September 2015 (UTC) | |||
| :: ] is one. The URL field (which is sort-of broken at the moment due to a recent change in the govt website but I am working to fix that) is different to the Work URL that explains what this data set is. ] (]) 08:29, 27 September 2015 (UTC) | |||
| This is a time when the general purpose nature of {{tlx|citation}} is a benefit: | |||
| :<code><nowiki>{{citation | |||
| |mode=cs1 | |||
| |contribution=Kenmore (41505) | |||
| |contribution-url=https://www.dnrm.qld.gov.au/mapping-data/place-names/search/queensland-place-names-search?id=41505 | |||
| |url=http://www.qld.gov.au/environment/land/place-names/ | |||
| |title=Queensland Place Names | |||
| |publisher=Queensland Government | |||
| |access-date= | |||
| |ref=CITEREFQPN41505 | |||
| }}</nowiki></code> | |||
| ::{{citation | |||
| |mode=cs1 | |||
| |contribution=Kenmore (entry 41505) | |||
| |contribution-url=https://www.dnrm.qld.gov.au/mapping-data/place-names/search/queensland-place-names-search?id=41505 | |||
| |url=http://www.qld.gov.au/environment/land/place-names/ | |||
| |title=Queensland Place Names | |||
| |publisher=Queensland Government | |||
| |access-date=13 September 2015 | |||
| |ref=CITEREFQPN41505 | |||
| }} | |||
| —] (]) 09:06, 27 September 2015 (UTC) | |||
| :Another advantage of this approach (i.e. using the {{tl|citation}} template as the primary one) is that by having {{para|mode}} available in the secondary template, it can be deployed in articles that use CS2. Many secondary citation templates don't allow a choice between CS1 and CS2, which prevents their use in many articles. ] (]) 09:40, 27 September 2015 (UTC) | |||
| ::Is contribution-url documented? I cannot see it. ] (]) 00:33, 29 September 2015 (UTC) | |||
| :::Visual editor does not know about it either. ] (]) 00:40, 29 September 2015 (UTC) | |||
| ::::{{para|contribution-url}} is listed at ]. It is a valid parameter that is an alias of {{para|chapter-url}} (also listed at Template Data). We need someone who knows and uses VE to update the VE-only documentation. As far as I know, there was never any documentation for {{para|contribution}} and {{para|contribution-url}}. There is no indication that either of these will be going away. | |||
| ::::—] (]) 00:56, 29 September 2015 (UTC) | |||
| == "The features of this template will be added to the citation templates in the next update." == | |||
| Greetings. ] (and other templates) say that their features (which presumably includes the <code><span lang=</code> microformat) will be included "in the next update". Has this been done for that specific template? I wanted to update the documentation there, but I don't know much about these übercomplicated templates.] (], ]) 21:15, 27 September 2015 (UTC) | |||
| :Retired Editor Gadget850, once a significant contributor to this project, added that comment. I'm not sure what his intentions were nor how he imagined that the facilities of {{tlx|lang}} et al. would be included in cs1|2. At a guess, I think that support for certain languages that use non-Latin alphabets was something that he was considering. Some of the {{tld|lang}} support is present in cs1|2 when editors use the {{para|script-title}} and {{para|script-chapter}} parameters. {{para|language}} now accepts ] codes. Editor Gadget850 participated regularly at this talk page and all of the cs1 template talk pages before they were merged into this talk page, and also to the talk pages for ] and {{tlx|citation}}. Perhaps your answer lies there. If you discover what it was that he meant by that rather cryptic note, come back and tell us what you've discovered. | |||
| :—] (]) 21:41, 27 September 2015 (UTC) | |||
| ::Doesn't look like it ever happened; there is a brief discussion ] but if it was implemented I can't see it. My understanding is that the language class could interfere with the COinS metadata; is there a solution to that?] (], ]) 08:16, 28 September 2015 (UTC) | |||
| :::Only the {{para|script-title}}, {{para|script-chapter}}, {{para|language}} I mentioned above has been implemented. There isn't a mechanism to automagically know that the content of {{para|title}} is indeed Spanish when {{para|language|es}}. I suppose we could use something similar to the language specifier that is used in {{para|script-title}} so that concerned editors could write {{para|title|es:...}} or maybe create {{para|lang-title}} that would use the content of {{para|language}} to wrap the title in {{tag|span|params=lang=...}}. | |||
| :::—] (]) 10:36, 28 September 2015 (UTC) | |||
| == Cite archive == | |||
| Editors may be interested in ] for a "cite archive" template. --] (]) 18:50, 28 September 2015 (UTC) | |||
| There are a number of links to books which have since lost their accessibility to the general public on Internet Archive (e.g., and of the same book). These are now " available to patrons with print disabilities." | |||
| == Where is the URL error here? == | |||
| Should the links like these which are ''not'' accessible to users ''without'' print disabilities be removed, or would it be possible to add another <code>|url-access</code> parameter to signify this? ] (]) 20:48, 28 November 2024 (UTC) | |||
| I must be missing something. Where is the URL error here? | |||
| :Alternatively (as with {{tlx|Hopcroft and Ullman 1979}}) should the link be appended to a reference a note? ] (]) 01:33, 29 November 2024 (UTC) | |||
| {{Cite American Factfinder2|2|46013|county|Brown County, South Dakota}} | |||
| ::{{re|Tule-hog}} I don't think any of the values in ] accurately represent the access status you have described. I'd be inclined to leave {{para|url-access}} blank and create a new template to indicate this information after the citation template, similar to many of the templates in ]. ] (]) 17:06, 16 December 2024 (UTC) | |||
| :::I went with {{tlx|Internet Archive patrons}} as a temporary solution, which allows for tracking pages (and ]) that use it (which should make future modifications more streamline-able). ] (]) 17:14, 16 December 2024 (UTC) | |||
| ::::], the book is fully searchable (click the magnifying glass). And, you can open it to any page like . This is the same as many books at Google Books. I would be careful about tagging books as "inaccessible" because there are many levels and types of access, beyond complete full access. We certainly don't tag Google Books. Also, access levels can change on a whim of the library based on publisher requirements, it's not set in stone, trying to maintain those tags over the years will be impossible. It's really beyond our scope or need. Readers are expected to be able to navigate and understand external websites. -- ]] 00:24, 17 December 2024 (UTC) | |||
| :::::That particular book is not fully browsable, click 'next page'. | |||
| :::::To clarify: are you in favor of deprecating <code>]</code> entirely, or are you making a point about Internet Archive's collections? ] (]) 00:39, 17 December 2024 (UTC) | |||
| ::::::"Fully browsable" is a rare condition for (copyright) books, at any website. At Internet Archive, for example, permissions can include: | |||
| ::::::* Full access for everyone | |||
| ::::::* Full access if you login | |||
| ::::::* Full access if you are disabled | |||
| ::::::* Some book pages browsable for everyone | |||
| ::::::* Some book pages browsable if you login | |||
| ::::::* Search access for everyone but not browsable | |||
| ::::::* Search access if you login but not browsable | |||
| ::::::* There are other permissions controlling access to files | |||
| ::::::Also, these permissions can, and frequently do, change at the whim of Internet Archive and the publishers, at any time. Including new types of permissions. | |||
| ::::::So my question is how you plan on communicating AND maintaining this information on Misplaced Pages for the next 20 years for millions of books. | |||
| ::::::Also, this is only one website. Google Books has similar gradations, is even more complex, and more opaque how it works. For these reasons we don't track the ''precise'' levels of access. It's generally understood that any copyright material is by default probably going to have ''some'' restrictions. It's a matter of practicality. -- ]] 02:50, 17 December 2024 (UTC) | |||
| :::::::Thank you for the clarification. Given that the current possibilities are: | |||
| :::::::* registration = 'Free registration required' | |||
| :::::::* limited = 'Free access subject to limited trial, subscription normally required' | |||
| :::::::* subscription = 'Paid subscription required' | |||
| :::::::do you think it would be unreasonable to collapse the tertiary possibilities discussed (e.g., search access only, some pages browsable, special permissions) into a fourth parameter: | |||
| :::::::* partial = 'Partial access, not fully readable' (or something) | |||
| :::::::The motivation for the parameter is the same as the other 3, with no more or less difficulty in implementation. In particular, it is to emphasize that the URL supplied is not "full access", in one way or another. ] (]) 00:21, 5 January 2025 (UTC) | |||
| ::::::::If the proposed fourth parameter is not reasonable, I will collapse the use of {{tlx|IAp}} to a simple <code>|url=</code> with no indicator. As a reader, I would find an indicator an appreciated convenience, but I don't see another solution. ] (]) 00:22, 5 January 2025 (UTC) | |||
| == DOI prefix limits should be bumped. == | |||
| When I View Source on this rendered page, I do not see a problem with the URL. I need another pair of eyes. – ] (]) 14:37, 29 September 2015 (UTC) | |||
| :], used in the creation of the URL, includes a comment at the beginning. Maybe that's causing the issue? --] (]) 14:58, 29 September 2015 (UTC) | |||
| ::{{tlx|Cite American Factfinder2}} gets it's value for {{para|url}} from {{tlx|American Factfinder2}} to which is passes three values, in this case <code>2</code>, <code>46013</code>, and <code>county</code>. With those values, {{tld|American Factfinder2}} returns this as a value for {{para|url}} | |||
| :::{{American Factfinder2|2|46013|CY10}} | |||
| We have DOI prefixes in the 10.70000s now. The limit should be bumped to 10.80000s  <span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 04:05, 1 December 2024 (UTC) | |||
| ::] rejects it because the 'url' contains spaces which urls must not do. | |||
| : Seconding this! —⁠]<sup>] ]</sup> 22:10, 17 December 2024 (UTC) | |||
| : | |||
| :If that is true, why (as I write this) is {{cl|CS1 errors: DOI}} empty? | |||
| ::<syntaxhighlight lang="wikitext" inline="1">{{PAGESINCATEGORY:CS1 errors: DOI}}</syntaxhighlight> → {{PAGESINCATEGORY:CS1 errors: DOI}} | |||
| :—] (]) 22:47, 17 December 2024 (UTC) | |||
| ::@]: The article ] has a DOI of 10.70460/jpa.v7i1.183 in reference #1 that is incorrectly giving a "<code>Check |doi= value</code>" error. Could you please help fix this? ] (]) 19:41, 19 December 2024 (UTC) | |||
| :Fixed in sandbox: | |||
| <div style="margin-left:3.2em">{{Cite compare |template=journal |last=McNiven |first=Ian J |date=2016 |title=Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea |journal=Journal of Pacific Archaeology |volume=7 |issue=1 |pages=74–83|doi=10.70460/jpa.v7i1.183 }}</div> | |||
| :—] (]) 20:06, 19 December 2024 (UTC) | |||
| ::Thank you! After this goes live, we could update the articles in ]. ] (]) 17:31, 26 December 2024 (UTC) | |||
| :::I reviewed each article in ] and removed the temporary error hiding for the 10.7#### DOIs that were kindly added by users such as {{U|Metamd}}, {{U|AManWithNoPlan}} and {{U|Snowman304}}. ] (]) 20:55, 2 January 2025 (UTC) | |||
| == cite episode id parameter silently ignored == | |||
| ::—] (]) 15:02, 29 September 2015 (UTC) | |||
| {{tl|cite episode}} currently silently ignores {{para|id}}. I have been using it to add IMDb identifiers to some items, eg. ] using {{tl|IMDb ID}}. I propose that we display the {{para|id}} parameter just like most other CS1 templates. A more elaborate discussion of IMDb in particular as an identifier is at {{slink|Misplaced Pages talk:IMDb link templates#IMDB as an identifier in citations}}. ] (]) 22:44, 4 December 2024 (UTC) | |||
| == Protected edit request on 1 October 2015 == | |||
| :{{para|id}} was: | |||
| :*initially supported at ] 25 May 2009 | |||
| :*reverted at ] 7 August 2009 | |||
| :*updated to use ] and simultaneously usurped as a vehicle to support {{para|network}} and {{para|station}} at ] 2 April 2012 | |||
| :Because it was the goal of the wikitext-to-module conversion to be transparent, it was necessary to overwrite whatever might be assigned to {{para|id}}. I do not recall any discussion here suggesting that we should change that. | |||
| : | |||
| :I am not enthusiastic about making a change just to support an identifier for a source that editors at ] have determined to be generally unreliable. | |||
| :—] (]) 00:20, 5 December 2024 (UTC) | |||
| :I've commented at the other discussion, there's general agreement that IMDb should not appear in references. I don't see how a courtesy link to an unreliable source can help with verification. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 01:16, 5 December 2024 (UTC) | |||
| ::I apologize for the delay in responding. {{u|Gonnym}} of ] two days after I raised the question here, making it difficult for me to determine how the template had been used. I strongly disagree with {{u|Gonnym}}'s claim that these uses of ] were "not what the ID= is for". It's exactly what {{para|id}} is for. Our current guideline is strong on this topic: {{slink|Misplaced Pages:Citing sources#Links and ID numbers}} says "{{tqi|A citation ideally includes a link or ID number to help editors locate the source.}}" Thus, '''according to this ]''', for these audiovisual materials where no link is suitable, '''some identifier ''should'' be included'''. I don't make a point of adding identifiers of this kind to citations generally, and I'm not sure I would advocate for the strength of that guideline's wording, but I believe that identifiers are beneficial to include for obscure content, such as old episodes of broadcast news. Contra {{u|ActivelyDisinterested}}, an identifier is not a ]. | |||
| ::This leads to the question of which identifier to use. Contra {{u|Trappist the monk}}, I don't think it matters whether IMDb is a reliable source. It matters whether its identifiers are ambiguous by being either underspecified or conflations. IMDb's primary benefit isn't the quality of its data or it's market share as {{u|Folly Mox}} suggests, but the breadth of its coverage. Other websites ] itself use its identifiers. If other identifiers were available, I would prefer to use them, but for items with no other identifier, we must use what we have. | |||
| ::For example, I think this citation (featuring a permanently dead link with no archives available) would be greatly benefited from the addition of an identifier from IMDb or anywhere else: | |||
| ::* {{cite episode | people=Mansbridge, Peter (host); Zaccardelli, Guiliano (guest) | title=Zaccardelli - On Maher Arar | url=http://www.cbc.ca/mrl3/23745/thenational/archive/zaccintvu-090308.wmv | series=] | publisher=] | airdate=September 3, 2008 | url-status=dead}} | |||
| ::I can't find anything about this episode on the internet except https://www.cbc.ca/news/canada/zaccardelli-faults-u-s-government-for-arar-s-deportation-1.757351 . | |||
| ::Perhaps a better solution than linking to IMDb would be to link to Wikidata using {{tl|QID}}. Wikidata's primary web interface isn't very navigable for readers, so perhaps a link target of Reasonator () or SQID ()? Forcing editors who want to add identifiers to create a Wikidata item linked to IMDb instead of using IMDb directly is more work for editors, which you may or may not find desirable. Searching revealed no existing policy or RFCs on using Wikidata an identifier in citations. ] (]) 02:04, 24 December 2024 (UTC) | |||
| :::The us of Wikidata on Misplaced Pages still has to comply with the consensus on Misplaced Pages. So using Wikidata to obfuscate a link to IMDb in a reference when there is a consensus against using IMDb in references sounds like a bad idea. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 10:52, 24 December 2024 (UTC) | |||
| ::::{{re|ActivelyDisinterested}} I wouldn't call this obfuscating a link to IMDb. As far as consensus on Misplaced Pages, we have a content guideline that requires the use of an identifier. That's as strong a consensus as it gets on Misplaced Pages. If this local consensus wants to argue against the use of IMDb as a identifier, I may be willing to accept that if Wikidata is preferred instead. At this local venue, we don't have the option of overruling a content guideline, and so may not forbid both IMDb and Wikidata. ] (]) 15:11, 24 December 2024 (UTC) | |||
| :::::The guideline doesn't require the use of an identifier, and certainly not these proposed identifiers. ] (]) 15:14, 24 December 2024 (UTC) | |||
| {{edit fully-protected|Template:Cite web|answered=yes}} | |||
| :::::No there is a strong general consensus across multiple discussions to not link IMDb in references, working out ways to circumvent that consensus is unadvisable. | |||
| <!-- Begin request --> | |||
| :::::Also the guideline also doesn't agree with your interpretation. It doesn't say that an ID is ''required'', it says ideally an ID can be included if it helps locate the source - IMDb doesn't help in locating the source. Even if it did require such a link that still wouldn't support your point, as it doesn't say that link must be to IMDb. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 15:29, 24 December 2024 (UTC) | |||
| :::I think it ''does'' matter that IMdB is not a reliable source, and expect most editors would agree. Out of curiosity, is the IMDb page on the episode given as example here (which I could not find) any more informative than the which also includes a "shotlist" element allowing for verification of certain quotes? Does the IMDb page truly {{xt|help editors locate the source}}, or is it a user-generated summary of the source? (Incidentally, but Internet Archive are unable to display it, possibly as a result of their recent lawsuit.) ] (]) 13:25, 24 December 2024 (UTC) | |||
| ::::{{re|Folly Mox}} Thank you for finding those archives! I was unable to do so despite significant effort, and obviously could learn a thing or two about finding them. I would regard the CBC archive summary as essentially the official website for the source, though not a manifestation of the source, and would certainly link to it. | |||
| ::::I don't expect identifiers to be informative. Is an ISBN informative? An ISBN is a number, not a resolver, a database, or a source. ] (]) 15:39, 24 December 2024 (UTC) | |||
| == Request to edit note at top of Category:CS1 maint: unflagged free DOI == | |||
| <!-- End request --> | |||
| ] (]) 12:54, 1 October 2015 (UTC) | |||
| :{{ping|197.156.86.194}} we need to know what change you desire to be made. Please provide us with some idea, preferably in a before and after format, so we know what it is you want us to do. <span style="background:#006B54; padding:2px;">'''] ]'''</span> 13:12, 1 October 2015 (UTC) | |||
| Hi there! Could someone please update the note at the top of ]? It mentions an issue affecting 17 Misplaced Pages articles, but there are now less than 10 articles in the category. Thanks! ] (]) 17:45, 8 December 2024 (UTC) | |||
| == Suggestion: maintenance or error category for characters that do not belong in any citation template == | |||
| :See ]. Also, I wonder why it dropped from 17. There hasn't been a template update in ages... I suspect someone performed bad fixes just to avoid the categorization.  <span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 12:15, 10 December 2024 (UTC) | |||
| This is a suggestion for a new maintenance or error category that could be created when characters are detected in citations that should not be in any citations. I'm thinking of various hidden characters and the � (question mark inside a diamond, character U+FFFD) that sometimes show up in Misplaced Pages articles because of copy-pasted text with hidden characters or characters that failed a transition from one character set to another. There may be a list of these undesirable characters in AWB's general fixes or somewhere else in a WP cleanup script. – ] (]) 01:26, 2 October 2015 (UTC) | |||
| ::@]: See ]. I don't know what the correct change should be, so it's better to get consensus here. ] (]) 19:38, 19 December 2024 (UTC) | |||
| == Citeref: if no year, use year from date == | |||
| :Basically the "no such character" characters, right? Sounds good. ~ ] (]) 22:16, 2 October 2015 (UTC) | |||
| Citeref is an html ID that is used to connect template:harv and template:sfn to cs1. | |||
| :Are there other {{tq|"no such character" characters}}? What other legitimate characters? ]? ]? What about ]? | |||
| Problem to be solved: | |||
| :—] (]) 00:29, 3 October 2015 (UTC) | |||
| ::I suspect that there is a list of them somewhere, possibly in the AWB source. I have one in line 20 of ] that shows up in copy-pasted DOI values sometimes. You can't see it, but it's there and it causes a DOI validation error. | |||
| An SQL search over linter errors of citerefs ] gives that ], so no year. It does make sense to look if the year can be fetched from elsewhere. CS1 alone makes 1.7 million out of 3.8 million duplicate IDs, so something has to be done, the status quo is not an feasible outcome. | |||
| :::The character in line 20 of your script is the ]. | |||
| Expected breakages: | |||
| :::—] (]) 01:39, 3 October 2015 (UTC) | |||
| https://en.wikipedia.org/search/?search=hastemplate%3A%22Cite+journal%22+hastemplate%3A%22Harvard+citation%22+insource%3A%2F%5C%7B%5C%7Bharvard+citation%5C%7C%5Ba-zA-Z%5C%7C%5D%2B%5C%7D%5C%7D%2F&title=Special:Search&profile=advanced&fulltext=1&ns0=1 shows that among the usages of cite journal and harv there is only one that does not have a number, ] with its reference to Green, but that reference does not have an date, so it will not be affected by the change. Among the usages of cite journal and harv there are none with only page and not date, so nothing expected to break there. Overall, I do expect breakages, but that that they fix more duplicate ID's than they cause issues with harv. One could do an interim solution with both IDs showing up, causing no breakages for harv and sfn in the meantime. | |||
| ::] may provide some guidance. – ] (]) 01:30, 3 October 2015 (UTC) | |||
| Solution: | |||
| :::]? | |||
| It does make sense to look for an year in date, when year is not given. An editor is not likely to duplicate the year when the date has already been given. | |||
| :::—] (]) 01:42, 3 October 2015 (UTC) | |||
| Add the following to line 4115 of Module:Citation/CS1, keeping the line break that is there. | |||
| ::::Here's a possible solution for three of the characters: | |||
| <pre> | |||
| ::::*{{cite book/new |title=Title with � character}} | |||
| if Year == nil or "" then | |||
| ::::*{{cite book/new |title=LoremIpsum with ZWS}} | |||
| Year = string.match(Date, "%d%d%d%d") | |||
| ::::*{{cite book/new |title=MargaretAreYouGrieving with SHY}} | |||
| end | |||
| ::::The test loops through all of the parameters in a template and tests each for all three. If a 'bad' character is found in a parameter, subsequent tests are not performed on that parameter. Is there a better error message? Yes, it needs proper formatting, I'll get to that. | |||
| </pre> ] (]) 15:00, 15 December 2024 (UTC) | |||
| ::::*{{cite book/new |title=MargaretAreYouGrieving with SHY |author=LoremIpsum}} | |||
| ::::—] (]) 12:50, 4 October 2015 (UTC) | |||
| :Having the same CITEREF in articles that do not use short form references is not an error that needs solving. | |||
| ::::Expanded a bit so that the test finds most of the ] and ] characters | |||
| :The year in {{para|date}} is already used if it is part of the cite. However the example in ] (CITEREFGreen) has no {{para|date}} parameter only {{para|access-date}} and {{para|archive-date}} neither of which would be appropriate to include in a short form reference. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 16:35, 15 December 2024 (UTC) | |||
| ::::*<s>{{cite book/new |title=Lorem Ipsum with HT}} – a horizontal tab (might be best to split HT, LF, and CR into separate test)</s> | |||
| :{{ec}} | |||
| ::::*{{cite book/new |title=U+008F between dots ..}} – SS3 (single shift three) | |||
| :No. At ] line 4114 is this: | |||
| ::::*{{cite book/new |title=Lo�rem Ipsum with BEL}} – either Lua or mediawiki replace most C0 controls with the replacement character when the citation is rendered so the test for the replacement character thinks that the string is good. | |||
| ::<syntaxhighlight lang="lua" inline="1">local year = first_set ({Year, anchor_year}, 2); -- Year first for legacy citations and for YMD dates that require disambiguation</syntaxhighlight> | |||
| <s><pre style="margin-left:6.4em">{{cite book/new |title=Margaret | |||
| :Normally, <code>Year</code> has been set to <code>nil</code> before this point in the code. <code>anchor_year</code> comes from ]. | |||
| Are | |||
| : | |||
| You | |||
| :This example has {{para|date}} but does not have {{para|year}}: | |||
| Grieving}}</pre></s> | |||
| ::<syntaxhighlight lang="wikitext" inline="1">{{cite book |title=Title |last=Greene |first=EB |date=15 December 2024}}</syntaxhighlight> → {{cite book |title=Title |last=Greene |first=EB |date=15 December 2024}} | |||
| ::::*<s>{{cite book/new |title=Margaret | |||
| :::{{code|lang=html|{{cite book |title=Title |last=Greene |first=EB |date=15 December 2024}}}} | |||
| Are | |||
| :Note the value assigned to the <code>id=</code> attribute in the {{tag|cite|o}} tag; it has the year portion from {{para|date}}. | |||
| You | |||
| : | |||
| Grieving}} – each word of the title is on a different line</s> | |||
| :If you know of cs1|2 templates that do not include the year portion from a publication-date parameter ({{para|date}}, {{para|publication-date}}, {{para|year}}) in the <code>CITEREF</code> anchor id, I'd like to see it. | |||
| ::::—] (]) 13:17, 5 October 2015 (UTC) | |||
| : | |||
| :::::I don't think there is anything wrong with having tab characters or line breaks in citation parameter text, as long as they do not break the rendered citation. People are used to the idea that white space of various sorts is rendered as a single space, and in this case, it looks to me like a case of "it ain't broke, so don't fix it". – ] (]) 14:09, 5 October 2015 (UTC) | |||
| :Editors do {{tq|duplicate the year when the date has already been given}}; {{cl|CS1 maint: date and year}} wouldn't be needed else. | |||
| ::::::Removed, but I'm not sure that they should be. The undetected and so uncorrected C0 control characters are included in the metadata. Here is the multi-line ''Margaret Are You Grieving'' example: | |||
| : | |||
| :::::::{{code|{{cite book/new |title=Margaret | |||
| :It used to be that cs1 templates did not automagically create <code>CITEREF</code> anchor ids. Some time back, there was discussion: | |||
| Are | |||
| :*{{slink|Help_talk:Citation_Style_1/Archive_46|2=Proposal:_make_ref=harv_the_default_for_CS1}} | |||
| You | |||
| :*{{slink|Help_talk:Citation_Style_1/Archive_66|2=make_ref=harv_the_default_for_CS1}} | |||
| Grieving}}}} | |||
| : Editors in those discussions decided that all cs1|2 templates would create <code>CITEREF</code> anchor ids, needed or not; the automagic <code>CITEREF</code> anchor id can be suppressed with {{para|ref|none}}. This linter thing is an artefact of that decision. | |||
| ::::::Something else has changed. When I first wrote it, the ''Lo�rem Ipsum with BEL'' test above did not render with the replacement character and showed the correct C0 controls error message. Now I can't insert the BEL character (or any other C0 control) without it is replaced. I'll leave the test in the code. | |||
| :—] (]) 17:01, 15 December 2024 (UTC) | |||
| :Sounds like the problem is the linter. We already have {{clc|Category:Harv and Sfn multiple-target errors}} for where this is an actual issue. ] (]) 12:37, 23 December 2024 (UTC) | |||
| ::I have worked on Linter errors daily for over six years, and I am unconvinced that the new "Duplicate ID" tracking is identifying many actual errors that cause problems for readers or editors. I haven't had the energy to push back against it though. I just ignore it. – ] (]) 17:49, 25 December 2024 (UTC) | |||
| == Generic title == | |||
| ::::::—] (]) 12:12, 6 October 2015 (UTC) | |||
| is a generic title string. -- ]] 00:59, 19 December 2024 (UTC) | |||
| == Citing catalogs and similar materials == | |||
| == Cite case causes CS1 errors == | |||
| What would be the best template for a product brochure? It's not really a book, and it's not really a techreport. Maybe I'm splitting hairs, or maybe there's the perfect template for this? ] (]) 11:51, 2 October 2015 (UTC) | |||
| {{tl|Cite case}} maps {{para|court}} to {{para|agency}}, which is no longer supported by {{tl|cite book}} -- see ]. This was brought up at ] a few months ago by @] and @], but I'm bringing it here since this is a better-watched talk page. '''Jay8g''' <small>]•]•]<nowiki />]</small> 04:24, 20 December 2024 (UTC) | |||
| == One cite episode template with multiple errors, none detected == | |||
| :I ] to {{para|series}}, which renders in the same position in the citation. Hopefully no court cases are part of a series. Haven't checked all 52 transclusions, but none of the dozen or so I checked are in ], so it seems fine. No documentation at this template. ] (]) 17:04, 21 December 2024 (UTC) | |||
| I found the following {{tl|cite episode}} template in ]: | |||
| == Placement of "translator"/"page" fields == | |||
| {{cite compare|mode=episode|old=no | title = The Longest Ever Raft Journey | url = http://www.bbc.co.uk/programmes/p01nnrx4 | series = Witness | serieslink = http://www.bbc.co.uk/programmes/p004t1hd | credits = | network = ] | station = ] | airdate = 2014-01-02 | time = 08:50 GMT | minutes = 11}} | |||
| Greetings and felicitations. When "translator" and "page" fields are used together in "Cite journal", it results in this: | |||
| * {{Cite journal |last1=Fujimoto |first1=Yukari |author-link=Yukari Fujimoto |date=2012 |title=Takahashi Macoto: The Origin of Shōjo Manga Style |journal=] |volume=7 |issue=1 |translator=] |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002|isbn=978-0-8166-8049-8}} | |||
| * Both {{para|minutes}} and {{para|time}} are used, but in the documentation and the rendering, they are mutually exclusive. Should we emit a redundant parameter error? | |||
| * The {{para|serieslink}} parameter should contain a wikilink, but it contains a URL, which breaks the rendered value of {{para|series}}. We already emit errors for errors like this in {{para|author-link}}. Should we check this -link parameter as well? – ] (]) 13:47, 2 October 2015 (UTC) | |||
| ISTM that the "translator" field should be followed by a period, or be placed before the volume/issue number fields, or after the pages field. —] (]) 05:48, 20 December 2024 (UTC) | |||
| ::I've added redundant parameter error checking for {{para|time}} and {{para|minutes}}. | |||
| :Yeah, a known flaw but a pain to fix. If we really need to fix it, we should revisit the placement of all rendered parameters. As it is now, the code that orders the cs1|2 template parameters is ugly and confusing. | |||
| : | |||
| :For this particular case, if one follows the doi link to the publisher's website, Oxford Academic identifies "Takahashi Macoto: The Origin of Shōjo Manga Style" as a chapter in the book ''Mechademia 7: Lines of Sight''. It would seem then that {{tlx|cite book}} would be the appropriate template. I don't have access to the source, but Oxford Academic's recommended citation does not include Rachel Thorn (with an 'N'). The recommended citation lists a co-author(?) 'Matt Thorm' (with an 'M'). So, perhaps the correct template looks like this (without {{para|translator}}): | |||
| ::<syntaxhighlight lang="wikitext" inline="1">{{Cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}}</syntaxhighlight> | |||
| :::{{Cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}} | |||
| :or with {{para|translator}}: | |||
| ::<syntaxhighlight lang="wikitext" inline="1">{{Cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |translator=] |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}}</syntaxhighlight> | |||
| :::{{Cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |translator=] |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}} | |||
| :—] (]) 16:44, 20 December 2024 (UTC) | |||
| ::I don't have time right now to reply in full, but '']'' is a journal in the form of a book, and the correct spelling of the particular author's name is ]. —] (]) 20:14, 20 December 2024 (UTC) | |||
| ::I know this is pretty stale (and evidently a pain to fix), but I'd support the eventual, non-urgent relocation of the {{para|translator-''n''*}} parameters to render immediately following {{para|chapter}} / {{para|entry}} if available, or immediately following {{para|title}} otherwise.{{pb}}As someone who has previously worked in translation, I can affirm that there is a reason why publishers may recommend the translator be attributed as coauthor. Unless machine translation is used as a jumping off point, translation is a significant and very personal contribution; it makes sense to credit close to the title. No rush though. ] (]) 17:15, 5 January 2025 (UTC) | |||
| :::That sounds good (logical) to me. And I hope the overhaul of parameters happens sooner rather than later. —] (]) 22:21, 6 January 2025 (UTC) | |||
| == module suite update 28–29 December 2024 == | |||
| ::Also added a wikilink/url check similar to the {{para|author-link}} check to {{para|series-link}}. Should probably add checks for {{para|title-link}} and {{para|episode-link}}. That done, we should probably create a single error message/category pair for these kinds of errors to also include {{para|author-link}}, {{para|editor-link}}, and {{para|translator-link}}. | |||
| I propose to update the cs1|2 module suite over the weekend 28–29 December 2024. Here are the changes: | |||
| ::—] (]) 21:40, 2 October 2015 (UTC) | |||
| :::I agree with expanding this check to all "-link" parameters. I think that a simple "Check |editor-link= value" or "Check |title-link= value" should work as an error message. The current category is called {{cl|CS1 errors: authorlink}}. We could call the replacement category {{cl|CS1 errors: link}}, which is a bit obtuse, or perhaps {{cl|CS1 errors: invalid link}}. Modifying the documentation should be straightforward. – ] (]) 23:49, 2 October 2015 (UTC) | |||
| ::::It should not be marked as any kind of error to supply a valid redlink for one of these parameters. But as long as the error checker is only looking for things that are formatted as urls rather than wikilinks. it should be ok. —] (]) 23:53, 2 October 2015 (UTC) | |||
| :::::As far as I know, no one has ever suggested testing wikilinks for color. The test is looking for wikilink markup in a {{para|<param>-link}} parameter because that extra markup breaks rendering of the link: | |||
| ::::::<code><nowiki>{{cite episode/new |series=Series |series-link=]}}</nowiki></code> | |||
| :::::::{{cite episode/new |series=Series |series-link=]}} | |||
| :::::—] (]) 00:23, 3 October 2015 (UTC) | |||
| ::::::Ok, but that's a different error than the one Jonesey95 was talking about, which involved putting a URL in the link field. Those would look more like redlinks except for the URL syntax. —] (]) 00:30, 3 October 2015 (UTC) | |||
| :::::::I'm confused. In the example at top, the error message is present because the assigned value is a url: | |||
| ::::::::{{para|serieslink|<nowiki>http://www.bbc.co.uk/programmes/p004t1hd</nowiki>}} | |||
| :::::::My example above shows the error because of the wikilink mark up. Both of these are the same as the errors displayed when {{para|author-link}} contains a url or wikilink markup which is, I think, the error that Editor Jonesey95 was talking about, is it not? Is it even possible to get a red external link (without applying special styling)? | |||
| ]: | |||
| :::::::—] (]) 00:48, 3 October 2015 (UTC) | |||
| *convert {{cl|CS1 maint: unfit URL}} to properties cat {{cl|CS1: unfit URL}}; ] | |||
| ::::::::{{U|David Eppstein}}: Nobody is suggesting here that we check for non-existent WP article names in {{para|whatever-link}}. We are simply talking about applying the existing {{para|author-link}} check (for <code><nowiki>//</nowiki></code> and <code><nowiki>]</nowiki></code> ) to other -link parameters. The checking code in question is: <code><nowiki>if is_set(person.link) and ((nil ~= person.link:find("//")) or (nil ~= person.link:find("]")))</nowiki></code> | |||
| ]: | |||
| ::::::::As you can see in my example above (copied from an actual article), the series link is rendered as <code><nowiki>http://www.bbc.co.uk/programmes/p004t1hd|Witness</nowiki></code>, which is clearly not the intent of the original editor. The new test will put these broken links in an error category so that we can fix them and help readers and editors find sources. – ] (]) 02:11, 3 October 2015 (UTC) | |||
| *update emoji zwj table to Unicode v16.0; nothing changed except version and date; | |||
| :::::::::You know we have an article ], right? (Well, it's a dab, but it could be an article.) Also ] and a few dozen redirects . How are we going to link to these after this test is made? —] (]) 04:09, 3 October 2015 (UTC) | |||
| *add script lang codes 'az', 'chr', 'zgh'; | |||
| ::::::::::Link to ] from {{para|editor-link}}? Let's resolve that edge case when it occurs. – ] (]) 13:40, 3 October 2015 (UTC) | |||
| *add free DOI registrants 10.18637 – Foundation for Open Access Statistic, 10.1016/j.proche – Procedia Chemistry | |||
| *convert Category:CS1 maint: unfit URL to properties cat Category:CS1: unfit URL | |||
| *relax 'HugeDomains' generic title search; ] | |||
| ]: | |||
| ::::::::::Percent encoding: | |||
| *fix extended free doi bug; ] | |||
| :::::::::::<code><nowiki>{{cite episode/new |series=// |series-link=:en:%2F%2F}}</nowiki></code> | |||
| *bump 5-digit doi prefix limit; ] | |||
| ::::::::::::{{cite episode/new |series=// |series-link=:en:%2F%2F}} | |||
| ::::::::::—] (]) 19:41, 3 October 2015 (UTC) | |||
| :::::::::::That is a gross hack. Percent encoding has nothing to do with whether something is a valid URL (the same URL with slashes percent-encoded still works equally well) nor whether something is a valid wikilink. Presumably the intended meaning is "this text is unterpreted unusually so I'm going to encode it unusually" but the encoding and the semantics are otherwise unrelated. It amounts to leaving an undocumented back door in the pattern matching code (that it doesn't know how to match patterns in strings when the strings happen to be percent-encoded) with the intention of using that back door when we need to bypass the code, and hoping that some future software maintainer doesn't clean up the code to make it handle strings with different encodings more smoothly. —] (]) 19:57, 3 October 2015 (UTC) | |||
| ::::::::::::Yep, {{tq|this text is nterpreted unusually so I'm going to encode it unusually}}. Not so much different from the requirement to use these replacements in urls: | |||
| {| class="wikitable" style="margin-left: 20.8em" | |||
| ! sp !! " !! ' !! < !! > !! !! { !! <nowiki>|</nowiki> !! } | |||
| |- | |||
| || %20 || %22 || %27 || %3c || %3e || %5b || %5d || %7b || %7c || %7d | |||
| |} | |||
| ::::::::::::I'm all ears. If you have a better solution, tell us. | |||
| ]: | |||
| ::::::::::::—] (]) 11:48, 4 October 2015 (UTC) | |||
| *reworked hyphen_to_dash(); ] | |||
| It occurs to me to wonder if we shouldn't refine the url test to look for a dot somewhere in the ]. MediaWiki is confused by: | |||
| —] (]) 01:57, 21 December 2024 (UTC) | |||
| :<code><nowiki>]</nowiki></code> | |||
| ::] | |||
| so editors must use ] notation: | |||
| :<code><nowiki>]</nowiki></code> | |||
| ::] | |||
| To ] <code><nowiki>en://hus</nowiki></code> looks like a valid url (though MediaWiki sees that it isn't): | |||
| :<code><nowiki>{{cite book |title=Title |url=en://hus}}</nowiki></code> | |||
| ::{{cite book |title=Title |url=en://hus}} | |||
| ] in ] (192.168.0.0) and ]s (example.com) are ]s with dots. ] syntax is different and (at the moment) I can find no use of it as a link in en:wp. Looking for the dot that separates IPv4 elements or domain-name labels will identify and flag {{para|url|en://hus}} as malformed. Looking for the dot will not identify {{para|title-link|en://hus}} as an error. Looking for the dot is no help when {{para|title-link|//hus}}; MediaWiki will still be confused. | |||
| —] (]) |
:I don't have an opinion on most of these but am very happy to see the hyphen-to-dash fix. Thanks! —] (]) 06:01, 21 December 2024 (UTC) | ||
| : | |||
| : Instead of {{cl|CS1: unfit URL}} could it be {{cl|CS1: usurped URL}} - it is the majority by about 3:1: , . The usurped will grow indef due to ]. -- ]] 06:21, 21 December 2024 (UTC) | |||
| ::Makes sense just to reparent the existing cat: {{code|usurped}} is a subtype of {{code|unfit}}. Thanks for all your work, Trappist. ] (]) 16:46, 21 December 2024 (UTC) | |||
| :::Just so I understand what you are saying: You think that {{para|url-status|unfit}} should categorize to {{cl|CS1: unfit URL}} and {{para|url-status|usurped}} should categorize to {{cl|CS1: usurped URL}} where the latter is a sub-category of the former? Do we really need two categories? | |||
| :::—] (]) 19:10, 21 December 2024 (UTC) | |||
| ::::"Is a sub-type of unfit" .. ? Unfit are individual URLs that are a problem in an otherwise legitimate website/domain. Usurped are URLs for an entire websites/domains. They are tracking similar problem URLs but of different scope. I agree it works to have one category, but thought the category placeholder name could be the larger more common set. Usurped is now up to and I forecast this number will be 100s k if not millions, dwarfing unfit. -- ]] 20:06, 1 January 2025 (UTC) | |||
| :I forgot to mention that some time ago I implemented a prospective work-around for the {{error-small|Lua error in Module:Citation/CS1/Configuration at line 2083: attempt to index a boolean value}} messages. These messages occur when the attempt to fetch ID limits from Commons (]) fails. When the fetch fails, ] will use default limit values of 99999999999 so that individual limit tests will not fail. Articles where this happens will be added to {{cl|CS1 maint: ID limit load fail}}. Unlike all other maintenance categories, this category will not emit the maintenance message because it would appear in every cs1|2 template rendered in the article. A null edit should remove an article from the category. It is nearly impossible to test this code because the load failure is rare and random but, famous last words, I believe that I haven't done anything too stupid. | |||
| :—] (]) 15:32, 27 December 2024 (UTC) | |||
| ::I've added the cat to list of things to watch. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 15:43, 27 December 2024 (UTC) | |||
| == Another generic title: "Conference Paper" == | |||
| :<code><nowiki>{{cite book/new |title=Title |url=en://hus}}</nowiki></code> | |||
| ::{{cite book/new |title=Title |url=en://hus}} | |||
| :and a variety of other conditions: | |||
| ::{{cite book/new |title=pass protocol relative with dot |url=//example.com}} | |||
| ::{{cite book/new |title=fail protocol relative without dot |url=//examplecom}} | |||
| ::{{cite book/new |title=fail path only with dot |url=/example.com}} | |||
| ::{{cite book/new |title=fail labels only with dot |url=example.com}} | |||
| ::{{cite book/new |title=pass scheme; hostname with dot |url=http://example.com}} | |||
| ::{{cite book/new |title=fail scheme; hostname without dot |url=http://examplecom}} | |||
| ::{{cite book/new |title=fail bad scheme; hostname with dot |url=8ttp://example.com}} | |||
| :If this change is to be kept, it will be necessary to change the error message. | |||
| :—] (]) |
See ] —] (]) 05:32, 24 December 2024 (UTC) | ||
| ::These look like reasonable tests. How about "check url= value" for an error message? That matches some of our other error messages. – ] (]) 21:25, 6 October 2015 (UTC) | |||
| == certain parameters not displaying on ']' == | |||
| I've created a new function that does this: | |||
| #checks {{para|<param>-link}} for illegal article title characters per ] | |||
| #looks for text that precedes a colon that could be a scheme | |||
| #looks for text that could be a protocol relative url | |||
| #inspects what should be the hostname for character or digit, dot, character or digit | |||
| For some reason, {{tl|cite map}} seems to have the following issues below: | |||
| See Editor Jonesy95's example. Here are others using {{para|author-link}} (same code as {{para|series-link}}): | |||
| :{{cite book/new |title=Pass, proper usage |author=Abraham Lincoln |author-link=Abraham Lincoln}} – expected use | |||
| :{{cite book/new |title=Fail, wikilinked |author=Abraham Lincoln |author-link=]}} | |||
| :{{cite book/new |title=Fail, attempt to ext-wikilink to author's website |author=Abraham Lincoln |author-link=}} | |||
| :{{cite book/new |title=Fail, attempt to use plain url with scheme and author name |author=Abraham Lincoln |author-link=http://www.abrahamlincoln.com Abraham Lincoln}} | |||
| :{{cite book/new |title=Fail, attempt to use author name and plain url with scheme |author=Abraham Lincoln |author-link=Abraham Lincoln's website http://www.abrahamlincoln.com}} | |||
| :{{cite book/new |title=Fail, attempt to use plain url with scheme |author=Abraham Lincoln |author-link=http://www.abrahamlincoln.com}} | |||
| :{{cite book/new |title=Fail, attempt to use protocol relative url |author=Abraham Lincoln |author-link=http://www.abrahamlincoln.com}} | |||
| :{{cite book/new |title=Fail, link to //hus |author=Abraham Lincoln |author-link=//hus}} | |||
| :{{cite book/new |title=Pass, link to en://hus |author=Abraham Lincoln |author-link=en://hus}} | |||
| {{cite compare |template=map |comment=In this first instance, the parameter {{param|volume}} isn't being shown after {{param|others}}, unlike in the other instances, and neither is {{param|issue}}, while {{param|title}} is displayed in ''italics'', the latter two issues, like in the third instance. |header=(with 'title' parameter, without 'map' or 'website' parameters) |last=Bloggs |first=Joe |author-link=Joe Bloggs |date={{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} |editor-last=Doe |editor-first=John |editor-link=John Doe |title=title |url=https://www.example.com/ |format=format |type=type |edition=57 |others=others |volume=52 |issue=38}} | |||
| Still to do is {{para|title-link}} and {{para|episode-link}}. All of these should share the same error message and category so I'll think about that as well. | |||
| {{cite compare |template=map |comment=In this second instance, the parameter {{param|edition}} isn't being shown at all, either after {{param|type}}, unlike in the first instance, or after {{param|format}}, unlike in the third or fourth instances, while the parameter {{param|title}} is displayed in "quotation marks", like in the fourth instance. |header=(with 'title' and 'website' parameters, without 'map' parameter) |last=Bloggs |first=Joe |author-link=Joe Bloggs |date={{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} |editor-last=Doe |editor-first=John |editor-link=John Doe |title=title |url=https://www.example.com/ |format=format |type=type |edition=57 |website=website |others=others |volume=52 |issue=38}} | |||
| —] (]) 23:42, 6 October 2015 (UTC) | |||
| {{cite compare |template=map |comment=In this third instance, the parameter {{param|issue}} isn't being shown, while {{param|title}} is displayed in ''italics'', both like in the first instance. |header=(with 'map' and 'title' parameters, without 'website' parameter) |last=Bloggs |first=Joe |author-link=Joe Bloggs |date={{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} |map=map |map-url=https://www.example.com/map/ |type=type |editor-last=Doe |editor-first=John |editor-link=John Doe |title=title |url=https://www.example.com/ |format=format |edition=57 |others=others |volume=52 |issue=38}} | |||
| {{para|title-link}} and {{para|episode-link}} tests added. All of the {{para|<param>-link}} parameters are now using a common error message and handler. If this change is retained we will need to move {{cl|CS1 errors: authorlink}} to {{cl|CS1 errors: parameter-link}}. Similarly, ] help text gets a new anchor, title, and expanded text. | |||
| {{cite compare |template=map |comment=In this fourth instance, the parameter {{param|website}} isn't being shown, unlike in the second instance, while {{param|title}} is displayed in "quotation marks", like in the second instance. |header=(with 'map', 'title' and 'website' parameters) |last=Bloggs |first=Joe |author-link=Joe Bloggs |date={{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} |map=map |map-url=https://www.example.com/map/ |type=type |editor-last=Doe |editor-first=John |editor-link=John Doe |title=title |url=https://www.example.com/ |format=format |website=website |edition=57 |others=others |volume=52 |issue=38}} ] (]; ]) 08:46, 26 December 2024 (UTC) | |||
| {{para|title-link}}: | |||
| :Not really 'issues'. All of your examples are correct except for the fourth example: | |||
| :{{cite book/new |title=Pass, proper usage |title-link=Abraham Lincoln}} | |||
| :# cites a standalone or sheet map; {{para|volume}} and {{para|issue}} are inappropriate | |||
| :{{cite book/new |title=fail, wikilinked |title-link=]}} | |||
| :# cites a map in a periodical; the periodical parameters are: {{para|journal}}, {{para|magazine}}, {{para|newspaper}}, {{para|periodical}}, {{para|website}}, {{para|work}}; {{para|edition}} is ignored in the final assembly process | |||
| {{para|title-link}} in {{tlx|cite encyclopedia}}: | |||
| :# cites a map in a book or encyclopedia; cs1|2 book and encyclopedia citations do not support {{para|issue}} (a periodical parameter) | |||
| :{{cite encyclopedia/new |title=Pass, proper usage |title-link=Abraham Lincoln |encyclopedia=Encyclopedia}} | |||
| :# doesn't know what you're citing because you included {{para|map}}, {{para|title}}, and {{para|website}} which is an attempt to cite a map in a book and simultaneously in a periodical; don't do that. | |||
| :{{cite encyclopedia/new |title=fail, wikilinked |title-link=] |encyclopedia=Encyclopedia}} | |||
| :Cast about in the archives of this talk page for the discussions we had when developing the current version of {{tlx|cite map}}. | |||
| {{para|episode-link}} in {{tlx|cite episode}}: | |||
| :—] (]) 15:02, 26 December 2024 (UTC) | |||
| :{{cite episode/new |title=Pass, proper usage |episode-link=Abraham Lincoln |series=Series}} | |||
| :: I accidentally said the word {{'}}''italics''{{'}} instead of {{'}}"quotation marks"{{'}} for the fourth instance above in {{tl|cite map}} when I started this discussion; I just replaced that instance of the word 'italics' with 'quotation marks' now. -- ] (]; ]) 05:32, 27 December 2024 (UTC) | |||
| :{{cite episode/new |title=fail, wikilinked |episode-link=] |series=Series}} | |||
| {{para|editor-link}} and {{para|translator-link}}: | |||
| :{{cite book/new |title=Fail, wikilinked |editor=Sam Houston |editor2=Abraham Lincoln |editor-link2=]}} | |||
| :{{cite book/new |title=Fail, wikilinked |translator=Abraham Lincoln |translator-link=]}} | |||
| —] (]) 15:29, 7 October 2015 (UTC) | |||
| ::Nice work. These all look good to me. Here's one with multiple link errors (editor-link and translator-link) and a missing editor, just to be cruel: | |||
| :::{{cite book/new |title=Fail, wikilinked |editor2=Abraham Lincoln |editor-link2=]| |translator=Mary Todd Lincoln |translator-link=]}} | |||
| ::It shows all three errors, with the very minor problem that the editor error message says that there is an error in {{para|editor-link1}} instead of {{para|editor-link2}} because the first editor is missing. – ] (]) 19:23, 7 October 2015 (UTC) | |||
| :::fixed. | |||
| == Reformat dates v2 == | |||
| :::—] (]) 19:59, 7 October 2015 (UTC) | |||
| Previous: ]<br> | |||
| == Referencing foreign language programs with English captions to be CS1 compliant == | |||
| Hi! I'm trying to find a variable that would allow me to display all dates (we use a bot to convert them into ISO format) using <code>formatDate</code>: https://ru.wikipedia.org/search/?diff=142375001&oldid=141847966. Can you tell me what I'm doing wrong and where it needs to be corrected? ] (]) 17:42, 29 December 2024 (UTC) | |||
| :What you mean by {{tq|variable that would allow me to display all dates}}. | |||
| : | |||
| :You {{tq|use a bot to convert them into ISO format}}. Does that mean that your bot converts all wikitext dates to {{tq|ISO format}} so that cs1|2 never sees anything but ISO format dates? Even date ranges? (YYYY-MM-DD/YYYY-MM-DD) Seasons? Named dates (Christmas, Easter, etc)? What about dates outside of the Gregorian calendar? | |||
| : | |||
| :At ] you use <code>formatDate()</code> to format the value returned from <code>reformatter()</code> (called from either ] or ]). At ] you use <code>formatDate()</code> to format the date that was just formatted at line 1002. Why? | |||
| : | |||
| :Do you have an example sandbox somewhere that shows what you want and what you're getting? | |||
| :—] (]) 18:37, 29 December 2024 (UTC) | |||
| ::{{tq|1=What you mean by variable that would allow me to display all dates.}}<br>I mean the variable that is returned in AccessDate, ArchiveDate and Date in ].{{pb}}{{tq|1=Does that mean that your bot converts all wikitext dates to <q>ISO format</q> so that cs1{{!}}2 never sees anything but ISO format dates?}}<br>So far only English and Russian dates supported by Citoid. Perhaps in the future we will try to convert all Russian and English dates, and another languages. <br>I thought to use additionally your date converter to convert maximum number of dates to iso (by using <syntaxhighlight lang="lua" inline>global_df = 'ymd-all',</syntaxhighlight>), and then pass what is obtained through the <code>formatDate()</code>. And if the <code>formatDate()</code> displays an error, then display your output without <code>formatDate()</code>.{{pb}}{{tq|1=At ] you use <code>formatDate()</code> to format the value returned from <code>reformatter()</code> (called from either ] or ]). At ] you use <code>formatDate()</code> to format the date that was just formatted at line 1002. Why?}}<br>I was trying to figure out how it works.{{pb}}{{tq|1=Do you have an example sandbox somewhere that shows what you want and what you're getting?}}<br>] - first table. {{pb}}I am currently using a local module to convert dates, but I don't like the location where I am using it.<br>https://ru.wikipedia.org/search/?title=Module:Citation/CS1&action=edit (line 436) ] (]) 19:00, 29 December 2024 (UTC) | |||
| :::The first three testcases ({{para|access-date|2001-01-14}}, {{para|access-date|January 14, 2001}}, {{para|access-date|14 January 2001}}) are not modified because those dates are invalid – there cannot be an access date that precedes the creation of Misplaced Pages. The last testcase is also invalid because that date exists in the future (day after tomorrow). | |||
| ::: | |||
| :::When <code>reformatter()</code> returns <syntaxhighlight lang="lua" inline="1">mw.language.new( 'ru' ):formatDate( 'j xg Y', new_date );</syntaxhighlight>, two testcases, {{para|access-date|January 15, 2001}} and {{para|access-date|15 January 2001}}, both return 15 января 2001. | |||
| ::: | |||
| :::The remaining testcases ({{para|access-date|2001-01-15}}, {{para|access-date|2024-12-30}} – today's date, {{para|access-date|2024-12-30}} – tomorrow's date) return their inputs because you specify <syntaxhighlight lang="lua" inline>global_df = 'ymd-all',</syntaxhighlight>. The code at ] terminates the conversion because converting ymd to ymd is a pointless waste of processor cycles. I added a test at line 932: | |||
| ::::<syntaxhighlight lang="lua"> if 'ymd' == format_param and 'ymd' == pattern_idx then -- special case for ru.wiki | |||
| return mw.language.new( 'ru' ):formatDate( 'j xg Y', date ); -- convert ymd to dMy | |||
| end | |||
| </syntaxhighlight> | |||
| :::With that code in place, the remaining tests return 15 января 2001, 30 декабря 2024, and 31 декабря 2024. | |||
| :::—] (]) 16:35, 30 December 2024 (UTC) | |||
| ::::Yeah! Thanks, it works, but I have some problems with dates without day.<br>].<br>If the date parameter is specified without a day, the conversion through formatDate does not occur. However, if it is specified in the archival date or access date, all dates break. ] (]) 19:46, 30 December 2024 (UTC) | |||
| :::::{{para|access-date}} and {{para|archive-date}} must include day, month, and year – the dates are meaningless else. | |||
| ::::: | |||
| :::::It is pointless to convert ym dates to ymd dates. Add this: | |||
| ::::::<syntaxhighlight lang="lua"> if 'ymd' == format_param and 'ym' == pattern_idx then -- special case for ru.wiki | |||
| return mw.language.new( 'ru' ):formatDate( 'xg Y', date ); -- convert ym to My | |||
| end | |||
| </syntaxhighlight> | |||
| :::::change the sequence in the first <code>if</code> in <code>reformatter()</code> to include <code>'ym', </code>. | |||
| ::::: | |||
| :::::You still need to add the call to <code>formatDate()</code> at the end of <code>reformatter()</code>. Without you do that, the 5th and 6th test_access_dates tests at ] do not convert. | |||
| :::::—] (]) 15:02, 31 December 2024 (UTC) | |||
| ::::::It works! Thanks! :) ] (]) 15:58, 31 December 2024 (UTC) | |||
| :Consider the | |||
| :<code><nowiki>{{cite journal/песочница |title=Title |journal=Journal |date=23–29 February 1700}}</nowiki></code> | |||
| :Leaving aside whether all the functions used can handle the date 29 February 1700. The correct result needs careful inspection because no real journal is specified, therefore it's unknown whether the journal used the Gregorian or Julian calendar until we examine the date. But the date 29 February 1700 tells us it must be a Julian date because 1700 was not a leap year in the Gregorian calendar. Since it is a Julian calendar, the choices are to keep the date in the original format, or change it to the corresponding Gregorian ISO 8601-1-2019 date range: | |||
| ::1700-03-05/03-11 | |||
| :] (]) 17:11, 31 December 2024 (UTC) | |||
| ::I agree with you, but as long as the core MediaWiki functions do not support date ranges and other mechanisms, I prefer not to use them in templates :)<br>]<br>] ] (]) 17:23, 31 December 2024 (UTC) | |||
| == OCLC parameter now needs to allow 11 digits. == | |||
| In referencing television episodes, I sometimes have to deal with cases where the episode is dubbed in a non-English language but presented with captions in English, but putting "language=Japanese with English subtitles" raises a problem with CS1. What would be the CS1-confirming way to describe that? "language=Japanese, English"? This would be for cases where the caption presented is important to the reference. Similarly what if I want to reference a program in which the English caption presented is different from the English that is said? This assumes the captions are pre-loaded for the broadcast and not transcribed on the fly. ] (] • ]) 18:15, 4 October 2015 (UTC) | |||
| During a preview on ] I ran into this: | |||
| :{{para|language}} is used for categorization so extraneous text confuses ]. {{para|language}} merely indicates which languages a source uses, not how they are used. As to which language should come first in your example, {{para|language}} doesn't care so it is up to you to decide whether you emphasize one language over the other by the order in which they appear in the rendered citation. You might consider {{para|type}} to point to the subtitles: | |||
| *<code><nowiki>{{cite journal |last1=Milona |first1=Michael |last2=Weindling |first2=Lauren |title=The Story of Romantic Love and Polyamory |journal=] |date=2024 |doi=10.1111/japp.12764 |doi-access=free |issn=0264-3758 |oclc=10395234777}}</nowiki></code> produces: | |||
| ::<code><nowiki>{{cite episode |title=Title |series=Series |language=en, ja |type=subtitles}}</nowiki></code> | |||
| *:{{cite journal |last1=Milona |first1=Michael |last2=Weindling |first2=Lauren |title=The Story of Romantic Love and Polyamory |journal=] |date=2024 |doi=10.1111/japp.12764 |doi-access=free |issn=0264-3758 |oclc=10395234777}} | |||
| :::{{cite episode |title=Title |series=Series |language=en, ja |type=subtitles}} | |||
| :This gave this error: <code>{{!xt|{{}}]{{!xt|<nowiki>}}: Check </nowiki>}}{{!xt|<nowiki>|oclc=</nowiki>}}</code> {{!xt|value (}}]{{!xt|)}} | |||
| *{{tl|OCLC}} works fine. <code><nowiki>{{OCLC|10395234777}}</nowiki></code> produces: | |||
| *:{{OCLC|10395234777}} | |||
| Click through on that 11-digit OCLC # to see that it links to a WorldCat record. ] (]) 22:10, 29 December 2024 (UTC) | |||
| == language parameter is not recognising languages == | |||
| :For the case where closed captioning is different from the spoken word: find a better source? Inaccurate transcriptions of the spoken word are inaccurate; they are the result of an editorial process gone awry either by omission or commission. Where this occurs, perhaps the best course is to use {{para|quote}} to include both an accurate transcription of the audio and an accurate transcription of the closed caption. Or find a better source. | |||
| The language parameter is not recognising languages includes ] and ] by their iso code.––]<sup>(])(])</sup> 11:18, 4 January 2025 (UTC) | |||
| :—] (]) 11:48, 6 October 2015 (UTC) | |||
| :None of the language tags are supported by MediaWiki: | |||
| :*Nagpuri (Sadri) <code>sck</code>: <syntaxhighlight lang="wikitext" inline="1">{{#language:sck|en}}</syntaxhighlight> → {{#language:sck|en}} | |||
| :*Nagpuri (Oraon Sadri) <code>sdr</code>: <syntaxhighlight lang="wikitext" inline="1">{{#language:sdr|en}}</syntaxhighlight> → {{#language:sdr|en}} | |||
| :*Kharia <code>khr</code>: <syntaxhighlight lang="wikitext" inline="1">{{#language:khr|en}}</syntaxhighlight> → {{#language:khr|en}} | |||
| :See the documentation for {{para|]}} and, in particular, ]. | |||
| :—] (]) 12:38, 4 January 2025 (UTC) | |||
| ::Is there any way to get such languages included.––]<sup>(])(])</sup> 12:48, 4 January 2025 (UTC) | |||
| == Module support edit req == | |||
| == |subscription= and |registration= font size tweak == | |||
| {{Edit protected|level=full|Module:Citation/CS1|answered=yes}} | |||
| The rendered versions of {{para|subscription}} and {{para|registration}} use css copied directly from {{tlx|link note}}: | |||
| I would like to have the following code added to ] - ]. This was previously discussed at ] without any convincing arguments against it. This adds support for modules to call the module directly, instead of using metatables or templates. ] is one of the usecases. The "citation" function was renamed to "_citation", and a new "citation" function made. The "_citation" function would be the entry point for any module, and that module calling it would have to provide the same information as the "citation" function provides. This _x and x naming scheme is consistent with other modules providing access from other modules. Any frame dependant functionality was moved to the "citation" function. Only 4 tests failed at ]. ] (]) 13:03, 4 January 2025 (UTC) | |||
| :{{tag|span|params=style="font-size:0.95em; font-size: 90%; color: #555"|o}} | |||
| :That ] did not, it seems, generate enthusiastic support either. From that discussion, are we to infer that you mean to replace ] (and the others) with a single module that then calls the ] function <code>_citation()</code> with the appropriate arguments? Have you written that replacement module? Where can we see it working? | |||
| I have changed that to: | |||
| : | |||
| :{{tag|span|params=style="font-size: 90%; color: #555"|o}} | |||
| :Not clear to me that ] would benefit from this change. What am I missing? | |||
| compare: | |||
| :—] (]) 14:35, 4 January 2025 (UTC) | |||
| :{{cite book |title=Title |subscription=yes}} | |||
| ::The modules and what parameters they support are distinct on purpose. This is a feature, not a bug.  <span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 16:42, 4 January 2025 (UTC) | |||
| :{{cite book/new |title=Title |subscription=yes}} | |||
| :I unequivocally support adding module access to this module. I have looked at it many times and have not been able to figure it out, so kudos to someone for taking a hack at it. ] (]) 21:32, 4 January 2025 (UTC) | |||
| :{{cite book |title=Title |registration=yes}} | |||
| ::I have a criticism though. The templatestyles should be in _citation. If you need to get another frame inside there that's fine. ] (]) 21:37, 4 January 2025 (UTC) | |||
| :{{cite book/new |title=Title |registration=yes}} | |||
| ::And actually, I think all the <code>lookups</code> should be in _citation. ] (]) 21:37, 4 January 2025 (UTC) | |||
| :::Concur. I've moved all that stuff into <code>_citation()</code>. Not yet tested calls from another module. | |||
| :::—] (]) 01:03, 5 January 2025 (UTC) | |||
| :I have hacked a proof of concept module in ] that appears to demonstrate that ] can be called from another module. The first three examples were scraped from elsewhere on this page, live template rendering above the sandbox rendering: | |||
| ::<syntaxhighlight lang="wikitext" inline="1">{{cite journal|date=2016|doi=10.70460/jpa.v7i1.183|first=Ian J|issue=1|journal=Journal of Pacific Archaeology|last=McNiven|pages=74–83|title=Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea|volume=7}}</syntaxhighlight> | |||
| ::*{{cite journal|date=2016|doi=10.70460/jpa.v7i1.183|first=Ian J|issue=1|journal=Journal of Pacific Archaeology|last=McNiven|pages=74–83|title=Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea|volume=7}} | |||
| ::*{{#invoke:Sandbox/trappist the monk/cite|cite|journal|date=2016|doi=10.70460/jpa.v7i1.183|first=Ian J|issue=1|journal=Journal of Pacific Archaeology|last=McNiven|pages=74–83|title=Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea|volume=7}} | |||
| ::<syntaxhighlight lang="wikitext" inline="1">{{cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |translator=] |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}}</syntaxhighlight> | |||
| ::*{{cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |translator=] |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}} | |||
| ::*{{#invoke:Sandbox/trappist the monk/cite|cite|book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |translator=] |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}} | |||
| ::<syntaxhighlight lang="wikitext" inline="1">{{cite map|author-link=Joe Bloggs|date=5 January 2025|edition=57|editor-first=John|editor-last=Doe|editor-link=John Doe|first=Joe|format=format|issue=38|last=Bloggs|others=others|title=title|type=type|url=https://www.example.com/|volume=52|website=website}}</syntaxhighlight> | |||
| ::*{{cite map|author-link=Joe Bloggs|date=5 January 2025|edition=57|editor-first=John|editor-last=Doe|editor-link=John Doe|first=Joe|format=format|issue=38|last=Bloggs|others=others|title=title|type=type|url=https://www.example.com/|volume=52|website=website}} | |||
| ::*{{#invoke:Sandbox/trappist the monk/cite|cite|map|author-link=Joe Bloggs|date=5 January 2025|edition=57|editor-first=John|editor-last=Doe|editor-link=John Doe|first=Joe|format=format|issue=38|last=Bloggs|others=others|title=title|type=type|url=https://www.example.com/|volume=52|website=website}} | |||
| :For most cs1|2 templates, the {{para|CitationClass}} parameter is set to the lowercase version of the canonical template name. There are six for which that is not true; {{tlx|cite encyclopedia}} sets {{para|CitationClass|encyclopaedia}}: | |||
| ::<syntaxhighlight lang="wikitext" inline="1">{{cite encyclopedia |last=Seberg |first=Ole |editor1-last=Heywood |editor1-first=Vernon H. |editor2-last=Brummitt |editor2-first=Richard K. |editor3-last=Culham |editor3-first=Alastair |title=Alliaceae |encyclopedia=Flowering Plant Families of the World |url={{google books |plainurl=y |id=Jy1FAQAAIAAJ|page=340}}|date=2007 |publisher=Firefly Books |location=Richmond Hill, Ontario |isbn=978-1-55407-206-4 |pages=340–341}}</syntaxhighlight> | |||
| ::*{{cite encyclopedia |last=Seberg |first=Ole |editor1-last=Heywood |editor1-first=Vernon H. |editor2-last=Brummitt |editor2-first=Richard K. |editor3-last=Culham |editor3-first=Alastair |title=Alliaceae |encyclopedia=Flowering Plant Families of the World |url={{google books |plainurl=y |id=Jy1FAQAAIAAJ|page=340}}|date=2007 |publisher=Firefly Books |location=Richmond Hill, Ontario |isbn=978-1-55407-206-4 |pages=340–341}} | |||
| ::*{{#invoke:Sandbox/trappist the monk/cite|cite|encyclopedia |last=Seberg |first=Ole |editor1-last=Heywood |editor1-first=Vernon H. |editor2-last=Brummitt |editor2-first=Richard K. |editor3-last=Culham |editor3-first=Alastair |title=Alliaceae |encyclopedia=Flowering Plant Families of the World |url={{google books |plainurl=y |id=Jy1FAQAAIAAJ|page=340}}|date=2007 |publisher=Firefly Books |location=Richmond Hill, Ontario |isbn=978-1-55407-206-4 |pages=340–341}} | |||
| :Conveniently, should we decide to implement this as a replacement for ] and the others, ] is currently available. | |||
| :—] (]) 19:49, 5 January 2025 (UTC) | |||
| == Requested move 4 January 2025 == | |||
| == Strange rendering of invalid access-date= parameter == | |||
| {{requested move/dated|multiple=yes | |||
| I found a citation similar to this one out in the wild. I have simplified it a bit: | |||
| |current1=Template:cite AV media|new1=Template:cite audiovisual media|current2=Template:cite AV media notes|new2=Template:cite audiovisual media notes|current3=Template:cite tech report|new3=Template:cite technical report|protected=Template:Cite AV media notes|}} | |||
| * ] → {{no redirect|Template:cite audiovisual media}} | |||
| {{cite compare|mode=web|old=no|accessdate=7 October2015|url=http://www.example.com|title=title|language=Danish|website=indenforvoldene.dk}} | |||
| * ] → {{no redirect|Template:cite audiovisual media notes}} | |||
| * ] → {{no redirect|Template:cite technical report}} | |||
| – The reason I'm requesting for these templates to be moved to their respective new titles is per ]; because template function should be clear from the template name, but redirects can be created to assist everyday use of very popular templates, because ]. ] (]; ]) 23:50, 4 January 2025 (UTC) | |||
| :References are used often and inline, which makes them noisy. These are some of the longer names. I would not support a move of any of the above. ] (]) 01:35, 5 January 2025 (UTC) | |||
| I see "Retrieved $1 $2" in the rendered citation where the access-date parameter is supposed to be. I wonder if that is a bug that will manifest itself even with valid dates. When the date is corrected, it looks fine: | |||
| ::The problem with the "redirects are cheap" argument is that redirected templates often lead to gnomes or bots replacing the templates with the redirect target (despite ]) and this leads to a lot of clutter on everyone's watchlists, and the resulting waste of human editors' attention is not so cheap. —] (]) 01:39, 5 January 2025 (UTC) | |||
| *'''Oppose''' per the arguments of Izno and David. -- ] (]) 01:58, 5 January 2025 (UTC) | |||
| :I'm unconvinced by the argument for this. I've never seen a confused misuse of {{tl|Cite AV media}}. I don't see that it's purpose is unclear. On the other hand I've seen {{tl|Cite journal}} used several times for people's diaries, but even that is an extremely rare issue. As other have said this will just result in the longer title being used, creating clutter for no practical effect. -- <small>LCU</small> ''']''' <small>''«]» °]°''</small> 13:42, 5 January 2025 (UTC) | |||
| {{cite compare|mode=web|old=no|accessdate=7 October 2015|url=http://www.example.com|title=title|language=Danish|website=indenforvoldene.dk}} | |||
| *'''Oppose''' for ''AV'', don't care on ''tech''.  <span style="font-variant:small-caps; whitespace:nowrap;">] {] · ] · ] · ]}</span> 16:00, 5 January 2025 (UTC) | |||
| *'''Oppose''' per {{noping|David Eppstein}} and {{noping|ActivelyDisinterested}}. Redirects are cheap until someone decides they all need to be bypassed, which people often choose to do en masse for some reason. And it's not clear how "AV media" could be confused for anything but "audio-visual media". I legitimately checked for possible confounders and came up empty.{{pb}}{{small|As an aside, I have also seen {{tl|Cite journal}} to cite a diary, but the more common cases of confusion – in steeply ascending order – are people trying to use {{tl|Cite document}} inappropriately to cite an online source, because it's a "document" (as if any written material isn't), and ] swapping in an incorrect template because it sees an isbn or something.}}{{pb}}{{tl|Cite tech report}} → {{tl|Cite technical report}} is less objectionable, but still seems undesirable. Again, what do people think "tech report" might mean apart from "technical report"? (I suppose "technology report" or "technique report" might be theoretically possible.) Good faith request, but unconvincing, and neglects drawbacks. ] (]) 17:00, 5 January 2025 (UTC) | |||
| *'''Oppose''' for the AV templates, I think there is a good argument that AV is more obvious than audiovisual. '''Meh''' on tech to technical. ] (]) 02:46, 6 January 2025 (UTC) | |||
| == Generic name == | |||
| Any thoughts? – ] (]) 05:22, 8 October 2015 (UTC) | |||
| I'm aware of Reuters and CNN as authors when I see citations in ]. ] (]) 23:13, 6 January 2025 (UTC) | |||
| :<code>nowrap_date()</code> had mismatched <code>%s*%d%d%d%d</code> and <code>%s+%d%d%d%d</code> patterns; one doesn't care if there are spaces preceding the year value and the other does. Now they both care. The problem also manifests when {{para|access-date}} is mdy: | |||
| {{cite compare|mode=web|old=no|accessdate=October 7,2015|url=http://www.example.com|title=title|language=Danish|website=indenforvoldene.dk}} | |||
| :—] (]) 10:09, 8 October 2015 (UTC) | |||
Latest revision as of 11:46, 7 January 2025
| This is the talk page for discussing improvements to the Help:Citation Style 1 and the CS1 templates page. |
|
Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97Auto-archiving period: 20 days  |
 | To help centralize discussions and keep related topics together, the talk pages for all Citation Style 1 and Citation Style 2 templates and modules redirect here. A list of those talk pages and their historical archives can be found here. |
 | This help page does not require a rating on Misplaced Pages's content assessment scale. It is of interest to multiple WikiProjects. | |||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||
 | Other talk page banners | |||
| ||||
 view · edit Frequently asked questions
|
Internet archive print disability book links
There are a number of links to books which have since lost their accessibility to the general public on Internet Archive (e.g., and of the same book). These are now " available to patrons with print disabilities."
Should the links like these which are not accessible to users without print disabilities be removed, or would it be possible to add another |url-access parameter to signify this? Tule-hog (talk) 20:48, 28 November 2024 (UTC)
- Alternatively (as with
{{Hopcroft and Ullman 1979}}) should the link be appended to a reference a note? Tule-hog (talk) 01:33, 29 November 2024 (UTC)- @Tule-hog: I don't think any of the values in the current current scheme accurately represent the access status you have described. I'd be inclined to leave
|url-access=blank and create a new template to indicate this information after the citation template, similar to many of the templates in Category:External link note templates. Daask (talk) 17:06, 16 December 2024 (UTC)- I went with
{{Internet Archive patrons}}as a temporary solution, which allows for tracking pages (and ref-templates) that use it (which should make future modifications more streamline-able). Tule-hog (talk) 17:14, 16 December 2024 (UTC)- User:Tule-hog, the book is fully searchable (click the magnifying glass). And, you can open it to any page like page 42. This is the same as many books at Google Books. I would be careful about tagging books as "inaccessible" because there are many levels and types of access, beyond complete full access. We certainly don't tag Google Books. Also, access levels can change on a whim of the library based on publisher requirements, it's not set in stone, trying to maintain those tags over the years will be impossible. It's really beyond our scope or need. Readers are expected to be able to navigate and understand external websites. -- GreenC 00:24, 17 December 2024 (UTC)
- That particular book is not fully browsable, click 'next page'.
- To clarify: are you in favor of deprecating
url-accessentirely, or are you making a point about Internet Archive's collections? Tule-hog (talk) 00:39, 17 December 2024 (UTC)- "Fully browsable" is a rare condition for (copyright) books, at any website. At Internet Archive, for example, permissions can include:
- Full access for everyone
- Full access if you login
- Full access if you are disabled
- Some book pages browsable for everyone
- Some book pages browsable if you login
- Search access for everyone but not browsable
- Search access if you login but not browsable
- There are other permissions controlling access to files
- Also, these permissions can, and frequently do, change at the whim of Internet Archive and the publishers, at any time. Including new types of permissions.
- So my question is how you plan on communicating AND maintaining this information on Misplaced Pages for the next 20 years for millions of books.
- Also, this is only one website. Google Books has similar gradations, is even more complex, and more opaque how it works. For these reasons we don't track the precise levels of access. It's generally understood that any copyright material is by default probably going to have some restrictions. It's a matter of practicality. -- GreenC 02:50, 17 December 2024 (UTC)
- Thank you for the clarification. Given that the current possibilities are:
- registration = 'Free registration required'
- limited = 'Free access subject to limited trial, subscription normally required'
- subscription = 'Paid subscription required'
- do you think it would be unreasonable to collapse the tertiary possibilities discussed (e.g., search access only, some pages browsable, special permissions) into a fourth parameter:
- partial = 'Partial access, not fully readable' (or something)
- The motivation for the parameter is the same as the other 3, with no more or less difficulty in implementation. In particular, it is to emphasize that the URL supplied is not "full access", in one way or another. Tule-hog (talk) 00:21, 5 January 2025 (UTC)
- If the proposed fourth parameter is not reasonable, I will collapse the use of
{{IAp}}to a simple|url=with no indicator. As a reader, I would find an indicator an appreciated convenience, but I don't see another solution. Tule-hog (talk) 00:22, 5 January 2025 (UTC)
- If the proposed fourth parameter is not reasonable, I will collapse the use of
- Thank you for the clarification. Given that the current possibilities are:
- "Fully browsable" is a rare condition for (copyright) books, at any website. At Internet Archive, for example, permissions can include:
- User:Tule-hog, the book is fully searchable (click the magnifying glass). And, you can open it to any page like page 42. This is the same as many books at Google Books. I would be careful about tagging books as "inaccessible" because there are many levels and types of access, beyond complete full access. We certainly don't tag Google Books. Also, access levels can change on a whim of the library based on publisher requirements, it's not set in stone, trying to maintain those tags over the years will be impossible. It's really beyond our scope or need. Readers are expected to be able to navigate and understand external websites. -- GreenC 00:24, 17 December 2024 (UTC)
- I went with
- @Tule-hog: I don't think any of the values in the current current scheme accurately represent the access status you have described. I'd be inclined to leave
DOI prefix limits should be bumped.
We have DOI prefixes in the 10.70000s now. The limit should be bumped to 10.80000s Headbomb {t · c · p · b} 04:05, 1 December 2024 (UTC)
- Seconding this! —Collin 22:10, 17 December 2024 (UTC)
- If that is true, why (as I write this) is Category:CS1 errors: DOI empty?
{{PAGESINCATEGORY:CS1 errors: DOI}}→ 0
- —Trappist the monk (talk) 22:47, 17 December 2024 (UTC)
- @Trappist the monk: The article Kiwai Island has a DOI of 10.70460/jpa.v7i1.183 in reference #1 that is incorrectly giving a "
Check |doi= value" error. Could you please help fix this? GoingBatty (talk) 19:41, 19 December 2024 (UTC)
- @Trappist the monk: The article Kiwai Island has a DOI of 10.70460/jpa.v7i1.183 in reference #1 that is incorrectly giving a "
- Fixed in sandbox:
| Wikitext | {{cite journal
|
|---|---|
| Live | McNiven, Ian J (2016). "Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea". Journal of Pacific Archaeology. 7 (1): 74–83. doi:10.70460/jpa.v7i1.183. |
| Sandbox | McNiven, Ian J (2016). "Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea". Journal of Pacific Archaeology. 7 (1): 74–83. doi:10.70460/jpa.v7i1.183. |
- —Trappist the monk (talk) 20:06, 19 December 2024 (UTC)
- Thank you! After this goes live, we could update the articles in Category:CS1 maint: ignored DOI errors. GoingBatty (talk) 17:31, 26 December 2024 (UTC)
- I reviewed each article in Category:CS1 maint: ignored DOI errors and removed the temporary error hiding for the 10.7#### DOIs that were kindly added by users such as Metamd, AManWithNoPlan and Snowman304. GoingBatty (talk) 20:55, 2 January 2025 (UTC)
- Thank you! After this goes live, we could update the articles in Category:CS1 maint: ignored DOI errors. GoingBatty (talk) 17:31, 26 December 2024 (UTC)
cite episode id parameter silently ignored
{{cite episode}} currently silently ignores |id=. I have been using it to add IMDb identifiers to some items, eg. Special:Diff/1261220079 using {{IMDb ID}}. I propose that we display the |id= parameter just like most other CS1 templates. A more elaborate discussion of IMDb in particular as an identifier is at Misplaced Pages talk:IMDb link templates § IMDB as an identifier in citations. Daask (talk) 22:44, 4 December 2024 (UTC)
|id=was:- initially supported at this edit 25 May 2009
- reverted at this edit 7 August 2009
- updated to use Template:Citation/core and simultaneously usurped as a vehicle to support
|network=and|station=at this edit 2 April 2012
- Because it was the goal of the wikitext-to-module conversion to be transparent, it was necessary to overwrite whatever might be assigned to
|id=. I do not recall any discussion here suggesting that we should change that. - I am not enthusiastic about making a change just to support an identifier for a source that editors at WP:RS/P have determined to be generally unreliable.
- —Trappist the monk (talk) 00:20, 5 December 2024 (UTC)
- I've commented at the other discussion, there's general agreement that IMDb should not appear in references. I don't see how a courtesy link to an unreliable source can help with verification. -- LCU ActivelyDisinterested «@» °∆t° 01:16, 5 December 2024 (UTC)
- I apologize for the delay in responding. Gonnym removed all transclusions of Template:IMDb ID two days after I raised the question here, making it difficult for me to determine how the template had been used. I strongly disagree with Gonnym's claim that these uses of Template:IMDb ID were "not what the ID= is for". It's exactly what
|id=is for. Our current guideline is strong on this topic: Misplaced Pages:Citing sources § Links and ID numbers says "A citation ideally includes a link or ID number to help editors locate the source.
" Thus, according to this content guideline, for these audiovisual materials where no link is suitable, some identifier should be included. I don't make a point of adding identifiers of this kind to citations generally, and I'm not sure I would advocate for the strength of that guideline's wording, but I believe that identifiers are beneficial to include for obscure content, such as old episodes of broadcast news. Contra ActivelyDisinterested, an identifier is not a convenience link. - This leads to the question of which identifier to use. Contra Trappist the monk, I don't think it matters whether IMDb is a reliable source. It matters whether its identifiers are ambiguous by being either underspecified or conflations. IMDb's primary benefit isn't the quality of its data or it's market share as Folly Mox suggests, but the breadth of its coverage. Other websites besides IMDb itself use its identifiers. If other identifiers were available, I would prefer to use them, but for items with no other identifier, we must use what we have.
- For example, I think this citation (featuring a permanently dead link with no archives available) would be greatly benefited from the addition of an identifier from IMDb or anywhere else:
- Mansbridge, Peter (host); Zaccardelli, Guiliano (guest) (September 3, 2008). "Zaccardelli - On Maher Arar". The National. CBC News.
{{cite episode}}: CS1 maint: url-status (link)
- Mansbridge, Peter (host); Zaccardelli, Guiliano (guest) (September 3, 2008). "Zaccardelli - On Maher Arar". The National. CBC News.
- I can't find anything about this episode on the internet except https://www.cbc.ca/news/canada/zaccardelli-faults-u-s-government-for-arar-s-deportation-1.757351 .
- Perhaps a better solution than linking to IMDb would be to link to Wikidata using {{QID}}. Wikidata's primary web interface isn't very navigable for readers, so perhaps a link target of Reasonator (eg.) or SQID (eg.)? Forcing editors who want to add identifiers to create a Wikidata item linked to IMDb instead of using IMDb directly is more work for editors, which you may or may not find desirable. Searching revealed no existing policy or RFCs on using Wikidata an identifier in citations. Daask (talk) 02:04, 24 December 2024 (UTC)
- The us of Wikidata on Misplaced Pages still has to comply with the consensus on Misplaced Pages. So using Wikidata to obfuscate a link to IMDb in a reference when there is a consensus against using IMDb in references sounds like a bad idea. -- LCU ActivelyDisinterested «@» °∆t° 10:52, 24 December 2024 (UTC)
- @ActivelyDisinterested: I wouldn't call this obfuscating a link to IMDb. As far as consensus on Misplaced Pages, we have a content guideline that requires the use of an identifier. That's as strong a consensus as it gets on Misplaced Pages. If this local consensus wants to argue against the use of IMDb as a identifier, I may be willing to accept that if Wikidata is preferred instead. At this local venue, we don't have the option of overruling a content guideline, and so may not forbid both IMDb and Wikidata. Daask (talk) 15:11, 24 December 2024 (UTC)
- The us of Wikidata on Misplaced Pages still has to comply with the consensus on Misplaced Pages. So using Wikidata to obfuscate a link to IMDb in a reference when there is a consensus against using IMDb in references sounds like a bad idea. -- LCU ActivelyDisinterested «@» °∆t° 10:52, 24 December 2024 (UTC)
- I apologize for the delay in responding. Gonnym removed all transclusions of Template:IMDb ID two days after I raised the question here, making it difficult for me to determine how the template had been used. I strongly disagree with Gonnym's claim that these uses of Template:IMDb ID were "not what the ID= is for". It's exactly what
- The guideline doesn't require the use of an identifier, and certainly not these proposed identifiers. Nikkimaria (talk) 15:14, 24 December 2024 (UTC)
- No there is a strong general consensus across multiple discussions to not link IMDb in references, working out ways to circumvent that consensus is unadvisable.
- Also the guideline also doesn't agree with your interpretation. It doesn't say that an ID is required, it says ideally an ID can be included if it helps locate the source - IMDb doesn't help in locating the source. Even if it did require such a link that still wouldn't support your point, as it doesn't say that link must be to IMDb. -- LCU ActivelyDisinterested «@» °∆t° 15:29, 24 December 2024 (UTC)
- I think it does matter that IMdB is not a reliable source, and expect most editors would agree. Out of curiosity, is the IMDb page on the episode given as example here (which I could not find) any more informative than the CBC archive summary, which also includes a "shotlist" element allowing for verification of certain quotes? Does the IMDb page truly help editors locate the source, or is it a user-generated summary of the source? (Incidentally, there is an archive, but Internet Archive are unable to display it, possibly as a result of their recent lawsuit.) Folly Mox (talk) 13:25, 24 December 2024 (UTC)
- @Folly Mox: Thank you for finding those archives! I was unable to do so despite significant effort, and obviously could learn a thing or two about finding them. I would regard the CBC archive summary as essentially the official website for the source, though not a manifestation of the source, and would certainly link to it.
- I don't expect identifiers to be informative. Is an ISBN informative? An ISBN is a number, not a resolver, a database, or a source. Daask (talk) 15:39, 24 December 2024 (UTC)
Request to edit note at top of Category:CS1 maint: unflagged free DOI
Hi there! Could someone please update the note at the top of Category:CS1 maint: unflagged free DOI? It mentions an issue affecting 17 Misplaced Pages articles, but there are now less than 10 articles in the category. Thanks! GoingBatty (talk) 17:45, 8 December 2024 (UTC)
- See WP:BOLD. Also, I wonder why it dropped from 17. There hasn't been a template update in ages... I suspect someone performed bad fixes just to avoid the categorization. Headbomb {t · c · p · b} 12:15, 10 December 2024 (UTC)
- @Headbomb: See WP:BOLD#Be careful. I don't know what the correct change should be, so it's better to get consensus here. GoingBatty (talk) 19:38, 19 December 2024 (UTC)
Citeref: if no year, use year from date
Citeref is an html ID that is used to connect template:harv and template:sfn to cs1.
Problem to be solved:
An SQL search over linter errors of citerefs with the same id gives that around 280k do not have any number, so no year. It does make sense to look if the year can be fetched from elsewhere. CS1 alone makes 1.7 million out of 3.8 million duplicate IDs, so something has to be done, the status quo is not an feasible outcome.
Expected breakages:
https://en.wikipedia.org/search/?search=hastemplate%3A%22Cite+journal%22+hastemplate%3A%22Harvard+citation%22+insource%3A%2F%5C%7B%5C%7Bharvard+citation%5C%7C%5Ba-zA-Z%5C%7C%5D%2B%5C%7D%5C%7D%2F&title=Special:Search&profile=advanced&fulltext=1&ns0=1 shows that among the usages of cite journal and harv there is only one that does not have a number, Gordon Pask with its reference to Green, but that reference does not have an date, so it will not be affected by the change. Among the usages of cite journal and harv there are none with only page and not date, so nothing expected to break there. Overall, I do expect breakages, but that that they fix more duplicate ID's than they cause issues with harv. One could do an interim solution with both IDs showing up, causing no breakages for harv and sfn in the meantime.
Solution:
It does make sense to look for an year in date, when year is not given. An editor is not likely to duplicate the year when the date has already been given.
Add the following to line 4115 of Module:Citation/CS1, keeping the line break that is there.
if Year == nil or "" then Year = string.match(Date, "%d%d%d%d") end
Snævar (talk) 15:00, 15 December 2024 (UTC)
- Having the same CITEREF in articles that do not use short form references is not an error that needs solving.
- The year in
|date=is already used if it is part of the cite. However the example in Gordon Peak (CITEREFGreen) has no|date=parameter only|access-date=and|archive-date=neither of which would be appropriate to include in a short form reference. -- LCU ActivelyDisinterested «@» °∆t° 16:35, 15 December 2024 (UTC) - (edit conflict)
- No. At Module:Citation/CS1 line 4114 is this:
local year = first_set ({Year, anchor_year}, 2); -- Year first for legacy citations and for YMD dates that require disambiguation
- Normally,
Yearhas been set tonilbefore this point in the code.anchor_yearcomes from Module:Citation/CS1/Date validation. - This example has
|date=but does not have|year=:{{cite book |title=Title |last=Greene |first=EB |date=15 December 2024}}→ Greene, EB (15 December 2024). Title.'"`UNIQ--templatestyles-0000003C-QINU`"'<cite id="CITEREFGreene2024" class="citation book cs1">Greene, EB (15 December 2024). ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=Title&rft.date=2024-12-15&rft.aulast=Greene&rft.aufirst=EB&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1" class="Z3988"></span>
- Note the value assigned to the
id=attribute in the<cite>tag; it has the year portion from|date=. - If you know of cs1|2 templates that do not include the year portion from a publication-date parameter (
|date=,|publication-date=,|year=) in theCITEREFanchor id, I'd like to see it. - Editors do
duplicate the year when the date has already been given
; Category:CS1 maint: date and year wouldn't be needed else. - It used to be that cs1 templates did not automagically create
CITEREFanchor ids. Some time back, there was discussion: - Editors in those discussions decided that all cs1|2 templates would create
CITEREFanchor ids, needed or not; the automagicCITEREFanchor id can be suppressed with|ref=none. This linter thing is an artefact of that decision. - —Trappist the monk (talk) 17:01, 15 December 2024 (UTC)
- Sounds like the problem is the linter. We already have Category:Harv and Sfn multiple-target errors (11) for where this is an actual issue. Folly Mox (talk) 12:37, 23 December 2024 (UTC)
- I have worked on Linter errors daily for over six years, and I am unconvinced that the new "Duplicate ID" tracking is identifying many actual errors that cause problems for readers or editors. I haven't had the energy to push back against it though. I just ignore it. – Jonesey95 (talk) 17:49, 25 December 2024 (UTC)
Generic title
Registered & Protected by MarkMonitor is a generic title string. -- GreenC 00:59, 19 December 2024 (UTC)
Cite case causes CS1 errors
{{Cite case}} maps |court= to |agency=, which is no longer supported by {{cite book}} -- see MKUltra#cite_note-107. This was brought up at Template talk:Cite case a few months ago by @DocWatson42 and @Isaidnoway, but I'm bringing it here since this is a better-watched talk page. Jay8g 04:24, 20 December 2024 (UTC)
- I remapped it to
|series=, which renders in the same position in the citation. Hopefully no court cases are part of a series. Haven't checked all 52 transclusions, but none of the dozen or so I checked are in Category:Pages using duplicate arguments in template calls, so it seems fine. No documentation at this template. Folly Mox (talk) 17:04, 21 December 2024 (UTC)
Placement of "translator"/"page" fields
Greetings and felicitations. When "translator" and "page" fields are used together in "Cite journal", it results in this:
- Fujimoto, Yukari (2012). "Takahashi Macoto: The Origin of Shōjo Manga Style". Mechademia. 7 (1). Translated by Thorn, Rachel: 24–55. doi:10.5749/minnesota/9780816680498.003.0002. ISBN 978-0-8166-8049-8.
ISTM that the "translator" field should be followed by a period, or be placed before the volume/issue number fields, or after the pages field. —DocWatson42 (talk) 05:48, 20 December 2024 (UTC)
- Yeah, a known flaw but a pain to fix. If we really need to fix it, we should revisit the placement of all rendered parameters. As it is now, the code that orders the cs1|2 template parameters is ugly and confusing.
- For this particular case, if one follows the doi link to the publisher's website, Oxford Academic identifies "Takahashi Macoto: The Origin of Shōjo Manga Style" as a chapter in the book Mechademia 7: Lines of Sight. It would seem then that
{{cite book}}would be the appropriate template. I don't have access to the source, but Oxford Academic's recommended citation does not include Rachel Thorn (with an 'N'). The recommended citation lists a co-author(?) 'Matt Thorm' (with an 'M'). So, perhaps the correct template looks like this (without|translator=):{{Cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}}- Fujimoto, Yukari; Thorm, Matt (2012). "Takahashi Macoto: The Origin of Shōjo Manga Style". In Lunning, Frenchy (ed.). Mechademia 7: Lines of Sight. pp. 24–55. doi:10.5749/minnesota/9780816680498.003.0002. ISBN 978-0-8166-8049-8.
- or with
|translator=:{{Cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |translator=] |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}}- Fujimoto, Yukari; Thorm, Matt (2012). "Takahashi Macoto: The Origin of Shōjo Manga Style". In Lunning, Frenchy (ed.). Mechademia 7: Lines of Sight. Translated by Thorn, Rachel. pp. 24–55. doi:10.5749/minnesota/9780816680498.003.0002. ISBN 978-0-8166-8049-8.
- —Trappist the monk (talk) 16:44, 20 December 2024 (UTC)
- I don't have time right now to reply in full, but Mechademia is a journal in the form of a book, and the correct spelling of the particular author's name is Matt Thorn. —DocWatson42 (talk) 20:14, 20 December 2024 (UTC)
- I know this is pretty stale (and evidently a pain to fix), but I'd support the eventual, non-urgent relocation of the
|translator-n*=parameters to render immediately following|chapter=/|entry=if available, or immediately following|title=otherwise.As someone who has previously worked in translation, I can affirm that there is a reason why publishers may recommend the translator be attributed as coauthor. Unless machine translation is used as a jumping off point, translation is a significant and very personal contribution; it makes sense to credit close to the title. No rush though. Folly Mox (talk) 17:15, 5 January 2025 (UTC)- That sounds good (logical) to me. And I hope the overhaul of parameters happens sooner rather than later. —DocWatson42 (talk) 22:21, 6 January 2025 (UTC)
module suite update 28–29 December 2024
I propose to update the cs1|2 module suite over the weekend 28–29 December 2024. Here are the changes:
- convert Category:CS1 maint: unfit URL to properties cat Category:CS1: unfit URL; discussion
Module:Citation/CS1/Configuration:
- update emoji zwj table to Unicode v16.0; nothing changed except version and date;
- add script lang codes 'az', 'chr', 'zgh';
- add free DOI registrants 10.18637 – Foundation for Open Access Statistic, 10.1016/j.proche – Procedia Chemistry
- convert Category:CS1 maint: unfit URL to properties cat Category:CS1: unfit URL
- relax 'HugeDomains' generic title search; discussion
Module:Citation/CS1/Identifiers:
- fix extended free doi bug; discussion
- bump 5-digit doi prefix limit; discussion
Module:Citation/CS1/Utilities:
- reworked hyphen_to_dash(); discussion
—Trappist the monk (talk) 01:57, 21 December 2024 (UTC)
- I don't have an opinion on most of these but am very happy to see the hyphen-to-dash fix. Thanks! —David Eppstein (talk) 06:01, 21 December 2024 (UTC)
- Instead of Category:CS1: unfit URL could it be Category:CS1: usurped URL - it is the majority by about 3:1: unfit 11,000, usurped 46,000. The usurped will grow indef due to WP:JUDI. -- GreenC 06:21, 21 December 2024 (UTC)
- Makes sense just to reparent the existing cat:
usurpedis a subtype ofunfit. Thanks for all your work, Trappist. Folly Mox (talk) 16:46, 21 December 2024 (UTC)- Just so I understand what you are saying: You think that
|url-status=unfitshould categorize to Category:CS1: unfit URL and|url-status=usurpedshould categorize to Category:CS1: usurped URL where the latter is a sub-category of the former? Do we really need two categories? - —Trappist the monk (talk) 19:10, 21 December 2024 (UTC)
- "Is a sub-type of unfit" .. ? Unfit are individual URLs that are a problem in an otherwise legitimate website/domain. Usurped are URLs for an entire websites/domains. They are tracking similar problem URLs but of different scope. I agree it works to have one category, but thought the category placeholder name could be the larger more common set. Usurped is now up to 55,000 and I forecast this number will be 100s k if not millions, dwarfing unfit. -- GreenC 20:06, 1 January 2025 (UTC)
- Just so I understand what you are saying: You think that
- Makes sense just to reparent the existing cat:
- I forgot to mention that some time ago I implemented a prospective work-around for the Lua error in Module:Citation/CS1/Configuration at line 2083: attempt to index a boolean value messages. These messages occur when the attempt to fetch ID limits from Commons (c:Data:CS1/Identifier limits.tab) fails. When the fetch fails, Module:Citation/CS1/Configuration will use default limit values of 99999999999 so that individual limit tests will not fail. Articles where this happens will be added to Category:CS1 maint: ID limit load fail. Unlike all other maintenance categories, this category will not emit the maintenance message because it would appear in every cs1|2 template rendered in the article. A null edit should remove an article from the category. It is nearly impossible to test this code because the load failure is rare and random but, famous last words, I believe that I haven't done anything too stupid.
- —Trappist the monk (talk) 15:32, 27 December 2024 (UTC)
- I've added the cat to list of things to watch. -- LCU ActivelyDisinterested «@» °∆t° 15:43, 27 December 2024 (UTC)
Another generic title: "Conference Paper"
See Special:Diff/1264743625 —David Eppstein (talk) 05:32, 24 December 2024 (UTC)
certain parameters not displaying on 'Template:cite map'
For some reason, {{cite map}} seems to have the following issues below:
| Wikitext | {{cite map
|
|---|---|
| Live | Bloggs, Joe (7 January 2025). Doe, John (ed.). title (format) (type) (57 ed.). others. |
| Sandbox | Bloggs, Joe (7 January 2025). Doe, John (ed.). title (format) (type) (57 ed.). others. |
In this first instance, the parameter {{{volume}}} isn't being shown after {{{others}}}, unlike in the other instances, and neither is {{{issue}}}, while {{{title}}} is displayed in italics, the latter two issues, like in the third instance.
| |
| Wikitext | {{cite map
|
|---|---|
| Live | Bloggs, Joe (7 January 2025). Doe, John (ed.). "title" (format) (type). website. others. Vol. 52, no. 38. |
| Sandbox | Bloggs, Joe (7 January 2025). Doe, John (ed.). "title" (format) (type). website. others. Vol. 52, no. 38. |
In this second instance, the parameter {{{edition}}} isn't being shown at all, either after {{{type}}}, unlike in the first instance, or after {{{format}}}, unlike in the third or fourth instances, while the parameter {{{title}}} is displayed in "quotation marks", like in the fourth instance.
| |
| Wikitext | {{cite map
|
|---|---|
| Live | Bloggs, Joe (7 January 2025). "map" (type). In Doe, John (ed.). title (format) (57 ed.). others. Vol. 52. |
| Sandbox | Bloggs, Joe (7 January 2025). "map" (type). In Doe, John (ed.). title (format) (57 ed.). others. Vol. 52. |
In this third instance, the parameter {{{issue}}} isn't being shown, while {{{title}}} is displayed in italics, both like in the first instance.
| |
| Wikitext | {{cite map
|
|---|---|
| Live | Bloggs, Joe (7 January 2025). "map" (type). In Doe, John (ed.). "title" (format) (57 ed.). others. Vol. 52, no. 38. |
| Sandbox | Bloggs, Joe (7 January 2025). "map" (type). In Doe, John (ed.). "title" (format) (57 ed.). others. Vol. 52, no. 38. |
In this fourth instance, the parameter {{{website}}} isn't being shown, unlike in the second instance, while {{{title}}} is displayed in "quotation marks", like in the second instance.
| |
PK2 (talk; contributions) 08:46, 26 December 2024 (UTC)
- Not really 'issues'. All of your examples are correct except for the fourth example:
- cites a standalone or sheet map;
|volume=and|issue=are inappropriate - cites a map in a periodical; the periodical parameters are:
|journal=,|magazine=,|newspaper=,|periodical=,|website=,|work=;|edition=is ignored in the final assembly process - cites a map in a book or encyclopedia; cs1|2 book and encyclopedia citations do not support
|issue=(a periodical parameter) - doesn't know what you're citing because you included
|map=,|title=, and|website=which is an attempt to cite a map in a book and simultaneously in a periodical; don't do that.
- cites a standalone or sheet map;
- Cast about in the archives of this talk page for the discussions we had when developing the current version of
{{cite map}}. - —Trappist the monk (talk) 15:02, 26 December 2024 (UTC)
- I accidentally said the word 'italics' instead of '"quotation marks"' for the fourth instance above in {{cite map}} when I started this discussion; I just replaced that instance of the word 'italics' with 'quotation marks' now. -- PK2 (talk; contributions) 05:32, 27 December 2024 (UTC)
Reformat dates v2
Previous: Help talk:Citation Style 1/Archive 97#'Reformat dates' function
Hi! I'm trying to find a variable that would allow me to display all dates (we use a bot to convert them into ISO format) using formatDate: https://ru.wikipedia.org/search/?diff=142375001&oldid=141847966. Can you tell me what I'm doing wrong and where it needs to be corrected? Iniquity (talk) 17:42, 29 December 2024 (UTC)
- What you mean by
variable that would allow me to display all dates
. - You
use a bot to convert them into ISO format
. Does that mean that your bot converts all wikitext dates toISO format
so that cs1|2 never sees anything but ISO format dates? Even date ranges? (YYYY-MM-DD/YYYY-MM-DD) Seasons? Named dates (Christmas, Easter, etc)? What about dates outside of the Gregorian calendar? - At line 1002 you use
formatDate()to format the value returned fromreformatter()(called from either line 1060 or line 1062). At line 1066 you useformatDate()to format the date that was just formatted at line 1002. Why? - Do you have an example sandbox somewhere that shows what you want and what you're getting?
- —Trappist the monk (talk) 18:37, 29 December 2024 (UTC)
What you mean by variable that would allow me to display all dates.
I mean the variable that is returned in AccessDate, ArchiveDate and Date in Module:Citation/CS1.Does that mean that your bot converts all wikitext dates to
ISO format
so that cs1|2 never sees anything but ISO format dates?
So far only English and Russian dates supported by Citoid. Perhaps in the future we will try to convert all Russian and English dates, and another languages.
I thought to use additionally your date converter to convert maximum number of dates to iso (by usingglobal_df = 'ymd-all',), and then pass what is obtained through theformatDate(). And if theformatDate()displays an error, then display your output withoutformatDate().At line 1002 you use
formatDate()to format the value returned fromreformatter()(called from either line 1060 or line 1062). At line 1066 you useformatDate()to format the date that was just formatted at line 1002. Why?
I was trying to figure out how it works.Do you have an example sandbox somewhere that shows what you want and what you're getting?
ru:Обсуждение модуля:Citation/CS1/testcases/dates - first table. I am currently using a local module to convert dates, but I don't like the location where I am using it.
https://ru.wikipedia.org/search/?title=Module:Citation/CS1&action=edit (line 436) Iniquity (talk) 19:00, 29 December 2024 (UTC)- The first three testcases (
|access-date=2001-01-14,|access-date=January 14, 2001,|access-date=14 January 2001) are not modified because those dates are invalid – there cannot be an access date that precedes the creation of Misplaced Pages. The last testcase is also invalid because that date exists in the future (day after tomorrow). - When
reformatter()returnsmw.language.new( 'ru' ):formatDate( 'j xg Y', new_date );, two testcases,|access-date=January 15, 2001and|access-date=15 January 2001, both return 15 января 2001. - The remaining testcases (
|access-date=2001-01-15,|access-date=2024-12-30– today's date,|access-date=2024-12-30– tomorrow's date) return their inputs because you specifyglobal_df = 'ymd-all',. The code at lines 933–935 terminates the conversion because converting ymd to ymd is a pointless waste of processor cycles. I added a test at line 932:if 'ymd' == format_param and 'ymd' == pattern_idx then -- special case for ru.wiki return mw.language.new( 'ru' ):formatDate( 'j xg Y', date ); -- convert ymd to dMy end
- With that code in place, the remaining tests return 15 января 2001, 30 декабря 2024, and 31 декабря 2024.
- —Trappist the monk (talk) 16:35, 30 December 2024 (UTC)
- Yeah! Thanks, it works, but I have some problems with dates without day.
ru:User:Iniquity/dates.
If the date parameter is specified without a day, the conversion through formatDate does not occur. However, if it is specified in the archival date or access date, all dates break. Iniquity (talk) 19:46, 30 December 2024 (UTC)|access-date=and|archive-date=must include day, month, and year – the dates are meaningless else.- It is pointless to convert ym dates to ymd dates. Add this:
if 'ymd' == format_param and 'ym' == pattern_idx then -- special case for ru.wiki return mw.language.new( 'ru' ):formatDate( 'xg Y', date ); -- convert ym to My end
- change the sequence in the first
ifinreformatter()to include'ym',. - You still need to add the call to
formatDate()at the end ofreformatter(). Without you do that, the 5th and 6th test_access_dates tests at ru:Обсуждение модуля:Citation/CS1/testcases/dates do not convert. - —Trappist the monk (talk) 15:02, 31 December 2024 (UTC)
- It works! Thanks! :) Iniquity (talk) 15:58, 31 December 2024 (UTC)
- Yeah! Thanks, it works, but I have some problems with dates without day.
- The first three testcases (
- Consider the testcase
{{cite journal/песочница |title=Title |journal=Journal |date=23–29 February 1700}}- Leaving aside whether all the functions used can handle the date 29 February 1700. The correct result needs careful inspection because no real journal is specified, therefore it's unknown whether the journal used the Gregorian or Julian calendar until we examine the date. But the date 29 February 1700 tells us it must be a Julian date because 1700 was not a leap year in the Gregorian calendar. Since it is a Julian calendar, the choices are to keep the date in the original format, or change it to the corresponding Gregorian ISO 8601-1-2019 date range:
- 1700-03-05/03-11
- Jc3s5h (talk) 17:11, 31 December 2024 (UTC)
- I agree with you, but as long as the core MediaWiki functions do not support date ranges and other mechanisms, I prefer not to use them in templates :)
phab:T381313
meta:Community Wishlist/Wishes/Support for ISO, EDTF or IETF Date Standards in MediaWiki Parser Functions Iniquity (talk) 17:23, 31 December 2024 (UTC)
- I agree with you, but as long as the core MediaWiki functions do not support date ranges and other mechanisms, I prefer not to use them in templates :)
OCLC parameter now needs to allow 11 digits.
During a preview on Polyamory I ran into this:
{{cite journal |last1=Milona |first1=Michael |last2=Weindling |first2=Lauren |title=The Story of Romantic Love and Polyamory |journal=] |date=2024 |doi=10.1111/japp.12764 |doi-access=free |issn=0264-3758 |oclc=10395234777}}produces:- Milona, Michael; Weindling, Lauren (2024). "The Story of Romantic Love and Polyamory". Journal of Applied Philosophy. doi:10.1111/japp.12764. ISSN 0264-3758. OCLC 10395234777.
- This gave this error:
{{cite journal}}: Check |oclc=value (help)
- {{OCLC}} works fine.
{{OCLC|10395234777}}produces:
Click through on that 11-digit OCLC # to see that it links to a WorldCat record. Peaceray (talk) 22:10, 29 December 2024 (UTC)
language parameter is not recognising languages
The language parameter is not recognising languages includes Nagpuri language and Kharia language by their iso code.––kemel49 11:18, 4 January 2025 (UTC)
- None of the language tags are supported by MediaWiki:
- Nagpuri (Sadri)
sck:{{#language:sck|en}}→ sck - Nagpuri (Oraon Sadri)
sdr:{{#language:sdr|en}}→ sdr - Kharia
khr:{{#language:khr|en}}→ khr
- Nagpuri (Sadri)
- See the documentation for
|language=and, in particular, the list of supported codes and names. - —Trappist the monk (talk) 12:38, 4 January 2025 (UTC)
- Is there any way to get such languages included.––kemel49 12:48, 4 January 2025 (UTC)
Module support edit req
 | This edit request to Module:Citation/CS1 has been answered. Set the |answered= or |ans= parameter to no to reactivate your request. |
I would like to have the following code added to Module:Citation/CS1 - DIFF. This was previously discussed at Help talk:Citation Style 1/Archive 94#Module access without any convincing arguments against it. This adds support for modules to call the module directly, instead of using metatables or templates. Module:CS1 translator is one of the usecases. The "citation" function was renamed to "_citation", and a new "citation" function made. The "_citation" function would be the entry point for any module, and that module calling it would have to provide the same information as the "citation" function provides. This _x and x naming scheme is consistent with other modules providing access from other modules. Any frame dependant functionality was moved to the "citation" function. Only 4 tests failed at Module talk:Citation/CS1/testcases. Snævar (talk) 13:03, 4 January 2025 (UTC)
- That previous discussion did not, it seems, generate enthusiastic support either. From that discussion, are we to infer that you mean to replace Module:Cite book (and the others) with a single module that then calls the Module:Citation/CS1 function
_citation()with the appropriate arguments? Have you written that replacement module? Where can we see it working? - Not clear to me that Module:CS1 translator would benefit from this change. What am I missing?
- —Trappist the monk (talk) 14:35, 4 January 2025 (UTC)
- I unequivocally support adding module access to this module. I have looked at it many times and have not been able to figure it out, so kudos to someone for taking a hack at it. Izno (talk) 21:32, 4 January 2025 (UTC)
- I have a criticism though. The templatestyles should be in _citation. If you need to get another frame inside there that's fine. Izno (talk) 21:37, 4 January 2025 (UTC)
- And actually, I think all the
lookupsshould be in _citation. Izno (talk) 21:37, 4 January 2025 (UTC)- Concur. I've moved all that stuff into
_citation(). Not yet tested calls from another module. - —Trappist the monk (talk) 01:03, 5 January 2025 (UTC)
- Concur. I've moved all that stuff into
- I have hacked a proof of concept module in my sandbox that appears to demonstrate that Module:Citation/CS1/sandbox can be called from another module. The first three examples were scraped from elsewhere on this page, live template rendering above the sandbox rendering:
{{cite journal|date=2016|doi=10.70460/jpa.v7i1.183|first=Ian J|issue=1|journal=Journal of Pacific Archaeology|last=McNiven|pages=74–83|title=Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea|volume=7}}- McNiven, Ian J (2016). "Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea". Journal of Pacific Archaeology. 7 (1): 74–83. doi:10.70460/jpa.v7i1.183.
- McNiven, Ian J (2016). "Stone Axes as Grave Markers on Kiwai Island Fly River Delta Papua New Guinea". Journal of Pacific Archaeology. 7 (1): 74–83. doi:10.70460/jpa.v7i1.183.
{{cite book |last=Fujimoto |first=Yukari |author-link=Yukari Fujimoto |last2=Thorm |first2=Matt |date=2012 |chapter=Takahashi Macoto: The Origin of Shōjo Manga Style |editor-last=Lunning |editor-first=Frenchy |title=Mechademia 7: Lines of Sight |translator=] |pages=24–55 |doi=10.5749/minnesota/9780816680498.003.0002 |isbn=978-0-8166-8049-8}}- Fujimoto, Yukari; Thorm, Matt (2012). "Takahashi Macoto: The Origin of Shōjo Manga Style". In Lunning, Frenchy (ed.). Mechademia 7: Lines of Sight. Translated by Thorn, Rachel. pp. 24–55. doi:10.5749/minnesota/9780816680498.003.0002. ISBN 978-0-8166-8049-8.
- Fujimoto, Yukari; Thorm, Matt (2012). "Takahashi Macoto: The Origin of Shōjo Manga Style". In Lunning, Frenchy (ed.). Mechademia 7: Lines of Sight. Translated by Thorn, Rachel. pp. 24–55. doi:10.5749/minnesota/9780816680498.003.0002. ISBN 978-0-8166-8049-8.
{{cite map|author-link=Joe Bloggs|date=5 January 2025|edition=57|editor-first=John|editor-last=Doe|editor-link=John Doe|first=Joe|format=format|issue=38|last=Bloggs|others=others|title=title|type=type|url=https://www.example.com/|volume=52|website=website}}- Bloggs, Joe (5 January 2025). Doe, John (ed.). "title" (format) (type). website. others. Vol. 52, no. 38.
- Bloggs, Joe (5 January 2025). Doe, John (ed.). "title" (format) (type). website. others. Vol. 52, no. 38.
- For most cs1|2 templates, the
|CitationClass=parameter is set to the lowercase version of the canonical template name. There are six for which that is not true;{{cite encyclopedia}}sets|CitationClass=encyclopaedia:{{cite encyclopedia |last=Seberg |first=Ole |editor1-last=Heywood |editor1-first=Vernon H. |editor2-last=Brummitt |editor2-first=Richard K. |editor3-last=Culham |editor3-first=Alastair |title=Alliaceae |encyclopedia=Flowering Plant Families of the World |url={{google books |plainurl=y |id=Jy1FAQAAIAAJ|page=340}}|date=2007 |publisher=Firefly Books |location=Richmond Hill, Ontario |isbn=978-1-55407-206-4 |pages=340–341}}- Seberg, Ole (2007). "Alliaceae". In Heywood, Vernon H.; Brummitt, Richard K.; Culham, Alastair (eds.). Flowering Plant Families of the World. Richmond Hill, Ontario: Firefly Books. pp. 340–341. ISBN 978-1-55407-206-4.
- Seberg, Ole (2007). "Alliaceae". In Heywood, Vernon H.; Brummitt, Richard K.; Culham, Alastair (eds.). Flowering Plant Families of the World. Richmond Hill, Ontario: Firefly Books. pp. 340–341. ISBN 978-1-55407-206-4.
- Conveniently, should we decide to implement this as a replacement for Module:Cite book and the others, Module:Cite is currently available.
- —Trappist the monk (talk) 19:49, 5 January 2025 (UTC)
Requested move 4 January 2025
 |  It has been proposed in this section that multiple pages be renamed and moved.A bot will list this discussion on the requested moves current discussions subpage within an hour of this tag being placed. The discussion may be closed 7 days after being opened, if consensus has been reached (see the closing instructions). Please base arguments on article title policy, and keep discussion succinct and civil. Please use {{subst:requested move}}. Do not use {{requested move/dated}} directly. Links: current log • target log • direct move |
- Template:cite AV media → Template:cite audiovisual media
- Template:cite AV media notes → Template:cite audiovisual media notes
- Template:cite tech report → Template:cite technical report
– The reason I'm requesting for these templates to be moved to their respective new titles is per WP:TG; because template function should be clear from the template name, but redirects can be created to assist everyday use of very popular templates, because redirects are cheap. PK2 (talk; contributions) 23:50, 4 January 2025 (UTC)
- References are used often and inline, which makes them noisy. These are some of the longer names. I would not support a move of any of the above. Izno (talk) 01:35, 5 January 2025 (UTC)
- The problem with the "redirects are cheap" argument is that redirected templates often lead to gnomes or bots replacing the templates with the redirect target (despite WP:COSMETICBOT) and this leads to a lot of clutter on everyone's watchlists, and the resulting waste of human editors' attention is not so cheap. —David Eppstein (talk) 01:39, 5 January 2025 (UTC)
- Oppose per the arguments of Izno and David. -- Michael Bednarek (talk) 01:58, 5 January 2025 (UTC)
- I'm unconvinced by the argument for this. I've never seen a confused misuse of {{Cite AV media}}. I don't see that it's purpose is unclear. On the other hand I've seen {{Cite journal}} used several times for people's diaries, but even that is an extremely rare issue. As other have said this will just result in the longer title being used, creating clutter for no practical effect. -- LCU ActivelyDisinterested «@» °∆t° 13:42, 5 January 2025 (UTC)
- Oppose for AV, don't care on tech. Headbomb {t · c · p · b} 16:00, 5 January 2025 (UTC)
- Oppose per David Eppstein and ActivelyDisinterested. Redirects are cheap until someone decides they all need to be bypassed, which people often choose to do en masse for some reason. And it's not clear how "AV media" could be confused for anything but "audio-visual media". I legitimately checked for possible confounders and came up empty.As an aside, I have also seen {{Cite journal}} to cite a diary, but the more common cases of confusion – in steeply ascending order – are people trying to use {{Cite document}} inappropriately to cite an online source, because it's a "document" (as if any written material isn't), and User:Citation bot swapping in an incorrect template because it sees an isbn or something.{{Cite tech report}} → {{Cite technical report}} is less objectionable, but still seems undesirable. Again, what do people think "tech report" might mean apart from "technical report"? (I suppose "technology report" or "technique report" might be theoretically possible.) Good faith request, but unconvincing, and neglects drawbacks. Folly Mox (talk) 17:00, 5 January 2025 (UTC)
- Oppose for the AV templates, I think there is a good argument that AV is more obvious than audiovisual. Meh on tech to technical. Skynxnex (talk) 02:46, 6 January 2025 (UTC)
Generic name
I'm aware of Reuters and CNN as authors when I see citations in Islamist insurgency in the Sahel. Achmad Rachmani (talk) 23:13, 6 January 2025 (UTC)
Categories: