Help talk:Citation Style 1

From Wikipedia, the free encyclopedia
Jump to: navigation, search
the Wikipedia Help Project (Rated B-class, High-importance)
WikiProject icon This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.
B-Class article B  This page does not require a rating on the project's quality scale.
 High  This page has been rated as High-importance on the project's importance scale.

Adding open access links to references[edit]

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={{citeseerx|...}}, 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= + |doi-free=yes or using |doi-free=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
{{cite journal |last=Smith |first=J. |year=2016 |title=Article of things |journal=Journal of Things |volume=66 |issue=3 |pages=11–15 |doi-free=10.1234/0123456789}}
Smith, J. (2016). "Article of things Open Access logo PLoS white green.svg". Journal of Things 66 (3): 11–15. doi:10.1234/0123456789 Open Access logo PLoS white green.svg.
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. @Ocaasi: can you raise this at WP:TWL? − Pintoch (talk) 07:47, 9 June 2016 (UTC)
Pintoch, 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)
Ocaasi (WMF): ping, can you gather discussion there? For now we can't really say we have a consensus. Headbomb, Matthiaspaul, Trappist the monk, 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 |format=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:
<span class="plainlinks">[ Article of things]</span>
Article of things
then for the lock image with a bit of css to slightly separate the lock from the url:
<span style="margin-left:.1em">[[File:Open_Access_logo_PLoS_white_green.svg|9px|link=|open access publication - free to read]]</span>
and put it all together:
{{cite journal |last=Smith |first=J. |year=2016 |title=Article of things |journal=Journal of Things |volume=66 |issue=3 |pages=11–15 |doi-free=10.1234/0123456789}}
Smith, J. (2016). "Article of thingsopen access publication - free to read". Journal of Things 66 (3): 11–15. doi:10.1234/0123456789open access publication - free to read.
Trappist the monk (talk) 12:40, 22 June 2016 (UTC)
Trappist the monk: 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)

Oiyarbepsy: 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#why is the lock orange?.

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 |alt=open access publication - free to read. I see that alt text when I hover my mouse cursor over the lock: open access publication - free to read. 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 ({{cite journal}}, 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:
[[File:Open_Access_logo_PLoS_white_green.svg|8px]]Open Access logo PLoS white green.svg – Headbomb
[[File:Open_Access_logo_PLoS_white_green.svg|9px|link=|open access publication - free to read]]open access publication - free to read – ttm
Trappist the monk (talk) 00:55, 24 June 2016 (UTC)

adding free-to-read icons[edit]

Because of this comment, I have modified the external_link_id(), and arxiv() functions in Module:Citation/CS1/Identifiers/sandbox to replace the standard external link icon with a green lock:

  • Sparling, George A. J. (2006). "Spacetime is spinorial; new dimensions are timelike". arXiv:gr-qc/0610068free to read. 
  • Leinster, Tom (2007). "The Euler characteristic of a category as the sum of a divergent series". arXiv:0707.0835free to read [math.CT]. 

The lock here is one that I modified from File:Open_Access_logo_PLoS_white_green.svg (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:

Open Access logo PLoS white green.svgFree-to-read lock.svg

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-free|}}}


      if {{{id-free|}}}


            if {{{access|}}}
            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 |access=registration and |access=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 |url-free=pmc} or |url-free=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):

I like conciseness. I suppose it depends on the question: Just how important is it for the reader to understand the situation before they click through? It could take decades before a majority of readers who look at sources (1) have noticed those little locks and (2) have learned what they mean. We have little PDF icons, but the PDF logo is fairly widely recognized already (I think).
— User:Mandruss 16:27, 22 June 2016 (UTC) (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.
Headbomb: 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?
Trappist the monk: 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.svgK – 9px lock image
We might shrink the lock:
qOpen Access logo PLoS white green.svgK – 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:
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:0707.0835free to read [math.CT]. 
  • Leinster, Tom (2007). "The Euler characteristic of a category as the sum of a divergent series". arXiv:0707.0835free to read [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 |subscription=yes text. Something like this:
Smythe, Johnstone P. B. (1986). "Title of something requiring registrationsubscription required". 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:
Open Access logo PLoS white.svgFree-to-read lock 75.svg
Trappist the monk (talk) 17:23, 1 July 2016 (UTC)
Trappist the monk: 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[edit]

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. Ocaasi t | 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 Ocaasi t | c 22:14, 30 June 2016 (UTC)

Vertical alignment[edit]

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 (talkdgaf)  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 0835.   ~ Tom.Reding (talkdgaf)  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.
0707.0835free to read [math.CT] – 9px
0707.0835free to read [math.CT] – 8px
Trappist the monk (talk) 17:17, 2 July 2016 (UTC)

Parameters which are not always free[edit]

Two syntaxes have been suggested to specify that a DOI (for instance) is free to read:

  • replacing |doi=10.3842/sigma.2014.079 by |doi-free=10.3842/sigma.2014.079
  • keeping |doi=10.3842/sigma.2014.079 and adding |doi-free=y (or |doi-free=yes/|doi-free=true) as an extra argument of the template
  • as there would be three different access levels, use a category instead of a boolean value: |doi-access=free, |doi-access=restricted, |doi-access=closed

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

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 |doi-free=10.3842/sigma.2014.079 because it's less clutter-y than an additional |doi-free=yes in addition to the regular |doi=10.3842/sigma.2014.079, but you do make a very good point concerning bots and tools. I think you may have convinced me |doi-free=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.) (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: |access-state=free|registration|subscription|limited etc. By the way, the exact naming is not important, but limiting it to doi is imo too narrow. (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)
Pigsonthewing: 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 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 ([[File:Lock-GREEN/YELLOW/RED.svg]]), 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)

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


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#Partial_paywall_and_subscription.3Dy. 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 TrappistTheMonk (talk · contribs)? 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 (talkdgaf)  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 limited free access subscription required
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)
Trappist the monk, 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 (talkdgaf)  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)
Headbomb, 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 Pigsonthewing below.   ~ Tom.Reding (talkdgaf)  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. (talk) 14:58, 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
Smith, J. (2016). "The Problem with Things". Journal of Stuff 1 (4): 2–28. arXiv:1201.0123. doi:10.1234/56789. (subscription required (help)). 
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"A free version of this source can be accessed here. Journal of Stuff 1(4): 2–28. doi:10.1234/56789A (paid) subscription is required to access this source. PMC 123456A free version of this source can be accessed here.
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. (talk) 18:39, 12 July 2016 (UTC)
It was the first post from, you're now posting from 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. (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. (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 (talkdgaf)  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 (talkdgaf)  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? (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 {{pp}}, not this stylized shape. ―Mandruss  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).
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. ―Mandruss  16:25, 12 July 2016 (UTC)
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)

dates other than year in |year=[edit]

I'm in the process of cleaning out Category:CS1 maint: Date and year and have found several templates like this one where |year= holds more date detail than just the year:

{{Cite news| url=|title=Intertek shares soar on speculation of bid from Swiss rival SGS|accessdate=30 August 2010|publisher=The Telegraph| year=23 Apr 2009 | location=London | first=Louise | last=Armitstead | date=23 April 2009}}
Armitstead, Louise (23 April 2009). Intertek shares soar on speculation of bid from Swiss rival SGS. London: The Telegraph. Retrieved 30 August 2010. 

It seems to me that |year= should hold just that, a year with optional circa and/or optional CITEREF disambiguator.

Trappist the monk (talk) 12:55, 10 June 2016 (UTC)

Looking further at this, a 'solution' is problematic. Before we do the date validation, we look at the values of |date=, |year=, and |publication-date=. If |date= is not set, we promote the first set of |year= or |publication-date= to |date=. So, when |date= is not set and |year=23 Apr 2009, we make |date=23 Apr 2009 and |year= becomes nil. Because '23 Apr 2009' is a valid date, and no longer associated with |year=, there is no detectable error.

'Fixed' in the sandbox:

pass: |year= without |date= is promoted to date. 23 Apr 2009. 
pass: |year= has year and |date= has date. 2009-04-23. 
pass: |year= has year with CITEREF disambiguator and |date= has date. 2009-04-23. 
fail: |year= has whole date and |date= has a value. 2009.  Check date values in: |year= (help)

Trappist the monk (talk) 10:45, 2 July 2016 (UTC)

Don't feel like hunting for the code, so I ask you instead:
If |date= is not set, we promote the first set of |year= or |publication-date= to |date=.
Does the code actually transfer the value of |year= or |publication-date= to |date=? Or does the value of these parameters become the cited date instead? (talk) 14:38, 2 July 2016 (UTC)
Module:Citation/CS1/sandbox line 2426.
Trappist the monk (talk) 14:52, 2 July 2016 (UTC)
Thanks. (talk) 15:22, 2 July 2016 (UTC)

Separator added before short volume names/numbers[edit]

In troubleshooting the publisher parentheses coding above, I noticed that short volume numbers, which are bolded (per our documentation – if you want to start a conversation about that, please create a separate section), did not have a separator (typically a period aka full stop) preceding them, leading to inconsistent formatting. I have attempted to force the template to display a separator before all volume numbers by modifying the sandbox code. Please let me know if I have made any errors or introduced any problems, or if you object to this change. It is easy to undo. – Jonesey95 (talk) 14:46, 12 June 2016 (UTC)

Cite journal compare
{{ cite journal | editor-last=Garbett | oclc=8007941 | journal=Journal of the Royal United Service Institution | year=1898 | publisher=J. J. Keliher | title=Naval Notes – Italy | volume=XLII | editor-first=H. | pages=199–204 | location=London }}
Live Garbett, H., ed. (1898). "Naval Notes – Italy". Journal of the Royal United Service Institution (London: J. J. Keliher) XLII: 199–204. OCLC 8007941. 
Sandbox Garbett, H., ed. (1898). "Naval Notes – Italy". Journal of the Royal United Service Institution. London: J. J. Keliher. XLII: 199–204. OCLC 8007941. 
Cite journal compare
{{ cite journal | editor-last=Garbett | oclc=8007941 | journal=Journal of the Royal United Service Institution | year=1899 | publisher=J. J. Keliher | title=Naval Notes – Italy | volume=XLIII | editor-first=H. | pages=792–796 | location=London }}
Live Garbett, H., ed. (1899). "Naval Notes – Italy". Journal of the Royal United Service Institution (London: J. J. Keliher). XLIII: 792–796. OCLC 8007941. 
Sandbox Garbett, H., ed. (1899). "Naval Notes – Italy". Journal of the Royal United Service Institution. London: J. J. Keliher. XLIII: 792–796. OCLC 8007941. 
I tweaked this so that the bold and non-bold versions use similar code forms.
Trappist the monk (talk) 17:21, 12 June 2016 (UTC)
Thanks. I figured there was a more elegant way to do it, but I don't know enough Lua code. – Jonesey95 (talk) 18:25, 12 June 2016 (UTC)
Why are XLII and XLIII bolded differently? That makes no sense. Headbomb {talk / contribs / physics / books} 21:00, 5 July 2016 (UTC)
From the template documentation: "volumes of four characters or less display in bold." I don't remember the rationale, if there is one. You might search the archives of this page. It doesn't make sense to me either. – Jonesey95 (talk) 21:27, 5 July 2016 (UTC)

archive url checks and preview mode[edit]

There is a discussion at WP:VPT that may change how Module:Citation/CS1 handles malformed Internet Archive |archive-url= values. Currently, when these values are malformed, the module renders the citation without a link to the archive but with an error message. When the page is rendered in preview mode, the module modifies the malformed archive url so that it links to what should be the most relevant calendar directory. To know if the page is being rendered in preview mode, the module looks at the value of {{REVISIONID}} (has no value in preview mode). Apparently this is a bad thing.

In the current live module, {{REVISIONID}} is queried for every cs1|2 template regardless of need. As an experiment, I've tweaked the sandbox so that the magic word is only queried when |archive-url= has a malformed IA url:

Incomplete without '*':

{{cite web/new |title=harri deutsch electronic science (hades) |url= |dead-url=yes |archive-url= |archive-date=2013-10-30}}
"harri deutsch electronic science (hades)".  |archive-url= is malformed: timestamp (help)

Save command:

{{cite web/new |title=example |url= |archive-url= |archive-date=2013-10-30}}
"example".  |archive-url= is malformed: save command (help)

It remains to be seen whether this change shall be kept

Trappist the monk (talk) 15:05, 17 June 2016 (UTC)

Making that change should be very helpful. You might spot the result in (save timing). Aaron Schulz 11:40, 18 June 2016 (UTC)
How often does the Sandbox get merged into the main module? It would be nice to make this change sooner rather than later. I still see waves of page saves effected by the vary-revision flag in the site logs. I eliminate one of the two excess parses needed on page save, but there is only so much I can do server side. Aaron Schulz 22:55, 21 June 2016 (UTC)
Jargon is ok as long as we all understand it. I have no idea what waves of page saves effected by the vary-revision flag in the site logs means.
Typically bimonthly; we did it in February, April, and first week of June this year.
At the WP:VPT conversation I asked you this:
What happens if a module that needs to know about preview mode got the value of REVISIONID passed to it in the {{#invoke:Module|function|{{REVISIONID}}}}? Is this still 'bad'?
You ignored those questions. Can I have answers?
What is the status of the patch proposing a magic word to expose preview mode? What does 'exposing preview mode' actually mean? What is the magic word? What does it return? When can I expect to have it available to me?
Trappist the monk (talk) 23:23, 21 June 2016 (UTC)
To make saves snappy, whenever we think the user is about to submit an edit (because s/he has started typing an edit summary, for example), we send it to our servers so we can start processing it. We try to do all the work except actually save the edit to the database. If the user does not end up saving the edit or if the user goes back and makes additional changes, we just throw away whatever we computed. But if the user saves the edit, then often times a lot of the work is already done and all we have to do is commit it to the database. Whenever the REVISIONID magic word is used, this whole mechanism is basically subverted, because we can't reliable know in advance what the revision ID is going to be before we save it to the database. CS1 is widely used and it *always* uses REVISIONID, which makes saving any page that uses it slower than it needs to be. You could improve the situation a lot if you only check REVISIONID if you know you're going to need it (because you definitely detected some issue you want to flag to the user). You could do this by applying the diff I put up here. It does not change the functionality of this module at all. --Ori Livneh (talk) 00:24, 22 June 2016 (UTC) (WMF, but editor too :))
Thank you. Didn't know about the predicting part.
Yep, I know that cs1 always uses REVISIONID; that's what this conversation is all about, ne?. At the top of this discussion I wrote:
I've tweaked the sandbox so that the magic word is only queried when |archive-url= has a malformed IA url
which change you can see in Module:Citation/CS1/sandbox at archive_url_check(). Because this is the only place where we want to know if we're in preview, the change I made works as you can see if you preview this discussion.
I would much prefer to have a Scributo function or environmental variable to query to learn the rendering mode. But, since the only tool available is a hammer, it is what must be used to insert that screw.
Trappist the monk (talk) 01:08, 22 June 2016 (UTC)
Looks good to me. Thanks a lot. (Though note you kept "local Preview_mode = false;", even though the variable is no longer in use.) --Ori Livneh (talk) 01:56, 22 June 2016 (UTC)
Any use of REVISIONID has the same problem, whether it is an argument to the #invoke call or not. Aaron Schulz 02:31, 22 June 2016 (UTC)
Thank you. And the answers to the other questions that I asked you?
Trappist the monk (talk) 02:51, 22 June 2016 (UTC)
The PREVIEWMODE magic word patch is unlikely to be deployed, since most discussion on it gravitated towards instead exposing a Lua method to add page save warnings. This was merged, but the warnings don't have anything to indicated the location of the page, which another developer was interested in working on. I don't know when anything will come of that, though it probably won't be soon. Aaron Schulz 08:54, 22 June 2016 (UTC)
If transaction prefetching is truly affected negatively by this then as you remarked at VPT, the use of REVISIONID should be disabled serverside. On the other hand, prefetching always carries risks, and REVISIONID seems too useful a marker not to be used by module writers when there is need. I am ignorant of how transcation commit/rollback happens in MW database(s). But I wonder if REVISIONID could be pre-stuffed with a dummy value, to be discarded when the transaction is actually commited. (talk) 14:49, 22 June 2016 (UTC)

@Trappist the monk:, any chance you could merge this change to the canonical module? We're eager to see the impact on page save perf. --Ori Livneh (talk) 23:24, 27 June 2016 (UTC)

In general, unless something is broken to the extent that there are large red system error messages or the rendering is meaningless, I avoid making changes to the live module. I understand that you are eager, but I don't see this issue rising above the must-fix-now threshold. Am I wrong?
Trappist the monk (talk) 10:19, 28 June 2016 (UTC)
This one on its own perhaps not, but certainly bundling that with the bibcode validation and other updates since the last one... bimonthly is a long time to wait between updates. Monthly seems much better. And if a WMF dev says they're waiting eagerly for that update, I don't really see a benefit to waiting for an arbitrary deadline before deploying. Headbomb {talk / contribs / physics / books} 13:56, 28 June 2016 (UTC)
There are those who would say that monthly is too often. Neither of these updates, even grouped together, it seems to me, are must-fix-now. I am eager for a fix to the Math ML metadata problem and am eager for a preview-mode keyword or a Lua function to take the place of the ugly mechanism that must be used to support the preview-mode functionality both as it is now or with the update. We all want something, ?
Trappist the monk (talk) 16:54, 28 June 2016 (UTC)
I know of no one who would argue that one month is too often. Personally, I'd even go with weekly. If the code is tested, and it works, then the sooner it's rolled out the better, and unless sys admins tell us they'd appreciate us slowing down the deploy rate, WP:PERF applies. Headbomb {talk / contribs / physics / books} 20:43, 28 June 2016 (UTC)
And it seems particularly silly to delay a feature that WMF sys admins say would actually help them with said performance, because... what exactly is the argument for only rolling out updates every two months anyway? Headbomb {talk / contribs / physics / books} 20:47, 28 June 2016 (UTC)
Let's not get all hot and bothered over this. The issue is not really pertinent here. Performance is something that should (and can) be resolved at the MW development/admin level, not in user space. As for updating, there is the issue of code stability. No matter how well code is tested, bugs/incompatibilities can and will creep in, as most updates introduce added levels of complexity. Especially so when programmers succumb to featuritis. Not to mention the increased opportunities of code misuse with every addtion. Security/stability updates should be applied as soon as possible. Optimizations can wait a while. And enhancements can certainly be under a two-month cycle. (talk) 23:46, 28 June 2016 (UTC)
Two months seems about right because by then, enough minor changes have accumulated to make it worth while. When the module suite was in development, there were complaints about too many changes too often – something to do with the job queue if I remember correctly. Every time we change Module:Citation/CS1, 2.9+million articles get dumped onto the job queue. It can take more than a month to sort through all of those articles.
Trappist the monk (talk) 12:16, 29 June 2016 (UTC)
We have a workflow that involves making small changes and looking carefully at the numbers so we can understand impact. Two months is just way too long in my opinion, especially considering you can apply this particular change in isolation very easily with no real risk. So I am a bit disappointed. That said, it's ultimately for you and your peers to make the call, based on whatever works best for you. --Ori Livneh (talk) 04:52, 30 June 2016 (UTC)

Parameter order[edit]

I didn't see this in the archives, so please point me in the right direction if this has been answered. Is there a logic behind the default parameter order at {{cite web}}, {{cite news}}, etc.? Is it local consensus? I try to put the parameters in the order in which they display, personally, and I know that their order is not standardized on the whole (and I am not suggesting that it should), but in terms of the default shown, I was wondering about the logic. czar 04:31, 22 June 2016 (UTC)

I wasn't aware that there was a "default" order. The blank templates that you can copypaste include a non-exhaustive selection of available parameters; mostly, these put authors info first, identifiers (like ISBN OCLC etc.) last. everything else in between those. But since the citation templates use named parameters exclusively (there are no positional parameters), the order in which you give them is immaterial - no order is more "correct" than another. The only requirement is that you don't use the same named parameter more than once - that includes its aliases, so {{cite book |last=Smith |first=Fred |author=Joe Public |title=Our book of facts }} would be an error. --Redrose64 (talk) 08:09, 22 June 2016 (UTC)
Since the order makes no difference to the software, I think it would be best (if there is to be a default order, i.e. the one you get by copying and pasting a blank template) if the ordering is useful to human editors reading the code. So I think the parameters that are more readable for identifying the citation (its title or authors) would be better placed earlier, and other more machine-only data (like urls) later. The custom software that I use for many citations puts authors first, then alphabetical for everything else, rather than trying to find a logical ordering for everything. —David Eppstein (talk) 08:24, 22 June 2016 (UTC)
My only 2 cents on this is that "first last" makes more sense than "last first", since there are more sources that show author as "first last". Thus you would code it the way you see it, more often than not, rather than the way readers will see it. ―Mandruss  10:28, 22 June 2016 (UTC)
In a bibliographic listing, alpha-ordered by lead author's/editor's surname, write the template {{cite ... |last=... . Doing that can make life easier for follow-on editors.
Trappist the monk (talk) 11:32, 22 June 2016 (UTC)
I have found both first/last and last/first name ordering have their advantages; I don't see that either warrants preference in all cases. To the extent that a particular citation model is recommended it should be clear that either name ordering is fine, provided it is consistent within the citation. I don't think we should require such consistency within an article. ~ J. Johnson (JJ) (talk) 20:36, 24 June 2016 (UTC)
Being a bit gnomeish, if you are sorting out a list that is out of order (not uncommon), then it is much easier if |last= comes first in the list. The only exception to this is where there is no author (corporate authorship or lookup to specialised databases such as listed buildings) when the publisher or listing organisation needs to be first. Martin of Sheffield (talk) 21:37, 24 June 2016 (UTC)
It really depends on the context. Assuming vertical format (one author per line) and some uniformity of spacing I found that something like the following (making allowances for proportional fonts)
  |first1= Tom A.     |last1= Jones
  |first2= Robert C. |last2= Brown
is very readable. Though many editors would object to the extra spacing. Of course, when you get to
  |first3= John Jacobjingleheimer |last3= Smith
the pattern is bit unwieldy. But for the many cases where only the initials (and last name) is used, this works well. And when the authors' names copied in are in first/last order it is a bit of work to invert them. Anyway, like I said before, both arrangements have their advantages. (And disadvantages.) I think this is less important than (e.g.) having everything closed-up (no spaces) except for the space before the vertical bar and the space after the equals sign. ~ J. Johnson (JJ) (talk) 22:08, 26 June 2016 (UTC)
Well we are certainly going to disagree here! When working on a bibliography I enter it at one parameter per line, two spaces to the left of the pipe one between pipe and parameter name and spaces surrounding the "=" sign. The first line will be an asterisk and the template name, the last just the closing braces. Obviously in-line citations aren't spaced out in the same way, but for a list it makes it so much more readable than everything condensed into a single wrapping string. Martin of Sheffield (talk) 22:21, 26 June 2016 (UTC)
"So much more readable" in your opinion, but not in mine. That's the problem with citations: editors have strong opinions and there's absolutely no consensus. WP:CITEVAR is interpreted to protect even minor variations. Result: endless back-and-forth changing of formatting. Sigh... Peter coxhead (talk) 09:40, 27 June 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Recently, one bot user and admin at the same time on wanted even to block me as I insisted on "my" parameter order that I consider logical (it is, for example, {{cite book |url= |title= |language= |last1= |first1= |last2= |first2= |publisher= |isbn= |lccn= |volume= |issue= |pages= |date= |accessdate= |quote= |archiveurl= |archivedate= |deadurl=}}). Stated reason was something like "bot unifies citation templates so |pages= has to be at the end [nonsense], near }}" etc. This could work if the bot user placed it at the end and then move it back on the initial position; but the second does not happen...

Can editor frame or whatever (e.g. after saving the wiki code) automatically reorder all parameters to some default order, and to make them like |parameter1=content |parameter2=content style; equally spaced, with parameter name and content right next to the = sign [no spaces] so it is clear on all Wikipedias that one format is used and such conflicts generally don't happen?

I wonder also something else: Is parameter order important for Lua time/memory usage? I think of some scanning-and-checking-like process [if it even exists, I do not understand the exact process of forming and displaying a single citation/reference] that goes slower/faster when taking into account order of some functions in Lua modules and order of parameters in some citation template.--Obsuser (talk) 18:12, 23 June 2016 (UTC)

The policies, guidelines and other conventions of the Serbian Wikipedia do not apply here and vice versa. If you are in breach of their rules for something that you did on that wikpedia, there's nothing that we can (or should) do about it here. --Redrose64 (talk) 18:37, 23 June 2016 (UTC)
I don't think that parameter order markedly improves cs1|2 performance.
Trappist the monk (talk) 19:03, 23 June 2016 (UTC)

Partial paywall and subscription=y[edit]

The Los Angeles Times has some kind of weird paywall thing going on. For example, this article displays for me with no problem, but this one tells me I've reached my monthly limit and need to cough up some cash if I want to read it.

Well never mind that weirdness, that's secondary. Let's say they treated all articles the same, giving you x free views per month. There is no way to know whether a particular reader has reached their monthly limit, so should cites for that site use |subscription=y? It's a "subscription might be required, depending" situation. ―Mandruss  09:43, 22 June 2016 (UTC)

Pretty sure this topic has come up before but never resolved. The template needs some sort of way to know that there is limited free-access so perhaps |subscription=limited which in turn might tell the module to emit a message like (Subscription may be required) or (Limited free access).
Trappist the monk (talk) 11:46, 22 June 2016 (UTC)
Ok, I'd support that parameter value, and "limited free access" would be the more descriptive of the two. For the time being I'll just omit |subscription= (which most editors are doing even for zero-free-access sites). ―Mandruss  12:46, 22 June 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Addressing issues raised at Adding open access links to references caused me to wonder about applying a similar mechanism to |subscription= and |registration=. For example, for this case: |subscription=yes, the module might render a citation

{{cite news |title=Article title |url=// |newspaper=World-wide Times Gazette |subscription=yes}}
"Article title"subscription required. World-wide Times Gazette.

Unlike the open access icons, this one is linked to explanatory text.

For |registration=yes, use the same lock icon but in a different color? For the 'limited free access' case contemplated in this discussion, perhaps a gray colored version of the open access lock?

Trappist the monk (talk) 15:10, 22 June 2016 (UTC)

I like conciseness. I suppose it depends on the question: Just how important is it for the reader to understand the situation before they click through? It could take decades before a majority of readers who look at sources (1) have noticed those little locks and (2) have learned what they mean. We have little PDF icons, but the PDF logo is fairly widely recognized already (I think). ―Mandruss  16:27, 22 June 2016 (UTC)

I have been thinking about this topic because of the discussion at Help talk:Citation Style 1#adding free-to-read icons. If cs1|2 is to replace text with icons, then those icons, it seems to me, should all have the same base shape. Because of the small size, detail visible at larger sizes will be lost. Along with that, we can't use color as the sole indicator of meaning because, those who are color blind won't notice the color difference except that perhaps the icon is a slightly different shade of gray. The meaning then, must be distinguishable by its shape. Here are four icons that I think could be used:

  • free to read – free to read – derived from the Open Access logo
  • registration required – registration required – same shape as free-to-read except that the shackle is closed and the color is black
  • subscription required – subscription required – same shape as registration required except that the body is filled
  • limited free access – limited free access – same shape as registration required except that half the body is filled

Trappist the monk (talk) 09:20, 3 July 2016 (UTC)

The icons are a cosmetic change, but the link notes are (or can be) precise and informative. Other than that, I suppose they look good, even if somewhat cryptic. Tooltips help to make their meaning more explicit, but in general, I have doubts over tooltip usability. (talk) 17:02, 3 July 2016 (UTC)
I've tweaked the above examples to include alt text which provides tool tips and in the case of the subscription required lock, added a link to Wikipedia:Verifiability#Access to sources. I imagine that we should make all of these locks, if we decide to use them in cs1|2 templates, link to appropriate subsections of Help:Citation Style 1 so that readers can learn what they mean.
Trappist the monk (talk) 10:38, 4 July 2016 (UTC)
I do have trouble mentally distinguishing between the registration and subscription icons. Both are in effect locks: one key is registering, and the other key is purchasing. I can't tell from looking which image is supposed to describe the more burdensome (costly) scenario. The registration lock still looks completely closed-off, moreso than it really is, while the subscription icon looks entirely foreboding with its menacing and blank white face. I've never seen a lock with no keyhole before, so this introduces some confusion regarding what to associate it with. It may be worth rethinking those two icons (although the other two are very cool). One thought, for registration, you could consider using a lock with the @ symbol somewhere it's keyhole would be, signifying an email address is needed. Just thinking. Graphic design is not my speciality... Jake Ocaasi (WMF) (talk) 20:08, 6 July 2016 (UTC)
There is only so much "meaning" you can put into something that small, so I think we would have to rely on the tooltips and links for first-time usage. Can you tell what this means without clicking on it? ---> No Smoking sign.gif <--- Similarly, Firefox shows me a little "i" icon next to my address bar. I had no clue what it meant until I moused over and read the tooltip: "Verified by: GlobalSign nv-sa". And the star to the right of the address bar? How could I have guessed that a star means "Bookmark this page"? I think we all use tooltips to learn what things are without even thinking about it. Don't know what something is? Try a mouseover. It's automatic for most of us. ―Mandruss  20:30, 6 July 2016 (UTC)
@Trappist the monk: But I think the icons would be more recognizable as padlocks if in the form Padlock-dark-green.svg or Open Padlock.png. This is consistent with the icons produced by {{pp}} to show page protection. Not necessarily the same images, but mimicking that shape. I think a darker color would make it more apparent that the second lock is open, but I couldn't find such an image. That Open Access logo is stylized and I don't think intended to closely resemble a padlock. Likewise, the Apple logo Apple logo black.svg is more about distinctive branding than apple recognition. It's meant to convey Apple, not apple. ―Mandruss  03:32, 7 July 2016 (UTC)
A propos of nothing, what you mentioned above re:meaning and cryptic icons (like your Firefox examples) is indicative of bad software design imo, which is now accepted as the norm. General-use software (i.e. software not targeting experts) should not force people to divine a whole new symbol-based nomenclature as an additional requirement (to learning how to actually use the software itself). (talk) 14:30, 7 July 2016 (UTC)
We live in a symbol-based world. How about you prototype us a browser interface that provides the needed functionality without using symbols and tooltips. Microsoft will pay big bucks for it. ―Mandruss  15:17, 7 July 2016 (UTC)

"CS1 maint: Multiple names: authors list" error[edit]

There is a discussion on {{ill}} concerning an interaction between |editor=, |editors= and {{ill}}. It can be accessed here. Simply put, use of {{ill}} in the |editor= field is generating errors unless the plural form is used - which is wrong for a single editor. Martin of Sheffield (talk) 16:15, 22 June 2016 (UTC)

As Tom.Reding remarked in that talk page (Template talk:Interlanguage link#"CS1 maint: Multiple names: authors list" error), |editor= and similar should not be used to insert links of any kind. His suggestion of using |editor-link= seems the way to go. I also believe that the resulting categorization issues could be resolved. (talk) 16:45, 22 June 2016 (UTC)
{{ill}} causes |author={{ill|fr|Jacques Stiennon}} to land in Category:CS1 maint: Multiple names: authors list (and the same for editor parameters) because when {{ill|fr|Jacques Stiennon}} is rendered and the result handed to Module:Citation/CS1 it looks like this:
[[Jacques Stiennon]]<span class="noprint" style="font-size:85%; font-style: normal; ">&nbsp;([[:fr:Jacques Stiennon|fr]][[Category:Interlanguage link template link number|1]])</span>
Jacques Stiennon (fr)
Only a small bit of that is the author name. The module sees the three semicolons which is one of the signs that there might be multiple author names in a singular author parameter. Use of {{ill}} in |author= will corrupt the citation's metadata and it was for that reason that I added the not-COinS-safe template to the {{ill}} documentation.
Trappist the monk (talk) 18:24, 22 June 2016 (UTC)
Would foreign-wiki author/editor-links be trackable in some way (other than a database/insource search for :<ISO language code>:), similar (or identical) to {{ill}}'s tracking Category:Interlanguage link template link number?   ~ Tom.Reding (talkdgaf)  16:23, 23 June 2016 (UTC)
To whom is that question addressed? If to me, then my answer is: it could. But I would return a question to you: why should it? Very brief searches for categories identifying pages with interwiki or inter-language links (the normal kind, not those associated with {{ill}}) turned up nothing. That doesn't mean that there aren't such categories, just that in my quick look, I didn't find any. If there are, great, perhaps we could use them. If not, then what is the purpose served by creating a new category for these links?
Trappist the monk (talk) 19:00, 23 June 2016 (UTC)
I would guess that, as foreign wikilinks became available in/translated to the native wiki, someone would want to change the |author-link= or |editor-link= to the native wikilink. That would be one purpose of a tracking category. I haven't really been involved with inter-wiki things, so maybe Martin of Sheffield or others can enumerate other use cases. I'm just trying to retain the functionality of what Martin was trying to do; whether or not that's preferable by the community is a question idk the answer to.   ~ Tom.Reding (talkdgaf)  20:04, 23 June 2016 (UTC)
To be accurate I only got drawn into this when I picked up on Dcirovic changed "ed" to "eds" on a couple of pages I'd worked on. Dcirovic told me that reverting to ed caused an error, which is how I became involved. I'm not actually sure who put in the {{ill}} templates since I assume Dcirovic was just finding a workaround for that error. Tom's suggestion seems fine to me, but you really need to track down whoever inserted the template in the first place. Martin of Sheffield (talk) 21:29, 23 June 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Found them (for Timeline of Liège & Timeline of Bruges)! M2545 (and anyone else here), since |author={{ill|de|Gerhard Dohrn-van Rossum}} should instead be written |author-link=:de:Gerhard Dohrn-van Rossum (see fix), the tracking performed by {{ill}} via Category:Interlanguage link template link number is lost. Do you (or anyone else here) wish it be retained in some way, say, via a tracking category?

For reference, I find 62 pages with |author={{ill, and 23 pages with |editor={{ill, which boil down to 80 uniques (that I will soon correct to the appropriate format).   ~ Tom.Reding (talkdgaf)  16:33, 14 July 2016 (UTC)

Yes check.svg Done. ~332 pages with |(author|editor)-link=:[a-z][a-z]: now.   ~ Tom.Reding (talkdgaf)  03:56, 15 July 2016 (UTC)
I don't think \s works as you intend. Kanguole 23:06, 15 July 2016 (UTC)
How so? I intend to capture potential whitespace surrounding = via \s*=\s*, which the query does.   ~ Tom.Reding (talkdgaf)  23:49, 15 July 2016 (UTC)
In \s*, the backslash escapes the 's'; the splat says match 0 or more of those. I suspect that if you look through the search results, you won' find any spaces where the \s* (in 'real' regex) would find them. I would write that search:
insource:/(author|editor)[1-4]?\-?link[1-4]? *= *:[a-z][a-z]:/
which returns a few more hits.
I don't think that cirrus search supports any of the character classes so you have to make your own with square brackets – [0-9] instead of \d, etc.
Trappist the monk (talk) 00:22, 16 July 2016 (UTC)
There is a hit (1 hit) for " = " in my query (American and British English spelling differences), which is findable through gedit's regex, buuuut it only showed up because a no-space counterpart also exists on the same page. And I find 56 " = " with your much better query, with 398 overall. I guess I'll learn the idiosyncrasies of cirrus search eventually... Until then, thanks Kanguole, and thanks again Trappist.   ~ Tom.Reding (talkdgaf)  00:57, 16 July 2016 (UTC)

kerning for “” and ‘’[edit]

It won't show in the comparison below but note the quote marks used in |title=UrFU scientist was awarded the title “Professor of the Russian Academy of Sciences”. When the template has typewriter single and double quote marks, the module adds kerning to separate them from quote marks that it adds as part of title formatting. It doesn't understand “” and ‘’. But the sandbox now does:

Cite web compare
{{ cite web | url= | title=UrFU scientist was awarded the title “Professor of the Russian Academy of Sciences” }}
Live "UrFU scientist was awarded the title “Professor of the Russian Academy of Sciences”". 
Sandbox "UrFU scientist was awarded the title "Professor of the Russian Academy of Sciences"". 

Trappist the monk (talk) 16:45, 25 June 2016 (UTC)

These shouldn't be used, see MOS:QUOTEMARKS. --Redrose64 (talk) 22:05, 25 June 2016 (UTC)
Aye, but that prohibition has never stopped editors from using them in the past. How would you have us deal with these cases?
Trappist the monk (talk) 22:23, 25 June 2016 (UTC)
@Trappist the monk: do my eyes deceive me, or does the sandboxed version uncurl the typographer's quotes in the final output? If so, this means it renders the final result to comply with with the MOS section Redrose64 mentions. In other words, win-win all around. Imzadi 1979  00:23, 26 June 2016 (UTC)
For quoted parameters, |title= in {{cite web}}, |chapter= in {{cite book}}, the module calls kern_quotes(). The first thing that the function does is replace any and all occurrences of “” and ‘’ with " and '. It then does it's usual kerning with those characters if necessary. So, even if kerning is not necessary, there are no typographer's quotes in the output:
{{cite book/new |chapter=Don’t do this |title=Things we shouldn't do}}
"Don't do this". Things we shouldn’t do. 
As you can see, the 'fix' only applies to quoted titles.
Trappist the monk (talk) 01:35, 26 June 2016 (UTC)
There are other, similar characters that are used as apostrophes and quotation marks. I come across them occasionally when editing citations. They look to me like copy-paste text from web sites. We should probably include them in our processing of these marks. I'll paste them here if I can find some. – Jonesey95 (talk) 16:31, 28 June 2016 (UTC)
Like those at quotation mark?
Trappist the monk (talk) 17:14, 28 June 2016 (UTC)
Yes, I have seen and fixed almost all of the characters listed in the Unicode table in that article. They mostly appear to be copy-pasted or inserted by a citation-filling tool. – Jonesey95 (talk) 21:38, 28 June 2016 (UTC)

Df parameter[edit]

I've tested the df parameter in the cite web template. The use of that parameter is described in the documentation for that template. However, that parameter isn't included in the TemplateData, which means that using the parameter in VE requires ignoring an "unknown field" comment by VE. Once added, it does work as documented, however. Would someone add df parameters to TemplateData descriptions for all citation templates that allow this, so the "unknown field" comment by VE goes away? -- John Broughton (♫♫) 23:23, 25 June 2016 (UTC)

On a related point, I just used |df= to test something else on the Beta Cluster, and there's a display bug. It produced ( 7 July 2008), with an extraneous leading space. Please feel free to {{ping}} me if you need any further information from me. Whatamidoing (WMF) (talk) 16:22, 30 June 2016 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── Fixed, I think.

Cite news compare
{{ cite news | last=Ablan | access-date= | date=July 8, 2007 | first=Jennifer | df=dmy | publisher=Reuters | title=Wikipedia page the latest status symbol | work= | url= | via= | accessdate=November 22, 2008 }}
Live Ablan, Jennifer ( 8 July 2007). "Wikipedia page the latest status symbol". Reuters. Retrieved November 22, 2008. 
Sandbox Ablan, Jennifer (8 July 2007). "Wikipedia page the latest status symbol". Reuters. Retrieved November 22, 2008. 

The conversion uses with a format string '%e %B %Y'. The %e format returns the day-of-month-number with a leading space if the day is 1–9. There isn't a format string to return just the number regardless of the number of digits so I tweaked the code to look for and remove any leading space characters.

Trappist the monk (talk) 17:19, 30 June 2016 (UTC)

tracking use of |authors= and |editors=[edit]

I have tweaked the sandbox so that templates that use either of |authors= or |editors= (the plural versions only). Use of these parameters is discouraged because they don't contribute to the citation's metadata (actually no 'editor' parameter contributes but all of the 'author' parameters do except |authors=).

For the time being, the aliases of |authors= (|people=, |host=, |credits=) are excluded from categorization because those parameters tend to bring with them additional baggage (|people=Jo Bloe (Director), Somebody Else (Producer) ...) which we should think about as a separate topic.

{{cite book/new |title=Title |authors=AB Black, CD Brown, EF White}}

AB Black, CD Brown, EF White. Title. 

{{cite book/new |title=Title |people=AB Black, CD Brown, EF White}}

AB Black, CD Brown, EF White. Title. 

{{cite book/new |title=Title |editors=AB Black, CD Brown, EF White}}

AB Black, CD Brown, EF White (eds.). Title. 

Trappist the monk (talk) 20:03, 27 June 2016 (UTC)

Hmm. If I read the above correctly, there is no metadata difference between using |editors= and |editor=. Is that right? If so, when people start to modify articles that are showing this message, and then other editors complain, what is the rationale to support the first modification (from editors= to editorn=)? I'm really just asking; I have no dog in this fight, but I suspect that there will be a fight, because people on WP love to fight about minutiae like this. – Jonesey95 (talk) 16:27, 28 June 2016 (UTC)
I was under the impression that the |editor= family of parameters (and, more recently, |translator=) populated the metadata. I support including them in the metadata.   ~ Tom.Reding (talkdgaf)  17:00, 28 June 2016 (UTC)

(edit conflict)

You read it correctly. I chose to include |editors= for the sake of consistency. If we prefer the use of multiple |authorn= and |lastn= / |firstn= parameters over the use of a single |authors= parameter then, for the sake of consistent documentation and usage, we should have the same preference for |editorn= and |editor-lastn= / |editor-firstn= over |editors=, shouldn't we? It was for this reason that we did not create |translators= and |contributors=.
There are no keywords for editors, translators, or contributors (authors of intro, forewords, etc) in the current incarnation of the COinS standard. If ever such support is added, it is best that we have already minimized the number of metadata keywords that will be corrupt or unavailable.
Trappist the monk (talk) 17:11, 28 June 2016 (UTC)

Archived from the original on...[edit]

This text or similar that points to the archived version (either on word "Archived" or "original", depending on the |deadurl= value) sometimes is not true because archive version must not have identical URL at the end as the original URL (i.e. word "original" in "... from the original..." is not always applicable).

Example is when website changes design and url format so page is still available in similar form but has different URL (and possibly some content is missing/extra). Then the most information is preserved if user changes parameter |url= so it is not broken anymore and adds |archiveurl=, |archivedate= and |deadurl=no with old archived URL (if he/she does not have time to / does not want to check source in the original URL whether it is still a valid Wikipedia reference or not, or does not want to archive that new URL etc.).

I think other form for this text can be figured out so implication that we are talking about "real original" does not exist but functionality is still preserved. However, I don't have any ideas for better formulation. Raw example (notice where are particular URLs):

  • {{cite web |url= |title=Take-Two has 'extensive pipeline' of unannounced titles in development |last=Makuch |first=Eddie |publisher=GameSpot |date=7 March 2013 |accessdate=7 April 2013}}
Makuch, Eddie (7 March 2013). "Take-Two has 'extensive pipeline' of unannounced titles in development". GameSpot. Retrieved 7 April 2013. 
  • {{cite web |url= |title=Take-Two has 'extensive pipeline' of unannounced titles in development |last=Makuch |first=Eddie |publisher=GameSpot |date=7 March 2013 |accessdate=7 April 2013 |archiveurl= |archivedate=11 May 2013 |deadurl=no}}
Makuch, Eddie (7 March 2013). "Take-Two has 'extensive pipeline' of unannounced titles in development". GameSpot. Archived from the original on 11 May 2013. Retrieved 7 April 2013. 

There might be other examples too when "original" does not fit but cannot remember now... --Obsuser (talk) 09:23, 28 June 2016 (UTC)

If I understand you correctly, this is a problem with the url metadata, not the source: the original and archive copy have different metadata (site, subpage, item identifier etc.) However, this does not affect the verifiability of the citation: the archive matches the original word for word. It also seems there is no material change in reliability, since this is the same type of source (and seemingly the same publisher). As far as Wikipedia policies/guidelines are concerned, the url metadata difference seems to be a non-issue. The citation contributor accessed the original at a documented date, and a true archived copy at another documented date. I think that this is sufficient for our purposes. (talk) 18:17, 28 June 2016 (UTC)

"|registration=yes" rendering is awful[edit]

I was just editing an article where one of the citations required (free) registration to read, so I looked at the {{cite web}} template and found there was a "|registration=yes" parameter, so I added that. However, it renders so poorly and confusingly for readers -- "(registration required (help))." with the help tooltip giving "Sources are not required to be available online. Online sources do not have to be freely available. The site may require registration." -- that I reverted my change and just added "(Registration required.)" at the end of the <ref> manually.

First off, the "r" in "registration" should be capitalized if there's a period at the end, and the period should go inside the parentheses, not outside. Secondly, "Sources are not required to be available online. Online sources do not have to be freely available." must be very confusing to the average reader. I don't think it's helpful to the average reader to obliquely define Wikipedia reference inclusion policy in the help for what the tag means. Finally, why the weasel words in "may be required"? The parameter says "registration=yes", and it renders as "registration required" -- the "may be" has no business being there.

Points 1 and 3 seem objective enough that I would go ahead and edit the template myself now, but I don't seem to have the rights to edit that particular template.

"|subscription=yes" rendering may have parallel problems; I didn't check. --Dan Harkless (talk) 09:15, 30 June 2016 (UTC)

@Dan Harkless: Everyone has the right permissions to edit the sandbox. Nothing at cs1|2 changes unless it first passes through the sandbox. The text rendered for |registration= and |subscription= is in Module:Citation/CS1/Configuration/sandbox.
You may also be interested in this discussion: Help talk:Citation Style 1#Partial paywall and subscription.3Dy.
Trappist the monk (talk) 09:54, 30 June 2016 (UTC)

Parameter "permalink"?[edit]


Maybe I'm missing something but I found that the cite web template (from here and citar web from portuguese wikipedia) doesn't offer a "permalink" parameter?! Most of time a website URL is different from the content URL (the "permalink"), how we inform this:

The portuguese version of "cite web" template is currently broken on several pages that has an URL on "publisher" and other parameters (eg [1], [2] and thousand others articles). How we can fix those citation without removing the very website URL or the permalink? It seems lame that cite web/citar web doesn't provide a permalink parameter. Thanks for any clarification. Dianakc (talk) 17:23, 30 June 2016 (UTC)

From's point of view, your template is working correctly. Here, we have taken the position that a working |url= is all that is required and that url links in |work= and |publisher= (and all of their aliases) are unnecessary and perhaps harmful (for a list of aliases, see 'Periodical' and 'PublisherName' here). The values assigned to |work= and |publisher= may be used in the citation's metadata where the metadata format expects titles or title-like text. For example, the publisher metadata from this {{citar web}} at pt:Begonia annulata:
{{Citar web | url=|título=''{{subst:PAGENAME}}''|acessodata=17/8/2014|autor=|data= 2010|formato= |publicado= [ The Plant List]|páginas=|língua=inglês|citação=}}
It should be:
Here, I don't think we have the same concept of 'permalink' that you apparently have. For us, I think that 'permalink' is a permanent link to a page. I understand your concept of 'permalink' to be a link to a website's home page.
As you can see from the example pages that you provided, |título=''{{subst:PAGENAME}}'' isn't doing what it is that you want it to do. This is not a fault of the template but is a long-standing problem with MediaWiki. {{subst:}} does not work in <ref>...</ref> tags.
Trappist the monk (talk) 19:29, 30 June 2016 (UTC)
I left out a bit. What to do about the 8,000+ pages is a decision that only can make. We cannot make it for you. Were it up to me, I would fix each citation. That is a task that can very likely be accomplished with a bot task or an editor who uses pt:WP:AWB.
Trappist the monk (talk) 19:44, 30 June 2016 (UTC)
Thanks for reply, just to clarify that I'm using the permalink concept that is "a URL that points to a specific web page", we do not have a different concept for that (on or off-wiki). I understand that the code is ok but not really sure on how this template can be useful, the rendering is not user friendly since it can't differ the website URL from the content permalink. I will ask someone to fix the current pages using the template and will avoid using the template. Thanks again. Dianakc (talk) 20:54, 30 June 2016 (UTC)
@Dianakc: I guess I don't understand what you wrote. |url= holds a URL that points to a specific web page. Nor do I understand how you are not really sure on how this template can be useful, the rendering is not user friendly since it can't differ the website URL from the content permalink. Someone must have found it useful because at it is used on 2.2+million pages and there is this at the top of the {{citar web}} documentation page:
Esta predefinição é usada em mais de 308 438 página
So perhaps I'm not understanding your question?
Trappist the monk (talk) 21:44, 30 June 2016 (UTC)

What is generated COinS for |publisher=[[The New York Times]]? I've seen editors often link publisher, newspapers etc. so [[ and ]] might be problem too if modules don't do delinking.

Btw, (maybe wrong place to ask for {{para}} but not important too much for starting discussion on template's talk page) I've just noticed that {{para|publisher|[[The New York Times]]}} gives |publisher=The New York Times, why not |publisher=[[The New York Times]] i.e. why not to nowiki parameter content?--Obsuser (talk) 02:46, 1 July 2016 (UTC)

For each of the three cases
|publisher=The New York Times
|publisher=[[The New York Times]]
|publisher=<nowiki>[[The New York Times]]</nowiki>
the emitted COinS is exactly the same - But the third case pollutes the displayed reference, by making the square brackets visible. However, your examples exhibit a common error with news sources - The New York Times is not the publisher, it is the publication (the work in which the item was published), so you should use |newspaper=The New York Times and if you want to be pedantically complete, add |publisher=Arthur Ochs Sulzberger Jr. as well (but I don't see the point in that unless the news item was libellous, in which case it is Sulzberger who would be served with the legal papers). --Redrose64 (talk) 08:39, 1 July 2016 (UTC)
Third case is irrelevant (I nowikied so that wikilink inside {{para}} is not shown but square brackets). Content of the parameter is also unimportant (however, thanks for explaination for publisher and newspaper etc.).
My question was only about square brackets i.e. whether they appear or not in (pollute or not) metadata. Now I know they don't but external links (with URLs) do. --Obsuser (talk) 14:13, 1 July 2016 (UTC)
If wikiling square brackets can be and are recognized and removed from metadata, why not to remove other things such as &nbsp;, some templates, some tags etc. too? --Obsuser (talk) 18:16, 8 July 2016 (UTC)

Small caps formatting in |author=[edit]

There are editors (or at least one that I know of: Tisquesusa) who insist on small caps formatting of author names in references. The argument is that the ability to customize appearance of names is important, and that a technical solution should be found to enable it (i.e. a form of |author-mask= functionality). It would be helpful to discuss whether the current recommendation is to be upheld, or perhaps there is a way to accommodate this request. --Dcirovic (talk) 22:42, 30 June 2016 (UTC)

Small caps are not allowed in |author=, per the Manual of Style, which says "Avoid writing with all capitals, including small caps, when they have only a stylistic function."
Also see this May 2015 RFC. Quoting from the closing statement: "essentially the consensus is that all caps should not be used, except when omitting them gives the section a completely different meaning, such as in scientific terms."
As for the specific diff, the {{aut}} template that is being used inside those cite templates "should not be used in citation templates such as Citation Style 1 and Citation Style 2, because it includes markup that will pollute the COinS metadata they produce". This is a quotation from the documentation for the {{aut}} template. The documentation for the template explains the reasons in detail and provides alternative cite templates to use if small caps are still desired. – Jonesey95 (talk) 00:05, 1 July 2016 (UTC)
The list of exceptions in the MOS section you cite includes "some citation styles". But I think Citation Style 1 is not one of them. —David Eppstein (talk) 00:22, 1 July 2016 (UTC)
The editor's claim that there are 35k uses of {{aut}} plainly wrong. That template has about 12k page uses; {{small caps}} has a mere 70 page uses. According to this insource: search, there are less than 25 pages using {{aut}} in |author=; I found none in a similar search using |last= or |lastn=.
Trappist the monk (talk) 00:41, 1 July 2016 (UTC)
Hi all, the thing is: is something is broken, fix it. It doesn't help avoiding the problem by postponing the solution. To avoid the problems is avoiding triggering a solution and that's what's needed. I hope a solution will be developed soon, as that is the only way forward. Cheers, Tisquesusa (talk) 02:44, 1 July 2016 (UTC)
Tisquesusa, thanks for joining this discussion. Please define what you think is broken so that we can help you fix it.
Citation Style 1 does not allow {{aut}}/{{smallcaps}} or all caps in citations as a text styling method. Reasons for this are explained in copious detail in the template's documentation. If you want all caps in your citation style, which is contrary to MOS (but which is probably OK with CITEVAR, which has been interpreted to allow editors to do just about anything), you can use {{Cite LSA}} or another template that allows such styling, or you can write your citations without the use of cite templates. There are probably other valid options as well. – Jonesey95 (talk) 03:39, 1 July 2016 (UTC)
Yes I saw it generates an error in Zotero (or something like that). To me, that means; task to solve the error, as apparently it is not about the small caps themselves, as LSA is possible. I will rewrite the citations to the LSA style then to keep the format. Will take some time as I cite a lot in the articles I write or expand. It could be good to mention it clearer, the LSA solution is somewhat hidden in a list of suggestions, and the page itself does not even list the option of |url= which is possible, I just tested it. But that's my general problem with "Help" pages in Wikipedia, they are far too unclear for even relatively experienced users, while the wiki syntax is easy enough. Thanks for the link, Tisquesusa (talk) 05:30, 1 July 2016 (UTC)
I'm aware, of course, of the interpretation of CITEVAR that says it allows smallcaps, but be clear that this is directly against the MOS and not acceptable to many editors. Peter coxhead (talk) 05:55, 1 July 2016 (UTC)
I was first one to suggest Tisquesusa not to use that as it is uncommon; however, the user was trying to prove it is a "professional" way to list out names in the particular citations (it is not true, obviously; not only for cited bibliography but for any CS1 template). --Obsuser (talk) 14:13, 1 July 2016 (UTC)

Volume and Issue default fields for Citoid w/ Journals[edit]

Currently, the invocation of {{cite journal}} in citoid and VE's insert template function, doesn't, by default, include the fields of "Volume" and "Issue". I am guessing for the vast majority (academic journal and popular magazine runs) of the uses of this template, having those fields is crucial to identifying the correct issue within the print run of the work. Can someone who is familiar with TemplateData make these default fields? It seems silly to have new editors know they need to add this field, instead of spoon feeding the option to them. Thanks much, Sadads (talk) 15:29, 5 July 2016 (UTC)

Not a fan of ve and certainly not a fan of TemplateData so I'm not going to be editing that. Perhaps you meant 'suggested' instead of 'default'. Since the TemplateData documentation is at best mediocre, I can only guess that 'default' applies to the parameter's assigned value – if |volume= is left blank, then ve uses the value set in the TemplateData 'default' field. The 'suggested' as opposed to 'optional' setting would seem to be what it is that you want.
To edit the {{cite journal}} TemplateData, go to Template:Cite_journal#TemplateData and edit that section. You will see a button at the top that reads 'Manage TemplateData'. Click that and you are in the TemplateData editor.
Trappist the monk (talk) 15:52, 5 July 2016 (UTC)
@Sadads: You shouldn't be using {{cite journal}} for popular magazines, but {{cite magazine}} - it also has |volume= and |issue=, but they are displayed differently. --Redrose64 (talk) 17:08, 5 July 2016 (UTC)
Yes check.svg Done Thanks for the feedback/suggestion @Trappist the monk:. If you haven't tried visual editor in the last 6 months or so, I am a convert: almost all the bugs are gone, and its only about 5-10% of my edits in article space that I want something more. I have also found it extremely useful in my volunteer outreach role, when I am running editathons, etc: not having to teach folks templates, and how they work -- instead teaching them simple forms for specific use cases is beautiful. Thanks for the suggestion Redrose64: was not familiar with cite magazine -- at some point in redirected didn't it? I think I have just never used it because all of the major citation guidelines and help tools just provide journal (which offers much the same metadata preservation). Sounds like something we ought to have a bot for, Sadads (talk) 22:21, 5 July 2016 (UTC)

Cite web is malfunctioning[edit]

template markup removed from section heading. here's the link {{Cite web}}—Trappist the monk (talk) 10:18, 13 July 2016 (UTC)


I tried inserting this:

{{cite web |url= |title=Lisa's Hourglass Is Back! |work=[[MacTech]] |publisher=Xplain |volume=5 |issue=5 |first=Mike |last=Morton |location=[[Waipahu, HI]]}}

It gave me this:

Morton, Mike. "Lisa's Hourglass Is Back!". MacTech. Waipahu, HI: Xplain. 

As you can see, the |issue=, |volume= and |location= are ignored without an error message saying they are unknown parameters. (Doc pages says they are supported.) I could swear this is new. I had seen these parameters working before.

FleetCommand (Speak your mind!) 07:09, 12 July 2016 (UTC)

|location= is working again. FleetCommand (Speak your mind!) 07:13, 12 July 2016 (UTC)
MacTech is a journal so you should use {{cite journal}}:
{{cite journal |url= |title=Lisa's Hourglass Is Back! |work=[[MacTech]] |publisher=Xplain |volume=5 |issue=5 |first=Mike |last=Morton |location=[[Waipahu, HI]]}}
Morton, Mike. "Lisa's Hourglass Is Back!". MacTech (Waipahu, HI: Xplain) 5 (5). 
Trappist the monk (talk) 11:11, 12 July 2016 (UTC)
Or, {{Cite magazine}}, unless you consider that in the class of "academic and scientific papers and journals". Per {{Cite journal}}. ―Mandruss  15:36, 12 July 2016 (UTC)
Judging from FC's edit log, he already knows as much. He has used {{Cite news}}.
But why is {{cite web}} broken? And why just this instance when I though we have the green light to go ahead and merge these two and have one less damn template around the place?
Best regards,
Codename Lisa (talk) 09:22, 13 July 2016 (UTC)
{{cite web}} is not broken. In November 2015 we adjusted how Module:Citation/CS1 supports |volume=, |issue=, |page(s)=. See the discussion.
I do not understand your last sentence. Merge what two? From whom did we get a green light? Can you point to a discussion about these matters?
Trappist the monk (talk) 10:18, 13 July 2016 (UTC)
@Trappist the monk: Did you or did you not prevent {{Cite web}} from displaying them? If yes, why Cite web isn't generating an error message to the effect that they are unsupported? (As it does when you pass |FooBarParam=FUBAR to it.) And why the documentation didn't get an update?
Best regards,
Codename Lisa (talk) 13:20, 13 July 2016 (UTC)
P.S. Please excuse any delay in my response time. I have a huge copyright mess to clean up. —Best regards, Codename Lisa (talk) 13:25, 13 July 2016 (UTC)
I did write: In November 2015 we adjusted how Module:Citation/CS1 supports |volume=, |issue=, |page(s)= and I did point to the discussion that preceded the change. So, yeah, I did prevent {{Cite web}} from displaying them.
cs1|2 is rather selective about reporting unsupported valid (in the sense that they are listed in Module:Citation/CS1/Whitelist) parameters. Off the top of my head I can think of {{cite arxiv}} which has a very limited set of parameters it supports and certain cases of |chapter= aliases (see Category:CS1 errors: chapter ignored).
The current Template:Cite web/doc does not mention |volume= or |issue= except in the COinS boilerplate. Because that template's documentation is itself a template, it's hard to know if {{cite web}} ever supported |volume= and |issue=. Certainly, it does not now and the documentation reflects that.
So what about the green light to merge something? I'm still unclear what it is that you're talking about.
Trappist the monk (talk) 00:55, 14 July 2016 (UTC)
Thank you for finally answering my question, after much beating around the bush. Of course, your point-making style of writing clearly indicates there is a lot bad blood between you and Mrs. "Best Regards" here, so I'll get out of the way and let you two kill each other however you see fit. —FleetCommand (Speak your mind!) 13:42, 14 July 2016 (UTC)

Two citations I can't figure out how to format correctly[edit]

Somehow neither my familiarity with these templates nor the documentation is helping me figure out how to cite these two citations using the templates in a way that generates correct metadata and avoids error messages.

First, from Monterey Road (California), we have the citation

I would like to format it as

  • {{cite magazine|publisher=California State Automobile Association|year=1974|url=|magazine=Motorland|issue=2|page=8}}

but that doesn't work:

Abusing |author= instead of |publisher= is a little better, but still no good.

  • California State Automobile Association (1974). "none". Motorland. No. 2. p. 8. 

It gets the text formatted the way I want, but puts the url in a bad place and complains about the missing or empty title. I also tried setting |title=none to no avail. Possibly the magazine piece has an actual title, but the Google books snippet view (sufficient for verifying the fact claimed to that source) is inadequate to locate it. In any case, we should be capable of formatting non-titled magazine information. (This article actually uses CS2 and {{citation}} but the behavior is the same.)

The second one is an external link from Erdős–Gyárfás conjecture:

There seems to be no way to include a link both on the |title= and |work= without a complaint from the template. Changing |title= to |contribution= and |url= to |contribution-url=, in order to free up |title= and |url= for the second link, also doesn't work; the template just ignores the url.

These sorts of inflexibilities are driving me away from using the citation templates. I can only imagine how much stronger the same effect is likely to be on new users. —David Eppstein (talk) 20:23, 12 July 2016 (UTC)

We've had a number of discussions regarding the second case, mostly resolving to the point that we don't need to provide the URL to the work's site if we have a more specific web page of interest (and sometimes even where we don't). I'm pretty sure we've also discussed #1, but I am unsure of keywords to look for that one in the archive. --Izno (talk) 21:11, 12 July 2016 (UTC)
A bit naughty, but how about *{{cite magazine|title=Article|publisher=California State Automobile Association|year=1974|url=|magazine=Motorland|issue=2|page=8}}
  • "Article". Motorland. No. 2 (California State Automobile Association). 1974. p. 8. 
I'd agree with Izno, the link to the article implicitly gives a link to the whole. {{cite web | url = | title = Erdős Gyárfás Conjecture on 2-power Cycle Lengths | work = Open Problems - Graph Theory and Combinatorics | author = West, Douglas B.}}
HTH, Martin of Sheffield (talk) 21:21, 12 July 2016 (UTC)
(edit conflict) Regarding the first situation, the title of the magazine article is not known because you're accessing it through snippet view. We can't read enough of the page that way to determine the proper article title to credit. We can't even be sure that Google's pagination matches that of the print magazine they're reproducing; what is page 8 to them might have a different numbering in print. In short, the citation is incomplete and the error is basically valid .The best course of action, long term, is for someone to attempt to locate the actual source in print and fill in the missing details. (Also, it would be better to consult the full article to see if there are additional details to be added to our article from that source, details obscured in snippet view. Imzadi 1979  21:24, 12 July 2016 (UTC)
Thanks for the clarification. Let me reiterate my broader point, since you all seem to be overlooking it. This inflexibility is driving me away from using the citation templates. I had already given up on using the templates for the Roadways cite, and have now gone ahead and reformatted the West cite manually as well. —David Eppstein (talk) 21:25, 12 July 2016 (UTC)
Interesting POV. Given a free choice I tend to use {{citation}}. Just fill in all that is known and let the system worry about the formatting. Citation has the advantage over the Cite XYZ templates that it sets up harvid for you, which makes using {{sfn}} simplicity itself. Martin of Sheffield (talk) 21:34, 12 July 2016 (UTC)
Ok, don't believe me that these templates are increasingly becoming very difficult to use. I don't care any more. —David Eppstein (talk) 21:54, 12 July 2016 (UTC)
The question here is mostly that |title=none should be supported, but also that the URL in this instance is useless. Headbomb {talk / contribs / physics / books} 21:57, 12 July 2016 (UTC)
How about: "[title unknown]". Motorland. No. 2 (California State Automobile Association). 1974. p. 8. 
That eliminates the error message and correctly shows that we do not know the title of the article we are citing. Some text in magazines appears with no title at all, so putting "[no title]" or something similar should suffice.
By the way, the article in question appears to be called "Commentary: Freeway link near San Jose needs finishing". Do a search for "commentary" or "dirty car again" to see the top of the page. I was unable to verify the page number. – Jonesey95 (talk) 22:06, 12 July 2016 (UTC)

cite arxiv tweak[edit]

{{cite arXiv | eprint = 1409.0473| authors = Dzmitry Bahdanau, Cho Kyunghyun, Yoshua Bengio | title = Neural Machine Translation by Jointly Learning to Align and Translate | year = 2014 | class = cs.CL }} yields the following

That's because the logic expect either |author= or |last=/|first= to be there, otherwise it display this message. The template should be updated accordingly (not show the "a bot will fix this soon" message / not categorize in Category:Articles_with_missing_Cite_arXiv_inputs).

Headbomb {talk / contribs / physics / books} 06:24, 14 July 2016 (UTC)

I thought we were moving away from |authors= for a variety of reasons. – Jonesey95 (talk) 12:50, 14 July 2016 (UTC)
Yes, but the error shouldn't be "a bot will complete this citation", because no bots handles converting |authors= to not |authors=. If anything, it should be one of those red "|authors= is deprecated" messages, which categorize the article in the appropriate category. Headbomb {talk / contribs / physics / books} 14:01, 14 July 2016 (UTC)
I've added |authors= to the list of parameters not supported by {{cite arxiv}} and modified {{cite arxiv/new}} so that if all of its authors are listed in |authors=, if will not solicit the bot but instead call the module and have the module render the appropriate error messages:
{{cite arXiv/new | eprint = 1409.0473| authors = Dzmitry Bahdanau, Cho Kyunghyun, Yoshua Bengio | title = Neural Machine Translation by Jointly Learning to Align and Translate | year = 2014 | class = cs.CL }}
"Neural Machine Translation by Jointly Learning to Align and Translate". 2014. arXiv:1409.0473free to read [cs.CL].  Unsupported parameter(s) in cite arXiv (help)
{{cite arXiv/new | eprint = 1409.0473| authors = Dzmitry Bahdanau, Cho Kyunghyun, Yoshua Bengio | year = 2014 | class = cs.CL }}
. 2014. arXiv:1409.0473free to read [cs.CL].  Unsupported parameter(s) in cite arXiv (help); Missing or empty |title= (help)
{{cite arXiv/new | eprint = 1409.0473 | title = Neural Machine Translation by Jointly Learning to Align and Translate | year = 2014 | class = cs.CL }}
A bot will complete this citation soon. Click here to jump the queue arXiv:1409.0473.
Trappist the monk (talk) 09:37, 15 July 2016 (UTC)
Is it possible to mention specifically that its |authors= that is not supported / say that |authors= is deprecated? Headbomb {talk / contribs / physics / books} 12:41, 15 July 2016 (UTC)
|authors= is discouraged but not deprecated. Before it is deprecated we need to find a way to deal with its aliases (|people=, |host=, |credits=) which, in use, often include role descriptors (director, producer, third assistant sycophant, etc) mostly used in {{cite AV media}}.
As the code is currently written, it is not possible to add the offending parameter to the error message. One of my long-standing TODOs is to find a better way of determining if {{cite arxiv}} is written with parameters not supported by the template. When I find that solution, I'll add the unsupported parameter name to the error message.
Trappist the monk (talk) 12:26, 18 July 2016 (UTC)
Perhaps a parameter like |author-role=director could be made, which could append (director) at the correct location in the rendered author-list?   ~ Tom.Reding (talkdgaf)  13:01, 18 July 2016 (UTC)
It may be easier to add aliases to |author= (and perhaps |editor=). The role could then be appended depending on the alias used. (talk) 13:40, 18 July 2016 (UTC)

Multiple authors II[edit]

Further to Help talk:Citation Style 1/Archive 18#Multiple authors, and User talk:Dcirovic/Archive 1#Authors, it appears that Dcirovic (talk · contribs) has resumed their behaviour. I have left a note at User talk:Dcirovic#Authors, again. --Redrose64 (talk) 14:37, 14 July 2016 (UTC)

author-link and editor-link acting weird with interwiki links[edit]

See this version of Carmen, which fails to render the editor "Neef, Sigrid" when |editor-link=de:Sigrid Need is present. Omitting the de: unsatisfactorily solves this problem.

Cite book compare "editor-link=de:Sigrid Need"
{{ cite book | editor-link=de:Sigrid Need | isbn=3-8290-3571-3 | editor=Neef, Sigrid | publisher=Könemann | title=Opera: Composers, Works, Performers | location=Cologne | year=2000 | edition=English }}
Live Neef, Sigrid, ed. (2000). Opera: Composers, Works, Performers (English ed.). Cologne: Könemann. ISBN 3-8290-3571-3. 
Cite book compare "author-link=de:Sigrid Need"
{{ cite book | isbn=3-8290-3571-3 | author=Neef, Sigrid | author-link=de:Sigrid Need | publisher=Könemann | year=2000 | title=Opera: Composers, Works, Performers | location=Cologne | edition=English }}
Live Neef, Sigrid (2000). Opera: Composers, Works, Performers (English ed.). Cologne: Könemann. ISBN 3-8290-3571-3. 
Cite book compare "editor-link=Sigrid Need"
{{ cite book | editor-link=Sigrid Need | isbn=3-8290-3571-3 | editor=Neef, Sigrid | publisher=Könemann | title=Opera: Composers, Works, Performers | location=Cologne | year=2000 | edition=English }}
Live Neef, Sigrid, ed. (2000). Opera: Composers, Works, Performers (English ed.). Cologne: Könemann. ISBN 3-8290-3571-3. 
Cite book compare "author-link=Sigrid Need"
{{ cite book | isbn=3-8290-3571-3 | author=Neef, Sigrid | author-link=Sigrid Need | publisher=Könemann | year=2000 | title=Opera: Composers, Works, Performers | location=Cologne | edition=English }}
Live Neef, Sigrid (2000). Opera: Composers, Works, Performers (English ed.). Cologne: Könemann. ISBN 3-8290-3571-3. 

  ~ Tom.Reding (talkdgaf)  18:07, 14 July 2016 (UTC)

What's doubly weird is that the editor is rendered here in the {{cite compare2}} calls above, but not in my sandbox...   ~ Tom.Reding (talkdgaf)  18:08, 14 July 2016 (UTC)

@Tom.Reding: they all render exactly as they should for me. Peter coxhead (talk) 18:17, 14 July 2016 (UTC)
@Peter coxhead: on all 3 pages (here, Carmen, sandbox)? I've null-edited all 3 of them, but that's not working.   ~ Tom.Reding (talkdgaf)  18:21, 14 July 2016 (UTC)
Whoops, no; at Carmen there's just a blank for the editor, displayed and in the source HTML. Must be a bug. Peter coxhead (talk) 18:46, 14 July 2016 (UTC)
That is very strange. I am seeing a rendered editor name and link here on this page, but not at User:Tom.Reding/sandbox2. I have copied and pasted the full contents of the Sandbox2 page to this page just to make sure I'm not missing invisible characters or something. – Jonesey95 (talk) 19:25, 14 July 2016 (UTC)

Perhaps this isn't a problem with cs1|2 but a problem with the mark-up. Remember the old days when interlanguage links were added to the article? Then we moved them all to wikidata so we've forgotten that those old interlanguage links had the form: [[de:Sigrid Neef]] (and it is Neef). Those constructs added the link to the languages menus at left but were not visible in the article.

In those days, and still today, if you want a visible interlanguage link in an article, the format is: [[:de:Sigrid Neef]]. Right? See Help:Interlanguage_links.

Trappist the monk (talk) 22:39, 14 July 2016 (UTC)

Eureka! [You] found it! Carmen & User:Tom.Reding/sandbox2 now display as intended (except for the Neef/d typo, which never happened on Carmen). I'll leave the above examples unchanged for permalink comparisons b/w here & my sandbox2.
So it works just like [[:Category:, [[:File:, etc; wonderful. I hadn't connected the syntaxes for some reason...   ~ Tom.Reding (talkdgaf)  01:53, 15 July 2016 (UTC)
The small remaining bug is that both {{cite compare}} and {{cite compare2}} display "Neef, Sigrid" here, but not when transcluded elsewhere (sandbox). One would expect them to at least be self-consistent regardless of their location, especially since they are used to check and instruct parameter usage.
Cite book compare
{{ cite book | editor-link=de:Sigrid Need | isbn=3-8290-3571-3 | editor=Neef, Sigrid | publisher=Könemann | title=Opera: Composers, Works, Performers | location=Cologne | year=2000 | edition=English }}
Old Neef, Sigrid, ed. (2000). Opera: Composers, Works, Performers (English ed.). Cologne: Könemann. ISBN 3-8290-3571-3. 
Live Neef, Sigrid, ed. (2000). Opera: Composers, Works, Performers (English ed.). Cologne: Könemann. ISBN 3-8290-3571-3. 
{{cite compare}}
Also, replacing de: with de&#58; didn't change anything.   ~ Tom.Reding (talkdgaf)  12:41, 15 July 2016 (UTC)
It's not a problem with either of those templates, it's the way that interlangauge links are parsed. In all namespaces, [[:de:Sigrid Need]] produces an inline link to the foreign-language page. In talk namespaces only, [[de:Sigrid Need]] produces an inline link to the foreign-language page, but in non-talk namespaces, [[de:Sigrid Need]] produces nothing inline, instead it adds a link to the "languages" list in the left sidebar. --Redrose64 (talk) 21:03, 15 July 2016 (UTC)
Ah, all is explained! So would it be sensible for the template to implicitly add ":" to interlanguage link values where it has been omitted? Peter coxhead (talk) 21:47, 15 July 2016 (UTC)
Yes, or at least an error message when in |author-link= or |editor-link=.   ~ Tom.Reding (talkdgaf)  22:45, 15 July 2016 (UTC)

Consulting editors[edit]

Hello. How do I cite "consulting editors" for this book in Zev Garber's article please? Someone added the book without using the citation template, but I'd like to cite it properly and include the OCLC. Thank you.Zigzig20s (talk) 21:40, 14 July 2016 (UTC)

Use |others=. See the documentation for {{cite book}}. – Jonesey95 (talk) 22:30, 14 July 2016 (UTC)
No, I don't think so. This looks weird:
  • Berenbaum, Michael; Rubenstein, Betty Rogers, eds. (1995). What Kind of God? Essays in Honor of Richard L. Rubenstein. Rubenstein Feibel, Hannah; Garber, Susan; Garber, Zev. Lanham, Maryland: University Press of America. ISBN 9780761800361. OCLC 32780110. 
User:Jonesey95: Did you mean something else?Zigzig20s (talk) 23:19, 14 July 2016 (UTC)
I meant like this:
  • Berenbaum, Michael; Rubenstein, Betty Rogers, eds. (1995). What Kind of God? Essays in Honor of Richard L. Rubenstein. Consulting editors: Rubenstein Feibel, Hannah; Garber, Susan; Garber, Zev. Lanham, Maryland: University Press of America. ISBN 9780761800361. OCLC 32780110. 
as is roughly described in the documentation to which I referred you. – Jonesey95 (talk) 23:33, 14 July 2016 (UTC)
OK I've updated Zev Garber's article. I think it's not ideal that the consulting editors don't come just after the main editors, though. Could someone please fix this? I also think the citation templates should include editors, not just authors.Zigzig20s (talk) 23:47, 14 July 2016 (UTC)


What is the work parameter for? Could someone please list it in the Parameters section of the documentation for me? Hyacinth (talk) 23:38, 18 July 2016 (UTC)

|work= is documented, such as that is, in Template:Cite web#Title, Template:Cite news#Periodical, and Template:Cite journal#Periodical. Also see Help:Citation Style 1#Work and publisher.
Trappist the monk (talk) 00:00, 19 July 2016 (UTC)

Advise on citing EI2[edit]

I want to cite an article on Encyclopedia of Islam titled Safawids. I'm just having trouble on the title and series

Savory, R.M.; Bruijn, J.T.P. de; Newman, A.J.; Welch, A.T.; Darley-Doran, R.E. (1995). "Ṣafawids". In Bearman, P.; Bianquis, Th.; Bosworth, C.E.; van Donzel, E.; Heinrichs, W.P. Encyclopaedia of Islam 8 (2nd ed.). Leiden: Brill. ISBN 9004098348. 

As far as I'm aware is this correct. Alexis Ivanov (talk) 15:02, 21 July 2016 (UTC)

The only thing that I would change is in the 2nd author's name: |last2=de Bruijn and |first2=J.T.P.. The "de" like "von" or "van" refers to the last name, and should be part of that field. Btw, this template's doc is particularly confusing when it comes to distinctions between the work, the article within the work, and the wikilinks applying to both. The sections Template:Cite encyclopedia §§ Title​ and In-source locations are the worst offenders. And this site is an encyclopedia to begin with. (talk) 17:27, 21 July 2016 (UTC)
Also, there seems to be an ISBN-13 for this, which is preferred (ISBN 9789004098343). (talk) 17:33, 21 July 2016 (UTC)

Nothing to do with Citation Style 1 but there are a number of problems here.

  • The title page of the volume gives the editors as: C.E. Bosworth, E. Van Donzel, W.P. Heinrichs and G. Lecomte (see here)
  • The page numbers within the volume should be specified: pages=765-793
  • The author A. Welch (Antony Welch, University of Victoria) uses only a single initial.
  • It would help the reader to include a link to the scan on the Internet Archive available here (using chapter-url=)
  • I agree that it is sensible to list all the authors together - although the actual article specifies an author for each section of the article.

Aa77zz (talk) 21:38, 21 July 2016 (UTC)

There's no mention of |chapter-url= in the template's doc. To add to the confusion, |url= links the article ("chapter") not the encyclopedia ("work") unlike other cs1 templates. (talk) 00:36, 22 July 2016 (UTC)
|url= links the title of the article:
Savory, R.M.; Bruijn, J.T.P. de; Newman, A. J.; Welch, A.; Darley-Doran, R.E. (1995). "Ṣafawids". In Bearman, P.; Bianquis, Th.; Bosworth, C. E.; van Donzel, E.; Heinrichs, W.P. Encyclopaedia of Islam 8 (2nd ed.). Leiden: Brill. pp. 765–793. ISBN 9004098348. 
Better? – Jonesey95 (talk) 01:34, 22 July 2016 (UTC)
I don't think so. As pointed out above, it is |chapter-url= that should link the in-source location fragment (the article). |url= is supposed to link the enclosing source (work), in this case, the encyclopedia. (talk) 13:08, 22 July 2016 (UTC)
The {{cite encyclopedia}} documentation explains: "title: Title of source. Can be wikilinked to an existing Wikipedia article or url may be used to add an external link, but not both." I have fixed an error in the portion of the documentation that describes |encyclopedia=. – Jonesey95 (talk) 16:26, 22 July 2016 (UTC)

Protected edit request on 22 July 2016[edit]


This is an edit request for Module:Citation/CS1. The aim of this edit request is to implement the May 2016 consensus. I have already tested this request via Module:Citation/CS1/sandbox, Template:Cite web/sandbox, Template:Cite news/sandbox, the result of which you can see at User:Codename Lisa/sandbox § May_2016 consensus.

Please locate the following code at lines 2956–2995:

	local Publisher;
	if is_set(Periodical) and
		not in_array(config.CitationClass, {"encyclopaedia","web","pressrelease","podcast"}) then
		if is_set(PublisherName) then
			if is_set(PublicationPlace) then
				Publisher = PublicationPlace .. ": " .. PublisherName;
				Publisher = PublisherName;  
		elseif is_set(PublicationPlace) then
			Publisher= PublicationPlace;
			Publisher = "";
		if is_set(PublicationDate) then
			if is_set(Publisher) then
				Publisher = Publisher .. ", " .. wrap_msg ('published', PublicationDate);
				Publisher = PublicationDate;
		if is_set(Publisher) then
			Publisher = " (" .. Publisher .. ")";
		if is_set(PublicationDate) then
			PublicationDate = " (" .. wrap_msg ('published', PublicationDate) .. ")";
		if is_set(PublisherName) then
			if is_set(PublicationPlace) then
				Publisher = sepc .. " " .. PublicationPlace .. ": " .. PublisherName .. PublicationDate;
				Publisher = sepc .. " " .. PublisherName .. PublicationDate;  
		elseif is_set(PublicationPlace) then 
			Publisher= sepc .. " " .. PublicationPlace .. PublicationDate;
			Publisher = PublicationDate;

...and replace it with:

	local Publisher;
	if is_set(PublicationDate) then
		PublicationDate = " (" .. wrap_msg ('published', PublicationDate) .. ")";
	if is_set(PublisherName) then
		if is_set(PublicationPlace) then
			Publisher = sepc .. " " .. PublicationPlace .. ": " .. PublisherName .. PublicationDate;
			Publisher = sepc .. " " .. PublisherName .. PublicationDate;  
	elseif is_set(PublicationPlace) then 
		Publisher= sepc .. " " .. PublicationPlace .. PublicationDate;
		Publisher = PublicationDate;

Best regards,
Codename Lisa (talk) 10:33, 22 July 2016 (UTC)

Assuming that real life can stay out of the way for long enough, I intend give advance notice that changes accumulated since the last live update will be incorporated into the live module over the weekend of 30–31 July. This change will be part of that.
Additional test cases in Editor Jonesey95's sandbox at Special:Permalink/724937035.
Trappist the monk (talk) 11:17, 22 July 2016 (UTC)
I have moved the parentheses that wrap |publication-date= into Module:Citation/CS1/Configuration/sandbox. This changes the line:
PublicationDate = " (" .. wrap_msg ('published', PublicationDate) .. ")";
PublicationDate = wrap_msg ('published', PublicationDate);
Trappist the monk (talk) 11:38, 22 July 2016 (UTC)

Update to the live CS1 module weekend of 30–31 July 2016[edit]

Over the weekend of 30–31 July I propose to update the live modules from their sandboxen:

changes to Module:Citation/CS1:

  1. moved {{cite thesis}} and {{cite interview}} static text to /Configuration; discussion
  2. removed parentheses from around publisher, per RFC; discussion, implementation discussion
  3. added separator before short |volume= name for consistency; discussion
  4. add |access-date= error when |pmc= makes url; discussion
  5. add bot specific maint cat and |dead-url= keyword; discussion and discussion
  6. fix corporate authors in |vauthors= parameter value; discussion
  7. proper kerning for “” and ‘’; discussion
  8. categorize use of |authors= and |editors=; discussion
  9. revised |publisher=, |location=, |publication-date= handling; discussion

changes to Module:Citation/CS1/Configuration

  1. add aliases for contributors and translators for consistency with authors and editors; discussion
  2. added {{cite thesis}} and {{cite interview}} static text;
  3. added separator before short |volume= name for consistency;
  4. add bot specific maint cat and |dead-url= keyword;
  5. categorize use of |authors= and |editors=;
  6. add free-to-read icon to presentation, arXiv identifier; discussion
  7. move parentheses into published message;

changes to Module:Citation/CS1/Whitelist

  1. add aliases for contributors and translators for consistency with authors and editors;

changes to Module:Citation/CS1/Date validation

  1. n.d. bug fix; see discussion
  2. use the internationalized access-date validation; see discussion
  3. strip white space from reformatted dates; see discussion
  4. year has something other than year when date is set; see discussion

changes to Module:Citation/CS1/Identifiers

  1. adjust bibcode detection to allow digits in positions 7 through 9 see discussion
  2. add free-to-read icon support for arXiv identifier;

Trappist the monk (talk) 10:34, 23 July 2016 (UTC)

If it's done for the arxiv, it should be done for pmc and rfc as well. Possibly others too, I think OSTI has fully available sources, but I need to check if that's always the case. But it might be better to wait for the result of the discussion above to implement everything at once, rather than partially. Headbomb {talk / contribs / physics / books} 11:23, 24 July 2016 (UTC)
I have just added |pmc= and |rfc=. Trappist the monk, can you review my edits (here and here) to make sure I did not break anything? I think it's fine if we push the changes even if some "always-free" parameters are not currently marked as such. Once the change is live, we will probably attract more attention and it will be easier to reach a consensus about the parameters and icon design. − Pintoch (talk) 14:38, 24 July 2016 (UTC)
Is Help_talk:Citation_Style_1#cite_arxiv_tweak included the proposed update? I can't see it in the list, but I'm pretty sure the code for this was tested and working. Headbomb {talk / contribs / physics / books} 21:09, 24 July 2016 (UTC)
Trappist the monk (talk) 09:31, 25 July 2016 (UTC)