Help talk:Citation Style 1

(Redirected from Template talk:Cite conference)
the Wikipedia Help Project (Rated B-class, High-importance)
This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the help menu or help directory. Or ask for help on your talk page and a volunteer will visit you there.
B  This page does not require a rating on the project's quality scale.
High  This page has been rated as High-importance on the project's importance scale.

cite map

In April 2014 Editor Imzadi1979 started a conversation with me on my talk page and another at WikiProject U.S. Roads regarding the migration of {{cite map}} to Module:Citation/CS1. Perhaps the time has come to consider what needs doing to make the migration.

There is some support for {{cite map}} that was done before my time:

|map= and |mapurl= were added to the {{citation/core}} version as aliases of |chapter= after what support there is was added to Module:Citation/CS1.

Clearly WikiProject U.S. Roads should be notified of this discussion; who else?

Trappist the monk (talk) 19:46, 22 February 2015 (UTC)

 {{ cite map | map=Michigan | section=B13 | isbn=0-528-00626-6 | scale=1 in=30 mi | inset=Western Upper Peninsula | year=2013 | cartography=Rand McNally | publisher=Rand McNally | title=The Road Atlas | author1=Rand McNally | location=Chicago | pages=50–51 | edition=2013 Walmart }} Live Rand McNally (2013). "Michigan" (Map). The Road Atlas (2013 Walmart ed.). 1 in=30 mi. Cartography by Rand McNally. Chicago: Rand McNally. pp. 50–51. Western Upper Peninsula inset. § B13. ISBN 0-528-00626-6. Sandbox Rand McNally (2013). "Michigan" (Map). The Road Atlas (2013 Walmart ed.). 1 in=30 mi. Cartography by Rand McNally. Chicago: Rand McNally. pp. 50–51. Western Upper Peninsula inset. § B13. ISBN 0-528-00626-6.
 {{ cite map | date=July 1, 1930 | author=Michigan State Highway Department | scale=Scale not given | publisher=Michigan State Highway Department | title=Official Highway Service Map | section=C3–C4 | location=Lansing, MI | inset=Detroit Area | cartography=H.M. Gousha }} Live Michigan State Highway Department (July 1, 1930). Official Highway Service Map (Map). Scale not given. Cartography by H.M. Gousha. Lansing, MI: Michigan State Highway Department. Detroit Area inset. § C3–C4. Sandbox Michigan State Highway Department (July 1, 1930). Official Highway Service Map (Map). Scale not given. Cartography by H.M. Gousha. Lansing, MI: Michigan State Highway Department. Detroit Area inset. § C3–C4.

1. For many (most?) maps, the publisher is the important detail on the same level as the author of a book. When the template was originally created, and before it was more fully moved into the CS1 scheme, that assumption meant that the publisher was listed first. I think that going forward, the template should discard that assumption and allow the full range of |authorn=, |firstn= |lastn= and |authorn-link= parameters, and the publisher should be shifted back into the order. If editors wish to list the publisher up front, they'll update articles to duplicate it in the appropriate author parameter. I would not repurpose |cartography= as an author.
2. The |via= parameter needs to be added, which I assume would be something that module support would accommodate. As it is, we can't indicate that the map being linked is hosted by a different entity than its publisher.
3. It would be better if the "(Map)." indicator "floated" a bit. In the example above, it follows the name of the journal (Colorado Highways) or the book (The Road Atlas) in which the map was published. That journal isn't the map, but rather the quoted title in the live output is, so the indicator should move to follow the quoted title in that case. In the case of sheet maps, the indicator should remain behind the italicized map |title= because there won't be a |map= defined.
1. It would also be nice in some circumstances to allow an editor to override the default, say to explicitly note that if something were a "Topographic map" or an "Aerial survey".
4. The edition should follow the italicized title and not have the scale and cartography information come between the two.
5. Where the page(s), inset, and section(s) are noted, they should be displayed in that order, which ranks them in size order. Also, we should consider adding |sections= to provide the plural form of the label. I would suggest we consider using the section mark (§) as a label, with the plural (§§) as well.
6. Something I suggested elsewhere would simplify a situation here. Maps can be published in a journal or in a book or atlas. As such, we have a need to use either the "V (I): p" format of a journal or the "p./pp. #" format of a book citation. I'd personally like to see us insert the "p." or the "pp." in front of a page number or range anytime that a volume or volume and issue aren't defined. If we did that, then the map template could assume it was within a journal because the lack of a volume or issue would prompt the "p." or "pp." to appear. In any case, the in-source location should be ordered: volume, issue, page(s), inset, section(s).

Imzadi 1979  04:32, 23 February 2015 (UTC)

I've added |map=, |map-url=, and |mapurl= as pseudo-aliases of |chapter=.
Item 2, |via= already available in the module.
Item 3.1, use |type=; this has always been available (see the first comparison above where |type=Road map).
In the module, after a bit of processing we come to a place where all of these meta parameters are concatenated into a single string separated by the separator character (period for CS1 or comma for CS2). There is one version for 'book-like' citations and another for 'journal-like' citations:
Title
TitleNote – this is |department=; not needed for {{cite map}}?
Conference – not needed for {{cite map}}?
Periodical
Format
TitleType
Scale
Series
Language
Volume
Issue
Others – not needed for {{cite map}}?
Cartography
Edition
Publisher
Agency – not needed for {{cite map}}?
This list of things seems sort of odd to me. For example, Chapter isn't listed here. It is lumped together with Authors, Date, Chapter, Place, Editors but Others is in this group. One would think that contributors would all be in the same group and title components would be in another group.
Ignoring the author/editor/date/chapter-as-map-alias group and the in-source location group (page, inset, section) for the time being, let us confine ourselves to the 'Title' list only for the time being. What is the preferred order of these parameters? If different orders make sense for different citations (sheet map, journal, atlas, book, other), then make multiple lists. It is not necessary to include all of the items in the list; you might even add new items if it makes sense to do so.
Trappist the monk (talk) 14:52, 23 February 2015 (UTC)
Ok, I'm a bit confused by what you asked at the end, but I'll go with what I think you're asking. In terms of output, CS1 is heavily based on the APA style, but the APA manual isn't terribly helpful with the lone example it gives. My general thoughts are to emulate what this page from NCSU Libraries suggests for APA style and pair it with how {{cite book}} handles the order of things.
There are only a few things that are map-specific: the scale of the map, the name of the cartography source, then the inset or map section as part of the in-source location. So basically, if we followed the order from a book citation, we'd be 90% there. The scale, as NCSU says, would come immediately before the series. I would then include the cartography information, if supplied, next before any |others= output. (I would imagine that other contributions would be rare, but why omit the possibility?) As for |agency=, I could foresee noting that a map out of a newspaper came through the Associated Press if someone were so incline to specifically cite just a map from a newspaper article. Looking at a book citation:
• Author (2015). Title. Book Series. Other contribution by someone else. Place: publisher.
So basically that if we used that same order, but put the map scale in between the title and the series, and a cartographer precedes any other "others". Wrap it up with the in-source location (volume/issue/page/inset/section), the various identifiers (ISBN/OCLC/etc) as well as the |access-date= |via= and archive-related information.
I guess in other words, a good map citation should look like a good book citation, but the default (or customized) type should float depending on if we are citing a |map= in a |title= or just a |title= alone. Using cite book as a mock up:
• Rand McNally (2013). "Michigan". The Road Atlas (Map). 1 in=30 mi. Cartography by Rand McNally (2013 Walmart ed.). Chicago: Rand McNally. pp. 50–51, Western Upper Peninsula inset, § B13. ISBN 0-528-00626-6.
• Michigan State Highway Department (July 1, 1930). Official Highway Service Map (Map). Scale not given. Cartography by H.M. Gousha. Lansing, MI: Michigan State Highway Department. Detroit Area inset, §§ C3–C4.
• U.S. Geological Survey (1999) [Photorevised 1993]. Raleigh West quadrangle, North Carolina (Map). 1:24,000. 7.5 Minute Series. Cartography by USGS. Reston, VA: U.S. Geological Survey.
I'd only make two changes: in the atlas example, the "(Map)." should go after the map title because The Road Atlas isn't a map, but a book while "Michigan" the title of the map, and the edition should really follow the title (which it should for books anyway) because it's modifying the title and not the series or contributions of other people. The latter though is a criticism I'd have of the {{cite book}} in general though. This sets aside the other issue of how to deal with maps in journals for the volume/issue/page vs. just page in a book. Imzadi 1979  16:47, 23 February 2015 (UTC)
What I wanted was a list of the meta parameters in order. I have tweaked the code and created three lists that look like this:
For maps in a book:
TitleType, Title, Format, Scale, Cartography, Others, Edition, Publisher, Series, Language, Volume
For maps in a periodical:
TitleType, Title, Format, Scale, Cartography, Others, Publisher, Series, Language, Volume, Issue
For sheet maps:
Title, TitleType, Format, Scale, Cartography, Others, Edition, Publisher, Series, Language
You can see the effect of this change in the comparisons above (ignore punctuation, spacing, and other weirdnesses; we'll fix those later).
Trappist the monk (talk) 17:46, 23 February 2015 (UTC)
 {{ cite map | date=1999 | scale=1:24,000 | publisher=U.S. Geological Survey | series=7.5 Minute Series | cartography=USGS | title=Raleigh West quadrangle, North Carolina | author1=U.S. Geological Survey | location=Reston, VA | language=fr | orig-year=Photorevised 1993 }} Live U.S. Geological Survey (1999) [Photorevised 1993]. Raleigh West quadrangle, North Carolina (Map). 1:24,000. 7.5 Minute Series (in French). Cartography by USGS. Reston, VA: U.S. Geological Survey. Sandbox U.S. Geological Survey (1999) [Photorevised 1993]. Raleigh West quadrangle, North Carolina (Map). 1:24,000. 7.5 Minute Series (in French). Cartography by USGS. Reston, VA: U.S. Geological Survey.
Ignoring the spacing and punctuation weirdness, that's pretty much looking good to me so far for maps , except that Series should be appear between Scale and Cartography. (In a book, the Series appears after the Title and before Others.) I'm neutral over where Language appears. Imzadi 1979  19:43, 23 February 2015 (UTC)

Comment: I have posted a link to this discussion on the Talk pages of half a dozen WikiProjects that appear to be active and (in my judgement, based on the articles transcluding this template) may have an interest in the use and formatting of this template. We have had objections in the past about decisions made by one of two editors, and I'd like to avoid those objections in the case of this template, which is used in 18,000 articles. – Jonesey95 (talk) 22:16, 23 February 2015 (UTC)

Tweaks that I think get the spacing and punctuation right, add |sections=, use § and §§ for sections:

• "New Map Showing the 8,880 Miles Which Comprise Colorado's Primary Highway System" (Road map). Colorado Highways. Scale not given. Cartography by CSHD. Colorado State Highway Department 2. July 1923. pp. 12–13. OCLC 11880590. Retrieved November 18, 2013 – via Google Books.
• Rand McNally (2013). "Michigan" (Map). The Road Atlas (2013 Walmart ed.). 1 in=30 mi. Cartography by Rand McNally. Chicago: Rand McNally. pp. 50–51. Western Upper Peninsula inset. § B13. ISBN 0-528-00626-6.
• Official Highway Service Map (Map). Scale not given. Cartography by H.M. Gousha. Lansing, MI: Michigan State Highway Department. July 1, 1930. Detroit Area inset. §§ C3–C4.
• U.S. Geological Survey (1999) [Photorevised 1993]. Raleigh West quadrangle, North Carolina (Map). 1:24,000. 7.5 Minute Series (in French). Cartography by USGS. Reston, VA: U.S. Geological Survey.

Trappist the monk (talk) 16:43, 24 February 2015 (UTC)

Looks good to me so far, and I think that we have just a few things left to sort out.
1. Figuring out the formatting with volume/issue/page in periodicals vs. volume/page in books. I know you know about it, but I'm just listing it here to keep this complete.
2. Are we putting in support for |agency= and |others=? I realized a case where the latter may be employed: noting a translator.
3. We'll need a |map-format= as the companion to |format= to note when maps online are in PDF or MrSID files. (The latter definitely requires special software to use.)
4. I'm thinking that the |language= should remain following the series as it is in book citations. It looks somewhat odd following the publisher.
Let's just say that so far I'm quite pleased with the rapid progress into making this work, and I think that we'll be well on our way to implementation if other editors don't object. From me, I appreciate your work, Trappist the monk. Imzadi 1979  17:22, 24 February 2015 (UTC)
1. Volume/issue/page is a separate topic I think because its resolution would apply to all CS1/CS2 templates.
2. |others= is supported and follows |cartography=. If we are to support |agency= it should only apply to the periodical version of {{cite map}}.
3. Added |map-format=
4. moved |langage= to follow |series=.
Do you have any 'periodical' style map citations? (magazine, journals, etc) There don't appear to be any on the test cases page.
Trappist the monk (talk) 12:32, 25 February 2015 (UTC)
The first example you used is a map printed in the journal Colorado Highways. So far it's the only one I've run into that I needed to cite properly with volume/issue/pages, but that doesn't mean that other editors won't run into them. It should have "2 (7): 12–13" as its page reference (to match what {{cite journal}} would do), which would then be followed by an inset, if appropriate (there aren't insets on that particular map), and sections (it lacks a grid marking off sections), also if appropriate. Imzadi 1979  14:22, 25 February 2015 (UTC)
That first cite is written as a chapter/book-style citation:
{{cite map/new |type=Road map |publisher=Colorado State Highway Department |date=July 1923 |map=New Map Showing the 8,880 Miles Which Comprise Colorado's Primary Highway System |map-url=http://books.google.com/books?id=czs5AQAAMAAJ&pg=RA10-PA12 |title=Colorado Highways |scale= Scale not given |cartography=CSHD |volume=2 |issue=7 |pages=12–13 |oclc=11880590 |accessdate= November 18, 2013 |via= Google Books}}
"New Map Showing the 8,880 Miles Which Comprise Colorado's Primary Highway System" (Road map). Colorado Highways. Scale not given. Cartography by CSHD. Colorado State Highway Department 2. July 1923. pp. 12–13. OCLC 11880590. Retrieved November 18, 2013 – via Google Books.
Rewriting it as a periodical-style cite (change |title= to |journal= and |map= to |title=):
{{cite map/new |type=Road map |publisher=Colorado State Highway Department |date=July 1923 |title=New Map Showing the 8,880 Miles Which Comprise Colorado's Primary Highway System |url=http://books.google.com/books?id=czs5AQAAMAAJ&pg=RA10-PA12 |journal=Colorado Highways |scale= Scale not given |cartography=CSHD |volume=2 |issue=7 |pages=12–13 |oclc=11880590 |accessdate= November 18, 2013 |via= Google Books}}
"New Map Showing the 8,880 Miles Which Comprise Colorado's Primary Highway System" (Road map). Colorado Highways. Scale not given. Cartography by CSHD (Colorado State Highway Department) 2 (7). July 1923: 12–13. OCLC 11880590. Retrieved November 18, 2013 – via Google Books.
and there you get the {{cite journal}}-like volume/issue/page style.
We really shouldn't need to 'remap' |map= et al. to achieve this effect. I'll think on that.
Trappist the monk (talk) 14:49, 25 February 2015 (UTC)
A ha. Hmm, I guess then that I'd support the use of |journal= over |title= to invoke the journal-style page display and leave |map= as is. The question then should be, do we need a |atlas= or |book-title= as an alias for dealing with maps in books, just to minimize possible confusion? Then an editor could specify map/journal or map/atlas.
Also, I noticed that if an author isn't specified through the normal means, then {{cite map/new}} is still shifting the publisher forward, but if |location= is specified, it's "hanging out" in the middle of the citation without something to follow it. I know Scott5114 below has objected, but we really need to either have the template copy |publisher= into both places (and retain |publisher-link= to link the version displayed as the author), or we need to break this behavior and force editors to manually specify the author(s), even if that means manually duplicating the publisher to keep the desired effect. Imzadi 1979  15:52, 25 February 2015 (UTC)
One thing at a time please.
Changing how we use the various parameters in extant cites doesn't seem like the best of ideas. I would guess that most {{cite map}} use |title= to refer to the title of the map. We introduce |map= and its companion parameters for the case where |title= is used for the atlas or book title. In {{cite journal}} we use |title= to name the article and |periodical= (or an alias) to name the periodical (journal, magazine, or what have you). If the goal is to make {{cite map}} act like {{cite journal}} when the map is in a periodical, then we should use |title= and |periodical=.
Trappist the monk (talk) 13:28, 26 February 2015 (UTC)

I have moved |edition= in the cases where the citation is for a map in a book and a stand-alone map (|edition= doesn't apply to periodicals):

 {{ cite map | map=Michigan | section=B13 | isbn=0-528-00626-6 | scale=1 in=30 mi | inset=Western Upper Peninsula | year=2013 | cartography=Rand McNally | publisher=Rand McNally | title=The Road Atlas | author1=Rand McNally | location=Chicago | pages=50–51 | edition=2013 Walmart }} Live Rand McNally (2013). "Michigan" (Map). The Road Atlas (2013 Walmart ed.). 1 in=30 mi. Cartography by Rand McNally. Chicago: Rand McNally. pp. 50–51. Western Upper Peninsula inset. § B13. ISBN 0-528-00626-6. Sandbox Rand McNally (2013). "Michigan" (Map). The Road Atlas (2013 Walmart ed.). 1 in=30 mi. Cartography by Rand McNally. Chicago: Rand McNally. pp. 50–51. Western Upper Peninsula inset. § B13. ISBN 0-528-00626-6.

This, I think answers items 1–5 in Editor Imzadi1979's list of things to change.

Trappist the monk (talk) 13:53, 1 March 2015 (UTC)

I have to strongly oppose any change to this template that would move the publisher information away from the beginning of the citation. This is usually the only way of identifying a particular map, since most of them are just titled after the geographic area they cover. ("Map of Oklahoma". Which map of Oklahoma? The Esso map.) Burying this key information in the middle of the citation for no good reason decreases the utility of the template's output. (Consistency with other templates is not a good reason in this case—maps are different than other sources and should be treated as such.)

It should be noted that the reason the cartography field exists at all is because sometimes a map is published under the branding of one company but the actual map is contracted out to another. This is most frequently encountered with U.S. gas station maps of the 20th century, which were essentially Rand McNally or H.M. Gousha maps bearing the branding of Texaco, Esso, Standard Oil, etc. Seldom are the actual people that did the cartography credited publicly, so that is not the use case the template was intending to address. —Scott5114 [EXACT CHANGE ONLY] 21:11, 24 February 2015 (UTC)

And by citing "Esso" as the author in addition to the publisher with Rand McNally or H.M. Gousha as the cartographer, you've just negated that issue. The |cartography= field has not been removed in the sandboxed version. Imzadi 1979  22:53, 24 February 2015 (UTC)
if you look at the test cases page, the publisher=author automation hasn't been removed yet, so unless we also specify |author=Rand McNally in case #8, we get "Chicago" just floating along in the middle of the citation output when it really should be joined as "Chicago: Rand McNally" to make more sense. Currently specifying any author parameters (last/first or author, with or without author-link) breaks this assumption that the publisher is the author and shifts the publisher value to the appropriate location. We either have two options to get the publisher displayed in the appropriate location with the place of publication:
1. Permanently remove the assumption and require editors to do the more correct action by specifying an author, which in your editing would mean the publisher is manually duplicated to appear in both parameters in almost all cases, or
2. We reinstate a briefly used bit of coding that automatically moves the publisher to the author field as now, and then also displays it in the appropriate location in the middle of the citation.
The latter option is messy when the publisher is linked. Trappist would know better if cite map is creating messy metadata at the moment, but I suspect that we are creating screwed up metadata. Imzadi 1979  14:22, 25 February 2015 (UTC)

Are we done? Have we done all that needs doing to migrate {{cite map}} to Module:Citation/CS1?

Trappist the monk (talk) 14:05, 5 March 2015 (UTC)

Everything looks good by me. Just let me know when we have some time table for implementing so I know when I should start updating some articles and other templates. Imzadi 1979  19:32, 5 March 2015 (UTC)
Probably on or before the Ides of March.
Trappist the monk (talk) 19:55, 5 March 2015 (UTC)

Categories in the existing template

Please note that there are two maintenance categories in the existing template that may need to be considered in this migration: Category:Pages using cite map with both series and version and Category:Pages using cite map with publisher-link. – Jonesey95 (talk) 07:14, 27 February 2015 (UTC)

There are six pages listed at Category:Pages using cite map with both series and version that have citations that look a lot like this:
 {{ cite map | scale=1:10,560 | url=http://www.british-history.ac.uk/mapsheet.aspx?compid=55127&sheetid=5029&ox=0&oy=0&zm=1&czm=10&x=259&y=123 | publisher=Ordnance Survey | title=England - Lincolnshire | date=1891 | version=Epoch 1 | series=County series | sheet=115/NE }} Live England - Lincolnshire (Map). 1:10,560. County series. Ordnance Survey. 1891. Sheet 115/NE. More than one of |version= and |series= specified (help) Sandbox England - Lincolnshire (Map). 1:10,560. County series. Ordnance Survey. 1891. Sheet 115/NE. More than one of |version= and |series= specified (help)
It seems to me that, at least for these six, |series= and |version= could be combined into |series=County series Epoch 1. It isn't clear to me if Epoch 1 is something that Ordnance Survey used in naming the map series or if that is something applied by British History. See here. |sheet= isn't a supported parameter in either the old or the new template.
The other article-space page has this:
 {{ cite map | archiveurl= | isbn=9780319238332 | scale=1:25 000 | trans_title= | cartography= | section=Bottesford & Colsterworth | url= | pages= | edition= | archivedate= | ref= | format= | id= | language= | page=247 | title=Grantham | inset= | publisher=OSGB | year= | version=A1 | location= | series=Explorer | date=03/04/2006 | accessdate= }} Live Grantham (Map). 1:25 000. Explorer. OSGB. 03/04/2006. p. 247. § Bottesford & Colsterworth. ISBN 9780319238332. More than one of |version= and |series= specified (help); Check date values in: |date= (help) Sandbox Grantham (Map). 1:25 000. Explorer. OSGB. 03/04/2006. p. 247. § Bottesford & Colsterworth. ISBN 9780319238332. More than one of |version= and |series= specified (help); Check date values in: |date= (help)
which appears to me to be a malformed citation. Follow the ISBN link to Amazon to look at the map.
There is a note at the top of Category:Pages using cite map with publisher-link that says "This parameter is in the process of being removed." If that is true, then an AWB script should be able to make pretty quick work of clearing the category.
Trappist the monk (talk) 14:04, 27 February 2015 (UTC)
Based on the example citations, it looks like citations in the "both series and version" category would end up in the CS1 redundant parameter category, and citations with |publisher-link= would end up in the "unsupported parameter" category.
 {{ cite map | publisher-link=Iowa Department of Transportation | publisher=Iowa Department of Transportation | title=Iowa Highway Map | scale=1:10,000 | date=1974 }} Live Iowa Highway Map (Map). 1:10,000. Iowa Department of Transportation. 1974. Unknown parameter |publisher-link= ignored (help) Sandbox Iowa Highway Map (Map). 1:10,000. Iowa Department of Transportation. 1974. Unknown parameter |publisher-link= ignored (help)

As long as we track them somehow with the new code (which it looks like we do), I'm satisfied.
An AWB script may not suffice to clear up publisher-link parameters. I have found a few of them in template code. I'll poke through that category. – Jonesey95 (talk) 15:49, 27 February 2015 (UTC)
The |version= might be analogous to a different |edition= of the map. It's something worth investigating slightly, and that might be the first to make it "(Epoch 1 ed.)." in the display of the citation. Imzadi 1979  17:00, 27 February 2015 (UTC)
the |publisher-link= parameter was put in use to deal with the author/publisher situation. If there is no author defined in any of the usual ways (|author= |first= |last=, etc) then the value of |publisher= is moved into the authorship position. However, for a brief period of time, the |publisher= was merely copied, and the value was also displayed in the traditional publisher location in the middle of the citation, following a |location=. In that brief period of time, |publisher-link= was added to serve as the analog of |author-link= so that one could link the name of the "publisher as author" without also linking the "publisher as publisher" output. Otherwise we'd have forced editors to insert the brackets to wikilink the publisher name, and it would be linked in both locations.
So, moving forward, we're going to have 3 basic options:
1. Status quo: publisher is shifted automatically, and if the |location= is defined, it appears alone in the middle, disconnected from the publisher unless an editor also defines |author=.
2. Restore the once-used version of the automation where the publisher appeared in both locations ("as author", "as publisher"), and un-deprecate |publisher-link= so that the "as author" portion of the citation can be linked without also linking the "as publisher" location.
3. Remove the coding that moves the publisher forward and require editors to specify an author (which doesn't have to be the |cartography= name) if they want some name to appear ahead of the map title.
Imzadi 1979  16:16, 27 February 2015 (UTC)
As another alternative, discard |publisher-link= as unneeded and simply wikilink |publisher=[[<value]] just as we would do in all other CS1 templates. When |author= is not set, the code still copies the value from |publisher= to |author=. If |location= is set then strip wikilink markup from |publisher=; if |location= not set then delete |publisher=. These examples illustrate:
2. wikilinked publisher and location (Map). Location: Publisher.
3. publisher (Map). Publisher.
4. publisher and location (Map). Location: Publisher.
5. Author. author, wikilinked publisher (Map). Publisher.
6. Author. author, wikilinked publisher, and location (Map). Location: Publisher.
Trappist the monk (talk) 17:24, 27 February 2015 (UTC)
The code that did this has been disabled at this edit
Trappist the monk (talk) 00:29, 1 March 2015 (UTC)
AWB is equally at home in Template space as in main space. There is, apparently some dispute about what to do with |publisher-link=. See the second paragraph of Editor Imzadi1979's 2015-02-25T15:52UTC post above. It would seem that if there is no |location= then |publisher= becomes |author= and |publisher-link= becomes |author-link= and Bob's your uncle. Not quite so simple if |location= is set; and this is where some thinking is probably still required.
Trappist the monk (talk) 16:10, 27 February 2015 (UTC)

Publisher vs. Author issue

Compare the following examples, all citing the same map in the same atlas used as a source in the M-553 (Michigan highway) article:

Publisher, location, but no author:

 {{ cite map | map=Forsyth T45N R25W | via=Historic Map Works | location=Rockford, IL | scale=1.25 in:1 mi | oclc=15326667 | page=17 | cartography=Rockford Map Publishers ''c'' | publisher=Rockford Map Publishers ''p'' | year=1962 | section=2, 3, 10, 11, 14, 15, 22, 23 | mapurl=http://www.historicmapworks.com/Atlas/US/16079/Marquette+County+1962/ | title=Plat Book with Index to Owners, Marquette County, Michigan | accessdate=March 29, 2012 }} Live "Forsyth T45N R25W" (Map). Plat Book with Index to Owners, Marquette County, Michigan. 1.25 in:1 mi. Cartography by Rockford Map Publishers c. Rockford, IL: Rockford Map Publishers p. 1962. p. 17. § 2, 3, 10, 11, 14, 15, 22, 23. OCLC 15326667. Retrieved March 29, 2012 – via Historic Map Works. Sandbox "Forsyth T45N R25W" (Map). Plat Book with Index to Owners, Marquette County, Michigan. 1.25 in:1 mi. Cartography by Rockford Map Publishers c. Rockford, IL: Rockford Map Publishers p. 1962. p. 17. § 2, 3, 10, 11, 14, 15, 22, 23. OCLC 15326667. Retrieved March 29, 2012 – via Historic Map Works.

Publisher, author and location:

 {{ cite map | map=Forsyth T45N R25W | via=Historic Map Works | title=Plat Book with Index to Owners, Marquette County, Michigan | oclc=15326667 | scale=1.25 in:1 mi | author=Rockford Map Publishers ''a'' | page=17 | cartography=Rockford Map Publishers ''c'' | publisher=Rockford Map Publishers ''p'' | year=1962 | section=2, 3, 10, 11, 14, 15, 22, 23 | mapurl=http://www.historicmapworks.com/Atlas/US/16079/Marquette+County+1962/ | location=Rockford, IL | accessdate=March 29, 2012 }} Live Rockford Map Publishers a (1962). "Forsyth T45N R25W" (Map). Plat Book with Index to Owners, Marquette County, Michigan. 1.25 in:1 mi. Cartography by Rockford Map Publishers c. Rockford, IL: Rockford Map Publishers p. p. 17. § 2, 3, 10, 11, 14, 15, 22, 23. OCLC 15326667. Retrieved March 29, 2012 – via Historic Map Works. Sandbox Rockford Map Publishers a (1962). "Forsyth T45N R25W" (Map). Plat Book with Index to Owners, Marquette County, Michigan. 1.25 in:1 mi. Cartography by Rockford Map Publishers c. Rockford, IL: Rockford Map Publishers p. p. 17. § 2, 3, 10, 11, 14, 15, 22, 23. OCLC 15326667. Retrieved March 29, 2012 – via Historic Map Works.

Author, location, but no publisher:

 {{ cite map | map=Forsyth T45N R25W | via=Historic Map Works | title=Plat Book with Index to Owners, Marquette County, Michigan | scale=1.25 in:1 mi | author=Rockford Map Publishers ''a'' | page=17 | oclc=15326667 | cartography=Rockford Map Publishers ''c'' | year=1962 | section=2, 3, 10, 11, 14, 15, 22, 23 | mapurl=http://www.historicmapworks.com/Atlas/US/16079/Marquette+County+1962/ | location=Rockford, IL | accessdate=March 29, 2012 }} Live Rockford Map Publishers a (1962). "Forsyth T45N R25W" (Map). Plat Book with Index to Owners, Marquette County, Michigan. 1.25 in:1 mi. Cartography by Rockford Map Publishers c. Rockford, IL. p. 17. § 2, 3, 10, 11, 14, 15, 22, 23. OCLC 15326667. Retrieved March 29, 2012 – via Historic Map Works. Sandbox Rockford Map Publishers a (1962). "Forsyth T45N R25W" (Map). Plat Book with Index to Owners, Marquette County, Michigan. 1.25 in:1 mi. Cartography by Rockford Map Publishers c. Rockford, IL. p. 17. § 2, 3, 10, 11, 14, 15, 22, 23. OCLC 15326667. Retrieved March 29, 2012 – via Historic Map Works.

In each of the examples, I added an italicized a, c, or p to note when "Rockford Map Publishers" is defined as an |author=, |cartography= source or |publisher=, respectively. Ignore the changes related to where "(Map)." is located, the change from "section" to "§", and the inclusion of the |via= in the following discussion.

In the first comparison, no |author= is defined. The current template, and its sandbox behave identically. The publisher is shifted forward to take the place of an author, and the location appears alone in the middle of the citation. In this case, there is effectively no publisher noted because of that shift.

In the middle comparison, |author= is defined. In this case, the author is displayed up front, and the publisher appears in the middle of the citation after the location, as expected in the sandbox. The live template ignores the value for the publisher, as you can see, because that value is superfluous because we have something else to display up front for an author.

In the last comparison, the live template is ignoring the |author=, and because there isn't a |publisher= to take its place, there is nothing listed in the author location. As a result, the year appears in the middle of the citation after the location. In the sandbox, the template isn't ignoring the |author=, so it appears where we expect, followed by the year. Because there is no |publisher=, the location stands alone, also as expected.

This is the more fundamental question of template output behavior that needs to be resolved before discussing |publisher-link=. Imzadi 1979  16:46, 27 February 2015 (UTC)

I am totally confused. Please, briefly and succinctly, state the fundamental question. My simple little brain is apparently incapable of extracting the fundamental question from what you've just written.
Trappist the monk (talk) 16:41, 28 February 2015 (UTC)
The fundamental question boils down to how the template will deal with this confusion over the proper role of citing an author (or authors) and publisher. Until that is resolved, totally deprecating |publisher-link= may be an effort in futility because the parameter may be needed after all.
The only situation that currently gets it "correct" is the sandbox when the author and the publisher are separately specified. If both are not provided, we are getting results that are visually inconsistent with the rest of the CS1 templates. In the sandbox, if an author (or set of authors) is not provided, the publisher is moved forward, but then we don't have something displayed where the publisher should be displayed.
So either we need to break this crazy "publisher as author" automated behavior and force editors to manually specify the author of a map, which usually is the same entity as the publisher, or we need to re-add the code that duplicates the publisher into both roles unless the author(s) is/are specified to override that behavior. Imzadi 1979  18:58, 28 February 2015 (UTC)
If I understand you, the fundamental question is:
Shall {{cite map}} place the map's publisher in the author position of the rendered citation when |<author alias>= is empty or omitted?
If that is the question, then my answer is no. If it is up to me, special cases in the code, and hence special cases in operation and documentation shall be avoided.
Trappist the monk (talk) 19:52, 28 February 2015 (UTC)
And my answer, for a few years now, has been that the publisher should not be a direct replacement for the author. On that much, we both agree. Furthermore, if editors want to indicate that X company or Y agency both authored and published a map, then they need to list that name twice so that it appears in both places. Imzadi 1979  22:26, 28 February 2015 (UTC)
Ok. I've disabled the code that moves publisher to author when author not present.
Trappist the monk (talk) 00:25, 1 March 2015 (UTC)

Something to note, but these plat atlases were published with written text and advertising solicited from the local 4H program and the appropriate county office/agency, and most library catalogs actually list those two entities as the authors of the book. Rockford Map Publishers just drew the maps using that text and printed the books. As it stands, the role of the 4H program and the county has had to be ignored because the design choices made years ago with the template and carried forward to the initial {{citation/core}} conversion forced us to discount the possibility that there could be separate authorship, cartography and publication of a map source. Imzadi 1979  16:57, 27 February 2015 (UTC)

If multiple authors are to be credited, then in the sandbox version, all of them may be listed as |author=Rockford Map Publishers |author2=Illinois 4H ... In this case, the publisher will not be moved to the author position. Isn't this what you wanted?
Trappist the monk (talk) 16:41, 28 February 2015 (UTC)
Yes, basically, but if an author or authors are not specified, we're not getting an output which also notes who the publisher is, because that spot is left empty when the publisher is moved into the author position. Imzadi 1979  18:58, 28 February 2015 (UTC)
You wanted to list Rockford, 4H, and the county as authors and also list Rockford as publisher. The {{citation/core}} version of {{cite map}} does not support that but the sandbox does. Whether we continue to move publisher data into the author position when there is no author data is irrelevant to this case because when there is author data, publisher data is not moved into the author position.
Trappist the monk (talk) 19:52, 28 February 2015 (UTC)

Geological maps?

I have not been attending to all of the above because I generally cite geological maps, for which {{cite map}} has been wholly unsatisfactory. (I use {{citation}} in a somewhat hacked form.) However, I wonder if there might be some interest in getting citation/cite map into a form (eventually) of making it more satisfactory for use with geological maps, which are generally cited in a more scholarly form. ~ J. Johnson (JJ) (talk) 22:34, 14 March 2015 (UTC)

I'm slightly confused. The changes being made are will make the output follow the general format for the APA citation style for maps, using the same general changes you'd find between CS1/CS2 and APA for things like books, journals and the like.
Compare the following examples from Western Washington University:
• Sheet map:
• Metsker Maps. (1979). Metsker's map of Island county, Washington [map]. (ca. 1:70,000.) Tacoma, WA: Metsker Maps.
• Metsker Maps (1979). Metsker's Map of Island County, Washington (Map). c. 1:70,000. Tacoma, WA: Metsker Maps.
• Sheet map in a series:
• Easterbrook, D. J. (1976). Geologic map of western Whatcom County, Washington [map]. 1:62,500. Miscellaneous investigations series, map 1-854-B. Reston, VA: U.S. Geological Survey.
• Easterbrook, D. J. (1976). Geologic Map of Western Whatcom County, Washington (Map). 1:62,500. Miscellaneous investigations series, map 1-854-B. Reston, VA: U.S. Geological Survey.
• Map from an atlas:
• Magocsi, P. R. (2003). Population movements, 1944–1948 [map]. 1:8 890 000. In P. R. Magocsi, Historical atlas of central Europe. (Rev. & ex. ed.) Seattle: University of Washington Press. (p. 53).
• Magocsi, P. R. (2003). "Population Movements, 1944–1948" (Map). Historical Atlas of Central Europe (Rev. & ex. ed.). 1:8 890 000. Cartography by P. R. Magocsi. Seattle: University of Washington Press. p. 53.
• Map from a periodical:
• Clout H. (2006). Figure 2: France: Types of countryside [map]. Scale not given. In H. Clout. Rural France in the new millennium: Change and challenge. Geography, 91, 207.
• Clout, H. (2006). "Figure 2: France: Types of countryside" (Map). Geography. Scale not given. Cartography by H. Clout 91: 207.
• Online map:
• U.S. Fish and Wildlife Service [cartographer]. (2009). Cahaba River Natural Refuge [map]. 1:24,000. Retrieved from http://permanent.access.gpo.gov/lps109506/
• U.S. Fish and Wildlife Service (2009). Cahaba River Natural Refuge (PDF) (Map). 1:24,000. Cartography by U.S. Fish and Wildlife Service. U.S. Fish and Wildlife Service. Retrieved March 14, 2015.
Overall, the new template will follow the general format from {{cite book}}, but it will also handle in-source citations in a journal with volume/issue/page numbers in the same output format as {{cite journal}}. The template will also handle noting insets and map sections right after the volume/issue/page number; those things very common on road maps printed as sheet maps or road atlases as part of the in-source location. After that, we get the usual suite of potentialID numbers (ISBNs/ISSNs/JSTOR/OCLCs/etc) as well as the |access-date=, archival information and even |via=.
About the only thing it doesn't handle that APA shows is the name of the article containing a map in a periodical, and it appears the |editor-first= |editor-last= aren't working either. Those could be added though. So what is it that you'd need for geological maps? Imzadi 1979  23:35, 14 March 2015 (UTC)
Example of |editor-first= and |editor-last= not working?
Trappist the monk (talk) 23:59, 14 March 2015 (UTC)
I tried this for an example above while editing it:
• Magocsi, P. R. (2003). "Population Movements, 1944–1948" (Map). In Magocsi, P. R. Historical Atlas of Central Europe (Rev. & ex. ed.). 1:8 890 000. Seattle: University of Washington Press. p. 53.
Imzadi 1979  00:05, 15 March 2015 (UTC)
Strike that, it wasn't working before. Imzadi 1979  00:06, 15 March 2015 (UTC)

Imzadi1979: your examples are free-form (untemplated), but as models your geological map examples are generally fine except that we usually:

1) omit "[map]";
2) omit place of publication for well-known agencies like the USGS;
3) identify the agency (publisher) before the series name;
4) put the scale and number of pages/plates at the end.

Following are examples of how I have done this using {citation}. I also use |journal=, which italicises the agency, and (with |volume=) use to make the series name/number bold. (E.g.: U.S. Geological Survey, Open-File Report 2010-1149.) Not an ideal implementation, but the best I have been able to devise.

{Cite journal} generates a very similar result, but {cite map} is not even close, in neither the old nor the new form:

 {{ cite map | date=June 2006 | url=http://www.dnr.wa.gov/Publications/ger_gm61_geol_map_mcmurray_24k.zip | last1=Dragovich | first2=A. J. | at=1 sheet, scale 1:24,000, 18 p. text | series=Geological Map GM–61 | first1=J. D. | journal=Washington Division of Geology and Earth Resources | title=Geologic map of the McMurray 7.5-minute Quadrangle, Skagit and Snohomish Counties, Washington, with a Discussion of the Evidence for Holocene Activity on the Darrington–Devils Mountain Fault Zone | ref=CITEREFGM-61 | last2=DeOme }} Old Geologic map of the McMurray 7.5-minute Quadrangle, Skagit and Snohomish Counties, Washington, with a Discussion of the Evidence for Holocene Activity on the Darrington–Devils Mountain Fault Zone (Map). Geological Map GM–61. June 2006. 1 sheet, scale 1:24,000, 18 p. text. Live Dragovich, J. D.; DeOme, A. J. (June 2006). "Geologic map of the McMurray 7.5-minute Quadrangle, Skagit and Snohomish Counties, Washington, with a Discussion of the Evidence for Holocene Activity on the Darrington–Devils Mountain Fault Zone" (Map). Washington Division of Geology and Earth Resources. Geological Map GM–61. 1 sheet, scale 1:24,000, 18 p. text.

. I am fine with using {citation/journal} (aside from the lack of bolding), but identifying maps as journals seems a little dishonest. Not a burning issue, but one I think we should think about. ~ J. Johnson (JJ) (talk) 18:50, 15 March 2015 (UTC)

Here's the citation above using {{cite map}} with some parameters used as documented (I think) and the sandbox version shown:
 {{ cite map | type=1 sheet, 18 p. text | url=http://www.dnr.wa.gov/Publications/ger_gm61_geol_map_mcmurray_24k.zip | date=June 2006 | scale=1:24,000 | last1=Dragovich | series=Geological Map GM–61 | publisher=Washington Division of Geology and Earth Resources | title=Geologic map of the McMurray 7.5-minute Quadrangle, Skagit and Snohomish Counties, Washington, with a Discussion of the Evidence for Holocene Activity on the Darrington–Devils Mountain Fault Zone | first1=J. D. | last2=DeOme | first2=A. J. }} Live Dragovich, J. D.; DeOme, A. J. (June 2006). Geologic map of the McMurray 7.5-minute Quadrangle, Skagit and Snohomish Counties, Washington, with a Discussion of the Evidence for Holocene Activity on the Darrington–Devils Mountain Fault Zone (1 sheet, 18 p. text). 1:24,000. Geological Map GM–61. Washington Division of Geology and Earth Resources. Sandbox Dragovich, J. D.; DeOme, A. J. (June 2006). Geologic map of the McMurray 7.5-minute Quadrangle, Skagit and Snohomish Counties, Washington, with a Discussion of the Evidence for Holocene Activity on the Darrington–Devils Mountain Fault Zone (1 sheet, 18 p. text). 1:24,000. Geological Map GM–61. Washington Division of Geology and Earth Resources.
Feedback on the sandbox version? – Jonesey95 (talk) 19:19, 15 March 2015 (UTC)
Definite improvement re the current version. (And even better if "series" is bolded.) However, the series name, which is often more significant than the full title, should precede the descriptive details (scale, sheets, etc.), which should come at the end. ~ J. Johnson (JJ) (talk) 21:25, 15 March 2015 (UTC)
1. I would oppose the ommission of "(Map).". In the other templates of the CS1 series, like {{cite press release}} or {{cite thesis}}, we indicate the type of source it is. Using |type=Geological map, |type=Topological map or even |type=Aerial survey would be ways to change the default, but something should be noted.
2. The place of publication isn't required, so you'd be free to omit if you wish. (We don't seem to require it on books, and we wouldn't require it on maps.)
3. I can see switching that, but the current order was based on the APA style (which is also the basis for most of CS1 and CS2) and it renders consistently with {{cite book}}.
4. I can also see switching that as well, to put the scale between publisher and in-source location information, but once again we started with the APA ordering as a basis.
In your example though, the publisher (USGS) should not be in italics. Nowhere else do we use italics in citations this way in the other templates, which is reserved for published works like the name of a book or the name of a journal.
 {{ cite map | url=http://www.dnr.wa.gov/Publications/ger_gm61_geol_map_mcmurray_24k.zip | scale=1:24,000 | date=June 2006 | series=Geological Map GM–61 | last1=Dragovich | at=1 sheet, 18 p. text | publisher=Washington Division of Geology and Earth Resources | title=Geologic map of the McMurray 7.5-minute Quadrangle, Skagit and Snohomish Counties, Washington, with a Discussion of the Evidence for Holocene Activity on the Darrington–Devils Mountain Fault Zone | first1=J. D. | last2=DeOme | first2=A. J. }} Live Dragovich, J. D.; DeOme, A. J. (June 2006). Geologic map of the McMurray 7.5-minute Quadrangle, Skagit and Snohomish Counties, Washington, with a Discussion of the Evidence for Holocene Activity on the Darrington–Devils Mountain Fault Zone (Map). 1:24,000. Geological Map GM–61. Washington Division of Geology and Earth Resources. 1 sheet, 18 p. text. Sandbox Dragovich, J. D.; DeOme, A. J. (June 2006). Geologic map of the McMurray 7.5-minute Quadrangle, Skagit and Snohomish Counties, Washington, with a Discussion of the Evidence for Holocene Activity on the Darrington–Devils Mountain Fault Zone (Map). 1:24,000. Geological Map GM–61. Washington Division of Geology and Earth Resources. 1 sheet, 18 p. text.

Imzadi 1979  23:13, 15 March 2015 (UTC)

I'm glad you think it's an improvement. I don't think bolding the series matches any of the style guides cited above, but moving the series may be possible. Do a text search above for "Series should be appear between Scale and Cartography" to see a discussion about the placement of that parameter. Pinging Imzadi1979 for comment. – Jonesey95 (talk) 23:15, 15 March 2015 (UTC)
Generally, I'm opposed to the usage of boldface text in citations. I've been in favor of totally removing it in the past for volume numbers. I'm not aware of any other style guides that bold volume numbers, and when it comes to books, I personally prefer |volume=vol. 1 to both add context to the number and force the template to render the output in roman (plain) text. For series names, I would oppose the boldface treatment, and I think it would go against our MOS.
As for the location of |series= vs. |scale=, the general order follows that of {{cite book}} combined with the map-specific items from the APA style.
1. First is the author(s) followed by the year in parentheses.
2. Then we render the name of the map in quotation marks, if it's a map within an atlas or journal (the analog of a chapter in a book or an article in a journal).
3. Then it's the name of the atlas/journal in italics. If it's a single sheet map, that name is rendered in italics as the map itself is the published work and not a component of a larger work.
4. The "(Map)" indicator is now flexible and follows the name of the map, whether that is in quotes or italics.
5. APA runs the scale next followed by the series. Cite book runs the names of other contributions after the series, so that's where we put the |cartography= output followed by |others=. (The former of those two is something I feel is a bit of a compromise based on how other road editors have and will use the template.)
6. Then we use the place of publication and the publisher, just as APA style and cite book would. Of course, many editors drop the place of publication when citing books.
7. Then we note the in-source location. For books, this has been the page number, and for maps, we also include the ability to source an inset of a map as well as the map sections.
8. Then we use the various possible ID numbers, like ISBN, ISSN, JSTOR, OCLC, etc.
9. Finally is any online-specific information, like access dates, archive dates, republisher (aka |via=) all like the other CS1 templates.
So in short, I'm flexible, but changing some of the ordering would also mean we should discuss the situation with other templates to keep consistency within the citation style. Imzadi 1979  23:40, 15 March 2015 (UTC)
So many points to consider!
Regarding omission of "[map]": the parallel with sources like theses and abstracts is incorrect. In scholarly work sources like these are identified because they have less weight than usual, but this is not applicable to geological maps. The correct parallel is with books and journals, where we do omit the source type. (E.g.: we don't indicate [book] or [journal].) Perhaps in some cases such an indication might be useful, but should be neither required nor the default.
I do not find APA style fully authoritative here. The USGS and most other agencies are quite similar in putting the name of the agency - the "publisher" - before the series name. Consider how ambiguous the very common "Open-File Report" is without specifying "USGS" or "Washington DGER". Indeed, it seems the name of the agency is deemed part of the series name, with subsequent specification as publisher omitted as being redundant. And in some cases (e.g., the Journal of Geophysical Research) the combined agency+series is all italicised, just as if was the title of a journal (and in line with your "3. ... atlas/journal in italics"), which gets back to the point I made above: geological maps are scholarly works on par with journal articles.
Out of time. More comments tomorrow. ~ J. Johnson (JJ) (talk) 23:22, 16 March 2015 (UTC)

Location of map scale and details

I raise a question of where the map scale (and certain other details, like the number sheets, numer of pages of text, etc.) should go. Imzadi1979 previously cited this page from NCSU Libraries that the scale "would come immediately before the series." I don't find that satisfactory. (In part because I find the NCSU examples generally clumsy and inelegant). In most (all?) geological usage the scale and other details are subordinated to, and therefore follow, the series; I recommend that here.

As to where scale should be placed relative to volume/issue/language: I do not recall ever seeing such a mixture. Do atlases and road maps have established usages in this regard? ~ J. Johnson (JJ) (talk) 23:29, 17 March 2015 (UTC)

CS1 is based on the APA style with modifications from it. It also uses The Chicago Manual of Style for inspiration, along with Wikipedian-generated concepts. The current template is mostly a Wikipedian-generated format that doesn't match the others in the CS1 series (it conflates the author and the publisher, and can't cite both), so in transitioning it to the Lua module, now is a good time to whip into shape to match the others.
The current APA stye guide only has a single example (p. 210):
That's why I pulled up the NCSU Libraries page because it has actual examples for citing maps in formats designed to be used with APA style, as the starting point for updating {{cite map}} to CS1 style as CS1 is so heavily based on APA.
CMOS 16 is largely silent. It does talk about noting map sources in a credit line (p. 128). The closest example is on p. 726 where it shows how to cite an illustration or table on a page as a part of a footnote, saying:
• The abbreviation fig. may be used for figure, but table, map, plate, and other illustration forms are spelld out. The page number, if given, recedes the illustration number, with a comma between then.

50. Richard Sobel, ed., Public Opinion in US Foreign Policy: The Controversy over Contra Aid (Boston: Rowman and Littlefield, 1993) 87, table 5.3.

To me, this isn't helpful because it only deals with citing a map as an illustration in a published work, and not when the map is the work. So, at this point, I think we're on our own, other than consulting the recommendations of various university libraries or cartography programs for guidance.
what exact order would you like us to use? I'm assuming that after the title(s), you would immediately go to the location*/publisher followed by series, scale, in-source locations, identifiers (ISBN, etc), and then the online archival/retrieval information where optionally used. That could work for me too, if that's what others want. (* |location= is omitted by a lot of Wikipedians in citing books, so as I've mentioned, individual editors could omit it as they wanted.) We'll need a place to insert |cartography=, to deal with the situations I illustrated in the next subsection. We'll also need a place in that order for |others= as well as |agency= in the rare cases of maps that have been translated (|others=Translation by Jean-Luc Picard) or distributed through a news wire agency (|agency=Associated Press).
Imzadi 1979  03:08, 18 March 2015 (UTC)
For all that I have seen (and I have spent most of today researching this), there are two locations for map scale: 1) immediately following the map name ("title"), or 2) following the series name/number. These correspond to two broad conceptions, which we can loosely identify as "APA style", or "geoscience style" (apparently universal with agencies and publishers in the US). Given that citations (references) are supposed to aid in identifying and locating sources, I find the APA style (esp. the NCSU examples) cumbersome in presenting the most relevant information. (E.g., "Reston, VA: United States Department of the Interior" are attributes of the USGS, and contribute nothing to identifying a map.) I will note that many experts consider a map's scale to be of primary importance, which would justify emphasis. However, in practice this is more of descriptive datum, and less important than the series, wherefore geoscience style subordinates scale to follow the series.
In all geoscience uses I have found the scale is always at the end of the citation, but this needs to be qualified in two ways. 1) As we are striving for broader usage, there are data that reasonably follow, such as ISBNs, urls, access date, etc., and perhaps volume and page numbers, which are generally absent in scholarly usage. 2) Geological maps generally include certain details such as the number of sheets (plates), the number pages of text, supplemental files, etc. These are usually associated with the scale, but I haven't seen any particular format.
Note that a "map" can consist of more than one sheet, at different scales. So it would be quite reasonable to see (though I haven't seen it) something like "2 maps (scale 1:62,500, 1:24,000), 32 p. text". Also, APA says that if a scale is not specified the citation should explicitly state "scale not given". However, there are "maps" that have multiple images (on a single sheet) at different scales, where this is nonsensical. ~ J. Johnson (JJ) (talk) 22:52, 18 March 2015 (UTC)
So, J. Johnson, what are you proposing? As a follow up, is anything you're proposing something that needs to be immediately addressed in the Lua transition, or would that be something to be addressed in a supplemental update to the template? Imzadi 1979  04:50, 19 March 2015 (UTC)
A quick second thought, but could it be that what you need to cite is just different enough from citing individual sheet maps, maps in atlases, online maps like those from Google Maps, et al., that there should be a forked template that is similar, but has a different use for these geological maps you need to cite, a {{cite geo map}}? Imzadi 1979  04:53, 19 March 2015 (UTC)
As for different scales, the insets on a sheet road map are almost always drawn at a different scale than the main map. In the few cases where I've had a need to cite the main map plus one of the insets, I've used separate footnotes, or manually indicated the locations on the sheet map being cited through the use of |at=. To follow the APA guidance, if necessary, I'd note "Scales not given" in the plural, although some of Michigan's maps included the scale on the insets but not the main map, oddly enough. For something like the iconic London Tube Map, I had occasion to use |scale=Not to scale. Imzadi 1979  04:59, 19 March 2015 (UTC)
No, nothing (that I am aware of) that needs immediate attention, although I would caution against having |scale= either required, or defaulting to "not given". (My initial question was "if there might be interest ...." We do seem to be well beyond a simple "yes".)
I don't believe a forked template (e.g., {cite geo map}) would be useful. In my context most (all?) geological maps are scholarly works, and are cited without special distinction as maps. My interest here is to see if {cite map}, and perhaps certain parameters in {citation}, can be made general enough to be suitable for geological maps. ~ J. Johnson (JJ) (talk) 19:49, 19 March 2015 (UTC)
At the moment, |scale= is not required and does not have a default value, which isn't something that is not being changed in the transition. Imzadi 1979  23:58, 19 March 2015 (UTC)
Keeping |scale= as not required is good. How this is ordered with other similar details does not seem very significant. ~ J. Johnson (JJ) (talk) 21:08, 22 March 2015 (UTC)

"Cartography"

The use of the |cartography= parameter has been touched on in several places above. Scott5114 suggested (24 Feb) that this field is intended to identify the original source of the "cartography" that has been republished by others, the people doing the actual cartography being seldom credited. However, in geological and topographic maps it is common to identify who did the cartography. But (at least in geological maps) this is only part of the "authorship", and I am not aware that cartogrpahers, distinguished from authors, are ever mentioned in a citation. So possibly the use of this parameter needs clarification. ~ J. Johnson (JJ) (talk) 23:31, 17 March 2015 (UTC)

I've cited a few county plat atlases in the past. The library catalogs credit the county and the local 4H Club as the authors of the atlas, while the company that actually published them did the cartography. Once the template is transition to the Lua module and updated, I can properly credit the authors of the atlas (the county, the 4H club) separate from the publishing company for their contributions.
I typically cite the official state road maps from Michigan. These were all printed by what is now the Michigan Department of Transportation, and for the most part, they drew them in house. However, for a few years in the 1930s, the base road map was drawn by HM Gousha or Rand McNally, while the state did all of the other work and may have modified the contracted company's work. The library catalogs credit the state highway department as the author; the cartography source is either omitted in the catalog or moved to a secondary contribution note.
In working with gas station road maps, the company who distributed them (say Esso) is typically thought of as the author because of the quantity of content they added to the map while they may have contracted with Rand McNally to provide the base road map. These are also indexed in library catalogs under the oil companies' names, not Rand McNally's.
I agree that in many contexts, the cartography is the author and doesn't need separate billing. Until the updated template goes live in the next module update, we have no way to separate author, publisher, and cartographer (where distinct), as the current inadequate template inappropriately conflates author and publisher. Imzadi 1979  02:30, 18 March 2015 (UTC)
So looking forward: should we have specific criteria to avoid ambiguous uses of this parameter? Perhaps even a caution that it is normally not used unless there is something special about the cartography/cartographers? ~ J. Johnson (JJ) (talk) 19:45, 18 March 2015 (UTC)
I think it might be fine to simply note that this parameter will usually be blank unless the information is available. The third-party cartography information is important because it can be helpful to know that, e.g, the Texaco Rand McNally map cited will probably have substantially similar content to a Rand McNally map with Skelly branding. In addition, some older Oklahoma state maps did list a credit for the woman who drew the maps (along with the name of her supervisor, for some reason), and when citing those maps I have included this information. Newer maps have nothing of the sort, probably because the map is the responsibility of a team of cartographers) so it is omitted. —Scott5114 [EXACT CHANGE ONLY] 04:24, 19 March 2015 (UTC)
As I said above, geological maps often credit who did the cartography (part of the general scholarly practice of crediting everyone who has contributed or assisted), but I am not aware of any cases where such information was of any use in a citation. Perhaps it would be sufficient to say that this parameter is for special cases, and not normally used. ~ J. Johnson (JJ) (talk) 19:53, 19 March 2015 (UTC)

"Scholarly" vs. "Everything Else" map citation order

I think we're both in general agreement about most of the order of presentation. It seems to be a question of where to put the |series= in relation to the publisher, and I'm ok with a general "Location: Publisher. Series" order. As you note, the publisher forms a type of natural disambiguation with the series name in that respect. ("Which '7.5-Minute Series'? Oh, the 'US Geological Survey 7.5-Minute Series'!") As for |scale=, I'm neutral about running it after the map name or after the publisher/series. So if we had a general order of:

• Author(s). (Date). Titles (in italics or in quotes and italics as appropriate). Location: Publisher. Series. Scale. Others. In-source location(s). ID numbers. Online-related data.

I think we'd both be generally happy. Maybe I've mis-read slightly, so one of those pieces may need a slight shuffling. (Others would be where to handle wire agency or |cartography= in the general scheme.)

The various CS1 templates though have no function to note the total number of pages in a book, so something like "2 maps (scale 1:62,500, 1:24,000), 32 p. text" doesn't seem to fit with the way the rest of the template family does things. I might be tempted to tell editors who felt strongly enough to insert that into |scale= since that is a free-form parameter that doesn't impact any metadata.

Turning to the "in-source" location, road maps have grid sections, which are supported through |section= or the new |sections=, which will be prefaced by § and §§, respectively. I'm wondering if we should add |sheet= and |sheets=. The MDOT Right-of-Way Map File Application (the name of their website) divides the state highway system into 83 "maps" (by county name) with individual numbered sheets as well as the county title sheets. I've used |at=Sheet 180 in the past, but a |sheet=180 along with |sheets=1–2 would be useful. I gather that would be useful for multi-sheet geological maps as well? Do geological maps ever have sheets numbered as multiple pages, or pages numbered as separate sheets? Imzadi 1979  03:11, 20 March 2015 (UTC)

Yes, sheets get numbered (also in dissertations), and a |sheets= parameter could be good. That could also take the number of pages of text. As to whether this should come immediately before or immediately after scale: I see no consistent pattern. (And I have no consistent opinion on this!) Any guidance from roadmap usage? Alternately, all this could go into (say) "desc=". Or simply appended to the template. But definitely after publisher/series.
Regarding "series": I strongly favor preceeding it with the "publisher". Preceding that with the publisher's location is a problem, because it could be confused as the location of the map. I suggest omitting location, just as we usually omit the location of a journal publisher. I also favor italicising the publisher, to distinguish it from the name of the series. (I note that some publishers do this with a colon, or even a comma.) With {{citation}} I have found that using journal+volume or journal+series works well, though strictly speaking that is a misuse of |journal=. However, |publisher= gets put after volume/series, so that isn't satisfactory. How do we manage this?
BTW, I found an interesting discussion on Map Authorship and Citation Guidelines. Part of it is about distinguishing between maps, and the data used to generate the maps. I don't think we need to worry about that. Yet. ~ J. Johnson (JJ) (talk) 23:15, 20 March 2015 (UTC)
Ok, Trappist the monk, can we add |sheet= and Template:Para sheets then? As for order, I'm thinking sheet/sheets should go with the page/pages ahead of any inset or section/sections. That would keep things in a general largest-unit-to-smallest-unit order, I think.
Regarding location, publisher and series, as I've noted, J. Johnson, you'll be free to omit the location, while others will include it, so that comment is less helpful. I agree with you that publisher can go ahead of series to have the natural disambiguation aspect mentioned above, but I'd oppose italicizing the publisher as no other CS1 templates does such. Yes, we should be designing a template to accommodate academic practices, but we're also fitting this template into the rest of a family of templates with an established style.
You left one of my questions unanswered though. Is a single sheet ever numbered as separate pages? The answer would let us know how to order the display of the parameters if both are present. Otherwise, I doubt we'd run into citations that used both. Imzadi 1979  02:16, 21 March 2015 (UTC)
I think we are pretty much in accord. We agree that the publisher should precede the series name, the challenge being in how to arrrange that. I would like the italicisaton, but I grant that's not likely. For scholarly usage (I dilike "academic") we don't need a separate template if this one will work, and I think it will. Having "location" right after the map title would be an issue, but as long as it can be omitted that is not an issue. The description of the map itself - such as the number of sheets (plates) and pages of text, and things like "five-foot poster of nine maps" (there is an instance) - should precede the page range or such that indicate where the map (or map subset) is to be found. Which I believe is what we are converging on.
I am not certain if I understand your last question. Geological maps generally consist of a main map sheet (like any other map), possibly additional supplementary sheets, and explantory text, which may be on the sheet, or in a separate pamphlet or book. If there is more than one sheet they will (or should) be numbered, just like the pages in a pamphlet or book are numbered. But sheets are not pages, they are separate. Sometimes sheets are bound into a book (often as foldouts), but they are not counted as pages. What might be confusing is where a small map is printed on a page. These are usually treated as a kind of figure or illustration, andare often numbered (just like tables), so might be cited as "map 2 on page 99". But in such a case the "map" is just a figure within a larger source (such as a book). If I understand your question, the answer is "no": as discription sheets and pages (of text) are counted separately, and as locaters they do not overlap. Okay? ~ J. Johnson (JJ) (talk) 19:46, 21 March 2015 (UTC)
OK, I think that we've probably converged on opinion then, and it's a matter of getting the Lua module changed at the next regular update to rearrange the display order and add |sheet= and |sheets=. I'll note that we have |at= for free-form locations, which is quite handy for more custom situations. The initial Lua conversion was implemented today, so if we make a list of specific tweaks, they can be implemented in the next regular update in a few weeks. Imzadi 1979  20:22, 21 March 2015 (UTC)
Yep, make a list of specific tweaks so that I don't have to try to understand all of what you-all are talking about. For existing in-source locators, the order of precedence is: |page=, |pages=, |at= but its |sections= over |section=. I think that's backwards. I should also add the redundant parameter error detection.
And that makes me wonder about the in-source locator parameters and COinS. Currently only |page=, |pages=, or |at= is included in the COinS. Should |sheet=, |sheets=, |section=, and |sections= be combined with |page=, |pages=, |at= in some appropriate order for assignment to COinS rft.pages?
Trappist the monk (talk) 13:59, 22 March 2015 (UTC)
Some maps have both text (pages) and sheets, so as description it is useful to have both the number of pages and the number of sheets. But I don't believe there is any particularly appropriate order for these (or scale). As for specifying a location within a larger work: I believe COinS is primarily about locating the work itself ("in the local library"), and specifying a particular page or sheet (in-source locator) does not seem useful. And as pages and sheets are non-overlapping specifying both as a location suggests some kind of error. ~ J. Johnson (JJ) (talk) 21:15, 22 March 2015 (UTC)
Since no list of specific tweaks has appeared, has this train of thought been abandoned?
Trappist the monk (talk) 13:12, 28 March 2015 (UTC)
I'm conflicted in my thought processes on this. On the one hand, the current order in the template was designed to mimic the style of the other templates in the CS1 family. It is also based on the APA style, just as most of the other CS1 templates are based on APA. APA is a scholarly style, so while I see some advantages to the style as proposed by J. Johnson, I'm content to leave the template as it is in terms of output order.
As for |sheet= and |sheets=, I still think that would be good to add. As I suspected, a map citation should not refer to both a page and sheet number, so in terms of an in-source reference, they'd be first followed by any inset and ending with the grid section(s). That would tell me that we could combine them into the COinS metadata in that order. Imzadi 1979  15:24, 28 March 2015 (UTC)
A map's full citation should handle having both number of sheets and number of pages as description; combining them for COinS seems fine. I believe we are agreed on the authors-date-title-[location]-publisher-series-scale... ordering. This is nearly what we have currently, except for
1) moving publisher in front of series, and
2) moving scale further down. And
3) adding a |sheet= parameter.
I don't believe there is anything critical hanging on any of this, so there's no need to get everything "right" on the first go. Take a whack at it, and we will see how it looks. ~ J. Johnson (JJ) (talk) 21:35, 28 March 2015 (UTC)
I still disagree on the full number of sheets or the full number of pages. We don't cite how many pages are in a book, just the page or pages where the cited information will be found.
As I noted immediately above, I'm still conflicted on changing the output order. As I've been working on updating the usage of templates in articles to use the updated {cite map}, my viewpoint is back on the side of leaving the order as it is now, based on CS1/APA usage, because that flows with {{cite book}}'s output. Your #1 change would move {cite map} away from {cite book} again, not toward it. The series for a book appears before the publisher, not after it, so it would follow that the series for a map should appear before the publisher to stay consistent. As for #2, APA style keeps the scale ahead of the series nearer to the title of the map; it could be moved, but I'm not sure why. APA is a scholarly citation style, so I don't see why we need to change things. Imzadi 1979  02:22, 29 March 2015 (UTC)
Map Title (Map). Sheet 4. – sheet map
"Map Title" (Map). Journal 45 (3): Sheet 4. – map in a journal
"Map Title" (Map). Title. Sheets 4, 5. Detail inset. §§ C2–D3. – map in a book or atlas
Trappist the monk (talk) 15:47, 29 March 2015 (UTC)
APA has evolved within the social sciences (and humanities?), with very little (if any) feedback from the geosciences on the use of map citations. Broad-based experience has led nearly all geoscience authorities (as I have said above) to converge on a fairly standardized style. Not being able to accomodate that will be a strong dis-incentive for using {cite map}, and limit {cite map}'s applicability.
A few details: The full citation of books often include the number of pages (which is often useful for identifying variant editions or reprintings); this is more common for pamphlets ("books" of less than 50 pages), which geological maps more closely resemble. Scale is very important in paper maps, where the relationship is fixed, but less so in digital formats (such as pdfs) which can be reproduced at any scale. This may be why scale is getting relegated to the descriptive details.
BTW: Trappist, your examples are hybridized short/full citations. E.g. (to use one of my examples), a short cite (in-line, with an in-source spec) could be "Dragovich and DeOme, 2007, p. 12" (author-date), or "GM-61, p. 12" (short title), while the full citation would be like any of the examples above. ~ J. Johnson (JJ) (talk) 22:08, 29 March 2015 (UTC)
The purpose of the three citations above is to illustrate new parameters |sheet= and |sheets=. No other purpose is intended.
Trappist the monk (talk) 23:01, 29 March 2015 (UTC)
No CS1 template includes total number of pages, and {{cite map}} is a CS1 template. The CS1 family is based on APA and the Chicago Manual of Style. Editors are free to use any style of citation they which, but they are supposed to do so consistently. Until now, this template was not very consistent with the rest of the CS1 family, and now it is.
APA says to omit a scale where it is not fixed, like Google Maps and such, but if a scanned map is reproduced in PDF format, the scale is still fixed. It's no different to enlarge a PDF on screen than to take a magnifying glass to a printed paper map. The original scale of the map will still impact the level of detail, even when enlarged because unlike something like Google Maps, the enlargement does not add details. You may omit including the scale if you wish as the template does not require a value in |scale=, nor can it because the template needs to be able to cite variable-scaled maps like Google Maps, Yahoo! Maps, OpenStreetMap, etc.
I just thought of something. |title= has a corresponding |trans-title=; should we have a |trans-map= to go with |map=? Imzadi 1979  23:20, 29 March 2015 (UTC)
"Map Title" [Translated Map Title] (Map). Title. Sheets 4, 5. Detail inset. §§ C2–D3. – map in a book or atlas
Trappist the monk (talk) 00:06, 30 March 2015 (UTC)
A map scale relates the size of a physical map to the size of the physical topography covered by the map. If a map sheet at 1:24,000 scale is 20 inches across, it means that the map covers an area of 480,000 inches (40,000 feet). And an inch on a physical map is still an inch, no matter how much you magnify it. (Presumably your ruler is below the magnifying glass, not above it.) All digitally derived maps are "variable-scale" until they are expressed physically, and then the resulting scale is specific to that expression.
If the scale is to follow APA style (following the title) then we should have a |desc= parameter where the scale can be included with the descriptive details. ~ J. Johnson (JJ) (talk) 21:57, 30 March 2015 (UTC)

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. -- 18:16, 28 February 2015 (UTC)

Concur.
Trappist the monk (talk) 19:55, 28 February 2015 (UTC)
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)

"Missing or empty |title=" error message

Various uses of citation without a |title= now throw the error message "Missing or empty |title=". Per a discussion last January I had thought that use of "|title=none" was going to suppress this message, but that is not happening. Can we get this message suppressed? ~ J. Johnson (JJ) (talk) 19:53, 12 March 2015 (UTC)

Example?
The referenced discussion referred specifically to {{cite journal}} though the applied 'fix' also applies to {{citation}} when one of the |periodical= parameters (except |encyclopedia=) is set. Which see:
{{cite journal |title=none |periodical=Periodical}}
Periodical.
{{citation |title=none |periodical=Periodical}}
Periodical
{{citation |title=none |encyclopedia=Encyclopedia}}
"none", Encyclopedia
Trappist the monk (talk) 22:49, 12 March 2015 (UTC)

Example:

{{citation |author= Hegerl, ''et al.'' |chapter= Chapter 9 |title=none }} in {{Harvnb|IPCC AR4 WG1|2007}}.
> Hegerl et al., "Chapter 9", none in IPCC AR4 WG1 2007.
[My apologies. I condensed the example the example so much that it looks like a short cite, but it is intended to be a full citation. See the uncondensed example below. ~ J. Johnson (JJ) (talk) 21:10, 14 March 2015 (UTC)]
Better example below at #Example of "source in work" ~ J. Johnson (JJ) (talk) 00:50, 21 March 2015 (UTC)
where the source is a chapter in the larger work linked to. Strictly speaking the 'work' is a book, but use of {cite book} gives the same result. Use {cite journal} causes |chapter= to be ignored. ~ J. Johnson (JJ) (talk) 22:18, 13 March 2015 (UTC)
This would allow replacement of the little used {{source in source}}. -- 22:58, 13 March 2015 (UTC)
I have never warmed to {source in source} (too grotesque), and would favor its replacement. ~ J. Johnson (JJ) (talk) 21:04, 14 March 2015 (UTC)

{Harvc} as alternative

Even though you are on the record in opposition, this is the kind of thing for which {{harvc}} was invented. Somewhere in the text you have: {{sfn|Hegerl, et al.|2007}} which for illustration I'll put here.[1]

In the bibliography section write a citation for the book. This template is one I found at Global warming; it has not been modified:

{{Cite book | year = 2007 | author = IPCC AR4 WG1 | title = Climate Change 2007: The Physical Science Basis | series = Contribution of Working Group I to the [[IPCC Fourth Assessment Report|Fourth Assessment Report]] of the Intergovernmental Panel on Climate Change | editor = Solomon, S.; Qin, D.; Manning, M.; Chen, Z.; Marquis, M.; Averyt, K.B.; Tignor, M.; and Miller, H.L. | publisher = Cambridge University Press | url = http://www.ipcc.ch/publications_and_data/ar4/wg1/en/contents.html | isbn = 978-0-521-88009-1 | ref = harv }}

Then write {{harvc}} templates for each of the individual chapters that are part the 'book' but are cited separately:

{{harvc |last=Hegerl, et al. |year=2007 |c=Chapter 9: Understanding and Attributing Climate Change |url= http://www.ipcc.ch/publications_and_data/ar4/wg1/en/ch9.html |loc=[http://www.ipcc.ch/publications_and_data/ar4/wg1/en/ch9s9-5-2.html Section 9.5.2: Sea Level]|in=IPCC AR4 WG1}}

So, from your {{sfn|Hegerl, et al.|2007}} there is now a link into §References where there is a link to the appropriate chapter in §Bibliography which links to the book. Here is the link in article text again.[2] The {{harvc}} template can also be enclosed in <ref>...</ref> tags.[3]

==References==

References

==Bibliography==

Trappist the monk (talk) 23:58, 13 March 2015 (UTC)

My apologies for causing some confusion here. In the interest of brevity I condensed the example above so much it may appear to be a short cite, such as where harv templates are used to connect to a full citation with full bibliographic details. (This confusion is further compounded by the way citations are misused at Global warming#Citations.) The preferred solution here is to have very short links (implemented with some form of {harv}), such as "Hegerl, et al. 2007", used where ever material needs to be attributed, all of which link to a single full citation such as the following:
This should be considered as a full citation, which would appear only once in an article (presumably in the "Bibliography" or such), and refers to the whole source ("Chapter 9"), not to any specific material within. (I have stricken the specification that was mistakenly included.) It does not look like a "full" citation because it does not repeat the bibliographic details of the encompassing work, nor a proper list of authors, and contains only the details that distinguish this chapter from other chapters in the same work. ~ J. Johnson (JJ) (talk) 20:41, 15 March 2015 (UTC)
{{harvc}} does that: can appear only once and refers/links to the single whole source, does not look like a full citation (because it isn't one) and contains only the details that distinguish this chapter from others in the same work. And, it doesn't produce corrupted metadata and so there isn't a missing title error message (though it will emit error messages when required stuff is omitted).
Trappist the monk (talk) 00:26, 16 March 2015 (UTC)
The important point is that the "in source" attribution follows only the full citation, not every instance of the short cite. (The latter being what {{harvc}} does, which is one reason why I opposed it, the other being that I don't believe a whole additional template is necessary for this.) And in fact the current set does all this just fine, except for the little detail of an entirely unnecessary and unuseful red error message.
So back to my initial request: can this little red splash be suppressed? ~ J. Johnson (JJ) (talk) 21:10, 14 March 2015 (UTC)
The example full citation template is incomplete. It identifies a chapter of 'something', but doesn't identify what that 'something' is. Because that template is a CS2 citation, it produces metadata that are also incomplete. This is the reason that there is, and should remain, an error message. The full template is coupled (by proximity only) to a {{harvnb}} template that links to a full citation that is complete in and of itself – title, editors, publisher, isbn, etc that the pseudo-full citation lacks.
This same is all true of {{harvc}} in that it also lists only a chapter of 'something' without identifying what that 'something' is; it also links to a full citation with all of the aforementioned stuff (without an additional {{harvnb}} template). But, because it isn't a CS1/CS2 template, it does not produce metadata and is simply a bridge between simple {{sfn}} templates and the full citation template. I've tweaked my examples above to include the chapter's name, url, and location data.
Trappist the monk (talk) 23:00, 14 March 2015 (UTC)
The "something" - the larger work which includes this source - is identified. Just not within the template. The citation is indeed complete as displayed (that is, the work is identified/linked). But I gather your concern is providing context for the metadata collected from the template. Well, that is a deep issue. And it seems to me that harvc is, in the end, just a kludge for getting around the CS1 error checking. I think it would be simpler to just suppress the error message. However, I want to take a deeper look at al this, and see if I can better formulate what is needed. For the duration: even if "missing title" is kept as a maintenance category, could we at least have the error message suppressed? ~ J. Johnson (JJ) (talk) 20:43, 15 March 2015 (UTC)
Yes. There is no facility for us to split a citation and then, somehow, later, gather up all of the incomplete metadata from the disparate parts and meld them into a single complete unit. It is not possible; templates can't communicate with each other. Maybe someday but not at present. So, {{harvc}} is no more a kludge than writing a CS1/CS2 citation that intentionally leaves out information critical to the proper compilation of the citation's metadata. Better, I think, to have metadata that is complete and correct than to have metadata that is incomplete.
Trappist the monk (talk) 00:26, 16 March 2015 (UTC)
I have had an idea (yikes). In {{harvc}} you have an |in= parameter. Could we have a similar parameter in {{citation}}, which would signal that the citation metadata is incomplete and should not be collected for COinS? And incidentally overlook the lack of a title? ~ J. Johnson (JJ) (talk) 23:04, 18 March 2015 (UTC)
Could. But:
1. {{harvc}} is already written, debugged, working, and documented
2. new documentation would be required
3. adding |in= to Module:Citation/CS1 adds yet another level of complexity to an already complex code set
So, unless overwhelming support for this compels me, I'd rather not.
Trappist the monk (talk) 15:25, 19 March 2015 (UTC)
Harvc does not provide the functionality needed (such as expansion of the author list), misorders the elements (but fixable?), and adds complexity to the use of citations. I would be satisfied if {{citation}} simply accepted the lack of a title; my idea for an |in= parameter would address your conern about incomplete metadata. It also permits retention of title checking for the general run of cases where lack of a title probably is an error. If coding that is too much trouble, then let's fall back to the previous idea of using |title=none to suppress the error message. I believe any changes to the documentation are minimal, and I can take care of that, so that should not be any objection. ~ J. Johnson (JJ) (talk) 19:24, 19 March 2015 (UTC)
{{harvc}} was modeled on the other short-form templates that accept a maximum of four author names. That could be changed, I suppose, though we would probably also need to include a form of |display-authors= so that the template could switch from its default, where it acts just like the other {{harv}} templates, to displaying all or part of the author list. How are the elements misordered? How is using {{harvc}} any more complex than the exemplar that uses both a broken CS2 template and a {{harvnb}} template?
Trappist the monk (talk) 14:26, 20 March 2015 (UTC)
I'm putting together an example which should clarify the situation. ~ J. Johnson (JJ) (talk) 23:27, 20 March 2015 (UTC)
I've added a better example below at #Example of "source in work". In brief, one or more short cites (implemented with harv templates) link to the citation for the chapter (contribution), which links to the citation for the work. The middle layer uses {{citation}} because there is no simple form of {{harv}} that will produce the full author list (which could include author-links), and because any use of harv of at the middle layer confuses the use of short cites. All of this works just fine, aside the from the red message. ~ J. Johnson (JJ) (talk) 01:06, 21 March 2015 (UTC)
Trappist the monk: back to my initial request, can the Missing or empty title message be suppressed, either entirely, or in the specific case of |title=none? ~ J. Johnson (JJ) (talk) 23:03, 24 March 2015 (UTC)
Have I not already answered this? No. The error message is there for a purpose and so should not be suppressed. If we do anything, it should be to {{harvc}} where we expand on its ability to better handle and display all or part of the author list.
Trappist the monk (talk) 11:02, 25 March 2015 (UTC)
You said you would "rather not" implement my idea of an |in= parameter, and I can accept that you think it is not important enough. However, suppressing this red message is a different matter. It is an "error" only because you (and ??) decided that it should be; I think it can be argued that it is not. Indeed, in regards of COinS I would argue that given a full citation for a containing work, citations for the chapters contained within should not generate COinS metadata. However, the usual way of handling such cases - incorporating all the bibliographic details of the containing working within each chapter's citation (see example below) - can lead to voluminous redundant data for the IPCC reports. The method I have developed for handling these cases is reasonable, and works. Except for the splot of red, which is a recent innovation.
Harvc is not suitable. Should we break out a subsection to discuss that? ~ J. Johnson (JJ) (talk) 21:46, 25 March 2015 (UTC)
You are mistaken. I do think it is important. That is why {{harvc}} exists. I also think that it is important to let the CS1/2 templates do what they do best and not try to make them do else-wise by creating special cases where the module does something different; there is too much of that already complicating the code in service of the unique characteristics of the various templates. So far I see no reason to abandon my 'rather not' position.
I have suggested that {{harvc}} functionality could be expanded but even with that you stand fast on Harvc is not suitable. This begins to look rather like a stalemate which to me is wearisome.
Trappist the monk (talk) 00:05, 26 March 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── I regret that this is becoming wearisome, but it is rather important for me, so I would deem it a great favor if you might bear with me a little longer. The IPCC citations present some unusual and difficult challenges, and though these are not so notable across the entirety of Wikipedia (but what sources are?), they are very significant within the Global Warming articles. The approach I developed has worked very well, up until the recently introduced "error" messages. I take your view to be that this approach involves "broken" {{citation}} templates, that this approach misuses the templates in making them do something they were not designed for, and would complicate the underlying code.

Regarding the last, I do not see how testing the template data for "missing or empty title" is any less complicated than not testing for that. Even the special case of skipping the test for "title=none" should be only a single line, nothing complicated. But if it is, then I would argue: eliminate the title test entirely.

Which gets to what I suspect is the core issue: is citation of chapters always incomplete, and therefore an error, if it is missing details of the containing work, such as title? I do agree that a "citation" is incomplete without such details. But I say the issue is more finely whether the template (whether {{citation}} or {{cite xxx}}) must contain all the details, and more particularly whether a link to those details is acceptable. I find that this must be made acceptable, as the alternative is that every chapter cited in every IPCC Assessment Report becomes bloated with these extensive details. I believe your argument at this point would be something about the incompleteness of COinS data. I will address that tomorrow. For now I ask if you concur with what I have described so far. ~ J. Johnson (JJ) (talk) 04:34, 27 March 2015 (UTC)

Here are a couple of {{harvc}} templates of the sandbox variety. They will accept as many authors as you want. Right now it's somewhat clunky: |display-authors=99 |display-authors=all is used to display all of the authors in the contributor's list. If the value assigned to |display-authors= is all or the same as or greater than the number of authors in the contributors list, then all last and first names are displayed. If |display-authors= is empty or omitted, then the template displays up to the first four (if present) last names in the same way that other 'harv' templates do. If |display-authors= is assigned a value less than the number of authors in the contributors list, the template displays both last and first names of that number of contributors followed by et al.
Here the {{harvc/sandbox}} template output is compared to your unmodified {{citation}} output. The differences are date display and brackets around year in the link to the enclosing work.
• {{sfn}} templates link to {{harv/sandbox}} templates.[1][2]

References

Trappist the monk (talk) 00:58, 29 March 2015 (UTC)
Thank you. I will study this tonight. ~ J. Johnson (JJ) (talk) 21:25, 29 March 2015 (UTC)
I am somewhat amazed that you went to the trouble of making harvc produce a proper display, where addition of (I believe) one or two lines in the CS1 code could have saved us all this trouble. Particularly as harvc extends the harv templates well past what they were designed for. Which sounds like what you complained about on the 26th, that "it is important to let the CS1/2 templates do what they do best and not try to make them do else-wise by creating special cases where the module does something different...". The only special case I am asking for is the one value of "none" for title, and all it does is suppress an error message. Your fix introduces three new parameters (|c=, |url=, and the |in= parameter you rejected for CS1 on the 19th), and radically alters the normal Harv output. Not to mention that new documentation will be required (your objection #2 on the 19th).
But while the harvc display now looks reasonable, there is still a fundamental problem: the harv templates are designed for use in-line as short cites, whereas the CS1 and CS2 templates are designed for full citations. As such the latter are often collected together as lists, where inclusion of a short cite form (harv) as an item is anomalous, and typically an error. Using a full citation form (such as {citation}) for the IPCC chapters is reasonable and conformable with all other full citations, using the same general format. Use of harvc increases complexity, creates anomalies that invite "correction", and increases the difficulty of explaining to other editors why there must be this anomalous usage.
Trappist, I really appreciate that you would put significant time and effort into tweaking harvc. However, it also concerns me that you should expend so much time and effort on something fundamentally unsatisfactory when there is a better solution. I believe your principal concern is the integrity of the COinS data. If that is satisfactorily addressed, could we not have the minimalist modification of "title=none"? ~ J. Johnson (JJ) (talk) 22:39, 30 March 2015 (UTC)
|c= (and its aliases |chapter= and |contribution=), |url=, and |inn= have been part of {{harvc}} since its first release. The changes in {{harvc/sandbox}} are: unlimited |lastn=, addition of |firstn=, |author-linkn=, |author-maskn=, and |display-authors=; conversion of |separator= to |mode= for CS1/2 compliance. Yeah, if I make this new version the live version then I'll need to update the documentation.
I chose {{harvc}} as a name because it was developed from the code that handles the {{harv}} and {{sfn}} templates. {{harvc}} is just a name. Pick another name; one that makes you happy; then make a redirect from that name. Or {{harvc}} can be moved to that name.
Trappist the monk (talk) 11:35, 31 March 2015 (UTC)
{{citation-in}}? Well, a name change would help, but the problem is that it is only "skin deep": the parameters and their usage are still different. This template by any name is inherently different, which increases complexity. ~ J. Johnson (JJ) (talk) 00:20, 1 April 2015 (UTC)

"Error" message still a problem, and Harvc still unsuitable

Trappist the monk: the "missing or empty title" message is still a problem, and (upon re-reviwing the matter) I find Harvc is still unsuitable for the use needed (as previously explained). Therefore I re-iterate my original request to suppress this message. Or, alternately, to allow some keyword that would suppress the message. You previously stated (25 Mar) that "[t]he error message is there for a purpose", which I take to be ensuring that data extracted for COinS is complete. However, it seems to me that skipping the metadata extraction these cases is simple (and even quite reasonable, as chapters are not really suitable for COinS anyway), and so should not be an issue if a special keyword is implemented.

If you still object to having a special keyword I would much appreciate reviewing your reasons. ~ J. Johnson (JJ) (talk) 23:09, 20 April 2015 (UTC)

I'm pretty sure that my position hasn't changed since my last post on this topic three weeks ago. Unless there is something new to discuss ...
Trappist the monk (talk) 11:49, 21 April 2015 (UTC)
Yep, because omitting |title= corrupts the metadata; yep, because to do what you want introduces yet another 'special case'; yep, because special cases complicate code, they always have and they always will. Checking for missing titles is not new but, rather, has been refined. In the past, anything that vaguely resembled a title counted as a title but that loose definition permitted editors to create citations that produced incomplete metadata.
I have no hidden reasons for my opposition and I have addressed the issue: see the {{harvc/sandbox}} examples in the adjoining discussions.
Trappist the monk (talk) 12:12, 23 April 2015 (UTC)
Thank you for clarifying this. So your opposition is based entirely on two points: 1) leaving out "title" corrupts the COinS data, and 2) special cases complicate the code.
Regarding your first objection, I point out that metadata is not corrupted if it is not generated. If a "title" (referring to a containing book or "work") is not present, then it is appropriate to not generate any metadata, and there is no corruption. This is reasonable, as COinS is used to find library items (e.g., books), not chapters within books. (Underlying this is a deeper issue of whether every use of a citation template must include a title, but as this is not a point of objection we need not examine it.) If in the special case I am asking for COinS data is simply not generated, there is then no corruption of the metadata. Your point is refuted.
Regarding your second objection: if you insist on simplicity for its own sake, then you should remove all COinS processing, which is a vast complication on the original and primary purpose of the CS templates. On a smaller scale you could simply remove the code that checks for "missing or empty" titles. Of course, that would conflict with the preference for complete metadata, but that is my point: it's all a matter of trade-offs. You decided that reducing data corruption warranted further "refinement", but when you broke an established and valid usage you decided that it was not important enough for any further refinements. This is particularly odd as the CS code appears to be a mass of special cases, so why do you think this special case will break everything?
I do not find your objections valid (which is why I wonder if there is some other basis for your adamancy), and do not know how else to address them. Would you be persuaded otherwise if I can find (say) three other editors (after all, this is an obscure technical point) who support what I have requested? ~ J. Johnson (JJ) (talk) 22:01, 23 April 2015 (UTC)
Of course, metadata are not corrupted if not generated, but CS1 and CS2 do generate metadata. The decision to do so was taken quite long ago. I don't know how the metadata are consumed but I would guess that complete and accurate metadata are important to those who do consume it. The COinS documentation identifies a keyword rft.atitle to hold chapter titles. COinS support exists, the metadata are used, so that facility likely isn't going away even though it would simplify the code. (And yes, I think every CS1 and CS2 template should have a title.)
Yep, Module:Citation/CS1 is awash in special cases because it directly supports some two dozen CS1 and CS2 templates. One of my long-term goals is to minimize that to the extent possible.
Trappist the monk (talk) 11:09, 24 April 2015 (UTC)
So you agree that, in the cases at issue, if a COinS record is not generated, there is no corruption of the data. The question is then whether, in such cases, not generating a record is a loss of data. I say no, as a record is generated for the item (book) containing the chapter. I believe the issue comes down to having either a) multiple records containing chapter data that is that is useless for finding the book and book data that is repeated across all these records, or b) a single record for the book that does not contain information not useful for finding the book (i.e., the chapter details). In most cases of "source in work" there is only a single instance, so it is convenient to package all the bibliographic detail into one citation. (That COinS has a field for chapter title is, I believe, for the rare but extant cases where a chapter is published separately, where it is useful to know that the material might be found as an individual item, or included in a larger work.) In the cases I am working with there are multiple instances, and even multiple levels of containment (section in chapter in report in review), each with substantial bibliographic detail. Such masses of detail can overwhelm both readers and editors, and causes other problems, wherefore I find it necessary to use the second approach. ~ J. Johnson (JJ) (talk) 21:27, 24 April 2015 (UTC)
I find it necessary to use the second approach for which purpose {{harvc}} was designed and since enhanced. {{harvc}} does not produce COinS metadata, can be linked from multiple places in an article, does link to the containing work's CS1/2 citation, and does hold and display the substantial bibliographic details of the sub-unit. All of this so that [s]uch masses of detail [don't] overwhelm both readers and editors, and [cause] other problems.
Trappist the monk (talk) 12:08, 25 April 2015 (UTC)
Have I not already explained this? Harvc is fundamentally unsuitable. (See my previous comment of 22:39, 30 March.) Although you can make the resulting display essentially equivalent, Harvc is quite at odds with the use and purpose of the Harv family of templates. It is very much a special case (such as you keep inveighing against) that will only confuse the editors attempting to use. E.g., the Harv templates generate short cites which do not contain bibliographic details, and (typically) use only the last name (of one or more authors) or a shortened title to link to the full citation. Now editors will wonder (it becomes necessary to explain) why bibliographically complete full names and full titles are required for Harvc, but are not accepatble for the rest of the Harv templates. Also: editors can readily understand having the short cites (implemented with Harv) in the text (or notes therein) and the full citations (implemented with CS1/CS2 templates) in a seperate "References" section. But having Harvc templates mixed in with the CS templates is anomalous, confusing an otherwise distinct usage. Harvc not only makes the already challenging task of IPCC citation more complex, it is likely to confuse and perplex editors in the use of the Harv templates generally. This is entirely unacceptable.
CS1/CS2 already does everything you claim for the unsuitable and even dubious Harvc, and the simple enhancement I am requesting could easily skip producing COinS data. Your advocacy of Harvc in the face of a simpler and more suitable option brings us back to my previous question: why? Your objections are inconsistent and disproportionate, and I believe I have adequately addressed them. So why do you persist?
BTW: In quoting me are you concurring in preferring the second approach? ~ J. Johnson (JJ) (talk) 23:46, 25 April 2015 (UTC)
I can take a file to one of the claws of a framing hammer so that it fits a slotted-head wood screw and use the modified hammer to drive the screw or I could just hammer the screw into place. I would be better to use a screwdriver, the proper tool for the job. {{harvc}} is not a special case but rather, the proper tool to render intermediate cites between long-form citation templates and short-form citation templates.
{{harvc}} has never required bibliographically complete full names; its default is to display the contributor list in the same manner as {{sfn}} and {{harv}}. Because of its intermediate nature, it does require a title and the enclosing work's author/editor list or name.
I don't believe that our editors are bucket-headed dolts who are incapable of understanding how all of these bits, pieces, and parts fit together. I took your point about {{harvc}}'s name. Do you have a better name? You did suggest {{citation-in}}. Because {{harvc}} defaults to CS1 styling perhaps that name should be {{cite-in}}. But, I don't think that {{harvc}} should be renamed to either of those because it isn't one of the CS1 (cite) or CS2 (citation) family of templates. Perhaps the name should describe the function: {{harvc}} is intermediate between short-form and long-form citation templates: {{intermediate harv cite}} perhaps with a redirect from {{ihc}}.
I would not have gone to the trouble of coding {{harvc}} if I didn't believe that there are times when an intermediate template between short- and long-form citation templates is appropriate.
Trappist the monk (talk) 15:10, 26 April 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── As a quasi-humorous interlude: years ago I was surprised to find a tool like an awl with screw thread on the end. The intended use is to hammer it into a stud, then screw it out, leaving a pre-threaded pilot hole for a proper screw. This was considered better practice than hammering screws in most of the way, taking a couple of turns at the end. Which is perhaps to say that kludginess is relative.

Your "bucket-headed dolts" is not really relevant here. I think there are such editors, but the editors I am trying to serve are quite experienced (and competently so), and I believe are fully capable of understanding citation complexity. But many of them are uncomfortable going beyond the simplest use of CS1/CS2. Which I find somewhat reasonable: WP has a lot of complex stuff, and I am loathe to add any unnecessary complexity. I would like to bring them up to using Harv, but there is great sensitivity to any perceived complexity, and especially so for any increase of complexity. This includes radically differing uses (such as use of full or only last name, as I described in my previous comment) of ostensibly similar "Harvx" templates. Using a different name would defuse some of the anticipation of similiarity, but would add another layer of complexity where I am convinced the existing tools (with a slight enhancement) are quite adequate.

Keep in mind that this intermediate link I am trying to implement has two components. First is the description (full biblilographic details) of the chapter (contribution); second is the link (minimal necessary details) to the enclosing work. Note the key differences: the chapter has the full names of all authors, AND the full title, while the enclosing work has either the last names only of the first three editors, OR a short title. The CS1/CS2 templates are designed to do the former, while the Harv templates are designed for the latter. Except for Harvc, which you are repurposing to do both by adding a raft of additional parameters. Your hammer is now trying to emulate a ratchet screwdriver that handles slotted, Phillips, or Allen head screws.

If you really insist on a separate template let's do this: copy {{citation}} to {{citation-nc}} ("no coins"), then remove both the title test and all of the code for generating COinS data. No red message, no corrupted data, and we're both happy. Right? ~ J. Johnson (JJ) (talk) 20:33, 27 April 2015 (UTC)

I think that the current situation works just fine. {{Harvc}} is designed to shorten a citation down to the name(s) of the contributor(s) of a component in a larger work and link to the full citation of the encompassing work in another section. It works just fine to handle multiple chapters in a report that each have individual authorship apart from the encompassing report on Michigan State Trunkline Highway System, and for the life of me, I can't see what the great issue is with that system that's caused all of this discussion and debate. The status quo with the templates, with a few possible amendments seems more than adequate. Imzadi 1979  05:05, 28 April 2015 (UTC)
Imzadi: I think you are not paying close enough attention. All that you said is quite true except one little detail: a couple of months ago the status quo changed, resulting in numerous "error" messages that beg "fixing". I am trying to get Tappist to make a "possible amendment", but won't do it. He wants me to use Harvc, which I find quite unsuitable. Not because of the displayed result, but for all the objections he makes to my requested little change, plus the confusion it will add the use of citations, particularly the Harv templates. We are not arguing about the resulting display, but the process, and similar underlying issues. ~ J. Johnson (JJ) (talk) 05:50, 28 April 2015 (UTC)

Comment

I need a context to understand this. Have I got this right? J. Johnson wants three levels of citation, a short inline citation, an intermediate level that describes a chapter in a larger work (in this case, an online work), and a top level citation that gives full information on the work? I don't think that's traditional in paper citation styles. If I'm right that it is untraditional, it's going to confuse readers, who won't be expecting a three-level citation hierarchy. And it's going to be even more confusing for editors. So if the work has the same authors for all chapters, I'd cite the entire work and have short cites to that. If the work has different authors for different chapters, and especially if the identity of the chapter authors is significant, I'd put every chapter that was used in the bibliography and make the short cites point to the appropriate chapter. Jc3s5h (talk) 21:04, 15 March 2015 (UTC)

Pretty nearly "yes" on all counts. (Though what I want is subect to modification. I'm still working this out.) And what you suggest - giving each chapter (these all have different authorship) a full citation that includes the details of the containing work - is inded the standard format. However, in the various global warming articles the chapters from the IPCC reports are cited so often, and the citations of the containing works have so much detail, that the citations become very bloated, in both the wiki-text and the displayed text, with redundant information. This obscures the essential information, and makes careful editing extremely tedious. That having three levels of citation (instead of the more common two levels) is not "treaditional" is not, I think, a problem, as any readers interested in the sources (most of them are not) are used to clicking on a link to get to the next level of information. ~ J. Johnson (JJ) (talk) 23:56, 17 March 2015 (UTC)

Example of "source in work"

The goal is to enable having within an article one or more short cites like this Hegerl et al. (2007)[1] (in either the text or a note, and optionally specifying a location within the source[2][3]) that link to a single citation for a chapter (contribution) with the full details of that source, which in turn links to a single citation for the containing work, without repeating at any level the details of the chapter or of the containing work. And without the red message complaining of a missing or empty title.

Notes

1. ^ [Generated with {{harv}} templates like this: {{Harvtxt|Hegerl et al.|2007}}]
2. ^ Hegerl et al. 2007, Section 9.5.2: Sea Level, p. 999. [Short cite, with specification appended.]
3. ^

In the "References" or "Bibliography" section, using {{citation}} templates:

• Hegerl, G. C.; Zwiers, F. W.; Braconnot, P.; Gillett, N. P.; Luo, Y.; Marengo Orsini, J. A.; Nicholls, N.; Penner, J. E.; Stott, P. A. (2007), "Chapter 9: Understanding and Attributing Climate Change", Missing or empty |title= (help) in IPCC AR4 WG1 2007. ["Full" citation of Hegerl et al., except that details included in the citation of the containing work (below) are not repeated here. This citation appears only once in the article.]

Contra-example: The goal is to avoid having to cite each chapter with a bloated "fullest" citation such as the following:

All this currently works just fine, aside from the recent introduction of the "missing or empty title" message. ~ J. Johnson (JJ) (talk) 00:43, 21 March 2015 (UTC)

I have added a contra-example of the bloated "fullest" citation that ordinary usage requires for every chapter cited. ~ J. Johnson (JJ) (talk) 21:34, 25 March 2015 (UTC)

Linked editor with initial in first name causes doubled period

A minor rendering bug in the code: If the final editor of a {{cite book}} has a first name ending in a period, then the template is clever enough to omit the extra period separating the editors from the rest of the citation, preventing an ugly doubled period. For example,

{{cite book|contribution=Chapter 27: Automorphism groups, isomorphism, reconstruction|title=Handbook of Combinatorics|pages=1447–1540|editor1-first=R. L.|editor1-last=Graham|editor1-link= Ronald Graham|editor2-first=M.|editor2-last=Grötschel|editor3-first=L.|editor3-last=Lovász|first=László|last=Babai|authorlink=László Babai|publisher=Elsevier|location=Amsterdam|year=1995|contribution-url=http://people.cs.uchicago.edu/~laci/handbook/handbookchapter27.pdf}}

produces

Babai, László (1995). "Chapter 27: Automorphism groups, isomorphism, reconstruction" (PDF). In Graham, R. L.; Grötschel, M.; Lovász, L. Handbook of Combinatorics. Amsterdam: Elsevier. pp. 1447–1540.

But, if the editor's name is wikilinked, then the doubled-period suppression doesn't work:

produces

Babai, László (1995). "Chapter 27: Automorphism groups, isomorphism, reconstruction" (PDF). In Graham, R. L.; Grötschel, M.; Lovász, L. Handbook of Combinatorics. Amsterdam: Elsevier. pp. 1447–1540.

One could work around this by omitting the period from the editor-first parameter, of course, but this is undesirable for a couple of reasons: it breaks the metadata, and it causes the wikilink to fail to include the final period in the editor's name. So fixing the code to suppress the doubled period in this case would be better. —David Eppstein (talk) 18:14, 15 March 2015 (UTC)

I'll work on this after the next update.
Trappist the monk (talk) 19:22, 15 March 2015 (UTC)
Thanks; no particular rush on this one as long as it gets done eventually. —David Eppstein (talk) 19:48, 15 March 2015 (UTC)
Fixed in the sandbox.
Babai, László (1995). "Chapter 27: Automorphism groups, isomorphism, reconstruction" (PDF). In Graham, R. L.; Grötschel, M.; Lovász, L. Handbook of Combinatorics. Amsterdam: Elsevier. pp. 1447–1540.
Trappist the monk (talk) 11:38, 28 March 2015 (UTC)

Where should |format= be used?

Where should it be used and where is it even necessary? Should it be used for TXT files? PHP files? Dustin (talk) 20:01, 17 March 2015 (UTC)

My preference would be to use it only for {{cite web}}, where the linked web resource *is* the citation. For journal articles or arxiv preprints or whatever that happen to include a link, the link is an incidental part of the reference, and could be changed to a different link in a different format that doesn't change the main information of the reference, so I don't see why the format of this incidental link is such important information that it needs to be displayed prominently in the citation. —David Eppstein (talk) 20:14, 17 March 2015 (UTC)
I don't think it is ever necessary, but if the document is a .doc or a .xls file, or something other than HTML or PDF or something else that displays normally in a web browser, it might help a reader to note the format. – Jonesey95 (talk) 21:55, 17 March 2015 (UTC)
I agree with Jonesey95, except that I also note PDFs. Not all browsers can display PDFs, and because PDFs tend to be larger files than HTML pages, some users would appreciate the warning that clicking the link means downloading a PDF. Imzadi 1979  22:11, 17 March 2015 (UTC)
|format= only applies to the content of |url=. Similarly, |chapter-format= only applies to the content of |chapter-url=. The parameters should be used whenever the file format of the file referred to in the url parameters is not an html document. Wikimedia adds the pdf icon to external links that have urls ending in .pdf but, these icons do not have alt= descriptors to tell screen readers what the image is so for pdf documents, it is important to include |format=pdf in the citation.
URLs that end in .php usually render HTML files so using |format= for them is unnecessary. For .txt files, it probably doesn't matter but might be a good thing to do so that readers have some idea of what they might expect if they click the citation's link.
Trappist the monk (talk) 22:07, 17 March 2015 (UTC)
I strongly disagree with your claim that format= should always be used for pdf links in citations that are not cite web. It is irrelevant cruft that clutters up the citation and makes the actual useful information harder to find. —David Eppstein (talk) 22:55, 17 March 2015 (UTC)
Here's a citation from Dots and Boxes to which I have added |chapter-format=pdf. Explain to us please, how that simple addition has made the actual useful information harder to find?
{{Citation | last = West | first = Julian | author-link = Julian West (author) | contribution = Championship-Level Play of Dots-and-Boxes | editor-last = Nowakowski | editor-first = Richard | title = Games of No Chance | pages = 79–84 | publisher = MSRI Publications | place = Berkeley | year = 1996 | contribution-url = http://library.msri.org/books/Book29/files/westboxes.pdf |chapter-format=pdf}}
West, Julian (1996), "Championship-Level Play of Dots-and-Boxes" (PDF), in Nowakowski, Richard, Games of No Chance, Berkeley: MSRI Publications, pp. 79–84
Returning to Editor Dustin V. S.'s question, other cases exist where |format=pdf should be used. The New York Times, for example, publishes archived copies of old articles in PDF format but the URLs don't end in .pdf so a reader has no way of knowing that the link to the article is not the usual HTML that is used for archival of more recent articles:
"Resolute Beats All Cup Course Records" (PDF). The New York Times. 11 June 1914.
Trappist the monk (talk) 23:58, 17 March 2015 (UTC)
Since the |format= value is displayed without the period, I would add "PDF" in uppercase because it's an acronym. GoingBatty (talk) 04:11, 18 March 2015 (UTC)
And then someone will notice MOS:ACRO and demand that it will be spelled out as "Portable Document Format" rather than abbreviated, no doubt... —David Eppstein (talk) 04:19, 18 March 2015 (UTC)

At MediaWiki:Common.css, the file extensions that change the normal external link icon to the pdf icon are .pdf, .pdf?, .pdf# (also in uppercase, but not mixed case). It occurs to me that it is relatively simple to test urls for these extensions. I've hacked a test into Module:Citation/CS1/sandbox that tests the url that is applied to the archive link. If the file extension is one of the Common.css recognized extensions then the code adds what amounts to |archive-format=PDF to the rendered citation (there is no such parameter).

The other thing I did was to shrink the size of the format annotation. Editor GoingBatty noted that because PDF is an acronym, it should be capitalized. I have always found that to be rather loud so have usually done |format=pdf as you can see from my New York Times example above. In the experiment, I set the annotation to 85% of the surrounding text. These examples are encloded in {{ref begin}} and {{ref end}} to mimic how reduced size format annotation might look in real reference lists.

"Title" (PDF). Archived from the original (PDF) on 2012.
"Title" (PDF). Archived (PDF) from the original on 2012. (|deadurl=no)

Trappist the monk (talk) 14:58, 28 March 2015 (UTC)

I've expanded a bit on the above by defining a presentation style in Module:Citation/CS1/Configuration/sandbox for |format=, |chapter-format=, etc. The style is the same as described above except that it forces the content of the format parameter to be uppercase before the size is reduced:
 {{ cite book | chapter=Chapter | format=PDF | title=Title | chapter-format=pdf | chapter-url=//example.org/somat.pdf | url=//example.com/somat.pdf }} Live "Chapter" (PDF). Title (PDF). Sandbox "Chapter" (pdf). Title (PDF).
In typing the above example, it occurred to me (not for the first time) that the is_pdf() test described above should be applied to all url-holding parameters and the appropriate format-holding parameters set to PDF if not already set.
Trappist the monk (talk) 13:42, 1 April 2015 (UTC)

At Help_talk:Citation_Style_1#lay-url-format I suggested that we should probably have format parameters for all url-holding parameters. The url-holding parameters that don't have matching format parameters are:

1. |archive-url=
2. |conference-url=
3. |contribution-url= – alias of |chapter-url=
4. |event-url= – alias of |conference-url=
5. |lay-url=
6. |section-url= – alias of |chapter-url=
7. |transcript-url=

So, without objection I'll add format parameters for the above.

Trappist the monk (talk) 14:39, 1 April 2015 (UTC)

Six are done, |archive-format= yet to be done.
conference: Title. Conference (format).
contribution: "Contribution" (format). Title.
event: Title (Speech). Event (format).
lay: "Title". Journal. Lay summary (format)Lay Source (1 April 2015).
section: "Section" (format). Title.
transcript: "Title". Series. Transcript (format).
Trappist the monk (talk) 16:31, 1 April 2015 (UTC)
And archive:
with |format=fmt and without |archive-format=afmt:
"Title". Archived from the original (fmt) on 2012.
"Title" (fmt). Archived from the original on 2012. (|deadurl=no)
without |format=fmt and with |archive-format=afmt:
"Title" (afmt). Archived from the original on 2012.
"Title". Archived (afmt) from the original on 2012. (|deadurl=no)
with |format=fmt and |archive-format=afmt:
"Title" (afmt). Archived from the original (fmt) on 2012.
"Title" (fmt). Archived (afmt) from the original on 2012. (|deadurl=no)
without |format=fmt and without |archive-format=afmt:
"Title". Archived from the original on 2012.
"Title". Archived from the original on 2012. (|deadurl=no)
Book with a |chapter=, |chapter-url=, |url=:
with |format=fmt, |chapter-format=cfmt, |archive-format=afmt:
"Chapter". Title. Archived from the original on 2012.
"Chapter". Title. Archived from the original on 2012. (|deadurl=no)
with |format=fmt, |chapter-format=cfmt, |archive-format=afmt:
"Chapter". Title (afmt). Archived from the original on 2012.
"Chapter". Title. Archived (afmt) from the original on 2012. (|deadurl=no)
with |format=fmt, |chapter-format=cfmt, |archive-format=afmt:
"Chapter" (cfmt). Title. Archived from the original on 2012.
"Chapter" (cfmt). Title. Archived from the original on 2012. (|deadurl=no)
with |format=fmt, |chapter-format=cfmt, |archive-format=afmt:
"Chapter" (cfmt). Title (afmt). Archived from the original on 2012.
"Chapter" (cfmt). Title. Archived (afmt) from the original on 2012. (|deadurl=no)
with |format=fmt, |chapter-format=cfmt, |archive-format=afmt:
"Chapter". Title. Archived from the original (fmt) on 2012.
"Chapter". Title (fmt). Archived from the original on 2012. (|deadurl=no)
with |format=fmt, |chapter-format=cfmt, |archive-format=afmt:
"Chapter". Title (afmt). Archived from the original (fmt) on 2012.
"Chapter". Title (fmt). Archived (afmt) from the original on 2012. (|deadurl=no)
with |format=fmt, |chapter-format=cfmt, |archive-format=afmt:
"Chapter" (cfmt). Title. Archived from the original (fmt) on 2012.
"Chapter" (cfmt). Title (fmt). Archived from the original on 2012. (|deadurl=no)
with |format=fmt, |chapter-format=cfmt, |archive-format=afmt:
"Chapter" (cfmt). Title (afmt). Archived from the original (fmt) on 2012.
"Chapter" (cfmt). Title (fmt). Archived (afmt) from the original on 2012. (|deadurl=no)
Book with a |chapter=, |chapter-url=, |url=:
with |chapter-format=cfmt, |archive-format=afmt:
"Chapter". Title. Archived from the original on 2012.
"Chapter". Title. Archived from the original on 2012. (|deadurl=no)
with |chapter-format=cfmt, |archive-format=afmt:
"Chapter" (afmt). Title. Archived from the original on 2012.
"Chapter". Title. Archived (afmt) from the original on 2012. (|deadurl=no)
with |chapter-format=cfmt, |archive-format=afmt:
"Chapter". Title. Archived from the original (cfmt) on 2012.
"Chapter" (cfmt). Title. Archived from the original on 2012. (|deadurl=no)
with |chapter-format=cfmt, |archive-format=afmt:
"Chapter" (afmt). Title. Archived from the original (cfmt) on 2012.
"Chapter" (cfmt). Title. Archived (afmt) from the original on 2012. (|deadurl=no)
In the examples that include |url=, you can see that the archive code doesn't swap |chapter-url= with |archive-url=. This seems wrong to me. Shouldn't |archive-url= be paired with the most specific url in the citation?
Trappist the monk (talk) 20:05, 1 April 2015 (UTC)
I have consolidated all of the format styling into a single function where as in the tests described above it was strewn thither and beyond. As part of that consolidation, I have restored the code that detects the various pdf file extensions so that when |xxx-format= is empty or omitted and the a url points to a pdf file, the the code sets |xxx-format=PDF:
conference: Title. Conference (PDF).
contribution: "Contribution" (PDF). Title.
event: Title (Speech). Event (PDF).
lay: "Title". Journal. Lay summary (PDF)Lay Source (1 April 2015).
section: "Section" (PDF). Title.
transcript: "Title". Series. Transcript (PDF).
These examples make sure that we get an error message when |xxx-format= is set but |xxx-url= is not
format: Title (format).
archive: Title (format).
conference: Title. Conference (format).
contribution: "Contribution" (format). Title.
event: Title (Speech). Event (format).
lay: "Title". Journal. (format).
section: "Section" (format). Title.
transcript: "Title". Series. Transcript (format).
Trappist the monk (talk) 00:02, 2 April 2015 (UTC)
• Strongly object. I hope this is an April Fools joke, because I very much dislike format= in cases where the url name makes the format obvious, very much do not want this gratuitous cruft added automagically to the references of the articles I edit, and very much do not want to have to add display-format=no (or whatever) to prevent your automagic cruft from crufting up the articles. By your stubborn insistance on imposing your formatting preferences on others despite their objections (see above) you are in gross violation of WP:RETAIN. Please DO NOT DO THIS. You are driving me away from using templates to format citations at all, because you keep making the templates harder to use and harder to prevent from doing annoying things. Is that really the effect you intend? —David Eppstein (talk) 00:10, 2 April 2015 (UTC)
This morning, these search strings turned up more than 68,000 pages that use |format= to identify PDF documents in CS1/2 citations:
insource:/\| *format *= *PDF/ – 53,991 pages
insource:/\| *format *= *pdf/ – 14,136 pages
I did not invent |format= nor did I write Help:Citation_Style_1#External_links or Template:Citation_Style_documentation#csdoc_format. Because icons do not support the alt attribute, leaving out |format= is a disservice to those who cannot see the icon (or the url since it is hidden in the href= attribute of the <a>...</a> tag). If you have a beef with |format= parameters, the beef is not with me but with W3C, or browser makers, or MediaWiki who have either not defined a requirement for alt= text use with images in CSS, not implemented such defined support in browsers, or who have not added alt= text to the icon portions of MediaWiki:common.css and perhaps elsewhere. When such support is defined and supported, then there is no further 'need' for |format=pdf when a visual icon is present. For other, non-browser supported file types (.xls, etc.) there will always be a need for |format=.
Because the icons are applied with CSS, they are therefore, not content but merely decoration. I suppose that in the module it's possible to override the background property and then insert the same icon using an <img /> tag with appropriate alt= text and whatever other attributes are required. It would seem better to do that globally in the MediaWiki software. You might raise the issue at Phabricator.
Trappist the monk (talk) 14:41, 2 April 2015 (UTC)

Hey, thanks to all of you for helping me to find an answer to my inquiry, as well as for the work you put into this template. Dustin (talk) 20:10, 1 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. RomanASCII. 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.
Trappist the monk (talk) 13:34, 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)
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)
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)
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:
1. 0000–007F C0 Controls and Basic Latin (C0 Controls: 0000–0020)
2. 0080–00FF C1 Controls and Latin-1 Supplement (C1 Controls: 0080–00A0 & 00AD)
3. 0100–017F Latin Extended-A
4. 0180–024F Latin Extended-B
5. 0250–02AF IPA Extensions
6. 02B0–02FF Spacing Modifier Letters
7. 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.
Trappist the monk (talk) 12:29, 23 March 2015 (UTC)
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)
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.
Trappist the monk (talk) 15:26, 23 March 2015 (UTC)
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)

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 to hidden = 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À-ÖØ-öø-ƿǄ-ɏ%-%s%']*\$")
The pattern includes, I think, all the letters in the Latin range of 0000–024F, jumping over things like × (00D7) and ÷ (00F7) etc.
Trappist the monk (talk) 00:53, 27 March 2015 (UTC)
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 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.
 {{ cite book | name-list-format=vanc | last=Waśniowska | first=J. Paul | last2=Gómez-Coronado | last3=Kühme | title=Title | last4=Ǆǻlĕç | first2=Suárez | first4=d | first3=T }} Live Waśniowska JP, Gómez-Coronado S, Kühme T, Ǆǻlĕç d. Title. Sandbox Waśniowska JP, Gómez-Coronado S, Kühme T, Ǆǻlĕç d. Title.
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)

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 Á. "title".

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'.
Trappist the monk (talk) 00:03, 23 March 2015 (UTC)
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.
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?
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)
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). 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=.
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=.
Trappist the monk (talk) 00:11, 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 |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)
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.
but then we get titles like this:
|title=A Parallactic Distance of $389^{+24}_{-21}$ 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 $389^{+24}_{-21}$ 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.
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, 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.
Trappist the monk (talk) 11:21, 9 April 2015 (UTC)
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)
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.
Trappist the monk (talk) 23:26, 10 April 2015 (UTC)
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)

{cite map} oddity

Overall, I'm very pleased with the changes made with {{cite map}} to convert it over to use the Lua module and make it more consistent with the other CS1 templates and academic citation standards. One little weird thing has popped up though.

1. Michigan Department of Transportation (2014). Pure Michigan: State Transportation Map (Map). 1 in≈15 mi / 1 cm≈9 km. Lansing: Michigan Department of Transportation. §§ A1–B2. OCLC 900162490.
2. Colorado State Highway Department (July 1923). "New Map Showing the 8,880 Miles Which Comprise Colorado's Primary Highway System" (Map). Colorado Highways. Scale not given 2 (7): 12–13. OCLC 11880590. Retrieved November 18, 2013 – via Google Books.
3. Rand McNally (2013). "Michigan" (Map). The Road Atlas. 1 in≈20 mi. Chicago: Rand McNally. §§ A1–B1. ISBN 0-528-00626-6.
4. Rand McNally (2013). "Michigan" (Road map). The Road Atlas. 1 in≈20 mi. Chicago: Rand McNally. §§ A1–B1. ISBN 0-528-00626-6.

If the map is a sheet map, or a map in a journal, as in the first two examples above, then the "(Map)." appears after the name of the map. For a sheet map (#1), that title is in italics; for a map in a journal (#2), it's in quotation marks while the journal is italicized. If it's a map in a book (#3) though, "(Map)." is missing instead of appearing after the map name in quotation marks. If |type=Road map (or some other type of map) is defined (#4), then the type shows up as expected, but the default isn't appearing as it should. If this can be fixed, it would be great. Imzadi 1979  05:36, 27 March 2015 (UTC)

Fixed, I think, in the sandbox. I've tweaked #s 2, 3, 4 to use {{cite map/new}}.
Trappist the monk (talk) 11:44, 27 March 2015 (UTC)
Sounds and looks good. Thanks for all of your work getting us to where we are on the template. Imzadi 1979  15:25, 28 March 2015 (UTC)

Article style template

I created {{article style}} as an edit notice for to indicate various styles within an article. -- 12:51, 27 March 2015 (UTC)

That looks helpful for editors. Do you have a grand vision that templates like {{Use British English}} and {{Use dmy dates}} could be merged into this new template? – Jonesey95 (talk) 13:53, 27 March 2015 (UTC)
Yes. Need to roll through Category:Editnotice templates.
Currently only admins can create article edit notices, and the system for non-admins is cumbersome. I have some thoughts on that. -- 19:22, 27 March 2015 (UTC)
Re "only admins...", I have run into that inconvenience in the past. It would be nice if having the article style template at the top of an article made the edit notice appear (admins could still do custom notices, I suppose), but I don't know any of the technical details that make WP work the way it currently does. – Jonesey95 (talk) 20:07, 27 March 2015 (UTC)
Users with the template-editor right can also created edit notices. I'm willing, within reason, to create them for people. I'm sure others with the TE right would feel similarly, although they may not be aware that they have the ability. Imzadi 1979  22:01, 27 March 2015 (UTC)
I've nominated this template for discussion. I like the concept of having this information readily available, but I oppose this approach due to getting users with elevated privileges involved in style changes, and the screen space the notice would occupy, which is an activity where users need all the screen space they can get. Jc3s5h (talk) 22:16, 27 March 2015 (UTC)

Date parameter

I want to give the date as "Christmas 2007", but |date=Christmas 2007 throws up an error. Eric Corbett 18:20, 28 March 2015 (UTC)

Will |issue=Christmas 2007 work? Do you have a specific example from a specific article? That always helps. – Jonesey95 (talk) 19:35, 28 March 2015 (UTC)
The issue parameter is intended for the issue number, for those periodicals that assign numbers for their issues (usually, but not always, starting at 1 in January). If the date printed in the magazine is "Christmas 2007" that's the date, and Eric is right and the error message is wrong. So the options are just leave the error message, format that particular citation by hand, or rip all the citation templates out of the article and use some non-template citation method for the articles. Jc3s5h (talk) 21:20, 28 March 2015 (UTC)
Why can't it be the "Christmas of 2007" issue? If "Christmas, 2007" is taken as a date (though not a style we really recognize) it implies the date of the issue really was December 25, 2007. ~ J. Johnson (JJ) (talk) 21:43, 28 March 2015 (UTC)
I was going to try to give you a good answer, but it's all wrapped up in the different placement of the date depending on whether an author is named for an article in a periodical. So I decline to explain myself until that bug is fixed. Jc3s5h (talk) 22:02, 28 March 2015 (UTC)
That's fine. ~ J. Johnson (JJ) (talk) 22:13, 29 March 2015 (UTC)
In addition, note that the publication may also have a conventional issue number - which would be lost if Christmas 2007 was used as the issue - really this is no different than Winter 2007, which is allowable.Nigel Ish (talk) 22:06, 28 March 2015 (UTC)
A specific example is ref #130 in the Stretford article. Eric Corbett 22:32, 28 March 2015 (UTC)
Five more examples: Northern Rail ref #4, Mario Kart: Double Dash‼ ref #33, Populous: The Beginning ref #23, Strange (TV series) ref #1, and Desiré Wilson ref #4. GoingBatty (talk) 22:41, 28 March 2015 (UTC)
This looks like a real thing. The linked source in Northern Rail gives its date as "Christmas 2004". The Mario Kart and Populous articles cite a magazine called Edge that published issues with issue numbers and "Christmas YYYY" dates (example). The Strange article cites SFX magazine, which has also published issues with issue numbers and dates of Christmas YYYY. That's enough proof for me that "Christmas YYYY" is a real date for citation purposes. – Jonesey95 (talk) 00:32, 29 March 2015 (UTC)
 {{ cite book | date=Christmas 2015 | title=Title }} Live Title. Christmas 2015. Sandbox Title. Christmas 2015.

Trappist the monk (talk) 12:38, 29 March 2015 (UTC)

When is that likely to go live? Eric Corbett

Cite:_web problem.

I would really like a way to insert a {{rp}} for web sites, like you can for books. Let us take a highly newsworthy murder and trial, for example. There may be dozens of articles from CNN.com, Foxnews.com along with various other news organizations, but then the ref list gets really long, really quick. Wouldn't it make more sense to line up references with RP for one single site? If there is a way to do that, would you mind sharing it with me (on my talk page, please)? While I understand that for books, the RP displays page numbers inline, but who says the web version has to do that? Why not over a hover with the webpage link for that citation? Let's say we name one that functions similarly as {{Wcp}}, (that is template:wcp). The markup would look like:

{{wcp|http://www.news.com/evil_ killer_convicted}}


Then inline text would look like article text....1.1, so when you hover over the 1.1, it provides the full citation (as any well-done citation does) with a clickable link to that particular article. Does this make sense?

MagnoliaSouth (talk) 19:13, 28 March 2015 (UTC)

{{cite journal}} (and others) : linking supplementary material?

Quite a few papers are accompanied by extra stuff (raw data, full experiment transcripts, elaborated proofs, source code, …, and for conference submissions more and more often talk slides and even recordings.) When reading a paper, having access to these is helpful.

The template currently only supports linking the main paper and a (single?) "laysummary". Adding separate citations for all of these materials isn't really an option – this would clutter the list, or may not fit the format (e.g. in the section "selected bibliography/works" of a person's page.) Leaving out these links means that everyone who's interested has to search for them. (And has to think of searching for these – if the paper doesn't mention the existence of extra materials, this may not happen.)

How should these supplementary materials be handled? (Just ignore that they exist, or include them in some way?)

If they should be included, should the template(s) be extended with extra fields (or a single, free-form-ish one) to accommodate these? (Or is there a better way?)

80.153.23.35 (talk) 01:48, 29 March 2015 (UTC)

You can always just add links to the additional material at the end of the template-generated citation within the <ref>...</ref> tags.
• <ref>{{cite journal ...}} [http://example.org/important-paper/raw-data.html Raw data]. [http://example.org/important-paper/talk-slides.html Talk slides].</ref>
Something like that should work if you customize it to whatever you extra materials you wanted to include. Imzadi 1979  02:06, 29 March 2015 (UTC)

cite arxiv

In considering how best to migrate {{cite arxiv}}, I have answered this feature request. |class= is used in {{cite arxiv}} to append the assigned value to the arxiv identifier. If |arxiv= is empty or omitted, |class= is ignored. There is no error checking of the value assigned to |class=.

Indelicato, Paul (2004). "Exotic Atoms". Physica Scripta T112 (1): 20–26. arXiv:physics/0409058 [physics.atom-ph]. Bibcode:2004PhST..112...20I. doi:10.1238/Physica.Topical.112a00020.

{{cite arxiv}} is an odd duck. In its current guise it is {{cite journal}} without a proper journal title though it uses the {{citation/core}} meta-parameter |Periodical= to hold the external link to the arXiv page.

{{cite arxiv}} has some parameters that are new to Module:Citation/CS1:

1. |class= – mentioned above
2. |eprint= – apparently an alias of |arxiv=
3. |version= – not actually new to the module but used in a different way. In the module, |version= is an alias of |serial= and is used in other CS1/2 templates to identify different versions of things in the rendered citation. In relation to arxiv identifiers, |version= is a suffix on the arxiv identifier that specifies which version of the paper the identifier identifies. I propose to deprecate this parameter in {{cite arxiv}} so that it is included in |arxiv= (arxiv error checking already supports this).
4. |use ampersand before last author= – really, it's there; same as |last-author-amp= so I propose to deprecate it.

Apparently, {{cite arxiv}} can be filled by bot if |title= and all of the |author= parameters are empty and if the citation contains |arxiv= or |eprint=. The bot that does this work isn't identified so if anyone knows which bot that is, and if it is still alive, please tell us so that we can add its name to the documentation.

When editors rely on the bot to fill the template, the template code invokes {{citation/core}} to render a link to the arxiv page with a message saying that a bot will soon fill the template. That won't work so nicely with the module which will emit a missing title error message. This code needs to be rewritten so that the appropriate message is rendered but the module isn't invoked.

I don't quite know yet what to do about the COinS metadata. Currently, this template:

Mashnik, Stepan G. (2000). "On Solar System and Cosmic Rays Nucleosynthesis and Spallation Processes". arXiv:astro-ph/0008382 [astro-ph].

produces this jibberish for rft.jtitle:

&rft.jtitle=%27%27%5B%5BarXiv%5D%5D%3A%5Bhttp%3A%2F%2Farxiv.org%2Fabs%2Fastro-ph%2F0008382+astro-ph%2F0008382%5D%26nbsp%3B%5B%5Bhttp%3A%2F%2Farxiv.org%2Farchive%2Fastro-ph+astro-ph%5D%5D%27%27

This may be a case where we just name the 'journal' arXiv and produce this:

&rft.jtitle=arXiv

For the |arxiv= identifier, the module produces this metatdata:

&rft_id=info%3Aarxiv%2Fastro-ph%2F0008382

which it would also do for {{cite arxiv}} once it has migrated.

Opinions?

Trappist the monk (talk) 15:50, 30 March 2015 (UTC)

The bot that does this work isn't identified – perhaps not well identified, but in the first line under the Usage heading, "a bot" is a piped link to User:Citation bot - Evad37 [talk] 16:04, 30 March 2015 (UTC)
So it does, I've tweaked it.
Trappist the monk (talk) 16:27, 30 March 2015 (UTC)

I've created {{cite arxiv/new}} which mimics the way the current {{cite arxiv}} works. The new version doesn't invoke Module:Citation/CS1/sandbox unless both |title= and |last= (or one of its aliases) are set. In contrast, {{cite arxiv}} always invokes {{citation/core}}. To mimic the old version, the new adds an external link to the output using the value provided in |arxiv= or |eprint=. The output for {{cite arxiv/new |arxiv = physics/0409058}} looks like this:

A bot will complete this citation soon. <small>[http://tools.wmflabs.org/citations/doibot.php?page=Help_talk:Citation_Style_1 Click here to jump the queue]</small>[[Category:Articles with missing Cite arXiv inputs |Citation Style 1]] [[arXiv]]:[//arxiv.org/abs/physics/0409058 physics/0409058].

which renders as (category commented out):

A bot will complete this citation soon. Click here to jump the queue arXiv:physics/0409058.

Trappist the monk (talk) 18:41, 30 March 2015 (UTC)

(e/c) I agree with points 1 through 4 above. I have seen Citation Bot fill in one of these templates recently, so that piece of the system does work. {{Cite doi}} emits a similar message about the bot when you create a new template that contains only a DOI value, although the template is structured differently, with only a single unnamed parameter.
Emitting "arXiv" as the journal may not be appropriate, but I can't tell. Some arXiv articles contain a "journal reference", presumably to indicate that the article, or a version of it, was published in a peer-reviewed journal. Maybe we emit "arXiv" unless |journal= is filled in?
Trappist, thanks for taking on these migrations. I know you get a lot of static for it since you are the main programmer, but I think that the changes that have been made to the CS1 templates over the last two years have dramatically increased the consistency and accuracy of CS1 citations in hundreds of thousands, if not millions, of articles. – Jonesey95 (talk) 18:50, 30 March 2015 (UTC)
If the arXiv article has a journal reference, we should be using {{cite journal}} (with |arxiv= filled in) not {{cite arxiv}} (which should only be for preprints that do not also have a more definitive published form). So I think using "arXiv" as the journal should be ok. —David Eppstein (talk) 19:52, 30 March 2015 (UTC)
I was just coming to that. {{cite arxiv}} has associated categories
Category:Articles with missing Cite arXiv inputs – I suspect that Citation bot uses the content of this category
Category:Articles with a journal parameter in their Cite arxiv templates – can go away and be replace with an error message? add to Category:CS1 errors: arXiv?
Category:Articles with a publisher parameter in their Cite arxiv templates – also goes away?
I think that if either of |journal= or |publisher= is set (or their alias), the module should set them to empty strings, and then emit an appropriate error message. There wouldn't be any periodical in the rendered citation, but the COinS would get &rft.jtitle=arXiv (this parameter usually holds the periodical name).
Trappist the monk (talk) 20:19, 30 March 2015 (UTC)
Perhaps like this, and, perhaps, |url= should be added to the list of parameters not supported by the new {{cite arxiv}}:
 {{ cite arXiv | last=Conte | date=2002 | first=Elio | journal=Proceedings Fundamental problems of Sciences, 271-304, S. Petersburg 2002 | arxiv=0711.2260 | title=A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics | url=http://arxiv.org/abs/0711.2260v1 | class=quant-ph | pages=271-304 | accessdate=3 March 2014 }} Live Conte, Elio (2002). "A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics". arXiv:0711.2260 [quant-ph]. Unsupported parameter(s) in cite arXiv (help) Sandbox Conte, Elio (2002). "A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics". arXiv:0711.2260 [quant-ph]. Unsupported parameter(s) in cite arXiv (help)
Trappist the monk (talk) 21:57, 30 March 2015 (UTC)
In comparison to all of the other CS1/2 templates, {{cite arxiv}} is quite limited in what it supports. Along with the aforementioned |journal=, |publisher=, and |url=, there are |access-date=, |page=, |pages=, and |at=. It does support |format= but shouldn't; it supports all of the usual identifiers but probably shouldn't. I have to think about this some more.
Trappist the monk (talk) 00:00, 31 March 2015 (UTC)
Ok, rather than have the error message list the unsupported parameter(s), I've opted to create a simpler error message. The list of unsupported parameters and an explanation will be available at the Help:CS1 errors. The test for unsupported parameters includes all of the special identifiers (ISBN, doi, etc) but doesn't set them to empty strings.
I've also added an error message for the case where |arxiv= is missing or empty:
 {{ cite arXiv | last=Conte | title=A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics | date=Nov 2007 | first=Elio }} Live Conte, Elio (Nov 2007). "A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics". |arxiv= required (help) Sandbox Conte, Elio (Nov 2007). "A Quantum Like Interpretation and Solution of Einstein, Podolsky, and Rosen Paradox in Quantum Mechanics". |arxiv= required (help)
With that then, I think that this migration is done. See Template:Cite arxiv/testcases and add more if you see something that should be tested.
Trappist the monk (talk) 13:46, 31 March 2015 (UTC)
I have notified Wikiproject Astronomy, Wikiproject Mathematics, and Wikiproject Physics about this discussion. Feedback from the actual users of this template will be helpful. – Jonesey95 (talk) 15:05, 31 March 2015 (UTC)
- I'm not sure if this will just automatically work once {{cite arXiv}} gets migrated, so, just in case: |display-authors= isn't recognized currently, and the citation auto-truncates to 8 authors. Also, I support points 1-4.
- Concerning |journal= or |publisher= in {{cite arXiv}}, I agree with David Eppstein and Trappist - I think it would be better to produce an error message, or at least a maintenance category/message to convert a {{cite arXiv}} to {{cite journal}} (I've seen variants of |publisher=arXiv though..., which could be made to emit an error as well?). If {{cite arXiv}} were to accept |journal=, then it would make sense to duplicate most of the other {{cite journal}} parameters, but I don't think that's the right way to go. I think it'd make more sense to make {{cite journal}} a wrapper around {{cite arXiv}} (if I'm using the term properly), than the other way around. {{cite arXiv}} should be reserved for papers not yet published in a {{cite journal}}. A potential problem is that arXiv eprints are not always word-for-word copies of their published peer-reviewed counterparts, but the differences are generally minor.   ~ Tom.Reding (talkcontribsdgaf)  16:28, 31 March 2015 (UTC)
Setting |displayauthors=4 seems to work in the new version; as an example I've added |publisher=Publisher (should show an error):
 {{ cite arXiv | author8=Bertaux, J.-L. | author6=Pepe, F. | author9=Bouchy, F. | class=astro-ph.EP | author5=Ségransan, D. | author7=Benz, W. | author4=Udry, S. | eprint=1109.2497 | displayauthors=4 | author=Mayor, M. | date=2011 | author14=Santos, N. C. | author13=Queloz, D. | publisher=Publisher | title=The HARPS Search for Southern Extra-solar Planets XXXIV. Occurrence, Mass Distribution and Orbital Properties of Super-Earths and Neptune-mass Planets | author12=Mordasini, C. | author11=Lo Curto, G. | author2=Marmier, M. | author10=Dumusque, X. | author3=Lovis, C. }} Live Mayor, M.; Marmier, M.; Lovis, C.; Udry, S. et al. (2011). "The HARPS Search for Southern Extra-solar Planets XXXIV. Occurrence, Mass Distribution and Orbital Properties of Super-Earths and Neptune-mass Planets". arXiv:1109.2497 [astro-ph.EP]. Unsupported parameter(s) in cite arXiv (help) Sandbox Mayor, M.; Marmier, M.; Lovis, C.; Udry, S. et al. (2011). "The HARPS Search for Southern Extra-solar Planets XXXIV. Occurrence, Mass Distribution and Orbital Properties of Super-Earths and Neptune-mass Planets". arXiv:1109.2497 [astro-ph.EP]. Unsupported parameter(s) in cite arXiv (help)
To convert {{cite arxiv}} to {{cite journal}} (once the paper has been published) is a simple matter of changing the template name and adding or deleting the relevant details – as you say, the preprint may not accurately reflect the final published paper.
Trappist the monk (talk) 16:50, 31 March 2015 (UTC)

In the COinS, the module version will report the title's genre as &rft.genre=preprint. The change to support this may allow us to refine COinS data for the other CS1 templates.

Trappist the monk (talk) 11:17, 6 April 2015 (UTC)

Forgive me if I'm being stupid, but isn't it always better to use {{cite journal|arxiv=xxx}} than {{cite arxiv|eprint=xxx}} anyway? In the former case Citation bot automatically fills out the journal details if and when the preprint is published, and it ensures full compliance with all the normal formatting used by {{cite journal}} and support for all the existing parameters. Is there any reason to maintain a separate template for this? It seems rather pointless to duplicate everything. Could {{cite arxiv}} not be deprecated entirely, or converted into a simple wrapper for {{cite journal}}? Modest Genius talk 22:11, 9 April 2015 (UTC)

Are you sure about that? {{cite journal}} doesn't have the auto-filling-by-bot code that {{cite arxiv}} has. Infact, creating a {{cite journal}} with just |arxiv= creates missing or empty title errors.
If an editor is citing a paper that hasn't been published, or if the editor is citing a version of the paper that is a preprint (because that's the WP:SAYWHEREYOUGOTIT paper) and not citing the published version, then the editor is correct to use {{cite arxiv}}. According to the arXiv article, some papers never make it out of preprint so, for those papers ever languishing in the arXiv limbo, {{arxiv}} is the correct template.
Trappist the monk (talk) 22:54, 9 April 2015 (UTC)
Whenever I use a {{cite journal}} I enter a single ID and then hit 'expand citations'. The bot is supposed to do it after some time if I forget to hit the button, but I haven't tested whether that's working in practice. If it's a preprint that hasn't been published yet the template still works fine so long as e.g. the title gets filled out by the bot.
I'm unconvinced by the need to specifically cite the preprint rather than the final publication, because a) many editors read the arxiv version simply because that is the green open access copy of the final publication (rather than a preliminary version) and thus citing the real thing is preferably (as there are many other ways of accessing it) and b) If some claim was present in a pre-reviewing arxiv posting but not in the final publication then must have been found to be deficient during the peer review process, so we really shouldn't be citing it.
Of course I still might be missing something here. Modest Genius talk 23:22, 12 April 2015 (UTC)
Update: I just did a quick sandbox test, and it was in fact the bibcode that behaves the way I was thinking, not the arxiv ID (which I had to add manually). Note however that the formatting of the final result was superior in the {{cite journal}} case, whilst the {{cite arxiv}} ended up with the wrong year of publication(!) but had a nicer clickable link. It's unclear to me whether it would be easier to get Citation bot to look up arxiv IDs in {{cite journal}}, or make changes to {{cite arxiv}} to mirror all the other desired functionality. I suspect the former but am no expert on bots. Modest Genius talk 23:34, 12 April 2015 (UTC)
There is no facility in {{cite journal}} to notify Citation bot that a journal citation needs to be completed. That facility does exist for {{cite arxiv}}; the template leaves you a message in the article telling you: "A bot will complete this citation soon." The template also gives you a link to click if you want it done now. {{cite journal}} does not do this.
Whatever problems you are having with auto-filling are problems with the tool you are using, not with {{cite arxiv}} or {{cite journal}}. My guess for the different dates is that it's simply a matter of where the tool goes to get the data. Following the Bibcode link at your sandbox example takes you to a page that lists publication date as 02/2013; similarly, following the arXiv link takes you to a page that identifies the v1 version date as 30 October 2012. It would appear that the tool acted correctly.
Your sandbox example makes no use of {{cite arxiv}} so it is not clear to me how you can make any claims that it is better or worse than {{cite journal}}.
If an editor uses material found at arXiv in support of assertions made in a Wikipedia article, that is the source that should be cited. If the editor uses material found in a journal in support of assertions made in a Wikipedia article, that is the source that should be cited. The two may be identical; they may not. If the editor has read one but not the other, it is inappropriate to identify the unread material as the source supporting the Wikipedia article. Is this not what WP:SAYWHEREYOUGOTIT is all about?
Trappist the monk (talk) 00:35, 13 April 2015 (UTC)
The 'tool' I'm using is just citation bot. Yes cite arxiv does give you a handy link to it, whilst cite journal does not (I mentioned this above), but the bot fills both out eventually anyway. The year is incorrect because it gave volume and page numbers that didn't exist until 2013 - in this case 2012 would refer to the preprint only and not the final journal publication. Oh and yes I did use cite arxiv, it's just that when the bot fills it out it changes it to cite journal. It seems that cite journal is better for some things, and cite arxiv better for others. Surely combining the best bits into a single template is easier to maintain than two separate but very similar templates? Modest Genius talk 17:43, 13 April 2015 (UTC)
So you did; I missed the (4 intermediate revisions by 2 users not shown) text.
The bot clearly fetches some information from the arXiv page which you can see if you compare the completed template page parameter with the page information at the arXiv page. But, this talk page isn't about Citation bot; if it is fetching incorrect information, regardless of the CS1 template being used, that topic should be raised at the bot's discussion page because it won't be solved or addressed here.
I don't have a problem with the notion of combining the best bits into a single template when it makes sense to do so. But, here we have one template designed to cite published work and another designed to cite unpublished work. These two templates are to my mind, serving sufficiently different purposes to remain separate.
Trappist the monk (talk) 13:41, 14 April 2015 (UTC)

multiple language support

One of the biggest contributors to Category:CS1 maint: Unrecognized language is multiple languages in the |language= parameter. I have tweaked Module:Citation/CS1/sandbox so that |language= now accepts a comma-delimited list of language names – either as ISO639-1 code or spelled-out (or a mix of both) – and renders a properly formatted language list:

 {{ cite book | language=nb, french , de,lt | title=Title }} Live Title (in Norwegian Bokmål, French, German, and Lithuanian). Sandbox Title (in Norwegian Bokmål, French, German, and Lithuanian).

Names or codes that aren't recognized are rendered as presented:

 {{ cite book | language=nb, Basilisk, de,lt, xt | title=Title }} Live Title (in Norwegian Bokmål, Basilisk, German, Lithuanian, and xt). Sandbox Title (in Norwegian Bokmål, Basilisk, German, Lithuanian, and xt).

Trappist the monk (talk) 18:34, 31 March 2015 (UTC)

This is a great idea. Based on poking through this category, I would like to see an option for an "and" between the last two languages accepted as valid. That would make the following examples valid:
• |language=German, French
• |language=German and French
• |language=German, Swedish, French
• |language=German, Swedish, and French
• |language=German, Swedish and French
But this would not be valid, since it is not valid grammar:
• |language=German, and French
I think it reads much better to use "and" after the introductory "In" before the language names, and based on what I see in the maint category, I believe that other editors feel the same way. – Jonesey95 (talk) 19:52, 31 March 2015 (UTC)
Ok, but ... Formatting of the rendered citation is the responsibility of the template. So, the rule for inside the raw template is: comma separate the languages and the module will add appropriate punctuation and interstitial words:
Title (in German).
Title (in German and French).
Title (in German, Swedish, and French).
Title (in German, Swedish, French, and Spanish).
Trappist the monk (talk) 20:58, 31 March 2015 (UTC)
That seems reasonable to me, though it might be interesting to track the usage of "and". --Izno (talk) 21:53, 31 March 2015 (UTC)
I can live with that and will be happy to document it in the shared template documentation. Once the code is live, a bot or AWB script can be used on the existing 6,200 articles in the main category to remove the existing instances of "and" and replace them with commas. I hope Trappist or GoingBatty or another AWB expert will be willing to do that. – Jonesey95 (talk) 00:23, 1 April 2015 (UTC)
Good change. Howevever, since the template doesn't recognize "xt" in the second example, shouldn't the template still cause the page to be added to Category:CS1 maint: Unrecognized language/emit the error? --Izno (talk) 21:53, 31 March 2015 (UTC)
The module doesn't categorize pages from the Help namespace. When this example:
{{cite book |title=Title |language=nb, Basilisk, de,lt, xt}}
is placed in a mainspace page you get this additional hidden output:
<span class="citation-comment" style="display:none; color:#33aa33">CS1 maint: Unrecognized language ([[:Category:CS1 maint: Unrecognized language|link]])</span>[[Category:CS1 maint: Unrecognized language]][[Category:CS1 Norwegian Bokmål-language sources (nb)]][[Category:CS1 German-language sources (de)]][[Category:CS1 Lithuanian-language sources (lt)]]
Trappist the monk (talk) 22:09, 31 March 2015 (UTC)
Ah, the error just isn't turned on. --Izno (talk) 22:14, 31 March 2015 (UTC)
The maintenance messages are controlled by the same mechanism that turns on all error messages. See Help:CS1 errors#Controlling error message display; which I need to update because that's the only way to see them.
Trappist the monk (talk) 22:37, 31 March 2015 (UTC)

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.
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.
Trappist the monk (talk) 21:22, 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)
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)
[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.
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)
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 (talkcontribsdgaf)  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)

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.
|display-authors=1Last1, First1. Title.
|display-authors=moreLast1, First1. Title. Invalid |display-authors=more (help)
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 (talkcontribsdgaf)  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. Invalid |display-authors=blahblahblah (help)
Nice work, Trappist. – Jonesey95 (talk) 02:02, 3 April 2015 (UTC)
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 and etal regardless of case. We should choose one. |display-editors= does not yet have this functionality.
|display-authors=moreLast1, First1. Title. Invalid |display-authors=more (help)
|display-authors=etalLast1, First1 et al. Title.
|display-authors=1Last1, First et al. Title.
|display-authors=Last1, First; Last2, First2 et al. Title.
|display-authors=blahblahblahLast1, First1. Title. Invalid |display-authors=blahblahblah (help)
Trappist the monk (talk) 11:09, 3 April 2015 (UTC)
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=moreLast1, First1 (ed.). Title. Invalid |display-editors=more (help)
|display-editors=etalLast1, First1 et al. (eds.). Title.
|display-editors=1Last1, First1 et al. (eds.). Title.
|display-editors=Last1, First1; Last2, First2; Last3, First3 et al. (eds.). Title.
|display-editors=Last1, First1 et al. (eds.). Title.
|display-editors=Last1, First1; Last2, First2 et al. (eds.). Title.
|display-editors=blahblahblahLast1, First1 (ed.). Title. Invalid |display-editors=blahblahblah (help)
We need to remember to revisit this code when Category:Pages using citations with old-style implicit et al. in editors has been cleared.
The code now uses the plural editor annotation whenever et al. is part of the rendered list.
Trappist the monk (talk) 12:56, 3 April 2015 (UTC)

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.
Trappist the monk (talk) 12:56, 3 April 2015 (UTC)

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=etalLast1, First1 et al. Title.
|display-authors=et alLast1, First1 et al. Title.
|display-authors=etal.Last1, First1 et al. Title.
|display-authors=et al.Last1, First1 et al. Title.
|display-authors=''etal''Last1, First1 et al. Title.
|display-authors=''et al''Last1, First1 et al. Title.
|display-authors=''etal.''Last1, First1 et al. Title.
|display-authors=''et al.''Last1, First1 et al. Title.

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 type et al or et 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.
Trappist the monk (talk) 16:57, 5 April 2015 (UTC)

Putting multiple authors or editors (an author list) into a single parameter should be deprecated

Putting multiple authors or editors (an author list) into a single parameter should be deprecated, as it muddles the metadata and (in that such a list is displayed however the editor formats it) can conflict with how the template displays the rest of the data. It also invites short cuts like where an editor copy-pasts the entire author/editor list into a single parameter (often including the footnote numbering of the original document. While this last is often a useful indication of sub-par editing, it really should not be encouraged. If we must have some kind of 'author-list' option it should be conditioned on having at least four 'lastn/firstn' parameters.
Which gets back to how much typing is needed. If your pdf (like many) is only an image of text, all you can copy is bits of image. To get text you have to either run it through decent OCR software, or type it in your self. Though if you have some other kind of identifier you might be able to find the bibliographic data on-line. Once you have text the insertion of parameter code can be done with some adroit search-and-replace editing. Or with a script. If you don't want to type in (say) 40 author names, fine, you only have type in one more than the number of authors you want to display.
Important note re COinS: standard cataloging practice is that works with many authors are identified by the first three authors. Don't count on COinS finding "Smith, Jones, and Brown, 2007" at someone's local library if all you give it is "Smith 2007". Incomplete data is a form of corrupted data, as is muddled data. ~ J. Johnson (JJ) (talk) 21:04, 2 April 2015 (UTC)
I have added a header to the above comment, since it is really a new conversation about policy, not a continuation of the conversation about how to allow editors to make "et al." display without resorting to lame hacks.
As for the substance of the comment, I am generally in agreement, but there are some around here who will CITEVAR you until you are blue in the face. One disadvantage of typing multiple authors is that it makes harv referencing more challenging and time-consuming. – Jonesey95 (talk) 02:02, 3 April 2015 (UTC)
It still amazes me that CITEVAR is used to protect lazy editing. ~ J. Johnson (JJ) (talk) 22:03, 3 April 2015 (UTC)
It still amazes me that people think we should make our citation templates even harder for new editors to use and even less forgiving of sloppy usage by new editors. I'm all for wikignomes or bots cleaning up author parameters and splitting out the separate authors and the different parts of authors names, so we get better metadata and more consistent formatting. However, it's easier to start out using this parameter and then later once you're more familiar with the templates learn to separate the names out properly. It's also worth noting that there are some citations where author= is the correct parameter to use; for instance this week I had occasion to use |author=Editorial board (for an unsigned editorial in an academic journal). —David Eppstein (talk) 22:43, 3 April 2015 (UTC)
Laziness is not the issue. Scripts such as WP:REFTOOLS can easily produce bloated "first1, last1, first2, last2, ..." parameter lists. The issue is how to avoid this unnecessary parameter bloat. The {{vcite2 journal}} template and the |vauthors= parameter which puts multiple authors in a single parameter and produces clean metadata. The citation-template-filling tool produces citations formatted in this style. If the author list is comma limited, why do we need to split authors into separate parameters? Lua scripts such as Module:ParseVauthors can easily parse a comma limited author list. Boghog (talk) 22:50, 3 April 2015 (UTC)
I agree regarding author (singular), but what we are talking about here are the plural forms. If we have robust tools for parsing such lists they should be made available. (Perhaps any attempt to use an authors/editors parameter should pop up a link to suh a tool. At the least be flagged for maintenance.) But it is not simply a newbie issue: I've seen cases where an editor just did not want to take the trouble to clean-up an author list, let alone split it. Or thought such sloppiness was good enough for Wikipedia. ~ J. Johnson (JJ) (talk) 23:23, 3 April 2015 (UTC)

deprecated |authorsn and |editorsn

These two parameters nave never made sense to me, were not part of the {{citation/core}} versions of the various CS1/2 templates so I propose to deprecate them at the next update.

Title. Unknown parameter |authors1= ignored (help); Unknown parameter |editors1= ignored (help); Unknown parameter |editors2= ignored (help); Unknown parameter |authors2= ignored (help)

Trappist the monk (talk) 17:12, 2 April 2015 (UTC)

I don't recall ever seeing or using these. But can we have some statistics on how many articles actually use them, before deciding on deprecation? —David Eppstein (talk) 18:05, 2 April 2015 (UTC)
For |authorsn=:
insource:/\| *authors1/ finds 4 instances
insource:/\| *authors2/ finds 12 instances
insource:/\| *authors3/ finds 2 instances
insource:/\| *authors4/ finds 3 instances
insource:/\| *authors5/ finds 2 instances
insource:/\| *authors6/ finds 1 instance
From Epigenetics of autism is this malformed citation that accounts for single finds when looking for |authors6=|authors9=:
{{cite journal |authors=Davies|title=Xlr3b is a new imprinted candidate for X-linked parent-of-origin effects on cognitive function in mice|journal=Nature Genetics |volume=37|pages=625–629|year=2005|authors2=W.|authors3=Isles|authors4=A.|authors5=Smith|authors6=R.|authors7=Karunadasa|authors8=D.|authors9=Burrmann|display-authors=20|doi=10.1038/ng1577|pmid=15908950|issue=6}}
Davies (2005). "Xlr3b is a new imprinted candidate for X-linked parent-of-origin effects on cognitive function in mice". Nature Genetics 37 (6): 625–629. doi:10.1038/ng1577. PMID 15908950. Unknown parameter |authors2= ignored (help); Unknown parameter |authors8= ignored (help); Unknown parameter |authors7= ignored (help); Unknown parameter |authors3= ignored (help); Unknown parameter |authors9= ignored (help); Unknown parameter |authors4= ignored (help); Unknown parameter |authors6= ignored (help); Unknown parameter |authors5= ignored (help)
Changing |authorsn= to |authorn= reveals that the module doesn't understand something about |authorsn=:
Davies; W.; Isles; A.; Smith; R.; Karunadasa; D.; Burrmann (2005). "Xlr3b is a new imprinted candidate for X-linked parent-of-origin effects on cognitive function in mice". Nature Genetics 37 (6): 625–629. doi:10.1038/ng1577. PMID 15908950.
I stopped looking at
insource:/\| *authors10/ finds none
For editors:
insource:/\| *editors1/ finds 1 instance
insource:/\| *editors2/ finds 1 instance
insource:/\| *editors3/ finds none in use
The insource: search appears to be somewhat crippled. It failed to return any results with these search strings:
insource:/\| *authors\d/
insource:/\| *editors\d/
Trappist the monk (talk) 19:44, 2 April 2015 (UTC)
I didn't even know we had "authorsn" parameters. They certainly don't make sense (multiple lists of authors??). I say delete them. As there are so few instances I would be willing to convert all the "authorsn" to "authorn". ~ J. Johnson (JJ) (talk)
Wow. This was so weird, I had to double check that lists of authors was actually a thing that worked. Looking at the history, I'm pretty sure I created that functionality by accident. A extra misplaced "#" in the parameter lists. Mea culpa. I agree with getting rid of it. Dragons flight (talk) 21:21, 2 April 2015 (UTC)
I'm usually a proponent of moving slowly on changes like this, but this looks like typos all the way down. We should just change this to unsupported instead of deprecating it. I'll be happy to work with J. Johnson (JJ) to clean these up before we roll out the changes to the module. – Jonesey95 (talk) 02:06, 3 April 2015 (UTC)
Ok, I've killed them.
Trappist the monk (talk) 10:45, 3 April 2015 (UTC)

It looks like all instances of |authorsn= and |editorsn= have been cleaned up, according to an insource search. – Jonesey95 (talk) 13:03, 3 April 2015 (UTC)

I just finished the last one now, assuming no more exist beyond |authors10= and |editors3=. |authorsn/editorsn= should still be made to emit errors, or at least aliased, in case they appear in the future.   ~ Tom.Reding (talkcontribsdgaf)  15:05, 3 April 2015 (UTC)
There are error messages for the citation in the first post of this discussion. Do you not see them?
Trappist the monk (talk) 15:26, 3 April 2015 (UTC)
Whoops, all good.   ~ Tom.Reding (talkcontribsdgaf)  15:33, 3 April 2015 (UTC)

|accessdate= checking

Following up on this feature request, I have added code to Module:Citation/CS1/Date validation/sandbox that constrains valid accessdates to the dates that fall between 15 January 2001 UTC and tomorrow's date UTC.

"Title". Retrieved 2001-01-14. Check date values in: |accessdate= (help)
"Title". Retrieved 2001-01-15. – Wikipedia start date
"Title". Retrieved 2001-01-16.
"Title". Retrieved 2015-04-27.
"Title". Retrieved 2015-04-28. – today's date
"Title". Retrieved 2015-04-29. – tomorrow's date
"Title". Retrieved 2015-04-30. Check date values in: |accessdate= (help) – day-after-tomorrow's date

Trappist the monk (talk) 19:01, 2 April 2015 (UTC)

It doesn't seen to be working for tomorrow's UTC date.
Trappist the monk (talk) 19:53, 2 April 2015 (UTC)
{{cite web/new |title=Title |url=//example.com |accessdate=2015-04-03}} displays as
"Title". Retrieved 2015-04-03. Check date values in: |accessdate= (help) [Link icon and colors not reproduced.]
in the UTC-4 time zone at 16:05 UTC-4. Jc3s5h (talk) 20:08, 2 April 2015 (UTC)
The comparison date-times for today (2015-04-02 UTC as write this) are 2001-01-15T00:00:00 UTC (Wikipedia start date) and 2015-04-03T00:00:00 UTC (tomorrow). The code produces an error message when the access date comparison value date-time (2015-04-03T00:00:00 UTC for your example) is not between those two date-times. In about an hour and a half, your example citation should no longer produce an error because 2015-04-03 will have become today UTC. Right?
{{cite web/new |title=Title |url=//example.com |accessdate=2015-04-03}}
"Title". Retrieved 2015-04-03.
The above citation is showing an error as of the date and time of my signature.
Trappist the monk (talk) 22:28, 2 April 2015 (UTC)
For completeness, at 2015-04-03T00:08 UTC the above citation was no longer showing an error message (after a null edit).
Trappist the monk (talk) 00:16, 3 April 2015 (UTC)
I think the point is more that people in early time zones will expect their date to work consistently, so the check should allow anything up to and including UTC today + 1. Dragons flight (talk) 22:50, 2 April 2015 (UTC)
Yeah, can be done. The test then becomes:
Wikipedia start date <= accessdate < today + 2 days
which is:
2001-01-15T00:00:00 UTC <= <accessdate>T00:00:00 UTC < 2015-04-30T00:00:00 UTC
So the full 24 hours of Wikipedia start date UTC and the full 24 hours of tomorrow UTC.
I'll tweak the code tomorrow UTC.
Trappist the monk (talk) 23:28, 2 April 2015 (UTC)
Tweaked and I've tweaked the examples above.
Trappist the monk (talk) 00:16, 3 April 2015 (UTC)

please rephrase your reply to not use the word between. Please choose among the phrases less than, less than or equal to, greater tha, and greater than or equal to. I agree with Dragons flight that since time zone designations are not normally included with accessdate, an access date should be considered valid if 15 January 2001 <= accessdate <= the least date in progress anywhere in the world at the time the check is made. Jc3s5h (talk) 23:12, 2 April 2015 (UTC)

Trappist the monk (talk) 23:28, 2 April 2015 (UTC)
Yes, thanks. Jc3s5h (talk) 23:37, 2 April 2015 (UTC)

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.
Trappist the monk (talk) 00:21, 3 April 2015 (UTC)
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://twitter.com/Pigsonthewing/status/564068436633214977. Missing or empty |title= (help)
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)

──────────────────────────────────────────────────────────────────────────────────────────────────── I've adjusted the sandbox version again, see the new testcases page. In addition to |retweet= as mentioned above, changes include:

1. 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
2. |author-link= added, so the author can be linked to their Wikipedia page
3. |title= added, for specifying a title for the tweet. Defaults to 'Tweet Number ...' if not specified.
4. Access date now only set by |access-date= or |accessdate=, not by |date=
5. |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
6. 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)
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)
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:
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)

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
1. {{Cita news}} – uses {{cite news}}
2. {{Citar web}} – uses {{cite web}}
3. {{Cite Merck Index}} – uses {{cite web}}
4. {{Cite tweet}} – uses {{cite web}}
5. {{Cite video game}} – uses {{cite journal}}
6. {{Cytuj stronę}} – uses {{cite web}}
7. {{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
1. {{Cite doi}} – transcludes bot-created {{cite journal}} templates
2. {{Cite hdl}} – transcludes other prefilled templates that may or may not be CS1 templates
3. {{Cite isbn}} – transcludes other prefilled templates that may or may not be CS1 templates
4. {{Cite jstor}} – transcludes bot-created {{cite journal}} templates
5. {{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
1. {{CitePMIDs}} – bundles {{cite pmid}} in {{#tag:ref}}; sort of an {{sfnmp}} for PMIDs
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.
Trappist the monk (talk) 15:36, 4 April 2015 (UTC)

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

[//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):

[//example.com ''Whaam!''].Whaam!.
''[//example.com Whaam!]''.Whaam!.

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!'' &#91;''Wham!''&#93;.

|trans-title= with |title-link=:

''[[Whaam!|Whaam!]]'' &#91;''Wham!''&#93;.

|trans-title= with |url=:

[//example.com ''Whaam!'' &#91;''Wham!''&#93;].

And this same for |chapter= and |trans-chapter=:

"Baam?" &#91;Bam?&#93;.

when |chapter= is wikilinked:

"[[Baam?]]" &#91;Bam?&#93;.

|chapter-url=

[//example.com "Baam?" &#91;Bam?&#93;].

argh.

Trappist the monk (talk) 13:13, 5 April 2015 (UTC)

Add code tweaks to test external link detection and add |chapter=Baam?:

Lichtenstein, Roy. Whaam!.
Lichtenstein, Roy. "Baam?". Whaam!.

And test these conditions:

!''&#93;. – unlinked trans-title
Lichtenstein, Roy. Whaam! [Wham!].
?&#93;. – unlinked trans-chapter
Lichtenstein, Roy. "Baam?" [Bam?]. Whaam!.

and these:

!''&#93;]. – ext linked trans-title
Lichtenstein, Roy. Whaam! [Wham!].
?&#93;]. – ext linked trans-chapter
Lichtenstein, Roy. "Baam?" [Bam?]. Whaam!.

and these, probably unusual conditions:

!]]''&#93;. – wikilinked trans-title
Lichtenstein, Roy. Whaam! [Wham!].
?]]&#93;. – 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.

 {{ cite book | authors=Authors | last2=Last2 | title=Title }} Old Authors; Last2. Title. Live Last2. Title. Missing |last1= in Authors list (help); More than one of |authors= and |last= specified (help) Sandbox Last2. Title. Missing |last1= in Authors list (help); More than one of |authors= and |last= specified (help)

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:

Last. Title. More than one of |authors= and |last= specified (help)

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:
1. strike |authors#= from |AuthorList-Last=
2. create a new temporary meta-parameter, perhaps |LastFirstAuthors=
3. allow the module to create a list of author names from |lastn=, |firstn=, |authorn=, |author-maskn=, |author-linkn=
4. if both |Authors= and |LastFirstAuthors= are set, choose one (probably |LastFirstAuthors=) and emit some sort of redundant parameter error message
5. strike |authors= from the |last= documentation
6. create new |authors= documentation noting the difference between it and |authorn=
Trappist the monk (talk) 23:30, 5 April 2015 (UTC)
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.
In short, I would change step 4 to read "(probably |Authors=)". I think. – Jonesey95 (talk) 00:24, 6 April 2015 (UTC)
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.
Trappist the monk (talk) 10:52, 6 April 2015 (UTC)

I have implemented items 1–4 from the list above:

{{cite book/new |authors=Authors |last2=Last2 |title=Title}}
Last2. Title. Missing |last1= in Authors list (help); More than one of |authors= and |last= specified (help)
{{cite book/new |author=Author |last2=Last2 |title=Title}}
Author; Last2. Title.
{{cite book/new |author1=Author1 |last2=Last2 |title=Title}}
Author1; Last2. Title.
{{cite book/new |authors=Authors |last1=Last1 |title=Title}}
Last1. Title. More than one of |authors= and |last= specified (help)

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.

 {{ cite book | display-authors=etal | title=Title | authors=Authors }} Live et al. Title. More than one of |authors= and |last= specified (help) Sandbox Authors et al. Title.

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

 {{ cite book | display-editors=etal | editors=Editors | title=Title }} Live Editors (ed.). Title. Sandbox Editors et al. (eds.). Title.

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. Missing |last1= in Editors list (help); More than one of |editors= and |editor-last= specified (help)
{{cite book/new |editor=Editor |editor-last2=Editor Last2 |title=Title}}
Editor; Editor Last2 (eds.). Title.
{{cite book/new |editor1=Editor1 |editor-last2=Editor Last2 |title=Title}}
Editor1; Editor Last2 (eds.). Title.
{{cite book/new |editors=Editors |editor-last1=Editor Last1 |title=Title}}
Editor Last1 (ed.). Title. More than one of |editors= and |editor-last= specified (help)

Trappist the monk (talk) 10:23, 23 April 2015 (UTC)

|Editor= (capital "E") not flagged in {{Cite book}}?

This capitalized |Editor= appears to work just fine. I believe that it should be flagged as unsupported.

 {{ cite book | Editor=James Wilson | publisher=On the Line Inc. | year=2006 | place=Seattle | title=Book about super trains | chapter=All the great shows }} Old "All the great shows". Book about super trains. Seattle: On the Line Inc.. 2006. Live James Wilson, ed. (2006). "All the great shows". Book about super trains. Seattle: On the Line Inc.

I haven't looked at the code yet to see why this capitalized parameter is accepted, but I will do so if I have time.Jonesey95 (talk) 22:01, 5 April 2015 (UTC)

It's on the Whitelist. That's odd. – Jonesey95 (talk) 22:03, 5 April 2015 (UTC)
It's also been in the main module for years; I've just never noticed. It looks like we also allow |Author= and |Ref= and |DoiBroken=, with all other parameters, except for initialisms, in lower case only. I think we should deprecate the capitalized form of all of these parameters. Are they in our documentation anywhere? – Jonesey95 (talk) 22:09, 5 April 2015 (UTC)
The supported alternative capitalizations were each part of one or more of the pre-Lua templates and hence were pulled in to maintain backward compatibility. Dragons flight (talk) 22:24, 5 April 2015 (UTC)
That makes sense. It's been two years since then, however, and I think it's time to bid them farewell. Maybe a maintenance category to ease into this transition? I have a nice AutoEd script that I use to clean up unsupported parameters (usually capitalization and misspelling errors), and it would work just fine on such a category. – Jonesey95 (talk) 22:34, 5 April 2015 (UTC)
insource:/\| *Author *=/ 25 instances
insource:/\| *Editor *=/ 332 instances; |Editor= is used by {{Infobox television episode}}
insource:/\| *Ref *=/ 47 instances; |Ref= is accepted by the {{harv}} family of templates
insource:/\| *DoiBroken *=/ none found
insource:/\| *EditorGiven *=/ none found
insource:/\| *EditorSurname *=/ 2 instances
insource:/\| *Embargo *=/ none found; we might want to think about removing |embargo= in the cases where the embargo has expired
insource:/\| *PPrefix *=/ none found
insource:/\| *PPPrefix *=/ none found
Presumably there are numbered versions: |Authorn=, |Editorn= and perhaps |EditorGivenn= and |EditorSurnamen=.
Given these low numbers, I don't have a problem deprecating the author and editor parameters and killing the others.
Trappist the monk (talk) 23:16, 5 April 2015 (UTC)
I believe that I have fixed all of the instances of the above parameters that needed to be fixed, i.e. they were in citation templates and were populated with a value. It has been my experience that the insource search doesn't always find everything, so there may be a few more that crop up in the deprecated parameter category. – Jonesey95 (talk) 19:55, 11 April 2015 (UTC)

These are now deprecated:

|Author=
|Author#=
|Editor=
|Editor#=
|EditorGiven=
|EditorGiven#=
|EditorSurname=
|EditorSurname#=

and these are invalidated:

|DoiBroken=
|Embargo=
|PPPrefix=

For PMCs with |embargo= that have expired, a new maintenance category:

 {{ cite journal | title=Title | embargo=28 April 2015 | pmc=12345 | journal=Journal }} Live "Title". Journal. PMC 12345. Sandbox "Title". Journal. PMC 12345. embargo expired today
 {{ cite journal | title=Title | embargo=29 April 2015 | pmc=12345 | journal=Journal }} Live "Title". Journal. PMC: 12345. Sandbox "Title". Journal. PMC: 12345. embargo expired today

Trappist the monk (talk) 16:13, 7 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.

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.
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)

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)
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)
Ok, archive and log removed. Are there others that should be added to sandbox and testcases?
Trappist the monk (talk) 11:29, 9 April 2015 (UTC)

Still hidden error messages

These five categories of errors still hide their error messages. Can/should any of these be unhidden?

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:
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 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.
Trappist the monk (talk) 00:19, 10 April 2015 (UTC)

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 Jonesey95, 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.
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.
See Help:CS1_errors#.7Cdisplayeditors.3D_suggested, Help_talk:Citation_Style_1#How_to_use_.22et_al.22.3F, Help_talk:Citation_Style_1/Archive_7#Maintenance_category_messaging
Trappist the monk (talk) 03:03, 13 April 2015 (UTC)
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)
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:

1. migrate {{cite episode}}; discussion
2. migrate {{cite serial}}; discussion
3. fix |type= anomaly in cite map; discussion
4. fix duplicate separator character bug; discussion
5. add |sheet=, |sheets=, and |trans-map= for cite map; discussion
6. migrate {{cite arxiv}}; discussion
7. add support for multiple comma-separated languages in |language=; discussion
8. 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
9. expand accepted character sets for Vancouver style; discussion
10. |display-authors=etal support; discussion
11. |authors= not (and hasn't ever really been) an alias of |lastn=; discussion
12. categorize expired PMC embargoes; discussion
13. do not categorize /sandbox and /testcases subpages; discussion
14. move static text (properties and maintenance category names, default title types) to Module:Citation/CS1/Configuration/sandbox;

Changes to Module:Citation/CS1/Configuration are:

1. add |credits=, |began=, |ended=, for {{cite episode}} and {{cite serial}};
2. add |sheet=, |sheets=, and |trans-map= for {{cite map}};
3. add |class=, |eprint= for {{cite arxiv}};
4. add |archive-format=, |conference-format=, |contribution-format=, |event-format=, |lay-format=, |section-format=, |transcript-format=; discussion; discussion
5. remove Authors# from AuthorList-Last - |authors= not an alias of |last=; discussion
6. remove invalidated |DoiBroken=, |Embargo=, |PPPrefix= (standardizing on the lower case versions of these parameter names); discussion
7. add citation_config.maint_cats table;
8. made all tables local; add uncategorized_subpages, prop_cats, title_types tables;

Changes to Module:Citation/CS1/Whitelist are:

1. add |credits=, |began=, |ended=, for {{cite episode}} and {{cite serial}};
2. add |episode= for cite serial;
3. add |sheet=, |sheets=, and |trans-map= for {{cite map}};
4. add |class=, |eprint= for {{cite arxiv}};
5. add |archive-format=, |conference-format=, |contribution-format=, |event-format=, |lay-format=, |section-format=, |transcript-format=; discussion; discussion
6. invalidated |authorsn= and |editorsn=; discussion
7. deprecated |Authorn=, |Editorn=, |EditorGivenn=, |EditorSurnamen= (standardizing on the lower case versions of these parameter names); discussion
8. invalidated |DoiBroken=, |Embargo=, |PPPrefix= (standardizing on the lower case versions of these parameter names); discussion
9. make all tables local;

Changes to Module:Citation/CS1/Date validation are:

1. add "Christmas" as a valid month/season; discussion
2. 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 (talkcontribsdgaf)  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.
Trappist the monk (talk) 11:40, 12 April 2015 (UTC)
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:
{{cite book/new |title=Title |authors=First Author; Second Author; Third Author}}
First Author; Second Author; Third Author. Title.
nor is |author= (singular)
{{cite book/new |title=Title |author=First Author; Second Author; Third Author}}
First Author; Second Author; Third Author. Title.
nor is |authorn= (also singular)
{{cite book/new |title=Title |author1=First Author; Second Author; Third Author}}
First Author; Second Author; Third Author. Title.
Trappist the monk (talk) 18:42, 16 April 2015 (UTC)
Under "Changes to Module:Citation/CS1/Whitelist" you have:
"7. deprecated |Authorn=, |Editorn= ...."
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)
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)
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)

──────────────────────────────────────────────────────────────────────────────────────────────────── Fixed in the sandbox.

 {{ cite web | title=Title | format=[[Portable Document Format|pdf]] | url=//example.pdf }} Live "Title" (PDF). Sandbox "Title" (pdf).
• "Title" (pdf).|format=[[pdf]]
• "Title" (pdf).|format=pdf

Trappist the monk (talk) 10:57, 19 April 2015 (UTC)

But, just to be a counterpoint:

 {{ cite map | format=[[MrSID]] | year=1930 | url=http://www.dot.state.oh.us/Divisions/Planning/TechServ/TIM/Documents/StateMaps/otm1930a.sid | title=Map of Ohio showing State Routes | author=Ohio Department of Highways }} 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.
Trappist the monk (talk) 12:08, 19 April 2015 (UTC)

With the format added automatically, anything that was using (or rather, misusing) |type=PDF now shows (PDF) twice, eg:

 {{ cite map | type=PDF | title=Title | url=http://www.example.com/example.pdf }} Old Live 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)

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)
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)

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.5110v2 [physics.atom-ph].

Trappist the monk (talk) 18:25, 18 April 2015 (UTC)

AWB volunteer to clean up Category:CS1 maint: Unrecognized language?

Now that multiple languages are recognized in |language=, do we have an AWB-savvy volunteer who can fix up articles in Category:CS1 maint: Unrecognized language?

There are many articles that have multiple valid languages that just need some cleanup, converting usages like "English & German" and "English / German" to comma-delimited format. – Jonesey95 (talk) 23:36, 19 April 2015 (UTC)

I think the code in the module already handles the examples you give above - many of the articles in that maintenance category don't show the green text maintenance tag, and a WP:NULLEDIT clears the article from populating the category. And in the case of usages with English as one of multiple languages, I've found that using a comma-delimited list actually puts it back into another maintenance category.
Consider the following edits of 3D pose estimation (reference #1 in each case) - an article originally with |language=English / German [4] doesn't show a green text tag. If you try to use comma, |language=English, German [5] causes the reference to then receive a green maintenance tag and it goes into Category:CS1 maint: English language specified. Changing to |language=English & German [6] clears the maintenance tag again. Stamptrader (talk) 00:17, 20 April 2015 (UTC)
Interesting. I got the impression from the discussion above that only comma-separated values would be accepted. Two languages (or non-languages) separated by an ampersand or a slash seems to render without emitting an error message, however:
 {{ cite book | language=foo & bar | title=Book title }} Live Book title (in foo & bar). Sandbox Book title (in foo & bar).

 {{ cite book | language=foo / bar | title=Book title }} Live Book title (in foo / bar). Sandbox Book title (in foo / bar).

Something is not quite right here.
And an article in "Latvian and English" should not be placed in Category:CS1 maint: English language specified, in my opinion. A bilingual or mixed-language article should be able to be described as such, even if one of the languages is English. I don't feel strongly about it, though. – Jonesey95 (talk) 03:58, 20 April 2015 (UTC)
The failure to categorize the two above examples is caused by a bug that I introduced when I moved static text out of Module:Citation/CS1 into Module:Citation/CS1/Configuration. Fixed in the sandbox.
Without some opinion either way I left the English language detector code alone. I think it's relatively simple to limit English language categorization to the single language case.
Trappist the monk (talk) 11:12, 20 April 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Over the past few days I ran an AWB script that changed |language= parameters with multiple languages to the comma delimited form on about 1750 pages. I have come to believe that multiple language sources that include English as one of the languages should not add the category Category:CS1 maint: English language specified. I have tweaked the sandbox accordingly.

|language= used to categorize into the same categories as those used by {{icon xx}} templates (Category:Articles with xx-language external links). The {{icon xx}} templates only categorize from article space. As I think about it, this constraint ought not apply to CS1/2. We have a defined set of name spaces that we don't categorize, I see no real reason to treat |language= in a special manner. That being the case, I have adjusted the code so that the |language= uses the same categorization rules as every other parameter.

 {{ cite book | language=en,fr | title=Title }} Live Title (in English and French). Sandbox Title (in English and French).
 {{ cite book | language=en | title=Title }} Live Title (in English). Sandbox Title (in English).

Trappist the monk (talk) 11:57, 24 April 2015 (UTC)

I'm going through this list and I'm not seeing the CS1 maintenance message on some of the pages. For example, Anton incident (last edited 2014) contains |language=English ([http://yle.fi/uutiset/kotimaa/2009/05/stubb_puolustaa_antonin_isaa_ja_konsulaatin_tyontekijaa_740524.html Finnish]) and is currently on the 1st page of Category:CS1 maint: Unrecognized language, yet I fail to see an unknown language error anywhere on the page. My common.css has the appropriate line of code to see maintenance messages, and I've null-edited the page. Is this a bug, a feature, or my fault?   ~ Tom.Reding (talkcontribsdgaf)  21:17, 21 April 2015 (UTC)

The bug that I introduced fails to categorize unrecognized languages. That whole long string is considered to be one language name because there isn't a comma separator.
{{Cite web/new | title = Stubb Defends Father and Consulate in Custody Battle | url = http://www.yle.fi/uutiset/news/2009/05/stubb_defends_father_and_consulate_in_custody_battle_740836.html | publisher = [[YLE]] | date = 15 May 2008 | accessdate = 2009-05-16 | language = English ([http://yle.fi/uutiset/kotimaa/2009/05/stubb_puolustaa_antonin_isaa_ja_konsulaatin_tyontekijaa_740524.html Finnish])}}
"Stubb Defends Father and Consulate in Custody Battle" (in English (Finnish)). YLE. 15 May 2008. Retrieved 2009-05-16.
The bug is fixed in the sandbox.
Trappist the monk (talk) 21:29, 21 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:

 {{ cite book | title=Book title | edition=2nd edition | author=Book author }} Live Book author. Book title (2nd edition ed.). Sandbox Book author. Book title (2nd edition ed.).

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.).
Book author. Book title (2nd ed ed.).
Book author. Book title (2nd Ed. ed.).
Book author. Book title (Edition Grande Plus ed.).
Are there other versions of this that should be detected?
Are there other parameters that should be handled the same way?
Trappist the monk (talk) 11:59, 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 |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)
Yep, these insource: search strings:
insource:/\| *page *= *p/ found 442 instances
insource:/\| *pages *= *p/ found 4334 instances
insource:/\| *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, where n can be any letter nor number, but not when |nopp= is set. So I'll work on that.
Trappist the monk (talk) 12:49, 21 April 2015 (UTC)
Sandbox tweaked. These of various forms of p. and pp.:
|page=123Title. p. 123.
|page=p123Title. p. p123.
|page=pp123Title. p. pp123.
|page=p 123Title. p. p 123.
|page=pp 123Title. p. pp 123.
|page=p.123Title. p. p.123.
|page=p. 123Title. p. p. 123.
|page=pp.123Title. p. pp.123.
|page=pp. 123Title. p. pp. 123.
pages:
|pages=123Title. p. 123.
|pages=p123Title. pp. p123.
|pages=pp123Title. pp. pp123.
|pages=p 123Title. pp. p 123.
|pages=pp 123Title. pp. pp 123.
|pages=p.123Title. pp. p.123.
|pages=p. 123Title. pp. p. 123.
|pages=pp.123Title. pp. pp.123.
|pages=pp. 123Title. pp. pp. 123.
and for page and pages:
|page=page123Title. p. page123.
|page=page 123Title. p. page 123.
|pages=pages123Title. pp. pages123.
|pages=pages 123Title. pp. pages 123.
|page=pagerangeTitle. p. pagerange.
|pages=pagerangeTitle. pp. pagerange.
Shouldn't categorize:
|pages=preface, 123Title. pp. preface, 123.
|page=PrefaceTitle. p. Preface.
|pages=p 123 |nopp=yTitle. p 123.
|page=page 123 |nopp=yTitle. page 123.
Doesn't categorize because at least some of these could be legitimate:
|pages=pA1Title. pp. pA1.
|page=p.A1Title. p. p.A1.
|pages=ppA1Title. pp. ppA1.
|pages=pp.A1Title. pp. pp.A1.
I have also limited the set of allowable parameter values for |nopp= to yes, y, true (case insensitive) because |nopp=no turns off the page prefixes but shouldn't. An insource: search for insource:/\| *nopp *= *[Nn]/ found one instance which I shall fix.
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?
Trappist the monk (talk) 17:26, 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.

Jc3s5h (talk) 17:38, 21 April 2015 (UTC)Q

I have tweaked the code to answer this particular case.
Trappist the monk (talk) 15:46, 24 April 2015 (UTC)
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.
"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.
"Stephenson tunnel saved". The Railway Magazine 154 (1,292). December 2008. p. p 10.
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)

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. 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)

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 [7], 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.
Trappist the monk (talk) 16:18, 25 April 2015 (UTC)
But a URL is specified: in the jstor= parameter. The jstor= parameter generates a link to https://www.jstor.org/stable/40203558, which is the accessed source, to which the accessdate= 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 the url= 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 via jstor= and once via url=.
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)
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?
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.
Trappist the monk (talk) 17:29, 25 April 2015 (UTC)
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)

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)

trans-title / script-title mismatch in Cite episode?

I can't make heads or tails of this one, from Greek Expeditionary Force (Korea):

 {{ cite episode | last=Βασιλόπουλος (Vasilopoulos) | network=[[Alpha TV]] | first=Χρίστος (Christos) | trans_title=Greeks in Korean War | script-title=el:Οι Έλληνες στον πόλεμο της Κορέας | year=2007 | series=Μηχανή Του Χρόνου (The Time Machine) | location=Greece | url=http://www.youtube.com/watch?v=IjP1RqevelU&feature=wa%C2%ADtch-vrec | language=Greek (English subtitles) }} Live Βασιλόπουλος (Vasilopoulos), Χρίστος (Christos) (2007). [Greeks in Korean War] |trans-chapter= requires |chapter= (help). Μηχανή Του Χρόνου (The Time Machine) Οι Έλληνες στον πόλεμο της Κορέας (in Greek (English subtitles)). Greece. Alpha TV. Sandbox Βασιλόπουλος (Vasilopoulos), Χρίστος (Christos) (2007). [Greeks in Korean War] |trans-chapter= requires |chapter= (help). Μηχανή Του Χρόνου (The Time Machine) Οι Έλληνες στον πόλεμο της Κορέας (in Greek (English subtitles)). Greece. Alpha TV.

There's a |script-title= and a |trans_title=, which seem to match, but the error message reads "|trans-chapter= requires |chapter=". – Jonesey95 (talk) 21:38, 27 April 2015 (UTC)

I guess it wants a |title= field (which would contain the romanized title) to put into the |chapter= field of the underlying call. Kanguole 22:30, 27 April 2015 (UTC)

I think that this is a case very much like {{cite encyclopedia}}. |title=, and |trans-title= are promoted to |chapter= and |trans-chapter= internally to get the proper formatting. In this case, there is not |script-chapter= to receive |script-title= so the module thinks that |trans-chapter= is missing |chapter=. I'm not sure why the title text is being rendered after the series text. Further research is required.

Monkbot task 6l made the edit that created this so I've stopped the bot and will disable the script-title functionality for {{cite episode}}. If you find others of this kind, and the edit was made by Monkbot task 6l, reverting the bot is the correct response.

Trappist the monk (talk) 22:52, 27 April 2015 (UTC)