Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
ย ย (Redirected from Template talk:Cite map)
Jump to: navigation, search

Use of at parameter to specify web searches where there is no direct URL to source material.[edit]

I recently added a paragraph to the documentation article "pages" that was subsequently reverted here by User:Redrose64 regarding using the |at= parameter to recreate a web search where this is to only way to retrieve the source material. This usage of the "at" parameter resulted from a discussion at the helpdesk here suggested by User:Thincat. If archived, search for "Best way to cite a FRA Accident report." of February 3, 2017 in the helpdesk archives.

The gist of the situation is this: If the source material can only be seen as the result of a query at a web site, and the resulting page containing the source material does not have a unique URL, how should the citation be written?

It may be that my proposed paragraph did not explain or emphasize the unusual circumstances well enough.--Arg342 (talk) 13:06, 4 February 2017 (UTC)

This is an interesting question. Sometimes you can find or construct a URL for a search, even though the browser doesn't show one, but this may involve interpreting the source HTML for the page in question, which isn't something anyone can do. If I can't find such a URL, then I've generally used a made-up title like "Search for 'XXX'", giving the url for the website's search page. I personally agree that the at parameter would be another way to handle this. It needs to be discussed before Redrose64's reversion is accepted. Peter coxhead (talk) 13:46, 4 February 2017 (UTC)
People's opinions differ, see Wikipedia talk:Citing sources/Archive 37#What do you do when there's no URL?. Thincat (talk) 14:24, 4 February 2017 (UTC)
Arg342's addition doesn't make it clear that the search facility should be provided by the same entity that provides the data. In that case, it's essentially a data base lookup. It wouldn't be appropriate to cite a search performed with a general-purpose search engine such as Google or Bing. Jc3s5h (talk) 15:04, 4 February 2017 (UTC)
That's a good point and it may be the source of the difficulty. I agree we should not cite Google, etc. searches as "references". Thincat (talk) 15:09, 4 February 2017 (UTC)
@Peter coxhead: WP:BRD says that it needs to be discussed before the changes of Arg342 are restored, not that it needs to be discussed before my reversion is accepted. Arg342 was WP:BOLD, I reverted, we're discussing - and until there is consensus here to put it back in, the status quo ante should stand.
@Arg342: It's about verifiability and no original research. People shouldn't be expected to perform their own web searches: can we be certain that one person's search results will be the same as another's? Recent evidence at WP:VPT indicates that it cannot. We don't cite books as "book in Oxfordshire County Libraries" and say to people "go find it yourself" - we give author, title and page at the very least. Yes, people may need to read a whole page of text in a book to find the one sentence that verifies the claim; and equally, when citing from the web, we might give a URL for one of the subpages of a website but nothing more specific - but at least the search is narrowed to a manageable level. --Redrose64 ๐ŸŒน (talk) 23:46, 4 February 2017 (UTC)
@Redrose64: but we're not talking about general searches. As Jc3s5h says, it wouldn't be appropriate to cite a search performed with a general-purpose search engine. We're talking about reliable sources, particularly online databases, that don't readily provide a URL to locate specific bits of information, but only a URL for the search page. If you can see in the browser or work out what the search syntax is for the website, you can use something like: "Search results for Yucca", The Plant List, retrieved 2017-02-05 , where I know that /search?q=item added to the URL for the website is what is needed. But if I didn't know that, I could only provide something like: "Search page", The Plant List, Search for Yucca, retrieved 2017-02-05 . What we're discussing is how to handle this second case. Peter coxhead (talk) 07:48, 5 February 2017 (UTC)
This seems like a useful thing. Is it likely to be stable? โ€ข โ€ข โ€ข Peter (Southwood) (talk): 17:35, 5 February 2017 (UTC)
Another suggestion - archive the results page at archive.org or archive.is and refer to that archived page within the reference. The archived page is static with a permanent, unique URL. -78.147.143.191 (talk) 19:45, 6 February 2017 (UTC)
Do both ({{webarchive}} supports multiple archive sites). In my experience they both have problems with database searches retaining them long term. Even better add a third from Webcite. -- GreenC 20:33, 8 February 2017 (UTC)
I will support the OP proposal if there will be explicit, understandable guidelines in place. Searches at properly managed/curated/maintained databases would be ok, for example โˆ’ I think most commercial/institutional databases would likely pass muster. Proper criteria about when this is allowed may alleviate Redrose64's misgivings regarding the consistency/stability of search results. I suppose it comes down to the management/integrity of the source, which is part of a source's overall reliability. 72.43.99.138 (talk) 17:22, 8 February 2017 (UTC)

Edit request: |script-series and |trans-series[edit]

Could we get {{{script-series}}} and {{{trans-series}}} parameters added to the {{Cite book}} template? Along the lines of {{{script-title}}} & {{{trans-title}}} and {{{script-chapter}}} & {{{trans-chapter}}}. I was surprised it didn't exist when I got an error thrown at Kabukidล Enkyล. Curly "JFC" Turkey ๐Ÿ ยกgobble! 23:03, 5 February 2017 (UTC)

Not done: please establish a consensus for this alteration before using the {{edit protected}} template. Izno (talk) 23:41, 5 February 2017 (UTC)
Iznoโ€”sorry, but isn't that the purpose of bringing it up here? Curly "JFC" Turkey ๐Ÿ ยกgobble! 02:26, 6 February 2017 (UTC)

|script-series and |trans-series for cite book?[edit]

Could we get {{{script-series}}} and {{{trans-series}}} parameters added to the {{Cite book}} template? Along the lines of {{{script-title}}} & {{{trans-title}}} and {{{script-chapter}}} & {{{trans-chapter}}}. I was surprised it didn't exist when I got an error thrown at Kabukidล Enkyล. Curly "JFC" Turkey ๐Ÿ ยกgobble! 23:03, 5 February 2017 (UTC)

Bump? Is there any reason not to include these? Curly "JFC" Turkey ๐Ÿ ยกgobble! 01:14, 10 February 2017 (UTC)
For one citation? Probably not worth the effort. Simply write: |series=Eight Flowers of Ukiyo-e ๆตฎไธ–็ตตๅ…ซ่ฏ or something similar if it's really important to have the script title of the series in the citation. The script versions of the |title= and |chapter= parameters were created because non-Latin scripts should not be italicized and because there can be strange artifacts when the original language is written right to left (most often when digits are part of the title). These two conditions turn out to be rather common (the former much more prevalent than the latter). We do not, for instance, have script parameters for authors which quite often list both the author's name in transcription as well as native script. If we were to add more script parameters, that, it would seem to me, would be where we would consider starting first.
โ€”Trappist the monk (talk) 11:15, 10 February 2017 (UTC)

PMC[edit]

Has anything changed recently with the way |pmc= is handled in {{cite journal}}? Whatamidoing (WMF) (talk) 20:24, 7 February 2017 (UTC)

No.
โ€”Trappist the monk (talk) 20:26, 7 February 2017 (UTC)
Thanks. It seems that we have more of these errors than we used to, and I'm trying to figure out why. A change in the template's tolerance for PMCnnnnn (rather than nnnnn) was one possible explanation. A change to an API somewhere? I don't know yet. Whatamidoing (WMF) (talk) 16:22, 9 February 2017 (UTC)
Module:Citation/CS1 and its succeeding Module:Citation/CS1/Identifiers has never accepted anything for |pmc= except the numeric characters. Similarly, the modules do not accept any 'identifier prefix' (doi, isbn, pmid, etc). There are no plans to change that.
โ€”Trappist the monk (talk) 16:34, 9 February 2017 (UTC)
I don't think PMC error-checking has changed significantly since March 2014, but I could be wrong. I think it's a change to Citoid or some other aspect of Visual Editor (or upstream data, as Whatamidoing (WMF) suggests), hence the Phabricator bug that I submitted. โ€“ Jonesey95 (talk) 19:06, 9 February 2017 (UTC)

Whatever happened to the access lock RFCs?[edit]

A discussion elsewhere prompted me to think about this topic.

Some time ago there was a lot of discussion about adding access signals to cs1|2 citations which discussion resulted in some RFCs. At the end of the RFC comment periods, nothing happened. And then a bot quietly archived the RFCs. So, there they sit, in the archive, unresolved.

So, what are we to do? Nothing? Get the RFCs' sponsor to resurrect them from the archives so that they can be properly closed? Revert the changes to Module:Citation/CS1 etc that support the RFCs? Something else that I haven't thought about?

โ€”Trappist the monk (talk) 12:09, 9 February 2017 (UTC)

Did anybody post a closure request at WP:AN/RFC? --Redrose64 ๐ŸŒน (talk) 12:21, 9 February 2017 (UTC)
One was and it was closed. The other apparently was not and so it remains unresolved.
โ€”Trappist the monk (talk) 12:44, 9 February 2017 (UTC)
I have been observing the WP:AN/RFC backlog for some time and some (very brave) editors seem to work on it. As the second RFC is now on the top of the list, I expect it to be closed in the coming days (weeks?). โˆ’ Pintoch (talk) 13:24, 9 February 2017 (UTC)

I have updated Module:Citation/CS1/sandbox and Module:Citation/CS1/Configuration/sandbox to use the lock images specified in the RFC close. Did I get it right?

Cite book compare
{{ cite book | title=url-access subscription | url-access=subscription | url=//example.com }}
Live url-access subscriptionPaid subscription required. 
Sandbox url-access subscriptionPaid subscription required. 
Cite book compare
{{ cite book | title=url-access registration | url-access=registration | url=//example.com }}
Live url-access registrationFree registration required. 
Sandbox url-access registrationFree registration required. 
Cite book compare
{{ cite book | title=url-access limited | url-access=limited | url=//example.com }}
Live url-access limitedFree access subject to limited trial, subscription normally required. 
Sandbox url-access limitedFree access subject to limited trial, subscription normally required. 
Cite journal compare
{{ cite journal | title=doi-access free | doi-access=free | doi=10.12345/12345 | journal=Journal }}
Live "doi-access free". Journal. doi:10.12345/12345Freely accessible. 
Sandbox "doi-access free". Journal. doi:10.12345/12345โ€ฏFreely accessible. 

Also, why do we need the images in two places? Shouldn't the images in Configuration be sufficient? Not my code so perhaps there is a reason that I'm not understanding.

โ€”Trappist the monk (talk) 13:56, 9 February 2017 (UTC)

I closed the RFCs, but people objected to that. The main message from RFCs that we need to go back to the drawing board with respect to colors (no one is really happy with GBR, and no one is really happy with GYB, although GRB has one more !vote than GYR), that all options have to be available (but aren't mandated) for the URL/identifiers, and that autolinking the title based on the availability of a free official version has consensus. Headbomb {talk / contribs / physics / books} 13:59, 9 February 2017 (UTC)
About the images in two places, you are right: we should only list them in one place. If I am responsible for this mess, then I deserve a trout. It looks like the images in the Configuration file are used for identifiers, the images in the main module are used for title links. I'll try to change the title link code to use the configuration as well. โˆ’ Pintoch (talk) 14:17, 9 February 2017 (UTC)
I have made changes to remove the duplicate lock code so that lock images are only defined in Configuration.
โ€”Trappist the monk (talk) 12:18, 12 February 2017 (UTC)

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜I closed the design RfC and am taking a look at the behavioral RfC. Thanks. Eggishorn (talk) (contrib) 19:03, 9 February 2017 (UTC)

Since aspects B1 and B2 lack consensus after all this time, they should be closed as no consensus and the module reverted in the pre-RFC state. Since the already closed RFC's implementation depends on the aforementioned aspects, it should be treated as a theoretical. 100.33.37.109 (talk) 00:38, 10 February 2017 (UTC)

I agree B2 lacks consensus, but I think that B1 does have enough for a rough consensus. I closed it as overall having a problem because there is a significant body of opinion disputing the whole process. Please see the close for further details. Thanks. Eggishorn (talk) (contrib) 15:11, 10 February 2017 (UTC)

So, what's next? Do we remove the locks-rendering code and remove all the |url-access= and |id-access=? โˆ’ Pintoch (talk) 21:33, 10 February 2017 (UTC)
I would suggest not going backwards but further changes to address the expressed concerns in a new RfC. I would guess that there will not be full agreement with whatever path is chosen, meaning that multiple options will likely be needed. Eggishorn (talk) (contrib) 22:36, 10 February 2017 (UTC)


No, we unrestrict their use on identifiers and urls, deprecate |registration= and |subscription= and go back to the drawing board with the visual design. Less visually aggressive scheme with sane color schemes can be presented in a follow up RFC. E.g.
Lock-green.svg / Lock-gray-alt-2.svg / Lock-red-alt.svg.
Lock-green.svg / Lock-gray-alt-2.svg / Lock-gray-full-alt.svg
In lieu of the 50-50 split vote on
Lock-green.svg / Lock-yellow-alt-2.svg / Lock-red-alt.svg. (main objection: yellow doesn't look yellow, hard for the color blind)
Lock-green.svg / Lock-blue-alt-2.svg / Lock-red-alt.svg. (main objection: blue makes no sense to blue an intermediate level)
Then after that (much simpler, 1 question only) RFC is over, we revisit the autolinking situation.Headbomb {talk / contribs / physics / books} 22:42, 10 February 2017 (UTC)
A fair assessment of the RfC process, and fair recommendations, by Eggishorn. The larger issue is that there is no definite consensus on the use of locks. Without such a consensus, arguing about the color scheme is putting the cart before the horse. Intimately related to implementation is the guidance given to editors by the help page. Such guidance cannot be finalized before a new RfC arrives at a clearer consensus. Until then, the proper thing to do is to rollback the code. 184.75.21.30 (talk) 23:32, 10 February 2017 (UTC)
There is consensus for such locks, although not it's not resounding at the moment. These locks already exist (e.g. templates such as {{closed access}}, {{open access}}, {{subscription required}}, etc.) and have been in the wild for years now, but because there's never been a centralized discussion, it's all very disparate, and the complexity of the case seem to have made many go "that will just complicate things, so oppose" or "too many options, unclear, so oppose". Deprecation, cleaning up weird instances of appending {{open access}} to citations with closed dois when a free url was provided, and streamlining with other templates will make things much easier to address in the future. We haven't covered everything, but the RFC does give us a direction for were we should be heading. We've at least nailed down the body, possibly the shackle, and we know the color scheme left no one truly happy. We also know restrictions on locks is a nope, as is mandating the flagging of non-free sources. So let's implement what we can from the mega RFC, and revisit the few issues we haven't nailed down yet one by one. Headbomb {talk / contribs / physics / books} 23:46, 10 February 2017 (UTC)

This is why, when these RFCs were first proposed, I suggested that they be simple and not run simultaneously. We have the design RFC that closed with some modicum of consensus. But, its closure is muddied somewhat because it is dependent upon the affirmative closure of the behavior RFC. That closure, if I read the closer correctly, calls into question the very existence of these access signals. Specifically, the closer writes:

There is,however, a greater issue: A significant body of opinion has been expressed below that the entire visual status indicator idea is not acceptable. The above assessment must be interpreted in light of this. I would urge that this close is treated as a tentative indication of how the Citation Template processing would work in a new RfC to see if there is significant buy-in to proceed forward. To move forward with the shaky consensus established below would not comport with WP:CONS. Overall, there is not yet significant consensus on implementation of these citation template behaviors. (non-admin closure) Eggishorn (talk) (contrib) 02:42, 10 February 2017 (UTC)

It isn't clear to me how this should be interpreted:

  1. remove whatever implementation has already occurred because "there is not yet significant consensus on implementation"; because a "significant body of opinion has been expressed ... that the entire visual status indicator idea is not acceptable"; because the close is "a tentative indication of how the Citation Template processing would work [if implemented after another RFC]"
  2. do nothing; treat the behavior RFC as 'no consensus' so what has been implemented remains implemented (default).
  3. implement those aspects of the behavior RFC for which the closer found consensus and ignore the "not yet significant consensus on implementation" because access signals are already in use and those aspects that did find consensus are relatively minor changes.
  4. some other interpretation that I haven't thought of?

I, for one, want a resolution that is unambiguous. As I suspect happens in many RFCs, this behavior RFC raised at least one issue not directly asked in the request: should we really be using access signalling? One could argue that because the question of access signal acceptability was not directly asked, many respondents to the RFC did not state an opinion on that specific point so those who did are disproportionately represented in closer's summary.

There haven't been that many changes since the last module update (none that are pressing) but before the next update, I would like this particular issue to have been put to bed.

โ€”Trappist the monk (talk) 14:15, 18 February 2017 (UTC)

The existence and use of the existing parameters |registration=/|subscription=, and templates like {{subscription}}/{{registration}}/{{Password-protected}}/{{Subscription or membership required}}/{{Subscription_or_libraries}}, as well as {{free access}}/{{open access}}/{{closed access}} makes it pretty clear there is consensus to flag access levels. Headbomb {talk / contribs / physics / books} 14:27, 18 February 2017 (UTC)
Yes there is consensus for flagging access requirements. There is no consensus for flagging access requirements via the scheme of icons proposed in the RFC. So this can be put to bed, I think. Remove the unsanctioned (i.e. consensus-lacking) code, and submit a better RFC. Perhaps a series of cascading RFC's, so that each level is agreed upon before further drilling down to finer detail. 65.88.88.126 (talk) 14:17, 22 February 2017 (UTC)

Template:Identifier[edit]

Let's revisit the idea of Template:Identifier meta template. I've done one example in the doc of that template, to show the general idea behind it.

Basically this would be a meta template (or a module) to handle all identifier links done in the style of CS1/2 (see list at User:Headbomb/Sandbox).

So the code for {{doi}} would become something like

{{Identifier
 |link=Digital object identifier
 |display=doi
 |separator=:
 |id={{{1}}}
 |base-url-start=//dx.doi.org/
 |allow-free=yes
 |allow-limited=yes
 |allow-registration=yes
 |allow-subscription=yes
 |access-parameter={{{doi-access|}}}
}}

This way people can use {{doi |10.1234/123465 |doi-access=subscription}} to create doi:10.1234/123465 Lock-red-alt.svg.

The code for {{PMC}} would become something like

{{Identifier
 |link=PubMed Central
 |display=PMC
 |separator= 
 |id={{{1}}}
 |base-url-start=//www.ncbi.nlm.nih.gov/pmc/articles/PMC
 |always-free=yes
}}

This way people can use {{PMC|2907408}} to create PMC 2907408 Lock-green.svg.

The code for {{bibcode}} would become something like

{{Identifier
 |link=Bibcode
 |display=Bibcode
 |separator=: 
 |id={{{1}}}
 |base-url-start=adsabs.harvard.edu/abs/
 |allow-free=yes
 |allow-limited=no
 |allow-registration=mo
 |allow-subscription=no
 |access-parameter={{{bibcode-access|}}}
}}

This way people can use {{bibcode|1974AJ.....79..819H}} to create Bibcode1974AJ.....79..819H Lock-green.svg.

The template/module would include error checking, and could be invoked by both the individual identifier templates, and CS1/2 templates. Headbomb {talk / contribs / physics / books} 00:06, 11 February 2017 (UTC)

Does this discussion really belong here?
โ€”Trappist the monk (talk) 01:19, 11 February 2017 (UTC)
Perhaps this discussion should be moved to Template talk:Identifier. After we get a rough draft template created, we can notify the talk pages of existing identifier templates about the new template to see if there is interest. โ€“ Jonesey95 (talk) 02:14, 11 February 2017 (UTC)
It might not really 'belong here', but ideally we probably want a high-level design discussion, and I don't know how the CS1/2 templates handle identifiers, nor do I know how LUA works. It might be a simple thing to copy-paste code from the template to the meta-identifier template/module, it might not. But certainly people here are the most knowledgeable about these issues, and long-term, a unified/coordinated approach is likely the best.
Plus, I don't know if this would be best handled as a module, or a template, so I'm reluctant to invest much effort in template coding without a clear picture of what we want here. Headbomb {talk / contribs / physics / books} 03:22, 11 February 2017 (UTC)

Month-year access dates[edit]

Delaunay triangulation has a bunch of old |accessdate=April 2010 parameters in its external links section. "April 2010" to me looks like a perfectly valid, if unspecific, date format. But the article is now filled with big red errors saying that the accessdate values need to be checked. Is there a reason this style of date is disallowed in this context? Yes, maybe whoever accessed the links on those dates should have also included the day, but there's nothing to check now about the validity of the dates. They are what they are, and the error message are a waste of reader attention. โ€”David Eppstein (talk) 18:50, 11 February 2017 (UTC)

Whole dates because ephemeral sources can change day-to-day and even hour-to-hour. When used in an external links section, the need for an access date is diminished because that source is supplementary information that is not necessarily used as a reference for the article. The fix then is to remove the |access-date= parameters, or comment them out, or fix the date (this edit 7 April 2010), or validate that the links are correct and useful and replace the existing date with the date of validation โ€“ this last especially when these errors are detected in article-supporting citations.
โ€”Trappist the monk (talk) 19:16, 11 February 2017 (UTC)
Full access dates have been a requirement for a long time. My personal preference among TTM's suggestions above is to validate the web page today and subsequently update the access date to today. There was a bot request at some point within the past half-year for something like IABot to work through this category of errors where some partial date was indicated, but the editors in that discussion didn't get to consensus on the topic. --Izno (talk) 00:49, 12 February 2017 (UTC)
Instead of leading to more precise dates, the actual effect of more-nitpicky error checking in this instance is that yet another editor has given up on using the citation templates and instead switched to manual formatting of the links. โ€”David Eppstein (talk) 02:58, 12 February 2017 (UTC)
But access dates are not used for precision. They are used for (a) source-version identification, which allows (b) verification of the referenced information. Editors must directly and personally check sources. Don't they know the date they did so? If that is the case, by all means do not use CS1. Let's try to keep this system within the verification/reliability policy parameters. 65.88.88.126 (talk) 14:05, 15 February 2017 (UTC)
Presumably the editor who checked the sources in April 2010 knew then what exact date the sources were checked, but it is now 2017 and even that editor has probably forgotten. We can make an estimate by looking at the edit history but that would be using the access date parameter incorrectly, as it is supposed to be a record by the actual editor who checked the sources, not someone else's later guess. โ€”David Eppstein (talk) 16:05, 15 February 2017 (UTC)
An error of +/- 1 day on the access date is much better than an error of up to +/- 30 days, and is what we have anyway because what you check on January 2 for you may have been checked on January 3 for someone else. The error should be thrown for that reason alone. Headbomb {talk / contribs / physics / books} 16:24, 15 February 2017 (UTC)

Give a citation bot link when mandatory parameters are missing, revisited[edit]

No one objected, and a notice was left on the citation bot page for a few months now. I say it's time we implement this. Headbomb {talk / contribs / physics / books} 04:00, 13 February 2017 (UTC)

Requesting new parameter[edit]

Over at c:Template:Cite web, they have a parameter |editor-type=. Recently I cited a website with no author, but a "compiler and annotator". I did it by setting |author= "John Doe (compiler and annotator)" but I couldn't do the cite using format "Doe, John" (|first= |last=) to match other citations on that page, so the new parameter would be helpful. Thanks to anyone who can add it! Vzeebjtf (talk) 06:20, 13 February 2017 (UTC)

We have |others= for this rare case. โ€“ Jonesey95 (talk) 06:50, 13 February 2017 (UTC)
Thank you! Vzeebjtf (talk) 10:07, 13 February 2017 (UTC)

Support multiple DOI, ISBN, MR, OCLC[edit]

I was doing some |id={{foobar}} to |foobar= conversions last night, and there's quite a few cases that I couldn't handle for a lack of support for some cornercase.

Specifically, if you have |id=ISBN 978-1-1234-4567-x, ISBN 978-1-4567-1234-9, you can't convert that to |isbn1=978-1-1234-4567-x |isbn2=978-1-4567-1234-9. These also happens when articles have |id=MR12345, MR54321, MR9876543 or |id=OCLC 012345, 12345, 654321.

Here's an example, taken from Ring (mathematics)

I've seen up to 2 multiple DOIs (usually one for the book, and one for the book chapter), 4 multiple ISBNs (ISBN 10/13 mostly, but also paperback vs hardcover), 3 ISSNs (print, online, cd), 6 multiples MRs (usually for reviews of books), and 10 multiple OCLCs (because the OCLC system is bad at handling dupes). Now you may argue some of this is bad practice, and I certainly would agree to an extent, but some cases are legit and it's nonetheless being done.

So I suggest we allow for

  • |doi#/doi-#=, #=1-2
  • |isbn#/isbn-#= #=1-10
  • |issn#/issn-#=, #=1-3
  • |oclc#/mr-#= #=1-10
  • |mr#/mr-#= #=1-10

with |foobar1/foobar-1= as aliases of |foobar=. Headbomb {talk / contribs / physics / books} 12:23, 13 February 2017 (UTC)

Not a good idea to my mind. The purpose of a citation is to identify the source that the editor used to support a statement in a Wikipedia article. It is not a place to collect links to various versions or editions of the same source. In your miltiple-MR example, there are two different publishers, five different publication dates (all different from the date in the {{citation}} template), different pagination, different editions, different parts, and perhaps more.
The cs1|2 templates are designed to render a proper citation for a single source. If you want to do a bibliography of all of the different versions of a source, do that one cs1|2 template per version, do not attempt to shoe-horn them all into a single template.
โ€”Trappist the monk (talk) 12:50, 13 February 2017 (UTC)
Like I said, I'm not necessarily in favour of putting up multiple MRs/ISBNs etc, but it's being done and there are cases where it's legit to do so. If anything, supporting that at least allows us to track and cleanup such usage if it's found to be undesirable. Headbomb {talk / contribs / physics / books} 12:57, 13 February 2017 (UTC)
When it comes to OCLCs, multiple numbers can be legitimate for the same specific source. As an example, the various annual and semi-annual maps published by the Michigan Department of Transportation (or its predecessor agency) can have up to 3 OCLC numbers. The Library of Michigan uses one number for a group of years lumped together, while other libraries assign a number for each individual map. If we only reference one number for a specific map, a reader may not locate a library near him or her because one institution closer is using one of the numbers. Template:Cite MDOT map/testcases lists all of the various permutations of the maps since 1919 with the appropriate OCLC numbers. Imzadi 1979 โ†’ 13:31, 13 February 2017 (UTC)
Citation templates are designed to cite one specific source. If you want to provide additional information about different versions of a source, it can be placed outside the citation template. โ€“ Jonesey95 (talk) 15:57, 13 February 2017 (UTC)
Yes, but this neglects the fact that one specific source can have multiple identifiers of the same kind. Headbomb {talk / contribs / physics / books} 16:20, 13 February 2017 (UTC)
Yes, but I think we should apply the KISS principle: one identifier of each type is fine. However, this reminds me of the idea to generate citations from Wikidata items which represent a source: in this case, support for multiple identifiers should be easy. (Note that I'm not saying that there is any consensus for such a template.) โˆ’ Pintoch (talk) 17:07, 13 February 2017 (UTC)
So which OCLC number is the "canonical" one to use, if we're supposed to limit to only one OCLC for the 2014 edition of the official state highway map of Michigan, OCLC 42778335 or OCLC 900162490? Different institutions catalog the exact same map under different numbers, yet it's the same resource. Imzadi 1979 โ†’ 17:20, 13 February 2017 (UTC)

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ KISS is my preference too, as far as what I do. And there's a lot of things the template can do that (ISSNs, publishers for journals, etc...) that I don't think should be used. But I don't think we need to insist on being purposefully unfriendly and force people to resort to the extremely awful

instead of the much better

The template should support that and put multiple identifier use in tracking categories. This will both facilitates cleanup in non-legit cases and supports in legit cases. Headbomb {talk / contribs / physics / books} 17:32, 13 February 2017 (UTC)

@Headbomb: one trick that was imparted to me at a WikiConference is to use |id={{OCLC|01234|012345}} , which would merge the two OCLC IDs together ร  la:
It's still a bit of a kludge over having the direct ability to insert two OCLC numbers, but at least it combines them together in the output. Imzadi 1979 โ†’ 18:29, 23 February 2017 (UTC)
Yes that's always possible, but that's a hack, which means in many case you'll have something like
where OCLCs are presented out of sequence (it should appear before the SSRN). Headbomb {talk / contribs / physics / books} 18:35, 23 February 2017 (UTC)

Help on scowiki[edit]

On the Scots Wikipedia, I've been having trouble with CS1, especially the Utilities module. As can be seen at sco:Game Freak, it displays "Lua error in Module:Citation/CS1/Utilities at line 39: bad argument #1 to 'ipairs' (table expected, got nil)". What can I do to fix this? --AmaryllisGardener talk 00:13, 14 February 2017 (UTC)

Looks like you don't have the appropriate version of the Configuration file. The error message appears to be referring to script_lang_codes which doesn't exist in sco:Module:Citation/CS1/Configuration.
โ€”Trappist the monk (talk) 00:29, 14 February 2017 (UTC)
@Trappist the monk: Thank you! I'll get on updating the Config module right away. --AmaryllisGardener talk 00:42, 14 February 2017 (UTC)

{{cite bioRxiv}}[edit]

Could someone help create this?

Basically, it should be very similar to {{cite arXiv}}, except without the "fill this with a bot" code. That is, the supported parameters should be

  • |authors= and variants
  • |date= and variants
  • |title=
  • |biorxiv=
  • |doi= should throw an error, telling people to use |biorxiv= without the '10.1011' part of the doi. If a valid doi that doesn't start with 10.1011 is used, the message should invite users to instead use {{cite journal}}.
  • All other identifiers and parameters should be unsupported.

Headbomb {talk / contribs / physics / books} 17:09, 16 February 2017 (UTC)

Hi Headbomb, I'm not sure I understand the added value of these specific templatesโ€ฆ Isn't it enough to use the |biorxiv= parameter with an existing CS1 template? The same holds for citeseerx below. โˆ’ Pintoch (talk) 17:44, 16 February 2017 (UTC)
This, like {{cite arxiv}} would do two things. It specifically identifies the publication as a preprint, and which would facilitate the bot-maintenance of these templates and general cleanup of the citations. Right now, there's a lot of people doing citations to biorxiv preprints like this (the first is done by putting the URL in the reftoolbar and letting the gadget complete it
Which is not how bioRxiv preprints should be cited. They should be cited as
  • Navarrete, Israel; Panchi, Nancy; Kromann, Peter; Forbes, Gregory; Andrade-Piedra, Jorge (15 February 2017). "Health quality of seed potato and yield losses in Ecuador". bioRxiv 108712Freely accessible. 
You might argue that this can be already be achieved with existing templates like {{cite web}} and {{cite journal}}, but using those templates misleads people into filling unnecessary and undesired parameters.
And if you try letting citation bot expand the doi in a cite journal, you get
  • . doi:10.1101/108712 (inactive 2017-02-16).  Missing or empty |title= (help)
This seems to be generalized to all biorxiv dois, but might be a temporary database issue. However, I have no faith that the crossref information would not polute the citation with extraneous and unecessary information, like putting CSHL as the publisher, biorxiv as the journal, and similar. It would also highjack the doi parameter which should be used for the official version, once published. Headbomb {talk / contribs / physics / books} 17:58, 16 February 2017 (UTC)
Makes sense, thanks for the explanation! โˆ’ Pintoch (talk) 18:12, 16 February 2017 (UTC)
@Pintoch, Trappist the monk, and Jonesey95: can any of you code this? I would, but I know nothing of LUA. I could hack something via an invocation of cite web, but I'd rather not. Headbomb {talk / contribs / physics / books} 12:18, 22 February 2017 (UTC)
Of course, but is there consensus to add yet two more cs1 templates with attendant error messages and categories, documentation, etc?
If the decision is taken to create these templates as cs1 templates, there is a side benefit in that it will force me to finally do the unsupported arXiv parameter test properly because these two templates will require the same sort of error detection.
โ€”Trappist the monk (talk) 12:28, 22 February 2017 (UTC)
The only argument against them really is "but that's more templates to deal with", and I think I've shown pretty conclusively that using the existing ones create lots of issues in the long term, while lots of benefits would come from a dedicated template like {{cite arxiv}}. We might need a {{cite SSRN}} too, but I haven't looked into them much. Headbomb {talk / contribs / physics / books} 12:34, 22 February 2017 (UTC)

{{cite citeseerx}}[edit]

Could someone help create this?

Basically, it should be very similar to {{cite arXiv}}, except without the "fill this with a bot" code. That is, the supported parameters should be

  • |authors= and variants
  • |date= and variants
  • |title=
  • |citeseerx=
  • |doi= should throw an error, telling people to use |citeseerx= instead. If a valid doi that doesn't start with '10.1.1.' is used, the message should invite users to instead use {{cite journal}}.
  • All other identifiers and parameters should be unsupported.

Headbomb {talk / contribs / physics / books} 17:09, 16 February 2017 (UTC)

Access locks on paywalled links: lock color and hover text[edit]

We have some access-lock images which are occasionally used to indicate whether a source is paywalled or not. One of them is File:Lock-red.svg. It's bright red (Lock-red.svg), with a transparent background. The {{cite journal}} source code uses it to indicate paywalled sources.

I don't like the bright red. Why? Because, as Mark viking pointed out six months ago,[1] many paywalled sources let you read the abstract for free, or a page or two for free. Please correct Mark and I if we're wrong, but we think that bright red may imply "you can't read any of this for free". This may mislead our readers, and dissuade them from clicking through and reading abstracts for free.

I think that we should use some color other than bright red.

We could use dark red (like this). And then we could add a white background or white border, to make sure that users reading Wikipedia on a black background would get sufficient contrast. In fact, if you look through the file history of Lock-red.svg, you'll see that it used to be dark red, until it changed to light red this past September.

Or we could use gray (on a transparent background), or black (on a white background), or any other color.

Thoughts?

Kind regards, โ€”Unforgettableid (talk) 02:30, 22 February 2017 (UTC)

The dark red fails one of the criteria we established for the icon designs, to wit: contrast against both white and black backgrounds. This is important for the visually impaired and for those who invert their colors (light text on a dark or black background).
As part of the initial discussions I proposed a series of icons that were all blue; access indicated by the lock shape only. That idea was shot down because others believed that multiple indications of access (shape and color) are better than the single (shape alone).
Before continuing this conversation, might I recommend that you spend some time in the archives of this page reading the discussions that got us to where we are today? I think that the bulk of it begins in Archive 22.
โ€”Trappist the monk (talk) 03:54, 22 February 2017 (UTC)
Dear Trappist: The problem with the old dark-red access lock icon is that it had a transparent background. This made it nearly invisible when the icon was superimposed upon a black webpage. I see four possible workarounds: A) Underlay a white rectangle beneath the dark-red lock. B) Or a white rounded rectangle. C) Or a white oval. D) Or add a thick white outline to the dark-red lock. Even three or four pixels thick, if you want. โ€”Unforgettableid (talk) 02:51, 23 February 2017 (UTC)
Sure, those are work-arounds. But, neither you nor I have the power to change that which was decided by RFC, do we? Without another RFC that overrides the current consensus, the access signals shall have the forms and colors that were determined by the visual design RFC.
โ€”Trappist the monk (talk) 03:56, 23 February 2017 (UTC)
In that RFC, Headbomb offered a choice of multiple colors for the free-access lock and the partial-access lock. But the only color choice he offered for the paywall lock was bright red. (In other words, bright red was the only choice available on the ballot.) Because the ballot offered no choice in the matter, I believe it might be inaccurate to say that the RFC participants agreed to make it bright red. I believe it'd be more accurate to say that the lock ended up bright red by default. โ€”Unforgettableid (talk) 04:27, 23 February 2017 (UTC)
Only one color was offered for the free access lock, green. The only one where there was a choice was the partial access lock, yellow vs blue which left very few people happy. I personally believe Green/Grey/Red will gain support the next time we ask, but it's possibly Green/Grey/Grey will get it too. Green/Blue/Red is a a truly ridiculous scheme that makes zero sense, and people only went for it because the yellow was felt 'not yellow enough' or WP:ACCESS unfriendly. Headbomb {talk / contribs / physics / books} 04:54, 23 February 2017 (UTC)
Look also at the post timestamped at "22:42, 10 February 2017 (UTC)" on this page for possible alternatives, some of which include gray. Headbomb {talk / contribs / physics / books} 12:17, 22 February 2017 (UTC)
That gray is fine, though I still suspect that I prefer dark red. โ€”Unforgettableid (talk) 02:51, 23 February 2017 (UTC)
The dark red would still violate WP:ACCESS. Headbomb {talk / contribs / physics / books} 04:46, 23 February 2017 (UTC)
I've thought of some possible workarounds, and described them, in a comment which you probably haven't read yet. Search through this page for the phrase [ four possible workarounds ] if you'd like to learn about them. I believe that, with the workarounds, dark red is a viable option. โ€”Unforgettableid (talk) 05:52, 23 February 2017 (UTC)
Those aren't viable workarounds. A white rectangle underneath the lock for instance, would look downright awful and be very distracting. Likewise for the other choices. Headbomb {talk / contribs / physics / books} 10:29, 23 February 2017 (UTC)
A) How about a thin white outline, perhaps one pixel thick or a few pixels thick? B) What percent of our readers view Wikipedia on a black background? I suspect that it's a tiny percentage. Shouldn't we care more about making things look nice for the majority than for the minority? โ€”Unforgettableid (talk) 14:39, 24 February 2017 (UTC)
One thing we could possibly add to the hover text is "Paid subscription required, abstract or excerpt may be available" instead of just "Paid subscription required". Headbomb {talk / contribs / physics / books} 12:44, 22 February 2017 (UTC)
Dear @Headbomb: Good idea. In fact, maybe we could provide even more alt text than that. Perhaps this: "A summary or excerpt may be available for free. However, to read the full text, you must either buy access or visit a library with a paid subscription. Try phoning your nearest university library." In addition, perhaps we could even add a dotted underline and a fancy cursor. border-bottom: 1px dotted #000; cursor: help; This would help readers realize that there's useful alt text, and that they should wait a second for it to appear. You can see a live preview of the full package at this link. โ€”Unforgettableid (talk) 02:51, 23 February 2017 (UTC)
That is a ridiculously long message. 'Paid subscription required, abstract or excerpt may be available' covers all of that. I'm not against the cursor/underlining though. Headbomb {talk / contribs / physics / books} 04:45, 23 February 2017 (UTC)
Both you and I have been to university. Also, both you and I both know that we can get free online access to many papers at a university library. But many laypeople don't know this. In fact, even some university graduates don't know this. For those in the know, we're wasting their time by writing so much hover text. But these people can quickly learn what the paywall lock means. They can read the hover text once, understand it, and never feel a need to hover their mouse over a paywall lock ever again. But, for high-school students and other individuals not in the know, we may be opening their eyes (maybe for the first time ever) to vast trove of scholarly knowledge. โ€”Unforgettableid (talk) 06:09, 23 February 2017 (UTC)
It's not a matter of having been to university or not, it's a matter of the message being exceedingly long. This is a message that will need to be read by screen readers several times per article, and thus needs to be short. This is why all the messages are short and to the point, e.g. "Free registration required" instead of "You are required to register to read this article, but it does not cost money to do so. Websites will typically asks for your email and some personal information. You could also ask a friend to register for you, or register with a dummy email if you do not trust the website with your personal information, however this may violate their terms of service. Your password and login information might be stored in a cookie. That being said, an excerpt might still be available to unregistered users."
"Paid subscription required" implies a subscription is required to have access to the full version; it doesn't matter if it's yours, your supervisor's, your friend's or the library's institutional subscription. If you have short wordings, those could be suitable however. But they need to be short, e.g. "Paid or library subscription required, free abstract or excerpt may be available". Headbomb {talk / contribs / physics / books} 10:29, 23 February 2017 (UTC)

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜ Ah OK fair. Your point about screen readers is a good one. Indeed, I looked into the matter just now; and it turns out that screen readers will indeed read out the image's title text in this case. (Source.) And your little speech discussing dummy emails and cookies made me laugh. :) How's this?: "Paid or library access required; but a summary may be available for free. Click for help." โ€”Unforgettableid (talk) 19:05, 23 February 2017 (UTC)

Locks aren't currently clickable and aren't linked to anything. Where would clicking on the lock take people? Headbomb {talk / contribs / physics / books} 19:29, 23 February 2017 (UTC)
There need not be anything clickable for a title= attribute to be used; it is valid on most HTML elements since HTML 4.00, and all elements from HTML5 onward. From the HTML 4.01 spec:

Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title as a "tooltip" (a short message that appears when the pointing device pauses over an object). Audio user agents may speak the title information in a similar context.

Try hovering your mouse here. --Redrose64 ๐ŸŒน (talk) 20:09, 23 February 2017 (UTC)
Re "There need not be anything clickable". The proposed message has "click for help". That's what I'm referring to. Headbomb {talk / contribs / physics / books} 20:38, 23 February 2017 (UTC)
Clicking on the paywall lock could take readers to Wikipedia:Find your source. โ€”Unforgettableid (talk) 14:48, 24 February 2017 (UTC)
MediaWiki copies the image's alt= attribute text into the title= attribute. No need to muck with title= attributes and no need for the image to be clickable.
โ€”Trappist the monk (talk) 20:17, 23 February 2017 (UTC)
Not true: consider the twelve images in Headbomb's post of 22:42, 10 February 2017 (UTC) beginning "No, we unrestrict their use on identifiers and urls" in the section #Whatever happened to the access lock RFCs? - here, all twelve images have the alt= attribute, and none of them have a title= attribute. --Redrose64 ๐ŸŒน (talk) 21:58, 23 February 2017 (UTC)
I think that we are both mistaken. Your mistake: none of those twelve images have alt= attributes โ€“ though some have 'alt' in their name:
[[File:Lock-blue-alt-2.svg|9px]] โ†’ Lock-blue-alt-2.svg
My mistake: MediaWiki does not copy alt= into title=. Rather, it is done in Module:Citation/CS1/Configuration where the lock images are defined like this:
[[File:Lock-green.svg|9px|link=|alt=Freely accessible|Freely accessible]] โ†’ Freely accessible
where the text to the right of the pipe is assigned to the title= attribute.
โ€”Trappist the monk (talk) 23:09, 23 February 2017 (UTC)
They do have alt= attributes. Use your browser's "View page source" feature. Search for the text <img alt="Lock-green.svg" src="//upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/9px-Lock-green.svg.png" You should find six instances, other than the one in this post. All six are identical: the <img /> tag has seven attributes, being (some values replaced with an ellipsis for clarity) alt="Lock-green.svg" src=... width="9" height="14" srcset=... data-file-width="512" data-file-height="813". There is an alt= attribute; there is not a title= attribute. The enclosing <a href="/wiki/File:Lock-green.svg" class="image">...</a> element doesn't have a title= either. --Redrose64 ๐ŸŒน (talk) 01:33, 24 February 2017 (UTC)
So they do. MediaWiki copies the image file name into the alt= attribute. Better that than nothing I suppose.
โ€”Trappist the monk (talk) 11:12, 24 February 2017 (UTC)

cite arxiv unsupported parameters[edit]

It has just occurred to me that we can, with slight modifications, reuse the main parameter validation code to validate the limited list of parameters for {{cite arxiv}}. This method could also carry-over to the newly proposed {{cite bioRxiv}} and {{cite citeseerx}}.

I have created a lists of parameters for {{cite arxiv}} in Module:Citation/CS1/Whitelist/sandbox that are subsets of the basic parameter lists used by all of the other cs1|2 templates. When the module is called, it uses the CitationClass parameter passed to it by the template (in this case arxiv) to determine which of the lists it uses to validate parameters:

Cite arxiv compare
{{ cite arxiv | author4=Usheva A | version=v1 | arxiv=0910.5294 | date=October 2010 | author=Alexandrov BS | journal=Physics Letters A/Physics-Bio PH. | doi=10.1016/j.physleta.2009.12.077 | issue=10 | title=DNA Breathing Dynamics in the Presence of a Terahertz Field | author5=Rasmunssen Kร˜ | volume=374 | author2=Gelev V | author3=Bishop AR }}
Live Alexandrov BS; Gelev V; Bishop AR; Usheva A; Rasmunssen Kร˜ (October 2010). "DNA Breathing Dynamics in the Presence of a Terahertz Field". arXiv:0910.5294v1Freely accessible. doi:10.1016/j.physleta.2009.12.077.  Cite uses deprecated parameter |version= (help); Unsupported parameter(s) in cite arXiv (help)
Sandbox Alexandrov BS; Gelev V; Bishop AR; Usheva A; Rasmunssen Kร˜ (October 2010). "DNA Breathing Dynamics in the Presence of a Terahertz Field". arXiv:0910.5294v1โ€ฏFreely accessible.  Unknown parameter |journal= ignored (help); Unknown parameter |doi= ignored (help); Unknown parameter |volume= ignored (help); Unknown parameter |issue= ignored (help); Cite uses deprecated parameter |version= (help)

One thing that I think that we should add to {{cite arxiv}} is support for |vauthors=.

โ€”Trappist the monk (talk) 14:29, 22 February 2017 (UTC)

|vauthors= should definitely be supported (as should all other |author= variants). I thought it was, but I guess not. Headbomb {talk / contribs / physics / books} 15:21, 22 February 2017 (UTC)
It turns out that |vauthors= is supported by the live template but it was not supported by {{cite arxiv/new}} which is used by {{cite compare}} and which is the version of the template that calls Module:Citation/CS1/sandbox. Fixed.
โ€”Trappist the monk (talk) 12:44, 23 February 2017 (UTC)