Jump to content

Help talk:Citation Style 1/Archive 28

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 25Archive 26Archive 27Archive 28Archive 29Archive 30→Archive 35

The paper [1] is available for free in pdf format at [2] via an "author-access-token" as part of the Springer Nature Sharedit. That is, you can't get to the free pdf via the normal Nature url, but you can get directly to it via the sharedit link, which Springer says can be "posted anywhere". It seems to me we'd like to include both the regular Nature link and the sharedit link as part of a cite, but I don't see any clean way to do that now. Am I missing something, or should we add this somehow to the cite journal template? ★NealMcB★ (talk) 21:27, 20 October 2016 (UTC)

Use |doi=10.1038/nature20101 and |url=http://...
"Hybrid computing using a neural network with dynamic external memory". doi:10.1038/nature20101. {{cite journal}}: Cite journal requires |journal= (help)
—Trappist the monk (talk) 21:56, 20 October 2016 (UTC)
May I ask, why should the non-free link be added when a free one is available? Or am I missing something? 65.88.88.75 (talk) 22:04, 20 October 2016 (UTC)
It's generally useful to provide identifiers (especially DOIs). If readers want to import the citation in their citation manager (for instance Zotero), it makes it easier. − Pintoch (talk) 22:15, 20 October 2016 (UTC)
It also makes template maintenance much easier, as bots can make use of identifiers in ways they can't do with URLs. Likewise if you print the article, the DOIs (and other links) make it much easier to find the article than typing a very cumbersome URL like http://www.nature.com/articles/nature20101.epdf?author_access_token=ImTXBI8aWbYxYQ51Plys8NRgN0jAjWel9jnR3ZoTv0MggmpDmwljGswxVdeocYSurJ3hxupzWuRNeGvvXnoO8o4jTJcnAyhGuZzXJ1GEaD-Z7E6X_a9R-xqJ9TfJWBqz for those who have access to academic subscription and the like. Headbomb {talk / contribs / physics / books} 22:20, 20 October 2016 (UTC)
Amazing. Not a single word about what these templates are actually for: to apply a consistent citation style as an aid to the reader so that s/he can easily verify an article. How many readers import citations to citation managers? How many are interested in template maintenance and bots? How many would rather have the simplest, most direct way to verify the cited claim? Or is it that there are unlimited development resources so that these trivial tangents (vis-a-vis the stated goals of verification) are equal in importance to producing stable, easy-to-use code without bugs? 71.125.43.126 (talk) 12:53, 21 October 2016 (UTC)
Amazing? Hardly. That wasn't the question asked. Headbomb {talk / contribs / physics / books} 13:05, 21 October 2016 (UTC)
Forgetting about the technical details, having a DOI is also interesting for human readers as a witness that the paper has been peer-reviewed and published, unless the DOI has a particular shape (such as the ones issued by figshare). It is not designed for that, but as far as I can tell it does play that role in some communities. If I see a citation with only title, authors and link, I don't know what to expect. Maybe clicking on the link would give me that information, but I find it useful to have it in Wikipedia already. − Pintoch (talk) 13:58, 21 October 2016 (UTC)
DOIs are also much less likely to change or degrade over time. URLs come and go like the weather. – Jonesey95 (talk) 17:08, 21 October 2016 (UTC)
And why should a non-free link be added when there is pre-emptive archiving? 24.193.13.108 (talk) 01:13, 22 October 2016 (UTC)
For the same reason. Since the DOI is more resilient than a hyperlink, it will survive being copied and pasted, printed on paper, ported to another wiki or web site (perhaps with all links removed), and many other things that people do to Wikipedia pages. – Jonesey95 (talk) 07:34, 22 October 2016 (UTC)
Is there any data that shows that a doi is more "resilient" than both a free link and a free pre-emptive archive to the same material? Is there anything stopping editors from removing both of these free links (if both are dead) and adding the non-free doi link? That would make things simpler, wouldn't it? 72.43.99.146 (talk) 14:06, 22 October 2016 (UTC)

url-access=

I tried to use |url-access= for

  • * {{cite thesis |last=Harris |first=J. P. |title=The War Office and Rearmament 1935–39 |type=Ph.D. |url=http://ethos.bl.uk/OrderDetails.do?uin=uk.bl.ethos.289189 |year=1983 |publisher=King's College London (University of London) |accessdate=22 October 2016 |url-access=Registration |docket=uk.bl.ethos.289189 |oclc=59260791}} but got a red, does anyone know why? Regards Keith-264 (talk) 18:30, 22 October 2016 (UTC)
This feature has not been deployed yet, as the help page indicates. − Pintoch (talk) 18:58, 22 October 2016 (UTC)

OAbot is submitted for approval

I have submitted OAbot for approval. Feel free to comment! This builds on the access signaling features we have been working on here. − Pintoch (talk) 20:06, 22 October 2016 (UTC)

This morning I saw several |url= links that seemed to be prohibited WP:COPYLINKs. A typical occurrence is somebody teaches a college class and publishes several copyrighted journal articles on the school's website. The copies were never intended for public distribution, but well-meaning editors find them and insert them in WP articles.

How about a parameter that is not displayed that provides a justification for the URL link (e.g., |url-just=)? There might be an enumerated list of values that include author's website, publisher's website, snippet view, public domain, authorized, and unknown.

Here's an example of a website that claims to have permission to republish an IEEE article:

The parameter could be used to check for copylink violations. For example, find journal citations published by ACM that have a URL that does not point to ACM's website. Require those citations to have a copyright justification (such as author controlled website). Glrx (talk) 20:37, 22 October 2016 (UTC)

How about just putting it into an html comment? Why does the template need to see the justification? —David Eppstein (talk) 21:07, 22 October 2016 (UTC)
I'm just spit balling here, but I'd like a bot to enforce it. Glrx (talk) 22:12, 22 October 2016 (UTC)

Cite template to use for an official government regulation

It's unclear to me what the best cite template is for official government regulations. The only two that seem to be possibilities are {{Cite report}} and {{Cite techreport}}. The CS1 documentation says that the former is to be used for "unpublished reports by government departments" and the later for "technical reports". And cite techreport doesn't seem specific enough. Well, government regulations are published (by the government itself) so cite report isn't right. Often these are available through an government website like the American Government Printing Office's. Of course, {{Cite web}} could be used in that case but this actually ends up occuring a lot of the information behind the source (publisher for cite web is supposed to be the website, so |publisher= becomes the GPO rather than the office that actually published the document. So it seems that using cite web is not an ideal solution. What cite template would people use for government regulations (I have the American Alcohol, Tobacco, and Firearm regulations in mind). Do you think there's a need for a {{cite regulation}}? Jason Quinn (talk) 07:19, 23 October 2016 (UTC)

Do any of the templates listed at Template:United States legal citation templates answer?
I suspect that governmental regulation citations may not fit nicely into the cs1|2 chapter/article/section + title model that defines cs1|2 so cs1|2 may not be the right armature upon which to hang a new template. Of course, you could do somthing like this:
{{cite web |website=Electronic Code of Federal regulations |publisher=United States Government |title=Title 27 → Chapter I → Subchapter A → Part 20 → Subpart B → §20.11 Meaning of terms |url=http://www.ecfr.gov/cgi-bin/text-idx?SID=d934011bc5835ac395beb59c7ab188f1&mc=true&node=se27.1.20_111&rgn=div8}}
"Title 27 → Chapter I → Subchapter A → Part 20 → Subpart B → §20.11 Meaning of terms". Electronic Code of Federal regulations. United States Government.
—Trappist the monk (talk) 10:22, 23 October 2016 (UTC)
If the publishing website is the GPO's website, then GPO is the de facto publisher (the entity that makes the material public). In the normal case where the GPO website supplies the material but another government agency is the original publisher, then that agency should populate |publisher= and this can be added: |via=GPO. The specific template used should depend on the publication: if it is book form/length I would use {{cite book}}; if it is audio or video I would use {{cite AV media}}; if it is a technical document {{cite techreport}}; and so on. 72.43.99.138 (talk) 14:37, 23 October 2016 (UTC)

doi-broken-date / dead-url behaviour tweak

Now I get that in a sense, it makes sense to disable a link if it doesn't work:

  • {{cite journal |author=Smith, J. |year=2006 |title=Article of Things |url=http://example.com |journal=Journal of Important Stuff |volume=5 |issue=2 |page=23 |doi=10.1023/123456 |doi-broken-date=2016-10-20}}
  • Smith, J. (2006). "Article of Things". Journal of Important Stuff. 5 (2): 23. doi:10.1023/123456 (inactive 2016-10-20).{{cite journal}}: CS1 maint: DOI inactive as of October 2016 (link)

However, NOT having the link makes it really annoying to verify if the DOI is still inactive (many of those flaggings are done by Citation bot when the doi resolver is down or is having some hiccups. And this is very inconsistent with how we treat dead urls, where we keep the link, but don't even flag them!

  • {{cite journal |author=Smith, J. |year=2006 |title=Article of Things |url=http://example.com |journal=Journal of Important Stuff |volume=5 |issue=2 |page=23 |doi=10.1023/123456 |dead-url=yes}}
  • Smith, J. (2006). "Article of Things". Journal of Important Stuff. 5 (2): 23. doi:10.1023/123456. {{cite journal}}: Unknown parameter |dead-url= ignored (|url-status= suggested) (help)

What we should really have is something like

With |dead-url= changed to support dates, with the templates invoking {{dead link}} and {{dead doi}} (which would need to be created) and passing the date to those templates so they can populate the relevant cleanup categories. Or implement some equivalent function.Headbomb {talk / contribs / physics / books} 15:09, 20 October 2016 (UTC)

@Trappist the monk: Any feedback here? Headbomb {talk / contribs / physics / books} 09:57, 24 October 2016 (UTC)

The obvious feedback is that this topic doesn't appear to be of much interest to other editors. For my part, I'm not sure that cs1|2 should be in the business of doing the work of other templates so should not be adding {{dead link}} to the rendered citation's title (or any other externally linked title).
I have some sympathy for the issue of unlinked |doi= when |doi-broken-date= is set. I don't know why the decision was made to unlink 'dead' dois. Before any attempt to overturn that decision is made, some research needs to be undertaken. This is not the forum for discussing the failings or shortcomings of citation bot.
If any changes are to be made to |dead-url=, first on the list should be its name. All other parameters that end in -url are url-holding parameters. It's that consistency thing again.
—Trappist the monk (talk) 11:17, 24 October 2016 (UTC)
I agree that unlinking DOIs when they are broken is not very helpful. − Pintoch (talk) 11:31, 24 October 2016 (UTC)
The unlinking part is my priority tbh. The pseudo-templating is a suggestion/could be handled differently. A red message saying "this url is dead, do not delete it, but try to find an archive copy instead (help)". / "Inactive DOI as of <doi-broken-date> (help)." or something of that nature could also do the trick. Headbomb {talk / contribs / physics / books} 13:24, 24 October 2016 (UTC)

Conversion from |id= to |citeseerx=

There are currently quite a few pages where a CiteSeerX link is input in a citation template using |id={{citeseerx}}. Once the new CS1 has been deployed, I wonder whether it would be appropriate to transfer all these occurrences to |citeseerx=, with the obvious substitution:

|id = {{citeseerx|([0-9.]*)}} -> |citeseerx=$1

This might generate a few CS1 errors, because {{citeseerx}} does not perform any validation, whereas CS1 does. What do you think? − Pintoch (talk) 18:13, 24 October 2016 (UTC)

Shouldn't the find part be more like:
\| *id *= *\{\{ *[Cc]ite[Ss]eer[Xx] *\| *([0-9\.]*) *\}\}
I included the spaces inside the {{citeseerx}} template because, sometimes, editors include them; curly braces have meaning to regex so they are escaped; similarly the dot in the identifier's valid character set; there is a {{CiteSeerX}} redirect so sets in the template name match that.
biorxiv also?
—Trappist the monk (talk) 18:32, 24 October 2016 (UTC)
Thanks for the better regex. The {{biorxiv}} template is not used in any |id= yet. − Pintoch (talk) 18:45, 24 October 2016 (UTC)

CO2 markup in cite templates

I have read at Template:Citation § COinS that one should not include HTML or wiki markup in cite templates, such as {{cite book}}, as these contaminate the COinS metadata embedded in Wikipedia pages. That includes everything: ''x'' for italics and &nbsp; for non-breaking spaces.

I searched this archive and found several threads on this topic.

It seems that there are exceptions and that the COinS extraction code is somewhat intelligent. I am particularly interested in "CO2" in titles. It seems clumsy to have to revert to "CO2". To record CO2 in a title, can one use CO<sub>2</sub> or {{co2}}? Surely the HTML tags will be stripped out before creating the metadata? What happens with {{co2}}? Or should one prioritize typesetting in a Wikipedia article (and use such markup) over the COinS metadata (which perhaps wants only clean text)? Any guidance would be helpful. Best wishes. RobbieIanMorrison (talk) 20:17, 21 October 2016 (UTC)

Getting the title correct should take precedence over encoding metadata that nobody actually uses. If the title as published is CO2, it would be incorrect to write it as CO2 and we should not do that, no matter how loudly the cOiNs proponents might scream. On the other hand, if there is a CoInS-compliant way of marking it up that also produces the correct appearance, then that would be preferable to other markups that have the same appearance but are harder to generate correct metadata for. The same issues come up, by the way, in mathematics papers with formulas in their titles, or for that matter with book reviews that contain the italicized title of the book they are reviewing. —David Eppstein (talk) 21:08, 21 October 2016 (UTC)
Stripping html markup from the value assigned to |title= and other title-holding parameters has been on my todo list for a while. Until recent changes to MediaWiki broke it, the module did a fair job of stripping <math>...</math> markup from titles for use in the metadata. Now, those metadata with equations in their titles may have a recognizable equation or they may have a stripmarker, which to those who consume citations via the metadata is completely meaningless. The module has, for quite awhile, stripped off standard bold and italic apostrophe markup from |title=, |script-title=, |chapter=, and |script-chapter= (and aliases) so that the markup causes correctly rendered titles but the metatdata are not contaminated.
Alas, other things have been more important and real life is currently interfering.
—Trappist the monk (talk) 21:55, 21 October 2016 (UTC)
For the specific case of carbon dioxide, and a few similar simple cases, there is the workaround CO₂ using the Unicode Superscripts and Subscripts block. It's not particularly user friendly for editors, unless a template is used to insert it, but it preserves significant sub- and superscript characters without using raw HTML markup. --Xover (talk) 05:17, 22 October 2016 (UTC)
That tiny tiny subscript looks bad in my browser. I don't know what the chemistry editors think about this sort of thing, but MOS:MATH specifically warns against using unicode subscript and superscript characters, because they don't match the other subscripts and superscripts (that you still have to use because not everything is a available as a character). And I'd think the same people who want COinS metadata would also want semantic purity, which having special characters doesn't really give. —David Eppstein (talk) 06:12, 22 October 2016 (UTC)
While having these in the Unicode standard is a bit off (there is no real difference between the glyph for "2" and "₂", except size and vertical offset, which are, I think, strictly outside the scope for Unicode), there is no semantic issue with using them: they are semantically unambivalent and correct. How it looks in your specific browser, with your specific settings for fonts and text sizes (not to mention your specific model of eyeball), is also pretty irrelevant. However, I suspect the problems you see are likely to be endemic to at least a statistically significant subset of all relevant browsers, and so your point, indirectly, stands. However, the potential less than optimal visual rendering and the current ditto lack of ease for editors are the sum of the significant drawbacks; and both are potentially fixable in reasonable timeframes (iff the effort is put towards it, of course).
Where one should put that effort is a more significant issue: Unicode can't cover all the needs for mathematical formulae (though it probably can for chemistry), and there are other needs, far outside the scope of Unicode, that currently necessitate use of HTML markup in citation template parameters. Dealing with that general problem (not necessarily by the simple stripping approach, but that's likely to give the most bang for the buck in the short and medium term) would seem to be the best use of resources right now. Hence my above characterisation of the Unicode approach as a "workaround" rather than a "solution". Xover (talk) 07:44, 22 October 2016 (UTC)
Thanks to all for replying in depth to my question. I have some suggestions for possible fixes:
  • the various cite templates could include a new |title-coins= parameter which contains the text version of the title — this then transfers the responsibility for creating a COinS title to the article editor — and seems particularly appropriate for titles containing mathematics
  • templates such as {{co2}} could recognize their calling environment (polymorphic behavior in some sense) and emit a different string when invoked by COinS processing code — this then transfers the responsibility to the template author
  • proceed as currently indicated and parse the cite template using ad hoc regexes and so forth — this then leaves the responsibility with the COinS developers
Just some thoughts. I favor the first option on initial evaluation. Best wishes. RobbieIanMorrison (talk) 17:30, 23 October 2016 (UTC)
We try to avoid introducing parameters in the general because of complexity for the article writer. #2 is not possible. So generally, we work on #3, and as above, it's more a case of "we haven't yet had time for such" than "we don't want to do it in CS1". --Izno (talk) 19:24, 23 October 2016 (UTC)

The long-term solution to this issue is a large-scale bibliographic database spanning all Wikipedia and Wikimedia projects. It is called WikiCite. Please see:

Best wishes. RobbieIanMorrison (talk) 07:23, 25 October 2016 (UTC)

Citation templates missing from Commons

I naively attempted to copy across {{cite thesis}} to Wikimedia Commons, but there seem to be some lua modules missing over there. Could someone versed in these things copy them across? Main discussion at Village pump (technical).
Thanks! T.Shafee(Evo&Evo)talk 23:45, 25 October 2016 (UTC)

Embargo'd PMC behaviour

Currently, a citation with an embargo'd PMC, such as

  • {{cite journal|title=Title|author=Author|PMC=12345|embargo=May 1, 3000|PMID=123456|work=Journal|date=2006}}

displays as

which changes to

after the embargo period. However, disabling the link is really annoying, as you can't (easily) verify that the PMC version is actually still embargoed.

How about we instead do this?

Headbomb {talk / contribs / physics / books} 12:20, 26 October 2016 (UTC)

The red lock seems wrong to me. As far as I can tell, when a PMC is embargoed, it is just not available from PubMed Central at all. Having a "PubMed Central subscription" (if that means anything) will not enable you to get the full text from PMC, right? − Pintoch (talk) 13:07, 26 October 2016 (UTC)
I agree that the red lock is misleading. In the case of an embargoed PMC, the normal PMC free-to-read signal should not be rendered. This discussion has revealed a bug in the date validation code. In this example, the embargo ends 1 October 2018:
Summers EL, Moon CD, Atua R, Arcus VL (1 October 2016). "The structure of a glycoside hydrolase 29 family member from a rumen bacterium reveals unique, dual carbohydrate-binding domains". Acta Crystallogr F Struct Biol Commun. 72 (Pt 10): 750–761. doi:10.1107/S2053230X16014072. PMC 5053160. PMID 27710940. {{cite journal}}: Unknown parameter |embargo= ignored (|pmc-embargo-date= suggested) (help)
—Trappist the monk (talk) 13:29, 26 October 2016 (UTC)
@Pintoch:, what you get (in a real case) is something like PMC 4930116. Keeping the link but omitting lock works, I suppose. Or we could have something like
Nice lock! But I could personally mistake it for a normal green lock, I think. − Pintoch (talk) 09:51, 27 October 2016 (UTC)
I personally I am in favor of having the PMC id always be an active link for embargoed works, with no lock icon before the embargo date and a green lock after the embargo date. —RP88 (talk) 09:59, 27 October 2016 (UTC)

Use of lay-summary parameter kills display of the access-date value

Example:

     Mughal, Muhammad Aurang Zeb (18 June 2014). "Calendars Tell History: Social Rhythm and Social Change in Rural Pakistan". History and Anthropology. 25 (5): 592–613. {{cite journal}}: |access-date= requires |url= (help); Unknown parameter |lay-summary= ignored (help)

It's still a URL to which an access-date applies. And as previously discussed many times, we should never suppress display of that value anyway, even in absence of a URL, since in a WP context is means more than "date that the text I cited said what I claim it did, even if it has since changed"; it means (possibly more importantly) "datestamp of an editor actually stating in good faith that they did the work to verify this citation."  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  08:26, 27 October 2016 (UTC)

Sure, the value in |lay-summary= is a url (it's also a doi link so why not use |doi=?). But, |url= is not present and the error message specifically states that the |access-date= parameter requires the |url= parameter. This has been the definition of the error message since the introduction of the error message code.
Where are these many discussions that determined that we should never suppress display of that value? I do not recall seeing them.
—Trappist the monk (talk) 10:41, 27 October 2016 (UTC)

Early dates

I find it a little bizarre that dates before 100 are not supported, as one who frequently uses early literature.--Michael Goodyear (talk) 11:33, 27 October 2016 (UTC)

Are you frequently citing literature sources that were created in the first century? By that I mean the actual first century book or scroll or whatever form it takes. If you are citing an ancient source in a form that is 'modern', a scholar's translation or transcription of the ancient source, for example, then you should be using |date= to hold the publication date of the 'modern' source you actually read. You may include the date of the 'original', if that date is known, in |orig-year=.
—Trappist the monk (talk) 12:01, 27 October 2016 (UTC)
  • Perhaps allow years <100 by clever date-check: Example of ancient sources, which many people could read in person, would be museum pieces, such as the royal announcement on the Rosetta Stone (dated 196 BC) or copies, on display in the British Museum in London. Hence the related cite:
As of 29 October 2016, the "origyear=" parameter failed to display data, unless an artificial date was also set in the "date=" parameter. Other numerous bugs, where parameter values are ignored ("volume=" or "issue=" etc.), should be fixed as a top priority to reduce the embarrassing poor quality of the cite templates. There are a lot of templates to fix, but overall the effect has been: "Garbage In, Garbage Out". A possible quick-fix could be a new fork, "{cite ancient}" where the date would not be restricted. -Wikid77 (talk) 17:29/17:33, 29 October 2016 (UTC)

RFCs on lock design + template behaviour.

See

Headbomb {talk / contribs / physics / books} 16:02, 29 October 2016 (UTC)

  • In general, adding new parameters for rare cases is trouble: Plus removing "subscription=" will tend to cause a lot of problems, as with the proposed new keywords ("url-access=registration" or "doi-access=registration"). Hence, the discussion at wp:VPP will need to show extensive benefits to offset or counter-act the likely problems. Meanwhile, I am often finding people marking "subscription" where the webpage has free access to many users, but perhaps not all. -Wikid77 (talk) 17:43, 29 October 2016 (UTC)
With regards to your first point, I am not sure what you are asking. The "url-access" and "doi-access" parameters have already been added and deployed earlier today. From what I've been able to determine the RFC's above are for further refinements to this new behavior, not a referendum on whether these parameters should be added. I suppose you could propose a third RFC asking that the new lock symbols and access parameters be removed. —RP88 (talk) 18:01, 29 October 2016 (UTC)

Render problems in columned reflist

After url-access=limited was added to refs within Grace VanderWaal—specifically, nos. 14 and 22—the titles of the articles no longer line-break in conformity with the columns. In fact, it forces the entire title onto its own line of text. —ATS 🖖 talk 21:22, 30 October 2016 (UTC)

I should note here that I just saw the nowrapping § above. —ATS 🖖 talk 21:59, 30 October 2016 (UTC)

False deprecation?

There is a warning message that appears in {cite interview}, where "program=" is identified as a deprecated parameter. Surely this is an error, as it is a key to identifying a broadcast/webcast source.Raellerby (talk) 14:33, 31 October 2016 (UTC)

The parameter was deprecated per discussion at [3]. Its replacement is identified in Help:CS1 errors#Cite uses deprecated parameter |<param>. Please let us know if you have other questions. --Izno (talk) 14:50, 31 October 2016 (UTC)

oadoi.org as default doi service

Hello,

Diptanshu.D has brought an interesting doi server alternative to my attention that I thought I'd recommend here as a replacement for our current server http://doi.org. If an article is not gold OA, it finds an alternative green OA to link to in stead. Implementing it would simply be a case of switching from http://doi.org/{{{doi}}} → http://oadoi.org/{{{doi}}}.

What do people reckon? T.Shafee(Evo&Evo)talk 02:16, 27 October 2016 (UTC)

  • Strongly support unless people can prove it's malfunctional or something. An enormous percentage of our journal citations run smack into a paywall or go to nothing but abstracts, and this would help find full-text from open access sources.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  08:28, 27 October 2016 (UTC)
  • Strongly support paywalled links are an obstacle to Wikipedia's goal, using oadoi.org looks like a great way to mitigate this whenever open-access versions can be found instead. --a3nm (talk) 08:52, 27 October 2016 (UTC)
  • Weak oppose. Disclaimer: I am part of the team behind http://doai.io/, which inspired http://oadoi.org/. Of course we have thought about proposing this change (for doai.io), but I don't think switching to any of these systems as doi resolvers would be a smart move (given how they currently function).
    • There are cases where these systems just don't redirect to the right thing. They can be mislead to think that a preprint is available somewhere but actually isn't. When that happens, it is quite annoying for the user to go back, copy-paste the doi after doi.org and recover the standard landing page from the publisher (and very few users would understand what is happening). For instance, doi:10.1007/978-3-319-10073-9_3 would resolve to http://oadoi.org/10.1007/978-3-319-10073-9_3 : these are slides, not the actual paper.
    • People expect to be lead to the publisher's version when they click on a DOI in wikipedia. This does not mean these alternative DOI resolvers are useless, they are just useful in other contexts (for instance via Zotero)
    • Wikipedia has a rich system of citation templates which already have all the features required to present multiple links to a given paper (|url=, |arxiv=, |pmc=, |hdl=…). It is much more useful to let users pick from Wikipedia which link they want to be taken to, instead of letting the DOI resolver choose for them.
    • A new set of features for access signaling in citation templates will be rolled out very soon, which should help readers click on the right identifier without being scholarly communication experts.
I invite you to check out our bot project, OAbot, which is currently submitted for approval. Feedback and contributions are extremely welcome! − Pintoch (talk) 09:03, 27 October 2016 (UTC)
  • While I can empathize with your concern, I think the DOI link should always use the standard resolver so that reviewers of a cited fact know exactly what version of a work was being cited. Editors can already supply a link to a free version via the URL or the other free repository identifiers. Not to mention, OAbot, referenced by Pintoch above, is in the process of being deployed, which will automatically add these free link/iids. —RP88 (talk) 10:09, 27 October 2016 (UTC)
  • I oppose this too. The doi should resolve via the official resolver. However, once we've deployed this weekend's update and the RFC (draft) is concluded, we'll know what's possible in terms of autolinking. We might be able to have a |auto-url=oadoi or |oadoi=yes or similar that would keep things simple. Headbomb {talk / contribs / physics / books} 10:16, 27 October 2016 (UTC)

Editors can always directly link to whatever they'd like by placing that link in |url=. No need to add a new oadoi.org identifier especially when, as it appears to me, it is not reliable. The example on their about page returns a blank page for me (the source for that blank page is full of jibberish so something is there but just what that is, I do not know).

—Trappist the monk (talk) 10:57, 27 October 2016 (UTC)

  • Strongly support - Of course some more work has to be done for integration. The people at OADOI would need to be involved and a suitable API integration has to be worked out. Based on that perhaps the issued pointed out by User:Pintoch can be resolved. DiptanshuTalk 23:20, 29 October 2016 (UTC)
Another approach could be to keep doi.org as default, introduce some parameter to check about the free full text status, if not available then check oadoi.org servers though designated API. That should take care of the issues pointed out by User:Headbomb. Give it a thought. DiptanshuTalk 23:30, 29 October 2016 (UTC)
  • Strongly oppose. A doi link should always go to the definitive final published version of an article. The "open" version of an article is often a less-polished preprint. It can be helpful to provide such links in addition to the official doi link, but we should not prevent people from reaching the final version when that's what they are looking for. —David Eppstein (talk) 00:09, 30 October 2016 (UTC)
  • Weak oppose. Disclosure: I'm one of the people running oaDOI. Of course we love the idea of oaDOI being used on Wikipedia. But I agree with User:Pintoch that using us as the primary resolver is a bad idea, for the reasons he mentioned. As a reader, I'd much prefer a link to both the publisher's page (so I can get metadata), and another oaDOI link to Whatever Fulltext We Can Find (so I can actually read the darn thing).Jasonpriem (talk) 20:35, 31 October 2016 (UTC)
  • Change to weak oppose for now - One thing I love about this community, is the breadth of knowledge and expertise. I can see how the aodoi system is not yet ready for the sort of implementation that I descibed. I still hope that some day, there will be a systems that is suitable (e.g. when no gold OA is available, brings up a page that gives the user a choice of either visiting the original publisher's paywall, or viewing a green OA version). T.Shafee(Evo&Evo)talk 22:53, 31 October 2016 (UTC)

Meta-identifier template

Hi, I've started building Template:Identifier. The idea would be that all identifier templates invoke {{identifier}} (or maybe some LUA module), and we can have a meta template/module for all identifier templates like {{arxiv}}, {{bibcode}}, {{doi}}. The meta template would need to support

  1. Rendered name of identifier
  2. Wikipedia page to link to
  3. Separator between identifier and link
  4. Which locks can be appended / are shown by default
  5. Embargo date
  6. Broken identifier date
  7. Identifier validation
  8. How the template renders in print

Help designing/coding this would be appreciated. Headbomb {talk / contribs / physics / books} 20:27, 31 October 2016 (UTC)

Seems like we should start with Module:Citation/CS1/Identifiers. --Izno (talk) 20:56, 31 October 2016 (UTC)
You may also be interested in the discussion at phab:T148274 and related tasks. --Izno (talk) 13:59, 1 November 2016 (UTC)

Parameter "city" shows up in Template:Cite episode a lot

With the recent setting of |city= to deprecated in the module, I've discovered a large number of cases where |city= is used outside {{cite interview}} (and particularly in {{cite episode}}, where I'm not sure it makes a lot of sense, since it must mean the DevelopmentLocation and not the PublishingLocation). I don't think it's a problem if we deprecate this parameter outside cite interview as well in favor of |location=, but just wanted to see if anyone else disagrees. --Izno (talk) 12:36, 1 November 2016 (UTC)

I find only 70 pages using cite episode with city=. It looks like using |location= instead is straightforward and not a big task. I also checked {{cite book}} and {{cite web}} and found far fewer instances. – Jonesey95 (talk) 13:02, 1 November 2016 (UTC)
Note: I have changed a bunch of articles to use |location= instead of |city=, and on the way, I have found once again that insource searches do not return all results. Here's what should be a subset of a search for all uses of city= within cite templates, but it actually finds more (300+ articles) than a more expansive search does (9 articles). This is a tracked bug, T106685. – Jonesey95 (talk) 12:49, 3 November 2016 (UTC)
I've just been through Category:Pages containing cite templates with deprecated parameters with an AWB task dedicated to replacing |city= with |location= in any and all cs1|2 templates. That task 'fixed' 700ish articles. The job queue is still adding new pages to the category.
—Trappist the monk (talk) 13:16, 3 November 2016 (UTC)
There is a list of 200 more at User:Jonesey95/sandbox3 if anyone is in the mood. – Jonesey95 (talk) 14:34, 3 November 2016 (UTC)

Turning off locks via user preferences

There is a significant amount of people who seem to not want to see the access locks. While removing the locks isn't really an option, we should at least provide a way to suppress their display via user preferences. What would we need to do to make that happen? Headbomb {talk / contribs / physics / books} 13:49, 1 November 2016 (UTC)

Probably not a good idea to promise something without first knowing that it is doable and that there is someone willing to do it.
Module:Citation/CS1 cannot look into a user's preferences; the module executes much too early for that. That leaves us with css or js. It is not clear to me that css can solve the problem. If we do not display the lock, we must restore the default external link icon. I don't know how to do that.
—Trappist the monk (talk) 14:07, 1 November 2016 (UTC)
Well, personally, I suppress all external link icons via "a.external { background:none !important; padding:0 !important; }" in my User:Headbomb/monobook.css. I'm not a css wizard however, so I don't quite know how that works. But there should be a way to wrap those in a span class, and have something in user preferences that lets you hide whatever is in that class from being displayed. Headbomb {talk / contribs / physics / books} 15:18, 1 November 2016 (UTC)
That will work, provided a class is provided. Is that the plan? Alternatively, people may block individual icons using an ad blocker. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:43, 3 November 2016 (UTC)
Well if that's what's needed to enable that in user preferences, it's a straightforward thing to implement. Doesn't mean it's the only option, but if it works, then let's do that? Headbomb {talk / contribs / physics / books} 15:49, 3 November 2016 (UTC)

Archive wikiwix

Hello,

I am Pascal Martin from Linterweb, our Wikiwix service archived since 2008 more than 100 million Francophones and Anglophones source links on Wikipedia. Our system is based on a detection of real-time links on Wikipedia and backup the content of external links without compromising the noarchive tag.

Then, I am coming to you to offer you to supply the template Citeweb through our archives, simply by http://archive.wikiwix.com/cache/?url=http://www.letelegramme.fr/ig/generales/regions/cotesarmor/coat-an-noz-le-chateau-retrouvera-son-eclat- 01-08-2011-1386817.php

Please, note that I am the manager of a small company, my goal is not to make money with archives but to propose an Alternative to content saveguard and give some big data for the europeen research.

Indeed, since December we will deploy our technology to the entire corpus of the Wikimedia Foundation and in all languages.

We are hosted by the French University Network.

Sincerely, Pascal --Pmartin (talk) 18:11, 4 November 2016 (UTC)

Wikiwix is listed at WP:DEADREF, for followon commenters. --Izno (talk) 18:15, 4 November 2016 (UTC)
thank you , I have send a request here https://en.wikipedia.org/wiki/Template_talk:Webarchive#Archive_wikiwix Pmartin (talk) 19:13, 4 November 2016 (UTC)
Wikiwix is listed at WP:DEADREF .. because it was just added by Pmartin, who is an employee of the private company that runs Wikiwix. Look I'm not assuming bad faith, but given the issues and limitations with this archiving service (see Template_talk:Webarchive#Archive_wikiwix) we should go a little slower before documenting it in help pages. There are dozens of web archiving initiatives. -- GreenC 19:52, 4 November 2016 (UTC)
It's linked pretty extensively by French Wikipedia with over 23k uses, so at least one large community finds it acceptable. (Mind you, we might not.) --Izno (talk) 20:17, 4 November 2016 (UTC)
Pmartin sounds like he is willing to work with us to add some new features. -- GreenC 20:25, 4 November 2016 (UTC)

ISSN display tweak

Something that kind of always annoyed me is in citations like

  • {{cite journal |last=Smith |first=J. |year=2014 |title=Article of things |journal=Journal of Stuff |volume=12 |issue=3 |page=4 |arxiv=1201.1234 |doi=10.1234/example |issn=2327-4662 |pmid=102344}}

It displays things like

Seems to me like it would be a lot better to present this as

Opinions? Headbomb {talk / contribs / physics / books} 00:58, 5 November 2016 (UTC)

Doesn't bother me. I know that the ISSN is the identifier for a periodical, not an article, and if I don't know that and click through the link, I'll learn fast. Or I can click the link for ISSN and find out what it is.
Cite book could be said to have a similar display:
  • {{cite book |last=Smith |first=J. |year=2014 |chapter=Chapter of things |title=Book of Stuff |pages=4 |isbn=123456789X |publisher=Random House|location=New York}}
Which renders as:
  • Smith, J. (2014). "Chapter of things". Book of Stuff. New York: Random House. p. 4. ISBN 123456789X.
Would you prefer the ISBN be placed in parentheses after the book's title as well? – Jonesey95 (talk) 01:17, 5 November 2016 (UTC)
I was thinking about that, but I can't find any place where they handle ISBNs that way. So this would really be for ISSNs only. The reason being that when citing a book, most style guides will add the ISBN at the end (if they include it at all), since it will (usually) be the only identifier (books with both ISBN / DOIs for chapters tend to be conference proceedings). But whenever anyone lists a journal's ISSN, it's always next to the journal's name. Probably because journals will tend to have multiple identifiers, so it makes sense to separate articles identifiers from ISSNs. Headbomb {talk / contribs / physics / books} 01:41, 5 November 2016 (UTC)
Personally, I nearly always remove ISSNs from citations anyway. Including them is very non-standard, and pretty pointless when you have DOIs etc. Headbomb {talk / contribs / physics / books} 01:42, 5 November 2016 (UTC)
Yes, the trade-off between visual brevity and bibliographic completeness is a hard one. Ideally in this case the ISSN could be still input (so that it makes it way to the COinS) but not displayed. But that would add a lot of complexity. I'm interested to see what comes out of meta:WikiCite. Storing metadata in a database could help distinguish between what we know and what we display. − Pintoch (talk) 10:45, 5 November 2016 (UTC)

update to the live cS1|2 module weekend of 29–30 October 2016

I expect to update the live cs1|2 modules on the weekend of 29–30 October. Changes since the last update are:

To Module:Citation/CS1

  1. added support for access-signalling; multiple discussions at different times listed here in no particular order:
    discussion
    discussion
    discussion
    discussion
  2. added special case translation table in support of internationalization; discussion
  3. reworked {{cite interview}}; discussion
  4. repaired empty citation test; discussion
  5. removed support for {{cite DVD notes}}; TfD discussion

To Module:Citation/CS1/Configuration

  1. added support for access-signalling; multiple discussions at different times listed here in no particular order:
    discussion
    discussion
    discussion
    discussion
  2. added special case translation table in support of internationalization;
  3. added |bioarxiv=; discussion, discussion
  4. reworked {{cite interview}};
  5. added |citeseerx=; discussion
  6. Add 'thesis' to templates_using_volume; discussion

To Module:Citation/CS1/Whitelist

  1. reworked {{cite interview}};
  2. added |citeseerx=;
  3. added support for access-signalling;

To Module:Citation/CS1/Identifiers

  1. added support for access-signalling;
  2. adjusted PMC ID limit; discussion
  3. added |citeseerx=;
  4. removed extraneous colon from embargoed PMC rendering; discussion
  5. added |bioarxiv=;

—Trappist the monk (talk) 11:12, 22 October 2016 (UTC)

That list is missing many changes. The actually list is here, but Trappist reverted it because reasons. Headbomb {talk / contribs / physics / books} 12:54, 22 October 2016 (UTC)
You could have simply added appropriate addenda to this discussion without rearranging, adding, and removing items from my list.
the Module:Citation/CS1/Configuration list you changed:
  • changed item #3: added a discussion link and text regarding |biorxiv= error checking
  • changed item #5: added discussion link about |citeseerx= error checking
  • swapped items #4 and #5
the Module:Citation/CS1/Whitelist list you:
  • moved existing item #1 to the bottom of the list where it ultimately becomes item #5
  • added new item #1 regarding the addition of |biorxiv=
  • inserted new item #3 regarding an addition of CamelCase variants of |arXiv=, |bioRxiv=, and |CiteSeerX= without discussion link
the Module:Citation/CS1/Whitelist list you:
  • reordered the list items
It seems to me unnecessary for you to reorder these lists because they are more-or-less in chronological order which is how I have always ordered these lists.
—Trappist the monk (talk) 14:35, 22 October 2016 (UTC)

camel case parameter names

As I read the discussion, there is not a strong consensus for reintroducing mixed case (in this instance, camel case) parameter names. Where is the strong consensus for this change?

—Trappist the monk (talk) 14:35, 22 October 2016 (UTC)

If I remember well, the consensus was more on the status quo side indeed. I just fixed the sandbox. Fully uppercased parameters are not introduced either as |ARXIV= and |BIBCODE= are deprecated. − Pintoch (talk) 07:40, 23 October 2016 (UTC)

Nowrapping locks

Right now, in citations like

The lock and its corresponding link aren't nowrapped. A line break and occur between them. This should be fixed before deployment if possible. Headbomb {talk / contribs / physics / books} 13:01, 28 October 2016 (UTC)

I have undone the nowrap. It worked fine for identifiers but not for long titles.
—Trappist the monk (talk) 21:38, 30 October 2016 (UTC)
How about using a non-breaking thinspace (&#8239;), or similar? Headbomb {talk / contribs / physics / books} 21:40, 30 October 2016 (UTC)
That works on my browser and I've implemented it in the sandbox but browser support for it may be an issue. If we can figure out how to use css to solve this problem, that would be best.
—Trappist the monk (talk) 22:16, 30 October 2016 (UTC)
@Trappist the monk: How about we roll it out now since the majority of browswers will support it? We can have a CSS solution later if needed/we can work that one out? Headbomb {talk / contribs / physics / books} 22:45, 4 November 2016 (UTC)
Also, someone on stack overflow suggested <span style="white-space:nowrap"> </span> [4] a few years ago. This may be relevant. Headbomb {talk / contribs / physics / books} 22:54, 4 November 2016 (UTC)
On my browser, the suggested <tag style="white-space:nowrap">&thinsp;</tag> does not prevent wrapping between the text and the signal icon.
I have a solution in mind. If time permits this weekend, I'll see if I can make it work.
—Trappist the monk (talk) 23:57, 4 November 2016 (UTC)

I've tweaked external_link() to use css to keep the access signal with the last word in |title=. It isn't very pretty, but it works so should not have the browser issues that might be present because of a reader's chosen font.

And here is the resulting markup:

  • '"`UNIQ--templatestyles-00000031-QINU`"'<cite id="CITEREFLast2016" class="citation book cs1">Last, First (2016). <span class="id-lock-subscription" title="Paid subscription required">[http://www.example.com/ ''a long multi-word title that could split the access signal onto a new line'']</span>. Somewhere: Publisher.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Abook&rft.genre=book&rft.btitle=a+long+multi-word+title+that+could+split+the+access+signal+onto+a+new+line&rft.place=Somewhere&rft.pub=Publisher&rft.date=2016&rft.aulast=Last&rft.aufirst=First&rft_id=http%3A%2F%2Fwww.example.com%2F&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+28" class="Z3988"></span>
  • '"`UNIQ--templatestyles-00000033-QINU`"'<cite id="CITEREFLast2016" class="citation journal cs1">Last, First (2016). <span class="id-lock-subscription" title="Paid subscription required">[http://www.example.com/ "a long multi-word title that could split the access signal onto a new line"]</span>. Somewhere: Publisher.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=article&rft.atitle=a+long+multi-word+title+that+could+split+the+access+signal+onto+a+new+line&rft.date=2016&rft.aulast=Last&rft.aufirst=First&rft_id=http%3A%2F%2Fwww.example.com%2F&rfr_id=info%3Asid%2Fen.wikipedia.org%3AHelp+talk%3ACitation+Style+1%2FArchive+28" class="Z3988"></span> <span class="cs1-visible-error citation-comment"><code class="cs1-code">{{[[Template:cite journal|cite journal]]}}</code>: </span><span class="cs1-visible-error citation-comment">Cite journal requires <code class="cs1-code">&#124;journal=</code> ([[Help:CS1 errors#missing_periodical|help]])</span>

—Trappist the monk (talk) 12:42, 6 November 2016 (UTC)

Kerning and id-access

Please add kerning on italicized urls (e.g. linked journal article titles). The locks bump into them in several browsers.
Add more choices for |jstor-access=. JSTOR has recently instituted a beta registration program. Several links require registration, not subscription.

17.255.236.9 (talk) 00:07, 30 October 2016 (UTC)
Correction: I meant something like this: Author. Title – via Google Books. {{cite book}}: |author= has generic name (help).
50.74.104.107 (talk) 00:33, 30 October 2016 (UTC)
There is already 0.1em kerning on the lock. Here are examples with 0.15em and 0.2em:
TitleFreely accessible margin-left:0.1em
TitleFreely accessible margin-left:0.15em
TitleFreely accessible margin-left:0.2em
Identifiers are presumed to require either subscription or registration. We do not highlight the norm. When identifiers are free-to-read, that is worth highlighting.
—Trappist the monk (talk) 00:41, 30 October 2016 (UTC)
If you want more options for the <id>-access parameters, you're encouraged to participate in the template behaviour RFC. Headbomb {talk / contribs / physics / books} 00:55, 30 October 2016 (UTC)
Existing kerning doesn't render properly in Safari. But this is cosmetic. However, the other tem is non-trivial. Subscription involves payment. Registration doesn't; they are different levels of access. Imo, this doesn't belong in an RFC. It is obvious and uncontroversial. 24.193.12.141 (talk) 01:39, 30 October 2016 (UTC)
Yes, but as you can see, |jstor-access=subscription is currently not allowed, only |jstor-access=free is. The reason is that some of us consider that identifiers are expected to be "closed" by default and urls are expected to be open by default, so we should only highlight outliers: signaling a restriction on an identifier is considered redundant. So, if |jstor-access=subscription was currently allowed, it would be uncontroversial to add support for |jstor-access=registration, but that's not the case. So yeah, the RFC is the right place to suggest this kind of change. − Pintoch (talk) 09:56, 30 October 2016 (UTC)
It seems the expectations that some of you have regarding JSTOR at least, are mistaken. Has anyone looked here before making assumptions? In this page it is also stated that 75% of archived material is free-to-read, and there is also the "borrow" option (registration). The apparent lack of research on the subject is no reason to take this to the RFC. 72.43.99.138 (talk) 14:21, 30 October 2016 (UTC)
Don't want to comment there? That's fine. Just don't complain if things don't end up how you want them because you didn't want to take place in the RFC. Headbomb {talk / contribs / physics / books} 15:15, 30 October 2016 (UTC)
Btw, the kerning issue may have to do with the implementation of {{reflist}} (and the associated class/list-styles etc.), which implement a smaller visual aspect for the included refs. Image scaling and text scaling are different beasts and may well be out-of-sync. Don't have time to look into it. 72.43.99.130 (talk) 20:23, 31 October 2016 (UTC)

Bengali or Bangla?

Until recently, cite templates containing |language=bn produced "(in Bengali)" in their output. Recently (past week or so?) something has changed so that they instead produce "(in Bangla)". In what I assume is a related development, articles such as 2010 South Asian Games now appear in Category:CS1 Bangla-language sources (bn). Previously such articles would have been in Category:CS1 Bengali-language sources (bn).

What to call a language can be highly controversial. So before straightening out the categories I would like to know how well-thought-out the change was. I can't figure out where the change took place, so I can't identify who made it or what discussion (if any) it was based on. Would someone more experienced point out where the change was made? --Worldbruce (talk) 18:58, 6 November 2016 (UTC)

The change was made somewhere in MediaWiki as can be seen by this magic word:
{{#language:bn|en}}
Bangla
The change was not made here.
Module:Citation/CS1 gets the language text from this Scribunto library call: 
mw.language.fetchLanguageName(lang:lower(), this_wiki_code);
where lang:lower() comes from the |language=bn parameter and this_wiki_code is the language code for English. It is not clear to me exactly where the change was made because there are at least two and perhaps more lists of language names in MediaWiki's code. Additionally, these lists may or may not use language names and codes that comport with the ISO 639 codes.
I do not have enough free time at present to chase this down. |language= expects a language name or an ISO 639-1 or -2 code. Bangla is not the primary name shown for code bn at the ISO 639 custodian's website. See here and the ethnologue cite linked from there.
If the change is permanent, I suspect that the correct solution is to modify language_parameter() in Module:Citation/CS1 so that bn returns Bengali and the Bengali category. We have done this before when no returned Norwegian Bokmål (nb). If the custodian changes the language name to Bangla, then we should follow that example for language and category names.
—Trappist the monk (talk) 19:33, 6 November 2016 (UTC)
I have asked for help from the folks at WP:VPT. It appears that somewhere, the language code "bn" has been changed to return "Bangla" instead of "Bengali". These are two names for the same language, according to the English Wikipedia, but most other parts of en.WP use "Bengali" as the name for this language. See, for example, Bengali language (which has not been moved), {{Bn icon}} (returns "Bengali"), {{ISO 639 name bn}} (returns "Bengali").
Also possibly relevant: this Talk:Bengali language discussion. – Jonesey95 (talk) 04:28, 7 November 2016 (UTC)
Aftabuzzaman works on both enwiki and bnwiki—do you know anything about this? Johnuniq (talk) 04:53, 7 November 2016 (UTC)
This sounds like it was a change in the MediaWiki software somewhere. The lists used by mw.language.fetchLanguageName() are maintained as part of the software, although I wasn't able to find exactly where the "Bangla" text is defined. — Mr. Stradivarius ♪ talk ♪ 07:08, 7 November 2016 (UTC)
mw:Help:Magic words#Miscellaneous says {{#language:}} uses mw:Extension:CLDR. It uses CLDR data for language names. http://cldr.unicode.org/index/downloads/cldr-30 says bn was changed to BengaliBangla in CLDR 30 in October 2016. [5] refers to the request at [6]. I don't know whether MediaWiki's language name data ever changes CLDR data. If people want Bengali back in {{#language:}} then they may have to request a revert of the change at CLDR. See http://cldr.unicode.org/index/bug-reports. English Wikipedia articles are not obligated to follow CLDR. The article can stay at Bengali language unless there is consensus to move it, but I think it would be messy if templates using {{#language:}} test for bn and make another name in that case. PrimeHunter (talk) 11:22, 7 November 2016 (UTC)
If our Bengali language and Exonym and endonym articles are correct, then Bangla is the name of the language used by the people who speak that language. For the rest of the world, Bengali is, apparently, the preferred term. It would seem that MediaWiki should know the difference and return correct results according to target language code in:
{{#language:bn|target language code}}
So, when target language code is omitted:
{{#language:bn}} → বাংলা (I presume that this translates to what speakers of the language understand as 'Bangla')
But, when target language code is specified, and is not bn, as here:
{{#language:bn|en}} → Bangla (should have returned 'Bengali' as the exonym and as the ISO 639 primary definition)
When target language code is not specified, or is set to bn, then MediaWiki should return the language endonym in that language's writing system. For all other cases, MediaWiki should return the language exonym in the target language's writing system. This should hold true until the ISO 639 standard is changed to make Bangla the primary name for bn.
Since all of this results from machinations outside of Wikipedia, I shall tweak Module:Citation/CS1 so that it gives special treatment to bn. Argh! There is a standard. Why can't we use and adhere to the standard? Yeah, rhetorical question.
—Trappist the monk (talk) 12:10, 7 November 2016 (UTC)
Done:
{{cite book/new |title=Title |language=bn}}
Title (in Bengali).
I have also intercepted |language=Bangla because, as the endonym, it is the incorrect form for en.wiki. For those who use this module in other-language wikis, it will be necessary for those users to tweak the code to suite their own language:
{{cite book/new |title=Title |language=Bangla}}
Title (in Bengali).
—Trappist the monk (talk) 12:27, 7 November 2016 (UTC)
Thanks, Trappist and PrimeHunter. That is frustrating. It's hard to know whether this is a Peking/Beijing situation (everyone changes) or a Myanmar/Burma situation (everyone fights about it). Since this is the English Wikipedia, it's probably best to follow whatever happens at Bengali language. For now, "Bengali", but nothing is ever permanent. – Jonesey95 (talk) 16:24, 7 November 2016 (UTC)

Cite dictionary and access locks

  • {{cite dictionary |title=Particle |url=http://oed.com/search?searchType=dictionary&q=particle |url-access=subscription |dictionary=[[Oxford English Dictionary]] |edition=3rd |publisher=[[Oxford University Press]] |date=September 2005}}

produces

There should be a red lock after the url. Headbomb {talk / contribs / physics / books} 15:32, 9 November 2016 (UTC)

Because {{cite dictionary}} is a redirect of {{cite encyclopedia}} which remaps Title to Chapter, URL to ChapterURL (among others). The same problem sill occur when using |chapter= and |chapter-url=. I guess I wouldn't worry about any of this until the RfCs run their course.
—Trappist the monk (talk) 15:43, 9 November 2016 (UTC)
We haven't made |chapter-url= have a corresponding |chapter-url-access=? Because we really should. I agree that we can wait for the RFC to see if we want to add support for |chapter-url-access=free, but the template should support the current limited/registration/subscription. Headbomb {talk / contribs / physics / books} 15:46, 9 November 2016 (UTC)

|location=Cambridge [u.a.]

I suppose that I should know the answer to this question but I do not. In |location=Cambridge [u.a.] what is the meaning and purpose of [u.a.]?

—Trappist the monk (talk) 12:28, 13 November 2016 (UTC)

See previous discussion. Nikkimaria (talk) 15:49, 13 November 2016 (UTC)
Worldcat does this a lot, so some automated tool is probably copying the Worldcat location directly. See this encyclopedia.com entry, which says that it is an abbreviation for the German unter anderem (in English: "among other things"), and this StackExchange discussion, which says that "u.a." and "et al." have the same meaning. We should probably remove it, since it does not help the reader find the source. – Jonesey95 (talk) 16:36, 13 November 2016 (UTC)
Short answer: Yes. Long answer: The abbreviation "u.a." has two similar, but nevertheless distinguishable meanings in German, "unter anderem" ("among other things") and "und andere" ("and others"). The first meaning is very commonly used, whereas the second meaning has somewhat fallen into disuse over time and is much less frequently used today. Germans typically use the Latin phrase "et al." / "et alii" only for people, not for things, so it would be okay to replace "u.a." by "et al." in a list of authors, but for a list of locations, Germans would probably use either "usw." ("and so on") or "etc." ("et cetera") instead today.
--Matthiaspaul (talk)

Russian (Cyrillic) characters in url

The article Troitsky Administrative Okrug contains cites with links to http://троицкий-округ.рф/ - which is causing {{cite web}} to complain Check |url= value. Short of encoding the url in punycode (which produces the human-unfriendly http://xn----ftbnafed0afniox8a.xn--p1ai/) is there anything that can be done to suppress or fix the warning in this case? It seems the .рф TLD has been issuing Cyrillic domains since 2010, so we must have come across this issue before. -- Finlay McWalter··–·Talk 11:57, 15 November 2016 (UTC)

However, the punycode url is not seen by readers. And one could argue that all machine encodings (including FQDNs - pun intended) are human-unfriendly. 64.134.69.23 (talk) 12:52, 15 November 2016 (UTC)
No, but they are seen by editors (Wikipedia is one of the few places where the format of URLs really impacts anyone but a handful of content creators - because we have so many content creators). And the less readable a URL is, the easier it is for someone to abuse it (by changing it to point to someone other than what the original author had intended). That's one of the reasons we don't allow URL shorteners. -- Finlay McWalter··–·Talk 13:05, 15 November 2016 (UTC)
The content creators in Wikipedia are a very small minority. There are far more editors than contributors. These in turn are dwarfed by the number of readers. I wonder if the required changes would pass a cost/benefit analysis. I can't even begin to think the kind of complexity that Scribunto for example, would have, if it was to be made as friendly to the small minority of programmers as your point is suggesting. Also, changes here are journaled: not only are they logged, but they are also reversible. Yet way too many things imo are restricted in order to make clerical functions (administration) easier. 72.43.99.146 (talk) 15:27, 15 November 2016 (UTC)
I think that the only conversation that has been had about internationalized domain names is here. I suppose that at some future date, if there is sufficient need for it, Module:Citation/CS1 might be changed to support multi-byte Unicode domain names but I can imagine that that is not a simple task. For example, the code must make sure that domain names are composed of a single alphabet so that vandals can't insert urls that look to be 'lеgіtіmаtе' (lU+0435gU+0456tU+0456mU+0430tU+0435) but link to unsuitable hosts.
—Trappist the monk (talk) 13:07, 15 November 2016 (UTC)
Yes, I can see that a solution is not a trivial task at all. Should we perhaps add to the documentation for the url parameter (perhaps at {{Cite web#URL}}) to say something like "urls with internationalized domain names will produce a Check |url= value warning; see here for a discussion" ? -- Finlay McWalter··–·Talk 13:23, 15 November 2016 (UTC)
Improved documentation is never bad. I think that referring to the archived discussion wouldn't be all that helpful. The documentation of this limitation should not be limited to {{cite web}} so the change should be made to Template:Citation Style documentation/url; should provide links to external puny encoders. The text might read:
URLs using non-Latin characters are not supported. These URLs must be converted to punycode. Online tools are available to internationalize URLs that are written in non-Latin scripts:
"IDN Conversion Tool". Verisign.
"IDNA Conversion tool". IDNA-converter.com.
—Trappist the monk (talk) 13:44, 15 November 2016 (UTC)

There may be some CS1 script errors popping up over the next day or two related to {{PDFlink}}. The template is a wrapper for {{cite web}} and will be substituted/replaced shortly. These script errors should be temporary, as there are a few instances where the unsubst version has errors not found in the substituted template. Once the substitutions are complete, there should be few if any script errors, but please let me know (either here or on my talk page) so that I can finish cleaning this up. Cheers, Primefac (talk) 17:07, 16 November 2016 (UTC)

Some of the problems are showing up in Category:CS1 errors: URL–wikilink conflict. I just fixed about eight of them. They are typically templates inside of templates. Move the offending template outside of the {{PDF}} or {{PDFlink}} template, and a bot will do the rest. – Jonesey95 (talk) 22:29, 16 November 2016 (UTC)

Tool for identifying what articles are cited under the work field

Is there a way to do that? I'm interested in setting up categories to keep track of articles about sources used by Wikipedia. Is there a way to generate a pinging list for any articles linked in the work= or website= fields by the use of this template on articles? Ranze (talk) 08:06, 18 November 2016 (UTC)

No tool that I'm aware of. There is this which is a collection dependent on |journal= which is one of the |work= aliases.
—Trappist the monk (talk) 13:20, 18 November 2016 (UTC)
Like Trappist said, there is WP:JCW for |journal=. It should be fairly straightforward to adapt User:JL-Bot to work on other parameters, but you'd have to contact the bot's owner for that. Headbomb {talk / contribs / physics / books} 13:23, 18 November 2016 (UTC)

author-linkn doesn't seem to work if n>10

See Platyceps najadum which has (Interwiki) links for authors 11 and 15 in the first ref. I determined through experimentation that the same links worked fine if I put them on an author #10 or below, but at their current, correct location, no links display. I also determined that the same symptom shows up for normal (not interwiki) links. --Floatjon (talk) 12:53, 18 November 2016 (UTC)

{{IUCN2014.2}} is not strictly a cs1 template but is a wrapper template for {{IUCN}} which is a wrapper template for {{cite web}}. This problem is not a failing of {{cite web}} but is a limitation of {{IUCN2014.2}} and {{IUCN}} which both only support |author-linkn= where 1 <= n <= 10. Rewriting the citation strictly as a {{cite web}} shows that |author-linkn= where n > 10 does work:
{{cite web |url=http://www.iucnredlist.org/details/157277 |vauthors=Lymberakis P, Ajtic R, Tok V, Ugurtas IH, Sevinç M, ((Crochet P-A)), Mousa Disi AM, Hraoui-Bloquet S, Sadek R, Haxhiu I, Böhme W, Agasyan A, Tuniyev B, Ananjeva N, Orlov N |author-link11=:de:Wolfgang Böhme (Zoologe)| author-link15=:fr:Nikolaï Orlov |date=2009 |title="Platyceps najadum" |work=IUCN Red List of Threatened Species |version=2014.2 |publisher=International Union for Conservation of Nature |access-date=2014-10-14}}
Lymberakis P, Ajtic R, Tok V, Ugurtas IH, Sevinç M, Crochet P-A, Mousa Disi AM, Hraoui-Bloquet S, Sadek R, Haxhiu I, Böhme W [in German], Agasyan A, Tuniyev B, Ananjeva N, Orlov N [in French] (2009). ""Platyceps najadum"". IUCN Red List of Threatened Species. 2014.2. International Union for Conservation of Nature. Retrieved 2014-10-14.
—Trappist the monk (talk) 13:12, 18 November 2016 (UTC)
I think, were all of our CS1/2 derivatives to call the module directly (with any parameters as necessary) rather than the CS1/2 templates, these limitations wouldn't exist. I haven't looked at how modules play with template syntax though. I might go try over at {{cite video game}} since that's a pretty basic template. --Izno (talk) 14:23, 18 November 2016 (UTC)
That should work as long as the template uses parameter names supported by cs1|2. The IUCN templates use |assessor= in places of |author= so that reassignment still needs to be done by the IUCN template.
|last1={{{last1|{{{last|{{{author1|{{{author|{{{assessor1|{{{assessor|}}}}}}}}}}}}}}}}}}
which still works, but has the same limitations that Editor Floatjon is complaining about. For {{cite video game}} something like this should work:
{{#invoke:citation/CS1|citation
|CitationClass=web
| title = {{{title|}}}
| author = {{{developer|}}}
| publisher = {{{publisher|}}}
| date = {{{date|}}}
| volume = {{{platform|}}}
| issue = {{#if:{{{version|}}}|v{{{version|}}}}}
| at = {{#if:{{{scene|}}}|Scene: {{{scene|}}}|}}{{#if:{{{level|}}}|{{#if:{{{scene|}}}|. }}Level/area: {{{level|}}}}}
| language = {{{language|}}}
| quote = {{{quote|}}}
}}
—Trappist the monk (talk) 14:56, 18 November 2016 (UTC)
Oh... I suppose they could write a small module that does what CS1/2 does with its enumerated parameters and then translate those into the equivalent assessors? --Izno (talk) 15:12, 18 November 2016 (UTC)

Flag issue= in Cite book as unsupported? And the more general question.

The discussion above reminds me of a long-standing question: should we flag |issue= as unsupported, placing it in the unsupported parameter category, when it is used in {{cite book}}? I guess the first question is: is it possible to do that in the module without a major rewrite?

The more general question: Should parameters that are valid in some CS1 templates (i.e. on the Whitelist) but not supported by specific CS1 templates:

1. be silently ignored (the status quo),
2. display a red error message and error category,
3. populate a maintenance category while displaying an optional error message in green,
4. populate an error category but show the error message only in Edit Preview mode, as is done with articles in Category:Pages using infobox mountain with unknown parameters and similar categories, or
5. something else?

To put my cards on the table: while it will be a pain to clean up, I think that silently discarding unsupported parameters is ultimately unhelpful to editors who are trying their best to use these complex templates. – Jonesey95 (talk) 16:17, 16 November 2016 (UTC)

I think my choice would be number 2 display a red error message and error category. This would show a reader of the encylopedia that the reference contains more possibly useful information. Some editor added the extra information; it may be of some use to a serious researcher, even if not displayed correctly due to a technical blunder on the part of the original editor. My second choice would be number 4 populate an error category but show the error message only in Edit Preview mode. This would let any editor know that there is an error that will require correction.--Arg342 (talk) 11:13, 17 November 2016 (UTC)
Please show error message to readers only when the errors impact verification. Otherwise, citations in general are cryptic enough for the average person. Secondly, "serious researchers" should know better: This is Wikipedia after all, where there is no formal mechanism for checking citations for completeness or accuracy. I doubt that incomplete or erroneous citations would escape the notice of such researchers for long. If they do, then some level of seriousness is lacking. 72.43.99.138 (talk) 17:15, 18 November 2016 (UTC)

Cite episode bug; missing parameters

{{Cite episode}}, which, according to its documentation "is used to create citations for television or radio programs and episodes", gives a red "Missing or empty |series=" warning when no |series= is provided.

For one-off programmes, the parameter is clearly not required.

I raised this last January, but nothing seems to have changed.

I've also previously requested the addition of |producer= and |writer= - could we have those, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:15, 16 November 2016 (UTC)

It was Help talk:Citation Style 1/Archive 10#Cite episode - series.
—Trappist the monk (talk) 16:32, 16 November 2016 (UTC)
Yes; that's what I meant to link to in my third paragraph (now fixed). When might this be fixed? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:24, 20 November 2016 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Help_talk:Citation_Style_1/Archive_28&oldid=1086690714"