Help talk:Citation Style 1/Archive 26

Page contents not supported in other languages.
Source: Wikipedia, the free encyclopedia.
Archive 20 ← Archive 24 Archive 25 Archive 26 Archive 27 Archive 28 → Archive 30

Any updates on adding open access links to references?

For simplicity's sake, I suggest we implement the coloured version of the locks, with |access= (paired for whatever link is in |url=) and |id-access= to append locks after the identifiers (replace 'id' with 'bibcode'/'doi'/etc.). We can then refine the behaviour later after we see what issues come up.

books
} 14:27, 14 September 2016 (UTC)

I totally agree! I think that's what is currently implemented in the sandbox (but only for id=doi, not for the others). We are ready to submit OAbot to
WP:BAG and we can discuss there which icons we want the bot to add (if the current implementation is pushed to live, otherwise there is no discussion to have about that as the bot would not have any option to display the status of the links it adds). − Pintoch (talk
) 21:27, 14 September 2016 (UTC)
I also agree that the colored versions are more intuitive and also more consistent with usage outside of Wikimedia. OAbot can do some pretty nifty work, so I think the current implementation is definitely "good enough" to get started with, and as noted above doesn't prevent us from tweaking icons in the future as we progress, get feedback, and learn. Cheers, Jake Ocaasi (WMF) (talk) 22:27, 14 September 2016 (UTC)
Colored versions of the lock are only more intuitive if you as a reader have color sight. For those who don't, the color is more-or-less meaningless; perhaps slightly differing shades of gray. As before, I remain opposed to implementing colored versions of the various locks.
As before, I remain opposed to highlighting the norm. Because named identifiers typically require registration or payment, we should not be adding closed-lock icons to those links. Throughout all of Wikipedia, links in |url= typically link to a readable source; we should not be highlighting those by adding open-lock icons.
I am not opposed to including lock icons in rendered citations where their use is appropriate, distinguishable in color and gray-scale against white or black background, and constrained in their application.
—Trappist the monk (talk) 11:27, 15 September 2016 (UTC)
They are more intuitive, and those with color blindness can still tell them apart by different shapes. Let's implement them, and if we can find a better way of showing this, then we'll refine. We're not saying ignore the 1% here, but to deny the 99% easier access because the information is conveyed in one extra way that the 1% doesn't have access to is silly.
books
} 17:36, 15 September 2016 (UTC)
OK. I will not write again here my arguments against your decision to forbid certain locks at certain places as they have not changed either. Are there any chances the change could still be implemented if you acknowledge that there is a consensus for it, or is your own position a definitive veto against it? All I want is to know when to submit the bot for approval: in the first case, we'll try to reach that consensus, in the latter, I'll submit the bot without waiting for CS1 to change. (I am only concerned about which parameters are allowed - the pictures do not have any influence on how the bot should work.) − Pintoch (talk) 17:18, 15 September 2016 (UTC)
Do not put words into my mouth that I have not spoken. I have not ever said that I forbid certain locks, nor have I said that I will veto changes that I do not support. You know that I do not have that power here.
—Trappist the monk (talk) 09:51, 16 September 2016 (UTC)
I can see my comment sounded rude. Please accept my apologies, I am still not familiar with the power structures here (as an admin you do control what gets into the live module, right?). − Pintoch (talk) 10:53, 16 September 2016 (UTC)
No. I do not have that power. Any admin can can be the boatman who conveys changes across the cascading protection (our River Styx). Neither they, nor I control what gets into the live module.
—Trappist the monk (talk) 11:47, 16 September 2016 (UTC)
Trappist's concerns are legitimate and I will comment that he is not the only one who holds them. "A consensus" does not seem to exist with such firmness as you think, and I suspect that an RFC would likely resolve in Trappist's favor on those points. --Izno (talk) 17:28, 15 September 2016 (UTC)
Fine! I thought most editors agreed on the mockup that I followed for my implementation in the sandbox (hence the "consensus"). Trappist was the only one to voice his concerns about this issue after my implementation. Good to see others finally chiming in! I just need the discussion to actually take place, because this detail is holding us back on another front, and I'm happy to see any decision taken about this. I hope this is clearer. − Pintoch (talk) 19:55, 15 September 2016 (UTC)
Let's implement the technicalities, and we'll work out the best practices. I'm not super thrilled about plastering |access=free myself, mostly because the url SHOULD be free by default. If it's not free, then the link adds nothing over |doi=, and should be removed. So the only time you really need to flag anything is if it's not free, and no id/doi are present. Likewise, DOIs should be closed by default, and we flag the free ones (with automated links when that is the case).
So that could mean only allowing |access=subscription/registration/ignoring |access=free and allowing |doi-access=free/ignoring |doi-access=subscription/registration. 17:45, 15 September 2016 (UTC)
They appear to have been refuted; and accessibility guidelines (our own, and the W3C's) suggest not relying on colour alone to distinguish items; they do not deprecate its use at all. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:20, 15 September 2016 (UTC)
I join others above in expressing doubts that there is sufficient consensus for the proposals as they stand. Both the icons to be used and the circumstances of their use have been debated and changed back and forth several times. There should be a clear proposal, or a clear small set of alternative proposals, and then a much wider RfC. Nothing less will be satisfactory for a change with such a significant visual impact all over Wikipedia. Peter coxhead (talk) 19:43, 15 September 2016 (UTC)
Let me join in the chorus of people here who are skeptical about this proposal. It cluttters up the citations, is not always easy to define (is a site that limits you to a certain number of downloads per month open access? is a link that works when you follow it from a specific other link, but not when you copy and paste the same url into Wikipedia, open access?), is about a specific link rather than the whole citation but is proposed to be parameterized and displayed in a way that does not indicate which links are open and which are not (the same paper can be open access through one access method and not open access through another), and is of dubious value to most readers. We can continue to discuss it and mock things up, of course, but I remain unpersuaded. Just because we can do something doesn't mean we should. —David Eppstein (talk) 20:03, 15 September 2016 (UTC)
The locks would apply to the links provided. doi:10.1234/whatever may sometimes resolve to different places, but never one that's open access and another that isn't. The lock on that doi would reflect the state of that link. We might need some more discussion, but right now what I'm proposing, and that I think is likely to be agreed on, is that |url= link shows when they ARENT free, while identifier links shows when they ARE free. But let's at least have a working sandbox version so we can debate and tweak behaviour as needed. And then we can RfC for deployment or something.
books
} 20:22, 15 September 2016 (UTC)
Re the different potential expansions of a doi never having different open-access statuses: [citation needed]. And what do you propose to do with links like the ones generated by {{MR}} that already give you useful information when accessed openly but give enhanced information to subscribers? —David Eppstein (talk) 22:15, 15 September 2016 (UTC)
Re doi: You can't prove a negative, and you know that. But I do citation cleanup like few people do, and I have never once ran into a doi that resolves to both an open and a closed access provider. That's because articles are either openly licensed, in which case they will be openly licensed to both providers, or they aren't, in which case neither providers will provide it.
Re MR: MR is closed/subscription based, and non-subscribers do not have access to the review. The options available are, mark it locked (which I think is unecessary/overkill, but others might differ), or do like we do now (which I think is the best behaviour, but again others might differ) and leave the MR link plain.
Re clutter: The locks are certainly better than Smith, J. (2016). "Article of things". Journal of Things. 1 (2): 3.
books
} 22:48, 15 September 2016 (UTC)
I have to go along with Headbomb, that we need a fully functional sandbox version so that we can compare the output with the existing templates to see what works best. Keith D (talk) 23:04, 15 September 2016 (UTC)

I have changed the sandbox to forbid |access=free and |doi-access=subscription. Intermediate access levels are currently allowed on both |access= and |doi-access= (but it's straightforward to change). |id-access= is not implemented for other ids. I can add them if you think that it would ease the discussion (but as far as I can tell they would work just like |doi-access=, right?). So I believe the sandbox is functional now. − Pintoch (talk) 06:15, 16 September 2016 (UTC)

The identifiers that need to be flagged would behave like that, yes. However, some are always free (arxiv, biorxiv [see above discussion], rfc, pmc, and possibly others) while others are always closed (mr, possibly others) and for others it's just irrelevant (asin, lccn, issn, isbn, oclc, ol) so we don't need to have an |arxiv-access=/|mr-access=/|asin-access= parameters. Only those that vary would need to have an access-parameter. Of the identifiers we support, I'm not sure of jstor, jfm, osti, ssrn, zbl as well as the proposed citeseerx support. I know bibcode/doi vary, I think citeseerx/jstor vary as well, but that jfm/zbl are always non-free and osti/ssrn are always free. But that's something that needs to be verified.
books
} 12:05, 16 September 2016 (UTC)
Perhaps this has been asked and answered: why do we need |access= when there is already |subscription= and |registration=? Are these not possibly conflicting?
—Trappist the monk (talk) 09:51, 16 September 2016 (UTC)
Those should be deprecated/cleaned up by bots when the new system is rolled out.
books
} 12:05, 16 September 2016 (UTC)
In my opinion, the main problem with |subscription= and |registration= is that it is unclear which link they apply to (given how they are currently rendered). Here is an instance where the |url= is closed, but |subscription= adds a note just after the CiteSeerX id, which is open:
Simpson, Alex (2012). "Measure, Randomness and Sublocales". Annals of Pure and Applied Logic. 163 (11): 1642–1659.
CiteSeerx: 10.1.1.220.7880. {{cite journal}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help
)
It has also been pointed out that |subscription= is quite verbose. However, I agree that allowing both |access= and |subscription= is annoying. I think we should deprecate these old parameters in favor of the new system we are discussing here. It might be possible to migrate existing |subscription= and |registration= to the new system with a bot, but that could only be done in unambiguous cases. − Pintoch (talk) 10:24, 16 September 2016 (UTC)
The conflict I was thinking about was |access=subscription and |registration=yes (and vice versa). I have always taken |subscription= and |registration= to apply to |url= but I can see that the template documentation is not clear on that. If this |access= proposal is adopted, then I agree that |subscription= and |registration= should be deprecated. For the case of a single external link, either by |url= or a named identifier, a bot could replace or remove |subscription= and |registration=.
—Trappist the monk (talk) 11:47, 16 September 2016 (UTC)
Concerning this conflict, should we simply raise an error in the cases you mention? About the ambiguity of |subscription= and |registration=, let me stress that a good documentation would not solve the problem: the rendered output is still ambiguous to readers, because most readers will not read the CS1 documentation. − Pintoch (talk) 13:25, 16 September 2016 (UTC)
Yes. I have done so:
"Title". journal. {{cite journal}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)
"Title". journal. {{cite journal}}: Unknown parameter |registration= ignored (|url-access= suggested) (help)
—Trappist the monk (talk) 10:44, 17 September 2016 (UTC)

Adding different access icons and related links

Is there any reason for adding a non-free source link to a citation when there is a free one? You present a false dilemma. 72.43.99.146 (talk) 12:33, 16 September 2016 (UTC)
This will not usually be done intentionally, but right now (see
books
} 12:46, 16 September 2016 (UTC)
I would think it should be the bot writer's job to have the bot check whether a source is already verifiable online through the current citation before adding yet another link? I still don't see the logic behind having both free and non-free links. 72.43.99.146 (talk) 13:02, 16 September 2016 (UTC)
What you're proposing that is that bots remove existing urls when they add free links, and that is something very, very risky. While it'll certainly be possible to do so in some case, for most links it will be nearly impossible to confirm whether or not an existing url is freely accessible or not.
books
} 13:18, 16 September 2016 (UTC)
In this particular example, the free version is only a preprint that significantly differs from the published version (the URL points to that version). The url is still useful to the happy few who can jump the paywall. In general, there are many reasons why non-free URLs or identifiers are useful even when there is a free one: for instance to generate richer COinS data, or to help readers find the article in their library's database (because they like reading a paper copy, say). − Pintoch (talk) 13:25, 16 September 2016 (UTC)
What is the citation verifying? Is it a claim that is sourced at the preprint or at the peer-reviewed version? Or both? If it is on both, only the free link is required for purposes of verification. If it is in either version, the links would be mutually exclusive. 72.43.99.146 (talk) 13:47, 16 September 2016 (UTC)
The statement is always backed by the official/published version. The preprint is a link of convenience.
books
} 14:56, 16 September 2016 (UTC)
Whether a version is official or not is irrelevant. Does it verify the related claim in the text? Then that is the only link (and icon) necessary. It is fine to provide additional information but be mindful of the overhead. 100.33.37.109 (talk) 01:17, 17 September 2016 (UTC)
It matters very much, because if the claim didn't survive peer review, then the source doesn't support the statement it is meant to support the article needs to be revised accordingly.
books
} 09:08, 17 September 2016 (UTC)
A single citation cannot point to two different versions/editions/reprints.
If an article, for whatever reason, states something from a particular version, and correctly cites that version, that is all that is needed. The editor can add |edition=preprint or |edition=peer-reviewed.
If it cites something as included in one version but not another, two different citations are needed. The editor can add |edition=preprint and |edition=peer-reviewed.
If the versions are identical, either can be used. Because the point is to verify the text, by whatever means, and there is no issue of reliability here. It is the contributor's choice to include the info about the versions being identical, in article text or non-reference footnote.
If the version cited is the non-free peer-reviewed one, and the particular statement is included in both, and the preprint is free, a |url= free link comparable to the one in {{cite book}} can be used. Such links do not need to be shown as free. Their existence as |url= without an access note in the citation, suffices. Again It is the contributor's choice to include the info about the versions, in article text or non-reference footnote.
The proposed proliferation of icons and parameters unnecessarily complicates this. Imo, per the current policies and citation guidelines, there is no need for the module(s) to accomodate different icons and related links per citation, taking into account the required overhead. 72.43.99.138 (talk) 13:40, 17 September 2016 (UTC)
Simply put, you're wrong because you're conflating several different and unrelated issues. We are not citing two versions, we are citing one version, and providing a convenience link to a preprint which is most of the time accurate as far as the information goes, but lacks the polish and format of a professionally edited final version. This link is useful because preprints are free, while published versions often aren't, and if the publisher's website is down, you can still access the preprint version. If the preprint version is what is cited, then we would use {{
books
} 14:17, 17 September 2016 (UTC)
I did not propose that preprint-version links should not be included. The last example in my previous comment states that such links, when they are used in a citation of a non-free, peer-reviewed article, should be treated the same way similar links are treated in {{cite book}}: using the pre-existing |url= without any additional access note, which by default signifies a free link. I completely support adding free links that directly verify the citation; I just don't believe an extra icon and/or access note is required. That is also the case with free doi ids etc.: either format them as |url= instead, or eschew the url link and (if so decided) add a free-access icon to |doi=. 72.43.99.138 (talk) 14:48, 17 September 2016 (UTC)
If your objection is simply the existence and use of icons, then consensus seems to be against you.
books
} 20:48, 17 September 2016 (UTC)
It is not just aesthetics. It is also the added complexity and overhead in the code. The added complexity is not static. It may return with a bite any time the code has to be modified, one more thing to take into account. I don't think the payoff is worth it. 72.43.99.138 (talk) 14:28, 18 September 2016 (UTC)
Hum, are we talking here about the complexity of the code required to implement |access=, |doi-access= and the others? If so, have you had a look at the relevant changes in the sandbox? The footprint is actually very small. After a (long) deprecation period for |subscription= and |registration=, we should eventually be able to remove these parameters, which would even simplify the code a bit. I agree we have to be careful to implement it in a responsible way, but I think the current approach is quite modular and fits well with the rest of the code. If you have any specific concern about the way it is currently implemented, let's discuss it. − Pintoch (talk) 15:27, 18 September 2016 (UTC)

Code footprint is not the issue. Complexity is not a result of mass, but of relationships. The effect of which, especially when they cascade (as they will invariably do), can be difficult to gauge beforehand. I am looking at what is being gained by implementing this. To me, the gain seems borderline trivial. This is not a reflection on OAbot per se. I'm not lingering on this because I want to micromanage, delay, or be obstructive. But once something wrong is applied, it takes forever (or never) to make right. The only chance to avoid this usual Wikipedia grind (due to the slowness and fragility of consensus building) is to make sure things are right the first time. Because something obviously true in the real world may not be obvious, nor true, where "Wikipedians" are concerned. 65.88.88.127 (talk) 18:34, 18 September 2016 (UTC)

Can you pinpoint some concrete case where this proposal could interfere with other aspects of CS1? Your point seems to be applicable against any new feature. (Moreover, this is not a new feature: this is a refinement of an existing one.) I don't think the gain is marginal. If we add a |citeseerx= or |hdl= while there is already a |url=, the change will go mostly unnoticed. People don't know if these ids give access to the full text, they will just click on |url=. And again, as in the example above, changing |url= is not an option. Peer reviewing really matters. − Pintoch (talk) 19:51, 18 September 2016 (UTC)
As I mentioned, I cannot know where the new dependencies may bite in the future. I can only do the cost-benefit analysis according to the perceived benefit. Furthermore, my opinion is as non-binding as anyone's. 65.88.88.126 (talk) 15:03, 19 September 2016 (UTC)

CiteSeerX id structure

Copied from an email I got from the CiteSeerX people

Resources ingested by CiteSeerX require a unique ID, or Digital Object Identifier (DOI) that will stay the same for lifespan of the resource. DOIServer provides the means to obtain unique DOIs safely, such that once a particular DOI is issued, that DOI will never be issued again at a particular site or at other sites that use DOIServer. DOIs are of the following form:

<SITE_ID>.<DEPLOYMENT_ID>.<TYPE>.<BIN>.<RECORD>

All variables are integers and have the following semantics:

• SITE_ID: a label that uniquely identifies the site where CiteSeerX is hosted.

• DEPLOYMENT_ID: a label that uniquely identifies the particular DOIServer deployment within the site (allows safe replication of DOIServer application).

• TYPE: a label identifying the type of resource that a DOI was issued for.

• BIN: an ID space for a particular resource type, meant to bound the size of the DOI string.

• RECORD: an ID for a particular resource, with values ranging from 1–9999.

When a new DOI is issued for a particular site, deployment, and resource type, if incrementing the RECORD field would result in a value greater than 9999, the BIN value is incremented instead and the RECORD value is dropped to 1.

This should be useful for error checking.

books
} 21:59, 20 September 2016 (UTC)

Can your contact identify what the legitimate value-ranges for these elements are? Besides the record element, which has a defined range of 1–9999, are there similar limits to the range-size of the other elements? Are there illegal values for some or all of these elements? (0 is apparently illegal for the record element).
—Trappist the monk (talk) 10:08, 21 September 2016 (UTC)
I'll ask.
books
} 11:45, 21 September 2016 (UTC)

Their answer

"In principle, all fields could range between 1 and 9999. If, let's say, a mirror of CiteSeerX is deployed on another site in the future, the SITE_ID may be different. Currently, the first three numbers are fixed, literally <SITE_ID>=10, DEPLOYMENT_ID=1, TYPE=1. The <BIN> could go from 1 to 9999. Currently this field only has three digits but it is increasing. Let me know if this answers your question."

So it seems that, for now, it's 10.1.1.(1-999).(1-9999). Depending on how stringent we want to be, this could be our error check, and then we'll adapt in the future when we run into issues and update to 10.1.1.(1-9999).(1-9999) or similar. Or we could anticipate the expansion, and implement 10.1.1.(1-9999).(1-9999) right off the bat to not worry about the rollover. Or we could allow the most general case of potentially valid ids with (1-9999).(1-9999).(1-9999).(1-9999).(1-9999) from the outset and never again worry about things, but I feel this would be much less useful.

books
} 20:42, 21 September 2016 (UTC)

Current state of the sandbox

Cite journal comparison
Wikitext {{cite journal|date=2007-09-29|first=Charles S.|issue=1|journal=Origins of Life and Evolution of Biospheres|last=Cockell|pages=87–104|title=The Interplanetary Exchange of Photosynthesis|url-access=subscription|url=http://link.springer.com/article/10.1007/s11084-007-9112-3|volume=38}}
Live Cockell, Charles S. (2007-09-29). "The Interplanetary Exchange of Photosynthesis". Origins of Life and Evolution of Biospheres. 38 (1): 87–104.
Sandbox Cockell, Charles S. (2007-09-29). "The Interplanetary Exchange of Photosynthesis". Origins of Life and Evolution of Biospheres. 38 (1): 87–104.
Cite journal comparison
Wikitext {{cite journal|arxiv=1412.8548|date=2014-12-28|doi-access=free|doi=10.4204/EPTCS.172.23|first1=Krzysztof|first2=Jamie|journal=Electronic Proceedings in Theoretical Computer Science|last1=Bar|last2=Vicary|pages=316–332|title=A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem|volume=172}}
Live Bar, Krzysztof; Vicary, Jamie (2014-12-28). "A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem". Electronic Proceedings in Theoretical Computer Science. 172: 316–332.
doi:10.4204/EPTCS.172.23
.
Sandbox Bar, Krzysztof; Vicary, Jamie (2014-12-28). "A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem". Electronic Proceedings in Theoretical Computer Science. 172: 316–332.
doi:10.4204/EPTCS.172.23
.
Cite journal comparison
Wikitext {{cite journal|date=1992-10-01|doi-access=subscription|doi=10.1139/f92-220|first1=K. K.|first2=R. C.|first3=J. R.|issue=10|journal=Canadian Journal of Fisheries and Aquatic Sciences|last1=English|last2=Bocking|last3=Irvine|pages=1982–1989|title=A Robust Procedure for Estimating Salmon Escapement based on the Area-Under-the-Curve Method|url-access=free|url=https://www.researchgate.net/profile/James_Irvine5/publication/233865122_A_Robust_Procedure_for_Estimating_Salmon_Escapement_based_on_the_Area-Under-the-Curve_Method/links/09e4150c65bae92991000000.pdf|volume=49}}
Live English, K. K.; Bocking, R. C.; Irvine, J. R. (1992-10-01). "A Robust Procedure for Estimating Salmon Escapement based on the Area-Under-the-Curve Method" (PDF). Canadian Journal of Fisheries and Aquatic Sciences. 49 (10): 1982–1989.
doi:10.1139/f92-220. {{cite journal}}: Invalid |doi-access=subscription (help); Invalid |url-access=free (help
)
Sandbox English, K. K.; Bocking, R. C.; Irvine, J. R. (1992-10-01). "A Robust Procedure for Estimating Salmon Escapement based on the Area-Under-the-Curve Method" (PDF). Canadian Journal of Fisheries and Aquatic Sciences. 49 (10): 1982–1989.
doi:10.1139/f92-220. {{cite journal}}: Invalid |doi-access=subscription (help); Invalid |url-access=free (help
)

− Pintoch (talk) 06:15, 16 September 2016 (UTC)

Personally, if |access/doi-access= are set to any 'valid' access options (free/registration/subscription), I wouldn't output error messages for the options we disallow. Those would act as a sort of edit-window comment of "yeah, I've actually checked this link, and it is freely accessible" / "yeah I've checked this doi, and it isn't freely accessible". Error messages should, IMO, only be displayed if |access/doi-access= is set to something like "24$" or "Smith 2005 et al.".
books
} 07:56, 16 September 2016 (UTC)
However, maybe we'll want to give the option of having the locks displayed, and make it a guideline (but not a hard rule) that those are best omitted in the instances where the url is free, and that the doi is not.
books
} 08:03, 16 September 2016 (UTC)
I agree with both comments. − Pintoch (talk) 08:12, 16 September 2016 (UTC)
Oppose the latter as highlighting the norm, and the former because excessive use becomes just so much clutter in the wikitext. If there is a need for a note in a reference, such notes can and should be enclosed in <!-- hidden comments -->.
—Trappist the monk (talk) 09:51, 16 September 2016 (UTC)
I fail to see how |url=http://www.example.com<!-- Open access link --> reduces clutter when compared to say, |url=http://www.example.com |access=free. However, I'm not sure exactly to what you are referring to with 'former' and 'later'.
books
} 10:38, 16 September 2016 (UTC)
|url=http://www.example.com<!-- Open access link --> and |access=free are just two forms of highlighting-the-norm. My statement was qualified: If there is a need .... The need to highlight the norm should be rare and because of rarity, html comments suffice.
You made two posts: the former and the latter.
—Trappist the monk (talk) 11:23, 16 September 2016 (UTC)

Automatic url generation

In the case of the free doi (and other free ids of official versions), |url= should be automatically populated with "https://dx.doi.org/{{{doi}}}" to match the behaviour of |pmc= which automatically populates |url= with "https://www.ncbi.nlm.nih.gov/pmc/articles/PMC{{{PMC}}}". Then we can see a priority of |url= (manual) > |doi= (automatic link) > |pmc= (automatic link) to prioritize which automatically-generated url gets used (assuming |url= is empty), and also support |url=doi/pmc so we can override the priority of url-generation if needed. Might be best to wait till later to get into this however.

books
} 08:23, 16 September 2016 (UTC)

Assuming that |url= is automatically populated, then the id should be unlinked. Having 2 links to the same content in a single citation would be superfluous. 72.43.99.146 (talk) 12:57, 16 September 2016 (UTC)
Doing that would be extremely confusing and contrary to established practice.
books
} 13:45, 16 September 2016 (UTC)
Simplicity is confusing? If established practice is wrong, it should go on because it is established, I suppose. 72.43.99.146 (talk) 13:53, 16 September 2016 (UTC)
Having something like
Would be very confusing, yes.
books
} 14:13, 16 September 2016 (UTC)
I agree that the example above would be confusing. I would counter-propose then that |url= should be not be populated when a content id like |pmc= etc. exists. Obviously this would not apply to non-content ids like |issn= etc. 72.43.99.146 (talk) 14:31, 16 September 2016 (UTC)
Well that's against long-established practice. You're free to try and gain consensus for a different behaviour, but not 'main linking' to a free source is a pretty unlikely to pass proposal.
books
} 14:53, 16 September 2016 (UTC)
Re: "long-established practice": Time rights wrongs? 72.43.99.138 (talk) 13:45, 17 September 2016 (UTC)

That would be very nice indeed! But we should make sure the logic remains simple. − Pintoch (talk) 13:53, 16 September 2016 (UTC)

The logic should be fairly simple, at least as far as template users are concerned. If there's a free link (|pmc=something or |doi-access=free is specified, the template automatically makes a link. The details of what is linked when multiple free links are available would be taken care of by the template, and in most situations no one needs to do anything else except to flag the 'freeness' of the doi with |doi-access=free. But the option to override the template's preference for a certain identifier for the main link would be there if it makes sense for that article (e.g. on medical articles, it may be that a link through pmc is preferable to a link through doi, in which case, you could just add |url=pmc or something to that nature).
books
} 14:20, 16 September 2016 (UTC)
Astonishing. For once, the IP editor and I are in agreement. I caught hell from editors at WP:MED when I removed the automatic title linking when |pmc= is set. I thought then that such linking was redundant and now that the PMC link is marked with a free-to-read icon, think that such auto-linking is doubly redundant.
I don't think that we should overload parameters. If an editor wants to override the current PMC auto-linking of |title=, they provide a url in |url=. Doing it that way relieves the template of the need to prioritize one free-to-read named identifier over another. I don't think that the templates should be in the prioritizing business.
—Trappist the monk (talk) 11:28, 18 September 2016 (UTC)
Except this creates issues in print, because you'd have something like Bar, Krzysztof; Vicary, Jamie (2014-12-28). "A 2-Categorical Analysis of Complementary Families, Quantum Key Distribution and the Mean King Problem". (https://dx.doi.org/10.4204%2FEPTCS.172.23) Electronic Proceedings in Theoretical Computer Science. 172: 316–332. arXiv:1412.8548
books
} 12:18, 18 September 2016 (UTC)

I would also oppose automatic filling of |url=, because it is redundant, adds needless complication, and clashes with the possibility of wikilinking a notable work. Kanguole 09:41, 4 October 2016 (UTC)

It's already done for other free identifiers (PMC), as far as wikilinking goes, automatic linking can be coded in a way that avoids that issue. Because right now, LOTS of people put both |url=http://dx.doi.org/10.1234/0123456 and |doi=10.1234/0123456 or both |url=http://adsabs.harvard.edu/abs/1924MNRAS..84..308E and |bibcode=1924MNRAS..84..308E when sources are free. This adds significant clutter both in the edit window, but especially when you print articles (see above example).
books
} 11:17, 4 October 2016 (UTC)
I think the treatment of PMC is a mistake that we oughtn't to spread (for the above reasons), and I remove redundant settings of |url= to the same target as a linked identifier when I come across them. Kanguole 13:10, 4 October 2016 (UTC)

Which identifiers?

Identifier Full text access? Template Examples Decision
|arxiv= Always {{arxiv}}
arXiv:1412.8548
 Always append Free access icon
|biorxiv= (?) Always {{biorxiv}}
bioRxiv 047720
 Always append Free access icon
|citeseerx= (?) Always {{
citeseerx
}}
CiteSeerx: 10.1.1.220.7880
 Always append Free access icon
|pmc= Always {{PMC}}
PMC 50050
 Always append Free access icon
|rfc= Always {{
IETF-RFC
}}
RFC 125
 Always append Free access icon
|ssrn= Always {{SSRN}}
SSRN 871210
 Always append Free access icon
|bibcode= Sometimes {{bibcode}}
Bibcode:1998ApJ...508L..81K
is not		 Use |bibcode-access=free
|doi= Sometimes {{doi }}
doi:10.1139/f92-220
is not		 Use |doi-access=free
|hdl= Sometimes {{hdl}}
hdl:1893/23021
is not		 Use |hdl-access=free
|jstor= Sometimes {{JSTOR}}
JSTOR 123456
is not		 Use |jstor-access=free
|ol= Sometimes {{OL}}
OL 5665961M
is not		 Use |ol-access=free
|osti= Sometimes {{OSTI}}
OSTI 4045588
is not		 Use |osti-access=free
|asin= No {{ASIN}} ASIN B00086U61Y No icon
|isbn= No {{ISBN}}
ISBN 0-7475-3269-9
 No icon
|ismn= No {{ISMN}}
ISMN
 979-0-2600-0043-8		 No icon
|issn= No {{ISSN}}
ISSN 0028-0836
 No icon
|jfm= No {{JFM}}
JFM 54.0271.04
 No icon
|lccn= No {{LCCN}}
LCCN 89-456
 No icon
|mr= No {{MR}}
MR0123456
 No icon
|oclc= No {{OCLC}}
OCLC 632791477
 No icon
|pmid= No* {{PMID}}
PMID 123456
 No icon
|zbl= No {{zbl}}
Zbl 06626752
 No icon
* If it's free, it will have both a PMID and PMC. PMID technically provides a link to a freely-accessible version, but it's the PMC version. So for purpose of displaying the free icon, it should be on the PMC, and not on the PMID, since the PMID link would point to the PMC version anyway.


I propose we build a table summarizing the status of all identifiers currently supported by CS1 with regard to these free to read icons. Feel free to edit it directly. − Pintoch (talk) 14:22, 20 September 2016 (UTC)

@Headbomb:, I am not familiar with bibcode: does this service store any full text? It seems to me that they redirect to the publisher's version or arXiv (which should be already covered by |doi= and |arxiv=), at least in the example you give. It looks similar to |pmid= in this respect, so I am not sure an icon is useful there? − Pintoch (talk) 17:59, 20 September 2016 (UTC)
The
books
} 18:31, 20 September 2016 (UTC)
Thanks for the examples (and other improvements to the table), it does make sense to add an icon indeed. − Pintoch (talk) 07:49, 21 September 2016 (UTC)
Somewhat relatedly, the doai project seems to be a somewhat official way of finding open-access versions of papers from their closed-access doi. For instance the doai version of the non-free doi example above links to a free pdf on the same paper, apparently in this case made available through ResearchGate. —David Eppstein (talk) 23:27, 20 September 2016 (UTC)
Yes, this is one of the sources OAbot will be pulling from. − Pintoch (talk) 07:49, 21 September 2016 (UTC)

Protected edit request on 7 October 2016

Two instances of the bad style "needs to" should be replaced by "must": Please change the quote needs to include terminating punctuation to the quote must include terminating punctuation.

Eric talk 02:57, 7 October 2016 (UTC)

It looks like you figured out that the documentation is not protected. – Jonesey95 (talk) 03:00, 7 October 2016 (UTC)
Partially, but for some reason I couldn't get at it here: Help:Citation_Style_1#Quote until just now. Just took care of it. Thanks. Eric talk 12:11, 7 October 2016 (UTC)

Template for deletion: cite archives

The template {{

C
19:19, 7 October 2016 (UTC)

Volume parameter absent from typeset output from Cite conference

This is about {{Cite conference}}. Consider this citation [1] and this citation,[2] the second differing from the first by the inclusion of |volume=2. As can be seen below, this volume information is not typeset.

References

  1. ^ Frog, Bill (1 January 2000). "On water and wetness". In Fly, Felicity (ed.). Proceedings of ABC 2000. ABC 2000. London, UK: Academic Press. pp. 659–668.
  2. ^ Frog, Bill (1 January 2000). "On water and wetness". In Fly, Felicity (ed.). Proceedings of ABC 2000. ABC 2000. Vol. 2. London, UK: Academic Press. pp. 659–668.

The documentation states however:

volume
For one publication published in several volumes. Displays after the title and series fields; volumes of four characters or less display in bold.

Looks like a bug? Best wishes. RobbieIanMorrison (talk) 13:18, 14 October 2016 (UTC)

Because you have identified the conference proceedings as a book (you used |book-title=Proceedings of ABC 2000), |volume= does not apply. Had you identified the proceedings as a journal (had you used |journal=Journal name and |title=Proceedings of ABC 2000), then |volume= (and |issue=) apply.
{{cite conference |last1=Frog |first1=Bill |title=On water and wetness |date=1 January 2000 |conference=ABC 2000 |editor-last1=Fly |editor-first1=Felicity |title=Proceedings of ABC 2000 |journal=Journal of Whatever |publisher=Academic Press |location=London, UK |pages=659–668 |volume=2 |issue=5}}
Frog, Bill (1 January 2000). Fly, Felicity (ed.). Proceedings of ABC 2000. ABC 2000. Journal of Whatever. Vol. 2, no. 5. London, UK: Academic Press. pp. 659–668.
—Trappist the monk (talk) 13:36, 14 October 2016 (UTC)
It's still a bug though. Books can have volumes.
books
} 14:18, 14 October 2016 (UTC)
A few more things: "the full parameter set" does not include |series=, however the parameter displays values when properly used with |book-title=. Yet when both |series= and |volume= are used, volume does not display. To compound the schizophrenia, there is this section: Template:Cite_conference#Edition, series, volume. 65.88.88.46 (talk) 15:46, 14 October 2016 (UTC)
Here is an example from real-life where a proceedings is published in multiple volumes:
{{cite conference/new |vauthors=Vos F, Delaey L, De Bonte M, Froyen L |veditors=Coddet C |url=https://books.google.com/books?id=o-wz5phUzhEC&pg=PA117 |title=Plasma Sprayed Self-lubricating Cr203-CaF2 Coatings: Friction and Wear Properties |book-title=Thermal Spray: Meeting the Challenges of the 21st Century; Proceedings |conference=15th International Thermal Spray Conference |date=25–29 May 1998 |location=Nice, France |volume=1 |pages=117–122 |doi=10.1361/cp1998itsc0117 |isbn=0-87170-659-8}}
Vos F, Delaey L, De Bonte M, Froyen L (25–29 May 1998). "Plasma Sprayed Self-lubricating Cr203-CaF2 Coatings: Friction and Wear Properties". In Coddet C (ed.). Thermal Spray: Meeting the Challenges of the 21st Century; Proceedings. 15th International Thermal Spray Conference. Vol. 1. Nice, France. pp. 117–122.
ISBN 0-87170-659-8
.
I have tweaked the sandbox to allow |volume= in non-periodical {{cite conference}} templates.
—Trappist the monk (talk) 12:01, 16 October 2016 (UTC)

Volumes not showing up in {{cite thesis}}

Hey guys, I just noticed that the "volume" part of {{cite thesis}} isn't working. I wonder if a recent change might have knocked it out.

  • Smith, John (1999). All about Frogs (PhD thesis). Vol. Vol. 1. {{cite thesis}}: |volume= has extra text (help)
  • Smith, John (1999). All about Frogs (PhD thesis). Vol. Vol. 2. {{cite thesis}}: |volume= has extra text (help)

See? The first one should show "Vol. 1" and the second should show "Vol. 2".--Brianann MacAmhlaidh (talk) 01:12, 16 October 2016 (UTC)

Assuming the documentation is correct and volume should be supported by thesis, I investigated the code. This is happening because in Module:Citation/CS1/Configuration templates_using_volume does not include 'thesis' in the set of templates that should use the volume parameter. The full list is {'citation', 'audio-visual', 'book', 'conference', 'encyclopaedia', 'interview', 'journal', 'magazine', 'map', 'news', 'report', 'tech report'}. Presumably it should be {'citation', 'audio-visual', 'book', 'conference', 'encyclopaedia', 'interview', 'journal', 'magazine', 'map', 'news', 'report', 'tech report', 'thesis'}. I've added it to the sandbox configuration. The sandbox configuration outputs the following...
  • Smith, John (1999). All about Frogs (PhD thesis). Vol. Vol. 1. {{cite thesis}}: |volume= has extra text (help)
  • Smith, John (1999). All about Frogs (PhD thesis). Vol. Vol. 2. {{cite thesis}}: |volume= has extra text (help)
...which appears to fix the issue when using the sandbox version. Does the above look OK to you? —RP88 (talk) 02:02, 16 October 2016 (UTC)
Yeah, that works. But is this just a complaint about the documentation? Instead of these contrived examples, is there a real-life need for this change? The operation of |volume= and |issue= were adjusted at the time of this conversation. So that it's easy to find, I've added the table from that conversation to Help:Citation Style 1#Pages.
—Trappist the monk (talk) 10:24, 16 October 2016 (UTC)
Are you directing this question to me? I don't know the circumstances surrounding why the original poster brought up this issue, but yes, multi-volume theses are not uncommon. See, for example, page 11 of Cornell's Thesis and Dissertation Guide or page 6 of Princeton's Doctor of Philosophy Dissertation And Master's Thesis Submission Requirements. —RP88 (talk) 12:27, 16 October 2016 (UTC)
Yep, multivolumed dissertations exist out in the wild. In many cases they're appendixes and whatnot. The thing is that I've cited a few on Wikipedia and have only now noticed the numbers weren't showing up. So I was hoping for a fix. RP88, your tweak looks good to me. Would there be any problem implementing it? --Brianann MacAmhlaidh (talk) 00:31, 17 October 2016 (UTC)
Brianann MacAmhlaidh, I don't anticipate any issues with my change since my edit to Module:Citation/CS1/Configuration/sandbox was very minor. If my change is not reverted, my change should be active the next time an admin updates the live version with the version from the sandbox. It has been a few months since the last update, but it looks like a discussion is taking place above about deploying the version in the sandbox very soon. —RP88 (talk) 02:40, 17 October 2016 (UTC)
OK, thanks RP88.--Brianann MacAmhlaidh (talk) 23:52, 17 October 2016 (UTC)

url-access support

Per the above discussion, we should now implement

  • |url-access== free (A free version of this source can be accessed here)/registration (A (free) registration is required to access this source)/limited (A (free) registration is required to access this source)/trial(A (free) registration is required to access this source)/subscription (A (paid) subscription is required to access this source)

And deprecate |registration=/|subscription=

We could also

  • leave |url-access=free out
  • make |access= an alias of |url-access=

The hover text and file versions for the locks should match (mine are a bit different).

books
} 17:02, 24 September 2016 (UTC)

I thought that the parameter for the url was to be |access=. It is implemented to some extent but is pretty severely broken:
{{cite book/new |title=Title |url=//example.com |url-access=subscription}}
Title.
Pintoch, did you break it?
—Trappist the monk (talk) 17:22, 24 September 2016 (UTC)
Oops, sorry about that. Let me investigate. − Pintoch (talk) 18:32, 24 September 2016 (UTC)
Well, it could be |access=, but then I saw the current error message so I was like... well maybe it's better to have it as |url-access=? I don't have strong feelings here, although I think it would be good to have both |access= and |url-access= as alias of each other.
books
} 19:07, 24 September 2016 (UTC)
@Trappist the monk: The bug was introduced when I added support for |access=, because now that the title can be wrapped inside a <span>, the following check for an empty citation triggers when there is only a title:
if string.len(text:gsub("<span[^>/]*>.-</span>", ""):gsub("%b<>","")) <= 2 then
I believe this check was introduced with the idea that all things enclosed by <span> tags were peripheral, non-essential pieces of metadata: this is not true anymore as adding |access=subscription encloses the title with a <span>. So, this check should be replaced by something simpler (should I write "cleaner"). Any idea how? What about string.len(text:gsub("%b","")) == 0? There is probably a reason why the original check was so complicated, but the test suite does not help much to understand. Concerning |url-access= vs |access=, I am happy with both, but maybe |url-access= is indeed more coherent with the |id-access= scheme. − Pintoch (talk) 19:17, 24 September 2016 (UTC)
I suspect that you're right about the <span>...</span> tags. I changed that line to use <cite>...</cite> and it seems to work. I'm not inclined to change it further until I have the time to actually think about what it is that its doing. It's from before my time, and like so much of that, undocumented.
But, since we're talking about code, can we not use camelCase? For the most part, the camelCase form is used only in calls to the Scribunto library and is the legacy form used for meta-parameter names. As long as I've been working on this code, I have tried to adopt a uniform naming convention.
—Trappist the monk (talk) 19:42, 24 September 2016 (UTC)
Got it, I just changed customAccess to custom_access. − Pintoch (talk) 20:43, 24 September 2016 (UTC)

Clearly, the change I made to the code snippet above (<span>...</span> to <cite>...</cite>) was wrong. It makes no sense to look for <cite>...</cite> tags before they are added to the output. This part of the snippet: 

text:gsub("<span[^>/]*>.-</span>", "")

looks for and replaces span tags with an empty string. Once that's done, this bit: 

:gsub("%b<>","")

looks for and replaces other html-like markup with an empty string (anything enclosed in <...>; cs1|2 adds <q>...</q> and <b>...</b>)

I am a bit perplexed by the pattern in the first replacement: 

"<span[^>/]*>.-</span>"

The pattern matches everything between the opening and closing tags and replaces the lot with nothing. So, in this case, where text has the value: 

<span class="plainlinks">[//example.com ''Title'']</span><span style="margin-left:.1em">[[File:Lock-red.svg|9px|link=|A (paid) subscription is required to access this source]]</span>.

everything except the final dot is replaced by nothing. Why?

I wonder if the pattern and replacement should have been: 

text:gsub("<span[^>/]*>(.-)</span>", "%1")

This captures the content and uses that as the replacement value so only the <span>...</span> tags are removed leaving the content behind: 

[//example.com ''Title'']

which gives string.len() something to count besides the dot.

Except that, once upon a time, there was code that added hidden comments to the module output for debug information. Those comments were enclosed in <span>...</span> tags so apparently, the first replacement pattern was added to deal with them. It makes sense that for those hidden comment <span>...</span> tags, removal of the whole is appropriate. That form of debugging has since been removed and we are now occasionally enclosing elements of the citation in <span>...</span> tags so we should not be discarding the content of those tags in the process of doing this test.

I have reverted my edit and modified the test as described above.

—Trappist the monk (talk) 11:54, 25 September 2016 (UTC)

Awesome, thanks a lot! Your new version looks much more sensible indeed. − Pintoch (talk) 13:36, 25 September 2016 (UTC)

I have changed |access= to |url-access=, given the arguments above (and also from the previous discussion):

  • The current error message (suggesting to use |access-date= instead of |access=) indicates that some editors might write |access= when they think |access-date=, so they could be confused by the new meaning of |access=
  • Using |url-access= is more consistent with the |id-access= schema
  • 'access' alone is too generic, not informative enough
  • This change underlines that the access level is tied to the |url= unlike |subscription= and |registration=.

Currently |access= is rejected (it is not an alias of |url-access=), essentially because of the first argument. − Pintoch (talk) 08:58, 27 September 2016 (UTC)

Category names. Perhaps not these: Category:Pages using citations with url-access and no URL and Category:Pages using citations with id-access and no id? For quite some time now, new error categories have been named: 'Category:CS1 errors: <something>' where <something> is a brief descriptor of the category's purpose. I might suggest: Category:CS1 errors: url-access without URL and Category:CS1 errors: id-access without id.

—Trappist the monk (talk) 09:40, 27 September 2016 (UTC)

That's much better indeed, I have changed that. Actually, is it useful to keep these two categories separate? It is quite simple to merge them (we can remove the error message for |url-access= and use the one for |id-access= with id=url). It seems harder to split the one for |id-access= into specialized ones for |doi-access=, |hdl-access= and the others without adding some complexity to the Lua code. − Pintoch (talk) 13:01, 27 September 2016 (UTC)
I think if anything, the category should be

books
} 11:51, 14 October 2016 (UTC)

Because the |url-access= error is essentially the same as the |<id>-access= error, because the error messages have identical static text, because the 'fix' for these errors is the same, I see no point in having two separate categories, two separate error message handlers. I have combined these into a single error message using the single Category:CS1 error: param-access.
If ever in future there are so many of these errors that individual parameter categories are desirable, we can contemplate that then.
—Trappist the monk (talk) 11:45, 15 October 2016 (UTC)
Excellent! I agree it's simpler like that. Thanks for adding the missing category by the way. - Pintoch (talk) 11:58, 15 October 2016 (UTC)

archive-url and url-access

How does url-access interface with archiveurl if at all? For example sometimes the live link is paywalled while a archive link version is not. Editors will add an archivelink version to get around the policy block. I don't think it is terribly common but does happen. If deadurl=yes, will url-access show a lock for the original dead link or for the archive link or both? --

C
17:27, 16 October 2016 (UTC)

Currently, the lock is still added to the title, which points to the archived version:
I guess it should rather be on the original link. Should I change that? − Pintoch (talk) 18:31, 16 October 2016 (UTC)
I would say the lock symbol should be on the original link rather the archive link. It's unknown what the status of the archive link is. --
C
14:48, 18 October 2016 (UTC)
I have swapped the icon, see example above. − Pintoch (talk) 15:11, 18 October 2016 (UTC)

biorXiv error handling

Following Headbomb's creation of the error tracking category, I've added a check for biorXiv ids (checking that the id is a number).

− Pintoch (talk) 11:26, 18 October 2016 (UTC)

The first two should give error messages as well.

books
} 11:37, 18 October 2016 (UTC)

Why so? I don't know anything about these ids, for me they are just numbers. If you know of any better regular expression, feel free to update the sandbox with it. − Pintoch (talk) 11:54, 18 October 2016 (UTC)
The bioRxiv id, as currently implemented, has exactly six digits (legitimate values currently range from 000067 to 081646). They've exhausted about 8% of their scheme in the 3 years they've been operating, so it is unlikely they'll be forced to increase the size of the bioRxiv id anytime soon. I've updated the bioRxiv check in Module:Citation/CS1/Identifiers/sandbox to report an error if the id is anything other than exactly six digits. —RP88 (talk) 12:49, 18 October 2016 (UTC)

We do not restate the erroneous value when invalid ids are detected. I tried to remove it in the sandbox and didn't get it quite right. I have reverted my change since I have to run off and don't have time to debug right now. – Jonesey95 (talk) 14:40, 18 October 2016 (UTC)

It should work now. − Pintoch (talk) 14:50, 18 October 2016 (UTC)
Looks better. Thanks. – Jonesey95 (talk) 17:04, 18 October 2016 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1/Archive_26&oldid=1086690706"