Help talk:Citation Style 1/Archive 22

Adding open access links to references
During WikiCite 2016 we plan to work on a bot that would add links to open access copies in citation links. See the relevant proposal and the current demo. Your input about how the bot should behave would be much appreciated. Let's use the project's talk page for this discussion.

In particular, we need to think about how to highlight open access versions, following the earlier discussion on this talk page. -- Pintoch (talk) 09:40, 20 May 2016 (UTC)
 * Only 13 page watchers at the project's talk page.


 * If your bot is going to add id, perhaps it would be better for us to add citeseerx as a regular identifier. That would allow simple error checking and inclusion in the ctiation's metadata.
 * —Trappist the monk (talk) 11:13, 20 May 2016 (UTC)


 * Thanks a lot for your feedback! It would be great if you could add citeseerx as a parameter! But in fact, we will add identifiers from many other platforms, so I'm not sure where we should draw the line between identifiers and OA links (should we add a parameter for ResearchGate, for instance?) − Pintoch (talk) 11:27, 25 May 2016 (UTC)


 * It's really time to implement this. Headbomb {talk / contribs / physics / books} 13:47, 25 May 2016 (UTC)


 * Yes, I could not agree more. But it is not clear to me whether any consensus has emerged out of this discussion. In the end, what would be the right way to indicate that the identifiers we add refer to open access material? − Pintoch (talk) 07:41, 26 May 2016 (UTC)


 * Well, I think the most straightforward implementation would be using something like 10.1234/0123456789 + yes or using 10.1234/0123456789, to be used only when the source is fully available, with no conditions on access. This would then display both the icon next to the ID and link the title. Something like
 * giving
 * Smith, J. (2016). "Article of things Open_Access_logo_PLoS_white_green.svg". Journal of Things 66 (3): 11–15. Open_Access_logo_PLoS_white_green.svg.
 * Headbomb {talk / contribs / physics / books} 16:55, 2 June 2016 (UTC)
 * Headbomb {talk / contribs / physics / books} 16:55, 2 June 2016 (UTC)

And that would apply for all identifiers, with the understanding that identifiers that are guaranteed to be free (e.g. arxiv, pmc, etc.) automatically get the icon. Headbomb {talk / contribs / physics / books} 16:57, 2 June 2016 (UTC)
 * That seems the best option to me as well. How to proceed? Should we draft the changes to the template somewhere? − Pintoch (talk) 22:34, 3 June 2016 (UTC)

Just a little side-idea: Given that in most cases the "open lock" symbol would follow the "external link arrow" symbol, wouldn't it be possible to combine them into one symbol? Either overlay the arrow symbol with a small lock in one of the corners, or just display a green (instead of a blue) external link symbol (and a red external link symbol for closed sources)? --Matthiaspaul (talk) 21:33, 8 June 2016 (UTC)
 * I have thought the same thing because the two together is clutter. It would, I think, need to work in a way similar to the way that the PDF icon replaces the external link icon for PDF urls.  That is accomplished with css in MediaWiki:Common.css.  I'm not a css expert, but I expect that there are editors out there who know who how to override the external link icon.  It might be best, to raise this narrow topic at WP:TWL and then once a consensus regarding color, image, etc is reached, approach the editors at Common.css for recommendations and implementation of a solution.  If there is a css class or something similar, Module:Citation/CS1 can apply it (when and if a decision is ever taken to support these icons in cs1|2).
 * —Trappist the monk (talk) 21:53, 8 June 2016 (UTC)


 * I agree CSS is the best solution here. can you raise this at WP:TWL? − Pintoch (talk) 07:47, 9 June 2016 (UTC)
 * , I'm fully supportive of this and trust all the above instincts. I'm just not exactly sure what's being proposed.  It would be helpful if you could draft on WP:TWL or in your sandbox a simple spec (...this icon here will be added when x, y, z, and it will look like this, and be implemented via this).  Then I can gather some more discussion around it.  Best, Jake Ocaasi (WMF) (talk) 18:29, 10 June 2016 (UTC)
 * ping, can you gather discussion there? For now we can't really say we have a consensus., , , anyone else: do not hesitate to drop a line there if you have time (as I understand it, participation is necessary to get the change done, which is itself a requirement to run the bot…) − Pintoch (talk) 21:20, 14 June 2016 (UTC)


 * Discussion should be here, not there. First, this is a much more visible forum, and one impacting all of wikipedia, not just WP:TWL, and second we already have an ongoing discussion, and forking serves no purpose. Headbomb {talk / contribs / physics / books} 12:35, 15 June 2016 (UTC)


 * OK. I've advertised the project at various places, hoping that we will be able to move forward with this. Pintoch (talk) 17:33, 20 June 2016 (UTC)

I'm pretty happy with the proposals here. Adding\marking links to openly accessible material is potentially quite valuable for the reader. It looks like the intention here is to signal "generally free to read" rather than (the previously suggested) "fully openly licensed content" - is this correct? If so, I'm definitely on board. If it's to be restricted to only CC-BY-type material, I'm not so sure it's useful; this is a bit of a subtle nuance that's not helpful for most readers. Andrew Gray (talk) 21:57, 20 June 2016 (UTC)


 * Yes, the criterion to mark links would be that they are free to read, not necessarily openly licensed. (I think this is indeed more useful for readers - and it happens to be technically a lot easier.) − Pintoch (talk) 08:54, 21 June 2016 (UTC)

There is a fly in the icon ointment. The way that MediaWiki implements the PDF icon has accessibility issues for the visually impaired. Because the icon is not an image in the html sense of an image, there is no alt attribute that a screen reader can read to the human. This is why cs1|2 has format and why cs1|2 automatically adds PDF when the value assigned to url would cause MediaWiki to use the pdf icon. Using css to replace the normal external link icon would then require cs1|2 to add some sort of text to explain the open access nature of the preceding link.

It may still be possible to disable the normal external link icon and use an html image of the lock in its place, but to avoid adding additional text to each citation, this must be accomplished by a mixture of css to hide the external link icon and html to provide an image with the proper alt text.

—Trappist the monk (talk) 12:05, 22 June 2016 (UTC)
 * Here is a possible solution to the technical issues. First wrap the url:
 * Article of things
 * then for the lock image with a bit of css to slightly separate the lock from the url:
 * and put it all together:
 * Smith, J. (2016). " Article of things Open_Access_logo_PLoS_white_green.svg ". Journal of Things 66 (3): 11–15. Open_Access_logo_PLoS_white_green.svg.
 * —Trappist the monk (talk) 12:40, 22 June 2016 (UTC)
 * Smith, J. (2016). " Article of things Open_Access_logo_PLoS_white_green.svg ". Journal of Things 66 (3): 11–15. Open_Access_logo_PLoS_white_green.svg.
 * —Trappist the monk (talk) 12:40, 22 June 2016 (UTC)
 * —Trappist the monk (talk) 12:40, 22 June 2016 (UTC)


 * : This is great news! That means that we don't even need to change common.css, so your screen-reader-compliant version is actually simpler to implement as it only requires us to change CS1|2, right? What do you think about trying to implement that for pmc and arxiv first? They are low-hanging fruits as they do not require any change in the way templates are instantiated. I am happy to help implement this. − Pintoch (talk) 16:37, 29 June 2016 (UTC)

I'm not quite sure why we need this. We already have indicators that can be added to indicate subscription required, like for newspaper sources. In my view, any source not free should be tagged with that, instead of tagging the free ones. Basically, online sources are free to read unless noted otherwise. Oiyarbepsy (talk) 13:17, 22 June 2016 (UTC)


 * first, the subscription and registration apply only to a citation as a whole, so we cannot use it to tell readers which links in a citation are paywalled. Second, we intend to use these parameters on scholarly references, where most sources are unfortunately paywalled (or just bare bibliographic references themselves). Third, I think that as a reader, it is more natural to get used to look for the green icon rather than to avoid links requiring subscriptions (you might actually have access to them in some contexts). Fourth, the bot we have written is never sure that a source is paywalled, but it can be sure that a source is free to read (that's easier to detect). − Pintoch (talk) 17:00, 22 June 2016 (UTC)


 * What pintoch said. Also, most links are usually not free, so it makes sense to flag those that are. It's telling readers 'go here', rather than 'avoid this one'. Headbomb {talk / contribs / physics / books} 17:22, 22 June 2016 (UTC)

Because the 'official' open access lock is orange, but the examples in this discussion use a green lock, I've started a conversation at Template talk:Open access.

—Trappist the monk (talk) 13:36, 23 June 2016 (UTC)


 * It would be useful to have the open lock icon have a tooltip explaining what it meant. I've never seen it until now, and it isn't exactly obvious what it is when looking at it. ··· 日本穣 ·  投稿  · Talk to Nihonjoe ·  Join WP Japan ! 19:05, 23 June 2016 (UTC)
 * In the lock example I used, the image has open access publication - free to read. I see that alt text when I hover my mouse cursor over the lock: Open_Access_logo_PLoS_white_green.svg. Does that not work for you?
 * —Trappist the monk (talk) 19:17, 23 June 2016 (UTC)
 * In the one in your comment, yes. In the ones farther up that are using a template (, I believe), no. ··· 日本穣 ·  投稿  · Talk to Nihonjoe ·  Join WP Japan ! 00:30, 24 June 2016 (UTC)
 * The 'rendered' cite journal templates in this discussion are mock-ups. Editor Headbomb and I used different image mark-up:
 * → Open_Access_logo_PLoS_white_green.svg – Headbomb
 * → Open_Access_logo_PLoS_white_green.svg – ttm
 * —Trappist the monk (talk) 00:55, 24 June 2016 (UTC)

adding free-to-read icons
Because of, I have modified the , and   functions in Module:Citation/CS1/Identifiers/sandbox to replace the standard external link icon with a green lock: The lock here is one that I modified from File:Open_Access_logo_PLoS_white_green.svg. The primary differences are that the modified lock has a transparent background (the original's is white) and that the shackle is slightly more open: For the time being, I have elected to leave the pmc identifier as it is. The pmc identifier is unique among the identifiers that cs1|2 supports because it causes the module to link title with a redundant link that is the same as the identifier's link. I would prefer that all identifiers act the same way so would prefer to add the free to read lock to the pmc identifier and remove the special-case code that links title with the identifier's url. I did remove that special-case code once, but that made some members of WP:MED rather angry.

—Trappist the monk (talk) 13:40, 30 June 2016 (UTC)


 * Personally, I'd make any free id automatically populate the |url= in cite xxx, except for arxiv because that's a non-official version. But I'd make it autolink in the case of cite arxiv because then you are citing the preprint itself. So basically in pseudocode

if |url= |url-icon=free

else

if          |url=https://www.foobar.com/ |url-icon=free

else |url=

if                |url-icon= end if     end if end if

with access being either 'free' (green open lock) or 'non-free' (red closed lock). It could possibly be extended to have registration and subscription, producing yellow/red closed locks or something like that. There will be a need to develop a hierarchy of identifiers to see which should be favoured in case many are free, and allow this to be overridden through something like pmc} or doi. Headbomb {talk / contribs / physics / books} 14:21, 30 June 2016 (UTC)


 * I think this is a pertinent observation (from Partial paywall and subscription=y below):
 * 72.43.99.146 (talk) 15:07, 30 June 2016 (UTC)
 * 72.43.99.146 (talk) 15:07, 30 June 2016 (UTC)


 * Well, personally, I detest flagging paywalled/subscription/registration/etc, and usually remove those from any article i edit in a more-than-drive-by-way, but flagging open access documents? That's a hell yes from me. This is extremely useful to the reader with no subscription to those journals, which consists of pretty much the entire world that's not currently attending or working at a university. "This link you can read!" Headbomb {talk / contribs / physics / books} 15:42, 30 June 2016 (UTC)
 * The logical conclusion of that is to remove printed links as well, they require you to seek out and purchase a book. A paywalled link is still useful, it indicates that the associated facts have been checked and are defensible even if the current reader can't do so for himself.  Most readers of WP will not follow citations just as most drivers accept the "RON" rating of fuel.  It is checkable against a standard, but heck I just want to read/drive. Martin of Sheffield (talk) 08:57, 1 July 2016 (UTC)


 * I agree with the IP that learning the meaning of the lock is not straightforward. I think its shape and color are fairly intuitive though, and not too intrusive, so I do not think it would harm to add it. This discussion here gathers specialists, so we might get more representative feedback once we have deployed the changes.
 * When you say "any free identifier other than pmc", which ones are you thinking about? I can think of arxiv and doi (when we mark it specifically as free, as proposed earlier), but what are the others?
 * : Thank you so much for implementing this, it works perfectly! If I had to make one cosmetic comment, I guess I would suggest to raise a bit the icon (its bottom is a bit far below the base line of the text it follows, I think). But I am not sure how to do this as we are not using CSS here. (Maybe simply by reducing slightly the size of the icon?) − Pintoch (talk) 19:46, 30 June 2016 (UTC)
 * Re 'any free': Not really sure honestly, but I'm acknowledging the possibility they exist. I think |rfc= is always free. But also, say that jstor it becomes open access in the future, it could be used there. But certainly instances of say |bibcode-free= or |doi-free= could/should be used to create a title link when they are explicitly declared as such. Headbomb {talk / contribs / physics / books} 17:13, 4 July 2016 (UTC)


 * I'm not sure that moving the lock up (or down) is necessary. Compare the image to a directly adjacent character with a desender:
 * qOpen_Access_logo_PLoS_white_green.svg – 9px lock image
 * We might shrink the lock:
 * qOpen_Access_logo_PLoS_white_green.svg – 8px lock image
 * I've been wondering if the lock is too 'heavy'. Perhaps the lines could be reduced to 75% (or even 50%) of their current thickness.  If you look at the lines in the normal external link icon, they are quite fine:
 * http://example.com
 * —Trappist the monk (talk) 21:32, 30 June 2016 (UTC)
 * I've made a 'lighter' lock that has stroke width that is 75% of the lock now used in the cs1 sandbox Can you tell the difference?  Which of these is better?:
 * Leinster, Tom (2007). "The Euler characteristic of a category as the sum of a divergent series". arXiv: [//arxiv.org/abs/0707.0835 0707.0835] Free-to-read lock 75.svg //arxiv.org/archive/math.CT math.CT.
 * —Trappist the monk (talk) 10:47, 1 July 2016 (UTC)
 * If my comment counts, I prefer the lighter one, always.
 * One more thing: Why not to add locked padlock too, and then make more clear difference between locked and unlocked padlock (current padlock is weirdly unlocked)? Locked one should have completely closed curved upper part (maybe with a dot on the right side or better—small cut on the left—to indicate which side is fixed and which is not fixed). Unlocked should be only lifted up (don't change angle of the upper curved part as the real locks do not usually [especially nowadays] function that way; however, some older ones do).
 * Check this and this example for unlocked; it should not be like this or this.
 * This and this might help as good examples too. --Obsuser (talk) 14:13, 1 July 2016 (UTC)
 * I have a locked lock image in black that I though might be used in place of the yes text. Something like this:
 * Smythe, Johnstone P. B. (1986). " Title of something requiring registration registration-required lock.svg ". Retrieved 2016-01-15.
 * Regardless, discussion of locked locks should be held elswhere because this conversation is about the green lock.
 * —Trappist the monk (talk) 15:52, 1 July 2016 (UTC)
 * What about straightening the left side of the upper curved part and adding small cut near its lower part (maybe the cut will not be visible), so it is like ordinary padlocks that have this part moving only up and down (not tilting to the right)? --Obsuser (talk) 17:04, 1 July 2016 (UTC)
 * The upper curved part is the 'shackle'. The goal here is to have a lock that looks more or less like the orange (what were they thinking when they chose that color?) lock apparently associated with Open Access: Open Access logo PLoS white.svg.  My green lock is derived from that design.  At 9px width, small detail like the notch you describe will be lost.  Even the much more open shackle of the green lock is relatively unnoticeable.  Here are the two locks at 18px width:
 * What about straightening the left side of the upper curved part and adding small cut near its lower part (maybe the cut will not be visible), so it is like ordinary padlocks that have this part moving only up and down (not tilting to the right)? --Obsuser (talk) 17:04, 1 July 2016 (UTC)
 * The upper curved part is the 'shackle'. The goal here is to have a lock that looks more or less like the orange (what were they thinking when they chose that color?) lock apparently associated with Open Access: Open Access logo PLoS white.svg.  My green lock is derived from that design.  At 9px width, small detail like the notch you describe will be lost.  Even the much more open shackle of the green lock is relatively unnoticeable.  Here are the two locks at 18px width:


 * —Trappist the monk (talk) 17:23, 1 July 2016 (UTC)
 * I like your lighter version, I have the feeling that it improves readability. − Pintoch (talk) 14:31, 1 July 2016 (UTC)

Proposing the format and changes
I am deeply impressed by and appreciative of the detailed work above to improve the implementation. I think before this goes live, it would be wise to draw attention to the conversation from at least Village Pump and WikiProject Open Access. In order to make that consultation useful, we need a concise explanation of the what/when/where/why/how and a few examples of the change as it will appear. Ocaasit &#124; c 20:47, 30 June 2016 (UTC)


 * I have already advertised the proposal at the Village Pump and at Wikiproject Open. Feel free to do it on WikiProject Open Access (why are these two wikiprojects different anyway?) − Pintoch (talk) 21:01, 30 June 2016 (UTC)
 * I see! Perfect (also the two projects redirect to the same place). Cheers, Jake Ocaasit &#124; c 22:14, 30 June 2016 (UTC)

Vertical alignment
The top of the icon appears to be 1 pixel higher than the surrounding text (which is fine by me, since I only noticed it when zooming in a lot).

What's bugging me is that the lock extends 5 pixels below the numeric characters to the left of the above examples after "0707.0835", and 1 pixel below the  to the right. It would be nice to have it aligned and/or as standardized height (which isn't that straightforward b/c people can use different fonts etc., but perhaps mimicking the default font's height limits is a good place to start). ~ Tom.Reding (talk ⋅dgaf) 16:41, 2 July 2016 (UTC)

Actually, this is more a description of a height issue than a valignment issue, since the lock is valigned (centered) with the, but not with the. ~ Tom.Reding (talk ⋅dgaf) 16:45, 2 July 2016 (UTC)
 * I'm not inclined to change to anything smaller than 9px. When I zoom in on these, the 8px version blurrs unacceptably at lower zoom levels than the 9px version.  I notice that the system external link icon is sharp regardless of the zoom level so that may mean that in the long term we will want to recreate these icons at 8px or 9px width.  Right now the original images are 640×1000px shrunk to 8px or 9px.  I suspect that when we zoom in, all of the resizing artifacts become apparent.
 * [//arxiv.org/abs/0707.0835 0707.0835] Free-to-read lock 75.svg //arxiv.org/archive/math.CT math.CT – 9px
 * [//arxiv.org/abs/0707.0835 0707.0835] Free-to-read lock 75.svg //arxiv.org/archive/math.CT math.CT – 8px
 * —Trappist the monk (talk) 17:17, 2 July 2016 (UTC)

Parameters which are not always free
Two syntaxes have been suggested to specify that a DOI (for instance) is free to read: I think it would be simpler to support only one of these syntaxes. Which one do you prefer? I am not an expert but I think it would be cleaner to implement the second one, because otherwise we might break other tools which expect to find DOIs at doi (for instance, codes that extract citations for Altmetrics, DBpedia or the DOI event watcher). These tools will typically ignore parameters they don't know how to interpret, so they should not be disturbed by an extra doi-free.
 * replacing 10.3842/sigma.2014.079 by 10.3842/sigma.2014.079
 * keeping 10.3842/sigma.2014.079 and adding y (or yes/true) as an extra argument of the template
 * as there would be three different access levels, use a category instead of a boolean value: free, restricted, closed

I guess the same applies for url-free and for any other identifier we might also want to support (what are they?). − Pintoch (talk) 22:59, 4 July 2016 (UTC)


 * I was initially in favour of using 10.3842/sigma.2014.079 because it's less clutter-y than an additional yes in addition to the regular 10.3842/sigma.2014.079, but you do make a very good point concerning bots and tools. I think you may have convinced me yes is the way to go, even if it is more annoying to type. Headbomb {talk / contribs / physics / books} 02:57, 5 July 2016 (UTC)


 * I recommend label access-state rather than the more specific doi-free. A more complex case would (could?) involve accessn-state (n=1, 2, etc.) 72.43.99.138 (talk) 17:43, 5 July 2016 (UTC)
 * That's too complicated and is super unclear (to which parameter would access-state or access1/2/3/etc.-state apply?). If the doi (or other id) is free, then we flag it as that. There's no need to flag each individual identifiers as free/registration required/subscription required/paywalled/embargoed/etc. If it's free flag it. If not, keep it a normal link. For the general url, access can be used. Headbomb {talk / contribs / physics / books} 17:49, 5 July 2016 (UTC)
 * If different lock icons are used for different levels of access then only one parameter need be used for different scenarios: free etc. By the way, the exact naming is not important, but limiting it to doi is imo too narrow. 72.43.99.138 (talk) 19:04, 5 July 2016 (UTC)
 * We are talking here about ways to specify, within a particular citation, different access levels for the different external links in the citation. The functionality you are talking about (defining a particular access state for the whole citation) is already possible via parameters such as subscription. − Pintoch (talk) 20:30, 5 July 2016 (UTC)
 * Rather than a binary "free" property, why don't we store the license ("CC by", "CC by-sa", "PD", etc), with (short) values for "copyright exempt", "out-of-copyright" and "non-free licence, but free to read"? We could still display a limited choice of icon. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 15:34, 12 July 2016 (UTC)
 * I have mixed feelings about this. I think that we want license information to be specified only once for a citation, as license variations among identifiers do not really make sense, whereas access restrictions do. − Pintoch (talk) 19:08, 16 July 2016 (UTC)
 * This is about flagging access, not licensing. Licensing information should go in wikidata/wikicite, not here. Headbomb {talk / contribs / physics / books} 10:37, 18 July 2016 (UTC)
 * I agree that, ultimately, it should. In the meantime, while that is not yet ready to happen, strong it in these templates makes it available for rapid upload when the time comes. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 11:42, 22 July 2016 (UTC)

Mockup

 * Mockup updated at 20:50, 5 July 2016 (UTC) per this thread. The new mockups for subscription/registration/limited trial are found below the old ones, with one more level of indentation.
 * Mockup updated at 16:21, 12 July 2016 (UTC), yellow icon now distinct with a dashed shackle.

I have made a series of icons, based on Trappist's version up there.
 * Lock-green.svg - For no-strings attached free to read sources
 * Lock-yellow.svg [alternative: Registration-required lock.svg/Limited-free-access_lock.svg]- For free registration/first x views ?
 * Lock-red.svg [alternative: Subscription-required lock.svg] - For paywalled/subscription only sources

This way, we can have something like (highlight the icons for tooltips)
 * Subscription
 * { {cite journal |last=Smith |first=J. |year=2016 |title=The Problem with Things |url=http://www.example.com |access=subscription |journal=Journal of Stuff |volume=1 |issue=4 |pages=2–28 |doi=10.1234/56789}}
 * Smith, J. (2016). "The Problem with Things"Lock-red.svg. Journal of Stuff 1(4): 2–28. doi:10.1234/56789.
 * Smith, J. (2016). "The Problem with Things"Subscription-required lock.svg. Journal of Stuff 1(4): 2–28. doi:10.1234/56789.


 * Registration
 * { {cite journal |last=Smith |first=J. |year=2016 |title=The Problem with Things |url=http://www.example.com |access=registration |journal=Journal of Stuff |volume=1 |issue=4 |pages=2–28 |doi=10.1234/56789}}
 * Smith, J. (2016). "The Problem with Things"Lock-yellow.svg. Journal of Stuff 1(4): 2–28. doi:10.1234/56789.
 * Smith, J. (2016). "The Problem with Things"Registration-required lock.svg. Journal of Stuff 1(4): 2–28. doi:10.1234/56789.


 * Limited trial
 * { {cite journal |last=Smith |first=J. |year=2016 |title=The Problem with Things |url=http://www.example.com |access=limited |journal=Journal of Stuff |volume=1 |issue=4 |pages=2–28 |doi=10.1234/56789}}
 * Smith, J. (2016). "The Problem with Things"Lock-yellow.svg. Journal of Stuff 1(4): 2–28. doi:10.1234/56789.
 * Smith, J. (2016). "The Problem with Things"Limited-free-access_lock.svg. Journal of Stuff 1(4): 2–28. doi:10.1234/56789.


 * Free url, but no free id
 * { {cite journal |last=Smith |first=J. |year=2016 |title=The Problem with Things |url=http://www.example.com |access=free |journal=Journal of Stuff |volume=1 |issue=4 |pages=2–28|doi=10.1234/56789}}
 * Smith, J. (2016). "The Problem with Things"Lock-green.svg. Journal of Stuff 1(4): 2–28. doi:10.1234/56789.


 * Free id (pmc)
 * { {cite journal |last=Smith |first=J. |year=2016 |title=The Problem with Things |journal=Journal of Stuff |volume=1 |issue=4 |pages=2–28 |doi=10.1234/56789 |pmc=123456}}
 * Smith, J. (2016). "The Problem with Things"Lock-green.svg. Journal of Stuff 1(4): 2–28. doi:10.1234/56789. PMC 123456Lock-green.svg.


 * Free id (both doi and pmc)
 * { {cite journal |last=Smith |first=J. |year=2016 |title=The Problem with Things |journal=Journal of Stuff |volume=1 |issue=4 |pages=2–28 |doi=10.1234/56789 |doi-access=free |pmc=123456}}
 * Smith, J. (2016). "The Problem with Things"Lock-green.svg. Journal of Stuff 1(4): 2–28. doi:10.1234/56789Lock-green.svg. PMC 123456Lock-green.svg.

Headbomb {talk / contribs / physics / books} 19:48, 5 July 2016 (UTC)

Discussion

 * This seems perfect to me! Just a quick note about OAbot: given the metadata we have access to, we rarely know for sure that an identifier is closed, so the bot will only add green locks. But of course these new features can be used by editors, this discussion goes beyond the scope of OAbot. − Pintoch (talk) 20:25, 5 July 2016 (UTC)
 * The distinction between yellow and green is hard to make out. That could be intentional, but if so, it's a poor decision. Please use more than just color, per MOS:COLOR to make that distinction; a different shape would be beneficial. Also, it appears that yellow is doing a double duty here, and that's also quite problematic. In sum, I'd have to rely on the tooltips to make out which is free (green) vs. limited/registration (yellow), and which meaning of yellow is intended.  Imzadi 1979  →   20:29, 5 July 2016 (UTC)
 * I agree. Maybe the meaning of the intermediate level (yellow) is actually not precise enough to be really useful. But if we find a better way to render it, it surely does not harm offer the feature. − Pintoch (talk) 20:35, 5 July 2016 (UTC)


 * The color can easily be changed, but I went with the usual green/yellow/red in the same tone as Trapist's green. I didn't test/optimize them for accessibility (which certainly should be done), and it would be nice if a different lock could be found for the yellow so that the colorblind could tell them apart without relying on the tooltips. This is more like a 'proof of concept' / 'what the parameters would do' than an actual implementation or even a final look. Headbomb {talk / contribs / physics / books} 20:38, 5 July 2016 (UTC)
 * Trappist has a fairly nice solution below Help_talk:Citation_Style_1. I'll update with alternate examples soon. Headbomb {talk / contribs / physics / books} 20:44, 5 July 2016 (UTC)


 * Instead of doi-free, it would be more flexible to have doi-access with the same range of values as access. Kanguole 21:03, 5 July 2016 (UTC)
 * That makes sense indeed. − Pintoch (talk) 08:25, 6 July 2016 (UTC)


 * I don't really like doi-access (and similar) because it encourages to fill them with 'subscription' and 'registration' etc. I'd rather keep it simple, it's free, or it's not. But I also suspect consensus will be against me, and if it can rid us of those awful 'registration/subscription required' from |subscription=yes, I can live with people combing through citations with |doi-access=subscription or similar.


 * Any feedback ? I feel we've made significant progress at garnering consensus here. Headbomb {talk / contribs / physics / books} 14:12, 12 July 2016 (UTC)
 * Support the color-scheme ones. I use color-inversion on my browser and the alternative icons look terrible, but the G/Y/R locks look as intended with and without inversion.  ~ Tom.Reding (talk ⋅dgaf)  14:52, 12 July 2016 (UTC)
 * You probably aren't the only reader who uses color-inversion so it occurred to me to make the lock color the same as one of the two colors used in the standard exteernal link icon (#06c and #06f). I settled on #07c which has 4.7:1 contrast against white and 4.5:1 against black:
 * free-to-read_lock_blue.svg limited-free-access_lock_blue.svg subscription-required_lock_blue.svg
 * —Trappist the monk (talk) 11:55, 20 July 2016 (UTC)
 * That looks nice too. It is more neutral and fits nicely in the current design. The problem I have with the coloured ones is that I find the red closed lock catchier than the others, which could have the unintended consequence of attracting the attention to closed versions rather than free ones. − Pintoch (talk) 20:03, 20 July 2016 (UTC)
 * , thank you for the contrast consideration. Are there varieties of green, yellow, and red with similar(ish) contrast ratios against white and black backgrounds? If not, then I understand the need for mono-blue. Also, can you make the half-locked one slightly more distinct from the locked version? Maybe fill-in ~40% of the circle instead of 50/50? I have to strain to see the difference otherwise, and would miss it if not shown as an isolated example.  ~ Tom.Reding (talk ⋅dgaf)  21:24, 20 July 2016 (UTC)
 * I too prefer the coloured versions, but the issue mostly is how do you convey 'registration' and 'limited access' to people who can't easily tell colours apart? Headbomb {talk / contribs / physics / books} 15:37, 12 July 2016 (UTC)
 * , how about using a dashed line to form the yellow lock? That would make each of them distinct, and remedy MOS:COLOR concerns raised by below.   ~ Tom.Reding (talk ⋅dgaf)  15:48, 12 July 2016 (UTC)
 * Done. I had just thought of that myself, and updated the mockup. Pretty happy to see that others thought of the same solution. Now I'm no graphic expert, so we can get someone from the WP:GL to put the polishing touches (e.g. make sure the dashes are all symmetrical), and then we can start focusing on the right shade of yellow. Headbomb {talk / contribs / physics / books} 16:21, 12 July 2016 (UTC)
 * Why are the registration/subscription notes "awful"? They are unambiguous and informative, in simple language. How is a gaggle of tiny icons that may easily be overlooked any better? And what would they even mean to the average Wikipedia reader? Who may very well ask why s/he should know one more artificial symbology in order understand something that could be easily written in plain English. 65.209.36.98 (talk) 14:58, 12 July 2016 (UTC)

These render at about the same apparent size for me, despite being 9px and 14px respectively. I'm guessing the latter has wider invisible margins. &#8213; Mandruss  &#9742;  16:25, 12 July 2016 (UTC)
 * Because 1) It's completely non-standard in all citation styles, from those used by the press to those used by the academic community to mention the type of access for each source; 2) Adds a lot of clutter 3) Is completely vague about which of the links requires access. If you see
 * can you tell me which of these links that "(subscription required (help))." refers to? All of them? Which would neglect that the arxiv link is free. Only the main link? Which would neglect the doi is also paywalled. That's without tackling the awful design of the message itself. Open and closed locks like
 * Smith, J. (2016). "The Problem with Things"Lock-green.svg. Journal of Stuff 1(4): 2–28. doi:10.1234/56789Lock-red.svg. PMC 123456Lock-green.svg.
 * It's immediately clear which of those links are openly accessible, and which of these aren't, and much, MUCH, better than
 * Smith, J. (2016). "The Problem with Things" (This source is freely available (help)). Journal of Stuff 1(4): 2–28. doi:10.1234/56789(subscription required (help)). PMC 123456(This source is freely available (help)).
 * Or whatever textual implementation one could design. Headbomb {talk / contribs / physics / books} 15:22, 12 July 2016 (UTC)
 * Remember WP:RF and WP:BITE. This was the IP user's first post so let's start by assuming that he is typical of the non-specialist that WP is aimed at and is trying to be helpful not agressive.  Having to learn new icons just to garner a fact which can easily be written in English is a right pain for the beginner.  As regards your (1): do "all citation styles" apart from wiki have any information on paywalls?  If not the use of text versus icon is irrelevant.  (2) Yes, but less clutter than having to have a page of icon interpretations open.  (3) Agreed, so how can we clarify it without resorting to a writing style abandoned by the Ancient Egyptions?  Perhaps simply noting "(some online resources require registration or a subscription)" at the end of affected citations would be enough? Martin of Sheffield (talk) 15:36, 12 July 2016 (UTC)
 * Hardly my first post, but I appreciate the sentiment. As for the reasoning by HEADBOMB. First it would be a good idea to stop referring to other citation systems. In their rationale, design, and use, they are inapplicable here, because they were all designed for, and by, experts. This citation system is for the benefit of non-expert, general-interest readers and should be designed from the ground up for this audience. Plain language, simplicity, and ease of use should be the design priorities here. Adding yet another layer of symbolic links while removing informative language adds complexity and reduces clarity. Secondly, I have never understood why a non-free link to a source should be included if there is also a free link (assuming equivalent reliability). I do agree that the subscription/registration note is convoluted: the link to help is unnecessary. Overall, I think too much time is given to this narrow area of the citation system anyway. 65.88.88.127 (talk) 18:39, 12 July 2016 (UTC)
 * It was the first post from 65.209.36.98, you're now posting from 65.88.88.127. Ever considered registering so that we know who we are talking to? Martin of Sheffield (talk) 19:45, 12 July 2016 (UTC)
 * You don't need to talk to me, talk to the argument. 72.43.99.146 (talk) 00:37, 13 July 2016 (UTC)
 * Hence why I said 'by the press' as well as 'academic' sources. These citation systems are widespread, and used by a lot more than simply 'experts'. As someone said below, most readers are familiar with symbols, and these should be reasonably clear in their meaning. If you don't know what they mean, we have tooltips. You hover once, and then you know what they mean, and then you save quite a bit of time after than not having to parse dozens if not hundreds of "(registration required)" per article, or multiple "(registration required)" per citation. Headbomb {talk / contribs / physics / books} 19:16, 12 July 2016 (UTC)
 * I've no idea how widespread is the knowledge of MLA, APA or any other citation system among the general Wikipedia readership. The prudent assumption would be on the side of less, not more, knowledge of citation particulars. That should be reflected in the Wikipedia citation system's presentation. Btw, I'm not making a similar argument regarding the technical aspects. The nuts and bolts could be as sophisticated as required. My experience has been that ease-of-use is proportional to design complexity: the easiest to use software is always the most complicated to design and implement. 72.43.99.146 (talk) 00:37, 13 July 2016 (UTC)
 * In the above examples, how is a reader to know what "1(4)" means? There is some level of abstraction required lest the citations become intractable. The relatively low bar set by icons like these are more intuitive than arbitrarily emphasized numbers, yet we have the latter and you argue against the former?  ~ Tom.Reding (talk ⋅dgaf)  18:53, 12 July 2016 (UTC)
 * That's an WP:OTHERSTUFF. Just because one thing sucks doesn't mean the other thing should also suck. (I have no opinion, just pointing it out--if you want to change the formatting of journal references, the "new section" button is at the top.) --Izno (talk) 19:09, 12 July 2016 (UTC)
 * I don't actually want to change "1(4)"; I'm using it to point out the ridiculousness of IP's argument. Also, these icons contain 'less suck' than our consensus-approved citation style, from the perspective of the "how will anyone understand anything that isn't explicitly spelled out in plain English?" argument. IP's argument is inadvertently for the icons, not against.  ~ Tom.Reding (talk ⋅dgaf)  20:40, 12 July 2016 (UTC)
 * That is certainly a novel interpretation. So "subscription required" is more convoluted than something that supposedly looks like a padlock, but at first glance could be anything, and maybe hardly distinguishable. Wait, it is color-coded as well, so I need to know that scheme. And there are these little curvy things (if you can see them), I'm sure they mean something? 72.43.99.146 (talk) 00:37, 13 July 2016 (UTC)
 * MOS:COLOUR warns - rightly - against using colour alone to convey information. For that reason, the first alternative icon on each line is better. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 15:41, 12 July 2016 (UTC)
 * Agreed that the shapes weren't right. I've updated the mockup with a yellow lock with a dashed shackle, although tweak can be made to the exact shade of yellow and dash density. Headbomb {talk / contribs / physics / books} 16:23, 12 July 2016 (UTC)
 * Suggest the more realistic padlock shape produced by, not this stylized shape. &#8213; Mandruss  &#9742;  15:45, 12 July 2016 (UTC)
 * That's File:Padlock.svg - I suggest it won't be clear enough at small size. Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 15:56, 12 July 2016 (UTC)
 * Registration-required lock.svg Padlock-dark-green.svg - You decide. I submit that the latter is the more recognizable of the two, being closer to, for example, the HTTPS padlock shown in my browser. The hasp could be made darker for better visibility, without affecting recognizability (or even improving it a little).
 * Registration-required lock.svg Padlock-dark-green.svg - You decide. I submit that the latter is the more recognizable of the two, being closer to, for example, the HTTPS padlock shown in my browser. The hasp could be made darker for better visibility, without affecting recognizability (or even improving it a little).
 * Your padlock means "secured connection (HTTPS)" to me, especially when it is next to a link. The other lock clearly looks like the standard open access lock in a closed version, so my vote goes for the current mockup (so, your first option). − Pintoch (talk) 22:38, 12 July 2016 (UTC)
 * I also like the current mockup very much. Nice work! Ocaasi (WMF) (talk) 20:21, 13 July 2016 (UTC)

Now that the discussion has stabilized, should we implement the current mockup in the sandbox? − Pintoch (talk) 18:56, 19 July 2016 (UTC)
 * Thanks for pushing the code to the live module! So, for now arxiv, rfc and pmc (when it is not marked as embargoed) are marked as free to read. I have not noticed any problem in the wild. I will try to implement the current mock-up in the sandbox in the coming days. − Pintoch (talk) 07:34, 1 August 2016 (UTC)

Implementation
I have implemented the mockup in the sandbox. You can try it out with.



For now it only covers access and doi-access, we might want to add other ones such as hdl-access. In the case above we replace the PDF icon with our icon, not sure whether this is a feature or a bug. What do you think? I also wanted to throw an error when access was provided without url (and similarly for doi-access / doi) but for some reason the error does not show up (any idea why?) − Pintoch (talk) 20:42, 1 August 2016 (UTC)
 * You must have fixed it because this shows an error:
 * I tweaked the doi version because, as written, the error message code wasn't pointing to a valid  table member.  That fixed, this shows an error:
 * I do not think that the rendered url-linked title should ever have the free-to-read lock. That, to me, is just so much clutter.  access should be constrained to limited, registration, and subscription.  Neither do I think that all identifiers (doi, bibcode, etc) have the subscription-require lock because that too is the norm so just more clutter.  We should be identifying the exceptions with these icons: the norm for url-linked titles is free-to-read; the norm for most identifiers is subscription-required.  When the title link or the identifier does not adhere to the norm, then we should say so.
 * I tweaked the doi version because, as written, the error message code wasn't pointing to a valid  table member.  That fixed, this shows an error:
 * I do not think that the rendered url-linked title should ever have the free-to-read lock. That, to me, is just so much clutter.  access should be constrained to limited, registration, and subscription.  Neither do I think that all identifiers (doi, bibcode, etc) have the subscription-require lock because that too is the norm so just more clutter.  We should be identifying the exceptions with these icons: the norm for url-linked titles is free-to-read; the norm for most identifiers is subscription-required.  When the title link or the identifier does not adhere to the norm, then we should say so.
 * I do not think that the rendered url-linked title should ever have the free-to-read lock. That, to me, is just so much clutter.  access should be constrained to limited, registration, and subscription.  Neither do I think that all identifiers (doi, bibcode, etc) have the subscription-require lock because that too is the norm so just more clutter.  We should be identifying the exceptions with these icons: the norm for url-linked titles is free-to-read; the norm for most identifiers is subscription-required.  When the title link or the identifier does not adhere to the norm, then we should say so.
 * I do not think that the rendered url-linked title should ever have the free-to-read lock. That, to me, is just so much clutter.  access should be constrained to limited, registration, and subscription.  Neither do I think that all identifiers (doi, bibcode, etc) have the subscription-require lock because that too is the norm so just more clutter.  We should be identifying the exceptions with these icons: the norm for url-linked titles is free-to-read; the norm for most identifiers is subscription-required.  When the title link or the identifier does not adhere to the norm, then we should say so.


 * Further,  and   should not use a yellow-ish lock color because the contrast value between that color and the background fails to meet the WCAG contrast standard.  And, making a darker yellow makes it not yellow.  For this reason, I favor shape over color and is why I suggested the blue locks:
 * free-to-read_lock_blue.svg limited-free-access_lock_blue.svg subscription-required_lock_blue.svg
 * —Trappist the monk (talk) 11:20, 2 August 2016 (UTC)


 * About the errors: that's interesting, here I do not see any error your examples (I tried logging out, changing browser, changing IP: still no error). But thanks for fixing my typo anyway.
 * About the free-to-read lock on the title: I thought the consensus was to keep it as it is present in the mockup. I'm not sure why we should purposely restrict which access levels are allowed for each parameter. The idea that some of them are open or closed by default is quite subjective (for instance, if I am a chemist, I will consider that url is closed by default). And what about hdl for instance? (HDL are mostly used to link to institutional repositories, where the full text might or might not be available, it's not clear what the default would be.) So I think it is fine to allow editors to use free to add a free-to-read lock on url. (That does not necessarily imply that we want to run a bot to add free at a large scale.) Actually, with your blue version of the icons, I don't think it would add much clutter as the blue lock would essentially replace the "external link" icon without being much catchier. I have included the colored ones because it seems to me that there was a consensus for them (now that the shapes are different) but of course it's easy to change. − Pintoch (talk) 12:40, 2 August 2016 (UTC)
 * Because you hid them. I have unhidden them so you should be able to see them.  See also: Help:CS1 errors
 * Yeah, people like color and that is reflected in the discussion. But, people also noted that color is problematic when it comes to readers' color perception.  And it is readers who matter most in this case.
 * Why would a chemist assume that url is closed by default? What is it about that occupation that leads them to believe that?
 * In general, identifier links do not lead to free-to-read content; arxiv, pmc, rfc excepted. Because the goal here, as I understand it, is to highlight for readers those links that are free-to-read, we should flag those that are and leave the rest with the default WP external link icon.  If an hdl link is free-to-read, mark it as such else don't mark it.
 * In the vast majority of cases, a linked citation title does lead to a free-to-read source. When this is not the case, editors currently use registration and subscription which identify the exceptions.
 * —Trappist the monk (talk) 15:57, 2 August 2016 (UTC)
 * Thanks, I can see the errors indeed!
 * About chemistry, it's just that the vast majority of papers in this field are paywalled and researchers rarely upload their papers to repositories. If I read Wikipedia articles about chemistry, I will not expect to find free-to-read full texts by clicking on the title of a source. So if by chance one of them is available (and not via a parameter), it is useful to have the free-to-read lock on url. (Chemistry is just the extreme example, but many other fields don't do much better than that unfortunately.) If free is forbidden, how should we indicate that the link is free to read? People have been using the template next to CS1 templates, but I think it is quite sad to resort to that while we could integrate it within CS1. − Pintoch (talk) 17:04, 2 August 2016 (UTC)
 * I suspect that the chemistry topic, when compared to all other topics at Wikipedia that also use cs1|2, is relatively small. I also suspect that the majority of the 2.97 million articles using cs1|2 use url to link the title to a free-to-read source. That is the norm.  In the cases where url links to a paywall or registration, we have had available registration and subscription and their progenitor templates  and.
 * When title links take the reader to a paywalls or registration forms, this is not the norm. We  highlight the title link with an appropriately shaped lock icon.  This is in keeping with our past use of registration and subscription.
 * But, you are going rise to assert that I want it both ways. I don't think that I do.  We do not highlight the norm.  We know that all of the named identifiers, excepting those that I mentioned in a previous post, for the most part, link to registration forms or paywalls.  That is the norm and we do not highlight the norm.  When there is a free-to-read source linked from an identifier, we  highlight that with the appropriately shaped lock icon.
 * —Trappist the monk (talk) 00:53, 3 August 2016 (UTC)
 * I suspect that the chemistry topic, when compared to all other topics at Wikipedia that also use cs1|2, is relatively small. I also suspect that the majority of the 2.97 million articles using cs1|2 use url to link the title to a free-to-read source. That is the norm.  In the cases where url links to a paywall or registration, we have had available registration and subscription and their progenitor templates  and.
 * When title links take the reader to a paywalls or registration forms, this is not the norm. We  highlight the title link with an appropriately shaped lock icon.  This is in keeping with our past use of registration and subscription.
 * But, you are going rise to assert that I want it both ways. I don't think that I do.  We do not highlight the norm.  We know that all of the named identifiers, excepting those that I mentioned in a previous post, for the most part, link to registration forms or paywalls.  That is the norm and we do not highlight the norm.  When there is a free-to-read source linked from an identifier, we  highlight that with the appropriately shaped lock icon.
 * —Trappist the monk (talk) 00:53, 3 August 2016 (UTC)
 * But, you are going rise to assert that I want it both ways. I don't think that I do.  We do not highlight the norm.  We know that all of the named identifiers, excepting those that I mentioned in a previous post, for the most part, link to registration forms or paywalls.  That is the norm and we do not highlight the norm.  When there is a free-to-read source linked from an identifier, we  highlight that with the appropriately shaped lock icon.
 * —Trappist the monk (talk) 00:53, 3 August 2016 (UTC)


 * Like all readers, chemists should be aware that they are using Wikipedia, a general-purpose encyclopedia geared toward non-experts. Their expectations regarding citations should accommodate that fact. 72.43.99.146 (talk) 14:45, 3 August 2016 (UTC)


 * Let's look at the facts. I've randomly taken 100 templates with a url and checked if I could access the full text from the given URL. Here are the results: 59 were open, 25 were closed and 16 were broken. Note that a good proportion of the open ones are not scholarly citations (which should rather use  or  according to the guidelines). So free to read is the majority, yes, but not the norm. So just let the community choose! Let them add any access level on their own, they will use the lock if they find it useful. I don't see why we should assert what information editors  or  add in a futile case like this. − Pintoch (talk) 17:25, 3 August 2016 (UTC)
 * Are you forgetting that there are 23 other cs1 templates and ? All of them support url so shouldn't you be examining the whole pie and not just a slice of it?
 * —Trappist the monk (talk) 22:41, 3 August 2016 (UTC)
 * Yes I am aware that is not the only CS1 template... (my previous message mentions  and ). I analyzed  because I think this is where free would be needed the most. I think it does not hurt to forbid free for, say (although I am not sure it is actually useful to do so), but surely we need it at least for . − Pintoch (talk) 06:41, 4 August 2016 (UTC)
 * It is best to have one rule that applies to cs1|2 globally than to have separate rules for individual templates because editors get confused when that happens. We just undid a long-standing condition with regard to parentheses and publisher.  Consistency is important to editors who use these templates.  We should not allow the application of access to have context-specific meaning unless the benefits gained far outweigh the troubles that come with it: code complexity and maintenance, documentation, support questions that need to be answered, ...
 * —Trappist the monk (talk) 10:45, 4 August 2016 (UTC)
 * I totally agree we should keep the code as simple as possible, and therefore… allow the same set of values for access, doi-access and others, regardless of the template, as it is currently implemented. Otherwise, as you say, we will have to answer support questions such as this one we have got a few days ago. - Pintoch (talk) 12:01, 4 August 2016 (UTC)
 * Do not put words into my mouth that I have not spoken. I did not say that we should keep the code as simple as possible.  You wrote: it does not hurt to forbid free for, say (although I am not sure it is actually useful to do so), but surely we need it at least for.  You expressed certainty in the one case and indifference in the other.  My reply to that was in regard to different code for different templates, to wit, given the same parameters, code that causes  to render differently from, should be avoided unless it is required by style guides, MOS, or the purpose of the template, etc.  The application of a little green lock to a title link is not necessary because title links almost always lead to free-to-read sources.  Do not highlight the norm.
 * I think that the post you refer to is the sort of user support question that we want. It draws our attention (again) to the inadequacies of registration and subscription.  I referred that editor to this discussion but apparently that editor has not elected to participate here.
 * —Trappist the monk (talk) 11:02, 5 August 2016 (UTC)
 * If free is forbidden, how should we indicate that the link is free to read?
 * By not including any icon? 65.88.88.126 (talk) 18:46, 2 August 2016 (UTC)
 * By not including any icon? 65.88.88.126 (talk) 18:46, 2 August 2016 (UTC)


 * Well, unless most paywalled url are marked as such, not including any icon will not indicate much. Tagging all paywalled sources with the appropriate lock is very difficult (if you know how to automate that at Wikipedia's scale, I'm very interested). So we cannot assume that once these icons will be live, the absence of an icon will mean "free to read". − Pintoch (talk) 18:58, 2 August 2016 (UTC)
 * I agree that a url source behind a registration form or paywall should be marked because that condition is not the norm. Because there isn't an automatic way to know the access status of a source, readers can never be perfectly confident that editors didn't omit access, that editors didn't assign it the correct value, ....  No sense in worrying about it.  To aid editors, we establish one simple rule: we do not highlight the norm.  We reinforce that rule by deciding that access accepts ,  , and  .  Similarly, for named identifiers, one simple rule: we do not highlight the norm and we reinforce that rule by deciding that -access accepts.
 * —Trappist the monk (talk) 00:53, 3 August 2016 (UTC)
 * So, in my example above, you would omit both locks? That's quite different from what we agreed on in the mockup. But if there is actually consensus for that, concretely that's good news for me, because then OAbot will not be able add any access or -access, so we can go straight to the Bot Approvals Group without waiting for the new version of CS1 to be rolled out. (OAbot would only be capable of adding new url and the corresponding free or parameters that are always free such as arxiv or pmc.) But then again, I think it is also sad to forbid subscription… − Pintoch (talk) 06:41, 4 August 2016 (UTC)
 * If you mean the example at the top of this section, then yes, I would omit both locks. I don't think that OAbot should be adding free for new url.  If url points to a free-to-read source, an icon is not needed.
 * —Trappist the monk (talk) 10:45, 4 August 2016 (UTC)
 * This is a circular argument. By the same token, tagging all non-paywalled sources with the appropriate lock would also be difficult. Once either of the two difficulties is surpassed, you will be able to safely assume that the other option applies. When this happens, and for the sake of simplicity, not adding the free-access icon will have the same effect. 65.88.88.126 (talk) 19:09, 2 August 2016 (UTC)


 * Sure, tagging all non-paywalled sources would be equally difficult. The point is that none of these are going to happen any time soon. Look, the OA signalling project has been running for a few years now and automated tagging of OA sources was its main goal, but nothing really happened: because it's very hard. So, as we cannot count on a decent automated coverage for any of the access levels, the absence of an icon is not going to carry information in the foreseeable future. Therefore we should allow editors to specify manually the access level of a url if they whish to do so. I don't think there is any circular argument here. − Pintoch (talk) 19:35, 2 August 2016 (UTC)

Parameter label
The label "access" is bound to cause confusion because it is too generic. It is conceivable that it could be mistaken for "url", "via", "access-date", "website" etc. Also: most people do not read the documentation anyway, and this label already has well-established meanings in everyday language. Naturally, editors may carry these meanings in editing CS1 templates. And that would be correct. After all, why should "access" have a special meaning here? Flagging such errors in code is "fixing" an unnecessary flaw. It is better to give more thought to this before hand, there are enough design flaws in the code already. It was suggested that "access-state" be used (but any such label would do). This is better because it is more specific, and also specialized enough to perhaps prompt somebody to look in the doc and find out what "access-state" actually means in this context. Assuming the doc is written clearly. I'm not really holding my breath. 65.88.88.126 (talk) 15:38, 5 August 2016 (UTC)


 * I agree. Again, I just followed the current state of the mockup. "access-state" sounds good to me. Would you also change "doi-access" to "doi-access-state"? − Pintoch (talk) 18:01, 5 August 2016 (UTC)


 * That's way too wordy. Access is short (which is IMPORTANT for parameter names), concise, and accurate. If it's confused with accessdate, we can throw out an error message saying 'you have put a date in |access=, to indicate the date at which you've accessed this source, use |accessdate=". Headbomb {talk / contribs / physics / books} 16:03, 9 August 2016 (UTC)


 * It is more important imo that people who are not professional editors be able to contribute a citation easily, and not to have to divine what an everyday term means when it comes to Wikipedia's citation system. Nor should they have to wade through voluble and poorly done documentation. It is also important to do preventive, not just reactive (such as error-control), software design. "Access" in this context does not mean any of the many different things that access implies. It means very specifically the condition (state) of access to a source. Just as "access-date" is specific to the date of access. Conceivably, "access-date" could be named "date2" or "access" or "ad" or "access2". These are less wordy too. The fact that we have to discuss this is an indication of something, and not pretty, imo. 65.88.88.127 (talk) 18:41, 9 August 2016 (UTC)


 * Except "access" to describe a date is clearly wrong, while "access" to describe what access readers have is correct. However, turning things |doi-access= into |doi-access-date is unnecessarily wordy. Brevity is important, adding |bibcode-access-state=, |doi-access-state=, or |zbl-access-state= etc is just pointlessly wordy when |bibcode-access=, |doi-access=, |zbl-access= are just as clear. The concern about newcomers not understanding what |access= or |doi-access= would be for is misplaced since none of these currently exists and newcomers won't know the parameter even exists unless they read the documentation, or copy-pastes from an existing citation which would have the correct usage. If for some reason, newcomers still fail to properly use the parameters, there will be error messages displayed, and many gnomes to clean up after them. Headbomb {talk / contribs / physics / books} 20:18, 9 August 2016 (UTC)


 * The meaning of access you describe is clear to you because you are involved in this discussion. As pointed out above, cleaning up after the fact when you have a good chance of avoiding the mess beforehand is a counter-productive. Because most people do not delve deeply in the doc. (In the case of CS1 doc that may be a good thing). They might as well see the list of parameters and pick the ones that make sense to them for whatever they want to cite. Bad edits, and questions by users that result from pure carelessness or inattention to detail are rife all over this encyclopedia. It's best to code for stupid. As the old geek saying goes, no matter how idiot-proof you make it, they keep making a better idiot. 72.43.99.146 (talk) 00:28, 10 August 2016 (UTC)

Most commonly used parameters
In Template:Cite_web, the sample with the most commonly used parameters, which I guess, I am not the only to paste regularly for use, should include the following parameters: | archive-url = | archive-date = | dead-url = The reason is to lure more editors to archive links or get archived links to resist link rot. Ever more I find dead links and source has already disappeared from the web. --Robertiki (talk) 18:04, 12 August 2016 (UTC)

New parameters to suppress maintenance false positives.
Add parameters / /  which Module:Citation/CS1   should check for before adding the page to Category:CS1 maint: Multiple names: authors list/Category:CS1 maint: Multiple names: editors list/Category:CS1 maint: Multiple names: translators list‎. This will allow editors to suppress false positives where a single author has a name which the module thinks looks like multiple authors. See Category talk:CS1 maint: Multiple names: authors list jnestorius(talk) 11:04, 10 August 2016 (UTC)
 * Instead of basing it on working around a bug, perhaps it would be better to add finer-grained semantics. How about a new parameter like corporate-author to contain the name of a corporate author (regardless of how it is punctuated) and similarly for editors and translators?  Kanguole 11:25, 10 August 2016 (UTC)
 * This is sound reasoning, but I'd like to point out that there are already free-form parameters for that (authors, editors, others, and aliases such as ). 72.43.99.146 (talk) 13:51, 10 August 2016 (UTC)
 * How does using authors instead of author match the semantics of a single (corporate) author? And use of that param is deprecated. jnestorius(talk) 14:44, 10 August 2016 (UTC)
 * authors is not deprecated. Nothing suggests to me that it must be used for multiple authors. It can be used for any author because it is a free-form field. That single author may or may not have multiple names, or/and roles indicated. 72.43.99.146 (talk) 14:55, 10 August 2016 (UTC)
 * For example, cf. use of others, another non-deprecated free-form parameter that may include a singular name. 72.43.99.146 (talk) 14:57, 10 August 2016 (UTC)
 * My mistake, it is "discouraged" rather than "deprecated". See Category:CS1 maint: Uses authors parameter. It doesn't seem optimal to remove one spurious maintenance category by adding another. jnestorius(talk) 15:25, 10 August 2016 (UTC)
 * One can't be sure corporate-author will handle all cases; what if the author is "John, Marquess of Foo, Bar, and Baz"? The fact is that any automated parsing of natural language is imperfect and will throw up errors; in this case, adding inappropriate maintenance categories. The most general solution would be a single suppress-maintenance-category param with comma-separated values, e.g.  . jnestorius(talk) 14:44, 10 August 2016 (UTC)
 * Is it that you just don't like the little green text in your citations? We know that there is an issue with authors (plural).  The size and scope of that issue was unknown until we added  which hardly makes it spurious.
 * Adopting Editor Kanguole's suggestion, I think, may address the issues that you've raised here, yet you seem opposed that that kind of a solution. Care to elaborate on your opposition with examples of why it will not work?
 * —Trappist the monk (talk) 00:50, 11 August 2016 (UTC)
 * Of course the maintenance category is spurious. It does not concern the validity of either the affected template or the citation. It tracks individual preferences of style and presupposes that metadata is more important than data. And the solution to this non-existent problem is even more complexity? Not to mention the additional documentation. This is going to be fun. 64.134.96.40 (talk) 01:35, 11 August 2016 (UTC)
 * No, it suggests that metadata, in addition to data, is important. We have data whether we use authors, authorn, or lastn/firstn. But from the point of view of "let us extract everything of value that we can from the template", only one of those provides the most value. If you're concerned regarding clutter, that's something you're going to get regardless of which citation style (hand-jammed or template) you use--the only way to remove such is to be using a WYSIWYG editor (yes, that's the only way). The view that changing the particular parameters in a particular template citation is a change in style was quite firmly rejected per the closure of this recent RFC. --Izno (talk) 11:58, 11 August 2016 (UTC)
 * For those who consume cs1|2 metadata renderings, missing or malformed information is just as much a problem as it is for those who consume cs1|2 visual renderings. The two renderings are of equal importance.  The data in authors (plural) are not included in the metadata because there is no   keyword in the metadata standard.  All information in authors (or any of its aliases) is missing from the metadata rendering of a template and that does concern the validity of the template and the citation.
 * —Trappist the monk (talk) 12:06, 11 August 2016 (UTC)
 * So by all means fix the metadata, and stop trying to limit the choices or trying to enforce a discrete-author style on the creators of the data. Because obviously metadata is not as important as data: only one of these two depends on the other. 65.88.88.127 (talk) 19:53, 11 August 2016 (UTC)
 * I guess you did not read, or did read and have elected to ignore, the part of my post where I wrote: there is no keyword in the metadata standard.  So let me elaborate.  The standard does not support the concept of multiple author-names in a single key/value pair.  It supports multiple authors by allowing an unlimited number of   key/value pairs (one author-name (the value) per key).  Because it is a standard established and maintained outside of Wikipedia, we cannot 'fix it'.  But, we can adapt to it by perhaps adopting Editor Kanguole's corporate-author suggestion.
 * If we revert to the dictionary definition of 'metadata', then its colloquial use here is only vaguely correct. cs1|2 templates produce two renderings: the visual rendering that can be seen at the bottom of a great many Wikipedia articles; and the so-called metadata rendering that is not visible but is consumed by Wikipedia users through various digital tools.  There is no pure 'data describing data' output from the cs1|2 templates.  Both renderings contain as much of the original data as can be supported by the standards to which they are rendered.  Complete and correct renderings are equally important to the respective users.
 * —Trappist the monk (talk) 00:46, 12 August 2016 (UTC)
 * I believe editor Kanguole was suggesting corporate-author as a free-form parameter, though one that is unnecessarily narrow (why limit it to "corporate"?). And yes, it seems that the code may be trying to do too many things, not all of them well. 72.43.99.146 (talk) 15:06, 10 August 2016 (UTC)
 * Are there such things as corporate editors? Corporate translators?  I rather like the corporate-author parameter.  Because it identifies its content, editors know what it's for and the module will know to ignore commas. We can enumerate them: corporate-authorn.
 * What to do when this parameter is mixed in a template with authorn? Do we decide that corporate authors are rendered at the end of the author name-list?  Or, do we list author names and corporate-author names in a single list where the enumerator decides where each name goes in the list? (this is the much more difficult of these possible options because corporate-authorn is not an alias of last).  Unlike authors (plural), corporate-author can be made part of the citation's metadata because it holds one corporate name.
 * —Trappist the monk (talk) 00:50, 11 August 2016 (UTC)
 * I would prefer the latter, personally. I suspect most will have a similar preference, since people will be likely to want to retain the order of the authorship in the source being cited. --Izno (talk) 11:58, 11 August 2016 (UTC)
 * What to do when this parameter is mixed in a template with authorn? Do we decide that corporate authors are rendered at the end of the author name-list?  Or, do we list author names and corporate-author names in a single list where the enumerator decides where each name goes in the list? (this is the much more difficult of these possible options because corporate-authorn is not an alias of last).  Unlike authors (plural), corporate-author can be made part of the citation's metadata because it holds one corporate name.
 * —Trappist the monk (talk) 00:50, 11 August 2016 (UTC)
 * I would prefer the latter, personally. I suspect most will have a similar preference, since people will be likely to want to retain the order of the authorship in the source being cited. --Izno (talk) 11:58, 11 August 2016 (UTC)
 * I would prefer the latter, personally. I suspect most will have a similar preference, since people will be likely to want to retain the order of the authorship in the source being cited. --Izno (talk) 11:58, 11 August 2016 (UTC)


 * anwering some of your points from 00:50, 11 August 2016
 * I should not have implied that is "spurious". What I meant was "It doesn't seem optimal to remove a [spurious] maintenance category by adding another [non-spurious] maintenance category, rather than fixing the format so that there are no maintenance categories".
 * "you seem opposed that that kind of a solution. Care to elaborate on your opposition with examples of why it will not work" -- I am not opposed to adding corporate-author but I am sceptical that it will address all problems. I already gave one example ("John, Marquess of Foo, Bar, and Baz").  I have no idea how common such cases will be.  I think it's usually worth having an override option to handle any unforeseen errors; but if the processing cost is high and the errors are rare it may not be.
 * As regards corporate-author
 * corporate-author needs to be corporate-authorn for the multiple case
 * we might replace Smith, Jones, and Foo with Smith, Jones, and Foo Y -- this allows interleaving of corporate and non-corporate authors and might be easier to code
 * jnestorius(talk) 11:35, 12 August 2016 (UTC)
 * In the discussion that caused the creation of, I suggested that the accept-this-as-it-is-written mechanism used in vauthors, the parameter value wrapped in doubled parentheses, could be applied to author to suppress categorization. So your contrived example would be written: ((John, Marquess of Foo, Bar, and Baz)).  That idea was dismissed but I raise it again as a solution to the false positive problem that does not require the introduction of new parameters and their attendant code an documentation.
 * —Trappist the monk (talk) 10:38, 13 August 2016 (UTC)


 * Thanks, that would have my support. (Theoretically if the value violates two criteria but only one is a false positive then a blanket accept-as-is is too blunt an override, but even I would regard that case as too finicky to worry about.) Of course it still needs a modicum of documentation, so that editors know that it can and should be done. jnestorius(talk) 14:22, 13 August 2016 (UTC)


 * I am continuing the discussion here, although it is more pertinent to Trappist's comments above.
 * Limitations in software should not dictate the behavior of human editors. The onus of change is on the software, especially when it is not vital. The rendering of metadata is a convenience, that happens to be entirely supefluous: the target audience of Wikipedia can always, directly and freely, access this site without going through middleware. Neither is this site difficult to use: so rendering the information in a different interface (the main objective of middleware) has no practical significance.
 * Wikipedia exists to provide verifiable, reliable content. The existence of such content trumps questions of style or automation, including the transmission of COinS biblio metadata. Contributors should be made as comfortable as humanly possible in providing such content. Limiting their options because a digital tool (that has no meaning without contributions) is not up to the task is the wrong way to go about it. From that principle, you can drill down to the current discussion: the maintenance category in question is a waste of time. It increasingly seems that application of COinS in Wikipedia is heading in that direction too. It is even more egregious when it results in increased complexity, as the so-called "solutions" offered here. Especially when there are other, more significant and pressing problems. 72.43.99.138 (talk) 13:01, 12 August 2016 (UTC)


 * It seems your concerns are broader and deeper and that this is too specific a discussion to raise them. I hardly think a category that is invisible to most editors and all non-logged-in readers worsens their user experience. Content can be added via authors and viewed by readers, as you would wish; readers and editors need not worry or even know about the concomitant CS1 issues if they don't want to. If someone patrolling the maintenance category comes along and modifies the format to make it CS1 compliant, there is no loss to those who don't care about metadata. This discussion is about facilitating the work of such patrollers; I agree that solutions which make life harder for CS1-disdainers should be avoided, but I don't think that makes the whole issue pointless. jnestorius(talk) 15:03, 12 August 2016 (UTC)
 * Things don't happen in a vacuum; we are having this discussion because "authors" does not render metadata and because some people would prefer another style for cases it would be used. These gave rise to this category. The category's flags prompted your OP. And the proposal is devolving into even more complexity and minutiae. So there we are. 24.193.13.32 (talk) 23:07, 12 August 2016 (UTC)


 * You can carry on using authors if you like: if others tweak it later it doesn't affect you; if those same others discuss how best to tweak it it doesn't affect you; if you think tweaking is a waste of time it doesn't affect you. jnestorius(talk) 01:51, 13 August 2016 (UTC)


 * Sure, but this not just about authors. Since this free-form parameter is "discouraged", an easy solution to the problem described in your original post gets a hiccup. The proposed workarounds introduce complexity to CS1 in general, and who knows what kinds of complications. And I think, likely additional bewilderment on the part of the average user. 72.43.99.146 (talk) 15:14, 13 August 2016 (UTC)