Help talk:Citation Style 1

ISBN

I usually change any dash in isbn to {{nbhyph}}, because Sod's law says the line will break there. However now although {{nbhyph}} gets transformed correctly to &#‍x2011; that is how it stays. So isbn gets shown as for instance 978&#‍x2011;1892214973

John of Cromer in Philippines (talk) mytime= Tue 13:53, wikitime= 05:53, 26 March 2013 (UTC)

{{ cite book | title=Title | isbn=978‑0812695939 }}
Old	Title. ISBN 978‑0812695939.
Lua	Title. ISBN 978‑0812695939 .

Yep. This hack also breaks magic linking ISBN 978‑0812695939 v. ISBN 978-0812695939. The better solution would be to add markup in the template to keep this from wrapping. --— Gadget850 (Ed) ^talk 15:09, 26 March 2013 (UTC)

Please do not make any such change. Not only is it not undesirable for ISBNs to be allowed wrap, it's positively desirable, especially where cites are in 2- or 3-column format. In fact I was about to suggest that linebreaks be allowed between PMID and what follows, between doi: and what follows, and (within doi) at the slash. EEng (talk) 19:43, 26 March 2013 (UTC)

I think my reference to {{nbhyph}} is bit of a red herring. In fact it breaks if I enter the hard hyphen (&#x‍3011;) directly. John of Cromer in Philippines (talk) mytime= Wed 04:46, wikitime= 20:46, 26 March 2013 (UTC)

...(&#x‍2011;) ...! John of Cromer in Philippines (talk) mytime= Wed 04:50, wikitime= 20:50, 26 March 2013 (UTC)

non-breaking hyphen is rendered by ‑ in html. "2011" is the unicode character. 70.19.122.39 (talk) 13:51, 30 March 2013 (UTC)

hex-2011 = dec-8209 John of Cromer in Philippines (talk) mytime= Sat 22:24, wikitime= 14:24, 30 March 2013 (UTC)

Is there a preference between ISBN-10 and ISBN-13 where both are given? Hgrosser (talk) 00:55, 19 April 2013 (UTC)

Use the 13-digit ISBN if you have it for the source being referenced. Use only one ISBN in the |isbn= parameter of CS1 citations.

—Trappist the monk (talk) 01:13, 19 April 2013 (UTC)

Category:Pages using citations with accessdate and no URL

Hi, I just noted this category on a page that I edited (Journal of Reinforced Plastics and Composites). I added two references there that seem to trigger this cat. The references are online, which is why I included an accessdate. However, I cannot include a URL. The reason is that this resource is behind a pay-wall and uses dynamic session-specific URLs. This means that any URL that I would copy would not work for anyone else and, once I have closed and restarted my browser, not even for myself. I don't really see a workaround and in this case, having an accessdate but no URL seems reasonable to me. I could, of course, include a URL to the homepage of the resource, but as that is not the page where I found the information sourced by this reference, that seems less correct to me (and also runs the risk that someone will add a "fails verification" template to the reference). I'd appreciate any advice on how to handle this situation. Thanks! --Randykitty (talk) 15:34, 27 March 2013 (UTC)

Just a note for people that may be unaware. The hidden tracking category was recently added as part of the Lua migration; however, the behavior hasn't changed. It has always been the case that accessdate= is ignored if no URL is specified. Dragons flight (talk) 16:41, 27 March 2013 (UTC)

Actually, it seems to me that in the case outlined above, accessdate should perhaps not be ignored and displayed... --Randykitty (talk) 16:56, 27 March 2013 (UTC)

Yes, there is a valid question about whether accessdate should be included even if no url is given. Historically, the answer has been no, but perhaps that should change. Personally, I don't have a strong opinion either way. I was just trying to make clear that this is a discussion of a possible problem with how the accessdate parameter has been used in citations, which is different from many of the other recent reports on this page which deal with bugs specific to the Lua migration. Dragons flight (talk) 17:08, 27 March 2013 (UTC)

Per the the documentation: "Not required for web pages or linked documents that do not change; mainly of use for web pages that change frequently or have no publication date." In this instance, the access date really does not help identify the source. --— Gadget850 (Ed) ^talk 18:45, 27 March 2013 (UTC)

That's an excellent point. The URL may be dynamic, the page content isn't, so the accessdate is indeed not needed. Problem solved, I think! --Randykitty (talk) 19:01, 27 March 2013 (UTC)

No, your suspicions of the hidden-accessdate problem are correct, when no "url=" data, because the id parameters (such as "doi=") generate an internal URL which needs the accessdate to assure the time when access was allowed. The recent shake-up at Billboard.com disabled 50,000(?) weblinks. Thanks for raising the issue so quickly. -Wikid77 23:20, 27 March 2013 (UTC)

• Use parameter "postscript=" to force a date to appear: Previously, the Lua version displayed the "accessdate=" data, with no judgmental restrictions, but merely echoed all parameters as added by each user. However, with accessdate conditionally ignored, the postscript can be used to show that data:

postscript=. Retrieved 27 March 2013.

In general, ignoring parameters is typically extremely frustrating to new users who are likely to misspell parameter "url=" as perhaps capital-letter "Url=" which would be ignored, then causing the "accessdate=" value to also be hidden as well, and a new user is likely to go bonkers wondering why this "trashy" citation software does not show the URL address nor even the damned accessdate as ignoring "everything" they put in the cite. In general, there is a fine line between "smart" software and "smart-ass" software, and the automatically ignored parameters, triggered by arcane rules of citation hierarchies, will be considered by many users to be poor-quality, and non-user-friendly. Beware when the interface acts as "minefield" of traps, where one misspelled word triggers peculiar sinkholes where other parameters also disappear. In general "keep it simple" and mimic the concept of "what you see is what you get" (WYSIWYG), so if a user enters a parameter, then display that parameter without prejudiced, judgmental restrictions as to what will be deemed permissable, and instead: if they see it in the markup, they get it. However, with the speed of Lua, we will be able to process an assistance parameter (such as "help") which could warn the user, at each specific citation, about which unexpected parameters were being ignored, according to what elaborate rules for citation etiquette, or common misspellings. -Wikid77 (talk) 21:33, 27 March 2013 (UTC)

Then we should remove all restrictions and allow any and all combinations of parameters to show. We could add 'url' 'URL' 'website' 'site' 'link' 'internet' 'tubes' and for those who just can't remember 'thingy'. Then we can delete the documentation and allow editors to pick their favorite parameter names.

But really- postscript is the terminating punctuation. Yes, editors stuff all sorts of crap in it, but we aren't allowed to send them to citation reeducation camp. Unless you can come up with some sort of heuristically programmed algorithm that will sort through a free-form citation and clean it up. then we just have to live with rules. If editors can't take how the templates work then they have other options. --— Gadget850 (Ed) ^talk 22:13, 27 March 2013 (UTC)

--— Gadget850 (Ed) ^talk 22:13, 27 March 2013 (UTC)

Hey, I did not invent the way people think about computers, I just spent 5-7 years in universities, to learn what issues to beware. And "People are the way they are". Working with computer users is like a complex chess game, and to "win" their approval, there are a lot of complex issues to consider, such as trying to make complicated operations seem simple to them, without over-complicating the underlying simplicity or freedom of choices. -Wikid77 (talk) 23:20, 27 March 2013 (UTC)

Accessdate needed for doi/PMID/bibcode URL links

I found the need for the unrestricted "accessdate=" parameter, in the first article I checked ("1843 in science"), which ironically, links to an article about the "first computer program in history" (Ada Lovelace and Charles Babbage), but the cite links the webpage using a doi-parameter to generate a URL address, so the accessdate disappeared (when no "url="). Compare:

{{ cite journal | last2=Francis | year=2003 | journal=IEEE Annals of the History of Computing | doi=10.1109/MAHC.2003.1253887 | last1=Fuegi | first2=Jo | month=October–December | issue=4 | first1=John | volume=25 | title=Lovelace & Babbage and the creation of the 1843 'notes' | pages=16–26 | accessdate=2010-10-01 }}
Old	Fuegi, John; Francis, Jo (October–December 2003). "Lovelace & Babbage and the creation of the 1843 'notes'". IEEE Annals of the History of Computing 25 (4): 16–26. doi:10.1109/MAHC.2003.1253887.
Lua	Fuegi, John; Francis, Jo (October–December 2003). "Lovelace & Babbage and the creation of the 1843 'notes'". IEEE Annals of the History of Computing 25 (4): 16–26. doi:10.1109/MAHC.2003.1253887.
Sandbox	Fuegi, John; Francis, Jo (October–December 2003). "Lovelace & Babbage and the creation of the 1843 'notes'". IEEE Annals of the History of Computing 25 (4): 16–26. doi:10.1109/MAHC.2003.1253887.

Cite_quick: Fuegi, John; Francis, Jo (October–December 2003). "Lovelace & Babbage and the creation of the 1843 'notes'". IEEE Annals of the History of Computing 25 (4): 16–26. doi:10.1109/MAHC.2003.1253887. Retrieved 2010-10-01.

Several other parameters (pmid, pmc, bibcode, OL, etc.) generate URL addresses, for which the date of access applies. See numerous URL links below:

{{ cite journal | pmid=PMID-777 | last=Lovelace | issue=1 | ol=99A | first=Ada | journal=Keep It Simple | pmc=PMC999 | bibcode=10.1109/MAHC.2003.1253887 | month=August | title=Numerous Generated URL addresses | volume=1 | year=1815 | pages=16–26 | accessdate=2013-03-27 }}
Old	Lovelace, Ada (August 1815). "Numerous Generated URL addresses". Keep It Simple 1 (1): 16–26. Bibcode 10.1109/MAHC.2003.1253887. OL99A. PMC PMC999. PMID PMID-777. //www.ncbi.nlm.nih.gov/pmc/articles/PMCPMC999/. Retrieved 2013-03-27.
Lua	Lovelace, Ada (August 1815). "Numerous Generated URL addresses". Keep It Simple 1 (1): 16–26. Bibcode:10.1109/MAHC.2003.1253887. OL 99A. PMC PMC999. PMID PMID-777. Retrieved 2013-03-27.
Sandbox	Lovelace, Ada (August 1815). "Numerous Generated URL addresses". Keep It Simple 1 (1): 16–26. Bibcode:10.1109/MAHC.2003.1253887. OL 99A. PMC PMC999. PMID PMID-777. Retrieved 2013-03-27.

The easiest fix is to "keep it simple" and not have any restriction to hide the "accessdate=xx" parameter. That would be another benefit of using the Lua version of the {cite_*} cites. -Wikid77 23:20, 27 March 2013 (UTC)

What does the access date mean to you? --— Gadget850 (Ed) ^talk 23:26, 27 March 2013 (UTC)

accessdate is when I or anyone else last visited the url. I hardly come across the doi etc. parameters, but aren't they as fixed as isbn, even more so, so why would they need any associated date? I'm not sure how your examples differ - I think you should subst: them in so they're fixed. Incidentally, I always specify dates as {{date|date}} because I understand that then emits date according to user's local style sheet. May also translate to user-language, I'm not sure.

John of Cromer in Philippines (talk) mytime= Thu 08:31, wikitime= 00:31, 28 March 2013 (UTC)

Apparently, people think the "accessdate=" is when they read the webpage, even if they did not know/want the URL address to include it. Perhaps that explains why many of those 40,576 people put "accessdate=" in their cites, with an empty "url=" because they are stating they accessed the page on that date. See: examples among the few 40,576 pages already in "Category:Pages using citations with accessdate and no URL". There might 90,000 people who also put the lone accessdate in {cite_web}. That is just the way people think. -Wikid77 07:29, 28 March 2013 (UTC)

I just noticed {{date}} being used in a citation. No it does not and cannot use the user date preference. With no other parameters it formats the date as DMY, thus it is rather useless here. Date formatting was dropped years ago since it relied on logged in user preferences and gave a mix of formats for casual readers. --— Gadget850 (Ed) ^talk 00:59, 28 March 2013 (UTC)

• Perhaps leave the lone accessdate until {cite_web} counted: This is an opportune time to allow the lone accessdate to remain hidden (when no "url="), until after Template:Cite_web is transitioned to Lua, to category-count all the people/pages where "accessdate=" is used without the URL parameter, among those 1.3 million {cite_web} pages. Then, based on "overwhelming demand" we can report that a consensus of "95,000" editor teams wanted to show the lone accessdate, and then perhaps sample among those thousands as to how many use "doi=" and "accessdate=" together. Remember, once {cite_web} uses Lua, then all those 1.7 million articles can be reformatted, to show accessdate, 4x times faster than any prior change to {Citation/core}. Optionally, we could upgrade to show the requested lone accessdate, but still log those pages in the Category, and later re-change to hide some of those lone accessdates. Think of this as: 3 extra chances to add new features, to the Lua cites, before incurring the overhead of 1 old update to {Citation/core}. Because once {cite_web} uses Lua, then general editing will reformat thousands of pages for "free" with the 3x faster edit-saves. -Wikid77 07:29, 28 March 2013 (UTC)

• Let's remember that the purpose of the citation is to identify the source, and each element should help in that goal. The access date is intended only for web pages that change frequently (e.g. Wikipedia main page) or have no discernible date, and has been documented that way from inception. The date someone added a citation does not help us in identifying the source. A Bibcode, doi, JSTOR or similar link does not need an access date as the content of those links by design do not change.
• Simply because editors use a field in some odd manner does not mean that we should automatically assume that there is some sort of gestalt consensus to change the use. Most casual editors will not read the documentation and will simply follow what they see in an extant page, thus bad practices are propagated. We have already seen that both page and pages are included, where the editor believes that pages is for the total number of pages in a work, which is not needed to identify the source. --— Gadget850 (Ed) ^talk 09:33, 28 March 2013 (UTC)

Yes, yes, this. 95,000 examples of improper use out 1.605 million or 1.205 million (which ever number is correct?) does not constitute consensus. Where is the discussion?

I think that Gadget850 is inadvertently helping to make my case for visible error messages (Error trapping and checks and Format but no URL) because without visible cues to the contrary, editors assume that improper use is proper and so continue with and adopt new bad practices.

—Trappist the monk (talk) 13:31, 28 March 2013 (UTC)

Error checking is good, but we need to spec it out and link to help pages for each specific issue. --— Gadget850 (Ed) ^talk 14:06, 28 March 2013 (UTC)

I've been thinking exactly that and will probably open a discussion to talk about messaging, help pages, linking from the error, etc when I return from spring break.

—Trappist the monk (talk) 23:38, 28 March 2013 (UTC)

make sure to include error-checking for when software exceeds the bounds, with overly-restrictive recommendations and the related generated errors. 70.19.122.39 (talk) 15:43, 29 March 2013 (UTC)

The Chicago Manual of Style (16th ed., p. 657–8) discusses access dates for electronic sources in general. Such a date might include electronic sources not accessible through a URL. For example, help files from software that is constantly updated. While some sort of version number might be available, the editor might not know how to access such a number, or it might be so difficult that the editor would feel the reader would be unable to access it or understand it. I admit this would be a fairly unusual occurrence. Jc3s5h (talk) 09:54, 29 March 2013 (UTC)

a version number is an edition, and should probably carry some kind of date. online sources are a subset of electronic sources, and internet/intranet sources a further subset of online sources. for such sources accessdate is the de facto edition date, if there is no other info available. 70.19.122.39 (talk) 15:43, 29 March 2013 (UTC)

• Online sources are always subject to computer-dependent revision at any time: Although stored documents might seem theoretically static, for the displayed contents, the broader reality in data processing is that all documents are subject to change when retrieved, or dynamically reformatted, from the document database(s). The problem of date-stamped materials has been so flexible that computer software, for years, has included a "build version" beyond just a computer program version number, where the contents of a "static" version might change because the underlying runtime library might have changed to alter operation of the upper-level software. For document storage, the underlying database might alter, or truncate, data in various ways, depending on unknown bugs in the current release, perhaps upgraded last week, of the database system used to display the stored document. For those reasons, an accessdate parameter helps to indicate which database or text-formatting product versions, at a point in time, were active in displaying the cited document, especially if national laws required censorship, of prior documents, for new content restrictions. -Wikid77 (talk) 19:07, 29 March 2013 (UTC)
• If an online document was subtly changed and the visible date did not change, how would you or another editor know it? --— Gadget850 (Ed) ^talk 19:23, 29 March 2013 (UTC)

well this can get complicated. if one drills down, the effects of caching may also have to be accounted for. personally i tend to think that in situations where the document (a) has not changed and (b) it is not retrieved from a cache, every access could be functionally considered a "reprint". 70.19.122.39 (talk) 00:39, 30 March 2013 (UTC)

Discussion regarding the usage and cleaning of accessdate

As this discussion seems to have puttered out without really reaching a broad consensus, I've decided to try taking the issue to a somewhat broader forum, as well as discussing what to do next. Please see the community discussion at Wikipedia:Village pump (policy)#Use of accessdate in citation templates about the appropriate usage of the |accessdate= parameter and what steps (if any) should be taken to clean it up. I invite your comments at that page. Dragons flight (talk) 03:57, 29 April 2013 (UTC)

Having an editor results in "In"?

[edit]Regarding {{cite book}} – Kerαunoςcopia^◁_galaxies 04:12, 11 April 2013 (UTC)
Is this new? That's very, very strange to me. What's wrong with using the "ed." abbreviation, even with an author? – Kerαunoςcopia^◁_galaxies 04:12, 11 April 2013 (UTC)

This is not new, per the template documentation:

If authors: Authors are first, followed by the included work, then "In" and the editors, then the main work.

If no authors: Editors appear before the included work; a single editor is followed by "ed."; multiple editors are followed by "eds."; more than three editors will be followed by "et al., eds."

--  Gadget850 (Ed) ^talk 07:39, 11 April 2013 (UTC)

Well, I saw that in the documentation, but I don't recall seeing "in" in any college papers. That just seems like a weird thing to say. Author, in another person. I've always seen "ed.", whether there's an author or not, so I'm wondering where this rule stems from. – Kerαunoςcopia^◁_galaxies 08:16, 11 April 2013 (UTC)

I can't answer for the template creators, but this is generally in line with APA Style.[1] --  Gadget850 (Ed) ^talk 15:43, 12 April 2013 (UTC)

See, those examples are normal. (ed.) and (eds.) are used to signify editors. "In" is just bizarre (I wasn't clear, but I meant that I didn't know where the "In" rule was coming from); I have never seen that until now. I suppose the only option would be to write the reference out manually and not use the template. – Kerαunoςcopia^◁_galaxies 17:56, 12 April 2013 (UTC)

But, if the article uses Citation Style 1, then you need to continue to use it unless you gain consesnsus to change all of the the citations to a different style. See WP:CITEVAR. --  Gadget850 (Ed) ^talk 18:11, 12 April 2013 (UTC)

Historically, the templates have always used "In" with books that had authors, editors, and named chapters:

Doe, John (1945). "My chapter". In Brown, Mary. My book.

If the book had authors and editors, but no chapter title, then "ed." was historically used:

Doe, John (1945). Brown, Mary. ed. My book.

However, this creates a problem with the lack of a clear demarcation between the end of an author list and the start of an editor list if the date is missing:

Doe, John. Brown, Mary. ed. My book.

So, in the new Lua templates, "In" is used whenever both authors and editors are specified, regardless of whether a chapter title is present:

Doe, John. In Brown, Mary. My book. 

Lastly, I would note that if a book has no authors, then editors are still marked with "ed.":

Brown, Mary, ed. (1945). My book. 

The style guide linked above suggests using both "In" at the beginning and "Ed." at the end to demarcate editors in edited volumes that contain both authors and editors. Personally, I wouldn't be opposed to adding the "Ed." at the end as well. Dragons flight (talk) 18:23, 12 April 2013 (UTC)

{{cite news}} uses Citation Sytle 1, and this produces awkward references for news articles that have both an author and an editor, for example:

Jim, Claire (April 24, 2013). In Wills, Ken. "Taiwan man contracts H7N9 bird flu, first outside mainland China". Taipei. Reuters. 

Is this really correct for a newspaper citation? —RP88 ^(talk) 12:44, 24 April 2013 (UTC)

The word "in" should only be used between the description of a component with a named author and a containing work with a named editor. It is not typical to name both an editor and an author for exactly the same work; indeed, RP88's example one would normally only cite the author, not the editor. If a case were discovered where it would be plagiarism to not site both the author and the editor, one would hand-write a citation because apparently citation style 1 does not support citing both an author and editor for exactly the same work; it only supports citing the author of a contained work and the editor of the containing work.

Of course all the stuff in WP:CITE about preserving the existing style of an article is no excuse to suppress information or commit plagiarism, so the preserving style stuff must be ignored when you need to cite a work that is not supported by a template. Jc3s5h (talk) 13:02, 24 April 2013 (UTC)

Yes, the "In" arises not from having an editor, but from a "work" being contained within a larger work. I seem to recall once seeing an article that had several authors, and two editors named as such. (Perhaps showing they were not responsible for the substantive content?) But most certainly that is not typical. ~ J. Johnson (JJ) (talk) 17:58, 24 April 2013 (UTC)

So, from my understanding, there's the case where there is an editor for the same work, as might be true for a newspaper articles or books, and then there is an editor for the "larger" (greater) work such as might be the case with an encyclopedia or a journal. Doesn't that suggest we should have two sets of parameters for it? I'm not sure I would know how to distinguish the two, but I have at least been using the parameter incorrectly. --Izno (talk) 19:42, 24 April 2013 (UTC)

Well, on second thought, what if it is the chief editor who is editing a newspaper article? I could easily claim that he certainly serves as the editor to the greater work. Just musing. --Izno (talk) 19:44, 24 April 2013 (UTC)

This is clearing things up for me. If I understand correctly, a book with an author and an editor shouldn't have the "In" line because only the author should be credited, or if the editor should be mentioned, it should be done manually; but a work by an author that is "contained within a larger work" would use "In", and this actually does make sense to me now. – Kerαunoςcopia^◁_galaxies 19:48, 24 April 2013 (UTC)

This is the first instance I have encountered where a newspaper article has an editor. I don't see the need for the editor, and I see no connection to plagiarism. --  Gadget850 ^talk 20:03, 24 April 2013 (UTC)

I am unable to think of an example where exactly the same work would have both an author and an editor, and the editor needs to be cited in order to avoid plagiarism. But I won't guarantee there isn't some such work lurking out there. Jc3s5h (talk) 20:45, 24 April 2013 (UTC)

It isn't at all about plagiarism, it is entirely about correct attribution. (Even an incorrect or an "anonymous" attribution technically avoids plagiarism.) The normal use-case for "in" would be something like an advanced reference deskbook or conference proceedings, where various chapters have different authors. Sometimes only the editors are show in the cataloguing data for the book, making it helpful in locating it among similarly-titled works in open stacks, yet the cited chapter in the work is due to a specific named author.

Historically (not so much for the Web) all published works had editors. They are not cited where they are essentially part of the publisher. They are cited (as editors) where they (and not the publisher) have assembled (and are responsible for) a work. ~ J. Johnson (JJ) (talk) 22:01, 29 April 2013 (UTC)

Cite episode deprecated parameters

Editor AussieLegend has reverted this edit. With this edit, Editor AussieLegend added new text. This is the text that, prior to its deprecation, described |episodelink=.

|episodelink= was used to link |title= to a Wikipedia article. But, |episodelink=, unlike |serieslink=, has no matching |episodetitle= parameter. If the citation includes |url= and |episodelink= the resulting citation title looks like this (red link because there is no Wikipedia article titled "Episode link"):

{{cite episode |title=Episode title |episodelink=Episode link |url=http://www.example.com}}

→"Episode title". . http://www.example.com.

A quick search to see how |episodelink= is used indicates that {{cite episode}} is most often used to cite other Wikipedia articles. For a spectacular example of this see Major villains in Charmed at §References.

Use of |episodelink= in this manner breaks |title= when a proper |url= is part of the citation and, when |url= is not part of the citation, serves simply as a wikilink to another article. This latter is a misuse of the citation because WP:NOTRS, particularly WP:CIRCULAR. Citations like those in Major villains in Charmed and other articles should be replaced with wikilinks in article text and proper citations to reliable sources. |serieslink= is not required because its matching parameter, |series=, can and should be wikilinked. For these reasons Editor AussieLegend's changes should be reverted and I have done so.

—Trappist the monk (talk) 14:33, 11 April 2013 (UTC)

This is not actually an accurate interpretation. The intention of |episodelink= is simply to provide a link to a Wikipedia entry on the episode. Per MOS:TV, specifically WP:TVPLOT, television episodes are acceptable primary sources. We link to the episode article because it's not possible to link to the actual episode that aired. When corrrectly used, {{cite episode}} should ideally include use of either the |minutes= or |time= parameters. For example:

• {{cite episode|title=Red-2|episodelink=#ep91|series=NCIS: Los Angeles|serieslink=NCIS: Los Angeles|network=[[CBS]]|date=March 26, 2013|season=4|number=19|minutes=02:21}} produces
  "Red-2". NCIS: Los Angeles. Season 4. Episode 19. March 26, 2013. 02:21 minutes in. CBS.

The documentation as I modified it simply reflects the way that the template works. It does not change the way that the template works; |episodelink= is still a functional parameter after Trappist the monk's removal of the documentation, which was modified around this time last year to change the description of |title= to "Title of source. Can be wikilinked to an existing Wikipedia article or url may be used to add an external link, but not both. Displays in quotes." (This was how the parameter was deprecated. There doesn't appear to have been any discussion about deprecating either |episodelink= or |serieslink=.) Despite the "but not both" claim, it is still possible both link to an article in the title and use a url. Doing so results in:

• {{cite episode|title=[[NCIS: Los Angeles (season 4)#ep91|Red-2]]|url=http://www.example.com}} producing:
  "Red-2". http://www.example.com.

or, to use Trappist the monk's example:

• "Episode title". http://www.example.com.

This results in the same peculiar output as Trappist the monk's example, where both the url and the wikilink are shown, with the url preceding the wikilink. Argue as you may that it won't, history shows that the likelihood such a citation will be added is high - I'm always fixing incorrect uses of this template. The solution would seem to be simply to modify {{cite episode}} so that |url= overrides |episodelink=; hiding the problem with documentation hacks is not the way to do it. I suspect that the reason this was never done previously is that, being a broadcast medium, there rarely is a url to a particular episode. Other than a recap on an official site, any such url is generally a linkvio and most urls don't actually seem to support the information that is being cited. There is no explanation as to why serieslink has been deprecated. It too is still a fully functional parameter. --AussieLegend (✉) 16:15, 11 April 2013 (UTC)

Stepping back from the issue of what it does output, which is pretty clearly malformed, do you have an opinion on what ought to happen if both episodelink and url are specified? If you do something like this with the new Lua citations you get:

{{cite web|title=Episode title |titlelink=Episode link |url=http://www.example.com}}

→"Episode title" http://www.example.com . 

Which is arguably better than the present format, but probably still bad because there is no description on the URL. Dragons flight (talk) 17:07, 11 April 2013 (UTC)

As I said, "The solution would seem to be simply to modify {{cite episode}} so that |url= overrides |episodelink=". In the event that a url is available, you should see "Episode title". http://www.example.com., which is easier to do if we continue to use |episodelink=. --AussieLegend (✉) 17:24, 11 April 2013 (UTC)

Having said that, I've discovered a now archived proposal by 117Avenue that may be an alternative. I haven't checked it out thoroughly, but you can find it here. --AussieLegend (✉) 17:32, 11 April 2013 (UTC)

(edit conflict)|serieslink= was and should be deprecated because:

|series=NCIS: Los Angeles|serieslink=NCIS: Los Angeles

is the same as:

|series=[[NCIS: Los Angeles]]

This works because |series= is not a synonym for another parameter and technically identical to how you implemented |network=.

How about this? Wikilink to the Wikipedia episode article through the |number= parameter. Doing that shows how |episodelink= isn't necessary, reduces duplication, and leaves |title= free for use with |url=. Here is a tweaked version of your example:

{{cite episode|title=Title for link to external NCIS: Los Angeles (season 4) site|url=http://www.example.com|series=[[NCIS: Los Angeles]]|network=[[CBS]]|date=March 26, 2013|season=4|number=[[NCIS: Los Angeles (season 4)#ep91|19]]|minutes=02:21}}

→"Title for link to external NCIS: Los Angeles (season 4) site". NCIS: Los Angeles. Season 4. Episode 19. March 26, 2013. 02:21 minutes in. CBS. http://www.example.com.

Presumably |url= identifies a WP:RS.

Per MOS:TV, specifically WP:TVPLOT, television episodes are acceptable primary sources. Well, yeah ... Except that it states in the same paragraph: "Since the episode is the primary source and the infobox provides details about it, citing the episode explicitly in the plot summary's section is not necessary." I think that this supports my position that the citations in articles like Major villains in Charmed should be reduced to wikilinks in the text rather than malformed "citations".

Here is a {{cite web}} version of the tweaked {{cite episode}} citation above:

{{cite web|title=Title for link to external [[NCIS: Los Angeles]] (season 4) site|url=http://www.example.com|series=[[NCIS: Los Angeles]]|network=[[CBS]]|date=March 26, 2013|season=4|number=[[NCIS: Los Angeles (season 4)#ep91|19]]|minutes=02:21}}

→"Title for link to external [[NCIS: Los Angeles]] (season 4) site". NCIS: Los Angeles (19). CBS 02:21 minutes in. March 26, 2013. 

The reason I show you this is because this is how Module:Citation/CS1 treats the case where |title= has both |url= and a competing wikilink. This is the future. CS1 will eventually handle all of the 23 or so separate Citation Style 1 templates.

—Trappist the monk (talk) 17:38, 11 April 2013 (UTC)

|serieslink= is often not the same as |series=. NCIS won't get you the TV series, Hell's Kitchen won't get you to the UK TV series or the U.S. TV series. The statement "|serieslink= is not required because its matching parameter, |series=, can and should be wikilinked" is not entirely correct either. The new documentation only says, "The name of the series the episode belongs to; may be wikilinked" but the old documentation gave more detail: "If the citation is being used in the article about the series itself, this call is not necessary and will in fact create improper formatting." This is more correct - when used in the main article, the series title will be improperly bolded in the citation:

• "Red-2". NCIS: Los Angeles. Season 4. Episode 19. March 26, 2013. 02:21 minutes in. CBS.

i.e. The series name should not be linked in some circumstances. I know from experience that when re-using a citation from a series or episode article, or episode list, which happens very often, it's a lot more convenient to strip "|serieslink=Series name (TV series)" from a citation than it is to delink [[Series name (TV series)|Series name]]. OK, it's not extremely complicated but I don't see the point in making anything more difficult than it needs to be and this has been working fine for years. |network= rarely requires disambiguation, just linking, which is why there is no |networklink=.

""Since the episode is the primary source and the infobox provides details about it, citing the episode explicitly in the plot summary's section is not necessary." I think that this supports my position that the citations in articles like Major villains in Charmed should be reduced to wikilinks in the text rather than malformed "citations"." - No, I'm afraid it doesn't. The section that you've quoted only applies to episode articles that have an infobox for the specific episode. Episode lists have a different infobox and {{cite episode}} isn't normally used in the plot section of episode lists or articles, although sometimes it is necessary. More often than not it's used in TV series main articles, character articles and even some completely unrelated articles that need to cite a television episode. It provides for the inclusion of times using |minutes= or |time=, which a wikilink doesn't. These parameters point to a specific time in the episode that supports the claim. For example, prior to airing, the NCIS: Los Angeles episode "Red-2" was listed in reliable sources as "Red: Part Two".[2] However, when it aired the title shown on-screen was "Red-2". The citation that I've been using as an example includes the time in the episode ("02:21 minutes in") where this is shown. Unlike a newspaper or website, where a reader can usually do a word search to verify a claim, this is not possible in a TV episode. A time code is needed in order to avoid having to watch a large chunk of most episodes (not all information is in the opening credits and fast-forwarding often misses the information, especially when it is spoken). --AussieLegend (✉) 17:58, 11 April 2013 (UTC)

Some sort of (edit conflict) occurred here that resulted in part of Editor AussieLegend's above post getting deleted. Not sure how that happened; there was no warning at the time I saved my post below. I think that Editor AussieLegend's has been restored,

—Trappist the monk (talk) 19:20, 11 April 2013 (UTC)

It isn't clear to me why there are any |whateverlink= parameters except for |authorlink= and |editorlink= - these because author and editor names are often broken up into given- and surnames. Your argument, as I understand it, is that creation and maintenance of disambiguated wikilinks is an onerous task. I'm not persuaded.

I'm not understanding the need to cling to {{cite episode}} and |episodelink= when all that it is accomplishing is a multiple-step link from the article text that the reader is reading: (click) to §References where the reader has to figure out which link in the citation to follow; (click) to the episode article. Tell me why using {{cite episode}} and |episodelink= is better for this than a simple wikilink in the article text where the reader is reading; (click) to the episode article.

Documentation can pretty much always be made more clear just as what we write here in this discussion can be made more clear. Perhaps I should have written "|serieslink= is not required because its matching parameter, |series=, can and should be wikilinked instead."

—Trappist the monk (talk) 18:49, 11 April 2013 (UTC)

(taps himself on the shoulder and reminds himself that the topic of the discussion is deprecated parameters)

This cite does what I think you want yet doesn't use the deprecated parameters |episodelink= and |serieslink=:

{{cite episode|title=Red-2|series=[[NCIS: Los Angeles]]|network=[[CBS]]|date=March 26, 2013|season=4|number=[[NCIS: Los Angeles (season 4)#ep91|19]]|minutes=02:21}}

→"Red-2". NCIS: Los Angeles. Season 4. Episode 19. March 26, 2013. 02:21 minutes in. CBS.

—Trappist the monk (talk) 19:36, 11 April 2013 (UTC)

"Your argument, as I understand it, is that creation and maintenance of disambiguated wikilinks is an onerous task. I'm not persuaded." - May I ask how many television articles you've edited and had to reference using {{cite episode}}? If the answer is what I think, then I can understand why you can't see. As an editor who has edited hundreds of TV articles I can say that it is something that saves considerable time and, as I've said, it's something that has worked well for years, so I don't see what is to be gained by deprecating useful parameters.

"Tell me why using {{cite episode}} and |episodelink= is better for this than a simple wikilink in the article text where the reader is reading; (click) to the episode article." - The episode link adds information. A link to the episode entry isn't really needed in the citation at all, if editors use the |time= or |minutes= parameters, but they are parameters that are often omitted - editors can often cite something from an episode but don't have the time from the episode that something occurred. Of course we could say that most citation parameters aren't needed. All we really need is <ref>http://www.example.com</ref> but we encourage editors to add as much information as possible to citations. Where a detailed episode article exists, a link to the episode article can often provide the information needed, without forcing the reader to have to search for a copy of the episode, especially if it's something that just deals with plot information. The full citation information is still present, but the link often provides a shortcut. It's also not always practical to provide a wikilink to an episode in the prose. Sometimes the episode title just doesn't "fit" - "The warden was revealed to be a man.^[10]" is preferable to "As stated in "Caged Fae", The warden was revealed to be a man.") When an episode is referenced multiple times, as often happens, a wikilink in each place generally violates WP:REPEATLINK. An episodelink in the citation avoids that.

"Perhaps I should have written "|serieslink= is not required because its matching parameter, |series=, can and should be wikilinked instead."" - No, because that's wrong too. There are times, as explained above, when | should NOT be wikilinked.

"This cite does what I think you want yet doesn't use the deprecated parameters" - It does, but I've explained the problems with that above, and you haven't convinced me that those parameters should be deprecated, remembering that never was any discussion that lead to them being deprecated. There was just one arbitrary edit that decided they should be deprecated. It was a bold edit, but it has been opposed. --AussieLegend (✉) 13:02, 12 April 2013 (UTC)

I updated the template to {{citation/core}} over a year ago and the documentation a bit later.discussion My reasoning for deprecating, but not removing these two parameters was to encourage editors to use the wikilink method of the other Citation Style 1 templates but retain the parameters for backward compatibility.

As we move forward in updating CS1 templates to use Lua, we have added a lot more error checking. For example, with {{cite book}}, if you specify 'url' and use a wikilink in 'title' then there is an error message. These are not yet visible as we want the help system to be in place before editors start seeing a bunch of new errors. This particular check would not fix the issue with 'serieslink' and a wikilink in 'title', but it would give an error and place the page in a category.

I have added a feature request to check to see if a wikilink is to the current page and simply kill the link. --  Gadget850 (Ed) ^talk 16:20, 12 April 2013 (UTC)

--  Gadget850 (Ed) ^talk 16:20, 12 April 2013 (UTC)

What you guess is probably close to right, but the number of whatever-type of article edits I've made has no bearing on whether or not |episodelink= and |serieslink= should be deprecated. Have you considered AWB for these repetitive edits?

Have you considered using {{rp}} to reference a specific event time?

However, when it aired the title shown on-screen was "Red-2".

I included a linked title which may not be the right destination but you get the point.

In your Caged Fae example, does the reader not already know that the subject is the Lost Girl Caged Fae episode? If not, then perhaps the article text needs editing to make that clear. While it might be helpful to the reader to know that the discussion is about the Caged Fae episode, it may be inconvenient or inappropriate to include that information at that particular place in the article text. So then perhaps this:

"The warden was revealed to be a man."

or something similar. The sentence might need rewording to more fully accommodate the wikilink. I don't think that this violates the tenants of WP:REPEATLINK.

Since I haven't convinced you and you haven't convinced me, here we stand unresolved. So, I've been wondering if an alternate solution exists that answers the need to make reference to an episode article, event time, etc that doesn't use {{cite episode}} at all so there is no need for |episodelink= and |serieslink=. What if we were to create a referencing template {{ref episode}}? It might provide <ref group=episode></ref> tags or similar so that references to episode articles would be automatically grouped together under a separate {{reflist|group=episode}}. Parameters might include |title=, |number=, |minutes=, etc. No external link conflicts; |title= and |number= are wikilinkable. Not sure how to do <ref group=episode name="??" /> but I'm sure it can be figured out – {{sfn}} does it which might be forked to create {{ref episode}}. Here, in this thread though, is not the place to discuss the details of this {{ref episode}} idea.

—Trappist the monk (talk) 16:03, 12 April 2013 (UTC)

If you haven't been through the experience, then it's hard to understand what it means to have the convenience. That's not a criticism of you, it just makes it hard to convey the information. For example, most people wouldn't know the advantage the pedals in a left hand drive Lamborghini Gallardo has over a right hand drive model (just trying to pick an "out there" example"). No, I haven't considered using {{rp}} because it is "is for appending page numbers in Harvard referencing style (or AMA style", not for adding time codes. {{Cite episode}} is a template specifically for citing episodes including times within episodes. We really should use the right tool for the right job, and the right tool here is {{Cite episode}}.

"In your Caged Fae example, does the reader not already know that the subject is the Lost Girl Caged Fae episode?" - Yes, of course they should. I was attempting to show you how episode titles don't necessarily fit into the prose - don't overthink it.

""The warden was revealed to be a man."" - That's pretty ambiguous. Wikilinks should be obvious in their purpose. A reader is more likely to ignore such a link, thinking that it's a link to an article related to "revealed".

"So, I've been wondering if an alternate solution exists that answers the need to make reference to an episode article, event time, etc that doesn't use {{cite episode}} at all so there is no need for |episodelink= and |serieslink=." - Again, don't overthink it. The reality is that, there was never any consensus to deprecate episodelink and serieslink and they remain fully functional parameters. They've only disappeared from the documentation, again without any consensus to remove them. The template is transcluded 7,226 times and many uses include episodelink and serieslink. There is no reason why we shouldn't continue to use them. What we DO need to do is fix the issue caused when the episode title is linked (in whatever form it is linked) and |url= is present. I don't think anyone disagrees with the argument that url should override wikilinking. --AussieLegend (✉) 16:46, 12 April 2013 (UTC)

The parameters are still supported, so use them as desired. The issues can be resolved per my post just above, unless there is an objection to the Lua update. --  Gadget850 (Ed) ^talk 3:31 am, Today (UTC+10)

No need to be patronizing. I'm not a neophyte; like most people I can use my own past experiences to understand things of which I have no direct experience.

If you'd rather not use {{rp}} in a manner different from its intended purpose, try this:

However, when it aired the title shown on-screen was "Red-2".^{(Red-2 02:21)}

The sentence: "The warden was revealed to be a man," was an example with the caveat that it might need rewriting. Do you think that readers give superscript-links to citations more attention than they do wikilinks? I don't know, but I'd be surprised if they did.

I agree that a |url=-type parameter should have precedence over a wikilink when there is a contention for the same title and, when this occurs, CS1 should report an error.

Still, I haven't convinced you and you haven't convinced me, here we stand unresolved.

—Trappist the monk (talk) 18:27, 12 April 2013 (UTC)

You certainly seem to be having issues with deleting content. This edit completely reverted Gadget850's post from more than an hour before yours.[3] In that post, which I've restored,[4] he says continue using the parameters. Since he's the one who originally deprecated the parameters, that should carry some weight. --AussieLegend (✉) 19:29, 12 April 2013 (UTC)

Use them, don't use them- it doesn't matter as long as we get the proper citation. But, the link parameters don't do anything that wikilinking can't do. When we do the Lua update we will just fake it. The doc does need to be edited for style. --  Gadget850 (Ed) ^talk 19:46, 12 April 2013 (UTC)

I don't delete other editors talk posts, ever. That it's happened to me twice and only in this conversation is interesting but not a willful act on my part.

Yep, |episodelink= and |serieslink= are deprecated and should stay that way.

—Trappist the monk (talk) 23:08, 12 April 2013 (UTC)

No, they are not deprecated. One editor can't make an arbitrary decision to deprecate parameters in a widely used template. There needs to be discussion and consensus to deprecate. Ironically, the editor who made the bold decision to deprecate seems to accept this. It's only you who is arguing for deprecation. --AussieLegend (✉) 15:30, 13 April 2013 (UTC)

Actually, an editor can make an arbitrary decision to deprecate parameters in a widely used template, especially when that editor is eminently qualified to do so. |episodelink= and |serieslink= have been deprecated for more than a year. I suspect that that year, many, many others have read the documentation so you aren't the first to discover that |episodelink= and |serieslink= are deprecated. Consensus by editing, ne?

I guess you and I not only disagree about |episodelink= and |serieslink=, but we also disagree about what Editor Gadget850 believes.

As before, I haven't convinced you and you haven't convinced me, here we stand unresolved.

—Trappist the monk (talk) 16:46, 13 April 2013 (UTC)

I'm sorry, but that is not how Wikipedia works. Whether or not an editor thinks he "is eminently qualified to do so", if his edits are objected to, then you need to form a consensus to make such changes. An editor has made edits, they've been objected to, and the editor who made the edits has said "The parameters are still supported, so use them as desired". That's fairly clear to anyone, apparently except you. --AussieLegend (✉) 12:03, 14 April 2013 (UTC)

"What we've got here is failure to communicate." I did not not write, nor intend to imply, anything about what Editor Gadget850 thinks he "is eminently qualified to do..." (emphasis added). Please do not put words into my mouth that I have not spoken. It is my opinion that Editor Gadget850 is eminently qualified. Without the broader Wikipedia community's consent, Editor Gadget850 would not have been allowed to make the significant, and largely under-appreciated, changes necessary to coerce 23 or so disparate CS1 templates into a nicely coherent suite. That Editor Gadget850 did this work across all of the CS1 templates is tacit consensus else, long before now, those changes would have been opposed.

I wonder if there is a conceptual misunderstanding. There is a difference between deprecated and disallowed. I have never argued that editors are now prohibited from using |episodelink= and |seriesslink=. I have only argued that |episodelink= and |seriesslink= are, and rightly should be, deprecated.

—Trappist the monk (talk) 14:02, 14 April 2013 (UTC)

With this edit and then this you've effectively "prohibited" editors from using the parameters by removing them from the template skeletons, which misleads editors into believing they're no longer valid parameters. --AussieLegend (✉) 14:58, 14 April 2013 (UTC)

Hardly. Those edits are entirely consistent with deprecation. Use of |episodelink= and |seriesslink= is not expressly disallowed nor is it encouraged.

—Trappist the monk (talk) 16:30, 14 April 2013 (UTC)

Semantics. The lack of documentation for fields gives the clear impression that they're parameters that either don't exist or shouldn't be used. The documentation does not mention them under the heading "Deprecated", although all those parameters were deprecated after discussion. Please note that the section begins with the statement "These parameters are deprecated and will no longer work", a statement that links the terms "deprecated" and "non-functional" for the average reader. --AussieLegend (✉) 13:33, 16 April 2013 (UTC)

By definition, deprecated parameters either don't exist or shouldn't be used. The documentation clearly marks |episodelink= and |serieslink= as deprecated.

Yeah, the documentation could be better. I've just started work on that because the Citation Style 1 citations are in the process of the Lua upgrade.

—Trappist the monk (talk) 11:11, 17 April 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ |episodelink= and |serieslink= both exist and there's no reason why they shouldn't be used. Serieslink avoids the need for editors to manually link (semi-automation is always a good idea) and episodelink is needed for 117Avenue's suggestion below. Therefore, by your own definition, neither is deprecated. --AussieLegend (✉) 15:46, 19 April 2013 (UTC)

That outdent and your comments make it feel like we're starting all over again. I have stated why |episodelink= and |serieslink= should be deprecated. I'm not going to repeat myself ad infinitum.

While I might like to take credit for the defining deprecation, I can't, but thanks anyway.

I haven't convinced you and you haven't convinced me, here we stand unresolved.

—Trappist the monk (talk) 18:36, 19 April 2013 (UTC)

Yes, you've explained why you think the parameters should be deprecated, but you haven't shown how they are deprecated and your definition shows that they are not. Since you don't seem interested in continuing, I assume you don't have a valid opposition to restoring the documentation? --AussieLegend (✉) 11:43, 21 April 2013 (UTC)

• |episodelink= and |serieslink= exist;
• |episodelink= and |serieslink= are not disallowed;
• |episodelink= and |serieslink= are deprecated to standardize parameter usage across the CS1 suite of citations;
• |episodelink= and |serieslink= are deprecated because wiki markup in |title= and |series= makes them redundant;
• |episodelink= is deprecated because when used in a citation with |url=, the rendered citation is broken;

This whole conversation is about what you and I think. Neither of us has convinced the other to think differently. I'm perfectly willing to continue as long as there is something new and relevant to discuss. I'm not interested in discussion about the discussion.

—Trappist the monk (talk) 13:19, 21 April 2013 (UTC)

Lack of documentation gives the appearance that |episodelink= and |serieslink= are disallowed, especially to editors newly using the template, as they won't realise the parameters have ever existed. The argument about |episodelink= being deprecated because of the problem caused when |url= is supplied is specious. If |title= is linked the same error occurs, and it doesn't fail gacefully. Since "Neither of us has convinced the other to think differently", there's no WP:CONSENSUS for your edits that removed the documentation. Per WP:STATUSQUO the removed documentation should remain in the documentation until we can come to some agreement. --AussieLegend (✉) 09:12, 23 April 2013 (UTC)

Leaving deprecated parameters in the template skeletons is contrary to the stated purpose of the deprecation so I removed them. It is intended that new and experienced editors move away from |episodelink= and |serieslink=. Removing the parameters from the template skeletons is a form of gentle dissuasion.

It is true that using |episodelink= with |url= in the same citation breaks the rendered citation. That truth is not invalidated by arguing that identically broken citations can be created by other methods.

I will accept leaving |episodelink= and |serieslink= in the template skeletons if you will accept the addition of <!-- deprecated --> annotations in both of the template skeletons and deprecated; wikilink title instead and deprecated; wikilink series instead in the Brief instructions / notes column of the vertical template skeleton.

—Trappist the monk (talk) 12:02, 23 April 2013 (UTC)

It's not really a case of you accepting "if". WP:STATUSQUO, which has wide support, says "If you make an edit which is good-faith reverted, do not simply reinstate your edit - leave the status quo up. If there is a dispute, the status quo reigns until a consensus is established to make a change." However, I don't see a problem with the above changes. --AussieLegend (✉) 13:57, 23 April 2013 (UTC)

Trappist the monk, you are the only one saying that the parameters are depreciated, a status that can only be determined by a group of editors who monitor the template. They are useful, and should be fully documented. 117Avenue (talk) 04:48, 24 April 2013 (UTC)

There is a marketing ploy that advertisers use to help get people to buy their stuff. Essentially it says to prospective purchasers, "All of your friends have our <insert cool product de jour>, look how great their lives are now." That doesn't work with me irl and it won't work here.

—Trappist the monk (talk) 12:06, 24 April 2013 (UTC)

Wikipedia is a collaborative project, and templates and help pages like these are used to produce "a consistent look throughout the encyclopedia." (From this page.) "Wikipedia does not have a single house style. Editors may choose any option they want; one article need not match what is done in other articles". However, I feel that other users should not be discouraged to use parameters that many others have found helpful. Listing a template's parameter in the documentation does not make its use compulsory, and I apologize if my comments make it sound like I said that. 117Avenue (talk) 22:36, 27 April 2013 (UTC)

Arbitrary section break - Fix for when both url and episodelink are supplied

I should probably add my comments, since my name has been mentioned. But this conversation has gone on long, so I didn't read it, and don't know who has said what. The citation should link to both an external website, and the episode article when both parameters are supplied. The external website should have prominence, because this is a cite template, and Wikipedia shouldn't be referencing itself. However, if an article exists on the episode, it is additional information that should be in the cite, like a link to the author, work, or isbn in other cite templates. 117Avenue (talk) 03:13, 14 April 2013 (UTC)

I hadn't actually realised the problem existed until I found your proposal (now archived here) during this discussion, but the resolution seems to make sense. Personally, I'd prefer to see both the season and episode number linked (ie Season 4, Episode 19, but what you've proposed is an acceptable compromise. The template has been modified since you made your proposal,[5] so the output is slightly different from what the current template provides but, using the example that I've been using, that output is:

"Red-2". NCIS: Los Angeles. Season 4. Episode 19. March 26, 2013. 02:21 minutes in. CBS. http://www.example.com.

I don't see why this change shouldn't be incorporated into the template. Can you update the sandbox using the current version of the template? --AussieLegend (✉) 12:29, 14 April 2013 (UTC)

This is what the change would look like. It should be noted that the template is currently broken, when both are supplied the open quote mark links to the URL, and the title links to the article. 117Avenue (talk) 06:30, 15 April 2013 (UTC)

That looks good, and fixes the problem. I've checked a number of articles and haven't seen any adverse effects that would be caused. Is there any opposition to this fix? --AussieLegend (✉) 11:25, 15 April 2013 (UTC)

I notice that {{cite episode/sandbox}} doesn't fail gracefully if |episodelink= is defined and when both |series= and |number= are missing or blank.

"Red-2". NCIS: Los Angeles. . March 3, 2001. 02:21 minutes in. CBS. http://www.example.com.

—Trappist the monk (talk) 12:41, 15 April 2013 (UTC)

I'm not sure that's a bad thing. Bells and flashing lights should go off when |season= (not series) and |number= are omitted. They're not really optional parameters, which is something the documentation fails to address. --AussieLegend (✉) 13:25, 16 April 2013 (UTC)

Yeah, I agree that errors should be reported in unambiguously. The Lua versions of the Citation Style 1 templates do that rather nicely. What happens here is that the template's output is readable; all of the season and episode information is there so the eye simply scans over the wiki markup. Because editors expect the citation to show the season and number and they see the season and number in much the same form as they saw it in the edit window, all is good. This is why authors have editors.

—Trappist the monk (talk) 13:42, 16 April 2013 (UTC)

I believe other cite templates err when there is an odd combination of parameters like this, I think it's acceptable. 117Avenue (talk) 05:14, 17 April 2013 (UTC)

Then please don't fix any more templates. Wikipedia needs excellence, not mediocrity.

—Trappist the monk (talk) 10:26, 17 April 2013 (UTC)

I don't think that tone is appropriate. Please be more WP:CIVIL. --AussieLegend (✉) 10:35, 17 April 2013 (UTC)

Sur, Name. http://www.example.com. Retrieved 19 April 2013. 

and

"Example". Archived from the original on . 

is excellence? 117Avenue (talk) 03:49, 19 April 2013 (UTC)

For those citations, the error messages are Editor AussieLegend's bells and flashing lights [that] go off when [|title=] and [|archivedate=] are omitted. They embody Editor Gadget850's engineer, educate, enforce philosophy. The error messages are engineered to draw the editor's attention to the problem, to educate the editor (the help link) and enforce correct construction of citations using the templates.

So, yeah, excellence.

—Trappist the monk (talk) 10:13, 19 April 2013 (UTC)

While I agree with the outputs shown above, they're not up to my standards for bells and flashing lights. Unfortunately even the most obvious of errors often go unnoticed,[6] so actual bells and flashing lights, with an electric shock or two thrown in are what I'd like to see. However, I don't think 117Avenue's proposal is mediocrity. It's a reasonable proposal. I don't see anyone proposing anything better. --AussieLegend (✉) 15:41, 19 April 2013 (UTC)

It was probably some lawyer at WMF that made them disable {{editor chair zap}}.

I'm far from an expert in the arcana of the templating language (if one can call it that). But it appears to me that the episode link section of the template starts producing its output before it knows what inputs are available. If it determined that it didn't have all of the requisite inputs, the output should be {{citation error}}.

—Trappist the monk (talk) 18:36, 19 April 2013 (UTC)

I see two options for the output when these unique set of parameters are supplied. A. don't use the episode link, giving the external link prominence, as I suggested at the top of this section. Or B. display an error message using Template:Citation error, as Trappist the monk suggests, placing the article in a maintenance category. 117Avenue (talk) 03:31, 20 April 2013 (UTC)

I think "B" is a better option. It still gives |url= prominence but I think there may be a third option; C. make |episodelink= always tied to |season= / |seriesno= and |number=. If |url= is not specified, then the episode name will just be plain text. --AussieLegend (✉) 11:46, 21 April 2013 (UTC)

I don't think that will work. A user would supply a link to a source (episodelink) and a title, but if there is no episode number, nothing will be linked to. 117Avenue (talk) 23:10, 21 April 2013 (UTC)

Fair enough, "B" it is then. --AussieLegend (✉) 09:20, 23 April 2013 (UTC)

So, are we going to stall the discussion at this point, or are we going to agree to implement the fixes? --AussieLegend (✉) 10:45, 30 April 2013 (UTC)

I still got some more testcases to run it through, we want excellence right? 117Avenue (talk) 03:23, 2 May 2013 (UTC)

Yes we do and I can see that you have made significant progress in that direction. Well done.

—Trappist the monk (talk) 10:44, 2 May 2013 (UTC)

Edit request on 12 May 2013

As discussed above, to fix some glitches, as seen here, please sync Template:Cite episode with my latest revision of the sandbox. Thanks, 117Avenue (talk) 06:32, 12 May 2013 (UTC)

Y Done, I enjoyed reading the conversation above. — Martin (MSGJ · talk) 18:47, 12 May 2013 (UTC)

Authorformat parameter

A new parameter named authorformat was introduced during development of the LUA version. This allows the display of author names to be somewhat decoupled from how the name is entered, and provides consistency: I particularly requested it because some planned instances of {{cite doi}} were in places where different styles were required (I didn't edit-war, honest ;-).

Allowable values at present are:

• vanc which applies a "Vancouver-like" style: first parameters are reduced to a set of initials without full-stops; author parameters are left untouched to allow for names in different configurations
• scap which applies a small caps effect to each author

There is a corresponding parameter named editorformat which performs as one might expect on the corresponding editor-related parameters.

These parameters require documentation. I think the above is roughly correct text-wise, but needs formatting. If someone with more familiarity with how to navigate the tangled strands of the documentation templates can add it in the correct place, I would be obliged. HTH HAND —Phil | Talk 15:41, 17 April 2013 (UTC)

I don't think it is that tangled, except for just adding a 'lua' parameter to several of the doc sets so we can start documenting the updated templates. Regardless, these are display options, thus they belong in {{Citation Style documentation/display‎}}.

As new display features, what are the guidelines for their use? When would I use the Vancouver style, which already has a set of little-used templates as documented at Citation Style Vancouver? Ditto for small caps. --  Gadget850 (Ed) ^talk 15:58, 17 April 2013 (UTC)

I have been using them solely to make the display conform to existing practice while allowing me to record names properly: I have encountered some inexplicable hostility in the past from people who do not like their articles disturbed for the sake of conforming to some style or other which applies in the world outside Wikipedia. My intent is to record full names where possible so that prolific authors can be detected and articles created for them, same as for frequently-cited journals. HTH HAND—Phil | Talk 17:19, 17 April 2013 (UTC)

Isn't scap at adds with MOS:SMALLCAPS? --AussieLegend (✉) 17:24, 17 April 2013 (UTC)

Phil: My SWAG is this involves academic journals where the editors use first name initials and probably shorthand journal names? --  Gadget850 (Ed) ^talk 17:37, 17 April 2013 (UTC)

"SWAG"? Dragons flight (talk) 19:20, 17 April 2013 (UTC)

SWAG? -- John of Reading (talk) 19:43, 17 April 2013 (UTC)

Yes. Learned that one in my first technical job. --  Gadget850 (Ed) ^talk 19:55, 17 April 2013 (UTC)

Pretty much, yes, it involves those who think that simply copying and pasting the names into a single authors parameter is better than splitting them out into individual entries and investigating the possibility of linking them to an appropriate article, because it conforms to a style used by certain (but not all) publications which have no actual bearing on how we do anything here on Wikipedia. Sorry, but if I sound jaded and bitter, it's the number of years I have wasted on this kind of "discussion" when we could have been collecting and storing useful data. HTH HAND —Phil | Talk 20:36, 17 April 2013 (UTC)

What I would like to see is a way to specify the authors' first and last names using the first?= and last?= parameters, but still display them in the format typically used in the author= parameter: "firstname lastname" etc. Splitting the name into first and last names is a good idea for sorting and searching, however, this should be decoupled from a certain display style. One scenario, where it might be useful to force the template to display the name in "firstname lastname" order despite being given using first= and last= parameters, is when the majority of the other references in an article use this style. Also, in the long run, it might be useful to make this configurable in order to allow registered users to specify the desired display order in their personal preferences. It looks like this new authorformat= parameter would be a good place to add this kind of configurability. --Matthiaspaul (talk) 00:48, 21 April 2013 (UTC)

CS1 uses last, first. What would you call this style set? --  Gadget850 (Ed) ^talk 11:34, 21 April 2013 (UTC)

Hm, perhaps something trivial like natural (assuming "firstname lastname" is the natural order to write names in Western locales). --Matthiaspaul (talk) 12:31, 21 April 2013 (UTC)

For Citation Style Natural, we will need a help page to define it and a list of the new templates. --  Gadget850 (Ed) ^talk 12:36, 21 April 2013 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ To get closer to the "Vancouver-like" style, one also needs to add author-separator and author-name-separator parameters:

• | authorformat = vanc | author-separator=, | author-name-separator =  

This syntax seems unnecessarily verbose. In my opinion, if "authorformat = vanc" is specified, then author-separator and author-name-separator should also be automatically set as above without having to explicitly include these two parameters. Thoughts? Boghog (talk) 06:39, 30 April 2013 (UTC)

URL is not parsed correctly

Turner Classic Movies is formatting URLs with a pipe (|), as in this example:

http://www.tcm.com/this-month/article/288806%7C288845/The-Big-Idea-My-Darling-Clementine.html

which is causing URLs to break in citations, as in the example shown for citation 5 here. — btphelps ^{(talk) (contribs)} 16:39, 18 April 2013 (UTC)

You need to encode it per Template:Cite web#URL. --  Gadget850 (Ed) ^talk 16:44, 18 April 2013 (UTC)

That should probably be mentioned at Help:Citation Style 1#Special characters but isn't. Dragons flight (talk) 16:52, 18 April 2013 (UTC)

Done. Could we encode the URL? I know we can't do the pipe. At least this will give an error when we make this one visible. --  Gadget850 (Ed) ^talk 17:01, 18 April 2013 (UTC)

That help text now includes a first line that describes the URI scheme. Is Special characters the right place for that snippet of text?

—Trappist the monk (talk) 17:24, 18 April 2013 (UTC)

Not precisely, but I used a template to keep the text the same across several pages. The page needs some work, especially regarding the updates. I could add a conditional to the template. --  Gadget850 (Ed) ^talk 17:39, 18 April 2013 (UTC)

Because of the way percent encoding is defined in the URI spec it is not universally safe to always encode any of the URI reserved characters !*'();:@&=+$,/?#[]. If you always encode (or never encode) those, then you are guaranteed that some population of URLs that are valid per spec will fail. We could try encoding characters that have Mediawiki significance such as <> and space (" ") but lack URI significance. I think that would work. Or at least it will work as long as people haven't been intentionally embedding things like " " or [] in their citation URLs with the intent of exploiting the Mediawiki meaning. As an aside, I'm not sure it is ever possible to use [] in a Mediawiki based URL in the way that the URI spec intends (IP address delimiters), though on the other hand, I've never seen a valid URL that actually used [] for their spec meaning, so it might be okay to encode those as well. Dragons flight (talk) 17:48, 18 April 2013 (UTC)

section parameter missing

The parameter "section" from {{cite news}} now shows as an error. Please fix it.--Auric talk 12:26, 21 April 2013 (UTC)

There is no 'section' parameter, which is why the error is displayed. What article? --  Gadget850 (Ed) ^talk 12:30, 21 April 2013 (UTC)

Previous advice (not necessarily on this page) has been to use the |at= parameter, for example |at=sec. B p. 28 col. 3 --Redrose64 (talk) 14:39, 21 April 2013 (UTC)

That results in an Extra |pages= or |at= error.--Auric talk 21:23, 21 April 2013 (UTC)

Can you tell us where this citation is or put a copy of it here?—Trappist the monk (talk) 21:49, 21 April 2013 (UTC)

Here's a random article: Aurora Community Channel.--Auric talk 21:56, 21 April 2013 (UTC)

It doesn't result in an error if you put the page number inside the |at=, as shown in my example. --Redrose64 (talk) 21:54, 21 April 2013 (UTC)

Replace the |section=Property - Commercial Property |page=18 with |at=Property - Commercial Property section, p. 18 --Redrose64 (talk) 22:00, 21 April 2013 (UTC)

That works. Thanks for the clarification.--Auric talk 22:07, 21 April 2013 (UTC)

Or use |department=, if "Property - Commercial Property" is a regular department of the newspaper, and return to |page=:

{{cite news |newspaper=[[The Sydney Morning Herald]] |title=Leasing Ladder |page=18 |department=Property - Commercial Property |date=17 July 2010 |accessdate=25 October 2010 |url=http://newsstore.fairfax.com.au/apps/viewDocument.ac?docID=SMH100717BGA2B40LRQ7}}

→"Leasing Ladder". Property - Commercial Property. The Sydney Morning Herald. 17 July 2010. p. 18. Retrieved 25 October 2010. 

—Trappist the monk (talk) 22:16, 21 April 2013 (UTC)

Very weirdly, I've happened across several examples of |section= being used in {{cite news}} and {{cite web}} in the past. I discovered another today.[7] --AussieLegend (✉) 14:03, 23 April 2013 (UTC)

Looks like that one could have used 'department', a parameter I added July 2012. --  Gadget850 ^talk 14:07, 23 April 2013 (UTC)

It works, but it doesn't seem a "natural" parameter. "Department" seems more related to departments in a department store or, for example, the service department in a car dealership. It doesn't really seem right in a newspaper. --AussieLegend (✉) 16:27, 23 April 2013 (UTC)

I initially proposed 'column' but it was thought that it might be confusing. We also discussed 'section' with the same conclusion. I then consulted Chicago 16 where 'department' was used.[8] --  Gadget850 ^talk 00:14, 24 April 2013 (UTC)

Cite book, at= should not be overridden by page=, simultaneous use should not be an error

The documentation for cite book (Template:Cite_book/doc#In-source_locations) shows that at: is used where page= is inappropriate or insufficient. If page= is insufficient (meaning necessary but not sufficient), then at: should not be overridden by page=, IMHO, nor should simultaneous use of the pair constitute an error. Example: page=234| at=Table 3.23 where six tables are present on a page. In my opinion, the sensible use of these params is a matter for editor discretion and discussion, not a hard and fast rule encoded in software. --Lexein (talk) 03:36, 22 April 2013 (UTC)

This has been covered several times before (not necessarily on this talk page). If the whole table is on page 234, use |at=p. 234, table 3.23 if the table spans more than one page and the pertinent information is only on page 234, use |at=Table 3.23, p. 234 In either case, omit |page= --Redrose64 (talk) 10:07, 22 April 2013 (UTC)

Seems not to be covered in the documentation, else I wouldn't have asked. That would be good. --Lexein (talk) 15:31, 22 April 2013 (UTC)

The "OR" before 'pages' and 'at' weren't sufficient? And the "Overridden by". --  Gadget850 (Ed) ^talk 15:40, 22 April 2013 (UTC)

Whoosh. Did I touch a nerve? Are you a documentation minimalist or something? Good grief. Examples, examples, examples. Such as those good ones suggested by Redrose. Not difficult. --Lexein (talk) 15:58, 22 April 2013 (UTC)

What can we do to make the documentation better? Sorry. --  Gadget850 (Ed) ^talk 18:20, 22 April 2013 (UTC)

I think a short table of examples is a good idea. Such as

Use case	Syntax	Display
Single page	|page=24	p. 24
Range of pages	|pages=24-38	pp. 24–38
List of pages	|pages=13-24, 28, 37	pp. 13–24, 28, 37
Unnumbered location	|at=Back Cover	Back Cover
Numbered location that is not part of a numbered page	|at=Table 2.3	Table 2.3
Specific subsection of a numbered page	|at=p. 23, Table 2.3	p. 23, Table 2.3

Dragons flight (talk) 18:41, 22 April 2013 (UTC)

Lets say we allow 'at' and 'page'. What do we put into the COinS rft.pages key? Do we ignore 'at' and just include 'pages'? Or do we combine them and guess at the intended order? --  Gadget850 (Ed) ^talk 11:01, 22 April 2013 (UTC)

Oh no! An unhandled case! This comes from overconstraining, and worrying about creating code, where, as I've indicated elsewhere, discretion and discussion completely address issues attempting to be solved by code. Sorry. --Lexein (talk) 15:31, 22 April 2013 (UTC)

It is handled. Pick one of the three parameters. What is your specific alternative that allows us to properly support COinS? Sorry. --  Gadget850 (Ed) ^talk 15:40, 22 April 2013 (UTC)

I agree that |at= should not be overridden by |page= (or vice versa). There are cases where it is very handy to have both page numbers and (e.g.) section numbers. But combining them in |at= is objectionable, as it breaks the metadata association. I don't know what COiNS wants, but if it asks for "pages" then probably that is what it should be given, not "at".~ J. Johnson (JJ) (talk) 23:20, 22 April 2013 (UTC)

It has always been the case that using |page= or |pages= will cause |at= to be ignored. That said, we could change it. What syntax would you suggest, e.g. "p. <PAGE>, <AT>"? The examples above aren't entirely consistent since one example goes essentially "<AT>, p. <PAGE>". One could also imagine a number of other variations using colons or parentheses as separators for example. Dragons flight (talk) 23:35, 22 April 2013 (UTC)

I propose we show 'at', 'page' and 'pages' and ignore rft.pages. --  Gadget850 (Ed) ^talk 23:47, 22 April 2013 (UTC)

We don't presently simultaneously show both 'page' and 'pages', and surely that behavior can and should be kept. Right? As to rft.pages, I am not acquainted with where and how it displays; perhaps you would favor us with an explanation? ~ J. Johnson (JJ) (talk) 00:02, 23 April 2013 (UTC)

We also don't show 'at' if 'page' is defined. You want to define and show both 'page' and 'at'. There are a lot of folks who are defining both 'page' and 'pages', so we should accommodate them as well, thus show all three. rft.pages is a COinS key. It does not show, but someone with reference management software like Zotero can scan the page and copy all the references into a database. They can then reuse those references elsewhere. Currently, one of the three in-source location fields ('at', 'page', 'pages') is inserted into the rft.pages key. I think we should just ignore rft.pages and not use it. --  Gadget850 (Ed) ^talk 00:10, 23 April 2013 (UTC)

In fact, this is over constrained. We should add parameters for 'act', 'back cover', 'book', 'canto', 'colophon', 'column', 'dust jacket', 'folio', 'hours', 'indicia', 'liner notes', 'minutes', 'paragraph', 'part', 'scene', 'seconds','section', 'stanza', 'track', 'verse'. Did I miss anything? --  Gadget850 (Ed) ^talk 00:37, 23 April 2013 (UTC)

I think you forgot table, figure, code listing, subsection, theorem, lemma, corollary, definition, observation, and equation. Probably a few others besides... —David Eppstein (talk) 02:24, 23 April 2013 (UTC)

Two of the three parameters are merely format specifiers that aid editors in getting the format right. That leaves |at= which allows for free-form specification of any kind of locator – but, the editor has to take care to use the proper p. or pp. for the rendered citation.

I suspect that |page= and |pages= by far outnumber |at= in citations. That would suggest that |at= should rank lowest in the hierarchy.

If I understand the definition of rft.pages, it will take any kind of in-source locator description. That being the case then, keep it.

So, this editor, who is constantly arguing for change, really doesn't see much need for change here. Perhaps inclusion of the example table and a bit of rewording in the documentation (though, I don't find it ambiguous or hard to understand) is in order.

—Trappist the monk (talk) 01:17, 23 April 2013 (UTC)

(Are you constantly arguing for change? Ah. Didn't know that.) I'm not opposed to filling in |at= with page and other detailed location, but (with Johnson, above) I feel a tug at the loss of metadata association. By the way, all, my concerns are completely addressed by better examples, and I appreciate Dragons flight's table, whatever fine tuning might be considered needed there. --Lexein (talk) 03:12, 23 April 2013 (UTC)

Ed, you seem to be feeling unusually grumpy. No, we don't need all those other specific identifiers, as |at= is generic, and can be used for all those. We do have the specific page/pages parameters because that is by far the most common form of "at". What we are asking is why "at" is essentially not allowed when page/pages is specified.

As to having separate |page= and |pages=, I think that is justified for ensuring that "p." or "pp." results, as trying to determine that in software is problematical. That people use both is probably an error (which I see gets flagged as such), where they consider 'pages' to be the page range (say of an article in journal) and 'page' to be the specification (the particular page where the material cited is to be found). As far as that goes, I would have 'pages' override 'page' within cite and citation, the more inclusive term likely being the more appropriate for a full reference. (And reversed in {{harv}} for p/pp, as a short cite should be as specific as possible.) ~ J. Johnson (JJ) (talk) 23:34, 23 April 2013 (UTC)

Citation error query

This edit to Pi showed up on my watchlist, and I'm wondering if that was the correct resolution.

It seems to me that the citation templates could do something sexy and mark up the title in italics with the lang attribute set according to the definition in the template of the language of the document. Alternatively, we could add a new parameter for "title-language", to take an ISO code language letter code compliant, to do the same thing.

Just tossing some thoughts out there. Let me know if I'm way off. :) --Izno (talk) 20:01, 24 April 2013 (UTC)

See Module talk:Citation/CS1/Feature requests#Language. --  Gadget850 ^talk 11:31, 27 April 2013 (UTC)

Even with the |nocat=true, {{lang}} introduces content into the WP:COinS metadata that does not belong there. Specifically, with {{lang}} the COinS title metatdata looks like this:

&rft.btitle=%3Cspan+lang%3D%22la%22+%3EElementa+Trigonometrica%3C%2Fspan%3E

without {{lang}} the COinS title metatdata looks like this:

&rft.btitle=Elementa+Trigonometrica

The correct resolution, for the time being, is to remove {{lang}} from |title=. As Editor Gadget850 has pointed out, and integrated solution to the language issue is needed.

—Trappist the monk (talk) 13:13, 27 April 2013 (UTC)

Template:Cite web#Title Unclear

Says: "title: Title of web page." Maybe clarify that this is about the <title>, or - if it's not - the article title on the web page, or that the Wikipedia editor should pick the one that fits best if the <title> and article title on the web page are different. What if, for example, the <title> says "My Website" and the article title on the web page is "Ten ways to improve your memory" (or vice versa)? What if the <title> says "Best way to lose weight" and the article title on the web page says "Why Ireland has no snakes"? --82.170.113.123 (talk) 17:50, 28 April 2013 (UTC)

Changed to "Title of source page on website". Also moved the note about linking to 'title' where it belongs. --  Gadget850 ^talk 18:10, 28 April 2013 (UTC)

Thanks. A question, merely out of curiosity and this is purely hypothetical... if, for example, the title is "My Website" and the article title on the web page is "Ten ways to improve your memory", and I want to use the page as a reference/source for text somewhere on, say, the Memory page, I should literally add "|title=My Website" as part of the cite web? --82.170.113.123 (talk) 18:20, 28 April 2013 (UTC)

I'd use whichever will be most helpful to the person reading the Wikipedia article. -- John of Reading (talk) 19:19, 28 April 2013 (UTC)

There is a reason that CS1 has |title= and |website= (aka |work=). In IP Editor's example, the citation is:

{{cite web |url=http://example.com |title=Ten ways to improve your memory |website=My Website |accessdate=2013-04-28}}

→"Ten ways to improve your memory". My Website. Retrieved 2013-04-28. 

Essentially, this is much like citing a chapter in a book:

{{cite book |chapter=Ten ways to improve your memory |title=My Website}}

→"Ten ways to improve your memory". My Website. 

—Trappist the monk (talk) 19:32, 28 April 2013 (UTC)

That's just because of my example though. What about the other example I gave, where the title doesn't say "My Website" but another relevant text that isn't about the website in general. See, cite web is used a lot throughout Wikipedia, so maybe a broader discussion about this is desirable? Because I agree with what John of Reading writes about whichever will be most helpful, but because of my comments here the official text now says "Title of source page on website"... --82.170.113.123 (talk) 19:36, 28 April 2013 (UTC)

Example please? My intial thought is that any website that does not clearly identify itself may not be a good source. Do we need further instruction on how to identify the title of a website? --  Gadget850 ^talk 20:15, 28 April 2013 (UTC)

[9], [10], [11], [12] - examples where the displayed page title was preferable to the hidden HTML title. -- John of Reading (talk) 20:39, 28 April 2013 (UTC)

I didn't have any trouble finding page titles and website names for any of those citations except for Melling, and that citation (such as it is) hardly supports the claim in the article.

"J.D. Chakravarthy Profile". Telugu Movie Talkies. Retrieved 2012-09-15.  – changed |publisher= to |website=;

David Melling - Author-Illustrator – this, to me should get {{failed verification}}; readers should not have to hunt for whatever was cited;

"Minister for Economics – Daniels Pavļuts". The Cabinet of Ministers of the Republic of Latvia. 1976-05-14. Retrieved 2012-08-11.  – deleted |publisher=, split old |title= into |website= and |title=, added Minister for Economics

"Management plan". Eravikulam National Park. 

—Trappist the monk (talk) 21:25, 28 April 2013 (UTC)

So from these examples can I infer that you happy for the citation not to copy the HTML "<title>" element from the cited web page, in cases where other text from the page makes the citation clearer for the reader? I think that was the OP's point. -- John of Reading (talk) 09:34, 29 April 2013 (UTC)

Yep. I am happy for an editor to find and use a human readable/understandable title. <title> may be a perfectly good title source for whatever bots go around seeking such things, but human editors know better than bots what is appropriate for |title=. As far as I can determine by looking back through the {{cite web/doc}} history, <title> has never been required nor even recommended as the value to be used with |title=.

However, editors should not be inventing titles which implies that <title> may have to be used regardless of how strange it may be.

—Trappist the monk (talk) 12:56, 29 April 2013 (UTC)

So, that was it, I guess. It'll say "title: Title of source page on website" until someone else brings it up again. --82.170.113.123 (talk) 17:28, 1 May 2013 (UTC)

Did you have another suggestion? --  Gadget850 ^talk 17:45, 1 May 2013 (UTC)

I'm not a native English speaker, but what I have in mind is something like "Relevant text between the <title> and </title> tags (the title in the browser toolbar), or, if more appropriate and helpful to readers of the Wikipedia article, the ...". Something that: 1. prevents editors from thinking they can inventing a title, 2. more clearly explains what the first option is (not "Title of source page on website" but show the < and > symbols and mention the word "tag" and say it is the title in the browser toolbar), and 3. also makes clear that using the main title on the web page itself is allowed/preferable if the <title> isn't very usable. --82.170.113.123 (talk) 18:45, 1 May 2013 (UTC)

I think it's appropriate to allow editors some discretion in choosing which title to use: it could be the text in the title tags, it could be the text in the most significant titling tag of the rendered page, or it could be some substring of those. I don't think requiring it to match the full title tag text is a good idea. Another case that frequently comes up is that the title tag text includes the name of the larger web site within which the page exists, which we would normally put into the |work= parameter. In that case, what we put into the title should be the rest of the title tag text, not including the work part. (Example: this page should have |title=Archimedean Solid and |work=MathWorld, not |title=Archimedean Solid -- from Wolfram MathWorld.) —David Eppstein (talk) 19:04, 1 May 2013 (UTC)

(edit conflict)Discerning the title of a web page or site may require some judgment. The <title> can be useful but may contain other information. For example, the <title> for this page is "Help talk:Citation Style 1 - Wikipedia, the free encyclopedia". It is obvious that this includes both the page and site titles and a description, but any automated tool is going to have trouble. --  Gadget850 ^talk 19:13, 1 May 2013 (UTC)

I can't edit Template:Cite web#Title, plus I'm not a native English speaker. If anyone feels like improving that's on the page, after the discussion in this thread, please go fo it. Thanks. --82.170.113.123 (talk) 17:02, 4 May 2013 (UTC)

Template:Cite web is protected, but Template:Cite web/doc is not. --Redrose64 (talk) 17:21, 4 May 2013 (UTC)

Discussion regarding the usage and cleaning of accessdate

I've started a wider community discussion at Wikipedia:Village pump (policy)#Use of accessdate in citation templates about the appropriate usage of the |accessdate= parameter and what steps (if any) should be taken to clean it up. I invite your comments at that page. Dragons flight (talk) 03:57, 29 April 2013 (UTC)

How to give author names in different scripts?

We need a parameter for reporting author name in different script (Chinese, Japanese, Korean, Cyrillic, etc.). This is the best I was able to do, and it is obviously not good enough. Giving author names in latin and originals script seems to me as important as translating the title. Ditto, btw, for publisher. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 03:57, 30 April 2013 (UTC)

• The wp:CS1 cites allow any text in author, title or publisher parameters: Feel free to show other-language text, along with the related English text, in those parameters of the wp:CS1-style cites. However, the title data can be placed into dual parameters, as "title=" for original and "trans_title=" for the English equivalent (or also "chapter=" with "trans_chapter="), but the author names can be combined as in "author2=Jonéiè Doeyåviçnoыfu (John Doe)" with the option "ref=Doe1998" to set author-year links by any spelling of the author names. Some text can be offset within square brackets "[__]" but perhaps encode them as &#91; ("[") or &#93; ("]") to avoid temptations to double-link "[" or "]" in the text. Yet, there has been a design flaw where the trans_title is also linked to the URL, causing wikilinks to be rejected in the trans_title text, and so it should no longer be in the external link [http:...] to "url=" addresses. In general, people have tried to avoid too many new parameter names, which would tend to confuse new users, and also slows the template processing. In fact, the rapid markup Template:Cite_quick (which handles only 50-60 major cite parameters) sometimes runs slightly faster, and allows more templates (omitting COinS metadata), than some of the Lua-based wp:CS1 templates, when numerous parameters are passed into citations. The slowdown seems to be related to the MediaWiki parser having exponentially-slower processing to pass additional parameters, and templates can run faster with data combined into fewer parameters. It is a complex problem, where passing the 99th parameter, seems to require re-processing the first 98 parameters, or such, perhaps to check reuse of prior parameter names, as accumulated slowdown. So, a template with 4,000 parameters runs much slower (4x?) than 2 templates of 2,000 parameters each, such as selecting among lists of thousands of entries. Even changing a template of 200 parameters, into 2 of 100-parameters-each, can run 30% faster by calling 2 rather than 1 template! Anyway, feel free to put multiple-language data into the various current cite parameters. -Wikid77 16:48, 19 May 2013 (UTC)
• See the first two sections at Module talk:Citation/CS1/Feature requests. --  Gadget850 ^talk 17:02, 19 May 2013 (UTC)

'Cite web' used more than once.

How to use

Could you please help me with the situation that a 'cite web' is used for more than once? How to shorten the cite? Thanks, New worl (talk) 08:55, 30 April 2013 (UTC)

This is covered at WP:NAMEDREFS. --Redrose64 (talk) 09:14, 30 April 2013 (UTC)

For example, I'd like to use this source more than once. What should I type specifically? Thanks, New worl (talk) 09:24, 30 April 2013 (UTC)

Change the <ref>{{cite web ... }}</ref> to <ref name="Vatican guesthouse">{{cite web ... }}</ref> and then later on you can put <ref name="Vatican guesthouse" />

Markup	Renders as
Pope Francis does not live in the Papal apartments.<ref name="Vatican guesthouse">{{cite web |url=http://ncronline.org/news/vatican/pope-francis-live-vatican-guesthouse-not-papal-apartments|title=Pope Francis to live in Vatican guesthouse, not papal apartments|first=Cindy |last=Wooden|date=26 March 2013 |accessdate=26 March 2013|work=[[National Catholic Reporter]]}}</ref> Something else about the Pope. The Pope lives in the Vatican guesthouse.<ref name="Vatican guesthouse" />	Pope Francis does not live in the Papal apartments. Something else about the Pope. The pope lives in the Vatican guesthouse.

The part of the name= inside the quotes can be almost anything you like, but must be unique within the article. --Redrose64 (talk) 09:48, 30 April 2013 (UTC)

Thanks Redrose64 very much. New worl (talk) 10:55, 30 April 2013 (UTC)

I like to use author date. In this case wooden2013. --  Gadget850 ^talk 12:16, 30 April 2013 (UTC)

Thanks Gadget850 for the nice tip. New worl (talk) 13:32, 30 April 2013 (UTC)

A shortcut to insert 'Cite web'

Could you please let me know if we have a shortcut to insert 'Cite web'? I'm new so any shortcut is very helpful. Many thanks, New worl (talk) 11:05, 30 April 2013 (UTC)

Just above the edit box you should have a strip of buttons and menus which looks like the example that I've added here. The right-most drop-down menu, "Cite", should have the function you require. I don't use it myself; but there is more at Wikipedia:RefToolbar/2.0. --Redrose64 (talk) 11:48, 30 April 2013 (UTC)

Oh, got it. Many thanks, Redrose64. New worl (talk) 11:59, 30 April 2013 (UTC)

Also ProveIt GT. --  Gadget850 ^talk 10:15, 1 May 2013 (UTC)

Wikipedia:VisualEditor

I just heard of Wikipedia:VisualEditor. Do you know if it will replace "Cite web", < ref >, etc. at least for editors with limited coding experience? Many thanks, New worl (talk) 12:04, 30 April 2013 (UTC)

It's a new front-end, offering different means for entering everything from italics and links to references, but the underlying Wikicode will remain the same. I shan't be using it myself: I dislike WYSIWYG web editors, since they always produce code bloat (Microsoft FrontPage was a particularly horrendous example). --Redrose64 (talk) 13:05, 30 April 2013 (UTC)

Thanks Redrose64. I think you are right. The problem is that it is not easy to have a common tool for all because there are so many preferences, strengths, etc. amongst individual editors. New worl (talk) 13:23, 30 April 2013 (UTC)

Cite-web#language

I think that it would be more reasonable to display the specified language just after the title but not after the "website" field. The reason is that we specify the language of the particular page, but currently a reader may think about it as the language of the whole web-site which may have a different language generally. --DixonD (talk) 18:38, 1 May 2013 (UTC)

I'm not sure that moving the language element is necessary. Doesn't the reader know that the leftmost element in the citation is the thing to which every element to the right refers? In the case of a {{cite book}} citation to a chapter, |title=, |publisher=, |date=, |page=, |language=, etc all refer to the value in |chapter=.

—Trappist the monk (talk) 13:03, 3 May 2013 (UTC)

Proposal for comment parameter

I would like to suggest the introduction of a comment= parameter to the various {{Cite}} templates. (The equivalent templates in the German WP have a similar kommentar= parameter already.) This could be displayed at the end of the cite info similar to quote=, but perhaps in a smaller font or framed with "(NB. ...)", "(Note: ...)" or something similar.

The rationale for such a parameter is that it is sometimes necessary or helpful to comment on a provided source, for example, if some information in a source is used as a reference, but other information in the source is known to be false or misleading, or if there is a typo in the title, the author's name or other bibliographic data, or if something else needs to be explained about the reference, which does not belong into the article's text, but could confuse or mislead a reader, if not mentioned at all while using the reference.

While it is possible to provide this information inside the <ref> environment, but outside the {{cite}} template, having a dedicated parameter for it would help to bring such comments into a stringent format and improve maintainability in the future.

Thanks. --Matthiaspaul (talk) 23:20, 2 May 2013 (UTC)

Editors in addition to authors

Apparently, when you use the template to cite a book that has an author and an editor, it assumes it's a work in an edited volume. Which is to say, in the citation, it puts it as "[Author name]. In [Editor name]..." Is there a way to correct this so it reads "[Author]. Book title. Edited by [Name]", as is the standard per CMoS? Or do I need to scrap the template and just enter it by hand? Parsecboy (talk) 20:22, 5 May 2013 (UTC)

There is some discussion of this issue at this topic above. Can you provide an example of the problem citation?

—Trappist the monk (talk) 20:28, 5 May 2013 (UTC)

I can provide one:

• Forster, Edith C. (1951). In Norris, Joe L. Yesterday's Highways: Traveling Around Early Detroit. Detroit: Wayne State University Press. OCLC 3324319. 

Ms. Forster wrote the book and Mr. Norris is credited with editing it. Imzadi 1979 → 20:53, 5 May 2013 (UTC)

This comparison suggests that Module:Citation/CS1 acts differently from {{citation/core}}. I have tweaked Module:Citation/CS1/sandbox so that if there is a date, 'In' is omitted and 'ed.' or 'eds. is appended. No doubt the way I accomplished this is crude and inept and I expect Editor Dragons flight shudder and then make it right or revert.

{{ cite book | editor-last=Norris | first=Edith C. | last1=Forster | year=1951 | publisher=Wayne State University Press | oclc=3324319 | editor-first=Joe L | location=Detroit | title=Yesterday's Highways: Traveling Around Early Detroit }}
Old	Forster, Edith C. (1951). Norris, Joe L. ed. Yesterday's Highways: Traveling Around Early Detroit. Detroit: Wayne State University Press. OCLC 3324319.
Lua	Forster, Edith C. (1951). In Norris, Joe L. Yesterday's Highways: Traveling Around Early Detroit. Detroit: Wayne State University Press. OCLC 3324319.
Sandbox	Forster, Edith C. (1951). Norris, Joe L. ed.Yesterday's Highways: Traveling Around Early Detroit. Detroit: Wayne State University Press. OCLC 3324319.

—Trappist the monk (talk) 22:28, 5 May 2013 (UTC)

Imzadi1979, please explain why you want to cite both the editor and the author. Ordinarily only the author is cited. Amazon has a picture of the book cover, and only the author is listed on the cover. What's so unusual about this editor? Jc3s5h (talk) 23:05, 5 May 2013 (UTC)

I pulled the citation information out of http://www.worldcat.org/title/yesterdays-highways-traveling-around-early-detroit/oclc/3324319 which is crediting both of them. Imzadi 1979 → 23:08, 5 May 2013 (UTC)

A library catalog is different from a citation and there is no reason to put every bit of information from a library catalog into a citation. Jc3s5h (talk) 23:21, 5 May 2013 (UTC)

Full date not showing in "cite web" template

The {{cite web}} template automatically generated from the "Templates" menu above the edit box appears to be operating incorrectly. Currently, it has separate provisions for "date", "month" and "year". Entering these as separate elements produces this tag:

<ref>{{cite web|title=Golden Era Records|url=https://www.facebook.com/permalink.php?story_fbid=10151597119869292&id=19129474291|work=Facebook|date=6|month=May|year=2013|accessdate=6 May 2013|quote=Head over to Hilltop Hoods page and wish Suffa a Happy Birthday!}}</ref>

Unfortunately, only the "date" (i.e., 6) is shown in the citation in the article; the "month" and "year" are ignored.

"Golden Era Records". Facebook. 6. Retrieved 6 May 2013. "Head over to Hilltop Hoods page and wish Suffa a Happy Birthday!"

The solution is to enter the full date (i.e., 6 March 2013) in the "date" field and leave the "month" and "year" fields blank, but this is somewhat counter-intuitive. Why are the other boxes there? —sroc (talk) 02:24, 6 May 2013 (UTC)

Per the documentation:

• date: Full date of source being referenced in the same format as other publication dates in the citations. Do not wikilink. Displays after the authors and enclosed in parentheses. If there is no author, then displays after publisher.
• OR: year: Year of source being referenced.
  • month: Name of the month of publication. If you also have the day, use date instead; do not wikilink.

This was implemented this way because of limitations in the #time parser function. --  Gadget850 ^talk 02:35, 6 May 2013 (UTC)

Can't really speak to the functionality of the templates tool you are using because it is not part of CS1. The citation that it created acts the way it does because |year= is a synonym of |date=. In the citation, |date= has priority over |year=. If |date= is not present but |month= and |year= are, then CS1 will concatenate them to make a date field.

The |day= parameter is deprecated and |month= is likely to be deprecated. Use |date= and ignore |month= and |year=

—Trappist the monk (talk) 02:42, 6 May 2013 (UTC)

Thanks, Trappist the monk. I'm remember this from now on and will try to patch up my past mistakes with this one. I've raised this at Wikipedia talk:RefToolbar#Dates in cite templates so hopefully this can be fixed to avoid others following in my folly. —sroc (talk) 02:48, 6 May 2013 (UTC)

It's happened again! I was beginning to think that the problem of posts to the same thread causing the other's post to disappear had been resolved. Apparently not. I have restored Editor Gadget850's post.

—Trappist the monk (talk) 03:06, 6 May 2013 (UTC)

"eds." not appearing in cite encyclopedia template

Can anybody tell me why "eds." is not appearing after the editor names in the output from this citation:

{{cite encyclopedia | last = Langrand| first = Olivier | editor-last = del Hoyo | editor-first = Josep | editor2-last = Elliott | editor2-first =Andrew | editor3-last = Sargatal| editor3-first =Jordi | title = Family Brachypteraciidae (Ground-rollers) | encyclopedia = [[Handbook of the Birds of the World]] | volume = 6. Mousebirds to Hornbills| publisher = Lynx Editions | location = Barcelona | year = 2001| isbn=84-87334-30-X|ref=harv}}

Output: Langrand, Olivier (2001). "Family Brachypteraciidae (Ground-rollers)". In del Hoyo, Josep; Elliott, Andrew; Sargatal, Jordi. Handbook of the Birds of the World. 6. Mousebirds to Hornbills. Barcelona: Lynx Editions. ISBN 84-87334-30-X. 

Thanks, Sasata (talk) 21:29, 8 May 2013 (UTC)

• Per the documentation:
  • If authors: Authors are first, followed by the included work, then "In" and the editors, then the main work.
  • If no authors: Editors appear before the included work; a single editor is followed by "ed."; multiple editors are followed by "eds."; exactly four editors will show three editors followed by "et al., eds."

--  Gadget850 ^talk 00:14, 9 May 2013 (UTC)

• Thanks; I obviously didn't read the documentation carefully enough. Sasata (talk) 16:33, 10 May 2013 (UTC)

"Googlebooks" parameter

Replacing {{Google books}}, could some please add a googlebooks parameter to {{cite book}} (or whatever sub-template is affected), that creates a link to, well, Google Books? Similar to JSTOR and others, it should look like |googlebooks=8jHiEwVmB8MC and produce something like "Google Books 8jHiEwVmB8MC", or just "Google Books". Thanks. --bender235 (talk) 09:55, 10 May 2013 (UTC)

I just insert the courtesy link to the item at Google Books into |url= along with the full citation information for the print edition that's really being cited. Imzadi 1979 → 16:41, 10 May 2013 (UTC)

Putting in the whole google url is unsatisfactory in several regards. It tends (by default) to disclose the country tld from which the editor is editing. Also it includes information about his browsing choices, etc. that is at best useless to other readers. The only useful things in the whole (often very long) url are the id and the page numbers. LeadSongDog come howl! 17:19, 17 May 2013 (UTC)

Should make it as easy as possible to see refs when available. In fact we have a tool to help with the problems you describe above see - Google book tool Coverts bare url into {{cite book}} format . Having sources easily accessible helps with article expansion and increases the credibility of articles. Sending readers on a goose chase to find a book for no reason when there is a link available directly to the source is clearly not better. Moxy (talk) 17:34, 17 May 2013 (UTC)

Ok, I've banged out {{gbook}} to simple render the url given the id and the initial page number. This should be usable for the value of the url parameter within CS1 templates. LeadSongDog come howl! 04:00, 18 May 2013 (UTC)

Please help make documentation consistent

I've seen some differences in the documentation between Help:Citation Style 1 and Template:Cite web, and hope people here can help clear them up. For example, Help:Citation Style 1#Work and publisher states "The 'publisher' parameter should be included even where it would be the same or mostly the same as the work/site/journal/etc., for example:

|newspaper=The New York Times    and   |publisher=The New York Times Company"

However, Template:Cite web#Publisher states that the publisher is "Not normally included for periodicals." Could someone please make these consistent so everyone knows how to use these templates? Thanks! GoingBatty (talk) 02:25, 16 May 2013 (UTC)

I believe the documentation merely instructs you where to put 'The New York Times Company' if someone wants to put it, and not actually an invitation or inducement to do so. -- Ohc ^¡digame!_{¿que pasa?} 06:38, 16 May 2013 (UTC)

It does look to me like a recommendation to do so, and it certainly does need to be reworded. It says "The "publisher" parameter should be included even where it would be the same or mostly the same as the work/site/journal/etc.", and this is completely wrong in the case of newspapers. We specifically do NOT want the publisher included in the case of mainstream newspapers. This has been discussed more than once elsewhere. It is absurd to have a ref. saying that The New York Times is published by the New York Times Company, and in fact we never do so. -- Alarics (talk) 07:16, 16 May 2013 (UTC)

Yes, there are several inconsistencies. Discussions have always been concerned with what appears on the template pages, so that should be considered more authoritative, as those are updated after discussion. This help page needs to be reworked so that is keeps up with the template doc— that has been on my todo list for a while. --  Gadget850 ^talk 10:31, 16 May 2013 (UTC)

Hi. What does {{Cite web}} has to do with periodicals anyway? It is for quoting web, not periodicals. This sentence is probably a leftover of copy and paste, especially since I see this exact sentence in other DOC pages too. The statement of Help:Citation Style 1 sounds more logical because it follows the same reason for which User:GoingBatty has come here: Consistency. When I was working on taking Microsoft Security Essentials to WP:FA status, I was required to make the citations consistent. It was deemed unacceptable for one citation to have |publisher= and another not having any. Best regards, Codename Lisa (talk) 11:29, 17 May 2013 (UTC)

Because many editors use {{cite web}} for online journals. Documentation is done through {{Citation Style documentation}} for consistency. --  Gadget850 ^talk 15:01, 17 May 2013 (UTC)

Therefore, the instructions at {{Cite journal}} and {{Cite news}} are the same as {{Cite web}}: publisher is not normally included for periodicals". My goal is to have the documentation consistent, so we know how to make articles consistent. Thanks! GoingBatty (talk) 20:04, 17 May 2013 (UTC)

Hi. I'm really confused: Why make two templates when both are taken to equally accomplish one task and their differences criticized in the name of consistency? But in any case, I was required to include both |publisher= and |work= in WP:FA, so I will continue to do so. No offense but I do not follow a guideline that does not help me in FA. Best regards, Codename Lisa (talk) 17:51, 18 May 2013 (UTC)

Then the problem seems to be at FA, because they are supposed to follow guidelines. And they do seem to rather slavishly seek adherence to the WP:MOS, which we all know is not policy but a guideline. -- Ohc ^¡digame!_{¿que pasa?} 05:38, 19 May 2013 (UTC)

Hi. I am guessing "they" think "we"/"others" are the problem! (Seriously, there is no "they"; it is us all the way.)

While we are at it, the significance of metadata my not be obvious today because we think "Well, who doesn't know [Insert Journal Name Here]? Let's not include |publisher=" The catch is: Five, ten or fifty years from now, the situation may be completely different. Even now, |work= and |publisher= have helped me revive dead links while otherwise, it would have been impossible.

To conclude, I support "Help:Citation Style 1"'s current statement. It is the only way of achieving guaranteed inclusion of metadata, true consistency and FA status.

Best regards,
09:54, 19 May 2013 (UTC)

Date formatting and machine readability

[Not sure whether this belongs here or on one of the related talk pages]

At some point, it's going to be useful to have the dates in citations made machine-readable, so that they can be included in emitted metadata. That could be achieved in a number of ways, for example, having separate parameters for their day, month and year; using YYYY-MM-DD format, or using a subtemplate. Each has advantages and disadvantages. In the first two examples, it's still possible to have the rendered output in the form "17 May 2013" or "May 17th, 2013", according to a setting (see {{Start date}} or {{Birth date}} for examples if this in practice), or even user preference. Anyone got any thoughts? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:32, 17 May 2013 (UTC)

Dates used in citations are not always simple dates - you will get things like 13–19 December 2011, or Summer 1975. This would make this sort of automatic generation of metadata difficult.Nigel Ish (talk) 15:47, 17 May 2013 (UTC)

Not at all; we already manage to emit metadata for regular birth/ death dates, while accommodating (and not emitting as metadata) irregular dates such as "fl. 1735". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:00, 17 May 2013 (UTC)

No thanks. Please don't try to bring back something that was binned two years ago. Machines are perfectly capable of parsing all the date formats that are permitted under our style guidelines, witness the dates that inhabit {{persondata}}. Thus extra Date Autoformatting templates that consume extra processing and compilation resources without bringing significant benefits should not be contemplated. -- Ohc ^¡digame!_{¿que pasa?} 15:54, 17 May 2013 (UTC)

I'm not "trying to bring back something that was binned two years ago". I'm proposing something new. Persondata is only read by our own tools; not generic metadata parsers, like the ones that read dates in our infoboxes. We already use date templates such as the ones I mention, elsewhere; with no undue overheads; and with significant benefits. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:01, 17 May 2013 (UTC)

I was merely using {{persondata}} as an example. Our MOSNUM-permitted date formats, of which there are only three, are all capable of being parsed by machine, all that is needed is software configuration that's not rocket science. In the average article, there may be up to 200 references, and thus up to 600 dates. Each set of dates is specific to one citation but most are unimportant. If each set of dates is already sitting in a citation template, we hardly need to nest in another three for each date type. If the dates are not already in citation templates, metadata is next to useless. Without contemplating in detail the computing resources consumed, and the benefit of standardising something that scarcely needs standardising is potentially highly disruptive to the 'pedia. -- Ohc ^¡digame!_{¿que pasa?} 16:37, 17 May 2013 (UTC)

Nigel Ish, above, has already shown that there are more than three ways to enter date information. Using a sub-template was only one of the example methods I gave; there are others. If we want to include machine readable dates to standard metadata formats like COinS or a microformat, then they need to be formatted consistently, not as prose. Your comments about potential for disruption are a straw man. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:59, 17 May 2013 (UTC)

:oppose until there is a way to set the default date on a page or to read the user preference date. --  Gadget850 ^talk 16:10, 17 May 2013 (UTC)

What do you mean by "default date on a page"? User preference for date formatting could be achieved by the same CSS technique that {{Coord}} uses for coordinates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:36, 17 May 2013 (UTC)

That CSS simply places the displayed coordinates. There is no magic word or parser function that will unify all dates on a page, thus citation template can't inherit the date format. The only user preference that I know can be read is gender. There was a 'dateformat' parameter for a brief time after date linking was removed, but there were technical issues an it was removed; you can check the archives. --  Gadget850 ^talk 17:16, 17 May 2013 (UTC)

That (your first sentence) simply isn't the case; see Template:Coord#Per-user display customization. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:37, 17 May 2013 (UTC)

Currently dates in citations are not machine readable because there is no indication what calendar they are stated in, Julian or Gregorian. I suggest Andy go discuss with the various metadata folks about how they should modify their formats to indicate a calendar of Julian, Gregorian, or unknown, and come back when the metadata formats have been suitably modified. Jc3s5h (talk) 16:57, 17 May 2013 (UTC)

This is already resolved for the date templates mentioned above (and which are used on many thousands of articles); see their documentation. It is also resolved in the metadata standards I mentioned. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:11, 17 May 2013 (UTC)

Wait. Your original post is confusing, but it looks like this has nothing to do with date formats, and I don't know why you threw that in. You simply want to include the date metadata, which is very possible. We could add an algorithm that would convert the standard date that is displayed to a metadata date that is now shown. For example, May 17, 2013 would be shown and converted to <time datetime="2013-05-17"> which would not be shown. <time> is an HTML metadata element now supported by MediaWiki. --  Gadget850 ^talk 17:27, 17 May 2013 (UTC)

I want to include the date metadata, and pointed out that how we store the values does not need to limit the display format. But yes, we could do as up suggest (providing we don't change the actual date ;-) )Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:37, 17 May 2013 (UTC)

We've moved to what is, IMO, a very desirable simplicity in both the display and the syntaxing of chronological items. When you say, "separate parameters for their day, month and year", I start to quail that the whole system will become complex—which is not good for the "anyone can edit" principle. I'm also quite unconvinced that metadata systems cannot be developed without the use of localised syntax. And we already have significant tools at our disposal for searching for years and dates. Tony (talk) 04:37, 18 May 2013 (UTC)

This isn't about "searching for years and dates" within Wikipedia. I'm not clear what you mean by your "localised syntax" comment - please clarify, bearing in mind that we already do this for other dates, mentioned above. Separate parameters are only suggested as one of several options what's your proposed solution? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:07, 18 May 2013 (UTC)

We don't need separate parameters. There is no need to change the template input, thus this would be user transparent. <time> is a standard HTML5 tag. --  Gadget850 ^talk 10:16, 18 May 2013 (UTC)

4.6.10 The time element at W3C --Redrose64 (talk) 11:00, 18 May 2013 (UTC)

How could that be deployed, in this case? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:07, 18 May 2013 (UTC)

Let's say that a given use of {{cite news}} emits <span class="citation news">Lane, Lois (18 May 2013). "Superman prevents another trainwreck". ''Daily Planet''.</span>. All of that is generated by Module:Citation/CS1 using the {{cite news}} parameters as input. We could amend the module so that it tests to see if |date= is a valid date (to cover the situations like 13–19 December 2011, or Summer 1975 mentioned above). If the test succeeds, we put the date through the Lua equivalent of {{#time:Y-m-d}} to generate a valid date string, place that in the datetime= attribute of a <time>...</time> element which is wrapped around the original date, and output it with the rest, something like <span class="citation news">Lane, Lois (<time datetime="2013-05-18">18 May 2013</time>). "Superman prevents another trainwreck". ''Daily Planet''.</span> --Redrose64 (talk) 12:07, 18 May 2013 (UTC) Sorry. I misread the documentation for the time element, so I've rewritten the approprate bits here. --Redrose64 (talk) 16:25, 18 May 2013 (UTC)

OK, so that deals with publication dates. I don't understand to what use the metadata would be put, so please explain to Dummy here how exactly this would be done in the case of access dates, archive dates, and dates within the titles? And to what end? -- Ohc ^¡digame!_{¿que pasa?} 12:42, 18 May 2013 (UTC)

We could use exactly the same technique for access dates and archive dates, in fact these should be easier because they ought to only ever be a single date, and not cases like 13–19 December 2011, or Summer 1975. We shouldn't try to detect dates in titles, these are pretty much free-form, and trying to write code to extract a date sensibly would be a nightmare, and I don't think it's worth the hassle. As regards "to what end"; well, that's up to the harvesters of metadata. --Redrose64 (talk) 16:15, 18 May 2013 (UTC)

Does seem like typical YAGNI request: I am also not convinced the date format even matters, here, because any metadata-processing tools could reformat whatever dates, on their end, and using their processing time. So, beware typical YAGNI options ("You aren't gonna need it"). Instead, wait for the issue to become a top headline in a major tech newspaper:

• "Riot at Wikimedia when users screamed date format more important than fixing Edit-conflicts" (just not likely)

There are probably some huge numbers of feature requests that are just typical YAGNI requests, and so it is a common problem which distracts from fixing the major problems, such as not external-linking the "trans_title=" to the URL address, to allow the trans_title to contain wikilinks, or footnotes, which could better explain the translation. -Wikid77 16:58, 18 May 2013 (UTC)

You seem to present this as an "either/or" choice: a false dichotomy. And that's before we consider the valid use-cases. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:15, 18 May 2013 (UTC)

• Well, instead of dismissing the opposition to the idea of collecting it, you ought to demonstrate a solid need on our part for ever-increasing quantities of metadata when the data is already in existence and in an exploitable form. Let's have some valid use-cases, then, instead of just saying or implying we need it. If Google (or any other third party) needs it, they can jolly well create it from what we give them – if they are not doing it already. ;-) -- Ohc ^¡digame!_{¿que pasa?} 05:09, 19 May 2013 (UTC)

Unlink trans_title from URL to allow wikilinks or reftags

Proposal: The wp:CS1 cite templates should be changed back, as in the original Lua revisions, to not have external-linking of the "trans_title=" (plus the "title=") to the URL address, but instead, allow the trans_title to contain wikilinks, or footnotes explaining the translation.

{{ cite web | trans_title=Not good style | title=Nicht gute Mode | date=18 May 2013 | url=http://en.wikipedia.org/wiki/Hyperlink }}
Old	"Nicht gute Mode [Not good style]". 18 May 2013. http://en.wikipedia.org/wiki/Hyperlink.
Lua	"Nicht gute Mode" [Not good style]. 18 May 2013.
Sandbox	"Nicht gute Mode" [Not good style]. 18 May 2013.

Sandbox2:   "Nicht gute Mode" [Not good style]. 18 May 2013. 
There is just no need to link both title and trans_title to the URL, when meanwhile any title can be extended to include extra words if a URL-link seems to be mysterious blue-linked text. Unlink "trans_title=" from "url=" and unlink "trans_chapter=" from the "chapterurl=" parameter. -Wikid77 16:58, 18 May 2013 (UTC)

These all look the same. --  Gadget850 ^talk 21:48, 18 May 2013 (UTC)

The position of the second double-quote is different: in the 'Old' row it follows the closing square bracket, whereas in the other two it follows the word 'Mode'. --Redrose64 (talk) 22:59, 18 May 2013 (UTC)

The change in the location of the double quote was intentional. The translated title (usually) isn't part of the original publication, but rather something added later, and style guides (such as the Chicago Manual of Style) generally seem to suggest that neither quotes nor italics should be applied to a translated title that was added after the fact. That said, I don't think Wikid77 is actually discussing the quote marks. I think he is trying to raise some other issue, though I'm not sure what. Dragons flight (talk) 23:50, 18 May 2013 (UTC)

• The proposal is to unlink "trans_title=Not good style" as not part of the linked title text, as shown above in the Sandbox2 example. -Wikid77 (talk) 03:45, 19 May 2013 (UTC)

csdoc and maps

Recent changes to Module:Citation/CS1 caused me to review {{cite map}}. There, in that template's documentation, |section= and |inset= are grouped with Identifiers. Use of |section= and |inset= is described part of In-source locations. Is this right? Shouldn't |section= and |inset= be grouped with In-source locations and not in Identifiers?

—Trappist the monk (talk) 22:59, 19 May 2013 (UTC)

Fixed Not sure why I did it that way. --  Gadget850 ^talk 23:11, 19 May 2013 (UTC)