Help talk:Citation Style 1

Adding open access links to references

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

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

Only 13 page watchers at the project's talk page.

If your bot is going to add |id={{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}}

giving

Smith, J. (2016). "Article of things ". Journal of Things 66 (3): 11–15. doi:10.1234/0123456789 .

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">[http://dx.doi.org/10.1234/0123456789 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 things". Journal of Things 66 (3): 11–15. doi:10.1234/0123456789.

—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: . 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]] → – Headbomb

[[File:Open_Access_logo_PLoS_white_green.svg|9px|link=|open access publication - free to read]] → – ttm

—Trappist the monk (talk) 00:55, 24 June 2016 (UTC)

adding free-to-read icons

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/0610068.
• Leinster, Tom (2007). "The Euler characteristic of a category as the sum of a divergent series". arXiv:0707.0835 [math.CT].

The lock here is one that I modified from File:Open_Access_logo_PLoS_white_green.svg (). The primary differences are that the modified lock has a transparent background (the original's is white) and that the shackle is slightly more open:

For the time being, I have elected to leave the pmc identifier as it is. The pmc identifier is unique among the identifiers that cs1|2 supports because it causes the module to link |title= with a redundant link that is the same as the identifier's link. I would prefer that all identifiers act the same way so would prefer to add the free to read lock to the pmc identifier and remove the special-case code that links |title= with the identifier's url. I did remove that special-case code once, but that made some members of WP:MED rather angry.

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

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

if {{{url-free|}}}
    |url={{{url-free|}}}
    |url-icon=free

   else

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

         else
             |url={{{url|}}}

            if {{{access|}}}
                |url-icon={{{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)

72.43.99.146 (talk) 15:07, 30 June 2016 (UTC)

Well, personally, I detest flagging paywalled/subscription/registration/etc, and usually remove those from any article i edit in a more-than-drive-by-way, but flagging open access documents? That's a hell yes from me. This is extremely useful to the reader with no subscription to those journals, which consists of pretty much the entire world that's not currently attending or working at a university. "This link you can read!" Headbomb {talk / contribs / physics / books} 15:42, 30 June 2016 (UTC)

The logical conclusion of that is to remove printed links as well, they require you to seek out and purchase a book. A paywalled link is still useful, it indicates that the associated facts have been checked and are defensible even if the current reader can't do so for himself. Most readers of WP will not follow citations just as most drivers accept the "RON" rating of fuel. It is checkable against a standard, but heck I just want to read/drive. Martin of Sheffield (talk) 08:57, 1 July 2016 (UTC)

I agree with the IP that learning the meaning of the lock is not straightforward. I think its shape and color are fairly intuitive though, and not too intrusive, so I do not think it would harm to add it. This discussion here gathers specialists, so we might get more representative feedback once we have deployed the changes.

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:

qK – 9px lock image

We might shrink the lock:

qK – 8px lock image

I've been wondering if the lock is too 'heavy'. Perhaps the lines could be reduced to 75% (or even 50%) of their current thickness. If you look at the lines in the normal external link icon, they are quite fine:

http://example.com

—Trappist the monk (talk) 21:32, 30 June 2016 (UTC)

I've made a 'lighter' lock that has stroke width that is 75% of the lock now used in the cs1 sandbox Can you tell the difference? Which of these is better?:

• Leinster, Tom (2007). "The Euler characteristic of a category as the sum of a divergent series". arXiv:0707.0835 [math.CT].
• Leinster, Tom (2007). "The Euler characteristic of a category as the sum of a divergent series". arXiv:0707.0835 [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 registration". 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: . My green lock is derived from that design. At 9px width, small detail like the notch you describe will be lost. Even the much more open shackle of the green lock is relatively unnoticeable. Here are the two locks at 18px width:

—Trappist the monk (talk) 17:23, 1 July 2016 (UTC)

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

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

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

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

Actually, this is more a description of a height issue than a valignment issue, since the lock is valigned (centered) with the [, but not with the 0835.   ~ Tom.Reding (talk ⋅dgaf)  16:45, 2 July 2016 (UTC)

I'm not inclined to change to anything smaller than 9px. When I zoom in on these, the 8px version blurrs unacceptably at lower zoom levels than the 9px version. I notice that the system external link icon is sharp regardless of the zoom level so that may mean that in the long term we will want to recreate these icons at 8px or 9px width. Right now the original images are 640×1000px shrunk to 8px or 9px. I suspect that when we zoom in, all of the resizing artifacts become apparent.

0707.0835 [math.CT] – 9px

0707.0835 [math.CT] – 8px

—Trappist the monk (talk) 17:17, 2 July 2016 (UTC)

Parameters which are not always free

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

• 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.) 72.43.99.138 (talk) 17:43, 5 July 2016 (UTC)

That's too complicated and is super unclear (to which parameter would |access-state= or |access1/2/3/etc.-state= apply?). If the doi (or other id) is free, then we flag it as that. There's no need to flag each individual identifiers as free/registration required/subscription required/paywalled/embargoed/etc. If it's free flag it. If not, keep it a normal link. For the general url, |access= can be used. Headbomb {talk / contribs / physics / books} 17:49, 5 July 2016 (UTC)

If different lock icons are used for different levels of access then only one parameter need be used for different scenarios: |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. 72.43.99.138 (talk) 19:04, 5 July 2016 (UTC)

We are talking here about ways to specify, within a particular citation, different access levels for the different external links in the citation. The functionality you are talking about (defining a particular access state for the whole citation) is already possible via parameters such as |subscription=. − Pintoch (talk) 20:30, 5 July 2016 (UTC)

Rather than a binary "free" property, why don't we store the license ("CC by", "CC by-sa", "PD", etc), with (short) values for "copyright exempt", "out-of-copyright" and "non-free licence, but free to read"? We could still display a limited choice of icon. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:34, 12 July 2016 (UTC)

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

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.

• - For no-strings attached free to read sources
• [alternative: /]- For free registration/first x views ?
• [alternative: ] - For paywalled/subscription only sources

This way, we can have something like (highlight the icons for tooltips)

Subscription

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

Registration

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

Limited trial

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

Free url, but no free id

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

Free id (pmc)

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

Free id (both doi and pmc)

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

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

Discussion

This seems perfect to me! Just a quick note about OAbot: given the metadata we have access to, we rarely know for sure that an identifier is closed, so the bot will only add green locks. But of course these new features can be used by editors, this discussion goes beyond the scope of OAbot. − Pintoch (talk) 20:25, 5 July 2016 (UTC)

The distinction between yellow and green is hard to make out. That could be intentional, but if so, it's a poor decision. Please use more than just color, per MOS:COLOR to make that distinction; a different shape would be beneficial. Also, it appears that yellow is doing a double duty here, and that's also quite problematic. In sum, I'd have to rely on the tooltips to make out which is free (green) vs. limited/registration (yellow), and which meaning of yellow is intended. Imzadi 1979 → 20:29, 5 July 2016 (UTC)

I agree. Maybe the meaning of the intermediate level (yellow) is actually not precise enough to be really useful. But if we find a better way to render it, it surely does not harm offer the feature. − Pintoch (talk) 20:35, 5 July 2016 (UTC)

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

Trappist has a fairly nice solution below Help_talk:Citation_Style_1#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 (talk ⋅dgaf)  14:52, 12 July 2016 (UTC)

You probably aren't the only reader who uses color-inversion so it occurred to me to make the lock color the same as one of the two colors used in the standard exteernal link icon (#06c and #06f). I settled on #07c which has 4.7:1 contrast against white and 4.5:1 against black:

—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 (talk ⋅dgaf)  21:24, 20 July 2016 (UTC)

I too prefer the coloured versions, but the issue mostly is how do you convey 'registration' and 'limited access' to people who can't easily tell colours apart? Headbomb {talk / contribs / physics / books} 15:37, 12 July 2016 (UTC)

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 (talk ⋅dgaf)  15:48, 12 July 2016 (UTC)

Done. I had just thought of that myself, and updated the mockup. Pretty happy to see that others thought of the same solution. Now I'm no graphic expert, so we can get someone from the WP:GL to put the polishing touches (e.g. make sure the dashes are all symmetrical), and then we can start focusing on the right shade of yellow. Headbomb {talk / contribs / physics / books} 16:21, 12 July 2016 (UTC)

Why are the registration/subscription notes "awful"? They are unambiguous and informative, in simple language. How is a gaggle of tiny icons that may easily be overlooked any better? And what would they even mean to the average Wikipedia reader? Who may very well ask why s/he should know one more artificial symbology in order understand something that could be easily written in plain English. 65.209.36.98 (talk) 14:58, 12 July 2016 (UTC)

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. {{cite journal}}: Unknown parameter |subscription= ignored (|url-access= suggested) (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". Journal of Stuff 1(4): 2–28. doi:10.1234/56789. PMC 123456.

It's immediately clear which of those links are openly accessible, and which of these aren't, and much, MUCH, better than

Smith, J. (2016). "The Problem with Things" (This source is freely available (help)). Journal of Stuff 1(4): 2–28. doi:10.1234/56789(subscription required (help)). PMC 123456(This source is freely available (help)).

Or whatever textual implementation one could design.Headbomb {talk / contribs / physics / books} 15:22, 12 July 2016 (UTC)

Remember WP:RF and WP:BITE. This was the IP user's first post so let's start by assuming that he is typical of the non-specialist that WP is aimed at and is trying to be helpful not agressive. Having to learn new icons just to garner a fact which can easily be written in English is a right pain for the beginner. As regards your (1): do "all citation styles" apart from wiki have any information on paywalls? If not the use of text versus icon is irrelevant. (2) Yes, but less clutter than having to have a page of icon interpretations open. (3) Agreed, so how can we clarify it without resorting to a writing style abandoned by the Ancient Egyptions? Perhaps simply noting "(some online resources require registration or a subscription)" at the end of affected citations would be enough? Martin of Sheffield (talk) 15:36, 12 July 2016 (UTC)

Hardly my first post, but I appreciate the sentiment. As for the reasoning by HEADBOMB. First it would be a good idea to stop referring to other citation systems. In their rationale, design, and use, they are inapplicable here, because they were all designed for, and by, experts. This citation system is for the benefit of non-expert, general-interest readers and should be designed from the ground up for this audience. Plain language, simplicity, and ease of use should be the design priorities here. Adding yet another layer of symbolic links while removing informative language adds complexity and reduces clarity. Secondly, I have never understood why a non-free link to a source should be included if there is also a free link (assuming equivalent reliability). I do agree that the subscription/registration note is convoluted: the link to help is unnecessary. Overall, I think too much time is given to this narrow area of the citation system anyway. 65.88.88.127 (talk) 18:39, 12 July 2016 (UTC)

It was the first post from 65.209.36.98, you're now posting from 65.88.88.127. Ever considered registering so that we know who we are talking to? Martin of Sheffield (talk) 19:45, 12 July 2016 (UTC)

You don't need to talk to me, talk to the argument. 72.43.99.146 (talk) 00:37, 13 July 2016 (UTC)

Hence why I said 'by the press' as well as 'academic' sources. These citation systems are widespread, and used by a lot more than simply 'experts'. As someone said below, most readers are familiar with symbols, and these should be reasonably clear in their meaning. If you don't know what they mean, we have tooltips. You hover once, and then you know what they mean, and then you save quite a bit of time after than not having to parse dozens if not hundreds of "(registration required)" per article, or multiple "(registration required)" per citation. Headbomb {talk / contribs / physics / books} 19:16, 12 July 2016 (UTC)

I've no idea how widespread is the knowledge of MLA, APA or any other citation system among the general Wikipedia readership. The prudent assumption would be on the side of less, not more, knowledge of citation particulars. That should be reflected in the Wikipedia citation system's presentation. Btw, I'm not making a similar argument regarding the technical aspects. The nuts and bolts could be as sophisticated as required. My experience has been that ease-of-use is proportional to design complexity: the easiest to use software is always the most complicated to design and implement. 72.43.99.146 (talk) 00:37, 13 July 2016 (UTC)

In the above examples, how is a reader to know what "1(4)" means? There is some level of abstraction required lest the citations become intractable. The relatively low bar set by icons like these are more intuitive than arbitrarily emphasized numbers, yet we have the latter and you argue against the former?   ~ Tom.Reding (talk ⋅dgaf)  18:53, 12 July 2016 (UTC)

That's an WP:OTHERSTUFF. Just because one thing sucks doesn't mean the other thing should also suck. (I have no opinion, just pointing it out--if you want to change the formatting of journal references, the "new section" button is at the top.) --Izno (talk) 19:09, 12 July 2016 (UTC)

I don't actually want to change "1(4)"; I'm using it to point out the ridiculousness of IP's argument. Also, these icons contain 'less suck' than our consensus-approved citation style, from the perspective of the "how will anyone understand anything that isn't explicitly spelled out in plain English?" argument. IP's argument is inadvertently for the icons, not against.   ~ Tom.Reding (talk ⋅dgaf)  20:40, 12 July 2016 (UTC)

That is certainly a novel interpretation. So "subscription required" is more convoluted than something that supposedly looks like a padlock, but at first glance could be anything, and maybe hardly distinguishable. Wait, it is color-coded as well, so I need to know that scheme. And there are these little curvy things (if you can see them), I'm sure they mean something? 72.43.99.146 (talk) 00:37, 13 July 2016 (UTC)

MOS:COLOUR warns - rightly - against using colour alone to convey information. For that reason, the first alternative icon on each line is better. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:41, 12 July 2016 (UTC)

Agreed that the shapes weren't right. I've updated the mockup with a yellow lock with a dashed shackle, although tweak can be made to the exact shade of yellow and dash density. Headbomb {talk / contribs / physics / books} 16:23, 12 July 2016 (UTC)

Suggest the more realistic padlock shape produced by {{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)

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

Thanks Trappist the monk for pushing the code to the live module! So, for now |arxiv=, |rfc= and |pmc= (when it is not marked as embargoed) are marked as free to read. I have not noticed any problem in the wild. I will try to implement the current mock-up in the sandbox in the coming days. − Pintoch (talk) 07:34, 1 August 2016 (UTC)

Implementation

I have implemented the mockup in the sandbox. You can try it out with Template:Tpl.

{{cite journal/new| ... | doi-access = subscription | access = free | doi = 10.1139/f92-220| url = https://www.researchgate.net/profile/James_Irvine5/publication/233865122_A_Robust_Procedure_for_Estimating_Salmon_Escapement_based_on_the_Area-Under-the-Curve_Method/links/09e4150c65bae92991000000.pdf}}

English, K. K.; Bocking, R. C.; Irvine, J. R. (1992-10-01). "A Robust Procedure for Estimating Salmon Escapement based on the Area-Under-the-Curve Method" (PDF). Canadian Journal of Fisheries and Aquatic Sciences. 49 (10): 1982–1989. doi:10.1139/f92-220. ISSN 0706-652X. {{cite journal}}: Invalid |doi-access=subscription (help); Unknown parameter |access= ignored (|access-date= suggested) (help)

For now it only covers |access= and |doi-access=, we might want to add other ones such as |hdl-access=. In the case above we replace the PDF icon with our icon, not sure whether this is a feature or a bug. What do you think? I also wanted to throw an error when |access= was provided without |url= (and similarly for |doi-access= / |doi=) but for some reason the error does not show up (any idea why?) − Pintoch (talk) 20:42, 1 August 2016 (UTC)

You must have fixed it because this shows an error:

{{cite journal/new |title=Title |journal=Journal |access=subscription}}

"Title". Journal. {{cite journal}}: Unknown parameter |access= ignored (|access-date= suggested) (help)

I tweaked the doi version because, as written, the error message code wasn't pointing to a valid error_condition table member. That fixed, this shows an error:

{{cite journal/new |title=Title |journal=Journal |doi-access=free}}

"Title". Journal. {{cite journal}}: |doi-access= requires |doi= (help)

I do not think that the rendered url-linked title should ever have the free-to-read lock. That, to me, is just so much clutter. |access= should be constrained to limited, registration, and subscription. Neither do I think that all identifiers (doi, bibcode, etc) have the subscription-require lock because that too is the norm so just more clutter. We should be identifying the exceptions with these icons: the norm for url-linked titles is free-to-read; the norm for most identifiers is subscription-required. When the title link or the identifier does not adhere to the norm, then we should say so.

Further, limited and registration should not use a yellow-ish lock color because the contrast value between that color and the background fails to meet the WCAG contrast standard. And, making a darker yellow makes it not yellow. For this reason, I favor shape over color and is why I suggested the blue locks:

—Trappist the monk (talk) 11:20, 2 August 2016 (UTC)

About the errors: that's interesting, here I do not see any error your examples (I tried logging out, changing browser, changing IP: still no error). But thanks for fixing my typo anyway.

About the free-to-read lock on the title: I thought the consensus was to keep it as it is present in the mockup. I'm not sure why we should purposely restrict which access levels are allowed for each parameter. The idea that some of them are open or closed by default is quite subjective (for instance, if I am a chemist, I will consider that |url= is closed by default). And what about |hdl= for instance? (HDL are mostly used to link to institutional repositories, where the full text might or might not be available, it's not clear what the default would be.) So I think it is fine to allow editors to use |access=free to add a free-to-read lock on |url=. (That does not necessarily imply that we want to run a bot to add |access=free at a large scale.) Actually, with your blue version of the icons, I don't think it would add much clutter as the blue lock would essentially replace the "external link" icon without being much catchier. I have included the colored ones because it seems to me that there was a consensus for them (now that the shapes are different) but of course it's easy to change. − Pintoch (talk) 12:40, 2 August 2016 (UTC)

Because you hid them. I have unhidden them so you should be able to see them. See also: Help:CS1 errors#Controlling error message display

Yeah, people like color and that is reflected in the discussion. But, people also noted that color is problematic when it comes to readers' color perception. And it is readers who matter most in this case.

Why would a chemist assume that |url= is closed by default? What is it about that occupation that leads them to believe that?

In general, identifier links do not lead to free-to-read content; |arxiv=, |pmc=, |rfc= excepted. Because the goal here, as I understand it, is to highlight for readers those links that are free-to-read, we should flag those that are and leave the rest with the default WP external link icon. If an |hdl= link is free-to-read, mark it as such else don't mark it.

In the vast majority of cases, a linked citation title does lead to a free-to-read source. When this is not the case, editors currently use |registration= and |subscription= which identify the exceptions.

—Trappist the monk (talk) 15:57, 2 August 2016 (UTC)

Thanks, I can see the errors indeed!

About chemistry, it's just that the vast majority of papers in this field are paywalled and researchers rarely upload their papers to repositories. If I read Wikipedia articles about chemistry, I will not expect to find free-to-read full texts by clicking on the title of a source. So if by chance one of them is available (and not via a parameter), it is useful to have the free-to-read lock on |url=. (Chemistry is just the extreme example, but many other fields don't do much better than that unfortunately.) If |access=free is forbidden, how should we indicate that the link is free to read? People have been using the {{open access}} template next to CS1 templates, but I think it is quite sad to resort to that while we could integrate it within CS1. − Pintoch (talk) 17:04, 2 August 2016 (UTC)

I suspect that the chemistry topic, when compared to all other topics at Wikipedia that also use cs1|2, is relatively small. I also suspect that the majority of the 2.97 million articles using cs1|2 use |url= to link the title to a free-to-read source. That is the norm. In the cases where |url= links to a paywall or registration, we have had available |registration= and |subscription= and their progenitor templates {{registration required}} and {{subscription required}}.

When title links take the reader to a paywalls or registration forms, this is not the norm. We should highlight the title link with an appropriately shaped lock icon. This is in keeping with our past use of |registration= and |subscription=.

But, you are going rise to assert that I want it both ways. I don't think that I do. We do not highlight the norm. We know that all of the named identifiers, excepting those that I mentioned in a previous post, for the most part, link to registration forms or paywalls. That is the norm and we do not highlight the norm. When there is a free-to-read source linked from an identifier, we should highlight that with the appropriately shaped lock icon.

—Trappist the monk (talk) 00:53, 3 August 2016 (UTC)

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

Let's look at the facts. I've randomly taken 100 {{cite journal}} templates with a |url= and checked if I could access the full text from the given URL. Here are the results: 59 were open, 25 were closed and 16 were broken. Note that a good proportion of the open ones are not scholarly citations (which should rather use {{cite magazine}} or {{cite news}} according to the guidelines). So free to read is the majority, yes, but not the norm. So just let the community choose! Let them add any access level on their own, they will use the lock if they find it useful. I don't see why we should assert what information editors should or shouldn't add in a futile case like this. − Pintoch (talk) 17:25, 3 August 2016 (UTC)

Are you forgetting that there are 23 other cs1 templates and {{citation}}? All of them support |url= so shouldn't you be examining the whole pie and not just a slice of it?

—Trappist the monk (talk) 22:41, 3 August 2016 (UTC)

Yes I am aware that {{cite journal}} is not the only CS1 template... (my previous message mentions {{cite magazine}} and {{cite news}}). I analyzed {{cite journal}} because I think this is where |access=free would be needed the most. I think it does not hurt to forbid |access=free for {{cite web}}, say (although I am not sure it is actually useful to do so), but surely we need it at least for {{cite journal}}. − Pintoch (talk) 06:41, 4 August 2016 (UTC)

It is best to have one rule that applies to cs1|2 globally than to have separate rules for individual templates because editors get confused when that happens. We just undid a long-standing condition with regard to parentheses and |publisher=. Consistency is important to editors who use these templates. We should not allow the application of |access= to have context-specific meaning unless the benefits gained far outweigh the troubles that come with it: code complexity and maintenance, documentation, support questions that need to be answered, ...

—Trappist the monk (talk) 10:45, 4 August 2016 (UTC)

I totally agree we should keep the code as simple as possible, and therefore… allow the same set of values for |access=, |doi-access= and others, regardless of the template, as it is currently implemented. Otherwise, as you say, we will have to answer support questions such as this one we have got a few days ago. - Pintoch (talk) 12:01, 4 August 2016 (UTC)

Do not put words into my mouth that I have not spoken. I did not say that we should keep the code as simple as possible. You wrote: it does not hurt to forbid |access=free for {{cite web}}, say (although I am not sure it is actually useful to do so), but surely we need it at least for {{cite journal}}. You expressed certainty in the one case and indifference in the other. My reply to that was in regard to different code for different templates, to wit, given the same parameters, code that causes {{cite journal}} to render differently from {{cite whatever}}, should be avoided unless it is required by style guides, MOS, or the purpose of the template, etc. The application of a little green lock to a title link is not necessary because title links almost always lead to free-to-read sources. Do not highlight the norm.

I think that the post you refer to is the sort of user support question that we want. It draws our attention (again) to the inadequacies of |registration= and |subscription=. I referred that editor to this discussion but apparently that editor has not elected to participate here.

—Trappist the monk (talk) 11:02, 5 August 2016 (UTC)

If |access=free is forbidden, how should we indicate that the link is free to read?

By not including any icon? 65.88.88.126 (talk) 18:46, 2 August 2016 (UTC)

Well, unless most paywalled |url= are marked as such, not including any icon will not indicate much. Tagging all paywalled sources with the appropriate lock is very difficult (if you know how to automate that at Wikipedia's scale, I'm very interested). So we cannot assume that once these icons will be live, the absence of an icon will mean "free to read". − Pintoch (talk) 18:58, 2 August 2016 (UTC)

I agree that a |url= source behind a registration form or paywall should be marked because that condition is not the norm. Because there isn't an automatic way to know the access status of a source, readers can never be perfectly confident that editors didn't omit |access=, that editors didn't assign it the correct value, .... No sense in worrying about it. To aid editors, we establish one simple rule: we do not highlight the norm. We reinforce that rule by deciding that |access= accepts subscription, limited, and registration. Similarly, for named identifiers, one simple rule: we do not highlight the norm and we reinforce that rule by deciding that |<id>-access= accepts free.

—Trappist the monk (talk) 00:53, 3 August 2016 (UTC)

So, in my example above, you would omit both locks? That's quite different from what we agreed on in the mockup. But if there is actually consensus for that, concretely that's good news for me, because then OAbot will not be able add any |access= or |<id>-access=, so we can go straight to the Bot Approvals Group without waiting for the new version of CS1 to be rolled out. (OAbot would only be capable of adding new |url= and the corresponding |access=free or parameters that are always free such as |arxiv= or |pmc=.) But then again, I think it is also sad to forbid |doi-access=subscription… − Pintoch (talk) 06:41, 4 August 2016 (UTC)

If you mean the example at the top of this section, then yes, I would omit both locks. I don't think that OAbot should be adding |access=free for new |url=. If |url= points to a free-to-read source, an icon is not needed.

—Trappist the monk (talk) 10:45, 4 August 2016 (UTC)

This is a circular argument. By the same token, tagging all non-paywalled sources with the appropriate lock would also be difficult. Once either of the two difficulties is surpassed, you will be able to safely assume that the other option applies. When this happens, and for the sake of simplicity, not adding the free-access icon will have the same effect. 65.88.88.126 (talk) 19:09, 2 August 2016 (UTC)

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

Parameter label

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

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

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

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

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

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

Separator added before short volume names/numbers

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 comparison

Wikitext	{{cite journal|editor-first=H.|editor-last=Garbett|journal=Journal of the Royal United Service Institution|location=London|oclc=8007941|pages=199–204|publisher=J. J. Keliher|title=Naval Notes – Italy|volume=XLII|year=1898}}
Live	Garbett, H., ed. (1898). "Naval Notes – Italy". Journal of the Royal United Service Institution. XLII. London: J. J. Keliher: 199–204. OCLC 8007941.
Sandbox	Garbett, H., ed. (1898). "Naval Notes – Italy". Journal of the Royal United Service Institution. XLII. London: J. J. Keliher: 199–204. OCLC 8007941.

Cite journal comparison

Wikitext	{{cite journal|editor-first=H.|editor-last=Garbett|journal=Journal of the Royal United Service Institution|location=London|oclc=8007941|pages=792–796|publisher=J. J. Keliher|title=Naval Notes – Italy|volume=XLIII|year=1899}}
Live	Garbett, H., ed. (1899). "Naval Notes – Italy". Journal of the Royal United Service Institution. XLIII. London: J. J. Keliher: 792–796. OCLC 8007941.
Sandbox	Garbett, H., ed. (1899). "Naval Notes – Italy". Journal of the Royal United Service Institution. XLIII. London: J. J. Keliher: 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)

As it was suggested when this "improvement" was applied, either bold all instances of volume, or none. This simple explanation was too much for some people, and apparently, it still is. 100.33.37.109 (talk) 01:43, 4 August 2016 (UTC)

But this is wrong when no publisher/location is given. The standard style for a journal to have the name of the journal immediately followed by the volume, without any punctuation. I now get a comma in CS2 and a full stop in CS1, which is just plain wrong.

• Smith, J. (2016), "Some paper", Journal of Results, 10 (3): 4–22
• Smith, J. (2016). "Some paper". Journal of Results. 10 (3): 4–22.

Peter coxhead (talk) 18:31, 3 August 2016 (UTC)

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

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)

Yes.

—Trappist the monk (talk) 09:31, 25 July 2016 (UTC)

So far, so good. It is still early, but I have seen no problems with pages I monitor. 204.19.162.34 (talk) 17:58, 31 July 2016 (UTC)

It looks like checking for incomplete access-date values was also implemented during this round of updates, as the .africa article has not changed since April, but it just appeared in the date error category. – Jonesey95 (talk) 20:34, 3 August 2016 (UTC)

That change was noticed at WT:VPT#New cite error "Check date values in date" and I couldn't find the change to point to in the list above. --Izno (talk) 16:22, 4 August 2016 (UTC)

Template:NewMusicBox

Would anyone care to make {{NewMusicBox}} a wrapper for a suitable CS1 template? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:56, 26 July 2016 (UTC)

Doesn't this question first belong on that template's talk page? Or, in lieu of that, a notice to the template's author about the conversation here?

—Trappist the monk (talk) 09:59, 28 July 2016 (UTC)

No. It needs someone with an understanding (better than mine, or I would do it) of CS1. This is the place where such people congregate. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:41, 31 July 2016 (UTC)

@Pigsonthewing: I've made {{NewMusicBox/sandbox}}, which is a wrapper for {{Cite interview}}. Note that if this sandbox version is used, someone should go through the articles using this template and change the parameter |composer=[[Composer article|Composer]] (or |composer=[[Composer]]) to |composer=Composer|composer-link=Composer article - Evad37 [talk] 06:07, 1 August 2016 (UTC)

Cite journal: "subscription=no" should show "public access" or similar?

I've suggested in Template talk:Subscription required#Public access template? that "subscription not required" should be supported both as a separate template and as a "subscription=no" parameter in {{Cite journal}}. As this topic is common to {{Subscription required}} and this one, I'd suggest that it be discussed there rather than here, to keep the discussion in one place.

While I suggest in the {{Subscription required}} Talk page that |subscription=no in {{Cite journal}} should generate text such as "(public access)", I think that as an interim measure (or permanent if my suggestion is not accepted) that |subscription=no which at present generates an error message in {{Cite journal}}, should be silently ignored.

Regarding this template specifically, I've edited Template:Citation Style documentation/registration to add "Setting |registration=no or |subscription=no is not ignored, but generates an error message." Best wishes, Pol098 (talk) 11:50, 29 July 2016 (UTC)

See this discussion.

—Trappist the monk (talk) 12:33, 29 July 2016 (UTC)

Thanks to Trappist the monk. Already (hopefully) in progress. Maybe it would be a good idea not to treat |subscription=no as an error, but (for now) to ignore it? (Just a suggestion, don't bother to reply). Pol098 (talk) (re-inventor of the wheel) 14:47, 29 July 2016 (UTC)

@Pol098:: Great to see that there's interest in the issue! But the current |registration= and |subscription= seem to be redundant with the more granular system we are implementing. I wonder whether we should think about migrating these parameters to the new |access=subscription / |access=registration / … ? It's not easy to automate this because if there are multiple outgoing links in the source, we don't know which one they apply to. − Pintoch (talk) 08:55, 2 August 2016 (UTC)

Thanks for response. A single |access= makes a lot of sense as it replaces and expands multiple mutually exclusive options covering the same aspect. I suppose |registration= and |subscription= would have to be kept as undocumented options to support existing text. But I'm no authority on this and am not aware of the tricks and traps of templates that affect thousands of articles. Best wishes, Pol098 (talk) 09:56, 2 August 2016 (UTC)

Questions about descriptions of "publisher" and about "via" parameters

Both my questions refer to text under the Help:Citation_Style_1#Work_and_publisher section.

"publisher" parameter: It says it "should not be included for mainstream newspapers or where it would be the same or mostly the same as the work/site/journal/etc." and has examples where the ""publisher" parameter should be omitted". I'm confused about the last one:

"|newspaper=USA Today and |publisher=Gannett Company"

• How does that example show that the "publisher" should be omitted?

"via" parameter: It says ..."or if(!) the deliverer requests attribution".

• What does the "(!)" mean?

Zeniff (talk) 05:15, 30 July 2016 (UTC)

Best to ask Lexein (talk · contribs), who added it nearly three years ago in this edit. --Redrose64 (talk) 09:05, 30 July 2016 (UTC)

Hello, Zeniff

You seem to have answered your own question: According to the text you quoted, |publisher= should not be included in two cases:

1. "for mainstream newspapers"
2. "where it would be the same or mostly the same as the work/site/journal/etc."

USA Today is an example of #1.

As for "(!)", the writer mean convey that he would be surprised that what is written after "if" ever comes to pass. IMHO, it is editorializing. Feel free to remove it if you wish.

Best regards,

Codename Lisa (talk) 13:27, 30 July 2016 (UTC)

Precisely, User:Lisa - you have devined my meaning ;) User:Redrose64 - I've removed it. I've only seen a content deliverer request attribution once, and that was in their initial offer of free research access to Wikipedia editors. It would be easier for editors if such deliverers would be explicit on their content pages, or next to them. --Lexein (talk) 16:55, 3 August 2016 (UTC)

@Lexein: User:Lisa ≠ User:Codename Lisa. Also, we have an admin called Liz. —Codename Lisa (talk) 07:32, 4 August 2016 (UTC)

I think that "should not be included for mainstream newspapers" is relatively new, and I'm glad to see it. I see |publisher= often being used as a synonym for |work= or its aliases, and this will put an end to that. Thank you, somebody. ―Mandruss ☎ 13:35, 30 July 2016 (UTC)

Not so new; that text was added with this edit.

—Trappist the monk (talk) 13:54, 30 July 2016 (UTC)

Yeah, my memory was fuzzy on the publisher thing. I guess a lot of the problem remains, come to think of it, given that the {{cite news}} doc still gives no guidance for what to do when the same name could be seen as either a work/website or a company-hence-publisher. This goes beyond mainstream newspapers, e.g. CNN. Unlike trivial disputes like website-vs-newspaper, this actually affects what readers see. But never mind for now. ―Mandruss ☎ 14:04, 30 July 2016 (UTC)\

via really should be removed from the templates. It's pointless clutter that serves no purpose. Headbomb {talk / contribs / physics / books} 14:53, 30 July 2016 (UTC)

That would need to be discussed with Wikipedia:The Wikipedia Library, as they seem to have promised its use to their partners (Wikipedia:The Wikipedia Library/Partners § What's in it for Publishers? and guidance for particular partners, such as Wikipedia:HighBeam). On the other hand, they also say that partnership is not "[a]n agreement to advertise the resource services beyond what is normally done for the use of any source" (Wikipedia:The Wikipedia Library/Partners § What it's not). Kanguole 16:05, 30 July 2016 (UTC)

The misuse of |publisher= is because some people don't know the difference between publication and publisher. --Redrose64 (talk) 19:56, 30 July 2016 (UTC)

Indeed, and it is a constant source of irritation that in "cite news" people keep putting the name of the newspaper or magazine under "publisher" instead of under "work" or "newspaper". When they do that, the name of the publication doesn't appear in italics, which the name of a publication always should. Is there really nothing we can do about this? -- Alarics (talk) 22:18, 30 July 2016 (UTC)

My one attempt to get a consensus that would support a doc change/clarification was met with a distinct "meh". Maybe the problem was that it was on this page rather than somewhere more public. Or maybe we just need to RfC it from here. I'm down for that—if someone else wants to do it! Just do it right, per WP:RFC. ―Mandruss ☎ 23:11, 30 July 2016 (UTC)

I attempted to resolve this issue by writing User:Codename Lisa/Websites and their publishers and linking to it in my edit summaries once in a blue moon. The result has been positive so far. —Best regards, Codename Lisa (talk) 16:52, 31 July 2016 (UTC)

|via= is a good thing, IMHO, to indicate where an online source was obtained when it's not from the original publisher. Yes, that means we credit some various republishers like those databases. Imzadi 1979 → 22:14, 30 July 2016 (UTC)

• |publisher=: Okay, then for #1, because "USA Today" is a mainstream newspaper, it does not even need the "Gannett Company" part. Is that right?
• |via=: That makes sense. I'll leave the "(!)" there. I was just confused and wasn't even sure if it was a typo or not.
• I recently used |via= in Special:Diff/732173882. I was trying to fix numerous "cite errors" which mostly were about |publisher=, and most of them used sources from one place which were re-published "via" another source. I'm not sure if I changed things correctly or not, though.. What do others think?
• Thank you all for the explanations:) I'm glad a discussion got started:) Zeniff (talk) 08:04, 31 July 2016 (UTC)

• @ZeniffMartineau: You made improvements to the Royaldutchshellplc.com article in your diff, and don't seem to have introduced any errors, but did not fix several that are present in the same cites:

• | work= | publisher=''Incentive Marketing and Sales Promotion'' Magazine |via=ShellNews.net should be |work= Incentive Marketing and Sales Promotion |via=ShellNews.net
• | publisher=Marketing Week |via=ShellNews.net should be |work=[[Marketing Week]] |via=ShellNews.net
• | publisher=''[[Sunday Business]]'' |via=ShellNews.net should be |work=[[Sunday Business]] |via=ShellNews.net
• | work= | publisher=''Marketing Magazine'' |via=ShellNews.net should be |work=Marketing Magazine |via=ShellNews.net
• | publisher=''Forecourt Trader'' Magazine |via=ShellNews.net should be |work=Forecourt Trader |via=ShellNews.net
• | work= | publisher=''Royal Dutch Shell'' |via=ShellNews.net should be |work=ShellNews.net, unless there's an actual publication named Royal Dutch Shell, in which odd case, |publisher=''Royal Dutch Shell'' |via=ShellNews.net
• | work= | publisher=''[[Financial Times]]'' |via=ShellNews.net should be |work=[[Financial Times]] |via=ShellNews.net
• | work= | publisher=''[[Reuters]]'' |via=ShellNews.net should be |agency=[[Reuters]] |via=ShellNews.net (two cases of this, and the second case need not link "Reuters")
• | work= | publisher=''[[The Wall Street Journal]]'' |via=ShellNews.net should be |work=[[The Wall Street Journal]] |via=ShellNews.net
• | work= | publisher=''[[Santa Barbara News-Press]]'' |via=ShellNews.net should be |work=[[Santa Barbara News-Press]] |via=ShellNews.net

Remember that |work= is the same as |publication= or |newspaper=, while |publisher= is a company and only added when not redundant. There are probably other errors like this in the article, since your diff only covered part of it.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:23, 1 August 2016 (UTC)

@Mandruss: Re: 'I think that "should not be included for mainstream newspapers" ... will put an end to ... |publisher= often being used as a synonym for |work= or its aliases' – I wish it would put an end to that! It has not made a dent. Some days I have to fix that error 20 or more times, without even looking for it. It's as if people can't tell the difference between The Magical Mystery Tour and Apple Records, or between Game of Thrones and HBO. @Redrose64: It boggles this mind that this publication/publisher confusion happens, but with both periodicals and (especially) websites, it happens again and again every day. I almost suspect some automated citation tool is the culprit, since I know for a fact that some of them were automating this error in the past (I fixed one of them, a now-obsolete Firefox add-on).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:42, 1 August 2016 (UTC)

Re: "the {{cite news}} doc still gives no guidance for what to do when the same name could be seen as either a work/website or a company-hence-publisher." – The solution is simple and obvious, fortunately: Instruct to always include the work/site title, first, and only add publisher afterward if it does not substantially duplicate the former (or is not considered necessary, in the case of major newspapers, something I strongly dispute, since corporate ownership of a paper frequently has bearing on its reliability, either in general, or with regard to particular topics).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:42, 1 August 2016 (UTC)

I have often wondered why it is that we don't have the module emit error messages for {{cite journal}} when the template doesn't include |journal=. That is easily accomplished and the error detection could be extended to {{cite magazine}}. It becomes a bit more difficult for {{cite new}} because the news source could be a website, a newspaper, a radio program, a television news broadcast, though these latter are problematic because, unless archived at the source's web site, they exist only in the time of the transmission and are thereafter lost and so, unverifiable. Still, it seems reasonable to me to require a |work= alias for {{cite journal}}, {{cite magazine}}, and {{cite news}}.

—Trappist the monk (talk) 15:05, 1 August 2016 (UTC)

@Trappist the monk: I strongly concur.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  15:23, 1 August 2016 (UTC)

@Headbomb: The |via= parameter is definitely not pointless clutter, and serves multiple purposes. The primary one is distinguishing between a provider of a "convenience copy" and the original publisher, needed for finding the source offline, or sometimes for identifying which quite different version is being cited/quoted. It is also useful for not falsely labelling things like YouTube as the publisher of something that was actually published elsewhere (there are also, of course, primary source videos that are literally published on such sites originally or solely, and the distinction isn't trivial). Plus the WP:LIBRARY use, which also serves reader interests, in not misidentifying something like Highbeam or JSTOR as a journal publisher.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:44, 1 August 2016 (UTC)

Re: "if(!)" – Just replace it with "if", like we would in an article.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  14:46, 1 August 2016 (UTC)

I've WP:Boldly reworded slightly, feel free to revert if inappropriate: The "publisher" parameter should not be included either for mainstream, widely-known newspapers, or where it would be the same ... Best wishes, Pol098 (talk) 10:02, 2 August 2016 (UTC)

Title punctuation suggestion

The same way that

Featherstone, Joseph L. (April 17, 1965). "'We Want Bread and Roses Too'". New Republic. 152 (16): 26–30. ISSN 0028-6583 – via EBSCOhost.

detects the single quotes in title so that it can space accordingly, I think it would be a good idea to detect whether the title ends in punctuation so that it may omit the period that follows the title's double quotes.  czar 04:06, 1 August 2016 (UTC)

A long-standing issue that is rather difficult to solve because, as the code is currently written, separators are added to citation elements in multiple places and in multiple ways. Sometimes the code adds a separator to the beginning of a citation element; sometimes it adds the separator to the end. Previous attempts to solve this problem have not been successful.

—Trappist the monk (talk) 09:23, 1 August 2016 (UTC)

A Meta discussion on the difference between via and publisher

FYI

 – pointer to relevant discussion elsewhere

A discussion at Meta, about the Citoid tool, may be of interest, and of relevance for how to better document these parameters. I'm not sure how to wikilink a Flow "Topic" like that, so the URL to it is https://www.mediawiki.org/wiki/Topic:T8bcw7u9sdu65a4y with a title of "Confusing publisher and via parameters?".  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:44, 1 August 2016 (UTC)

You wikilink it the same way as a normal link: mw:Topic:T8bcw7u9sdu65a4y. --Izno (talk) 12:48, 1 August 2016 (UTC)

Sandbox transclusions

A lot (2000-3000) of pages transclude the /sandbox's, e.g. see https://tools.wmflabs.org/templatecount/index.php?lang=en&name=Citation/CS1/sandbox&namespace=828#bottom Christian75 (talk) 04:51, 2 August 2016 (UTC)

Thanks for that. The problem was caused by a cut and paste error I made when I updated {{cite arxiv}}. That has been remedied so the number of transclusions should decline as the pages work their way through the job queue.

—Trappist the monk (talk) 10:06, 2 August 2016 (UTC)

New access-date check leads to bad bot proposal

I understand that the date validation code now produces an error message if the access date is not precise to the day:

• {{cite journal | title = Three-body problem, the measure of oscillating types. A short review | url = http://journals.cambridge.org/action/displayIssue?jid=IAU&volumeId=9&issueId=S310 | access-date = August 4, 2016 | last1 = Marchal | first1 = Christian | journal = Proceedings of the International Astronomical Union | date = July 2014 | pages = 43–44 | volume = 9 | issue = S310}}

  Marchal, Christian (July 2014). "Three-body problem, the measure of oscillating types. A short review". Proceedings of the International Astronomical Union. 9 (S310): 43–44. Retrieved August 4, 2016.

• {{cite journal | title = Three-body problem, the measure of oscillating types. A short review | url = http://journals.cambridge.org/action/displayIssue?jid=IAU&volumeId=9&issueId=S310 | access-date = August 2016 | last1 = Marchal | first1 = Christian | journal = Proceedings of the International Astronomical Union | date = July 2014 | pages = 43–44 | volume = 9 | issue = S310}}

  Marchal, Christian (July 2014). "Three-body problem, the measure of oscillating types. A short review". Proceedings of the International Astronomical Union. 9 (S310): 43–44. Retrieved August 2016. {{cite journal}}: Check date values in: |access-date= (help)

The unfortunate response to these error messages is a proposal to falsify all the old imprecise access dates by using a bot to falsely assert the access occurred on the first of the month: Wikipedia:Bot requests#Fix thousands of citation errors in accessdate

Of course, the only ways to "correct" an old access date is to have the editor who accessed the source to provide the day of the month the access occurred, or to revisit the source and provide the date of the revisit (provided, of course, the source in its current form still supports the claim(s) in the article. Jc3s5h (talk) 16:31, 4 August 2016 (UTC)

Or remove the access date for articles with DOI or other identifiers, per the {{cite journal}} documentation. – Jonesey95 (talk) 18:29, 4 August 2016 (UTC)

Or have the bot access the url in the citation and if error=0 input the date of the bot access. If any webpage-related http errors appear (404 etc.) remove |access-date= altogether. Then, in phase 2, the bot could check to see whether in pages that it successfully accessed, the content actually verifies the respective citations. That 1. could keep bot writers busy for a few years/decades, and therefore, 2. keep CS1 relatively unsullied. 65.88.88.127 (talk) 21:15, 4 August 2016 (UTC)

Use the date the URL was added to the article which the BOT could extract from the history. Keith D (talk) 00:21, 5 August 2016 (UTC)

That may or may not be the date the source was accessed. Revision date does not automatically imply access date. Also, inputting a prior (or forward) date violates WP:SAYWHEREYOUGOTIT. Only the editor who accesses the source can make such corrections after the fact. 72.43.99.146 (talk) 00:37, 5 August 2016 (UTC)

One solution would be to only output the error warning if the MM YYYY date is Sept 2016 or later (or a year of 2017 or later) - thereby catching (mostly) new instances, but not historic ones. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:30, 6 August 2016 (UTC)

Why should past instances be ignored? They are still wrong. Not flagging such obvious incogruities diminishes confidence in the encyclopedia. 64.134.101.16 (talk) 19:25, 6 August 2016 (UTC)

Firstly, they are not wrong, although they may be imprecise. And they should not generate an error for that reason, and for the reasons stated above, in this section. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:51, 11 August 2016 (UTC)

Since we are discussing the date when an anonymous editor claims to have verified the particulars of a citation by accessing it, not entering the exact, full date this happened is a bit more than imprecise, or careless, or just not following the correct procedure. Entering such exact information is as easy as not entering it. Therefore, other questions now arise. Afaic, something is wrong with such a citation and it should be flagged. 65.88.88.127 (talk) 19:43, 11 August 2016 (UTC)

Partial access dates

CS1 is generating an error if |accessdate= is partial. For example these generate an error:

|accessdate=2015

|accessdate=May 2015

This is good:

|accessdate=May 1, 2015

The number of articles impacted is 14665 in 32255 citations. The error is a new feature added recently from Help_talk:Citation_Style_1/Archive_19#incomplete_access_dates. This led to a proposal for a bot fix: Wikipedia:Bot_requests#Fix_thousands_of_citation_errors_in_accessdate .. However the Oppose camp do not believe an access-date with two parameters (Month Year) should generated a CS1 error. There is no way to fix 32255 citations without a bot, and no way to do a bot without consensus for the error message.

1. Should CS1 generate an error in accessdate's with only a year |accessdate=2015 ?
2. Should CS1 generate an error in accessdate's with only a month year |accessdate=May 2015 ?

Pinging previously involved parties: @Trappist the monk, 72.43.99.138, Matthiaspaul, 65.88.88.62, Rfassbind, Jonesey95, Jc3s5h, Cyberpower678, Redrose64, Magioladitis, PBS, Tom.Reding, BabbaQ, and Finnusertop:

Note: this is not an RfC please consider discussion rather than vote-style. If we need an RfC it will become evident and we can announce to the community a separate RfC here or Village pump. -- GreenC 16:56, 30 August 2016 (UTC)

It should. Having accessed an article in August 2015 doesn't help you if the page got updated on August 17th of that year. You the day needs to be specified for that reason, as recommended by every style guide out there. Bots can retrieve the date a link got added (with some fancy logic to rule out corner cases) to take care of most of those. Headbomb {talk / contribs / physics / books} 17:10, 30 August 2016 (UTC)

The templates should not generate error messages if the access date is earlier than the date the "feature" was added to the templates. Jc3s5h (talk) 17:30, 30 August 2016 (UTC)

Free-to-read icon

In Module:Citation/CS1/Configuration/sandbox:135, I vertically aligned the green lock icon that appears after PMC identifiers () and added an entry to {{cite journal/testcases}}. The change is minor and straightforward, but given the propagation of the change, I’m checking in here first. Thank you. —LLarson (said & done) 18:42, 5 August 2016 (UTC)

I'm going to undo that part of your change. We did this comparison earlier at Help talk:Citation Style 1#adding free-to-read icons (I've modified that test here to use the same image as is used in the Module:

qK

and here's another:

[]

and with your change:

qK

[]

—Trappist the monk (talk) 19:08, 5 August 2016 (UTC)

Thanks as always, Trappist! What about this though?

Current:

qK

[]

Proposed:

qK

[]

—LLarson (said & done) 19:22, 5 August 2016 (UTC)

Looks to me like the {{open access}} lock is too high. It should be lowered so that it more-or-less spans the distance between the lowest descender and the highest ascender.

—Trappist the monk (talk) 20:36, 5 August 2016 (UTC)

I also find it more natural to have the main circle at the same height as a "o" letter (so, LLarson's proposal) − Pintoch (talk) 20:50, 5 August 2016 (UTC)

I'm on Team LLarson for height. Headbomb {talk / contribs / physics / books} 20:22, 9 August 2016 (UTC)

Quick question, but what is the difference in the meaning of the green "free to read" icon () and the orange "open access" icon ()? --bender235 (talk) 16:46, 24 August 2016 (UTC)

As I understand it, the orange icon is meant to identify sources that are free to reuse. The green only indicates that the source may be read without cost to the reader. Reuse rights are determined by agreement between the publisher and the author(s).

—Trappist the monk (talk) 16:51, 24 August 2016 (UTC)

Hmm, well if so, then the "open access" icon suggested for Newspapers.com citations is wrong, isn't it? --bender235 (talk) 17:50, 24 August 2016 (UTC)

I think you're right, that use of the orange icon there is inappropriate. I don't think that newspaper.com urls in a cs1|2 template need either of these icons because the norm for urls that link title-holding parameters in cs1|2 templates is that the linked source can be read without the reader jumping through registration or paywall hoops.

—Trappist the monk (talk) 19:00, 24 August 2016 (UTC)

Citation data via Wikidata

Has anyone started work on a citation template which pulls data from a Wikidata item? It might look something like:

{{Cite Q|Q1234}}

and would pull title, journal, author, etc, from the given Wikidata item.

Alternatively, we could add a |Wikidata= parameter to existing citation templates, so that they would pull in fields unless the value was supplied locally.

If not, I'll knock up a demo. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:26, 6 August 2016 (UTC)

This appears of no benefit. Something like what you are proposing would be completely opaque to editors, and if you have enough information to actually define a reference such that it could be found in a database (and wikidata is not in anyway shape or form a reliable source), then you might as well manually enter it into the appropriate template or a manual reference. No-one should be using references that they havn't seen anyway.Nigel Ish (talk) 19:43, 6 August 2016 (UTC)

No one has claimed that Wikidata is a "reliable source", and Wikidata won't be used as a citation. Please avoid such FUD. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:03, 6 August 2016 (UTC)

If Wikidata won't be used as a citation, why do you need a citation template which pulls data from a Wikidata item? Please explain. What you are proposing is using Wikidata as a citation where for example Q1234 is the citation stored in Wikidata and {{Cite Q|Q1234}} would presumably produce a formatted citation. This is not FUD, but a reasonable interpretation of what you have stated. Boghog (talk) 13:07, 7 August 2016 (UTC)

There is a difference between storing citation metadata on Wikidata and citing Wikidata as a source. This section is about the former. The metadata (title, authors, etc) would be the properties of a particular Wikidata item instead of being specified in the citation template. − Pintoch (talk) 14:10, 7 August 2016 (UTC)

Storing citation metadata is fine. Having a human inspect and call the data and permanently place it in an article is fine. Having a dynamic citation that can change over time is not fine. Citations need to stay the way they were when they were used. Under this system, an editor would have to go and look at the citation on Wikidata to make sure it is OK, then come back here and use it. That takes longer than just using it here. The only advantage of templated or remotely called citations is where you have a lot to use in many articles (a form of automation). Even then, it needs to be substituted each time, otherwise when you change the template, you change many citations without inspecting each one individually. Each citation needs to have been inspected. You cannot make the process easier. It is difficult for a reason, because it needs to be correct. Carcharoth (talk) 14:20, 7 August 2016 (UTC)

I am very worried about the use of wikidata like this. Take this edit as an example. The value of '142000' that refers to that memorial in the database we are linking to has been removed from the article and is now being called from Wikidata. That is really difficult for most editors to understand. What is the benefit of that? Before, people knew to use a template and add a parameter. Now they have to look up whether wikidata has the parameter, and then use the template? That is more difficult for people to understand (I get it makes the data manipulation easier across multiple wikis, but it leaves editors confused and that is bad). Carcharoth (talk) 21:29, 6 August 2016 (UTC)

A point of information: This proposal is similar to, but more opaque than, the {{cite doi}} templates, all of which were proposed for deletion and substituted because the consensus view was that citation information should be placed in articles. – Jonesey95 (talk) 02:48, 7 August 2016 (UTC)

You mean this discussion? Thank you for pointing that out. Was there not some discussion somewhere of where and how it was acceptable to use wikidata? Have I missed something about how it can be used at present? As I've said on Andy's user talk page, I would have no problem with this if when an editor clicks "edit", the data being called from Wikidata shows up in the edit window. At the moment, there is nothing there at all, just a mysterious emptiness, a black box whirring away. Opaque doesn't even begin to describe it. Another example of 'use wikidata' is here. There is more here, here and here and here. There is also Category:Wikidata templates. At the moment, what seems to be happening is that whole swathes of what I would call 'database maintenance' in the form of carefully incorporating database material and links in Wikipedia (whether that be citations or anything else that can be put in a database), are being transferred over to Wikidata, and editors who carefully maintain the articles here are being forced to work elsewhere, which increases the complexity of the workflow. That works for Commons and images, but when you have atomised data, it introduces complexity rather than removing it. Carcharoth (talk) 08:29, 7 August 2016 (UTC)

@Carcharoth: I believe you're looking for Wikipedia:Requests_for_comment/Wikidata_Phase_2? Nikkimaria (talk) 13:01, 7 August 2016 (UTC)

I remember that (vaguely). Have things changed in three years? I am still at a complete loss as to how an edit removing a local value with the edit summary "use wikidata" is helpful. I get that there are other edits being done elsewhere that ensure no functionality is lost, but unlike "go to this template and edit it", which is understandable, how does "go to Wikidata and try and work out how things work there" actually understandable? I can now see that some obscure link in the sidebar called "wikidata item" takes you here, and that the value is being called from there. But how do you associate an article with a wikidata item? I opened the edit window for Chatham Naval Memorial and searched for "wikidata", but nothing. Was it the initial creation of the page over on wikidata (this edit) that caused the "wikidata item" link to appear on the sidebar? If so, that is crazy. There should be a way to alert the editors of an article that a Wikidata item has been associated with it. Is that possible? I suppose not. It is just like if an article has templates, someone can merrily edit away on that template and those pages where the template is transcluded don't get 'told' that this editing is going on (unless that got fixed recently?). <sigh> Carcharoth (talk) 14:07, 7 August 2016 (UTC)

Other issues aside, how is Wikidata performance these days? Before adopting this into CS1, I'd like to see a mockup study of the performance impact. Citation templates can run hundreds of times on a single page, and I'd want to make sure that using 100s of wikidata citation calls would not appreciably impact the user experience. Dragons flight (talk) 18:05, 7 August 2016 (UTC)

cite arxiv vauthors support

* {{Cite arXiv |vauthors=Vo P, Nunez M |year=2010 |title=Bdellovibrio bacteriovorus Predation in Dual-Species Biofilms of E. coli Prey and M. luteus Decoys |class= q-bio.PE|eprint=1005.3582}}

yields

• Vo P, Nunez M (2010). "Bdellovibrio bacteriovorus Predation in Dual-Species Biofilms of E. coli Prey and M. luteus Decoys". arXiv:1005.3582 [q-bio.PE].

It should recognize |vauthors=. Headbomb {talk / contribs / physics / books} 23:48, 7 August 2016 (UTC)

@Headbomb: it appears to support it to me. I see a list of authors in the output that corresponds to the |vauthors=. Is there another way it should be recognizing it that it isn't? Imzadi 1979 → 01:08, 8 August 2016 (UTC)

That's because Trappist the Monk (talk · contribs) has just fixed it. Thanks. Headbomb {talk / contribs / physics / books} 07:28, 8 August 2016 (UTC)

New parameters to suppress maintenance false positives.

Add parameters single-author/single-editor/single-translator which Module:Citation/CS1 name_has_mult_names should check for before adding the page to Category:CS1 maint: Multiple names: authors list/Category:CS1 maint: Multiple names: editors list/Category:CS1 maint: Multiple names: translators list‎. This will allow editors to suppress false positives where a single author has a name which the module thinks looks like multiple authors. See Category talk:CS1 maint: Multiple names: authors list#And jnestorius^(talk) 11:04, 10 August 2016 (UTC)

Instead of basing it on working around a bug, perhaps it would be better to add finer-grained semantics. How about a new parameter like |corporate-author= to contain the name of a corporate author (regardless of how it is punctuated) and similarly for editors and translators? Kanguole 11:25, 10 August 2016 (UTC)

This is sound reasoning, but I'd like to point out that there are already free-form parameters for that (|authors=, |editors=, |others=, and aliases such as people). 72.43.99.146 (talk) 13:51, 10 August 2016 (UTC)

How does using |authors= instead of |author= match the semantics of a single (corporate) author? And use of that param is deprecated. jnestorius^(talk) 14:44, 10 August 2016 (UTC)

|authors= is not deprecated. Nothing suggests to me that it must be used for multiple authors. It can be used for any author because it is a free-form field. That single author may or may not have multiple names, or/and roles indicated. 72.43.99.146 (talk) 14:55, 10 August 2016 (UTC)

For example, cf. use of |others=, another non-deprecated free-form parameter that may include a singular name. 72.43.99.146 (talk) 14:57, 10 August 2016 (UTC)

My mistake, it is "discouraged" rather than "deprecated". See Category:CS1 maint: Uses authors parameter. It doesn't seem optimal to remove one spurious maintenance category by adding another. jnestorius^(talk) 15:25, 10 August 2016 (UTC)

One can't be sure |corporate-author= will handle all cases; what if the author is "John, Marquess of Foo, Bar, and Baz"? The fact is that any automated parsing of natural language is imperfect and will throw up errors; in this case, adding inappropriate maintenance categories. The most general solution would be a single |suppress-maintenance-category= param with comma-separated values, e.g. suppress-maintenance-category=mult_names_auth,mult_names_trans. jnestorius^(talk) 14:44, 10 August 2016 (UTC)

Is it that you just don't like the little green text in your citations? We know that there is an issue with |authors= (plural). The size and scope of that issue was unknown until we added Category:CS1 maint: Uses authors parameter which hardly makes it spurious.

Adopting Editor Kanguole's suggestion, I think, may address the issues that you've raised here, yet you seem opposed that that kind of a solution. Care to elaborate on your opposition with examples of why it will not work?

—Trappist the monk (talk) 00:50, 11 August 2016 (UTC)

Of course the maintenance category is spurious. It does not concern the validity of either the affected template or the citation. It tracks individual preferences of style and presupposes that metadata is more important than data. And the solution to this non-existent problem is even more complexity? Not to mention the additional documentation. This is going to be fun. 64.134.96.40 (talk) 01:35, 11 August 2016 (UTC)

No, it suggests that metadata, in addition to data, is important. We have data whether we use |authors=, |authorn=, or |lastn=/|firstn=. But from the point of view of "let us extract everything of value that we can from the template", only one of those provides the most value. If you're concerned regarding clutter, that's something you're going to get regardless of which citation style (hand-jammed or template) you use--the only way to remove such is to be using a WYSIWYG editor (yes, that's the only way). The view that changing the particular parameters in a particular template citation is a change in style was quite firmly rejected per the closure of this recent RFC. --Izno (talk) 11:58, 11 August 2016 (UTC)

(edit conflict) For those who consume cs1|2 metadata renderings, missing or malformed information is just as much a problem as it is for those who consume cs1|2 visual renderings. The two renderings are of equal importance. The data in |authors= (plural) are not included in the metadata because there is no rft.authors keyword in the metadata standard. All information in |authors= (or any of its aliases) is missing from the metadata rendering of a template and that does concern the validity of the template and the citation.

—Trappist the monk (talk) 12:06, 11 August 2016 (UTC)

So by all means fix the metadata, and stop trying to limit the choices or trying to enforce a discrete-author style on the creators of the data. Because obviously metadata is not as important as data: only one of these two depends on the other. 65.88.88.127 (talk) 19:53, 11 August 2016 (UTC)

I guess you did not read, or did read and have elected to ignore, the part of my post where I wrote: there is no rft.authors keyword in the metadata standard. So let me elaborate. The standard does not support the concept of multiple author-names in a single key/value pair. It supports multiple authors by allowing an unlimited number of rft.au key/value pairs (one author-name (the value) per key). Because it is a standard established and maintained outside of Wikipedia, we cannot 'fix it'. But, we can adapt to it by perhaps adopting Editor Kanguole's |corporate-author= suggestion.

If we revert to the dictionary definition of 'metadata', then its colloquial use here is only vaguely correct. cs1|2 templates produce two renderings: the visual rendering that can be seen at the bottom of a great many Wikipedia articles; and the so-called metadata rendering that is not visible but is consumed by Wikipedia users through various digital tools. There is no pure 'data describing data' output from the cs1|2 templates. Both renderings contain as much of the original data as can be supported by the standards to which they are rendered. Complete and correct renderings are equally important to the respective users.

—Trappist the monk (talk) 00:46, 12 August 2016 (UTC)

I believe editor Kanguole was suggesting |corporate-author= as a free-form parameter, though one that is unnecessarily narrow (why limit it to "corporate"?). And yes, it seems that the code may be trying to do too many things, not all of them well. 72.43.99.146 (talk) 15:06, 10 August 2016 (UTC)

Are there such things as corporate editors? Corporate translators? I rather like the |corporate-author= parameter. Because it identifies its content, editors know what it's for and the module will know to ignore commas. We can enumerate them: |corporate-authorn=.

What to do when this parameter is mixed in a template with |authorn=? Do we decide that corporate authors are rendered at the end of the author name-list? Or, do we list author names and corporate-author names in a single list where the enumerator decides where each name goes in the list? (this is the much more difficult of these possible options because |corporate-authorn= is not an alias of |last=). Unlike |authors= (plural), |corporate-author= can be made part of the citation's metadata because it holds one corporate name.

—Trappist the monk (talk) 00:50, 11 August 2016 (UTC)

I would prefer the latter, personally. I suspect most will have a similar preference, since people will be likely to want to retain the order of the authorship in the source being cited. --Izno (talk) 11:58, 11 August 2016 (UTC)

@Trappist the monk:: anwering some of your points from 00:50, 11 August 2016

• I should not have implied that Category:CS1 maint: Uses authors parameter is "spurious". What I meant was "It doesn't seem optimal to remove a [spurious] maintenance category by adding another [non-spurious] maintenance category, rather than fixing the format so that there are no maintenance categories".
• "you seem opposed that that kind of a solution. Care to elaborate on your opposition with examples of why it will not work" -- I am not opposed to adding |corporate-author= but I am sceptical that it will address all problems. I already gave one example ("John, Marquess of Foo, Bar, and Baz"). I have no idea how common such cases will be. I think it's usually worth having an override option to handle any unforeseen errors; but if the processing cost is high and the errors are rare it may not be.
• As regards corporate-author
  1. |corporate-author= needs to be |corporate-authorn= for the multiple case
  2. we might replace |corporate-authorn=Smith, Jones, and Foo with |authorn=Smith, Jones, and Foo |corporate-authorn=Y -- this allows interleaving of corporate and non-corporate authors and might be easier to code

jnestorius^(talk) 11:35, 12 August 2016 (UTC)

In the discussion that caused the creation of Category:CS1 maint: Multiple names: authors list‎, I suggested that the accept-this-as-it-is-written mechanism used in |vauthors=, the parameter value wrapped in doubled parentheses, could be applied to |author= to suppress categorization. So your contrived example would be written: |authorn=((John, Marquess of Foo, Bar, and Baz)). That idea was dismissed but I raise it again as a solution to the false positive problem that does not require the introduction of new parameters and their attendant code an documentation.

—Trappist the monk (talk) 10:38, 13 August 2016 (UTC)

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

I am continuing the discussion here, although it is more pertinent to Trappist's comments above.

Limitations in software should not dictate the behavior of human editors. The onus of change is on the software, especially when it is not vital. The rendering of metadata is a convenience, that happens to be entirely supefluous: the target audience of Wikipedia can always, directly and freely, access this site without going through middleware. Neither is this site difficult to use: so rendering the information in a different interface (the main objective of middleware) has no practical significance.

Wikipedia exists to provide verifiable, reliable content. The existence of such content trumps questions of style or automation, including the transmission of COinS biblio metadata. Contributors should be made as comfortable as humanly possible in providing such content. Limiting their options because a digital tool (that has no meaning without contributions) is not up to the task is the wrong way to go about it. From that principle, you can drill down to the current discussion: the maintenance category in question is a waste of time. It increasingly seems that application of COinS in Wikipedia is heading in that direction too. It is even more egregious when it results in increased complexity, as the so-called "solutions" offered here. Especially when there are other, more significant and pressing problems. 72.43.99.138 (talk) 13:01, 12 August 2016 (UTC)

It seems your concerns are broader and deeper and that this is too specific a discussion to raise them. I hardly think a category that is invisible to most editors and all non-logged-in readers worsens their user experience. Content can be added via |authors= and viewed by readers, as you would wish; readers and editors need not worry or even know about the concomitant CS1 issues if they don't want to. If someone patrolling the maintenance category comes along and modifies the format to make it CS1 compliant, there is no loss to those who don't care about metadata. This discussion is about facilitating the work of such patrollers; I agree that solutions which make life harder for CS1-disdainers should be avoided, but I don't think that makes the whole issue pointless. jnestorius^(talk) 15:03, 12 August 2016 (UTC)

Things don't happen in a vacuum; we are having this discussion because "authors" does not render metadata and because some people would prefer another style for cases it would be used. These gave rise to this category. The category's flags prompted your OP. And the proposal is devolving into even more complexity and minutiae. So there we are. 24.193.13.32 (talk) 23:07, 12 August 2016 (UTC)

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

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

Most commonly used parameters

In Template:Cite_web#Usage, the sample with the most commonly used parameters, which I guess, I am not the only to paste regularly for use, should include the following parameters:

| archive-url =
| archive-date =
| dead-url =

The reason is to lure more editors to archive links or get archived links to resist link rot. Ever more I find dead links and source has already disappeared from the web. --Robertiki (talk) 18:04, 12 August 2016 (UTC)

The documentation for 'cite av media' needs to be improved...

I assume {{Cite AV media}} is supposed to be used for YouTube video references? Yet the documentation doesn't contain one "YouTube example". It would certainly help if such an example could be added to the documentation. Just sayin'... --IJBall (contribs • talk) 03:20, 17 August 2016 (UTC)

Hello, IJBall

Your assumption is wrong. YouTube is not a reliable source in Wikipedia and must never be used. (It can be used as a medium though, as opposed to a source, e.g. you link to a reliable source that has an embedded video.)

{{Cite AV media}} is used for film and audio recordings, e.g. a conference available for sale on a tape, CD, DVD, Blu-Ray and online streaming.

Best regards,

Codename Lisa (talk) 08:58, 17 August 2016 (UTC)

@IJBall: my opinion is a bit more nuanced than Codename Lisa's. If the appropriate entity uploads a video to YouTube, without violating copyright, and the video otherwise meets our requirements regarding reliable sources and self-published sources, then in that case the video is acceptable as a source. However, in this case, YouTube is not the publisher, but it's acting as a republisher of sorts. In that case, you'd cite the video as if YouTube had nothing to do with the video, crediting the original creators and publisher. Then you could add the appropriate |url= with |access-date= and append |via=YouTube to note where it was republished.

However, since most content on YouTube is self-published, it can't be used without complying with the exceptions noted at WP:SPS. Imzadi 1979 → 09:37, 17 August 2016 (UTC)

Looks to me we are actually on the same page. Just different opinions of how to word our approach... —Best regards, Codename Lisa (talk) 09:44, 17 August 2016 (UTC)

I actually knew all that. And, yes, I'm thinking of something like this which is simply a promo released directly from Nickelodeon on YouTube. Movie trailers direct from movie studios would be another example. In any case, this comes up a lot, and a "YouTube" example should be added to the {{Cite AV media}} documentation so that your garden variety editor knows how to properly cite YouTube, including the |via=YouTube parameter. --IJBall (contribs • talk) 15:01, 17 August 2016 (UTC)

Wadewitz memorial proposal

Recently a discussion at Talk:Jane Austen has revolved around the linchpin issue of template formatting. The original version of the article from 10 years had initially been started in MLA Handbook format (without templates, see below) by the late Wadewitz, and it was clearly her strong desire (as evidenced by her comment in the references section) that that MLA format be retained. However, a regrettable situation arose: since Wadewitz passed away, 5-6 editors have edited the article in different cite formats (or even "freestyle format", perhaps). Manual editing resulted in a massively inconsistent references section that I described as a "steaming mess of wrongness".

I strongly support the use of reference templates to create consistency in formatting within any given article, and to provide the many benefits of COinS.

However, neither of these advantages is available to any editors who wish to edit in MLA (or APA, or Chicago/Turabian, or Bluebook) as expressly supported under WP:CITEVAR.

WP:CITEVAR does not by extension mean that such template options must be created, but I suggest that the proper way to show courtesy and respect to all editors working within those extremely common (outside of Wikipedia) formats would be to create them. The reason these formats are rare in Wikipedia is precisely because template options for them are completely unavailable. If these template options had existed before, the "steaming mess of wrongness" at Jane Austen would never have come to be.

If possible, I propose (perhaps using |mode=) the creation of |style-guide=mla, |style-guide=apa, |style-guide=chicago and |style-guide=bluebook as alternate parameters that reformat displayed template text.   Lingzhi ♦ (talk) 09:33, 23 August 2016 (UTC)

The reason why MLA style is not suited to use in Wikipedia has been explained at length, by user:RexxS, in the discussion at Talk:Jane Austen; not least - in great detail - in Talk:Jane_Austen#MLA. Attempting to bypass that discussion here, and framing it in such a way as to imply that anyone opposing your proposal is both disrespecting other editors and disrespecting the memory of a much missed former colleague, is facile, and in the latter case is an abuse of her memory. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:44, 23 August 2016 (UTC)

@Lingzhi: Rather than wade through that lengthy talk page, I'd rather refer anyone to the essay presently at User:RexxS/NoCiteBar, where I've tried to collect my thoughts and explore the issues related to MLA-type and similar referencing schemes. That does rather damn MLA-type short cites as inadequate for our needs. If it's any consolation, I have been in the process of working through Module:Citation/CS1, with a view to creating a version that allowed a parameter to act as a switch for the displayed output. That, of course, would only affect the long citations, and would do nothing to fix the fundamental problems with MLA-type short citations. When I can get an uninterrupted stretch of time to do some programming (hint, hint), I'd hope to have something sandboxed that might go some way to meeting your request. Any pointers to definitive on-line references for the different styles, MLA, APA, Chicago, etc. would be appreciated. --RexxS (talk) 12:05, 23 August 2016 (UTC)

I think that having an MLA style option for the CS1 {{cite xxx}} templates is a good idea. It would allow editors to make use of the error checking that is available in CS1 templates but still format full citations in their discipline's preferred format. (As Andy says above, MLA style, e.g. "Smith, 101", is unsuitable for Wikipedia, where anyone can edit an article and easily introduce ambiguity. We would have to adopt a modified MLA style for short footnotes, e.g. "Smith 2005a, 101", linked to the full citation.) – Jonesey95 (talk) 13:23, 23 August 2016 (UTC)

I think a |mod=MLA wouldn't be a bad idea for full citations, but the existing {{harvnb}} templates should be be used for any short even though MLA itself doesn't call for the inclusion of the year there. Other mode options could be added in the future for other styles. Imzadi 1979 → 20:02, 23 August 2016 (UTC)

• We need short form MLA templates (and APA, and Chicago, and...) similar to sfn etc. Why oh why oh why do I have to come here and beg? Why do I have to kiss the ring of a small group of editors? Give me permission to edit templates, show me how you've implemented things in the years since I last edited a template, and I'll do it. This is nothing but flat WP:OWNership, and that's a fact.  Lingzhi ♦ (talk) 04:19, 24 August 2016 (UTC)

  A good way to get me to abandon this mla project is for you to continue to make unsupported accusations of WP:OWNership and the like:

  • Cite Book is a wikipedia-only standard that is in practice shoved down everyone's throats because the template maintainers flatly refuse to make MLA and APA templates. (you wrote that here)
  • I DO think that the template maintainers of cite book are massively remiss for flatly refusing to produce MLA, APA and Chicago flavors of cite book; they have an untouchable cast-iron WP:OWN on the issue, in flagrant violation of policy at WP:OWN. (you wrote that here)

  Show me where template maintainers or the maintainers of {{cite book}} have refused to make MLA and APA templates.

  —Trappist the monk (talk) 12:18, 24 August 2016 (UTC)

  @Trappist the monk: I admit to having become consistently embittered against those who maintain templates... I've been around Wikipedia off and on (with a nearly three year "off" period) for ten years. I have come to various template-related forums asking for various things, and have always been shown the door... even when I asked nicely (I ceased being so nice after a while). I don't recall when I asked last (either as User:Ling.Nut or User:Ling.Nut3) for these particular APA/MLA/Chicago template alterations, or what specific template-related forum I asked on, but I do recall asking for them, and I do recall being treated like an intruding idiot, to put it nicely. So my attitude is embittered, but it is a response to past arrogance. I do not recall the usernames of all of those who were rude in the past, but I am quite certain that you were not one of them. I do recall one user (still quite active) who treated me rudely in the dim past, but I will not repeat that username in this particular moment. So. Is this a non-apology apology? I'm not sure. But it is perhaps true that nicer people are around now than I have dealt with in the past, and if I have unfairly tossed you and others here into the bucket with the relatively unreasonable ones, then I do apologize for that. But having said that, I still feel bitter. So it's a bit of a dilemma. :/  Lingzhi ♦ (talk) 14:51, 24 August 2016 (UTC)

  Perhaps you are mis-remembering. I can find no discussions on template-related talk pages (the Template:, Module:, and Help: namespaces) where any of User:Lingzhi, User:Ling.Nut, or User:Ling.Nut3 asked for templates to write references in a style other than cs1|2. I did not look at user talk pages because those are not generally public venues and did not look into article or other namespace talk pages because those are clearly not template-related fora so perhaps you asked in one of those places. I am interested in knowing the reasons that were given when requests for alternate styles were denied.

  —Trappist the monk (talk) 16:14, 24 August 2016 (UTC)

(←) I also spent 10 or 15 minutes looking for that incident and have not found it yet either. I will continue looking. Meanwhile, I am in the present case obviously in the wrong, though (in my opinion) somewhat humanly so. But still in the wrong.  Lingzhi ♦ (talk) 02:35, 25 August 2016 (UTC)

• You don't need any special permission to create a new template or to edit a template's sandbox code. Go for it! And all template code is available via the Edit or View Source links at the top of the page. You might start at Module:Footnotes. – Jonesey95 (talk) 05:17, 24 August 2016 (UTC)

  @Lingzhi: Let's assume that you have a ref like <ref>Smith, 101</ref> and you want that linking to a long-form cite template. There are two things to do here, and neither of them is restricted by the edit protection on the templates.

  The first thing to do is to make a link inside that ref, this could be as simple as <ref>[[#Smith|Smith]], 101</ref> but as there may be a section in the article titled "Smith" it's a good idea to add something distinguishing, such as the letters "ref" - so you might use <ref>[[#refSmith|Smith]], 101</ref>.

  The second thing to do is to create an anchor on the long-form citation template, this might be {{citation}}, {{cite book}} or one of the others. Use the |ref= parameter for that, i.e. |ref=refSmith.

  You can see it in action at Wikipedia:Sandbox. You could make a template for the [[#refSmith|Smith]] part, but it's not essential. --Redrose64 (talk) 10:12, 24 August 2016 (UTC)

  @Lingzhi: Further to the above: I've found that you can in fact do it using existing templates, see Wikipedia:Sandbox. Here, we have <ref>{{harvnb|Smith|loc=101}}</ref> in the text, and |ref={{harvid|Smith}} in the cite template. The two templates used here are {{harvnb}} and {{harvid}}; notice that I didn't use the year parameter on either one, and with {{harvnb}} I used |loc= instead of |p= in order to suppress the "p." that would otherwise have been included. --Redrose64 (talk) 11:29, 24 August 2016 (UTC)

  @Redrose64: I think the short MLA can be finessed using existing |loc= in sfn, plus text for the year (since sfn treats everything as a string), plus and ref={{harvid}} except for the hard-coded comma in Module:Footnotes (in the args.location). See the very first cite in my sandbox for a fake example.  Lingzhi ♦ (talk) 12:15, 24 August 2016 (UTC)

For a long time I have wanted to restructure the code that assembles the miscellaneous constituent parts into a recognizable whole. Perhaps this is the burr under the saddle.

To help me understand what kind of changes are needed, I have hacked the sandbox so that |mode=mla controls a couple of the most obvious differences between cs1 and mla, date and editor placement and style, for {{cite book}}:

Author; Author2; Author3 (2016). "Chapter". In Editor; Editor2 (eds.). Title. Location: Publisher. pp. 12–34. {{cite book}}: |author= has generic name (help)CS1 maint: numeric names: authors list (link)

Author; Author2; Author3 (2016). "Chapter". In Editor; Editor2 (eds.). Title. Location: Publisher. pp. 12–34. {{cite book}}: |author= has generic name (help); Invalid |mode=mla (help)CS1 maint: numeric names: authors list (link)

—Trappist the monk (talk) 11:15, 24 August 2016 (UTC)

And last author / editor separator. —Trappist the monk (talk) 13:27, 24 August 2016 (UTC)

I don't think this is currently feasible in practice, but if you're looking at switches to control citation style, please consider the possibility of the displayed citation format being controlled by a user preference. At least half the clamour for, e.g., MLA is due to dissonance when reading a cite in an unfamiliar format; as opposed to that caused when having to enter a cite in an unfamiliar format (for which, those with MLA bred in their bones will dislike any template-based solution). Letting them choose to see all cites in MLA format would help a lot (and the right gizmo in VisualEditor might eventually help with the other issue). --Xover (talk) 14:46, 24 August 2016 (UTC)

Aye, that would be the thing. But, I think that for such a thing, we would need to compel all editors to write citations with templates. I think that it is a bit much to expect some bit of code at MediaWiki to read free-form contents of <ref>...</ref> tags and then correctly render that reference according to a user's Special:Preferences. It would also require the server to render the citations at the time they are served or to cache multiple versions of the rendered page.

—Trappist the monk (talk) 15:35, 24 August 2016 (UTC)

We might not be able to "compel all editors to write citations with templates". It would be progress to stop editors from blocking the conversion of (for want of a better description) "plain-text" references to use citation templates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:05, 24 August 2016 (UTC)

@Lingzhi: The changes that Trappist the monk has made to Module:Citation/CS1/sandbox are producing something very close to what you want for long citations:

• {{cite book/new |last=Southam |first=Brian C |chapter=Grandison |editor-last=Grey |editor-first=J David |title=The Jane Austen companion |year=1986 |publisher=Macmillan |location=New York |isbn=0025455400 |mode=mla}}

produces:

• Southam, Brian C (1986). "Grandison". In Grey, J David (ed.). The Jane Austen companion. New York: Macmillan. ISBN 0025455400. {{cite book}}: Invalid |mode=mla (help)

and

• {{cite book/new |last=Tomalin |first=Claire |author-link=Claire Tomalin |title= Jane Austen: A Life |location=New York |publisher= Alfred A. Knopf |date=1997 |isbn=0-679-44628-1 |mode=mla}}

produces:

• Tomalin, Claire (1997). Jane Austen: A Life. New York: Alfred A. Knopf. ISBN 0-679-44628-1. {{cite book}}: Invalid |mode=mla (help)

Surely that is appreciable progress. Thank you very much, Trappist.

Before anybody starts thinking about "faking" MLA-style short citations, I'd like to hear your refutation of my arguments in User:RexxS/NoCiteBar against using <<Author Page>> or sometimes <<Author "made-up Short title">> short citations in Wikipedia articles. It is clear that authors regularly produce multiple works on the same topic, which require disambiguating via a user-constructed "short title" in MLA-style (e.g. about 70 times out of 146 short references in Jane Austen 18 February 2016), whereas it is equally clear that authors rarely produce multiple works on the same topic in the same year (none in Jane Austen today). For Wikipedia use, MLA-style short citations are a non-starter: different editors make different short titles, and adding another work by the same author requires all the previous <<Author page>> cites to be found and disambiguated. No, no, no, no (sounds familiar?). Harvard-style short cites (as already implemented in sfn) have the same format throughout, so any editor new to the page can copy the same style without effort by using the template {{sfn}}, and Ucucha's script can catch any errors that creep in. There's really no case for using anything else. --RexxS (talk) 21:21, 24 August 2016 (UTC)

First/last name order:

Last1, First1; Last2, First2; Last3, First3 (2016). "Chapter". In EditorLast1, EditorFirst1; EditorLast2, EditorFirst2 (eds.). Title. Location: Publisher. pp. 12–34.{{cite book}}: CS1 maint: numeric names: authors list (link)

Last1, First1; Last2, First2; Last3, First3 (2016). "Chapter". In EditorLast1, EditorFirst1; EditorLast2, EditorFirst2 (eds.). Title. Location: Publisher. pp. 12–34. {{cite book}}: Invalid |mode=mla (help)CS1 maint: numeric names: authors list (link)

—Trappist the monk (talk) 00:36, 25 August 2016 (UTC)

I have a few quick thoughts about MLA, and maybe these are items yet to come as this effort proceeds. If so, I apologize for jumping the gun.

• At least the more recent versions, the style specifically omits URLs and assumes that anyone can search for the source online. Of course we can link to a source within our citations because our formatting explicitly includes hyperlinks while MLA is designed for print. I assume we'd want to continue the practice of actually linking items, and probably continue to insert the file type as we do now.
• Also, MLA would append a medium designation, something like "Print" or "Web" to the end of the citation. For online sources, the "Web" would be followed by the access date. If it were a source reprinted online, that would be "Web. <republisher>. <access date>." Perhaps a little coding to assume that this would be "Print" unless a link is supplied when it would be "Web", but we'd need to either use |type= or another new parameter to allow editors to override this for DVDs and other media.

Imzadi 1979 → 01:42, 25 August 2016 (UTC)

I would have thought that the addition of a hyperlink when a source is available online is such a convenience for the reader that there's no case for failing to do that in our citations. MLA is indeed designed for printed work (including instructions on margins, double line spacing and the name of the Works Cited section), so we have to adapt to some extent. The whole point of offering an MLA-style long citation is so that readers accustomed to that style don't find it jarring when they see the citations in CS1 default style, not to precisely mimic a print format within an online encyclopedia. I can therefore see little point in appending "Web" or "Print" - that tells readers of the printed article that it's worth searching for online or not. In a Wikipedia article, it is surely obvious that if there's a hyperlink, it's available online, and if there's not, it isn't. --RexxS (talk) 02:11, 25 August 2016 (UTC)

It seems to me that it would be a bit disingenuous to add the capability to code a citation with |mode=mla and not actually output what MLA says is their citation format. That said, I've seen something that makes it seem as though they've dropped the medium indicator from the 8th edition published this year, so that might be something unique to the 7th edition that's now superseded. Imzadi 1979 → 15:22, 26 August 2016 (UTC)

Original year and edition:

Author; Author2; Author3 (2016) [1920]. "Chapter". In Editor; Editor2 (eds.). Title (2nd ed.). Location: Publisher. pp. 12–34. {{cite book}}: |author= has generic name (help)CS1 maint: numeric names: authors list (link)

Author; Author2; Author3 (2016) [1920]. "Chapter". In Editor; Editor2 (eds.). Title (2nd ed.). Location: Publisher. pp. 12–34. {{cite book}}: |author= has generic name (help); Invalid |mode=mla (help)CS1 maint: numeric names: authors list (link)

—Trappist the monk (talk) 09:48, 25 August 2016 (UTC)

Translators:

Author; Author2; Author3 (2016) [1920]. "Chapter". In Editor; Editor2 (eds.). Title. Translated by Translator; Translator2 (2nd ed.). Location: Publisher. pp. 12–34. {{cite book}}: |author= has generic name (help)CS1 maint: numeric names: authors list (link)

Author; Author2; Author3 (2016) [1920]. "Chapter". In Editor; Editor2 (eds.). Title. Translated by Translator; Translator2 (2nd ed.). Location: Publisher. pp. 12–34. {{cite book}}: |author= has generic name (help); Invalid |mode=mla (help)CS1 maint: numeric names: authors list (link)

—Trappist the monk (talk) 13:49, 25 August 2016 (UTC)

Break

@Trappist the monk, RexxS, and Lingzhi: I know nothing about templates and haven't read the above, so perhaps this isn't feasible, but I would love to see those templates converted so that we could simply place the punctuation where we needed it. At the moment, I write manually:

• John Rawls, A Theory of Justice, Cambridge: Harvard University Press, 1971, 1.
• and thereafter: Rawls 1971, 2.
• Chantal Zabus, "The Excised Body in African Texts and Contexts," in Merete Falck Borch (ed.), Bodies and Voices: The Force-field of Representation and Discourse in Colonial and Postcolonial Studies, New York: Rodopi, 2008, 1.
• and thereafter: Zabus 2008, 2.
• Nicky Woolf, "Stingray documents offer rare insight into police and FBI surveillance", The Guardian, 26 August 2016.

When I'm editing with people who use templates, I can copy their style manually, even though it leads to internal inconsistency with newspapers (date after name if there's a byline, and date at the end if not; it's frustrating to add an inconsistency deliberately just to copy the template style). But if people edit an article where I've added manual cites in the style above, they can't copy my style (or any other) using templates; they have to do it manually because the templates are so limiting.

Is it not possible to create a set of templates where the punctuation is more flexible? SarahSV ^(talk) 00:07, 27 August 2016 (UTC)

Is it really punctuation that you're talking about or is it element placement or a combination of both? Your apparently preferred style looks to be a combination of cs2 (comma separated elements) and mla (publication date moves to the end):

• John Rawls, A Theory of Justice, Cambridge: Harvard University Press, 1971, 1. – your original
• John Rawls (1971), A Theory of Justice, Cambridge: Harvard University Press, 1. {{cite book}}: Unknown parameter |nopp= ignored (|no-pp= suggested) (help) – {{cite book}} with |mode=cs2
• John Rawls (1971). A Theory of Justice. Cambridge: Harvard University Press. 1. {{cite book}}: Invalid |mode=mla (help); Unknown parameter |nopp= ignored (|no-pp= suggested) (help)CS1 maint: postscript (link) – {{cite book}} (sandbox) with |mode=mla

A primary purpose of the templates is to take on the burden of punctuation so that editors don't have to worry about it – punctuation just happens and it is the same, citation-to-citation, editor-to-editor. One could, I suppose, create punctuation-specific parameters:

|title= – normal or standard title parameter follows the cs1|2 rules according to the rules of the enclosing template

|title,= – override the normal cs1 element separator, full stop, with a comma

|qtitle= – force a normally italic title to be quoted

|ititle= – force a normally quoted title to be italic

|ptitle= – force a normally italic or quote title to be plain text

One could extend this idea and enumerate the parameters so that they would render in order specified in the template:

{{cite book |1author,=John Rawls |2title,=A Theory of Justice |3location=Cambridge |4publisher,=Harvard University Press |5date,=1971 |6page.=1 |nopp=yes}}

I don't think that either of these ideas should be pursued. Better, I think is to support a handful of commonly used and well documented styles – mla, apa, cms.

The above discussion that you didn't read is mostly about implementing mla in the cs1|2 templates. I have adapted {{cite book}} so that it can render basic mla style. I intend to similarly adapt {{cite journal}}, {{cite news}}, and {{cite web}} and then when real life gets out of the way, take what I've learned from this experiment and rewrite a large chunk of Module:Citation/CS1 so that other similarly documented styles can be supported.

—Trappist the monk (talk) 10:38, 27 August 2016 (UTC)

Trappist the monk, thank you for the detailed response. The style I use is close to Chicago, but I've pared it down to all commas, no brackets, to keep it simple. I usually use the long cite on first reference in the text and the short thereafter, and usually no separate bibliography section.

Can cite news at least be changed so that the dates don't move? We had an RfC that supported the change, but it was never implemented. SarahSV ^(talk) 16:16, 27 August 2016 (UTC)

Above I mentioned a rewrite of a large chunk of Module:Citation/CS1. The difficulty that Editor Dragons flight mentioned in the RfC still exists. I would expect that at the end of the rewrite, it will be easier to position the publication date as the second element in the rendered citation.

—Trappist the monk (talk) 09:50, 28 August 2016 (UTC)

@Trappist the monk: I strongly disagree with both creating punctuation-specific and enumerating parameters as this would make total mess over months/years and references would be not unified/uniform but – mess. I'm even surprised that you proposed this as goal of CS1 was to standardize – not to allow "citeshakes"?

Moreover, I thought you would simply ignore SarahSV's comment as this user is not using CS1 and says ... they can't copy my style (or any other) using templates; they have to do it manually because the templates are so limiting. – I can't even comment on this one.

@SlimVirgin: Templates and CS1 are not "so limiting" but a perfect solution not to disable people from "copying each other styles" but to introduce one style for all references that can be altered in future if there is need to, because citation style and Wikipedia style generally should be uniform and consistent with guidelines; if every editor would cite in a different way – "chaos mode" would be turned on in references section.--Obsuser (talk) 23:07, 27 August 2016 (UTC)

You must have missed this line in that post: I don't think that either of these ideas should be pursued. It is the prerogative and the responsibility of the cs1|2 templates to handle formatting details. I do not think that we should be changing that. What I wrote was merely a thought experiment.

When an editor specifically asks a question of me, as was done here, common courtesy requires me to respond. No one benefits if questions that can be answered are left unanswered.

—Trappist the monk (talk) 09:50, 28 August 2016 (UTC)

Just for the record, I also "strongly disagree with both creating punctuation-specific and enumerating parameters" for similar reasons. We already have a frequent problem with people abusing the |publisher= parameter to "get their way or else" in their WP:GREATWRONGS campaign against ever italicizing the name of a cited website, for example. This nonsense battlegrounding has to stop, not be given a whole new navy of battleships with which to engage in style-micromanagement editwarring. I also agree with the points above about the benefits of a consistent citation style. I don't think we should be doing any work at all to integrate MLA, ALA, AMA, etc. citation styles into CS1 or any template system; it's a non-productive waste of editorial time to do it, and an much worse waste of many editors' combined editorial time to deal with the mess it creates, and, worst of all, all the "don't you dare touch my precious citation formatting" drama festivals it generates. If we just ignore these off-WP citation styles, at some point the sheer pressure of more and more articles being done in default CS1 style, and more and more articles converted to it without objection, will result (finally) in consensus that WP should have a consistent citation style, not permit every imaginable, inconsistent one. That may take 5 years, or 10. Even if it never happened, what has to go – no doubt – is the nonsense WP:LOCALCONSENSUS over at WP:CITE that any made-up on the spot out of your own imagination citation "style", not found in any source anywhere, can be ruthlessly enforced at an article as long as you made it the consistent "style" at the article at some point, no matter how irrational and confusing the "style" is. WP:CITEVAR was intended to permit people professionally steeped in a particular, real-world citation style, like AMA or MHRA or Vancouver, to use it here without hissy-fits erupting about it (and this has proven to be a mistake). Whether or not that was a good idea, it's since then been totally hijacked to permit idiosyncratic WP:OWN chaos that has to go. This will probably require a WP:VPPOL RfC, since prior attempts to deal with it at WT:CITE itself have met with tagteam stonewalling.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  10:10, 28 August 2016 (UTC)

mla in cite journal

Adapting {{cite journal}} to use mla:

Author; Author2; Author3 (2016). "Title". Journal. Volume (Issue): 12–34. {{cite journal}}: |author= has generic name (help); |issue= has extra text (help); |volume= has extra text (help)CS1 maint: numeric names: authors list (link)

Author; Author2; Author3 (2016). "Title". Journal. Volume (Issue): 12–34. {{cite journal}}: |author= has generic name (help); |issue= has extra text (help); |volume= has extra text (help); Invalid |mode=mla (help)CS1 maint: numeric names: authors list (link)

—Trappist the monk (talk) 12:12, 27 August 2016 (UTC)

If I make a tangential comment, but seeing how this is formatted above MLA style, reminds me of a minor request related to {{cite magazine}}. That template is capitalizing "Vol." when I think it really should be lowercasing it as your MLA example does. Maybe a minor change for a future module update? Imzadi 1979 → 14:01, 29 August 2016 (UTC)

Compare these; one is {{cite magazine}} (cs1) and the other is {{citation}} (cs2):

"Title". Magazine. Vol. 23, no. 4. Archived from the original on 2016-08-29. Retrieved 2016-08-29.

"Title", Magazine, vol. 23, no. 4, archived from the original on 2016-08-29, retrieved 2016-08-29

The 'style' defined for cs1 is to use full stops between citation elements compared to commas for cs2. Because each citation element in cs1 is essentially a new sentence, the element's static text is capitalized. Because cs2 is a single sentence, the static text is not capitalized.

—Trappist the monk (talk) 15:04, 29 August 2016 (UTC)

Except that "p." and "pp." aren't capitalized when used, so I don't buy the "separate" sentence argument. Why isn't the volume ended by a period when issue and page number are?

"Title". Magazine. Vol. 23, no. 4. p. 6. Archived from the original on 2016-08-29. Retrieved 2016-08-29.

I think it would be better to be a bit more consistent here, and oddly MLA shows a bit of a better way forward. Imzadi 1979 → 15:36, 29 August 2016 (UTC)

Are p. and pp. ever capitalized outside of Wikipedia? I don't think that those two have ever been capitalized in cs1|2. 'Vol.' has only recently been made available. The thing that I notice about your example is the separator character following the issue number. If there isn't a separator character between volume and issue, should there be a separator character between issue and page?

—Trappist the monk (talk) 10:03, 30 August 2016 (UTC)

Edited collections and chapters

Is there a difference between edited collections and books with chapters with different authors? Template:Cite book says: "For edited collections, use {{cite encyclopedia}}". But 'cite book' also gives the option for 'Citing a chapter in a book with different authors for different chapters and an editor'. This seems identical to 'cite encyclopedia'. Is there a difference? Some collections are arranged in chapters, some are not. Is that the main difference? That non-chapter collections should use 'cite encyclopedia' and collections arranged in chapters can use either? (In passing, people do sometimes use 'contribution' for chapters in a collection, when 'contribution' should really be for "afterword, foreword, introduction, or preface"). Carcharoth (talk) 12:06, 23 August 2016 (UTC)

Everything makes sense when you realize that the doc is actually a story by Lewis Carrol. 108.55.199.227 (talk) 12:43, 23 August 2016 (UTC)

Am I supposed to find a queen somewhere on the documentation page? Clearly I'm looking in the wrong places. --Izno (talk) 13:08, 23 August 2016 (UTC)

I'm not sure where the use-{{cite encyclopedia}}-for-edited-collections notion comes from. Perhaps it is a documentation artifact from the early days of the cs1 templates when those templates were much less capable than they are today. Scholarly works on some topic are often edited collections of writings by many authors compiled into a book of chapters. I see no reason to prefer {{cite encyclopedia}} over {{cite book}} for these works.

There is no requirement that states that |contribution= is specifically limited to afterword, foreword, introduction, and preface. The requirement that I think you allude to is for |contributor= which requires |contribution=. The contribution can be anything but is typically one of the afterword, foreword, etc.

—Trappist the monk (talk) 13:18, 23 August 2016 (UTC)

Puzzling. I use 'cite encyclopedia' all the time. Quoting from {{cite encyclopedia}}:

"This Citation Style 1 template is used to create citations for articles or chapters in edited collections such as encyclopedias and dictionaries, but more generally any book or book series containing individual sections or chapters written by various authors, and put together by one or more editors."

Example of my use of 'cite encyclopedia': [1], [2]. Another example is the Dictionary of Scottish Architects, which could be cited as a collection (more strictly, it is an online database). Many of these online collections would be encyclopedias if printed. Carcharoth (talk) 13:39, 23 August 2016 (UTC)

Certainly your first example could use {{cite book}}. Your second could use {{cite web}} especially if the online version is the source that you consulted:

{{cite web|last=Brody|first=David|author-link=David Brody|title=Meany, George|url=http://www.anb.org/articles/15/15-01098.html|website=American National Biography Online|publisher=Oxford University Press and American Council of Learned Societies|subscription=yes|date=February 2000|access-date=12 August 2016}}

Brody, David (February 2000). "Meany, George". American National Biography Online. Oxford University Press and American Council of Learned Societies. Retrieved 12 August 2016. {{cite web}}: Unknown parameter |subscription= ignored (|url-access= suggested) (help)

—Trappist the monk (talk) 14:16, 23 August 2016 (UTC)

I don't think that any editor actually makes use of the information contained in the name of the cite template. {{Cite encyclopedia}} treats the container |encyclopedia= rather like MLA's style of using quotes, while {{cite book}} treats it as an alias for |work= so it is italicised. Chacun à son goût.

• Cavell, Richard (2015). "Remembering Canada: The Politics of Cultural Memory". In Sugars, Cynthia (ed.). The Oxford Handbook of Canadian Literature. Oxford University Press. pp. 64–79. ISBN 9780199941865. - cite encyclopedia
• Cavell, Richard (2015). Sugars, Cynthia (ed.). Remembering Canada: The Politics of Cultural Memory. Oxford University Press. pp. 64–79. ISBN 9780199941865. {{cite book}}: Unknown parameter |encyclopedia= ignored (help) - cite book with |encyclopedia=
• Cavell, Richard (2015). Sugars, Cynthia (ed.). Remembering Canada: The Politics of Cultural Memory. Oxford University Press. pp. 64–79. ISBN 9780199941865. {{cite book}}: |work= ignored (help) - cite book with |work=

--RexxS (talk) 14:27, 23 August 2016 (UTC)

I don't think a chapter in a book is supposed to be rendered in italics. The citation immediately above should be rendered as:

• Cavell, Richard (2015). "Remembering Canada: The Politics of Cultural Memory". In Sugars, Cynthia (ed.). The Oxford Handbook of Canadian Literature. Oxford University Press. pp. 64–79. ISBN 9780199941865. - cite book with |chapter=

– Jonesey95 (talk) 14:37, 23 August 2016 (UTC)

Jonesy is right. 'Title' in cite encyclopedia is equivalent to 'chapter' in cite book. This can confuse people. Carcharoth (talk) 15:10, 23 August 2016 (UTC)

Quite. I'm sorry I wasn't clearer: I was trying to show what would happen if you were to use |encyclopedia= in {{cite book}}, not advocate its use! There is a case you could make for using {{cite book}} for all works written on paper with covers on the front and back. You just learn one set of parameters and the output they produce. Personally, I don't care if chapter titles are in quotes or offset in superscripted Comic Sans with a pink shadow. As long as we all agree on something recognisable and use it consistently. --RexxS ^{Call me Dino} (talk) 16:39, 23 August 2016 (UTC)

I realise they produce the same output. It is more a case of when I look at a source, I think to myself "what type of source is this?". If it is a printed book, that is obvious. If it is is a collection, I tend to reach for 'cite encylopedia'. If it is a news publication, then 'cite news'. When it is a webpage, I know I should really use 'cite web', but there is a distinction in my mind between webpages with no named author and no obvious date on a website with no clear structure, and more organised online websites clearly intended to replicate the organisation of a collection of entries under a named work (sometimes with a named author, sometimes not). The DSA and ANB are examples of the latter, while an example of the former would be this. In those cases, it is sometimes only really possible to identity the title of the webpage and the publishing organisation (usually obvious from the website home page). The authority (i.e. 'reliability') of a citation with no named author rests on the reputation of the publisher. I'm not consistent, though, as citations to various online databases I do often format using cite web. What I think people struggle with is the idea that the webpage is the thing with the 'title' and the 'website' is the 'work', when in the case of a book, the 'work' is the 'title' and bits within it (the webpages in the case of the website) are pages or chapters and so on. What I am saying is that in some cases, it is obvious that the website as a whole is the 'work', but for other websites, they are more a collection of pages that sometimes bear little relation to each other except for being on the same domain name. This is a well-defined website, but this is more a loose grouping of pages published by the same organisation. Does that make sense of the difference I'm trying to describe? Carcharoth (talk) 15:04, 23 August 2016 (UTC)

The documentation is inconsistent and confusing, but sometimes this results from design flaws, such as the dual use of |title= as remarked. Not that this hasn't come up before, it has, several times in the past 5 years (or more). Fixing these flaws (there are several) should be the first order of business. In my mind, this is much more pressing than adding nice little icons, or making sure that machines can exchange metadata, or making the native citation system comfortable for users of other systems. A moratorium on any new features until a clean easy-to-use design emerges, would not be a bad idea imo. Otherwise the rabbit hole may keep getting larger. 72.43.99.146 (talk) 23:31, 23 August 2016 (UTC)

Agree the docs are contradictory and this should be resolved. I would advocate re-documenting {{Cite encyclopedia}} as for being for tertiary sources composed of numerous encyclopedia- or dictionary-style entries (whether it's a multi-author work or not is irrelevant, as a large number, maybe even a majority, of topical specialist encyclopedias and dictionaries are single-author). For my part, any time I'm citing a multi-author academic book composed of papers by authors, presented as chapters, with a volume editor, I use {{Cite book}} and treat the paper/chapter as |chapter=. I one case I ran into trouble because the paper itself had chapters, and I dealt with this with |at= to site both the subchapter and the page number, though technically it was overkill since a page number was probably sufficient. I have not monkeyed with |contribution= much, so I'm not sure how nice it plays with |chapter=; I've always reserved it for forewords, afterwords, and introductions.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:40, 28 August 2016 (UTC)

Replacements (gsub) in Module:Citation/CS1

Should str= mw.ustring.gsub (str, '[“”]', '\"'); be changed to str= mw.ustring.gsub (str, '[“”]', '%"'); as Lua escape character should be %, not standard regex \?

Same applies for line below. --Obsuser (talk) 03:50, 24 August 2016 (UTC)

@Obsuser: In Lua, strings can use various escape sequences that start with \, including \". Further details at mw:LUAREF#string - Evad37 [talk] 08:57, 24 August 2016 (UTC)

@Obsuser: The Lua reference manual states that \" is a valid escape character for double quotes: Lexical Conventions. Normally %x is usable in describing a character class for x, (see Character Class, but within a replacement string a character class doesn't make sense, unless it's part of a capture. Try pasting:

1. print( string.gsub('123abc', '[2a]', '\"') )
2. print( string.gsub('123abc', '[2a]', '"') )
3. print( string.gsub('123abc', '[2a]', '%"') )

into https://www.lua.org/cgi-bin/demo and you'll see that 1 & 2 work, but the interpreter barfs at the % in number 3. --RexxS (talk) 20:31, 24 August 2016 (UTC)

@Evad37 and RexxS: Thank you. I was confused with mw:LUAREF#string.gsub which says for replacement string that "The character % works as an escape character: any...". However, the following part of the sentence mentions captures.

I've tried to use :gsub(',', '%.') on one string in Wikipedia module and it worked as I thought it would: I got "." instead of ",", not "%." instead of "," (I want to say that % worked as escape character for dot; in https://www.lua.org/cgi-bin/demo it doesn't work that way). --Obsuser (talk) 21:01, 24 August 2016 (UTC)

About WP:PAGELINK

The problem seems to have arisen nearly 6 years ago, when it was decided to link Google Books pages not adding pageurl to titleurl and chapterurl, but distorting the use of titleurl, which since then can also no longer be addressed to the front cover. Personally I solve by placing a link in the page or quote parameter, but some editors disagree and revert me. I mean, what do you think of updating the template {{cite book}}? --Mauro Lanari (talk) 09:51, 25 August 2016 (UTC)

A link to a particular page can be useful, but a link to the cover is just advertising Google Books for little benefit, since the same page is only one extra click away via the ISBN link. Kanguole 10:42, 25 August 2016 (UTC)

But since the title of a book is written on the front cover, the titleurl should direct there and nowhere else. Or not? In addition, the ISBN link often leads to a wrong edition of the book, or to one now out of print. --Mauro Lanari (talk) 11:30, 25 August 2016 (UTC)

The ISBN should lead to the edition of the book being cited, otherwise it tends to make page number useless. Nikkimaria (talk) 11:43, 25 August 2016 (UTC)

What are you talking about? That RFC did not make any decision regarding a (non-existent) |pageurl= parameter. In fact, |pageurl= is not mentioned in the RFC and only once is a cs1|2 template mentioned as an example – the editor described linked to a specific page using {{cite book}}. If there is a problem, I don't understand what it is. Can you elaborate?

—Trappist the monk (talk) 11:46, 25 August 2016 (UTC)

I'll try. I'm asking about the possibility of linking directly a Google Books page using an appropriate new parameter (for instance |pageurl=) instead of overloading the functions of the other already existing parameters. --Mauro Lanari (talk) 12:10, 25 August 2016 (UTC)

A |page-url= parameter is problematic because |pages= allows comma separated lists of page numbers. To do it 'properly', I think that we would need to deprecate that form of |pages= so that its only allowed value would be a single page-range (|pages=100–120). We would then need to enumerate both |pagen= and |pagesn= and create matching enumerated |page-urln= and |pages-urln= parameters. For semantic reasons it is desirable to keep |pages= because we shouldn't be using the singular form when identifying a page-range (|page=100–120).

—Trappist the monk (talk) 13:13, 25 August 2016 (UTC)

Really very interesting. Well: maybe (maybe) pagesurl is a false problem. A page-range always corresponds to a chapter or to a page ff, which means that no one is interested in a direct link to the last page. For example so far I have only ever linked the first page, while on the page parameter I have included the full range (pp./pages 100-120, p./page 100 ff and so on). --Mauro Lanari (talk) 14:13, 25 August 2016 (UTC)

There is no requirement that a page-range [shall] always [correspond] to a chapter (or journal article). It is a common practice in bibliographic cites, but in that case, the specific page numbers are stated in the accompanying short cites. cs1|2, as a style, does not limit editors' use of page ranges in that way. For in-line citations, if the source chapter or article includes pages 100–120 but the important bit that supports a statement in our article is on page 105, we should cite the chapter in |chapter= or the journal article in |title= and identify the location as |page=105 not as |pages=100–120. It is poor practice for us to make the reader search an entire article for a sentence or fact that lives on one page.

—Trappist the monk (talk) 14:48, 25 August 2016 (UTC)

As you know, there is substantial disagreement on this point. Kanguole 14:57, 25 August 2016 (UTC)

Every useful link to Google Books I have seen in cite templates links |title= to a URL for the page where the citation can be verified. That's the point of linking in citations – helping the reader verify the text in the article. – Jonesey95 (talk) 15:09, 25 August 2016 (UTC)

As I said above, by doing so you have overloaded the functions of the other existing parameters instead of adding a new appropriate one. This is an example of how all the info may be supplied in the unfortunately persistent absence of |pageurl=: Graham, Stephen (2008) [1st ed. 2004]. Cities, war, and terrorism. Towards an urban geopolitics. Hoboken, New Jersey: John Wiley & Sons. p. 51. ISBN 978-0-470-75302-6. ISBN 0-47075302-1., where the reader is helped in verifying the text in the article (SUV as a "defensive capsule") --Mauro Lanari (talk) 16:23, 25 August 2016 (UTC)

Linking to the front cover can only confuse the reader. The ISBN link and the URL link in the page number field are both one click away from the front cover page, and the front cover image is already in the left sidebar of the Google Books page. Just do this (I also removed a redundant ISBN): Graham, Stephen (2008) [2004]. Cities, war, and terrorism. Towards an urban geopolitics. Hoboken, New Jersey: John Wiley & Sons. p. 51. ISBN 978-0-470-75302-6. – Jonesey95 (talk) 16:35, 25 August 2016 (UTC)

@Kanguole: Last time that there was disagreement over what should be put in |pages=, I unwatched this page. I can easily do that again. --Redrose64 (talk) 16:40, 25 August 2016 (UTC)

Linking the front cover is the only correct use of titleurl: "URL of an online location where the text of the publication can be found." It's not provided any further usage, and if you collapse the front cover with the page, you're getting the opposite of what you would like to avoid: confusing the reader. --Mauro Lanari (talk) 17:19, 25 August 2016 (UTC)

There is no |titleurl= parameter, but the next sentence in the documentation for |url= is "If applicable, the link may point to the specific page(s) referenced." The link to the front cover is superfluous, so putting the specific page link in |url= may be inelegant, but is justifiable in terms of the purpose of the citation. Kanguole 17:32, 25 August 2016 (UTC)

I've always thought that where a link to the page is possible (where a preview is available, though it won't be available to all) then the link should be wrapped around the page number. Where no preview is possible, but you still want to point to the book somewhere, then the URL can be usefully wrapped around the title. Doing both is a bit of overkill. Sometimes I think it is not worth the bother, and no links at all is best. It is often more important to start from the front cover of the book, and assess its reliability, before turning to the page you have been directed at. Jumping straight to a page is lazy and encourages people to take things out of context. I hate it when people use search-string URLs - that is discouraged, isn't it? Carcharoth (talk) 18:26, 25 August 2016 (UTC)

Linking the Google Books title page ("About this book") is useful because it verifies the entire citation, in "§ Bibliographic information". I don't think linking to Google Books "About this book" pages is advertising, any more than mentioning the (original) publisher. After all, all citations could be conceivably reduced to just the identifier. That would make them extra-simple. In any case, my preference runs towards short citations; I link the page url at the short form, and often, the book title ("About this book") at the full citation. 72.43.99.146 (talk) 00:35, 26 August 2016 (UTC)

When a reader/user finds a {{cite book}} and sees the title book as a blue link, clicking on it (s)he expects anything but being directed to a specific page, furthermore "out of the context". To have discarded the idea of a |pageurl= parameter for "|url=: if applicable, the link may point to the specific page(s) referenced" is symptomatic of a lazy, confused, twisted mind. --95.234.110.97 (talk) 02:49, 26 August 2016 (UTC)

Url validation

@Trappist the monk: and others: Why is http://нижнийновгород.рф/references/inter/tampere.html not recognized as good url? I found it on one page and error is raised. However, if I copy it in Chrome and paste it – I get form converted into standard latin characters: http://xn--b1acdfjbh2acclca1a.xn--p1ai/references/inter/tampere.html. --Obsuser (talk) 10:17, 25 August 2016 (UTC)

Because the domain name is not written using the Latin character set. When you paste that url into Chome, it translates it into an internationalized domain name so that the internet infrastructure can understand it. Module:Citation/CS1 uses the standardized rules for domain name validation which requires domain names to be in the Latin character set.

—Trappist the monk (talk) 11:23, 25 August 2016 (UTC)

Using Firefox, I don't find any difference between the two types of url: both work well. --Mauro Lanari (talk) 11:44, 25 August 2016 (UTC)

The translation is still done; firefox apparently doesn't show that it is done.

—Trappist the monk (talk) 11:48, 25 August 2016 (UTC)

We have a magic word, {{urlencode:}}, that could be used to wrap URLs like that provided by the OP. Can this be built into CS1's Lua module? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:30, 30 August 2016 (UTC)

Sections of websites

Is there a correct way to link to a section of a website? Which of these three is best?

• [3] put both section and title information in the 'title' parameter
• [4] put the section information outside the citation template
• [5] use the 'at' parameter to describe the section

I should provide the full examples here, but am not sure how to do that. Carcharoth (talk) 18:20, 25 August 2016 (UTC)

If the destination website provided an anchor to a section, then I'd use:

• {{cite web |url=http://venn.lib.cam.ac.uk/Documents/acad/lists/P.html#Aeronautical_Engineering,_Francis_Mond_Professorship_of |title=Francis Mond Professor of Aeronautical Engineering |website=A Cambridge Alumni Database |publisher=University of Cambridge |accessdate=15 September 2013}}
• "Francis Mond Professor of Aeronautical Engineering". A Cambridge Alumni Database. University of Cambridge. Retrieved 15 September 2013.

On the grounds that nobody actually cares what the title of the container is (i.e. page title) when they have the title of the section linked via the fragment in the url. But that's just me. As for the actual venn.lib.cam.ac.uk site, they haven't realised yet that the HTML5 spec at https://www.w3.org/TR/html-markup/a.html#a-constraints has now made obsolete the "name" attribute that the web-designers are using to create an anchor for each section - which is why the above doesn't actually work. Even dinosaurs like me have caught on to that. --RexxS (talk) 20:21, 25 August 2016 (UTC)

The spec that I normally refer to shows that name= is obsolete, but words it as "should not", which is weaker than "must not". It then describes how the name= attribute can be used in such a way that it won't conflict with other name= or id= attributes. Later on we find "The following attributes are obsolete (though the elements are still part of the language), and must not be used by authors ... name on a elements (except as noted in the previous section)". Here we have the strong "must not", but conditionally weakened. --Redrose64 (talk) 22:47, 25 August 2016 (UTC)

I would use the |at= solution here. The above suggestion of |title=Francis Mond Professor of Aeronautical Engineering is a made-up pseudo-title not appearing in the work, thus making it harder to find and verify the exact source material. I encounter this problem frequently, and fix it, of people trying to use the |title= parameter to describe or retitle a work because they think the actual title isn't clear enough or something. E.g., often I'll seen dictionary entries done as |title='anthropogenesis' entry, and this is simply incorrect; the correct value is |title=anthropogenesis. Don't second-guess the title even if you don't like it.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:31, 28 August 2016 (UTC)

Title2 or AltTitle

Is it possible to incorporate something into template:cite web to reflect when a piece has more than one title?

For example as you can see at http://web.archive.org/web/20160729014127/http://www.macleans.ca/news/justice-for-black-canadians-not/ the original title of the July 28 piece by Domise is "Justice for Black Canadians (not)" but the present version of the article at http://www.macleans.ca/news/justice-for-black-canadians-not/ has changed the title to "Why we can’t trust SIU to probe death of Abdirahman Abdi" even though the URL still reflects the old title.

I would like a way to convey in the citation both the original title of the piece and then the replacement title for the piece.

To give another example of what I mean, take this piece by Stephanie McCrummen in the Washington Post:

• 22 March 2005 http://www.washingtonpost.com/wp-srv/metro/specials/homefront/khan_article.html "Looking for Logic Amid the Pain: Grieving Father Struggles to Understand"
• 28 July 2016 https://www.washingtonpost.com/national/khizr-khans-loss-a-grieving-father-of-a-soldier-struggles-to-understand/2016/07/28/18e8139a-552d-11e6-bbf5-957ad17b4385_story.html "Khizr Khan's loss: A grieving father of a soldier struggles to understand"

It's the same piece, but was given a new title. Ranze (talk) 06:32, 26 August 2016 (UTC)

I would use |orig-year=originally published 22 March 2005 as "Looking for Logic amid the Pain". 64.134.66.58 (talk) 11:43, 26 August 2016 (UTC)

I would not advise what the IP above suggests. In this case, I would only use the title for the version of the article that was consulted and cited. Yes, that could mean a mismatch between the title and the version of it repeated within the URL, but so be it. If necessary, it may be possible to additionally cite an archived copy of the old version of the article under the old title, but I would not try to combine what are really separate sources together. Imzadi 1979 → 15:19, 26 August 2016 (UTC)

I disagree. This is for all practical purposes a reprint, except for the article's title. For purposes of verification, nothing changed materially, and discovery of the source has not been affected. It is convenient to provide prior history for the title, but this is not necessary in this case. Why make it any more complicated? It would be a different story if this was a different title in a different edition. 72.43.99.138 (talk) 15:32, 26 August 2016 (UTC)

When you add the content to the article, with a ref, in that ref you should use the title as it is shown at that time, the date as it is shown, and the accessdate is today's date. If the title changes tomorrow, leave it alone together with the date, accessdate and anything else. --Redrose64 (talk) 19:20, 26 August 2016 (UTC)

If the title changes, the citation should be edited because this affects discovery of the source, and/or may confuse readers. This may be more pertinent when sources are online (eventually, all of them may be). Something should promptly alert the reader that they are looking at the right source, albeit with a different title. The use of |orig-year= was suggested in cases where the new title is cited, in order to provide title history as a convenience. 72.43.99.138 (talk) 14:47, 27 August 2016 (UTC)

If you went and looked (how else could you know the title changed?), then you have accessed it again, so should update the title to the current one and change the access-date. The purpose of the access-date parameter is to mark the date that something was most recently verified, not to freeze in time when a source was first added. In complex situations involving offline sources, you can just add a note after the citation template and before the closing </ref>. Another thing I've done when a work as two titles in different markets and they're they same down the page numbers, just with different covers and nominal publishers, is to do <ref>{{Cite book|...}} Also published as: {{Cite book|...}}</ref> There is no reason that every possible detail must be fitted into a single citation template.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:21, 28 August 2016 (UTC)

Adding a "disable italics on work" parameter?

I know there's a history about the use of italics for websites or not (which comes from MOS:TITLE) and whether to use the work= or publisher= parameter to achieve the right effect. We're having a discussion on WT:VG for websites like Rotten Tomatoes and Metacritic which seem to have, in common practice around WP, to not be italicized as websites (as they aren't creative work websites but more as services). Past discussion on CS1 suggests they should be entered as publisher=, but this is not true as they have a separate publishing entity.

The only trick with CS1 that can make these appear non-italic in citations is to italic the name in the template entry , but this has this data passed into wikidata so it is undesirable.

Is it possible if we could get a field like "workni=y" or "wni=y" added to CS1 that, if set, disables the italics on the work= entry, so that we respect the general styling these types of sites have in prose, while also respecting how they are entered as wikidata? If the field is not set (eg applying to all existing templates), then there should be no change in behavior, the work entry is still italicized.

This type of change probably would affect less than 1% of the citations out there, while also making these templates consistent with the openness of MOS:TITLE which does not fully prescribe how to handle websites. --MASEM (t) 16:26, 27 August 2016 (UTC)

Oppose. We need to put to bed any further coddling of people who want to force-format things to suit their personal peccadilloes. People are just going to have to live with the fact that WP is not their personal blog, and has it's own style guide. Every citation style in the world is different in minor details, zero of them satisfy 100% of the people, and probably no one is 100% satisfied with every nit-pick any any of them. People just get over it. If someone is abusing the |publisher= parameter for the |website= title just to force it to not be italic, this is an error and should be reverted.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:09, 28 August 2016 (UTC)

I looked over that thread, and the entire thing is just because some people do not think clearly about the difference between a publication, a [re]distribution, and a publishing company, nor bother to figure out what the template parameters are. There is no use case at all in which we could need some |workni=. I've laid this out as a mini-tutorial at Wikipedia talk:WikiProject Video games#This really isn't difficult once you sort it out.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:09, 28 August 2016 (UTC)

The problem is that CS1 is forcing a choice that MOS:TITLE does not fully define. MOS:TITLE only speaks to using italics to a specific type of website but does not describes for all websites, and practice (which defines policy not the reverse) clearly shows that we don't italicize certain types of websites in running prose. So CS1 should be flexible to the openness that MOS:TITLE has, and not force a style choice nor encourage poor use of parameters to make a style choice work. --MASEM (t) 14:40, 28 August 2016 (UTC)

??? CS1 is a style, and it is optional. Styles must be internally consistent. Templated styles like CS1 must be standardized. In this optional, templated style, |work= is always italicized. Unless you want to change the font-style rendering of the parameter (a different discussion, imo) I suggest using a different citation style, maybe a non-templated one. 72.43.99.138 (talk) 15:35, 28 August 2016 (UTC)

New categories

I have just created:

• Category:Templates that wrap Cite book
• Category:Templates that wrap Cite encyclopedia
• Category:Templates that wrap Cite journal
• Category:Templates that wrap Cite map
• Category:Templates that wrap Cite news
• Category:Templates that wrap Cite web

These are applied automatically, by {{cs1 wrapper}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:45, 27 August 2016 (UTC)

Cite interview title and italics

I searched in the CS1 archives regarding {{cite interview}} and couldn't find a reason for why cite interview italicizes its title.

I couldn't find anything in our Manual regarding the title of an interview. MLA and Chicago recommend (not official links!) to place the title of a published interview in quotation marks, while APA doesn't seem to have a recommendation (presumably because they consider published interviews to take the format of the publication type in question--official blog from 2009--APA then seemed to have the practice of italicizing their titles regardless, so maybe it's not worth considering).

Would there be support for changing how interview titles are cited to use quotation marks instead of italics? (I did note Help talk:Citation Style 1/Archive 5#The "title" parameter in the Cite interview, which seems to work around a local issue and which happens to use the italics as a feature, not a bug, but as cite interview is only used about 3k times, I doubt that we couldn't fix them locally as necessary.) --Izno (talk) 22:46, 27 August 2016 (UTC)

Yeah, should be quotation marks. The major work in which the interview is published gets the italics.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:14, 28 August 2016 (UTC)

Google Books and page URLs

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Redundant thread; my bad.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:13, 28 August 2016 (UTC)

---

Moved to #About WP:PAGELINK

User Mauro Lanari (talk), at 02:06, 25 August 2016 (UTC), opened a WP:TFD about {{Cite book}}, and it was speedily closed as being in the wrong venue. As a procedural matter, I'm posting it to the correct one for him, in slightly clarified wording, though I haven't formulated a firm opinion about it myself:

About WP:PAGELINK: The problem seems to have arisen nearly 6 years ago, when it was decided to link Google Books pages in a way that distorts the purpose of |titleurl=, rather than adding a |pageurl= parameter to go along with |titleurl= and |chapterurl=. Since then, |titleurl= can also no longer be addressed to the front cover of a Google Book. Personally I [Maura Lanari] solve this by placing a link in the page or quote parameter, but some editors disagree and revert me. I mean, what do you think of updating the template {{cite book}}?

For Mauro Lanari (talk)  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:05, 28 August 2016 (UTC)

• For my part, I'm uncertain we have an encyclopedic need to link to the front of a Google Book when citing a page in it. Most of us do not use |titleurl= but |url= (I didn't even know |titleurl= existed). A possible solution would be to enable a |pageurl=, and treat |url= as an alias of it if a separate |titleurl= is given, but otherwise treat |url= as synonymous with |pageurl=. A problem with treating any Google Books |url= as a |pageurl= is that people expect to see the title linked, not a tiny page number, and another is that we'd need the Lua to parse for books.google.com URLs in particular.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  06:05, 28 August 2016 (UTC)
  • @SMcCandlish: look at #About WP:PAGELINK above. He started another discussion here at about the same time. Imzadi 1979 → 06:23, 28 August 2016 (UTC)

  There is no |titleurl= to know about:

  Title. {{cite book}}: Unknown parameter |titleurl= ignored (help)

  —Trappist the monk (talk) 08:35, 28 August 2016 (UTC)

Okay!  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  09:13, 28 August 2016 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Porting into another wiki with localisation

I've tried to port the module code into the local wiki and found out that the $1 value in element 'mult_names' in this module may not be localisable. Is anyone know how to localise the value for that? (typically the $1 maybe "authors list", "editors list" or similar.) Shinjiman ⇔ ♨ 05:58, 30 August 2016 (UTC)

I think that you need to better explain what the problem is. What and where is the local wiki? Does the module properly render author lists, editor lists?

—Trappist the monk (talk) 09:41, 30 August 2016 (UTC)

Forgot to mention the module would be modified was listed in zh-yue:Module:Citation/CS1/Configuration. And seems by the current code, the category name which cannot be localised (like that one listed below). :D Shinjiman ⇔ ♨ 14:00, 30 August 2016 (UTC)

['mult_names'] = 'CS1 maint: Multiple names: $1', -- $1 is authors or editors

As an experiment, I've created a special_case_translation table in Module:Citation/CS1/Configuration/sandbox, provided the English words that replace $1 in the category names for mult_names and disp_auth_ed, and made the appropriate changes to extract_names(), name_has_mult_names(), and get_display_authors_editors():

Cite book comparison

Wikitext	{{cite book|author=blue, black, brown|title=Title}}
Live	blue, black, brown. Title.{{cite book}}: CS1 maint: multiple names: authors list (link)
Sandbox	blue, black, brown. Title.{{cite book}}: CS1 maint: multiple names: authors list (link)

Cite book comparison

Wikitext	{{cite book|author2=black|author3=brown|author=blue|display-authors=6|title=Title}}
Live	blue; black; brown. Title. {{cite book}}: Invalid |display-authors=6 (help)
Sandbox	blue; black; brown. Title. {{cite book}}: Invalid |display-authors=6 (help)

Does this work in your application?

—Trappist the monk (talk) 15:42, 30 August 2016 (UTC)