Help talk:Citation Style 1/Archive 8
![]() | This is an archive of past discussions about Help:Citation Style 1. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Archive 5 | Archive 6 | Archive 7 | Archive 8 | Archive 9 | Archive 10 | → | Archive 15 |
Documentation / Lua
We currently have three templates not using the Lua module: {{cite episode}}, {{cite serial}} and {{cite map}} (which is in progress). Currently we have a documentation switch |lua=yes
in {{Citation Style documentation}} to display documentation sections for the Lua templates. I think it is time to remove that and show the Lua documentation on all with notes on the non-Lua templates. -- Gadget850 talk 18:16, 28 February 2015 (UTC)
- Concur.
- Support, especially if we proceed with migration of {{cite episode}} and {{cite serial}}. I will help in any way that I can. It will be exciting to be done with this multi-year migration project. – Jonesey95 (talk) 23:29, 1 March 2015 (UTC)
What is needed to proceed with this change? Do we change to |lua=no
for the non-Lua templates? Do we just put a big note at the top of the documentation for each of them saying that they don't work quite as described? Do we gather the non-Lua content from the subtemplates into a single subtemplate to display on the non-Lua pages?
As an aside, I noticed that {{Cite arXiv}} is listed in some of the official lists of CS1 templates (e.g. at {{Citation Style documentation/cs1}}) but not in others (e.g. Help:CS1 errors and Help:Citation Style 1#General use). It does not yet use Lua. – Jonesey95 (talk) 20:30, 21 March 2015 (UTC)
Done. Now that all of the templates have been converted to Lua, this project was straightforward. I believe that I have stripped all of the "lua=yes" and "if lua" statements from our CS1 documentation. If I missed or broke anything, let me know (or be bold and fix it). – Jonesey95 (talk) 15:38, 19 April 2015 (UTC)
Vancouver style error
The recent module update that included the changes discussed in name-list-format is now generating a enormous number of "Vancouver style errors" which I think are unintended. Roman ≠ ASCII. ASCII is a subset of Roman characters. Roman characters include characters with diacritical marks. I am no expert on character sets, but allowed Roman characters would seem to include Unicode characters in the range of 0000 to 036F (Latin character set) and exclude Unicode 0370 and higher (Greek, Cyrillic, Arabic, etc.). PubMed which uses Vancouver style authors and is the source of the citation data that is used in many Wiki articles, clearly allows for extended Roman characters in author names (see for example, PMID 15196329). Boghog (talk) 13:11, 21 March 2015 (UTC)
- I'm not sure that characters with diacritical marks are included in the Roman characters. I've been watching for the introduction of a new law about vital records in my state, and the last time they tried, they wanted to restrict names on birth certificates to Roman letters, which was interpreted to exclude diacritical marks. Since our so-called Vancouver style is only quasi-Vancouver, I would think we would want to allow diacritical marks, regardless of whether the official Vancouver style guide (if such a thing exists) allows them or not. Jc3s5h (talk) 13:24, 21 March 2015 (UTC)
- The Romanization requirement is in what appears to be the Vancouver style guide.
- OK, I now see that the The NLM Style Guide for Authors, Editors, and Publishers states Ignore diacritics, accents, and special characters in names. (e.g., Å treated as A). However PubMed does not follow this recommendation and NLM/PubMed is the de facto Vancouver System standard (see Vancouver_system#History) and is also the source of much of Wikipedia's citation data. I think we should follow PubMed practice and allow extended Roman characters. The alternative is to replace these characters but this would cause an enormous amount of work with no real benefit to our readers. Boghog (talk) 13:41, 21 March 2015 (UTC)
- I agree with Jc3s5h, we should allow diacritical marks regardless. Boghog (talk) 13:41, 21 March 2015 (UTC)
- If PubMed uses diacritical marks, we should consider hiding this red error message until we come to a consensus on whether to permit or eliminate (and how to eliminate, if we so choose) the marks from existing articles that use the Vancouver style. (I am amending this comment to say that there are currently 16 articles in Category:CS1 errors: Vancouver style, a number that will surely grow, but which I would not classify as "enormous".) – Jonesey95 (talk) 15:05, 21 March 2015 (UTC)
- The module was just updated. Existing articles must be edited for purged before the error message occurs. Also there is a lag between when an error displayed in an article and when it shows up in the CS1 error category. I guarantee you that within a few days, this number will be huge. Boghog (talk) 15:20, 21 March 2015 (UTC)
- The use of extended Latin characters in citation authors in Wikipedia is wide spread and has been so for a very long time. Tools and bots that generate citations that support extended Latin characters include WP:REFTOOLS, User:Diberri/Template filler, and User:Citation bot. Clearly the current consensus is that extended Latin characters are allowed. A new consensus would need to be established to classify extended Latin characters as citation errors, even if these errors are only generated when
|name-list-author=vanc
is invoked. Even PubMed doesn't follow this particular author style recommendation. Why should we? Boghog (talk) 15:54, 21 March 2015 (UTC)
- If PubMed uses diacritical marks, we should consider hiding this red error message until we come to a consensus on whether to permit or eliminate (and how to eliminate, if we so choose) the marks from existing articles that use the Vancouver style. (I am amending this comment to say that there are currently 16 articles in Category:CS1 errors: Vancouver style, a number that will surely grow, but which I would not classify as "enormous".) – Jonesey95 (talk) 15:05, 21 March 2015 (UTC)
- I agree with Jc3s5h, we should allow diacritical marks regardless. Boghog (talk) 13:41, 21 March 2015 (UTC)
- OK, I now see that the The NLM Style Guide for Authors, Editors, and Publishers states Ignore diacritics, accents, and special characters in names. (e.g., Å treated as A). However PubMed does not follow this recommendation and NLM/PubMed is the de facto Vancouver System standard (see Vancouver_system#History) and is also the source of much of Wikipedia's citation data. I think we should follow PubMed practice and allow extended Roman characters. The alternative is to replace these characters but this would cause an enormous amount of work with no real benefit to our readers. Boghog (talk) 13:41, 21 March 2015 (UTC)
- Use of foreign letters in an English context still presents problems of classification and sortng, but it's not like the "old" days when many publications could not even produce diacritical and other foreign letters. But modern typography is more capable, and even on the English Wikipedia there is a trend to a more global orthography. {{Citation}} already accomodates diacrticals, Vancouver style should not be an exception. ~ J. Johnson (JJ) (talk) 20:34, 21 March 2015 (UTC)
- Agreed. The NLM Style Guide states, "Ignore diacritics, accents, and special characters in names ... to simplify rules for English-language publications." However displaying diacritical marks is no longer a technical problem using modern publication methods. Hence this particular NLM guideline is antiquated and is no longer followed even by PubMed. While non-Latin characters must be romanized in Wikipedia (see MOS:ROMANIZATION), Latin diacritical marks are allowed (MOS:DIACRITICS). In addition, by using metadata, someone might want to transfer Vancouver style references to another article that uses the default CS1 style that allows diacritical marks. Stripping out the diacritical marks from the Vancouver style references represents an unnecessary loss of information that will adversely impact the transferability of these citations into different citation formats. Boghog (talk) 14:11, 22 March 2015 (UTC)
- Use of foreign letters in an English context still presents problems of classification and sortng, but it's not like the "old" days when many publications could not even produce diacritical and other foreign letters. But modern typography is more capable, and even on the English Wikipedia there is a trend to a more global orthography. {{Citation}} already accomodates diacrticals, Vancouver style should not be an exception. ~ J. Johnson (JJ) (talk) 20:34, 21 March 2015 (UTC)
- Yes. If there is any real need to dediacriticise (!) perhaps that could be done with a template, thus preserving the fuller form. ~ J. Johnson (JJ) (talk) 20:15, 22 March 2015 (UTC)
- Unicode 0x0000–0x036F consists of seven defined groups:
- 0000–007F C0 Controls and Basic Latin (C0 Controls: 0000–0020)
- 0080–00FF C1 Controls and Latin-1 Supplement (C1 Controls: 0080–00A0 & 00AD)
- 0100–017F Latin Extended-A
- 0180–024F Latin Extended-B
- 0250–02AF IPA Extensions
- 02B0–02FF Spacing Modifier Letters
- 0300–036F Combining Diacritical Marks
- It would seem that if we choose to disregard the NLM Style Guide then the range of characters that we allow should be 0021–007F, 00A1–00AC, 00AE–024F.
- Yes, those ranges make sense. Per MOS:ROMANIZATION, shouldn't this restriction not only apply to
|author-name-list=vanc
but also to the default author format? Although before expanding the scope of the check, I think we would need wider consensus. Just for curiosities sake, implementing this type of check in standard Lua appears non-trivial. Can this be done with something like utf8.find? Boghog (talk) 14:37, 23 March 2015 (UTC)
- Yes, those ranges make sense. Per MOS:ROMANIZATION, shouldn't this restriction not only apply to
- This whole test was added because it was pointed out that the NLM Style Guide (Vancouver) requires Romanization. It would seem, if we are to apply MOS:ROMANIZATION to non-Vancouver-style author/editor names, then MOS:ROMANIZATION should also apply to everything else in a CS1/2 citation. If that is the case then there can be no titles in Cyrillic, Japanese, Hebrew, Thai, etc and there are a lot of those.
-
- Though kind of ugly, this might work:
for codepoint in mw.ustring.gcodepoint( s ) do
if 33 > codepoint -- C0 controls
or 128 >= codepoint and 160 <= codepoint -- most C1 controls
or 173 == codepoint -- odd-man-out C1 control
or 591 < codepoint then -- codepoints beyond Latin Extended-B
-- error message stuff
end
end
- We might simplify and just accept everything below codepoint 592 (0x0250) on the theory that C0 and C1 controls would be an unlikely part of a name.
- Ah, thanks. With the mw.ustring library, it is still somewhat messy, but not as difficult as I first thought. Boghog (talk) 17:07, 23 March 2015 (UTC)
- Some editors are starting to Romanize author names to eliminate these errors and there appears to be a developing consensus that this is unnecessary. Is there any way the current error message can be suppressed until a solution that has consensus has been implemented? The only argument that has been advanced in favor of the error message is the NLM Romanization guideline and there appears consensus above that we should ignore this particular guideline. Furthermore no one has raised any objections to following PubMed practice of using extended Latin characters. Boghog (talk) 17:06, 24 March 2015 (UTC)
- I concur. There is no urgency regarding this "error", and prompting editors to make changes where matters are yet unsettled leads to instability and confusion. ~ J. Johnson (JJ) (talk) 22:47, 24 March 2015 (UTC)
- Some editors are starting to Romanize author names to eliminate these errors and there appears to be a developing consensus that this is unnecessary. Is there any way the current error message can be suppressed until a solution that has consensus has been implemented? The only argument that has been advanced in favor of the error message is the NLM Romanization guideline and there appears consensus above that we should ignore this particular guideline. Furthermore no one has raised any objections to following PubMed practice of using extended Latin characters. Boghog (talk) 17:06, 24 March 2015 (UTC)
@Trappist the monk: Please suppress this error message. In the mean time, I have boldly warned editors to ignore this message. Boghog (talk) 20:21, 26 March 2015 (UTC)
- With your bold warning, is it really necessary to dump a couple of million pages onto the job queue for simply changing
hidden = false
tohidden = true
?- OK, thanks for your reply. I thought there might be a way of suppressing the message that didn't require modifying the template code. I will be patient. Boghog (talk) 19:01, 27 March 2015 (UTC)
- It occurred to me this afternoon while I was doing something completely unrelated that we can still use the lua patterns to solve this problem. The above code snippet is really pretty ugly and in fact would have gotten uglier. This pattern that I concocted in the debug window is, I think, better:
=mw.ustring.find("a Ëb-c ɏÝ'a", "^[A-Za-zÀ-ÖØ-öø-ƿDŽ-ɏ%-%s%']*$")
- The pattern includes, I think, all the letters in the Latin range of 0000–024F, jumping over things like × (00D7) and ÷ (00F7) etc.
- I am ignorant on the specifics of Lua, but I believe that in many programming languages the mappinng/ordering of characters is dependent on a locale setting. Is that a factor here? ~ J. Johnson (JJ) (talk) 04:23, 27 March 2015 (UTC)
- I don't think so.
- I am ignorant on the specifics of Lua, but I believe that in many programming languages the mappinng/ordering of characters is dependent on a locale setting. Is that a factor here? ~ J. Johnson (JJ) (talk) 04:23, 27 March 2015 (UTC)
- I have managed to try the pattern I identified above, not without some struggle. It seems that the code editor gets confused regarding character and cursor position – I could put the cursor at a place, and the next character I typed ended up in some other position. Writing the line here and then copy/pasting it there worked.
Wikitext | {{cite book
|
---|---|
Live | Waśniowska, J. Paul; Gómez-Coronado, Suárez; Kühme, T; DŽǻlĕç, d. Title. {{cite book}} : Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (help)
|
Sandbox | Waśniowska, J. Paul; Gómez-Coronado, Suárez; Kühme, T; DŽǻlĕç, d. Title. {{cite book}} : Unknown parameter |name-list-format= ignored (|name-list-style= suggested) (help)
|
- This appears to work. The first three names are taken from article space, the last one is concocted from various letters in the four Latin code sets.
- —Trappist the monk (talk) 13:46, 27 March 2015 (UTC)
- Your solution looks brilliant! Thanks :-) Boghog (talk) 19:04, 27 March 2015 (UTC)
- —Trappist the monk (talk) 13:46, 27 March 2015 (UTC)
I have discovered and fixed an error in reduce_to_initials()
that produced � for author initials when the first character of the name was not in the set [A-Za-z]:
{{cite news/new|title=title|name-list-format=vanc|last1=González|first1=Ángel}}
- →González, Ángel. "title".
{{cite news}}
: Unknown parameter|name-list-format=
ignored (|name-list-style=
suggested) (help)
—Trappist the monk (talk) 16:22, 4 April 2015 (UTC)
Add a 'volume-b=' parameter that skips the four-chr test for bolding?
I just learned from a discussion above that bolding of |volume=
is conditioned on having four or fewer characters. I don't know why that limit was picked; presumably it serves some useful purpose. But it does lead to some inconsistent results. Would it be possible to have something like |volume-b=
that would be identical to Volume= in all respects except that it skips the the four-chr test, and thus always does bolding? ~ J. Johnson (JJ) (talk) 21:53, 22 March 2015 (UTC)
- Some history. The suggestion to wrap the volume value in wikimarkup (
|volume='''MCMLXXXIV'''
) corrupts the COinS metadata so that shouldn't be considered as a way to get around this 'constraint'.
- For sure a parameter value should never include wikimarkup. But that is irrelevant to what I am asking. The current code already generates bolded output, and apparently without corrupting COinS. What I am asking should make no difference in how such bolding is done, only in when the existing test is applied. ~ J. Johnson (JJ) (talk) 00:15, 24 March 2015 (UTC)
- Trappist the monk: while this is not an urgent matter, I hope that will not entirely overlooked. It should be simple to implement (just a test condition), and its availability should reduce the "need" and tendency of editors to add wikimarkup to force bolding. ~ J. Johnson (JJ) (talk) 21:23, 4 April 2015 (UTC)
- I've changed my position with regard to wikimarkup in
|volume=
. We allow constructs like this in|title=
:{{cite journal | ref=harv | last=Cody | first=William J. | title=''Adiantum pedatum'' ssp. ''calderi'', a new subspecies in northeastern North America | journal=[[Rhodora (journal)|Rhodora]] | volume=85 | issue=841 |date=January 1983 | pages=93–96 | url=http://www.botanicus.org/item/31753003488258}}
- →Cody, William J. (January 1983). "Adiantum pedatum ssp. calderi, a new subspecies in northeastern North America". Rhodora. 85 (841): 93–96.
{{cite journal}}
: Invalid|ref=harv
(help)
- and there is code in the module that strips the apostrophe markup from the title value before it becomes COinS:
&rft.atitle=Adiantum+pedatum+ssp.+calderi%2C+a+new+subspecies+in+northeastern+North+America
- so, why not use that same code to render the value in
|volume=
COinS-safe as well?
- I've changed my position with regard to wikimarkup in
- —Trappist the monk (talk) 23:58, 4 April 2015 (UTC)
- Why don't we just drop the bold completely, regardless of character count? Imzadi 1979 → 01:24, 5 April 2015 (UTC)
- —Trappist the monk (talk) 23:58, 4 April 2015 (UTC)
- Volume numbers, which are especially significant for serials and journals, are often overlooked on account of being so short, wherefore they are commonly bolded so they are more readily seen in long citations.
- There often is a need to specifically apply italicization, perhaps even bolding, within a title, just as there is often a need for special characters and raised or lowered text. But I am against encouraging use of wikimarkup in the templates generally, as it confuses the display and data functions. (It is a really bad practice in respect of database systems.) I could possibly accept 'volume' as another exception, but it rankles me. ~ J. Johnson (JJ) (talk) 21:18, 5 April 2015 (UTC)
- Editors will use wikimarkup. I don't think that we're going to get them to not use wikimarkup except in places where it is obviously detrimental to the function of the citation. Since we must accept wikimarkup in titles, doing so for
|volume=
isn't too difficult because editors will sometimes use|volume=
as an extension of a title:{{cite book|last=Tolkien|first=J. R. R.|title=The Lord of the Rings (50th Anniversary Edition)|year=2004|publisher=Houghton Mifflin Company|volume=''The Return of the King''|pages=747–748}}
- →Tolkien, J. R. R. (2004). The Lord of the Rings (50th Anniversary Edition). Vol. The Return of the King. Houghton Mifflin Company. pp. 747–748.
- Here it isn't bold, it's italics (of course using
|volume=
for the title of a book in a series is problematic because COinS doesn't support volume for books; it does for journals). That makes me think that sometime down the road someone is going to want|volume-i=
.
- Editors will use wikimarkup. I don't think that we're going to get them to not use wikimarkup except in places where it is obviously detrimental to the function of the citation. Since we must accept wikimarkup in titles, doing so for
- Properly written, and COinS compatible, the citation above could be:
{{cite book|last=Tolkien|first=J. R. R.|series=The Lord of the Rings |edition=50th Anniversary |year=2004 |publisher=Houghton Mifflin Company|title=The Return of the King |pages=747–748}}
- →Tolkien, J. R. R. (2004). The Return of the King. The Lord of the Rings (50th Anniversary ed.). Houghton Mifflin Company. pp. 747–748.
- I know that there has been some debate about styling of series' titles. I don't know what the result of that debate was but I could easily imagine that there are clear cases for styles and unstyled. If that's the case then we should also strip wikimarkup from
|series=
.
- Properly written, and COinS compatible, the citation above could be:
- Perhaps not the best example. When "works" (books) are split into volumes those are usually numbered, with one title for the entire work. When a work consists of volumes separately titled, the work is a series. It is confusing that the generic workhorse
|title=
can be used for chapter, article, volume, book, work, and series, all with differing nuances of display. Perhaps it would help to have more specific title parameters. But (as I was just saying) there is a need to apply special formatting in some titles, so we are stuck with having to allow wikimarkup (or html?) in some cases. So much as I deplore this: perhaps it would be simpler (in terms of use) to generally allow some markup across all parameters. However, there will be greater problems trying to maintain consistency if editors can individually customize their references. ~ J. Johnson (JJ) (talk) 20:15, 6 April 2015 (UTC)
- Perhaps not the best example. When "works" (books) are split into volumes those are usually numbered, with one title for the entire work. When a work consists of volumes separately titled, the work is a series. It is confusing that the generic workhorse
- Wikimarkup is simple to deal with and even titles like this aren't so bad:
|title=Tracing H<sub>2</sub> Via Infrared Dust Extinction
- →Alves, J.; Lada, C.; Lada, E. (2001). Tracing H2 Via Infrared Dust Extinction. Cambridge University Press. p. 217. ISBN 0-521-78224-4.
{{cite book}}
: Unknown parameter|booktitle=
ignored (help)
- but then we get titles like this:
|title=A Parallactic Distance of <math>389^{+24}_{-21}</math> Parsecs to the Orion Nebula Cluster from Very Long Baseline Array Observations
- →Sandstrom, Karin M.; Peek, J. E. G.; Bower, Geoffrey C.; Bolatto, Alberto D.; Plambeck, Richard L. (2007). "A Parallactic Distance of Parsecs to the Orion Nebula Cluster from Very Long Baseline Array Observations". The Astrophysical Journal. 667 (2): 1161. arXiv:0706.2361. Bibcode:2007ApJ...667.1161S. doi:10.1086/520922.
- Fortunately there aren't that many instances of this second type:
insource:/\| *title *=[^\|\}]*\<math/
- Still, these lurk in the back of my mind as something that needs to be addressed.
- Wikimarkup is simple to deal with and even titles like this aren't so bad:
- —Trappist the monk (talk) 22:05, 6 April 2015 (UTC)
- Yes, that's the kind of stuff I was thinking about. The variations in how Sandstrom et al. is cited suggests that COinS might be ineffective is such cases, so perhaps it doesn't matter much how this markup gets flattened. ~ J. Johnson (JJ) (talk) 22:40, 6 April 2015 (UTC)
- —Trappist the monk (talk) 22:05, 6 April 2015 (UTC)
Trappist the monk, Imzadi1979: If use of wikimarkup (specifically, apostrophes) in parameters is acceptable (yuck), then there is no need for 'volume-b'. But to make that determination, should we have an RfC? ~ J. Johnson (JJ) (talk) 22:17, 8 April 2015 (UTC)
- For the moment I guess I have no opinion with regard to an RfC.
- Are the three of us sufficient to decide whether the use of apostrophes in
|volume=
should be acceptable? Do we have sufficiently broad scope of view to not miss some important consideration, or should we request comments from others? I lean some what in that direction, so will consider what question should be formulated. ~ J. Johnson (JJ) (talk) 20:34, 10 April 2015 (UTC)
- Are the three of us sufficient to decide whether the use of apostrophes in
- I still have no opinion on the matter. If you want an RfC, do so. I have done nothing with the code that handles
|volume=
and likely won't before I freeze the current changes in advance of the next update.
- I still have no opinion on the matter. If you want an RfC, do so. I have done nothing with the code that handles
- Nah, let's just fake it. So in regard of getting the value of
|volume=
bolded when it has more than four characters: we have a consensus (of sorts) that using apostrophes (wikimarkup) is an acceptable work-around. In view of that, and the backlog of other work, we can close this discussion. ~ 21:06, 11 April 2015 (UTC)
- Nah, let's just fake it. So in regard of getting the value of
How to use "et al"?
Looking over the template dox, I see examples of the use of "et al" in long lists of names. It appears this is automated though, is there some way to do this manually? I have a conference paper with about 40 names in it, I only want the first one to appear, along with et al. Maury Markowitz (talk) 20:32, 1 April 2015 (UTC)
{{cite conference |title=Title |last=Last1 |first=First1 |last2=Last2 |first2=First2 |last3=Last3 |first3=First3 <!-- and as many more author names as you'd like to include --> |display-authors=1}}
- →Last1, First1; et al. Title.
{{cite conference}}
: CS1 maint: numeric names: authors list (link)
- →Last1, First1; et al. Title.
- —Trappist the monk (talk) 20:54, 1 April 2015 (UTC)
- Ah ha! Ok, so if I put in only one author, and say |display-authors=1, do I get the et al? I'd test this myself, but the article is being edited offline in my text editor... Maury Markowitz (talk) 20:59, 1 April 2015 (UTC)
- You could test it here, click show preview, and see. But, since I'm here I'll show you that no, that doesn't work, pretty much as you'd expect.
{{cite conference |title=Title |last=Last1 |first=First1 |display-authors=1}}
- →Last1, First1. Title.
{{cite conference}}
: Invalid|display-authors=1
(help)CS1 maint: numeric names: authors list (link)
- →Last1, First1. Title.
- Bummer. Suggestions on what such a beast would look like? |display=0 seems more confusing than useful. Maury Markowitz (talk) 21:35, 1 April 2015 (UTC)
- You can still add two authors and set display authors to 1. --Izno (talk) 21:51, 1 April 2015 (UTC)
- That's fooling the system, precisely what I would like to avoid. This should be a feature, not a workaround. Maury Markowitz (talk) 02:50, 2 April 2015 (UTC)
- You can still add two authors and set display authors to 1. --Izno (talk) 21:51, 1 April 2015 (UTC)
- Bummer. Suggestions on what such a beast would look like? |display=0 seems more confusing than useful. Maury Markowitz (talk) 21:35, 1 April 2015 (UTC)
- [ec] The "et al." doesn't come up unless have at least one more author than display-authors. E.g., adding last2 and first2 to the above code gives us:
- →Last1, First1; et al. Title.
{{cite conference}}
: CS1 maint: numeric names: authors list (link)
- →Last1, First1; et al. Title.
- [ec] The "et al." doesn't come up unless have at least one more author than display-authors. E.g., adding last2 and first2 to the above code gives us:
- But note that your full citation really should list at least three authors. (Some style conventions (including APA?) will add "and 37 others" instead of "et al.") The "Last, et al." would be in an in-line short cite, such as created by harv. ~ J. Johnson (JJ) (talk) 22:07, 1 April 2015 (UTC)
Sure, but I'm simply not going to type in all 37 to get the "and 37 others" tag. Since the cite will only list one author, and the citeref refers only to that author, I shouldn't have to list all the rest just to get the template to display the way it's going to in the end anyway. Maury Markowitz (talk) 02:48, 2 April 2015 (UTC)
- Maury Markowitz: I just showed you how to get the 'et al.' with just two authors. Look at the wikisource. (Though, as I said, you really should have at least three/four. See below.) ~ J. Johnson (JJ) (talk) 21:00, 2 April 2015 (UTC)
- @Maury Markowitz: you can put the 1st author in
|author1=
, set|display-authors=1
(as suggested above), and copy & paste the remaining authors into|author2=
as long as they're either comma or semicolon delimited. Then I, or someone with a similar script, can enumerate them into the appropriate # of authors. From all my citation cleanup, this seems to be the way it is being (hastily?) done. Whether or not there's a better way is a different story. ~ Tom.Reding (talk ⋅contribs ⋅dgaf) 14:14, 2 April 2015 (UTC)- The original problem that led me here was a PDF document that doesn't allow cut and paste of the text. :-) Maury Markowitz (talk) 14:19, 2 April 2015 (UTC)
- I have that same frustration with paper books and newspapers. I can cut and paste, but then I can't see my whole computer monitor. – Jonesey95 (talk) 14:35, 2 April 2015 (UTC)
- The original problem that led me here was a PDF document that doesn't allow cut and paste of the text. :-) Maury Markowitz (talk) 14:19, 2 April 2015 (UTC)
Because we now detect and categorize citations that include et al. in author and editor parameters, and because of this conversation, it occurs to me that we might create a couple of parameters, perhaps |more-authors=
and |more-editors=
that would append et al. to the author list if the parameter is set to yes
or true
. In this way, Editor Maury Markowitz could list only one of the bazillion authors, need only one author in {{sfn}}
or {{harv}}
templates, not corrupt the COinS metadata, nor fool the system.
Alternatively, perhaps we modify |display-authors=
and |display-editors=
by adding a keyword more
that would append et al. to the appropriate name-list.
It would seem that either of these solutions would also provide a way of positively dealing with the 18,000+ pages in Category:CS1 maint: Explicit use of et al.
—Trappist the monk (talk) 16:21, 2 April 2015 (UTC)
- I strongly agree that we should have a non-hacky way for WP editors to ask the citation to show "et al." without breaking the harv referencing or the metadata.
- It would be nice to come up with a way to implement this that allowed us to sweep through those 18,000 articles and convert them elegantly to the new way. – Jonesey95 (talk) 16:52, 2 April 2015 (UTC)
- Sort of like this:
|display-authors=
→ Last1, First1. Title.{{cite book}}
: CS1 maint: numeric names: authors list (link)|display-authors=1
→ Last1, First1. Title.{{cite book}}
: Invalid|display-authors=1
(help)CS1 maint: numeric names: authors list (link)|display-authors=more
→ Last1, First1. Title.{{cite book}}
: Invalid|display-authors=more
(help)CS1 maint: numeric names: authors list (link)
- I have not implemented this for the editor name-list. Shall I proceed or revert?
- —Trappist the monk (talk) 16:58, 2 April 2015 (UTC)
- I agree with both
|display-authors=more
and|more-authors=
, and prefer the|display-authors=more
solution since it uses an existing parameter in a non-conflicting way, is intuitive to use, and it's easy to remember. ~ Tom.Reding (talk ⋅contribs ⋅dgaf) 19:28, 2 April 2015 (UTC)- I agree with
|display-authors=more
for the reasons given by Tom.Reding. It would probably be useful to have a bit of error checking for|display-authors=
to locate values that are not numbers or "more". I don't know what is done with|display-authors=blahblahblah
now, but it should throw an error. - Testing
|display-authors=blahblahblah
: Smith, John. Title.{{cite book}}
: Invalid|display-authors=blahblahblah
(help) - Nice work, Trappist. – Jonesey95 (talk) 02:02, 3 April 2015 (UTC)
- I agree with
- I agree with both
- Using a keyword of "etal" or similar might be more (heh) intuitive in the parameter than the word "more". I read "display-authors = more" in the sense of "display more of them!"... which obviously isn't the intent. --Izno (talk) 03:21, 3 April 2015 (UTC)
- Currently supports keywords
more
andetal
regardless of case. We should choose one.|display-editors=
does not yet have this functionality.|display-authors=more
→ Last1, First1. Title.{{cite book}}
: Invalid|display-authors=more
(help)CS1 maint: numeric names: authors list (link)|display-authors=etal
→ Last1, First1; et al. Title.{{cite book}}
: CS1 maint: numeric names: authors list (link)|display-authors=1
→ Last1, First; et al. Title.{{cite book}}
: CS1 maint: numeric names: authors list (link)|display-authors=
→ Last1, First; Last2, First2; et al. Title.{{cite book}}
: Explicit use of et al. in:|first2=
(help)CS1 maint: numeric names: authors list (link)|display-authors=blahblahblah
→ Last1, First1. Title.{{cite book}}
: Invalid|display-authors=blahblahblah
(help)CS1 maint: numeric names: authors list (link)
- —Trappist the monk (talk) 11:09, 3 April 2015 (UTC)
- Currently supports keywords
- I've made a separate function so that both
|display-authors=
and|display-editors=
use the same code. So, the keywords are now supported by|display-editors=
:|display-editors=more
→ Last1, First1 (ed.). Title.{{cite book}}
: Invalid|display-editors=more
(help)CS1 maint: numeric names: editors list (link)|display-editors=etal
→ Last1, First1; et al. (eds.). Title.{{cite book}}
: CS1 maint: numeric names: editors list (link)|display-editors=1
→ Last1, First1; et al. (eds.). Title.{{cite book}}
: CS1 maint: numeric names: editors list (link)|display-editors=
→ Last1, First1; Last2, First2; Last3, First3; Last4, First4 (eds.). Title.{{cite book}}
: CS1 maint: numeric names: editors list (link)|display-editors=
→ Last1, First1; et al. (eds.). Title.{{cite book}}
: Explicit use of et al. in:|editor-first=
(help)CS1 maint: numeric names: editors list (link)|display-editors=
→ Last1, First1; Last2, First2; et al. (eds.). Title.{{cite book}}
: Explicit use of et al. in:|editor-first2=
(help)CS1 maint: numeric names: editors list (link)|display-editors=blahblahblah
→ Last1, First1 (ed.). Title.{{cite book}}
: Invalid|display-editors=blahblahblah
(help)CS1 maint: numeric names: editors list (link)
- We need to remember to revisit this code when Category:Pages using citations with old-style implicit et al. in editors has been cleared.
- I've made a separate function so that both
- The code now uses the plural editor annotation whenever et al. is part of the rendered list.
This neatly solves the other issue I've had with the sfn's, which is the need to use CITEREF if there's a lot of authors to make the ref something typeable. I really like this mod. One suggestion though, perhaps the item after the = could be one of a number of different indicators? etal is the one I would use, but as you pointed out, others prefer a number. Maury Markowitz (talk) 12:50, 3 April 2015 (UTC)
- I don't understand what you mean by
one of a number of different indicators
. In the sandbox code the value assigned to|display-authors=
can be a number, which truncates the author name list and appends et al. or it can be a keyword that simply adds et al. to the end of the name list without truncation.
We have two options on the table for a keyword to add 'et al.' to an author/editor list. I'm inclined to agree with Editor Izno that |display-authors=etal
should be preferred over |display-authors=more
. While more
is really simple in that it has only one spelling, it turns out that it isn't much more work to allow for a variety of etal
spellings. Here are some variations on the etal
theme:
|display-authors=etal
→ Last1, First1; et al. Title.{{cite book}}
: CS1 maint: numeric names: authors list (link)|display-authors=et al
→ Last1, First1; et al. Title.{{cite book}}
: CS1 maint: numeric names: authors list (link)|display-authors=etal.
→ Last1, First1; et al. Title.{{cite book}}
: CS1 maint: numeric names: authors list (link)|display-authors=et al.
→ Last1, First1; et al. Title.{{cite book}}
: CS1 maint: numeric names: authors list (link)|display-authors=''etal''
→ Last1, First1; et al. Title.{{cite book}}
: CS1 maint: numeric names: authors list (link)|display-authors=''et al''
→ Last1, First1; et al. Title.{{cite book}}
: CS1 maint: numeric names: authors list (link)|display-authors=''etal.''
→ Last1, First1; et al. Title.{{cite book}}
: CS1 maint: numeric names: authors list (link)|display-authors=''et al.''
→ Last1, First1; et al. Title.{{cite book}}
: CS1 maint: numeric names: authors list (link)
So, more
or etal
?
—Trappist the monk (talk) 17:16, 4 April 2015 (UTC)
- I think
etal
is clearer, and I love the idea of allowing multiple forms of it in the parameter value. Editors will reasonably expect to be able to typeet al
oret al.
, especially since the latter is the recommended form in MOS. – Jonesey95 (talk) 23:04, 4 April 2015 (UTC)- I think that using
|display-authors=etal
(and silently allowing the variations) is the easiest solution. Imzadi 1979 → 01:28, 5 April 2015 (UTC)- Ok,
|display-authors=more
no more.
- Ok,
- I think that using
Adding retweet parameter to cite tweet and twitter status
Is there a way the templates for cite tweet and twitter status can be modified to note that the status was retweeted by a reliable source.
For instance:
{{Twitter status | user = DisneyChannelPR <!-- https://twitter.com/DisneyChannelPR/status/558343980690059264 --> | statusid = 558343980690059264 | title = Confirms Jimmy Weldon as voice of the Whoopty-Doopty-Schmoodily-Duck | name = Disney Channel PR | date = January 22, 2015 | accessdate = April 3, 2015 }} Retweeted by Shea Fontana.
would become:
{{Twitter status | user = DisneyChannelPR <!-- https://twitter.com/DisneyChannelPR/status/558343980690059264 --> | statusid = 558343980690059264 | title = Confirms Jimmy Weldon as voice of the Whoopty-Doopty-Schmoodily-Duck | name = Disney Channel PR | date = January 22, 2015 | accessdate = April 3, 2015 | retweet = Shea Fontana }}
This would apply for the cases where the original tweeter's handle is not anyone particularly notable, but the reliable source person takes it and retweets it rather than tweeting a reply to it. -AngusWOOF (talk) 23:55, 2 April 2015 (UTC)
{{Twitter status}}
is not a Citation Style 1 template. I suspect that the best place to discuss this is at the template's talk page.
- No prob. I added the request to twitter status's talk page. Cite tweet's talk page redirected here so it'd be nice to know if someone can work on that template. -AngusWOOF (talk) 14:06, 3 April 2015 (UTC)
- In {{cite tweet}}'s sandbox I've passed a new
|retweet=
parameter through to the|others=
parameter in cite web, preceded by "Retweeted by":- Example code:
{{Cite tweet/sandbox |user=Pigsonthewing |number=564068436633214977 |date = 7 February 2015 |quote=This is an example tweet. |retweet=Someone else }}
- Example output: @Pigsonthewing (7 February 2015). (Tweet). Retweeted by Someone else https://x.com/Pigsonthewing/status/564068436633214977 – via Twitter.
This is an example tweet.
{{cite web}}
: Missing or empty|title=
(help)
- Example code:
- Is this the sort of thing you're after, AngusWOOF? - Evad37 [talk] 03:49, 4 April 2015 (UTC)
- Yep, that would work! -AngusWOOF (talk) 04:21, 4 April 2015 (UTC)
- The biggest criticism I have of {{cite tweet}} is that it links through the tweet number and relegates the content of the tweet to the optional quote parameter. Most citation guides say to include the full content of a tweet as the title of the tweet and not to display the tweet's number. At least one guide also advises using the real name of the author in addition to the Twitter account name, which should be preceded by the @. Imzadi 1979 → 07:01, 4 April 2015 (UTC)
- If there's a way to make Twitter status compatible with CS1 I'd be all for that. Twitter status (as shown in my above example) allows for the title to summarize the tweet rather than force the exact quote which would introduce hashtags, links, and replies to non-notable users. -AngusWOOF (talk) 14:14, 4 April 2015 (UTC)
- The biggest criticism I have of {{cite tweet}} is that it links through the tweet number and relegates the content of the tweet to the optional quote parameter. Most citation guides say to include the full content of a tweet as the title of the tweet and not to display the tweet's number. At least one guide also advises using the real name of the author in addition to the Twitter account name, which should be preceded by the @. Imzadi 1979 → 07:01, 4 April 2015 (UTC)
- Yep, that would work! -AngusWOOF (talk) 04:21, 4 April 2015 (UTC)
- In {{cite tweet}}'s sandbox I've passed a new
I've adjusted the sandbox version again, see the new testcases page. In addition to |retweet=
as mentioned above, changes include:
- The default author value is @{{{user}}}. Setting
|author=
overrides this, so it can be set to the real name, or the real name together with the account name if desired |author-link=
added, so the author can be linked to their Wikipedia page|title=
added, for specifying a title for the tweet. Defaults to 'Tweet Number ...' if not specified.- Access date now only set by
|access-date=
or|accessdate=
, not by|date=
|link=
added, so that Twitter is unlinked when|link=no
is set (as per {{Google maps}}) – when used multiple times in an article, only the first instance needs to be linked- Error messages adjusted to say which parameters are missing, and moved to the end. Tracking category is only added in mainspace.
Any other comments or suggestions? - Evad37 [talk] 04:43, 6 April 2015 (UTC)
- Just a minor comment: the title shouldn't be in quotes, otherwise it implies it is what is being tweeted. Also, does this mean the title and quote are both usable? -AngusWOOF (talk) 06:20, 6 April 2015 (UTC)
- We need not reinvent the wheel here folks. CS1 was heavily based on APA style, and the APA Style Blog has already created guidelines on how to cite social media that we can easily adapt to handle citing tweets. Looking at them, I would suggest:
- When the real name is known, it should be listed first with the user handle in square brackets: "Mabbett, Andy [Pigsonthewing]". (The APA says to drop the "@", but we could leave that in place.)
- When the real name of the author is not known, only the user handle would appear without any bracketing: "Pigsonthewing".
- The full tweet should be used as the title, which should appear in quotes as the title of the source.
- Tweet numbers are meaningless, and any citation that lacks a full title should flag an error for correction. Citing just the ISBN for a book without the book title is just as meaningless to a reader. Yes, we could click the links to determine the title of the book, but it's just not a proper citation.
- To solve the issue of multiple instances of "Twitter" being linked, I'd just drop the publisher completely and default to
|type=Tweet
. It may be a semantical distinction, but Twitter doesn't actually cause any tweets to be published; the user tweeting does. They merely host the content, just as Google Books hosts copies of scanned books, and we'd never say Google actually published the books. (It's possible that Google published content that they host on Google Books, but it's also possible that Twitter itself tweets.) - The quote parameter is superfluous as the full tweet should be given.
- For additional ideas, we can consult guidelines from the MLA and the suggestion from the Chicago Manual of Style, although CMOS quotes the full tweet in the prose and omits it from the footnote, relying on a reader's ability to locate it from the Twitter feed. Imzadi 1979 → 07:12, 6 April 2015 (UTC)
- These changes implement your suggestions. Another point for discussion: At the moment, if
|user=
or|number=
is ommitted, a junk url such as https://twitter.com/{{{user}}}/status/{{{number}}} is passed through to {{cite web}}, and error messages regarding|user=
and|number=
are displayed. Another option would be to check the parameters, so that no url rather than a junk url is passed through – but not having a url results in the "Missing or empty |url=" error message, which is a bit deceptive as cite tweet doesn't have a |url= parameter. Any ideas on which is preferable, or if there is another option? - Evad37 [talk] 08:18, 6 April 2015 (UTC)- Actually, I've just noticed that the missing url error message is hidden by default, so now the code checks that the parameters have been set - Evad37 [talk] 09:55, 6 April 2015 (UTC)
- Probably best that you don't rely on the missing url error remaining forever hidden. You might change the
{{cite tweet}}
code to something like this:|url={{#ifeq: {{{number|}}}{{{user|}}} | {{{number}}}{{{user}}} | https://twitter.com/{{{user}}}/status/{{{number}}} | https://twitter.com/ }}
- —Trappist the monk (talk) 10:46, 6 April 2015 (UTC)
- Done - Evad37 [talk] 14:57, 6 April 2015 (UTC)
- Probably best that you don't rely on the missing url error remaining forever hidden. You might change the
- Actually, I've just noticed that the missing url error message is hidden by default, so now the code checks that the parameters have been set - Evad37 [talk] 09:55, 6 April 2015 (UTC)
- These changes implement your suggestions. Another point for discussion: At the moment, if
- One other idea, but MLA uses a time in addition to the date, and it advises that the time zone should be that of the author of the paper, not the author of the tweet. Since Wikipedia is an international publication, if we did have a way to insert the time, I would suggest that we mandated UTC. (We don't use times in any other form of citations though, and I think the Lua module would see any attempt to add a time to a date as an error.) Imzadi 1979 → 07:17, 6 April 2015 (UTC)
- Regarding whether titles and quotes be the same, I disagree. While the quote can contain the full tweet (without the hashtags as appropriate) the title should be without the quotes as it may be needed to explain the context, such as when a user says "Happy Birthday", and the tweeter replies "Thanks!" -AngusWOOF (talk) 16:59, 6 April 2015 (UTC)
- @AngusWOOF: since the title of a tweet is the full tweet, hashtags and all, any quotation in the middle of that is superfluous to the full tweet, period.
- In your proffered example, the context would require the citation of two separate tweets. You'd end up with something like
<ref>{{cite tweet <details on first tweet...>}}<br/>{{cite tweet <details on reply tweet..>}}</ref>
. To attempt to quote the reply while only citing the original one fails to attribute both authors, even if the link to the original tweet displays the reply. If the reply comes days after original, you'd have issues related to which date to use. By using separate citations, even if combined into the same footnote, you'd properly attribute each other and note the proper date(s) for what are separate tweets. Imzadi 1979 → 18:53, 6 April 2015 (UTC)- Yes, that would be needed if the tweets are not threaded, but in the case where it is threaded only the second tweet is necessary, as in this example: [1] But a double tweet in the ref would be fine. -AngusWOOF (talk) 18:59, 6 April 2015 (UTC)
- There's still the same issue of attribution. Even in that case, you need the work of two separate authors to set up the context, and the template only supports one author because, by design, tweets only have a single author/account. I still think that even with the threading, you'd want to separately cite [2] followed by the reply to keep attribution and dates correct. There's a 6-hour gap between the original and the reply, putting them on separate days according to how Twitter displays them for me. Maybe in other time zones they'd appear to have the same date. Adding date support would require additional modifications to the Lua module that handles CS1 templates though. Imzadi 1979 → 19:45, 6 April 2015 (UTC)
- If the quote and the title are to be the same, then it would be fine to exclude hashtags and @'s (and http:// links, similarly use ellipses) where it doesn't add to the content of the article. Would that make it CS1 compatible? As for the date, it should be mainly dependent on where the RS person in question is situated. This would work if the OP asks their question the day before (or after if they are in the Far East and the RS is in the United States) and is also consistent with news article time stamps coming from whoever posted the article. -AngusWOOF (talk) 01:59, 7 April 2015 (UTC)
- Why would you drop the hashtags, at signs or the links? They're part of the content of the tweet, period. There's no compatibility issues to be worried about with the links, as Twitter drops the "http://" part of a URL in the displayed text. We wouldn't have any issue with the template/MediaWiki software recognizing a link in the middle of the title:
- Gates, Bill [BillGates] (February 26, 2013). "#Polio is 99% eradicated. Join me & @FCBarcelona as we work to finish the job and #EndPolio. VIDEO: b-gat.es/X75Lvy" (Tweet). Retrieved April 6, 2015.
- using that example from the APA Style Blog, and putting it in {{cite web}}, there isn't a need to drop any of the content. If we're going to do this, we should do it properly and reproduce the full tweet.
- As of right now, we can't include publication times in CS1 citations. The Lua module checks the formatting and validity of the dates supplied, and there is no standardized way to handle a time of publication. Adding a time stamp to a citation, at the present, creates an error. For most sources, anything more precise than a day is not needed; for other sources like books, anything more specific than the year of publication is overkill.
- Twitter, like other social media, is different from news articles. The date and time stamp on an article published on cnn.com won't vary based on the time zone of the reader. CNN's time stamps are fixed based on their location in Atlanta, Georgia, United States. However, Twitter reports the date and time stamp on a tweet based on the time zone of the reader. Where I am located at the moment is UTC-5, so a freshly posted tweet would carry a date of April 6, 2015, and a time of 9:48 p.m. If I were located in London, that same tweet would appear with April 7, 2015 at 3:48 a.m. We can't assume or guess the original local time for the person writing a tweet, unless it's geotagged. Printed publications get around this because they'll default to the time zone of the author citing the tweet, which will be fixed because it is in print. If we ever added the capacity to include the time of a tweet, to minimize issues we should then specify that the time be given in UTC. Imzadi 1979 → 02:48, 7 April 2015 (UTC)
- Well that a tweet has that character limit means quoting the entire thing shouldn't be an issue then. -AngusWOOF (talk) 04:25, 7 April 2015 (UTC)
- Why would you drop the hashtags, at signs or the links? They're part of the content of the tweet, period. There's no compatibility issues to be worried about with the links, as Twitter drops the "http://" part of a URL in the displayed text. We wouldn't have any issue with the template/MediaWiki software recognizing a link in the middle of the title:
- If the quote and the title are to be the same, then it would be fine to exclude hashtags and @'s (and http:// links, similarly use ellipses) where it doesn't add to the content of the article. Would that make it CS1 compatible? As for the date, it should be mainly dependent on where the RS person in question is situated. This would work if the OP asks their question the day before (or after if they are in the Far East and the RS is in the United States) and is also consistent with news article time stamps coming from whoever posted the article. -AngusWOOF (talk) 01:59, 7 April 2015 (UTC)
- There's still the same issue of attribution. Even in that case, you need the work of two separate authors to set up the context, and the template only supports one author because, by design, tweets only have a single author/account. I still think that even with the threading, you'd want to separately cite [2] followed by the reply to keep attribution and dates correct. There's a 6-hour gap between the original and the reply, putting them on separate days according to how Twitter displays them for me. Maybe in other time zones they'd appear to have the same date. Adding date support would require additional modifications to the Lua module that handles CS1 templates though. Imzadi 1979 → 19:45, 6 April 2015 (UTC)
- Yes, that would be needed if the tweets are not threaded, but in the case where it is threaded only the second tweet is necessary, as in this example: [1] But a double tweet in the ref would be fine. -AngusWOOF (talk) 18:59, 6 April 2015 (UTC)
- Regarding whether titles and quotes be the same, I disagree. While the quote can contain the full tweet (without the hashtags as appropriate) the title should be without the quotes as it may be needed to explain the context, such as when a user says "Happy Birthday", and the tweeter replies "Thanks!" -AngusWOOF (talk) 16:59, 6 April 2015 (UTC)
- We need not reinvent the wheel here folks. CS1 was heavily based on APA style, and the APA Style Blog has already created guidelines on how to cite social media that we can easily adapt to handle citing tweets. Looking at them, I would suggest:
I have updated the template, and fixed the resulting errors in the error tracking category - Evad37 [talk] 04:43, 10 April 2015 (UTC)
Time variable for Template:Cite tweet
Could we design a time= variable for this template? Tweets always include time-of-day tags and this could help put things in order if multiple tweets from the same day are cited within an article. Ranze (talk) 13:08, 4 April 2015 (UTC)
Cs1 template categories
In Category:Citation Style 1 templates there are a handful of templates that aren't part of the core suite. These are:
- meta-templates
{{Cita news}}
– uses{{cite news}}
{{Citar web}}
– uses{{cite web}}
{{Cite Merck Index}}
– uses{{cite web}}
{{Cite tweet}}
– uses{{cite web}}
{{Cite video game}}
– uses{{cite journal}}
{{Cytuj stronę}}
– uses{{cite web}}
{{Vcite2 journal}}
– uses{{cite journal}}
- Except for
{{Cite Merck Index}}
, these meta-templates aren't specific-source templates so don't belong in Category:Citation Style 1 specific-source templates. It would seem that for all of these but{{Cite Merck Index}}
, we should create a new category Category:Citation Style 1 meta-templates. - identifier-based citations
{{Cite doi}}
– transcludes bot-created{{cite journal}}
templates{{Cite hdl}}
– transcludes other prefilled templates that may or may not be CS1 templates{{Cite isbn}}
– transcludes other prefilled templates that may or may not be CS1 templates{{Cite jstor}}
– transcludes bot-created{{cite journal}}
templates{{Cite pmid}}
– transcludes bot-created{{cite journal}}
templates
- These are all deprecated. I think that they should be placed in their own category outside of Category:Citation Style 1 templates; perhaps Category:Identifier-based citations as a member of Category:Citation templates.
- other
- Because
{{cite pmid}}
, shouldn't this template also be deprecated? Because it is unconditionally linked to{{cite pmid}}
, this template probably belongs in the identifier-based citations category.
Opinions?
—Trappist the monk (talk) 14:35, 4 April 2015 (UTC)
- Another option, which could be in addition to or instead of any of the options above, is to establish a "CS1 core templates" category that would include cite web, cite journal, and the other templates we list in the "official" CS1 table of templates. – Jonesey95 (talk) 14:45, 4 April 2015 (UTC)
- Perhaps another, vaguely related issue is that meta-templates should not redirect their talk pages here because they are not CS1 templates. Yeah, I'm thinking about this because of the
{{cite tweet}}
conversations currently underway.
Category changes done. Instead of Category:Identifier-based citations I used Category:Identifier-based citation templates.
—Trappist the monk (talk) 13:41, 7 April 2015 (UTC)
Today I noticed that all, most, a lot, of the CS1 error categories are also listed in Category:Articles with incorrect citation syntax. Is there any real reason for them to be listed there? The documentation on the category page doesn't apply to Module:Citation/CS1-based errors but to templates that use {{citation error}}
. Because the category page has a 'see also' link to Category:CS1 errors, I see no reason for the CS1 error pages to be listed in both places.
—Trappist the monk (talk) 17:28, 12 April 2015 (UTC)
separator suppression
At Module_talk:Citation/CS1/Feature_requests#Separator suppression is this example:
{{cite AV media |title=[[Whaam!]] |last=Lichtenstein |first=Roy}}
which renders as:
- Lichtenstein, Roy. Whaam!. – a period follows the exclamation point
Without all of the wrapping spans the raw output looks like this:
Lichtenstein, Roy. ''[[Whaam!]]''.
It occurs to me that terminal punctuation inside a wikilink or external link followed by another terminator (a period for CS1 or a comma for CS2) can be detected and the punctuation added by the Module can be easily removed. So I've hacked an experiment to test that notion:
{{cite AV media/new |title=[[Whaam!]] |last=Lichtenstein |first=Roy}}
which renders as:
- Lichtenstein, Roy. Whaam!. – no period
- Lichtenstein, Roy, Whaam!, Publisher –
|mode=cs2
;|publisher=
so the module places a comma before removing it; compare live version of same:- Lichtenstein, Roy, Whaam!, Publisher – has comma
- Lichtenstein, Roy. Whaam!. – no period, no wikilink
- Lichtenstein, Roy. Whaam!. – no period, using
|title-link=Whaam!
Change to {{cite book}}
and add |chapter=Baam?
:
- Lichtenstein, Roy. "Baam?". Whaam!. – no periods
Because the module renders external links slightly differently from Wikilinks:
[//example.com ''Whaam!''].
a different test is required. I don't know of any reason why we couldn't render them both in the same way (with italic markup outside the brackets):
Is there a reason for them to be different?
So, for the time being, the hack in the sandbox does not fix duplicate punctuation for the external link variety of this issue. I recently addressed a similar issue related to editor names. That happened in one place in the code. There is another place that has a long if-then-else test (safe_join()
) that handles it for other portions of the rendered citation.
After the next update, I propose to disable those portions of the code, make the module render Wikilinks and external links with markup outside the brackets, and see if this simpler method of removing duplicate punctuation carries any water.
—Trappist the monk (talk) 19:27, 4 April 2015 (UTC)
And another variation: |trans-title=
:
''Whaam!'' [''Wham!''].
|trans-title=
with |title-link=
:
''[[Whaam!|Whaam!]]'' [''Wham!''].
|trans-title=
with |url=
:
[//example.com ''Whaam!'' [''Wham!'']].
And this same for |chapter=
and |trans-chapter=
:
"Baam?" [Bam?].
when |chapter=
is wikilinked:
"[[Baam?]]" [Bam?].
|chapter-url=
[//example.com "Baam?" [Bam?]].
argh.
—Trappist the monk (talk) 13:13, 5 April 2015 (UTC)
Add code tweaks to test external link detection and add |chapter=Baam?
:
And test these conditions:
!''].
– unlinked trans-title- Lichtenstein, Roy. Whaam! [Wham!].
?].
– unlinked trans-chapter- Lichtenstein, Roy. "Baam?" [Bam?]. Whaam!.
and these:
!'']].
– ext linked trans-title- Lichtenstein, Roy. Whaam! [Wham!].
?]].
– ext linked trans-chapter- Lichtenstein, Roy. "Baam?" [Bam?]. Whaam!.
and these, probably unusual conditions:
!]]''].
– wikilinked trans-title- Lichtenstein, Roy. Whaam! [Wham!].
?]]].
– wikilinked trans-chapter- Lichtenstein, Roy. "Baam?" [Bam?]. Whaam!.
I have placed all of this in a function experiment_strip_dup_punct ()
that does these tests. Before the next update to the live module, I will leave the code enabled but not use the 'fixed' rendering. The code will still categorize citations like this so that I can see how the code is working.
—Trappist the monk (talk) 16:42, 5 April 2015 (UTC)
I've discovered a couple of problems with this idea. The first is that Bibcodes often look like this: 2004PhST..112...20I which the code dutifully turns into: 2004PhST.112..20I and the second occurs when the template mode is CS2, uses |editor-firstn=
where the assigned value is an initial followed by a period. I think that I'm going to discontinue this experiment.
—Trappist the monk (talk) 13:49, 10 April 2015 (UTC)
|authors= not an alias of |last=
|authors=
is not an complete alias of |last=
and hasn't been for a long time.
Wikitext | {{cite book
|
---|---|
Live | Last2. Title. {{cite book}} : Missing |author1= (help); Unknown parameter |authors= ignored (help); Unknown parameter |sandbox= ignored (help)CS1 maint: numeric names: authors list (link)
|
Sandbox | Last2. Title. {{cite book}} : Missing |author1= (help); Unknown parameter |authors= ignored (help); Unknown parameter |sandbox= ignored (help)CS1 maint: numeric names: authors list (link)
|
In Module:Citation/CS1/Configuration, where aliases are defined, is this line:
['Authors'] = {'authors', 'people', 'host', 'credits'}
which defines the parameters that alias to the meta-parameter |Authors=
. Further along in that same module is:
['AuthorList-Last'] = {"author#-last", "author-last#", "last#", "surname#", "Author#", "author#", "authors#", "subject#"}
In that code |last#=
is an alias of |authors#=
. Here, the '#' represents 0 or more digits. This list is used by the module to determine if there are redundant parameters used for author names:
But, when it comes time to assemble the author name-list, a test is made to see if the meta-parameter |Authors=
is set. If it is, the module assumes that |Authors=
contains the complete list of names and does not execute the code that assembles the author name-list from the parameters that alias to |AuthorList-Last=
. This makes some sense because with a complete list of authors in |authors=
there is no need to go through the motions of examining |display-authors=
, |last-author-amp=
, |name-list-format=
, etc.
I guess the question is: What to do about this? In the documentation, we clearly state that |authors=
is an alias of |last=
. Semantically, I think that they ought not be aliases and that |authors#=
should be stricken from |AuthorList-Last=
and from the documentation. There have been discussions elsewhere regarding the use of |authors=
which topic is not part of this discussion. Just to enforce that last statement, the question at hand is:
- Shall
|last=
and|authors=
be aliases of each other?
—Trappist the monk (talk) 19:05, 5 April 2015 (UTC)
- The redundant parameter category is essentially empty (new pages pop in there at a rate of a few per day), so we know that there are essentially no instances of
|last=
and|authors=
in the same citation. That said, I would not be surprised if|lastn=
and|authors=
exist together in many citations, and it looks like the|lastn=
parameters are ignored in that case. That is not desirable.
- What do you propose to do about this situation? Would you list the contents of
|lastn=
/|firstn=
along with|authors=
? Mark the presence of|lastn=
and|authors=
as an error condition? Or something else? If the second option is chosen, that could be a problem, since our documentation has said that|last=
and|authors=
are aliases for a while. – Jonesey95 (talk) 20:37, 5 April 2015 (UTC)
- To gauge opinion and to figure out what to do was the purpose of my post. But, since you've asked, if it is left to me, I propose to:
- strike
|authors#=
from|AuthorList-Last=
- create a new temporary meta-parameter, perhaps
|LastFirstAuthors=
- allow the module to create a list of author names from
|lastn=
,|firstn=
,|authorn=
,|author-maskn=
,|author-linkn=
- if both
|Authors=
and|LastFirstAuthors=
are set, choose one (probably|LastFirstAuthors=
) and emit some sort of redundant parameter error message - strike
|authors=
from the|last=
documentation - create new
|authors=
documentation noting the difference between it and|authorn=
- strike
- —Trappist the monk (talk) 23:30, 5 April 2015 (UTC)
- To gauge opinion and to figure out what to do was the purpose of my post. But, since you've asked, if it is left to me, I propose to:
- I agree with all of the above except step 4, which may require a bit more thought. Right now, if
|authors=
and|last2=
are present, only the value of|authors=
is displayed. Following the procedure (marked "probably") in step 4 would silently change that to prefer|last2=
, and presumably emit a "missing author" error. If the "missing author" error category were already empty, it would be a simple matter of finding these new instances and fixing them to display all of the intended authors, but it currently contains 9,700 articles. The newly changed articles would get lost in the shuffle.
- I agree with all of the above except step 4, which may require a bit more thought. Right now, if
- In short, I would change step 4 to read "(probably
|Authors=
)". I think. – Jonesey95 (talk) 00:24, 6 April 2015 (UTC)
- In short, I would change step 4 to read "(probably
- True, but step 4 also says that it will
emit some sort of redundant parameter error message
which will place the page in Category:Pages with citations having redundant parameters which is not so large.
- True, but step 4 also says that it will
I have implemented items 1–4 from the list above:
{{cite book/new |authors=Authors |last2=Last2 |title=Title}}
- →Last2. Title.
{{cite book}}
: Missing|author1=
(help); Unknown parameter|authors=
ignored (help)CS1 maint: numeric names: authors list (link) {{cite book/new |author=Author |last2=Last2 |title=Title}}
- →Author; Last2. Title.
{{cite book}}
:|author=
has generic name (help)CS1 maint: numeric names: authors list (link) {{cite book/new |author1=Author1 |last2=Last2 |title=Title}}
- →Author1; Last2. Title.
{{cite book}}
:|author1=
has generic name (help)CS1 maint: numeric names: authors list (link) {{cite book/new |authors=Authors |last1=Last1 |title=Title}}
- →Last1. Title.
{{cite book}}
: Unknown parameter|authors=
ignored (help)CS1 maint: numeric names: authors list (link)
—Trappist the monk (talk) 15:10, 7 April 2015 (UTC)
|display-author=etal bug
I've discovered a bug. When a citation has |authors=
and |display-author=etal
the author list is simply et al. This happens because the module inappropriately adds 'et al.' to the empty |last_first_list=
meta parameter. I've fixed it in the sandbox.
Wikitext | {{cite book
|
---|---|
Live | Title. {{cite book}} : Unknown parameter |authors= ignored (help)
|
Sandbox | Title. {{cite book}} : Unknown parameter |authors= ignored (help)
|
The issue doesn't arise with |display-editors=
in the live version because the code to distinguish |editors=
from |editor=
is not present. But, if it were, it would be fixed in the sandbax as well
Wikitext | {{cite book
|
---|---|
Live | Title. {{cite book}} : Unknown parameter |editors= ignored (|editor= suggested) (help)
|
Sandbox | Title. {{cite book}} : Unknown parameter |editors= ignored (|editor= suggested) (help)
|
I've also tweaked the code so that |editors=
is always treated as multiple names so the content of |editors=
in the rendered citation is annotated with (eds.) (where appropriate).
—Trappist the monk (talk) 16:19, 23 April 2015 (UTC)
|editors= not an alias of |editor-last=
I should have made the change described in the above section for |editors=
(plural) because it also is not a complete alias of of |editor-last=
. I have now done so:
{{cite book/new |editors=Editors |editor-last2=Editor Last2 |title=Title}}
- →Editor Last2 (ed.). Title.
{{cite book}}
:|editor-last2=
has generic name (help); Missing|editor1=
(help); Unknown parameter|editors=
ignored (|editor=
suggested) (help)CS1 maint: numeric names: editors list (link) {{cite book/new |editor=Editor |editor-last2=Editor Last2 |title=Title}}
- →Editor; Editor Last2 (eds.). Title.
{{cite book}}
:|editor=
has generic name (help)CS1 maint: numeric names: editors list (link) {{cite book/new |editor1=Editor1 |editor-last2=Editor Last2 |title=Title}}
- →Editor1; Editor Last2 (eds.). Title.
{{cite book}}
:|editor1=
has generic name (help)CS1 maint: numeric names: editors list (link) {{cite book/new |editors=Editors |editor-last1=Editor Last1 |title=Title}}
- →Editor Last1 (ed.). Title.
{{cite book}}
:|editor-last1=
has generic name (help); Unknown parameter|editors=
ignored (|editor=
suggested) (help)CS1 maint: numeric names: editors list (link)
—Trappist the monk (talk) 10:23, 23 April 2015 (UTC)
Questions regarding citation of a government report
I would like to cite this section of this report for use in October Surprise conspiracy theory and related articles. I am wondering if the following is sufficient:
- <ref name="October Surprise Task Force">{{cite book |title=Joint report of the Task Force to Investigate Certain Allegations Concerning the Holding of American Hostages by Iran in 1980 ("October Surprise Task Force") |url=http://babel.hathitrust.org/cgi/pt?id=mdp.39015060776773;view=1up;seq=1 |date=January 3, 1993 |publisher=United States Government Printing Office |location=Washington, D.C. |page=147|chapter=VII. Alleged Attempts to Delay the Release of the Hostages |chapterurl=http://babel.hathitrust.org/cgi/pt?id=mdp.39015060776773;view=1up;seq=161;size=150 |ref={{harvid|"October Surprise Task Force"|1993}}}}</ref>
Which gives...
- "VII. Alleged Attempts to Delay the Release of the Hostages". Joint report of the Task Force to Investigate Certain Allegations Concerning the Holding of American Hostages by Iran in 1980 ("October Surprise Task Force"). Washington, D.C.: United States Government Printing Office. January 3, 1993. p. 147.
{{cite book}}
: External link in
(help); Unknown parameter|chapterurl=
|chapterurl=
ignored (|chapter-url=
suggested) (help)
You may notice that I used {{Cite book}} and that I did not fill in |author=
; I wasn't sure if the author should be United States House of Representatives or just House October Surprise Task Force. Should I also place "H. Rept. No. 102-1102" somewhere? Thanks again! - Location (talk) 15:45, 7 April 2015 (UTC)
- I think that it's VIII
- I'd use
|url=http://hdl.handle.net/2027/mdp.39015060776773
, the book's permalink, and|chapter-url=http://hdl.handle.net/2027/mdp.39015060776773?urlappend=%3Bseq=161
, the chapter's permalink.
- I have no strong opinion about
|author=
except that I think the nickname 'October Surprise Task Force' is too informal.
- —Trappist the monk (talk) 16:24, 7 April 2015 (UTC)
- I agree on the comment about informality of the name. Personally, I'd use the official name of the task force as the author. As for the report number,
|id= H. Rept. No. 102-1102
should work to include it. Adding|oclc= 27492534
(OCLC 27492534) to link to the library catalog entry is another beneficial extension of the citation for readers. Imzadi 1979 → 16:47, 7 April 2015 (UTC)- Thanks for the feedback. Although it makes the citation quite lengthy, I used the formal name in
|author=
but House October Surprise Task Force for its link:- Task Force to Investigate Certain Allegations Concerning the Holding of American Hostages by Iran in 1980 (January 3, 1993). "VIII. Alleged Attempts to Delay the Release of the Hostages". Joint report of the Task Force to Investigate Certain Allegations Concerning the Holding of American Hostages by Iran in 1980 ("October Surprise Task Force"). Washington, D.C.: United States Government Printing Office. p. 147. OCLC 27492534. H. Rept. No. 102-1102.
{{cite book}}
: External link in
(help); Unknown parameter|chapterurl=
|chapterurl=
ignored (|chapter-url=
suggested) (help)CS1 maint: numeric names: authors list (link)
- Task Force to Investigate Certain Allegations Concerning the Holding of American Hostages by Iran in 1980 (January 3, 1993). "VIII. Alleged Attempts to Delay the Release of the Hostages". Joint report of the Task Force to Investigate Certain Allegations Concerning the Holding of American Hostages by Iran in 1980 ("October Surprise Task Force"). Washington, D.C.: United States Government Printing Office. p. 147. OCLC 27492534. H. Rept. No. 102-1102.
- By the way, where did you find the OCLC number? - Location (talk) 18:22, 7 April 2015 (UTC)
- The webpage displaying the report has a link on its left side to "Find in a library". Clicking that takes you to the worldcat.org entry: http://www.worldcat.org/title/joint-report-of-the-task-force-to-investigate-certain-allegations-concerning-the-holding-of-american-hostages-by-iran-in-1980-october-surprise-task-force/oclc/27492534 . Imzadi 1979 → 18:36, 7 April 2015 (UTC)
- Thanks again! - Location (talk) 19:53, 7 April 2015 (UTC)
- The webpage displaying the report has a link on its left side to "Find in a library". Clicking that takes you to the worldcat.org entry: http://www.worldcat.org/title/joint-report-of-the-task-force-to-investigate-certain-allegations-concerning-the-holding-of-american-hostages-by-iran-in-1980-october-surprise-task-force/oclc/27492534 . Imzadi 1979 → 18:36, 7 April 2015 (UTC)
- Thanks for the feedback. Although it makes the citation quite lengthy, I used the formal name in
- I agree on the comment about informality of the name. Personally, I'd use the official name of the task force as the author. As for the report number,
Exclude some templates from citation errors?
Is it possible to exclude some template pages from citation errors, such as Template:AASHTO minutes and Template:Accu-Stats? Note that I'm just asking about the template pages themselves, not incorrect uses of the templates in articlespace. Thanks! GoingBatty (talk) 01:23, 8 April 2015 (UTC)
- There is some way to do this with
<noinclude>
statements, but some people got hot and bothered when it was done to a batch of template pages a while ago, so I'm not inclined to mess with it. I'm open to clever suggestions, because they bug me when I run a report of templates with errors using catscan. – Jonesey95 (talk) 02:30, 8 April 2015 (UTC)- Actually, I think you probably want WP:INCLUDEONLY (
<includeonly>...</includeonly>
) so that the code is processed in transclusions, but not for the template itself - Evad37 [talk] 02:40, 8 April 2015 (UTC)- This would fix his immediate issue but restricts viewing the templates and isn't really a long-term change. --Izno (talk) 16:36, 8 April 2015 (UTC)
- Actually, I think you probably want WP:INCLUDEONLY (
- Probably what core should do is avoid categorizing any errors outside mainspace/draftspace. --Izno (talk) 03:52, 8 April 2015 (UTC)
Given the variety of answers to the original question, it would seem that the original question is a bit imprecise.
But, it did bring to mind something that has been fermenting at the back of my brain for a while. I have noticed that Module:Citation/CS1 categorizes pages that perhaps ought not be categorized. For example, we categorize archived pages, log pages, sandbox pages, testcases pages, and, undoubtedly, others as well. I don't think that it would be too difficult to prevent categorization of these pages if we can come up with a complete list of them.
I've added a snippet of code to Module:Citation/CS1/sandbox that sets the don't-categorize flag when an article title matches any of these simple Lua patterns:
/[Aa]rchive
/[Ll]og
/sandbox
/testcases
Others that might be added are:
/%d%d%d%d
– subpage starts with a year/%a+ %d%d%d%d
– subpage starts with month (or some other text) followed by year
Opinions?
—Trappist the monk (talk) 14:25, 8 April 2015 (UTC)
- I'm amenable (obviously) to starting to de-categorize certain classes of pages. My query would be: why not (additionally?) by namespace? Do we see any particular uses for such categories outside the main/draftspace? --Izno (talk) 16:38, 8 April 2015 (UTC)
- To Trappist: I strongly support removing /sandbox and /testcases from categorization. I do not support summarily decategorizing /Archive and /Log. I just fix those pages instead, and I have had zero complaints (that I can remember, at least).
- To Izno: We already exclude some namespaces. Here's a previous discussion. Please read that discussion and then let us know what namespaces you would recommend that we completely exclude from categorization. I am definitely open to suggestions.
- Excluding the Template namespace is not a good idea, as there are plenty of times when templates have errors that should be fixed, and sometimes those templates are transcluded in hundreds or thousands of pages. If you look through some of my edits, you can see examples of fixes I have made to citation errors in templates.
- To GoingBatty: Clarifying your question, it sounds like you are asking how to exclude Template pages when the transcluded version of the template does not produce errors, but the example version of the template given on the Template's own page has an error. I think that
<includeonly>...</includeonly>
is the way to do that, but I don't remember how to do it. There might be some chatter about it in my Talk page archives. – Jonesey95 (talk) 20:00, 8 April 2015 (UTC)
- To GoingBatty: Clarifying your question, it sounds like you are asking how to exclude Template pages when the transcluded version of the template does not produce errors, but the example version of the template given on the Template's own page has an error. I think that
- Ok, archive and log removed. Are there others that should be added to sandbox and testcases?
Still hidden error messages
These five categories of errors still hide their error messages. Can/should any of these be unhidden?
- Category:Pages using citations with accessdate and no URL – 0
- Category:Pages using web citations with no URL – 0
- Category:Pages containing cite templates with deprecated parameters – 0
- Category:Pages using citations with format and no URL – 0
- Category:Pages using citations with old-style implicit et al. in editors – 0
—Trappist the monk (talk) 14:46, 9 April 2015 (UTC)
- Unhidden as in publicly flogged with red splotches? Yikes. I have a bunch of citations with explicit et als. to revise, but I am waiting for a better resolution of the "missing title" message (a related issue) before proceeding. I would rather keep both of those categories hidden for a while longer. ~ J. Johnson (JJ) (talk) 19:34, 9 April 2015 (UTC)
- The RFC that governs the hiding of these messages says that they should be turned off "until an appropriate bot fixes resolvable instances of the error." We can turn on the error messages in the category when it is not feasible for a bot to fix any of the existing/remaining errors in a given category. Here's my understanding of where each of these categories stands:
- Category:Pages using citations with accessdate and no URL – A morass. There is no consensus about what to do with this category, despite multiple discussions over the years.
- Category:Pages using web citations with no URL – Nobody has proposed a way to address this category with a bot. I have not seen any discussion about this category. If we decide that it is not possible for a bot to fix these errors, the error messages can be displayed.
- Category:Pages containing cite templates with deprecated parameters – Monkbot has drastically reduced the number of errors in this category. I think that a significant fraction of the remaining articles are bot-fixable.
- Category:Pages using citations with format and no URL – Nobody has proposed a way to address this category with a bot. I have not seen any discussion about this category. If we decide that it is not possible for a bot to fix these errors, the error messages can be displayed.
- Category:Pages using citations with old-style implicit et al. in editors – These articles could be fixed by Citation Bot or a bot with similar journal lookup capabilities. I requested this feature a while ago. Citation Bot is not actively maintained.
- Please discuss the individual categories below. If my summaries above are incorrect, please post corrections below, and I will add strikethrough markup to, and adjust, the summaries. – Jonesey95 (talk) 23:17, 9 April 2015 (UTC)
Pages using citations with accessdate and no URL
Someone should troll through the archives for previous discussions before rehashing them here. – Jonesey95 (talk) 23:17, 9 April 2015 (UTC)
- A list of links to many of these previous discussions is included in my recent census of data for this error. The last link in the list was not updated by a bot before the post was moved to the archives - it is found at [3]. Stamptrader (talk) 22:02, 13 April 2015 (UTC)
Pages using web citations with no URL
Pages containing cite templates with deprecated parameters
I am willing to work to help Monkbot clear up bot-fixable entries in this category. – Jonesey95 (talk) 23:17, 9 April 2015 (UTC)
- I have a script that will clear a lot of the
|name-list-format=
related parameter errors but I stopped running it because of this RfC which remains open.
- A rather significant amount of what remains is
|coauthors=
that Monkbot, without a rewrite, can't do much about. So I'm going to say that this category should remain hidden for now.
Pages using citations with format and no URL
Pages using citations with old-style implicit et al. in editors
There are only about 750 articles in this category, so we could just fix them and then eliminate the category as we did with the "et al. in authors" category. I think that this would be the easiest path. – Jonesey95 (talk) 23:17, 9 April 2015 (UTC)
- Like I said above, I have a handful of articles where a suitable fix (for which Citation Bot is not competent) is tied into other stuff which is not yet ready. ~ J. Johnson (JJ) (talk) 20:09, 10 April 2015 (UTC)
- To editors Jonesey95 and J. Johnson: I've just noticed today that, in addition to CS1 errors in red, there are now notices of CS1 maintenance in green, which link to various maintenance categories. The reason I'm asking about this here is that the first one I came across was the CS1 maint: Explicit use of et al. category. I haven't been able to find much information on these categories, so I am compelled to ask, "Is this how the 'et al. in authors' category you mention was 'eliminated'? just by redefining it from an 'error' to a 'maintenance' item?" – Paine EllsworthCLIMAX! 02:42, 13 April 2015 (UTC)
- Implicit et al. is an error message (red) and caused by citations that have exactly four editors. In the old
{{citation/core}}
version, templates with four or more editors would display three editors followed by et al. In the Module:Citation/CS1 version, you can display as many as you'd like. The implicit (red) message was there because the Module mimics{{citation/core}}
. Once Category:Pages using citations with old-style implicit et al. in editors is cleared, that error message will go away.
- Implicit et al. is an error message (red) and caused by citations that have exactly four editors. In the old
- Explicit et al. refers to the intentional addition of the text string et al. (in a variety of flavors) to any of the author or editor parameters. This is a maintenance category with attendant green messages because at the time the code was developed there wasn't a viable 'solution' to the problem (the et al. text corrupts the COinS meta data). At the next update of the Module, editors will be able to set
|display-authors=etal
and|display-editors=etal
so that the template displays the et al. text regardless of how many authors/editors are included in the template.
- Explicit et al. refers to the intentional addition of the text string et al. (in a variety of flavors) to any of the author or editor parameters. This is a maintenance category with attendant green messages because at the time the code was developed there wasn't a viable 'solution' to the problem (the et al. text corrupts the COinS meta data). At the next update of the Module, editors will be able to set
- Paine Ellsworth, the maintenance category and the original authors category are unrelated. See this discussion for an explanation of how the display-authors et al. category was eliminated through hard work, not through any sort of sleight of hand. – Jonesey95 (talk) 13:49, 13 April 2015 (UTC)
- Thank you both for helping me to fill in the gaps of my understanding. I really did not mean to imply any "sleight of hand", Jonesey95, only perhaps a lowering of priorities so that more important issues may be more easily seen and addressed. I see now that I was mixing apples and oranges. Thank you again, and we wish the best of everything to you and yours! – Paine EllsworthCLIMAX! 08:59, 14 April 2015 (UTC)
- To editors Jonesey95, Trappist the monk and J. Johnson: Thank you so much for this! I fixed one in the Java Man article and several more at Mitochondrion, and it works great! Thank you! and Best of everything to you and yours! – Paine 00:15, 19 April 2015 (UTC)
Update to the live CS1 module weekend of 18–19 April 2015
On the weekend of 18–19 April I propose to update the live CS1 module files from the sandbox counterparts:
Changes to Module:Citation/CS1 are:
- migrate
{{cite episode}}
; discussion - migrate
{{cite serial}}
; discussion - fix
|type=
anomaly in cite map; discussion - fix duplicate separator character bug; discussion
- add
|sheet=
,|sheets=
, and|trans-map=
for cite map; discussion - migrate
{{cite arxiv}}
; discussion - add support for multiple comma-separated languages in
|language=
; discussion - add support for
|archive-format=
,|conference-format=
,|contribution-format=
,|event-format=
,|lay-format=
,|section-format=
,|transcript-format=
; add automatic pdf detection and annotation; discussion; discussion - expand accepted character sets for Vancouver style; discussion
|display-authors=etal
support; discussion|authors=
not (and hasn't ever really been) an alias of|lastn=
; discussion- categorize expired PMC embargoes; discussion
- do not categorize /sandbox and /testcases subpages; discussion
- move static text (properties and maintenance category names, default title types) to Module:Citation/CS1/Configuration/sandbox;
Changes to Module:Citation/CS1/Configuration are:
- add
|credits=
,|began=
,|ended=
, for{{cite episode}}
and{{cite serial}}
; - add
|sheet=
,|sheets=
, and|trans-map=
for{{cite map}}
; - add
|class=
,|eprint=
for{{cite arxiv}}
; - add
|archive-format=
,|conference-format=
,|contribution-format=
,|event-format=
,|lay-format=
,|section-format=
,|transcript-format=
; discussion; discussion - remove
Authors#
fromAuthorList-Last
-|authors=
not an alias of|last=
; discussion - remove invalidated
|DoiBroken=
,|Embargo=
,|PPPrefix=
(standardizing on the lower case versions of these parameter names); discussion - add
citation_config.maint_cats
table; - made all tables local; add
uncategorized_subpages
,prop_cats
,title_types
tables;
Changes to Module:Citation/CS1/Whitelist are:
- add
|credits=
,|began=
,|ended=
, for{{cite episode}}
and{{cite serial}}
; - add
|episode=
for cite serial; - add
|sheet=
,|sheets=
, and|trans-map=
for{{cite map}}
; - add
|class=
,|eprint=
for{{cite arxiv}}
; - add
|archive-format=
,|conference-format=
,|contribution-format=
,|event-format=
,|lay-format=
,|section-format=
,|transcript-format=
; discussion; discussion - invalidated
|authorsn=
and|editorsn=
; discussion - deprecated
|Authorn=
,|Editorn=
,|EditorGivenn=
,|EditorSurnamen=
(standardizing on the lower case versions of these parameter names); discussion - invalidated
|DoiBroken=
,|Embargo=
,|PPPrefix=
(standardizing on the lower case versions of these parameter names); discussion - make all tables local;
Changes to Module:Citation/CS1/Date validation are:
- add "Christmas" as a valid month/season; discussion
- refined
|access-date=
checking; discussion
—Trappist the monk (talk) 11:00, 11 April 2015 (UTC)
- Thoughts on incorporating
|orig-date=
, perhaps by aliasing|orig-year=
to it? (discussion) ~ Tom.Reding (talk ⋅contribs ⋅dgaf) 16:58, 11 April 2015 (UTC)
- Trappist the monk, please post here when you have made the above edits so that we can update the documentation. Am I correct in thinking that we will be able to remove all of the non-Lua text from the template documentation files? – Jonesey95 (talk) 23:04, 11 April 2015 (UTC)
- Yes, I think so.
- I checked all of the transclusions of Template:Citation Style documentation/author, one of our documentation subtemplates (from which non-Lua documentation will be removed), and it was being used by only two templates that were not "CS1 core" templates: {{Cite wikisource}} and {{Cite IETF}}. Both use {{citation/core}} to render citations. I substed the non-Lua documentation into those templates' documentation pages, and I left a note on the talk page for each to explain that watchers there should check the documentation for accuracy.
- I also checked transclusions of the CS1 title documentation, figuring that author and title would be transcluded most frequently. It looks like we are OK to proceed with removing non-Lua wording from all of these doc templates after the module update. – Jonesey95 (talk) 14:16, 12 April 2015 (UTC)
- Hold up! Let's not be over hasty in deprecating the
|author=
(|authorN=
) parameter. Doing so was a comment on the indicated discussion, it was not actually discussed. Some authorship is attributed to groups or organizations, the names of which do not map into first/last (personal/surname), so we do need a general "author's name" parameter (note possessive form). I believe the deprecation we discussed was of plural "authors". Similarly for "editors". ~ J. Johnson (JJ) (talk) 18:30, 16 April 2015 (UTC)
|authors=
(plural) is not deprecated:- nor is
|author=
(singular) - nor is
|authorn=
(also singular) - —Trappist the monk (talk) 18:42, 16 April 2015 (UTC)
- Under "Changes to Module:Citation/CS1/Whitelist" you have:
- "7. deprecated
|Authorn=
,|Editorn=
...."
- "7. deprecated
- Is there something here I don't understand? ~ J. Johnson (JJ) (talk) 19:31, 16 April 2015 (UTC)
- I think that's just the capitalized version he's removing support for. --Izno (talk) 19:34, 16 April 2015 (UTC)
- Under "Changes to Module:Citation/CS1/Whitelist" you have:
- Yes, non-standard capitalization per this discussion.
- —Trappist the monk (talk) 19:42, 16 April 2015 (UTC)
- We are standardizing on all lower case for parameter names, except for initialisms like DOI, ISBN, and similar identifiers. So
|authors=
is fine, but|Authors=
is being deprecated. Note the non-standard capital "A" in the second parameter name. If you look at the Whitelist now, you will see only a few parameters that start with capital letters. They are essentially never used, so it should not be a burden to deprecate them. Sorry for any confusion. – Jonesey95 (talk) 21:15, 16 April 2015 (UTC)
- We are standardizing on all lower case for parameter names, except for initialisms like DOI, ISBN, and similar identifiers. So
- —Trappist the monk (talk) 19:42, 16 April 2015 (UTC)
- Ah, yes. I was thinking we were being casual about case. I'll talk with my barista about adjusting my caffeination. ~ J. Johnson (JJ) (talk) 21:15, 16 April 2015 (UTC)
Update complete
This update is complete. Most documentation has been updated. If you notice any errors or omissions, please post your findings here. – Jonesey95 (talk) 04:40, 19 April 2015 (UTC)
- I noticed that the deprecated parameters
|began=
and|ended=
are still shown in the {{Cite episode}} documentation. There may well be others, this is simply one that I noticed while cleaning up CS1 errors earlier tonight. Stamptrader (talk) 04:55, 19 April 2015 (UTC)- Good catch. Fixed.
- I have noticed that some of the "if lua" statements have not been removed from documentation subpages, but it's late at night where I am, and I do not trust my brain to do complex editing at this time of night. – Jonesey95 (talk) 05:33, 19 April 2015 (UTC)
- Another small point regarding the update (but not the documentation) - there seems to have been code added to the module to capitalize the contents of the
|format=
parameter. A large number of citations (about 6800 according to an insource: search) populate the|format=
parameter with[[Portable Document Format|PDF]]
, creating a wikilink to the PDF article. However, the module code turns the parameter contents into[[PORTABLE DOCUMENT FORMAT|PDF]]
, which created a red patch of text because there wasn't a Wikipedia article with that capitalization. There is now, I created a redirect page to get rid of the red ink, but there may be other examples cropping up. Stamptrader (talk) 07:30, 19 April 2015 (UTC)
- Another small point regarding the update (but not the documentation) - there seems to have been code added to the module to capitalize the contents of the
- I have noticed that some of the "if lua" statements have not been removed from documentation subpages, but it's late at night where I am, and I do not trust my brain to do complex editing at this time of night. – Jonesey95 (talk) 05:33, 19 April 2015 (UTC)
Fixed in the sandbox.
Wikitext | {{cite web
|
---|---|
Live | "Title" (pdf). |
Sandbox | "Title" (pdf). |
—Trappist the monk (talk) 10:57, 19 April 2015 (UTC)
But, just to be a counterpoint:
Wikitext | {{cite map
|
---|---|
Live | Ohio Department of Highways (1930). Map of Ohio showing State Routes (MrSID) (Map). |
Sandbox | Ohio Department of Highways (1930). Map of Ohio showing State Routes (MrSID) (Map). |
The "r" in MrSID shouldn't be capitalized. Imzadi 1979 → 11:25, 19 April 2015 (UTC)
- Ok, no case shifting.
With the format added automatically, anything that was using (or rather, misusing) |type=PDF
now shows (PDF) twice, eg:
Wikitext | {{cite map
|
---|---|
Live | Title (PDF) (PDF). |
Sandbox | Title (PDF) (PDF). |
Could this or should this be tracked, and/or would this be fixable with an AWB run? (The real examples I noticed are at this revision of North West Coastal Highway, but I intend to fix them shortly.) - Evad37 [talk] 13:02, 19 April 2015 (UTC)
- An insource: search for
/\| *type *= *pdf/
finds about 400 instances of|type=pdf
. I'm just now working on an AWB script that will remove the now redundant|format=pdf
when|url=
points to one of the MediWiki recognized pdf file extensions so making a tweak to that code to handle|type=pdf
fits nicely.
- —Trappist the monk (talk) 13:15, 19 April 2015 (UTC)
- I don't agree that
|format=pdf
is redundant. It might well be in the English Wikipedia at the moment, but (1) urls can change and often remove the Mediawiki recognised pdf file extensions; (2) our articles are translated and reused in other wikis where there is no guarantee of support for automatic addition of the PDF indicator. We should not be needlessly throwing away data just because of our own assumptions about redundancy. --RexxS (talk) 18:58, 19 April 2015 (UTC)
- I don't agree that
chapter and section
Nothing in {{tl:cite book}} suggests that chapter and section are mutually exclusive. Ideally they should be allowed concurrently, but at a minimum the documentation should reflect that it is not permitted. The particular case I wanted was
{{cite book|last1=Bowen
|first1=Ray M.
|authorlink1=
|last2=Wang
|first2=C.-C.
|last3=Ratiu
|first3=T.
|title=INTRODUCTION TO VECTORS AND TENSORS, Linear and Multilinear Algebra, Volume 1
|url=http://repository.tamu.edu/bitstream/handle/1969.1/2502/IntroductionToVectorsAndTensorsVol1.pdf
|format=PDF
|year=2010
|language=English
|isbn=0-306-37508-7
|page=214
|chapter=Chapter 7 TENSOR ALGEBRA
|section=Section 32. The Second Dual Space, Canonical Isomorphisms
|quote=Since the isomorphism J is defined without using any structure in addition to the vector space structure on V. , its notation can often be suppressed without any ambiguity. We shall adopt such a convention here and identify any v \in V as a linear function on <Math>V^*.
|separator= ,
|lastauthoramp=}}
, where Section 32 is within Chapter 7.
Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:46, 12 April 2015 (UTC)
- In such cases I would usually just use a contribution (or chapter) parameter referring to the section, but with the chapter number attached:
|contribution=7.32 The Second Dual Space, Canonical Isomorphisms
. If you really need the chapter title you can also include it as part of the same parameter. By the way, please do not use all-caps in the book and chapter titles, per MOS:CAPS. —David Eppstein (talk) 20:07, 12 April 2015 (UTC)- There is also the other case where a book is in volumes, subdivided into sections (or parts) for some editions and then chapters within those sections (or parts). Take for example versions of Magna Britannia;: Being a Concise Topographical Account of ..., Volume 2, Part 2. Of course one can hack in the different combinations, but it would be better if books could have volume, section, part and chapter, to be combined as needed to follow usage in the book. -- PBS (talk) 12:35, 13 April 2015 (UTC)
- It bothers me to use a parameter explicitly named "chapter" for something not a chapter. But in the case here it seems to me that you have to decide whether the source is the book, or a chapter in the book. The latter is typically where the chapters have separate authorship. But this is rarely so at the level of sections (though I have seen exceptions). Citing a section is typically an in-source location of specific material, of which there may be multiple instances in given source. Such in-source specfification is best done at the level of the short cite. E.g.: "Smith et al. (2009), §26". ~ J. Johnson (JJ) (talk) 19:52, 13 April 2015 (UTC)
- In the example given above, the source is the whole book (by Bowen and Wang), and the chapter, section and page number are all in-source location information. The usual citation style would just give the page number. There's sometimes a tendency to think that if a template has fields, they should be filled in. Kanguole 21:29, 13 April 2015 (UTC)
- It bothers me to use a parameter explicitly named "chapter" for something not a chapter. But in the case here it seems to me that you have to decide whether the source is the book, or a chapter in the book. The latter is typically where the chapters have separate authorship. But this is rarely so at the level of sections (though I have seen exceptions). Citing a section is typically an in-source location of specific material, of which there may be multiple instances in given source. Such in-source specfification is best done at the level of the short cite. E.g.: "Smith et al. (2009), §26". ~ J. Johnson (JJ) (talk) 19:52, 13 April 2015 (UTC)
- Indeed. There is also confusion between use of "pages" in a full citation to indicate the location of the source within the work, and the in-source specification of a particular location. Then there is the classical footnote usage of including the full citation in the first reference, along with the specific page number. In a certain respect all of this is simple, but it is also a little bit complicated, and I despair that we will ever (in my lifetime?) have a simple, understandable explanation of all this. ~ J. Johnson (JJ) (talk) 22:15, 13 April 2015 (UTC)
- Re the page number ambiguity: yes. This is especially problematic when the citation is to a journal article (where by convention we always list the page number range for the whole article) but where we want to refer to a specific point within the article. The way I generally handle this is something like what you recommend above with a short cite: give the full journal citation (with the full page range), but then either at the same place or in a footnote referring to the article give the more specific location where a quote or result can be found. —David Eppstein (talk) 23:19, 13 April 2015 (UTC)
- Indeed. There is also confusion between use of "pages" in a full citation to indicate the location of the source within the work, and the in-source specification of a particular location. Then there is the classical footnote usage of including the full citation in the first reference, along with the specific page number. In a certain respect all of this is simple, but it is also a little bit complicated, and I despair that we will ever (in my lifetime?) have a simple, understandable explanation of all this. ~ J. Johnson (JJ) (talk) 22:15, 13 April 2015 (UTC)
cite arxiv tweaks
Something I missed:
|version=
should have been deprecated because it can and should be concatenated onto |arxiv=
or |eprint=
. I have fixed that in the sandbox:
{{Cite arXiv/new |eprint=1004.5110 |class=physics.atom-ph |title= Extreme ultraviolet frequency comb metrology |version=v2 |date=10 May 2010 |first1=Dominik Z. |last1=Kandula |first2=Christoph |last2=Gohle |first3=Tjeerd J. |last3=Pinkert |first4=Wim |last4=Ubachs |first5=Kjeld S.E. |last5=Eikema}}
- →Kandula, Dominik Z.; Gohle, Christoph; Pinkert, Tjeerd J.; Ubachs, Wim; Eikema, Kjeld S.E. (10 May 2010). "Extreme ultraviolet frequency comb metrology". arXiv:1004.5110 [physics.atom-ph].
{{cite arXiv}}
: Unknown parameter|version=
ignored (help)
—Trappist the monk (talk) 18:25, 18 April 2015 (UTC)
Suggestion for maintenance category: redundant "edition" or "ed" used in |edition
Would it make sense to set up a maintenance category for citations using a redundant "ed." or "edition" in the |edition=
parameter? Like this:
Wikitext | {{cite book
|
---|---|
Live | Book author. Book title (2nd edition ed.). {{cite book}} : |author= has generic name (help); |edition= has extra text (help)
|
Sandbox | Book author. Book title (2nd edition ed.). {{cite book}} : |author= has generic name (help); |edition= has extra text (help)
|
I have seen "edition", "Edition", "ed", "ed.", and possibly other variants in the wild. A bot or AWB script should be able to tidy these without much fuss, and without the need for a red error message. – Jonesey95 (talk) 05:10, 20 April 2015 (UTC)
- Added detection of 'edition', 'ed', 'ed.' (insensitive to first letter case) where they occur at the end of
|edition=
:- Book author. Book title (2nd Edition ed.).
{{cite book}}
:|author=
has generic name (help);|edition=
has extra text (help) - Book author. Book title (2nd ed ed.).
{{cite book}}
:|author=
has generic name (help);|edition=
has extra text (help) - Book author. Book title (2nd Ed. ed.).
{{cite book}}
:|author=
has generic name (help);|edition=
has extra text (help) - Book author. Book title (Edition Grande Plus ed.).
{{cite book}}
:|author=
has generic name (help)
- Book author. Book title (2nd Edition ed.).
- Are there other versions of this that should be detected?
- Are there other parameters that should be handled the same way?
- I can't think of anything that I have actually seen, but it stands to reason that there are instances of "pp." within the
|pages=
parameter. I would prefer to find some in the wild before adding code to the module, since coding for hypothetical problems is the first step to madness. – Jonesey95 (talk) 13:30, 20 April 2015 (UTC)
- I can't think of anything that I have actually seen, but it stands to reason that there are instances of "pp." within the
- Yep, these insource: search strings:
insource:/\| *page *= *p/
found 442 instancesinsource:/\| *pages *= *p/
found 4334 instancesinsource:/\| *nopp *= *[YyTt]/
found 1726 instances
- Given this, it seems that we might also add categorize citations into Category:CS1 maint: Extra text when
|page(s)=p n
,|page(s)=p. n
,|page(s)=pp n
,|page(s)=pp. n
,|page(s)=page n
,|page(s)=pages n
, wheren
can be any letter nor number, but not when|nopp=
is set. So I'll work on that.
- Yep, these insource: search strings:
- Sandbox tweaked. These of various forms of p. and pp.:
|page=123
– Title. p. 123.{{cite book}}
: Cite has empty unknown parameter:|nopp=
(help)|page=p123
– Title. p. p123.{{cite book}}
:|page=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|page=pp123
– Title. p. pp123.{{cite book}}
:|page=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|page=p 123
– Title. p. p 123.{{cite book}}
:|page=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|page=pp 123
– Title. p. pp 123.{{cite book}}
:|page=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|page=p.123
– Title. p. p.123.{{cite book}}
:|page=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|page=p. 123
– Title. p. p. 123.{{cite book}}
:|page=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|page=pp.123
– Title. p. pp.123.{{cite book}}
:|page=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|page=pp. 123
– Title. p. pp. 123.{{cite book}}
:|page=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)
- pages:
|pages=123
– Title. p. 123.{{cite book}}
: Cite has empty unknown parameter:|nopp=
(help)|pages=p123
– Title. pp. p123.{{cite book}}
:|pages=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|pages=pp123
– Title. pp. pp123.{{cite book}}
:|pages=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|pages=p 123
– Title. pp. p 123.{{cite book}}
:|pages=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|pages=pp 123
– Title. pp. pp 123.{{cite book}}
:|pages=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|pages=p.123
– Title. pp. p.123.{{cite book}}
:|pages=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|pages=p. 123
– Title. pp. p. 123.{{cite book}}
:|pages=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|pages=pp.123
– Title. pp. pp.123.{{cite book}}
:|pages=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|pages=pp. 123
– Title. pp. pp. 123.{{cite book}}
:|pages=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)
- and for page and pages:
|page=page123
– Title. p. page123.{{cite book}}
:|page=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|page=page 123
– Title. p. page 123.{{cite book}}
:|page=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|pages=pages123
– Title. pp. pages123.{{cite book}}
:|pages=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|pages=pages 123
– Title. pp. pages 123.{{cite book}}
:|pages=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|page=pagerange
– Title. p. pagerange.{{cite book}}
:|page=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)|pages=pagerange
– Title. pp. pagerange.{{cite book}}
:|pages=
has extra text (help); Cite has empty unknown parameter:|nopp=
(help)
- Shouldn't categorize:
|pages=preface, 123
– Title. pp. preface, 123.{{cite book}}
: Cite has empty unknown parameter:|nopp=
(help)|page=Preface
– Title. p. Preface.{{cite book}}
: Cite has empty unknown parameter:|nopp=
(help)|pages=p 123
|nopp=y
– Title. p 123.{{cite book}}
:|pages=
has extra text (help); Unknown parameter|nopp=
ignored (|no-pp=
suggested) (help)|page=page 123
|nopp=y
– Title. page 123.{{cite book}}
:|page=
has extra text (help); Unknown parameter|nopp=
ignored (|no-pp=
suggested) (help)
- Doesn't categorize because at least some of these could be legitimate:
|pages=pA1
– Title. pp. pA1.{{cite book}}
: Cite has empty unknown parameter:|nopp=
(help)|page=p.A1
– Title. p. p.A1.{{cite book}}
: Cite has empty unknown parameter:|nopp=
(help)|pages=ppA1
– Title. pp. ppA1.{{cite book}}
: Cite has empty unknown parameter:|nopp=
(help)|pages=pp.A1
– Title. pp. pp.A1.{{cite book}}
: Cite has empty unknown parameter:|nopp=
(help)
- I have also limited the set of allowable parameter values for
|nopp=
toyes
,y
,true
(case insensitive) because|nopp=no
turns off the page prefixes but shouldn't. An insource: search forinsource:/\| *nopp *= *[Nn]/
found one instance which I shall fix.
- Sandbox tweaked. These of various forms of p. and pp.:
- —Trappist the monk (talk) 14:02, 21 April 2015 (UTC)
- You probably should make sure that any error checks for p or pp in page/pages is not carried out in cite journal, as they are likely to be intentionalNigel Ish (talk) 17:14, 21 April 2015 (UTC)
- Can I have an example of where it makes sense to include p. or pp. in the page specification of a journal article?
- You probably should make sure that any error checks for p or pp in page/pages is not carried out in cite journal, as they are likely to be intentionalNigel Ish (talk) 17:14, 21 April 2015 (UTC)
- —Trappist the monk (talk) 14:02, 21 April 2015 (UTC)
The Astronomical Almanac names each chapter with a capital letter, and restarts the page numbering with each chapter. There are other books that do this too. In 2011 they were up to chapter N; maybe by the end of the decade they will be up to chapter P. A citation would look something like
{{cite book/new |title=Astronomical Almanac for the Year 2020 |page=P7 |nopp=}}
which would render as
Astronomical Almanac for the Year 2020. p. P7. {{cite book}}
: Cite has empty unknown parameter: |nopp=
(help)
Jc3s5h (talk) 17:38, 21 April 2015 (UTC)Q
- I have tweaked the code to answer this particular case.
- As cite journal is the only citation style 1 template that omits p. and pp. from the displayed output, it is necessary to add them to make cites look consistent between cite journal and cite news/book etc, and to make the sourcing clear to the reader.Nigel Ish (talk) 18:36, 21 April 2015 (UTC)
- May be we should change {{cite journal}} to put in the p. or pp. to be consistent with the other templates and then the presence of the p. or pp. can be detected and removed. Should not be removing from instances of this template without the template change being made. Keith D (talk) 19:10, 21 April 2015 (UTC)
- Some editors are probably adding the explicit page indication when they use {{cite journal}} or {{cite magazine}} because the citation looks too confusing with the clump of numbers at the end. If {{cite news}} is used, an explicit page indicator is added by the module code, but that is left out of {{cite journal}} to conform with norms in scientific citations. Consider this citation from the Leicester and Swannington Railway article - it looks doubly clumsy without the inclusion of an author, as then the date gets tacked on to the mix of numbers and things get real confusing even with the addition of an indicator in the
|page=
parameter. First, {{cite journal}} as originally written, then {{cite journal}} as it would look if the page indicator had been left out, then {{cite journal}} as it would look if there had been an author included in the citation, then {{cite news}} as it would look if that had been used while retaining the editor's page indicator text.- "Stephenson tunnel saved". The Railway Magazine. 154 (1, 292): p 10. December 2008.
{{cite journal}}
:|page=
has extra text (help) - "Stephenson tunnel saved". The Railway Magazine. 154 (1, 292): 10. December 2008.
- Author (December 2008). "Stephenson tunnel saved". The Railway Magazine. 154 (1, 292): p 10.
{{cite journal}}
:|author=
has generic name (help);|page=
has extra text (help) - "Stephenson tunnel saved". The Railway Magazine. Vol. 154, no. 1, 292. December 2008. p. p 10.
{{cite news}}
:|page=
has extra text (help)
- "Stephenson tunnel saved". The Railway Magazine. 154 (1, 292): p 10. December 2008.
- I think an editor coming at referencing from a "non-academic normal guy" standpoint can be easily confused by the text generated for citations when using {{cite journal}}, and some of these uses of an explicit page indicator within the
|page=
parameter will be attempts at making things easier to read. Stamptrader (talk) 20:36, 21 April 2015 (UTC)- Maybe we could consider changing the formatting of journal references to something like "Journal, vol. 3, no. 2, pp. 54–128" instead of "Journal 3 (2): 54–128"? It's a little less concise (so what) and less like typical academic citation formats (also so what) but clear enough and much less intimidating, I think. Not to be done without a lot of discussion first, though, since this is a big change. —David Eppstein (talk) 21:11, 21 April 2015 (UTC)
- I'm looking at CMOS 16, and for citing a specific volume of multivolume books, it uses "4:243" to put the volume and page number together if the volume lacks a separate name. For journals, they use "76, no. 1 (2006): 19–35;" after the name of the journal. On that basis, David Eppstein's idea of explicitly adding the "vol", "no." and "p."/"pp." prefixes isn't far fetched. What I've wanted to do for {{cite journal}} is that "76(1):19–35" would be fine, but if the volume or issue number are dropped, the "p." or "pp." would appear with the page number, but the less concise format may be better for Stamptrader's "non-academic normal guy". As it is, I wish many of our editors would heed the advice to stop using the overly abbreviated journal names in deference to our non-academic readers. Imzadi 1979 → 22:36, 21 April 2015 (UTC)
- Maybe we could consider changing the formatting of journal references to something like "Journal, vol. 3, no. 2, pp. 54–128" instead of "Journal 3 (2): 54–128"? It's a little less concise (so what) and less like typical academic citation formats (also so what) but clear enough and much less intimidating, I think. Not to be done without a lot of discussion first, though, since this is a big change. —David Eppstein (talk) 21:11, 21 April 2015 (UTC)
- Some editors are probably adding the explicit page indication when they use {{cite journal}} or {{cite magazine}} because the citation looks too confusing with the clump of numbers at the end. If {{cite news}} is used, an explicit page indicator is added by the module code, but that is left out of {{cite journal}} to conform with norms in scientific citations. Consider this citation from the Leicester and Swannington Railway article - it looks doubly clumsy without the inclusion of an author, as then the date gets tacked on to the mix of numbers and things get real confusing even with the addition of an indicator in the
date for bimonthly issue
Scouting Magazine had a January-February 2005 issue (http://books.google.com/books?id=kfwDAAAAMBAJ&pg=PA40#v=onepage&q&f=false) how should that properly be cited, date=January-February 2005 , still gives a CS1 error.Naraht (talk) 17:33, 20 April 2015 (UTC)
- Use an en dash:
|date=January–February 2005
. – Jonesey95 (talk) 18:01, 20 April 2015 (UTC)- thank you.Naraht (talk) 18:25, 20 April 2015 (UTC)
- How do you format date ranges which span years, please? |date=21 December 1963–1 February 1964 still produces an error. 86.160.232.4 (talk) 22:45, 21 April 2015 (UTC)
- The dash needs to have a space on either side of it:
- "Title". Journal. 21 December 1963 – 1 February 1964.
- "Title". Journal. 21 December 1963–1 February 1964.
{{cite journal}}
: Check date values in:|date=
(help)
- This is how the MOS says we are supposed to format dates in prose, which the templates are designed to enforce. Imzadi 1979 → 22:54, 21 April 2015 (UTC)
- The dash needs to have a space on either side of it:
- How do you format date ranges which span years, please? |date=21 December 1963–1 February 1964 still produces an error. 86.160.232.4 (talk) 22:45, 21 April 2015 (UTC)
Thank you; alles klar. 86.160.232.4 (talk) 22:39, 22 April 2015 (UTC)
accessdate and indirectly-specified URLs
When a reference specifies a URL indirectly, e.g., using a parameter like jstor=
, it ignores accessdate=
and generates the category Pages using citations with accessdate and no URL. For example, in [4], the invocation:
- {{cite journal| last=Nichols|first=Thomas M. |title=Soldiers and War: A Top Ten List |journal=International Journal |date=Spring 2001 |volume=56 |issue=2 |pages=312, 316–317 |jstor=40203558 |accessdate=30 June 2011 |publisher=Canadian International Council}}
generates:
- Nichols, Thomas M. (Spring 2001). "Soldiers and War: A Top Ten List". International Journal (Canadian International Council) 56 (2): 312, 316–317. JSTOR 40203558. [[Category:Pages using citations with accessdate and no URL]]
Note the missing "Retrieved 30 June 2011." and the category generation.
A work-around (maybe) is to specify the URL both directly via the url=
parameter and indirectly via the jstor=
parameter, see, here, but that's clumsy, and I think there may be a bot that "fixes" the article by converting links to jstor.org to the jstor=
parameter.
I assume this would also occur with other implicit URL indicators (e.g., doi=
, pmid=
, etc., maybe isbn=
and issn=
) but have not confirmed. TJRC (talk) 15:47, 25 April 2015 (UTC)
|access-date=
has always indicated the date that the URL provided in|url=
was last accessed and found to support the content of the Wikipedia article.|access-date=
has never applied to material at archival-like sites such as JSTOR, doi, PMC, ZBL, etc.|isbn=
is different in that it links to Special:BookSources.
- The error message and the category supporting it are correct for your example citation because
|url=
is not specified. If you choose, you may duplicate the JSTOR or other identifier URL in|url=
but that seems to me to be needlessly redundant.
- But a URL is specified: in the
jstor=
parameter. Thejstor=
parameter generates a link to https://www.jstor.org/stable/40203558, which is the accessed source, to which theaccessdate=
refers. It's not an error for an editor to indicate the date on which the cited source at https://www.jstor.org/stable/40203558 was accessed, and should not be flagged by the template. - To make this clear: I'm not saying that the template is incorrectly saying the
url=
parameter is not present. I'm saying the template is incorrectly flagging a template with accessdate= when the URL is specified with a supported parameter other than with theurl=
parameter. It does not make sense to choose between losing the documentary evidence supplied by accessdate= and the needlessly redundantly putting in the URL twice, once viajstor=
and once viaurl=
. - It may be "working as designed" to flag this as a CS1 error; but that just means the bug is in the design, not in the code. IN short, if there is a URL present in the citation to which
accessdate=
refers, it should not be flagged as an error. TJRC (talk) 16:53, 25 April 2015 (UTC)
- But a URL is specified: in the
- I understand what you are saying. It has been said before by others. It is perfectly legitimate to have multiple identifiers,
|pmc=
,|pmid=
,|jstor=
,|doi=
all in the same citation. To which of these would|access-date=
'attach'? Should we have an access date parameter for each of them? What if we accept the premise that|access-date=
applies to identifier-based parameters and also to|url=
. Suppose we have a citation that, legitimately, uses both|url=
and some identifier, both pointing to different resources, to which of these does|access-date=
apply?
- I understand what you are saying. It has been said before by others. It is perfectly legitimate to have multiple identifiers,
- The philosophy regarding
|access-date=
is that it applies when the resource (identified by|url=
) is ephemeral in nature. Identifier-based URLs are considered permanent so are presumed to always be available in the same state they were when the Wikipedia editor added the citation. Resources at ephemeral URLs may be here today and gone tomorrow, may change for no apparent reason, may move to a different location; in essence, link rot. Because these kinds of resources are not permanent, we have|access-date=
to identify the date when the resource was valid, and|archive-url=
and|archive-date=
to help us recover the once-valid resource. This functionality is not required for the permanent identifier-based external links.
- The philosophy regarding
- I agree entirely that
|access-date=
should not be used with identifier-based URLs. I'd just like to point out, though, that access dates are needed for two slightly different reasons: (1) for those URLs that may be transient, as Trappist the monk notes above, and (2) for URLs whose target is updated more-or-less continuously without distinct "versions". In case (1), it's often appropriate to archive the target webpage. In case (2), archiving is usually inappropriate, and the access date is the only way of telling whether the content might have changed. Peter coxhead (talk) 08:55, 26 April 2015 (UTC)
- I agree entirely that
orig-year parameter in Template:Cite web
Is this parameter deprecated? It's listed in the template documentation under "Date", though not in the full parameter set under "Usage". As far as I can tell it doesn't do anything. PC78 (talk) 23:50, 25 April 2015 (UTC)
- Not deprecated but ignored if
|date=
is not set.{{cite web |title=Title |url=//example.com |date=25 April 2015 |orig-year=1995}}
- →"Title". 25 April 2015 [1995].
- —Trappist the monk (talk) 00:10, 26 April 2015 (UTC)
- Ah-ha, thanks for clearing that up. PC78 (talk) 02:33, 26 April 2015 (UTC)