Help talk:Citation Style 1

{{cite bioRxiv}}

Could someone help create this?

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

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

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

Hi Headbomb, I'm not sure I understand the added value of these specific templates… Isn't it enough to use the |biorxiv= parameter with an existing CS1 template? The same holds for citeseerx below. − Pintoch (talk) 17:44, 16 February 2017 (UTC)

This, like {{cite arxiv}} would do two things. It specifically identifies the publication as a preprint, and which would facilitate the bot-maintenance of these templates and general cleanup of the citations. Right now, there's a lot of people doing citations to biorxiv preprints like this (the first is done by putting the URL in the reftoolbar and letting the gadget complete it

• Navarrete, Israel; Panchi, Nancy; Kromann, Peter; Forbes, Gregory; Andrade-Piedra, Jorge (15 February 2017). "Health quality of seed potato and yield losses in Ecuador". bioRxiv. p. 108712. doi:10.1101/108712.

Which is not how bioRxiv preprints should be cited. They should be cited as

• Navarrete, Israel; Panchi, Nancy; Kromann, Peter; Forbes, Gregory; Andrade-Piedra, Jorge (15 February 2017). "Health quality of seed potato and yield losses in Ecuador". bioRxiv 108712. {{cite web}}: Check |biorxiv= value (help); Missing or empty |url= (help)

You might argue that this can be already be achieved with existing templates like {{cite web}} and {{cite journal}}, but using those templates misleads people into filling unnecessary and undesired parameters.

And if you try letting citation bot expand the doi in a cite journal, you get

• . doi:10.1101/108712 (inactive 2017-02-16). {{cite journal}}: Cite journal requires |journal= (help); Missing or empty |title= (help)CS1 maint: DOI inactive as of February 2017 (link)

This seems to be generalized to all biorxiv dois, but might be a temporary database issue. However, I have no faith that the crossref information would not polute the citation with extraneous and unecessary information, like putting CSHL as the publisher, biorxiv as the journal, and similar. It would also highjack the doi parameter which should be used for the official version, once published. Headbomb {talk / contribs / physics / books} 17:58, 16 February 2017 (UTC)

Makes sense, thanks for the explanation! − Pintoch (talk) 18:12, 16 February 2017 (UTC)

@Pintoch, Trappist the monk, and Jonesey95: can any of you code this? I would, but I know nothing of LUA. I could hack something via an invocation of cite web, but I'd rather not. Headbomb {talk / contribs / physics / books} 12:18, 22 February 2017 (UTC)

Of course, but is there consensus to add yet two more cs1 templates with attendant error messages and categories, documentation, etc?

If the decision is taken to create these templates as cs1 templates, there is a side benefit in that it will force me to finally do the unsupported arXiv parameter test properly because these two templates will require the same sort of error detection.

—Trappist the monk (talk) 12:28, 22 February 2017 (UTC)

The only argument against them really is "but that's more templates to deal with", and I think I've shown pretty conclusively that using the existing ones create lots of issues in the long term, while lots of benefits would come from a dedicated template like {{cite arxiv}}. We might need a {{cite SSRN}} too, but I haven't looked into them much. Headbomb {talk / contribs / physics / books} 12:34, 22 February 2017 (UTC)

Any progress on this? Headbomb {talk / contribs / physics / books} 16:37, 1 March 2017 (UTC)

@Trappist the monk:? Headbomb {talk / contribs / physics / books} 09:41, 22 March 2017 (UTC)

Is there a consensus to add this template to cs1? Of all the editors who monitor this talk page (234 at this writing) only three have had anything to say here. If I read this topic correctly, you are the only editor who has expressed support for it.

—Trappist the monk (talk) 13:51, 22 March 2017 (UTC)

{{cite arxiv}} exists, this one (as well as {{cite citeseerx}}) is no different. I have shown a need for it, and no one objects. We don't need RFCs for every single incremental upgrade to the CS1 suite of templates. The only reason I haven't created it myself is because I can't write in LUA. I could have half-assed a {{cite journal}} wrapper for it, and only allow a few basic parameters, but I'd much rather have proper support from the start go. Headbomb {talk / contribs / physics / books} 14:41, 22 March 2017 (UTC)

Created. Both need documentation which I shall leave to others.

—Trappist the monk (talk) 16:52, 26 March 2017 (UTC)

Thanks! We might need a {{cite SSRN}}: Empty citation (help) in the future, but right now I don't understand the SSRNs system well enough to be sure that it's needed, or what should or shouldn't be allowed for parameters if there is a need for it. I'll be focusing on biorxiv/citeseerx cleanup for now (and I'll create documentation for them later this week). Headbomb {t · c · p · b} 08:50, 27 March 2017 (UTC)

@Trappist the monk: When using {{Cite biorxiv | last1 = Goldberg|first1 = Amy |display-authors=etal. |year=2016 |title=Familial migration of the Neolithic contrasts massive male migration during Bronze Age in Europe inferred from ancient X chromosomes|biorxiv=078360}}, the title gets italicized.

• Goldberg, Amy; et al. (2016). "Familial migration of the Neolithic contrasts massive male migration during Bronze Age in Europe inferred from ancient X chromosomes". bioRxiv 078360. {{cite bioRxiv}}: Check |biorxiv= value (help)

It should be put in quotes. Similarly, |journal= seems to be allowed (see above for the list that should be allowed), and it shouldn't be. There the . at the end of the citation can also appear on a different line, but that may be a wider issue related to access locks and dots.Headbomb {t · c · p · b} 02:36, 8 April 2017 (UTC)

{{cite biorxiv}} does not yet exist; {{cite biorxiv/new}} does:

{{Cite biorxiv/new | last1 = Goldberg|first1 = Amy |display-authors=etal. |year=2016 |title=Familial migration of the Neolithic contrasts massive male migration during Bronze Age in Europe inferred from ancient X chromosomes|biorxiv=078360}}

Goldberg, Amy; et al. (2016). "Familial migration of the Neolithic contrasts massive male migration during Bronze Age in Europe inferred from ancient X chromosomes". bioRxiv 078360. {{cite bioRxiv}}: Check |biorxiv= value (help)

this is true because the live module does not yet support {{cite biorxiv}}; still waiting for template documentation.

—Trappist the monk (talk) 03:01, 8 April 2017 (UTC)

Ah I see. I was waiting for it to go live before creating the doc, but I suppose I could do that now. Headbomb {t · c · p · b} 03:11, 8 April 2017 (UTC)

Done. I hope I haven't screwed up. Headbomb {t · c · p · b} 03:27, 8 April 2017 (UTC)

quick query from a by-stander: should the template output some sort of indication of the name of the website or the publisher of the website that's hosting these articles beyond the bioRxiv identifier number? I understand what it is from clicking on the ID number, but maybe we could give just an extra clue for our readers? Imzadi 1979 → 06:10, 8 April 2017 (UTC)

I suppose that's possible, but I based it on {{cite arxiv}}, which doesn't do that since website/publisher is obvious (it's the arxiv repository). Likewise for bioRxiv, it's hosted on the bioRxiv repository. The only difference between the two is bioRxiv is relatively new and only starting to pick up steam (at a very impressive rate too). The real question is how are bioRxiv entries usually cited in the literature? We should follow that, but I suspect biology treats them the same way as physics/astronomy treats arxiv citations. Headbomb {t · c · p · b} 14:28, 8 April 2017 (UTC)

Access locks on paywalled links: lock color and hover text

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

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

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

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

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

Thoughts?

Kind regards, —Unforgettableid (talk) 02:30, 22 February 2017 (UTC)

The dark red fails one of the criteria we established for the icon designs, to wit: contrast against both white and black backgrounds. This is important for the visually impaired and for those who invert their colors (light text on a dark or black background).

As part of the initial discussions I proposed a series of icons that were all blue; access indicated by the lock shape only. That idea was shot down because others believed that multiple indications of access (shape and color) are better than the single (shape alone).

Before continuing this conversation, might I recommend that you spend some time in the archives of this page reading the discussions that got us to where we are today? I think that the bulk of it begins in Archive 22.

—Trappist the monk (talk) 03:54, 22 February 2017 (UTC)

Dear Trappist: The problem with the old dark-red access lock icon is that it had a transparent background. This made it nearly invisible when the icon was superimposed upon a black webpage. I see four possible workarounds: A) Underlay a white rectangle beneath the dark-red lock. B) Or a white rounded rectangle. C) Or a white oval. D) Or add a thick white outline to the dark-red lock. Even three or four pixels thick, if you want. —Unforgettableid (talk) 02:51, 23 February 2017 (UTC)

Sure, those are work-arounds. But, neither you nor I have the power to change that which was decided by RFC, do we? Without another RFC that overrides the current consensus, the access signals shall have the forms and colors that were determined by the visual design RFC.

—Trappist the monk (talk) 03:56, 23 February 2017 (UTC)

In that RFC, Headbomb offered a choice of multiple colors for the free-access lock and the partial-access lock. But the only color choice he offered for the paywall lock was bright red. (In other words, bright red was the only choice available on the ballot.) Because the ballot offered no choice in the matter, I believe it might be inaccurate to say that the RFC participants agreed to make it bright red. I believe it'd be more accurate to say that the lock ended up bright red by default. —Unforgettableid (talk) 04:27, 23 February 2017 (UTC)

Only one color was offered for the free access lock, green. The only one where there was a choice was the partial access lock, yellow vs blue which left very few people happy. I personally believe Green/Grey/Red will gain support the next time we ask, but it's possibly Green/Grey/Grey will get it too. Green/Blue/Red is a a truly ridiculous scheme that makes zero sense, and people only went for it because the yellow was felt 'not yellow enough' or WP:ACCESS unfriendly. Headbomb {talk / contribs / physics / books} 04:54, 23 February 2017 (UTC)

Look also at the post timestamped at "22:42, 10 February 2017 (UTC)" on this page for possible alternatives, some of which include gray. Headbomb {talk / contribs / physics / books} 12:17, 22 February 2017 (UTC)

That gray is fine, though I still suspect that I prefer dark red. —Unforgettableid (talk) 02:51, 23 February 2017 (UTC)

The dark red would still violate WP:ACCESS. Headbomb {talk / contribs / physics / books} 04:46, 23 February 2017 (UTC)

I've thought of some possible workarounds, and described them, in a comment which you probably haven't read yet. Search through this page for the phrase [ four possible workarounds ] if you'd like to learn about them. I believe that, with the workarounds, dark red is a viable option. —Unforgettableid (talk) 05:52, 23 February 2017 (UTC)

Those aren't viable workarounds. A white rectangle underneath the lock for instance, would look downright awful and be very distracting. Likewise for the other choices. Headbomb {talk / contribs / physics / books} 10:29, 23 February 2017 (UTC)

A) How about a thin white outline, perhaps one pixel thick or a few pixels thick? B) What percent of our readers view Wikipedia on a black background? I suspect that it's a tiny percentage. Shouldn't we care more about making things look nice for the majority than for the minority? —Unforgettableid (talk) 14:39, 24 February 2017 (UTC)

The colors and shapes of the access signals lock was decided by the visual design RFC. Must I repeat myself? Neither you nor I have the authority to arbitrarily overturn such a decision. The number of readers who use an inverted color scheme is irrelevant; those who do deserve to be accommodated if it is possible to do so.

—Trappist the monk (talk) 11:17, 8 March 2017 (UTC)

One thing we could possibly add to the hover text is "Paid subscription required, abstract or excerpt may be available" instead of just "Paid subscription required". Headbomb {talk / contribs / physics / books} 12:44, 22 February 2017 (UTC)

Dear @Headbomb: Good idea. In fact, maybe we could provide even more alt text than that. Perhaps this: "A summary or excerpt may be available for free. However, to read the full text, you must either buy access or visit a library with a paid subscription. Try phoning your nearest university library." In addition, perhaps we could even add a dotted underline and a fancy cursor. border-bottom: 1px dotted #000; cursor: help; This would help readers realize that there's useful alt text, and that they should wait a second for it to appear. You can see a live preview of the full package at this link. —Unforgettableid (talk) 02:51, 23 February 2017 (UTC)

That is a ridiculously long message. 'Paid subscription required, abstract or excerpt may be available' covers all of that. I'm not against the cursor/underlining though. Headbomb {talk / contribs / physics / books} 04:45, 23 February 2017 (UTC)

Both you and I have been to university. Also, both you and I both know that we can get free online access to many papers at a university library. But many laypeople don't know this. In fact, even some university graduates don't know this. For those in the know, we're wasting their time by writing so much hover text. But these people can quickly learn what the paywall lock means. They can read the hover text once, understand it, and never feel a need to hover their mouse over a paywall lock ever again. But, for high-school students and other individuals not in the know, we may be opening their eyes (maybe for the first time ever) to vast trove of scholarly knowledge. —Unforgettableid (talk) 06:09, 23 February 2017 (UTC)

It's not a matter of having been to university or not, it's a matter of the message being exceedingly long. This is a message that will need to be read by screen readers several times per article, and thus needs to be short. This is why all the messages are short and to the point, e.g. "Free registration required" instead of "You are required to register to read this article, but it does not cost money to do so. Websites will typically asks for your email and some personal information. You could also ask a friend to register for you, or register with a dummy email if you do not trust the website with your personal information, however this may violate their terms of service. Your password and login information might be stored in a cookie. That being said, an excerpt might still be available to unregistered users."

"Paid subscription required" implies a subscription is required to have access to the full version; it doesn't matter if it's yours, your supervisor's, your friend's or the library's institutional subscription. If you have short wordings, those could be suitable however. But they need to be short, e.g. "Paid or library subscription required, free abstract or excerpt may be available". Headbomb {talk / contribs / physics / books} 10:29, 23 February 2017 (UTC)

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

Locks aren't currently clickable and aren't linked to anything. Where would clicking on the lock take people? Headbomb {talk / contribs / physics / books} 19:29, 23 February 2017 (UTC)

There need not be anything clickable for a title= attribute to be used; it is valid on most HTML elements since HTML 4.00, and all elements from HTML5 onward. From the HTML 4.01 spec:

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

Try hovering your mouse here. --Redrose64 🌹 (talk) 20:09, 23 February 2017 (UTC)

Re "There need not be anything clickable". The proposed message has "click for help". That's what I'm referring to. Headbomb {talk / contribs / physics / books} 20:38, 23 February 2017 (UTC)

Clicking on the paywall lock could take readers to Wikipedia:Find your source. Would this work? —Unforgettableid (talk) 14:48, 24 February 2017 (UTC)

MediaWiki copies the image's alt= attribute text into the title= attribute. No need to muck with title= attributes and no need for the image to be clickable.

—Trappist the monk (talk) 20:17, 23 February 2017 (UTC)

Not true: consider the twelve images in Headbomb's post of 22:42, 10 February 2017 (UTC) beginning "No, we unrestrict their use on identifiers and urls" in the section #Whatever happened to the access lock RFCs? - here, all twelve images have the alt= attribute, and none of them have a title= attribute. --Redrose64 🌹 (talk) 21:58, 23 February 2017 (UTC)

I think that we are both mistaken. Your mistake: none of those twelve images have alt= attributes – though some have 'alt' in their name:

[[File:Lock-blue-alt-2.svg|9px]] →

My mistake: MediaWiki does not copy alt= into title=. Rather, it is done in Module:Citation/CS1/Configuration where the lock images are defined like this:

[[File:Lock-green.svg|9px|link=|alt=Freely accessible|Freely accessible]] →

where the text to the right of the pipe is assigned to the title= attribute.

—Trappist the monk (talk) 23:09, 23 February 2017 (UTC)

They do have alt= attributes. Use your browser's "View page source" feature. Search for the text <img alt="Lock-green.svg" src="//upload.wikimedia.org/wikipedia/commons/thumb/6/65/Lock-green.svg/9px-Lock-green.svg.png" You should find six instances, other than the one in this post. All six are identical: the <img /> tag has seven attributes, being (some values replaced with an ellipsis for clarity) alt="Lock-green.svg" src=... width="9" height="14" srcset=... data-file-width="512" data-file-height="813". There is an alt= attribute; there is not a title= attribute. The enclosing <a href="/wiki/File:Lock-green.svg" class="image">...</a> element doesn't have a title= either. --Redrose64 🌹 (talk) 01:33, 24 February 2017 (UTC)

So they do. MediaWiki copies the image file name into the alt= attribute. Better that than nothing I suppose.

—Trappist the monk (talk) 11:12, 24 February 2017 (UTC)

The documentation implies that Links inserted by identifiers such as |doi= are not expected to offer a free full text by default So I am expecting the subscription will be set to yes by default if one of these is set. But it isn't. Hawkeye7 (talk) 21:20, 10 March 2017 (UTC)

If you mean that the template sets |subscription=yes if |doi= or other identifier is set, then no, that does not happen. The problem with |subscription= is that it doesn't specify which external link, |url= or one of the identifiers – there can be multiples – requires the subscription. As the code stands now, it assumes, correctly, that most identifiers (like |doi=) rarely offer free access to the source. We do not highlight the norm. When |doi= refers to a source that is free-to-read, editors may add |doi-access=free to highlight that identifier. There are exceptions: a couple of identifiers are automatically flagged because it is known that these identifiers are always free-to-read (|arxiv=, |rfc=, etc). In the same sense, |url= and |chapter-url= and their aliases are assumed to be free-to-read. Again, we don't hightlight the norm but when these are not free-to-read, editors may set |url-access=subscription, etc.

—Trappist the monk (talk) 21:48, 10 March 2017 (UTC)

But a |doi= card does not trigger a "subscription required" note, nor does a |jstor= card; so |doi-access=free is the default. Hawkeye7 (talk) 23:07, 10 March 2017 (UTC)

What is card?

No, |doi-access=free is not the default because we do not highlight the normal state, either with an icon or with text. For most identifiers the links normally link to sources behind a registration or subscription wall. Because of this, there is no need to clutter the rendered citation with extraneous access signals.

—Trappist the monk (talk) 23:17, 10 March 2017 (UTC)

Adding a license parameter

Issues around indicating the accessibility of a cited reference have been discussed repeatedly here (example 1; example 2), usually with a focus on free availability rather than open licensing. However, with more and more scholarly journals — including many megajournals — now using CC BY and other Creative Commons licenses (not only open ones), perhaps adding a |license= parameter to the citation template would be a good way to go.

Initially, it would probably make sense to restrict this to standard copyright licenses, say the seven regularly used Creative Commons licenses (in which CC0 — technically a license waiver — was included) plus public domain. In order to display the information, the respective license icon could be used, which could link to the license text:

• Petraglia, Michael D.; Ashton, Nick; Lewis, Simon G.; De Groote, Isabelle; Duffy, Sarah M.; Bates, Martin; Bates, Richard; Hoare, Peter; Lewis, Mark; Parfitt, Simon A.; Peglar, Sylvia; Williams, Craig; Stringer, Chris (2014). "Hominin Footprints from Early Pleistocene Deposits at Happisburgh, UK". PLoS ONE. 9 (2): e88329. doi:10.1371/journal.pone.0088329. ISSN 1932-6203. PMC 3917592. PMID 24516637.{{cite journal}}: CS1 maint: unflagged free DOI (link) 

-- Daniel Mietchen (talk) 12:50, 16 March 2017 (UTC)

The purpose of a citation (any, not just cs1|2) is to identify the source material that supports article text in accordance with WP:V. The purpose of the access signalling icons is to make it easier for readers to know of the linked sources in a citation are free-to-read or which lie behind registration or paywall. The licensing of the source does not aid the reader who seeks to read the source. Wikipedia should not be responsible for labeling citations with license status when that is the responsibility of the source's publisher. If readers and editors wish to reuse source material, they should consult the source's publisher and not rely on an icon attached to a Wikipedia citation.

—Trappist the monk (talk) 14:39, 16 March 2017 (UTC)

Trappist said basically what I was going to say, but more eloquently. The copyright or copyleft status of an on-line source has no effect on whether the reader will be able to find or read it. – Jonesey95 (talk) 17:02, 16 March 2017 (UTC)

Hi Daniel Mietchen, I'm a bit late on the party but I want to emphasize the fact that if you want to push for this, the first thing to do is to make sure that people outside our bubble of open-* advocates support the idea. Otherwise you'll face some backlash sooner or later. While I tend to agree with Trappist and Jonesey95, the opinion of the few people watching this page does not matter (well, in theory). I think we need a lot more work of educating editors, readers and researchers about open licenses before consensus for such a signaling can happen, but I would love to be proved wrong. − Pintoch (talk) 18:58, 29 March 2017 (UTC)

I personally favor the idea of signalling a license for references, especially when we have tools like oaDOI that can provide API for that. What I think is most important, though, is "free-to-read"-ness. I have an hard time understanding if there is a consensus here: what do you think about that? My bias of course is towards open access and open access sources (I'm a digital librarian and I think there would be a lot of advantages to have some sort of system here on Wikipedia). Aubrey (talk) 12:18, 6 April 2017 (UTC)

Both of the external links that you provided are the same. Did you intend that?

—Trappist the monk (talk) 12:35, 6 April 2017 (UTC)

Wholeheartedly Support! I use NYPL databases that are closed access all the time -- I have been wanting to have a better option than subscription required for a long time. So I fully embrace this very elegant and clear option to note open and closed access to these entries that require paywall access. There's a huge advantage to being able to see a lock and unlock symbol on citations. I fully embrace this usage and will be using it going forward. I think that especially for DOI type items this is a no-brainer and can only be a positive thing for citations on en Wikipedia especially.

As to this not being Wikipedia's job, I disagree completely. The Wikipedia editor's job is to create a full citation, in my opinion. Access information -- especially closed access -- is a natural and necessary part of this process. The creation of citations is curation, and how this information is accessed is a huge part of this. And it _does_ have a huge impact on how a reader uses the citation. Readers are in a hurry and respond to icons like this. I know that the PDF icon is a huge improvement when I am sussing out citations. To think otherwise I think is very disingenuous and wrong. Totally disagree. I KNOW it's part of my responsibility as an editor who creates citations. I am obsessed with citations and this access issue is a big deal, especially for an end-user. And that's what the information is there for, isn't it?

I would like to also advocate that this field is built into the WikiMarkup Template:Cite journal as well as being an option in the WikiMarkup Template:Cite news -- as these have been the places where I have seen the most restricted access.

Best, Erika aka BrillLyle (talk) 13:31, 6 April 2017 (UTC)

@BrillLyle: This thread is nothing to do with open or closed access (whether you need to go through some sort of registration/login process in order to view the source material). It concerns the licensing of the source - that is, licensing in the same sense that we use CC BY-SA and so on. --Redrose64 🌹 (talk) 14:18, 6 April 2017 (UTC)

@BrillLyle: I am perplexed. This topic is about adding licensing icons (perhaps like those found at Creative Commons license) to cs1|2 templates. I am the editor who wrote that Wikipedia should not be responsible for labeling citations with license status. You appear (to me anyway) to be talking about, and supporting, the access-signalling icons that cs1|2 now supports. Can you clarify?

—Trappist the monk (talk) 14:23, 6 April 2017 (UTC)

Licensing is not a referencing or verifiability concern. If anywhere, it'd belong in Wikidata. Open access signaling, however, is much desirable, and definitely within the scope of CS1|2 templates. Headbomb {t · c · p · b} 14:55, 6 April 2017 (UTC)

External link in title

Wikipedia contributors. "Wikipedia:Archive.is RFC 4". English Wikipedia. Wikimedia Foundation. Retrieved March 29, 2017. {{cite web}}: |author= has generic name (help)

In this case, how can I resolve this error?--Namoroka (talk) 06:26, 29 March 2017 (UTC)

To Module:Citation/CS1, Wikipedia:Archive.is looks like a scheme (Wikipedia:) followed by a domain name (Archive), a separator (.), and a top level domain (is); a very common description of a URL. You can get round this error message by wrapping that part of the title (or the whole title, doesn't matter) in <nowiki>...</nowiki> tags:

{{cite web|author=''Wikipedia'' contributors|title=<nowiki>Wikipedia:Archive.is</nowiki> RFC 4|url=https://en.wikipedia.org/wiki/Wikipedia:Archive.is_RFC_4|website=[[English Wikipedia]]|publisher=[[Wikimedia Foundation]]|access-date=March 29, 2017}}

Wikipedia contributors. "Wikipedia:Archive.is RFC 4". English Wikipedia. Wikimedia Foundation. Retrieved March 29, 2017. {{cite web}}: |author= has generic name (help)

—Trappist the monk (talk) 10:25, 29 March 2017 (UTC)

The real way to fix this problem is to cite a secondary source and not a primary source. --Izno (talk) 12:34, 29 March 2017 (UTC)

That depends for what you want to cite this. Primary sources are quite often acceptable. Headbomb {t · c · p · b} 14:40, 29 March 2017 (UTC)

ISBN wrapping

Hi, when spaces are used in ISBN numbers, the number can be split over lines as it is allowed to wrap. Should the templates be modified to use {{nowrap}} or should we deprecate spaces in ISBN numbers and always go with dashes? If the latter then we would need to track those ISBNs using the space format so that they could be converted. Keith D (talk) 23:50, 30 March 2017 (UTC)

This thread reminds me of a related conversation at Template talk:ISBN from January 2017 and a previous conversation at Template talk:ISBNT from September 2016. It looks like there was a desire for consistency among the templates and also varying behavior among web browser software.

In the meantime, feel free to play with your browser's window size at this revision of my sandbox page. When I shrink my (Firefox) window, both {{ISBN}} and {{cite book}} freely wrap the ISBN value when it has spaces in it but keep the identifier whole when it has hyphens in it. So at least they are consistent. – Jonesey95 (talk) 02:54, 31 March 2017 (UTC)

• Actually, I think ISBNs should be allowed to wrap on hyphens -- they frequently cause very unsightly bad breaks (but not spaces -- too confusing). EEng 03:04, 31 March 2017 (UTC)

When used in cs1|2, |isbn=123-4567-89X is translated to this:

[[International Standard Book Number|ISBN]] [[Special:BookSources/123-4567-89X|123-4567-89X]]

which MediaWiki translates to:

<a href="/wiki/International_Standard_Book_Number" title="International Standard Book Number">ISBN</a>&#160;<a href="/wiki/Special:BookSources/123-4567-89X" title="Special:BookSources/123-4567-89X">123-4567-89X</a>

As you can see, there is no special treatment of the ISBN link with regard to wrapping except that we connect the label to the first group of digits in the number with a   character. I use Chrome so the ISBNs on Editor Jonesey95's sandbox page wrap at both hyphen and space separators. It makes me wonder if Firefox also doesn't wrap multi-word hyperlinks or if ISBNs are a special case. What about ISSNs? DOIs? or other identifiers when they have hyphens? The module does not protect any of these from wrapping.

The module does nowrap the rendering of |access-date= and at the next update will insert   (narrow no-break space) between an access signal icon and its identifier.

—Trappist the monk (talk) 10:07, 31 March 2017 (UTC)

They're hyphens, not dashes. In an ISBN, a space is no more or less valid than a hyphen; you will find books with both forms, even to the point of inconsistency between what is shown on the copyright page and what is on the back cover. We must not instruct people to only use hyphens. --Redrose64 🌹 (talk) 11:05, 31 March 2017 (UTC)

May be we could just convert the spaces in the ISBN to the   character to stop it wrapping inappropriately. Keith D (talk) 23:44, 31 March 2017 (UTC)

No, non-breaking spaces are not valid. It's plain spaces or hyphens. --Redrose64 🌹 (talk) 07:28, 1 April 2017 (UTC)

Preference between year or date parameter in Cite Journal

@Headbomb: According to the Template documentation, the date parameter is preferred. Also, simply putting just the year in the date parameter serves the same purpose. TemplateData is only relevant to VE. I do not see the problem in suggesting date in VE.  —አቤል ዳዊት^?(Janweh64) (talk) 09:27, 31 March 2017 (UTC)

In the edit summary of this edit, you claim that the template documentation says: "Listing only the publications year is recommended." Where does it say that? I know of no such recommendation.

—Trappist the monk (talk) 10:54, 31 March 2017 (UTC)

I was only trying to appease Headbomb who suggests that year is recommended for journals. I prefer date. I was only showing a willingness to compromise.

As I understand it, year is only necessary and recommended under the special case where date format is ymd and therefore can not be used with a CITEREF diambiguator. —አቤል ዳዊት^?(Janweh64) (talk) 11:02, 31 March 2017 (UTC)

I don't have time to review the whole argument or the specifics of the 'solution', I'm just saying that for journal and books, standard practice (and recommendation by most style guides) is to only use the year, not the full date. Encouraging use of the date parameter means that people will feel compelled to use the full date for things. We already have enough issue with the various tools trying to fill citations with complete dates. Headbomb {t · c · p · b} 11:13, 31 March 2017 (UTC)

I agree with Headbomb. I don't understand why Template:Cite journal/doc#Date says Use of |date= is recommended unless all of the following conditions are met:. What is the advantage of putting |date=2017 over |year=2017? The disadvantage is that it encourages the addition of wholly unnecessary month and day information where these are not needed and are not standard practice for journals. Newspapers, magazines, sure, but not scientific journals. Peter coxhead (talk) 11:28, 31 March 2017 (UTC)

I can't answer to the reasoning behind why the template doc suggests date. I frankly don't care either way. My issue is that for most recent journals published the auto citation fill feature recognizes the full date and fills in the full date parameter. When you go in to edit the cite journal in VE the year param pops back in and you have to delete it. Right now empty |year= are being inserted everywhere when someone uses VE.

The solution to all this is simple have the Cite journal template convert the date and display only the year, even when user gives full date. While suggesting date, that is.  —አቤል ዳዊት^?(Janweh64) (talk) 11:39, 31 March 2017 (UTC)

We shouldn't be making up rules, or even reformatting dates. Our only rule should be "use the cover date". If the journal states "March 2017", then we should not encourage people to use anything other than |date=March 2017. Do not tell them to remove the month; do not suggest that they should add a day-of-month that isn't actually there. Some journals - such as Nature - do have full dates, and we must not discourage those. --Redrose64 🌹 (talk) 11:41, 31 March 2017 (UTC)

We certainly ought to. In as much as virtually all styles guides recommend omitting full dates for books and journals. Headbomb {t · c · p · b} 11:43, 31 March 2017 (UTC)

The key word in that quote is all (of those conditions). YMD date format does not allow for a disambiguator: |date=YYYYa-MM-DD is not allowed. When it is necessary to disambiguate a cs1|2 citation that uses YMD date format, the disambituator is attached to |year=YYYYa so editors can use |date=YYYY-MM-DD if they choose to do so. If only the year portion of a date is used, then editors may use either of |year= or |date= as they choose because Module:Citation/CS1 treats them as aliases of each other (there is no difference between |date=2017 and |year=2017).

I think that the notion that cs1|2 templates should be written preferring the use of year-only publication dates is a new topic. Certainly I do not recall seeing it raised before. If there has been previous discussion, here or elsewhere, please give us some links to those discussions.

—Trappist the monk (talk) 12:03, 31 March 2017 (UTC)

I admit my 14th edition of the Chicago Manual is getting a bit old, but page 570 indicates that either the month/season, or the issue number, may be used in bibliography entries, if there are issue numbers available. Not all journals number their issues. I believe these are the ones that use continuous paging throughout the year, so the January issue starts with page 1, the February issue starts with page 189, etc.

Example from Chicago Manual 14th ed. p. 570

Bush, Jane R. "Rhetoric and the Instinct for Survival." Political Perspectives 29 (March 1990): 45–53.

Jc3s5h (talk) 13:27, 31 March 2017 (UTC)

• MLA omits full dates for periodicals, even magazines/newspapers, unless you are interested in the historical details.
• May omit in Chicago. In my experience, most journals following Chicago omits them.
• May omit in Vancouver. In my experience, most journals following Vancouver omits them, or only include the month.
• In all cases, books only get years. Headbomb {t · c · p · b} 13:47, 31 March 2017 (UTC)

None of the links Headbomb provided indicate that if a journal publishes several physical issues per year, but dates them with a month or season name and does not number the issues, that it would be ok to omit the month or season from the citation. The citation should lead the reader to the bound-together bundle of sheets of paper that are being cited, rather than leaving the reader to guess which of 12 bound-together bundles contains the pages the reader wants. Our documentation should not be written in a way that tells editors it's OK to omit the month or season when there is no issue number in the citation. (The Chicago link prompts for a user name and password so I don't know what that one says.) Jc3s5h (talk) 14:09, 31 March 2017 (UTC)

Look at the examples. "For example, Brain Res. 2002;935(1-2):40-6." (full date is 10 May 2002) or "Walter Blair, "Americanized Comic Braggarts," Critical Inquiry 4, no. 2 (1977): 331–32.]" (full date is Winter 2017) Headbomb {t · c · p · b} 14:59, 31 March 2017 (UTC)

These examples are not applicable because the issue number is available. Jc3s5h (talk) 15:49, 31 March 2017 (UTC)

These examples most certainly apply. None of them have the full date. Headbomb {t · c · p · b} 16:01, 31 March 2017 (UTC)

The examples do not apply. Let me give you a scenario. You want the right issue of the journal. You are requesting it from another library (for journals, the libraries would probably have a special arrangement). Or, the library has closed stacks and you can't go to the stacks to see which issue you want. The citation says "Jones, J. "April fool's day pranks", Old Fashioned Journal 8 (1875):335–7." Let us suppose that journal didn't assign numbers to its issues. By poking around, you determine that journal was published monthly, and the volume number was incremented once per year. You don't know which month to have sent to you, so you have to hope the librarians won't get upset with you if you waste their time and ask for all 12. Jc3s5h (talk) 17:29, 31 March 2017 (UTC)

You're telling us examples which come directly from their manuals of style, which show full dates being omitted, do not support the general idea that full dates may be omitted according to these manuals of style? Yeaaaaaaaaaaaaah no. Headbomb {t · c · p · b} 17:42, 31 March 2017 (UTC)

This sort of thing merely makes it harder for people for people to find out what the reference is - stripping the date is pure disruption and hinders the reader. There are too many citatations without sufficient information to be traceable already, without Citation Style 1 intentionally removing important information. For a large proportion of references date will be the primary way of identifying the issue - removing the identifier printed on the cover of a magazine or journal to replace it by an issue number which may be hidden inside is not sensible.Nigel Ish (talk) 22:45, 31 March 2017 (UTC)

Concur. Do NOT remove any true information that makes it easier for Wikipedia readers to verify citations, and therefore article claims. Fashion citation style around the policy requirement, not the opposite. With this in mind, treat the formatting of the relevant fields as verification metadata, not data. The verification data is the source's content. Therefore a journal date written in some format can be substituted with any other equivalent format that provides the same, or better, ease of verification. 50.74.121.43 (talk) 00:05, 1 April 2017 (UTC)

Information that makes verification easier is good. Removing it to comply with someone's idea of good style is not helpful. • • • Peter (Southwood) ^(talk): 04:30, 1 April 2017 (UTC)

My thoughts, and my editing practices are simple: use the date off the cover of the journal formatted to fit our MOS on dates (so an en dash, not a slash, etc) complete with the month or season, if specified, and if a journal issue has printed volume and issue numbers, include them too. More information, within reason, is beneficial to our readers who want to locate a source. Imzadi 1979 → 04:58, 1 April 2017 (UTC)

Scowiki localization problems

Tracked in Phabricator
Task T162406

Hi, I would like to know what I need to do to better localize CS1 on the Scots Wikipedia. For one, I would like to know how to make reference templates convert English dates put in the templates into Scots on the article (via sco:Module:Citation/CS1/Date validation). Also, I would like to know how to localize the languages to where pages would go into sco:Category:CS1 Swadish-leid soorces (sv). At the moment, they either go into an incorrect category (sco:Category:CS1 Swedish-leid soorces (sv)) or into the error category (sco:Category:CS1 maint: Unrecognised leid). I can't find where any language name localization takes place in any of the modules. So, what needs to be done? Thanks in advance. --AmaryllisGardener ^talk 01:33, 6 April 2017 (UTC)

The purpose of date validation has never been to be a translator. That functionality has never been supported nor has it, to my knowledge been suggested. Presumably such translation could be done. It might take some thinking to determine where and when that would best be done; during validation? After? I would guess that the proper place might be in sco:Module:Citation/CS1 in the if not is_set(error_message) then test where a call is made to a new function that spins through the date_parameters_list and makes the translation; perhaps with a variant of this:

string.gsub('June 17, 1994', '%a+', {['January']='Januar', ['February']='Februar', ['March']='Mairch', ['April']='Aprile', ['May']='Mey', ['June']='Juin', ['July']='Julie'}) (in Scots, August through December are the same as in English?)

I think that the language issue is not an issue with the module. Rather, I think that it is an issue with MediaWiki. I think that the magic word {{#language:}} uses the same code as mw.language.fetchLanguageName() – I get the same result when comparing the one with the other:

{{#language:sv|fr}} → suédois (French)

{{#language:sv|nl}} → Zweeds (Dutch)

{{#language:sv|sco}} → Swaidish (Scots)

{{#language:sv|tgl}} → Swedish (Tagalog)

Try these in the Scribunto debug console:

=mw.language.fetchLanguageName('sv', 'fr')

=mw.language.fetchLanguageName('sv', 'nl')

=mw.language.fetchLanguageName('sv', 'sco')

=mw.language.fetchLanguageName('sv', 'tgl')

MediaWiki may not support language translations for ISO 639-2 language codes (or perhaps only some, I don't know) so I suspect that it falls back on English when it doesn't know the target language. Perhaps you should pursue this topic at Phabricator.

—Trappist the monk (talk) 11:32, 6 April 2017 (UTC)

@Trappist the monk: I will bring it up at Phabricator. The MediaWiki not recorgnizing the correct language name was my biggest concern. Thank you for the response. --AmaryllisGardener ^talk 20:12, 6 April 2017 (UTC)

Wikimania 2017

I will be making (assuming my proposal is accepted) a presentation on Journals Cited by Wikipedia at Wikimania 2017, in Montreal.

If you are interested in attending, please sign up! Headbomb {t · c · p · b} 14:55, 7 April 2017 (UTC)

@Headbomb: Your "homepage or blog" link leads to a red link here. :D --Izno (talk) 15:12, 7 April 2017 (UTC)

Fixed. Thanks! Headbomb {t · c · p · b} 15:44, 7 April 2017 (UTC)

title_rem .. deadurl_rem etc..

[2] Came across these .. the article has more. Is it just someone's notes? -- GreenC 17:03, 7 April 2017 (UTC)

Don't know. None of those have ever been part of en.wiki's cs1|2 but may have come from some other wiki?

—Trappist the monk (talk) 17:07, 7 April 2017 (UTC)

Ok. -- GreenC 17:29, 7 April 2017 (UTC)

These were introduced by Allen4names in this series of edits in February 2016. --Izno (talk) 17:39, 7 April 2017 (UTC)

Can anyone remember...

Can anyone know how to manage these templates for volumes with publication dates spread over multiple years? (they're unusual, but early 20th century works sometimes had publication dates of 1910-1913, for example). I've done it once before, but can't remember where! Any advice gratefully received... Hchc2009 (talk) 08:12, 10 April 2017 (UTC)

Real life examples are almost always useful. It saves us from the need to contrive examples.

I think that it is true that, generally, each of the the several volumes of a multi-volume source should be treated as a separate source. The cs1|2 templates are not designed to render the necessary bibliographic details for a single source. So, best practice is, I think:

{{cite book |author=Author |title=Title |chapter=Chapter |pages=100–110 |date=1910 |volume=1}}

Author (1910). "Chapter". Title. Vol. 1. pp. 100–110. {{cite book}}: |author= has generic name (help)

{{cite book |author=Author |title=Title |chapter=Chapter |page=78 |date=1911 |volume=2}}

Author (1911). "Chapter". Title. Vol. 2. p. 78. {{cite book}}: |author= has generic name (help)

{{cite book |author=Author |title=Title |chapter=Chapter |pages=204, 223 |date=1912 |volume=3}}

Author (1912). "Chapter". Title. Vol. 3. pp. 204, 223. {{cite book}}: |author= has generic name (help)

{{cite book |author=Author |title=Title |chapter=Chapter |pages=xxiv, 31–33, 354 |date=1913 |volume=4}}

Author (1913). "Chapter". Title. Vol. 4. pp. xxiv, 31–33, 354. {{cite book}}: |author= has generic name (help)

—Trappist the monk (talk) 10:47, 10 April 2017 (UTC)

Or, for a single volume with a publication date that spans multiple years:

{{cite book |author=Author |title=Title |chapter=Chapter |pages=100–110 |date=1910–1913 |volume=1}}

Author (1910–1913). "Chapter". Title. Vol. 1. pp. 100–110. {{cite book}}: |author= has generic name (help)

That should work. Note the en dash. – Jonesey95 (talk) 14:41, 10 April 2017 (UTC)

Any update on doi-broken-date?

If anything, the doi should at the very least still link. Other improvements can wait/get more discussion, but the linking part should be easy to fix. Headbomb {t · c · p · b} 14:25, 11 April 2017 (UTC)

PMCID and the PMC prefix

I wanted to bring this topic back to the surface again. It was recently discussed at Help_talk:Citation_Style_1/Archive_30#PMC, which led to the creation of phab:T157152. This ticket concludes (and I agree) that what CS1 is doing is basically not following the guidelines for usage of PMCID usage. It is therefor a 'CS1'-problem that we should deal with at this level as well. I think we have two options, either make the 'input format' of the PMCID be more flexible (The lua code can easily be adapted to accept both) or cleanup PMCID additions with a bot. —TheDJ (talk • contribs) 15:14, 12 April 2017 (UTC)

It's a citoid bug, so fix citoid? Headbomb {t · c · p · b} 15:40, 12 April 2017 (UTC)

Mmm I see. [3] says format should be PMCID: PMC#####. We should follow suit then. Headbomb {t · c · p · b} 15:49, 12 April 2017 (UTC)

(The lua code can easily be adapted to accept both) Do we want to have output of "PMC PMC\d*" or "PMC \d*" in the event that we take that path? --Izno (talk) 15:59, 12 April 2017 (UTC)

Aside courtesy @Boghog: due to involvement on the phabricator task. --Izno (talk) 16:06, 12 April 2017 (UTC)

Izno, according to that documentation, the output should be PMCID: PMC0123456. Headbomb {t · c · p · b} 16:11, 12 April 2017 (UTC)

Which has little or no bearing on how we present the ID. I appreciate the fact that the ID is actually "PMC\d*", but that does not require us to present the ID as "PMC: PMC\d*" or even "PMC\d* rather than the current "PMC: \d*", and in fact I disfavor the former as being unnecessary at this time and the latter as being somewhat inconsistent with how we do present it presently. --Izno (talk) 16:29, 12 April 2017 (UTC)

The NIH guideline (e.g., PMCID: PMC2291284) is crazy. Why repeat PMC twice? As pointed out by Izno and Trappist, there is no reason that CS1/2 has to follow the NIH guideline. Even less reason why the parmeter value has to include PMC (e.g., |pmc=PMC2291284). Boghog (talk) 17:31, 12 April 2017 (UTC)

Not that crazy. Numbers without context are meaningless. By explicitly making the context part of the identifier, it's easier to scrape the web and find your numbers back (for starters). It's also not really uncommon. Many image database identifiers do the same thing for instance. —TheDJ (talk • contribs) 19:35, 12 April 2017 (UTC)

For consistency, we then should add the parameter names to all parameter values (e.g., |volume=volume298, |issue=issue1, |pages=pages59–70, |year=year2006, |doi=doi10.1016/j.ydbio.2006.06.013, |volume=volume4}. The context is provided by the parameter name (e.g., |pmc=2291284) and in wiki link in the rendered citation (PMC: 2291284). It is redundant to repeat the parameter name in the parameter value and the wiki linked database name in the database accession number. Boghog (talk) 19:46, 13 April 2017 (UTC)

For scraping Wikipedia for specific PMC ids, CirrusSearch works pretty well (e.g., insource:\pmc = \d+\). Boghog (talk) 20:33, 13 April 2017 (UTC)

That's the thing. For the PMID, the actual PMID is a pure number: e.g. 18183754. For the PMCID, the actual PMCID is not a pure number, it is e.g. PMC2990724. Headbomb {t · c · p · b} 19:55, 13 April 2017 (UTC)

QED. The NIH is internally inconsistent. Boghog (talk) 20:02, 13 April 2017 (UTC)

Headbomb {t · c · p · b} 20:22, 13 April 2017 (UTC)

the actual PMID is a pure number: e.g. 18183754 Just quoting you ;-) Boghog (talk) 20:37, 13 April 2017 (UTC)

I don't follow. PMIDs are in one format. PMCIDs are in another. It's like faulting ISBNs for not following the format of ISSNs. Headbomb {t · c · p · b} 20:39, 13 April 2017 (UTC)

Both ISSNs and ISBNs are ISO standards and neither requires that the parameter name be include in the parameter value. Hence ISSNs and ISBNs are internally consistent. PMIDs and PMCIDs are both issued by the US National Library of Medicine/National Institutes of Health and only the PMC requires that the parameter name be included in the parameter value. This is inconsistent. Boghog (talk) 20:51, 13 April 2017 (UTC)

ISSN is 8 characters. ISBN is 10 or 13. Clearly this is inconsistent. And no, the PMCID does not required the 'parameter name ' to be included in the parameter value. The name is PMCID, the value is PMC0123456. PMCID does not appear in PMC0123456 and even if it did, so what? Headbomb {t · c · p · b} 20:59, 13 April 2017 (UTC)

The letters "PMC" appear twice which is redundant. Boghog (talk) 21:03, 13 April 2017 (UTC)

cs1|2, claims to the contrary notwithstanding, is a style in its own right. cs1|2 takes cues from published style guides but is not beholden to those style guides. So it is with PMC. We have no obligation to make cs1|2 adhere to PubMed Central's preferred styling. Given the comments in phab:T157152 I think it unlikely that those who play in the internals of citoid are interested in a citoid solution to the problem. That leaves it to us. We can tweak the module to accept PMC values with the redundant PMC prefix and then do as we wish with it.

—Trappist the monk (talk) 16:24, 12 April 2017 (UTC)

Because I think that there is no citoid fix, I've tweaked Module:Citation/CS1/Identifiers/sandbox:

• Title. PMC 4664-351. {{cite book}}: Check |pmc= value (help)
• Title. PMC 4664351.
• Title. PMC pmc4664-351. {{cite book}}: Check |pmc= value (help)
• Title. PMC 4664351.{{cite book}}: CS1 maint: PMC format (link)

—Trappist the monk (talk) 17:13, 12 April 2017 (UTC)

I assume from the length of the phab ticket that mediawiki devs have declined to do anything on their side. So yes, pragmatic solution for the moment is to allow |pmc=pmc1234 and |pmc=PMC1234 in addition to the existing |pmc=1234 (do we need to allow |pmc=pmc 1234 too?), and leave the rendered display as-is. If there is a desire to change the rendered display, that's a separate matter (I am also of the view that the PubMed guidelines seem to want redundancy that we are not required to show; broadly I think they want any display to be clear whether the number is a PMID or a PMC, which we do clearly as is, so I don't see a need to change rendered display.) Rjwilmsi 19:21, 12 April 2017 (UTC)

The primary point being made in the ticket is that the identifier is NOT just the number, but PMCnumber, and so Citoid is conceptually returning the right value. It's just that our templates expect a 'partial identifier'. The developer discussion gave no judgement on how we should render the ID. I wouldn't object personally to keeping any representation to just as it is right now, even though NIH guidelines suggest something else. However I do note that NIH uses that notation quite consistently, and I think that such consistency is something to take into account when evaluating this. —TheDJ (talk • contribs) 19:51, 12 April 2017 (UTC)

ASIN-related discussion

See Wikipedia talk:WikiProject Spam#amazon.com Headbomb {t · c · p · b} 11:56, 13 April 2017 (UTC)

Template:Cite IETF

Can something be done about this template?

1. It has quite low use (according to User:Green Cardamom at Special:Diff/775225851, only 181 articles).
2. It has bugs which are not easy to fix. i.e. |deadurl=no is ignored, plus |archiveurl= and |archive-url= are not the same. It uses Template:Citation/core instead of Lua module templates like Template:Cite web.
3. Template:Cite web can do almost everything this template can do, including |rfc=.
4. Documentation is outdated.

As an example, right now this template needs to use Template:Webarchive for the purpose of |archive-url=, seen in revision 775225151.

I'd like to see this IETF template go away, or be fixed of its bugs. Any other proposals or suggestions? 80.221.152.17 (talk) 23:59, 13 April 2017 (UTC)