Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
  (Redirected from Module talk:Citation/CS1/sandbox)
Jump to: navigation, search

Chinese and Korean[edit]

I propose that we add an extra parameter that instructs Wikipedia to write the author's name as **family name** - **personal name**, for Korean and Chinese authors. This is how Chinese and Koreans write their names. This template guide advises uses to just put it all in **last**, but if I do this then the **harv** template cannot link to the reference properly. Ghrelinger (talk) 17:33, 10 December 2016 (UTC)

The documentation currently says "last: Surname of a single author", "first: Given or first names of author", and "author: this parameter is used to hold the complete name of a single author (first and last)". What words would you propose? Also see this China-related MOS section. Are you aware of any other guidelines that could help us in this situation? – Jonesey95 (talk) 17:49, 10 December 2016 (UTC)
One can also use the parameters |surname= and |given=. These are aliases for |last= and |first=, but are less confusing when working with East Asian names, in which the surname is customarily first, or a mixture of Eastern and Western names. Kanguole 02:17, 11 December 2016 (UTC)
I think one part of the original comment bears some exploration is that if a Chinese name, like "Wu Ni" were cited using the recommended |author= Wu Ni, it won't work right for |ref=harv applications, and if |last=Wu |first=Ni (or even |surname=Wu |given=Ni) were used, we'd get an extraneous comma resulting in "Wu, Ni" in the rendered citation. Imzadi 1979  03:02, 11 December 2016 (UTC)
It's true that the formatting in a citation is different from the way one normally writes an Eastern name, but that's even more true of Western names ("Smith, John"). Perhaps the current uniform format in a list of citations makes it easier for readers not familiar with all those languages to distinguish surnames ("Wu" and "Smith"). Kanguole 11:19, 11 December 2016 (UTC)
|ref={{harvid}} works well for cases where you want to customize the ref=harv default. – Jonesey95 (talk) 15:06, 11 December 2016 (UTC)
We have had this discussion before. So, here is a possible solution:
  1. create a new parameter, perhaps |surname-eastn=
  2. tweak Module:Citation/CS1 to recognize that parameter as being different from all of the other |last= aliases so that it renders |surname-eastn= and its matching |givenn= (or other acceptable alias) without a comma separator
As a test, I hacked the module sandbox so that it does that with |surname=:
{{cite book/new |surname=Surname |given=Given |surname2=Surname |first2=Given |last3=Last |first3=First |title=Title}}
Surname, Given; Surname, Given; Last, First. Title. 
If this functionality is to be retained, an appropriately named parameter is required; unless we simply declare that, from this point forward, |surname= is defined to hold eastern family names.
Trappist the monk (talk) 18:47, 11 December 2016 (UTC)
It would be rather weird to say that Chinese authors' family names are surnames but those of English authors aren't. Cleaner schemes would be |author-separatorn=none or |author-surname-firstn=y (and similarly for editors, etc), but as argued above I don't think it's necessarily a good idea. Kanguole 19:05, 11 December 2016 (UTC)
I don't see where you or anyone else has argued against the notion of removing the comma from the author-name-rendering when the author's name is Asian. I disagree with your suggestion that |author-separatorn=none or |author-surname-firstn=y are 'cleaner' implementations. Using |surname-eastn= is one parameter (which is required anyway) whereas |surname= plus a separator parameter is two so would bloat a cs1|2 template's author list by as much as a third – especially {{cite journal}} templates which can often have numerous Asian authors.
Trappist the monk (talk) 19:47, 11 December 2016 (UTC)

Because there has been no further discussion, I have reverted the |surname= experiment.

Trappist the monk (talk) 11:46, 25 December 2016 (UTC)

It seems we need to clarify that the standard and most common meaning of surname is "hereditary name common to all members of a family, as distinct from a forename or given name", for all languages. Nor is this a "Chinese and Korean", nor even "eastern" issue: Hungarian (e.g.) also puts the surname first. To make more special cases just makes everything messier, and more complicated.
We should not be recommending putting both surname and personal name into a single parameter (e.g.: |author=Wu Ni), as that is a misuse of "author", corrupts the metadata, and encourages stuff like |author=Doe, John, and further confusion having to explain why names are handled in different ways. Definitely calls for revising the documentation.
I believe the underlying issue is the objection to the inserted comma into an "Asian" name, like "Wu, Ni" (a point which has had some extensive discussion here). I will argue that the presence of the comma should be taken as reassurance that the surname has been properly handled, and provides a consistent view that the surname by which indexing is usually done is everything up to the first comma. ~ J. Johnson (JJ) (talk) 21:53, 26 December 2016 (UTC)
This is putting the cart before the horse. What matters most is what appears to the reader. In most Chinese or Korean names the comma is just wrong. If the name appears as "Lee, Kwan Yew" it just looks ignorant and unprofessional and ridiculous. -- Alarics (talk) 23:49, 26 December 2016 (UTC)
That is certainly the case in running text, but citations are a different matter. After all, an author name like John Smith is displayed differently in a citation than in running text. Names of East Asian authors are often written without the comma in citations in specialist publications on Chinese or Japanese topics, where the target audience all know the convention, but in publications in global topics like the sciences, it is common to mark all authors' family names in citations in a uniform manner. For example, Nature uses "Zhou, L. P." and "Clark, J. D.", while Science uses "L. P. Zhou" and "J. D. Clark". This allows readers to identify the surnames (which are a key identifier of citations, and also used in short citations), without assuming knowledge of regional name conventions. As a general-purpose work, Wikipedia should cater to such an audience, and the natural way to do that is to uniformly use the comma separator after the surname. Kanguole 00:38, 27 December 2016 (UTC)
Another common convention is to write the surname in all-caps, like "LEE Kwan Yew", but that runs afoul of MOS:ALLCAPS. —David Eppstein (talk) 02:11, 27 December 2016 (UTC)
An exception is made for citations per LSA or Bluebook. Not for CS1 though. (talk) 13:41, 27 December 2016 (UTC)
Alarics: you seem to be attributing to a general "reader sensibility" your own notion of what "just looks ignorant and unprofessional and ridiculous", which suggests a basic WP:JDLI. But, Kanguole has shown professional use of the comma, and I would like to think my own comments (above) show that inclusion of the comma is not "ridiculous". As to "ignorant", well, someone not familiar with standard bibliographic and indexing practice might, the first time they encounter it (perhaps in the seventh grade??), think that "Smith, Frank" is pretty ignorant. It's really a matter of convention. And as I said before, we could establish an understanding that the comma delimits the surname, similar to the use of small caps. The world has conflicting usage re surnames, but this use of the comma could be taken as how we resolve it. ~ J. Johnson (JJ) (talk) 21:10, 27 December 2016 (UTC)
We shall have to agree to differ. I shall continue to put "author=Lee Kwan Yew" so that the name appears correctly to the reader. -- Alarics (talk) 19:39, 28 December 2016 (UTC)
Please don't. Doing this makes linking to the reference with {{harv}} much more difficult. —David Eppstein (talk) 20:34, 28 December 2016 (UTC)
In that case it is {{harv}} -- whatever that may be -- that needs fixing. The tail is wagging the dog. What actually matters is how it appears to the reader. If the citation says "Lee, Kwan Yew" the ordinary reader will think we are bonkers. -- Alarics (talk) 20:58, 28 December 2016 (UTC)
Yes, please don't. It seems to me there is a "tail" here trying to wag the dog, but I would say the tail is your insistence in not having the inserted comma. In this case there is nothing needing "fixing" with harv; it does just what it is supposed to do. On the other hand, the problem doing it your way is there is no indication whether "Lee Kwan Yew" is in first-last or last-first order, and whether the surname (essential for searching and indexing) is "Lee" or "Yew". Besides, it is a misuse of |author= to mush together personal and surnames, which blurs the metadata, and condones what with other names is bad practice (like |author=Frank Smith).
I understand the inserted comma annoys you, but that seems really trivial, and I don't understand why you should be so obstinate about this. Nor do I see why any "ordinary reader" should think we are "bonkers". And certainly not if we should adopt the understanding I suggested. ~ J. Johnson (JJ) (talk) 22:23, 28 December 2016 (UTC)
The "ordinary reader" probably doesn't have a clue what referencing is about in the first place, has anyone done a survey?. All reference formatting follows arbitrary conventions, so as long as the convention is easy to use, unambiguous and simple, we can use whatever works best for Wikipedia. We can create our own convention. If Lee, Kwan Yew is clear and unambiguous to the ordinary reader who has little knowledge of the other conventions, cool. It may look a little unconventional to those accustomed to other conventions, but it has the big advantage that it makes clear which is intended to be the family name to those of us who would otherwise wonder whether the editor who inserted the reference got it right or even thought about it. It doesn't stop them getting it wrong, but nothing is foolproof. Also it is easy to use and is currently supported. • • • Peter (Southwood) (talk): 17:45, 6 January 2017 (UTC)

Inconsistent behavior in para: format + para archiveurl[edit]

Take a look at what |format= is doing in {{cite web|url=,11040,4844-188675-205897-133277-0-file,00.pdf |title=World Junior Figure Skating Championships: Ladies' results |work=International Skating Union |format=PDFlink |deadurl=yes |archiveurl=,11040,4844-188675-205897-133277-0-file,00.pdf |archivedate=2013-12-24 }}:

"World Junior Figure Skating Championships: Ladies' results" (PDF). International Skating Union. Archived from the original (PDFlink) on 2013-12-24. 

Would making the parenthetical statements which come after the URLs consistent be desirable? --Izno (talk) 02:47, 1 January 2017 (UTC)

Or perhaps, the archive URL shouldn't have the (automatic) format=PDF detection? What about how deadurl plays into this conundrum? --Izno (talk) 02:48, 1 January 2017 (UTC)
The same citation without a |format= produces "World Junior Figure Skating Championships: Ladies' results" (PDF). International Skating Union. Archived from the original (PDF) on 2013-12-24. , which seems good to me. --Izno (talk) 02:50, 1 January 2017 (UTC)
{{cite web|url=,11040,4844-188675-205897-133277-0-file,00.pdf |title=World Junior Figure Skating Championships: Ladies' results |work=International Skating Union |format=PDFlink |archive-format=PDFlink |deadurl=yes |archiveurl=,11040,4844-188675-205897-133277-0-file,00.pdf |archivedate=2013-12-24}}
"World Junior Figure Skating Championships: Ladies' results" (PDFlink). International Skating Union. Archived from the original (PDFlink) on 2013-12-24. 
Trappist the monk (talk) 03:57, 1 January 2017 (UTC)
Seems to me like archive-format should take the format value if the archive-format value is unset (or is set as detecting a PDF). --Izno (talk) 19:45, 12 January 2017 (UTC)[edit] is a rarely used alias to the Wayback machine. It is usually used erroneously for example, notice there is no YYYYMMDD in the URL.

This should render with an error but does not:

  • {{cite web |url= |archiveurl= |archivedate=June 3, 2016 |title=Yahoo! | |author= |date=May 3, 2016 |accessdate=January 5, 2017}}
  • "Yahoo!". May 3, 2016. Archived from the original on June 3, 2016. Retrieved January 5, 2017. 

This correctly renders with an error:

  • {{cite web |url= |archiveurl= |archivedate=June 3, 2016 |title=Yahoo! | |author= |date=May 3, 2016 |accessdate=January 5, 2017}}
  • "Yahoo!". May 3, 2016. Retrieved January 5, 2017.  |archive-url= is malformed: timestamp (help)

I'm working on a script to find and add snapshot dates in the wikitext (based on existing archivedate data), but a rendered error for liveweb would help. Thanks.

-- GreenC 15:34, 5 January 2017 (UTC)

Is a fix to cs1|2 necessary? This external link search would seem to indicate that there are relatively few instances of the url; most appear to be in user and talk namespaces.
Trappist the monk (talk) 15:45, 5 January 2017 (UTC)
Because I ran an AWB regex to convert them yesterday (sans talk pages). In over 530 article pages. Without the error message there is nothing to prevent (or discourage) editors from continuing to add them. is a deprecated method that once worked without the need for a date in the URL (it actually still works but you can't lock-in which date it will end up at perhaps different from the intended archivedate). So editors who are accustomed to that format (without using a timestamp) will continue doing so without a warming message. -- GreenC 18:54, 5 January 2017 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Ok:

Cite web compare
{{ cite web | archiveurl= | date=May 3, 2016 | author= | title=Yahoo! | url= | | archivedate=June 3, 2016 | accessdate=January 5, 2017 }}
Live "Yahoo!". May 3, 2016. Archived from the original on June 3, 2016. Retrieved January 5, 2017. 
Sandbox "Yahoo!". May 3, 2016. Retrieved January 5, 2017.  |archive-url= is malformed: liveweb (help)

Trappist the monk (talk) 19:44, 5 January 2017 (UTC)

Thanks. Looks good to me. Though would it say "malformed: timestamp" since that's really the issue, the missing timestamp. is an alias to so nothing inherently wrong with the hostname so long as it has a timestamp. -- GreenC 19:51, 5 January 2017 (UTC)
But you wrote: is a deprecated method .... If it's deprecated, we should not support it.
Trappist the monk (talk) 20:23, 5 January 2017 (UTC)
I did some research and liveweb is the name of a component of the Wayback Machine software stack. The Wayback archive shows activity only from 2011-2012. So I believe the liveweb hostname was a public-facing alias during that period, and is now a "hidden" alias (unadvertised) .. during that period it's possible they were advertising a method of linking that used the liveweb hostname but didn't include a timestamp (I'm guessing to explain why so many were added to Wikipedia that way). So the important difference is a timestamp be included - there may be other old hostnames lurking, others include wayback, www, www.web and web. -- GreenC 23:03, 5 January 2017 (UTC)

Lay summary in Cite journal[edit]

There are a number of articles with references that have "Check |laysummary= value" caused by editors adding a title with the url, for example Cardiopulmonary resuscitation (ref 84). Removing the title gets rid of the error message, but doing so removes what appears to be useful information. Is there a way to show the title without it creating this message? if not I like to propose the creation of a parameter "laytitle" or "lay-title" which could be used to prevent these Check value messages and still enable a title to be displayed EdwardUK (talk) 18:02, 6 January 2017 (UTC)

The error message is correct. |lay-summary= is a url-holding parameter that should have nothing but a url as an assigned value. The parameter's name is confusing so I believe that it should be deprecated in favor of |lay-url=. Title text applied to |lay-url= is the static text 'Lay summary'. I can be persuaded that |lay-title= should be adopted such that when set, the assigned value modifies the static text and the link from |lay-url= is applied to the title-text from |lay-title= but not to the static text:
|lay-title=Heart has enough oxygen to survive hypothermia, CPR crucial |lay-url= |lay-source=EurekAlert! |lay-date=18 July 2006
Lay summary: "Heart has enough oxygen to survive hypothermia, CPR crucial"EurekAlert! (18 July 2006)
Trappist the monk (talk) 12:31, 7 January 2017 (UTC)
That matches my thoughts exactly. I’m not quite sure how to test this (the template is far more complicated than any I worked on before), but as an addition to the template I can’t see why it would cause any problems when implemented, so I have added a proposal at the village pump here: Addition of “lay-title” to Cite journal
EdwardUK (talk) 19:16, 10 January 2017 (UTC)

How can the cite AV Media template be used from Wikiversity[edit]

I would like to use the cite AV media template from Wikiversity. When I attempt this it appears in Red, indicating it is unknown. How can the cite AV Media template be used from Wikiversity? Thanks! --Lbeaumont (talk) 15:19, 8 January 2017 (UTC)

Wikiversity uses an old version of en.wikipedia's {{citation/core}} for some cs1|2 templates and an old version of en.wikipedia's Module:Citation/CS1 for others. That then gives you some options:
  1. copy en.wikipedia's Template:Cite AV media/old to v:Template:Cite AV media – probably simplest
  2. create v:Template:Cite AV media based on v:Template:Cite web – may or may not work
  3. upgrade all cs1|2 templates to use a copy of the current version of en.wikipedia's Module:Citation/CS1 – most difficult
For all of the above, documentation will need to be created from scratch.
Trappist the monk (talk) 16:06, 8 January 2017 (UTC)

Stop linking trans-title[edit]

This overlinking is unhelpful to anyone and looks awful, hard for a typical reader to distinguish from some kind of coding error:

 — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  09:03, 12 January 2017 (UTC)

Err, this is a "coding error": the template doc makes it clear that the foreign title goes in |title= and the English one in |trans-title=. So I'm not clear what point you're trying to make? --NSH002 (talk) 09:38, 12 January 2017 (UTC)
The specific of the above citation is an error on his part with respect to parameter use, but his concern (that the link is much too long because it includes the translated title) is not a coding error. He wants the title, and only the title, to be linked, rather than including the translated title. --Izno (talk) 12:38, 12 January 2017 (UTC)
Ah, a matter of taste, I suppose. I don't think it hurts, but YMMV. --NSH002 (talk) 13:51, 12 January 2017 (UTC)
I personally would also prefer to reduce the size of this link either internal or external, so I've made the change in the sandbox module. Below is the comparison (with corrected parameters). I am happy to be reverted if someone should disagree with this change.
Cite book compare
{{ cite book | last=Cohen | isbn=978-953-6108-44-2 | first=Philip J. | year=1997 | publisher=Ceres | title=Drugi svjetski rat i suvremeni četnici : Njihov povijesno-politički kontinuitet i posljedice po stabilnost na Balkanu | url= | location=Zagreb | language=English, Croatian | trans-title=The World War II and contemporary Chetniks: Their historico-political continuity and implications for stability in the Balkans }}
Live Cohen, Philip J. (1997). Drugi svjetski rat i suvremeni četnici : Njihov povijesno-politički kontinuitet i posljedice po stabilnost na Balkanu [The World War II and contemporary Chetniks: Their historico-political continuity and implications for stability in the Balkans] (in English and Croatian). Zagreb: Ceres. ISBN 978-953-6108-44-2. 
Sandbox Cohen, Philip J. (1997). Drugi svjetski rat i suvremeni četnici : Njihov povijesno-politički kontinuitet i posljedice po stabilnost na Balkanu [The World War II and contemporary Chetniks: Their historico-political continuity and implications for stability in the Balkans] (in English and Croatian). Zagreb: Ceres. ISBN 978-953-6108-44-2. 
--Izno (talk) 19:17, 12 January 2017 (UTC)
Meh. I guess I don't see this as a clear case of 'overlinking' in the sense that is defined in WP:OVERLINKING. Actually, the arguments presented here seem to amount to nothing more than "I don't like links longer than a few words." Not much of an argument in my opinion.
Trappist the monk (talk) 00:32, 13 January 2017 (UTC)
It's not overlinking as such, but the large expanse of blue does make the title harder to read, so I prefer Izno's version with the linking restricted to the value of |title=. (But in this particular case I wouldn't have used |url=, since the ISBN link leads to the same place.) Kanguole 00:58, 13 January 2017 (UTC)

I would say it's not WP:OLINK from a words-not-sense point of view because these are elinks and not internal links. However, the purpose of OLINK is indeed to reduce (or remove) some "sea of blue". I would venture that what is often 10+ words all linked (to the same location or otherwise), where TransTitle is used, in a row, meets that definition. Additionally, this makes this a bit more consistent when the name of the work (outside of cite web) is internally linked. In the case of cite web: I have a handful of citations in Call to Arms (video game) where, if I linked the works cited to those web pages with translated titles, I would experience a similar "ugh, lots of blue".

But, perhaps there is a better question: how is a citation served/improved by having a translated title? --Izno (talk) 12:49, 13 January 2017 (UTC)

Please close your <p>...</p> tags; not doing so buggers up the context highlighting (and isn't valid html).
Fine question, that. If the purpose of a citation is to assist the reader in locating the source, then the source's actual title is necessary. A translated title isn't really helpful unless the source is one of those that is constructed so that it reads in one language from one end, but when flipped over reads in another language and even then, editors should use the title of the 'sub-source' that they consulted. But, I think that this particular sub-topic is perhaps best discussed (it may already have) at WP:CITE because it isn't specific to cs1|2.
Trappist the monk (talk) 13:25, 13 January 2017 (UTC)

Huh. I thought it was valid HTML 5 but I see that I was wrong (though there is plenty of exception in the specification regarding closing <p> tags.[1] Your script/gadget should process paragraph elements without closing tags with that much exception.

Indeed, and I might send it that direction. --Izno (talk) 14:12, 13 January 2017 (UTC)

Section field for cite book[edit]

I had actually entered a "PART II" division under "section" before realizing...

|chapter=, |contribution=, |entry=, |article=, |section=

All equivalent.

Can we have a field for sections? For example

yet contents says:

  • PART II 77
  • PART III 207
  • PART IV 321

So clearly chapter 9 and 10 are both part of section II. Both are useful things to be able to cite, 'part' and 'chapter'. Ranze (talk) 22:24, 12 January 2017 (UTC)

The reason they're all equivalent is that they're used to cite separately authored parts of a book, like the chapter "Sportacus Saves the Day!" by Dagny Kristjansdottir, pp. 135–155. That (and the book info) is the vital information; the fact that it's chapter 9, or that it's in Part II: Filmic Translations, isn't normally considered worth putting in a citation. Kanguole 12:12, 13 January 2017 (UTC) single letter domain names CS1 error (copied from the Help Desk)[edit]

(Copied from the Help Desk.)

Hello, I am trying to fix a "Check |url= value (help)" error in zcash for this URL: It seems like the validation code is incorrectly flagging single-letter domain names like this. How can I report this bug to the maintainer? – JonathanCross (talk) 13:44, 18 January 2017 (UTC)

I've verified that is a valid website, any ideas? Naraht (talk) 14:25, 19 January 2017 (UTC)

I took a look at the validation rules. Someone put a lot of energy into trying to to account for specific single letter domains, quirks of TLDs, etc. Much of this is no longer applicable given the vast expansion of Generic TLDs and will continue to cause issues as these domains are more widely used in the future. Can we remove some of the restrictions to make the validation less brittle? – JonathanCross (talk) 15:01, 19 January 2017 (UTC)