the Wikipedia Help Project | (Rated B-class, High-importance) | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Contents
- 1 "Check title= value" links to param-link error
- 2 |editor= documentation
- 3 Status of filtering square brackets in URLs
- 4 Second DOI for English translation
- 5 eISBN?
- 6 Need {cite_page} to link "url=" to page
- 7 Perhaps pages+page combined as page of pages
- 8 Language
- 9 Cite web - source code
- 10 Suppressing unnecessary archive-urls
- 11 Italics in publisher
- 12 author-link effciency
- 13 date=, year= mismatch
- 14 Update to the live cs1|2 modules weekend of 20–21 February 2016
- 15 Suggestion for orig-date= parameter
- 16 Suggestion for edition= parameter to treat raw numbers
- 17 Suggestion to add a printing= parameter similar to edition=
- 18 Cite magazine with combined season date.
- 19 Cite web needs a section parameter
- 20 multiple author names in |author= and aliases
- 21 Proper use of Website not explained.
- 22 Transcript parameter for cite podcast
- 23 Unrecognized language
- 24 Author clarification
- 25 Template {{Cite episode}} undocumented parameter / error
- 26 Retrieved date precedes archived date
- 27 Author titles or jobs
- 28 Error message at preview
- 29 More help with foreign languages
- 30 |language= and ISO 639-2 codes
- 31 Script variants of parameters for author, editor, etc.
- 32 Date ranges
- 33 Citing the Introduction written by the editor, not the author
- 34 Getting errors fixed
- 35 web.archive.org/save/...
- 36 County based inaccessibility for cite web
"Check title= value" links to param-link error
I'm confused about the error messages here and how to fix them. I found this citation in Bayou Country.
{{ cite AV media notes | last=Selvin | others=Creedence Clearwater Revival | id=FAN-30877-02 | titlelink=Bayou Country | first=Joel | type=CD booklet | publisher=[[Concord Music Group]] | year=2008 | authorlink=Joel Selvin | location=U.S.A. | url=http://www.concordmusicgroup.com/assets/documents01/Artists/Creedence-Clearwater-Revival/FAN-30877-02/Bayou-Country-40th-Anniversary-Liner-Notes.pdf | title=Bayou Country [Expanded Reissue] }} | |
Live | Selvin, Joel (2008). Bayou Country [Expanded Reissue] (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02 http://www.concordmusicgroup.com/assets/documents01/Artists/Creedence-Clearwater-Revival/FAN-30877-02/Bayou-Country-40th-Anniversary-Liner-Notes.pdf |url= missing title (help). |
Sandbox | Selvin, Joel (2008). Bayou Country [Expanded Reissue] (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02 http://www.concordmusicgroup.com/assets/documents01/Artists/Creedence-Clearwater-Revival/FAN-30877-02/Bayou-Country-40th-Anniversary-Liner-Notes.pdf |url= missing title (help). |
I see "|url= missing title (help). Check |title= value (help)". There is a title, and the second help link leads to the param-link error explanation. I'm guessing it has to do with the single square brackets in the title parameter. – Jonesey95 (talk) 22:56, 22 January 2016 (UTC)
- Yes, the brackets are causing the title value error but not the url error.
{{ cite AV media notes | last=Selvin | others=Creedence Clearwater Revival | id=FAN-30877-02 | titlelink=Bayou Country | first=Joel | type=CD booklet | publisher=[[Concord Music Group]] | year=2008 | authorlink=Joel Selvin | location=U.S.A. | url=http://www.concordmusicgroup.com/assets/documents01/Artists/Creedence-Clearwater-Revival/FAN-30877-02/Bayou-Country-40th-Anniversary-Liner-Notes.pdf | title=Bayou Country Expanded Reissue }} | |
Live | Selvin, Joel (2008). Bayou Country Expanded Reissue (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02 http://www.concordmusicgroup.com/assets/documents01/Artists/Creedence-Clearwater-Revival/FAN-30877-02/Bayou-Country-40th-Anniversary-Liner-Notes.pdf |url= missing title (help). |
Sandbox | Selvin, Joel (2008). Bayou Country Expanded Reissue (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02 http://www.concordmusicgroup.com/assets/documents01/Artists/Creedence-Clearwater-Revival/FAN-30877-02/Bayou-Country-40th-Anniversary-Liner-Notes.pdf |url= missing title (help). |
- I would guess that because there's a title link the url-title checker is going a little haywire:
{{ cite AV media notes | last=Selvin | others=Creedence Clearwater Revival | id=FAN-30877-02 | first=Joel | authorlink=Joel Selvin | publisher=[[Concord Music Group]] | year=2008 | type=CD booklet | location=U.S.A. | title=Bayou Country Expanded Reissue | url=http://www.concordmusicgroup.com/assets/documents01/Artists/Creedence-Clearwater-Revival/FAN-30877-02/Bayou-Country-40th-Anniversary-Liner-Notes.pdf }} | |
Live | Selvin, Joel (2008). Bayou Country Expanded Reissue (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02. |
Sandbox | Selvin, Joel (2008). Bayou Country Expanded Reissue (PDF) (CD booklet). Creedence Clearwater Revival. U.S.A.: Concord Music Group. FAN-30877-02. |
- On an aside, I've removed the link from the article in question, since articles shouldn't have self-links (aside from navigation, etc.). --Izno (talk) 23:05, 22 January 2016 (UTC)
-
- Thanks for the feedback and the suggestion about how to fix this instance of the problem, but I think the sandbox code might need to be adjusted. There are a number of articles that appeared in Category:CS1 errors: parameter link after the latest code update that seem to be false positives. – Jonesey95 (talk) 04:30, 25 January 2016 (UTC)
-
-
- Square brackets are not allowed in article titles unless they are encoded as html entities (see WP:TITLESPECIALCHARACTERS). The module appears to be doing the wrong thing in this case. Because it is permissible to wikilink the value assigned to
|title=
, the intent was to reuse the code that finds the illegal characters in|<param>-link=
to find the first[
of a wikilink when|title=[[link label]]
and|title-link=article title
from which the module would produce this illegal construct:[[article title|[[link label]]]]
- I have tweaked the module sandbox to explicitly look for the double leading square brackets of a wikilink in
|title=
(also applies to|series=
when|series-link=
is set as well as to the various other link/label pairs identified in the help text.
- Square brackets are not allowed in article titles unless they are encoded as html entities (see WP:TITLESPECIALCHARACTERS). The module appears to be doing the wrong thing in this case. Because it is permissible to wikilink the value assigned to
-
-
-
|title=
cannot be linked simultaneously by both|title-link=
and|url=
. When both of the latter are present,|title-link=
consumes|title=
so|url=
has no title-text for which it can be a link. This is a long-standing error message.
-
-
-
- —Trappist the monk (talk) 11:01, 2 February 2016 (UTC)
-
Meanwhile, to view this thread on a mobile-phone screen, I have wrapped the overlong url by inserting a hyphen into "assets/" as "assets-/" which no longer links to the actual webpage but is treated as valid URL format (and wraps on small-device screens). -Wikid77 (talk) 13:37, 8 February 2016 (UTC)
- Reverted. If you have a problem with the template, the page you should be changing is Template talk:Cite compare. --Izno (talk) 15:34, 8 February 2016 (UTC)
|editor= documentation
Editor SMcCandlish added this to the |editor=
documentation:
These parameters are for editors of collaborative printed works, such as multi-author anthologies. Wikipedia does not use them to indicate the managing editors of periodicals such as journals, newspapers, magazines, or news sites (this information is not needed in source citations). For editor-revisers of later editions of previously published unitary works, add any editors as authors, with an "(ed.)" annotation after their given names, e.g.
|author2-last=Doe |author2-first=Jane (ed.)
; this will prevent formatting that implies the cited|chapter=
in a|title=
(for books), or the|title=
in a|work=
or|website=
, is an isolated contribution contained within a multi-author work compiled by the named editor(s). None of these parameters should be used to add other, non-essential contributors who are not needed in citations, such as foreword authors or illustrators, only credited editors, revisers, and work-wide commentators.
I am on wikibreak and have no time to discuss right now so have reverted the addition and started this discussion. Please discuss.
My objection lies in the 'add any editors as authors, with an "(ed.)" annotation ...'. We should not be encouraging the improper practice of adding extraneous text to parameters that are part of the metadata nor should we misuse parameters in this way.
We can, and probably should disable |editor=
when the template is {{cite journal}}
, {{cite news}}
, {{cite magazine}}
. Foreword authors is supported in {{cite book}}
with |contributor=
and |others=
serves for illustrators and other non-essential contributors.
—Trappist the monk (talk) 13:49, 25 January 2016 (UTC)
- That solution would work for some cases, but not for the main problem. I'm not trying to impose a permanent solution, just work around a problem that bites us really often. The number of misleading citations that imply that a chapter in a single-author book, in a revised edition with an author-posthumous editor, is just one author's minor contribution to an anthology, greatly outnumber the cases of metadata-extraneous "(ed.)" annotations. You've said before that any such editorial insertions can be used with square brackets, so just changing it to "[ed.]" is sufficient for my documentation to be correct. (And I already know that for some of these templates we have special parameters for other contributor types, and I still see editor parameters abused for this purpose frequently, so the documentation still needs to say not to use editors parameters for those.) I would prefer that this be fixed in some parameter-based way, that suppresses the "in" output when it's not wanted, but until that's implemented, what I documented (plus the square-brackets fix) is the most correct approach, because it's overwhelmingly more important that our citations be correct and be parsed properly by our own readers than that COinS metadata be perfect. That metadata is an afterthought, a convenience we provide for non-central purposes, and some of us are starting to think that directly implementing it in these templates is more trouble than its worth.
Almost every time I document a real, reader- or editor-affecting problem here and try to work around or fix it, I get shot down or ignored by the same one or two editors for whom COinS seems to be more important than WP:CITE, but who effectively totally control these templates. I've been a vocal supporter of CS1 for years, and would like to see CS2 eliminated, but over the last year and half I get increasingly inspired to go create a CS3 that looks almost identical to CS1, and has one consistent set of parameters, and no extraneous fiddly stuff. CS1 has turned into an enormous pile of "feeping creaturism", and hardly anyone can figure out how to use it effectively any longer. I've been here a decade, and these template still screw up my sourcing attempts at least once a week. I spend more time reading these templates' documentation than any others. I've reported more problems with these templates than any others. Fewer of them have been resolved than with any others. Given that people are not required to use any of our templates at all to insert citations, it would be a entirely valid approach to simplicity-fork this. If the principal and rather my-way-only maintainers of these templates don't want to see that happen, they need to be more responsive to problem reports, including paying attention to the details they report, and not dismissing them "oh well, you can do this complicated hack no one will remember nor understand when they encounter it", much less "we can't fix this because our precious metadata won't be ideal". Faaaaaack... — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 14:28, 25 January 2016 (UTC)
-
- Where have I said that editorial insertions can be used with square brackets?
-
- Yes, Wikipedia editors abuse
|editor=
and|author=
to include names that are neither (sometimes with annotation; sometimes not). That will be a problem forever I'm afraid.
- Yes, Wikipedia editors abuse
-
- Yes, a parametric remedy is best. A couple of solutions occur to me off the top of my head: perhaps a modification of
|mode=
to accept additional keywords to control how the editor name list is rendered; perhaps alternate editor parameters that render in a certain way; perhaps some other parameter or parameter modification. Of these, I think that modifying|mode=
is likely the better solution. Suggest other solutions.
- Yes, a parametric remedy is best. A couple of solutions occur to me off the top of my head: perhaps a modification of
-
- Consumers of the metadata are also our own readers and though only a small minority of our own readers their right to quality information is the same as that of the majority.
- —Trappist the monk (talk) 13:13, 26 January 2016 (UTC)
- We could also modify
|display-editors=
in some fashion; this would be my new favorite solution. - —Trappist the monk (talk) 13:22, 26 January 2016 (UTC)
- We could also modify
- I agree that we need to be careful not to allow the metadata aspect of citation templates to prevent reasonable use within Wikipedia, but recommending something like
|author2-first=Jane (ed.)
can't possibly be a sensible way forward – it's simply a misuse of the parameters regardless of whether it generates misleading metadata. (@SMcCandlish: it's like using '' instead of {{em}} or <tt> instead of <code>, both of which you have rightly deprecated in the past. Parameters, like markup, should be used semantically.) - The purpose of a citation is not to record every last minute detail of the contributions of different people to the work, but to enable readers to find a source. The templates are over-complex partly because editors have been allowed to keep adding "features" which have nothing to do with their primary purpose, which, I repeat, is to provide sufficient information (and no more) to allow readers to locate the source. Peter coxhead (talk) 15:32, 25 January 2016 (UTC)
- I agree with the purpose of citations. But I thought the topic here (CS1) is citation style. That is, after citation requirements have been agreed upon, how do we proceed with presentation?
- Because there has been haphazard discussion on citation requirements elsewhere, discussion on requirements creeps into this forum. It shouldn't be so, imo. There should be a more organized discussion on citation design (discovering & implementing requirements) separately from the discussion on citation formatting (presentation).
- 72.43.99.130 (talk) 20:19, 25 January 2016 (UTC)
-
- I Oppose any attempt to remove editor from
{{cite magazine}}
,{{cite news}}
etc. Many articles have no credited author, for example this one. --Redrose64 (talk) 19:54, 25 January 2016 (UTC)- Seconded. Oppose removal of editor from the templates mentioned. As an aside, most of the problems mentioned in the thread I believe could be resolved with better, clearer documentation. 72.43.99.130 (talk) 20:24, 25 January 2016 (UTC)
- It is not the usual practice to give the editor name in this situation. CMOS recommends using the magazine name in such a case.
- The reason we name the editors of collections of contributions by several authors, or of an author's work, is because it helps the reader find the book, as that is how they are typically catalogued. That doesn't apply in the case of magazines or newspapers. Kanguole 22:19, 25 January 2016 (UTC)
- Oppose changing the templates to remove the possibility of setting an editor. Although the editor or editorial board of most journal publications should not be cited, editors are occasionally useful for journals, for instance when citing a special issue or special section of a journal that has its own separate editors. Making the templates more rigid in what they accept has the cost of making more special-case citations that cannot be properly handled by the templates (pushing people to not use the templates at all) for only a very small benefit of catching a few unusual cases where people are citing things the wrong way. It's the wrong tradeoff to take. —David Eppstein (talk) 23:26, 25 January 2016 (UTC)
- PS I also agree with Trappist's reversion of the change to the documentation: adding "(ed.)" to values of other parameters is the wrong way to do it and should not be encouraged. —David Eppstein (talk) 00:15, 26 January 2016 (UTC)
- I also oppose any disablement of
|editor=
in journal, etc. However, note that such disablement is only TM's secondary comment, that the main point is regarding Mac's documentation change that editors can be cited as authors. I also oppose that change (effectively supporting TM's reversion), though as a possible work-around it might merit discussion. ~ J. Johnson (JJ) (talk) 23:46, 25 January 2016 (UTC)- Fine. You can keep your precious author/editor distinction (which is often artificial or tenuous; I have books where the author went from author to "editor" between editions, simply because someone at the publisher decided to make it that way). I can concede that in most cases it's a distinction we want to preserve, iff it actually affects the metadata accuracy in COinS (which is a rather blunt instrument). But that still leaves us with the question of what do in cases like what I outlined in my "rogue" documentation change.
To address some of the comments above: For the record, I do not agree that the sole purpose of these citations is identifying the source so people can find it; that's the primary purpose. As anyone with any familiarity with academia knows, it also has a lot to do with proper attribution, credit where due. And this is actually important for WP-internal reasons, like being exact in our attribution of claims, especially primary ones.
As someone commented above, yes, it is true that we do not cite managing editors of newspapers and such, except possibly under unusual circumstances. (When would we ever do that? Give a concrete example. Even if there's some kind of "Statement by the Editor" piece, the "editor" in that case is actually the author, and would be cited as such.) If you are adding the names of the general or managing editorial staff at a newspaper or journal as |editors, you are not doing citations right, you're engaging in WP:NOT#BIBLIOGRAPHY; it's exactly the same thing as giving the total page count, the address of the publisher, or hardback vs. paperback. This is not citation information. It looks superficially like attribution, but it's attribution for an organizational role, like adding a parameter for the owner of the newspaper, and its janitor. WP is not IMDb; we don't provide details on every single person associated with a "production" in any medium. That said, we s should not disable the parameter for any particular medium, since a particular piece may in fact have a direct, actual, credited-in-the-specific-piece editor who needs attribution (and whose editorial presence in the piece may considerably enhance its reliability, I might add). We don't need to kill the parameter, we need to clarify what not to do with it. That much of what I added to the docs should be restored.
At any rate, it looks like me like neither of the issues I attempted to address in what I wrote in the doc page have been addressed. We do need to discourage the misuse of the editor field to identify corporate administrators, and we do need to distinguish between two different levels of revisers of an original author, especially when the intermediary one was a very significant contributor to the work. Many "editors" are actually posthumous co-authors, and may even be responsible for much more of the content than the original author, yet may themselves be retired from the project in question (or deceased) for some time, with some new editor (actually acting as an editor per se or a new layer of co-author). This sort of thing comes up very frequently in style guides, as just one topical example. What is presently called Fowler's Modern English has much less of H. W. Fowler's original content in it than people think (I know; I have the 1st ed., too). Same goes for the ones we call in short form Turabian and Hart's, and Gowers. Sometimes the editions with different editors are cumulative, sometimes they are not, and this can have actual RS implications – particular editors are more reputable than others, and even particular editions by the same editor may be (and this is not always chronological). — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 01:29, 9 February 2016 (UTC)
- Fine. You can keep your precious author/editor distinction (which is often artificial or tenuous; I have books where the author went from author to "editor" between editions, simply because someone at the publisher decided to make it that way). I can concede that in most cases it's a distinction we want to preserve, iff it actually affects the metadata accuracy in COinS (which is a rather blunt instrument). But that still leaves us with the question of what do in cases like what I outlined in my "rogue" documentation change.
-
-
- Just for clarification, the change that Editor SMcCandlish is discussing refers to how cs1|2 handles editors when
|chapter=
is set (1) and when it is not set (2):- Darwin, Charles (1909). "Laws of Variation". In Eliot, Charles W. The Origin of Species. New York: P F Collier and Son.
- Darwin, Charles (1909). Eliot, Charles W, ed. The Origin of Species. New York: P F Collier and Son.
- When chapter is set (1) cs1|2 makes it appear that Darwin is one of possibly several authors of an anthology edited by Eliot when, in fact, Darwin is the only author.
- Just for clarification, the change that Editor SMcCandlish is discussing refers to how cs1|2 handles editors when
-
- The question then is: how should we instruct cs1|2 to render
|editor=
using the form in (2) when|chapter=
and|editor=
are set and when|authorn=
is/are the author(s) of the whole work?
- The question then is: how should we instruct cs1|2 to render
-
- The answer to the implementation question will determine, I think, how the documentation should be changed so perhaps that topic should be tabled until the implementation decision is taken.
- —Trappist the monk (talk) 13:43, 9 February 2016 (UTC)
-
Proposal: editor, cite encyclopedia
- Remove the text "in {{{editor}}}" from all templates except {{cite encyclopedia}}; keep the display of editor role (ed.) in all templates
- Rename {{cite encyclopedia}} into {{cite compilation}} (or similar); keep {{cite encyclopedia}} as an alias
- Activate {{{contributor}}} in proposed {{cite compilation}}
- Thank you. 72.43.99.146 (talk) 15:23, 26 January 2016 (UTC)
-
- On first glance, that might actually do it, as long as there's not some new "you're abusing the metadata" complaint about using |contributor to deal with multiple levels of editor–co-authors. Is there any sort of potential fallout from this? Besides the obvious one: Many collaborative books (e.g. scholarly volumes of journal-style papers by different authors, under an editor [or plural] who is actually an editor, not a corporate functionary, like this [1]) are already coded in {{cite book}} with the expectation of the "in {{{editor}}} (editor)" output, not just "{{{editor}}} (editor)". I have to ask if there any actual harm at all in that drop-the-"in" conversion? While the "in" format (in one exact stylization or another) is very common, it's not universal. In a quick comparison of American citation styles (from Cite Right, Charles Lipson, 2006, and "Purdue OWL Citation Chart" 2014), there's a clear split between how to style an editor of a book when just citing the book, or a chapter by someone else in an edited book. I've summarized these, splitting the former from the latter with a "/", and giving some indication whether the editor citation starts a new sentence or not, and how it ends (the quotation marks are bracketing what I'm quoting, not part of the citation style):
MLA: "Ed. Kathleen A. Hauke." or "Hauke, Kathleen A., ed.," depending on edition / "In. [title], ed. Kathleen A. Hauke." or "[chapter]. [title]. Ed. Kathleen A. Hauke." (emphasis added – note the lack of "[i|I]n", and that's from the 2014 source), depending on edition
APA: "K. A. Hauke (Ed.)." / "In K. A. Hauke (Ed.),"
CMS: "Edited by Kathleen A. Hauke." / "In [title], edited by Kathleen A. Hauke,"
Chicago/Turabian: "Kathleen A. Hauke, ed.," / "[I|i]n [title], edited by Kathleen A. Hauke,"
AAA: "Kathleen A. Hauke, ed." / In [title]. Kathleen A. Hauke, ed."
CSE & AMA: "Hauke KA, editor." / In: Hauke KA, editor. [title]."
ACS: "Hauke, K. A., Ed.;" / "In [title]; Hauke, K.A., Ed.;"
AIP: "K. A. Hauke, editor," / ", in [title], edited by K. A. Hauke (...)."
Astro. (no single standard, but fairly consistent): ", ed. K. A. Hauke (...)" / ", in [title], ed. K. A. Hauke (...)."
Maths. (not consistent): "K. A. Hauke (ed.)," or "K. A. Hauke (ed.):" or "In: K. A. Hauke (ed.)," / ", in [title], K. A. Hauke, ed.," or "In: K. A. Hauke (ed.), [title]."
Bluebook & ALWD: "(Kathleen A. Hauke ed, ...)." / ", in [title] (Kathleen A. Hauke ed, ...)." (Bluebook italicizes in, ALWD does not).So, all of these use some form of "in" except some editions of MLA. But at least that's proof it's not effectively mandatory to treat it this way. I've not yet gone through MHRA and other non-American sources on this question. I'm pretty sure there are more that do not expect an "in". Anyway, I actually need to verify that the 2014 Purdue source is correct on MLA dropping the "in". I actually just got the latest MLA guide last month, and have not perused it yet, but my eyes hurt, so I'll look into it later. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 02:51, 9 February 2016 (UTC)
- On first glance, that might actually do it, as long as there's not some new "you're abusing the metadata" complaint about using |contributor to deal with multiple levels of editor–co-authors. Is there any sort of potential fallout from this? Besides the obvious one: Many collaborative books (e.g. scholarly volumes of journal-style papers by different authors, under an editor [or plural] who is actually an editor, not a corporate functionary, like this [1]) are already coded in {{cite book}} with the expectation of the "in {{{editor}}} (editor)" output, not just "{{{editor}}} (editor)". I have to ask if there any actual harm at all in that drop-the-"in" conversion? While the "in" format (in one exact stylization or another) is very common, it's not universal. In a quick comparison of American citation styles (from Cite Right, Charles Lipson, 2006, and "Purdue OWL Citation Chart" 2014), there's a clear split between how to style an editor of a book when just citing the book, or a chapter by someone else in an edited book. I've summarized these, splitting the former from the latter with a "/", and giving some indication whether the editor citation starts a new sentence or not, and how it ends (the quotation marks are bracketing what I'm quoting, not part of the citation style):
-
-
- There are differences in the roles of editors of single-author books and editors of works from multiple authors. In the latter case, the term editor often encompasses the work of a compiler (somebody who chooses who and why will be included in the work) and also somebody who often vets the contributions for relevance/topicality relative to the particular "compilation". Although a “compilation” editor (for lack of better term) may not be involved in fact-checking (esp. in science publications) s/he should have acquired a certain level of confidence regarding the veracity of the contributions. It seems that in many situations, a compilation editor does meaningful work, which affects the end-product. Less, or not at all so, with single-author books. So the text “in {{{editor}}}” would be justified in the former case. 65.88.88.127 (talk) 20:57, 9 February 2016 (UTC)
- I know there are differences; that's why I carefully showed how these citations styles specify the two distinct cases. [sigh] — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 14:41, 10 February 2016 (UTC)
- In order not to have recurring useless discussion about style, the doc should make clear why the editor may be presented differently in {{cite book}} vs. the proposed {{cite compilation}}. It's not enough that we know. Letting all Wikipedia users know (through the doc) that there is a valid rationale behind the difference in formatting, would perhaps rid this page of unnecessary debate. 65.88.88.127 (talk) 16:12, 10 February 2016 (UTC)
- I know there are differences; that's why I carefully showed how these citations styles specify the two distinct cases. [sigh] — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 14:41, 10 February 2016 (UTC)
- There are differences in the roles of editors of single-author books and editors of works from multiple authors. In the latter case, the term editor often encompasses the work of a compiler (somebody who chooses who and why will be included in the work) and also somebody who often vets the contributions for relevance/topicality relative to the particular "compilation". Although a “compilation” editor (for lack of better term) may not be involved in fact-checking (esp. in science publications) s/he should have acquired a certain level of confidence regarding the veracity of the contributions. It seems that in many situations, a compilation editor does meaningful work, which affects the end-product. Less, or not at all so, with single-author books. So the text “in {{{editor}}}” would be justified in the former case. 65.88.88.127 (talk) 20:57, 9 February 2016 (UTC)
-
Status of filtering square brackets in URLs
Are we planning to handle brackets in URLs? I found an article (at redirect "EAPPI") where the "url=" contains sets of single brackets ("[...]") and should be encoded by a Lua filter (as '%7b' and '%7d' values?). Apparently those are very rare inside a URL, but they should be filtered by the Lua module, some day. This problem goes back 15 years due to the poor design of the MediaWiki markup language which should have used 2-character tokens to denote an external URL link, such as with both angle+square brackets, "<[http:...]>" rather than just single brackets "[http...]" as now unable to include each ']' inside a URL address. Anyway, 15 years later, now the cite templates should handle "[...]" inside each URL parameter. -Wikid77 (talk) 11:37, 27 January 2016 (UTC)
- Technically, unencoded single brackets are actually forbidden in the path part of a URL according to the URL specification. Of course, in practice anything is allowed provided that browsers and servers support it. Wikipedia also have issues with angle brackets ("<", ">") breaking urls. There might be other examples too. Dragons flight (talk) 12:39, 27 January 2016 (UTC)
- The embedded brackets "[...]" are so rare, it can wait to be handled, along with other URL characters. -Wikid77 (talk) 14:00, 27 January 2016 (UTC)
- Forbidden in the path part yes, but I think that they are legal in the query string. When used there they will still break the MediaWiki parsing: I have come across examples of such use in the past, occasionally when somebody posts to VPT with "why doesn't my URL work?". --Redrose64 (talk) 21:53, 27 January 2016 (UTC)
- The embedded brackets "[...]" are so rare, it can wait to be handled, along with other URL characters. -Wikid77 (talk) 14:00, 27 January 2016 (UTC)
Here's an example of a URL containing square brackets (from Pass Me By (R5 song)) that does not render correctly:
{{ cite web | publisher=Muzikkitabi | title=R5 Performs Pass Me By, Loud [Morning Show Toronto] 8/26/13 | accessdate=2012-09-13 | date=2012-09-08 | url=http://muzikkitabi.com/Video/VIDEOIDEDGno_UD0U4/R5-performs-Pass-Me-By-Loud-[Morning-Show-Toronto]-8-26-13 }} | |
Live | [Morning-Show-Toronto-8-26-13 "R5 Performs Pass Me By, Loud [Morning Show Toronto] 8/26/13"]. Muzikkitabi. 2012-09-08. Retrieved 2012-09-13. |
Sandbox | "R5 Performs Pass Me By, Loud [Morning Show Toronto] 8/26/13". Muzikkitabi. 2012-09-08. Retrieved 2012-09-13. |
We should probably do something to either render this reasonably or flag it as an error. – Jonesey95 (talk) 03:41, 10 February 2016 (UTC)
- Following up on a comment at Help_talk:Citation_Style_1#Update to the live cs1|2 modules weekend of 20–21 February 2016:
- For a very long time, the template docs have advised editors to percent-encode certain characters when they occur in a url; see Template:Cite_book#URL for the list. :Characters allowed in the various parts of a url are defined in Uniform Resource Identifier (URI): Generic Syntax. Essentially, the characters defined in the table at Template:Cite_book#URL must be percent-encoded when used in the path portion of a url (not allowed in the scheme and domain parts).
- That leaves us three options:
- ignore the content and make up of the url path – this is what we do now
- detect the presence of these characters in the url path and then emit an error message
- detect the presence of these characters in the url path and then percent encode them
- What do?
- —Trappist the monk (talk) 18:31, 14 February 2016 (UTC)
-
- I think option 1 is not good, since the citation renders quite poorly.
-
- We have been encouraged many times on this page to pursue option 3, i.e. be permissive in what we accept, even if it is technically invalid. Our historical practice in most cases has been option 2, detect input that does not comply with guidelines and emit an error messages, letting human editors fix the errors.
-
- If option 3 (reliably detect and replace) is technically feasible, I recommend it. If not, option 2 (emit an error message). – Jonesey95 (talk) 23:54, 14 February 2016 (UTC)
- I'll explore the latter two options after the next update.
- —Trappist the monk (talk) 16:29, 15 February 2016 (UTC)
- I too would prefer option 3. The FAQ database on various Konica Minolta web sites is another example of urls containing square brackets (see f.e. http://www.konicaminoltasupport.com/index.php?id=4569&L=2 ).
- --Matthiaspaul (talk) 21:03, 15 February 2016 (UTC)
- If option 3 (reliably detect and replace) is technically feasible, I recommend it. If not, option 2 (emit an error message). – Jonesey95 (talk) 23:54, 14 February 2016 (UTC)
I've added a bit of code to external_link()
so that square brackets occurring in the path portion of a url are percent encoded.
{{ cite web | title=Was ist die Zonenwahl-Funktion? | url=http://www.konicaminoltasupport.com/index.php?id=4569&tx_faqmanager_pi1[question]=3640&tx_faqmanager_pi1[product]=136&tx_faqmanager_pi1[producttype]=10&tx_faqmanager_pi1[category]=&L=2 | trans-title=What is the Zone Matching function? | language=de }} | |
Live | [question=3640&tx_faqmanager_pi1[product]=136&tx_faqmanager_pi1[producttype]=10&tx_faqmanager_pi1[category]=&L=2 "Was ist die Zonenwahl-Funktion?" [What is the Zone Matching function?]] (in German). |
Sandbox | "Was ist die Zonenwahl-Funktion?" [What is the Zone Matching function?] (in German). |
Because the module creates a label from |url=
when |title=
is missing or empty, the label it creates is not encoded:
{{ cite web | url=http://www.konicaminoltasupport.com/index.php?id=4569&tx_faqmanager_pi1[question]=3640&tx_faqmanager_pi1[product]=136&tx_faqmanager_pi1[producttype]=10&tx_faqmanager_pi1[category]=&L=2 | language=de }} | |
Live | (in German) [question=3640&tx_faqmanager_pi1[product]=136&tx_faqmanager_pi1[producttype]=10&tx_faqmanager_pi1[category]=&L=2 http://www.konicaminoltasupport.com/index.php?id=4569&tx_faqmanager_pi1%5Bquestion%5D=3640&tx_faqmanager_pi1%5Bproduct%5D=136&tx_faqmanager_pi1%5Bproducttype%5D=10&tx_faqmanager_pi1%5Bcategory%5D=&L=2]. Missing or empty |title= (help) |
Sandbox | (in German) http://www.konicaminoltasupport.com/index.php?id=4569&tx_faqmanager_pi1[question]=3640&tx_faqmanager_pi1[product]=136&tx_faqmanager_pi1[producttype]=10&tx_faqmanager_pi1[category]=&L=2. Missing or empty |title= (help) |
—Trappist the monk (talk) 13:13, 22 February 2016 (UTC)
- Looks good to me. – Jonesey95 (talk) 14:56, 22 February 2016 (UTC)
- Thanks. --Matthiaspaul (talk) 00:51, 24 February 2016 (UTC)
Second DOI for English translation
Many Russian mathematics journal articles have two DOIs, one for the original Russian article and a second one for its translation into English. Example:
- Demidov, S. S. (2006). "70 лет журналу “Успехи математических наук”" [70 years of the journal Uspekhi Matematicheskikh Nauk]. Uspekhi Matematicheskikh Nauk (in Russian) 61 (4): 203–207. doi:10.4213/rm3273. Translated as doi:10.1070/RM2006v061n04ABEH004354.
(Also note that the Russian original is free online while the translation is paywalled.) Above, I am abusing the |id=
parameter to link the translation. Is there or should there be a better way? —David Eppstein (talk) 21:48, 27 January 2016 (UTC)
- Or just append the extra stuff after the citation template:
- Demidov, S. S. (2006). "70 лет журналу “Успехи математических наук”" [70 years of the journal Uspekhi Matematicheskikh Nauk]. Uspekhi Matematicheskikh Nauk (in Russian) 61 (4): 203–207. doi:10.4213/rm3273. Translated as doi:10.1070/RM2006v061n04ABEH004354.
-
- ~ J. Johnson (JJ) (talk) 00:24, 28 January 2016 (UTC)
- Right, that's what I actually did in the article where this came from. Using
|id=
was a later cleanup for here. But it would be nice if we could actually use the template to format the whole citation rather than having some of it spill over into freeform non-templated text. —David Eppstein (talk) 06:16, 28 January 2016 (UTC)- I agree. But this kind of problem doesn't happen too often, and it's easier to just slap something on then try to fine tune the tool for every possibility. ~ J. Johnson (JJ) (talk) 21:12, 28 January 2016 (UTC)
- Right, that's what I actually did in the article where this came from. Using
- ~ J. Johnson (JJ) (talk) 00:24, 28 January 2016 (UTC)
- Why would we need, on en.WP, to provide a URL (etc.) to the Russian version if the English one is available? WP:NOT a document translation indexing service. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 14:38, 10 February 2016 (UTC)
eISBN?
It seems the number of works with dual numbers (print & electronic ISBN) or just an eISBN (when published solely as e-books) is increasing. 72.43.99.130 (talk) 20:37, 2 February 2016 (UTC)
- Apparently, there is no such thing.
- —Trappist the monk (talk) 20:48, 2 February 2016 (UTC)
-
- Some publishers are using the term anyway (in edition notices of both print and digital books), but the acronym is not important. How to differentiate, if need be? It seems to me that digital versions of books increasingly differ from print versions, sometimes with "enhanced" features. If eISSN is justified, "eISBN" (or whatever) should be considered. 208.87.234.201 (talk) 01:29, 3 February 2016 (UTC)
- Not necessary per WP:SAYWHEREYOUGOTIT. Just use the ISBN of what you're actually reading. If you want to add a note that it's also available in a different-medium edition with a different ISBN, you could do so between the template and the
</ref>
. Largely unnecessary. For some books, there may be 5 or more ISBNs, depending on whether its hardback, paperback, trade paperback, spiral-bound, e-book, etc., and maybe additional ones depending on whether the UK or US or India office printed it, etc. There's no point in including all this info, per WP:NOT#BIBLIOGRAPHY. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 14:34, 10 February 2016 (UTC)- The question was about specifying that there may be substantially different editions based on medium-type. Is it enough to add e.g.
|type=e-book
and|edition=digital
(or similar) to a citation of an e-book that has additional features not in the print editions? Or is an additional signifier along the lines of eISSN to be considered? 65.88.88.127 (talk) 16:23, 10 February 2016 (UTC)
- The question was about specifying that there may be substantially different editions based on medium-type. Is it enough to add e.g.
- Not necessary per WP:SAYWHEREYOUGOTIT. Just use the ISBN of what you're actually reading. If you want to add a note that it's also available in a different-medium edition with a different ISBN, you could do so between the template and the
- Some publishers are using the term anyway (in edition notices of both print and digital books), but the acronym is not important. How to differentiate, if need be? It seems to me that digital versions of books increasingly differ from print versions, sometimes with "enhanced" features. If eISSN is justified, "eISBN" (or whatever) should be considered. 208.87.234.201 (talk) 01:29, 3 February 2016 (UTC)
Need {cite_page} to link "url=" to page
I am thinking to create a simple template, {cite_page} to ignore "title=" & "publisher" and just show "Author (year). p. [url page]." as a short cite for optional link page+url. However, the template could also show "volume=" so the cite could link a page within different volumes of the same author/year book. The benefit would be to morph multiple refs to the same book, but different pages, to be {cite_page} with optional "url=" link to each page (rather than link to title). Recent timing tests show the simple markup cite templates (without Lua) now run over 800/second and use perhaps 300 bytes (rather than Lua's 1,000-1,600 per cite, as 4x title+url length) of the wp:post-expand include size (limit 2,000MB). Would that kind of short cite need CoINS metadata? -Wikid77 (talk) 17:04, 5 February 2016 (UTC)
- What's wrong with using the existing {{sfn}} and its cousins?
- Here's a short cite, linking to page 34 of an article, hosted on www.example.com.[1]
- The real source is a Time magazine article, fully cited using
|ref=harv
.[2]
References
- ^ Baker 2013, p. 34.
- ^ Baker, Aryn (2013). "Syria's Breaking Bad: Are Amphetamines Funding the War?". Time. ISSN 0040-781X. Retrieved 2016-02-05.
— Preceding unsigned comment added by Jonesey95 (talk • contribs) 17:16, 5 February 2016
While the use of "{{sfn|Baker|2013|p=[http://www.example.com 34]}}" is great for people who think of parameters that way, it is very, very different from "author=" plus "year=" plus "url=" & "pages=" etc. Again, the benefit would be to easily morph multiple refs to the same book, but different pages, to be {cite_page} with optional "url=" link to each page (rather than link to title). Typically, we see repeated:
-
-
- {cite book |author=John Doe |title=Book |year=2011 |url=http...books.google |publisher=Acme}
- {cite book |author=John Doe |title=Book |year=2011 |url=http...books.google..PA14 |page=14}
- {cite book |author=John Doe |title=Book |year=2011 |url=http...books.google..PA34 |pages=34-36}
- {cite book |author=John Doe |title=Book |year=2011 |url=http...books.google..PA67 |pages=67}
-
So to fix all the repeats, just change each extra "cite book" to be "cite page" and instantly done. No need to explain Harvard referencing with the mandatory parameter "|ref=harv" and no need to omit "author=" or "year=" or "url=" or "pages=" (etc.); the template could just ignore "title=" (or "publisher") to show the short cites. Fixing repeated references would become a matter of seconds per article, with no worry of misspelling the author's names or putting wrong year. New users would see {cite_page} as having similar parameters to the other cites they wrote in the page. -Wikid77 (talk) 17:48, 5 February 2016 (UTC)
- How is a reader to know that "Baker 2013 p. 34" is a reference to the full Baker 2013 citation without a link to the full citation? Showing just "Author (year). p. [url page]." makes it difficult for the reader to locate the source if there is not a clear link to that full source in the article. Harvard referencing provides that full link.
- Maybe a sandbox example page would be a good way of explaining how your proposed way is better than the documented way of doing this that is standard and has existed for a while. – Jonesey95 (talk) 18:03, 5 February 2016 (UTC)
- The {cite book ...} examples above are all full citations of a source, and generally should not be repeated; once per article is generally sufficient. Repeated citation of a source is handled with short citations, that is their purpose, and {{harv}} implements them very well. E.g.:
-
- {harv |Doe|2011|p=14}
- {harv |Doe|2011|pp=34-36} etc.
-
- It seems to me what you want is a way of converting existing instances of repeated full citations to some kind of short cite without a lot of retyping, essentially re-using the existing "typing". That would leave a lot of unused cruft in the text, confusing new editors as to what parameters are actually needed. It would be better to have a script that does whole replacement of such instances, perhaps after checking that there is a full citation some where. ~ J. Johnson (JJ) (talk) 21:56, 11 February 2016 (UTC)
- P.S. Just had an idea. How about a {cit2harv} template that is only an alias for {cite} (etc.). An editor could use it to identify full citations that should be converted to short cites, which would be done by a script. What I like about this is the avoidance of yet another bot turned loose; it would provide specific and deliberate targeting for a limited purpose script. ~ J. Johnson (JJ) (talk) 22:05, 11 February 2016 (UTC)
Perhaps pages+page combined as page of pages
In the Category:Pages_with_citations_having_redundant_parameters, I have cleared all old entries from months ago, and left new entries to show a growing set of examples of recent redundant parameters. Previously, over 80% of entries had been pages+page, but 2nd most were author2+last2 (or similar). For the vast majority, as pages+page, the common fix is to show "page of pages" where many people think "pages=" is the total (similar to French "pages totales=" in fr:Template:Ouvrage but not in fr:Template:Lien_web). If the cites auto-combine as "page of pages" then over 80% of former "redundant" parameters will be valid now, and in viewing prior revisions of those pages, such as in old talk-pages. We would simply state in the CS1 documentation, "when pages+page cite shows page of pages" (or such), and that would remove those numerous pages+page errors from cites. -Wikid77 (talk) 17:18, 5 February 2016 (UTC)
- All of those edits are relatively new; I have cleared out that category many times over the past year or more. They appear to be caused by editors who misread or do not read the documentation, which clearly states "pages: A range of pages in the source that supports the content. Use either |page= or |pages=, but not both. ... do not use to indicate the total number of pages in the source."
- Showing "page x of xxx" would require consensus to change the documentation for the CS1 templates. – Jonesey95 (talk) 17:25, 5 February 2016 (UTC)
- Or are caused by Citation bot. --Izno (talk) 17:30, 5 February 2016 (UTC)
Language
In keeping with my post at Wikipedia_talk:COinS#Language metadata pollutes COinS, and because this page has more watchers, I have moved this conversation from Module_talk:Citation/CS1/Feature_requests#Language to here.
At Feature requests#Language, Editor OwenBlacker wrote
Is it possible to reinstigate discussion on this change? At the moment, providing human-readable language tagging is done (as Jonesey95 pointed out on 20 December 2013) and COinS-tagging means that we can't use {{lang}} within CS1 templates (like {{cite book |title={{lang|es|La Casa de Mi Padre}} |trans_title=My Father's Home |author=Will Ferrell |language=es }}) because it would pollute the machine-readable data; we need to use {{cite book |title=La Casa de Mi Padre |trans_title=My Father's Home |author=Will Ferrell |language=es }} instead. What would be great would be to change the output markup so that this example above goes from rendering (without the COinS):
to rendering<cite class="citation book">Will Ferrell. <i>La Casa de Mi Padre</i> [<i>My Father's Home</i>] (in Spanish).</cite>for example. This would allow assistive technologies correctly to identify the language of the title (and, for example, user CSS to style text differently according to language). Alternatively, rather than assuming that the<cite class="citation book">Will Ferrell. <i lang="es" xml:lang="es">La Casa de Mi Padre</i> [<i>My Father's Home</i>] (in Spanish).</cite>title
(and only thetitle
) will match thelanguage
, new parameters could be added such as|title_lang=
,|chapter_lang=
and|journal_lang=
, for example.I'm entirely open to discussing the details, as I've just made these up on the spot, but in principle this feels like something we could make work, no? :o)
— OwenBlacker (Talk) 14:32, 7 February 2016 (UTC)
Is xml:lang="..."
required? Wikipedia pages are <!DOCTYPE html>
.
It occurs to me that one way to address this might be to support certain parameters that look like this: |title-es=
, |chapter-de=
, etc where the language code suffix is the appropriate ISO 639-1 code. This will require that we make changes to validate()
, argument_wrapper()
(this one is problematic because it is not at all documented and is not easily understood), and certainly others.
We would ignore the English versions: |title-en=
, etc.
What do we do when |script-title=
is also set? If both |script-title=
and |title=
are set, |title=
is supposed to hold the transliteration of the original title so its language specifier, if provided, must be the same as the specifier in |script-title=
. If the language is specified for one of |script-title=
or |title=
but not both, what do we do then?
—Trappist the monk (talk) 16:44, 7 February 2016 (UTC)
- Using
|script-title=
overloaded to hold the lang code of the title, or a new|title-lang=
, seems more sensible than a number of new parameters. I have a preference for the latter. --Izno (talk) - StackExchange on xml:lang. My read is that, since we're serving Html5, we don't need xml:lang. --Izno (talk) 17:29, 7 February 2016 (UTC)
- We also need parameters for identifying the language of other items IMO e.g.
|work-title-lang=
. --Izno (talk) 17:34, 7 February 2016 (UTC)- Not sure I quite understand this. How would you overload
|script-title=
to hold the language code of|title=
? Like this?:{{cite ... |title=La Casa de Mi Padre |script-title=es: |...}}
- The purpose of my suggestion was to avoid creating new parameters; we have enough of them now. If we can figure out how to modify or tag existing parameters and still recognize, programmatically, when they are valid, that seems a better solution for editors who will use them. If we can make this work for
|title=
then it should extend to other 'title' holding parameters as well. Which leads me to the additional question, what about authors:{{cite book |first=Guðrún Eva |last=Mínervudóttir |author-link=Guðrún Eva Mínervudóttir |title=Fyrirlestur um hamingjuna |trans-title=Lecture on Happiness |isbn=9789979865773 |location=Reykjavík |publisher=Bjartur |date=2000 |language=is}}
- Mínervudóttir, Guðrún Eva (2000). Fyrirlestur um hamingjuna [Lecture on Happiness] (in Icelandic). Reykjavík: Bjartur. ISBN 9789979865773.
- and this is a simple example, author and title are the same language. What about for journals? For journals, internationally disparate authors are common. Perhaps we just don't go there.
- I agree that
xml:lang
does not apply to us, but I thought that the question should be asked since the Editor OwenBlacker specifically included it in the example cite. - —Trappist the monk (talk) 18:30, 7 February 2016 (UTC)
-
It was a stray thought tossed out that might solve the issue of "what to do when script is also specified". Don't worry too much if an implementation doesn't jump out at you--we have two others to consider (but which include the issue).
I think we should attempt not to confuse the issue of having a title in a different language than the default and the issue of having a title at all, which is why I prefer
|title-lang=es
+|title=
to|title-es=
. The former can presumably also re-use the language checking utility we have in|language=
without change. There is also the issue of duplicate parameteres that User:Citation bot chokes on (reported already as a bug) as-it-is as well as updating other scripts to consider|title=
and|title-es=
as duplicates.I think it's trivial to indicate that a certain work's/section's/whatnot's title may be in a particular language in the citation; I'm unsure if the same can be said about personal names. Besides the case of psuedonyms (which, at best, we can indicate are in a particular script), is the name "Steven" in Swedish, English, or Spanish? So I'd be disinclined to agree to an
|author-lang=
or similar. --Izno (talk) 18:49, 7 February 2016 (UTC)- The relevant section of the HTML5 spec is 3.2.5.3 The
lang
andxml:lang
attributes, in particular the paragraph beginning "Authors must not use thelang
attribute in the XML namespace on HTML elements in HTML documents." In this context, "thelang
attribute in the XML namespace" meansxml:lang=something
. Therefore, as MediaWiki serves HTML, we must not add thexml:lang=
attribute to a<i>
tag. --Redrose64 (talk) 21:33, 7 February 2016 (UTC)- Concur. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 14:30, 10 February 2016 (UTC)
- The relevant section of the HTML5 spec is 3.2.5.3 The
-
- Not sure I quite understand this. How would you overload
Cite web - source code
Is there a way to cite a URL in a way that clicking the link will instead of loading the webpage as HTML instead directly bring up its source code?
I would like to do this because a page displays some information about characters when viewed live, but when I created an archived copy there is some kind of object error which prevents its display, even though it shows up just fine when viewed live.
This happens at http://web.archive.org/web/20160208130149/http://www.nickjr.co.uk/shows/wallykazam/ if you 'view source' on the archive you can see the titular character Wally's age is given as "six year old". You can see it displays as intended in the live version but the archived version gets an error which prevents people from being able to check it.
If we cannot view text directly on an archive due to problems like this, is there some way to include a note hen using template:cite web that people should 'view source' to search for a quote if the quote does not display in the archive like it did when live? 184.145.18.50 (talk) 13:17, 8 February 2016 (UTC)
- Place a note in the reference after the closing curly braces of the cite template. – Jonesey95 (talk) 15:07, 8 February 2016 (UTC)
Okay, I guess there's no "sources=yes/no" or "note=" to help standardize it though? 184.145.18.50 (talk) 02:43, 6 March 2016 (UTC)
Suppressing unnecessary archive-urls
It would be nice to have some option to pre-emptively archiveurl things but without having any archive-related stuff appear in the rendered citation at all, either with a particular dead-url value to suppress it, or better yet, having display suppressed by default any time dead-url=no. Having archive-related stuff appear when it is not needed is cruft that badly bloats references sections when pre-emptive archiving of Web sources is done article-wide. It's bad enough that I put all my pre-emptive archive-url and archive-date parameters inside HTML comments; it adds 7 characters of edit-mode cruft per cite, versus a big bunch of it visible to everyone when left un-commented-out. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 00:32, 9 February 2016 (UTC)
- This should not be difficult. I did and then reverted a simple test to prove that a tweak to the code that handles the case of
|dead-url=no
worked as you described (no archive output). I'm not sure that|dead-url=no
is the best parameter value to use to suppress the archive output. The historic definition means that the|url=
is still assigned to|title=
and 'Archived' in the archive out put is linked: - We already have
unfit
andusurped
which keep the archive text output but don't link to the original url:{{cite web |title=Title |url=//example.com |archive-url=//example.org |archive-date=2016-02-08 |dead-url=unfit}}
- "Title". Archived from the original on 2016-02-08.
- Adding another keyword to handle this particular case shouldn't be a problem. Provide an appropriate keyword.
- —Trappist the monk (talk) 01:04, 9 February 2016 (UTC)
- Nominate
hidden
. It may be more intuitive to change|dead-url=
to|url-state=
. 208.87.234.201 (talk) 14:53, 9 February 2016 (UTC)- I could go with "hidden". But having the display off by default would be better. We can have a bot check for dead links and turn the display on for cases that need it. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 14:29, 10 February 2016 (UTC)
- Nominate
Italics in publisher
May we use italics in |publisher=
when it is a newspaper? SLBedit (talk) 00:49, 9 February 2016 (UTC)
- What's wrong with using
|newspaper=
? E.g.- {{cite news|title=Headline|date=February 8, 2016|newspaper=[[Los Angeles Times]]|publisher=[[Tribune Publishing]]}}
- "Headline". Los Angeles Times (Tribune Publishing). February 8, 2016.
- (although I would normally omit the publisher in this case). —David Eppstein (talk) 00:54, 9 February 2016 (UTC)
- I normally use
{{cite web}}
when using a source from a newspaper's website. SLBedit (talk) 01:06, 9 February 2016 (UTC)- I'm not sure why you should: it's a newspaper, regardless of whether you are reading the print or online version, just like en e-book is still a book and an online scientific journal is still a journal. But if you insist, you can use
|work=
:- {{cite web|title=Headline|date=February 8, 2016|work=[[Los Angeles Times]]|publisher=[[Tribune Publishing]]}}
- "Headline". Los Angeles Times. Tribune Publishing. February 8, 2016.
- —David Eppstein (talk) 01:15, 9 February 2016 (UTC)
- Yes,
|work=
(alias for|website=
) adds italics. SLBedit (talk) 02:59, 9 February 2016 (UTC)- What is the reason for
{{cite web}}
to display a website's name in italics? SLBedit (talk) 03:07, 9 February 2016 (UTC)- cs1|2 take their styling cues from standard published style guides like MLA, APA, CMOS. No doubt, we've made certain styling decisions ourselves, but in general, cs1|2 is guided by those established style guides. There is this, which on pages 4 and 5, compares three style guides for citing online material:
- "The Purdue OWL: Citation Chart" (PDF). Online Writing Lab. Purdue University. pp. 4–5.
- If one is to believe that, website names are rendered in italics in citations.
- —Trappist the monk (talk) 12:37, 9 February 2016 (UTC)
- cs1|2 take their styling cues from standard published style guides like MLA, APA, CMOS. No doubt, we've made certain styling decisions ourselves, but in general, cs1|2 is guided by those established style guides. There is this, which on pages 4 and 5, compares three style guides for citing online material:
- What is the reason for
- Yes,
- I'm not sure why you should: it's a newspaper, regardless of whether you are reading the print or online version, just like en e-book is still a book and an online scientific journal is still a journal. But if you insist, you can use
- I normally use
- The answer to your question is: no you may not use italics in
|publisher=
. Markup and static text in rendered citations is the duty and obligation of the template. The cs1|2 templates provide a machine readable version of the rendered citation as metadata. By adding extraneous markup and text to parameter values, you corrupt that metadata. This is documented in all of the cs1|2 templates at, for example, Template:Cite_web#COinS. - —Trappist the monk (talk) 01:19, 9 February 2016 (UTC)
- Okay. SLBedit (talk) 02:59, 9 February 2016 (UTC)
- Also, do not confuse publisher with publication. Newspapers are publications; they have publishers. --Redrose64 (talk) 12:03, 9 February 2016 (UTC)
- Which in many cases take the same name as their publication. --Izno (talk) 13:15, 9 February 2016 (UTC)
- In reality, not exactly (nitpick). Publishers have designations (Inc., Ltd.) etc. It is a convention not to include these in citations which sometimes makes publication-title=publisher-name. 208.87.234.201 (talk) 14:58, 9 February 2016 (UTC)
-
- That's why the wording here says "substantially" the same. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 14:26, 10 February 2016 (UTC)
- A recent discussion on this page showed that, while there are strong opinions, there is no documented community consensus on the use of
|publisher=
in a news context. I welcome anyone to go to a more public venue and try to establish such a consensus. ―Mandruss ☎ 15:27, 9 February 2016 (UTC)
-
- In reality, not exactly (nitpick). Publishers have designations (Inc., Ltd.) etc. It is a convention not to include these in citations which sometimes makes publication-title=publisher-name. 208.87.234.201 (talk) 14:58, 9 February 2016 (UTC)
- Which in many cases take the same name as their publication. --Izno (talk) 13:15, 9 February 2016 (UTC)
- Also, do not confuse publisher with publication. Newspapers are publications; they have publishers. --Redrose64 (talk) 12:03, 9 February 2016 (UTC)
- Okay. SLBedit (talk) 02:59, 9 February 2016 (UTC)
- Agreed with David. Using
{{cite web|title=Aliens Invade Roswell|...|website=latimes.com|publisher=''[[Los Angeles Times]]''}}
is an abuse of the parameters. If you insist on drawing a distinction between the online and print editions (this should only be done when an article appears in one but not the other, or when it appears in different form in one vs. the other), do{{cite news|title=Aliens Invade Roswell|...|work=[[Los Angeles Times]]|edition=online}}
: Doeh, Janet (April 1, 2016). "Aliens Invade Roswell". Los Angeles Times (online ed.). — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 14:24, 10 February 2016 (UTC)
Why should I use {{cite news}} for news and articles available on a newspaper's website if those articles are different from the (printed) newspaper itself? (I'm not discussing an online edition of a printed newspaper.) SLBedit (talk) 18:28, 10 February 2016 (UTC)
- I don't know, maybe because they are news? ―Mandruss ☎ 19:06, 10 February 2016 (UTC)
- Web news. SLBedit (talk) 19:36, 10 February 2016 (UTC)
- News nonetheless. Perhaps you wish to propose
{{cite webnews}}
, since{{cite news}}
is clearly not up to the task. Before you do that, see WP:BIKESHED. ―Mandruss ☎ 19:39, 10 February 2016 (UTC)- But a source from a newspaper's website is not always news. SLBedit (talk) 22:49, 10 February 2016 (UTC)
- For that source,
{{cite web}}
would probably be more appropriare. That doesn't mean you can't use{{cite news}}
for the items that are news. You don't have to use the same template for everything on a given site. ―Mandruss ☎ 22:55, 10 February 2016 (UTC)- Okay. SLBedit (talk) 23:00, 10 February 2016 (UTC)
{{cite news}}
says, right at the top,- This Citation Style 1 template is used to create citations for news articles in print, video, audio or web.
- Nothing in that sentence prevents it from being used for a news story on a newspaper's website. If you don't want to use the
|newspaper=
parameter, you can use|work=
or|website=
, as I explained above at 23:33, 31 January 2016. --Redrose64 (talk) 00:03, 11 February 2016 (UTC)- What should I use for a magazine that is part of a newspaper? I'm inclined to use
{{cite magazine}}
with|newspaper=
, which is an alias for|magazine=
. SLBedit (talk) 00:59, 11 February 2016 (UTC)- My answer depends on one factor, if that magazine is a nationally printed or recognizable item that's inserted in a paper, like Parade, versus something specific to a single paper. For the former, I'd cite the magazine with no reference to the enclosing paper as it wouldn't matter which paper that included it was consulted. In the latter case, I'd probably cite it as a department of the enclosing paper since you'd need to find that specific paper to find that magazine. Things like The New York Times Book Review, which are recognizable as their own publications would probably fall into the former case as well. Imzadi 1979 → 10:12, 11 February 2016 (UTC)
- I would do it the other way round - you're citing a news source, so use
{{cite news}}
and since it's not the actual newspaper but its magazine, use e.g.|magazine=The Sunday Times Magazine
. --Redrose64 (talk) 14:24, 11 February 2016 (UTC)- Agree with Imzadi1979. Most newspaper "magazines" cannot be purchased/subscribed to/searched-for independently, and therefore they cannot be verified independently of the enclosing newspaper. So they should not be cited independently. Most newspaper publishers in my experience call them their newspaper's "magazine section". The proper citation would be:
{{cite news|department=Magazine|newspaper=Newspaper}}
. 72.43.99.146 (talk) 15:25, 11 February 2016 (UTC)- The magazine (yes, it's printed "magazine" in the cover) I'm referring to is like a supplement, it
cannotcould not be bought separately. It came with the newspaper. I don't have the newspaper anymore, but I know its issue number, which is also printed in the magazine's cover. SLBedit (talk) 18:50, 11 February 2016 (UTC)- The issue numbers of supplementary magazines don't necessarily correspond with those of the newspaper itself, particularly when the magazine hasn't always been included: The Sunday Times Magazine began in 1962, whereas The Sunday Times began some 140 years earlier. Although intended for sale together, they're often printed in different plants, and supplied to the newsagent in different bundles - my younger brother had a paper round, and had to make sure that he put the correct supplement inside each Sunday newspaper before he delivered it. --Redrose64 (talk) 00:58, 12 February 2016 (UTC)
- The magazine (yes, it's printed "magazine" in the cover) I'm referring to is like a supplement, it
- Agree with Imzadi1979. Most newspaper "magazines" cannot be purchased/subscribed to/searched-for independently, and therefore they cannot be verified independently of the enclosing newspaper. So they should not be cited independently. Most newspaper publishers in my experience call them their newspaper's "magazine section". The proper citation would be:
- I would do it the other way round - you're citing a news source, so use
- My answer depends on one factor, if that magazine is a nationally printed or recognizable item that's inserted in a paper, like Parade, versus something specific to a single paper. For the former, I'd cite the magazine with no reference to the enclosing paper as it wouldn't matter which paper that included it was consulted. In the latter case, I'd probably cite it as a department of the enclosing paper since you'd need to find that specific paper to find that magazine. Things like The New York Times Book Review, which are recognizable as their own publications would probably fall into the former case as well. Imzadi 1979 → 10:12, 11 February 2016 (UTC)
- What should I use for a magazine that is part of a newspaper? I'm inclined to use
- Okay. SLBedit (talk) 23:00, 10 February 2016 (UTC)
- For that source,
- But a source from a newspaper's website is not always news. SLBedit (talk) 22:49, 10 February 2016 (UTC)
- News nonetheless. Perhaps you wish to propose
- Web news. SLBedit (talk) 19:36, 10 February 2016 (UTC)
By far the most important things about citations are:
- To facilitate verifiability. Give the reader a link they can click on to verify the information. And it's nice if the rendered citation looks neat and professional, too.
- To help combat link rot. When the link for a source goes dead, it's easier to find its new location (if any) if the cite contains information beyond the URL, such as title, author names, date, etc.
As long as your cite satisfies those two goals, the rest is trivial detail. Make some attempt to follow whatever guidance is given in the doc. Where something is not covered in the doc, or the doc is ambiguous, use your best judgment. Many of the things we agonize over make no difference in what the reader sees, so we should cease agonizing over them. Even when they make a difference in what the reader sees, it's usually a minor formatting difference that is meaningless to most readers.
My opinions. ―Mandruss ☎ 01:33, 11 February 2016 (UTC)
author-link effciency
It would be helpful if |author[N]-link=y
would auto-grab values from the author/first/last[N] parameters and use them. About 80% of the time, no disambiguation or other alteration is needed (unless you use one of those awful citations styles that force the use of initials, which should be banned on WP, but that's another matter). — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 14:04, 10 February 2016 (UTC)
- This would cover our article references in a sea of red links. Is that desirable? Most authors do not pass notability criteria. – Jonesey95 (talk) 14:27, 10 February 2016 (UTC)
- How about having the author-link not display if no target is found? Just a little more run-time overhead. ~ J. Johnson (JJ) (talk) 19:47, 10 February 2016 (UTC)
- But the same benefit would apply to other parameters that can accept wikilinks. So the first thing we'd see would be a thread saying, hey, if we have this cool autolinking feature for
|author-link=
, why not|work=
and its aliases? And so on. Hard to justify saying yes to one and no to the rest, hard to justify the overhead to do all of them, in my opinion. Slippery slope, Unintended consequences. ―Mandruss ☎ 19:52, 10 February 2016 (UTC)- This proposal makes absolutely no sense. To reinforce what Jonesey said above, 99.9% of authors currently or will ever have a Wikipedia page devoted to them. Implementing this proposal would convert the reference section of many articles into a sea of red. Also the
|author-link=y
parameter makes no sense. If you are going to the trouble of using that, why not just use|author-link=
as it was originally intended and only use it if and only if the corresponding page exists? (For the remaining 0.1% of authors that do have articles, it would be simple enough for a bot to create systematic redirects from the Vancouver style author name to the target article so that we can avoid that awful first1, last1, ... parameter bloat, but that's another matter ;-) Boghog (talk) 20:25, 10 February 2016 (UTC)- To link author names in
|vauthors=
, use|author-linkn=
wheren
is that author's position in the|vauthors=
list. Same is true for|veditors=
. Bots to create redirects not needed. - —Trappist the monk (talk) 20:37, 10 February 2016 (UTC)
- Implementing this proposal would convert the reference section of many articles into a sea of red - No reading of SMcCandlish's proposal suggests such an outcome. No reading of J. Johnson's proposal suggests such an outcome. Both mentions of "sea of red" have been unfounded. I assumed that Jonesey95 simply misread the proposal, but to continue saying that is puzzling to me.
I assume the point of SMcCandlish's proposal is that|last=Ishihara
|first=Shintaro
|author-link=Shintaro Ishihara
is significantly more difficult and time-consuming for the average, non-techy user than|last=Ishihara
|first=Shintaro
|author-link=y
, as well as being a case of data redundancy/duplication. It has a small upside and no downside that I can see, aside from the one-time developer effort, and a small bit of feature creep. ―Mandruss ☎ 20:50, 10 February 2016 (UTC)- OK, I misread the original proposal, but I still think it doesn't make any sense. Works "80% of the time" is a non starter. In addition, there are numerous ways that an the title of an author could be spelled and authors with the same name are a frequent occurrence. It is simpler and more reliable for an editor to locate and link the author's article than relying on an automatic procedure that will frequently be wrong. Boghog (talk) 21:09, 10 February 2016 (UTC)
- The proposal assumes that the editor would first check to see if the article's title is an exact match for first+last. The only difference would be what they code. They wouldn't use the feature in cases where it wouldn't work. The 80% number is the proposer's guesstimate of the proportion of cases where it would work. ―Mandruss ☎ 21:14, 10 February 2016 (UTC)
- Assumptions concerning editor behavior are dangerous. An editor would have made a conscious decision to use the
|author-linkn=
and is more likely to have checked the target of the link. An editor using|authorn-link=y
may assume that it would work without checking. Boghog (talk) 21:33, 10 February 2016 (UTC)- A fair point. A competent editor would check for a redlink, but not all editors are that competent. At least we're now on the same page as to what the proposal means. ―Mandruss ☎ 21:38, 10 February 2016 (UTC)
- I don't like this idea. No automatic system will be able to determine if the linked-to article is the right one. Consider Diana Ross (author) - how is the system going to know that the disambiguator is necessary to distinguish from the Motown singer? --Redrose64 (talk) 00:23, 11 February 2016 (UTC)
- The system doesn't determine that, the editor does. As I've said, the editor would not code
|author-link=y
unless they have checked and determined that the correct article's title is a match for first+last. At least that's how the proposal intends for it to work. ―Mandruss ☎ 00:30, 11 February 2016 (UTC)- Expectations of editorial care and thoroughness are nearly always disappointed. While there is no indication that an editor will exercise more care and checking if s/he has to type out the full name, yet we might hope that the few extra seconds required might allow for a tad more reflection on the matter. What would be really disappointing is if some editors started thinking that the s/w will handle all the details, and blame the s/w where all they did was to type "y". ~ J. Johnson (JJ) (talk) 21:22, 11 February 2016 (UTC)
- The system doesn't determine that, the editor does. As I've said, the editor would not code
- I don't like this idea. No automatic system will be able to determine if the linked-to article is the right one. Consider Diana Ross (author) - how is the system going to know that the disambiguator is necessary to distinguish from the Motown singer? --Redrose64 (talk) 00:23, 11 February 2016 (UTC)
- A fair point. A competent editor would check for a redlink, but not all editors are that competent. At least we're now on the same page as to what the proposal means. ―Mandruss ☎ 21:38, 10 February 2016 (UTC)
- Assumptions concerning editor behavior are dangerous. An editor would have made a conscious decision to use the
- The proposal assumes that the editor would first check to see if the article's title is an exact match for first+last. The only difference would be what they code. They wouldn't use the feature in cases where it wouldn't work. The 80% number is the proposer's guesstimate of the proportion of cases where it would work. ―Mandruss ☎ 21:14, 10 February 2016 (UTC)
- OK, I misread the original proposal, but I still think it doesn't make any sense. Works "80% of the time" is a non starter. In addition, there are numerous ways that an the title of an author could be spelled and authors with the same name are a frequent occurrence. It is simpler and more reliable for an editor to locate and link the author's article than relying on an automatic procedure that will frequently be wrong. Boghog (talk) 21:09, 10 February 2016 (UTC)
- To link author names in
- This proposal makes absolutely no sense. To reinforce what Jonesey said above, 99.9% of authors currently or will ever have a Wikipedia page devoted to them. Implementing this proposal would convert the reference section of many articles into a sea of red. Also the
- But the same benefit would apply to other parameters that can accept wikilinks. So the first thing we'd see would be a thread saying, hey, if we have this cool autolinking feature for
date=, year= mismatch
Hi there. In this edit I overcame a date=/year= mismatch error but I do not feel this is a proper edit to really fix the error. What is the correct fix? The papers were re-released in 2010 and written in 1914. Ping me back. Cheers! {{u|Checkingfax}} {Talk}
04:42, 11 February 2016 (UTC)
- I don't think it was the correct fix. Your cite uses
|date=28 January 1914
which appears to refer to the date of the lecture that is Chapter 12. Generally,|date=
is the publication date. The template identifies Cambridge University Press as publisher but links to the Bartleby version. The Bartleby version is dated April 2000. According to WorldCat and GoogleBooks, the ISBN is for a 2008 Cambridge publication. Were I seeking the exact source that you are citing, I would be at a loss since I cannot extract the reality, the WP:SAYWHEREYOUGOTIT, from this collection of mismatched facts. Choose one source, and cite that. Since the Bartleby appears to support the article text, I would rewrite the cite this way:{{cite book |last1=Quiller-Couch |first1=Sir Arthur |title=On the Art of Writing: Lectures Delivered in the University of Cambridge, 1913–1914 |edition=Online |url=http://www.bartleby.com/190/ |access-date=3 March 2012 |date=2000 |orig-year=1916 |publisher=Bartleby.com |chapter=XII. On Style |chapterurl=http://www.bartleby.com/190/12.html |at=¶6}}
- Quiller-Couch, Sir Arthur (2000) [1916]. "XII. On Style". On the Art of Writing: Lectures Delivered in the University of Cambridge, 1913–1914 (Online ed.). Bartleby.com. ¶6. Retrieved 3 March 2012.
- —Trappist the monk (talk) 11:15, 11 February 2016 (UTC)
Update to the live cs1|2 modules weekend of 20–21 February 2016
I propose to update the cs1|2 modules over the weekend of 20–21 February 2016. The changes are:
- bug fix; format/title type order in
{{cite map}}
; discussion - query and fragment delimiters in
split_url()
; discussion - language code 'no' spoof no longer required; discussion
- presentation tweaks; discussion
- bug fix in
link_title_ok()
; discussion - add language code 'be' to
format_script_value()
;
to Module:Citation/CS1/Configuration:
- oclc error checking; discussion
- presentation tweaks; discussion
to Module:Citation/CS1/Date validation:
- tweak
get_month_number()
andis_valid_month_season_range()
; better code practices;
to Module:Citation/CS1/Identifiers:
- oclc error checking; discussion
—Trappist the monk (talk) 12:50, 14 February 2016 (UTC)
- Do you have an opinion on the section "Status of filtering square brackets in URLs" above? I think it would be helpful to add this check. Thanks. – Jonesey95 (talk) 14:13, 14 February 2016 (UTC)
- I don't. At least not at the moment. More at the original discussion.
- —Trappist the monk (talk) 18:30, 14 February 2016 (UTC)
Suggestion for orig-date= parameter
In many cases, where we currently use the |orig-year=
parameter, the full original date is known (and sometimes even important or at least insightful to know), but our |orig-year=
parameter only accepts a year, not a full date. I would like to suggest to either relax the error checking of the |orig-year=
parameter or to add an |orig-date=
parameter to the cite template framework accepting a date similar to the |date=
parameter. The existing |orig-year=
parameter could be deprecated and mapped to the new |orig-date=
parameter. --Matthiaspaul (talk) 18:05, 15 February 2016 (UTC)
- There is no error checking on
|orig-year=
:{{cite book |title=Title |date=2016 |orig-year=some text in orig year that clearly isn't a year}}
- Title. 2016 [some text in orig year that clearly isn't a year].
- —Trappist the monk (talk) 18:09, 15 February 2016 (UTC)
-
- Thanks for the hint, I haven't tried stuffing full dates into
|orig-year=
for quite a while, but I seem to remember that it threw an error message when I tried back then. Anyway, even better this way. - So my suggestion is basically to "rename"
|orig-year=
into|orig-date=
and change the documentation accordingly. - --Matthiaspaul (talk) 19:23, 15 February 2016 (UTC)
- Thanks for the hint, I haven't tried stuffing full dates into
-
Suggestion for edition= parameter to treat raw numbers
I would like to suggest an addition to the |edition=
parameter, so that it would treat at least the numbers 1..9 (perhaps 1..99) as symbols, so that we no longer have to write |edition=3rd
, but just |edition=3
etc. It would make the parameter list easier to parse and edit by editors (at least in the default cases), it would make it easier to change the output format of the template in the future, and it would aid automatic processing by bots, translation services, etc. Since the use of raw numbers is not conflictive with the existing usage of the parameter, it should be very easy to implement this. --Matthiaspaul (talk) 18:05, 15 February 2016 (UTC)
- This has occurred to me but I haven't given it much thought. Apparently in some parts of the world, '3.' (with the dot) is the same as '3rd' so if we consider this, we should standardize on one form of ordinal number.
- —Trappist the monk (talk) 18:15, 15 February 2016 (UTC)
- FWIW, I can confirm that "3." is a very common form to numerically denote "third".
- My proposal was meant to accept the value of the
|edition=
parameter symbolically only when it does not contain any other info. In all other cases, the string would be passed along unaltered. So, values like "1", "2", "3" etc. would be replaced by whatever is our preferred text to indicate a first, second, third etc. edition (f.e. "1st ed.", "2nd ed.", "3rd ed." in the English version of the template), whereas "third", "3." or "3rd" (with or without more stuff following) would not be changed in any way. So, the proposal would only cover the most common cases, but still give us the freedom to use the parameter as free-flow parameter for the more complicated cases. - Beyond the scope of the proposal, a bot could implement more complicated logic to detect obvious cases like "third", "3.", "3rd" or "Dritte Auflage" and replace them by "3" (still leaving alone anything it cannot detect reliably), but this would already be too complicated to put into the template itself, I think. So, I'm not proposing to add this to the template.
- --Matthiaspaul (talk) 19:52, 15 February 2016 (UTC)
-
-
-
- Which would be the common case, and not a problem case at all, or do I miss something?
- At present, you would normally use
|edition=3rd
and it would be rendered as "(3rd ed.)". You could continue to do this if you want to, of course. - However, following my proposal, you could simply write
|edition=3
as well (which isn't a useful value at present, as it would result in the grammatically incorrect rendering "(3 ed.)" at present). Following my proposal, this would be rendered properly as "(3rd ed.)" as well (but it could be easily adjusted to something different like "(third edition)", if we'd want to do so in the future). - There is no conflict with existing usage of the parameter, and the existing usage can continue into the future without creating problems. The point is once again to isolate semantics (information) from presentation (grammar, style).
- --Matthiaspaul (talk) 20:34, 15 February 2016 (UTC)
-
-
-
-
-
-
- The common situation is the publisher would call the edition "3rd" or "third". But especially if dealing with software, it possible a publisher would decide to call an edition just "3". Jc3s5h (talk) 20:48, 15 February 2016 (UTC)
- Yes, in the case of a software rather than a book, a publisher might very well decide to call an edition "3". But outside of a name (which would most likely end up as part of the
|title=
) wouldn't you still enter this as|edition=3rd
? After all, if you'd enter it as|edition=3
, the template displays "(3 ed.)" at present, which is grammatically incorrect. - --Matthiaspaul (talk) 22:32, 15 February 2016 (UTC)
- Yes, in the case of a software rather than a book, a publisher might very well decide to call an edition "3". But outside of a name (which would most likely end up as part of the
- The common situation is the publisher would call the edition "3rd" or "third". But especially if dealing with software, it possible a publisher would decide to call an edition just "3". Jc3s5h (talk) 20:48, 15 February 2016 (UTC)
-
-
-
Suggestion to add a printing= parameter similar to edition=
Mentioning the printing batch of a work has come out of fashion in recent years, but many older books mention both, an edition and a printing, and it may be even important to mention both since simple fixes of typographical errors and other slight corrections were often more or less "silently" incorporated into newer print runs, without marking this as a new edition. At present, both information would have to be put into the |edition=
free-flow parameter, but this results in inconsistent formatting and more difficult (automatic) parsing, therefore a separate parameter |printing=
appears beneficial to me. --Matthiaspaul (talk) 18:05, 15 February 2016 (UTC)
- I oppose any automatic parsing of
|edition=
because of the wide variety of ways publishers may describe their editions. Automatic parsing would just be a stumbling stone to mess up editors. Jc3s5h (talk) 19:36, 15 February 2016 (UTC)- Hm, you must have misunderstood my proposal, as it is about adding a
|printing=
parameter, not about adding any automatic parsing. |edition=
is and|printing=
should be free-flow parameters accepting any text. At most, I would add a special case for the case where the value given is a single numerical character ("1".."9"), as this cannot conflict with any other reasonable free-flow text (even not with other short forms like "3rd" or "3." discussed in a thread further above).- --Matthiaspaul (talk) 20:09, 15 February 2016 (UTC)
- Well, dates used to be free-form, but now we can't enter February 29, 1900 because of all the error checking. I oppose trying to parse fields that are not standardized by the outside world. "Edition" is not standardized by the outside world, so I oppose parsing it. If
|edition=
isn't parsed, then printing information can be included in the edition parameter. Jc3s5h (talk) 20:53, 15 February 2016 (UTC)- Thanks for your reply, but I'm afraid there must be a misunderstanding, still. I don't propose at all to add code to somehow "automagically" make sense of whatever an editor might put in a
|edition=
parameter (it would be way too complicated for the template to sort it out). However, I also don't propose to put printing information into the|edition=
parameter. While in lack of a proper parameter for this,|edition=
might be the next-best place to put printing information, I don't think it is wise to mix together semantically separate information, this just creates the "mess" (non-standardized and difficult to parse text) you are complaining about. Editions and printings are different properties of a work, therefore we should have different parameters for them, in particular as the|edition=
parameter automatically adds "(? ed.)", which clearly does not work for printings. - While (in the other thread above) I propose to add a non-conflicting special case (only for single-character values "1".."9") to
|edition=
(and|printing=
), both parameters should, of course, (continue to) accept any free-flow text and pass it along unaltered. So, I don't see how my proposal could in any way get in the way of your or another editor's edit style. - --Matthiaspaul (talk) 22:01, 15 February 2016 (UTC)
- Jc3s5h: I think you're raising your opposition in the wrong thread? --Izno (talk) 22:30, 15 February 2016 (UTC)
- Thanks for your reply, but I'm afraid there must be a misunderstanding, still. I don't propose at all to add code to somehow "automagically" make sense of whatever an editor might put in a
- Well, dates used to be free-form, but now we can't enter February 29, 1900 because of all the error checking. I oppose trying to parse fields that are not standardized by the outside world. "Edition" is not standardized by the outside world, so I oppose parsing it. If
- Hm, you must have misunderstood my proposal, as it is about adding a
Cite magazine with combined season date.
I'm looking to properly cite the following magazine https://issuu.com/apa1906network/docs/201510001-02 . The issue date according to the cover is "Spring/Summer 2015". How should I place this into the date field?Naraht (talk) 01:42, 17 February 2016 (UTC)
|date=Spring–Summer 2015
. We convert the slash to an en dash for consistency with our MOS.- Author (Spring–Summer 2015). "Article". Magazine.
- Imzadi 1979 → 01:57, 17 February 2016 (UTC)
- Imzadi1979 (talk · contribs)Thank You!Naraht (talk) 13:48, 17 February 2016 (UTC)
- I wonder whether seasons should be used? They are frowned upon by WP:MOS#Seasons and also by WP:SEASON. Instead, "March–August" seems to be suggested instead of "Spring–Summer". 65.88.88.126 (talk) 16:14, 17 February 2016 (UTC)
- That would apply to wording date references inline, but it can't apply to citations for a very practical resason. Changing it would remove the correct information used to locate the proper issue of a source article. Additionally, there is no one way to convert a season to a range of dates/months even once we assume which hemisphere's seasons are an appropriate starting point. Imzadi 1979 → 16:31, 17 February 2016 (UTC)
- Your reasoning is sound. An indication (per your explanation) in the doc might be helpful to editors and would-be strict MOS followers. 65.88.88.126 (talk) 16:44, 17 February 2016 (UTC)
- I think User:65.88.88.126's question illustrates why WP:MOS should be changed to clearly state that it does not apply to citations at all, and that only WP:CITE governs citations. Jc3s5h (talk) 16:45, 17 February 2016 (UTC)
- For the magazine in question, it is definitely Northern Hemisphere seasons (USA based Collegiate Greek Letter Organization), but I'd rather drop the date descriptor and just use volume and number rather than try to convert to a date range. (Ugh).Naraht (talk) 18:33, 17 February 2016 (UTC)
- @Jc3x5h, Naraht, and 65.88.88.126: at least as far as I'm concerned, in citation contexts, the name of a season or a quarter that appears on a periodical's cover as a publication date is just as valid as the name of a month, and they should be treated accordingly. As a result, the MOS needs an exception to its preference of avoiding seasons. That preference is laudable in the sense of making dates more accessible to a global audience, but it has been carried to an extreme when the context of an article makes it quite clear otherwise what is intended. However, this is not the place to discuss that other than to say that copying the season name from a periodical to a citation should always be an acceptable practice. Imzadi 1979 → 06:45, 18 February 2016 (UTC)
- @Jc3x5h, Imzadi1979, and 65.88.88.126:So where is the appropriate place to discuss it/make the policy more clear?Naraht (talk) 08:52, 18 February 2016 (UTC)
- @Naraht: I just checked, and it says at Wikipedia:Manual of Style#Seasons: "For guidelines regarding publication dates in citations, refer to Wikipedia:Citing sources § Dates and reprints of older publications." MOS:SEASON just needs a similar statement, which I proposed at WT:MOSDATE#Seasons in citation dates. Imzadi 1979 → 09:47, 18 February 2016 (UTC)
- @Naraht: the MOS has been updated to make clear that the season in an issue date is perfectly acceptable: [2] Imzadi 1979 → 23:49, 18 February 2016 (UTC)
- @Imzadi1979: Thank you a lot!Naraht (talk) 00:50, 19 February 2016 (UTC)
- @Naraht: the MOS has been updated to make clear that the season in an issue date is perfectly acceptable: [2] Imzadi 1979 → 23:49, 18 February 2016 (UTC)
- @Naraht: I just checked, and it says at Wikipedia:Manual of Style#Seasons: "For guidelines regarding publication dates in citations, refer to Wikipedia:Citing sources § Dates and reprints of older publications." MOS:SEASON just needs a similar statement, which I proposed at WT:MOSDATE#Seasons in citation dates. Imzadi 1979 → 09:47, 18 February 2016 (UTC)
- @Jc3x5h, Imzadi1979, and 65.88.88.126:So where is the appropriate place to discuss it/make the policy more clear?Naraht (talk) 08:52, 18 February 2016 (UTC)
- @Jc3x5h, Naraht, and 65.88.88.126: at least as far as I'm concerned, in citation contexts, the name of a season or a quarter that appears on a periodical's cover as a publication date is just as valid as the name of a month, and they should be treated accordingly. As a result, the MOS needs an exception to its preference of avoiding seasons. That preference is laudable in the sense of making dates more accessible to a global audience, but it has been carried to an extreme when the context of an article makes it quite clear otherwise what is intended. However, this is not the place to discuss that other than to say that copying the season name from a periodical to a citation should always be an acceptable practice. Imzadi 1979 → 06:45, 18 February 2016 (UTC)
- For the magazine in question, it is definitely Northern Hemisphere seasons (USA based Collegiate Greek Letter Organization), but I'd rather drop the date descriptor and just use volume and number rather than try to convert to a date range. (Ugh).Naraht (talk) 18:33, 17 February 2016 (UTC)
- That would apply to wording date references inline, but it can't apply to citations for a very practical resason. Changing it would remove the correct information used to locate the proper issue of a source article. Additionally, there is no one way to convert a season to a range of dates/months even once we assume which hemisphere's seasons are an appropriate starting point. Imzadi 1979 → 16:31, 17 February 2016 (UTC)
- I wonder whether seasons should be used? They are frowned upon by WP:MOS#Seasons and also by WP:SEASON. Instead, "March–August" seems to be suggested instead of "Spring–Summer". 65.88.88.126 (talk) 16:14, 17 February 2016 (UTC)
- Imzadi1979 (talk · contribs)Thank You!Naraht (talk) 13:48, 17 February 2016 (UTC)
Cite web needs a section parameter
We need a |section=
parameter in {{cite web}}. We used to have better support for this, it seems to have been "rationalised".
I'm just trying to reference a PDF hundreds of pages long. It has chapters and legalistic paragraph or section numbering, yet it's not published except on the web, it has no ISBN, it's not a "book". |section=
or |chapter=
annotation would be useful and appropriate here. Merging the section numbers into the title (as suggested) breaks downstream metadata handling. Andy Dingley (talk) 13:38, 21 February 2016 (UTC)
- This cite? So what if it doesn't have an ISBN? That source is book length, has chapters, and pages, is in electronic form which would seem to pass the duck test for an e-book. Therefore, use
{{cite book}}
. - —Trappist the monk (talk) 14:03, 21 February 2016 (UTC)
- Similar issues arise with books and other documents. Rather than sections or chapters, a more general solution might be to allow
|at=
to co-exist with|page=
/|pages=
. In this case, one would write|at=Rule 184.3
|page=208
. In others, it would be|at=Table 3.1
or|at=Map 9
in conjunction with a page number. Kanguole 14:05, 21 February 2016 (UTC)|at=
would work for me (better than calling something that isn't a book a book). I tried that, but it's either/or with|pages=
.- Incidentally (AIUI) this isn't a book and can't be readily bought as a book. That itself is a source of some annoyance to those who'd like to be able to buy it as a bound paper book, but instead keep ending up with ragged printouts. Andy Dingley (talk) 14:15, 21 February 2016 (UTC)
- If you just dislike calling it a book, use {{Citation}}, with
|mode=CS1
if you must scatter stops everywhere. :-) Peter coxhead (talk) 22:23, 21 February 2016 (UTC)
- If you just dislike calling it a book, use {{Citation}}, with
- A
|section=
parameter would be useful only in those cases (analoguous with the use of|pages=
) where the source as a whole is a sub-unit of a larger work (such as an article in a journal, or contribution that is published separately). Where one is citing a specific section (or page) then it is best not to merge a specific detail into the full citation. In the typical case where a source is cited only once it is quite acceptable to append the specific location after the template. Which is a tad cumbersome with {cite} as you have defeat the automatic terminal punctuation (with|postscript=none
). And another reason for using {citation}. Or (as Peter suggests)|mode=CS1
. ~ J. Johnson (JJ) (talk) 21:05, 22 February 2016 (UTC)
multiple author names in |author= and aliases
One of the things that I noticed recently while cleaning up Category:CS1 maint: display-editors is that there are a lot of cs1|2 templates that use |author=
to hold multiple author names. This is semantically incorrect and I can't see in our documentation that we explicitly permit multiple author names in a |last=
alias – yeah, that practice isn't specifically proscribed either but should be. The simple fix is to change |author=
to |authors=
but that's not really a fix. It's not a fix because |authors=
is not made part of the metadata:
{{cite book |title=Title |authors=one, two, three}}
<cite class="citation book">one, two, three. ''Title''.</cite><span title="ctx_ver=Z39.88-2004&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1&rft.btitle=Title&rft.genre=book&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook" class="Z3988"><span style="display:none;"> </span></span>
I've added code to extract_names()
that calls a new function name_has_mult_names()
which counts the number of separator characters (comma and semicolon). If there is more than one of these characters in a |last=
alias then the page is added to a new (not yet existing) maintenance category:
{{cite book/new |title=Title |author=one, two, three}}
- one, two, three. Title.
the same applies to |editor-last=
aliases:
{{cite book/new |title=Title |editor=one, two, three}}
- one, two, three (ed.). Title.
I don't know how many of these kinds of improper uses there are but I'm guessing that there are a lot of them. Fixing these will be a task similar to the (still incomplete) |coauthor(s)=
task. I suspect that a bot can cleanup the low-hanging fruit by converting these kinds of parameters to |vauthors=
or to individual |authorn=
parameters. When that is done, we should then convert this code so that it emits an error message. —Trappist the monk (talk) 16:32, 22 February 2016 (UTC)
- What is your plan for corporate authors that have two or more commas as part of their name? Jc3s5h (talk) 17:27, 22 February 2016 (UTC)
- Examples?
- —Trappist the monk (talk) 17:48, 22 February 2016 (UTC)
- It's obvious that corporations and partnerships can choose names that include several commas. You're the one that wants to make the templates harder to use; you should prove there are no legitimate institutional names that contain more than one comma. Jc3s5h (talk) 20:09, 22 February 2016 (UTC)
- It might be something like Abel, Baker, Charley and partners --Redrose64 (talk) 21:36, 22 February 2016 (UTC)
- So no examples then? [Proving] there are no legitimate institutional names that contain more than one comma is a bit like proving that Russell's teapot doesn't exist, isn't it? You have claimed that these names exist so the burden to prove that is yours.
-
- But, to forestall a pointless discussion about orbiting crockery and the like, I will stipulate that such corporate names exist. I can think of no better way to know if
|author=
has more than one author name assigned to it. Can you? The method won't find the cases where two names are separated a single separator character (|author=A. Smith, B. Jones
) so it is just as likely that the method will find names that legitimately have multiple separators. - —Trappist the monk (talk) 21:42, 22 February 2016 (UTC)
- My suggestion is don't implement unreliable checks and make editors do unnecessary troubleshooting when there is really nothing wrong with an author's name. Jc3s5h (talk) 14:39, 23 February 2016 (UTC)
-
- So no idea for a better method then?
- —Trappist the monk (talk) 11:24, 24 February 2016 (UTC)
- Trappist, are you seriously trying to claim that there are no corporate or partnership names with more than one comma in them? We have articles here on Adelson, Testan, Brundo & Jimenez – Baker, Donelson, Bearman, Caldwell & Berkowitz – Donovan, Leisure, Newton & Irvine – Finnegan, Henderson, Farabow, Garrett & Dunner – Robinson, Silverman, Pearce, Aronsohn, and Berman – Sullivan, Papain, Block, McGrath, & Cannavo – to pick a few examples found from briefly poking around some likely categories. —David Eppstein (talk) 01:02, 24 February 2016 (UTC)
- No.
- —Trappist the monk (talk) 11:24, 24 February 2016 (UTC)
-
- My suggestion is don't implement unreliable checks and make editors do unnecessary troubleshooting when there is really nothing wrong with an author's name. Jc3s5h (talk) 14:39, 23 February 2016 (UTC)
- But, to forestall a pointless discussion about orbiting crockery and the like, I will stipulate that such corporate names exist. I can think of no better way to know if
- It might be something like Abel, Baker, Charley and partners --Redrose64 (talk) 21:36, 22 February 2016 (UTC)
- It's obvious that corporations and partnerships can choose names that include several commas. You're the one that wants to make the templates harder to use; you should prove there are no legitimate institutional names that contain more than one comma. Jc3s5h (talk) 20:09, 22 February 2016 (UTC)
- I agree that no parameter (except in vcite) should have multiple authors. However, is it proper or useful for the cs code the enforce this? It seems to me this is not such a great problem that the cs code needs to be further complicated in a quest to Right All (citation) Wrongs. An occassional run with a special purpose bot would suffice. And then Trappist would have little more time to expand the
|title=none
feature. ~ J. Johnson (JJ) (talk) 21:09, 22 February 2016 (UTC)- I wouldn't mind a maintenance category, with the understanding that there is not yet a consensus for "fixing" the condition identified. The description of the category, and the linked help text, could make it clear that this message is merely a tracking category to identify the scale of this type of parameter usage and to look for potential false positives that could be used to refine the error check. – Jonesey95 (talk) 04:04, 23 February 2016 (UTC)
- Yes, sounds like a reasonable approach to me. --Matthiaspaul (talk) 00:50, 24 February 2016 (UTC)
- I wouldn't mind a maintenance category, with the understanding that there is not yet a consensus for "fixing" the condition identified. The description of the category, and the linked help text, could make it clear that this message is merely a tracking category to identify the scale of this type of parameter usage and to look for potential false positives that could be used to refine the error check. – Jonesey95 (talk) 04:04, 23 February 2016 (UTC)
For those cases where any single entity's name requires multiple separators, we can employ a similar trick that is used in |vauthors=
to instruct the module to skip the multiple names test:
{{cite book/new |author=(([[Baker, Donelson, Bearman, Caldwell & Berkowitz]])) |title=Title}}
The doubled parentheses must wrap the entire parameter value. If they do not, then they are not stripped from the rendering:
-
- ((Baker, Donelson, Bearman, Caldwell & Berkowitz)) more author stuff. Title.
—Trappist the monk (talk) 14:11, 24 February 2016 (UTC)
-
-
- I think we should avoid introduction of such type of text (vauthors excepted, of course) since there's no demonstrable consensus above for editing the articles which exhibit this concern. As with Jonesey and Matthias, I think a maintenance category is desirable. --Izno (talk) 14:18, 24 February 2016 (UTC)
-
Proper use of Website not explained.
From the CS1 messages it appears that it is not proper to use a URL in the website= entry for cite web. I think that needs to be *much* better explained if that is a problem. A would expect a new user to be much more likely to do {{cite web|url=http://www.example.com/widgets|title=Widgets through the ages|website=http://www.example.com}} than {{cite web|url=http://www.example.com/widgets|title=Widgets through the ages|website=Example Company}}. IMO, *either* website= needs to be specifically added to both Help:CS1 errors#External link in |<param>= (which doesn't show website as one that would be a problem and the docs on Cite web, or this CS1 error needs to be disabled.Naraht (talk) 21:13, 22 February 2016 (UTC)</nowiki>— Preceding unsigned comment added by Naraht (talk • contribs) 19:45, 22 February 2016
- In the doc for the templates, the description of
|website=
says "title of the website". I don't see how that could be interpreted as URL. - Of the multiple occurrences of
|website=
in the Examples section, none show a URL. - The error shows
|website=
as the problem parameter. - The error description lists several problem parameters and says "or any of their aliases". The doc shows that
|website=
is an alias of|work=
, which is one of the parameters listed in the error description.
That's adequate in my opinion. Any more would be unwarranted instruction creep, and people do need to learn to use the doc that's available to them. ―Mandruss ☎ 21:50, 22 February 2016 (UTC)
- I've calmed down now. I agree that the docs are as good as they could be, but it is still a fairly likely mistake. Any ideas that may help?Naraht (talk) 15:25, 23 February 2016 (UTC)
- I've added the aliases to Help:CS1 errors#External link in |<param>=. This is about users who don't read the template documentation, but adapt existing examples and are then confused by error messages. The first documentation they encounter is a subsection of Help:CS1 errors that is linked from the error. Kanguole 15:54, 23 February 2016 (UTC)
Transcript parameter for cite podcast
This question (Help talk:Citation Style 1/Archive 5#Transcript parameter for cite podcast) was asked in March 2014 and after becoming frustrated in my attempts to solve it, I left Wikipedia editing for quite some time. Will the question ever be addressed by people who know the Lua coding and can avoid all the mistakes I made in trying to solve it? It still seems a valid parameter to have for the {{Cite podcast}} template.—D'Ranged 1 VTalk 12:37, 23 February 2016 (UTC)
Unrecognized language
Is there some reason that Filipino is triggering the unrecognized language error message? It's a valid language with the code [fil], apparently. Maybe some list needs to be updated?
—D'Ranged 1 VTalk 14:25, 23 February 2016 (UTC)
fil
is not an ISO 639-1 code which is a requirement of|language=
. Neither offil
nor Filipino are recognized by MediaWiki. See names.php for the current list of supported language names and codes. Consider Tagalog (tl
).- —Trappist the monk (talk) 14:39, 23 February 2016 (UTC)
- More confusing information, then. If you look at the entry for Tagalog at List of ISO 639-1 codes, you find the following in the Notes column:
- Note: Filipino (Pilipino) has the code [fil]
- Apparently ISO 639-1 is limited to two-letter codes, although they have three-letter codes under ISO 639-2. In skimming the Wikipedia articles on Tagalog and Filipino, apparently Filipino is the standardized version of Tagalog. That's all well and good, but shouldn't we be accommodating to what people want to call their own language? I can't see us editing every citation that lists Filipino as a language to read Tagalog instead. I realize this isn't your circus, nor your monkeys, but once again I'm up against not knowing how to effect a change. How does one request that Mediawiki adopt the ISO 639-2 standard to be more inclusive? Should one even bother?
- —D'Ranged 1 VTalk 23:27, 23 February 2016 (UTC)
- What the reader sees when you use
|language=Filipino
is (in Filipino). When Module:Citation/CS1 doesn't recognize the content of|language=
, it does categorize the page and, for those who have turned on messaging, shows the maintenance category message. Maintenance messages are not necessarily error messages.
- What the reader sees when you use
- More confusing information, then. If you look at the entry for Tagalog at List of ISO 639-1 codes, you find the following in the Notes column:
-
-
- When I introduced ISO 639-1 as an option, I created a table of all of the ISO 639-1 codes and their languages. I abandoned that when I discovered the Scribunto library function
mw.language.fetchLanguageName( code, inLanguage )
. It works well enough for ISO 639-1 and to some extent with ISO-639-2. The library fails for ISO 639-2 codes what also have an ISO 639-1 code. The library appears to use the same data set as the magic word{{#language}}
. As an example,{{#language:is|en}}
– ISO 639-1- Icelandic
{{#language:ice|en}}
– ISO 639-2- ice
mw.language.fetchLanguageName('is', 'en')
returns 'Icelandic' but when the language code isice
, it returnsnil
.
- That 'anomaly' was sufficient for me to not attempt to support ISO 639-2.
- When I introduced ISO 639-1 as an option, I created a table of all of the ISO 639-1 codes and their languages. I abandoned that when I discovered the Scribunto library function
-
-
-
- The other issue that comes to mind is categorizing. Module:Citation/CS1 categorizes all templates that use
|language=
(except English). For the ISO-639-1 languages there are 185 of these categories. There are some 500-ish ISO 639-2 language codes 185 of which duplicate ISO 639-1 codes. Supporting all of them might be more work than it is worth.
- The other issue that comes to mind is categorizing. Module:Citation/CS1 categorizes all templates that use
-
-
-
- I have thought, on and off, of supporting certain ISO 639-2 codes where those codes or their associated language names appear commonly in Category:CS1 maint: Unrecognized language;
fil
and Filipino would be one such example. - —Trappist the monk (talk) 00:57, 24 February 2016 (UTC)
- I have thought, on and off, of supporting certain ISO 639-2 codes where those codes or their associated language names appear commonly in Category:CS1 maint: Unrecognized language;
-
-
-
-
- I would definitely support that solution. I agree that supporting an additional 300+ language codes is burdensome and unnecessary, but since ISO 639-1 isn't ever likely to include Filipino, it would be great to add it to our list somehow. Thanks for your very educational response!
- —D'Ranged 1 VTalk 19:04, 24 February 2016 (UTC)
-
-
-
-
-
-
- In perusing the pages in the maintenance category, I've found two anomalies already.
- If the language in
|language=
is Wikilinked, the maintenance tag is added, as in|language=[[Japanese language|Japanese]]
. - If the language is the English equivalent, it may trigger the maintenance tag, as in
|language=German
- If the language in
- While the first example is easily fixed by unlinking the language (although that's a pain), the second is more problematical. Purging the page cache removes the green maintenance tag notifications, but doesn't remove the page from the category. The relevant article is 1. FSV Mainz 05. Other articles using
|language=German
don't fall into the maintenance category, though, see Attila. - Something goofy is obviously going on, but don't ask me what. It would seem that there are numerous pages in the category that don't belong there.
- 19:28, 24 February 2016 (UTC)
- At the last update of Module:Citation/CS1 a bug in the code caused the
language_parameter()
to improperly categorize proper and correct language names (not codes) as unrecognized. That has been fixed. MediaWiki sometimes takes its time when removing pages from a category. The usual solution is to simply wait for MediaWiki to get around to doing whatever it is that needs doing to remove the page from the category. After all, there are thousands of us all making little modifications which all need MediaWiki's attention, so some things can be put off until later. - —Trappist the monk (talk) 19:58, 24 February 2016 (UTC)
- At the last update of Module:Citation/CS1 a bug in the code caused the
- In perusing the pages in the maintenance category, I've found two anomalies already.
-
-
-
The problem in the 1. FSV Mainz 05 article was apparently the use of {{de icon}}
in some raw html references. Once I converted them to Cite templates (which were widely used in the rest of the article), the page was de-listed from the Category. I'll try to remember to check back in a few days and see if the Category has been purged.
I want to expressly thank you, Trappist, for your patience and all the time you spend composing detailed, educational responses to my queries. I know I'm probably on your "HME list" (High Maintenance Editors), but I hope my wanting to improve my editing skills and Wikipedia as a whole is some sort of balance for all the energy you expend. You're very much appreciated! Thank you. —D'Ranged 1 VTalk 21:51, 24 February 2016 (UTC)
- If that were the problem, you would see the category and the error message when looking at the previous version of the article in the article's History. I do not see the category or the error message. Your edits forced the page to reload all of the templates in the page, which is what fixed the category membership.
- Standardizing the citations was the right thing to do, but it was not related to this discussion. – Jonesey95 (talk) 22:54, 24 February 2016 (UTC)
-
- Thanks! Since I'm mostly clueless about this stuff, all I can do is relate my actions and wait for someone to explain what impact they did or didn't have. I appreciate the education!
- —D'Ranged 1 VTalk 23:03, 24 February 2016 (UTC)
Author clarification
When filling out the 'author' (or first= and last=) in template:cite episode in association with quote= is this intended for:
- the name of the character who is saying this thing
- the name of the voice actor who is speaking for the character
- the name of the writer of the script
- some combination of the above.
Instructions for this in the template would be appreciated. I've been doing the characters so far since this seems the most useful, stuff like character's voice actors is explained in the cast and stuff like episode writers is explained in episode lists, so I personally think it ought to be the character who is saying the quote. Particularly since sometimes characters have multiple voice actors and episodes sometimes have multiple writers. 184.145.18.50 (talk) 18:30, 23 February 2016 (UTC)
- The
|author=
and related parameters are intended for the author of the episode being cited, not the "author" or "speaker" of the|quote=
parameter, which is used to optionally add a brief, relevant quotation from the cited episode. The|quote=
parameter doesn't accommodate identifying the speaker of the quote, as everything in the parameter is enclosed in quotation marks. - The markup for a citation might look something like this:
{{Cite episode |title=What Mary Knew |series=Alfred Hitchcock Presents |series-link=Alfred Hitchcock Presents |first=Alfred |last=Hitchcock |network=NBC |station=WMAQ |city=Chicago |date=April 14, 1958 |number=311 |quote=Mary had a secret.}}
- That would display in the references list as:
- Hitchcock, Alfred (April 14, 1958). "What Mary Knew". Alfred Hitchcock Presents. Episode 311. NBC. WMAQ.
Mary had a secret.
- Hitchcock, Alfred (April 14, 1958). "What Mary Knew". Alfred Hitchcock Presents. Episode 311. NBC. WMAQ.
- I note that the
|city=
parameter doesn't seem to function, nor is it documented at the template. I'll open a separate topic for that below. - Hope this helped!
- —D'Ranged 1 VTalk 23:56, 23 February 2016 (UTC)
It doesn't really help in where we should specify the speaker, this is more important than repeating the writer who will already be identified in using title= or date= or number= since the writer will be listed on the list. Episode writers speak through the proxies of characters so I consider them to be the primary authors and if anyone wants to list the episode writer they can be listed as author2 if necessary. Little is gained from repeating this data, everything is gained by specifying the speaker. 184.145.18.50 (talk) 20:09, 25 February 2016 (UTC)
- You have not persuaded me. Citations like this from Wallykazam! are not proper uses of
{{cite episode}}
{{cite episode |series=Wallykazam! |title=The Great Missing Potato |author=Bobgoblin |quote=Okay Wally Trollman and Norville Trollman, you may now approach the Great Wishing Potato.}}
- Do not misuse cs1|2 templates in this way. If you want to quote a character from an episode, do so, but these templates are not the proper tools for that task.
- —Trappist the monk (talk) 22:54, 26 February 2016 (UTC)
This basically means we can't use the quote= field if we want to attribute a character. We'd just manually put Bobgoblin: "Bobgoblin!" or something. How about a "speaker=" field? First/Last should be taken out and instead have author-first/author-last and speaker-first/speaker-last. It's just very convenient to use first/last to indicate the speaker.
The problem with citing writers is we don't know how specific dialogue actually is to writers. Sometimes when writers work on a show, they don't write the dialogue completely in stone and some ad-libbing occurs on part of the actors. A good example of this is Monday Night Raw. There are certainly script writers in the WWE but they only write the overall plot, they don't actually write every distinct word of the dialogue, which is why if I was quoting from an episode of Raw, the first/last would be attributed to the IRL person, not the WWE writers, particularly since there's a whole bunch of writers and I don't know their names or who was involved in what storylines.
Crediting the voice actors would be more specific, since they are the authors of their own speech, however a writer/director may have dictated it to them. I still think a "role=" field to supplement a "speaker=" field would be good though, since sometimes a voice actor will speak multiple roles in a show and you need to clarify which role did the quote.
Another issue is that sometimes, end credits do not directly associate voice actors with characters, some just give a big unspecified list of voice talent and people will not know which actor to attribute. For that reason a "role=" or "character=" would be useful. It's also useful if someone doesn't know who wrote an episode, since that info isn't always apparent or accessible if quoting from a clip where credits are not viewable. 184.145.18.50 (talk) 02:40, 6 March 2016 (UTC)
Template {{Cite episode}} undocumented parameter / error
In researching the answer to the query above, I discovered that the |city=
parameter in this template doesn't seem to function, nor is it documented. Would someone investigate, please?
—D'Ranged 1 VTalk 23:56, 23 February 2016 (UTC)
This comparison is the current Lua version against the last {{citation/core}}
version:
{{ cite episode | number=311 | last=Hitchcock | network=NBC | date=April 14, 1958 | first=Alfred | series-link=Alfred Hitchcock Presents | title=What Mary Knew | city=Chicago | quote=Mary had a secret. | station=WMAQ | series=Alfred Hitchcock Presents }} | |
Old | Hitchcock, Alfred (April 14, 1958). "What Mary Knew". Alfred Hitchcock Presents. Episode 311. NBC. WMAQ. "Mary had a secret." |
Live | Hitchcock, Alfred (April 14, 1958). "What Mary Knew". Alfred Hitchcock Presents. Episode 311. NBC. WMAQ. Mary had a secret. |
|city=
was removed from {{cite episode}}
with this edit; three years before the Lua conversion.
—Trappist the monk (talk) 01:20, 24 February 2016 (UTC)
- I've edited the documentation to reflect the deletion. The parameter no longer appears in the documentation. Is this template part of any tools that you know of that need to be checked?
- —D'Ranged 1 VTalk 01:34, 24 February 2016 (UTC)
Retrieved date precedes archived date
At Tennessee Walking Horse#Footnotes in cases where I archived dead URLs (using the archive-url= and archive-date= parameters), the Retrieved date precedes the Archived date. Some indicate they were Retrieved over a year before they were Archived. How and why is that? Also, I retrieved the Archived versions today. Isn't that an important retrieval parameter? Cheers! {{u|Checkingfax}} {Talk}
07:36, 25 February 2016 (UTC)
- Checkingfax Unless you have savvy editors who check for archived versions of sites when they access them, it's quite often the case that the site is archived long after it was accessed by the editor. In those cases, the url of the first available archived site is the one to use, as the intention is to have an archived version of the site that matches what the editor saw when s/he used it as a source. An editor always has the opportunity to either archive the site for the first time when they visit it or add an archive that is dated on the date they access the site. Sadly, it isn't common for that to happen. As for the retrieval date for the archive, that is unimportant compared to the date the site was archived. The archived date identifies which archived version was retrieved. When you retrieved that version is irrelevant, as it doesn't help identify which version is referenced.
- In glancing at your edits, I would highly recommend always including
|dead-url=
for ease in future editing. If omitted, it's understood to be"no" (meaning the original url is still live); if the original goes offline, it's easier to revise the "no" to "yes" than it is to add the parameter and value.Per Trappist below, I stand corrected. Sorry! All the more reason to include the|dead-url=
and set it tono
. - Additionally, for one of the citations you marked as dead (footnote 12), I searched Google for the title and found another url where the article had been cross-posted. I updated the url, archived the page, and added the archive parameters. I also added a parenthetical note indicating the cross-posting in the
|publisher=
parameter. For additional methods to rescue dead links, have a look at WP:DEADLINK - For notes about issues with the web archive, it's probably best to enclose them in
<!-- -->
comment brackets so they're visible to editors but not readers. I didn't fix this, and honestly don't know if it's your edit. I just happened to notice it and didn't do more research. - Thanks for your efforts to stem Link rot, which are greatly appreciated by a bunch of us! Cheers, yourself!
- —D'Ranged 1 VTalk 08:20, 25 February 2016 (UTC)
-
- If omitted, it's understood to be "no" (meaning the original url is still live).
-
- The default state of
|dead-url=
isyes
which means that when|dead-url=
is omitted or empty, the url in|url=
is dead so|title=
is linked to the url provided in|archive-url=
:{{cite book |title=Title |url=//example.com |archive-url=//archive.org |archive-date=2016-02-25 |dead-url=}}
- Title. Archived from the original on 2016-02-25.
- —Trappist the monk (talk) 10:55, 25 February 2016 (UTC)
- The default state of
-
-
- My apologies and thanks. I knew that; it was late and I was very tired! Thanks, Trappist!
- —D'Ranged 1 VTalk
-
-
- Since the process can be automated perhaps one of the bot maintainers should add a task to deliberately trigger archivation of a (new) snapshot at archive.org whenever a new link gets added to an article. While this should be triggered immediately if the link was added by editors with more than perhaps 1000 edits, archivation of links added by new editors or IPs would be triggered only, if they survived in the article for more than a week. Something like this would help alot in keeping information accessible long-term and help improving the quality of articles while keeping potential abuse at a minimum.
- --Matthiaspaul (talk) 22:44, 25 February 2016 (UTC)
Author titles or jobs
A lot of time, like when arguing over whether a source is from a "scholar" or not, I think listing the person's title or job at the time they wrote a book would be useful. Is it possible to have a field for that?
It seems to fall outside the bounds of |last= |first= splitting. Should we just use |author= and manually do "Last, First" ? In that case how would we format a mention of their title or job? After, before, in-between? 184.145.18.50 (talk) 20:06, 25 February 2016 (UTC)
- Probably not. For example, I suspect that many authors of articles in medical journals and other scholarly works are entitled to be addressed as doctor or professor; many I suspect have PhDs yet, that information is not included in citations or bibliographies. That being the case, such titles and honoraria should not be made part of cs1|2 citations.
- —Trappist the monk (talk) 20:34, 25 February 2016 (UTC)
- [ec] Not a good idea. It is outside the scope of citation to evaluate the goodness, authority, relevance, etc. of the source or the author(s), and it would be a very large can worms to address anything like that in a citation. If there is any question regarding the reliability or applicability of a particular source or author in particular case that is resolved on the Talk page of the article where the question is raised. Also, job titles are very poor indicators for such purposes. Note that when Einstein published his theory of relativity he was just a clerk in a patent office. ~ J. Johnson (JJ) (talk) 20:39, 25 February 2016 (UTC)
- As a compromise, perhaps not titles and job specifications (they are just "sounds and smoke"), but direct professional affiliations or associations (if mentioned).
- I have run into various cases, where an author's affiliation / association with a particular company or research facility (f.e. Hewlett Packard, IBM or General Electric) was prominently mentioned in an article or on a book's front cover, to the extent that this information almost had "publisher status", even though the work was published by someone else. Related research or the work itself might have been initiated and/or sponsored by the associated company. In such cases I consider an author's association a vital part of a reference, and I have seen references in books where such information was included as part of the reference.
- I have sometimes put this information into the
|location=
parameter, but a dedicated parameter would be more desirable in order to allow automatic parsing and ensure a consistent display format. Something like|author-assoc=
and|editor-assoc=
(or something more generic like|author-suffix=
and|editor-suffix=
), displayed after the author name and separated by comma or in brackets. Like in: Doe, John, IBM; Zweistein, Willibald, CERN (2016). Title XYZ Press (Ghosttown, USA).- --Matthiaspaul (talk) 23:21, 25 February 2016 (UTC)
- It's advertising. Hewlett Packard or whoever have put up money towards the cost of producing the book, in return for getting their name on the front. The author would probably have written exactly the same book without HP's cash, but might not have found a publisher willing or interested enough to take a gamble. --Redrose64 (talk) 00:15, 26 February 2016 (UTC)
- In some cases, that might be true, in others the research or development work the book is about was funded and conducted at that company and by the author of the book, so without the company the work would not exist in the first place, and without the company's consent and approval (and perhaps endorsement) the book could not have been written as the author would typically be under NDA prohibiting him from sharing his insights with anyone outside the company.
- Examples:
- (Schmid was employed by General Electric when he wrote this book on decimal computation, and the book introduces him in the front matter like "Hermann Schmid, General Electric Company, Binghamton, New York" whereas the publishing company is located elsewhere. I put the company information into the
|location=
parameter, but it would certainly look more logical if the "General Electric Company" thing would immediately follow the author's name):
- Schmid, Hermann (1974). Decimal Computation (1 ed.). General Electric Company, Binghamton, New York, USA: John Wiley & Sons. ISBN 0-471-76180-X.
- (Walther was employed by HP when he carried out the R&D work on CORDIC for the first scientific handheld electronic calculator HP-35. In that capacity he published a paper at a conference. I tried to use
|via=
and|publisher=
to reflect this, but the result is unsatisfactory):
- Walther, John Stephen (May 1971). Written at Palo Alto, California, USA. "A unified algorithm for elementary functions" (PDF). Proceedings of the Spring Joint Computer Conference (Atlantic City, New Jersey, USA: Hewlett-Packard Company) 38: 379–385 – via American Federation of Information Processing Societies.
- (Chen and Ho were both IBM employees when they created the so-called Chen-Ho encoding for IBM):
- Chen, Tien Chi; Ho, Irving T. (January 1975). "Storage-Efficient Representation of Decimal Data". Communications of the Association for Computing Machinery 18 (1): 49–52.
- (Schmid was employed by General Electric when he wrote this book on decimal computation, and the book introduces him in the front matter like "Hermann Schmid, General Electric Company, Binghamton, New York" whereas the publishing company is located elsewhere. I put the company information into the
- I don't see cases like these as blatant advertising, even though it may have a promotional side-effect (because of the work they did). I see this information as part of the bibliographic data that belongs into the citation somehow. In some cases, it might be possible to use the
|others=
parameter treating the company as kind of a co-author or other contributor, but this would break for multiple authors. - What I'm trying to say is that the OP's suggestion has some merits. Some kind of suffix parameter associated with each of the author / editor parameters could be put to good use in quite a few cases.
- --Matthiaspaul (talk) 11:20, 26 February 2016 (UTC)
|location=
is for the town or city that the publisher is located in, not a full postal address nor anything not directly related to the company that published it. If General Electric Company have published the book - and so are named as publisher on the copyright page - then|location=Binghamton, NY
|publisher=General Electric Company
is valid. Otherwise, it's|location=Hoboken, NJ
|publisher=John Wiley & Sons
and General Electric Company don't get a mention. --Redrose64 (talk) 12:02, 26 February 2016 (UTC)- (edit conflict)
- As I think someone said before in a different way, this is an attempt to assert notability via citations. That's not what citations are for. Citations are a way for a reader to verify the information that is included in the article is sourced from a particular place. Their main function is the location of the information, not communicating the quality of the information. There are policies and guidelines for what can and cannot be used as a verifiable, reliable source, if the citation is included in the article one must assume that the source meets the criteria necessary for inclusion.
- If there are disputes over sources used, they need to be resolved on the article's Talk page, not in the citations themselves. With millions of articles on this Wikipedia alone, imagine the additional space needed to include justification for a citation in every citation? The examples above include information totally superfluous to enabling a reader to locate the citation. Adding a company name to the
|location=
parameter, for example, also breaks any metadata indexing, as General Electric is not a location. Please use the templates in the way the are intended to be used: - Addendum As for including credentials, etc., it's also not the job of the citation to identify the qualifications of the person being cited. If we don't list Albert Einstein's accomplishments in citations, I see no reason to list anyone else's. Just my 2¢. 12:35, 26 February 2016 (UTC)
- —D'Ranged 1 | VTalk : 12:28, 26 February 2016 (UTC)
- It's advertising. Hewlett Packard or whoever have put up money towards the cost of producing the book, in return for getting their name on the front. The author would probably have written exactly the same book without HP's cash, but might not have found a publisher willing or interested enough to take a gamble. --Redrose64 (talk) 00:15, 26 February 2016 (UTC)
- --Matthiaspaul (talk) 23:21, 25 February 2016 (UTC)
-
-
-
-
-
-
- Yes! Citation are for identifying and locating sources, not for any kind of comment about the source or its authors. And any such misuse of the citations should be removed. ~ J. Johnson (JJ) (talk) 22:23, 26 February 2016 (UTC)
- Exactly so. Peter coxhead (talk) 20:42, 27 February 2016 (UTC)
- Yes! Citation are for identifying and locating sources, not for any kind of comment about the source or its authors. And any such misuse of the citations should be removed. ~ J. Johnson (JJ) (talk) 22:23, 26 February 2016 (UTC)
-
-
-
-
-
Error message at preview
I'm running into this more and more as I try to clean up pages and need a way to identify the miscreant citation, please.
When I press Preview, I get a message similar to this:
-
- Warning: [Article name] is calling Template:Cite web with more than one value for the "publisher" parameter. Only the last value provided will be used.
Maybe I'm tired, but short of eyeballing every instance of {{Cite web}}
, I don't know how to identify this. I'm sure there's a RegEx search that would help, but that is beyond my current skill set.
Wouldn't this error message be better appearing next to the guilty citation in the Refs list like missing/misspelled parameter name messages? Is there some reason it doesn't? And shouldn't this be a maintenance category as well?
Thanks!—D'Ranged 1 | VTalk : 19:03, 27 February 2016 (UTC)
-
- That error message is is not created by Module:Citation/CS1. The module does not see duplicate parameters; it gets one parameter of each name even if there are 50 of them. The error message is created by MediaWiki.
-
- There is a tool that may be helpful (I haven't used it so don't know): User:Frietjes/findargdups
- —Trappist the monk (talk) 19:16, 27 February 2016 (UTC)
-
-
- Thanks! I gave it a try and it failed, but I left a message at the author's Talk page. Apparently such pages are categorized, so maybe someone else will be able to fix it. I so appreciate your fount of knowledge, kind sir Trappist!
- —D'Ranged 1 | VTalk : 20:27, 27 February 2016 (UTC)
-
-
-
-
- To find these errors efficiently, add the following code to your vector.js or monobook.js file (whichever one you use):
-
-
//Find duplicate template parameters importScript('User:Frietjes/findargdups.js'); // [[User:Frietjes/findargdups.js]]
-
-
-
- Then go to the article again, click Edit, and look for the "Find dups" link in your left toolbar, under Tools. Click it, and it will tell you which template has a repeated parameter.
-
-
-
-
-
- Frietjes, SporkBot, and a handful of other editors have been working on emptying Category:Pages using duplicate arguments in template calls, which is down to about 15,000 articles from a high of well over 50,000 when the error tracking was put in place. – Jonesey95 (talk) 22:41, 27 February 2016 (UTC)
-
-
More help with foreign languages
I just discovered an article where 99.9% of the citations are in Portuguese! Someone went through and changed all the parameter names, but left the foreign dates behind, which is what triggered the cleanup from me. (That was not fun, by the way.)
So we have citations with valid dates and parameter names, but none of the citations use |translate-title=
or |language=
. Several also use the |quote=
parameter, stuffed with Portuguese. In other words, these citations are nearly worthless on the English Wikipedia.
I can't find a specific {{Cleanup}} template for this situation and wondered if anyone here had any advice on how to tag the page?
Thanks!—D'Ranged 1 | VTalk : 20:33, 27 February 2016 (UTC)
- It is helpful to provide a link to the page when you have a question like this.
- BattyBot will clean up most foreign dates in citation templates. It runs that task about once a month, so I usually fix the unsupported parameters and leave the dates in their original language.
- You might try {{cleanup-translation}}. – Jonesey95 (talk) 23:00, 27 February 2016 (UTC)
-
- @D'Ranged 1: BattyBot just ran over Category:CS1 errors: dates - did it fix the article you discovered? GoingBatty (talk) 03:22, 1 March 2016 (UTC)
-
-
- The article is A Regra do Jogo; I fixed all the dates in the citations by hand, not really thinking about bots that would do that. Since Portuguese isn't even remotely in my wheelhouse, I had to find a translation of the names of months, lol. All's well and I'll know better next time. Thanks, GoingBattyand Jonesey95
- —D'Ranged 1 | VTalk : 03:36, 1 March 2016 (UTC)
-
|language= and ISO 639-2 codes
Module:Citation/CS1 queries MediaWiki to see if the value assigned to |language=
is a supported (and thus valid) language. |language=
allows language names and two-character ISO 639-1 codes (|language=English
, |language=en
). When these kinds of names or codes are recognized by MediaWiki the module adds the page to the appropriate category in Category:CS1 foreign language sources.
I have tweaked Module:Citation/CS1/sandbox to accept MediaWiki-recognized three-character language codes and associated names. Because there are some 500 ISO 639-2 languages but comparatively few uses, I have elected to create a single category, Category:CS1 ISO 639-2 language sources, where the member pages are sorted by language code. That sorting is probably not optimal but for the time being should serve until we better understand the categorization needs.
{{ cite book | language=Northern Frisian | title=Title }} | |
Live | Title (in Northern Frisian). |
Sandbox | Title (in Northern Frisian). |
{{ cite book | language=frr | title=Title }} | |
Live | Title (in frr). |
Sandbox | Title (in Northern Frisian). |
This change does not address the issues raised in the previous discussion about languages and codes not supported by MediaWiki.
—Trappist the monk (talk) 15:08, 28 February 2016 (UTC)
Script variants of parameters for author, editor, etc.
We have a |script-title=
parameter for titles in foreign languages written in other scripts like Arabic, Chinese, Cyrillic, Greek, Hebrew, Japanese, Korean, Vietnamese, etc. For obvious reasons, we need a similar mechanism for the range of |author=
and |editor=
parameters (because there are often many different transliterations in use and only the spelling in the original script is representative for a name). Adding script- variants may also be useful for |chapter=
and|publisher=
.
At present, editors often stuff both spelling variants into the |author=
and |editor=
parameter (or don't use the templates), putting the original representation of a name in brackets. While this usage may be acceptable for the |author=
and |editor=
parameters, it breaks when specifying script names (like ja:) or when using the |-first=
and |-last=
parameter variants. For consistency, the "script-" extension should always be the first part of the parameter name. These parameter variants should follow the same syntax and logic as the existing |script-title=
parameter, except for displaying the name in brackets. Examples:
- (for a title, which was only available in Russian):
- Ryzhik, I. M. (Рыжик, И. М.); Gradshteyn, I. S. (Градштейн, И. С.) (1951). Tablitsy integralov, summ, ryadov i proizvedeniy Таблицы интегралов, сумм, рядов и произведений [Tables of integrals, sums, series, and products] (in Russian) (Third ed.). Gosudarstvennoe Izdatel'stvo Tehniko-Teoretičeskoj Literatury (Государственное издательство технико-теоретической литературы).
- (for an English title with two Russian authors):
- Gradshteyn, I. S. (Градштейн, И. С.); Ryzhik, I. M. (Рыжик, И. М.); Jeffrey, Alan; Zwillinger, Daniel (2007). Table of Integrals, Series, and Products (Seventh ed.). Academic Press.
Thanks. :--Matthiaspaul (talk) 17:17, 28 February 2016 (UTC)
- We have
|script-chapter=
. - —Trappist the monk (talk) 17:54, 28 February 2016 (UTC)
- Thanks for the hint. Not yet documented at Help:Citation Style 1. --Matthiaspaul (talk) 18:20, 28 February 2016 (UTC)
Date ranges
It often happens that a multi-volume work, or one published in parts (sometimes a few sheets at a time) has a date which needs to be expressed as a range, like 1844-1875, rather than a single year. The "Cite book" template currently returns a red warning if a range is entered in the date= or the year= field. A range of this kind is not the same thing as "origyear", and putting the range in origyear= without a date= results in the display of no date at all, hardly helpful. Could we please be permitted to have a date range in date= or at least year= to express the true situation for publications of this kind. With many thanks, Chiswick Chap (talk) 13:40, 29 February 2016 (UTC)
- Does the help text linked by the error message not answer this question?
{{cite book |title=Title |date=1844-1875}}
- Title. 1844-1875. Check date values in:
|date=
(help)
- Title. 1844-1875. Check date values in:
- —Trappist the monk (talk) 13:47, 29 February 2016 (UTC)
-
-
- It did, I had read a lot of irrelevant "help" text and tried several combinations. I do think that a plain hyphen or dash should work, as should a spaced en-dash; a bot can convert these if need be but frankly I don't see why anyone would care. Among the problems for the en-dash is that the citation tool doesn't provide for it, so one has to enter a hyphen in the tool, press ok and then tweak the text. It's also not a good choice for people entering the cite book code manually, a hyphen would be far more convenient. But we have to keep the wiki-gnomes busy. Chiswick Chap (talk) 14:04, 29 February 2016 (UTC)
- We follow MOS, which specifies an unspaced en dash for year ranges. If you want WP to be more flexible, start a conversation at the appropriate MOS talk page. Be prepared for a lively discussion. – Jonesey95 (talk) 15:53, 29 February 2016 (UTC)
- En dashes can be entered at cursor position in any edit window (right next to the "Insert" drop down menu at the bottom of the edit window). My personal preference is to use {{en dash}} since it also visually signifies to other editors the use of an en dash, and hints the link to the template page, where more info is available. Additionally, it does not mess the metadata. I agree that MOS should be followed (as is already generally the case, imo) when it doesn't conflict with the objectives/purposes of the citation system. 72.43.99.130 (talk) 18:55, 29 February 2016 (UTC)
- We follow MOS, which specifies an unspaced en dash for year ranges. If you want WP to be more flexible, start a conversation at the appropriate MOS talk page. Be prepared for a lively discussion. – Jonesey95 (talk) 15:53, 29 February 2016 (UTC)
- It did, I had read a lot of irrelevant "help" text and tried several combinations. I do think that a plain hyphen or dash should work, as should a spaced en-dash; a bot can convert these if need be but frankly I don't see why anyone would care. Among the problems for the en-dash is that the citation tool doesn't provide for it, so one has to enter a hyphen in the tool, press ok and then tweak the text. It's also not a good choice for people entering the cite book code manually, a hyphen would be far more convenient. But we have to keep the wiki-gnomes busy. Chiswick Chap (talk) 14:04, 29 February 2016 (UTC)
-
-
Citing the Introduction written by the editor, not the author
The book has one author and one editor. The editor wrote the Preface/Introduction, how do we cite it? Roger (Dodger67) (talk) 09:22, 1 March 2016 (UTC)
{{cite book |title=Title |contribution=Introduction |contributor=Editor name |author=Author name |publisher=Publisher |location=Location |date=2016}}
- Editor name (2016). Introduction. Title. By Author name. Location: Publisher.
- —Trappist the monk (talk) 10:56, 1 March 2016 (UTC)
-
- Thanks! Roger (Dodger67) (talk) 11:34, 1 March 2016 (UTC)
Getting errors fixed
Hi, while fixing problems with errors generated by the templates I had a thought that now we know when articles are added to a category may be a BOT could be used to message those who have introduced the error. Thus giving them a chance to go and sort out the problem and so reduce the amount of entries that are in the categories. Something similar to BracketBot that reports broken wiki-mark-up or DPL bot that reports on DAB links entered in an edit. Keith D (talk) 19:57, 5 March 2016 (UTC)
- ReferenceBot does this notification already for most of the categories. It might need some updates for categories that have been added recently. – Jonesey95 (talk) 00:01, 6 March 2016 (UTC)
- Thanks the one I was thinking about was Category:CS1 errors: dates. Keith D (talk) 01:20, 6 March 2016 (UTC)
web.archive.org/save/...
I just found this template:
{{cite news |ref={{sfnRef|The Jakarta Post, 2002}} |author=<!--Staff writer(s); no by-line.--> |date=June 5, 2002 |title=Medan loses its historical buildings |url=http://www.thejakartapost.com/news/2002/06/05/medan-loses-its-historical-buildings.html |dead-url= |newspaper=The Jakarta Post |location=Jakarta |archive-url=http://web.archive.org/save/http://www.thejakartapost.com/news/2002/06/05/medan-loses-its-historical-buildings.html |archive-date=May 3, 2016 |access-date=May 3, 2016 }}
The May archive and access dates were causing error messages. When I looked at fixing them, I clicked on the citation's title but landed on a page that didn't look like a standard archived page: the header along the top that I usually see was missing. Assuming that I had misclicked, I backtracked and tried again landing in the same place.
Looking at the |archive-url=
again, I noticed the 'save' in the path. I wonder then, does that cause archive.org to save a copy of the target url? If it does, we should not be making that kind of link active in cs1|2 templates.
I propose then, to create a test for the content of |archive-url=
that looks for |archive-url=http://web.archive.org/save/
(and also https:...) When found, the module will emit an error message and disable the link.
—Trappist the monk (talk) 01:35, 6 March 2016 (UTC)
County based inaccessibility for cite web
Template:Cite web has registration=yes/no or subscription=yes/no to represent when a web page may not be viewable based on needing to sign up for a free or cost service.
Do we have a field to represent when neither of these is needed but a website restricts itself based upon the location of the viewer?
For example I am able to view http://www.chrgd.ca/videos/dreamworkstv-pirates-and-party-crashers/ just fine from here in Canada, but when I tried to archive it using the Wayback Machine (based in the United States) it only archived an error page.
This also happens with US/Canada cognates, when I try to view the US version of Disney Jr or Disney XD it will bounce me to the Canadian ones, which can be frustrating since they actually have different programming. Based on what I've seen from archives, the reverse also happens if US people access the Canadian site, it will bounce them to the American one.
If we do not have a field to represent country-locked URLs then could we create one? It seems like a valuable thing to note when people want to check a URL and cannot do so. These restrictions inconvenience archival (it may be hard to find a Wayback equivalent outside the US for sites not viewable from the US) and also fact-checking from editors not in the country the site exclusively serves. A field like subscription/registration to denote these would help prepare people ahead of time for that and to be able to discuss it more clearly. 184.145.18.50 (talk) 02:31, 6 March 2016 (UTC)